¿Por qué OVH apuesta por OpenZFS?

El evento anual OpenZFS Developer Summit se desarrolló durante los días 19 y 20 del pasado mes de octubre en la ciudad de San Francisco, California. OpenZFS, que hasta el momento había sido utilizado discretamente en el sector tecnológico, celebra sus diez años y su adopción se amplifica. Conozca cómo se ha utilizado esta tecnología de open source para almacenar los 12 PB del rodaje de la película "Gravedad" (1), e incluso cómo se ha integrado al último lanzamiento de Ubuntu, como sistema de archivos nativo. OVH, que comenzó a utilizar OpenZFS en el año 2009, envió al Summit dos representantes de su equipo de almacenamiento, con el fin de conocer las nuevas propuestas y de ofrecer además una contribución al proyecto “Live migration with Zmotion”. François Lesage y Alexandre Lecuyer, ingenieros de almacenamiento de OVH, ofrecen los detalles.

El evento fue también la ocasión para celebrar los diez años de OpenZFS.

OVH propone un parche para la migración de datos sin downtime

OpenZFS se deriva del proyecto ZFS, patrocinado por Sun Microsystems (propiedad de Oracle desde 2009), una bifurcación llevada a cabo en el año 2005 por una comunidad independiente, formada fundamentalmente por antiguos colaboradores de Sun. Aparte de Netflix, que explota OpenZFS por su plataforma Titan (2), no muchas empresas del sector tecnológico han admitido el uso de OpenZFS, que ha consolidado su fiabilidad. Los especialistas proveedores de almacenamiento tradicional proponen soluciones patentadas sólidas y de alto rendimiento, que tienen la innegable ventaja de tranquilizar a los usuarios con respecto a la conservación de sus datos. «El inconveniente, -explica François- es el precio. Estos sistemas funcionan con un tipo específico de hardware, que aumenta considerablemente el costo por GB; y constituyen verdaderas cajas negras, ya que no es posible descifrar o modificar su código.»
Por su compatibilidad con la arquitectura x86 (máquinas estándar), OpenZFS reduce de manera drástica el costo de almacenamiento, además de tener un código abierto, lo cual posibilita que OVH pueda adaptarlo y hasta mejorarlo. «A diez años del lanzamiento de OpenZFS, su estabilidad continúa siendo satisfactoria, prosigue François. Su sistema de comprobación de la integridad de los datos, que previene minuciosamente la corrupción silenciosa de los archivos, está entre los más efectivos. Por otra parte, su conjunto de funciones es muy amplio: snapshot, almacenamiento en frío y en caliente... »
En el año 2007, OVH dejó EXT3 por ZFS, y un poco más tarde, en 2009, se interesó en OpenZFS. Los primeros proyectos de OVH en OpenZFS vieron la luz a fanales de 2011, y en la actualidad, esta tecnología está presente en un gran número de servicios de OVH: email, web hosting, VPS Classic, NAS-HA, Dedicated Cloud, Backup Storage, etc. «En aquel momento, la tecnología ya había madurado, y la experiencia que adquirimos nos permitió competir de manera eficaz con sistemas de almacenamiento patentados»... y es esta experiencia adquirida en OpenZFS, la que compartieron François y Alexandre en San Francisco. «Nuestra presentación técnica se refirió fundamentalmente a la migración de datos en OpenZFS. Nuestra actividad como proveedores de alojamiento web nos conduce a asignar y denegar continuamente espacios de almacenamiento (zpools), lo cual ocasiona problemas de fragmentación, razón por la cual debemos efectuar la migración de datos con regularidad. Desafortunadamente, debido a restricciones asociadas al uso de NFS en nuestras infraestructuras, OpenZFS no ofrece la posibilidad de realizar estas operaciones de migración sin downtime.» "Zmotion ", un parche creado por Alexandre, fue revisado en un taller comunitario donde estuvo presente Matt Ahrens, co-fundador del proyecto ZFS. Esta propuesta de desarrollo de software ya está disponible en Github. «Pensamos que nuestra propuesta interesará a las grandes empresas, ya que la problemática de la migración de datos es tema recurrente de discusión en la mailing list de la comunidad», explica Alexandre.

Ver la presentación de OVH “Live Migration with Zmotion”:

