Moderní clusterové systémy a jejich využití. Prostředky implementace clusterů s vysokou dostupností. Klastrové projekty v Rusku

Vysoce výkonný cluster (skupina počítačů)

Počítačový cluster je skupina počítačů propojených vysokorychlostními komunikačními linkami, které společně zpracovávají stejné požadavky a jsou uživatelem prezentovány jako jeden výpočetní systém.

Hlavní vlastnosti shluků

Clustery se skládají z více počítačových systémů;

Fungují jako jeden výpočetní systém (ne všechny);

Cluster je spravován a prezentován uživateli jako jeden výpočetní systém;

Proč jsou potřeba klastry

Clustery lze použít pro různé účely. Clustery mohou vytvářet systémy odolné proti chybám, mohou sloužit ke zlepšení výkonu počítačového uzlu nebo mohou být použity pro časově náročné výpočty.

Jaké jsou shluky

Klastry převzetí služeb při selhání

Takové clustery jsou vytvářeny pro zajištění vysoké úrovně dostupnosti služby reprezentované clusterem. Čím větší je počet počítačů zahrnutých v clusteru, tím nižší je pravděpodobnost selhání prezentované služby. Počítače, které jsou součástí geograficky rozptýleného clusteru, také poskytují ochranu před přírodními katastrofami, teroristickými útoky a dalšími hrozbami.

Clusterová data lze sestavit podle tří hlavních principů

shluky studeného pohotovostního režimu- to je, když aktivní uzel zpracovává požadavky a pasivní uzel je nečinný a jen čeká, až aktivní uzel selže. Pasivní uzel začne fungovat až po výpadku aktivního. Cluster vytvořený podle tohoto principu může poskytovat vysokou odolnost proti chybám, ale v okamžiku, kdy je aktivní uzel vypnutý, mohou být požadavky, které v tu chvíli zpracovává, ztraceny.
hot standby cluster- tehdy všechny uzly systému společně vyřizují požadavky a v případě výpadku jednoho nebo více uzlů se zátěž rozloží mezi zbývající. Tento typ clusteru lze také nazvat clusterem pro vyrovnávání zátěže, o kterém si povíme později, ale s podporou distribuce požadavků při selhání jednoho nebo více uzlů. Při použití tohoto clusteru existuje také možnost ztráty dat zpracovaných uzlem, který selhal.
modulární redundantní cluster- to je, když všechny počítače v clusteru paralelně zpracovávají stejné požadavky a po zpracování je převzata jakákoli hodnota. Takové schéma zaručuje provedení žádosti, protože lze vzít jakýkoli výsledek zpracování žádosti.

Cluster pro vyrovnávání zátěže

Tyto clustery jsou vytvářeny především z důvodu výkonu, ale lze je také použít ke zlepšení odolnosti proti chybám, jako je tomu v případě clusteru s přepnutím při selhání za provozu. V datech klastru jsou požadavky distribuovány prostřednictvím vstupních uzlů do všech ostatních uzlů klastru.

Výpočetní clustery

Tento typ shluků se obvykle používá pro vědecké účely. V těchto systémech je úloha rozdělena na části, prováděné paralelně na všech uzlech clusteru. To vám umožní výrazně zkrátit dobu zpracování ve srovnání s jednotlivými počítači.

Nezapomeň odejít

Rychlý rozvoj informačních technologií, nárůst zpracovávaných a přenášených dat a zároveň zvyšující se požadavky na spolehlivost, dostupnost, odolnost proti chybám a škálovatelnost nás nutí znovu se podívat na již tak zdaleka mladou technologii clusteringu. Tato technologie umožňuje vytvářet poměrně flexibilní systémy, které budou splňovat všechny výše uvedené požadavky. Bylo by nesprávné si myslet, že instalace clusteru vyřeší absolutně všechny problémy. Ale je docela možné dosáhnout působivých výsledků shlukováním. Stačí jasně pochopit, o co se jedná, jaké jsou nejvýraznější rozdíly mezi jejich jednotlivými odrůdami a také znát výhody určitých systémů – z hlediska efektivity jejich aplikace ve vašem podnikání.

Analytici z IDC spočítali, že velikost trhu pro klastry v roce 1997 činila pouhých 85 milionů dolarů, zatímco loni měl tento trh „hodnotu“ již 367,7 milionů dolarů.. Vzestupný trend je zřejmý.

Zkusme tedy tečkovat „i“. K dnešnímu dni neexistuje jasná definice klastru. Navíc neexistuje jediný standard, který by klastr jasně reguloval. Nezoufejte však, protože ze samotné podstaty shlukování nevyplývá soulad s žádnou normou. Jediná věc, která určuje, že klastr je klastr, je soubor požadavků kladených na takové systémy. Uvádíme tyto požadavky (čtyři pravidla): l spolehlivost, l dostupnost funkce (dostupnost), l škálovatelnost, l výpočetní výkon. Na základě toho formulujeme definici shluku. Cluster je systém libovolných zařízení (servery, diskové jednotky, úložné systémy atd.), který poskytuje 99,999% odolnost proti chybám a také splňuje „čtyři pravidla“. Například: klastr serverů je skupina serverů (běžně označovaných jako uzly klastru) propojených a konfigurovaných tak, aby poskytovaly uživateli přístup ke klastru jako jedinému koherentnímu prostředku.

odolnost proti chybám

Hlavní charakteristikou clusteru je nepochybně odolnost proti chybám. To potvrzuje i uživatelský průzkum: 95 % respondentů odpovědělo, že potřebují spolehlivost a odolnost proti chybám v clusterech. Tyto dva pojmy by se však neměly zaměňovat. Tolerance chyb označuje dostupnost určitých funkcí v případě poruchy, jinými slovy je to redundance funkcí a vyrovnávání zátěže. A spolehlivost je chápána jako soubor prostředků zajišťujících ochranu proti poruchám. Takové požadavky na spolehlivost a odolnost klastrových systémů jsou dány specifiky jejich použití. Vezměme si malý příklad. Cluster slouží elektronickému platebnímu systému, takže pokud klient v určité chvíli zůstane bez obsluhy pro provozní společnost, přijde ho to draho. Jinými slovy, systém musí fungovat nepřetržitě 24 hodin denně, sedm dní v týdnu (7-24). Přitom 99% odolnost proti chybám zjevně nestačí, protože to znamená, že téměř čtyři dny v roce bude informační systém podniku nebo provozovatele nefunkční. Vzhledem k preventivní práci a údržbě systému se to nemusí zdát jako tak dlouhá doba. Ale dnešnímu klientovi jsou důvody, proč systém nefunguje, absolutně lhostejné. Potřebuje služby. Takže 99,999 % se stává přijatelnou hodnotou pro odolnost proti chybám, což odpovídá 5 minutám za rok. Těchto ukazatelů může být dosaženo samotnou architekturou clusteru. Uveďme příklad serverového clusteru: každý server v clusteru zůstává relativně nezávislý, to znamená, že jej lze zastavit a vypnout (například z důvodu údržby nebo instalace dalšího zařízení), aniž by došlo k narušení clusteru jako celku. Úzká souhra serverů, které tvoří cluster (uzly clusteru), zaručuje maximální výkon a minimální prostoje aplikace díky skutečnosti, že: l v případě selhání softwaru na jednom uzlu aplikace nadále funguje (nebo se automaticky restartuje) na jiné uzly clusteru;l selhání nebo selhání uzlu (nebo uzlů) clusteru z jakéhokoli důvodu (včetně lidských chyb) neznamená selhání clusteru jako celku; na jiných uzlech v clusteru Potenciální výpadky, kterým konvenční systémy nemohou zabránit, v clusteru se změní buď v mírný pokles výkonu (pokud uzly klesnou), nebo výrazné snížení (aplikace jsou nedostupné pouze po krátkou dobu potřebnou k přechodu na jiný uzel ), což umožňuje 99,99% úroveň dostupnosti.

Škálovatelnost

Vysoká cena klastrových systémů je způsobena jejich složitostí. Škálovatelnost clusteru je tedy docela relevantní. Počítače, které svým výkonem splňují dnešní požadavky, je totiž v budoucnu nutně splňovat nebudou. S téměř jakýmkoliv zdrojem v systému se dříve nebo později musí člověk potýkat s problémem s výkonem. V tomto případě jsou možné dvě možnosti změny měřítka: horizontální a vertikální. Většina počítačových systémů umožňuje několik způsobů, jak zlepšit svůj výkon: přidání paměti, zvýšení počtu procesorů ve víceprocesorových systémech nebo přidání nových adaptérů nebo jednotek. Toto škálování se nazývá vertikální škálování a umožňuje dočasně zlepšit výkon systému. Systém však bude nastaven na maximální podporované množství paměti, procesorů nebo disků a systémové prostředky budou vyčerpány. A uživatel bude čelit stejnému problému zlepšení výkonu počítačového systému jako dříve Horizontální škálování poskytuje možnost přidat do systému další počítače a rozdělit mezi ně práci. Výkon nového systému jako celku tak překračuje limity předchozího. Přirozeným omezením takového systému bude software, který se na něm rozhodnete provozovat. Nejjednodušším příkladem použití takového systému je distribuce různých aplikací mezi různé součásti systému. Můžete například přesunout své kancelářské aplikace z jednoho uzlu clusteru webových aplikací do druhého a podnikové databáze do třetího. To však vyvolává otázku vzájemné interakce těchto aplikací. Opět platí, že škálovatelnost je obvykle omezena na data používaná v aplikacích. Různé aplikace vyžadující přístup ke stejným datům potřebují způsob, jak přistupovat k datům z různých uzlů v takovém systému. Řešením jsou v tomto případě technologie, které ve skutečnosti z clusteru dělají cluster, a nikoli systém vzájemně propojených strojů. Zároveň samozřejmě zůstává zachována možnost vertikálního škálování clusterového systému. Klastrový model tedy díky vertikálnímu a horizontálnímu škálování poskytuje seriózní ochranu spotřebitelských investic.Jako varianta horizontálního škálování stojí za zmínku také použití skupiny počítačů připojených přes switch, který rozděluje zátěž (technologie Load Balancing ). O této poměrně oblíbené možnosti si povíme podrobně v dalším článku. Zde si všimneme pouze nízké ceny takového řešení, která je především součtem ceny přepínače (6 000 $ nebo více, v závislosti na funkčním vybavení) a hostitelského adaptéru (řádově několik set dolarů za každý; i když , samozřejmě můžete použít běžné síťové karty). Taková řešení nacházejí své primární využití na webech s vysokou návštěvností, kde jediný server nemůže zpracovat všechny příchozí požadavky. Schopnost distribuovat zátěž mezi serverové uzly takového systému vám umožňuje vytvořit jeden web na mnoha serverech.

