Virtualizáció és magas rendelkezésre állás – 5

Két alkalmazásnál már úgy láttuk, hogy a szolgáltatás szintű magas rendelkezésre állás nem elhagyható opció. Nézzük most meg az Exchange-et. Elvégre AD és NLB elérhető egy Windows Standard változattal is, Exchange clusterhez viszont minimum Windows Enterprise Edition szükségeltetik, tehát pénzre megy a játék(*). A korábbi táblázatunk Exchange alkalmazásra vonatkoztatva az alábbiak szerint alakul:

Kieső komponens	Exch – DAG fizikai	Exch – VMware HA-val	Exch – Hyper-V clusterrel	Exch – VMware FT-vel	Exch DAG VMware HA-val	Exch DAG Hyper-V clusterrel	Exch DAG VMware   FT-vel
Adatbázis	x				NS	NS	NS
Alkalmazás	x				NS	NS	NS
Operációs rendszer	x				NS	NS	NS
Szerver hardver	x	x	x	x	NS	NS	NS
SAN kapcsolat	x	x	x	x	NS	NS	NS
SAN tároló	x	x(*)	x(*)	x(*)	NS	NS	NS
Teljes telephely	x	x(*)	x(*)	x(*)	NS	NS	NS

A táblázat bal fele – most már mondhatjuk – a szokásos. Az alacsonyabb logikai rétegben dolgozó virtualizációs HA  képtelen bizonyos szituációkat lekezelni. Ráadásul  a le nem kezelt szituációk még talán gyakoribbak, mint a lekezeltek, főleg ha azt is számítjuk, hogy a táblázat nem csak a nem tervezett, de a tervezett leállásokat is tartalmazza. Azt nem mondom, hogy egy adatbázis szétesés mindennapi eset, de egy javítócsomag telepítés az alkalmazásra vagy az operációs rendszerre már sokkal inkább. A következtetésem ismét ugyanaz, mint korábban: lemondani az alkalmazás szintű Exchange fürtözésről és pusztán a virtualizációs HA/FT megoldásokra támaszkodni – ez visszalépés a magas rendelkezésre állás biztosítása terén.

A táblázat jobb oldala már újdonság. NS, vagyis “not supported” (nem támogatott). A pontos megfogalmazás így hangzik:

“Microsoft doesn’t support combining Exchange high availability solutions (database availability groups (DAGs)) with hypervisor-based clustering, high availability, or migration solutions that will move or automatically failover mailbox servers that are members of a DAG between clustered root servers. DAGs are supported in hardware virtualization environments provided that the virtualization environment doesn’t employ clustered root servers, or the clustered root servers have been configured to never failover or automatically move mailbox servers that are members of a DAG to another root server.”

Forrás: http://technet.microsoft.com/en-us/library/aa996719.aspx

Mielőtt bárki csúnya-csúnya microsoftozna, íme a VMware álláspont:

Before you set up MSCS, review the list of functionality that is not supported for this release, and any
requirements and recommendations that apply to your configuration.The following environments and functionality are not supported for MSCS setups with this release of vSphere:
* Clustering on iSCSI, FCoE, and NFS disks.
* Mixed environments, such as configurations where one cluster node is running a different version of ESX/ESXi than another cluster node.
* Clustered virtual machines as part of VMware clusters (DRS or HA).
* Use of MSCS in conjunction with VMware Fault Tolerance.
* Migration with VMotion of clustered virtual machines.
* N-Port ID Virtualization (NPIV)
* With native multipathing (NMP), clustering is not supported when the path policy is set to round robin.
* You must use hardware version 7 with ESX/ESXi 4.0.

Forrás: www.vmware.com/pdf/vsphere4/r41/vsp_41_mscs.pdf

Ez az utóbbi cikk egyébként nagyon pontos, és számos együttélési problémára rávilágít (RDM lezemek, egyáltalán storage kezelés, multipath, clustered vmdk, 2003 vs 2008 fürtök stb stb.) érdemes olvasgatni. Ha a táblázat bal oldala szerint a virtualizációs HA/FT megoldások csökkentik a rendszer képességét, hogy különböző meghibásodásokra reagáljon, a jobb oldala pedig a “nem támogatott” helyzetbe sodorna minket, a következtetés egyértelmű: ha komolyan gondoljuk az Exchange adatbázis kiszolgálók magas rendelkezésre állását, akkor Exchange Mailbox Store szerepkört nem keverünk össze virtualizációs HA/FT megoldással.

Ez viszont nem jelenti azt, hogy ne lehetne egy mailbox szerepkört virtualizálni. Lehet, guest clustering segítségével – ez a téma viszont nem tartozik szorosan a tárgyhoz, majd máskor tárgyaljuk.

Még egy fontos dolgot tisztáznunk kell. Vajon minden fail-over clusteres alkalmazás esetén azonos szabályokat kell alkalmaznunk? Ez egyáltalán nem biztos. Az eredeti alkalmazások között ugyan nem szerepel, de érdekes példa lehet a Microsoft SQL szerver. Szemben az Exchange csapattal, itt a host + guest cluster támogatott.

• Guest Failover Clustering is supported for SQL Server 2005, SQL Server 2008, and SQL Server 2008 R2 in a virtual machine for the supported hardware virtualization environments listed in this article provided all of the following requirements are met: 
  • The Operating System running in the virtual machine (the “Guest Operating System”) is Windows Server 2008 or higher
  • The virtualization environment meets the requirements of Windows 2008 Failover Clustering, as documented in the following Microsoft Knowledge Base article:

    943984 (http://support.microsoft.com/kb/943984/ ) The Microsoft Support Policy for Windows Server 2008 Failover Clusters

[…]

Q5: Is Quick and Live Migration with Windows Server 2008 R2 Hyper-V supported with SQL Server?
A5: Yes, Live Migration is supported for SQL Server 2005, SQL Server 2008, and SQL Server 2008 R2 when using Windows Server 2008 R2 with Hyper-V or Hyper-V Server 2008 R2.Quick Migration, which was introduced with Windows Server 2008 with Hyper-V and Hyper-V Server 2008, is also supported for SQL Server 2005, 2008, and 2008 R2 for Windows Server 2008 with Hyper-V, Windows Server 2008 R2 with Hyper-V, Hyper-V Server 2008, and Hyper-V Server 2008 R2.

Forrás: http://support.microsoft.com/?id=956893

Furcsa fricska, hogy az előbb idézett vSphere dokumentum általánosan a Microsoft cluster megoldásra vonatkozik, tehát az SQL szerverre is, míg a Microsoft a maga részéről a guest clustered SQL kiszolgálók migrációját nem bánja.

Végeredményben tehát két dolgot legalább meg kell tanulnunk:

1. A fail-over cluster – NEM ELHAGYHATÓ magas rendelkezésre állást biztosító technológia.
2. A guest fail-over cluster és a host cluster megoldások vagy egyáltalán nem keverhetők, vagy pedig erősen meg kell nézni, hogy mely gyártó mely alkalmazásnál milyen megkötéseket ad meg.

Folytatjuk…

—————

(*) – Ezt az “érvet” még elemezzük egy későbbi cikkben