Ignorer les liens de navigation | |
Quitter l'aperu | |
Administration d'Oracle Solaris : Systèmes de fichiers ZFS Oracle Solaris 11 Information Library (Français) |
1. Système de fichiers Oracle Solaris ZFS (introduction)
2. Mise en route d'Oracle Solaris ZFS
3. Différences entre les systèmes de fichiers Oracle Solaris ZFS et classiques
4. Gestion des pools de stockage Oracle Solaris ZFS
5. Gestion des composants du pool racine ZFS
6. Gestion des systèmes de fichiers Oracle Solaris ZFS
7. Utilisation des instantanés et des clones ZFS Oracle Solaris
8. Utilisation des ACL et des attributs pour protéger les fichiers Oracle Solaris ZFS
9. Administration déléguée de ZFS dans Oracle Solaris
10. Rubriques avancées Oracle Solaris ZFS
11. Dépannage d'Oracle Solaris ZFS et récupération de pool
12. Archivage des instantanés et récupération du pool racine
13. Pratiques recommandées pour Oracle Solaris ZFS
Pratiques recommandées pour les pools de stockage
Pratiques recommandées générales
Pratiques de création de pools de stockage ZFS
Pratiques recommandées générales pour les pools de stockage
Pratiques recommandées pour la création de pool racine
Pratiques recommandées pour la création de pools non racine
Pratiques recommandées pour la création de pools pour une base de données Oracle
Pratiques recommandées pour l'optimisation des performances des pools de stockage
Pratiques recommandées pour la maintenance et la gestion d'un pool de stockage ZFS
Pratiques recommandées pour les systèmes de fichiers
Pratiques recommandées pour la création de systèmes de fichiers
Pratiques recommandées pour la création de systèmes de fichiers pour une base de données Oracle
Pratiques recommandées pour la surveillance de systèmes de fichiers ZFS
Les sections suivantes décrivent les pratiques recommandées pour la création et la surveillance de pools de stockage ZFS. Pour plus d'informations sur le dépannage des problèmes de pools de stockage, reportez-vous au Chapitre 11, Dépannage d'Oracle Solaris ZFS et récupération de pool.
Maintenez votre système à jour grâce aux dernières versions et aux correctifs Solaris.
Evaluez la mémoire requise en fonction de la charge de travail actuelle du système.
Avec une application dont l'encombrement mémoire est connu, telle qu'une application de base de données par exemple, vous pouvez limiter la taille de l'ARC de manière à ce que l'application n'ait pas besoin de récupérer la mémoire nécessaire à partir du cache ZFS.
Tenez compte de la mémoire requise pour la suppression des doublons.
Identifiez l'utilisation de la mémoire par ZFS à l'aide de la commande suivante :
# mdb -k > ::memstat Page Summary Pages MB %Tot ------------ ---------------- ---------------- ---- Kernel 388117 1516 19% ZFS File Data 81321 317 4% Anon 29928 116 1% Exec and libs 1359 5 0% Page cache 4890 19 0% Free (cachelist) 6030 23 0% Free (freelist) 1581183 6176 76% Total 2092828 8175 Physical 2092827 8175 > $q
Envisagez l'utilisation de mémoire ECC pour prévenir la corruption de mémoire. La corruption de mémoire silencieuse peut endommager vos données.
Effectuez des sauvegardes régulières : bien qu'un pool créé avec redondance ZFS permette de réduire le temps d'inactivité dû à des pannes matérielles, il n'est pas à l'abri des pannes matérielles, des pannes d'alimentation ou des déconnexions de câbles. Veillez à sauvegarder régulièrement vos données. Toutes les données importantes doivent être sauvegardées. Il existe différentes méthodes de copie des données :
Prise quotidienne ou à intervalles réguliers d'instantanés ZFS.
Sauvegardes hebdomadaires des données du pool ZFS. Vous pouvez utiliser la commande zpool split pour créer une copie exacte du pool de stockage ZFS mis en miroir.
Sauvegardes mensuelles à l'aide d'un produit de sauvegarde mis en oeuvre à l'échelle de l'entreprise.
RAID matériel
Envisagez l'utilisation du mode JBOD pour les baies de stockage plutôt que des baies RAID matérielles, afin que ZFS puisse gérer le stockage et la redondance.
Utilisez la redondance matérielle RAID et/ou la redondance ZFS.
L'utilisation de la redondance ZFS présente de nombreux avantages : pour les environnements de production, configurez ZFS de manière à lui permettre de réparer les incohérences de données. Utilisez la redondance ZFS, telle que RAIDZ, RAIDZ-2, RAIDZ-3, la mise en miroir, quel que soit le niveau RAID mis en oeuvre sur le périphérique de stockage sous-jacent. Avec une telle redondance, ZFS est en mesure de détecter et de réparer les défaillances du périphérique de stockage sous-jacent ou des connexions à l'hôte de celui-ci.
Les vidages sur incident consomment davantage d'espace disque, généralement entre 1/2 et 3/4 de la taille de la mémoire physique.
Les sections suivantes présentent des pratiques recommandées générales et plus spécifiques pour les pools de stockage
Utilisez des disques entiers pour activer la mise en cache et faciliter la maintenance. La création de pools sur des tranches complique la gestion et la récupération des disques.
Utilisez la redondance ZFS pour permettre à ZFS de réparer les incohérences de données.
Le message suivant s'affiche lorsqu'un pool non redondant est créé :
# zpool create tank c4t1d0 c4t3d0 'tank' successfully created, but with no redundancy; failure of one device will cause loss of the pool
Pour des pools mis en miroir, utilisez des paires de disques mis en miroir
Pour des pools RAIDZ, regroupez 3 à 9 disques par VDEV
Utilisez des disques hot spare pour réduire le temps d'inactivité dû aux pannes matérielles.
Utilisez des disques de taille similaire afin que de répartir les E/S de façon équilibrée entre les périphériques.
Des LUN de petite taille peuvent être étendus en LUN de grande taille
N'étendez pas des LUN de façon excessive, comme par exemple de 128 Mo à 2 To, de manière à conserver des tailles de metaslabs optimales
Envisagez la création d'un petit pool racine et de pools de données plus volumineux pour assurer une récupération plus rapide du système
Créez des pools racine comportant des tranches à l'aide de l'identificateur s*. N'utilisez pas l'identificateur p*. Le pool racine ZFS d'un système est généralement créé au moment de l'installation du système. Si vous êtes en train de créer un second pool racine ou de recréer un pool racine, utilisez une syntaxe semblable à la suivante :
# zpool create rpool c0t1d0s0
Sinon, créez un pool racine mis en miroir. Par exemple :
# zpool create rpool mirror c0t1d0s0 c0t2d0s0
Le pool racine 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 racine 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, mais l'algorithme de compression gzip n'est pas pris en charge sur les pools racine.
Ne renommez pas le pool racine une fois qu'il a été créé par une installation initiale. Si vous renommez le pool racine, cela peut empêcher l'initialisation du système.
Créez des pools non racine 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 offrant à ZFS un meilleur aperçu de la configuration des LUN, vous lui permettez de prendre de meilleures décisions de planification d'E/S.
Créez des configurations de pools redondants dans plusieurs contrôleurs afin de réduire le temps d'inactivité dû à une panne de contrôleur.
Pools de stockage mis en miroir : consomment davantage d'espace disque mais présentent de meilleures performances pour les petites lectures aléatoires.
# zpool create tank mirror c1d0 c2d0 mirror c3d0 c4d0
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 fournit généralement des performances satisfaisantes lorsque les données sont écrites et lues en gros blocs (128 Ko ou plus).
Prenons l'exemple d'une configuration RAID-Z à parité simple (raidz) avec 2 périphériques virtuels à 3 disques (2+1) chacun.
# zpool create rzpool raidz1 c1t0d0 c2t0d0 c3t0d0 raidz1 c1t1d0 c2t1d0 c3t1d0
Une configuration RAIDZ-2 améliore la disponibilité des données et offre 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).
# zpool create rzpool raidz2 c0t1d0 c1t1d0 c4t1d0 c5t1d0 c6t1d0 c7t1d0 raidz2 c0t2d0 c1t2d0 c4t2d0 c5t2d0 c6t2d0 c7t2d
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) à 9 disques (6+3).
# zpool create rzpool raidz3 c0t0d0 c1t0d0 c2t0d0 c3t0d0 c4t0d0 c5t0d0 c6t0d0 c7t0d0 c8t0d0
Tenez compte des pratiques recommandées pour la création de pools de stockage suivantes lorsque vous créez une base de données Oracle.
Utilisez un pool mis en miroir ou un RAID matériel pour plusieurs pools
Les pools RAID-Z ne sont généralement pas recommandés pour les charges de travail en lecture aléatoire
Créez un petit pool distinct avec un périphérique de journalisation distinct pour les fichiers de journalisation de la base de données
Créez un petit pool distinct pour le journal d'archivage
Pour plus d'informations, consultez le livre blanc suivant :
http://blogs.oracle.com/storage/entry/new_white_paper_configuring_oracle
N'utilisez pas plus de 80 % de la capacité d'un pool pour des performances optimales.
Les pools mis en miroir sont à préférer aux pools RAID-Z pour des charges de travail en lecture/écriture aléatoires
Périphériques de journalisation distincts
Recommandés pour améliorer les performances d'écriture synchrone
Avec une charge d'écriture synchrone élevée, empêche la fragmentation de l'écriture de nombreux blocs de journal dans le pool principal
Des périphériques de cache distincts sont recommandés pour améliorer les performances de lecture
Nettoyage/réargenture : un très grand pool RAID-Z comportant un grand nombre de périphériques nécessite des temps de nettoyage et de réargenture plus long
Si les performances du pool sont ralenties : utilisez la commande zpool status pour éliminer les problèmes matériels à l'origine des problèmes de performances du pool. Si la commande zpool status ne fait apparaître aucun problème, utilisez la commande fmdump pour afficher les pannes matérielles ou utilisez la commande fmdump -eV pour repérer les éventuelles défaillances matérielles qui n'ont pas encore été signalées en tant qu'erreur.
Assurez-vous que la capacité d'un pool est inférieure à 80 %, pour obtenir de meilleures performances.
Les performances d'un pool peuvent se dégrader lorsque le pool est très plein et que les systèmes de fichiers sont fréquemment mis à jour, comme c'est le cas par exemple pour un serveur de courrier très actif. Des pools pleins peuvent entraîner une baisse des performances, mais aucun autre problème. Si la charge de travail principale consiste en des fichiers immuables, maintenez un taux d'utilisation du pool de 95 à 96 %. Même avec un contenu essentiellement statique et un taux d'utilisation de 95 à 96 %, les performances d'écriture, de lecture et de réargenture risquent de se dégrader.
Contrôlez l'espace des pools et des systèmes de fichiers pour vous assurer qu'il n'est pas entièrement utilisé.
Vous pouvez envisager d'utiliser des quotas et des réservations ZFS afin d'être sûr que l'espace du système de fichiers ne dépasse pas 80 % de la capacité du pool.
Surveillez la santé du pool
Surveillez les pools redondants sur une base hebdomadaire à l'aide de zpool status et fmdump
Surveillez les pools non redondants toutes les deux semaines à l'aide de zpool status et fmdump
Exécutez régulièrement zpool scrub pour repérer les problèmes d'intégrité des données.
Si vous utilisez des lecteurs de qualité grand public, envisagez de planifier un nettoyage hebdomadaire.
Si vous utilisez des lecteurs de qualité professionnelle, envisagez de planifier un nettoyage hebdomadaire.
Vous devez également exécuter un nettoyage avant de remplacer des périphériques ou de réduire temporairement la redondance d'un pool, afin d'assurer que tous les périphériques sont alors opérationnels.
Surveillance des défaillances de pools ou de périphériques : utilisez zpool status comme décrit ci-dessous. Utilisez également les commandes fmdump ou fmdump -eV pour vérifier l'absence de défauts et d'erreurs au niveau des périphériques.
Surveillez la santé des pools redondants sur une base hebdomadaire à l'aide de zpool status et fmdump
Surveillez la santé des pools non redondants toutes les deux semaines à l'aide de zpool status et fmdump
Le périphérique de pool est UNAVAIL ou OFFLINE : si un périphérique de pool n'est pas disponible, vérifiez si le périphérique est répertorié dans la sortie de la commande format. Si le périphérique n'apparaît pas dans la sortie de format, il n'est pas visible sur ZFS.
L'état de périphérique de pool UNAVAIL ou OFFLINE signifie généralement que le périphérique est en panne, qu'un câble est déconnecté ou qu'un autre problème matériel, tel qu'un câble ou un contrôleur défectueux, a rendu inaccessible le périphérique.
Envisagez de configurer le service smtp-notify de manière à ce qu'il vous informe lorsqu'un composant matériel est diagnostiqué comme défectueux. Pour plus d'informations, reportez-vous à la rubrique Paramètres de notification des pages de manuel smf(5) et smtp-notify(1M).
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.
Surveillez l'espace du pool de stockage : utilisez les commandes zpool list et zfs list pour déterminer la quantité d'espace disque utilisée par les données des systèmes de fichiers. Les instantanés ZFS peuvent consommer de l'espace disque et, lorsqu'ils ne sont pas répertoriés par la commande zfs list, peuvent consommer de l'espace disque de manière silencieuse. Utilisez la commande d'instantané zfs list - t pour identifier l'espace disque consommé par des instantanés.