Ett stort antal Enterprise-applikationer och virtualiseringssystem har sina egna mekanismer för att bygga feltoleranta lösningar. Specifikt är Oracle RAC (Oracle Real Application Cluster) ett kluster av två eller flera Oracle-databasservrar som arbetar tillsammans för att balansera belastningen och ge feltolerans på server-/applikationsnivå. För att arbeta i det här läget behöver du en delad lagring, vilket vanligtvis är ett lagringssystem.
Som vi redan har diskuterat i en av våra , har själva lagringssystemet, trots närvaron av duplicerade komponenter (inklusive styrenheter), fortfarande felpunkter - främst i form av en enda uppsättning data. Därför, för att bygga en Oracle-lösning med ökade krav på tillförlitlighet, måste systemet "N servrar - ett lagringssystem" vara komplicerat.
Först måste vi förstås ta ställning till vilka risker vi försöker försäkra oss mot. I den här artikeln kommer vi inte att överväga skydd mot hot som "en meteorit har anlänt." Så att bygga en geografiskt spridd katastrofåterställningslösning kommer att förbli ett ämne för en av följande artiklar. Här ska vi titta på den så kallade Cross-Rack disaster recovery-lösningen, när skydd byggs på nivå med serverskåp. Själva skåpen kan placeras i samma rum eller i olika, men oftast inom samma byggnad.
Dessa skåp måste innehålla hela den nödvändiga uppsättningen av utrustning och programvara som tillåter driften av Oracle-databaser oavsett tillståndet för "grann". Med andra ord, genom att använda Cross-Rack-lösningen för katastrofåterställning eliminerar vi riskerna för fel:
- Oracle Application Servers
- Lagringssystem
- Växla system
- Fullständigt fel på all utrustning i skåpet:
- Kraftvägran
- Kylsystemfel
- Yttre faktorer (människa, natur, etc.)
Duplicering av Oracle-servrar innebär själva operativa principen för Oracle RAC och implementeras genom en applikation. Duplicering av växlingsanläggningar är inte heller ett problem. Men med duplicering av lagringssystemet är allt inte så enkelt.
Det enklaste alternativet är datareplikering från huvudlagringssystemet till backupsystemet. Synkron eller asynkron, beroende på lagringssystemets kapacitet. Med asynkron replikering uppstår omedelbart frågan om att säkerställa datakonsistens i förhållande till Oracle. Men även om det finns programvaruintegration med applikationen, i alla fall, om det finns ett fel på huvudlagringssystemet, kommer det att krävas manuellt ingripande av administratörer för att byta klustret till backuplagring.
Ett mer komplext alternativ är "virtualiserare" för lagring av mjukvara och/eller hårdvara som eliminerar konsistensproblem och manuella ingrepp. Men komplexiteten i utbyggnaden och den efterföljande administrationen, liksom den mycket oanständiga kostnaden för sådana lösningar, avskräcker många.
AccelStor NeoSapphire™ All Flash-arraylösning är perfekt för scenarier som Cross-Rack katastrofåterställning använder Shared-Nothing-arkitekturen. Denna modell är ett lagringssystem med två noder som använder egenutvecklad FlexiRemap®-teknik för att arbeta med flash-enheter. Tack vare NeoSapphire™ H710 kan leverera prestanda upp till 600K IOPS@4K slumpmässig skrivning och 1M+ IOPS@4K slumpmässig läsning, vilket är ouppnåeligt när man använder klassiska RAID-baserade lagringssystem.
Men huvudfunktionen hos NeoSapphire™ H710 är exekveringen av två noder i form av separata fall, som var och en har sin egen kopia av data. Synkronisering av noder utförs genom det externa InfiniBand-gränssnittet. Tack vare denna arkitektur är det möjligt att distribuera noder till olika platser på ett avstånd av upp till 100m, vilket ger en Cross-Rack-katastrofåterställningslösning. Båda noderna fungerar helt synkront. Från värdsidan ser H710 ut som ett vanligt lagringssystem med dubbla kontroller. Därför finns det inget behov av att utföra ytterligare program- eller hårdvarualternativ eller särskilt komplexa inställningar.
Om vi jämför alla Cross-Rack-katastrofåterställningslösningar som beskrivs ovan, så sticker alternativet från AccelStor ut märkbart från resten:
AccelStor NeoSapphire™ Shared Nothing Architecture
Programvara eller hårdvara "virtualizer" lagringssystem
Replikeringsbaserad lösning
tillgänglighet
Serverfel
Ingen driftstopp
Ingen driftstopp
Ingen driftstopp
Brytarfel
Ingen driftstopp
Ingen driftstopp
Ingen driftstopp
Fel i lagringssystemet
Ingen driftstopp
Ingen driftstopp
Downtime
Helt skåpfel
Ingen driftstopp
Ingen driftstopp
Downtime
Kostnad och komplexitet
Lösningskostnad
Låg*
Hög
Hög
Installationskomplexitet
låg
Hög
Hög
*AccelStor NeoSapphire™ är fortfarande en All Flash-array, som per definition inte kostar "3 kopek", särskilt eftersom den har en dubbel kapacitetsreserv. Men när man jämför den slutliga kostnaden för en lösning baserad på den med liknande från andra leverantörer, kan kostnaden anses vara låg.
Topologin för att ansluta applikationsservrar och Alla Flash-arraynoder kommer att se ut så här:
När du planerar topologin rekommenderas det också starkt att duplicera hanteringsväxlar och sammankoppla servrar.
Här och vidare kommer vi att prata om att ansluta via Fibre Channel. Om du använder iSCSI kommer allt att vara detsamma, justerat för de typer av switchar som används och lite olika arrayinställningar.
Förberedande arbete på arrayen
Utrustning och programvara som används
Server- och switchspecifikationer
Komponenter
beskrivning
Oracle Database 11g-servrar
Två
Serveroperativsystem
Oracle Linux
Oracles databasversion
11 g (RAC)
Processorer per server
Två 16 kärnor Intel® Xeon® CPU E5-2667 v2 @ 3.30 GHz
Fysiskt minne per server
128GB
FC nätverk
16Gb/s FC med multipathing
FC HBA
Emulex Lpe-16002B
Dedikerade publika 1GbE-portar för klusterhantering
Intel Ethernet-adapter RJ45
16Gb/s FC-switch
Brokad 6505
Dedikerade privata 10GbE-portar för datasynkronisering
Intel X520
AccelStor NeoSapphire™ All Flash Array Specifikation
Komponenter
beskrivning
Förvaringssystem
NeoSapphire™ modell med hög tillgänglighet: H710
Bildversion
4.0.1
Totalt antal enheter
48
Drive storlek
1.92TB
Typ av enhet
SSD
FC målportar
16x 16Gb-portar (8 per nod)
Hanteringsportar
1GbE Ethernet-kabeln ansluter till värdar via en Ethernet-switch
Hjärtslagsport
1GbE Ethernet-kabel som ansluter mellan två lagringsnoder
Datasynkroniseringsport
56Gb/s InfiniBand-kabel
Innan du kan använda en array måste du initialisera den. Som standard är kontrolladressen för båda noderna densamma (192.168.1.1). Du behöver ansluta till dem en efter en och ställa in nya (redan olika) hanteringsadresser och ställa in tidssynkronisering, varefter Management-portarna kan anslutas till ett enda nätverk. Efteråt kombineras noderna till ett HA-par genom att tilldela subnät för interlink-anslutningar.
När initieringen är klar kan du hantera arrayen från vilken nod som helst.
Därefter skapar vi nödvändiga volymer och publicerar dem på applikationsservrar.
Det rekommenderas starkt att skapa flera volymer för Oracle ASM eftersom detta kommer att öka antalet mål för servrarna, vilket i slutändan kommer att förbättra den övergripande prestandan (mer om köer i en annan ).
Testa konfiguration
Lagringsvolymens namn
Volymstorlek
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
Gör om01
100GB
Gör om02
100GB
Gör om03
100GB
Gör om04
100GB
Gör om05
100GB
Gör om06
100GB
Gör om07
100GB
Gör om08
100GB
Gör om09
100GB
Gör om10
100GB
Några förklaringar om arrayens driftlägen och de processer som sker i nödsituationer
Datauppsättningen för varje nod har en "versionsnummer"-parameter. Efter initial initiering är det samma och lika med 1. Om versionsnumret av någon anledning är annorlunda, så synkroniseras alltid data från den äldre versionen till den yngre, varefter numret på den yngre versionen justeras, d.v.s. det betyder att kopiorna är identiska. Orsaker till att versioner kan vara olika:
- Schemalagd omstart av en av noderna
- En olycka på en av noderna på grund av en plötslig avstängning (strömförsörjning, överhettning etc.).
- Förlorad InfiniBand-anslutning med oförmåga att synkronisera
- En krasch på en av noderna på grund av datakorruption. Här måste du skapa en ny HA-grupp och slutföra synkroniseringen av datamängden.
I vilket fall som helst ökar noden som förblir online sitt versionsnummer med ett för att synkronisera sin datamängd efter att anslutningen med paret har återställts.
Om anslutningen över Ethernet-länken bryts, växlar Heartbeat tillfälligt till InfiniBand och återgår inom 10 sekunder när det återställs.
Konfigurera värdar
För att säkerställa feltolerans och förbättra prestanda måste du aktivera MPIO-stöd för arrayen. För att göra detta måste du lägga till rader i filen /etc/multipath.conf och sedan starta om flervägstjänsten
Dold textenheter {
enhet {
leverantör "AStor"
path_grouping_policy "group_by_prio"
path_selector "kölängd 0"
path_checker "tur"
har "0"
hardware_handler "0"
prio "konst"
failback omedelbart
fast_io_fail_tmo 5
dev_loss_tmo 60
användarvänliga_namn ja
detect_prio ja
rr_min_io_rq 1
no_path_retry 0
}
}
Därefter, för att ASM ska fungera med MPIO via ASMLib, måste du ändra filen /etc/sysconfig/oracleasm och sedan köra /etc/init.d/oracleasm scandisks
Dold text
# ORACLEASM_SCANORDER: Matchande mönster för att beställa diskskanning
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Matchande mönster för att utesluta diskar från genomsökning
ORACLEASM_SCANEXCLUDE="sd"
Notera
Om du inte vill använda ASMLib kan du använda UDEV-reglerna, som är grunden för ASMLib.
Från och med version 12.1.0.2 av Oracle Database är alternativet tillgängligt för installation som en del av ASMFD-programvaran.
Det är absolut nödvändigt att se till att diskarna som skapats för Oracle ASM är anpassade till den blockstorlek som arrayen fysiskt arbetar med (4K). Annars kan prestandaproblem uppstå. Därför är det nödvändigt att skapa volymer med lämpliga parametrar:
delades /dev/mapper/enhetsnamn mklabel gpt mkpart primär 2048s 100% align-check optimal 1
Distribution av databaser över skapade volymer för vår testkonfiguration
Lagringsvolymens namn
Volymstorlek
Volym LUN-mappning
ASM-volymenhetsdetalj
Tilldelningsenhetsstorlek
Data01
200GB
Mappa alla lagringsvolymer till lagringssystem alla dataportar
Redundans: Normal
Namn: DGDATA
Syfte: Datafiler
4MB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
Grid01
1GB
Redundans: Normal
Namn: DGGRID1
Syfte: Rutnät: CRS och röstning
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundans: Normal
Namn: DGGRID2
Syfte: Rutnät: CRS och röstning
4MB
Grid05
1GB
Grid06
1GB
Gör om01
100GB
Redundans: Normal
Namn: DGREDO1
Syfte: Gör om logg för tråd 1
4MB
Gör om02
100GB
Gör om03
100GB
Gör om04
100GB
Gör om05
100GB
Gör om06
100GB
Redundans: Normal
Namn: DGREDO2
Syfte: Gör om logg för tråd 2
4MB
Gör om07
100GB
Gör om08
100GB
Gör om09
100GB
Gör om10
100GB
Databasinställningar
- Blockstorlek = 8K
- Byt utrymme = 16GB
- Inaktivera AMM (automatisk minneshantering)
- Inaktivera Transparent Huge Pages
Andra inställningar
# 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.byte=10
✓ vm.min_free_kbytes=524288 # ställ inte in detta om du använder Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ rutnät mjuk nproc 2047
✓ rutnät hård nproc 16384
✓ rutnät mjuk nofile 1024
✓ rutnät hård nofile 65536
✓ rutnät mjuk stack 10240
✓ rutnät hård stack 32768
✓ oracle soft nproc 2047
✓ oracle hard nproc 16384
✓ oracle soft nofile 1024
✓ oracle hård nofile 65536
✓ oracle soft stack 10240
✓ oracle hard stack 32768
✓ mjukt memlock 120795954
✓ hård memlock 120795954
sqlplus "/as sysdba"
ändra systemuppsättning processer=2000 scope=spfile;
ändra systemuppsättning open_cursors=2000 scope=spfile;
ändra systemuppsättning session_cached_cursors=300 scope=spfile;
ändra systemuppsättning db_files=8192 scope=spfile;
Misslyckande test
För demonstrationsändamål användes HammerDB för att emulera en OLTP-belastning. HammerDB-konfiguration:
Antal lager
256
Totala transaktioner per användare
1000000000000
Virtuella användare
256
Resultatet blev en 2.1 miljoner TPM, vilket är långt ifrån arrayens prestandagräns , men är ett "tak" för den nuvarande hårdvarukonfigurationen av servrar (främst på grund av processorer) och deras antal. Syftet med detta test är fortfarande att demonstrera feltoleransen för lösningen som helhet, och inte att uppnå maximal prestanda. Därför kommer vi helt enkelt att bygga på denna siffra.
Testa för fel på en av noderna
Värdarna förlorade en del av vägarna till lagringen och fortsatte att arbeta genom de återstående med den andra noden. Prestandan sjönk under några sekunder på grund av att banorna byggdes om och återgick sedan till det normala. Det var inget avbrott i tjänsten.
Skåpsfelstest med all utrustning
I det här fallet sjönk också prestandan under några sekunder på grund av omstruktureringen av banorna och återgick sedan till hälften av det ursprungliga värdet. Resultatet halverades från den ursprungliga på grund av uteslutningen av en applikationsserver från drift. Det var heller inget avbrott i tjänsten.
Om det finns ett behov av att implementera en feltolerant Cross-Rack-katastrofåterställningslösning för Oracle till en rimlig kostnad och med liten implementerings-/administrationsansträngning, så samarbetar Oracle RAC och arkitekturen kommer att vara ett av de bästa alternativen. Istället för Oracle RAC kan det finnas vilken annan programvara som helst som tillhandahåller klustring, till exempel samma DBMS eller virtualiseringssystem. Principen för att konstruera lösningen kommer att förbli densamma. Och slutsatsen är noll för RTO och RPO.
Källa: will.com