HA cluster

Z DCEwiki
Skočit na navigaci Skočit na vyhledávání
cluster
je seskupení dvou a více fyzických počítačů (nodů), které navenek mohou vystupovat jako jeden subjekt - módně nazývaný cloud
nod
je fyzický stroj (server, PC,..), vybavený pevnými disky (HDD) s alespoň jednou síťovou kartou, který je v interakci s ostatními nody prostřednictvím komunikačního software - tím může být Pacemaker, zookeeper, apod.

Typologie clusteru z hlediska použití

Výpočetní cluster

Výpočetní cluster ( angl. HPC - High-performance Computing) využívá výpočetního výkonu jednotlivých nodů, tvořených obvykle stroji nižší cenové kategorie, pro zpracování dílčích matematických operací. Celkový výkon je pak mnohonásobně vyšší než by bylo vůbec možné dosáhnout u jediného fyzického stroje.

Diskový cluster

Neboli také Storage cluster vytváří jeden virtuální diskový prostor jeho rozložením mezi fyzické disky nodů. Využít pro tento účel lze buď speciálních clusterových souborových systémů ( OCFS2, GFS2, Lustre, CEPH,...), které jsou schopny řešit rozložení zátěže a redundanci dat mezi nody, nebo clusterové verze LVM (cluster).

Poznámka Některé clusterové souborové systémy, jako např. CEPH už při svém návrhu počítají s výpadky nodů, proto ukládají tzv. roztroušená data i s informacemi, které umožňují v případě potřeby dopočítat chybějící bloky dat.

Škálovatelný cluster

Je spojením nodů, které jsou schopny paralelně poskytovat stejný typ služby. V případě potřeby tak lze rozložit zátěž na více strojů, a takto zabránit přetížení některého z nodů. Tato funkcionalita se angl. označuje jako load ballancing. Protože lze tímto způsobem celkový výkon clusteru podle potřeby navyšovat nebo snižovat, označuje se tento typ clusteru jako škálovatelný (angl. scallable)

Typologie clusteru z hlediska zdrojů

Výše uvedenou typologii clusterů lze v čisté formě aplikovat pouze na homogenní clusterové prostředí, které nabízí pouze jednu službu (zdroj). V reálu však clusterové prostředí spravuje zdrojů více a navíc je i věšinou sestaveno z nodů různé kvality a s rozdílným hardwarovým vybavením.

Synchronní cluster

V případě synchronního clusteru může být zdroj poskytován na kterémkoliv nodu, případně z každého nodu současně.

Aby to bylo možné, musí být splněný výchozí předpoklad, že každý z nodů musí mít k dispozici:

  • identickou adresářovou infrastrukturu odpovídající potřebám zdroje
  • identické softwarové vybavení, potřebné k poskytování zdroje
  • identická zařízení potřebná k provozu zdroje.

Asynchronní cluster

Asynchronní cluster je typicky sestaven z různých nodů, které nemusí být schopny některé zdroje provozovat. Proto je u poskytovaných zdrojů nutné vždy nakonfigurovat lokaci. Pacemaker má v případě takového clusteru především zajistit, aby byly nody informovány zda-li je zdroj A, který potřebují pro zajištění zdroje B dostupný. Aby v případě, že tomu tak není, mohly podniknout příslušné kroky (zastavení zdroje B, restart zdroje A, atd.)

Grid

Grid někdo rovněž považuje za typ clusteru, ale není tomu tak. Grid sice připomíná svou funkcionalitou výpočetní a datový cluster, ale liší se tím, že jeho výpočetního výkonu není dosaženo paralelizací procesů, nýbrž jejich distribucí.

Stroje, které jsou v gridu, jsou vzájemně nezávislé a společnou mají pouze aplikaci, která rozděluje zpracování úkolu mezi jednotlivé výpočetní jednotky. Těmi nemusí být pouze jednotlivé fyzické servery (nody), ale i jiné clustery. Příkladem praktické implementace gridu může být internetová síť.

Pro grid je - na rozdíl od clusteru, naprosto normální, že se jeho nody průběžně objevují, nebo ztrácejí. Gridové aplikace je navrženy tak, aby s tím počítaly.

Grid svým rozsahem je tedy spíše typem infrastruktury, která navíc může přesáhnout rámec jedné organizace či společnosti.

HA cluster

Z hlediska funkcionality může implementovat všechny výše zmíněné typy clusterů. Liší se od nich především v tom, že je navržen tak, aby byl schopen přežít selhání nodů, bey toho, že by to muselo vést ke ztrátě dat či omezení poskytované služby.

