Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Reconstruction de répliques

Lorsque SUSE Storage détecte une réplique échouée ou supprimée, il initie automatiquement un processus de reconstruction. Ce document décrit le flux de travail de reconstruction de répliques pour le moteur de données v1, y compris les méthodes de reconstruction complètes, delta et rapides. Il explique également les limitations associées à chaque méthode.

La reconstruction ne commencera pas dans les scénarios suivants :

  • Le volume est en cours de migration vers un autre nœud.

  • Le volume est un ancien volume de restauration/DR.

  • Le volume s’agrandit.

Flux de travail de reconstruction de répliques

La reconstruction de répliques peut se produire dans les scénarios suivants pour le moteur de données v1 :

  • Un nœud est redémarré, vidé ou expulsé.

  • Une réplique devient non saine ou est supprimée.

Image

  1. Marquez la réplique cible avec le mode WO (écriture seule).

  2. Créez un nouvel instantané pour servir de point de référence pour l’intégrité des données du volume.

  3. Générez la liste des fichiers de synchronisation pour la tête du volume et les fichiers d’instantané.

Pour le moteur de données V1

  1. Démarrez un serveur récepteur sur la réplique cible pour chaque instantané.

  2. Instruisez la réplique source pour commencer la synchronisation des données.

    1. Pour chaque instantané :

      • Vérifiez si le fichier d’instantané existe dans le répertoire de données de la réplique cible.

        • Si non, transférez toutes les données de l’instantané de la réplique source vers la réplique cible. Reportez-vous à la page [_full_replica_rebuilding].

        • Si oui, vérifiez si les fichiers de somme de contrôle de l’instantané existent, et si l’heure de modification et les sommes de contrôle sont identiques entre les répliques cible et source.

          • Si oui, SUSE Storage saute le transfert des données de l’instantané. Cette optimisation réduit l’utilisation de l’UC, les E/S disque, les E/S réseau et le temps total de reconstruction. Reportez-vous à la page [_fast_replica_rebuilding].

          • Si non, SUSE Storage calcule et compare les sommes de contrôle au niveau des blocs en utilisant l’algorithme SHA-512. Si des incohérences sont trouvées, seuls les blocs différents sont synchronisés. Reportez-vous à la page [_delta_replica_rebuilding].

Pour le moteur de données V2

  1. Exposez les répliques source et cible et préparez une copie superficielle en utilisant le moteur SPDK.

  2. Pour chaque instantané :

    • Vérifiez si l’horodatage de l’instantané, la taille réelle et la somme de contrôle correspondent entre la source et la cible.

      • Si oui, SUSE Storage saute le transfert des données de cet instantané.

      • Si non, vérifiez si les instantanés source et cible contiennent des sommes de contrôle par plage.

        • Si oui, récupérez et comparez les sommes de contrôle par plage. Si des incohérences existent, seules les plages non concordantes sont copiées. Reportez-vous à la page [_fast_replica_rebuilding].

        • Si non, supprimez l’instantané cible existant. Ensuite, copiez l’intégralité de l’instantané de la réplique source vers la réplique cible. Reportez-vous à la page [_full_replica_rebuilding].

Reconstruction complète de répliques

Si la réplique est irrécupérable ou n’a pas de données existantes, SUSE Storage synchronise toutes les données d’une réplique saine. Elle reconstruit la réplique en transférant l’intégralité de la chaîne d’instantanés.

La reconstruction complète de la réplique consomme une bande passante réseau significative et entraîne de lourdes opérations d’écriture sur disque sur le nœud cible. Cependant, cela est nécessaire lorsque la réplique cible n’a pas de données utilisables.

Reconstruction Delta de répliques

