Reprise et rétablissement du cluster

Les noeuds de tête clusterisés se trouvent dans l'un des petits ensembles d'états à tout 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, comme indiqué ci-dessus, tandis que le rétablissement est tenté dès qu'une défaillance est détectée. Vous pouvez également le déclencher manuellement à l'aide de la CLI ou de la BUI de configuration du cluster. Cela peut être utile à des fins de test ou pour effectuer des mises à niveau logicielles non simultanées (lors desquelles une tête est mise à niveau tandis que l'autre fournit le service exécutant l'ancien logiciel, une fois le nouveau logiciel validé, la deuxième tête est alors mise à niveau). Enfin, la reprise a lieu lorsqu'une tête est initialisée et qu'elle détecte que son pair est absent. Cela permet au service de fonctionner à nouveau normalement lorsqu'une tête est défaillante de façon permanente ou lorsque les deux têtes sont temporairement hors tension.

Le rétablissement ne se fait jamais automatiquement. Lorsqu'une tête défaillante est réparée puis réinitialisée, elle 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, la tête encore fonctionnelle 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 la tête 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 la tête A soit en panne et que la tête B ait pris le relais. Lorsque la tête A rejoint le cluster, elle peut assurer une reprise si elle détecte que la tête B est absente ou défectueuse. 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 une tête précédemment défaillante ne s'effectue jamais automatiquement, il peut néanmoins effectuer la reprise à tout moment.

Lorsque vous configurez 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 clusterisé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.