Bou 'n foutverdraagsame oplossing gebaseer op Oracle RAC en AccelStor Shared-Nothing-argitektuur

'n Aansienlike aantal ondernemingstoepassings en virtualiseringstelsels het hul eie meganismes om foutverdraagsame oplossings te bou. Spesifiek, Oracle RAC (Oracle Real Application Cluster) is 'n groep van twee of meer Oracle-databasisbedieners wat saamwerk om lasbalansering en fouttoleransie op die bediener/toepassingsvlak te verskaf. Om in hierdie modus te werk, benodig jy 'n gedeelde berging, wat gewoonlik die bergingstelsel is.

Soos ons reeds in een van ons bespreek het artikels, het die stoorstelsel self, ten spyte van die teenwoordigheid van gedupliseerde komponente (insluitend beheerders), steeds punte van mislukking - hoofsaaklik in die vorm van 'n enkele datastel. Daarom, om 'n Oracle-oplossing met verhoogde vereistes vir betroubaarheid te bou, moet die "N bedieners - een stoorstelsel"-skema ingewikkeld wees.

Bou 'n foutverdraagsame oplossing gebaseer op Oracle RAC en AccelStor Shared-Nothing-argitektuur

Eerstens moet ons natuurlik besluit teen watter risiko's ons probeer verseker. Binne die raamwerk van hierdie artikel sal ons nie beskerming teen bedreigings soos "'n meteoriet het aangekom" oorweeg nie. Die bou van 'n geografies verspreide oplossing vir rampherstel sal dus 'n onderwerp vir een van die volgende artikels bly. Hier sal ons die sogenaamde Cross-Rack-ramphersteloplossing oorweeg, wanneer beskerming op die vlak van bedienerkaste gebou word. Die kaste self kan beide in dieselfde kamer en in verskillende kamers geleë wees, maar gewoonlik binne dieselfde gebou.

Hierdie kaste moet al die nodige stel hardeware en sagteware bevat wat Oracle-databasisse sal toelaat om te werk, ongeag die toestand van die "buurman". Met ander woorde, deur die Cross-Rack-ramphersteloplossing te gebruik, skakel ons die risiko's van mislukking uit:

  • Oracle-toepassingsbedieners
  • Bergingstelsels
  • Skakel stelsels
  • Volledige mislukking van alle toerusting in die kas:
    • voedsel ontkenning
    • Verkoelingstelsel mislukking
    • Eksterne faktore (mens, natuur, ens.)

Duplisering van Oracle-bedieners impliseer die beginsel van Oracle RAC-werking en word deur die toepassing geïmplementeer. Duplisering van skakelfasiliteite is ook nie 'n probleem nie. Maar met die duplisering van die bergingstelsel is alles nie so eenvoudig nie.

Die maklikste opsie is om data van die hoofbergingstelsel na die rugsteunstelsel te repliseer. Sinchronies of asinchronies, afhangende van die bergingsvermoëns. Met asinchroniese replikasie ontstaan ​​die vraag onmiddellik om datakonsekwentheid met betrekking tot Oracle te verseker. Maar selfs al is daar sagteware-integrasie met die toepassing, in elk geval, in die geval van 'n mislukking op die hoofbergingstelsel, sal handmatige ingryping deur administrateurs vereis word om die groepie na die rugsteunberging oor te skakel.

'n Meer komplekse opsie is sagteware en/of hardeware "virtualiseerders" van bergingstelsels wat probleme met konsekwentheid en handmatige ingryping sal uitskakel. Maar die kompleksiteit van ontplooiing en daaropvolgende administrasie, sowel as die baie onsedelike koste van sulke oplossings, skrik baie af.

Net vir scenario's soos Cross-Rack-rampherstel, is die AccelStor NeoSapphire™ All Flash-skikking perfek H710 gebruik Shared-Nothing-argitektuur. Hierdie model is 'n dubbelnode-bergingstelsel wat eie FlexiRemap®-tegnologie gebruik om met flash drives te werk. Te danke aan FlexiRemap® NeoSapphire™ H710 is in staat om werkverrigting te lewer tot 600K IOPS@4K ewekansige skryf en 1M+ IOPS@4K ewekansige lees, wat onbereikbaar is wanneer klassieke RAID-gebaseerde bergingstelsels gebruik word.

Maar die hoofkenmerk van NeoSapphire™ H710 is die uitvoering van twee nodusse in die vorm van afsonderlike gevalle, wat elkeen sy eie kopie van die data het. Sinchronisasie van nodusse word uitgevoer deur die eksterne InfiniBand-koppelvlak. Danksy hierdie argitektuur is dit moontlik om nodusse na verskillende liggings op 'n afstand van tot 100m te versprei en sodoende 'n Cross-Rack-ramphersteloplossing te verskaf. Albei nodusse werk heeltemal in sinchroniese modus. Van die kant van die gashere lyk die H710 soos 'n gewone twee-beheerder stoorstelsel. Daarom hoef geen bykomende sagteware- en hardeware-opsies en besonder komplekse instellings uitgevoer te word nie.

