SQL Server High Availability megoldások

Az SQL Server több lehetőséget is biztosít számunkra, hogy magas rendelkezésre állású környezeteket alakíthassunk ki vele. Alapvetően négy út van, amin elindulhatunk:

• Failover clustering: ez a lehetőség egy kicsit kilóg a sorból, mert igazából nem (csak) SQL Server szolgáltatás: megosztott diszk(ek)en és azokat közösen használó cluster node-okon alapuló megoldás. Ezeket az erőforrásokat a Microsoft Cluster Service (MSCS) segítségével egyetlen virtuális erőforrássá gyúrhatjuk egybe a külvilág számára - ez a virtuális erőforrás saját azonosítóval (IP címmel, hosztnévvel, stb) rendelkezik, klienseink ehhez kapcsolódnak, és nem is tudják, hogy a clusteren belül melyik gép szolgálja ki őket.
  Ez egyben azt is jelenti, hogy ez egy szerver-szintű megoldás, tehát nincs lehetőség arra, hogy egy SQL Server instance csak bizonyos adatbázisán használjuk, míg másokon ne.
  Hátránya, hogy a közös disk single point of failure: ha az meghal, oda a cluster (tehát minimum érdemes valamilyen RAID megoldásban gondolkodni adattárolás szinten). Géphalál esetén, vagy ha az oprendszer megáll vagy megállítottuk (lásd: patchelés), a cluster többi gépe pillanatok alatt át tudja venni a kiszolgálást a működésképtelen node-tól, miközben a kliensek ebből jó esetben semmit nem vesznek észre.
  
  
• Database mirroring: ez esetben két adatbázisunk van, egy éles (principal), és annak egy készenléti tükre (mirror).
  Látható, hogy ez egy database-level HA megoldás, tehát egy instance-on belül eldönthetjük, hogy mely adatbázisokat szeretnénk tükrözni, és melyeket nem.
  A tükrözést kétféleképp is megvalósíthatjuk: szinkron (egy művelet akkor tekinthető végrehajtottnak, ha az élesről a tüköradatbázisba is átkerült az adat), illetve aszinkron módon (az tranzakciók az éles adatbázisban kommitálódnak, a tükör a háttérben szinkronizálódik). Az előbbi nagyobb adatbiztonságot, de rosszabb teljesítményt, míg az utóbbi az esetleges adatvesztés (a élesen már igen, de a tükrön még nem commitálódott tranzakciók) kockázata melletti jobb performanciát biztosít.
  A mirror adatbázis a kliensek számára nem használhatók, de készíthetők róla snapshot-ok, amik az adatbázis adott időpillanatbeli, csak olvasható verziói - reporting feladatokra ideális lehet, ha nem szeretnék az éles szervert report-lekérdezésekkel terhelni, és nincs szükség abszolút real-time adatokra.
  
  
• Log shipping: A log shipping némileg hasonlatos a mirroring-hoz, ahelyett vagy amellett is használható. A mirroringgal szemben egynél több másodlagos adatbázist is támogat.
  Gyakorlatilag arról van szó, hogy az éles adatbázisról készítünk egy backup-ot, azt visszaállítjuk, mint másodlagos, majd (konfigurálható) időnként automatikusan log backup készül az élesről, ami a másodlagos adatbázis(ok)on visszaállításra kerül. Így lesz egy (konfigurálható) delay az éles és a tükrök között, ez néha nem jó, néha meg de: például ha egy kikommentezett WHERE feltétellel az összes munkavállalónk nevét Kovács Józsefnévá UPDATE-eljük, nem rossz, ha megvan az eredeti állapot.
  
  
