Kļūmju izturīga risinājuma izveide, pamatojoties uz Oracle RAC un AccelStor Shared-Nothing arhitektūru

Ievērojamam skaitam uzņēmuma lietojumprogrammu un virtualizācijas sistēmu ir savi mehānismi defektu izturīgu risinājumu izveidei. Konkrēti, Oracle RAC (Oracle Real Application Cluster) ir divu vai vairāku Oracle datu bāzes serveru kopa, kas darbojas kopā, lai līdzsvarotu slodzi un nodrošinātu kļūdu toleranci servera/lietojumprogrammas līmenī. Lai strādātu šajā režīmā, ir nepieciešama koplietojama krātuve, kas parasti ir uzglabāšanas sistēma.

Kā mēs jau esam apsprieduši vienā no mūsu raksti, pašai uzglabāšanas sistēmai, neskatoties uz dublētiem komponentiem (tostarp kontrolieriem), joprojām ir atteices punkti - galvenokārt vienas datu kopas veidā. Tāpēc, lai izveidotu Oracle risinājumu ar paaugstinātām uzticamības prasībām, shēmai “N serveri – viena uzglabāšanas sistēma” ir jābūt sarežģītai.

Pirmkārt, mums, protams, ir jāizlemj, pret kādiem riskiem mēs cenšamies apdrošināt. Šajā rakstā mēs neapsvērsim aizsardzību pret tādiem draudiem kā “Ir ieradies meteorīts”. Tātad ģeogrāfiski izkliedēta avārijas seku novēršanas risinājuma izveide joprojām būs viena no turpmākajiem rakstiem. Šeit apskatīsim tā saukto Cross-Rack katastrofu atkopšanas risinājumu, kad aizsardzība tiek veidota serveru skapju līmenī. Paši skapji var atrasties vienā telpā vai dažādās, bet parasti vienas ēkas ietvaros.

Šajos skapjos ir jābūt visam nepieciešamajam aprīkojuma un programmatūras komplektam, kas ļaus darboties Oracle datubāzēm neatkarīgi no “kaimiņa” stāvokļa. Citiem vārdiem sakot, izmantojot Cross-Rack avārijas atkopšanas risinājumu, mēs novēršam atteices riskus:

• Oracle lietojumprogrammu serveri
• Uzglabāšanas sistēmas
• Komutācijas sistēmas
• Pilnīga visa skapī esošā aprīkojuma kļūme:
  • Varas atteikums
  • Dzesēšanas sistēmas kļūme
  • Ārējie faktori (cilvēks, daba utt.)

Oracle serveru dublēšana ietver pašu Oracle RAC darbības principu un tiek īstenota, izmantojot lietojumprogrammu. Arī komutācijas iespēju dublēšanās nav problēma. Bet ar uzglabāšanas sistēmas dublēšanos viss nav tik vienkārši.

Vienkāršākā iespēja ir datu replikācija no galvenās krātuves sistēmas uz rezerves sistēmu. Sinhronā vai asinhronā, atkarībā no uzglabāšanas sistēmas iespējām. Izmantojot asinhrono replikāciju, nekavējoties rodas jautājums par datu konsekvences nodrošināšanu attiecībā uz Oracle. Bet pat tad, ja ir programmatūras integrācija ar lietojumprogrammu, jebkurā gadījumā galvenās krātuves sistēmas kļūmes gadījumā būs nepieciešama manuāla administratoru iejaukšanās, lai pārslēgtu klasteru uz rezerves krātuvi.

Sarežģītāka iespēja ir programmatūras un/vai aparatūras uzglabāšanas "virtualizatori", kas novērsīs konsekvences problēmas un manuālu iejaukšanos. Taču izvietošanas un turpmākās administrēšanas sarežģītība, kā arī šādu risinājumu ļoti nepiedienīgās izmaksas daudzus atbaida.

