Dans le cadre de l’administration système à l’April, nous utilisons, sous l’impulsion de Loïc Dachary, OpenStack. Pour ceux qui ne le savent pas encore, OpenStack est une pile logicielle permettant d’offrir de l’informatique dans les nuages et plus précisément des machines virtuelles réparties sur un cluster de machines. L’architecture est constituée d’un contrôleur et de deux grands sous ensembles :

  • d’une part nova-compute, en charge des machines virtuelles au sens du processeur/ram ;
  • d’autre part nova-volume (dans la version Essex ; remplacé par Cinder à partir de la version Folsom), en charge des disques virtuels.

Il est assez évident, pour différentes raisons que les deux sous ensembles ne sont pas nécessairement situées sur les mêmes machines physiques et il faut donc un moyen pour OpenStack d’exporter un disque du serveur de disque (nova-volume) vers le serveur de calcul (nova-compute). Je limite ici volontairement à un unique serveur de disque et un unique serveur de calcul, mais on peut imaginer d’autres configuration. La technologie choisie est d’utiliser iSCSI pour exporter un disque iSCSI. On retrouve dans cette technologie les concepts présents dans SCSI de target et de LUN. Comme le nuage OpenStack de l’April n’utilise que du logiciel libre, les outils choisis sont iscsitarget du côté du serveur de disque et open-iscsi du côté du client iSCSI, c’est à dire nova-compute. Dans le jargon iSCSI, la partie serveur se nomme target, car c’est elle qui correspond à la cible SCSI et la partie client se nomme initiatior, car c’est elle qui va initier la connexion vers la cible iSCSI.

L’utilisation d’une couche d’abstraction permet une utilisation confortable d’un système complexe. Néanmoins, il me paraît dangereux, terme de liberté, d’utiliser une abstraction sans comprendre les concepts sous-jacents. C’est pourquoi il est utile de réaliser une première fois les manipulations sans utiliser la couche d’abstraction. Autant, il était relativement évident pour moi d’utiliser kvm en ligne de commande, autant iSCSI était une grande découverte. Et c’est là que le bât a blessé. Lors du processus de migration d’une machine physique de l’April vers une instance OpenStack„ nous avons eu un gros souci avec l’export d’un volume par iSCSI. Notre méconnaissance du sujet, en particulier de monter des tests manuellement (hors l’abstraction OpenStack), nous a fortement pénalisés dans notre compréhension du problème. En effet, il est compliqué de chercher une cause au hasard dans des journaux assez touffus comme le sont ceux d’OpenStack.

La solution est venue de deux pages du wiki de Debian, qui sont documentés sur la tâche #1034 de notre outil de suivi. Je vous livre ici la substantifique moelle :

Pour faire fonctionner tout ça «à la main» :

root@volume-server:# ietadm --op new --tid=1 --params Name=iqn.foo.bar:test1
root@volume-server:# ietadm --op show --tid=1
root@compute-client:# iscsiadm -m discovery -t st -p volume-server
root@volume-server:# ietadm --op new --tid=1 --lun=0 --params Path=/dev/vg/volume-0000003f,Type=fileio
root@compute-client:# iscsiadm -m node --targetname iqn.foo.bar:test1 --portal "volume-server:3260" --login

dmesg devrait renvoyer :

[14231392.707306] scsi16 : iSCSI Initiator over TCP/IP
[14231392.961274] scsi 16:0:0:0: Direct-Access     IET      VIRTUAL-DISK     0    PQ: 0 ANSI: 4
[14231392.961515] sd 16:0:0:0: Attached scsi generic sg6 type 0
[14231392.962253] sd 16:0:0:0: [sde] 314572800 512-byte logical blocks: (161 GB/150 GiB)
[14231392.962353] sd 16:0:0:0: [sde] Write Protect is off
[14231392.962358] sd 16:0:0:0: [sde] Mode Sense: 77 00 00 08
[14231392.962555] sd 16:0:0:0: [sde] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[14231392.976618]  sde: sde1
[14231392.977641] sd 16:0:0:0: [sde] Attached SCSI disk
root@compute-client:# iscsiadm  -m node --targetname iqn.foo.bar:test1 --portal "volume-server:3260" --logout  
root@volume-server:# ietadm --op delete --tid=1 --lun=0 
root@volume-server:# ietadm --op delete --tid=1 

Une fois que la manipulation a été faite une fois, on sait enfin quoi chercher dans les journaux de nova/OpenStack et trouver les coupables.

Suite au prochain épisode.