{"id":83100,"date":"2020-05-28T13:42:10","date_gmt":"2020-05-28T11:42:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/bekap-hranilishhe-dlya-tysyach-virtualnyh-mashin-svobodnymi-instrumentami"},"modified":"2020-05-28T13:42:10","modified_gmt":"2020-05-28T11:42:10","slug":"bekap-hranilishhe-dlya-tysyach-virtualnyh-mashin-svobodnymi-instrumentami","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/bekap-hranilishhe-dlya-tysyach-virtualnyh-mashin-svobodnymi-instrumentami","title":{"rendered":"Almacenamiento de copias de seguridad para miles de m\u00e1quinas virtuales con herramientas gratuitas","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Almacenamiento<\/p>\n

<\/p>\n

Hola, recientemente me encontr\u00e9 con un interesante desaf\u00edo para configurar un almacenamiento para hacer copias de seguridad de una gran cantidad de dispositivos de bloques.<\/p>\n

<\/p>\n

Cada semana realizamos copias de seguridad de todas las m\u00e1quinas virtuales en nuestra nube, por lo que necesitamos ser capaces de gestionar miles de copias de seguridad y hacerlo de la manera m\u00e1s r\u00e1pida y eficiente posible.<\/p>\n

<\/p>\n

Desafortunadamente, las configuraciones est\u00e1ndar RAID5<\/strong>, RAID6<\/strong> en este caso no nos servir\u00e1n porque el proceso de recuperaci\u00f3n en discos tan grandes como los nuestros ser\u00e1 tediosamente largo y probablemente nunca terminar\u00e1.<\/p>\n

<\/p>\n

Veamos qu\u00e9 alternativas hay:<\/p>\n

<\/p>\n

Erasure Coding<\/a><\/noindex><\/strong> \u2014 Equivalente a RAID5, RAID6, pero con un nivel de paridad configurable. En este caso, la redundancia se realiza no por bloques, sino para cada objeto por separado. La forma m\u00e1s sencilla de probar el erasure coding es desplegar minio<\/a><\/noindex>.<\/p>\n

<\/p>\n

DRAID<\/a><\/noindex><\/strong> \u2014 es una caracter\u00edstica a\u00fan no lanzada de ZFS. A diferencia de RAIDZ, DRAID tiene un bloque de paridad distribuido y al recuperarse involucra todos los discos del arreglo, lo que le permite manejar mejor las fallas de los discos y recuperarse m\u00e1s r\u00e1pido despu\u00e9s de un fallo. <\/p>\n

<\/a><\/noindex><\/p>\n

\"Almacenamiento<\/p>\n

<\/p>\n

\"Almacenamiento<\/p>\n

Dispongo de un servidor Fujitsu Primergy RX300 S7<\/strong> con un procesador Intel Xeon CPU E5-2650L 0 @ 1.80GHz<\/strong>, nueve m\u00f3dulos de memoria RAM Samsung DDR3-1333 8Gb PC3L-10600R ECC Registered (M393B1K70DH0-YH9)<\/strong>, una cabina de discos Supermicro SuperChassis 847E26-RJBOD1<\/strong>, conectada a trav\u00e9s de Dual LSI SAS2X36 Expander<\/strong> y 45 discos Seagate ST6000NM0115-1YZ110<\/strong> en 6TB<\/strong> cada uno.<\/p>\n

<\/p>\n

Antes de tomar una decisi\u00f3n, primero necesitamos probar todo adecuadamente.<\/p>\n

<\/p>\n

Para ello me prepar\u00e9 y realic\u00e9 pruebas de diversas configuraciones. Utilic\u00e9 minio, que actu\u00f3 como un backend S3, y lo ejecut\u00e9 en diferentes modos con diversas cantidades de targets.<\/p>\n

<\/p>\n

Principalmente se prob\u00f3 el caso de minio en erasure coding vs software raid con la misma cantidad de discos y discos de paridad, que son: RAID6, RAIDZ2 y DRAID2.<\/p>\n

<\/p>\n

Para referencia: cuando inicias minio con un solo target, minio opera en modo S3 gateway, ofreciendo tu sistema de archivos local como un almacenamiento S3. Sin embargo, si inicias minio indicando m\u00faltiples targets, se activar\u00e1 autom\u00e1ticamente el modo Erasure Coding, que distribuir\u00e1 los datos entre tus targets garantizando resistencia a fallos.<\/p>\n

Por defecto, minio divide los objetivos en grupos de 16 discos, donde cada grupo tiene 2 paridades. Es decir, dos discos pueden fallar simult\u00e1neamente sin p\u00e9rdida de datos.<\/p><\/blockquote>\n

Para probar el rendimiento, utilic\u00e9 16 discos de 6TB cada uno y escrib\u00ed en ellos peque\u00f1os objetos de 1MB, lo cual describ\u00eda con precisi\u00f3n nuestra carga futura, ya que todas las herramientas modernas de respaldo dividen los datos en bloques de varios megabytes y los escriben de esa manera.<\/p>\n

<\/p>\n

Para realizar el benchmark se utiliz\u00f3 la herramienta s3bench ejecutada en un servidor remoto, que envi\u00f3 a minio decenas de miles de tales objetos en cien hilos. Luego intent\u00f3 solicitarlos de la misma manera.<\/p>\n

<\/p>\n

Los resultados del benchmark se presentan en la siguiente tabla:<\/p>\n

<\/p>\n

\"Almacenamiento<\/p>\n

<\/p>\n

Como podemos ver, minio en modo propio de erasure coding trabaja significativamente peor en escritura que minio ejecutado sobre RAID6, RAIDZ2 y DRAID2 en la misma configuraci\u00f3n.<\/p>\n

<\/p>\n

Me pidieron<\/a><\/noindex> probar minio en ext4 vs XFS. Sorprendentemente, para mi tipo de carga, XFS result\u00f3 ser significativamente m\u00e1s lento que ext4.<\/p>\n

<\/p>\n

En la primera serie de pruebas, Mdadm mostr\u00f3 superioridad sobre ZFS, pero luego gmelikov<\/a><\/noindex> sugiri\u00f3<\/a><\/noindex>, que se puede mejorar el rendimiento de ZFS instalando las siguientes opciones:<\/p>\n

<\/p>\n

xattr=sa atime=off recordsize=1M<\/code><\/pre>\n
<\/p>\n
y despu\u00e9s de eso, las pruebas con ZFS fueron mucho mejores.<\/p>\n
<\/p>\n
Tambi\u00e9n se puede notar que DRAID no proporciona una ventaja significativa en rendimiento sobre RAIDZ, pero en teor\u00eda deber\u00eda ser mucho m\u00e1s seguro.<\/p>\n
<\/p>\n
En las \u00faltimas dos pruebas tambi\u00e9n intent\u00e9 mover los metadatos (special) y ZIL (log) a un espejo de SSD. Sin embargo, mover los metadatos no proporcion\u00f3 una ventaja significativa en velocidad de escritura, y al mover ZIL mis SSDSC2KI128G8<\/a><\/noindex> se encontraron con un l\u00edmite del 100% de utilizaci\u00f3n, por lo que considero que esta prueba ha sido fallida. No descarto que si hubiera tenido discos SSD m\u00e1s r\u00e1pidos, podr\u00eda haber mejorado significativamente mis resultados, pero, desafortunadamente, no los tuve.<\/p>\n
<\/p>\n
En conclusi\u00f3n, decid\u00ed detenerme en el uso de DRAID y, a pesar de su estado beta, es la soluci\u00f3n m\u00e1s r\u00e1pida y efectiva para el almacenamiento en nuestro caso.<\/p>\n
<\/p>\n
Cre\u00e9 un DRAID2 sencillo en una configuraci\u00f3n con tres grupos y dos spares distribuidos:<\/p>\n
<\/p>\n
# zpool status data\n  pool: data\n state: ONLINE\n  scan: none requested\nconfig:\n\n    NAME                 STATE     READ WRITE CKSUM\n    data                 ONLINE       0     0     0\n      draid2:3g:2s-0     ONLINE       0     0     0\n        sdy              ONLINE       0     0     0\n        sdam             ONLINE       0     0     0\n        sdf              ONLINE       0     0     0\n        sdau             ONLINE       0     0     0\n        sdab             ONLINE       0     0     0\n        sdo              ONLINE       0     0     0\n        sdw              ONLINE       0     0     0\n        sdak             ONLINE       0     0     0\n        sdd              ONLINE       0     0     0\n        sdas             ONLINE       0     0     0\n        sdm              ONLINE       0     0     0\n        sdu              ONLINE       0     0     0\n        sdai             ONLINE       0     0     0\n        sdaq             ONLINE       0     0     0\n        sdk              ONLINE       0     0     0\n        sds              ONLINE       0     0     0\n        sdag             ONLINE       0     0     0\n        sdi              ONLINE       0     0     0\n        sdq              ONLINE       0     0     0\n        sdae             ONLINE       0     0     0\n        sdz              ONLINE       0     0     0\n        sdan             ONLINE       0     0     0\n        sdg              ONLINE       0     0     0\n        sdac             ONLINE       0     0     0\n        sdx              ONLINE       0     0     0\n        sdal             ONLINE       0     0     0\n        sde              ONLINE       0     0     0\n        sdat             ONLINE       0     0     0\n        sdaa             ONLINE       0     0     0\n        sdn              ONLINE       0     0     0\n        sdv              ONLINE       0     0     0\n        sdaj             ONLINE       0     0     0\n        sdc              ONLINE       0     0     0\n        sdar             ONLINE       0     0     0\n        sdl              ONLINE       0     0     0\n        sdt              ONLINE       0     0     0\n        sdah             ONLINE       0     0     0\n        sdap             ONLINE       0     0     0\n        sdj              ONLINE       0     0     0\n        sdr              ONLINE       0     0     0\n        sdaf             ONLINE       0     0     0\n        sdao             ONLINE       0     0     0\n        sdh              ONLINE       0     0     0\n        sdp              ONLINE       0     0     0\n        sdad             ONLINE       0     0     0\n    spares\n      s0-draid2:3g:2s-0  AVAIL   \n      s1-draid2:3g:2s-0  AVAIL   \n\nerrors: No known data errors<\/code><\/pre>\n
Bien, ya hemos resuelto el almacenamiento, ahora hablemos de lo que vamos a utilizar para el respaldo. Aqu\u00ed quiero hablar de tres soluciones que logr\u00e9 probar, que son:<\/p>\n
<\/p>\n
Benji Backup<\/a><\/noindex><\/strong> \u2014 un fork Backy2<\/a><\/noindex>, soluci\u00f3n especializada para la copia de seguridad de dispositivos de bloques, tiene una integraci\u00f3n estrecha con Ceph. Puede recoger las diferencias entre instant\u00e1neas y formar un respaldo incremental a partir de ellas. Soporta una gran cantidad de nodos de almacenamiento, tanto locales como S3. Requiere una base de datos separada para almacenar la tabla hash de desduplicaci\u00f3n. Entre sus desventajas: est\u00e1 escrito en Python y tiene un CLI algo poco receptivo.<\/p>\n
<\/p>\n
Borg Backup<\/a><\/noindex><\/strong> \u2014 un fork Attic<\/a><\/noindex>, un medio bien conocido y confiable para la copia de seguridad, puede respaldar datos y los deduplica de manera eficiente. Puede guardar copias de seguridad tanto localmente como en un servidor remoto a trav\u00e9s de scp. Puede respaldar dispositivos de bloques si se ejecuta con la bandera --special<\/code>, entre sus desventajas: al crear una copia de seguridad, se bloquea completamente el repositorio, por lo que se recomienda crear un repositorio separado para cada m\u00e1quina virtual. En principio, esto no es un problema, ya que se crean con mucha facilidad.<\/p>\n
<\/p>\n
Restic<\/a><\/noindex><\/strong> \u2014 un proyecto en activo desarrollo, escrito en Go, es bastante r\u00e1pido y soporta una gran cantidad de backends de almacenamiento, incluyendo almacenamiento local, scp, S3 y muchos m\u00e1s. Es importante destacar que hay un rest-server<\/a><\/noindex> para restic, que permite exportar el almacenamiento de manera m\u00e1s r\u00e1pida para uso remoto. De todos los anteriores, me gust\u00f3 m\u00e1s. Puede respaldo desde stdin. No tiene desventajas notables, pero hay algunas peculiaridades:<\/p>\n
<\/p>\n