Data Domain : Pratiques d’excellence pour la réplication de répertoires et de pools

Pratiques d’excellence en matière de réplication de répertoire

OBJECTIF

Cet article définit les pratiques d’excellence de configuration de la réplication de répertoire.

S’APPLIQUE À

• Tous les systèmes Data Domain
• Toutes les versions du logiciel

RECOMMANDATIONS

1. Répartissez la charge applicative dans autant de contextes que possible.
   Le débit précompressé à contexte unique idéal est de l’ordre de 200 à 300 Mo/s. Dans les configurations où le multistreaming est disponible, les performances idéales en contexte unique sont similaires aux performances idéales en multicontexte. Cependant, plusieurs variables limitent l’efficacité du multistreaming :

   • Si le DDR source possède de nombreux contextes de réplication, la logique de division des flux multistreaming entre les contextes limite le nombre de flux disponibles.
   • Le multistreaming n’est pas actif pendant l’initialisation/restauration basée sur des snapshots. Par défaut, une initialisation basée sur des snapshots est effective si le contexte source comporte plus d’un million d’entrées.
   • À partir de la version 5.0, le multistreaming a été introduit pour la réplication des données CIFS.

   Le débit précompressé multicontexte idéal par modèle varie d’environ 200 Mo/s à 500 Mo/s ou plus.

2. Concevez la charge applicative avec des fichiers de taille modérée.
   La taille du fichier peut avoir un impact significatif sur les performances globales de tout contexte de réplication. En général, les fichiers dont la taille est inférieure à 10 Mo ne peuvent pas être répliqués efficacement.

   En outre, lorsqu’une paire de réplication se reconnecte après une déconnexion inattendue, la source doit redémarrer à partir du début du fichier qui était en cours de réplication lors de la déconnexion. Si le fichier est très volumineux et qu’il y a des déconnexions fréquentes (par exemple, en raison d’un réseau peu fiable), la réplication peut effectivement être « bloquée ». essayer de répliquer le même fichier encore et encore. Cela se produit le plus souvent avec les fichiers dont la taille dépasse 100 Go. Il n’y a aucune incidence sur les performances en raison de la taille du fichier lui-même.

3. Concevez la charge applicative pour tirer parti de la planification de la réplication.
   Les fichiers sont mis en file d’attente pour réplication lorsqu’ils sont fermés en interne. Le moment de fermeture du fichier est le suivant :

   Lorsqu’un fichier modifié est fermé, un enregistrement « close » du journal de réplication est généré pour le fichier. La réplication met en file d’attente les nouvelles données du fichier en vue de leur envoi. S’il n’y a pas d’autres opérations de réplication en avant dans la file d’attente (c’est-à-dire des enregistrements de log non traités), les nouvelles données sont immédiatement envoyées. Dans le cas contraire, le fichier sera répliqué après le traitement des enregistrements de journaux précédents.

   • 10 minutes après le dernier accès, NFS ferme le fichier.
   • Tous les fichiers sont fermés toutes les heures, quelle que soit la date à laquelle ils ont été écrits.
   • Si de nombreux fichiers sont consultés ou écrits, les fichiers peuvent être fermés plus tôt que ne l’exigent les règles ci-dessus. Le logiciel de sauvegarde qui écrit des fichiers dans des fragments plus petits (par exemple, 1 Mo) peut entraîner un démarrage plus rapide de la réplication en raison du nombre de fichiers générés.

4. Utilisez un réseau dédié si possible.
   Des taux de perte de paquets aussi bas que 0,1 % peuvent gravement dégrader le débit du réseau, en particulier pour les réseaux à haut délai de bande passante. Pour les réseaux avec bande passante <= T2, le RTT (Round-Trip Time) jusqu’à une seconde fournit un bon débit. Pour les réseaux de >= T3, il y a une dégradation significative du débit à partir d’un RTT de 300 à 500 ms.

   Plus généralement, le débit sous perte de paquets est approximativement
   Throughput = MSS /(RTT * sqrt(p)) où MSS := taille minimale du segment (typiquement 1460 octets) RTT := temps aller-retour p := probabilité de perte de paquets

5. Évaluer la réplication delta (optimisation de bande passante faible).
   Dans DD OS 4.8 et versions ultérieures, la réplication delta, également appelée « optimisation à faible bande passante », peut augmenter le débit virtuel de réplication de répertoire ou de pool sur des liaisons avec moins de 6 mégabits par seconde (Mbit/s) de bande passante disponible. La réplication delta entraîne une surcharge de processeur et d’E/S supplémentaire importante sur les systèmes Data Domain source et cible. Si l’optimisation des faibles bandes passantes est activée sur les liaisons dont la bande passante est supérieure à 6 Mbit/s, il est peu probable que le débit virtuel progresse. D’une manière générale, si :

   • Les données à répliquer sont identiques à moins de 96 % aux données déjà présentes sur le système de destination
   • La bande passante disponible est inférieure à 6 Mbit/s.
   • Les deux systèmes disposent d’un processeur et d’une capacité d’E/S de secours

     L’optimisation des faibles bandes passantes doit être activée. Surveillez la sortie de « replication show history » sur plusieurs semaines. Le rapport « Low-bw-optim » doit être en moyenne de 2,00 ou plus, et le débit réseau (octets de réseau divisés par intervalle de temps) ne doit pas être inférieur à la bande passante disponible. Si la moyenne du ratio « Low-bw-optim » n’est pas supérieure ou égale à 2,00, la compression delta n’est probablement pas efficace sur le jeu de données et doit être désactivée. Si le débit réseau est nettement inférieur à la bande passante disponible, il est fort probable que l’un des systèmes Data Domain, ou les deux, ne disposent pas de suffisamment de CPU ou de capacité d’E/S de secours pour prendre en charge la réplication delta, et qu’il faille le désactiver.

6. Suivez les pratiques d’excellence pour les autres composants et applications de sauvegarde tierces.
   Nos guides de pratiques d’excellence sont rédigés dans une optique de performances globales. Les écarts par rapport aux pratiques d’excellence suggérées par Data Domain peuvent avoir des incidences importantes sur les performances dans plusieurs domaines, même si cela ne semble pas évident immédiatement.

DOCUMENTATION

Dépannage de la latence de réplication 180482