Ignorer les liens de navigation | |
Quitter l'aperu | |
Transition d'Oracle Solaris 10 vers Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library (Français) |
1. Transition d'Oracle Solaris 10 vers une version d'Oracle Solaris 11 (présentation)
2. Transition vers une méthode d'installation d'Oracle Solaris 11
4. Gestion des fonctions de stockage
Comparaison des configurations Solaris Volume Manager et des configurations ZFS
Pratiques recommandées pour les pools de stockage ZFS
Création de pools de stockage ZFS pratiques
Remplacement du démon cible iSCSI par COMSTAR
5. Gestion des systèmes de fichiers
6. Gestion des logiciels et des environnements d'initialisation
7. Gestion de la configuration réseau
8. Gestion de la configuration système
10. Gestion des versions d'Oracle Solaris dans un environnement virtuel
11. Gestion des comptes et des environnements utilisateur
ZFS utilise un modèle de stockage de pool où les périphériques de stockage sont regroupés dans un pool de stockage. Les systèmes de fichiers situés à l'intérieur du pool de stockage utilisent tout le stockage présent dans le pool.
Les sections suivantes décrivent les pratiques recommandées pour la création, le contrôle et le dépannage de pools de stockage ZFS.
Configuration requise spécifique pour les périphériques de pools root et les disques d'initialisation
Pratiques générales relatives à la création de pools root
Le pool root doit être créé sous la forme d'une configuration en miroir ou d'une configuration à disque unique. Les configurations RAID-Z ou entrelacées ne sont pas prises en charge. Vous ne pouvez pas ajouter d'autres disques mis en miroir pour créer plusieurs périphériques virtuels de niveau supérieur à l'aide de la commande zpool add. Toutefois, vous pouvez étendre un périphérique virtuel mis en miroir à l'aide de la commande zpool attach.
Un pool root ne peut pas avoir de périphérique de journal distinct.
Les propriétés d'un pool peuvent être définies lors d'une installation AI à l'aide de la syntaxe de mot-clé pool_options, mais l'algorithme de compression gzip n'est pas pris en charge sur les pools root.
Ne renommez pas le pool root une fois qu'il a été créé par une installation initiale. Si vous renommez le pool root, cela peut empêcher l'initialisation du système.
Ne créez pas de pool root sur une clé USB pour un système de production, car les disques de pool roots sont vitaux pour un fonctionnement continu, en particulier dans un environnement professionnel. Envisagez d'utiliser les disques internes d'un système pour le pool root, ou au moins d'utiliser des disques de la même qualité que celle que vous utiliseriez pour vos données non root. De plus, une clé USB peut s'avérer trop petite pour gérer une taille de fichier de vidage équivalente à la moitié de la taille de la mémoire physique.
Vous pouvez envisager d'isoler les composants de pools root des données de pools non root.
Pratiques de création de pools non root – Créez des pools non root avec des disques entiers à l'aide de l'identificateur d*. N'utilisez pas l'identificateur p*.
ZFS fonctionne mieux sans logiciel de gestion de volumes supplémentaire.
Pour de meilleures performances, utilisez des disques individuels ou, tout au moins, des LUN constitués d'un petit nombre de disques. En apportant à ZFS davantage de visibilité sur le paramétrage des LUN, vous lui permettez de mieux planifier les E/S.
Pools de stockage mis en miroir : consomment davantage d'espace disque mais présentent de meilleures performances pour les petites lectures aléatoires. Par exemple :
# zpool create tank mirror c1d0 c2d0 mirror c3d0 c4d0
Les pools de stockage mis en miroir sont également plus flexibles, car vous pouvez les séparer, les joindre, et remplacer des périphériques déjà présents dans le pool.
Pools de stockage RAID-Z : ces pools peuvent être créés avec 3 stratégies de parité, d'une parité égale à 1 (raidz), 2 (raidz2) ou 3 (raidz3).
Une configuration RAID-Z optimise l'espace disque et généralement effectue bien lorsque les données sont écrites et lues en gros blocs (128 Ko ou plus). Créez une configuration RAIDZ à parité simple (raidz) à 3 disques (2+1).
Une configuration RAIDZ-2 améliore la disponibilité des données et fournit les mêmes performances qu'une configuration RAID-Z. En outre, sa valeur de temps moyen entre pertes de données MTTDL (Mean Time To Data Loss) est nettement meilleure que celle d'une configuration RAID-Z ou de miroirs bidirectionnels. Créez une configuration RAID-Z à double parité RAID-Z (raidz2) à 6 disques (4+2).
La configuration RAIDZ-3 optimise l'espace disque et offre une excellente disponibilité car elle peut résister à 3 pannes de disque. Créez une configuration RAID-Z à triple parité (raidz3) à 8 disques (5+3).
Pools non redondants : si vous créez un pool non redondant, un message s'affiche, semblable à l'exemple suivant :
# zpool create pond c8t2d0 c8t3d0 'pond' successfully created, but with no redundancy; failure of one device will cause loss of the pool
Il n'est pas recommandé de créer un pool sans redondance car une panne de périphérique peut entraîner l'impossibilité de récupérer les données. Envisagez plutôt de créer un pool de stockage ZFS avec redondance. Par exemple :
# zpool create pond mirror c8t2d0 c8t3d0
Assurez-vous que la capacité d'un pool est inférieure à 90 %, pour obtenir de meilleures performances. Contrôlez l'espace des pools et des systèmes de fichiers pour vous assurer qu'il n'est pas entièrement utilisé. Il vous est conseillé d'envisager l'utilisation quotas et réservations ZFS pour vous assurer que l'espace pour système de fichiers ne dépasse pas 90 % capacité du pool.
Exécutez régulièrement la commande zpool scrub pour identifier des problèmes d'intégrité des données :
Si vous utilisez des unités de qualité grand public, envisagez de planifier un nettoyage hebdomadaire.
Si vous utilisez des unités de qualité professionnelle, envisagez de planifier un nettoyage mensuel.
Vous devez également exécuter un nettoyage avant de remplacer des périphériques afin de vérifier que tous les périphériques sont opérationnels.
Utilisez zpool status sur une base hebdomadaire pour surveiller pool et le pool statut d'un périphérique. Utilisez également fmdump ou fmdump -eV pour voir si un périphérique erreurs se sont produites.
Le dépannage de problèmes de pools sous Oracle Solaris 11 est similaire au diagnostic de problèmes sous Oracle Solaris 10, mais il convient de vérifier les nouvelles descriptions et fonctions de diagnostic décrites ci-après :
Echec de périphériques : vérifiez la sortie de la commande zpool status - l pour identifier l'emplacement physique du périphérique défectueux et remplacez ce dernier. Pour plus d'informations sur le remplacement d'un disque défectueux, reportez-vous à la section Remplacement ou réparation d’un périphérique endommagé du manuel Administration d’Oracle Solaris 11.1 : Systèmes de fichiers ZFS.
Notification de périphérique défectueux : le service smtp-notify peut être configuré pour envoyer des notifications par courrier électronique en réponse à divers événements de gestion des défauts, par exemple lorsqu'un composant matériel est diagnostiqué défectueux. Pour plus d'informations, reportez-vous à la section relative aux paramètres de notification de la page de manuel smf(5).
Par défaut, certaines notifications sont configurées automatiquement pour être envoyées à l'utilisateur root. Si vous ajoutez un alias pour votre compte utilisateur en tant qu'utilisateur root dans le fichier /etc/aliases, vous recevrez par courrier électronique des notifications semblables à la suivante :
-------- Original Message -------- Subject: Fault Management Event: tardis:SMF-8000-YX Date: Wed, 21 Sep 2011 11:11:27 GMT From: No Access User <noaccess@tardis.drwho.COM> Reply-To: root@tardis.drwho.COM To: root@tardis.drwho.COM SUNW-MSG-ID: ZFS-8000-D3, TYPE: Fault, VER: 1, SEVERITY: Major EVENT-TIME: Wed Sep 21 11:11:27 GMT 2011 PLATFORM: Sun-Fire-X4140, CSN: 0904QAD02C, HOSTNAME: tardis SOURCE: zfs-diagnosis, REV: 1.0 EVENT-ID: d9e3469f-8d84-4a03-b8a3-d0beb178c017 DESC: A ZFS device failed. Refer to http://sun.com/msg/ZFS-8000-D3 for more information. AUTO-RESPONSE: No automated response will occur. IMPACT: Fault tolerance of the pool may be compromised. REC-ACTION: Run 'zpool status -x' and replace the bad device.
Déplacement de périphériques : les périphériques faisant partie d'un pool de stockage ZFS contiennent un ID de périphérique, si celui-ci a été créé par le pilote du périphérique. Comme tous les systèmes de fichiers, ZFS est étroitement lié à ses périphériques sous-jacents. Par conséquent, si vous tentez de mettre à niveau le microprogramme d'un système, de déplacer un périphérique de pool vers un autre contrôleur ou de modifier le câblage d'un périphérique, vous pouvez envisager d'exporter le périphérique au préalable. Si l'ID du périphérique ne correspond plus au périphérique modifié, ce qui peut se produire avec matériel non Oracle, le pool et les données du pool risquent de devenir non disponibles. En général, le matériel Sun d'Oracle peut se rétablir si un périphérique est modifié sous un pool en cours d'utilisation, car nos pilotes prennent totalement en charge les ID de périphériques. Vous pouvez cependant envisager d'exporter le pool avant toute modification apportée au matériel.
Pour obtenir une description complète du dépannage des problèmes de pools, reportez-vous au Chapitre 10, Dépannage d’Oracle Solaris ZFS et récupération de pool du manuel Administration d’Oracle Solaris 11.1 : Systèmes de fichiers ZFS.