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
Reprise et rétablissement du cluster
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
La majorité de la configuration de l'appareil est représentée par des propriétés service ou des propriétés partage/LUN. Alors que les propriétés partage et LUN sont stockées avec les données de l'utilisateur sur le pool de stockage (et sont par conséquent toujours accessibles au propriétaire en cours de cette ressource de stockage), la configuration de service est stockée dans chaque tête. Afin de garantir que les deux têtes fournissent un service cohérent, toutes les propriétés service doivent être synchronisées en cas de modification ou lorsqu'une tête précédemment hors service rejoint son pair. Etant donné que tous les services sont représentés par des ressources réplique, la synchronisation est automatiquement effectuée par le logiciel de l'appareil dès lors qu'une propriété est modifiée sur l'une des têtes.
Par conséquent, il n'est pas nécessaire pour les administrateurs de répliquer les modifications de la configuration (ce qui serait redondant). Les procédures de fonctionnement standard doivent refléter cet attribut et appeler à des modifications sur une seule des deux têtes en cas de modification de la configuration du cluster d'origine. Notez également que le processus de configuration du cluster d'origine réplique toute la configuration existante sur le pair bénéficiant d'une nouvelle configuration. Il en découle généralement deux meilleures pratiques en matière de modification de la configuration en cluster :
Apporter toutes les modifications de la configuration liées au stockage et au réseau sur la tête qui contrôle actuellement (ou contrôlera plus tard, si une nouvelle ressource est en cours de création) les ressources de stockage ou d'interface réseau sous-jacentes.
Apporter toutes les autres modifications sur une des têtes, mais pas les deux. La stratégie de site doit permettre de spécifier la tête principale à utiliser, qui doit à son tour dépendre de la tête qui fonctionne et du nombre de pools de stockage configurés. Notez que le logiciel de l'appareil ne fait pas cette distinction.
Le problème d'amnésie, selon lequel des modifications disjointes de configuration sont effectuées puis perdues sur chaque tête lorsque son pair ne fonctionne pas, est très surestimé. Cela est particulièrement vrai pour la série Oracle ZFS Storage Appliance, qui n'inclut aucun mécanisme pour effectuer des modifications indépendantes de la configuration système sur chaque tête. Cette simplification réduit considérablement le besoin de référentiels de configuration centralisés et plaide pour une approche simplifiée : la tête en cours de fonctionnement est censée détenir la configuration appropriée et son pair sera synchronisé par rapport à elle lors de l'initialisation. Alors que des améliorations futures du produit pourront permettre de sélectionner une stratégie alternative pour la résolution des divergences de configuration, cette approche basique est simple et facile à comprendre : la deuxième tête adopte un ensemble de paramètres de configuration déjà utilisés par un système de production existant (dont le degré d'exactitude est par conséquent très élevé). Pour s'assurer que cela reste vrai, les administrateurs doivent vérifier qu'une tête défaillante rejoint le cluster dès sa réparation.