OVH | ACTUALIDAD, INNOVACIÓN Y TENDENCIAS IT


Descubrir, entender y anticiparse









30/11/2017
Compartir

Artículo redactado por ...


OpenZFS: ¿por qué esta tecnología de almacenamiento de Open Source continúa seduciendo?


Durante los días 24 y 25 del pasado mes de octubre, tuvo lugar la 5ta edición del OpenZFS Developer Summit en San Francisco, la cual contó con el apoyo de OVH. OpenZFS, que actualmente celebra sus doce años, es una tecnología que explotamos a gran escala desde 2011, para el almacenamiento de datos y el alojamiento en internet de soluciones de correo electrónico, VPS, NAS HA, Private Cloud e incluso Backup Storage. François Lesage y Alexandre Lecuyer, ambos ingenieros especializados en soluciones de almacenamiento en OVH, se desplazaron hacia California para un intercambio con la comunidad OpenZFS, sobre el futuro de esta tecnología.





Durante los días 24 y 25 del pasado mes de octubre, tuvo lugar la 5ta edición del OpenZFS Developer Summit en San Francisco, la cual contó con el apoyo de OVH.



Filesystem vs Object Storage: ¿por qué necesitamos los dos?


En un momento en el que el Object Storage parece ser la respuesta de todo, resulta sorprendente constatar la vitalidad de la comunidad que se activa alrededor de la tecnología OpenZFS, y que continúa, año tras año, ampliando sus funcionalidades. A primera vista, el Object Storage lo tiene todo: como infraestructura distribuida, tiene gran disponibilidad, y es altamente escalable, además de económica, ya que se basa en hardware estándar (servidores dotados de una arquitectura x86 y discos duros tradicionales). La fuerza del sistema radica, más que en el rendimiento o la capacidad unitaria de cada elemento del conjunto, en el gran número de máquinas que lo integran, además de la posibilidad de eliminar los efectos negativos del aumento inflexible de almacenamiento con discos de gran capacidad, lo cual reduce significativamente la rentabilidad al elevar los costos.



No obstante, debido al uso masivo del sharding (distribución de archivos -o de distintos bloques o segmentos de un mismo archivo- entre varios nodos del cluster), el Object Storage ofrece latencias que no se igualan con las de un filesystem tradicional, alojado localmente o en un NAS. De igual manera, el Object Storage no es conveniente para ciertos usos, tales como los sistemas de gestión de bases de datos (SGBD), constantemente requeridos para operaciones de lectura/escritura, y es por esta razón que infraestructuras basadas totalmente en el Public Cloud utilizan para sus bases de datos, ya sea el almacenamiento local de las máquinas virtuales o un block storage, o un servicio de Database as a Service.



Por el contrario, el Object Storage conviene perfectamente para el almacenamiento de archivos de gran volumen, como imágenes o videos, por ejemplo. En este sentido, la latencia se ve compensada por la gran velocidad de descarga, propia del diseño distribuido del Object Storage, ya que se recurre al uso de varias máquinas en paralelo para servir el archivo. Por otra parte, un sistema de caché se puede colocar en sentido ascendente para servir instantáneamente los archivos solicitados con mayor frecuencia.



Concluyendo: si es posible codificar un sistema virtual de archivos (filesystem) por encima de una solución de Object Storage (lo cual sucede muy a menudo, debido a la gran cantidad de aplicaciones diseñadas para operar con un sistema de archivos), la tecnología OpenZFS ofrece funcionalidades que el Object Storage no garantiza, como contrapartida de su sencillez.



