HA cluster Win Server 2012 R2-vel - tapasztalatok?

Microsoft Windows

Sziasztok!

A subject-ben szereplo megoldassal kapcsolatos tapasztalatok erdekelnenek.

Leginkabb ezekre volnek kivancsi:

- Mennyire hibaturo a rendszer? Varatlan esemenykor megbizhatoan reagal? Pl. halozati problema van, jelentos a csomagvesztes, vagy teljesen elszall egy interfesz, vagy leall egy service. Lekezeli rendesen az esemenyt?
- Tenyleg mukodik a cluster akkor is, ha a DC leszakad a halorol? Allitolag el tud indulni a mar felkonfiguralt cluster akkor is, ha epp nem erheto el DC, illetve a futo service-ek se halnak meg, ha nem erik el a DC-t.
- Mik az uzemeltetesi tapasztalatok? Kenyelmesen, kulonosebb nehezsegek nelkul uzemeltetheto egy atgondoltan felepitett cluster?
- Windows Update hogy zajlik? Pl. ha ket node-bol frissitem az egyiket, es utana visszaadom a role-okat, kell szamitani ra, hogy esetleg valami nem fog mukodni?

Egy 2 node-os, IIS8-at es Mssql 2012-t futtato HA clustert szeretnek epiteni, eros vassal, sok memoriaval, a virtualizacio egyelore opcionalis, bar gondolom ugy lenne "trendi". A halozati kapcsolatok redundansak lennenek, es a MS ajanlasa alapjan disk witness is lenne a clusterben, az osztott storage a hosting szolgatato altal adott SAN-on lenne. Ez vajon jol mukodo megoldas lehet?

Tudom, nem feltetlen jo helyen erdeklodok, de hatha van nehany Windows-os kollega is errefele. :)

Gyakorlati tapasztalatokat varok, elmeletben mar nagyjabol kepben vagyok.

Koszonom!

  • 4068 megtekintés

( jonnyuser | 2014. 09. 07., v – 19:54 )

Hello

En sok Windows clustert uzemeltetek.
A cluster network celszeruen onallo halozat, nem az adatforgalmon megy, igy ha az megszakad, a nodeok latjak egymast, nem tortenik failover. Fizikai servereknel ez egy crosskabel lehet a cluster intefacek kozott.
Ha nincs DC is tud mukodni a failover, a szolgaltatasok viszont nem feltetlen tudnak DC nelkul indulni, attol fugg mi a clusterezett szolgatatas.
Az atgondolt clusterekkel semmi problema nincsen, sok eve mukodnek gond nelkul.
Windows Update tamogatott modja a passive node updatelese, atterheles, majd a korabbi aktiv node updatelese. Nekem ezzel sosem volt gond, akkor se, ha SQL servert updateltem. Az updateknek viszont azonosaknak kell lenni mindket nodeon az ajanlas szerint.
A disk witness jo a SANon, csak legyen a szolgaltato storagea is jo minosegu.

Köszi szépen az infókat, óriási segítség!

Mostanra sikerült egy működő tesztkörnyezetemet felépítenem, épp azzal foglalatoskodok, hogy végigpróbálgassam a fontosabb hibalehetőségeket. Úgy tűnik, a DC elérhetetlensége nem okoz leállást, de azért bizonyos funkciók nem működnek DC nélkül. Mivel a DNS redundáns (mindhárom szerveren fut a DNS service, a DC master, a két node pedig slave módban szolgáltatja a zónát), ezért a névfeloldással nincs gond, viszont az erőforrások átadásánál eléggé megnő a downtime, kb. 4-5 percig tart, amíg az MSSQL átkerül az egyik node-ról a másikra. Gyanítom, hogy egy jól működő megoldáshoz 4 szerver fog kelleni, hogy az AD szolgáltatások is redundánsak legyenek.

( ncc1701 | 2014. 09. 07., v – 21:22 )

Vmware alatt bevirtualizálod az egészet, és csoki. :)

( gergelykiss | 2014. 09. 08., h – 00:00 )

