Zjistil jsem, že když lidé navrhují architekturu Oracle RAC, často ve svých plánech implementace nemyslí na redundanci N+1. Existují dva důvody pro implementaci Oracle RAC, dostupnost a škálovatelnost. Pro účely této diskuze se zaměřuji pouze na stránku dostupnosti. Pokud jsou vaše nasazení RAC pouze z důvodů škálovatelnosti, pak se vás toto téma nemusí týkat.
Co je tedy redundance N+1? Jednoduše řečeno, pokud potřebujete N jednotek něčeho, pak pro účely redundance byste měli mít N+1 této položky. Podívejme se na databázový server. Musí mít napájení. To je požadavek. Bez funkčního zdroje napájení nebude server fungovat vůbec. Minimální počet napájecích zdrojů je 1. Pokud chceme, aby měl tento server vysoký stupeň dostupnosti, zajistíme, aby měl napájecí zdroje N+1, nebo v tomto případě duální napájecí zdroje. Pokud existuje pouze jeden zdroj napájení a ten selže, vezme s sebou server. Pokud máme extra napájecí zdroj, náhradní jednotku, ztráta jednoho zdroje nesundá server s ním. Redundance je skvělá věc a základní součást infrastruktury s vysokou dostupností.
Při navrhování systému Oracle RAC musí DBA určit, kolik uzlů je potřeba k podpoře požadavků koncového uživatele. Pokud DBA určí, že jsou potřeba 4 uzly a tento cluster RAC musí vykazovat vlastnosti vysoké dostupnosti, pak je pro DBA životně důležité vytvořit 5 uzlový cluster (4+1). Pokud jsou požadavky na zdroje dostatečné k udržení 4 uzlů zaneprázdněných a jeden uzel je ztracen, zbývající 3 nebudou schopny držet krok s pracovní zátěží. Pokud DBA staví systém RAC s ohledem na schopnost N+1, pak ztrátu jednoho uzlu koncoví uživatelé nepostřehnou. Pokud DBA sestaví cluster RAC bez redundance N+1, pak ztráta jednoho uzlu může být pro výkon koncového uživatele tak hrozná, že může být celý cluster mimo provoz. Při navrhování implementací RAC usilujte o redundanci N+1.
Pamatuji si, že před dvěma lety jsem měl cluster RAC, který ztratil uzel. Žádný problém, stále jsme měli k dispozici dva uzly. Když jsem sledoval výkon dvou zbývajících uzlů, zdálo se, že jsou docela ohromeni. Naše call centrum začalo přijímat stížnosti. Spolupracoval jsem s ostatními správci v IT týmu, aby byl uzel co nejrychleji zprovozněn a spuštěn, ale nemusí to tak být vždy, pokud je důvodem výpadku hardware a je třeba vyměnit díly. Poté, co byl uzel zpět v provozu, jsem několik týdnů poté sledoval výkon clusteru. Naše využití vzrostlo od doby, kdy byl tento systém původně navržen. Původně jsme tento systém navrhovali s ohledem na redundanci N+1, ale naše využití rostlo a N se změnilo z 2 na 3. Náš současný 3-uzlový cluster již nebyl redundantní N+1. Spolupracoval jsem tedy s vedením, abych do rozpočtu na příští rok vložil dostatek prostředků na pořízení nového uzlu a zajistil, aby na něj byla licence Oracle. V noci spím mnohem lépe, protože vím, že jsem zpět na redundanci N+1.
Stejně jako mnoho dalších implementací není můj systém RAC jedinou funkcí vysoké dostupnosti zabudovanou do naší infrastruktury. Tato databáze RAC je primární pro fyzickou pohotovostní databázi s Oracle's Data Guard. Při diskuzi o pohotovostních databázích RAC s jinými Oracle DBA jsem překvapen, kolik z nich neuvažuje o schopnosti N+1 pro svůj pohotovostní režim. Fyzická pohotovostní databáze je moje záchranná síť pro případ, že by primární datové centrum bylo z nějakého důvodu nedostupné. Viděl jsem tolik Oracle DBA implementovat pohotovostní režim jedné instance pro primární RAC s více uzly. Au! Doufám, že nikdy nebudou muset selhat. Celá pracovní zátěž jejich clusteru RAC s více uzly bude v této jediné instanci v pohotovostním režimu silně bojovat. Takže při navrhování implementací RAC pro primární i pohotovostní režim zvažte své důsledky redundance N+1 na návrh architektury.
Pravděpodobně se liším od mnoha lidí v tom, že moje implementace fyzického pohotovostního režimu nejsou schopné N+1, ale spíše N. Přeskočím nadbytečný uzel navíc pro můj fyzický pohotovostní režim. proč tomu tak je? Čistě z pohledu nákladů. Můj fyzický pohotovostní režim je jen záchranná síť. Chci, aby mi to fungovalo v den, kdy to budu potřebovat. Ale doufám, že to nikdy nebudu potřebovat. Fyzická pohotovost je moje pojistka pro případ, že by se riziko stalo skutečností. Pro mě je to „+1“ navíc na pohotovostním místě nadměrným pojištěním. Mohu ušetřit na fyzickém hardwaru a licencování Oracle.
Takže řekněme, že přijde den a já přepnu do pohotovostního režimu. Ztratil jsem redundanci N+1. Ale jaká je pravděpodobnost, že přijdu o primární datové centrum *a* o jeden z uzlů v mém pohotovostním clusteru? Docela mizivé šance. Pravděpodobnost selhání na dvou místech současně je velmi malá. V tuto chvíli náš IT tým vyhodnocuje, proč je naše primární datové centrum ztraceno a kdy můžeme s největší pravděpodobností vrátit naše operace do tohoto zařízení. Pokud primární datové centrum ztratí veškerou energii a energetická společnost řekne, že služba bude obnovena do zítřka, pak jednoduše poběžíme v pohotovostním datovém centru, i když tam máme pouze N uzlů pro databázi RAC. Pokud však bylo primární datové centrum zničeno požárem, bude trvat mnoho měsíců, než bude znovu spuštěno. V tuto chvíli musím naplánovat, jak tento fyzický pohotovostní režim dostat na redundanci N+1, protože naše používání tohoto pohotovostního režimu jako primárního bude mnohem delší období. Takže rychle objednáme další server a přidáme ho do clusteru co nejdříve. Navrhuji tedy svou pohotovostní databázi RAC jako N, nikoli N+1 s ohledem na její zvýšení na N+1 v krátké době, pokud zjistíme, že budeme pohotovostní režim skutečně používat po delší dobu.
Takže je tu ještě jeden zvláštní případ, o kterém bych chtěl diskutovat. To je místo, kde DBA určuje, že N=1. Pro aktuální požadavky na zátěž stačí jeden uzel. Chceme však mít vysokou dostupnost, a proto navrhujeme dvouuzlový cluster RAC pro primární databázi. Nyní máme redundanci N+1 zabudovanou do primární. Podle mého posledního odstavce moje pohotovostní databáze potřebuje pouze 1 uzel. Chyba, kterou někteří lidé dělají, je vytvořit pohotovostní režim jako databázi s jednou instancí. Zatím jejich logika dává smysl. Primární je N+1 a pohotovostní režim N. Zatím dobrý. V čem se liším, je to, že z pohotovostního režimu vytvořím cluster RAC s jedním uzlem, nikoli čistě implementaci jedné instance. Důvodem je budoucí růst. V určitém okamžiku může DBA zjistit, že N již není rovno 1 v primárním. Využití vzrostlo a N nyní musí být 2. DBA chce rozšířit primární na 3 uzly (2+1). To lze snadno odstranit s nulovými prostoji a přidat nový uzel do clusteru a rozšířit databázi RAC na tento nový uzel. Ale není to tak snadné udělat v pohotovostním režimu, aby se z pohotovostního režimu stal klastr se 2 uzly, pokud tento 1 uzel, který existuje, není povolen RAC. Pokud existuje pouze jednoinstanční pohotovostní režim, DBA jej musí zrušit a přesunout do clusteru se dvěma uzly. Pokud měl DBA prozíravost a nainstaloval infrastrukturu Grid, jako by fyzický pohotovostní režim byl cluster s jedním uzlem, pak vše, co musí udělat DBA, je přidat nový uzel, stejně jako to udělal na primární straně.
Při navrhování implementací RAC zvažte, zda máte schopnost N+1 na primární a alespoň N v pohotovostním režimu. Pokud společnost zjistí, že pohotovostní režim je příliš kritický, může chtít implementovat N+1 také v pohotovostním režimu. Pokud DBA určí, že N=1, zvažte vytvoření pohotovostního režimu alespoň jako cluster RAC s jedním uzlem.