Asimismo, la reputación de OpenZFS está respaldada por aplicaciones avanzadas como la replicación, la deduplicación, la compresión, la posibilidad de crear clones (snapshots del sistema, modificables), el intercambio de datos entre distintos sistemas, el bloqueo de los datos ante un cluster cuyos componentes deben sincronizarse en tiempo real, e incluso la protección y la corrección de datos, con un sistema de verificación de la integridad capaz de bloquear la corrupción silenciosa de los archivos. Y a todo esto le agregamos un alto rendimiento y una estabilidad inigualable para operaciones a gran escala, como las de OVH. Para algunos, el acrónimo ZFS significa "Zettabyte File System", una unidad de medida que parecía absurda en los años 2000... y que pronto será muy común para operadores como OVH (tres letras a las que se atribuyen varios significados, que por ahora no vamos a revelar).



OpenZFS: de las infraestructuras in-situ de las empresas al cloud


Hace algunos años, las empresas recurrían casi exclusivamente a soluciones de almacenamiento con hardware y software propietarios, sistemas potentes y robustos, con la ventaja indiscutible de tranquilizar a los usuarios y a sus superiores en cuanto a la durabilidad de los datos, a pesar de sus precios elevados. Hoy las cosas han cambiado. Compañías como Facebook operan la tecnología OpenZFS y contribuyen al mejoramiento de los algoritmos de compresión, e incluso sectores como el de seguros, la banca y la industria cinematográfica han desplegado infraestructuras de almacenamiento basadas en esta tecnología. Por una parte, esto reduce considerablemente los costos, en un contexto donde la producción de datos se dispara vertiginosamente. Por otra parte, los sistemas propietarios constituyen verdaderas cajas negras, ya que para los usuarios es imposible saber cómo funciona el código o modificarlo ellos mismos. No obstante, el almacenamiento se ha convertido en un conjunto de infraestructuras que deben ser adaptadas en función de estrategias y necesidades específicas. El éxito de OpenZFS también radica en el hecho de estar integrado por defecto a Ubuntu a partir de la versión 16.04, lanzada en 2016.



Cada vez más son las empresas que reemplazan sus racks de almacenamiento propietarios por plataformas in-situ de OpenZFS. El próximo paso es, sin duda alguna, desplazar la totalidad o parte de este almacenamiento al cloud, con un proveedor como OVH, que ofrece la solución as a service NAS-HA OpenZFS.

Cada vez más son las empresas que reemplazan sus racks de almacenamiento propietarios por plataformas en OpenZFS



ZFS y OpenZFS... ¿camino a la reconciliación?


El OpenZFS Developer Summit fue escenario de un inesperado anuncio de Mark Maybee, arquitecto principal de la tecnología ZFS de Oracle. El mismo declaró su intención de unificar la tecnología de almacenamiento ZFS -cuyo código había sido cerrado por Oracle poco después de adquirirlo de Sun en el año 2009-, con OpenZFS, todo con el objetivo de desarrollar y sostener la tecnología, haciendo de ZFS un componente upstream de Linux, y, por tanto, la base de los sistemas de almacenamiento, ya sean o no de objetos.



Desafortunadamente, este proyecto ha quedado en el aire con el reciente despido de Mark Maybee, según publicó Bryan Cantrill en su cuenta de Twitter.



El OpenZFS Developer Summit reveló que actualmente algunas empresas desarrollan servicios propietarios basados en OpenZFS, asumiendo el riesgo de bifurcación ("fork"), pero cabe destacar que también constituyó una buena ocasión para descubrir mejoras significativas de esta tecnología, ... y de imaginar, con cierta impaciencia, cómo podría OVH aplicar tales innovaciones, un ejercicio para el que ya estábamos listos desde el OpenZFS Developer Summit de 2015, en el que presentamos un parche para la migración de datos sin downtime.



Resumen de los principales anuncios del OpenZFS Developer Summit 2017


El OpenZFS Developer Summit fue una buena ocasión para descubrir mejoras significativas de esta tecnología, e imaginar cómo podría OVH aplicar estas innovaciones.



Mejoras en la seguridad


MMP: Safe "zpool import" for Clusters



Mayor seguridad para evitar la importación de un mismo pool en dos máquinas, que podría ocasionar la ruptura del pool.