AccelStor NeoSapphire™ All Flash masīva risinājums ir lieliski piemērots tādiem scenārijiem kā Cross-Rack avārijas atkopšana H710 izmantojot Shared-Nothing arhitektūru. Šis modelis ir divu mezglu uzglabāšanas sistēma, kas izmanto patentētu FlexiRemap® tehnoloģiju, lai strādātu ar zibatmiņas diskiem. Pateicoties FlexiRemap® NeoSapphire™ H710 spēj nodrošināt veiktspēju līdz pat 600 K IOPS@4K izlases veida rakstīšanai un 1 miljonam+ IOPS@4K nejaušai lasīšanai, kas nav sasniedzams, izmantojot klasiskās uz RAID balstītas uzglabāšanas sistēmas.

Taču NeoSapphire™ H710 galvenā iezīme ir divu mezglu izpilde atsevišķu gadījumu veidā, kuriem katram ir sava datu kopija. Mezglu sinhronizācija tiek veikta, izmantojot ārējo InfiniBand interfeisu. Pateicoties šai arhitektūrai, ir iespējams sadalīt mezglus dažādās vietās līdz 100 m attālumā, tādējādi nodrošinot Cross-Rack avārijas atkopšanas risinājumu. Abi mezgli darbojas pilnīgi sinhroni. No saimniekdatora puses H710 izskatās kā parasta divu kontrolieru glabāšanas sistēma. Tāpēc nav nepieciešams veikt papildu programmatūras vai aparatūras opcijas vai īpaši sarežģītus iestatījumus.

Ja salīdzinām visus iepriekš aprakstītos Cross-Rack avārijas atkopšanas risinājumus, tad AccelStor opcija ievērojami izceļas no pārējiem:

AccelStor NeoSapphire™ Shared Nothing Architecture
Programmatūras vai aparatūras "virtualizatora" uzglabāšanas sistēma
Replikāciju balstīts risinājums

Pieejamība

Servera kļūme
Nav dīkstāves
Nav dīkstāves
Nav dīkstāves

Slēdža kļūme
Nav dīkstāves
Nav dīkstāves
Nav dīkstāves

Uzglabāšanas sistēmas kļūme
Nav dīkstāves
Nav dīkstāves
Dīkstāves

Visa skapja kļūme
Nav dīkstāves
Nav dīkstāves
Dīkstāves

Izmaksas un sarežģītība

Risinājuma izmaksas
zems*
Augsts
Augsts

Izvietošanas sarežģītība
Zems
Augsts
Augsts

*AccelStor NeoSapphire™ joprojām ir All Flash masīvs, kas pēc definīcijas nemaksā “3 kapeikas”, jo īpaši tāpēc, ka tam ir dubulta jaudas rezerve. Tomēr, salīdzinot uz tā balstīta risinājuma galīgās izmaksas ar līdzīgiem citu piegādātāju risinājumiem, izmaksas var uzskatīt par zemām.

Lietojumprogrammu serveru un visu Flash masīva mezglu savienošanas topoloģija izskatīsies šādi:

Plānojot topoloģiju, ļoti ieteicams arī dublēt pārvaldības slēdžus un savienot serverus.

Šeit un tālāk mēs runāsim par savienojuma izveidi, izmantojot Fibre Channel. Ja izmantojat iSCSI, viss būs vienāds, pielāgots izmantoto slēdžu veidiem un nedaudz atšķirīgiem masīva iestatījumiem.

Sagatavošanas darbi pie masīva

Izmantotais aprīkojums un programmatūra

Serveru un slēdžu specifikācijas

Komponenti
Apraksts

Oracle Database 11g serveri
Divās

Servera operētājsistēma
Oracle Linux

Oracle datu bāzes versija
11 g (RAC)

Procesori uz serveri
Divi 16 kodolu Intel® Xeon® CPU E5-2667 v2 @ 3.30 GHz

Fiziskā atmiņa uz serveri
128GB

