JavaScript is required to for searching.
Ignorer les liens de navigation
Quitter l'aperu
Administration d'Oracle Solaris : Systèmes de fichiers ZFS     Oracle Solaris 11 Information Library (Français)
search filter icon
search icon

Informations document

Préface

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

Volumes ZFS

Utilisation d'un volume ZFS en tant que périphérique de swap ou de vidage

Utilisation d'un volume ZFS en tant qu'unité logique de stockage iSCSI

Utilisation de ZFS dans un système Solaris avec zones installées

Ajout de systèmes de fichiers ZFS à une zone non globale

Délégation de jeux de données à une zone non globale

Ajout de volumes ZFS à une zone non globale

Utilisation de pools de stockage ZFS au sein d'une zone

Gestion de propriétés ZFS au sein d'une zone

Explication de la propriété zoned

Copie de zones vers d'autres systèmes

Utilisation de pools racine ZFS de remplacement

Création de pools racine de remplacement ZFS

Importation de pools racine de remplacement

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

A.  Descriptions des versions d'Oracle Solaris ZFS

Index

Utilisation de ZFS dans un système Solaris avec zones installées

Les sections suivantes décrivent l'utilisation d'un système de fichiers ZFS sur un système avec des zones Oracle Solaris :

Tenez compte des points suivants lors de l'association de jeux de données à des zones :

Dans les sections suivantes, le terme jeu de données ZFS fait référence à un système de fichier ou à un clone.

L'ajout d'un jeu de données permet à la zone non globale de partager l'espace avec la zone globale, mais l'administrateur de zone ne peut pas contrôler les propriétés ou créer de nouveaux systèmes de fichiers dans la hiérarchie de systèmes de fichiers sous-jacents. Cette opération est identique à l'ajout de tout autre type de système de fichiers à une zone. Effectuez-la lorsque vous souhaitez simplement partager de l'espace commun.

ZFS autorise également la délégation de jeux de données à une zone non globale, ce qui permet à l'administrateur de zone de contrôler parfaitement le jeu de données et ses enfants. L'administrateur de zone peut créer et détruire les systèmes de fichiers ou les clones au sein de ce jeu de données et modifier les propriétés des jeux de données. L'administrateur de zone ne peut pas affecter des jeux de données qui n'ont pas été ajoutés à la zone, y compris ceux qui dépassent les quotas de niveau supérieur du jeu de données délégué.

Tenez compte des points suivants lorsque vous utilisez ZFS sur un système sur lequel des zones Oracle Solaris sont installées :

Ajout de systèmes de fichiers ZFS à une zone non globale

Vous pouvez ajouter un système de fichiers ZFS en tant que système de fichiers générique lorsqu'il s'agit simplement de partager de l'espace avec la zone globale. La propriété mountpoint d'un système de fichiers ZFS ajouté à une zone non globale doit être définie sur legacy. Par exemple, si le système de fichiers tank/zone/zion doit être ajouté à une zone non globale, définissez comme suit la propriété mountpoint dans la zone globale :

# zfs set mountpoint=legacy tank/zone/zion

La sous-commande add fs de la commande zonecfg permet d'ajouter un système de fichiers ZFS à une zone non globale.

Dans l'exemple suivant, un système de fichiers ZFS est ajouté à une zone non globale par un administrateur global de la zone globale :

# zonecfg -z zion
zonecfg:zion> add fs
zonecfg:zion:fs> set type=zfs
zonecfg:zion:fs> set special=tank/zone/zion
zonecfg:zion:fs> set dir=/export/shared
zonecfg:zion:fs> end

Cette syntaxe permet d'ajouter le système de fichiers ZFS tank/zone/zion à la zone zion déjà configurée et montée sur /export/shared. La propriété mountpoint du système de fichiers doit être définie sur legacy et le système de fichiers ne peut pas être déjà monté à un autre emplacement. L'administrateur de zone peut créer et détruire des fichiers au sein du système de fichiers. Le système de fichiers ne peut pas être remonté à un autre emplacement, tout comme l'administrateur ne peut pas modifier les propriétés suivantes du système de fichiers : atime, readonly, compression, etc. L'administrateur de zone globale est chargé de la configuration et du contrôle des propriétés du système de fichiers.

Pour plus d'informations sur la commande zonecfg et sur la configuration des types de ressources à l'aide de zonecfg, reportez-vous à la Partie II, Oracle Solaris Zones du manuel Administration Oracle Solaris : Oracle Solaris Zones, Oracle Solaris 10 Zones et gestion des ressources

Délégation de jeux de données à une zone non globale

Si l'objectif principal est de déléguer l'administration du stockage d'une zone, le système de fichiers ZFS prend en charge l'ajout de jeux de données à une zone non globale à l'aide de la sous-commande add dataset de la commande zonecfg.

