Cluster na Linuxu: sdílené úložiště pomocí iSCSI a multipathingu

4. 9. 2017
Doba čtení: 15 minut

Sdílet

V úvodním díle jsme probrali základní pojmy týkající se vysoké dostupnosti na Linuxu a sestrojili úplně jednoduchý cluster. Tentokrát si nakofigurujeme sdílené úložiště pomocí iSCSI a multipathingu.

Proč sdílené úložiště? A proč pomocí multipathingu?

Pokud chceme, aby mohly resources v případě potřeby běžet na všech (obou) nodech, musejí mít nody přístup ke stejným datům. V praxi to znamená, že LUNy, kde jsou data uložena, jsou zónovány na všechny nody clusteru. Logika clusteru už potom zajistí, aby se LUNy používaly jen tím nodem (těmi nody), kde má služba využívající daný LUN běžet, a to pomocí LVM. Podrobněji možnosti konfigurace LVM vysvětlím v jednom z příštích dílů.

V praxi je běžné, že ke každému LUNu na úložišti vede zpravidla více než jedna cesta (path). Proč? Jednoduše proto, že se chceme pojistit pro případ, kdy nám jedna cesta vypadne – je to forma redundance. Pokud data nejsou dostupná jednou cestou, systém si může zvolit jinou. Takový koncept označujeme termínem multipathing. Systémů multipathingu je celá řada: EMC ke svým storage boxům dodává software EMC Powerpath, s Huawei storage boxy také můžete použít jejich multipathing, atd. Pokud nechcete použít software dodávaný výrobcem storage boxu, pokud žádný takový software dodáván není, nebo se jedná o virtuální prostředí (cluster, který stavíme), použijeme multipathing software dostupný ve Fedoře a RHEL.

Jak multipathing funguje? A jak zjistíme, že systém „vidí“ více cest ke stejnému LUNu? Každá cesta k LUNu v blokovém zařízení (diskové pole storage boxu) je v Linuxu reprezentována jednou sd jednotkou (device, existující pod /dev. Tedy /dev/sda, /dev/sdb, /dev/sdc atd. Pokud se abeceda vyčerpá, začíná se znovu přidáním další hlásky – sdaa, sdab, sdac atd.). Každá SCSI device má v Linuxu vlastní SCSI ID. Na Fedoře a RHEL 7 ho zjistíte příkazem:

# /lib/udev/scsi_id --whitelisted --replace-whitespace /dev/sdXX

Co toto SCSI ID označuje? Je to identifikační číslo LUNu nebo disku. Znamená to, že všechny cesty (sd jednotky) k určitému LUNu mají stejné SCSI ID? Přesně tak. Tímto způsobem multipath určuje, které cesty vedou k jakému LUNu. Velice často v produkci vidíme nejen dvě, ale třeba 4 nebo 8 cest ke každému LUNu. Záleží na designu prostředí.

Abychom i my mohli využít výhod multipathingu v našem clusteru na KVM, budeme potřebovat další síťovou kartu. Momentálně máme ve VM pravděpodobně jen jednu síťovku. Pokud přidáme druhou, můžeme exportovat LUNy přes dvě síťovky. Pokud přidáme síťovky dvě, můžeme ponechat tu stávající pro přístupovou IP a ty dvě nové využít pro IP, na kterých budou LUNy exportovány. Samozřejmě bond nebo team poskytne exportní IP redundanci – volba je na vás. Článek bude pracovat s jednoduchou variantou – tři síťovky na iSCSI targetu, z nichž dvě budou mít IP sloužící pro export LUNů a původní bude obsluhovat přístupovou IP. Kdo chce, může si nastavit tyto IP pro export LUNů jako statické a nespoléhat se na DHCP od KVM. V praxi bude rozhodně rozumnější mít tyto IP na teamu/bondu – statické a nejlépe na privátní síti, aby tudy proudila skutečně jen data týkající se storage. V naší ukázce na tom až tolik nesejde. Na obrázku uvidíte virtuální síť kvm-nat. Je to mnou definovaná síť s rozsahem adres 192.168.10.3 až 192.168.10.254, vy si můžete definovat vlastní nebo ponechat na výchozím nastavení KVM, to by mělo fungovat správně.

