Ielūkosimies Failover Cluster un HyperV Cluster funkcionalitātē. Apskatīsim Site Aware, Guest klāsterēšanu, failover procesu. Nedaudz no tā ko nevajadzētu piemirst un labo praksi.

Failover Cluster

Darbības princips

Sāksim ar to kā darbojas Windows Failover Cluster, no kā tas sastāv. Klāstera pamatā ir nodes, jeb serveri kas darbina servisus, virtuālās mašīnas. Tas viss tiek dēvēts par rolēm (Roles) un tā pamatdoma ir nodrošināt augstu pieejamību.

Atrodoties uz serveriem tās izmanto servera resursus - atmiņu, procesora jaudu. Storage resursi var tikt iegūti vairākos veidos. Izmantojot ārēju storage ar FC, iSCSI pieslēgumiem, kā arī, iespējams izmantot lokālu storage ar, piemēram, Storage Spaces Direct, taču jāņem vērā ka S2D vairs nebūs pieejams sākot ar Windows Server 2016 build 1709 tā kā bez trešo pušu risinājumiem neiztikt. Labi pazīstams SDS spēlētājs ir Starwind.

Šajā piemērā un lielākoties tiek izmantots ārējs disku masīvs, no kura tiek eksportēta viena un tā pati Volume/LUNs visiem klāsterī esošajiem hostiem. No šī LUNa pēcāk tiek izveidots CSV, Failover Cluster storage sadaļā. Šajā piemērā interfeisam nav nozīmes, kamēr hostos ir nokonfigurēts MPIO vairāku ceļu gadījumā (redundancei u.t.t.). Vēl jāatceras visiem HyperV hostiem (no HyperV Manager) kā noklusējuma direktoriju VM glabāšanai, izmantot izveidoto CSV šāri, lai tas katru reizi nav jādara veidojot jaunas VM no Failover Cluster Manager konsoles.

02-Failover Cluster

Quorum un Witness

Vēl viena būtiska klāstera sastāvdaļa ir Quorum Witness. Gadījumos, kad hostu skaits nepārsniedz piecus, varētu teikt, ka Quorum Witness ir obligāts priekšnosacījums. Klāstera pastāvēšanu nosaka balsu sistēma, precīzāk balsu vairākums. Situācijās, kad tiek izmantots pāra skaits hostu, quorum witness izmantošana ir vitāla, jo tā varētu pasargāt no iespējamām dīkstāvēm. Piemēram, 2 hostu gadījumā, ja viens no hostiem “iet bojā”, klāsteris pārtrauc darbību, jo netiek pārsniegts balsu pārsvars ½ vai 50% balsu (ar izņēmumiem kad klāsterī darbojas Dynamic Quorum), tas pats 4 hostu gadījumā, kur 2/4 ir 50% un klāsteris spēj izturēt tikai 1 hosta kļūmi. Quorumam tiek piešķirta balss, kas panāk balsu vairākumu divu un 4 hostu gadījumā.

Kā quorum ir iespējams izmantot klāstera disku, file share vai jaunievedumu 2016 serverī - Cloud Witness. Attēlā zemāk tiek izmantots klāstera disks.

03-Failover Cluster

Dynamic Quorum

Vēl viena lieliska Failover Cluster īpašība ir Dynamic Quorum, jeb klāsterī balsu skaits tiek automātiski pielāgots tā, lai klāsteris pēc iespējas ilgāk varētu pastāvēt. Balss tiek noņemta, ja klāsterī ir pāra skaits hostu. Vairāk par Dynamic quorum un scenārijiem iespējams uzzināt šeit. Dynamic quorum gadījumā klāsteris turpina darbību tik ilgi cik ir pieejami resursi servisu darbināšanai.

Failover process, politikas

Paskatīsimies kā klāsteris reaģē, kad tajā notiek kļūda, piemēram, hostam pazūd elektrība. Visi uz hosta esošie resursi tiek migrēti un restartēti uz pieejamajiem hostiem. Kļūdainajam hostam iestājas Down statuss.

04-Failover Cluster

Gadījumos, kad hostam tiek veikta graceful izslēgšana, piemēram, tā apkopes veikšanai, hosts par to paziņo klāsterim un visi resursi tiek Live migrēti neietekmējot servisu darbību.

Gadījumos, kad kādam no hostiem pazūd tīkls, hostam iestājas Isolated, resursam - Unmonitored statuss.

05-Failover Cluster

