Buenas,
Agree en todo :)
:'-)
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.
A mí, es que eso de abierto no sé qué significa en este contexto. Cuántos fabricantes pueden usar y construir LTO? Pero sí, oye, que sea abierto no es malo.
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.
Ah, eso. Sí, lo que yo llamo archivado profundo. Justo ese caso de uso. Trabajo para una organización de esas (de esas que generan ficheros cuyo tamaño individual es de varios TB). El reto es convencer a los ingenieros implantar una política de ILM. Lo guardan todo, son como diógenes... o peor. Van pasando el dato de un sitio a otro sin borrarlo de ningún sitio.
- 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.
Uhm... Sí, esto sí es 'fácil'. El asunto es que LTOn puede leer escribir en la generación 'n' y 'n-1', y solo leer de la 'n-2'. Lo normal es que las cintas 'n-2' vayan siendo migradas a generación 'n'. Esto, en una infraestructura con cientos de cintas... uhm... :-)
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.
Sin duda. Es un coste a tener en cuenta. En este caso, además, este tipo de datos deduplica fatal, con lo que la ventaja de la dedup frente a la compresión se pierde.
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.
Absolutamente normal lo de cambiar discos. (lo siento, no me sale nada por IIRC más allá de https://en.wikipedia.org/wiki/IIRC)
Por si alguien tiene curiosidad, esto es lo que tenemos: Ibrix en servidores y almacenamiento HPE
¿3PAR?
GPFS en DDN ZFS y BeeGFS en Supermicro
Interesante lo de Supermicro. Cuantas CPUs? Compráis soporte?
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 :)
Lo poquito que me han contado del mundo de fabricantes es que... no son exactamente las mismas librerías las Scalar y Spectra que luego venden a los IBM, HPE, etc?
- 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.
Hablamos de Enterprise, claro.
- 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:)
Es un proceso que compite contra: - operaciones de backup: si los drives están ocupados haciendo backup toca esperar. - operaciones de restore: se suelen configurar los restores con la máxima prioridad, así que si hay un restores se paran hasta los backups, ni te cuento las migraciones :-)
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.
Uhm, esto no lo he conocido... Interesante.
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.
Y cuáles son los efectos de esto? Lo digo porque no observo yo esas corrupciones habitualmente :-?
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
El RAID era una cosa estupenda hasta que los sistemas de almacenamiento han escalado tanto que ocurre lo que dices. Hay que inventarse otra cosa. Oh, wait!
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.
Erasure Coding es una cosa estupenda :-) Y es lo que usan las soluciones de object storage (swift si os gusta open source, S3 para el estándar de facto...).
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.
--> La muerte (pero lenta, claro).
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.
Sí, es estupendo. -- Saludos, miguel Los agujeros negros son lugares donde dios dividió por cero. Black holes are places where god divided by zero. Steven Wright -- 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