Implementace sdíleného úložiště

Pro vytvoření sdíleného úložiště použijeme iSCSI. Ve VM f25storage, která bude fungovat jako iSCSI target, vytvoříme VG, jejíž LV budeme exportovat virtuálkám f25a a f25b, neboli iSCSI initiators. Samozřejmě můžeme exportovat celý disk a nikoli LV. Tím se ale připravíme o výhodu flexibility LVM při případném rozšiřování LUNu.

Poznámka na okraj: Fyzické stroje pro připojení úložiště mohou pro iSCSI použít jak běžné síťovky, tak iSCSI karty (ty umožňují navíc i boot z iSCSI), pokud je při návrhu zvolen tento protokol, nebo FC karty, pokud padne volba na protokol Fibre Channel . Protokolů pro připojení úložiště existuje více a každý samozřejmě využívá jiné typy karet.

Přidání disku do VM pro export a vytvoření iSCSI exportu

Do virtuálky f25storage přidáme disk, z něhož vytvoříme PV. Na tomto PV bude VG sloužící pro export.

Ve VM se tento disk ukáže jako sdX , v našem případě jako sda

# lsblk
NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr0              11:0    1 1024M  0 rom
sda               8:0    0   10G  0 disk
vda             252:0    0    5G  0 disk
├─vda2          252:2    0    4G  0 part
│ ├─fedora-swap 253:1    0  512M  0 lvm  [SWAP]
│ └─fedora-root 253:0    0  3.5G  0 lvm  /
└─vda1          252:1    0    1G  0 part /boot

Následuje vytvoření VG (PV bude z disku vytvořeno automaticky). VG pojmenujeme jako exportvg :

# vgcreate exportvg /dev/sda
  Physical volume "/dev/sda" successfully created.
  Volume group "exportvg" successfully created

Ještě vytvoříme LV…

# lvcreate -n cluster1lun1 -L 1G exportvg
  Logical volume "cluster1lun1" created.

… a hurá na iSCSI export! Ten se realizuje přes utilitutargetcli (balík targetcli ). Rozhraní je krásně intuitivní a můžete v něm využít tab-completion. targetcli spustíme stejnojmenným příkazem. Příkazls nám ukáže strukturu:

/> ls
o- / ......................................................................................................................... [...]
  o- backstores .............................................................................................................. [...]
  | o- block .................................................................................................. [Storage Objects: 0]
  | o- fileio ................................................................................................. [Storage Objects: 0]
  | o- pscsi .................................................................................................. [Storage Objects: 0]
  | o- ramdisk ................................................................................................ [Storage Objects: 0]
  o- iscsi ............................................................................................................ [Targets: 0]
  o- loopback ......................................................................................................... [Targets: 0]
  o- vhost ............................................................................................................ [Targets: 0]

Adresářbackstores skrývá možnosti uložení exportovaných LUNů. Nás bude zajímat block , který exportuje bloková zařízení. Stejně tak ale můžete exportovat soubor (fileio ) nebo část operační paměti (ramdisk ). V adresářiiscsi pak budeme definovat jednotlivé exporty.

Definice typu exportovaného úložiště

V /backstores/block  definujeme právě vytvořený LV (není nutné použít stejné jméno pro LV i pro LUN, je to ale více konzistentní):

/> /backstores/block create cluster1lun1 /dev/exportvg/cluster1lun1
Created block storage object cluster1lun1 using /dev/exportvg/cluster1lun1.

Definice iSCSI exportu

V /iscsi  vytvoříme IQN (iSCSI Qualified Name), které bude označovat celý export. Toto IQN má speciální tvar

/> /iscsi create iqn.2017-06.com.example.f25storage:cluster1
Created target iqn.2017-06.com.example.f25storage:cluster1.
Created TPG 1.
Global pref auto_add_default_portal=true
Created default portal listening on all IPs (0.0.0.0), port 3260.

