Bull AIX 5.3 Manuel utilisateur

Bull
Concepts de gestion de système AIX 5L
Système d’exploitation et unités
AIX
REFERENCE
86 F2 48EM 01
Bull
Concepts de gestion de système AIX 5L
Système d’exploitation et unités
AIX
Logiciel
Février 2005
BULL CEDOC
357 AVENUE PATTON
BP 20845
49008 ANGERS CEDEX 01
FRANCE
REFERENCE
86 F2 48EM 01
L’avis juridique de copyright ci–après place le présent document sous la protection des lois de Copyright
des États–Unis d’Amérique et des autres pays qui prohibent, sans s’y limiter, des actions comme la copie,
la distribution, la modification et la création de produits dérivés à partir du présent document.
Copyright
Bull S.A. 1992, 2005
Imprimé en France
Vos suggestions sur la forme et le fond de ce manuel seront les bienvenues.
Une feuille destinée à recevoir vos remarques se trouve à la fin de ce document.
Pour commander d’autres exemplaires de ce manuel ou d’autres publications techniques
Bull, veuillez utiliser le bon de commande également fourni en fin de manuel.
Marques déposées
Toutes les marques déposées sont la propriété de leurs titulaires respectifs.
AIXR est une marque déposée d’IBM Corp. et est utilisée sous licence.
UNIX est une marque déposée aux Etats–Unis et dans d’autres pays, licenciée exclusivement par Open Group.
Linux est une marque déposée de Linus Torvalds.
Les informations contenues dans le présent document peuvent être modifiées sans préavis. Bull ne pourra
être tenu pour responsable des erreurs qu’il peut contenir ni des dommages accessoires ou indirects que son
utilisation peut causer.
A propos de ce manuel
Ce guide fournit aux administrateurs système des informations conceptuelles pouvant
affecter la sélection des options lors de l’exécution de tâches telles que la sauvegarde et
la restauration du système, la gestion du stockage physique et logique, l’évaluation de
l’espace de pagination approprié, etc. Ce guide est conçu pour être utilisé comme
compagnon du System Management Guide: Operating System and Devices. Cette
publication est également disponible sur le CD de documentation fourni avec le système
d’exploitation.
Comment utiliser ce manuel
Ce manuel contient des informations générales et, si nécessaire, des informations
conceptuelles relatives aux principaux éléments du système d’exploitation AIX. Seules les
tâches de base sont décrites de manière générale. Pour plus d’informations sur les
instructions associées aux tâches, reportez–vous au document AIX 5L Version 5.3 System
Management Guide: Operating System and Devices
Depuis l’existence de la bibliothèque de documentation AIX 5.3, les informations de ce
manuel associées à la sécurité du système AIX ou à la sécurité en générale se trouvent
désormais dans un autre document. Toutes les informations associées à la sécurité se
trouvent dans le document AIX 5L Version 5.3 Security Guide.
Conventions typographiques
Les conventions typographiques adoptées dans ce manuel sont les suivantes :
Gras
Commandes, sous-routines, mots-clés, fichiers, structures,
répertoires et autres éléments dont le nom est prédéfini par le
système, ainsi que les objets graphiques (tels que boutons, labels,
icônes). Identifie également les objets graphiques (tels que
boutons, labels, icônes).
Italique
Paramètres dont la valeur ou le nom est fourni par l’utilisateur.
Espacement fixe
Exemples de valeurs spécifiques, de texte affiché, de code
programme, messages système, ou données entrées par
l’utilisateur.
Prise en compte de la casse dans AIX
Le système d’exploitation AIX tient compte de la casse, ce qui implique qu’il tient compte
des majuscules et des minuscules. Vous pouvez, par exemple, utiliser la commande ls pour
afficher des listes de fichiers. Si vous tapez LS, le système envoie un message indiquant
que la commande n’existe pas. De même, FILEA, FiLea et filea correspondent chacun à
des noms de fichiers différents, même s’ils résident dans le même répertoire. Pour éviter
d’exécuter des actions indésirables, veillez à toujours utiliser la casse appropriée.
ISO 9000
ISO 9000 registered quality systems were used in the development and manufacturing of
this product.
Préface
i
Documentation connexe
• AIX 5L Version 5.3 System Management Guide: Operating System and Devices
• AIX 5L Version 5.3 Security Guide
• AIX 5L Version 5.3 Installation Guide and Reference.
• AIX 5L Version 5.3 General Programming Concepts: Writing and Debugging Programs
• AIX 5L Version 5.3 Communications Programming Concepts
• AIX 5L Version 5.3 Kernel Extensions and Device Support Programming Concepts
• AIX 5L Version 5.3 Files Reference
• Performance Toolbox Version 2 and 3 for AIX: Guide and Reference
• AIX 5L Version 5.3 Performance Management Guide
• Common Desktop Environment 1.0: Advanced User’s and System Administrator’s
Guide.
ii
Concepts de gestion de système AIX – Système d’exploitation et unités
Table des matières
A propos de ce manuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comment utiliser ce manuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conventions typographiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prise en compte de la casse dans AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ISO 9000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Documentation connexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
i
i
i
i
ii
Chapitre 1. Gestion du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aspects uniques de la gestion de système dans AIX . . . . . . . . . . . . . . . . . . . . . . . . . .
Interfaces de gestion de système disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fonctions uniques du système d’exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LVM (Logical Volume Manager) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contrôleur de ressources système SRC (System Resource Controller) . . . . . . .
Object Data Manager (ODM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Base des données techniques essentielles (SWVPD) . . . . . . . . . . . . . . . . . . . . . .
Workload Manager (WLM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mises à jour du système d’exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identification des éléments installés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Commande man . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-1
1-1
1-1
1-2
1-2
1-2
1-2
1-3
1-3
1-3
1-4
1-4
Chapitre 2. Démarrage et arrêt du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Démarrage du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Amorçage du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Création d’images d’amorçage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identification et modification du niveau d’exécution du système . . . . . . . . . . . . . .
Description du processus d’amorçage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description du traitement de l’amorçage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Phase d’initialisation du noyau ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Phase de configuration de l’unité de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Phase d’amorçage du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description du processus d’amorçage de maintenance . . . . . . . . . . . . . . . . . . . . . . .
Description du système de fichiers RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description du processus de fermeture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Détection du blocage du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Détection PHD (Priority Hang Detection) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Détection des blocages par les E/S perdues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-1
2-2
2-2
2-2
2-2
2-3
2-4
2-4
2-5
2-5
2-6
2-7
2-8
2-9
2-9
2-10
Chapitre 3. Volumes logiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Généralités sur le stockage des volumes logiques . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Concepts de stockage des volumes logiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Groupes de volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Partitions physiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Volumes logiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Partitions logiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Systèmes de fichiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Limitations de la gestion de la mémoire logique . . . . . . . . . . . . . . . . . . . . . . . . .
LVM (Logical Volume Manager) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Concepts de quorum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Procédure de mise en service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Quorum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-1
3-1
3-2
3-3
3-4
3-5
3-5
3-5
3-6
3-7
3-7
3-7
3-7
Préface
iii
iv
Groupes de volumes sans quorum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Développement d’une stratégie relative aux groupes de volumes . . . . . . . . . . . . . .
Création de groupes de volumes distincts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Haute disponibilité face aux incidents de disque . . . . . . . . . . . . . . . . . . . . . . . . . . .
Haute disponibilité face aux incidents de carte ou d’alimentation . . . . . . . . . . . . .
Développement d’une stratégie relative aux volumes logiques . . . . . . . . . . . . . . . . .
Analyse des besoins associés à la mise en miroir et à l’entrelacement . . . . . . . .
Règles de programmation des écritures miroir sur disque . . . . . . . . . . . . . . . .
MWC (cohérence écrit–miroir) pour un volume logique . . . . . . . . . . . . . . . . . . .
Règles d’affectation inter-disque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Copie unique du volume logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Copies multiples du volume logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Règles d’affectation intra-disque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Affectations combinées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Affectation affinée avec des fichiers mappe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Développement d’une stratégie relative à la répartition du volume logique . . . .
Règles de contrôle de l’écriture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Détermination des stratégies de disques de secours remplaçables à chaud . . .
Gestion des zones actives dans les volumes logiques . . . . . . . . . . . . . . . . . . . . . .
Mise en œuvre de stratégies de groupe de volumes . . . . . . . . . . . . . . . . . . . . . . . . . .
3-8
3-9
3-9
3-10
3-10
3-11
3-11
3-12
3-14
3-16
3-16
3-17
3-19
3-20
3-20
3-21
3-21
3-21
3-22
3-24
Chapitre 4. Espace de pagination et mémoire virtuelle . . . . . . . . . . . . . . . . . . . . .
Généralités sur VMM (Virtual Memory Manager) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestion de la mémoire réelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Liste libre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Segments de mémoire persistants et segments de mémoire actifs . . . . . . . . . . .
Segments actifs et espace de pagination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fonction VMM Memory Load Control Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Généralités sur l’espace de pagination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Stratégies d’allocation d’espace de pagination . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comparaison du mode d’allocation d’espace de pagination Late et du mode
d’allocation d’espace de pagination Early . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interface de programmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Taille par défaut d’espace de pagination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichier d’espace de pagination, commandes et options . . . . . . . . . . . . . . . . . . . . .
4-1
4-2
4-2
4-2
4-2
4-3
4-3
4-4
4-4
Chapitre 5 Systèmes de fichiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Organisation et contenu de l’arborescence de fichiers . . . . . . . . . . . . . . . . . . . . . . . .
Description du système de fichiers racine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description du système de fichiers /usr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lien symbolique vers le répertoire /var. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Liens symbolique vers les répertoires /usr/share et /usr/lib . . . . . . . . . . . . . . . .
Description du système de fichiers /usr/share . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description du système de fichiers /var . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description du répertoire /export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tâches de gestion des systèmes de fichiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Commandes de système de fichier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Montage : généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description des points de montage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Montage des systèmes de fichiers, des répertoires et des fichiers . . . . . . . . . . . .
Contrôle des montages automatiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description de la sécurité du montage des stations de travail sans disque . . . .
Montages sans disque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sécurisation des montages sans disque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Types de systèmes de fichiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-1
5-2
5-3
5-5
5-6
5-6
5-7
5-7
5-8
5-10
5-11
5-12
5-12
5-13
5-13
5-14
5-15
5-15
5-17
Concepts de gestion de système AIX – Système d’exploitation et unités
4-5
4-6
4-7
4-7
JFS (Journaled File System) ou JFS2 (Enhanced Journaled File System) . . . . .
NFS (Network File System) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CDRFS (CD–ROM File System) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UDFS (DVD–ROM File System) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description de JFS et de JFS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
JFS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description de la segmentation de l’espace disque . . . . . . . . . . . . . . . . . . . . . .
Description du nombre variable d’i–nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description des limitations de taille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description des fichiers supplémentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description des fichiers volumineux et JFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description de la compression des données JFS . . . . . . . . . . . . . . . . . . . . . . . .
Description des sauvegardes en ligne JFS et des clichés JFS2 . . . . . . . . . . .
Description de la compatibilité et de la migration . . . . . . . . . . . . . . . . . . . . . . . .
Description de CDRFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description de UDFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-17
5-17
5-17
5-17
5-18
5-18
5-19
5-21
5-22
5-25
5-26
5-26
5-29
5-30
5-31
5-32
Chapitre 6. Sauvegarde et restauration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Généralités sur la sauvegarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Méthodes de sauvegarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Choix d’une politique de sauvegarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description des supports de sauvegarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Restauration des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Développement d’une stratégie de sauvegarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Structure du système de fichiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Données système et données utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sauvegarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reproduction d’un système (clonage) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sauvegarde des fichiers des utilisateurs ou des Systèmes de fichiers . . . . . . . . . . .
Sauvegarde de l’image système et des groupes de volumes définis
par l’utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration du système source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Montage et démontage des systèmes de fichiers . . . . . . . . . . . . . . . . . . . . . . . . . .
Remarques sur la sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Restauration d’une image de sauvegarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-1
6-2
6-2
6-3
6-4
6-4
6-5
6-5
6-6
6-6
6-7
6-8
6-9
6-9
6-10
6-10
6-10
Chapitre 7. Environnement système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Profils - généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichier /etc/profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
fichier .profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Services de manipulation des données sur l’heure . . . . . . . . . . . . . . . . . . . . . . . . . . .
Désallocation dynamique de processeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Impact potentiel sur les applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Désallocation de processeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Activation et désactivation de la désallocation de processeur . . . . . . . . . . . . . . . .
Relance d’une désallocation de processeur abandonnée . . . . . . . . . . . . . . . . . . .
Considérations relatives à l’état du processeur . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Entrées du journal des erreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-1
7-2
7-2
7-2
7-3
7-4
7-4
7-5
7-5
7-5
7-6
7-6
7-7
Chapitre 8. Gestion des processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-1
Préface
v
Chapitre 9. Gestion de la charge de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Concepts et généralités sur WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Affectation de process aux classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contrôle des ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Droits à ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modes de fonctionnement WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contrôle dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Outils de contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
API WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comptabilité par classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Généralités sur les classes WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Superclasses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sous–classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attribut de niveau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attribut d’héritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attribut localshm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attribut Resource Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Affectation de process à des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Affectation automatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Affectation manuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple 1 : Première affectation de process . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple 2 : Réaffectation et annulation de process . . . . . . . . . . . . . . . . . . . . . .
Mise à jour de WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestion des ressources à l’aide de WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Types de ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Partages cibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Limites de ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description de la priorité de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Groupes de ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Registre Rset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration de WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identification des besoins des applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Définition des niveaux, des partages et des limites . . . . . . . . . . . . . . . . . . . . . . . . .
Ajustement de la configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
API de Workload Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etiquette d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
API de gestion de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
API de gestion de WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
API de statistiques de WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
API de classification de WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compatibilité binaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Commandes WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple de classification, de règles et de limites WLM . . . . . . . . . . . . . . . . . . . . . . .
Exemples d’affectation de règles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemples de partages et de limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple avec des limites d’UC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple avec des limites de mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compatibilité amont . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi
Concepts de gestion de système AIX – Système d’exploitation et unités
9-1
9-2
9-2
9-4
9-5
9-5
9-6
9-7
9-7
9-7
9-8
9-8
9-9
9-10
9-11
9-11
9-12
9-12
9-13
9-14
9-14
9-14
9-15
9-15
9-17
9-18
9-18
9-19
9-19
9-20
9-20
9-22
9-23
9-26
9-27
9-27
9-28
9-28
9-29
9-30
9-31
9-31
9-32
9-33
9-33
9-33
9-33
9-34
9-34
9-34
9-35
9-36
9-36
9-37
Chapitre 10. SRC et sous-systèmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SRC - généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Composants du sous-système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Groupe de sous-systèmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sous-serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Structure hiérarchique de SRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Liste des commandes d’administration du SRC . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-1
10-2
10-2
10-3
10-3
10-3
10-3
Chapitre 11. Comptabilité système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comptabilité - généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Collecte et rapport de données système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Collecte de données comptables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Durée de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comptabilité de l’utilisation du disque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utilisation de l’imprimante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Taxation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rapport de données comptables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rapports de durée de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rapport de comptabilité de l’utilisation du disque . . . . . . . . . . . . . . . . . . . . . . . .
Rapport de comptabilité de l’utilisation de l’imprimante . . . . . . . . . . . . . . . . . . .
Rapport de comptabilité des frais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rapports quotidiens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rapport mensuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prise en charge d’un nom d’utilisateur de longueur supérieure
à huit caractères . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Commandes comptables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Commandes exécutées automatiquement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Commandes disponibles à partir du clavier . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichiers comptables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichiers de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichiers de rapport et de résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichiers de commande runacct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichiers du répertoire /var/adm/acct/nite(x) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichiers du répertoire /var/adm/acct/sum(x) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichiers du répertoire /var/adm/acct/fiscal(x) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Formats des fichiers comptables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11-1
11-2
11-2
11-3
11-3
11-3
11-4
11-4
11-4
11-4
11-5
11-5
11-5
11-5
11-5
11-6
11-6
11-6
11-6
11-7
11-8
11-8
11-9
11-9
11-9
11-10
11-11
11-11
11-11
Chapitre 12. Web–based System Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12-1
Chapitre 13. SMIT (System Management Interface Tool) . . . . . . . . . . . . . . . . . . .
13-1
Chapitre 14. Unités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration d’un grand nombre d’unités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Nœuds d’unité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Classes d’unité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Base de configuration d’unités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etats des unités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestion des unités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Codes d’emplacement des unités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Carte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Imprimante/traceur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unité tty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unité SCSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14-1
14-1
14-2
14-3
14-3
14-4
14-4
14-5
14-5
14-6
14-6
14-7
Préface
vii
viii
Codes d’emplacement des disques connectés directement au bus . . . . . . . . . . .
Disque série . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unité de disquette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Codes d’emplacement du rotateur/clavier LPFK . . . . . . . . . . . . . . . . . . . . . . . . . . .
Port multiprotocole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestion des connexions à chaud PCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unconfiguring PCI Communications Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E/S à plusieurs chemins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration d’une unité MPIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unités à plusieurs chemins prises en charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs d’unité MPIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs de module PCM (Path Control Module) . . . . . . . . . . . . . . . . . . . . . . . . . . .
14-7
14-7
14-8
14-8
14-8
14-9
14-11
14-11
14-11
14-13
14-13
14-14
14-16
Chapitre 15. Unités de bande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs des unités de bande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Présentation générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Taille de bloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mémoires tampon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Marques de fichier étendues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attribut de densité égale à #1 et attribut de densité égale à #2 . . . . . . . . . . . .
Réservation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Taille de bloc de longueur variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compression de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Autochargement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Délai entre deux tentatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Délai de lecture/écriture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Renvoyer erreur sur changement de bande . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs pour unités de bande 4 mm 2 Go (type 4mm2gb) . . . . . . . . . . . . . . . . . .
Taille de bloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mémoires tampon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs à valeur fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs pour unités de bande 4 mm 4 Go (type 4mm4gb) . . . . . . . . . . . . . . . . . .
Taille de bloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mémoires tampon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Densité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compression de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs à valeur fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs pour unités de bande 8 mm 2,3 Go (type 8mm) . . . . . . . . . . . . . . . . . . . .
Taille de bloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mémoires tampon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Marques de fichier étendues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs à valeur fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs pour unités de bande 8 mm 5 Go (type 8mm5gb) . . . . . . . . . . . . . . . . . .
Taille de bloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mémoires tampon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Marques de fichier étendues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Densité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compression de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs à valeur fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs pour unités de bande 8 mm 20000 Mo (autoconfiguration) . . . . . . . . . .
Taille de bloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mémoires tampon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Marques de fichier étendues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15-1
15-2
15-2
15-2
15-2
15-2
15-2
15-2
15-3
15-3
15-3
15-3
15-3
15-3
15-3
15-4
15-4
15-4
15-4
15-4
15-4
15-4
15-4
15-4
15-4
15-4
15-4
15-4
15-4
15-5
15-5
15-5
15-5
15-5
15-5
15-5
15-5
15-5
15-5
15-5
15-5
Concepts de gestion de système AIX – Système d’exploitation et unités
Paramètre de densité #1 et paramètre de densité #2 . . . . . . . . . . . . . . . . . . . .
Compression de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs à valeur fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs pour unités de bande 35 Go (type 35gb) . . . . . . . . . . . . . . . . . . . . . . . . . .
Taille de bloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mémoires tampon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Marques de fichier étendues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Paramètre de densité #1 et paramètre de densité #2 . . . . . . . . . . . . . . . . . . . .
Compression de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs à valeur fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs pour unités de bande 1/4 pouce 150 Mo (type 150mb) . . . . . . . . . . . . . .
Taille de bloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mémoires tampon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Marques de fichier étendues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Paramètre de densité #1 et paramètre de densité #2 . . . . . . . . . . . . . . . . . . . .
Attributs à valeur fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs pour unités de bande 1/4 pouce 525 Mo (type 525mb) . . . . . . . . . . . . . .
Taille de bloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mémoires tampon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Marques de fichier étendues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Paramètre de densité #1 et paramètre de densité #2 . . . . . . . . . . . . . . . . . . . .
Attributs à valeur fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs pour unités de bande 1/4 pouce 1200 Mo (type 1200mb–c) . . . . . . . . .
Taille de bloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mémoires tampon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Marques de fichier étendues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Paramètre de densité #1 et paramètre de densité #2 . . . . . . . . . . . . . . . . . . . .
Attributs à valeur fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs pour unités de bande 4 mm 12 000 Mo (autoconfiguration) . . . . . . . . . .
Taille de bloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mémoires tampon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Marques de fichier étendues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Paramètre de densité #1 et paramètre de densité #2 . . . . . . . . . . . . . . . . . . . .
Compression de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs à valeur fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs pour unités de bande 1/4 pouce 13 000 Mo (autoconfiguration) . . . . . .
Taille de bloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mémoires tampon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Marques de fichier étendues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Paramètre de densité #1 et paramètre de densité #2 . . . . . . . . . . . . . . . . . . . .
Attributs à valeur fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs pour unités de bande 9 pistes 1/2 pouce (type 9trk) . . . . . . . . . . . . . . . .
Taille de bloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mémoires tampon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Paramètre de densité #1 et paramètre de densité #2 . . . . . . . . . . . . . . . . . . . .
Attributs à valeur fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs pour cartouche 1/2 pouce 3490e (type 3490e) . . . . . . . . . . . . . . . . . . . . .
Taille de bloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mémoires tampon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Autochargement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Préface
15-6
15-6
15-6
15-6
15-6
15-7
15-7
15-7
15-7
15-7
15-7
15-7
15-7
15-7
15-8
15-8
15-8
15-8
15-8
15-8
15-8
15-8
15-8
15-9
15-9
15-9
15-9
15-9
15-9
15-9
15-9
15-10
15-10
15-10
15-10
15-10
15-11
15-11
15-11
15-11
15-11
15-11
15-11
15-11
15-12
15-12
15-12
15-12
15-12
15-12
15-12
15-12
15-12
15-12
15-12
ix
x
Attributs pour autres bandes SCSI (type ost) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Taille de bloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mémoires tampon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Marques de fichier étendues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Paramètre de densité #1 et paramètre de densité #2 . . . . . . . . . . . . . . . . . . . .
Réservation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Taille de bloc de longueur variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Délai entre deux tentatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Délai de lecture/écriture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs à valeur fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichiers spéciaux pour unités de bande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15-13
15-13
15-13
15-13
15-13
15-13
15-13
15-13
15-13
15-13
15-14
Annexe A. Comparaisons pour les gestionnaires de systèmes BSD . . . . . . . .
Comparaison de AIX et de BSD pour les gestionnaires de systèmes . . . . . . . . . . .
Introduction à ce système d’exploitation pour administrateurs système BSD . . . . .
Principales différences entre 4.3 BSD et ce système d’exploitation . . . . . . . . . . . . .
Stockage des données de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestion de la configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestion de disque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Nouvelles commandes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Amorçage et lancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Autorisation utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Impression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Shells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comptabilité pour administrateurs système BSD 4.3 . . . . . . . . . . . . . . . . . . . . . . . . . .
Sauvegarde pour les gestionnaires de systèmes BSD 4.3 . . . . . . . . . . . . . . . . . . . . .
Prise en charge des unités de bande SCSI autres que Bull . . . . . . . . . . . . . . . . .
Amorçage et lancement pour administrateurs système BSD 4.3 . . . . . . . . . . . . . . . .
Commandes d’administration pour administrateurs système BSD 4.3 . . . . . . . . . . .
Cron pour administrateurs système BSD 4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unités pour administrateurs systèmes BSD 4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tableau de comparaison de fichiers BSD 4.3,
SVR4 et de ce système d’exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Systèmes de fichiers pour administrateurs système BSD 4.3 . . . . . . . . . . . . . . . . . .
Fichiers /etc/filesystems et /etc/fstab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Support des systèmes de fichiers sur ce système d’exploitation . . . . . . . . . . . . .
Recherche et examen de fichiers pour administrateurs système BSD 4.3 . . . . . . .
Espace de pagination pour administrateurs système BSD 4.3 . . . . . . . . . . . . . . . . . .
Réseau pour administrateurs système BSD 4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration BSD 4.3 : modification du lancement par défaut . . . . . . . . . . . . . . .
Autres options des commandes ifconfig et netstat . . . . . . . . . . . . . . . . . . . . . . . . .
Autres commandes de gestion de réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Résolution nom et adresse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Différences entre ce système d’exploitation et BSD 4.3 . . . . . . . . . . . . . . . . . . . . .
Commande tn3270 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Documentation en ligne et commande man pour administrateurs
système BSD 4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NFS et NIS (ex”Yellow Pages”) pour administrateurs système BSD 4.3 . . . . . . . . .
Mots de passe pour administrateurs système BSD 4.3 . . . . . . . . . . . . . . . . . . . . . . . .
Définition d’un mot de passe utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Importation d’un fichier de mots de passe BSD 4.3 . . . . . . . . . . . . . . . . . . . . . . . . .
Edition du fichier de mots de passe (Password) . . . . . . . . . . . . . . . . . . . . . . . . . . .
A-1
A-2
A-3
A-4
A-4
A-5
A-5
A-5
A-6
A-6
A-6
A-6
A-7
A-9
A-9
A-10
A-11
A-15
A-16
Concepts de gestion de système AIX – Système d’exploitation et unités
A-17
A-19
A-19
A-19
A-20
A-21
A-22
A-22
A-22
A-22
A-24
A-24
A-24
A-25
A-26
A-27
A-27
A-27
A-27
Mesure des performances et réglage pour les gestionnaires
systèmes BSD 4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Imprimantes pour les gestionnaires de systèmes BSD 4.3 . . . . . . . . . . . . . . . . . . . . .
Terminaux pour administrateurs système BSD 4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
termcap et terminfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UUCP pour administrateurs système BSD 4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A-30
A-31
A-34
A-34
A-35
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
X-1
Préface
xi
xii
Concepts de gestion de système AIX – Système d’exploitation et unités
Chapitre 1. Gestion du système
Les sujets traités dans ce chapitre sont les suivants :
• Aspects uniques de la gestion de système dans AIX, page 1-1
• Fonctions uniques du système d’exploitation, page 1-2
• Commande man, page 1-4
Aspects uniques de la gestion de système dans AIX
Ce système d’exploitation fournit sa propre version du support de la gestion de système
pour faciliter l’utilisation et améliorer la sécurité et l’intégrité. Ce chapitre présente ces
caractéristiques uniques :
• Interfaces de gestion de système disponibles, page 1-1
• Fonctions uniques du système d’exploitation, page 1-2
• Commande man, page 1-4
Interfaces de gestion de système disponibles
Ce système d’exploitation fournit en option, en plus de l’administration standard de type
ligne de commande, les interfaces suivantes :
• SMIT (System Management Interface Tool), interface utilisateur permettant de créer
et d’exécuter des commandes à partir d’options, et d’assurer :
L’interface SMIT vous permet d’assurer :
– l’installation, la mise à jour et la maintenance du logiciel,
– la configuration des unités,
– la configuration des unités de disque pour le stockage en groupes de volumes
et en volumes logiques,
– la création et l’extension de systèmes de fichiers et d’espaces de pagination,
– la gestion des utilisateurs et des groupes,
– la configuration des réseaux et des applications de communication,
– l’impression,
– l’identification des incidents,
– l’organisation des travaux,
– la gestion des ressources système et de la charge de travail
– Gestion des environnements de système
– Gestion des données de système en cluster. Voir SMIT (System Management
Interface Tool), page 13-1, pour plus d’informations sur la gestion du système avec
l’outil SMIT.
• Web-based System Manager, interface utilisateur graphique orientée objet prenant en
charge les mêmes tâches de gestion du système que SMIT, mais facilitant les tâches
de gestion système grâce :
– à la réduction des erreurs utilisateur à l’aide du contrôle d’erreurs et de la conception
des boîtes de dialogue
Gestion du système
1-1
– à des procédures pas à pas permettant d’exécuter des tâches nouvelles ou
compliquées
– à des options avancées pour les administrateurs expérimentés
– à la visualisation facilitée de données ou de relations complexes entre objets système
– au contrôle de l’activité système et à l’alerte de l’administrateur lorsque des
événements prédéfinis se produisent
– à la présence d’aide contextuelle, de généralités, de conseils et de liens vers de la
documentation en ligne
Web-based System Manager fonctionne sous AIX desktop ou par le biais d’une
connexion distante sécurisée vers tout client disposant d’un navigateur prenant en
charge Java. Une seule console Web–based System Manager peut gérer plusieurs
machines AIX.
Fonctions uniques du système d’exploitation
Ces fonctions sont présentées ci-après de façon succincte.
LVM (Logical Volume Manager)
LVM (Logical Volume Manager) maintient la hiérarchie des structures logiques qui gère le
stockage sur disque. Dans cette hiérarchie, les unités de disque sont définies comme des
volumes physiques. Chaque volume physique utilisé appartient à un groupe de volumes.
Chaque groupe de volumes contient au moins un volume logique. Les données des
volumes logiques semblent contiguës pour l’utilisateur, mais peuvent ne pas être contiguës
dans le volume physique. Cela permet aux systèmes de fichiers, à l’espace de pagination
et aux autres volumes logiques d’être redimensionnés et réalloués, de couvrir plusieurs
volumes physiques et de répliquer leur contenu pour améliorer la flexibilité et la
disponibilité.
Pour plus d’informations, reportez–vous à la section Généralités sur le stockage des
volumes logiques, page3-1.
Contrôleur de ressources système SRC (System Resource Controller)
Le contrôleur SRC fournit un ensemble de commandes et de sous–routines pour créer et
contrôler les sous–systèmes et permet de réduire l’intervention humaine dans le traitement
de système. Il fournit un mécanisme de contrôle des processus des sous–systèmes en
utilisant une ligne de commande ou une interface C. Vous pouvez ainsi démarrer, arrêter
ces processus et collecter des informations d’état sur ces derniers à l’aide de scripts shell,
de commandes et de programmes personnalisés.
Object Data Manager (ODM)
ODM est un gestionnaire de données dédié au stockage des données du système. Nombre
de fonctions de gestion système font appel à ODM. Les données servant à nombre de
fonctions SMIT et de commandes sont stockées et actualisées comme des objets, avec
leurs caractéristiques associées. Les données système gérées par ODM comprennent :
• des informations sur la configuration des unités ;
• des menus, des sélecteurs et des dialogues d’écrans SMIT ;
• des VPD (données techniques essentielles) pour les procédures d’installation et de mise
à jour ;
• des informations relatives à la configuration des communications ;
• des informations relatives aux ressources système.
1-2
Concepts de gestion de système AIX – Système d’exploitation et unités
Base des données techniques essentielles (SWVPD)
Certaines informations concernant les logiciels et leurs options installables sont actualisées
dans la base de données SWVPD (données techniques essentielles du logiciel). Cette base
est constituée d’un ensemble de commandes et de classes d’objets ODM, dédiées à la
maintenance des données relatives au logiciel. Par le biais de ces commandes, l’utilisateur
peut formuler des requêtes (commande lslpp) et vérifier (commande lppchk) les produits
logiciels installés. Les classes d’objets ODM définissent la portée et le format des données
actualisées.
La commande installp fait appel à ODM pour actualiser dans la base de données SWVPD :
• le nom du logiciel installé ;
• sa version ;
• son niveau d’édition, indiquant les modifications de son interface de programmation
externe ;
• son niveau de modification, indiquant les modifications n’affectant pas l’interface de
programmation externe ;
• son niveau de correction, indiquant les mises à jour mineures qui feront ultérieurement
l’objet d’un nouveau niveau de modification ;
• l’identification de la correction ;
• les noms, les totaux de contrôle, et la taille des fichiers constituant le logiciel ou l’option ;
• Etat d’installation du produit logiciel : application, appliqué, validation, validé, rejet ou
brisé.
Workload Manager (WLM)
Workload Manager (WLM) vous permet de créer différentes classes de services pour
travaux et d’en spécifier les attributs. Ces attributs spécifient les quantités minimale et
maximale de CPU, de mémoire physique et de débit d’E/S disque allouées à une classe.
WLM assigne alors automatiquement des travaux à des classes à l’aide des règles
d’affectation aux classes fournies par un administrateur système. Ces règles d’affectation
sont basées sur les valeurs d’un ensemble d’attributs pour un processus. L’administrateur
système ou un utilisateur privilégié peut également attribuer manuellement des travaux à
des classes, remplaçant l’affectation automatique. Pour en savoir plus, reportez–vous à
Workload Management, page 9-1.
Mises à jour du système d’exploitation
Le système d’exploitation est divisé en ensembles de fichiers qui contiennent chacun un
groupe de fichiers client associés logiquement. Chaque ensemble de fichiers peut être
installé et mis à jour individuellement.
Les révisions des ensembles de fichiers peuvent être suivies à l’aide des niveaux VRMF
(Version, Release, Maintenance and Fix). Par convention, chaque fois qu’une mise à jour
d’ensemble de fichiers est appliquée, le niveau du correctif est ajusté. Chaque fois qu’un
niveau de maintenance AIX est appliqué, le niveau de modification est ajusté et le niveau du
correctif est remise à zéro. L’installation initiale d’une version AIX, par exemple, AIX 5.3,
s’appelle une installation de base. Le système d’exploitation fournit les mises à jour de ses
fonctions et fonctionnalités qui peuvent être disponibles sous la forme d’un niveau de
maintenance, d’un PTF (Program Temporary Fix) ou d’un module de maintenance
recommandé.
Gestion du système
1-3
Niveaux de maintenance
Un niveau de maintenance fournit une nouvelle fonctionnalité destinée à
mettre à jour la version. La partie maintenance du niveau VRMF est mise à
jour dans un niveau de maintenance. Le premier niveau de maintenance
pour AIX 5.2, par exemple, est 5.2.1.0; le deuxième 5.2.2.0, et ainsi de
suite.
PTF
Entre les versions, vous pouvez recevoir des PTF qui corrigent ou éliminent
un problème particulier. Une installation peut nécessiter tous, certains ou
aucun des PTF disponibles.
Modules de maintenance recommandés
Un module de maintenance recommandé est un groupe de PTF entre les
niveaux de maintenance, qui ont été soigneusement testés ensemble et qui
sont recommandés pour la maintenance préventive.
Identification des éléments installés
Pour identifier le niveau de maintenance installé sur un système, tapez :
oslevel
Pour identifier les ensembles de fichiers à mettre à jour pour que le système corresponde à
un niveau de maintenance donné (4.3.3.0, en l’occurrence), utilisez la commande suivante :
oslevel –l 4.3.3.0
Pour déterminer si un module de maintenance recommandé est installé (5100–02, en
l’occurrence), utilisez la commande suivante :
oslevel –r 5100–02
Pour identifier les ensembles de fichiers à mettre à jour pour que le système corresponde
au niveau 5100–02, utilisez la commande suivante :
oslevel –rl 5100–02
Pour identifier le niveau d’un ensemble de fichiers (bos.mp, en l’occurrence) utilisez
la commande suivante :
lslpp –L bos.mp
Commande man
La commande man permet principalement d’accéder aux informations de référence sur
les commandes, les sous–routines et les fichiers. Pour afficher les informations relatives
à la commande ls, par exemple, entrez :
>man ls
La majorité des informations affichées sont issues principalement de fichiers HTML
formatés. La plupart des gestionnaires de systèmes considèrent qu’il est plus pratique
d’utiliser la commande man que de démarrer un navigateur Web pour rechercher
simplement des informations sur une option ou la syntaxe d’une commande.
Pour plus d’informations sur la commande man, reportez–vous à AIX 5L Version 5.3
Commands Reference. Consultez également la documentation en ligne et la section
Commande man pour les gestionnaires de système BSD 4.3, page A-25.
1-4
Concepts de gestion de système AIX – Système d’exploitation et unités
Chapitre 2. Démarrage et arrêt du système
Ce chapitre est consacré aux activités de démarrage du système, notamment l’amorçage,
la création d’images ou de fichiers d’amorçage et la définition du niveau d’exécution du
système. L’arrêt du système, au moyen des commandes reboot et shutdown, est
également traité.
Les sujets traités dans ce chapitre sont les suivants :
•
Démarrage du système, page 2-2
•
Description du processus d’amorçage, page 2-3
•
Description du traitement de l’amorçage du système, page 2-4
•
Description du processus d’amorçage de maintenance, page 2-6
•
Description du système de fichiers RAM, page 2-7
•
Description du processus d’arrêt, page 2-8
•
Détection du blocage du système, page 2-9
Démarrage et arrêt du système
2-1
Démarrage du système
A l’amorçage du système d’exploitation de base, le système lance un ensemble complexe
de tâches. En conditions normales d’exploitation, ces tâches s’exécutent automatiquement.
Amorçage du système
Vous demandez l’amorçage du système dans certaines situations : par exemple, pour
entériner l’installation d’un nouveau logiciel, pour réinitialiser les unités périphériques, pour
exécuter des routines de maintenance (telles que la vérification des systèmes de fichiers),
ou pour relancer le système après une panne ou une interruption. Vous trouverez des
informations sur ces procédures aux sections :
• Amorçage d’un système non installé.
• Réamorçage d’un système en cours d’exploitation.
• Amorçage à l’issue d’une panne système.
Création d’images d’amorçage
Lors de la première installation, la commande bosboot crée une image d’amorçage à partir
d’une image du système de fichiers disque en RAM et du noyau du système d’exploitation.
L’image d’amorçage est transférée sur un support donné, un disque dur par exemple. Au
réamorçage, l’image d’amorçage est chargée en mémoire à partir de son support.
Pour plus d’informations, reportez–vous à la section ”Creating Boot Images” du document
AIX 5L Version 5.3 System Management Guide: Operating System and Devices.
Identification et modification du niveau d’exécution du système
Le niveau d’exécution spécifie l’état du système et définit les processus à démarrer. Par
exemple, avec un niveau 3, tous les processus définis pour opérer à ce niveau sont lancés.
Juste avant la fin de phase d’amorçage système du processus d’amorçage, le niveau
d’exécution est lu dans l’entrée initdefault du fichier /etc/inittab. Il peut être modifié par le
biais de la commande init. Le fichier /etc/inittab contient un article par processus, qui
définit les niveaux d’exécution. A l’amorçage du système, la commande init lit le fichier
/etc/inittab pour définir les processus à démarrer. Vous trouverez des informations sur ces
procédures aux sections :
• Identification des niveaux d’exécution.
• Modification du niveau d’exécution.
• Modification du fichier /etc/inittab.
2-2
Concepts de gestion de système AIX – Système d’exploitation et unités
Description du processus d’amorçage
Lors du processus d’amorçage, le système teste le matériel, charge puis exécute le
système d’exploitation et configure les unités. L’amorçage du système d’exploitation
nécessite les ressources suivantes :
• une image d’amorçage chargeable après la mise sous tension ou la réinitialisation
de la machine,
• l’accès aux systèmes de fichiers racine et /usr.
Il existe trois types d’amorçage :
Amorçage à partir du
disque dur
Une machine est démarrée pour des opérations normales.
Pour plus d’informations, reportez–vous à la section
Description du traitement de l’amorçage du système,
page 2-4.
Amorçage réseau sans
disque
Une station de travail sans disque et sans données est
démarrée à distance sur le réseau. Une machine est
démarrée pour des opérations normales. Un ou plusieurs
serveurs de fichiers fournissent les fichiers et les
programmes dont ont besoin les stations de travail sans
disque et sans données pour s’amorcer.
Amorçage de maintenance Une machine est démarrée à partir d’un disque dur, d’un
réseau, d’une bande ou d’un CD–ROM en mode
Maintenance. Un administrateur système peut exécuter
des tâches telles qu’installer un nouveau logiciel ou une
mise à jour d’un logiciel et exécuter des programmes de
diagnostics. Pour plus d’informations, reportez–vous à
la section Description du processus d’amorçage de
maintenance, page 2-6.
Pendant l’amorçage à partir d’un disque, le système recherche l’image d’amorçage sur un
disque local défini à l’installation du système d’exploitation. Au cours du processus, le
système configure toutes les unités trouvées dans la machine et initialise le logiciel de base
nécessaire pour l’exploitation du système, tel que LVM (Logical Volume Manager). En fin de
processus, les systèmes de fichiers sont montés et prêts à l’emploi. Pour plus de détails sur
le système de fichiers utilisé lors de l’amorçage, reportez-vous à “Description du système
de fichiers RAM”, page 2-7.
Ce traitement s’applique également, dans les grandes lignes, aux clients de réseau sans
disque. Ils requièrent également une image d’amorçage et l’accès à l’arborescence du
fichier système d’exploitation. Ce type de client sans disque ne possédant pas de système
de fichiers local y accède à distance.
Démarrage et arrêt du système
2-3
Description du traitement de l’amorçage
Lors du démarrage du système pour une exploitation dans des conditions normales,
l’amorçage s’effectue généralement à partir du disque. Le système trouve sur le disque
toutes les données nécessaires au processus d’amorçage.
Lorsque le système est démarré par une mise sous tension (“à froid”) ou redémarré par
la commande reboot ou shutdown (“à chaud”), un certain nombre d’événements ont lieu
avant qu’il ne soit prêt à l’emploi. Ces événements sont répartis en trois phases :
1. Initialisation du noyau ROS (Read Only Storage),
2. Configuration des unités de base,
3. Phase d’amorçage de maintenance
Phase d’initialisation du noyau ROS
Cette phase comprend les étapes suivantes :
1. Le microcode détermine si la carte–mère du système fonctionne correctement.
Le contrôle est transmis à ROS qui exécute un autotest à la mise sous tension.
2. L’IPL (Initial Program Load = chargement initial du programme) ROS vérifie la liste
d’amorçage utilisateur, qui répertorie les unités d’amorçage disponibles. Vous pouvez
adapter cette liste à vos besoins au moyen de la commande bootlist. Si la liste
d’amorçage utilisateur dans la mémoire vive non volatile (NVRAM) n’est pas correcte ou
si aucune unité d’amorçage correcte n’est trouvée, la liste d’amorçage par défaut est
vérifiée. Dans les deux cas, la première unité d’amorçage valide rencontrée est utilisée
pour le démarrage du système. Les unités sont vérifiées dans l’ordre de la liste (à
condition qu’elle soit valide) située, le cas échéant, au niveau de la NVRAM. A défaut de
liste, toutes les cartes et unités du bus sont vérifiées. Dans les deux cas, les unités sont
vérifiées en boucle (continue) jusqu’à trouver une unité d’amorçage valide.
Remarque :
Le système se charge de la maintenance d’une liste d’amorçage par défaut,
située en ROS, et d’une liste d’amorçage utilisateur, stockée en NVRAM,
pour l’amorçage normal. Font aussi l’objet de maintenance deux listes
d’amorçage distinctes (une liste utilisateur et une liste par défaut), pour
l’amorçage avec le sélecteur sur maintenance.
3. Lorsqu’une unité d’amorçage valide est trouvée, c’est le premier article d’amorçage ou le
premier PSN (numéro de secteur de programme) qui est vérifié ; si cet article est valide,
il est lu en mémoire et ajouté au bloc de contrôle de l’IPL en mémoire. Les principales
données de l’article d’amorçage comprennent la position de démarrage de l’image
d’amorçage sur l’unité d’amorçage, la taille de cette image et les instructions relatives à
l’emplacement mémoire sur laquelle charger l’image d’amorçage.
4. L’image d’amorçage est lue de manière séquentielle depuis l’unité d’amorçage dans la
mémoire à partir de l’emplacement défini dans la mémoire NVRAM. L’image d’amorçage
sur disque est constituée du noyau, d’un système de fichiers RAM et d’informations
d’unités personnalisées.
5. Le contrôle est transmis au noyau qui initialise le système.
6. Le noyau exécute init qui exécute la phase 1 du script rc.boot.
A l’issue de cette phase, la configuration de l’unité de base est lancée.
2-4
Concepts de gestion de système AIX – Système d’exploitation et unités
Phase de configuration de l’unité de base
Le processus init lance le script rc.boot. La phase 1 de ce script se charge de la
configuration de l’unité de base. Elle comprend les différentes étapes suivantes :
1. Le script d’amorçage appelle le programme restbase pour créer la base de données
ODM (Object Data Manager) dans un système de fichiers RAM à partir des données
personnalisées compressées.
2. Le script d’amorçage lance le gestionnaire de configuration, qui accède à la phase 1 des
règles de configuration ODM pour configurer les unités de base.
3. Le gestionnaire de configuration démarre le système, le bus, le disque, SCSI et LVM
(Logical Volume Manager) et les méthodes de configuration du groupe de volumes
rootvg.
4. Les méthodes de configuration chargent les gestionnaires d’unités, créent les fichiers
spéciaux et mettent à jour les données personnalisées dans la base de données ODM.
Phase d’amorçage du système
Les étapes de la phase d’amorçage du système étaient les suivantes :
1. Le processus init lance la phase 2 du script rc.boot comprenant les étapes suivantes :
a. Appelez le programme ipl_varyon pour mettre en service le groupe de volumes
rootvg.
b. Monter les systèmes de fichiers de disque dur sur leurs points de montage normaux.
c. Exécution de swapon pour lancer la pagination.
d. Copie des données personnalisées de la base ODM du système de fichiers RAM
dans la base ODM du système de fichiers disque.
e. Sortie du script rc.boot.
2. Le processus d’amorçage passe ensuite du système de fichiers RAM au système
de fichiers disque.
3. Le processus init exécute les processus définis dans les articles du fichier /etc/inittab.
Selon l’une des instructions de ce fichier, la phase 3 du script rc.boot est exécutée ;
elle comprend les étapes suivantes :
a. Montage du système de fichiers disque /tmp
b. Lancement du gestionnaire de configuration – phase 2 pour configurer les unités
restantes
c. Exécution de la commande savebase pour sauvegarder les données personnalisées
sur le volume logique d’amorçage
d. Sortie du script rc.boot.
En fin de processus, le système est monté et prêt à l’emploi.
Démarrage et arrêt du système
2-5
Description du processus d’amorçage de maintenance
Il peut arriver qu’il soit nécessaire de réamorcer le système pour effectuer des tâches
spécifiques telles qu’installer un nouveau logiciel ou une mise à jour de logiciel, effectuer
des diagnostics ou exécuter des opérations de maintenance. Dans ce cas, le système
démarre depuis un support amorçable tel qu’un CD–ROM, une unité de bande, le réseau
ou une unité de disque.
La séquence des événements d’amorçage en mode maintenance est similaire à la
séquence d’amorçage normale.
1. Le microcode détermine si la carte–mère du système fonctionne correctement.
2. Le contrôle est transmis à ROS qui exécute un autotest à la mise sous tension.
3. ROS vérifie la liste d’amorçage personnalisée. Vous pouvez utiliser la commande
bootlist pour modifier cette liste en fonction des besoins. Si la liste en mémoire NVRAM
n’est pas valide ou que l’unité d’amorçage est introuvable, la liste d’amorçage par défaut
est utilisée. Dans les deux cas, la première unité d’amorçage valide détectée dans la
liste est utilisée pour démarrer le système.
Remarque :
Pour un amorçage normal, le système gère une liste d’amorçage par
défaut dans ROS et une liste d’amorçage en mémoire NVRAM. Des
listes d’amorçage par défaut et personnalisées sont également gérées
pour l’amorçage en mode de maintenance.
4. Lorsqu’une unité d’amorçage valide est détectée, le premier numéro d’enregistrement ou
PSN (Program Sector Number) est vérifié. S’il s’agit d’un enregistrement d’amorçage
valide, il est lu en mémoire et ajouté au bloc de contrôle IPL (Initial Program Load) en
mémoire. Les principales données d’enregistrement d’amorçage contiennent
l’emplacement de départ de l’image d’amorçage sur l’unité d’amorçage, la longueur de
l’image d’amorçage et le décalage par rapport au point d’entrée du démarrage lorsque
l’image d’amorçage est en mémoire.
5. L’image d’amorçage est lue de manière séquentielle depuis l’unité d’amorçage dans la
mémoire à partir de l’emplacement défini dans la mémoire NVRAM.
6. Le contrôle est transmis au noyau qui exécute les programmes dans le système de
fichiers RAM.
7. Le contenu de la base de données ODM détermine les unités présentes et la commande
cfgmgr configure dynamiquement toutes les unités détectées, y compris tous les
disques qui figurent dans le système de fichiers racine.
8. Si un CD–ROM, une bande ou le réseau est utilisé pour démarrer le système, le groupe
de volumes rootvg n’est pas activé, car le groupe de volumes rootvg peut ne pas exister
(comme c’est le cas lors de l’installation du système d’exploitation sur un nouveau
système). La configuration réseau peut avoir lieu à ce stade. Aucune pagination n’a lieu
lors du démarrage en mode maintenance.
A la fin de cette procédure, le système est prêt à être installé et pour exécuter des
opérations de maintenance et effectuer des diagnostics.
Remarque :
2-6
Si le système est démarré depuis le disque dur, rootvg est activé, le fichier
racine du disque dur et le système de fichiers utilisateur du disque dur sont
montés dans le système de fichiers RAM et un menu s’affiche pour vous
permettre d’utiliser divers modes de diagnostics ou un mode
mono–utilisateur. L’utilisation du mode mono–utilisateur permet de
poursuivre la procédure d’amorçage et d’entrer dans ce mode où le niveau
d’exécution init est ”S”. Le système est ensuite prêt pour la maintenance,
les mises à jour logicielles ou l’exécution de la commande bosboot.
Concepts de gestion de système AIX – Système d’exploitation et unités
Description du système de fichiers RAM
Le système de fichiers RAM, qui fait partie de l’image d’amorçage, réside en mémoire et
contient tous les programmes assurant la poursuite du processus d’amorçage. Les fichiers
de ce système déterminent le type d’amorçage.
Il se peut qu’un système de fichiers RAM d’amorçage ne contienne pas les routines de
volume logique, car il peut ne pas être nécessaire de mettre en service le groupe de
volumes rootvg. Toutefois, lors d’un amorçage depuis le disque dur, il est préférable
d’activer le plus rapidement possible le groupe de volumes rootvg et la pagination. Bien que
les deux scénarios d’amorçage soient différents, la structure du système de fichiers reste
pratiquement identique.
La commande init du système de fichiers RAM utilisée lors de l’amorçage est en fait le
programme ssh (simple shell). Ce programme contrôle le processus d’amorçage en
appelant le script rc.boot dont la première étape consiste à déterminer à partir de quelle
unité la machine a été amorcée. L’unité d’amorçage détermine les unités à configurer dans
le système de fichiers RAM. Si la machine est amorcée à partir du réseau, les unités du
réseau doivent être configurées pour permettre le montage à distance des systèmes de
fichiers client. En cas d’amorçage à partir d’un bande ou d’un CD–ROM, la console affiche
les menus d’installation de BOS. Quand rc.boot a identifié l’unité d’amorçage, les routines
de configuration correspondantes sont appelées dans le système de fichiers RAM. ssh
appelle rc.boot à deux reprises, c’est-à-dire pour les deux phases de configuration de
l’amorçage. Un troisième appel de rc.boot se produit au moment de l’appel de la
commande init pendant un amorçage disque ou réseau. Une strophe de rc.boot figurant
dans le fichier inittab se charge de la configuration finale de la machine.
Le système de fichier RAM de chaque unité d’amorçage est également unique du fait des
divers types d’unités à configurer. Un fichier prototype est associé à chaque type d’unité
d’amorçage. Le fichier prototype est un modèle de fichiers qui constituent le système de
fichiers RAM. La commande mkfs est utilisée par la commande bosboot pour créer le
système de fichiers RAM au moyen de différents fichiers de prototype. Pour plus de détails,
reportez-vous à la commande bosboot.
Démarrage et arrêt du système
2-7
Description du processus de fermeture
Vous avez la possibilité de fermer le système sous contrôle dans les situations suivantes :
• après l’installation d’un nouveau logiciel ou la modification de la configuration logicielle,
• lors d’un incident matériel,
• en cas d’interruption anormale persistante,
• en cas de performances décroissantes,
• si un système de fichiers est vraisemblablement endommagé.
2-8
Concepts de gestion de système AIX – Système d’exploitation et unités
Détection du blocage du système
AIX peut détecter les blocages et tenter de résoudre ces problèmes en fonction d’actions
définies par l’utilisateur. Actuellement, AIX prend en charge deux types de détection de
blocage.
• Détection PHD (Priority Hang Detection)
• Détection des blocages par les E/S perdues
Ces types de blocages sont décrits dans les sections suivantes. Pour plus d’informations
sur la détection des blocages du système, reportez–vous à la section System Hang
Management du document AIX 5L Version 5.3 System Management Guide: Operating
System and Devices.
Détection PHD (Priority Hang Detection)
Tous les processus (également appelés routines) ont une priorité d’exécution. Cette priorité
est comprise entre 0 et 126, par ordre croissant. Zéro est la priorité la plus élevée et 126 la
plus basse. La priorité par défaut pour toutes les routines est 60. Tout utilisateur peut
baisser la priorité d’un processus à l’aide de la commande nice. Toute personne ayant un
privilège d’utilisateur racine peut également augmenter la priorité d’un processus.
L’ordonnanceur du noyau envoie toujours au CPU la routine exécutable ayant la priorité la
plus élevée. Il est donc possible, en présence d’un nombre suffisant de routines à haute
priorité, de bloquer complètement la machine, de sorte que les routines à faibles priorité ne
s’exécutent jamais. Si les routines en cours d’exécution ont une priorité plus élevée que la
valeur par défaut, qui est de 60, les connexions et les shells normaux peuvent s’en trouver
verrouillés à un point tel que le système semble bloqué.
La fonction (System Hang Detection) offre un mécanisme permettant de détecter cette
situation et offrant à l’administrateur système un moyen de la corriger. Cette fonction est
mise en oeuvre sous forme de démon (shdaemon) s’exécutant avec la priorité la plus
élevée. Ce démon interroge le noyau pour connaître la routine à plus faible priorité
exécutée sur un intervalle spécifié. Si sa priorité dépasse un seuil configuré, le démon peut
exécuter différentes actions. Chacune de ces actions peut être activée indépendamment et
configurée pour se déclencher en fonction d’une priorité et d’un intervalle de temps
quelconque. Les actions et leurs valeurs par défaut sont les suivantes :
Action
1)
2)
3)
4)
5)
Activée
par défaut
Consigner erreur
Message console
Shell de connexion
à haute priorité
Exécution d’une
commande à haute
priorité
Panne et
redémarrage
Priorité
par défaut
Tempor.
Périph.
p. défaut par défaut
non
non
oui
60
60
60
2
2
2
non
60
2
non
39
5
/dev/console
/dev/tty0
Démarrage et arrêt du système
2-9
Détection des blocages par les E/S perdues
Du fait de l’existence d’erreurs d’E/S, le chemin E/S peut se bloquer et les autres E/S du
chemin sont affectées. Dans ce cas, il est important que le système d’exploitation puisse
avertir l’utilisateur et exécuter les actions définies par ce dernier. Dans le cadre de la
détection des E/S perdues et de la notification, le processus shdaemon, avec LVM,
contrôle les tampons d’E/S pendant un certain délai et détermine si des E/S sont en attente
depuis un certain temps. Si le délai d’attente est supérieur au seuil d’attente défini par le
fichier shconf , une perte d’E/S est détectée et d’autres actions sont exécutées.
Les informations relatives à l’E/S perdue sont consignées dans le journal des erreurs.
En outre, en fonction des paramètres définis dans le fichier shconf, le système peut être
redémarré pour résoudre le problème de perte d’E/S.
Pour la détection des pertes d’E/S, vous pouvez définir le délai et activer les actions
suivantes :
2-10
Action
Activée par défaut
Message de console
Non
/dev/console
Blocage et réamorçage
Non
–
Concepts de gestion de système AIX – Système d’exploitation et unités
Unité par défaut
Chapitre 3. Volumes logiques
Ce chapitre décrit les concepts de gestion du stockage des volumes logiques et porte sur
les sujets suivants :
• Généralités sur le stockage sur volumes logiques, page 3-1
• Développement d’une stratégie de groupes de volumes, page 3-9
• Développement d’une stratégie de volumes logiques, page 3-11
• Mise en oeuvre de stratégies de groupes de volumes, page 3-23
Généralités sur le stockage des volumes logiques
Une hiérarchie de structures est utilisée pour gérer la mémoire physique. Chaque unité de
disque, appelée volume physique( PV), porte un nom tel que /dev/hdisk0. Chaque
volume physique utilisé appartient à un groupe de volumes (VG). Tous les volumes
physiques d’un groupe de volumes sont divisés en partitions physiques (PP) de même taille.
Pour les besoins d’allocation d’espace, chaque volume physique est divisé en cinq régions
(outer_edge, inner_edge, outer_middle, inner_middle et center). Le nombre de partitions
physiques dans chaque région varie en fonction de la capacité totale de l’unité de disque.
Chaque groupe de volumes contient au moins un volume logique (LV). Les volumes
logiques sont des groupes d’informations situés dans les volumes physiques. Les données
des volumes logiques semblent contiguës pour l’utilisateur, mais peuvent ne pas être
contiguës dans le volume physique. Cela permet aux systèmes de fichiers, à l’espace de
pagination et aux autres volumes logiques d’être redimensionnés et réalloués, de couvrir
plusieurs volumes physiques et de répliquer leur contenu pour améliorer la flexibilité et la
disponibilité du stockage des données.
Chaque volume logique est constitué d’au moins une partition logique (LP). Chaque
partition logique correspond à au moins une partition physique. Si la mise en miroir est
définie pour le volume logique, d’autres partitions physiques sont allouées pour stocker les
copies supplémentaires de chaque partition logique. Bien que les partitions logiques soient
numérotées chronologiquement, les partitions physiques sous–jacentes ne sont pas
nécessairement consécutives, ni contiguës.
Les volumes logiques peuvent entrer dans divers processus système, tels que la
pagination, mais chaque volume logique n’a qu’une seule fonction. Un grand nombre de
volumes logiques contient un seul système de fichiers (JFS ou JFS2). Chaque système de
fichiers JFS est constitué d’un groupe de blocs de page (4 Ko). Lorsque des données
doivent être écrites dans un fichier, un ou plusieurs blocs supplémentaires sont alloués au
fichier. Ces blocs peuvent ne pas être contigus les uns par rapport aux autres ou à d’autres
blocs déjà alloués au fichier. Un système de fichiers peut être défini avec une taille de
fragment inférieur à 4 Ko (512 octets, 1 Ko, 2 Ko).
Après l’installation, le système dispose d’un groupe de volumes (rootvg) constitué d’un
ensemble de volumes logiques de base, nécessaires au démarrage du système, et d’autres
volumes logiques que vous définissez dans le script d’installation. Tous les autres volumes
physiques que vous connectez au système peuvent être ajoutés à un groupe de volumes
(à l’aide de la commande extendvg). Vous pouvez ajouter le volume physique au groupe
de volumes rootvg ou à un autre groupe de volumes (définir par la commande mkvg).
Les volumes logiques peuvent être personnalisés à l’aide de commandes, de SMIT
(System Management Interface Tool) ou de Web–based System Manager.
Volumes logiques
3-1
Concepts de stockage des volumes logiques
Les concepts de base du stockage des volumes logiques sont les suivants :
•
Volumes physiques, page 3-2
•
Groupes de volumes, page 3-3
•
Partitions physiques, page 3-4
•
Volumes logiques, page 3-5
•
Partitions logiques, page 3-5
La figure ci–dessous montre les relations entre ces concepts.
Figure 1. Groupe de volumes Cette illustration montre un groupe de volumes constitué de
trois volumes physiques avec une plage maximale. Le volume logique (qui peut être étendu
à plusieurs volumes physiques) est constitué de partitions logiques allouées à des partitions
physiques.
Partition
physique
Partition
physique
Partition
logique
Volume physique
Volume physique
Partition
physique
Volume physique
Volume physique
Volumes physiques
Une unité de disque doit être désignée en tant que volume physique et être
rendue disponible avant d’être attribuée à un groupe de volumes. Un volume physique
contient des informations de configuration et d’identification. Ces informations incluent un
identificateur de volume physique qui est unique pour le système.
Dans AIX 5.2 et les versions supérieures, LVM peut utiliser l’espace supplémentaire que
peut ajouter un module RAID (Redundant Array of Identical Disks) à un LUN (Logical Unit
Number), en ajoutant des partitions physiques au volume physique associé au LUN.
3-2
Concepts de gestion de système AIX – Système d’exploitation et unités
Groupes de volumes
Le volume physique doit maintenant faire partie d’un groupe de volumes. Un groupe de
volumes normal est un ensemble constitué de 1 à 32 volumes physiques de tailles et de
types différents. Un gros groupe de volumes peut contenir entre 1 et 128 volumes
physiques. Un groupe de volumes évolutif peut contenir jusqu’à 1024 volumes physiques.
Un volume physique peut appartenir à un seul groupe de volumes par système. Il peut
exister jusqu’à 255 groupes de volumes actifs.
Lorsqu’un volume physique est affecté à un groupe de volumes, les blocs physiques sur le
support de stockage sont organisés en partitions physiques dont la taille correspond à celle
que vous définissez lorsque vous créez le groupe de volumes. Pour en savoir plus,
reportez–vous à Partitions physiques, page 3-4.
Lorsque vous installez le système, un groupe de volumes (le groupe de volume racine
appelé rootvg) est créé automatiquement. Il contient le jeu de base de volumes logiques
nécessaires au démarrage du système ainsi que les autres volumes logiques que vous
définissez dans le script d’installation. Le groupe de volumes rootvg contient l’espace de
pagination, le journal des erreurs, les données d’amorçage, les clichés système, chacun
des ces éléments étant enregistrés dans son propre volume logique. Les attributs du
groupe de volumes rootvg sont différents de ceux des groupes de volumes que vous
définissez. Ce volume ne peut pas être importé, ni exporté, par exemple. Lorsque vous
exécutez une commande ou une procédure sur le groupe de volumes rootvg, vous devez
connaître ses caractéristiques spécifiques.
Utilisez la commande mkvg pour créer un groupe de volumes. Pour ajouter un volume
physique à un groupe de volumes, utilisez la commande extendvg. Pour changer la taille
d’un volume physique, utilisez la commande chvg. Pour supprimer un volume logique d’un
groupe de volumes, utilisez la commande reducevg. Vous pouvez utiliser également les
commandes suivantes avec les groupes de volumes : liste (lsvg), retrait (exportvg),
installation (importvg), réorganisation (reorgvg), synchronisation (syncvg), activation
(varyonvg) et désactivation (varyoffvg).
Les petits systèmes peuvent nécessiter un seul groupe de volumes contenant tous les
volumes physiques connectés au système. Vous pouvez créer des groupes de volumes
différents, mais pour des raisons de sécurité, car chaque groupe de volumes peut avoir ses
propres autorisations de sécurité. Des groupes de volumes différents facilitent également la
maintenance, car les groupes autres que celui en cours de maintenance peuvent rester
actifs. Du fait que le groupe de volumes rootvg doit toujours être en service, il contient
uniquement le nombre de volumes physiques nécessaires au fonctionnement du système.
Vous pouvez transférer les données d’un volume physique vers un autre dans le même
groupe de volumes avec la commande migratepv. Cette commande permet de libérer un
volume physique pour le supprimer du groupe de volumes. Par exemple, vous pouvez
transférer des données d’un volume physique à remplacer.
Un groupe de volumes créé avec des limites de volume physique et de volume logique plus
petites peut être converti vers un autre format pour contenir un plus grand nombre de
volumes physiques et de volumes logiques. Cette opération nécessite qu’il existe un
nombre suffisant de partitions dans chaque volume physique du groupe de volumes dans
l’extension de la zone VGDA (Volume Group Descriptor Area). Le nombre de partitions
libres nécessaires dépend de la taille de la zone VGDA actuelle et de la taille des partitions
physiques. Du fait que la zone VGDA réside au bord du disque et qu’elle nécessite un
espace contigu, les partitions libres doivent se trouver au bord du disque. Si ces partitions
sont allouées à l’utilisateur, elles sont migrées vers d’autres partitions libres du même
disque. Les autres partitions physiques sont renumérotées pour refléter la perte des
partitions pour la zone VGDA. Cette renumérotation change l’association des partitions
logiques et des partitions physiques dans tous les volumes physiques du groupe de
volumes. Si vous avez sauvegardé les associations des volumes logiques pour une
opération de reprise potentielle, régénérez les mappes à la fin de la conversion. En outre,
si la sauvegarde du groupe de volumes est effectuée avec l’option map et que vous
envisagez d’effectuer la restauration en utilisant ces mappes, la restauration peut échouer
Volumes logiques
3-3
car le nombre de partitions peut ne plus exister (du fait de la réduction). Il est recommandé
d’effectuer la sauvegarde avant la conversion et après la conversion si l’option map est
utilisée. Du fait que l’espace VGDA a été augmenté de manière substantielle, chaque mise
à jour VGDA (création d’un volume logique, modification d’un volume logique, ajout d’un
volume physique, etc.) peut durer beaucoup plus longtemps.
Partitions physiques
Lorsque vous ajoutez un volume physique à un groupe de volumes, le volume physique est
partitionné en espace d’unités égales contiguës appelées partitions physiques. Une partition
physique est la plus petite unité d’allocation d’espace de stockage et correspond à un
espace contigu dans un volume physique.
Les volumes physiques héritent de la taille de partition physique du groupe de volumes, que
vous définissez uniquement lorsque vous créez le groupe de volumes (par exemple, à l’aide
de la commande mkvg –s). L’illustration suivante montre la relation entre les partitions
physiques des volumes physiques et les groupes de volumes.
Figure 2. Groupe de volumes contenant trois volumes physiques. Cette illustration
montre trois volumes physiques contenant chacun six partitions physiques.
Partition
physique
Partition
physique
Volume physique
Partition
physique
Volume physique
Volume physique
3-4
Concepts de gestion de système AIX – Système d’exploitation et unités
Volumes logiques
Après avoir créé un groupe de volumes, vous pouvez créer ses volumes logiques. Un
volume logique, bien qu’il réside dans des partitions physiques non contiguës ou même sur
plusieurs volumes physiques, apparaît pour les utilisateurs et les applications sous la forme
d’un volume de disque extensible unique contigu. Vous pouvez créer d’autres volumes
logiques avec la commande mklv. Cette commande permet de définir le nom du volume
logique et ses caractéristiques, notamment le nombre et l’emplacement des partitions
logiques à lui associer.
Après avoir créé un volume logique, vous pouvez changer son nom et ses caractéristiques
avec la commande chlv. Vous pouvez augmenter le nombre de partitions logiques du
volume logique à l’aide de la commande extendlv. La taille maximale par défaut d’un
volume logique est égale à 512 partitions logiques, à moins que vous définissiez une autre
valeur. Pour changer cette valeur, utilisez la commande chlv.
Remarque : Après avoir créé un volume logique, les caractéristiques LV STATE, que
vous pouvez afficher avec la commande lslv, sont fermées. Elles sont rouvertes lorsque,
par exemple, un système de fichiers est créé dans le volume logique et que le volume
logique est monté.
Les volumes logiques peuvent être également copiés avec la commande cplv, listés avec
la commande lslv et supprimés avec la commande rmlv. Vous pouvez augmenter ou
diminuer le nombre de copies qu’ils gèrent à l’aide des commandes mklvcopy et rmlvcopy,
respectivement. Vous pouvez également déplacer les volumes logiques lorsque le groupe
de volumes est réorganisé.
Le système permet de définir jusqu’à 255 volumes logiques par groupe de volumes normal
(511 pour un grand groupe de volumes et 4 095 pour un groupe de volumes évolutif), mais
le nombre réel que vous pouvez définir dépend de la quantité totale de mémoire physique
définie pour le groupe de volumes et de la taille des volumes logiques que vous définissez.
Partitions logiques
Lorsque vous créez un volume logique, vous définissez le nombre de partitions logiques du
volume logique. Une partition logique est constituée d’une, de deux ou de trois partitions
physiques, selon le nombre d’instances des données à gérer. Si vous définissez une seule
instance, cela implique qu’il existe qu’une seule copie du volume logique (valeur par
défaut). Dans ce cas, il existe une association directe entre une partition logique et une
partition physique. Chaque instance, y compris la première, s’appelle une copie.
L’emplacement des partitions physiques (à savoir leur emplacement physique par rapport
aux autres) est déterminé par des options que vous définissez lorsque vous créez le volume
logique.
Systèmes de fichiers
Le volume logique définit l’allocation d’espace disque jusqu’au niveau de la partition
physique. Des niveaux de gestion plus fins des données peuvent être atteints à l’aide de
composants logiciels de plus haut niveau, tels que Virtual Memory Manager ou le système
de fichiers. En conséquence, la dernière étape de l’évolution d’un disque correspond à la
création des systèmes de fichiers. Vous pouvez créer un système de fichiers par volume
logique. Pour créer un système de fichiers, utilisez la commande crfs. Pour plus
d’informations sur les systèmes de fichiers, reportez–vous à la section Systèmes de fichiers,
page 5-1.
Volumes logiques
3-5
Limitations de la gestion de la mémoire logique
Le tableau suivant répertorie les limitations de la gestion de la mémoire logique. Bien que
le nombre maximum par défaut de volumes physiques par groupe de volumes soit égal à
(128 pour un grand groupe de volumes), vous pouvez définir le nombre maximum de
groupes de volumes définis par l’utilisateur avec la commande mkvg. Pour le groupe de
volumes rootvg, toutefois, cette variable est définie automatiquement par le système lors
de l’installation.
Limitations de la gestion de la mémoire logique
Catégorie
Limite
Groupes de
volumes
255 par système
Volume physique
(MAXPVS/facteur de groupe de volumes) par groupe de volumes.
MAXPVS est égal à 32 pour un groupe de volumes normal, à 128
pour un grand groupe de volumes et à 1 024 pour un groupe de
volumes évolutif.
Partitions
physiques
Groupes de volumes normaux et grands : (1016 x facteur de groupe
de volumes) par volume physique jusqu’à 1 024 Mo chacun.
Groupes de volumes évolutifs : 2 097 152 partitions d’une taille
maximum de 128 Go. Il n’y a pas de facteur de groupes de volumes
pour les groupes de volumes évolutifs.
Volume logique
MAXLVS par groupe de volume, qui est égal à 255 pour un groupe
de volumes normal, à 511 pour un grand groupe de volumes et à
4 095 pour un groupe de volumes évolutif.
Si vous avez créé un groupe de volumes avant l’entrée en vigueur de la limite de
1 016 partitions physiques par volume physique, les partitions périmées (qui ne
contiennent plus des données à jour) dans le groupe de volumes ne peuvent pas être
identifiées correctement si vous n’affectez pas un état pris en charge au groupe de
volumes. Vous pouvez convertir le groupe de volumes avec la commande chvg –t.
Une valeur de facteur adaptée est définie par défaut pour prendre en charge le plus grand
disque du groupe de volumes.
Si, par exemple, vous avez créé un groupe de volumes avec un disque de 9 Go et des
partitions de 4 Mo, le groupe de volumes contiendra 2 250 partitions environ. En utilisant
le facteur de conversion 3 (1016 * 3 = 3048), vous pouvez suivre 2 250 partitions
correctement. La conversion d’un groupe de volumes normal ou grand avec un facteur plus
élevé permet d’inclure un plus grand nombre de partitions jusqu’au facteur 1 016*. Vous
pouvez également définir un facteur plus élevé lorsque vous créez un groupe de volumes
pour prendre en charge un plus grand disque avec des partitions plus petites.
Cette opération réduit le nombre total de disques que vous pouvez ajouter à un groupe de
volumes. Le nouveau nombre maximum de disques que vous pouvez ajouter est
MAXPVS/facteur. Par exemple, pour un groupe de volumes normal, le facteur 2 ramène à
16 (32/2) le nombre de disques maximum dans le groupe de volumes. Pour un groupe de
volumes normal, le facteur 2 ramène à 64 (128/2) le nombre de disques maximum dans le
groupe de volumes. Pour un groupe de volumes évolutif, le facteur 2 ramène à 512 (1024/2)
le nombre de disques maximum dans le groupe de volumes.
3-6
Concepts de gestion de système AIX – Système d’exploitation et unités
LVM (Logical Volume Manager)
Les commandes du système d’exploitation, les sous–programmes de bibliothèque,
et les autres outils permettant de réaliser et de contrôler le stockage de volume logique
forment un ensemble appelé LVM (Logical Volume Manager). LVM contrôle les ressources
disque en associant des données entre une vue logique plus simple et plus souple et les
disques physiques. LVM effectue cette opération en utilisant une couche de code de pilotes
d’unité qui s’exécute au–dessus des pilotes d’unité de disque traditionnels.
LVM est constitué du pilote LVDD (Logical Volume Device Driver) et de la bibliothèque
d’interfaces de sous–routines LVM. Le pilote LVDD (Logical Volume Device est un
pseudo–pilote d’unité qui gère et traite toutes les E/S. Il convertit les adresses logiques en
adresses physiques et envoie les demandes E/S à des pilotes d’unités spécifiques. La
bibliothèque d’interfaces de sous–routines contient des routines utilisées par le les
commandes de gestion du système pour effectuer des tâches de gestion de système pour
les volumes logiques et physiques d’un système.
Pour plus d’informations sur le fonctionnement de LVM, voir Understanding the Logical
Volume Device Driver dans le document AIX 5L Version 5.3 Kernel Extensions and Device
Support Programming Concepts et Logical Volume Programming Overview dans le
document AIX 5L Version 5.3 General Programming Concepts:
Concepts de quorum
Les sections suivantes décrivent la procédure de mise en service et le quorum qui
correpond au mécanisme qu’utilise LVM pour garantir qu’un groupe de volumes est prêt
à être utilisé et qu’il contient les données les plus à jour.
Procédure de mise en service
Les commandes varyonvg et varyoffvg activent et désactivent (rendent disponible et
indisponible) un groupe de volumes que vous avez défini dans le système. Le groupe de
volumes doit être activé pour que le système puisse y accéder. Au cours de l’activation,
LVM lit les données de gestion sur les volumes physiques définis dans le groupe de
volumes. Ces données de gestion, qui incluent une zone VGDA (Volume Group Descriptor
Area) et une zone VGSA (Volume Group Status Area), sont stockées dans chaque volume
physique du groupe de volumes.
La zone VGDA contient des informations qui décrivent l’association des partitions physiques
et des partitions logiques de chaque volume logique du groupe de volumes ainsi que des
informations importantes telles que la date et l’heure. La zone VGSA contient, par exemple,
des informations sur les partitions physiques périmées et les volumes physiques manquants
(non disponibles ou actifs) lorsqu’une activation est tentée dans un groupe de volumes.
Si la procédure d’activation ne peut pas accéder à un ou plusieurs volumes physiques
définis dans le groupe de volumes, la commande affiche les noms de tous les volumes
physiques du groupe de volumes et leur état. Cela vous permet de décider d’activer ou non
le groupe de volumes.
Quorum
Un quorum est le rapport entre le nombre de zones VGDA et de zones VGSA actives. Un
quorum garantit l’intégrité des données des zones VGDA/VGSA en cas de défaillance du
disque. Chaque disque physique d’un groupe de volumes dispose d’au moins une zone
VGDA/VGSA. Lorsque vous créez un groupe de volumes sur un disque, le disque contient
deux zones VGDA/VGSA. Si un groupe de volumes est constitué de deux disques, un
disque contient deux zones VGDA/VGSA et le second disque contient une zone
VGDA/VGSA. Lorsqu’un groupe de volumes est constitué d’au moins trois disques, chaque
disque contient une seule zone VGDA/VGSA.
Le quorum est perdu lorsqu’un nombre suffisant de disques et leurs VGDA/VGSA ne sont
pas accessibles de sorte que 51 % des zones VGDA/VGSA n’existent plus. Dans un groupe
de volumes à deux disques, si le disque qui contient une seule zone VGDA/VGSA est
Volumes logiques
3-7
défaillant, un quorum existe toujours, car deux des trois zones VGDA/VGSA sont toujours
accessibles. Si le disque avec deux zones VGDA/VGSA est défaillant, le quorum n’existe
plus. Les risques de perte de quorum en cas de défaillance d’un disque sont inversement
proportionnels au nombre de disques dans un groupe de volumes.
Lorsque le quorum est perdu, le groupe de volumes se désactive automatiquement pour
que LVM ne puisse plus accéder aux disques. Cela évite de créer d’autres E/S dans le
groupe de volumes pour que les données ne soient pas perdues ou supposées avoir été
écrites lors de l’incident physique. En outre, suite à la désactivation, l’utilisateur reçoit un
message d’erreur dans le journal des erreurs indiquant qu’un incident matériel s’est produit
et qu’une opération de maintenance est nécessaire.
Il existe des cas dans lesquels il préférable de continuer à utiliser le groupe de volumes,
même si le quorum n’existe plus. Dans ce cas, vous pouvez désactiver la vérification du
quorum du groupe de volumes. Ce type de groupe de volumes s’appelle un groupe de
volumes sans quorum. En règle générale, un groupe de volumes sans quorum existe
lorsque les volumes logiques sont mis en miroir. Lorsqu’un disque est défaillant, les
données ne sont pas perdues s’il existe une copie du volume logique sur un disque actif
accessible. Toutefois, il peut arriver que, dans des groupes de volumes sans quorum, mis
en miroir ou non, les données (y compris les données) résident sur le disque ou les disques
qui sont indisponibles. Dans ce cas, les données peuvent ne pas être accessibles, même si
le groupe de volumes est toujours actif.
Groupes de volumes sans quorum
LVM (Logical Volume Manager) désactive automatiquement le groupe de volumes lorsque
le quorum de zones VGDA ou VGSA n’est pas respecté. Toutefois, vous pouvez choisir une
option qui permet au groupe de rester actif dès qu’il existe une zone VGDA/VGSA intacte.
Cette option produit un groupe de volumes sans quorum. LVM doit pouvoir accéder à tous
les disques des groupes de volumes sans quorum pour pouvoir permettre la réactivation et
garantir que les zones VGDA et VGSA contiennent des données à jour.
Vous pouvez utiliser cette procédure sur des systèmes dont chaque volume logique dispose
d’au moins de deux copies. En cas de défaillance de disque, le groupe de volumes reste
actif tant qu’il existe un disque actif.
Remarque :
3-8
Les groupes de volumes définis par l’utilisateur et le groupe de volumes
rootvg peuvent fonctionner sans quorum, mais les méthodes utilisées pour
configurer les groupes de volumes utilisateur et le groupe de volumes
rootvg comme groupes de volumes sans quorum et pour restaurer les
données à la suite d’incidents matériels sont différentes. Veillez à utiliser la
méthode adaptée au groupe de volumes.
Concepts de gestion de système AIX – Système d’exploitation et unités
Développement d’une stratégie relative aux groupes
de volumes
Une défaillance de disque est la panne matérielle la plus courante dans le système de
stockage, suivie par une défaillance des cartes et alimentations. La protection contre les
défaillances de disques implique avant tout la configuration de volumes logiques. Pour plus
d’informations, reportez–vous à la section Développement d’une stratégie de volume
logique, page 3-11. La taille des groupes de volumes peut être également déterminante.
Prévenir les défaillances d’alimentation et de cartes suppose une configuration matérielle
particulière pour tout groupe de volumes spécifiques, avec deux cartes et au moins un
disque par carte, avec utilisation de disques miroirs par le biais de cartes et une
configuration de groupe de volumes “nonquorum”. L’investissement en jeu pour de telles
configurations n’est pas à la portée de tous les sites ou systèmes. Il est surtout
recommandé lorsque la haute disponibilité est l’exigence prioritaire du système. Selon la
configuration, la haute disponibilité est apte à couvrir les incidents matériels se produisant
entre la dernière sauvegarde et l’entrée des données en cours; Elle ne couvre pas les
fichiers supprimés par accident.
Création de groupes de volumes distincts
Voici différentes raisons de structurer des volumes physiques en groupes de volumes
indépendants de rootvg :
• Pour sécuriser et faciliter les opérations de maintenance.
– Les mises à jour du système d’exploitation, les réinstallations et les reprises sur panne
système sont plus fiables avec des systèmes de fichiers utilisateur séparés du
système d’exploitation, préservant ainsi les fichiers utilisateur.
– Les opérations de maintenance sont facilitées : vous pouvez actualiser le système
d’exploitation ou le reinstaller sans restaurer les données utilisateur. Par exemple,
avant de lancer une mise à jour, vous pouvez retirer du système un groupe de
volumes utilisateur en démontant ses systèmes de fichiers, en le désactivant (avec la
commande varyoffvg), puis en exportant le groupe (avec la commande exportvg).
Ensuite, après la mise à jour, il suffit de réintégrer le groupe de volumes utilisateur
(avec la commande importvg), puis de remonter ses systèmes de fichiers.
• Pour définir des tailles de partitions physiques hétérogènes. Tous les volumes physiques
d’un même groupe de volumes doivent avoir la même taille de partition physique. Pour
que des volumes physiques aient des tailles de partition physique différentes, placez
chaque taille dans un groupe de volumes distinct.
• Pour définir des caractéristiques de quorum hétérogènes. Vous pouvez prévoir un groupe
de volumes distinct pour un système de fichiers de type “nonquorum”, tous les autres
systèmes de fichiers faisant partie du groupe de volumes soumis au quorum.
• Pour la sécurité. Par exemple, vous pouvez être amené à retirer de nuit un groupe de
volumes.
• Pour commuter des volumes physiques entre systèmes. La commutation de volumes
physiques entre systèmes est possible en créant un groupe de volumes par système
connecté à une carte accessible aux systèmes, ceci sans interrompre les opérations
en cours (voir les commandes varyoffvg, exportvg, importvg et varyonvg).
Volumes logiques
3-9
Haute disponibilité face aux incidents de disque
Les principales mesures de prévention des incidents de disque comprennent les définitions
de configuration de volume logique, telles que l’écriture miroir. Bien que secondaires, les
informations ci-après ont des répercussions économiques significatives, impliquant le
nombre de volumes physiques par groupe de volumes :
• La configuration avec quorum (valeur par défaut) maintient le groupe de volumes actif
(en service) tant que le quorum des disques (51%) existe. Pour plus d’informations sur
les conditions, reportez–vous à la section Processus de mise en service, page 3-7.
Dans la plupart des cas, vous devez utiliser au moins trois disques en plaçant leur image
miroir dans le groupe de volumes pour la protection contre les incidents de disque.
• La configuration sans quorum maintient le groupe de volumes actif (en service) tant
qu’une zone VGDA est disponible sur le disque (voir « Changing a Volume Group to
Nonquorum Status » dans le document AIX 5L Version 5.3 System Management Guide :
Operating System and Devices). Dans cette configuration, vous n’utilisez que deux
disques en plaçant leur image miroir dans le groupe de volumes pour la protection
contre les incidents de disque.
Lors de la détermination du nombre de disques associés à chaque groupe de volumes,
vous devez également prendre en compte l’espace nécessaire à la mise en miroir des
données. Notez que vous ne pouvez mettre en miroir les données et déplacer les données
qu’entre les disque qui appartiennent à un même groupe de volumes. Si le site utilise des
systèmes de fichiers volumineux, la recherche d’espace disque pour la mise en miroir
peut poser des problèmes ultérieurement. Tenez compte des conséquences sur la
disponibilité des paramètres inter disques pour les copies de volumes logiques (voir
Paramètres inter disques pour les copies de volumes logiques, page 3-16) et l’allocation
intra–disque (voir Détermination d’une stratégie d’allocation intra–disque pour chaque
volume logique, page 3-18) pour chaque volume logique.
Haute disponibilité face aux incidents de carte ou d’alimentation
Pour prévenir les incidents de carte ou d’alimentation, en fonction de la rigueur de vos
besoins :
• Utilisez deux cartes, installées ou non dans la même armoire. Si les cartes ne sont pas
situées dans la même armoire, elles seront toutes deux protégées en cas de problème
d’alimentation dans une armoire.
• Utilisez deux cartes et connectez un ou plusieurs disques sur chacune : ceci pour pré–
venir tout incident de carte (ou d’alimentation lorsque les cartes sont installées dans des
armoires séparées) en maintenant le quorum dans le groupe de volumes, compte tenu
de l’écriture miroir croisée (pour une partition logique, les copies ne pouvant partager le
même volume physique) entre les volumes logiques du disque A (carte A) et les volumes
logiques du disque B (carte B). Ceci signifie que vous copiez les volumes logiques des
disques connectés à la carte A sur les disques connectés à la carte B, et inversement.
• Configurez tous les disques à partir des deux cartes dans le même groupe de volumes.
Ainsi, au moins une copie de volume logique reste intacte si une carte est défectueuse,
ou, en cas d’armoires séparées, si l’alimentation est défaillante.
• Passez le groupe de volumes à l’état “nonquorum” Ainsi, le groupe reste actif tant qu’une
zone VGDA est accessible sur un disque quelconque du groupe. Reportez-vous à
“Passage d’un groupe de volumes à l’état nonquorum” dans le manuel AIX - Guide
d’administration : système d’exploitation et unités.
• Si le groupe de volumes possède deux disques, configurez l’écriture miroir croisées entre
les cartes. Si plusieurs disques sont connectés à chaque carte, configurez l’écriture
miroir double en créant une copie miroir sur un disque utilisant la même carte et une
autre sur un disque utilisant une autre carte.
3-10
Concepts de gestion de système AIX – Système d’exploitation et unités
Développement d’une stratégie relative aux volumes logiques
Les règles ci-après vous aideront à élaborer une stratégie en matière d’exploitation des
volumes logiques, orientée à la fois sur la disponibilité, les performances et le coût.
La disponibilité correspond à la possibilité d’accéder aux données, même si le disque
associé est défaillant ou inaccessible. Les données peuvent rester accessibles en les
copiant et en les gérant sur des disques et des cartes différents lorsque le système
fonctionne normalement. La mise en miroir et l’utilisation de disques de secours, par
exemple, permettent de garantir la disponibilité des données.
Les performances correspondent au délai d’accès moyen aux données.
L’écriture–vérification et la mise en miroir, par exemple, améliorent la disponibilité, mais
augmentent la charge de travail du système et affectent donc les performances. La mise
en miroir double ou triple la taille du volume logique. En règle générale, l’amélioration de la
disponibilité affecte les performances. L’entrelacement des disques peut améliorer les
performances. Depuis la version AIX 4.3.3, l’entrelacement peut être utilisé avec la mise en
miroir. Depuis la version AIX 5.1, vous pouvez détecter et résoudre les problèmes qui se
produisent lorsque des partitions logiques du disque sont soumises à un nombre excessif
d’opérations E/S qui affectent sensiblement les performances.
En contrôlant l’allocation des données sur le disque et entre les disques, vous pouvez régler
le système de stockage pour optimiser les performances. Pour plus d’informations sur la
manière d’optimiser les performances du système de stockage, reportez–vous au document
AIX 5L Version 5.3 Performance Management Guide.
Utilisez les sections suivantes pour évaluer les compromis entre les performances, la
disponibilité et les coûts. Notez que l’amélioration de la disponibilité dégrade généralement
les performances et vice versa. Toutefois, la mise en miroir améliore les performances si
LVM choisit de copier les données sur le disque le moins sollicité pour la lecture.
Remarque : La mise en miroir n’offre pas de protection contre la perte de fichiers
individuels supprimés ou perdus de manière accidentelle à la suite de problèmes
logiciels. Ces fichiers ne peuvent être restaurés que depuis une bande classique ou les
sauvegardes des disques.
Analyse des besoins associés à la mise en miroir et à l’entrelacement
Déterminez si les données stockées dans le volume logique sont suffisamment importantes
pour justifier le traitement et les coûts d’espace disque qu’impliquent la mise en miroir.
Si vous utilisez un système de fichiers à accès séquentiel volumineux dont l’efficacité
dépend des performances, envisagez d’utiliser l’entrelacement.
Performances et mise en miroir ne sont pas forcément antagonistes. Si les copies des
partitions logiques se trouvent sur des volumes physiques différents, connectés de
préférence à des cartes différentes, LVM peut améliorer les opérations de lecture en lisant
la copie sur le disque le moins utilisé. Les performances des opérations d’écriture, si les
disques ne sont pas connectés à des cartes différentes, ont le même coût, car vous devez
mettre à jour toutes les copies. Il est uniquement nécessaire de lire un seule copie pour une
opération de lecture.
LVM AIX prend en charge les options RAID suivantes :
Tableau 1. Prise en charge LVM pour RAID
RAID 0
Entrelacement
RAID 1
Mise en miroir
RAID 10 ou 0+1
Mise en miroir et entrelacement
Volumes logiques
3-11
Bien que la mise en miroir améliore la disponibilité du système de stockage, elle ne
remplace pas les sauvegardes sur bande classique.
Vous pouvez mettre en miroir le groupe de volumes rootvg, mais dans ce cas, créez un
volume logique cliché différent. La création d’un cliché dans un volume logique en miroir
peut générer un cliché incohérent. En outre, du fait que l’unité de cliché par défaut
correspond au volume logique de pagination principal, créez un volume logique cliché
différent si vous mettez en miroir les volumes logiques de pagination.
Normalement, lorsque les données d’une partition logique sont mises à jour, toutes les
partitions physiques qui contiennent la partition logique sont mises à jour automatiquement.
Toutefois, les partitions physiques peuvent devenir obsolètes (elles ne contiennent pas les
toutes dernières données) suite à des dysfonctionnements du système ou du fait de la
non–disponibilité du volume physique lors d’une mise à jour. LVM peut actualiser les
partitions obsolètes avec les informations appropriées en copiant les données en cours
depuis une partition physique à jour. Ce processus s’appelle la synchronisation de la mise
en miroir. L’actualisation peut avoir lieu lors du démarrage du système, lorsque le volume
physique est remis en ligne ou lorsque vous exécutez la commande syncvg.
Toute modification qui affecte la partition physique d’un volume logique d’amorçage
nécessite d’exécuter la commande bosboot à la suite de la modification. Cela implique que
des actions telles que la modification de la mise en miroir d’un volume logique d’amorçage
nécessite d’exécuter la commande bosboot.
Règles de programmation des écritures miroir sur disque
Pour des données qui n’ont qu’une copie physique, LVDD traduit l’adresse des demandes
de lecture ou d’écriture logique en adresse physique, et appelle le gestionnaire d’unités
physiques approprié pour traiter la demande. Cette politique de copie unique ou d’écriture
non miroir gère la réaffectation des blocs défectueux pour les demandes d’écriture et
renvoie toutes les erreurs de lecture au processus appelant.
Si vous utilisez des volumes logiques en miroir, vous pouvez définir quatre politiques de
programmation différentes pour l’écriture sur disque dans le cadre d’un volume logique avec
copies multiples : le traitement séquentiel, le traitement parallèle, l’écriture parallèle avec
lecture séquentielle et l’écriture parallèle avec lecture “round robin”.
3-12
Concepts de gestion de système AIX – Système d’exploitation et unités
Politique de traitement séquentiel
L’écriture sur plusieurs copies ou l’écriture miroir est traitée en séquence.
Plusieurs partitions physiques représentant les copies miroir d’une seule
partition logique sont qualifiées de primaires, secondaires et tertiaires.
Les partitions physiques sont écrites séquentiellement (l’une après l’autre).
Le système attend que l’opération d’écriture sur une partition physique soit
terminée avec de commencer l’opération d’écriture sur la partition suivante.
Une fois toutes les opérations d’écriture terminées sur tous les miroirs,
l’opération d’écriture globale est terminée.
Politique de traitement parallèle
En traitement parallèle, l’écriture de toutes les partitions physiques d’une
partition logique démarre en même temps. Elle prend fin après l’écriture de
la partition physique la plus longue. La définition de volumes logiques mis
en miroir et d’une stratégie de planification parallèle peut améliorer les
performances des opérations de lecture E/S, car plusieurs copies
permettent au système d’envoyer les opérations de lecture vers le disque le
moins utilisé du volume logique.
Politique d’écriture parallèle avec lecture séquentielle
L’écriture de toutes les partitions physiques d’une partition logique démarre
en même temps. La lecture s’effectue toujours d’abord sur la copie
primaire. Si elle n’aboutit pas, elle est effectuée sur la copie suivante. A la
seconde tentative de lecture sur la copie suivante, la copie primaire dont la
lecture a échoué est corrigée par LVM, avec une réaffectation matérielle.
Ceci permet de corriger le bloc défectueux pour un accès ultérieur.
Politique d’écriture parallèle avec politique de lecture “round robin”
L’écriture de toutes les partitions physiques d’une partition logique démarre
en même temps. Les lectures s’effectuent alternativement sur les
différentes copies en miroir.
Bad block policy
indique si le groupe de volumes est activé pour le repositionnement des
blocs erronés. La valeur par défaut est yes. Lorsque la valeur est définie
sur yes pour le groupe de volume, les blocs erronés peuvent être
repositionnés. Lorsque la valeur est définie sur no, la stratégie contourne
les paramètres des volumes logiques. Lorsque la valeur est modifiée, tous
les volumes logiques continuent avec les anciens paramètres. Cette valeur
indique si une demande d’E/S doit être dirigée vers un bloc repositionné.
Lorsque la valeur est définie sur yes, le groupe de volumes autorise le
repositionnement des blocs erronés. Lorsque la valeur est définie sur no,
l’affectation des blocs erronés n’est pas terminée.
Remarque :
Le repositionnement des blocs erronés est désactivé à
moins que les paramètres de stratégie de blocs erronés
pour le groupe de volumes et le volume logique ne soient
tous les deux définis sur yes.
MWC (cohérence écrit–miroir) pour un volume logique
Lorsqu’il est activé, MWC identifie les partitions logiques susceptibles d’être incohérentes
si le système ou le groupe de volumes n’est pas correctement fermé. Lorsque le groupe de
volumes est à nouveau mis en fonction, ces informations sont utilisées pour rendre
cohérentes les partitions logiques. On nomme cette opération MWC actif.
Lorsqu’un volume logique utilise le MWC actif, les requêtes portant sur ce volume logique
sont retenues dans la couche de programmation jusqu’à ce que les blocs de la mémoire
cache MWC puissent être mis à jour sur les volumes physiques cible. Une fois les blocs
Volumes logiques
3-13
de mémoire cache MWC mis à jour, la requête passe aux opérations d’écriture des données
physiques.
Les blocs de mémoire cache MWC ne doivent être écrits que sur les disques sur lesquels
les données résident effectivement avant que l’opération d’écriture puisse se poursuivre.
Lors de l’utilisation de MWC actif, les performances du système peuvent être réduites.
Ces effets sont causés par la charge de travail de la consignation ou la journalisation d’une
demande d’écriture dans laquelle un LTG (Logical Track Group) est actif. Les tailles de LTG
autorisées pour un groupe de volumes sont 128 K, 256 K, 512 K, 1 024 K, 2 Mo, 4 Mo,
8 Mo et 16 Mo.
Remarque :
Pour que la taille de LTG soit supérieure à 128 Ko, les disques faisant partie
du groupe de volumes doivent prendre en charge les demandes d’E/S de
cette taille à partir des routines de stratégie du disque. Le LTG est un bloc
contigu contenu dans le volume logique, dont l’alignement s’effectue en
fonction de sa taille. Les opérations d’E/S ne doivent pas dépasser la taille
d’un LTG, et doivent être contenues un seul LTG. Cette surcharge ne
s’applique qu’à la mise en miroir des opérations d’écriture.
Il est nécessaire d’assurer la cohérence des données entre les miroirs uniquement en cas
de panne du système ou du groupe de volumes avant la fin de l’écriture vers tous les
miroirs. Tous les volumes logiques d’un groupe de volumes partagent le journal MWC. Ce
dernier est tenu à jour sur le bord externe de chaque disque. Placez les volumes logiques
tirant partir de MWC actif sur le bord externe du disque, de façon qu’ils se trouvent à
proximité du journal MWC sur disque.
Lorsque MWC est à l’état passif, le groupe de volume consigne le fait que le volume logique
a été ouvert. Lorsque le groupe de volumes est mis en fonction après une panne, une
synchronisation forcée automatique du volume logique est lancée. La cohérence est
assurée pendant que la synchronisation forcée est en cours en faisant appel à une copie de
la politique de récupération de lecture qui propage les blocs en cours de lecture sur les
autres miroirs du volume logique. Cette règle n’est prise en charge que sur le type de
groupe de volumes BIG.
Lorsque MWC est désactivé, les miroirs d’un volume logique en miroir peuvent être laissés
dans un état incohérent au cas où le système ou le groupe de volumes tomberait en panne.
Il n’y a pas de protection automatique de la cohérence du miroir. Les écritures restant à
faire au moment de la panne peuvent laisser les miroirs dans un état incohérent lors de la
prochaine mise en fonction du groupe de volumes. Après une panne, un volume logique en
miroir avec MWC désactivé doit effectuer une synchronisation forcée avant l’utilisation des
données du volume. Par exemple :
syncvg –f –l LTV nom
Il y a exception à la synchronisation forcée dans le cas de volumes logiques dont le contenu
n’est valide que pendant l’ouverture du volume logique, par exemple les espaces de
pagination.
Un volume logique mis en miroir est identique à un volume logique non mis en miroir en
terme d’opération de lecture. Une fois LVM a fini de traiter une demande d’écriture, les
données sont écrites sur toutes les unités sous LVM. Le résultat de l’écriture est inconnu
jusqu’à ce que LVM exécute un processus iodone sur l’opération d’écriture. Une fois cette
opération terminée, aucune restauration n’est nécessaire après un blocage. Tout bloc écrit
non terminé (iodone) lors d’un blocage de la machine doit être vérifié et réécrit, quel que
soit le paramètre MWC ou qu’il soit mis en miroir ou non.
Du fait qu’un volume logique mis en miroir est identique à un volume logique non mis en
miroir, il ne peut y avoir de problème d’actualisation de données de ce type. Toutes les
applications qui doivent tenir compte de la validité des données doivent déterminer la
validité des données des opérations d’écriture en attente ou en cours lors de l’incident sur le
groupe de volume ou la défaillance du système que le volume logique soit mis en miroir ou
non.
3-14
Concepts de gestion de système AIX – Système d’exploitation et unités
Le MWC actif et passif ne rendent les miroirs cohérents que lorsque le groupe de volumes
est remis en fonction après une panne, en choisissant un miroir et en propageant ces
données sur les autres miroirs. Les règles MWC ne conservent pas la trace des dernières
données. Le MWC actif n’assure que le suivi des LTG en cours d’écriture. Il ne garantit donc
pas la propagation des dernières données à tous les miroirs. Le MWC passif assure la
cohérence des miroirs en passant dans un mode de propagation sur lecture après une
panne. C’est l’application au-dessus de LVM qui détermine la validité des données après
une panne. D’après la perspective LVM, si l’application réémet toujours toutes les
demandes d’écriture en suspens au moment de la panne, les miroirs éventuellement
incohérents deviendront cohérents à la fin des opérations d’écriture (du moment que les
blocs écrits sont les mêmes que ceux en suspens au moment de la panne).
Remarque :
Les volumes logiques en miroir contenant des journaux JFS ou des
systèmes de fichiers doivent être synchronisés après une panne, soit par
synchronisation forcée avant utilisation, en activant MWC, soit en activant le
MWC passif.
Règles d’affectation inter-disque
Cette procédure permet de spécifier le nombre de disques sur lesquels sont situées les
partitions physiques du volume logique. Celles-ci peuvent être placées sur un seul disque
ou réparties sur l’ensemble des disques. Les options suivantes sont utilisées avec les
commandes mklv et chlv pour déterminer la stratégie inter disque :
• Range définit le nombre de disques utilisés pour une copie physique unique du volume
logique.
• Strict détermine si mklv peut aboutir lorsque plusieurs copies doivent occuper le même
volume physique.
• L’option Super Strict définit que les partitions allouées à un miroir ne peuvent pas
partager un volume physique avec les partitions d’un autre miroir.
• Si les volumes logiques sont répartis sur plusieurs disques, les seules valeurs admises
pour Range et Strict sont maximum et yes.
Copie unique du volume logique
Si vous optez pour l’affectation inter- (Range = minimum), les partitions physiques
affectées au volume logique seront situées sur un seul disque, afin d’accroître la
disponibilité. Avec l’affectation inter-disque optimale (Range = maximum), les partitions
physiques sont situées sur plusieurs disque pour améliorer la performance. L’affectation de
copies miroir aux partitions d’origine est décrite dans la section suivante.
Pour les volumes logiques de type ”non miroir”, prenez la valeur minimum qui confère au
système une disponibilité optimale (quant à l’accès aux données en cas de d’incident
matériel). Le paramètre minimum indique qu’un volume physique doit contenir, si possible,
toutes les partitions physiques d’origine de ce volume. Si le programme d’affectation a
besoin de plusieurs volumes physiques, il utilise le nombre minimal, tout en restant
cohérent par rapport aux autres paramètres.
En utilisant le nombre minimal de volumes physiques, vous réduisez le risque de perdre des
données en cas de défaillance d’un disque. Tout volume physique supplémentaire utilisé
pour une copie physique unique accroît ce risque. En cas de défaillance d’un volume
physique, le risque de perdre des données pour un volume logique de type ”non miroir”
réparti sur quatre volumes physiques est quadruplé par rapport à un volume logique logé
dans un seul volume physique.
La figure ci-après illustre une affectation inter-disque minimale.
Figure 3. Stratégie d’allocation inter disque minimum Cette illustration contient trois
disques. Un disque contient trois partitions physiques et les deux autres disques ne
contiennent pas de partitions physiques.
Volumes logiques
3-15
Partitions physiques
Le paramètre maximum, compte tenu d’autres contraintes, répartit de façon aussi égale
que possible, les partitions physiques du volume logique sur le plus grand nombre de
volumes physiques possible. Cette option vise la performance, en tendant à réduire le
temps d’accès du volume logique. Pour améliorer la disponibilité, elle ne doit être utilisée
qu’avec des volumes logiques avec traitement miroir.
La figure ci–après illustre une affectation inter–disque optimale.
Figure 4. Stratégie d’allocation inter disque maximum Cette illustration contient trois
disques contenant chacun une partition physique.
Partition physique 1
Partition physique 2
Partition physique 3
Ces paramètres sont également applicables à l’extension et à la copie d’un volume logique
existant. L’affectation de nouvelles partitions physiques est déterminée en fonction de la
politique en cours, ce à l’emplacement où sont situées les partitions physiques existantes.
Copies multiples du volume logique
L’affectation d’une seule copie d’un volume logique est une procédure relativement simple.
Toutefois, lors de la création de copies miroir, l’affectation résultante est quelque peu
complexe. Les figures suivantes illustrent l’emploi des paramètres minimum et maximum
(Range) pour la première instance d’un volume logique, et les définitions possibles de strict
pour les copies miroir de ce volume.
Par exemple, avec des copies miroir du volume logique, minimum permet d’affecter, si
possible, les partitions physiques contenant la première instance du volume logique sur un
seul volume physique. Puis, en fonction de la définition de Strict, la ou les copies
supplémentaires sont affectées sur le même volume physique ou sur des volumes distincts.
Autrement dit, l’algorithme utilise le plus petit nombre possible de volumes physiques, en
respectant les contraintes imposées par les autres paramètres tels que Strict, pour
maintenir toutes les partitions physiques.
Strict = y signifie que chaque copie de la partition logique est placée sur un volume
physique différent. Strict = n signifie que les copies ne sont pas tenues d’être situées
sur des volumes distincts. En comparaison, l’option Super Strict ne permet pas à une
3-16
Concepts de gestion de système AIX – Système d’exploitation et unités
partition physique d’un miroir de se trouver sur le même disque qu’une partition physique
d’un autre miroir du même volume logique.
Remarque :
Lorsque le nombre de volumes physiques du groupe est inférieur au nombre
de copies par partition logique sélectionnée, affectez la valeur n à Strict. Si
Strict = y, un message d’erreur est renvoyé quand vous tentez de créer le
volume logique.
La figure Affectation inter–disque minimale/ Strict illustre une règle d’affectation inter–disque
minimale avec différents paramètres Strict :
Figure 5. Stratégie inter disque minimum/Option Strict Cette figure montre que si
l’option Strict est affectée de la valeur Yes, chaque copie de la partition logique se trouve
sur un volume physique différent. Si l’option Strict est affectée de la valeur No, toutes les
copies des partitions logiques se trouvent dans le même volume physique.
hd2
hd1
hd1
copie 2
hd2
copie 2
hd1
copie 3
hd2
copie 3
Affectation inter-disque minimale avec une
seule copie du volume logique par disque (Strict = y)
hd1
copie 3
hd2
copie 3
hd1
copie 2
hd2
copie 2
hd1
copie 1
hd2
copie 1
Affectation inter-disque minimale avec
plusieurs copies du volume logique par disque (Strict = n)
La figure Affectation inter-disque optimale/Strict illustre une règle d’affectation inter-disque
optimale avec différents paramètres Strict :
Volumes logiques
3-17
Figure 6. Stratégie inter disque maximum/Option Strict Cette figure montre que si
l’option Strict est affectée de la valeur Yes, chaque copie d’une partition se trouve sur un
volume physique différent. Si l’option Strict est affectée de la valeur No, toutes les copies
des partitions logiques se trouvent dans le même volume physique.
hd1
partition 2
(copie 1)
hd1
partition 1
(copie 2 )
hd1
partition 1
(copie 1)
hd1
partition 1
(copie 1)
hd1
partition 1
(copie 2)
hd1
partition 2
(copie 2)
Affectation inter-disque optimale avec une
seule copie du volume logique par disque (Strict = y)
hd1
partition 2
(copie 1)
hd1
partition 2
(copie 2)
Affectation inter-disque optimale avec plusieurs
copies du volume logique par disque (Strict = n)
Règles d’affectation intra-disque
Plus une partition physique est proche du centre d’un volume physique, plus le temps de
recherche moyen est rapide, la distance de recherche moyenne étant la plus réduite par
rapport aux autres zones du disque.
Le journal du système de fichiers est un bon candidat pour l’allocation au centre d’un
volume physique du fait qu’il est très fréquemment utilisé par le système d’exploitation.
A l’autre extrémité, le volume logique d’amorçage est utilisé peu fréquemment et il se trouve
donc au bord ou au milieu du volume physique.
En règle générale, plus les E/S (en valeur absolue ou pendant l’exploitation d’une
application importante) sont nombreuses, plus les partitions physiques du volume logique
doivent être affectées près du centre des volumes physiques. Deux exceptions à cette
règle :
Il existe une exception importante à cette règle : Les volumes logiques mis en miroir avec
l’option MWC (Mirror Write Consistency) affectée de la valeur On se trouvent sur le bord
extérieur, car il s’agit de l’emplacement dans lequel le système écrit les données MWC. Si la
mise en miroir n’est pas active, MWC ne s’applique pas et n’affecte pas les performances.
3-18
Concepts de gestion de système AIX – Système d’exploitation et unités
Les choix de stratégies d’allocation intra–disque reposent sur les cinq régions d’un disque
dans lesquelles les partitions physiques peuvent être allouées. Les cinq régions sont les
suivantes :
1. outer edge
2. inner edge
3. outer middle
4. inner middle
5. center
La politique d’affectation intra-disque est fondée sur les cinq régions de disque où placer les
partitions physiques. Ces cinq régions sont : outer edge (bord extérieur), inner edge (bord
intérieur), outer middle (milieu extérieur), inner middle (milieu intérieur), et center (centre).
Au bord, le temps de recherche moyen est le plus lent, d’où des temps de réponse plus
longs pour les applications. Les partitions du centre ont le temps de recherche moyen
optimal, donc les meilleurs temps de réponse. Toutefois, le centre contient moins de
partitions sur un volume physique que les autres régions du disque.
Affectations combinées
Le choix de politiques d’affectation inter-disque et intra-disque incompatibles peut générer
des résultats imprévisibles. Le système donnera la priorité à un type d’affectation. Par
exemple, si vous optez pour une affectation intra-disque de type ”center” au centre et
inter-disque de type minimum, l’affectation inter-disque sera prioritaire. Le système placera,
si possible, toutes les partitions du volume logique sur un seul disque, même si elles ne
tiennent pas toutes au centre du disque. Avant de combiner différentes politiques,
assurez-vous d’en avoir assimilé les interactions.
Affectation affinée avec des fichiers mappe
Si les options par défaut des politiques d’affectation interdisque et intradisque ne sont pas
adaptées à vos besoins, vous pouvez créer des fichiers mappe pour spécifier l’ordre et
l’emplacement exacts des partitions physiques d’un volume logique.
Vous pouvez utiliser WSM (Web–based System Manager), SMIT ou la commande mklv –m
pour créer des fichiers de mappes.
Par exemple, pour créer un volume logique de dix partitions nommé lv06 dans rootvg
en partitions 1 à 3, 41 à 45 et 50 à 60 sur le disque hdisk1, procédez comme suit :
1. Pour vérifier si les partitions physiques que vous envisagez d’utiliser peuvent être
allouées, tapez :
lspv –p hdisk1
2. Créez un fichier, tel que /tmp/mymap1, contenant :
hdisk1:1–3
hdisk1:41–45
hdisk1:50–60
La commande mklv affectera les partitions physiques dans l’ordre où elles figurent dans
le fichier mappe. Assurez-vous que ce fichier contient un nombre suffisant de partitions
à affecter à l’ensemble du volume logique spécifié par la commande mklv. (Au besoin,
vous pouvez en afficher la liste.)
3. Exécutez la commande :
mklv –t jfs –y lv06 –m /tmp/mymap1 rootvg 10
Volumes logiques
3-19
Développement d’une stratégie relative à la répartition
du volume logique
La répartition des volumes logiques concerne les systèmes de fichiers séquentiels
volumineux, sensibles aux performances, et à forte fréquence d’accès. Ce procédé vise à
améliorer les performances.
Remarque :
un espace de cliché ou un volume logique d’amorçage ne peut être
entrelacé. Le volume logique d’amorçage doit correspondre à des partitions
physiques contiguës.
Pour créer le volume logique entrelacé à 12 partitions 1v07 dans NomGV avec une taille de
segment de 16 Ko sur hdisk1, hdisk2 et hdisk3, tapez :
mklv –y lv07 –S 16K NomVG 12 hdisk1 hdisk2 hdisk3
Pour créer un volume logique de 12 partitions nommé lv08 dans NomVG réparti sur trois
disques quelconques, avec une taille de 8 Ko pour la répartition, entrez :
mklv –y lv08 –S 8K –u 3 NomVG 12
Pour plus de détails sur l’amélioration des performances avec cette stratégie, reportez-vous
à AIX 5L Version 5.3 - Guide d’optimisation.
Règles de contrôle de l’écriture
L’option de contrôle de l’écriture lit en temps réel toutes les opérations d’écriture pour
vérifier qu’elles sont lisibles. Un message d’erreur s’affiche lorsqu’elles sont incorrectes.
Cette option améliore la disponibilité, ceci au détriment de la performance, en raison du
temps de lecture nécessaire. Vous pouvez définir cette option sur un volume logique lors
de sa création (mklv) ou, ultérieurement, en le modifiant (chlv).
Détermination des stratégies de disques de secours remplaçables
à chaud
Depuis la version AIX 5.1, vous pouvez définir des disques comme disques de secours
remplaçables à chaud pour un groupe de volumes avec des volumes logiques mis en miroir.
Lorsque vous définissez les disques de secours remplaçables à chaud, vous pouvez définir
une stratégie en cas de défaillance d’un ou de plusieurs disques, ainsi que les
caractéristiques de synchronisation. Ce support complète mais ne remplace pas le support
de création de disques de secours disponible avec les disques SSA (Serial Storage
Architecture). Vous pouvez également utiliser des disques de secours remplaçables à
chaud lorsque vous en ajoutez un au groupe de volumes.
Si vous ajoutez un volume physique à un groupe de volumes (pour le définir comme disque
de secours remplaçable à chaud), le disque doit avoir au minimum la même capacité que le
plus petit disque du groupe de volumes. Lorsque cette fonction est mise en œuvre, les
données sont envoyées vers un disque de secours remplaçable à chaud lorsque les échecs
d’écriture MWC (Mirror Write Consistency) marquent un volume physique manquant.
Les commandes de prise en charge des disques de secours remplaçables à chaud, chvg
et chpv, fournissent diverses options de mise en oeuvre de la fonction sur votre site,
comme l’indique la syntaxe suivante :
chvg –h
stratégie_remplacement_à_chaud
Groupe_volumes
–s
stratégie_synchronisation
où stratégie_remplacement_à_chaud définit l’une des stratégies suivantes à utiliser en cas
de défaillance d’un disque :
3-20
y
Transfère automatiquement les partitions du disque défaillant vers un
disque de secours. Dans le groupe de disques de secours remplaçables à
chaud, le plus petit disque ayant la capacité suffisante pour remplacer le
disque défaillant est utilisé.
Y
Transfère automatiquement les partitions du disque défaillant, mais peut
utiliser l’ensemble des disques de secours remplaçables à chaud.
Concepts de gestion de système AIX – Système d’exploitation et unités
n
Ne transfère pas automatiquement les partitions (valeur par défaut).
r
Supprime tous les disques du groupe de disques de secours remplaçables
à chaud du groupe de volumes.
L’argument stratégie_synchronisation indique si vous voulez synchroniser automatiquement
les partitions contenant des données obsolètes :
y
Tente automatiquement de synchroniser les partitions obsolètes.
n
Ne synchronise pas automatiquement les partitions obsolètes.
(il s’agit de l’option par défaut).
L’argument Groupe_volumes définit le nom du groupe de volumes associé mis en miroir.
Gestion des zones actives dans les volumes logiques
Depuis la version AIX 5.1, vous pouvez identifier les zones actives des volumes logiques et
résoudre les problèmes sans arrêter le système. Un problème de zone active se produit
lorsque le nombre d’E/S traitées par des partitions logiques du disque affectent de manière
significative les performances.
La première étape pour résoudre le problème consiste à l’identifier. Par défaut, le système
ne collecte pas de statistiques sur l’utilisation du volume logique. Lorsque vous activez la
collecte des statistiques et que vous entrez la commande lvmstat pour la première fois, le
système affiche des valeurs de compteurs depuis le dernier réamorçage. Ensuite, chaque
fois que vous entrez la commande lvmstat, le système affiche la différence par rapport à la
commande lvmstat précédente.
En interprétant le résultat de la commande lvmstat, vous pouvez identifier les partitions
logiques ayant le trafic le plus élevé. Si des partitions logiques d’un disque sont très
utilisées et que vous voulez équilibrer les partitions sur les disques disponibles, vous
pouvez utiliser la commande migratelp pour transférer ces partitions logiques vers d’autres
disques physiques.
Dans l’exemple suivant, la collecte des statistiques est active et la commande lvmstat est
utilisée de manière répétitive pour collecter des statistiques de base :
# lvmstat –v rootvg –e
# lvmstat –v rootvg –C
# lvmstat –v rootvg
Le résultat se présente comme suit :
Logical Volume
hd8
paging01
lv01
hd1
hd3
hd9var
hd2
hd4
hd6
hd5
iocnt
Kb_read
4
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Kb_wrtn
16
0
0
0
0
0
0
0
0
0
Kbps
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
Volumes logiques
3-21
La sortie précédente montre que tous les compteurs sont remis à zéro. Dans l’exemple
suivant, les données sont d’abord copiées du répertoire /unix vers le répertoire /tmp.
La sortie de la commande lvmstat reflète l’activité du groupe de volumes rootvg :
# cp –p /unix /tmp
# lvmstat –v rootvg
Logical Volume
hd3
hd8
hd4
hd2
paging01
lv01
hd1
hd9var
hd6
hd5
iocnt
296
47
29
16
0
0
0
0
0
0
Kb_read
0
0
0
0
0
0
0
0
0
0
Kb_wrtn
6916
188
128
72
0
0
0
0
0
0
Kbps
0.04
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
La sortie indique l’activité du volume logique hd3 qui est monté dans le répertoire /tmp, sur
hd8 qui correspond au volume logique du journal JFS, sur hd4 qui correspond à / (racine),
sur hd2 qui correspond au répertoire /usr et sur hd9var qui correspond au répertoire /var.
La sortie suivante fournit des informations sur hd3 et hd2 :
# lvmstat –l hd3
Log_part
mirror#
1
1
3
1
2
1
4
1
# lvmstat –l hd2
Log_part
mirror#
2
1
3
1
7
1
4
1
9
1
14
1
1
1
iocnt
299
4
0
0
Kb_read
0
0
0
0
Kb_wrtn
6896
52
0
0
Kbps
0.04
0.00
0.00
0.00
iocnt
9
9
9
4
1
1
0
Kb_read
0
0
0
0
0
0
0
Kb_wrtn
52
36
36
16
4
4
0
Kbps
0.00
0.00
0.00
0.00
0.00
0.00
0.00
La sortie d’un groupe de volumes fournit un résumé de toute l’activité E/S d’un volume
logique. La sortie indique le nombre de demandes E/S (iocnt), le nombre de kilo–octets lus
et écrits (Kb_read et Kb_wrtn) et le débit du transfert des données en Kbps. Si vous
demandez les informations relatives à un volume logique, vous recevez les mêmes
informations pour chaque partition logique. S’il existe des volumes logiques mis en miroir,
vous affichez les statistiques de chaque volume mis en miroir. Dans l’exemple de sortie
précédent, plusieurs lignes de partitions logiques sans activité ont été omises. La sortie est
toujours triée en ordre décroissant dans la colonne iocnt.
La commande migratelp utilise comme paramètres le nom du volume logique, le numéro
de partition logique (tel qu’il est affiché par la commande lvmstat) et un numéro facultatif de
copie miroir. Si des informations sont omises, la première copie miroir est utilisée. Vous
devez définir le volume physique cible du transfert. En outre, vous pouvez spécifier un
numéro de partition physique cible. Si l’opération aboutit, la sortie se présente comme suit :
# migratelp hd3/1 hdisk1/109
migratelp: Mirror copy 1 of logical partition 1 of logical volume
hd3 migrated to physical partition 109 of hdisk1.
Lorsque vous activez la fonction de zone active sur un volume logique ou un groupe de
volumes, vous pouvez définir les rapports et les statistiques, afficher les statistiques,
sélectionner les partitions logiques à migrer, définir la partition physique de destination et
vérifier les informations avant de valider les modifications. Web-based System Manager
vous aide à définir les rapports de zone active et gérer le résultat. Pour plus d’informations
sur les instructions d’activation des rapports de zone active, reportez–vous au document
AIX 5L Version 5.3 System Management Guide: Operating System and Devices
3-22
Concepts de gestion de système AIX – Système d’exploitation et unités
Mise en œuvre de stratégies de groupe de volumes
Après avoir déterminé les stratégies de groupes de volumes à utiliser, analysez la
configuration actuelle en tapant la commande lspv sur la ligne de commande. La
configuration standard fournit un groupe de volumes unique qui contient plusieurs volumes
physiques connectés à la même carte de disque et d’autres matériels de stockage. Dans
une configuration standard, plus le nombre de disques constituant un groupe de volumes à
quorum est élevé, plus il est aisé de respecter le quorum en cas de défaillance de disque.
Dans un groupe sans quorum, le groupe de volumes doit être constitué d’au moins deux
disques. Pour mettre en œuvre la modification de votre stratégie de groupe de volumes,
procédez comme suit :
1. Utilisez la commande lspv pour vérifier les volumes alloués et les volumes physiques
libres.
2. Définissez un quorum en ajoutant un ou plusieurs volumes physiques. Pour plus
d’informations, reportez–vous à section Ajout de disques lorsque le système reste
disponible, Ajout d’un disque fixe sans données à un groupe de volumes existant ou
Ajout d’un disque fixe sans données à un nouveau groupe de volumes.
3. Pour convertir un groupe de volumes en groupe de volumes sans quorum,
reportez–vous à la section Conversion d’un groupe de volumes en groupe de volumes
sans quorum.
4. Reconfigurez le matériel uniquement pour garantir une disponibilité optimale.
Pour plus d’informations, reportez–vous au guide de maintenance de votre système.
Volumes logiques
3-23
3-24
Concepts de gestion de système AIX – Système d’exploitation et unités
Chapitre 4. Espace de pagination et mémoire virtuelle
AIX utilise la mémoire virtuelle pour accéder à une plus grande quantité de mémoire que
n’en dispose physiquement le système. La gestion des pages de mémoire en RAM ou sur
disque est effectuée par VMM (Virtual Memory Manager). Les segments de mémoire
virtuelle sont partitionnés en unités appelées pages. Un espace de pagination est un type
de volume logique associé un espace disque qui contient des informations qui résident en
mémoire virtuelle, mais qui ne sont actuellement utilisées. Ce volume logique dispose d’un
type d’attribut de pagination et s’appelle généralement espace de pagination ou espace
d’échange. Lorsque la quantité de mémoire RAM libre du système est faible, les
programmes ou les données qui n’ont pas été utilisées récemment sont transférés de
la mémoire vers l’espace de pagination pour libérer la mémoire.
Pour plus d’informations sur la gestion des espaces de pagination ou de la mémoire
virtuelle, reportez–vous à la section Paging Space and Virtual Memory dans le document
AIX 5L Version 5,3 System Management Guide: Operating System and Devices.
Espace de pagination et mémoire virtuelle
4-1
Généralités sur VMM (Virtual Memory Manager)
VMM (Virtual Memory Manager) gère les demandes de mémoire du système et de ses
applications. Des segments de mémoire virtuelle sont partitionnés en unités appelées
pages, chaque page étant située dans la mémoire physique réelle (RAM) ou sur disque tant
que cela est nécessaire. AIX utilise la mémoire virtuelle pour accéder à une plus grande
quantité de mémoire que n’en dispose physiquement le système. La gestion des pages de
mémoire en RAM ou sur disque est effectuée par VMM.
Gestion de la mémoire réelle
Dans AIX, les segments de mémoire virtuelle sont partitionnés en unités de 4 096 octets
appelés pages. La mémoire réelle est divisée en cadres de page de 4 096 octets. VMM
remplit deux fonctions principales :
• Il gère l’allocation des cadres de page.
• Il résout les références aux pages de mémoire virtuelle qui se trouvent en mémoire RAM
(stockées dans l’espace de pagination) ou qui n’existent pas encore.
Pour exécuter ces fonctions, VMM gère une liste libre de cadres de page disponibles. VMM
utilise également un algorithme de remplacement de page pour déterminer les pages de
mémoire virtuelle dans la mémoire RAM dont les cadres de page doivent être réaffectés à la
liste libre. Cet algorithme tient compte de l’existence des segments persistants par rapport
aux segments actifs, de la repagination et des seuils VMM.
Liste libre
VMM gère une liste de cadres de page libres (non alloués) qui est utilisée pour résoudre les
erreurs de pages. AIX tente d’utiliser en permanence toute la mémoire RAM, mais conserve
une petite quantité de mémoire dans la liste libre. Pour gérer cette petite quantité de pages
non allouées, VMM utilise page outs et page steals pour libérer de l’espace et réaffecter les
pages à la liste libre. Les pages de mémoire virtuelle dont les cadres de page ne sont pas
réaffectés sont sélectionnés en utilisant l’algorithme de remplacement de page de VMM.
Segments de mémoire persistants et segments de mémoire actifs
AIX utilise deux types de segments de mémoire. Pour comprendre VMM, il est important de
comprendre la différence existant entre les segments persistants et les segments actifs. Un
segment persistant dispose d’un emplacement de stockage permanent sur le disque. Les
fichiers qui contiennent des données ou des programmes exécutables sont associés à des
segments persistants. Lorsqu’un fichier JFS ou JFS2 est ouvert ou que le système y
accède, les données du fichier sont copiés vers la mémoire RAM. Les paramètres VMM
contrôlent le moment où les cadres de mémoire physique alloués aux pages persistantes
doivent être remplacés et utilisés pour stocker d’autres données.
Les segments actifs sont temporaires et existent uniquement lorsqu’ils sont utilisés par un
processus. Ces segments n’ont pas d’emplacement de stockage sur disque. La pile des
processus et les régions de données sont associées à des segments actifs et à des
segments texte partagés dans la bibliothèque. Les pages de segments actifs doivent
également se trouver dans des emplacements de stockage sur disque lorsqu’elles ne
peuvent pas être conservées dans la mémoire réelle. L’espace de pagination du disque est
utilisé à cet effet. Lorsqu’un programme se termine, toutes les pages actives sont replacées
immédiatement dans la liste libre.
4-2
Concepts de gestion de système AIX – Système d’exploitation et unités
Segments actifs et espace de pagination
Les pages actives dans la mémoire RAM qui peuvent être modifiées et sortie de la mémoire
sont affectées d’une fenêtre d’espace de pagination. L’espace de pagination alloué est
utilisé uniquement si la page doit être sortie de la mémoire. Toutefois, une page allouée
dans l’espace de pagination ne peut pas être utilisée par une autre page. Elle reste
réservée à une page particulière tant que la page existe dans la mémoire virtuelle. Du fait
que les pages persistantes sont placées dans le même emplacement d’origine sur le
disque, il n’est pas nécessaire d’allouer un espace de pagination aux pages persistantes
en mémoire RAM.
VMM utilise deux modes d’allocation d’espace de pagination : Early et Late. Chaque
stratégie d’allocation Early réserve un espace de pagination lorsqu’une demande de
mémoire pour une page active est effectuée. La stratégie d’allocation Late affecte
uniquement un espace de pagination lorsque la page active est sortie de la mémoire,
ce qui réduit sensiblement les besoins d’espace de pagination du système.
Fonction VMM Memory Load Control Facility
Lorsqu’un processus fait référence à une page de mémoire virtuelle sur disque, car il est
sortie de la mémoire ou n’a jamais été lu, la page référencée doit être remise en mémoire,
ce qui peut amener une ou plusieurs pages à être sorties de la mémoire si le nombre de
cadres de page (libres) est faible. VMM tente de ”voler” des cadres de page qui n’ont pas
été référencés dernièrement et qui ne sont donc pas susceptibles de l’être dans un avenir
proche, en utilisant un algorithme de remplacement de page.
Un remplacement de page qui aboutit conserve les pages de mémoire de tous les
processus actifs en cours dans la mémoire RAM alors que les pages de mémoire des
processus inactifs sont sorties de la mémoire. Toutefois, lorsque la mémoire RAM est
surestimée, il devient difficile de déterminer les pages à sortir de la mémoire, car elles
seront vraisemblablement référencées dans un avenir proche par les processus actifs en
cours. En conséquence, les pages susceptibles d’être référencées dans un avenir proche
sont toujours sorties de la mémoire, puis replacées dans la mémoire lorsqu’elles sont
référencées. Lorsque la mémoire RAM est surestimée, la pagination continue en mémoire
et hors de la mémoire, appelée thrashing, se produit. Lorsqu’un système connaît le
thrashing, le système passe la majorité de son temps à sortir et entrer les données en
mémoire au lieu d’exécuter des instructions utiles, et aucun processus actif ne progresse.
VMM utilise un algorithme de contrôle du chargement en mémoire qui détecte quand
système est soumis au thrashing et qui permet de résoudre le problème.
Espace de pagination et mémoire virtuelle
4-3
Généralités sur l’espace de pagination
Un espace de pagination est un type de volume logique associé un espace disque qui
contient des informations qui résident en mémoire virtuelle, mais qui ne sont pas
actuellement utilisées. Ce volume logique dispose d’un type d’attribut de pagination et
s’appelle généralement espace de pagination ou espace d’échange. Lorsque la quantité de
mémoire RAM libre du système est faible, les programmes ou les données qui n’ont pas été
utilisées récemment sont transférés de la mémoire vers l’espace de pagination pour libérer
la mémoire.
Un autre type d’espace de pagination est accessible via une unité qui utilise un serveur NFS
pour le stockage dans l’espace de pagination. Pour qu’un client NFS puisse accéder à cet
espace de pagination, il est nécessaire de créer un fichier pour le serveur NFS et de
l’exporter vers le client. La taille du fichier représente la taille de l’espace de pagination du
client.
La quantité d’espace de pagination nécessaire dépend du type des activités exécutées sur
le système. Si l’espace de pagination devient insuffisant, des processus sont perdus et si
l’espace de pagination est saturé, le système panique. Lorsque l’espace de pagination est
insuffisant, définissez un espace de pagination supplémentaire. Pour plus d’informations,
reportez–vous la section Paging Space Troubleshooting du document AIX 5L Version 5.2
System Management Guide: Système d’exploitation et unités
L’espace de pagination des volumes logiques est défini en créant un nouveau volume
d’espace de pagination ou en augmentant la taille des volumes logiques d’espace de
pagination existants. Pour augmenter la taille d’un espace de pagination NFS, vous devez
augmenter la taille du fichier sur le serveur en exécutant les actions appropriées sur ce
dernier.
L’espace de pagination total du système correspond à la somme des tailles de tous les
volumes logiques d’espace de pagination.
Les sections suivantes contiennent des informations sur les espace de pagination :
• Stratégies d’allocation d’espace de pagination, page 4-4
• Taille par défaut d’espace de pagination, page 4-7
• Fichier d’espace de pagination, commandes et options, page 4-7
Stratégies d’allocation d’espace de pagination
AIX utilise deux modes d’allocation d’espace de pagination. La variable d’environnement
PSALLOC détermine l’algorithme d’allocation d’espace de pagination à utiliser : Late ou
Early. Le mode par défaut est Late. Vous pouvez activer le mode Early en changeant la
variable d’environnement PSALLOC, mais il existe plusieurs facteurs à prendre en compte
avant d’effectuer cette modification. Lorsque vous utilisez l’algorithme d’allocation Early,
dans le pire des cas, vous pouvez bloquer le système en utilisant tout l’espace de
pagination disponible.
4-4
Concepts de gestion de système AIX – Système d’exploitation et unités
Comparaison du mode d’allocation d’espace de pagination Late et du mode
d’allocation d’espace de pagination Early
Le système d’exploitation utilise la variable d’environnement PSALLOC pour déterminer le
mécanisme utilisé pour l’allocation de mémoire et l’espace de pagination. Si la variable
d’environnement PSALLOC n’est pas définie ou est affectée de la valeur null ou d’une
valeur autre que early, le système utilise l’algorithme d’allocation par défaut late.
L’algorithme d’allocation late aide à utiliser efficacement les ressources disque et prend en
charge les applications qui préfèrent un algorithme d’allocation sparse pour gérer les
ressources. Cet algorithme ne réserve pas d’espace de pagination lorsqu’une demande de
mémoire est effectuée. Il améliore la demande et affecte un espace de pagination lorsque
les pages sont utilisées. Certains programmes allouent de grande quantité de mémoire
virtuelle et utilisent uniquement une portion de la mémoire. Les applications techniques, par
exemple, utilisent des vecteurs ou des matrices sparse comme structures de données.
L’algorithme d’allocation Late est également plus efficace pour un noyau de demande de
pages temps réel, tels que celui du système d’exploitation.
Toutefois, cet espace de pagination peut ne jamais être utilisé, notamment sur les systèmes
qui disposent d’une grande quantité de mémoire réelle où la pagination est rare. En
conséquence, l’algorithme Late retarde davantage l’allocation d’espace de pagination
jusqu’à ce qu’il soit nécessaire de lire la page, ce qui permet de ne pas perdre d’espace de
pagination. Toutefois, cela ne se traduit par une surestimation de l’espace de pagination.
Il est possible de surestimer les ressources avec l’algorithme Late pour l’allocation d’espace
de pagination. Dans ce cas, lorsqu’un processus obtient la ressource avant une autre, un
incident se produit. Le système d’exploitation tente d’éviter l’échec du système en arrêtant
les processus affectés par la surestimation de ressources. Le signal SIGDANGER est
envoyé pour indiquer aux processus que la quantité d’espace de pagination libre est faible.
Si l’espace de pagination atteint un niveau encore plus critique, les processus sélectionnés
qui ne reçoivent pas le signal SIGDANGER reçoivent le signal SIGKILL.
Utilisez la variable d’environnement PSALLOC pour utiliser l’algorithme d’allocation Early
qui alloue l’espace de pagination au processus en cours lorsque de la mémoire est
demandée. Si l’espace de pagination est insuffisant lors de la demande, l’allocation Early ne
répond pas à la demande de mémoire.
Si vous affectez à la variable d’environnement PSALLOC la valeur early, chaque
programme démarré dans cet environnement, mais qui n’inclue pas de processus en cours,
est exécuté dans l’environnement d’allocation Early. Dans l’environnement d’allocation
Early, les interfaces, telles que la sous–routine malloc et la sous–routine brk, échouent si
un espace de pagination suffisant ne peut pas être réservé lorsque la demande est
effectuée.
Les processus exécutés dans l’environnement d’allocation Early ne reçoivent pas le signal
SIGKILL si l’espace de pagination est insuffisant.
Vous pouvez affecter à la variable d’environnement PSALLOC la valeur early de
différentes manières en fonction de l’étendue de la modification. (Voir Setting the PSALLOC
Environment Variable for Early Allocation Mode dans le document AIX 5L Version 5.3
System Management Guide: Operating System and Devices.)
Les sous–routines d’interface d’allocation de mémoire suivantes sont affectées par le
passage à l’environnement d’allocation Early :
• malloc
• free
• calloc
• realloc
• brk
• sbrk
Espace de pagination et mémoire virtuelle
4-5
• shmget
• shmctl
Considérations relatives au mode d’allocation Early
L’algorithme d’allocation Early permet de fournir l’espace de pagination nécessaire à une
demande d’allocation de mémoire. Ainsi, l’allocation de l’espace de pagination approprié sur
le disque système est important pour garantir l’efficacité des opérations. Lorsqu’un espace
de pagination tombe en dessous d’un seuil, de nouveaux processus ne peuvent pas être
démarrés et les processus en cours peuvent ne pas recevoir de mémoire supplémentaire.
Tout processus exécuté dans le mode d’allocation par défaut Late devient très vulnérable
au signal SIGKILL. En outre, du fait que le noyau du système d’exploitation nécessite
parfois une allocation de mémoire, il est possible de bloquer le système en utilisant tout
l’espace de pagination disponible.
Avant d’utiliser le mode d’allocation Early sur l’ensemble du système, il est important de
définir un espace de pagination approprié pour le système. L’espace de pagination
nécessaire au mode d’allocation Early est presque plus grand que l’espace de pagination
nécessaire au mode d’allocation par défaut Late. La quantité d’espace de pagination à
définir dépend de la manière dont le système est utilisé et des programmes exécutés.
Un bon point de départ pour déterminer cet élément pour les système consiste à définir
un espace de pagination quatre fois plus grand que la mémoire physique.
Certaines applications peuvent utiliser de grandes quantités d’espace de pagination si elles
sont exécutées en mode d’allocation Early. Le serveur AIXwindows nécessite actuellement
plus de 250 Mo d’espace de pagination lorsque l’application est exécutée en mode
d’allocation Early. L’espace de pagination nécessaire par une application dépend de la
manière dont l’application est écrite et de son exécution.
Toutes les commandes et sous–routines qui utilisent un espace de pagination et de la
mémoire incluent l’espace de pagination alloué en mode d’allocation Early. La commande
lsps utilise l’option –s pour afficher l’allocation d’espace de pagination total, y compris
l’espace de pagination alloué en mode d’allocation Early.
Interface de programmation
L’interface de programmation qui contrôle le mode d’allocation d’espace de pagination
utilise la variable d’environnement PSALLOC. Pour garantir qu’une application s’exécute
toujours dans le mode approprié (avec ou sans allocation d’espace de pagination Early),
procédez comme suit :
1. Utilisez la sous–routine getenv pour identifier l’état en cours de la variable
d’environnement PSALLOC.
2. Si la variable d’environnement PSALLOC ne correspond pas à la valeur nécessaire à
l’application, utilisez la sous–routine setenv pour changer sa valeur. Du fait que seule la
sous–routine execve examine l’état de la variable d’environnement PSALLOC, appelez
la sous–routine execve avec les mêmes paramètres et l’environnement reçu par
l’application. Lorsque l’application réexamine l’état de la variable d’environnement
PSALLOC et trouve la valeur correcte, l’exécution de l’application se poursuit
normalement.
3. Si la sous–routine getenv détecte que l’état en cours de la variable d’environnement
PSALLOC est correcte, aucune modification n’est nécessaire. L’exécution de
l’application se poursuit normalement.
4-6
Concepts de gestion de système AIX – Système d’exploitation et unités
Taille par défaut d’espace de pagination
La taille d’espace de pagination par défaut est déterminée lors de la personnalisation de
l’installation AIX en fonction des standards suivants :
• L’espace de pagination ne peut utiliser moins de 16 Mo, sauf pour hd6 qui ne peut utiliser
moins de 64 Mo dans AIX 4.3 et les versions supérieures.
• L’espace de pagination ne peut utiliser plus de 20 % de l’espace disque total.
• Si la mémoire réelle est inférieure à 256 Mo, l’espace de pagination est égale à deux fois
la mémoire réelle.
• Si la mémoire réelle est supérieure ou égale à 256 Mo, l’espace de pagination est de
512 Mo.
Fichier d’espace de pagination, commandes et options
Le fichier /etc/swapspaces définit les unités d’espace de pagination activées par la
commande swapon –a. Un espace de pagination est ajouté au fichier lorsqu’il est créé par
la commande mkps –a, supprimé du fichier lorsqu’il est supprimé par la commande rmps
et ajouté ou supprimé par la commande chps –a. Si l’espace de pagination est trop grand,
vous pouvez supprimer des partitions logiques de l’espace de pagination sans avoir à
réamorcer le système, en utilisant la commande chps –d.
Les commandes suivantes permettent de gérer l’espace de pagination :
chps
Change les attributs de l’espace de pagination.
lsps
Change les caractéristiques de l’espace de pagination.
mkps
Ajoute un espace de pagination. La commande mkps utilise la
commande mklv avec des options spécifiques lors de la création
d’un volume logique d’espace de pagination. Pour créer des
espaces de pagination NFS, la commande mkps utilise la
commande mkdev avec des options différentes. Pour les espaces
de pagination NFS, la commande mkps doit utiliser le nom d’hôte du
serveur NFS et le chemin du fichier exporté du serveur.
rmps
Supprime un espace de pagination inactif.
swapoff
Désactive un ou plusieurs espaces de pagination sans réamorcer le
système. Les informations dans l’espace de pagination sont
transférées vers d’autres zones d’espace de pagination. L’espace de
pagination désactivé peut être ensuite supprimé avec la commande
rmps.
swapon
Active un espace de pagination. La commande swapon est utilisée
lors de l’initialisation anticipée du système pour activer l’unité
d’espace de pagination initiale. Lors d’une phase d’initialisation
ultérieure, lorsque d’autres commandes deviennent disponibles, la
commande swapon est utilisée pour activer d’autres espaces de
pagination pour que l’activité de pagination ait lieu sur plusieurs
unités.
Espace de pagination et mémoire virtuelle
4-7
Certaines des options suivantes sont nécessaires à tous les espaces de pagination de
volume logique:
• Paging type
• No bad–block relocation
• No mirroring
Les options suivantes permettent d’optimiser les performances de la pagination avec un
volume logique :
• Allocate in the middle of the disk to reduce disk arm travel
• Use multiple paging spaces, each allocated from a separate physical volume.
4-8
Concepts de gestion de système AIX – Système d’exploitation et unités
Chapitre 5 Systèmes de fichiers
Un système de fichiers est une structure hiérarchique (arborescence) de fichiers et de
répertoires. Ce type de structure ressemble à une arborescence inversé avec les racines en
haut de l’arbre et les branches vers le bas. Cette arborescence utilise des répertoires pour
organiser les données et les programmes dans des groupes, ce qui permet de gérer
plusieurs répertoires et fichiers simultanément. Pour plus d’informations sur la structure du
système de fichiers, reportez–vous à Organisation et contenu de l’arborescence de fichiers.
Un système de fichiers réside dans un seul volume logique. Chaque fichier et chaque
répertoire appartiennent à un système de fichiers dans un volume logique. Du fait de sa
structure, certaines tâches sont exécutées plus efficacement sur un système de fichiers que
sur chaque répertoire d’un système de fichiers. Vous pouvez, par exemple, sauvegarder,
déplacer ou sécuriser l’ensemble d’un système de fichiers. Vous pouvez créer une image
dans le temps d’un système de fichiers JFS ou d’un système de fichiers JFS2, appelée
cliché (AIX 5.2 et versions supérieures).
Remarque :
Le nombre maximum de partitions logiques par volume logique est de
32 512. Pour plus d’informations sur les caractéristiques des volumes
logiques des systèmes de fichiers, voir la commande chlv.
La commande mkfs (make file system) ou System Management Interface Tool
(commande smit) crée un système de fichiers dans un volume logique. Pour plus
d’informations sur la gestion des systèmes de fichiers, voir Tâches de gestion des
systèmes de fichiers, page 5-10.
Pour être accessible, un système de fichiers doit être monté sur un point de montage de
répertoire. Lorsque plusieurs systèmes de fichiers sont montés, une structure de
répertoires, qui représente l’image d’un système de fichiers, est créée. Il s’agit d’une
structure hiérarchique avec une seule racine. Cette structure inclut les systèmes de fichiers
de base et les systèmes de fichiers que vous créez. Vous pouvez accéder aux systèmes de
fichiers locaux et distants à l’aide de la commande mount. La commande vous permet
d’accéder au système de fichiers en lecture et en écriture depuis votre système. Le
montage ou le démontage d’un système de fichiers nécessite généralement d’appartenir au
groupe système. Les systèmes de fichiers peuvent être montés automatiquement s’ils sont
définis dans le fichier /etc/filesystems. Vous pouvez démonter un système de fichiers local
ou distant à l’aide de la commande umount si aucun utilisateur ou processus n’utilise le
système de fichiers. Pour plus d’informations sur le montage d’un système de fichiers, voir
Généralités sur le montage, page 5-12.
Plusieurs types de systèmes de fichiers sont pris en charge par AIX 5.2, notamment JFS
(Journaled File System) et JFS2 (Enhanced Journaled File System). Pour plus
d’informations sur les types de fichiers et les caractéristiques de chaque type, voir Types
de systèmes de fichiers, page 5-17.
Systèmes de fichiers
5-1
Organisation et contenu de l’arborescence de fichiers
L’arborescence de fichiers organise les fichiers dans des répertoires qui contiennent des
informations similaires. Cette organisation facilite le montage à distance des répertoires
et des fichiers. Les administrateurs système peuvent utiliser ces répertoires comme
composants pour créer une arborescence de fichiers unique pour chaque client qui monte
des répertoires individuels depuis un ou plusieurs serveurs. Monter les fichiers et les
répertoires à distance au lieu de stocker localement les informations offre les avantages
suivants :
• Economise d’espace disque
• Facilite l’administration centralisée du système.
• Fournit un environnement plus sécurisé.
L’arborescence de fichiers à les caractéristiques suivantes :
• Les fichiers qui peuvent être partagés par les machines ayant une architecture matérielle
identique se trouvent dans le système de fichiers /usr.
• Les fichiers variables par client, tels que les fichiers spool et les fichiers de messagerie,
se trouvent dans le système de fichiers /var.
• Les fichiers texte partageables indépendants de l’architecture, tels que des pages
de manuel, se trouvent dans le répertoire /usr/share.
• Le système de fichiers / (racine) contient les fichiers et les répertoires importants du
système d’exploitation. Par exemple, il contient un répertoire d’unités, les programmes
utilisés pour démarrer le système et les points de montage sur lesquels les systèmes
de fichiers peuvent être montés sur le système de fichiers racine.
• Le système de fichiers /home est le point de montage des répertoires locaux de
l’utilisateur.
• Pour les serveurs, le répertoire /export contient des fichiers d’espace de pagination,
des systèmes de fichiers (non partagés) par client, un cliché, un répertoire local, des
répertoires /usr/share pour les clients sans disque et des répertoires exportés /usr.
5-2
Concepts de gestion de système AIX – Système d’exploitation et unités
Description du système de fichiers racine
Le système de fichiers racine est le premier système de fichiers de l’arborescence de
fichiers hiérarchique Il contient les fichiers et les répertoires importants du système
d’exploitation, notamment le répertoire des unités et les programmes de démarrage du
système. Le système de fichiers racine contient aussi des points de montage de systèmes
de fichiers pour les connecter à la hiérarchie des systèmes de fichiers racine.
L’illustration ci–dessous montre les nombreux sous–répertoire du système de fichiers
racine.
Figure 7. Système de fichiers racine Cette illustration montre le système de fichiers
racine et ses sous–répertoires. Les points de sous–répertoires /bin du répertoire /usr/bin.
Les points de sous–répertoires /lib du répertoire /usr/lib. Les points de sous–répertoires
/u du répertoire /home.
La liste suivante fournit des informations sur le contenu des sous–répertoires du système
de fichiers / (racine).
Systèmes de fichiers
5-3
/etc
Contient les fichiers de configuration qui varient en fonction de la
machine. Exemples :
• /etc/hosts
• /etc/passwd
Le répertoire /etc contient les fichiers généralement utilisés pour
l’administration de système. La plupart des commande qui se
trouvaient auparavant dans le répertoire /etc figurent désormais
dans le répertoire /usr/sbin. Toutefois, pour des raisons de
compatibilité, le répertoire /usr/sbin contient des liens symboliques
vers des emplacements de fichiers exécutables. Exemples :
• /etc/chown est un lien symbolique vers /usr/bin/chown.
• /etc/exportvg est un lien symbolique vers /usr/sbin/exportvg.
5-4
/bin
Lien symbolique vers le répertoire /usr/bin. Dans les systèmes de
fichiers UNIX antérieurs, la répertoire /bin contenait des commandes
utilisateur qui résident maintenant dans le répertoire /usr/bin.
/sbin
Contient les fichiers nécessaires au démarrage de la machine et au
montage du système de fichiers /usr. La plupart des commandes
utilisées pendant l’amorçage proviennent du système de fichiers du
disque RAM de l’image d’amorçage et en conséquence un nombre
limité de commandes se trouve ans le répertoire /sbin.
/dev
Contient les nœuds d’unités des fichiers spéciaux des unités locales.
Le répertoire /dev contient des fichiers spéciaux pour les unités de
bande, les imprimantes, les partitions de disque et les terminaux.
/tmp
Sert de point de montage d’un système de fichiers qui contient des
fichiers temporaires générés par le système. Le système de fichiers
/tmp est un répertoire vide.
/var
Sert de point de montage de fichiers qui varient fonction de la
machine. Le système de fichiers /var est configuré comme système
de fichiers étant donné que la taille des fichiers qu’il contient tend à
augmenter. Voir Description du système de fichiers /var, page 5-7
pour plus d’informations.
/u
Lien symbolique vers le répertoire /home.
/usr
Contient des fichiers qui ne changent pas (exécutables et
documentation ASCII, par exemple) et qui peuvent être partagés par
des machines.
Les machines autonomes montent la racine d’un système de fichiers
local séparé sur le répertoire /usr. Les machines sans disque et les
machines dont les ressources disque sont limitées montent un
répertoire depuis un serveur distant sur le système de fichiers /usr.
Pour plus d’informations sur l’arborescence de fichiers montée sur le
répertoire /usr, reportez–vous à la section Description du système
de fichiers /usr, page 5-5.
/home
Sert de point de montage pour un système de fichiers qui contient
les répertoires locaux de l’utilisateur. Le système de fichiers /home
contient des fichiers par utilisateur et des répertoires.
Sur une machine autonome, le répertoire /home se trouve dans un
système de fichiers différent dont la racine est montée sur le
système de fichiers racine du répertoire /home. Dans un réseau, un
serveur peut contenir des fichiers utilisateur accessibles depuis
plusieurs machines. Dans ce cas, la copie serveur du répertoire
/home est montée à distance sur un système de fichiers local
/home.
Concepts de gestion de système AIX – Système d’exploitation et unités
/export
Contient les répertoires et les fichiers, destinés à des clients
distants, sur un serveur.
Pour plus d’informations sur l’arborescence de fichiers qui réside
dans le répertoire /usr, reportez–vous à la section Description du
système du répertoire /export , page 5-8.
/lib
Lien symbolique vers le répertoire /usr/lib. Voir Description du
système de fichiers /usr, page 5-5 pour plus d’informations.
/tftpboot
Contient les images et les informations d’amorçage des clients
sans disque.
Description du système de fichiers /usr
Le système de fichiers /usr contient des fichiers exécutables qui peuvent être partagés
entre les machines. Les principaux sous–répertoires du répertoire /usr figurent dans
l’illustration ci–dessous.
Figure 8. Système de fichiers /usr Cette illustration montre les principaux
sous–répertoires du répertoire /usr qui contient : les sous–répertoires /bin, /ccs, /lib, /lpp,
/adm et /var/adm et les sous répertoires /man et /usr/share/man.
Sur une machine autonome, le système de fichiers /usr est un système de fichiers distinct
(dans le volume logique /dev/hd2). Sur une machine sans disque ou une machine dont les
ressources disque sont limitées, un répertoire d’un serveur distant est monté avec
l’autorisation Lecture seule sur le système de fichiers /usr. Le système de fichiers /usr
contient des commandes, des bibliothèques et des données accessibles en lecture seule.
Sauf pour le contenu du répertoire /usr/share, les fichiers et les répertoires du système de
fichiers /usr peuvent être partagés par toutes les machines ayant la même architecture
matérielle.
Systèmes de fichiers
5-5
Le système de fichiers /usr contient les répertoires suivants :
/usr/bin
Contient des commandes ordinaires et des scripts shell. Par
exemple, le répertoire /usr/bin contient les commandes ls, cat
et mkdir.
/usr/ccs
Contient des fichiers binaires de développement de module non
modulaires.
/usr/include
Contient include ou des fichiers d’en–tête.
/usr/lbin
Contient des fichiers exécutables qui sont nécessaires à des
commandes.
/usr/lbin
Contient des bibliothèques dépendantes de l’architecture dont les
noms ont le format lib*.a. Le répertoire /lib du répertoire / (racine)
est un lien symbolique vers le répertoire /usr/lib. En conséquence,
tous les fichiers qui se trouvaient dans le répertoire /lib figurent
désormais dans le répertoire /usr/lib. Ces fichiers incluent des
fichiers ne correspondant pas à des bibliothèques, à des fins de
compatibilité.
/usr/lpp
Contient des produits installés optionnels.
/usr/sbin
Contient des utilitaires utilisés pour l’administration de système, tels
que les commandes SMIT (System Management Interface Tool).
La plupart des commandes qui se trouvaient auparavant dans le
répertoire /etc figurent désormais dans le répertoire /usr/sbin.
/usr/share
Contient des fichiers qui peuvent être partagés par des machines
ayant une architecture différente. Voir Description du répertoire
/usr/share, page 5-7, pour plus d’informations.
Lien symbolique vers le répertoire /var.
/usr/adm
Lien symbolique vers le répertoire /usr/adm.
/usr/mail
Lien symbolique vers le répertoire /var/spool/main.
/usr/news
Lien symbolique vers le répertoire /var/news.
/usr/preserve
Lien symbolique vers le répertoire /var/preserve.
/usr/spool
Lien symbolique vers le répertoire /var/spool.
/usr/tmp
Lien symbolique vers le répertoire /var/tmp, car le répertoire /usr est
potentiellement partagé par un grand nombre de nœuds et qu’il est
accessible en lecture seule.
Liens symbolique vers les répertoires /usr/share et /usr/lib
5-6
/usr/dict
Lien symbolique vers le répertoire /usr/share/dict.
/usr/man
Lien symbolique vers le répertoire /usr/share/man.
/usr/lpd
Lien symbolique vers le répertoire /usr/lib/lpd.
Concepts de gestion de système AIX – Système d’exploitation et unités
Description du système de fichiers /usr/share
Le répertoire /usr/share contient des fichiers texte partageables indépendants de
l’architecture. Le contenu de ce répertoire peut être partagé par toutes les machines, quelle
que soit l’architecture matérielle.
Dans un environnement architectural mixte, le client sans disque type monte un répertoire
serveur sur son propre répertoire /usr et monte un répertoire différent sur le répertoire
/usr/share. Les fichiers sous le répertoire /usr/share se trouvent dans un ou plusieurs
modules installables séparés. Ainsi, les autres parties du répertoire /usr dont dépend un
nœud localement peuvent être installées sur le nœud tout en utilisant un serveur pour
fournir le répertoire /usr/share.
Certains fichiers du répertoire /usr/share fournissent les répertoires et les fichiers indiqués
dans l’illustration ci–dessous.
Figure 9. Répertoire /usr/share L’illustration montre divers répertoires du répertoire
/usr/share, notamment /lib, /lpp, /dict et /man.
Le répertoire /usr/share contient :
/usr/share/man
Contient les pages du manuel si elles ont été chargées.
/usr/share/dict
Contient le dictionnaire orthographique et ses index.
/usr/share/lib
Contient des fichiers de données dépendants de l’architecture,
notamment terminfo, learn, tmac, me et macros
/usr/share/lpp
Contient des données et des informations sur les produits
installables optionnels du système.
Description du système de fichiers /var
Attention: La taille du système de fichiers /var tend à augmenter, car il contient des
sous–répertoires et des fichiers de données utilisés par les applications courantes telles
que comptabilité, messagerie et spouleur d’impression. Si des applications sur système
utilisent très souvent le système de fichiers /var, exécutez régulièrement la commande
skulker ou définissez une taille de système de fichiers /var supérieure à la valeur par
défaut 4 Mo.
Les fichiers spécifiques /var qui garantissent un contrôle régulier sont /var/adm/wtmp
et /var/adm/ras/errlog.
Autres fichiers /var à contrôler :
/var/adm/ras/trcfile
Si la fonction de trace est active
/var/tmp/snmpd.log
Si la commande snmpd est exécutée sur le système
Le graphique du répertoire /var montre des répertoires du système de fichiers /var.
Systèmes de fichiers
5-7
Figure 10. Répertoire /var L’illustration montre les principaux répertoires du répertoire /var,
notamment /adm, /news, /preserve, /spool et /tmp.
/var/adm
Contient les fichiers de journalisation et de comptabilité.
/var/news
Contient des informations récentes sur le système.
/var/preserve
Contient les données protégées des sessions d’édition
interrompues. Similaires au répertoire /usr/preserve des versions
précédentes.
/var/spool
Contient les fichiers traités par des programmes tels que de
messagerie électronique. Similaire au répertoire /usr/spool des
versions précédentes.
/var/tmp
Contient des fichiers temporaires. Similaire au répertoire /usr/tmp
des versions précédentes. Le répertoire /usr/tmp est désormais
un lien symbolique vers /var/tmp.
Description du répertoire /export
Le répertoire /export contient des fichiers de serveur exportés vers les clients, tels que des
machines sans disque, des machines sans données ou des machines limitées en ressource
disque. Un serveur peut exporter plusieurs types d’espaces disque, notamment des
modules de programmes exécutables, un espace de pagination pour les clients sans disque
et des systèmes de fichiers racines pour les clients sans disques ou dont les ressources en
disques sont limitées. L’emplacement standard d’un tel espace disque dans l’arborescence
de fichiers est le répertoire /export. Certains sous–répertoires du répertoire /export figurent
dans la liste ci–dessous :
5-8
/exec
Contient des répertoires sur lesquels les clients sans disque montent leurs
systèmes de fichiers /usr.
/swap
Contient les fichiers de pagination à distance des clients sans disque.
/share
Contient des répertoires sur lesquels les clients sans disque montent leur
répertoire /usr.
/root
Contient des répertoires sur lesquels les clients sans disque montent leur
système de fichiers / (racine).
/dump
Contient les répertoires des fichiers clichés distants des clients sans
disque.
Concepts de gestion de système AIX – Système d’exploitation et unités
/home
Contient des répertoires sur lesquels les clients sans disque montent leur
système de fichiers / home.
Le répertoire /export est l’emplacement par défaut des ressources client pour les
commandes sans disque. Le répertoire /export est le seul emplacement des ressources
client sur le serveur. Du fait que les clients montent ces ressources dans leur propre
arborescence de fichiers, ces ressources apparaissent pour les client dans des
emplacement normaux dans une arborescence de fichiers. Les principaux sous–répertoires
du répertoire /export et leurs points de montage correspondant dans une arborescence de
fichiers incluent :
/export/root
Ce répertoire est monté sur le système de fichiers racine (/) du client. Les
répertoires racines des clients se trouvent par défaut dans le répertoire
/export/root et portent le nom d’hôte du client.
/export/exec
Appelé également répertoire SPOT (Shared Product Object Tree). Ce
répertoire est monté sur le système de fichiers client /usr. Les répertoires
SPOT sont des versions du système de fichiers /usr stocké dans le
répertoire /export/exec et leurs noms reflètent leur niveau de version.
Le nom par défaut est RISCAIX.
/export/share Ce répertoire est monté sur le répertoire client /usr/share. Ce répertoire
contient des données qui peuvent être partagées par un grand nombre
d’architectures. L’emplacement par défaut est
/export/share/AIX/usr/share.
/export/home Ce répertoire est monté sur le système de fichiers racine /home (/) du
client. Il contient des répertoires utilisateur groupés par nom d’hôte de
client. L’emplacement par défaut des répertoires racines des clients est
/export/home.
/export/swap
Appelé également répertoire de pagination. Dans un système autonome ou
sans données, la pagination fournit un disque local pour les clients sans
disque. Ce service est fourni par un fichier sur un serveur. Le nom de ce
fichier provient du nom d’hôte du client. Le fichier se trouve par défaut dans
le répertoire /export/swap.
/export/dump Les systèmes autonomes utilisent un disque local comme unité de cliché.
Les clients sans disque utilisent un fichier sur un serveur. Ce fichier réside
dans un répertoire dont le nom provient du nom d’hôte du client. Le fichier
se trouve par défaut dans le répertoire /export/dump.
microcode
Ce répertoire contient le microcode des unités physiques. L’emplacement
par défaut est /export/exec/RISCAIX/usr/lib/microcode.
Systèmes de fichiers
5-9
Tâches de gestion des systèmes de fichiers
Un système de fichiers est une structure de répertoires complète qui est constituée d’un
répertoire racine et de répertoires et de fichiers stockés sous le répertoire racine. Les
systèmes de fichiers se trouvent dans un seul volume logique. Certaines des tâches de
gestion les plus importantes concernent les systèmes de fichiers, notamment :
• Allocation d’espace aux systèmes de fichiers dans les volume logiques
• Création de systèmes de fichiers
• Rendre l’espace de système de fichiers disponibles aux utilisateurs du système
• Contrôle de l’utilisation de l’espace de système de fichiers
• Sauvegarde des systèmes de fichiers pour la protection contre la perte de données en
cas d’incident
• Création d’un cliché pour capturer une image cohérente de bloc d’un système de fichiers
à un moment donné
• Maintien des systèmes de fichiers dans un état cohérent.
La liste suivante contient les commandes de gestion de systèmes de fichiers :
5-10
backup
Exécute une sauvegarde complète ou incrémentielle d’un système
de fichiers.
chfs –a splitcopy
Crée une sauvegarde en ligne d’un système de fichiers JFS monté.
dd
Copie les données directement d’une unité vers une autre pour créer
des sauvegardes de systèmes de fichiers.
df
Indique la quantité d’espace utilisé et l’espace libre dans un système
de fichiers
fsck
Vérifie les systèmes de fichiers et répare les incohérences.
mkfs
Crée un système de fichiers d’une taille donnée dans un volume
logique défini.
mount
Connecte un système de fichiers à une structure de nom de système
pour pouvoir accéder aux fichiers et aux répertoires du système de
fichiers.
restore
Restaure des fichiers depuis une sauvegarde.
snapshot
Crée un cliché d’un système de fichiers JFS2.
umount
Supprime un système de fichiers d’une structure de nom de système
pour rendre les fichiers et les répertoires du système de fichiers
inaccessibles.
Concepts de gestion de système AIX – Système d’exploitation et unités
Commandes de système de fichier
Il existe des commandes associées à tous les types de systèmes de fichiers. Le fichier
/etc/filesystems contrôle la liste des systèmes de fichiers que peuvent manipuler les
commandes suivantes :
chfs
Change les caractéristiques d’un système de fichiers.
crfs
Ajoute un système de fichiers.
lsfs
Affiche les caractéristiques d’un système de fichiers.
rmfs
Supprime un système de fichiers.
mount
Rend accessible un système de fichiers
Quatre commandes sont disponibles pour les types de systèmes de fichiers virtuels.
Le fichier /etc/vfs contient les informations sur les types de systèmes de fichiers que
les commandes suivantes manipulent :
chvfs
Change les caractéristiques d’un type de système de fichiers.
crvfs
Ajoute un nouveau type de système de fichiers.
lsvfs
Indique les caractéristiques d’un type de système de fichiers.
rmvfs
Supprime un type de système de fichiers.
Systèmes de fichiers
5-11
Montage : généralités
Le montage met les systèmes de fichiers, les fichiers, les répertoires, les unités et les
fichiers spéciaux à disposition de l’utilisateur à un emplacement spécifique. Il représente
l’unique moyen de donner l’accès à un système de fichiers. Par le biais de la commande
mount, le système d’exploitation reçoit l’instruction d’associer un système de fichiers au
répertoire spécifié.
Pour monter un fichier ou un répertoire, vous devez posséder les droits d’accès à ce fichier
ou à ce répertoire, et avoir l’autorisation d’écriture au niveau du point de montage. Les
membres du groupe système également peuvent procéder à des montages d’unités (dans
lesquels les systèmes de fichiers ou les unités sont montés sur les répertoires), ainsi qu’aux
montages décrits dans le fichier /etc/filesystems les montages décrits plus loin. L’utilisateur
racine peut aussi monter un système de fichiers arbitrairement, en nommant l’unité et le
répertoire sur la ligne de commande. Dans /etc/filesystems, il est possible de définir les
montages qui seront automatiquement effectués à l’initialisation du système. La commande
mount sert au montage une fois le système démarré.
Description des points de montage
Un point de montage est un répertoire ou un fichier au niveau duquel un nouveau système
de fichiers, un répertoire ou un fichier est accessible. Le point de montage d’un fichier est
obligatoirement un fichier, et celui d’un répertoire ou d’un système de fichiers,
obligatoirement un répertoire.
Un système de fichiers, un répertoire ou un fichier est généralement monté au niveau d’un
point de montage vide, mais ceci n’est pas obligatoire. Si le répertoire ou le fichier servant de
point de montage contient des données, celles-ci ne sont plus accessibles. En effet, elles sont
recouvertes par les données du répertoire ou du fichier monté qui se trouvait préalablement
dans ce répertoire. Elles redeviennent accessibles après le démontage du répertoire ou du
fichier monté.
Quand un système de fichiers est monté sur un répertoire, les droits associés au répertoire
racine du système de fichier monté ont priorité sur ceux du point de montage. Une
exception, toutefois, concernant le répertoire parent .. (point point) du répertoire de
montage. Ses informations doivent être disponibles pour permettre au système
d’exploitation d’accéder au nouveau système de fichiers.
Par exemple, si le répertoire courant est /home/frank, la commande cd .. passe au
répertoire /home. Si /home/frank est le répertoire racine d’un système de fichiers monté,
le système d’exploitation doit avoir accès aux informations du répertoire parent dans
/home/frank pour faire aboutir la commande cd ...
Pour toute commande dont l’exécution requiert des informations du répertoire parent,
l’utilisateur doit être autorisé à rechercher ces informations dans le répertoire de montage.
En cas d’échec du répertoire de montage à accorder cette autorisation, le résultat est
imprévisible, d’autant que ce type d’autorisation n’est pas visible. L’échec de la commande
pwd est courant. En l’absence d’autorisation, pwd renvoie le message :
pwd: Permission denied
Affecter la valeur 111 aux autorisations du répertoire de montage permet d’éviter
ce problème.
5-12
Concepts de gestion de système AIX – Système d’exploitation et unités
Montage des systèmes de fichiers, des répertoires et des fichiers
Il existe deux types de montages : local et à distance. Le montage à distance s’effectue
sur un système distant par transfert des données sur une ligne de télécommunication.
Les systèmes de fichiers distants, tels que NFS, doivent être exportés avant d’être montés.
Le montage local est effectué sur le système local.
Chaque système de fichiers est associé à une unité distincte (volume logique). Un système
de fichiers, pour être exploité, doit être connecté au préalable à la structure de répertoire
existante (soit le système de fichiers racine soit un autre système de fichiers déjà
connecté). C’est la commande mount qui se charge de cette connexion.
Plusieurs chemins permettent d’accéder au même système de fichiers, répertoire ou fichier.
Par exemple, pour l’accès multi-utilisateur à une base de données, il est préférable d’avoir
plusieurs points de montage. Chaque montage doit avoir ses propres noms et mot de
passe, pour des raisons de suivi et de séparation des travaux. Ainsi, le même système de
fichiers peut être monté sur différents points de montage. Par exemple, à partir de
/home/server/database, vous pouvez monter au niveau du point de montage
/home/user1, /home/user2 et /home/user3 :
/home/server/database
/home/server/database
/home/server/database
/home/user1
/home/user2
/home/user3
Un système de fichiers, un répertoire ou un fichier peut être mis à disposition de l’utilisateur
par le biais de liens symboliques. Ces liens symboliques sont créés par le biais de la
commande ln –s. Les liens entre plusieurs utilisateurs et un fichier central permettent
de refléter les modifications du fichier à chaque accès utilisateur.
Contrôle des montages automatiques
Les montages peuvent être configurés pour s’effectuer automatiquement à l’initialisation
du système. Il existe deux types de montages automatiques : les montages requis pour
amorcer et exploiter le système, et les montages utilisateur. En ce qui concerne les
premiers, les systèmes de fichiers sont automatiquement montés par le processus
d’amorçage. Leurs strophes, dans le fichier /etc/filesystems, sont assorties de
mount = automatic. Le second type de montage est contrôlé par l’utilisateur. Les systèmes
de fichiers sont montés automatiquement par le script /etc/rc à l’exécution de la commande
mount all. Les strophes de ces systèmes sont assorties de mount = true dans
/etc/filesystems.
C’est le fichier /etc/filesystems qui contrôle les montages automatiques, effectués un à un,
selon la hiérarchie. L’ordre spécifié dans ce fichier peut être modifié et restructuré.
/etc/filesystems est structuré en strophes, une par montage. La strophe décrit les attributs
du système de fichiers correspondant et le procédé de montage. Les systèmes de fichiers
sont montés dans l’ordre où ils figurent dans /etc/filesystems. Voici un extrait de
/etc/filesystems avec un exemple de strophes :
Systèmes de fichiers
5-13
/:
dev=/dev/hd4
vol=”root”
mount=automatic
check=false
free=true
vfs=jfs
log=/dev/hd8
type–bootfs
/home:
dev=/dev/hd1
vfs=jfs
log=/dev/hd8
mount=true
check=true
vol=”/home”
free=false
/usr:
/dev=/dev/hd2
vfs=jfs
log=/dev/hd8
mount=automatic
check=false
type=bootfs
vol=”/usr”
free=false
Pour vérifier l’ordre de montage, vous pouvez afficher le fichier /etc/filesystems. Quand un
montage n’aboutit pas, le processus de montage continue. Par exemple, si le montage du
système de fichiers /home échoue, le système de fichier suivant, /usr, est monté. Un
montage peut échouer en raison d’une erreur de typographie, d’une dépendance ou d’un
incident système.
Description de la sécurité du montage des stations
de travail sans disque
Les stations de travail sans disque doivent pouvoir créer des fichiers spéciaux d’unité et y
accéder sur des machines distantes pour pouvoir monter leurs répertoires /dev depuis un
serveur. Du fait que les serveurs ne peuvent pas distinguer les fichiers spéciaux d’unité d’un
client de ceux d’un serveur, l’utilisateur sur le serveur peut être capable d’accéder aux
unités physiques du serveur en utilisant les fichiers spéciaux de l’unité du client.
Par exemple, la propriété d’un terminal tty est automatiquement affectée à l’utilisateur qui
utilise le terminal tty. Si les ID utilisateur ne sont pas identiques sur le client et le serveur, un
utilisateur non privilégié sur le serveur peut accéder à un terminal tty utilisé par un autre
utilisateur sur le serveur.
Un utilisateur privilégié sur un client peut créer des fichiers spéciaux d’unités pour qu’ils
correspondent aux unités physiques du serveur et ne pas avoir à disposer de privilège pour
y accéder. L’utilisateur peut ensuite utiliser un compte privilégié sur le serveur pour accéder
aux unités protégées normalement en utilisant les nouveaux fichiers spéciaux d’unités.
Un problème de sécurité similaire est associé aux programmes setuid et setgid sur le
client et le serveur. Les clients sans disque doivent pouvoir créer et exécuter les
programmes setuid et setgid sur le serveur dans des conditions d’exploitation normales.
Là encore, le serveur ne peut pas distinguer les programmes du serveur de ceux du client.
En outre, les ID d’utilisateur et les ID de groupe peuvent ne pas être identiques sur le
serveur et le client. En conséquence, les utilisateurs du serveur peuvent être capables
d’exécuter les programmes en accédant à des fonctions auxquelles ils ne devraient pas
accéder.
5-14
Concepts de gestion de système AIX – Système d’exploitation et unités
Ce problème existe par le fait que les programmes setuid et setgid et les fichiers spéciaux
d’unités ne devraient pouvoir être utilisés que sur la machine sur laquelle ils ont été créés.
La solution consiste à utiliser des options de sécurité avec la commande mount, qui
restreignent l’utilisation de ces objets. Ces options peuvent être également utilisées dans
les strophes du fichier /etc/filesystems.
L’option nosuid de la commande mount empêche d’exécuter les programmes setuid et
setgid accessibles via le système de fichiers monté résultant. Cette option est utilisée avec
n’importe quel système de fichiers monté sur un hôte pour être utilisé uniquement par un
autre hôte (par exemple, exporté pour des clients sans disque).
L’option nodev de la commande mount empêche d’ouvrir les unités en utilisant des
fichiers spéciaux d’unités accessibles via le système de fichiers monté résultant. Cette
option est utilisée avec n’importe quel système de fichiers monté pour être utilisé
uniquement par un autre hôte (par exemple, exporté pour des clients sans disque).
Montages sans disque
Bien que le système de fichiers d’une station de travail soit monté depuis le répertoire /
exports d’un serveur, pour la machine sans disque, le système de fichiers correspond au
système de fichiers d’une machine autonome.
Les informations suivantes montrent la relation entre le répertoire exports du serveur et les
points de montage de la station de travail sans disque :
Exports serveur
Imports sans disque
/export/root/ Nom_hôte
/ (root)
/export/exec/ Nom_SPOT
/usr
/export/home/ Nom_hôte
/home
/export/share
/usr/share
/export/dump
Utilisé par le client sans disque comme
espace de cliché
/export/swap
Utilisé par le client sans disque comme
espace de cliché distant
Pour plus d’informations sur le répertoire /export, reportez–vous à la section Description
du répertoire /export, page 5-8.
Sécurisation des montages sans disque
En règle générale, les utilisateurs d’un serveur ne peuvent pas accéder au répertoire
/export.
Exportation du répertoire /export/root
Le répertoire /export/root doit être exporté avec les autorisations Lecture/Ecriture
et l’utilisateur root sur le serveur doit y avoir accès. Toutefois, vous pouvez monter
ce répertoire avec les options suivantes de la commande mount :
nosuid
Empêche un utilisateur du serveur d’exécuter les programmes
setuid du client.
nodev
Empêche un utilisateur d’accéder aux unités du serveur en utilisant
un fichier spécial d’unité du client.
Une alternative au montage du répertoire /export/root avec ces options consiste à
empêcher les utilisateurs du serveur d’accéder au répertoire /export/root.
Systèmes de fichiers
5-15
Exportation du répertoire /export/exec
Le répertoire /export/exec est exporté avec l’autorisation Lecture seule et doit fournir un
accès root. Toutefois, vous pouvez monter ce répertoire avec les options suivantes de la
commande mount :
nosuid
Empêche un utilisateur du serveur d’exécuter les programmes
setuid du client. Si vous exportez le répertoire /usr du serveur,
vous ne pouvez pas utiliser l’option nousid.
nodev
Empêche un utilisateur d’accéder aux unités du serveur en utilisant
un fichier spécial d’unité du client.
Exportation du répertoire /export/share
Le répertoire /export/share est exporté avec l’autorisation Lecture seule et doit fournir un
accès root. Du fait que ce répertoire ne contient généralement que des données (pas
d’exécutables, ni des unités), il n’est pas nécessaire d’utiliser les options de sécurité de la
commande mount.
Exportation du répertoire /export/home
Vous pouvez monter le répertoire utilisateur /home de différentes manières :
• Vous pouvez monter le répertoire /export/home/ Nom_hôte_client sur le répertoire
/home du client. Dans ce cas, le client dispose des autorisations Lecture/Ecriture et
l’utilisateur dispose d’un accès. Pour protéger le système, monter le répertoire
/export/home avec les options suivantes de la commande mount :
nosuid
Empêche un utilisateur du serveur d’exécuter les programmes
setuid du client.
nodev
Empêche un utilisateur d’accéder aux unités du serveur en utilisant
un fichier spécial d’unité du client.
• Vous pouvez monter le répertoire /home sur le serveur sur le répertoire /home du client.
Dans ce cas, le répertoire /home est exporté avec les autorisations Lecture/Ecriture et
sans accès root. Pour protéger le système, montez le répertoire /home sur le serveur
et le client avec les options nosuid et nodev de la commande mount.
• Vous pouvez également monter le client sur chaque répertoire /home/ Nom_Utilisateur
du serveur sur le répertoire /home/ Nom_utilisateur du client pour que les utilisateurs
puissent se connecter à des machines différentes et toujours accéder à leurs répertoires
home. Dans ce cas, les répertoires /home/ Nom_utilisateur du serveur et des clients
sont montés avec les options nousid et nodev de la commande mount.
Exportation du répertoire /export/dump
Exportez le répertoire /export/dump/ Nom_hôte_client avec les autorisations
Lecture/Ecriture et l’accès root. Les utilisateurs du serveur n’ont pas accès aux fichiers
/export/dump/ Nom_hôte_client.
Exportation du répertoire /export/swap
Exportez le répertoire /export/swap/ Nom_hôte_client avec les autorisations
Lecture/Ecriture et l’accès root. Aucune mesure de sécurité n’est nécessaire. Les
utilisateurs du serveur n’ont pas accès aux fichiers /export/swap/ Nom_hôte_client.
5-16
Concepts de gestion de système AIX – Système d’exploitation et unités
Types de systèmes de fichiers
AIX prend en charge plusieurs types de systèmes de fichiers, à savoir :
• JFS (Journaled File System) ou JFS2 (Enhanced Journaled File System), page 5-17
• NFS (Network File System), page 5-17
• CDRFS (CD–ROM File System), page 5-17
• UDFS (DVD–ROM File System), page 5-17
JFS (Journaled File System) ou JFS2 (Enhanced Journaled File System)
Il prend en charge l’ensemble de la sémantique de système de fichiers. Ces systèmes de
fichiers utilisent des techniques de journalisation de base de données pour maintenir la
cohérence structurelle. Cela permet d’éviter d’endommager le système de fichiers lorsque
le système s’arrête de manière anormale.
Chaque système de fichiers JFS ou JFS2 réside dans un volume logique distinct.
Le système d’exploitation monte le système de fichiers lors de l’initialisation. Cette
configuration à plusieurs systèmes de fichiers s’avère utile pour les fonctions de gestion
de système telles que les sauvegardes, les restaurations et les réparations, car elle isole
une partie de l’arborescence de fichiers pour vous permettre de travailler dessus.
JFS2 se distingue de JFS dans la mesure ou ce système de fichiers prend en charge des
fichiers et des systèmes de fichiers volumineux. Ces types de systèmes de fichiers sont
décrits plus en détail dans la section Description de JFS et de JFS2, page 5-18.
NFS (Network File System)
Il s’agit d’un système de fichiers distribué qui permet aux utilisateurs d’accéder aux fichiers
et aux répertoires situés sur des ordinateurs distants et qui les utilise comme s’il s’agissait
de fichiers et de répertoires locaux. Les utilisateurs, par exemple, peuvent utiliser les
commandes du système d’exploitation pour créer, supprimer, lire, écrire des fichiers et
définir des attributs sur les fichiers et les répertoires distants. NFS est décrit plus en détail
dans la section NFS (Network File System) du Guide de gestion du système AIX 5L
Version 5.3 : Communications et réseaux.
CDRFS (CD–ROM File System)
Ce système de fichiers permet d’accéder au contenu d’un CD–ROM via des interfaces
de système de fichiers normales. CDRFS est décrit plus en détail dans la section
Description de CDRFS, page 5-31.
UDFS (DVD–ROM File System)
Ce système de fichiers permet d’accéder au contenu d’un DVD via des interfaces
de système de fichiers normales. UDFS est décrit plus en détail dans la section
Description de UDFS, page 5-32.
Systèmes de fichiers
5-17
Description de JFS et de JFS2
Les systèmes de fichiers JFS (Journaled File System) et JFS2 (Enhanced Journaled File
System) sont intégrés au système d’exploitation de base. Les deux types de systèmes de
fichiers lient leurs données de fichiers et de répertoires à la structure utilisée par LVM
(Logical Volume Manager) AIX pour le stockage et l’extraction des données. JFS2 diffère de
JFS dans la mesure où ce système de fichiers prend en charge un noyau de 64 bits et des
fichiers plus volumineux.
Ces types de fichiers sont décrits dans les sections suivantes. Sauf indication contraire, les
sections suivantes s’appliquent aux systèmes de fichiers JFS et JFS2.
JFS2
JFS2 (Enhanced Journaled File System) est un système de fichiers introduit dans AIX 5L for
POWER Version 5.1 qui permet de stocker des fichiers beaucoup plus volumineux que le
système de fichiers JFS (Journaled File System). Les clients peuvent décider de mettre en
œuvre JFS, le système de fichiers recommandé pour les environnements 32 bits, ou JFS2
qui offre des fonctionnalités 64 bits.
Remarque :
Contrairement au système de fichiers JFS, le système de fichiers JFS2 ne
permet pas d’utiliser l’API link() sur des fichiers de type répertoire. Cette
limitation peut empêcher certaines applications qui fonctionnent
correctement avec un système de fichiers JFS, de fonctionner correctement
avec le système de fichiers JFS2.
Le tableau ci–dessous répertorie les fonctions JFS et JFS2 :
Fonctions
JFS2
JFS
Fragments/taille de bloc
Tailles de blocs 512–4096
Fragments 512–4096
Taille maximale de système
de fichiers
16 téraoctets
1 téraoctet
Taille maximale de fichier
16 téraoctets
64 Go
Nombre d’i–nodes
Dynamique, limitée
par l’espace disque
Fixe, défini lors de la
création d’un système
de fichiers
Organisation des répertoires Arborescence B
Linéaire
Compression
Non
Oui
Quotas
Oui
Oui
Journal d’erreurs
Oui
Oui
Remarques :
1. La taille de fichier maximale et la taille de système de fichiers maximale sont limitées
à 1 téraoctet avec le noyau 32 bits.
2. JFS2 prend en charge le schéma de journalisation des erreurs standard AIX à partir de
la version AIX 5.2. Pour plus d’informations sur la journalisation des erreurs dans AIX,
reportez–vous à la section Error–Logging Overview dans AIX 5L Version 5.3 General
Programming Concepts: Writing and Debugging Programs
5-18
Concepts de gestion de système AIX – Système d’exploitation et unités
Description de la segmentation de l’espace disque
La plupart des systèmes de fichiers UNIX allouent uniquement un espace disque contigu en
unités dont la taille est égale à celle des blocs logiques utilisés pour la division logique des
fichiers et des répertoires. Ces unités d’allocation s’appellent généralement des blocs de
disque et un seul bloc de disque est utilisé exclusivement pour stocker des données
contenues dans un seul bloc logique de fichier ou de répertoire.
L’utilisation d’une taille de bloc logique relativement grande (4096 octets par exemple) et la
gestion des allocations de blocs de disque dont la taille est égale à celle du bloc logique
permettent de réduire le nombre d’opérations E/S exécutées par une seule opération de
système d’exploitation. Les données d’un fichier ou d’un répertoire sont stockées sur disque
dans un plus petit nombre de blocs de plus grande taille au lieu d’être stockées dans un
grand nombre de petits blocs de disque. Par exemple, un fichier de 4096 octets ou moins
est alloué à un bloc de disque de 4096 octets si la taille de bloc logique est égale à 4096
octets. En conséquence, une opération de lecture ou d’écriture n’effectue qu’une seule
opération E/S sur disque pour accéder aux données du disque. Si la taille de bloc logique
est plus petite et nécessite plusieurs allocations pour la même quantité de données,
plusieurs opérations E/S sur disque sont nécessaires pour accéder aux données. Un grand
bloc logique et une taille de bloc de disque égale permettent également de réduire le
nombre d’allocations d’espace disque qui doivent être exécutées lorsque des données sont
ajoutées aux fichiers et aux répertoires, car les grands blocs de données contiennent plus
de données.
La limitation de l’unité d’allocation d’espace disque à la taille de bloc logique peut toutefois
générer une perte d’espace disque dans un système de fichiers qui contient de nombreux
petits fichiers et répertoires. Une perte d’espace disque se produit lorsque la valeur d’un
bloc logique d’espace disque est allouée à un bloc logique partiel d’un fichier ou d’un
répertoire. Du fait que les blocs logiques partiels contiennent toujours moins d’un bloc
logique de données, un bloc logique partiel ne consomme qu’une partie de l’espace disque
qui lui est alloué. La partie restante est inutilisée, car aucun autre fichier ou répertoire ne
peut écrire son contenu dans l’espace de disque qui a déjà été alloué. La quantité totale
d’espace disque perdue peut être importante pour les systèmes de fichiers qui contiennent
un grand nombre de petits fichiers et répertoires.
Le système de fichiers (Journaled File System) divise l’espace disque en unités d’allocation
appelées fragments. Le système de fichiers JFS2 (Enhanced Journaled File System)
segmente l’espace disque en blocs. L’objectif est le même : stocker efficacement les données.
Les fragments JFS sont plus petits que la taille d’allocation de disque par défaut de
4096 octets. Les fragments réduisent les pertes d’espace disque en stockant beaucoup
plus efficacement les données dans des blocs logiques partiels de fichier ou de répertoire.
Le comportement fonctionnel du support des fragments JFS repose sur celui fourni par le
support des fragments BSD (Berkeley Software Distribution).
JFS2 prend en charge plusieurs tailles de blocs de système de fichiers, à savoir 512, 1 024,
2 048 et 4 096. Des blocs de plus petite taille réduisent les pertes d’espace disque en
stockant plus efficacement les données dans des blocs logiques partiels de fichier ou de
répertoire. Les blocs de petite taille augmentent la charge de travail. La taille des blocs d’un
système de fichiers JFS2 est définie lors de sa création. Des systèmes de fichiers différents
peuvent avoir des tailles de blocs différentes, mais une seule taille de bloc peut être utilisée
dans un même système de fichiers.
Systèmes de fichiers
5-19
Fragments JFS
Dans JFS, l’unité d’allocation d’espace disque s’appelle un fragment dont la taille peut être
inférieure à celle d’un bloc logique de 4096 octets. En utilisant des fragments de moins de
4 096 octets, les données contenues dans un bloc logique partiel peuvent être stockées
plus efficacement en utilisant uniquement le nombre de fragments nécessaire pour stocker
les données. Par exemple, un bloc logique partiel de 500 octets peut être alloué à un
fragment de 512 octets (en supposant que la taille de fragment est de 512 octets), ce qui
permet de réduire considérablement les pertes d’espace disque. Si les besoins en stockage
d’un bloc logique partiel augmentent, un ou plusieurs fragments supplémentaires sont
alloués.
La taille de fragment d’un système de fichiers est définie lors de sa création. Des fragments
de 512, 1024, 2048 et 4096 octets peuvent être alloués à un système de fichiers JFS. Des
systèmes de fichiers différents peuvent avoir des tailles de fragments différentes, mais une
seule taille de fragment peut être utilisée dans un même système de fichiers. Différentes
tailles de fragments peuvent également coexister sur un même système (machine) pour
que les utilisateurs puissent sélectionner la taille la mieux adaptée à chaque système de
fichiers.
Le support de fragment JFS fournit une vue du système de fichiers sous la forme d’une
série de fragments contigus et non sous la forme d’une série de blocs de disque contigus.
Pour garantir l’efficacité des opérations sur disque, l’espace disque est souvent alloué en
unités de 4096 octets pour que les blocs de disque ou les unités d’allocation aient la même
taille que les blocs logiques. Dans ce cas, une allocation de bloc de disque correspond à
une allocation de 4096 octets de fragments contigus.
L’augmentation de la charge de travail (recherches sur disque, transferts de données et
activité d’allocation supplémentaires) et la meilleure utilisation de l’espace disque sont
inversement proportionnelles à la taille de fragment d’un système de fichiers. Pour garantir
un équilibre optimum entre l’augmentation de la charge de travail et la diminution de
l’espace disque, les facteurs suivants s’appliquent au support de fragment JFS :
• Dans la mesure du possible, les allocations de fragments de 4096 octets sont prises en
charge pour un fichier ou les blocs logiques d’un répertoire.
• Des fragments de moins de 4096 octets peuvent être alloués uniquement à des blocs
logiques partiels de fichier ou de répertoire de moins de 32 Ko
Du fait que la taille des fichiers et des répertoires d’un système de fichiers dépasse 32 Ko,
l’avantage de gérer des allocations d’espace disque de moins de 4096 octets pour les blocs
logiques partiels diminue. L’économie d’espace disque en tant que pourcentage de l’espace
de système de fichiers total diminue alors que les performances de gestion de petites
allocations d’espace disque restent constantes. Du fait que les allocations d’espace disque
de moins de 4096 octets permettent d’utiliser l’espace disque plus efficacement avec des
petits fichiers et répertoires, les blocs logiques des fichiers et des répertoires dont la taille
est égale ou supérieure à 32 Ko se voient toujours alloués 4096 octets de fragments. 4096
octets de fragment sont alloués à tout bloc logique partiel associé à un fichier ou un
répertoire volumineux.
Blocs JFS2
Le système de fichiers JFS2 (Enhanced Journaled File System) segmente l’espace disque
en blocs. JFS2 prend en charge différentes tailles de blocs de système de fichiers, à savoir
512, 1024, 2048 et 4096. Différents systèmes de fichiers peuvent avoir différentes tailles de
blocs, mais une seule taille de bloc peut être utilisée dans un même système de fichiers.
Les petits blocs réduisent les pertes d’espace disque en stockant beaucoup plus
efficacement les données dans des blocs logiques partiels de fichier ou de répertoire. Les
blocs de petite taille augmentent également la charge de travail. En outre, les pilotes
d’unités doivent fournir une adressibilité de bloc de disque égale ou inférieure à la taille de
bloc du système de fichiers.
5-20
Concepts de gestion de système AIX – Système d’exploitation et unités
Du fait que l’espace disque est alloué en petites unités pour un système de fichiers avec
une taille de bloc autre que 4096 octets, les activités d’allocation sont plus fréquentes
lorsque la taille des fichiers ou des répertoires augmentent régulièrement. Par exemple, une
opération d’écriture qui augmente la taille d’un fichier vide de 512 octets génère une
allocation d’un bloc pour le fichier, en supposant une taille de bloc de 512 octets. Si la taille
du fichier augmente de nouveau de 512 octets en écriture, un bloc supplémentaire doit être
alloué au fichier. Si l’on applique cet exemple à un système de fichiers qui utilise des blocs
de 4096 octets, l’allocation d’espace disque se produit une seule fois dans le cadre de la
première opération d’écriture. Aucune autre activité d’allocation supplémentaire n’est
exécutée lors de la seconde opération d’écriture du fait que l’allocation initiale de 4096
octets est suffisamment importante pour stocker les données ajoutées par la seconde
opération d’écriture.
La taille de bloc d’un système de fichiers est définie lors de la création du système de
fichiers avec Web–based System Manager, SMIT (System Management Interface Tool)
ou les commandes crfs et mkfs. La taille de bloc de système de fichiers à utiliser doit être
déterminée en fonction de la taille prévisible des fichiers du système de fichiers.
La taille de bloc d’un système de fichiers peut être identifiée via Web–based System
Manager, SMIT (System Management Interface Tool) ou la commande lsfs. Pour les
applications, utilisez la sous–routine statfs pour identifier la taille des blocs du système
de fichiers.
Les blocs font office d’unités de base pour l’allocation d’espace disque et l’état de
l’allocation de chaque bloc dans un système de fichiers est enregistré dans la mappes
d’allocation de blocs du système de fichiers. Une plus grande quantité de mémoire virtuelle
et d’espace disque de système de fichiers peuvent être nécessaire pour stocker les mappes
d’allocation de blocs des systèmes de fichiers dont la taille de bloc est inférieure à 4096
octets.
Description du nombre variable d’i–nodes
L’utilisation de segments d’espace disque de moins de 4 096 octets permet d’optimiser
l’utilisation de l’espace disque, mais elle augmente le nombre de petits fichiers et de
répertoires qui peuvent être stockés dans un système de fichiers. Toutefois, l’espace disque
correspond uniquement à l’une des ressources de système de fichiers nécessaires aux
fichiers et aux répertoires : chaque fichier ou répertoire nécessite également un i–node de
disque.
JFS et i–nodes
JFS permet de définir le nombre d’i–nodes de disque créés dans un système de fichier
lorsqu’un nombre d’i–nodes de disque inférieur ou supérieur au nombre d’i–nodes de
disque par défaut est nécessaire. Le nombre d’i–nodes de disque lors de la création du
système de fichiers est défini par une valeur appelée nombre d’octets par i–node ou NBPI.
Par exemple, une valeur NBPI de 1024 génère la création d’i–nodes de disque pour chaque
1024 octets d’espace disque du système de fichiers. Il convient également de considérer
qu’une petite valeur l NBPI (512, par exemple) génère un grand nombre d’i–nodes alors
qu’une grande valeur NBPI (telle que 16384) génère un plus petit nombre d’i–nodes.
Pour un système de fichiers JFS, un i–node est créé pour chaque octet NBPI d’espace de
groupe d’allocation alloué au système de fichiers. Le nombre total d’i–nodes dans un
système de fichiers limite le nombre total de fichiers et la taille totale du système de fichiers.
Un groupe d’allocation peut être alloué partiellement bien que le nombre total d’i–nodes par
groupe d’allocation soit toujours alloué. La valeur NBPI est inversement proportionnelle au
nombre total d’i–nodes dans un système de fichiers.
JFS limite tous les systèmes de fichiers à 16 Mo (2 24) d’i–nodes.
Systèmes de fichiers
5-21
Le groupe de valeurs NBPI pouvant être alloué varie en fonction de la taille du groupe
d’allocation (agsize). La valeur par défaut est 8 Mo. Les valeurs NBPI pouvant être allouées
sont 512, 1024, 2048, 4096, 8192 et 16384 avec une valeur agsize de 8 Mo. Une plus
grande taille peut être utilisée. Les valeurs agsize peuvent être égales à 8, 16, 32 et 64. La
plage de valeurs NBPI augmente lorsque la valeur agsize augmente. Si la valeur agsize est
le double de 16 Mo, les valeurs de la plage de valeurs NBPI double également : 1024,
2048, 4096, 8193, 16384 et 32768.
La taille de fragment et la valeur NBPI sont définie lors de la création du système de fichiers
avec Web–based System Manager, SMIT (System Management Interface Tool) ou les
commandes crfs et mkfs. La détermination de la taille de fragment et du nombre di–nodes
à créer pour le système de fichiers dépendent du nombre de fichiers et de la taille des
fichiers prévisibles du système de fichiers.
La taille de fragment et la valeur NBPI peuvent être identifiées via Web–based System
Manager, SMIT (System Management Interface Tool) ou la commandes lsfs. Pour les
applications, utilisez la sous–routine statfs pour identifier la taille des fragments du système
de fichiers.
JFS2 et i–nodes
JFS2 alloue des i–nodes en fonction des besoins. Si le système de fichiers contient un
espace suffisant pour créer d’autres i–nodes, des i–nodes sont alloués automatiquement.
En conséquence, le nombre d’i–nodes disponible est limité par la taille du système de
fichiers.
Description des limitations de taille
Vous définissez la taille maximale d’un système de fichiers JFS lors de sa création. La taille
du système de fichiers JFS dépend de plusieurs éléments importants. La section suivante
décrit les principales considérations.
La taille maximale recommandée pour un système de fichiers JFS2 est de 16 téraoctets.
Les principales considérations associées aux systèmes de fichiers JFS2 volumineux
sont décrites dans la section Taille de journal, page 5-23 et Limitations de taille JFS2 ,
page 5-24.
Bien que les systèmes de fichiers qui utilisent une unité d’allocation inférieure à 4096 octets
nécessitent substantiellement moins d’espace disque que ceux dont l’unité d’allocation par
défaut est de 4096 octets, l’utilisation de fragments plus petits peut avoir un impact sur les
performances.
L’état d’allocation de chaque fragment (JFS) o bloc (JFS2) dans un système de fichiers est
enregistré dans la mappe d’allocation du système de fichiers. Une plus grande quantité de
mémoire virtuelle et d’espace disque de système de fichiers peuvent être nécessaires pour
stocker les mappes d’allocation des systèmes de fichiers dont la taille de fragment ou de
bloc est inférieure à 4096 octets.
Du fait que l’espace disque est alloué en petites unités pour un système de fichiers avec
une taille de fragment autre que 4096 octets, les activités d’allocation sont plus fréquentes
lorsque la taille des fichiers ou des répertoires augmente régulièrement. Par exemple, une
opération d’écriture qui augmente la taille d’un fichier vide de 512 octets génère une
allocation de fragment ou de bloc de 512 octets pour le fichier, en fonction du type de
système de fichiers. Si la taille du fichier augmente de nouveau de 512 octets en écriture,
un fragment ou un bloc supplémentaire doit être alloué au fichier. Si l’on applique cet
exemple à un système de fichiers qui utilise des fragments ou des blocs de 4096 octets,
l’allocation d’espace disque se produit une seule fois dans le cadre de la première opération
d’écriture. Aucune autre activité d’allocation supplémentaire n’est exécutée lors de la
seconde opération d’écriture du fait que l’allocation initiale de 4 096 octets est suffisamment
importante pour stocker les données ajoutées par la seconde opération d’écriture. L’activité
d’allocation peut être réduite si la taille des fichiers augmente de 4 096 octets à la fois.
5-22
Concepts de gestion de système AIX – Système d’exploitation et unités
Taille de journal
L’un des problèmes de taille est associé à la taille du journal du système de fichiers.
Pour JFS, dans la majorité des cas, plusieurs systèmes de fichiers utilisent un journal
commun dont la taille est de 4 Mo. Par exemple, après l’installation initiale, tous les
systèmes de fichiers dans le groupe de volume racine utilisent le volume logique hd8
comme journal JFS. La taille de partition par défaut du volume logique est de 4 Mo et la
taille par défaut du journal étant égale à une partition, le groupe de volume racine contient
normalement un journal JFS de 4 Mo. Lorsque la taille des systèmes de fichiers par défaut
est supérieure à 2 Go ou que l’espace total du système de fichiers utilisant un seul journal
est supérieur à 2 go, la taille de journal par défaut peut s’avérer insuffisante. Dans les deux
cas, les tailles de journaux augmentent lorsque la taille des systèmes de fichiers augmente.
Lorsque la taille du volume logique du journal change, la commande logform doit être
exécutée pour réinitialiser le journal et pouvoir utiliser le nouvel espace. La taille du journal
JFS est limité à 256 Mo.
Un journal JFS peut prendre en charge une certaine taille cumulée de systèmes de fichiers.
Comme référence, une capacité totale de systèmes de fichiers d’un trois millions d’octets
est la limite recommandée pour un journal JFS. Lorsque cette limite est dépassée ou est
sur le point d’être dépassée ou qu’un manque de mémoire existe lors de l’exécution de la
commande logredo (exécutée par la commande fsck), ajoutez un journal JFS et partagez
la charge entre les journaux JFS.
Pour JFS2, dans la plupart des cas, plusieurs systèmes de fichiers utilisent un journal
commun. Lorsque la taille des systèmes de fichiers par défaut est supérieure à 2 Go ou que
l’espace total des systèmes de fichiers utilisant un seul journal est supérieur à 2 Go, la taille
de journal par défaut peut s’avérer insuffisante. Dans les deux cas, vous pouvez augmenter
la taille des journaux à mesure que celle du système de fichier augmente ou vous pouvez
ajouter un journal JFS2 et partager la charge entre les deux journaux JFS2.
Limites de taille JFS
La taille maximale JFS est définie lors de la création du système de fichiers. La valeur NBPI,
la taille de fragment et la taille de groupe d’allocation déterminent la taille maximale. La
limitation de la taille du système de fichiers correspond aux valeurs minimales suivantes :
NBPI
* 2
24
ou
Taille_fragment
* 2
28
Par exemple, si vous sélectionnez un taux NBPI de 512, la taille du système de fichiers est
limitée à 8 Go ( 512 * 2 24 = 8 Go ). JFS prend en charge les valeurs NBPI 512,
1 024, 2 048, 4 096, 8 192, 16 384, 32 768, 65 536 et 131 072.
JFS limite tous les systèmes de fichiers à 16 Mo ( 2 24 ) d’i–nodes.
Un i–node est créé pour chaque octet NBPI d’espace de groupe d’allocation alloué au
système de fichiers. Un groupe d’allocation peut être alloué partiellement bien que le
nombre total d’i–nodes par groupe d’allocation soit toujours alloué. La valeur NBPI est
inversement proportionnelle au nombre total d’i–nodes dans un système de fichiers.
Systèmes de fichiers
5-23
JFS divise l’espace de système de fichiers en groupes d’i–nodes et de blocs de disque pour
les données utilisateur. Ces groupes s’appellent des groupes d’allocation. La taille de
groupe d’allocation peut être définie lors que la création du système de fichiers. Les tailles
de groupe d’allocation sont 8 Mo, 16 Mo, 32 Mo et 64 Mo. Chaque taille de groupe
d’allocation est associée à une plage NBPI. Les plages sont définies en fonction du tableau
suivant :
Groupe d’allocation
Taille en mégaoctets
8
Valeurs NBPI allouables
512, 1024, 2048, 4096, 8192, 16384
16
1024, 2048, 4096, 8192, 16384, 32768
32
64
131072
2048, 4096, 8192, 16384, 32768, 65536
4096, 8192, 16384, 32768, 65536,
JFS supporte quatre tailles de segments, à savoir des unités de 512, 1 024, 2 048 et 4
096 octets d’espace disque contigus. JFS gère les adresses des segments dans les
i–nodes et les blocs indirects sous forme de nombre de 28 bits. Chaque segment doit être
adressable par un nombre compris entre 0 et ( 2 28 ).
Description des limitations de taille JFS2
Les tests montrent que des systèmes de fichiers JFS2 très volumineux sont plus faciles à
gérer que les systèmes de fichiers qui contiennent un grand nombre de petits fichiers.
Lorsqu’un système de fichiers volumineux contient un grand nombre de petits fichiers,
l’exécution de la commande fsck et des autres tâches de maintenance des systèmes de
fichiers est plus longue. Les limitations de tailles suivantes sont recommandées :
Taille maximale de système de fichiers
JFS2 :
16 To
Taille maximale de fichier JFS2 :
16 To
Fragmentation de l’espace libre JFS
Pour les systèmes de fichiers JFS, l’utilisation de fragments inférieurs à 4 096 octets peut
provoquer une plus fragmentation plus importante de l’espace disque libre. Par exemple,
considérez une zone du disque qui est divisée en huit fragments de 512 octets chacun.
Supposons que différents fichiers, nécessitant chacun 512 octets, sont écrits dans le
premier, le quatrième, le cinquième et le septième segments dans cette zone de disque et
que le deuxième, le troisième, le sixième et le huitième segments sont libres. Bien que
quatre fragments représentant 2048 octets d’espace disque soient libres, aucun bloc
logique partiel nécessitant quatre fragments (ou 2048 octets) n’est alloué pour ces
fragments libres du fait que les fragments d’une allocation doivent être contigus.
5-24
Concepts de gestion de système AIX – Système d’exploitation et unités
Du fait que les fragments pour un fichier ou des blocs logiques de répertoire doivent être
contigus, la fragmentation de l’espace libre peut provoquer l’échec d’un système de fichiers
qui demande un nouvel espace disque, même si la quantité d’espace libre disponible est
suffisamment grande pour répondre aux besoins de l’opération. Pour exemple, une
opération d’écriture qui augmente la taille d’un fichier vide d’un bloc logique nécessite
l’allocation de 4096 octets d’espace disque contigu. Si l’espace libre de système fichiers
est fragmenté et qu’il est constitué de 32 fragments de 512 octets non contigus ou d’un total
de 16 Ko d’espace libre, l’opération d’écriture échoue car huit fragments contigus (ou
4096 octets d’espace disque contigu) ne sont pas disponibles pour exécuter l’opération.
Un système de fichiers JFS avec une quantité d’espace libre fragmenté non gérable peut
être défragmenté avec la commande defragfs. La commande defrags a un impact positif
sur les performances.
Description des fichiers supplémentaires
Un fichier est une séquence des blocs indexés. Les blocs sont associés depuis l’i–node au
décalage logique du fichier qu’ils représentent.
Un fichier qui dispose d’un ou de plusieurs index qui ne sont pas associés à un bloc de
données est considéré être un fichier alloué sporadiquement ou fichier sporadique. Un
fichier sporadique a une taille donnée, mais il ne contient pas tous les blocs alloués pour
répondre aux exigences de taille. Pour déterminer si un fichier est alloué sporadiquement,
utilisez la commande fileplace. La commande indique tous les blocs du fichier qui ne sont
pas alloués.
Remarque :
Dans la plupart des cas, la commande du peut être également utilisée pour
déterminer si le nombre de blocs de données alloués à un fichier ne
correspondent pas à ceux nécessaires au stockage d’un fichier de cette
taille. Un système de fichiers compressé a le même comportement que les
fichiers qui ne sont pas alloués sporadiquement.
Un fichier supplémentaire est créé lorsqu’une application étend un fichier en effectuant une
recherche dans un emplacement externe aux index alloués, tandis que les données qui
sont écrites n’occupent pas l’ensemble des nouveaux index affectés. La nouvelle taille de
fichier reflète l’opération d’écriture à la dernière extrémité dans le fichier.
Une opération de lecture dans une section d’un fichier qui contient des blocs de données
non alloués génère un tampon de zéros qui sont retournés. Lorsqu’une opération d’écriture
a lieu dans un fichier qui contient des blocs de données non alloués, les blocs de données
nécessaires sont alloués et les données sont écrites.
Ce comportement peut affecter la manipulation du fichier ou les commandes d’archivage.
Par exemple, les commandes suivantes ne préservent pas l’allocation ponctuelle d’un
fichier :
• cp
• mv
• tar
• cpio
Remarque :
Dans le cas de la commande mv, cela s’applique uniquement au transfert
d’un fichier vers un autre système de fichiers. Si le fichier est transféré dans
le même système de fichiers, il demeure un fichier sporadique.
Systèmes de fichiers
5-25
Lorsqu’un fichier est copié ou restauré depuis les commandes précédentes, chaque bloc
de données est alloué et le fichier ne dispose pas de caractéristiques supplémentaires.
Toutefois, les commandes d’archivage préservent les caractéristiques sporadiques ou
utilisent activement un fichier sporadique :
• backup
• restore
• pax
Du fait qu’il est possible d’omettre des ressources pour un systèmes de fichiers avec des
fichiers sporadiques, vous devez utiliser et gérer ce type de fichier avec précaution.
Description des fichiers volumineux et JFS
Cette section explique comment créer des fichiers volumineux et l’allocation de fichiers avec
le système de fichiers JFS. Tous les systèmes de fichiers JFS2 prennent en charge des
fichiers volumineux.
Les systèmes de fichiers compatibles avec les fichiers volumineux peuvent être créés avec
les commandes crfs et mkfs. Les deux commandes disposent d’une option (bf=true) qui
permet de définir les systèmes de fichiers compatibles avec les fichiers volumineux. Vous
pouvez également utiliser SMIT ou Web-based System Manager pour créer des systèmes
de fichiers.
Dans les systèmes de fichiers compatibles avec les fichiers volumineux, les données des
fichiers sont stockées avant que les 4 Mo des fichiers soient alloués dans des blocs de
4 096 octets. Les données des fichiers stockées au–delà de la limite de 4 Mo sont affectées
de grand blocs de disque de 128 Ko. En fait, les grands blocs de disque correspondent à
32 blocs de 4096 octets contigus.
Par exemple, dans un système de fichiers normal, le fichier de 132 Mo nécessite 33 blocs
de disque de 4 Ko (33 blocs indirects contenant chacun 1024 adresses de disque de 4 Ko).
Un fichier de 132 Mo dans un système de fichiers compatible avec des fichiers volumineux
contient 1024 blocs de disque de 4 Ko et 1024 blocs de disque de 128 Ko. La géométrie de
fichier volumineux nécessite uniquement des blocs indirects simples pour un fichier de
132 Mo. Les types de fichiers volumineux et normaux nécessitent un double bloc indirect.
Les blocs de disque volumineux nécessitent 32 blocs de 4 Ko contigus. Si vous écrivez
dans des fichiers volumineux au–delà de 4 Mo, le décalage de fichier échoue avec
ENOSPC si le système de fichiers ne contient pas 32 blocs de 4 Ko contigus non utilisés.
Remarque :
Le système de fichiers peut contenir des milliers de blocs libres, mais si
32 d’entre eux ne sont pas contigus, l’allocation échoue.
La commande defragfs identifie les blocs de disque pour fournir des zones de blocs libres
contiguës.
Le système de fichiers JFS nécessite d’initialiser toutes les nouvelles allocations de disque.
JFS démarre la procédure kproc du noyau pour mettre à zéro l’allocation de fichier initiale
lors du montage du premier système de fichiers compatible avec les fichiers volumineux
du système. La procédure kproc reste active une fois que le système de fichiers compatible
avec les fichiers volumineux a été démonté.
Description de la compression des données JFS
Le système de fichiers JFS prend en charge les systèmes de fichiers fragmentés et
compressés qui permettent d’économiser l’espace disque en permettant à un bloc logique
d’être stocké sur le disque sous forme d’unités ou de ”fragments” d’une taille inférieure à la
taille totale de bloc de 4096 octets. JFS2 ne prend pas en charge la compression des
données.
5-26
Concepts de gestion de système AIX – Système d’exploitation et unités
Dans un système de fichiers fragmenté, seul le dernier bloc logique des fichiers inférieurs à
32 Ko est stocké de cette manière. Le support de fragment n’est ainsi que bénéfique aux
systèmes de fichiers qui contiennent de nombreux petits fichiers. Toutefois, la compression
des données permet de stocker tous les blocs logiques d’un fichier de n’importe quelle taille
sous la forme d’un ou de plusieurs fragments contigus. En moyenne, la compression des
données permet d’économiser la moitié de l’espace disque.
L’utilisation de fragments et de la compression de données, augmentent toutefois la
fragmentation potentielle de l’espace disque libre. Les fragments alloués à un bloc logique
doivent être contigus sur le disque. Un système de fichiers soumis à une fragmentation
d’espace peut avoir des difficultés à rechercher suffisamment de fragments contigus pour
une allocation de bloc logique, même si le nombre total de fragments libres est supérieur
aux besoins de bloc logique. Le système de fichiers JFS réduit la fragmentation de l’espace
en fournissant le programme defragfs qui ”défragmente” un système de fichiers en
augmentant la quantité d’espace libre contiguë. Cet utilitaire peut être utilisé pour
fragmenter et compresser des systèmes de fichiers L’économie d’espace disque issue des
fragments et de la compression des données peut être significative tandis que la
fragmentation de l’espace libre reste gérable.
La compression des données dans le système de fichiers JFS en cours est compatible avec
les versions précédentes du système d’exploitation. L’API constituée de tous les appels
système reste la même dans les deux versions du système de fichiers JFS.
Pour plus d’informations sur la prise en charge des fragments, l’utilisation du disque, la
fragmentation de l’espace libre et les coûts en performances associés aux fragments,
reportez–vous à la section Description de la segmentation de l’espace libre, page 5-19.
Mise en œuvre de la compression des données
Attention : Le système de fichiers racine (/) ne doit pas être compressé. La compression
du système de fichiers /usr n’est pas recommandée, car installp doit pouvoir calculer
précisément sa taille pour les mises à jour et les nouvelles installations. Pour plus
d’informations sur la taille et les calculs, reportez–vous à la section Comportement implicite,
page 5-28.
La compression des données est un attribut d’un système de fichiers, qui est défini lors de
la création du système de fichiers avec la commande crfs ou mkfs. Vous pouvez
également utiliser Web-based System Manager ou SMIT pour définir la compression des
données. La compression ne s’applique qu’aux fichiers normaux et aux liens symboliques
longs des systèmes de fichiers de ce type. Le support de la fragmentation continue de
s’appliquer aux répertoires et aux métadonnées qui ne sont pas comprimés. Chaque bloc
logique d’un fichier s’auto–comprime avant d’être écrit sur le disque. De cette manière, la
compression facilite les recherches aléatoires et les mises à jour tout en ne perdant qu’une
petite quantité d’espace disque libre par rapport à la compression des données dans des
unités plus grandes.
Après la compression, un bloc logique nécessite en général moins de 4096 octets d’espace
libre. Le bloc logique compressé est écrit sur le disque et reçoit uniquement le nombre de
fragments contigus nécessaire à son stockage. S’il est impossible de compressé un bloc
logique, le bloc est écrit sur le disque non compressé et il reçoit 4096 octets de fragments
contigus.
La commande lsfs –q affiche la valeur en cours de la compression. Vous pouvez également
utiliser Web-based System Manager ou SMIT pour identifier la compression des données.
Systèmes de fichiers
5-27
Comportement implicite
Du fait qu’un programme qui écrit un fichier ne s’attend pas à manquer d’espace (ENOSPC)
après la réussite de l’écriture (ou le stockage des fichiers mappés), il est nécessaire de
garantir la disponibilité de l’espace lorsque les blocs logiques sont écrits sur le disque. Cette
opération est effectuée en allouant 4096 octets à un bloc logique lorsqu’il est modifié pour la
première fois pour qu’il existe un espace disque disponible si le bloc ne peut pas être
compressé. Si une allocation de 4096 octets n’est pas disponible, le système retourne une
erreur ENOSPC ou EDQUOT, même s’il existe un espace disque suffisant pour contenir le
bloc logique compressé. La signalisation du manque d’espace anticipé se produit en
général lorsque les limites de quotas de disque sont presque atteintes ou lorsque le
système de fichiers est presque plein.
Les systèmes de fichiers compressés peuvent avoir également les comportements
suivants :
• Du fait que 4096 octets sont initialement alloués à un bloc logique, certains appels
système peuvent recevoir une erreur ENOSPC ou EDQUOT. Par exemple, un ancien
fichier peut être mappé à l’aide de l’appel système mmap et une opération dans un
emplacement déjà écrit peut provoquer une erreur ENOSPC.
• Avec la compression des données, un bloc de disque plein reste alloué à un bloc modifié
jusqu’à ce qu’il soit écrit sur le disque. Si le bloc a eu précédemment une allocation
validée d’une taille inférieure à un bloc complet, la quantité d’espace disque occupée par
le bloc correspond à la somme des deux, l’allocation précédente n’étant pas libre tant
que le fichier (i–node) n’est pas validé. C’est le cas pour les fragments normaux. Le
nombre de blocs logiques dans un fichier dont les allocations précédentes peuvent être
validées correspond, au plus, au nombre de fragments normaux, mais peut
correspondre au nombre de blocs dans un fichier avec compression.
• Aucune des ressources déjà validées d’un bloc logique n’est libérée tant que l’appel
fsync ou sync n’est pas exécuté par l’application.
• L’appel système stat indique le nombre de fragments alloués à un fichier. Le nombre
indiqué est basé sur les 4096 octets alloués aux blocs modifiés mais non écrits et à la
taille compressée des blocs non modifiés. Les ressources déjà validées ne sont pas
prises en compte par l’appel système stat. L’appel système stat indique le nombre
correct de fragments alloués après une validation d’i–node si aucun des blocs modifiés
n’est compressé. De même, les quotas de disque sont pris en compte pour l’allocation
en cours. Lors de l’écriture des blocs logiques d’un fichier sur le disque, le nombre de
fragments qui leur sont associés diminue s’ils sont compressés et ils changent donc les
quotas de disque et le résultat de stat.
Algorithme de compression
L’algorithme de compression correspond à une version LZ Bull. En général, les algorithmes
LZ compressent les données en représentant la deuxième et la dernière occurrence d’une
chaîne donnée avec un pointeur qui identifie l’emplacement de la première occurrence de la
chaîne et sa longueur. Au début de la compression, aucune chaîne n’est identifiée et en
conséquence au moins le premier octet de données doit être représenté sous la forme d’un
caractère ”brut” nécessitant 9 bits (0, octet). Une fois qu’une certaine quantité de données
est compressée, par exemple N octets, le compresseur recherche la plus longue chaîne
dans les octets N qui correspond à la chaîne de début de l’octet suivant non compressé.
Si la longueur la plus grande correspondante est égale à 0 ou 1, l’octet suivant est codé
comme caractère ”brut”. Sinon, la chaîne est représentée sous la forme d’une paire
(pointeur, longueur) et le nombre d’octets traité est incrémenté de la longueur. D’un point de
vue architectural, LZ Bull supporte des valeurs N de 512, 1 024 et 2 048. LZ Bull définit le
codage des paires (pointeur, longueur) et les caractères bruts. Le pointeur est un champ de
longueur fixe de taille log2 N, alors que la longueur est codée sous la forme d’un champ de
longueur variable.
5-28
Concepts de gestion de système AIX – Système d’exploitation et unités
Coûts de performances
Du fait que la compression des données est une extension de la fragmentation, les
performances associées aux fragments s’appliquent à la compression des données.
Les systèmes de fichiers compressés affectent également les performances des manières
suivantes :
• La compression et la décompression des données peuvent nécessiter beaucoup de
temps pour que l’utilisation d’un système de fichiers compressé puisse être limitée pour
certains environnements utilisateur.
• La plupart des fichiers normaux UNIX sont écrits une seule fois, mais certains sont mis
à jour sur place. Pour ces derniers, la compression des données ajoute une surcharge
d’allocation de 4 096 octets d’espace disque lorsqu’un bloc logique est modifié, puis
réalloue l’espace disque après l’écriture du bloc logique sur le disque. Cette activité
d’allocation supplémentaire n’est pas nécessaire aux fichiers normaux d’un système
de fichiers non compressé.
• La compression des données augmente le nombre de cycles de processeur. Pour le
compresseur logiciel, le nombre de cycles de compression est d’environ 50 par octet
et de 10 par octet pour la décompression.
Description des sauvegardes en ligne JFS et des clichés JFS2
Vous pouvez créer un cliché d’un système de fichiers JFS ou JFS2 (AIX 5.2 et versions
supérieures) que vous pouvez utiliser ensuite pour les sauvegardes. Toutefois, il existe des
différences dans les besoins et le comportement de cette image pour chaque type de
système de fichiers.
Pour un système de fichiers JFS, vous pouvez diviser une copie statique en lecture seule
d’une copie miroir du système de fichiers. Généralement, une copie miroir est mise à jour
chaque fois que le système de fichiers est mis à jour, mais ce cliché ne change pas. Il s’agit
d’une image stable au moment où la copie a été effectuée. Lorsque cette image est utilisée
pour la sauvegarde, toute modification après le début de la procédure de création de
l’image peut ne pas figurer dans la copie de sauvegarde. En conséquence, il est
recommandé d’effectuer la division lorsque l’activité du système de fichiers est minimale.
Toute modification effectuée après la division ne figure pas dans la copie de sauvegarde.
Pour un système de fichiers JFS2, l’image cliché s’appelle cliché. Le cliché reste statique et
il conserve les autorisations de sécurité que le système de fichiers d’origine (appelé
snappedFS) avait avant le cliché. En outre, vous pouvez créer un cliché JFS2 sans monter
ou arrêter le système de fichiers. Vous pouvez utiliser un cliché JFS2 comme sauvegarde
en ligne du système de fichiers, pour accéder aux fichiers ou aux répertoires tels qu’ils
existaient lors du cliché ou pour sauvegarder sur un support amovible. Notez les éléments
suivants sur les clichés JFS2.
• Un cliché du système de fichiers racine (/) ou du système de fichiers /usr est remplacé
lorsque le système est réamorcé. Les clichés des autres systèmes de fichiers peuvent
être préservés en démontant les systèmes de fichiers avant de réamorcer le système.
Les clichés créés dans AIX 5.2 avec 5200–01 sont récupérables. Lorsque fsck ou
logredo est exécuté sur un système de fichiers JFS2 avec un cliché créé sur AIX 5.2
avec 5200–01, le cliché est préservé. Un système de fichiers proprement démonté avec
un cliché AIX 5.2 est également récupérable une fois monté sur un système AIX 5.2
avec 5200–01.
• Il est recommandé de ne pas exécuter la commande defragfs sur un système de
fichiers avec des clichés. Chaque bloc transféré lors de la défragmentation doit être
également copié vers le cliché, ce qui prend du temps et génère une perte d’espace
dans le volume logique du cliché.
• Si un cliché manque d’espace, tous les clichés de ce système de fichiers cliché sont
supprimés. Cette erreur est consignée dans le journal des erreurs.
• Si l’écriture d’un cliché échoue, tous les clichés de ce système de fichiersz cliché sont
supprimés. Cette erreur est consignée dans le journal des erreurs.
Systèmes de fichiers
5-29
• Un cliché créé ou auquel vous accédez sur un système AIX 5.2 avec 5200–01 n’est pas
accessible sur un système AIX 5.2. Ces clichés doivent être supprimés pour pouvoir
monter le système de fichiers.
• Un système de fichiers JFS2 avec un cliché sur AIX 5.3 n’est pas accessible avec
les versions antérieures à AIX 5.2 avec 5200–01. Si le système doit de nouveau être
déplacé, les clichés doivent d’abord être supprimés pour permettre l’accès au système
de fichiers.
Description de la compatibilité et de la migration
Les systèmes de fichiers JFS sont totalement compatibles avec AIX 5.1 et AIX 5.2. Les
versions précédentes prises en charge du système d’exploitation sont compatibles avec
le système de fichiers actuel, bien que les systèmes de fichiers sans taille de fragment par
défaut, valeur NBPI ou taille de groupe d’allocation puissent nécessiter une certaine
attention s’ils sont migrés vers une version précédente.
Les systèmes de fichiers JFS2, à l’exception des clichés, sont compatibles avec AIX 5.1 et
AIX 5.2, mais pas avec les versions précédentes du système d’exploitation. Les systèmes
de fichiers JFS2 avec des clichés ne sont pas compatibles avec AIX 5.1. Veillez à toujours
démonter proprement tous les systèmes de fichiers JFS2 avant de revenir à une version
précédente de AIX car la commande logredo ne s’exécute pas nécessairement sur un
système de fichiers créé pour une version antérieure.
Remarque :
Les systèmes de fichiers JFS2 créés ou convertis au format v2 ne sont
pas accessibles sur les versions antérieures d’AIX
Les sections suivantes décrivent les éléments qui peuvent générer des problèmes avec les
systèmes de fichiers créés avec des versions précédentes du système d’exploitation.
Images de système de fichiers JFS
Toute image de système de fichiers JFS créée avec la taille de fragment par défaut, la
valeur NBPI 4 096 octets et la taille de groupe d’allocation par défaut (agsize) 8 peut être
interchangée avec une image de système de fichiers JFS créée sous AIX 4.3 et les versions
antérieures de ce système d’exploitation sans activités de migration spéciale.
Remarque : Clichés JFS2 :
Les clichés JFS2 créés ou auxquels vous accédez dans AIX 5.2 avec
5200–01 ne sont pas accessibles avec les versions antérieures. Ces
clichés doivent être supprimés pour pouvoir monter le système de fichiers.
Sauvegarde et restauration entre systèmes de fichiers Systèmes de fichiers
Les séquences de sauvegarde et de restauration peuvent être effectuées entre des
systèmes de fichiers ayant des tailles de blocs différentes. Toutefois, du fait de
l’augmentation de l’utilisation du disque, les restaurations peuvent échouer du fait d’un
manque de blocs libres si la taille de bloc du système de fichiers source est inférieure à
celle du système de fichiers cible. Cela est particulièrement intéressant pour la sauvegarde
et la restauration totale d’un système de fichiers et cette situation peut même se produire
lorsque la taille totale du système de fichiers cible est supérieure à celle du fichier source.
Bien que les sauvegardes et les restaurations puissent être effectuées depuis des systèmes
de fichiers compressés vers des systèmes de fichiers non compressés ou entre des
systèmes de fichiers compressés ayant des tailles de différentes, les restaurations peuvent
échouer du fait de l’utilisation étendue du disque des systèmes de fichiers compressés et
du manque d’espace disque. Cela est particulièrement intéressant pour la sauvegarde et la
restauration totale d’un système de fichiers et cette situation peut même se produire lorsque
la taille totale du système de fichiers cible est supérieure à celle du fichier source.
5-30
Concepts de gestion de système AIX – Système d’exploitation et unités
Limitations des pilotes d’unités JFS et JFS2
Un pilote d’unité doit fournir une adressibilité de bloc de disque égale ou inférieure à la taille
de fragment du système de fichiers JFS ou à la taille de bloc JFS2. Si, par exemple, un
système de fichiers JFS a été créé sur un pilote d’unité de disque RAM fourni par
l’utilisateur, le pilote doit permettre à des blocs de 512 octets de contenir un système de
fichiers qui avait des segments de 512 octets. Si le pilote ne fournit qu’une adressibilité au
niveau de la page, un système de fichiers JFS avec une taille de fragment de 4 096 octets
peut être utilisé uniquement.
Description de CDRFS
Un système de fichiers CDRFS est un système de fichiers local en lecture seule sous la
couche FLS (Logical File System). Il est stocké sur un support CD–ROM. Depuis la version
AIX 5.2, les CD sont montés automatiquement par défaut, mais cette fonction peut être
désactivée. Si la fonction est inactive, utilisez la commande cdmount pour monter le
système de fichiers CDRFS.
Pour AIX 5.1 et les versions supérieures, montez le CD–ROM et son système de fichiers
à l’aide de la commande mount et protégez le CD contre l’écriture. Par exemple :
mount –r –v cdrfs /dev/cd0 /mnt
Vous devez définir les éléments suivants lors du montage d’un CD–ROM
(AIX 5.1 et versions supérieures) :
Nom d’unité
Définit le nom de l’unité contenant le support.
Point de montage
Définit le répertoire de montage du système de fichiers.
Montage automatique
Indique si le système de fichiers sera monté automatiquement au
démarrage du système.
AIX prend en charge le volume CDRFS et les formats de structure suivants :
Type
Description
Norme ISO 9660:1988(E)
CDRFS prend en charge l’interchange ISO
9660 niveau 3 et la mise en œuvre
niveau 1.
High Sierra Group Specification
Précède la norme ISO 9660 et fournit une
compatibilité amont avec les CD–ROM
précédents.
Rock Ridge Group Protocol
Spécifie les extensions ISO 9660
totalement compatibles avec la norme ISO
9660 et qui fournissent une sémantique de
système de fichiers complète POSIX basée
sur SUSP (System Use Sharing Protocol) et
RRIP (Rock Ridge Interchange Protocol)
pour permettre le montage/l’accès
CD–ROM comme avec n’importe quel autre
système de fichiers UNIX.
Format de fichier CD–ROM eXtended
Architecture (format de secteur Mode 2
Form 1 uniquement)
Le format de fichier CD–ROM eXtended
Architecture (XA) spécifie les extensions de
la norme ISO 9660 qui sont utilisées dans
les applications multimédias CD–ROM
telles que Photo CD.
Systèmes de fichiers
5-31
Les restrictions suivantes s’appliquent à tous les formats de volumes et de structures de
fichiers :
• Groupe de volumes à un seul volume uniquement
• Pas de fichiers entrelacés uniquement
CDRFS dépend du pilote d’unité CD–ROM sous–jacent pour fournir la transparence du
format de secteur physiques (CD–ROM Mode 1 et CD–ROM XA Mode 2 Form 1) et le
format multisession des disques (mappage du groupe de descripteurs de volumes depuis
la zone de reconnaissance de volume de la dernière session).
Remarque :
CDRFS doit être démonté depuis le système pour pouvoir retirer le support
CD–ROM.
Description de UDFS
La version AIX 5.2 a introduit le type de système de fichiers UDFS qui est un système de
fichiers en lecture seule stocké sur un support DVD–ROM. UDFS doit être démonté depuis
le système pour pouvoir retirer le support CD–ROM. Le systèmes d’exploitation prend en
charge le format UDFS des versions 1.50, 2.00 et 2.01.
Pour utiliser la commande cdmount pour monter automatiquement un UDFS en
écriture/lecture; modifiez le fichier cdromd.conf. Vous pouvez également monter
manuellement un UDFS en lecture/écriture avec la commande mount.
5-32
Concepts de gestion de système AIX – Système d’exploitation et unités
Chapitre 6. Sauvegarde et restauration
Ce chapitre donne des informations relatives aux méthodes de sauvegarde
et de restauration des données.
Les sujets traités sont les suivants :
• Généralités sur la sauvegarde, page 6-2
• Développement d’une stratégie de sauvegarde, page 6-5
• Sauvegarde des systèmes de fichiers et fichiers utilisateur, page 6-8
• Sauvegarde de l’image système et des groupes de volumes définis par l’utilisateur,
page 6-9
Sauvegarde et restauration
6-1
Généralités sur la sauvegarde
La sauvegarde des systèmes de fichiers, des répertoires et des fichiers prend du temps
et implique de nombreuses tâches. D’autre part, tous les fichiers peuvent être modifiés ou
supprimés par inadvertance ou par accident. Lors de la défaillance d’un disque dur, les
informations stockées sur le disque sont perdues. La seule manière de restaurer les
données détruites consiste à les extraire de la copie de sauvegarde. Si vous sauvegardez
soigneusement et méthodiquement les systèmes de fichiers, vous pouvez toujours
restaurer aisément les dernières versions des fichiers et des systèmes de fichiers
Méthodes de sauvegarde
Il existe plusieurs méthodes de sauvegarde des données. La méthode la plus fréquente
s’appelle la sauvegarde par nom ou l’archivage par nom de fichier. Cette méthode de
sauvegarde est appliquée lorsque l’option i est définie et elle est utilisée pour créer une
copie de sauvegarde de fichiers et de répertoires individuels. Cette méthode est
communément utilisée par des utilisateurs individuels pour sauvegarder leurs comptes.
Une autre méthode fréquemment utilisée s’appelle la sauvegarde par i–node ou archive
de système de fichiers. Cette méthode est appliquée lorsque l’option i n’est pas définie.
Elle permet de sauvegarder une copie de l’ensemble d’un système de fichiers et elle est
communément utilisée par les administrateurs système pour sauvegarder des groupes
de fichiers volumineux, tels que tous les comptes utilisateurs, dans le répertoire /home.
Une sauvegarde de système de fichiers permet d’effectuer aisément des sauvegardes
incrémentielles. Une sauvegarde incrémentielle sauvegarde tous les fichiers modifiés
depuis la dernière sauvegarde.
Les commandes compress et pack permettent de compresser des fichiers à stocker
et les commandes uncompress et unpack permettent de décompresser les fichiers
stockés. La compression et la décompression des fichiers prennent du temps, mais une
fois compressées, les données occupent moins d’espace sur le support de stockage.
Plusieurs commandes permettent de créer des sauvegardes et des archives. Pour cette
raison, les données sauvegardées doivent porter une étiquette qui indique la commande
de sauvegarde utilisée et le type de la sauvegarde (par nom ou par système de fichiers).
6-2
sauvegarde
Sauvegardes des fichiers par nom ou par système de fichiers
mksysb
Crée une image installable du groupe de volumes rootvg.
cpio
Copie les fichiers vers ou depuis un stockage d’archives.
dd
Convertit et copie un fichier. Communément utilisée pour convertir
et copier des données entre des systèmes exécutant des systèmes
d’exploitation différents, tels que des mainframes. La commande
dd ne place pas plusieurs fichiers dans une archive ; elle permet
de manipuler et de déplacer des données.
tar
Crée ou manipule les archives de format tar.
rdump
Sauvegarde les fichiers par système de fichiers sur un périphérique
d’une machine distante.
pax
(Utilitaire d’archivage compatible POSIX) Lit et écrit des archives
tar et cpio.
Concepts de gestion de système AIX – Système d’exploitation et unités
Choix d’une politique de sauvegarde
Aucune stratégie de sauvegarde ne répond aux besoins de tous les utilisateurs. Une
stratégie adaptée à un système et un utilisateur, par exemple, peut ne pas être adaptée à
un système qui prend en charge cent utilisateurs. De même, une politique développée pour
un système dont nombre de fichiers sont modifiés chaque jour ne convient pas à un
système avec des données rarement modifiées. Quelle que soit la stratégie de sauvegarde
sur votre site, l’important est qu’elle existe et qu’elle soit appliquée fréquemment et
régulièrement. A défaut de stratégie efficace et opérationnelle, il peut s’avérer difficile de
restaurer des données perdues.
C’est vous qui ferez le choix de la politique à adopter. Voici toutefois quelques règles qui
vous guideront :
• Prévenir les pertes importantes de données
La poursuite de l’activité du système est-elle possible après la panne d’un disque dur,
quel qu’il soit ? La reprise du système est-elle possible si tous les disques fixes sont en
panne ? La reprise du système est-elle possible si vous égarez vos disquettes ou
bandes de sauvegarde ? Pour récupérer des données en cas de perte, pouvez-vous
mesurer les difficultés rencontrées ? Elaborez ensuite une politique de sauvegarde qui
prenne toutes ces questions en compte.
• Vérifier régulièrement les sauvegardes
Les supports et unités matérielles de sauvegarde ne sont pas toujours fiables. Une
bibliothèque volumineuse sur bandes ou disquettes de sauvegarde n’a de valeur que si
les données sont restituables et lisibles sur disque. Pour vérifier que vos sauvegardes
sont exploitables, affichez régulièrement la table des matières à partir de la bande de
sauvegarde (avec la commande restore –T ou tar –t pour les bandes d’archives). Pour
les sauvegardes sur disquettes, lisez régulièrement les disquettes, si possible à partir
d’une unité de disquette différente de celle utilisée pour la création des sauvegardes.
Pour plus de sécurité, vous pouvez doubler les sauvegardes de niveau 0 sur un
deuxième support. Sur les bandes en continu contenant des sauvegardes, appliquez
la commande tapechk qui vérifie sommairement la cohérence.
• Conserver les anciennes sauvegardes
Prévoyez des recyclages réguliers des supports de sauvegarde, sans toutefois les
réutiliser tous. L’absence ou l’endommagement d’un fichier important n’est pas toujours
détectée en temps réel. Il est donc conseillé de conserver quelques sauvegardes
anciennes. Les recyclages suivants des bandes ou disquettes de sauvegarde sont
indiqués à titre d’exemple :
– Une fois par semaine, recyclez les disquettes quotidiennes, excepté celle du vendredi.
– Une fois par mois, recyclez toutes les disquettes hebdomadaires, excepté la plus
récente ; les sauvegardes des quatre derniers vendredis sont ainsi toujours
disponibles.
– Tous les trimestres, recyclez les disquettes mensuelles, à l’exception de la dernière.
Conservez en permanence la dernière disquette mensuelle de chaque trimestre sur un
autre site.
• Vérifiez les systèmes de fichiers avant la sauvegarde
La sauvegarde d’un système de fichiers endommagés risque d’être inexploitable. Avant
de faire des sauvegardes, il est bon de vérifier l’intégrité du système de fichiers avec la
commande fsck.
• S’assurer que les fichiers ne sont pas en cours d’utilisation pendant la sauvegarde
Pendant les sauvegardes, le système ne doit pas être en cours d’utilisation. Sinon, les
fichiers sont susceptibles d’être modifiés auquel cas les sauvegardes seraient inexactes.
Sauvegarde et restauration
6-3
• Sauvegarder le système avant toute modification majeure
La sauvegarde complète du système est toujours conseillée avant tout test ou réparation
matérielle, avant l’installation d’une unité, d’un programme ou d’autres fonctions
système.
Remarque : La sauvegarde des tubes désignés (fichiers spéciaux FIFO) fonctionne, que
ceux–ci soient fermés ou ouverts. Toutefois, la restauration est impossible
lorsque la sauvegarde est faite sur des tubes ouverts. Lors de la restauration
d’un fichier spécial FIFO, son inode est le seul élément indispensable pour le
recréer car il contient toutes ses caractéristiques. Le contenu d’un tube
désigné n’est pas nécessaire à la restauration. C’est pourquoi, la taille du
fichier lors de la sauvegarde doit être zéro (tous les FIFO fermés) avant de
lancer cette procédure.
Attention : La sauvegarde et la restauration d’un système doivent être effectuées sur le
même type de plate-forme. Les cartes principales CPU et d’E/S notamment doivent être
de même type.
Description des supports de sauvegarde
Il existe divers types de supports de sauvegarde. Les types de supports de sauvegarde
disponibles pour votre système dépendent de votre logiciel et de votre matériel. Des
bandes, des disquettes, des archives distantes et des disques durs locaux sont
généralement utilisés. Si vous ne définissez pas une autre unité à l’aide de la commande
backup –f, la commande backup écrit automatiquement sa sortie sur /dev/rfd0, à savoir
le lecteur de disquette.
Attention : L’exécution de la commande backup provoque la perte de toutes les données
stockées sur le support de sortie sélectionné.
Restauration des données
Il existe plusieurs méthodes. Choisissez-en une compatible avec celle utilisée pour la
sauvegarde.
Vous devez connaître la méthode adoptée pour la sauvegarde ou l’archivage effectué.
Chaque procédure de sauvegarde fournit des informations sur la restauration des données.
Par exemple, si vous utilisez la commande backup, vous pouvez spécifier une sauvegarde
par système de fichiers ou par nom. Une sauvegarde effectuée par système de fichiers ou
par nom doit être restaurée de la même manière.
Voici les différentes commandes relatives à la restauration des données :
6-4
restore
Copie les fichiers créés par la commande backup.
rrestore
Copie les systèmes de fichiers sauvegardés sur une machine
distante vers la machine locale.
cpio
Copie les fichiers vers ou depuis un stockage d’archives.
tar
Crée ou manipule les archives tar.
pax
(Utilitaire d’archivage compatible POSIX) Lit et écrit des archives
tar et cpio.
Concepts de gestion de système AIX – Système d’exploitation et unités
Développement d’une stratégie de sauvegarde
Il existe deux méthodes de sauvegarde de grandes quantités de données :
• la sauvegarde intégrale du système,
• la sauvegarde incrémentale.
Pour choisir la méthode la plus adaptée à votre site ou à votre système, il est important
de bien appréhender la structure du système de fichiers et le placement des données.
La stratégie de placement des données doit être déterminée avant de développer une
stratégie de sauvegarde. Reportez–vous à la section ”Planification des sauvegardes” dans
le manuel AIX - Guide d’administration : système d’exploitation et unités pour un exemple
de stratégie combinant la sauvegarde intégrale, hebdomadaire et la sauvegarde
incrémentale quotidienne.
Structure du système de fichiers
Notez bien la différence entre un système de fichiers et un répertoire. Un système de
fichiers est une section du disque affectée aux données. L’accès à cette section se fait par
montage du système de fichiers sur un répertoire. Du point de vue utilisateur, ce système
de fichiers, une fois monté, ressemble à un répertoire. Toutefois, en raison des différences
structurelles entre les systèmes de fichiers et les répertoires, les données à l’intérieur de
ces deux entités peuvent être gérées séparément.
Lorsque le système d’exploitation est installé pour la première fois, il est chargé dans une
structure de répertoire, comme indiqué dans l’illustration de l’arborescence du système de
fichiers /root.
Figure 11. Arborescence de système de fichiers / (racine) Cette arborescence montre
une structure de répertoires avec le système de fichiers / (racine) et les ramifications vers
les répertoires et systèmes de fichiers. Les répertoires se ramifient à /bin, /dev, /etc et /lib.
Les systèmes de fichiers se ramifient à /usr, /tmp, /var et /home.
/(répertoire racine)
système de fichiers
systèmes de
fichiers
répertoires
/bin
/dev
/etc
/lib
/usr
/tmp
/var
/home
Les répertoires de droite (/usr, /tmp, /var et /home) sont tous des systèmes de fichiers,
affectés d’une section du disque. Ces systèmes de fichiers sont montés automatiquement à
l’amorçage du système ; c’est pourquoi l’utilisateur ne les différencie pas des répertoires de
gauche (/bin, /dev, /etc et /lib).
Sauvegarde et restauration
6-5
Données système et données utilisateur
Les données (programmes ou texte) sont réparties ici en deux catégories :
• Les données système, qui établissent la relation au système d’exploitation et à ses
extensions. Elles doivent toujours figurer dans les systèmes de fichiers système,
/ (racine), /usr, /tmp, /var, etc.
• Les données utilisateur, qui sont exploitées localement par les utilisateurs pour effectuer
des tâches spécifiques. Elles doivent être stockées dans le système de fichiers /home
ou dans des systèmes de fichiers créés à cet effet.
Les applications utilisateur et le texte ne doivent en aucun cas être placés dans des
systèmes de fichiers dédiés aux données système. Elles doivent placées plutôt, par
exemple, dans un système de fichiers créé par l’administrateur et monté sur un répertoire
nommé /local. /tmp, qui est utilisé pour le stockage temporaire des données systèmes et
utilisateur, constitue une exception.
Sauvegarde
Les sauvegardes de données système et utilisateur sont conservées en cas de destruction
accidentelle ou de défaillance d’un disque. Il est plus facile de gérer des sauvegardes
distinctes pour les données système et les données utilisateur. Les raisons sont les
suivantes :
• Les données utilisateur sont beaucoup plus souvent modifiées que les données du
système d’exploitation. En outre, les images de sauvegarde sont beaucoup plus petites
quand les deux types de données ne sont pas sur la même image. Par ailleurs, le
nombre d’utilisateurs affecte le support et la fréquence du stockage nécessaires.
• La restauration des données utilisateur est plus facile et plus rapide quand la sauvegarde
est séparée des données système. La restauration du système d’exploitation en même
temps que des données utilisateur prend plus de temps et demande plus d’efforts. En
effet, pour restaurer les données système, il faut amorcer le système à partir d’un support
amovible (bande ou CD-ROM) puis installer la sauvegarde système.
Pour sauvegarder les données système, démontez tous les systèmes de fichiers utilisateur,
y compris /home, à l’aide de la commande umount. Si ces systèmes de fichiers sont en
cours d’utilisation, vous ne pouvez pas les démonter. Planifiez les sauvegardes aux heures
creuses pour qu’ils puissent être démontés. Si vous ne démontez pas les systèmes de
fichiers des données utilisateur, ils sont sauvegardés avec les données du système
d’exploitation. Utilisez la commande mount pour ne monter que les systèmes de fichiers
du système d’exploitation.
Les seuls systèmes de fichiers montés sont /, /usr, /var et /tmp et la sortie de la commande
mount doit se présenter comme suit :
node
mounted
mounted over vfs
date
options
/dev/hd4
/
jfs
Jun 11 10:36
rw,log=/dev/hd8
/dev/hd2
/usr
jfs
Jun 11 10:36
rw,log=/dev/hd8
/dev/hd9var
/var
jfs
Jun 11 10:36
rw,log=/dev/hd8
/dev/hd
/tmp
jfs
Jun 11 10:36
rw,log=/dev/hd8
Une fois tous les systèmes de fichiers utilisateur démontés, reportez–vous à Backing Up the
System Image and User–Defined Volume Groups, pour plus de détails sur la sauvegarde
des données du système d’exploitation.
Quand la sauvegarde du système d’exploitation est terminée, montez le système de fichiers
utilisateur avec la commande smit mount. Vous pouvez ensuite sauvegarder fichiers,
systèmes de fichiers ou autres groupes de volumes, en fonction de vos besoins.
Les procédures correspondantes sont décrites plus loin dans ce chapitre.
6-6
Concepts de gestion de système AIX – Système d’exploitation et unités
Reproduction d’un système (clonage)
Le clonage permet de sauvegarder les données de configuration avec les données
utilisateur ou les données système. La reproduction d’un système ou d’un groupe de
volumes est parfois appelée clonage. L’image obtenue est installable sur un autre système
et donc exploitable comme sur le premier système. La commande mksysb sert au clonage
du groupe de volumes rootvg, qui contient le système d’exploitation tandis que la
commande savevg sert au clonage des autres groupes de volumes. Les procédures de
sauvegarde du système et des groupes de volumes utilisateur sont décrites plus loin dans
ce chapitre.
Sauvegarde et restauration
6-7
Sauvegarde des fichiers des utilisateurs
ou des Systèmes de fichiers
Pour sauvegarder les fichiers utilisateur et les systèmes de fichiers utilisateur, vous pouvez
utiliser Web–based System Manager, les raccourcis SMIT smit backfile, ou smit
backfilesys ou les commandes listées dans les Méthodes de sauvegarde, page 6-2.
Vous pouvez utiliser l’interface SMIT pour sauvegarder un seul fichier et des petits
systèmes de fichiers par nom, tel que /home, sur votre système local. Notez que SMIT ne
peut créer des archives que dans le format fourni par la commande backup. En outre, les
options de la commande backup ne sont pas toutes disponibles dans SMIT. SMIT peut se
bloquer si plusieurs bandes ou disques sont nécessaires au cours de la sauvegarde.
(Pour plus d’informations, reportez–vous à la description de la commande backup dans
le document AIX 5L Version 5.3 Commands Reference.)
Utilisez la commande backup pour sauvegarder des systèmes de fichiers volumineux.
Vous pouvez définir un numéro de niveau pour contrôler la quantité de données à
sauvegarder (sauvegarde complète, 0; sauvegarde incrémentielle, 1–9). Seule la
commande backup permet de définir le numéro de niveau des sauvegardes.
La commande backup crée des copies dans l’un des deux formats de sauvegarde
suivants :
• Fichiers spécifiques sauvegardés par nom à l’aide de l’option –i.
• Systèmes de fichiers entiers sauvegardés par i–node à l’aide des paramètres –Level
et FileSystem. Le système de fichiers est défragmenté lors de la restauration depuis
la sauvegarde.
Attention : La sauvegarde par i–node ne fonctionne pas correctement avec les fichiers
dont l’ID utilisateur (UID) ou l’ID de groupe (GID) est supérieur à 65 535. Ces fichiers sont
sauvegardés avec l’D tronqué et les attributs seront donc erronés lors de la restauration.
Dans ce cas, vous devez effectuer une sauvegarde par nom.
6-8
Concepts de gestion de système AIX – Système d’exploitation et unités
Sauvegarde de l’image système et des groupes
de volumes définis par l’utilisateur
Le groupe de volumes est stocké sur un disque dur ou un groupe de disques durs, et
contient les fichiers de démarrage, BOS, les informations de configuration et les produits
logiciels optionnels. Un groupe de volumes défini par l’utilisateur (appelé également groupe
de volumes nonrootvg) contient généralement des fichiers de données et des applications.
Vous pouvez sauvegarder une image du système et des groupes de volumes à l’aide de
WSM (Web–based System Manager), SMIT ou de procédures de commandes.
Le groupe de volumes rootvg est un disque ou un groupe de disques contenant les fichiers
de démarrage du système (BOS), les données de configuration et tout autre produit logiciel
en option. Un groupe de volumes utilisateur (ou groupe de volumes non rootvg) contient les
fichiers de données et les logiciels d’application.
Les procédures SMIT et Web-based System Manager font appel à la commande mksysb
pour créer une image de sauvegarde, stockée sur bande ou dans un fichier. Si vous optez
pour la bande, le programme de sauvegarde écrit une image d’amorçage sur la bande et
l’image obtenue pourra donc servir à l’installation.
Remarque :
1. Vous ne pouvez pas créer des bandes de démarrage ou en utiliser pour démarrer un
ordinateur personnel PowerPC.
2. Si vous optez pour SMIT, installez d’abord l’ensemble de fichiers sysbr dans le progiciel
bos.sysmgt. Reportez-vous à ”Installation de logiciels en option et de mises à jour de
service à l’aide de SMIT” dans AIX 5L Version 5.3 Guide d’Installation.
Configuration du système source
Configurez le système source avant de créer son image de sauvegarde. Faites-le, excepté
si cette image est destinée à l’installation d’autres systèmes (cible) dont les configurations
prévues sont différentes.
Le système source est celui à partir duquel vous créez la copie de sauvegarde. Le système
cible est celui sur lequel vous installez cette copie.
Le programme d’installation n’installe que le support logiciel d’unité correspondant à la
configuration matérielle de la machine. Aussi, si vous prévoyez d’utiliser une copie du
système pour installer d’autres machines, vous aurez probablement d’autres unités à
installer sur le système source avant d’en faire l’image de sauvegarde.
Utilisez Web-based System Manager ou le raccourci SMIT smit devinst pour installer un
support de périphérique supplémentaire sur le système source.
• Si les système source et cible disposent de suffisamment d’espace disque, installez
l’ensemble du support logiciel d’unité.
• Si l’espace disque est limité, n’installez que les supports indispensables.
Pour plus d’informations sur l’installation d’un logiciel optionnel, reportez–vous à la section
Installing Optional Software and Service Updates Using SMIT du document AIX 5L
Version 5.3 Installation Guide and Reference.
Sont transférées par la sauvegarde, du système source vers le système cible, les données
relatives :
• à l’espace de pagination,
• aux volumes logiques,
• Informations rootvg
• Emplacement des partitions logiques (si vous avez sélectionné l’option Map).
Sauvegarde et restauration
6-9
Pour plus d’informations sur la définition des paramètres d’installation lors de l’installation
de la machine cible depuis une sauvegarde système, reportez–vous à Customizing the
BOS Install Program dans le document AIX 5L Version 5.3 Installation Guide and
Reference.
Montage et démontage des systèmes de fichiers
La procédure ”Sauvegarde du système” est dédiée exclusivement à la sauvegarde des
systèmes de fichiers montés dans rootvg. De ce fait, vous devez monter avant la
sauvegarde tous les systèmes de fichiers que vous voulez inclure dans la sauvegarde.
A l’inverse, vous devez démonter tous ceux que vous ne souhaitez pas sauvegarder.
La procédure effectue une double sauvegarde des fichiers figurant dans un répertoire local
monté sur un autre répertoire local du même système de fichiers. Par exemple, si /tmp est
monté sur /usr/tmp, les fichiers de /tmp sont sauvegardés deux fois. Cette duplication peut
provoquer le dépassement du nombre de fichiers admis et, par conséquent, l’échec de la
future installation de l’image de sauvegarde.
Remarques sur la sécurité
Si vous installez une image de sauvegarde sur d’autres systèmes, pour des raisons de
sécurité, les mots de passe et les adresses de réseau ne doivent pas être copiés sur les
systèmes cible. Et ce d’autant que des adresses en double peuvent provoquer l’interruption
des communications sur le réseau.
Restauration d’une image de sauvegarde
Pendant l’installation de l’image de sauvegarde, le système vérifie si l’espace disque du
système cible est suffisant pour créer tous les volumes logiques stockés sur la sauvegarde.
Si cet espace est suffisant, la restauration complète de l’image est possible. Sinon, la
procédure s’arrête et le système vous invite à sélectionner des disques supplémentaires.
Les systèmes de fichiers créés sur le système cible ont la même taille que sur le système
source, sauf si la variable SHRINK était définie à oui dans le fichier image.data avant
l’exécution de la sauvegarde. Une exception cependant : le répertoire /tmp, qui peut être
agrandi pour réserver suffisamment d’espace à la commande bosboot. Pour plus
d’informations sur la définition des variables, reportez–vous au fichier image.data dans
le document AIX 5L Version 5.3 Files Reference.
Une fois que le système a terminé d’installer l’image de sauvegarde, le programme
d’installation reconfigure ODM sur le système cible. Si le système cible n’a pas exactement
la même configuration matérielle que le système source, le programme modifie des attributs
d’unités dans les fichiers suivants du système cible :
• Tous les fichiers qui commencent par ”Cu” dans /etc/objrepos.
• Tous les fichiers du répertoire /dev.
Pour plus d’informations sur l’installation (ou la restauration) d’une image de sauvegarde,
reportez–vous à la section Installing BOS from a System Backup dans le document AIX 5L
Version 5.3 Installation Guide and Reference.
6-10
Concepts de gestion de système AIX – Système d’exploitation et unités
Chapitre 7. Environnement système
A la base, l’environnement système est l’ensemble de variables qui définissent ou
contrôlent certains aspects de l’exécution des processus. Ces variables sont définies ou
redéfinies à chaque démarrage d’un shell. Du point de vue de l’administrateur système, il
est important de garantir des valeurs correctes pour la connexion de l’utilisateur. La plupart
de ces variables sont définies lors de l’initialisation du système, soit par défaut, soit en
fonction des valeurs lues dans le fichier /etc/profile.
Cette section traite des points suivants :
• Présentation des profiles, page 7-2
• Liste des services de manipulation des données temporelles, page 7-3
• Désallocation dynamique de processeur, page 7-4
Environnement système
7-1
Profils - généralités
Lors de la connexion au système d’exploitation, le shell utilise deux types de fichiers de
profils. Il analyse les commandes figurant dans ces fichiers puis les exécute pour définir
votre environnement système. Ces fichiers ont des fonctions similaires à ceci près que
/etc/profile contrôle les variables de profil concernant l’ensemble des utilisateurs du
système tandis que .profile permet de personnaliser votre propre environnement.
Ce chapitre traite des points suivants :
• Fichier /etc/profile,
• Fichier .profile,
• Modification de la date/heure système dans le manuel ,
• Modification du message du jour dans le manuel,
• Liste des services de manipulation des données temporelles, page 7-3.
Fichier /etc/profile
/etc/profile est le premier fichier qu’utilise le système d’exploitation au moment de la
connexion. Il contrôle les variables par défaut à l’échelle du système, telles que :
• les variables d’exportation,
• le masque de création de fichier (umask),
• les types de terminaux,
• les messages signalant l’arrivée du courrier.
L’administrateur système configure le fichier profile pour tous les utilisateurs du système.
Il est le seul à pouvoir modifier ce fichier.
fichier .profile
.profile est le deuxième fichier qu’utilise le système d’exploitation au moment de la
connexion. Ce fichier est présent dans votre répertoire personnel ($HOME) ; il vous permet
de personnaliser votre environnement de travail. Les commandes de .profile ont la priorité
sur celles de /etc/profile. Etant donné que le fichier .profile est caché, utilisez la
commande ls–a pour le répertorier. Utilisez le fichier .profile pour contrôler les défauts
suivants :
• les shells à ouvrir,
• l’apparence de l’invite,
• les variables d’environnement (par exemple, les variables de chemin d’accès),
• le son du clavier.
L’exemple suivant illustre un fichier .profil courant :
PATH=/usr/bin:/etc:/home/bin1:/usr/lpp/tps4.0/user:/home/gsc/bin::
epath=/home/gsc/e3:
export PATH epath
csh
Dans cet exemple, deux chemins (PATH et epath) sont définis, puis exportés, et un shell C
(csh) est ouvert.
Le fichier .profile (ou, à défaut, le fichier profile) sert aussi à déterminer les variables shell
de connexion. En outre, vous pouvez personnaliser les autres environnements shell. Par
exemple, utilisez les fichiers .chsrc et .kshrc pour personnaliser un shell C et un shell Korn
au démarrage de ces deux shells.
7-2
Concepts de gestion de système AIX – Système d’exploitation et unités
Services de manipulation des données sur l’heure
Les fonctions de date/heure servent à accéder à la date et l’heure courantes du système
et à modifier leur format. Aucun indicateur n’est à spécifier au compilateur pour exploiter
ces fonctions.
Ajoutez le fichier d’en–tête de ces fonctions dans le programme. Pour inclure un fichier
d’en–tête, procédez comme suit :
#include <time.h>
Voici la liste des services de date/heure :
adjtime
ajuste l’heure pour synchroniser l’horloge système.
ctime, localtime, gmtime, mktime, difftime, asctime, tzset
convertit la date et l’heure selon la représentation de la chaîne.
getinterval, incinterval, absinterval, resinc, resabs, alarm, ualarm, getitimer,
setitimer
gère l’heure d’expiration de plusieurs horloges.
gettimer, settimer, restimer, stime, time
recherche ou définit la valeur courante de l’horloge spécifiée
à l’échelle du système.
gettimerid
affecte une horloge par processus.
gettimeofday, settimeofday, ftime
recherche et définit la date et l’heure.
nsleep, usleep, sleep
met un processus en veille.
reltimerid
libère une horloge affectée.
Environnement système
7-3
Désallocation dynamique de processeur
Depuis l’existence de la machine de type 7044, modèle 270, le matériel de tous les
systèmes dotés de deux processeurs ou plus peut détecter les erreurs de connexion
collectées par le microcode. Ces erreurs ne sont pas irrémédiables, tant qu’elles ne sont
pas récurrentes, et peuvent être ignorées. Toutefois, lorsqu’un type d’échec semble se
développer sur un processeur, le type d’incident peut indiquer que le composant est sur le
point de connaître une erreur irrémédiable. Cette prévision est effectuée par le microcode
en fonction du taux d’échec et de l’analyse des seuils.
Sur ces systèmes, AIX surveille en continu le matériel et appelle régulièrement le microcode
pour identifier les erreurs matérielles. Lorsque le nombre d’erreurs de processeur atteint un
seuil et que le microcode détermine que le composant système va vraisemblablement
connaître une défaillance, le microcode envoie un rapport d’erreur. Dans tous les cas,
l’erreur est consignée dans le journal des erreurs du système. En outre, sur les systèmes
à plusieurs processeurs, selon le type d’échec, AIX tente d’arrêter en utilisant le processeur
non fiable et le désalloue. Cette fonction s’appelle la désallocation dynamique de
processeur.
A ce stade, le processeur est également marqué par le microcode pour indiquer qu’il est
désalloué en permanence pour les réamorçages suivants jusqu’à ce que le personnel de
maintenance le remplace.
Impact potentiel sur les applications
La désallocation de processeur est transparente pour la très grande majorité des
applications, y compris pour les pilotes et les extensions du noyau. Toutefois, vous pouvez
utiliser les interfaces publiées pour déterminer si une application ou une extension du noyau
est exécutée sur une machine à plusieurs processeurs, identifier le nombre de processeurs
et lier les threads à des processeurs spécifiques.
L’interface bindprocessor de liaison des processus ou des threads aux processeurs utilise
des numéros de liaison UC. Ces numéro sont compris entre [0.. N –1] où N correspond au
nombre total d’UC. Pour éviter de rompre les applications ou les extensions de noyau qui
n’acceptent pas de ”trous” dans la numérotation des UC, AIX fait apparaître l’UC aux
applications comme s’il s’agissait de la ”dernière” UC liée (celle qui porte le numéro le
numéro plus grand) à désallouer. Par exemple sur un SMP à 8 voies, les numéros d’UC
liées sont [0..7]. Si un processeur est désalloué, le nombre total d’UC disponibles devient 7
et elles sont numérotées [0..6]. En externe, il semble que l’UC 7 ait disparue, quel que soit
le processeur physique qui connaît une défaillance.
Remarque :
Dans le reste de cette description, le terme UC désigne l’entité logique et le
terme processeur désigne l’entité physique.
Potentiellement, les applications ou les extensions de noyau qui sont des processus de
liaison ou des threads peuvent être rompues si AIX termine silencieusement leurs threads
de liaison ou force leur transfert vers une autre UC lorsque des processeurs doivent être
désalloués. La désallocation dynamique de processeur fournit des interface de
programmation pour que les applications et les extensions de noyau puissent savoir qu’une
désallocation de processeur va se produire. Lorsque les applications et les extensions de
noyau sont averties, elles doivent transférer leurs threads liées et les ressources associées
(tels que les blocs de demande de synchronisation) depuis le dernier ID d’UC liée et
s’adapter à la nouvelle configuration d’UC.
Après la notification, si des threads restent liées au dernier ID d’UC liée, la désallocation
est abandonnée, la désallocation abonnée est consignée dans le journal des erreurs et AIX
continue en utilisant le processeur défaillant. Lorsque le processeur tombe en panne, il
provoque une erreur générale du système. En conséquence, il important que les
applications et les extensions de noyau soient informées de l’imminence de la désallocation
d’un processeur et puissent réagir de manière appropriée.
7-4
Concepts de gestion de système AIX – Système d’exploitation et unités
Même dans les cas rares où la désallocation n’aboutit pas, la désallocation dynamique de
processeur avertit toujours à l’avance les administrateurs système. En enregistrant l’erreur
dans le journal des erreurs, ils ont la possibilité de planifier une opération de maintenance
sur le système pour remplacer le composant défaillant avant qu’une erreur générale du
système se produise.
Désallocation de processeur
Le flux type d’événements pour la désallocation de processeur est le suivant :
1. Le microcode détecte qu’un processeur a atteint un seuil d’erreur irrémédiable.
2. Le rapport d’erreur du microcode est consigné dans le journal des erreurs du système
et, lorsque AIX est exécuté sur une machine qui prend en charge la désallocation de
processeur, il lance la désallocation.
3. AIX signale les processus non–noyau et les threads liées à la dernière UC liée.
4. AIX attend jusqu’à 10 minutes que toutes les threads liées soit transférées depuis
la dernière UC liée. Si des threads restent liées, AIX abandonne la désallocation.
5. Si tous les processeurs ou threads ne sont plus liés au processeur défaillant, les
descripteurs HAEH (High Availability Event Handlers) déjà enregistrés sont appelés.
Un HAEH peut retourner une erreur qui fait échouer la désallocation.
6. Si elle n’est pas abandonnée, le processus de désallocation arrête le processeur
défaillant.
En cas d’échec au cours de la désallocation, l’échec et sa cause sont consignés.
L’administrateur système peut consulter le journal des erreurs, exécuter les actions
appropriées (si possible) et relancer la désallocation. Par exemple, si la désallocation a été
abandonnée parce qu’une application n’a pas pu délier ses threads liées, l’administrateur
système peut arrêter l’application, relancer la désallocation, puis redémarrer l’application.
Activation et désactivation de la désallocation de processeur
La désallocation dynamique de processeur peut être activée ou désactivée en changeant
la valeur de l’attribut cpuguard de l’objet ODM sys0. Les valeurs possibles de l’attribut sont
enable et disable.
Depuis la version AIX 5.2, la valeur par défaut est enabled (l’attribut cpuguard est affecté
de la valeur enable). Les administrateurs système qui veulent désactiver cette fonction
doivent utiliser les menus système Web-based System Manager, le menu SMIT System
Environments ou la commande chdev. Dans les versions précédentes de AIX, la valeur
par défaut était disabled.)
Remarque :
Les erreurs sont toujours consignées, même lorsque la désallocation de
processeur est désactivée. Le journal des erreurs contient une erreur telle
que CPU_FAILURE_PREDICTED qui indique que AIX a été averti d’un
problème d’UC.
Relance d’une désallocation de processeur abandonnée
Parfois, la désallocation de processeur échoue parce qu’une application n’a pas transféré
ses threads liées depuis la dernière UC logique. Une fois ce problème résolu, par la
suppression de liaison (lorsque cette opération est sûre) ou par l’arrêt de l’application,
l’administrateur système peut redémarrer la désallocation, de processus avec la commande
ha_star.
La syntaxe de la commande est la suivante :
ha_star –C
où –C correspond à l’événement de défaillance UC prévisible.
Environnement système
7-5
Considérations relatives à l’état du processeur
Les processeurs physiques sont représentés dans la base de données ODM par des objets
proc n où n est un nombre décimal qui correspond au numéro du processeur physique.
A l’instar des autres unités représentées dans la base de données ODM, les objets
processeur ont un état, tel que Défini/Disponible, et des attributs.
L’état d’un objet proc est toujours Disponible tant que le processeur est présent, qu’il soit
ou non utilisable. L’attribut state d’un objet proc indique si un processeur est utilisé, et s’il
ne l’est pas, il en indique la raison. Cet attribut peut avoir trois valeurs :
enable
Le processeur est utilisé.
disable
Le processeur a été désalloué dynamiquement.
faulty
Le processeur est déclaré défaillant par le microcode au démarrage.
Si un processeur défaillant est désalloué, son état passe de enable à disable.
Indépendamment de AIX, le processeur est marqué comme défaillant dans le microcode.
Lors de l’amorçage, le processeur désalloué n’est pas disponible et il a l’état faulty. L’objet
ODM proc, toutefois, est toujours disponible. Vous devez généralement retirer l’UC
défaillante de la carte système ou retirer la carte UC (si possible) de l’objet proc pour définir
l’état Défini.
Exemple
Dans le scénario suivant, le processeur proc4 fonctionne correctement et il est utilisé par le
système d’exploitation, comme l’indique la sortie suivante :
# lsattr –EH –l
proc4
attribute
value
state
type
#
description
user_settable
enable
Processor state
PowerPC_RS64–III
Processor type
False
False
Lorsque le processeur proc4 reçoit un échec prévisible, il est désalloué par le système
d’exploitation, comme indiqué ci–dessous :
# lsattr –EH –l
proc4
attribute
value
state
type
#
description
user_settable
disable
Processor state
PowerPC_RS64–III
Processor type
False
False
Lors du redémarrage, le microcode signale que le processeur proc4 est défaillant, comme
indiqué ci–dessous :
# lsattr –EH –l
proc4
attribute
value
state
type
#
description
user_settable
faulty
Processor state
PowerPC_RS64–III
Processor type
False
False
Mais l’état du processeur proc4 est toujours Disponible, comme indiqué ci–dessous :
# lsdev –CH –l
proc4
name
status
proc4
#
7-6
Available
location
description
00–04
Processor
Concepts de gestion de système AIX – Système d’exploitation et unités
Entrées du journal des erreurs
Trois messages d’erreurs sont associés à la désallocation d’UC dans le journal des erreurs.
Exemples :
Format court errpt, résumé
Voici un exemple d’entrées affichées par la commande errpt (sans options) :
# errpt
IDENTIFIER
804E987A
8470267F
ABORTED
1B963892
PREDICTED
#
TIMESTAMP
1008161399
1008161299
T
I
T
C
O
S
RESOURCE_NAME
proc4
proc4
DESCRIPTION
CPU DEALLOCATED
CPU DEALLOCATION
1008160299
P
H
proc4
CPU FAILURE
. Si la désallocation de processeur est active, le message CPU FAILURE
PREDICTED est toujours suivi du message CPU DEALLOCATED ou du message
CPU DEALLOCATION ABORTED.
. Si la désallocation de processeur n’est pas active, seul le message CPU FAILURE
PREDICTED est présent. L’activation de la désallocation de processeur, après
qu’un ou plusieurs messages CPU FAILURE PREDICTED ont été consignés,
démarre le processus de désallocation et génère une entrée de succès ou d’échec
dans le journal des erreurs, comme indiqué ci–dessus, pour chaque processeur
signalé défaillant.
Format long errpt, résumé
Voici la forme des sorties obtenues par la commande errpt –a :
. CPU_FAIL_PREDICTED
Error description: Predictive Processor Failure
Cette erreur indique que le matériel a détecté qu’un processeur va
vraisemblablement connaître une défaillance très bientôt. Elle est toujours
consignée, que la désallocation de processeur soit active ou non.
DETAIL DATA: Physical processor number, location
Environnement système
7-7
Exemple : entrée du journal des erreurs – forme longue
LABEL:
IDENTIFIER:
CPU_FAIL_PREDICTED
1655419A
Date/Time:
Sequence Number:
Machine Id:
Node Id:
Class:
Type:
Resource Name:
Resource Class:
Resource Type:
Location:
Thu Sep 30 13:42:11
53
00002F0E4C00
auntbea
H
PEND
proc25
processor
proc_rspc
00–25
Description
CPU FAILURE PREDICTED
Probable Causes
CPU FAILURE
Failure Causes
CPU FAILURE
Recommended Actions
ENSURE CPU GARD MODE IS ENABLED
RUN SYSTEM DIAGNOSTICS.
1100
0000
0000
0000
Detail Data
PROBLEM DATA
0144
1000
1999
0930
0000
0000
0000
0000
4942
4D00
2E31
2D50
0002
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
...
...
0000
4019
0000
0000
5531
312D
0000
0000
0000
0000
0000
0000
...
003A
8E00
9100
1842
0000
0000
0000
0000
0000
0000
4332
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
...
0000
...
. CPU_DEALLOC_SUCCESS
Description de l’erreur : Un processeur a été désalloué après la détection d’un
échec de processeur prévisible. Ce message est consigné lorsque la désactivation
de processeur est active et que l’UC a été désallouée.
DETAIL DATA: Logical CPU number of deallocated processor.
7-8
Concepts de gestion de système AIX – Système d’exploitation et unités
Exemple : entrée du journal des erreurs – forme longue :
LABEL:
IDENTIFIER:
CPU_DEALLOC_SUCCESS
804E987A
Date/Time:
Sequence Number:
Machine Id:
Node Id:
Class:
Type:
Resource Name:
Thu Sep 30 13:44:13
63
00002F0E4C00
auntbea
O
INFO
proc24
Description
CPU DEALLOCATED
Recommended Actions
MAINTENANCE IS REQUIRED BECAUSE OF CPU FAILURE
Detail Data
LOGICAL DEALLOCATED CPU NUMBER
0
Dans cet exemple, proc24 a été désalloué et correspondait à l’UC logique 0 lors
de la défaillance.
. CPU_DEALLOC_FAIL
Description de l’erreur : La désallocation d’un processeur, à la suite d’un échec
de processeur prévisible, n’a pas abouti. Ce message est consigné lorsque la
désactivation de processeur est active et que l’UC a été désallouée.
DETAIL DATA: Code d’erreur, numéro d’UC logique, informations
complémentaires en fonction du type d’échec.
Le code d’erreur est une valeur numérique hexadécimale. Les codes d’erreur
possibles sont :
2
Un(e) ou plusieurs processus/threads sont toujours lié(e)s à la
dernière UC logique. Dans ce cas, les données détaillées indiquent
les PID des processus concernés.
3
Un pilote ou une extension de noyau enregistrée ont renvoyé un
code d’erreur lorsqu’ils ont été notifiés. Dans ce cas, le champ des
données détaillées contient le nom du pilote ou de l’extension de
noyau concerné (en ASCII).
4
En désallouant un processeur, la machine a moins de deux UC
disponibles. Ce système d’exploitation ne désalloue pas plus de
N –2 processeurs sur une machine N voies pour éviter de perturber
les applications ou les extensions de noyau qui utilisent le nombre
total de processeurs disponibles pour déterminer s’ils fonctionnent
sur un système à un seul processus sur lequel il est possible de ne
pas utiliser les verrous multiprocesseur ou un processeur SMP
(Symmetric Multi Processor).
200 (0xC8)
La désallocation de processeur est désactivée (l’attribut ODM
cpuguard a la valeur disable). Cette erreur n’apparaît généralement
pas lorsque vous ne démarrez pas ha_star manuellement.
Environnement système
7-9
Exemples : entrée du journal des erreurs – forme longue :
Exemple 1 :
LABEL:
IDENTIFIER:
Date/Time:
Sequence Number:
Machine Id:
Node Id:
Class:
Type:
Resource Name:
CPU_DEALLOC_ABORTED
8470267F
Thu Sep 30 13:41:10
50
00002F0E4C00
auntbea
S
TEMP
proc26
Description
CPU DEALLOCATION ABORTED
Probable Causes
SOFTWARE PROGRAM
Failure Causes
SOFTWARE PROGRAM
Recommended Actions
MAINTENANCE IS REQUIRED BECAUSE OF CPU FAILURE
SEE USER DOCUMENTATION FOR CPU GARD
Detail Data
DEALLOCATION ABORTED CAUSE
0000 0003
DEALLOCATION ABORTED DATA
6676 6861 6568 3200
Dans cet exemple, la désallocation de proc26 a échoué. Le code d’erreur 3
indique qu’une extension de noyau a retourné une erreur à la routine de
notification du noyau. DEALLOCATION ABORTED DATA ci–dessus indique
fvhaeh2 qui correspond au nom de l’extension utilisée pour l’enregistrement avec
le noyau.
Exemple 2 :
LABEL:
CPU_DEALLOC_ABORTED
IDENTIFIER:
8470267F
Date/Time:
Thu Sep 30 14:00:22
Sequence Number:
71
Machine Id:
00002F0E4C00
Node Id:
auntbea
Class:
S
Type:
TEMP
Resource Name:
proc19
Description
CPU DEALLOCATION ABORTED
Probable Causes
SOFTWARE PROGRAM
Failure Causes
SOFTWARE PROGRAM
Recommended Actions
MAINTENANCE IS REQUIRED BECAUSE OF CPU FAILURE
SEE USER DOCUMENTATION FOR CPU GARD
Detail Data
DEALLOCATION ABORTED CAUSE
0000 0002
DEALLOCATION ABORTED CAUSE
0000 0000 0000
4F4A
7-10
Concepts de gestion de système AIX – Système d’exploitation et unités
Dans cet exemple, la désallocation de proc19 a échoué. Le code d’erreur 2
indique que des threads sont liées au dernier processeur logique et qu’elles n’ont
pas été déliées après avoir reçu le signal SIGCPUFAIL. DEALLOCATION
ABORTED DATA indique ces threads appartenaient au processus 0x4F4A.
Les options de la commande ps ( –o THREAD, –o BND) permettent de lister tous
les threads et processus avec le numéro de l’UC à laquelle ils sont liés, le cas
échéant.
Exemple 3 :
LABEL:
IDENTIFIER:
CPU_DEALLOC_ABORTED
8470267F
Date/Time:
Thu Sep 30 14:37:34
Sequence Number:
106
Machine Id:
00002F0E4C00
Node Id:
auntbea
Class:
S
Type:
TEMP
Resource Name:
proc2
Description
CPU DEALLOCATION ABORTED
Probable Causes
SOFTWARE PROGRAM
Failure Causes
SOFTWARE PROGRAM
Recommended Actions
MAINTENANCE IS REQUIRED BECAUSE OF CPU FAILURE
SEE USER DOCUMENTATION FOR CPU GARD
Detail Data
DEALLOCATION ABORTED CAUSE
0000 0004
DEALLOCATION ABORTED CAUSE
0000 0000 0000 0000
Dans cet exemple, la désallocation de proc2 a échoué parce qu’il existait au
moins deux processeurs actifs au moment de l’incident (code d’erreur 4).
Environnement système
7-11
7-12
Concepts de gestion de système AIX – Système d’exploitation et unités
Chapitre 8. Gestion des processus
Le processus est l’entité que le système d’exploitation utilise pour contrôler l’utilisation des
ressources système. Les threads peuvent contrôler le temps processeur, mais la plupart
des outils de gestion de système impose toujours de faire référence au processus dans
lequel la thread est exécutée et non à la thread elle–même.
Reportez–vous au document AIX 5L Version 5.3 System Management Guide: Operating
System and Devices pour obtenir des informations générales sur la gestion de vos propres
processus, tels que redémarrer ou arrêter un processus que vous avez démarré, ou
planifier un processus pour plus tard.
Pour plus d’informations sur les instructions associées aux tâches, reportez–vous à la
section Monitoring and Managing Processes du document AIX 5L Version 5.3 System
Management Guide: Operating System and Devices.
Des outils sont disponibles, qui permettent de :
• Surveiller la création, l’annulation, l’identité des processus, et leur consommation de
ressources par le biais de :
– ps qui rend compte des ID processus, des utilisateurs, de la consommation du temps
CPU et d’autres attributs.
– who –u qui rend compte de l’ID processus shell des utilisateurs connectés.
– svmon qui rend compte de la consommation par le processus de la mémoire réelle.
Pour en savoir plus sur cette commande, reportez-vous à Performance Toolbo 2 and 3
for AIX: User’s Guide.
– Le mécanisme de commande acct écrit des enregistrements lors de l’arrêt des
processus pour résumer les ressources de processus utilisées. (Consultez des
informations sur la configuration d’un système de comptabilité dans Généralités sur
la comptabilité, page 11-2.)
• Contrôler le niveau de priorité auquel prétend le processus pour le CPU par le biais de :
– nice qui lance une commande spécifiant la priorité d’un processus. Reportez-vous à
AIX 5L Version 5.3 - Guide de l’utilisateur : système d’exploitation et unités.
– renice qui change la priorité d’un processus donné.
• Mettre fin aux processus incontrôlables par le biais de :
– kill qui adresse un signal au(x) processus concerné(s).
Gestion des processus
8-1
8-2
Concepts de gestion de système AIX – Système d’exploitation et unités
Chapitre 9. Gestion de la charge de travail
WLM (Workload Manager) permet à l’administrateur système d’exercer un plus grand
contrôle sur l’allocation des ressources aux processus par VMM (Virtual Memory Manager)
et le sous–système E/S de disque. Vous pouvez utiliser WLM pour empêcher les classes de
travail d’entrer mutuellement en conflit et allouer des ressources en fonction des besoins
des groupes d’utilisateurs.
Attention : Pour utiliser efficacement WLM, vous devez bien connaître les processus
système et les performances. Si l’administrateur système configure WLM avec des valeurs
extrêmes ou inexactes, les performances en seront affectées.
WLM est principalement destiné à une utilisation avec des systèmes importants. Ces
systèmes sont souvent utilisés pour la consolidation des serveurs, dont les charges de
travail de nombreux systèmes de serveurs différents (tels qu’une imprimante, une base de
données, un utilisateur général, et des systèmes de traitement de transactions) sont
associées en un grand système unique pour réduire le coût de maintenance du système.
Ces charges de travail interfèrent souvent entre elles et on des buts et accords de service
différents.
Workload Management permet également de séparer les utilisateurs en fonction de
l’utilisation qu’ils font du système. Ceci permet d’empêcher les fortes charges de travail
(travaux en mode batch ou demandant beaucoup de mémoire, par exemple) de priver les
faibles charges (par exemple, travaux nécessitant peu de temps CPU ou en mode
interactif).
WLM s’intègre également au sous–système de comptabilité (reportez–vous à la section
Comptabilité – généralités, page 11-2) qui permet aux utilisateurs d’effectuer une
comptabilité d’usage de ressource par classe WLM en plus de la comptabilité standard
par utilisateur ou par groupe.
Gestion de la charge de travail
9-1
Concepts et généralités sur WLM
WLM offre la possibilité de créer différentes classes de services pour les travaux, et de
définir des attributs pour ces classes. Lesdits attributs fixent les quantités minimale et
maximale de CPU, de mémoire physique et de débit d’E/S disque affectés à ces classes.
WLM ordonne ensuite automatiquement les travaux dans des classes, en fonction de règles
d’affectation fournies par l’administrateur système. Ces règles d’affectation reposent sur les
valeurs d’un ensemble d’attributs d’un process. L’administrateur système ou un utilisateur
privilégié peut également affecter des travaux à des classes, choix qui prévaut sur
l’affectation automatique.
Définitions
classe
Ensemble de process et des routines associées,
possédant un ensemble unique de valeurs de limitation
de ressources et auxquels sont appliqués des partages
cibles. Le terme classe désigne à la fois les
sous–classes et les superclasses.
superclasse
Une superclasse est une classe à laquelle sont associées
des sous–classes. Aucun process ne peut appartenir à
une superclasse sans également appartenir à une
sous–classe. Une superclasse possède un jeu de règles
d’affectation de classe qui déterminent quels process lui
seront affectés. Elle possède également un jeu de
valeurs de limitation de ressources et de partages cibles
de ressources qui déterminent la quantité de ressources
susceptibles d’être utilisées par les process lui
appartenant. Ces ressources sont réparties entre les
sous–classes en fonction de leurs valeurs de limitation
de ressource et de leurs partages cibles de ressources.
sous–classe
Une sous–classe est une classe associée à une seule et
unique superclasse. Chaque process d’une sous–classe
est également membre d’une superclasse. Les
sous–classes n’ont accès qu’aux ressources mises à la
disposition de la superclasse. Une sous–classe possède
un ensemble de règles d’affectation de classe qui
déterminent quels process affectés à la superclasse lui
appartiennent. Elle possède également un jeu de valeurs
de limitation de ressources et de partages cibles de
ressources qui déterminent les ressources susceptibles
d’être utilisées par les process lui appartenant.
Ces valeurs de limitation de ressources et partages cibles
de ressources indiquent quelle proportion des ressources
dont dispose la superclasse (cible de la superclasse)
peuvent être exploitées par les process de la
sous–classe.
L’administration de WLM peut être assurée à l’aide de
l’outil de type Web Web-based System Manager, de SMIT
ou de l’interface à ligne de commande de WLM.
mécanisme de classification
9-2
Un mécanisme de classification est un ensemble de
règles d’affectation de classe qui détermine les process
qui sont affectés aux différentes classes (superclasses ou
sous–classes au sein de superclasses).
Concepts de gestion de système AIX – Système d’exploitation et unités
règle d’affectation de classe
Une règle d’affectation de classe indique quelles valeurs
d’un ensemble d’attributs d’un process entraîneront son
affectation à une classe particulière (superclasse ou
sous–classe d’une superclasse).
valeur d’attribut de process
La valeur d’attribut d’un process est la valeur que prend
un de ses attributs. Ces attributs sont par exemple :
ID utilisateur, ID de groupe et chemin d’accès de
l’application.
valeurs de limitation de
ressources
Les valeurs de limitation de ressources sont les séries de
valeurs que Workload Manager doit tenter de préserver
pour un ensemble de valeurs d’utilisation de ressources.
Ces limites sont totalement indépendantes des limites
de ressources spécifiées avec setrlimit().
partage cible de ressource
Les partages cibles de ressources sont les partages
d’une ressource qui doivent être à disposition d’une
classe (sous–classe ou superclasse). Ces partages sont
utilisés avec d’autres partages de classe (sous–classe ou
superclasse) au même niveau pour déterminer la
répartition des ressources souhaitée entre les classes de
ce niveau.
valeur d’utilisation de
ressource
Une valeur d’utilisation de ressource est la quantité d’une
ressource qu’un process ou ensemble de process utilise
actuellement dans un système. Le fait qu’il s’agisse d’un
process ou d’un ensemble de process est déterminé par
la portée de la collecte de ressource de process.
portée de la collecte de
ressource
La portée de la collecte de ressource est le niveau auquel
l’utilisation des ressources est collectée et le niveau
auquel les valeurs de limitation de ressource sont
appliquées. Cela peut intervenir au niveau de chaque
process d’une classe, au niveau de la somme des
process d’une classe détenus par chaque utilisateur, ou
au niveau de la somme des process d’une classe. La
seule portée actuellement prise en charge est la dernière.
propriétés des classes de
process
Ce sont les ensembles de propriétés attribuées à un
process en fonction des classes (sous–classes ou
superclasses) auxquelles il est affecté.
Gestion de la charge de travail
9-3
autorisations de classe
Les autorisations de classe sont les ensembles de règles
qui indiquent quels utilisateurs et groupes sont autorisés
à effectuer des opérations sur une classe ou sur les
process et les routines d’une classe. Cela comprend
l’autorisation d’affecter manuellement les process à une
classe ou de créer des sous–classes d’une superclasse.
rang de classe
La valeur de rang d’une classe est sa position dans la
hiérarchie de limitation de ressources souhaitée pour
toutes les classes. Les limites de ressources (y compris
les cibles de ressources) pour toutes les classes d’un
rang doivent être satisfaites avant qu’une ressource
quelconque soit fournie aux classes de rang inférieur.
Les rangs sont définis au niveau des superclasses et
des sous–classes. Les ressources sont fournies aux
superclasses en fonction de leur rang. Au sein d’une
superclasse, les ressources sont attribuées aux
sous–classes en fonction de leurs valeurs de rang dans
la superclasse. De ce fait, le rang de superclasse est
l’élément de différentiation principal dans la répartition
des ressources, le rang de sous–classe offrant un autre
élément de différentiation inférieur au sein d’une
superclasse.
Classes
WLM permet aux administrateurs système de définir des classes et, pour chaque classe,
un ensemble d’attributs et de limites de ressources. Les process sont affectés aux classes
en fonction de critères fournis par l’administrateur système. Les droits à ressources et les
limites sont appliqués au niveau de la classe. Cette solution permet de définir des classes
de service et de réguler l’utilisation des ressources de chaque classe d’application, afin
d’éviter que des applications ayant des modèles d’utilisation des ressources très différents
n’interfèrent les unes avec les autres lorsqu’elles partagent un seul serveur.
WLM prend en charge une hiérarchie de classes à deux niveaux :
• Les ressources du système sont réparties entre les superclasses en fonction des droits
à ressource de chacune d’elles. Ces droits à ressources sont définis par l’administrateur
système.
• Chaque superclasse peut à son tour avoir des sous–classes. Les ressources affectées
aux superclasses sont réparties entre les sous–classes en fonction des droits à
ressources attribués à chacune d’elles.
• L’administrateur système peut déléguer la gestion des sous–classes de chaque
superclasse à un administrateur de superclasses ou à un groupe d’administrateurs.
• Dans AIX 5.2 et les versions supérieures, WLM prend en charge jusqu’à 69
superclasses (64 définies par l’utilisateur) et 64 sous–classes par superclasse
(61 définies par l’utilisateur).
• Selon les besoins de l’entreprise, l’administrateur système peut décider d’utiliser
uniquement les superclasses ou les superclasses et les sous–classes. Il peut également
n’utiliser les sous–classes que pour certaines superclasses.
Remarque : Tout au long de cette discussion sur WLM, le terme classe s’applique aux
superclasses et aux sous–classes. Si la discussion ne s’applique qu’à un type de classe
spécifique, ce type est explicitement mentionné.
9-4
Concepts de gestion de système AIX – Système d’exploitation et unités
Affectation de process aux classes
Les process sont affectés à une classe selon les règles d’affectation établies par
l’administrateur système. Les critères de classification reposent sur la valeur d’un ensemble
d’attributs du process, tels que l’id utilisateur, l’id de groupe, le nom du fichier d’application,
le type de process et l’étiquette d’application.
Un ensemble de règles défini est utilisé pour déterminer la superclasse à laquelle un
processus est affecté. Si des sous–classes sont définies pour cette superclasse, il existe un
autre ensemble de règles pour cette superclasse pour déterminer quelle sous–classe est
affectée à quel processus. Ce processus d’affectation automatique tient également compte
des attributs d’héritage de la superclasse et de la sous–classe. (Pour plus d’informations
sur les attributs de classe, reportez–vous à la section Attributs de classe WLM, page 9-11.)
L’affectation automatique de classe intervient lorsqu’un process exécute l’appel système
exec. L’affectation de classe est réévaluée lorsqu’un process emploie un appel système
susceptible de modifier un attribut de process servant à la classification. C’est le cas par
exemple de setuid, setgid, setpri et plock.
Outre cette affectation automatique de classe, un utilisateur disposant des droits appropriés
peut affecter manuellement des process ou groupes de process à certaines superclasses
ou sous–classes.
Contrôle des ressources
WLM permet de gérer les ressources de deux manières : sous la forme d’un pourcentage
des ressources disponibles ou en fonction de l’usage total des ressources. Les ressources
qui peuvent être contrôlées sous la forme d’un pourcentage incluent :
• Utilisation du CPU par les routines d’une classe. Il s’agit de la somme de tous les cycles
CPU consommés par chaque routine de la classe.
• Utilisation de la mémoire physique par les process d’une classe. Il s’agit de la somme
des pages mémoires appartenant aux process de la classe.
• Bande passante d’E/S disque de la classe. Il s’agit de la bande passante (en blocs de
512 octets par seconde) de toutes les E/S lancées par des routines de la classe sur
chaque unité de disque à laquelle la classe accède.
Les ressources qui peuvent être contrôlées en fonction de l’utilisation total sont regroupées
dans deux catégories : totaux de classe ou totaux de processus Les totaux de classe
incluent :
le nombre de processus dans une classe
Il s’agit du nombre de processus actifs dans une classe à un moment
donné.
le nombre de threads dans une
Il s’agit du nombre de threads actives dans une classe à un moment donné.
le nombre de connexions dans une
Il s’agit du nombre de sessions de connexions dans une classe à un
moment donné.
Les totaux de processus incluent :
le temps UC total
Il s’agit du temps total UC cumulé associé à un processus.
E/S disque totales
Il s’agit du nombre total de blocs cumulés d’E/S de disque associé à un
processus.
Durée de connexion totale
Il s’agit du délai total d’activité d’une session de connexion.
Gestion de la charge de travail
9-5
Droits à ressources
WLM permet aux administrateurs système de spécifier les droits à ressource par classe
indépendamment pour chaque type de ressource. Ces droits peuvent être spécifiés en
indiquant ce qui suit :
• La cible d’utilisation des différents types de ressources. Cette cible est indiquée à l’aide
de partages, spécifiés sous forme de quantités relatives d’utilisation des différentes
classes. Ainsi, si deux classes ont respectivement 1 et 3 partages de CPU et si ce sont
les seules classes actives au moment concerné, WLM adoptera un objectif de régulation
du CPU de 25 % et 75 %, respectivement. Les pourcentages cibles sont calculés pour
les classes dans chaque niveau en fonction du nombre de partages actifs dans un niveau
et de la quantité de ressource disponible pour le niveau.
• Limites minimale et maximale. Elles sont indiquées sous forme de pourcentage du total
de ressources disponibles. WLM accepte deux types de limites maximales :
– Une limite maximale souple (soft), qui indique la quantité maximale de la ressource qui
peut être rendue disponible en cas de conflit d’accès la concernant. Cette limite peut
être dépassée en l’absence de conflit, c’est–à–dire si la ressource ne fait pas l’objet
d’autres demandes.
– Une limite maximale ferme, qui indique la quantité maximale de la ressource qui peut
être rendue disponible, même en l’absence de conflit d’accès la concernant.
• Limites totales Les limites totales sont appliquées de manière stricte. Si un processus
dépasse l’une de ses limites de consommation totale, il est arrêté. Si une classe atteint
l’une de ses limites totales, toute opération qui génère une autre instance de la
ressource échoue.
Dans la plupart des cas, des limites maximales logicielles sont suffisantes pour garantir
l’affectation des ressources. En utilisant des limites maximales matérielles, des ressources
système peuvent ne pas être utilisées du fait qu’elles sont appliquées strictement, même s’il
n’existe pas de conflit pour la ressource. Vous devez utiliser les limites maximales
matérielles avec précaution du fait qu’elles peuvent affecter considérablement les
performances du système ou les application si les limites sont trop basses. Les limites
totales doivent être également utilisées avec précaution du fait qu’elles peuvent provoquer
l’arrêt des processus ou ne pas fonctionner comme prévu.
En mode actif, WLM tente de maintenir les classes actives proches de leurs cibles. Du fait
qu’il existe quelques contraintes sur les valeurs des diverses limites, la somme des limites
dans toutes les classes peut dépasser largement 100%. Dans ce cas, si toutes les classes
sont actives, la limite ne peut pas être atteinte par toutes les classes. WLM régule la
consommation UC en ajustant les priorités de planification des threads dans le système en
fonction des performances de la classe à laquelle elles appartiennent, par rapport à ses
limites et sa cible. Cette approche garantit une consommation UC moyenne calculée sur
une période donnée et non une consommation UC sur une courte période (tics de 10 ms,
par exemple).
Si la classe A, par exemple, est la seule classe active, avec une consommation UC
minimum de 0 % et une cible UC de 60 partages, elle dispose de 100 % de l’UC. Si la
classe B, avec une limite minimale UC de 0 % et une cible UC de 40 partages, devient
active, l’utilisation UC de la classe A diminue progressivement pour atteindre 60 % et
l’utilisation UC de la classe B passe de 0 à 40 %. Le système se stabilise à une utilisation
UC de 60 % et 40 % respectivement en quelques secondes.
Cet exemple suppose qu’il n’existe pas de conflit de mémoire entre les classes. Dans des
conditions de travail normales, les limites que vous définissez pour l’UC et la mémoire sont
interdépendantes. Par exemple, une classe peut ne pas pouvoir atteindre sa cible ou même
son allocation UC minimale si la limite maximale d’utilisation de la mémoire est trop basse
comparée à son ensemble d’exploitation.
9-6
Concepts de gestion de système AIX – Système d’exploitation et unités
Pour redéfinir la classe et les limites de classe pour un groupe d’applications, WLM fournit
l’outil de génération de rapports wlmstat qui indique la quantité de ressource utilisée par
chaque classe. L’outil graphique wlmmon est également fourni pour contrôler le système.
Modes de fonctionnement WLM
WLM peut être utilisé pour réguler la consommation des ressources sous forme de
pourcentages par classe, de totaux par classe ou de totaux par processus. La régulation
de tous les types de ressources peut être activée en exécutant WLM en mode actif.
Vous pouvez également démarrer un mode WLM qui classe les processus nouveaux et
existants et contrôle l’utilisation des ressources des diverses classes sans tenter de réguler
cette utilisation. Ce mode s’appelle le mode passif.
Le mode passif peut être utilisé lors de la configuration de WLM sur un nouveau système
pour vérifier les règles de classification et d’affectation et pour établir une base d’utilisation
des ressources pour les diverses classes lorsque WLM ne régule pas l’allocation UC et de
mémoire. Cela permet aux administrateurs système de définir la manière d’appliquer les
partages de ressources et les limites de ressources (si nécessaire) pour favoriser les
applications importantes et limiter les applications moins importantes pour leur permettre
d’atteindre leurs objectifs professionnels.
Si le temps UC est la seule ressource à réguler, vous pouvez décider d’exécuter WLM en
mode actif pour l’UC et en mode passif pour toutes les autres ressources. Ce mode
s’appelle le mode uc uniquement. Si vous voulez réguler les pourcentages par classe, mais
pas les types de ressources totales, la comptabilité et la régulation des ressources totales
peut être désactivée pour les totaux par classe, les totaux par processus ou les deux. Dans
tous les modes, vous pouvez désactiver la liaison des groupes de ressources.
Contrôle dynamique
Lorsque WLM est actif, les paramètres de la configuration en cours peuvent être modifiés à
tout moment ; c’est notamment le cas des attributs d’une classe, de ses partages et limites
de ressources, de ses règles d’affectation et de l’ajout ou de la suppression de classes
existantes. A cet effet, diverses solutions sont disponibles :
• Modification des fichiers de propriétés pour la configuration actuellement active
(répertoire pointé par le lien symbolique /etc/wlm/current) et rafraîchissement de WLM
avec wlmcntrl pour permettre la prise en compte des nouveaux paramètres.
• Création d’une autre configuration avec un jeu de paramètres différent et mise à jour de
WLM afin qu’il charge ces paramètres et en fasse la configuration active.
• Modification de certains des paramètres de la configuration active à l’aide de l’interface à
ligne de commande de WLM (mkclass, chclass, et rmclass).
• Modification de certains paramètres de la configuration active en cours dans une
application à l’aide des API WLM.
Le passage automatique à une nouvelle configuration à des moments donnés de la journée
peut être réalisé à l’aide de jeux de configuration. Les jeux de configuration permettent à
l’administrateur de définir un groupe de configurations à utiliser ainsi que la période pendant
laquelle chaque configuration sera active.
Outils de contrôle
WLM dispose de trois commandes qui affichent les statistiques de WLM et permettent à
l’administrateur système de surveiller le fonctionnement de ce logiciel :
• wlmstat est une commande orientée texte qui affiche des statistiques sous forme de
texte (pourcentage d’utilisation des ressources par classe pour tous les types de
ressources gérés par WLM).
• wlmmon offre une vue graphique de l’utilisation des ressources par classe et de la
régulation de WLM.
Gestion de la charge de travail
9-7
• wlmperf est un outil en option disponible avec la Performance Toolbox ; il offre plus de
possibilités, par exemple l’enregistrement et la réexécution à long terme, ainsi que
d’autres fonctions.
API WLM
Une API (interface de programmation d’applications) permet aux applications d’effectuer
toute opération susceptible d’être exécutée à l’aide de l’interface à ligne de commande de
WLM :
• Comme la création, la modification ou la suppression de classes
• Le changement d’attributs des classes ou des partages et limites de ressources
• L’affectation manuelle de process aux classes.
De plus, l’API permet aux applications de définir un attribut de classification qui leur est
propre, appelé étiquette (tag). La définition de cette étiquette à l’aide d’un jeu de valeurs
connu de l’administrateur système (via la documentation utilisateur de l’application) permet
de faire la distinction entre plusieurs instances de la même application. Sa classification
dans différentes classes, avec différents droits à ressources, est ainsi possible.
Comptabilité par classe
Avec l’utilitaire de système de comptabilité d’AIX, vous pouvez rassembler et rendre compte
de l’utilisation de plusieurs ressources de système par utilisateur, groupe ou classe WLM.
Lorsque le relevé de processus est activé, le système d’exploitation enregistre des
statistiques sur l’utilisation de la ressource du processus dans un fichier de comptabilité
lorsque le processus s’arrête. A partir de AIX 5.1, cet enregistrement comptable comprend
une touche numérique de 64 octets représentant le nom de la classe WLM à laquelle le
processus appartenait. (Pour en savoir plus sur l’utilitaire de système de comptabilité,
reportez–vous à la section Comptabilité – généralités, page 11-2.)
Le sous–système de comptabilité utilise une touche de 64 octets à la place du nom de
classe complet de 34 caractères pour économiser de l’espace (sinon la modification
doublerait pratiquement la taille de l’enregistrement comptable). Lorsque la commande de
comptabilité est exécutée pour extraire les données au niveau du processus, la touche est
traduite en nom de classe à l’aide de la routine mentionnée ci–dessus. Cette traduction
utilise les noms de classe actuellement dans les fichiers de configuration WLM. Donc si une
classe a été supprimée entre le moment où l’enregistrement comptable a été écrit, lorsque
le processus s’est terminé, et le moment où le compte–rendu de comptabilité est exécuté,
le nom de classe correspondant à la touche est introuvable, et la classe s’affiche comme
Unknown (inconnue).
Pour garder des comptes–rendus appropriés de l’usage de ressource de classes
supprimées pendant un exercice financier, utilisez l’une des procédures suivantes :
• Au lieu de supprimer la classe, gardez le nom de la classe dans le fichier des classes
et supprimez la classe du fichier de règles afin qu’aucun processus ne puisse lui être
attribué. Vous pouvez ensuite supprimer la classe après avoir généré le compte–rendu
de comptabilité à la fin de l’exercice financier.
• Vous pouvez également supprimer la classe de la configuration à laquelle elle appartient
et garder le nom de la classe dans le fichier des classes dans une configuration
« factice » (jamais activée) jusqu’à la génération des comptes–rendus de comptabilité
pour l’exercice.
9-8
Concepts de gestion de système AIX – Système d’exploitation et unités
Généralités sur les classes WLM
Workload Manager vous aide à contrôler l’allocation des ressources système en définissant
des classes de service et en allouant des ressources à chacune de ces classes. Chaque
classe dispose d’un groupe d’attributs qui déterminent les allocations de ressources et
d’autres comportement. Chaque processus du système appartient à une classe de service
et l’allocation de ressources et les comportements associés à la classe lui sont appliqués.
Les processus sont affectés à une classe manuellement à l’aide de l’affectation manuelle
ou automatiquement en fonction des règles de classification définies par l’utilisateur.
WLM prend en charge deux niveaux de classes : les superclasses et les sous–classes.
Les superclasses sont affectées de ressources en fonction des ressources système
disponibles et les sous–classes sont affectées de ressources en fonction des affectations
de la superclasse qui leur est associée. Vous pouvez également définir des sous–classes
pour mieux contrôler les processus d’une superclasse. Vous pouvez également déléguer
la définition des superclasses en définissant un utilisateur administrateur ou un groupe
d’administrateurs pour une superclasse.
Pour les superclasses et les sous–classes, vous pouvez définir des classes, des partages
de ressources, des limites et des règles en utilisant SMIT, Web–based System Manager ou
l’interface de ligne de commande. Les applications peuvent utiliser les API WLM. Les
définitions de configurations sont stockées dans des fichiers texte appelés fichiers de
propriétés WLM.
Un nom de classe contient jusqu’à 16 caractères qui peuvent correspondre à des
majuscules et des minuscules, des chiffres et le caractère souligné (_). Pour chaque
configuration WLM, chaque nom de superclasse doit être unique. Chaque nom de
sous–classe doit être unique dans les superclasses, mais une sous–classe peut porter
le nom d’une sous–classe d’une autre superclasse. Pour identifier chaque sous–classe de
manière unique, le nom complet d’une sous–classe est constitué du nom de la superclasse
et du nom de la sous–classe séparés par un point. Par exemple : Super. Sub.
Gestion de la charge de travail
9-9
Superclasses
L’administrateur système peut définir jusqu’à 64 superclasses. De plus, cinq superclasses
sont créées automatiquement, comme suit :
Superclasse Default (par défaut)
Il s’agit de la superclasse par défaut, qui est toujours définie. Tous les
process non–racine qui ne sont pas affectés automatiquement à une
superclasse spécifique sont affectés à la superclasse par défaut. Les
autres process peuvent également être affectés à la superclasse Default
à l’aide de règles d’affectation spécifiques.
Superclasse System (système)
Cette superclasse se voit affecter tous les process privilégiés (root) si
ceux–ci ne sont pas affectés à une classe spécifique par des règles.
Cette superclasse collecte également les pages mémoire appartenant aux
segments mémoire, aux process et aux routines du noyau. D’autres
process peuvent également être affectés à la superclasse System à l’aide
de règles d’affectation spécifiques. Par défaut, la limite minimale de
mémoire de cette superclasse est de 1 %.
Superclasse Shared (partagée)
Cette superclasse reçoit toutes les pages mémoire partagées par des
process appartenant à plusieurs superclasses. Cela comprend les pages
dans des régions de mémoire partagée et celles des fichiers utilisés par
des process appartenant à plusieurs superclasses (ou à des sous–classes
de superclasses distinctes). La mémoire partagée et les fichiers utilisés par
plusieurs process appartenant tous à une seule superclasse (ou à des
sous–classes de la même superclasse) sont associés à cette superclasse.
Ce n’est que lorsqu’un process d’une superclasse différente accède à la
région de mémoire partagée ou au fichier que les pages sont placées dans
la superclasse Shared. Seuls des partages et limites de mémoire physique
peuvent être appliqués à cette superclasse. Les partages et limites des
autres types de ressources, sous–classes ou règles d’affectation spécifiées
ne peuvent pas lui être appliqués. Qu’un segment de mémoire partagé par
des processus dans différentes sous–classes de la même superclasse soit
classé dans la sous–classe Shared (partagé) ou reste dans sa sous–classe
d’origine dépend de la valeur de l’attribut localshm de la sous–classe
d’origine.
Superclasse Unclassified (non classée)
Les process existants au moment du lancement de WLM sont classés en
fonction des règles d’affectation de la configuration de WLM en cours de
chargement. Pendant cette classification initiale, toutes les pages mémoire
sont affectées soit à la superclasse à laquelle le process appartient (si elles
ne sont pas partagées, ou si elles sont partagées par les process de la
même superclasse), soit à la superclasse Shared si elles sont partagées
par des process de différentes superclasses.
Toutefois, quelques pages ne peuvent pas être directement liées à un
process quelconque (et donc à une classe quelconque) au moment de la
classification ; la mémoire correspondante est affectée à la superclasse
Unclassified. La majeure partie de cette mémoire finit par être correctement
reclassée au cours des temps, lorsqu’un process y accède, ou lorsqu’elle
est libérée et réaffectée à un process après le démarrage de WLM. La
superclasse Unclassified ne contient aucun process. Des partages et des
limites de mémoire physique peuvent lui être appliqués. Elle ne peut pas
avoir de partages ou de limites pour les autres types de ressources,
sous–classes ou règles d’affectation spécifiées.
9-10
Concepts de gestion de système AIX – Système d’exploitation et unités
Superclasse Unmanaged (non gérée)
Cette superclasse est toujours définie. Aucun process ne lui est affecté.
Elle sert à accumuler l’utilisation du CPU pour tous les process à priorité
fixe et l’utilisation de mémoire pour toutes les pages réservées du système.
L’utilisation du CPU pour le waitprocs n’est accumulée dans aucune classe.
Ce fait est volontaire, car sinon le système semblerait toujours être à 100 %
d’utilisation CPU, ce qui pourrait être trompeur pour les utilisateurs
examinant les statistiques WLM.
Sous–classes
Jusqu’à 61 sous–classes peuvent être définies par l’administrateur système ou un
administrateur de superclasse. De plus, deux sous–classes spéciales, Default et Shared
sont toujours définies.
Sous–classe Default
Il s’agit de la sous–classe par défaut, qui est toujours définie. Tous les
process qui ne sont pas automatiquement affectés à une sous–classe
particulière de la superclasse sont affectés à la sous–classe Default. Vous
pouvez également affecter d’autres process à la sous–classe Default, à
l’aide de règles d’affectation spécifiques.
Sous–classe Shared
Cette classe reçoit toutes les pages mémoire utilisées par des process
appartenant à plusieurs sous–classes de la superclasse. Il s’agit
notamment des pages figurant dans des zones de mémoire partagée et
des pages se trouvant dans des fichiers utilisés par des process
appartenant à plusieurs sous–classes de la même superclasse. La
mémoire partagée et les fichiers utilisés par plusieurs process appartenant
tous à une seule sous–classe sont associés à cette sous–classe. Ce n’est
que lorsqu’un process d’une sous–classe différente, appartenant à la
même superclasse, accède à la zone de mémoire partagée ou au fichier
que les pages sont placées dans la sous–classe Shared de la superclasse.
La sous–classe Shared ne contient pas de process. Seuls des partages et
des limites de mémoire physique peuvent lui être appliqués. Elle ne peut
pas avoir de partages ou de limites pour les autres types de ressources ou
les règles d’affectation spécifiées. Qu’un segment de mémoire partagé par
des processus dans différentes sous–classes de la même superclasse soit
classé dans la sous–classe Shared (partagé) ou reste dans sa sous–classe
d’origine dépend de la valeur de l’attribut localshm de la sous–classe
d’origine.
Attributs de classe
Les attributs d’une classe sont :
Class name (nom de la classe) :
peut comporter jusqu’à 16 caractères, ne contenant que des lettres
majuscules et minuscules, des chiffres et des caractères de
soulignement (_).
Tier (rang) :
chiffre entre 0 et 9 servant à définir la priorité d’affectation de ressources
entre les classes.
Inheritance (héritage) :
spécifie si un process enfant hérite l’affectation de classe de son process
parent.
localshm
Empêche les segments de mémoire d’une classe de migrer vers la classe
Shared.
Administrator (adminuser, admingroup, authgroup) (superclasse uniquement)
Délègue l’administration d’une superclasse.
Gestion de la charge de travail
9-11
Authorization (authuser, authgroup)
Délègue le droit d’affecter manuellement un processus à une classe.
Resource Set (rset)
Limite le jeu de ressources auquel une classe peut accéder en terme d’UC
(groupe de processeurs).
Attribut de niveau
Les niveaux correspondent à l’ordre d’allocation des ressources système dans les classes
WLM. L’administrateur peut définir des classes sur 10 niveaux maximum, numérotés de 0
à 9, 0 correspondant au niveau le plus haut ou le plus important. La quantité de ressources
disponible pour le niveau 0 correspond à toutes les ressources système disponibles.
La quantité de ressources disponible pour les niveaux inférieurs (nombre supérieur)
correspond au nombre de ressources non utilisées par tous les niveaux supérieurs. Les
pourcentages de consommation cibles des classes reposent sur le nombre de partages
actifs dans ses niveaux et la quantité de ressources disponible pour le niveau. Du fait que le
niveau 0 est le seul niveau qui ait toujours des ressources disponibles, il est recommandé
de classer dans ce niveau les processus indispensables au fonctionnement du système.
Si aucun niveau n’est défini pour une classe, le niveau 0 est utilisé.
Un niveau peut être défini dans la superclasse et dans la sous–classe. Les niveaux de
superclasse permettent de vérifier la priorité d’allocation de ressources entre les
superclasses. Les niveaux de sous–classe permettent de vérifier la priorité de l’allocation d
e ressources entre les sous–classes d’une superclasse. Il n’existe pas de relation entre les
sous–niveaux de différentes superclasses.
Attribut d’héritage
L’attribut d’héritage d’une classe indique si les processus de la classe doivent être reclassés
automatiquement lorsque l’un des attributs de classification du processus change. Lors de
la création d’un processus avec la sous–routine fork, le processus hérite automatiquement
de la classe de son parent, que l’héritage soit activé ou non, sauf lorsque le processus
parent a une option, que inherit tag at fork est désactivé et que l’héritage de classe de la
classe parent est désactivé. Dans ce cas, le processus enfant est reclassé en fonction des
règles de classification.
Lorsque l’héritage de classe n’est pas activé sur une classe, tout processus de la classe est
classifié automatiquement en fonction des règles de classification après l’appel d’un service
qui change un attribut de processus utilisé dans la règle. L’appel le plus courant de ces
appels est la sous–routine exec, mais les autres sous–routines qui peuvent changer la
classification incluent setuid, setgid, plock, setpri et wlm_set_tag. Lorsque l’héritage est
actif, le processus n’est pas reclassé en fonction des règles de classification et il reste dans
sa classe. L’affectation manuelle est prioritaire par rapport à l’héritage et peut être utilisée
pour reclasser les processus d’une classe dont l’héritage est activé.
La valeur définie pour cet attribut peut être yes ou no. Si aucune valeur n’est définie,
l’héritage n’est pas activé sur la classe.
Cet attribut peut être défini au niveau de la superclasse et de la sous–classe.
Pour une sous–classe d’une superclasse :
• Si l’attribut d’héritage est affecté de la valeur yes au niveau de la superclasse et
de la sous–classe, un enfant d’un processus de la sous–classe reste dans la même
sous–classe.
• S’il est affecté de la valeur yes pour la superclasse et de la valeur no (non défini)
pour la sous–classe, un enfant d’un processus dans la sous–classe reste dans
la même superclasse et il sera classé dans l’une de ses sous–classes en fonction
des règles d’affectation de la superclasse.
• S’il est affecté de la valeur no (non défini) pour la superclasse et de la valeur yes
pour la sous–classe, un enfant de processus dans la sous–classe est soumis aux
règles d’affectation automatique des superclasses.
9-12
Concepts de gestion de système AIX – Système d’exploitation et unités
– Si le process est classé par les règles de la même superclasse, il reste dans
la sous–classe (il n’est pas soumis aux règles d’affectation des sous–classes).
– Si le process est classé dans une superclasse différente par les règles des
superclasses, les règles d’affectation de sous–classe de la nouvelle superclasse lui
sont appliquées pour déterminer à quelle sous–classe de la nouvelle superclasse le
process est affecté.
• Si les attributs d’héritage de la superclasse et de la sous–classe ont la valeur non (no)
ou ne sont pas spécifiés, lors de l’exec(), l’enfant d’un process d’une sous–classe est
soumis aux règles d’affectation automatique standard.
Attribut localshm
L’attribut localshm peut être spécifié aux niveaux de la superclasse et de la sous–classe.
Il est utilisé pour éviter que des segments de mémoire appartenant à une classe migrent
vers la superclasse ou vers la sous–classe Shared (partagé) lorsque des processus y
accèdent dans d’autres classes. Les valeurs possibles de l’attribut sont oui ou non. La
valeur oui signifie que des segments de mémoire dans cette classe doivent y rester et
ne pas migrer vers la classe Shared (partagé) appropriée. La valeur non est la valeur
par défaut lorsque l’attribut n’est pas spécifié.
Les segments de mémoire sont classés dans les défaillances de page. Lors de la création
d’un segment, ce dernier est signalé comme appartenant à la superclasse Unclassified (non
classé). Sur la première défaillance de page du segment, il est classé dans la même classe
que le processus défaillant. Si ensuite un processus appartenant à une classe différente de
la page du segment est défaillant sur ce segment, WLM décide si le segment doit être
reclassé dans la classe Shared (partagé) (superclasse ou sous–classe) appropriée. Si le
processus défaillant et le segment appartiennent à des superclasses différentes, l’une des
possibilités suivantes se produit :
• Si l’attribut localshm de la superclasse du segment est défini sur oui, le segment reste
dans sa superclasse actuelle. Si l’attribut localshm de la sous–classe du segment est
défini sur oui, le segment reste dans sa sous–classe actuelle. Si l’attribut localshm de la
superclasse est défini sur oui mais que son attribut de sous–classe est défini sur non, il
va dans la sous–classe Shared (partagé) de la superclasse actuelle.
• Si l’attribut localshm de la superclasse du segment est défini sur non, le segment va à la
superclasse Shared (partagé). Il s’agit là de l’action par défaut.
Si le processus défaillant et le segment appartiennent à différentes sous–classes de la
même superclasse, et que l’attribut localshm de la sous–classe du segment est défini
sur oui, le segment reste dans la classe actuelle (superclasse et sous–classe). Sinon,
le segment va dans la sous–classe Shared (partagé) de la superclasse.
Bien sûr, si le processus défaillant et le segment appartiennent à la même classe (même
superclasse et même sous–classe), le segment n’est pas reclassé sans que les valeurs
des attributs localshm soient prises en compte.
Gestion de la charge de travail
9-13
Attributs Administrator
Remarque : Ces attributs ne sont valables que pour les superclasses.
Les attributs suivants servent à déléguer l’administration d’une superclasse à un utilisateur
ou un groupe d’utilisateurs :
• adminuser spécifie le nom de l’utilisateur (tel qu’il est mentionné dans /etc/passwd)
autorisé à effectuer des tâches d’administration sur la superclasse.
• admingroup spécifie le nom d’un groupe d’utilisateurs (tel qu’il est mentionné dans
/etc/group) autorisés à effectuer des tâches d’administration sur la superclasse.
Une seule valeur (utilisateur ou groupe) est autorisée pour chaque attribut. Il est possible
de spécifier l’un ou l’autre attribut, les deux ou aucun d’eux. L’utilisateur ou groupe aura
le droit de :
• créer et supprimer des sous–classes ;
• modifier les attributs et les partages et limites de ressources pour les sous–classes;
• définir, supprimer ou modifier les règles d’affectation de sous–classes ;
• rafraîchir (actualiser) la configuration WLM active pour la superclasse.
Attributs Authorization
Ces attributs sont valables pour toutes les classes. Ils permettent d’indiquer l’utilisateur
ou le groupe autorisé à affecter manuellement des process à une classe (superclasse ou
sous–classe). Lors de l’affectation manuelle d’un process (ou d’un groupe de process) à
une superclasse, les règles d’affectation de la superclasse servent à déterminer à quelle
sous–classe de cette superclasse chaque process sera affecté.
Une seule valeur (utilisateur ou groupe) est autorisée pour chaque attribut. Il est possible
de spécifier l’un ou l’autre attribut, les deux ou aucun d’eux.
Attribut Resource Set
L’attribut Resource set (appelé rset) peut être défini pour n’importe quelle classe. Sa valeur
correspond à un nom de groupe de ressources défini par l’administrateur. L’attribut rset est
un sous–ensemble de la ressource UC disponible dans le système (groupe de
processeurs). La valeur par défaut est ”system” qui donne accès aux ressources UC
disponibles dans le système. La seule restriction réside dans le fait que si rset est défini
pour une sous–classe, les UC du groupe d’UC doivent correspondre à un sous–ensemble
des UC disponibles dans la superclasse. (Pour plus d’informations, reportez–vous à la
description de la commande mkrset dans le document AIX 5L Version 5.3 Commands
Reference.)
Remarque :
9-14
Veillez à affecter les groupes de ressources à une classe n’appartenant pas
au niveau 0, du fait que les niveaux inférieurs ont uniquement accès aux
ressources non utilisées par les niveaux supérieurs. La restriction d’une
classe ne correspondant pas à une classe de niveau 0 à un
sous–ensemble d’UC du système peut provoquer un manque d’UC s’il
n’existe pas de temps UC sur ces UC.
Concepts de gestion de système AIX – Système d’exploitation et unités
Affectation de process à des classes
Dans Workload Manager, les process sont classés de deux façons :
• Un processus est automatiquement affecté en utilisant les règles d’affectation lorsque
les attributs de classification de processus changent. Lorsque WLM fonctionne en mode
actif, cette affectation automatique est toujours en vigueur (elle peut être désactivée).
Il s’agit de la procédure la plus courante de classification des processus.
• Un processus sélectionné ou un groupe de processus peuvent être affectés
manuellement à une classe par un utilisateur avec la priorité appropriée sur les
processus et la classe cible. L’affectation manuelle peut être effectuée en utilisant
une commande WLM qui peut être appelée directement ou exécutée via SMIT ou
Web–based System Manager ou bien par une application utilisant une fonction de
l’interface API WLM. Cette affectation manuelle remplace l’affectation automatique
et l’héritage.
Affectation automatique
L’affectation automatique de process à des classes s’effectue selon un ensemble de règles
d’affectation de classe définies par l’administrateur WLM. Deux niveaux de règles
d’affectation sont disponibles :
• Un premier ensemble de règles au niveau de la configuration de WLM, qui sert à
déterminer à quelle superclasse un process particulier doit être affecté.
• Un deuxième ensemble, situé au niveau des superclasses pour lesquelles des
sous–classes sont définies. Il détermine à quelle sous–classe le process doit être affecté.
Les règles d’affectation aux deux niveaux repose sur les valeurs d’un groupe d’attributs de
processus. Ces attributs sont les suivants :
• L’ID utilisateur du process
• L’ID de groupe du process
• Le chemin d’accès de l’application (programme) exécutée
• Type of processus ( 32 bits ou 64 bits, par exemple)
• L’étiquette (tag) du process
L’étiquette (tag) est un attribut, défini sous forme de chaîne de caractères, qu’une
application peut définir par programme, en faisant appel à l’API (interface de programmation
d’application) de WLM.
La classification a lieu chaque fois qu’un attribut change en comparant la valeur des
attributs des processus à des listes de valeurs possibles dans les règles d’affectation de
classe (appelées règles). La comparaison détermine la règle qui correspond à la valeur
en cours des attributs de processus.
Une règle d’affectation de classe est une chaîne de caractères qui contient les champs
suivants séparés par au moins un espace :
Gestion de la charge de travail
9-15
Une affectation de classe est une chaîne de texte contenant différents champs séparés par
un ou plusieurs espaces ou tabulations. Les champs sont les suivants :
Name (nom)
Ce champ doit contenir le nom d’une classe défini dans le fichier de
classe correspondant au niveau du fichier rules (superclasse ou
sous–classe). Les noms de classe ne peuvent contenir que des
lettres majuscules ou minuscules, des chiffres et des caractères de
soulignement. Ils peuvent comporter jusqu’à 16 caractères. Aucune
règle d’affectation ne peut être spécifiée pour les classes définies
par le système Unclassified, Unmanaged et Shared.
Reserved (réservé)
Ce champ est réservé à des extensions futures. Sa valeur doit être
un tiret (–), et sa présence est obligatoire.
User (utilisateur)
Peut contenir un trait d’union (–) ou au moins un nom d’utilisateur
(tel que défini dans le fichier /etc/passwd) La liste contient un ou
plusieurs noms séparés par une virgule (,). Vous pouvez utiliser un
point d’exclamation (!) avant le nom pour exclure un utilisateur de la
classe. Des modèles peuvent être définis pour correspondre à un
groupe de noms d’utilisateurs en utilisant la syntaxe de
correspondance de modèles du shell Korn. S’il n’existe pas de noms
d’utilisateur valides, la règle est ignorée.
Group (groupe)
Peut contenir un trait d’union (–) ou au moins un nom de groupe
(tel que défini dans le fichier /etc/group) La liste contient un ou
plusieurs noms séparés par une virgule (,). Vous pouvez utiliser un
point d’exclamation (!) avant le nom pour exclure un groupe de la
classe. Des modèles peuvent être définis pour correspondre à un
groupe de noms d’utilisateurs en utilisant la syntaxe de
correspondance de modèles du shell Korn. S’il n’existe pas de noms
de groupes valides, la règle est ignorée.
Application
Ce champ peut contenir un tiret (–) ou une liste de noms de chemin
d’accès d’applications. Il contient le chemin d’accès des applications
(programmes) exécutées par les process inclus dans la classe. Les
noms d’application sont soit des chemins d’accès complets, soit des
modèles du shell Korn correspondant à des chemins d’accès. La
liste est composée d’un ou plusieurs chemins d’accès, séparés par
une virgule. Pour exclure une application particulière, il suffit
d’indiquer un point d’exclamation devant son nom.
Au moins une application de la liste doit être détectée lors du
chargement sinon la règle est ignorée. Les règles ignorées
initialement pour cette raison peuvent devenir effectives plus tard
si un système de fichiers est monté et qu’il contient une ou plusieurs
applications de la liste.
9-16
Concepts de gestion de système AIX – Système d’exploitation et unités
Type
Ce champ peut contenir un tiret (–) ou une liste d’attributs du
process. Les valeurs possibles de ces attributs sont les suivantes :
• 32bit: il s’agit d’un process 32 bits
• 64bit: il s’agit d’un process 64 bits
• plock: le process a exécuté l’appel système plock pour réserver
de la mémoire
• fixed: il s’agit d’un process à priorité fixe (SCHED_FIFO
ou SCHED_RR). La valeur du champ type peut être une
combinaison d’un ou plusieurs des attributs ci–dessus, séparés
par le signe plus (+). 32bit et 64bit s’excluent mutuellement.
Tag (étiquette)
Ce champ peut contenir un tiret (–) ou une liste d’étiquettes
d’application. Une étiquette d’application est une chaîne d’au plus
30 caractères alphanumériques. La liste est composée d’une ou
plusieurs étiquettes d’application séparées par des virgules.
Les attributs User, Group, Application et Tag peuvent être un groupe de valeurs d’attributs.
Lors de la création d’un process (fourchette), celui–ci reste dans la même classe que son
parent. La reclassification se produit lorsque le nouveau process modifie l’un de ses
attributs servant à la classification : exec, setuid (et appels associés), setgid (et appels
associés), setpri et plock, par exemple.
Afin de classer le process, WLM examine le fichier rules de niveau supérieur de la
configuration active pour trouver à quelles superclasses le process doit appartenir. Pour
chaque règle du fichier, WLM compare les valeurs en cours des attributs du process aux
valeurs et listes de valeurs spécifiées dans la règle. Les règles sont vérifiées dans l’ordre
dans lequel elles apparaissent dans le fichier. En cas de correspondance, le process est
affecté à la superclasse nommée dans le premier champ de la règle. Ensuite, le fichier de
règles de la superclasse est examiné de la même façon, afin de déterminer à quelles
sous–classes le process doit être affecté.
Pour qu’un process corresponde à l’une des règles, chacun de ses attributs doit
correspondre au champ adéquat de la règle. La liste suivante répertorie les critères servant
à déterminer si la valeur d’un attribut correspond aux valeurs du champ du fichier rules :
• Si le champ du fichier de règles contient un tiret (–), toute valeur de l’attribut de process
en rapport lui correspond.
• Pour tous les attributs à l’exception de type, si la valeur de l’attribut de process
correspond à l’une des valeurs de la liste du fichier de règles qui n’est pas exclue
(précédée d’un “!”), il y a concordance.
• Pour l’attribut type, si l’une des valeurs de la règle comprend deux valeurs ou plus
séparées par un signe plus (+), il n’y aura concordance du process que si toutes ses
caractéristiques correspondent à toutes les valeurs mentionnées ci–dessus.
Tant au niveau des superclasses que des sous–classes, WLM parcourt les règles dans
l’ordre dans lequel elles apparaissent dans le fichier rules, et range les process dans les
classes qui correspondent à la première règle pour laquelle il y a concordance. En d’autres
termes, l’ordre dans lequel les règles figurent dans le fichier de règles est très important : il
convient d’agir avec la plus grande précaution lors de la création ou de la modification du
fichier de règles.
Affectation manuelle
Un process ou un groupe de process peut être affecté manuellement à une superclasse
et/ou une sous–classe soit à l’aide des interfaces d’administration de WLM Web-based
System Manager, SMIT ou de la commande wlmassign, soit via une application utilisant la
fonction de l’API WLM wlm_assign.
Gestion de la charge de travail
9-17
Pour affecter manuellement des processus à une classe ou pour annuler une affectation
manuelle existante, un utilisateur doit disposer du niveau de prilèges approprié. (Pour plus
d’informations, reportez–vous à Remarques sur la sécurité, page 9-19.) Une affectation
manuelle peut être faite ou annulée séparément au niveau de la superclasse, de la
sous–classe ou des deux. Cette affectation est indiquée par des options pour l’interface de
programmation et un ensemble d’options pour l’interface de ligne de commande est utilisé
par les outils d’administration WLM. Un processus peut donc être affecté manuellement à
une superclasse uniquement ou à une superclasse et une sous–classe de cette
superclasse. Dans ce dernier cas, la double affectation peut être effectuée simultanément
(avec une commande ou un appel API unique) ou en plusieurs fois, par des utilisateurs
différents.
Ce système est très souple, mais peut prêter à confusion. Voici deux exemples de cas
possibles.
Exemple 1 : Première affectation de process
L’administrateur système affecte manuellement Process1de la superclasseA à la
superclasseB (affectation n’intervenant qu’au niveau des superclasses). WLM fera appel
aux règles d’affectation automatique des sous–classes de la superclasseB pour déterminer
à quelle sous–classe le process sera finalement affecté. Process1 sera affecté à
superclasseB.sous–classeA et sera désigné comme ayant une affectation de type
“superclasse uniquement”.
Un utilisateur muni des droits appropriés affecte le process Process2 appartenant
actuellement à la classe superclasseA.sous–classeA à une nouvelle sous–classe de la
même superclasse, superclasseA.sous–classeB. Process2 est affecté à sa nouvelle
sous–classe et désigné comme ayant une affectation de type “sous–classe uniquement”.
L’administrateur WLM des sous–classes de superclasseB peut décider de réaffecter
manuellement le process Process1 à une autre sous–classe de superclasseB,
sous–classeC par exemple. Process1 sera reclassé dans superclasseB.sous–classeC
et sera désigné comme ayant une affectation de niveau superclasse et sous–classe.
Exemple 2 : Réaffectation et annulation de process
La réaffectation et l’annulation d’une affectation manuelle au niveau d’une sous–classe est
simple et n’a d’implications que sur l’affectation au niveau de cette sous–classe.
Supposons que l’administrateur système souhaite que Process2 figure dans une
superclasse disposant de plus de ressources, et décide d’affecter manuellement Process2
à superclasseC. Process2 avait été affecté manuellement à la sous–classeB de
superclasseA, via une affectation de type “sous–classe uniquement”. Process2 étant affecté
à une superclasse différente, l’affectation manuelle précédente perd sa signification et est
annulée. Process2 a désormais une affectation manuelle de type “superclasse uniquement”
à la superclasseC, et est affecté à une sous–classe de cette dernière conformément aux
règles d’affectation automatiques.
Maintenant, l’administrateur système décide de mettre fin à l’affectation manuelle du
Processus 1 vers la superclasse B. L’affectation manuelle ”niveau superclasse” du
Processus 1 est annulée et en l’absence d’héritage, le Processus 1 est affecté à une
superclasse en utilisant les règles d’affectation automatique de premier niveau.
Si les règles n’ont pas changé, Process1 est affecté à superclasseA et son affectation
manuelle de niveau sous–classe à superclasseB.sousclasseC perd sa signification et est
annulée.
Si, pour une raison quelconque, les règles de niveau supérieur affectent Process1 à
superclasseB, l’affectation de niveau sous–classe à superclasseB.sousclasseC reste valide
et est appliquée. Process1 a désormais une affectation manuelle de type “sous–classe”
uniquement.
9-18
Concepts de gestion de système AIX – Système d’exploitation et unités
Mise à jour de WLM
Lors de la mise à jour de WLM (avec la commande wlmcntrl –u), la configuration mise à
jour peut charger un nouveau groupe de règles de classification. Dans ce cas, les
processus sont souvent reclassifiés à l’aide de nouvelles règles. WLM ne reclassifie pas
les processus affectés manuellement ou qui se trouvent dans une classe dont l’héritage est
activé, à moins que leur classe n’existe pas dans la nouvelle configuration.
Sécurité
Pour affecter un process à une classe ou annuler une affectation manuelle antérieure,
l’utilisateur doit disposer de droits sur le process et sur la classe cible. Ces contraintes se
traduisent comme suit :
• L’utilisateur root peut affecter tout process à n’importe quelle classe.
• Un utilisateur possédant des droits d’administration sur les sous–classes d’une
superclasse donnée (c’est–à–dire que le nom d’utilisateur ou du groupe correspond à
celui spécifié dans les attributs adminuser et admingroup de la superclasse) peut
réaffecter manuellement tout process de l’une des sous–classes de cette superclasse à
une autre de ses sous–classes.
• Un utilisateur peut affecter manuellement ses process (même ID utilisateur réel ou en
vigueur) à une sous–classe pour laquelle il dispose de droits d’affectation manuelle
(c’est–à–dire que le nom d’utilisateur ou du groupe correspond à celui spécifié dans les
attributs authuser et authgroup de la superclasse ou de la sous–classe).
Il y a donc trois niveaux de droits parmi les personnes qui peuvent affecter manuellement
des process à des classes, root étant le plus élevé. Pour qu’un utilisateur puisse modifier ou
mettre fin à une affectation manuelle, il doit avoir au moins le même niveau de droit que la
personne à l’origine de la dernière affectation manuelle.
Gestion de la charge de travail
9-19
Gestion des ressources à l’aide de WLM
WLM contrôle et régule l’utilisation des ressources des routines et processus actifs du
système. Le contrôle et la régulation s’effectuent par classe. Vous pouvez définir des limites
minimum ou maximum par classe pour chaque type de ressource gérée par WLM. En outre,
il est possible d’affecter une valeur cible par classe pour chaque ressource. Cette valeur
représente le quota de ressources optimal pour les tâches de cette classe.
Les partages et les limites au niveau des superclasses font référence à la quantité totale
de chaque ressource disponible sur le système. Au niveau des sous–classes, elles font
référence à la quantité de chaque ressource mise à la disposition de la superclasse à
laquelle appartient la sous–classe (superclasse cible). La hiérarchie des classes est un
moyen de diviser les ressources système entre groupes d’utilisateurs (superclasses) et
de déléguer l’administration de ce partage des ressources aux administrateurs de
superclasses. Chaque administrateur de superclasse peut alors redistribuer cette quantité
de ressources entre les utilisateurs du groupe en créant des sous–classes et en définissant
les droits à ressources pour ces sous–classes.
Types de ressources
WLM gère trois types de ressources en fonction d’une consommation en pourcentage :
Utilisation du CPU par les routines
d’une classe
Somme de tous les cycles CPU consommés par
chaque routine de la classe.
Utilisation de la mémoire physique
par les processus d’une classe
Somme de toutes les pages mémoire qui
appartiennent aux processus de la classe.
Bande passante d’E/S disque de la
classe
Bande passante (en blocs de 512 Ko/seconde) de
toutes les E/S lancées par des routines de la classe
sur chaque unité de disque à laquelle la classe
accède.
Chaque seconde, WLM calcule l’utilisation par classe de chaque ressource au cours de la
dernière seconde, sous forme de pourcentage des ressources totales disponibles.
• Pour le CPU, la quantité totale de temps CPU disponible chaque seconde est égale à
une seconde multipliée par le nombre de CPU du système. Par exemple, sur un SMP à
huit voies, si toutes les routines combinées d’une classe ont consommé 2 secondes de
temps CPU pendant la dernière seconde, cela représente un pourcentage de 2/8= 25 %.
Le pourcentage utilisé par WLM est une moyenne étalée sur quelques secondes de cette
utilisation des ressources par seconde “instantanée”.
• Pour la mémoire physique, la quantité totale de mémoire physique disponible pour les
processus à un moment donné est égale au nombre total de pages mémoire
physiquement présentes sur le système, moins le nombre de pages réservées. Ces
dernières ne sont pas gérées par WLM, puisqu’elles ne peuvent être prises dans une
classe et données à une autre pour réguler l’utilisation de mémoire. L’utilisation de
mémoire d’une classe est le rapport entre le nombre de pages mémoire non réservées
détenues par tous les processus de la classe et le nombre de pages disponibles dans le
système, exprimé sous forme de pourcentage.
• Pour les E/S disque, le problème principal est celui de déterminer un “bande passante”
disponible significative pour un périphérique. Lorsqu’un disque est occupé à 100 %, son
débit en blocs par seconde est très différent lorsqu’une application effectue des E/S
séquentielles et lorsque plusieurs applications génèrent des E/S aléatoires. L’emploi du
débit maximal mesuré avec des E/S séquentielles comme valeur de bande passante
d’E/S disponible afin de calculer le pourcentage d’utilisation du périphérique, peut laisser
penser que ce dernier est utilisé à 20 %, alors qu’en fait il l’est à 100 %.
9-20
Concepts de gestion de système AIX – Système d’exploitation et unités
Pour obtenir des pourcentages d’utilisation disque par classe plus précis et fiables, WLM fait
appel aux statistiques fournies par les pilotes de disque (affichées à l’aide de la commande
iostat), qui donnent pour chaque unité de disque le pourcentage de temps pendant lequel
le périphérique a été occupé au cours de la dernière seconde. WLM compte le nombre total
de blocs qui ont été lus ou écrits sur un périphérique pendant la dernière seconde par
toutes les classes accédant au périphérique, le nombre de blocs qui ont été lus ou écrits par
chaque classe, et le pourcentage d’utilisation du périphérique. WLM calcule ensuite le
pourcentage de débit du disque consommé par chaque classe.
Par exemple, si le nombre total de blocs lus ou écrits au cours de la dernière seconde était
de 1000 et si le périphérique était utilisé à 70 %, cela signifie qu’une classe qui lit ou écrit
100 blocs utilise 7 % de la bande passante du disque. Comme pour le temps CPU (qui est
également une ressource renouvelable), les valeurs utilisées par WLM pour la régulation
des E/S disque sont également une moyenne étalée sur quelques secondes de ces
pourcentages par seconde.
Pour les ressources d’E/S disque, les partages et limites s’appliquent à chaque unité de
disque à laquelle la classe accède individuellement. La régulation est effectuée
indépendamment pour chaque périphérique. En d’autres termes, une classe peut avoir
dépassé ses droits sur un périphérique, et les E/S sur ce dernier seront régulées, tout en
étant en deça de ses droits sur un autre disque, ses E/S sur cet autre disque n’étant alors
pas limitées.
Dans la version AIX 5.2 et les versions supérieures, WLM prend en charge la comptabilité
et la régulation des ressources en fonction de la consommation totale. Il existe deux types
de ressources qui peuvent être régulées de cette manière : totaux de classe ou totaux de
processus
Totaux de classe
Des limites par classe peuvent être définies pour le nombre de processus,
de threads et de sessions de connexion dans la classe. Ces limites sont
définies sous forme de valeurs absolues pour chaque ressource qui existe
dans la classe à un moment donné. Ces limites sont appliquées de manière
stricte. Lorsqu’une classe a atteint sa limite pour l’une de ces ressources,
toute tentative de création d’une autre instance de la ressource échoue.
L’opération échoue toujours pour tout processus de la classe jusqu’à ce
que la classe tombe en dessous de sa limite définie pour la ressource.
totaux de processus
Des limites par processus peuvent être définies pour le temps UC total, les
blocs d’E/S de disque et le délai de connexion pour une session de
connexion. Ces limites sont définies au niveau de la classe, mais
s’appliquent à chaque processus de la classe (chaque processus peuvent
utiliser ce délai). Ces valeurs de consommation sont cumulatives et
représentent donc la quantité totale associée à chaque ressource qui peut
être consommée par le processus au cours de sa durée de vie. Lorsqu’un
processus dépasse sa limite totale pour une ressource, le processus prend
fin. Le processus reçoit un signal SIGTERM et s’il le détecte et ne se
termine pas après une période de grâce de 5 secondes, il reçoit un signal
SIGKILL. Lorsqu’une session de connexion atteint 90 % de sa limite de
délai, un message d’avertissement est envoyé au terminal de contrôle pour
signaler à l’utilisateur que la session va prendre fin.
Gestion de la charge de travail
9-21
Partages cibles
Le pourcentage de consommation de la ressource cible (ou désirée) d’une classe est
déterminé par le nombre de partages dont il dispose pour la ressource. Les partages
indiquent la quantité d’une ressource dont peut disposer une classe, par rapport aux autres
classes de son niveau. Un pourcentage cible de classe pour une ressource correspond
simplement au nombre de partages divisé par le nombre de partages actifs dans son
niveau. Si des limites sont également utilisées, la cible est limitée à la plage [minimum,
maximum logiciel]. Si la cible calculée est en dehors de la plage, elle est affectée de la
limite supérieure/inférieure appropriée (voir Limites de ressource). Le nombre de partages
actifs correspond au nombre total de partages de toutes les classes contenant au moins un
processus actif. Du fait que le nombre de partages actifs est dynamique, la cible l’est aussi.
Si une classe est la seule classe active d’un niveau, sa cible correspond à 100 % de la
quantité de ressource disponible pour le niveau.
Supposons trois classes de superclasses actives A, B, et C dans le niveau 0,
avec des partages pour une ressource de 15, 10 et 5, respectivement. Les cibles sont :
target(A) = 15/30 = 50%
target(B) = 10/30 = 33%
target(C) = 5/30 = 17%
Si ultérieurement, la classe B devient inactive (aucun processus actif),
les cibles des classes A et C sont ajustées automatiquement :
target(A) = 15/20 = 75%
target(C) = 5/20 = 25%
Comme vous pouvez le constater, les partages représentent un pourcentage ajusté
automatiquement qui permet aux ressources allouées à une classe d’être réparties de
manière égale entre les autres classes ou d’être prises aux autres classes, lorsqu’il devient
actif/inactif.
Pour plus de souplesse, le nombre de partages d’une classe peut correspondre à un
nombre compris entre 1 et 65535. Des partages peuvent être définis pour les superclasses
et les sous–classes. Pour les superclasses, les partages sont relatifs à toutes les autres
superclasses actives du même niveau. Pour les sous–classes, les partages sont relatifs
à toutes les autres sous–classes actives de la même superclasse du même niveau. Les
partages d’une sous–classe d’une superclasse n’ont pas de relation avec les partages
d’une sous–classe d’une autre superclasse.
Dans certains cas, il peut être nécessaire de rendre la cible d’une classe indépendante
du nombre de partages actifs. Pour ce faire, définissez la valeur ”–” pour le nombre de
partages. Dans ce cas, la classe de la ressource n’est pas régulée, ce qui implique qu’elle
n’a pas de partages et que sa cible ne dépend pas du nombre de partages actifs. Sa cible
correspond à (ressource disponible pour le niveau – somme des minimaux de toutes les
autres classes du niveau). Cette cible, ou la consommation actuelle (qui est inférieure), est
issue de ce qui est disponible dans les autres classes du même niveau.
Supposons que les classes A, B, C et D aient des partages pour une ressources donnée,
qui correspondent à ”–”, 200, 150 et 100, respectivement. Toutes les classes sont actives
et la classe A consomme 50 % de la ressource :
target(A) = unregulated = 100%
target(B) = 200/450 * available = 44% * 50% = 22%
target(C) = 150/450 * available = 33% * 50% = 17%
target(D) = 100/450 * available = 22% * 50% = 11%
Du fait que la classe A n’est pas régulée et qu’elle consomme 50 % de la ressource
disponible, les autres classes ne disposent que de 50 % de la ressource et leurs cibles sont
calculées en fonction de ce pourcentage. Du fait que la classe A est toujours en dessous sa
cible (100 %), elle a toujours une priorité supérieure par rapport à toutes les autres classes
du même niveau qui ont atteint leur cible ou qui sont supérieures à leur cible (pour plus
d’informations, voir Description de la priorité des classes, page 9-26).
9-22
Concepts de gestion de système AIX – Système d’exploitation et unités
Remarque :
Ne pas réguler une classe pour une ressource ne revient pas à la mettre
dans un niveau supérieur. Les comportements suivants sont vrais pour une
classe non régulée (dans le même niveau) et ne sont pas vrais si la classe
est placée dans un niveau supérieur :
. Du fait que les partages sont définis pour chaque ressource, une classe peut être
dérégulée pour une ou plusieurs ressources et régulée pour d’autres.
. Les limites minimales des autres classes du même niveau sont respectées. Les
niveaux supérieurs ne respectent pas les minimaux définis dans les niveaux
inférieurs.
. Même en l’absence de limites minimales pour les classes avec des partages, la
consommation des classes non régulées dépend quelque peu des classes avec
des partages du fait qu’elles entrent en compétition pour obtenir de la ressource
disponible pour le niveau. Il est nécessaire de faire des tests pour identifier le
comportement avec une charge de travail donnée.
Si le nombre de partages n’est pas défini, la valeur par défaut ”–” est utilisée et la classe est
dérégulée pour la ressource. Notez que dans la première version de WLM, la valeur de
partage par défaut, si elle n’est pas définie, est 1.
Les partages sont définis pour chaque classe pour tous les types de ressources.
Les partages sont définis dans des strophes du fichier des partages. Par exemple :
shares
classname :
CPU
=
memory
=
diskIO
=
2
4
3
Limites de ressources
WLM utilise non seulement des partages pour définir des affectations de ressource,
mais permet également de définir des limites de ressource pour une classe. Les limites
de ressource permettent à l’administrateur de mieux contrôler l’affectation de ressources.
Ces limites sont définies sous forme de pourcentages et sont relatives à la quantité de
ressources disponible pour le niveau de la classe.
Il existe trois types de limites de régulation par pourcentage :
Minimum
Il s’agit de la quantité minimale de ressources qui peut être disponible pour
la classe. Si la consommation réelle de la classe est inférieure à cette
valeur, la classe est affectée d’une priorité d’accès supérieure à la
ressource. Les valeurs possibles sont comprises entre 0 et 100, 0 étant la
valeur par défaut (si non définie).
Soft Maximum Il s’agit de la quantité de ressource maximale qu’une classe consomme
lorsqu’il existe un conflit pour cette ressource. Si la consommation de la
classe est supérieure à cette valeur, la classe est affectée de la priorité la
plus basse dans son niveau. S’il n’existe pas de conflit pour la ressource
(avec des classes du même niveau), la classe peut consommer une
quantité de ressources illimitée. Les valeurs possibles sont comprises entre
1 et 100, 100 étant la valeur par défaut (si non définie).
Gestion de la charge de travail
9-23
Hard Maximum Il s’agit de la quantité de ressources maximale qu’une classe consomme
même lorsqu’il n’existe pas de conflit. Si la classe atteint cette limite, elle ne
peut pas consommer plus de la ressources tant que son pourcentage de
consommation ne tombe pas en dessous de la limite. Les valeurs possibles
sont comprises entre 1 et 100, 100 étant la valeur par défaut (si non
définie).
Les valeurs de limites de ressource sont définies dans le fichier des limites de ressources
par type de ressource dans les strophes de chaque classe. Les limites sont définies comme
un minimum dans la plage logicielle maximale, séparées par un trait d’union (–), les
espaces étant ignorés. Les valeurs maximales matérielles lorsqu’elles sont définies suivent
les valeurs maximales logicielles en étant séparées par un point–virgule (;). Chaque valeur
de limite est suivie par un symbole de pourcentage (%).
Voici des exemples d’utilisation des fichiers de règles :
• Si l’utilisateur Jean du groupe acct3 exécute /bin/vi, le processus est placé dans la
superclasse acctg.
• Si l’utilisateur Jeanne du groupe dev exécute /bin/emacs, le processus est placé dans la
superclasse devlt (correspondance d’ID de groupe), mais il n’est pas classé dans la
sous–classe editors, car l’utilisateur Jeanne est exclu de cette classe. Le processus est
placé dans devlt. Default
• Lorsqu’un administrateur DB démarre /usr/sbin/oracle avec l’ID utilisateur oracle et l’ID
de groupe dbm, pour servir la base de données DB1, le processus doit être classé dans
la superclasse Default. Le processus n’est affecté à la superclasse db1 que lorsqu’il
affecte _DB1 à son option.
Les limites sont définies pour tous les types de classes, par classe, dans les strophes du
fichier des limites. Par exemple :
shares
classname :
CPU
=
0%–50%;80%
memory =
10%–30%;50%
Dans cet exemple, aucune limite n’est définie pour les E/S de disque. En utilisant les
valeurs par défaut système, on obtient :
diskIO
=
0%–100%;100%
Tous les exemples précédents supposent que l’attribut d’héritage des superclasses et des
sous–classes décrites est affecté de la valeur yes. Autrement, les nouveaux processus
héritent simplement de la superclasse ou de la sous–classe de leur parent.
Les contraintes suivantes sont les seules que WLM place sur les valeurs des limites de
ressources.
• La limite minimum doit être inférieure ou égale à la limite logicielle maximum.
• La limite logicielle maximum doit être inférieure ou égale à la limite matérielle maximum.
• La somme des minimaux de toutes les superclasses d’un niveau ne peut pas être
supérieure à 100.
• La somme des minimaux de toutes les sous–classes d’un niveau ne peut pas être
supérieure à 100.
Lorsqu’une classe avec une limite de mémoire matérielle atteint sa limite et demande plus
de pages, l’algorithme de remplacement de page VMM est démarré et ”vole” des pages
dans la classe limitée en ramenant ainsi le nombre de pages sous la limite matérielle
maximum avant de fournir de nouvelles pages. Ce comportement est correct, mais
l’augmentation des activités de pagination, qui peut se produire même lorsqu’il existe un
grand nombre de pages libres, affecte les performances générales du système. Des limites
de mémoire minimum pour les autres classes sont recommandées avant d’imposer un
maximum de mémoire matérielle pour une classe.
9-24
Concepts de gestion de système AIX – Système d’exploitation et unités
Du fait que les classes en dessous de leur minimum ont la priorité la plus haute dans leur
niveau, la somme des minimaux doit correspondre à un niveau raisonnable, en fonction des
besoins en ressources des autres classes du même niveau.
La contrainte de la somme des limites minimum dans un niveau étant égale ou inférieure à
100, implique qu’une classe dans le niveau de priorité le plus haut est toujours autorisée à
recevoir des ressources jusqu’à hauteur de sa limite minimum. WLM ne garantit pas que la
classe atteindra sa limite minimum. Cela dépend de la manière dont les processus de la
casse utilisent leurs ressources et des autres limites en vigueur. Par exemple, une classe
peut ne pas atteindre sa limite de temps UC minimum, car elle ne peut pas obtenir une
quantité de mémoire suffisante.
Pour la mémoire physique, la définition d’une limite de mémoire minimum offre une
protection pour les pages de mémoire des processus de classes (au moins pour ceux qui
figurent au niveau de priorité le plus élevé). Une classe ne doit pas avoir de pages volées
lorsqu’elle se trouve au–dessous de sa limite minimum, à moins que toutes les classes
actives ne soient au–dessous de leur limite minimum et que l’une d’entre elles demande
des pages supplémentaires. Une classe du niveau le plus élevé ne doit jamais avoir de
pages volées lorsqu’elle se trouve au–dessous de son minimum. La définition de limites
minimum de mémoire pour une classe de travaux interactifs aide à assurer que leurs pages
n’auront pas toutes été volées entre des activations consécutives (même lorsque la
mémoire est restreinte) et accélère le temps de réponse.
Attention : L’utilisation inappropriée de limites maximales matérielles peut avoir un impact
significatif sur les performances du système ou des applications. Du fait qu’en définissant
des limites matérielles, des ressources peuvent ne pas être utilisées, dans la plupart des
cas, il est préférable d’utiliser des limites maximales logicielles. Les limites maximales
matérielles peuvent être utilisées pour limiter la consommation d’un niveau supérieur pour
rendre disponible une ressource à un niveau inférieur, mais il est préférable de placer les
applications qui ont besoin de ressources dans un niveau supérieur.
Depuis la version AIX 5.2, des limites totales peuvent être définies dans le fichier des limites
avec les valeurs et les unités figurant dans le tableau suivant :
Table 2. Limites de ressources pour Workload Manager
Ressource
Unités
autorisées
Unité par
défaut
Valeur
maximale
Valeur
minimale
totalCPU
s, m, h, d, w
s
2 30 – 1s
10 s
KB, MB, TB,
PB, EB
KB
(2 63 – 1) *
1 MB
totalConnect
Time
s, m, h, d, w
s
2 63 – 1 s
5m
totalProcesses
–
–
2 63 – 1
2
–
2 63 – 1
2
–
2 63 – 1
1
totalDiskIO
totalThreads
totalLogins
Remarque :
–
–
512/1 024 KB
Les spécificateurs d’unité ne tiennent pas compte de la casse. s =
secondes, m = minutes, h = heures, d = jours, w = semaine, KB =
kilo–octets, MK = mégaoctets, etc.
Exemple de strophe de limites :
BadUserClass:
totalCPU = 1m
totalConnectTime = 1h
Le nombre total de limites peut être défini en utilisant n’importe quelle valeur du tableau
ci–dessus avec les restrictions suivantes :
• Si définie, la valeur totalThreads doit correspondre au minimum à la valeur de
totalProcesses.
Gestion de la charge de travail
9-25
• Si totalThreads est défini et que totalProcesses ne l’est pas, la limite de totalProcesses
correspond à la valeur de totalThreads.
Les limites totales peuvent être définies au niveau de la superclasse et de la sous–classe.
Lors de la vérification des limites, la limite de la sous–classe est vérifiée avant la limite de la
superclasse. Si les deux limites sont définies, la limite la plus basse est utilisée. Si la limite
de la sous–classe est supérieure à la limite de la superclasse associée, un avertissement
est envoyé lorsque la configuration est chargée. Cela est significatif pour les limites totales
de classe du fait que la limite absolue (et non par rapport à la superclasse) et une
sous–classe peuvent consommer toutes les ressources disponibles pour la superclasse. Si
non définie, la valeur par défaut de toutes les limites totales est ”–”, ce qui correspond à
aucune limite. Par défaut, la comptabilité et la régulation de total de classes et de processus
sont activées lorsque WLM est actif. L’option –T [class|proc] de la commande wlmcntrl
peut être utilisée pour désactiver la comptabilité et la régulation.
Description de la priorité de classe
WLM alloue des ressources aux classes en affectant une priorité à chaque classe de
chaque ressource. La priorité d’une classe est dynamique et repose sur le niveau, les
partages, les limites et la consommation actuelle de la classe. A tout moment, la classe
ou les classes ayant la priorité la plus haute ont un accès préférentiel aux ressources.
Au niveau le plus haut, les niveaux représentent les plages non entrelacées de la priorité
de classe. Les classes du niveau 0 ont toujours une priorité supérieure à celle des clases
du niveau 1 (sauf si supérieure à la valeur maximale matérielle)
Lors de la détermination de la priorité d’une classe, WLM utilise ses contraintes avec
la priorité suivante (de la plus haute vers la plus basse) :
limites matérielles
Si la consommation de la classe est supérieure à la limite maximale
matérielle d’une ressource, la classe est affectée de la priorité la plus basse
et ne peut pas accéder à la ressource tant que son niveau de
consommation ne tombe pas en dessous de cette limite.
niveau
En l’absence de limites matérielles, une priorité de classe est limitée par
les priorités minimale et maximale autorisées pour son niveau.
limites logicielles
Si la consommation de la classe est inférieure à la valeur minimale des
limites maximales logicielles, la classe est affectée de la priorité la plus
haute dans le niveau. Si la consommation de la classe est supérieure à la
valeur maximale logicielle, la classe est affectée de la priorité la plus basse
du niveau.
partages
Les partages permettent de calculer les cibles de consommation de classe
pour chaque ressource. La priorité de classe augmente alors que la
consommation de classe tombe sous la valeur cible, et diminue alors que la
consommation de la classe est supérieure à la valeur cible. Notez que les
limites logicielles ont une plus haute priorité et que la priorité d’une classe
est déterminée en fonction de ces limites, lorsque nécessaire.
Même si les partages et les limites peuvent être utilisés pour chaque classe et pour chaque
ressource, les résultats sont plus prévisibles si l’un ou l’autre est utilisé pour chaque classe.
9-26
Concepts de gestion de système AIX – Système d’exploitation et unités
Groupes de ressources
WLM utilise des groupes de ressources (ou rsets) pour restreindre les processus dans une
classe à un sous–ensemble des ressources physiques du système. Dans WLM, les
ressources physiques gérées sont la mémoire et les processeurs. Un groupe de ressources
valide est constitué de la mémoire et d’au moins un processeur.
En utilisant SMIT ou Web–based System Manager, un administrateur système peut définir
et nommer des groupes de ressources contenant un sous–ensemble des ressources
disponibles sur le système. Ensuite, en utilisant les interfaces d’administration WLM,
l’utilisateur root ou un administrateur de superclasse désigné peut utiliser le nom du groupe
de ressources sous la forme de l’attribut rset d’une classe WLM. Ensuite, chaque
processus affecté à la classe WLM est envoyé uniquement à l’un des processeurs du
groupe de ressources, en séparant efficacement les charges de travail de la ressource UC.
Tous les systèmes actuels ont uniquement un domaine de mémoire partagé par tous les
groupes de ressources. En conséquence, cette méthode ne sépare pas physiquement les
charges de travail en mémoire.
Registre Rset
Les services de registre rset permettent à l’administrateur système de définir et de nommer
des groupes de ressources pour permettre à d’autres utilisateurs ou applications de les
utiliser. Pour diminuer les risques de conflits de noms, le registre prend en charge un
schéma d’appellation à deux niveaux. Le nom du groupe de ressources se présente sous
la forme espace_nom / nom_rset. espace_nom et nom_rset peuvent comporter jusqu’à
255 caractères, tiennent compte de la casse et peuvent contenir des majuscules, des
minuscules, des chiffres, le caractère souligné et des points (.). L’ espace de nom de sys
est réservé par le système d’exploitation et utilisé pour les définitions rset qui représentent
les ressources du système.
Les noms de définition rset sont uniques dans l’espace de nom de registre. Si vous ajoutez
au registre une définition rset dont le nom correspond à une définition rset existante, la
définition existante est remplacée par la nouvelle définition en affectant l’autorisation et le
privilège appropriés. Seul l’utilisateur root peut créer, modifier et supprimer des groupes de
ressources et mettre à jour la base de données in–core rset à l’aide de SMIT ou
Web–based System Manager.
Chaque définition rset a ses propres propriétaires (ID utilisateur), groupe (ID de groupe) et
autorisations d’accès. Ces données sont spécifiques lors de la création de la définition rset
et existent pour contrôler les accès. Comme c’est le cas pour les fichiers, des autorisations
d’accès distinctes existent pour le propriétaire, le groupe et les autres qui définissent si des
autorisations de lecture et/ou d’écriture ont été accordées. L’autorisation de lecture permet
d’extraire une définition rset alors que l’autorisation d’écriture permet de modifier ou de
supprimer une définition rset.
Les définitions rset définies par l’administrateur système sont stockées dans le fichiers
de strophe /etc/rsets. Le format de ce fichier n’est pas décrit et les utilisateurs doivent
manipuler les définitions rsets via SMIT ou les interfaces Web-based System Manager
pour éviter tout problème de compatibilité ultérieur si le format de fichier est modifié.
Comme c’est le cas avec les définitions de classes WLM, les définitions rset doivent être
chargées dans les structures de données du noyau pour que WLM puisse les utiliser.
Au lieu de donner une longue définition des groupes de ressources et d’expliquer comment
les créer depuis des blocs de base appelés RAD système (Resource Access Domains).
Pour plus d’informations sur ce qu’est un groupe de ressources et la manière d’en créer un,
reportez–vous à la section Creating a Resource Set du document AIX 5L Version 5.3
System Management Guide: Operating System and Devices
Gestion de la charge de travail
9-27
Configuration de WLM
Les définitions de classe, les attributs de classe, les partages et les limites et les règles
d’affectation de classe automatique peuvent être entrés avec Web–based System Manager,
SMIT ou l’interface de ligne de commande WLM. Ces définitions et règles sont stockées
dans des fichiers texte qui peuvent être également créés ou modifiés dans un éditeur de
texte.
Ces fichiers (appelés fichiers de propriétés WLM) sont stockés dans les sous–répertoires
de /etc/wlm. Un groupe de fichiers décrivant les superclasses et leurs sous–classes
définissent une configuration WLM. Les fichiers de la configuration WLM Config sont
stockés dans /etc/wlm/Config. Ce répertoire contient les définitions des paramètres WLM
des superclasses. Les fichiers s’appellent description, classes, shares, limits et rules.
Ce répertoire peut également contenir des sous–répertoires avec le nom des superclasses
où sont stockées les définitions des sous–classes. Par exemple, pour la superclasse Super
de la configuration WLM Config, le répertoire /etc/wlm/Config/Super contient les fichiers
de propriétés des sous–classes de la superclasse Super. Les fichiers s’appellent
description, classes, shares, limits et rules.
Une fois que l’administrateur système a défini une configuration WLM, la configuration peut
être activée à l’aide de Web–based System Manager, du raccourci smit wlmmanage ou de
la commande wlmcntrl.
Vous pouvez définir plusieurs groupes de fichiers de propriétés qui définissent différentes
configurations de gestion de la charge de travail. Ces configurations sont généralement
stockées dans les sous–répertoires de /etc/wlm. Un lien symbolique /etc/wlm/current
pointe vers le répertoire qui contient les fichiers de configuration en cours. Ce lien est mis
à jour par la commande wlmcntrl au démarrage de WLM, avec un groupe défini de fichiers
de configuration.
La création d’une configuration WLM est décrite dans la section Configure Workload
Manager (WLM) to Consolidate Workloads du document AIX 5L Version 5.3 System
Management Guide: Operating System and Devices. Cette section décrit les concepts
et les caractéristiques de chaque phase de la procédure.
Identification des besoins des applications
La première étape de la définition d’une configuration repose sur l’identification des besoins
des utilisateurs et informatiques ainsi que sur les applications du système, leurs besoins en
ressources et les besoins de votre entreprise (par exemple, quelles tâches sont importantes
et quelle est celle qui doit recevoir la priorité la plus basse). A partir de ces informations,
vous pouvez définir les superclasses, puis les sous–classes.
La définition des priorités dépend des fonctions que WLM dessert dans votre organisation.
Dans le cas de consolidation de serveurs, il se peut que vous connaissiez déjà les
applications, les utilisateurs et leurs besoins en ressources ; vous pourrez alors ignorer ou
raccourcir certaines des étapes.
WLM vous permet de classer les processus par utilisateur ou groupe, application, type,
étiquette ou selon une combinaison de ces attributs. Comme WLM régule l’utilisation des
ressources entre les classes, groupez les applications et les ressources ayant les mêmes
modèles d’utilisation des ressources dans les mêmes classes. Par exemple, il peut s’avérer
judicieux de séparer les travaux interactifs, qui généralement consomment très peu de
temps CPU mais exigent des temps de réponse rapides, des travaux de traitement par lots,
qui consomment beaucoup de CPU et de mémoire. La situation est identique dans un
environnement de bases de données où vous devez séparer le trafic de type OLTP des
requêtes d’exploration de données, qui représentent une lourde charge.
9-28
Concepts de gestion de système AIX – Système d’exploitation et unités
Cette étape s’effectue à l’aide des interfaces d’administration de WLM, Web–based System
Manager, SMIT ou interface à ligne de commande. Pour les premières occasions, il est
probablement préférable d’utiliser Web–based System Manager ou SMIT. Ces outils vous
guideront dans les étapes de création de votre première configuration WLM, dont la
définition des superclasses et de leurs attributs. Lors de la première passe, vous pouvez
définir certains des attributs et laisser les autres à leur valeur par défaut. Il en va de même
des partages de ressources et des limites. Toutes ces caractéristiques peuvent être
modifiées dynamiquement par la suite.
Vous pouvez alors démarrer WLM en mode passif, vérifier votre classement et commencer
à consulter les trames d’utilisation des ressources de vos applications.
Vérifiez votre configuration à l’aide de la commande wlmcheck ou des menus
correspondants de SMIT ou de Web-based System Manager, puis lancez WLM en mode
passif sous la nouvelle configuration. WLM classera tous les processus existants (et tous
ceux créés par la suite) et commencera à compiler des statistiques sur le CPU, la mémoire
et l’utilisation des E/S disque des différentes classes. Il ne tentera pas de réguler cette
utilisation des ressources.
Vérifiez que les différents processus sont classés dans la bonne classe, tel que cela a
été prévu par l’administrateur système (à l’aide du paramètre –o de la commande ps).
Si certains processus ne sont pas classés conformément à vos attentes, vous pouvez
modifier vos règles d’affectation ou définir le bit d’héritage pour certaines des classes (si
vous souhaitez que les nouveaux processus restent dans la même classe que leur parent)
et mettre WLM à jour. Vous pouvez répéter ce processus jusqu’à ce que ce premier niveau
de classification vous convienne (superclasses).
L’exécution de WLM en mode passif et sa régénération (toujours en mode passif) entraîne
peu de risques, une faible surcharge système et peut être lancée en toute sécurité sur un
système de production sans perturber le fonctionnement normal du système. L’activation
et la régénération de WLM sont effectuées avec la commande wlmcntrl, appelée soit
directement, soit via SMIT ou Web-based System Manager.
L’exécution de WLM en mode passif permet de collecter des statistiques à l’aide de la
commande wlmstat. wlmstat peut être utilisée à intervalles réguliers pour afficher
l’utilisation des ressources par classe sous forme de pourcentage du total des ressources
disponibles, pour les superclasses. Ceci vous permet de surveiller votre système pendant
des périodes prolongées pour vérifier l’utilisation des ressources par vos principales
applications.
Définition des niveaux, des partages et des limites
En utilisant les données collectées en exécutant WLM en mode passif et en fonction de vos
objectifs professionnels, déterminez le nombre de niveaux à associer à chaque superclasse
et quel partage pour chaque ressource doit être affecté aux diverses classes. Pour
certaines classes, vous pouvez définir des limites minimales et maximales. Ajustez les
partages et le nombre de niveaux pour atteindre vos objectifs d’allocation de ressources.
Réservez des limites pour les cas qui ne peuvent pas être résolus qu’avec des partages.
En outre, vous pouvez être amené à ajouter des sous–classes.
Dans certains cas, il peut être nécessaire d’utiliser les limites minimales et maximales.
Ajustez les partages et les numéros de niveau pour parvenir à vos objectifs en matière
d’affectation des ressources. Réservez les limites aux cas que vous ne pouvez pas
résoudre avec les seuls partages.
• Utilisez les limites minimales pour les applications qui ont en général une faible utilisation
des ressources mais ont besoin d’un temps de réponse court lorsqu’elles sont activées
par un événement externe. L’un des problèmes auxquels sont confrontés les travaux
interactifs lorsque la mémoire devient insuffisante est que leurs pages leur sont retirées
pendant les périodes d’inactivité. Une limite de mémoire minimale peut servir à protéger
certaines des pages des travaux interactifs si leurs classe est dans le niveau 0.
Gestion de la charge de travail
9-29
• Faites appel aux limites maximales pour restreindre certains travaux de faible priorité
consommant beaucoup de ressources. Sauf si vous partitionnez vos ressources système
pour d’autres raisons, une limite ferme prend son sens généralement pour une ressource
non renouvelable telle que la mémoire. Ceci est dû au temps nécessaire à l’écriture de
données hors de l’espace de pagination lorsqu’une classe de priorité plus élevée a
besoin de pages que la première classe aurait utilisée. Pour l’utilisation du CPU, vous
pouvez utiliser des niveaux ou des maximums souples pour garantir qu’une classe de
priorité plus élevée se voie affecter immédiatement du temps CPU.
Lorsque vous créez et ajustez les paramètres des sous–classes, vous pouvez actualiser
WLM uniquement pour les sous–classes d’une superclasse qui n’affectent pas les
utilisateurs et les applications des autres superclasses, jusqu’à ce que le comportement
du système vous convienne.
Vous pouvez également définir d’autres configurations avec des paramètres différents
en fonction de vos besoins. Dans ce cas, vous pouvez gagner du temps en copiant et
en modifiant les configurations existantes.
Ajustement de la configuration
Maintenant, vous êtes prêt à démarrer WLM en mode actif. Contrôlez le système avec
la commande wlmstat, vérifiez que la régulation effectuée par WLM correspond à vos
objectifs et assurez–vous qu’il ne supprime pas des ressources pour des applications et
qu’il n’en affecte pas plus à d’autres. Si tel est le cas, ajustez les partages et actualisez
WLM.
Lorsque vous contrôlez et ajustez les partages, les limites et le nombre de niveaux,
déterminez si vous voulez déléguer l’administration des sous–classes ou de toutes les
superclasses. L’administrateur peut ensuite contrôler et définir les partages de
sous–classes, les limites et le nombre de niveaux.
L’administrateur de chaque superclasse peut répéter ce processus pour les sous–classes
de chaque superclasse. La seule différence est qu’il n’est pas possible de lancer WLM en
mode passif au niveau de la sous–classe seulement. La configuration et l’optimisation de la
sous–classe doivent être effectuées lorsque WLM est en mode actif. Pour éviter tout impact
sur les utilisateurs et les applications de la superclasse, vous pouvez lancer le numéro de
niveau, ainsi que les partages et les limites des sous–classes avec leur valeur par défaut
(’–’ (tiret) pour les partages, 0 % pour les minimums, et 100 % pour les maximums souples
et fermes). Avec ces options, WLM ne régulera pas l’affectation de ressources entre les
sous–classes.
9-30
Concepts de gestion de système AIX – Système d’exploitation et unités
API de Workload Manager
Les applications peuvent utiliser les API WLM, un groupe de sous–routines de la
bibliothèque /usr/lib/libwlm.a, pour exécuter toutes les tâches qu’un administrateur WLM
peut effectuer à l’aide des commandes WLM, notamment :
• créer des classes ;
• modifier des classes ;
• supprimer des classes ;
• affecter manuellement des process à des classes ;
• extraire des statistiques WLM.
De plus, la routine wlm_set_tag permet à une application de définir l’étiquette (tag) d’une
application et de spécifier si cette étiquette doit être héritée par les process enfants au
niveau de fork ou d’exec. La bibliothèque permet la prise en charge d’applications 32 ou
64 bits multi–routines.
Etiquette d’application
Cette étiquette est une chaîne de caractères pouvant servir de critère pour la classification
automatique des process (à l’aide du fichier rules). Elle offre un critère de classification
défini par application, en complément des critères définis par le système tels que user,
group, application et type.
Lorsqu’un process d’application définit son étiquette, il est immédiatement reclassé en
fonction des règles de superclasse et de sous–classe en vigueur pour la configuration WLM
active. WLM vérifie alors les règles d’affectation, recherchant une correspondance à partir
de tous les attributs de process, y compris la nouvelle étiquette.
Pour avoir un effet, cette étiquette doit apparaître dans une ou plusieurs des règles
d’affectation. Cela signifie que le format et l’utilisation des différentes étiquettes par chaque
application doivent être clairement indiqués dans la documentation d’administration de ces
applications et être connues des administrateurs WLM, afin qu’ils puissent exploiter les
différentes valeurs des étiquettes dans leurs règles d’affectation en vue de faire la
distinction entre les différentes instances de la même application.
Le jeu de caractéristiques des process de l’application dont ils ont besoin pour classer ces
process pouvant varier selon les utilisateurs, il est conseillé de faire en sorte que
l’application fournisse un jeu d’attributs de configuration ou d’exécution pouvant servir à
constituer l’étiquette. L’administrateur de l’application aura ainsi la possibilité de spécifier à
l’application le format de l’étiquette. Les attributs susceptibles d’être utilisés et la syntaxe
servant à spécifier le format de l’étiquette WLM dépendent de l’application et sont sous la
responsabilité de son fournisseur.
Par exemple, une instance d’un serveur de bases de données est capable de déterminer
sur quelle base de données elle travaille (db_name) et via quel port TCP (port_num) un
utilisateur donné est connecté. Les administrateurs peuvent avoir les priorités suivantes :
• créer différentes classes pour les process accédant à différentes bases de données,
afin de donner à chaque classe des droits à ressource distincts ;
• séparer les process desservant des demandes distantes d’origines différentes et
employer le numéro de port comme attribut de classification ;
• créer une superclasse pour chaque base de données et une sous–classe par numéro
de port dans chaque superclasse.
Pour répondre à ces différents besoins, une solution consiste à spécifier le contenu et le
format de l’étiquette. Dans cet exemple, nous supposons que l’étiquette peut être transmise
à l’application dans un fichier de configuration ou un paramètre d’exécution tel que
WLM_TAG=$db_name ou WLM_TAG=$db_name_$port_num.
Gestion de la charge de travail
9-31
Lors de la définition de cette étiquette, une application peut spécifier si ses enfants en
hériteront, afin que tous les process issus d’une instance particulière d’une application
puissent être classés dans la même classe. Dans la plupart des cas, l’étiquette d’application
sert à définir l’étiquette d’héritage.
L’exemple suivant montre comment il est possible d’utiliser les étiquettes d’application.
Dans cet exemple, l’étiquette de la base de données est identique au nom de la base de
données. Deux instances du serveur travaillant sur des bases de données différentes
définiront deux étiquettes distinctes, db1 et db2.
L’administrateur système peut créer deux classes distinctes, dbserv1 et dbserv2, puis
classer les deux serveurs de bases de données (ainsi que leurs enfants, en cas de recours
à l’héritage d’étiquette) dans ces classes à l’aide des étiquettes. Il est alors possible de
donner à chaque classe des droits à ressource distincts, en fonction des objectifs de
l’entreprise.
Les règles d’affectation correspondantes seront semblables à ceci :
* class
*
dbserv1
dbserv2
resvd
user
group
application
type
–
–
–
–
dbadm
dbadm
/usr/sbin/dbserv
/usr/sbin/dbserv
tag
–
–
db1
db2
API de gestion de classe
L’API WLM permet aux applications de :
• demander les noms et les caractéristiques des classes existant dans une configuration
WLM donnée (wlm_read_classes) ;
• créer une nouvelle classe pour une configuration WLM particulière, définir les valeurs des
différents attributs de la classe (rang, héritage, etc.) ainsi que les partages et limites des
ressources gérées par WLM, telles que le CPU, la mémoire physique et les E/S par blocs
(wlm_create_class) ;
• modifier les caractéristiques d’une classe existant dans un configuration WLM
particulière, notamment les attributs de la classe et ses partages et limites de ressources
(wlm_change_class) ;
• supprimer une classe existante d’une configuration donnée (wlm_delete_class).
Les modifications ne sont appliquées qu’au fichier de propriétés de la configuration WLM
spécifiée. Il est également possible, en indiquant une chaîne vide comme nom de
configuration, de n’appliquer les modifications qu’aux classes chargées en mémoire
centrale, ce qui entraîne une mise à jour immédiate de l’état de la configuration active.
Pour effectuer des appels à l’API, l’appelant doit disposer des mêmes droits que pour une
exécution à partir des interfaces à ligne de commande, SMIT et Web-based System
Manager :
• tout utilisateur peut lire les noms et les caractéristiques de la classe,
• seul l’utilisateur root peut créer, modifier ou supprimer des superclasses,
• seul root ou des administrateurs de superclasse désignés (attribut de superclasse
adminuser ou admingroup) peuvent créer, modifier ou supprimer des sous–classes d’une
superclasse donnée.
Lorsque l’administration de WLM est assurée simultanément par les administrateurs de
WLM via les outils à ligne de commande et d’administration ainsi que par des applications
via l’API, il convient d’être particulièrement vigilant. Les deux interfaces partagent le même
espace de noms pour les noms des superclasses et des sous–classes, et le nombre total
de superclasses et de sous–classes.
9-32
Concepts de gestion de système AIX – Système d’exploitation et unités
De surcroît, lorsque l’API modifie directement les données WLM en mémoire centrale
(en créant de nouvelles classes par exemple), les administrateurs WLM n’en sont avertis
que lorsqu’ils voient apparaître des classes qu’ils n’ont pas créées dans le résultat de
commandes telles que wlmstat. Pour éviter tout conflit susceptible de perturber les
applications utilisant cette API lorsque l’administrateur met à jour WLM, les classes
créées via l’API qui ne sont pas définies dans les fichiers de propriétés de WLM ne sont
pas automatiquement retirées des données en mémoire centrale. Elles restent en vigueur
jusqu’à ce qu’elles soient explicitement supprimées par la routine wlm_delete_class ou
par une exécution de la commande rmclass (appelée par l’administrateur système soit
directement, soit via SMIT ou Web-based System Manager).
API de gestion de WLM
L’API de WLM permet également aux applications de :
• demander ou modifier le mode de fonctionnement de WLM, à l’aide de la fonction
wlm_set ;
• demander l’état actuel de WLM ;
• arrêter WLM ;
• basculer du mode actif au mode passif et vice versa ;
• activer et désactiver la liaison rset ;
• démarrer ou mettre à jour WLM avec la configuration en cours ou une autre,
à l’aide de la routine wlm_load ;
• affecter un process ou un groupe de process à une classe, à l’aide de la routine
wlm_assign.
L’API doit avoir le même niveau de droits que les commandes de l’interface à ligne
de commande wlmcntrl et wlmassign :
• Tout utilisateur peut demander l’état de WLM.
• Seul root peut changer le mode de fonctionnement de WLM.
• Seul root peut mettre à jour ou actualiser une configuration complète.
• root ou un administrateur de superclasse autorisé (adminuser ou admingroup) peut
mettre à jour WLM en ce qui concerne les sous–classes d’une superclasse donnée.
• root, un utilisateur autorisé (spécifié à l’aide de authuser ou de authgroup), ou un
administrateur autorisé de superclasse (adminuser ou admingroup) peut affecter
des process à une superclasse ou une sous–classe. Reportez–vous à wlmassign
pour plus de détails.
API de statistiques de WLM
Les routines de l’API de WLM et wlm_get_bio_stats permettent aux applications d’accéder
aux statistiques de WLM affichées par les commandes wlmstat.
API de classification de WLM
La routine wlm_check permet à l’utilisateur de vérifier les définitions de classes et les
règles d’affectation d’une configuration WLM. La routine API wlm_classify permet à une
application de déterminer la classe dans laquelle un processus avec un groupe d’attributs
défini doit être placé.
Compatibilité binaire
Afin d’assurer une compatibilité binaire en cas de changements ultérieurs des structures de
données, chaque appel à l’API se voit transmettre comme paramètre un numéro de version
qui permettra à la bibliothèque de déterminer avec quelle version des structures de
données l’application a été bâtie.
Gestion de la charge de travail
9-33
Commandes WLM
WLM dispose de commandes qui permettent à l’administrateur système de :
• créer, modifier et supprimer des superclasses et des sous–classes en utilisant les
commandes mkclass, chclass et rmclass. Ces commandes mettent à jour les classes,
partages et limites du fichier.
• Utilisez la commande wlmcntrl pour démarrer, arrêter et mettre à jour WLM.
• Vérifier les fichiers de propriétés WLM d’une configuration et déterminer la classe
(superclasse et sous–classe) à laquelle est affecté un processus avec un groupe
d’attributs donné en utilisant la commande wlmcheck.
• Contrôler l’utilisation des ressources par classe à l’aide de la commande wlmstat
(ASCII). La majorité des outils de contrôle des performances, tels que ceux démarrés
par les commandes svmon et topas, ont des extensions pour prendre en compte les
classes WLM et fournissent des statistiques sur les classes et les niveaux en utilisant de
nouvelles options de ligne de commande.
• Les options de la commande ps permettent à l’utilisateur d’afficher la classe à laquelle
appartiennent un processus et son option d’application. La commande ps permet
également de lister tous les processus qui appartiennent à une superclasse ou
sous–classe.
• Il n’existe pas d’interface de ligne de commande pour gérer les règles d’affectation. Vous
devez utiliser les outils d’administration SMIT ou Web–based System Manager ou un
éditeur de texte.
Exemple de classification, de règles et de limites WLM
Il existe plusieurs méthodes pour classer un processus et ces méthodes fonctionnent toutes
simultanément. Un algorithme de première correspondance vertical est utilisé pour fournir
une souplesse de configuration maximale. Vous pouvez organiser le regroupement des
processus par utilisateur avec des cas spéciaux pour les programmes portant un certain
nom, par nom de chemin avec des cas spéciaux pour certains utilisateurs et en fonction
d’autres arrangements.
Exemples d’affectation de règles
Voici un exemple de fichier de règles de haut niveau pour la configuration Config
(/etc/wlm/Config/fichier de règles) :
* Ce fichier contient les règles utilisées par WLM pour
* affecter un processus à une superclasse
*
* class resvd user
group
application
type tag
db1
–
–
–
/usr/bin/oracle*
_DB1
db2
–
–
–
/usr/bin/oracle*
_DB2
devlt
–
–
dev
–
–
–
VPs
–
bob,ted
–
–
–
–
acctg
–
–
acct*
–
–
–
System
–
root
–
–
–
–
Default –
–
–
–
–
–
9-34
Concepts de gestion de système AIX – Système d’exploitation et unités
Voici un exemple de fichier règles pour la superclasse devlt dans
/etc/wlm/Config/devlt/fichier de règles :
* Ce fichier contient les règles utilisées par WLM pour
* affecter un processus à une sous–classe de la
* superclasse devlt
*
* class resvd user
group
application
type tag
hackers
–
jim,liz
–
–
–
hogs
–
–
–
–
64bit+plock
editors
–
!sue
–
/bin/vi,/bin/emacs
–
build
–
–
–
/bin/make,/bin/cc
–
Default
–
–
–
–
–
Remarque :
–
–
–
–
–
L’astérisque (*) est le caractère de commentaire utilisé dans le fichier
des règles.
Voici des exemples d’utilisation de ce fichier de règles : Tous les exemples suivants
supposent que l’attribut d’héritage des superclasses et des sous–classes décrites est
affecté de la valeur yes. Si l’héritage était activé, les nouveaux processus hériteraient
de la superclasse ou de la sous–classe de leurs processus parents.
• Si l’utilisateur Jean du groupe acct3 exécute /bin/vi, le processus est placé
dans la superclasse acctg.
• Si l’utilisateur Jeanne du groupe dev exécute /bin/emacs, le processus est placé
dans la superclasse devlt (correspondance d’ID de groupe), mais il n’est pas classé
dans la sous–classe editors, car l’utilisateur Jeanne est exclu de cette classe.
Le processus est placé par défaut dans devlt.
• Lorsqu’un administrateur de base de données avec l’ID utilisateur oracle et l’ID
de groupe dbm démarre /usr/sbin/oracle pour servir la base de données DB1,
le processus doit être classé dans la superclasse Default. Le processus n’est affecté
à la superclasse db1 que lorsqu’il affecte _DB1 à son option.
Exemples de partages et de limites
Supposons que les classes A, B, C et D aient les parages 3, 2, 1 et 1, respectivement.
Si les classes A, C et D sont actives, les cibles calculées sont :
target(A) = 3/5 = 60%
target(C) = 1/5 = 20%
target(D) = 1/5 = 20%
Si lors du test, il s’avère que les applications de la classe A fonctionnent correctement
lorsqu’elles sont autorisées à utiliser 50 % de la ressource, il peut être préférable de fournir
les 50 % restant de la ressource aux autres classes. Cela peut être effectué en fournissant
à la classe A un maximum logiciel de 50 % pour la ressource. Du fait que la cible calculée
actuelle 60 % est au–dessus de cette limite, elle est ramenée à la valeur logicielle
maximum. Dans ce cas, la consommation cible ou actuelle (selon la plus basse des deux)
de la classe A est soustraite de la quantité de ressource disponible. Du fait que la classe a
désormais une cible contrainte par sa limite (et non ses partages), les partages de la classe
sont également soustraits du nombre de partages actifs. En supposant que la
consommation de la classe A est de 48 %, les cibles sont maintenant :
target(A) = 3/5 = 60%, softmax = 50, = 50%
target(C) = 1/2 * (100 – 48) = 26%
target(D) = 1/2 * (100 – 48) = 26%
Un peu plus tard, toutes les classes peuvent devenir actives et les cibles sont là encore
ajustées automatiquement :
target(A) = 3/7 = 42%
target(B) = 2/7 = 28%
target(C) = 1/7 = 14%
target(D) = 1/7 = 14%
Gestion de la charge de travail
9-35
Exemple avec des limites d’UC
L’exemple suivant examine l’allocation d’UC, en supposant que chaque classe consomme
toute l’UC qui lui est fournie.
Les classes A et B sont dans le même niveau. Les limites d’UC de A sont [30 % – 100 %].
Les limites d’UC de B sont [20 % – 100 %]. Lorsque les deux classes sont actives et
qu’elles utilisent suffisamment d’UC, WLM vérifie qu’elles obtiennent leurs pourcentages
minimum de chaque seconde (moyenne de plusieurs secondes). Ensuite WLM distribue les
cycles UC restants en fonction des valeurs de partages cibles UC.
Si les partages cibles UC de A et B correspondent respectivement à 60 % et 40 %,
l’utilisation de l’UC pour A et B se stabilise respectivement à 60 % et 40 %.
La troisième classe C est ajoutée. Cette classe est un groupe de travaux UC et doit être
exécutée avec la moitié du temps (ou plus) UC disponible. La classe a les limites [20% –
100%] et les partages cibles d’UC 100 %. Si C se trouve dans le même niveau que A et B,
quand C démarre, l’allocation d’UC de A et B diminue franchement et les trois classes se
stabilisent à 30 %, 20 % et 50 %, respectivement. Dans ce cas, leurs cibles correspondent
également au minimum de A et B.
Un administrateur système peut décider d’empêcher les travaux par lot de consommer
50 % de l’UC lorsque d’autres travaux, avec une priorité supérieure éventuellement, sont
également actifs. Dans le cas de l’exemple précédent, C est placé dans le niveau de priorité
le plus bas. C reçoit le temps UC qui reste après que A et B ont reçu le temps UC qui leur
est nécessaire. Dans l’exemple ci–dessus, C ne reçoit aucun temps UC, car A et B peuvent
consommer 100 % du temps UC. Dans la plupart des cas, toutefois, A et B, dans un niveau
de priorité élevé, sont constitués de travaux interactifs ou orientés transaction qui n’utilisent
pas tout le temps UC. C reçoit du temps UC pour lequel il est en compétition avec d’autres
classes du même niveau ou des niveaux inférieurs.
Exemple avec des limites de mémoire
L’exemple suivant examine l’allocation de mémoire à des groupes de processus avec des
cibles de mémoire variables. Trois groupes de processus doivent être actifs : un groupe de
processus interactifs qui doivent être exécutés chaque fois qu’ils sont utilisés (PEOPLE),
un travail par lot qui doit être toujours exécuté en arrière–plan (BATCH1) et un second
travail par lot plus important qui est exécuté toutes les nuits (BATCH0).
PEOPLE a un minimum de mémoire de 20 %, une cible de mémoire de 50 partages et une
valeur de niveau de classe de 1.Une limite de 20 % minimum garantit que les applications
bureautiques de cette classe reprennent leur exécution rapidement lorsque l’utilisateur
touche le clavier.
BATCH1 a un minimum de mémoire de 50 %, une cible de mémoire de 50 partages et une
valeur de niveau de 3.
BATCH0 a un minimum de mémoire de 80 %, une cible de mémoire de 50 partages et une
valeur de niveau de 2.
Les classes PEOPLE et BATCH1 ont une limite de mémoire totale minimum de 70. Dans
des conditions normales (lorsque BATCH0 est actif), ces deux classes peuvent utiliser
l’ensemble de la mémoire qui leur est réservée. Elles partagent le reste de la mémoire dans
la machine à hauteur de 50 %, même si elles se trouvent dans des niveaux différents. A
minuit, lorsque BATCH0 démarre, le total de mémoire minimum atteint 150. WLM ignore le
minimum du niveau le plus bas jusqu’à ce que les processus des niveaux supérieurs se
terminent. BATCH0 prend de la mémoire de la réserve de 50 % de BATCH1, mais pas de la
réserve de 20 % de PEOPLE. Une fois BATCH0 terminé, les réserves de mémoire pour les
processus du niveau 3 sont de nouveau honorées et le système revient à son équilibre de
mémoire normale.
9-36
Concepts de gestion de système AIX – Système d’exploitation et unités
Compatibilité amont
Lorsque vous démarrez WLM avec des configurations créées avec des versions antérieures
à AIX 5.1, seules les superclasses sont utilisées. La sortie par défaut de la commande
wlmstat liste uniquement les superclasses qui sont similaires à celles des versions
précédentes. Par exemple :
# wlmstat
CLASS
Unclassified
Unmanaged
Default
Shared
System
class1
class2
CPU
0
0
0
0
2
0
0
MEM
0
0
0
2
12
0
0
DKIO
0
0
0
0
0
0
0
#
Si des superclasses contiennent des sous–classes définies par un administrateur WLM, les
sous–classes sont affichées. Par exemple :
# wlmstat
CLASS
Unclassified
Unmanaged
Default
Shared
System
class1
class1.Default
class1.Shared
class1.sub1
class2
CPU MEM DKIO
0
0
0
0
0
0
0
0
0
0
2
0
3
11
7
46
0
0
28
0
0
0
0
0
18
0
0
48
0
0
#
La sortie est identique lorsque vous utilisez la commande ps. Pour les processus d’une
superclasse sans sous–classes, la commande ps affiche le nom de la superclasse comme
nom de classe de processus.
Gestion de la charge de travail
9-37
9-38
Concepts de gestion de système AIX – Système d’exploitation et unités
Chapitre 10. SRC et sous-systèmes
Ce chapitre présente le contrôleur de ressources système (SRC) et les différents
sous–systèmes qu’il gère. Pour les procédure relatives aux tâches, reportez–vous à la
section SRC et sous–systèmes dans le manuel AIX 5L Version 5.3 Guide de Gestion du
Système: Système d’exploitation et unités.
SRC et sous–systèmes
10-1
SRC - généralités
Le contrôleur SRC (System Resource Controller) fournit un ensemble de commandes et
de sous-routines rendant le travail de création et de contrôle des sous-systèmes plus facile
pour l’administrateur et le programmeur. Un sous-système est un programme, un
processus, un ensemble de programmes ou un ensemble de processus capables d’opérer
indépendamment ou avec un système de contrôle. Le sous-système est conçu comme une
unité remplissant une fonction donnée.
Le SRC a été conçu pour minimiser l’intervention de l’opérateur. Il fournit un mécanisme de
contrôle des processus du sous-système opérant à partir d’une ligne de commande et avec
l’interface C Ce mécanisme comprend :
• Une interface utilisateur cohérente pour lancer, arrêter et générer des états.
• La journalisation des arrêts anormaux des sous-systèmes.
• Un programme de notification appelé lors de l’arrêt système anormal des processus
associés.
• Le suivi d’un sous-système, d’un groupe de sous-systèmes ou d’un sous-serveur.
• La prise en charge du contrôle des opérations sur un système distant.
• Le rafraîchissement d’un sous-système (par exemple, après en avoir modifié la
configuration).
SRC représente un moyen simple de lancer et arrêter la collecte d’informations sur l’état
des processus.
Composants du sous-système
Un sous-système peut être doté des propriétés suivantes :
• Il possède un nom connu du système.
• Il requiert un environnement d’exécution plus complexe qu’un sous-routine ou un
programme non privilégié.
• Il intègre des programmes d’application, des bibliothèques et un code sous-système.
• Il contrôle des ressources qu’il peut démarrer et arrêter par leur nom.
• Il a besoin d’être notifié de l’échec d’un processus associé pour effectuer un nettoyage
ou restaurer des ressources.
• Il requiert un contrôle opérationnel plus important qu’un simple processus démon.
• Il a besoin d’être contrôlé à distance par un opérateur.
• Il met en oeuvre des sous-serveurs pour gérer des ressources spécifiques.
• Il ne se place pas lui-même en arrière-plan.
Voici quelques sous-systèmes : ypserv, ntsd, qdaemon, inetd, syslogd et sendmail.
Remarque : Pour en savoir plus sur les fonctions SRC d’un sous-système spécifique,
reportez-vous à ce sous-système.
Pour la liste des sous-systèmes actifs et inactifs de votre système, exécutez la commande
lssrc –a.
10-2
Concepts de gestion de système AIX – Système d’exploitation et unités
Groupe de sous-systèmes
Un groupe de sous-systèmes est un ensemble de sous-systèmes spécifiés. Regrouper des
sous-systèmes permet de les contrôler ensemble et en une seule opération. Voici quelques
exemples de groupes de sous-systèmes : TCP/IP, SNA Services, NIS (Network Information
System) et NFS (Network File Systems).
Sous-serveur
Un sous-serveur est un programme ou un processus appartenant à un sous-système.
Un sous-système peut posséder plusieurs sous-serveurs, auquel cas il est responsable
du démarrage et de l’arrêt des sous-serveurs ; il doit en outre fournir leurs états. Les
sous-serveurs ne peuvent être définis que pour un sous-système communiquant par
sockets et files de message IPC. Les sous-systèmes communiquant par signaux sont
incompatibles avec les sous-serveurs.
Les sous-serveurs sont automatiquement démarrés en même temps que leurs
sous-systèmes parent. Si vous tentez de démarrer un sous-serveur dont le parent est
inactif, la commande startsrc démarre également le sous-système.
Structure hiérarchique de SRC
SRC présente une structure hiérarchique. En début de structure, se trouve le système
d’exploitation, suivi d’un groupe de sous-systèmes (tel que tcpip) lui-même contenant un
sous-système (tel que le démon inetd), qui, à son tour, peut posséder plusieurs
sous-serveurs (tels que le démon ftp et la commande finger.
Liste des commandes d’administration du SRC
La liste suivante
présente les commandes d’administration du SRC :
démon srcmstr
Démarre SRC.
commande startsrc
Démarre un sous-système, un groupe de sous-systèmes
ou un sous-serveur.
commande stopsrc
Arrête un sous-système, un groupe de sous-systèmes
ou un sous-serveur.
commande refresh
Rafraîchit un sous-système.
commande traceson
Active le suivi d’un sous-système, d’un groupe de
sous-systèmes ou d’un sous-serveur.
commande tracesoff
Désactive le suivi d’un sous-système, d’un groupe de
sous-systèmes ou d’un sous-serveur.
commande lssrc
Recherche l’état d’un sous-système.
SRC et sous–systèmes
10-3
10-4
Concepts de gestion de système AIX – Système d’exploitation et unités
Chapitre 11. Comptabilité système
Ce chapitre apporte des généralités sur l’utilitaire de comptabilité système,
qui permet de collecter des informations et de générer des rapports sur l’exploitation
(de groupe ou individuelle) des différentes ressources système.
Remarque :
Un nouveau sous–système de comptabilité avancée est disponible à partir
de la version 5.3 d’AIX. Pour plus d’informations, voir le document AIX 5L
Version 5.3 Understanding the Advanced Accounting Subsystem.
Les sujets traités sont les suivants :
• Généralités sur la comptabilité, page 11-2
• Collecte et rapports de données système, page 11-2
• Collecte de données sur la comptabilité, page 11-3
• Rapports de données de comptabilité, page 11-4
• Commandes de comptabilité, page 11-6
• Fichiers de comptabilité, page 11-8.
Comptabilité système
11-1
Comptabilité - généralités
Avec l’utilitaire de système de comptabilité d’AIX, vous pouvez rassembler et rendre compte
de l’utilisation individuelle, de groupe et de classe Workload Manager (WLM) de différentes
ressources système.
Ces informations peuvent servir à facturer l’exploitation des ressources aux utilisateurs et à
contrôler certains aspects de l’exploitation du système. Pour faciliter la facturation, le
système de comptabilité fournit le cumul par membre du groupe adm de l’utilisation des
ressources et, avec la commande chargefee (le cas échéant), les éléments de facturation.
En outre, le système de comptabilité permet d’évaluer l’adéquation des affectations de
ressources en cours, de définir des limites et des quotas de ressources, de planifier les
besoins futurs et de commander des fournitures pour les imprimantes et autres unités.
Pour la mise en œuvre de l’utilitaire de comptabilité sur votre système, reportez-vous à :
• Collecte et rapports de données système, page 11-2
• Collecte de données sur la comptabilité, page 11-3
• Rapports de données de comptabilité, page 11-4
• Commandes de comptabilité, page 11-6
• Fichiers de comptabilité, page 11-8
Collecte et rapport de données système
Pour la collecte automatique de données, un membre du groupe adm doit suivre les
procédures décrites à “Mise en œuvre d’un système de comptabilité” dans le manuel
“Setting Up an Accounting System”. Ces procédures permettent au démon cron d’exécuter
des commandes générant des données sur :
• Durée de connexion de l’utilisateur au système
• Utilisation de l’unité de traitement, de la mémoire et des ressources d’E–S
• Espace disque occupé par chaque fichier de l’utilisateur
• Utilisation des imprimantes et des traceurs
• Nombre de fois qu’une commande est indiquée.
Chaque session et chaque processus terminé fait l’objet d’un enregistrement écrit par le
système. Ces enregistrements sont convertis en enregistrements comptables cumulés
(tacct), regroupés par utilisateur puis fusionnés dans un rapport quotidien.
Un rapprochement des rapports quotidiens est effectué régulièrement pour générer les
cumuls concernant l’exercice fiscal défini. Les méthodes de collecte des données et de
rapport sur celles-ci, ainsi que les différents fichiers et commandes comptables sont décrits
ci-après.
Toutefois, pour obtenir des informations spécifiques, un membre du groupe adm peut entrer
certaines commandes (au clavier). Ces commandes sont décrites à “Commandes clavier”,
page 11-8.
11-2
Concepts de gestion de système AIX – Système d’exploitation et unités
Collecte de données comptables
Il existe différents types de données comptables :
Données sur les durées de connexion, page 11-3
Les processus, page 11-3
L’utilisation disque, page 11-3
L’utilisation de l’imprimante, page 11-3
La taxation, page 11-3
Chacun de ces types est décrit dans les paragraphes suivants.
Durée de connexion
Ce sont les commandes init et login qui collectent ce type de données. Lors de la
connexion, le programme login écrit un enregistrement dans le fichier /etc/utmp. Dans cet
enregistrement figurent le nom de l’utilisateur, la date, l’heure et le port de connexion. Les
commandes, telles que who, utilisent ce fichier pour rechercher les utilisateurs connectés
sur les différentes stations. Si le fichier comptable sur l’heure de connexion /var/adm/wtmp
existe, la commande login y intègre une copie de l’enregistrement de connexion.
A la fin du programme de connexion (c’est-à-dire généralement lorsque vous vous
déconnectez), la commande init enregistre la fin de session dans un autre enregistrement
du fichier /var/adm/wtmp. A la différence des enregistrements de connexion, ces
enregistrements ne reprennent pas le nom de l’utilisateur. Le format de ces deux types
d’enregistrements est décrit dans le fichier utmp.h.
La commande acctwtmp écrit également des entrées spécifiques dans le fichier
/var/adm/wtmp, relatives aux démarrages et fermetures du système.
Pour en savoir plus, reportez-vous à “Rapports de données comptables”, page 11-5.
Processus
Le système collecte des données sur l’utilisation par chaque processus en cours des
différentes ressources. Ces données comprennent :
• les numéros des utilisateurs et groupes exécutant des processus,
• les huit premiers caractères du nom de la commande,
• le temps écoulé et le temps processus utilisé par le processus,
• la mémoire utilisée,
• le nombre de caractères transférés,
• le nombre de blocs disque écrits ou lus pour l’exécution du processus.
La commande accton enregistre ces données dans un fichier spécial, généralement
dans le fichier /var/adm/pacct.
Les commandes associées sont startup, shutacct, dodisk, ckpacct et turnacct.
Pour en savoir plus, reportez–vous à la section Rapports de données de comptabilité,
page 11-4.
Comptabilité système
11-3
Comptabilité de l’utilisation du disque
La plupart des informations de comptabilité sont collectées à mesure de la consommation
des ressources. La commande dodisk , exécutée sur la requête du démon cron, écrit de
façon périodique les informations d’utilisation du disque pour chacun des utilisateurs dans le
fichier /var/adm/acct/nite(x)/dacct. Pour ce faire, la commande dodisk appelle d’autres
commandes. Selon la minutie de la recherche de comptabilité, la commande diskusg ou la
commande acctdusg peuvent servir à collecter les données. La commande acctdisk sert à
écrire un enregistrement global de la comptabilité. L’enregistrement global sert, à son tour, à
la commande acctmerg pour préparer le rapport quotidien de comptabilité.
dodisk facture à l’utilisateur les liens aux fichiers trouvés dans son répertoire de connexion
et répartit équitablement le coût de chaque fichier entre ces liens. Ainsi, le coût d’utilisation
d’un fichier est partagé également entre tous ceux qui l’utilisent et ne grève pas les
utilisateurs qui renoncent à l’accès au fichier concerné.
Pour en savoir plus, reportez–vous à la section Rapports de comptabilité sur l’utilisation
du disque, page 11-5.
Utilisation de l’imprimante
La collecte des données sur l’utilisation de l’imprimante résulte de la coopération de la
commande enq et du démon de mise en file d’attente. enq met en file d’attente le nom de
l’utilisateur, le numéro du travail d’impression et le nom du fichier à imprimer. Après
l’impression du fichier, la commande qdaemon écrit un enregistrement ASCII dans un
fichier, généralement le fichier /var/adm/qacct, contenant le nom et numéro de l’utilisateur
et le nombre de pages imprimées. Vous pouvez trier ces enregistrements et les convertir en
un enregistrement comptable cumulé.
Pour en savoir plus, reportez-vous à “Utilisation disque”, page 11-3
Taxation
Avec la commande chargefee, vous pouvez générer dans le fichier /var/adm/fee un
enregistrement comptable cumulé en ASCII. Ce fichier peut être intégré aux rapports
quotidiens avec la commande acctmerg.
Pour en savoir plus, reportez-vous à “Comptabilité - généralités”, page 11-3.
Rapport de données comptables
Une fois les différents types de données comptables collectées, les enregistrements sont
traités et convertis en rapports.
Les commandes comptables convertissent automatiquement les enregistrements en
notation scientifique dès lors que les nombres sont élevés. Les nombres sont représentés
en notation scientifique au format suivant :
Base e+ Exp
OU
Base e– Exp
qui est égal au nombre Base multiplié par 10 puissance + Exp ou – Exp. Par exemple,
la notation scientifique 1,345e+9 est égale à 1,345x109 ou à 1 345 000 000. Et la notation
scientifique 1,345e–9 est égale à 1,345x10–9 ou à 0,000000001345.
11-4
Concepts de gestion de système AIX – Système d’exploitation et unités
Rapports de durée de connexion
La commande runacct appelle deux autres commandes, acctcon1 et acctcon2, pour
traiter les enregistrements de connexion, de déconnesion et d’arrêt système regroupés
dans le fichier /var/adm/wtmp. La commande acctcon1 convertit ces enregistrements en
enregistrements de session et les écrits dans le fichier /var/adm/acct/nite(x)/lineuse. La
commande acctcon2 convertit alors les enregistrements de session en un enregistrement
global de comptabilité, /var/adm/logacct, ajouté aux rapports quotidiens par la commande
acctmerg.
Si vous exécutez la commande acctcon1 à partir de l’invite de commande, ajoutez
l’indicateur –l afin de générer le rapport d’utilisation de la ligne de commande,
/var/adm/acct/nite(x)/lineuse. Pour générer un rapport général de la session
correspondant à la période de comptabilité, /var/adm/acct/nite(x)/reboots, exécutez la
commande acctcon1 avec l’indicateur –o.
La commande lastlogin génère un rapport indiquant la dernière date de connexion de
chaque utilisateur.
Processus
Deux commandes traitent les données de facturation collectées dans le fichier
/var/adm/pacct ou dans un autre fichier spécifié. La commande acctprc1 traduit l’ID
utilisateur en un nom d’utilisateur et écrit des enregistrements ASCII contenant les éléments
facturables : La commande acctprc2 convertit ces enregistrements en enregistrements
comptables cumulés intégrés aux rapports quotidiens par la commande acctmerg.
Les données comptables sur les processus fournissent des informations exploitables pour
contrôler l’utilisation des ressources système. La commande acctcms en résume
l’utilisation par nom de commande. Ce résumé indique combien de fois la commande a été
exécutée, le temps processeur et la mémoire utilisés, et l’intensité d’exploitation de ces
ressources (appelé hog factor = facteur de monopolisation). La commande acctcms génère
des statistiques à long terme sur l’utilisation du système, dont l’utilisation totale et la
fréquence d’utilisation des commandes.
La commande acctcom gère les mêmes données que acctcms, mais fournit des
informations détaillées sur chaque processus. Vous pouvez afficher tous les
enregistrements comptables de processus ou sélectionner ceux qui vous intéressent. Les
critères de sélection comprennent la charge imposée par le processus, l’heure à laquelle le
processus s’est terminé, le nom de la commande, l’utilisateur ou le groupe qui a appelé le
processus, le nom de la classe WLM à laquelle le processus appartenait et le port sur
lequel le processus s’est exécuté. Contrairement à d’autres commandes de comptabilité,
acctcom peut être exécutée par tous les utilisateurs.
Rapport de comptabilité de l’utilisation du disque
La commande acctmerg fusionne les enregistrements d’utilisation du disque regroupés
dans le fichier /var/adm/acct/nite(x)/dacct dans les rapports quotidiens de comptabilité.
Rapport de comptabilité de l’utilisation de l’imprimante
La commande acctmerg permet de convertir l’enregistrement ASCII du fichier
/var/adm/qacct en un rapport global de comptabilité à ajouter au rapport quotidien.
Rapport de comptabilité des frais
Si vous avez utilisé la commande chargefee pour facturer aux utilisateurs des services tels
que la restauration de fichiers, le conseil ou du matériel, un enregistrement global de
comptabilité ASCII est écrit dans le fichier /var/adm/fee. Le fichier est ajouté aux rapports
quotidiens par la commande acctmerg.
Comptabilité système
11-5
Rapports quotidiens
La commande acctmerg fusionne les données brutes de comptabilité de la durée de
connexion, des processus, de l’utilisation du disque et des frais à facturer. Appelée par la
commande runacct dans le cadre de son exécution quotidienne, la commande acctmerg
génère les éléments suivants :
/var/adm/acct/nite(x)/dacct
Rapport intermédiaire généré lorsqu’un des fichiers d’entrée est plein.
/var/adm/acct/sum(x)/tacct
Rapport de total cumulatif dans le format tacct. Ce fichier est utilisé par la
commande monacct pour produire le résumé mensuel ASCII.
La commande acctmerg peut convertir les enregistrements de format ASCII en format
binaire et fusionner les enregistrements de différentes sources pour créer un seul
enregistrement pour chaque utilisateur.
Rapport mensuel
Appelée par le démon cron, la commande monacct génère l’élément suivant :
/var/adm/acct/fiscal
Rapport périodique généré à partir du rapport
/var/adm/acct/sum/tacct par la commande monacct. Il est
possible de configurer la commande monacct pour une
exécution mensuelle ou en fin de période fiscale.
Prise en charge d’un nom d’utilisateur de longueur supérieure à huit caractères
Afin de préserver la compatilité amont avec tous les scripts, la prise en charge des noms
d’utilisateur longs n’est pas activée par défaut pour la comptabilité. Les identifiants
utilisateur sont tronqués après les huit premiers caractères. Afin d’activer la prise en charge
des noms d’utilisateur longs, l’indicateur –X a été ajouté à la plupart des commandes, leur
permettant ainsi d’accepter et d’afficher des identifiants d’utilisateur d’une longueur
supérieure à huit caractères (à la fois dans les formats ASCII et binaire). En outre, lorsque
la prise en charge des noms d’utilisateur longs est activée, commandes et scripts traitent
les fichiers dans /var/adm/acct/sumx, /var/adm/acct/nitex et /var/adm/acct/fiscalx au lieu
d’utiliser /var/adm/acct/sum, /var/adm/acct/nite et /var/adm/acct/fiscal.
Commandes comptables
Les commandes comptables ne fonctionnent pas toutes de la même façon. Certaines :
• collectent des données ou produisent des rapports pour un type de comptabilité
spécifique : durées des connexions ou des processus, utilisation disque ou imprimante,
ou utilisation des commandes.
• appellent d’autres commandes. Par exemple, la commande runacct, généralement
exécutée automatiquement par le démon cron, appelle nombre des commandes qui
collectent et traitent les données comptables et préparent les rapports. Pour le traitement
automatique de la comptabilité, vous devez tout d’abord configurer le démon cron pour
exécuter runacct. Reportez-vous à la commande crontab pour plus de détails sur la
configuration du démon cron en vue de soumettre des commandes à intervalles
réguliers.
• exécutent des fonctions de maintenance et garantissent l’intégrité des fichiers de
données actifs.
• permettent aux membres du groupe adm d’exécuter des tâches occasionnelles, telles que
afficher des enregistrements spécifiques au moyen d’une commande entrée au clavier.
• permettent à l’utilisateur d’afficher des informations spécifiques. acctcom est l’unique
commande utilisateur ; elle affiche la synthèse comptable des processus.
11-6
Concepts de gestion de système AIX – Système d’exploitation et unités
Commandes exécutées automatiquement
Plusieurs commandes, généralement exécutées par le démon cron, collectent
automatiquement des données comptables.
runacct
Gère la principale procédure comptable quotidienne. Généralement initiée
par le démon cron en dehors des heures d’exploitation, runacct appelle
plusieurs autres commandes comptables pour traiter les fichiers de
données actifs et produire des synthèses sur l’utilisation des commandes
et des ressources, triées par nom d’utilisateur. En outre, elle appelle la
commande acctmerg pour générer une synthèse quotidienne et la
commande ckpacct pour maintenir l’intégrité des fichiers de données
actifs.
ckpacct
Gère les tailles de fichiers pacct. Il est préférable de disposer de plusieurs
petits fichiers pacct si vous devez redémarrer la procédure runacct après
l’échec du traitement de ces enregistrements. La commande ckpacct
vérifie la taille du fichier de données actif /var/adm/pacct et si le fichier
contient plus de 500 blocs, la commande appelle la commande turnacct
switch pour désactiver temporairement la comptabilité des processus. Les
données sont transférées vers un nouveau fichier pacct, /var/adm/pacct x.
(x est un entier dont la valeur augmente chaque fois qu’un fichier pacct est
créé.) Si le nombre de blocs libres sur le disque tombe en dessous de 500,
la commande ckpacct appelle la commande turnacct off pour désactiver
la comptabilité des processus.
dodisk
Appelle la commande acctdisk et la commande diskusg ou la commande
acctdusg pour écrire les enregistrements d’utilisation du disque dans le
fichier /var/adm/acct/nite/dacct. Ces données sont ensuite fusionnées
dans les rapports quotidiens.
dodisk
Appelle la commande acctdisk et la commande diskusg ou la commande
acctdusg pour écrire les enregistrements d’utilisation du disque dans le
fichier /var/adm/acct/nite/dacct. Ces données sont ensuite fusionnées
dans les rapports quotidiens.
monacct
Génère un résumé périodique à partir des rapports quotidiens.
sa1
Collecte et stocke les données binaires dans le fichier /var/adm/sa/sa dd,
où dd correspond au jour du mois.
sa2
Ecrit un rapport quotidien dans le fichier /var/adm/sa/sa dd, où dd
correspond au jour du mois. La commande supprime du fichier
/var/adm/sa/sa dd les rapports de plus d’une semaine.
Les autres commandes sont exécutées automatiquement par les procédures autres que
le deamon cron :
startup
Ajoutée au fichier /etc/rc, la commande startup lance les procédures de
démarrage du système de comptabilité.
shutacct
Enregistre l’heure de désactivation de la comptabilité en appelant la
commande acctwtmp pour écrire une ligne dans le fichier /var/adm/wtmp.
Elle appelle ensuite la commande turnacct off pour désactiver la
comptabilité des processus.
Comptabilité système
11-7
Commandes disponibles à partir du clavier
Un membre du groupe adm peut entrer les commandes suivantes depuis le clavier :
ac
Imprime les enregistrements d’heure de connexion. Cette commande est
fournie pour la compatibilité avec les systèmes BSD (Berkeley Software
Distribution).
acctcom
Affiche les résumés de comptabilité des processus. Cette commande est
également accessible aux utilisateurs.
acctcon1
Affiche les résumés des heures de connexion. L’option –l ou –o doit être
utilisée.
accton
Active ou désactive la comptabilité des processus.
chargefee
Impute à l’utilisateur une charge prédéterminée pour les unités de travail
effectuées. Les charges sont ajoutées au rapport quotidien par la
commande acctmerg.
fwtmp
Convertit les fichiers binaires en fichiers ASCII et vice versa.
last
Affiche des informations sur les connexions précédentes. Cette commande
est fournie pour la compatibilité avec les systèmes BSD.
lastcomm
Affiche des informations sur les dernières commandes exécutées. Cette
commande est fournie pour la compatibilité avec les systèmes BSD.
lastlogin
Affiche l’heure de la dernière connexion de chaque utilisateur.
pac
Prépare les enregistrements de comptabilité d’imprimante/traceur. Cette
commande est fournie pour la compatibilité avec les systèmes BSD
(Berkeley Software Distribution).
prctmp
Affiche un enregistrement de session.
prtacct
Affiche les fichiers de comptabilité totale.
sa
Résume les informations de comptabilité brutes pour faciliter la gestion des
informations de comptabilité volumineuses. Cette commande est fournie
pour la compatibilité avec les systèmes BSD.
sadc
Fournit des rapports sur diverses actions système local, telles que
l’utilisation des tampons, les E/S de disque et de bande, les compteurs
d’activité du terminal TTY et les compteurs d’accès aux fichiers.
sar
Ecrit dans un format standard le contenu des compteurs d’activité
cumulatifs sélectionnés dans le système d’exploitation. La commande sar
fournit des rapports uniquement sur les activités locales.
time
Imprime l’heure réelle, l’heure utilisateur et l’heure système nécessaires
pour exécuter une commande.
timex
Signale en secondes le délai écoulé, le délai utilisateur et le délai
d’exécution.
Fichiers comptables
Il existe deux répertoires principaux de comptabilité : /usr/sbin/acct où sont stockés tous
les programmes en C et les procédures shell indispensables pour lancer la comptabilité
système et /var/adm contenant les fichiers de données, de rapports et de synthèse.
Ce sont les membres du groupe adm qui possèdent ces fichiers de données comptables ;
tous les fichiers de données actifs (tels que wtmp et pacct) résident dans le répertoire
personnel adm /var/adm.
11-8
Concepts de gestion de système AIX – Système d’exploitation et unités
Fichiers de données
Les fichiers du répertoire /var/adm sont les suivants :
/var/adm/diskdiag
sortie des diagnostics pendant l’exécution de
programmes comptables sur disque.
/var/adm/dtmp
sortie de la commande acctdusg.
/var/adm/fee
sortie de la commande chargefee, sous forme
d’enregistrements tacct en ASCII.
/var/adm/acct/
fichier comptable de processus actif.
/var/adm/wtmp
fichier comptable de processus actif.
/var/adm/Spacct.mmdd
fichier comptable de processus actif.
Fichiers de rapport et de résumé
Les fichiers de rapport et de résumé se trouvent dans un sous–répertoire /var/adm/acct.
Vous devez créer les sous–répertoires suivant avant d’activer le système de comptabilité.
Reportez–vous à Mise en oeuvre d’un système de comptabilité pour plus d’informations.
/var/adm/acct/nite(x)
Contient les fichiers réutilisés quotidiennement par la commande runacct.
/var/adm/acct/sum(x)
Contient les fichiers de résumé cumulatif mis à jour quotidiennement par la
commande runacct.
/var/adm/acct/fiscal(x)
Contient les fichiers de résumé mensuel créés par la commande monacct.
Fichiers de commande runacct
Les fichiers de rapport et de résumé suivants, générés par la commande runacct,
présentent un intérêt particulier :
/var/adm/acct/nite(x)/lineuse
Contient les statistiques d’utilisation de chaque ligne
de terminal du système. Ce rapport est particulièrement
utile pour détecter les lignes défaillantes. Si le rapport
entre le nombre de déconnexions et le nombre de
connexions dépasse environ 3/1, la probabilité qu’une
ligne soit défaillante est élevée.
/var/adm/acct/nite(x)/daytacct
Contient le fichier global de comptabilité du jour
précédent.
/var/adm/acct/sum(x)/tacct
Contient l’accumulation des fichiers nite/daytacct de
chaque jour et peut servir à la facturation. La
commande monacct réinitialise le fichier chaque mois
ou chaque période fiscale.
/var/adm/acct/sum(x)/cms
Contient l’accumulation des résumés de commandes
de chaque jour. La commande monacct lit cette
version binaire du fichier et la purge. La version ASCII
est nite/cms.
/var/adm/acct/sum(x)/daycms
Contient le résumé quotidien des commandes. Une
version ASCII est stockée dans nite/daycms.
/var/adm/acct/sum(x)/loginlog
Contient un enregistrement de l’heure de la dernière
utilisation de chaque identifiant utilisateur.
/var/adm/acct/sum(x)/rprt
mmdd
Ce fichier contient une copie du rapport quotidien
enregistré par la commande runacct.
Comptabilité système
11-9
Fichiers du répertoire /var/adm/acct/nite(x)
11-10
active
utilisé par la commande runacct pour enregistrer la progression et
imprimer les messages d’erreur et les avertissements. Le fichier active.
mmjj est une copie du fichier active effectuée par le programme
runacct après une détection d’erreur.
cms
synthèse cumulée en ASCII sur les commandes utilisées par la
commande prdaily.
ctacct. mmjj
enregistrements comptables cumulés sur les connexions.
ctmp
enregistrements sur les sessions de connexion.
daycms
synthèse quotidienne en ASCII sur les commandes, utilisée par
la commande prdaily.
daytacct
enregistrements comptables cumulés sur un jour.
dacct
enregistrements comptables cumulés sur les disques, créés par
la commande dodisk.
accterr
sortie des diagnostics générée pendant l’exécution de la commande
runacct.
lastdate
dernière exécution de runacct, sous la forme date +%m%d.
lock1
contrôle l’exploitation en série de la commande runacct.
lineuse
rapport sur l’utilisation de la ligne tty, exploité par la commande prdaily.
log
sortie de la commande acctconl.
log mmjj
semblable à log après détection d’une erreur par la commande
runacct.
reboots
contient les dates de début et fin de wtmp, et un listing des
redémarrages du système.
statefile
enregistre l’état courant pendant l’exécution d’une commande runacct.
tmpwtmp
fichier wtmp corrigé par la commande wtmpfix.
wtmperror
Contient les messages d’erreur wtmpfix.
wtmperr mmjj
semblable à wtmperror après détection d’une erreur par la commande
runacct.
wtmp. mmjj
Fichier wtmp du jour précédent. Supprimée pendant le nettoyage de
la commande runacct.
Concepts de gestion de système AIX – Système d’exploitation et unités
Fichiers du répertoire /var/adm/acct/sum(x)
cms
fichier de synthèse de toutes les commandes pour l’exercice fiscal en
cours, en format binaire.
cmsprev
fichier de synthèse des commandes sans la dernière mise à jour.
daycms
fichier de synthèse des commandes pour le jour précédent, en format
binaire.
lastlogin
fichier créé par la commande lastlogin.
pacct. mmjj
version concaténée de tous les fichiers pacct pour mmjj. Ce fichier est
supprimé par la commande remove après le démarrage du système.
rprt mmjj
sortie sauvegardée de la commande prdaily.
tacct
fichier comptable de cumuls pour l’exercice fiscal en cours.
tacctprev
semblable à tacct sans la dernière mise à jour.
tacct mmjj
fichier comptable cumulé pour mmjj.
Fichiers du répertoire /var/adm/acct/fiscal(x)
cms ?
fichier de synthèse de toutes les commandes pour l’exercice fiscal,
spécifié par ?, en format binaire.
fiscrpt ?
rapport semblable à celui de la commande prdaily pour l’exercice
fiscal, spécifié par ?, en format binaire.
tacct ?
fichier comptable cumulé pour l’exercice fiscal, spécifié par ?,
en format binaire.
Formats des fichiers comptables
Les sorties générées par les fichiers comptables et les formats correspondants sont décrits
ci-après :
wtmp
fichier comptable de processus actifs, au format défini dans le fichier
utmp.h.
ctmp
enregistrements sur les sessions de connexion. Le format est décrit
dans le fichier ctmp.h.
pacct*
enregistrements comptables de processus actifs, au format défini dans
le fichier /usr/include/sys/acct.h.
Spacct*
fichier comptable de processus actif. Le format de ces fichiers est défini
dans le fichier sys/acct.h.
daytacct
enregistrements comptables cumulés sur un jour. Le format du fichier
est défini dans le fichier tacct.
sum/tacct
fichier binaire cumulant les synthèses quotidiennes des commandes.
Le format de ce fichier est défini dans le fichier d’en-tête
/usr/include/sys/acct.h.
ptacct
versions concaténées des fichiers pacct. Le format de ces fichiers est
défini dans le fichier tacct.
ctacct
enregistrements comptables cumulés sur les connexions. Le format de
ce fichier est défini dans le fichier tacct.
cms
synthèse comptable cumulée des commandes exploitée chaque jour
par la commande prdaily au format binaire. Une version ASCII figure
dans nite/cms.
daycms
synthèse quotidienne des commandes exploitée par la commande
prdaily au format binaire. Une version ASCII figure dans nite/daycms.
Comptabilité système
11-11
11-12
Concepts de gestion de système AIX – Système d’exploitation et unités
Chapitre 12. Web–based System Manager
Web–based System Manager est une application client–server qui fournit à l’utilisateur une
interface graphique puissante pour accéder à plusieurs hôtes et les gérer. Avec Web–based
System Manager, vous pouvez afficher les utilisateurs et les groupes, installer des logiciels,
des imprimantes et des unités, gérer les volumes logiques, les utilisateurs, les groupes et
les ressources, monter et démonter des systèmes de fichiers, configurer le réseau et
exécuter de nombreuses autres tâches d’administration de système. Une architecture
plug–in facilite l’extension de la suite. En outre, Web–based System Manager prend en
charge le contrôle dynamique des événements système et la notification à l’administrateur.
L’interface offre un contrôle Pointer et cliquer sur les objets qui fournit une alternative à
l’apprentissage des commandes ou de SMIT. Vous pouvez sélectionner la machine à gérer
et lorsque vous naviguez vers l’opération à exécuter, les panneaux actualisent les données
pour afficher les options autorisées.
Pour plus d’informations sur l’utilisation de Web–based System Manager et les procédure
associées, reportez–vous au document AIX 5L Version 5.3 Web–based System Manager
Administration Guide.
Web–based System Manager
12-1
12-2
Concepts de gestion de système AIX – Système d’exploitation et unités
Chapitre 13. SMIT (System Management Interface Tool)
Bien que Web–based System Manager, page 12-1 soit la principale interface de gestion
de système, SMIT (System Management Interface Tool) fournit une interface alternative en
langage naturel orientée tâches. L’outil SMIT s’exécute dans deux interfaces : ASCII (non
graphique) ou AIXwindows (graphique).
SMIT vous aide à exécuter la tâche appropriée à l’aide de menus, de sélecteurs et de
boîtes de dialogue, ce qui vous évite d’avoir à utiliser des syntaxes de commandes
complexes et des valeurs de paramètres et les erreurs d’orthographe des commandes
système. En outre, SMIT crée des fichiers journaux que vous pouvez utiliser pour dupliquer
une configuration système ou pour apprendre à utiliser des commandes.
Dans l’interface SMIT, les options du menu principal permettent d’accéder à des
sous–menus qui fournissent les options appropriées pour l’exécution d’une tâche. Pour
ignorer le menu principal et accéder directement à un sous–menu ou une boîte de dialogue,
vous pouvez utiliser la commande smit avec le paramètre Fast Path.
Pour en savoir plus sur SMIT, vous pouvez :
• Démarrer SMIT et sélectionner Using SMIT (Information Only) dans le menu principal
SMIT.
• Dans les boîtes de dialogue SMIT, sélectionnez On Context (Ctrl+F1) dans le menu
Help et placez le curseur sur l’option de menu appropriée ou dans le champ sur lequel
vous voulez afficher des informations complémentaires.
Le tableau suivant répertorie les tâches SMIT de base :
Tâches de base SMIT
Tâche
Raccourci SMIT
Sélection (ASCII)
Sélection
(AIXwindows)
Entrer dans SMIT
smit
Quitter SMIT.
F12
F12 ou option Exit
SMIT dans le menu
Exit
Commande Show
F6
F6 ou option
Command dans le
menu Show
Raccourci Show
F8
F8 ou option
FastPath dans le
menu Show
SMIT (System Management Interface Tool)
13-1
13-2
Concepts de gestion de système AIX – Système d’exploitation et unités
Chapitre 14. Unités
Les unités incluent les composants matériels, tels que les imprimantes, les périphériques,
les cartes, les bus et les emplacements d’extension, ainsi que les pseudo–unités telles que
le fichier spécial d’erreur et le fichier spécial null. Les pilotes d’unités se trouvent dans le
répertoire /usr/lib/drivers.
•
Configuration d’un grand nombre d’unités, page 14-1
•
Noeuds d’unités, page 14-2
•
Codes d’emplacement des unités, page 14-5
•
Gestion de la connexion à chaud PCI, page 14-9.
•
E/S à plusieurs chemins, page 14-11
Ce chapitre présente les méthodes utilisées par le système d’exploitation
pour gérer ces unités :
Configuration d’un grand nombre d’unités
Le nombre d’unités que peut prendre en charge AIX varie en fonction du système et dépend
de plusieurs facteurs. Les facteurs suivants ont un impact sur les systèmes de fichiers qui
prennent en charge les unités :
• La configuration d’un grand nombre d’unités nécessite de stocker plus d’informations
dans la base de données de configuration des unités ODM. Elle peut également
nécessiter plusieurs fichiers spéciaux d’unités. En conséquence, un espace plus
important et plus d’i–nodes sont nécessaires pour le système de fichiers.
• Certaines unités nécessitent plus d’espace que d’autres dans la base de configuration
des unités ODM. Le nombre de fichiers spéciaux ou d’i–nodes varie également en
fonction des unités. En conséquence, la quantité d’espace et le nombre d’i–nodes du
système de fichiers dépendent du type des unités du système.
• Les unités MPIO (Multipath I/O) nécessitent plus d’espace que les unités non–MPIO,
car les informations sont stockées dans l’ODM de l’unité elle–même, et pour chaque
chemin d’accès à l’unité. En règle générale, l’espace de chaque chemin correspond à
1/5 de l’espace de l’unité. Par exemple, une unité MPIO avec cinq chemins dispose
d’un espace équivalent à celui de deux unités non–MPIO.
• AIX inclut des unités logiques et des unités physiques dans la base de données de
configuration des unités ODM. Les unités logiques incluent les groupes de volumes,
les volumes logiques, les interfaces réseau, etc. Dans certains cas, la relation entre les
unités logiques et les unités physiques peut affecter considérablement le nombre total
d’unités prises en charge. Si, par exemple, vous définissez un groupe de volumes avec
deux volumes logiques pour chaque disque physique connecté au système, cela
correspond à quatre unités AIX pour chaque disque. En revanche, si vous définissez un
groupe de volumes avec six volumes logiques pour chaque disque physique, il existera
huit unités AIX pour chaque disque. En conséquence, moitié moins de disques peut être
connectée.
• La modification des attributs par défaut augmente la taille de la base de données de
configuration des unités ODM et peut empêcher de prendre en charge un plus grand
nombre d’unités.
• La mémoire réelle nécessaire est proportionnelle au nombre d’unités.
Unités
14-1
AIX utilise deux fichiers système pour prendre en charge les unités :
• Le système de fichiers RAM est utilisé au cours de l’amorçage dans un environnement
sans espace de pagination et sans système de fichiers disque monté. La taille du
système de fichiers RAM correspond à 25 % de la taille de la mémoire système, jusqu’à
128 Mo. Un i–node est alloué à chaque Ko dans le système de fichiers RAM. La
mémoire système minimum pour AIX 5.2 est de 128 Mo, ce qui se traduit par un
système de fichiers d’une taille minimale de 32 Mo avec 32 768 i–nodes. Si la mémoire
système est de 512 Mo ou plus, la taille maximale du système de fichiers RAM est de
128 Mo avec 131 072 i–nodes. Si la taille de l’espace du système de fichiers RAM ou
le nombre d’i–nodes nécessaire pour prendre en charge les unités connectées est
supérieure à l’allocation associée au disque RAM, le système ne démarre pas.
Dans ce cas, vous devez supprimer des unités.
• La taille et le nombre d’i–nodes du système de fichiers root (rootvg) sur le disque
peuvent être augmentés si le groupe de volumes rootvg contient des partitions non
allouées. Avec AIX 5.2 et la taille minimale de système de fichiers RAM, il est possible
de configurer jusqu’à 5 000 unités AIX. Avec la taille maximale de système de fichiers
RAM, il est possible de configurer jusqu’à 25 000 unités AIX. Ces chiffres incluent les
unités physiques et les unités logiques. Selon les divers facteurs mentionnés dans cette
section, votre système peut configurer plus ou moins d’unités.
Remarques :
1. Un grand nombre d’unités allonge le délai de configuration et donc le délai d’amorçage.
2. AIX 5L Version 5.2 avec le module de maintenance recommandé 5200–03 et ultérieur
prend en charge les unités IDE DVD–RAM.
Nœuds d’unité
Les unités sont structurées en grappes appelées nœuds. Chaque nœud représente un
sous-système logique d’unités, les unités de niveau inférieur étant dépendantes de celles
de niveau supérieur dans la hiérarchie (enfant-parent). Par exemple, le nœud système est
en haut de la hiérarchie et comprend l’ensemble des unités physiques du système. Le
noeud système est le noeud le plus élevé dans la hiérarchie, suivi du bus et des cartes qui
en dépendent. En bas de la hiérarchie sont situées les unités auxquelles ne sont pas
connectées d’autres unités. Ces unités sont dépendantes de toutes les autres dans la
hiérarchie.
Lors de l’amorçage, les dépendances parent-enfant servent à configurer toutes les unités
formant un nœud. La configuration commence par le nœud supérieur et continue vers le
bas. Les unités qui dépendent d’une unité d’un niveau supérieur ne peuvent être
configurées qu’après celle-ci.
MPIO (Multiple–path I/O) est une fonction disponible dans AIX 5.2 et les versions
supérieures. Si une unité dispose d’un pilote compatible MPIO, elle peut avoir plusieurs
parents dans cette hiérarchie, ce qui permet de disposer de plusieurs chemins de
communication simultanée entre l’unité et une machine donnée ou une partition logique
dans une machine. Pour plus d’informations sur le fonctionnement de cette fonction,
reportez–vous à la section Base de données de configuration des unités, page 14-3.
14-2
Concepts de gestion de système AIX – Système d’exploitation et unités
Classes d’unité
La gestion d’unité suppose la compréhension par le système d’exploitation des connexions
d’unité autorisées. Le système d’exploitation classe les unités en trois groupes :
• classes fonctionnelles,
• sous-classes fonctionnelles,
• types d’unité.
Une classe fonctionnelle représente des unités exécutant la même fonction. Par exemple,
les imprimantes constituent une classe fonctionnelle. Les classes fonctionnelles sont
réparties en sous-classes, tenant compte de certaines similitudes des unités. Par exemple,
les imprimantes peuvent être divisées en deux sous-classes : les imprimantes série et les
imprimantes parallèles. Les types d’unités sont classés en fonction des modèles et du
fabricant.
Les classes d’unité définissent des connexions parent-enfant pour le système d’exploitation.
La hiérarchie définit les sous-classes pouvant être connectées pour chaque emplacement
potentiel de connexion enfant. Par exemple, le terme carte 8 ports RS-232 indique que seules
les unités de la sous-classe RS-232 peuvent être connectées à un des ports de la carte.
Les classes d’unité et leurs dépendances hiérarchiques sont actualisées dans une base
de configuration d’unités ODM (Object Data Manager).
Base de configuration d’unités
Les données relatives aux unités figurent dans une base prédéfinie ou une base
personnalisée constituant la base de configuration d’unités. La base prédéfinie regroupe
les données de configuration de toutes les unités possibles prises en charge par le
système. Les données sur la hiérarchie de la classe d’unité font partie de cette base de
données. La base personnalisée contient des données de configuration concernant chaque
unité définie et configurée du système. Un enregistrement de chaque unité connectée au
système est conservé.
Le gestionnaire de configuration est un programme qui configure automatiquement les
unités pendant l’amorçage du système et le temps d’exécution. Pendant ce processus,
il fait appel aux données de la base prédéfinie et de la base personnalisée et actualise
ensuite cette dernière.
Depuis la version AIX 5.2, la fonction MPIO (Multiple–path I/O) utilise un identificateur
d’unité unique (UDID) pour identifier chaque unité MPIO, quel que soit le chemin dans
lequel elle est découverte. L’identificateur UDID est enregistré dans la base de données de
configuration des unités. Lorsqu’une unité est découverte, les UDID de la base de données
sont vérifiés pour déterminer s’il s’agit d’une nouvelle unité ou d’un autre chemin d’accès à
une unité existante. Lorsque plusieurs chemins d’accès à une unité sont détectés, le pilote
d’unité ou l’extension de noyau Path Control Manager détermine le chemin à utiliser pour
une demande donnée. Pour plus d’informations sur la gestion des unités MPIO,
reportez–vous à la section Managing MPIO–Capable Devices du document AIX 5L
Version 5.3 System Management Guide: Operating System and Devices
Unités
14-3
Etats des unités
Quatre états peuvent caractériser les unités connectées au système :
Undefined
Le système ne connaît pas l’unité (état non défini).
Defined
Les données spécifiques de l’unité sont enregistrées dans la base
personnalisée sans toutefois être disponibles (état défini).
Available
Une unité définie est associée au système d’exploitation ou l’unité
définie est configurée (état disponible).
Stopped
L’unité n’est pas disponible mais est toutefois connue de son
gestionnaire (état arrêté).
Quand une unité tty et une imprimante utilisent alternativement le même connecteur tty,
dans la base de configuration d’unités, l’unité tty et l’imprimante sont définies sur le même
parent et le même port. Une seule unité peut être configurée à la fois. Pendant la
configuration du connecteur tty, les données d’installation de l’imprimante sont retenues en
attendant d’être à nouveau configurées. L’unité n’est pas supprimée mais est à l’état défini.
Maintenir une unité à l’état défini retient les données de la base personnalisée pour une
unité qui n’est pas couramment utilisée, avant sa première mise à disposition ou pendant
sa suppression temporaire du système.
C’est le gestionnaire d’unité, s’il existe, qui rend l’unité disponible.
Certaines unités, en particulier les pseudo-unités TCP/IP, ont recours à l’état arrêté.
Gestion des unités
Vous pouvez utiliser l’application Web–based System Manager Devices, SMIT, ou les
commandes du système d’exploitation pour exécuter les tâches de gestion des unités,
telles que supprimer, ajouter ou configurer des unités.
14-4
Concepts de gestion de système AIX – Système d’exploitation et unités
Codes d’emplacement des unités
Le code d’emplacement représente le chemin d’accès de l’unité centrale ou du tiroir CPU à
la carte, aux câbles de signaux et, le cas échéant, au multiplexeur asynchrone de l’unité ou
de la station. Ce code représente un autre moyen d’identifier les unités physiques.
Le code d’emplacement est formé de une à quatre zones de données de deux caractères,
selon le type d’unité. Ces zones représentent le tiroir, l’emplacement de carte, le connecteur
et le port. Chacune de ces zones comporte deux caractères.
Le code d’emplacement du tiroir est un code de deux caractères situé dans la zone
correspondante. Celui de la carte figure dans la zone du tiroir et celle de l’emplacement de
carte au format AA–BB, AA correspondant au code d’emplacement du tiroir et BB au code du
bus et de l’emplacement de la carte. Les autres unités ont des codes d’emplacement au
format AA–BB–CC ou AA–BB–CC–DD, où AA–BB est le code d’emplacement de la carte à
laquelle l’unité est connectée, CC le code du connecteur de la carte et DD un numéro de port
ou une adresse d’unité SCSI.
Pour trouver les étiquettes mentionnant les codes d’emplacement sur le matériel,
reportez-vous au guide de l’opérateur.
Carte
Le code d’emplacement d’une carte est un code au format AA–BB, où AA représente le
code d’emplacement du tiroir logeant la carte et BB le bus d’E/S et l’emplacement de la
carte.
La valeur 00 dans la zone AA signifie que la carte est située dans le tiroir CPU ou l’unité
centrale, selon le type du système. Dans cette zone, toute autre valeur indique que la carte
loge dans une unité d’extension d’E/S. Dans ce cas, la valeur de AA identifie le bus d’E/S et
le numéro d’emplacement du tiroir CPU où se trouve la carte d’extension asynchrone. Pour
le premier chiffre, la valeur 0 correspond au bus d’E/S standard et la valeur 1 au bus d’E/S
en option. Le second chiffre identifie le numéro d’emplacement sur le bus d’E/S indiqué.
Le premier chiffre de la zone BB identifie la carte d’E/S contenant la carte d’adaptation. Si
elle loge dans le tiroir CPU ou l’unité centrale, la valeur de ce chiffre est 0 pour le bus d’E/S
standard et 1 pour celui en option. Si la carte est située dans un tiroir d’extension d’E/S, ce
chiffre est 0. Le second chiffre identifie le numéro d’emplacement sur le bus d’E/S indiqué
(ou dans le tiroir d’extension d’E/S).
Le code d’emplacement 00–00 identifie la carte d’E/S standard.
Exemples :
00–05
carte à l’emplacement 5 de la carte d’E/S standard, située dans le tiroir
CPU ou l’unité centrale, selon le type du système.
00–12
carte à l’emplacement 2 du bus d’E/S en option, située dans le tiroir
CPU.
18–05
carte à l’emplacement 5 d’un tiroir d’extension d’E/S. Ce tiroir est
connecté à la carte d’extension asynchrone située à l’emplacement 8
du bus d’E/S en option dans le tiroir CPU.
Unités
14-5
Imprimante/traceur
Les codes d’emplacement 00–00–S1–00 ou 00–00–S2–00 représentent
l’imprimante/traceur connecté au port série s1 ou s2 de la carte d’E/S standard.
Le code 00–00–0P–00 représente l’imprimante parallèle connectée au port parallèle
de la carte d’E/S standard.
Tout autre code d’emplacement indique que l’imprimante ou le traceur n’est pas connecté
à la carte d’E/S standard mais à une autre carte. Le code a le format AA–BB–CC–DD,
où AA–BB indique le code d’emplacement de la carte pilotant l’unité.
AA
La valeur 00 dans la zone AA signifie que la carte est située dans le
tiroir CPU ou l’unité centrale, selon le type du système. Toute autre
valeur indique que la carte loge dans un tiroir d’extension d’E/S ; dans
ce cas, le premier chiffre identifie le bus d’E/S et le second le numéro
d’emplacement sur le bus dans le tiroir CPU contenant la carte
d’extension asynchrone à laquelle le tiroir d’extension d’E/S est
connecté.
BB
Le premier chiffre de cette zone identifie le bus d’E/S contenant la carte.
Si la carte loge dans le tiroir CPU ou l’unité centrale, la valeur 0
représente le bus d’E/S standard et 1 celui en option. Si la carte se
trouve dans un tiroir d’extension d’E/S, ce chiffre est 0. Le second
chiffre identifie le numéro d’emplacement sur le bus d’E/S (ou dans le
tiroir d’extension d’E/S) contenant la carte.
CC
Cette zone identifie le connecteur de la carte à laquelle le multiplexeur
asynchrone est connecté. Les valeurs possibles de cette zone sont 01,
02, 03 et 04.
DD
Cette zone identifie le numéro de port sur le multiplexeur asynchrone
auquel l’imprimante ou le traceur est connecté.
Unité tty
Les codes d’emplacement 00–00–S1–00 ou 00–00–S2–00 indiquent que l’unité tty est
connectée aux ports série d’E/S standard s1 ou s2.
Tout autre code indique que l’unité tty n’est pas connecté à la carte d’E/S standard mais à
une autre carte. Le code a le format AA–BB–CC–DD, où AA–BB indique le code
d’emplacement de la carte pilotant l’unité.
14-6
AA
La valeur 00 dans la zone AA signifie que la carte est située dans le
tiroir CPU ou l’unité centrale, selon le type du système. Toute autre
valeur indique que la carte loge dans une unité d’extension d’E/S. Dans
ce cas, le premier chiffre identifie le bus d’E/S et le second le numéro
d’emplacement sur le bus dans le tiroir CPU contenant la carte
d’extension asynchrone à laquelle le tiroir d’extension d’E/S est
connecté.
BB
Le premier chiffre de la zone BB identifie le bus d’E/S contenant la carte
d’adaptation. Si elle loge dans le tiroir CPU ou l’unité centrale, la valeur
de ce chiffre est 0 pour le bus d’E/S standard et 1 pour celui en option.
Si la carte est située dans un tiroir d’extension d’E/S, ce chiffre est 0.
Le second chiffre identifie le numéro d’emplacement sur le bus d’E/S
indiqué (ou dans le tiroir d’extension d’E/S).
CC
Cette zone identifie le connecteur de la carte à laquelle le multiplexeur
asynchrone est connecté. Les valeurs possibles de cette zone sont 01,
02, 03 et 04.
DD
Cette zone identifie le numéro de port sur le multiplexeur asynchrone
auquel l’unité tty est connectée.
Concepts de gestion de système AIX – Système d’exploitation et unités
Unité SCSI
Toute unité SCSI, y compris :
• CD-ROM,
• disques,
• unités Initiator,
• unités optiques de lecture-écriture,
• bandes,
• mode Target.
Le format du code d’emplacement est AA–BB–CC–S,L. AA–BB identifie le code
d’emplacement de la carte SCSI pilotant l’unité SCSI.
AA
La valeur 00 dans la zone AA signifie que la carte pilotant l’unité est
située dans le tiroir CPU ou l’unité centrale, selon le type du système.
BB
Cette zone identifie le bus d’E/S et l’emplacement contenant la carte.
Le premier chiffre représente le bus d’E/S standard. La valeur 00
représente le bus d’E/S standard et 1 celui en option. Le second chiffre
identifie le numéro d’emplacement sur le bus d’E/S contenant la carte.
La valeur 00 dans cette zone indique le contrôleur SCSI standard.
CC
Cette zone identifie le bus SCSI de la carte à laquelle l’unité est
connectée. Pour une carte ne fournissant qu’un seul bus SCSI, la
valeur de cette zone est 00. Sinon, la valeur 00 indique une unité reliée
au bus SCSI interne de la carte et la valeur 01 une unité reliée au bus
SCSI externe de la carte.
S,L
Cette zone identifie l’ID SCSI et le numéro d’unité logique (LUN)
de l’unité SCSI. La valeur S identifie l’ID SCSI et L le numéro d’unité
logique (LUN).
Codes d’emplacement des disques connectés directement au bus
Pour une unité de disque connectée directement,
le format du code d’emplacement est AA–BB. Le champ AA contient la valeur 00 qui
indique que le disque se trouve dans l’unité système. Le champ BB indique le bus E/S et le
numéro d’emplacement d’extension contenant le disque. Le premier chiffre est toujours 0,
qui indique que le disque est connecté au bus E/S standard. Le second chiffre indique le
numéro de l’emplacement d’extension du bus E/S standard auquel le disque est connecté.
Disque série
Le code d’emplacement des unités de disque en série a le format AA–BB–CC–DD,
où AA–BB indique le code d’emplacement de la carte pilotant l’unité.
Les différentes zones s’interprètent comme suit :
AA
La valeur 00 dans la zone AA signifie que la carte pilotant l’unité est
située dans le tiroir CPU ou l’unité centrale, selon le type du système.
BB
Cette zone identifie le bus d’E/S et l’emplacement contenant la carte.
Le premier chiffre identifie le bus d’E/S standard, 0 pour le bus d’E/S
standard et 1 celui en option. Le second chiffre identifie le numéro
d’emplacement sur le bus d’E/S contenant la carte.
Unités
14-7
CC
Cette zone identifie le connecteur de la carte à laquelle le tiroir pilotant
l’unité est connecté. Les valeurs possibles de cette zone sont 00, 01,
02 et 03.
DD
Cette zone identifie le numéro d’unité logique (LUN) du disque.
Il correspond à l’emplacement du tiroir logeant le disque.
Unité de disquette
Les codes d’emplacement des unités de disquette sont 00–00–0D–01 ou 00–00–0D–02,
indiquant qu’elles sont reliées au port 0 ou 1 de la carte principale d’E/S standard.
Codes d’emplacement du rotateur/clavier LPFK
Pour un rotateur/clavier LPFK
connecté à une carte graphique d’entrée, le format du code d’emplacement est AA–BB–CC.
Les différentes zones s’interprètent comme suit :
AA
La valeur 00 dans la zone AA signifie que la carte pilotant l’unité est
située dans le tiroir CPU ou l’unité centrale, selon le type du système.
BB
Cette zone identifie le bus d’E/S et l’emplacement contenant la carte.
Le premier chiffre identifie le bus d’E/S standard, 0 pour le bus d’E/S
standard et 1 celui en option. Le second chiffre identifie le numéro
d’emplacement sur le bus d’E/S contenant la carte.
CC
Cette zone indique le connecteur de carte auquel l’unité est connectée.
La valeur est 01 ou 02, selon que l’unité est reliée au port 1 ou 2
sur la carte.
Remarque : En série, ces unités n’indiquent pas de codes d’emplacement. Elles sont
supposées reliées à une unité tty. Cette dernière est spécifiée par l’utilisateur
lors de la définition des rotateurs/claviers LPFK.
Port multiprotocole
Le code d’emplacement d’un port multiprotocole a le format AA–BB–CC–DD, où AA–BB
indique le code d’emplacement de la carte multiprotocole.
Les différentes zones s’interprètent comme suit :
14-8
AA
La valeur 00 dans la zone AA signifie que la carte est située dans le
tiroir CPU ou l’unité centrale, selon le type du système.
BB
Cette zone identifie le bus d’E/S et l’emplacement contenant la carte.
Le premier chiffre identifie le bus d’E/S standard, 0 pour le bus d’E/S
standard et 1 celui en option. Le second chiffre identifie le numéro
d’emplacement sur le bus d’E/S contenant la carte.
CC
Cette zone identifie le connecteur de la carte à laquelle le multiplexeur
multiprotocole est connecté. La valeur est toujours 01.
DD
Cette zone identifie le numéro de port physique sur le multiplexeur
multiprotocole. Les valeurs possibles de cette zone sont 00, 01,
02 et 03.
Concepts de gestion de système AIX – Système d’exploitation et unités
Gestion des connexions à chaud PCI
Vous pouvez connecter à chaud une nouvelle carte PCI dans un emplacement d’extension
PCI à connexion à chaud alors que le système d’exploitation est actif. Il peut s’agir d’une
carte de même type que celle qui est installée ou d’une carte d’un type différent. Les
nouvelles ressources sont disponibles pour le systèmes d’exploitation et les applications
sans avoir à redémarrer le système d’exploitation. Vous pouvez être amené à ajouter une
carte connectable à chaud dans les cas suivants :
• Ajout de fonction au matériel et au microcode existant ou extension de leur capacité.
• Migration de cartes PCI d’un système qui ne nécessite plus la fonction fournie par les
cartes.
• Installation d’un nouveau système pour lequel les cartes deviennent disponibles après
la configuration initiale des sous–systèmes matériels, notamment des cartes PCI, et
l’installation et le démarrage du système d’exploitation.
Remarque :
Si vous ajoutez une carte en exécutant une opération de remplacement
ou d’ajout de carte PCI à chaud, ou à l’aide du partitionnement logique
dynamique, la carte et ses unités enfants ne sont pas disponibles comme
spécifications d’unité d’amorçage à l’aide de la commande bootlist.
Vous devez redémarrer la machine pour que le système d’exploitation
reconnaisse toutes les unités d’amorçage potentielles. Une carte
apparaissant déjà dans la liste de démarrage, remplacée alors par le type
exact de la carte, est encore une unité d’amorçage valide.
Vous pouvez également supprimer une carte PCI connectable à chaud défaillante ou la
remplacer par une autre de même type sans avoir à arrêter le système ou le mettre hors
tension. Lorsque vous remplacez la carte, le pilote d’unité existant prend en charge la carte,
car il s’agit d’une carte de même type. Les informations de configuration des unités et de
configuration des unités sous la carte sont conservées pour la carte de remplacement.
Vous pouvez être amené à remplacer une carte dans les cas suivants :
• Remplacement temporaire d’une carte pour déterminer un problème ou isoler une FRU
défaillante.
• Remplacement d’une carte défaillante en continu ou par intermittence.
• Remplacement d’une carte redondante défaillante dans une configuration HACMP ou I/S
à plusieurs chemins.
Lorsque vous retirez une carte connectable à chaud, les ressources fournies par la carte ne
sont plus disponibles pour le système d’exploitation et les applications. Vous pouvez être
amené à retirer une carte dans les cas suivants :
• Retrait des sous–systèmes E/S existants.
• Retrait d’une carte qui n’est plus nécessaire ou défaillante et carte de remplacement non
disponible.
• Migration d’une carte vers un autre système lorsque la fonction de la carte n’est plus
nécessaire sur le système contenant la carte.
Pour pouvoir retirer ou remplacer une carte, vous devez la déconfigurer. Le pilote d’unité
associé doit libérer les ressources système qu’il a allouées à l’unité. Cela inclut la libération
de la mémoire, l’annulation de la définition de l’interruption et des descripteurs EPOW, la
libération de la zone DMA et des ressources de synchronisation, et toutes les autres tâches
nécessaires. Les interruptions, la mémoire de bus et les E/S de bus doivent être également
désactivées dans le pilote.
Unités
14-9
L’administrateur système doit exécuter les tâches suivantes avant et après le retrait
d’une carte :
• Terminer et restaurer les applications, daemons ou processus qui utilisent l’unité.
• Démonter et remonter les systèmes de fichiers.
• Retirer et recréer les définitions d’unités et exécuter d’autres opérations nécessaires
pour libérer une unité utilisée.
• Placer le système dans un état qui permette d’effectuer les opérations de maintenance.
• Obtenir et installer les pilotes d’unités nécessaires.
Les opérations de retrait et de remplacement échouent si l’unité connectée à l’emplacement
d’extension identifié n’a pas été déconfiguré et ne se trouve pas dans l’état défini. Vous
pouvez effectuer cette opération avec la commande rmdev. Avant de placer la carte dans
l’état défini, fermez toutes les application qui utilisent la carte afin que la commande
aboutisse.
Dans certains cas, vous pouvez effectuer les tâches suivantes :
• Préparez une carte PCI connectable à chaud à insérer, retirer ou remplacer.
• Identifiez les emplacements d’extension PCI impliqués dans l’opération de connexion à
chaud.
• Retirez ou insérez les cartes PCI connectables à chaud.
Attention : Bien que la gestion PCI de connexion à chaud permette d’ajouter, de retirer et
de remplacer des cartes PCI sans mettre le système hors tension ou redémarrer le système
d’exploitation, les cartes connectables à chaud ne peuvent pas être toutes gérées de cette
manière. Par exemple, le disque dur qui constitue le groupe de volumes ou le contrôleur
E/S auquel il est connecté ne peut pas être supprimé ou remplacé sans mettre le système
hors tension car il est nécessaire pour exécuter le système d’exploitation. Si le groupe de
volumes rootvg est mis en miroir, la commande chpv permet de placer les disques hors
ligne. Si le groupe de volumes rootvg réside sur un ou plusieurs disques activés pour des
E/S à plusieurs chemins (MPIO, Multi–Path I/O) et connectés à plusieurs contrôleurs d’E/S,
l’un de ces contrôleurs d’E/S peut être retiré (ou remplacé) sans redémarrer le système.
Dans cette situation, tous les chemins depuis le contrôleur d’E/S à retirer (ou remplacer)
doivent être supprimés de la configuration à l’aide de la commande rmdev –R sur la carte.
Cette commande permet de retirer les chemins et la carte de la configuration. Vous pouvez
ensuite poursuivre avec la gestion de la connexion à chaud. Avant toute tentative de retrait
ou d’insertion de cartes PCI hot plug, reportez–vous au document PCI Adapter Placement
Reference, fourni avec les unités centrales qui gèrent les unités hot plug, pour déterminer si
votre carte peut être remplacée à chaud. Reportez–vous à la documentation de l’unité
système pour plus d’informations sur l’installation ou le retrait des cartes.
Pour plus d’informations sur la gestion d’une carte PCI connectable à chaud, reportez–vous
aux sections suivantes du document AIX 5L Version 5.3 System Management Guide:
Operating System and Devices
• Adding a PCI Hot Plug Adapter
• Removing or Replacing a PCI Hot Plug Adapter
14-10
Concepts de gestion de système AIX – Système d’exploitation et unités
Unconfiguring PCI Communications Adapters
Cette section contient des informations générales sur la déconfiguration des cartes de
communication PCI, à savoir les cartes Ethernet, Token–ring, FDDI et ATM. Pour plus
d’informations sur la procédure, reportez–vous à la section Unconfiguring Communications
Adapters du document AIX 5L Version 5.3 System Management Guide: Operating System
and Devices
Si votre application utilise le protocole TCP/IP, vous devez retirer l’interface TCP/IP de la
carte de la liste des interfaces réseau avant de placer la carte dans l’état défini. Utilisez la
commande netstat pour déterminer si la carte est configurée en fonction du protocole
TCP/IP et identifier les interfaces réseau actives de la carte.
Une carte Ethernet peut avoir deux interfaces : Standard Ethernet (en X) ou IEEE 802.3
(et X). X correspond au même numéro dans le nom de carte ent X. Une seule des ces
interfaces peut utiliser TCP/IP à la fois. Par exemple, la carte Ethernet ent0 peut avoir les
interfaces en0 et et0.
Une carte Token ring peut avoir une seule interface : Token–ring (tr X). X correspond au
même numéro dans le nom de carte tok X. Par exemple, la carte Token–ring tok0 a une
interface tr0.
Une carte ATM peut avoir une seule interface atm : ATM (at X). X correspond au même
numéro dans le nom de carte atm X. Par exemple, la carte ATM atm0 a une interface at0.
Toutefois, les cartes ATM peuvent avoir plusieurs clients émulés fonctionnant sur une seule
carte.
La commande ifconfig supprime une interface du réseau. La commande rmdev déconfigure
l’unité PCI en conservant sa définition dans la classe d’objet CDOC (Customized Devices
Object Class). Lorsque la carte se trouve dans l’état défini, vous pouvez utiliser la
commande drslot pour retirer la carte.
Exemple
1. Pour déconfigurer les enfants du bus PCI pci1 et toutes les autres unités en dessous
d’eux en conservant leurs définitions d’unité dans la classe d’objet CDOC, tapez :
rmdev –p pci1
Le système affiche un message similaire au message suivant :
rmt0 Defined
hdisk1 Defined
scsi1 Defined
ent0 Defined
E/S à plusieurs chemins
Avec les E/S à plusieurs chemins (MPIO), une unité peut être détectée via une ou plusieurs
connexions physiques ou chemins. Un module PCM (Path–Control Module) fournit les
fonctions de gestion de chemins.
Un pilote d’unité compatible MPIO peut contrôler plusieurs types d’unités cibles. Un module
PCM peut prendre en charge une ou plusieurs unités spécifiques. En conséquence, un
pilote d’unité peut être interfacé avec plusieurs modules PCM qui contrôlent les E/S sur les
chemins d’accès aux unités cibles.
Figure 12. Interaction des composants MPIO Cette illustration montre l’interaction entre
les différents composants d’une solution MPIO. Dans cette figure, le pilote d’unité MPIO
contrôle plusieurs types d’unités cibles nécessitant chacun un module PCM différent.
(KE=Kernel Extension, RTL=Run–time Loadable).
Unités
14-11
ODM
Méthodes d’unité
PCM RTL
Pilote d’unité
PCM KE
Pilote de carte
Pour qu’une unité puisse tirer parti de MPIO, le pilote, les méthodes et les attributs
prédéfinis de l’unité dans ODM (Object Data Manager) doivent être modifiés pour prendre
en charge la détection, la configuration et la gestion de plusieurs chemins. Les pilotes
d’unités de disques SCSI et à canal à fibre optique et leurs méthodes d’unités prennent en
charge les unités de disques MPIO. A partir de la version 5.2 d’AIX 5L avec le progiciel de
maintenance recommandé 5200–04, les unités de disques iSCSI sont prises en charge
comme des unités de disques MPIO. A partir de la version 5.3 d’AIX, le pilote d’unité de
bande à fibre optique et ses méthodes d’unités ont été modifiés afin de prendre en charge
les unités de bande MPIO. En outre, les attributs prédéfinis de certaines unités dans ODM
ont été modifiés pour MPIO.
Le module AIX PCM est constitué : du module de configuration PCM RTL et de l’extension
de noyau PCM KE. La module PCM RTL est un module chargeable à l’exécution qui permet
aux méthodes d’unité de détecter d’autres attributs d’unité PCM KE ou de chemin ODM
nécessaires à l’extension de noyau PCM KE. Le module PCM RTL est chargé par une
méthode d’unité. Une ou plusieurs routines dans le module PCM RTL sont utilisées pour
exécuter des opérations spécifiques qui initialisent ou modifient des variables PM KE.
Le module PCM KE fournit les fonction de gestion de chemins aux pilotes qui prennent en
charge l’interface MPIO. Le module PCM KE dépend de la configuration de l’unité pour
détecter les chemins et communiquer les informations correspondantes au pilote de l’unité.
Chaque pilote d’unité compatible MPIO ajoute les chemins à une unité depuis son ou ses
parents immédiats. La maintenance et la planification des E/S sur différents chemins sont
fournies par le module PCM KE et elles ne sont pas apparentes pour le pilote d’unité MPIO.
Le module PCM KE peut fournir plusieurs algorithmes de routage qui peuvent être
sélectionnés par l’utilisateur. Le module PCM KE peut également permettre de collecter des
informations qui peuvent être utilisées pour déterminer et sélectionner le meilleur chemin
d’une demande E/S. Le module PCM KE peut sélectionner le meilleur chemin en fonction
de divers critères, notamment de l’équilibre de la charge, du débit de la connexion, de
l’échec de connexion, etc.
14-12
Concepts de gestion de système AIX – Système d’exploitation et unités
Le module AIX PCM dispose d’une fonction de vérification d’intégrité qui peut être utilisée
pour :
• Vérifier les chemins et déterminer ceux qui peuvent être utilisés pour envoyer des E/S.
• Activer un chemin marqué comme défaillant suite à un dysfonctionnement temporaire
(par exemple, lorsqu’un câble connecté à une unité a été retiré, puis déconnecté).
• Identifier les chemins non utilisés qui pourraient être utilisés en cas de basculement (par
exemple, lorsque la valeur d’attribut d’algorithme est failover, la vérification d’intégrité
peut tester des chemins alternatifs).
Configuration d’une unité MPIO
La configuration d’une unité MPIO fait appel aux mêmes commandes que celles d’une unité
non–MPIO. Depuis la version AIX 5.2 avec 5200–01, les commandes cfgmgr, mkdev,
chdev, rmdev et lsdev prennent en charge la gestion des instances d’unités MPIO et
l’affichage de leurs attributs. Une instance d’unité MPIO dispose également d’instances de
chemins associés à l’instance d’unité. Les commandes mkpath, chpath, rmpath et
lspath gèrent les instances de chemins et affichent leurs attributs.
Une instance de chemin peut être ajoutée ou supprimée d’une unité MPIO sans avoir à
déconfigurer l’unité. Pour plus d’informations sur ces commandes, reportez–vous à la
section Managing MPIO–Capable Devices du document AIX 5L Version 5.3 System
Management Guide: Operating System and Devices.
Une unité MPIO peut avoir des attributs supplémentaires, mais les attributs obligatoires que
toutes les unités MPIO doivent prendre en charge sont reserve_policy et algorithm.
L’attribut reserve_policy détermine le type de méthodologie de réserve que met en œuvre
le pilote d’unité lorsque l’unité est ouverte et il peut être utilisé pour limiter l’accès à l’unité
depuis d’autres cartes sur le même système ou un autre système. L’attribut algorithm
définit la technologie qu’utilise le module PCM pour gérer les E/S sur les chemins
configurés de l’unité. Pour plus d’informations sur l’attribut reserve_policy, reportez–vous à
la section Attributs d’unité MPIO, page 14-14. Pour plus d’informations sur l’attribut
algorithm, reportez–vous à la section Attributs de module PCM (Path Control Module),
page 14-16.
Unités à plusieurs chemins prises en charge
Les modules AIX PCM par défaut prennent en charge un groupe d’unités de disque et de
bande définies dans le fileset devices.common.IBM.mpio.rte. Pour les unités non prises
en charge par les modules AIX Disk PCM ou Tape PCM, le vendeur de l’unité doit fournir les
attributs prédéfinis ODM, un PCM et tout autre code nécessaire à la reconnaissance de
l’unité comme prenant en charge MPIO.
Pour déterminer les unités de disque prises en charge par le module AIX Disk PCM,
exécutez le script suivant :
odmget –qDvDr=aixdiskpcmke PdDv | grep uniquetype | while read line
do
utype=‘echo $line | cut –d’”’ –f2‘
dvc=‘odmget –q”uniquetype=$utype AND
attribute=dvc_support” PdAt‘
echo $dvc | grep values | cut –d’”’ –f2
done
Pour déterminer les unités de bande prises en charge par le module AIX Disk PCM,
exécutez le script suivant :
odmget –qDvDr=aixtapepcmke PdDv | grep uniquetype | while read line
do
utype=‘echo $line | cut –d’”’ –f2‘
dvc=‘odmget –q”uniquetype=$utype AND
attribute=dvc_support” PdAt‘
echo $dvc | grep values | cut –d’”’ –f2
done
Unités
14-13
Le script affiche la liste des types d’unités uniques pris en charge par les modules AIX PCM
par défaut. Les trois types d’unités pris en charge par AIX Disk PCM sont self–configuring
parallel scsi disk (disk/scsi/scsd), MPIO other FC disk (disk/fcp/mpioosdisk) et MPIO
other iSCI (disk/iscsi/mpioosdisk). Le type d’unité pris en charge par le module AIX Tape
PCM est MPIO other FC tape (tape/fcp/mpioost).
Les unités de disque MPIO other FC et de bande MPIO other FC sont des sous–ensembles
respectivement de other Fibre Channel disks et de other Fibre Channel tapes. Une unité est
prise en charge comme unité MPIO other FC uniquement s’il n’existe pas d’attributs
prédéfinis ODM fournis par le vendeur et que l’unité a été certifiée fonctionner avec l’un des
modules AIX PCM par défaut. La certification ne garantit pas que toutes les fonctions de
l’unité sont prises en charge lorsque l’unité est configurée comme unité MPIO other FC.
Un disque MPIO other iSCSI est un sous–ensemble de other iSCSI disks. Une unité est
prise en charge comme disque MPIO other iSCSI uniquement s’il n’existe pas d’attributs
prédéfinis ODM fournis par le vendeur et que l’unité a été certifiée fonctionner avec le
module AIX PCM. La certification ne garantit pas que toutes les fonctions de l’unité sont
prises en charge lorsque l’unité est configurée comme disque MPIO other iSCSI.
Pour déterminer les unités prises en charge comme disques MPIO other FC, exécutez les
script suivants :
odmget –quniquetype=disk/fcp/mpioosdisk PdAt | grep deflt | cut –d’”’ –f2
Pour déterminer les unités prises en charge comme bandes MPIO other FC, exécutez les
script suivants :
odmget –q ”uniquetype=tape/fcp/mpioosdisk AND attribute=mpio_model_map PdAt
| grep deflt | cut –d’”’ –f2
Pour déterminer les unités prises en charge comme disques MPIO other iSCSI, exécutez
les script suivants :
odmget –quniquetype=disk/iscsi/mpioosdisk PdAt | grep deflt | cut –d’”’ –f2
Le script affiche la liste des données de requête qui contiennent le nom du fournisseur et le
modèle de l’unité.
Pour afficher toutes les unités MPIO installées sur le système, exécutez le script suivant :
odmget –qattribute=unique_id PdAt | grep uniquetype | cut –d’”’ –f2
Le script affiche la liste des types d’unités MPIO uniques prises en charge par les modules
AIX PCM par défaut et les modules PCM fournis par les vendeurs.
Attributs d’unité MPIO
Cette section décrit les attributs pris en charge uniquement par les unités à plusieurs
chemins. Vous pouvez afficher ou modifier les attributs avec Web–based System Manager,
SMIT ou des commandes (notamment lsattr et chdev).
L’attribut obligatoire que toutes les unités MPIO doivent prendre en charge est
reserve_policy. Généralement, une unité à plusieurs chemins dispose également de
l’attribut PR_key. Une unité à plusieurs chemins peut avoir d’autres attributs. Les autres
attributs d’unité sont les suivants :
reserve_policy Indique si une méthodologie de réservation est utilisée lorsque l’unité est
ouverte. Les valeurs sont les suivantes :
no_reserve
14-14
N’applique pas une méthodologie de réservation pour l’unité. L’unité
est accessible à d’autres initiateurs qui peuvent se trouver sur
d’autres systèmes hôtes.
Concepts de gestion de système AIX – Système d’exploitation et unités
single_path_reserve
Applique une méthodologie de réservation SCSI2 pour l’unité, ce qui
implique que l’unité est accessible uniquement à l’initiateur qui a
émis la réserve. Cette stratégie empêche d’autres initiateurs du
même hôte ou d’autres hôtes d’accéder à l’unité. La stratégie utilise
la réservation SCSI2 pour réserver l’unité à un seul initiateur
(chemin) et les commandes routées via les autres chemins créent un
conflit de réservation.
Des algorithmes de sélection qui alternent les commandes dans plusieurs
chemins peuvent provoquer une augmentation des échanges (thrashing)
lorsque la valeur single_path_reserve est sélectionnée. Supposons qu’un
module PCM d’unité dispose d’un attribut obligatoire affecté d’une valeur qui
distribue les E/S dans plusieurs chemins. Lorsque single_path_reserve est en
vigueur, le pilote d’unité doit émettre une réinitialisation BDR (Bus Device
Reset), puis une réservation en utilisant un nouveau chemin pour envoyer la
commande suivante pour arrêter la réservation précédente. Chaque fois qu’un
chemin différent est sélectionné, une augmentation des échanges se produit et
les performances se dégradent du fait de l’envoi d’une réinitialisation BDR et
d’une réservation vers l’unité cible. Le module AIX PCM ne permet pas de
sélectionner un algorithme qui pourrait provoquer une augmentation des
échanges.
PR_exclusive
Applique une réservation persistante SCSI3, une méthodologie
d’hôte exclusive lorsque l’unité est ouverte. La valeur de l’attribut
PR_key doit être unique pour chaque système hôte. L’attribut
PR_key permet d’empêcher les initiateurs d’autres systèmes hôtes
d’accéder à l’unité.
PR_shared
Applique une réservation persistante SCSI3, une méthodologie
d’hôte partagée lorsque l’unité est ouverte. La valeur de l’attribut
PR_key doit être unique pour chaque système hôte. Les initiateurs
des autres systèmes hôtes doivent s’enregistrer pour pouvoir
accéder à l’unité.
PR_key
Nécessaire uniquement si l’unité prend en charge les stratégies de
réservation persistante (PR_exclusive ou PR_shared).
Unités
14-15
Attributs de module PCM (Path Control Module)
Outre les modules par défaut AIX PCM, un module PCM d’unité spécifique peut être fourni
par le fournisseur de l’unité. Les attributs qui peuvent être modifiés par l’utilisateur sont
définis par le fournisseur de l’unité. Un module PCM d’unité spécifique peut avoir des
attributs d’unité et de chemin.
Les attributs d’unité pour les modules AIX PCM par défaut sont les suivants :
algorithm
Détermine la méthodologie qui distribue les E/S dans les chemins d’une
unité. Cet attribut a les valeurs suivantes :
failover
Envoie toutes les E/S dans un seul chemin. Si le chemin est
défaillant, un autre chemin est sélectionné pour envoyer toutes les
E/S. Cet algorithme suit tous les chemins activés dans une liste
ordonnée. Si le chemin utilisé pour envoyer les E/S connaît un
dysfonctionnement, le chemin suivant actif de la liste est sélectionné.
La séquence dans la liste est déterminée par l’attribut priorité de
chemin, page 14-17. Cet algorithme est disponible à la fois dans le
modules AIX Disk PCM et AIX Tape PCM.
round_robin
Distribue les E/S dans tous les chemins actifs. La priorité de chemin
est déterminée par la valeur d’attribut priorité de chemin, page 14-17.
Si un chemin connaît une défaillance ou est désactivé, il ne peut plus
envoyer les E/S. La priorité des autres chemins est recalculée pour
déterminer le pourcentage d’E/S qui doit être envoyé dans chaque
chemin. Si tous les chemins ont la même valeur, les E/S sont
envoyées à part égale dans tous les chemins actifs. Cet algorithme
est disponible uniquement dans le module AIX Disk PCM. Le module
AIX Tape PCM ne prend pas en charge round_robin.
hcheck_mode Détermine les chemins à vérifier lorsque la fonction de vérification
d’intégrité est utilisée. L’attribut prend en charge les modes suivants :
enabled
Envoie la commande healthcheck dans les chemins actifs.
failed
Envoie la commande healthcheck dans les chemins défaillants.
nonactive
(valeur par défaut) Envoie la commande healthcheck dans les
chemins sans E/S actives, y compris les chemins défaillants.
Si l’algorithme sélectionné est failover, la commande healthcheck
est également envoyée dans les chemins actifs sans E/S actives.
Si l’algorithme sélectionné est round_robin, la commande
healthcheck est envoyée uniquement dans les chemins défaillants,
car cet algorithme maintient actifs tous les chemins avec des E/S.
hcheck_interval Définit la fréquence d’exécution de la vérification de l’intégrité sur
les chemins d’une unité. L’attribut peut avoir une valeur comprise entre
0 et 3 600 secondes. Lorsque la valeur est 0, la vérification de l’intégrité
est désactivée.
dist_tw_width
14-16
définit la durée d’une « fenêtre de temps ». Il s’agit de la fenêtre de temps
pendant laquelle l’algorithme de détection des erreurs distribuées cumulera
les E/S retournées avec une erreur. L’unité de mesure d’attribut
dist_tw_width est la milliseconde. La diminution de la valeur de cet attribut
permet de réduire la durée de chaque échantillon et de réduire la sensibilité
des algorithmes à de petites rafales d’erreurs d’E/S. L’augmentation de la
valeur de cet attribut permet d’accroître la sensibilité des algorithmes à de
petites rafales d’erreurs et la probabilité de faire échouer un chemin.
Concepts de gestion de système AIX – Système d’exploitation et unités
dist_err_percent
définit le pourcentage des « fenêtres de temps » ayant une erreur autorisée
sur un chemin avant l’échec du chemin suite à de mauvaises
performances. dist_err_percent a une plage allant de 0 à 100.
L’algorithme de détection des erreurs distribuées sera désactivé lorsque
l’attribut est défini sur zéro (0). La valeur par défaut est zéro. L’algorithme
de détection des erreurs distribuées détecte les erreurs entre l’unité et la
carte. L’algorithme calcule un pourcentage d’échantillons contenant des
erreurs et fait échouer un chemin si cette valeur est supérieure à la valeur
de l’attribut dist_err_percent.
L’attribut de chemin pour le module AIX PCM est le suivant :
path priority
Modifie le comportement de la méthodologie de l’algorithme de la liste des
chemins.
Lorsque la valeur de l’attribut algorithm est failover, les chemins sont placés dans une
liste. La séquence de la liste détermine le chemin qui est sélectionné en premier et
s’il est défaillant, le chemin suivant sélectionné. La séquence est définie par la valeur
de l’attribut de priorité de chemin. La priorité 1 est la priorité la plus haute. Plusieurs
chemins peuvent avoir la même priorité, mais si tous les chemins ont la même
priorité, la sélection est basée sur le moment où chaque chemin a été configuré.
Lorsque la valeur de l’attribut algorithm est round_robin, la séquence est déterminée
par le pourcentage d’E/S. La priorité de chemin détermine le pourcentage d’E/S qui
doit être envoyé dans chaque chemin. Les E/S sont distribuées dans les chemins
actifs. Un chemin est sélectionné jusqu’à ce qu’il atteigne son pourcentage.
L’algorithme marque ensuite le chemin comme étant défaillant ou désactivé pour
distribuer les demandes E/S en fonction de la priorité de chemin.
Unités
14-17
14-18
Concepts de gestion de système AIX – Système d’exploitation et unités
Chapitre 15. Unités de bande
Ce chapitre présente les fonctions de gestion des unités de bande. La plupart de ces
fonctions exploitent les informations de la base de données de configuration des unités
du système, cette base de données regroupe deux bases : la base de données de
configuration prédéfinie qui contient les informations sur tous les types d’unité admis par le
système et la base de données personnalisée qui contient les informations sur chaque unité
installée sur le système. Pour que le système d’exploitation puisse utiliser une unité (de
bande ou non), elle doit être déclarée dans cette base personnalisée et relever d’un type
défini dans la base prédéfinie.
Cette section traite des points suivants :
• Attributs des unités de bande, page 15-2
• Fichiers spéciaux pour unités de bande, page 15-14
Les tâches de base des unités de bande sont répertoriées dans la section Tape Drives,
page 15-1 du document AIX 5L Version 5.3 System Management Guide: Operating
System and Devices.
Unités de bande
15-1
Attributs des unités de bande
Cette section décrit les attributs modifiables des unités de bande. Vous pouvez afficher
ou modifier les attributs avec Web–based System Manager, SMIT ou des commandes
(notamment lsattr et chdev).
Chaque type d’unité de bande n’utilise qu’une partie des attributs.
Présentation générale
Taille de bloc
L’attribut taille de bloc indique la taille de bloc à utiliser pour la lecture ou l’écriture d’une
bande. Les données sont inscrites sous forme de blocs de données délimités par des
espaces interblocs. Sur les bandes non formatées, il est préférable d’utiliser des blocs de
grande taille pour réduire le nombre d’espaces interblocs et disposer ainsi de davantage
d’espace pour l’inscription des données. La valeur 0 indique une taille de bloc variable.
Les valeurs par défaut et les valeurs admises varient en fonction de l’unité de bande.
Mémoires tampon
Lorsque vous positionnez l’attribut mémoires tampon sur yes (avec chdev, l’attribut mode),
les applications reçoivent un message de confirmation d’écriture dès le transfert des
données en mémoire tampon sur l’unité de bande, même si l’écriture de bande n’est pas
encore réalisée. Avec la valeur no, l’écriture n’est notifiée qu’une fois les données inscrites
sur la bande. La valeur no n’est pas compatible avec la lecture et l’écriture sur bande en
mode continu. La valeur par défaut est yes.
Lorsque cet attribut est positionné sur no, l’unité de bande est moins rapide mais elle
garantit une meilleure intégrité des données en cas de coupure de courant ou de
défaillance du système et facilite le traitement des fins de support.
Marques de fichier étendues
Lorsque cet attribut est positionné sur no (avec chdev, l’attribut extfm), une marque de
fichier standard est inscrite sur la bande chaque fois que nécessaire. La valeur yes
provoque l’inscription d’une marque de fichier étendue. Pour les unités de bande, cet
attribut peut être activé. La valeur par défaut est no. Par exemple, les marques de fichiers
étendues sur unités de bande 8 mm mobilisent 2,2 Mo et nécessitent pour leur inscription
jusqu’à 8,5 secondes. Les marques de fichiers standard utilisent 184 Ko et environ
1,5 secondes.
Lorsque vous utilisez des bandes 8 mm en mode adjonction, il est préférable d’utiliser les
marques de fichier étendues pour un meilleur positionnement après des opérations inverses
sur marques de fichier. Ceci permet de réduire les risques d’erreur.
Tension
La valeur yes (avec chdev, l’attribut ret) qu’après chaque insertion ou réinitialisation d’une
bande, la bande est automatiquement retendue. Cela signifie que la bande est déroulée
jusqu’à la fin puis entièrement rebobinée. Cette opération, qui demande plusieurs minutes,
diminue le risque d’erreurs. Avec la valeur no, l’unité de bande ne retend pas
automatiquement la bande. La valeur par défaut est yes.
Attribut de densité égale à #1 et attribut de densité égale à #2
L’attribut Densité égale à #1 (pour la commande chdev, l’attribut density_set_1) définit la
densité appliquée par l’unité de bande pour l’utilisation de fichiers spéciaux /dev/rmt*,
/dev/rmt*.1, /dev/rmt*.2 et /dev/rmt*.3. L’attribut Densité égale à #2 (avec chdev, l’attribut
density_set_2) définit la densité appliquée par l’unité de bande pour l’utilisation de fichiers
spéciaux /dev/rmt*.4, /dev/rmt*.5, /dev/rmt*.6 et /dev/rmt*.7. Pour plus de détails,
reportez–vous à Fichiers spéciaux pour unités de bande, page 15-14.
15-2
Concepts de gestion de système AIX – Système d’exploitation et unités
Les attributs de densité sont représentés par des nombres décimaux compris entre 0 et
255. La valeur 0 demande l’application de la densité par défaut pour l’unité de bande,
généralement la densité maximale. Les valeurs admises et leur signification varient en
fonction du type d’unité de bande. Ces attributs n’ont aucune répercussion sur la capacité
de lecture de l’unité pour des bandes écrites dans des densités admises par l’unité.
Habituellement, l’attribut densité égale à #1 est positionné à la valeur maximale possible
pour l’unité de bande et l’attribut densité égale à #2, à la seconde valeur maximale possible
pour l’unité de bande.
Réservation
Pour les unités de bande qui acceptent cet attribut (avec chdev, l’attribut res_support), la
valeur res_support=yes réserve l’unité de bande sur le bus SCSI à son ouverture.
Lorsque plusieurs cartes SCSI partagent l’unité de bande, l’activation de cet attribut permet
de limiter l’accès à une seule carte lorsque l’unité est ouverte. Certaines unités SCSI ne
prennent pas en charge cette fonction. D’autres ont une valeur prédéfinie pour cette
fonction et la prennent toujours en charge.
Taille de bloc de longueur variable
Cet attribut (avec chdev, l’attribut var_block_size) spécifie la taille de bloc requise par
l’unité de bande lors de l’écriture d’articles de longueur variable. Sur certaines unités de
bande SCSI, une taille de bloc non nulle doit être spécifiée (dans les données Mode Select)
lors de l’écriture d’articles de longueur variable. La taille de bloc est positionnée à 0 pour
indiquer des blocs de longueur variable. Reportez–vous aux informations spécifiques de
l’unité de bande SCSI pour déterminer le positionnement requis.
Compression de données
La valeur yes de cet attribut (avec chdev, l’attribut compress) passe l’unité de bande en
mode compression, si l’unité offre cette fonction. Dans ce cas, elle inscrit les données sur la
bande dans un format compressé pour stocker plus d’informations. La valeur no force
l’unité de bande à écrire les données en mode natif (non compressé). Cet attribut est sans
incidence sur les opérations de lecture. La valeur par défaut est yes.
Autochargement
La valeur yes de cet attribut (avec chdev, l’attribut autoload) active la fonction
d’autochargement, si l’unité offre cette fonction. Dans ce cas, si la fin de la bande est
atteinte lors d’une opération de lecture et d’écriture, la bande suivante est automatiquement
chargée pour poursuivre l’opération. Cette fonction est sans incidence sur les commandes
applicables uniquement à une seule bande en cartouche. La valeur par défaut est yes.
Délai entre deux tentatives
Cet attribut définit le délai d’attente en secondes au-delà duquel le système relance une
commande qui n’a pas abouti. Le système peut effectuer quatre tentatives maximum. Cet
attribut ne s’applique qu’aux unités de bande de type ost. La valeur par défaut est 45.
Délai de lecture/écriture
Cet attribut définit le délai maximal (en secondes) accordé au système pour exécuter avec
succès une commande de lecture (READ) ou d’écriture (WRITE). Cet attribut ne s’applique
qu’aux unités de bande de type ost. La valeur par défaut est 144.
Renvoyer erreur sur changement de bande
Lorsque l’attribut Renvoyer erreur sur changement de bande ou réinitialisation est
sélectionné, une erreur est renvoyée à l’ouverture lorsque l’unité de bande a été réinitialisée
ou que la bande a été changée. Une opération ayant laissé la bande au milieu de la bande
à la fermeture doit avoir eu lieu. L’erreur renvoyée est un –1 et errno a la valeur EIO. Une
fois présentée à l’application, la situation d’erreur est annulée. De même, la reconfiguration
de l’unité de bande annule la situation d’erreur.
Unités de bande
15-3
Attributs pour unités de bande 4 mm 2 Go (type 4mm2gb)
Taille de bloc
La valeur par défaut est 1024.
Mémoires tampon
Reportez-vous aux informations générales fournies pour cet attribut.
Attributs à valeur fixe
Pour les unités de bande déclarées de ce type, des valeurs prédéfinies non modifiables
sont affectées aux attributs de tension, de réservation, de taille de bloc variable et de
densité. Les valeurs de densité sont prédéfinies car l’unité de bande écrit toujours
en mode 2 Go.
Attributs pour unités de bande 4 mm 4 Go (type 4mm4gb)
Taille de bloc
La valeur par défaut est 1024.
Mémoires tampon
Reportez–vous aux informations générales fournies pour cet attribut.
Attribut de densité égale à #1 et attribut de densité égale à #2
L’utilisateur ne peut pas modifier la densité appliquée par cette unité. L’unité module
automatiquement la densité utilisée en fonction du type de support DDS (Digital Data
Storage) installé :
Type de support Configuration de l’unité
DDS
Lecture seulement
DDS ||||
Lecture/écriture en mode 2 Go uniquement
DDS2
Lecture dans l’une ou l’autre des densités, écriture en mode 4 Go
seulement
non–DDS
Non pris en charge ; cartouche éjectée
Compression de données
Reportez–vous aux informations générales fournies pour cet attribut.
Attributs à valeur fixe
Pour les unités de bande déclarées de ce type, des valeurs prédéfinies non modifiables
sont affectées aux attributs de tension, de réservation, de taille de bloc variable et de
densité.
Attributs pour unités de bande 8 mm 2,3 Go (type 8mm)
Taille de bloc
La valeur par défaut est 1024. Une valeur inférieure réduit le volume de données stockées
sur bande.
Mémoires tampon
Reportez-vous aux informations générales fournies pour cet attribut.
Marques de fichier étendues
Reportez-vous aux informations générales fournies pour cet attribut.
15-4
Concepts de gestion de système AIX – Système d’exploitation et unités
Attributs à valeur fixe
Pour les unités de bande déclarées de ce type, des valeurs prédéfinies non modifiables
sont affectées aux attributs de tension, de réservation, de taille de bloc variable et de
densité. Les valeurs de densité sont prédéfinies car l’unité de bande écrit toujours
en mode 2,3 Go.
Attributs pour unités de bande 8 mm 5 Go (type 8mm5gb)
Taille de bloc
La valeur par défaut est 1024. Pour une bande inscrite en mode 2,3 Go, une valeur
inférieure réduit la quantité de données stockées.
Mémoires tampon
Reportez-vous aux informations générales fournies pour cet attribut.
Marques de fichier étendues
Reportez-vous aux informations générales fournies pour cet attribut.
Attribut de densité égale à #1 et attribut de densité égale à #2
Valeurs possibles :
Valeur
Signification
140
Mode 5 Go (compression possible)
21
Mode 5 Go (compression impossible)
20
Mode 2,3 Go
0
Valeur par défaut (mode 5 Go)
Les valeurs par défaut sont 140 pour l’attribut densité égale à #1 et 20 pour l’attribut densité
égale à #2. La valeur 21 associée à l’un de ces attributs autorise la lecture ou l’écriture en
mode 5 Go non compressé.
Compression de données
Reportez-vous aux informations générales fournies pour cet attribut.
Attributs à valeur fixe
Pour les unités de bande déclarées de ce type, des valeurs prédéfinies non modifiables
sont affectées aux attributs de tension, de réservation, de taille de bloc variable et de
densité.
Attributs pour unités de bande 8 mm 20000 Mo (autoconfiguration)
Taille de bloc
La valeur par défaut est 1024.
Mémoires tampon
Reportez-vous aux informations générales fournies pour cet attribut.
Marques de fichier étendues
Reportez-vous aux informations générales fournies pour cet attribut.
Unités de bande
15-5
Paramètre de densité #1 et paramètre de densité #2
L’unité peut lire et écrire sur des cartouches de format 20 Go. Pendant la lecture, l’unité
détermine automatiquement le format des données inscrites sur la bande. Pendant
l’écriture, la valeur de la densité détermine le format des données inscrites sur la bande.
Valeurs possibles :
Valeur
Signification
39
Mode 20 Go (compression possible)
0
Valeur par défaut (mode 20 Go)
La valeur par défaut est 39 pour les attributs densité égale à #1 et densité égale à #2.
Compression de données
Reportez-vous aux informations générales fournies pour cet attribut.
Attributs à valeur fixe
Pour les unités de bande déclarées de ce type, des valeurs prédéfinies non modifiables
sont affectées aux attributs de tension, de réservation, de taille de bloc variable et de
densité.
Attributs pour unités de bande 35 Go (type 35gb)
Taille de bloc
La capacité de traitement du Bull 7205 Modèle 311 est affectée par la taille de bloc. Pour
cette unité, la taille de bloc minimale recommandée est de 32 Ko. Toute valeur inférieure
réduit le débit des données (temps de sauvegarde/restauration). Le tableau ci–après
répertorie les tailles de bloc recommandées par les commandes :
Commande prise en
charge
Taille de bloc par défaut
(octets)
RECOMMENDATION
BACKUP
32 Ko ou 51,2 Ko
(par défaut)
32 Ko ou 51,2 Ko, selon que
la commande Backup est
par nom ou pas. Aucune
modification de l’utilisateur
n’est requise.
TAR
10 Ko
Il y a erreur dans le manuel
qui indique une taille de bloc
de 512 Ko. Définissez le
paramètre de taille de bloc à
–N64.
MKSYSB
Voir BACKUP
MKSYSB utilise la
commande BACKCUP.
Aucune modification de
l’utilisateur n’est requise.
DD
n/a
Définissez le paramètre de
taille de bloc à bs=32K.
CPIO
n/a
Définissez le paramètre de
taille de bloc à –C64.
Remarque : Vous devez connaître la puissance et la capacité de traitement lorsque vous
sélectionnez une taille de bloc. Les tailles de bloc réduites affectent les
performances, mais pas la puissance de traitement. Les puissances de
traitement des formats 2,6 Go (densité) et 6 Go (densité) sont affectées si
vous utilisez une taille de bloc inférieure à la taille recommandée.
Par exemple: la sauvegarde de 32 Go dure environ 22 heures avec une taille
15-6
Concepts de gestion de système AIX – Système d’exploitation et unités
de bloc de 1024 octets. La même sauvegarde dure environ 2 heures avec une
taille de bloc de 32 Ko.
Mémoires tampon
Reportez-vous aux informations générales fournies pour cet attribut.
Marques de fichier étendues
Reportez-vous aux informations générales fournies pour cet attribut.
Paramètre de densité #1 et paramètre de densité #2
Le tableau suivant indique le type de cartouche de données pris en charge et les
paramètres de densité (décimaux et hexadécimaux) pour l’unité de bande Bull 7205–311.
Lors d’une opération de restauration (lecture), l’unité de bande règle automatiquement la
densité sur la densité écrite. Lors d’une opération de sauvegarde (écriture), vous devez
régler la densité sur celle de la cartouche de données que vous utilisez.
Cartouches de
données
prises en
charge
Capacité native Capacité des
données
compressées
Web-based
System
Manager ou
SMIT
Valeur de
densité
hexadécimale
DLTtape III
2,6 Go
2,6 Go (sans
compression)
6,0 Go (sans
compression)
20,0 Go (par
défaut pour
l’unité)
23
17h
24
18h
25
19h
6,0 Go
10,0 Go
DLTtapeIIIxt
15,0 Go
30,6 Go (par
défaut pour
l’unité)
25
19h
DLTtapeIV
20,0 Go
40,0 Go
26
1Ah
35,0 Go
70,0 Go (par
défaut pour
l’unité)
27
1Bh
Remarque : Si vous demandez une capacité native non prise en charge pour la cartouche
de données, l’unité utilise la puissance de traitement maximale prise en charge
pour la cartouche chargée dans l’unité.
Compression de données
La compression réelle dépend du type de données écrites. (voir le tableau ci-dessus) Un
rapport de compression de 2/1 est adopté pour cette capacité des données compressées.
Attributs à valeur fixe
Reportez-vous aux informations générales fournies pour cet attribut.
Attributs pour unités de bande 1/4 pouce 150 Mo (type 150mb)
Taille de bloc
La taille de bloc par défaut est 512. Pour les blocs de longueur variable, la seule taille de
bloc possible est 0.
Mémoires tampon
Reportez-vous aux informations générales fournies pour cet attribut.
Marques de fichier étendues
L’écriture sur une bande 1/4 pouce ne peut être effectuée qu’en début de bande (BOT) ou
sur bande vierge. Si la bande contient des données, vous ne pouvez écraser les données
qu’à partir du début de la bande. Pour ajouter des données sur une bande non vide et
Unités de bande
15-7
rebobinée, vous devez la faire dérouler jusqu’à la marque de fichier suivante (signalée par
le système lorsqu’elle est détectée par un message d’erreur). Vous pouvez alors reprendre
les opérations d’écriture.
Tension
Reportez-vous aux informations générales fournies pour cet attribut.
Paramètre de densité #1 et paramètre de densité #2
Valeurs possibles :
Valeur
Signification
16
QIC–150
15
QIC–120
0
Valeur par défaut (QIC–150) ou dernière valeur de densité utilisée par
le système.
Les valeurs par défaut sont 16 pour l’attribut densité égale à #1 et 15 pour l’attribut densité
égale à #2.
Attributs à valeur fixe
Pour les unités de bande déclarées de ce type, des valeurs prédéfinies non modifiables
sont affectées aux attributs de marques de fichier étendues, de réservation, de taille de bloc
variable et de compression.
Attributs pour unités de bande 1/4 pouce 525 Mo (type 525mb)
Taille de bloc
La taille de bloc par défaut est 512. Les autres valeurs possibles sont 0 pour des blocs de
longueur variable et 1024.
Mémoires tampon
Reportez-vous aux informations générales fournies pour cet attribut.
Marques de fichier étendues
L’écriture sur une bande 1/4 pouce ne peut être effectuée qu’en début de bande (BOT) ou
sur bande vierge. Si la bande contient des données, vous ne pouvez écraser les données
qu’à partir du début de la bande. Pour ajouter des données sur une bande non vide et
rebobinée, vous devez la faire dérouler jusqu’à la marque de fichier suivante (signalée par
le système lorsqu’elle est détectée par un message d’erreur). Vous pouvez alors reprendre
les opérations d’écriture.
Tension
Reportez-vous aux informations générales fournies pour cet attribut.
Paramètre de densité #1 et paramètre de densité #2
Valeurs possibles :
Valeur
Signification
17
QIC–525*
16
QIC–150
15
QIC–120
0
Valeur par défaut (QIC–525) ou dernière valeur de densité utilisée par
le système.
* QIC–525 est le seul mode qui accepte une taille de bloc de 1024.
15-8
Concepts de gestion de système AIX – Système d’exploitation et unités
Les valeurs par défaut sont 17 pour l’attribut densité égale à #1 et 16 pour l’attribut densité
égale à #2.
Attributs à valeur fixe
Pour les unités de bande déclarées de ce type, des valeurs prédéfinies non modifiables
sont affectées aux attributs de marques de fichier étendues, de réservation, de taille de bloc
variable et de compression.
Attributs pour unités de bande 1/4 pouce 1200 Mo (type 1200mb–c)
Taille de bloc
La taille de bloc par défaut est 512. Les autres valeurs possibles sont 0 pour des blocs de
longueur variable et 1024.
Mémoires tampon
Reportez-vous aux informations générales fournies pour cet attribut.
Marques de fichier étendues
L’écriture sur une bande 1/4 pouce ne peut être effectuée qu’en début de bande (BOT) ou
sur bande vierge. Si la bande contient des données, vous ne pouvez écraser les données
qu’à partir du début de la bande. Pour ajouter des données sur une bande non vide et
rebobinée, vous devez la faire dérouler jusqu’à la marque de fichier suivante (signalée par
le système lorsqu’elle est détectée par un message d’erreur). Vous pouvez alors reprendre
les opérations d’écriture.
Tension
Reportez-vous aux informations générales fournies pour cet attribut.
Paramètre de densité #1 et paramètre de densité #2
Valeurs possibles :
Valeur
Signification
21
QIC–1000*
17
QIC–525*
16
QIC–150
15
QIC–120
0
Valeur par défaut (QIC–1000) ou dernière valeur de densité utilisée par
le système.
* QIC–525 et QIC–1000 sont les seuls modes qui acceptent une taille de bloc de 1024.
Les valeurs par défaut sont 21 pour l’attribut densité égale à #1 et 17 pour l’attribut densité
égale à #2.
Attributs à valeur fixe
Pour les unités de bande déclarées de ce type, des valeurs prédéfinies non modifiables
sont affectées aux attributs de marques de fichier étendues, de réservation, de taille de bloc
variable et de compression.
Unités de bande
15-9
Attributs pour unités de bande 4 mm 12 000 Mo (autoconfiguration)
Taille de bloc
La capacité de traitement de l’unité de bande Bull 12 000 Mo 4 mm est affectée par la taille
de bloc. Pour cette unité, la taille de bloc minimale recommandée est de 32 Ko.
Toute valeur inférieure réduit le débit des données (temps de sauvegarde/restauration).
Le tableau ci–après répertorie les tailles de bloc recommandées par les commandes :
Commande prise en
charge
Taille de bloc par défaut
(octets)
RECOMMENDATION
BACKUP
32 Ko ou 51,2 Ko
(par défaut)
32 Ko ou 51,2 Ko, selon que
la commande Backup est
par nom ou pas. Aucune
modification de l’utilisateur
n’est requise.
TAR
10 Ko
Il y a erreur dans le manuel
qui indique une taille de bloc
de 512 Ko. Définissez le
paramètre de taille de bloc à
–N64.
MKSYSB
Voir BACKUP
MKSYSB utilise la
commande BACKCUP.
Aucune modification de
l’utilisateur n’est requise.
DD
n/a
Définissez le paramètre de
taille de bloc à bs=32K
CPIO
n/a
Définissez le paramètre de
taille de bloc à –C64.
Remarque : Vous devez connaître la puissance et la capacité de traitement lorsque vous
sélectionnez une taille de bloc. Les tailles de bloc réduites affectent les
performances, mais pas la puissance de traitement.
Mémoires tampon
Reportez–vous aux informations générales fournies pour cet attribut.
Marques de fichier étendues
Reportez–vous aux informations générales fournies pour cet attribut.
Paramètre de densité #1 et paramètre de densité #2
Le tableau suivant indique le type de cartouche de données pris en charge et les
paramètres de densité (décimaux et hexadécimaux) pour l’unité de bande Bull 12 000 Mo 4
mm. Lors d’une opération de restauration (lecture), l’unité de bande règle
automatiquement la densité sur la densité écrite. Lors d’une opération de sauvegarde
(écriture), vous devez régler la densité sur celle de la cartouche de données que vous
utilisez.
15-10
Concepts de gestion de système AIX – Système d’exploitation et unités
Cartouches de
données
prises en
charge
Capacité
native
Capacité des
données
compressées
Valeur de
densité
Web-based
System
Manager ou
SMIT
Valeur de
densité
hexadécimale
DDS III
2,0 Go
4,0 Go
19
13h
DDS2
4,0 Go
8,0 Go
36
24h
DDS3
12,0 Go
24,0 Go
37
25h
Remarque : Si vous demandez une capacité native non prise en charge pour la cartouche
de données, l’unité utilise la puissance de traitement maximale prise en charge
pour la cartouche chargée dans l’unité.
Compression de données
La compression réelle dépend du type de données écrites. (voir le tableau ci–dessus) Un
rapport de compression de 2/1 est adopté pour cette capacité des données compressées.
Attributs à valeur fixe
Reportez–vous aux informations générales fournies pour cet attribut.
Attributs pour unités de bande 1/4 pouce 13 000 Mo (autoconfiguration)
Taille de bloc
La taille de bloc par défaut est 512. Les autres valeurs possibles sont 0 pour des blocs de
longueur variable et 1024.
Mémoires tampon
Reportez–vous aux informations générales fournies pour cet attribut.
Marques de fichier étendues
L’écriture sur une bande 1/4 pouce ne peut être effectuée qu’en début de bande (BOT) ou
sur bande vierge. Si la bande contient des données, vous ne pouvez écraser les données
qu’à partir du début de la bande. Pour ajouter des données sur une bande non vide et
rebobinée, vous devez la faire dérouler jusqu’à la marque de fichier suivante (signalée par
le système lorsqu’elle est détectée par un message d’erreur). Vous pouvez alors reprendre
les opérations d’écriture.
Tension
Reportez–vous aux informations générales fournies pour cet attribut.
Paramètre de densité #1 et paramètre de densité #2
Valeurs possibles :
Valeur
Signification
33
QIC–5010–DC*
34
QIC–2GB*
21
QIC–1000*
17
QIC–525*
16
QIC–150
15
QIC–120
0
Valeur par défaut (QIC–5010–DC)*
Unités de bande
15-11
* QIC–525, QIC–1000, QIC–5010–DC et QIC–2GB sont les seuls modes qui acceptent une
taille de bloc de 1024.
Les valeurs par défaut sont 33 pour l’attribut densité égale à #1 et 34 pour l’attribut densité
égale à #2.
Attributs à valeur fixe
Pour les unités de bande déclarées de ce type, des valeurs prédéfinies non modifiables
sont affectées aux attributs de marques de fichier étendues, de réservation et de taille de
bloc variable.
Attributs pour unités de bande 9 pistes 1/2 pouce (type 9trk)
Taille de bloc
La valeur par défaut est 1024.
Mémoires tampon
Reportez-vous aux informations générales fournies pour cet attribut.
Paramètre de densité #1 et paramètre de densité #2
Valeurs possibles :
Valeur
Signification
3
6 250 bits par pouce (bpp)
2
1 600 bpp
0
Densité précédemment utilisée
Les valeurs par défaut sont 3 pour l’attribut densité égale à #1 et 2 pour l’attribut densité
égale à #2.
Attributs à valeur fixe
Pour les unités de bande déclarées de ce type, des valeurs prédéfinies non modifiables
sont affectées aux attributs de marques de fichier étendues, de tension, de réservation,
de taille de bloc variable et de compression.
Attributs pour cartouche 1/2 pouce 3490e (type 3490e)
Taille de bloc
La valeur par défaut est 1024. Cette unité offre un débit de transfert de données élevé et la
taille de bloc peut se révéler critique pour certaines opérations. La vitesse d’exploitation
peut être sensiblement améliorée avec des blocs de grande taille. De façon générale, il est
conseillé d’opter pour la plus grande taille de bloc possible.
Remarque : Augmenter la taille de bloc peut entraîner des incompatibilités avec d’autres
programmes installés sur le système. Dans ce cas, vous en êtes averti lors
de l’exécution des programmes concernés par le message :
Un appel système a reçu un paramètre incorrect.
Mémoires tampon
Reportez-vous aux informations générales fournies pour cet attribut.
Compression
Reportez-vous aux informations générales fournies pour cet attribut.
15-12
Concepts de gestion de système AIX – Système d’exploitation et unités
Autochargement
Cette unité est équipée d’un séquenceur de bande, fonction d’autochargement qui charge
et éjecte séquentiellement les cartouches de bande d’une série à partir d’un chargeur de
cartouche Pour cette opération, le commutateur situé sur le panneau avant de l’unité doit
être positionné sur AUTO et l’attribut d’autochargement sur yes.
Attributs pour autres bandes SCSI (type ost)
Taille de bloc
La valeur par défaut est 512, mais elle peut être ajustée à la taille de bloc par défaut de
votre unité de bande. Les valeurs les plus courantes sont 512 et 1024. Les unités de bande
8 et 4 mm utilisent généralement une taille de bloc de 1024. L’espace sur bande est mal
exploité si l’attribut taille de bloc est laissé à 512. La valeur 0 indique une taille de bloc
variable sur certaines unités.
Mémoires tampon
Reportez-vous aux informations générales fournies pour cet attribut.
Marques de fichier étendues
Reportez-vous aux informations générales fournies pour cet attribut.
Paramètre de densité #1 et paramètre de densité #2
La valeur par défaut est 0 pour les deux densités. Les valeurs possibles et leur signification
varient en fonction du type d’unité de bande.
Réservation
La valeur par défaut est no. Elle peut être basculée sur yes si l’unité accepte la fonction
de réservation. En cas de doute, conservez la valeur no.
Taille de bloc de longueur variable
La valeur par défaut est 0. Les valeurs non nulles sont utilisées sur des unités QIC
(Quarter Inch Cartridge). Pour plus de précisions, reportez-vous aux informations
relatives à votre unité de bande.
Délai entre deux tentatives
Cet attribut ne s’applique qu’aux unités de bande de type ost.
Délai de lecture/écriture
Cet attribut ne s’applique qu’aux unités de bande de type ost.
Attributs à valeur fixe
Pour les unités de bande déclarées de type ost, des valeurs prédéfinies non modifiables
sont affectées aux attributs de marques de fichier étendues, de tension et de compression.
Unités de bande
15-13
Fichiers spéciaux pour unités de bande
L’écriture et la lecture de fichiers sur bande se fait à l’aide de fichiers spéciaux rmt.
Plusieurs types de fichiers spéciaux sont associés à chaque unité de bande connue du
système d’exploitation. Ces fichiers sont /dev/rmt*, /dev/rmt*.1, /dev/rmt*.2, ... /dev/rmt*.7
où rmt* représente le nom logique d’une unité de bande, par exemple rmt0 ou rmt1.
Sélectionner l’un de ces fichiers spéciaux revient à choisir le mode d’exécution des
opérations d’E/S sur l’unité de bande.
Densité
Vous pouvez opter pour une densité égale à #1 ou à #2. Ces densités
sont définies dans les attributs de l’unité de bande. La densité
maximale possible est généralement attribuée à la densité #1 et la
valeur maximale suivante possible à la densité #2. C’est pourquoi, par
abus de langage, les fichiers spéciaux utilisant la densité égale à #1
sont parfois assortis du qualificatif Haute densité et les fichiers spéciaux
utilisant la densité égale à #2 du qualificatif Faible densité. Lors de la
lecture de la bande, le paramètre de densité est ignoré.
Rebobinage à
la fermeture
Vous pouvez demander le rebobinage automatique complet de la
bande à la fermeture du fichier spécial relatif à l’unité de bande. Dans
ce cas, le positionnement en début de bande est intégré au processus
de fermeture du fichier.
Tension à
l’ouverture
Vous pouvez demander que la bande soit retendue à l’ouverture du
fichier, c’est-à-dire déroulée jusqu’à la fin, puis entièrement rebobinée.
Cette précaution réduit le risque d’erreurs. Dans ce cas, le
positionnement en début de bande est intégré au processus d’ouverture
du fichier.
Le tableau ci-dessous donne la liste des fichiers spéciaux rmt et de leurs caractéristiques.
Fichier spécial
Rebobinage à la
fermeture
Tension à
l’ouverture
Densité
/dev/rmt*
oui
non
#1
/dev/rmt*.1
non
non
#1
/dev/rmt*.2
oui
oui
#1
/dev/rmt*.3
non
oui
#1
/dev/rmt*.4
oui
non
#2
/dev/rmt*.5
non
non
#2
/dev/rmt*.6
oui
oui
#2
/dev/rmt*.7
non
oui
#2
Si, par exemple, vous souhaitez écrire trois fichiers sur bande dans l’unité de bande rmt2,
le premier en début de bande et les deux autres à la suite, avec la densité égale à #1 pour
l’unité de bande, vous pouvez utiliser, dans l’ordre, les fichiers spéciaux suivants :
1. /dev/rmt2.3
2. /dev/rmt2.1
3. /dev/rmt2
15-14
Concepts de gestion de système AIX – Système d’exploitation et unités
Explication :
• Le fichier /dev/rmt2.3 est choisi comme premier fichier car il est doté de l’option de
rebobinage à l’ouverture qui garantit l’écriture du premier fichier en début de bande.
L’option de rebobinage à la fermeture n’est pas retenue car l’opération d’E/S suivante
doit commencer à la fin de ce fichier. Si la bande est déjà positionnée au début,
l’utilisation du fichier /dev/rmt2.1 comme premier fichier se révèle plus rapide,
la phase de retension de la bande étant omise.
• Le fichier /dev/rmt2.1 est choisi comme deuxième fichier car il ne comporte ni l’option
de retension à l’ouverture, ni l’option de rebobinage à la fermeture. Le repositionnement
en début de bande à l’ouverture ou à la fermeture du fichier est inutile.
• Le fichier /dev/rmt2 est choisi comme troisième et dernier fichier car l’option de
retension à l’ouverture n’est pas souhaitée, ce fichier étant précédé du deuxième fichier.
En revanche, l’option de rebobinage à la fermeture est sélectionnée car aucune
opération d’écriture n’est prévue à la suite du troisième fichier. La prochaine utilisation de
la bande commencera au début de la bande.
Le choix du fichier spécial rmt n’est pas le seul moyen de contrôle des opérations sur
bande ; vous disposez également de la commande tctl.
Unités de bande
15-15
15-16
Concepts de gestion de système AIX – Système d’exploitation et unités
Annexe A. Comparaisons pour les gestionnaires
de systèmes BSD
Rubriques de cette annexe :
• Comparaison de AIX et de BSD pour les gestionnaires de systèmes, page A-2
• Présentation de AIX pour les gestionnaires de systèmes BSD, page A-3
• Principales différences entre 4.3 BSD et ce système d’exploitation, page A-4
• Comptabilité pour les gestionnaires de systèmes BSD 4.3, page A-7
• Sauvegarde pour les gestionnaires de systèmes BSD 4.3, page A-9
• Démarrage pour les gestionnaires de systèmes BSD 4.3, page A-10
• Commandes d’administration de système pour les gestionnaires de systèmes BSD 4.3,
page A-11
• Commande Cron pour les gestionnaires de systèmes BSD 4.3, page A-15
• Unités pour les gestionnaires de systèmes BSD 4.3, page A-16
• Tableau de comparaison de fichiers pour 4.3 BSD, SVR4 et ce système d’exploitation,
page A-17
• Systèmes de fichiers pour les gestionnaires de systèmes BSD 4.3, page A-19
• Recherche et analyse des fichiers pour les gestionnaires de systèmes BSD 4.3,
page A-20
• Espace de pagination pour les gestionnaires de systèmes BSD 4.3, page A-21
• Mise en réseau pour les gestionnaires de systèmes BSD 4.3, page A-22
• Documentation en ligne et Commande man pour les gestionnaires de système BSD 4.3,
page A-25.
• NFS et NIS (Yellow Pages auparavant) pour les gestionnaires de systèmes BSD 4.3,
page A-26
• Mots de passe pour les gestionnaires de systèmes BSD 4.3, page A-27
• Mesure des performances et réglage pour les gestionnaires de systèmes BSD 4.3,
page A-30
• Imprimantes pour les gestionnaires de systèmes BSD 4.3, page A-31
• Terminaux pour les gestionnaires de systèmes BSD 4.3, page A-34
• UUCP pour les gestionnaires de systèmes BSD 4.3, page A-35
Comparaisons pour les gestionnaires de systèmes BSD
A-1
Comparaison de AIX et de BSD
pour les gestionnaires de systèmes
Les articles suivants contiennent des informations sur les administrateurs 4.3 BSD :
•
Présentation de AIX pour les gestionnaires de systèmes BSD, page A-3
•
Principales différences entre 4.3 BSD et ce système d’exploitation, page A-4
– Comptabilité pour les gestionnaires de systèmes BSD 4.3, page A-7
– Sauvegarde pour les gestionnaires de systèmes BSD 4.3, page A-9
– Démarrage pour les gestionnaires de systèmes BSD 4.3, page A-10
– Commandes d’administration de système pour les gestionnaires de systèmes
BSD 4.3, page A-11
– Commande Cron pour les gestionnaires de systèmes BSD 4.3, page A-15
– Unités pour les gestionnaires de systèmes BSD 4.3, page A-16
– Tableau de comparaison de fichiers pour 4.3 BSD, SVR4 et ce système
d’exploitation, page A-17
– Systèmes de fichiers pour les gestionnaires de systèmes BSD 4.3, page A-19
– Recherche et analyse des fichiers pour les gestionnaires de systèmes BSD 4.3,
page A-20
– Espace de pagination pour les gestionnaires de systèmes BSD 4.3, page A-21
– Mise en réseau pour les gestionnaires de systèmes BSD 4.3, page A-22
– Documentation en ligne et Commande man pour les gestionnaires de système
BSD 4.3, page A-25.
– NFS et NIS (Yellow Pages auparavant) pour les gestionnaires de systèmes BSD 4.3,
page A-26
– Mots de passe pour les gestionnaires de systèmes BSD 4.3, page A-27
– Mesure des performances et réglage pour les gestionnaires de systèmes BSD 4.3,
page A-30
– Imprimantes pour les gestionnaires de systèmes BSD 4.3, page A-31
– Terminaux pour les gestionnaires de systèmes BSD 4.3, page A-34
– UUCP pour les gestionnaires de systèmes BSD 4.3, page A-35
A-2
Concepts de gestion de système AIX – Système d’exploitation et unités
Introduction à ce système d’exploitation pour administrateurs
système BSD
Voici quelques conseils qui vous aideront à démarrer l’administration du système :
• Commencez par vous connecter, en tant qu’utilisateur racine, sur la console graphique.
• Exécutez les tâches de gestion à partir de la console système tant que vous n’êtes pas
complètement à l’aise avec le système : il est plus simple de travailler depuis cette
console qu’à partir d’un terminal distant. Une fois qu’AIX n’aura plus de secret pour vous,
vous pourrez sans problème travailler à distance depuis un terminal xterm ou ASCII.
• Plusieurs utilitaires de ce système d’exploitation sont proposés pour la gestion du
système. Ces utilitaires sont les suivants :
– System Management Interface Tool (SMIT). SMIT fournit une interface entre les
gestionnaires de systèmes et les commandes de configuration et de gestion. SMIT
peut aider les gestionnaires de systèmes dans la plupart des tâches d’administration
du système. Pour plus d’informations, voir System Management Interface Tool,
page 13-1.
– Object Data Manager (ODM). L’ODM fournit des routines pour accéder à des objets à
partir de bases de données ODM. Les bases de données ODM contiennent des
informations de configuration sur les unités. Pour plus d’informations sur la manière
dont les bases de données ODM enregistrent des informations sur les unités, voir
Devices, page 14-1.
– Contrôleur de ressources système SRC (System Resource Controller). Le SRC
fournit un accès et le contrôle des démons et autres ressources système via une
interface unique. Pour plus d’informations, voir System Resource Controller
Overview, page 10-2.
Comparaisons pour les gestionnaires de systèmes BSD
A-3
Principales différences entre 4.3 BSD et ce système
d’exploitation
Cet article résume les principales différences entre 4.3 BSD et ce système d’exploitation.
Pour obtenir plus d’informations sur ces thèmes, reportez–vous à la liste d’articles dans la
section Comparaison entre AIX et BSD pour les administrateurs système, page A-2.
Stockage des données de configuration
BSD 4.3 stocke généralement les données de configuration dans des fichiers ASCII.
Les informations apparentées se trouvent sur une même ligne et le traitement des
enregistrements (tri et recherche) peut être effectué sur le fichier ASCII lui-même. Ces
enregistrements, de longueur variable, sont terminés par un saut de ligne. BSD 4.3 offre
des outils permettant de convertir les fichiers ASCII volumineux en format base de données
(dbm). Les fonctions de bibliothèque correspondantes explore la paire de fichiers dbm s’ils
existent, ou, dans le cas contraire, le fichier ASCII d’origine.
Certaines données de configuration du présent système d’exploitation sont stockées dans
des fichiers ASCII, mais le plus souvent sous forme de strophes. Une strophe est un
ensemble d’éléments d’information apparentés, stockés dans un groupe de lignes. Chaque
élément est doté d’une étiquette, simplifiant l’appréhension du contenu du fichier.
Le présent système d’exploitation prend également en charge les versions dbm des mots
de passe et des informations utilisateur. Les fichiers /etc/passwd, /etc/group et /etc/inittab
sont en outre des exemples de fichiers de ce système d’exploitation où les informations
sont stockées sous forme traditionnelle et non sous forme de strophes.
Les autres données de configuration de ce système d’exploitation sont stockées dans des
fichiers maintenus par le gestionnaire d’objet ODM (Object Data Manager). Web-based
System Manager ou SMIT (System Management Interface Tool) peut manipuler et afficher
les informations des fichiers ODM. Vous pouvez également faire appel directement aux
commandes ODM pour visualiser ces fichiers. Pour interroger les fichiers ODM, vous
disposez des commandes :
• odmget,
• odmshow.
Pour modifier ces fichiers, des commandes :
• odmadd,
• odmcreate,
• odmdrop,
• odmchange,
• odmdelete.
Attention : Modifier les fichiers ODM de manière incorrecte peut provoquer l’arrêt du
système, avec impossibilité de le relancer. Ne faites pas appel aux commandes ODM
que si des commandes spécifiques (telles que celles générées par SMIT ou Web-based
System Manager) échouent.
A-4
Concepts de gestion de système AIX – Système d’exploitation et unités
Gestion de la configuration
Au démarrage d’un système sous le présent système d’exploitation, un ensemble de
commandes de configuration sont appelées par le gestionnaire de configuration. Ces
commandes sont appelées méthodes. Elles identifient les unités du système et mettent à
jour les fichiers ODM appropriés dans le répertoire /etc/objrepos.
Les fichiers unité spéciaux du répertoire /dev ne sont pas préinstallés. Certains fichiers
spéciaux (fichiers disque, par exemple) sont créés automatiquement au cours du processus
de configuration du démarrage. D’autres fichiers spéciaux (ceux des terminaux ASCII, par
exemple) doivent être créés par l’administrateur système par le biais du menu Unités de
SMIT ou de l’application Web-based System Manager Devices. Ces informations sont
conservées dans ODM en vue d’un usage ultérieur.
Gestion de disque
Sous le présent système d’exploitation, les unités de disque sont des volumes physiques.
Les partitions forment des volumes logiques. Comme dans BSD 4.3, un volume physique
peut être associé à plusieurs volumes logiques. Mais, contrairement à BSD 4.3, un seul
volume de ce système d’exploitation peut s’étendre sur plusieurs volumes physiques. Pour
ce faire, il faut regrouper les volumes physiques dans un groupe de volumes et créer les
volumes logiques sur ce groupe.
Voici quelques-unes des commandes relatives aux systèmes de fichiers et à la gestion des
volumes :
• crfs
• varyonvg
• varyoffvg
• lsvg
• importvg
• exportvg
Les commandes BSD 4.3 suivantes sont également disponibles :
• mkfs
• fsck
• fsdb
• mount
• umount
Les différences entre ces commandes pour BSD 4.3 et pour ce système d’exploitation sont
expliquées dans la section Systèmes de fichiers pour administrateurs système BSD 4.3,
page A-19.
BSD 4.3 maintient la liste des systèmes de fichiers dans le fichiers /etc/fstab. Le présent
système d’exploitation maintient une strophe pour chaque système de fichiers dans le
fichier /etc/filesystems.
Nouvelles commandes
Pour manipuler de nouveaux systèmes de gestion des disques et de la configuration, ce
système d’exploitation dispose d’environ 150 nouvelles commandes pour les
administrateurs 4.3 BSD. Pour plus d’informations, reportez–vous à la section Commandes
d’administration pour administrateurs système BSD 4.3, page A-11.
Comparaisons pour les gestionnaires de systèmes BSD
A-5
Amorçage et lancement
Le présent système d’exploitation prend en charge l’identification et la configuration
automatiques des unités. Par conséquent, le démarrage est très différent de celui des
systèmes BSD 4.3. Outre le noyau, une image d’un système de fichiers d’amorçage, ainsi
que les données de configuration (des unités) antérieures, sont chargés sur un disque
RAM. Au cours de la première phase du lancement, un nombre de données de
configuration suffisant pour permettre l’accès aux volumes logiques est chargé et vérifié.
L’unité d’espace de pagination est identifiée auprès du noyau et le système de fichiers
racine du disque est vérifié. Le système d’exploitation déplace alors le système de fichiers
racine du disque RAM vers le disque dur, et achève la procédure de lancement, en
configurant notamment les autres unités.
Autorisation utilisateur
BSD 4.3, et les systèmes UNIX version AT&T antérieures à SVR4, stockent toutes les
données d’authentification utilisateur (mots de passe chiffrés compris) dans le fichier
/etc/passwd. Normalement, ce fichier est lisible par tous.
Sur les systèmes SVR4, les mots de passe chiffrés ne se trouvent plus dans le fichier
/etc/passwd, mais dans le fichier /etc/shadow. Ce fichier est accessible aux seuls
utilisateurs racine et aux programmes sécurisés (/bin/login par exemple).
Le présent système d’exploitation enregistre les mots de passe chiffrés dans le fichier
/etc/security/passwd. Le répertoire /etc/security contient deux autres fichiers, user et
limits. Ces trois fichiers déterminent les droits d’accès d’un utilisateur au système (accès
aux commandes rlogin ou telnet, par exemple) et les limites des ressources utilisateur
(taille de fichier, espace d’adressage, etc.).
Impression
La plupart des commandes d’impression BSD 4.3 sont acceptées. Parmi les différences,
minimes, notez que /etc/qconfig est le fichier de configuration de ce système d’exploitation.
Les systèmes d’impression ligne de ce système d’exploitation et de BSC 4.3 peuvent
coopérer : il est possible de soumettre des travaux à des systèmes BSD 4.3 et d’imprimer
des travaux soumis par des systèmes BSC 4.3.
Shells
Le présent système d’exploitation prend en charge les shells Bourne, C et Korn. Le chemin
d’accès complet au shell Bourne est /bin/bsh. Le fichier /bin/sh est un lien fixe au fichier
/bin/ksh. Ce fichier est modifiable par l’administrateur.
AIX ne prend pas en charge setuid ou setgid comme scripts shell dans quelque shell que
ce soit.
Remarques :
1. Ce système d’exploitation ne dispose pas de scripts shell basés sur /bin/sh. Mais de
nombreux scripts d’autres systèmes sont basés sur /bin/sh (le shell Bourne).
2. Malgré la similarité des shells Bourne et Korn, le shell Korn n’est pas exactement un
surensemble du shell Bourne.
A-6
Concepts de gestion de système AIX – Système d’exploitation et unités
Comptabilité pour administrateurs système BSD 4.3
Les fichiers de comptabilité du répertoire /usr/lib/acct et les outils de suivi de l’activité
système du répertoire /usr/lib/sa de ce système d’exploitation sont identiques à ceux de
AT&T System V Release 4 (SVR4) combinés avec les utilitaires de comptabilité BSC 4.3.
La plupart des commandes de comptabilité se trouvent dans le répertoire /usr/lib/acct.
Pour démarrer le système de comptabilité, exécutez la commande /usr/lib/acct/startup.
Sinon, aucune commande de comptabilité (lastcomm (1), par exemple) ne renverra
d’informations.
Ce système d’exploitation fournit les fonctions de compatibilité BSC 4.3 suivantes :
last (1)
Indique les dernières connexions utilisateur et terminale.
lastcomm (1)
Affiche, dans l’ordre inverse, les dernières commandes
exécutées.
acct (3)
Active/désactive la comptabilité des processus.
ac (8)
Comptabilité de connexion.
accton(8)
Active/désactive la comptabilité système.
sa (8)
Maintient les fichiers de comptabilité système.
Ce système d’exploitation fournit également les commandes de comptabilité SVID
(System V Interface Definition) Issue II et les fonctions de bibliothèque suivantes :
acctcms (1)
Génère un rappel de la syntaxe des commandes pour les
enregistrements de comptabilité.
acctcms (1)
Affiche les récapitulatifs sélectionnés des enregistrements de
comptabilité des processus.
acctcon1 (1)
Convertit les enregistrements de connexion/déconnexion en
enregistrements de session.
acctcon2 (1)
Convertit les enregistrements de connexion/déconnexion en
enregistrements de cumul.
acctdisk (1)
Génère des enregistrements de cumul à partir des résultats de
la commande diskusg (1).
acctmerg (1)
Fusionne des fichiers de cumul dans un fichier intermédiaire.
accton (1)
Active le système de comptabilité.
acctprc1 (1)
Traite les données comptables issues de la commande acct (3).
acctprc2 (1)
Traite les résultats de la commande acctprc1 (1) dans des
enregistrements de cumul.
acctwtmp (1)
Manipule les enregistrements de durée de connexion.
chargefee (1)
Impute au nom de connexion.
ckpacct (1)
Contrôle la taille du fichier /usr/adm/pacct.
diskusg (1)
Génère des données comptables relatives au disque.
dodisk (1)
Effectue des opérations comptables sur le disque.
fwtmp (1)
Convertit des enregistrements binaires (fichier wtmp) en
enregistrements ASCII formatés.
Remarque : Le fichier wtmp se trouve dans le répertoire
/var/adm.
lastlogin (1)
Met à jour les dates de dernière connexion de chaque
utilisateur.
Comparaisons pour les gestionnaires de systèmes BSD
A-7
A-8
monacct (1)
Crée des fichiers récapitulatifs mensuels.
prctmp (1)
Imprime le fichier d’enregistrement de session issu de la
commande acctcon1 (1).
prdaily (1)
Formate l’état comptable de la veille.
prtacct (1)
Formate et imprime un fichier de cumul comptable.
runacct (1)
Exécute la comptabilité quotidienne.
shutacct (1)
Appelée par la commande d’arrêt du système (shutdown) pour
interrompre la comptabilité et en consigner la cause.
startup (1)
Appelée par l’initialisation du système pour démarrer la
comptabilité.
turnacct (1)
Active/désactive la comptabilité des processus.
wtmpfix (1)
Corrige l’horodate dans un fichier avec le format wtmp.
Concepts de gestion de système AIX – Système d’exploitation et unités
Sauvegarde pour les gestionnaires de systèmes BSD 4.3
Les commandes tar et cpio permettent de déplacer les données entre systèmes.
La commande tar de ce système d’exploitation n’est pas entièrement compatible avec
la commande tar du BSD 4.3. En cas de lecture à partir d’un canal de communication,
l’indicateur –B doit être ajouté à la commande tar de ce système d’exploitation.
La commande cpio d’AT&T est compatible avec cette version.
Le système d’exploitation peut lire et écrire dans les formats de commande dump
et restore. Par exemple, la commande backup de ce système d’exploitation avec
la syntaxe :
backup –0uf Device
Filesystemname
est identique à la commande dump du BSD 4.3 avec la syntaxe :
dump 0uf Device
Filesystemname
De même, la commande restore de ce système d’exploitation avec la syntaxe :
restore –mivf Device
est identique à la commande restore du BSD 4.3 avec la syntaxe :
restore ivf Device
Ce système d’exploitation dispose également des commandes rdump et rrestore du
BSD 4.3. La seule différence entre les deux versions est que pour ce système
d’exploitation, chaque argument doit être précédé d’un tiret –. Par exemple, la commande :
rdump –0 –f orca:/dev/rmt0 /dev/hd2
est équivalente à la commande du BSD 4.3 :
rdump 0f orca:/dev/rmt0 /dev/hd2
La commande backup de ce système d’exploitation avec la syntaxe :
backup –0f /dev/rmt0 /dev/hd2
est équivalente à la commande dump du BSD 4.3 avec la syntaxe :
dump 0f /dev/rmt0 /dev/hd2
Prise en charge des unités de bande SCSI autres que Bull
Ce système d’exploitation ne prend pas directement en charge les unités de bande SCSI
autres que Bull. Néanmoins, vous pouvez ajouter vos propres en–tête et interface utilisés
par le pilote SCSI Bull. Pour plus d’informations, reportez–vous à la section relative à l’ajout
au système d’une unité non prise en charge dans le guide AIX 5L Version 5.3 Kernel
Extensions and Device Support Programming Concepts and Backup Overview, page 6-2.
Comparaisons pour les gestionnaires de systèmes BSD
A-9
Amorçage et lancement pour administrateurs système BSD 4.3
Sur les systèmes BSD 4.3, le programme init est la dernière étape de la procédure
d’amorçage. Le rôle essentiel de ce programme est de créer des processus pour chaque
port de terminal disponible. Les ports de terminal disponibles sont repérables en lisant le
fichier /etc/ttys.
Sur un système System V, le programme init est démarré à l’initialisation du système.
Le processus init lance les processus en fonction des entrées du fichier /etc/inittab.
Le présent système d’exploitation adopte la procédure d’initialisation de System V. Vous
pouvez éditer le fichier /etc/inittab, directement via la commande telinit ou par le biais
d’une des commandes suivantes :
chitab (1)
modification d’article(s) dans le fichier /etc/inittab.
lsitab (1)
Affiche la liste des enregistrements du fichier /etc/inittab.
mkitab (1)
Crée des enregistrements dans le fichier /etc/inittab.
rmitab (1)
Supprime des enregistrements du fichier /etc/inittab.
Les modifications apportées au fichier /etc/inittab prennent effet au réamorçage suivant du
système ou après exécution de la commande telinit q.
A-10
Concepts de gestion de système AIX – Système d’exploitation et unités
Commandes d’administration pour administrateurs
système BSD 4.3
Voici la liste des commandes propres à l’administration de l’environnement du présent
système d’exploitation.
bosboot (1)
Initialise une unité d’amorçage.
bootlist (1)
Modifie la liste des unités d’amorçage (ou leur ordre dans cette liste)
disponibles pour le système.
cfgmgr (1)
Configure des unités en exécutant les programmes du répertoire
/etc/methods.
chcons (1)
Réachemine la console système vers une unité ou un fichier – effectif
au démarrage suivant.
chdev (1)
Modifie les caractéristiques d’une unité.
chdisp (1)
Change l’écran utilisé par le sous-système LFT (low-function terminal).
checkcw (1)
Prépare le texte en espacement fixe pour la commande troff.
checkeq (1)
Vérifie les documents formatés par les macros de type memorandum.
checkmm (1)
Vérifie les documents formatés par les macros de type memorandum.
checknr (1)
Contrôle les fichiers nroff et troff.
chfont (1)
Change la police par défaut sélectionnée au moment de l’amorçage.
chfs (1)
Modifie les attributs d’un système de fichiers.
chgroup (1)
Modifie les attributs des groupes.
chgrpmem (1)
Modifie les administrateurs ou les membres d’un groupe.
chhwkbd (1)
Modifie les attributs du clavier LFT (low-function terminal) enregistrés
dans la base de données ODM (Object Data Manager).
chitab (1)
Modifie des articles dans le fichier /etc/inittab.
chkbd (1)
Modifie la mappe clavier par défaut utilisée par le LFT (low-function
terminal) au moment de l’amorçage.
chkey (1)
Modifie votre clé de chiffrement.
chlang
Définit la variable d’environnement LANG dans le fichier
/etc/environment pour la connexion suivante.
chlicense (1)
Il existe deux types de licence utilisateur: Les licences fixes sont
toujours activées, leur nombre pouvant être modifié via l’option –u.
Les licences flottantes sont activées ou désactivées via l’option –f.
chlv (1)
Modifie les caractéristiques d’un volume logique.
chnamsv (1)
Modifie la configuration d’un service de noms TCP/IP sur un hôte.
chprtsv (1)
Modifie la configuration d’un service d’impression sur une machine
client ou serveur.
chps (1)
Modifie les attributs d’un espace de pagination.
chpv (1)
Modifie les caractéristiques d’un volume physique dans un groupe
de volumes.
chque (1)
Modifie le nom de la file d’attente.
chquedev (1)
Change le nom d’unité de l’imprimante ou du traceur.
chssys (1)
Modifie la définition d’un sous–système dans la classe d’objets
sous-système.
chtcb (1)
Modifie ou interroge l’attribut TCB (Trusted Computing Base)
d’un fichier.
Comparaisons pour les gestionnaires de systèmes BSD
A-11
A-12
chtz
Modifie les informations relatives au temps système.
chuser (1)
Modifie les attributs d’un utilisateur.
chvfs (1)
Modifie des articles dans le fichier /etc/vfs.
chvg (1)
Définit les caractéristiques d’un groupe de volumes.
chvirprt (1)
Modifie la valeur des attributs d’une imprimante virtuelle.
crfs (1)
Ajoute un système de fichiers.
crvfs (1)
Crée des entrées dans le fichier /etc/vfs.
exportvg (1)
Exporte la définition d’un groupe de volumes à partir d’un ensemble
de volumes physiques.
extendvg (1)
Ajoute des volumes physiques à un groupe de volumes.
grpck (1)
Vérifie une définition de groupe.
importvg (1)
Importe une nouvelle définition de groupe de volumes à partir d’un
ensemble de volumes physiques.
lsallq (1)
Affiche la liste de toutes les files d’attente configurées.
lsallqdev (1)
Affiche la liste de toutes les files d’attente d’imprimante et de traceur
configurées dans une file d’attente donnée.
lsdisp (1)
Affiche la liste des écrans disponibles sur le système.
lsfont (1)
Affiche la liste des polices disponibles sur l’écran.
lsfs (1)
Affiche les caractéristiques de systèmes de fichiers.
lsgroup (1)
Affiche les attributs de groupes.
lsitab (1)
Affiche la liste des enregistrements du fichier /etc/inittab.
lskbd (1)
Affiche la liste des mappes clavier disponibles pour le sous-système
LFT (low-function terminal).
lslicense (1)
Affiche le nombre de licences fixes et l’état des licences flottantes.
lslpp (1)
Affiche la liste des logiciels en option.
lsnamsv (1)
Affiche les informations sur le service de noms, enregistrées dans la
base de données.
lsprtsv (1)
Affiche les informations sur le service d’impression, enregistrées dans
la base de données.
lsps
Affiche l’espace de pagination et ses attributs.
lsque (1)
Affiche le nom de la strophe de file d’attente.
lsquedev (1)
Affiche le nom de la strophe d’unité.
lssrc (1)
Récupère l’état d’un sous-système, d’un groupe de sous-systèmes
ou d’un sous-serveur.
lsuser (1)
Affiche les attributs des comptes utilisateur.
lsvfs (1)
Affiche la liste des entrées dans le fichier /etc/vfs.
mkcatdefs (1)
Prétraite un fichier source de messages.
runcat (1)
Etablit un tube du résultat de la commande mkcatdefs pour la
commande gencat.
mkdev (1)
Ajoute une unité au système.
mkfont (1)
Ajoute au système le code de police associé à un écran.
mkfontdir (1)
Crée un fichier fonts.dir à partir d’un répertoire de fichiers de police.
mkgroup (1)
Crée un groupe.
mkitab (1)
Crée des enregistrements dans le fichier /etc/inittab.
mklv (1)
Crée un volume logique.
Concepts de gestion de système AIX – Système d’exploitation et unités
mklvcopy (1)
Ajoute des copies à un volume logique.
mknamsv (1)
Configure un service de noms TCP/IP sur un hôte pour un client.
mknotify (1)
Ajoute une définition de méthode de notification à la classe d’objets
de notification.
mkprtsv (1)
Modifie la configuration d’un service de noms TCP/IP sur un hôte.
mkps (1)
Ajoute un espace de pagination au système.
mkque (1)
Ajoute une file d’attente d’impression au système.
mkquedev (1)
Ajoute une unité de file d’attente d’impression au système.
mkserver (1)
Ajoute une définition de sous-serveur à la classe d’objets sous-serveur.
mkssys (1)
Ajoute une définition de sous-système à la classe d’objets
sous-système.
mksysb
Sauvegarde des systèmes de fichiers montés dans le groupe de
volumes rootvg pour les réinstallations ultérieures.
mkszfile
Enregistre la taille des systèmes de fichiers montés dans le groupe
de volumes rootvg pour les réinstallations ultérieures.
mktcpip (1)
Définit les valeurs requises pour démarrer TCP/IP sur un hôte.
mkuser (1)
Crée un compte utilisateur.
mkuser.sys (1)
Personnalise un nouveau compte utilisateur.
mkvg (1)
Crée un groupe de volumes.
mkvirprt (1)
Crée une imprimante virtuelle.
odmadd (1)
Ajoute des objets aux classes d’objets créées.
odmchange (1)
Modifie le contenu d’un objet sélectionné dans la classe spécifiée.
odmcreate (1)
Génère les fichiers .c (source) et .h (en-tête) requis pour le
développement d’application ODM et crée des classes d’objets vides.
odmdelete (1)
Supprime les objets sélectionnés de la classe d’objets spécifiée.
odmdrop (1)
Supprime une classe d’objets.
odmget (1)
Extrait des objets des classes spécifiées et les place dans le fichier
d’entrée odmadd.
odmshow (1)
Affiche la définition d’une classe d’objets.
pwdck (1)
Vérifie les informations d’authentification locale.
redefinevg
Redéfinit l’ensemble de volumes physique d’un groupe de volumes
dans la base de données de configuration des unités.
reducevg (1)
Supprime des volumes physiques d’un groupe de volumes. Si tous
les volumes physiques d’un groupe sont supprimés, le groupe lui-même
l’est également.
reorgvg (1)
Réorganise l’affectation de la partition physique d’un groupe de volume.
restbase (1)
Restaure les informations personnalisées de l’image d’amorçage.
rmdel (1)
Supprime un delta d’un fichier SCCS (Source Code Control System).
rmdev (1)
Supprime une unité du système.
rmf (1)
Supprime des dossiers et les messages qu’ils contiennent.
rmfs (1)
Supprime un système de fichiers.
rmgroup (1)
Supprime un groupe.
rmitab (1)
Supprime des enregistrements du fichier /etc/inittab.
rmlv (1)
Supprime des volumes logiques d’un groupe de volumes.
rmlvcopy (1)
Supprime des copies d’un volume logique.
Comparaisons pour les gestionnaires de systèmes BSD
A-13
A-14
rmm (1)
Supprime des messages.
rmnamsv (1)
Modifie la configuration d’un service de noms TCP/IP sur un hôte.
rmnotify (1)
Supprime une définition de méthode de notification de la classe d’objets
de notification.
rmprtsv (1)
Supprime de la configuration un service d’impression sur une machine
serveur ou client.
rmps (1)
Supprime un espace de pagination du système.
rmque (1)
Supprime une file d’attente d’impression du système.
rmquedev (1)
Supprime du système une unité de file d’attente imprimante ou traceur.
rmserver (1)
Supprime une définition de sous-serveur de la classe d’objets
sous-serveur.
rmssys (1)
Supprime une définition de sous-système de la classe d’objets
sous-système.
rmuser (1)
Supprime un compte utilisateur.
rmvfs (1)
Supprime des entrées du fichier /etc/vfs.
rmvirprt (1)
Supprime une imprimante virtuelle.
savebase (1)
Sauvegarde les données d’unité personnalisées ODM sur l’unité
d’amorçage.
swapoff (1)
Désactive un ou plusieurs espaces de pagination.
swapon (1)
Spécifie des périphériques supplémentaires pour la pagination et
l’échange.
syncvg (1)
Synchronise les copies non courantes de volumes logiques.
usrck (1)
Vérifie une définition utilisateur.
varyoffvg (1)
Désactive un groupe de volumes.
varyonvg (1)
Active un groupe de volumes.
Concepts de gestion de système AIX – Système d’exploitation et unités
Cron pour administrateurs système BSD 4.3
Le démon cron du présent système d’exploitation est semblable à celui du System V
Release 2. Une entrée du fichier /etc/inittab active le démon cron.
Comparaisons pour les gestionnaires de systèmes BSD
A-15
Unités pour administrateurs systèmes BSD 4.3
Une unité d’un système BSD 4.3 n’est accessible à une application que si :
• l’unité est physiquement installée et qu’elle fonctionne,
• le pilote de l’unité se trouve dans le noyau,
• les fichiers unité spéciaux correspondants se trouvent dans le répertoire /dev,
Une unité de ce système d’exploitation n’est accessible à une application que si :
• l’unité est physiquement installée et qu’elle fonctionne,
• le pilote de l’unité se trouve dans le noyau ou dans une extension chargée,
• les fichiers unité spéciaux correspondants se trouvent dans le répertoire /dev,
• la base de données objet du répertoire /etc/objrepos contient des entrées pour l’unité
qui correspondent à la configuration physique.
Les programmes propres aux unités, appelés méthodes, qui se trouvent dans le répertoire
/etc/methods, maintiennent la base de données objet. Les méthodes sont appelées par le
gestionnaire de configuration (accessible via la commande cfgmgr) et d’autres
commandes.
Si une application ne peut plus accéder à une unité, ce peut être le matériel qui est en
cause, ou encore la base de données du répertoire /etc/objrepos qui est endommagée.
Les processus de la commande cfgmgr de la base de données de configuration
(du répertoire /etc/objrepos) sont traités au moment du lancement par la commande
cfgmgr (le gestionnaire de configuration).
Le pseudo-code ci-dessous illustre la logique du gestionnaire de configuration :
/* Main */
While there are rules in the Config_Rules database
{
Get the next rule and execute it
Capture stdout from the last execution
Parse_Output(stdout)
}
/* Parse Output Routine */
/* stdout will contain a list of devices found */
Parse_OutPut(stdout)
{
While there are devices left in the list
{
Lookup the device in the database
if (!defined)
Get define method from database and
execute
if (! configured)
{
Get config method from database and
execute
Parse_Output(stdout)
}
}
}
A-16
Concepts de gestion de système AIX – Système d’exploitation et unités
Tableau de comparaison de fichiers BSD 4.3,
SVR4 et de ce système d’exploitation
Le tableau suivant compare noms et fonctions des fichiers dans les trois systèmes BSD 4.3,
SVR4 et de ce système d’exploitation.
Tableau de comparaison de fichiers
Fichier
BSD 4.3
Fichier SVR4
Fichier de ce
système
d’exploitation
Base de
données
L–Devices
Devices
Devices
non
L–dialcodes
Dialcodes
Dialcodes
non
L.cmds
Permissions
Permissions
non
L.sys
Systems
Systems
non
USERFILE
Permissions
Permissions
non
aliases
mail/namefiles
aliases
alias DB/DB
fstab
vfstab
filesystems
non
ftpusers
ftpusers
ftpusers
non
gettytab
group
group
non
hosts
hosts
hosts
non
hosts.equiv
hosts.equiv
hosts.equiv
non
inetd.conf
inetd.conf
inetd.conf
non
map3270
N/A
map3270
non
motd
motd
motd
non
mtab
mnttab
N/A
non
named.boot
named.boot
named.boot
non
named.ca
named.ca
non
named.hosts
named.data
(voir remarque)
non
named.local
named.local
non
named.pid
non
named.rev
non
named.pid
named.rev
networks
networks
networks
non
passwd
passwd
passwd
non
printcap
qconfig
qconfig
protocols
protocols
non
remote
remote
remote
non
resolv.conf
resolv.conf
resolv.conf
non
sendmail.cf
sendmail.cf
sendmail.cf
sendmail.cfDB
services
non
services
shells
dbm
N/A
group
named.pid
Type
(odm/dbm)
shells
aucun
N/A
Comparaisons pour les gestionnaires de systèmes BSD
A-17
stab
N/A
syslog.conf
syslog.conf
non
syslog.pid
syslog.pid
non
termcap
terminfo
terminfo
ttys
ttys
N/A
types
utmp
odm
N/A
utmp
utmp
vfont
N/A
vgrindefs
vgrindefs
wtmp
oui
wtmp
wtmp
Remarque : Les noms de fichiers named.ca, named.hosts, named.local et named.rev
peuvent être définis par l’utilisateur dans le fichier named.boot. Les noms
indiqués ici sont ceux qui ont été retenus dans la documentation de ce
système d’exploitation.
A-18
Concepts de gestion de système AIX – Système d’exploitation et unités
Systèmes de fichiers pour administrateurs système BSD 4.3
Cette section propose une comparaison sommaire entre les systèmes de fichiers de ce
système d’exploitation et ceux d’autres systèmes et indique les types de systèmes de
fichiers pris en charge sur ce système d’exploitation.
Ce système d’exploitation passe par le fichier /etc/filesystem pour obtenir les informations
sur les unités des systèmes de fichiers et propose des commandes similaires pour le
montage et le démontage des systèmes de fichiers.
Fichiers /etc/filesystems et /etc/fstab
Les systèmes BSD 4.3 stockent les listes d’unités par bloc et de points de montage dans
le fichier /etc/fstab.
Les systèmes SVR4 stockent les données sur les unités par bloc et sur les points de
montage dans le fichier /etc/vfstab.
Le présent système d’exploitation stocke les données sur les unités sur bloc et sur les
points de montage dans le fichier /etc/filesystems. Le commandes crfs, chfs et rmfs
mettent à jour le fichier /etc/filesystems.
Les administrateurs BSD 4.3 seront sans doute intéressés par la variable check du fichier
/etc/filesystems. Vous pouvez affecter à cette variable la valeur True, False ou une valeur
numérique. Par exemple, vous pouvez spécifier check=2 dans le fichier /etc/filesystems.
Le nombre précise le passage de la commande fsck qui effectuera la vérification du
système de fichiers concerné. Le paramètre check correspond au cinquième champ d’un
enregistrement du fichier /etc/fstab.
Aucun paramètre relatif à la fréquence de cliché ne se trouve dans le fichier
/etc/filesystems.
Support des systèmes de fichiers sur ce système d’exploitation
Ce système d’exploitation prend en charge les quotas disque.
Ce système d’exploitation ne permet pas le montage de disquettes comme systèmes
de fichiers.
La syntaxe des commandes mount et umount dans ce système d’exploitation diffère
de celle des versions BSD 4.3 et SVR4 de ces commandes. Le tableau récapitule les
différentes syntaxes.
Fonction
Syntaxe de ce
système
d’exploitation
Syntaxe BSD 4.3
Syntaxe SVR4
monte tous les
systèmes de fichiers
mount all
mount –a
mountall
démonte tous les
systèmes de fichiers
umount all
umount –a
umountall
Voir Systèmes de fichiers, page 5-1 pour plus d’informations.
Comparaisons pour les gestionnaires de systèmes BSD
A-19
Recherche et examen de fichiers
pour administrateurs système BSD 4.3
Le présent système d’exploitation accepte les commandes BSD 4.3 suivantes :
• which,
• whereis,
• what,
• file.
Le présent système d’exploitation n’accepte pas la syntaxe BSD 4.3 fast find
de la commande find. Il n’existe pour le moment pas de fonction de remplacement.
Le script ffind suivant peut simuler la fonction :
#!/bin/bsh
PATH=/bin
for dir in /bin /etc /lib /usr
do
find $dir –print | egrep $1
done
La syntaxe du script ffind est la suivante :
ffind NomFichie
A-20
Concepts de gestion de système AIX – Système d’exploitation et unités
Espace de pagination pour administrateurs système BSD 4.3
Les commandes suivantes aident à gérer l’espace de pagination (également appelé espace
de permutation) :
chps (1)
Modifie les attributs d’un espace de pagination.
lsps (1)
Affiche la liste des attributs d’un espace de pagination.
mkps (1)
Ajoute un espace de pagination au système.
rmps (1)
Supprime un espace de pagination du système.
swapoff (1)
Désactive un ou plusieurs espaces de pagination.
swapon (1)
Spécifie d’autres unités de pagination et de permutation.
Si vous avez besoin d’un grand espace de pagination, placez un volume logique de
pagination sur chaque disque : vous pourrez ainsi planifier la pagination sur plusieurs unités
de disque.
Comparaisons pour les gestionnaires de systèmes BSD
A-21
Réseau pour administrateurs système BSD 4.3
Cet article traite de l’utilisation de la configuration de réseau BSD 4.3 ASCII, des
commandes et des options complémentaires, de la résolution de noms et d’adresses sur ce
système d’exploitation et des différences entre la gestion d’un réseau BSD 4.3 et celle de ce
système d’exploitation.
Configuration BSD 4.3 : modification du lancement par défaut
Vous pouvez administrer les interfaces réseau de ce système d’exploitation via SMIT et les
fichiers ODM, ou encore via les fichiers de configuration BSD 4.3 ASCII.
Pour administrer des interfaces réseau via les fichiers de configuration BSD 4.3 ASCII,
annulez, dans le fichier /etc/rc.net, la mise en commentaire des commandes sous
l’en-tête :
# Part II – Traditional
Configuration
Puis, si vous souhaitez que soient pris en charge la configuration des fichiers ordinaires et
le support SRC, éditez le fichier /etc/rc.net et annulez la mise en commentaire des
commandes hostname, ifconfig et route avec les paramètres appropriés.
Pour la configuration des fichiers ordinaires sans support SRC, lancez la commande smit
setbootup_option pour passer à une configuration rc de style BSD. Cette option configure
le système pour qu’il utilise le fichier /etc/rc.bsdnet au moment du lancement. Vous devez
également éditer le fichier /etc/rc.bsdnet et annuler la mise en commentaire des
commandes hostname, ifconfig et route avec les paramètres appropriés.
Autres options des commandes ifconfig et netstat
La commande ifconfig de ce système d’exploitation a les options complémentaires
suivantes :
mtu
La variable mtu définit l’unité MTU (Maximum Transmission Unit) maximale
utilisée sur le réseau local (et les sous–réseaux locaux) et l’unité MTU
utilisée pour les réseaux distants. Pour optimiser la compatibilité avec
Ethernet et les autres réseaux, affectez la valeur 1500 à la variable par
défaut mtu Token–Ring et Ethernet.
allcast
L’option allcast définit la stratégie de diffusion Token–Ring. Définissez
l’option allcast pour optimiser la connectivité via les ponts Token–Ring. Si
vous désactivez l’option allcast (en définissant –allcast), vous réduisez
l’excès de trafic sur l’anneau.
La commande netstat de ce système d’exploitation utilise l’option –v. La commande netstat
–v imprime les statistiques des pilotes telles que le nombre d’octets transmis, le nombre
d’erreurs transmises, le nombre d’octets reçus et le nombre d’erreur reçues.
Autres commandes de gestion de réseau
Le système d’exploitation prend également en charge les commandes suivantes :
A-22
securetcpip
Le script shell securetcpip active le mode d’accès contrôlé qui
renforce la sécurité du réseau. Il empêche l’exécution de plusieurs
programmes TCP/IP non sécurisés, tels que les programmes tftp,
rcp, rlogin et rsh. Il limite également l’utilisation du fichier .netrc.
gated
La commande gated permet la prise en charge de base de données
MIB pour SNMP.
Concepts de gestion de système AIX – Système d’exploitation et unités
no
La commande no définit les options du réseau telles que :
dogticks
Règle la granularité de l’horloge pour les routines ifwatchdog.
subnetsarelocal
Détermine la présence de l’adresse des paquets sur le réseau local.
ipsendredirects
Indique si le noyau doit envoyer des signaux de redirection.
ipforwarding
Indique si le noyau doit réexpédier des paquets.
tcp_ttl
Indique la durée de vie des paquets TCP (Transmission Control
Protocol).
udp_ttl
Indique la durée de vie des paquets UDP (User Datagram Protocol).
maxttl
Indique la durée de vie des paquets RIP (Routing Information
Protocol).
ipfragttl
Indique la durée de vie des fragments IP (Internet Protocol).
lowclust
Indique un niveau bas pour le pool mbuf de cluster.
lowmbuf
Indique un niveau bas pour le pool mbuf.
thewall
Indique la quantité maximale de mémoire allouée au pool mbuf et au
pool mbuf de cluster.
arpt_killc
Indique le délai en minutes avant suppression d’une entrée complète
ARP (Address Resolution Protocol) inactive.
iptrace
La commande iptrace effectue le suivi des paquets au niveau interface
pour les protocoles Internet.
ipreport
La commande ipreport formate les données de suivi de façon lisible
par l’homme. Exemple d’utilisation de cette commande :
iptrace –i en0 /tmp/iptrace.log
# kill iptrace daemon
kill ‘ps ax | grep iptrace | awk ’{ print $1 }’‘
ipreport /tmp/iptrace.log | more
Comparaisons pour les gestionnaires de systèmes BSD
A-23
Résolution nom et adresse
Les sous–routines gethostbyname et gethostbyaddr de la bibliothèque libc offrent une
prise en charge pour DNS (Domain Name Service), NIS (Network Information Services,
anciennement Yellow Pages) et la base de données /etc/hosts. Si le fichier
/etc/resolv.conf existe, le serveur de noms est toujours le premier contrôlé. Si le nom n’est
pas résolu et que NIS est en cours d’exécution, NIS est contrôlé. Si NIS n’est pas en
service, la recherche s’effectue sur le fichier /etc/hosts.
Différences entre ce système d’exploitation et BSD 4.3
Sur ce système d’exploitation, les démons réseau sont lancés depuis le fichier /etc/rc.tcpip,
et non depuis le fichier /etc/rc.local. Le script shell /etc/rc.tcpip est appelé depuis le fichier
/etc/inittab, et non depuis le fichier /etc/rc.
Si le contrôleur SRC (System Resource Controller) est actif, les démons TCP/IP sont
exécutés sous son contrôle. Si vous ne souhaitez pas qu’ils le soient, lancez la commande
smit setbootup_option pour passer à une configuration rc de style BSD.
Les fonctions de gestion de réseau BSD 4.3 acceptées par ce système d’exploitation sont
les suivantes :
• fonctions de journalisation SYSLOG au niveau noyau,
• droits d’accès aux sockets de domaine UNIX.
Commande tn3270
La commande tn3270 est un lien avec la commande telnet, mais qui utilise le fichier
/etc/map3270 et la variable d’environnement courante TERM pour générer les mappages
clavier 3270. Ainsi, la commande tn3270 opère exactement comme sa version BSD.
Si vous souhaitez modifier les séquences d’échappement par défaut utilisées par les
commandes tn3270, telnet et tn, définissez la variable d’environnement TNESC avant de
lancer ces commandes.
A-24
Concepts de gestion de système AIX – Système d’exploitation et unités
Documentation en ligne et commande man pour
administrateurs système BSD 4.3
Le présent système d’exploitation accepte les commandes man –k, apropos et whatis,
mais la base de données utilisée par ces commandes soit être créée au préalable via la
commande catman –w.
La commande man recherche d’abord les pages de texte plat dans les fichiers
/usr/man/cat?. Puis, elle recherche les pages formatées nroff dans le fichier
/usr/man/man?. Les nouvelles pages de manuel peuvent être ajoutées en texte plat ou au
format nroff.
Remarques :
1. Les pages de texte de la commande man ne sont pas fournies avec le système.
La base de données correspondante doit être créée via la commande catman.
Ces pages peuvent être soit du texte plat stocké dans les fichiers /usr/man/cat ?,
soit des pages formatées nroff stockées dans les fichiers /usr/man/man ?.
2. Le programme sous licence de formatage de texte doit être installé pour que la
commande nroff soit à disposition de la commande man pour la lecture des
pages formatées nroff.
Comparaisons pour les gestionnaires de systèmes BSD
A-25
NFS et NIS (ex”Yellow Pages”) pour administrateurs
système BSD 4.3
Les démons NFS (Network File System) et NIS (Network Information Services) sont lancés
à partir du fichier /etc/rc.nfs. Ils supposent l’activation préalable du démon portmap dans le
fichier /etc/rc.tcpip. Par défaut, le fichier /etc/rc.nfs n’est pas appelé par le fichier
/etc/inittab. Si vous ajoutez une ligne dans le fichier /etc/inittab pour appeler le script
/etc/rc.nfs, il doit être appelé après le script /etc/rc.tcpip.
Si NIS est actif, vous devez intégrer une entrée racine avant l’entrée +:: (signe plus,
deux-points, deux-points) dans le fichier /etc/passwd et une entrée système avant
l’entrée +:: dans le fichier /etc/group. Un administrateur système peut ainsi se connecter
comme utilisateur racine et effectuer les modifications requises si le système ne parvient
pas à communiquer avec le serveur NIS.
Vous pouvez configurer NFS avec Web–based System Manager, (saisissez wsm,
puis sélectionnez Network ), ou le raccourci SMIT, smit nfs. Les menus Web–based
System Manager et SMIT font référence à NIS (anciennement Yellow Pages) en tant
que NIS. De nombreuses commandes NFS et NIS se trouvent dans le répertoire /etc
et /usr/etc.
Certains environnements NFS utilisent une commande arch pour identifier les familles et
les types de machines. Par exemple, si vous utilisez Bull ESCALA, indiquez l’identifiant
power pour la famille (UC) et l’identifiant ibm6000 pour le type (machine).
A-26
Concepts de gestion de système AIX – Système d’exploitation et unités
Mots de passe pour administrateurs système BSD 4.3
Voici quelques précisions sur les différences de gestion des mots de passe entre ce
système d’exploitation et BSD 4.3.
Définition d’un mot de passe utilisateur
Lorsque vous exécutez la commande /bin/passwd de ce système d’exploitation comme
utilisateur racine, vous êtes invité à fournir le mot de passe racine. Voici un exemple :
# passwd cslater
Changing password for ”cslater”
Enter root’s Password or
cslater’s Old password:
cslater’s New password:
Re–enter cslater’s
new password:
#
La version BSD 4.3 ne vous invite pas à entrer le mot de passe racine. En voici un
exemple :
# passwd cslater
New password:
Retype new password:
#
Importation d’un fichier de mots de passe BSD 4.3
Pour importer un fichier de mots de passe BSD 4.3, copiez-le dans le fichier /etc/passwd,
puis entrez :
pwdck –y ALL
Le fichier /etc/security/limits doit être ensuite mis à jour avec une strophe nulle pour tout
nouvel utilisateur. La commande usrck le fait, mais elle peut poser problème sauf si le
fichier /etc/group est importé avec le fichier /etc/passwd.
Remarque : Si le fichier /etc/security/limits est modifié, la pile ne doit pas dépasser
65 536 octets. Si elle dépasse cette limite, l’exécution de la commande usrck
risque de poser problème : ramenez la taille de la pile à 65536 et relancez la
commande usrck.
Exécutez également les commandes grpck et usrck pour vérifier les attributs groupe et
utilisateur.
Edition du fichier de mots de passe (Password)
Sous ce système d’exploitation, les commandes lsuser, mkuser, chuser et rmuser
permettent de gérer les mots de passe. Toutes ces commandes peuvent être exécutées via
SMIT ou Web-based System Manager. Toutefois elles ne traitent qu’un utilisateur à la fois.
Remarque : Passer par un éditeur pour modifier plusieurs noms utilisateur requiert d’éditer
simultanément plusieurs fichiers, car les mots de passe sont stockés dans le
fichier /etc/security/passwd, les informations sur les droits d’accès, dans le
fichier /etc/security/user et les autres données utilisateur, dans le fichier
/etc/passwd.
Ce système d’exploitation rejette la commande vipwn, mais accepte la commande
mkpasswd. Mais vous pouvez toujours administrer les mots de passe sur ce système
d’exploitation comme vous le feriez sur un système BSD 4.3. Procédez comme suit :
1. Placez un fichier de mots de passe BSD 4.3 dans le fichier /etc/shadow.
2. Modifiez les droits d’accès au fichier :
chmod 000 /etc/shadow
Comparaisons pour les gestionnaires de systèmes BSD
A-27
3. Placez le script shell vipw suivant dans le répertoire /etc :
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––
#!/bin/bsh
#
# vipw. Uses pwdck for now. May use usrck someday
#
PATH=/bin:/usr/bin:/etc:/usr/ucb # Add to this if your editor is
# some place else
if [ –f /etc/ptmp ] ; then
echo ”/etc/ptmp exists. Is someone else using
vipw?”
exit 1
fi
if [ ! –f /‘which ”$EDITOR” | awk ’{ print $1 }’‘ ] ; then
EDITOR=vi
fi
cp /etc/shadow /etc/ptmp
if (cmp /etc/shadow /etc/ptmp) ; then
$EDITOR /etc/ptmp
else
echo cannot copy shadow to ptmp
exit 1
fi
if (egrep ”^root:” /etc/ptmp >/dev/null) ; then
cp /etc/ptmp /etc/shadow ; cp /etc/ptmp /etc/passwd
chmod 000 /etc/passwd /etc/shadow
pwdck –y ALL 2>1 >/dev/null # return code 114 may change
rc=$?
if [ $rc –eq 114 ]; then
chmod 644 /etc/passwd
rm –f /etc/passwd.dir /etc/passwd.pag
mkpasswd /etc/passwd
# update /etc/security/limits, or ftp
# will fail
else
pwdck –y ALL
fi
else
echo bad entry for root in ptmp
fi
rm /etc/ptmp
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––
4. Si vous utilisez le script shell vipw ou la commande mkpasswd, n’oubliez pas que
Web-based System Manager, SMIT et les commandes mkuser, chuser et rmuser
n’utilisent pas la commande mkpasswd. Vous devez lancer :
pour mettre à jour les fichiers /etc/passwd.dir et
/etc/passwd.pag.
Attention : L’initialisation de la variable IFS et des instructions trap permettent de se
prémunir contre certaines méthodes exploitant les failles au niveau de la sécurité,
inhérentes à la fonction setuid. Les scripts shell vipw et passwd sont toutefois conçus
pour des environnements relativement ouverts, où la compatibilité est un élément-clé. Si
vous souhaitez un environnement plus sûr, utilisez exclusivement les commandes
standard de ce système d’exploitation.
A-28
Concepts de gestion de système AIX – Système d’exploitation et unités
5. Placez le script shell passwd suivant dans le répertoire /usr/ucb :
–––––––––––––––––––––––––––––––––––––––––––––––––––––
#!/bin/ksh
#
# matches changes to /etc/security/passwd file with changes to
#/etc/shadow
#
IFS=” ”
PATH=/bin
trap ”exit 2” 1 2 3 4 5 6 7 8 10 12 13 14 15 16 17 18 21 22 \
23 24 25 27 28 29 30 31 32 33 34 35 36 60 61 62
if [ –n ”$1” ]; then
USERNAME=$1
else
USERNAME=$LOGNAME
fi
if [ –f /etc/ptmp ] ; then
echo password file busy
exit 1
fi
trap ”rm /etc/ptmp; exit 3” 1 2 3 4 5 6 7 8 10 12 13 \
14 15 16 17 18 21 22 23 24 25 27 28 29 30 31 \
32 33 34 35 36 60 61 62
if (cp /etc/security/passwd /etc/ptmp) ; then
chmod 000 /etc/ptmp else
rm –f /etc/ptmp exit 1
fi
if ( /bin/passwd $USERNAME ) ; then
PW=‘ awk ’ BEGIN { RS = ”” }
$1 == user { print $4 } ’ user=”$USERNAME:” \
/etc/security/passwd ‘
else
rm –f /etc/ptmp
exit 1
fi
rm –f /etc/ptmp
awk –F: ’$1 == user { print $1”:”pw”:”$3 ”:”$4”:”$5”:”$6”:”$7 }
$1 != user { print $0 }’ user=”$USERNAME” pw=”$PW” \
/etc/shadow > /etc/ptmp
chmod 000 /etc/ptmp
mv –f /etc/ptmp /etc/shadow
–––––––––––––––––––––––––––––––––––––––––––––––––––––
6. Modifiez les droits d’accès au script passwd :
chmod 4711 /usr/ucb/passwd
7. Vérifiez que la variable d’environnement PATH de chaque utilisateur spécifie d’explorer
le répertoire /usr/ucb avant le répertoire /bin.
Comparaisons pour les gestionnaires de systèmes BSD
A-29
Mesure des performances et réglage
pour les gestionnaires systèmes BSD 4.3
Toutes les unités du système d’exploitation disposent d’attributs. Pour afficher les attributs
des unités, entrez :
lsattr –E –l
nom_unité
Tout attribut ayant la valeur True peut être modifié avec la commande :
chdev –l
nom_unité
–a attr=valeur
Attention : Modifier incorrectement les paramètres d’unité peut endommager le système.
Par défaut, le nombre maximal de processus par utilisateur est de 40. Cette valeur peut se
révéler insuffisante pour des utilisateurs ayant ouvert simultanément plusieurs fenêtres.
Pour modifier la valeur sur tout le système, entrez :
hdev –l sys0 –a maxuproc=100
Le maximum est ici porté à 100 (effectif dès le réamorçage du système).
Pour afficher la valeur courante, ainsi que d’autres attributs, entrez :
lsattr –E –l sys0
L’attribut maxmbuf n’est pour le moment pas accepté par les services mbuf.
Ce système d’exploitation accepte les commandes vmstat et iostat, mais non la
commande systat, ni les moyennes de charge.
A-30
Concepts de gestion de système AIX – Système d’exploitation et unités
Imprimantes pour les gestionnaires de systèmes BSD 4.3
Dans AIX versions 5.1 et ultérieures,
le système d’exploitation prend en charge deux sous–systèmes d’impression : 4.3 BSD
et System V. Le sous–système d’impression System V utilise les commandes, les files
d’attente et les fichiers System V Release 4 et il est administré de la même manière.
Les paragraphes suivants indiquent les connaissances nécessaires à la gestion du
sous–système d’impression 4.3 BSD. Vous contrôlez l’activation du système via SMIT.
Un seul sous–système peut être actif à la fois.
L’impression est gérée par des programmes et des configurations du répertoire /usr/lpd.
La conception, la configuration, le mécanisme de file d’attente et les processus du démon
du BSD 4.3 diffèrent des sous–systèmes d’impression de ce système d’exploitation.
Cependant, les deux utilisent le protocole lpd pour l’impression à distance. Les deux
systèmes exploitent /etc/hosts.lpd, s’il existe, ou /etc/host.equiv. Le sous–système
d’impression de ce système d’exploitation offre une passerelle vers les sous–systèmes
d’impression du BSD 4.3 de manière à permettre la soumission de travaux d’impression
aux systèmes BSD 4.3 et la réception de travaux d’impression des systèmes BSD 4.3.
Le fichier /etc/printcap du BSD 4.3 est absent de ce système d’exploitation. Ce fichier
associe configuration de spouleur et base de données des capacités de l’imprimante. Pour
une bonne configuration de l’imprimante, il est indispensable aux utilisateurs de comprendre
le format et les mots–clés du fichier printcap.
Le fichier /etc/qconfig de ce système d’exploitation contient uniquement les informations de
configuration du spouleur. La capacité de l’imprimante est définie dans la base de données
ODM prédéfinie ou personnalisée. Vous pouvez définir sur le système les capacités d’une
imprimante donnée à l’aide de la commande mkvirprt (définir l’imprimante virtuelle).
Pour rendre l’imprimante Ip0 disponible sur l’hôte distant viking, indiquer les éléments
suivants dans un fichier /etc/printcap du système BSD 4.3 :
lp0|Print on remote printer attached to
viking:Z
:lp=:rm=viking:rp=lp:st=/usr/spool/lp0d
Pour effectuer la même action sur ce système d’exploitation, indiquer les éléments suivants
dans un fichier /etc/qconfig :
lp0:
device = dlp0
host = viking
rq = lp
dlp0:
backend = /usr/lib/lpd/rembak
Pour plus d’informations sur le sous–système d’impression, voir le document Généralités
sur l’inmprimante pour la gestion de système.
Ce système d’exploitation prends en charge les commandes d’impression et les fonctions
de bibliothèque suivantes :
cancel (1)
Annule les requêtes adressées à une imprimante ligne
chquedev (1)
Modifie les noms des unités à file d’attente de l’imprimante ou du
traceur.
chvirprt (1)
Modifie les valeurs des attributs d’une imprimante virtuelle.
disable (1)
Désactive la file d’attente d’une imprimante.
enable (1)
Active la file d’attente d’une imprimante.
Comparaisons pour les gestionnaires de systèmes BSD
A-31
A-32
hplj (1)
Effectue le post–traitement de la sortie troff pour l’imprimante HP
LaserJetII avec la cartouche K.
ibm3812 (1)
Effectue le post–traitement de la sortie troff pour l’imprimante 3812
Mod 2 Pageprinter.
ibm3816 (1)
Effectue le post–traitement de la sortie troff pour l’imprimante 3816
Pageprinter.
ibm5587G (1)
Effectue le post–traitement de la sortie troff pour l’imprimante
5587G avec la cartouche 32x32/24x24.
lp (1)
Envoie une demande à une imprimante ligne.
lpr (1)
Met en file d’attente les travaux d’impression.
lprm (1)
Supprime des travaux d’impression de l’imprimante ligne.
lpstat (1)
Affiche des informations sur l’état de l’imprimante ligne.
lptest (1)
Génère la réaction en chaîne de l’imprimante ligne.
lsallqdev (1)
Dresse la liste des noms de toutes les unités à file d’attente
configurées d’une imprimante présentes dans la file d’attente.
lsvirprt (1)
Affiche les valeurs des attributs d’une imprimante virtuelle.
mkque (1)
Ajoute une file d’attente au système.
mkquedev (1)
Ajoute une unité à file d’attente au système.
mkvirprt (1)
Définit une imprimante virtuelle.
pac (1)
Prépare les enregistrements de comptabilité d’imprimante/traceur.
piobe (1)
Gestionnaire de travaux d’impression pour l’imprimante principale.
pioburst (1)
Génère le transfert en continu (en–tête et pages de fin) pour une
sortie d’imprimante.
piocmdout (3)
Sous–programme qui génère une chaîne d’attribut pour un
programme de mise en forme d’impression.
piodigest (1)
Effectue le prétraitement des valeurs d’attributs pour une définition
d’imprimante virtuelle et les enregistre.
pioexit (3)
Sous–programme qui permet de quitter le programme de mise en
forme d’impression.
pioformat (1)
Pilote un programme de mise en forme d’impression.
piofquote (1)
Convertit certains caractères de contrôle destinés aux imprimantes
PostScript.
piogetstr (3)
Sous–programme qui extrait une chaîne d’attribut pour un
programme de mise en forme d’impression.
piogetvals (3)
Sous–programme qui initialise les variables de la base de données
des attributs d’une imprimante pour le programlme de mise en
forme d’impression.
piomsgout (3)
Sous–programme qui envoie un message à partir d’un programme
de mise en forme d’impression.
pioout (1)
Programme d’interface du pilote d’unité de l’imprimante principale.
piopredef (1)
Crée une définition de flux de données d’imprimante prédéfinie.
proff (1)
Formate le texte pour les imprimantes avec des flux de données
d’imprimantes personnelles.
qadm (1)
Réalise l’administration du système pour le spouleur de
l’imprimante.
qconfig (4)
Configure un système de file d’attente d’impression.
qstatus (1)
Transmet l’état de l’imprimante au spouleur.
Concepts de gestion de système AIX – Système d’exploitation et unités
restore (3)
Restaure l’état par défaut de l’imprimante.
rmque (1)
Supprime une file d’attente du système.
rmquedev (1)
Supprime une unité à file d’attente de l’imprimante ou du traceur
du système.
rmvirprt (1)
Supprime une imprimante virtuelle.
splp (1)
Modifie ou affiche les paramètres du pilote d’imprimante.
xpr (1)
Formate un fichier de vidage pour la sortie d’imprimante.
Comparaisons pour les gestionnaires de systèmes BSD
A-33
Terminaux pour administrateurs système BSD 4.3
Traditionnellement, pour activer/désactiver un port, les administrateurs BSD 4.3 modifient
le fichier /etc/ttys et envoient un signal HUP au programme init.
Ce système d’exploitation stocke les informations sur le port du terminal dans le
gestionnaire ODM et lance les terminaux lorsque le programme init lit le fichier /etc/inittab.
Dans ce système d’exploitation, vous devriez utiliser l’application Web-based System
Manager Devices ou SMIT pour configurer les ports du terminal.
Il n’existe pas de mappage fixe entre le port et le nom de fichier unité spécial dans le
répertoire /dev. Cela peut engendrer des doutes sur le port à configurer, pour les
administrateurs abordant ce système d’exploitation. Dans les menus SMIT, le port série de
la première carte (libellé s1) est référencé par l’emplacement 00–00–S1, la carte sa0 et le
port s1 dans le menu SMIT. Le port série de la seconde carte (libellé s2) est référencé par
l’emplacement 00–00–S2, la carte sa1 et le port s2.
Pour activer/désactiver un port, vous disposez des commandes penable et pdisable.
termcap et terminfo
Comme System V, le présent système d’exploitation se sert des entrées terminfo du fichier
/usr/lib/terminfo/?/*. Les utilisateurs BSD 4.3 trouveront sans doute utiles les commandes
suivantes :
captoinfo(1)
Convertit un fichier termcap en fichier terminfo
tic(1)
Traduit les fichiers terminfo source en format compilé.
Ce système d’exploitation inclut la source de nombreuses entrées terminfo. Certaines
doivent être compilées via la commande tic. Le fichier termcap se trouve dans le fichier
/lib/libtermcap/termcap.src.
A-34
Concepts de gestion de système AIX – Système d’exploitation et unités
UUCP pour administrateurs système BSD 4.3
Ce système d’exploitation fournit les utilitaires BNU (Basic Networking Utilities) System V
(souvent appelés HDB UUCP).
Dialers (4)
Affiche la liste des modems utilisés par les liaisons BNU à
distance.
Maxuuxqts (4)
Limite le nombre d’instances de démons BNU uuxqt exécutables
simultanément.
Permissions (4)
Spécifie les droits des systèmes distants sur les commandes
BNU.
Poll (4)
Spécifie le moment où BNU doit interroger les systèmes distants.
Systems (4)
Affiche la liste des ordinateurs distants avec lesquels peut
communiquer le système local.
rmail (1)
Gère le courrier reçu à distance via BNU.
uucheck (1)
Vérifie les fichiers et les répertoires requis par BNU.
uuclean (1)
Supprime les fichiers du répertoire de spoulage BNU.
uucleanup (1)
Supprime les fichiers sélectionnés du répertoire de spoulage
BNU.
uucpadm (1)
Entre les informations de configuration BNU de base.
uudemon.admin (1)
Donne régulièrement des informations sur l’état des transferts de
fichiers BNU.
uudemon.cleanu (1)
Nettoie les répertoires de spoulage et les fichiers journaux BNU.
uudemon.hour (1)
Lance les appels de transport de fichier vers les systèmes
distants via BNU.
uudemon.poll (1)
Interroge les systèmes spécifiés dans le fichier d’interrogation
BNU.
uulog (1)
Donne des informations sur les activités de transfert de fichiers
BNU sur un système.
uupoll (1)
Force l’interrogation d’un système BNU distant.
uuq (1)
Affiche la file d’attente des travaux BNU et supprime de cette file
les travaux spécifiés.
uusnap (1)
Affiche l’état des contacts BNU avec les systèmes distants.
uustat (1)
Consigne l’état et propose un contrôle limité des opérations BNU.
Ce système d’exploitation propose également les commandes BSD 4.3 uuencode et
uudecode. La commande HDB uugetty n’est pas acceptée.
Pour en savoir plus, reportez-vous à Fichiers BNU, formats de fichiers et répertoires dans
AIX 5L Version 5.3 - Guide de l’utilisateur : communications et réseaux.
Comparaisons pour les gestionnaires de systèmes BSD
A-35
A-36
Concepts de gestion de système AIX – Système d’exploitation et unités
Index
A
adressibilité de fragment de système
de fichiers, 5-24
AIX, généralités sur les administrateurs
système BSD
amorçage et lancement, A-10
commandes, A-11
comptabilité, A-7
cron, A-15
espace de pagination, A-21
unités, A-16
UUCP, A-35
allocation, fichier vide (kproc), 5-26
allocations de fichier vide, 5-26
amorçage
AIX pour administrateurs système BSD, A-10
description
généralités, 2-3
mode de maintenance, 2-6
système de fichiers RAM, 2-7
traitement de l’amorçage, 2-4
B
blocs, coûts des performances de, 5-24
BSD, A-2, A-30, A-31
comparaison à AIX pour les gestionnaires
de systèmes, comptabilité, A-2
comparaison avec les administrateurs
système AIX
amorçage et lancement, A-10
commandes, A-11
comptabilité, A-7
cron, A-15
espace de pagination, A-21
unités, A-16
UUCP, A-35
comparaison pour les administrateurs
système, A-3
comparaison de fichiers, A-17
documentation en ligne
et commande man, A-25
mots de passe, A-27
NFS et NIS (exYellow Pages), A-26
recherche et examen de fichiers, A-20
réseau, A-22
systèmes de fichiers, A-19
terminaux, A-34
comparaison pour les gestionnaires de
systèmes, A-1, A-4
imprimantes, A-31
performances, A-30
C
clavier, modification des attributs,
utilisation de la commande chhwkbd, A-11
codes d’emplacement, 14-5
défini, 14-5
disque connecté directement, 14-7
disque série, 14-7
imprimante/traceur, 14-6
port multiprotocole, 14-8
rotateur/clavier LPFK, 14-8
tty, 14-6
unité de disquette, 14-8
unité SCSI, 14-7
codes d’emplacement
du rotateur/clavier LPFK, 14-8
Commande man, 1-4
commande man, pour administrateurs
système BSD, A-25
commandes, AIX pour administrateurs
système BSD, A-11
compression des données, 5-26
coûts des performances de, 5-29
fragments, 5-19
comptabilité
AIX pour administrateurs système BSD, A-7
collecte de données, généralités, 11-3
commandes
exécution automatique, 11-7
généralités, 11-6
données d’utilisation de l’imprimante, 11-4
données de processus
collecte, 11-3
rapport, 11-5
durée de connexion, collecte, 11-3
fichiers
fichiers de données, 11-9
formats, 11-11
généralités, 11-8
généralités, 11-2
rapport de données, généralités, 11-4
taxation, taxation, 11-4
comptabilité de l’utilisation du disque, 11-4
comptabilité système
collecte de données, généralités, 11-3
commandes, exécution automatique, 11-7
données d’utilisation de l’imprimante,
collecte, 11-4
données de processus
collecte, 11-3
rapport, 11-5
durée de connexion, 11-3
fichiers
fichiers de données, 11-9
formats, 11-11
généralités, 11-8
généralités, 11-2
rapport de données, généralités, 11-4
taxation, taxation, 11-4
Contrôleur de ressources système
fonctions, 10-2
illustration, 10-3
Contrôleur de ressources système SRC
(System Resource Controller)
Index
X-1
attributs, modifiable, 15-2
commandes, liste, 10-3
cron, AIX pour administrateurs système BSD, A-15
D
démon cron, collecte de données, 11-2
Désallocation dynamique de processeur, 7-4
disponibilité
face aux incidents de carte
ou d’alimentation, 3-10
face aux incidents de disque, 3-10
durée de connexion, 11-3
E
E/S à plusieurs chemins, 14-11
environnement de système, 7-4
Désallocation dynamique de processeur, 7-4
environnement système
profil, 7-2
services de manipulation des données
de l’heure, 7-3
environnements shell, personnalisation, 7-2
environnements utilisateur, personnalisation, 7-2
espace d’échange, voir espace de pagination, 4-1
espace de pagination, AIX pour administrateurs
système BSD, A-21
F
fermeture, description, 2-8
fichier .profile, 7-2
fichier /etc/profile, 7-2
fichiers
montage, 5-13
pour administrateurs système BSD, A-17, A-20
fichiers de connexion
fichier .profile, 7-2
fichier /etc/profile, 7-2
fichiers mappe, 3-20
fragments
coûts des performances de, 5-24
effet sur l’utilisation du disque, 5-19
effet sur la sauvegarde et la restauration, 5-30
et un nombre variable d’i–nodes, 5-19
limitation pour pilote d’unité, limitation pour
pilotes d’unité, 5-31
taille de
définition, 5-21
identification, 5-22
G
gestion des connexions à chaud PCI, PCI, 14-9
groupe de sous–systèmes, description, 10-3
groupes de volumes
création de groupes de volumes distincts, 3-9
définition de, 3-3
haute disponibilité, 3-9
mise en œuvre d’une stratégie, 3-24
procédure de mise en service, 3-7
quorums, 3-7
sans quorum, 3-8
stratégie, 3-9
groupes de volumes sans quorum, 3-8
X-2
I
i–nodes, 5-21
et fragments, 5-19
nombre d’octets par i–node (NBPI)
définition, 5-21
identification, 5-22
nombre variable de, 5-21
i–nodes, nombre de, 5-23
idbgen, 7-3
imprimante, pour les gestionnaires
de systèmes BSD, A-31
imprimantes, codes d’emplacement, 14-6
J
JFS (Journaled File System)
avec un nombre variable d’i–nodes, 5-19
compression des données, 5-26
fragments, 5-19
limitations de taille, 5-22
taille maximum de, 5-23
JFS2 (Enhanced Journaled File System),
limitations de taille, 5-22, 5-24
Journal JFS (Journaled File System), taille de, 5-24
L
LVM, 3-1
LVM (Logical Volume Manager), 3-1
définition, 3-7
M
montage
distant, définition, 5-13
généralités, 5-12
local, définition, 5-13
montage de station de travail sans disque
description de, 5-15
sécurité, 5-14
montage des systèmes de fichiers, 5-13
montages automatiques, 5-13
montages automatiques
de /etc/filesystem, 5-13
utilisation de plusieurs montages, 5-13
mots de passe,
pour administrateurs système BSD, A-27
MPIO, 14-11
MWC (cohérence écrit–miroir), 3-14
N
NBPI, 5-21
NFS et NIS, pour administrateurs
système BSD, A-26
NIS, A-26
nombre d’octets par i–node (NBPI), 5-21
allocation, 4-4
caractéristiques de création, 4-8
commandes de gestion, 4-7
généralités, 4-1, 4-4
mode d’allocation Early, 4-4
mode d’allocation Late, 4-4
nombre variable d’i–nodes, 5-21
et fragments, 5-19
Concepts de gestion de système AIX – Système d’exploitation et unités
P
partitions logiques
définition, 3-5
règles d’affectation inter-disque, 3-16
partitions physiques
définition, 3-4
taille, 3-4
performances,
Gestionnaires de systèmes BSD, A-30
pilotes d’unités, effet sur l’utilisation
de fragments sur la taille de, 5-31
point de montage, 5-12
port multiprotocole, codes d’emplacement, 14-8
procédure de mise en service, 3-7
processus
collecte de données comptables, 11-3
génération de rapports comptables, 11-5
gestion, 8-1
profil
fichiers, 7-2
généralités, 7-2
Q
quorums
définition, 3-7
groupes de volumes sans quorum, 3-8
R
range (option), 3-16
règles d’affectation inter-disque, 3-16
règles d’affectation intra-disque, 3-19
règles de contrôle de l’écriture, 3-21
règles de programmation des écritures, 3-12
répartition, 3-21
répertoire /export, 5-8
répertoire /usr/share, 5-7
Répertoire SOPT
(Shared Product Object Tree), 5-9
répertoire SPOT, 5-9
répertoires, montage, 5-13
réseau, pour administrateurs système BSD, A-22
restauration, effet des fragments sur, 5-30
S
sauvegarde
commandes, liste de, 6-2
effet des fragments sur, 5-30
fichiers utilisateur, 6-8
généralités, 6-2
groupe de volumes défini par l’utilisateur,
image système, 6-9
méthodes, 6-2
procédure pour les données système et
utilisateur, 6-6
reproduction d’un système (clonage), 6-7
restauration des données, 6-4
stratégie de gestion
développement, 6-5
planification, 6-5
politique, 6-3
systèmes de fichiers utilisateur, 6-8
types de supports, 6-4
unités, illustration, 6-4
services de manipulation des données
de l’heure, 7-3
SMIT (System Management Interface Tool), 13-1
sous–serveur, description, 10-3
sous–système, propriétés, 10-2
stations de travail sans disque, sécurité du
montage, 5-14
stockage de volume logique
définition, 3-2
groupes de volumes, 3-3
groupes de volumes sans quorum, 3-8
partitions logiques, 3-5
quorums, 3-7
systèmes de fichiers, 3-5
tailles maximales, 3-6
volumes logiques, 3-5
volumes physiques, 3-2
stockage sur volume logique
règles d’affectation inter-disque, 3-16
règles d’affectation intra-disque, 3-19
règles de programmation
des écritures, 3-12, 3-14
Strict (option), 3-17
système, démarrage, 2-2
système de comptabilité
commandes, depuis le clavier, 11-8
données d’utilisation de l’imprimante, 11-5
indication, 11-5
données de l’utilisation du disque, 11-4, 11-5
collecte, 11-4
indication, 11-5
durée de connexion, 11-5
indication, 11-5
fichiers
fichiers de commande runacct, 11-9
fichiers de rapport et de résumé, 11-9
frais, indication, 11-5
rapports
mensuels, 11-6
quotidiens, 11-6
système de fichiers, images, 5-30
système de fichiers / (racine), 5-3
système de fichiers /var, 5-7
systèmes de fichiers
arborescence
généralités, 5-2
répertoire /export, 5-8
répertoire /usr/share, 5-7
système de fichiers / (racine), 5-3
système de fichiers /usr, 5-5
système de fichiers /var, 5-7
commandes de gestion, 5-10, 5-11
compression des données, 5-26
fichiers sporadiques, 5-25
fichiers volumineux, 5-26
fragments, 5-19
généralités, 5-1
i–nodes, 5-19
montage, 5-13
pour administrateurs système BSD, A-19
sauvegarde des systèmes de fichiers
utilisateur, 6-8
Index
X-3
tâches de gestion, 5-10
techniques de journalisation, 5-1
types
CD–ROM, 5-17
DVD–ROM, 5-17
JFS (Journaled File System), 5-17
JFS2 (Enhanced Journaled
File System), 5-17
NFS (Network File System), 5-17
systèmes de fichiers activés, espace libre, 5-26
systèmes de fichiers compatibles
allocations de fichier vide, 5-26
créer, 5-26
géométrie des fichiers volumineux, 5-26
T
taille de groupe d’allocation, 5-23
taxation, 11-4
terminaux, pour administrateurs
système BSD, A-34
traitement de l’amorçage, phases, 2-4
tty (teletypewriter), codes d’emplacement, 14-6
U
unité
AIX pour administrateurs système BSD, A-16
classes, 14-3
états, 14-4
noeuds, 14-2
unité de disquette, codes d’emplacement, 14-8
unités, 14-1
codes d’emplacement, 14-5
configuration d’un grand nombre d’unités, 14-1
unités de bande
attributs, modifiable, 15-4, 15-5, 15-7, 15-8,
15-9, 15-11, 15-12, 15-13
fichiers spéciaux, 15-14
X-4
gestion, 15-1
unités de disque, disque série, codes
d’emplacement, 14-7
unités de disques (disques durs), connecté
directement, 14-7
unités SCSI, codes d’emplacement, 14-7
utilisation de l’imprimante, 11-4
utilisation du disque, effet des fragments sur, 5-19
UUCP, AIX pour administrateurs
système BSD, A-35
V
VGDA (Volume Group Descriptor Area), 3-7
VGSA (Volume Group Status Area), 3-7
Virtual Memory Manager, 4-2
VMM, 4-2
VMM (Virtual Memory Manager), généralités, 4-1
volumes logiques
définition, 3-5
fichiers mappe, 3-20
règles de contrôle de l’écriture, 3-21
répartis, 3-21
stratégie, 3-11
stratégie de groupe de volumes, 3-24
zones actives, 3-22
volumes physiques, définition, 3-2
W
Web–based System Manager, 12-1
Y
Yellow Pages, A-26
pour administrateurs système BSD, A-26
Z
zones actives dans les volumes logiques, 3-22
Concepts de gestion de système AIX – Système d’exploitation et unités
Vos remarques sur ce document / Technical publication remark form
Titre / Title :
Bull Concepts de gestion de système AIX 5L Système d’exploitation et unités
Nº Référence / Reference Nº :
86 F2 48EM 01
Daté / Dated :
Février 2005
ERREURS DETECTEES / ERRORS IN PUBLICATION
AMELIORATIONS SUGGEREES / SUGGESTIONS FOR IMPROVEMENT TO PUBLICATION
Vos remarques et suggestions seront examinées attentivement.
Si vous désirez une réponse écrite, veuillez indiquer ci-après votre adresse postale complète.
Your comments will be promptly investigated by qualified technical personnel and action will be taken as required.
If you require a written reply, please furnish your complete mailing address below.
NOM / NAME :
SOCIETE / COMPANY :
ADRESSE / ADDRESS :
Remettez cet imprimé à un responsable BULL ou envoyez-le directement à :
Please give this technical publication remark form to your BULL representative or mail to:
BULL CEDOC
357 AVENUE PATTON
B.P.20845
49008 ANGERS CEDEX 01
FRANCE
Date :
Technical Publications Ordering Form
Bon de Commande de Documents Techniques
To order additional publications, please fill up a copy of this form and send it via mail to:
Pour commander des documents techniques, remplissez une copie de ce formulaire et envoyez-la à :
BULL CEDOC
ATTN / Mr. L. CHERUBIN
357 AVENUE PATTON
B.P.20845
49008 ANGERS CEDEX 01
FRANCE
Phone / Téléphone :
FAX / Télécopie
E–Mail / Courrier électronique :
+33 (0) 2 41 73 63 96
+33 (0) 2 41 73 60 19
[email protected]
Or visit our web sites at: / Ou visitez nos sites web à :
http://www.logistics.bull.net/cedoc
http://www–frec.bull.com
http://www.bull.com
CEDOC Reference #
No Référence CEDOC
Qty
Qté
CEDOC Reference #
No Référence CEDOC
Qty
Qté
CEDOC Reference #
No Référence CEDOC
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
Qty
Qté
[ _ _ ] : no revision number means latest revision / pas de numéro de révision signifie révision la plus récente
NOM / NAME :
Date :
SOCIETE / COMPANY :
ADRESSE / ADDRESS :
TELEPHONE / PHONE :
FAX :
E–MAIL :
For Bull Subsidiaries / Pour les Filiales Bull :
Identification:
For Bull Affiliated Customers / Pour les Clients Affiliés Bull :
Customer Code / Code Client :
For Bull Internal Customers / Pour les Clients Internes Bull :
Budgetary Section / Section Budgétaire :
For Others / Pour les Autres :
Please ask your Bull representative. / Merci de demander à votre contact Bull.
BULL CEDOC
357 AVENUE PATTON
B.P.20845
49008 ANGERS CEDEX 01
FRANCE
REFERENCE
86 F2 48EM 01
Utiliser les marques de découpe pour obtenir les étiquettes.
Use the cut marks to get the labels.
AIX
Concepts de gestion
de système AIX
Système
d’exploitation
et unités
86 F2 48EM 01
AIX
Concepts de gestion
de système AIX
Système
d’exploitation
et unités
86 F2 48EM 01
AIX
Concepts de gestion
de système AIX
Système
d’exploitation
et unités
86 F2 48EM 01
">