La reconstruction Delta de répliques est réservée au moteur de données v1. Elle commence avec une réplique échouée réutilisable et vérifie l’intégrité des données pour tous les instantanés, bloc par bloc.

  • Ceci est disponible uniquement pour la réutilisation de répliques échouées, et il existe un fichier d’instantané (avec le même nom) dans le répertoire de données de la réplique échouée.

  • Lorsqu’un instantané n’a pas de somme de contrôle, SUSE Storage effectue la reconstruction de réplique delta pour cet instantané à la place.

  • Avantages :

    • Réduire la consommation de bande passante réseau.

  • Inconvénients :

    • Augmentation de la surcharge de l’UC car SUSE Storage va calculer la somme de contrôle des données de l’instantané bloc par bloc pour vérifier l’intégrité des données.

    • Le temps de reconstruction est influencé par les performances de l’UC.

Reconstruction rapide de réplique

La reconstruction rapide de réplique est activée lorsque les conditions suivantes sont remplies :

  • Le paramètre de reconstruction rapide de réplique est activé :

    fast-replica-rebuild-enabled: true

  • Des fichiers de somme de contrôle d’instantané sont créés (les sommes de contrôle sont pré-calculées) en utilisant l’une des méthodes suivantes :

    • snapshot-data-integrity est défini sur enabled : Un travail planifié calcule les sommes de contrôle pour tous les instantanés à un intervalle configuré (par défaut : 7 jours).

    • snapshot-data-integrity-immediate-check-after-snapshot-creation est défini sur true : La somme de contrôle de l’instantané est calculée immédiatement après la création de l’instantané.

Ces calculs de somme de contrôle consomment des ressources de stockage et de calcul. Le temps de calcul est imprévisible et peut avoir un impact négatif sur les performances de stockage. Pour plus d’informations, voir Intégrité des données de l’instantané.

  • Avantages :

    • Minimise la consommation de bande passante réseau.

    • Minimise les E/S disque.

  • Inconvénients :

    • Le calcul des sommes de contrôle des instantanés peut prendre du temps.

    • Le moment du calcul de la somme de contrôle est imprévisible. Cela peut être déclenché même sous une forte charge d’E/S.

Pour plus d’informations, voir Reconstruction rapide des répliques.

Facteurs qui affectent les performances de reconstruction

  • Tête de volume importante

    • Pourquoi c’est important : La tête de volume est un fichier spécial qui n’a jamais de somme de contrôle précalculée. Si une réplique échoue, SUSE Storage doit toujours synchroniser l’ensemble de la tête de volume. Une tête de volume plus grande augmente le temps de reconstruction.

    • Comment prévenir : Prenez des instantanés régulièrement pour réduire la taille de la tête de volume. Planifiez des instantanés avant une maintenance prévue pour minimiser le temps de reconstruction.

  • Aucun instantané n’existe

    • Pourquoi c’est important : Sans instantanés, SUSE Storage ne peut pas sauter le transfert de données ni réutiliser les données existantes. Si un instantané de tête de volume est créé mais que sa somme de contrôle n’est pas prête, SUSE Storage doit effectuer une reconstruction delta. Cela augmente l’utilisation de l’UC en raison des comparaisons de sommes de contrôle effectuées bloc par bloc.

    • Comment prévenir :

      1. Activez snapshot-data-integrity-immediate-check-after-snapshot-creation ou snapshot-data-integrity pour précalculer les sommes de contrôle. Compromis : Augmente l’utilisation de l’UC, des E/S disque et du stockage pendant le calcul.

      2. Utilisez un travail récurrent pour créer des instantanés régulièrement.

  • Instantané purgé

    • Pourquoi c’est important : Lorsque la purge des instantanés commence, les instantanés générés par le système sont fusionnés dans le prochain instantané. Cela invalide la somme de contrôle du prochain instantané.

    • Comment prévenir :

      1. Activez snapshot-data-integrity-immediate-check-after-snapshot-creation pour garantir que les sommes de contrôle sont calculées après la purge.

      2. Créez proactivement un instantané et laissez du temps pour la génération de la somme de contrôle avant d’effectuer des mises à niveau ou des reconstructions.

  • Reconstructions simultanées

    • Pourquoi c’est important : Exécuter plusieurs reconstructions sur le même nœud peut surutiliser l’UC, l’entrée/sortie disque et l’entrée/sortie réseau, impactant les performances.

    • Comment prévenir : Ajustez le nombre de reconstructions simultanées en utilisant le paramètre concurrent-replica-rebuild-per-node-limit.

  • Échecs de plusieurs répliques

    • Pourquoi c’est important : Augmente le temps et la complexité de reconstruction. Si auto-cleanup-system-generated-snapshot est true et qu’aucun instantané créé par l’utilisateur n’existe, deux répliques échouées peuvent déclencher au moins un transfert de données complet.

      Pour plus de détails, voir Évitez "le transfert de données complet" lors de la reconstruction de deux répliques échouées.

    • Comment prévenir :

      1. Désactivez auto-cleanup-system-generated-snapshot avant d’effectuer la maintenance.

      2. Créez des instantanés créés par l’utilisateur de tous les volumes avant de commencer la maintenance.

      3. Utilisez un travail récurrent pour prendre des instantanés régulièrement.

  • Reconstruction de répliques à l’échelle

    • Pourquoi c’est important :

      La reconstruction de répliques à l’échelle permet à une réplique de reconstruction de récupérer des instantanés de plusieurs répliques saines simultanément, améliorant ainsi considérablement les performances de reconstruction pour certains modèles de charge de travail.

    • Comment activer :

      Définissez replica-rebuild-concurrent-sync-limit > 1 pour permettre à plusieurs répliques saines de démarrer des serveurs de synchronisation. La réplique en cours de reconstruction récupère alors différents instantanés de différentes répliques sources simultanément. Cette fonctionnalité est particulièrement bénéfique pour les volumes contenant de petits morceaux de données dispersés ainsi que des trous dans leurs instantanés.

      Pour plus de détails, voir Reconstruction de répliques à l’échelle.

