V rámci přípravy na dnešní (nakonec odložený) livemeeting na téma failover cluster na Windows 2012 R2 jsem narazil na několik zajímavých problémů, které je asi dobré zdokumentovat.
Samostatná síťovka pro iSCSI
Pokud máte clusterové disky (cluster storage) na iSCSI, tak pro to iSCSI musíte mít oddělenou síťovou kartu. Jinak vám neprojde validace clusteru. Nebo přesněji řečeno, síťovku, přes kterou chodí to iSCSI, nelze použít pro nic jiného, nelze z ní tedy udělat ani síťovku pro inter-cluster komunikaci, ani client-enabled síťovku pro přístup z klientů.
Failover Cluster Manager se připojuje na všechny členy clusteru na jejich Admin$ a C$ sdílení
Ano, pokud vypnete admin share, sice vám failover cluster manager pojede, ale velice pomalu a občas to bude hlásit nějaké problémy. Pro provoz clusteru prostě potřebujete mít povolené administrativní sdílení na všech členech. Včetně na tom, na kterém vám běží ta konzole. Ona se připojuje i sama na sebe na admin share.
Na členech clusteru nesmíte mít žádný dynamický ani diferenční VHD disk
Pokud děláte cluster v Hyper-V virtuálce, žádný disk nesmí být dynamically expanding VHD, ani differenting VHD. Cluster validation wizard se totiž zasekne okamžitě, jakmile na takový disk narazí. A to se zasekne třeba dříve, než narazí na jakýkoliv jiný sdílený storage. Takže skončíte s tím, že nemáže žádné disky a hotovo.
Chybová hláška je tato:
Failover Cluster Validation Report
Storage - Failed
Physical disk does not have the inquiry data (SCSI page 83h VPD descriptor) that is required by failover clustering.
Řešení je jednoduché. Prostě také datové disky nemůžete používat. Operační systém (systémový disk) takový mít můžete. Ale pokud je to prostě další disk, byť to není sdílený disk, tak nesmí být ani dynamický and diferenční.
Upozorňuju, že toto neplatí pro VHD disky připojené přes iSCSI. Pokud si připojíte dynamický disk z iSCSI targetu, tak to pojede v pohodě.
Jak zjistím signaturu, nebo sériové číslo disku?
Různé chybové stavy, průvodci, cluster validation report a události týkající se konfigurace clusteru hlásí buď signaturu (signature), nebo sériové číslo (serial number) problematického disku. Pokud je disk MBR, tak má signature. Disky inicializované na formát GPT nemají signature, ale mají serial number.
Zjistit se to dá jednoduše z PowerShellu pomocí WMI. Jenom to chce přepočítat desítkovou hodnotu Signature na hexa:
gwmi Win32_DiskDrive | Sort Index | Select Caption,Index,PNPDeviceID,SerialNumber, @{ name = 'Signature' ; exp = { '{0:X}' -f $_.Signature } }, @{ name = 'IsGPT' ; exp = { $_.Signature -eq $null } }
Tohle jsou mimochodem informace, které se dají najít v registrech v klíči HKML\System\MountedDevices, pakliže jsou na těch discích i nějaké oddíly.
Bezpečnost
Účet clusteru v Active Directory je možno samozřejmě vytvořit ručně dopředu. Na tom účtu clusteru v Active Directory musí mít ale uživatel, který cluster vytváří buď Full Control. Nebo tam musí být přímo položka SELF = Full Control, protože to přesně cluster chce, tuhle by si tam chtěl při vytváření clusteru nastavit sám pro sebe.
Na sdíleném adresáři, který používáte jako file share witness potřebuje mít cluster account také full control. Zase to už není potřeba nastavovat vzdáleně. Stejně jako v Active Directory stačí úplně, když to tam už nastaveno je. Což je podstatné vylepšení proti mým předchozím zkušenostem, kdy to bylo potřeba nechat průvodce nastavit samotného.
Zjištění a pozavírání spojení na sdílené soubory pomocí PowerShell a WMI
Aniž bych byl překvapen, že i tohle WMI dokáže, vám tu sděluji, že pomocí Win32_ServerSession a Win32_ServerConnection je možno zobrazit všechny sešny sdílených souborů a případně tedy také konkrétní vzdálená spojení. Což se samozřejmě může hodit například i pokud testujete cluster shared volumes (CSV).
Z jazyka PowerShell zavřít svšechny sdílené sešny (session, share session) na lokální souborový server:
gwmi Win32_ServerSession
gwmi Win32_ServerConnection
gwmi Win32_ServerSession | % { $_.Delete() }