3S.cz

VMware versus diskové pole

29.02.2012, 12:20

Virtualizace – co by nástroj k reálným úsporám – bezesporu zakotvila v korporátním prostředí. Jejím reálným benefitem není jen deployment více virtuálů na jednom fyzickém serveru, ale předně mechanismy spojené s vysokou dostupností, přesuny virtuálů, fault tolerance režimem apod.

Podmínkou nutnou pro fungování těchto mechanismů je centrální datové úložiště. Jaké úložiště je vhodné? Jaké jsou pravdy a mýty?

Datové úložiště – storage

Datové úložiště je podmínkou nutnou, aby mohly fungovat zcela zásadní funkcionality VMware jako je Vmotion, High Availability, Fault Tolerance, DRS. Podrobněji zde. Všechny tyto uvedené mechanismy tak či onak využívají možnost přesunu virtuálního serveru mezi fyzickými. Proto je sdílené datové úložiště – diskové pole – dostupné z celé skupiny VMware serverů řešením, které právě tento přesun umožňuje.

Rozdíly mezi diskovými poli

Rozdíly mezi diskovýmy poli různých vendorů samozřejmě existují. Problematika není daná pouze výkonností controlleru diskového pole a typem použitých disků (FC, SAS, SATA) – ale mimo jiné i architekturou controllerů.  A právě architektura controllerů, definování primárních cest a fail over cest včetně chování diskového pole v případě, že se nekomunikuje primární cestou je velmi podstatný aspekt designu diskového pole vůči VMware!

Transportní vrstva – FC? iSCSI?

Následující text se zabývá architekturou storage v souvislosti s VMware, ale i ostatními firemnímy systémy bez virtualizace. V textu se zabývám především prostředím FibreChannel s vědomím, že poněkud opomíjím problematiku iSCSI protokolu. Logika věci je však identická nezávisle na přenosové vrstvě.

Poznámka: iSCSI je síťový protokol rodiny TCP/IP protokolů.Představuje sloučení SCSI (SmallComputer System Interface) protokolu a protokolu TCP/IP. Pomocí iSCSI jsme schopni přenášet SCSI příkazy přes LAN síť založenou na IPv4 nebo IPv6. Podobně jako u FibreChannel se komunikace odehrává mezi initiatorem a targetem reprezentovaným portem diskového pole. Implementace iSCSI Initiatoru může být softwarová na úrovni operačního systému nebo hardwarová.

Při implementaci pod VMware je třeba mít na vědomí jak mechanismus iSCSI funguje na straně initiatoru, jak funguje multipath a jaké jsou limity z hlediska výkonu a stability a tyto skutečnosti mohou v určitých situacích zmařit relativní úspory vzniklé investicí do iSCSI prostředí oproti FC prostředí. Vhodná volba je vždy otázkou konkrétních požadavků na úroveň a dostupnost služeb.

Zásadní rozdíly v architektuře diskových polí – Symetrický active/active nebo jen active/active?

Pro pochopení  je třeba poruzumět tomu, že klasická disková pole pracují s termínem “LUN OWNER”. To znamená, že daný logický disk – LUN – je ve “vlastnictví” buď controlleru 1 nebo controlleru 2 – přestože controllery pracují oba. Cesta přes controller, který je vlastníkem LUNu by měla být v klasické koncepci diskového pole primární.

Cesta přes druhý controller je pak určena pro failover situace. Tato alternativní cesta v naprosté většině případů představuje úzké hrdlo, které zásadním způsobem může degradovat výkon všech služeb postihnutých touto situací.

Navíc u klasického diskového pole stojí administrátor před poměrně náročným úkolem – aby nebyl v situaci, že jeden controller diskového pole je přetížen a služby uživatelům jsou “líné”, zatímco druhý controller nemá co na prácí – musí zkušenostmi a intuicí manuálně zajistit rozložení služeb mezi oba controllery diskového pole a korektně definovat primární a záložní cesty.

Ve větších prostředích už je uvedené poměrně složitý úkol.

Pohled na klasickou architekturu z hlediska VMware

Příklad architektury dvou VMware serverů pracujících nad diskovým polem s klasickou koncepcí může vypadat takto:

V tomto případě je je Controller 0 diskového pole vlastníkem LUNu na kterém jsou jednotlívé virtuální servery prezentovány jako image. Je tedy vhodné aby veškerá komunikace probíhala přes vlastníka LUNu, tedy controller 0 – protože jen v tomto případě je schopno diskové pole dát maximální výkon.

