AlwaysOn Availability Group: AG vs. FCI vs. DBM

Amikor SQL Server bevezetésről van szó, az egyik legfontosabb kérdés mindig a magas rendelkezésre állás, illetve annak megvalósítása. A legtöbbször nem is technikai okai vannak egy-egy választásnak, inkább költségalapú a döntés vagy az ismeretek hiánya áll a háttérben. Sokszor van az az érzésem, hogy most éppen melyik kezembe harapjak bele, persze csak képletesen. Az alábbiakban a leggyakrabban előforduló eseteket és döntéseink okait elemezném picit (csak a database engine-re vonatkozó dolgokkal foglalkozom, az SSAS, SSRS, MDS, stb. szolgáltatásokkal talán később).

FCI vagy nem FCI

A Failover Cluster Instance (FCI) egy érdekes megoldás, egyetlen esetben szoktam csak javasolni, minden egyéb esetben inkább a Database Mirroring (DBM) vagy az AlwaysON Availability Group (AG) megoldásokat részesítem előnyben. Ez az egyetlen eset, amikor a replikáció disztributor adatbázisának kell HA (High Availability) megoldás. mivel ez csak SQL Server FCI segítségével lehetséges.

Hogyan is néz ki egy cluster? Hát nagyjából így:

Látható, hogy optikán kapcsolódik a SAN-hoz a két node. Ez nem egy olcsó megoldás. Arról nem is beszélek, hogy MPIO esetén, illetve ennek HA biztosítása érdekében már több FC controller és több SAN switch-re lehet szükség. Ezek sem az olcsóságukról híresek. Persze lehet mondani, hogy iSCSI, erre én azt mondom, hogy: csak akkor ha tényleg nincs más lehetőség!  Denny Cherry írt a különböző csatlakozási formákról egy elég jó összefoglalót angolul a http://sqlmag.com/blog/should-i-be-using-fiber-channel-iscsi-or-fcoe oldalon.

  • Előnyei: 
    • Instance szintű védelmet ad.
    • Nem kell a szerver szintű objektumokat – pl.: login – másolni a másodlagos szerver(ek)re.
    • Standard Edition esetében is elérhető szolgáltatás, maximum 2 node.
    • A klienseknél nem kell semmit átállítani egy failover után, nulla konfigurációt igényel.
    • A SAN végett könnyen bővíthető és átkonfigurálható a lemezek száma és a kiosztott terület.
  • Hátrányai:
    • Általában drága/drágább, mint bármely másik megoldás.
    • Ha a SAN kiesik, akkor vége történetnek, annyi a magas rendelkezésre állásnak. Persze lehet a SAN is hibatűrő, de ne legyünk ennyire optimisták  (SAN adminok kíméljetek :-))
    • A failover során egy teljes crash recovery történik, ami azt jelenti, hogy az SQL szolgáltatásokat a cluster elindítja, az adatbázisokon a REDO és az UNDO – tranzakciók előre és visszagörgetése – megtörténik, ez pedig sok idő lehet.
    • A failover után egy un. cold szerver állapotot kapunk: se adat cache, se proc. cache nincs.
    • Sávszélesség korlátok (pl. SAN switch 4-8-16Gbps, FCoE és iSCSI az ethernet sávszélessége).
    • Esetek többségében nehéz az IO problémák feltárása, bizonyítása.

Kimondhatjuk, hogy a magas ár mellett egy egység kiesése (SAN) teljes leálláshoz vezethet. Éppen ezek miatt sem szoktam ajánlgatni ezt, de volt már rá példa, hogy csak ezt a megoldást lehetett bevezetni a helyi IT nyomására. A legtöbb esetben a ���nyomás” oka rém egyszerű volt: nem akartak új megoldást megtanulni. Pedig ha egy kicsit utánaszámoltak volna, rengeteg pénzt takaríthattak volna meg, amiből jutott volna oktatásra is ;-).

Másik érdekes történet, amikor egy cég újra feltalálja a kereket: nevezetesen nem jó nekik az MCS – pre 2008 – vagy a WSFC, hanem vesznek egy másik cégtől egy Windows-os cluster szolgáltatást (még jó, hogy nem íratták meg házon belül, az lett volna még szép :-)).  Ez sem a költséghatékonyságot hivatott növelni.

