Töluverður fjöldi fyrirtækjaforrita og sýndarvæðingarkerfa hefur sitt eigið kerfi til að byggja upp bilunarþolnar lausnir. Nánar tiltekið, Oracle RAC (Oracle Real Application Cluster) er þyrping tveggja eða fleiri Oracle gagnagrunnsþjóna sem vinna saman að því að jafna álag og veita bilanaþol á miðlara/forritsstigi. Til að vinna í þessum ham þarftu sameiginlega geymslu, sem er venjulega geymslukerfi.
Eins og við höfum þegar rætt í einu af okkar , geymslukerfið sjálft, þrátt fyrir tilvist afritaðra íhluta (þar á meðal stýringar), hefur enn bilunarpunkta - aðallega í formi eins gagnasetts. Þess vegna, til að byggja Oracle lausn með auknum áreiðanleikakröfum, þarf „N netþjónar - eitt geymslukerfi“ að vera flókið.
Fyrst þurfum við auðvitað að ákveða hvaða áhættu við erum að reyna að tryggja gegn. Í þessari grein munum við ekki íhuga vernd gegn ógnum eins og „loftsteinn er kominn“. Svo að byggja upp landfræðilega dreifða hörmungabatalausn verður áfram efni í eina af eftirfarandi greinum. Hér munum við skoða hina svokölluðu Cross-Rack disaster recovery lausn, þegar vörn er byggð á stigi netþjónaskápa. Skáparnir sjálfir geta verið staðsettir í sama herbergi eða í mismunandi, en venjulega í sömu byggingu.
Þessir skápar verða að innihalda allan nauðsynlegan búnað og hugbúnað sem gerir kleift að nota Oracle gagnagrunna óháð ástandi „nágrannans“. Með öðrum orðum, með því að nota Cross-Rack hörmungarbatalausnina, útilokum við hættuna á bilun:
- Oracle forritaþjónar
- Geymslukerfi
- Skipta um kerfi
- Algjör bilun á öllum búnaði í skápnum:
- Völd synjun
- Bilun í kælikerfi
- Ytri þættir (manneskjur, náttúra osfrv.)
Fjölföldun Oracle netþjóna felur í sér meginreglu Oracle RAC og er útfærð í gegnum forrit. Tvöföldun skiptiaðstöðu er heldur ekki vandamál. En með fjölföldun geymslukerfisins er allt ekki svo einfalt.
Einfaldasti kosturinn er afritun gagna frá aðalgeymslukerfinu yfir í öryggisafritið. Samstilltur eða ósamstilltur, allt eftir getu geymslukerfisins. Með ósamstilltri afritun vaknar strax spurningin um að tryggja samræmi gagna í tengslum við Oracle. En jafnvel þótt það sé hugbúnaðarsamþætting við forritið, í öllum tilvikum, ef bilun verður í aðalgeymslukerfinu, verður handvirkt inngrip stjórnenda krafist til að skipta þyrpingunni yfir í öryggisafrit.
Flóknari valkostur er hugbúnaðar- og/eða vélbúnaðargeymsla „sýndarvélar“ sem munu koma í veg fyrir samræmisvandamál og handvirkt inngrip. En hversu flókin uppsetningin er og síðari stjórnun, sem og mjög ósæmilegur kostnaður við slíkar lausnir, hræðir marga.
AccelStor NeoSapphire™ All Flash fylkislausnin er fullkomin fyrir aðstæður eins og Cross-Rack hörmung. með Shared-Nothing arkitektúr. Þetta líkan er tveggja hnúta geymslukerfi sem notar sér FlexiRemap® tækni til að vinna með flash-drifum. Þökk sé NeoSapphire™ H710 er fær um að skila afköstum allt að 600K IOPS@4K handahófskennd skrif og 1M+ IOPS@4K handahófskenndan lestur, sem er ekki hægt að ná þegar klassísk RAID byggð geymslukerfi eru notuð.
En aðaleiginleikinn við NeoSapphire™ H710 er framkvæmd tveggja hnúta í formi aðskildra mála, sem hver um sig hefur sitt eintak af gögnunum. Samstilling hnúta fer fram í gegnum ytra InfiniBand tengi. Þökk sé þessum arkitektúr er hægt að dreifa hnútum á mismunandi staði í allt að 100m fjarlægð og veita þannig Cross-Rack hörmungarlausn. Báðir hnútar starfa algjörlega samstillt. Frá gestgjafahliðinni lítur H710 út eins og venjulegt geymslukerfi með tvöföldum stjórnanda. Þess vegna er engin þörf á að framkvæma neina viðbótarhugbúnað eða vélbúnaðarvalkosti eða sérstaklega flóknar stillingar.
Ef við berum saman allar Cross-Rack hörmungarlausnirnar sem lýst er hér að ofan, þá sker valkosturinn frá AccelStor sig áberandi úr hinum:
AccelStor NeoSapphire™ Shared Nothing Architecture
Hugbúnaðar- eða vélbúnaðar „virtualizer“ geymslukerfi
Afritunar byggð lausn
Framboð
Bilun á netþjóni
Enginn niður í miðbæ
Enginn niður í miðbæ
Enginn niður í miðbæ
Rofi bilun
Enginn niður í miðbæ
Enginn niður í miðbæ
Enginn niður í miðbæ
Bilun í geymslukerfi
Enginn niður í miðbæ
Enginn niður í miðbæ
Niður í miðbæ
Alveg bilun í skáp
Enginn niður í miðbæ
Enginn niður í miðbæ
Niður í miðbæ
Kostnaður og margbreytileiki
Kostnaður við lausn
Lágt*
High
High
Dreifing flókið
Lágt
High
High
*AccelStor NeoSapphire™ er enn All Flash fylki, sem samkvæmt skilgreiningu kostar ekki „3 kopek,“ sérstaklega þar sem það hefur tvöfaldan afkastagetu varasjóð. Hins vegar, þegar endanlegur kostnaður við lausn sem byggir á henni er borinn saman við svipaðar frá öðrum söluaðilum, getur kostnaðurinn talist lágur.
Greiðslufræðin til að tengja forritaþjóna og All Flash array hnúta mun líta svona út:
Við skipulagningu staðfræðinnar er einnig mjög mælt með því að afrita stjórnunarrofa og samtengja netþjóna.
Hér og lengra munum við tala um tengingu í gegnum Fibre Channel. Ef þú notar iSCSI verður allt eins, stillt fyrir þær tegundir rofa sem notaðar eru og örlítið mismunandi fylkisstillingar.
Undirbúningsvinna við fylkið
Búnaður og hugbúnaður notaður
Forskriftir miðlara og rofa
Hluti
Lýsing
Oracle Database 11g netþjónar
Tveir
Stýrikerfi miðlara
Oracle linux
Oracle gagnagrunnsútgáfa
11g (RAC)
Örgjörvar á hvern netþjón
Tveir 16 kjarna Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz
Líkamlegt minni á hvern netþjón
128GB
FC net
16Gb/s FC með multipathing
FC HBA
Emulex Lpe-16002B
Sérstök opinber 1GbE tengi fyrir klasastjórnun
Intel ethernet millistykki RJ45
16Gb/s FC rofi
6505
Sérstök einka 10GbE tengi fyrir gagnasamstillingu
Intel X520
AccelStor NeoSapphire™ All Flash Array Specification
Hluti
Lýsing
Geymslukerfi
NeoSapphire™ módel með miklu framboði: H710
Myndaútgáfa
4.0.1
Heildarfjöldi aksturs
48
Drifstærð
1.92TB
Drive gerð
SSD
FC markhafnir
16x 16Gb tengi (8 á hvern hnút)
Stjórnunarhöfn
1GbE Ethernet snúran sem tengist vélum með Ethernet rofi
Hjartsláttarhöfn
1GbE Ethernet snúran sem tengir á milli tveggja geymsluhnúta
Gagnasamstillingargátt
56Gb/s InfiniBand snúru
Áður en þú getur notað fylki þarftu að frumstilla það. Sjálfgefið er að stjórnfang beggja hnúta er það sama (192.168.1.1). Þú þarft að tengjast þeim eitt af öðru og setja ný (nú þegar önnur) stjórnunarheimilisföng og setja upp tímasamstillingu, eftir það er hægt að tengja stjórnunartengin við eitt net. Síðan eru hnútarnir sameinaðir í HA par með því að úthluta undirnetum fyrir samtengingar.
Eftir að frumstillingu er lokið geturðu stjórnað fylkinu frá hvaða hnút sem er.
Næst búum við til nauðsynleg bindi og birtum þau á forritaþjónum.
Það er mjög mælt með því að búa til mörg bindi fyrir Oracle ASM þar sem þetta mun auka fjölda markmiða fyrir netþjónana, sem mun að lokum bæta heildarafköst (meira um biðraðir í öðrum ).
Próf stillingar
Nafn geymslumagns
Stærð rúmmáls
Gögn01
200GB
Gögn02
200GB
Gögn03
200GB
Gögn04
200GB
Gögn05
200GB
Gögn06
200GB
Gögn07
200GB
Gögn08
200GB
Gögn09
200GB
Gögn10
200GB
Tafla01
1GB
Tafla02
1GB
Tafla03
1GB
Tafla04
1GB
Tafla05
1GB
Tafla06
1GB
Endurtaka01
100GB
Endurtaka02
100GB
Endurtaka03
100GB
Endurtaka04
100GB
Endurtaka05
100GB
Endurtaka06
100GB
Endurtaka07
100GB
Endurtaka08
100GB
Endurtaka09
100GB
Endurtaka10
100GB
Nokkrar útskýringar um rekstrarhami fylkisins og ferla sem eiga sér stað í neyðartilvikum
Gagnasett hvers hnúts hefur „útgáfunúmer“ færibreytu. Eftir frumstillingu er það það sama og jafnt og 1. Ef útgáfunúmerið af einhverjum ástæðum er annað, þá eru gögn alltaf samstillt frá eldri útgáfunni yfir í þá yngri, eftir það er númer yngri útgáfunnar samræmt, þ.e. þetta þýðir að eintökin eru eins. Ástæður fyrir því að útgáfur geta verið mismunandi:
- Áætluð endurræsing á einum af hnútunum
- Slys á einum af hnútunum vegna skyndilegrar stöðvunar (aflgjafi, ofhitnun osfrv.).
- Missti InfiniBand tengingu með vanhæfni til að samstilla
- Hrun á einum af hnútunum vegna gagnaspillingar. Hér þarftu að búa til nýjan HA hóp og ljúka samstillingu gagnasafnsins.
Í öllum tilvikum, hnúturinn sem er áfram á netinu eykur útgáfunúmer sitt um einn til að samstilla gagnasettið eftir að tengingin við parið er endurheimt.
Ef tengingin yfir Ethernet tengilinn rofnar, skiptir Heartbeat tímabundið yfir í InfiniBand og snýr aftur innan 10 sekúndna þegar það er endurheimt.
Að setja upp gestgjafa
Til að tryggja bilanaþol og bæta árangur verður þú að virkja MPIO stuðning fyrir fylkið. Til að gera þetta þarftu að bæta línum við /etc/multipath.conf skrána og endurræsa síðan fjölbrautaþjónustuna
Falinn textitæki {
tæki {
söluaðili "AStor"
path_grouping_policy "group_by_prio"
path_selector "biðröð-lengd 0"
path_checker "tur"
lögun "0"
hardware_handler "0"
prio "const"
bilun strax
fast_io_fail_tmo 5
dev_loss_tmo 60
notendavæn_nöfn já
detect_prio já
rr_min_io_rq 1
nei_slóð_reyna aftur 0
}
}
Næst, til þess að ASM geti unnið með MPIO í gegnum ASMLib, þarftu að breyta /etc/sysconfig/oracleasm skránni og keyra síðan /etc/init.d/oracleasm skannadiska
Falinn texti
# ORACLEASM_SCANORDER: Samsvörun mynstur til að panta skönnun á diskum
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Samsvörun mynstur til að útiloka diska frá skönnun
ORACLEASM_SCANEXCLUDE="sd"
Athugið
Ef þú vilt ekki nota ASMLib geturðu notað UDEV reglurnar sem eru grunnurinn að ASMLib.
Frá og með útgáfu 12.1.0.2 af Oracle Database er valmöguleikinn í boði fyrir uppsetningu sem hluti af ASMFD hugbúnaðinum.
Nauðsynlegt er að tryggja að diskarnir sem búnir eru til fyrir Oracle ASM séu í samræmi við blokkastærðina sem fylkið vinnur líkamlega með (4K). Annars geta frammistöðuvandamál komið upp. Þess vegna er nauðsynlegt að búa til bindi með viðeigandi breytum:
skildi /dev/mapper/device-name mklabel gpt mkpart primary 2048s 100% align-check best 1
Dreifing gagnagrunna yfir búið bindi fyrir prófunarstillingar okkar
Nafn geymslumagns
Stærð rúmmáls
Magn LUN kortlagning
Upplýsingar um ASM hljóðstyrkstæki
Úthlutunareiningarstærð
Gögn01
200GB
Kortaðu allt geymslumagn við geymslukerfi öll gagnatengi
Offramboð: Eðlilegt
Nafn: DGDATA
Tilgangur: Gagnaskrár
4MB
Gögn02
200GB
Gögn03
200GB
Gögn04
200GB
Gögn05
200GB
Gögn06
200GB
Gögn07
200GB
Gögn08
200GB
Gögn09
200GB
Gögn10
200GB
Tafla01
1GB
Offramboð: Eðlilegt
Nafn: DGGRID1
Tilgangur: Rat: CRS og atkvæðagreiðsla
4MB
Tafla02
1GB
Tafla03
1GB
Tafla04
1GB
Offramboð: Eðlilegt
Nafn: DGGRID2
Tilgangur: Rat: CRS og atkvæðagreiðsla
4MB
Tafla05
1GB
Tafla06
1GB
Endurtaka01
100GB
Offramboð: Eðlilegt
Nafn: DGREDO1
Tilgangur: Endurtaka skrá yfir þráð 1
4MB
Endurtaka02
100GB
Endurtaka03
100GB
Endurtaka04
100GB
Endurtaka05
100GB
Endurtaka06
100GB
Offramboð: Eðlilegt
Nafn: DGREDO2
Tilgangur: Endurtaka skrá yfir þráð 2
4MB
Endurtaka07
100GB
Endurtaka08
100GB
Endurtaka09
100GB
Endurtaka10
100GB
Gagnagrunnsstillingar
- Stærð blokk = 8K
- Skipta um pláss = 16GB
- Slökktu á AMM (sjálfvirk minnisstjórnun)
- Slökktu á gagnsæjum risastórum síðum
Aðrar stillingar
# 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 # ekki stilla þetta ef þú ert að nota Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ rist mjúkt nproc 2047
✓ rist harður nproc 16384
✓ rist mjúkur nofile 1024
✓ grid hard nofile 65536
✓ rist mjúkur stafla 10240
✓ rist harður stafla 32768
✓ Oracle soft nproc 2047
✓ Oracle hard nproc 16384
✓ Oracle soft nofile 1024
✓ Oracle hard nofile 65536
✓ Oracle mjúkur stafla 10240
✓ Oracle harður stafla 32768
✓ mjúkur minnislás 120795954
✓ harður minnislás 120795954
sqlplus “/as sysdba”
breyta ferli kerfissetts=2000 scope=spfile;
breyta kerfissettinu open_cursors=2000 scope=spfile;
breyta kerfissettinu session_cached_cursors=300 scope=spfile;
breyta kerfissettinu db_files=8192 scope=spfile;
Fallpróf
Í sýningarskyni var HammerDB notað til að líkja eftir OLTP álagi. HammerDB stillingar:
Fjöldi vöruhúsa
256
Heildarfærslur á hvern notanda
1000000000000
Sýndarnotendur
256
Niðurstaðan var 2.1M TPM, sem er langt frá frammistöðumörkum fylkisins , en er „þak“ fyrir núverandi vélbúnaðarstillingar netþjóna (aðallega vegna örgjörva) og fjölda þeirra. Tilgangur þessarar prófunar er enn að sýna fram á bilunarþol lausnarinnar í heild sinni, en ekki að ná hámarksafköstum. Þess vegna munum við einfaldlega byggja á þessari mynd.
Próf fyrir bilun á einum af hnútunum
Gestgjafarnir misstu hluta af leiðunum að geymslunni og héldu áfram að vinna í gegnum þær sem eftir voru með öðrum hnút. Afköst féllu í nokkrar sekúndur vegna þess að stígarnir voru endurbyggðir og fór síðan aftur í eðlilegt horf. Engin truflun varð á þjónustunni.
Bilunarprófun á skáp með öllum búnaði
Í þessu tilviki lækkaði árangur einnig í nokkrar sekúndur vegna endurskipulagningar á slóðunum og fór síðan aftur í hálft upphaflegt gildi. Niðurstaðan minnkaði um helming frá þeim upphaflega vegna útilokunar á einum forritaþjóni frá rekstri. Engin truflun varð á þjónustunni heldur.
Ef þörf er á að innleiða bilunarþolna Cross-Rack hörmungabatalausn fyrir Oracle á sanngjörnum kostnaði og með lítilli uppsetningu/stjórnunarátaki, þá vinna Oracle RAC og arkitektúr saman verður einn besti kosturinn. Í stað Oracle RAC getur verið einhver annar hugbúnaður sem veitir klasagerð, sama DBMS eða sýndarvæðingarkerfi, til dæmis. Meginreglan um að smíða lausnina verður sú sama. Og niðurstaðan er núll fyrir RTO og RPO.
Heimild: www.habr.com