Distribution des applications et des données

Les rubriques qui suivent sont destinées à simplifier la configuration générale du groupe de travail, en termes de choix des éléments de traitements implantés ou exécutés sur un système donné. Cette section sera éclairée par la lecture préalable de la précédente, « Choix du modèle de partage de fichiers » ; vous noterez l’accent mis sur le « Modèle client-serveur ».

Pour de plus amples informations, voir :

Modèle de partage de fichiers HP-UX (V.4)

HP-UX a introduit avec la version 10.0 une nouvelle configuration du système de fichiers. Elle est basée sur les systèmes de fichiers ATT SVR4 et OSF/1. Ses avantages sont les suivants :

Séparation du système d’exploitation et des applications.
Une base pour les modèles de partage de fichiers décrits dans « Modèle NFS sans disque » et « Modèle client-serveur ».
Compatibilité avec d’autres fournisseurs de systèmes UNIX.

Pour plus d’informations, voir HP-UX 10.0 File System Layout sur le site http://docs.hp.com.

Comment tout cela facilite-t-il le partage de fichiers ?

La nouvelle configuration est plus directe et plus logique que la version 9.x, elle est indispensable à l’utilisation de NFS sans disque (voir « Modèle NFS sans disque »). Elle devrait simplifier l’interaction avec les systèmes UNIX d’autres fournisseurs.

Elle ne modifie pas le dispositif de configuration des systèmes de fichiers NFS, mais elle simplifie leur gestion sur une question déterminante : la séparation des applications non-« système » présentes dans /opt et les modifications apportées aux applications telles que Netscape pour s’y conformer, ont pour conséquence que le serveur peut maintenant exporter une application donnée depuis un simple sous-répertoire de /opt au lieu d’exporter plusieurs sous-répertoires pour chaque application, voire la totalité du répertoire /usr/local.

Quelles ressources doivent être distribuées ou conservées en local ?

Théorie

Le paradigme de partage V.4 divise les répertoires HP-UX en deux catégories : privés et partagés (également appelés dynamiques et statiques).

Les répertoires contenant les informations de configuration système sont désignés comme privés et ne doivent pas être partagés via NFS. Ce sont :

/ (racine)
/etc
/dev
/var
/stand

Le modèle définit également /home (pour les répertoires personnels utilisateurs), /tmp et /mnt (pour le montage local) comme privés, même si dans la pratique il existe des arguments en faveur du partage de /home et /var/mail (voir « Devez-vous partager vos répertoires personnels et vos répertoires de messagerie électronique ? »). En outre, /opt lui-même ne doit pas être partagé, bien que ses sous-répertoires soient prioritaires en termes de partage.

Les répertoires définis comme partageables sont :

/usr
/sbin
sous-répertoires de /opt

Pratique

En pratique, sauf sous NFS sans disque (voir « Modèle NFS sans disque »), il n’est pas conseillé de partager /sbin ou les sous-répertoires de /usr autres que /usr/local, car ceci crée une trop forte dépendance (le client NFS ne peut fonctionner que si le serveur NFS est en service), et en raison des problèmes qui interviendront lors de la mise en place d’une nouvelle révision de HP-UX. HP recommande de ne mettre en œuvre ce type de configurations intégrées que sous NFS sans disque (qui est actuellement limité aux systèmes 10.x).

Les répertoires dont vous pouvez envisager le partage sont :

Les répertoires d’applications sous /opt.
Les répertoires contenant les données sur lesquelles agissent les applications partagées.
Les répertoires contenant les projets sur lesquels collaborent un certain nombre d’utilisateurs.
Les répertoires contenant d’importantes données volatiles devant être sauvegardées de nuit.

À titre d’exemple, la source du présent document est stockée sur un serveur de fichiers, un système de la Série 800 utilisant HP-UX 10.20, avec une sauvegarde effectuée chaque nuit. Les outils de création et le navigateur Web résident sur un serveur d’applications de classe K exécutant la version 10.20, sur lequel est effectuée toute la maintenance du logiciel. Nos disques locaux ne sont pas sauvegardés et ne contiennent aucune application, ni aucun outil exigeant une assistance externe.

Distribution des applications

Les principaux critères sont ici le rendement et la facilité de gestion. Les applications peuvent être distribuées :

En les stockant sur un serveur et en les distribuant aux stations de travail via NFS.
En les stockant sur un serveur auquel les utilisateurs se connecteront afin de les exécuter.

La seule configuration à éliminer dès le départ est l’installation individuelle de chaque application sur le disque local de chaque station ; elle peut être envisagée comme une exception pour un utilisateur particulier, mais les problèmes liés à la maintenance des logiciels l’interdisent pratiquement comme approche générale.