La presentación de SlideShare también está disponible en:
slideshare.net/ovhcom/live-migration-of-openzfs-datasets-with-zmotion

Nueve contribuciones que mejorarán OpenZFS

«De manera general, las presentaciones de los distintos contribuyentes contaban con un alto nivel técnico, -relatan François y Alexandre- Cada una de ellas prometía un progreso fantástico para OpenZFS, con beneficios a corto, mediano y largo plazos para los usuarios de esta tecnología.»

A continuación ofrecemos las nueve contribuciones que harán de OpenZFS una tecnología más potente:

1- Compressed ARC (Adaptive Replacement Cache)
OpenZFS funciona con un sistema de caché de dos niveles (ARC y L2ARC), en el cual se almacenan los datos de uso más frecuente. La caché de nivel 1 extrae los recursos desde la RAM, mientras que la caché de nivel 2 se aloja en los discos (generalmente SSD). La contribución de George Wilson, de la compañía Delphix, persigue el objetivo de posibilitar la compresión y descompresión (sobre la marcha) de los archivos presentes en la caché de nivel 1, en la RAM. Un archivo .txt ocuparía tres veces menos espacio, por ejemplo, y como resultado, aumentaría el rendimiento de la caché sin necesidad de adicionar hardware. Disponibilidad en OpenZFS: corto plazo.

2 - Discontiguous caching with ABD
ARC, el sistema de caché propio de OpenZFS, tiene un funcionamiento redundante con la caché de los sistemas operativos, como la caché Page en Linux, por ejemplo. Esto significa que un archivo está doblemente en caché: una vez en la de OpenZFS y una vez en la del sistema operativo. Sin embargo, esto resulta en la pérdida de espacio en la RAM. La contribución de David Chen, de la compañía OSNexus, visualiza la oportunidad de explotar los mecanismos de caché estándar de los sistemas operativos. Disponibilidad en OpenZFS: mediano plazo.

3 - Persistent L2ARC
El mecanismo de caché de nivel 2 de OpenZFS es particularmente sofisticado. La opción de almacenar datos en la caché (generalmente en discos SSD, ya que la producción se aloja en discos más lentos), es el fruto del trabajo competitivo de dos algoritmos, que determinan, conjuntamente y en tiempo real, la mejor estrategia de conservación de datos en función de las solicitudes existentes. No obstante, este mecanismo tiene un punto débil: en caso de reinicio, se debe reconstruir la caché. Esta operación puede tardar hasta 24 horas para la caché del alojamiento compartido de OVH, antes de alcanzar el rendimiento óptimo. La contribución de Saso Kiselkov, de la compañía Nexenta, permite conservar el rendimiento de la caché en caliente, incluso después del reinicio, mediante la modificación del formato. Disponibilidad en OpenZFS: corto plazo en Illumos.

4 - Writeback cache
La idea de contribución de Alex Aizman, de la compañía Nexenta, consiste en implementar un mecanismo de caché de escritura, diferente a los discos dedicados a los lobs. En caso de burst de entrada, por ejemplo, los datos se escriben en un disco SSD o en una tarjeta PCI, y posteriormente se transfieren de manera asincrónica en el pool de discos. Disponibilidad en OpenZFS: desconocida.

5 - Compressed Send and Receive
La contribución de Dan Kimmel, de la compañía Delphix, consiste en enviar directamente el flujo de datos comprimidos durante el backup o la migración, lo cual permite eliminar la etapa de descompresión durante el envío o de recompresión durante la recepción. Como resultado, se reducen el consumo de ancho de banda, el tiempo de backup y la carga de CPU durante el mismo. Disponibilidad en OpenZFS: corto a mediano plazo.

6 - Resumable ZFS send/receive
La contribución de Matthew Ahrens, de la compañía Delphix, fue presentada en París hace seis meses durante la OpenZFS European Conference. Esta solución posibilita la reanudación del backup (mediante un token), en caso de fallo en la red durante la transferencia de archivos. En la actualidad, cuando se interrumpe el backup, es reiniciado "de cero".
La contribución de Matthew Ahrens ya está disponible en Illumos y FreeBSD, y próximamente en Linux.