Beowulf neboli výpočetní výkon

Řešení podobná výše popsaným se často nazývají Beowulfův cluster. Takové systémy jsou primárně navrženy pro maximální výpočetní výkon. Proto další systémy pro zlepšení spolehlivosti a odolnosti proti poruchám jednoduše nejsou poskytovány. Toto řešení má mimořádně atraktivní cenu, pravděpodobně proto si získalo největší oblibu v mnoha vzdělávacích a výzkumných organizacích. Projekt Beowulf se objevil v roce 1994 - vznikla myšlenka vytvořit paralelní výpočetní systémy (klastry) z veřejných počítačů založených na Intelu a levných ethernetových sítí, na tyto počítače nainstalovat Linux a jednu z bezplatných komunikačních knihoven (PVM a poté MPI). Ukázalo se, že pro mnoho tříd problémů a s dostatečným počtem uzlů poskytují takové systémy výkon srovnatelný s výkonem superpočítače. Jak ukazuje praxe, je docela jednoduché takový systém postavit. K tomu je potřeba pouze vysoce výkonný switch a k němu připojených několik pracovních stanic (serverů) s nainstalovaným operačním systémem Linux. To však nestačí. Aby tato hromada železa ožila, je potřeba speciální software pro paralelní výpočty Nejběžnějším paralelním programovacím rozhraním v modelu předávání zpráv je MPI (Message Passing Interface). Název Message Passing Interface mluví sám za sebe. Je to dobře standardizovaný mechanismus pro vytváření paralelních programů v modelu zasílání zpráv. Existují bezplatné (!) a komerční implementace pro téměř všechny superpočítačové platformy, stejně jako pro sítě pracovních stanic UNIX a Windows NT. MPI je v současnosti nejpoužívanějším a dynamicky se rozvíjejícím rozhraním své třídy. Doporučená bezplatná implementace MPI je balíček MPICH vyvinutý v Argonne National Laboratory. MPI je standardizováno MPI Forum. Nejnovější verze standardu je 2.0. Tato verze přidává k MPI důležité funkce, jako je dynamické řízení procesů, jednosměrná komunikace (Put/Get), paralelní I/O Neustálá poptávka po vysokém výpočetním výkonu vytvořila atraktivní trh pro mnoho výrobců. Některé z nich vyvinuly vlastní technologie pro spojování počítačů do clusteru. Nejznámější z nich jsou Myrinet od MyriCom a cLAN od Giganet. Myrinet je otevřený standard. K jeho implementaci nabízí MyriCom širokou škálu síťových zařízení za relativně nízké ceny. Na fyzické vrstvě jsou podporována síťová prostředí SAN (System Area Network), LAN (CL-2) a optická síť. Technologie Myrinet poskytuje vysokou škálovatelnost sítě a v současnosti je velmi široce používána při budování vysoce výkonných clusterů. Giganet vyvíjí software a hardware pro přímou interakci centrálních procesorových jednotek clusterových serverů při gigabitových rychlostech a obchází funkce OS. Cena řešení je asi 2 500 USD za 8portový přepínač, 150 USD za adaptér Myrinet, asi 6 250 USD za 8portový přepínač a 800 USD za adaptér Giganet. Ten mimochodem získal ocenění Best of Show na výstavě Microsoft Tech Ed 2000. Jako příklad si vezměme implementaci clusteru Beowulf v Institutu pro vysoce výkonné výpočty a databáze Ministerstva vědy a techniky Ruské federace. Cluster s názvem „PARITET“ je založen na běžně dostupných komponentách pro osobní počítače a pracovní stanice a poskytuje celkový špičkový výkon 3,2 GFLOP/s. Cluster se skládá ze čtyř dvouprocesorových výpočetních uzlů založených na procesorech Intel Pentium II/450 MHz. Každý uzel má 512 MB RAM a 10 GB Ultra Wide SCSI pevný disk. Výpočetní uzly clusteru jsou sjednoceny vysoce výkonným přepínačem Myrinet (kanály s šířkou pásma 1,28 GB/s, full duplex). Pro správu a konfiguraci slouží také redundantní síť (100 Mbit Fast Ethernet). Na uzlech výpočetního clusteru je nainstalován operační systém Linux (distribuční sada Red Hat 5.2). Rozhraní pro předávání zpráv MPI/PVM se používají pro programování paralelních aplikací.

Mini cluster od společností Dell a Compaq

Kromě přepínačového řešení pro budování clusteru existuje řada řešení – hardwarových i softwarových. Některá řešení jsou komplexní a jsou dodávána „tak jak jsou“ – „vše v jedné krabici“. Poslední možnost – nazvěme ji „cluster in a box“ – je také poměrně oblíbeným řešením, protože je určena pro masový trh a jedná se o cluster na základní úrovni (z hlediska výkonu a možností škálování). Konstrukce takových systémů, propojení vnitřních komponent, spolehlivost a odolnost proti poruchám jsou však plně v souladu s „velkými“ systémy. Abyste pochopili, jak cluster funguje, zvažte dva podobné produkční systémy – Compaq a Dell. Clustery od těchto známých hráčů na počítačovém trhu jsou sestaveny ze dvou serverů DELL - PowerEdge 6100 nebo PowerEdge 4200 a následně Compaq - Proliant 1850R. Použitý software je Microsoft Cluster Server (Compaq, Dell) nebo Novell High-Availability Services pro NetWare 4.0 / Clustering Services pro NetWare 5.0 (Compaq). Software umožňuje nakonfigurovat dva servery tak, že pokud jeden ze serverů v clusteru selže, jeho práce a aplikace budou okamžitě automaticky přeneseny na druhý server, čímž se eliminují prostoje. Oba klastrové servery poskytují své prostředky k provádění produkční práce, takže ani jeden z nich nečinně nečeká, dokud druhý selže. Komunikace mezi dvěma servery probíhá prostřednictvím tzv. pulzujícího spojení (Heartbeat) vyhrazené části lokální sítě. Když primární server selže, druhý server, který monitoruje připojení prezenčního signálu, zjistí, že primární server je mimo provoz, a převezme pracovní zátěž, která byla spuštěna na počítači se selháním. Mezi vykonávané funkce patří spouštění aplikací, procesů a služeb, které jsou nutné k reakci na požadavky klientů na přístup k selhávajícímu serveru. Přestože každý ze serverů v clusteru musí mít všechny prostředky potřebné k převzetí funkcí jiného serveru, hlavní vykonávané úkoly mohou být zcela odlišné. Sekundární server, který je součástí clusteru s podporou převzetí služeb při selhání, splňuje požadavek na poskytování funkce horkého pohotovostního režimu, ale může také spouštět své vlastní aplikace. I přes masivní duplicitu zdrojů má však takový cluster „krk láhve“ – rozhraní sběrnice SCSI a systému sdílené externí paměti, jehož výpadek způsobuje selhání clusteru. I když je to podle výrobců pravděpodobnost mizivá, takové miniklastry jsou primárně určeny pro autonomní provoz bez neustálého sledování a správy. Příkladem použití je řešení pro vzdálené kanceláře velkých společností pro zajištění vysoké dostupnosti (7S24) nejkritičtějších aplikací (databáze, poštovní systémy atd.). Vzhledem k rostoucí poptávce po výkonných, avšak odolných vstupních systémech, trh pro tyto clustery vypadá docela příznivě. Jediným „ale“ je, že ne každý potenciální spotřebitel klastrových systémů je ochoten zaplatit asi 20 000 USD za dvouserverový systém.

Suchý zbytek

Stručně řečeno, klastry mají konečně masový trh. Takový závěr lze snadno vyvodit z předpovědí analytiků Standish Group International, kteří tvrdí, že v příštích dvou letech bude celosvětový růst počtu instalovaných clusterových systémů činit 160 %. Analytici z IDC navíc spočítali, že velikost klastrového trhu v roce 1997 činila pouhých 85 milionů dolarů a loni měl tento trh „hodnotu“ již 367,7 milionů dolarů. Trend růstu je zřejmý. Potřeba clusterových řešení dnes skutečně vyvstává nejen ve velkých datových centrech, ale také v malých firmách, které nechtějí žít podle principu „lakomec platí dvakrát“ a investují své peníze do vysoce spolehlivých a snadno škálovatelných clusterových systémů. Možností implementace clusteru je naštěstí více než dost. Při výběru jakéhokoli řešení by se však nemělo zapomínat, že všechny parametry clusteru jsou na sobě závislé. Jinými slovy, musíte jasně upřednostnit požadovanou funkcionalitu clusteru, protože s rostoucím výkonem klesá míra dostupnosti (dostupnosti). Zvýšení výkonu a zajištění požadované úrovně dostupnosti nevyhnutelně vede ke zvýšení nákladů na řešení. Uživatel tedy musí udělat to nejdůležitější – najít zlatou střední cestu schopností clusteru v aktuálním okamžiku. To je o to obtížnější, čím více různých řešení se dnes na trhu klastrů nabízí.Při přípravě článku byly použity materiály z WWW serverů: http://www.dell.ru/ , http://www.compaq .ru/ , http:// www.ibm.ru/ , http://www.parallel.ru/ , http://www.giganet.com/ , http://www.myri.com/

ComputerPress 10"2000

Blue Gene /L a rodina SGI Altix.

