Go to main content

Guide d'administration d'Oracle® ZFS Storage Appliance, version OS8.8.x

Quitter la vue de l'impression

Mis à jour : Août 2021
 
 

Réplication en cascade

La réplication en cascade permet la réplication de données en configurant des actions pour des packages de réplication. Vous pouvez créer plusieurs actions de réplication pour le même package, visant à le répliquer dans plusieurs appareils cibles.

Configuration de base

La configuration de base d'une réplication en cascade consiste en une source, une ou plusieurs cibles intermédiaires et une cible finale.

L'exemple suivant d'une réplication en cascade est composé du noeud source A comprenant une action configurée pour l'un de ses projets afin de le répliquer dans un package sur le noeud B. Le noeud B, à son tour, comprend une action créée pour répliquer ce package dans un autre package sur le noeud C, et le noeud C comprend une action configurée pour ce package afin de le répliquer dans un package sur le noeud D. Ainsi, le noeud B et le noeud C effectue une réplication en cascade à partir du noeud A vers le noeud D, comme illustré dans la figure ci-dessous.

image:Image montrant un exemple de configuration de réplication en cascade

Comme illustré dans la figure suivante, le noeud source A comprend une action qui est configurée pour l'un de ses projets afin de le répliquer dans un package sur le noeud B. Le noeud B, à son tour, comprend des actions créées pour répliquer ce package dans le noeud C et le noeud D. Ainsi, le noeud B effectue une réplication en cascade à partir du noeud A vers les noeuds C et D.

image:Image montrant une réplication en cascade effectuée par le noeud B à partir du noeud A vers les noeuds C et D

