Cette section fournit les directives suivantes sur la planification de la gestion des volumes de votre configuration en cluster :
Le logiciel Oracle Solaris Cluster utilise le gestionnaire de volumes pour regrouper les disques en groupes de périphériques pouvant être gérés comme une seule unité. Il faut installer le logiciel Solaris Volume Manager sur tous les noeuds du cluster.
Consultez la documentation de votre gestionnaire de volumes et la section Configuration du logiciel Solaris Volume Manager pour des instructions relatives à l'installation et à la configuration du logiciel de gestion des volumes. Pour plus d'informations sur le recours à la gestion des volumes dans une configuration de cluster, reportez-vous aux sections Multihost Devices du manuel Oracle Solaris Cluster 4.3 Concepts Guide et Device Groups du manuel Oracle Solaris Cluster 4.3 Concepts Guide.
Tenez compte des instructions générales suivantes lorsque vous configurez vos disques à l'aide du gestionnaire de volumes :
RAID logiciel – Le logiciel Oracle Solaris Cluster ne prend pas en charge le RAID logiciel 5.
Disques multihôtes mis en miroir - Vous devez mettre en miroir tous les disques multihôtes des unités d'expansion de disque. Reportez-vous à la section Directives concernant la mise en miroir des disques multihôtes pour connaître les directives relatives à la mise en miroir des disques multihôtes. Il est inutile de procéder à la mise en miroir des logiciels si le périphérique de stockage fournit un RAID matériel ainsi que des chemins redondants vers les périphériques.
Racine mise en miroir - La mise en miroir du pool root ZFS assure la haute disponibilité, mais cette mise en miroir n'est pas obligatoire. Reportez-vous à la section Directives concernant la mise en miroir pour des instructions qui vous aideront à mettre en miroir le pool root ZFS.
Listes de noeuds – Pour assurer la haute disponibilité d'un groupe de périphériques, les listes de noeuds maîtres potentiels et la règle de basculement doivent être identiques dans tous les groupes de ressources associés. Ou si un groupe de ressources évolutives utilise davantage de noeuds que son groupe de périphériques associé, faites de la liste de noeuds du groupe de ressources évolutif un surensemble de la liste de noeuds du groupe de périphériques. Pour plus d'informations sur les listes de noeuds, reportez-vous aux informations de planification du groupe de ressources du Guide de planification et d’administration des services de données d’Oracle Solaris Cluster 4.3.
Disques multihôtes – Vous devez connecter ou insérer tous les périphériques utilisés dans la construction d'un groupe de périphériques dans tous les noeuds configurés dans la liste des noeuds de ce groupe de périphériques. Le logiciel Solaris Volume Manager peut rechercher cette connexion automatiquement au moment où les périphériques sont ajoutés à un ensemble de disques.
Disques hot spare – Vous pouvez utiliser des disques hot spare pour augmenter la disponibilité, mais ils ne sont pas requis.
Reportez-vous à la documentation du gestionnaire de volumes pour connaître les recommandations sur l'organisation des disques et les éventuelles restrictions supplémentaires.
Tenez compte des points suivants lorsque vous planifiez les configurations Solaris Volume Manager :
Dénomination unique – Les noms d'ensembles de disques doivent être uniques dans le cluster.
Noms d'ensemble de disques réservés – N'attribuez pas le nom admin ou shared à un ensemble de disques.
Médiateurs à deux chaînes – Une chaîne de disques se compose d'un boîtier de disques, de ses disques physiques, des câbles reliant le boîtier aux hôtes et d'adaptateurs d'interface. Chaque ensemble de disques configuré avec exactement deux chaînes de disque et géré par exactement deux ou trois hôtes Oracle Solaris s'appelle un ensemble de disques à deux chaînes. Des médiateurs à deux chaînes Solaris Volume Manager doivent être configurés pour ce type d'ensemble de disques. Pour configurer des médiateurs à deux chaînes, observez les règles suivantes :
Vous devez configurer chaque ensemble de disques sur deux ou trois hôtes agissant comme hôtes médiateurs.
Vous devez utiliser les hôtes pouvant gérer un ensemble de disques en tant que des médiateurs pour cet ensemble de disques. Si vous disposez d'un cluster campus, vous pouvez également configurer un troisième noeud ou un noeud non clusterisé sur le réseau du cluster sous la forme d'une troisième hôte médiateur pour améliorer la disponibilité.
Les médiateurs ne peuvent pas être configurés pour des ensembles de disques ne remplissant pas les conditions requises (deux chaînes et deux hôtes).
Pour plus d’informations, reportez-vous à la page de manuel mediator(7D).
La journalisation est requise pour les systèmes de fichiers du cluster UFS . Le logiciel Oracle Solaris Cluster prend en charge la journalisation UFS d'Oracle Solaris. Reportez-vous à la page de manuel mount_ufs(1M) pour plus d'informations.
Cette section fournit les directives suivantes sur la planification de la mise en miroir de votre configuration en cluster
La mise en miroir de tous les disques multihôtes dans une configuration Oracle Solaris Cluster permet à la configuration de tolérer les pannes sur des périphériques isolés. Le logiciel Oracle Solaris Cluster requiert la mise en miroir de tous les disques multihôtes dans les unités d'expansion. Il est inutile de procéder à la mise en miroir des logiciels si le périphérique de stockage fournit un RAID matériel ainsi que des chemins redondants vers les périphériques.
Considérez les points suivants lorsque vous mettez en miroir des disques multihôtes :
Unités d'expansion de disque séparées - Chaque sous-miroir d'un miroir ou plex donné doit résider sur une unité d'expansion multihôte différente.
Espace disque - La mise en miroir double la quantité d'espace disque nécessaire.
Mise en miroir triple – Le logiciel Solaris Volume Manager prennent en charge la mise en miroir triple s. Cependant, Oracle Solaris Cluster ne nécessite qu'une mise en miroir à deux voies.
Tailles de périphérique différentes – Si vous placez la copie miroir sur un périphérique de taille différente, votre capacité de mise en miroir est limitée à la taille du sous-miroir ou du plex le plus petit.
Pour plus d'informations sur les disques multihôtes, reportez-vous à la section Multihost Devices du manuel Oracle Solaris Cluster 4.3 Concepts Guide.
Oracle Solaris ZFS est le système de fichiers root par défaut de la version Oracle Solaris. Pour connaître les instructions relatives à la mise en miroir du pool root ZFS, reportez-vous à la section Configuration d’un pool root mis en miroir (SPARC ou x86/VTOC) du manuel Gestion des systèmes de fichiers ZFS dans OracleSolaris 11.3. Reportez-vous également au Chapitre 6, Gestion du pool root ZFS du manuel Gestion des systèmes de fichiers ZFS dans OracleSolaris 11.3 pour obtenir des informations sur la procédure de gestion des différents composants du pool root.
Pour une disponibilité maximale, mettez en miroir la racine (/), /usr, /var, /opt et swap sur les disques locaux. Toutefois, le logiciel Oracle Solaris Cluster ne requiert pas la mise en miroir du pool root ZFS.
Tenez compte des points suivants lorsque vous prenez la décision de mettre en miroir ou non le pool root ZFS :
Disque d'initialisation - Vous pouvez configurer le miroir en tant que pool root amorçable. Vous pouvez ensuite effectuer une initialisation à partir du miroir si le disque d'initialisation principal tombe en panne.
Sauvegardes - Que vous ayez mis en miroir le pool root ou non, il est recommandé d'effectuer des sauvegardes régulières de la racine. La mise en miroir seule ne protège pas des erreurs de gestion. Seul un plan de sauvegarde vous permet de restaurer des fichiers qui ont été modifiés ou supprimés accidentellement.
Périphériques de quorum – N'utilisez pas un disque configuré en tant que périphérique de quorum pour mettre en miroir un pool root.
Contrôleurs séparés - La plus haute disponibilité implique la mise en miroir du pool root sur un contrôleur séparé.