Hola :)
2017-05-22 10:47 GMT+03:00 miguel gmail
Buenas,
Actualmente LTO7. Yo prefiero LTO porque es un estándar. El de IBM es tecnológicamente mejor ... pero sólo de IBM.
Hay que distinguir varias cosas.
- la capacidad de las las cintas de 15 TB no dependen del fabricante, sino de la densidad de la cinta y de la longitud de ésta. Las densidades de las cintas de 15 TB son posibles gracias a un material relativamente reciente basado en Ferritas de Bario (BaFe): https://en.wikipedia.org/wiki/Barium_ferrite
Antes se usaban de 'Metal Particles' (MP). La diferencia es la forma que adoptan las partículas que se orientan a los campos magnéticos.
Es cierto que, además, influye el algoritmo de compresión que use cada drive... IBM promete 3x en sus TS, LTO 2,5x... no recuerdo cuánto promete STK (luego Sun, ahora Oracle) en sus T10000.
Agree en todo :)
Exacto, tiene sentido. Varios fabricantes, luego mejor servicio.
Psché... yo he vivido con librerías STK y... servicio inmejorable, la verdad. Creo que esto depende más del contrato de soporte que tengas. En cualquier caso, la tecnología de drive y cintas es muuuuy madura, dan poca guerra.
No me referia tanto a soporte o mantenimiento sino a la posibilidad de tener mas fabricantes (IIRC, LTO tiene 3 fabricantes) o competencia ... aunque ya sabemos como funciona con solo 3 fabricantes: se ponen de acuerdo y punto. Tambien porque es un estandar abierto. Estoy de acuerdo con lo que dices de que depende del contrato :)
Una cinta de 15 TB es algo muy interesante, pero costará una pasta gansa.
Hay que ver si es rentable. En entornos de HPC es rentable.
Esto no lo entendí... HPC me suena a exigencia de rendimiento rabioso, pero las cintas... salvo en lectura secuencial no tienen el rendimiento que supongo necesita un HPC. A qué te refieres?
No se utilizarian para "trabajar" (en plan LTFS) sino para Archivado y HSM/ILM en el mundo de HPC. Para este tipo de cosas no requieres una gran velocidad ni baja latencia sino volumen bruto. Aunque algunos fabricantes tienen buenas "bestias", como SpectraLogic con su T-Finity y su T950 (nosotros tenemos ambos modelos) que te permiten buen ancho de banda. El cientifico/ingeniero acaba un proyecto y se manda todo a cinta para dejar espacio libre en disco. El dato archivado o en HSM se utiliza muy rara vez.
Haces una inversión en el aparato, pero luego el coste por gigabyte compensa. Para usuarios pequeños, gastar 1500$ en el aparato es difícil de justificar, es más que un ordenador.
Cierto.
Para volúmenes pequeños no te vale la pena una unidad de cinta, es preferible un sistema de ficheros fiable (ZFS o XFS, mi orden de preferencia) en un servidor con memoria ECC y discos buenos (HGST si son rotacionales y Samsung EVO si son SSD, es mi preferencia aunque YMMV).
Para grandes volúmenes de datos la unidad de cinta tiene dos ventajas: - el consumo del aparato en sí (mucho menos que el equivalente en disco). La necesidad de refrigeración que necesita es mucho menor. - poder almacenar datos fuera, físicamente te puedes llevar las cintas a otro lugar.
Eso sí, el disco ocupa mucho menos espacio y es más rápido (más ancho de banda y menor latencia). Aunque la primera ... se puede discutir según el tipo de librería, ...
OJO, me refiero sólo al hardware, hay software de backup muy caro que te dispara el precio ;)
Las cuentas que yo hice la para organización para la que trabajo (grande, muy grande) concluían que *para backup* - sin contar costes de electricidad - el almacenamiento en disco es más rentable que la cinta. Las razones de esto son:
- La deduplicación es más eficiente que la compresión (cerca de 8x vs 2.5x) - El coste del sw de backup es un factor considerable. Algunos proveedores permiten ciertos trucos pero, en general, el mantenimiento del sw de backup, es un coste muy elevado.
Yup, eso es lo que mencionaba en mi correo anterior. El SW de backup es muy caro (prohibitivo). La rentabilidad me referia a HW. Es mas, es la principal razon por la que personalmente huiria de cinta: no tener que pagar los precios de los proveedores de SW de backup ;)
- El coste de la cinta puede parecer bajo frente al disco, pero cuando incluyes otros factores: - mantenimiento de las librerías (las grandes) y un montón de drives, el OPEX empieza a subir.
Esto no lo hemos visto nosotros y tenemos la T-Finity (20 PB) y la T-950 (5 PB). De hecho, una vez configuradas ... ahi estan. Lo unico que hicimos fue cambiar de LTO-6 a LTO-7 cuando estuvo disponible. Tarde unas 4 horas: comprobar firmwar, sacar fisicamente los drives LTO-6 y meter los nuevos, arrancar y seguir currando. El coste de consumo (incluyendo la refrigeracion) en cinta es mucho menor que en disco a mismo volumen de datos (incluso discos MAID). Lo digo porque tenemos 17 PB en Lustre y casi 3 PB en GPFS frente a los 25 PB de cinta. y mas de 500 TB en Ibrix. Otros sistemas de ficheros que hay por aqui son ZFS y BeeGFS. Es mas, hemos tenido muchos mas problemas con los discos que con las cintas, incluyendo perdida de datos: en uno de los casos los dos discos de un mismo RAID 1 de los metadatos se estropearon: adios metadatos ... adios datos. Esto era un GPFS. Discos andamos cambiando todas las semanas. Por si alguien tiene curiosidad, esto es lo que tenemos: Ibrix en servidores y almacenamiento HPE GPFS en DDN ZFS y BeeGFS en Supermicro No quiere decir que las cintas sean perfectas. Un cliente que tuve en ES tuvo una cinta atascada en un drive la primera semana (IIRC). Las cintas hay que tensarlas correctamente, hay que limpiar los cabezales, ... de lo contrario puedes tener problemas. En el caso de SpectraLogic, el firmware realiza muchas mas comprobaciones que otros fabricantes. Y todo el rollo de tensar cintas y limpiar cabezales lo tienen muy automatizado :)
- el coste operativo de manejar cintas, externalizarlas, etc. no se suele tener en cuenta... y es elevado.
En nuestro caso tenemos edificio para eso (un edificio de respaldo dentro del Campus). El que tenga que llevar las cintas a una caja fuerte y alquilar/comprar un local para eso, es otro gasto que tiene que tener en cuenta.
- el coste operativo de migrar las cintas cada una o, incluso, dos generaciones es enorme. La misma operativa sobre disco es muuuucho más sencilla y rápida.
En disco es mucho mas sencillo, especialmente si utilizas sistemas de ficheros modernos (SDS). En el caso de cinta, no es algo que hagas todos los dias. Migramos de una librerias de IBM antigua a la nueva y fue cosa de paciencia mientras se copiaban los datos. Sip, de disco a disco hubiese sido mas rapido. Pero esto era archivado asi que tampoco habia mucha prisa :) Cuando migramos de LTO-6 a 7 tampoco fue mucho curro, mas bien paciencia. No lo hice yo asi que no puedo dar detalls 0:)
... pierde esa ventaja.
Además, hay un coste que no se suele incluir: el error silencioso. Ocurre que, muy de vez en cuando, una drive puede guardar mal un dato en la cinta, o el dato 'pudrirse' en la cinta... y no hay forma de saberlo hasta que necesitas ese dato; entonces suele ser demasiado tarde.
Esto lo tienes con discos tambien: silent data crruption. Depende del sistema de ficheros que uses el que se pueda solucionar. RAID no ayuda porque te comprueba la paridad al escribir, pero no al leer de nuevo el dato. El bit flip puede ocurrir una vez que el dato ya se haya escrito y hay pasado un tiempo. ZFS y XFS, por ejemplo, te hacen un CRC (ZFS hace mas comprobaciones). GPFS tambien protege contra esto (ahora no me acuerdo como). RAID tampoco sabe si de RAM a disco el bit ha cambiado (ZFS si lo comprueba, XFS no).
Un disco, en cambio, suele ir protegido con RAID y las controladoras hacen un trabajo excelente controlando estas cosas y, en muchos casos, el sw de backup puede ejecutar tareas periódicas adicionales de comprobación de integridad con costes operativos muy bajos (no hay que andar montando y desmontando cintas que - aún de forma automática - es un proceso costoso en tiempo).
El disco tiene otro problema: las caches del propio disco. Los discos sufren microcortes de electricidad y pierden datos de la cache (mas habitual de lo que nos imaginamos). En mi epoca en SGI ya recomendabamos a los clientes deshabilitar la cache del propio deisco debido a su baja fiabilidad. El RAID que conocemos a dia de hoy es poco eficiente porque: - los discos son demasiado grandes. Una regla "aceptada" es que 1 disco de 1 TB SATA en RAID 5/6 te tarda 24 horas en recostruir (mas o menos). Teniendo en cuenta que tenemos discos de 10 TB ... Es muy grande el tiempo de reconstruccion. - el volumen de datos que se maneja es brutal - mientras reconstruye, se pierde rendimiento del almacenamiento Es mucho mejor utilizar un SDS en el que se utilizan Erasure Codes ya que: - solo se reconstruyen los bits afectados (RAID te reconstruye el disco entero, por eso tarda tanto) - en la reconstruccion intervienen todos los discos por lo que el rendimiento "no cae" (es despreciable) - puedes aplicar diferentes niveles de proteccion individualmente a cada fichero y directorio en el mismo sistema de ficheros. Por ejemplo, el directorio small_files puede tener un mirror (RAID1) mientras que el directorio big_files puede tener una proteccion N+4 (similar a RAID5, pero con 4 discos de paridad) y todo en el mismo sistema de ficheros. Con RAID tradicional, tienes que montar sistemas de ficheros diferentes en diferentes RAID (bueno, con LVM lo puedes trampear, pero no controlas donde se colocan los ficheros) - puedes crecer y decrecer el sistema de ficheros sin parada (en RAID por HW y LVM tambien lo puedes hacer) con un simple comando (a lo mejor dos ;) No pretendo defender la cinta "a capa y espada", creo que cada uno tiene su utilidad.
Finalmente, en cuanto a rendimiento: Realmente las cintas no son malas en cuanto a lecturas o escrituras *secuenciales*; cualquier cosa que no sea eso el rendimiento se reduce muchísimo... más o menos igual que un disco. Las operaciones de escritura de datos deduplicados tienen rendimientos aceptables... al contrario que la recuperación de datos... el rendimiento de 'rehidratación' no es brillante, siendo generosos :-)
Estoy de acuerdo, cintas tienen buen ancho de banda si es secuencial, como hagas I/O aleatoria ... estas perdido, especialmente si tienes que saltar de cinta a cinta.
En esta organización hemos dejado la cinta para aquellas situaciones en que doble copia a disco (una local, otra remota) no es posible por razones de línea de comunicación o legales (no es posible enviar datos fuera de ciertos países).
Ufff ... los temas legales son de lo mas entretenido ;) En temas de comunicacion (bajo ancho de banda y gran volumen de datos), podria ser interesante el tema de SDS. Algunos sistemas de ficheros te permiten delimitar copias o datos a una zona geografica determinada. Ceph (IIRC) te permitia algo por el estilo. MHO 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