• Replication: A replikáció szintén adatbázis-szintű megoldás, sőt: lehetőségünk van csak az adatbázis bizonyos részeit replikálni. A replikáció a publisher-subscriber modellre épül, az elsődleges adatbázisunk publikálja az adatokat (vagy azoknak egy részét), amire a másodlagos adatbázis(ok) "előfizetnek". A másodlagos adatbázisok használhatók lekérdezésre, vagy bármilyen reporting funkcióra. A replikáción belül három al-típus létezik:
  • snapshot: minden egyes szinkronizációkor egy "fénykép" (snapshot) készül a publisher sémájáról és adatairól az adott időpillanatban és jut el a subscriberekhez. Ebben az esetben a másodlagos adatbázisok csak a szintkronizáció pillanatában lesznek up-to-datek (mint a megállt óra,ami napjában kétszer pontos). Akkor alkalmazható, ha ez megengedhető, vagy csak kis mennyiségű adatot mozgatunk. Hasznos lehet akkor is, hogy az éles adatbázisban rengeteg művelet történik, de minket igazából csak a végeredmény érdekel ("nap végi zárás" - mennyi lett a záróegyenleg?).
    
  • transactional: itt az első lépés egy snapshot replikáció (ezzel áll elő a "tükör"), majd a publisher összes séma- és adatmódosítása real-time eljut a subscriberek felé is, így a tranzakcionalitás biztosított.
    A subscriber adatbázis(ok) írhatók ugyan, de ezek a módosítások nem jutnak vissza a publisher felé, szóval gondoljuk át, hogy mit csinálunk.
    
  • merge: itt is egy snapshot-tal indulunk, de mind a publisher, mint a subscriber(ek) módosításai követésre kerülnek, és alkalomadtán szinkronizálódnak (ez remek lehetőség konfliktusok kialakulására, amikor több subscriber próbálja ugyanazt az adatot módosítani).
    

Bár ez egy relatíve hosszú post, mégis nagyon (nagyon-nagyon-nagyon) csak a felszínét kapargatja a magas rendelkezésre állás, megbízhatóság, skálázhatóság témakörének. Szerencsére elég sok szakirodalom található a témában (én most épp ezt gyúrom, ez ugyan nem csak HA témákat jár körül, de elég jó, küldeném mindenkinek aki szereti; de ezen felül sok más könyv, vagy akár a BOL is rengeteg információval szolgál).
Ennek ellenére szerettem volna összeszedni legalább nagy vonalakban a lehetőségeket, merthogy annyi van, hogy az ember könnyen eltévedhet, még mielőtt egyáltalán elindult volna - ami nem túl szerencsés.

Application Architecture Guide, Second Edition

Megjelent a Microsoft Application Architecture Guide második kiadásának végleges verziója.
Az anyag már egy ideje már elérhető volt, de most nyomtatásba került - így aztán véglegesedett is, a "béta" verzióhoz képest kicsit át lett szerkesztve. Az online verzió szerencsére továbbra is ingyenesen böngészhető, vagy letölthető .pdf formátumban.

A dokumentum célja, hogy iránymutatást és segítséget adjon a fejlesztőknek, architekteknek a .NET platformon futó alkalmazásaik megtervezéséhez - hogyan szervezzék a funkcionalitást rétegekbe, szervizekbe, hogyan építsék, kapcsolják össze azokat, mik azok a szempontok, amiket a teljes alkalmazás-tervezési folyamat alatt érdemes figyelembe venni...

A guide-hoz tartozik egy Knowledge Base is, amiben a műhöz kapcsolódó anyagok találhatók (videók, prezentációk, magyarázatok - de letölthetjük pl. az összes szemléltető ábrát is Visio formátumban).

IIS 6.0 Resource Kit Tools

Mi is az az "IIS 6.0 Resource Kit Tools"? Egy a Microsofttól ingyenesen letölthető tool-gyűjtemény, amivel az IIS 6-unkat adminisztálhatjuk. Legalábbis nagy vonalakban az.
Két féligazság az IIS 6 Resource Kit Tools-szal kapcsolatban:

• Ezek rendszergazdáknak való toolok: többnyire valóban, de van néhány olyan eszköz közöttük, ami nagy segítség lehet fejlesztők számára is (főleg teszteléshez, hibakereséshez).
• Ezek a toolok csak IIS 6 alatt használhatók: többnyire valóban, de van néhány olyan eszköz közöttük, ami webszerver-független.

