El culto a ZFS

Es bastante común que en los círculos de TI se desarrolle cierta mentalidad sectaria o de “fanático”. No estoy del todo seguro de qué provoca esta reacción ante las tecnologías y los productos, pero es innegable que ocurre. Un área en la que nunca pensé que vería que esto sucediera es la de los sistemas de archivos – uno de los componentes del sistema más “internos” y uno que, hasta hace poco, no recibía literalmente ninguna atención ni siquiera en círculos razonablemente técnicos. Seamos sinceros: confundir cuándo algo proviene de Active Directory frente a cuándo proviene de NTFS es algo casi omnipresente. Los sistemas de archivos, sencillamente, se ignoran. Desde que se lanzó Windows NT 4 y NTFS era la única opción viable, la idea de que un sistema de archivos no es un componente intrínseco de un sistema operativo y de que podría haber otras opciones para el almacenamiento de archivos prácticamente ha desaparecido. Es decir, hasta hace poco.

La única comunidad donde, en cierto pequeño grado, esto no sucedió fue la comunidad de Linux, pero incluso allí Ext2 y sus descendientes acapararon de forma tan completa la mentalidad colectiva que, aunque estaban ampliamente disponibles, los sistemas de archivos alternativos quedaron relegados y solo XFS recibió algo de atención, históricamente, e incluso este recibió muy poca.

Donde se ha producido un comportamiento verdaderamente extraño, más recientemente, es en torno al sistema de archivos ZFS de Oracle, desarrollado originalmente para el sistema operativo Solaris y para la plataforma de almacenamiento abierto X4500 “Thumper” (originalmente bajo el amparo de Sun, antes de la adquisición por parte de Oracle). En la época (hace nueve años) en que se lanzó ZFS, los sistemas de archivos de la competencia estaban en su mayoría mal preparados para manejar los grandes arreglos de discos que se esperaba construir en los años venideros. ZFS fue diseñado para manejarlos y marcó el inicio de la era de los sistemas de archivos a gran escala. Como la mayoría de los sistemas de archivos de aquel momento, ZFS estaba limitado a un único sistema operativo y, por ello, aunque se consideraba ampliamente un gran salto adelante en el diseño de sistemas de archivos, generó pocas ondas en el mundo del almacenamiento y aún menos en el mundo de los “sistemas”, donde incluso los administradores de Solaris lo consideraron por lo general, durante bastante tiempo, un mero punto de interés, optando en su mayoría por seguir con el probado y fiable UFS que llevaban muchos años utilizando.

ZFS fue, verdaderamente, un sistema de archivos revolucionario y yo fui, y sigo siendo, un gran defensor de él. Pero es muy importante comprender por qué ZFS hizo lo que hizo, cuáles son sus objetivos, por qué esos objetivos eran importantes y cómo se aplica esto a nosotros hoy. La complejidad de ZFS ha generado mucha confusión y malentendidos acerca de cómo funciona el sistema de archivos y cuándo es apropiado utilizarlo.

Los principales objetivos de ZFS eran crear un sistema de archivos capaz de escalar bien hacia arreglos de discos muy grandes. En el momento de su introducción, la escala que ZFS era capaz de manejar resultaba inaudita en otros sistemas de archivos, pero no existía una necesidad real de que un sistema de archivos pudiera crecer hasta ese tamaño. Para cuando surgió la necesidad, muchos otros sistemas de archivos como NTFS, XFS, Ext3 y otros ya habían escalado para satisfacer la demanda. ZFS sin duda lideró la marcha hacia la gestión de sistemas de archivos más grandes, pero se le sumaron muchos otros poco después.

Como ZFS se originó en el mundo de Solaris donde, como en todos los grandes sistemas UNIX de gran potencia, no existe RAID por hardware, hubo que utilizar RAID por software. Solaris siempre había tenido disponible el RAID por software como su propio subsistema. Se tomó la decisión de integrar una nueva implementación de RAID por software directamente en ZFS. Esto permitiría una administración simplificada mediante un único conjunto de herramientas tanto para la capa de RAID como para el sistema de archivos. No introdujo ningún cambio ni ventaja significativos en ZFS, como a menudo se cree; simplemente trasladó la interfaz de la capa de RAID por software de ser su propio conjunto de comandos a formar parte del conjunto de comandos de ZFS.