Pokud se podíváme na výpis ls, vidíme jak položku v /backtores, tak i export v  /iscsi.

/> ls
o- / ......................................................................................................................... [...]
  o- backstores .............................................................................................................. [...]
  | o- block .................................................................................................. [Storage Objects: 1]
  | | o- cluster1lun1 ................................................. [/dev/exportvg/cluster1lun1 (1.0GiB) write-thru deactivated]
  | o- fileio ................................................................................................. [Storage Objects: 0]
  | o- pscsi .................................................................................................. [Storage Objects: 0]
  | o- ramdisk ................................................................................................ [Storage Objects: 0]
  o- iscsi ............................................................................................................ [Targets: 1]
  | o- iqn.2017-06.com.example.f25storage:cluster1 ....................................................................... [TPGs: 1]
  |   o- tpg1 ............................................................................................... [no-gen-acls, no-auth]
  |     o- acls .......................................................................................................... [ACLs: 0]
  |     o- luns .......................................................................................................... [LUNs: 0]
  |     o- portals .................................................................................................... [Portals: 1]
  |       o- 0.0.0.0:3260 ..................................................................................................... [OK]
  o- loopback ......................................................................................................... [Targets: 0]
  o- vhost ............................................................................................................ [Targets: 0]

Každý export iSCSI shlukuje více složek, obsažených v takzvaném target portal group, neboli TPG. targetcli je inteligentní, a protože TPG je součástí každého iSCSI exportu, vytvoří TPG za nás. („ Created TPG 1. “). Jednotlivé složky TPG vidíme na výpisu výše:

  1. acls: ACL oddělené pro každého jednotlivého iSCSI klienta
  2. luns: Sezman LUNů, které exportujeme tímto exportem. Jsou to ty, které jsme dříve definovali v /backstores/  a po úspěšném přihlášení klientů budou všechny tyto LUNy viditelné na klientech.
  3. portals: Seznam portálů neboli cest, kudy budou LUNy v tomto exportu exportovány. Pokud definujeme více než jeden portál (více než jednu cestu), klienti budou mít k dispozici více cest (paths) ke každému exportovanému LUNu, což se dá využít k multipathingu.

Definujeme ACL pro každý node zvlášť:

/iscsi/iqn.20...cluster1/tpg1> acls/ create iqn.2017-06.com.example.f25storage:node1
Created Node ACL for iqn.2017-06.com.example.f25storage:node1
/iscsi/iqn.20...cluster1/tpg1> acls/ create iqn.2017-06.com.example.f25storage:node2
Created Node ACL for iqn.2017-06.com.example.f25storage:node2

/iscsi/iqn.20...cluster1/tpg1> ls
o- tpg1 ..................................................................................................... [no-gen-acls, no-auth]
  o- acls ................................................................................................................ [ACLs: 2]
  | o- iqn.2017-06.com.example.f25storage:node1 ................................................................... [Mapped LUNs: 0]
  | o- iqn.2017-06.com.example.f25storage:node2 ................................................................... [Mapped LUNs: 0]
  o- luns ................................................................................................................ [LUNs: 0]
  o- portals .......................................................................................................... [Portals: 1]
    o- 0.0.0.0:3260 ........................................................................................................... [OK]
/iscsi/iqn.20...cluster1/tpg1>

Přiřadíme tomuto TPG LUN(y), který se má (které se mají) tímto TPG exportovat:

/iscsi/iqn.20...cluster1/tpg1> luns/ create /backstores/block/cluster1lun1 1
Created LUN 1.
Created LUN 1->1 mapping in node ACL iqn.2017-06.com.example.f25storage:node2
Created LUN 1->1 mapping in node ACL iqn.2017-06.com.example.f25storage:node1
/iscsi/iqn.20...cluster1/tpg1>

