Exemple : Configuration de réplication pour des appareils en cluster
Cet exemple montre comment configurer correctement la réplication pour garantir que la réplication des projets continue après une reprise du cluster, un rétablissement du cluster ou l'exécution d'une réplication inverse sur un appareil cible.
Instructions de configuration
Lorsque vous configurez la réplication pour des appareils en cluster, respectez les règles suivantes :
-
Assurez-vous que les deux appareils source et cible sont dans l'état CLUSTERED. Pour plus de détails, reportez-vous à la section Table 44.
-
Sélectionnez les interfaces réseau et les adresses IP à utiliser pour le trafic de réplication sur les appareils source et cible.
-
Sélectionnez une interface réseau singleton. Contrairement à une interface réseau privée, une interface réseau singleton sera reprise par le contrôleur resté fonctionnel après la perte d'un des contrôleurs du cluster. L'utilisation d'une interface singleton garantit la réussite de la réplication à la suite d'une reprise ou d'un rétablissement du cluster. Pour plus d'informations sur les interfaces singleton, reportez-vous à la section Table 43.
-
Assurez-vous que l'interface réseau sélectionnée sur l'appareil source et le pool à partir duquel les données seront répliquées sont tous les deux affectés au même contrôleur. C'est toujours le cas lorsque le cluster source est dans l'état CLUSTERED.
-
Pour le cluster cible également, l'interface réseau sélectionnée sur l'appareil cible et le pool dans lequel les données seront répliquées doivent tous les deux être affectés au même contrôleur. Cette association est garantie lorsque la configuration de réplication est effectuée pendant que le cluster cible est dans l'état CLUSTERED.
-
Les appareils source et cible doivent être capables de communiquer à l'aide des interfaces réseau et des adresses IP sélectionnées.
-
-
Créez un routage statique /32 basé sur les hôtes entre les appareils source et cible pour garantir qu'à la suite d'une inversion de réplication, l'interface sélectionnée sera utilisée pour le trafic de réplication sortant une fois que l'inversion aura transformé la cible actuelle en source de réplication.
-
Après avoir créé la route statique, configurez l'objet cible de la réplication sur l'appareil source en utilisant l'adresse IP sélectionnée de la cible.
-
Lorsque l'appareil cible est dans l'état OWNER, toutes les ressources partagées (y compris les interfaces réseau et les pools de stockage) font l'objet d'une reprise et d'une appropriation par le seul contrôleur resté fonctionnel et présentant désormais l'état OWNER. Sur le contrôleur en état OWNER, il est possible de sélectionner une interface réseau affectée à un contrôleur et de l'utiliser pour livrer le trafic de réplication à un pool qui est affecté à un contrôleur différent. Lorsque les contrôleurs reprennent l'état CLUSTERED, les interfaces réseau et les pools de stockage retournent à leurs affectations (contrôleurs) d'origine. Il s'ensuit que les mises à jour de réplication risquent d'être impossibles parce que l'appareil source utilise l'interface réseau d'un contrôleur cible qui n'est plus propriétaire du pool. Cette erreur ne peut pas se produire si la configuration de réplication est effectuée alors que l'appareil cible est dans l'état CLUSTERED.
Exemple : Configuration de la réplication pour des appareils en cluster
La procédure décrite dans cet exemple utilise les interfaces réseau source et cible et les adresses IP suivantes :
Le cluster d'appareils source se compose des contrôleurs source S1 et S2. Le pool de stockage sp1 est assigné à S1 et le pool sp2 est assigné à S2. Les interfaces réseau du cluster sont les suivantes :
-
Interface privée ixgbe0 sur S1, présentant l'adresse IP 198.51.100.81/24
-
Interface privée ixgbe0 sur S2, présentant l'adresse IP 198.51.100.82/24
-
Interface singleton ixgbe1 d'adresse IP 192.0.2.101/25 assignée à S1
-
Interface singleton ixgbe2 d'adresse IP 192.0.2.102/25 assignée à S2
-
Interface singleton ixgbe3 d'adresse IP 192.0.2.201/25 assignée à S1
-
Interface singleton ixgbe4 d'adresse IP 192.0.2.202/25 assignée à S2
L'appareil est initialement dans l'état CLUSTERED, où :
-
S1 est propriétaire de sp1, ixgbe1 et ixgbe3
-
S2 est propriétaire de sp2, ixgbe2 et ixgbe4
Le cluster d'appareils cible se compose des contrôleurs T1 et T2. Le pool de stockage tp1 est assigné à T1 et le pool tp2 est assigné à T2. Les interfaces réseau du cluster sont les suivantes :
-
Interface privée ixgbe0 sur T1, présentant l'adresse IP 198.51.100.83/24
-
Interface privée ixgbe0 sur T2, présentant l'adresse IP 198.51.100.84/24
-
Interface singleton ixgbe1 d'adresse IP 192.0.2.103/25 assignée à T1
-
Interface singleton ixgbe2 d'adresse IP 192.0.2.104/25 assignée à T2
-
Interface singleton ixgbe3 d'adresse IP 192.0.2.203/25 assignée à T1
-
Interface singleton ixgbe4 d'adresse IP 192.0.2.204/25 assignée à T2
L'appareil est initialement dans l'état CLUSTERED, où :
-
T1 est propriétaire de tp1, ixgbe1 et ixgbe3
-
T2 est propriétaire de tp2, ixgbe2 et ixgbe4
Les étapes décrites ci-après permettent de configurer la réplication pour les projets Red, Blue et Green à l'aide de l'interface de ligne de commande (CLI).
-
Sélectionnez les interfaces réseau et les adresses IP.
-
Commencez par sélectionner les interfaces réseau et les adresses IP à utiliser pour la réplication du projet Red.
Comme la source S est dans l'état CLUSTERED, il suffit de s'assurer que les interfaces réseau et adresses IP sélectionnées ne sont pas privées. Sur S1, utilisez par conséquent ixgbe1 ou ixgbe3.
-
Il en va de même pour la cible T. Utilisez donc ixgbe1 ou ixgbe3 sur l'appareil T1. Comme ixgbe1 et ixgbe3 (que ce soit sur S1 ou sur T1) appartiennent au même sous-réseau, vous pouvez sélectionner indifféremment l'une ou l'autre interface pour la réplication du projet Red. Cet exemple choisit l'interface ixgbe1 sur S1 et sur T1.
-
-
Définissez une route statique sur S1.
L'exemple suivant configure la route statique pour la réplication du projet Red du contrôleur source S1 :
S1:configuration net routing> create S1:configuration net route (uncommitted)> set family=IPv4 family = IPv4 (uncommitted) S1:configuration net route (uncommitted)> set destination=192.0.2.103 destination = 192.0.2.103 (uncommitted) S1:configuration net route (uncommitted)> set mask=32 mask = 32 (uncommitted) S1:configuration net route (uncommitted)> set interface=ixgbe1 interface = ixgbe1 (uncommitted) S1:configuration net route (uncommitted)> set gateway=192.0.2.1 gateway = 192.0.2.1 (uncommitted) S1:configuration net route (uncommitted)> commit S1:configuration net routing> list ROUTE DESTINATION GATEWAY INTERFACE TYPE STATUS ... route-003 192.0.2.103/32 192.0.2.1 ixgbe1 static active -
Définissez une route statique sur T1.
L'exemple suivant configure la route statique pour la réplication du projet Red du contrôleur cible T1 :
T1:configuration net routing> create T1:configuration net route (uncommitted)> set family=IPv4 family = IPv4 (uncommitted) T1:configuration net route (uncommitted)> set destination=192.0.2.101 destination = 192.0.2.101 (uncommitted) T1:configuration net route (uncommitted)> set mask=32 mask = 32 (uncommitted) T1:configuration net route (uncommitted)> set interface=ixgbe1 interface = ixgbe1 (uncommitted) T1:configuration net route (uncommitted)> set gateway=192.0.2.1 gateway = 192.0.2.1 (uncommitted) T1:configuration net route (uncommitted)> commit T1:configuration net routing> list ROUTE DESTINATION GATEWAY INTERFACE TYPE STATUS ... route-003 192.0.2.101/32 192.0.2.1 ixgbe1 static active -
Créez une cible de réplication sur S1.
L'exemple suivant crée l'objet cible de réplication sur S1 à utiliser pour répliquer le projet Red de sp1 vers tp1 :
S1:shares replication targets>target S1:shares replication target (uncommitted)> set hostname=192.0.2.103 hostname = 192.0.2.103 (uncommitted) S1:shares replication target (uncommitted)> set label=t1-1 label = t1-1 (uncommitted) S1:shares replication target (uncommitted)> set root_password=******** root_password = (set) (uncommitted) S1:shares replication target (uncommitted)> commit -
Créez une action de réplication pour chaque projet.
-
Répliquez le projet Red depuis le pool sp1 vers le pool tp1
-
Répliquez le projet Blue depuis le pool sp1 vers le pool tp2
-
Répliquez le projet Green depuis le pool sp2 vers le pool tp2
L'exemple suivant crée l'action de réplication pour le projet Red :
S1:> shares select Red replication action S1:shares Red action (uncommitted)> set target=t1-1 target=t1-1 (uncommitted) S1:shares Red action (uncommitted)> set pool=tp1 pool=tp1 (uncommitted) S1:shares Red action (uncommitted)> commit -
-
Configurez la réplication du projet Blue du pool sp1 vers le pool tp2.
Commencez par la sélection d'interfaces et d'adresses : sélectionnez les interfaces S1/ixgbe3 et T2/ixgbe4, en sachant que S comme T sont dans l'état CLUSTERED et que les adresses IP de ces interfaces appartiennent au même sous-réseau (à savoir 192.0.2.128/25). Ensuite, définissez des routes statiques sur les deux appareils comme illustré dans de précédents exemples. Créez l'objet cible de la réplication t2-2 sur S1, puis créez l'action de réplication sur S1 pour le projet Blue.
-
Configurez la réplication du projet Green du pool sp2 vers le pool tp2.
Commencez par la sélection des interfaces : sélectionnez S2/ixgbe2 et T2/ixgbe2. Créez les routes statiques sur S2 et T2 en utilisant les interfaces sélectionnées et leurs adresses, définissez l'objet cible de la réplication t2-1 avec l'adresse T2/ixgbe2, puis créez l'action de réplication du projet Green avec comme objet cible t2-1.
-
Lancez les trois actions de réplication.
-
Commencez par le projet Red :
S1:> shares select Red replication select action-000 S1:shares Red action-000> sendupdate
-
En suivant l'exemple précédent, lancez les actions de réplication définies pour les projets Blue et Green.
-
Chemin des données de réplication - Exemples
Les figures suivantes illustrent les chemins de réplication des données empruntés par les actions de réplication des projets Red, Blue et Green :
Figure 31 Chemin normal de réplication des données
Supposons que le contrôleur T2 a dû être arrêté pour subir une opération de maintenance. T1 a effectué une reprise et détient désormais toutes les ressources. Si des mises à jour de réplication sont en cours pour les projets Blue et Green pendant la reprise, elles seront annulées. Une fois la reprise effectuée par T1, ces mises à jour de réplication peuvent faire l'objet d'une reprise manuelle ou bien attendre une reprise automatique si des calendriers ont été configurés pour les actions de réplication correspondantes.
Lorsque le contrôleur T1 a terminé la reprise, il possède les interfaces ixgbe2 et ixgbe4 qui sont nécessaires à la poursuite des mises à jour de réplication pour les projets Blue et Green. La figure suivante illustre le chemin des données de réplication après que T1 a terminé la reprise.
Figure 32 Chemin des données de réplication après la reprise par T1
Lorsque T2 est remis en ligne, un rétablissement est effectué sur le contrôleur T1 et il reprend ses ressources. Si des mises à jour de réplication des projets Blue et Green sont en cours, elles sont annulées et pourront être reprises à l'issue de l'opération de rétablissement.
Le contrôleur S2 est alors mis hors service pour maintenance et la reprise effectuée sur le contrôleur S1 fait qu'il prend possession de toutes les ressources, y compris de l'interface requise pour continuer la réplication du projet Green. Si une mise à jour de réplication du projet Green est en cours, elle est annulée et pourra être relancée une fois l'opération de reprise terminée.
Figure 33 Chemin des données après rétablissement sur T1 et reprise sur S1
Rubriques connexes