La implementación de RAID de ZFS introdujo los stripes de ancho variable en los niveles de RAID con paridad. Esta innovación cerró un riesgo menor del RAID con paridad conocido como el “agujero de escritura” (write hole). Esta innovación fue muy buena, pero llegó muy tarde, ya que la era del RAID con paridad fiable empezaba a llegar a su fin y el problema del agujero de escritura ya se consideraba un riesgo de “ruido de fondo” no mencionado de los arreglos con paridad, pues por lo general no se consideraba una amenaza debido a su eliminación mediante el uso de cachés de arreglo respaldados por batería y, casi al mismo tiempo, de cachés de arreglo no volátiles – evita la pérdida de energía y evitarás el agujero de escritura. ZFS necesitaba abordar este problema porque, al ser RAID por software, estaba más expuesto al agujero de escritura que el RAID por hardware, ya que no existe la posibilidad de una caché protegida contra la pérdida de energía – el RAID por hardware ofrece la posibilidad de una capa adicional de protección energética para los arreglos.

La verdadera “innovación” que ZFS hizo de forma inadvertida fue que, en lugar de simplemente implementar los niveles de RAID habituales 1, 5, 6 y 10, optó por “marcar” esos niveles con sus propias convenciones de nomenclatura. RAID 5 se conoce como RAIDZ. RAID 6 se conoce como RAIDZ2. RAID 1 simplemente se conoce como espejado (mirroring). Y así sucesivamente. En su momento esto se consideró ampliamente una tontería e innecesariamente confuso pero, según resultó, esa confusión se convirtió en la piedra angular del resurgimiento de ZFS muchos años después.

Cabe señalar que ZFS añadió posteriormente la primera implementación en producción del sector de un sistema RAID 7 (también conocido como RAID 7.3) de triple paridad y lo marcó como RAIDZ3. Esta incorporación posterior es una innovación importante para los arreglos a gran escala que necesitan la máxima capacidad manteniéndose a la vez extremadamente seguros, pero que están dispuestos a sacrificar rendimiento para lograrlo. Esta sigue siendo una funcionalidad exclusiva de ZFS, aunque rara vez se utiliza.

Con el espíritu de colapsar la pila de almacenamiento y utilizar un único conjunto de comandos para administrar todos los aspectos del almacenamiento, las funciones de gestión de volúmenes lógicos también se integraron en ZFS. A menudo se cree erróneamente, en ciertos círculos, que ZFS introdujo la gestión de volúmenes lógicos, pero casi todas las plataformas empresariales, incluidas AIX, Linux, Windows e incluso el propio Solaris, ya contaban con gestión de volúmenes lógicos desde hacía muchos años. ZFS no hacía esto para introducir un nuevo paradigma, sino simplemente para consolidar la administración y envolver las tres capas clave del almacenamiento (RAID, gestión de volúmenes lógicos y sistema de archivos) en una única entidad que fuera más fácil de administrar y que pudiera proporcionar comunicaciones inherentes a lo largo de toda la pila. Este método tiene sus pros y sus contras, y la opinión del sector sigue sin formarse casi una década después.

Uno de los aspectos más importantes de esta consolidación de tres sistemas en uno es que ahora tenemos un producto muy confuso del que hablar. ZFS es un sistema de archivos, sí, pero no es solo un sistema de archivos. Es un gestor de volúmenes lógicos, pero no solo un gestor de volúmenes lógicos. La gente se refiere a ZFS como un sistema de archivos, que es su función principal, pero el hecho de que sea mucho más que un sistema de archivos puede resultar muy confuso y dificulta las comparaciones frente a otros sistemas de almacenamiento. En su momento, creo que esta confusión no se previó.

Lo que ha resultado de esta confusa fusión es que a ZFS a menudo se le compara con otros sistemas de archivos, como XFS o Ext4. Pero esto es confuso, ya que ZFS es una pila completa y XFS es solo un aspecto de una pila. ZFS se compararía mejor con MD (RAID por software de Linux) / LVM / XFS o con SmartArray (RAID por hardware de HP) / LVM / XFS que con XFS por sí solo. De lo contrario, parece que ZFS está repleto de funcionalidades de las que XFS carece pero, en realidad, no es más que una victoria semántica. La mayoría de las funcionalidades que suelen pregonar los defensores de ZFS no se originaron con ZFS y estaban comúnmente disponibles en los sistemas de archivos alternativos mucho antes de que ZFS existiera. Pero es difícil comparar “¿hace eso tu sistema de archivos?” porque la respuesta es “no…. eso lo hace mi RAID o mi gestor de volúmenes lógicos.” Y, en realidad, no es ZFS el sistema de archivos el que proporciona RAIDZ, es ZFS el subsistema de RAID por software el que lo hace.

