Základní pojmy
Abychom věděli, o čem je řeč, začneme malým slovníkem.
Cluster – seskupení počítačů. Pro účely tohoto průvodce vystačíme s clusterem pro vysokou dostupnost (high-availability cluster).
High availability – vysoká dostupnost. Smysl tohoto řešení je eliminovat situaci, kdy kvůli selhání jednoho stroje přijdeme o veškeré služby, které na něm běží.
Single point of failure – jediný bod vedoucí k selhání.
Člen clusteru/Cluster node – každý jednotlivý operační systém zapojený do clusteru.
Zdroj/Resource/Služba– stavební kostka toho, co chceme poskytovat. Každá jednotlivá aplikace (webserver, ftp server, databázový server, DNS server, NFS server apod.); IP, na které chceme ke službě přistupovat; filesystém, kam chceme ukládat data.
Skupina zdrojů/Skupina služeb/Resource group – většinou potřebujeme, aby vícero služeb běželo najednou. Například httpd bude vyžadovat nějaký filesystém s obsahem, který má obsluhovat. Proto je výhodné přidávat zdroje do skupin (resource group).
Token, heartbeat – označení pro způsob komunikace mezi nody v clusteru. Nody si mezi sebou ve stanoveném intervalu posílají token, aby o ostatních zjistily, zda jsou schopny normálně odpovídat. Pokud ano, node je považován za zdravý.
Quorum – nadpoloviční většina hlasů. Cluster vyhodnocuje, zda nodů korektně odpovídajících na token je dostatek na to, aby resources mohly být spuštěny. Pokud vyhodnotí, že takových nodů je více než polovina z jejich celkového počtu v clusteru, je cluster quorate, má quorum, a službám je povoleno běžet. Výjimkou je samozřejmě dvounodový cluster, kdy potřebujeme, aby na jednom nodu zpravidla běžely všechny služby.
Split-brain – situace vyskytující se ve dvounodovém clusteru, kdy jsou oba nody přesvědčené o tom, že služba (nebo skupina služeb) má bežet právě na něm. Za normálních okolností běží ve vysoce dostupném clusteru služba nebo skupina služeb pouze na jednom z nodů, a to kvůli integritě dat. Předpokládejme, že naše skupina služeb obsahuje MySQL databázi a filesystém, na který budeme data ukládat. Není třeba žádných zkušeností s clusterem, abychom si dokázali představit, že pokud by naše databáze a filesystém běžely na obou strojích a každý z nich by se snažil zapisovat jiné transakce na stejný filesystém, integrita dat by byla tatam. Tento stav může znamenat, že více než jeden node bude modifikovat sdílená data. To je zcela nežádoucí stav, a proto je třeba mít po ruce mechanismus, jak tyto nody z clusteru vyloučit. Takový mechanismus se označuje jako fencing. Zatímco split-brain existuje jen u dvounodových clusterů, ochrana integrity dat fencingem je nutná ve všech clusterech.
Fencing – soubor metod, jak dočasně vyloučit node z clusteru a tím zabránit poškození sdílených dat. Nody v clusteru se neustále domlouvají a komunikují spolu. Posílají si takzvaný token. Za normálních okolností node na token odpoví ve stanovené časové prodlevě – dává ostatním vědět, že je „živý a zdravý“. Pokud se tak ale nestane a ostatní cluster nody odpověď v nastaveném čase nedostanou, pak se nody, které na token odpovídají normálně, domluví, a jeden z nich (konkrétně ten s nejnižším ID), se pokusí „fencnout“, tedy odpojit toho (nebo ty), který (kteří) na token neodpovídá.
Proč je třeba takto zakročit? Chráníme tím data! Ve chvíli, kdy node ztratí token, nemůžeme vědět, v jakém stavu se nachází. Proto ho musíme rázně zastavit dříve, než data přijdou k újmě. Nejčastěji používaným způsobem fencingu je restart systému (reboot), a to ve smyslu tvrdého restartu. Efekt je stejný jako při zmáčknutí tlačítka reset na vašem PC. Je to nejpřímočařejší metoda, jak nodu znemožnit, aby „sahal“ na data. Podobně účinné je kompletní vypnutí (poweroff), to ale samozřejmě vyžaduje manuální intervenci v podobě opětovného zapnutí nodu. Reboot a poweroff jsou základní metody fencingu, a proto, pokud je konfigurován víceúrovňový (multilevel) fencing, figurují jako první úroveň.
Další způsoby jsou ty, které se nejčastěji používají jako druhořadé, pokud metoda vypnutí nebo tvrdého restartu z nějakého důvodu selže (Pamatujete? Princip redundance). Nicméně i tyto metody, kdy nody nejsou vypnuty, jsou při dodržení určitých pravidel podporovány jako primární fencing.
Dochází tady k situaci, kdy node sice běží (reboot z nějakého důvodu neproběhl), ale má zamezen přístup k datům. Způsobů, jak tohoto typu fencingu dosáhnout, je více. Nejčastěji se používají SCSI rezervace nebo odeslání speciálních pokynů storage switchi.
Power fencing (reboot/poweroff) provádíme vždy hostem neboli hypervisorem, pokud se jedná o cluster z virtuálních mašin. V případě fyzických serverů jednu z takzvaných power-based metod představuje out-of-band management – lights out kartami, UPSkami, PDU atd. Technologií je spousta (virtuálky – KVM, VMWare; Dell má DRAC karty, IBM své management moduly nazývá AMM nebo IMM, HP používá iLO atd.), proto potřebujeme mnoho druhů fence agentů.
Fence agent – program zajišťující korektní provedení fencingu. Často bývá napsaný v céčku nebo Pythonu. Má za úkol kontaktovat hypervisor, lights out kartu nebo jiné zařízení a předat jim pokyn k okamžitému vypnutí dané VM. V případě storage-based fencingu, tedy odstřižení stroje od dat, si fence agent vyžádá okamžité odpojení stroje od disků a LUNů spravovaných clusterem. V případě virtuálek zasáhne hypervisor, u fyzických strojů zasáhne storage switch nebo se na LUNy odešlou SCSI rezervace.
Corosync – vrstva, přes kterou je zabezpečena základní komunikace mezi nody clusteru. Na této vrstvě se odehrává komunikace přes zmíněný token. Teprve cluster, korektně komunikující na této úrovni, může hostovat nějaké služby.
Pacemaker – resource manager, správce zdrojů/služeb v clusteru na RHEL 7 a derivátech
Rgmanager – resource manager, správce zdrojů/služeb v clusteru na RHEL 6 a derivátech. Od 6.5 je na RHEL podporována kombinace corosync + rgmanager nebo corosync + pacemaker Nudný, ale nutný úvod v podobě pojmů je za námi. Jdeme dál!
Jak na to?
Nejprve je samozřejmě nutné mít stroje, na nichž lze cluster postavit. Prozatím potřebujeme VM s nainstalovaným OS: RHEL7, Centos 7 nebo Fedora. Cokoliv odvozené od RHEL by mělo být použitelné pro tento článek. Pokud jde o fyzické stroje, ty musejí mít buď možnost out-of-band managementu, nebo mít k dispozici jinou formu fencingu – viz výše. Dále bude nutné znát přihlašovací jméno a heslo uživatele, který má na dané out-of-band management kartě (pokud je použita) dostatečné oprávnění k tomu, aby mohl vypínat/zapínat naše stroje a zjistit jejich stav. Toto je ostatně nutná podmínka i v případě VMware. Pokud si postavíte cluster na VMware, účet, který je použit pro tyto operace, musí mít dostatečná oprávnění na hypervisoru. Tyto problémy ale můžete ignorovat, pokud je váš cluster postavený na KVM, jako v tomto článku – fence agent fence_xvm, který je pro KVM doporučený, žádného uživatele pro připojení se nepoužívá.
Poznámka ke clusteru použitému v tomto článku
Cluster, se kterým budu v tomto článku/seriálu pracovat, bude postaven na Fedora 25. Samozřejmě odkazovaná Red Hat dokumentace se vztahuje k RHEL. Je velice dobrá, vyplatí se pročíst ji. Pokud jste vývojářem v Linuxu, můžete využít nabídky Red Hat a její produkty používat zdarma, na základě registrace. Ta vám zajistí i přístup do znalostní databáze (access.redhat.com/solutions a access.redhat.com/articles). VMkám stačí 1GB RAM a 1 procesor. Můj KVM host je rovněž Fedora 25. Pokud si chcete ušetřit práci s virtuálkami, můžete použít rychlejší řešení, například Fast-VM mého kolegy Ondry Faměry. VM budou tři: f25a a f25b budou cluster nody a klienty (initiators) iSCSI targetu na f25storage, odkud bude pocházet sdílené úložiště.
V článku používám slovo host v souvislosti s hypervisorem, nikoli VM.anglicky host – česky hostitel, neboli stroj, na kterém VM běží anglicky guest – česky host, neboli VM samotná
Sestavení clusteru
Nastavení fencingu na KVM hypervisoru
Jak už bylo řečeno, jako fencing použijeme v tomto článku agenta fence_xvm. Jeho architektura v podstatě funguje na principu klient – server. Na KVM hostu běží služba poslouchající (na portu 1229/tcp a ta je schopná virtuálky natvrdo stopnout, restartovat nebo například zjistit jejich stav.
Nejdříve nainstalujte službu fence_virtd na KVM hosta:
# yum install -y fence-virt fence-virtd fence-virtd-libvirt fence-virtd-multicast fence-virtd-serial
fence_xvm ke svému fungování potřebuje takzvaný klíč. Jedná se o soubor, který obsahuje nějaká data a je nakopírován na KVM hostu a na všech nodech clusteru na stejném místě (očekává se /etc/cluster/fence_xvm.key, ale dá se to změnit).
Vytvořme tedy na KVM hostu složku /etc/cluster a do ní příkazem dd uložíme náhodná data do souboru fence_xvm.key. Fungovat bude například i textový soubor. Hlavní je, aby KVM host i všechny nody clusteru měly tentýž klíč.
# mkdir -p /etc/cluster # dd if=/dev/urandom of=/etc/cluster/fence_xvm.key bs=4k count=1
Složku /etc/cluster vytvoříme i na nodech clusteru.
Soubor /etc/cluster/fence_xvm.key pak zkopírujeme na všechny nody clusteru. Pokud na KVM hostu máte v /etc/hosts záznamy o nodech v clusteru (což je praktické) nebo používáte DNS, můžete použít jejich jména, popřípadě „plně specifikované doménové jméno počítače“ (FQDN, převzato z wiki).
# scp /etc/cluster/fence_xvm.key root@f25a:/etc/cluster # scp /etc/cluster/fence_xvm.key root@f25b:/etc/cluster
Poté stačí službě fence_virt vygenerovat konfigurační soubor…
# fence_virtd -c
Parsing of /etc/fence_virt.conf failed.
Start from scratch [y/N]? y
Module search path [/usr/lib64/fence-virt]:
Listener module [multicast]:
Multicast IP Address [225.0.0.12]:
Multicast IP Port [1229]:
Interface [none]: virbr0 <---- Zařízení zabezpečující komunikaci mezi nody
Key File [/etc/cluster/fence_xvm.key]:
Backend module [libvirt]:
Libvirt URI [qemu:///system]:
Configuration complete.
=== Begin Configuration ===
backends {
libvirt {
uri = "qemu:///system";
}
}
listeners {
multicast {
key_file = "/etc/cluster/fence_xvm.key";
interface = "virbr0";
port = "1229";
address = "225.0.0.12";
family = "ipv4";
}
}
fence_virtd {
backend = "libvirt";
listener = "multicast";
module_path = "/usr/lib64/fence-virt";
}
=== End Configuration ===
Replace /etc/fence_virt.conf with the above [y/N]? y
… povolit firewall na port 1229/tcp ….
Na RHEL 6 a derivátech bude potřeba:
# iptables -I INPUT -m state --state NEW -p tcp --dport 1229 -j ACCEPT # service iptables save ; service iptables restart
Na RHEL 7 a derivátech spusťte:
# firewall-cmd –permanent –add-port=1229/tcp # firewall-cmd --reload
… a spustit službu a zabezpečit její spuštění po startu systému:
Na RHEL 6 a derivátech
# service fence_virtd start # chkconfig –levels 35 fence_virtd on
Na RHEL 7 a systémech používajících systemd:
# systemctl start fence_virtd # systemctl enable fence_virtd
Pro kontrolu si na KVM hostu zkuste vypsat seznam VM, které služba fence_virtd vidí (ty, které jsou momentálně zapnuté)
# fence_xvm -o list | grep f25 f25a 882d2e34-2579-4c74-848b-91c8f71a3854 on f25b 43607646-7a22-4867-841a-fa80fe6a53ef on f25storage 270d1938-e63e-4677-9caa-3cf825bee455 on
Ověřit si, že to funguje, můžeme tak, že zkusíme jednu z běžících VM otočit.
# fence_xvm -o reboot -H f25a; echo $?
0
Funkčnost směrem z nodů clusteru na KVM host si ověříme za chvíli, až nainstalujeme fence agenty a cluster balíky na nody.
Name resolution a samostatná síť pro heartbeat
Jedním ze základů při sestavování clusteru (pokud chceme mít nody nějak pojmenované a nepoužívat jen jejich IP adresy) je name resolution – přiřazení IP adresy k nějakému jménu. Nejjednodušeji a nejspolehlivěji to provedeme v /etc/hosts na všech (obou) nodech. Bývá zvykem mít dedikovanou privátní síť pro heartbeat neboli posílání tokenu. Je to například z toho důvodu, abychom nezahltili hearbeat síť daty, které jsou clusterovou službou přijímána/odesílán, a tím nechtěně nezpůsobili, že nody neodpoví na token včas. Dále, stále ve smyslu eliminace single point of failure, bychom měli naše privátní IP adresy přiřadit zařízením, která jsou sama redundantní. Ačkoliv je v RHEL 7 k dispozici team, pouze bonding je podporovaný pro heartbeat síť. Pokud vám bonding přijde příliš složitý, nebojte se ho pro účely prvního testovacího clusteru vynechat a přiřaďte statickou IP jedné samostatné síťové kartě.
Dále máme určitě zájem na tom, aby se nám IP adresy v privátní heartbeat síti nijak neměnily, protože by to ohrozilo stabilitu celého clusteru. Proto použijeme statické IP adresy (parametr BOOTPROTO=none v ifcfg- souborech nebo ipv4.method manual, pokud konfigurujeme síťovou kartu pomocí nmcli).
Instalace a sestavení clusteru
Po instalaci systému doporučuji provést aktualizaci na obou nodech, abychom měli aktuální balíky. Pravděpodobně se nainstaluje i nový kernel, proto bude vhodné VM restartovat. Fedora používá dnf, na RHEL byste použili yum.
# dnf update -y && reboot
Instalace clusterových balíků:
# dnf install -y pcs fence-virt fence-agents-all
Povolení firewallu jak pro clusterové služby, tak pro xvm fencing:
# firewall-cmd --permanent --add-service=high-availability # firewall-cmd --permanent --add-port=1229/tcp # firewall-cmd --reload
Cluster nody používají pro komunikaci uživatele hacluster, který je součástí skupiny haclient:
# id hacluster
uid=189(hacluster) gid=189(haclient) groups=189(haclient)
Nastavme tedy stejné heslo na všech nodech:
# echo "password" | passwd --stdin hacluster Changing password for user hacluster. passwd: all authentication tokens updated successfully.
Pro zapnutí clusterových služeb stačí nastartovat pcsd a povolit jeho start při startu systému:
# systemctl start pcsd.service # systemctl enable pcsd.service
Nyní už můžeme cluster konečně sestavit. V následujícím příkazu použijeme jména nodů tak, jak jsme je definovali v /etc/hosts. Pokud tedy máme definované node1 a node2, použijeme tato jména. /etc/hosts je výhodné rozkopírovat na všechny (oba) nody clusteru. Pokud si rozkopírujete i ssh klíče, bude se vám pohodlněji pracovat:
# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 # Access IPs 192.168.10.227 f25storage f25storage.example.com 192.168.10.136 f25a f25a.example.com 192.168.10.231 f25b f25b.example.com # iSCSI IPs 192.168.10.179 storage1 192.168.10.146 storage2 # corosync (heartbeat) IPs 192.168.30.205 node1 f25a-int 192.168.30.231 node2 f25b-int
Po spuštění pcsd démona je potřeba nody autorizovat:
# pcs cluster auth node1 node2 -u hacluster -p password node2: Authorized node1: Authorized
Samotné sestavení clusteru provedeme příkazem:
# pcs cluster setup --name cluster1 --enable --start node1 node2 Destroying cluster on nodes: node1, node2... node2: Stopping Cluster (pacemaker)... node1: Stopping Cluster (pacemaker)... node1: Successfully destroyed cluster node2: Successfully destroyed cluster Sending cluster config files to the nodes... node1: Succeeded node2: Succeeded Starting cluster on nodes: node1, node2... node1: Starting Cluster... node2: Starting Cluster... node1: Cluster Enabled node2: Cluster Enabled Synchronizing pcsd certificates on nodes node1, node2... node1: Success node2: Success Restarting pcsd on the nodes in order to reload the certificates... node1: Success node2: Success
Gratulace, náš nový cluster je na světě! Ověříme si to:
# pcs status Cluster name: cluster1 WARNING: no stonith devices and stonith-enabled is not false Stack: corosync Current DC: node1 (version 1.1.16-1.fc25-94ff4df) - partition with quorum Last updated: Thu Apr 27 13:56:24 2017 Last change: Thu Apr 27 13:56:05 2017 by hacluster via crmd on node1 2 nodes configured 0 resources configured Online: [ node1 node2 ] No resources Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled
Dostali jsme varování:
WARNING: no stonith devices and stonith-enabled is not false
Prý nemáme nastavené žádné stonith zařízení. Co je stonith?
STONITH znamená Shoot The Other Node In The Head. Neboli jedná se o fencing. V RHEL 6 to byly fence devices, v RHEL 7 se jmenují stonith devices. Na začátku článku jsme zdůraznili, jak důležitý fencing je. Clustery bez správně nastaveného fencingu ani nejsou podporované. Proto do našeho clusteru fencing neboli stonith device přidáme.
Jde v podstatě o cluster resource, řekněme o jakousi obálku nad fence agentem. Jako každý resource musí být i fence device v clusteru definována. Ale tím, že je to jen nadstavba fence agenta, musíme fence agentu dát správné parametry. Ty otestujeme a pokud nám to pěkně funguje, zaneseme tohle nastavení do clusterové konfigurace. V našem případě to bude jednoduché: fence_xvm většinou funguje bez jakýchkoliv parametrů, pokud jsme ho nastavili správně. Ale při použití reálných fyzických strojů je potřeba otestovat uživatele a heslo, jeho oprávnění, jsou tam možnosti zabezpečení, různé timeouty apod. Pro informaci si pročtěte manuálové stránky fence agentů:
# man -k fence_
Pusťme se tedy do testování fencingu. V této chvíli by oba nody clusteru, poté, co jim to přikážeme, měly být schopné fencovat jeden druhého. Zatím není fencing v režii clusteru (to se stane až po vytvoření stonith device), ale už teď by fencing měl být technicky možný. Pojďme se přesvědčit.
Pamatujete si příkaz fence_xvm? Je to ten, který tady budeme používat. Měl by fungovat úplně stejně jako předtím na KVM hostu.
V této chvíli by už nody měly být schopné vidět virtuálky na hostu příkazem fence_xvm:
# fence_xvm -o list | grep f25 f25a 882d2e34-2579-4c74-848b-91c8f71a3854 on f25b 43607646-7a22-4867-841a-fa80fe6a53ef on f25storage 270d1938-e63e-4677-9caa-3cf825bee455 on
[root@f25b ~]# fence_xvm -o status -H f25a Status: ON
Reboot by samozřejmě měl také fungovat. (Skutečně, i když pro účely článku používám jen VM f25a, funguje následující příkaz i pro ostatní virtuálky – domény, které na KVM hostu máte nadefinovány):
# fence_xvm -o reboot -H f25a; echo $? 0
A protože jsme si nechali vypsat jen návratový kód příkazu (nula, korektní provedení bez chyb) a fence_xvm bez parametru -d nevypisuje žádné další informace, spustili jsme před fencingem journalctl -af pro zobrazení logů (podobné tailf /var/log/messages na RHEL6). Aneb vítejte ve světě logů na clusteru s pacemakerem!
# journalctl -af
Z celé této zaplavy hlášek vyberu několik podstatných:
corosync[1495]: [TOTEM ] A processor failed, forming new configuration.
Pochází z corosyncu, takže se jedná o komunikační vrstvu: processor failed
znamená, že corosync jednoho z cluster nodů už nekomunikuje s clusterem a corosync přeživšího nodu si toho brzy všimnul. V momentu, kdy vidíte tuto hlášku, musí následovat fencing, aby se mohly nastartovat resources.corosync[1495]: [TOTEM ] A new membership (192.168.30.205:24) was formed. Members joined: 1 corosync[1495]: [QUORUM] Members[2]: 1 2
Nastal moment, kdy se corosync restartovaného nodu znovu připojil do clusteru. Corosync nám také vždy vypíše, kolik nodů vidí, a které z nich (Members[2]: 1 2):
pengine[1741]: error: Resource start-up disabled since no STONITH resources have been defined
Dokud není konfigurovaný fencing, nic nám prostě nepojede.
Pokud zkusíte totéž na nodu 2, musíte zaznamenat stejné chování. Pokud ne, je někde chyba, kterou je třeba odstranit.
Teď vzhůru ke konfiguraci stonith resource!
Konfigurace stonith resource
Můžeme si nechat vypsat všechny podporované fence agenty:
# pcs stonith
Zobrazíme si parametry toho našeho:
# pcs stonith describe fence_xvm
Vytvoříme stonith device :
# pcs stonith create xvmfence fence_xvm pcmk_host_list="node1 node2" pcmk_host_map="node1:f25a node2:f25b"
Pro vysvětlení, co jednotlivé parametry znamenají – jak asi tušíte, pomůže nám manuálová stránka, a to man stonithd. V pcmk_host_map je před dvojtečkou označení nodu tak, jak ho zná cluster, po dvojtečce tak, jak ho zná KVM host.
# pcs status Cluster name: cluster1 Stack: corosync Current DC: node2 (version 1.1.16-1.fc25-94ff4df) - partition with quorum Last updated: Thu Apr 27 14:13:01 2017 Last change: Thu Apr 27 14:12:33 2017 by root via cibadmin on node2 2 nodes configured 1 resource configured Online: [ node1 node2 ] Full list of resources: xvmfence (stonith:fence_xvm): Started node1 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled
Konfiguraci ověříme, jak jinak, testem. Interpretaci logů nechám na vás:
# pcs stonith fence node1 Node: node1 fenced
Je rovněž dobré nasimulovat situaci, kdy jeden z nodů neodpovídá. Očekávali bychom, že zdravý node problém detekuje a provede fencing toho, který neodpovídá.
Zdaleka nejjednodušší je situaci nasimulovat tím, že prostě vypnete síťovou kartu, na které běží IP pro heartbeat. Ačkoliv se nejedná o správný způsob simulace (dokument výše zmiňuje zablokování portů komunikace a v případě KVM i odstranění bridge, který na KVM hostu obsluhuje síť pro VM v clusteru), pro rychlou ukázku ztráty tokenu to stačí.
# nmcli dev dis bond1
Nebo:
# nmcli dev dis sitovka
Sledujte poté logy a uvidíte, co se doopravdy děje.
Ovládání clusteru
Jak jste si všimli, cluster se ovládá přikazy pcs … oblast, kterou chcete spravovat. Pokud nevíte, jak dál, spusťte jen pcs a bude vás to navigovat dále. Funguje tam propracovaná kontextová nápověda. Dále je dobré zmínit praktickou a návykovou tab-completion.
Zkuste objevovat možnosti pcs sami. Nebojte se používat –full, často je to výhodný přepínač, který vám vypíše spoustu zajímavých informací.
Jako tečku zmíním ještě možnost ovládat cluster přes webové rozhraní. Stačí do vyhledávače zadat:
https://ip-nodu:2224
Přihlásíte se jako hacluster a po přiřazení existujícího clusteru (viz obrázek), ho můžete spravovat tady:
Závěr
Pokud jste došli až sem a řídili se našimi pokyny, měli byste dospět k funkčnímu clusteru. Asi to bylo náročné, ale jste dobří, zvládli jste to!
Cluster zatím nic neumí, ale brzy to napravíme. Hlavně, že už je hotový a je (nebo by měl být) schopný rozpoznat neodpovídající node. To je základ, bez něhož nelze dále pokračovat.
V příštím díle se zaměříme na sdílené úložiště pomocí iSCSI a multipath. Po tom, co oba nody budou mít možnost zapisovat na stejné úložiště, resources začnou mít smysl.
Reference
[1] https://cs.wikipedia.org/wiki/Po%C4%8D%C3%ADta%C4%8Dov%C3%BD_cluster
[2] https://cs.wikipedia.org/wiki/Vysok%C3%A1_dostupnost
[3] https://en.wikipedia.org/wiki/Single_point_of_failure
[4] https://en.wikipedia.org/wiki/Split-brain_(computing)
[5] Smyslem fencingu je okamžitá akce ihned po detekci chybějící odpovědi na token. Proto se v clusterech důrazně doporučuje vypínat acpid, které z tohoto okamžitého restartu dělal restart pozvolný, s běžným zastavením všech systémových služeb (signálem SIGTERM, 15), anglicky graceful shutdown. Více zde:
Fencing fails in a RHEL 7 High Availability cluster because systemd initiates a graceful shutdown
High Availability Cluster nodes shutdown gracefully rather than powering off when fenced in RHEL
[6] https://en.wikipedia.org/wiki/Out-of-band_management
[7] https://en.wikipedia.org/wiki/Uninterruptible_power_supply
[8] https://en.wikipedia.org/wiki/Power_distribution_unit
[9] https://en.wikipedia.org/wiki/Dell_DRAC
[11] https://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=MIGR-5079770
[12] hhttps://en.wikipedia.org/wiki/HP_Integrated_Lights-Out
[13] https://en.wikipedia.org/wiki/Logical_unit_number
[14] http://searchstorage.techtarget.com/definition/SAN-switch-storage-area-network-switch
[15] https://en.wikipedia.org/wiki/Out-of-band_management
[17] Oficiální dokumentace Red Hat týkající se clusteru
[18] https://github.com/OndrejHome/fast-vm
[19] FQDN
https://en.wikipedia.org/wiki/Fully_qualified_domain_name
https://cs.wikipedia.org/wiki/FQDN
[24] What is the proper way to simulate a network failure on a RHEL Cluster?
