Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!
(Bevezető)
A Windows Server AppFabric Cache egy explicit, eloszott, egységes, memóriabeli adat gyorsítótár.
(minden szó fontos! gondolkodjunk el rajta!)
(Nem véletlen részleteztem ezeket így, fontos dolgok. Ezekből rengeteg minden következik, ha valamit hiányolunk, vagy valamit furcsának találunk ezekben megtalálhatjuk a magyarázatot.)
Miben más ez mint egyéb megoldások? Pl. van az ASP.Net-nek is cache megoldása?!? van de csak az adott kiszolgálón. Pl ha van egy webfarmunk, és egy adott kiszolgálón bekerül vanalmi a cache-be, akkor azt csak és kizárólag az a gép látja… Létezik továbbá olyan megoldás, hogy SQL serverbe perzisztáljuk az objektumokat, s így egy közös pontból elérheti mindenki által az adott objektumot. Pl. a 3.5-ös workflow-persistence szolgáltatásánál hasonló a helyzet: workflow services kiszolgálóból lehet N darab, de mind ugyan azt a pers. tárat használja, így bárhova érkezik be a kérés mindenki eléri a perzisztált workflow-t. (Persze ez nem cache, pusztán csak az elv az érdekes).
Ebben az esetben viszont az SQL server válik szűk keresztmetszetté… amit ugye nagyon nehéz skálázni…
(pl. egy hagyományos web-farm esetében:)
Az ábra érzékelteti, hogy normál esetben minden alkalmazás/kiszolgáló egyedileg kapcsolódik az adatbázishoz, közvetlenül ír-olvas belőle, ennek minden előnyével-hátrányával.
A cache-réteg alkalmazása esetén az adatbázis és az alkalmazás réteg közé kerül az AppFabric cluster. Az alkalmazások normál esetben továbbra is kapcsolatban maradnak közvetlenül az erőforrások kiszolgálójával, kiszolgálóival ( a továbbiakban az erőforrás és az adatbázis/adattár fogalmakat keverve használom, mint ahogy írtam a cache-be bármilyen bináris adat bekerülhet, így pl. akár file gyorsításra is használható), de a cache-kliens-en keresztül a kapcsolatban áll a cluster-rel is. Ha nincs a cache-ben az adat (ez nagyon gyorsan kiderül, a későbbiekben részletezett módon), akkor felolvassa, majd beteszi a cache-be (és használja), és legközelebb már minden kliens eléri amikor szüksége van rá.
Az előző bejegyzésben megfogalmazott követelmények alapján világosan látható hogy a különböző gyorsítandó erőforrásokkal szemben különböző követelmények állnak fent. Ezek koncepcionálisan megjelennek az egész AppFabric Cache architektúrában, így nagyon fontos hogy értsük és tisztában legyünk vele, továbbá fontos hogy egy saját megoldás implementálásakor ezt figyelembe vegyük, mind tervezéskor mind implementáláskor.
Vegyük sorba ezen kategóriákat!
Hogy oldjuk meg ezeket?
1. Particionálunk. N darab cache-kliens elkezdi önteni az adatok a clusterbe, és valami logika szerint valemelyik node tárolja az adott elemet. Nő a sebesség? Nő ‘hát! N gép Nx annyi memória, Nx annyi processzor és Nx annyi sávszélesség.
Hogyan működik ez fizikailag?
(eddig még nem beszéltünk az API-ról, de itt a lényeg hogy minden cache elem egyedi azanosítóval rendelkezik, amit a programozó ad neki. továbbá adhatok régiókat, ami egyfajta kategorizálása az adatoknak, ez fontos szerepet játszik a fizikai megvalósításban is)
Ha nem adok meg régiót, akkor egy előre meghatározott, számunkra érdektelen, logika szerint automatikusan régióba kerül az adat, majd ez alapján bekerül egy range-be, és ez alapján egy adott cache(Velocity)-node-ra. Ebben az elosztásban nagy szerepet játszanak a hash algoritmusok amikkel könnyen kivitelezhető ez a csoportosítás. A lényeg ebben hogy egy régióba tartozó cache adatok egy szerverre kerülnek. Továbbá a hash alapján a kliens villámgyorsan el tudja érni az kívánt adatot, és nem fog gondot, overhead-et okozni a cluster-ben való tájékozódás.
2. Fail-over
Fail-over biztosítására (kiesik N darab cache-node, mert a takarítónű kihuzta a dugót a konnektorból) nincs más teendőnk, mint hogy megmondjuk hogy az adott named-cache-en (egy cache-cluster-en bármennyi cache lehet, ezek egyedileg azonosítottak a nevük alapján) mennyi gép kiesését szeretnénk elviselni. Ha pl. egyet, akkor 2 helyen lesz tárolva az adat, ha kettőt, akkor hármon, és így tovább… Minden elemnek van tehát N darab másodlagos példánya, aminek szerepe csak akkor van ha kiesik az elsődleges:
Látható hogy pl az A objektum a Server1-en előlépett elsődlegessé, ill. a kiesett F-E-C másodlagos elemekből újra készült másodlagos példány a Server1 ill. a Server2-n (Server 2 hősi halála esetén).
Mindez automatikusan, aszinkron módon türténik, nekünk csak 2-3 konfigurációs bejegyzést kell tenni. Persze ekkor ha van 10 gépünk 2 gbyte memóriával, és 2 gép kiesését szeretnénk elviselni, akkor 10*2/3 gbyte hely áll rendelkezésünk.
Ennyit el kell viselnünk, de amúgy szerintem zs-e-n-i-á-l-i-s!!!
3. Konkurencia.
Ennek megvalósítása biztos nem volt egyszerű, de szerencsére nekünk a fizikai működéssel nem kell foglalkoznunk, pusztán a már jól megismert optimista vagy pesszimista konkurencia kezelés közül választani, és ez alapján írni a kódót.
Pl. pesszimista konkurencia kezelés (az lokkolás):
(az API-ról a továbbiakban lesz szó, de a fenti ábrán látható hogy a van Get() and GetAndLock() metódus ami értelemszerűen végzi a dolgát, tehát nekünk csak meg kell tervezni és ez alapján implementálni az elvártakat)
Optimista konkurencia kezelés esetén pedig “visszaíráskor” kerül ellenőrzésre hogy az “eredeti” állapot van e még a cache-ben. Ha igen akkor mi vagyunk az elsők így mehet az írás. Ha nem, akkor így jártunk, valaki megelőzött. Ekkor a programozó dolga hogy kezelje a különböző lehetőségeket.
A fent megismert koncepciók véleményem szerint az egész AppFabric-Cache megoldás alap-pillérei. Nagyon fontos hogy e képességeket/lehetőségeket figyelembe vegyük amikor döntünk a használata mellett. És ha már döntöttünk, akkor ezt az adott architektúrába illesztéskor kellő gondossággal tegyük.
A továbbiakban látni fogjuk részletesen az AppFabric Cache használatát (API), azt hogy hogy illeszük ezt egy meglévő rendszerbe, ill ha olyan szerencsés helyzetben vagyunk hogy most építünk 0-ról rendszert, akkor miként tervezzük azt úgy hogy bármikor, akár generikus módon, egy cache-réteg legyen “beszúrható” a rétegek közé.
(00:45 +1 server online betétel a clusterbe, 2:00 +1 server online betétele a clusterbe)
(láthatü a közel lineáris áteresztő-képesség növekedés, 3. servernél már a test-kliensek véges száma miatt nem lineáris az érték, ill. latency végtelenségig nem csökkenthető, van egy fizikai korlát)
És persze nem elhanyagolható a biztonság, ill. a menedzselhetőség kérdése sem, a mindenféle load- és fail-over teszt mellett. Különben mi értelme lenne bonyolítani az architektúrát?!?
Ezek következnek most!
Adott a következő helyzet:
Van egy kis ‘számítástechnikai kereskedésünk, és mivel nagyon-nagyon 21. századi módon szervezzük a cégünket, szükségünk van egy komoly kereskedelmi rendszerre, amit megtámadunk több oldalról:
Rendszerünket a 18. Programozó és Bélyeggyüjtő Közhasznú Kft, átadja, majd 1-2 hónapig tökéletesen működik a “2-3” rétegű architektúra… És mivel az üzleti modellünkben nincs hiba, és gondolván a magyarul nem beszélő világpolgárokra akik tőlünk szeretnének vásárolni, már előre lokalizált az alkalmazásunk, így egyszer csak betámad minket a világ!!!
Az elején persze örülünk, dől a zsé. Aztán az oldal elkezd haldokolni. Winchesterek pörögnek, processzorok izzadnak… nincs mit tenni megtámogatjuk egy-két giga rammal a gépet, dobunk bele még egy procit… Kitart legalább egy hétig.
Ekkor megszületik a döntés még egy gép kell!!! SQL server szedi a sátorfáját és elköltözik másik gépre… huh. probléma megoldva. egy hétre.
’szerencsére sql programozó kolléga munkájában nincs kivetnivaló, az SQL adatbázis sem túl bonyolult (Customers-ProductCategories-Products-ProductPhotos-Inventories-OrderDetails-Orders sémánál megáll), termékből sincs sok, így egy kis performance analízis után azonnal látszik hogy a WEB-SERVER a ludas a sok lekérés miatt, no meg a képek!!!! mindeki látni akarja mit vesz meg!!! oldalról, elölről, kicsiben, hd-ben… Így készül egy cluster, loadbalancing… minden ami kell.
Eldöcög.jólesz.
Aztán persze ügyes programozó készít egy túlt, amivel Excel táblából importálni lehet termékeket a rendszerbe, és hirtelen lesz 1000 termék helyett 100.000, a hozzá tartozó képekkel, leírásokkal és még 100.000 elégedett vásárlóval, az akciókról nem is beszélve… SQL szerver ugyan nem száll el exponenciálisan ( bírná a terhelést ha 22Ghz-es lenne 30Gb cache-el, tehát skálázható elméletben,de akkor is…), de képtelen feldolgozni a sokszoros kérést….
Nincs más hátra mint architektúrális (ÁT)tervezés!!! (Vagy persze bele lehet ölni végtelen mennyiségű jó kemény magyar forintot több és több vasba, aminek csak az áramszámlája elviszi a hasznot)
Szakértőnk elemezvén a helyzetet arra a megállapításra jut, hogy az architektúra annyira nem feltétlen rossz, csak egy kis furfang kellene, mert tulajdonképpen az idő(erőforrások) nagy részét a termékek leírásának/adatlapjának az előkeresése, ill. a képek kiszolgálása viszi el. Továbbá erőforrás igényes és körülményes a raktárkészlet információk kezelése a megrendelések szempontjából. Egy termékből nem azt tartjuk nyilván hogy 5 darab, mert akkor csak azt kell figyelni hogy nagativba ne menjen a készlet, hanem minden egyes darab egy sort jelent egy táblában (az egyszerűség kedvéért tekintsük úgy hogy minden számítástechnikai termék egyedi azonosítóval rendelkezik. tehát nem csak a processzor, winchester, alaplap,stb. hanem minden…) (Ha ebbe nehéz belegondolni, akkor hozhatjuk példának a jegyásursítást. Ha helyre szóló jegyek vannak akkor egy jegyet pontosan egyszer lehet eladni.) Vagyis egyedi erőforrásként kell(ene) kezelni. Ez megnehezíti egy csöppet a helyzetünket (a cache-elése az ilyen adatoknak kihívás!!!).
Probléma még, mivel júzerikszperienből nem adunk alább, a session jellegű adatok megfelelő kezelése:
web-farm esetében A szerverren bejelentkezik Béla, majd a load-balancer valami miatt, pl A szerver hősi halála okán, B szerverre küldi a következő kérést… ekkor ugye érheti meglepetés Bélát…
(ugye ismerős? találkozhatunk hasonlóval, lehet ez webshop, közösségi oldal, valamilyen hullámzó terheltségű oldal, pl. egy foci-bajnoskság, póker-bajnokság oldal, stb.)
Szakértőnk elmélázik, hogy hogy is lehetne megoldani a helyzetet, és arra a nem meglepő következtetésre jut hogy bizony ide olyan gyorsítótár szolgáltatás kellene, mely nem bonyolítja túl az architektúrát, megfelelően kihasználja az erőforrásokat annak érdekénen hogy tehermentesítse az SQL szervert (amit ugye nehéz egy bizonyos szint főlé skálázni), villámsebesen kiszolgálja az alkalmazás motor által kért kéréseket, mindezt persze úgy hogy választ ad a fent részletezett problémákra, és teszi ezt programozó barát módon ( na jó, rendszergazda és programozó módon).
Szakértőnk nekikát és felvési az igényeket, hogy házalni tudjon vele, azon meggyőződéssel hogy ő márpedig ebből nem enged!!!
Nos… azért ezt nem programozzuk le jövő hétre, ugye?!? Szerencsére nem is kell!!!
Windows Server AppFabric (született Velocity, Microsoft Distributed Cache)
(nincs köze az Azure AppFabric-hez, lsd névkommandós bejegyzés)
A Windows Server AppFabric cache szolgáltatása képes kezelni a fent vázolt helyzetet. Úgy gondolom hogy akkor is érdemes ezt az oldalát is ismerni az AppFabric-nek (nem csak a WCF+WF-t) és a .Net 4.0-nak, ha éppen nem olyan rendszer bütykölünk a garázsban ami 1.000.000 usert szolgál ki terrabyte-os adatbázisok felett. Ugyanis sose tudhatjuk hogy mikor válik ilyenné a rendszerünk :D, másrészről pedig nem feltétlen kell itt 10-20 gépes cache rétegekre godnolni, kis méretekben is hasznos tud lenni!!!
És miért is AppFabric? Beszéljenek a számok:
(ez egy quad gép, de kb 2008-ból)
Ezért tervezem hogy a következőkben megismerkedünk az AppFabric Cache hátterével (architektúra, mit tud, hogyan tudja, hogyan kell programozni), és különböző esetek segítésével megnézzük a teljesítményeket…
E sarkított bevezető után kitérünk egy ilyen cache rendszer sajátosságaira, és kirészletezzük a “specifikációban” megfogalmazott elvárásokat ill. következményeit. Vagyis szó lesz arról hogy hogyan kategorizáljuk a cache-elendő adatokat, hogy a kívánt célt érjük el (Katalógus adat->írtó gyors legyen, nagy áteresztő képességgel; Session adat->biztosított legyen, pl. HW hiba esetén; Katalógus adat-> zárolások).
Miután áttekintettük az elméletet megismerkedünk az API-val, vagyis hogyan programozzuk a kicsikét, ill. hogyan illeszthető mindez egy (meglévő) architektúrába…
S végül a legfontosabb, ha sikerül összehozni egy 5-10 gépes játékteret, performancia teszt alá vetünk egy-két állatorvosi-lovat és ASP.Net weboldalt, eljátszva az összes szituációt (kihuzza a takarítónő a szervert, hogy mögötte is feltakarítson, akciót hirdetünk 1 napra és felmegy a terhelés 3-5X-re).
És hogy addig se unatkozzunk, ajánlom figyelmébe mindenkinek a lenti linkek mögötti tartalmat, továbbá Tóth László (Tocsi) barátom előadását a Visual Studio 2010 bemutató eseményen.
Információk a Windows Server App Fabric Cache-ről:
(Javaslom hogy a fenti listán idősorrendben menjünk, ugyan a 2008-as PDC előadás környékén még csak CTPx volt, de nagyon-nagyon hasznos infók hangzanak el az egész KONCEPCIÓVAL kapcsolatban, nem túl célravezető a végén kezdeni)
…ez itt a kérdés.
Elkezdtem írni magamnak egy listát, hogy mivel szeretnék, akarok, kellene megismerkedni a közeljövőben, hogy tartsam a lépést, ill. mi az a téma ami érdekel szívesen elmélyednék benne. mert érdekel.
Akkora a lista hogy csoportosítani kell 😀
(amit lehet ezer módon…)
Elkeserítő
Persze gyakorlatilag majdnem mindent felírtam ami körül most mozgás van, de akkor is. Akármilyen sapkát húzok is fel (Web programozó, desktop programozó, elszotott programozó, architect, stb.) legalább a felét akkor is ismerni kell ezeknek, tehát nem tud kibújni az ember a feladat alol, vagyis hogy megtanulja a fentieket.
Amiért megosztom veletek ezeket a gondolatokat az az, hogy megkérdezzem ki hogy látja ezt? Van értelme-nincs értelme? Ki hogy bírja munka mellett, tanulás mellett, csajok-XBOX 🙂 mellett?!?!?
http://www.devconnections.com/shows/SP2010ASP/default.asp?s=142
Tehát eszerint VS2010-el együtt a Silverlight 4 is útjára indul…
Lassan ideje lenne már felhoznom a tudásomat Entity Framework témából… Be kell valjam az “előző” verziót sem ismerem A-Z-ig, sőt…
Ennek kapcsán kezdtem el keresgélni honnan is kellene nekiindulni e nagy falatnak, talán ez hasznos lehet más számára is:
Alapok:
EF4:
Ill. találtam egy bejegyzést az ADO.Net team blog-on, amely szintén összeszedi az újdonságokat. Ennek érdekessége hogy azt írják hogy sok dolog a LINQ 2 SQL-ből “jött”. Visszanyal a fagyi 😀
Könyvek :
Hajrá!!!!
Egy érdekes írásra találtam: WPF Application Quality Guide.
Tulajdonképpen egy Guide-line WPF applikációk fejlesztéséhez.
WPF Application Quality Guide v.0.5
HTML : http://windowsclient.net/wpf/white-papers/wpf-app-quality-guide.aspx
 | Sándor - Cool Silverlight demó |
| Attila - Ebook’s |
| Krisztián - Cool Silverlight demó |
| Sándor - Cool Silverlight demó |
| Krisztián - Ingyenes Ebook |
Bátyai Krisztián[KRis] 