Print-friendly Version

Don Turnbull, avril 2007

Présentation

Le SMF est un nouveau modèle unifié pour les services et la gestion de service compris dans le système d'exploitation Solaris. Le SMF offre une vue plus approfondie et plus fonctionnelle des processus gérés pendant le démarrage et l'arrêt d'un système Solaris. En outre, les processus gérés par l'intermédiaire du SMF peuvent comporter des dépendances et sont surveillés pour permettre des redémarrages en cas d'échec d'un processus ou d'arrêt incorrect.

Le SMF est un élément essentiel de la technologie d'autorétablissement prédictif disponible dans le SE Solaris 10, qui assure la récupération automatique des défaillances logicielles et matérielles ainsi que des erreurs d'administration. De plus, les services gérés par le SMF peuvent être délégués à des utilisateurs non root. Enfin, le SMF est une suite de la méthode hérité de démarrage et d'arrêt des services, bien que les scripts/etc/rc continuent à s'exécuter pour assurer la compatibilité ascendante.

Le déploiement des services par l'intermédiaire du SMF offre un environnement plus homogène et plus robuste. En premier lieu, les utilisateurs peuvent interroger le SE Solaris avec une simple commande (svcs -a) pour déterminer si un service est exécuté, au lieu de tenter une connexion en se demandant si elle va réussir. De plus, les services critiques peuvent être redémarrés automatiquement en cas de problème, comme un arrêt par inadvertance, un bogue provoquant un core dump ou d'autres défaillances de processus. Ensuite, le SMF fournit une journalisation détaillée et commune ainsi qu'un traitement robuste des erreurs pour éviter que les services ne se figent après un changement d'état du système. Consultez la page du manuel man page for smf(5) pour des informations plus détaillées.

Après une installation de logiciel standard, il peut y avoir une demi douzaine de services, ou plus, à redémarrer et à arrêter pendant le démarrage et l'arrêt du système. En outre, ces processus peuvent dépendre les uns des autres et peuvent nécessiter d'être surveillés et redémarrés s'ils échouent. Pour chaque processus, des étapes logiques doivent être effectuées pour les incorporer comme services dans le SMF :

• Créez un fichier de manifeste de service.
• Créez un fichier script des méthodes pour définir les méthodes de démarrage, d'arrêt et de redémarrage pour le service.
• Validez et importez le manifeste de service à l'aide de svccfg(1M).
• Activez ou démarrez le service avec svcadm(1M).
• Vérifiez que le service est exécuté en utilisant svcs(1).

En utilisant des processus SAS comme exemple, nous allons créer deux services, l'un pour le serveur de métadonnées SAS (OMR) et l'autre pour le multiplicateur d'objet SAS. Dans cet exemple, le multiplicateur d'objet ne peut pas tenter de démarrer avant que l'OMR ait démarré et doit être arrêté avant l'arrêt de l'OMR.

Configuration du service OMR

Étape 1

Créez le fichier de manifeste conformément à la description dans la page du manuel smf_method(5). Pour plus de clarté, ce fichier doit être placé dans un répertoire dédié aux fichiers relatifs à l'application. En réalité, le service sera organisé dans un dossier logique au sein du SMF, c'est pourquoi il est utile de disposer d'un dossier dédié aux fichiers relatifs à l'application. En revanche, il n'existe pas de nom de répertoire ou d'exigence d'emplacement dans le SMF.

Dans l'exemple, le service OMR sera organisé dans SMF en faisant partie du dossier d'application SAS. Il s'agit d'un regroupement logique ; il n'existe par de dossier physique intitulé sasassocié au SMF. Toutefois, à des fins de gestion, application/sas/metadata fera référence au service. D'autres processus liés SAS peuvent aussi être ajoutés et identifiés ultérieurement sous application/sas. Pour l'exemple, le fichier /var/svc/manifest/application/sas/metadata.xml doit être créé et contenir les éléments suivants :

<?xml version="1.0"?>
<!DOCTYPE service_bundle
  SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">