Posible aplicación en OVH: asegurar el cambio de un datastore al otro en caso de fallo de hardware (en la solución Private Cloud). Esta puede ser una alternativa en caso de que la interrupción de las conexiones SAS no sea posible desde el punto de vista de hardware.



DRAID: una alternativa al RAIDZ



Intel ofrece una alternativa al RAID-Z (el dispositivo de RAID nativo de OpenZFS), que tiene como ventaja principal la de aumentar considerablemente la velocidad de reconstrucción de un pool luego de la avería de uno o más discos. La limitación de esta alternativa viene dada porque el DRAID utiliza más espacio (se emplea el padding para hacer llegar los datos y la paridad siempre a los mismos discos). Este es un gran proyecto que será lanzado muy pronto.



Posible aplicación en OVH: sin dudas un proyecto muy interesante tanto para los pools de backup como para los sitios mirror de OVH (ver recuadro al final de este artículo). La idea es que, al reescribir un disco más rápidamente, disminuye el tiempo de riesgo potencial. Este parche ya está disponible en la wiki del proyecto.



Mejoras en la velocidad de reescritura de un disco (resilver)



Reescritura más rápida de un disco luego de un reemplazo, debido a la generación de IO secuenciales en lugar de aleatorias. Se genera una cola de escrituras necesarias, la cual se clasifica por emplazamiento en el disco (offset). De esta manera, los encabezamientos de solo lectura se mueven menos en las operaciones de escritura, por lo que la reescritura del disco se acelera, y se alcanza la redundancia más rápidamente. La fecha de publicación de este parche aún no se ha anunciado.



Storage pool checkpoint



Permite establecer un punto de control en un pool entero, incluyendo sus propiedades.



Posible aplicación en OVH: mejoras en la seguridad antes de llevar a cabo una operación de riesgo para el pool, con la posibilidad de un "rollback" escalado en caso de fallos durante la migración.



Mejoras en el rendimiento


ZStandard compression



OpenZFS ofrece una amplia gama de algoritmos para la compresión de los archivos almacenados, que permite a su vez la liberación de hasta un 80% del espacio, en dependencia del tipo de archivo. ScaleEngine, en colaboración con Facebook, ha desarrollado un nuevo algoritmo de compresión, rápido como LZ4 y eficiente como gzip.



Posible aplicación en OVH: optimización de los pools de backup, como contrapartida del sobreconsumo de CPU.



Fast Clone Deletion



Aceleración de la eliminación de clones (snapshots modificables) mediante la creación de una lista de bloques utilizados por un clon, para no tener que recorrerlos todos.



Posible aplicación en OVH: clonar las máquinas virtuales del Private Cloud (con OpenZFS como tecnología utilizada por los datastores) con integración VAAI.



Faster allocation with the log spacemap



Si ZFS debe asignar o denegar espacio en un disco, esto genera IO: a cada zona del disco le corresponde un space map. Si las operaciones de lectura/escritura se realizan en varias zonas del disco, se generan IO aleatorias.



La idea es guardar la información en la RAM, y escribir un log único para todos los space maps, que sirva solo para la recuperación en caso de fallos. La actualización de los space maps en el disco se lleva a cabo de la siguiente manera: se actualiza un space map en cada transaction group (TXG).



Posible aplicación en OVH: mejoras en el rendimiento, específicamente con la eliminación masiva de datos. Este parche aún no está disponible. Probablemente lo estará en 2018.



iFlash: Dynamic adaptive L2ARC caching



En una plataforma OpenZFS es posible utilizar un disco SSD para la caché y la aceleración de operaciones de IO. La limitación viene dada por el hecho de que el tamaño de este espacio de caché, así como el del ZIL (ZFS Intent log, que es la caché para las escrituras síncronas), deben estar previamente definidos para cada uno de los clientes de la plataforma. Un fabricante de sistemas de almacenamiento ha logrado un desarrollo propietario que permite la asignación dinámica de este espacio de caché en la unidad flash.



