OVH NEWS | ACTUALIDAD, INNOVACIÓN Y TENDENCIAS IT


Descubrir, entender y adelantarse









18/04/2018
Compartir

Artículo redactado por ...


OpenZFS: ¿por qué esta tecnología de almacenamiento de código abierto no pierde poder de seducción?


Los pasados 24 y 25 de octubre se celebró en San Francisco la quinta edición del OpenZFS Developer Summit, con el apoyo de OVH. OpenZFS, que cumple 12 años, es una tecnología que utilizamos a gran escala desde 2011 para el almacenamiento de los datos de los alojamientos web, correo electrónico, VPS, NAS-HA, Private Cloud o Backup Storage. Como cabía esperar, François Lesage y Alexandre Lecuyer, ingenieros de almacenamiento de OVH, se desplazaron a California para abordar con la comunidad de OpenZFS el futuro de esta tecnología.





Los pasados 24 y 25 de octubre se celebró en San Francisco la quinta edición del OpenZFS Developer Summit, con el apoyo de OVH.



‘Filesystem’ y ‘object storage’: ¿por qué necesitamos los dos?


En un momento en el que el object storage parece ser el centro de todas las miradas (OpenStack Swift, Ceph…), puede resultar sorprendente constatar la vitalidad de la comunidad que gravita en torno a OpenZFS y sigue ampliando sus funcionalidades año tras año. A primera vista, el object storage tiene todo para gustar: distribuido y, por lo tanto, altamente disponible y escalable hasta el infinito, pero a la vez económico, ya que se basa en hardware estándar (servidores de arquitectura x86 y discos duros convencionales). La potencia del sistema radica en el número de máquinas, más que en el rendimiento y la capacidad individual de cada elemento del conjunto. De este modo se atenúan los «escalones» que encarecen los filesystems, ya que, para aumentar la capacidad de almacenamiento, es necesario aprovisionar nuevos chasis provistos de discos de gran capacidad que tardarán un cierto tiempo en llenarse y, por ende, en rentabilizarse (scale up).



Al utilizar masivamente el sharding (distribución de los archivos o, incluso, de diferentes bloques o segmentos de un mismo archivo entre varios nodos del cluster), el object storage ofrece latencias que no igualan las de un filesystem tradicional, alojado en local o en un NAS. Por lo tanto, el object storage no es adecuado para determinados usos, por ejemplo, para sistemas de gestión de bases de datos (SGBD), que están constantemente solicitados por operaciones de lectura-escritura. Esa es la razón por la que las infraestructuras íntegramente basadas en Public Cloud recurren al almacenamiento local en la máquina virtual o en un block storage, cuando no a un servicio de Cloud Databases, para las bases de datos.



Por el contrario, el object storage es idóneo para almacenar y servir archivos pesados, fotos o vídeos, por ejemplo. En estos casos, la latencia se verá compensada por la mayor velocidad de descarga que proporciona el diseño distribuido del object storage, que recurre a varias máquinas en paralelo para entregar el archivo. Además, es posible implementar delante un sistema de caché para servir de forma instantánea los archivos más demandados.



Por último, si bien es posible programar un sistema de archivos (filesystem) virtual por encima de un object storage (algo que se suele hacer, puesto que muchas aplicaciones están pensadas para funcionar con un filesystem), una tecnología como OpenZFS ofrece funcionalidades que no tienen las soluciones de object storage. Esta es la otra cara de la moneda de su extrema simplicidad.



De este modo, la reputación de OpenZFS se debe en gran medida a funcionalidades avanzadas como la replicación, la deduplicación, la compresión, la posibilidad de crear clones (snapshots del sistema que se pueden modificar) y de compartir datos entre distintos sistemas, el bloqueo de los datos en clusters cuyos componentes deban estar sincronizados en tiempo real e incluso la protección y corrección de los datos con un sistema de comprobación de la integridad que impide que los archivos se corrompan de forma silenciosa. Todo ello con un rendimiento y una estabilidad que no tienen comparación cuando esta tecnología se emplea a gran escala, como es el caso en OVH. De hecho, hay quienes atribuyen al acrónimo ZFS significado de «Zettabyte File System». El zettabyte es una unidad de medida que en los años 2000 parecía una locura... y que pronto será habitual para operadores como OVH (dicho sea de paso, también nosotros atribuimos varios significados apócrifos a esas tres letras... aunque nos abstendremos de desvelar el misterio).



