Mailinglist Archive: opensuse-es (127 mails)

< Previous Next >
Re: [opensuse-es] Duda Tamaño de Disco Duro máximo
  • From: Rafa Griman <rafagriman@xxxxxxxxx>
  • Date: Wed, 9 May 2012 17:01:31 +0200
  • Message-id: <CANRt_=YGj+654kBCNDOvw9xh6nsGXwRUP+gVRTbiY2x2JUF76Q@mail.gmail.com>
Hey !!!

2012/5/9 Carlos E. R. <robin.listas@xxxxxxxxxxxxxx>:
-----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@xxxxxxxxxxxx
Para obtener el resto de direcciones-comando, mande
un mensaje a:
opensuse-es+help@xxxxxxxxxxxx

< Previous Next >