S tím koresponduje i angl. zkratka HA, která znamená vysoce dostupný (high availability). Někdy se tento typ clusteru označuje také jako Failover Cluster.

Schopnost přežití spuštěných služeb je zajištěna jednak tím, že jsou..

  • Data uloženy redundantně (podobně jako u diskového clusteru)
  • Nody vzájemně informovány o spuštěných službách, takže v případě selhání nodu může být služba spuštěna jinde (podobně jako u škálovatelných clusterů).
  • Nody - jejich operační systém a hardware - navrženy tak, aby byly schopny přečkat i výpadek některého z lokálních disků, aniž by musely být odstaveny. U klasických výpočetních clusterů žádná data lokálně uložena nejsou, takže výpadek celého nodu není nijak kritický.

CRM - Cluster Resource Manager

O vzájemnou komunikaci mezi nody v rámci HA clusteru se stará CRM (Cluster Resource Manager). Komerční implementací CRM je např. LanderCluster, který může běžet jak na unixové platformě, tak na systémech od Microsoftu. Open source implementací CRM, které bude věnován zbytek tohoto manuálu, je Pacemaker - fork původní implementace linuxového HA clusteru, vyvíjené v rámci projektu Linux-HA.

Vysoká dostupnost služeb

CRM řeší kromě vzájemné komunikace nodů prostřednictvím lokálních agentů spouštění a zastavování služeb, podle nastavených pravidel. Cílem je aby byly spuštěné zdroje v rámci clusteru vždy k dispozici.

Náš cluster je určen především jako virtualizační platforma pro KVM. Vysoká dostupnost služeb tak není zajištěna přímo clusterem, ale virtuálními stroji, které lze..

  • v případě plánovaného výpadku nodu včas přesunout
  • v případě neplánovaného výpadku nodu znovu spustit

Aby bylo možné stroje migrovat za běhu, resp. provést spuštění po pádu původního nodu s minimální prodlevou, jsou všechny virtuální stroje umístěny v rámci jednoho sdíleného datového prostoru.

Sdílený datový prostor

Sdílení jednoho a téhož datového prostoru v rámci clusteru lze zrealizovat několika způsoby

  1. využitím sdíleného externího úložiště
  2. vytvořením datového úložiště rozprostřeného mezi nody

Pro náš účel jsme zvolili druhou variantu, neboť naším cílem bylo vytvořit "samonosnou" variantu clusteru, nezávislou na externím úložišti.

Pokud chceme k jednomu sdílenému datovému prostoru přistupovat na úrovni souborového systému, pak na něm musí být nainstalován clusterový souborový systém. Ten se liší od běžného souborového systému především tím, že umožňuje přistupovat k jednomu a témuž úložišti přes více míst. Od běžného souborového systému se interně liší distribuovaným zamykáním souborů, které zajistí, aby bylo možné pracovat s jedním a týmž souborem z několika nodů současně. U běžného souborového systému totiž s jednou otevřeným souborem jiný proces pracovat nemůže.

Existují dvě skupiny clusterových souborových systémů.

Sdílené blokové zařízení

První skupina těchto FS předpokládá, že je nainstalována nad jedním blokovým zařízením, sdíleným mezi všemi nody.

OCFS2
za jeho vývojem stojí fa. ORACLE. Zatím sice nemá podporu pro IPv6 protokol a umožňuje integrovat pouze 255 nodů, ale oproti GFS2 (který vyvíjí fa. Red Hat), je lépe dokumentovaný a z hlediska výkonu má mít i lepší výsledky.
GFS2
za jeho vývojem stojí fa. Red Hat.

Roztroušené datové úložiště

Výhodou clusterových souborových systémů, které používají roztroušené datové úložiště je, že jsou schopny dát dohromady hodně velkou datovou kapacitu i přes to, že její část padne na uložení metadat pro zajištění redundance.

Diskutabilní otázkou, je však výkon těchto FS ve srovnání se implementací clusterového FS nad sdíleným blokovým zařízení.

Jejich výhodou je, že při větším počtu nodů by měly být schopny ustát i výpadek části nodů, neboť jsou schopny chybějící data dopočítat, ovšem použitelní nasazení vyžaduje aby byly nody minimálně tři a více. U clusterů tvořených dvěma nody to nemá smysl.