FC tīkls
16Gb/s FC ar daudzceļu

FC HBA
Emulex Lpe-16002B

Īpaši publiskie 1GbE porti klasteru pārvaldībai
Intel Ethernet adapteris RJ45

16Gb/s FC slēdzis
Brokāde 6505

Īpaši privātie 10GbE porti datu sinhronizēšanai
Intel X520

AccelStor NeoSapphire™ visa zibspuldzes masīva specifikācija

Komponenti
Apraksts

Uzglabāšanas sistēma
NeoSapphire™ augstas pieejamības modelis: H710

Attēla versija
4.0.1

Kopējais disku skaits
48

Piedziņas izmērs
1.92TB

Piedziņas veids
SSD

FC mērķa porti
16 x 16 Gb porti (8 vienā mezglā)

Pārvaldības porti
1GbE Ethernet kabelis, kas savieno ar saimniekdatoriem, izmantojot Ethernet slēdzi

Sirdspukstu osta
1GbE Ethernet kabelis, kas savieno divus uzglabāšanas mezglus

Datu sinhronizācijas ports
56Gb/s InfiniBand kabelis

Lai varētu izmantot masīvu, tas ir jāinicializē. Pēc noklusējuma abu mezglu vadības adrese ir vienāda (192.168.1.1). Ar tiem jāpieslēdzas pa vienam un jāiestata jaunas (jau dažādas) pārvaldības adreses un jāiestata laika sinhronizācija, pēc kuras Management portus var savienot ar vienu tīklu. Pēc tam mezgli tiek apvienoti HA pārī, piešķirot apakštīklus starpsaišu savienojumiem.

Kad inicializācija ir pabeigta, varat pārvaldīt masīvu no jebkura mezgla.

Tālāk mēs izveidojam nepieciešamos sējumus un publicējam tos lietojumprogrammu serveros.

Ir ļoti ieteicams izveidot vairākus Oracle ASM sējumus, jo tas palielinās serveru mērķu skaitu, kas galu galā uzlabos vispārējo veiktspēju (vairāk par rindām citā raksts).

Testa konfigurācija

Krātuves apjoma nosaukums
Tilpuma lielums

Dati01
200GB

Dati02
200GB

Dati03
200GB

Dati04
200GB

Dati05
200GB

Dati06
200GB

Dati07
200GB

Dati08
200GB

Dati09
200GB

Dati10
200GB

Grid01
1GB

Grid02
1GB

Grid03
1GB

Grid04
1GB

Grid05
1GB

Grid06
1GB

Atkārtot01
100GB

Atkārtot02
100GB

Atkārtot03
100GB

Atkārtot04
100GB

Atkārtot05
100GB

Atkārtot06
100GB

Atkārtot07
100GB

Atkārtot08
100GB

Atkārtot09
100GB

Atkārtot10
100GB

Daži skaidrojumi par masīva darbības režīmiem un procesiem, kas notiek ārkārtas situācijās

Katra mezgla datu kopai ir parametrs “versijas numurs”. Pēc sākotnējās inicializācijas tas ir vienāds un vienāds ar 1. Ja kāda iemesla dēļ versijas numurs ir atšķirīgs, tad dati vienmēr tiek sinhronizēti no vecākās versijas uz jaunāko, pēc tam tiek izlīdzināts jaunākās versijas numurs, t.i. tas nozīmē, ka kopijas ir identiskas. Iemesli, kāpēc versijas var atšķirties:

• Ieplānota viena mezgla atsāknēšana
• Negadījums vienā no mezgliem pēkšņas izslēgšanas dēļ (barošanas padeve, pārkaršana utt.).
• Pazaudēts InfiniBand savienojums ar nespēju sinhronizēt
• Avārija vienā no mezgliem datu bojājumu dēļ. Šeit jums būs jāizveido jauna HA grupa un jāpabeidz datu kopas sinhronizācija.