<service_bundle type='manifest' name='SAS:Metadata'>
  <service
    name='application/sas/metadata'
    type='service'
    version='1'>
    <create_default_instance enabled='false' />
    <single_instance />

    <dependency
      name='multi-user-server'
      grouping='optional_all'
      type='service'
      restart_on='none'>
        <service_fmri value='svc:/milestone/multi-user-server' />
    </dependency>
    <exec_method
      type='method'
      name='start'
      exec='/lib/svc/method/sas/metadata %m'
      timeout_seconds='60'>
      <method_context>
        <method_credential user='sas' />
      </method_context>
    </exec_method>

    <exec_method
      type='method'
      name='restart'
      exec='/lib/svc/method/sas/metadata %m'
      timeout_seconds='60'>
      <method_context>
        <method_credential user='sas' />
      </method_context>
    </exec_method>

    <exec_method
      type='method'
      name='stop'
      exec='/lib/svc/method/sas/metadata %m'
      timeout_seconds='60' >
      <method_context>
        <method_credential user='sas' />
      </method_context>
    </exec_method>

    <property_group name='startd' type='framework'>
      <propval name='duration' type='astring' value='contract' />
    </property_group>

    <template>
      <common_name>
        <loctext xml:lang='C'>
          SAS Metadata Service
        </loctext>
      </common_name>
      <documentation>
        <doc_link name='sas_metadata_overview' iri=
'http://www.sas.com/technologies/bi/appdev/base/metadatasrv.html'
        />
        <doc_link name='sas_metadata_install' uri=
            'http://support.sas.com/rnd/eai/openmeta/v9/setup' />
      </documentation>
    </template>
  </service>
</service_bundle>

Le fichier de manifeste se compose à la base de deux strophes balisées dont les propriétés définissent comment le processus doit être démarré, arrêté et redémarré, ainsi que ses éventuelles dépendances. La première balise , <service_bundle> définit le nom du bundle de service qui sera utilisé pour regrouper les services et fera partie des paramètres dans les commandes svcs (svcs, svcmgr, et ainsi de suite). La balise interne, <service>, définit un processus spécifique, ses dépendances et comment manipuler le processus. Consultez lapage du manuel de service_bundle(4) pour des informations plus détaillées sur le format de fichiers de manifeste.

Étape 2

Créez les scripts des méthodes. Ce fichier est analogue aux scriptsrc traditionnels utilisés dans les versions précédentes du SE Solaris. Ce fichier doit être un script capable de démarrer, arrêter et redémarrer le processus. Ce script doit être exécutable pour tous les utilisateurs susceptibles de gérer le service, et doit être placé dans le répertoire et le nom de fichier référencés dans les propriétés exec du fichier de manifeste. Pour l'exemple de cette procédure, le fichier correct est /lib/svc/method/sas/metadata, basé sur le fichier de manifeste élaboré à l'étape 1. Consultez les pages du manuel de smf_method(5) pour des informations plus détaillées sur les scripts de méthode.

#!/sbin/sh
# Start/stop client SAS MetaData service
#
.. /lib/svc/share/smf_include.sh
SASDIR=/d0/sas9-1205
SRVR=MSrvr
CFG=$SASDIR/SASMain/"$SRVR".sh

case "$1" in
'start')
        $CFG start
        sleep 2
        ;;
'restart')
        $CFG restart
        sleep 2
        ;;
'stop')
        $CFG stop
        ;;
*)
        echo "Usage: $0 { start | stop }"
        exit 1
        ;;
esac
exit $SMF_EXIT_OK

Étape 3

Validez et importez le fichier de manifeste dans le référentiel du service Solaris pour créer le service dans le SMF et le rendre disponible à la manipulation. Les commandes suivantes indiquent le nom de fichier correct à utiliser pour le manifeste dans cet exemple.

# svccfg
svc:> validate /var/svc/manifest/application/sas/metadata.xml
svc:> import /var/svc/manifest/application/sas/metadata.xml
svc:> quit

Étape 4

Activez le service en utilisant la commande svcadm. Le commutateur -t vous permet de tester la définition du service sans la rendre persistante. Excluez le commutateur si -t vous voulez que la définition soit une modification permanente qui persiste entre les réinitialisations.

# svcadm enable -t svc:/application/sas/metadata

Étape 5

Vérifiez que le service est en ligne et que les processus sont réellement exécutés en utilisant la commande svcs.

# svcs -a | grep sas
online  8:44:37 svc:/application/sas/metadata:default

# ps -ef | grep sas
.....
sas 26791  1  0  08:44:36 ?  0:00 /bin/sh /d0/SASMain/MSrvr.sh
.....

Configuration du service multiplicateur d'objet

Maintenant, dans l'exemple, le processus OMR (ci-dessus) et le processus de multiplicateur d'objet étaient à configurer. Le multiplicateur d'objet dépend de l'OMR. Le reste de ce document décrit la configuration du processus du multiplicateur d'objet dépendant.

Étape 1

Le fichier de manifeste pour le service de multiplicateur d'objet est similaire à celui utilisé pour le service OMR. Il existe quelques petites modifications et une dépendance différente. Les différences sont mises en évidence en gras ci-après :

<?xml version="1.0">
<!DOCTYPE service_bundle
  SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">