CEPH
GlusterFS
Na rozdíl od CEPHu nepoužívá jeho klient pro přístup do souborového systému vlastní jaderný modul, ale modul fuse, který však provádí veškeré operace se soubory v userspace. Tím je ovšem limitován z hlediska výkonu. Při takových operacích, jako je rozbalení archivu brutálně selhává protože je vysoká režie spojená s malými soubory. Tento problém však lze do jisté míry obejít, pokud se vyžije přímý přístup přes API. Výhodou tohoto souborového systému je že umožňuje pružně přidávat i odebírat nody (funguje podobně jako LVM).

Proto je vhodné aby měly nody pro přenosy těchto dat vyhrazené vlastní síťové rozhraní, připojené nezávisle na ostatní síti skrz samostatný switch. U HA clusteru, který má pouze dva nody, lze takové připojení realizovat samostatným kabelem, připojeným přes vyhrazené síťové rozhraní napřímo (tzv. "bonding").

Redundance uložených dat

Clusterové souborové systémy nainstalované nad sdíleným blokovým zařízením samy o sobě žádnou redundanci dat neřeší, neboť tuto starost přenechávají externímu úložišti. V případě že cluster takové úložiště nemá, musí být redundance dat mezi nody zajištěna jinak.

Na úrovni nodů...

U HA clusterů se dvěma nody to lze vyřešit tak, že..

  • se z každého nodu vyexportuje jedno blokové zařízení přes NBD, a pak se z těchto síťových blokových zařízení sestaví softwarový raid. Na ten se pak nainstaluje clusterový FS.
  • jiné řešení je vytvořit DRBD zařízení v režimu Primary/Primary

DRBD zařízení (na schématu zvýrazněno jako oranžová vrstva), je ve své podstatě implementace síťového mirroru blokového zařízení. Funguje jako RAID 1, ovšem s tím rozdílem, že zrcadlení neprobíhá v rámci fyzického stroje, ale po síti. Stejně jako u lokálního softwarového RAID 1 pole to však znamená, že tímto způsobem nelze replikovat jedno blokové zařízení mezi více než dvěma nody. DRBD sice umožňuje přidat i blokové zařízení na třetím nodu, ovšem to by stejně fungovalo pouze jako spare disk, tj. data by se na ně začala replikovat až poté, co by vypadnul jeden z aktuálně aktivních strojů.

Nasazení DRBD má smysl především tam, kde malý počet nodů neumožňuje nasadit clusterový souborový systém, který by byl schopen v případě výpadku některého z nodů chybějící data dopočítat z uložených metadat.

V rámci jednoho nodu..

Na lokální úrovni nodů může být redundance dat zajištěna buď na úrovni softwarového RAID pole, nebo na úrovni LVM.

Poznámka Svislá linie na schématu, která odděluje oba nody, naznačuje do jaké úrovně se v rámci hierarchie clusteru pracuje s lokálními blokovými zařízeními.
Úroveň první vrstvy - RAID
I když jsou ve schématu naznačeny pro každý nod dva softwarové raidy typu mirror (zrcadlení), postačuje v zásadě pouze jeden raid typu 1 a výše. Úkolem první vrstvy je zajistit, aby při selhání jednoho z HDD zařízení stroj nadále běžel a výměnu vadného zařízení tak bylo možné provést aniž by bylo nutné stroj (nod) restartovat.
Úroveň druhé vrstvy - LVM
Umožňuje libovolné zvětšování a přerozdělování diskové kapacity nodu - opět bez nutnosti restartu celého stroje.

HA cluster - schémata

Cluster se dvěma nody (DRBD + OCFS2)

