Számos vállalati alkalmazás és virtualizációs rendszer rendelkezik saját mechanizmussal a hibatűrő megoldások kiépítésére. Pontosabban, az Oracle RAC (Oracle Real Application Cluster) két vagy több Oracle adatbázis-kiszolgáló fürtje, amelyek együtt dolgoznak a terhelés kiegyenlítése és a hibatűrés biztosítása érdekében a szerver/alkalmazás szintjén. Ebben a módban való munkához megosztott tárhelyre van szüksége, amely általában egy tárolórendszer.
Ahogy az egyik cikkünkben már megbeszéltük , magának a tárolórendszernek a duplikált komponensek (beleértve a vezérlőket is) jelenléte ellenére is vannak meghibásodási pontok - főként egyetlen adathalmaz formájában. Ezért egy megnövekedett megbízhatósági követelményeket támasztó Oracle-megoldás felépítéséhez az „N szerver – egy tárolórendszer” sémának bonyolultnak kell lennie.
Először természetesen el kell döntenünk, hogy milyen kockázatok ellen próbálunk biztosítani. Ebben a cikkben nem foglalkozunk az olyan fenyegetésekkel szembeni védelmet, mint például a „meteorit érkezett”. Tehát a földrajzilag szétszórt katasztrófa-helyreállítási megoldás készítése a következő cikkek egyikének témája marad. Itt megnézzük az úgynevezett Cross-Rack katasztrófa-helyreállítási megoldást, amikor a védelem a szerverszekrények szintjén épül fel. Maguk a szekrények elhelyezhetők ugyanabban a helyiségben vagy különböző helyiségekben, de általában ugyanabban az épületben.
Ezeknek a szekrényeknek tartalmazniuk kell a teljes szükséges felszerelést és szoftvert, amely lehetővé teszi az Oracle adatbázisok működését, függetlenül a „szomszéd” állapotától. Más szóval, a Cross-Rack katasztrófa-helyreállítási megoldással kiküszöböljük a meghibásodás kockázatát:
- Oracle alkalmazáskiszolgálók
- Tároló rendszerek
- Kapcsolórendszerek
- A szekrényben lévő összes berendezés teljes meghibásodása:
- A hatalom megtagadása
- A hűtőrendszer meghibásodása
- Külső tényezők (ember, természet stb.)
Az Oracle szerverek megkettőzése magában foglalja az Oracle RAC működési elvét, és egy alkalmazáson keresztül valósul meg. A kapcsolási lehetőségek megkettőzése szintén nem jelent problémát. De a tárolórendszer megkettőzésével minden nem olyan egyszerű.
A legegyszerűbb lehetőség az adatok replikálása a fő tárolórendszerről a tartalék rendszerre. Szinkron vagy aszinkron, a tárolórendszer képességeitől függően. Az aszinkron replikációnál azonnal felmerül a kérdés, hogy biztosítsuk az adatok konzisztenciáját az Oracle-lel kapcsolatban. De még ha van is szoftveres integráció az alkalmazással, mindenesetre a fő tárolórendszer meghibásodása esetén a rendszergazdák kézi beavatkozására lesz szükség ahhoz, hogy a klasztert tartalék tárolóra váltsák.
Bonyolultabb lehetőség a szoftveres és/vagy hardveres tárolási „virtualizálók”, amelyek kiküszöbölik a konzisztencia problémákat és a kézi beavatkozást. De a telepítés és az azt követő adminisztráció bonyolultsága, valamint az ilyen megoldások rendkívül méltatlan költségei sokakat elriasztanak.
Az AccelStor NeoSapphire™ All Flash tömb megoldás tökéletes olyan forgatókönyvekhez, mint például a Cross-Rack katasztrófa utáni helyreállítás Shared-Nothing architektúra használatával. Ez a modell egy kétcsomópontos tárolórendszer, amely szabadalmaztatott FlexiRemap® technológiát használ a flash meghajtókkal való együttműködéshez. Köszönet A NeoSapphire™ H710 akár 600K IOPS@4K véletlenszerű írási és 1M+ IOPS@4K véletlenszerű olvasási teljesítményt is képes nyújtani, ami klasszikus RAID-alapú tárolórendszerek használata esetén elérhetetlen.
A NeoSapphire™ H710 fő jellemzője azonban két csomópont végrehajtása különálló esetek formájában, amelyek mindegyikének megvan a saját másolata az adatokról. A csomópontok szinkronizálása a külső InfiniBand interfészen keresztül történik. Ennek az architektúrának köszönhetően a csomópontok akár 100 méteres távolságra is eloszthatók különböző helyekre, ezáltal biztosítva a Cross-Rack katasztrófa-helyreállítási megoldást. Mindkét csomópont teljesen szinkronban működik. A gazdagép oldaláról a H710 egy közönséges kétvezérlős tárolórendszernek tűnik. Ezért nincs szükség további szoftver- vagy hardveropciók elvégzésére, vagy különösen összetett beállítások elvégzésére.
Ha összehasonlítjuk az összes fent leírt Cross-Rack katasztrófa-helyreállítási megoldást, akkor az AccelStor lehetősége észrevehetően kiemelkedik a többi közül:
AccelStor NeoSapphire™ Shared Nothing Architecture
Szoftver vagy hardver „virtualizáló” tárolórendszer
Replikáció alapú megoldás
elérhetőség
Szerverhiba
Nincs leállás
Nincs leállás
Nincs leállás
Kapcsoló hiba
Nincs leállás
Nincs leállás
Nincs leállás
A tárolórendszer meghibásodása
Nincs leállás
Nincs leállás
Állásidő
A teljes szekrény meghibásodása
Nincs leállás
Nincs leállás
Állásidő
Költség és összetettség
Megoldás költsége
Alacsony*
Magas
Magas
A telepítés bonyolultsága
alacsony
Magas
Magas
*Az AccelStor NeoSapphire™ továbbra is egy All Flash tömb, ami értelemszerűen nem „3 kopejkába” kerül, különösen azért, mert dupla kapacitástartalékkal rendelkezik. Ha azonban összehasonlítjuk egy ezen alapuló megoldás végső költségét más gyártók hasonló megoldásaival, akkor a költség alacsonynak tekinthető.
Az alkalmazáskiszolgálók és az összes Flash tömb csomópontjának összekapcsolásának topológiája így fog kinézni:
A topológia tervezésekor erősen ajánlott a felügyeleti kapcsolók duplikálása és a szerverek összekapcsolása is.
Itt és a továbbiakban a Fibre Channel kapcsolatról lesz szó. Ha iSCSI-t használ, akkor minden ugyanaz lesz, a használt kapcsolók típusaihoz és kissé eltérő tömbbeállításokhoz igazítva.
Előkészítő munka a tömbön
Használt berendezések és szoftverek
A szerver és a kapcsoló specifikációi
Alkatrészek
Leírás
Oracle Database 11g szerverek
két
Szerver operációs rendszer
oracle linux
Oracle adatbázis verzió
11g (RAC)
Processzorok szerverenként
Két 16 magos Intel® Xeon® CPU E5-2667 v2 @ 3.30 GHz
Fizikai memória szerverenként
128GB
FC hálózat
16 Gb/s FC többutas átvitellel
FC HBA
Emulex Lpe-16002B
Dedikált nyilvános 1GbE portok a fürtkezeléshez
Intel ethernet adapter RJ45
16Gb/s FC kapcsoló
Brokát 6505
Dedikált privát 10 GbE portok az adatszinkronizáláshoz
Intel X520
AccelStor NeoSapphire™ All Flash Array specifikáció
Alkatrészek
Leírás
Tároló rendszer
NeoSapphire™ magas rendelkezésre állású modell: H710
Képes verzió
4.0.1
A meghajtók teljes száma
48
Meghajtó mérete
1.92TB
Hajtás típus
SSD
FC célportok
16x 16 Gb port (csomópontonként 8)
Kezelő portok
Az 1GbE ethernet kábel Ethernet switchen keresztül csatlakozik a gazdagépekhez
Szívverés port
1 GbE Ethernet kábel, amely két tároló csomópontot köt össze
Adatszinkronizálási port
56Gb/s InfiniBand kábel
Mielőtt egy tömböt használna, inicializálnia kell. Alapértelmezés szerint mindkét csomópont vezérlőcíme ugyanaz (192.168.1.1). Egyenként kell csatlakozni hozzájuk, és új (már eltérő) felügyeleti címeket kell beállítani, és be kell állítani az időszinkronizálást, ami után a Management portok egyetlen hálózatra kapcsolódhatnak. Ezt követően a csomópontokat egy HA-párba egyesítik úgy, hogy alhálózatokat rendelnek hozzá az Interlink kapcsolatokhoz.
Az inicializálás befejezése után a tömböt bármelyik csomópontról kezelheti.
Ezután elkészítjük a szükséges köteteket, és közzétesszük őket alkalmazásszervereken.
Erősen ajánlott több kötet létrehozása az Oracle ASM számára, mivel ez megnöveli a kiszolgálók célpontjainak számát, ami végső soron javítja az általános teljesítményt (további információ a sorokról egy másikban ).
Tesztkonfiguráció
Tárolókötet neve
Kötetméret
Adatok01
200GB
Adatok02
200GB
Adatok03
200GB
Adatok04
200GB
Adatok05
200GB
Adatok06
200GB
Adatok07
200GB
Adatok08
200GB
Adatok09
200GB
Adatok10
200GB
Grid01
1GB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Grid05
1GB
Grid06
1GB
Redo01
100GB
Redo02
100GB
Redo03
100GB
Redo04
100GB
Redo05
100GB
Redo06
100GB
Redo07
100GB
Redo08
100GB
Redo09
100GB
Redo10
100GB
Néhány magyarázat a tömb működési módjairól és a vészhelyzetekben előforduló folyamatokról
Minden csomópont adatkészletéhez tartozik egy „verziószám” paraméter. A kezdeti inicializálás után ez megegyezik és egyenlő 1-gyel. Ha valamilyen oknál fogva a verziószám eltér, akkor a rendszer mindig szinkronizálja az adatokat a régebbi verziótól a fiatalabbhoz, ami után a fiatalabb verzió száma igazodik, pl. ez azt jelenti, hogy a másolatok azonosak. Az okok, amelyek miatt a verziók eltérőek lehetnek:
- Az egyik csomópont ütemezett újraindítása
- Baleset az egyik csomóponton hirtelen leállás miatt (tápellátás, túlmelegedés stb.).
- Megszakadt az InfiniBand kapcsolat, és nem sikerült szinkronizálni
- Összeomlás az egyik csomóponton adatsérülés miatt. Itt létre kell hoznia egy új HA-csoportot, és be kell fejeznie az adatkészlet szinkronizálását.
Mindenesetre az online maradó csomópont eggyel növeli a verziószámát, hogy a párral való kapcsolat helyreállítása után szinkronizálja adatkészletét.
Ha az Ethernet-kapcsolaton keresztüli kapcsolat megszakad, a Heartbeat átmenetileg átvált InfiniBandra, és 10 másodpercen belül visszatér, amikor helyreáll.
Gazdagépek beállítása
A hibatűrés és a teljesítmény javítása érdekében engedélyeznie kell a tömb MPIO támogatását. Ehhez sorokat kell hozzáadnia az /etc/multipath.conf fájlhoz, majd újra kell indítania a többutas szolgáltatást.
Rejtett szövegeszközök {
eszköz {
eladó "AStor"
path_grouping_policy "group_by_prio"
path_selector "queue-length 0"
path_checker "tur"
funkciók "0"
hardver_kezelő "0"
prio "const"
azonnali hibaelhárítás
fast_io_fail_tmo 5
dev_loss_tmo 60
felhasználóbarát_nevek igen
detect_prio igen
rr_min_io_rq 1
no_path_retry 0
}
}
Ezután ahhoz, hogy az ASM az MPIO-val ASMLib-n keresztül működjön, módosítania kell az /etc/sysconfig/oracleasm fájlt, majd futtassa az /etc/init.d/oracleasm scandisks fájlt.
Rejtett szöveg
# ORACLEASM_SCANORDER: Minták egyeztetése a lemezellenőrzés sorrendjéhez
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Egyező minták a lemezek vizsgálatból való kizárásához
ORACLEASM_SCANEXCLUDE="sd"
Megjegyzés
Ha nem akarja használni az ASMLib-et, használhatja az UDEV-szabályokat, amelyek az ASMLib alapját képezik.
Az Oracle Database 12.1.0.2-es verziójától kezdve az opció az ASMFD szoftver részeként telepíthető.
Feltétlenül gondoskodni kell arról, hogy az Oracle ASM számára létrehozott lemezek igazodjanak ahhoz a blokkmérethez, amellyel a tömb fizikailag működik (4K). Ellenkező esetben teljesítményproblémák léphetnek fel. Ezért szükséges a megfelelő paraméterekkel rendelkező kötetek létrehozása:
parted /dev/mapper/device-name mklabel gpt mkpart elsődleges 2048s 100% align-check optimális 1
Adatbázisok elosztása a tesztkonfigurációhoz létrehozott kötetek között
Tárolókötet neve
Kötetméret
Kötet LUN-ok leképezése
Az ASM köteteszköz adatai
Kiosztási egység mérete
Adatok01
200GB
Az összes tárolási kötet hozzárendelése a tárolórendszer összes adatportjához
Redundancia: Normál
Név: DGDATA
Cél: Adatfájlok
4MB
Adatok02
200GB
Adatok03
200GB
Adatok04
200GB
Adatok05
200GB
Adatok06
200GB
Adatok07
200GB
Adatok08
200GB
Adatok09
200GB
Adatok10
200GB
Grid01
1GB
Redundancia: Normál
Név: DGGRID1
Cél: Rács: CRS és szavazás
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundancia: Normál
Név: DGGRID2
Cél: Rács: CRS és szavazás
4MB
Grid05
1GB
Grid06
1GB
Redo01
100GB
Redundancia: Normál
Név: DGREDO1
Cél: Az 1. szál naplójának újrakészítése
4MB
Redo02
100GB
Redo03
100GB
Redo04
100GB
Redo05
100GB
Redo06
100GB
Redundancia: Normál
Név: DGREDO2
Cél: Az 2. szál naplójának újrakészítése
4MB
Redo07
100GB
Redo08
100GB
Redo09
100GB
Redo10
100GB
Adatbázis beállítások
- Blokkméret = 8K
- Csereterület = 16 GB
- Az AMM (automatikus memóriakezelés) letiltása
- Az Átlátszó hatalmas oldalak letiltása
Egyéb beállitások
# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-max = 6815744
✓ kernel.shmmax 103079215104
✓ kernel.shmal 31457280
✓ kernel.shmmn 4096
✓ kernel.sem = 250 32000 100 128
✓ net.ipv4.ip_local_port_range = 9000 65500
✓ net.core.rmem_default = 262144
✓ net.core.rmem_max = 4194304
✓ net.core.wmem_default = 262144
✓ net.core.wmem_max = 1048586
✓vm.swappiness=10
✓ vm.min_free_kbytes=524288 # ne állítsa be, ha Linux x86-ot használ
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ grid soft nproc 2047
✓ Grid hard nproc 16384
✓ rács lágy nofile 1024
✓ rács kemény nofile 65536
✓ rács lágy köteg 10240
✓ Grid hard stack 32768
✓ Oracle soft nproc 2047
✓ Oracle hard nproc 16384
✓ Oracle soft nofile 1024
✓ Oracle hard nofile 65536
✓ Oracle soft stack 10240
✓ Oracle hard stack 32768
✓ puha memlock 120795954
✓ kemény memlock 120795954
sqlplus "/as sysdba"
rendszerkészlet módosítása folyamatok=2000 hatókör=spfile;
rendszerkészlet módosítása open_cursors=2000 hatókör=spfile;
alter system set session_cached_cursors=300 hatókör=spfile;
rendszerkészlet módosítása db_files=8192 hatókör=spfile;
Hiba teszt
Demonstrációs célokra a HammerDB-t használták az OLTP-terhelés emulálására. HammerDB konfiguráció:
Raktárak száma
256
Összes tranzakció felhasználónként
1000000000000
Virtuális felhasználók
256
Az eredmény egy 2.1 milliós TPM volt, ami messze van a tömb teljesítményhatárától , hanem a szerverek jelenlegi hardverkonfigurációjának (elsősorban a processzorok miatt) és számának „plafonja”. Ennek a tesztnek továbbra is az a célja, hogy demonstrálja a megoldás egészének hibatűrését, és nem a maximális teljesítmény elérése. Ezért egyszerűen erre az ábrára fogunk építeni.
Tesztelje az egyik csomópont meghibásodását
A gazdagépek elvesztették a tárolóhoz vezető útvonalak egy részét, és a fennmaradó útvonalakon a második csomóponttal folytatták a munkát. A teljesítmény néhány másodpercre visszaesett az utak újjáépítése miatt, majd visszatért a normál kerékvágásba. A szolgáltatásban nem volt fennakadás.
Szekrény meghibásodási teszt az összes berendezéssel
Ebben az esetben is a teljesítmény néhány másodpercre visszaesett a pályák átstrukturálása miatt, majd visszaállt az eredeti érték felére. Az eredmény az eredetihez képest felére csökkent, mivel egy alkalmazásszervert kizártak a működésből. A szolgáltatásban sem volt fennakadás.
Ha szükség van egy hibatűrő Cross-Rack katasztrófa-helyreállítási megoldás bevezetésére az Oracle számára elfogadható költséggel és csekély telepítési/adminisztrációs erőfeszítéssel, akkor az Oracle RAC és az architektúra együtt működik az egyik legjobb lehetőség lesz. Az Oracle RAC helyett bármilyen más szoftver is létezhet, amely fürtözést biztosít, például ugyanaz a DBMS vagy virtualizációs rendszer. A megoldás megalkotásának elve változatlan marad. A lényeg pedig nulla az RTO és az RPO esetében.
Forrás: will.com