Një numër jo i vogël aplikacionesh dhe sistemesh virtualizimi Enterprise kanë mekanizma të tyre për ndërtimin e zgjidhjeve me qëndrueshmëri. Në veçanti, Oracle RAC (Oracle Real Application Cluster) përbën një grup prej dy ose më shumë serverash të bazës së të dhënave Oracle që punojnë së bashku për të balancuar ngarkesën dhe për të siguruar qëndrueshmëri në nivelin e serverit/aplikacionit. Për të punuar në një mënyrë të tillë, nevojitet një ruajtje e përbashkët, e cila zakonisht shërben si SÇD.
Siç e kemi shqyrtuar në një nga artikujt e saj, SÇD, pavarësisht nga prania e komponentëve të dyfishuar (përfshirë kontrollorët), përmban ende 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 më të larta për besueshmëri, skemën "N servera – një SÇD" duhet ta komplikohet.
Fillimisht, sigurisht, duhet të vendosim se nga cilat rreziqe po përpiqemi të mbrohemi. Në kuadër të këtij artikulli, nuk do të shqyrtojmë mbrojtjen nga kërcënime si "kishim një meteor të ra". Kështu, ndërtimi i një zgjidhjeje të shpërndarë territorialisht për rimëkëmbjen nga fatkeqësitë do të mbetet temë për një nga artikujt e ardhshëm. Këtu do të shqyrtojmë atë që quhet zgjidhja Cross-Rack për rimëkëmbje nga fatkeqësitë, kur mbrojtja ndërtohet në nivelin e dollapëve të serverëve. Vetë dollapët mund të ndodhen si në një dhomë ashtu edhe në të ndryshme, por zakonisht brenda një ndërtese.
Këta dollapë duhet të përmbajnë të gjithë setin e nevojshëm të pajisjeve dhe softuerit që do të lejonin funksionimin e bazave të dhënave Oracle pavarësisht nga gjendja e "fqinjit". Me fjalë të tjera, duke përdorur zgjidhjen Cross-Rack për rimëkëmbje nga fatkeqësitë, ne eliminojmë rreziqet në rast dështimi:
- Serverat e aplikacionit Oracle
- Sistemet e ruajtjes
- Sistemet e komunikimit
- Dështimi i plotë i të gjithë pajisjeve në dollap:
- Dështimi i energjisë
- Dështimi i sistemit të ajrit të kondicionuar
- Faktorë të jashtëm (njeri, natyrë, etj.)
Dyfishimi i serverave Oracle nënkupton vetë parimin e funksionimit të Oracle RAC dhe bëhet nëpërmjet aplikacionit. Dyfishimi i mjeteve të komunikimit gjithashtu nuk paraqet problem. Por me dyfishimin e sistemit të ruajtjes, gjërat nuk janë aq të thjeshta.
Zgjedhja më e thjeshtë është replikimi i të dhënave nga storage-i kryesor në atë rezervë. Sinhron ose asinkron, në varësi të mundësive të storage-it. Me replikimin asinkron, menjëherë lind pyetja mbi sigurimin e qëndrueshmërisë së të dhënave në lidhje me Oracle. Por, madje edhe nëse ka integrim programor me aplikacionin, në çdo rast, në rast aksidenti në storage-in kryesor, do të kërkohet ndërhyrja e administratorëve manualisht për të kaluar klasterin në storage-in rezervë.
Një opsion më i komplikuar është "virtualizatorët" e storage-it programor dhe/apo harduerik, të cilët shkurtojnë problemet me qëndrueshmërinë dhe ndërhyrjen manuale. Por, kompleksiteti i shpërndarjes dhe administratës së mëvonshme, si dhe kostoja krejtësisht e papranueshme e këtyre zgjidhjeve frikëson shumë.
Pikërisht për skenarët e tillë, si rikuperimi nga katastrofat Cross-Rack, zgjidhja All Flash array AccelStor NeoSapphire™ është ideale. duke përdorur arkitekturën Shared-Nothing. Ky model përbën një sistem ruajtjeje me dy node, që përdor teknologjinë e saj FlexiRemap® për të punuar me pajisjet flash. Falë NeoSapphire™ H710 është në gjendje të sigurojë performancë deri në 600K IOPS@4K shkrim të rastësishëm dhe 1M+ IOPS@4K lexim të rastësishëm, që nuk është e arritshme duke përdorur storage-in klasik me RAID.
Por veçoria kryesore e NeoSapphire™ H710 është se dy nodet janë të ndara në forma të ndryshme, çdo një prej të cilave ka kopjen e vet të të dhënave. Sinkronizimi i nodeve bëhet përmes ndërfaqes së jashtme InfiniBand. Falë kësaj arkitekture, node-t mund të vendosen në lokacione të ndryshme deri në 100m larg, duke siguruar kështu zgjidhjen Cross-Rack disaster recovery. Të dy node-t punojnë plotësisht në mënyrë sinhrone. Nga ana e hosteve, H710 duket si një storage i zakonshëm me dy kontrollues. Pra, nuk është e nevojshme të kryhen opsione shtesë programore dhe harduerike, as konfigurime të komplikuara.
Nëse e krahasojmë të gjitha zgjidhjet e mësipërme për rikuperimin nga katastrofat Cross-Rack, opsioni i AccelStor dallohet dukshëm nga të tjerët:
AccelStor NeoSapphire™ Arkitektura Shared Nothing
Programor ose harduerik "virtualizator" i storage-it
Zgjidhje e bazuar në replikim
Disponueshmëria
Dështimi i serverit
Pa ndalesë
Pa ndalesë
Pa ndalesë
Dështimi i switch-it
Pa ndalesë
Pa ndalesë
Pa ndalesë
Dështimi i sistemit të ruajtjes
Pa ndalesë
Pa ndalesë
Ndalesë
Dështimi i gjithë kabinetit
Pa ndalesë
Pa ndalesë
Ndalesë
Kostoja dhe kompleksiteti
Kostoja e zgjidhjes
E ulët*
E lartë
E lartë
Kompleksiteti i shpërndarjes
E ulët
E lartë
E lartë
*AccelStor NeoSapphire™ – është gjithsesi një sistem i pllakës All Flash, që për definicionin e tij nuk kushton «3 nishanë», sidomos duke pasur dyfish kapacitetin. Megjithatë, kur krahasohet kostoja përfundimtare e zgjidhjes mbi të bazuar me të ngjashme nga ofrues të tjerë, kostoja mund të konsiderohet e ulët.
Topologjia e lidhjes së serverëve të aplikacioneve dhe nyjave të sistemit All Flash do të duket si më poshtë:
Kur planifikoni topologjinë, gjithashtu rekomandohet shumë që të bëni një kopjim të switch-ëve të menaxhimit dhe interkonneksionit të serverëve.
Këtu dhe më tej do të flitet për lidhjen përmes Fibre Channel. Në rastin e përdorimit të iSCSI do të jetë e njëjta gjë, me përjashtimin e llojeve të ndryshme të switch-eve dhe disa konfigurimeve të tjera të sistemit.
Puna përgatitore në sistem
Pajisjet dhe softueri të përdorura
Specifikimet e serverëve dhe switch-eve
Komponentët
Përshkrimi
Serverët Oracle Database 11g
Dy
Sistemi operativ i serverit
Oracle Linux
Versioni i bazës së të dhënave Oracle
11g (RAC)
Procesorët për server
Dy procesorë 16 cores Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz
Memoria fizike për server
128GB
Rrjeti FC
16Gb/s FC me rrugë multiple
FC HBA
Emulex Lpe-16002B
Portat publike 1GbE të dedikuara për menaxhimin e grupit
Adapteri ethernet Intel RJ45
Switch 16Gb/s FC
Brocade 6505
Portat private 10GbE të dedikuara për sinkronizimin e të dhënave
Intel X520
Specifikimi i sistemit AccelStor NeoSapphire™ All Flash
Komponentët
Përshkrimi
Sistemi i ruajtjes
Modeli me disponueshmëri të lartë NeoSapphire™: H710
Versioni imazhit
4.0.1
Numri total i disqeve
48
Madhësia e disqeve
1.92TB
Lloji i disqeve
SSD
Portat e targetit FC
16x 16Gb portat (8 për nyjë)
Portat e menaxhimit
Kabla ethernet 1GbE që lidhet me hostet përmes një switch ethernet-i
Porta e zemrës
Kabla ethernet 1GbE që lidh dy nyjat e ruajtjes
Porta e sinkronizimit të të dhënave
Kabla InfiniBand 56Gb/s
Para fillimit të përdorimit të sistemit, ai duhet të inicializohet. Siç është parazgjedhur, adresa e menaxhimit e të dy nyjave është identike (192.168.1.1). Duhet të lidheni një nga një dhe të caktoni adresat e reja (të ndryshme) të menaxhimit dhe të konfiguroni sinkronizimin e kohës, pas së cilës portat e menaxhimit mund të lidhen në një rrjet të vetëm. Pas kësaj, nyjat bashkohen në një çift HA duke caktuar nënsisteme për lidhjet Interlink.
Pas përfundimit të inicializimit, sistemi mund të menaxhohet nga çdo nyjë.
Më pas krijojmë volumet e nevojshme dhe i publikojmë ato për serverët e aplikacioneve.
Fort rekomandohet të krijoni disa volume për Oracle ASM, pasi kjo do të rrisë numrin e targeteve për serverat, që në përfundim do të përmirësojë performancën e përgjithshme (më shumë rreth radhëve në një tjetër) ).
Konfigurimi provues
Emri i volumit të ruajtjes
Madhësia e volumit
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
Disa disa rreth modëve të operimit të grumbullit dhe proceseve që ndodhin gjatë situatave të jashtëzakonshme
Grupit të të dhënave të çdo node i është caktuar parametrin "numri versionit". Pas inicializimit të parë, ai është njëlloj dhe barabartë me 1. Nëse për shkak ndonjë arsye numri i versioneve ndryshon, gjithmonë ndodhim një sinkronizim të të dhënave nga versioni më të lartë në versionin më të ulët, pas së cilës numri i versionit të versionit më të ulët rritet, dmth. kjo do të thotë që kopjet janë identike. Arsyet se pse versionet mund të ndryshojnë janë:
- Rivendosja e planifikuar e njërit nga node
- Dështimi në një nga node për shkak të ndalimit të papritur (furnizimi, mbi ngrohja etj.).
- Prerja e lidhjes InfiniBand pa mundësi sinkronizimi
- Dështimi në një nga node për shkak të dëmtimit të të dhënave. Këtu do të kërkohet krijimi i një grupi të ri HA dhe sinkronizimi i plotë i grupit të të dhënave.
Në çdo rast, node që mbetet në online rrit numrin e saj të versionit me njësi, për të sinkronizuar grupin e saj të të dhënave pas rikthimit të lidhjes me çiftin.
Nëse ndodh një ndërprerje e lidhjes përmes Ethernetit, atëherë Heartbeat kalon përkohësisht në InfiniBand dhe kthehet përsëri brenda 10 sekondave pas rikthimit.
Konfigurimi i hosteve
Për të siguruar disponueshmërinë dhe për të rritur performancën, është e nevojshme që të aktivizohet mbështetja për MPIO për grumbullin. Për këtë, duhet të shtoni rreshtat në skedarin /etc/multipath.conf, pas së cilës duhet të rinisni shërbimin multipath
Tekst i fshehurdevices {
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
}
}
Pastaj, që ASM të punojë me MPIO përmes ASMLib, është e nevojshme të ndryshohet skedari /etc/sysconfig/oracleasm dhe pastaj të ekzekutohet /etc/init.d/oracleasm scandisks
Tekst i fshehur
# ORACLEASM_SCANORDER: Matching patterns to order disk scanning
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Matching patterns to exclude disks from scan
ORACLEASM_SCANEXCLUDE="sd"
Shënim
Nëse nuk dëshiron të përdorësh ASMLib, mund të përdorësh rregullat UDEV, të cilat janë baza për ASMLib.
Që nga versioni 12.1.0.2 të Oracle Database, opsioni është në dispozicion për t'u instaluar si pjesë e softuerit ASMFD.
Patjetër duhet të sigurohet që diskët e krijuar për Oracle ASM të jenë të rreshtuar në lidhje me madhësinë e bllokut, me të cilin punon fizikisht grumbulli (4K). Ndryshe do të mund të ketë probleme me performancën. Prandaj, është e nevojshme të krijohen volume me parametrat përkatës:
parted /dev/mapper/device-name mklabel gpt mkpart primary 2048s 100% align-check optimal 1
Distribucioni i bazave të dhënash sipas volumesh të krijuara për konfigurimin tonë të testit
Emri i volumit të ruajtjes
Madhësia e volumit
Hartimi i volumeve LUN
Detaje për Pajisjen e Volumit ASM
Madhësia e Njësisë së Shpërndarjes
Data01
200GB
Hartoni të gjithë volume të ruajtjes në sistemin e ruajtjes të gjitha portet e të dhënave
Redundanca: Normale
Emri: DGDATA
Qëllimi: Skedarët e të dhënave
4MB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
Grid01
1GB
Redundanca: Normale
Emri: DGGRID1
Qëllimi: Gridi: CRS dhe Votimi
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundanca: Normale
Emri: DGGRID2
Qëllimi: Gridi: CRS dhe Votimi
4MB
Grid05
1GB
Grid06
1GB
Redo01
100GB
Redundanca: Normale
Emri: DGREDO1
Qëllimi: Regjistri i riparimeve të thread 1
4MB
Redo02
100GB
Redo03
100GB
Redo04
100GB
Redo05
100GB
Redo06
100GB
Redundanca: Normale
Emri: DGREDO2
Qëllimi: Regjistri i riparimeve të thread 2
4MB
Redo07
100GB
Redo08
100GB
Redo09
100GB
Redo10
100GB
Cilësimet e bazës së të dhënave
- Madhësia e bllokut = 8K
- Hapësira e shkëmbimit = 16GB
- Çaktivizoni AMM (Menaxhimi Automatik i Memories)
- Çaktivizoni FAQET e Mëdha Të Transparencës
Cilësime të 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 po përdorni 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”
ndrysho sistemin set processes=2000 scope=spfile;
ndrysho sistemin set open_cursors=2000 scope=spfile;
ndrysho sistemin set session_cached_cursors=300 scope=spfile;
ndrysho sistemin set db_files=8192 scope=spfile;
Testi për qëndrushmërinë
Për qëllime demonstrative, u përdor HammerDB për të imituar ngarkesën OLTP. Konfigurimi i HammerDB:
Numri i Magazynave
256
Transaksionet Totale për Përdorues
1000000000000
Përdoruesit Virtualë
256
Si rezultat u arrit një normë prej 2.1M TPM, që është larg kufijve të performancës së grupeve , por është "tavan" për konfigurimin aktual të hardware-it të serverëve (përveç se për procesorët) dhe numrit të tyre. Qëllimi i këtij testi është akoma demonstrimi i qëndrushmërisë së zgjidhjes si një tërësi, dhe jo arritja e maksimumeve të performancës. Prandaj, do të mbështetemi thjesht në këtë qëndrim.
Testi për dështimin e një prej nodave
Hostet humbën një pjesë të rrugëve deri te ruajtja, duke vazhduar të punojnë përmes mundësive të mbetura me nodin e dytë. Performanca ra për disa sekonda për shkak të rimarrjes së rrugëve dhe më pas u riktheu në nivelet normale. Nuk kishte ndërprerje në shërbim.
Testi për dështimin e kabinetit me të gjithë pajisjet
Në këtë rast, performanca gjithashtu ra për disa sekonda për shkak të rimarrjes së rrugëve dhe më pas u riktheu në gjysmë të vlerës fillestare. Rezultati ra në gjysmë nga fillimi për shkak të përjashtimit të një serveri aplikacionesh. Nuk kishte ndërprerje në shërbim.
Nëse keni nevojë për zbatimin e një zgjidhjeje të besueshme për rikuperim nga fatkeqësitë Cross-Rack për Oracle me një kosto të arsyeshme dhe me pak përpjekje për shpërndarje/administrim, atëherë bashkëpunimi i Oracle RAC me arkitekturën do të jetë një nga opsionet më të mira. Në vend të Oracle RAC mund të jetë ndonjë tjetër software që parashikon klasterizimin, të njëjtat DBMS ose sisteme virtualizimi, për shembull. Mënyra e ndërtimit të zgjidhjes do të mbetet e njëjtë. Dhe treguesi përfundimtar është një vlerë zero për RTO dhe RPO.
Burimi: habr.com
