AIX: migration de SDD vers SDDPCM

Ces drivers sont utilisés pour gérer les LUN des baies ESS et DS8000. Le principal avantage que je vois à migrer de SDD vers SDDPCM outre le comfort d'administration est la possibilité d'effectuer des boot on SAN avec gestion de chemin d'accès multiple.

présentation de SDD

Le driver SDD est le driver historique pour la gestion des disques des baies ESS et DS6000/DS8000.
Lorsqu'AIX effectue sa détection de disque, un hdisk est créé pour chaque chemin d'accès au LUN. Lorsque le driver SDD est utilisé, un pseudo disque nommé vpath est créé par dessus pour gérer ces différents chemins d'accès.

La commande permettant d’accéder à la gestion des chemins d’accès au pseudo disque se nomme datapath.
Voici un exemple avec la définition du vpath0 sur un serveur :

# datapath query device 0

DEV#: 0 DEVICE NAME: vpath0 TYPE: 2107900 POLICY: Optimized
SERIAL: 77777770309
==========================================================================
Path# Adapter/Hard Disk State Mode Select Errors
0 fscsi0/hdisk2 OPEN NORMAL 173866154 0
1 fscsi1/hdisk6 OPEN NORMAL 172989784 0
On voit que le pseudo disque vpath0 permet d’accéder au LUN 0309(les 4 derniers caractères du numéro de série du disque) en passant par hdisk2 à travers la carte fibre fcs0 et hdisk6 à travers la carte fibre fcs1.
La politique de gestion des chemins est “Optimized” ce qui correspond à un load balancing amélioré pour prendre en compte le type de baie.
La règle d’administration est de travailler uniquement avec les pseudo disques. On peut travailler directement sur un hdisk mais on ne dispose alors pas de redondance ou de load balancing. C’est donc vivement déconseillé.

présentation de SDDPCM

SDDPCM est un driver développé pour utiliser la couche MPIO d’AIX et l’optimiser pour les baies ESS et DS. La couche MPIO d’AIX permet à l’OS de détecter qu’il accède par plusieurs chemins d'accès différents au même LUN.
La commande fournit avec les drivers sddpcm pour gérer les chemins d'accès se nomme pcmpath. Les commandes AIX standard comme lspath et chpath fonctionnent aussi.
Voici un exemple qui montre les chemins d’accès d’un volume hdisk2 :
# pcmpath query device 2
DEV#: 2 DEVICE NAME: hdisk2 TYPE: 2107900 ALGORITHM: Load Balance
SERIAL: 77777770200
==========================================================================
Path# Adapter/Path Name State Mode Select Errors
0 fscsi1/path0 OPEN NORMAL 983763 0
1 fscsi2/path1 OPEN NORMAL 986323 0
2 fscsi3/path2 OPEN NORMAL 984349 0
3 fscsi4/path3 OPEN NORMAL 985177 0
Il est aussi possible de liste les chemins d’accès à un disque avec la commande standard lspath
# lspath
Enabled hdisk2 fscsi1
Enabled hdisk2 fscsi2
Enabled hdisk2 fscsi3
Enabled hdisk2 fscsi4
Cette fois-ci on ne voit plus qu’un seul hdisk mais disposant de plusieurs chemin d’accès. Dans ce cas, un chemin par carte fibre.

Avantages de SDDPCM par rapport à SDD

  • Administration simplifiée. Il y a une correspondance un pour un entre les LUNs des baies et les hdisk. Cela rend l'analyse de l'activité disque plus facile.

  • Driver légèrement plus performant. Le fait que la gestion des chemins d’accès soit directement intégré dans le kernel est plus performante en théorie. En pratique, je n’ai jamais remarqué de différence notable.
  • SDDPCM supporte le multipathing en boot on SAN. SDD n’est pas supporté en boot on san avec gestion de chemin d’accès multiple.
Je ne connais pas de désavantage spécifique à l'utilisation de SDDPCM par rapport à SDD.

Désinstallation de SDD

Il est tout d’abord nécessaire de supprimer tout les disques configurés avec SDD.
La procédure consiste à :

  • Démonter les filesystems des volume groups contenant des vpath

    for i in $(lsvgfs vpathvg)
    do
    umount $i
    done
    Si des filesystems n’ont pas pu être démonter, vérifier avec les commandes fuser ou lsof(s’il est installé) s’il y a des processus qui rendent le démontage impossible. Il peut aussi y avoir des montages NFS ou des filesystems dont les points de montage se chevauchent.

  • Faire un vary off du volume group
    varyoffvg vpathvg 

  • Récupérer la liste des pvid et exporter le volume group
    lspv > /tmp/liste_pv_[date].txt 
    exportvg varyoffvg

  • Reproduire les étapes précédentes pour chaque volume group utilisant des vpaths.

  • Stopper le service sddsrv
    stopsrc -s sddsrv
  • Supprimer les vpaths
    rmdev -Rdl dpo 
  • Supprimer les disques détectés sur chaque fibre
    rmdev -Rdl fcsX 
  • Vérifier qu’il n’y a plus d’entrées listant des disques de la baie ou des vpath
    lsdev -Cc disk
  • Une fois ces étapes réalisées, il reste à supprimer les anciens drivers (ici pour un AIX 5.3)
    installp -u  devices.sdd.53.rte devices.fcp.disk.ibm.rte 
  • Dans le cas des baies ESS, il faut retirer les drivers suivants
    installp -u  ibm2105.rte devices.fcp.disk.ibm2105.rte

Installation de SDDPCM

Récupérer le driver Host Attachment for SDDPCM on AIX sur la page du driver sur le site IBM

Récupérer le driver Subsystem Device Driver Path Control Module (SDDPCM) sur cette page

ATTENTION : le package SDDPCM est dépendant de la version d’AIX
Voici le nom des deux packages a installé :

  • devices.fcp.disk.ibm.mpio.rte : host attachment
  • devices.sddpcm.52.rte ou devices.sddpcm.53.rte : SDDPCM
Télécharger les fichiers sur le serveur a configurer.
Dans le répertoire où se trouve les packages, création de la TOC
inutoc .
Installation des packages
installp -acXd . devices.fcp.disk.ibm.mpio.rte devices.sddpcm.52.rte
Il est conseillé de redémarrer le système après l’installation du driver.
Une fois le serveur redémarré, il suffit de ré-importer les volumes group en se basant sur le fichier /tmp/liste_pv_[date].txt
importvg -y nomvg hdisk3

boot on SAN

Pour démarrer une partition en boot sur SAN, il est nécessaire de vérifier le niveau de firmware des cartes fibres et si elles sont bien supportés sur le site IBM
La méthode la plus propre pour passer en boot sur SAN est d’utiliser la commande alt_disk_copy pour cloner le rootvg sur un disque de la baie.
Il faut allouer un disque de la baie ayant une taille suffisante pour accueillir rootvg.
Une fois un disque ayant une taille suffisante pour pouvoir contenir le rootvg définit, il suffit ensuite de lancer la copie (dans l’exemple ci-dessous le disque de la baie est connue comme hdisk2)
alt_disk_copy -d hdisk2
Il faut ensuite vérifier la bootlist, elle doit correspondre à une sortie de ce type :
 # bootlist -m normal -o
hdisk2 blv=hd5
hdisk2 blv=hd5
Il suffit ensuite de lancer un reboot du serveur (le mieux est d’ouvrir une console pour suivre la séance de boot)
shutdown -Fr