Cluster za málo peňazí

Potreboval som vytvoriť lacné prostredie, ktoré by sa čo najviac približovalo finálnej verzii, použitej pri nasadení projektu do produkcie (ľubovoľný počet uzlov na jednom zdieľanom storidži, na ktorý by v danom momente mohli okrem čítania všetky uzly aj zapisovať – rovnocenné uzly).

Text (neviem, či je označiteľný za článok) rozdelím na 2 časti. V prvej budem popisovať problém a riešenie. V druhej popíšem konkrétny postup.

Najmenej nákladným riešením, ktoré mi v tom momente napadlo boli dva servery, ktoré si navzájom budú obojsmerne replikovať dáta a budú mať na sebe distribuovaný filesystém. Bez váhania som si zvolil sadu RHCS (RedHat Cluster Suite), poskytujúcu množstvo užitočných nástrojov, ktorá bude systémom poskytovať GFSv2 (Global Filesystem). Komerčné licencie plnohodnotne ustojí free verzia v podobe CentOS (pravdepodobne aj Fedora, ktorá obsahuje tiež všetko potrebné – neskúšal som). Celá suita sa v release 5 veľmi vylepšila, takže bolesti spôsobované pri verzii 3 a 4 ma teraz už netrápili.

Prvým problémom je samotná replikácia. Na ňu som využil DRBD, ktoré je v CentOS obsiahnuté a už od verzie 8.0 podporuje tzv. Dual-primary mód, kedy sú si oba uzly rovnocenné – dá sa do nich zapisovať. Pred verziou 8.0 fungovalo DRBD ako fail-over – bol primárny uzol, ktorý bol read/write a sekundárny – na ktorý sa replikovali dáta z primárneho (read only). DRBD všetko rieši na relatívne nízkej úrovni. Aby nedochádzalo k sústavnej likvidácii dát, potreboval som filesystém využívajúci zámky, aby si uzly neliezli do kapusty. Na to je GFS ako stvorený, podobne funguje OCFS (Oracle Cluster Filesystem), ktorý ale nepoznám, preto som ani neexperimentoval. Samozrejme, že je viacej podobných filesystémov ale toto nie je text o nich. Druhým problémom je fakt, že RHCS nemá práve najradšej clustre menšie ako 3 uzly – má radšej keď má master uzol, ktorý šéfuje zvyšku (dá sa to napriek tomu prežiť). Posledným problémom je samotný lacný hardvér (skladačky). Štandardne ak cluster zistí, že niektorý uzol má problém, tak vie využiť rôzne možnosti (power switch, fiber switch, drac, ibm rsa...) na zakázanie prístupu problémového uzlu k prostriedkom (fencing). Na skladačke sa väčšina enterprise vecí nenachádza, je teoreticky možné použiť power switch, ten sa ale neodporúča použiť práve v prípade distribuovaných filesystémov. Využil som preto fence_ack_manual, kedy sa ohraničí druhý uzol manuálne. Oficiálne sa táto možnosť neodporúča používať v produkcii, vznikla pre testovacie potreby a kameňom úrazu je to, že na živej nóde treba zadať príkaz, ktorý odblokuje prístup ku GFS, po detekovaní problému s druhým uzlom. Na tom som si vyrobil démona, ktorý to za mňa ošéfuje.

Teraz prakticky. Máme 2 zhodne nainštalované uzly s rovnakou minimálne jednou partíciou, ktorú použijeme na GFS. V oboch serveroch máme po 2 sieťové karty, jednu použijeme na bežnú komunikáciu, druhú si prepojíme napriamo káblom, aby sme v prípade replikácie eliminovali riziko zníženia rýchlosti kvôli pomalej sieti. Takto sa obmedzíme na rýchlosť diskov/diskových polí v uzloch, keďže Gbit (dnes štandardnú kapacitu sieťovej karty) low-cost diskami neprekonáme.

Nainštalujeme, čo potrebujeme (oproti starším RHCS natrepali teraz služby do cman balíka, takže nie je potrebných milión ako v minulosti):

Na sekundárnych sieťovkách použijeme network podľa vlastnej ľubovôle, napríklad 172.16.0.1/30 a 172.16.0.2/30.

Na oboch nódach (ak máme zapnuté redhatovské iptables) urobíme napríklad:

do /etc/hosts pridáme:

a vytvoríme si /etc/drbd.conf:

Je to za predpokladu, že /dev/node2vg/node2srv sú na oboch uzloch rovnaké. Samozrejme, že device môže byť akákoľvek. Ak potrebujeme viac replikovaných partícií, tak si môžme obdobne urobit drbd2, drbd3, jankoamarienka atď.

Konfiguračný súbor prenesieme aj na druhý uzol. Urobíme:

Ak sme na danej partícii mali predtým dáta alebo metablok drbd z nejakých minulých neúspešných pokusov, môžme pomocou /dev/zero prepísať buď metadáta alebo rovno celý disk (dd if=/dev/zero ...)

