Mitte väike hulk ettevõtte rakendusi ja virtualiseerimissüsteeme omab oma mehhanisme usaldusväärsete lahenduste loomiseks. Eriti Oracle RAC (Oracle Reaalsete Rakenduste Klaster) on klaster, mis koosneb kahest või enam Oracle'i andmebaasiserverist, mis töötavad koos koormuse tasakaalustamiseks ja usaldusväärsuse tagamiseks serveri/rakenduse tasandil. Tööks sellises režiimis on vajalik ühine salvestus, milleks on tavaliselt SAN.
Nagu oleme varem arutanud ühes oma , iseenda SAN, vaatamata dubleeritud komponentide olemasolule (sealhulgas kontrolleritele), sisaldab siiski vigu – peamiselt ühesugust andmekogumit. Seetõttu tuleb Oracle'i lahenduse loomiseks, millel on suurenenud usaldusväärsuse nõuded, skeemi "N serverit – üks SAN" keerukamaks muuta.
Esiteks, loomulikult tuleb määratleda, millistelt riskidelt püüame end kaitsta. Käesolevas artiklis ei käsitle me kaitset selliste ohtude eest nagu "meteoriit kukkus alla". Seega jääb ruumiliselt hajutatud lahenduse disaster recovery ehitamine järgmiste artiklite teemaks. Siin vaatleme nii nimetatud Cross-Rack disaster recovery lahendust, kus kaitse ehitatakse serverikapid tasandil. Kapid võivad asuda kas ühes ruumis või erinevates, kuid tavaliselt samas hoones.
Need kapid peavad sisaldama kogu vajaliku varustuse ja tarkvara komplekti, mis võimaldab Oracle andmebaaside töötagamist sõltumata "naabri" seisundist. Teisisõnu, kasutades Cross-Rack disaster recovery lahendust, välistame rikke riskid:
- Oracle rakenduste serverid
- Salvestussüsteemid
- Switching süsteemid
- Kogu varustuse rike kapis:
- Toite rike
- Jahutussüsteemi rike
- Välised tegurid (inimene, loodus jne)
Oracle'i serverite dubleerimine põhineb Oracle RAC tööpõhimõttel ja toimub rakenduse kaudu. Dubleerimisprobleemide lahendamine vahetuskomplektides ei ole samuti probleem. Kuid salvestussüsteemide dubleerimine on juba keerulisem.
Lihtsaim lahendus on andmete replikatsioon põhivaruhoidlast (SāH) varuhoidlast. See võib olla sünkroonne või asünkroonne, sõltuvalt SāH võimalustest. Asünkroonsel replikatsioonil tekib kohe küsimus andmete järjepidevuse tagamise kohta Oracle'i suhtes. Kuid isegi juhul, kui rakendusel on tarkvaraline integratsioon, on peamise SāH tõrke korral alati vajalik administraatorite käsitsi sekkumine klusteri üleviimise jaoks varuse salvestusse.
Keerulisem lahendus on tarkvara ja/või riistvaralised SāH "virtuaaliseerijad", mis vabastavad teid järjepidevuse ja käsitsi sekkumise probleemidest. Kuid nende lahenduste rakendamise ja edasise haldamise keerukus ning üsna kõrge hind peletab paljusid eemale.
Just for scenarios like these, the All Flash array AccelStor NeoSapphire™ is an excellent solution for Cross-Rack disaster recovery. using Shared-Nothing architecture. This model represents a dual-node storage system utilizing proprietary FlexiRemap® technology for working with flash drives. Thanks to NeoSapphire™ H710 can deliver performance of up to 600K IOPS@4K random write and over 1M IOPS@4K random read, which is unattainable with traditional RAID-based storage systems.
But the main feature of the NeoSapphire™ H710 is its design as two nodes in separate enclosures, each having its own copy of the data. Node synchronization is accomplished through an external InfiniBand interface. This architecture allows for placing nodes at different locations up to 100m apart, thereby providing a Cross-Rack disaster recovery solution. Both nodes operate fully synchronously. From the perspective of hosts, H710 appears as a regular dual-controller storage system. Therefore, no additional software and hardware options or particularly complex configurations are necessary.
Võrreldes kõigi ülaltoodud Cross-Rack katastroofide taastamise lahendustega paistab AccelStori variant selgelt teiste seas silma.
AccelStor NeoSapphire™ jagatud mitte-ressursi arhitektuur
Programmiline või riistvaraline „virtualiseerija” HDA
Lahendus, mis põhineb replikatsioonil
Saadavus
Serveri rike
Ilma seisakuta
Ilma seisakuta
Ilma seisakuta
Lüliti rike
Ilma seisakuta
Ilma seisakuta
Ilma seisakuta
Salvestussüsteemi rike
Ilma seisakuta
Ilma seisakuta
Seisak
Kogu riistvara rike
Ilma seisakuta
Ilma seisakuta
Seisak
Kulud ja keerukus
Lahenduse hind
Madala*
Kõrge
Kõrge
Paigaldamise keerukus
Madala
Kõrge
Kõrge
*AccelStor NeoSapphire™ on siiski All Flash maatriks, mis oma määratlemise järgi ei maksa «3 kopikat», eriti kui arvestada kahekordset mahtude varu. Siiski, võrreldes lõplikku lahenduse maksumust selle alusel teiste tarnijate sarnastega, võib maksumust pidada madalaks.
Rakendusserverite ja All Flash maatriksi sõlmede ühenduse topoloogia näeb välja järgmine:
Topoloogia planeerimisel on äärmiselt soovitatav teha juhtimisseente ja serverite vahelise ühenduse koopia.
Edasi ja edasi räägime ühendamisest läbi Fibre Channel. iSCSI kasutamisel on kõik sama, välja arvatud kasutatavate lülitite tüübid ja veidi erinevad asetuste seaded.
Ettevalmistavad tööd maatriksil
Kasutatavad seadmed ja tarkvara
Serverite ja lülitite spetsifikatsioonid
Komponendid
Kirjeldus
Oracle Database 11g serverid
Kaks
Serveri operatsioonisüsteem
Oracle Linux
Oracle andmebaasi versioon
11g (RAC)
Protsessorid 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 koos multipathiga
FC HBA
Emulex Lpe-16002B
Dedikeeritud avalikud 1GbE sadamad klastrihalduseks
Intel ethernet adapter RJ45
16Gb/s FC lüliti
Brocade 6505
Dedikeeritud privaatne 10GbE sadamad andmete sünkroniseerimiseks
Intel X520
AccelStor NeoSapphire™ All Flash süsteemi spetsifikatsioon
Komponendid
Kirjeldus
Salvestussüsteem
NeoSapphire™ suure kättesaadavuse mudel: H710
Pildi versioon
4.0.1
Kokku kettaid
48
Ketta suurus
1.92TB
Ketta tüüp
SSD
FC sihtsadamad
16 x 16Gb porti (8 sõlme kohta)
Haldusportid
1GbE ethernet kaabel, mis ühendab hoste ethernet lülitiga
Südame löögisageduse port
1GbE ethernet kaabel, mis ühendab kaks salvestussõlme
Andmete sünkroniseerimise port
56Gb/s InfiniBand kaabel
Enne süsteemi kasutamist tuleb see initsialiseerida. Vaikimisi on mõlema sõlme haldusadress sama (192.168.1.1). Tuleb järjestikku ühenduda nendega ja määrata uued (juba erinevad) haldusadressid ning seadistada ajasünkroonimine, pärast mida saab haldusportid ühendada üheks võrguks. Järgmiseks toimub sõlmede ühendamine HA paariks, määrates alamvõrgud Interlink ühenduste jaoks.
Pärast initsialiseerimist saab süsteemi hallata mistahes sõlmest.
Seejärel loome vajalikud mahud ja avaldame need rakendusserveritele.
Soovitatav on luua mitu mahtu Oracle ASM-i jaoks, kuna see suurendab serverite sihtpunktide arvu, mis lõpuks parandab üldist jõudlust (järgnevates artiklites on esitatud rohkem teavet järjekordade kohta). ).
Testimise konfiguratsioon
Salvestusmahu nimi
Mahu suurus
Andmed01
200GB
Andmed02
200GB
Andmed03
200GB
Andmed04
200GB
Andmed05
200GB
Andmed06
200GB
Andmed07
200GB
Andmed08
200GB
Andmed09
200GB
Andmed10
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 seletused massiivide töörežiimide ja häireolukordade protsesside kohta.
Iga sõlme andmestikul on parameeter „versiooninumber“. Pärast esialgset initsialiseerimist on see sama ja võrdne 1-ga. Kui mingil põhjusel on versiooninumber erinev, toimub alati andmete sünkroonimine vanemalt versioonilt noorematele, pärast mida noorema versiooni number tasandatakse, st see tähendab, et koopiad on identsed. Versioonide erinevuse põhjused võivad olla:
- Üks sõlmedest taaskäivitati planeeritult.
- Üks sõlmedest äpardus ootamatu välja lülitamise tõttu (toide, ülekuumenemine jne).
- InfiniBand-ühenduse katkestamine sünkroonimise võimatuse tõttu.
- Üksusest andmete kahjustumise tõttu toimunud rike. Siin on vajalik uus HA rühma loomine ja andmete täielik sünkroonimine.
Igal juhul, online jääv sõlm suurendab oma versiooninumbrit ühe võrra, et pärast ühenduse taastamist paariga sünkroonida selle andmestikku.
Kui Etherneti ühenduse katus katkeb, lülitub Heartbeat ajutiselt InfiniBandi peale ja naaseb tagasi 10 sekundi jooksul pärast taastumist.
Hostide seadistamine
Tõrketeabe tagamiseks ja jõudluse suurendamiseks tuleb MPIO tugi rakendamiseks sisselülitada. Selleks tuleb faili /etc/multipath.conf lisada read ning seejärel taaskäivitada multipath teenus.
Peidetud tekstdevices {
seade {
tootja «AStor»
tee_grupid_poliitika «group_by_prio»
tee_valik «queue-length 0»
tee_kontrollija «tur»
funktsioonid «0»
riistvara_käitleja «0»
prio «const»
tagasi võtma koheselt
kiire_io_ülekuumenemise_aeg 5
seadmestiku_kadu_aeg 60
kasutajasõbralikud_nimed jah
tuvasta_prio jah
rr_min_io_rq 1
pole_ted_võimaluse_katset 0
}
}
Edasi, et ASM töötaks MPIO kaudu ASMLib'i, tuleb faili /etc/sysconfig/oracleasm muuta 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 soovi, saab kasutada UDEVi reegleid, mis on ASMLib'i alus.
Alates versioonist 12.1.0.2 on Oracle Databasei valik saadaval installimiseks kui osa ASMFD tarkvarast.
On hädavajalik veenduda, et Oracle ASM-i jaoks loodud kettad oleksid joondatud füüsiliselt töötava massiivi ploki suurusega (4K). Vastasel juhul võivad tekkida jõudlusprobleemid. Seetõttu tuleb luua mahtusid vastavate parameetritega:
parted /dev/mapper/device-name mklabel gpt mkpart primary 2048s 100% align-check optimal 1
Andmebaaside jaotamine loodud mahtude vahel meie testkonfiguratsiooni jaoks
Salvestusmahu nimi
Mahu suurus
Volume LUNs mapping
ASM Volume Device Detail
Allocation Unit Size
Andmed01
200GB
Kaardista kõik salvestusmahtude andmesüsteemi kõik andmeportid
Redundancy: Normaalne
Nimi:DGDATA
Eesmärk: Andmefailid
4MB
Andmed02
200GB
Andmed03
200GB
Andmed04
200GB
Andmed05
200GB
Andmed06
200GB
Andmed07
200GB
Andmed08
200GB
Andmed09
200GB
Andmed10
200GB
Grid01
1GB
Redundancy: Normaalne
Nimi: DGGRID1
Eesmärk: Grid: CRS ja hääletamine
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundancy: Normaalne
Nimi: DGGRID2
Eesmärk: Grid: CRS ja hääletamine
4MB
Grid05
1GB
Grid06
1GB
Redo01
100GB
Redundancy: Normaalne
Nimi: DGREDO1
Eesmärk: Thread 1 taastelog
4MB
Redo02
100GB
Redo03
100GB
Redo04
100GB
Redo05
100GB
Redo06
100GB
Redundancy: Normaalne
Nimi: DGREDO2
Eesmärk: Thread 2 taastelog
4MB
Redo07
100GB
Redo08
100GB
Redo09
100GB
Redo10
100GB
Andmebaasi seadistused
- Ploki suurus = 8K
- Vahetusruum = 16GB
- AMM (Automaatne Mälu Halduse) keelamine
- Läbipaistvate Suurte Lehtede keelamine
Muud seadistused
# 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 # ärge seadistage seda, kui kasutate 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;
Vastuskatsetus
Demonstreerimiseks kasutati HammerDB-d OLTP koormuse simuleerimiseks. HammerDB konfiguratsioon:
Ladude arv
256
Kokku tehinguid kasutaja kohta
1000000000000
Virtuaalsed kasutajad
256
Tulemuseks oli 2,1M TPM, mis jääb kaugele salve jõudluse piirist, , kuid on praeguse serverite riistvara konfiguratsiooni (peamiselt protsessorite) ja nende arvu "lagi". Selle testi eesmärgiks on siiski demonstreerida lahenduse usaldusväärsust üldiselt, mitte jõudlustippude saavutamist. Seetõttu lähtume lihtsalt sellest numbrist.
Ühe sõlme tõrketest
Hostid kaotas osa teid hulgimüügiossa, jätkates tööd läbi jäänud teede teise sõlme. Tulemus langes mitmeks sekundiks teede ümberkorraldamise tõttu ja seejärel naasis normaalsesse tasemesse. Teenuse katkestust ei olnud.
Kapoti rikke test kogu seadmetega
Selles juhul langes tulemus samuti mitmeks sekundiks teede ümberkorraldamise tõttu ja seejärel naasis algse taseme poole. Tulemused vähenesid poole võrra algsest, kuna ühe rakendusse serveri töö lõpetamise tõttu. Teenuse katkestust samuti ei olnud.
Kui on vajadusi rakendada Ristjõudude katastroofide taastamise lahendust Oracle jaoks mõistliku hinna ja väheste juurutamis-/halduspingutustega, siis Oracle RAC ja arhitektuuri koostöö on üks parimaid variante. Oracle RAC-i asemel võib kasutada mis tahes muud tarkvara, mis toetab klasterdamist, samu andmebaase või virtualiseerimisse süsteeme, näiteks. Lahenduse ehitamise põhimõte jääb samaks. Lõplik näitaja on RTO ja RPO nullväärtus.
Allikas: habr.com