OpenZFS: de las infraestructuras ‘on premise’ al cloud


Hace algunos años, las empresas se decantaban de forma casi unánime por soluciones de almacenamiento con hardware y software propietarios. Estos sistemas son potentes y robustos, y tienen la ventaja indiscutible de ofrecer tranquilidad a los usuarios, independientemente de su nivel jerárquico en la empresa, en relación con la conservación de los datos. Con todo, el precio que hay que pagar por ello es alto. En la actualidad, la situación ha dado un vuelco. Empresas como Facebook utilizan OpenZFS (y realizan contribuciones, en particular para mejorar los algoritmos de compresión) e incluso sectores como el de los seguros, la banca o incluso el cine han desplegado infraestructuras de almacenamiento que funcionan con esta tecnología. Por un lado, esto les permite reducir costes drásticamente en un contexto en el que la producción de datos crece de forma exponencial. Por otro, los sistemas propietarios constituyen auténticas cajas negras, en el sentido de que no es posible saber cómo funciona el código, ni modificarlo uno mismo. Sin embargo, el almacenamiento se ha convertido en un elemento de las infraestructuras que cada uno quiere poder adaptar a su estrategia y sus necesidades particulares. El éxito de OpenZFS también se puede vincular al hecho de que se incluya por defecto en Ubuntu desde la versión 16.04, lanzada en 2016.



Así pues, cada vez son más las empresas que sustituyen sus racks de almacenamiento propietarios por plataformas on premise con OpenZFS. Evidentemente, el siguiente paso es trasladar todo o una parte de este almacenamiento al cloud, es decir a un proveedor de servicios de cloud como OVH, que ofrece NAS-HA con OpenZFS as a service.






Cada vez son más las empresas que sustituyen sus racks de almacenamiento propietarios por plataformas con OpenZFS.



ZFS y OpenZFS: ¿rumbo a la reconciliación?


El OpenZFS Developer Summit fue el escenario de un anuncio bastante inesperado por parte de Mark Maybee, arquitecto jefe de la tecnología ZFS en Oracle. Maybee hizo pública su intención de reconciliar la tecnología de almacenamiento ZFS —cuyo código procedió a cerrar Oracle poco después de haberlo heredado con la compra de Sun en 2009— con su rama libre, OpenZFS, con el objetivo de aunar los esfuerzos de desarrollo y afianzar la tecnología, convirtiendo a ZFS en un componente upstream de Linux y, por lo tanto, en la base de los sistemas de almacenamiento, ya sean o no de object storage.



Por desgracia, el proyecto no tiene visos de llegar a materializarse a la vista del reciente despido de Oracle de Mark Maybee, según informa Bryan Cantrill en su cuenta de Twitter.



Por otro lado, el OpenZFS Developer Summit puso de manifiesto que, en la actualidad, algunas empresas desarrollan servicios propietarios basándose en OpenZFS, con el riesgo que implica trabajar sobre un fork. No obstante, el encuentro fue ante todo una ocasión para descubrir mejoras significativas de la tecnología y pruebas de concepto tan sorprendentes como prometedoras... y para imaginar, con cierta impaciencia, qué aplicación se podría dar a estos avances en OVH. Este es un ejercicio al que ya nos prestamos en 2015, cuando presentamos en el OpenZFS Developer Summit un parche para migrar datos sin interrupción del servicio.



Repaso de los principales anuncios del OpenZFS Developer Summit 2017




El OpenZFS Developer Summit fue una ocasión para descubrir mejoras significativas de la tecnología e imaginar, con cierta impaciencia, qué aplicación se podría dar a estos avances en OVH.



Mejora de la seguridad