Este proyecto es, en potencia, muy interesante para OVH, ya que tenemos el mismo caso de uso en NAS, pero se trata de un desarrollo propietario basado en una versión de ZFS de 2013.



ZIL Performance



En la actualidad, cuando una aplicación realiza un fsync(), deben escribirse 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 aún no ha finalizado, pero deberá estar listo en upstream en 2018.



Posible aplicación en OVH: mejoramiento del rendimiento de una gran carga de trabajo, específicamente en el Private Cloud, cuya arquitectura con dos datastores redundantes requiere un gran número de escrituras síncronas.



Mejoras operativas


"Oh Shift!": cambiar el tamaño de la asignación



Hoy en día resulta imposible cambiar el tamaño de la asignación (alineamiento del pool) luego de su creación. Esto ocasiona grandes problemas de rendimiento cuando, en un pool creado en 512 bytes, se reemplazan los discos averiados por discos de 4K, que emulan con 512 bytes, a causa de las operaciones de "read-modify-write". Este parche permitirá alinear en caliente las escrituras en un tamaño superior.



Posible aplicación en OVH: ya no estaremos limitados a velar por el tamaño de la asignación de los discos durante el reemplazo, lo cual evitará los problemas de rendimiento.



RAID-Z expansion



Posibilidad de añadir discos a un vdev RAID-Z. Aunque no parezca, este es un gran avance, ya que, hasta el momento, añadir un disco a un pool ya existente, no era una operación sencilla. Este proyecto es un pequeño paso hacia el aumento de la escalabilidad.



Posible aplicación en OVH: limitada, pues nosotros añadimos algunos discos a posteriori.



Mil veces más rápido que la deduplicación



Este proyecto consiste en cambiar el formato en disco de la tabla de deduplicación para limitar en gran número las operaciones de lectura/escritura generadas por la deduplicación. Un log reemplaza la tabla hash. El árbol se construye en RAM a partir del log en disco, al importar el pool. Si esta operación no se realiza en RAM, la deduplicación se desactiva para los nuevos bloques.



Interés para OVH: Debemos admitir que la deduplicación (optimización de los archivos duplicados en una infraestructura) no se puede utilizar actualmente, ya que es muy riesgosa e inestable en nuestra escala. Si este proyecto fructifica, se podría visualizar la realización de pruebas, pero para estas se necesitarían máquinas bien dotadas de RAM.



Open ZFS en OS X y Windows 10:



Un desarrollador ha utilizado el código de OpenZFS en Mac OSX... ¡y en Windows 10! Un proyecto magnífico sin dudas, pero que por el momento no tiene aplicación posible en OVH... 🙂



Los sitios "mirror" de OVH: un uso típico del OpenZFS para el almacenamiento masivo


Desde hace mucho tiempo, OVH aloja sus propios sitios "mirror", desde los cuales se pueden descargar distribuciones de open source, tales como Debian, Ubuntu o incluso Postfix, OpenCSW... (existen alrededor de cien sitios "mirror" en total). El mantenimiento de los sitios es una manera de contribuir con las distintas comunidades. Las alternativas al sitio de descarga principal, alivia los servidores de la comunidad y aligera las necesidades en materia de recursos y ancho de banda. Y es también desde estos sitios "mirror" que se descargan las distribuciones y paquetes cuando los usuarios de servicios de OVH solicitan la preinstalación de los mismos en sus máquinas.



Para ello, almacenamos más de 40 TB en OpenZFS, con triple replicación (que nos garantiza copias con una proximidad geográfica a nuestros centros de datos, además de la descarga rápida). En esta plataforma de almacenamiento, el uso intensivo de snapshots hace posible la disposición de las imágenes conocidas y probadas, a la vez que ofrece los últimos lanzamientos en tiempo real.