/iscsi/iqn.20...cluster1/tpg1> ls
o- tpg1 ..................................................................................................... [no-gen-acls, no-auth]
  o- acls ................................................................................................................ [ACLs: 2]
  | o- iqn.2017-06.com.example.f25storage:node1 ................................................................... [Mapped LUNs: 1]
  | | o- mapped_lun1 ................................................................................ [lun1 block/cluster1lun1 (rw)]
  | o- iqn.2017-06.com.example.f25storage:node2 ................................................................... [Mapped LUNs: 1]
  |   o- mapped_lun1 ................................................................................ [lun1 block/cluster1lun1 (rw)]
  o- luns ................................................................................................................ [LUNs: 1]
  | o- lun1 ...................................................................... [block/cluster1lun1 (/dev/exportvg/cluster1lun1)]
  o- portals .......................................................................................................... [Portals: 1]
    o- 0.0.0.0:3260 ........................................................................................................... [OK]
/iscsi/iqn.20...cluster1/tpg1>

Všimněte si, že targetcli rovnou namapoval přidaný LUN do obou ACL.

Teď nakonfigurujeme více cest k LUNu, a to pomocí položky v portals. Bez jakěkoliv modifikace v této sekci bude targetcli exportovat LUNy přes všechny IP, které jsou v systému dostupné. My ale budeme chtít omezit export jen na IP, které jsme si k tomu určili – budou to ty, které jsou přiřazeny k síťovkám vytvořeným výše. V mém případě se jedná o tyto (použil jsem DHCP KVM, takže vaše IP se určitě budou lišit):

[root@f25storage ~]# ip link
[...]
3: ens4: <broadcast,multicast,up,lower_up> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:64:b4:ea brd ff:ff:ff:ff:ff:ff
4: ens10: broadcast,multicast,up,lower_up> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:eb:fb brd ff:ff:ff:ff:ff:ff
[root@f25storage ~]#

[root@f25storage ~]# ip a
[...]
3: ens4: <broadcast,multicast,up,lower_up> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:64:b4:ea brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.227/24 brd 192.168.10.255 scope global dynamic ens4
       valid_lft 2525sec preferred_lft 2525sec
    inet6 fe80::f1fe:fcd4:fdbc:a48b/64 scope link
       valid_lft forever preferred_lft forever
4: ens10: <broadcast,multicast,up,lower_up> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:12:eb:fb brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.179/24 brd 192.168.10.255 scope global dynamic ens10
       valid_lft 2730sec preferred_lft 2730sec
    inet6 fe80::de2c:3b66:ed40:32c4/64 scope link
       valid_lft forever preferred_lft forever
[root@f25storage ~]#

targetcli – vymazání výchozího portálu a vytvoření dvou nových, námi určených; opuštění targetcli. Díky výchozímu nastavení auto_save_on_exit s hodnotou true targetcli při ukončení naše nastavení uloží:

/iscsi/iqn.20...cluster1/tpg1> portals/ delete 0.0.0.0 3260
Deleted network portal 0.0.0.0:3260

/iscsi/iqn.20...cluster1/tpg1> portals/ create 192.168.10.227
Using default IP port 3260
Created network portal 192.168.10.227:3260.
/iscsi/iqn.20...cluster1/tpg1> portals/ create 192.168.10.179
Using default IP port 3260
Created network portal 192.168.10.179:3260.

/iscsi/iqn.20...cluster1/tpg1> ls
o- tpg1 ..................................................................................................... [no-gen-acls, no-auth]
  o- acls ................................................................................................................ [ACLs: 2]
  | o- iqn.2017-06.com.example.f25storage:node1 ................................................................... [Mapped LUNs: 1]
  | | o- mapped_lun1 ................................................................................ [lun1 block/cluster1lun1 (rw)]
  | o- iqn.2017-06.com.example.f25storage:node2 ................................................................... [Mapped LUNs: 1]
  |   o- mapped_lun1 ................................................................................ [lun1 block/cluster1lun1 (rw)]
  o- luns ................................................................................................................ [LUNs: 1]
  | o- lun1 ...................................................................... [block/cluster1lun1 (/dev/exportvg/cluster1lun1)]
  o- portals .......................................................................................................... [Portals: 2]
    o- 192.168.10.179:3260 .................................................................................................... [OK]
    o- 192.168.10.227:3260 .................................................................................................... [OK]