NOD 1                            NOD 2
/====\ /====\ /====\ /====\  |  /====\ /====\ /====\ /====\
| HDD || HDD || HDD || HDD | | | HDD || HDD || HDD || HDD |
\====/ \====/ \====/ \====/  |  \====/ \====/ \====/ \====/
/±±±±±±±±±±±\ /±±±±±±±±±±±±\ | /±±±±±±±±±±±\ /±±±±±±±±±±±±\
|   RAID1   ||    RAID1    | | |   RAID1   ||    RAID1    |
\±±±±±±±±±±±/ \±±±±±±±±±±±±/ | \±±±±±±±±±±±/ \±±±±±±±±±±±±/
/――――――――――――――――――――――――――\ | /――――――――――――――――――――――――――\
|          LVM VG          | | |         LVM VG           |
\――――――――――――――――――――――――――/ | \――――――――――――――――――――――――――/
/----------\ /-------------\ | /-------------\ /----------\
|  LVM LV  ||     LVM LV   | | |    LVM LV    ||  LVM LV  |
\----------/ \-------------/ | \-------------/ \----------/
/^^^^^^^^^^\ /++++++++++++++ ⇄ ++++++++++++++\ /^^^^^^^^^^\
| REISERFS ||              DRBD              || REISERFS |
\^^^^^^^^^^/ \++++++++++++++ ⇄ ++++++++++++++/ \^^^^^^^^^^/
/∷∷∷∷∷∷∷∷∷\ /^^^^^^^^^^^^^^^ ⇄ ^^^^^^^^^^^^^^\ /∷∷∷∷∷∷∷∷∷∷\
∷  Linux  ∷ |              OCFS2             | ∷  Linux   ∷
∷    OS   ∷ \^^/^^^/^\^^^^^^ ⇄ ^^\^^^^^^^^^^^/ ∷    OS    ∷
\∷∷∷∷∷∷∷∷∷/   /   /   \           \            \∷∷∷∷∷∷∷∷∷∷/
/∷∷∷∷∷∷∷∷∷\  /   /     \           \           /∷∷∷∷∷∷∷∷∷∷\
∷ Virtual  -    /       \            -----------  Virtual
\∷∷∷∷∷∷∷∷∷/-----          --- ⇄ ---------------\∷∷∷∷∷∷∷∷∷∷/
                          CLUSTER

Poznámka Poznámky ke schématu...
  • Hardwarová unifikace strojů (nodů) není podmínkou, ale výhodou, neboť usnadňuje konfiguraci a správu software.
  • Veškeré vrstvy blokových zařízení, souborové systémy na nich nainstalované, včetně umístění operačního systému na obou strojích, jsou pro snazší orientaci barevně zvýrazněny. Schéma bylo vytvořeno jako tzv. ascii-art protože obsahuje linky na stránky této wiki.
  • Komunikace, která probíhá v rámci clusteru je na schématu naznačena obousměrnými šipkami mezi nody

Cluster se dvěma a více nody (GlusterFS)

NOD 1                            NOD 2
/====\ /====\ /====\ /====\  |  /====\ /====\ /====\ /====\
| HDD || HDD || HDD || HDD | | | HDD || HDD || HDD || HDD |
\====/ \====/ \====/ \====/  |  \====/ \====/ \====/ \====/
/±±±±±±±±±±±\ /±±±±±±±±±±±±\ | /±±±±±±±±±±±\ /±±±±±±±±±±±±\
|   RAID1   ||    RAID1    | | |   RAID1   ||    RAID1    |
\±±±±±±±±±±±/ \±±±±±±±±±±±±/ | \±±±±±±±±±±±/ \±±±±±±±±±±±±/
/――――――――――――――――――――――――――\ | /――――――――――――――――――――――――――\
|          LVM VG          | | |         LVM VG           |
\――――――――――――――――――――――――――/ | \――――――――――――――――――――――――――/
/----------\ /-------------\ | /-------------\ /----------\
|  LVM LV  ||     LVM LV   | | |    LVM LV    ||  LVM LV  |
\----------/ \-------------/ | \-------------/ \----------/
/^^^^^^^^^^\ /^^^^^^^^^^^^^\ | /^^^^^^^^^^^^^\ /^^^^^^^^^^\
| REISERFS | |             | | |             | | REISERFS |
\^^^^^^^^^^/ \^^^^^^^^^^^^^/ | \^^^^^^^^^^^^^/ \^^^^^^^^^^/
/∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷\ | /∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷\
∷           Linux          ∷ | ∷          Linux           ∷
∷             OS           ∷ | ∷           OS             ∷
\∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷/ | \∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷/
/∷∷∷∷∷∷∷∷∷\ /^^^^^^^^^^^^^^^ ⇄ ^^^^^^^^^^^^^^\ /∷∷∷∷∷∷∷∷∷∷\
∷ Virtual <=             GlusterFS            => Virtual  ∷
\∷∷∷∷∷∷∷∷∷/ \^^^^^^^^^^^^^^^ ⇄ ^^^^^^^^^^^^^^/ \∷∷∷∷∷∷∷∷∷∷/
                          CLUSTER

Výpočetní výkon

V případě nouze lze virtuální stroje spustit i na jediném nodu, ale za normálního provozu lze virtuální stroje podle potřeby a aktuálního zatížení mezi nody migrovat a dosáhnout tím optimálního rozdělení výkonu jak fyzických strojů, tak jejich hardwarových prostředků.