On Monday 15 November 2010 14:11:51 Ramiro Magallanes wrote: > Ahora te vuelvo a preguntar: ves logico mantener gastar un 3er disco > para almacenar donde-esta-que cuando haces un raid sobre 2 ?
No veig què té d'estrany. Aquest detall no em preocupa gaire si tota l'arquitectura és coherent i funciona; cosa que no passava amb l'únic GFS que he vist en producció (però probablement el problema no era GFS sinó PEBKAC). Un altre exemple de separació de dades i metadades era Lustre. I sembla coherent si en lloc de mirar-te estrictament les dades, mires el flux d'informació. Els servidors de metadades han d'escupir informació "curta" a tota castanya. Els servidors de dades poden passar-se molta estona escupint fitxers grossos, però el sistema no es quedarà frenat esperant les metadades. Un altre benefici hauria de ser fer més fàcil el creixement: pots anar afegint capacitat a base de caixes de discs, i afegir puntualment servidors de metadades quan vegis que es frenen. El hardware estrictament per storage és força típic i, per tant, més fàcil de seleccionar que el de metadades. Barrejar les dues funcions encara ho complica més. L'altra cosa que m'agradava de l'arquitectura de Lustre era que, si demano un fitxer d'un servidor de dades caigut, el servidor de metadades li pot passar aquesta informació, sense esperar; però si les dades i metadades són al mateix servidor, què tinc? L'aplicació espera fins que hi hagi un timeout? Tinc la sensació de que faria servir GFS i Gluster en casos diferents, però en tot cas no em preocupa que algun detall de l'arquitectura sembli poc elegant. Si han d'agafar compromisos per a que el sistema funcioni, endavant. Ramiro, no em queda clara una cosa. En igualtat de condicions, tots triaríem un sistema que sembli més elegant. Però em sorprèn que li dones molta més importància que jo a la separació de dades i metadades. Perquè? -- ############################## ### Jordi Funollet ### http://www.terraquis.net -- _______________________________________________ Comandob mailing list Comandob@badopi.org http://lists.badopi.org/mailman/listinfo/comandob