Para manejar con elegancia sistemas de archivos muy grandes, se incorporaron a ZFS funcionalidades de integridad de datos que incluían una comprobación de suma de verificación (checksum) o de hash a lo largo de todo el sistema de archivos, que podía aprovechar el RAID por software incluido para reparar archivos corruptos. Esto se consideró necesario debido al tamaño previsto de los sistemas de archivos ZFS en el futuro. La corrupción del sistema de archivos es un fenómeno que se ve rara vez, pero, a medida que los sistemas de archivos crecen en tamaño, el riesgo aumenta. Esta funcionalidad menos conocida de ZFS es posiblemente la mejor que tiene.

ZFS también cambió la forma en que se gestionan las comprobaciones del sistema de archivos. Debido a la suposición de que ZFS se utilizaría en sistemas de archivos muy grandes, existía un temor genuino de que una comprobación del sistema de archivos en el momento del arranque pudiera tardar un tiempo imposiblemente largo en completarse, por lo que se encontró una estrategia alternativa. En lugar de esperar a realizar una comprobación en el reinicio, el sistema requeriría que se ejecutara un proceso de depuración (scrubbing) que realizara una comprobación similar mientras el sistema estaba en funcionamiento. Esto requiere una mayor sobrecarga del sistema mientras este está activo, pero el sistema es capaz de recuperarse de un reinicio inesperado con mayor rapidez. Una concesión, pero una que se considera ampliamente muy positiva.

ZFS tiene potentes capacidades de instantáneas (snapshots) en su capa de volúmenes lógicos y, en su capa de RAID, ha implementado mecanismos de caché muy robustos, lo que convierte a ZFS en una excelente opción para muchos casos de uso. Estas funcionalidades no son exclusivas de ZFS, sino que están ampliamente disponibles en sistemas más antiguos que ZFS. Son, sin embargo, muy buenas implementaciones de cada una y están muy bien integradas debido a la naturaleza de ZFS.

En su momento, ZFS fue de código abierto y, durante esa época, su código pasó a formar parte de los sistemas operativos Mac OSX de Apple y FreeBSD porque eran compatibles con la licencia de ZFS. Linux no obtuvo ZFS en aquel momento debido a desafíos relacionados con las licencias. Si la licencia de ZFS hubiera permitido a Linux usarlo sin restricciones, el panorama de Linux probablemente sería muy diferente hoy. Mac OSX acabó abandonando ZFS, ya que no se consideró que tuviera suficientes ventajas para justificarlo en ese entorno. FreeBSD se aferró a ZFS y, con el tiempo, se convirtió en el sistema de archivos más popular de la plataforma, aunque UFS también se sigue utilizando mucho. Oracle cerró el código fuente de ZFS tras la adquisición de Sun, dejando a FreeBSD sin actualizaciones continuas para su versión de ZFS, mientras Oracle siguió desarrollando ZFS internamente para Solaris.

Hoy en día, Solaris sigue utilizando la implementación original de ZFS, ahora con varias actualizaciones desde su separación de la comunidad de código abierto. FreeBSD y otros continuaron usando ZFS en el estado en que se encontraba cuando se cerró el código, sin tener ya acceso a las últimas actualizaciones de Oracle. Con el tiempo se emprendió el trabajo de actualizar la base de código de ZFS de código abierto que había quedado abandonada, y ahora se conoce como OpenZFS. OpenZFS todavía está en sus inicios y aún no ha dejado realmente su huella, pero tiene cierto potencial para revitalizar la plataforma ZFS en el espacio del código abierto aunque, por ahora, OpenZFS todavía va por detrás de ZFS.

El desarrollo de código abierto en este espacio durante los últimos años se ha centrado más en el nuevo rival de ZFS, BtrFS, que se está desarrollando de forma nativa en Linux y cuenta con un buen soporte por parte de muchos de los principales fabricantes de sistemas operativos. BtrFS es muy incipiente, pero está dando grandes pasos para alcanzar la paridad de funcionalidades con ZFS en cuanto a funcionalidades implementadas, aunque tiene grandes aspiraciones y, debido a la naturaleza de código cerrado de ZFS, cuenta con la ventaja del impulso del mercado. BtrFS fue iniciado, al igual que ZFS, por Oracle y se ha considerado ampliamente como la visión de futuro de Oracle, siendo un reemplazo de ZFS incluso dentro de la propia Oracle. En este momento BtrFS ya ha, al igual que ZFS, fusionado las capas de sistema de archivos, gestión de volúmenes lógicos y RAID por software, implementado sumas de verificación para la integridad del sistema de archivos, escala incluso más que ZFS (mismo límite absoluto pero maneja más archivos), instantáneas con copia sobre escritura (copy on write), etc.