Cas d’utilisation

Redémarrage de nœud pendant la mise à niveau

Lorsqu’un nœud de travail avec des répliques est redémarré dans le cadre d’une mise à niveau planifiée :

  1. La réplique sur ce nœud devient temporairement indisponible et échoue, mais les opérations de lecture et d’écriture continuent.

  2. Si le nœud se rétablit dans le délai de replica-replenishment-wait-interval, SUSE Storage initie une reconstruction en utilisant la réplique échouée réutilisable.

Pendant le processus de reconstruction :

  1. SUSE Storage sélectionne la dernière réplique échouée réutilisable si plusieurs répliques échouées réutilisables sont disponibles.

  2. En fonction du scénario de reconstruction :

    • Si la reconstruction rapide de répliques est activée et que toutes les sommes de contrôle des instantanés existent : SUSE Storage déclenche [_fast_replica_rebuilding]. Seuls les blocs modifiés dans l’en-tête du volume sont synchronisés, évitant ainsi à la fois la reconstruction complète et la reconstruction delta.

    • Si la reconstruction rapide de répliques est activée mais que certaines sommes de contrôle des instantanés sont manquantes : SUSE Storage déclenche [_delta_replica_rebuilding]. Les blocs modifiés des instantanés sans sommes de contrôle sont synchronisés, évitant la reconstruction complète.

    • Si la reconstruction rapide de répliques est désactivée : SUSE Storage effectue une reconstruction delta en synchronisant les blocs modifiés de tous les instantanés, évitant la reconstruction complète.

Drainage de nœud à court terme

Si un nœud de travail est drainé pour une maintenance à court terme puis rapidement restauré :

  1. La réplique sur le nœud drainé est immédiatement marquée comme échouée.

  2. Si le nœud est déverrouillé avant l’expiration de replica-replenishment-wait-interval, SUSE Storage tente de réutiliser la réplique échouée.

  3. Le comportement de reconstruction suit la même logique que celle décrite dans le cas d’utilisation précédent.

Paramètres pertinents

Paramètre Par défaut Description

fast-replica-rebuild-enabled

true

