Een aanzienlijk aantal bedrijfsapplicaties en virtualisatiesystemen hebben hun eigen mechanismen voor het bouwen van fouttolerante oplossingen. Concreet is Oracle RAC (Oracle Real Application Cluster) een cluster van twee of meer Oracle-databaseservers die samenwerken om de belasting te verdelen en fouttolerantie op server-/applicatieniveau te bieden. Om in deze modus te werken, heb je een gedeelde opslag nodig, meestal een opslagsysteem.
Zoals we al hebben besproken in een van onze , heeft het opslagsysteem zelf, ondanks de aanwezigheid van dubbele componenten (inclusief controllers), nog steeds faalpunten - voornamelijk in de vorm van een enkele set gegevens. Om een Oracle-oplossing te bouwen met hogere betrouwbaarheidseisen moet het ‘N-servers – één opslagsysteem’-schema ingewikkeld zijn.
Eerst moeten we natuurlijk beslissen tegen welke risico's we ons proberen te verzekeren. In dit artikel gaan we niet in op bescherming tegen bedreigingen als ‘er is een meteoriet gearriveerd’. Het bouwen van een geografisch verspreide oplossing voor noodherstel zal dus een onderwerp blijven voor een van de volgende artikelen. Hier zullen we kijken naar de zogenaamde Cross-Rack disaster recovery-oplossing, waarbij bescherming wordt gebouwd op het niveau van serverkasten. De kasten zelf kunnen zich in dezelfde kamer of in verschillende kamers bevinden, maar meestal in hetzelfde gebouw.
Deze kasten moeten de volledige noodzakelijke set apparatuur en software bevatten die de werking van Oracle-databases mogelijk maakt, ongeacht de staat van de “buurman”. Met andere woorden: met behulp van de Cross-Rack disaster recovery-oplossing elimineren we de risico's op storingen:
- Oracle-applicatieservers
- Opslagsystemen
- Schakelsystemen
- Volledige uitval van alle apparatuur in de kast:
- Weigering van macht
- Storing in het koelsysteem
- Externe factoren (mens, natuur, etc.)
Duplicatie van Oracle-servers impliceert het werkingsprincipe van Oracle RAC en wordt geïmplementeerd via een applicatie. Ook duplicatie van schakelvoorzieningen is geen probleem. Maar met duplicatie van het opslagsysteem is alles niet zo eenvoudig.
De eenvoudigste optie is gegevensreplicatie van het hoofdopslagsysteem naar het back-upsysteem. Synchronisch of asynchroon, afhankelijk van de mogelijkheden van het opslagsysteem. Bij asynchrone replicatie rijst meteen de vraag hoe de dataconsistentie in relatie tot Oracle gewaarborgd moet worden. Maar zelfs als er sprake is van software-integratie met de applicatie, zal in ieder geval bij een storing op het hoofdopslagsysteem handmatig ingrijpen door beheerders nodig zijn om het cluster over te zetten naar back-upopslag.
Een complexere optie zijn software- en/of hardwareopslag-virtualizers die consistentieproblemen en handmatige tussenkomst elimineren. Maar de complexiteit van de implementatie en het daaropvolgende beheer, evenals de zeer onfatsoenlijke kosten van dergelijke oplossingen, schrikken velen af.
De AccelStor NeoSapphire™ All Flash array-oplossing is perfect voor scenario's zoals noodherstel via meerdere racks met behulp van de Shared-Nothing-architectuur. Dit model is een opslagsysteem met twee knooppunten dat gebruikmaakt van de eigen FlexiRemap®-technologie om met flashdrives te werken. Dankzij NeoSapphire™ H710 kan prestaties leveren tot 600K IOPS@4K willekeurig schrijven en 1M+ IOPS@4K willekeurig lezen, wat onhaalbaar is bij gebruik van klassieke RAID-gebaseerde opslagsystemen.
Maar het belangrijkste kenmerk van NeoSapphire™ H710 is de uitvoering van twee knooppunten in de vorm van afzonderlijke cases, die elk hun eigen kopie van de gegevens hebben. Synchronisatie van knooppunten wordt uitgevoerd via de externe InfiniBand-interface. Dankzij deze architectuur is het mogelijk om knooppunten te distribueren naar verschillende locaties op een afstand van maximaal 100 meter, waardoor een Cross-Rack disaster recovery-oplossing wordt geboden. Beide knooppunten werken volledig synchroon. Van de hostkant ziet de H710 eruit als een gewoon opslagsysteem met twee controllers. Daarom is het niet nodig om extra software- of hardwareopties of bijzonder complexe instellingen uit te voeren.
Als we alle hierboven beschreven Cross-Rack disaster recovery-oplossingen vergelijken, onderscheidt de optie van AccelStor zich merkbaar van de rest:
AccelStor NeoSapphire™ Shared Nothing-architectuur
Software- of hardware “virtualizer” opslagsysteem
Op replicatie gebaseerde oplossing
Beschikbaarheid
Serverstoring
Geen downtime
Geen downtime
Geen downtime
Schakelfout
Geen downtime
Geen downtime
Geen downtime
Storing in het opslagsysteem
Geen downtime
Geen downtime
Uitvaltijd
Het falen van het hele kabinet
Geen downtime
Geen downtime
Uitvaltijd
Kosten en complexiteit
Oplossing kosten
Laag*
Hoog
Hoog
Complexiteit van de implementatie
laag
Hoog
Hoog
*AccelStor NeoSapphire™ is nog steeds een All Flash-array, die per definitie geen “3 kopeken” kost, vooral omdat het een dubbele capaciteitsreserve heeft. Wanneer u echter de uiteindelijke kosten van een daarop gebaseerde oplossing vergelijkt met vergelijkbare oplossingen van andere leveranciers, kunnen de kosten als laag worden beschouwd.
De topologie voor het verbinden van applicatieservers en All Flash array-knooppunten ziet er als volgt uit:
Bij het plannen van de topologie wordt het ook ten zeerste aanbevolen om beheerschakelaars te dupliceren en servers met elkaar te verbinden.
Hier en verder zullen we het hebben over verbinding maken via Fibre Channel. Als u iSCSI gebruikt, zal alles hetzelfde zijn, aangepast aan de gebruikte typen schakelaars en enigszins verschillende array-instellingen.
Voorbereidende werkzaamheden aan de array
Gebruikte apparatuur en software
Server- en switchspecificaties
Onderdelen
beschrijving
Oracle Database 11g-servers
twee
Serverbesturingssysteem
Oracle Linux
Oracle-databaseversie
11g (RAC)
Processoren per server
Twee 16 cores Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz
Fysiek geheugen per server
128GB
FC-netwerk
16Gb/s FC met multipathing
FC HBA
Emulex Lpe-16002B
Speciale openbare 1GbE-poorten voor clusterbeheer
Intel ethernetadapter RJ45
16Gb/s FC-schakelaar
Brokaat 6505
Speciale privé 10GbE-poorten voor gegevenssynchronisatie
Intel X520
AccelStor NeoSapphire™ All Flash Array-specificatie
Onderdelen
beschrijving
Opslagsysteem
NeoSapphire™-model met hoge beschikbaarheid: H710
Afbeeldingsversie
4.0.1
Totaal aantal schijven
48
Schijfgrootte:
1.92TB
Type aandrijving
SSD
FC-doelpoorten
16x 16Gb-poorten (8 per node)
Beheerpoorten
De 1GbE-ethernetkabel die via een ethernet-switch op hosts wordt aangesloten
Heartbeat-poort
De 1GbE ethernetkabel die verbinding maakt tussen twee opslagknooppunten
Gegevenssynchronisatiepoort
56Gb/s InfiniBand-kabel
Voordat u een array kunt gebruiken, moet u deze initialiseren. Standaard is het besturingsadres van beide knooppunten hetzelfde (192.168.1.1). U dient er één voor één verbinding mee te maken en nieuwe (al verschillende) beheeradressen in te stellen en tijdsynchronisatie in te stellen, waarna de Management-poorten op één netwerk kunnen worden aangesloten. Daarna worden de knooppunten gecombineerd tot een HA-paar door subnetten toe te wijzen voor Interlink-verbindingen.
Nadat de initialisatie is voltooid, kunt u de array vanaf elk knooppunt beheren.
Vervolgens creëren we de benodigde volumes en publiceren deze naar applicatieservers.
Het wordt ten zeerste aanbevolen om meerdere volumes voor Oracle ASM te maken, omdat dit het aantal doelen voor de servers zal vergroten, wat uiteindelijk de algehele prestaties zal verbeteren (meer over wachtrijen in een andere versie). ).
Configuratie testen
Naam opslagvolume
Volumegrootte
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
Opnieuw01
100GB
Opnieuw02
100GB
Opnieuw03
100GB
Opnieuw04
100GB
Opnieuw05
100GB
Opnieuw06
100GB
Opnieuw07
100GB
Opnieuw08
100GB
Opnieuw09
100GB
Opnieuw10
100GB
Enige uitleg over de werkingsmodi van de array en de processen die plaatsvinden in noodsituaties
De dataset van elk knooppunt heeft een parameter “versienummer”. Na de initiële initialisatie is het hetzelfde en gelijk aan 1. Als het versienummer om wat voor reden dan ook anders is, worden de gegevens altijd gesynchroniseerd van de oudere versie naar de jongere, waarna het nummer van de jongere versie wordt uitgelijnd, d.w.z. dit betekent dat de kopieën identiek zijn. Redenen waarom versies kunnen verschillen:
- Geplande herstart van een van de knooppunten
- Een ongeval op een van de knooppunten als gevolg van een plotselinge uitschakeling (stroomvoorziening, oververhitting, enz.).
- Verloren InfiniBand-verbinding met onvermogen om te synchroniseren
- Een crash op een van de knooppunten als gevolg van gegevensbeschadiging. Hier moet u een nieuwe HA-groep aanmaken en de synchronisatie van de dataset voltooien.
In ieder geval verhoogt het knooppunt dat online blijft zijn versienummer met één om zijn dataset te synchroniseren nadat de verbinding met het paar is hersteld.
Als de verbinding via de Ethernet-verbinding verbroken wordt, schakelt Heartbeat tijdelijk over naar InfiniBand en keert binnen 10 seconden terug wanneer deze hersteld is.
Gastheren instellen
Om fouttolerantie te garanderen en de prestaties te verbeteren, moet u MPIO-ondersteuning voor de array inschakelen. Om dit te doen, moet u regels toevoegen aan het bestand /etc/multipath.conf en vervolgens de multipath-service opnieuw starten
Verborgen tekstapparaten {
apparaat {
leverancier "AStor"
path_grouping_policy "group_by_prio"
path_selector "wachtrijlengte 0"
path_checker "tur"
kenmerken "0"
hardware_handler "0"
prio "const"
failback onmiddellijk
fast_io_fail_tmo 5
dev_loss_tmo 60
gebruikersvriendelijke_namen ja
detect_prio ja
rr_min_io_rq 1
no_path_retry 0
}
}
Om ASM via ASMLib met MPIO te laten werken, moet u vervolgens het bestand /etc/sysconfig/oracleasm wijzigen en vervolgens /etc/init.d/oracleasm scandisks uitvoeren
Verborgen tekst
# ORACLEASM_SCANORDER: overeenkomende patronen om schijfscannen te bestellen
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: overeenkomende patronen om schijven uit te sluiten van de scan
ORACLEASM_SCANEXCLUDE="sd"
Noot
Als u ASMLib niet wilt gebruiken, kunt u de UDEV-regels gebruiken, die de basis vormen voor ASMLib.
Vanaf versie 12.1.0.2 van Oracle Database is de optie beschikbaar voor installatie als onderdeel van de ASMFD-software.
Het is absoluut noodzakelijk om ervoor te zorgen dat de schijven die voor Oracle ASM zijn gemaakt, zijn uitgelijnd met de blokgrootte waarmee de array fysiek werkt (4K). Anders kunnen er prestatieproblemen optreden. Daarom is het noodzakelijk om volumes te maken met de juiste parameters:
parted /dev/mapper/device-name mklabel gpt mkpart primair 2048s 100% uitlijning-controle optimaal 1
Verdeling van databases over gemaakte volumes voor onze testconfiguratie
Naam opslagvolume
Volumegrootte
Toewijzing van volume-LUN's
ASM-volumeapparaatdetail
Grootte van toewijzingseenheid
Data01
200GB
Wijs alle opslagvolumes toe aan alle datapoorten van het opslagsysteem
Redundantie: Normaal
Naam:DGDATA
Doel: Gegevensbestanden
4MB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
Grid01
1GB
Redundantie: Normaal
Naam: DGGRID1
Doel: Raster: CRS en stemmen
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundantie: Normaal
Naam: DGGRID2
Doel: Raster: CRS en stemmen
4MB
Grid05
1GB
Grid06
1GB
Opnieuw01
100GB
Redundantie: Normaal
Naam: DGREDO1
Doel: Logboek van thread 1 opnieuw uitvoeren
4MB
Opnieuw02
100GB
Opnieuw03
100GB
Opnieuw04
100GB
Opnieuw05
100GB
Opnieuw06
100GB
Redundantie: Normaal
Naam: DGREDO2
Doel: Logboek van thread 2 opnieuw uitvoeren
4MB
Opnieuw07
100GB
Opnieuw08
100GB
Opnieuw09
100GB
Opnieuw10
100GB
Database-instellingen
- Blokgrootte = 8K
- Wisselruimte = 16 GB
- Schakel AMM uit (automatisch geheugenbeheer)
- Schakel transparante grote pagina's uit
Andere instellingen
# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.bestand-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 # stel dit niet in als u Linux x86 gebruikt
✓ vm.vfs_cache_druk=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ rooster zacht nproc 2047
✓ rooster hard nproc 16384
✓ rooster zacht nofile 1024
✓ rooster hard nofile 65536
✓ rooster softstack 10240
✓ rooster harde stapel 32768
✓ orakel zacht nproc 2047
✓ orakel harde nproc 16384
✓ orakel zacht nofile 1024
✓ orakel hard nofile 65536
✓ orakel softstack 10240
✓ orakel harde stapel 32768
✓ zacht memslot 120795954
✓ harde memlock 120795954
sqlplus “/as sysdba”
wijzig systeemsetprocessen=2000 scope=spfile;
systeemset wijzigen open_cursors=2000 scope=spfile;
wijzig systeemset session_cached_cursors=300 scope=spfile;
wijzig systeemset db_files=8192 scope=spfile;
Mislukkingstest
Voor demonstratiedoeleinden werd HammerDB gebruikt om een OLTP-belasting te emuleren. HammerDB-configuratie:
Aantal Magazijnen
256
Totaal aantal transacties per gebruiker
1000000000000
Virtuele gebruikers
256
Het resultaat was een TPM van 2.1 miljoen, wat ver verwijderd is van de prestatielimiet van de array , maar is een “plafond” voor de huidige hardwareconfiguratie van servers (voornamelijk vanwege processors) en hun aantal. Het doel van deze test is nog steeds om de fouttolerantie van de oplossing als geheel aan te tonen, en niet om maximale prestaties te bereiken. Daarom zullen we eenvoudigweg op dit cijfer voortbouwen.
Test op falen van een van de knooppunten
De hosts verloren een deel van de paden naar de opslag en bleven via de resterende paden werken met het tweede knooppunt. De prestaties daalden een paar seconden doordat de paden opnieuw werden opgebouwd, maar keerden daarna terug naar normaal. Er was geen onderbreking in de dienstverlening.
Kaststoringstest met alle apparatuur
In dit geval daalden de prestaties ook een paar seconden als gevolg van de herstructurering van de paden, en keerden daarna terug naar de helft van de oorspronkelijke waarde. Het resultaat werd gehalveerd ten opzichte van het oorspronkelijke resultaat, omdat één applicatieserver buiten gebruik werd gesteld. Er was ook geen onderbreking in de dienstverlening.
Als het nodig is om een fouttolerante Cross-Rack disaster recovery-oplossing voor Oracle te implementeren tegen redelijke kosten en met weinig implementatie-/beheerinspanningen, dan werken Oracle RAC en architectuur samen zal een van de beste opties zijn. In plaats van Oracle RAC kan er andere software zijn die clustering biedt, bijvoorbeeld dezelfde DBMS- of virtualisatiesystemen. Het principe van het construeren van de oplossing blijft hetzelfde. En de bottom line is nul voor RTO en RPO.
Bron: www.habr.com