Aktív/aktív SQL cluster

(Ezt a cikket küldöm Tonesznak meg mindenkinek, aki szereti:)

Mint említettem, mostanság éppen próbálok egy aktív/aktív SQL clustert építeni, de mivel sokaknak ismeretlen a téma cégen belül is, kicsit úgy érzem magam, mint Gallilei: hol szép, hol kevésbé szép szóval próbálnak jobb belátásra bírni. Úgyhogy gondoltam, hogy ahelyett, hogy engedek, inkább leírom, hogy hogyan is működik a Microsoft eme remek találmánya.

Kezdjük az elején, a cluster fogalmánál. A Microsoft cluster egy failover cluster, azaz hibatűrésre van kitalálva. Nem várhatunk tőle nagyobb teljesítményt, párhuzamosítást, satöbbit. Egy adott feladatot (tipikusan valamilyen hálózati szolgáltatás nyújtása) egy adott pillanatban csak egy gép végez. Az SQL Server külön fel van okosítva arra, hogy ő hogyan is fusson egy clusteren, úgyhogy már egy “sima” aktív-passzív cluster is okozhat zavart arra fel nem készített fejekben. Ahhoz, hogy SQL clustert építsünk, először is kell telepítenünk két Windows 2003 Enterprise Editiont (a 2008-as clusteringhez még hülye vagyok egyelőre, elég sokat változott) két azonos hardverre (izé, működik különböző vasakkal is, csak problémáink lesznek a supporttal, meg esetleg a clusterrel is). Kell továbbá plusz egy IP cím és egy hozzá tartozó hálózati név, valamint egy megosztott diszk (a quorum, mely általában a Q: betűt szokja kapni), melyet mindkét gép (avagy node) lát lokális diszkként (SAN, DAS, vagy csak egyszerűen iSCSI). Nem kötelező, de ajánlott még egy heartbeat hálózati kapcsolat a gépek között, ez két node-os clustereknél gyakran egy keresztkábellel megoldható (ha a távolság elég kicsi a fizikai gépek között). Ha ezek mind megvannak, akkor az első node-on (CLNODE1) elindítjuk a cluadmin.exe nevű kütyüt, és építünk egy új clustert, megadva a cluster nevét (MYCLUSTER), IP-jét (172.18.1.104). Majd a második node-on is elindítjuk ezt, és hozzáadjuk őt az új clusterhez. Ezzel elértük az alsó, szürke keretben látható állapotot: van egy Microsoft failover clusterünk, mely ebben a pillanatban még semmilyen gyakorlati hasznot nem hajt. (Több, mint két node-os clustert is lehet építeni, a második node-on végrehajtott lépések ismételgetésével.) Amikor módosítunk a resource-okon vagy a node-okon, érdemes mindig kipróbálni, hogy mindegyik node át tudja-e venni azt, amit át kell tudnia venni, azaz működik-e a failover funkció.

Építsünk rá egy SQL clustert is. Ehhez hasonló dolgok kellenek, mint az előbb: diszk, IP cím + hálózati név. Plusz SQL telepítő. SQL 2005-től apró, de a pénztárnál jelentősnek tűnő öröm, hogy nemcsak az Enterprise Edition clusterezhető, hanem a Standard Edition is, igaz utóbbi csak két node-ra, de úgyis ez a leggyakoribb. A telepítés megkezdése előtt hozzunk létre egy új resource groupot a cluadminban, és tegyük bele az SQL-nek szánt diszkeket. Teszteljük le, hogy mindkét node tudja-e birtokolni a diszkeket (erről Andor tudna mesélni). Fontos tudni, hogy az SQL Server csak ezekre a diszkekre enged majd adatbázis fájlokat tenni. A telepítő elvárja azt is, hogy fel tudjunk mutatni egy domain csoportot, amit felruházhat minden node-on az SQL Server futtatásához szükséges jogokkal. Ezt érdemes előre megcsinál(tat)ni és beletenni az SQL service-eket futtató technikai accountot.

