Por Henry Precheur y Kevin Jamieson
La replicación continua de Qumulo garantiza que una copia actualizada de los datos de un clúster se refleje en un clúster de Qumulo fuera del sitio o en la nube. Esto permite que nuestros clientes duerman bien por la noche sabiendo que pueden recuperarse rápidamente en caso de un desastre natural o una falla catastrófica.
¿Cómo puede un sistema de archivos que se amplía a miles de millones de archivos y petabytes de datos mantener una copia de los datos que normalmente está actualizada en minutos?
Las herramientas tradicionales para la copia de seguridad incremental como rsync y robocopy simplemente no escalan. Estas herramientas identifican los cambios entre un directorio de origen y destino al recorrer todo el árbol de directorios para comparar los atributos (el tamaño típico y el tiempo de modificación) o los datos de cada archivo.
Cuando solo un puñado de archivos puede haber cambiado entre incrementales, incluso con la paralelización que atraviesa miles de millones de archivos para identificar esos cambios, puede tomar horas o días.
En Qumulo, uno de nuestros mantras es "no hay caminatas en los árboles". La replicación continua de Qumulo se basa en la misma agregación en tiempo real que permite que nuestras funciones de análisis y cuotas eficientes eviten las caminatas en los árboles. Junto con las instantáneas, esto permite que cualquier cambio en el sistema de archivos se identifique y replique de manera eficiente con la cantidad mínima de tiempo y E / S.
La replicación continua funciona al tomar continuamente una nueva instantánea, comparando esa instantánea con la última instantánea replicada y replicando las diferencias. Cada instantánea tiene un identificador o "epoch" único y auto-incremental, y asociada con cada archivo y directorio es algo que llamamos una "última época modificada". Esto actúa como una marca de tiempo que describe la última instantánea en la que ese archivo o directorio cambió.
Cada vez que un archivo se modifica, se actualiza su última época modificada. De esta manera, sabemos si un archivo ha cambiado sin mirar su contenido, pero eso solo no es suficiente para ubicar un archivo modificado sin una caminata por el árbol. También actualizamos la última época modificada del directorio principal del archivo y su directorio primario, y así sucesivamente hasta el directorio raíz del sistema de archivos. Esto deja un rastro para encontrar rápidamente todos los cambios en el sistema de archivos entre las instantáneas.
Cuando se ejecuta la replicación continua, comparamos estas últimas épocas modificadas con la última instantánea, comenzando con el directorio raíz. Si esta comparación muestra que el directorio no ha cambiado desde la última vez que se ejecutó la replicación, podemos omitirlo y todos sus contenidos. Si el directorio ha cambiado, comparamos recursivamente la última época modificada de cada archivo y subdirectorio bajo ese directorio para averiguar qué archivos han cambiado y deben copiarse al clúster remoto.
Considere este ejemplo simple:
/casa (época=1)
|– alicia/ (época=1)
| |– diagrama.svg (época=1)
| `– informe.doc (época=1)
`– bob/ (época=1)
`– proyecto.psd (época=1)
Inicialmente, cada archivo tiene su última época modificada establecida en 1. Cuando Alice actualiza report.doc en / home / alice, la última época modificada de report.doc y de todos sus directorios de antepasados se establece en 2. Después de lo cual el sistema de archivos ahora se ve así:
/casa (época=2)
|– alicia/ (época=2)
| |– diagrama.svg (época=1)
| `– informe.doc (época=2)
`– bob/ (época=1)
`– proyecto.psd (época=1)
La época sin cambios de /home/alice/diagram.svg le dice a la replicación continua que omita ese archivo y solo copie el report.doc actualizado, mientras que la época de / home / bob informa a la replicación para ignorar ese directorio por completo y no examinar ninguno de sus contenidos .
¿Qué hay de los archivos parcialmente modificados? Si solo han cambiado unos pocos bytes de un archivo grande, sería una pérdida de tiempo y ancho de banda re-replicar ese archivo por completo. Es mucho más eficiente replicar solo el subconjunto de bloques del archivo que realmente ha cambiado. Debido a que el sistema de archivos Qumulo almacena los datos de un archivo en una estructura similar a un árbol de fragmentos de datos, el mismo último concepto de época modificado que permite la identificación eficiente de archivos modificados dentro de un árbol de directorios también se extiende a la identificación eficiente de bloques de datos modificados dentro de cada individuo expediente.
Como ejemplo, suponga que un archivo 3MB se crea y replica en la época 1, después de lo cual un usuario sobrescribe solo la mitad del archivo con datos nuevos. El árbol de datos del archivo se vería así:
presentar
| - 0 - 1 MB (época = 1)
| - 1 - 2 MB (época = 2)
`- 2 - 3 MB (época = 1)
Encontramos los fragmentos de datos actualizados en un archivo de la misma manera que encontramos los archivos actualizados en un directorio, al examinar las últimas épocas modificadas en su árbol. En el ejemplo anterior, omitimos la primera y la última parte del archivo y solo replicamos los datos en el medio con la época actualizada, haciendo solo una tercera parte del trabajo que tendríamos que hacer si copiamos todo el archivo.
De esta manera, las épocas actúan como un rastro de los archivos y datos dentro de los archivos que se modificaron entre las instantáneas replicadas, permitiendo que el sistema de replicación continua de Qumulo identifique todas las diferencias en el sistema de archivos en un tiempo que sea proporcional al tamaño de las mismas. diferencias, no el tamaño total del sistema de archivos!