Ott van pl. a wfetch, amivel tetszőleges HTTP kérést barkácsolhatunk össze magunknak, illetve vizsgálhatjuk meg az arra kapott választ:

A másik hasznos tool a tinyget, ami egy command line HTTP kliens, ami képes sok szálon kérésekkel bombázni a webszerverünket (gyors stress teszhez, performance issue-k debugolásához kiváló):

A Velocity halott. Éljen az AppFabric!

De kezdjük az elején. Mi is az a Velocity? A Microsoft cache megoldása.
De hát eddig is volt cache megoldásuk, nem? System.Web.HttpRuntime.Cache, és kész. Minek új?

Nos, több ok miatt is.
A .NET Framework, illetve a C# nyelv 4.0-ás verziója kapcsán leginkább a dynamic-cal vannak tele a blogok, pedig máshol is történnek érdekességek. Például a caching területén: az eddigi cache megoldással több gond is volt, szám szerint három:

1. Nevezéktanában erősen kötődött a webhez - pedig nem felétlenül csak webalkalmazásokból szerettük használni. Ez inkább csak szépségiba, de valóban nem teljesen keresztény megoldás egy akármilyen library-ba a System.Web.dll-t bereferenciálni, és első látásra elég érthetetlen a HttpRuntime-ot szólógató hívásokat látni.
2. Az API-ját is az elsődleges, webes felhasználáshoz tervezték. Nincsenek benne igazán jól használható bővíthetőségi pontok.
3. Nem elosztott. Minden egyes AppDomain saját cache példánnyal rendelkezik, azaz egy nagyobb (web)farmon ugyanaz az objektum kétszer-négyszer-sokszor is be lehetett cache-elve.

Az első két problámára a cache alapos átfaktorálása lett a megoldás: a .NET Framework 4.0-ban az eddigi funkcionalitás külön assemblybe (System.Runtime.Caching.dll), a System.Runtime.Caching névtér alá költözött, az API-ja alaposan átalakításra került, és számos extensibility point is bevezetésre került.
A harmadik pontra azonban ez nem megoldás. Arra egy külön szoftverkomponenst kellett készíteni, ez lett a Velocity: egy nagyteljesítményű, skálázható, in-memory alkalmazás cache.

A Velocity nem az eddig megszokott, a "te AppDomain-edben lakok, key-ekkel és CLR objektumokra mutató refereciákkal bűvészkedek, gyakorlatilag én vagyok a speciális-szuperokos Dictionary" típusú cache. A Velocity egy out-of-process megoldás (in practice: egy Windows Service), ami szerializált formában képes objektumokat tárolni oly módon, hogy azokat több gép között szétszórja. A cache-be való berakás, az onnan való kivétel transzparens, a klienskódnak nem kell tudni, hogy az objektuma hova kerül, vagy honnan jön, és egyáltalán hány cache szerver ketyeg alatta.

Ezt a Velocity-t már jó ideje fejlesztgeti a Microsoft, a legutolsó, harmadik CTP áprilisban jelent meg - akkor szó volt róla, hogy rá néhány hónapra akár release is lehet. Aztán volt szó egy CTP 4-ről, ami sosem jelent meg, helyette viszont jöttek pletykák arról, hogy majd a .NET 4.0-val együtt, aztán azóta csönd.
Na hát ez a Velocity szűnt most meg. Szerencsére nem őrült meg a Microsoft, mindössze annyi történt, hogy a Velocity a rendkívül fantáziadús "Caching" néven a Windows Server AppFabric része lett.
Az AppFabric WF és WCF témakörben tartalmaz még okosságokat (ezek eddig "Dublin" néven futottak). A nagy örömre mindjárt meg is jelent az AppFabric Beta 1.

A cachingről már nagyon régóta szeretnék írni - ha lesz időm, írok is, mert nagyon pörgős téma mostanság. Esküszök! Lassan úgy is itt vannak az ünnepek, míg más a bejglit tömi, mi lehetne nagyobb mulatság, mint elosztott cache-t tömni?
Na majd meglátjuk. Addig is: viszlát!