Ignorer les liens de navigation | |
Quitter la vue de l'impression | |
Guide d'administration des systèmes Oracle® ZFS Storage Appliance, version 2013.1.3.0 |
A propos d'Oracle ZFS Storage Appliance
Configuration d'Oracle ZFS Storage Appliance
Configuration initiale de l'appareil
Configuration initiale à l'aide de la BUI
Configuration initiale à l'aide de la CLI
Utilisation de la page de configuration réseau de la BUI
Configuration des périphériques réseau
Configuration des liaisons de données réseau
Configuration des interfaces réseau
Configuration du multiacheminement IP (IPMP) réseau
Configuration des performances et de la disponibilité réseau
Configuration du routage réseau
Configuration du réseau à l'aide de la BUI
Création d'une interface à port unique à l'aide de la BUI
Modification d'une interface à l'aide de la BUI
Création d'une interface à port unique à l'aide de la BUI
Création d'une interface de liaison groupée LACP à l'aide de la BUI
Extension d'un groupement LACP à l'aide de la BUI
Extension d'un groupe IPMP à l'aide de la BUI
Création d'une liaison de données et d'une interface de partition InfiniBand à l'aide de la BUI
Création d'un VNIC sans ID de VLAN pour des contrôleurs en cluster à l'aide de la BUI
Création de VNIC avec le même ID de VLAN pour des contrôleurs en cluster à l'aide de la BUI
Ajout d'une route statique à l'aide de la BUI
Suppression d'une route statique à l'aide de la BUI
Configuration du réseau à l'aide de la CLI
Ajout d'une route statique à l'aide de la CLI
Suppression d'une route statique à l'aide de la CLI
Réglage de la propriété de multihébergement sur strict à l'aide de la CLI
Configuration d'un profil de données
Importation de pools de stockage existants
Annulation de la configuration du stockage
Configuration d'un pool de stockage à l'aide de la BUI
Ajout de périphériques de cache à un pool existant à l'aide de la BUI
Ajout de périphériques de cache à un pool existant à l'aide de la CLI
Présentation du statut de l'appareil
Résumé de l'utilisation de la mémoire
Section Matériel du Tableau de bord
Tableau de bord d'activité du disque
Exécution continue de l'écran Tableau de bord
Paramètres de statut du tableau de bord
Modification des statistiques d'activité affichées
Modification des seuils d'activité
Configuration du réseau de stockage SAN
Configuration du protocole SAN Fibre Channel
Configuration des modes de port FC à l'aide de la BUI
Détection de ports FC à l'aide de la BUI
Création de groupes d'initiateurs FC à l'aide de la BUI
Association d'un LUN à un groupe d'initiateurs FC à l'aide de la BUI
Changement de mode de port FC à l'aide de la CLI
Détection de ports FC à l'aide de la CLI
Création de groupes d'initiateurs FC à l'aide de la CLI
Association d'un LUN à un groupe d'initiateurs FC à l'aide de la CLI
Scripts de création d'alias pour les initiateurs et groupes d'initiateurs à l'aide de la CLI
Configuration du protocole SAN iSCSI
Configuration des initiateurs SAN iSCSI
Création d'une feuille de travail d'analyse à l'aide de la BUI
Configuration des cibles SAN iSER
Ajout d'une cible iSCSI possédant un IQN généré de manière automatique à l'aide de la CLI
Ajout d'une cible iSCSI avec IQN spécifique et authentification RADIUS à l'aide de la CLI
Ajout d'un initiateur iSCSI utilisant l'authentification CHAP à l'aide de la CLI
Ajout d'un groupe de cibles iSCSI à l'aide de la CLI
Ajout d'un groupe d'initiateurs iSCSI à l'aide de la CLI
Configuration du protocole SAN SRP
Configuration des cibles SRP à l'aide de la BUI
Configuration des cibles SRP à l'aide de la CLI
Configuration des utilisateurs
Gestion des propriétés utilisateur
Ajout d'un administrateur à l'aide de la BUI
Ajout d'un rôle à l'aide de la BUI
Ajout d'autorisations à un rôle à l'aide de la BUI
Suppression des autorisations d'un rôle à l'aide de la BUI
Ajout d'un utilisateur uniquement autorisé à afficher le tableau de bord à l'aide de la BUI
Ajout d'un rôle à l'aide de la CLI
Ajout d'un administrateur à l'aide de la CLI
Ajout d'autorisations à un rôle à l'aide de la CLI
Suppression des autorisations d'un rôle à l'aide de la CLI
Définition des préférences d'Oracle ZFS Storage Appliance
Définition des préférences à l'aide de la CLI
Configurations des clés SSH publiques à l'aide de la CLI
Ajout d'une alerte avec seuil à l'aide de la BUI
Ajout d'une action d'alerte à l'aide de la BUI
Ajout d'une alerte avec seuil à l'aide de la CLI
Ajout d'une action d'alerte à l'aide de la CLI
Reprise/suspension d'ensembles de données
Reprise/suspension de feuilles de travail
Avantages et inconvénients des clusters
E/S d'interconnexion de 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
Considérations relatives au clustering pour Infiniband
Prévention des états 'split-brain'
Estimation et réduction de l'impact de la reprise
Configuration du clustering à l'aide de la BUI
Annulation de la configuration du clustering à l'aide de la BUI
Arrêt de la configuration clusterisée à l'aide de la CLI
Arrêt de la tête de secours à l'aide de la CLI
Annulation de la configuration du clustering à l'aide de la CLI
Câblage des clusters ZS4-4, ZS3-4 et 7x20
Câblage des étagères de stockage pour la mise en cluster
Le gestionnaire de ressources veille à la solidité de l'installation des interfaces réseau, vérifie que les pools de stockage adaptés sont actifs et s'assure de la synchronisation des nombreux paramètres de configuration avec les deux têtes clusterisées. La plupart des activités de ce sous-système sont invisibles pour les administrateurs ; néanmoins, un aspect important est exposé. Les ressources sont classées en plusieurs types qui régissent le moment où elles sont importées et décident de leur importation ou non (activation). Notez que la définition d'activation varie d'une classe de ressources à une autre. Par exemple, une interface réseau appartient à la classe net et devient active lorsque l'interface s'affiche. Les trois plus importants types de ressources sont singleton, privé et réplique.
Les répliques sont les plus simples : elles ne sont jamais exposées aux administrateurs et n'apparaissent pas dans l'écran de configuration du cluster (voir l'illustration 4). Les répliques existent toujours et sont toujours actives sur les deux têtes. De manière générale, elles agissent simplement comme des conteneurs de propriétés de service à synchroniser entre les deux têtes.
De même que les répliques, les ressources singleton permettent la synchronisation de l'état. Toutefois, les singletons sont toujours actifs sur une tête exactement. Les administrateurs peuvent choisir la tête sur laquelle activer le singleton de manière générale. En cas d'échec sur cette tête, son pair importe le singleton. Les singletons sont la clé des caractéristiques de disponibilité du clustering, ils représentent les ressources que l'on imagine déplacer d'une tête défaillante vers son pair encore fonctionnel et incluent les interfaces réseau et les pools de stockage. Etant donné qu'une interface réseau est un ensemble d'adresses IP utilisées par les clients pour rechercher un ensemble connu de services de stockage, il est essentiel que chaque interface soit assignée à la même tête que celle que les clients du pool de stockage s'attendent à voir en accédant aux adresses de l'interface. Dans l'illustration 4, toutes les adresses associées à l'interface PrimaryA sont toujours fournies par la tête ayant importé pool-0, tandis que les adresses associées à PrimaryB sont toujours fournies par la même tête que pool-1.
Les ressources privées sont uniquement connues par la tête à laquelle elles sont assignées et ne sont jamais reprises en cas de panne. Ce type est généralement utile pour les interfaces réseau (voir la discussion suivante relative aux cas d'utilisation spécifiques).
Figure 2-22 Exemple de clustering ZS3-2
D'autres types de ressources existent : il s'agit de détails d'implémentation qui ne sont pas exposés aux administrateurs. On trouve par exemple le type symbiote qui permet à une ressource d'en suivre une autre en cas d'importation et d'exportation. Ce type de ressource est le plus souvent utilisé pour représenter les disques et les périphériques flash dans le pool de stockage. Ces ressources se présentent sous la forme d'ensembles de disques et doivent toujours être importées avant le pool ZFS qu'elles contiennent. Chaque ensemble de disques est composé pour moitié de disques dans un boîtier de stockage externe. Un système de stockage clusterisé peut posséder un nombre illimité d'ensembles de disques joints (en fonction de la prise en charge matérielle) et chaque pool ZFS est formé à partir des périphériques de stockage dans un ou plusieurs ensembles de disques. Etant donné que les ensembles de disques peuvent contenir des périphériques ATA, ils doivent être importés et exportés de manière explicite afin d'éviter certains comportements liés à l'affiliation typiques des périphériques ATA utilisés dans des environnements à chemins d'accès multiples. Représenter ces disques sous forme de ressources est une manière simple d'effectuer ces activités au bon moment. Lorsqu'un administrateur définit ou modifie la propriété d'un pool de stockage, l'assignation de la propriété des ensembles de disques associés est modifiée simultanément de façon transparente. De même que tous les symbiotes, les ressources ensembles de disques n'apparaissent pas dans l'interface utilisateur de configuration du cluster.
|
Lorsqu'une nouvelle ressource est créée, elle est initialement assignée à la tête sur laquelle elle est créée. Il est impossible de modifier cette propriété tant que la tête possède l'état AKCS_OWNER. Il est donc nécessaire soit de créer des ressources sur la tête qui devrait les posséder, soit d'assurer le relais avant de modifier la propriété des ressources. Il est généralement possible de détruire des ressources sur toutes les têtes, à l'exception des pools de stockage exportés. Les meilleurs résultats sont généralement obtenus en détruisant les ressources sur la tête qui est alors chargée de les contrôler, indépendamment de la tête à laquelle la propriété est assignée.
La plupart des paramètres de configuration, notamment les propriétés du service, les utilisateurs, les rôles, les règles autohome SMB et les définitions d'initiateur iSCSI sont répliqués automatiquement sur les deux têtes. Il n'est donc jamais nécessaire de configurer ces paramètres sur les deux têtes, quel que soit l'état du cluster. Si un appareil est hors service durant la modification de la configuration, cette dernière est répliquée lorsque l'autre appareil rejoint le cluster à la prochaine initialisation, avant de fournir tout service. Il existe quelques exceptions :
Les définitions et les options des partages et des LUN peuvent uniquement être définies sur la tête qui contrôle le pool sous-jacent, indépendamment de la tête à laquelle le pool est normalement affecté.
La configuration du service "Identity" (c'est-à-dire le nom et l'emplacement de l'appareil) n'est pas répliquée.
Les noms donnés au châssis sont uniquement visibles sur la tête à laquelle ils ont été assignés.
Chaque route réseau est liée à une interface spécifique. Si chaque tête est associée à une interface contenant une adresse dans un sous-réseau particulier et que ce dernier contient un routeur vers lequel les appareils sont censés diriger le trafic, vous devez impérativement créer une route pour chaque interface, même lorsque l'adresse de passerelle est utilisée. Ainsi, chaque route peut devenir active individuellement lorsque le contrôle des ressources réseau sous-jacentes bascule d'une tête à une autre. Pour plus d'informations, reportez-vous aux considérations relatives à la gestion de réseaux.
Les clés d'hôte SSH ne sont pas répliquées et ne sont jamais partagées. Par conséquent, si aucune interface d'administration privée n'a été configurée, des incohérences de clé sont à prévoir lorsque vous tentez de vous connecter à la CLI à l'aide d'une adresse affectée à un noeud défaillant. Les mêmes limitations s'appliquent aux certificats SSL utilisés pour accéder à la BUI.
D'après le modèle de base, la configuration commune est répliquée de façon transparente et les administrateurs attribuent un ensemble de ressources à chaque tête de l'appareil. Ces affectations de ressources forment à leur tour la liaison des adresses réseau aux ressources de stockage que les clients s'attendent à voir. Quel que soit l'appareil qui contrôle l'ensemble des ressources, les clients peuvent accéder au stockage dont ils ont besoin sur les emplacements réseau auxquels ils s'attendent.