És már kezdhetjük is a telepítést. A telepítés során láthatjuk, hogy a virtual server nevére kíváncsi a telepítő – ez az a hálózati név, amit előre beregisztráltunk a DNS-be az SQL Server részére (SQLCLUSTER1). Emellett pedig még az instance nevére is kíváncsi lesz: default vagy named, és ha named instance, akkor mi a neve. Az első SQL clusterünk minden további nélkül lehet default, vagy amit akarunk. Egyébként a szokásos kérdések jönnek, majd feltelepíti az installer az SQL Server failover clusterünket, és megkapjuk a középső téglaszínű téglalapot, melyben a nyilak jelzik a függőséget: az SQL Servernek kell az összes diszk plusz a network name (ami pedig az IP címtől függ értelemszerűen) ahhoz, hogy el tudjon indulni, az SQL Agentnek meg az SQL Server, de ebben nincs semmi meglepő. És íme, az SQLCLUSTER1 nevű SQL szerverhez már lehet is csatlakozni.

Van viszont néhány dolog, amire jó gondolni:

  • Az Integration Services és az SQL Browser nincsenek clusterezve, ők ugyanolyan mezei service-ek, mint máskor.
  • Az adatfájlok egy példányban találhatóak a shared diszkeken, melyekhez egyszerre csak egy node férhet hozzá. (És ezzel meg is találtunk a single point of failure-t a failover clusterben – megfelelő diszk alrendszerrel jelentősen csökkenthető a kockázat.)
  • Az alkalmazás binárisai két példányban találhatóak meg, mindkét node-nak a saját, lokális diszkjén, tehát mindkét gépen van külön C:\Program Files\Microsoft SQL Server\… könyvtár.
  • Az SQL Server a cluster IP megadott portján figyel, tehát a node-okon kiadott kapcsolódások a . vagy (local) szerverekhez csúnya véget érnek (hacsak nem installáltunk fel lokálisan is egy nem-clusterezett SQL Servert, ami nem lehetetlen, csak perverz). A mellékelt ábrán pl. akármelyik gépen fut éppen a SQLCLUSTER1, csak a 172.18.1.115 IP 1433-as TCP portján figyel a szerver, a 172.18.1.101 és 102 1433 portja be van csukva, senki nincs ott.
  • Az SQL Server igazából magasról fütyül a cluster groupra, tehát nem érdekli, hogy hol van (ha egyáltalán fut) a cluster név és IP.
  • Ha szeretnénk elosztott tranzakciókat, akkor az MSDTC-t is clusterezni kell.

Mostanra tehát van egy failover clusterünk. Mitől lesz aktív/aktív a cluster, ha egyszer ez egy failover cluster, ahol egyszerre csak az egyik node lehet aktív? Az elnevezés pongyolasága sokakat megtéveszt, hivatalosan ezt multiple-instance cluster néven találtam meg az MSDN-en. Szóval annyi történik, hogy installálunk még egy SQL Server instance-ot, külön resource-okkal, és innentől kezdve az egyik node-on fut az egyik instance, a másikon a másik, tehát mindkét node aktív, vagyis a clusterem aktív/aktív. A második instance telepítéséhez megint mindent be kell szereznünk: diszket, DNS-be regisztrált hálózati nevet és IP címet, egyedül a domaincsoportot tudjuk újrahasznosítani. Telepítéskor a virtual server neve az új hálózati név lesz (SQLCLUSTER2), és itt már muszáj lesz instance nevet megadnunk. De miért is? Mert különben nem tud egy node-on futni a két SQL Server, két default instance nem fér meg egy csárdában, ezen a clusterezés sem segít. Mindkét node-on ott vannak a service-ek felinstallálva, és a default instance MSSQLSERVER nevű service-e már foglalt. Nevezzük el TEST-nek ezt az instance-ot. Így létrejönnek mindkét node-on a MSSQL$TEST és SQLAgent$TEST servicek a named instance-hoz. És íme, megcsináltuk a felső téglaszínű téglalapot is a képről, készen van a török basa aktív/aktív SQL cluster. Az új darab SQLCLUSTER2\TEST névre hallgat.

