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.
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.
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.
La figure ci-dessous montre 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.
La figure ci-dessous montre 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.
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é.
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.
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 :
-
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).
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.
-
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).
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.
-
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).
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}.
La figure ci-dessous montre 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.
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.
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.
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.
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.
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.
Contournement d'un noeud ayant échoué à l'aide de la CLI :
-
Sélectionnez l'action pour le noeud ayant échoué dans la source.
-
Saisissez retarget.
-
Définissez la propriété retarget_mode sur bypass.
-
Définissez la cible pour qu'elle soit la cible ignorée, comme illustré dans la figure ci-dessous.
-
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.
-
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.
Contournement d'un noeud ayant échoué à l'aide de la BUI :
-
Sur le noeud source, sélectionnez l'action pour le noeud ayant échoué.
-
Dans la boîte de dialogue Modifier l'action de réplication, cliquez sur Recibler.
-
Dans la boîte de dialogue Reciblage de réplication, définissez le mode sur Ignorer.
-
Sélectionnez la cible dans la liste déroulante en tant que cible ignorée, comme illustré dans la figure ci-dessous.
-
Cliquez sur Appliquer.
-
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.
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.
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.
Remarques concernant la compatibilité
-
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.
Lors de la configuration de la réplication en cascade, respectez les règles de compatibilité suivantes :
Rubriques connexes