La reprise permet d'assurer la continuité ou la reprise normale du service lorsqu'un contrôleur de cluster tombe en panne ou n'est plus alimenté.
L'un des contrôleurs tente automatiquement d'effectuer une reprise du cluster lorsqu'il détecte que son pair est absent (par exemple, dans le cas d'un arrêt ou d'une réinitialisation). Après la reprise, le contrôleur qui en est à l'origine possède toutes les ressources du cluster et fournit tous les services.
Si les deux contrôleurs sont en panne ou mis hors tension, le logiciel de l'appareil exécute une procédure d'arbitrage lors du démarrage afin de déterminer le contrôleur qui poursuivra la reprise.
La reprise peut également être effectuée manuellement, ce qui peut être utile à des fins de test.
L'opération de rétablissement fait passer la configuration du cluster de OWNER-STRIPPED (active-passive) à CLUSTERED-CLUSTERED (active-active). Le rétablissement ne se fait jamais automatiquement.
Le rétablissement s'effectue généralement :
Lorsqu'un contrôleur revient en ligne après une reprise.
Lors de la dernière étape de la configuration d'un cluster. Reportez-vous à la section Mise à niveau d'un appareil autonome vers une configuration clustérisée (BUI).
Si le contrôleur B d'un cluster tombe en panne ou n'est plus alimenté, le contrôleur A de ce cluster reprend les ressources qui étaient assignées au contrôleur B, et fournit tous les services du cluster. Après la réparation et la réinitialisation du contrôleur B, un administrateur effectue l'opération de rétablissement pour permettre au contrôleur B de reprendre le service de production.
Une fois réparé et initialisé, le contrôleur B :
Rejoint le cluster, en resynchronisant l'affichage de toutes les ressources et leurs propriétés.
Attend qu'un administrateur exécute une opération de rétablissement.
Pendant que le contrôleur B attend, le contrôleur A continue de fournir tous les services. Le contrôleur A est à l'état Actif (la reprise est terminée) ou AKCS_OWNER, et le contrôleur B est à l'état Prêt (en attente du rétablissement) ou AKCS_STRIPPED.
L'opération de rétablissement permet au contrôleur B de reprendre le service de production. Depuis la panne du contrôleur B, c'est le contrôleur A qui fournit tous les services. L'opération de rétablissement restaure sur le contrôleur B les ressources qu'il possédait avant la panne. L'opération de rétablissement exporte du contrôleur A toutes les ressources assignées au contrôleur B, lequel importe ces ressources. Après un rétablissement réussi, le contrôleur A et le contrôleur B sont tous les deux à l'état Actif ou CLUSTERED.
Lors du rétablissement, un pool qui ne peut pas être importé par le contrôleur B car il est défaillant déclenche la réinitialisation du contrôleur B. L'opération de rétablissement échoue et le contrôleur A continue de fournir tous les services.
Lorsque vous planifiez une opération de rétablissement, tenez compte des points suivants :
Le rétablissement perturbe les clients du cluster.
Retarder le rétablissement est tout aussi, voire plus perturbant encore, si l'unique contrôleur actif tombe en panne avant que le rétablissement soit effectué.
Pour réduire le temps d'arrêt pour maintenance, les données ne sont pas collectées et les statistiques et les ensembles de données ne sont pas disponibles lors des opérations de rétablissement et de reprise. Les demandes de suspension ou de reprise des statistiques sont différées jusqu'à la fin des opérations de rétablissement et de reprise. La collecte de données reprend automatiquement une fois les opérations de rétablissement et de reprise terminées.
Rubriques connexes