A dologban van néhány finomság: az instance-ok egymástól teljesen függetlenek, leszámítva azt az apróságot, hogy ha véletlenül egy node-on futnak, akkor kegyetlenül fogják ölni egymást erőforrásokért. Ebből következik, hogy a dizájnban kell hagyni tartalékot, azaz a két instance-nak elfogadható szinten kell futnia egy fizikai gépen (bármelyiken a clusterből). Kedvencem, hogy az összes instance figyelhet a 1433-as porton, hiszen mindegyik a saját IP-jének a 1433-as portján figyel. Ezt a beállítást azért konzervatívabb helyeken istenkísértésnek hívják, én is örülök neki, és eszem ágában sincs használni. Mivel az instance-ok függetlenek, ezért függetlenül lehet patchelni is őket. SQL 2000/2005-nél az aktív node-on kell elindítani a patch installert, ami sajnos ugyanúgy szolgáltatáskiesést fog okozni, mint a nem-clusterezett esetben, amíg fut.

A koncepció fő előnye az, hogy megszűnik az 50%-os hardverpazarlás, ami az aktív/passzív cluster velejárója, gyakorlatilag a plusz memória a node-okba a többletköltség. Hátránya pedig az (az egy lábra billenéskor bekövetkező teljesítményesés mellett), hogy ha meghal mindkét node, akkor egy ideig műsorszünet van két failover clusternél. Ez persze így van a/p clusternél is, de ha két a/p cluster van, amik egymásra teszik a mirrorozott/logshippelt adatbázisaikat, akkor a rendszer három gép halálát éli túl, cserébe két gép soha nem csinál semmit. Ebben a kérdésben mindenki döntsön maga tapasztalatai alapján. Aki már több gépét látta elfüstölni, az persze kicsit visszafogottabb, és meg is értem őt. Én szerencsére már hat éve használom ugyanazon, általam nagyon szeretett hardvergyártó szervereit (de nem csinálok ingyenreklámot egy cégnek, amelyik rettenetes felügyeleti rendszert és egyéb szoftvereket gyárt :P), és annak az esélyét, hogy 24 órán belül meghal mindkét node, nagyon alacsonynak látom, úgyhogy én simán belevágok.

4 Comments

  1. Tonesz:

    Szia,

    köszi! Holnap kezdünk neki előreláthatólag, így azért már gördülékenyebben fog menni, remélem.:)

    Köszi mégegyszer!

  2. Erik:

    Szívesen. Majd írd meg, hogy muzsikál, kíváncsi vagyok rá, hogy tetszeni fog-e. Én imádom a konstrukciót.
    Erik

  3. kriz:

    Szia Erik!

    köszi infokat, egy dolgot azonban nem látok tisztán. Egyszer van a winclusternek egy közös Ipje és a gépeknek fizikai IPje, ez tiszta sor. Ez a szürke ábra. De hogyan kell a narancssárga boxokat értelmezni, amik külön IPkkel vannak, azok virtual szerverek ?
    A narancssárga boxokon lévő sql szerverek gondolom, a saját lemezeken kívül a szürkén látható Q közös osztott lemezt érik el DB szempontjából ?
    Mint látom 1 éves kb a cikk, azóta van e bármilyen egyéb fejlemény? mi 2k8 clusterre húzzuk az egészet. Az hogy a/p vagy a/a lesz ügyfél és pénztárca függő lesz, hisz A/A nál 2 sql licence kell ahogy írtad. Gondolom 2005/2008 között nincs nagy különbség a/a a/p tekintetében.

    Köszi előre is a választ.
    Üdv,
    kr

  4. Erik:

    Szia!

    A narancssárga boxok a cluster resource groupok. Lehetne több resource group is, tehát akár 4 SQL Servert is futtathatnánk a két gépen, ha úgy akarnánk.

    A diszk elérésnek két feltétele van: 1. Azonos resource group. 2. Az SQL Server service dependál a diszken. Az ilyen diszkeket tekinti “saját” diszknek a SQL, a többi diszket úgy használhatod, mintha másik gépbe lenne dugva: backupot tehetsz rá, adatbázist nem. Tehát a Q-t általában nem használhatod az SQL-ből, és nem is ajánlom, hogy megtedd, mert ha véletlen betelne, akkor reszeltek a clusternek amíg nem tudsz törölni róla (ami kicsit nehéz lesz, mert sehol sem indul el a cluster service ezek után, és senki nem tudja belockolni a diszket). Ez persze a 2008-as clustereknél lehet másképpen is.

    SQL 2000 óta nem sok változott a témában, ugyanaz igaz 2005/2008(R2)-re.

Leave a comment