Një numër i konsiderueshëm i aplikacioneve Enterprise dhe sistemeve të virtualizimit kanë mekanizma të tyre për ndërtimin e zgjidhjeve të qëndrueshmërisë. Në veçanti, Oracle RAC (Oracle Real Application Cluster) përbën një grup të dy ose më shumë serverësh të bazave të të dhënave Oracle që punojnë së bashku për të balancuar ngarkesën dhe garantuar qëndrueshmërinë në nivelin e serverit/aplikacionit. Për të funksionuar në këtë mënyrë nevojitet një ruajtje e përbashkët, e cila zakonisht vepron si një Shtëpi e Dhënash.
Siç e kemi shqyrtuar tashmë në një nga , vetë Shtëpia e Dhënave, pavarësisht pranisë së komponentëve të dyfishuar (përfshirë kontrolluesit), ka ende pika dështimi - kryesisht në formën e një grupi të vetëm të të dhënave. Prandaj, për të ndërtuar një zgjidhje Oracle me kërkesa të rritura për besueshmëri, skema "N serverë - një Shtëpi e Dhënash" duhet të komplikohet.
Së pari, natyrisht, duhet të përcaktojmë se nga cilat rreziqe po përpiqemi të mbrohemi. Në kuadër të këtij artikulli ne nuk do të shqyrtojmë mbrojtjen nga kërcënime si "Meteoriti ka rënë". Prandaj, ndërtimi i një zgjidhjeje të shpërndarë gjeografikisht për rikuperimin nga fatkeqësitë do të mbetet një temë për një nga artikujt e ardhshëm. Këtu do të shqyrtojmë thonjëza e asaj që quhet zgjidhje Cross-Rack disaster recovery, kur mbrojtja ndërtohet në nivelin e dollapëve të serverëve. Dollapët vetë mund të ndodhen si në një ambijent të vetëm ashtu edhe në të ndryshëm, por zakonisht brenda një ndërrmarrjeje.
Këta dollapë duhet të përmbajnë të gjithë setin e nevojshëm të pajisjeve dhe softuerit, i cili do të lejojë punën e bazave të të dhënave Oracle pavarësisht nga gjendja e "fqinjes". Në fjalë të tjera, duke përdorur zgjidhjen Cross-Rack disaster recovery, ne eliminojmë rreziqet në rast dështimi:
- Serverat e aplikacionit Oracle
- Sistemet e ruajtjes
- Sistemet e kalimit
- Shkëputja totale e të gjithë pajisjeve në dollap:
- Dështimi i energjisë
- Dështimi i sistemit të ftohjes
- Faktorë të jashtëm (njeri, natyrë etj.)
Duplikimi i serverëve Oracle nënkupton vetë parimin e funksionimit të Oracle RAC dhe realizohet përmes aplikacionit. Duplikimi i mjeteve të kalimit gjithashtu nuk është një problem. Por me duplikimin e sistemit të ruajtjes, gjërat nuk janë kaq të thjeshta.
Mundësia më e thjeshtë është replikimi i të dhënave nga Shtëpia e Dhënash kryesore në atë rezervë. Synchronous ose asynchronous, në varësi të mundësive të Shtëpisë së Dhënash. Me replikimin asinkron, çështja e sigurisë së të dhënave në lidhje me Oracle ngrihet menjëherë. Por edhe nëse ka një integrim programor me aplikacionin, në çdo rast, gjatë një aksidenti në Shtëpinë e Dhënash kryesore, do të jetë e nevojshme një ndërhyrje nga administratorët në mënyrë manuale për të kaluar grupe në ruajtjen rezervë.
Një variant më kompleks është "virtualizuesit" softuerikë dhe/apo harduerikë të Shtëpisë së Dhënash, të cilët do të eliminojnë problemet me konsistencën dhe ndërhyrjen manuale. Por kompleksiteti i vendosjes dhe administratës pasuese, si dhe kostoja shumë të lartë të këtyre zgjidhjeve, tremb shumë.
Pikërisht për skenarë të tillë, si Cross-Rack disaster recovery, zgjidhja All Flash array AccelStor NeoSapphire⹠përshtatet në mënyrë të shkëlqyer duke përdorur arkitekturën Shared-Nothing. Ky model përbën një sistem ruajtjeje me dy node, i cili përdor teknologjinë e vet FlexiRemapŸ për të punuar me pajisjet flash. Falë NeoSapphire⹠H710 është në gjendje të ofrojë një performancë deri në 600K IOPS@4K shkruaj të rastit dhe 1M+ IOPS@4K lexim të rastit, që është e papërballueshme me përdorimin e Shtëpive të Dhënash tradicionale të bazuara në RAID.
Por karakteristika kryesore e NeoSapphire⹠H710 është ekzekutimi i dy nodeve si trupa të veçanta, secila prej të cilave ka kopjen e vet të të dhënave. Sinkronizimi i nodeve bëhet përmes një interfesi të jashtëm InfiniBand. Falë kësaj arkitekture, mund të shpërndahen node të ndryshëm në distanca deri në 100m, duke ofruar kështu zgjidhjen Cross-Rack disaster recovery. Të dy node janë plotësisht të sinkronizuara. Nga ana e hosteve, H710 duket si një Shtëpi e Dhënash me dy kontrollues zakonore. Prandaj, nuk ka nevojë të kryhen asnjë opsion tjetër softuerik ose harduerik dhe as ndonjë konfigurim veçanërisht të komplikuar.
Nëse krahasojmë të gjitha zgjidhjet e lartpërmendura për Cross-Rack disaster recovery, varianti i AccelStor dallohet dukshëm nga të tjerët:
AccelStor NeoSapphireâą Shared Nothing Architecture
Virtualizues softuerik ose harduerik të Shtëpisë së Dhënash
Zgjidhja e bazuar në replikim
Disponueshmëria
DĂ«shtimi i serverit
No Downtime
No Downtime
No Downtime
DĂ«shtimi i kaluesit
No Downtime
No Downtime
No Downtime
Dështimi i sistemit të ruajtjes
No Downtime
No Downtime
Downtime
Dështimi i tërë dollapit
No Downtime
No Downtime
Downtime
Kosto dhe kompleksitet
Kostoja e zgjidhjes
Të ulëta*
I lartë
I lartë
Kompleksiteti i vendosjes
I ulët
I lartë
I lartë
*AccelStor NeoSapphire⹠është ende një All Flash array, i cili sipas përkufizimit nuk është "tre cope", sidomos duke pasur dyfishin e kapacitetit. Megjithatë, krahasuar me koston përfundimtare të një zgjidhjeje në këtë bazë me ato të ngjashme nga furnizues të tjerë, kostoja mund të konsiderohet e ulët.
Topologjia e lidhjes së serverëve të aplikacioneve dhe nyjeve të sistemit të të dhënave All Flash do të duket si më poshtë:
Në planifikimin e topologjisë, rekomandohet gjithashtu që të sigurohet një dyfishim i switches të menaxhimit dhe interkoneksionit të serverëve.
Nga këtu e tutje, do të flasim për lidhjen përmes Fibre Channel. Nëse përdoret iSCSI, gjithçka do të jetë e njëjtë, me përjashtim të llojeve të switches të përdorura dhe disa konfigurime të ndryshme të sistemit.
Puna përgatitore në sistem
Pajisjet dhe softueri i përdorur
Specifikimet e serverëve dhe switches
Komponentët
PĂ«rshkrimi
Serverat 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 16 cores IntelÂź XeonÂź CPU E5-2667 v2 @ 3.30GHz
Memoria fizike për server
128GB
Rrjeti FC
16Gb/s FC me rrugë të shumta
FC HBA
Emulex Lpe-16002B
Portat publike 1GbE të dedikuara për menaxhimin e klasterit
Intel ethernet adapter RJ45
Switch 16Gb/s FC
Brocade 6505
Portat private 10GbE të dedikuara për sinkronizimin e të dhënave
Intel X520
Specifika e sistemit AccelStor NeoSapphireâą All Flash
Komponentët
PĂ«rshkrimi
Sistemi i ruajtjes
Modeli i lartĂ« i disponueshmĂ«risĂ« NeoSapphireâą: H710
Versioni i imazhit
4.0.1
Numri total i disqeve
48
Madhësia e disqeve
1.92TB
Lloji i disqeve
SSD
Portat e synimit FC
16x 16Gb portat (8 për nyje)
Portat e menaxhimit
Kablli 1GbE ethernet që lidh me hostët përmes një switchi ethernet
Porta e zemrës
Kablli 1GbE ethernet që lidhet midis dy nyjeve të ruajtjes
Porta e sinkronizimit të të dhënave
Kablli InfiniBand 56Gb/s
Para fillimit të përdorimit të sistemit, ai duhet të inicializohet. Në mënyrë default, adresa e menaxhimit e të dy nyjeve është e njëjtë (192.168.1.1). Duhet të lidhen një nga një dhe të caktohen adresa të reja (të ndryshme) për menaxhim dhe të konfigurohet sinkronizimi i kohës, pas së cilës portat e menaxhimit mund të lidhen në një rrjet të vetëm. Më pas, nyjet duhet të bashkohen në një çift HA duke caktuar nënrrjeta për lidhjet Interlink.
Pas përfundimit të inicializimit, mund të menaxhohet sistemi nga çdo nyje.
Më pas krijojmë volumet e nevojshme dhe i publikojmë ato për serverët e aplikacioneve.
Rekomandohet fuqimisht që të krijohen disa volume për Oracle ASM, pasi kjo do të rrisë numrin e targeteve për serverët, çka përfundimisht do të përmirësojë performancën totale (më shumë për radhët në një tjetër, ).
Konfigurimi testues
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 sqarime në lidhje me modalitetet e punës së sistemit dhe proceset që ndodhin në situata jashtëzakonisht të zakonshme
Seti i të dhënave të çdo nyje ka një parametër "numri i versionit". Pas inicializimit fillestar, ai është i njëjtë dhe barazohet me 1. Nëse për ndonjë arsye numri i versionit është i ndryshëm, gjithmonë ndodh sinkronizimi i të dhënave nga versioni më të lartë në atë më të ulët, pas së cilës numri në versionin më të ulët rregullohet, pra kjo do të thotë se kopjet janë identike. Arsyet pse versionet mund të jenë të ndryshme janë:
- Ribashkimi i planifikuar i njërës nga nyjet
- Aksident në njërën nga nyjet për shkak të ndalimit të papritur (energji, mbinxehje etj.).
- Prishja e lidhjes InfiniBand pa mundësi sinkronizimi
- Aksident në njërën nga nyjet për shkak të dëmtimit të të dhënave. Këtu do të nevojitet krijimi i një grupi të ri HA dhe sinkronizimi i plotë i setit të të dhënave.
Në çdo rast, nyja që mbetet online rrit numrin e saj të versionit me një, që të mund të sinkronizojë setin e saj të të dhënave pas rikthimit të lidhjes me çiftin.
Nëse ndodh një ndërprerje e lidhjes përmes Ethernet, atëherë porta Heartbeat kalon përkohësisht në InfiniBand dhe kthehet përsëri brenda 10 sekondave pas rikthimit.
Konfigurimi i hostëve
Për të siguruar që sistemi të jetë i qëndrueshëm dhe për të rritur performancën, është e nevojshme të aktivizohet mbështetje MPIO për sistemin. Për këtë, duhet të shtoni në skedarin /etc/multipath.conf rreshtat e mëposhtëm, pastaj të rinisni shërbimin multipath
Teksti 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
}
}
Më pas, për të siguruar 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
Teksti 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ëshirohet të përdoret ASMLib, mund të përdoren rregulla UDEV, të cilat janë baza për ASMLib.
Që nga versioni 12.1.0.2, opsioni i Oracle Database është i disponueshëm për instalim si pjesë e softuerit ASMFD.
ĂshtĂ« absolutisht e domosdoshme tĂ« sigurohet qĂ« disqet e krijuara pĂ«r Oracle ASM tĂ« jenĂ« tĂ« rreshtuar sipas madhĂ«sisĂ« sĂ« bllokut me tĂ« cilin sistemi fizikisht punon (4K). Ndryshe, mund tĂ« ketĂ« probleme me performancĂ«n. Prandaj, duhet tĂ« krijohen volume me parametrat pĂ«rkatĂ«s:
parted /dev/mapper/device-name mklabel gpt mkpart primary 2048s 100% align-check optimal 1
Shpërndarja e bazave të të dhënave sipas volumëve të krijuar për konfigurimin tonë testues
Emri i volumit të ruajtjes
Madhësia e volumit
Mapimi i Volume LUNs
Detajet e Pajisjes së Volume ASM
Madhësia e Njesisë së Allocimit
Data01
200GB
Maponi të gjitha volumet e ruajtjes në të gjithë portat e të dhënave të sistemit të ruajtjes
Redundanca: Normale
Emri:DGDATA
Qëllimi:Skedat 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:Grid: CRS dhe Votimi
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundanca: Normale
Emri: DGGRID2
QĂ«llimi:Grid: CRS dhe Votimi
4MB
Grid05
1GB
Grid06
1GB
Redo01
100GB
Redundanca: Normale
Emri: DGREDO1
Qëllimi: Log-u i rikthimit të thread 1
4MB
Redo02
100GB
Redo03
100GB
Redo04
100GB
Redo05
100GB
Redo06
100GB
Redundanca: Normale
Emri: DGREDO2
Qëllimi: Log-u i rikthimit 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 ndërrimit = 16GB
- Ăaktivizoni AMM (Menaxhimi Automatik i Memories)
- Ăaktivizoni Pagesat e Bujshme
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 e vendos të dhëna=2000 skopa=spfile;
ndrysho sistemin e vendos të dhëna të hapura=2000 skopa=spfile;
ndrysho sistemin e vendos të dhëna të ruajtur në sesion=300 skopa=spfile;
ndrysho sistemin e vendos numrin e skedarëve të db=8192 skopa=spfile;
Test për qëndrushmëri
Për qëllime demonstrimi u përdor HammerDB për të simuluar ngarkesë OLTP. Konfigurimi i HammerDB:
Numri i Magazinateve
256
Transaksionet Totale për Përdorues
1000000000000
Përdoruesit Virtualë
256
Si rezultat, u arrit një tregues prej 2.1M TPM, që është larg kufirit të performancës së grupeve , 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ë demonstrohet qëndrueshmëria e zgjidhjes si një e tërë, në vend të arritjes së maksimumeve të performancës. Prandaj, do të mbështetemi thjesht në këtë numër.
Test për dështimin e një prej nodëve
Hostet humbën disa rrugë deri te depoja, duke vazhduar të punojnë përmes rrugëve të mbetura me nodën e dytë. Performanca ra për disa sekonda për shkak të rindërtimit të rrugëve, dhe më pas u rikthye në nivele normale. Nuk ndodhi ndërprerje shërbimi.
Test për dështimin e kabinetit me gjithë pajisjet
Në këtë rast, gjithashtu performanca ra për disa sekonda për shkak të rindërtimit të rrugëve, dhe më pas u rikthye në gjysmë të vlerës fillestare. Rezultati u zvogëlua në gjysmën e asaj fillestare për shkak të përjashtimit të një serveri aplikacionesh. Nuk ndodhi ndërprerje shërbimi.
NĂ«se ka nevoja pĂ«r implementimin e njĂ« zgjidhjeje tĂ« qĂ«ndrueshme Cross-Rack pĂ«r rikuperimin nga fatkeqĂ«sitĂ« pĂ«r Oracle me njĂ« çmim tĂ« arsyeshĂ«m dhe me pak pĂ«rpjekje pĂ«r shpĂ«rndarje/administrim, atĂ«herĂ« bashkĂ«punimi i Oracle RAC dhe arkitekturĂ«s do tĂ« jetĂ« njĂ« nga opsionet mĂ« tĂ« mira. NĂ« vend tĂ« Oracle RAC mund tĂ« vendoset çdo program tjetĂ«r qĂ« parashikon klasterizimin, tĂ« njĂ«jtat DBMS ose sisteme virtualizimi, pĂ«r shembull. Parimi i ndĂ«rtimit tĂ« zgjidhjes do tĂ« mbetet i njĂ«jtĂ«. Dhe treguesi pĂ«rfundimtar â Ă«shtĂ« njĂ« vlerĂ« zero pĂ«r RTO dhe RPO.
Burimi: habr.com