Za základní software pro organizování výpočtů na clusterových systémech je považován Windows Compute Cluster Server (CCS) 2003. Je uvedena jeho obecná charakteristika a skladba služeb běžících na uzlech clusteru.

Na konci této části jsou uvedena pravidla pro práci s konzolou spuštění CCS a řízení úloh. Popisuje podrobnosti o tom, jak pracuje plánovač CCS při provádění sekvencí úloh v klastru.

1.1. Architektura vysoce výkonných procesorů a clusterových systémů

V historii vývoje architektury počítačových procesorů lze rozlišit dvě hlavní etapy:

Fáze 1 - zvýšení taktovací frekvence procesorů (až 2000),
2. etapa - vznik vícejádrových procesorů (po roce 2000)

Přístup založený na SMP ( Symmetrical MultiProcessing ), který byl vyvinut při budování vysoce výkonných serverů, ve kterých několik procesorů sdílí systémové prostředky, a především RAM (viz obr. 1.1), se tak posunul „dolů“ na úroveň jader uvnitř procesoru.

Rýže. 1.1.

Na cestě k vícejádrovým procesorům se jako první objevila technologie Hyper-Threading, která byla poprvé použita v roce 2002 v procesorech Intel Pentium 4:

Rýže. 1.2.

V této technologii dva virtuální procesory sdílejí všechny prostředky jednoho fyzického procesoru, konkrétně mezipaměti, spouštěcí kanál a jednotlivé prováděcí jednotky. Současně, pokud jeden virtuální procesor obsadil sdílený prostředek, pak druhý bude čekat na jeho uvolnění. Procesor s Hyper-Threading lze tedy přirovnat k multitaskingovému operačnímu systému, který každému procesu v něm běžícímu poskytuje vlastní virtuální počítač s plnou sadou nástrojů a na fyzickém hardwaru plánuje pořadí a čas těchto procesů. Pouze v případě Hyper-Threading se vše děje na mnohem nižší hardwarové úrovni. Dva toky instrukcí však umožňují efektivnější načítání prováděcích jednotek procesoru. Reálný nárůst výkonu procesoru z použití technologie Hyper-Threading se odhaduje na 10 až 20 procent.

Plnohodnotný dvoujádrový procesor (viz obrázek 1.3) vykazuje u některých úloh nárůst výkonu o 80 až 100 procent.

Rýže. 1.3.

Dvoujádrový a obecně vícejádrový procesor lze tedy považovat za miniaturní SMP systém, který nepotřebuje složité a drahé víceprocesorové základní desky.

Každé jádro navíc může (jako například u procesoru Intel Pentium Extreme Edition 840) podporovat technologii Hyper-Threading, a proto tento druh dvoujádrového procesoru může spouštět čtyři programová vlákna současně.