A následne:

S veľkou pravdepodobnosťou sa drbd prepne do secondary módu a bude označený ako inconsistent (cat /proc/drbd).

Túto chorobu vyliečime:

Na prepínač -o pozor, neskôr, keď budú na zariadení dáta, by sme mali dávať na jeho použitie pozor (znamená to, že za každú cenu má zariadenie označiť ako konzistentné, bez ohľadu na stav dát).

Rovnako pomocou drbdadm vytvoríme zariadenie aj na druhom uzle, rovnako zapneme drbd a v /proc/drbd vidíme, že sa disky synchronizujú. Bude to trvať ( v závislosti na veľkosti partície, schopnosti sieťových kariet na eth1 a samozrejme rýchlosti disku/diskov ) niekoľko minút alebo desiatok minút.

Status zdravej drbd jednotky bude potom vyzerať takto:

Teraz nakonfigurujeme cluster manažéra (/etc/cluster/cluster.conf):

Opäť je dôležité, aby bol súbor na oboch strojoch rovnaký, ako aj pri drbd.conf.

Spustíme cman:

Tu sa fenced zasekne, lebo druhá nóda ešte nebeží. Bude čakať 5 minút, kým ju začne pokladať za nedostupnú. Dovtedy, keď zapneme aj druhú nódu, fence sa spustí, prípadne sa bez čakania spustí aj v prípade, že na aktívnom uzle použijeme fence_ack_manual -n node2.local

Zvolili sme si manuálne ohraničenie pomocou fence_ack_manual a cman sa spustil komplet.
Pozrieme si status clustra:

alebo obdobne zoznam uzlov (nód):

Službu cman zapneme aj na druhej nóde:

-t je tzv locktable name, používa sa názov clustra, pre ktorý je a názov filesystému.
-p slúži na výber protokolu pre zamkýňanie zápisov. Gfs sa dá používať aj ako lokálny filesystém, kedy zvolíme bez zamykania, my sme zvolili lock_dlm (distributed lock management) a minimálne v minulosti (neviem ako teraz) ešte existoval aj lock_gnbd (pre zvedavcov global network block device - redhatovský spôsob exportu lokálneho systému po sieti na iné stroje)
-j je počet žurnálov, po prečítaní manuálovej stránky mkfs.gfs2 sa dozviete, že sa dá definovať aj veľkosť žurnálov a niekoľko ďalších vlastností.

A potom už spokojne na oboch nódach:

Pozrieme, čo nám teraz cluster všetko poskytuje:

Z toho vieme vyčítať, že najnižšie je fence, nad ním dlm, nad ním gfs. Inak povedané, gfs, keďže je nastavený na lock_dlm, nám bez dlm nepôjde, dlm nepôjde bez fenced. Teraz môžme spokojne do /srv písať, nastaviť si naň služby atď. Nezabúdajte však, že RedHat-like systémy bežia štandardne so zapnutým SELinuxom a v príklade použitý /srv je neštandardný adresár, na ktorom nemá nastavené kontexty ani nič. Preto si ho buď dokonfigurujte, použite iné adresáre, alebo ho vypnite (čo by bola škoda).

Ďalej by som odporučil cez chkconfig –del vymazať služby drbd, cman, gfs2 a ostatné, čo chcete spúšťať nad gfs filesystémom a vytvoriť si démona, ktorý to všetko spustí a aj vypne v správnom poradí. RedHatovské init skripty to nemajú práve usporiadané pre takéto riešenie a je jednoduchšie to spustiť z jedného miesta, ako sa trápiť s prioritami a závislosťami initu. Rovnako by vaša služba/démon/čo chcete mala vedieť zavolať fence_ack_manual v prípade priekaku. Môžte použiť lokálny soket vo /var/run/cman_client, alebo jednoduché pingovanie strojov (čo môže byť neplecha, ak sa stroj len resetne), prípadne čítanie statusov zo syslogu, do ktorého cluster všetko píše. Máte neskutočne veľa možností (moje riešenie nie je freeware, tak ho nemôžem zverejniť).

Využiteľnosť tohto riešenia je diskutabilná. Je aj nie je použiteľné v produkčnom prostredí. Určite by som sa pobral cestou fiber diskového poľa, prípadne dualchannel scsi (s tým mám ale z minulosti zlé skúsenosti). V každom prípade, ak je obmedzený rozpočet a je treba vyššiu dostupnosť alebo aj výkon, dá sa uvažovať o výpomoci týmto riešením.

Vďaka zdieľanému read/write môžte urobiť napríklad round-robin v dns, môžte použiť inú časť z cluster suite (piranha), prípadne klasický heartbeat. Čokoľvek.

Cieľom tohto textu nebolo podrobne rozpísať funkcionalitu a možnosti RHCS, ktoré sú oveľa ďalej, ako tento príklad. RHCS poskytuje okrem iného automatické distribuovanie konfigurácií, failoverovanie, balancing atď. To už ale nie je o dvojuzlovom low-coste.