Tippek a szerverek fürtözött SQL szerverhez
A kiszolgálók csoportja lehetővé teszi több fizikai kiszolgáló (csomópont) összekapcsolását, amelyek partnerekként szolgálnak a tartalékforrásra való áttérés folyamatában. A klaszter által biztosított redundancia szignifikánsan hosszabb ideig biztosítja a kritikus számára szükséges megszakítás nélküli munkát
műveleteket. 13 éve az SQL Server ™ használatával számos klasztert implementáltam, és minden esetben saját tulajdonságokkal rendelkeztek. Ez a tapasztalat lehetővé tette számomra, hogy olyan tippeket és ajánlásokat fogalmazjak meg, amelyek megkönnyítik és sikeresebbé teszik a klaszterekkel való együttműködést.
1. ábra Egy másik klaszter
Végül a klaszterezés igazi céljának elérése érdekében - magas szintű rendelkezésre állást igénylő szakemberek és megpróbált eljárások szükségesek hibás működés esetén. Bár a fürtözés jó biztosíték a hardverhibák ellen, ez nem akadályozza meg a felhasználók hibáit, például egy fontos táblázatnak egy nem kívánatos adatbázis-kezelővel való lebomlását az éjszaka közepén.
Egy csomóponttal rendelkező klaszterek
Még akkor is, ha csak egy szerverre van szükség, még mindig van értelme gondolkodni egy klaszter létrehozásával egy csomóponttal. Ez lehetővé teszi a konfiguráció későbbi frissítését a klaszterhez, anélkül, hogy újra meg kellene tennie a rendszert. Csak meg kell győződnie arról, hogy a kiválasztott eszköz a Windows Katalógus fürtrészében található.
A csomó későbbi hozzáadásának képessége nemcsak a rendelkezésre állás szintjének javítása érdekében hasznos. Tekintsük a helyzetet, amikor egy bizonyos időpontban megállapítást nyer, hogy a szerver teljesítménye nem elegendő. Ez azt jelenti, hogy szükség van a migrációra, vagyis az idő és erőfeszítés költségeire. Ha egy csomóponttal rendelkező klaszter van, akkor a költöztetés sokkal könnyebbé és kevésbé leállítható. A klaszterhez új csomópont kerül hozzáadásra; Az SQL Server bináris fájljai és szervizcsomagjai az új csomópontra vannak telepítve, majd a kiszolgáló átáll az új csomópontra a failover eljárással. Ezután további javításokat kell telepítenie a szervizcsomag után, végül törölni kell a régi csomópontot. A készenléti időt korlátozza az idő a mentési erőforráshoz való visszatéréshez és frissítések telepítéséhez (ha szükséges).
Természetesen ez újra meggondolta magát. Végtére is létrehozhat olyan parancsfájlokat, amelyek CLUSTER.EXE-t hívnak a csomópont hozzáadásához a Microsoft® Cluster Server (MSCS) szolgáltatáshoz. Mindössze annyit kell tennie, hogy elküldi a csomópont nevét a szkriptnek, a többi pedig saját maga fogja megtenni. Vészhelyzetben az automatizálás valóságos barát.
Néha egy csomópontot adnak a fürtnek, hogy ne cseréljen egy másik csomópontot. Talán hozzá kell adnia az SQL Server további példányait a fürtnek, és minden példányhoz külön lemez erőforrások szükségesek. Bár a kiszolgáló több példánya egy csomóponton futhat, ilyen helyzetben meg kell osztaniuk a processzort és a RAM-ot, ami a teljesítmény csökkenéséhez vezet. Ideális helyzetben csak egy példány kell futnia egy csomóponton. Hogyan garantálhatom ezt, ha átállok egy tartalék erőforrásra? Nagyon egyszerű! Az egyik csomópont nem működhet semmilyen szolgáltatással, és a fennmaradó csomópontok mindegyikén az SQL Server egy példányának futnia kell. Ez az "N + 1" klaszter definíciója: N példányok futnak N + 1 csomópontokon. Az extra csomópont tartalék.
Az SQL Server frissítése
Milyen lehetőségek vannak? Először is tekintse a legdrágább megoldást: egy teljesen új fürt létrehozása, amely új kiszolgálókat és esetleg egy új tárolóterület-hálózatot (SAN) igényel. Valószínűleg megmarad a meglévő hálózati kapcsolók, de ez kimeríti a régi eszközök használatának lehetőségét. Nyilvánvaló, hogy ez nem olcsó megközelítés, de előnyei vannak. Az új berendezések általában jóval jobban működnek, mint a régiek; a lemezek sebessége és kapacitása folyamatosan növekszik. Következésképpen a berendezés megújulása miatt nő a termelékenység. Ahhoz, hogy mindig rendelkezzen a modern felszereléssel, még érdemes bérelni.
Amikor a hardver telepítve van, létrehozhat egy új SQL Server virtuális kiszolgálót, és átmásolhatja a gyártási adatbázisokat, majd az új rendszer átfogó tesztelésére kerülhet sor a potenciális problémák megoldására, mielőtt a kiszolgáló újraindulna. Ugyanakkor létre kell hoznia parancsfájlokat a felhasználói fiókok meglévő szerverről egy újabbra történő átvitelére. (Lásd: support.microsoft.com/kb/246133 (angolul).) Szintén érdemes frissíteni a fiók létrehozási parancsfájlt hirtelen teljes hiba esetén.)
A leállás minimálisra csökkentése érdekében valószínűleg a naplózást kell használni, kivéve, ha az adatbázisok nagyon kicsiek, és nincs idő, amikor nincs felhasználó. A naplózás az átadás előtt elvégezhető. Ezután húzza ki a felhasználókat, vágja le és küldje el a végleges naplót, és mutassa az alkalmazást egy új példányra. (Az alábbiakban a tükrözési adatbázisok szakaszában érdekes alternatíva van a naplók szállítására vonatkozóan.) Ha DNS-álneveket használ, akkor valószínűleg nem kell az alkalmazások új példányba való beillesztésére. Ehelyett csak frissítenie kell a DNS-aliast. Ez a megközelítés a következő előnyökkel jár: ha szükséges, hogy a migrációs folyamat félúton leálljon, és visszatérjen eredeti állapotához, akkor ez a kezdeti állapot legalább elérhető lesz.
Választhat egy kevésbé drága opciót, de bonyolultabb előzetes tervezést igényel. A fürt egy SQL Server kiszolgáló több mint egy példányát támogathatja, de minden példánynak saját lemezerőforrással kell rendelkeznie. Ezért tárolóterület-hálózat (SAN) beállításakor egy logikai egységszámot (LUN) kell fenntartani a jövőbeli frissítésekhez. A frissítéshez telepítenie kell az SQL Server bináris fájlokat erre a lemezforrásra. Ezután tesztelje a rendszert, és amikor minden készen áll, állítsa le az aktuális SQL szervert, mozgassa a lemez erőforrásait a régi SQL Server csoportból, frissítse a függőségeket és helyezze át az új SQL Server példányt. Ezután csatolnia kell az adatbázisokat a régi példányból, és a műveletet elvégezheti. (Előre készített biztonsági másolatokat, ugye?)
Ez a megközelítés kevesebb kiadást igényel, de a kockázat egy részét is magában hordozza. Ha valami baj van, akkor lehetetlen lesz leválasztani az adatbázisokat az új példányról, és visszaadni az eredeti helyükre. Ebben az esetben a helyreállítás csak a biztonsági másolatokból lehetséges, és ez hosszú leálláshoz vezethet.
Alternatív megoldásként két példányt is elhelyezhet az SQL Server a tárterület hálózaton, ha elegendő hely van benne. Ezután helyre kell állítania a gyártási biztonsági másolatokat (és a naplókat) a kiszolgáló új példányára, és folytassa a fent leírtak szerint. Most azonban vannak módok visszavonulásra. Amikor a költöztetés befejeződött, felszabadíthatja a tárolóterület hálózati erőforrásait a régi példányban. E művelet költsége csak az új lemezek ára lesz.
Először is meg fogjuk cáfolni egy általános félreértést. A fürtözött MSCS-t a rendelkezésre állás szintjének növelésére használják, nem pedig a terheléskiegyenlítéshez. Ezenkívül az SQL Server nem rendelkezik beépített képességgel az automatikus kiegyenlítéshez. A terhelés kiegyenlítése az alkalmazás fizikai kialakításával szükséges. Mit jelent ez?
Mivel a táblázat mérete nő, a teljesítmény lebomlása várható, különösen az asztal beolvasása során. Amikor a vonalak száma millió és milliárdos értéket ér el, a szokásos megoldás eddig megosztott reprezentációk használata volt. Ezek a partícionált nézetek ugyanazon sémákból álló táblákból állnak, amelyeket az UNION ALL utasítások tartalmaznak. Ezenkívül az asztalalkatrészek ellenőrzéséhez ellenőrizze a korlátozások beállítását (CHECK utasítás), amely megakadályozza az adatok duplázását a particionált nézetben. Ha az ellenőrzési kényszerben használt oszlop az elsődleges kulcs része, akkor a nézet frissíthető.
Talán van még néhány extra szerver, de ezek nem állnak rendelkezésre a Windows könyvtárcsoportban. Nem akarok új szervereket vásárolni, csak klasztertámogatás esetén, ha szabad szerverek vannak.
A klaszterezés csábító alternatívája tükrözi az adatbázisokat. A tükrözéshez három összetevőre van szükség: a tükrözött adatbázis (elsődleges kiszolgáló), a biztonsági mentési (tükör) szerver és - ha vissza akarunk kapcsolódni a mentési erőforrásra - a harmadik (szolga) kiszolgálót. Dióhéjban, amikor tükrözi az adatbázist, a következő történik: a fő szerveren lévő adatbázisban lévő tranzakció is elindul a tükörben. Ha a fő szerver nem sikerül, akkor az adatbázist áthelyezheti egy biztonsági erőforrásra - egy tükrökiszolgálóra. Ha van egy tanúkiszolgáló, akkor ez automatikusan megtörténik. Tükröződő tükröződést kell beállítani az alkalmazás minden adatbázisához; Rendszeradatbázisok esetén a tükrözés nem áll rendelkezésre.
A fürttől eltérően a tükrözött kiszolgáló az SQL Server különálló példánya; több ezer kilométerre található a fő kiszolgálótól. Gyorsítótárai olyan frissítési műveleteken keresztül érhetők el, amelyek az elsődleges kiszolgálóról megkettőzött tranzakciók eredményeképpen következnek be. Természetesen feltételezzük, hogy a tükörszerver nem tesz semmilyen lépést, kivéve, hogy tükrözött tranzakciókat fogadjon az elsődleges kiszolgálóról. Ebben az esetben a biztonsági erőforrásra való áttérés rendszerint gyorsabban megy végbe, mint a fürtben, mivel a tükrözött kiszolgáló SQL Server már fut. Mivel a gyorsítótár már teljes (legalábbis részben), a kezdeti teljesítmény nem olyan alacsony, mint a klaszter forgatókönyvében. Ne feledje azonban, hogy amikor a tükrözött adatbázis egy tartalék erőforrásra megy, az elsődleges és a tükörszerverek megváltoztatják a szerepüket.
Az adatbázisok tükrözésének hátránya a lemezek kapacitásának kétszerese a klaszterrel összehasonlítva. Továbbá nagyobb számítási teljesítményre van szükség, ha szinkron műveletre van szükség adatvesztés nélkül. Mint már említettük, a magas rendelkezésre állás nem olcsó.
Mivel a tükörszerver nagy távolságra helyezkedik el a fő tükörtől, érdemes tükrözött tükröződést használni a katasztrófa-helyreállítási tervekben (DR-Disaster Recovery). A fürt szolgálhat az első védelmi vonalnak, de mi történik, ha egyszerre alkalmazza a klaszterezést és a tükrözést? Ha a fürtben hiba történik, akkor ha a tükörkonfigurációban van egy tanúkiszolgáló, az utóbbi az elsődleges kiszolgálóvá válik, amíg a fürtözött SQL Server visszatér az internetre. Ugyanakkor szem előtt kell tartani, hogy az új elsődleges szerverről a (fürtözött) új tükörszerverre történő áttérés nem történik automatikusan. Ezért jobb, ha nem engedélyezi a tükrözött adatbázisok automatikus lebonyolítását a klaszterrel együtt.
A tükrözés használatának egyetlen célja nem a katasztrófa-helyreállítás. Ez olyan helyzetekben is hasznos, amikor az elsődleges szerveren frissítési csomagot vagy javítást kell alkalmazni; ebben az esetben manuálisan át lehet váltani egy biztonsági erőforrásra a tükörszerveren. Alkalmazásakor a szervizcsomag vagy gyorsjavításhoz korábbi fő szervere átmenetileg nem elérhető, és a befejezett tranzakciók az elsődleges kiszolgálón, sorban állnak, várva indulás vissza az új tükör (régi fő) szerver. A szervizcsomag vagy javítás telepítésének végén szinkronizálódás következik be, amelynek eredményeként a két szerver teljes mértékben kompatibilis. Most megváltoztathatja az elsődleges és a tükörszerver szerepköröket. A készenléti idő néhány másodperc, amely a tartalékforrásra és a visszafelé történő áttérésre fordított. Ezt a megközelítést használhatja az SQL Server SQL Server egy másik fizikai kiszolgálóra történő átállítására is. Az egyetlen különbség az, hogy nem kell visszamenned.
Növelje a rugalmasságot egy virtuális szerverrel
2. ábra Virtuális kiszolgáló használata
Az SQL Server telepítéséért felelős adminisztrátornak biztosnak kell lennie a kiszolgáló folyamatos rendelkezésre állásának. Ennek eléréséhez a kiszolgálói klaszterezés segít. Ez a cikk olyan kipróbált és tesztelt ajánlásokat javasol, amelyek segítenek Önnek. További hasznos információk találhatók az "Erőforrások fürtözéshez" oldalsávon.