Ou comment faire tomber tout ce beau monde en marche, assez simplement 
De quoi parle-t-on ?
iSCSI
iSCSI c’est un protocole pour accéder à un disque, un morceau de disque, bref à un espace de stockage à travers le réseau (via des adresses IP).
Dit autrement, vous avez une machine avec plein de disques d’un côté du réseau, et une machine avec une (ou plusieurs) cartes réseau et vous souhaitez accéder à vos disques directement via le réseau ? C’est ce que permet de faire iSCSI.
Multipath
Le multipath, comme le nom peut le laisser entendre, c’est permettre d’accéder à la même chose par plusieurs chemins.
Appliqué au stockage, ça veut dire qu’on va accéder sur la même ressource de stockage via plusieurs liens, ce qui permet d’avoir de la redondance en cas de perte, et éventuellement, une répartition de charge. Ça peut être vu de manière équivalente à ce qui avait décrit dans ce billet, sur le bonding réseau.
Mise en pratique
Ici, je ne vais pas expliquer comment partager la ressource de stockage. Plusieurs raisons :
- On utilise en général des technologies de stockage différentes les unes des autres, et chacune a ses propres manières de faire la partie « serveur » (target) ;
- La ressource de stockage peut être via Ceph/RDB, une baie dédiée (type Dell, IBM, EMC²), du VSAN VMware, une grappe raid… ou un simple disque dur.
En termes de stockage, lorsqu’on partage un espace qui sera vu comme un disque, on appelle ça un LUN (Logical Unit Number), on doit donc définir sur l’équipement qui fait le stockage que le LUN numéro xyz sera publié pour le serveur Charlie. Pour ça, on présente le LUN dans un target et ce target au serveur. Il peut y avoir plusieurs LUN dans le même target et, à ma connaissance, un LUN ne peut pas être dans plusieurs targets.
Puisque l’on souhaite mettre du multipath ensuite, on doit donc s’assurer que le target sera joignable par plusieurs addresses IP (qui seront potentiellement sur des équipements réseau différents le long du chemin, sinon on se retrouve avec un SPoF qu’on va chercher à éviter).
Une fois le LUN « publié » depuis notre serveur Linux, on va pouvoir attacher ce volume au serveur.
Sur CentOS/RedHat, il faut installer le paquet iscsi-initiator-utils ; pour Debian/Ubuntu, il faut installer open-iscsi.
Dans les deux cas, on se retrouve avec une commande : iscsiadm.
iscsiadmin
Avant de commencer, on va (re)définir quelques valeurs par défaut qui sont plus adaptées pour la suite.
Ces réglages se font dans le fichier /etc/iscsi/iscsid.conf
Il y a quelques variables qui peuvent être définies, elles permettent d’avoir des mots de passe et du chiffrement, ce n’est pas obligatoire mais fortement recommandé.
node.session.auth.authmethod = CHAP node.session.auth.username = username node.session.auth.password = password! discovery.sendtargets.auth.authmethod = CHAP discovery.sendtargets.auth.username = username discovery.sendtargets.auth.password = password!
Cette valeur doit être modifiée, elle définit au bout de combien de secondes une session iSCSI qui n’est plus valable (par exemple le chemin réseau est KO) l’erreur sera remontée au-dessus. Vu autrement, au bout de combien de secondes, en cas de perte, on aura des erreurs et le LUN sera vu comme hors ligne, comme nous allons mettre du multipath ensuite, il est préférable d’avoir cette valeur à 0.
node.session.timeo.replacement_timeout = 0
Une fois les options modifiées, lancez ou relancez le service iscsid.
Une fois ces réglages faits, avec la commande iscsiadm on va demander à la partie stockage, d’envoyer la liste des « targets » auquels le serveur a accès.
# iscsiadm -m discovery -t sendtargets -p 10.10.199.4 10.10.199.4:3260,2 iqn.1998-01.com.foo:4beb2e86-9c13-45f7-be3d-5eb96b7b62a6
On répète la même commande pour toutes les IP où notre LUN est joignable.
Une fois l’ensemble des discovery réalisés, la commande suivante permet de passer en ligne tous les LUNs.
# iscsiadm -m node -L all
Si vous faites la commande lsblk -pS vous devriez voir plusieurs nouveaux disques (ici de sdb à sdm, je vous laisse deviner la solution de stockage utilisée :)).
# lsblk -pS NAME HCTL TYPE VENDOR MODEL REV TRAN /dev/sda 0:0:0:0 disk VMware Virtual disk 2.0 /dev/sdb 8:0:0:0 disk VMware Virtual SAN 0001 iscsi /dev/sdc 3:0:0:0 disk VMware Virtual SAN 0001 iscsi /dev/sdd 9:0:0:0 disk VMware Virtual SAN 0001 iscsi /dev/sde 10:0:0:0 disk VMware Virtual SAN 0001 iscsi /dev/sdf 8:0:0:1 disk VMware Virtual SAN 0001 iscsi /dev/sdg 3:0:0:1 disk VMware Virtual SAN 0001 iscsi /dev/sdh 9:0:0:1 disk VMware Virtual SAN 0001 iscsi /dev/sdi 10:0:0:1 disk VMware Virtual SAN 0001 iscsi /dev/sdj 8:0:0:2 disk VMware Virtual SAN 0001 iscsi /dev/sdk 3:0:0:2 disk VMware Virtual SAN 0001 iscsi /dev/sdl 9:0:0:2 disk VMware Virtual SAN 0001 iscsi /dev/sdm 10:0:0:2 disk VMware Virtual SAN 0001 iscsi
Le multipath
Pour configurer le multipath, ça va être relativement plus simple à faire. Sous CentOS/RHEL, il faut installer le paquet device-mapper-multipath et sous Debian/Ubuntu : multipath-tools.
Ensuite, il suffit de créer le fichier /etc/multipath.conf avec le contenu suivant :
defaults {
user_friendly_names yes
find_multipaths yes
features "1 queue_if_no_path"
path_grouping_policy failover
no_path_retry 100
}
Une relance du service multipathd suffit en général pour prendre en compte les modifs.
Il est possible d’être plus specifique dans le fichier de configuration mais dans le cas présent, ces options suffisent pour nos besoins.
Une fois fait, la commande multipath -l permet de lister les différents agrégats de disque réalisés :
# multipath -l mpathd (1VMware_VITDEVIDc7593159e1fd795a1d02901b0eafc51b) dm-4 VMware ,Virtual SAN size=400G features='1 queue_if_no_path' hwhandler='0' wp=rw |-+- policy='service-time 0' prio=0 status=enabled | `- 8:0:0:2 sdj 8:144 active undef running |-+- policy='service-time 0' prio=0 status=enabled | `- 9:0:0:2 sdl 8:176 active undef running |-+- policy='service-time 0' prio=0 status=active | `- 3:0:0:2 sdk 8:160 active undef running `-+- policy='service-time 0' prio=0 status=enabled `- 10:0:0:2 sdm 8:192 active undef running mpathc (1VMware_VITDEVIDa05931591221cbf9f449901b0eafc615) dm-3 VMware ,Virtual SAN size=200G features='1 queue_if_no_path' hwhandler='0' wp=rw |-+- policy='service-time 0' prio=0 status=enabled | `- 8:0:0:1 sdf 8:80 active undef running |-+- policy='service-time 0' prio=0 status=active | `- 3:0:0:1 sdg 8:96 active undef running |-+- policy='service-time 0' prio=0 status=enabled | `- 9:0:0:1 sdh 8:112 active undef running `-+- policy='service-time 0' prio=0 status=enabled `- 10:0:0:1 sdi 8:128 active undef running mpatha (1VMware_VITDEVID3dc72e59d49bb331d68b901b0eafc615) dm-2 VMware ,Virtual SAN size=100G features='1 queue_if_no_path' hwhandler='0' wp=rw |-+- policy='service-time 0' prio=0 status=enabled | `- 3:0:0:0 sdc 8:32 active undef running |-+- policy='service-time 0' prio=0 status=enabled | `- 8:0:0:0 sdb 8:16 active undef running |-+- policy='service-time 0' prio=0 status=active | `- 9:0:0:0 sdd 8:48 active undef running `-+- policy='service-time 0' prio=0 status=enabled `- 10:0:0:0 sde 8:64 active undef running
Ici, on se retrouve avec 3 disques, mpathd, mpathc, et mpatha qui sont joignables par 4 chemins différents.
Pour l’usage ensuite, on accèdera non plus à sdX mais à mpathX, ainsi l’abstraction multipath permet de garantir l’accès au stockage.