Tengo un grupo de zfs que contiene varios zvols y conjuntos de datos, algunos de los cuales también están anidados. Todos los conjuntos de datos y zvols se capturan periódicamente mediante zfs-auto-snapshot. Todos los conjuntos de datos y zvols también tienen algunas instantáneas creadas manualmente.
He configurado un grupo remoto en el que, debido a la falta de tiempo, la copia inicial a través de la red local de alta velocidad a través de zfs send -R no se completó (faltan algunos conjuntos de datos, algunos conjuntos de datos tienen instantáneas desactualizadas o faltantes).
Ahora el grupo es físicamente remoto a través de una conexión de baja velocidad y necesito sincronizar periódicamente el grupo remoto con el grupo local, lo que significa que los datos presentes en el grupo local deben copiarse al grupo remoto, los datos que salen del grupo local deben eliminarse del grupo remoto y los datos presentes en el grupo remoto pero no en el grupo local deben eliminarse del grupo remoto, donde los datos significan "zvols", "conjuntos de datos" o "instantáneas".
Si estuviera haciendo esto entre dos sistemas de archivos normales usando rsync, sería "-axPHAX --delete" (eso es lo que realmente hago para hacer copias de seguridad de algunos sistemas).
¿Cómo configuro una tarea de sincronización para que los zvols y conjuntos de datos del grupo remoto (incluidas sus instantáneas) puedan sincronizarse con los zvols, conjuntos de datos e instantáneas locales?
Me gustaría evitar la transferencia a través de ssh, debido al bajo rendimiento de ssh; Preferiría mbuffer o iscsi.
Respuesta1
Descargo de responsabilidad: Como nunca he usado zvols, no puedo decir si son diferentes en replicación que los sistemas de archivos o instantáneas normales. Supongo que sí, pero no confíe en mi palabra.
Su pregunta en realidad son varias preguntas, trato de responderlas por separado:
Cómo replicar/duplicar un grupo completo en una ubicación remota
Debe dividir la tarea en dos partes: primero, la replicación inicial debe estar completa, luego es posible la replicación incremental.siempre y cuando no te metas con tus instantáneas de replicación. Para habilitar la replicación incremental, debe conservar las últimas instantáneas de replicación; todo lo anterior se puede eliminar. Si elimina la instantánea anterior, zfs recvse quejará y abortará la replicación. En este caso tendrás que empezar de nuevo, así que intenta no hacerlo.
Si solo necesita las opciones correctas, son:
zfs send:-R: envía todo lo que se encuentra en el grupo o conjunto de datos determinado (replicación recursiva, necesaria todo el tiempo, incluye-p). Además, al recibirlas, todas las instantáneas de origen eliminadas se eliminan en el destino.-I: incluye todas las instantáneas intermedias entre la última instantánea de replicación y la instantánea de replicación actual (solo es necesaria con envíos incrementales)
zfs recv:-F: amplía el grupo de destino, incluida la eliminación de conjuntos de datos existentes que se eliminan en el origen-d: descarte el nombre del grupo de origen y reemplácelo con el nombre del grupo de destino (el resto de las rutas del sistema de archivos se conservarán y, si es necesario, también se crearán)-u: no montar el sistema de archivos en el destino
Si prefieres un ejemplo completo, aquí tienes un pequeño script:
#!/bin/sh
# Setup/variables:
# Each snapshot name must be unique, timestamp is a good choice.
# You can also use Solaris date, but I don't know the correct syntax.
snapshot_string=DO_NOT_DELETE_remote_replication_
timestamp=$(/usr/gnu/bin/date '+%Y%m%d%H%M%S')
source_pool=tank
destination_pool=tank
new_snap="$source_pool"@"$snapshot_string""$timestamp"
destination_host=remotehostname
# Initial send:
# Create first recursive snapshot of the whole pool.
zfs snapshot -r "$new_snap"
# Initial replication via SSH.
zfs send -R "$new_snap" | ssh "$destination_host" zfs recv -Fdu "$destination_pool"
# Incremental sends:
# Get old snapshot name.
old_snap=$(zfs list -H -o name -t snapshot -r "$source_pool" | grep "$source_pool"@"$snapshot_string" | tail --lines=1)
# Create new recursive snapshot of the whole pool.
zfs snapshot -r "$new_snap"
# Incremental replication via SSH.
zfs send -R -I "$old_snap" "$new_snap" | ssh "$destination_host" zfs recv -Fdu "$destination_pool"
# Delete older snaps on the local source (grep -v inverts the selection)
delete_from=$(zfs list -H -o name -t snapshot -r "$source_pool" | grep "$snapshot_string" | grep -v "$timestamp")
for snap in $delete_from; do
zfs destroy "$snap"
done
Utilice algo más rápido que SSH
Si tiene una conexión suficientemente segura, por ejemplo un túnel IPSec u OpenVPN y una VLAN separada que solo existe entre el remitente y el receptor, puede cambiar de SSH a alternativas no cifradas como mbuffer.como se describe aquí, o podría usar SSH con cifrado débil o sin cifrado y compresión deshabilitada,que se detalla aquí. También había un sitio web sobre cómo volver a compilar SSH para que sea mucho más rápido, pero desafortunadamente no recuerdo la URL; la editaré más tarde si la encuentro.
Para conjuntos de datos muy grandes y conexiones lentas, también puede resultar útil realizar la primera transmisión a través del disco duro (use un disco cifrado para almacenar zpool y transmitirlo en un paquete sellado mediante mensajería, correo postal o en persona). Como el método de transmisión no importa para envío/recepción, puede canalizar todo al disco, exportar el grupo, enviar el disco a su destino, importar el grupo y luego transmitir todos los envíos incrementales a través de SSH.
El problema de las instantáneas desordenadas
Como se indicó anteriormente, si elimina/modifica sus instantáneas de replicación, recibirá el mensaje de error
cannot send 'pool/fs@name': not an earlier snapshot from the same fs
lo que significa que su comando fue incorrecto o que se encuentra en un estado inconsistente en el que debe eliminar las instantáneas y comenzar de nuevo.
Esto tiene varias implicaciones negativas:
- No puede eliminar una instantánea de replicación hasta que la nueva instantánea de replicación se haya transferido correctamente. Como estas instantáneas de replicación incluyen el estado de todas las demás instantáneas (más antiguas), el espacio vacío de los archivos e instantáneas eliminados solo se recuperará si finaliza la replicación. Esto puede provocar problemas de espacio temporales o permanentes en su grupo que solo puede solucionar reiniciando o finalizando el procedimiento de replicación completo.
- Tendrá muchas instantáneas adicionales, lo que ralentiza el comando de lista (excepto en Oracle Solaris 11, donde esto se solucionó).
- Es posible que necesite proteger las instantáneas contra la eliminación (accidental), excepto mediante el propio script.
Existe una posible solución a esos problemas, pero yo no la he probado. Podría utilizar zfs bookmark, una nueva función en OpenSolaris/illumos creada específicamente para esta tarea. Esto le liberaría de la gestión de instantáneas. El único inconveniente es que en la actualidad solo funciona para conjuntos de datos únicos, no de forma recursiva. Tendría que guardar una lista de todos sus conjuntos de datos antiguos y nuevos y luego recorrerlos, marcarlos, enviarlos y recibirlos, y luego actualizar la lista (o una pequeña base de datos, si lo prefiere).
Si pruebas la ruta de los marcadores, ¡me interesaría saber cómo te funcionó!
Respuesta2
Personalmente, me haría una lista de zvols, conjuntos de datos, etc. en el servidor remoto quenotenga instantáneas actualizadas y luego actualice esas instantáneas con zfs send, incluso si esto lleva mucho tiempo y utiliza mucho ancho de banda.
Entonces podría seguir usándolo zfs senda partir de ese momento y no tener que reinventar la rueda escribiendo mi propio código de sincronización. rsynces bueno para sistemas de archivos más antiguos pero zfs sendes mucho mejor para zfs: sabeexactamentequé bloques han cambiado en la instantánea y envíasoloellos, mientras que rsync tiene que comparar archivos individuales y/o marcas de tiempo entre servidores locales y remotos. Lo mismo se aplica a btrfs sendlos grupos btrfs.
Si solo tiene una pequeña cantidad de instantáneas que deben actualizarse, esto puede hacerse manualmente. De lo contrario, para hacerlo automáticamente, necesita una lista de las últimas instantáneas locales frente a las instantáneas remotas y un script para comparar versiones y luego zfs sendinstantáneas locales que están desactualizadas en el servidor rmeote.
Eso será suficiente si solo le importa la última instantánea de cada conjunto de datos. Si le importan todas las instantáneas anteriores, obviamente su script tendrá que manejarlas también... y eso se vuelve MUCHO más complicado. En algunos casos, es posible que tenga que revertir el servidor remoto para poder volver a enviar las instantáneas intermedias o faltantes.
Si desea una conexión segura al servidor remoto, realmente no tiene más remedio que usarla ssh, o tal vez configurar un túnel con openvpnalgo así como usar netcat.
Respuesta3
Eche un vistazo a `zrepl', en FreeBSD, que podría hacer su vida, y la de cualquier persona, mucho más fácil. Fue presentado hace unos días durante el BSDCan2018 en Ottawa. Parece prometedor y puede ser una solución a sus problemas.
Respuesta4
zrep es una buena solución todo en uno, Y tiene documentación + enlaces sobre cómo obtener transferencias más rápidas que simplemente transferencias SSH
https://github.com/bolthole/zrep
También es multiplataforma: compatible con Linux, FreeBSD y Solaris/Illumos.