ZFS, sin duda alguna, fue un sistema de archivos asombroso en su apogeo y sigue siendo un líder hoy. Yo fui un defensor de él en 2005 y sigo creyendo firmemente en él. Pero me ha entristecido ver que la comunidad en torno a ZFS adopta un fervor y un fanatismo que no le hacen ningún favor y que hacen que la mención de ZFS casi parezca algo negativo – ZFS es elegido de forma tan universal por las razones equivocadas: principalmente la creencia de que sus funcionalidades no existen en ningún otro lugar, de que su RAID no está sujeto a los riesgos y limitaciones a los que esos niveles de RAID están siempre sujetos, o de que fue diseñado con un propósito diferente (principalmente el rendimiento) al que en realidad tenía. Y cuando ZFS es una buena elección, a menudo se implementa de forma deficiente basándose en suposiciones falsas.

ZFS, por supuesto, no tiene la culpa. Tampoco la tienen, por lo que puedo apreciar, ni sus partidarios corporativos ni sus desarrolladores de código abierto. Donde ZFS parece haberse descarriado es en una comunidad informal y no oficial que solo recientemente ha llegado a conocer ZFS, creyendo a menudo que es nuevo o de “próxima generación” porque acaban de descubrirlo. Por lo que he visto, esto casi nunca ocurre a través de los canales de Solaris o FreeBSD, sino casi exclusivamente a través de pequeñas empresas que buscan utilizar un “sistema operativo NAS” empaquetado como FreeNAS o NAS4Free y que no están familiarizadas con los sistemas operativos UNIX. El uso de sistemas operativos NAS empaquetados, principalmente por parte de departamentos de TI que no poseen conocimientos profundos ni de UNIX ni de almacenamiento y, en consecuencia, poca exposición al mundo más amplio de los sistemas de archivos fuera de Windows y, a menudo, poca o ninguna exposición a la gestión de volúmenes lógicos y al RAID, especialmente al RAID por software en absoluto, parece dar lugar a una cultura de “mito” en torno a ZFS, en la que este adopta un estatus casi incuestionable e infalible.

Este seguimiento sectario y el malentendido general de ZFS conducen a menudo a aplicaciones erróneas de ZFS o a una cadena de toma de decisiones basada en malas suposiciones que puede llevarlo a uno muy por el camino equivocado.

Uno de los cambios más asombrosos en este espacio es el cambio de seguimiento desde el RAID por hardware hacia el RAID por software. Tradicionalmente, el RAID por software era un paria en los círculos de administración de Windows sin un buen motivo – los administradores de Windows y las pequeñas empresas, a menudo poco familiarizados con los servidores UNIX más grandes, creían que el RAID por hardware era omnipresente cuando, de hecho, los sistemas a mayor escala siempre usaban RAID por software. El RAID por hardware se consideraba, casi en todo el sector, una necesidad, y el RAID por software se rechazaba por completo. Ese mismo público, ahora frente al movimiento del “Culto a ZFS”, reacciona ahora exactamente de la manera opuesta, creyendo que el RAID por hardware es malo y que el RAID por software de ZFS es la única opción viable. El cambio es drástico y ninguno de los dos enfoques es válido – tanto el RAID por hardware como el RAID por software, y ambos en muchas implementaciones, son opciones muy válidas, e incluso usando ZFS el uso de RAID por hardware podría ser fácilmente apropiado.

ZFS se elige a menudo porque se cree que es la opción de mayor rendimiento entre los sistemas de archivos, pero esto nunca fue un objetivo clave del diseño de ZFS. Las funcionalidades que le permiten escalar tanto y manejar tantos aspectos diferentes del almacenamiento en realidad hacen que ser de alto rendimiento resulte muy difícil. ZFS, en el momento de su creación, ni siquiera se esperaba que fuera tan rápido como el venerable UFS, que se ejecutaba en los mismos sistemas que él. Sin embargo, esto a menudo es secundario frente al hecho de que el rendimiento del sistema de archivos es ampliamente irrelevante, ya que todos los sistemas de archivos modernos son extremadamente rápidos y la velocidad del sistema de archivos rara vez es un factor importante – especialmente fuera de los sistemas de almacenamiento masivos y de gama alta a muy gran escala.

Un interesante estudio de diez sistemas de archivos en Linux elaborado por Phoronix en 2013 mostró diferencias enormes entre los sistemas de archivos según la carga de trabajo, pero ningún ganador claro en cuanto al rendimiento general. Lo que el estudio demostró de forma concluyente es que ajustar la carga de trabajo al sistema de archivos es la elección más importante, que ZFS se sitúa en el lado más lento de todos los sistemas de archivos predominantes, incluso en sus implementaciones más modernas, y que elegir un sistema de archivos por razones de rendimiento sin una comprensión muy profunda de la carga de trabajo dará como resultado un rendimiento impredecible – ningún sistema de archivos debería elegirse a ciegas si el rendimiento es un factor importante. Lamentablemente, dado que la prueba se realizó en Linux, carecía de UFS, que a menudo es el principal competidor de ZFS, especialmente en Solaris y FreeBSD, y carecía de HFS+ de Mac OSX.

