Gérer les modules du VMkernel avec vmkload_mod et esxcfg-module

Décharger un module peu sembler superflu de prime abord. En effet, l’hôte ESX sur lequel vous allez effectuer l’opération ne sera probablement pas plus performant et bien malin qui pourrait voir une augmentation des performances CPU et/ou RAM. Pourtant, au niveau réseau, vous pourrez observer dans certains cas (installations avec de nombreuses LUNs et volumes VMFS…) une rapidité accrue dans le rafraîchissement de vos datastores et de vos adaptateurs de stockage iSCSI et Fiber Channel.

Opérations en environnement VMware ESX 3.5

Pour lister les modules actifs du VMkernel, on utilise soit la commande vmkload_mod -l, soit la commande esxcfg-module -l.

[root@srv5 etc]# vmkload_mod -l
Name           R/O Addr     Length      R/W Addr     Length        ID Loaded
vmklinux       0x87e000     0x20000     0x28a3280    0x4d000       1  Yes
ata_piix       0x89e000     0xb000      0x28f02a0    0x4000        2  Yes
megaraid_sas   0x8a9000     0x7000      0x28f42c0    0x3000        3  Yes
bnx2           0x8b0000     0x10000     0x28f72e0    0x17000       4  Yes
e1000          0x8c0000     0x1c000     0x290e300    0x6000        5  Yes
lvmdriver      0x8dc000     0xb000      0x292b580    0x2000        6  Yes
vmfs3          0x8e7000     0x2c000     0x292d5c0    0x1000        7  Yes
etherswitch    0x913000     0x3000      0x292e688    0x1000        8  Yes
shaper         0x916000     0x3000      0x292fb80    0x1000        9  Yes
tcpip          0x919000     0x3a000     0x2930c00    0x1c000       10 Yes
cosShadow      0x953000     0x3a000     0x294cc80    0x1c000       11 Yes
migration      0x98d000     0xf000      0x2968ca0    0x2000        12 Yes
nfsclient      0x99c000     0x12000     0x296acc0    0x1000        13 Yes
deltadisk      0x9ae000     0x7000      0x296bf60    0x1000        14 Yes
vmfs2          0x9b5000     0x10000     0x296cf80    0x11000       15 Yes
iscsi_mod      0x9c5000     0x35000     0x297dfa0    0xa000        16 Yes

Ici, on remarque que le module vmfs2 est chargé, or nous n’utilisons que vmfs3. On peut donc désactiver ce module pour décharger le VMkernel de cette gestion inutile. Pour cela, on utilise à nouveau la commande vmkload_mod mais cette fois avec l’argument -u (pour unload). La commande esxcfg-module -d aurait également été possible.

[root@srv5 etc]# vmkload_mod -u vmfs2

Ne reste plus qu’à lister de nouveau pour vérifier que le module vmfs2 a bien été désactivé. Vous pouvez bien sûr répéter l’opération pour tout autre module qui vous serait inutile. Comme nous avons pris l’exemple du stockage, continuons dedans. Si vous n’utilisez pas NFS (module nfsclient), désactivez-le à son tour et validez l’opération en listant de nouveau les modules.

[root@srv5 etc]# vmkload_mod -l
Name           R/O Addr     Length      R/W Addr     Length        ID Loaded
vmklinux       0x87e000     0x20000     0x28a3280    0x4d000       1  Yes
ata_piix       0x89e000     0xb000      0x28f02a0    0x4000        2  Yes
megaraid_sas   0x8a9000     0x7000      0x28f42c0    0x3000        3  Yes
bnx2           0x8b0000     0x10000     0x28f72e0    0x17000       4  Yes
e1000          0x8c0000     0x1c000     0x290e300    0x6000        5  Yes
lvmdriver      0x8dc000     0xb000      0x292b580    0x2000        6  Yes
vmfs3          0x8e7000     0x2c000     0x292d5c0    0x1000        7  Yes
etherswitch    0x913000     0x3000      0x292e688    0x1000        8  Yes
shaper         0x916000     0x3000      0x292fb80    0x1000        9  Yes
tcpip          0x919000     0x3a000     0x2930c00    0x1c000       10 Yes
cosShadow      0x953000     0x3a000     0x294cc80    0x1c000       11 Yes
migration      0x98d000     0xf000      0x2968ca0    0x2000        12 Yes
deltadisk      0x9ae000     0x7000      0x296bf60    0x1000        14 Yes
iscsi_mod      0x9c5000     0x35000     0x297dfa0    0xa000        16 Yes

Seul bémol, les modifications effectuées ne seront plus valables au prochain boot. Il faudrait donc envisager de scripter les opérations pour bénéficier de vos modifications à long terme.

Opérations en environnement VMware vSphere 4

Il y a eu peu de changements dans la gestion des modules avec l’arrivée de VMware vSphere 4, néanmoins, ils sont assez significatifs pour être décrits ici. En effet, les commandes de listage et de déchargement de modules sont les mêmes mais la commande esxcfg-module permet désormais de préserver les modifications, même après redémarrage !

Si la désactivation d’un module par esxcfg-module -d <module> fonctionne sans problème, la confirmation n’apparaît pas en listant les modules avec esxcfg-module -l ce qui peut être déroutant. Pourtant, en utilisant la commande esxcfg-module -q (pour lister les modules actifs), on verra bien que le module est déchargé, de même que dans le fichier /etc/vmware/esx.conf, à la ligne correspondante.