Dans l'exemple suivant, un système de fichiers ZFS est délégué à une zone non globale par un administrateur global dans la zone globale.

# zonecfg -z zion
zonecfg:zion> add dataset
zonecfg:zion:dataset> set name=tank/zone/zion
zonecfg:zion:dataset> set alias=tank
zonecfg:zion:dataset> end

Contrairement à l'ajout d'un système de fichiers, cette syntaxe entraîne la visibilité du système de fichiers ZFS tank/zone/zion dans la zone zion déjà configurée. Dans la zone zion, ce système de fichiers n'est pas accessible en tant que tank/zone/zion, mais en tant que virtual pool nommé tank. L'alias du système de fichiers délégué fournit à la zone en tant que pool virtuel une vue du pool d'origine. La propriété d'alias indique le nom du pool virtuel. Si aucun alias n'est précisé, un alias par défaut correspondant au dernier composant du nom du système de fichiers est utilisé. Si aucun alias n'avait été indiqué, l'alias par défaut aurait été zion dans l'exemple ci-dessus.

Dans les jeux de données délégués, l'administrateur des zones peut définir les propriétés des systèmes de fichiers et créer des systèmes de fichiers descendants. En outre, l'administrateur des zones peut créer des instantanés ainsi que des clones, et contrôler la totalité de la hiérarchie du système de fichiers. Si des volumes ZFS sont créés au sein de systèmes de fichier délégués, ils risquent d'entrer en conflit avec les volumes ZFS ajoutés en tant que ressources de périphériques. Pour plus d'informations, reportez-vous à la section suivante et à dev(7FS).

Ajout de volumes ZFS à une zone non globale

Il est possible d'ajouter ou de créer un volume ZFS dans une zone non globale ou d'ajouter l'accès aux données d'un volume dans une zone non globale de l'une des manières suivantes :

Utilisation de pools de stockage ZFS au sein d'une zone

Il est impossible de créer ou de modifier des pools de stockage ZFS au sein d'une zone. Le modèle d'administration délégué centralise le contrôle de périphériques de stockage physique au sein de la zone globale et le contrôle du stockage virtuel dans les zones non globales. Bien qu'un jeu de données au niveau du pool puisse être ajouté à une zone, toute commande modifiant les caractéristiques physiques du pool, comme la création, l'ajout ou la suppression de périphériques est interdite au sein de la zone. Même si les périphériques physiques sont ajoutés à une zone à l'aide de la sous-commande add device de la commande zonecfg, ou si les fichiers sont utilisés, la commande zpool n'autorise pas la création de nouveaux pools au sein de la zone.

Gestion de propriétés ZFS au sein d'une zone

Après avoir délégué un jeu de données à une zone, l'administrateur de zone peut contrôler les propriétés spécifiques au jeu de données. Lorsqu'un jeu de données est délégué à une zone, tous les ancêtres s'affichent en tant que jeux de données en lecture seule, alors que le jeu de données lui-même, ainsi que tous ses descendants, est accessible en écriture. Considérez par exemple la configuration suivante :

global# zfs list -Ho name
tank
tank/home
tank/data
tank/data/matrix
tank/data/zion
tank/data/zion/home

En cas d'ajout de tank/data/zion à une zone ayant l'alias zion par défaut, chaque jeu de données possède les propriétés suivantes.

Jeu de données
Visible
Accessible en écriture
Propriétés immuables
tank
Non
-
-
tank/home
Non
-
-
tank/data
Non
-
-
tank/data/zion
Oui
Oui
zoned, quota, reservation
tank/data/zion/home
Oui
Oui
zoned

Notez que tous les parents de tank/zone/zion sont invisibles et que tous ses descendants sont accessibles en écriture. L'administrateur de zone ne peut pas modifier la propriété zoned car cela entraînerait un risque de sécurité, comme décrit dans la section suivante.

Les utilisateurs privilégiés dans la zone peuvent modifier toute autre propriété paramétrable, à l'exception des propriétés quota et reservation. Ce comportement permet à un administrateur de zone globale de contrôler l'espace disque occupé par tous les jeux de données utilisés par la zone non globale.

En outre, l'administrateur de zone globale ne peut pas modifier les propriétés sharenfs et mountpoint après la délégation d'un jeu de données à une zone non globale.

Explication de la propriété zoned

Lors qu'un jeu de données est délégué à une zone non globale, il doit être marqué spécialement pour que certaines propriétés ne soient pas interprétées dans le contexte de la zone globale. Lorsqu'un jeu de données est délégué à une zone non globale sous le contrôle d'un administrateur de zone, son contenu n'est plus fiable. Comme dans tous les systèmes de fichiers, cela peut entraîner la présence de binaires setuid, de liens symboliques ou d'autres contenus douteux qui pourraient compromettre la sécurité de la zone globale. De plus, l'interprétation de la propriété mountpoint est impossible dans le contexte de la zone globale. Dans le cas contraire, l'administrateur de zone pourrait affecter l'espace de noms de la zone globale. Afin de résoudre ceci, ZFS utilise la propriété zoned pour indiquer qu'un jeu de données a été délégué à une zone non globale à un moment donné.

