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 :
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 nœuds à un cluster existant Si vous le souhaitez, vous pouvez installer et configurer le logiciel Sun StorEdge QFS. |
Sun StorEdge QFS and Sun StorEdge SAM-FS Software Installation and Configuration Guide |
|
Installation et configuration du logiciel Solstice DiskSuiteTM ou 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 Service 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 9/04 |
Planification du SE 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 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.
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 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 :
-
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 man 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 man pmconfig(1M) et power.conf(4) pour de plus amples informations.
À propos des groupes de logiciels Solaris
Le logiciel Sun Cluster 3.1 9/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 Interface de programmation d'application de mémoire partagée distante (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 aux pages man Solaris 8 Section (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 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 au tableau approprié de la Fiche de travail de configuration des systèmes de fichiers locaux.
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 – Le total combiné d'espace swap 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 de 512Mo qui sera utilisé par l'utilitaire scinstall(1M) avec les périphériques globaux.
-
Gestionnaire de volumes : créez une partition de 20 Mo sur une tranche en fin de disque (tranche 7) destinée au 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 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 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 d'espace dans le système de fichiers root (/). Le logiciel Solstice DiskSuite ou 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é 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. 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_nœud, id_nœud représente le nombre assigné à un nœud 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 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 root, 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 disposant de 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 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 |
Sommaire |
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 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ée |
- |
Tranche libre disponible pour l'encapsulation du disque root sous VxVM. |
|
5 |
inutilisée |
- |
- |
|
6 |
inutilisée |
- |
- |
|
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 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 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 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” du document Sun Cluster 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” du document 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 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 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 également ces adresses IP au fichier /etc/inet/hosts local sur chacun des nœuds du 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 du 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 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 Service 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 nœuds de cluster.
-
Vous pouvez disposer d'autant de connexions supplémentaires au réseau public que votre configuration matérielle le permet.
-
Le logiciel Sun Cluster prend en charge les adresses IPv4 et IPv6 sur le réseau public dans le cadre des services de données évolutifs ou de basculement. En revanche, il ne prend pas en charge les communications IPv6 sur réseaux privés.
-
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 automatiquement un groupe Multiacheminement sur réseau IP à adaptateur unique pour chacun des adaptateurs du réseau public. Pour modifier ces groupes de secours une fois l'installation effectuée, suivez la procédure indiquée sous la rubrique “Deploying Network Multipathing” du document IP Network Multipathing Administration Guide (Solaris 8) ou sous la rubrique “Administering Network Multipathing (Task)” du System Administration Guide: IP Services (Solaris 9).
Voir la rubrique Groupes Multiacheminement sur réseau IP pour obtenir des instructions sur la planification de groupes de sauvegarde d'adaptateurs de réseau public. Pour de plus amples informations sur les interfaces de réseau public, reportez-vous au document Sun Cluster Concepts Guide for Solaris OS.
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 prendre en considération les points suivants :
-
Aucun nœud Sun Cluster ne peut être le client NFS d'un système de fichiers exporté Sun Cluster HA pour NFS contrôlé sur un nœud du même cluster. Un tel montage croisé de Sun Cluster HA pour NFS est interdit. Utilisez le système de fichiers de 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é par le biais du système NFS. Sinon, un blocage local (par exemple, flock(3UCB) ou fcntl (2)) risque d'empêcher le gestionnaire de verrouillage (lockd) de redémarrer. 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 Secure NFS, ni l'utilisation de Kerberos avec NFS. Plus particulièrement, Sun Cluster ne prend pas en charge les options secure et kerberos dans le sous-système share_nfs(1M).
En revanche, Sun Cluster prend en charge l'utilisation de ports sécurisés avec NFS. Pour en bénéficier, vous devez ajouter l'entrée set nfssrv:nfs_portmon=1 dans le fichier /etc/system sur les nœuds du cluster.
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+. Les nœuds 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 de processus de priorité élevée dans des classes de programmation 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. D'autres 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 CPU 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 travail relative à la configuration appropriée.
Tableau 1–4 Fiches de travail relatives à la configuration de Sun Cluster|
Fiche de configuration |
Emplacement |
|---|---|
|
Tableau 2–2 (valeurs par défaut) ou Tableau 2–3 (personnalisation) |
Procédure de configuration du logiciel Sun Cluster sur tous les nœuds(scinstall) |
|
Installation et configuration du logiciel Sun Cluster (SunPlex Installer) |
|
|
Installation de Solaris et du logiciel Sun Cluster (JumpStart) |
|
|
Procédure de configuration du logiciel Sun Cluster sur d'autres nœuds du cluster (scinstall) |
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 à nœud unique, le nom du nœud 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 à nœud unique.
Le logiciel Sun Cluster utilise le réseau privé pour les communications internes entre les nœuds. 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 nœud 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 ceux de votre choix si l'adresse par défaut est déjà utilisée dans l'entreprise.
Remarque –
Une fois l'exécution de l'utilitaire d'installation (scinstall, SunPlex Installer 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 dans le cadre d'interconnexions privées.
Bien que l'utilitaire scinstall vous permette d'indiquer un autre masque de réseau, il est préférable d'accepter celui par défaut, à savoir 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 plus d'informations sur les réseaux privés, reportez-vous à la rubrique “Planning Your TCP/IP Network” du manuel System Administration Guide, Volume 3 (Solaris 8) ou à la rubrique “Planning Your TCP/IP Network (Task)” du manuel System Administration Guide: IP Services (Solaris 9).
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é. 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_nœud-priv, où id_nœud est le numéral 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 membre du cluster. Une fois le cluster configuré, vous pouvez modifier 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 à nœud unique. Cependant, si vous prévoyez d'ajouter par la suite des nœuds à une configuration de cluster à nœud 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 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 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 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. 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.
Prenez en considération les instructions et contraintes suivantes :
-
Adaptateurs SCI SBus : l'interface SCI (Scalable Coherent Interface) SBus n'est pas prise en charge dans le cadre d'une interconnexion en cluster. En revanche, l'interface SCI–PCI l'est.
-
Interfaces réseau logique : leur utilisation est réservée à Sun Cluster.
Reportez-vous aux pages man 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 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.
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” des documents Sun Cluster Overview for Solaris OS et Sun Cluster Concepts Guide for Solaris OS.
Groupes Multiacheminement sur réseau IP
Ajoutez ces informations de planification à la Fiche de travail relative aux réseaux publics.
Les groupes Multiacheminement sur réseau IP, 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 multiacheminement.
-
Pour les groupes de multiacheminement contenant au moins deux adaptateurs, il faut configurer une adresse IP de test pour chaque adaptateur du groupe. Si un groupe de multiacheminement 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, la propriété TRACK_INTERFACES_ONLY_WITH_GROUPS doit être paramétrée sur 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'applique à la fois aux environnements cluster et non-cluster. Pour plus d'informations sur Multiacheminement sur réseau IP, vous pouvez donc vous reporter au document Solaris approprié :
-
pour le système d'exploitation Solaris 8, voir la rubrique “Deploying Network Multipathing” du manuel IP Network Multipathing Administration Guide ;
-
pour Solaris 9, voir la rubrique “Administering Network Multipathing (Task)” du manuel System Administration Guide: IP Services.
Consultez également la rubrique “IP Network Multipathing Groups” des documents 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 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. Vous pouvez configurer les 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 à nœud unique.
Tenez compte des points suivants lorsque vous planifiez des périphériques de quorum.
-
Minimum : un cluster à deux nœuds doit disposer d'au moins un disque partagé désigné comme périphérique de quorum. 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 plus d'informations sur les périphériques de quorum, reportez-vous à la rubrique “Quorum and Quorum Devices” du manuel Sun Cluster Concepts Guide for Solaris OS et à la rubrique “ Quorum Devices” du manuel Sun Cluster Overview 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 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 : ils ne sont pas pris en charge dans les systèmes de fichiers de cluster.
-
Système de fichiers Loopback (LOFS) : Sun Cluster ne prend pas en charge l'utilisation du système de fichiers Loopback (LOFS) sur les nœuds de cluster.
-
Points finaux de communication : le système de fichiers du cluster ne prend en charge aucune des fonctions de système de fichiers du logiciel Solaris permettant de placer un point final de communication dans l'espace de noms du système de fichiers.
-
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 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 ou 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 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 : contrainte relative au montage de VxFS : si vous utilisez Système de fichiers VERITAS (VxFS), vous devez monter et démonter globalement un système de fichiers VxFS à partir du 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.
-
Le système de fichiers de cluster Sun Cluster 3.1 ne prend pas en charge les fonctions VxFS ci-dessous. 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 VxFS spécifiques :
-
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 noeud sélectionné.
Toutes les autres fonctions et options VxFS prises en charge dans un système de fichiers 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.
-
-
Imbrication des points de montage : normalement, vous ne devriez pas imbriquer les points de montage des systèmes de fichiers de cluster. Par exemple, vous ne devez pas définir 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–5 Gestionnaires de volumes pris en charge par Sun Cluster|
Logiciel de gestionnaire de volume |
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. |
|
SPARC : VxVM avec la fonction cluster |
Vous devez installer VxVM,et en posséder la licence, avec la fonction cluster sur tous les nœuds du cluster. |
|
SPARC : VxVM sans la fonction 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 utiliser le logiciel Solstice DiskSuite ou Solaris Volume Manager pour gérer les disques locaux de chaque nœud. Les disques locaux incluent le disque root. 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 ou 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 :
-
Logiciel RAID : Sun Cluster ne prend pas en charge le logiciel RAID.
-
Disques multihôtes mis en miroir : vous devez mettre tous les disques multihôtes en miroir sur les unités d'extension de disque. 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 périphériques redondants.
-
Root mis en miroir : la mise en miroir du disque root assure une disponibilité élevée, 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 root.
-
Attribution de noms uniques : vous pouvez disposer de métapériphériques Solstice DiskSuite locaux, de volumes Solaris Volume Manager locaux ou de volumes VxVM utilisés en tant que périphériques sur lesquels sont montés les systèmes de fichiers /global/.devices/node@id_nœud. 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 nœuds : 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 nœuds que le groupe de périphériques de disques associé, la liste des nœuds du groupe de ressources évolutif doit être un surensemble de la liste des nœuds du groupe de périphériques de disques. Reportez-vous aux informations de planification de ressources dans le document Sun Cluster Data Service Planning and Administration Guide for Solaris OS pour de plus amples informations sur les listes des nœuds.
-
Disques multihôtes : vous devez connecter ou relier par un port, tous les périphériques utilisés dans le cadre de l'élaboration d'un groupe de périphériques au sein du cluster à tous les nœuds configurés dans la liste de nœuds du 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.
-
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 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).
Reportez-vous à la page man mediator( 7D) pour de plus amples informations.
-
-
Paramètres /kernel/drv/md.conf : tous les métapériphériques Solstice DiskSuite ou tous les volumes Solaris Volume Manager utilisés par chacun des jeux de disques sont créés à l'avance, lors de l'initialisation de la reconfiguration. Cette reconfiguration se base sur les paramètres de configuration existant dans le fichier /kernel/drv/md.conf.
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.
Vous devez modifier les champs nmd et md_nsets comme indiqué ci-dessous pour prendre en charge une configuration Sun Cluster.
-
md_nsets : le champ md_nsets définit le nombre total de jeux de disques pouvant être créés afin qu'un système réponde 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. Les disques privés sont les métapériphériques ou volumes absents du jeu de disques 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 le nombre de métapériphériques ou de volumes créés pour chacun des jeux de disques. Définissez sa valeur sur le nombre maximum prévu de métapériphériques ou de volumes utilisés par l'un des jeux de disques du cluster. Par exemple, si un cluster utilise 10 métapériphériques ou volumes dans les 15 premiers jeux de disques, mais 1000 métapériphériques ou volumes dans le 16e jeu, vous devez paramétrer le champ nmd sur une valeur supérieure ou égale à 1000. De même, cette valeur doit être suffisamment grande afin de garantir qu'il existe au moins autant de numéros que de noms IDP 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.
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” du document 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) :
-
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, 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 root : si vous utilisez VxVM 3.5 ou version antérieure, vous devez créer un groupe de disques root sur chacun des nœuds. Pour VxVM 4.0, la création d'un groupe de disques root est facultative.
Un groupe de disques root peut être créé sur les disques suivants :
-
le disque root, devant être encapsulé ;
-
un ou plusieurs disques locaux non root, pouvant être encapsulés ou initialisés ;
-
une combinaison de disques root et de disques locaux non root.
Le groupe de disques root doit être local sur le nœud.
-
-
Groupes de disques root simples : les groupes de disques root simples (rootdg créé sur une seule tranche du disque root) ne sont pas pris en charge en tant que types de disques avec le logiciel VxVM sur Sun Cluster. Il s'agit d'une restriction générale du logiciel VxVM.
-
Encapsulation : les disques à encapsuler doivent disposer de 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 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 multiacheminement 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 de plus amples informations, reportez-vous à la documentation d'installation de VxVM.
Journalisation de système de fichiers
La journalisation des systèmes de fichiers de cluster UFS et VxFS est requise. 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 plus d'informations, reportez-vous à la page man mount_ufs(1M).
-
Solstice DiskSuite Journalisation de trans-métapériphériques ou Solaris Volume Manager Journalisation de volumes de transaction : pour plus d'informations, reportez-vous à la rubrique “Creating DiskSuite Objects” du manuel Solstice DiskSuite 4.2.1 User's Guide ou à la rubrique “Transactional Volumes (Overview)” du manuel Solaris Volume Manager Administration Guide.
-
Journalisation SPARC : Système de fichiers VERITAS (VxFS) : pour plus d'informations, reportez-vous à la page man mount_vxfs fournie avec le logiciel VxFS.
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 ou Solaris Volume Manager |
|
|
SPARC : VERITAS Volume Manager |
|
Prenez en compte les points suivants lorsque vous faites votre choix entre la Journalisation UFS Solaris et la Solstice DiskSuite Journalisation de trans-métapériphériques/Solaris Volume Manager Journalisation de volumes de transaction pour les systèmes de fichiers de cluster UFS :
-
Solaris Volume Manager Journalisation de volumes de transaction (anciennement Solstice DiskSuite Journalisation de trans-métapériphériques) doit être supprimée du système 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 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 root
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.
Tenez compte des points suivants lors de la mise en miroir des disques multihôtes :
-
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.
-
Nombre de métapériphériques ou de volumes : sous Solstice DiskSuite ou 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, la 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 root
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 root et dupliquez les sous-disques générés. Le logiciel Sun Cluster n'impose pas de mise en miroir du disque root.
Avant de décider de mettre ou non le disque root 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 root, 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 ou Solaris Volume Manager ou SPARC: Installation et configuration du logiciel VxVM pour connaître la procédure de mise en miroir du disque root.
Tenez compte des points suivants pour décider d'appliquer ou non la mise en miroir du disque root :
-
Disque d'initialisation : vous pouvez paramétrer le miroir afin qu'il devienne un disque root 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 root complique l'administration du système, ainsi que l'initialisation en mode mono-utilisateur.
-
Sauvegardes : qu'il soit ou non mis en miroir, le disque root 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 root 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 root doit être mis en miroir sur un contrôleur distinct.
-
Disque root secondaire : avec un disque root mis en miroir, vous pouvez continuer à travailler à partir du disque root secondaire (miroir) en cas de panne du disque root principal. Plus tard, le disque root 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 root 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 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 root (miroir) secondaire, elles ne seront pas reflétées sur le disque root 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 ou Solaris Volume Manager peuvent avoir modifié le fichier /etc/system alors que le disque root principal était hors service.
Le programme d'initialisation ne vérifie pas si le système s'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