JavaScript is required to for searching.
Ignorer les liens de navigation
Quitter l'aperu
Guide d'administration des systèmes Oracle® ZFS Storage Appliance
Oracle Technology Network
Bibliothque
PDF
Aperu avant impression
Commentaires
search filter icon
search icon

Informations document

Utilisation de la présente documentation

Chapitre 1 Présentation d'Oracle ZFS Storage Appliance

Chapitre 2 Statut

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

Inconvénients du cluster

Terminologie du cluster

Présentation du clustering

E/S d'interconnexion de cluster

Présentation de la gestion des ressources du cluster

Reprise et rétablissement 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

Interfaces IP locales privées

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

Configuration du clustering

Annulation de la configuration du clustering

Configuration du clustering à l'aide de la CLI

Arrêt de la configuration clusterisée

Arrêt de la tête de secours

Annulation de la configuration du clustering

Câblage des noeuds du cluster

Câblage du cluster ZS3-2

Câblage des clusters ZS3-4 et 7x20

Câblage des étagères de stockage

Page de la BUI de configuration du cluster

Chapitre 11 Services ZFSSA

Chapitre 12 Partages, projets et schéma

Chapitre 13 Réplication

Chapitre 14 Migration shadow

Chapitre 15 Ecriture de scripts à l'aide de la CLI

Chapitre 16 Maintenance des workflows

Chapitre 17 Intégration

Index

Modifications de la configuration dans un environnement clusterisé

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 :

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.