{"id":83582,"date":"2020-06-01T19:42:21","date_gmt":"2020-06-01T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost"},"modified":"2020-06-01T19:42:21","modified_gmt":"2020-06-01T17:42:21","slug":"osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","title":{"rendered":"Fundamentos de ZFS: sistema de almacenamiento y rendimiento","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Fundamentos
\n
\nEsta primavera ya discutimos algunos temas introductorios, como c\u00f3mo verificar la velocidad de sus discos<\/a><\/noindex> y qu\u00e9 es RAID<\/a><\/noindex>. En el segundo de ellos incluso prometimos continuar explorando el rendimiento de varias topolog\u00edas de m\u00faltiples discos en ZFS. Este es un sistema de archivos de pr\u00f3xima generaci\u00f3n que se est\u00e1 implementando en todas partes: desde Apple<\/a><\/noindex> hasta Ubuntu<\/a><\/noindex>.
\n<\/a><\/noindex>
\nBien, hoy es el d\u00eda m\u00e1s adecuado para conocer ZFS, lectores curiosos. Simplemente sepan que, seg\u00fan la modesta estimaci\u00f3n del desarrollador de OpenZFS, Matt Arens, \"realmente es complicado\".<\/p>\n

Pero antes de llegar a los n\u00fameros \u2014y los habr\u00e1, lo prometo\u2014 sobre todas las configuraciones de ocho discos de ZFS, es necesario hablar de c\u00f3mo c\u00f3mo<\/i> ZFS almacena datos en el disco.<\/p>\n

Zpool, vdev y device<\/h1>\n

\n\"Fundamentos
\nEste diagrama de pool completo incluye tres vdevs auxiliares, uno de cada clase, y cuatro para RAIDz2.<\/i><\/p>\n

\"Fundamentos
\nGeneralmente, no hay razones para crear un pool a partir de tipos y tama\u00f1os de vdev no coincidentes \u2014pero si lo desea, nada le impide hacerlo<\/i><\/p>\n

Para entender realmente el sistema de archivos ZFS, es necesario observar de cerca su estructura real. En primer lugar, ZFS combina los niveles tradicionales de gesti\u00f3n de vol\u00famenes y sistemas de archivos. En segundo lugar, utiliza un mecanismo transaccional de copia en escritura. Estas caracter\u00edsticas significan que la estructura del sistema es muy diferente de los sistemas de archivos y arrays RAID convencionales. El primer conjunto de bloques de construcci\u00f3n b\u00e1sicos para entender: es el pool de almacenamiento (zpool), el dispositivo virtual (vdev) y el dispositivo real (device).<\/p>\n

zpool<\/h3>\n

\nEl pool de almacenamiento zpool es la estructura m\u00e1s alta de ZFS. Cada pool contiene uno o m\u00e1s dispositivos virtuales. A su vez, cada uno de ellos contiene uno o m\u00e1s dispositivos reales (device). Los pools virtuales son bloques aut\u00f3nomos. Una computadora f\u00edsica puede contener dos o m\u00e1s pools separados, pero cada uno es completamente independiente de los dem\u00e1s. Los pools no pueden compartir dispositivos virtuales.<\/p>\n

La redundancia de ZFS est\u00e1 a nivel de dispositivos virtuales, no a nivel de pools. A nivel de pools no hay absolutamente ninguna redundancia \u2014si se pierde alg\u00fan almacenamiento vdev o un vdev dedicado, entonces se pierde todo el pool junto con \u00e9l.<\/p>\n

Los modernos grupos de almacenamiento pueden sobrevivir a la p\u00e9rdida de cach\u00e9 o de registro del dispositivo virtual; aunque pueden perder una peque\u00f1a cantidad de datos no escritos si pierden el registro del vdev durante un corte de energ\u00eda o una falla del sistema.<\/p>\n

Existe una creencia com\u00fan de que las 'bandas de datos' (stripes) de ZFS se escriben a trav\u00e9s de todo el grupo. Esto es incorrecto. Zpool no es simplemente un RAID0 divertido, es m\u00e1s bien algo m\u00e1s complejo. JBOD<\/a><\/noindex> con un mecanismo complejo y variable de distribuci\u00f3n.<\/p>\n

En su mayor parte, las escrituras se distribuyen entre los dispositivos virtuales disponibles de acuerdo con el espacio libre disponible, por lo que te\u00f3ricamente todos se llenar\u00edan al mismo tiempo. En versiones m\u00e1s recientes de ZFS, se toma en cuenta el uso actual (utilizaci\u00f3n) del vdev; si un dispositivo virtual est\u00e1 significativamente m\u00e1s cargado que otro (por ejemplo, debido a una alta carga de lectura), se omitir\u00e1 temporalmente para la escritura, a pesar de tener el mayor coeficiente de espacio libre.<\/p>\n

El mecanismo de determinaci\u00f3n de utilizaci\u00f3n incorporado en los m\u00e9todos modernos de distribuci\u00f3n de escritura de ZFS puede reducir la latencia y aumentar el rendimiento durante per\u00edodos de carga inusualmente alta; pero esto no da carta blanca<\/i> para la mezcla involuntaria de HDD lentos y SSD r\u00e1pidos en un mismo grupo. Un grupo desigualmente equilibrado seguir\u00e1 funcionando a la velocidad del dispositivo m\u00e1s lento, es decir, como si estuviera completamente compuesto de esos dispositivos.<\/p>\n

vdev<\/h3>\n

\nCada grupo de almacenamiento consta de uno o varios dispositivos virtuales (virtual device, vdev). A su vez, cada vdev incluye uno o m\u00e1s dispositivos f\u00edsicos. La mayor\u00eda de los dispositivos virtuales se utilizan para almacenamiento simple de datos, pero existen varias clases auxiliares de vdev, incluyendo CACHE, LOG y SPECIAL. Cada uno de estos tipos de vdev puede tener una de cinco topolog\u00edas: dispositivo \u00fanico (single-device), RAIDz1, RAIDz2, RAIDz3 o espejo (mirror).<\/p>\n

RAIDz1, RAIDz2 y RAIDz3 son tipos especiales de lo que los viejos llamar\u00edan RAID de doble paridad (diagonal). 1, 2 y 3 se refieren a cu\u00e1ntos bloques de paridad se asignan a cada franja de datos. En lugar de discos separados para la paridad, los dispositivos virtuales RAIDz distribuyen esta paridad de manera semiuniforme entre los discos. Un arreglo RAIDz puede perder tantos discos como bloques de paridad tenga; si pierde uno m\u00e1s, fallar\u00e1 y llevar\u00e1 consigo el pool de almacenamiento.<\/p>\n

En los dispositivos virtuales espejo (mirror vdev), cada bloque se almacena en cada dispositivo en vdev. Aunque los espejos dobles (two-wide) son los m\u00e1s comunes, en un espejo puede haber cualquier cantidad arbitraria de dispositivos; en instalaciones grandes, para mejorar el rendimiento de lectura y la resiliencia, a menudo se utilizan espejos triples. Un espejo vdev puede sobrevivir a cualquier falla mientras al menos un dispositivo en vdev siga funcionando.<\/p>\n

Los vdev individuales son intr\u00ednsecamente peligrosos. Este tipo de dispositivo virtual no sobrevivir\u00e1 a ninguna falla, y si se utiliza como almacenamiento o vdev especial, su falla resultar\u00e1 en la destrucci\u00f3n de todo el pool. Aqu\u00ed se debe tener mucho, mucho cuidado.<\/p>\n

Los dispositivos virtuales CACHE, LOG y SPECIAL pueden ser creados en cualquiera de las topolog\u00edas mencionadas anteriormente, pero recuerde que la p\u00e9rdida de un dispositivo virtual SPECIAL significa la p\u00e9rdida del pool, por lo que se recomienda encarecidamente una topolog\u00eda redundante.<\/p>\n

dispositivo<\/h3>\n

\nProbablemente este es el t\u00e9rmino m\u00e1s f\u00e1cil de entender en ZFS: se refiere literalmente a un dispositivo de bloques de acceso aleatorio. Recuerde que los dispositivos virtuales est\u00e1n compuestos de dispositivos individuales, y un pool est\u00e1 hecho de dispositivos virtuales.<\/p>\n

Los discos, ya sean magn\u00e9ticos o de estado s\u00f3lido, son los dispositivos de bloques m\u00e1s comunes utilizados como bloques de construcci\u00f3n de vdev. Sin embargo, cualquier dispositivo con un descriptor en \/dev funcionar\u00e1, por lo que se pueden usar arreglos RAID de hardware completos como dispositivos individuales.<\/p>\n

Un archivo raw simple es uno de los dispositivos de bloques alternativos m\u00e1s importantes de los que se puede construir un vdev. Los pools de prueba de archivos delgados<\/a><\/noindex>\u00a0son una forma muy conveniente de probar los comandos del pool y ver cu\u00e1nto espacio est\u00e1 disponible en el pool o dispositivo virtual de esta topolog\u00eda.<\/p>\n

\"Fundamentos
\nPuedes crear un grupo de prueba a partir de archivos dispersos en solo unos segundos, pero no olvides eliminar todo el grupo y sus componentes despu\u00e9s.<\/i> <\/p>\n

Supongamos que deseas configurar un servidor con ocho discos y planeas usar discos de 10 TB (~9300 GiB), pero no est\u00e1s seguro de cu\u00e1l topolog\u00eda se adapta mejor a tus necesidades. En el ejemplo anterior, construimos un grupo de prueba a partir de archivos dispersos en segundos, y ahora sabemos que un RAIDz2 vdev compuesto por ocho discos de 10 TB proporciona 50 TiB de capacidad \u00fatil.<\/p>\n

Otra categor\u00eda especial de dispositivos son los SPARE (de reserva). A diferencia de los dispositivos convencionales, los dispositivos de reemplazo en caliente pertenecen a todo el grupo, no a un solo dispositivo virtual. Si alg\u00fan vdev en el grupo falla y un dispositivo de reserva est\u00e1 conectado y disponible, se unir\u00e1 autom\u00e1ticamente al vdev afectado.<\/p>\n

Una vez conectado al vdev afectado, el dispositivo de reserva comienza a recibir copias o reconstrucciones de los datos que deber\u00edan estar en el dispositivo faltante. En RAID tradicional, esto se llama recuperaci\u00f3n (rebuilding), y en ZFS se conoce como \"recuperaci\u00f3n de redundancia\" (resilvering).<\/p>\n

Es importante destacar que los dispositivos de reserva no sustituyen permanentemente a los dispositivos fallidos. Son solo un reemplazo temporal para reducir el tiempo durante el cual se observa la degradaci\u00f3n del vdev. Despu\u00e9s de que el administrador reemplace el dispositivo fallido del vdev, se lleva a cabo la recuperaci\u00f3n de redundancia en el nuevo dispositivo permanente, y el SPARE se desconecta del vdev y regresa a su funci\u00f3n de reserva para todo el grupo.<\/p>\n

Conjuntos de datos, bloques y sectores<\/h1>\n

\nEl siguiente conjunto de bloques de construcci\u00f3n que debemos entender en nuestro viaje por ZFS se relaciona menos con el hardware y m\u00e1s con c\u00f3mo est\u00e1n organizados y almacenados los propios datos. Aqu\u00ed omitimos algunos niveles, como el metaslab, para no sobrecargar de detalles, manteniendo as\u00ed una comprensi\u00f3n de la estructura general.<\/p>\n

Conjunto de datos (dataset)<\/h3>\n

\n\"Fundamentos
\nCuando creamos un conjunto de datos por primera vez, muestra todo el espacio disponible del grupo. Luego, establecemos una cuota y cambiamos el punto de montaje. \u00a1Magia!<\/i> <\/p>\n

\"Fundamentos
\nZvol es en su mayor\u00eda solo un conjunto de datos sin su capa de sistema de archivos, que aqu\u00ed reemplazamos por un sistema de archivos ext4 completamente normal.<\/i> <\/p>\n

El conjunto de datos ZFS es aproximadamente comparable a un sistema de archivos montado est\u00e1ndar. Al igual que un sistema de archivos com\u00fan, a primera vista parece \"simplemente otra carpeta m\u00e1s\". Pero, al igual que los sistemas de archivos montables, cada conjunto de datos ZFS tiene su propio conjunto de propiedades b\u00e1sicas.<\/p>\n

En primer lugar, a un conjunto de datos se le puede asignar una cuota. Si estableces zfs set quota=100G poolname\/datasetname<\/code>, no podr\u00e1s escribir en la carpeta montada \/poolname\/datasetname<\/code> m\u00e1s de 100 GiB.<\/p>\n

\u00bfNotaste la presencia y ausencia de la barra diagonal al comienzo de cada l\u00ednea? Cada conjunto de datos tiene su propio lugar tanto en la jerarqu\u00eda de ZFS como en la jerarqu\u00eda de montaje del sistema. En la jerarqu\u00eda de ZFS no hay barra inicial: comienzas con el nombre del pool y luego sigues el camino de un conjunto de datos al siguiente. Por ejemplo, pool\/parent\/child<\/code> para un conjunto de datos llamado child<\/code> debajo del conjunto de datos padre parent<\/code> en un pool con un nombre creativo pool<\/code>.<\/p>\n

Por defecto, el punto de montaje del conjunto de datos ser\u00e1 equivalente a su nombre en la jerarqu\u00eda de ZFS, con una barra al principio: el pool llamado pool<\/code> se montar\u00e1 como \/pool<\/code>, el conjunto de datos parent<\/code> se montar\u00e1 en \/pool\/parent<\/code>, y el conjunto de datos hijo child<\/code> se montar\u00e1 en \/pool\/parent\/child<\/code>. Sin embargo, el punto de montaje del conjunto de datos puede ser cambiado.<\/p>\n

Si especificamos zfs set mountpoint=\/lol pool\/parent\/child<\/code>, el conjunto de datos pool\/parent\/child<\/code> se montar\u00e1 en el sistema como \/lol<\/code>.<\/p>\n

Adem\u00e1s de los conjuntos de datos, debemos mencionar los vol\u00famenes (zvols). Un volumen es aproximadamente comparable a un conjunto de datos, excepto que en \u00e9l realmente no hay un sistema de archivos: es solo un dispositivo de bloque. Puedes, por ejemplo, crear zvol<\/code> llamado mypool\/myzvol<\/code>, luego formatearlo con un sistema de archivos ext4, y luego montar este sistema de archivos: \u00a1ahora tienes un sistema de archivos ext4, pero con soporte para todas las funciones de seguridad de ZFS! Puede parecer tonto en una computadora, pero tiene mucho m\u00e1s sentido como backend al exportar un dispositivo iSCSI.<\/p>\n

Bloques<\/h3>\n

\n\"Fundamentos
\nUn archivo se presenta como uno o varios bloques. Cada bloque se almacena en un dispositivo virtual. El tama\u00f1o del bloque generalmente es igual al par\u00e1metro recordsize<\/b>, pero puede ser reducido a 2^ashift<\/b>, si contiene metadatos o un archivo peque\u00f1o.<\/i><\/p>\n

\"Fundamentos
\nRealmente, realmente<\/b> no estamos bromeando sobre el enorme da\u00f1o al rendimiento si se establece un ashift demasiado peque\u00f1o.<\/i><\/p>\n

En el grupo ZFS, todos los datos, incluidos los metadatos, se almacenan en bloques. El tama\u00f1o m\u00e1ximo del bloque para cada conjunto de datos se define en la propiedad recordsize<\/code> (tama\u00f1o del registro). El tama\u00f1o del registro puede cambiar, pero esto no alterar\u00e1 el tama\u00f1o o la ubicaci\u00f3n de cualquier bloque que ya haya sido escrito en el conjunto de datos; solo se aplica a nuevos bloques a medida que se escriben.<\/p>\n

A menos que se indique lo contrario, el tama\u00f1o de registro actual por defecto es de 128 KiB. Es una especie de compromiso complicado, en el que el rendimiento no ser\u00e1 ideal, pero tampoco ser\u00e1 terrible en la mayor\u00eda de los casos. Tama\u00f1o del registro<\/code> puede establecerse en cualquier valor de 4K a 1M (con configuraciones adicionales recordsize<\/code> puede establecerse a\u00fan m\u00e1s grande, pero rara vez es una buena idea).<\/p>\n

Cualquier bloque hace referencia solo a los datos de un \u00fanico archivo; no puedes encajar dos archivos diferentes en un solo bloque. Cada archivo consiste en uno o varios bloques, dependiendo de su tama\u00f1o. Si el tama\u00f1o del archivo es menor que el tama\u00f1o del registro, se almacenar\u00e1 en un bloque de menor tama\u00f1o; por ejemplo, un bloque con un archivo de 2 KiB ocupar\u00e1 solo un sector de 4 KiB en el disco.<\/p>\n

Los vol\u00famenes zvol no tienen la propiedad recordsize<\/code>\u00a0\u2014 en su lugar tienen una propiedad equivalente volblocksize.<\/code>.<\/p>\n

Sectores<\/h3>\n

\nEl \u00faltimo y m\u00e1s b\u00e1sico bloque de construcci\u00f3n es el sector. Esta es la unidad f\u00edsica m\u00e1s peque\u00f1a que se puede escribir o leer desde un dispositivo base. Durante varias d\u00e9cadas, la mayor\u00eda de los discos han utilizado sectores de 512 bytes. Recientemente, la mayor\u00eda de los discos est\u00e1n configurados para sectores de 4 KiB, y algunos, especialmente SSD, tienen sectores de 8 KiB o incluso m\u00e1s.<\/p>\n

En el sistema ZFS, hay una propiedad que permite establecer manualmente el tama\u00f1o del sector. Esta propiedad ashift<\/code>. Es algo confuso que ashift sea una potencia de dos. Por ejemplo, ashift=9<\/code> significa un tama\u00f1o de sector de 2^9, o 512 bytes.<\/p>\n

ZFS solicita al sistema operativo informaci\u00f3n detallada sobre cada dispositivo de bloque cuando se a\u00f1ade a un nuevo vdev, y te\u00f3ricamente establece ashift autom\u00e1ticamente seg\u00fan esta informaci\u00f3n. Desafortunadamente, muchos discos proporcionan informaci\u00f3n incorrecta sobre su tama\u00f1o de sector para mantener la compatibilidad con Windows XP (que no pod\u00eda entender discos con otros tama\u00f1os de sectores).<\/p>\n

Esto significa que se recomienda encarecidamente al administrador de ZFS conocer el tama\u00f1o real de sector de sus dispositivos y establecerlo manualmente. ashift<\/code>. Si ashift se establece demasiado bajo, se incrementa de forma astron\u00f3mica la cantidad de operaciones de lectura\/escritura. As\u00ed, escribir \"sectores\" de 512 bytes en un sector real de 4 KiB implica primero escribir el primer \"sector\", luego leer el sector de 4 KiB, modificarlo con el segundo \"sector\" de 512 bytes, volver a escribirlo en el nuevo sector de 4 KiB y as\u00ed sucesivamente para cada escritura.<\/p>\n

En el mundo real, esta penalizaci\u00f3n afecta a los SSD Samsung EVO, para los cuales deber\u00eda aplicarse ashift=13<\/code>, pero estos SSD informan incorrectamente sobre su tama\u00f1o de sector, y por lo tanto se establece por defecto ashift=9<\/code>. Si un administrador del sistema experimentado no cambia esta configuraci\u00f3n, este SSD funcionar\u00e1 m\u00e1s lentamente<\/i> que un HDD magn\u00e9tico normal.<\/p>\n

En comparaci\u00f3n, un tama\u00f1o demasiado grande ashift<\/code> pr\u00e1cticamente no tiene ninguna penalizaci\u00f3n. No hay una disminuci\u00f3n real en el rendimiento, y el aumento del espacio no utilizado es infinitesimal (o nulo cuando la compresi\u00f3n est\u00e1 habilitada). Por ello, recomendamos encarecidamente que incluso aquellos discos que realmente usan sectores de 512 bytes, configuren ashift=12<\/code> o incluso ashift=13<\/code>, para mirar con confianza hacia el futuro.<\/p>\n

Propiedad ashift<\/code> se establece para cada dispositivo virtual vdev, y no para el pool<\/i>, como muchos piensan err\u00f3neamente, y no se cambia despu\u00e9s de la configuraci\u00f3n. Si accidentalmente lo alteras ashift<\/code> al agregar un nuevo vdev al pool, habr\u00e1s contaminado irremediablemente este pool con un dispositivo de bajo rendimiento y, por lo general, no hay otra opci\u00f3n que destruir el pool y comenzar desde cero. Incluso eliminar el vdev no salvar\u00e1 de la configuraci\u00f3n incorrecta. ashift<\/code>!<\/p>\n

El mecanismo de copia al escribir<\/h3>\n

\n\"Fundamentos
\nSi a un sistema de archivos normal necesita reescribir datos, modifica cada bloque donde se encuentra.<\/i><\/p>\n

\"Fundamentos
\nEl sistema de archivos con copia al escribir guarda una nueva versi\u00f3n del bloque y luego desbloquea la versi\u00f3n antigua.<\/i><\/p>\n

\"Fundamentos
\nEn t\u00e9rminos abstractos, si ignoramos la ubicaci\u00f3n f\u00edsica real de los bloques, nuestra 'cometa de datos' se simplifica a un 'gusano de datos' que se mueve de izquierda a derecha por el mapa del espacio disponible.<\/i><\/p>\n

\"Fundamentos
\nAhora podemos tener una buena idea de c\u00f3mo funcionan los snapshots de copia al escribir: cada bloque puede pertenecer a varios snapshots y se conservar\u00e1 hasta que se destruyan todos los snapshots asociados.<\/i><\/p>\n

El mecanismo de copia al escribir (Copy on Write, CoW) es la base fundamental de lo que hace que ZFS sea un sistema tan impresionante. El concepto b\u00e1sico es simple: si le pides a un sistema de archivos tradicional que cambie un archivo, har\u00e1 exactamente lo que pediste. Si le pides a un sistema de archivos con copia al escribir que haga lo mismo, dir\u00e1 'est\u00e1 bien' pero te mentir\u00e1.<\/p>\n

En lugar de eso, el sistema de archivos con copia al escribir guarda una nueva versi\u00f3n del bloque modificado y luego actualiza los metadatos del archivo para romper la conexi\u00f3n con el bloque antiguo y asociar el nuevo bloque que acabas de guardar.<\/p>\n

La desconexi\u00f3n del bloque antiguo y la asociaci\u00f3n del nuevo se realiza en una sola operaci\u00f3n, por lo que no se puede interrumpir: si apagas la alimentaci\u00f3n despu\u00e9s de que ocurra, tienes una nueva versi\u00f3n del archivo, y si apagas la alimentaci\u00f3n antes, tienes la versi\u00f3n antigua. En cualquier caso, no habr\u00e1 conflictos en el sistema de archivos.<\/p>\n

La copia al escribir en ZFS ocurre no solo a nivel de sistema de archivos, sino tambi\u00e9n a nivel de gesti\u00f3n de discos. Esto significa que ZFS no es susceptible a los huecos de escritura (hoyo en RAID<\/a><\/noindex>) \u2014 un fen\u00f3meno en el que la franja solo se escribi\u00f3 parcialmente antes de un fallo del sistema, da\u00f1ando el arreglo despu\u00e9s del reinicio. Aqu\u00ed, la franja se escribe de manera at\u00f3mica, el vdev siempre es coherente, y Bob es tu t\u00edo<\/a><\/noindex>.<\/p>\n

ZIL: el diario de intenciones de ZFS<\/h3>\n

\n\"Fundamentos
\nEl sistema ZFS maneja las escrituras s\u00edncronas de una manera especial: las guarda temporalmente, pero inmediatamente en el ZIL, antes de escribirlas permanentemente junto con las escrituras as\u00edncronas.<\/i><\/p>\n

\"Fundamentos
\nNormalmente, los datos escritos en el ZIL nunca se vuelven a leer. Pero esto es posible despu\u00e9s de un fallo del sistema.<\/i><\/p>\n

\"Fundamentos
\nSLOG, o dispositivo LOG secundario, es simplemente un vdev especial \u2014 y, preferiblemente, muy r\u00e1pido \u2014 donde ZIL puede almacenarse por separado del almacenamiento principal.<\/i><\/p>\n

\"Fundamentos
\nDespu\u00e9s de un fallo, todos los datos sucios en ZIL se reproducen \u2014 en este caso, ZIL se encuentra en SLOG, as\u00ed que se reproducen desde all\u00ed.<\/i><\/p>\n

Existen dos categor\u00edas principales de operaciones de escritura: sincr\u00f3nicas (sync) y asincr\u00f3nicas (async). Para la mayor\u00eda de las cargas de trabajo, la gran mayor\u00eda de las operaciones de escritura son asincr\u00f3nicas \u2014 el sistema de archivos permite agregarlas y emitirlas en paquetes, reduciendo la fragmentaci\u00f3n y aumentando significativamente el ancho de banda.<\/p>\n

Las escrituras sincr\u00f3nicas son algo completamente diferente. Cuando una aplicaci\u00f3n solicita una escritura sincr\u00f3nica, le dice al sistema de archivos: \u00abNecesitas registrar esto en la memoria no vol\u00e1til, este mismo momento<\/i>, y hasta entonces no puedo hacer nada m\u00e1s\u00bb. Por lo tanto, las escrituras sincr\u00f3nicas deben registrarse inmediatamente en el disco \u2014 y si esto aumenta la fragmentaci\u00f3n o reduce el ancho de banda, as\u00ed sea.<\/p>\n

ZFS maneja las escrituras sincr\u00f3nicas de manera diferente a los sistemas de archivos convencionales \u2014 en lugar de verterlas inmediatamente en el almacenamiento normal, ZFS las registra en un \u00e1rea de almacenamiento especial llamada ZFS Intent Log, o ZIL. La clave es que estas escrituras tambi\u00e9n<\/i> permanecen en memoria, siendo agregadas junto con las solicitudes de escritura asincr\u00f3nicas normales, para ser luego volcadas en el almacenamiento como grupos de transacciones (TXG, Transaction Groups) completamente normales.<\/p>\n

En condiciones normales de operaci\u00f3n, ZIL se escribe y nunca se lee nuevamente. Cuando despu\u00e9s de unos momentos las escrituras de ZIL se registran en el almacenamiento principal dentro de los TXG normales desde la memoria, se desconectan de ZIL. La \u00fanica vez que algo se lee de ZIL es durante la importaci\u00f3n de un pool.<\/p>\n

Si ocurre un fallo en ZFS \u2014 fallo del sistema operativo o corte de energ\u00eda \u2014 cuando hay datos en ZIL, estos datos se leer\u00e1n durante la pr\u00f3xima importaci\u00f3n del pool (por ejemplo, al reiniciar un sistema de recuperaci\u00f3n). Todo lo que est\u00e1 en ZIL se leer\u00e1, se combinar\u00e1 en grupos TXG, se registrar\u00e1 en el almacenamiento principal y luego se desconectar\u00e1 de ZIL durante el proceso de importaci\u00f3n.<\/p>\n

Una de las clases auxiliares de vdev se llama LOG o SLOG, que es un dispositivo secundario LOG. Su tarea es proporcionar al pool un dispositivo vdev separado y, preferiblemente, mucho m\u00e1s r\u00e1pido, con una alta resistencia a la escritura, para almacenar ZIL, en lugar de almacenar ZIL en el almacenamiento principal del vdev. El propio ZIL se comporta de la misma manera independientemente de d\u00f3nde se almacena, pero si el vdev con LOG tiene un rendimiento de escritura muy alto, las escrituras sincr\u00f3nicas suceder\u00e1n m\u00e1s r\u00e1pido.<\/p>\n

Agregar un vdev con LOG al pool no puede mejorar<\/b> el rendimiento de la escritura asincr\u00f3nica, incluso si obligas a todas las escrituras en ZIL usando zfs set sync=always<\/code>, seguir\u00e1n atadas al almacenamiento principal en TXG de la misma forma y al mismo ritmo que sin el registro. La \u00fanica mejora directa en el rendimiento es la latencia de la escritura sincr\u00f3nica (ya que una velocidad de registro mayor acelera la ejecuci\u00f3n de las operaciones sync<\/code>).<\/p>\n

Sin embargo, en un entorno que ya requiere una gran cantidad de escrituras sincr\u00f3nicas, el vdev LOG puede acelerar indirectamente la escritura asincr\u00f3nica y la lectura no en cach\u00e9. Descargar las escrituras ZIL en un vdev LOG separado significa menos competencia por IOPS en el almacenamiento primario, lo que en cierta medida mejora el rendimiento de todas las operaciones de lectura y escritura.<\/p>\n

Instant\u00e1neas<\/h3>\n

\nEl mecanismo de copia en escritura tambi\u00e9n es una base necesaria para las instant\u00e1neas at\u00f3micas de ZFS y la replicaci\u00f3n asincr\u00f3nica incremental. En un sistema de archivos activo, hay un \u00e1rbol de punteros que marca todas las escrituras con los datos actuales; cuando haces una instant\u00e1nea, simplemente haces una copia de este \u00e1rbol de punteros.<\/p>\n

Cuando se sobrescribe una escritura en un sistema de archivos activo, ZFS primero escribe la nueva versi\u00f3n del bloque en el espacio no utilizado. Luego desvincula la antigua versi\u00f3n del bloque del sistema de archivos actual. Pero si alguna instant\u00e1nea hace referencia al antiguo bloque, este sigue siendo inalterado. \u00a1El bloque antiguo no se recuperar\u00e1 realmente como espacio libre hasta que se destruyan todas las instant\u00e1neas que referencian ese bloque!<\/p>\n

Replicaci\u00f3n<\/h3>\n

\n\"Fundamentos
\nMi biblioteca de Steam en 2015 ocupaba 158 GiB y conten\u00eda 126,927 archivos. Esto est\u00e1 bastante cerca de la situaci\u00f3n \u00f3ptima para rsync; la replicaci\u00f3n ZFS a trav\u00e9s de la red fue \u00absolo\u00bb un 750% m\u00e1s r\u00e1pida.<\/i><\/p>\n

\"Fundamentos
\nEn la misma red, la replicaci\u00f3n de un archivo de imagen de m\u00e1quina virtual de 40 gigabyte de Windows 7 es una historia completamente diferente. La replicaci\u00f3n ZFS ocurre 289 veces m\u00e1s r\u00e1pido que rsync, o 'solo' 161 veces m\u00e1s r\u00e1pido si tienes suficientes conocimientos para invocar rsync con la opci\u00f3n \u2014inplace.<\/i><\/p>\n

\"Fundamentos
\nCuando se escala una imagen de m\u00e1quina virtual, los problemas de rsync tambi\u00e9n escalan con ella. Un tama\u00f1o de 1,9 TiB no es tan grande para una imagen de m\u00e1quina virtual moderna, pero es lo suficientemente grande como para que la replicaci\u00f3n ZFS resulte 1148 veces m\u00e1s r\u00e1pida que rsync, incluso con el argumento de rsync \u2014inplace.<\/i><\/p>\n

Una vez que comprenda c\u00f3mo funcionan las instant\u00e1neas, no ser\u00e1 dif\u00edcil captar la esencia de la replicaci\u00f3n. Dado que una instant\u00e1nea es simplemente un \u00e1rbol de punteros a registros, se deduce que si hacemos zfs send<\/code> de la instant\u00e1nea, estamos enviando tanto este \u00e1rbol como todos los registros asociados. Cuando transmitimos esto a zfs send<\/code> en zfs receive<\/code> en el objeto de destino, escribe tanto el contenido real del bloque como el \u00e1rbol de punteros que referencia los bloques en el conjunto de datos de destino.<\/p>\n

Las cosas se vuelven a\u00fan m\u00e1s interesantes en el segundo zfs send<\/code>. Ahora tenemos dos sistemas, cada uno conteniendo poolname\/datasetname@1<\/code>, mientras toma una nueva instant\u00e1nea poolname\/datasetname@2<\/code>. Por lo tanto, en el pool original tiene datasetname@1<\/code> y datasetname@2<\/code>, mientras que en el pool de destino solo hay la primera instant\u00e1nea por el momento. datasetname@1<\/code>.<\/p>\n

Dado que entre la fuente y el destino tenemos una instant\u00e1nea compartida datasetname@1<\/code>, podemos hacer un incremental<\/i> zfs send<\/code> sobre ella. Cuando le decimos al sistema zfs send -i poolname\/datasetname@1 poolname\/datasetname@2<\/code>, compara los dos \u00e1rboles de punteros. Cualquier puntero que exista solo en @2<\/code>, evidentemente, apunta a nuevos bloques, por lo que necesitaremos el contenido de esos bloques.<\/p>\n

En el sistema remoto, el proceso incremental send<\/code> es igual de sencillo. Primero, escribimos todos los nuevos registros incluidos en el flujo send<\/code>, y luego a\u00f1adimos punteros a esos bloques. Voil\u00e0, tenemos @2<\/code> en el nuevo sistema!<\/p>\n

La replicaci\u00f3n incremental as\u00edncrona de ZFS es una gran mejora respecto a los m\u00e9todos anteriores que no se basaban en instant\u00e1neas, como rsync. En ambos casos, se transfieren solo los datos modificados, pero rsync debe primero leer<\/i> desde el disco todos los datos desde ambos lados, para verificar el checksum y compararlo. A diferencia de esto, la replicaci\u00f3n ZFS no lee nada excepto los \u00e1rboles de punteros y cualquier bloque que no est\u00e9 presente en el snapshot compartido.<\/p>\n

Compresi\u00f3n integrada<\/h3>\n

\nEl mecanismo de escritura tambi\u00e9n simplifica el sistema de compresi\u00f3n integrada. En un sistema de archivos tradicional, la compresi\u00f3n es problem\u00e1tica: tanto la versi\u00f3n antigua como la nueva de los datos modificados residen en el mismo espacio.<\/p>\n

Si consideramos un fragmento de datos en medio del archivo, que comienza su vida como un megabyte de ceros desde 0x00000000 y as\u00ed sucesivamente, se puede comprimir f\u00e1cilmente a un solo sector en el disco. Pero \u00bfqu\u00e9 pasar\u00e1 si reemplazamos este megabyte de ceros por un megabyte de datos no comprimibles, como JPEG o ruido pseudoaleatorio? Sorprendentemente, este megabyte de datos requerir\u00e1 no uno, sino 256 sectores de 4 KiB, mientras que en este lugar del disco solo se ha reservado un sector.<\/p>\n

ZFS no tiene tal problema, ya que las escrituras modificadas siempre se registran en el espacio no utilizado: el bloque original ocupa solo un sector de 4 KiB, y la nueva escritura ocupar\u00e1 256, pero esto no es un problema, ya que el fragmento \"medio\" del archivo recientemente modificado se habr\u00eda registrado en el espacio no utilizado independientemente de si su tama\u00f1o ha cambiado o no, por lo que para ZFS esto es una situaci\u00f3n bastante normal.<\/p>\n

La compresi\u00f3n integrada de ZFS est\u00e1 desactivada por defecto, y el sistema ofrece algoritmos conectables: actualmente entre ellos est\u00e1n LZ4, gzip (1-9), LZJB y ZLE.<\/p>\n

Si el archivo es lo suficientemente grande y requiere varios bloques, entonces todos los registros de ese archivo tendr\u00e1n un tama\u00f1o recordsize<\/code>\u00a0\u2014 incluyendo el \u00faltimo registro, cuya mayor parte puede resultar ser espacio no utilizado.<\/a><\/noindex>.<\/p>\n