Pasar del RAID por hardware al RAID por software conlleva también riesgos adicionales, a menudo imprevistos, para los departamentos sin experiencia en UNIX. Si bien ZFS permite el intercambio en caliente (hot swap), a menudo se olvida que el intercambio en caliente es principalmente una funcionalidad del hardware, no del software, y también es ampliamente desconocido que el intercambio a ciegas (blind swapping, es decir, la extracción de discos duros sin antes desconectarlos lógicamente en el sistema operativo) no es sinónimo de intercambio en caliente, y esto puede provocar desastres para los departamentos que pasan de una tradición de RAID por hardware, que gestionaba la compatibilidad, el intercambio en caliente y el intercambio a ciegas de forma transparente para ellos, a un sistema de RAID por software que requiere mucha más planificación, coordinación y comprensión del sistema para usarse de forma segura.

Un concepto erróneo menor, pero aún común, sobre ZFS es que se trata de un sistema de archivos en clúster apto para su uso en escenarios de DAS compartido o SAN al estilo de OCFS, VxFS y GFS2. ZFS no es un sistema de archivos en clúster y comparte las mismas limitaciones en ese ámbito que todos sus competidores habituales.

ZFS puede ser una excelente opción, pero está lejos de ser la única. ZFS viene acompañado de grandes salvedades, entre las que no es la menor la de las limitaciones de sistema operativo asociadas a él y, aunque tiene muchos beneficios, pocos, si es que alguno, son exclusivos de ZFS y es muy raro que algún departamento se beneficie de todos y cada uno de ellos. Como con cualquier tecnología, hay concesiones que hacer. No existe una talla única que sirva para todos. La clave para saber cuándo ZFS es adecuado para ti es comprender qué es ZFS, qué es y qué no es exclusivo de él, cuáles son sus objetivos de diseño, cómo el comparar un sistema de almacenamiento con un sistema de archivos puro produce resultados engañosos y qué limitaciones inherentes lleva asociadas.

ZFS es una consideración clave y la elección habitual cuando Solaris o FreeBSD es el sistema operativo elegido. Salvo raras excepciones, el sistema operativo nunca debería elegirse por ZFS, sino que más bien ZFS debería elegirse a menudo, aunque no siempre, una vez elegido el sistema operativo. El sistema operativo debería determinar las elecciones de sistema de archivos en todos los casos salvo en los más excepcionales. La elección del sistema operativo es mucho más importante que la elección del sistema de archivos.

ZFS puede usarse en Linux, pero allí no se considera una opción empresarial, sino más bien un sistema de aficionado para la experimentación, ya que ningún fabricante empresarial (como Red Hat, Suse o Canonical) brinda soporte a ZFS en Linux y dado que Linux ya cuenta con excelentes alternativas. Algún día ZFS podría ser promovido a sistema de archivos de primera clase en Linux, pero esto no se espera, ya que BtrFS ya ha entrado en el núcleo principal (mainline kernel) y ha sido incluido en versiones de producción por parte de varios fabricantes importantes.

Si bien ZFS se verá en la inmensa mayoría de los despliegues de Solaris y FreeBSD, esto se debe principalmente a que ha pasado a ocupar la posición de sistema de archivos predeterminado, y no a que sea claramente la opción superior en esos casos ni a que siquiera se haya evaluado de forma crítica. ZFS es perfectamente adecuado como sistema de archivos de propósito general allí donde es nativo y cuenta con soporte.

¿Cuál es el principal caso de uso de ZFS?

El objetivo de diseño y el principal caso de uso de ZFS son los sistemas de almacenamiento abierto de Solaris y FreeBSD que proporcionan, bien almacenamiento compartido a otros servidores, bien repositorios de datos masivos para aplicaciones instaladas localmente. En estos casos, el enfoque de ZFS en la escalabilidad y la integridad de los datos realmente brilla. ZFS se inclina fuertemente hacia los departamentos de gran escala y de nivel empresarial y, por lo general, se aleja de su aplicabilidad en el espacio de la pequeña y mediana empresa, donde las habilidades en Solaris y FreeBSD, así como las necesidades de almacenamiento a gran escala, son poco frecuentes.

Referencia: http://www.phoronix.com/scan.php?page=article&item=linux_310_10fs&num=1