Et betydelig antall Enterprise-applikasjoner og virtualiseringssystemer har sine egne mekanismer for å bygge feiltolerante løsninger. Nærmere bestemt er Oracle RAC (Oracle Real Application Cluster) en klynge av to eller flere Oracle-databaseservere som jobber sammen for å balansere belastning og gi feiltoleranse på server-/applikasjonsnivå. For å jobbe i denne modusen trenger du en delt lagring, som vanligvis er et lagringssystem.
Som vi allerede har diskutert i en av våre , selve lagringssystemet, til tross for tilstedeværelsen av dupliserte komponenter (inkludert kontrollere), har fortsatt feilpunkter - hovedsakelig i form av et enkelt sett med data. Derfor, for å bygge en Oracle-løsning med økte krav til pålitelighet, må ordningen "N servere - ett lagringssystem" være komplisert.
Først må vi selvfølgelig bestemme hvilke risikoer vi prøver å forsikre oss mot. I denne artikkelen vil vi ikke vurdere beskyttelse mot trusler som "en meteoritt har ankommet." Så å bygge en geografisk spredt katastrofegjenopprettingsløsning vil fortsatt være et tema for en av de følgende artiklene. Her skal vi se på den såkalte Cross-Rack disaster recovery-løsningen, når beskyttelse bygges på nivå med serverskap. Selve skapene kan være plassert i samme rom eller i forskjellige, men vanligvis innenfor samme bygning.
Disse skapene må inneholde hele det nødvendige settet med utstyr og programvare som vil tillate drift av Oracle-databaser uavhengig av tilstanden til "naboen". Med andre ord, ved å bruke Cross-Rack-løsningen for katastrofegjenoppretting eliminerer vi risikoen for feil:
- Oracle applikasjonsservere
- Lagringssystemer
- Bytte systemer
- Fullstendig feil på alt utstyr i skapet:
- Strømavslag
- Kjølesystemfeil
- Ytre faktorer (menneske, natur, etc.)
Duplisering av Oracle-servere innebærer selve driftsprinsippet til Oracle RAC og implementeres gjennom en applikasjon. Duplisering av koblingsanlegg er heller ikke noe problem. Men med duplisering av lagringssystemet er ikke alt så enkelt.
Det enkleste alternativet er datareplikering fra hovedlagringssystemet til backupsystemet. Synkron eller asynkron, avhengig av lagringssystemets evner. Med asynkron replikering oppstår umiddelbart spørsmålet om å sikre datakonsistens i forhold til Oracle. Men selv om det er programvareintegrasjon med applikasjonen, vil det i alle fall, i tilfelle feil på hovedlagringssystemet, være nødvendig med manuell inngripen fra administratorer for å bytte klyngen til backuplagring.
Et mer komplekst alternativ er programvare- og/eller maskinvarelagrings-"virtualiseringer" som vil eliminere konsistensproblemer og manuell intervensjon. Men kompleksiteten ved utplassering og påfølgende administrasjon, samt de svært uanstendige kostnadene ved slike løsninger, skremmer mange.
AccelStor NeoSapphire™ All Flash array-løsningen er perfekt for scenarier som Cross-Rack katastrofegjenoppretting bruker Shared-Nothing-arkitekturen. Denne modellen er et lagringssystem med to noder som bruker proprietær FlexiRemap®-teknologi for å jobbe med flash-stasjoner. Takk til NeoSapphire™ H710 er i stand til å levere ytelse på opptil 600K IOPS@4K tilfeldig skriving og 1M+ IOPS@4K tilfeldig lesing, noe som er uoppnåelig ved bruk av klassiske RAID-baserte lagringssystemer.
Men hovedtrekket til NeoSapphire™ H710 er kjøringen av to noder i form av separate tilfeller, som hver har sin egen kopi av dataene. Synkronisering av noder utføres gjennom det eksterne InfiniBand-grensesnittet. Takket være denne arkitekturen er det mulig å distribuere noder til forskjellige steder i en avstand på opptil 100m, og dermed gi en Cross-Rack-katastrofegjenopprettingsløsning. Begge nodene fungerer helt synkront. Fra vertssiden ser H710 ut som et vanlig lagringssystem med to kontroller. Derfor er det ikke nødvendig å utføre noen ekstra programvare- eller maskinvarealternativer eller spesielt komplekse innstillinger.
Hvis vi sammenligner alle Cross-Rack-katastrofegjenopprettingsløsningene beskrevet ovenfor, skiller alternativet fra AccelStor seg merkbart ut fra resten:
AccelStor NeoSapphire™ delte ingenting-arkitektur
Programvare eller maskinvare "virtualizer" lagringssystem
Replikeringsbasert løsning
tilgjengelighet
Serverfeil
Ingen driftsstans
Ingen driftsstans
Ingen driftsstans
Bryterfeil
Ingen driftsstans
Ingen driftsstans
Ingen driftsstans
Feil i lagringssystem
Ingen driftsstans
Ingen driftsstans
Nedetid
Hele skapsvikt
Ingen driftsstans
Ingen driftsstans
Nedetid
Kostnad og kompleksitet
Løsningskostnad
Lav*
Høy
Høy
Implementeringskompleksitet
lav
Høy
Høy
*AccelStor NeoSapphire™ er fortsatt en All Flash-array, som per definisjon ikke koster "3 kopek", spesielt siden den har en dobbel kapasitetsreserve. Men når man sammenligner den endelige kostnaden for en løsning basert på den med lignende fra andre leverandører, kan kostnaden anses som lav.
Topologien for tilkobling av applikasjonsservere og All Flash-array-noder vil se slik ut:
Når du planlegger topologien, anbefales det også sterkt å duplisere administrasjonssvitsjer og sammenkoble servere.
I det følgende vil vi snakke om tilkobling via Fibre Channel. Hvis du bruker iSCSI, vil alt være det samme, justert for typene brytere som brukes og litt forskjellige array-innstillinger.
Forberedende arbeid med matrisen
Utstyr og programvare brukt
Server- og bryterspesifikasjoner
Komponenter
beskrivelse
Oracle Database 11g servere
To
Server operativsystem
Oracle Linux
Oracle databaseversjon
11 g (RAC)
Prosessorer per server
To 16 kjerner Intel® Xeon® CPU E5-2667 v2 @ 3.30 GHz
Fysisk minne per server
128GB
FC nettverk
16Gb/s FC med multipathing
FC HBA
Emulex Lpe-16002B
Dedikerte offentlige 1GbE-porter for klyngeadministrasjon
Intel Ethernet-adapter RJ45
16 Gb/s FC-bryter
Brokade 6505
Dedikerte private 10GbE-porter for datasynkronisering
Intel X520
AccelStor NeoSapphire™ All Flash Array-spesifikasjon
Komponenter
beskrivelse
Lagringssystem
NeoSapphire™ modell med høy tilgjengelighet: H710
Bildeversjon
4.0.1
Totalt antall stasjoner
48
Stasjonsstørrelse
1.92TB
Kjøretype
SSD
FC-målporter
16 x 16 Gb porter (8 per node)
Administrasjonsporter
1GbE Ethernet-kabel som kobles til verter via en Ethernet-svitsj
Hjerteslagport
1GbE Ethernet-kabel som kobles mellom to lagringsnoder
Datasynkroniseringsport
56Gb/s InfiniBand-kabel
Før du kan bruke en matrise, må du initialisere den. Som standard er kontrolladressen til begge nodene den samme (192.168.1.1). Du må koble til dem én etter én og sette nye (allerede forskjellige) administrasjonsadresser og sette opp tidssynkronisering, hvoretter administrasjonsportene kan kobles til et enkelt nettverk. Etterpå blir nodene kombinert til et HA-par ved å tilordne subnett for Interlink-forbindelser.
Etter at initialiseringen er fullført, kan du administrere matrisen fra hvilken som helst node.
Deretter lager vi de nødvendige volumene og publiserer dem til applikasjonsservere.
Det anbefales sterkt å opprette flere volumer for Oracle ASM, da dette vil øke antall mål for serverne, noe som til slutt vil forbedre den generelle ytelsen (mer om køer i en annen ).
Test konfigurasjon
Lagringsvolumnavn
Volumstørrelse
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
Gjenta01
100GB
Gjenta02
100GB
Gjenta03
100GB
Gjenta04
100GB
Gjenta05
100GB
Gjenta06
100GB
Gjenta07
100GB
Gjenta08
100GB
Gjenta09
100GB
Gjenta10
100GB
Noen forklaringer om driftsmodusene til arrayet og prosessene som skjer i nødssituasjoner
Datasettet til hver node har en "versjonsnummer"-parameter. Etter initialisering er den lik og lik 1. Hvis versjonsnummeret av en eller annen grunn er forskjellig, så synkroniseres data alltid fra den eldre versjonen til den yngre, hvoretter nummeret til den yngre versjonen justeres, dvs. dette betyr at kopiene er identiske. Årsaker til at versjoner kan være forskjellige:
- Planlagt omstart av en av nodene
- En ulykke på en av nodene på grunn av en plutselig stans (strømforsyning, overoppheting osv.).
- Mistet InfiniBand-forbindelse med manglende evne til å synkronisere
- Et krasj på en av nodene på grunn av datakorrupsjon. Her må du opprette en ny HA-gruppe og fullføre synkroniseringen av datasettet.
Uansett, noden som forblir online øker versjonsnummeret med én for å synkronisere datasettet etter at forbindelsen med paret er gjenopprettet.
Hvis forbindelsen over Ethernet-koblingen mistes, bytter Heartbeat midlertidig til InfiniBand og går tilbake innen 10 sekunder når den gjenopprettes.
Sette opp verter
For å sikre feiltoleranse og forbedre ytelsen, må du aktivere MPIO-støtte for arrayet. For å gjøre dette må du legge til linjer i filen /etc/multipath.conf, og deretter starte multipath-tjenesten på nytt
Skjult tekstenheter {
enhet {
leverandør "AStor"
path_grouping_policy "group_by_prio"
banevelger "kølengde 0"
path_checker "tur"
funksjoner "0"
hardware_handler "0"
prio "konst"
failback umiddelbart
fast_io_fail_tmo 5
dev_loss_tmo 60
brukervennlige_navn ja
detect_prio ja
rr_min_io_rq 1
no_path_retry 0
}
}
Deretter, for at ASM skal fungere med MPIO via ASMLib, må du endre filen /etc/sysconfig/oracleasm og deretter kjøre /etc/init.d/oracleasm scandisks
Skjult tekst
# ORACLEASM_SCANORDER: Matchende mønstre for å bestille diskskanning
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Matchende mønstre for å ekskludere disker fra skanning
ORACLEASM_SCANEXCLUDE="sd"
Note
Hvis du ikke ønsker å bruke ASMLib, kan du bruke UDEV-reglene, som er grunnlaget for ASMLib.
Fra og med versjon 12.1.0.2 av Oracle Database, er alternativet tilgjengelig for installasjon som en del av ASMFD-programvaren.
Det er viktig å sikre at diskene som er opprettet for Oracle ASM, er justert med blokkstørrelsen som arrayet fysisk opererer med (4K). Ellers kan det oppstå ytelsesproblemer. Derfor er det nødvendig å lage volumer med de riktige parameterne:
delt /dev/mapper/enhetsnavn mklabel gpt mkpart primær 2048s 100% align-check optimal 1
Distribusjon av databaser på tvers av opprettede volumer for vår testkonfigurasjon
Lagringsvolumnavn
Volumstørrelse
Volum LUN-kartlegging
ASM-volumenhetsdetaljer
Tildelingsenhet Størrelse
Data01
200GB
Tilordne alle lagringsvolumer til lagringssystem alle dataporter
Redundans: Normal
Navn: DGDATA
Formål: Datafiler
4MB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
Grid01
1GB
Redundans: Normal
Navn: DGGRID1
Formål: Rutenett: CRS og stemmegivning
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundans: Normal
Navn: DGGRID2
Formål: Rutenett: CRS og stemmegivning
4MB
Grid05
1GB
Grid06
1GB
Gjenta01
100GB
Redundans: Normal
Navn: DGREDO1
Formål: Gjenta logg av tråd 1
4MB
Gjenta02
100GB
Gjenta03
100GB
Gjenta04
100GB
Gjenta05
100GB
Gjenta06
100GB
Redundans: Normal
Navn: DGREDO2
Formål: Gjenta logg av tråd 2
4MB
Gjenta07
100GB
Gjenta08
100GB
Gjenta09
100GB
Gjenta10
100GB
Databaseinnstillinger
- Blokkstørrelse = 8K
- Bytt plass = 16 GB
- Deaktiver AMM (automatisk minneadministrasjon)
- Deaktiver Transparent Huge Pages
Andre innstillinger
# 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 # ikke still dette hvis du bruker Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ rutenett myk nproc 2047
✓ grid hard nproc 16384
✓ rutenett myk nofile 1024
✓ grid hard nofile 65536
✓ rutenett myk stabel 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
✓ myk memlock 120795954
✓ hard memlock 120795954
sqlplus "/as sysdba"
endre systemsett prosesser=2000 scope=spfile;
endre systemsett open_cursors=2000 scope=spfile;
endre systemsett session_cached_cursors=300 scope=spfile;
endre systemsett db_files=8192 scope=spfile;
Feiltest
For demonstrasjonsformål ble HammerDB brukt til å emulere en OLTP-belastning. HammerDB-konfigurasjon:
Antall varehus
256
Totale transaksjoner per bruker
1000000000000
Virtuelle brukere
256
Resultatet ble en 2.1M TPM, som er langt fra arrayets ytelsesgrense , men er et "tak" for gjeldende maskinvarekonfigurasjon av servere (primært på grunn av prosessorer) og deres nummer. Hensikten med denne testen er fortsatt å demonstrere feiltoleransen til løsningen som helhet, og ikke å oppnå maksimal ytelse. Derfor vil vi ganske enkelt bygge videre på denne figuren.
Test for feil på en av nodene
Vertene mistet deler av banene til lagringen, og fortsatte å jobbe gjennom de resterende med den andre noden. Ytelsen falt i noen sekunder på grunn av at banene ble gjenoppbygd, og gikk deretter tilbake til normalen. Det var ingen avbrudd i tjenesten.
Skapfeiltest med alt utstyr
I dette tilfellet falt ytelsen også i noen sekunder på grunn av omstruktureringen av banene, og gikk deretter tilbake til halvparten av den opprinnelige verdien. Resultatet ble halvert fra det opprinnelige på grunn av utelukkelse av én applikasjonsserver fra drift. Det var heller ingen avbrudd i tjenesten.
Hvis det er behov for å implementere en feiltolerant Cross-Rack katastrofegjenopprettingsløsning for Oracle til en rimelig pris og med liten implementerings-/administrasjonsinnsats, samarbeider Oracle RAC og arkitekturen. vil være et av de beste alternativene. I stedet for Oracle RAC kan det være hvilken som helst annen programvare som gir klynging, for eksempel samme DBMS eller virtualiseringssystemer. Prinsippet for å konstruere løsningen vil forbli det samme. Og bunnlinjen er null for RTO og RPO.
Kilde: www.habr.com