Végigszaladtam egy általam összeállított tesztsorozaton, bemásoltam ide is, mert igencsak tanulságos (2 node + 1 DC HyperV környezetben, nem redundáns hálózati kapcsolatokkal):

  1. DC nem elérhető működés közben
  • Reakcióidő: valószínűleg, amíg le nem áll az IIS worker pool, addig nincs gond a cluster működésével
  • Mi történik: lassabb működés DNS timeout-ok miatt, IIS működik, de megbízhatatlan (néha lejön a site, néha service unavailable hiba jön vissza), MSSQL gond nélkül elérhető. Az IIS egyáltalán nem menedzselhető. Erőforrás átadásakor lassabb az átállás (plusz 2-3 perc role-onként), de működik.
  • Helyreálláskor mi történik: a timeout-ok megszűnnek, az IIS ismét működik rendesen
  • DC nem elérhető a cluster elindításakor:
    • Reakcióidő: n/a
    • Mi történik: a cluster elindul, de lassabban a szokásosnál (kb. 5-6 perc)
    • Helyreálláskor mi történik: u.a. mint fent
  • Aktív node szabályosan leáll:
    • Reakcióidő: azonnal
    • Mi történik: kb. 30 másodpercen belül átkerül minden role a tartalék szerverre
    • Helyreálláskor mi történik: failback beállítástól függ, a leállított node újraindítása után azonnal megjelnik a cluster-ben és online státuszt kap
  • Aktív node szabálytalanul leáll:
    • Reakcióidő: kb. 30 másodperc
    • Mi történik: az erőforrások átkerülnek a működő node-ra
    • Helyreálláskor mi történik: failback beállítástól függ, a leállított node újraindítása után azonnal megjelnik a cluster-ben és online státuszt kap
  • Aktív node-on leáll egy service (pl. IIS/MSSQL):
    • Reakcióidő: néhány másodperc (szinte azonnal)
    • Mi történik: a failover beállításoktól függően egy leállásnál újraindul a service, a következőnél pedig átkerül a role a tartalék node-ra (default beállításban ez a folyamat 6 órán belül csak egyszer ismétlődhet).
    • Helyreálláskor mi történik: a service működik tovább
  • Aktív node-nak elmegy a kliensek felé néző hálózata:
    • Reakcióidő: 10 másodperc
    • Mi történik: a role-ok átkerülnek a másik node-ra, az IIS kivételével, az failed státuszt kapott
    • Helyreálláskor mi történik: a cluster hálózat státusza online lesz, a role-ok kiosztása nem változik, ha nincs failback bekapcsolva
  • Aktív node-nak elmegy a storage felé néző hálózata:
    • Reakcióidő: kb 1 perc
    • Mi történik: leállnak a role-ok
    • Helyreálláskor mi történik: a leállt role-ok pár másodpercen belül automatikusan elindulnak. Az IIS failed státuszban maradt, és csak a cluster teljes újraindítása után tudott helyreállni.

    Összegezve: egyetlen DC-vel nem egy életbiztosítás Windows-os cluster-t üzemeltetni, az IIS kifejezetten érzékeny a DC elérhetetlenségére és a hálózati problémákra. Az MSSQL meglepően jól bírja a kieséseket.

    Innentől egyértelmű, hogy kell az a második DC, illetve minden hálózati kapcsolatnak redundánsnak kell lennie a megbízható működéshez.

    Igazabol csak az, hogy az NLB es a failover cluster nem futhat egyszerre.

    Idokozben picit atszerveztem fejben a clustert (aludtam ra egyet :), ha a licenc engedi, kulon rendszerre kerul majd az IIS es az MSSQL, igy vegul 6 szerver lesz osszesen, kulon OS alatt, elvegre igy korrekt (frontend es backend szetvalasztva). Muszaj mindenbol redundans megoldast csinalni, ha tartani akarjuk az elvart 4 kilences rendelkezesreallast.

    53 perc kiesés évente? Meredek! Tervezett vagy tervezetlen kiesésre vonatkozik? Hol a mérési pontja (szolgáltatási végpont)?
    A Neked nyújtott szolgáltatások (hálózat, gépterem stb.) mindegyike jobb négy kilencesnél?
    Nem tervezett hiba esetén milyen gyorsan tudod biztosítani a rendszergazdát, hogy elkezdje a hibaelhárítást? Kiszámoltad, hány ember kell, hogy 7x24-ben mindig elérhető legyen valaki, szabadságokat-betegségeket is figyelembe véve?

    Üdv,
    Marci

    Valóban meredek, ezért is pörgök a témán annyira, hogy még vasárnap is ilyesmivel foglalkozom. :)

    Minden jogos, amit írsz, és sajnos egyelőre úgy tűnik, nem fogjuk tudni vállalni szerződésben a 99,99%-ot, mivel a hosting szolgáltató egyedül a netkapcsolatra vállalja ezt a rendelkezésre állást (ami persze nekünk nem jó, mert így legrosszabb esetben nem marad idő a tervezett leállásokra). Kemény dió, bár van egy olyan sejtésem, hogy a kilencesek halmozása sokszor inkább csak marketing, és azon túl, hogy drágább lesz egy megoldás, nincs valódi előnye.

    Csak zárójelben mondom, hogy az ügyfél először 5 kilences rendelkezésre állást kért, ezt sikerült 4 kilencesre "lealkudni". Simán lehet, hogy végül 99,9%-ban állapodunk meg, de persze az is benne van a pakliban, hogy meg sem rendelik, mert sokallni fogják az árát...