<service_bundle type='manifest' name='SAS:ObjectSpawner'>
  <service
    name='application/sas/objectspawner'
    type='service'
    version='1'>
    <create_default_instance enabled='false' />
    <single_instance />
    <dependency
      name='sas-metadata-server'
      grouping='optional_all'
      type='service'
      restart_on='none'>
        <service_fmri value='svc:/application/sas/metadata' />
    </dependency>
    <exec_method
      type='method'
      name='start'
      exec='/lib/svc/method/sas/objectspawner %m'
      timeout_seconds='60'>
      <method_context>
        <method_credential user='sas' />
      </method_context>
    </exec_method>

    <exec_method
      type='method'
      name='restart'
      exec='/lib/svc/method/sas/objectspawner %m'
      timeout_seconds='60'>
      <method_context>
        <method_credential user='sas' />
      </method_context>
    </exec_method>

    <exec_method
      type='method'
      name='stop'
      exec='/lib/svc/method/sas/ objectspawner %m'
      timeout_seconds='60' >
      <method_context>
        <method_credential user='sas' />
      <method_context>
    <exec_method>

    <property_group name='startd' type='framework'>
      <propval name='duration' type='astring' value='contract' />
    </property_group>

    <template>
      <common_name>
        <loctext xml:lang='C'>
          SAS Object Spawner Service
        </loctext>
      </common_name>
      <documentation>
        <doc_link name='sas_metadata_overview' iri=
'http://www.sas.com/technologies/bi/appdev/base/metadatasrv.html'
        />
        <doc_link name='sas_metadata_install' uri=
            'http://support.sas.com/rnd/eai/openmeta/v9/setup' />
      </documentation>
    </template>
  </service>
</service_bundle>

Étape 2

Une fois le fichier de manifeste créé, créez le script /lib/svc/method/sas/objectspawner:

#!/sbin/sh
# Start/stop client SAS Object Spawner service
#
.. /lib/svc/share/smf_include.sh
SASDIR=/d0/sas9-1205
SRVR=ObjSpa
CFG=$SASDIR/SASMain/"$SRVR".sh

case "$1" in
'start')
        $CFG start
        sleep 2
        ;;
'restart')
        $CFG restart
        sleep 2
        ;;
'stop')
        $CFG stop
        ;;
*)
        echo "Usage: $0 { start | stop }"
        exit 1
        ;;
esac
exit $SMF_EXIT_OK

Étape 3

Validez et importez le fichier de manifeste de la même manière que pour le service OMR :

# svccfg
svc:> validate /var/svc/manifest/application/sas/objectspawner.xml
svc:> import /var/svc/manifest/application/sas/objectspawner.xml
svc:> quit

Étape 4

Activez le nouveau service de la même manière que pour le service OMR :

# svcadm enable -t svc:/application/sas/objectspawner

Étape 5

Enfin, vérifiez que le service est actif et exécuté de la même manière que pour le service OMR :

# svcs -a | grep sas
online  10:28:39 svc:/application/sas/metadata:default
online  10:38:20 svc:/application/sas/objectspawner:default

# ps -ef | grep sas
.....
sas 26791  1  0  18:44:36 ?  0:00 /bin/sh /d0/SASMain/MSrvr.sh
sas 26914  1  0  18:18:49 ?  0:00 /bin/sh /d0/SASMain/ObjSpa.sh
.....

Dans une situation réelle, SAS détiendrait d'autres services et le processus de service serait le processus parent. Toutefois, le fait que le script défini comme script de méthode du processus s'exécute apporte la preuve que la sortie de svcs -a est correcte ; le service est exécuté.

Démonstration de la fonctionnalité SMF

Pour démontrer que les services redémarrent automatiquement par eux-mêmes conformément à leur configuration, arrêtez le serveur de métadonnées actuel (PID 26791).

# kill 26791

La commande ps(1) indique que le précédent PID Métadonnées de 26791 n'existe plus et qu'un nouveau PID, 27035, est désormais exécuté. Tout a redémarré sans intervention de l'utilisateur.

# ps -ef | grep sas
.....
sas 27035  1  0  18:44:36 ?  0:00 /bin/sh /d0/SASMain/MSrvr.sh
sas 26914  1  0  18:18:49 ?  0:00 /bin/sh /d0/SASMain/ObjSpa.sh
.....

Sachant que le serveur de métadonnées est un composant essentiel du déploiement SAS 9, la fonctionnalité SMF constitue un atout important pour la disponibilité de l'environnement d'application SAS. La plupart des applications sont dans le même cas. Par l'intermédiaire du SMF, les processus d'une application peuvent être automatisés, surveillés et gérés avec une moindre charge et une moindre personnalisation par l'administrateur du SE Solaris.

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.