Hey !!! 2012/5/9 Carlos E. R. <robin.listas@telefonica.net>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-05-09 16:20, Rafa Griman wrote:
Wenas :)
Jo, vaya respuesta, gracias... me la tendré que leer despacio para entenderla :-)
Solo comentaré algo:
En cualquier caso, el peligro de perder un sector, o un disco de un array, es bastante grande.
Sip, de ahí el uso de RAID.
Leí un estudio no hace mucho que con esos tamaños de ahora el riesgo de perder un disco durante la reconstrucción era muy grande, y lo demostraban numéricamente con la tasa de fallos por mega multiplicado por los megas del disco, y el tiempo necesario para la reconstrucción. Por eso pensaba en sistemas de ficheros distribuidos.
El problema no es sólo que si pierdes un disco (de 3 TB) pierdes mucha info ... hmmmm, mejor dicho: la probabilidad de perder [...] ;) Hay otros problemas asociados como por ejemplo: - tiempo de reconstrucción: hablamos de algo más de un día para discos > 2 TB - pérdida de rendimiento durante la reconstrucción de un RAID - probabilidad de perder otro disco durante la reconstrucción de un RAID. Si tenemos RAID 6, podemos perder hasta 2 discos ... pero si perdemos un tercero ... good bye ... Por eso, muchos fabricantes recomiendan: - RAIDs pequeños de unos 8+2 discos - RAID 10 - backups - backups - backups - backups - backups - backups - DR y BC - deduplicación - compresión - backups - backups - backups Personalmente añado a esta lista: borrar toda la basura que NO usas ;) No ... no lo necesitamos todo, podemos vivir sin tener una copia de Internet en nuestro disco duro: nuestros antepasados sobrevivieron y nosotros hasta hace poco también :D ;) De todas maneras, en el mundo HPC, no siempre se tienen ficheros muy grandes, lo que pasa es que durante el procesado de los datos puede ocurrir: - que se generan muchos ficheros temporales - que hace falta un elevado ancho de banda a disco para evitar lo que se llama CPU starvation (que los procesadores "pasen hambre" y se encuentren tocándose las narices y consumiendo electricidad y produciendo calor).
Parecen soluciones propietarias, ¿no?
Hay de todo: Lustre, Cephs, OrangeFS, PVFS, ... son libres. Panasas está basado en FreeBSD, pero no liberan el código AFAIK. Aunque no te cobran por el software, es decir, no te cobran por el cliente/agente software que tienes que instalar. Te cobran por el hardware que compras. Isilon está basado en Linux, pero te cobran por hardware y licencias software. Tranquilos, no te cobran el Linux, te cobran las licencias de las aplicaciones suyas: balanceo de carga, monitorización avanzada, ... que es SW cerrado. CXFS tiene el código de los MDS cerrado porque: - hay código que no es de SGI - no consiguen localizar al desarrollador de cierto código y, por tanto, no pueden liberar ese código sin su permiso Os aseguro que internamente en SGI hay muchas peticiones de los propios desarrolladores y técnicos, pero los abogados no se atreven por lo mencionado anteriormente. Lo malo es que es mucho código y reescribirlo sería muy costoso (en tiempo) y complejo. GPFS es cerrado y bien cerrado (y caro). Hay de todo un poco ;) De todas maneras, en el mundo HPC, el "ganador" es Lustre. Lustre se está llevando el gato al agua en casi todos los proyectos. HTH Rafa -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org