Na začátku roku 2007 Intel představil 80jádrový jednočipový procesor s názvem Teraflops Research Chip (http://www.intel.com/research/platform/terascale/teraflops.htm). Tento procesor dokáže dosáhnout výkonu 1,01 teraflopu s minimálním taktem jádra 3,16 GHz a napětím 0,95 V. spotřeba energiečip je pouze 62 wattů.

Podle prognóz Intelu se v příštích 5 letech objeví komerční varianty procesorů s velkým počtem jader a do roku 2010 bude mít čtvrtina objemu všech dodaných serverů teraflop. výkon.

Clusterové výpočetní systémy a jejich architektura

shluk je lokální (geograficky umístěný na jednom místě) výpočetní systém, který se skládá z mnoha nezávislých počítačů a sítě, která je spojuje. Cluster je navíc lokální systém, protože je spravován v rámci samostatné administrativní domény jako jeden počítačový systém.

počítačové uzly ze kterých se skládá, jsou standardní, univerzální (osobní) počítače používané v různých oblastech a pro různé aplikace. Výpočetní uzel může obsahovat buď jeden mikroprocesor nebo několik mikroprocesorů, které tvoří v druhém případě symetrickou (SMP-) konfiguraci.

Síťovou složkou clusteru může být buď konvenční lokální síť, nebo může být postavena na základě speciálních síťových technologií, které poskytují ultrarychlý přenos dat mezi uzly clusteru. Síť clusteru je navržena tak, aby integrovala uzly clusteru a je obvykle oddělena od externí sítě, přes kterou uživatelé přistupují ke clusteru.

Clusterový software se skládá ze dvou komponent:

vývojové/programovací nástroje a
nástroje pro správu zdrojů.

Vývojové nástroje zahrnují kompilátory jazyků, knihovny pro různé účely, nástroje pro měření výkonu a debuggery, které dohromady umožňují vytvářet paralelní aplikace.

Software pro správu zdrojů zahrnuje nástroje pro instalaci, správu a plánování pracovních postupů.

Přestože existuje mnoho programovacích modelů pro paralelní zpracování, v současnosti je dominantním přístupem model předávání zpráv, implementovaný ve formě standardu MPI (Message Passing Interface). MPI je knihovna funkcí, které lze použít v programech C nebo Fortran k odesílání zpráv mezi paralelními procesy a také k řízení těchto procesů.

Alternativou k tomuto přístupu jsou jazyky založené na tzv. globálním rozděleném adresním prostoru (GPAS), jehož typickými představiteli jsou jazyky HPF (High Performance Fortran) a UPC (Unified Parallel C).

Několik úvah o tom, kdy má smysl používat clustery s vysokou dostupností k ochraně aplikací.

Jedním z hlavních úkolů provozu IT systému v jakémkoli podniku je zajištění kontinuity poskytované služby. Inženýři i IT lídři však velmi často nemají zcela jasno v tom, jaká „kontinuita“ je konkrétně vyjádřena v jejich podnikání. Dle názoru autora je to dáno nejednoznačností a vágností samotného pojmu kontinuita, proto nelze vždy jednoznačně říci, které diskretizační období je považováno za spojité a který interval bude intervalem nedostupnosti. Situaci zhoršuje množství technologií navržených tak, aby nakonec vyřešily jeden společný problém, ale různými způsoby.

Jaká technologie by měla být zvolena v každém konkrétním případě pro vyřešení úkolů stanovených v rámci dostupného rozpočtu? V tomto článku se blíže podíváme na jeden z nejpopulárnějších přístupů k ochraně aplikací, a to zavedení hardwarové a softwarové redundance, tedy budování clusteru s vysokou dostupností. Tento úkol je i přes zdánlivou jednoduchost implementace ve skutečnosti velmi náročný na doladění a obsluhu. Kromě popisu známých konfigurací se pokusíme ukázat, jaké další funkce - nepříliš často používané - jsou v takových řešeních dostupné, jak jsou uspořádány různé implementace clusterů. Navíc je často žádoucí, aby zákazník, když vážně zvážil všechny výhody klastrového přístupu, měl stále na paměti jeho nevýhody, a proto zvážil celou škálu možných řešení.

Co ohrožuje aplikace...

Podle různých odhadů je 55–60 % aplikací kritických pro podnikání společnosti – to znamená, že absence služby, kterou tyto aplikace poskytují, vážně ovlivní finanční blaho společnosti. V tomto ohledu se pojem přístupnost stává základním aspektem činnosti výpočetního střediska. Podívejme se, odkud pocházejí hrozby pro dostupnost aplikací.

Zničení dat. Jedním z hlavních problémů je dostupnost služby. Nejjednodušší způsob, jak se chránit, je pořizovat časté „snímky“ dat, abyste se mohli kdykoli vrátit ke kompletní kopii.

Selhání hardwaru. Výrobci hardwarových systémů (servery, disková úložiště) vyrábějí řešení s redundantními součástmi – procesorové desky, systémové řadiče, napájecí zdroje atd. V některých případech však může selhání hardwaru vést k nedostupnosti aplikací.

Chyba v aplikaci. Chyba programátora v aplikaci, která již byla otestována a uvedena do výroby, se může v jednom případě projevit v desítkách či dokonce stovkách tisíc, pokud však k takovému incidentu skutečně dojde, vede k přímé ztrátě zisku organizace, neboť transakce zpracování se zastaví a způsob odstranění chyby není zřejmý a vyžaduje čas.

Lidská chyba. Jednoduchý příklad: správce provede změny v konfiguračních souborech, jako je DNS. Když otestuje změny, služba DNS funguje, ale služba, která používá DNS, jako je e-mail, začne mít problémy, které nejsou okamžitě detekovány.

Naplánovaná údržba.Údržba systému – výměna komponent, instalace aktualizací Service Pack, restartování – je hlavní příčinou nedostupnosti. Gartner odhaduje, že 80 % případů, kdy je systém nedostupný, je plánovaná odstávka.

Obecné problémy na výpočetní platformě. I když organizace udělá vše pro to, aby se ochránila před místními problémy, nezaručuje to dostupnost služby, pokud je z nějakého důvodu nedostupná celá stránka. I to je třeba vzít v úvahu při plánování systému.

...a jak se s tím vypořádat

V závislosti na kritičnosti úlohy lze použít následující mechanismy pro obnovení stavu výpočetního systému.

Záloha data na pásku nebo disk. To je základní úroveň dostupnosti – nejjednodušší, nejlevnější, ale také nejpomalejší.

lokální zrcadlení. Poskytuje dostupnost dat v reálném čase, data jsou chráněna před zničením.

Lokální shlukování. Jakmile je zorganizována ochrana dat, dalším krokem k zajištění dostupnosti aplikací je místní shlukování, tedy vytvoření redundance z hlediska hardwaru i softwaru.

vzdálená replikace. Předpokládá oddělení výpočetních míst za účelem vytvoření kopie dat v oddělených datových centrech.

Vzdálené shlukování. Protože je zajištěna dostupnost dat na různých místech, je také možné udržovat dostupnost služby z různých míst organizováním přístupu aplikací k těmto datům.

Nebudeme se zde zabývat popisem všech těchto metod, protože každá položka se může stát tématem samostatného článku. Myšlenka je jasná – čím více redundance zavedeme, tím vyšší bude cena řešení, ale tím lépe budou aplikace chráněny. Pro každou z výše uvedených metod existuje arzenál řešení od různých výrobců, ale s typickou sadou funkcí. Pro projektanta řešení je velmi důležité mít na paměti všechny tyto technologie, protože pouze jejich kompetentní kombinace povede k vyčerpávajícímu řešení zadání zadaného zákazníkem.

Podle názoru autora je přístup Symantecu velmi úspěšný pro pochopení strategie obnovy služeb (obr. 1). Jsou zde dva klíčové body – bod, ve kterém je systém obnoven (cíl bodu obnovení, RPO) a čas potřebný k obnovení služby (cíl doby obnovení, RTO).

Výběr jednoho nebo druhého nástroje závisí na konkrétních požadavcích, které se vztahují na kritickou aplikaci nebo databázi.

U nejkritičtějších systémů by RTO a RPO neměly přesáhnout 1 hod. Páskové systémy poskytují bod obnovy dva nebo více dní. Obnova pásky navíc není automatizovaná, administrátor si musí neustále pamatovat, že vše správně obnovil a spustil.

Navíc, jak již bylo zmíněno, při plánování schématu dostupnosti jeden nástroj nestačí. Například stěží má smysl používat pouze replikační systém. I když jsou důležitá data umístěna na vzdáleném místě, aplikace musí být spouštěny ručně ve správném pořadí. Replikaci bez automatického spouštění aplikací lze tedy považovat za jakousi drahou zálohu.

Pokud chcete poskytovat RTO a RTS měřené v minutách, tedy úkol vyžaduje minimalizaci prostojů (plánovaných i neplánovaných), pak je jediným správným řešením cluster s vysokou dostupností. V tomto článku jsou takové systémy zvažovány.

Vzhledem k tomu, že pojem „výpočetní cluster“ je již nějakou dobu přetěžován kvůli své velké rozmanitosti, nejprve si řekneme něco málo o tom, co jsou clustery.

Typy klastrů

Ve své nejjednodušší podobě je cluster systém počítačů, které spolupracují na společném řešení problémů. Nejedná se o model zpracování dat klient-server, kde lze aplikaci logicky oddělit tak, aby klienti mohli odesílat požadavky na různé servery. Myšlenkou klastru je sdružovat výpočetní zdroje souvisejících uzlů za účelem vytvoření redundantních zdrojů, které poskytují větší sdílený výpočetní výkon, vysokou dostupnost a škálovatelnost. Clustery tedy nezpracovávají pouze požadavky klientů na servery, ale současně využívají mnoho počítačů, prezentují je jako jeden systém a poskytují tak výrazně vyšší výpočetní schopnosti.

Shluk počítačů musí být samoorganizující se systém – práce vykonávaná na jednom z uzlů musí být koordinována s prací na ostatních uzlech. To vede ke složitosti konfiguračních vztahů, obtížné komunikaci mezi uzly clusteru a nutnosti řešit problém přístupu k datům ve společném souborovém systému. Existují také provozní problémy spojené s provozem potenciálně velkého počtu počítačů jako jediného zdroje.

Shluky mohou existovat v různých formách. Nejběžnějšími typy clusterů jsou vysoce výkonné výpočty (HPC) a vysoká dostupnost (HA).

Vysoce výkonné výpočetní clustery využívají k vyřešení problému paralelní výpočetní metody za účasti co největšího výkonu procesoru. Existuje mnoho příkladů takových řešení ve vědeckých výpočtech, kde se paralelně používá mnoho levných procesorů k provádění velkého počtu operací.

Tématem tohoto článku jsou však systémy s vysokou dostupností. Proto dále, když mluvíme o shlucích, budeme mít na mysli právě takové systémy.

Při budování clusterů s vysokou dostupností se zpravidla využívá redundance k vytvoření spolehlivého prostředí, tj. vytvoří se výpočetní systém, ve kterém výpadek jedné nebo více komponent (hardwaru, softwaru nebo síťových zařízení) výrazně neovlivní dostupnost aplikace nebo systém obecně.

V nejjednodušším případě se jedná o dva shodně nakonfigurované servery s přístupem do sdíleného úložného systému (obr. 2). Během normálního provozu běží aplikační software na jednom systému, zatímco druhý systém čeká na spuštění aplikací, když první systém selže. Když je zjištěna porucha, druhý systém přepne příslušné zdroje (systém souborů, síťové adresy atd.). Tento proces se běžně nazývá převzetí služeb při selhání. Druhý systém zcela nahrazuje ten neúspěšný a uživatel nemusí vědět, že jeho aplikace běží na různých fyzických strojích. Toto je nejběžnější dvouuzlová asymetrická konfigurace, kdy jeden server je aktivní, druhý pasivní, to znamená, že je v pohotovostním stavu pro případ výpadku hlavního. V praxi toto schéma funguje ve většině společností.

Je však třeba si položit otázku: jak přijatelné je ponechat si doplňkovou sadu vybavení, která je skutečně v záloze a většinu času se nepoužívá? Problém s vyloženým zařízením je vyřešen změnou schématu clusteru a alokací zdrojů v něm.

Konfigurace clusteru

Kromě výše zmíněné dvouuzlové asymetrické struktury clusteru existují možnosti, že různí výrobci clusterového softwaru mohou mít různá jména, ale jejich podstata je stejná.

Symetrický shluk

Symetrický cluster se také provádí na dvou uzlech, ale na každém z nich běží aktivní aplikace (obr. 3). Clusterový software zajišťuje správný automatický přechod aplikace ze serveru na server v případě selhání jednoho z uzlů. V tomto případě je zatížení hardwaru efektivnější, ale pokud dojde k poruše, ukáže se, že aplikace celého systému běží na jednom serveru, což může mít nežádoucí důsledky z hlediska výkonu. Kromě toho je třeba zvážit, zda je možné provozovat více aplikací na stejném serveru.

Konfigurace N+1

Tato konfigurace již obsahuje více než dva uzly a mezi nimi je jeden vyhrazený, redundantní (obr. 4). Jinými slovy, na každých N běžících serverů existuje jeden hot standby. V případě poruchy se aplikace „přesune“ z problémového uzlu do vyhrazeného volného uzlu. V budoucnu bude moci správce clusteru nahradit neúspěšný uzel a označit jej jako pohotovostní.

Varianta N+1 je méně flexibilní konfigurace N na 1, kde pohotovostní uzel zůstává vždy stejný pro všechny pracovní uzly. Pokud aktivní server vypadne, služba se přepne do pohotovostního režimu a systém zůstane bez zálohy, dokud nebude aktivován uzel, který selhal.

Ze všech konfigurací clusteru je N + 1 pravděpodobně nejúčinnější z hlediska složitosti a účinnosti zařízení. Tabulka níže. 1 tento odhad potvrzuje.

Konfigurace N až N

Jedná se o nejefektivnější konfiguraci z hlediska využití výpočetních zdrojů (obr. 5). Všechny servery v něm fungují, na každém běží aplikace, které jsou součástí clusterového systému. Pokud dojde k selhání na jednom z uzlů, aplikace se z něj přesunou v souladu se zavedenými zásadami na zbývající servery.

Při návrhu takového systému je nutné vzít v úvahu kompatibilitu aplikací, jejich připojení při „přechodu“ z uzlu na uzel, zatížení serveru, šířku pásma sítě a mnoho dalšího. Tato konfigurace je nejsložitější z hlediska návrhu a provozu, ale poskytuje největší hodnotu pro váš hardware při použití clusterové redundance.

Posouzení klastrových konfigurací

V tabulce. 1 shrnuje to, co bylo řečeno výše o různých konfiguracích clusteru. Hodnocení se provádí na čtyřbodové škále (4 - nejvyšší skóre, 1 - nejnižší).

Od stolu. 1 je vidět, že klasický asymetrický systém je z hlediska konstrukce a provozu nejjednodušší. A pokud to může zákazník provozovat samostatně, pak by bylo správné převést zbytek na externí údržbu.

Na závěr, když mluvíme o konfiguracích, rád bych řekl pár slov o kritériích, podle kterých může jádro clusteru automaticky dát příkaz k „přesunu“ aplikace z uzlu do uzlu. Naprostá většina administrátorů v konfiguračních souborech definuje pouze jedno kritérium – nedostupnost jakékoli součásti uzlu, tedy softwarovou a hardwarovou chybu.

Mezitím moderní clusterový software poskytuje schopnost vyrovnávat zátěž. Pokud zatížení jednoho z uzlů dosáhne kritické hodnoty, při správně nakonfigurované politice se aplikace na něm správně vypne a spustí na jiném uzlu, kde to aktuální zatížení umožňuje. Nástroje pro řízení zátěže serveru mohou být navíc statické – aplikace v konfiguračním souboru clusteru sama uvádí, kolik zdrojů potřebuje – a dynamické, když je nástroj pro vyrovnávání zátěže integrován s externím nástrojem (například Precise), který vypočítává aktuální zatížení systému.

Abychom nyní porozuměli tomu, jak clustery fungují v konkrétních implementacích, podívejme se na hlavní součásti jakéhokoli systému s vysokou dostupností.

Hlavní komponenty clusteru

Jako každý složitý komplex se klastr bez ohledu na konkrétní implementaci skládá z hardwarových a softwarových komponent.

Pokud jde o zařízení, na kterém je cluster sestavován, je zde hlavní součástí meziuzlové propojení nebo interní propojení clusteru, které zajišťuje fyzické a logické propojení serverů. V praxi se jedná o vnitřní ethernetovou síť s duplicitními připojeními. Jeho účelem je za prvé přenos paketů potvrzujících integritu systému (tzv. srdeční tep), za druhé při určité konstrukci nebo schématu, které vznikly po poruše, výměna informačního provozu mezi uzly určenými k přenosu. mimo. Další součásti jsou zřejmé: uzly, na kterých běží OS se softwarem clusteru, disková úložiště, ke kterým mají uzly clusteru přístup. A konečně společná síť, jejímž prostřednictvím klastr interaguje s vnějším světem.

Softwarové komponenty poskytují kontrolu nad provozem klastrové aplikace. Za prvé, je to sdílený OS (ne nutně sdílená verze). V prostředí tohoto OS funguje jádro clusteru – clusterový software. Ty aplikace, které jsou clusterované, tedy mohou migrovat z uzlu na uzel, jsou řízeny – spouštěny, zastavovány, testovány – pomocí malých skriptů, tzv. agentů. Pro většinu úloh existují standardní agenti, ale ve fázi návrhu je nezbytné zkontrolovat matici kompatibility, abyste zjistili, zda existují agenti pro konkrétní aplikace.

Implementace klastrů

Na softwarovém trhu existuje mnoho implementací výše popsaných clusterových konfigurací. Téměř všichni významní výrobci serverů a softwaru – například Microsoft, HP, IBM, Sun, Symantec – nabízejí své produkty v této oblasti. Microtest má zkušenosti s řešeními Sun Cluster Server (SC) od Sun Microsystems (www.sun.com) a Veritas Cluster Server (VCS) od společnosti Symantec (www.symantec.com). Z pohledu správce jsou si tyto produkty z hlediska funkčnosti velmi podobné – poskytují stejné nastavení a reakce na události. Z hlediska jejich vnitřní organizace se však jedná o zcela odlišné produkty.

SC byl vyvinut společností Sun pro svůj vlastní OS Solaris, a proto běží pouze na tomto OS (jak SPARC, tak x86). Výsledkem je, že během instalace je SC hluboce integrován s OS a stává se jeho součástí, součástí jádra Solaris.

VCS je multiplatformní produkt, který pracuje s téměř všemi aktuálně populárními operačními systémy - AIX, HP-UX, Solaris, Windows, Linux a je doplňkem - aplikací, která řídí provoz dalších aplikací, které podléhají clusteringu. .

Podíváme se na vnitřní implementaci těchto dvou systémů – SC a VCS. Ještě jednou ale zdůrazňujeme, že i přes odlišnost terminologie a zcela odlišnou vnitřní strukturu jsou hlavní součásti obou systémů, se kterými správce interaguje, v podstatě stejné.

Softwarové součásti serveru Sun Cluster

Jádrem SC (obrázek 6) je operační systém Solaris 10 (nebo 9) s přídavným shellem, který poskytuje funkci vysoké dostupnosti (jádro je zvýrazněno zeleně). Další jsou globální komponenty (světle zelené), které poskytují své služby odvozené od jádra clusteru. A nakonec úplně nahoře – zakázkové komponenty.

HA framework je komponenta, která rozšiřuje jádro Solaris o poskytování klastrových služeb. Úloha rámce začíná inicializací kódu, který spouští uzel do režimu clusteru. Hlavními úkoly frameworku jsou interakce mezi uzly, řízení stavu clusteru a členství v něm.

Komunikační modul mezi jednotlivými uzly přenáší zprávy o srdečním tepu mezi uzly. Jedná se o krátké zprávy potvrzující odpověď sousedního uzlu. Interakce dat a aplikací je také řízena rámcem HA jako součást meziuzlové komunikace. Kromě toho framework spravuje integritu klastrované konfigurace a v případě potřeby provádí úlohy obnovy a aktualizace. Integrita je udržována prostřednictvím zařízení kvora; v případě potřeby se provede rekonfigurace. Zařízení kvora je dalším mechanismem pro kontrolu integrity uzlů clusteru prostřednictvím malých částí sdíleného systému souborů. Nejnovější verze clusteru SC 3.2 zavedla možnost přiřadit zařízení kvora mimo systém clusteru, to znamená použít další server na platformě Solaris, přístupný přes TCP/IP. Selhali členové klastru jsou odebráni z konfigurace. Prvek, který bude opět funkční, je automaticky zahrnut do konfigurace.

Funkce globálních komponent jsou odvozeny od rámce HA. Tyto zahrnují:

globální zařízení se společným jmenným prostorem klastrových zařízení;
globální souborová služba, která organizuje přístup ke každému souboru v systému pro každý uzel, jako by byl v jeho vlastním lokálním souborovém systému;
globální síťová služba, která poskytuje vyrovnávání zátěže a možnost přístupu ke klastrovým službám prostřednictvím jediné IP adresy.

Vlastní komponenty spravují klastrové prostředí na nejvyšší úrovni aplikačního rozhraní. Spravovat je možné jak přes grafické rozhraní, tak přes příkazový řádek. Moduly, které sledují chod aplikací, spouštějí je a zastavují, se nazývají agenti. Existuje knihovna hotových agentů pro standardní aplikace; Tento seznam roste s každým vydáním.

Softwarové komponenty Veritas Cluster Server

Schematicky je na obr. 2 znázorněn dvouuzlový VCS cluster. 7. Meziuzlová komunikace ve VCS je založena na dvou protokolech - LLT a GAB. VCS používá vnitřní síť k udržení integrity clusteru.

LLT (Low Latency Transport) je protokol vyvinutý společností Veritas, který běží přes Ethernet jako vysoce efektivní náhrada za IP stack a je používán uzly ve všech interních komunikacích. Požadovaná redundance v meziuzlové komunikaci vyžaduje alespoň dvě zcela nezávislé vnitřní sítě. To je nezbytné, aby VSC mohl rozlišit mezi selháním sítě a systému.

Protokol LLT plní dvě hlavní funkce: distribuci provozu a odesílání prezenčního signálu. LLT rozděluje (vyrovnává) komunikaci mezi uzly mezi všechny dostupné vnitřní linky. Toto schéma zajišťuje, že veškerý interní provoz je náhodně distribuován mezi vnitřní sítě (může jich být maximálně osm), což zlepšuje výkon a odolnost proti chybám. V případě výpadku jednoho odkazu budou data přesměrována na zbývající ostatní. Kromě toho je LLT odpovědný za odesílání srdečního provozu přes síť, kterou používá GAB.

GAB (Group Membership Services/Atomic Broadcast) je druhý protokol používaný ve VCS pro interní komunikaci. Stejně jako LLT má na starosti dva úkoly. Prvním je členství uzlů v clusteru. GAB přijímá srdeční tep z každého uzlu prostřednictvím LLT. Pokud systém delší dobu nepřijímá odpověď z uzlu, pak označí svůj stav jako DOWN - nefunkční.

Druhou funkcí GAB je poskytovat spolehlivou komunikaci mezi skupinami. GAB poskytuje garantované doručování vysílání a zpráv typu point-to-point mezi všemi uzly.

Řídicí komponentou VCS je VCS engine, neboli HAD (High Availability daemon), běžící na každém systému. Je zodpovědná za:

vytváření pracovních konfigurací získaných z konfiguračních souborů;
distribuce informací mezi nové uzly připojující se ke clusteru;
zpracování vstupu od správce (operátora) clusteru;
provádění rutinních akcí v případě selhání.

HAD používá agenty ke sledování a správě zdrojů. Informace o stavu zdrojů se shromažďují od agentů v místních systémech a přenášejí se všem členům clusteru. HAD každého uzlu přijímá informace od ostatních uzlů a aktualizuje svůj vlastní obrázek o celém systému. HAD funguje jako replikovaný stavový stroj RSM, tj. jádro na každém uzlu má obrázek o stavu zdrojů, který je plně synchronizován se všemi ostatními uzly.

Cluster VSC je spravován buď prostřednictvím konzoly Java nebo prostřednictvím webu.

co je lepší

Otázku, kdy který cluster je lepší použít, jsme již probrali výše. Znovu zdůrazňujeme, že produkt SC byl napsán společností Sun pro svůj vlastní operační systém a je s ním hluboce integrován. VCS je multiplatformní produkt, a proto je flexibilnější. V tabulce. 2 porovnává některé možnosti těchto dvou řešení.

Na závěr si dovolím uvést ještě jeden argument ve prospěch použití SC v prostředí Solaris. S využitím hardwaru i softwaru od jediného výrobce – Sun Microsystems, získává zákazník službu „single window“ pro celé řešení. Navzdory skutečnosti, že prodejci nyní vytvářejí společná kompetenční centra, čas pro vysílání požadavků mezi výrobci softwaru a hardwaru sníží rychlost reakce na incident, což ne vždy vyhovuje uživateli systému.

Teritoriálně distribuovaný cluster

Podívali jsme se na to, jak je sestaven a provozován cluster s vysokou dostupností v rámci jednoho webu. Taková architektura může chránit pouze před lokálními problémy v rámci jednoho uzlu a s ním souvisejících dat. V případě problémů zasahujících celou lokalitu, ať už technických, přírodních či jiných, bude celý systém nepřístupný. V dnešní době vyvstává stále více úkolů, jejichž kritičnost vyžaduje zajištění migrace služeb nejen v rámci lokality, ale i mezi geograficky rozptýlenými datovými centry. Při navrhování takových řešení je třeba vzít v úvahu nové faktory - vzdálenost mezi místy, šířku pásma kanálu atd. Která replikace by měla být preferována - synchronní nebo asynchronní, znamená hostitel nebo pole, jaké protokoly by měly být použity? Úspěch projektu může záviset na řešení těchto problémů.

Replikace dat z hlavního místa na místo zálohy se nejčastěji provádí pomocí některého z oblíbených balíčků: Veritas Volume Replicator, EMC SRDF, Hitachi TrueCopy, Sun StorageTek Availability Suite.

V případě selhání hardwaru nebo problému s aplikací nebo databází se klastrový software nejprve pokusí přesunout aplikační službu do jiného uzlu na hlavní lokalitě. Pokud se primární web z jakéhokoli důvodu stane nedostupným pro vnější svět, všechny služby, včetně DNS, migrují na záložní web, kde jsou již data kvůli replikaci přítomna. Pro uživatele je tak služba obnovena.

Nevýhodou tohoto přístupu jsou obrovské náklady na nasazení další „horké“ lokality s vybavením a síťovou infrastrukturou. Výhoda úplné ochrany však může tyto dodatečné náklady převážit. Pokud centrální uzel není schopen poskytovat služby po dlouhou dobu, může to vést k velkým ztrátám a dokonce ke smrti podniku.

Test systému před katastrofou

Podle studie společnosti Symantec pouze 28 % společností testuje plán obnovy po havárii. Bohužel většina zákazníků, se kterými měl autor o této problematice mluvit, takový plán vůbec neměla. Důvody, proč se testování nedělá, je nedostatek času pro administrátory, neochota dělat to na „živém“ systému a nedostatek testovacího vybavení.

Pro testování můžete použít simulátor, který je součástí balíčku VSC. Uživatelé, kteří se rozhodnou používat VCS jako svůj clusterový software, mohou otestovat svá nastavení na Cluster Server Simulator, který jim umožňuje otestovat strategii migrace aplikací mezi uzly na PC.

Závěr

Úkol poskytovat službu s vysokou dostupností je velmi nákladný jak z hlediska nákladů na hardware a software, tak z hlediska nákladů na další údržbu a technickou podporu systému. Přes zdánlivou jednoduchost teorie a jednoduchou instalaci se clusterový systém při hloubkovém prostudování ukazuje jako složité a drahé řešení. V tomto článku byla technická stránka systému posouzena pouze obecně, přičemž o určitých otázkách clusteru, například určení členství v něm, by se dal napsat samostatný článek.

Clustery jsou obvykle vytvářeny pro kritické obchodní úkoly, kde jednotka výpadku vede k velkým ztrátám, například u fakturačních systémů. Dalo by se doporučit následující pravidlo, které určuje, kde je rozumné clustery používat: tam, kde by prostoj služby neměl přesáhnout hodinu a půl, je cluster vhodným řešením. V ostatních případech můžete zvážit levnější možnosti.

Nejprve je třeba určit, komu je článek určen, aby se čtenáři rozhodli, zda se mu vyplatí věnovat čas.

Potřeba napsat tento článek vyvstala po přečtení semináře na výstavě ENTEREX'2002 v Kyjevě. Tehdy, na začátku roku 2002, jsem viděl, že zájem o téma klastrových systémů výrazně vzrostl ve srovnání s tím, co bylo pozorováno jen před několika lety.

Na semináři jsem si nedal za cíl a v tomto článku rozebrat možnosti řešení konkrétních aplikovaných problémů na klastrových systémech, to je samostatné a velmi rozsáhlé téma. Dal jsem si za úkol seznámit čtenáře s terminologií a nástroji pro budování clusterových systémů a také ukázat, pro jaké úlohy je clustering užitečný. Abych plně přesvědčil pochybovače, uvádím v článku konkrétní příklady implementace klastrových systémů a mé kontakty, na kterých jsem připraven v rámci možností zodpovědět dotazy související s klastrovými technologiemi a přijmout i vaše připomínky a rady.

Koncept klastrových systémů

Obrázek 1. Clusterový systém

LAN - Local Area Network, místní síť
SAN - Storage Area Network, storage area network

Poprvé v klasifikaci výpočetních systémů byl termín „cluster“ definován společností Digital Equipment Corporation (DEC).

Podle definice DEC je cluster skupina počítačů, které jsou vzájemně propojeny a fungují jako jeden uzel pro zpracování informací.

Cluster funguje jako jeden systém, to znamená, že pro uživatele nebo aplikovaný úkol vypadá celý soubor výpočetní techniky jako jeden počítač. To je nejdůležitější při budování klastrového systému.

První clustery Digital byly postaveny na strojích VAX. Tyto stroje se již nevyrábějí, ale jsou stále v provozu na místech, kde byly instalovány před mnoha lety. A možná nejdůležitější je, že obecné principy stanovené v jejich návrhu zůstávají základem pro budování clusterových systémů i dnes.

Obecné požadavky na klastrové systémy zahrnují:

Vysoká dostupnost
Vysoký výkon
Měřítko
Sdílení zdrojů
Obslužnost

U soukromých implementací jsou samozřejmě některé požadavky kladeny do popředí, zatímco jiné ustupují do pozadí. Takže například při implementaci clusteru, pro který je nejdůležitější rychlost, se v zájmu úspory zdrojů věnuje menší pozornost vysoké dostupnosti.

V obecném případě cluster funguje jako víceprocesorový systém, proto je důležité porozumět klasifikaci takových systémů v rámci distribuce softwarových a hardwarových zdrojů.

Obrázek 2. Pevně propojený víceprocesorový systém

Obrázek 3. Středně propojený víceprocesorový systém

Obrázek 4 Volně připojený víceprocesorový systém

Platformy PC, se kterými pracuji, obvykle používají implementace klastrových systémů v modelech úzce provázaných a středně propojených víceprocesorových architektur.

Rozdělení na systémy High Avalability a High Performance

Ve funkční klasifikaci lze klastry rozdělit na „High Performance“ (HP), „High Availability“ (HA) a „Mixed Systems“.

Vysokorychlostní clustery se používají pro úlohy, které vyžadují značný výpočetní výkon. Klasické oblasti, ve kterých se tyto systémy používají, jsou:

zpracování obrazu: rendering, rozpoznávání vzorů
vědecký výzkum: fyzika, bioinformatika, biochemie, biofyzika
průmysl (geoinformační úlohy, matematické modelování)

a mnoho dalších…

Clustery, což jsou systémy s vysokou dostupností, se používají všude tam, kde náklady na možné prostoje převyšují náklady na náklady nutné k vybudování clusterového systému, například:

fakturační systémy
Bankovní operace
elektronický obchod
řízení podniku atd...

Smíšené systémy kombinují vlastnosti prvního i druhého. Při jejich umístění je třeba poznamenat, že cluster, který má parametry High Performance i High Availability, definitivně ztratí na výkonu ve srovnání se systémem zaměřeným na vysokorychlostní výpočty a v případných prostojích na systém zaměřený na vysokou dostupnost.

Problémy vysoce výkonných klastrů

Obrázek 5. Vysokorychlostní cluster

Téměř v jakékoli paralelně orientované úloze se nelze vyhnout nutnosti přenášet data z jedné dílčí úlohy do druhé.

Výkon klastrového systému s vysokým výkonem je tedy určen výkonem uzlů a vazeb mezi nimi. Navíc vliv rychlostních parametrů těchto spojení na celkový výkon systému závisí na povaze prováděné úlohy. Pokud úloha vyžaduje častou výměnu dat s dílčími úlohami, pak je třeba věnovat maximální pozornost rychlosti komunikačního rozhraní. Přirozeně, čím méně částí paralelního úkolu se vzájemně ovlivňují, tím méně času zabere jeho dokončení. Což diktuje určité požadavky také na programování paralelních úloh.

Hlavní problémy s nutností výměny dat mezi dílčími úlohami vznikají v důsledku skutečnosti, že rychlost přenosu dat mezi centrálním procesorem a RAM uzlu výrazně převyšuje rychlostní charakteristiky systémů interakce počítač-počítač. Rozdíl v rychlosti mezipaměti procesoru a meziuzlové komunikace navíc výrazně ovlivňuje změnu ve fungování systému ve srovnání s nám známými SMP systémy.

Rychlost rozhraní charakterizují dva parametry: propustnost kontinuálního datového toku a maximální počet nejmenších paketů, které lze přenést za jednotku času. Možnosti implementace komunikačních rozhraní zvážíme v části „Implementační nástroje pro vysoce výkonné clustery“.

Problémy klastrových systémů s vysokou dostupností

Dnes je ve světě běžných několik typů systémů s vysokou dostupností. Mezi nimi je clusterový systém ztělesněním technologií, které poskytují nejvyšší úroveň odolnosti proti chybám při nejnižších nákladech. Přepnutí při selhání klastru je zajištěno duplikací všech důležitých komponent. Systém nejvíce odolný proti poruchám by neměl mít jediný bod, tedy aktivní prvek, jehož porucha může vést ke ztrátě funkčnosti systému. Tato charakteristika se obvykle nazývá - NSPF (No Single Point of Failure, - anglicky absence jediného bodu selhání).

Obrázek 6. Klastrový systém bez bodů selhání

Při budování systémů s vysokou dostupností je hlavním cílem zajistit minimální prostoje.

Aby měl systém vysoké indikátory připravenosti, je nutné:

aby jeho součásti byly co nejspolehlivější
aby byl odolný vůči chybám, je žádoucí, aby neměl body selhání
a je také důležité, aby se snadno udržoval a umožňoval výměnu součástí bez zastavení

Zanedbání některého ze specifikovaných parametrů může vést ke ztrátě funkčnosti systému.

Pojďme si krátce projít všechny tři body.

Pokud jde o zajištění maximální spolehlivosti, je prováděno pomocí elektronických součástek vysoké a ultra vysoké integrace, při zachování normálních provozních režimů, včetně tepelných.

Odolnost proti chybám je zajištěna použitím specializovaných komponent (ECC, paměťové moduly Chip Kill, napájecí zdroje odolné proti chybám atd.) a také využitím technologií shlukování. Díky shlukování je dosaženo takového fungujícího schématu, kdy se v případě výpadku jednoho z počítačů úkoly přerozdělí mezi ostatní správně fungující uzly clusteru. Kromě toho je jedním z nejdůležitějších úkolů výrobců klastrového softwaru zajistit minimální dobu obnovy systému v případě selhání, protože tolerance systémových chyb je potřebná právě pro minimalizaci takzvaných neplánovaných prostojů.

Mnoho lidí zapomíná, že jedním z nejdůležitějších parametrů systémů s vysokou dostupností je snadná údržba, která slouží ke snížení plánovaných prostojů (například výměna vadného zařízení). A pokud systém neumožňuje výměnu komponent bez vypnutí celého komplexu, pak se faktor jeho dostupnosti snižuje.

smíšené architektury

Obrázek 7. Vysokorychlostní Failover Cluster

Dnes můžete často najít smíšené klastrové architektury, což jsou jak systémy s vysokou dostupností, tak i vysokorychlostní klastrové architektury, ve kterých jsou aplikační úlohy distribuovány mezi systémové uzly. Přítomnost komplexu odolného proti chybám, jehož rychlost se zvyšuje přidáním nového uzlu, je považována za nejoptimálnější řešení při budování výpočetního systému. Ale samotné schéma budování takových smíšených clusterových architektur vede k potřebě kombinovat velké množství drahých komponent, aby byl zajištěn vysoký výkon a zároveň redundance. A protože nejdražší komponentou ve vysoce výkonném clusterovém systému je vysokorychlostní komunikační systém, jeho duplikace povede ke značným finančním nákladům. Je třeba poznamenat, že systémy s vysokou dostupností se často používají pro úlohy OLTP, které optimálně fungují na symetrických víceprocesorových systémech. Implementace takovýchto klastrových systémů se často omezuje na možnosti 2 uzlů, primárně zaměřené na zajištění vysoké dostupnosti. Ale v poslední době se stalo populárním řešením použití levných systémů s více než dvěma jako komponenty pro budování smíšených HA / HP clusterových systémů.

Potvrzují to zejména informace agentury The Register zveřejněné na její stránce:

"Předseda společnosti Oracle Corporation oznámil, že v blízké budoucnosti budou tři unixové servery, které provozují většinu podnikových aplikací společnosti, nahrazeny blokem serverů založených na procesorech Intel s operačním systémem Linux. Larry Ellison trvá na tom, že zavedení podpory clusterů při práci s aplikacemi a databázemi snižuje náklady a zlepšuje odolnost proti chybám."

Nástroje pro implementaci vysoce výkonných klastrů

Nejoblíbenější komunikační technologie pro stavbu superpočítačů založených na clusterových architekturách jsou dnes:

Myrinet, Virtual Interface Architecture (Giganet's cLAN je jednou z prvních komerčních hardwarových implementací), SCI (Scalable Coherent Interface), QsNet (Quadrics Supercomputers World), Memory Channel (vyvinutý společnostmi Compaq Computer a Encore Computer Corp), stejně jako studna -známý Fast Ethernet a Gigabit Ethernet.

Obrázek 8. Rychlost nepřetržitého přenosu dat

Obrázek 9. Doba přenosu paketů s nulovou délkou

Tyto diagramy (obr. 8 a 9) umožňují vidět rychlost hardwarových implementací různých technologií, ale je třeba mít na paměti, že na skutečných úlohách a při použití různých hardwarových platforem jsou parametry zpoždění a rychlosti přenosu dat získány o 20 -40 % a někdy o 100 %. % je horší než maximální možné.

Například při použití knihoven MPI pro komunikační karty cLAN a servery Intel se sběrnicí PCI je skutečná propustnost kanálu 80-100 MByte/s, zpoždění je asi 20 μs.

Jedním z problémů, které vznikají při použití vysokorychlostních rozhraní, jako je například SCI, je, že architektura PCI není vhodná pro práci s vysokorychlostními zařízeními tohoto typu. Pokud je ale PCI Bridge přepracován se zaměřením na jedno zařízení pro přenos dat, pak je tento problém vyřešen. Takové implementace probíhají v řešeních některých výrobců, například SUN Microsystems.

Při navrhování vysokorychlostních klastrových systémů a výpočtu jejich výkonu je tedy třeba vzít v úvahu ztráty výkonu spojené se zpracováním a přenosem dat v uzlech klastru.

Tabulka 1. Porovnání vysokorychlostních komunikačních rozhraní

Technologie	Šířka pásma MByte/s	Zpoždění μs/shluk	Cena karty/přepínače pro 8 portů	Podpora platformy	Komentář
Rychlý Ethernet	12.5	158	50/200	Linux, UNIX, Windows	Nízké ceny, oblíbené
gigabitový ethernet	125	33	150/3500	Linux, UNIX, Windows	Snadný upgrade
Myrinet	245	6	1500/5000	Linux, UNIX, Windows	Otevřený standard, populární
VI (s LAN od Giganet)	150	8	800/6500	Linux, Windows	První hardwarová průmyslová implementace VI
SCI	400	1.5	1200/5000 *	Linux, UNIX, Windows	Standardizované, široce používané
QsNet	340	2	N/A**	True64 UNIX	Systémy AlphaServer SC a Quadrics
Paměťový kanál	100	3	N/A	True64 UNIX	Používá se v Compaq AlphaServer

* SCI hardware (a podpůrný software) umožňuje konstrukci tzv. MASH topologií bez použití přepínačů
** žádná data

Obrázek 10. Pevně propojený víceprocesorový systém s asymetrickým přístupem do paměti

Jednou ze zajímavých vlastností komunikačních rozhraní, která poskytují nízkou latenci, je to, že je lze použít k vytváření systémů s architekturou NUMA a také systémů, které mohou simulovat víceprocesorové SMP systémy na softwarové úrovni. Výhodou takového systému je, že můžete používat standardní operační systémy a software orientovaný na použití v SMP řešeních, ale vzhledem k vysokému zpoždění meziprocesorové interakce, které je několikanásobně vyšší než u SMP, bude výkon takového systému nižší. nepředvídatelné.

Paralelizační nástroje

Existuje několik různých přístupů k programování paralelních počítačových systémů:

ve standardních široce používaných programovacích jazycích využívajících komunikační knihovny a rozhraní pro organizaci interakce mezi procesory (PVM, MPI, HPVM, MPL, OpenMP, ShMem)
použití specializovaných paralelních programovacích jazyků a paralelních rozšíření (paralelní implementace Fortran a C/C++, ADA, Modula-3)
využití automatické a poloautomatické paralelizace sekvenčních programů (BERT 77, FORGE, KAP, PIPS, VAST)
programování ve standardních jazycích s využitím paralelních postupů ze specializovaných knihoven, které jsou zaměřeny na řešení problémů ve specifických oblastech, např.: lineární algebra, metody Monte Carlo, genetické algoritmy, zpracování obrazu, molekulární chemie atd. (ATLAS, DOUG, GALOPPS, NAMD, ScaLAPACK).

Existuje také mnoho nástrojů, které zjednodušují návrh paralelních programů. Například:

KÓD- Grafický systém pro tvorbu paralelních programů. Paralelní program je reprezentován jako graf, jehož vrcholy jsou postupnými částmi programu. Pro předávání zpráv se používají knihovny PVM a MPI.
LAPOVAČ- Komerční produkt německé firmy Genias. Grafické programovací prostředí, které obsahuje komponenty pro vytváření paralelního softwaru.

Podle zkušeností uživatelů vysokorychlostních clusterových systémů fungují nejefektivněji programy, které jsou speciálně napsány s ohledem na potřebu meziprocesorové interakce. A i když je mnohem pohodlnější programovat na balíčcích, které využívají rozhraní sdílené paměti nebo nástroje automatické paralelizace, dnes jsou nejrozšířenější knihovny MPI a PVM.

Vzhledem k masivní popularitě MPI (The Message Passing Interface) bych vám o něm rád něco málo řekl.

"Rozhraní pro předávání zpráv" je standard, který se používá k vytváření paralelních programů a používá model zasílání zpráv. Existují implementace MPI pro C/C++ a Fortran jak ve bezplatných, tak komerčních verzích pro většinu běžných superpočítačových platforem, včetně vysoce výkonných clusterových systémů postavených na uzlech Unix, Linux a Windows. MPI Forum () je zodpovědné za standardizaci MPI. Nová verze standardu 2.0 popisuje velké množství nových zajímavých mechanismů a postupů pro organizaci provozu paralelních programů: dynamické řízení procesů, jednosměrné komunikace (Put/Get), paralelní I/O. Ale bohužel zatím neexistují kompletní hotové implementace této verze standardu, i když některé novinky jsou již aktivně využívány.

Pro zhodnocení funkčnosti MPI vám chci dát do pozornosti graf časové závislosti výpočtu úlohy řešení soustav lineárních rovnic v závislosti na počtu procesorů zapojených do shluku. Cluster je postaven na procesorech Intel a propojení mezi uzly SCI (Scalable Coherent Interface). Problém je přirozeně specifický a není nutné chápat získané výsledky jako obecný model pro predikci výkonu požadovaného systému.

Obrázek 11. Závislost doby výpočtu úlohy řešení soustav lineárních rovnic v závislosti na počtu procesorů zapojených do shluku

Graf ukazuje dvě křivky, modrou - lineární zrychlení a červenou - získané jako výsledek experimentu. To znamená, že v důsledku použití každého nového uzlu získáme zrychlení vyšší než lineární. Autor experimentu tvrdí, že k takovým výsledkům dochází díky efektivnějšímu využití vyrovnávací paměti, což je vcelku logické a pochopitelné. Pokud má někdo k tomu myšlenky a nápady, budu vděčný, když se o ně podělíte (můj e-mail: [e-mail chráněný]).

Prostředky pro implementaci clusterů vysoké dostupnosti

Klastry vysoké dostupnosti lze rozdělit na:

Shared Nothing Architecture (architektura bez sdílení zdrojů)
Shared Disk Architecture (architektura se sdílenými disky)

Obrázek 12. Architektura bez sdílení zdrojů

Nesdílená architektura nepoužívá sdílené úložiště. Při jeho použití má každý uzel své vlastní diskové jednotky, které nejsou sdíleny uzly clusterového systému. Ve skutečnosti jsou na hardwarové úrovni odděleny pouze komunikační kanály.

Obrázek 13. Architektura se sdílenými disky

Architektura sdíleného disku se klasicky používá k budování vysoce dostupných clusterových systémů, které jsou orientovány na zpracování velkého množství dat. Takový systém se skládá ze sdíleného úložného systému a klastrových uzlů, které distribuují přístup ke sdíleným datům. S vysokou kapacitou úložného systému je při práci s datově orientovanými úlohami efektivnější architektura se sdílenými disky. V tomto případě není potřeba uchovávat více kopií dat a zároveň, když některý uzel selže, mohou být úkoly okamžitě dostupné ostatním uzlům.

Pokud se v úloze podaří logicky oddělit data tak, aby bylo možné pomocí části dat zpracovat požadavek z určité podmnožiny požadavků, pak může být systém bez sdílení zdrojů efektivnější řešení.

Zajímavá je podle mě možnost budování heterogenních klastrových systémů. Například software Tivoli Sanergy umožňuje budovat systémy, které mohou sdílet přístup k datům mezi heterogenními uzly. Takové řešení může být velmi užitečné v systémech pro hromadné zpracování videoinformací nebo jiných dat v organizaci, kde požadovaný rozsah řešení jednoduše neexistuje na jedné platformě, nebo již existuje vytvořená flotila hardwarových a softwarových prostředků, které potřebují využívat efektivněji.

Obrázek 14. Heterogenní klastrový systém

Nejoblíbenějšími komerčními systémy jsou dnes clustery s podporou převzetí služeb při selhání se dvěma uzly. Rozlišujte Active-Active (Active-Active) a Active-Passive (Active-Passive) implementační modely klastrových systémů odolných proti chybám ve vztahu k distribuci softwarových prostředků.

Obrázek 15. Model Active-Active

V modelu Active-Active spolu s řešením odolným proti chybám získáme prakticky vysokorychlostní řešení, protože jedna úloha funguje na více serverech současně. Tato možnost je implementována například v Oracle Prallel Server, MS SQL 2000, IBM DB2. To znamená, že implementace takového modelu je možná pouze v případě, že je aplikační software napsán se zaměřením na fungování v clusterovém režimu (výjimkou jsou clusterové systémy se sdílenou RAM). V modelu Active-Active je možné škálovat rychlost úlohy přidáním nového uzlu, pokud je samozřejmě požadovaný počet uzlů podporován softwarem. Například Oracle Parallel Server 8.0.5 podporuje cluster 2 až 6 uzlů.

Obrázek 16. Aktivní-aktivní cluster na 3 uzlech

Velmi často se uživatelé setkávají s takovým problémem, když je potřeba zajistit bezchybné fungování hotových softwarových řešení. Bohužel model Active-Active v tomto případě nefunguje. Pro takové situace se používá model, který zajišťuje migraci úloh, které byly spuštěny na neúspěšném uzlu, do jiných uzlů. Dostáváme tak implementaci Active-Passive.

Obrázek 17. Aktivně-pasivní model

Vzhledem k tomu, že v mnoha případech můžeme jeden úkol rozdělit do několika distribučních oblastí odpovědnosti, a také k tomu, že v obecném případě podnik potřebuje plnit mnoho různých úkolů, je implementován tzv. pseudo Active-Active model clusterového systému.

Obrázek 18. Pseudo Active-Active cluster na 3 uzlech

Pokud potřebujete zajistit bezchybný provoz několika softwarových prostředků, pak stačí přidat nový uzel do systému a spustit potřebné úlohy na clusteru, který se v případě selhání tohoto uzlu přenese k provedení na jiném uzlu. Takový model je implementován v softwaru ReliantHA pro Caldera OpenUnix a Unixware OS, který podporuje clustering od 2 do 4 uzlů, v modelech MSCS (Microsoft Cluster Service) a Linux Failover Cluster.

Komunikační systém v clusterových systémech s podporou převzetí služeb při selhání může být postaven na stejném hardwaru jako ve vysokorychlostních clusterech. Ale v případě implementace architektury se sdíleným diskem je nutné poskytnout vysokorychlostní přístup ke sdílenému úložnému systému. Tento problém má dnes mnoho řešení.

Pokud se použije nejjednodušší 2uzlový model, pak lze přístup k diskům vybudovat jejich přímým připojením ke společné sběrnici SCSI,

Obrázek 19. Architektura se sdílenou sběrnicí SCSI

nebo pomocí samostatného diskového subsystému s vestavěným řadičem SCSI na SCSI. V druhém případě jsou disky připojeny k interním nezávislým kanálům diskového subsystému.

Obrázek 20. Varianta využívající diskový subsystém SCSI až SCSI

Možnost použití diskového subsystému SCSI na SCSI je škálovatelnější, funkční a odolnější vůči chybám. Navzdory tomu, že mezi uzlem a disky existuje další most, je rychlost takového systému obvykle vyšší, protože získáme dial-up přístup k jednotce (situace je podobná použití rozbočovače a přepínače v místní síti ). Na rozdíl od varianty se sdíleným přístupem k disku na společné sběrnici SCSI má samostatný nezávislý diskový subsystém také pohodlnou schopnost budovat systémy bez bodů selhání a schopnost vytvářet konfigurace s více uzly.

V poslední době si začalo získávat na popularitě nové sériové rozhraní pro protokol SCSI, FC (Fibre Channel). Na bázi FC se budují tzv. storage sítě - SAN (Storage Area Network).

Obrázek 21. Clusterový systém využívající Fibre Channel SAN

Téměř všechny jeho vlastnosti lze připsat hlavním výhodám Fibre Channel.

Vysoké datové rychlosti
Nezávislost na protokolu (0-3 úrovně)
Velké vzdálenosti mezi body
Nízká latence při přenosu krátkých paketů
Vysoká spolehlivost přenosu dat
Prakticky neomezené škálování
Multidrop topologie

Tyto pozoruhodné vlastnosti Fibre Channel jsou dány tím, že se na jeho návrhu podíleli specialisté v oblasti kanálových i síťových rozhraní a podařilo se jim spojit kladné vlastnosti obou v jednom FC rozhraní.

Abychom pochopili význam FC, uvedu srovnávací tabulku FC a paralelního rozhraní SCSI.

Tabulka 2. Tabulka srovnávacích charakteristik rozhraní FC a paralelního SCSI

Dnes jsou FC zařízení dražší než paralelní SCSI zařízení, ale cenový rozdíl se v posledních letech drasticky snižuje. Disky a úložné systémy jsou již cenově téměř stejné jako paralelní implementace SCSI, pouze adaptéry FC představují významný rozdíl v ceně.

Existuje další velmi zajímavá implementace architektury clusteru - clusterový systém se sdílenou pamětí (včetně RAM) Shared Memory Cluster. Ve skutečnosti může tento cluster fungovat jak v modelu středně vázaného víceprocesorového systému, tak v pevně vázaném systému. Takový systém, jak bylo zmíněno na začátku článku, se nazývá NUMA.

Obrázek 22. Model klastru sdílené paměti

Cluster se sdílenou pamětí používá software (klastrové služby), který poskytuje jeden systémový obraz, i když je cluster vytvořen jako nepřidělená architektura, jak to vidí operační systém.

Na konci příběhu o vysoce dostupných clusterových systémech chci uvést statistiky o výpadcích různých systémů.

Obrázek 23. Porovnání průměrné doby odstávky různých systémů

Jsou uvedeny zprůměrované údaje i údaje převzaté z propagačních materiálů jedné z výrobních společností, proto je třeba je brát s určitou mírou kritičnosti. Celkový obraz, který popisují, je však zcela správný.

Jak vidíte, klastrové systémy s vysokou dostupností nejsou všelékem pro minimalizaci prostojů. Pokud je výpadek systému extrémně kritický, pak by měly být použity systémy třídy Fault Tolerant nebo Continuous Availability, systémy této třídy mají faktor dostupnosti řádově vyšší než systémy třídy High Availability.

Příklady osvědčených řešení

Protože úspěšnost každé technologie dokazují příklady jejího praktického použití, chci ukázat konkrétní možnosti implementace pro několik podle mého názoru nejdůležitějších clusterových řešení.

Nejprve o vysokorychlostních clusterech.

Jedním z nejužitečnějších příkladů je podle mého názoru to, že první místa a vlastně většinu míst v 18. vydání žebříčku nejvýkonnějších superpočítačů světa obsadily systémy IBM SP2 a Compaq AlphaServer SC. Oba systémy jsou masivně paralelní výpočetní systémy (MPP), které jsou konstrukčně podobné vysoce výkonným clusterovým řešením.

IBM SP2 používá stroje RS/6000 připojené pomocí SP Switch2 jako uzly. Propustnost switche je 500MB/s v jednom směru, latence 2,5 μs.

Compaq AlphaServer SC. Nody jsou 4-procesorové systémy typu Compaq AlphaServer ES45, propojené pomocí komunikačního rozhraní QsNet, jejichž parametry byly zmíněny výše.

Ve stejném seznamu superpočítačů jsou stroje postavené na konvenčních platformách Intel a přepínačích SCI a Myrinet a dokonce i na konvenčním Fast a Gigabit Ethernet. Navíc jak v prvních dvou verzích, tak na vysokorychlostních clusterových systémech postavených na běžném vybavení se pro programování používají balíčky MPI.

A nakonec bych rád uvedl krásný příklad škálovatelného clusterového systému s vysokou dostupností. Hardwarový model clusterového řešení pro vysokorychlostní zpracování databáze IBM DB/2 odolné proti chybám.

Obrázek 24. Cluster IBM DB2

To je vše. Pokud má někdo nějaké dotazy, rady nebo chuť si popovídat - jste vítáni. Moje souřadnice najdete na konci článku.

Literatura

"Sizing Up Parallel Architectures" - Greg Pfister, hlavní technický specialista IBM.
"Je pro Windows možná odolnost proti chybám?" - Natalya Pirogova, materiály vydavatelství Open Systems.
"Použití systémů pro paralelizaci úloh ve volně propojeném clusteru", - M. N. Ivanov.
"Počítače odolné proti chybám společnosti Stratus", - Victor Shnitman, materiály vydavatelství "Open Systems".
"Moderní výkonné počítače", - V. Shnitman, informačně-analytické materiály Centra informačních technologií.
"Krok k sítím pro ukládání dat", informační a analytické materiály společnosti USTAR.
"Vývoj architektury virtuálního rozhraní" - Torsten von Aiken, Werner Vogels, materiály vydavatelství "Open Systems".
Materiály Laboratoře paralelních informačních technologií "NIVTs MGU".
Informační centrum Cluster Computing.
Materiály SCI Europe.
Materiály VI Forum (Virtual Architecture Developers Forum).
Materiály Caldera.
Delfinické materiály.
Materiály Emulex.
Obsah od KAI Software, divize společnosti Intel Americas, Inc. (KAI).
Materiály od společnosti Myricom, Inc.
Oracle Materials.
Doporučení technické podpory Intel.