Jebkurā gadījumā mezgls, kas paliek tiešsaistē, palielina savu versijas numuru par vienu, lai pēc savienojuma ar pāri atjaunošanas sinhronizētu savu datu kopu.

Ja savienojums, izmantojot Ethernet saiti, tiek zaudēts, Heartbeat īslaicīgi pārslēdzas uz InfiniBand un atgriežas 10 sekunžu laikā, kad tas ir atjaunots.

Saimnieku iestatīšana

Lai nodrošinātu kļūdu toleranci un uzlabotu veiktspēju, jums ir jāiespējo MPIO atbalsts masīvam. Lai to izdarītu, failam /etc/multipath.conf jāpievieno rindas un pēc tam jārestartē vairākceļu pakalpojums.

Slēpts tekstsierīces {
ierīce {
pārdevējs "AStor"
path_grouping_policy "group_by_prio"
path_selector "rindas garums 0"
ceļa_pārbaudītājs "tur"
funkcijas "0"
hardware_handler "0"
pirms "konst"
nekavējoties
fast_io_fail_tmo 5
dev_loss_tmo 60
lietotājam draudzīgi_nosaukumi jā
detect_prio jā
rr_min_io_rq 1
no_path_retry 0
}
}

Tālāk, lai ASM varētu strādāt ar MPIO, izmantojot ASMLib, jums ir jāmaina /etc/sysconfig/oracleasm fails un pēc tam jāpalaiž /etc/init.d/oracleasm scandisks

Slēpts teksts

# ORACLEASM_SCANORDER: modeļu atbilstība diska skenēšanas pasūtīšanai
ORACLEASM_SCANORDER="dm"

# ORACLEASM_SCANEXCLUDE: atbilst modeļi, lai izslēgtu diskus no skenēšanas
ORACLEASM_SCANEXCLUDE="sd"

Piezīme

Ja nevēlaties izmantot ASMLib, varat izmantot UDEV noteikumus, kas ir ASMLib pamatā.

Sākot ar Oracle Database versiju 12.1.0.2, šī opcija ir pieejama instalēšanai kā daļa no ASMFD programmatūras.

Ir obligāti jānodrošina, lai Oracle ASM izveidotie diski būtu saskaņoti ar bloka izmēru, ar kādu masīvs fiziski darbojas (4K). Pretējā gadījumā var rasties veiktspējas problēmas. Tāpēc ir jāizveido sējumi ar atbilstošiem parametriem:

parted /dev/mapper/ierīces nosaukums mklabel gpt mkpart primārais 2048s 100% align-check optimal 1

Datu bāzu sadalījums izveidotajos sējumos mūsu testa konfigurācijai

Krātuves apjoma nosaukums
Tilpuma lielums
Skaļuma LUN kartēšana
ASM skaļuma ierīces informācija
Piešķīruma vienības lielums

Dati01
200GB
Kartē visus krātuves apjomus ar krātuves sistēmas visus datu portus
Atlaišana: normāla
Nosaukums: DGDATA
Mērķis: datu faili

4MB

Dati02
200GB

Dati03
200GB

Dati04
200GB

Dati05
200GB

Dati06
200GB

Dati07
200GB

Dati08
200GB

Dati09
200GB

Dati10
200GB

Grid01
1GB
Atlaišana: normāla
Nosaukums: DGGRID1
Mērķis: Režģis: DRS un balsošana

4MB

Grid02
1GB

Grid03
1GB

Grid04
1GB
Atlaišana: normāla
Nosaukums: DGGRID2
Mērķis: Režģis: DRS un balsošana

4MB

Grid05
1GB

Grid06
1GB

Atkārtot01
100GB
Atlaišana: normāla
Vārds: DGREDO1
Mērķis: atjaunot 1. vītnes žurnālu

4MB

Atkārtot02
100GB

Atkārtot03
100GB

Atkārtot04
100GB

Atkārtot05
100GB

