Les configurations Oracle HSM haute disponibilité sont conçues pour maintenir des services d'archivage et de système de fichiers ininterrompus. Dans une solution de haute disponibilité, le logiciel Oracle HSM ou QFS est intégré au logiciel Oracle Solaris Cluster, au matériel redondant et aux communications redondantes. Si un système hôte ou un composant échoue ou est mis hors service par les administrateurs, les services Oracle HSM basculent automatiquement sur un hôte de remplacement auquel les utilisateurs et les applications peuvent accéder. Les configurations haute disponibilité réduisent ainsi les périodes d'inactivité dues à une panne de l'équipement ou du système.
Les configurations haute disponibilité sont complexes et doivent être soigneusement conçues et déployées pour éviter les interactions imprévues et, éventuellement, l'altération des données. Ce chapitre démarre par une explication des configurations prises en charge. Etudiez cette section et sélectionnez la configuration qui répond le mieux à vos exigences en matière de disponibilité. Les sections suivantes expliquent ensuite comment configurer la configuration sélectionnée.
Notez que vous ne pouvez pas mélanger les architectures matérielles dans une configuration Oracle Solaris Cluster partagée. Tous les noeuds doivent utiliser l'architecture SPARC, l'architecture x86-64 (Solaris 11.1 uniquement) ou l'architecture x86 32 bits (Solaris 10 et versions antérieures).
Dans les solutions en cluster à plusieurs hôtes, les interactions entre les systèmes de fichiers, les applications, les systèmes d'exploitation, le logiciel de mise en cluster et le stockage doivent être soigneusement contrôlées pour assurer l'intégrité des données stockées. Pour réduire la complexité et les risques potentiels, les configurations Oracle HSM haute disponibilité prises en charge sont adaptées à quatre ensembles spécifiques d'exigences de déploiement :
HA-QFS : configuration de système de fichiers QFS autonome, non partagée et de haute disponibilité
HA-SAM, une configuration de système de fichiers QFS partagé, haute disponibilité et avec archivage
SC-RAC, une configuration de système de fichiers QFS partagé et haute disponibilité pour Oracle RAC.
La configuration QFS haute disponibilité (HA-QFS) permet de garantir qu'un système de fichiers QFS autonome et non partagé reste accessible en cas de panne de l'hôte. Le système de fichiers est configuré sur les deux noeuds dans un cluster à deux noeuds géré par le logiciel Solaris Cluster en tant que ressource du type SUNW.HAStoragePlus. Mais, à tout moment, seul un noeud monte le système de fichiers QFS. Si le noeud qui monte le système de fichiers tombe en panne, le logiciel de clustering procède au basculement et remonte le système de fichiers sur le noeud restant.
Les clients accèdent aux données par le biais du système de fichiers réseau (NFS), du système de fichiers réseau haute disponibilité (HA-NFS) ou des partages SMB/CIFS avec le noeud de cluster actif jouant le rôle de serveur de fichiers.
Pour obtenir des instructions sur l'implémentation, reportez-vous à la Systèmes de fichiers non partagés QFS haute disponibilité.
La configuration HA-COTC (clients haute disponibilité hors du cluster) assure la disponibilité d'un serveur de métadonnées QFS de sorte que les clients du système de fichiers QFS puissent continuer d'accéder à leurs données en cas de panne d'un serveur. Le système de fichiers est partagé. Les serveurs QFS actifs et de métadonnées potentiels sont hébergés sur un cluster à deux noeuds géré par le logiciel Solaris Cluster. Une ressource Oracle HSM haute disponibilité de type SUNW.qfs gère le basculement pour les serveurs de systèmes de fichiers partagés au sein du cluster. Tous les clients sont hébergés en dehors du cluster. Les serveurs en cluster s'assurent de la disponibilité des métadonnées, délivrent des licences d'E/S et assurent la cohérence du système de fichiers.
Si le noeud qui héberge le serveur de métadonnées actif tombe en panne, le logiciel Solaris Cluster active automatiquement le serveur de métadonnées (MDS) potentiel sur le noeud en bon état et lance le basculement. Le système de fichiers QFS est partagé. Il est donc déjà monté sur le noeud du serveur de métadonnées qui vient d'être activé et reste monté sur les clients. Les clients continuent de recevoir les mises à jour des métadonnées et les baux d'E/S, donc le système de fichiers peut continuer sans interruption.
Les configurations HA-COTC doivent utiliser des systèmes de fichiers ma haute performance avec des périphériques de métadonnées mm et des périphériques de données mr physiquement séparés. Les systèmes de fichiers ms à usage général et les périphériques md ne sont pas pris en charge.
Vous pouvez utiliser un système de fichiers réseau (NFS) standard ou SMB/CIFS pour partager les systèmes de fichiers HA-COTC avec des clients qui n'exécutent pas Oracle HSM. Toutefois, HA-NFS n'est pas pris en charge.
Pour obtenir des instructions d'implémentation, reportez-vous à la Systèmes de fichiers partagés QFS haute disponibilité, clients en dehors du cluster.
La configuration Oracle Hierarchical Storage Manager (HA-SAM) haute disponibilité garantit la disponibilité d'un système de fichiers d'archivage en s'assurant que le serveur de métadonnées QFS et l'application Oracle Hierarchical Storage Manager continuent de fonctionner en cas de panne d'un hôte de serveur. Le système de fichiers est partagé entre les serveurs de métadonnées QFS actifs et potentiels hébergés sur un cluster à deux noeuds géré par le logiciel Solaris Cluster. Une ressource Oracle HSM haute disponibilité du type SUNW.qfs gère le basculement pour les serveurs.
En cas de panne du noeud du serveur de métadonnées Oracle HSM actif, le logiciel de clustering active automatiquement le noeud du serveur de métadonnées potentiel et lance le basculement. Le système de fichiers QFS étant partagé et déjà monté sur tous les noeuds, l'accès aux données et métadonnées reste ininterrompu.
Les clients accèdent aux données par le biais du système de fichiers réseau (NFS), du système de fichiers réseau haute disponibilité (HA-NFS) ou des partages SMB/CIFS avec le noeud de cluster actif jouant le rôle de serveur de fichiers.
Pour obtenir des instructions d'implémentation, reportez-vous à la Systèmes de fichiers d'archivage partagés Oracle HSM haute disponibilité,.
La configuration SC-RAC (Solaris Cluster-Oracle Real Application Cluster) prend en charge les solutions de base de données haute disponibilité qui utilisent les systèmes de fichiers QFS. Le logiciel RAC coordonne les demandes d'E/S, distribue la charge de travail et conserve un ensemble unique et cohérent de fichiers de base de données pour plusieurs instances Oracle Database exécutées sur les noeuds d'un cluster. Dans la configuration SC-RAC, Oracle Database, Oracle Real Application Cluster (RAC) et le logiciel QFS sont exécutés sur deux noeuds du cluster ou plus. Le logiciel Solaris Cluster gère le cluster comme une ressource de type SUNW.qfs. Un noeud est configuré en tant que serveur de métadonnées (MDS) d'un système de fichiers partagé QFS. Les autres noeuds sont configurés en tant que serveurs de métadonnées potentiels qui partagent le système de fichiers en tant que clients. Si le noeud du serveur de métadonnées actif tombe en panne, le logiciel Solaris Cluster active automatiquement un serveur de métadonnées potentiel sur un noeud en bon état et lance le basculement. Le système de fichiers QFS étant partagé et déjà monté sur tous les noeuds, l'accès aux données reste ininterrompu.
Pour configurer un système de fichiers QFS haute disponibilité (HA-QFS), vous devez configurer deux hôtes identiques dans un cluster Solaris à deux noeuds géré en tant que ressource du type SUNW.HAStoragePlus. Vous devez ensuite configurer un système de fichiers QFS non partagé sur les deux noeuds. Seul un noeud monte le système de fichiers à tout moment. Cependant, si un noeud tombe en panne, le logiciel de clustering lance automatiquement le basculement et remonte le système de fichiers sur le noeud restant.
Pour configurer un système de fichiers QFS haute disponibilité (HA-QFS), procédez comme suit :
Création de systèmes de fichiers QFS non partagés sur les deux noeuds du cluster
Configuration du système de fichiers QFS haute disponibilité
Si nécessaire, configurez le partage du système de fichiers réseau haute disponibilité (HA-NFS).
Les procédures détaillées relatives à la configuration de HA-NFS sont incluses dans le manuel Oracle Solaris Cluster Data Service for Network File System (NFS) Guide inclus dans la bibliothèque de documentation en ligne Oracle Solaris Cluster.
Connectez-vous à l'un des noeuds du cluster en tant qu'utilisateur root.
Dans l'exemple, les hôtes sont qfs1mds-node1 et qfs1mds-node2. Nous nous connectons à l'hôte qfs1mds-node1 :
[qfs1mds-node1]root@solaris:~#
Configurez le système de fichiers QFS souhaité sur l'hôte, mais ne le montez pas.
Configurez le système de fichiers à l'aide des instructions fournies dans la Configuration d'un système de fichiers ms à usage généraliste ou la Configuration d'un système de fichiers ma haute performance. La configuration HA-QFS ne prend pas en charge les systèmes de fichiers partagés QFS.
Connectez-vous au noeud de cluster restant en tant qu'utilisateur root.
Dans l'exemple, nous nous connectons à l'hôte qfs1mds-node2 à l'aide de ssh :
[qfs1mds-node1]root@solaris:~# ssh root@qfs1mds-node2 Password: [qfs1mds-node2]root@solaris:~#
Configurez un système de fichiers QFS identique sur le deuxième noeud.
Puis, configurez le système de fichiers QFS haute disponibilité.
Procédez comme suit :
Connectez-vous à l'un des noeuds du cluster en tant qu'utilisateur root.
Dans l'exemple, les hôtes sont qfs1mds-node1 et qfs1mds-node2. Nous nous connectons à l'hôte qfs1mds-node1 :
[qfs1mds-node1]root@solaris:~#
Si vous ne l'avez pas déjà fait, définissez le type de ressource SUNW.HAStoragePlus pour le logiciel Solaris Cluster. Exécutez la commande clresourcetype register SUNW.HAStoragePlus.
HAStoragePlus est le type de ressource Solaris Cluster qui définit et gère les dépendances entre les groupes de périphériques de disque, les systèmes de fichiers en cluster et les systèmes de fichiers locaux. Il coordonne le démarrage du basculement des services de données, de sorte que tous les composants requis soient prêts lorsque le service tente de redémarrer. Pour plus d'informations, reportez-vous à la page de manuel SUNW.HAStoragePlus.
[qfs1mds-node1]root@solaris:~# clresourcetype register SUNW.HAStoragePlus [qfs1mds-node1]root@solaris:~#
Créez une nouvelle ressource Solaris Cluster du type SUNW.HAStoragePlus et un nouveau groupe de ressources pour la contenir. Exécutez la commande /usr/global/bin/clresource create -g resource-group -t SUNW.HAStoragePlus -x FilesystemMountPoints=/global/mount-point -x FilesystemCheckCommand=/bin/true QFS-resource, où :
resource-group correspond au nom que vous avez choisi pour le groupe de ressources du système de fichiers.
mount-point correspond au répertoire dans lequel le système de fichiers QFS est monté.
QFS-resource correspond au nom que vous avez donné à la ressource SUNW.HAStoragePlus.
Dans cet exemple, nous créons le groupe de ressources qfsrg avec le répertoire de point de montage /global/qfs1 et la ressource SUNW.HAStoragePlus haqfs (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[qfs1mds-node1]root@solaris:~# clresource create -g qfsrg -t SUNW.HAStoragePlus \ -x FilesystemMountPoints=/global/hsmqfs1/qfs1 \ -x FilesystemCheckCommand=/bin/true haqfs [qfs1mds-node1]root@solaris:~#
Affichez les noeuds dans le cluster. Exécutez la commande clresourcegroup status.
Dans l'exemple, les noeuds de l'hôte du système de fichiers QFS sont qfs1mds-1 et qfs1mds-2. Le noeud qfs1mds-1 est en ligne (Online). Il s'agit donc du noeud principal qui monte le système de fichiers et héberge le groupe de ressources qfsrg :
[qfs1mds-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- --------- --------- ------ qfsrg qfs1mds-1 No Online qfs1mds-2 No Offline [qfs1mds-node1]root@solaris:~#
Assurez-vous que le groupe de ressources bascule correctement en déplaçant le groupe de ressources vers le noeud secondaire. Exécutez la commande Solaris Cluster clresourcegroup switch -n node2 group-name, où node2 correspond au nom du noeud secondaire et group-name correspond au nom que vous avez choisi pour le groupe de ressources HA-QFS. Exécutez ensuite clresourcegroup status pour vérifier le résultat.
Dans l'exemple, nous déplaçons le groupe de ressources haqfs vers qfs1mds-node2 et confirmons que le groupe de ressources se met en ligne sur le noeud spécifié :
[qfs1mds-node1]root@solaris:~# clresourcegroup switch -n qfs1mds-node2 qfsrg [qfs1mds-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- --------- --------- ------ qfsrg qfs1mds-1 No Offline qfs1mds-2 No Online [qfs1mds-node1]root@solaris:~#
Replacez le groupe de ressources sur le noeud principal. Exécutez la commande Solaris Cluster clresourcegroup switch -n node1 group-name, où node1 correspond au nom du noeud principal et group-name correspond au nom que vous avez choisi pour le groupe de ressources HA-QFS. Exécutez ensuite clresourcegroup status pour vérifier le résultat.
Dans l'exemple, nous avons replacé le groupe de ressources qfsrg sur qfs1mds-node1 :
[qfs1mds-node1]root@solaris:~# clresourcegroup switch -n qfs1mds-node1 qfsrg [qfs1mds-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ qfsrg qfs1mds-node1 No Online qfs1mds-node2 No Offline [qfs1mds-node1]root@solaris:~#
Si vous avez besoin de configurer le partage HA-NFS (système de fichiers réseau haute disponibilité), faites-le maintenant. Pour obtenir des instructions, reportez-vous au manuel Oracle Solaris Cluster Data Service for Network File System (NFS) Guide inclus dans la bibliothèque de documentation en ligne Oracle Solaris Cluster.
Si vous prévoyez d'utiliser la fonctionnalité de base de données sideband, reportez-vous au Configuration de la base de données de rapports.
Sinon, passez à la Configuration des notifications et de la journalisation.
La configuration HA-COTC (haute disponibilité-clients en dehors du cluster) est un système de fichiers partagé QFS sans archivage qui héberge le serveur de métadonnées (MDS) essentiel sur les noeuds d'un cluster haute disponibilité géré par le logiciel Solaris Cluster. Cette disposition fournit la protection via basculement pour les métadonnées QFS et les baux d'accès aux fichiers, de sorte que les clients du système de fichiers ne perdent pas l'accès à leurs données si un serveur tombe en panne. Les clients de système de fichiers et les périphériques de données restent toutefois hors du cluster, de sorte que Solaris Cluster lutte contre le logiciel QFS pour le contrôle des données partagées QFS.
Pour configurer un système de fichiers HA-COTC, effectuez les tâches ci-dessous :
Configuration d'un serveur de métadonnées QFS actif sur le noeud principal du cluster HA-COTC
Configuration d'un serveur de métadonnées QFS potentiel sur le noeud secondaire du cluster HA-COTC
Configuration du basculement des serveurs de métadonnées HA-COTC
Si nécessaire, configurez les partages NFS (système de fichiers réseau), comme décrit dans la Accès aux systèmes de fichiers à partir de plusieurs hôtes à l'aide de NFS et SMB/CIFS. HA-NFS (NFS haute disponibilité) n'est pas pris en charge.
Dans un système de fichiers partagé QFS, vous devez configurer un fichier d'hôtes sur les serveurs de métadonnées, de sorte que tous les hôtes puissent accéder aux métadonnées pour le système de fichiers. Le fichier d'hôtes est stocké avec le fichier mcf dans le répertoire /etc/opt/SUNWsamfs/. Lors de la création initiale d'un système de fichiers partagé, la commande sammkfs -S configure le partage selon les paramètres stockés dans ce fichier. Créez-le maintenant en appliquant la procédure ci-dessous.
Connectez-vous au noeud principal du cluster HA-COTC en tant qu'utilisateur root.
Dans l'exemple, les hôtes sont qfs1mds-node1 et qfs1mds-node2. Nous nous connectons à l'hôte qfs1mds-node1 :
[qfs1mds-node1]root@solaris:~#
Affichez la configuration du cluster. Exécutez la commande /usr/global/bin/cluster show. Recherchez l'enregistrement de chaque nom de noeud (Node Name), puis notez le privatehostname, le nom de Transport Adapter et la propriété ip_address de chaque adaptateur réseau.
Les sorties des commandes peuvent être très longues. Ainsi, dans les exemples ci-dessous, les affichages trop longs sont abrégés à l'aide de points de suspension (...).
Dans les exemples, chaque noeud comporte deux interfaces réseau, qfe3 et hme0 :
Les adaptateurs hme0 disposent d'adresses IP sur le réseau privé que le cluster utilise pour la communication interne entre les noeuds. Le logiciel Solaris Cluster attribue un nom d'hôte privé correspondant à chaque adresse privée.
Par défaut, le nom d'hôte privé du noeud principal est clusternode1-priv et le nom d'hôte privé du noeud secondaire est clusternode2-priv.
Les adaptateurs qfe3 disposent d'adresses IP et de noms d'hôte publics (qfs1mds-node1 et qfs1mds-node2) que le cluster utilise pour le transport de données.
[qfs1mds-node1]root@solaris:~# cluster show ... === Cluster Nodes === Node Name: qfs1mds-node1... privatehostname: clusternode1-priv... Transport Adapter List: qfe3, hme0... Transport Adapter: qfe3... Adapter Property(ip_address): 172.16.0.12... Transport Adapter: hme0... Adapter Property(ip_address): 10.0.0.129... Node Name: qfs1mds-node2... privatehostname: clusternode2-priv... Transport Adapter List: qfe3, hme0... Adapter Property(ip_address): 172.16.0.13... Transport Adapter: hme0 Adapter Property(ip_address): 10.0.0.122
A l'aide d'un éditeur de texte, créez le fichier /etc/opt/SUNWsamfs/hosts.family-set-name sur le serveur de métadonnées, où family-set-name correspond au nom de famille du système de fichiers.
Dans cet exemple, nous créons le fichier hosts.qfs1 à l'aide de l'éditeur de texte vi. Nous ajoutons des en-têtes facultatives pour afficher les colonnes dans la table des hôtes, en commençant chaque ligne par le signe dièse (#), lequel indique un commentaire :
[qfs1mds-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/hosts.qfs1 # /etc/opt/SUNWsamfs/hosts.qfs1 # Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ----------
Dans la première colonne de la table, entrez les noms d'hôte des noeuds du serveur de métadonnées principal et secondaire, suivis par des espaces. Placez chaque entrée sur une ligne séparée.
Dans un fichier d'hôtes, les lignes sont des rangées (enregistrements) et les espaces sont des séparateurs de colonnes (champ). Dans cet exemple, la colonne Host Name des deux premières lignes contient les valeurs qfs1mds-node1 et qfs1mds-node2, soit les noms d'hôte des noeuds de cluster qui hébergent les serveurs de métadonnées pour le système de fichiers :
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- qfs1mds-node1 qfs1mds-node2
Dans la deuxième colonne de chaque ligne, commencez à fournir des informations Network Interface pour l'hôte Host Name. Saisissez le nom d'hôte privé ou l'adresse réseau privée Solaris Cluster de chaque noeud de cluster HA-COTC, suivi d'une virgule.
Les noeuds du serveur HA-COTC utilisent les noms d'hôte privés pour les communications de serveur à serveur au sein du cluster haute disponibilité. Dans cet exemple, nous utilisons les noms d'hôte privés clusternode1-priv et clusternode2-priv qui sont les noms par défaut assignés par le logiciel Solaris Cluster :
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- qfs1mds-node1 clusternode1-priv, qfs1mds-node2 clusternode2-priv,
A la suite de la virgule dans la deuxième colonne de chaque ligne, entrez un nom d'hôte public virtuel pour le serveur de métadonnées actif, suivi par des espaces.
Les noeuds de serveur HA-COTC utilisent le réseau de données public pour communiquer avec les clients, chacun résidant hors du cluster. Dans la mesure où l'adresse IP et le nom d'hôte du serveur de métadonnées actif changent lors du basculement (de qfs1mds-node1 à qfs1mds-node2 et inversement), nous utilisons un nom d'hôte virtuel (qfs1mds) pour les deux. Ultérieurement, nous configurerons le logiciel Solaris Cluster pour toujours acheminer les demandes pour qfs1mds vers le serveur de métadonnées actif :
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- qfs1mds-node1 clusternode1-priv,qfs1mds qfs1mds-node2 clusternode2-priv,qfs1mds
Dans la troisième colonne de chaque ligne, indiquez le nombre ordinal du serveur (1 pour le serveur de métadonnées actif et 2 pour le serveur de métadonnées potentiel), suivi par des espaces.
Dans cet exemple, il n'existe qu'un seul serveur de métadonnées : le noeud principal, qfs1mds-node1, est le serveur de métadonnées actif. Il s'agit donc du nombre ordinal 1. Le second noeud, qfs1mds-node2, correspond au nombre ordinal 2 :
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- qfs1mds-node1 clusternode1-priv,qfs1mds 1 qfs1mds-node2 clusternode2-priv,qfs1mds 2
Dans la quatrième colonne de chaque ligne, entrez 0 (zéro), suivi par des espaces.
Un 0 (zéro), un - (tiret) ou une valeur vierge dans la quatrième colonne indique que l'hôte est activé (on) : configuré avec accès au système de fichiers partagé. Un 1 (chiffre un) indique que l'hôte est désactivé off, configuré sans accès au système de fichiers (pour plus d'informations sur l'utilisation de ces valeurs lors de l'administration des systèmes de fichiers partagés, reportez-vous à la page de manuel samsharefs).
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- qfs1mds-node1 clusternode1-priv,qfs1mds 1 0 qfs1mds-node2 clusternode2-priv,qfs1mds 2 0
Dans la cinquième colonne de la ligne du noeud principal, entrez le mot-clé server.
Le mot-clé server identifie le serveur de métadonnées actif par défaut.
# Server On/ Additional
#Host Name Network Interface Ordinal Off Parameters
#------------ ----------------------------- ------- --- ----------
qfs1mds-node1 clusternode1-priv,qfs1mds 1 0 server
qfs1mds-node2 clusternode2-priv,qfs1mds 2 0
Ajoutez une ligne pour chaque hôte client, en définissant la valeur de Server Ordinal sur 0. Ensuite, enregistrez le fichier et fermez l'éditeur de texte.
Le nombre ordinal de serveur 0 identifie l'hôte comme un client plutôt qu'un serveur. Les clients HA-COTC ne sont pas membres du cluster et, par conséquent, communiquent uniquement via le réseau de données public du cluster. Ils disposent uniquement d'adresses IP publiques. Dans cet exemple, nous ajoutons deux clients, qfs1client1 et qfs1client2, par leur adresse IP publique, 172.16.0.133 et 172.16.0.147 plutôt que par leur nom d'hôte :
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- qfs1mds-node1 clusternode1-priv,qfs1mds 1 0 server qfs1mds-node2 clusternode2-priv,qfs1mds 2 0 qfs1client1 172.16.0.133 0 0 qfs1client2 172.16.0.147 0 0 :wq [qfs1mds-node1]root@solaris:~#
Placez une copie du fichier /etc/opt/SUNWsamfs/hosts.family-set-name global sur le serveur de métadonnées potentiel QFS (le second noeud du cluster HA-COTC).
Procédez maintenant à la création des fichiers d'hôtes locaux sur les serveurs QFS et les clients en dehors du cluster HA-COTC.
Dans une configuration haute disponibilité qui partage un système de fichiers avec les clients en dehors du cluster, vous devez vous assurer que les clients communiquent uniquement avec les serveurs du système de fichiers à l'aide du réseau de données public défini par le logiciel Solaris Cluster. Pour ce faire, vous utilisez des fichiers d'hôtes locaux QFS spécifiquement configurés pour acheminer de manière sélective le trafic réseau entre les clients et plusieurs interfaces réseau sur le serveur.
Chaque hôte du système de fichiers identifie les interfaces réseau des autres hôtes en commençant par vérifier le fichier /etc/opt/SUNWsamfs/hosts.family-set-name sur le serveur de métadonnées. Il vérifie ensuite son propre fichier /etc/opt/SUNWsamfs/hosts.family-set-name.local. S'il n'y a pas de fichier d'hôtes local, l'hôte utilise les adresses d'interfaces spécifiées dans le fichier d'hôtes global, dans l'ordre spécifié dans le fichier global. S'il y a un fichier d'hôtes local, l'hôte le compare avec le fichier global et utilise uniquement les interfaces répertoriées dans les deux fichiers, dans l'ordre spécifié dans le fichier local. En utilisant différentes adresses dans différentes dispositions dans chaque fichier, vous pouvez contrôler les interfaces utilisées par différents hôtes.
Pour configurer les fichiers d'hôtes locaux, suivez la procédure décrite ci-dessous :
Connectez-vous au noeud principal du cluster HA-COTC en tant qu'utilisateur root.
Dans l'exemple, les hôtes sont qfs1mds-node1 et qfs1mds-node2. Nous nous connectons à l'hôte qfs1mds-node1 :
[qfs1mds-node1]root@solaris:~#
Création de fichiers d'hôtes locaux sur chacun des serveurs de métadonnées actif et potentiel. A l'aide du chemin et du nom de fichier /etc/opt/SUNWsamfs/hosts.family-set-name.local, où family-set-name correspond à l'identificateur d'équipement du système de fichiers partagé. Incluez uniquement les interfaces pour les réseaux que vous souhaitez que les serveurs actifs et potentiels utilisent.
Dans notre exemple, nous souhaitons que les serveurs de métadonnées actifs et potentiels communiquent entre eux via le réseau privé et avec les clients via le réseau public. Ainsi, le fichier d'hôtes local sur les serveurs actifs et potentiels, hosts.qfs1.local, répertorie uniquement les adresses privées du cluster pour les serveurs actifs et potentiels :
[qfs1mds-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/hosts.qfs1.local # /etc/opt/SUNWsamfs/hosts.qfs1.local # Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- qfs1mds-node1 clusternode1-priv 1 0 server qfs1mds-node2 clusternode2-priv 2 0 qfs1client1 172.16.0.133 0 0 qfs1client2 172.16.0.147 0 0 :wq [qfs1mds-node1]root@solaris:~# ssh root@qfs1mds-node2 Password:
[qfs1mds-node2]root@solaris:~# vi /etc/opt/SUNWsamfs/hosts.qfs1.local # /etc/opt/SUNWsamfs/hosts.qfs1.local # Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- qfs1mds-node1 clusternode1-priv 1 0 server qfs1mds-node2 clusternode2-priv 2 0 qfs1client1 172.16.0.133 0 0 qfs1client2 172.16.0.147 0 0 :wq [qfs1mds-node2]root@solaris:~# exit [qfs1mds-node1]root@solaris:~#
Utilisez un éditeur de texte pour créer un fichier d'hôtes local sur chacun des clients. A l'aide du chemin et du nom de fichier /etc/opt/SUNWsamfs/hosts.family-set-name.local, où family-set-name correspond à l'identificateur d'équipement du système de fichiers partagé. Incluez uniquement les interfaces pour les réseaux que vous souhaitez que les clients utilisent. Ensuite, enregistrez le fichier et fermez l'éditeur de texte.
Dans notre exemple, nous utilisons l'éditeur vi. Nous souhaitons que les clients communiquent uniquement avec les serveurs via le réseau de données public. Le fichier ne comprend donc que le nom d'hôte virtuel pour le serveur de métadonnées actif qfs1mds. Le logiciel Solaris Cluster achemine les demandes pour qfs1mds vers le noeud de serveur actif :
[qfs1mds-node1]root@solaris:~# ssh root@qfsclient1 Password: [qfs1client1]root@solaris:~# vi /etc/opt/SUNWsamfs/hosts.qfs1.local # /etc/opt/SUNWsamfs/hosts.qfs1.local # Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- qfs1mds qfs1mds 1 0 server :wq qfs1client1]root@solaris:~# exit [qfs1mds-node1]root@solaris:~# ssh root@qfs1client2 Password: [qfs1client2]root@solaris:~# vi /etc/opt/SUNWsamfs/hosts.qfs1.local # /etc/opt/SUNWsamfs/hosts.qfs1.local # Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- qfs1mds qfs1mds 1 0 server :wq [qfs1client2]root@solaris:~# exit [qfs1mds-node1]root@solaris:~#
Procédez ensuite à la configuration d'un serveur de métadonnées QFS actif sur le noeud principal du cluster HA-COTC.
Pour configurer le serveur de métadonnées actif, effectuez les tâches suivantes :
Création d'un système de fichiers QFS haute performance sur le noeud HA-COTC principal
Exclusion des périphériques de données du contrôle de cluster
Montage du système de fichiers QFS sur le noeud HA-COTC principal.
Sélectionnez le noeud du cluster qui servira à la fois de noeud principal pour le cluster HA-COTC et de serveur de métadonnées actif pour le système de fichiers partagé QFS. Connectez-vous en tant que root.
Dans l'exemple, qfs1mds-node1 correspond au noeud principal et au serveur de métadonnées actif :
[qfs1mds-node1]root@solaris:~#
Sélectionnez les périphériques de stockage globaux qui seront utilisés pour le système de fichiers QFS. Exécutez la commande /usr/global/bin/cldevice list -v de Solaris Cluster.
Le logiciel Solaris Cluster assigne des identificateurs de périphériques (DID) uniques à tous les périphériques qui se connectent aux noeuds du cluster. Les périphériques globaux sont accessibles depuis tous les noeuds du cluster, tandis que les périphériques locaux sont accessibles uniquement depuis les hôtes qui les montent. Les périphériques globaux restent accessibles à la suite d'un basculement. Ce n'est pas le cas des périphériques locaux.
Dans l'exemple, notez que les périphériques d1, d2, d7 et d8 ne sont pas accessibles depuis les deux noeuds. Nous effectuons donc la sélection parmi les périphériques d3, d4 et d5 lors de la configuration du système de fichiers partagé QFS haute disponibilité :
[qfs1mds-node1]root@solaris:~# cldevice list -v DID Device Full Device Path ---------- ---------------- d1 qfs1mds-node1:/dev/rdsk/c0t0d0 d2 qfs1mds-node1:/dev/rdsk/c0t6d0 d3 qfs1mds-node1:/dev/rdsk/c1t1d0 d3 qfs1mds-node2:/dev/rdsk/c1t1d0 d4 qfs1mds-node1:/dev/rdsk/c1t2d0 d4 qfs1mds-node2:/dev/rdsk/c1t2d0 d5 qfs1mds-node1:/dev/rdsk/c1t3d0 d5 qfs1mds-node2:/dev/rdsk/c1t3d0 d6 qfs1mds-node2:/dev/rdsk/c0t0d0 d7 qfs1mds-node2:/dev/rdsk/c0t1d0
Sur le noeud principal sélectionné, créez un système de fichiers ma haute performance qui utilise les périphériques de données md ou mr. Dans un éditeur de texte, ouvrez le fichier /etc/opt/SUNWsamfs/mcf.
Dans l'exemple, nous configurons le système de fichiers qfs1. Nous configurons le périphérique d3 en tant que périphérique de métadonnées (type d'équipement mm), et utilisons d4 et d5 comme périphériques de données (type d'équipement mr) :
[qfs1mds-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf # Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #------------------ --------- --------- ------- ------ ---------------- qfs1 100 ma qfs1 - /dev/did/dsk/d3s0 101 mm qfs1 - /dev/did/dsk/d4s0 102 mr qfs1 - /dev/did/dsk/d5s1 103 mr qfs1 -
Dans le fichier /etc/opt/SUNWsamfs/mcf, entrez le paramètre shared dans la colonne Additional Parameters de l'entrée du système de fichiers. Enregistrez le fichier.
[qfs1mds-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf # Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #------------------ --------- --------- ------- ------ ---------------- qfs1 100 ma qfs1 - shared /dev/did/dsk/d3s0 101 mm qfs1 - /dev/did/dsk/d4s0 102 mr qfs1 - /dev/did/dsk/d5s1 103 mr qfs1 - :wq [qfs1mds-node1]root@solaris:~#
Recherchez les erreurs éventuelles dans le fichier mcf. Exécutez la commande /opt/SUNWsamfs/sbin/sam-fsd et corrigez les erreurs trouvées.
La commande sam-fsd lit les fichiers de configuration Oracle HSM et initialise les systèmes de fichiers. Elle s'arrête en cas d'erreur. Dans l'exemple, nous vérifions le fichier mcf sur l'hôte qfs1mds-node1 :
[qfs1mds-node1]root@solaris:~# sam-fsd
...
Would start sam-archiverd()
Would start sam-stagealld()
Would start sam-stagerd()
Would start sam-amld()
[qfs1mds-node1]root@solaris:~#
Créez le système de fichiers. Exécutez la commande /opt/SUNWsamfs/sbin/sammkfs -S family-set-name, où family-set-name correspond à l'identificateur d'équipement du système de fichiers.
La commande sammkfs lit les fichiers hosts.family-set-name et mcf sur le noeud principal, qfs1mds-node1, et crée un système de fichiers partagé avec les propriétés spécifiées.
[qfs1mds-node1]root@solaris:~# sammkfs -S qfs1 Building 'qfs1' will destroy the contents of devices: ... Do you wish to continue? [y/N]yes ... [qfs1mds-node1]root@solaris:~#
Procédez maintenant à l'exclusion des périphériques de données du contrôle de cluster.
Par défaut, le logiciel Solaris Cluster clôt les périphériques de disque pour l'utilisation exclusive du cluster. Dans les configurations HA-COTC, seuls les périphériques de métadonnées (mm) font partie du cluster. Les périphériques de données (mr) sont partagés avec les clients du système de fichiers en dehors du cluster et directement connectés aux hôtes du client. Vous devez donc placer les périphériques de données (mr) en dehors du contrôle du logiciel de cluster. Cela peut se faire de l'une des deux manières suivantes :
Connectez-vous au noeud principal du cluster HA-COTC et au serveur de métadonnées actif pour le système de fichiers partagé QFS. Connectez-vous en tant que root.
Dans l'exemple, qfs1mds-node1 correspond au noeud principal et au serveur de métadonnées actif :
[qfs1mds-node1]root@solaris:~#
Pour chaque périphérique de données (mr) défini dans le fichier /etc/opt/SUNWsamfs/mcf, désactivez la séparation. Exécutez la commande cldevice set -p default_fencing=nofencing-noscrub device-identifier, où device-identifier correspond à l'identificateur de périphérique répertorié pour le périphérique dans la première colonne du fichier mcf.
Ne désactivez pas la séparation pour les périphériques de métadonnées (mm). Dans les configurations HA-COTC, les périphériques de métadonnées QFS (mm) font partie du cluster, contrairement aux périphériques de données partagés QFS (mr). Les périphériques de données sont directement connectés aux clients en dehors du cluster. Pour cette raison, les périphériques de données HA-COTC (mr) doivent être gérés en tant que périphériques locaux qui ne sont pas gérés par le logiciel Solaris Cluster. Sinon, le logiciel Solaris Cluster et QFS sont susceptibles de travailler de manière contradictoire et de corrompre les données.
Dans les exemples ci-dessus, nous avons configuré les périphériques d4 et d5 en tant que périphériques de données pour le système de fichiers qfs1. Ainsi, nous désactivons globalement la séparation pour ces périphériques (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[qfs1mds-node1]root@solaris:~# cldevice set -p \ default_fencing=nofencing-noscrub d4 [qfs1mds-node1]root@solaris:~# cldevice set -p \ default_fencing=nofencing-noscrub d5
Procédez ensuite au montage du système de fichiers QFS sur le noeud principal du cluster HA-COTC.
Connectez-vous au noeud principal du cluster HA-COTC et au serveur de métadonnées actif pour le système de fichiers partagé QFS. Connectez-vous en tant que root.
Dans l'exemple, qfs1mds-node1 correspond au noeud principal et au serveur de métadonnées actif :
[qfs1mds-node1]root@solaris:~#
Placez tous les périphériques de données (mr) du système de fichiers dans un groupe de périphériques localonly. Utilisez la commande cldevicegroup set -d device-identifier-list -p localonly=true -n active-mds-node device-group, où device-list correspond à une liste séparée par des virgules d'identificateurs de périphériques, active-mds-node correspond au noeud principal sur lequel le serveur de métadonnées actif réside normalement et device-group correspond au nom que vous choisissez pour votre groupe de périphériques.
Dans l'exemple suivant, nous plaçons les périphériques de données d4 et d5 (numéros d'équipement mcf 102 et 103) dans le groupe de périphériques local mdsdevgrp sur le noeud principal (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[qfs1mds-node1]root@solaris:~# cldevicegroup set -d d4,d5 -p localonly=true \ -n node1mds mdsdevgrp [qfs1mds-node1]root@solaris:~#
Procédez ensuite au montage du système de fichiers QFS sur le noeud principal du cluster HA-COTC.
Connectez-vous au noeud principal du cluster HA-COTC et au serveur de métadonnées actif pour le système de fichiers partagé QFS. Connectez-vous en tant que root.
Dans l'exemple, qfs1mds-node1 correspond au noeud principal et au serveur de métadonnées actif :
[qfs1mds-node1]root@solaris:~#
Sauvegardez le fichier /etc/vfstab du système d'exploitation.
[qfs1mds-node1]root@solaris:~# cp /etc/vfstab /etc/vfstab.backup
Ouvrez le fichier /etc/vfstab du système d'exploitation dans un éditeur de texte et démarrez une ligne pour le nouveau système de fichiers. Entrez le nom du système de fichiers dans la première colonne (Device to Mount) suivi d'un ou de plusieurs espaces.
Dans l'exemple, utilisez l'éditeur de texte vi. Nous démarrons une ligne pour le système de fichiers qfs1 :
[qfs1mds-node1]root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ------------ ------ ---- ------- --------------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs1 -
Dans la deuxième colonne du fichier /etc/vfstab (Device to fsck), entrez un tiret (-) suivi d'au moins un espace.
Le tiret indique au système d'exploitation d'ignorer la vérification de l'intégrité du système de fichiers. Ces vérifications concernent les systèmes de fichiers UFS plutôt que SAMFS.
[qfs1mds-node1]root@solaris:~# vi /etc/vfstab
#File
#Device Device Mount System fsck Mount Mount
#to Mount to fsck Point Type Pass at Boot Options
#-------- ------- ------------ ------ ---- ------- ---------------------
/devices - /devices devfs - no -
/proc - /proc proc - no -
...
qfs1 -
Dans la troisième colonne du fichier /etc/vfstab, entrez le point de montage du système de fichiers par rapport au cluster. Sélectionnez un sous-répertoire qui ne se trouve pas directement en dessous du répertoire root du système.
Le montage d'un système de fichiers QFS partagé immédiatement sous la racine peut provoquer des problèmes de basculement lors de l'utilisation du type de ressource SUNW.qfs. Dans l'exemple, nous définissons le point de montage sur le cluster sur /global/ha-cotc/qfs1 :
#File
#Device Device Mount System fsck Mount Mount
#to Mount to fsck Point Type Pass at Boot Options
#-------- ------- -------------------- ------ ---- ------- --------------
/devices - /devices devfs - no -
/proc - /proc proc - no -
...
qfs1 - /global/ha-cotc/qfs1
Renseignez les champs restants de l'enregistrement de fichier /etc/vfstab comme vous le feriez pour n'importe quel système de fichiers QFS partagé. Ensuite, enregistrez le fichier et fermez l'éditeur de texte.
#File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- -------------------- ------ ---- ------- -------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs1 - /global/ha-cotc/qfs1 samfs - no shared :wq [qfs1mds-node1]root@solaris:~#
Créez un point de montage pour le système de fichiers partagé haute disponibilité.
La commande mkdir avec l'option -p (parents) crée le répertoire /global s'il n'existe pas déjà :
[qfs1mds-node1]root@solaris:~# mkdir -p /global/ha-cotc/qfs1
Montez le système de fichiers partagé haute disponibilité sur le noeud principal.
[qfs1mds-node1]root@solaris:~# mount /global/ha-cotc/qfs1
Procédez ensuite à la configuration d'un serveur de métadonnées QFS potentiel sur le noeud secondaire du cluster HA-COTC.
Le noeud secondaire du cluster à deux noeuds sert de serveur de métadonnées potentiel. Un serveur de métadonnées potentiel est un hôte qui peut accéder aux périphériques de métadonnées et, par conséquent, endosser les responsabilités d'un serveur de métadonnées. Ainsi, si le serveur de métadonnées actif sur le noeud principal tombe en panne, le logiciel Solaris Cluster peut basculer sur le noeud secondaire et activer le serveur de métadonnées potentiel. Pour configurer le serveur de métadonnées potentiel, effectuez les tâches suivantes :
Création d'un système de fichiers QFS haute performance sur le noeud HA-COTC secondaire
Montage du système de fichiers QFS sur le noeud HA-COTC secondaire.
Connectez-vous au noeud secondaire sur le cluster HA-COTC en tant qu'utilisateur root.
Dans l'exemple, qfs1mds-node2 est le noeud secondaire et le serveur de métadonnées potentiel :
[qfs1mds-node2]root@solaris:~#
Copiez le fichier /etc/opt/SUNWsamfs/mcf du noeud principal vers le noeud secondaire.
Recherchez les erreurs éventuelles dans le fichier mcf. Exécutez la commande /opt/SUNWsamfs/sbin/sam-fsd et corrigez les erreurs trouvées.
La commande sam-fsd lit les fichiers de configuration Oracle HSM et initialise les systèmes de fichiers. Elle s'arrête en cas d'erreur. Dans l'exemple, nous vérifions le fichier mcf sur l'hôte qfs1mds-node1 :
[qfs1mds-node2]root@solaris:~# sam-fsd
...
Would start sam-archiverd()
Would start sam-stagealld()
Would start sam-stagerd()
Would start sam-amld()
[qfs1mds-node2]root@solaris:~#
Procédez ensuite au montage du système de fichiers QFS sur le noeud secondaire du cluster HA-COTC.
Connectez-vous au noeud secondaire sur le cluster HA-COTC en tant qu'utilisateur root.
Dans l'exemple, qfs1mds-node2 est le noeud secondaire :
[qfs1mds-node2]root@solaris:~#
Sauvegardez le fichier /etc/vfstab du système d'exploitation.
[qfs1mds-node2]root@solaris:~# cp /etc/vfstab /etc/vfstab.backup
Ouvrez le fichier /etc/vfstab du système d'exploitation dans un éditeur de texte et ajoutez une ligne pour le nouveau système de fichiers. Ensuite, enregistrez le fichier et fermez l'éditeur de texte.
Dans cet exemple, nous utilisons l'éditeur de texte vi :
[qfs1mds-node2]root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- -------------------- ------ ---- ------- ------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs1 - /global/ha-cotc/qfs1 samfs - no shared :wq [qfs1mds-node2]root@solaris:~#
Créez le point de montage du système de fichiers partagé haute disponibilité sur le noeud secondaire.
[qfs1mds-node2]root@solaris:~# mkdir -p /global/ha-cotc/qfs1 [qfs1mds-node2]root@solaris:~#
Montez le système de fichiers partagé haute disponibilité sur le noeud secondaire.
[qfs1mds-node2]root@solaris:~# mount /global/ha-cotc/qfs1 [qfs1mds-node2]root@solaris:~#
Procédez maintenant à la configuration du basculement des serveurs de métadonnées HA-COTC.
Lorsque vous hébergez un système de fichiers partagé Oracle HSM dans un cluster géré par le logiciel Solaris Cluster, vous configurez le basculement des serveurs de métadonnées en créant une ressource de cluster SUNW.qfs, un type de ressource défini par le logiciel Oracle HSM (reportez-vous à la page de manuel SUNW.qfs pour plus d'informations). Pour créer et configurer la ressource pour une configuration HA-COTC, procédez comme suit :
Connectez-vous au noeud principal dans le cluster HA-COTC en tant qu'utilisateur root.
Dans l'exemple, qfs1mds-node1 est le noeud principal :
[qfs1mds-node1]root@solaris:~#
Définissez le type de ressource QFS, SUNW.qfs, pour le logiciel Solaris Cluster. Exécutez la commande clresourcetype register SUNW.qfs.
[qfs1mds-node1]root@solaris:~# clresourcetype register SUNW.qfs [qfs1mds-node1]root@solaris:~#
Si l'enregistrement échoue parce que le fichier d'enregistrement est introuvable, placez un lien symbolique vers le répertoire /opt/SUNWsamfs/sc/etc/ dans le répertoire dans lequel Solaris Cluster conserve les fichiers d'enregistrement de type de ressource, /opt/cluster/lib/rgm/rtreg/.
Vous n'avez pas installé le logiciel Oracle Solaris Cluster avant d'installer le logiciel Oracle HSM. Normalement, Oracle HSM fournit automatiquement l'emplacement du fichier d'enregistrement SUNW.qfs lorsqu'il détecte Solaris Cluster durant l'installation. Vous devez donc créer un lien manuellement.
[qfs1mds-node1]root@solaris:~# cd /opt/cluster/lib/rgm/rtreg/ [qfs1mds-node1]root@solaris:~# ln -s /opt/SUNWsamfs/sc/etc/SUNW.qfs SUNW.qfs [qfs1mds-node1]root@solaris:~#
Créez un groupe de ressources pour le serveur de métadonnées QFS. Exécutez la commande Solaris Cluster clresourcegroup create -n node-list group-name, où node-list correspond à une liste séparée par des virgules des deux noms de noeud de cluster et group-name correspond au nom que nous souhaitons utiliser pour le groupe de ressources.
Dans cet exemple, nous créons le groupe de ressources qfsrg avec les noeuds de serveur HA-COTC en tant que membres (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[qfs1mds-node1]root@solaris:~# clresourcegroup create -n \ qfs1mds-node1,qfs1mds-node2 qfsrg [qfs1mds-node1]root@solaris:~#
Dans le nouveau groupe de ressources, configurez un nom d'hôte virtuel pour le serveur de métadonnées actif. Exécutez la commande Solaris Cluster clreslogicalhostname create -g group-name virtualMDS, où group-name correspond au nom du groupe de ressources QFS et virtualMDS correspond au nom d'hôte virtuel.
Utilisez le même nom d'hôte virtuel que vous avez utilisé dans les fichiers d'hôtes pour le système de fichiers partagé. Dans l'exemple, nous créons l'hôte virtuel qfs1mds dans le groupe de ressources qfsr :
[qfs1mds-node1]root@solaris:~# clreslogicalhostname create -g qfsrg qfs1mds
Ajoutez les ressources du système de fichiers QFS au groupe de ressources. Exécutez la commande clresource create -g group-name -t SUNW.qfs -x QFSFileSystem=mount-point -y Resource_dependencies=virtualMDS resource-name, où :
group-name correspond au nom du groupe de ressources QFS.
mount-point correspond au point de montage du système de fichiers dans le cluster, un sous-répertoire qui n'est pas directement sous le répertoire root du système.
Le montage d'un système de fichiers QFS partagé immédiatement sous la racine peut provoquer des problèmes de basculement lors de l'utilisation du type de ressource SUNW.qfs.
virtualMDS correspond au nom d'hôte virtuel du serveur de métadonnées actif.
resource-name correspond au nom que vous souhaitez donner à la ressource.
Dans cet exemple, nous créons une ressource nommée hasqfs du type SUNW.qfs dans le groupe de ressources qfsrg. Nous définissons la propriété d'extension SUNW.qfs QFSFileSystem sur le point de montage /global/ha-cotc/qfs1 et définissons la propriété standard Resource_dependencies sur l'hôte logique pour le serveur de métadonnées actif, qfs1mds (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[qfs1mds-node1]root@solaris:~# clresource create -g qfsrg -t SUNW.qfs \ -x QFSFileSystem=/global/ha-cotc/qfs1 -y Resource_dependencies=qfs1mds hasqfs
Mettez le groupe de ressources en ligne. Exécutez la commande clresourcegroup online -emM group-name, où group-name correspond au nom du groupe de ressources QFS.
Dans l'exemple, nous mettons en ligne le groupe de ressources qfsr :
[qfs1mds-node1]root@solaris:~# clresourcegroup manage qfsrg [qfs1mds-node1]root@solaris:~# clresourcegroup online -emM qfsrg
Assurez-vous que le groupe de ressources QFS est en ligne. Exécutez la commande Solaris Cluster clresourcegroup status.
Dans l'exemple, le groupe de ressources qfsrg est online sur le noeud principal, sam1mds-node1 :
[qfs1mds-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ qfsrg qfs1mds-node1 No Online qfs1mds-node2 No Offline
Assurez-vous que le groupe de ressources bascule correctement en déplaçant le groupe de ressources vers le noeud secondaire. Exécutez la commande Solaris Cluster clresourcegroup switch -n node2 group-name, où node2 correspond au nom du noeud secondaire et group-name correspond au nom que vous avez choisi pour le groupe de ressources HA-QFS. Exécutez ensuite clresourcegroup status pour vérifier le résultat.
Dans l'exemple, nous déplaçons le groupe de ressources qfsrg vers qfs1mds-node2 et confirmons que le groupe de ressources se met en ligne sur le noeud spécifié :
[qfs1mds-node1]root@solaris:~# clresourcegroup switch -n qfs1mds-node2 qfsrg [qfs1mds-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ qfsrg qfs1mds-node1 No Offline qfs1mds-node2 No Online
Replacez le groupe de ressources sur le noeud principal. Exécutez la commande Solaris Cluster clresourcegroup switch -n node1 group-name, où node1 correspond au nom du noeud principal et group-name correspond au nom que vous avez choisi pour le groupe de ressources HA-QFS. Exécutez ensuite clresourcegroup status pour vérifier le résultat.
Dans l'exemple, nous avons replacé le groupe de ressources qfsrg sur qfs1mds-node1 :
[qfs1mds-node1]root@solaris:~# clresourcegroup switch -n qfs1mds-node1 qfsrg [qfs1mds-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ qfsrg qfs1mds-node1 No Online qfs1mds-node2 No Offline
Procédez ensuite à la configuration des hôtes en dehors du cluster HA-COTC en tant que clients du système de fichiers partagé QFS.
Configurez chaque hôte en tant que client QFS qui n'a pas accès aux périphériques de métadonnées du système de fichiers, de sorte que les clients n'interfèrent pas avec la configuration haute disponibilité des serveurs de métadonnées au sein du cluster.
Pour chaque client du système de fichiers partagé HA-COTC, procédez comme suit :
Connectez-vous au noeud principal dans le cluster HA-COTC. Connectez-vous en tant que root.
[qfs1mds-node1]root@solaris:~#
Affichez la configuration du périphérique du cluster. Exécutez la commande Solaris Cluster /usr/global/bin/cldevice list -v.
[qfs1mds-node1]root@solaris:~# cldevice list -v DID Device Full Device Path ---------- ---------------- d1 qfs1mds-node1:/dev/rdsk/c0t0d0 d2 qfs1mds-node1:/dev/rdsk/c0t6d0 ... d7 qfs1mds-node2:/dev/rdsk/c0t1d0 [qfs1mds-node1]root@solaris:~#
Observez la sortie de la commande cldevice list -v. Notez le chemin d'accès /dev/rdsk/ qui correspond à l'identificateur de périphérique pour chaque périphérique de données QFS (mr).
Dans l'exemple, les périphériques de données QFS sont d4 et d5 :
[qfs1mds-node1]root@solaris:~# cldevice list -v DID Device Full Device Path ---------- ---------------- d1 qfs1mds-node1:/dev/rdsk/c0t0d0 d2 qfs1mds-node1:/dev/rdsk/c0t6d0 d3 qfs1mds-node1:/dev/rdsk/c1t1d0 d3 qfs1mds-node2:/dev/rdsk/c1t1d0 d4 qfs1mds-node1:/dev/rdsk/c1t2d0 d4 qfs1mds-node2:/dev/rdsk/c1t2d0 d5 qfs1mds-node1:/dev/rdsk/c1t3d0 d5 qfs1mds-node2:/dev/rdsk/c1t3d0 d6 qfs1mds-node2:/dev/rdsk/c0t0d0 d7 qfs1mds-node2:/dev/rdsk/c0t1d0 [qfs1mds-node1]root@solaris:~#
Connectez-vous à l'hôte client du cluster HA-COTC en tant qu'utilisateur root.
Dans l'exemple, qfs1client1 est l'hôte client :
[qfs1mds-node1]root@solaris:~# ssh root@qfs1client1 [qfs1client1]root@solaris:~#
Sur l'hôte client, récupérez les informations de configuration pour le système de fichiers partagé. Exécutez la commande samfsconfig /dev/rdsk/*.
La commande samfsconfig /dev/rdsk/* recherche le chemin d'accès spécifié des périphériques connectés qui appartiennent à un système de fichiers QFS. Dans l'exemple, la commande trouve les chemins vers les périphériques de données qfs1 (mr). Comme prévu, elle ne trouve pas les périphériques de métadonnées (mm) et renvoie donc les messages Missing slices et Ordinal 0 avant de répertorier les périphériques de données partagés :
[qfs1client1]root@solaris:~# samfsconfig /dev/rdsk/* # Family Set 'qfs1' Created Thu Dec 21 07:17:00 2013 # Missing slices # Ordinal 0 # /dev/rdsk/c1t2d0s0 102 mr qfs1 - # /dev/rdsk/c1t3d0s1 103 mr qfs1 -
Comparez la sortie de la commande samfsconfig à la sortie de la commande Solaris Cluster cldevice list sur le serveur. Assurez-vous que les deux affichent les mêmes chemins d'accès aux périphériques de données mr.
Les commandes samfsconfig et cldevice list doivent indiquer les mêmes périphériques, mais les numéros de contrôleur (cN) sont susceptibles d'être différents. Dans l'exemple, les commandes samfsconfig et cldevice list pointent vers les mêmes périphériques.
Sur le noeud du serveur de métadonnées, le fichier /etc/opt/SUNWsamfs/mcf identifie les périphériques de données mr 102 et 103 à l'aide des identificateurs de périphériques du cluster d4 et d5 :
/dev/did/dsk/d4s0 102 mr qfs1 - /dev/did/dsk/d5s1 103 mr qfs1 -
La commande cldevice list sur le serveur de métadonnées mappe les identificateurs de périphériques du cluster d4 et d5 vers les chemins /dev/rdisk/c1t2d0 et /dev/rdisk/c1t3d0 :
d4 qfs1mds-node1:/dev/rdsk/c1t2d0 d5 qfs1mds-node1:/dev/rdsk/c1t3d0
Sur le noeud client, la commande samfsconfig identifie également les périphériques de données mr partagés 102 et 103 avec les chemins /dev/rdisk/c1t2d0 et /dev/rdisk/c1t3d0 :
/dev/rdsk/c1t2d0s0 102 mr qfs1 - /dev/rdsk/c1t3d0s1 103 mr qfs1 -
Ouvrez le fichier /etc/opt/SUNWsamfs/mcf du client dans un éditeur de texte. Ajoutez une entrée pour le système de fichiers partagé HA-COTC. Cette entrée doit correspondre parfaitement aux entrées des fichiers mcf du serveur de métadonnées.
Dans cet exemple, nous utilisons l'éditeur vi pour créer une entrée pour le système de fichiers QFS partagé qfs1 (nombre ordinal d'équipement 100) :
[qfs1client1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf # Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #------------------ --------- --------- ------- ------ ---------------- qfs1 100 ma qfs1 - shared
Sur une nouvelle ligne, démarrez une entrée pour les périphériques de métadonnées (mm) du système de fichiers partagé HA-COTC. Dans la première colonne (Equipment Identifier), entrez le mot clé nodev.
# Equipment Equipment Equipment Family Device Additional
# Identifier Ordinal Type Set State Parameters
#------------------ --------- --------- ------- ------ ----------------
qfs1 100 ma qfs1 - shared
nodev
Remplissez les champs restants pour les périphériques de métadonnées (mm) du système de fichiers HA-COTC avec les mêmes nombres ordinaux d'équipement, la même famille et les mêmes paramètres d'état de périphérique que ceux dans les fichiers mcf sur les serveurs de métadonnées.
# Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #------------------ --------- --------- ------- ------ ---------------- qfs1 100 ma qfs1 - shared nodev 101 mm qfs1 -
Copiez l'intégralité des entrées pour les périphériques de données (mr) à partir de la sortie samfsconfig. Collez les entrées dans le fichier /etc/opt/SUNWsamfs/mcf du client. Supprimez les marques de commentaire (#) du début insérées par samfsconfig. Ensuite, enregistrez le fichier et fermez l'éditeur de texte.
# Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #------------------ --------- --------- ------- ------ ----------------- qfs1 100 ma qfs1 - shared nodev 101 mm qfs1 - /dev/rdsk/c1t2d0s0 102 mr qfs1 - /dev/rdsk/c1t3d0s1 103 mr qfs1 - :wq [qfs1client1]root@solaris:~#
Recherchez les erreurs éventuelles dans le fichier mcf. Exécutez la commande /opt/SUNWsamfs/sbin/sam-fsd et corrigez les erreurs trouvées.
La commande sam-fsd lit les fichiers de configuration Oracle HSM et initialise les systèmes de fichiers. Elle s'arrête en cas d'erreur. Dans l'exemple, nous vérifions le fichier mcf sur l'hôte qfs1client1 :
[qfs1client1]root@solaris:~# sam-fsd
...
Would start sam-archiverd()
Would start sam-stagealld()
Would start sam-stagerd()
Would start sam-amld()
[qfs1client1]root@solaris:~#
Ouvrez le fichier /etc/vfstab du système d'exploitation client dans un éditeur de texte et ajoutez une entrée pour le nouveau système de fichiers en utilisant les mêmes paramètres que sur le serveur. Ensuite, enregistrez le fichier et fermez l'éditeur de texte.
Dans cet exemple, nous utilisons l'éditeur de texte vi :
[qfs1client1]root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- -------------------- ------ ---- ------- ------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs1 - /global/ha-cotc/qfs1 samfs - no shared :wq [qfs1client1]root@solaris:~#
Créez le point de montage du système de fichiers partagé haute disponibilité sur le client.
[qfs1client1]root@solaris:~# mkdir -p /global/qfs1 [qfs1client1]root@solaris:~#
Montez le système de fichiers partagé haute disponibilité sur le client.
Dans l'exemple
[qfs1client1]root@solaris:~# mount /global/qfs1 [qfs1client1]root@solaris:~#
Répétez cette procédure jusqu'à ce que tous les clients HA-COTC soient configurés.
Si vous prévoyez d'utiliser la fonctionnalité de base de données sideband, reportez-vous au Configuration de la base de données de rapports.
Sinon, passez à la Configuration des notifications et de la journalisation.
La configuration Oracle Hierarchical Storage Manager (HA-SAM) haute disponibilité garantit la disponibilité d'un système de fichiers d'archivage en s'assurant que le serveur de métadonnées QFS et l'application Oracle Hierarchical Storage Manager continuent de fonctionner en cas de panne d'un hôte de serveur. Le système de fichiers est partagé entre les serveurs de métadonnées QFS actifs et potentiels hébergés sur un cluster à deux noeuds géré par le logiciel Solaris Cluster. Si le noeud de cluster actif tombe en panne, le logiciel de clustering active automatiquement le serveur Oracle HSM potentiel sur le noeud restant et transfert le contrôle des opérations en cours. Les répertoires de stockage locaux de l'application Oracle HSM et du système de fichiers QFS étant déjà partagés et montés, l'accès aux données et aux métadonnées reste ininterrompu.
La configuration HA-SAM assure la cohérence du système de fichiers dans un environnement de cluster car elle permet d'envoyer toutes les E/S via le serveur de métadonnées actif. Vous partagez le système de fichiers HA-SAM uniquement pour des raisons liées à l'accessibilité. Vous ne pouvez pas utiliser l'hôte de serveur de métadonnées potentiel en tant que client du système de fichiers comme vous le feriez dans d'autres configurations de systèmes de fichiers partagés SAM-QFS. Le serveur de métadonnées potentiel n'exécute pas les E/S, à moins qu'il soit activé au cours du basculement du noeud. Vous pouvez partager un système de fichiers HA-SAM avec les clients utilisant NFS. Vous devez cependant vous assurer que les partages sont exportés exclusivement à partir du noeud de serveur de métadonnées actif.
Les systèmes de fichiers d'archivage haute disponibilité dépendent de trois types de ressources Solaris Cluster :
SUNW.hasam
Si l'hôte principal tombe en panne, la ressource SUNW.hasam gère le basculement de l'application Oracle Hierarchical Storage Manager. Le logiciel SUNW.hasam est inclus dans la distribution du logiciel Oracle HSM.
SUNW.qfs
Si l'hôte principal tombe en panne, la ressource SUNW.qfs gère le basculement pour le serveur de métadonnées QFS. Le logiciel SUNW.qfs est inclus dans la distribution du logiciel Oracle HSM (pour plus d'informations, reportez-vous à la page de manuel SUNW.qfs).
SUNW.HAStoragePlus
Si l'hôte principal tombe en panne, la ressource SUNW.HAStoragePlus gère le basculement du stockage local de Oracle Hierarchical Storage Manager. L'application Oracle HSM conserve les informations d'archivage volatiles (files d'attente des tâches et catalogues de médias amovibles) dans le système de fichiers local de l'hôte du serveur. SUNW.HAStoragePlus est inclus dans le logiciel Solaris Cluster en tant que type de ressource standard (pour plus d'informations, reportez-vous à la documentation Administration et planification des services de données dans la Bibliothèque de documentation Oracle Solaris).
Pour configurer des instances des composants requis et les intégrer dans une configuration d'archivage HA-SAM qui fonctionne, effectuez les tâches suivantes :
Création d'un fichier d'hôtes global sur les deux noeuds du cluster HA-SAM
Création de fichiers d'hôtes locaux sur les deux noeuds du cluster HA-SAM
Configuration d'un serveur de métadonnées QFS actif sur le noeud principal du cluster HA-SAM
Configuration d'un serveur de métadonnées QFS potentiel sur le noeud secondaire du cluster HA-SAM
Configuration du cluster HA-SAM pour l'utilisation du système de fichiers local haute disponibilité
Configuration du basculement du serveur de métadonnées du système de fichiers QFS
Configuration du basculement de l'application Oracle Hierarchical Storage Manager
Définition des dépendances de ressources du Cluster pour la solution HA-SAM
Mise en ligne du groupe de ressources HA-SAM et test de la configuration
Si nécessaire, configurez le partage du système de fichiers réseau haute disponibilité (HA-NFS).
Les procédures détaillées relatives à la configuration de HA-NFS sont incluses dans le manuel Oracle Solaris Cluster Data Service for Network File System (NFS) Guide inclus dans la bibliothèque de documentation en ligne Oracle Solaris Cluster.
Dans un système de fichiers partagé Oracle HSM d'archivage, vous devez configurer un fichier d'hôtes sur les serveurs de métadonnées, de sorte que les hôtes sur les deux noeuds puissent accéder aux métadonnées pour le système de fichiers. Le fichier d'hôtes est stocké avec le fichier mcf dans le répertoire /etc/opt/SUNWsamfs/. Lors de la création initiale d'un système de fichiers partagé, la commande sammkfs -S configure le partage selon les paramètres stockés dans ce fichier. Créez-le maintenant en appliquant la procédure ci-dessous.
Connectez-vous au noeud principal du cluster HA-SAM en tant qu'utilisateur root.
Dans l'exemple, sam1mds-node1 est le noeud principal :
[sam1mds-node1]root@solaris:~#
Affichez la configuration du cluster. Exécutez la commande /usr/global/bin/cluster show. Dans la sortie, localisez l'enregistrement pour chaque Node Name et notez le privatehostname, le nom Transport Adapter et la propriété ip_address de chaque adaptateur réseau.
Dans l'exemple, chaque noeud comporte deux interfaces réseau, hme0 et qfe3 :
Les adaptateurs hme0 disposent d'adresses IP sur le réseau privé que le cluster utilise pour la communication interne entre les noeuds. Le logiciel Solaris Cluster attribue un privatehostname qui correspond à chaque adresse privée.
Par défaut, le nom d'hôte privé du noeud principal est clusternode1-priv et le nom d'hôte privé du noeud secondaire est clusternode2-priv.
Les adaptateurs qfe3 disposent d'adresses IP et de noms d'hôte publics (sam1mds-node1 et sam1mds-node2) que le cluster utilise pour le transport de données.
Notez que l'affichage a été abrégé à l'aide de points de suspension (...) :
[sam1mds-node1]root@solaris:~# cluster show ... === Cluster Nodes === Node Name: sam1mds-node1... privatehostname: clusternode1-priv... Transport Adapter List: qfe3, hme0... Transport Adapter: qfe3... Adapter Property(ip_address): 172.16.0.12... Transport Adapter: hme0... Adapter Property(ip_address): 10.0.0.129... Node Name: sam1mds-node2... privatehostname: clusternode2-priv... Transport Adapter List: qfe3, hme0... Adapter Property(ip_address): 172.16.0.13... Transport Adapter: hme0... Adapter Property(ip_address): 10.0.0.122
A l'aide d'un éditeur de texte, créez le fichier /etc/opt/SUNWsamfs/hosts.family-set-name, où family-set-name correspond au nom de famille que le fichier /etc/opt/SUNWsamfs/mcf assigne à l'équipement du système de fichiers.
Dans l'exemple, nous créons le fichier hosts.sam1 à l'aide de l'éditeur de texte vi. Nous ajoutons des en-têtes facultatifs pour afficher les colonnes dans la table des hôtes, en commençant chaque ligne par le signe dièse (#) pour indiquer un commentaire :
[sam1mds-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/hosts.sam1 # /etc/opt/SUNWsamfs/hosts.sam1 # Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ----------
Dans la première colonne de la table, entrez les noms d'hôte des noeuds de serveur de métadonnées principal et secondaire, suivis par des espaces, avec chaque entrée sur une ligne séparée.
Dans un fichier d'hôtes, les lignes sont des rangées (enregistrements) et les espaces sont des séparateurs de colonnes (champ). Dans cet exemple, la colonne Host Name des deux premières lignes contient les valeurs sam1mds-node1 et sam1mds-node2, soit les noms d'hôte des noeuds de cluster qui hébergent les serveurs de métadonnées pour le système de fichiers :
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- sam1mds-node1 sam1mds-node2
Dans la deuxième colonne de chaque ligne, commencez par fournir les informations Network Interface pour les hôtes répertoriés dans la colonne Host Name. Saisissez le nom d'hôte privé ou l'adresse réseau privée Solaris Cluster de chaque noeud de cluster HA-SAM, suivi d'une virgule.
Les noeuds du serveur HA-SAM utilisent les noms d'hôte privés pour les communications de serveur à serveur au sein du cluster haute disponibilité. Dans cet exemple, nous utilisons les noms d'hôte privés clusternode1-priv et clusternode2-priv qui sont les noms par défaut assignés par le logiciel Solaris Cluster :
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- sam1mds-node1 clusternode1-priv, sam1mds-node2 clusternode2-priv,
A la suite de la virgule dans la deuxième colonne de chaque ligne, entrez le nom d'hôte public pour le serveur de métadonnées actif, suivi par des espaces.
Les noeuds du serveur HA-SAM utilisent le réseau de données public pour communiquer avec les hôtes en dehors du cluster. Dans la mesure où l'adresse IP et le nom d'hôte du serveur de métadonnées actif changent lors du basculement (de sam1mds-node1 à sam1mds-node2 et inversement), nous utilisons un nom d'hôte virtuel (sam1mds) pour les deux. Ultérieurement, nous configurerons le logiciel Solaris Cluster pour toujours acheminer les demandes pour sam1mds vers le serveur de métadonnées actif :
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- sam1mds-node1 clusternode1-priv,sam1mds sam1mds-node2 clusternode2-priv,sam1mds
Dans la troisième colonne de chaque ligne, indiquez le nombre ordinal du serveur (1 pour le serveur de métadonnées actif et 2 pour le serveur de métadonnées potentiel), suivi par des espaces.
Dans cet exemple, il n'existe qu'un seul serveur de métadonnées : le noeud principal, sam1mds-node1, est le serveur de métadonnées actif, il s'agit donc du nombre ordinal 1, et le second noeud, sam1mds-node2, correspond au nombre ordinal 2 :
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- sam1mds-node1 clusternode1-priv,sam1mds 1 sam1mds-node2 clusternode2-priv,sam1mds 2
Dans la quatrième colonne de chaque ligne, entrez 0 (zéro), suivi par des espaces.
Le caractère 0, un trait d'union (-) ou une valeur vierge dans la quatrième colonne indiquent que l'hôte est activé (on), c'est-à-dire configuré avec un accès au système de fichiers partagé. Un 1 (chiffre un) indique que l'hôte est désactivé off, configuré sans accès au système de fichiers (pour plus d'informations sur l'utilisation de ces valeurs lors de l'administration des systèmes de fichiers partagés, reportez-vous à la page de manuel samsharefs).
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- sam1mds-node1 clusternode1-priv,sam1mds 1 0 sam1mds-node2 clusternode2-priv,sam1mds 2 0
Dans la cinquième colonne de la ligne du noeud principal, entrez le mot-clé server. Ensuite, enregistrez le fichier et fermez l'éditeur de texte.
Le mot-clé server identifie le serveur de métadonnées actif par défaut :
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- sam1mds-node1 clusternode1-priv,sam1mds 1 0 server sam1mds-node2 clusternode2-priv,sam1mds 2 0 :wq [sam1mds-node1]root@solaris:~#
Placez une copie du fichier /etc/opt/SUNWsamfs/hosts.family-set-name global sur le serveur de métadonnées potentiel.
Procédez maintenant à la création de fichiers d'hôtes locaux sur les deux noeuds du cluster HA-SAM.
Dans un système de fichiers d'archivage haute disponibilité, vous devez vous assurer que les serveurs communiquent entre eux à l'aide du réseau privé défini par le logiciel Solaris Cluster. Pour ce faire, vous utilisez des fichiers d'hôtes locaux spécifiquement configurés pour acheminer de manière sélective le trafic réseau entre les interfaces réseau sur les serveurs.
Chaque hôte du système de fichiers identifie les interfaces réseau des autres hôtes en commençant par vérifier le fichier /etc/opt/SUNWsamfs/hosts.family-set-name sur le serveur de métadonnées. Il vérifie ensuite son propre fichier /etc/opt/SUNWsamfs/hosts.family-set-name.local. S'il n'y a pas de fichier d'hôtes local, l'hôte utilise les adresses d'interfaces spécifiées dans le fichier d'hôtes global, dans l'ordre spécifié dans le fichier global. S'il y a un fichier d'hôtes local, l'hôte le compare avec le fichier global et utilise uniquement les interfaces répertoriées dans les deux fichiers, dans l'ordre spécifié dans le fichier local. En utilisant différentes adresses dans différentes dispositions dans chaque fichier, vous pouvez contrôler les interfaces utilisées par différents hôtes.
Pour configurer les fichiers d'hôtes locaux, suivez la procédure décrite ci-dessous :
Connectez-vous au noeud principal du cluster HA-SAM en tant qu'utilisateur root.
Dans l'exemple, sam1mds-node1 est le noeud principal :
[sam1mds-node1]root@solaris:~#
A l'aide d'un éditeur de texte, créez un fichier d'hôtes local sur le serveur de métadonnées actif, à l'aide du chemin et du nom de fichier /etc/opt/SUNWsamfs/hosts.family-set-name.local, où family-set-name correspond au nom de famille assigné par le fichier /etc/opt/SUNWsamfs/mcf à l'équipement du système de fichiers. Incluez uniquement les interfaces des réseaux que le serveur actif doit utiliser lors de la communication avec le serveur potentiel. Ensuite, enregistrez le fichier et fermez l'éditeur de texte.
Dans notre exemple, nous souhaitons que les serveurs de métadonnées actifs et potentiels communiquent entre eux via le réseau privé. Ainsi, le fichier d'hôtes local sur le serveur de métadonnées actif, hosts.sam1.local, répertorie uniquement les adresses privées du cluster pour les serveurs actifs et potentiels :
[sam1mds-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/hosts.sam1.local # Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- sam1mds-node1 clusternode1-priv 1 0 server sam1mds-node2 clusternode2-priv 2 0 :wq [sam1mds-node1]root@solaris:~#
Connectez-vous au noeud secondaire du cluster en tant qu'utilisateur root.
Dans l'exemple, sam1mds-node2 est le noeud secondaire :
[sam1mds-node1]root@solaris:~# ssh root@sam1mds-node2 Password: [sam1mds-node2]root@solaris:~#
Utilisez un éditeur de texte pour créer un fichier d'hôtes local sur le serveur de métadonnées potentiel. Utilisez le chemin et le nom de fichier /etc/opt/SUNWsamfs/hosts.family-set-name.local, où family-set-name correspond au nom de famille assigné par le fichier /etc/opt/SUNWsamfs/mcf à l'équipement du système de fichiers. Incluez uniquement les interfaces des réseaux que le serveur potentiel doit utiliser lors de la communication avec le serveur actif. Ensuite, enregistrez le fichier et fermez l'éditeur de texte.
Dans notre exemple, nous souhaitons que les serveurs de métadonnées actifs et potentiels communiquent entre eux via le réseau privé. Ainsi, le fichier d'hôtes local sur le serveur de métadonnées potentiel, hosts.sam1.local, répertorie uniquement les adresses privées du cluster pour les serveurs actifs et potentiels :
[sam1mds-node2]root@solaris:~# vi /etc/opt/SUNWsamfs/hosts.sam1.local # Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- sam1mds-node1 clusternode1-priv 1 0 server sam1mds-node2 clusternode2-priv 2 0 :wq [sam1mds-node2]root@solaris:~# exit [sam1mds-node1]root@solaris:~#
Procédez ensuite à la configuration d'un serveur de métadonnées QFS actif sur le noeud principal du cluster HA-SAM.
Sélectionnez le noeud du cluster qui servira à la fois de noeud principal pour le cluster HA-SAM et de serveur de métadonnées actif pour le système de fichiers partagé QFS. Connectez-vous en tant que root.
Dans l'exemple, sam1mds-node1 est le noeud principal :
[sam1mds-node1]root@solaris:~#
Sélectionnez les périphériques de stockage globaux qui seront utilisés pour le système de fichiers QFS. Exécutez la commande /usr/global/bin/cldevice list -v.
Le logiciel Solaris Cluster assigne des identificateurs de périphériques (DID) uniques à tous les périphériques qui se connectent aux noeuds du cluster. Les périphériques globaux sont accessibles depuis tous les noeuds du cluster, tandis que les périphériques locaux sont accessibles uniquement depuis les hôtes qui les montent. Les périphériques globaux restent accessibles à la suite d'un basculement. Ce n'est pas le cas des périphériques locaux.
Dans l'exemple, notez que les périphériques d1, d2, d7 et d8 ne sont pas accessibles depuis les deux noeuds. Nous effectuons donc la sélection parmi les périphériques d3, d4 et d5 lors de la configuration du système de fichiers partagé QFS haute disponibilité :
[sam1mds-node1]root@solaris:~# cldevice list -v DID Device Full Device Path ---------- ---------------- d1 sam1mds-node1:/dev/rdsk/c0t0d0 d2 sam1mds-node1:/dev/rdsk/c0t6d0 d3 sam1mds-node1:/dev/rdsk/c1t1d0 d3 sam1mds-node2:/dev/rdsk/c1t1d0 d4 sam1mds-node1:/dev/rdsk/c1t2d0 d4 sam1mds-node2:/dev/rdsk/c1t2d0 d5 sam1mds-node1:/dev/rdsk/c1t3d0 d5 sam1mds-node2:/dev/rdsk/c1t3d0 d6 sam1mds-node2:/dev/rdsk/c0t0d0 d7 sam1mds-node2:/dev/rdsk/c0t1d0
Sur le noeud principal sélectionné, créez un système de fichiers ma haute performance qui utilise les périphériques de données mr. Dans un éditeur de texte, ouvrez le fichier /etc/opt/SUNWsamfs/mcf.
Dans l'exemple, nous configurons le système de fichiers sam1. Nous configurons le périphérique d3 en tant que périphérique de métadonnées (type d'équipement mm), et utilisons d4 et d5 comme périphériques de données (type d'équipement mr) :
[sam1mds-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf # Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #------------------ --------- --------- ------- ------ ----------------- sam1 100 ma sam1 - /dev/did/dsk/d3s0 101 mm sam1 - /dev/did/dsk/d4s0 102 mr sam1 - /dev/did/dsk/d5s1 103 mr sam1 -
Dans le fichier /etc/opt/SUNWsamfs/mcf, entrez le paramètre shared dans la colonne Additional Parameters de l'entrée du système de fichiers. Enregistrez le fichier.
[sam1mds-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf # Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #------------------ --------- --------- ------- ------ ----------------- sam1 100 ma sam1 - shared /dev/did/dsk/d3s0 101 mm sam1 - /dev/did/dsk/d4s0 102 mr sam1 - /dev/did/dsk/d5s1 103 mr sam1 - :wq [sam1mds-node1]root@solaris:~#
Recherchez les erreurs éventuelles dans le fichier mcf. Exécutez la commande /opt/SUNWsamfs/sbin/sam-fsd et corrigez les erreurs trouvées.
La commande sam-fsd lit les fichiers de configuration Oracle HSM et initialise les systèmes de fichiers. Elle s'arrête en cas d'erreur. Dans l'exemple, nous vérifions le fichier mcf sur l'hôte sam1mds-node1 :
[sam1mds-node1]root@solaris:~# sam-fsd
...
Would start sam-archiverd()
Would start sam-stagealld()
Would start sam-stagerd()
Would start sam-amld()
[sam1mds-node1]root@solaris:~#
Créez le système de fichiers. Exécutez la commande /opt/SUNWsamfs/sbin/sammkfs -S family-set-name, où family-set-name correspond au nom de famille que le fichier /etc/opt/SUNWsamfs/mcf assigne à l'équipement de système de fichiers.
La commande sammkfs lit les fichiers hosts.family-set-name et mcf, et crée un système de fichiers Oracle HSM avec les propriétés spécifiées.
[sam1mds-node1]root@solaris:~# sammkfs -S sam1 Building 'sam1' will destroy the contents of devices: ... Do you wish to continue? [y/N]yes ... [sam1mds-node1]root@solaris:~#
Ouvrez le fichier /etc/vfstab du système d'exploitation dans un éditeur de texte et démarrez une ligne pour le nouveau système de fichiers. Entrez le nom du système de fichiers dans la première colonne, suivi d'espaces, puis un tiret dans la deuxième colonne, suivi d'espaces.
Dans l'exemple, nous utilisons l'éditeur de texte vi. Nous démarrons une ligne pour le système de fichiers sam1. Le tiret empêche le système d'exploitation de tenter de vérifier l'intégrité du système de fichiers à l'aide des outils UFS :
[sam1mds-node1]root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ------------ ------ ---- ------- --------------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... sam1 -
Dans la troisième colonne du fichier /etc/vfstab, entrez le point de montage du système de fichiers par rapport au cluster. Sélectionnez un sous-répertoire qui ne se trouve pas directement en dessous du répertoire root du système.
Le montage d'un système de fichiers QFS partagé immédiatement sous la racine peut provoquer des problèmes de basculement lors de l'utilisation du type de ressource SUNW.qfs. Dans l'exemple, nous définissons le point de montage sur le cluster sur /global/ha-sam/sam1 :
#File
#Device Device Mount System fsck Mount Mount
#to Mount to fsck Point Type Pass at Boot Options
#-------- ------- ------------------- ------ ---- ------- ---------------
/devices - /devices devfs - no -
/proc - /proc proc - no -
...
sam1 - /global/ha-sam/sam1
Renseignez les champs restants de l'enregistrement de fichier /etc/vfstab comme vous le feriez pour n'importe quel système de fichiers partagé Oracle HSM. Ensuite, enregistrez le fichier et fermez l'éditeur de texte.
#File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ------------------- ------ ---- ------- --------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... sam1 - /global/ha-sam/sam1 samfs - no shared :wq [sam1mds-node1]root@solaris:~#
Créez un point de montage pour le système de fichiers haute disponibilité.
La commande mkdir avec l'option -p (parents) crée le répertoire /global s'il n'existe pas déjà :
[sam1mds-node1]root@solaris:~# mkdir -p /global/ha-sam/sam1
Montez le système de fichiers partagé haute disponibilité sur le noeud principal.
[sam1mds-node1]root@solaris:~# mount /global/ha-sam/sam1
Procédez ensuite à la configuration d'un serveur de métadonnées QFS potentiel sur le noeud secondaire du cluster HA-SAM.
Le noeud secondaire du cluster à deux noeuds sert de serveur de métadonnées potentiel. Un serveur de métadonnées potentiel est un hôte qui peut accéder aux périphériques de métadonnées et, par conséquent, endosser les responsabilités d'un serveur de métadonnées. Ainsi, si le serveur de métadonnées actif sur le noeud principal tombe en panne, le logiciel Solaris Cluster peut basculer sur le noeud secondaire et activer le serveur de métadonnées potentiel.
Connectez-vous au noeud secondaire du cluster HA-SAM en tant qu'utilisateur root.
Dans l'exemple, sam1mds-node2 est le noeud secondaire :
[sam1mds-node2]root@solaris:~#
Copiez le fichier /etc/opt/SUNWsamfs/mcf du noeud principal vers le noeud secondaire.
Recherchez les erreurs éventuelles dans le fichier mcf. Exécutez la commande /opt/SUNWsamfs/sbin/sam-fsd et corrigez les erreurs trouvées.
La commande sam-fsd lit les fichiers de configuration Oracle HSM et initialise les systèmes de fichiers. Elle s'arrête en cas d'erreur. Dans l'exemple, nous vérifions le fichier mcf sur l'hôte sam1mds-node1 :
[sam1mds-node2]root@solaris:~# sam-fsd
...
Would start sam-archiverd()
Would start sam-stagealld()
Would start sam-stagerd()
Would start sam-amld()
[sam1mds-node2]root@solaris:~#
Créez le système de fichiers. Exécutez la commande /opt/SUNWsamfs/sbin/sammkfs -S family-set-name, où family-set-name correspond au nom de famille que le fichier /etc/opt/SUNWsamfs/mcf assigne à l'équipement de système de fichiers.
La commande sammkfs lit les fichiers hosts.family-set-name et mcf, et crée un système de fichiers Oracle HSM avec les propriétés spécifiées.
[sam1mds-node2]root@solaris:~# sammkfs sam1 Building 'sam1' will destroy the contents of devices: ... Do you wish to continue? [y/N]yes ... [sam1mds-node2]root@solaris:~#
Ouvrez le fichier /etc/vfstab du système d'exploitation dans un éditeur de texte et ajoutez une ligne pour le nouveau système de fichiers. Ensuite, enregistrez le fichier et fermez l'éditeur de texte.
Dans cet exemple, nous utilisons l'éditeur de texte vi :
[sam1mds-node2]root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ------------------- ------ ---- ------- -------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... sam1 - /global/ha-sam/sam1 samfs - no shared :wq [sam1mds-node2]root@solaris:~#
Créez le point de montage du système de fichiers partagé haute disponibilité sur le noeud secondaire.
[sam1mds-node2]root@solaris:~# mkdir -p /global/ha-sam/sam1
Montez le système de fichiers partagé haute disponibilité sur le noeud secondaire.
[sam1mds-node2]root@solaris:~# mount /global/ha-sam/sam1
Procédez maintenant à la création du groupe de ressources du cluster HA-SAM.
Créez le groupe de ressources qui gèrera les ressources haute disponibilité pour votre solution HA-SAM.
Connectez-vous au noeud principal du cluster HA-SAM en tant qu'utilisateur root.
Dans l'exemple, le noeud principal est sam1mds-node1 :
[sam1mds-node1]root@solaris:~#
Créez un groupe de ressources Solaris Cluster pour gérer les ressources de la solution HA-SAM. Exécutez la commande clresourcegroup create -n node1,node2 groupname, où :
node1 correspond au nom d’hôte du principal noeud du cluster.
node2 correspond au nom d'hôte du noeud secondaire du cluster.
groupname correspond au nom que vous avez choisi pour le groupe de ressources HA-SAM.
Dans cet exemple, nous créons un groupe de ressources nommé has-rg et incluons les hôtes sam1mds-node1 et sam1mds-node2 (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[sam1mds-node1]root@solaris:~# clresourcegroup create \ -n sam1mds-node1,sam1mds-node2 has-rg
Procédez ensuite à la configuration d'un système de fichiers local haute disponibilité pour les fichiers de configuration Oracle HSM.
Pour réussir la reprise après un basculement, le logiciel Oracle HSM doit redémarrer les opérations d'archivage qui étaient en cours d'exécution au moment du basculement. Pour redémarrer les opérations d'archivage, le logiciel doit pouvoir accéder aux informations de configuration et d'état du système qui sont généralement stockées sur le système de fichiers local du serveur de métadonnées actif. Vous devez donc déplacer les informations nécessaires vers un système de fichiers local haute disponibilité qui reste toujours accessible à partir des deux noeuds du cluster.
Pour créer le système de fichiers nécessaire, procédez comme suit :
Connectez-vous au noeud principal du cluster HA-SAM en tant qu'utilisateur root.
Dans l'exemple, le noeud principal est sam1mds-node1 :
[sam1mds-node1]root@solaris:~#
Sur le noeud principal du cluster, créez un système de fichiers UFS sur une tranche libre d'un périphérique global. Exécutez la commande newfs /dev/global/dsk/dXsY, où X correspond au numéro d'identificateur de périphérique (DID) du périphérique global et Y correspond au numéro de la tranche.
Dans cet exemple, nous créons le nouveau système de fichiers sur /dev/global/dsk/d10s0 :
[sam1mds-node1]root@solaris:~# newfs /dev/global/dsk/d10s0 newfs: construct a new file system /dev/global/dsk/d10s0: (y/n)? y /dev/global/dsk/d10s0: 1112940 sectors in 1374 cylinders of 15 tracks, 54 sectors 569.8MB in 86 cyl groups (16 c/g, 6.64MB/g, 3072 i/g) super-block backups(for fsck -b #) at: 32, 13056, 26080, 39104, 52128, 65152, 78176, 91200, 104224, . . . [sam1mds-node1]root@solaris:~#
Sur le noeud principal du cluster, ouvrez le fichier /etc/vfstab du système d'exploitation dans un éditeur de texte. Ajoutez une ligne pour le nouveau système de fichiers UFS. Enregistrez le fichier et fermez l'éditeur de texte.
La ligne doit être une liste délimitée par des espaces sous la forme : /dev/global/dsk/dXsY /dev/global/dsk/dXsY /global/mount_point ufs 5 no global, où :
X correspond au numéro d'identificateur de périphérique (DID) du périphérique global qui détient le système de fichiers.
Y correspond au numéro de la tranche qui détient le système de fichiers.
/dev/global/dsk/dXsY correspond au nom du périphérique du système de fichiers qui sera monté.
/dev/global/dsk/dXsY correspond au nom du périphérique du système de fichiers qui sera vérifié par la commande fsck.
mount_point correspond au nom du sous-répertoire où le fichier UFS doit être monté.
ufs correspond au type du système de fichiers.
5 correspond au numéro de passe fsck recommandé.
no indique au système d'exploitation qu'il ne doit pas monter le système de fichiers au démarrage.
global monte le système de fichiers pour que les deux noeuds disposent d'un accès.
Dans l'exemple, nous utilisons l'éditeur de texte vi. Le nom du système de fichiers est /dev/global/dsk/d10s0 et le point de montage est /global/hasam_cfg (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[sam1mds-node1]root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ------------------- ------ ---- ------- -------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... sam1 - /global/ha-samsam1 samfs - no shared /dev/global/dsk/d10s0 /dev/global/rdsk/d10s0 /global/hasam_cfg ufs 5 \ no global :wq [sam1mds-node2]root@solaris:~#
Créez le point de montage du système de fichiers local haute disponibilité sur le noeud principal du cluster. Exécutez la commande mkdir -p /global/mount_point où mount_point correspond au répertoire sélectionné du point de montage.
Dans cet exemple, nous créons le répertoire /global/hasam_cfg :
[sam1mds-node1]root@solaris:~# mkdir -p /global/hasam_cfg
Connectez-vous au noeud secondaire du cluster en tant qu'utilisateur root.
Dans cet exemple, sam1mds-node2 est le noeud secondaire. Nous nous connectons à l'aide de ssh :
[sam1mds-node1]root@solaris:~# ssh root@sam1mds-node2 Password: [sam1mds-node2]root@solaris:~#
Sur le noeud secondaire, ouvrez le fichier /etc/vfstab du système d'exploitation dans un éditeur de texte. Ajoutez une entrée identique pour le nouveau système de fichiers UFS. Enregistrez le fichier et fermez l'éditeur de texte.
[sam1mds-node1]root@solaris:~# ssh root@sam1mds-node2 Password: [sam1mds-node2]root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ------------------- ------ ---- ------- -------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... sam1 - /global/ha-samsam1 samfs - no shared /dev/global/dsk/d10s0 /dev/global/rdsk/d10s0 /global/hasam_cfg ufs 5 \ no global :wq [sam1mds-node1]root@solaris:~#
Sur le noeud secondaire, créez le même point de montage.
Dans cet exemple, nous créons le répertoire /global/hasam_cfg. Nous fermons ensuite la session ssh et reprenons la session sur le noeud principal :
[sam1mds-node2]root@solaris:~# mkdir -p /global/hasam_cfg [sam1mds-node2]root@solaris:~# exit [sam1mds-node1]root@solaris:~#
Montez le système de fichiers local haute disponibilité sur le noeud principal. Exécutez la commande mount /global/mount_point, où mount_point correspond au répertoire sélectionné du point de montage.
La commande monte le système de fichiers UFS sur les deux noeuds. Dans cet exemple, le système de fichiers est monté sur /global/hasam_cfg :
[sam1mds-node1]root@solaris:~# mount /global/hasam_cfg [sam1mds-node1]root@solaris:~#
Sur le noeud principal, créez un sous-répertoire pour conserver les informations de transfert de Oracle HSM. Exécutez la commande mkdir -p /global/mount_point/catalog, où mount_point correspond au répertoire du point de montage sélectionné.
[sam1mds-node1]root@solaris:~# mkdir /global/hasam_cfg/catalog [sam1mds-node1]root@solaris:~#
Sur le noeud principal, créez un sous-répertoire pour conserver les catalogues d'archives de Oracle HSM. Exécutez la commande mkdir -p /global/mount_point/stager, où mount_point correspond au répertoire sélectionné du point de montage.
[sam1mds-node1]root@solaris:~# mkdir /global/hasam_cfg/stager [sam1mds-node1]root@solaris:~#
Procédez ensuite au déplacement des fichiers de configuration Oracle HSM vers le système de fichiers local haute disponibilité.
Connectez-vous au noeud principal du cluster HA-SAM en tant qu'utilisateur root.
Dans l'exemple, le noeud principal est sam1mds-node1 :
[sam1mds-node1]root@solaris:~#
Sur le noeud principal, copiez les répertoires catalog/ et stager/ à partir de leur emplacement par défaut dans /var/opt/SUNWsamfs/ vers un emplacement temporaire.
Dans cet exemple, nous copions les fichiers de manière récursive vers /var/tmp/ (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[sam1mds-node1]root@solaris:~# cp -r /var/opt/SUNWsamfs/catalog \ /var/tmp/catalog [sam1mds-node1]root@solaris:~# cp -r /var/opt/SUNWsamfs/stager /var/tmp/stager [sam1mds-node1]root@solaris:~#
Sur le noeud principal, supprimez les répertoires catalog/ et stager/ de /var/opt/SUNWsamfs/.
[sam1mds-node1]root@solaris:~# rm -rf /var/opt/SUNWsamfs/catalog [sam1mds-node1]root@solaris:~# rm -rf /var/opt/SUNWsamfs/stager [sam1mds-node1]root@solaris:~#
Sur le noeud principal, créez un lien symbolique à partir de l'emplacement par défaut des informations de catalogue vers le nouvel emplacement dans le système de fichiers local UFS haute disponibilité. Exécutez la commande ln -s /global/mount_point/catalog /var/opt/SUNWsamfs/catalog, où :
mount_point correspond au nom du sous-répertoire où le système de fichiers local haute disponibilité est connecté au système de fichiers racine du noeud.
/var/opt/SUNWsamfs/catalog correspond à l'emplacement par défaut.
Le lien symbolique redirigera automatiquement les demandes d'informations de catalogue vers le nouvel emplacement. Dans cet exemple, nous créons un lien catalog qui pointe vers le nouvel emplacement /global/hasam_cfg/catalog (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[sam1mds-node1]root@solaris:~# ln -s /global/hasam_cfg/catalog \ /var/opt/SUNWsamfs/catalog [sam1mds-node1]root@solaris:~#
Sur le noeud principal, créez un lien symbolique à partir de l'emplacement par défaut des informations de transfert vers le nouvel emplacement dans le système de fichiers local UFS haute disponibilité. Exécutez la commande ln -s /global/mount_point/stager /var/opt/SUNWsamfs/stager, où :
mount_point correspond au nom du sous-répertoire où le système de fichiers local haute disponibilité est connecté au système de fichiers racine du noeud.
/var/opt/SUNWsamfs/stager correspond à l'emplacement par défaut.
Le lien symbolique redirigera automatiquement les demandes d'informations de transfert vers le nouvel emplacement. Dans cet exemple, nous créons un lien stager qui pointe vers le nouvel emplacement /global/hasam_cfg/stager (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[sam1mds-node1]root@solaris:~# ln -s /global/hasam_cfg/stager \ /var/opt/SUNWsamfs/stager [sam1mds-node1]root@solaris:~#
Assurez-vous que les liens symboliques remplacent les répertoires /var/opt/SUNWsamfs/catalog et /var/opt/SUNWsamfs/stager par défaut sur le noeud principal. Assurez-vous que les liens symboliques pointent vers les nouveaux emplacements dans le système de fichiers haute disponibilité.
Dans l'exemple, les liens sont corrects :
[sam1mds-node1]root@solaris:~# ls -l /var/opt/SUNWsamfs/catalog lrwxrwxrwx 1 root other ... /var/opt/SUNWsamfs/catalog -> /global/hasam_cfg/catalog [sam1mds-node1]root@solaris:~# ls -l /var/opt/SUNWsamfs/stager lrwxrwxrwx 1 root other ... /var/opt/SUNWsamfs/stager -> /global/hasam_cfg/stager [sam1mds-node1]root@solaris:~#
Copiez le contenu des répertoires catalog/ et stager/ à partir de l'emplacement temporaire vers le système de fichiers haute disponibilité.
Dans cet exemple, nous copions les répertoires catalog/ et stager/ depuis /var/tmp/ vers le nouvel emplacement /global/hasam_cfg/stager (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[sam1mds-node1]root@solaris:~# cp -rp /var/tmp/catalog/* \ /var/opt/SUNWsamfs/catalog [sam1mds-node1]root@solaris:~# cp -rp /var/tmp/stager/* \ /var/opt/SUNWsamfs/stager [sam1mds-node1]root@solaris:~#
Connectez-vous au noeud secondaire du cluster HA-SAM en tant qu'utilisateur root.
Dans cet exemple, nous utilisons ssh (shell sécurisé) pour nous connecter à sam1mds-node2, le noeud secondaire :
[sam1mds-node1]root@solaris:~# ssh root@sam1mds-node2 Password: [sam1mds-node2]root@solaris:~#
Sur le noeud secondaire, créez un lien symbolique à partir de l'emplacement par défaut des informations de catalogue vers le nouvel emplacement dans le système de fichiers local UFS haute disponibilité. Exécutez la commande ln -s /global/mount_point/catalog /var/opt/SUNWsamfs/catalog, où :
mount_point correspond au nom du sous-répertoire où le système de fichiers local haute disponibilité est connecté au système de fichiers racine du noeud.
/var/opt/SUNWsamfs/catalog correspond à l'emplacement par défaut.
Le lien symbolique redirigera automatiquement les demandes d'informations de catalogue vers le nouvel emplacement. Dans cet exemple, nous créons un lien catalog qui pointe vers le nouvel emplacement /global/hasam_cfg/catalog (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[sam1mds-node2]root@solaris:~# ln -s /global/hasam_cfg/catalog \ /var/opt/SUNWsamfs/catalog [sam1mds-node2]root@solaris:~#
Sur le noeud secondaire, créez un lien symbolique à partir de l'emplacement par défaut des informations de transfert vers le nouvel emplacement dans le système de fichiers local UFS haute disponibilité. Exécutez la commande ln -s /global/mount_point/stager /var/opt/SUNWsamfs/stager, où :
mount_point correspond au nom du sous-répertoire où le système de fichiers local haute disponibilité est connecté au système de fichiers racine du noeud.
/var/opt/SUNWsamfs/stager correspond à l'emplacement par défaut.
Le lien symbolique redirigera automatiquement les demandes d'informations de transfert vers le nouvel emplacement. Dans cet exemple, nous créons un lien stager qui pointe vers le nouvel emplacement /global/hasam_cfg/stager (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[sam1mds-node2]root@solaris:~# ln -s /global/hasam_cfg/stager \ /var/opt/SUNWsamfs/stager [sam1mds-node2]root@solaris:~#
Assurez-vous que les liens symboliques remplacent les répertoires /var/opt/SUNWsamfs/catalog et /var/opt/SUNWsamfs/stager par défaut sur le noeud secondaire. Assurez-vous que les liens symboliques pointent vers les nouveaux emplacements dans le système de fichiers haute disponibilité.
Dans cet exemple, les liens sont corrects. Nous fermons donc la session ssh et reprenons la session sur le noeud principal :
[sam1mds-node2]root@solaris:~# ls -l /var/opt/SUNWsamfs/catalog lrwxrwxrwx 1 root other ... /var/opt/SUNWsamfs/catalog -> /global/hasam_cfg/catalog [sam1mds-node2]root@solaris:~# ls -l /var/opt/SUNWsamfs/stager lrwxrwxrwx 1 root other ... /var/opt/SUNWsamfs/stager -> /global/hasam_cfg/stager [sam1mds-node2]root@solaris:~# exit [sam1mds-node1]root@solaris:~#
Procédez ensuite à la configuration du cluster HA-SAM pour l'utilisation du système de fichiers local haute disponibilité.
Sur le noeud principal du cluster HA-SAM, enregistrez le type de ressource SUNW.HAStoragePlus dans le cadre de la configuration du cluster. Exécutez la commande Solaris Cluster clresourcetype register SUNW.HAStoragePlus.
[sam1mds-node1]root@solaris:~# clresourcetype register SUNW.HAStoragePlus [sam1mds-node1]root@solaris:~#
Sur le noeud principal, créez une nouvelle instance du type de ressource SUNW.HAStoragePlus et associez-la à un groupe de ressources Solaris Cluster. Exécutez la commande clresource create -g groupname -t SUNW.HAStoragePlus -x FilesystemMountPoints=mountpoint -x AffinityOn=TRUE resourcename, où :
groupname correspond au nom que vous avez choisi pour le groupe de ressources HA-SAM.
SUNW.HAStoragePlus correspond au type de ressource Solaris Cluster qui prend en charge le basculement des systèmes de fichiers locaux.
mountpoint correspond au point de montage du système de fichiers local haute disponibilité qui contiendra les catalogues et les fichiers de transfert.
resourcename correspond au nom que vous avez choisi pour la ressource elle-même.
Dans cet exemple, nous créons une ressource nommée has-cfg du type SUNW.HAStoragePlus. Nous ajoutons la nouvelle ressource au groupe de ressources has-rg. Ensuite, nous configurons les propriétés de l'extension de la ressource. Nous définissons FilesystemMountPoints sur /global/hasam_cfg et AffinityOn sur TRUE (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[sam1mds-node1]root@solaris:~# clresource create -g has-rg \ -t SUNW.HAStoragePlus -x FilesystemMountPoints=/global/hasam_cfg \ -x AffinityOn=TRUE has-cfg [sam1mds-node1]root@solaris:~#
Procédez ensuite à la configuration du basculement du serveur de métadonnées du système de fichiers QFS.
Vous configurez le basculement des serveurs de métadonnées en créant une ressource de cluster SUNW.qfs, un type de ressource défini par le logiciel Oracle HSM (reportez-vous à la page de manuel SUNW.qfs pour plus d'informations). Pour créer et configurer la ressource pour une configuration HA-SAM, procédez comme suit :
Connectez-vous au noeud principal du cluster HA-SAM en tant qu'utilisateur root.
Dans l'exemple, le noeud principal est sam1mds-node1 :
[sam1mds-node1]root@solaris:~#
Définissez le type de ressource SUNW.qfs pour le logiciel Solaris Cluster. Exécutez la commande clresourcetype register SUNW.qfs.
[sam1mds-node1]root@solaris:~# clresourcetype register SUNW.qfs [qfs1mds-node1]root@solaris:~#
Si l'enregistrement échoue parce que le fichier d'enregistrement est introuvable, placez un lien symbolique vers le répertoire /opt/SUNWsamfs/sc/etc/ dans le répertoire dans lequel Solaris Cluster conserve les fichiers d'enregistrement de type de ressource, /opt/cluster/lib/rgm/rtreg/.
L'enregistrement échoue si vous n'avez pas installé le logiciel Oracle Solaris Cluster avant d'installer le logiciel Oracle HSM. Normalement, Oracle HSM fournit automatiquement l'emplacement du fichier d'enregistrement SUNW.qfs lorsqu'il détecte Solaris Cluster durant l'installation. Dans cet exemple, nous créons le lien manuellement.
[qfs1mds-node1]root@solaris:~# cd /opt/cluster/lib/rgm/rtreg/ [qfs1mds-node1]root@solaris:~# ln -s /opt/SUNWsamfs/sc/etc/SUNW.qfs SUNW.qfs [qfs1mds-node1]root@solaris:~#
Dans le nouveau groupe de ressources, configurez un nom d'hôte virtuel pour le serveur de métadonnées actif. Exécutez la commande Solaris Cluster clreslogicalhostname create -g group-name virtualMDS, où :
group-name correspond au nom du groupe de ressources QFS.
virtualMDS correspond au nom d'hôte virtuel.
Utilisez le même nom d'hôte virtuel que vous avez utilisé dans les fichiers d'hôtes pour le système de fichiers partagé. Dans cet exemple, nous ajoutons le nom d'hôte virtuel sam1mds au groupe de ressources has-rg :
[sam1mds-node1]root@solaris:~# clreslogicalhostname create -g has-rg sam1mds [qfs1mds-node1]root@solaris:~#
Ajoutez les ressources du système de fichiers Oracle HSM au groupe de ressources. Exécutez la commande clresource create -g groupname -t SUNW.qfs -x QFSFileSystem=mount-point, où :
groupname correspond au nom que vous avez choisi pour le groupe de ressources HA-SAM.
SUNW.qfs correspond au type de ressource Solaris Cluster qui prend en charge le basculement des serveurs de métadonnées du système de fichiers QFS.
mount-point correspond au point de montage du système de fichiers dans le cluster, un sous-répertoire qui n'est pas directement sous le répertoire root du système.
Le montage d'un système de fichiers QFS partagé immédiatement sous la racine peut provoquer des problèmes de basculement lors de l'utilisation du type de ressource SUNW.qfs.
resource-name correspond au nom que vous avez choisi pour la ressource elle-même.
Dans cet exemple, nous créons une ressource nommée has-qfs du type SUNW.qfs dans le groupe de ressources has-rg. Nous définissons la propriété d'extension SUNW.qfs QFSFileSystem sur le point de montage /global/ha-sam/sam1. Nous définissons la propriété standard Resource_dependencies sur sam1mds, le nom d'hôte virtuel qui représente le serveur de métadonnées actif (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[sam1mds-node1]root@solaris:~# clresource create -g has-rg -t SUNW.qfs \ -x QFSFileSystem=/global/ha-sam/sam1 -y Resource_dependencies=sam1mds has-qfs [sam1mds-node1]root@solaris:~#
Procédez ensuite à la configuration du basculement de l'application Oracle Hierarchical Storage Manager.
Vous configurez le basculement de l'application Oracle Hierarchical Storage Manager en créant une ressource SUNW.hasam Oracle HSM. Ce type de ressource coordonne l'arrêt et le redémarrage méthodiques des processus Oracle HSM.
Pour configurer le basculement de l'application Oracle Hierarchical Storage Manager, procédez comme suit :
Connectez-vous au noeud principal du cluster HA-SAM en tant qu'utilisateur root.
Dans l'exemple, le noeud principal est sam1mds-node1 :
[sam1mds-node1]root@solaris:~#
Définissez le type de ressource SUNW.hasam pour le logiciel Solaris Cluster. Exécutez la commande clresourcetype register SUNW.hasam.
[sam1mds-node1]root@solaris:~# clresourcetype register SUNW.hasam [sam1mds-node1]root@solaris:~#
Ajoutez la ressource SUNW.hasam Oracle HSM au groupe de ressources. Exécutez la commande clresource create -g groupname -t SUNW.hasam -x QFSName=fs-name -x CatalogFileSystem=mount-point resource-name, où :
groupname correspond au nom que vous avez choisi pour le groupe de ressources HA-SAM.
SUNW.hasam correspond au type de ressource Solaris Cluster qui prend en charge le basculement de l'application Oracle Hierarchical Storage Manager.
mount-point correspond au point de montage du système de fichiers global qui contient les catalogues d'archives Oracle HSM.
resource-name correspond au nom que vous avez choisi pour la ressource elle-même.
Dans cet exemple, nous créons une ressource nommée has-sam du type SUNW.hasam dans le groupe de ressources has-rg. Nous définissons la propriété d'extension SUNW.hasam QFSName pour le nom du système de fichiers QFS spécifié dans le fichier mcf, sam1. Nous définissons la propriété d'extension SUNW.hasam CatalogFileSystem pour le point de montage /global/hasam_cfg :
[sam1mds-node1]root@solaris:~# clresource create -g has-rg -t SUNW.hasam \ -x QFSName=sam1 -x CatalogFileSystem=/global/hasam_cfg has-sam [sam1mds-node1]root@solaris:~#
Procédez ensuite à la définition des dépendances de ressources du cluster pour la solution HA-SAM.
Connectez-vous au noeud principal du cluster HA-SAM en tant qu'utilisateur root.
Dans l'exemple, le noeud principal est sam1mds-node1 :
[sam1mds-node1]root@solaris:~#
Le système de fichiers QFS ne doit pas démarrer si le système de fichiers local haute disponibilité n'est pas disponible. Créez une dépendance de la ressource SUNW.qfs vis-à-vis de la ressource SUNW.HAStoragePlus. Exécutez la commande clresource set -p Resource_dependencies=dependency resource-name de Solaris Cluster, où :
dependency correspond au nom de la ressource SUNW.HAStoragePlus.
resource-name correspond au nom de la ressource SUNW.qfs.
Dans cet exemple, nous créons une dépendance de la ressource SUNW.qfs vis-à-vis de la ressource SUNW.HAStoragePlus has-cfg (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[sam1mds-node1]root@solaris:~# clresource set \ -p Resource_dependencies=has-cfg has-qfs [sam1mds-node1]root@solaris:~#
Aucun nom d’hôte virtuel ne doit être rendu disponible par le cluster, à moins que le serveur de métadonnées QFS actif ne soit en ligne. Ainsi, créez une dépendance du nom d’hôte virtuel vis-à-vis de la ressource SUNW.qfs. Exécutez la commande clresource set -p Resource_dependencies=virtualMDS resource-name de Solaris Cluster, où :
virtualMDS correspond au nom d’hôte virtuel qui représente le serveur de métadonnées Oracle HSM actif.
resource-name correspond au nom de la ressource SUNW.qfs.
Dans cet exemple, le nom d’hôte virtuel que nous avons créé lorsque nous avons configuré la ressource SUNW.qfs est sam1mds. La ressouce est nommée has-qfs (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[sam1mds-node1]root@solaris:~# clresource set \ -p Resource_dependencies=sam1mds has-qfs [sam1mds-node1]root@solaris:~#
Procédez ensuite à la mise en ligne du groupe de ressources HA-SAM et au test de la configuration.
Connectez-vous au noeud principal du cluster HA-SAM en tant qu'utilisateur root.
Dans l'exemple, le noeud principal est sam1mds-node1 :
[sam1mds-node1]root@solaris:~#
Mettez le groupe de ressources en ligne. Exécutez les commandes clresourcegroup manage groupname et clresourcegroup online -emM groupname de Solaris Cluster, où groupname correspond au nom du groupe de ressources HA-SAM.
Dans cet exemple, nous mettons en ligne le groupe de ressources has-rg :
[sam1mds-node1]root@solaris:~# clresourcegroup manage has-rg [sam1mds-node1]root@solaris:~# clresourcegroup online -emM has-rg [sam1mds-node1]root@solaris:~#
Assurez-vous que le groupe de ressources HA-SAM est en ligne. Exécutez la commande Solaris Cluster clresourcegroup status.
Dans cet exemple, le groupe de ressources has-rg est online sur le noeud principal, sam1mds-node1 :
[sam1mds-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ has-rg sam1mds-node1 No Online sam1mds-node2 No Offline [sam1mds-node1]root@solaris:~#
Ensuite, assurez-vous que le groupe de ressources bascule correctement. Déplacez le groupe de ressources sur le noeud secondaire. Exécutez la commande clresourcegroup switch -n node2 groupname Solaris Cluster, où node2 correspond au nom du noeud secondaire et groupname correspond au nom que vous avez choisi pour le groupe de ressources HA-SAM. Exécutez ensuite clresourcegroup status pour vérifier le résultat.
Dans cet exemple, nous déplaçons le groupe de ressources has-rg vers sam1mds-node2 et confirmons que le groupe de ressources se met en ligne sur le noeud spécifié :
[sam1mds-node1]root@solaris:~# clresourcegroup switch -n sam1mds-node2 has-rg [sam1mds-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ has-rg sam1mds-node1 No Offline sam1mds-node2 No Online [sam1mds-node1]root@solaris:~#
Replacez le groupe de ressources sur le noeud principal. Exécutez la commande clresourcegroup switch -n node1 groupname de Solaris Cluster, où node1 correspond au nom du noeud principal et groupname correspond au nom que vous avez choisi pour le groupe de ressources HA-SAM. Exécutez ensuite clresourcegroup status pour vérifier le résultat.
Dans cet exemple, nous avons déplacé le groupe de ressources has-rg sur sam1mds-node1 :
[sam1mds-node1]root@solaris:~# clresourcegroup switch -n sam1mds-node1 has-rg [sam1mds-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ has-rg sam1mds-node1 No Online sam1mds-node2 No Offline [sam1mds-node1]root@solaris:~#
Si nécessaire, configurez dès maintenant le partage du système de fichiers réseau haute disponibilité (HA-NFS).
Les procédures détaillées relatives à la configuration de HA-NFS sont incluses dans le manuel Oracle Solaris Cluster Data Service for Network File System (NFS) Guide inclus dans la bibliothèque de documentation en ligne Oracle Solaris Cluster.
Si vous prévoyez d'utiliser la fonctionnalité de base de données sideband, reportez-vous au Configuration de la base de données de rapports.
Sinon, passez à la Configuration des notifications et de la journalisation.
Dans la configuration SC-RAC (Solaris Cluster-Oracle Real Application Cluster), le logiciel Solaris Cluster gère un système de fichiers partagé QFS en tant que ressource SUNW.qfs montée sur les noeuds qui hébergent également Oracle Database et le logiciel Oracle Real Application Cluster (RAC). Tous les noeuds sont configurés en tant que serveurs QFS, avec un noeud configuré comme serveur de métadonnées actif et les autres comme serveurs de métadonnées potentiels. Si le noeud du serveur de métadonnées actif tombe en panne, le logiciel Solaris Cluster active automatiquement un serveur de métadonnées potentiel sur un noeud en bon état et lance le basculement. Les E/S sont coordonnées via Oracle RAC et le système de fichiers QFS est partagé et déjà monté sur tous les noeuds. L'accès aux données reste donc ininterrompu.
Dans la configuration SC-RAC, le logiciel RAC coordonne les demandes d'E/S, distribue la charge de travail et conserve un ensemble unique et cohérent de fichiers de base de données pour plusieurs instances Oracle Database exécutées sur les noeuds du cluster. L'intégrité du système de fichiers étant assurée sous RAC, les serveurs de métadonnées QFS potentiels peuvent effectuer des E/S en tant que clients du système de fichiers partagé. Pour plus d'informations, reportez-vous à la documentation du service de données Oracle Solaris Cluster pour Oracle Real Application Clusters dans la bibliothèque de documentation en ligne Oracle Solaris Cluster.
Pour configurer un système de fichiers SC-RAC, effectuez les tâches ci-dessous :
Configuration d'un serveur de métadonnées QFS actif sur le noeud principal du cluster SC-RAC ou Configuration des serveurs de métadonnées QFS sur les noeuds SC-RAC à l'aide du stockage RAID logiciel
Configuration d'un serveur de métadonnées QFS potentiel sur les noeuds restants du cluster SC-RAC
Configuration du basculement des serveurs de métadonnées SC-RAC
Si nécessaire, configurez les partages NFS (système de fichiers réseau), comme décrit dans la Accès aux systèmes de fichiers à partir de plusieurs hôtes à l'aide de NFS et SMB/CIFS. HA-NFS (NFS haute disponibilité) n'est pas pris en charge.
Dans un système de fichiers partagé QFS, vous devez configurer un fichier d'hôtes sur les serveurs de métadonnées, de sorte que tous les hôtes puissent accéder aux métadonnées pour le système de fichiers. Le fichier d'hôtes est stocké avec le fichier mcf dans le répertoire /etc/opt/SUNWsamfs/. Lors de la création initiale d'un système de fichiers partagé, la commande sammkfs -S configure le partage selon les paramètres stockés dans ce fichier. Créez-le maintenant en appliquant la procédure ci-dessous.
Connectez-vous au noeud principal du cluster SC-RAC en tant qu'utilisateur root.
Dans l'exemple, le noeud principal estqfs1rac-node1 :
[qfs1rac-node1]root@solaris:~#
Affichez la configuration du cluster. Exécutez la commande /usr/global/bin/cluster show. Dans la sortie, recherchez l'enregistrement de chaque Node Name. Notez ensuite le privatehostname, le nom du Transport Adapter et la propriété ip_address de chaque adaptateur réseau.
Dans les exemples, chaque noeud comporte deux interfaces réseau, qfe3 et hme0 :
Les adaptateurs hme0 disposent d'adresses IP sur le réseau privé que le cluster utilise pour la communication interne entre les noeuds. Le logiciel Solaris Cluster attribue un privatehostname qui correspond à chaque adresse privée.
Par défaut, le nom d'hôte privé du noeud principal est clusternode1-priv et le nom d'hôte privé du noeud secondaire est clusternode2-priv.
Les adaptateurs qfe3 disposent d'adresses IP et de noms d'hôte publics (qfs1rac-node1 et qfs1rac-node2) que le cluster utilise pour le transport de données.
Notez que l'affichage a été abrégé à l'aide de points de suspension (...) :
[qfs1rac-node1]root@solaris:~# cluster show
...
=== Cluster Nodes ===
Node Name: qfs1rac-node1...
privatehostname: clusternode1-priv...
Transport Adapter List: qfe3, hme0...
Transport Adapter: qfe3...
Adapter Property(ip_address): 172.16.0.12...
Transport Adapter: hme0...
Adapter Property(ip_address): 10.0.0.129...
Node Name: qfs1rac-node2...
privatehostname: clusternode2-priv...
Transport Adapter List: qfe3, hme0...
Adapter Property(ip_address): 172.16.0.13...
Transport Adapter: hme0
Adapter Property(ip_address): 10.0.0.122...
Node Name: qfs1rac-node3...
privatehostname: clusternod3-priv...
Transport Adapter List: qfe3, hme0...
Adapter Property(ip_address): 172.16.0.33...
Transport Adapter: hme0
Adapter Property(ip_address): 10.0.0.092
A l'aide d'un éditeur de texte, créez le fichier /etc/opt/SUNWsamfs/hosts.family-set-name, où family-set-name correspond au nom de famille que le fichier /etc/opt/SUNWsamfs/mcf assigne à l'équipement du système de fichiers.
Dans cet exemple, nous créons le fichier hosts.qfs1rac à l'aide de l'éditeur de texte vi. Nous ajoutons des en-têtes facultatifs pour afficher les colonnes dans la table des hôtes, en commençant chaque ligne par le signe dièse (#) pour indiquer un commentaire :
[qfs1rac-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/hosts.qfs1rac # /etc/opt/SUNWsamfs/hosts.qfs1rac # Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ -------------------------------- ------- --- ----------
Dans la première colonne de la table, entrez les noms d'hôte des noeuds du serveur de métadonnées principal et secondaire, suivis par des espaces. Placez chaque entrée sur une ligne séparée.
Dans un fichier d'hôtes, les lignes sont des rangées (enregistrements) et les espaces sont des séparateurs de colonnes (champ). Dans cet exemple, la colonne Nom d'hôte des deux premières lignes répertorie les noms d'hôte des noeuds de clusterqfs1rac-node1, qfs1rac-node2 et qfs1rac-node3.
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ -------------------------------- ------- --- ---------- qfs1rac-node1 qfs1rac-node2 qfs1rac-node3
Dans la deuxième colonne de chaque ligne, commencez à fournir des informations Network Interface pour l'hôte Host Name. Saisissez le nom d'hôte privé ou l'adresse réseau privée Solaris Cluster de chaque noeud de cluster SC-RAC, suivi d'une virgule.
Les noeuds du serveur SC-RAC utilisent les noms d'hôte privés pour les communications de serveur à serveur au sein du cluster haute disponibilité. Dans cet exemple, nous utilisons les noms d'hôte privés clusternode1-priv, clusternode2-priv et clusternode3-priv qui sont les noms par défaut assignés par le logiciel Solaris Cluster :
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ -------------------------------- ------- --- ---------- qfs1rac-node1 clusternode1-priv, qfs1rac-node2 clusternode2-priv, qfs1rac-node3 clusternode3-priv,
A la suite de la virgule dans la deuxième colonne de chaque ligne, entrez le nom d'hôte public pour le serveur de métadonnées actif, suivi par des espaces.
Les noeuds de serveur SC-RAC utilisent le réseau de données public pour communiquer avec les clients, chacun résidant hors du cluster. Dans la mesure où l'adresse IP et le nom d'hôte du serveur de métadonnées actif changent lors du basculement (de qfs1rac-node1 à qfs1rac-node2, par exemple), nous représentons le serveur actif avec un nom d'hôte virtuel, qfs1rac-mds. Ultérieurement, nous configurerons le logiciel Solaris Cluster pour toujours acheminer les demandes pour qfs1rac-mds vers le noeud qui héberge actuellement le serveur de métadonnées actif :
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ -------------------------------- ------- --- ---------- qfs1rac-node1 clusternode1-priv,qfs1rac-mds qfs1rac-node2 clusternode2-priv,qfs1rac-mds qfs1rac-node3 clusternode3-priv,qfs1rac-mds
Dans la troisième colonne de chaque ligne, indiquez le nombre ordinal du serveur (1 pour le serveur de métadonnées actif et 2 pour le serveur de métadonnées potentiel), suivi par des espaces.
Dans cet exemple, le noeud principal qfs1rac-node1 est le serveur de métadonnées actif. Son numéro ordinal est donc 1. Le deuxième noeud, qfs1rac-node2, correspond au numéro ordinal 2, etc. :
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ -------------------------------- ------- --- ---------- qfs1rac-node1 clusternode1-priv,qfs1rac-mds 1 qfs1rac-node2 clusternode2-priv,qfs1rac-mds 2 qfs1rac-node3 clusternode3-priv,qfs1rac-mds 3
Dans la quatrième colonne de chaque ligne, entrez 0 (zéro), suivi par des espaces.
Le caractère 0, un trait d'union (-) ou une valeur vierge dans la quatrième colonne indiquent que l'hôte est activé (on), c'est-à-dire configuré avec un accès au système de fichiers partagé. Un 1 (chiffre un) indique que l'hôte est désactivé (off), configuré sans accès au système de fichiers (pour plus d'informations sur l'utilisation de ces valeurs lors de l'administration des systèmes de fichiers partagés, reportez-vous à la page de manuel samsharefs).
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ -------------------------------- ------- --- ---------- qfs1rac-node1 clusternode1-priv,qfs1rac-mds 1 0 qfs1rac-node2 clusternode2-priv,qfs1rac-mds 2 0 qfs1rac-node3 clusternode3-priv,qfs1rac-mds 3 0
Dans la cinquième colonne de la ligne du noeud principal, entrez le mot-clé server. Enregistrez le fichier et fermez l'éditeur de texte.
Le mot-clé server identifie le serveur de métadonnées actif par défaut :
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ -------------------------------- ------- --- ---------- qfs1rac-node1 clusternode1-priv,qfs1rac-mds 1 0 server qfs1rac-node2 clusternode2-priv,qfs1rac-mds 2 0 qfs1rac-node3 clusternode3-priv,qfs1rac-mds 2 0 :wq [qfs1rac-node1]root@solaris:~#
Placez une copie du fichier /etc/opt/SUNWsamfs/hosts.family-set-name global sur chaque noeud du cluster SC-RAC.
Procédez maintenant à la configuration d'un serveur de métadonnées QFS actif sur le noeud principal du cluster SC-RAC.
Sélectionnez le noeud du cluster qui servira à la fois de noeud principal pour le cluster SC-RAC et de serveur de métadonnées actif pour le système de fichiers partagé QFS. Connectez-vous en tant que root.
Dans l'exemple, le noeud principal estqfs1rac-node1 :
[qfs1rac-node1]root@solaris:~#
Sélectionnez les périphériques de stockage globaux qui seront utilisés pour le système de fichiers QFS. Exécutez la commande /usr/global/bin/cldevice list -v.
Le logiciel Solaris Cluster assigne des identificateurs de périphériques (DID) uniques à tous les périphériques qui se connectent aux noeuds du cluster. Les périphériques globaux sont accessibles depuis tous les noeuds du cluster, tandis que les périphériques locaux sont accessibles uniquement depuis les hôtes qui les montent. Les périphériques globaux restent accessibles à la suite d'un basculement. Ce n'est pas le cas des périphériques locaux.
Dans cet exemple, notez que les périphériques d1, d2, d6, d7 et d8 ne sont accessibles depuis aucun noeud. Nous effectuons donc la sélection parmi les périphériques d3, d4 et d5 lors de la configuration du système de fichiers partagé QFS haute disponibilité :
[qfs1rac-node1]root@solaris:~# cldevice list -v DID Device Full Device Path ---------- ---------------- d1 qfs1rac-node1:/dev/rdsk/c0t0d0 d2 qfs1rac-node1:/dev/rdsk/c0t6d0 d3 qfs1rac-node1:/dev/rdsk/c1t1d0 d3 qfs1rac-node2:/dev/rdsk/c1t1d0 d3 qfs1rac-node3:/dev/rdsk/c1t1d0 d4 qfs1rac-node1:/dev/rdsk/c1t2d0 d4 qfs1rac-node2:/dev/rdsk/c1t2d0 d4 qfs1rac-node3:/dev/rdsk/c1t2d0 d5 qfs1rac-node1:/dev/rdsk/c1t3d0 d5 qfs1rac-node2:/dev/rdsk/c1t3d0 d5 qfs1rac-node3:/dev/rdsk/c1t3d0 d6 qfs1rac-node2:/dev/rdsk/c0t0d0 d7 qfs1rac-node2:/dev/rdsk/c0t1d0 d8 qfs1rac-node3:/dev/rdsk/c0t1d0
Créez un système de fichiers ma partagé haute performance qui utilise les périphériques de données mr. Dans un éditeur de texte, ouvrez le fichier /etc/opt/SUNWsamfs/mcf.
Dans l'exemple, nous configurons le système de fichiers qfs1rac. Nous configurons le périphérique d3 en tant que périphérique de métadonnées (type d'équipement mm), et utilisons d4 et d5 comme périphériques de données (type d'équipement mr) :
[qfs1rac-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf # Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #------------------ --------- --------- ------- ------ -------------- qfs1rac 100 ma qfs1rac - /dev/did/dsk/d3s0 101 mm qfs1rac - /dev/did/dsk/d4s0 102 mr qfs1rac - /dev/did/dsk/d5s0 103 mr qfs1rac - ...
Dans le fichier /etc/opt/SUNWsamfs/mcf, entrez le paramètre shared dans la colonne Additional Parameters de l'entrée du système de fichiers. Enregistrez le fichier.
[qfs1rac-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf # Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #------------------ --------- --------- ------- ------ -------------- qfs1rac 100 ma qfs1rac - shared /dev/did/dsk/d3s0 101 mm qfs1rac - /dev/did/dsk/d4s0 102 mr qfs1rac - /dev/did/dsk/d5s0 103 mr qfs1rac - ... :wq [qfs1rac-node1]root@solaris:~#
Recherchez les erreurs éventuelles dans le fichier mcf. Exécutez la commande /opt/SUNWsamfs/sbin/sam-fsd et corrigez les erreurs trouvées.
La commande sam-fsd lit les fichiers de configuration Oracle HSM et initialise les systèmes de fichiers. Elle s'arrête en cas d'erreur. Dans l'exemple, nous vérifions le fichier mcf sur l'hôte qfs1rac-node1 :
[qfs1rac-node1]root@solaris:~# sam-fsd
...
Would start sam-archiverd()
Would start sam-stagealld()
Would start sam-stagerd()
Would start sam-amld()
[qfs1rac-node1]root@solaris:~#
Créez le système de fichiers. Exécutez la commande /opt/SUNWsamfs/sbin/sammkfs -S family-set-name, où family-set-name correspond à l'identificateur d'équipement du système de fichiers.
La commande sammkfs lit les fichiers hosts.family-set-name et mcf et crée un système de fichiers partagé avec les propriétés indiquées.
[qfs1rac-node1]root@solaris:~# sammkfs -S qfs1rac Building 'qfs1rac' will destroy the contents of devices: ... Do you wish to continue? [y/N]yes ... [qfs1rac-node1]root@solaris:~#
Ouvrez le fichier /etc/vfstab du système d'exploitation dans un éditeur de texte et démarrez une ligne pour le nouveau système de fichiers. Entrez le nom du système de fichiers dans la première colonne, suivi d'espaces, puis un tiret dans la deuxième colonne, suivi d'espaces.
Dans l'exemple, nous utilisons l'éditeur de texte vi. Nous démarrons une ligne pour le système de fichiers qfs1rac. Le tiret empêche le système d'exploitation de tenter de vérifier l'intégrité du système de fichiers à l'aide des outils UFS :
[qfs1rac-node1]root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- --------------- ------ ---- ------- ------------------ /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs1rac -
Dans la troisième colonne du fichier /etc/vfstab, entrez le point de montage du système de fichiers par rapport au cluster. Spécifiez un sous-répertoire qui ne se trouve pas directement en dessous du répertoire root du système.
Le montage d'un système de fichiers QFS partagé immédiatement sous la racine peut provoquer des problèmes de basculement lors de l'utilisation du type de ressource SUNW.qfs. Dans l'exemple, le point de montage pour le système de fichiers qfs1rac est /global/sc-rac/qfs1rac :
#File
#Device Device Mount System fsck Mount Mount
#to Mount to fsck Point Type Pass at Boot Options
#-------- ------- ----------------------- ------ ---- ------- ----------
/devices - /devices devfs - no -
/proc - /proc proc - no -
...
qfs1rac - /global/sc-rac/qfs1rac
Entrez le type de système de fichiers samfs dans la quatrième colonne, - (tiret) dans la cinquième colonne et no dans la sixième colonne.
#File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ----------------------- ------ ---- ------- ---------- /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs1rac - /global/sc-rac/qfs1rac samfs - no :wq [qfs1rac-node1]root@solaris:~#
Dans la septième colonne du fichier /etc/vfstab, entrez les options de montage répertoriées ci-dessous. Ensuite, enregistrez le fichier et fermez l'éditeur de texte.
Les options de montage suivantes sont recommandées pour la configuration de cluster SC-RAC. Elles peuvent être spécifiées ici, dans /etc/vfstab, ou dans le fichier /etc/opt/SUNWsamfs/samfs.cmd, si cela est plus approprié :
shared
stripe=1
sync_meta=1
mh_write
qwrite
forcedirectio
notrace
rdlease=300
wrlease=300
aplease=300
Dans l'exemple, la liste a été abrégée pour s'adapter à la mise en page :
#File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- -------------------- ------ ---- ------- ------------ /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs1rac - /global/sc-rac/qfs1rac samfs - no shared,...=300 :wq [qfs1rac-node1]root@solaris:~#
Créez le point de montage du système de fichiers partagé haute disponibilité.
[qfs1rac-node1]root@solaris:~# mkdir -p /global/sc-rac/qfs1rac [qfs1rac-node1]root@solaris:~#
Montez le système de fichiers partagé haute disponibilité sur le noeud principal.
[qfs1rac-node1]root@solaris:~# mount /global/sc-rac/qfs1rac [qfs1rac-node1]root@solaris:~#
Procédez ensuite à la configuration d'un serveur de métadonnées QFS potentiel sur les noeuds restants du cluster SC-RAC.
Les noeuds restants du cluster font office de serveurs de métadonnées potentiels. Un serveur de métadonnées potentiel est un hôte qui peut accéder aux périphériques de métadonnées et endosser les responsabilités d'un serveur de métadonnées. Ainsi, si le serveur de métadonnées actif sur le noeud principal tombe en panne, le logiciel Solaris Cluster peut basculer sur un noeud secondaire et activer un serveur de métadonnées potentiel.
Pour chaque noeud restant dans le cluster SC-RAC, procédez comme suit :
Connectez-vous au noeud en tant qu'utilisateur root.
Dans l'exemple, le noeud actuel est qfs1rac-node2 :
[qfs1rac-node2]root@solaris:~#
Copiez le fichier /etc/opt/SUNWsamfs/mcf du noeud principal vers le noeud actuel.
Recherchez les erreurs éventuelles dans le fichier mcf. Exécutez la commande /opt/SUNWsamfs/sbin/sam-fsd et corrigez les erreurs trouvées.
La commande sam-fsd lit les fichiers de configuration Oracle HSM et initialise les systèmes de fichiers. Elle s'arrête en cas d'erreur. Dans l'exemple, nous vérifions le fichier mcf sur l'hôte qfs1rac-node2 :
[qfs1rac-node2]root@solaris:~# sam-fsd
...
Would start sam-archiverd()
Would start sam-stagealld()
Would start sam-stagerd()
Would start sam-amld()
[qfs1rac-node2]root@solaris:~#
Ouvrez le fichier /etc/vfstab du système d'exploitation dans un éditeur de texte et démarrez une ligne pour le nouveau système de fichiers.
Dans cet exemple, nous utilisons l'éditeur de texte vi :
[qfs1rac-node2]root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ---------------------- ------ ---- ------- ------------ /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs1rac - /global/sc-rac/qfs1rac samfs - no
Dans la septième colonne du fichier /etc/vfstab, entrez les options de montage répertoriées ci-dessous. Ensuite, enregistrez le fichier et fermez l'éditeur de texte.
Les options de montage suivantes sont recommandées pour la configuration de cluster SC-RAC. Elles peuvent être spécifiées ici, dans /etc/vfstab, ou dans le fichier /etc/opt/SUNWsamfs/samfs.cmd, si cela est plus approprié :
shared
stripe=1
sync_meta=1
mh_write
qwrite
forcedirectio
notrace
rdlease=300
wrlease=300
aplease=300
Dans l'exemple, la liste a été abrégée pour s'adapter à la mise en page :
#File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ---------------------- ------ ---- ------- ------------ /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs1rac - /global/sc-rac/qfs1rac samfs - no shared,...=300 :wq [qfs1rac-node2]root@solaris:~#
Créez le point de montage du système de fichiers partagé haute disponibilité sur le noeud secondaire.
[qfs1rac-node2]root@solaris:~# mkdir -p /global/sc-rac/qfs1rac [qfs1rac-node2]root@solaris:~#
Montez le système de fichiers partagé haute disponibilité sur le noeud secondaire.
[qfs1rac-node2]root@solaris:~# mount /global/sc-rac/qfs1rac [qfs1rac-node2]root@solaris:~#
Procédez maintenant à laconfiguration du basculement des serveurs de métadonnées SC-RAC .
Lorsque vous hébergez un système de fichiers partagé Oracle HSM dans un cluster géré par le logiciel Solaris Cluster, vous configurez le basculement des serveurs de métadonnées en créant une ressource de cluster SUNW.qfs, un type de ressource défini par le logiciel Oracle HSM (reportez-vous à la page de manuel SUNW.qfs pour plus d'informations). Pour créer et configurer la ressource pour une configuration SC-RAC, procédez comme suit :
Connectez-vous au noeud principal dans le cluster SC-RAC en tant qu'utilisateur root.
Dans l'exemple, le noeud principal estqfs1rac-node1 :
[qfs1rac-node1]root@solaris:~#
Définissez le type de ressource QFS, SUNW.qfs, pour le logiciel Solaris Cluster. Exécutez la commande clresourcetype registerSUNW.qfs.
[qfs1rac-node1]root@solaris:~# clresourcetype registerSUNW.qfs [qfs1rac-node1]root@solaris:~#
Si l'enregistrement échoue parce que le fichier d'enregistrement est introuvable, placez un lien symbolique vers le répertoire /opt/SUNWsamfs/sc/etc/ dans le répertoire dans lequel Solaris Cluster conserve les fichiers d'enregistrement de type de ressource, /opt/cluster/lib/rgm/rtreg/.
Vous n'avez pas installé le logiciel Oracle Solaris Cluster avant d'installer le logiciel Oracle HSM. Normalement, Oracle HSM fournit automatiquement l'emplacement du fichier d'enregistrement SUNW.qfs lorsqu'il détecte Solaris Cluster durant l'installation. Vous devez donc créer un lien manuellement.
[qfs1rac-node1]root@solaris:~# cd /opt/cluster/lib/rgm/rtreg/ [qfs1rac-node1]root@solaris:~# ln -s /opt/SUNWsamfs/sc/etc/SUNW.qfs SUNW.qfs [qfs1rac-node1]root@solaris:~#
Créez un groupe de ressources pour le serveur de métadonnées QFS. Exécutez la commande clresourcegroup create -n node-list group-name de Solaris Cluster, où node-list correspond à une liste séparée par des virgules des noeuds du cluster et group-name correspond au nom que nous souhaitons utiliser pour le groupe de ressources.
Dans cet exemple, nous créons le groupe de ressources qfsracrg avec les noeuds de serveur SC-RAC en tant que membres (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[qfs1rac-node1]root@solaris:~# clresourcegroup create \ -n qfs1rac-node1,qfs1rac-node2 qfsracrg [qfs1rac-node1]root@solaris:~#
Dans le nouveau groupe de ressources, configurez un nom d'hôte virtuel pour le serveur de métadonnées actif. Exécutez la commande clreslogicalhostname create -g group-name de Solaris Cluster, où group-name correspond au nom du groupe de ressources QFS et virtualMDS correspond au nom de l'hôte virtuel.
Utilisez le même nom d'hôte virtuel que vous avez utilisé dans les fichiers d'hôtes pour le système de fichiers partagé. Dans cet exemple, nous créons l'hôte virtuel qfs1rac-mds dans le groupe de ressources qfsracrg (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[qfs1rac-node1]root@solaris:~# clreslogicalhostname create \ -g qfsracrg qfs1rac-mds [qfs1rac-node1]root@solaris:~#
Ajoutez les ressources du système de fichiers QFS au groupe de ressources. Exécutez la commande clresource create -g group-name -t SUNW.qfs -x QFSFileSystem=mount-point -y Resource_dependencies=virtualMDS resource-name, où :
group-name correspond au nom du groupe de ressources QFS.
mount-point correspond au point de montage du système de fichiers dans le cluster, un sous-répertoire qui n'est pas directement sous le répertoire root du système.
Le montage d'un système de fichiers QFS partagé immédiatement sous la racine peut provoquer des problèmes de basculement lors de l'utilisation du type de ressource SUNW.qfs.
virtualMDS correspond au nom d'hôte virtuel du serveur de métadonnées actif.
resource-name correspond au nom que vous souhaitez donner à la ressource.
Dans l'exemple, nous créons une ressource nommée scrac du type SUNW.qfs dans le groupe de ressources qfsracrg. Nous définissons la propriété d'extension SUNW.qfs QFSFileSystemsur le point de montage /global/sc-rac/qfs1rac. Nous définissons la propriété standard Resource_dependencies sur l'hôte logique pour le serveur de métadonnées actif qfs1rac-mds (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[qfs1rac-node1]root@solaris:~# create -g qfsracrg -t SUNW.qfs \ -x QFSFileSystem=/global/sc-rac/qfs1rac \ -y Resource_dependencies=qfs1rac-mds scrac [qfs1rac-node1]root@solaris:~#
Mettez le groupe de ressources en ligne. Exécutez les commandes clresourcegroup manage group-name et clresourcegroup online -emM group-name de Solaris Cluster, où group-name correspond au nom du groupe de ressources QFS.
Dans l'exemple, nous mettons en ligne le groupe de ressources qfsracrg :
[qfs1rac-node1]root@solaris:~# clresourcegroup manage qfsracrg [qfs1rac-node1]root@solaris:~# clresourcegroup online -emM qfsracrg [qfs1rac-node1]root@solaris:~#
Assurez-vous que le groupe de ressources QFS est en ligne. Exécutez la commande Solaris Cluster clresourcegroup status.
Dans l'exemple, le groupe de ressources qfsracrg est online sur le noeud principal, qfs1rac-node1 :
[qfs1rac-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ qfsracrg qfs1rac-node1 No Online qfs1rac-node2 No Offline qfs1rac-node3 No Offline [qfs1rac-node1]root@solaris:~#
Assurez-vous que le groupe de ressources bascule correctement. Déplacez le groupe de ressources sur le noeud secondaire. Exécutez la commande clresourcegroup switch -n node2 group-name de Solaris Cluster, où node2 correspond au nom du noeud secondaire et group-name correspond au nom que vous avez choisi pour le groupe de ressources HA-SAM. Exécutez ensuite clresourcegroup status pour vérifier le résultat.
Dans cet exemple, nous déplaçons le groupe de ressources qfsracrg vers qfs1rac-node2 et qfs1rac-node3, et confirmons que le groupe de ressources se met en ligne sur le noeud spécifié :
[qfs1rac-node1]root@solaris:~# clresourcegroup switch -n qfs1rac-node2 qfsracrg [qfs1rac-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ qfsracrg qfs1rac-node1 No Offline qfs1rac-node2 No Online qfs1rac-node3 No Offline [qfs1rac-node1]root@solaris:~# clresourcegroup switch -n qfs1rac-node3 qfsracrg [qfs1rac-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ qfsracrg qfs1rac-node1 No Offline qfs1rac-node2 No Offline qfs1rac-node3 No Online [qfs1rac-node1]root@solaris:~#
Replacez le groupe de ressources sur le noeud principal. Exécutez la commande clresourcegroup switch -n node1 group-name de Solaris Cluster, où node1 correspond au nom du noeud principal et group-name correspond au nom que vous avez choisi pour le groupe de ressources HA-SAM. Exécutez ensuite clresourcegroup status pour vérifier le résultat.
Dans cet exemple, nous avons replacé le groupe de ressources qfsracrg sur qfs1rac-node1 :
[qfs1rac-node1]root@solaris:~# clresourcegroup switch -n qfs1rac-node1 qfsracrg [qfs1rac-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ samr qfs1rac-node1 No Online qfs1rac-node2 No Offline qfs1rac-node3 No Offline [qfs1rac-node1]root@solaris:~#
Si vous prévoyez d'utiliser la fonctionnalité de base de données sideband, reportez-vous au Configuration de la base de données de rapports.
Sinon, passez à la Configuration des notifications et de la journalisation.
Un système de fichiers haute disponibilité doit stocker les données et les métadonnées sur des périphériques de stockage principaux redondants. Le matériel de baie de disques redondant peut fournir la redondance à l'aide de RAID-1 ou RAID-10 pour les métadonnées et RAID-5 pour les données. Si vous avez besoin d'utiliser des périphériques de disques SCSI bruts à double accès ou une baie JBOD (just a bunch of disks) comme stockage principal, vous devez fournir la redondance requise en logiciel.
Pour cette raison, la configuration SC-RAC prend en charge les configurations RAID logicielles basées sur les ensembles de disques multipropriétaire Oracle Solaris Volume Manager (SVM). Cette section décrit les étapes de base que vous devez effectuer lors de la configuration de cette variante de la configuration de système de fichiers SC-RAC.
Notez que vous devez utiliser Solaris Volume Manager exclusivement pour la gestion de la baie de stockage redondante. Ne concaténez pas le stockage sur des périphériques séparés. Cette pratique répartit les E/S vers les périphériques composants de manière inefficace et dégrade les performances du système de fichiers QFS.
Effectuez les tâches suivantes :
Création de groupes de disques multipropriétaire Solaris Volume Manager
Création de volumes en miroir pour les données et métadonnées QFS
Création d'un système de fichiers partagé QFS sur le cluster SC-RAC à l'aide de volumes en miroir
Depuis Solaris 11, Solaris Volume Manager (SVM) n'est plus intégré à solaris. Toutefois, le logiciel Solaris Cluster 4 continue à prendre en charge Solaris Volume Manager. Ainsi, pour utiliser le logiciel, vous devez télécharger et installer la version incluse avec Solaris 10 9/10. Pour chaque noeud dans le cluster, procédez comme suit :
Connectez-vous au noeud en tant qu'utilisateur root.
Dans les exemples ci-dessous, nous configurons le noeud de cluster qfs2rac-node1 à l'aide de Solaris Image Packaging System (IPS) :
[qfs2rac-node1]root@solaris:~#
Recherchez les packages Solaris Volume Manager (SVM) disponibles localement. Exécutez la commande pkg info svm.
[qfs2rac-node1]root@solaris:~# pkg info svm pkg: info: no packages matching the following patterns you specified are installed on the system. Try specifying -r to query remotely: svm [qfs2rac-node1]root@solaris:~#
Si vous ne trouvez aucun package localement, recherchez dans le référentiel Solaris Image Packaging System (IPS). Exécutez la commande pkg -r svm.
[qfs2rac-node1]root@solaris:~# pkg -r svm Name: storage/svm Summary: Solaris Volume Manager Description: Solaris Volume Manager commands Category: System/Core State: Not installed Publisher: solaris Version: 0.5.11 Build Release: 5.11 Branch: 0.175.0.0.0.2.1 Packaging Date: October 19, 2011 06:42:14 AM Size: 3.48 MB FMRI: pkg://solaris/storage/svm@0.5.11,5.11-0.175.0.0.0.2.1:20111019T064214Z [qfs2rac-node1]root@solaris:~#
Installez le package. Exécutez la commande pkg install storage/svm :
[qfs2rac-node1]root@solaris:~# pkg install storage/svm Packages to install: 1 Create boot environment: No Create backup boot environment: Yes Services to change: 1 DOWNLOAD PKGS FILES XFER (MB) Completed 1/1 104/104 1.6/1.6 PHASE ACTIONS Install Phase 168/168 PHASEITEMS Package State Update Phase 1/1 Image State Update Phase 2/2 [qfs2rac-node1]root@solaris:~#
Lorsque l'installation est terminée, vérifiez l'emplacement de metadb. Exécutez la commande which metadb.
[qfs2rac-node1]root@solaris:~# which metadb /usr/sbin/metadb [qfs2rac-node1]root@solaris:~#
Vérifiez l'installation. Exécutez la commande metadb.
[qfs2rac-node1]root@solaris:~# metadb
[qfs2rac-node1]root@solaris:~#
Si metadb renvoie une erreur, vérifiez si le fichier kernel/drv/md.conf existe.
[qfs2rac-node1]root@solaris:~# metadb metadb: <HOST>: /dev/md/admin: No such file or directory [qfs2rac-node1]root@solaris:~# ls -l /kernel/drv/md.conf -rw-r--r-- 1 root sys 295 Apr 26 15:07 /kernel/drv/md.conf [qfs2rac-node1]root@solaris:~#
Si le fichier kernel/drv/md.conf n'existe pas, créez-le. Définissez l'utilisateur root comme propriétaire du fichier et sys comme propriétaire du groupe. Définissez les autorisations sur 644.
Dans l'exemple, nous créons le fichier avec l'éditeur vi. Le contenu du fichier doit ressembler à ceci :
[qfs2rac-node1]root@solaris:~# vi kernel/drv/md.conf ################################################### #pragma ident "@(#)md.conf 2.1 00/07/07 SMI" # # Copyright (c) 1992-1999 by Sun Microsystems, Inc. # All rights reserved. # name="md" parent="pseudo" nmd=128 md_nsets=4; #################################################### :wq [qfs2rac-node1]root@solaris:~# chown root:sys kernel/drv/md.conf [qfs2rac-node1]root@solaris:~# chmod 644 [qfs2rac-node1]root@solaris:~#
Lancez une nouvelle analyse dynamique du fichier md.conf et assurez-vous que l'arborescence de périphériques est mise à jour. Exécutez la commande update_drv -f md :
Dans l'exemple, l'arborescence de périphériques est mise à jour. Solaris Volume Manager est donc installé :
[qfs2rac-node1]root@solaris:~# update_drv -f md [qfs2rac-node1]root@solaris:~# ls -l /dev/md/admin lrwxrwxrwx 1 root root 31 Apr 20 10:12 /dev/md/admin -> ../../devices/pseudo/md@0:admin [qfs2rac-node1]root@solaris:~#
Procédez ensuite à la création de groupes de disques multipropriétaire Solaris Volume Manager.
Connectez-vous à tous les noeuds dans la configuration SC-RAC en tant qu'utilisateur root.
Dans l'exemple, nous nous connectons au noeud qfs2rac-node1. Nous ouvrons ensuite des nouvelles fenêtres de terminal et utilisons ssh pour nous connecter aux noeuds qfs2rac-node2 et qfs2rac-node3 :
[qfs2rac-node1]root@solaris:~# [qfs2rac-node1]root@solaris:~# ssh root@qfs2rac-node2 Password: [qfs2rac-node2]root@solaris:~# [qfs2rac-node1]root@solaris:~# ssh root@qfs2rac-node3 Password: [qfs2rac-node3]root@solaris:~#
Si vous utilisez Oracle Solaris Cluster 4.x sous Solaris 11.x et que vous ne l'avez pas déjà fait, vous devez procéder à l'installation de Solaris Volume Manager sur chaque noeud avant de poursuivre.
A partir de Solaris 11, Solaris Volume Manager n'est plus installé par défaut.
Sur chaque noeud, connectez un nouveau périphérique de base de données d'état et créez trois répliques de base de données d'état. Exécutez la commande metadb -a -f -c3 device-name, où device-name correspond à un nom de périphérique physique sous la forme cXtYdYsZ.
N'utilisez pas les identificateurs de périphérique (DID) Solaris Cluster. Utilisez le nom de périphérique physique. Dans l'exemple, nous créons les périphériques de base de données d'état sur les trois noeuds du cluster :
[qfs2rac-node1]root@solaris:~# metadb -a -f -c3 /dev/rdsk/c0t0d0 [qfs2rac-node2]root@solaris:~# metadb -a -f -c3 /dev/rdsk/c0t6d0 [qfs2rac-node3]root@solaris:~# metadb -a -f -c3 /dev/rdsk/c0t4d0
Créez un groupe de disques multipropriétaire Solaris Volume Manager sur un noeud. Exécutez la commande metaset -sdiskset -M -a -h host-list, où host-list correspond à une liste de propriétaires délimitée par des espaces.
Solaris Volume Manager prend en charge jusqu'à quatre hôtes par ensemble de disques. Dans cet exemple, nous créons le groupe de disques datadisks sur qfs2rac-node1 et indiquons les trois noeuds qfs2rac-node1, qfs2rac-node2 et qfs2rac-node3 en tant que propriétaires (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[qfs2rac-node1]root@solaris:~# metaset -s datadisks -M -a -h qfs2rac-node1 \ qfs2rac-node2 qfs2rac-node3
Répertoriez les périphériques sur l'un des noeuds. Exécutez la commande Solaris Cluster cldevice list -n -v.
[qfs2rac-node1]root@solaris:~# cldevice list -n -v DID Device Full Device Path ---------- ---------------- d13 qfs2rac-node1:/dev/rdsk/c6t600C0FF00000000000332B62CF3A6B00d0 d14 qfs2rac-node1:/dev/rdsk/c6t600C0FF0000000000876E950F1FD9600d0 d15 qfs2rac-node1:/dev/rdsk/c6t600C0FF0000000000876E9124FAF9C00d0 ... [qfs2rac-node1]root@solaris:~#
Dans la sortie de la commande cldevice list -n -v, sélectionnez les périphériques qui seront mis en miroir.
Dans l'exemple, nous sélectionnons quatre paires de périphériques pour quatre miroirs : d21 et d13, d14 et d17, d23 et d16, et d15 et d19.
[qfs2rac-node1]root@solaris:~# cldevice list -n -v DID Device Full Device Path ---------- ---------------- d13 qfs2rac-node1:/dev/rdsk/c6t600C0FF00000000000332B62CF3A6B00d0 d14 qfs2rac-node1:/dev/rdsk/c6t600C0FF0000000000876E950F1FD9600d0 d15 qfs2rac-node1:/dev/rdsk/c6t600C0FF0000000000876E9124FAF9C00d0 d16 qfs2rac-node1:/dev/rdsk/c6t600C0FF00000000000332B28488B5700d0 d17 qfs2rac-node1:/dev/rdsk/c6t600C0FF000000000086DB474EC5DE900d0 d18 qfs2rac-node1:/dev/rdsk/c6t600C0FF0000000000876E975EDA6A000d0 d19 qfs2rac-node1:/dev/rdsk/c6t600C0FF000000000086DB47E331ACF00d0 d20 qfs2rac-node1:/dev/rdsk/c6t600C0FF0000000000876E9780ECA8100d0 d21 qfs2rac-node1:/dev/rdsk/c6t600C0FF000000000004CAD5B68A7A100d0 d22 qfs2rac-node1:/dev/rdsk/c6t600C0FF000000000086DB43CF85DA800d0 d23 qfs2rac-node1:/dev/rdsk/c6t600C0FF000000000004CAD7CC3CDE500d0 d24 qfs2rac-node1:/dev/rdsk/c6t600C0FF000000000086DB4259B272300d0 .... [qfs2rac-node1]root@solaris:~#
Ajoutez les périphériques sélectionnés à l'ensemble de disques sur le même noeud. Exécutez la commande metaset -a devicelist, où devicelist correspond à une liste délimitée par des espaces d'un ou plusieurs identificateurs de périphériques en cluster.
Dans cet exemple, nous ajoutons les disques répertoriés à l'ensemble de disques multipropriétaire dataset1 (notez que la commande ci-dessous est entrée sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
[qfs2rac-node1]root@solaris:~# metaset -s dataset1 -M -a -h /dev/did/rdsk/d21 \ /dev/did/rdsk/d13 /dev/did/rdsk/d14 /dev/did/rdsk/d17 /dev/did/rdsk/d23 \ /dev/did/rdsk/d16 /dev/did/rdsk/d15 /dev/did/rdsk/d19 [qfs2rac-node1]root@solaris:~#
Procédez ensuite à la création de volumes en miroir pour les données et métadonnées QFS.
Pour que les relations entre les composants restent claires, définissez un schéma de nommage pour les volumes logiques RAID-0 et les miroirs RAID-1 que vous allez créer.
Généralement, les miroirs RAID-1 sont nommés dn, où n correspond à un entier. Les volumes RAID-0 qui composent les miroirs RAID-1 sont nommés dnX, où X correspond à un entier représentant la position du périphérique au sein du miroir (généralement 0 ou 1 pour un miroir bidirectionnel).
Dans les exemples tout au long de cette procédure, nous créons des miroirs RAID-1 bidirectionnels à partir de paires de volumes logiques RAID-0. Nous nommons donc les miroirs d1, d2, d3, d4, et ainsi de suite. Nous nommons ensuite chaque paire de volumes RAID-0 pour le miroir RAID-1 qui les inclut : d10 et d11, d20 et d21, d30 et d31, d40 et d41, etc.
Connectez-vous au noeud sur lequel vous avez créé l'ensemble de disques multipropriétaire. Connectez-vous en tant que root.
Dans les exemples ci-dessus, nous avons créé l'ensemble de disques sur qfs2rac-node1 :
[qfs2rac-node1]root@solaris:~#
Créez le premier volume logique RAID-0. Exécutez la commande metainit -s diskset-name device-name number-of-stripes components-per-stripe component-names, où :
diskset-name correspond au nom que vous avez choisi pour l'ensemble de disques.
device-name correspond au nom que vous avez choisi pour le volume logique RAID-0.
number-of-stripes correspond à 1.
components-per-stripe correspond à 1.
component-name correspond au nom de périphérique du composant d'ensemble de disques à utiliser dans le volume RAID-0.
Dans l'exemple, nous utilisons le périphérique de cluster (DID) /dev/did/dsk/d21s0 dans l'ensemble de disques multipropriétaire dataset1 pour créer le volume logique RAID-0 d10 :
[qfs2rac-node1]root@solaris:~# metainit -s dataset1 d10 1 1 /dev/did/dsk/d21s0 [qfs2rac-node1]root@solaris:~#
Créez les volumes logiques RAID-0 restants.
[qfs2rac-node1]root@solaris:~# metainit -s dataset1 d11 1 1 /dev/did/dsk/d13s0 [qfs2rac-node1]root@solaris:~# metainit -s dataset1 d20 1 1 /dev/did/dsk/d14s0 [qfs2rac-node1]root@solaris:~# metainit -s dataset1 d21 1 1 /dev/did/dsk/d17s0 [qfs2rac-node1]root@solaris:~# metainit -s dataset1 d30 1 1 /dev/did/dsk/d23s0 [qfs2rac-node1]root@solaris:~# metainit -s dataset1 d31 1 1 /dev/did/dsk/d16s0 [qfs2rac-node1]root@solaris:~# metainit -s dataset1 d40 1 1 /dev/did/dsk/d15s0 [qfs2rac-node1]root@solaris:~# metainit -s dataset1 d41 1 1 /dev/did/dsk/d19s0 ... [qfs2rac-node1]root@solaris:~#
Créez le premier miroir RAID-1. Exécutez la commande metainit -s diskset-name RAID-1-mirrorname -m RAID-0-volume0, où :
diskset-name correspond au nom de l'ensemble de disques multipropriétaire.
RAID-1-mirrorname correspond au nom du volume RAID-1 en miroir.
RAID-0-volume0 correspond au premier volume logique RAID-0 que vous ajoutez au miroir.
Dans l'exemple, nous créons le miroir d1 et ajoutons le premier volume RAID-0 dans le miroir, d10 :
[qfs2rac-node1]root@solaris:~# metainit -s dataset1 d1 -m d10 [qfs2rac-node1]root@solaris:~#
Ajoutez les volumes RAID-0 restants au premier miroir RAID-1. Exécutez la commande metattach -s diskset-name RAID-1-mirrorname RAID-0-volume, où :
diskset-name correspond au nom de l'ensemble de disques multipropriétaire
RAID-1-mirrorname correspond au nom du volume RAID-1 en miroir
RAID-0-volume correspond au volume logique RAID-0 que vous ajoutez au miroir.
Dans l'exemple, d1 étant un miroir bidirectionnel, nous ajoutons un volume RAID-0 unique, d11 :
[qfs2rac-node1]root@solaris:~# metattach -s dataset1 d11 d1 [qfs2rac-node1]root@solaris:~#
Créez les autres miroirs.
Dans l'exemple, nous créons les miroirs d2, d3, d4, etc.
[qfs2rac-node1]root@solaris:~# metainit -s dataset1 d2 -m d20 [qfs2rac-node1]root@solaris:~# metattach -s dataset1 d21 d2 [qfs2rac-node1]root@solaris:~# metainit -s dataset2 d3 -m d30 [qfs2rac-node1]root@solaris:~# metattach -s dataset2 d31 d3 [qfs2rac-node1]root@solaris:~# metainit -s dataset2 d4 -m d40 [qfs2rac-node1]root@solaris:~# metattach -s dataset2 d41 d4 ... [qfs2rac-node1]root@solaris:~#
Sélectionnez les miroirs qui conserveront les métadonnées du système de fichiers QFS.
Pour les exemples ci-dessous, nous choisissons les miroirs d1 et d2.
Dans les miroirs sélectionnés, créez des partitions logicielles pour conserver les métadonnées QFS. Pour chaque miroir, exécutez la commande metainit -s diskset-name partition-name -p RAID-1-mirrorname size, où :
diskset-name correspond au nom de l'ensemble de disques multipropriétaire.
partition-name correspond au nom de la nouvelle partition.
RAID-1-mirrorname correspond au nom du miroir.
size correspond à la taille de la partition.
Dans l'exemple, nous créons deux partitions de 500 giga-octets : d53 sur le miroir d1 et d63 sur le miroir d2 :
[qfs2rac-node1]root@solaris:~# metainit -s dataset1 d53 -p d1 500g [qfs2rac-node1]root@solaris:~# metainit -s dataset1 d63 -p d2 500g
Procédez ensuite à la création d'un système de fichiers partagé QFS sur le cluster SC-RAC à l'aide de volumes en miroir.
Si ce n'est pas encore fait, effectuez la procédure de la Création d'un fichier d'hôtes de système de fichiers partagé QFS sur tous les noeuds du cluster SC-RAC. Lorsque vous avez terminé, revenez à cette page.
Sélectionnez le noeud du cluster qui servira à la fois de noeud principal pour le cluster SC-RAC et de serveur de métadonnées actif pour le système de fichiers partagé QFS. Connectez-vous en tant que root.
Dans l'exemple, nous sélectionnons le noeud qfs2rac-node1 :
[qfs2rac-node1]root@solaris:~#
Sur le noeud principal, créez un système de fichiers partagé ma haute performance. Utilisez les volumes de disques en miroir Solaris Volume Manager en tant que périphériques de métadonnées mm et périphériques de données mr. Dans un éditeur de texte, ouvrez le fichier /etc/opt/SUNWsamfs/mcf, apportez les modifications requises et enregistrez le fichier.
Dans l'exemple, nous utilisons l'éditeur de texte vi pour créer le système de fichiers qfs2rac. Les partitions sur les volumes en miroir d1 et d2 servent de périphériques de métadonnées mm du système de fichiers, 110 et 120. Les volumes en miroir d3 et d4 servent de périphériques de données mr du système de fichiers, 130 et 140.
[qfs2rac-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf # /etc/opt/SUNWsamfs/mcf file: # # Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters # ----------------------- --------- -------- ------- ------ ---------- qfs2rac 100 ma qfs2rac on shared /dev/md/dataset1/dsk/d53 110 mm qfs2rac on /dev/md/dataset1/dsk/d63 120 mm qfs2rac on /dev/md/dataset1/dsk/d3 130 mr qfs2rac on /dev/md/dataset1/dsk/d4 140 mr qfs2rac on :wq [qfs2rac-node1]root@solaris:~#
Recherchez les erreurs éventuelles dans le fichier mcf. Exécutez la commande /opt/SUNWsamfs/sbin/sam-fsd et corrigez les erreurs trouvées.
La commande sam-fsd lit les fichiers de configuration Oracle HSM et initialise les systèmes de fichiers. Elle s'arrête en cas d'erreur. Dans l'exemple, nous vérifions le fichier mcf sur l'hôte qfs2rac-node1 :
[qfs2rac-node1]root@solaris:~# sam-fsd
...
Would start sam-archiverd()
Would start sam-stagealld()
Would start sam-stagerd()
Would start sam-amld()
[qfs2rac-node1]root@solaris:~#
Créez le système de fichiers. Exécutez la commande /opt/SUNWsamfs/sbin/sammkfs -S family-set-name, où family-set-name correspond à l'identificateur d'équipement du système de fichiers.
La commande sammkfs lit les fichiers hosts.family-set-name et mcf et crée un système de fichiers partagé avec les propriétés indiquées.
[qfs2rac-node1]root@solaris:~# sammkfs -S qfs2rac Building 'qfs2rac' will destroy the contents of devices: ... Do you wish to continue? [y/N]yes ... [qfs2rac-node1]root@solaris:~#
Ouvrez le fichier /etc/vfstab du système d'exploitation dans un éditeur de texte et démarrez une ligne pour le nouveau système de fichiers. Entrez le nom du système de fichiers dans la première colonne, suivi d'espaces, puis un tiret dans la deuxième colonne, suivi d'espaces.
Dans l'exemple, utilisez l'éditeur de texte vi. Nous démarrons une ligne pour le système de fichiers qfs2rac. Le tiret empêche le système d'exploitation de tenter de vérifier l'intégrité du système de fichiers à l'aide des outils UFS :
[qfs2rac-node1]root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ---------------------- ------ ---- ------- ------------ /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs2rac -
Dans la troisième colonne du fichier /etc/vfstab, entrez le point de montage du système de fichiers par rapport au cluster. Spécifiez un sous-répertoire de point de montage qui ne se trouve pas directement en dessous du répertoire root du système.
Le montage d'un système de fichiers QFS partagé immédiatement sous la racine peut provoquer des problèmes de basculement lors de l'utilisation du type de ressource SUNW.qfs. Dans l'exemple, le point de montage pour le système de fichiers qfs2rac est /global/sc-rac/qfs2rac :
#File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ---------------------- ------ ---- ------- ------------ /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs2rac - /global/sc-rac/qfs2rac samfs - no
Dans la quatrième colonne du fichier /etc/vfstab, entrez le type de système de fichiers (nfs).
#File
#Device Device Mount System fsck Mount Mount
#to Mount to fsck Point Type Pass at Boot Options
#-------- ------- ---------------------- ------ ---- ------- ------------
/devices - /devices devfs - no -
/proc - /proc proc - no -
...
qfs2rac - /global/sc-rac/qfs2rac samfs
Dans la cinquième colonne du fichier /etc/vfstab, entrez l'option de passe fsck (-).
#File
#Device Device Mount System fsck Mount Mount
#to Mount to fsck Point Type Pass at Boot Options
#-------- ------- ---------------------- ------ ---- ------- ------------
/devices - /devices devfs - no -
/proc - /proc proc - no -
...
qfs2rac - /global/sc-rac/qfs2rac samfs -
Dans la sixième colonne du fichier /etc/vfstab, entrez l'option de montage au démarrage (no).
#File
#Device Device Mount System fsck Mount Mount
#to Mount to fsck Point Type Pass at Boot Options
#-------- ------- ---------------------- ------ ---- ------- ------------
/devices - /devices devfs - no -
/proc - /proc proc - no -
...
qfs2rac - /global/sc-rac/qfs2rac samfs - no
Dans la septième colonne du fichier /etc/vfstab, entrez l'option de montage sw_raid et les options de montage recommandées pour la configuration SC-RAC. Ensuite, enregistrez le fichier et fermez l'éditeur de texte.
Les options de montage suivantes sont recommandées. Elles peuvent être spécifiées ici, dans /etc/vfstab, ou dans le fichier /etc/opt/SUNWsamfs/samfs.cmd, si cela est plus approprié :
shared
stripe=1
sync_meta=1
mh_write
qwrite
forcedirectio
notrace
rdlease=300
wrlease=300
aplease=300
Dans cet exemple, la liste des options de montage a été abrégée pour s'adapter à la mise en page :
#File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ---------------------- ------ ---- ------- ------------ /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs2rac - /global/sc-rac/qfs2rac samfs - no shared,...sw_raid :wq [qfs2rac-node1]root@solaris:~#
Créez le point de montage du système de fichiers partagé haute disponibilité.
[qfs2rac-node1]root@solaris:~# mkdir -p /global/sc-rac/qfs2rac [qfs2rac-node1]root@solaris:~#
Montez le système de fichiers partagé haute disponibilité sur le noeud principal.
[qfs2rac-node1]root@solaris:~# mount /global/sc-rac/qfs2rac [qfs2rac-node1]root@solaris:~#
Configurez le noeud secondaire. Suivez la procédure décrite à la Configuration d'un serveur de métadonnées QFS potentiel sur les noeuds restants du cluster SC-RAC
Configurez le basculement. Suivez la procédure décrite à la Configuration du basculement des serveurs de métadonnées SC-RAC Revenez ensuite ici.
Vous avez défini une configuration SC-RAC à l'aide de volumes en miroir Solaris Volume Manager.
Si vous prévoyez d'utiliser la fonctionnalité de base de données sideband, reportez-vous au Configuration de la base de données de rapports.
Sinon, passez à la Configuration des notifications et de la journalisation.