MMP: importación segura de pools para clusters



Incorporación de medidas de seguridad para evitar la importación de un mismo pool en dos máquinas, lo que podría romperlo.



Posible aplicación en OVH: Securizar la migración de un datastore a otro en caso de fallo de hardware (para la solución Private Cloud). Podría ser una alternativa en caso de que no fuera materialmente posible cortar las conexiones SAS.



DRAID: una alternativa a RAIDZ



Intel propone una alternativa a RAIDZ (el dispositivo de RAID nativo de OpenZFS). Su principal ventaja es que acelera considerablemente la velocidad de reconstrucción de un pool tras un fallo en uno o más discos. El inconveniente es que DRAID utiliza un poco más de espacio, ya que recurre al padding para que los datos y la paridad lleguen siempre a los mismos discos. Es un enorme proyecto que llega a su fin y que pronto debería incorporarse.



Posible aplicación en OVH: No cabe duda de que resultará muy interesante para los pools de backup, así como para las webs espejo que OVH pone a disposición de sus clientes (véase el recuadro al final del artículo). La idea es que al reconstruir un disco de forma más rápida, la situación de riesgo se prolonga menos tiempo. El parche ya está disponible en la wiki del proyecto.



Mejora de la velocidad de reconstrucción de un disco (resilver)



Reconstrucción más rápida de un disco después de una sustitución, generando IO secuenciales en lugar de aleatorias. Se genera una cola de las escrituras necesarias, clasificadas en función de su ubicación en el disco (offset). De esta forma, las operaciones de escritura requieren menos desplazamientos de la cabeza de lectura en el disco y se acelera la reconstrucción. Por consiguiente, la redundancia se restablece más rápidamente. A día de hoy no se ha anunciado la fecha de publicación del parche.



Storage Pool Checkpoint



Permite realizar un checkpoint de un pool entero, incluidas sus propiedades.



Posible aplicación en OVH: Mejora de la seguridad antes de una operación que entrañe riesgo para el pool, con la posibilidad de un rollback a escala si una migración va mal.



Mejora del rendimiento


Compresión ZStandard



OpenZFS permite aplicar una compresión a los archivos almacenados, pudiendo elegir entre varios algoritmos que permiten ganar hasta un 80% de espacio en función del tipo de archivo. ScaleEngine, en colaboración con Facebook, ha desarrollado un nuevo algoritmo de compresión muy rápido, como LZ4, pero con una eficiencia de compresión próxima a la de gzip.



Posible aplicación en OVH: Optimización de los pools de backup, a cambio de un consumo superior de recursos de CPU.



Borrado rápido de los clones



Eliminación más rápida de los clones (snapshots modificables) mediante la elaboración de una lista de los bloques empleados por un clon para no tener que recorrerlos todos.



Posible aplicación en OVH: Clonar las MV del Private Cloud (los datastores utilizan la tecnología OpenZFS) con integración VAAI.



Asignación más rápida con el log space map



Si ZFS debe asignar y desasignar espacio en cualquier parte de un disco, eso genera una gran cantidad de IO, ya que a cada región del disco le corresponde un space map. Cuando las operaciones de lectura-escritura se realizan en muchas regiones, este proceso genera un gran número de IO aleatorias.



La idea es guardar la información en la RAM y escribir un solo log para todos los space maps que solo servirá para recuperarlo en caso de fallo. La actualización de los space maps en los discos se realiza de la siguiente forma: se actualiza un space map en cada grupo de transacciones (TXG).



Posible aplicación en OVH: Mejora del rendimiento, sobre todo cuando se eliminen datos masivamente. El parche no está disponible todavía. Probablemente lo esté a lo largo de 2018.



iFlash: cacheado L2ARC adaptativo dinámico



En una plataforma OpenZFS se puede utilizar un disco SSD como caché para acelerar las operaciones de IO. El inconveniente es que el tamaño de este espacio de caché, así como el del ZIL (ZFS Intent Log, que, simplificando, viene a ser la caché para las escrituras síncronas), debe establecerse de antemano para cada uno de los clientes de la plataforma. Un fabricante de racks de almacenamiento ha desarrollado una aplicación propietaria que permite una asignación dinámica de este espacio de caché en el disco flash.



