Chapitre 1 Planification de la configuration Sun Cluster
Ce chapitre fournit des informations et des instructions de planification et d'installation d'une configuration Sun Cluster.
Les informations présentées dans ce chapitre sont les suivantes :
Tâches d'installation de Sun Cluster
Le tableau suivant indique l'emplacement des instructions pour diverses tâches d'installation de Sun Cluster et l'ordre dans lequel vous devez procéder.
Tableau 1–1 Informations relatives aux tâches d'installation du logiciel Sun Cluster|
Tâche |
Instructions |
|---|---|
|
Installation matérielle du cluster |
Sun Cluster 3.0-3.1 Hardware Administration Manual for Solaris OS Documentation fournie avec votre serveur et vos périphériques de stockage |
|
Planification de l'installation du logiciel de cluster | |
|
Installation des packages (Facultatif) Installation et configuration de Sun StorEdge QFS. |
Sun StorEdge QFS and Sun StorEdge SAM-FS Software Installation and Configuration Guide |
|
Établissement d'un cluster ou d'un nœud | |
|
Installation et configuration du logiciel Solstice DiskSuiteTM ou Solaris Volume Manager. |
Installation et configuration du logiciel Solstice DiskSuite ou Solaris Volume Manager Documentation de Solstice DiskSuite ou Solaris Volume Manager |
|
SPARC : Installation et configuration du logiciel VERITAS Volume Manager (VxVM). |
SPARC : Installation et configuration du logiciel VxVM Documentation de VxVM |
|
Configuration des systèmes de fichiers et d'autres composants du cluster | |
|
(Facultatif) SPARC : : installation et configuration du module Sun Cluster dans Sun Management Center. |
SPARC : installation du module Sun Cluster pour Sun Management Center Documentation de Sun Management Center |
|
Planification, installation et configuration des services de données et des groupes de ressources |
Sun Cluster Data Services Planning and Administration Guide for Solaris OS |
|
Développement de services de données personnalisés |
Guide du développeur de services de données Sun Cluster pour SE Solaris |
|
Mise à niveau vers le logiciel Sun Cluster 3.1 8/05 |
Chapitre 5, Mise à niveau du logiciel Sun Cluster Installation et configuration du logiciel Solstice DiskSuite ou Solaris Volume Manager ou SPARC : Installation et configuration du logiciel VxVM Documentation du gestionnaire de volumes |
Planification du SE Solaris
Cette rubrique explique comment planifier l'installation du logiciel Solaris dans une configuration de cluster. Pour obtenir plus d'informations sur le logiciel Solaris, reportez-vous à la documentation d'installation de Solaris.
Choix de la méthode d'installation de Solaris
Vous pouvez installer le logiciel Solaris à partir d'un lecteur de CD local ou d'un serveur d'installation réseau, par la méthode d'installation JumpStartTM. En outre, le logiciel Sun Cluster offre un procédé d'installation personnalisé permettant d'installer à la fois le système d'exploitation Solaris et le logiciel Sun Cluster à l'aide de la méthode d'installation JumpStart. Si vous installez plusieurs nœuds de cluster, nous vous recommandons une installation en réseau.
Pour obtenir des informations sur la méthode d'installation JumpStart (scinstall), reportez-vous à la rubrique Installation de Solaris et du logiciel Sun Cluster (JumpStart) . Pour obtenir plus d'informations sur les méthodes d'installation standard de Solaris, reportez-vous à la documentation d'installation de Solaris.
Restrictions d'utilisation des fonctions du système d'exploitation Solaris
Dans une configuration Sun Cluster, les fonctions ci-dessous du système d'exploitation Solaris ne sont pas prises en charge :
-
Sun Cluster 3.1 8/05 ne prend pas en charge les zones non globales. Tous les logiciels Sun Cluster et ceux que gère le cluster doivent être installés exclusivement dans la zone globale du nœud. N'installez pas de logiciels liés au cluster dans les zones non globales. Par ailleurs, tous les logiciels liés au cluster doivent être installés d'une manière qui empêche leur propagation vers les futures zones non globales des nœuds. Pour obtenir plus d'informations, reportez-vous à la rubrique Adding a Package to the Global Zone Only du System Administration Guide: Solaris Containers-Resource Management and Solaris Zones.
-
Sun Cluster ne prend pas en charge les groupes d'interfaces Solaris. La fonction de groupes d'interfaces de Solaris est désactivée par défaut pendant l'installation de ce logiciel, ne la réactivez pas. Pour obtenir plus d'informations sur les groupes d'interfaces Solaris, reportez-vous à la page de manuel ifconfig(1M).
-
L'économie d'énergie automatique n'est pas prise en charge par Sun Cluster. Elle ne doit pas être activée. Pour obtenir plus d'informations, reportez-vous aux pages de manuel pmconfig(1M) et power.conf(4).
-
Sun Cluster ne prend pas en charge les étiquettes de disque EFI (Extensible Firmware Interface).
-
Sun Cluster ne prend pas en charge le filtre IP de Solaris. L'utilisation du mécanisme autopush(1M) du module STREAMS par le filtre IP de Solaris n'est pas compatible Sun Cluster.
À propos des groupes de logiciels Solaris
Le logiciel Sun Cluster 3.1 8/05 nécessite au moins le groupe de logiciels de support système utilisateur final Solaris. Il est possible que d'autres composants de la configuration de votre cluster requièrent leurs propres logiciels Solaris. Prenez connaissance des informations présentées ci-dessous pour identifier le groupe de logiciels Solaris à installer.
-
Reportez-vous à la documentation de votre serveur pour connaître la configuration minimale requise par Solaris. Par exemple, les serveurs Sun EnterpriseTM 10000 nécessitent l'intégralité du groupe de logiciels Solaris Plus la prise en charge OEM.
-
Si vous envisagez d'utiliser les adaptateurs SCI-PCI (uniquement disponibles pour des clusters basés sur SPARC) ou Interface de programmation d'application de mémoire partagée distante (RSMAPI), veillez à installer les packages RSMAPI (SUNWrsm, SUNWrsmo, SUNWrsmx et SUNWrsmox pour Solaris 8 ou Solaris 9). Les packages RSMAPI sont inclus uniquement dans certains groupes de logiciels Solaris. Par exemple, les packages RSMAPI sont inclus dans le groupe de logiciels développeur de Solaris, mais pas dans le groupe de logiciels utilisateur final.
Si le groupe de logiciels que vous installez n'inclut pas les packages RSMAPI, installez-les manuellement avant Sun Cluster Utilisez la commande pkgadd(1M) pour installer manuellement les packages. Pour obtenir plus d'informations sur l'utilisation de RSMAPI, reportez-vous à la section Solaris 8 (3RSM) des pages de manuel.
-
Vous aurez peut-être besoin d'installer d'autres packages Solaris non inclus dans le groupe de logiciels utilisateur final de Solaris, par exemple les packages du serveur HTTP Apache. Les logiciels d'autres éditeurs, par exemple ORACLE®, peuvent aussi nécessiter des packages de logiciels Solaris supplémentaires. Reportez-vous à la documentation du fournisseur tiers pour connaître la configuration logicielle nécessaire de Solaris.
Astuce –
pour éviter d'avoir à installer manuellement les packages Solaris, installez la prise en charge Entire Solaris Software Group Plus OEM.
Partitions du disque système
Ajoutez ces informations à la Fiche de travail de configuration des systèmes de fichiers locaux appropriée.
Lors de l'installation du système d'exploitation Solaris, veillez à créer les partitions Sun Cluster requises et assurez-vous que toutes les partitions répondent aux conditions requises en termes d'espace minimum.
-
swap : l'espace swap total alloué à Solaris et au logiciel Sun Cluster ne doit pas être inférieur à 750 Mo. Pour obtenir des résultats optimaux, ajoutez au moins 512 Mo pour le logiciel Sun Cluster à l'espace requis par le système d'exploitation Solaris. En outre, vous devez allouer tout espace de swap supplémentaire requis par les applications qui seront exécutées sur le nœud du cluster.
Remarque –si vous envisagez de créer un fichier swap supplémentaire, ne le faites pas sur un périphérique global. Utilisez un disque local comme périphérique swap pour le nœud.
-
/globaldevices : créez un système de fichiers 512 Mo, que l'utilitaire scinstall(1M) pourra utiliser pour les périphériques globaux.
-
Gestionnaire de volumes : créez, sur une tranche en fin de disque (tranche 7), une partition de 20 Mo destinée au gestionnaire de volumes. Si votre cluster utilise VERITAS Volume Manager (VxVM;) et que vous prévoyez d'encapsuler le disque racine, vous avez besoin de deux tranches inutilisées pour VxVM.
Pour répondre à ces exigences, vous devez personnaliser le partitionnement si vous effectuez une installation interactive du SE Solaris.
Reportez-vous aux instructions suivantes pour de plus amples informations sur la planification des partitions.
Recommandations relatives au système de fichiers root (/)
Comme avec tout autre système exécutant le système d'exploitation Solaris, vous pouvez configurer les répertoires racine (/), /var, /usr et /opt en tant que systèmes de fichiers séparés ou inclure tous les répertoires dans le système de fichiers racine (/). Vous trouverez ci-dessous une description du contenu logiciel des répertoires racine (/), /var, /usr et /opt dans une configuration Sun Cluster. Tenez compte de ces informations lorsque vous planifiez votre projet de partitionnement.
-
racine (/) : le logiciel Sun Cluster occupe lui-même moins de 40 Mo d'espace dans le système de fichiers racine (/). Le logiciel Solstice DiskSuite ou Solaris Volume Manager requiert moins de 5 Mo et le logiciel VxVM moins de 15 Mo. Pour bénéficier de plus d'espace et de capacité de l'inode, ajoutez au moins 100 Mo à la quantité généralement attribuée au système de fichiers racine ( /). Cet espace est utilisé dans le cadre de la création de périphériques spéciaux en mode bloc et en mode caractère utilisés par le logiciel de gestion de volumes. Cet espace supplémentaire est particulièrement nécessaire si un nombre important de disques partagés se trouve dans le cluster.
-
/var : le logiciel Sun Cluster occupe un espace négligeable dans le système de fichiers /var au moment de l'installation. Cependant, vous devez réserver un espace important pour les fichiers journaux. Notez également que le nombre de messages consignés sur un nœud de cluster peut être plus important que sur un serveur autonome classique. Allouez donc au moins 100 Mo au système de fichiers /var.
-
/usr : le logiciel Sun Cluster occupe moins de 25 Mo d'espace dans le système de fichiers /usr. Les logiciels Solstice DiskSuite ou Solaris Volume Manager et VxVM requièrent chacun moins de 15 Mo.
-
/opt: le logiciel de structure Sun Cluster utilise moins de 2 Mo dans le système de fichiers /opt. Toutefois, chaque service de données de Sun Cluster peut utiliser entre 1 et 5 Mo. Le logiciel Solstice DiskSuite ou Solaris Volume Manager n'occupe aucun espace dans le système de fichiers /opt. Le logiciel VxVM peut utiliser plus de 40 Mo si vous installez tous ses packages et outils.
En outre, la plupart des logiciels de bases de données et d'applications sont installés dans le système de fichiers /opt.
Si vous utilisez le logiciel Sun Management Center pour surveiller le cluster, vous avez besoin de 25 Mo supplémentaires sur chaque nœud pour la prise en charge de l'agent Sun Management Center et des packages de modules Sun Cluster.
Recommandations relatives au système de fichiers /globaldevices
Le logiciel Sun Cluster exige que vous réserviez un système de fichiers particulier sur l'un des disques locaux pour la gestion des périphériques globaux. Ce système de fichiers est monté plus tard comme un système de fichiers de cluster. Pour ce système de fichiers, utilisez le nom par défaut reconnu par la commande scinstall(1M) : /globaldevices.
Par la suite, la commande scinstall renomme le système de fichiers en /global/.devices/node@id_nœud, où id_nœud représente le numéro assigné à un nœud lorsque celui-ci devient un élément du cluster. Le point initial de montage, /globaldevices, est supprimé.
Le système de fichiers /globaldevices doit disposer d'un espace et d'une capacité d'inode suffisants pour créer les périphériques spéciaux en mode bloc et les dispositifs de caractères spéciaux. Cette instruction est particulièrement importante si le cluster comprend un grand nombre de disques. Un système de fichiers de 512 Mo doit suffire à la plupart des configurations de cluster.
Exigences du gestionnaire de volumes
Si vous utilisez le logiciel Solstice DiskSuite ou Solaris Volume Manager, vous devez réserver une tranche sur le disque racine pour la création de la réplique de la base de données d'état. Notez que cela concerne chacun des disques locaux. Cependant, si un nœud ne comporte qu'un seul disque local, vous devrez peut-être créer trois répliques de la base de données d'état dans la même tranche pour que le logiciel Solstice DiskSuite ou Solaris Volume Manager fonctionne correctement. Pour de plus amples informations, reportez-vous à la documentation de Solstice DiskSuite ou Solaris Volume Manager.
SPARC : si vous utilisez VERITAS Volume Manager (VxVM) et que vous envisagiez d'encapsuler le disque racine, deux tranches inutilisées devront être consacrées à VxVM. En outre, vous aurez besoin d'un espace libre supplémentaire non assigné soit au début, soit à la fin du disque. Pour de plus amples informations sur l'encapsulation du disque racine, reportez-vous à la documentation VxVM.
Exemples d'allocation de système de fichiers
Le Tableau 1–2 présente un schéma de partitionnement pour un nœud de cluster occupant moins de 750 Mo de mémoire physique. Ce schéma doit être installé avec le groupe de logiciels d'utilisateur final Solaris, le logiciel Sun Cluster et le service de données Sun Cluster HA pour NFS. La dernière tranche du disque, la tranche 7, se voit allouer un petit espace destiné au gestionnaire de volumes.
Cette répartition permet d'utiliser Solstice DiskSuite ou Solaris Volume Manager ou VxVM. Si vous utilisez Solstice DiskSuite ou Solaris Volume Manager, vous pouvez réserver la tranche 7 pour la réplique de la base de données d'état. Si vous utilisez VxVM, vous pourrez libérer la tranche 7 ultérieurement en lui affectant une longueur nulle. Cette disposition fournit les deux tranches libres nécessaires (tranches 4 et 7) ainsi qu'un espace disque inutilisé à la fin du disque.
Tableau 1–2 Exemples d'allocations de systèmes de fichiers|
Tranche |
Contenu |
Taille allouée |
Description |
|---|---|---|---|
|
0 |
/ |
6,75 Go |
Espace libre restant sur le disque après l'allocation d'espace aux tranches 1 à 7. Utilisé pour le système d’exploitation Solaris, le logiciel Sun Cluster, le logiciel de services de données, le gestionnaire de volumes, l'agent Sun Management Center et les packages de l'agent du module Sun Cluster, les systèmes de fichiers root et les logiciels de bases de données et d’applications. |
|
1 |
swap |
1 Go |
512 Mo pour le système d'exploitation Solaris. 512 Mo pour le logiciel Sun Cluster. |
|
2 |
chevauchement |
8,43 Go |
Totalité du disque. |
|
3 |
/globaldevices |
512 Mo |
Le logiciel Sun Cluster affectera ultérieurement un autre point de montage à cette tranche et la montera en tant que système de fichiers de cluster. |
|
4 |
inutilisé |
- |
Tranche libre disponible pour l'encapsulation du disque racine sous VxVM. |
|
5 |
inutilisé |
- |
- |
|
6 |
inutilisé |
- |
- |
|
7 |
gestionnaire de volumes |
20 Mo |
Utilisé par le logiciel Solstice DiskSuite ou Solaris Volume Manager pour la réplique de la base de données d'état ou par VxVM pour l'installation après la libération de la tranche. |
Planification de l'environnement Sun Cluster
Cette rubrique indique comment planifier et préparer les composants ci-dessous pour l'installation et la configuration du logiciel Sun Cluster.
Pour obtenir plus d'informations sur les composants Sun Cluster, reportez-vous aux documents Présentation de Sun Cluster pour SE Solaris et Guide des notions fondamentales de Sun Cluster pour SE Solaris.
Gestion des licences
Avant de commencer l'installation du logiciel, assurez-vous de posséder les certificats de licence nécessaires. Le logiciel Sun Cluster ne nécessite pas de certificat de licence, mais chaque nœud sur lequel il est installé doit être couvert par votre contrat de licence pour le logiciel Sun Cluster.
Pour connaître les licences requises par le gestionnaire de volumes et les applications, reportez-vous aux documents d'installation de ces produits.
Patchs des logiciels
Après avoir installé chacun des logiciels, vous devez également installer les patchs éventuellement requis.
-
Pour obtenir des informations sur les patchs actuellement requis, reportez-vous à la rubrique Patchs et niveaux de microprogrammes requis du Notes de version de Sun Cluster 3.1 8/05 pour SE Solaris ou contactez votre prestataire de services Sun.
-
Pour connaître les procédures générales d'application des patchs, reportez-vous au Chapitre 8, Patchs pour logiciel et microprogramme Sun Cluster du Guide d’administration système de Sun Cluster pour SE Solaris.
Adresses IP
Vous devez définir un certain nombre d'adresses IP pour divers composants de Sun Cluster en fonction de la configuration de votre cluster. Chaque nœud de votre configuration de cluster doit avoir au moins une connexion de réseau public vers le même ensemble de sous-réseaux publics.
Le tableau ci-dessous répertorie les composants qui nécessitent des adresses IP. Ajoutez ces adresses IP aux emplacements suivants :
-
tout service d'attribution de noms utilisé ;
-
le fichier /etc/inet/hosts local de chaque nœud de cluster après l'installation de Solaris ;
-
le fichier /etc/inet/iphosts local de chaque nœud de cluster après l'installation de Solaris 10.
Pour obtenir plus d'informations sur la planification d'adresses IP, reportez-vous au document System Administration Guide, Volume 3 (Solaris 8) ou au document System Administration Guide: IP Services (Solaris 9 ou Solaris 10).
Pour obtenir plus d'informations sur les adresses IP de test liées à la prise en charge de Multiacheminement sur réseau IP, reportez-vous au document IP Network Multipathing Administration Guide.
Périphériques d'accès par console
Vous devez disposer d'un accès par console à l'ensemble des nœuds de cluster. Si vous installez le logiciel Cluster Control Panel sur votre console administrative, vous devez indiquer le nom d'hôte du périphérique d'accès par console employé pour communiquer avec les nœuds du cluster.
-
Un concentrateur de terminal est utilisé pour établir la communication entre la console administrative et les consoles de nœuds du cluster.
-
Un serveur Sun Enterprise 10000 utilise un processeur SSP (System Service Processor) au lieu d'un concentrateur de terminal.
-
Un serveur Sun FireTM utilise un contrôleur de système au lieu d'un concentrateur de terminal.
Pour obtenir plus d'informations sur l'accès par console, reportez-vous au document Guide des notions fondamentales de Sun Cluster pour SE Solaris.
Adresses logiques
Lors de la planification d'adresses logiques, tenez compte des points suivants :
-
Chaque groupe de ressources de service de données qui utilise une adresse logique doit avoir un nom d'hôte spécifié pour chaque réseau public à partir duquel l'adresse logique est accessible.
-
L'adresse IP doit se trouver sur le sous-réseau de l'adresse IP de test utilisée par le groupe Multiacheminement sur réseau IP contenant l'adresse logique.
Pour obtenir plus d'informations, reportez-vous au document Sun Cluster Data Services Planning and Administration Guide for Solaris OS. Pour obtenir plus d'informations sur les services de données et les ressources, reportez-vous aux documents Présentation de Sun Cluster pour SE Solaris et Guide des notions fondamentales de Sun Cluster pour SE Solaris.
Réseaux publics
Les réseaux publics communiquent hors du cluster. Tenez compte des points suivants lorsque vous planifiez votre configuration de réseau public.
-
Les réseaux publics et le réseau privé (interconnexion de cluster) doivent utiliser des adaptateurs distincts, ou un VLAN en mode marqué doit être configuré sur des adaptateurs et des commutateurs compatibles de manière à utiliser le même adaptateur pour l'interconnexion privée et le réseau public.
-
Vous devez avoir au moins un réseau public connecté à tous les nœuds de cluster.
-
La configuration matérielle détermine le nombre maximal de connexions supplémentaires au réseau public.
-
Sun Cluster prend en charge les adresses IPv4 du réseau public.
-
Sun Cluster prend en charge les adresses IPv6 du réseau public, à certaines conditions :
-
Sun Cluster ne prend pas en charge les adresses IPv6 du réseau public si l'interconnexion privée utilise des adaptateurs SCI.
-
Sous Solaris 9 ou Solaris 10, Sun Cluster prend en charge les adresses IPv6 pour les services de données évolutifs et ceux de basculement.
-
Sous Solaris 8, Sun Cluster prend en charge les adresses IPv6 pour les services de données de basculement uniquement.
-
-
Chaque adaptateur de réseau public doit appartenir à un groupe multi-acheminement sur réseau IP (Multiacheminement sur réseau IP). Pour obtenir plus d'informations, reportez-vous à la rubrique Groupes Multiacheminement sur réseau IP .
-
Tous les adaptateurs de réseau public doivent utiliser des cartes d'interface réseau prenant en charge l'affectation d'adresse MAC locale. L'affectation d'adresse MAC locale est une exigence de Multiacheminement sur réseau IP.
-
La variable local-mac-address? doit utiliser la valeur par défaut, true, pour les adaptateurs Ethernet. Le logiciel Sun Cluster ne prend pas en charge la valeur local-mac-address? false pour les adaptateurs Ethernet. Cette exigence est une modification apportée par rapport à Sun Cluster 3.0, qui nécessitait la variable local-mac-address? false.
-
Lors de l'installation de Sun Cluster sous Solaris 9 ou Solaris 10, l'utilitaire scinstall configure automatiquement un groupe Multiacheminement sur réseau IP à un seul adaptateur pour chaque adaptateur de réseau public. Pour modifier ces groupes de sauvegarde après l'installation, suivez les procédures du chapitre Administering IPMP (Tasks) du System Administration Guide: IP Services (Solaris 9 ou Solaris 10).
-
Sun Cluster ne prend pas en charge le filtre IP de Solaris.
Pour obtenir plus d'informations sur la planification des groupes de sauvegarde d'adaptateur de réseau public, reportez-vous à la rubrique Groupes Multiacheminement sur réseau IP . Pour obtenir plus d'informations sur les interfaces de réseau public, reportez-vous au document Guide des notions fondamentales de Sun Cluster pour SE Solaris.
Groupes Multiacheminement sur réseau IP
Ajoutez ces informations de planification à Fiche de travail relative aux réseaux publics.
Les groupes Multiacheminement sur réseau IP, qui remplacent les groupes NAFO (Network Adapter Failover, reprise sur panne de l'adaptateur réseau), assurent le contrôle et le basculement des adaptateurs de réseau public et constituent la base des ressources d'adresse réseau. Un groupe IPMP offre une haute disponibilité quand il est configuré avec au moins deux adaptateurs. Si un adaptateur échoue, toutes les adresses de l'adaptateur concerné vont vers un autre adaptateur du groupe IPMP. De cette façon, les adaptateurs du groupe IPMP préservent la connectivité du réseau public au sous-réseau auquel ils sont connectés.
Dans quels cas est-il nécessaire de configurer manuellement les groupes Multiacheminement sur réseau IP lors d'une installation Sun Cluster ?
-
Pour les installations Sun Cluster sous Solaris 8, vous devez configurer manuellement tous les adaptateurs de réseau public des groupes Multiacheminement sur réseau IP avec des adresses IP de test.
-
Si vous utilisez le programme d'installation SunPlex pour installer Sun Cluster sous Solaris 9 ou Solaris 10, certains adaptateurs de réseau public pourront demander une configuration manuelle des groupes Multiacheminement sur réseau IP.
Pour les installations Sun Cluster sous Solaris 9 ou Solaris 10, l'utilitaire scinstall associe automatiquement tous les adaptateurs de réseau public à des groupes Multiacheminement sur réseau IP à un seul adaptateur (sauf en cas d'utilisation du programme d'installation SunPlex).
Lors de la planification de vos groupes IPMP, tenez compte des points suivants.
-
Chaque adaptateur de réseau public doit appartenir à un groupe de multi-acheminement.
-
Dans les types de groupe de multiacheminement suivants, vous devez configurer une adresse IP de test pour chaque adaptateur du groupe :
-
Sous Solaris 8, chacun des adaptateurs de chacun des groupes de multiacheminement nécessite une adresse IP de test.
-
Sous Solaris 9 ou Solaris 10, seuls les groupes de multiacheminement comprenant deux adaptateurs ou plus nécessitent des adresses IP de test. Si un groupe de multi-acheminement contient un seul adaptateur, vous n'avez pas besoin de configurer une adresse IP de test.
-
-
Les adresses IP de test de tous les adaptateurs du même groupe de multiacheminement doivent appartenir au même sous-réseau IP.
-
Les adresses IP de test ne doivent pas être utilisées par des applications normales car elles ne sont pas hautement disponibles.
-
Dans le fichier /etc/default/mpathd, la valeur de TRACK_INTERFACES_ONLY_WITH_GROUPS doit être yes.
-
Le nom d'un groupe de multiacheminement ne fait l'objet d'aucune exigence ni restriction.
La plupart des procédures, instructions et restrictions présentées dans la documentation Solaris pour Multiacheminement sur réseau IP s'appliquent à la fois aux environnements de cluster et sans cluster. Pour plus d'informations sur Multiacheminement sur réseau IP, vous pouvez donc vous reporter au document Solaris approprié :
-
Pour Solaris 8, reportez-vous à la rubrique consacrée au déploiement IPMP du document IP Network Multipathing Administration Guide.
-
Pour Solaris 9, reportez-vous au Chapitre 28, Administering Network Multipathing (Task) du System Administration Guide: IP Services.
-
Pour Solaris 10, reportez-vous au Chapitre 31, Administering IPMP (Tasks) du System Administration Guide: IP Services.
Reportez-vous également à la rubrique Groupes de multiacheminement sur réseau IP du Présentation de Sun Cluster pour SE Solaris et au Guide des notions fondamentales de Sun Cluster pour SE Solaris.
Instructions relatives à l'utilisation du système NFS
Lorsque vous envisagez d'utiliser le système NFS (Network File System) dans un environnement Sun Cluster, vous devez tenir compte des points suivants :
-
Aucun nœud Sun Cluster ne peut être client NFS d'un système de fichiers exporté par Sun Cluster HA pour NFS et dont le maître soit un nœud du même cluster. Un tel montage croisé Sun Cluster HA pour NFS est interdit. Utilisez le système de fichiers du cluster pour répartir les fichiers entre les nœuds.
-
Les applications exécutées localement sur le cluster ne doivent pas verrouiller les fichiers sur un système de fichiers exporté via NFS. Si vous ne suivez pas cette recommandation, le blocage local (par exemple, flock(3UCB) ou fcntl(2)) risque d'entraver le redémarrage du gestionnaire de verrouillage (lockd(1M)). Lors du redémarrage, il est possible qu'un processus local bloqué soit verrouillé et que seul un client distant puisse le déverrouiller. Le comportement qui s'ensuit est imprévisible.
-
Sun Cluster ne prend pas en charge les options suivantes de la commande share_nfs(1M) :
-
secure
-
sec=dh
Toutefois, Sun Cluster prend en charge les fonctions de sécurité suivantes pour NFS :
-
L'utilisation de ports sécurisés pour NFS. Pour activer les ports sécurisés pour NFS, ajoutez le paramètre d'entrée nfssrv:nfs_portmon=1 dans le fichier /etc/system des nœuds de cluster.
-
L'utilisation de Kerberos avec NFS. Pour obtenir plus d'informations, reportez-vous à la rubrique Securing Sun Cluster HA for NFS With Kerberos V5 du Sun Cluster Data Service for NFS Guide for Solaris OS.
-
Restrictions de service
Veillez à respecter les restrictions de service suivantes dans les environnements Sun Cluster :
-
Ne configurez pas les nœuds du cluster en tant que routeurs (passerelles). Si le système est immobilisé, les clients ne pourront pas trouver de routeur alternatif et, de ce fait, effectuer une reprise.
-
Ne configurez pas les nœuds de cluster en tant que serveurs NIS ou NIS+. Il n'existe aucun service de données disponible pour NIS ou NIS+. Ils peuvent toutefois être des clients NIS ou NIS+.
-
N'utilisez pas de configuration Sun Cluster pour doter les systèmes client d'un service d'initialisation ou d'installation à haute disponibilité.
-
N'utilisez pas une configuration Sun Cluster pour fournir un service rarpd.
-
Si vous installez un service RPC sur le cluster, ce service ne doit utiliser aucun des numéros de programme suivants :
-
100141
-
100142
-
100248
Ces numéros sont réservés respectivement aux démons Sun Cluster rgmd_receptionist , fed et pmfd.
Si le service RPC installé utilise l'un de ces numéros, vous devez lui en attribuer un autre.
-
-
Sun Cluster ne prend pas en charge l'exécution des classes de programmation de processus à priorité élevée sur les nœuds du cluster. N'exécutez aucun des types de processus suivants sur les nœuds du cluster :
-
processus s'exécutant dans la classe de programmation en temps partagé avec une priorité élevée ;
-
processus s'exécutant dans la classe de programmation en temps réel.
Le logiciel Sun Cluster s'appuie sur des threads du noyau ne s'exécutant pas dans la classe en temps réel. Des processus en temps partagé s'exécutant avec une priorité supérieure à la normale ou des processus en temps réel peuvent empêcher les threads du noyau de Sun Cluster d'acquérir les cycles processeur requis.
-
Composants configurables de Sun Cluster
Cette rubrique fournit des instructions pour les composants de Sun Cluster suivants que vous configurez.
Ajoutez ces informations à la fiche de configuration appropriée.
Nom du cluster
Nommez le cluster au cours de la configuration de Sun Cluster. Ce nom doit être unique dans toute l'entreprise.
Noms des nœuds
Le nom de nœud est celui que vous affectez à une machine lorsque vous installez le système d'exploitation Solaris. Pendant la configuration de Sun Cluster, indiquez le nom de tous les nœuds que vous installez en tant que nœuds de cluster. Dans les installations de cluster mononœud, le nom par défaut du cluster est celui du nœud.
Réseau privé
Remarque –
pour les clusters mononœuds, il est inutile de configurer un réseau privé.
Le logiciel Sun Cluster utilise le réseau privé pour assurer les communications internes entre les nœuds. Chaque configuration Sun Cluster nécessite au moins deux connexions pour procéder à l'interconnexion du cluster sur le réseau privé. Vous indiquez l'adresse de réseau privé et le masque de réseau lorsque vous configurez le logiciel Sun Cluster sur le premier nœud du cluster. Vous pouvez soit accepter l'adresse de réseau privé par défaut (172.16.0.0) et le masque de réseau (255.255.0.0), soit indiquer d'autres choix.
Remarque –
Une fois l'exécution de l'utilitaire d'installation (scinstall, le programme d'installation SunPlex ou JumpStart) terminée et le cluster établi, vous ne pouvez plus modifier ni l'adresse, ni le masque. Vous devrez désinstaller et réinstaller le logiciel de cluster pour pouvoir utiliser une adresse de réseau privé ou un masque de réseau différent.
Si vous indiquez une adresse de réseau privé différente de l'adresse par défaut, elle doit répondre aux exigences suivantes :
-
Elle doit se terminer par deux zéros, comme l'adresse par défaut 172.16.0.0. Le logiciel Sun Cluster requiert les 16 derniers bits de l'espace de l'adresse pour son usage personnel.
-
L'adresse doit figurer dans le bloc d'adresses dont l'utilisation est réservée par la demande de commentaires RFC 1918 dans les réseaux privés. Vous pouvez contacter le centre InterNIC pour obtenir des RFC ou les afficher en ligne à partir de l'adresse http://www.rfcs.org.
-
Vous pouvez utiliser la même adresse de réseau privé dans plusieurs cluster. Les adresses de réseaux IP privés ne sont pas accessibles de l'extérieur du cluster.
-
Sun Cluster ne prend pas en charge les adresses IPv6 pour l'interconnexion privée. Le système configure les adresses IPv6 sur les adaptateurs de réseau privé pour prendre en charge les services évolutifs utilisant les adresses IPv6. Toutefois, la communication entre les nœuds du réseau privé n'utilise pas ces adresses IPv6.
Même si l'utilitaire scinstall permet d'indiquer un autre masque de réseau, il est recommandé d'accepter le masque de réseau par défaut (255.255.0.0). En effet, il n'y a aucun avantage à indiquer un masque de réseau représentant un réseau plus grand et l'utilitaire scinstall n'accepte pas de masque représentant un réseau plus petit.
Pour obtenir plus d'informations sur les réseaux privés, reportez-vous à la rubrique Planning Your TCP/IP Network du document System Administration Guide, Volume 3 (Solaris 8) ou à la rubrique Planning Your TCP/IP Network (Tasks) du document System Administration Guide: IP Services (Solaris 9 ou Solaris 10) .
Noms d'hôtes privés
Le nom d'hôte privé est le nom utilisé pour la communication entre les nœuds sur l'interface de réseau privé. Ces noms sont créés automatiquement lors de la configuration de Sun Cluster. Il sont conformes à la convention d'attribution de nom clusternodenodeid -priv (nodeid représente le numéro de l'ID du nœud interne). Lors de la configuration de Sun Cluster, ce numéro d'ID est affecté automatiquement à chaque nœud dès lors qu'il devient élément du cluster. Après la configuration du cluster, vous pouvez modifier les noms d'hôtes privés à l'aide de l'utilitaire scsetup(1M).
Interconnexion de cluster
Remarque –
pour les clusters mononœuds, il est inutile de configurer une interconnexion de cluster. Cependant, si vous prévoyez d'ajouter des nœuds à une configuration de cluster mononœud, vous souhaiterez probablement configurer l'interconnexion de cluster pour une utilisation future.
Les interconnexions de cluster fournissent les voies matérielles pour la communication en réseau privé entre les nœuds du cluster. Chaque interconnexion consiste en un câble connecté de l'une des manières suivantes :
-
entre deux adaptateurs de transport ;
-
entre un adaptateur de transport et une jonction de transport ;
-
entre deux jonctions de transport.
Lors de la configuration de Sun Cluster, vous fournissez des informations de configuration pour deux interconnexions de cluster. Vous pourrez configurer d'autres connexions de réseau privé après avoir établi le cluster à l'aide de l'utilitaire scsetup(1M).
Pour obtenir plus d'informations sur les périphériques d'interconnexion de cluster, reportez-vous à la rubrique Interconnect Requirements and Restrictions du Sun Cluster 3.0-3.1 Hardware Administration Manual for Solaris OS. Pour obtenir des informations générales sur l'interconnexion de cluster, reportez-vous à la rubrique Interconnexion de cluster du Présentation de Sun Cluster pour SE Solaris et au Guide des notions fondamentales de Sun Cluster pour SE Solaris.
Adaptateurs de transport
Pour les adaptateurs de transport, tels que les ports sur les interfaces réseau, indiquez le nom des adaptateurs et le type de transport. Si votre configuration repose sur un cluster à deux nœuds, vous devez également indiquer si l'interconnexion fait l'objet d'une liaison directe (adaptateur à adaptateur) ou si elle utilise une jonction de transport.
Tenez compte des instructions et restrictions suivantes :
-
IPv6 : Sun Cluster ne prend pas en charge les communications IPv6 sur les interconnexions privées.
-
Affectation d'adresse MAC locale : tous les adaptateurs de réseau privé doivent utiliser des cartes d'interface réseau prenant en charge l'affectation d'adresse MAC locale. Les adresses IPv6 à portée locale, requises sur les adaptateurs de réseau privé pour prendre en charge les adresses IPv6 de réseau public, sont dérivées des adresses MAC locales.
-
Adaptateurs VLAN en mode marqué : Sun Cluster prend en charge les réseaux locaux virtuels (VLAN) pour partager un adaptateur entre l'interconnexion privée et le réseau public. Lorsque vous configurez un adaptateur VLAN en mode marqué pour l'interconnexion privée, indiquez le nom de l'adaptateur et son ID VLAN (VID) de l'une des manières suivantes :
-
Indiquez le nom usuel de l'adaptateur, c'est-à-dire le nom du périphérique, suivi du numéro de l'instance ou du point physique de connexion. Par exemple, le nom de l'instance 2 d'un adaptateur Gigabit Ethernet de Cassini serait ce2. Si l'utilitaire scinstall vous demande si l'adaptateur appartient à un réseau local virtuel partagé, répondez yes et indiquez le numéro VID.
-
Indiquez l'adaptateur par son nom de périphérique VLAN. Ce nom se compose du nom de l'adaptateur et du numéro de l'instance VLAN. Le numéro de l'instance VLAN est obtenu par la formule (1000*V)+N (V étant le numéro VID et N, le point physique de connexion).
Par exemple, pour le VID 73 sur l'adaptateur ce2, vous calculez le numéro de l'instance VLAN par la formule (1000*73)+2. Vous devez donc désigner l'adaptateur par le nom ce73002 pour indiquer son appartenance à un réseau local virtuel partagé.
Pour obtenir plus d'informations sur les réseaux locaux virtuels, reportez-vous à la rubrique Configuring VLANs du document Solaris 9 9/04 Sun Hardware Platform Guide.
-
-
Adaptateurs SCI SBus : l'interface SCI (Scalable Coherent Interface) SBus n'est pas prise en charge dans le cadre d'une interconnexion de cluster. En revanche, l'interface SCI–PCI l'est.
-
Interfaces de réseau logique : les interfaces de réseau logique sont réservées à Sun Cluster.
Pour obtenir plus d'informations sur un adaptateur de transport en particulier, reportez-vous aux pagesde manuel scconf_trans_adap_*(1M).
Jonctions de transport
Si vous utilisez des jonctions de transport (par exemple, des commutateurs réseau), indiquez un nom de jonction de transport pour chaque interconnexion. Vous pouvez utiliser le nom par défaut switchN, où N est un numéro affecté automatiquement à la configuration, ou créer un autre nom. Il existe une exception à cette règle : l'adaptateur Sun Fire Link nécessite le nom de jonction sw-rsm N. L'utilitaire scinstall utilise automatiquement ce nom de jonction lorsque vous indiquez qu'il s'agit d'un adaptateur Sun Fire Link (wrsmN).
Indiquez également le nom du port de la jonction ou acceptez le nom par défaut. Le nom de port par défaut est identique à l'ID de nœud interne du nœud qui héberge l'extrémité adaptateur du câble. Cependant, vous ne pouvez pas utiliser le nom de port par défaut pour certains types d'adaptateurs, tels que SCI-PCI.
Remarque –
les clusters à trois nœuds ou plus doivent utiliser des jonctions de transport. La connexion directe entre les nœuds de cluster est possible uniquement pour les clusters à deux nœuds.
Si votre cluster à deux nœuds utilise une connexion directe, vous pouvez toujours spécifier une jonction de transport pour l'interconnexion.
Astuce –
si vous le faites, il sera plus facile d'ajouter un autre nœud au cluster à l'avenir.
Périphériques de quorum
Les configurations de Sun Cluster utilisent des périphériques de quorum pour préserver l'intégrité des données et des ressources. Si le cluster perd temporairement la connexion à un nœud, le périphérique de quorum évite les problèmes “d'amnésie” ou de dédoublement lorsque le nœud tente de rejoindre le cluster. Lors de l'installation d'un cluster à deux nœuds sous Sun Cluster, l'utilitaire scinstall configure automatiquement un périphérique de quorum. Le périphérique de quorum est choisi parmi les disques de stockage partagés et disponibles. L'utilitaire scinstall suppose que tous les disques de stockage partagés et disponibles peuvent être utilisés comme périphériques de quorum. Après l'installation, vous pouvez également configurer des périphériques de quorum supplémentaires à l'aide de l'utilitaire scsetup(1M).
Remarque –
vous n'avez pas besoin de configurer des périphériques de quorum pour un cluster à nœud unique.
Si votre configuration de cluster ne vous autorise pas à utiliser des périphériques partagés de stockage tierrs comme périphériques de quorum, vous devez exécuter l'utilitaire scsetup pour configurer manuellement le quorum.
Tenez compte des points suivants lorsque vous planifiez des périphériques de quorum.
-
Minimum: un cluster à deux nœuds doit avoir au moins un périphérique de quorum (disque partagé ou périphérique NAS Network Appliance). Pour les autres topologies, les périphériques de quorum sont facultatifs.
-
Règle du nombre impair : si plusieurs périphériques de quorum sont configurés dans un cluster à deux nœuds ou dans une paire de nœuds directement connectée au périphérique de quorum, vous devez vous assurer qu'ils sont en nombre impair. Cette configuration garantit que les périphériques de quorum ont des chemins défaillants complètement indépendants les uns des autres.
-
Connexion : vous devez connecter un périphérique de quorum à deux nœuds au moins.
Pour obtenir plus d'informations sur les périphériques de quorum, reportez-vous aux rubriques Quorum et périphériques de quorum du Guide des notions fondamentales de Sun Cluster pour SE Solaris et Périphériques de quorum du Présentation de Sun Cluster pour SE Solaris.
Planification des périphériques globaux et des systèmes de fichiers de cluster
Cette rubrique fournit les recommandations suivantes sur la planification des périphériques globaux et des systèmes de fichiers de cluster :
Pour obtenir plus d'informations sur les périphériques globaux et les systèmes de fichiers de cluster, reportez-vous aux documents Présentation de Sun Cluster pour SE Solaris et Guide des notions fondamentales de Sun Cluster pour SE Solaris.
Recommandations relatives aux systèmes de fichiers de cluster et aux périphériques globaux à haute disponibilité
Sun Cluster n'impose pas de contraintes particulières en matière de disposition des disques ou de taille des système de fichiers. Tenez compte des points suivants lors de la planification de votre présentation des périphériques globaux et des systèmes de fichiers de cluster :
-
Mise en miroir : vous devez mettre en miroir tous les périphériques globaux afin que le périphérique global soit considéré comme hautement disponible. Vous n'êtes pas tenu de procéder à une mise en miroir logicielle si le périphérique de stockage dispose de matériel RAID ainsi que de chemins d'accès aux disques redondants.
-
Disques : lorsque vous effectuez une mise en miroir, organisez les systèmes de fichiers de sorte qu'ils soient mis en miroir sur les baies de disques.
-
Disponibilité : vous devez connecter physiquement un périphérique global à plusieurs nœuds du cluster pour que ledit périphérique global soit considéré à haute disponibilité. Un périphérique global à plusieurs connexions physiques peut tolérer la défaillance d'un nœud unique. Vous pouvez configurer un périphérique global avec une seule connexion physique, mais il sera inaccessible depuis les autres nœuds en cas de panne du nœud avec la connexion.
-
Périphériques de swap : ne créez pas un fichier de swap sur un périphérique global.
Systèmes de fichiers de cluster
Lorsque vous planifiez les systèmes de fichiers de cluster, tenez compte des points suivants :
-
Quotas : les quotas ne sont pas pris en charge dans les systèmes de fichiers de cluster.
-
Système de fichiers loopback (LOFS) : n'utilisez pas le système de fichiers loopback (LOFS) si les deux conditions suivantes sont remplies :
-
Sun Cluster HA pour NFS est configuré sur un système de fichiers local à haute disponibilité.
-
Le démon automountd est en cours d'exécution.
Dans ce cas, il est nécessaire de désactiver le système LOFS pour éviter des problèmes de basculement ou d'autres incidents. Si une seule condition est remplie, l'activation du système LOFS ne pose pas de problème.
Si vous avez besoin d'activer le système LOFS et le démon automountd, excluez du schéma de montage tous les fichiers du système local hautement disponible exporté par Sun Cluster HA pour NFS.
-
-
Fichiers journaux de comptabilisation des processus : ne placez pas les fichiers journaux de comptabilisation des processus dans un système de fichiers de cluster ni dans un système de fichiers local à haute disponibilité. La journalisation empêcherait un basculement et provoquerait un blocage du nœud. Utilisez seulement un système de fichiers local pour contenir les fichiers journaux de comptabilisation des processus.
-
Points finaux de communication : le système de fichiers de cluster ne prend pas en charge les fonctions de Solaris qui permettent d'introduire un point final de communication dans l'espace de noms.
-
Bien que vous puissiez créer un socket de domaine UNIX portant le nom d'un chemin dans le système de fichiers de cluster, ce socket ne résistera pas à un basculement du nœud.
-
Tout FIFO ou canal nommé créé sur un système de fichiers de cluster est globalement inaccessible.
Par conséquent, évitez d'utiliser la commande fattach à partir de tout autre nœud que le nœud local.
-
Groupes de périphériques de disques
Ajoutez ces informations de planification à la Fiche de travail relative aux configurations des groupes de périphériques de disque.
Vous devez configurer tous les groupes de disques du gestionnaire de volumes en tant que groupes de périphériques de disques Sun Cluster. Cette configuration permet à des disques multihôtes d'être hébergés par un nœud secondaire en cas de panne du nœud principal. Tenez compte des points suivants lorsque vous planifiez des groupes de périphériques de disques.
-
Basculement : vous pouvez définir des disques multihôtes et des périphériques de gestionnaire de volumes correctement configurés comme périphériques de basculement. Pour qu'un périphérique du gestionnaire de volumes soit correctement configuré, il doit comporter des disques multihôtes et le gestionnaire de volumes doit lui-même être correctement configuré. Cette configuration garantit que les nœuds multiples peuvent héberger le périphérique exporté. Il est impossible de configurer des lecteurs de bandes, des lecteurs de CD-ROM ou des périphériques à un seul port comme périphériques de basculement.
-
Mise en miroir : vous devez mettre les disques en miroir pour protéger les données en cas de défaillance du disque. Pour obtenir plus d'informations, reportez-vous à la rubrique Recommandations relatives à la mise en miroir . Pour connaître la procédure de mise en miroir, reportez-vous à la rubrique Installation et configuration du logiciel Solstice DiskSuite ou Solaris Volume Manager ou SPARC : Installation et configuration du logiciel VxVM et à la documentation sur votre gestionnaire de volumes.
Pour obtenir plus d'informations sur les groupes de périphériques de disques, reportez-vous à la rubrique Périphériques du Présentation de Sun Cluster pour SE Solaris et au Guide des notions fondamentales de Sun Cluster pour SE Solaris.
Informations de montage pour les systèmes de fichiers de cluster
Tenez compte des points suivants lorsque vous planifiez des points de montage pour les systèmes de fichiers de cluster :
-
Emplacement de points de montage : créez les points de montage des systèmes de fichiers de cluster dans le répertoire /global, sauf si d'autres logiciels vous en empêchent. Ce répertoire vous permet de distinguer facilement les systèmes de fichiers de cluster globaux, des systèmes de fichiers locaux.
-
SPARC : exigence de montage VxFS. Si vous utilisez Système de fichiers VERITAS (VxFS), vous devez monter et démonter globalement les systèmes de fichiers VxFS depuis le nœud principal. Le nœud principal contrôle le disque sur lequel se trouve le système de fichiers VxFS. Cette méthode assure la réussite des opérations de montage et de démontage. Tout montage ou démontage d'un système de fichiers VxFS à partir d'un nœud secondaire risque d'échouer.
-
Les fonctions VxFS qui suivent ne sont pas prises en charge dans un système de fichier de cluster Sun Cluster version 3.1. Ces dernières sont cependant prises en charge dans un système de fichiers local.
-
E/S rapide ;
-
instantanés ;
-
points de contrôle du stockage ;
-
options de montage spécifiques au logiciel VxFS :
-
convosync (Convertir O_SYNC) ;
-
mincache ;
-
qlog, delaylog, tmplog ;
-
-
système de fichiers de cluster VERITAS (requiert la fonction de cluster VxVM et VERITAS Cluster Server).
Les avis de cache peuvent être utilisés, mais ils ne s'appliquent qu'au nœud sélectionné.
Toutes les autres fonctions et options VxFS prises en charge dans un système de fichier de cluster sont acceptées par le logiciel Sun Cluster version 3.1. Pour plus d'informations sur les options de VxFS prises en charge dans une configuration de cluster, voir la documentation correspondante.
-
-
Imbrication des points de montage : normalement, vous ne devez pas imbriquer les points de montage des systèmes de fichiers de cluster. Par exemple, ne définissez pas un système de fichiers monté sur /global/a et un autre système de fichiers monté sur /global/a/b. Si vous ne respectez pas cette règle, vous risquez de rencontrer des problèmes de disponibilité et d'ordre d'initialisation des nœuds. Ces problèmes peuvent survenir si le point de montage parent est absent au moment où le système tente de monter un fils de ce système de fichiers. La seule exception à cette règle s'applique lorsque les périphériques des deux systèmes de fichiers possèdent la même connectivité de nœud physique, par exemple, différentes tranches du même disque.
-
forcedirectio : Sun Cluster ne prend pas charge l'exécution de binaires en dehors de systèmes de fichiers de cluster montés à l'aide de l'option forcedirectio.
Planification de la gestion des volumes
Ajoutez ces informations de planification à la Fiche de travail relative aux configurations des groupes de périphériques de disque et à la Fiche de travail relative à la configuration du gestionnaire de volumes. Pour Solstice DiskSuite ou Solaris Volume Manager, ajoutez également ces informations de planification à la Fiche de travail relative aux métapériphériques (Solstice DiskSuite ou Solaris Volume Manager).
Cette rubrique donne les recommandations suivantes sur la planification de la gestion de volume de la configuration de votre cluster :
-
Recommandations relatives au logiciel de gestion des volumes
-
Recommandations relatives au logiciel Solstice DiskSuite ou Solaris Volume Manager
-
SPARC : Recommandations relatives au logiciel VERITAS Volume Manager
Sun Cluster utilise un logiciel de gestion des volumes pour grouper les disques par groupes de périphériques de disques pouvant être administrés comme une seule unité. Il prend en charge les logiciels Solstice DiskSuite ou Solaris Volume Manager et VERITAS Volume Manager (VxVM) que vous pouvez installer et utiliser des manières indiquées ci-dessous.
Tableau 1–4 Utilisation des gestionnaires de volumes avec Sun Cluster|
Gestionnaire de volumes |
Configuration requise |
|---|---|
|
Solstice DiskSuite ou Solaris Volume Manager |
Vous devez installer le logiciel Solstice DiskSuite ou Solaris Volume Manager sur tous les nœuds du cluster, que vous utilisiez ou non VxVM sur certains nœuds pour gérer les disques. |
|
Vous devez installer VxVM et obtenir la licence correspondante avec la fonction de cluster sur tous les nœuds du cluster. |
|
|
SPARC : VxVM sans la fonction de cluster |
Vous devez installer VxVM et en posséder la licence seulement pour les nœuds liés aux dispositifs de stockage gérés par VxVM. |
|
SPARC : Solstice DiskSuite ou Solaris Volume Manager et VxVM |
Si vous installez ces deux gestionnaires de volumes sur le même nœud, vous devez utilisez le logiciel Solstice DiskSuite ou Solaris Volume Manager pour gérer les disques locaux de chaque nœud. Les disques locaux incluent le disque racine. Utilisez VxVM pour gérer tous les disques partagés. |
Pour connaître les procédures d'installation et de configuration, reportez-vous à la documentation sur le gestionnaire de volumes et à la rubrique Installation et configuration du logiciel Solstice DiskSuite ou Solaris Volume Manager ou SPARC : Installation et configuration du logiciel VxVM . Pour obtenir plus d'informations sur la gestion de volumes dans une configuration de cluster, reportez-vous au document Guide des notions fondamentales de Sun Cluster pour SE Solaris.
Recommandations relatives au logiciel de gestion des volumes
Tenez compte des instructions générales suivantes lors de la configuration de vos disques à l'aide d'un logiciel de gestion de volumes :
-
RAID : Sun Cluster ne prend pas en charge le logiciel RAID 5.
-
Disques multihôtes mis en miroir : vous devez mettre tous les disques multihôtes en miroir sur les unités d'extension de disque. Pour obtenir plus d'informations sur la mise en miroir des disques multihôtes, reportez-vous à la rubrique Recommandations relatives à la mise en miroir des disques multihôtes . Vous n'êtes pas tenu de procéder à une mise en miroir logicielle si le périphérique de stockage dispose de matériel RAID ainsi que de chemins d'accès aux périphériques redondants.
-
Disque racine mis en miroir : la mise en miroir du disque racine assure une disponibilité élevée, mais elle n'est pas obligatoire. Pour savoir comment déterminer si la mise en miroir du disque racine est ou non souhaitable, reportez-vous à la rubrique Recommandations relatives à la mise en miroir .
-
Attribution d'un nom unique : vous pouvez disposer de métapériphériques Solstice DiskSuite locaux, de volumes Solaris Volume Manager locaux ou de volumes VxVM utilisés comme périphériques pour monter les systèmes de fichiers /global/.devices/node@nodeid. Dans ce cas, le nom de chaque métapériphérique ou volume local utilisé pour monter un système de fichiers /global/.devices/node@nodeid doit être unique sur le cluster.
-
Listes des nœuds : pour être hautement disponible, un groupe de périphériques de disques doit posséder des listes de maîtres potentiels et une stratégie de rétablissement en cas de panne identiques à celles du groupe de ressources associé. Ou, si un groupe de ressources évolutives utilise plus de nœuds que le groupe de périphériques de disques associé, la liste des nœuds du groupe de ressources évolutives doit être un surensemble de la liste des nœuds du groupe de périphériques de disques. Pour obtenir plus d'informations sur les listes de nœuds, reportez-vous aux rubriques consacrées à la planification des groupes de ressources dans le document Sun Cluster Data Services Planning and Administration Guide for Solaris OS.
-
Disques multihôtes : vous pouvez connecter tous les périphériques utilisés pour établir un groupe sur tous les nœuds configurés pour ce groupe de périphériques. Le logiciel Solstice DiskSuite ou Solaris Volume Manager peut contrôler automatiquement cette connexion lors de l'ajout de périphériques à un jeu de disques. Cependant, les groupes de disques VxVM configurés ne sont associés à aucun ensemble de nœuds particulier.
-
Disques hot spare : vous pouvez utiliser des disques hot spare pour accroître la disponibilité, mais ils ne sont pas obligatoires.
Reportez-vous à la documentation de votre gestionnaire de volumes pour connaître les recommandations de disposition du disque et les restrictions supplémentaires.
Recommandations relatives au logiciel Solstice DiskSuite ou Solaris Volume Manager
Tenez compte des points suivants lorsque vous planifiez des configurations Solstice DiskSuite ou Solaris Volume Manager.
-
Nom de métapériphérique/de volume local : le nom de chaque métapériphérique Solstice DiskSuite ou volume Solaris Volume Manager local utilisé pour monter un système de fichiers de périphériques globaux /global/.devices/node@nodeid doit être unique sur le cluster. De plus, le nom ne peut pas être le même que celui d'aucun ID de périphérique.
-
Médiateurs à deux chaînes : chaque jeu de disques configuré avec exactement deux chaînes de disque et géré par exactement deux nœuds doit comporter des médiateurs Solstice DiskSuite ou Solaris Volume Manager. Une chaîne de disque se compose d'une baie de disques avec ses disques physiques, des câbles de la baie vers le ou les nœuds et des adaptateurs d'interface. Respectez les règles suivantes pour configurer les médiateurs à deux chaînes :
-
Vous devez configurer chaque jeu de disques avec exactement deux nœuds intervenant en tant qu'hôtes médiateurs.
-
Vous devez utiliser les deux mêmes nœuds pour tous les jeux de disques nécessitant des médiateurs. Ces deux nœuds doivent contrôler les jeux de disques.
-
Les médiateurs ne peuvent pas être configurés pour des jeux de disques ne remplissant pas les conditions requises (deux chaînes et deux hôtes).
Pour obtenir plus d'informations, reportez-vous à la page de manuel mediator(7D).
-
-
Paramètres /kernel/drv/md.conf : tous les métapériphériques Solstice DiskSuite ou volumes Solaris Volume Manager (Solaris 9) utilisés par chaque jeu de disques sont créés à l'avance (au moment de la réinitialisation après reconfiguration). Cette reconfiguration se base sur les paramètres de configuration existant dans le fichier /kernel/drv/md.conf.
Remarque –Avec la parution de Solaris 10, Solaris Volume Manager a été amélioré et prend désormais en charge la configuration dynamique des volumes. Il n'est plus nécessaire de modifier les paramètres nmd et md_nsets du fichier /kernel/drv/md.conf. Les nouveaux volumes sont créés de manière dynamique, selon vos besoins.
Pour prendre en charge une configuration Sun Cluster sous Solaris 8 ou Solaris 9, vous devez modifier les champs nmd et md_nsets comme suit :
Caution – Tous les nœuds du cluster doivent disposer de fichiers /kernel/drv/md.conf identiques, quel que soit le nombre de jeux de disques servis par chacun d'eux. Le non-respect de cette consigne peut occasionner de graves erreurs de Solstice DiskSuite ou Solaris Volume Manager et un risque de pertes de données.
-
md_nsets : le champ md_nsets définit le nombre total de jeux de disques qui peuvent être créés pour un système afin de répondre aux besoins du cluster entier. Paramétrez la valeur du champ sur le nombre attendu de jeux de disques dans le cluster plus un jeu supplémentaire. Le logiciel Solstice DiskSuite ou Solaris Volume Manager utilise ce dernier pour gérer les disques privés sur l'hôte local.
Le nombre maximal de jeux de disques autorisés par cluster est de 32. Il correspond à 31 jeux de disques dédiés à une utilisation générale plus un jeu destiné à la gestion de disques privés. La valeur par défaut de md_nsets est 4.
-
nmd : le champ nmd définit la valeur la plus élevée du futur nom de métapériphérique/de volume du cluster. Par exemple, si la plus haute valeur utilisée par les 15 premiers jeux de disques d'un cluster est 10, alors que celle du seizième est 1000, définissez nmd sur au moins 1000. Par ailleurs, la valeur de nmd doit être suffisamment grande pour prendre en compte chaque ID de périphérique et pour garantir que le nom de chaque métapériphérique local ou de chaque volume local est unique dans tout le cluster.
La valeur maximale de noms de métapériphérique ou de volume par jeu de disques est de 8192. La valeur par défaut du champ nmd est 128.
Définissez ces champs au moment de l'installation en tenant compte des éventuelles extensions futures du cluster. L'augmentation de la capacité de ces champs, après la production du cluster, prend du temps. La modification de cette valeur nécessite une reconfiguration au démarrage pour chaque nœud. Si vous reportez cette opération, cela augmente également la probabilité d’erreurs d’allocation d’espace dans le système de fichiers root (/) pour créer tous les périphériques nécessaires.
Parallèlement, définissez la valeur des champs nmd et md_nsets sur la valeur la plus basse possible. Les structures de mémoire existent pour tous les périphériques possibles conformément aux commandes nmd et md_nsets, même si vous n'avez pas créé ces périphériques. Pour des performances optimales, configurez la valeur de nmd et de md_nsets de sorte qu'elle soit légèrement supérieure au nombre de métapériphériques ou de volumes que vous utiliserez.
Pour obtenir plus d'informations sur le fichier md.conf, reportez-vous à la rubrique System and Startup Files du document Solstice DiskSuite 4.2.1 Reference Guide (Solaris 8) ou System Files and Startup Files du Solaris Volume Manager Administration Guide (Solaris 9 ou Solaris 10).
-
SPARC : Recommandations relatives au logiciel VERITAS Volume Manager
Tenez compte des points suivants lorsque vous planifiez des configurations VERITAS Volume Manager (VxVM) :
-
Convention d'appellation d'après la baie : si vous décidez de nommer les périphériques d'après la baie qu'ils occupent (Enclosure-Based Naming), veillez à préserver la cohérence des noms sur tous les nœuds du cluster qui partagent le même stockage. VxVM ne procède pas à la coordination de ces noms, il incombe donc à l'administrateur de vérifier que VxVM attribue le même nom à tous les périphériques identiques des différents nœuds. Des noms incompatibles n'ont pas d'incidence sur le comportement correct du cluster. Cependant, ils compliquent considérablement l'administration du cluster et augmentent grandement le risque d'erreurs de configuration, pouvant éventuellement engendrer des pertes de données.
-
Groupe de disques racine : depuis VxVM 4.0, la création d'un groupe de disques racine est facultative.
Un groupe de disques racine peut être créé sur les disques suivants :
-
le disque racine, devant être encapsulé ;
-
un ou plusieurs disques locaux non racine, pouvant être encapsulés ou initialisés ;
-
une combinaison de disques racine et de disques locaux non racine.
Le groupe de disques racine doit être local sur le nœud.
-
-
Groupes de disques racine simples : Sun Cluster ne prend pas en charge les groupes de disques racine simples (rootdg créé sur une tranche unique) avec VxVM. Il s'agit d'une restriction générale du logiciel VxVM.
-
Encapsulation : les disques à encapsuler doivent disposer de deux entrées libres de table de tranches.
-
Nombre de volumes : lors de la création d'un groupe de périphériques de disques, estimez le nombre maximal de volumes qu'il utilisera.
-
Si ce nombre de volumes est inférieur à 1000, vous pouvez utiliser les codes mineurs par défaut.
-
Si ce nombre est supérieur ou égal à 1000, vous devez prévoir avec soin le mode d'affectation des codes mineurs aux volumes du groupe de périphériques de disques. Il est impossible d'affecter des codes mineurs se chevauchant à deux groupes de périphériques.
-
-
Journal des zones modifiées : l'utilisation de ce journal permet une récupération plus rapide des volumes après la défaillance d'un nœud. Il peut cependant réduire le débit d'E/S.
-
Multiacheminement dynamique : l'utilisation de cette seule fonction pour gérer plusieurs chemins d'E/S par nœud vers l'espace de stockage partagé n'est pas prise en charge. Elle ne l'est que pour les configurations suivantes :
-
chemin d'E/S unique par nœud vers le stockage partagé du cluster ;
-
solution de multi-acheminement prise en charge, telle que Sun Traffic Manager, EMC PowerPath ou Hiatchi HDLM et gérant plusieurs chemins d'E/S par nœud vers le stockage partagé du cluster.
-
Pour obtenir plus d'informations, reportez-vous à la documentation d'installation de VxVM.
Journalisation de système de fichiers
La journalisation est requise pour les systèmes de fichiers de cluster VxFS et UFS. Cette obligation ne s'applique pas aux systèmes de fichiers partagés QFS. Le logiciel Sun Cluster prend en charge les choix suivants en matière de journalisation de système de fichiers :
-
Journalisation UFS Solaris : pour obtenir plus d'informations, reportez-vous à la page de manuel mount_ufs(1M).
-
Journalisation de trans-métapériphériques Solstice DiskSuite ou Journalisation de volumes de transaction Solaris Volume Manager : reportez-vous au Chapitre 2, Creating DiskSuite Objects du Solstice DiskSuite 4.2.1 User’s Guide ou à la rubrique Transactional Volumes (Overview) du Solaris Volume Manager Administration Guide. Les volumes transactionnels ne sont plus valides depuis la version Solaris 10 de Solaris Volume Manager.
-
SPARC : journalisation Système de fichiers VERITAS (VxFS). Pour obtenir plus d'informations, reportez-vous à la page de manuel relative à mount_vxfs fournie avec VxFS.
Le tableau suivant répertorie les journalisations de systèmes de fichiers prises en charge par chaque gestionnaire de volumes.
Tableau 1–5 Tableau des journalisations de système de fichiers prises en charge
Lors du choix entre la Journalisation UFS Solaris et la Journalisation de trans-métapériphériquesSolstice DiskSuite/Journalisation de volumes de transaction Solaris Volume Manager pour les systèmes de fichiers de cluster UFS, tenez compte des points suivants :
-
Solaris Volume Manager Journalisation de volumes de transaction (anciennement Solstice DiskSuite Journalisation de trans-métapériphériques) sera supprimée du système d'exploitation Solaris dans une version à venir. La Journalisation UFS Solaris offre les mêmes possibilités mais avec des performances optimales, ainsi que des conditions d'administration système et une surcharge allégées.
-
Taille du journal de Solaris UFS : la Journalisation UFS Solaris alloue toujours le journal avec l'espace libre sur le système de fichiers UFS, suivant la taille du système de fichiers.
-
Sur les systèmes de fichiers de moins de 1 Go, le journal occupe 1 Mo.
-
Sur les systèmes de fichiers d'au moins 1 Go ou plus, le journal occupe 1 Mo par Go sur le système de fichiers, la limite maximale étant de 64 Mo.
-
-
Métapériphérique/volume de transaction de journalisation : un trans-métapériphérique Solstice DiskSuite ou un volume de transaction Solaris Volume Manager gère la journalisation UFS. Le composant de journalisation d'un trans-métapériphérique ou d'un volume de transaction est un métapériphérique ou un volume qui permet la mise en miroir et en bande. La taille maximale du journal est de 1 Go, mais 64 Mo suffisent pour la plupart des systèmes de fichiers. La taille de journal minimale est de 1 Mo.
Recommandations relatives à la mise en miroir
Cette rubrique donne les recommandations suivantes sur la planification de la mise en miroir de la configuration de votre cluster :
-
Recommandations relatives à la mise en miroir des disques multihôtes
-
Recommandations relatives à la mise en miroir du disque racine
Recommandations relatives à la mise en miroir des disques multihôtes
La mise en miroir de tous les disques multihôtes dans une configuration Sun Cluster permet de tolérer des pannes générées au niveau d'un seul périphérique. Sun Cluster requiert la mise en miroir de tous les disques multihôtes sur les différentes unités d'extension. Vous n'êtes pas tenu de procéder à une mise en miroir logicielle si le périphérique de stockage dispose de matériel RAID ainsi que de chemins d'accès aux périphériques redondants.
Lors de la mise en miroir de disques multihôtes, tenez compte des points suivants.
-
Unités d'extension de disque distinctes : chaque sous-miroir d'un miroir ou d'un plex donné doit résider dans une unité d'extension multihôte différente.
-
Espace disque : la mise en miroir double l'espace disque nécessaire.
-
Mise en miroir à trois voies : les logiciels Solstice DiskSuite ou Solaris Volume Manager et VERITAS Volume Manager (VxVM) prennent en charge la mise en miroir à trois voies. Cependant, Sun Cluster ne nécessite qu'une mise en miroir à deux voies.
-
Tailles de disques différentes : si vous effectuez une mise en miroir vers un disque de taille différente, la capacité de mise en miroir se limite à la taille du plus petit sous-miroir ou plex.
Pour obtenir plus d'informations sur les disques multihôtes, reportez--vous à la rubrique Stockage sur disques multihôtes du Présentation de Sun Cluster pour SE Solaris et au Guide des notions fondamentales de Sun Cluster pour SE Solaris.
Recommandations relatives à la mise en miroir du disque racine
Ajoutez ces informations de planification à la Fiche de travail de configuration des systèmes de fichiers locaux.
Pour une disponibilité maximale, mettez en miroir les systèmes de fichiers racine (/), /usr, /var, /opt et swap sur les disques locaux. Sous VxVM, vous encapsulez le disque racine et dupliquez les sous-disques générés. Le logiciel Sun Cluster n'impose pas de mise en miroir du disque racine.
Avant de décider de mettre ou non le disque racine en miroir, tenez compte des risques, de la complexité, du coût et du temps de maintenance pour les différentes possibilités concernant ce disque. Il n'existe pas de stratégie de mise en miroir valable pour toutes les configurations. Pour appliquer la mise en miroir au disque racine, n'hésitez pas à prendre conseil auprès de votre interlocuteur du service technique de Sun.
Pour connaître les procédures de mise en miroir du disque racine, reportez-vous à la documentation sur le gestionnaire de volumes et à la rubrique Installation et configuration du logiciel Solstice DiskSuite ou Solaris Volume Manager ou SPARC : Installation et configuration du logiciel VxVM .
Tenez compte des points suivants pour décider d'appliquer ou non la mise en miroir du disque racine :
-
Disque d'initialisation : vous pouvez paramétrer le miroir afin qu'il devienne un disque racine d'amorçage. Vous pourrez alors démarrer à partir du miroir en cas d'échec du disque d'amorçage principal.
-
Complexité : la mise en miroir du disque racine complique l'administration du système, ainsi que l'initialisation en mode monoutilisateur.
-
Sauvegardes : qu'il soit ou non mis en miroir, le disque racine doit faire l'objet de sauvegardes régulières. La mise en miroir à elle seule ne protège pas contre les erreurs administratives. Seul un plan de sauvegarde vous permet de récupérer des fichiers accidentellement altérés ou supprimés.
-
Périphériques de quorum : n'utilisez pas de disque configuré en tant que périphérique de quorum pour mettre un disque racine en miroir.
-
Quorum : sous le logiciel Solstice DiskSuite ou Solaris Volume Manager, en cas de panne entraînant la perte du quorum de la base de données d'état des métapériphériques, vous ne pouvez pas réinitialiser le système sans effectuer un minimum de maintenance. Reportez-vous à la documentation Solstice DiskSuite ou Solaris Volume Manager pour de plus amples informations sur la base de données d'état et ses répliques.
-
Contrôleurs distincts : pour une disponibilité maximale, le disque racine doit être mis en miroir sur un contrôleur distinct.
-
Disque racine secondaire : avec un disque racine mis en miroir, vous pouvez continuer à travailler à partir du disque racine secondaire (miroir) en cas de panne du disque racine principal. Plus tard, le disque racine principal pourra être remis en service, par exemple, après une mise sous tension ou des erreurs E/S transitoires. Les initialisations qui suivront seront effectuées sur le disque racine principal indiqué pour le paramètre eeprom(1M) boot-device. Dans ce cas, aucune tâche de réparation manuelle n'a eu lieu, mais le lecteur redémarre à un niveau suffisant pour permettre la réinitialisation. Avec Solstice DiskSuite ou Solaris Volume Manager une resynchronisation a lieu. La resynchronisation nécessite une étape manuelle lors de la remise en service du lecteur.
Si des modifications ont été apportées à des fichiers du disque racine (miroir) secondaire, elles ne seront pas reflétées sur le disque racine principal lors de l'initialisation. Cela entraînerait un sous-miroir périmé. Par exemple, les éventuelles modifications apportées au fichier /etc/system sont perdues. Avec le logiciel Solstice DiskSuite ou Solaris Volume Manager, certaines commandes administratives sont susceptibles de modifier le fichier /etc/system tandis que le disque racine principal est hors service.
Le programme d'initialisation ne vérifie pas si le système initialise à partir d'un miroir ou à partir d'un périphérique physique sous-jacent. La mise en miroir devient active à travers le processus d'initialisation, une fois que les métapériphériques ou les volumes sont chargés. Avant ce point, le système est vulnérable face aux problèmes d'obsolescence des sous-miroirs.
- © 2010, Oracle Corporation and/or its affiliates