Chapitre 1 Planification de la configuration Sun Cluster
Ce chapitre fournit des informations et des instructions pour la planification et l'installation d'une configuration Sun Cluster.
Il contient les informations générales suivantes :
Emplacement des 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 de cluster |
|
|
Planification de l'installation du logiciel de cluster | |
|
Installation d'un nouveau cluster ou ajout de noeuds à un cluster existant | |
|
Installation et configuration du logiciel Solstice DiskSuiteTM/Solaris Volume Manager |
|
|
SPARC : installation et configuration du logiciel VERITAS Volume Manager (VxVM). |
|
|
Configuration du logiciel de structure cluster, installation et configuration optionnelles du module Sun Cluster sur Sun Management Center (disponible uniquement sur systèmes SPARC) | |
|
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 | |
|
Mise à niveau vers le logiciel Sun Cluster 3.1 4/04 |
|
Planification de l'environnement d'exploitation Solaris
Cette rubrique explique comment planifier l'installation du logiciel Solaris dans une configuration de cluster. Pour de plus amples 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 en utilisant la méthode d'installation JumpStartTM. En outre, le logiciel Sun Cluster offre une méthode personnalisée permettant d'installer à la fois l'environnement d'exploitation Solaris et le logiciel Sun Cluster avec la méthode d'installation JumpStart. Si vous installez plusieurs noeuds de cluster, nous vous recommandons une installation en réseau.
Reportez-vous à la rubrique Installation de Solaris et du logiciel Sun Cluster (JumpStart) pour de plus amples informations sur la méthode d'installation scinstall de JumpStart. Reportez-vous à la documentation d'installation de Solaris pour de plus amples informations sur les méthodes d'installation standard de Solaris.
Restrictions au niveau des fonctions de l'environnement d'exploitation de Solaris
Les fonctions de l'environnement d'exploitation Solaris suivantes ne sont pas prises en charge dans une configuration de Sun Cluster :
-
Les groupes d'interface de Solaris ne sont pas pris en charge dans une configuration Sun Cluster. 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. Reportez-vous à la page de manuel ifconfig(1M) pour de plus amples informations sur les groupes d'interfaces de Solaris.
-
L'arrêt automatique pour économie d'énergie n'est pas pris en charge dans les configurations Sun Cluster et ne doit pas être activé. Reportez-vous aux pages de manuel pmconfig(1M) et power.conf(4) pour de plus amples informations.
À propos des groupes de logiciels Solaris
Le logiciel Sun Cluster 3.1 4/04 implique l’installation du 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 déterminer le groupe de logiciels Solaris que vous devez installer.
-
Reportez-vous à la documentation de votre serveur pour connaître la configuration minimale requise par Solaris. Par exemple les serveurs Sun Enterprise 10000 requièrent les groupes de logiciels Entire Distribution et OEM.
-
Si vous envisagez d’utiliser des adaptateurs SCI-PCI, disponibles uniquement dans les clusters basés sur SPARC, ou le package Remote Shared Memory Application Programming Interface (RSMAPI), vérifiez que vous avez installé les packages des logiciels RSMAPI (SUNWrsm, SUNWrsmx, SUNWrsmo et SUNWrsmox). Ces packages ne sont inclus que dans certains groupes de logiciels de 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 à l'aide de la commande pkgadd(1M). Reportez-vous à la rubrique Solaris 8 des pages de manuel (3RSM), pour de plus amples informations sur l'utilisation de RSMAPI.
-
Vous aurez peut-être besoin d'installer d'autres packages Solaris non inclus dans le groupe de logiciels utilisateur final de Solaris, comme 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 au tableau approprié de la Fiche de travail de configuration des systèmes de fichiers locaux.
Lorsque vous installez l'environnement d'exploitation Solaris, veillez à créer les partitions Sun Cluster requises et à ce que toutes les partitions répondent aux exigences d'espace minimales.
-
swap : le total combiné d'espace de swap alloué à Solaris et au logiciel Sun Cluster ne doit pas être inférieur à 750 Mo. Pour de meilleurs résultats, ajoutez au moins 512 Mo pour le logiciel Sun Cluster à l'espace requis par l'environnement 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 noeud 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 de swap pour le noeud.
-
/globaldevices : créez un système de fichiers de 512 Mo qu'utilisera scinstall(1M) pour les périphériques globaux.
-
Gestionnaire de volumes : créez une partition de 20 Mo sur une tranche en fin de disque (tranche 7) qu'utilisera le gestionnaire de volumes. Si votre cluster utilise VERITAS Volume Manager (VxVM) et que vous prévoyez d'encapsuler le disque root, 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 de l'environnement d'exploitation 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 équipé de l'environnement d'exploitation Solaris, vous pouvez configurer les répertoires racine (/), /var, /usr, et /opt en systèmes de fichiers séparés, ou inclure tous les répertoires dans le système de fichiers root (/). 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.
-
root (/) : le logiciel Sun Cluster occupe lui-même moins de 40 Mo dans le système de fichiers root (/). Le logiciel Solstice DiskSuite/Solaris Volume Manager requiert moins de 5 Mo et le logiciel VxVM moins de 15 Mo. Pour configurer davantage d'espace et de capacité d'inode suffisants, ajoutez au moins 100 Mo à l'espace que vous alloueriez en temps normal à votre système de fichiers root (/). Cet espace est utilisé pour la création de périphériques spéciaux en mode bloc et des dispositifs de caractères spéciaux utilisés soit par Solstice DiskSuite/Solaris Volume Manager, soit par VxVM. 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 noeud de cluster peut être plus important que sur un serveur autonome typique. Allouez donc au moins 100 Mo au système de fichiers /var.
-
/usr : le logiciel Sun Cluster occupe moins de 25 Mo dans le système de fichiers /usr. Les logiciels Solstice DiskSuite/Solaris Volume Manager et VxVM requièrent chacun moins de 15 Mo.
-
/opt : la structure logicielle de Sun Cluster occupe 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/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 noeud 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. Nommez ce système de fichiers /globaldevices ; il s'agit du nom par défaut reconnu par la commande scinstall(1M).
La commande scinstall renomme le système de fichiers plus tard /global/.devices/node@id_noeud, id_noeud représente le nombre assigné à un noeud lorsque celui-ci devient membre du cluster. Le point de montage /globaldevices d'origine est supprimé.
Le système de fichiers /globaldevices doit disposer d'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 devrait suffire à la plupart des configurations de cluster.
Exigences du gestionnaire de volumes
Si vous utilisez le logiciel Solstice DiskSuite/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 noeud 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/Solaris Volume Manager fonctionne correctement. Pour de plus amples informations, reportez-vous à la documentation de Solstice DiskSuite/Solaris Volume Manager.
SPARC : si vous utilisez VERITAS Volume Manager (VxVM) et que vous envisagez d'encapsuler le disque root, vous aurez besoin de deux tranches inutilisées pour 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'encapsulage du disque racine, reportez-vous à la documentation relative à VxVM.
Exemples d'allocation de système de fichiers
Le Tableau 1–2 présente un schéma de partitionnement pour un noeud de cluster disposant de moins de 750 Mo de mémoire physique. Y seront installés le groupe de logiciels utilisateur final de l'environnement d'exploitation Solaris, Sun Cluster et le service de données Sun Cluster HA for NFS. La dernière tranche du disque, la tranche 7, se voit allouer un petit espace destiné au gestionnaire de volumes.
Cette disposition permet d'utiliser Solstice DiskSuite/Solaris Volume Manager ou VxVM. Si vous utilisez Solstice DiskSuite/Solaris Volume Manager, vous pouvez réserver la tranche 7 pour la réplique de 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 |
Allocation (en Mo) |
Description |
|---|---|---|---|
|
0 |
/ |
6,75 Go |
Espace libre restant sur le disque après l'allocation d'espace aux tranches 1 à 7. Utilisé pour l’environnement 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 racine et les logiciels de bases de données et d’applications. |
|
1 |
swap |
1 Go |
512 Mo pour l'environnement 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ée |
- |
Tranche libre disponible pour l'encapsulage du disque racine sous VxVM. |
|
5 |
inutilisée |
- |
- |
|
6 |
inutilisée |
- |
- |
|
7 |
gestionnaire de volumes |
20 Mo |
Utilisé par le logiciel Solstice DiskSuite/Solaris Volume Manager pour la réplique de 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 des informations détaillées sur les composants Sun Cluster, consultez les documents Sun Cluster Overview for Solaris OS et Sun Cluster Concepts Guide for Solaris OS.
Gestion des licences
Assurez-vous de bien posséder les certificats de licence nécessaires avant de commencer l'installation du logiciel. Le logiciel Sun Cluster ne nécessite pas de certificat de licence, mais chaque noeud 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 documentations d'installation de ces produits.
Patchs logiciels
Après avoir installé chacun des logiciels, vous devez également installer les patchs éventuellement requis.
-
Pour de plus amples informations sur les patchs éventuellement requis, reportez-vous à la rubrique “Patches and Required Firmware Levels” in Sun Cluster 3.1 4/04 Release Notes for Solaris OS ou consultez votre prestataire de services Sun.
-
Pour obtenir des instructions et des procédures générales sur l'application des patchs, reportez-vous à la rubrique “Patching Sun Cluster Software and Firmware” in Sun Cluster System Administration Guide for Solaris OS.
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 noeud 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 suivant répertorie les composants nécessitant l'affectation d'une adresse IP. Ajoutez ces adresses IP à tous les services d'attribution de noms utilisés. Ajoutez-les également au fichier local /etc/inet/hosts sur chaque noeud de cluster après avoir installé le logiciel Solaris.
-
Pour de plus amples informations sur les adresses IP, reportez-vous aux documents System Administration Guide, Volume 3 (Solaris 8) ou System Administration Guide: IP Services (Solaris 9).
-
Pour de plus amples informations sur les adresses IP de test pour la prise en charge de l'IPMP, 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 noeuds 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 noeuds du cluster.
-
Un concentrateur de terminal est utilisé pour établir la communication entre la console administrative et les consoles de noeuds 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 de plus amples informations sur l'accès aux consoles, reportez-vous au document Sun Cluster Concepts Guide for Solaris OS.
Adresses logiques
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.
-
Pour de plus amples informations, reportez-vous au document Sun Cluster Data Services Planning and Administration Guide for Solaris OS.
-
Pour de plus amples informations sur les ressources et les services de données, reportez-vous également aux documents Sun Cluster Overview for Solaris OS et Sun Cluster Concepts Guide for Solaris OS.
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 privés (interconnexion de cluster) doivent utiliser des adaptateurs distincts.
-
Vous devez avoir au moins un réseau public connecté à tous les noeuds de cluster.
-
Vous pouvez avoir autant de connexions supplémentaires au réseau public que votre configuration matérielle le permet.
-
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.
-
Au cours de l'installation de Sun Cluster, l'utilitaire scinstall configure un groupe IPMP à adaptateur unique pour chaque adaptateur de réseau public. Pour modifier ces groupes de secours une fois l'installation effectuée, suivez la procédure indiquée dans la rubrique “Deploying Network Multipathing” du document IP Network Multipathing Administration Guide (Solaris 8) ou dans la rubrique “Administering Network Multipathing (Task)” in System Administration Guide: IP Services (Solaris 9).
Reportez-vous à la rubrique Groupes IPMP pour de plus amples informations sur la planification de groupes d'adaptateurs de réseau public de secours. Pour de plus amples informations sur les interfaces de réseau public, reportez-vous au document Sun Cluster Concepts Guide for Solaris OS.
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 travail relative à la configuration appropriée.
Tableau 1–4 Fiches de travail relatives à la configuration de Sun Cluster
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 noeuds
Le nom de noeud est le nom que vous affectez à une machine lorsque vous installez l'environnement d'exploitation Solaris. Pendant la configuration de Sun Cluster, indiquez le nom de tous les noeuds que vous installez en tant que noeuds de cluster. Dans les installations à noeud unique, le nom du noeud par défaut est celui du cluster.
Réseau privé
Remarque :
vous n'avez pas besoin de configurer un réseau privé pour un cluster à noeud unique.
Le logiciel Sun Cluster utilise le réseau privé pour les communications internes entre les noeuds. La configuration de 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 noeud du cluster. Vous pouvez soit accepter l'adresse de réseau privé (172.16.0.0) et le masque de réseau (255.255.0.0) par défaut, soit entrer des données différentes si cette adresse est déjà utilisée dans l'entreprise.
Remarque :
une fois le traitement de l'utilitaire d'installation (scinstall, SunPlex Manager, ou JumpStart) effectué et le cluster établi, vous ne pourrez plus modifier l'adresse de réseau privé et le masque de réseau. 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 :
-
Les deux derniers octets de l'adresse doivent être nuls.
-
L'adresse doit respecter les instructions de la RFC 1597 pour l'affectation d'adresses réseau.
Vous pouvez contacter l'InterNIC pour obtenir des exemplaires d'RFC. 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 (Task)” in System Administration Guide: IP Services (Solaris 9) pour obtenir des instructions.
Si vous spécifiez un masque de réseau différent du masque par défaut, il doit masquer au minimum tous les bits fournis dans l'adresse du réseau privé.
Noms d'hôtes privés
Le nom d'hôte privé est le nom utilisé pour la communication entre les noeuds sur l'interface de réseau privé. Ils sont créés automatiquement lors de la configuration de Sun Cluster. Ces noms d'hôtes privés sont conformes à la convention d'attribution de noms clusternodeid_noeud-priv, où id_noeud est le numéral de l'ID du noeud interne. Lors de la configuration de Sun Cluster, ce numéro d'ID est affecté automatiquement à chaque noeud dès lors qu'il devient membre du cluster. Une fois le cluster configuré, vous pouvez renommer les noms d'hôtes privés à l'aide de l'utilitaire scsetup(1M).
Interconnexion de cluster
Remarque :
vous n'avez pas besoin de configurer une interconnexion de cluster pour un cluster à noeud unique. Cependant, si vous prévoyez d'ajouter par la suite des noeuds à une configuration de cluster à noeud unique, 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 noeuds 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 indiquez les informations de configuration suivantes pour deux interconnexions de clusters.
-
Adaptateurs de transport : pour les adaptateurs de transport comme les ports ou les interfaces réseau, indiquez le nom des adaptateurs de transport, ainsi que le type de transport. Si votre configuration est un cluster à deux noeuds, vous devez également indiquer si votre interconnexion est connectée directement (adaptateur à adaptateur) ou utilise une jonction de transport. Si votre cluster à deux noeuds 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 noeud au cluster à l'avenir.
Reportez-vous aux pages du manuel scconf_trans_adap_*(1M) pour de plus amples informations sur un adaptateur de transport spécifique.
-
Jonctions de transport : si vous utilisez des jonctions de transport, par exemple un commutateur réseau, indiquez leur nom 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. L'adaptateur Sun Firelink constitue une exception ; il requiert le nom de jonction sw-rsmN. scinstall utilise automatiquement ce nom de jonction lorsqu'un adaptateur Sun Firelink est spécifié (wrsmN).
Indiquez également le nom du port de jonction ou acceptez le nom par défaut. Le nom de port par défaut est identique à l'ID de noeud interne du noeud 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 noeuds ou plus doivent utiliser des jonctions de transport. La connexion directe entre les noeuds de cluster est possible uniquement pour les clusters à deux noeuds.
Une fois le cluster établi, vous pouvez configurer des connexions supplémentaires au réseau privé à l'aide de l'utilitaire scsetup(1M).
Pour de plus amples informations concernant l'interconnexion de cluster, reportez-vous à la rubrique “Cluster Interconnect” in Sun Cluster Overview for Solaris OS et Sun Cluster Concepts Guide for Solaris OS.
Groupes IPMP
Ajoutez ces informations de planification à la Fiche de travail relative aux réseaux publics.
Les groupes IPMP, qui remplacent les groupes NAFO (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.
Prenez les points suivants en considération lorsque vous planifiez les groupes IPMP.
-
Chaque adaptateur de réseau public doit appartenir à un groupe de multi-acheminement.
-
Pour les groupes de multi-acheminement contenant au moins deux adaptateurs, il faut configurer une adresse IP de test pour chaque adaptateur du groupe. 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 pour tous les adaptateurs du même groupe de multi-acheminement doivent appartenir à un seul 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, ne modifiez pas la valeur de TRACK_INTERFACES_ONLY_WITH_GROUPS de yes pour no.
-
Le nom d'un groupe de multi-acheminement ne fait l'objet d'aucune exigence ni restriction.
Pour de plus amples informations sur l'IPMP, reportez-vous à la rubrique “Deploying Network Multipathing” du document IP Network Multipathing Administration Guide (Solaris 8) ou à la rubrique “Administering Network Multipathing (Task)” in System Administration Guide: IP Services (Solaris 9). Consultez également la rubrique “IP Network Multipathing Groups” in Sun Cluster Overview for Solaris OS et Sun Cluster Concepts Guide for Solaris OS.
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 noeud, le périphérique de quorum évite les problèmes “d'amnésie” ou de dédoublement lorsque le noeud tente de rejoindre le cluster. You affecter des périphériques de quorum à l'aide de l'utilitaire scsetup(1M).
Remarque :
vous n'avez pas besoin de configurer des périphériques de quorum pour un cluster à noeud unique.
Tenez compte des points suivants lorsque vous planifiez des périphériques de quorum.
-
Minimum : un cluster à deux noeuds doit avoir au moins un disque partagé affecté en tant que périphérique de quorum. Pour les autres topologies, les périphériques de quorum sont facultatifs.
-
La règle du nombre impair : si plus d’un périphérique de quorum est configuré dans un cluster à deux noeuds, ou dans plusieurs noeuds directement connectés à un périphérique de quorum, configurez un nombre impair de périphériques de quorum. 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 noeuds au moins.
Pour de plus amples informations sur les périphériques de quorum, reportez-vous aux documents “Quorum Devices” in Sun Cluster Overview for Solaris OS et Sun Cluster Concepts Guide for Solaris OS.
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 de plus amples informations sur les périphériques globaux et les systèmes de fichiers de cluster, reportez-vous aux documents Sun Cluster Overview for Solaris OS et Sun Cluster Concepts Guide for Solaris OS.
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 du périphérique global à haute disponibilité. 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 procédez à une mise en miroir, organisez les systèmes de fichiers de manière à obtenir une mise en miroir qui respecte les baies de disques.
-
Disponibilité : vous devez connecter physiquement un périphérique global à plus d’un noeud 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 noeud unique. Vous pouvez configurer un périphérique global avec une seule connexion physique, mais il sera inaccessible depuis les autres noeuds en cas de panne du noeud avec la connexion.
-
Périphériques de swap : ne créez pas un fichier de swap sur un périphérique global.
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 noeud secondaire en cas de panne du noeud principal. Tenez compte des points suivants lorsque vous planifiez des groupes de périphériques de disques.
-
Basculement : vous pouvez configurer des disques multiports et des périphériques du gestionnaire de volumes configurés correctement en tant que périphériques de basculement. Pour qu'un périphérique du gestionnaire de volumes soit configuré convenablement, des disques multiports doivent être configurés et le gestionnaire de volumes doit être installé correctement. Cette configuration garantit que les noeuds multiples peuvent héberger le périphérique exporté. Il est impossible de configurer des lecteurs de bandes, des CD ou des disques à un seul port comme des périphériques de reprise sur panne.
-
Mise en miroir : vous devez mettre les disques en miroir pour protéger les données en cas de panne de disque. Pour de plus amples informations sur la mise en miroir, reportez-vous aux rubriques Recommandations relatives à la mise en miroir, Installation et configuration du logiciel Solstice DiskSuite/Solaris Volume Manager et SPARC: installation et configuration du logiciel VxVM, ainsi qu'à la documentation de votre gestionnaire de volumes.
Pour de plus amples informations sur les groupes de périphériques de disques, reportez-vous aux documents “Devices” in Sun Cluster Overview for Solaris OS et Sun Cluster Concepts Guide for Solaris OS.
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 du point de montage : créez des points de montage pour les systèmes de fichiers de cluster du répertoire /global, sauf si d'autres produits 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 : La configuration Sun Cluster 3.1 ne prend pas en charge les fonctions VxFS suivantes :
-
E/S rapide ;
-
instantanés ;
-
points de contrôle du stockage ;
-
options de montage VxFS spécifiques :
-
convosync (Convertir O_SYNC) ;
-
mincache ;
-
qlog, delaylog, tmplog ;
-
-
fonction de cluster VERITAS & VCS nécessaire à VERITAS CFS.
Les avis de cache peuvent être utilisés, mais ils ne s'appliquent qu'au noeud sélectionné.
Toutes les autres fonctions et options VxFS prises en charge dans une configuration de cluster sont également prises en charge par le logiciel Sun Cluster 3.1. Veuillez vous reporter à la documentation VxFS pour obtenir des détails sur les options VxFS qui sont prises en charge dans une configuration de cluster.
-
-
Exigences de montages SPARC : VxFS : si vous utilisez VERITAS File System (VxFS), montez et démontez globalement un système de fichiers VxFS du noeud principal. Le noeud 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 noeud secondaire risque d'échouer.
-
Imbrication des points de montage : normalement, vous ne devriez pas imbriquer les points de montage pour les 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 noeuds. 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 noeud physique, par exemple, différentes tranches du même disque.
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/Solaris Volume Manager, ajoutez également ces informations de planification à la Fiche de travail relative aux métapériphériques (Solstice DiskSuite/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/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/Solaris Volume Manager et VERITAS Volume Manager (VxVM) que vous pouvez installer et utiliser des manières indiquées ci-dessous.
Tableau 1–5 Gestionnaires de volumes pris en charge par Sun Cluster|
Logiciel de gestionnaire de volume |
Conditions requises |
|---|---|
|
Solstice DiskSuite/Solaris Volume Manager |
Vous devez installer le logiciel Solstice DiskSuite/Solaris Volume Manager sur tous les noeuds du cluster, que vous utilisiez ou non VxVM sur certains noeuds pour gérer les disques. |
|
SPARC : VxVM avec la fonction cluster |
Vous devez installer VxVM et en posséder la licence avec la fonction cluster sur tous les noeuds du cluster. |
|
SPARC : VxVM sans la fonction cluster |
Vous devez installer VxVM et en posséder la licence seulement pour les noeuds liés aux périphériques de stockage gérés par VxVM. |
|
SPARC : Solstice DiskSuite/Solaris Volume Manager et VxVM à la fois |
Si vous installez ces deux gestionnaires de volumes sur le même noeud, vous devez utilisez le logiciel Solstice DiskSuite/Solaris Volume Manager pour gérer les disques locaux de chaque noeud. Les disques locaux incluent le disque racine. Utilisez VxVM pour gérer tous les disques partagés. |
Reportez-vous à la documentation du gestionnaire de volumes ainsi qu'aux rubriques Installation et configuration du logiciel Solstice DiskSuite/Solaris Volume Manager ou SPARC: installation et configuration du logiciel VxVM pour de plus amples informations sur l'installation et la configuration du logiciel de gestion des volumes. Pour de plus amples informations sur la gestion des volumes dans une configuration de cluster, reportez-vous au document Sun Cluster Concepts Guide for Solaris OS.
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 :
-
Disques multihôtes mis en miroir : vous devez mettre tous les disques multihôtes en miroir sur des périphériques d'extension de disques. Reportez-vous à la rubrique Recommandations relatives à la mise en miroir des disques multihôtes pour de plus amples informations sur 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 disques redondants.
-
Racine mise en miroir : la mise en miroir du disque racine améliore la disponibilité, mais elle n'est pas obligatoire. Reportez-vous à la rubrique Recommandations relatives à la mise en miroir pour de plus amples informations sur la mise en miroir du disque racine.
-
Attribution de nom unique : vous pouvez avoir des métapériphériques Solstice DiskSuite locaux, des volumes Solaris Volume Manager locaux, ou des volumes VxVM utilisés en tant que périphériques sur lesquels sont montés des systèmes de fichiers /global/.devices/node@id_noeud. Si tel est le cas, le nom de chaque métapériphérique local ou volume local doit être unique dans tout le cluster.
-
Listes des noeuds : pour être à haute disponibilité, un groupe de périphériques de disques doit comporter des listes de maîtres potentiels et une stratégie de repli en cas de panne identiques à celles du groupe de ressources associé. Ou, si un groupe de ressources évolutif utilise plus de noeuds que le groupe de périphériques de disques associé, la liste des noeuds du groupe de ressources évolutif doit être un surensemble de la liste des noeuds du groupe de périphériques de disques. Reportez-vous aux informations de planification de ressources dans le document Sun Cluster Data Services Planning and Administration Guide for Solaris OS pour de plus amples informations sur les listes des noeuds.
-
Disques multiports : vous devez connecter ou relier par un port tous les disques utilisés pour monter un groupe de périphériques au sein du cluster à tous les noeuds configurés dans la liste des noeuds de ce groupe de périphériques. Le logiciel Solstice DiskSuite/Solaris Volume Manager peut contrôler automatiquement cette connexion au moment où des disques sont ajoutés à un ensemble de disques. Cependant, les groupes de disques VxVM configurés ne sont associés à aucun ensemble de noeuds particulier.
-
Disques hot spare : vous pouvez utiliser des disques hot spare pour accroître la disponibilité, mais ils ne sont pas nécessaires.
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/Solaris Volume Manager
Tenez compte des points suivants lorsque vous planifiez des configurations Solstice DiskSuite/Solaris Volume Manager.
-
Noms des métapériphériques locaux ou des volumes : le nom de chaque métapériphérique Solstice DiskSuite ou volume Solaris Volume Manager doit être unique dans tout 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 ensemble de disques configuré avec exactement deux chaînes de disque et géré par exactement deux noeuds doit comporter des médiateurs Solstice DiskSuite/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 noeuds et des adaptateurs d'interface. Respectez les règles suivantes pour configurer les médiateurs à deux chaînes :
-
Vous devez configurer chaque ensemble de disques avec exactement deux noeuds en tant qu'hôte médiateur.
-
Vous devez utiliser les deux mêmes noeuds pour tous les ensembles de disques nécessitant des médiateurs. Ces deux noeuds doivent maîtriser ces ensembles de disques.
-
Vous ne pouvez pas configurer de médiateurs pour les ensembles de disques qui ne répondent pas à ces critères (deux chaînes et deux hôtes).
Reportez-vous à la page de manuel mediator( 7D) pour de plus amples informations.
-
-
Paramètres : tous les métapériphériques Solstice DiskSuite ou les volumes Solaris Volume Manager utilisés par chaque groupe de disques sont créés à l'avance, au moment de l'initialisation de la reconfiguration. Cette reconfiguration se base sur les paramètres de configuration existant dans le fichier /kernel/drv/md.conf.
Attention : les fichiers /kernel/drv/md.conf de tous les noeuds du cluster doivent être identiques, indépendamment du nombre d'ensembles de disques desservis par chaque noeud. Le non-respect de cette consigne peut occasionner de graves erreurs de Solstice DiskSuite/Solaris Volume Manager et un risque de pertes de données.
Vous devez modifier les champs nmd et md_nsets comme indiqué ci-dessous pour prendre en charge une configuration Sun Cluster.
-
md_nsets : ce champ définit le nombre total d’ensembles de disques pouvant être créés pour qu’un système réponde aux besoins du cluster. Réglez la valeur de md_nsets sur le nombre d'ensembles de disques envisagé du cluster plus un supplémentaire. Solstice DiskSuite/Solaris Volume Manager utilise l'ensemble de disques supplémentaire pour gérer les disques privés sur l'hôte local. Les disques privés sont ces métapériphériques ou volumes absents de l'ensemble de disques local.
Le nombre maximal d’ensembles de disques autorisés par cluster est de 32. Ce nombre comprend 31 ensembles de disques d’utilisation générale plus un ensemble de disques pour la gestion de disques privés. La valeur par défaut de md_nsets est 4.
-
nmd : ce champ définit le nombre de métapériphériques ou de volumes créés par ensemble de disques. Définissez sa valeur sur le nombre maximum prévu de métapériphériques ou volumes utilisés par l'un des ensembles de disques du cluster. Par exemple, si un cluster utilise 10 métapériphériques ou volumes dans ses 15 premiers ensembles de disques, mais 1000 dans le 16ème, la valeur de nmd doit être au moins égale à 1000. Cette valeur doit également être suffisamment importante pour s’assurer qu’il existe assez de nombres pour l’ID de chaque 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 d’un nom de métapériphérique ou de volume par ensemble de disques est de 8192. La valeur par défaut de 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 noeud. 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 nmdet 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.
Reportez-vous à la rubrique “System and Startup Files” du document Solstice DiskSuite 4.2.1 Reference Guide ou à la rubrique “System Files and Startup Files” in Solaris Volume Manager Administration Guide pour obtenir de plus amples informations sur le fichier md.conf.
-
SPARC: recommandations relatives au logiciel VERITAS Volume Manager
Tenez compte des points suivants lorsque vous planifiez des configurations VERITAS Volume Manager (VxVM) :
-
Attribution de noms basée sur la délimitation : l’attribution de noms basée sur la délimitation est une fonction introduite dans la version 3.2 de VxVM. Si vous l’utilisez pour des périphériques, assurez-vous d’utiliser des noms de périphériques compatibles sur tous les noeuds du cluster partageant 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 noeuds. Des noms incompatibles n'ont pas d'incidence sur le comportement correct du cluster. Cependant, cela complique considérablement l'administration du cluster et augmente grandement le risque d'erreurs de configuration, pouvant éventuellement engendrer des pertes de données.
-
Groupe de disques racine : vous devez créer un groupe de disques racine par défaut sur chaque noeud. Le 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 noeud.
-
-
Encapsulage : les disques à encapsuler doivent posséder deux entrées de table de tranches de disque libres.
-
Nombre de volumes : lors de la création d'un groupe de périphériques de disques, estimez le nombre maximal de volumes que ce groupe 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 du journal des zones modifiées permet une récupération plus rapide des volumes après un échec de noeud. Il peut cependant réduire le débit d'E/S.
-
DMP (multi-acheminement dynamique) :
l'utilisation du seul multi-acheminement dynamique (DMP) pour la gestion de plusieurs chemins d'E/S par noeud vers le stockage partagé du cluster n'est pas prise en charge. Elle ne l'est que pour les configurations suivantes :
-
chemin d'E/S unique par noeud 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 noeud vers le stockage partagé du cluster.
-
Journalisation de système de fichiers
La journalisation est obligatoire pour tous les systèmes de fichiers de cluster. Le logiciel Sun Cluster prend en charge les choix suivants en matière de journalisation de système de fichiers :
-
Journalisation UFS Solaris : pour de plus amples informations, reportez-vous à la page de manuel mount_ufs(1M).
-
Journalisation de trans-métapériphériques Solstice DiskSuite ou Journalisation de volumes transactionnels Solaris Volume Manager : reportez-vous à la rubrique “Creating DiskSuite Objects” in Solstice DiskSuite 4.2.1 User's Guide ou à la rubrique “Transactional Volumes (Overview)” in Solaris Volume Manager Administration Guide pour de plus amples informations.
-
SPARC : journalisation VERITAS File System (VxFS) : consultez la page de manuel mount_vxfs fournie avec le logiciel VxFS pour de plus amples informations.
Le tableau suivant répertorie les journalisations de systèmes de fichiers prises en charge par chaque gestionnaire de volumes.
Tableau 1–6 Tableau des journalisations de système de fichiers prises en charge|
Gestionnaire de volumes |
Journalisation de système de fichiers prise en charge |
|---|---|
|
Solstice DiskSuite/Solaris Volume Manager |
Journalisation UFS Solaris, Journalisation de trans-métapériphériques Solstice DiskSuite, Journalisation de volumes transactionnels Solaris Volume Manager ou Journalisation VxFS |
|
SPARC : VERITAS Volume Manager |
Journalisation UFS Solaris, Journalisation VxFS |
Prenez en compte les points suivants lorsque vous faites votre choix entre la Journalisation UFS Solaris et la Journalisation de trans-métapériphériques Solstice DiskSuite/Journalisation de volumes transactionnels Solaris Volume Manager :
-
La Journalisation de volumes transactionnels Solaris Volume Manager (anciennement Journalisation de trans-métapériphériques Solstice DiskSuite) doit être supprimée de l'environnement d'exploitation Solaris dans une prochaine version de Solaris. 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 au moyen de 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 Solaris Volume Manager de transaction 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 à la configuration de tolérer les défaillances d'un disque unique. Le logiciel Sun Cluster nécessite la duplication de tous les disques multihôtes sur les périphériques d'extension de disque. 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.
Tenez compte des points suivants lors de la mise en miroir des disques multihôtes :
-
Périphériques d'extension de disque distincts : chaque sous-miroir d'un miroir ou d'un plex donné doit résider dans un périphérique d'extension de disque multihôte différent.
-
Espace disque : la mise en miroir double l'espace disque nécessaire.
-
Mise en miroir à trois voies : les logiciels Solstice DiskSuite/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.
-
Nombre de métapériphériques ou de volumes : sous Solstice DiskSuite/Solaris Volume Manager, les miroirs sont en fait d'autres métapériphériques Solstice DiskSuite ou volumes Solaris Volume Manager tels que des concaténations ou des bandes. Les grandes configurations peuvent comporter un grand nombre de métapériphériques ou de volumes.
-
Tailles de disques différentes : si vous effectuez une mise en miroir vers un disque de taille différente, votre capacité de mise en miroir se limite à la taille du plus petit sous-miroir ou plex.
Pour de plus amples informations sur les disques multihôtes, reportez-vous aux documents “Multihost Disk Storage” in Sun Cluster Overview for Solaris OS et Sun Cluster Concepts Guide for Solaris OS.
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 root (/), /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.
Reportez-vous à la documentation de votre gestionnaire de volumes, ainsi qu'aux rubriques Installation et configuration du logiciel Solstice DiskSuite/Solaris Volume Manager ou SPARC: installation et configuration du logiciel VxVM pour connaître la procédure de mise en miroir du disque racine.
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/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/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 ultérieures sont alors effectuées à l’aide du disque racine principal spécifié dans le champ 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/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. Certaines commandes administratives de Solstice DiskSuite/Solaris Volume Manager peuvent avoir modifié le fichier /etc/system alors que le disque racine principal était 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