Active la reconstruction rapide des répliques. S’appuie sur des sommes de contrôle d’instantané pré-calculées.

intégrité-des-données-d’instantané

fast-check

Hache les fichiers de disque d’instantané uniquement s’ils ne sont pas hachés ou si leur date de modification a changé.

snapshot-data-integrity-cronjob

0 0 */7 * *

Planification cron pour calculer les sommes de contrôle pour tous les instantanés. Par défaut : tous les 7 jours.

snapshot-data-integrity-immediate-check-after-snapshot-creation

false

Si activé, calcule les sommes de contrôle immédiatement après la création de l’instantané.

replica-replenishment-wait-interval

600

Temps en secondes à attendre avant de créer une nouvelle réplique. Permet la réutilisation des répliques échouées.

concurrent-replica-rebuild-per-node-limit

5

Limite le nombre de reconstructions de répliques simultanées par nœud.

replica-rebuild-concurrent-sync-limit

1

Nombre maximum de répliques saines pouvant se synchroniser avec une réplique en reconstruction simultanément. Plage : 1-5. Définir à 1 désactive la reconstruction à l’échelle.

offline-replica-rebuilding

false

Détermine si les répliques dégradées sont reconstruites pendant que le volume est détaché.

Analyse des compromis des paramètres

  • reconstruction-rapide-des-répliques-activée

    • enabled : Ignore le transfert de données des instantanés si les sommes de contrôle sont à jour. Fournit des reconstructions rapides mais ne revalide pas les données.

    • disabled : Effectue une reconstruction delta en utilisant des comparaisons de blocs. Plus lent, mais garantit l’intégrité des données de l’instantané.

  • intégrité-des-données-instantané

    • enabled : Par défaut, calcule les sommes de contrôle des instantanés tous les 7 jours. Augmente l’utilisation de l’UC, des E/S disque et des ressources.

  • snapshot-data-integrity-cronjob

    • Par défaut : 0 0 */7 * *

      Si snapshot-data-integrity est activé, cela définit quand les sommes de contrôle des instantanés sont recalculées. Les instantanés créés entre les exécutions de cron peuvent manquer de sommes de contrôle.

  • vérification-d’intégrité-des-données-d’instantané-immédiate-après-création

    • true : Calcule immédiatement les sommes de contrôle des instantanés après leur création. Augmente l’utilisation de l’UC et des E/S disque. Le temps d’achèvement est imprévisible.

    • false : Les instantanés peuvent ne pas avoir de sommes de contrôle jusqu’à la prochaine exécution de cron. Une reconstruction delta sera nécessaire si des sommes de contrôle sont manquantes.

  • intervalle-d’attente-de-réapprovisionnement-des-répliques

    • Par défaut : 600 secondes

      • Intervalle court : Peut ignorer la réutilisation des répliques échouées et déclencher des reconstructions complètes.

      • Intervalle long: Attend plus longtemps pour réutiliser les répliques échouées, mais cela peut retarder la récupération.

  • concurrent-replica-rebuild-per-node-limit

    • Par défaut : 5

      • Limite élevée: Peut surcharger les ressources du nœud, ralentissant les reconstructions et les charges de travail actives.

      • Limite faible: Réduit la contention des ressources mais augmente le temps de reconstruction en raison de la mise en file d’attente.

  • replica-rebuild-concurrent-sync-limit

    • Par défaut : 1

      • Lorsqu’il est réglé sur 1, la reconstruction à l’échelle est désactivée et seule la reconstruction traditionnelle à source unique est utilisée avec une consommation minimale de ressources. Lorsqu’il est réglé sur des valeurs de 2 à 5, cela active la reconstruction à l’échelle avec plusieurs répliques sources, offrant une amélioration significative des performances pour les volumes. Cependant, des valeurs plus élevées augmentent la consommation de CPU sur les répliques source et destination.

      • Ce paramètre peut être remplacé par volume.spec.RebuildConcurrentSyncLimit sur une base par volume.