/iscsi/iqn.20...cluster1/tpg1> exit
Global pref auto_save_on_exit=true
Last 10 configs saved in /etc/target/backup.
Configuration saved to /etc/target/saveconfig.json

Je dobré zdůraznit, že targetcli ukládá deset záloh konfiguračních souborů do /etc/target/backup. Pokud se tedy vaše nastavení z jakéhokoli důvodu smaže, většinou není problém najít poslední vhodnou konfiguraci, nahradit soubor /etc/target/saveconfig.json některým z /etc/target/backup  a restartovat target ( systemctl restart target).

Nezapomeňme na povolení komunikace na iSCSI portu ve firewallu a spuštění služby během startu systému. iSCSI využívá port 3260/tcp. Parametr --permanent příkazu firewall-cmd uloží nastavení trvale, ale pro okamžitou platnost nového nastavení je potřeba uložit ho i do runtime konfigurace (stejný příkaz bez --permanent) nebo znovu načíst firewall pomocí  --reload:

[root@f25storage ~]# firewall-cmd --permanent --add-port=3260/tcp
success
[root@f25storage ~]# firewall-cmd --reload
success
[root@f25storage ~]# systemctl enable target
Created symlink /etc/systemd/system/multi-user.target.wants/target.service → /usr/lib/systemd/system/target.service.

V této chvíli už by měl být iSCSI target připravený pro export. Budeme mít dvě cesty přes dvě IP, přičemž úložistě (backing storage) bude LV. Pokud na LUNu dojde místo, bude tedy možné poměrně jednoduše dostupné místo zvětšit rozšířením LV. To si ukážeme v jednom z příštích dílů.

Konfigurace iSCSI klientů

iSCSI klienti (initiators) se potřebují připojit k targetu pomocí příkazu iscsiadm, který je poskytován balíkem iscsi-initiator-utils. Je důležité, aby v systému existovala IP ve stejné síti, kde jsou IP pro export LUNů. Znovu je výhodné mít redundanci na IP, přes kterou se k targetu připojujeme. Pokud nepoužíváme autentifikaci, je procedura přihlášení k targetu poměrně snadná:

1. Změnit hodnotu InitiatorName v /etc/iscsi/initiatorname.iscsi  na tu, která figuruje v acl  definice iSCSI exportu. Příklad: na node1 tedy tato hodnota bude  iqn.2017-06.com.example.f25storage:node1

2. Nastartovat iscsid a iscsi systemd služby a povolit jejich spuštění při startu systému.

[root@f25a ~]# systemctl start iscsid ; systemctl start iscsi
[root@f25a ~]# systemctl enable iscsid ; systemctl enable iscsi
Created symlink /etc/systemd/system/multi-user.target.wants/iscsid.service → /usr/lib/systemd/system/iscsid.service.

[root@f25b ~]# systemctl start iscsid ; systemctl start iscsi
[root@f25b ~]# systemctl enable iscsid ; systemctl enable iscsi
Created symlink /etc/systemd/system/multi-user.target.wants/iscsid.service → /usr/lib/systemd/system/iscsid.service.

3. Provést discovery LUNů na exportní IP. Pokud se nezobrazí obě cesty na jedně z nich, proveďte stejnou operaci na obou exportních IP. Zobrazí se nejen LUNy, které jsou namapovány v acl  pro tento initiator, ale i LUNy z ostatních iSCSI exportů, pokud jsou definovány.

