Pojďme si na začátek říct, co to vlastně jsou geoclustery a k čemu slouží?

Asi nebude překvapením, že jako geoclustery označujeme řešení provozovaná ve více lokalitách. V rámci každého takového clusteru funguje skupina uzlů jako jeden systém. Typicky zajišťuje vysokou dostupnost. Známé jsou proto taky pod označením high-availability nebo failover clustery. Ale sloužit můžou třeba i k vyrovnání zátěže nebo k paralelnímu zpracování dat. Vždy záleží na jejich architektuře a zapojení. Zda lokality fungují v režimu Active/Active, nebo Active/Passive, což je mimochodem typičtější případ. Z příkladů Active/Active infrastruktury můžu uvést třeba Youtube.

Takže základním předpokladem je primární a sekundární lokalita…

Ano, ale tady bych jen rád podotkl, že abychom mohli mluvit o clusteru, musí být v obou lokalitách dostupná kompletní infrastruktura včetně výpočetních kapacit. Je dobré nezaměňovat geozálohování za geocluster. Na to pozor.

Dobře, pokud se vrátíme k těm dvěma lokalitám, tak jací zákazníci obvykle mají zájem o druhou lokalitu pro svá řešení?

Typicky to jsou společnosti s kritickými požadavky na vysoké zabezpečení a vysokou dostupnost. Banky, sázkové kanceláře a podobně. Některé k tomu přímo vybízí legislativa, jiné k podobnému řešení přistupují z vlastní iniciativy.

Co byste poradil jako úplně první věc, kterou by měla firma udělat při rozhodování o clusteru?

Spočítat ztráty za hodinu výpadku. Protože provoz clusteru vás jen na infrastruktuře bude stát dvojnásobek. Jinými slovy: spočítejte si, jestli se vám takové řešení vyplatí. A myslete na to, že ztráty nemusí být jen finanční. Výpadek může uškodit reputaci vaší společnosti. Stojí vám to za to? Pokud jsou potenciální ztráty příliš vysoké, běžte do toho.

Typicky je vhodné provozovat geoclustery z profesionálních datových center. Předpokládejme ale, že by si zákazník chtěl postavit cluster na vlastní pěst. Z jedné svojí pobočky do druhé. Jaká úskalí na něho čekají?

Předně musí v obou lokalitách zajistit redundantní napájení od dvou nezávislých dodavatelů energií, ze dvou zcela nezávislých rozvoden. A to byste nevěřili, ale už jen to je poměrně netriviální záležitost, a na mnoha místech v Česku neproveditelná. Protože někam prostě vede jen přípojka od jediného dodavatele.

Dále je potřeba vyřešit redundanci konektivity a propojení těchto lokalit. Zajistit, aby obě linky skutečně vedly fyzicky jinudy. Protože sice nejsme v tak tristní situaci jako Arménie, kam 90 % internetu vede z Gruzie jedním kabelem a k několikahodinovému odpojení celé země v roce 2011 stačila jedna aktivní sedmdesátnice hledající měď… (smích) Ale i u nás občas stačí jeden krumpáč a bezelstný silničář, aby se ukázalo, že v místě, kde nemělo být nic jiného než zemina, vede optika pro celý kraj od několika providerů.

To vypadá jako dost práce…

Rozhodně. Proto není od věci využít alespoň pro jednu z lokalit už existující infrastruktury datového centra. Nejenže máte k ruce profíky pro konzultace na bezpečnost i síťařinu, ale neřešíte ani napájení, UPSky, diesel agregáty, redundantní switche, routery. Odpadá taky spousta potenciálních problémů s vyjednáváním konektivity a podobně.

Existují vlastně nějaká doporučení ohledně vzdálenosti primární a sekundární lokality?

Ta omezení jsou de facto dvě. Maximální a minimální. Maximální vám určují technologie. Specifikace hardwaru a softwaru vám napoví, jaká je největší možná vzdálenost (RTT) pro replikaci. Ta minimální je vždy na vás. Stanovte si threat assessment, neboli míru rizika, jaké jste ochotní podstoupit. Je pro vás zásadní, aby byla primární loka­li­ta chráněna před rozvodněnou Vltavou? Pak volte tu druhou v jiném kraji, kudy Vltava neprotéká. Obáváte se nestabilní situace v nějaké konkrétní zemi? Takto můžete s trochou nadsázky dojít až k erupcím na Slunci a sami si určíte, jaká vzdálenost je pro vás ta pravá.

Probrali jsme clustery z pohledu hardware. Ale jak správně ošetřit jejich aplikační část. Jak by se měla zachovat aplikace, pokud se v primární lokalitě něco pokazí?

Pokud se bavíme o Active/Passive clusteru, tak tam je proměnných poměrně dost: RTO (Recovery Time Objective), RPO (Recovery Point Objective), failover a fallback. Zjednodušeně řečeno je to – jako hodně věcí v životě – celé o správném načasování. Jako admin musíte zvolit vhodný časový interval, po kterém v případě nedostupnosti dojde k přesměrování a spuštění provozu ze záložní lokality. Jestli to má být vteřina, minuta nebo pět minut, na to neumím odpovědět. Tohle je otázka, kterou kladu zákazníkům a odpověď na ni hledáme při konzultacích. Obecně ale zákazníkům radíme následovně: buďte realisté a nedávejte si zbytečně vysoké cíle. Minuta výpadku je v drtivé většině případů zcela tolerovatelná. Nižší interval se vám naopak může vymstít. Stačí, když se někde zasekne nějaký proces a dojde k úplně zbytečnému failoveru.

A co fallback zpět, je vhodné přepínání částech?

Záleží, obvykle se to doporučuje. Rozhodně bych zvážil provádět ho mimo pracovní dobu. Ale běžně se stává, že k němu nemusí nikdy dojít a řešení dál běží ze sekundární lokality. Z té se tak stává lokalita primární.

Máte nějakou radu na závěr?

Pokud provozujete geocluster pro potřeby disaster recovery, nezapomínejte na testy. Testujte, testujte, a zase testujte. Ať v případě výpadku opravdu vše sepne, jak má. Protože v opačném případě zjistíte, že jste si roky platili záložní lokalitu úplně zbytečně. A myslete i na třetí lokalitu pro ukládání dokumentace a dalších, pro obnovu důležitých, informací.