Les applications étant stockées sur un (ou des) serveur(s), est-il préférable de les exécuter sur les stations de travail (via NFS) ou sur le serveur ? Les avis sont partagés et vous pouvez, en fait, conjuguer les deux approches. N’oubliez pas, toutefois, que les applications actuelles exécutent de nombreuses permutations de fichiers et sont gourmandes en mémoire ; il est souvent préférable de concentrer ces ressources sur un serveur plutôt que de les répartir entre des stations de travail individuelles.

Pour faciliter au maximum la gestion des informations (sauvegarde et mises à jour du logiciel), vous devez :

Conserver vos données sur un site central où elles seront faciles à sauvegarder.
Ne conserver qu’une version et qu’une copie de chaque application.
Si possible, concentrer les applications sur un même serveur puissant.

Choisissez la configuration la plus simple sous réserve que ceci ne nuise pas aux performances.

Serveurs pour différentes fonctions

Les éléments utiles d’un système informatique sont les applications et les données qu’elles manipulent. Votre tâche est de décider comment distribuer ces applications et ces données à l’intérieur du groupe de travail, de façon à garantir leur accès et leur sécurité.

Dans cette section, nous supposons que :

Certains des utilisateurs sont équipés de stations de travail (par opposition aux terminaux de visualisation).
Les membres du groupe de travail partagent un certain nombre d’applications.

Il est nécessaire de prévoir le stockage des applications partagées à un emplacement centralisé servant à les installer, les configurer, les sauvegarder et les gérer. Prévoyez également de conserver les données partagées par les utilisateurs et le plus grand nombre possible de données volatiles (à savoir les informations variant fréquemment, partagées ou non) sur un site central où il sera facile d’effectuer leur sauvegarde, et d’où elles seront distribuées aux stations de travail via NFS. Un système dont les disques contiennent des données partagées est généralement appelé serveur de fichiers (même si, en fait, ces données résident dans des bases de données, et non dans des fichiers). Un système sur lequel sont stockées des applications partagées est appelé serveur d’applications ou serveur de calcul ; nous utiliserons ici l’expression serveur d’applications.

Dans de nombreux groupes de travail, le serveur de fichiers et le serveur d’applications se trouvent sur la même machine qui abrite toutes les informations partagées et celles devant faire l’objet de sauvegardes fréquentes. Ce système est peut-être commode, et sans doute correspond-il à vos ressources existantes, mais il ne représente pas la solution idéale, car les fonctions d’un serveur de fichiers diffèrent de celles d’un serveur d’applications, ceci entraînant des conséquences : par exemple, un processeur occupé à traiter les demandes NFS disposera de moins de cycles pour l’exécution des applications.

Serveur de fichiers

Les utilisateurs ne se connectent normalement pas à un serveur de fichiers ; ils obtiennent les informations nécessaires par l’intermédiaire d’un montage en mode NFS.

Les principales caractéristiques d’un serveur de fichiers sont :

Un espace disque important.
L’utilisation de disques entrelacés, qui permet d’effectuer des entrées/sorties simultanées sur plusieurs disques, améliore le débit.
Une quantité de mémoire RAM importante.
Des interfaces d’entrées/sorties rapides de type Fast-Wide SCSI.
La proximité des stations de travail desservies.
Les concentrateurs, routeurs, commutateurs et segments de réseau local intermédiaires ne peuvent que ralentir le processus.

En conclusion, le rôle du processeur d’un serveur de fichiers n’est pas négligeable, mais il n’est pas aussi important que celui d’un serveur d’applications.

Serveur d’applications

Si vous possédez (ou avez les moyens d’acquérir) les ressources matérielles nécessaires, installez les applications sur un système auquel les utilisateurs pourront se connecter pour les exécuter. Ils pourront y accéder ou non selon la puissance et la capacité de leurs stations de travail, les performances du réseau local et la compatibilité des applications avec le système d’exploitation. Mais il est probable que certains utilisateurs du groupe ne pourront exécuter toutes leurs applications en mode local ; d’autres préféreront s’en abstenir en raison des faibles performances obtenues en mode local. De plus, certaines applications comme les grands SGBD exigent des ressources qui n’existent pas sur une station de travail ordinaire.

Un serveur d’applications exige donc :

Toutes les caractéristiques d’un serveur de fichiers, car il peut être amené à en jouer le rôle, en distribuant, via NFS, les applications à des clients qui les exécuteront en mode local.
Pour des raisons de performances, il ne s’agit probablement pas d’une solution idéale (les applications seront sans doute exécutées plus rapidement si l’unité centrale du serveur n’est pas occupée à traiter des demandes de traitement NFS), mais il est très courant et, concrètement, il fonctionne correctement.
Un puissant processeur, voire plusieurs, pour l’exécution de grandes applications, éventuellement en parallèle.

Pour des raisons liées à la compatibilité avec les applications, un serveur d’applications peut également exiger des mises à jour du système d’exploitation plus fréquentes qu’un serveur de fichiers.