Hola :)
2017-05-22 17:19 GMT+03:00 miguel gmail
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.
IIRC, hay 3 fabricantes ... todos "enemigos" <wink> <wink> <wink> Ya sabes: seguro que se sientan juntitos para ver como realmente reducir los costes al cliente y permitirle vivir en un Mundo mas abierto y Libre. Y seguro que NO pactan precios.
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.
xD xD xD Creo que compartimos usuarios ;) Diogenes era la cima del orden y la limpieza comparado con los usuarios que mencionas :)
- 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... :-)
Lo incomodo es cuando tienes las cintas fuera de la libreria. Entonces si que es un PITA tener que anda metiendo cintas y sacando cintas. SpectraLogic facilita esto con una especie de contenedor en el que metes/sacas cintas de 10 en 10. La libreria se encarga de saber que cinta va en que contenedor. Cuando compras cintas nuevas, te vienen ya en los contenedores. Solo tendrias que meterlas/sacarlas "amanuense" si se estropea una cinta o bien compras 1 cinta porque tienes un contenedor con algun hueco.
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.
Yup ... aunque bueno ... hay usuarios que se encargan de tener como 173 copias del mismo fichero repartidas por el sistema de ficheros xD xD A veces comprimen las copias, a veces no, a veces usan el mismo compresor, a veces no, ... A veces tienen directorios anidados ... con la misma informacion una y otra vez. Creo que sabes de lo que hablo ;) ;)
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)
If I Remember Correctly. Perdona 0:)
Por si alguien tiene curiosidad, esto es lo que tenemos: Ibrix en servidores y almacenamiento HPE
¿3PAR?
Nop, DLs y MSAs. Viejunos :(
GPFS en DDN ZFS y BeeGFS en Supermicro
Interesante lo de Supermicro. Cuantas CPUs? Compráis soporte?
Lo de SuperMicro son unas bestias que tenemos que encadenar al suelo porque llevan 24 discos NVMe ... Espera que se me cae la baba ... Para que te hagas una idea: un compi decidio hacer un "benchmark" con 80 mil ficheros en no se cuantos directorios y subdirectorios. Decidio hacer un ls -lR /mnt/nvme /mnt/ssd. Mismo numero de discos SSD y NMVe, en el mismo servidor y exportando por NFS. Tenia 2 terminales abiertas: en una tecleaba ls -lR /mnt/nvme o bien ls -lR /mnt/ssd pinchaba en la otra terminal y tecleaba iotop* Pues con los NVMe no le daba tiempo a pincha en la otra terminal. Instantaneo. Se me ponen los pelos de punta solo de pensarlo. Al compi los SSD le parecen lentos y anticuados xD xD xD Si quieres te paso datos tecnicos con mas detalle del bicho este. *Ya, podia dejar el iotop corriendo. Pero era parte del "benchmark" con rigor cientifico que estaba haciendo. Luego si uso iozone y SW de los propios usuarios.
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 drive es el mismo, lo que ocurre es que los fabricantes luego tienen permiso (o no) para modificar el firmware. En el caso de SpectraLogic, aumentan el numero de cosas que monitorizan para mejorar la fiabilidad.
- 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.
Universidad, es donde estoy ahora.
- 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 :-)
Tienes toda la razon :) Lo realmente lento es el cambio de cintas ... La T-finity tiene 2 brazos y 24 drives (IIRC) y aun asi ... cuando hay mucho jaleo le cuesta. Lo "bueno" es que la T-finity se usa exclusivamente para HSM asi que "no hay prisa". La T950 la usamos para backup y archivado y limitamos los datos que van al backup a /projects, nada de /scratch.
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.
https://en.wikipedia.org/wiki/Data_corruption#SILENT http://changelog.complete.org/archives/9769-silent-data-corruption-is-real
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 :-?
Perdida de datos. Yo no lo he visto, desde hace 12 anos deshabilito siempre las caches de los discos (las controladoras RAID de LSI lo hacen automaticamente si quieres y con hdparm tambien lo puedes hacer). Creo recordar (tendria que repasar la documentacion de ZFS), que cuando usas ZFS te recomiendan que tambien deshabilites la cocahe de la controladora RAID (configurar la controladora en modo write-through en lugar de write-back). Lo hacen porque ZFS utiliza la RAM como cache, por eso recomiendan ECC RAM. [...]
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...).
Eso es :) Menos mal que lo inventaron (y usan).
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).
xD xD xD Lo que decias antes, como para una prisas en un proceso de restauracion xD xD xD
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.
Bueno que lo confirmes. Usas Ceph (u otro SDS) para Geoclustering? Por saber que tal funciona, nunca lo he usado. Gracias !! 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