[root@f25a ~]#  iscsiadm --mode discoverydb --type sendtargets --portal 192.168.10.179:3260 --discover
192.168.10.179:3260,1 iqn.2017-06.com.example.f25storage:cluster1
192.168.10.227:3260,1 iqn.2017-06.com.example.f25storage:cluster1
[root@f25a ~]#
[root@f25b ~]# iscsiadm --mode discoverydb --type sendtargets --portal 192.168.10.179:3260 --discover
192.168.10.179:3260,1 iqn.2017-06.com.example.f25storage:cluster1
192.168.10.227:3260,1 iqn.2017-06.com.example.f25storage:cluster1
[root@f25b ~]#

4. Provést login do acl na dané exportní IP (celkem tedy dva loginy pro každou exportní IP)

[root@f25a ~]#  iscsiadm --mode node --targetname iqn.2017-06.com.example.f25storage:cluster1 --portal 192.168.10.179:3260 --login
Logging in to [iface: default, target: iqn.2017-06.com.example.f25storage:cluster1, portal: 192.168.10.179,3260] (multiple)
Login to [iface: default, target: iqn.2017-06.com.example.f25storage:cluster1, portal: 192.168.10.179,3260] successful.

[root@f25a ~]#  iscsiadm --mode node --targetname iqn.2017-06.com.example.f25storage:cluster1 --portal 192.168.10.227:3260 --login
Logging in to [iface: default, target: iqn.2017-06.com.example.f25storage:cluster1, portal: 192.168.10.227,3260] (multiple)
Login to [iface: default, target: iqn.2017-06.com.example.f25storage:cluster1, portal: 192.168.10.227,3260] successful.
[root@f25a ~]#
[root@f25b ~]# iscsiadm --mode node --targetname iqn.2017-06.com.example.f25storage:cluster1 --portal 192.168.10.179:3260 --login
Logging in to [iface: default, target: iqn.2017-06.com.example.f25storage:cluster1, portal: 192.168.10.179,3260] (multiple)
Login to [iface: default, target: iqn.2017-06.com.example.f25storage:cluster1, portal: 192.168.10.179,3260] successful.
[root@f25b ~]#

[root@f25b ~]# iscsiadm --mode node --targetname iqn.2017-06.com.example.f25storage:cluster1 --portal 192.168.10.227:3260 --login
Logging in to [iface: default, target: iqn.2017-06.com.example.f25storage:cluster1, portal: 192.168.10.227,3260] (multiple)
Login to [iface: default, target: iqn.2017-06.com.example.f25storage:cluster1, portal: 192.168.10.227,3260] successful.
[root@f25b ~]#

5. Můžete si zkontrolovat, jaké blokové jednotky jsou v systému viditelné. Měli byste vidět dvě sd jednotky navíc – každá z nich přibyla po jednom iSCSI loginu. Jsou to tedy cesty k témuž LUNu.

[root@f25b ~]# lsblk -s
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdb           8:16   0    1G  0 disk
sr0          11:0    1 1024M  0 rom
fedora-root 253:0    0  4.5G  0 lvm  /
└─vda2      252:2    0  4.5G  0 part
  └─vda     252:0    0    5G  0 disk
sda           8:0    0    1G  0 disk 
vda1        252:1    0  512M  0 part /boot
└─vda       252:0    0    5G  0 disk

Malý trik: iscsiadm příkazy pravděpodobně nebudete sypat jen tak z rukávu, parametry se nepamatují lehce. Pomůže vám man iscsiadm. Kromě detailních vysvětlivek najdete, úplně na konci manuálu, příklady použití. Rozhodně doporučuji manuál si pročíst.

Pokud se selinuxem zapnutým na enforcing nevidíte po rebootu nodu exportovaný LUN (pravděpodobně sda a sdb), zkontrolujte v logu journalctl, jestli vidíte hlášku „ iscsid[PID]: Could not insert module tcp. Kmod error -13 “. Pokud ano, problém můžete obejít nastavením selinuxu na permissive v /etc/selinux/config. Pravé řešení se mi najít nepodařilo.

A co ten multipath?