Ja pēc 4 (noklusējuma) minūtēm hosts neatgūst savienojumu, tā esošie resursi tiek migrēti uz pieejamajām nodēm. Šī ir jauna funkcija Server 2016 failover klāsterī. Nepieciešamība šādai funkcijai ir gadījumos, kad hosti saskaras ar īslaicīgām kļūdām. Īslaicīgu kļūdu gadījumā migrācija un servisa restartēšana uz cita hosta izraisītu daudz lielāku dīkstāves ilgumu nekā gadījumos, ja serviss būtu palicis uz hosta un problēma tiktu novērsta turpat (human error vai citos gadījumos). Ar maināmo timeout laiku ir iespējams koriģēt cik ilgs laiks dots lai problēmu atrisinātu, pirms servisi tiek migrēti ir iespējams mainīt arī laikus atsevišķiem servisiem un VM).

06-Failover Cluster

Turpinot tālāk, ja infrastruktūrā ir hosts kas, pēc noklusējuma 3 reizes stundas laikā, sācis zaudēt savienojumu ar klāsteri (piemēram sākušās hw problēmas), tas tiks ievietots karantīnā un servisi uz šī hosta vairs netiks migrēti līdz šīs problēmas (pēc noklusējuma 2h laikā) netiks novērotas, vai hosts no karantīnas tiks izņemts manuāli. Tas tiek darīts ar mērķi, lai servisi netiktu uzturēti uz nestabiliem hostiem, lai izvairītos no iespējamajām problēmām.

07-Failover Cluster

Failover aplikāciju līmenī

Gadījumos, kad redundance tiek nodrošināta aplikāciju līmenī, kas tiek uzturētas uz virtuālajām mašīnām, to failovers uz citiem hostiem nav nepieciešams, lai virtuālās mašīnas nemigrē uz viena hosta un nekļūst par, piemēram, single-point-of failure un nenāktos tās migrēt atpakaļ uz paredzētajiem hostiem. Šādos gadījumos VM veidošanu un pārvaldību iespējams veikt no Hyper-V Manager, tās nemaz neveidojot Failover Clusterī. Taču tam ir savi mīnusi - vairāki pārvaldības interfeisi varētu radīt neskaidrību par mašīnām lielu infrastruktūru gadījumos. Cits risinājums būtu Hyper-V hosta iestatījumos norādīt to, lai hosts neveic migrāciju, bet minētajā SQL gadījumā to būtu nepieciešams veikt uz vairākiem hostiem un tas zaudē Failover Cluster jēgu, jo migrācijas vairs nav iespējams veikt.

Lielisks veids kā adresēt šo problēmu ir Failover Cluster Managerī norādīt rekvizītu Possible Owners.

08-Failover Cluster

Šādi iespējams norādīt uz kādiem hostiem VM ir iespējams darboties. Norādot tikai vienu hostu VM kļūdas gadījumā neveiks migrāciju, tā kā failover būs noticis jau minētajā aplikāciju līmenī. Šādi ir iespējams arī pārvaldīt VM no viena interfeisa. Kā redzams attēlā, ir iespējams norādīt vairākus iespējamos hostus bez nepieciešamības veidot jaunus klāsterus noteiktu VM izdalīšanai.

Site Aware klāsteri

Vēl viens jaunums ko piedāvā Server 2016 Failover Cluster ir Site aware klāsteri. Tagad iespējams veidot multisite klāsterus, kur hosti “saprot” kur atrodas. Tas piedāvā iespēju hostus granuāli atdalīt pa serveru skapjiem, blade šasijām un saitiem, failoverot servisus servera skapja ietvaros vai migrēt uz citu site, ja vairs nav pieejami lokāli hosti. Tas piedāvā lielāku pieejamību, ietaupa tīkla resursus sākumā migrējot skapja ietvaros. Vairāk par to kā konfigurētu site aware klāsteri var apskatīt šeit. Mēģinot nodzēst Site Aware klāstera konfigurāciju nepieciešams to darīt hierarhiskā secībā, sākot ar mazāko noņemt child-items, jeb no hostiem serveru skapjus, no skapjiem site, norādot – parent “”.

Vēl pieminēšanas vērts ir fakts, ka Site Aware klāsterī, ja tiek izmantots Primary site, opcija Preffered Owners vairs nedarbojas. Fīča vai bugs - atkarīgs no situācijas.

Guest Cluster

Lai sasniegtu HA aplikācijām kā SQL vai Sharepoint prasība ir būt klāsterī. Lai visas aplikācijas un VM neraisītu haosu vienā klāsterī tiek izmantots viesklāsteris, jeb uz virtuālajām mašīnām, kas atrodas HyperV klāsterī tiek izveidots atsevišķs klāsteris priekš, piemēram, SQL, kura serviss tad griežas vai nu uz vm1 vai vm2.

09-Failover Cluster

Failover Cluster 2016 piedāvā daudz jaunu uzlabojumu un iespēju. Šie uzlabojumi sniedz spēju izskaust iespējamās dīkstāves, lai sasniegtu nevainojami augstu pieejamību.