As ons al die bogenoemde Cross-Rack-ramphersteloplossings vergelyk, dan staan ​​die weergawe van AccelStor uit van die res:

AccelStor NeoSapphire™ het niks-argitektuur gedeel
Sagteware of hardeware "virtualizer" berging
Replikasie-gebaseerde oplossing

beskikbaarheid

Bedienerfout
Geen stilstand nie
Geen stilstand nie
Geen stilstand nie

Skakelaar mislukking
Geen stilstand nie
Geen stilstand nie
Geen stilstand nie

Berging mislukking
Geen stilstand nie
Geen stilstand nie
Stilstand

Mislukking van die hele kabinet
Geen stilstand nie
Geen stilstand nie
Stilstand

Koste en kompleksiteit

Oplossing koste
Laag*
High
High

Ontplooiing kompleksiteit
lae
High
High

*AccelStor NeoSapphire™ is steeds 'n All Flash-skikking, wat per definisie nie "3 kopecks" kos nie, veral met 'n dubbele stoorkapasiteit. Wanneer die finale koste van 'n oplossing wat daarop gebaseer is met soortgelyke van ander verskaffers vergelyk word, kan die koste egter as laag beskou word.

Die topologie vir die koppeling van toepassingsbedieners en nodusse van die All Flash-skikking sal soos volg lyk:

Bou 'n foutverdraagsame oplossing gebaseer op Oracle RAC en AccelStor Shared-Nothing-argitektuur

Wanneer die topologie beplan word, word dit ook sterk aanbeveel om die bestuurskakelaars en bedienerverbindings te dupliseer.

Hierna sal ons praat oor verbinding via Fibre Channel. In die geval van die gebruik van iSCSI, sal alles dieselfde wees, aangepas vir die tipe skakelaars wat gebruik word en effens verskillende skikking instellings.

Voorbereidende werk op die skikking

Gebruikte hardeware en sagteware

Bediener en skakelaar spesifikasies

Komponente
Beskrywing

Oracle-databasis 11g-bedieners
Twee

bediener bedryfstelsel
oracle linux

Oracle databasis weergawe
11 g (RAC)

Verwerkers per bediener
Twee 16 kern Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz

fisiese geheue per bediener
128GB

FC netwerk
16Gb/s FC met multipathing

FC HBA
Emulex Lpe-16002B

Toegewyde publieke 1GbE-poorte vir groepbestuur
Intel Ethernet-adapter RJ45

16Gb/s FC-skakelaar
Brokaat 6505

Toegewyde privaat 10GbE-poorte vir datasinkronisering
Intel X520

AccelStor NeoSapphhire™ All Flash Array Spesifikasie

Komponente
Beskrywing

Bergingstelsel
NeoSapphire™-model met hoë beskikbaarheid: H710

beeld weergawe
4.0.1

Totale aantal dryf
48

Ry grootte
1.92TB

Ry tipe
SSD

FC teikenpoorte
16x 16Gb-poorte (8 per nodus)

Bestuur hawens
Die 1GbE-ethernetkabel wat aan gashere verbind word via 'n Ethernet-skakelaar

hartkloppoort
Die 1GbE-ethernetkabel wat tussen twee stoornodusse verbind

Datasinchronisasiepoort
56Gb/s InfiniBand-kabel

Voordat 'n skikking gebruik kan word, moet dit geïnisialiseer word. By verstek is die beheeradres van beide nodusse dieselfde (192.168.1.1). Jy moet een vir een aan hulle koppel en nuwe (reeds verskillende) bestuursadresse instel en tydsinchronisasie opstel, waarna die Bestuurspoorte aan 'n enkele netwerk gekoppel kan word. Daarna word die nodusse in 'n HA-paar gekombineer deur subnette vir interlink-verbindings toe te ken.

Bou 'n foutverdraagsame oplossing gebaseer op Oracle RAC en AccelStor Shared-Nothing-argitektuur

Nadat die inisialisering voltooi is, kan jy die skikking vanaf enige nodus bestuur.

Vervolgens skep ons die nodige volumes en publiseer dit na die toepassingsbedieners.

Bou 'n foutverdraagsame oplossing gebaseer op Oracle RAC en AccelStor Shared-Nothing-argitektuur

