Optimisation mémoire d'un hôte HPVM

L'utilisation de HPVM (aka Integrity VM) pour virtualiser des serveurs HP-UX permet de consolider aisément de nombreuses machines sur un unique hôte.
Néanmoins, la configuration initiale du serveur hôte peut impacter sensiblement la disponibilité mémoire allouable aux VM.
Par exemple, sur un serveur configuré avec peu de personnalisation :

#  kctune | grep -v Default
Tunable                            Value  Expression   Changes
base_pagesize                         64  64
filecache_max                 1027323330  1%           Imm (auto disabled)
filecache_min                 1027323330  1%           Imm (auto disabled)
max_thread_proc                     3000  3000         Immed
maxdsiz                       2063835136  2063835136   Immed
maxdsiz_64bit                34359738368  34359738368  Immed
maxfiles                            2048  2048

# kmeminfo
tool: kmeminfo 10.11 - libp4 9.466 - libhpux 1.309 - HP CONFIDENTIAL
unix: /stand/current/vmunix 11.31 64bit Montvale on host "xxxxxx"
core: /dev/kmem live
nbpg: 65536 bytes
hpvm: host
------------------------------ ----------------------------------------
Physical memory usage summary (in page/byte/percent):

Physical memory       =  1572360   96.0g 100%
Free memory           =    21715    1.3g   1%
User processes        =  1371494   83.7g  87%  details with -user
  Detached SHMEM      =        2  128.0k   0%  details with -shmem
System                =   174935   10.7g  11%
  Kernel              =   143585    8.8g   9%  kernel text and data
    HPVM overhead     =    27803    1.7g   2%  details with -hpvm
    Dynamic Arenas    =    54002    3.3g   3%  details with -arena
      vx_inode_kmcach =     6623  413.9m   0%
      vx_global_kmcac =     5954  372.1m   0%
      spinlock_arena  =     4246  265.4m   0%
      reg_fixed_arena =     3837  239.8m   0%
      FCACHE_ARENA    =     3827  239.2m   0%
      Other arenas    =    29515    1.8g   2%  details with -arena
    Super page pool   =      525   32.8m   0%  details with -kas
    Emergency pool    =    49686    3.0g   3%  system critical reserve
    UAREA's           =      728   45.5m   0%
    Overflow pte's    =      784   49.0m   0%
    Static Tables     =     5956  372.2m   0%  details with -static
      pfdat           =     4798  299.9m   0%
      text            =      559   34.9m   0%  vmunix text section
      bss             =      321   20.1m   0%  vmunix bss section
      inode           =      112    7.0m   0%
      data            =       99    6.2m   0%  vmunix data section
      Other tables    =       65    4.1m   0%  details with -static
  File Cache          =    31350    1.9g   2%  details with -ufc

Si on exclut la surcharge engendrée par HPVM, la quantité de mémoire réservée pour le système est de 9 Go pour une quantité totale de 96 Go, soit plus de 9%.
Si on y ajoute le cache de fichiers, on arrive à presque 11 Go (11,5%)


Au prix de la mémoire installée sur les machines HP Integrity, il est judicieux de se pencher sur son utilisation optimale.


La partie facile 
Le premier levier pour optimiser la mémoire est le cache de fichiers.
La fonction du serveur hôte n'étant pas de distribuer des fichiers ou d'en faire un usage intensif, le bénéfice d'un cache de grande taille est nul.
On peut réduire à une taille fixe de 200 Mo.

# kctune  -v filecache_max
Tunable             filecache_max
Description         Maximum amount of physical memory to be used for caching file I/O data
Module              fs_bufcache
Current Value       205462700
Value at Next Boot  205462700
Value at Last Boot  205462700
Default Value       51365609472 (automatic)
Can Change          Immediately (Automatic Tuning Disabled)

#kctune filecache_min=205462700 filecache_max=205462700

Et voilà, 1,7 Go facilement récupérés et sans douleur.


Déjà optimisé mais un rappel ne fait pas de mal
Sur un serveur équipé de 96 Go, la gestion des pages mémoires peut nécessiter une quantité importante de mémoire.
96 Go = 100663296 Ko soit 25 165 824 pages de 4 ko
Chaque page nécessitant 200 octets, il ne faut pas moins de 4,6 Go pour sa gestion.
Exemple réel sur un serveur avec 58 Go:
taille de page de 4k : 
pfdat = 742328             2.8g 5%
Après l'augmentation de la taille de page à 64k :
pfdat = 2899               181.2m 0%
La modification de la taille de page mémoire de base est heureusement effectuée automatiquement lors de l'installation de HPVM.
Dans les autres cas, la commande est de modification est la suivante :
# kctune base_pagesize=64
Il faut toutefois vérifier que les applications supportent cette modification de taille de page par défaut.