Atkārtot06
100GB
Atlaišana: normāla
Vārds: DGREDO2
Mērķis: atjaunot 2. vītnes žurnālu

4MB

Atkārtot07
100GB

Atkārtot08
100GB

Atkārtot09
100GB

Atkārtot10
100GB

Datu bāzes iestatījumi

• Bloka izmērs = 8K
• Maināmā vieta = 16 GB
• Atspējot AMM (automātisko atmiņas pārvaldību)
• Atspējot caurspīdīgās milzīgas lapas

Citi iestatījumi

# 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 # neiestatiet to, ja izmantojat Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000

# vi /etc/security/limits.conf
✓ grid soft nproc 2047
✓ režģa cietais nproc 16384
✓ režģa mīkstais nofile 1024
✓ režģa cietais nofile 65536
✓ režģa mīkstā kaudze 10240
✓ režģa cietā kaudze 32768
✓ Oracle soft nproc 2047
✓ Oracle hard nproc 16384
✓ Oracle soft nofile 1024
✓ Oracle cietais nofile 65536
✓ Oracle soft stack 10240
✓ Oracle cietā kaudze 32768
✓ mīkstais memlock 120795954
✓ cietais atmiņu bloks 120795954

sqlplus “/as sysdba”
mainīt sistēmas kopas procesus=2000 tvērums=spfile;
mainīt sistēmas kopu open_cursors=2000 tvērums=spfile;
mainīt sistēmas kopu session_cached_cursors=300 sfēra=spfile;
mainīt sistēmas kopu db_files=8192 sfēra=spfile;

Neveiksmes pārbaude

Demonstrācijas nolūkos HammerDB tika izmantots, lai emulētu OLTP slodzi. HammerDB konfigurācija:

Noliktavu skaits
256

Kopējais darījumu skaits vienam lietotājam
1000000000000

Virtuālie lietotāji
256

Rezultāts bija 2.1 M TPM, kas ir tālu no masīva veiktspējas ierobežojuma H710, bet ir “griesti” pašreizējai serveru aparatūras konfigurācijai (galvenokārt procesoru dēļ) un to skaitam. Šī testa mērķis joprojām ir demonstrēt risinājuma kļūdu toleranci kopumā, nevis sasniegt maksimālu veiktspēju. Tāpēc mēs vienkārši balstīsimies uz šo skaitli.

Pārbaudiet, vai nav kāda no mezgliem atteices

Saimnieki zaudēja daļu ceļu uz krātuvi, turpinot strādāt ar atlikušajiem ceļiem ar otro mezglu. Veiktspēja uz dažām sekundēm kritās, jo celiņi tika pārbūvēti, un pēc tam atgriezās normālā stāvoklī. Pakalpojumā nebija nekādu pārtraukumu.

Skapja bojājumu pārbaude ar visu aprīkojumu

Šajā gadījumā arī veiktspēja uz dažām sekundēm samazinājās ceļu pārstrukturēšanas dēļ un pēc tam atgriezās uz pusi no sākotnējās vērtības. Rezultāts tika samazināts uz pusi salīdzinājumā ar sākotnējo, jo viens lietojumprogrammu serveris tika izslēgts no darbības. Arī apkalpošanā nebija nekādu pārtraukumu.

Ja ir nepieciešams ieviest defektiem izturīgu Cross-Rack avārijas atkopšanas risinājumu Oracle par saprātīgām izmaksām un ar nelielu izvietošanas/administrēšanas piepūli, Oracle RAC un arhitektūra strādā kopā. AccelStor koplietots — nekas būs viens no labākajiem variantiem. Oracle RAC vietā var būt jebkura cita programmatūra, kas nodrošina klasterizāciju, piemēram, tās pašas DBVS vai virtualizācijas sistēmas. Risinājuma konstruēšanas princips paliks nemainīgs. Un apakšējā līnija ir nulle attiecībā uz RTO un RPO.

Avots: www.habr.com