Database Mirroring

Gyakorlatilag az AG elődjéről beszélünk, annyit azonban fontos megemlíteni, hogy ez csak egy adatbázis egyidejű átállására alkalmas. Akkor miért ezt ajánlgatom? Mert jobb! Ha megadja magát egy lemez, vagy az összes lemez egy szerverben az nem okoz szolgáltatás kiesést, hisz a másik szerverben ott vannak a saját lemezei, szemben a SAN + FCI, ahol ha a SAN kiesik, a szolgáltatás nem lesz elérhető a továbbiakban. Így sokkal jobb rendelkezésre állást biztosít, nem is beszélve a további előnyeiről.

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

A teljesség igénye nélkül pár pontban előnyök és hátrányok:

  • Előnyei:
    • Olcsó, de legalábbis nagyságrendekkel olcsóbb lehet, mint egy cluster.
    • Minden szerver saját lemezekkel rendelkezik: egy lemez (tömb) kiesése, nem okoz szolgáltatás leállást.
    • A másodlagos – mirror – szerver egy un. hot standby: van data cache és a proc. cache is.
    • A failover szinte azonnali, esetek többségében gyorsabb, mint FCI esetében.
    • Ha a mirror csak a magas rendelkezésre állás miatt van, akkor nincs licensz költsége, lásd itt.
    • Automatikus page repair.
    • Standard Edition esetében is elérhető szolgáltatás (néhány korlátozással).
    • Transparent Client Redirect vagy FAILOVER PARTNER a connection string-ben.
  • Hátrányai:
    • Nem lehet több adatbázist egyszerre átállítani a másodlagos szerverre (saját kód nélkül).
    • Csak egy darab másodlagos szerver lehetséges.
    • Dupla adminisztráció (szerver objektumok).
    • Lemezek bővítése és átkonfigurálása igen fájdalmas tud lenni.

Amit szeretnék kiemelni, az a hot standby és a saját lemezek: ezek a fő érveim az FCI ellenében, persze az ár sem utolsó szempont.

A hátrányoknál említett egy másodlagos szerver is csak addig igaz, amíg nem állítok be egy Log Shipping-et is a DBM mellé. Ilyet lehet? Hát persze, és nagyon jól működik! Sajnos a DBM és a LS csillaga leáldozóban van, már az új szerverek esetében az AG szolgáltatást állítom be.

Availability Group

Meg is érkeztünk a lényeghez. Ez gyakorlatilag egy database mirroring extended edition :), ami kombinálja a WSFC és a DBM előnyeit (és hátrányait is).

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

  • Előnyei:
    • Minden előny, ami a database mirorring-nál felsorolásra került.
    • Több másodlagos szerver lehetséges (3 szinkron és összesen max. 5 szerver SQL 2012 esetén).
    • Egyszerre több adatbázist is érinthet az átállás.
    • AG Listener-ek segítségével a klienseknél nem kell semmit átállítani egy failover után.
  • Hátrányai:
    • Csak SQL Server Enterprise Edition esetén áll rendelkezésre ez a szolgáltatás.
    • Üzemletetés komplexitása.
    • Dupla adminisztráció (szerver objektumok).

Összegzés

Figyelembe véve a fentieket, az alábbi táblázat segíthet a megfelelő megoldás kiválasztásában, de az üzleti igények felülírhatják az egészet.

Én a részemről az Availability Group mellett teszem le a voksom: ár-érték arányaiban és üzemeltetési szempontok miatt is. Az FCI ettől függetlenül újra és újra előjön, van olyan nagyon komplex infrastruktúra, ahol minden AG node egyben egy FCI is és a SAN is “duplán” áll rendelkezésre. Drága lett a megoldás, de az üzleti igények megkövetelték (szép nagy házat tudnék venni az árából :-)). 

A további bejegyzéseimben remélem sikerül megmutatni, hogy miért is tettem le a voksom az AG mellett és milyen érdekes dolgokat lehet ezzel művelni.

Add comment