Hola :) On Friday 24 July 2009 19:31:14 Camaleón wrote:
El 2009-07-24 a las 18:52 +0200, Rafa Grimán escribió:
On Friday 24 July 2009 18:09:30 Camaleón wrote:
Es muy cómodo, sí. En raid por software necesitas intervención manual para poder iniciar el sistema. Aunque también es cierto que montarlo por software tiene otras ventajas.
¿Cuales? Yo no veo ninguna ...
- Precio (el coste de implementación es de "0" EUR)
Tienes que tener en cuenta el overheade de CPU y RAM y aumentar esa cantidad de CPU y RAM ;)
Como ha dicho carlopmart, los precios no son tan elevados: si quieres te envío un presupuesto ;)
Ningún prespuesto que paséis puede competir con el coste "cero" :-P
La ram está tirada de precio (hasta la ECC) y los micros no sé cómo andarán, pero vaya, tengas controladora raid o no tienes que tener un procesador decentillo.
Pero el RAID sw está ligado a la máquina y la controladora externa con RAID por hw no. Lo del precio depende de lo que mires: - la factura solamente - el time to market - ambas - otras Otra cosa, en un RAID, generalemnte se trabaja con un gestor de volúmenes (o se debería) para poder hacer cosas como crecimiento dinámico de sistemas de ficheros. Esto añade más cálculo a la CPU y consumo de memoria ;)
- Puedes acceder a los datos de inmediato en caso de fallo
Tienes que montar otro Linux (o el OS que hayas usado para el RAID sw o disco dinámico de MS-Windows). Si usas discos dinámicos de MS-Windows, el Linux no lo verá y al revés. Si haces un RAID por hw ... todos los OS lo verán, sólo necesitas que el OS tenga el driver para el sistema de ficheros que hayas montado por encima.
¿Quién ha invitado al windows a la fiesta del raid? Te pones una livecd y listo >:-)
Pues porque es la manía que tienen algunos: tener uno chisme de esos por ahí ;)
- No dependes de ningún fabricante
Cierto, pero te evitas el tener que manualmente decirle al RAID por sw que vas a sacar un disco y meter otro. Cambiar un disco de un RAID por hw lo podría hacer hasta un niño de 5 años ... habrá que empezar a contratarles ;)
Eso ya lo hemos comentado.
Eso es tiempo -> tiempo es dinero ;)
- Flexibilidad en la administración y configuración (integración directa con el SO)
RAID por hw puedes usarlo con diferentes OS ya que lo que ven es un LUN (o HDD virtual). Si el otro OS tiene drivers para leer el sistema de ficheros que estás usando, puedes montar una SAN junto con un clustered filesystem, claro está ;) Tienes clustered filesystems heterogéneos como CXFS y Veritas o no, como GPFS, OCFSv2 o GFS.
En nuestro caso, las cabinas las administras desde una herramienta gráfica que la puedes instalar en cualquier PC y la gestión de la cabina se puede hacer por ethernet (out bound) y/o por SAS/FC (in bound). Además, con una única aplicación de esas puedes gestionar todas las cabinas que tengas, no hace falta una aplicación por cabina. La aplicación es Java y la puedes usar desde Irix, Solaris, Linux, AIX, MacOS, MS-Windows, ...
Lo cual está directamente relacionado con el punto 1): precio.
Efectivamente y es lo que te preguntaba. Una SAN con un sistema de ficheros en cluster puede ahorrarte mucha pasta: - evitas duplicidad de datos: * ahorras en volumen de almacnemiento aka discos y/o controladoras * tiempo de backup * tiempo de recuperación * cintas o discos de backup * pérdida de tiempo a la hora d ebuscar ficheros - si usas FC o SAS aumentas la velocidad de acceso: * muy importante para cine y TV: no penséis en grandes productoras de Hollywood, pequeñas productoras también se ahorran mucha pasta y tiempo * muy importante en diseño * muy importante en entornos científicos - si usas iSCSI: * puedes utilizar tecnología barata (GigE) para montar una SAN con clustered filesystem * tienes las ventajas del punto 1 - si montas alta disponibilidad: * es muy recomendable tener una cabina externa con RAID por hw * se puede hacer con RAID por sw y drbd, pero el resultado no es el mismo y cuando el jefe está gritando porque el servidor de correo no funciona ... Te sale barato lo caro - al usar cabinas externas, puede usar gestores de volúmenes cLVM/LVM/... para "unir" cabinas y poder expandir tu sistema de ficheros hasta ... que alcance el bolsillo ;) Si usas RAID por hw, quitas un nivel de complejidad sw a tu sistema de almacenamiento Un ejemplo de caro/barato, un cliente al que le vendimos un maquinón de cuidado vió que la factura era también de cuidado, pero cuando sus diseños tardaban sólo 3 semanas y con la competencia tardaban 3 meses ... dijo: "Qué barato". Al final, el cliente admitió que el TCO era muy bajo y que el ROI fue muy alto (de 3 meses a 3 semanas). Luego, ¿es caro? También calculó ahorro de tiempo - factura y le salía rentable por ese lado también. Obviamente, depende mucho del entorno. He puesto un ejemplo bastante exagerado de un cliente grande. Pero también hay casos de clientes pequeños: correo y web y BBDD (un LAMP) en alta disponibilidad en una empresa de 5 personas. Servidores ASUS y cabina de discos externa SCSI (no me acuerdo del fabricante). Antes no lo hacían así y el tiempo que les costaba el tener que manualmente usar los comandos md para quitar y poner los discos ya era suficiente escusa. Otro ejemplo, tenemos un cliente (con dinero) que hace un Disaster Recovery entre Madrid y Barcelona con un rsync+cron. Eso es ser cutre. No por el dinero que tiene sino por el servicio que ofrece a todos los españoles que debería ser una cosa de muy elevada HA y QoS. Pero como es de la opinión de que eso* es caro. * desde cosas muy caras como fibra dedicada y copia síncrona (lo recomendable en este tipo de cliente) a cosas como BakBone o DataCore con copia asíncrona (menos caras, pero más caras que rsync+cron), pero mucho menos estresante para el disco, el cron (debido al volumen de datos que tiene se pueden solapar rsyncs), ... que el rsync. Entonces, el ahorro lo ves dónde, ¿en la factura? ¿ROI? ¿TCO? Estoy de acuerdo, no siempre está justificado o no siempre es necesario un RAID externo o un RAID por hw. Igual que no siempre es necesario gastarse un dineral en unos zapatos. Yo, por ejemplo ando descalzo por casa así que ahí no me gasto nada, pero para trabajar sí busco algo cómodo porque viajo mucho y si tengo que invertir un poco más, no me importa porque luego lo agradezco (dicen mis pies que ellos también lo agradecen ;) Muchas veces tampoco es fácil saber dónde poner una tecnología u otra ya que influyen muchos factores: - presupuesto del que disponemos - flujo de trabajo de la gente - conocimientos de los admins - ... Luego están también las manías de unos y otros. Conozco a dos personas que odian la consolidación de almacenamiento y lo quieren todo distribuido. Yo soy de la opinión contraria: prefiero un almacenamiento consolidado (hasta donde se pueda) que me va a ahorrar tiempo en administración que un montón de islas con datos duplicados, backups complejos, ... Pero cada uno tiene sus gustos ;)
- Facilidad de actualización en caso de cambio de equipo
En cabinas de discos con controladoras duales activas/activas, puedes hacer las actualizaciones sin down time :)
No me refiero a eso. ¿Y si el nuevo equipo NO tiene cabinas? ¿A comprar nuevo hardware? Yeeech, es un círculo vicioso (comprar, comprar, comprar) :-}
Si el equipo no tiene cabina externa (1 sólo servidor con 5 discos internos, por ejemplo, sin controladora por hardware) y te da por actualizar el OS (Linux, por poner un ejemplo) y hay un bug en el sw ... tienes parado el servidor y el almacenamiento. Si lo tienes separado basta con enchufar la cabina en otra máquina y empezar a servir. "Pierdes" un servidor, pero puedes seguir trabajando con esos datos. Para esto no hace falta que sea una cabina con controladora RAID, puede ser una JBOD externa y controladora RAID en placa PCI[X|e]. Es decir: barato.
A día de hoy un equipo bien construido y pensado para gestionar un raid por software (buena placa base, procesador potente, discos duros rápidos y con SAI detrás) no tiene porqué verse tan afectado en cuestión de rendimiento.
A mis clientes sí les afecta ;)
A otros usuarios no :-)
Efectivamente. Todo depende de la prisa que tengas en acceder a un dato.
Fíjate que hasta el ZFS implementa un "mini-raid" de serie (tiene nombre, pero no lo recuerdo ahora mismo). Por algo será.
z-RAID. ZFS es poco flexible ya que te incluye: gestión de RAID, gestión de volúmenes y sistema de ficheros todo en uno. Carlos (Robinson) tendría ahí un gran problema ;) Ahora en serio, imagínate que te gusta el z-RAID, pero quieres cLVM (porque es el estándar de la empresa) y GFS: NO puedes.
Si quieres z-RAID con EVMS y reiserfs ... TAMPOCO.
El ZFS es un bloque monolítico aka poco flexible.
Con eso no quiero decir que sea malo, digo que a MI no me gusta. Conozco gente a la que le gusta mucho y me alegro por ellos.
No te he dicho que lo uses >:-)
Ya, pero estaba dejando claro que es un gusto personal mío, una MHO.
Oye, pero es un principio. El concepto es original, es una buena idea. ZFS está aún verde, pero aporta una visión interesante de lo que debe ser un sistema de archivos. Al menos, innova.
Entonces te gustará btrfs. Por cierto, lo de que yo esté a favor del RAID por hw es MHO, no quiero que parezca que intento convencer a nadie a usar RAID por hw. Tampoco estoy en contra del RAID por sw. [...] Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org -- 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