Dit word sterk aanbeveel om veelvuldige volumes vir Oracle ASM te skep, aangesien dit die aantal teikens vir bedieners sal verhoog, wat uiteindelik algehele werkverrigting sal verbeter (meer oor toue in 'n ander Artikel).

Toets konfigurasie

Berging Volume Naam
Volume Grootte

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

Herhaal 01
100GB

Herhaal 02
100GB

Herhaal 03
100GB

Herhaal 04
100GB

Herhaal 05
100GB

Herhaal 06
100GB

Herhaal 07
100GB

Herhaal 08
100GB

Herhaal 09
100GB

Herhaal 10
100GB

Enkele verduidelikings oor die bedryfsmodusse van die skikking en die deurlopende prosesse in noodsituasies

Bou 'n foutverdraagsame oplossing gebaseer op Oracle RAC en AccelStor Shared-Nothing-argitektuur

Elke nodus se datastel het 'n "weergawenommer" parameter. Na die aanvanklike inisialisering is dit dieselfde en gelyk aan 1. As die weergawenommer om een ​​of ander rede verskil, dan word die data altyd vanaf die ouer weergawe na die jonger een gesinchroniseer, waarna die nommer van die jonger weergawe gelyk gemaak word, m.a.w. dit beteken dat die kopieë identies is. Redes waarom weergawes anders kan wees:

  • Geskeduleerde herlaai van een van die nodusse
  • 'n Ongeluk op een van die nodusse as gevolg van 'n skielike afskakeling (krag, oorverhitting, ens.).
  • Verlore InfiniBand-verbinding met onvermoë om te sinkroniseer
  • 'n Ongeluk op een van die nodusse weens datakorrupsie. Dit sal reeds die skepping van 'n nuwe HA-groep en volle sinchronisasie van die datastel vereis.

In beide gevalle verhoog die nodus wat aanlyn bly sy weergawenommer met een sodat wanneer kommunikasie met die paar herstel word, sy datastel gesinchroniseer sal word.

As daar 'n onderbreking in die verbinding oor die Ethernet-skakel is, skakel Heartbeat tydelik oor na InfiniBand en keer terug binne 10s wanneer dit herstel word.

Gashere-opstelling

Vir fouttoleransie en beter werkverrigting moet MPIO-ondersteuning vir die skikking geaktiveer word. Om dit te doen, voeg reëls by die /etc/multipath.conf-lêer, en herbegin dan die multipath-diens

Versteekte tekstoestelle {
toestel {
verkoper "AStor"
pad_groeperingsbeleid "groep_vir_prio"
pad-kieser "tou-lengte 0"
padkontroleerder "tur"
kenmerke "0"
hardeware_hanteerder "0"
prio "konst"
mislukking onmiddellik
fast_io_fail_tmo 5
dev_loss_tmo 60
gebruikersvriendelike_name ja
detect_prio ja
rr_min_io_rq 1
geen_pad_probeer weer 0
}
}

Volgende, sodat ASM met MPIO deur ASMLib kan werk, moet jy die /etc/sysconfig/oracleasm-lêer verander en dan /etc/init.d/oracleasm scandisks hardloop

Versteekte teks

# ORACLESM_SCANORDER: Pas patrone om skyfskandering te bestel
ORACLESM_SCANORDER="dm"

# ORACLEASM_SCANEXCLUDE: Pas patrone om skywe van skandering uit te sluit
ORACLEASM_SCANEXCLUDE="sd"

Let daarop

As jy nie ASMLib wil gebruik nie, kan jy die UDEV-reëls gebruik, wat die basis vir ASMLib is.

Vanaf weergawe 12.1.0.2 van Oracle-databasis, is die opsie beskikbaar vir installasie as deel van die ASMFD-sagteware.

Maak seker dat jy seker maak dat die skywe wat jy vir Oracle ASM skep, in lyn is met die blokgrootte waarmee die skikking fisies werk (4K). Andersins is prestasieprobleme moontlik. Daarom is dit nodig om volumes te skep met die toepaslike parameters:

geskei /dev/mapper/device-name mklabel gpt mkpart primêre 2048s 100% belyn-kontroleer optimaal 1

Verspreiding van databasisse oor geskepde volumes vir ons toetskonfigurasie

Berging Volume Naam
Volume Grootte
Volume LUNs kartering
ASM Volume Toestel Detail
Toewysingseenheid Grootte

Data01
200GB
Kaart alle stoorvolumes na die stoorstelsel alle datapoorte
Oortolligheid: Normaal
Naam: DGDATA
Doel: Datalêers

4MB

Data02
200GB

Data03
200GB

Data04
200GB

Data05
200GB

Data06
200GB

Data07
200GB

Data08
200GB

Data09
200GB

Data10
200GB

Grid01
1GB
Oortolligheid: Normaal
Naam: DGGRID1
Doel: Rooster: CRS en Stemming

4MB

Grid02
1GB

Grid03
1GB

Grid04
1GB
Oortolligheid: Normaal
Naam: DGGRID2
Doel: Rooster: CRS en Stemming

4MB

Grid05
1GB

Grid06
1GB

Herhaal 01
100GB
Oortolligheid: Normaal
Naam: DGREDO1
Doel: Herhaal log van draad 1

4MB

Herhaal 02
100GB

Herhaal 03
100GB

Herhaal 04
100GB

Herhaal 05
100GB

Herhaal 06
100GB
Oortolligheid: Normaal
Naam: DGREDO2
Doel: Herhaal log van draad 2

4MB

Herhaal 07
100GB

Herhaal 08
100GB

Herhaal 09
100GB

Herhaal 10
100GB

Databasis instellings

  • blokgrootte = 8K
  • Ruil spasie = 16GB
  • Deaktiveer AMM (outomatiese geheuebestuur)
  • Deaktiveer deursigtige groot bladsye

Ander instellings

#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.ruilmiddel=10
✓ vm.min_free_kbytes=524288 # moenie dit stel as jy Linux x86 gebruik nie
vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000

# vi /etc/security/limits.conf
✓ rooster sagte nproc 2047
✓ rooster harde nproc 16384
✓ rooster sagte nofile 1024
✓ rooster harde nofile 65536
✓ rooster sagte stapel 10240
✓ rooster harde stapel 32768
✓ oracle soft nproc 2047
✓ oracle hard nproc 16384
✓ oracle soft nofile 1024
✓ oracle harde nofile 65536
✓ oracle soft stack 10240
✓ oracle harde stapel 32768
✓ sagte memlock 120795954
✓ harde memlock 120795954

sqlplus "/as sysdba"
verander stelsel stel prosesse = 2000 omvang = sp-lêer;
verander stelsel stel open_cursors=2000 scope=spfile;
verander stelsel stel session_cached_cursors=300 scope=spfile;
verander stelsel stel db_files=8192 scope=spfile;

Fouttoleransie toets

Vir demonstrasiedoeleindes is HammerDB gebruik om 'n OLTP-werklading na te boots. HammerDB-konfigurasie:

Aantal pakhuise
256

Totale transaksies per gebruiker
1000000000000

Virtuele gebruikers
256

Die resultaat was 2.1M TPM, ver van die prestasielimiet van die skikking H710, maar dit is 'n "plafon" vir die huidige hardeware-konfigurasie van bedieners (hoofsaaklik as gevolg van verwerkers) en hul nommer. Die doel van hierdie toets is steeds om die fouttoleransie van die oplossing as geheel te demonstreer, en nie om maksimum werkverrigting te behaal nie. Daarom sal ons eenvoudig op hierdie figuur bou.

Bou 'n foutverdraagsame oplossing gebaseer op Oracle RAC en AccelStor Shared-Nothing-argitektuur

Toets vir mislukking van een van die nodusse

Bou 'n foutverdraagsame oplossing gebaseer op Oracle RAC en AccelStor Shared-Nothing-argitektuur

Bou 'n foutverdraagsame oplossing gebaseer op Oracle RAC en AccelStor Shared-Nothing-argitektuur

Die gashere het sommige van die paaie na die berging verloor, en het voortgegaan om deur die oorblywendes met die tweede nodus te werk. Werkverrigting het vir 'n paar sekondes gedaal weens die herbou van die pad en het toe na normaal teruggekeer. Daar was geen diensonderbreking nie.

Kabinet mislukking toets met alle toerusting

Bou 'n foutverdraagsame oplossing gebaseer op Oracle RAC en AccelStor Shared-Nothing-argitektuur

Bou 'n foutverdraagsame oplossing gebaseer op Oracle RAC en AccelStor Shared-Nothing-argitektuur

In hierdie geval het prestasie ook vir 'n paar sekondes gedaal as gevolg van die herbou van paaie, en dan teruggekeer na die helfte van die oorspronklike waarde. Die resultaat is gehalveer van die oorspronklike as gevolg van die uitsluiting van een toepassingsbediener van die werk. Daar was ook geen diensonderbreking nie.

As daar 'n behoefte is om 'n foutverdraagsame Cross-Rack-ramphersteloplossing vir Oracle te implementeer teen 'n redelike koste en met min ontplooiing / administrasiepoging, dan werk Oracle RAC en argitektuur saam AccelStor Gedeel-niks sou een van die beste opsies wees. In plaas van Oracle RAC, kan daar enige ander sagteware wees wat voorsiening maak vir groepering, byvoorbeeld dieselfde DBMS of virtualiseringstelsels. Die beginsel van die konstruksie van die oplossing sal dieselfde bly. En die bottom line is nul vir RTO en RPO.

Bron: will.com

Voeg 'n opmerking