La réplication inverse dans une configuration en cascade est uniquement prise en charge sur les noeuds recevant des mises à jour de réplication directement à partir de la source (noeud B dans l'exemple précédent) et si l'inversion est désactivée sur les autres noeuds (noeuds C et D). L'inversion multicible doit être envisagée lors de la planification de la récupération après sinistre dans une configuration de réplication en cascade. Voir Inversion multicible et "Utilisation de la propriété distant_target pour gérer l'inversion" dans les sections suivantes.

Gestion de la réplication en cascade

La gestion de la réplication en cascade est composée de deux tâches :

  • Création d'une action dans le package de réplication

  • Configuration des calendriers de réplication en cascade

Création d'une action dans le package de réplication

De la même manière qu'une action de réplication peut être créée dans un projet, une action de réplication peut être créée dans un package de réplication. La figure ci-dessous montre la création d'une action dans un package de réplication à l'aide de la BUI.

Notez que la réplication en cascade n'est pas prise en charge pour la réplication au niveau des partages. Il n'est pas possible de configurer des actions dans les partages des packages de réplication et dans des packages créés à la suite d'une réplication au niveau d'un partage.

image:Image montrant la création d'une action dans un package de réplication à l'aide de la BUI

La figure ci-dessous montre la création d'une action dans un package de réplication à l'aide de la CLI.

image:Image montrant la création d'une action dans un package de réplication à l'aide de la CLI

Configuration des calendriers de réplication en cascade

Chaque action comprend deux calendriers :

  • Un calendrier pour une action configurée dans le cadre d'un projet, appelée calendrier source.

  • Un calendrier pour une action configurée dans le cadre d'un package, appelée calendrier en cascade

La figure ci-dessous montre la configuration d'un nouveau calendrier en cascade dans une action de réplication, à l'aide de la CLI.

image:Image montrant la configuration d'un nouveau calendrier en cascade dans une action de réplication, à l'aide de la CLI.

La figure ci-dessous montre la configuration d'un nouveau calendrier en cascade dans une action de réplication, à l'aide de la BUI.

image:Image montrant la configuration d'un nouveau calendrier en cascade dans une action de réplication, à l'aide de la BUI.

Les deux calendriers peuvent être configurés à tout moment, mais un seul d'entre eux est appliqué, selon l'emplacement de configuration de l'action. Si la topologie de réplication est modifiée en raison d'une réplication inverse ou d'une conversion, le calendrier appliqué peut changer. Par exemple, après une inversion dans un package de réplication, les actions configurées dans le package inversé sont maintenant configurées dans le projet et leur calendrier source devient actif. De même, après une conversion de réplication pour des actions qui étaient configurées dans le projet mais sont maintenant configurées dans le package, leur calendrier en cascade devient actif.

La figure ci-dessous montre l'affichage du calendrier appliqué à l'aide de la CLI.

image:Image montrant l'affichage du calendrier appliqué à l'aide de la CLI

La figure ci-dessous montre l'affichage du calendrier appliqué à l'aide de la BUI. L'onglet de calendrier le plus à gauche pour une action reflète le calendrier appliqué.

image:Image montrant l'affichage du calendrier appliqué à l'aide de la BUI

Les calendriers sources et en cascade sont conservés lorsque de nouvelles actions sont créées au cours d'une réplication inverse. Voir Inversion du sens de réplication et Inversion multicible.

L'option after_update est disponible pour les calendriers en cascade. Lorsqu'elle est définie, la mise a jour sera initialisée uniquement après la fin d'une mise à jour entrante.

Vous pouvez utiliser la propriété update_cascade_delay pour spécifier le délai entre l'achèvement d'une mise à jour de réplication entrante et l'initialisation de la mise à jour en cascade sortante. Cette propriété est uniquement appliquée lorsque vous sélectionnez l'option after_update.

L'option after_update et la propriété update_cascade_delay peuvent être configurées comme illustré dans la figure suivante.

image:Image montrant la configuration des options dans la CLI

Notez que l'option de planification continue n'est pas disponible pour les actions liées à des packages et que les actions de réplication en cascade ne créent pas d'instantané de réplication. Lorsqu'une nouvelle mise à jour est livrée à partir de la source, les actions en cascade utilisent l'instantané de package le plus récent pour effectuer les mises à jour de réplication dans ses cibles. Par conséquent, effectuer une mise à jour pour une action en cascade sans recevoir d'abord de mise à jour à partir de la source n'a aucun incidence. Le statut de mise à jour réussie est défini et la propriété last_try est mise à jour.

Utilisation de la propriété distant_target pour gérer l'inversion

Dans une réplication en cascade, une relation de cible distante entre deux noeuds fait la distinction entre les cibles locales et distantes. La propriété distant_target conserve cette relation après les transformations de la topologie à la suite d'une réplication inverse ou d'une conversion.

Les scénarios de configuration suivants illustrent la propriété distant_target :

  1. La propriété distant_target n'est pas définie et aucune inversion multicible n'est configurée. Dans ce cas, lorsqu'une inversion est effectuée pour une cible, les actions ne sont pas toutes conservées. Pour plus d'informations, reportez-vous à la section Inversion multicible. Comme illustré dans la figure ci-dessous, aucun des noeuds A et B n'a de relation de cible distante et le noeud B n'est pas configuré en tant que source potentielle (action AB : potential_source=false, distant_target=false).

    image:Image montrant la propriété distant_target non définie, sans configuration d'inversion multicible

    Si A échoue et qu'une inversion est effectuée pour B, aucune action n'est créée pour A{1..3}, comme illustré dans la figure ci-dessous.

    image:Image montrant la défaillance de A et l'inversion effectuée pour B
  2. La propriété distant_target n'est pas définie et une inversion multicible est configurée. Dans ce cas, lorsqu'une inversion est effectuée pour une source potentielle, des actions sont créées pour toutes les cibles du groupe d'inversions multicibles. Il n'y a aucune relation de cible distante et, par conséquent, aucune distinction entre les cibles locales et distantes. Le noeud A représente la source et le noeud B la source potentielle, comme illustré dans la figure ci-dessous. Les noeuds A et B n'ont pas de relation de cible distante (action AB : potential_source=true, distant_target=false).

    image:Image montrant la propriété distant_target non définie avec configuration d'une inversion multicible

    Toutefois, si le noeud A échoue et que le noeud B devient la nouvelle source après une inversion, des actions sont créées pour A{1..3}, comme illustré dans la figure ci-dessous.

    image:Image montrant la défaillance du noeud A0 et le noeud B0 en tant que nouvelle source après une inversion
  3. La propriété distant_target est définie et une inversion multicible est configurée. Dans ce cas, lorsqu'une inversion est effectuée pour une source potentielle, aucune action n'est créée pour les cibles locales par rapport à la source distante. Le noeud A représente la source et le noeud B la source potentielle, comme illustré dans la figure ci-dessous. Les noeuds A et B ont une relation de cible distante (action AB : potential_source=true, distant_target=true).

    image:Image montrant la propriété distant_target définie avec configuration d'une inversion multicible

    Si le noeud A échoue et après une inversion sur le noeud B, le noeud B devient la nouvelle source. Toutefois, en raison de la relation de cible distante entre A et B, aucune action n'est créée pour A{1..3}. Après la récupération de A, son package est répliqué en cascade dans A{1..3}.

    image:Image montrant la défaillance du noeud A après une inversion sur le noeud B

La figure ci-dessous montre la configuration d'une cible distante à l'aide de la CLI.

image:Image montrant la configuration d'une cible distante à l'aide de la CLI

La figure ci-dessous montre la configuration d'une cible distante à l'aide de la BUI.

image:Image montrant la configuration d'une cible distante à l'aide de la BUI

Il est recommandé de configurer l'inversion multicible en définissant une source potentielle lors de l'utilisation de la réplication en cascade, sinon il peut ne pas être possible de retourner à la configuration en cascade initiale après plusieurs inversions de réplication. En outre, la cible distante peut uniquement être définie lorsqu'une source potentielle l'est. Pour plus d'informations, reportez-vous à la section Inversion multicible.

Scénarios de défaillance

La défaillance d'un seul noeud dans une réplication en cascade peut avoir une incidence sur plusieurs appareils ou même plusieurs centres de données connectés les uns aux autres par des relations de réplication. Bien qu'il n'existe pas de restriction pour la topologie de réplication en cascade, les scénarios de défaillance typiques suivants sont présentés :

  • Défaillance de source initiale

  • Défaillance de cible intermédiaire

  • Défaillance de site source

Défaillance de source initiale

Dans ce scénario, la source de la chaîne en cascade échoue. La récupération après cette défaillance nécessite une configuration d'inversion multicible initiale pour la source. Le processus est lancé sur une cible en effectuant une réplication inverse. La cible inversée devient la source et continue à envoyer des mises à jour incrémentielles vers toutes les autres cibles initiales et vers la source initiale. Pour plus de détails, reportez-vous à la section Inversion multicible.

Comme illustré dans la figure ci-dessous, A représente la source et A1 la source potentielle. A est répliqué dans A1 et B. B, à son tour, est répliqué dans C et D, et la source A échoue.

image:Image montrant la défaillance de la source A

Comme illustré dans la figure ci-dessous, après l'inversion de A1, il est répliqué dans A (lors de la récupération de A) et dans B qui, à son tour, continue à envoyer des mises à jour vers C et D.

image:Image montrant une inversion effectuée pour A1

Défaillance de cible intermédiaire

Ce scénario de défaillance se rapporte à la défaillance d'un noeud intermédiaire dans une chaîne en cascade. La récupération après ce scénario peut être effectuée en suivant la procédure de reciblage. Comme illustré dans la figure ci-dessous, le noeud intermédiaire B échoue dans la chaîne en cascade.

image:Image montrant une défaillance de cible intermédiaire

Comme illustré dans la figure ci-dessous, après la procédure de reciblage/contournement, la source A ignore le noeud B ayant échoué et continue à envoyer des mises à jour vers le noeud C, qui à son tour envoie une mise à jour vers le noeud D.

image:Image montrant la source A ignorant le noeud B ayant échoué et continuant à envoyer des mises à jour vers le noeud C, puis D

Comme illustré dans la figure ci-dessous, après la récupération de B, l'action entre A et B est restaurée alors que l'action entre B et C reste ignorée.

image:Image montrant la restauration de l'action entre A et B, et le contournement de l'action entre B et C

Contournement d'un noeud ayant échoué à l'aide de la CLI :

  1. Sélectionnez l'action pour le noeud ayant échoué dans la source.

  2. Saisissez retarget.

  3. Définissez la propriété retarget_mode sur bypass.

  4. Définissez la cible pour qu'elle soit la cible ignorée, comme illustré dans la figure ci-dessous.

    image:Image montrant la cible définie en tant que cible ignorée dans la CLI
  5. Vous pouvez utiliser la propriété bypassed_id montrée dans l'action de contournement afin de sélectionner l'action initiale pour effectuer la restauration de reciblage après la récupération du noeud ayant échoué. Vous pouvez afficher la propriété bypassed_id générée, comme illustré dans la figure ci-dessous.

    image:Image montrant l'affichage de la propriété bypassed_id dans la CLI
  6. Ultérieurement, après la récupération de B, utilisez la procédure de reciblage/contournement pour retourner à la topologie en cascade initiale, comme illustré dans la figure ci-dessous.

    image:Image montrant la procédure de restauration dans la CLI

Contournement d'un noeud ayant échoué à l'aide de la BUI :

  1. Sur le noeud source, sélectionnez l'action pour le noeud ayant échoué.

  2. Dans la boîte de dialogue Modifier l'action de réplication, cliquez sur Recibler.

  3. Dans la boîte de dialogue Reciblage de réplication, définissez le mode sur Ignorer.

  4. Sélectionnez la cible dans la liste déroulante en tant que cible ignorée, comme illustré dans la figure ci-dessous.

    image:Image montrant la sélection de la cible dans la liste déroulante en tant que cible ignorée dans la BUI
  5. Cliquez sur Appliquer.

  6. Ultérieurement, après la récupération de B, utilisez la procédure de restauration pour retourner à la topologie en cascade initiale, comme illustré dans la figure ci-dessous.

    image:Image montrant la procédure de restauration dans la BUI

Défaillance de site source

Dans ce scénario, la source et toutes ses cibles locales directes ne sont pas disponibles et sont remplacées par une nouvelle source dans l'une des cibles distantes. La récupération après ce scénario nécessite une configuration d'inversion multicible pour la source. Pour plus de détails, reportez-vous à la section Inversion multicible. Elle nécessite également la configuration de certaines cibles en tant que cibles distantes. Pour plus de détails, reportez-vous à la section "Utilisation de la propriété distant_target pour gérer l'inversion".

Comme illustré dans la figure ci-dessous, A0, B0 et C0 forment un groupe d'inversions multicibles, où B0 et C0 sont des sources potentielles et des cibles distantes. A0,B0 et A0,C0 forment une relation de cible distante (A0B0 et A0C0 doivent être configurés en tant que source potentielle et cible distante), alors que A1,A2,A3 forme une relation locale avec A0, et B1,B2,B3 avec B0.

image:Image montrant la source et toutes ses cibles locales directes non disponibles et leur remplacement par une nouvelle source dans l'une des cibles distantes

Si une inversion est effectuée pour B0, comme illustré dans la figure ci-dessous, elle traite A1,A2,A3 comme cibles locales de A0 et, par conséquent, ne recrée pas d'action pour A1,A2,A3. En raison des propriétés d'inversion multicible, B0 envoie les mises à jour vers C0.

image:Image montrant l'inversion effectuée et la défaillance de site source

Remarques concernant la compatibilité

    Lors de la configuration de la réplication en cascade, respectez les règles de compatibilité suivantes :

  • Les noeuds exécutant un microprogramme antérieur à la version OS8.7.0 ne peuvent pas être configurés dans le cadre d'une réplication en cascade.

  • Les noeuds exécutant un microprogramme postérieur à la version OS8.7.0 peuvent être configurés en tant que noeuds finaux.

  • Les noeuds finaux exécutant un microprogramme qui ne prend pas en charge la réplication en cascade peuvent effectuer une réplication inverse. Toutefois, ils ne peuvent pas effectuer de mise à jour de réplication vers leur source. Dans un tel scénario, il n'est pas possible de récupérer les relations de réplication.

  • Le reciblage ne peut pas être effectué pour des noeuds finaux exécutant un microprogramme qui ne prend pas en charge la réplication en cascade.

  • Les règles de compatibilité de réplication pour des cibles exécutant divers microprogrammes dans des chaînes en cascade sont les mêmes que pour des sources et des cibles. Par exemple, lorsqu'une cible ne prend pas en charge une fonctionnalité utilisée par la source, la mise à jour de réplication à partir de la source correspondante risque d'échouer.

  • La restauration du système à une version du microprogramme qui ne prend pas en charge la réplication en cascade entraîne la destruction de toutes les actions de réplication en cascade.

Rubriques connexes