Synchronisation ZFS sur un WAN lent et peu fiable. Réplication ZFS ou rsync?


10

J'ai été chargé de faire une sauvegarde hors site sur le WAN. Les deux boîtiers de stockage sont des boîtiers NAS basés sur FreeBSD exécutant ZFS.

Une à deux fois par semaine, 15 à 60 concerts de données photographiques sont transférés sur le NAS du bureau. Mon travail consiste à comprendre comment obtenir ces données hors site de la manière la plus fiable possible en utilisant la connexion DSL TRÈS LENTE (envoi de ~ 700 Ko / s). La boîte de réception est en bien meilleure forme, à 30 Mo / s en bas, 5 Mo / s en haut.

Je sais, transporter un disque dur hors site déplacerait les données beaucoup plus rapidement, mais ce n'est pas une option dans ce cas.

Mes options semblent être soit:

  • Envoi incrémentiel ZFS sur ssh
  • Rsync

rsync est une solution qui a fait ses preuves et a la capacité primordiale de reprendre un envoi si quelque chose est interrompu. Il a l'inconvénient d'itérer sur de nombreux fichiers et de ne pas connaître la déduplication.

L'envoi d'instantanés ZFS peut transférer un peu moins de données (il en sait beaucoup plus sur le système de fichiers, peut faire la déduplication, peut regrouper les changements de métadonnées plus efficacement que rsync) et a l'avantage de dupliquer correctement l'état du système de fichiers, plutôt que de simplement copier fichiers individuellement (ce qui est plus gourmand en disque).