/vmkernel/module/vmfs2/enabled = "false"

Pour information, voici le détail des arguments les plus utiles de la commande esxcfg-module :

-e --enable
Enable the given module, indicating it should load at boot time.
-d --disable
Disable the given module preventing it from loading at boot.
This will have no immediate effect on the module state on a running system.
-q --query
Query the system for the modules to load at boot.
-l --list
Detailed list of loaded modules

Remarquez que l’argument -d se comporte donc bien différemment de VMware ESX 3.5. : “Disable the given module preventing it from loading at boot”.

Surveiller un hôte et des services sous Debian Lenny grâce à Mon

Pour monitorer la disponibilité d’un hôte et/ou de services, on installe mon :

apt-get install mon

mon prévient d’un problème via syslog, e-mail ou exécute un script donné. Il peut paramétrer chaque alerte selon plusieurs critères :

• heure/jour de la semaine
• combien de fois un problème doit être signalé

Pour connaître son statut, on utilise la commande monshow :

<serveur>:~# monshow

server: localhost
time: Thu Jul 23 17:15:38 2009
state: scheduler running

All systems OK

Le fichier de configuration de l’application se trouve dans /etc/mon/mon.cf

A présent, je vais vous présenter un exemple de configuration de mon dans lequel vous remarquerez entre autres la possibilité de “prendre les ressources” indisponibles du serveur monitoré. Cela se fait au moyen du service heartbeat qui fera bientôt l’objet d’un article détaillé. Sachez juste pour le moment qu’il faut un deuxième serveur qui passera en production lorsqu’il remarquera une défaillance de son…voisin. Car oui, toute l’astuce réside dans le fait de monitorer son voisin plutôt que de se monitorer soi-même !

maxprocs = 20
histlength = 100
randstart = 60s

authtype = getpwnam

hostgroup ADSL 123.123.123.123
hostgroup SRV-TEST 123.123.123.123

# On surveille le routeur du fournisseur d'acces
watch ADSL
   service ping
       interval 5s
       monitor ping.monitor
       period wd {Mon-Sun}
          alert mail.alert -S "Votre routeur ADSL est down !" votre_email
          upalert mail.alert -S "Votre routeur ADSL est up !" votre_email
          alert hb_standby
          alertafter 5
          alertevery 10m

# On surveille le serveur
watch SRV-TEST

# On surveille le protocole SMTP via Postfix
# En cas de probleme on recupere les ressources via heartbeat
   service postfix
       interval 5s
       monitor smtp.monitor
       period wd {Mon-Sun}
          alert mail.alert -S "Le serveur mail ne repond pas" votre_email
          alert hb_takeover
          upalert mail.alert -S "Le serveur mail repond de nouveau" votre_email
          alertafter 2
          alertevery 10m

# On surveille le protocole HTTP via Squid
# En cas de probleme on recupere les ressources via heartbeat
   service proxy
       interval 5s
       monitor http.monitor -p 8080 -u 'http://www.google.fr/'
       period wd {Mon-Sun}
          alert mail.alert -S "Le proxy ne repond pas" votre_email
          alert hb_takeover
          upalert mail.alert -S "Le proxy repond de nouveau" votre_email
          alertafter 4
          alertevery 10m

# On surveille si le port TCP 10443 est ouvert (Reverse Proxy)
# En cas de probleme on recupere les ressources via heartbeat
   service reverse_proxy
       interval 5s
       monitor tcp.monitor -p 10443
       period wd {Mon-Sun}
          alert mail.alert -S "Le reverse proxy ne repond pas" votre_email
          alert hb_takeover
          upalert mail.alert -S "Le reverse proxy repond de nouveau" votre_email
          alertafter 6
          alertevery 10m

Scripter une sauvegarde ou une restauration de bases avec Microsoft SQL Server 2005

Il est possible de lancer un script .sql à partir d’un batch DOS grâce à la commande sqlcmd. Cela pourra notamment vous être utile dans le cadre d’un lancement de routines de maintenance par tâche planifiée :

sqlcmd -E -i C:backup.sql > C:backup.log

• -E indique une connexion approuvée
• -i permet de spécifier un fichier d’entrée
• > permet la sortie dans un fichier (ici on voudra créer un log des opérations)

Sauvegarde de bases

Ce script permet de faire une sauvegarde à chaud d’autant de bases que l’on souhaite, de personnaliser le chemin de destination ainsi que le nom du fichier de sortie :

BACKUP DATABASE [base] TO DISK = N'\serveurpartage\ma_base.bak'
WITH NOFORMAT, INIT,  NAME = N'sav-base', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO
BACKUP DATABASE, [base1] TO DISK = N'\serveurpartage\ma_base1.bak'
WITH NOFORMAT, INIT,  NAME = N'sav-base1', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

Restauration de bases

Ce script permet de faire une restauration d’autant de bases que l’on souhaite :

RESTORE DATABASE [base] TO DISK = N'\serveurpartage\base.bak'
GO
RESTORE DATABASE [base1] TO DISK = N'\serveurpartage\base1.bak'
GO