Reprise et rétablissement du cluster

Les nœuds de contrôleur clustérisés se trouvent dans l'un des petits ensembles d'états à un moment donné :

Etat Icône Expression de la CLI/BUI Description UNCONFIGURED Le clustering n'est pas configuré Un système ne contenant aucun clustering possède cet état. Soit le système est en cours de configuration, soit la tâche de configuration du cluster n'a jamais été terminée. OWNER Actif (reprise terminée) Le clustering est configuré et ce noeud a pris le contrôle de toutes les ressources partagées de ce cluster. Un système saisit immédiatement cet état dans son interface utilisateur une fois la configuration du cluster effectuée et lorsqu'il détecte l'échec de son pair (p. ex après la reprise). Il reste dans cet état jusqu'à ce qu'un administrateur exécute manuellement une opération de rétablissement. STRIPPED Prêt (en attente du rétablissement) Le clustering est configuré et ce noeud ne contrôle aucune ressource de données. Un système reçoit immédiatement l'état STRIPPED une fois la configuration du cluster terminée à partir de l'interface utilisateur de l'autre noeud, ou à la suite d'une réinitialisation, d'une coupure de courant ou d'une autre panne. Un noeud reste dans cet état jusqu'à ce qu'un administrateur exécute manuellement une opération de rétablissement. CLUSTERED Actif Le clustering est configuré et les deux noeuds possèdent des ressources partagées en fonction des ressources qui leur sont affectées. Si chaque noeud possède un pool ZFS et qu'il est défini sur l'état CLUSTERED, les deux noeuds forment ce qui est communément appelé un cluster actif-actif. - Retour au cluster... L'appareil a été récemment réinitialisé ou le logiciel de gestion des appareils a été redémarré après une panne interne. L'état de la ressource est en cours de resynchronisation. - Inconnu (déconnecté ou en cours de redémarrage) L'appareil pair est hors tension ou en cours de réinitialisation, toutes ses liaisons d'interconnexion sont interrompues ou le clustering n'a pas encore été configuré.

Les transitions entre ces états ont lieu dans le cadre de deux opérations : la reprise et le rétablissement.

La reprise peut avoir lieu à tout moment et est tentée dès qu'une défaillance du pair est détectée. Vous pouvez également la déclencher manuellement à l'aide de la CLI ou de la BUI de configuration du cluster, ce qui peut être utile à des fins de test. Enfin, la reprise a lieu lorsqu'un contrôleur est initialisé et qu'il détecte que son pair est absent. Cela permet au service de reprendre normalement lorsqu'un contrôleur est en panne de façon permanente ou lorsque les deux contrôleurs ont subi temporairement une panne de courant.

Le rétablissement ne se fait jamais automatiquement. Lorsqu'un contrôleur est réparé puis réinitialisé, il rejoint le cluster (en resynchronisant l'affichage de toutes ses ressources et propriétés) puis attend qu'un administrateur exécute une opération de rétablissement. Jusqu'ici, le contrôleur encore fonctionnel d'origine continue de fournir tous les services. Cela permet d'étudier en détail le problème à l'origine de la reprise, de valider une nouvelle révision du logiciel ou de réaliser d'autres tâches d'administration avant que le contrôleur ne reprenne le service de production. Etant donné que le rétablissement perturbe les clients, il doit être planifié en fonction des besoins et des processus métier spécifiques. Il existe une exception : supposons que le contrôleur A soit en panne et que le contrôleur B ait pris le relais. Lorsque le contrôleur A rejoint le cluster, il peut assurer une reprise s'il détecte que le contrôleur B est absent ou défectueux. Le principe est le suivant : il vaut toujours mieux être en service qu'inactif, même si cela implique de ne pas examiner le problème d'origine. Alors que le rétablissement vers un contrôleur précédemment défaillant ne s'effectue jamais automatiquement, il peut néanmoins effectuer la reprise à tout moment.

Une fois que vous avez configuré un cluster, l'état initial comprend le noeud ayant initialisé la configuration, dont l'état est OWNER, ainsi que l'autre noeud dont l'état est STRIPPED. Après avoir exécuté une opération de rétablissement initiale pour octroyer au noeud STRIPPED sa part de ressources partagées, les deux noeuds sont CLUSTERED. Si les deux noeuds clustérisés sont en panne ou mis hors tension, ils font l'objet d'un arbitrage lors du démarrage, au cours duquel l'un d'eux devient OWNER et l'autre STRIPPED.

Durant le rétablissement, toutes les ressources étrangères (celles qui sont assignées au pair) sont exportées puis importées par le pair. Un pool qui ne peut pas être importé en raison de sa défaillance déclenche la réinitialisation du noeud STRIPPED. Une tentative de rétablissement à l'aide d'un pool défectueux peut réinitialiser le noeud STRIPPED en raison de l'échec d'importation.

Pour réduire le temps d'arrêt pour maintenance, les statistiques et les ensembles de données ne sont pas disponibles lors des opérations de rétablissement et de reprise. Les données ne sont pas collectées et toute tentative de suspension ou de reprise des statistiques est différée jusqu'à la fin des opérations de rétablissement et de reprise et jusqu'à la reprise automatique de la collecte de données.

Rubriques connexes

• Arrêt de la configuration clustérisée (CLI)