Një numër i konsiderueshëm i aplikacioneve të Ndërmarrjeve dhe sistemeve të virtualizimit kanë mekanizmat e tyre për ndërtimin e zgjidhjeve tolerante ndaj gabimeve. Në mënyrë të veçantë, Oracle RAC (Oracle Real Application Cluster) është një grup i dy ose më shumë serverëve të bazës së të dhënave Oracle që punojnë së bashku për të balancuar ngarkesën dhe për të ofruar tolerancë ndaj gabimeve në nivelin e serverit/aplikacionit. Për të punuar në këtë mënyrë, ju nevojitet një hapësirë ruajtëse e përbashkët, e cila zakonisht është një sistem ruajtjeje.
Siç kemi diskutuar tashmë në një nga tonat , vetë sistemi i ruajtjes, megjithë praninë e komponentëve të dyfishtë (përfshirë kontrollorët), ende ka pika dështimi - kryesisht në formën e një grupi të vetëm të dhënash. Prandaj, për të ndërtuar një zgjidhje Oracle me kërkesa të rritura besueshmërie, skema "N server - një sistem ruajtjeje" duhet të jetë e ndërlikuar.
Së pari, natyrisht, ne duhet të vendosim kundër çfarë rreziqesh po përpiqemi të sigurojmë. Në këtë artikull, ne nuk do të shqyrtojmë mbrojtjen kundër kërcënimeve si "ka mbërritur një meteorit". Pra, ndërtimi i një zgjidhjeje gjeografikisht të shpërndarë për rikuperimin e fatkeqësive do të mbetet një temë për një nga artikujt e mëposhtëm. Këtu do të shikojmë të ashtuquajturën zgjidhje të rimëkëmbjes nga fatkeqësitë Cross-Rack, kur mbrojtja ndërtohet në nivelin e kabineteve të serverëve. Vetë dollapët mund të vendosen në të njëjtën dhomë ose në të ndryshme, por zakonisht brenda së njëjtës ndërtesë.
Këto kabinete duhet të përmbajnë të gjithë grupin e nevojshëm të pajisjeve dhe softuerëve që do të lejojnë funksionimin e bazave të të dhënave Oracle pavarësisht nga gjendja e "fqinjës". Me fjalë të tjera, duke përdorur zgjidhjen e rikuperimit të fatkeqësive Cross-Rack, ne eliminojmë rreziqet e dështimit:
- Serverët e aplikacionit Oracle
- Sistemet e ruajtjes
- Sistemet komutuese
- Dështimi i plotë i të gjitha pajisjeve në kabinet:
- Refuzimi i pushtetit
- Dështimi i sistemit të ftohjes
- Faktorët e jashtëm (njeriu, natyra, etj.)
Dyfishimi i serverëve Oracle nënkupton vetë parimin e funksionimit të Oracle RAC dhe zbatohet përmes një aplikacioni. Dyfishimi i objekteve komutuese gjithashtu nuk është problem. Por me dyfishimin e sistemit të ruajtjes, gjithçka nuk është aq e thjeshtë.
Opsioni më i thjeshtë është riprodhimi i të dhënave nga sistemi kryesor i ruajtjes në atë rezervë. Sinkron ose asinkron, në varësi të aftësive të sistemit të ruajtjes. Me replikimin asinkron, lind menjëherë pyetja e sigurimit të konsistencës së të dhënave në lidhje me Oracle. Por edhe nëse ka një integrim të softuerit me aplikacionin, në çdo rast, në rast të një dështimi në sistemin kryesor të ruajtjes, do të kërkohet ndërhyrja manuale nga administratorët për të kaluar grupin në ruajtje rezervë.
Një opsion më kompleks janë "virtualizuesit" e ruajtjes së softuerit dhe/ose harduerit që do të eliminojnë problemet e konsistencës dhe ndërhyrjen manuale. Por kompleksiteti i vendosjes dhe administrimi i mëvonshëm, si dhe kostoja shumë e pahijshme e zgjidhjeve të tilla, tremb shumë njerëz.
Zgjidhja AccelStor NeoSapphire™ All Flash është perfekte për skenarë të tillë si rikuperimi nga fatkeqësitë Cross-Rack duke përdorur arkitekturën Shared-Nothing. Ky model është një sistem ruajtjeje me dy nyje që përdor teknologjinë e pronarit FlexiRemap® për të punuar me disqet flash. Falë NeoSapphire™ H710 është në gjendje të ofrojë performancë deri në 600K IOPS@4K shkrim të rastësishëm dhe 1M+ IOPS@4K lexim të rastësishëm, gjë që është e paarritshme kur përdorni sisteme ruajtjeje klasike të bazuara në RAID.
Por tipari kryesor i NeoSapphire™ H710 është ekzekutimi i dy nyjeve në formën e rasteve të veçanta, secila prej të cilave ka kopjen e vet të të dhënave. Sinkronizimi i nyjeve kryhet përmes ndërfaqes së jashtme InfiniBand. Falë kësaj arkitekture, është e mundur të shpërndahen nyje në vende të ndryshme në një distancë deri në 100 m, duke ofruar kështu një zgjidhje Cross-Rack për rikuperimin e fatkeqësive. Të dy nyjet funksionojnë plotësisht në mënyrë sinkronike. Nga ana pritës, H710 duket si një sistem i zakonshëm ruajtjeje me dy kontrollues. Prandaj, nuk ka nevojë të kryeni ndonjë opsion shtesë softueri ose hardueri ose cilësime veçanërisht komplekse.
Nëse krahasojmë të gjitha zgjidhjet e rikuperimit të katastrofave Cross-Rack të përshkruara më sipër, atëherë opsioni nga AccelStor dallohet dukshëm nga pjesa tjetër:
AccelStor NeoSapphire™ Architecture Asgjë e përbashkët
Sistemi i ruajtjes së "virtualizuesit" të softuerit ose harduerit
Zgjidhje e bazuar në përsëritje
disponueshmëri
Dështimi i serverit
Jo joproduktive
Jo joproduktive
Jo joproduktive
Dështimi i çelësit
Jo joproduktive
Jo joproduktive
Jo joproduktive
Dështimi i sistemit të ruajtjes
Jo joproduktive
Jo joproduktive
kohë joproduktive
Dështim i plotë i kabinetit
Jo joproduktive
Jo joproduktive
kohë joproduktive
Kostoja dhe kompleksiteti
Kostoja e zgjidhjes
i ulët*
I lartë
I lartë
Kompleksiteti i vendosjes
ulët
I lartë
I lartë
*AccelStor NeoSapphire™ është ende një grup i të gjitha Flash, i cili sipas përkufizimit nuk kushton "3 kopekë", veçanërisht pasi ka një rezervë të dyfishtë të kapacitetit. Megjithatë, kur krahasojmë koston përfundimtare të një zgjidhjeje të bazuar në të me ato të ngjashme nga shitësit e tjerë, kostoja mund të konsiderohet e ulët.
Topologjia për lidhjen e serverëve të aplikacionit dhe të gjitha nyjet e grupit Flash do të duket si kjo:
Gjatë planifikimit të topologjisë, rekomandohet gjithashtu të dyfishohen çelsat e menaxhimit dhe ndërlidhja e serverëve.
Këtu dhe më tej do të flasim për lidhjen përmes Fiber Channel. Nëse përdorni iSCSI, gjithçka do të jetë e njëjtë, e rregulluar për llojet e ndërprerësve të përdorur dhe cilësimet paksa të ndryshme të grupit.
Punë përgatitore në grup
Pajisjet dhe programet e përdorura
Specifikimet e serverit dhe ndërprerësit
Komponentet
Përshkrim
Serverët e bazës së të dhënave Oracle 11g
dy
Sistemi operativ i serverit
orakull linux
Versioni i bazës së të dhënave Oracle
11 g (RAC)
Procesorët për server
Dy CPU me 16 bërthama Intel® Xeon® E5-2667 v2 @ 3.30 GHz
Kujtesa fizike për server
128GB
rrjeti FC
16 Gb/s FC me shumë rrugë
FC HBA
Emulex Lpe-16002B
Porta publike të dedikuara 1GbE për menaxhimin e grupimeve
Përshtatës Ethernet Intel RJ45
Ndërprerës FC 16 Gb/s
Brokada 6505
Porta private të dedikuara 10 GbE për sinkronizimin e të dhënave
Intel X520
AccelStor NeoSapphire™ Specifikimet e të gjitha grupeve të Flash
Komponentet
Përshkrim
Sistemi i ruajtjes
Modeli NeoSapphire™ me disponueshmëri të lartë: H710
Versioni i imazhit
4.0.1
Numri total i disqeve
48
Madhësia e makinës
1.92TB
Lloji i automjetit
SSD
Portet e synuara FC
16x 16Gb porte (8 për nyje)
Portet e menaxhimit
Kabllo ethernet 1 GbE që lidhet me hostet nëpërmjet një ndërprerësi ethernet
Porta e rrahjeve të zemrës
Kabllo ethernet 1 GbE që lidhet midis dy nyjeve të ruajtjes
Porta e sinkronizimit të të dhënave
Kabllo InfiniBand 56 Gb/s
Përpara se të përdorni një grup, ai duhet të inicializohet. Si parazgjedhje, adresa e kontrollit të të dy nyjeve është e njëjtë (192.168.1.1). Ju duhet të lidheni me ta një nga një dhe të vendosni adresa të reja (tashmë të ndryshme) menaxhimi dhe të vendosni sinkronizimin e kohës, pas së cilës portat e Menaxhimit mund të lidhen me një rrjet të vetëm. Më pas, nyjet kombinohen në një çift HA duke caktuar nënrrjeta për lidhjet Interlink.
Pas përfundimit të inicializimit, mund të menaxhoni grupin nga çdo nyje.
Më pas, ne krijojmë vëllimet e nevojshme dhe i publikojmë ato në serverët e aplikacionit.
Rekomandohet shumë të krijohen vëllime të shumta për Oracle ASM pasi kjo do të rrisë numrin e objektivave për serverët, gjë që përfundimisht do të përmirësojë performancën e përgjithshme (më shumë për radhët në një tjetër ).
Konfigurimi i testit
Emri i vëllimit të ruajtjes
Madhësia e vëllimit
Të dhënat01
200GB
Të dhënat02
200GB
Të dhënat03
200GB
Të dhënat04
200GB
Të dhënat05
200GB
Të dhënat06
200GB
Të dhënat07
200GB
Të dhënat08
200GB
Të dhënat09
200GB
Të dhënat10
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
Disa shpjegime rreth mënyrave të funksionimit të grupit dhe proceseve që ndodhin në situata emergjente
Grupi i të dhënave të çdo nyje ka një parametër "numri i versionit". Pas inicializimit fillestar, ai është i njëjtë dhe i barabartë me 1. Nëse për ndonjë arsye numri i versionit është i ndryshëm, atëherë të dhënat sinkronizohen gjithmonë nga versioni më i vjetër në versionin më të ri, pas së cilës rreshtohet numri i versionit më të ri, d.m.th. kjo do të thotë që kopjet janë identike. Arsyet pse versionet mund të jenë të ndryshme:
- Rindezja e planifikuar e një prej nyjeve
- Një aksident në një nga nyjet për shkak të një mbylljeje të papritur (furnizimi me energji elektrike, mbinxehja, etj.).
- Humbi lidhjen InfiniBand me pamundësi për t'u sinkronizuar
- Një përplasje në një nga nyjet për shkak të korrupsionit të të dhënave. Këtu do t'ju duhet të krijoni një grup të ri HA dhe sinkronizimin e plotë të grupit të të dhënave.
Në çdo rast, nyja që mbetet në linjë rrit numrin e versionit me një në mënyrë që të sinkronizojë grupin e të dhënave të saj pasi të rivendoset lidhja me çiftin.
Nëse lidhja me lidhjen Ethernet humbet, Heartbeat kalon përkohësisht në InfiniBand dhe kthehet brenda 10 sekondave kur të rikthehet.
Vendosja e hosteve
Për të siguruar tolerancën e gabimeve dhe për të përmirësuar performancën, duhet të aktivizoni mbështetjen MPIO për grupin. Për ta bërë këtë, duhet të shtoni linja në skedarin /etc/multipath.conf dhe më pas të rinisni shërbimin me shumë rrugë
Teksti i fshehurpajisje {
pajisja {
shitësi "AStor"
path_grouping_policy "group_by_prio"
path_selector "queue-length 0"
path_checker "tur"
karakteristikat "0"
hardware_handler "0"
prio "konst"
kthimi i menjëhershëm
fast_io_fail_tmo 5
dev_humbja_tmo 60
user_friendly_names po
detect_prio po
rr_min_io_rq 1
no_path_riprovo 0
}
}
Më pas, në mënyrë që ASM të punojë me MPIO përmes ASMLib, duhet të ndryshoni skedarin /etc/sysconfig/oracleasm dhe më pas të ekzekutoni /etc/init.d/oracleasm scandisks
Teksti i fshehur
# ORACLEASM_SCANORDER: Përputhja e modeleve për të porositur skanimin e diskut
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Përputhja e modeleve për të përjashtuar disqet nga skanimi
ORACLEASM_SCANEXCLUDE="sd"
Shënim
Nëse nuk dëshironi të përdorni ASMLib, mund të përdorni rregullat UDEV, të cilat janë baza për ASMLib.
Duke filluar me versionin 12.1.0.2 të Oracle Database, opsioni është i disponueshëm për instalim si pjesë e softuerit ASMFD.
Është e domosdoshme të sigurohet që disqet e krijuar për Oracle ASM të jenë në linjë me madhësinë e bllokut me të cilin grupi funksionon fizikisht (4K). Përndryshe, mund të shfaqen probleme me performancën. Prandaj, është e nevojshme të krijohen vëllime me parametrat e duhur:
ndarë /dev/mapper/device-name mklabel gpt mkpart primar 2048s 100% align-check optimal 1
Shpërndarja e bazave të të dhënave nëpër vëllime të krijuara për konfigurimin tonë të testit
Emri i vëllimit të ruajtjes
Madhësia e vëllimit
Harta e vëllimit LUN
Detaje të pajisjes së volumit ASM
Madhësia e njësisë së alokimit
Të dhënat01
200GB
Harto të gjitha vëllimet e ruajtjes në sistemin e ruajtjes të gjitha portat e të dhënave
Teprica: Normale
Emri: DGDATA
Qëllimi: Skedarët e të dhënave
4MB
Të dhënat02
200GB
Të dhënat03
200GB
Të dhënat04
200GB
Të dhënat05
200GB
Të dhënat06
200GB
Të dhënat07
200GB
Të dhënat08
200GB
Të dhënat09
200GB
Të dhënat10
200GB
Grid01
1GB
Teprica: Normale
Emri: DGGRID1
Qëllimi:Rrjeti: CRS dhe Votimi
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Teprica: Normale
Emri: DGGRID2
Qëllimi:Rrjeti: CRS dhe Votimi
4MB
Grid05
1GB
Grid06
1GB
Redo01
100GB
Teprica: Normale
Emri: DGREDO1
Qëllimi: Ribërë regjistrin e fillit 1
4MB
Redo02
100GB
Redo03
100GB
Redo04
100GB
Redo05
100GB
Redo06
100GB
Teprica: Normale
Emri: DGREDO2
Qëllimi: Ribërë regjistrin e fillit 2
4MB
Redo07
100GB
Redo08
100GB
Redo09
100GB
Redo10
100GB
Cilësimet e bazës së të dhënave
- Madhësia e bllokut = 8K
- Ndërrimi i hapësirës = 16 GB
- Çaktivizo AMM (Menaxhimi automatik i kujtesës)
- Çaktivizo Faqet e mëdha transparente
Cilësimet e tjera
# 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 # mos e vendosni këtë nëse jeni duke përdorur Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ rrjetë e butë nproc 2047
✓ rrjetë e vështirë nproc 16384
✓ grid soft nofile 1024
✓ Grid hard nofile 65536
✓ rrjetë e butë 10240
✓ rrjetë e fortë 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
✓ memlock i butë 120795954
✓ memlock i fortë 120795954
sqlplus "/as sysdba"
alter proceset e grupit të sistemit=2000 fushëveprimi=spfile;
alter set system open_cursors=2000 scope=spfile;
ndrysho grupin e sistemit session_cached_cursors=300 scope=spfile;
ndryshimi i grupit të sistemit db_files=8192 scope=spfile;
Testi i dështimit
Për qëllime demonstrimi, HammerDB u përdor për të imituar një ngarkesë OLTP. Konfigurimi i HammerDB:
Numri i Depove
256
Totali i transaksioneve për përdorues
1000000000000
Përdoruesit Virtualë
256
Rezultati ishte një TPM 2.1 milion, që është larg kufirit të performancës së grupit , por është një "tavan" për konfigurimin aktual të harduerit të serverëve (kryesisht për shkak të procesorëve) dhe numrit të tyre. Qëllimi i këtij testi është ende të demonstrojë tolerancën e gabimeve të zgjidhjes në tërësi, dhe jo të arrijë performancën maksimale. Prandaj, ne thjesht do të ndërtojmë mbi këtë shifër.
Testoni për dështimin e një prej nyjeve
Pritësit humbën një pjesë të shtigjeve për në ruajtje, duke vazhduar të punojnë nëpër ato të mbetura me nyjen e dytë. Performanca ra për disa sekonda për shkak të rindërtimit të shtigjeve dhe më pas u kthye në normalitet. Nuk ka pasur asnjë ndërprerje në shërbim.
Testi i dështimit të kabinetit me të gjitha pajisjet
Në këtë rast, performanca gjithashtu ra për disa sekonda për shkak të ristrukturimit të shtigjeve, dhe më pas u kthye në gjysmën e vlerës origjinale. Rezultati u përgjysmua nga ai fillestar për shkak të përjashtimit të një serveri aplikacioni nga funksionimi. Nuk ka pasur as ndërprerje në shërbim.
Nëse ka nevojë për të zbatuar një zgjidhje tolerante për rikuperimin e fatkeqësive Cross-Rack për Oracle me një kosto të arsyeshme dhe me pak përpjekje për vendosjen/administrimin, atëherë Oracle RAC dhe arkitektura punojnë së bashku do të jetë një nga opsionet më të mira. Në vend të Oracle RAC, mund të ketë çdo softuer tjetër që ofron grupim, të njëjtat DBMS ose sisteme virtualizimi, për shembull. Parimi i ndërtimit të zgjidhjes do të mbetet i njëjtë. Dhe përfundimi është zero për RTO dhe RPO.
Burimi: www.habr.com