Záložní cesta včetně controlleru 1 se nevyužívá, což je není ideální z hlediska využití dostupných zdrojů. (Nemusí to však být vždy limitující, v praxi se např. controller 1 a “jeho” LUNy udělají primárním pro non-VMware prostředí).

Co se stane v případě FailOveru?

V případě, že selže připojení, host bus adaptér, switch, musí dojít k přesunu komunikace z primárně definované cesty na alternativní datovou cestu. Tímto však dojde k situaci, že datová komunikace na daný LUN probíhá přes controller, který není vlastníkem tohoto LUNu! Tato situace silně afektuje výkon.

V praxi jsme v situaci, že s modelem klasického diskového pole máme sice řešení vysoké dostupnosti, je však třeba myslet a při designu pamatovat na skutečnost, že v případě Fail Overu může být kvalita služeb silně degradována.

Existuje východisko?

Východisko existuje a jako první bylo stvořeno v oblasti enteprise diskových polí. Jde o konstrukci controllerů, která je symetrická a controllery jsou v režimu Symetrický Active/Active.

Tato koncepce termín “vlastník LUNu” vůbec nezná a nepoužívá a přístup daným diskovým prostředkům je identický jak přes controller 0, tak přes controller 1.

Architektura Symetrický active-active z pohledu LUNu nerozlišuje, který controller daný LUN vlastní (přes tento contreller byl přístup nejrychlejší, druhý controller se použil v případěfailoveru), ale oba jsou naprosto rovnocenné a plně zastupitelné. Toto prostředí potom umožňuje loadbalancovat vstupní IO operace přes všechny vstupní (front-endové porty).  Mezi controllery je výkonostně velmi silně dimenzovaná sběrnice přes kterou probíhá vnitřní komunikace mezi controllery a mimo jiné hardwarový load ballancing.

Hardwarový load ballancing je zároveň cestou k zásadnímu navýšení výkonu storage vůči konkrétním serverům. Ballancing funguje tak, že v případě vytížení jednoho controlleru dojde k jeho utilizaci nad 70%, automaticky vnitřní sběrnicí předává vstupní IO požadavky ke zpracování druhému controlleru. Maximální výkon z hlediska serveru tak není dán potenciálem jednoho controlleru, ale obou!

Touto unikátní technologií disponují disková pole AMS společnosti HITACHI DATA SYSTEMS. Podrobněji zde.

V případě výše uvedeného jednoduchého VMware prostředí by design řešení pak mohl vypadat takto:

Toto řešení zásadně zjednodušuje administraci a garantuje stejnou kvalitu služeb jak v případě, že VMware servery komunikují po primárních datových cestách, tak v případě FailOver stavu.

Další benefity active/active architektury diskových polí HITACHI

• Zajišťuje, že I/O provoz z host systému na disky je dynamicky řízen, balancován a rovnoměrně sdílen oběma řadiči, a to i v případě, že I/O zátěž je nesouměrně rozdělena mezi specifické logické jednotky (LUNy).
• Zjednodušuje celkovou administraci diskového systému eliminací nutnosti přiřazovat vlastnictví LUNů pro jednotlivé řadiče.
• Umožňuje provádět on-line upgrade firmwaru řadiče, a to i v případě, že servery jsou připojeny k diskovému poli pouze jedním host bus adaptérem. Na jednom řadiči probíhá update, zatímco druhý provádí všechny I/O operace.
• Zajišťuje jednoduchou kooperaci s řešením VMware v prostředí VMotion, umožňuje virtuálním strojům efektivním způsobem provádět přesun mezi fyzickými systémy. Je to dáno tím, že stejný LUN může být přistupován z rozdílného host systému použitím libovolného portu na jednom z řadičů.
• Zajišťuje rychlejší dobu odezvy pro prostředí Microsoft Exchange pomocí dynamického load balancingu.

Ti co pracují v oblasti návrhu topologie SAN vědí, že úkol výkonově vyladit konfiguraci diskového pole je obtížný. V praxi není možné vyladit zatížení controllerů servery tak, aby bylo rovnoměrné – už i proto, že na serverech běží nějaké aplikace a ty negenerují rovnoměrné datové toky. Opak je spíše pravdou a jde o náhodné špičkové hodnoty mezi “obdobím klidu”.

To znamená, že dochází k situacím, kdy jeden controller diskového pole je utilizován an 100%, zatímco druhý nemá co na práci. Nový modulární diskový systém Hitachi je v tomto ohledu revoluční, protože funkce automatického loadbalancingu hardwarových prostředků zajistí jejich rovnoměrné využití podle aktuální zátěže vstupních IO operací.

Jít zpět