De la faible utilisation des fichiers
Un autre levier très important mais qu'il faut manipuler avec précaution est le nombre d'Inde HFS maximum disponible en mémoire "ninode" ainsi que son pendant pour VXFS "vx_ninode". Comme pour le nombre maximum de descripteurs de fichiers ouvrables en même temps (aka "nfiles"), il est important de prendre toutes les précautions nécessaires avant de toucher à ces "tunables".
Sous HP-UX 11i v3, HFS devient obsolète même pour /stand. On peut donc réduire "ninode" à son minimum. "vx_ninode" devient prépondérant.

#  kctune|grep ninode
ninode                8192  Default
vx_ninode            20000  20000        Immed
Par défaut (lorsque vx_ninode = 0), le nombre d'inode pour des serveurs disposant de plus de 3 Go de ram est de 131072. 

Pour avoir un état à un instant T du taux d'utilisation de la table d'inode, il faut utiliser la commande :
#  vxfsstat -v / | grep maxino
vxi_icache_inuseino            1013    vxi_icache_maxino             20000
ou la commande sar : 

# sar -v 1 1

HP-UX xxxxxxxx B.11.31 U ia64    12/05/11

10:53:35 text-sz  ov  proc-sz  ov  inod-sz  ov  file-sz  ov
10:53:36   N/A   N/A 182/4200  0  1008/28192 0  999/2147483647 0

Le résultat de la commande sar nous renvoie le nombre d'inodes utilisés et le nombre maximum d'inodes HFS et VXFS confondus.
Dans le cas de nos serveurs hôte HPVM, ce nombre a été ramené sans problème à 20000.
# /usr/sbin/kctune vx_ninode=20000

Un redémarrage sera nécessaire à la prise en compte des dernières modifications.


A la fin...
Le résultat après la modification sans risque de ces quelques paramètres : un peu plus de 3 Go récupérés. De quoi donner un peu de flexibilité aux projets hébergés ou consolider encore un peu plus sur cette machine.

tool: kmeminfo 10.11 - libp4 9.466 - libhpux 1.309 - HP CONFIDENTIAL
unix: /stand/current/vmunix 11.31 64bit Montvale on host "xxxxxxxx"
core: /dev/kmem live
nbpg: 65536 bytes
hpvm: host
----------------------------------------------------------------------
Physical memory usage summary (in page/byte/percent):

Physical memory       =  1572355   96.0g 100%
Free memory           =    59109    3.6g   4%
User processes        =  1389015   84.8g  88%  details with -user
  Detached SHMEM      =        1   64.0k   0%  details with -shmem
System                =   124435    7.6g   8%
  Kernel              =   118249    7.2g   8%  kernel text and data
    HPVM overhead     =    44642    2.7g   3%  details with -hpvm
    Dynamic Arenas    =    14956  934.8m   1%  details with -arena
      ALLOCB_MBLK_DA  =     1197   74.8m   0%
      spinlock_arena  =     1129   70.6m   0%
      vx_buffer_kmcac =     1114   69.6m   0%
      FCACHE_ARENA    =     1022   63.9m   0%
      vx_global_kmcac =      967   60.4m   0%
      Other arenas    =     9527  595.4m   1%  details with -arena
    Super page pool   =      190   11.9m   0%  details with -kas
    Emergency pool    =    49686    3.0g   3%  system critical reserve    UAREA's           =      658   41.1m   0%
    Overflow pte's    =      784   49.0m   0%
    Static Tables     =     5983  373.9m   0%  details with -static
      pfdat           =     4798  299.9m   0%
      text            =      563   35.2m   0%  vmunix text section
      bss             =      346   21.6m   0%  vmunix bss section
      inode           =      112    7.0m   0%
      data            =       99    6.2m   0%  vmunix data section
      Other tables    =       64    4.0m   0%  details with -static
  File Cache          =     6186  386.6m   0%  details with -ufc


Une question reste en suspend : quid du "Emergency pool" (system critical reserve)
Je n'ai trouvé aucune référence à sa raison d'être ou à son utilisation.
Si quelqu'un a des informations, je suis preneur.


Références :
- Performance Cookbook :
- Common Misconfigured HP-UX Resources
- HP-UX 11.31 - The Cost of Page Frame Data Table pfdat in Large Memory System
- Tunable Base Page Size
- Kernel parameters for HP-UX systems running Oracle E-Business Suite software applications
- Introduction to performance tuning for HP-UX
- SAP ON HP-UX BEST PRACTICES - PART 2

[1/2] Tunnel IPSec entre un iPhone et Ubuntu 10.04

Pour tous ceux et celles qui, comme moi, sont paranoïaque conscient du manque de confidentialité qu'offre un hotspot wifi, voici un petit tutoriel pour créer un tunnel IPsec entre un iPhone (ou iPad) et un petit serveur Ubuntu.

Pour ma part, j'ai choisi de louer une VM dans le cloud du célèbre hébergeur français OVH.
Mon besoin étant assez réduit, j'ai choisi l'offre minimale. Seul bémol, la puissance allouée est proportionnelle au faible prix pratiqué.

Cet article s'inspire du wiki officiel de StrongSwan. J'espère toutefois apporter une dose de facilité et d'industrialisation permettant un passage rapide et sans douleur au VPN IPSec.