La propriété zoned est une valeur booléenne automatiquement activée lors de la première initialisation d'une zone contenant un jeu de données ZFS. L'activation manuelle de cette propriété par un administrateur de zone n'est pas nécessaire. Si la propriété zoned est définie, le montage ou le partage du jeu de données est impossible dans la zone globale. Dans l'exemple suivant, le fichier tank/zone/zion a été délégué à une zone, alors que le fichier tank/zone/global ne l'a pas été :

# zfs list -o name,zoned,mountpoint -r tank/zone
NAME                  ZONED  MOUNTPOINT
tank/zone/global        off  /tank/zone/global
tank/zone/zion           on  /tank/zone/zion
# zfs mount
tank/zone/global           /tank/zone/global
tank/zone/zion             /export/zone/zion/root/tank/zone/zion

Notez la différence entre la propriété mountpoint et le répertoire dans lequel le jeu de données tank/zone/zion est actuellement monté. La propriété mountpoint correspond à la propriété telle qu'elle est stockée dans le disque et non à l'emplacement auquel est monté le jeu de données sur le système.

Lors de la suppression d'un jeu de données d'une zone ou de la destruction d'une zone, la propriété zoned n'est pas effacée automatiquement. Ce comportement est dû aux risques de sécurité inhérents associés à ces tâches. Dans la mesure où un utilisateur qui n'est pas fiable dispose de l'accès complet au jeu de données et à ses enfants, la propriété mountpoint risque d'être configurée sur des valeurs erronées ou des binaires setuid peuvent exister dans les systèmes de fichiers.

Afin d'éviter tout risque de sécurité, l'administrateur global doit effacer manuellement la propriété zoned pour que le jeu de données puisse être utilisé à nouveau. Avant de configurer la propriété zoned sur off, assurez-vous que la propriété mountpoint du jeu de données et de tous ses enfants est configurée sur des valeurs raisonnables et qu'il n'existe aucun binaire setuid, ou désactivez la propriété setuid.

Après avoir vérifié qu'aucune vulnérabilité n'existe au niveau de la sécurité, vous pouvez désactiver la propriété zoned à l'aide de la commande zfs set ou zfs inherit. Si la propriété zoned est désactivée alors que le jeu de données est en cours d'utilisation au sein d'une zone, le système peut se comporter de façon imprévue. Ne modifiez la propriété que si vous êtes sûr que le jeu de données n'est plus en cours d'utilisation dans une zone non globale.

Copie de zones vers d'autres systèmes

Si vous devez migrer une ou plusieurs zones vers un autre système, pensez à utiliser les commandes zfs send et zfs receive. Selon le scénario, il peut être préférable d'utiliser des flux de réplication ou des flux récursifs.

Les exemples de cette section décrivent la copie de données de zone d'un système à un autre. Des étapes supplémentaires sont nécessaires pour transférer la configuration de chaque zone et rattacher chaque zone au nouveau système. Pour plus d'informations, reportez-vous à la Partie II, Oracle Solaris Zones du manuel Administration Oracle Solaris : Oracle Solaris Zones, Oracle Solaris 10 Zones et gestion des ressources.

Si toutes les zones d'un système doivent migrer vers un autre système, envisagez d'utiliser un flux de réplication car il permet de conserver les instantanés et les clones. Les instantanés et les clones sont largement utilisés par les commandes pkg update, beadm create et zoneadm clone.

Dans l'exemple suivant, les zones de sysA sont installées dans le système de fichiers rpool/zones et doivent être copiées dans le système de fichiers tank/zones sur sys. Les commandes suivantes créent un instantané et copient les données vers sysb à l'aide d'un flux de réplication :

sysA# zfs snapshot -r rpool/zones@send-to-sysB
sysA# zfs send -R rpool/zones@send-to-sysB | ssh sysB zfs receive -d tank

Dans l'exemple ci-dessous, l'une des zones est copiée de sysC vers sysD. Supposons que la commande ssh ne soit pas disponible mais qu'une instance de serveur NFS le soit. Les commandes suivantes peuvent être utilisées pour générer un flux zfs send récursif sans se soucier de savoir si la zone est le clone d'une autre zone ou non.

sysC# zfs snapshot -r rpool/zones/zone1@send-to-nfs
sysC# zfs send -rc rpool/zones/zone1@send-to-nfs > /net/nfssrv/export/scratch/zone1.zfs
sysD# zfs create tank/zones
sysD# zfs receive -d tank/zones < /net/nfssrv/export/scratch/zone1.zfs