Palju ettevõtte rakendusi ja virtualiseerimissüsteeme omavad oma mehhanisme, et luua tõrgeteta lahendusi. Eriti Oracle RAC (Oracle Real Application Cluster) on klaster, mis koosneb kahest või enamast Oracle’i andmebaasiserverist, mis töötavad koos koormuse tasakaalustamiseks ja tõrketaluvuse tagamiseks serveri/rakenduse tasemel. Selle süsteemi tööks on vajalik ühine salvestusruum, mille rolli täidab tavaliselt andmemagasi (СХД).
Kuidas me juba ühes oma , ise СХД, hoolimata dubleeritud komponentide (sealhulgas kontrollereid) olemasolust, omab siiski tõrkepunkte – peamiselt arvutiseadmestiku ühtsest andmest. Seetõttu, et luua Oracle'i lahendust, millele on seatud kõrgendatud usaldusväärsuse nõuded, tuleb skeemi "N serverit – üks СХД" keerukamaks muuta.
Esiteks tuleb loomulikult välja selgitada, millistest riskidest me üritame end kaitsta. Käesolevas artiklis me ei käsitle kaitset ohtude vastu, nagu „meteoriit tabas”. Seega, territoriaalselt jaotatud katastroofide taastamise lahenduse loomine jääb järgmiste artiklite teemaks. Siin käsitleme nn Cross-Rack katastroofi taastamise lahendust, kus kaitse on üles ehitatud serveririiulite tasemel. Riiulid võivad asuda ühes ruumis või mitmes, kuid tavaliselt ühes hoones.
Need riiulid peavad sisaldama kogu vajalikku seadmete ja tarkvara komplekti, mis võimaldab Oracle'i andmebaaside tööd sõltumata „naabri” seisundist. Teisisõnu, kasutades Cross-Rack katastroofi taastamise lahendust, välistame riske tõrgete korral:
- Oracle'i rakendusserverid
- Salvestussüsteemid
- Lülitusseadmestikud
- Kogu seadme väljajätmine riiulis:
- Toiteviga
- Küttesüsteemi rike
- Välistest teguritest (inimene, loodus jne)
Oracle'i serverite dubleerimine tähistab Oracle RAC tööpõhimõtte ja seda rakendatakse rakenduse kaudu. Ka lülitusseadmestike dubleerimine ei valmista suuri probleeme. Kuid salvestussüsteemi dubleerimine pole sugugi nii lihtne.
Lihtsaim variant on andmete replikatsioon peamisest salvestuslahendusest varukoopia peale. Sünkroonne või asünkroonne, sõltuvalt salvestuslahenduse võimalustest. Asünkroonse replikatsiooni korral tekib kohe küsimus andmete järjepidevuse tagamisest Oracle'i suhtes. Kuid isegi kui rakendusega on olemas tarkvaraline integreerimine, vajab igal juhul peamise salvestuslahenduse tõrke korral administratori käsitsi sekkumist, et klaster suunata varusalvestusele.
Komplekssem variant on tarkvara ja/või riistvara 'virtualiseerijad' salvestuslahendustele, mis vabastavad järjepidevuse ja käsitsi sekkumise probleemidest. Kuid juurutamise ja edasise haldamise keerukus ning selliste lahenduste üsna kõrge hind hirmutavad paljusid.
Just selliste stsenaariumide jaoks, nagu Cross-Rack katastroofide taastamine, sobib suurepäraselt lahendus All Flash järjestik AccelStor NeoSapphire™ kasutades jagatud mitte midagi arhitektuuri. See mudel esindab kahekordset salvestussüsteemi, mis kasutab oma FlexiRemap® tehnoloogiat flash-mäludega töötamiseks. Tänu sellele NeoSapphire™ H710 suudab pakkuda jõudlust kuni 600K IOPS@4K juhuslik kirjutamine ja 1M+ IOPS@4K juhuslik lugemine, mida ei ole võimalik saavutada klassikaliste RAID-põhiste salvestuslahenduste kasutamisel.
Kuid NeoSapphire™ H710 peamine omadus on kahe sõlme täitmine eraldi korpustes, millest igaühel on oma andmekopeering. Sõlmede sünkroniseerimine toimub välist InfiniBand liidest kasutades. Tänu sellisele arhitektuurile saab sõlmed paikneda erinevates kohtades kuni 100 meetri kaugusel, tagades seeläbi Cross-Rack katastroofide taastamise lahenduse. Mõlemad sõlmed töötavad täiesti sünkroonselt. H710 poolt väljastatud hostide jaoks näeb see välja nagu tavaline kahekontrolleriline salvestuslahendus. Seega ei ole vaja täiendavaid tarkvaralisi ja riistvaralisi valikuid ega keerulisi seadistusi.
Kui võrrelda kõiki eelnevalt kirjeldatud Cross-Rack katastroofide taastamise lahendusi, siis AccelStori variant eristub oluliselt ülejäänutest:
AccelStor NeoSapphire™ jagatud mitte midagi arhitektuur
Tarkvara või riistvara 'virtualiseerija' salvestuslahendusele
Replikatsiooni põhjal lahendus
Saadavus
Serveri tõrge
Ilma seiskamiseta
Ilma seiskamiseta
Ilma seiskamiseta
Lüliti tõrge
Ilma seiskamiseta
Ilma seiskamiseta
Ilma seiskamiseta
Salvestussüsteemi tõrge
Ilma seiskamiseta
Ilma seiskamiseta
Seiskamine
Kogu kapi tõrge
Ilma seiskamiseta
Ilma seiskamiseta
Seiskamine
Hind ja keerukus
Lahenduse hind
Madala*
Kõrge
Kõrge
Juurutamise keerukus
Madal
Kõrge
Kõrge
*AccelStor NeoSapphire™ on siiski All Flash-massiiv, mis määratletakse, et see ei maksa „3 kopikat”, eriti kui arvestada topeltmahtu. Siiski, võrreldes lahenduse lõpphinda selle alusel, on hind suhteliselt madal, võrreldes teiste tootjate pakutavate sarnaste lahendustega.
Rakendusse serverite ja All Flash-massiivi seadmete ühendamise topoloogia näeb välja järgmiselt:
Topoloogia planeerimisel on äärmiselt soovitatav teha dubleerimine juhtimisseente ja serverite vaheliseks sideks.
Edasi räägitakse Fibre Channeli ühendustest. iSCSI kasutamisel on kõik sama, lihtsalt kasutatavad seente tüübid ja mõnevõrra erinevad massiivi seadistused.
Töö massiivi peal
Kasutatav riistvara ja tarkvara
Serverite ja seente spetsifikatsioonid
Komponendid
Kirjeldus
Oracle Database 11g serverid
Kaks
Serveri operatsioonisüsteem
Oracle Linux
Oracle andmebaasi versioon
11g (RAC)
Protsessorite arv serveri kohta
Kaks 16 tuuma Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz
Füüsiline mälu serveri kohta
128GB
FC võrk
16Gb/s FC mitme tee
FC HBA
Emulex Lpe-16002B
Pühendatud avalikud 1GbE pordid klastrihalduseks
Intel ethernet adapter RJ45
16Gb/s FC lüliti
Brocade 6505
Pühendatud privaatne 10GbE port andmete sünkroonimiseks
Intel X520
AccelStor NeoSapphire™ All Flash-massiivi spetsifikatsioon
Komponendid
Kirjeldus
Salvestussüsteem
NeoSapphire™ kõrge kättesaadavuse mudel: H710
Pildi versioon
4.0.1
Koguarv kettaid
48
Ketta suurus
1.92TB
Ketta tüüp
SSD
FC sihtportid
16x 16Gb porti (8 ühe seadme kohta)
Halduse portid
1GbE ethernet kaabel, mis on ühendatud hostidega Etherneti lüliti kaudu
Südame löögi port
1GbE ethernet kaabel, mis ühendab kahte salvestusseadet
Andmete sünkroonimise port
56Gb/s InfiniBand kaabel
Enne massiivi kasutuselevõttu tuleb see algatada. Vaikimisi on mõlema seadme haldusadresid samad (192.168.1.1). Tuleb järjestikku need ühenduda ja määrata uued (juba erinevad) haldusadresid ning seadistada aja sünkroniseerimine, pärast mida saab haldusportid ühendada ühte võrku. Seejärel toimub seadmete ühendamine HA paarina, määrates alamvõrgud Interlink ühendustele.
Pärast algatamise lõpetamist saab massiivi hallata ükskõik millisest seadmest.
Seejärel loome vajalikud mahud ja avaldame need rakendusse serveritele.
Soovitatav on luua mitu mahtu Oracle ASM-i jaoks, kuna see suurendab sihtide arvu serverite jaoks, mis omakorda parandab üldist jõudlust (rohkem teavet järjekordade kohta teises) ).
Testimise konfiguratsioon
Salvestusmahu nimi
Maht
Data01
200GB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
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
Mõned selgitused massiivi töörežiimide ja hädaolukordade käigus toimuvate protsesside kohta
Iga sõlme andmekogumil on parameeter 'versiooninumber'. Pärast esmast initsialiseerimist on see ühesugune ja võrdub 1. Kui mingil põhjusel on versiooninumber erinev, toimub alati andmete sünkroniseerimine kõrgemalt versioonilt madalamale, mille järel ühtlustatakse madalama versiooni number. See tähendab, et koopiad on identsed. Versioonide erinevuse põhjused võivad olla:
- Ühe sõlme planeeritud taaskäivitamine
- Ühe sõlme rike ootamatu väljalülitamise tõttu (toitekatkestus, ülekuumenemine jne).
- InfiniBand'i ühenduse katkemine sünkroniseerimise võimaluse puudumisel
- Ühe sõlme rike andmete rikkumise tõttu. Siin on juba vajalik uue HA grupi loomine ja andmekogumi täielik sünkroniseerimine.
Igatahes, online olev sõlm suurendab oma versiooninumbrit ühe võrra, et ühenduse taastamisel sünkroniseerida oma andmekogum.
Kui Etherneti lingi ühendus katkeb, siis Heartbeat lülitub ajutiselt InfiniBand'ile ja naaseb tagasi 10 sekundi jooksul pärast selle taastumist.
Hostide seadistamine
Veatuks toimimiseks ja jõudluse suurendamiseks on vajalik lubada MPIO toetus massiivi jaoks. Selleks tuleb lisada failile /etc/multipath.conf read ja seejärel taaskäivitada multipath teenus
Peidetud tekstdevices {
device {
vendor «AStor»
path_grouping_policy «group_by_prio»
path_selector «queue-length 0»
path_checker «tur»
features «0»
hardware_handler «0»
prio «const»
failback immediate
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names yes
detect_prio yes
rr_min_io_rq 1
no_path_retry 0
}
}
Edasi, et ASM töötaks MPIO kaudu ASMLib'iga, tuleb muuta faili /etc/sysconfig/oracleasm ja seejärel käivitada /etc/init.d/oracleasm scandisks
Peidetud tekst
# ORACLEASM_SCANORDER: Matching patterns to order disk scanning
ORACLEASM_SCANORDER=«dm»
# ORACLEASM_SCANEXCLUDE: Matching patterns to exclude disks from scan
ORACLEASM_SCANEXCLUDE=«sd»
Märkus
Kui ASMLib'i kasutada ei soovita, võib kasutada UDEV reegleid, mis on ASMLib'i aluseks.
Alates versioonist 12.1.0.2 on Oracle Database'i võimalus saadaval installimiseks kui osa ASMFD tarkvarast.
Oluline on veenduda, et Oracle ASM'ile loodud kettad oleksid joondatud massiivi füüsilise tööbloki suuruse (4K) suhtes. Vastasel juhul võivad tekkida jõudlusprobleemid. Seetõttu tuleb luua mahud vastavate parameetritega:
parted /dev/mapper/device-name mklabel gpt mkpart primary 2048s 100% align-check optimal 1
Andmete jaotamine loodud mahtude põhjal meie testkonfiguratsioonis
Salvestusmahu nimi
Maht
Mahtude LUNide kaardistamine
ASM Mahtude Seadme Üksikasjad
Eraldusüksuse suurus
Data01
200GB
Kaardista kõik salvestusmahtude andmed salvestussüsteemi kõigile andmeportidele
Redundantsus: Tavaline
Nimi: DGDATA
Eesmärk: Andmefailid
4MB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
Grid01
1GB
Redundantsus: Tavaline
Nimi: DGGRID1
Eesmärk: Rida: CRS ja Hääletamine
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundantsus: Tavaline
Nimi: DGGRID2
Eesmärk: Rida: CRS ja Hääletamine
4MB
Grid05
1GB
Grid06
1GB
Redo01
100GB
Redundantsus: Tavaline
Nimi: DGREDO1
Eesmärk: Taaselustuskäik 1
4MB
Redo02
100GB
Redo03
100GB
Redo04
100GB
Redo05
100GB
Redo06
100GB
Redundantsus: Tavaline
Nimi: DGREDO2
Eesmärk: Taaselustuskäik 2
4MB
Redo07
100GB
Redo08
100GB
Redo09
100GB
Redo10
100GB
Andmebaasi seaded
- Bloki suurus = 8K
- Vahetusruum = 16GB
- Deaktiveeri AMM (Automaatne Mälu Halduse)
- Deaktiveeri Läbipaistev Suured Lehed
Muud seaded
# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-max = 6815744
✓ kernel.shmmax 103079215104
✓ kernel.shmall 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 # ära seadista seda, kui kasutad Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ grid soft nproc 2047
✓ grid hard nproc 16384
✓ grid soft nofile 1024
✓ grid hard nofile 65536
✓ grid soft stack 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
✓ soft memlock 120795954
✓ hard memlock 120795954
sqlplus “/as sysdba”
alter system set processes=2000 scope=spfile;
alter system set open_cursors=2000 scope=spfile;
alter system set session_cached_cursors=300 scope=spfile;
alter system set db_files=8192 scope=spfile;
Vaatluskatsed katkestuskindluse osas
Demonstratsiooni eesmärgil kasutati HammerDB-d OLTP koormuse emuleerimiseks. HammerDB konfiguratsioon:
Laodega arvu
256
Kokku tehinguid kasutaja kohta
1000000000000
Virtuaalsed kasutajad
256
Testi tulemuseks oli 2.1M TPM, mis on kaugel salvestussüsteemi jõudluse piirist , kuid see on aktsepteeritav "lagi" praegusele serverite riistvarakonfiguratsioonile (peamiselt protsessorite ja nende arvu tõttu). Selle testi eesmärk on siiski demonstreerida lahenduse üldist katkestuskindlust, mitte jõudluse maksimume saavutada. Seetõttu tugineme lihtsalt sellele numbrile.
Test ühe node katkestuskindluse osas
Hostid kaotasid osa teedest salvestussüsteemi, jätkates töötamist jäänud teede kaudu teise node'iga. Jõudlus langes paariks sekundiks teede taastamise tõttu ning seejärel naasis normaalsesse tasemesse. Teenusekatkestust ei toimunud.
Test kogu varustusega rack'i katkestuskindluse osas
Sel juhul langes jõudlus samuti paariks sekundiks teede taastamise tõttu ning seejärel naasis pooliku originaalväärtuseni. Tulemused langesid poole võrra algsest seetõttu, et üks rakenduste server eemaldati tööst. Teenusekatkestust samuti ei toimunud.
Kui teil on vajadus rakendada usaldusväärset lahendust Cross-Rack katastroofide taastamiseks Oracle'i jaoks mõistliku hinna ja väikeste juurutamise/halduskuludega, siis Oracle RAC ja arhitektuuri koostöö on üks parimaid valikuid. Oracle RAC-i asemel võib kasutada mõnda muud tarkvara, mis toetab klasterdamist, sama andmebaasi või virtualiseerimissüsteeme, näiteks. Lahenduse loomise põhimõte jääb samaks. Lõppkokkuvõttes peab RTO ja RPO väärtus olema null.
Allikas: habr.com