La gestion des fichiers par package (dpkg, rpm, ebuild...) étant, IMHO, nécessaire à une saine administration des serveurs, StrongSwan sera re-compilé et packagé. De très bons packageur (ça se dit ?) travaillent dûr chez Debian/Ubuntu. Il serait dommage de s'en passer.

Nous réutiliserons donc un paquet source destiné à la dernière version d'Ubuntu : http://packages.ubuntu.com/source/precise/strongswan

De prime abord, installation des pré-requis nécessaires au fonctionnement de StrongSwan 

$ sudo apt-get install ipsec-tools 

Pré-requis nécessaires à la compilation. Une partie de ceux-ci pourront être dé-installé après la phase de packaging. 

$ sudo apt-get install build-essential fakeroot dpkg-dev devscripts gperf libcap-dev libgmp3-dev bison flex

$ sudo apt-get install libssl-dev  libcurl4-openssl-dev  libldap2-dev libpam0g-dev libkrb5-dev po-debconf hardening-wrapper network-manager-dev libfcgi-dev clearsilver-dev libxml2-dev libsqlite3-dev libnm-util-dev debhelper libtool libnm-glib-dev

Récupération des sources de StrongSwan : 

$ mkdir Sources && cd Sources

$ wget  http://archive.ubuntu.com/ubuntu/pool/universe/s/strongswan/strongswan_4.5.2-1.2.dsc

$ wget http://archive.ubuntu.com/ubuntu/pool/universe/s/strongswan/strongswan_4.5.2.orig.tar.gz

$ wget  http://archive.ubuntu.com/ubuntu/pool/universe/s/strongswan/strongswan_4.5.2-1.2.debian.tar.gz

Decompression

$ tar xzf strongswan_4.5.2.orig.tar.gz 

$ cd strongswan-4.5.2/

$ tar xf ../strongswan_4.5.2-1.2.debian.tar.gz 

Ajout de l'option "cisco-quirks" conformément au wiki StrongSwan.
$ perl -i.bak -pe  's/(--enable-led)/\1 --enable-cisco-quirks/' debian/rules

Compilation 

$ dpkg-buildpackage -rfakeroot -uc -b

Lors de la tentative de compilation, l'erreur suivante doit apparaître : 

dpkg-checkbuilddeps: Unmet build dependencies: libnm-glib-vpn-dev (>= 0.7)

Ce paquet, lié à l'utilisation de NetworkManager n'est disponible qu'à partir de "Natty". 

Ca tombe bien, le fichier "debian/rules" configure détecte automatiquement la présence de NM.

# And only enable network-manager building if the libraries are present

# (they will be when the build-deps are fulfilled, but this makes it easier

# to do backports where the network-manager libs can not be installed, and 

# thus to just ignore build-deps).

ifeq ($(shell test -d /usr/include/libnm-glib/ && echo yes),yes)

  CONFIGUREARGS += --enable-nm

endif

Donc, soit on modifie le fichier "debian/control" pour supprimer la dépendance, soit on désactive la vérification lors de la compilation. 

La seconde option est la plus rapide : 

$ time dpkg-buildpackage -rfakeroot -uc -b -d 2>&1 | tee /tmp/dpkg-buildpackage.log

real 6m41.164s

user 4m50.970s

sys 1m32.458s

Après quelques minutes, les packages sont tous chauds dans le dossier parent : 

$ cd ..

$ ls *deb

$ ls *deb

libstrongswan_4.5.2-1.2_i386.deb

strongswan-ikev1_4.5.2-1.2_i386.deb  

strongswan-starter_4.5.2-1.2_i386.deb

strongswan_4.5.2-1.2_all.deb       

strongswan-ikev2_4.5.2-1.2_i386.deb

strongswan-dbg_4.5.2-1.2_i386.deb  

strongswan-nm_4.5.2-1.2_i386.deb

Bien sûr, il est recommandé de laisser une trace des modifications effectuées dans les packages. Au minimum, on peut utiliser les options de dpkg-buildpackage
       -vversion
       -Cdescription-des-changements
       -madresse-du-responsable
       -eadresse-du-responsable
              Passé tel quel à dpkg-genchanges. Voir sa page de manuel.

Installation de StrongSwan 

$ sudo dpkg -i *deb

L'installation de StrongSwan est terminée. On va pouvoir passer à la phase de configuration.

La suite dans le prochain billet.

Premiers pas avec Git

Dans le monde du libre, qui peux passer à coté de Git, le gestionnaire de version logicielle créé par Linus Torvalds himself.

On trouvera sur le web moultes documentations, how-to et tutoriels. Mais un commentaire sur LinuxFR m'a permis de découvrir deux vidéos d'une présentation de Sébastien Douche particulièrement efficaces et agréables à suivre :

- la théorie : http://www.parleys.com/#st=5&id=2366

- un peu de pratique : http://www.parleys.com/#st=5&id=2368

Si les vidéos vous ont plu, sachez que Sebastien Douche sera présent à Bordeaux pour animera une soirée Git et un atelier les 24 et 25 novembre 2011.

Plus d'info chez BordeauxJUG.