Märkimisväärsel hulgal ettevõtte rakendustel ja virtualiseerimissüsteemidel on oma mehhanismid tõrketaluvate lahenduste loomiseks. Täpsemalt on Oracle RAC (Oracle Real Application Cluster) kahe või enama Oracle'i andmebaasiserveri klaster, mis töötavad koos, et tasakaalustada koormust ja pakkuda serveri/rakenduse tasemel tõrketaluvust. Selles režiimis töötamiseks vajate jagatud salvestusruumi, mis on tavaliselt salvestussüsteem.
Nagu oleme juba ühes oma , on salvestussüsteemil endal vaatamata dubleeritud komponentide (sealhulgas kontrollerite) olemasolule endiselt tõrkepunkte - peamiselt ühe andmekogumi kujul. Seetõttu peab kõrgendatud töökindlusnõuetega Oracle'i lahenduse loomiseks skeem “N serverit – üks salvestussüsteem” olema keeruline.
Kõigepealt peame loomulikult otsustama, milliste riskide vastu me püüame kindlustada. Selles artiklis me ei käsitle kaitset selliste ohtude eest nagu "meteoriit on saabunud". Seega jääb geograafiliselt hajutatud avariitaastelahenduse loomine ühe järgmistest artiklitest teemaks. Siin vaatleme nn Cross-Racki avariitaastelahendust, kui kaitse on üles ehitatud serverikappide tasemel. Kapid ise võivad asuda samas ruumis või erinevates, kuid enamasti samas hoones.
Need kapid peavad sisaldama kogu vajalikku seadmete ja tarkvara komplekti, mis võimaldavad Oracle'i andmebaase töötada olenemata "naabri" olekust. Teisisõnu, kasutades Cross-Racki avariitaastelahendust, välistame tõrkeohu:
- Oracle'i rakendusserverid
- Säilitussüsteemid
- Lülitussüsteemid
- Kõikide kapis olevate seadmete täielik rike:
- Võimu keeldumine
- Jahutussüsteemi rike
- Välised tegurid (inimene, loodus jne)
Oracle'i serverite dubleerimine eeldab Oracle RACi tööpõhimõtet ja seda rakendatakse rakenduse kaudu. Samuti pole probleemiks lülitusvõimaluste dubleerimine. Kuid salvestussüsteemi dubleerimisega pole kõik nii lihtne.
Lihtsaim võimalus on andmete replikatsioon põhisalvestussüsteemist varusüsteemi. Sünkroonne või asünkroonne, olenevalt salvestussüsteemi võimalustest. Asünkroonse replikatsiooni puhul kerkib kohe küsimus andmete järjepidevuse tagamisest Oracle'i suhtes. Kuid isegi kui rakendusega on tarkvara integreeritud, on peamise salvestussüsteemi tõrke korral igal juhul vaja administraatorite käsitsi sekkumist, et klastrit varumälule lülitada.
Keerulisem valik on tarkvara- ja/või riistvarasalvestuse "virtualisaatorid", mis kõrvaldavad järjepidevuse probleemid ja käsitsi sekkumise. Kuid juurutamise ja sellele järgneva halduse keerukus, aga ka selliste lahenduste ülimalt vääritu hind hirmutab paljusid.
AccelStor NeoSapphire™ All Flash massiivilahendus sobib suurepäraselt selliste stsenaariumide jaoks nagu Cross-Rack avariitaaste kasutades Shared-Nothing arhitektuuri. See mudel on kahe sõlmega salvestussüsteem, mis kasutab välkmäluseadmetega töötamiseks patenteeritud FlexiRemap® tehnoloogiat. Tänu NeoSapphire™ H710 suudab pakkuda jõudlust kuni 600K IOPS@4K juhuslikku kirjutamist ja 1M+ IOPS@4K juhuslikku lugemist, mis on klassikaliste RAID-põhiste salvestussüsteemide kasutamisel saavutamatu.
Kuid NeoSapphire™ H710 peamine omadus on kahe sõlme täitmine eraldi juhtumite kujul, millest igaühel on oma andmete koopia. Sõlmed sünkroonitakse InfiniBand välise liidese kaudu. Tänu sellele arhitektuurile on võimalik jaotada sõlmed erinevatesse kohtadesse kuni 100 m kaugusele, pakkudes seeläbi Cross-Racki avariitaastelahendust. Mõlemad sõlmed töötavad täiesti sünkroonselt. Hosti poolelt näeb H710 välja nagu tavaline kahe kontrolleriga salvestussüsteem. Seetõttu pole vaja teha täiendavaid tarkvara- või riistvaravalikuid ega eriti keerulisi seadistusi.
Kui võrrelda kõiki ülalkirjeldatud Cross-Racki avariitaastelahendusi, eristub AccelStori valik teistest märgatavalt:
AccelStor NeoSapphire™ Shared Nothing Architecture
Tarkvara või riistvara "virtualiseerija" salvestussüsteem
Replikatsioonipõhine lahendus
Kättesaadavus
Serveri rike
Seisakuid pole
Seisakuid pole
Seisakuid pole
Lüliti rike
Seisakuid pole
Seisakuid pole
Seisakuid pole
Salvestussüsteemi rike
Seisakuid pole
Seisakuid pole
Seisuaeg
Kogu kapi rike
Seisakuid pole
Seisakuid pole
Seisuaeg
Maksumus ja keerukus
Lahenduse maksumus
Madal*
Kõrge
Kõrge
Juurutamise keerukus
Madal
Kõrge
Kõrge
*AccelStor NeoSapphire™ on endiselt All Flash massiiv, mis definitsiooni järgi ei maksa “3 kopikat”, eriti kuna sellel on topeltmahureserv. Kui aga võrrelda sellel põhineva lahenduse lõplikku maksumust teiste tarnijate sarnaste lahendustega, võib selle maksumust pidada madalaks.
Rakendusserverite ja kõigi Flash-massiivi sõlmede ühendamise topoloogia näeb välja järgmine:
Topoloogia kavandamisel on tungivalt soovitatav ka halduslüliteid dubleerida ja servereid omavahel ühendada.
Siin ja edaspidi räägime Fibre Channeli kaudu ühendamisest. Kui kasutate iSCSI-d, on kõik sama, kohandatud kasutatavate lülitite tüüpide ja pisut erinevate massiiviseadete jaoks.
Massiivi ettevalmistustööd
Kasutatud seadmed ja tarkvara
Serveri ja lüliti spetsifikatsioonid
Komponendid
Kirjeldus
Oracle Database 11g serverid
kaks
Serveri operatsioonisüsteem
Oracle Linux
Oracle'i andmebaasi versioon
11 g (RAC)
Protsessorid serveri kohta
Kaks 16-tuumalist Intel® Xeon® CPU E5-2667 v2 @ 3.30 GHz
Füüsiline mälu serveri kohta
128GB
FC võrk
16Gb/s FC mitme teega
FC HBA
Emulex Lpe-16002B
Spetsiaalsed avalikud 1GbE pordid klastri haldamiseks
Inteli Etherneti adapter RJ45
16Gb/s FC lüliti
Brokaat 6505
Spetsiaalsed privaatsed 10 GbE pordid andmete sünkroonimiseks
Intel X520
AccelStor NeoSapphire™ kõik välklambi massiivi spetsifikatsioonid
Komponendid
Kirjeldus
Salvestussüsteem
NeoSapphire™ kõrge kättesaadavusega mudel: H710
Pildi versioon
4.0.1
Draivide koguarv
48
Ajami suurus
1.92TB
Sõidu tüüp
SSD
FC sihtpordid
16x 16Gb porti (8 sõlme kohta)
Halduspordid
1GbE Etherneti kaabel, mis ühendub hostidega Etherneti lüliti kaudu
Südamelöögi port
1GbE Etherneti kaabel, mis ühendab kahte salvestussõlme
Andmete sünkroonimise port
56Gb/s InfiniBand kaabel
Enne massiivi kasutamist peate selle initsialiseerima. Vaikimisi on mõlema sõlme juhtaadress sama (192.168.1.1). Peate nendega ükshaaval ühenduse looma ja määrama uued (juba erinevad) haldusaadressid ning seadistama aja sünkroonimise, mille järel saab Management pordid ühendada ühtsesse võrku. Seejärel ühendatakse sõlmed HA paariks, määrates omavaheliste ühenduste jaoks alamvõrgud.
Pärast lähtestamise lõpetamist saate massiivi hallata mis tahes sõlmest.
Järgmiseks loome vajalikud köited ja avaldame need rakendusserverites.
On väga soovitatav luua Oracle ASM-i jaoks mitu köidet, kuna see suurendab serverite sihtmärkide arvu, mis lõppkokkuvõttes parandab üldist jõudlust (rohkem järjekordade kohta teises ).
Testi 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
Tee uuesti01
100GB
Tee uuesti02
100GB
Tee uuesti03
100GB
Tee uuesti04
100GB
Tee uuesti05
100GB
Tee uuesti06
100GB
Tee uuesti07
100GB
Tee uuesti08
100GB
Tee uuesti09
100GB
Tee uuesti10
100GB
Mõned selgitused massiivi töörežiimide ja eriolukordades toimuvate protsesside kohta
Iga sõlme andmekogumil on parameeter "versiooninumber". Peale esialgset lähtestamist on see sama ja võrdne 1. Kui versiooni number on mingil põhjusel erinev, siis sünkroniseeritakse andmed alati vanemast versioonist nooremasse, misjärel joondatakse noorema versiooni number, s.t. see tähendab, et koopiad on identsed. Põhjused, miks versioonid võivad erineda:
- Ühe sõlme plaanitud taaskäivitamine
- Õnnetus ühes sõlmes äkilise väljalülitamise tõttu (toiteallikas, ülekuumenemine jne).
- InfiniBandi ühendus katkes ja sünkroonimisvõimetus
- Ühe sõlme krahh andmete riknemise tõttu. Siin peate looma uue HA rühma ja lõpetama andmestiku sünkroonimise.
Igal juhul suurendab võrgus olev sõlm oma versiooninumbrit ühe võrra, et pärast paariga ühenduse taastamist oma andmekogum sünkroonida.
Kui ühendus Etherneti lingi kaudu katkeb, lülitub Heartbeat ajutiselt InfiniBandile ja naaseb 10 sekundi jooksul pärast taastamist.
Hostide seadistamine
Veataluvuse tagamiseks ja jõudluse parandamiseks peate lubama massiivi MPIO toe. Selleks peate lisama faili /etc/multipath.conf read ja seejärel taaskäivitama mitmeteeteenuse
Varjatud tekstseadmed {
seade {
müüja "AStor"
path_grouping_policy "group_by_prio"
path_selector "järjekorra pikkus 0"
path_checker "tur"
funktsioonid "0"
riistvara_käsitleja "0"
eelnev "konst"
kohene tõrketagastus
fast_io_fail_tmo 5
dev_loss_tmo 60
kasutajasõbralikud_nimed jah
detect_prio jah
rr_min_io_rq 1
no_path_retry 0
}
}
Järgmiseks, et ASM töötaks MPIO-ga ASMLibi kaudu, peate muutma faili /etc/sysconfig/oracleasm ja seejärel käivitama /etc/init.d/oracleasm scandisks
Varjatud tekst
# ORACLEASM_SCANORDER: mustrite sobitamine ketta skannimise tellimiseks
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: mustrite sobitamine ketaste kontrollist väljajätmiseks
ORACLEASM_SCANEXCLUDE="sd"
Märkus
Kui te ei soovi ASMLibi kasutada, võite kasutada UDEV-reegleid, mis on ASMLibi aluseks.
Alates Oracle Database'i versioonist 12.1.0.2 on see valik saadaval installimiseks ASMFD tarkvara osana.
Kindlasti tuleb tagada, et Oracle ASM-i jaoks loodud kettad oleksid joondatud ploki suurusega, millega massiiv füüsiliselt töötab (4K). Vastasel juhul võivad tekkida jõudlusprobleemid. Seetõttu on vaja luua sobivate parameetritega köited:
parted /dev/mapper/device-name mklabel gpt mkpart esmane 2048s 100% joondus-kontrolli optimaalne 1
Andmebaaside jaotamine loodud köidete vahel meie testkonfiguratsiooni jaoks
Salvestusmahu nimi
Mahu suurus
Mahu LUN-ide kaardistamine
ASM-i helitugevuse seadme üksikasjad
Jaotusühiku suurus
Andmed01
200GB
Kaardistada kõik salvestusmahud salvestussüsteemi kõik andmepordid
Koondamine: 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
Koondamine: normaalne
Nimi: DGGRID1
Eesmärk: Ruudustik: arvutipõhine ettetellimine ja hääletamine
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Koondamine: normaalne
Nimi: DGGRID2
Eesmärk: Ruudustik: arvutipõhine ettetellimine ja hääletamine
4MB
Grid05
1GB
Grid06
1GB
Tee uuesti01
100GB
Koondamine: normaalne
Nimi: DGREDO1
Eesmärk: Tee 1. lõime logi uuesti
4MB
Tee uuesti02
100GB
Tee uuesti03
100GB
Tee uuesti04
100GB
Tee uuesti05
100GB
Tee uuesti06
100GB
Koondamine: normaalne
Nimi: DGREDO2
Eesmärk: Tee 2. lõime logi uuesti
4MB
Tee uuesti07
100GB
Tee uuesti08
100GB
Tee uuesti09
100GB
Tee uuesti10
100GB
Andmebaasi sätted
- Ploki suurus = 8K
- Vahetusruum = 16 GB
- Keela AMM (automaatne mäluhaldus)
- Keela läbipaistvad suured lehed
Muud seaded
# 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 # ära määra 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
✓ ruudustiku pehme nofile 1024
✓ ruudustiku kõva nofile 65536
✓ ruudustiku pehme virn 10240
✓ ruudustiku kõva virn 32768
✓ Oracle soft nproc 2047
✓ Oracle hard nproc 16384
✓ Oracle soft nofile 1024
✓ oraakli kõva nofile 65536
✓ Oracle soft stack 10240
✓ Oracle'i kõva virn 32768
✓ pehme memlock 120795954
✓ kõva mälupulk 120795954
sqlplus "/ as sysdba"
muuda süsteemikomplekti protsessid=2000 ulatus=spfile;
muuda süsteemikomplekti open_cursors=2000 ulatus=spfile;
muuda süsteemikomplekti session_cached_cursors=300 ulatus=spfile;
muuda süsteemikomplekti db_files=8192 ulatus=spfile;
Ebaõnnestumise test
Demonstratsiooni eesmärgil kasutati HammerDB-d OLTP-koormuse jäljendamiseks. HammerDB konfiguratsioon:
Ladude arv
256
Tehinguid kasutaja kohta kokku
1000000000000
Virtuaalsed kasutajad
256
Tulemuseks oli 2.1 miljonit TPM, mis on massiivi jõudluspiirangust kaugel , kuid see on serverite praeguse riistvarakonfiguratsiooni (peamiselt protsessoritest tingitud) ja nende arvu "lagi". Selle testi eesmärk on ikkagi demonstreerida lahenduse kui terviku veataluvust, mitte saavutada maksimaalset jõudlust. Seetõttu tugineme lihtsalt sellele joonisele.
Testige ühe sõlme rikke suhtes
Hostid kaotasid osa salvestusruumi teedest, jätkates ülejäänud teede läbimist teise sõlmega. Jõudlus langes mõneks sekundiks teede ümberehitamise tõttu ja taastus seejärel normaalseks. Teenuses katkestusi ei esinenud.
Kapi rikke test kõigi seadmetega
Sel juhul langes ka jõudlus teede ümberkorraldamise tõttu mõneks sekundiks ja naasis seejärel pooleni esialgsest väärtusest. Ühe rakendusserveri tööst väljajätmise tõttu jäi tulemus esialgsest poole väiksemaks. Samuti ei esinenud katkestust teeninduses.
Kui on vaja rakendada Oracle'i jaoks tõrketaluv Cross-Rack avariitaastelahendus mõistlike kuludega ja vähese juurutamis-/haldusjõuga, töötavad Oracle RAC ja arhitektuur koos oleks üks parimaid valikuid. Oracle RACi asemel võib olla mis tahes muu tarkvara, mis pakub klasterdamist, näiteks samad DBMS-id või virtualiseerimissüsteemid. Lahenduse konstrueerimise põhimõte jääb samaks. Ja alumine rida on null RTO ja RPO jaoks.
Allikas: www.habr.com