Echecs de réplication
Les mises à jour de réplication individuelles peuvent échouer pour différentes raisons. Lorsque c'est possible, l'appareil signale la raison de l'échec de l'action dans les alertes publiées sur l'appareil source ou cible, ou dans l'écran Réplication. Vous pouvez obtenir des détails sur l'échec en cliquant sur l'icône d'alerte orange représentant le statut de l'action.
Les types d'échecs de réplication suivants sont les plus courants :
|
|
|
Annulée
|
La mise à jour de réplication a été annulée par un administrateur. La réplication peut être annulée sur la source ou la cible.
|
|
Panne de connectivité réseau
|
L'appareil n'a pas pu se connecter à l'appareil cible en raison d'un problème réseau. Il existe peut-être une erreur de configuration sur la source, la cible ou le réseau.
|
|
Echec de la vérification du pair
|
L'appareil n'est pas parvenu à vérifier l'identité de la source. Cela se produit généralement lorsque la cible a été réinstallée ou que ses paramètres d'usine ont été rétablis. Il faut configurer une nouvelle cible de réplication sur l'appareil source pour une cible qui a été réinstallée ou dont les paramètres d'usine ont été rétablis afin de générer un nouveau jeu de clés d'authentification. Reportez-vous à la section Cibles de réplication. |
|
Echec du RPC du pair
|
Un appel de procédure distante sur le système cible a échoué. Cela se produit généralement lorsque l'appareil cible exécute un logiciel incompatible.
|
|
Collision de noms
|
La réplication de <project/share> depuis <source> échoue en raison d'une collision de noms avec @<snapname> qui est conservé sur la cible pour NDMP. Pour effectuer une récupération, renommez (ou supprimez) l'instantané sur la source de réplication dont le nom est identique à celui de l'instantané conservé par NDMP sur la cible (celui nommé dans l'alerte), à moins qu'il ne commence par .rr. Puis effectuez une synchronisation manuelle ou autorisez la source de réplication à retenter automatiquement la mise à jour de réplication.
|
|
Aucun package
|
La réplication a échoué car aucun package n'existe sur la cible pour accueillir les données répliquées. Etant donné que le package est créé après avoir configuré l'action, l'erreur se produit généralement après qu'un administrateur a supprimé le package sur la cible. Cette erreur peut également se produire si le pool de stockage n'est pas importé sur le système cible, ce qui peut arriver si le pool est défectueux ou si le stockage ou la mise en réseau a été reconfiguré(e) sur l'appareil cible.
|
|
Un package non vide est présent
|
La réplication a échoué car le package cible contient des données d'une précédente mise à jour de réplication qui a échoué. Cette erreur se produit lors d'une tentative d'envoi d'une mise à jour de réplication pour une action dont la première mise à jour de réplication a échoué après la réplication d'une partie des données. L'appareil cible ne supprimant pas les données sans ordre explicite de l'administrateur, les données partiellement reçues ne sont pas écrasées. L'administrateur doit supprimer l'action et le package existants et créer une nouvelle action sur la source, puis relancer la réplication.
|
|
Désactivé
|
La réplication a échoué car elle est désactivée sur la cible. Soit le service de réplication est désactivé sur la cible, soit la réplication a été désactivée pour le package spécifique étant répliqué.
|
|
Cible occupée
|
La réplication a échoué car le système cible a atteint le nombre maximal de mises à jour de réplication simultanées. Le système limite le nombre maximal d'opérations de réplication en cours afin d'éviter la saturation des ressources. Lorsque cette limite est atteinte, les tentatives ultérieures de réception de mises à jour échouent et indiquent cette erreur, tandis que les tentatives d'envoi de mises à jour sont mis en attente jusqu'à ce que les ressources soient disponibles.
|
|
Espace saturé
|
La réplication a échoué car le système source ne disposait pas d'espace suffisant pour créer un nouvel instantané. Cela peut être causé par l'absence d'espace physique disponible sur le pool de stockage, ou car le projet ou un de ses partages dépasse des quotas en raison de réservations qui ne comprennent pas les instantanés.
|
|
Indisponibilité de clés
|
La réplication a échoué car la clé de chiffrement utilisée par le partage n'est pas disponible, soit sur le système source soit sur le système cible. Passez les alertes en revue sur les deux systèmes, source et cible, afin de vous assurer que la clé est disponible sur les deux systèmes. Reportez-vous à la section Réplication d'un partage chiffré pour plus d'informations sur la réplication de projets et de partages chiffrés. |
|
Cible incompatible
|
La réplication a échoué car le système cible ne peut pas recevoir le format de flux du système source. Cela peut se produire consécutivement à la mise à niveau d'un système source et à l'application de mises à jour différées sans avoir mis à niveau et appliqué les mêmes mises à jour sur la cible. Consultez les notes de version du logiciel du système à propos des mises à jour différées et de leurs éventuelles implications pour la réplication distante.
|
|
Initiateur/cible iSCSI manquant(e)
|
L'opération de clone, de dissociation ou d'inversion de réplication a échoué car les LUN de groupe d'initiateurs ou de groupe cible n'existent pas pour les LUN inclus dans le package de réplication. Le nom du groupe cible ou d'initiateurs a été supprimé ou modifié sur le système cible.
|
|
Divers
|
La réplication a échoué, mais aucune information supplémentaire n'est disponible sur la source. Consultez le journal d'alertes sur le système cible et si nécessaire, contactez le support pour obtenir une assistance. Certains modes d'erreur qui entrent dans cette catégorie comprennent l'espace disque insuffisant pour recevoir la mise à jour et la tentative de réplication d'un clone dont l'instantané d'origine n'existe pas sur le système cible.
|
|
Une mise à jour de réplication échoue si une partie de la mise à jour échoue. L'implémentation actuelle réplique en série les partages au sein d'un projet et n'annule pas les modifications des mises à jour ayant échoué. Par conséquent, lorsqu'une mise à jour échoue, il est possible que certains partages sur la cible soient à jour, et que d'autres non. Pour plus d'informations, reportez-vous à la section Instantanés de réplication et cohérence des données.
Bien que certaines données aient été répliquées avec succès dans le cadre d'une mise à jour ayant échoué, l'implémentation actuelle renvoie toutes les données envoyées dans la précédente mise à jour (en échec). Concrètement, les mises à jour ayant échoué ne reprennent pas là où elles se sont arrêtées, mais démarrent là ou la mise à jour qui a échoué a commencé.
Lorsque la réplication en continu ou planifiée échoue, le système attend plusieurs minutes puis effectue une nouvelle tentative. Le système continue a réessayer indéfiniment les réplications en continu ou planifiées. A tout moment pendant la procédure de nouvel essai, lancer une mise à jour manuelle commence immédiatement un nouvel essai, le délai habituel entre les nouveaux essais n'étant pas observé. Si la mise à jour manuelle réussit, elle met fin à la séquence des nouveaux essais et l'action de réplication retrouve ses mises à jour planifiées ou en continu. Les réplications manuelles ayant échoué sans action de réplication planifiée préalable ne font pas l'objet d'un nouvel essai.
Lorsqu'une mise à jour de réplication est en cours et qu'une autre est programmée, cette dernière est retardée jusqu'à la fin de la mise à jour précédente et une alerte est émise.
Rubriques connexes