Ignorer les liens de navigation | |
Quitter l'aperu | |
![]() |
Guide d'administration des systèmes Oracle® ZFS Storage Appliance |
Utilisation de la présente documentation
Chapitre 1 Présentation d'Oracle ZFS Storage Appliance
Chapitre 3 Configuration initiale
Chapitre 4 Configuration réseau
Chapitre 5 Configuration de stockage
Chapitre 6 Configuration du réseau de stockage SAN
Chapitre 7 Configuration utilisateur
Chapitre 8 Définition des préférences de ZFSSA
Chapitre 9 Configuration des alertes
Chapitre 10 Configuration de cluster
Fonctions et avantages du cluster
E/S d'interconnexion de cluster
Présentation de la gestion des ressources du cluster
Modifications de la configuration dans un environnement clusterisé
Considérations relatives au clustering pour le stockage
Considérations relatives au clustering pour la gestion réseau
Considérations relatives au clustering pour Infiniband
Scénarios de chemin redondant de clustering
Prévention des conditions 'split-brain'
Estimation et réduction de l'impact de la reprise
Configuration du cluster à l'aide de la BUI
Annulation de la configuration du clustering
Configuration du clustering à l'aide de la CLI
Arrêt de la configuration clusterisée
Annulation de la configuration du clustering
Câblage des clusters ZS3-4 et 7x20
Câblage des étagères de stockage
Page de la BUI de configuration du cluster
Chapitre 12 Partages, projets et schéma
Chapitre 15 Ecriture de scripts à l'aide de la CLI
Les noeuds de tête clusterisés se trouvent dans l'un des petits ensembles d'états à tout moment donné :
|
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.