Stockage, iSCSI, Multipath et Linux

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.

 

 

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.

Ajouter un rétrolien

URL de rétrolien : https://www.aplu.fr/v2/trackback/87

Haut de page