Když už máme obě cesty k úložišti, nainstalujme a nakonfigurujme si na obou nodech multipath. Balík, který potřebujeme, je device-mapper-multipath. Po instalaci spustíme příkaz mpathconf, který provede nastavení multipath. Potom démona multipathd nastartujeme, povolíme start démona při bootu a nakonec se podíváme, jestli se nám namapovaný LUN zobrazí dvěma cestami.

[root@f25a ~]# mpathconf --enable --find_multipaths y --with_multipathd y

[root@f25a ~]# systemctl start multipathd ; systemctl enable multipathd
Created symlink /etc/systemd/system/sysinit.target.wants/multipathd.service → /usr/lib/systemd/system/multipathd.service.

[root@f25a ~]# multipath -ll
mpatha (36001405b2ca0e79775f4ef3bf59803e8) dm-1 LIO-ORG ,cluster1lun1
size=1.0G features='0' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=1 status=active
| `- 3:0:0:1 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=1 status=enabled
  `- 2:0:0:1 sda 8:0  active ready running


[root@f25a ~]# lsblk -s
NAME        MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
mpatha      253:1    0    1G  0 mpath
├─sdb         8:16   0    1G  0 disk
└─sda         8:0    0    1G  0 disk 
sr0          11:0    1 1024M  0 rom
fedora-root 253:0    0  4.5G  0 lvm   /
└─vda2      252:2    0  4.5G  0 part
  └─vda     252:0    0    5G  0 disk
vda1        252:1    0  512M  0 part  /boot
└─vda       252:0    0    5G  0 disk

[root@f25b ~]# mpathconf --enable --find_multipaths y --with_multipathd y

[root@f25b ~]# systemctl start multipathd ; systemctl enable multipathd
Created symlink /etc/systemd/system/sysinit.target.wants/multipathd.service → /usr/lib/systemd/system/multipathd.service.

[root@f25b ~]# multipath -ll
mpatha (36001405b2ca0e79775f4ef3bf59803e8) dm-1 LIO-ORG ,cluster1lun1
size=1.0G features='0' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=1 status=active
| `- 2:0:0:1 sda 8:0  active ready running
`-+- policy='service-time 0' prio=1 status=enabled
  `- 3:0:0:1 sdb 8:16 active ready running

[root@f25b ~]#  lsblk -s
NAME        MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
mpatha      253:1    0    1G  0 mpath
├─sdb         8:16   0    1G  0 disk
└─sda         8:0    0    1G  0 disk  
sr0          11:0    1 1024M  0 rom
fedora-root 253:0    0  4.5G  0 lvm   /
└─vda2      252:2    0  4.5G  0 part
  └─vda     252:0    0    5G  0 disk
vda1        252:1    0  512M  0 part  /boot
└─vda       252:0    0    5G  0 disk

Aktuální stav a poznámky

Máme nakonfigurovaný iSCSI export a do cluster nodů putuje jeden LUN dvěma cestami, které jsou pod správou multipath. Toto je sdílené úložiště, bez něhož to v clusteru snad ani nejde (pokud nepoužíváme DRBD nebo jiný systém umožňující zápis / čtení dat na dvě odlišná bloková zařízení současně). Otázku sdíleného uložiště bychom mohli vyřešit i NFS exportem připojeným na oba nody. Použití iSCSI bylo čistě pro ukázku. V praxi by podobnou funkci zastaly i jiné protokoly jako FC, FCoE atd. Také celková infrastruktura storage by pravděpodobně vypadala jinak – více cest za pomoci storage switchů a víceportových karet.

bitcoin_skoleni

Pokud bude zájem, mohu multipath a device mapper rozvést do větších podrobností (nikoli na úroveň kódu, ale na úroveň uživatele) v některém z příštích dílů.

Konečně už tedy máme vše potřebné k tomu, abychom si mohli hrát s resources. Protože příprav už bylo hodně, příště bude náš cluster skutečně pracovat – nakonfigurujeme vysoce dostupný web a možná i zprovozníme český PHP framework Nette. Takže po této ryze storage odbočce bude pokračování opět clusterové.

Autor článku

Pracuje na technické podpoře Red Hat a věnuje se skialpu a lezení.