Et betydeligt antal Enterprise-applikationer og virtualiseringssystemer har deres egne mekanismer til at bygge fejltolerante løsninger. Specifikt er Oracle RAC (Oracle Real Application Cluster) en klynge af to eller flere Oracle-databaseservere, der arbejder sammen for at balancere belastning og give fejltolerance på server-/applikationsniveau. For at arbejde i denne tilstand har du brug for et delt lager, som normalt er et lagersystem.
Som vi allerede har diskuteret i en af vores , selve lagersystemet, på trods af tilstedeværelsen af duplikerede komponenter (inklusive controllere), har stadig fejlpunkter - hovedsageligt i form af et enkelt sæt data. Derfor, for at bygge en Oracle-løsning med øgede krav til pålidelighed, skal "N servere - ét lagersystem"-skemaet være kompliceret.
Først skal vi selvfølgelig beslutte, hvilke risici vi forsøger at forsikre os imod. I denne artikel vil vi ikke overveje beskyttelse mod trusler som "en meteorit er ankommet." Så opbygning af en geografisk spredt disaster recovery-løsning vil forblive et emne for en af de følgende artikler. Her vil vi se på den såkaldte Cross-Rack disaster recovery løsning, når beskyttelse er bygget på niveau med serverkabinetter. Selve skabene kan placeres i samme rum eller i forskellige, men normalt inden for samme bygning.
Disse kabinetter skal indeholde hele det nødvendige sæt udstyr og software, der tillader driften af Oracle-databaser uanset tilstanden af "naboen". Med andre ord, ved at bruge Cross-Rack-katastrofegendannelsesløsningen eliminerer vi risikoen for fejl:
- Oracle applikationsservere
- Opbevaring systemer
- Skifte systemer
- Fuldstændig fejl på alt udstyr i kabinettet:
- Afslag på strøm
- Fejl i kølesystemet
- Eksterne faktorer (menneske, natur osv.)
Duplikering af Oracle-servere indebærer selve driftsprincippet i Oracle RAC og implementeres gennem en applikation. Duplikering af omstillingsfaciliteter er heller ikke et problem. Men med duplikering af lagersystemet er alt ikke så enkelt.
Den enkleste mulighed er datareplikering fra hovedlagersystemet til backupsystemet. Synkron eller asynkron, afhængigt af lagersystemets muligheder. Ved asynkron replikering opstår der straks spørgsmålet om at sikre datakonsistens i forhold til Oracle. Men selv hvis der er softwareintegration med applikationen, vil der under alle omstændigheder, hvis der er en fejl på hovedlagersystemet, kræves manuel indgriben fra administratorer for at skifte klyngen til backuplager.
En mere kompleks mulighed er software- og/eller hardwarelagrings-"virtualizere", der vil eliminere konsistensproblemer og manuel indgriben. Men kompleksiteten af implementeringen og den efterfølgende administration, såvel som de meget uanstændige omkostninger ved sådanne løsninger, afskrækker mange.
AccelStor NeoSapphire™ All Flash-array-løsningen er perfekt til scenarier som Cross-Rack-katastrofegendannelse ved hjælp af Shared-Nothing-arkitektur. Denne model er et to-node lagringssystem, der bruger proprietær FlexiRemap®-teknologi til at arbejde med flashdrev. Tak til NeoSapphire™ H710 er i stand til at levere ydeevne op til 600K IOPS@4K tilfældig skrivning og 1M+ IOPS@4K tilfældig læsning, hvilket er uopnåeligt ved brug af klassiske RAID-baserede lagersystemer.
Men hovedtræk ved NeoSapphire™ H710 er udførelsen af to noder i form af separate sager, som hver har sin egen kopi af dataene. Synkronisering af noder udføres gennem den eksterne InfiniBand-grænseflade. Takket være denne arkitektur er det muligt at distribuere noder til forskellige lokationer i en afstand på op til 100m, hvilket giver en Cross-Rack disaster recovery-løsning. Begge noder fungerer fuldstændig synkront. Fra værtssiden ligner H710 et almindeligt dual-controller-lagersystem. Derfor er det ikke nødvendigt at udføre yderligere software- eller hardwareindstillinger eller særligt komplekse indstillinger.
Hvis vi sammenligner alle Cross-Rack-katastrofegendannelsesløsningerne beskrevet ovenfor, skiller muligheden fra AccelStor sig mærkbart ud fra resten:
AccelStor NeoSapphire™ Shared Nothing Architecture
Software eller hardware "virtualizer" lagringssystem
Replikationsbaseret løsning
tilgængelighed
Serverfejl
Ingen nedetid
Ingen nedetid
Ingen nedetid
Switchfejl
Ingen nedetid
Ingen nedetid
Ingen nedetid
Lagersystemfejl
Ingen nedetid
Ingen nedetid
Nedetid
Hele kabinetsfejl
Ingen nedetid
Ingen nedetid
Nedetid
Omkostninger og kompleksitet
Løsningsomkostninger
Lav*
Høj
Høj
Implementeringskompleksitet
Низкая
Høj
Høj
*AccelStor NeoSapphire™ er stadig et All Flash-array, som pr. definition ikke koster "3 kopek", især da det har en dobbelt kapacitetsreserve. Men når man sammenligner de endelige omkostninger for en løsning baseret på den med lignende fra andre leverandører, kan omkostningerne betragtes som lave.
Topologien for tilslutning af applikationsservere og All Flash array noder vil se sådan ud:
Når du planlægger topologien, anbefales det også stærkt at duplikere administrationsswitches og sammenkoble servere.
Her og længere vil vi tale om tilslutning via Fibre Channel. Hvis du bruger iSCSI, vil alt være det samme, justeret for de anvendte typer af switche og lidt forskellige array-indstillinger.
Forberedende arbejde på arrayet
Anvendt udstyr og software
Server- og switch-specifikationer
Komponenter
beskrivelse
Oracle Database 11g servere
to
Server operativsystem
Oracle Linux
Oracle database version
11 g (RAC)
Processorer pr. server
To 16 kerner Intel® Xeon® CPU E5-2667 v2 @ 3.30 GHz
Fysisk hukommelse pr. server
128GB
FC netværk
16Gb/s FC med multipathing
FC HBA
Emulex Lpe-16002B
Dedikerede offentlige 1GbE-porte til klyngestyring
Intel ethernet adapter RJ45
16 Gb/s FC switch
Brokade 6505
Dedikerede private 10GbE-porte til datasynkronisering
Intel X520
AccelStor NeoSapphire™ All Flash Array Specifikation
Komponenter
beskrivelse
Lagersystem
NeoSapphire™ model med høj tilgængelighed: H710
Billedversion
4.0.1
Samlet antal drev
48
Drevstørrelse
1.92TB
Drev type
SSD
FC målporte
16 x 16 Gb porte (8 pr. node)
Ledelsesporte
1GbE Ethernet-kablet forbinder til værter via en Ethernet-switch
Hjerteslagsport
1GbE Ethernet-kablet forbinder mellem to lagernoder
Datasynkroniseringsport
56 Gb/s InfiniBand kabel
Før du kan bruge et array, skal du initialisere det. Som standard er kontroladressen for begge noder den samme (192.168.1.1). Du skal oprette forbindelse til dem én efter én og sætte nye (allerede forskellige) administrationsadresser og opsætte tidssynkronisering, hvorefter Management-portene kan forbindes til et enkelt netværk. Bagefter kombineres noderne til et HA-par ved at tildele undernet til interlinkforbindelser.
Når initialiseringen er fuldført, kan du administrere arrayet fra enhver node.
Dernæst opretter vi de nødvendige volumener og udgiver dem til applikationsservere.
Det anbefales stærkt at oprette flere volumener til Oracle ASM, da dette vil øge antallet af mål for serverne, hvilket i sidste ende vil forbedre den samlede ydeevne (mere om køer i en anden ).
Test konfiguration
Navn på lagervolumen
Volumenstørrelse
Data 01
200GB
Data 02
200GB
Data 03
200GB
Data 04
200GB
Data 05
200GB
Data 06
200GB
Data 07
200GB
Data 08
200GB
Data 09
200GB
Data 10
200GB
Grid01
1GB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Grid05
1GB
Grid06
1GB
Gentag 01
100GB
Gentag 02
100GB
Gentag 03
100GB
Gentag 04
100GB
Gentag 05
100GB
Gentag 06
100GB
Gentag 07
100GB
Gentag 08
100GB
Gentag 09
100GB
Gentag 10
100GB
Nogle forklaringer om arrayets driftstilstande og de processer, der forekommer i nødsituationer
Datasættet for hver node har en "versionsnummer"-parameter. Efter initialisering er det det samme og lig med 1. Hvis versionsnummeret af en eller anden grund er anderledes, så synkroniseres data altid fra den ældre version til den yngre, hvorefter nummeret på den yngre version justeres, dvs. det betyder, at kopierne er identiske. Årsager til, at versioner kan være forskellige:
- Planlagt genstart af en af noderne
- Et uheld på en af knudepunkterne på grund af en pludselig nedlukning (strømforsyning, overophedning osv.).
- Mistet InfiniBand-forbindelse med manglende evne til at synkronisere
- Et nedbrud på en af noderne på grund af datakorruption. Her skal du oprette en ny HA-gruppe og fuldføre synkronisering af datasættet.
Under alle omstændigheder øger den node, der forbliver online, sit versionsnummer med én for at synkronisere sit datasæt, efter at forbindelsen med parret er gendannet.
Hvis forbindelsen over Ethernet-forbindelsen afbrydes, skifter Heartbeat midlertidigt til InfiniBand og vender tilbage inden for 10 sekunder, når det gendannes.
Opsætning af værter
For at sikre fejltolerance og forbedre ydeevnen skal du aktivere MPIO-understøttelse for arrayet. For at gøre dette skal du tilføje linjer til filen /etc/multipath.conf og derefter genstarte multipath-tjenesten
Skjult tekstenheder {
enhed {
sælger "AStor"
path_grouping_policy "gruppe_efter_prio"
stivælger "kø-længde 0"
path_checker "tur"
har "0"
hardware_handler "0"
prio "konst"
failback øjeblikkeligt
fast_io_fail_tmo 5
dev_loss_tmo 60
brugervenlige_navne ja
detect_prio ja
rr_min_io_rq 1
no_path_retry 0
}
}
Dernæst, for at ASM kan arbejde med MPIO via ASMLib, skal du ændre filen /etc/sysconfig/oracleasm og derefter køre /etc/init.d/oracleasm scandisks
Skjult tekst
# ORACLEASM_SCANORDER: Matchende mønstre for at bestille diskscanning
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Matchende mønstre for at udelukke diske fra scanning
ORACLEASM_SCANEXCLUDE="sd"
Bemærk
Hvis du ikke ønsker at bruge ASMLib, kan du bruge UDEV-reglerne, som er grundlaget for ASMLib.
Fra og med version 12.1.0.2 af Oracle Database er muligheden tilgængelig for installation som en del af ASMFD-softwaren.
Det er bydende nødvendigt at sikre, at de diske, der er oprettet til Oracle ASM, er tilpasset den blokstørrelse, som arrayet fysisk opererer med (4K). Ellers kan der opstå ydeevneproblemer. Derfor er det nødvendigt at oprette volumener med de relevante parametre:
delt /dev/mapper/enhedsnavn mklabel gpt mkpart primære 2048s 100% align-check optimal 1
Distribution af databaser på tværs af oprettede volumener til vores testkonfiguration
Navn på lagervolumen
Volumenstørrelse
Volume LUN-kortlægning
ASM Volume Device Detail
Tildelingsenhedsstørrelse
Data 01
200GB
Tilknyt alle lagervolumener til lagersystem alle dataporte
Redundans: Normal
Navn: DGDATA
Formål: Datafiler
4MB
Data 02
200GB
Data 03
200GB
Data 04
200GB
Data 05
200GB
Data 06
200GB
Data 07
200GB
Data 08
200GB
Data 09
200GB
Data 10
200GB
Grid01
1GB
Redundans: Normal
Navn: DGGRID1
Formål: Gitter: CRS og afstemning
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundans: Normal
Navn: DGGRID2
Formål: Gitter: CRS og afstemning
4MB
Grid05
1GB
Grid06
1GB
Gentag 01
100GB
Redundans: Normal
Navn: DGREDO1
Formål: Gentag log af tråd 1
4MB
Gentag 02
100GB
Gentag 03
100GB
Gentag 04
100GB
Gentag 05
100GB
Gentag 06
100GB
Redundans: Normal
Navn: DGREDO2
Formål: Gentag log af tråd 2
4MB
Gentag 07
100GB
Gentag 08
100GB
Gentag 09
100GB
Gentag 10
100GB
Databaseindstillinger
- Blokstørrelse = 8K
- Byt plads = 16 GB
- Deaktiver AMM (Automatic Memory Management)
- Deaktiver Transparent Huge Pages
Andre indstillinger
# 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.bytte=10
✓ vm.min_free_kbytes=524288 # indstil ikke dette, hvis du bruger Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ gitter blød nproc 2047
✓ grid hard nproc 16384
✓ gitter blød nofile 1024
✓ grid hard nofile 65536
✓ gitter blød stak 10240
✓ gitter hård stak 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
✓ blød memlock 120795954
✓ hård memlock 120795954
sqlplus "/as sysdba"
ændre systemsæt processer=2000 scope=spfile;
ændre systemsæt open_cursors=2000 scope=spfile;
ændre systemsæt session_cached_cursors=300 scope=spfile;
ændre systemsæt db_files=8192 scope=spfile;
Fejltest
Til demonstrationsformål blev HammerDB brugt til at emulere en OLTP-belastning. HammerDB konfiguration:
Antal varehuse
256
Samlede transaktioner pr. bruger
1000000000000
Virtuelle brugere
256
Resultatet var en 2.1M TPM, hvilket er langt fra arrayets ydeevnegrænse , men er et "loft" for den aktuelle hardwarekonfiguration af servere (primært på grund af processorer) og deres antal. Formålet med denne test er stadig at demonstrere fejltolerancen for løsningen som helhed og ikke at opnå maksimal ydeevne. Derfor vil vi blot bygge videre på dette tal.
Test for fejl på en af noderne
Værterne mistede en del af stierne til lageret og fortsatte med at arbejde gennem de resterende med den anden node. Ydeevnen faldt i et par sekunder på grund af stierne, der blev genopbygget, og vendte derefter tilbage til normalen. Der var ingen afbrydelse i tjenesten.
Skabsfejltest med alt udstyr
I dette tilfælde faldt ydeevnen også i nogle få sekunder på grund af omstruktureringen af stierne og vendte derefter tilbage til halvdelen af den oprindelige værdi. Resultatet blev halveret i forhold til det oprindelige på grund af udelukkelsen af en applikationsserver fra drift. Der var heller ingen afbrydelse i tjenesten.
Hvis der er behov for at implementere en fejltolerant Cross-Rack-katastrofegendannelsesløsning til Oracle til en rimelig pris og med ringe implementerings-/administrationsindsats, så arbejder Oracle RAC og arkitektur sammen vil være en af de bedste muligheder. I stedet for Oracle RAC kan der være enhver anden software, der giver clustering, f.eks. samme DBMS eller virtualiseringssystemer. Princippet om at konstruere løsningen vil forblive det samme. Og bundlinjen er nul for RTO og RPO.
Kilde: www.habr.com