Hola, recientemente me encontré con un problema interesante: configurar el almacenamiento para realizar copias de seguridad de una gran cantidad de dispositivos en bloque.
Cada semana realizamos copias de seguridad de todas las máquinas virtuales en nuestra nube, por lo que debemos poder realizar miles de copias de seguridad y hacerlo de la manera más rápida y eficiente posible.
Desafortunadamente, las configuraciones estándar RAID5, RAID6 en este caso no podremos hacerlo, ya que el proceso de recuperación en discos tan grandes como el nuestro será dolorosamente largo y probablemente nunca terminará.
Veamos qué alternativas hay:
— Similar a RAID5, RAID6, pero con nivel de paridad configurable. En este caso, la reserva no se realiza bloque por bloque, sino para cada objeto por separado. La forma más sencilla de intentar la codificación de borrado es expandir .
es una característica de ZFS inédita actualmente. A diferencia de RAIDZ, DRAID tiene un bloque de paridad distribuida y, durante la recuperación, utiliza todos los discos de la matriz a la vez, lo que le permite sobrevivir mejor a las fallas del disco y recuperarse más rápido después de una falla.
Servidor disponible Fujitsu Primergy RX300 S7 con procesador CPU Intel Xeon E5-2650L 0 a 1.80 GHz, nueve unidades de RAM Samsung DDR3-1333 8Gb PC3L-10600R Registro ECC (M393B1K70DH0-YH9), estante para discos Supermicro SuperChasis 847E26-RJBOD1, conectado a través de Expansor doble LSI SAS2X36 y 45 discos Seagage ST6000NM0115-1YZ110 en 6TB todo el mundo
Antes de decidir algo, primero debemos probar todo adecuadamente.
Para ello, preparé y probé varias configuraciones. Para hacer esto, utilicé minio, que actuó como un backend de S3 y lo lanzó en diferentes modos con diferentes números de objetivos.
Básicamente, el caso minio se probó en codificación de borrado versus raid de software con la misma cantidad de discos y paridad de discos, y estos son: RAID6, RAIDZ2 y DRAID2.
Como referencia: cuando inicia minio con un solo destino, minio funciona en modo puerta de enlace S3 y entrega su sistema de archivos local en forma de almacenamiento S3. Si inicia minio especificando varios objetivos, el modo de codificación de borrado se activará automáticamente, lo que distribuirá los datos entre sus objetivos y al mismo tiempo proporcionará tolerancia a fallas.
De forma predeterminada, minio divide los destinos en grupos de 16 discos, con 2 paridades por grupo. Aquellos. Dos discos pueden fallar al mismo tiempo sin perder datos.
Para probar el rendimiento, utilicé 16 discos de 6 TB cada uno y escribí en ellos pequeños objetos de 1 MB, lo que describe con mayor precisión nuestra carga futura, ya que todas las herramientas de copia de seguridad modernas dividen los datos en bloques de varios megabytes y los escriben de esta manera.
Para realizar la prueba comparativa, utilizamos la utilidad s3bench, iniciada en un servidor remoto y enviando decenas de miles de objetos de este tipo a minio en cientos de subprocesos. Después de lo cual intenté solicitarles que regresaran de la misma manera.
Los resultados del benchmark se muestran en la siguiente tabla:
Como podemos ver, minio en su propio modo de codificación de borrado tiene un rendimiento significativamente peor en escritura que minio ejecutándose sobre el software RAID6, RAIDZ2 y DRAID2 en la misma configuración.
Por separado yo Pruebe minio en ext4 frente a XFS. Sorprendentemente, para mi tipo de carga de trabajo, XFS resultó ser significativamente más lento que ext4.
En el primer lote de pruebas, Mdadm mostró superioridad sobre ZFS, pero luego que puede mejorar el rendimiento de ZFS configurando las siguientes opciones:
xattr=sa atime=off recordsize=1My después de eso las pruebas con ZFS mejoraron mucho.
También puede observar que DRAID no proporciona mucha ganancia de rendimiento respecto a RAIDZ, pero en teoría debería ser mucho más seguro.
En las dos últimas pruebas, también intenté transferir metadatos (especiales) y ZIL (registro) al espejo desde el SSD. Pero eliminar metadatos no aportó mucha ganancia en la velocidad de grabación, y al eliminar ZIL, mi Llegó al techo con una utilización del 100%, por lo que considero que esta prueba fue un fracaso. No excluyo que si tuviera unidades SSD más rápidas, quizás esto podría mejorar enormemente mis resultados, pero, desafortunadamente, no las tenía.
Al final, decidí usar DRAID y, a pesar de su estado beta, es la solución de almacenamiento más rápida y eficiente en nuestro caso.
Creé un DRAID2 simple en una configuración con tres grupos y dos repuestos distribuidos:
# zpool status data
pool: data
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
draid2:3g:2s-0 ONLINE 0 0 0
sdy ONLINE 0 0 0
sdam ONLINE 0 0 0
sdf ONLINE 0 0 0
sdau ONLINE 0 0 0
sdab ONLINE 0 0 0
sdo ONLINE 0 0 0
sdw ONLINE 0 0 0
sdak ONLINE 0 0 0
sdd ONLINE 0 0 0
sdas ONLINE 0 0 0
sdm ONLINE 0 0 0
sdu ONLINE 0 0 0
sdai ONLINE 0 0 0
sdaq ONLINE 0 0 0
sdk ONLINE 0 0 0
sds ONLINE 0 0 0
sdag ONLINE 0 0 0
sdi ONLINE 0 0 0
sdq ONLINE 0 0 0
sdae ONLINE 0 0 0
sdz ONLINE 0 0 0
sdan ONLINE 0 0 0
sdg ONLINE 0 0 0
sdac ONLINE 0 0 0
sdx ONLINE 0 0 0
sdal ONLINE 0 0 0
sde ONLINE 0 0 0
sdat ONLINE 0 0 0
sdaa ONLINE 0 0 0
sdn ONLINE 0 0 0
sdv ONLINE 0 0 0
sdaj ONLINE 0 0 0
sdc ONLINE 0 0 0
sdar ONLINE 0 0 0
sdl ONLINE 0 0 0
sdt ONLINE 0 0 0
sdah ONLINE 0 0 0
sdap ONLINE 0 0 0
sdj ONLINE 0 0 0
sdr ONLINE 0 0 0
sdaf ONLINE 0 0 0
sdao ONLINE 0 0 0
sdh ONLINE 0 0 0
sdp ONLINE 0 0 0
sdad ONLINE 0 0 0
spares
s0-draid2:3g:2s-0 AVAIL
s1-draid2:3g:2s-0 AVAIL
errors: No known data errorsBien, hemos ordenado el almacenamiento, ahora hablemos de lo que respaldaremos. Aquí me gustaría hablarles de inmediato sobre tres soluciones que logré probar, y estas son:
- tenedor , una solución especializada para la copia de seguridad de dispositivos en bloque, tiene una estrecha integración con Ceph. Puede tomar diferencias entre instantáneas y formar una copia de seguridad incremental a partir de ellas. Admite una gran cantidad de backends de almacenamiento, incluidos tanto locales como S3. Requiere una base de datos independiente para almacenar la tabla hash de deduplicación. De las desventajas: escrito en Python, tiene un CLI que no responde.
- tenedor , una herramienta de copia de seguridad probada y conocida desde hace mucho tiempo, puede realizar copias de seguridad de datos y deduplicarlos bien. Capaz de guardar copias de seguridad tanto localmente como en un servidor remoto a través de scp. Puede hacer una copia de seguridad de los dispositivos bloqueados si se inicia con la bandera --special, una de las desventajas: al crear una copia de seguridad, el repositorio se bloquea completamente, por lo que se recomienda crear un repositorio separado para cada máquina virtual, en principio esto no es un problema, afortunadamente se crean muy fácilmente.
es un proyecto en desarrollo activo, escrito en go, bastante rápido y compatible con una gran cantidad de backends de almacenamiento, incluido almacenamiento local, scp, S3 y mucho más. Por separado, me gustaría señalar que hay un creado especialmente para restic, que le permite exportar rápidamente el almacenamiento para usarlo de forma remota. De todos los anteriores, el que más me gustó. Puede realizar una copia de seguridad desde la entrada estándar. Casi no tiene desventajas notables, pero hay varias características:
-
En primer lugar, intenté usarlo en el modo de repositorio general para todas las máquinas virtuales (como Benji) e incluso funcionó bastante bien, pero las operaciones de restauración tomaron mucho tiempo, porque... Cada vez antes de restaurar, restic intenta leer los metadatos de todas las copias de seguridad. Este problema se resolvió fácilmente, al igual que con borg, creando un repositorio separado para cada máquina virtual. Este enfoque también ha demostrado ser muy eficaz para gestionar las copias de seguridad. Los repositorios separados pueden tener una contraseña separada para acceder a los datos, y tampoco debemos temer que el repositorio global se rompa de alguna manera. Puedes generar nuevos repositorios tan fácilmente como en borg backup.
En cualquier caso, la deduplicación se realiza solo en relación con la versión anterior de la copia de seguridad; la copia de seguridad anterior está determinada por la ruta para la copia de seguridad especificada, por lo que si realiza una copia de seguridad de diferentes objetos desde stdin en un repositorio común, no olvide especificar el opción
--stdin-filename, o especificar explícitamente la opción cada vez--parent.
-
En segundo lugar, la recuperación a la salida estándar lleva mucho más tiempo que la recuperación al sistema de archivos debido a su naturaleza paralela. En el futuro, planeamos agregar un mayor soporte para copias de seguridad para dispositivos de bloque.
-
En tercer lugar, actualmente se recomienda utilizar , porque La versión 0.9.6 tiene un error con la recuperación prolongada de archivos grandes.
Para probar la efectividad de la copia de seguridad y la velocidad de escritura/restauración desde una copia de seguridad, creé un repositorio separado e intenté hacer una copia de seguridad de una pequeña imagen de una máquina virtual (21 GB). Se realizaron dos copias de seguridad sin cambiar el original, utilizando cada una de las soluciones enumeradas para verificar qué tan rápido/lento se copiaron los datos deduplicados.
Como podemos ver, Borg Backup tiene el mejor ratio de eficiencia de copia de seguridad inicial, pero es inferior en términos de velocidad de escritura y restauración.
Restic resultó ser más rápido que Benji Backup, pero lleva más tiempo restaurar a la salida estándar y, desafortunadamente, todavía no sabe cómo escribir directamente en un dispositivo de bloque.
Después de sopesar todos los pros y los contras, decidí decidirme por inquieto с servidor de descanso como la solución de respaldo más conveniente y prometedora.
En este screencast puede ver cómo se utiliza completamente un canal de 10 gigabits durante varias operaciones de respaldo que se ejecutan simultáneamente. Vale la pena señalar que el reciclaje de discos no supera el 30%.
¡Estoy más que satisfecho con la solución que recibí!
Fuente: habr.com