Esta solución podría ser muy interesante para OVH, ya que nos encontramos con el mismo caso de uso en los NAS, pero se trata de una aplicación propietaria basada en una versión de ZFS de 2013.



Rendimiento ZIL



Actualmente, cuando una aplicación realiza un fsync(), deben realizarse todas las escrituras síncronas en espera. Este parche mejora la granularidad y el paralelismo de las escrituras síncronas en el ZIL. Su desarrollo no ha finalizado, pero debería estar en producción a lo largo de 2018.



Posible aplicación en OVH: Mejora del rendimiento de buena parte de la carga, en particular en Private Cloud, cuya arquitectura con dos datastores redundantes requiere una gran cantidad de escrituras síncronas.



Mejoras operativas


«Oh Shift!»: cambiar el tamaño de asignación



A día de hoy es imposible cambiar el tamaño de asignación (alineación del pool) después de crearlo. Esto conlleva grandes problemas de rendimiento en caso de que, en un pool creado en 512 bytes, se sustituyan discos averiados por discos 4K, que realizan la emulación de 512 bytes, debido al read modify write. El parche permitirá alinear las escrituras a un tamaño superior, y en caliente.



Posible aplicación en OVH: Al sustituir los discos, ya no estaremos obligados a prestar atención al tamaño de asignación de los mismos para evitar posibles problemas de rendimiento.



Expansión RAID-Z



Posibilidad de añadir discos a un vdev RAID-Z. Aunque no parezca gran cosa, es un gran progreso. Hasta ahora no era fácil añadir un disco a un pool existente. Este avance es un (pequeño) paso hacia una mayor escalabilidad.



Posible aplicación en OVH: Limitada, ya que no añadimos muchos discos a posteriori.



Aceleración por 1000 de la velocidad de deduplicación



Este proyecto consiste en cambiar el formato en disco de la tabla de deduplicación para limitar enormemente las operaciones de lectura-escritura que genera la deduplicación. Un log sustituye a la tabla hash. El árbol se construye en la RAM a partir del log en disco cuando se importa el pool. Si no cabe en la RAM, se desactiva la deduplicación para los nuevos bloques.



Interés para OVH: A fin de cuentas, la deduplicación (optimización de los archivos presentes por duplicado en una infraestructura) no es utilizable a día de hoy. Aplicada a nuestra escala, es demasiado inestable y arriesgada. Si este proyecto llega a buen puerto, se podría valorar realizar una prueba, pero requeriría máquinas con mucha RAM.



OpenZFS en OS X y Windows 10



Un desarrollador ha portado el código de OpenZFS a Mac OS X y... ¡a Windows 10! Un buen trabajo, pero no vemos que tenga ninguna aplicación en OVH por ahora... 🙂



Los ‘mirrors’ de OVH: un uso típico de OpenZFS para almacenamiento masivo


Desde hace mucho tiempo, OVH aloja sus propios mirrors. Desde ellos se pueden descargar distribuciones de código abierto como Debian, Ubuntu, Postfix u OpenCSW (en total hay un centenar de mirrors). Mantener estos mirrors es una forma de contribuir a las distintas comunidades. Al ofrecer una alternativa a las principales webs de descarga, aliviamos a los servidores de la comunidad y reducimos sus necesidades de recursos informáticos y ancho de banda. Además, cuando los usuarios de servicios de OVH solicitan la preinstalación de distribuciones y paquetes en sus máquinas, las descargas se realizan desde estos mirrors.



Con ese fin, almacenamos más de 40 TB en OpenZFS con triple replicación, para así disponer de copias geográficamente cercanas a nuestros datacenters y, de este modo, ofrecer menores tiempos de descarga. En esta plataforma de almacenamiento se recurre de forma intensiva a snapshots para poner a disposición de los usuarios imágenes conocidas y probadas, y se ofrecen los últimos lanzamientos en tiempo real.