7 - Parity Declustered RAID-Z/Mirror
La contribución de Isaac Huang, de la compañía Intel, se basa en investigaciones de matemática aplicada para lograr una más rápida reconstrucción de un RAIDZ (RAID de OpenZFS), en caso de pérdida de un disco. Actualmente, con el aumento de la capacidad de la infraestructura, actualizar la duplicación de un RAID puede tardar varios días, y también puede suceder que un segundo disco de RAID falle antes de completar la reconstrucción del primero. Esta situación presupone un riesgo importante de pérdida de datos. En este sentido, la optimización de la distribución de los bloques de datos en los discos (a nivel de I+D) permitiría reducir significativamente el tiempo de reconstrucción de un RAID.

8 - Dedup Ceiling
La duplicación de datos existe desde hace tiempo en OpenZFS. En realidad se usa con poca frecuencia debido al riesgo que presupone la manipulación de grandes cantidades de archivos. La tabla de equivalencias se almacena en la RAM, y, cuando el volumen de esta última se incrementa, lo mismo sucede con el tiempo de respuesta del sistema de desduplicación de archivos.
La contribución de Saso Kiselkov, de la compañía Nexenta, visualiza el almacenamiento de la tabla de equivalencias en un disco dedicado, así como la posibilidad de predefinir el tamaño máximo. Así la duplicación de archivos se haría más utilizable.
Esta solución causaría un impacto positivo importante en el alojamiento web de OVH. Por ejemplo: los archivos que componen WordPress son replicados millones de veces, y la desduplicación se podría traducir en un gran ahorro de espacio. Disponibilidad en OpenZFS: mediano plazo.

9 - SPA Metadata Allocation Classes
La contribución de Don Brady, de la compañía Intel, constituye una oportunidad para recordar que el alma de OpenStack es el almacenamiento de objetos, utilizable a modo de sistema de archivos basado en los metadatos de objetos dispuestos en forma de árbol. Algunos de estos objetos almacenados son archivos, mientras que otros son metadatos (UNIX, ACL, etc). Y estos objetos se mezclan de manera indiscriminada en el pool ZFS. Don Brady propone una solución que permite la organización de objetos teniendo en cuenta la naturaleza de los mismos, y, por ejemplo, la asignación de metadatos a discos SSD, con el fin de aumentar el rendimiento del pool. Por otra parte Don Brady sugiere la asociación de recursos (SATA, SSD, MVNe, disks, etc). Disponibilidad en OpenZFS: desconocida.

Una mirada de cerca al sistema de caché de OpenZFS (ARC)

por Rémy Vandepoel, arquitecto de sistemas de OVH

ZFS y OpenZFS utilizan dos algoritmos diferentes para ubicar -o no- un objeto o un archivo en la ARC (la caché de almacenamiento en la RAM). Estos algoritmos, MRU y MFU (del inglés Most Recently Used y Most Frequently Used, respectivamente) garantizan la optimización del tiempo de respuesta para los objetos más recientemente utilizados y más solicitados, para lo cual se "apropian" de casi toda la RAM disponible en el servidor. Esto aumenta el rendimiento, ya que la coordinación del sistema es circunstancial, en dependencia de las necesidades de cada situación.
Existen estadísticas disponibles sobre el uso de la función kstat, en específico de las variables zfs::arcstats:hits y zfs::arcstats:misses, que permiten el acceso al contenido en la caché.

# kstat -p zfs:0:arcstats:hits zfs:0:arcstats:misses
zfs:0:arcstats:hits 51250034196
zfs:0:arcstats:misses 5983583701

Aquí tenemos, por ejemplo, un éxito aproximado del 89%.
p.ej.: Solo se accede al 11% de los archivos en el disco, y no a través de la caché en la RAM.

kstat -p zfs:0:arcstats:mfu_hits zfs:0:arcstats:mru_hits
zfs:0:arcstats:mfu_hits 28694504638
zfs:0:arcstats:mru_hits 11647492315

Todas las estadísticas están disponibles mediante ‘kstat -pn arcstats’.

Mi cuenta de clienteContact SalesWebmail OVHcloud Blog

¡Bienvenido/a a OVHcloud!

Identifíquese para contratar una solución, gestionar sus productos y servicios, y consultar sus pedidos

Conectar