Je suis préoccupé par les performances de réplication ZFS [1] (bien que cet article date d'un an). Je m'inquiète également de pouvoir redémarrer le transfert si quelque chose tombe en panne - la capacité d'instantané ne semble pas inclure cela. L'ensemble du système doit être complètement mains libres.

[1] http://wikitech-static.wikimedia.org/articles/z/f/s/Zfs_replication.html

En utilisant l'une ou l'autre option, je devrais être en mesure de dé-prioriser le trafic en le routant via un port spécifié, puis en utilisant le QOS sur les routeurs. Je dois éviter un impact négatif majeur sur les utilisateurs des deux sites lors de chaque transfert, car cela prendra plusieurs jours.

Alors ... c'est ma pensée sur la question. Ai-je manqué de bonnes options? Quelqu'un d'autre a-t-il créé quelque chose de similaire?


Considérez Unison .
sampablokuper

Réponses:


8
  1. Si vous pouvez transférer un maximum de 6 Go par jour (en supposant zéro frais généraux et zéro trafic concurrent) et que vous devez déplacer "15-60 concerts" à une fréquence de "une ou deux fois par semaine", cela équivaut à 15-120 Go par semaine ou de 2 à 17 Go par jour. Étant donné qu'il est nécessaire de planifier une demande de pointe et que 17 Go dépassent de loin même votre maximum théorique de 6 Go, il est probable que vous ayez un problème de bande passante très grave. Que faut-il pour mettre à niveau la connexion? Si la mise à niveau de la connexion est impossible, veuillez envisager la possibilité d'envoyer des supports physiques sur une base planifiée (par exemple hebdomadaire).

  2. En supposant que vous pouvez obtenir les calculs de bande passante pour avoir un peu plus de sens, rsync est probablement la meilleure option. La sensibilisation à la déduplication serait extrêmement précieuse lors de la réplication de données hautement redondantes (par exemple, les images de machines virtuelles), mais elle devrait avoir peu ou pas d'avantages en ce qui concerne le contenu numérique unique (audio, vidéo, photos) ... à moins, bien sûr, que les utilisateurs ne soient stocker par inadvertance des copies en double de fichiers identiques.


Je pense que je peux utiliser la bande passante disponible, et la plupart des vidages de données tendent vers l'extrémité la plus petite de la plage. Pratiquement, ça va être environ 2-3 concerts par jour en moyenne, à en juger par un mois de données. Je n'ai pas besoin de la réplication immédiatement.
Paul McMillan

Et oui, l'envoi de supports physiques par courrier électronique est bien meilleur ... J'aimerais que ce soit une option.
Paul McMillan

Bon point sur la déduplication. La plupart de ce qui est copié ne sera pas dupliqué - les utilisateurs ne sont pas aussi denses.
Paul McMillan

1
La seule chose que j'ajouterais est peut-être de ne pas utiliser rsync. J'ai moi aussi connu la lenteur de rsync car je l'utilisais comme processus de transfert, pas de processus de synchronisation. Ensuite, j'ai réalisé que la plupart de mes données existantes n'avaient pas changé et que seules les nouvelles données devaient être copiées, pour moi, j'ai utilisé cp uniquement sur les nouveaux fichiers et c'était beaucoup plus rapide. Si j'avais des fichiers modifiés (ou seulement des parties de fichiers), j'utiliserais rsync. Je suggère donc de séparer les nouveaux fichiers et de choisir une méthode de transfert pouvant être reprise. En outre, la compression serait un compromis CPU & RAM / bande passante (aux deux extrémités).
Scott McClenning du

Hmm ... J'ai lu qu'avec une configuration correcte, rsync peut être fait pour aller assez rapidement. Quelle optimisation avez-vous tenté?
Paul McMillan

13

Après avoir fait quelques recherches, je pense que vous avez raison d'envoyer des instantanés. Le ZFS SENDet les RECEIVEcommandes peuvent être canalisés dans bzip2, puis ce fichier peut être rsync-ed sur l'autre machine.

Voici quelques sources que j'ai utilisées:

Je n'avais trouvé aucun message avec des scripts de réplication publiés, mais j'ai trouvé quelqu'un qui a publié leur script de sauvegarde . Cela dit, je ne l'ai pas compris, donc ça peut être de la camelote.

De nombreux sites Web parlaient de la mise en place d'un travail cron pour le faire fréquemment. Si tel est le cas, vous pouvez répliquer / sauvegarder avec moins d'impact sur la bande passante et les utilisateurs et être une bonne fonction de récupération après sinistre car les données hors site sont plus à jour. (C'est-à-dire après le bloc de données initial lors du démarrage.)

Encore une fois, je pense que vous avez eu la bonne idée d'envoyer des instantanés, il semble y avoir beaucoup d'avantages à utiliser SEND/ RECEIVE.

EDIT: Je viens de regarder une vidéo1 vidéo2 qui peut aider à utiliser SEND/ RECEIVEet parler de rsync (commence à 3 min 49 s). Ben Rockwood était le conférencier et voici un lien vers son blog .


1
Je suppose que l'utilisation de rsync est limitée à la fonctionnalité pause / reprise, plutôt que le fichier réel diffère. Cela a du sens, car le système de fichiers lui-même (et les fichiers de modifications qu'il génère) sait mieux que rsync ce qui se passe.
Paul McMillan

Remarque supplémentaire: ZSTD, un remplacement plus rapide et moderne pour gzip et bzip, prend en charge plusieurs threads et plus de 20 niveaux de compression. Il dispose également d'une fonctionnalité optionnelle appelée «compression adaptative». Avec ce mode, le niveau de compression est automatiquement réglé de haut en bas selon les besoins pour garder le tube réseau plein, tout en faisant autant de compression que possible pour gagner du temps. Cela vous empêche de faire tellement de compression que cela devient un goulot d'étranglement, ou de manquer la compression que vous pourriez faire parce que le réseau est trop lent.
Allan Jude

2

Quel est le but des sauvegardes et comment devront-elles être accessibles?

Si vos sauvegardes sont principalement destinées à la récupération après sinistre, les instantanés ZFS peuvent être préférables, car vous pourrez remettre un système de fichiers dans son état exact au moment de la dernière incrémentation.

Cependant, si vos sauvegardes sont également censées fournir aux utilisateurs un accès à des fichiers qui pourraient avoir été accidentellement supprimés, corrompus, etc., alors rsync pourrait être une meilleure option. Les utilisateurs finaux peuvent ne pas comprendre le concept des instantanés ou peut-être que votre NAS ne permet pas aux utilisateurs finaux d'accéder aux instantanés précédents. Dans les deux cas, vous pouvez utiliser rsync pour fournir une sauvegarde facilement accessible à l'utilisateur via le système de fichiers.

Avec rsync, vous pouvez utiliser l'indicateur --backup pour conserver les sauvegardes des fichiers qui ont été modifiés, et avec l'indicateur --suffix, vous pouvez contrôler la façon dont les anciennes versions des fichiers sont renommées. Cela facilite la création d'une sauvegarde où vous pourriez avoir daté d'anciennes versions de fichiers comme

file_1.jpg
file_1.jpg.20101012
file_1.jpg.20101008
etc.

Vous pouvez facilement combiner cela avec un cronjob contenant une commande find pour purger tous les anciens fichiers selon vos besoins.

Les deux solutions devraient être en mesure de conserver suffisamment de métainformations sur les fichiers pour fonctionner comme une sauvegarde (rsync fournit des indicateurs --perms, --owner, etc.). J'utilise rsync pour sauvegarder de grandes quantités de données entre les centres de données et je suis très satisfait de la configuration.


2

ZFS devrait recevoir la fonction «envoi de reprise», qui permettra de poursuivre une réplication interrompue vers le mois de mars de cette année. La fonctionnalité a été complétée par Matt Ahrens et quelques autres personnes, et devrait être mise en ligne prochainement.


Juste une note que «l'envoi de reprise» est dans OpenZFS (sur FreeBSD, Linux, MacOS, etc.) depuis un certain temps maintenant. Il existe également une fonction «d'envoi compressé», où les données resteront compressées telles qu'elles se trouvent sur le disque, dans le cadre du flux de réplication.
Allan Jude

0

Peut-être que le périphérique de compression WAN serait une solution ...? nous utilisons Riverbed et nous en sommes très satisfaits (par exemple, NetApp SnapMirror est très bien compressé, jusqu'à 80-90%)

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.