Eine Vielzahl von Enterprise-Anwendungen und Virtualisierungssystemen verfügt über eigene Mechanismen zur Erstellung von ausfallsicheren Lösungen. Insbesondere ist Oracle RAC (Oracle Real Application Cluster) ein Cluster aus zwei oder mehr Oracle-Datenbankservern, die zusammenarbeiten, um die Last zu verteilen und die Ausfallsicherheit auf Server- und Anwendungsebene zu gewährleisten. Für den Betrieb in einem solchen Modus ist ein gemeinsamer Speicher erforderlich, der in der Regel von einem SAN bereitgestellt wird.
Wie wir bereits in einem unserer , selbst ein SAN, trotz redundanter Komponenten (einschließlich Controller), hat dennoch Ausfallpunkte – hauptsächlich in Form eines einzigen Datensatzes. Daher muss das Schema 'N Server – ein SAN' für die Erstellung einer Oracle-Lösung mit höheren Anforderungen an die Zuverlässigkeit komplexer gestaltet werden.
Zunächst müssen wir natürlich klären, vor welchen Risiken wir uns schützen möchten. In diesem Artikel werden wir nicht auf Bedrohungen wie "Meteoriteneinschläge" eingehen. Daher bleibt der Aufbau einer geografisch verteilten Lösung für die Notfallwiederherstellung ein Thema für einen der nächsten Artikel. Hier betrachten wir die sogenannte Cross-Rack-Notfallwiederherstellungslösung, bei der der Schutz auf Ebene der Serverschränke erfolgt. Diese Schränke können sich entweder in einem Raum oder verteilt in verschiedenen Räumen befinden, jedoch meist innerhalb eines Gebäudes.
Diese Schränke müssen die gesamte erforderliche Hardware und Software enthalten, die es ermöglicht, Oracle-Datenbanken unabhängig vom Zustand des „Nachbarn“ zu betreiben. Mit anderen Worten, durch die Nutzung einer Cross-Rack-Notfallwiederherstellungslösung minimieren wir die Risiken bei einem Ausfall:
- Oracle-Anwendungsserver
- Speichersysteme
- Verbindungssysteme
- Vollständiger Ausfall aller Geräte im Schrank:
- Stromausfall
- Ausfall der Kühlsysteme
- Externe Faktoren (Menschen, Natur usw.)
Die Duplizierung von Oracle-Servern basiert auf dem Prinzip von Oracle RAC und wird über Anwendungen realisiert. Auch die Duplizierung von Switch-Mitteln stellt in der Regel kein Problem dar. Mit der Duplizierung des Speichersystems wird es jedoch komplizierter.
Die einfachste Lösung besteht darin, Daten von der primären Speicherlösung auf eine Backup-Lösung zu replizieren. Ob synchron oder asynchron, hängt von den Möglichkeiten der Speicherlösungen ab. Bei asynchroner Replikation stellt sich sofort die Frage der Sicherstellung der Datenkonsistenz im Verhältnis zu Oracle. Selbst wenn eine Softwareintegration mit der Anwendung vorhanden ist, ist im Falle eines Ausfalls der primären Speicherlösung dennoch manuelles Eingreifen der Administratoren erforderlich, um den Cluster auf den Backup-Speicher umzustellen.
Eine komplexere Lösung sind software- und/oder hardwarebasierte „Virtualisierer“ von Speicherlösungen, die Probleme mit der Konsistenz und manuellem Eingreifen vermeiden. Doch die Komplexität der Bereitstellung und anschließenden Verwaltung sowie die erhebliche Kosten solcher Lösungen schrecken viele ab.
Für Szenarien wie die Wiederherstellung nach einem Rack-Ausfall ist das All Flash Array AccelStor NeoSapphire™ die ideale Lösung. Es nutzt eine Shared-Nothing-Architektur. Dieses Modell ist ein zweiknotenbasiertes Speichersystem, das die eigene FlexiRemap®-Technologie zur Arbeit mit Flash-Speichern verwendet. Dadurch kann das NeoSapphire™ H710 eine Leistung von bis zu 600K IOPS bei 4K zufälligen Schreibvorgängen und über 1 Million IOPS bei 4K zufälligen Lesevorgängen erreichen, was mit klassischen RAID-basierten Speicherlösungen nicht möglich ist.
Das Hauptmerkmal des NeoSapphire™ H710 ist jedoch, dass die beiden Knoten in separaten Gehäusen untergebracht sind, von denen jedes eine eigene Datenkopie hat. Die Synchronisation der Knoten erfolgt über die externe InfiniBand-Schnittstelle. Diese Architektur ermöglicht es, die Knoten über verschiedene Standorte bis zu 100 m entfernt zu verteilen und somit eine cross-rack disaster recovery Lösung bereitzustellen. Beide Knoten arbeiten vollständig synchron. Aus der Sicht der Hosts erscheint das H710 wie eine gewöhnliche dual-controller Speicherlösung. Daher sind keine zusätzlichen Software- und Hardware-Optionen oder besonders komplexen Einstellungen erforderlich.
Wenn man alle oben beschriebenen Cross-Rack-Disaster-Recovery-Lösungen vergleicht, sticht die Lösung von AccelStor deutlich hervor.
AccelStor NeoSapphire™ Shared Nothing Architektur
Software- oder Hardware-Virtualisierer für Speichersysteme
Lösung basierend auf Replikation
Verfügbarkeit
Serverausfall
Kein Ausfall
Kein Ausfall
Kein Ausfall
Switch-Ausfall
Kein Ausfall
Kein Ausfall
Kein Ausfall
Speichersystemausfall
Kein Ausfall
Kein Ausfall
Ausfallzeiten
Ausfall des gesamten Racks
Kein Ausfall
Kein Ausfall
Ausfallzeiten
Kosten und Komplexität
Kosten der Lösung
Niedrig*
Hoch
Hoch
Komplexität der Bereitstellung
Niedrig
Hoch
Hoch
*AccelStor NeoSapphire™ ist schließlich ein reines Flash-Array, das per Definition nicht „billig“ ist, zumal es über eine doppelte Kapazität verfügt. Vergleicht man jedoch die Gesamtkosten einer Lösung auf seiner Basis mit ähnlichen von anderen Anbietern, kann man die Kosten als niedrig betrachten.
Die Topologie zur Verbindung von Anwendungsservern und Knoten des All-Flash-Arrays sieht wie folgt aus:
Bei der Planung der Topologie wird dringend empfohlen, Redundanzen für die Verwaltungs- und Interconnect-Switches der Server zu erstellen.
Hier und im Folgenden wird von Anschlüssen über Fibre Channel die Rede sein. Bei der Verwendung von iSCSI bleibt alles gleich, mit Ausnahme der verwendeten Switch-Typen und etwas anderer Array-Konfigurationen.
Vorbereitungsarbeiten am Array
Verwendete Hardware und Software
Spezifikationen von Servern und Switches
Komponenten
Beschreibung
Oracle Database 11g-Server
Zwei
Betriebssystem des Servers
Oracle Linux
Version der Oracle-Datenbank
11g (RAC)
Prozessoren pro Server
Zwei 16-Kern Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz
Physischer Speicher pro Server
128GB
FC-Netzwerk
16Gb/s FC mit Multipath
FC HBA
Emulex Lpe-16002B
Dedizierte öffentliche 1GbE-Ports für das Cluster-Management
Intel Ethernet-Adapter RJ45
16Gb/s FC-Switch
Brocade 6505
Dedizierte private 10GbE-Ports für die Datensynchronisation
Intel X520
Spezifikation des AccelStor NeoSapphire™ All-Flash-Arrays
Komponenten
Beschreibung
Speichersystem
NeoSapphire™ Hochverfügbarkeitsmodell: H710
Bildversion
4.0.1
Gesamtanzahl der Laufwerke
48
Laufwerksgröße
1,92TB
Laufwerkstyp
SSD
FC-Zielports
16 x 16Gb-Ports (8 pro Knoten)
Management-Ports
Das 1GbE-Ethernetkabel, das über einen Ethernet-Switch mit Hosts verbunden ist
Heartbeat-Port
Das 1GbE-Ethernetkabel, das zwischen zwei Speicherknoten verbunden ist
Datensynchronisationsport
56Gb/s InfiniBand-Kabel
Vor der Verwendung des Arrays muss es initialisiert werden. Standardmäßig haben die Management-Adressen beider Knoten die gleiche (192.168.1.1). Man muss sich nacheinander mit ihnen verbinden und neue (nun unterschiedliche) Management-Adressen festlegen sowie die Zeit synchronisieren, bevor die Management-Ports in ein gemeinsames Netzwerk angeschlossen werden können. Anschließend erfolgt die Zusammenführung der Knoten zu einem HA-Paar durch die Zuweisung von Subnetzen für die Interlink-Verbindungen.
Nach der Initialisierung kann das Array von jedem Knoten aus verwaltet werden.
Erstellen Sie dann die erforderlichen Volumes und veröffentlichen Sie diese für die Anwendungsserver.
Es wird dringend empfohlen, mehrere Volumes für Oracle ASM zu erstellen, da dies die Anzahl der Target für die Server erhöht, was letztendlich die Gesamtleistung verbessert (weitere Informationen zu Warteschlangen in einem anderen Kontext). ).
Testkonfiguration
Name des Speicherprodukts
Größe des Volumes
Daten01
200GB
Daten02
200GB
Daten03
200GB
Daten04
200GB
Daten05
200GB
Daten06
200GB
Daten07
200GB
Daten08
200GB
Daten09
200GB
Daten10
200GB
Grid01
1 GB
Grid02
1 GB
Grid03
1 GB
Grid04
1 GB
Grid05
1 GB
Grid06
1 GB
Redo01
100GB
Redo02
100GB
Redo03
100GB
Redo04
100GB
Redo05
100GB
Redo06
100GB
Redo07
100GB
Redo08
100GB
Redo09
100GB
Redo10
100GB
Einige Erklärungen zu den Arbeitsmodi des Arrays und den Abläufen in Notfällen.
Jede Datensatzgruppe eines Knotens hat eine "Versionsnummer". Nach der ersten Initialisierung ist sie identisch und beträgt 1. Wenn aus irgendeinem Grund die Versionsnummer unterschiedlich ist, erfolgt immer eine Synchronisierung der Daten von der höheren zur niedrigeren Version, nach der die niedrigere Version angepasst wird, d.h. dies bedeutet, dass die Kopien identisch sind. Gründe, warum die Versionen unterschiedlich sein können:
- Geplante Neustart eines der Knoten
- Ausfall eines der Knoten aufgrund plötzlicher Abschaltungen (Stromausfall, Überhitzung usw.).
- Unterbrechung der InfiniBand-Verbindung mit Unmöglichkeit der Synchronisierung.
- Ein Ausfall an einem der Nodes aufgrund von Datenbeschädigung. Hier ist die Einrichtung einer neuen HA-Gruppe und die vollständige Synchronisierung des Datensatzes erforderlich.
In jedem Fall erhöht der Node, der online bleibt, seine Versionsnummer um eins, um nach der Wiederherstellung der Verbindung mit der Pair seine Datensätze zu synchronisieren.
Wenn es zu einem Verbindungsabbruch über den Ethernet-Link kommt, wechselt Heartbeat vorübergehend zu InfiniBand und kehrt innerhalb von 10 Sekunden nach Wiederherstellung zurück.
Host-Konfiguration
Um Redundanz zu gewährleisten und die Leistung zu steigern, muss die MPIO-Unterstützung für das Array aktiviert werden. Dazu müssen Sie die Zeilen in die Datei /etc/multipath.conf einfügen und den Multipath-Dienst neu starten.
Versteckter Textdevices {
device {
vendor «AStor»
path_grouping_policy «group_by_prio»
path_selector «queue-length 0»
path_checker «tur»
features «0»
hardware_handler «0»
prio «const»
failback immediate
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names yes
detect_prio yes
rr_min_io_rq 1
no_path_retry 0
}
}
Um sicherzustellen, dass ASM mit MPIO über ASMLib funktioniert, muss die Datei /etc/sysconfig/oracleasm geändert werden, gefolgt von /etc/init.d/oracleasm scandisks.
Versteckter Text
# ORACLEASM_SCANORDER: Matching patterns to order disk scanning
ORACLEASM_SCANORDER=«dm»
# ORACLEASM_SCANEXCLUDE: Matching patterns to exclude disks from scan
ORACLEASM_SCANEXCLUDE=«sd»
Hinweis
Wenn Sie ASMLib nicht verwenden möchten, können Sie UDEV-Regeln verwenden, die die Grundlage für ASMLib bilden.
Beginnen mit der Version 12.1.0.2 ist die Oracle-Datenbankoption als Teil der ASMFD-Software verfügbar.
Stellen Sie sicher, dass die für Oracle ASM erstellten Festplatten blockweise auf die physische Array-Größe (4K) ausgerichtet sind. Andernfalls sind Leistungsprobleme möglich. Deshalb müssen Volumes mit den entsprechenden Parameter erstellt werden:
parted /dev/mapper/device-name mklabel gpt mkpart primary 2048s 100% align-check optimal 1
Verteilung der Datenbanken auf die erstellten Volumes für unsere Testkonfiguration
Name des Speicherprodukts
Größe des Volumes
Volume LUNs-Zuordnung
ASM Volume Device Detail
Zuweisungseinheitengröße
Daten01
200GB
Ordnen Sie alle Speicher-Volumes dem Speichersystem und allen Datenports zu.
Redundanz: Normal
Name:DGDATA
Zweck:Daten-Dateien
4MB
Daten02
200GB
Daten03
200GB
Daten04
200GB
Daten05
200GB
Daten06
200GB
Daten07
200GB
Daten08
200GB
Daten09
200GB
Daten10
200GB
Grid01
1 GB
Redundanz: Normal
Name: DGGRID1
Zweck:Grid: CRS und Abstimmung
4MB
Grid02
1 GB
Grid03
1 GB
Grid04
1 GB
Redundanz: Normal
Name: DGGRID2
Zweck:Grid: CRS und Abstimmung
4MB
Grid05
1 GB
Grid06
1 GB
Redo01
100GB
Redundanz: Normal
Name: DGREDO1
Zweck: Redo-Protokoll von Thread 1
4MB
Redo02
100GB
Redo03
100GB
Redo04
100GB
Redo05
100GB
Redo06
100GB
Redundanz: Normal
Name: DGREDO2
Zweck: Redo-Protokoll von Thread 2
4MB
Redo07
100GB
Redo08
100GB
Redo09
100GB
Redo10
100GB
Datenbankeinstellungen
- Blockgröße = 8K
- Swap-Speicher = 16GB
- AMM (Automatische Speicherverwaltung) deaktivieren
- Transparente große Seiten deaktivieren
Sonstige Einstellungen
# 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.swappiness=10
✓ vm.min_free_kbytes=524288 # nicht setzen, wenn Sie Linux x86 verwenden
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ grid soft nproc 2047
✓ grid hard nproc 16384
✓ grid soft nofile 1024
✓ grid hard nofile 65536
✓ grid soft stack 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
✓ soft memlock 120795954
✓ hard memlock 120795954
sqlplus “/as sysdba”
alter system set processes=2000 scope=spfile;
alter system set open_cursors=2000 scope=spfile;
alter system set session_cached_cursors=300 scope=spfile;
alter system set db_files=8192 scope=spfile;
Test auf Ausfallsicherheit
Zur Demonstration wurde HammerDB verwendet, um eine OLTP-Last zu simulieren. HammerDB-Konfiguration:
Anzahl der Lagerhäuser
256
Gesamttransaktionen pro Benutzer
1000000000000
Virtuelle Benutzer
256
Das Ergebnis war eine Rate von 2,1M TPM, was weit entfernt von der Leistungsgrenze des Arrays ist , aber dennoch die „Obergrenze“ für die aktuelle Hardware-Konfiguration der Server darstellt (hauptsächlich aufgrund der Prozessoren) und deren Anzahl. Ziel dieses Tests ist es dennoch, die Ausfallsicherheit der Lösung insgesamt zu demonstrieren und nicht maximale Leistungen zu erreichen. Daher werden wir uns einfach auf diese Zahl stützen.
Test auf Ausfall einer der Knoten
Die Hosts haben einen Teil der Verbindungen zum Speicher verloren, arbeiten jedoch weiterhin über die verbleibenden Verbindungen zur zweiten Node. Die Leistung sank für einige Sekunden aufgrund der Neuausrichtung der Verbindungen und kehrte dann zu normalen Werten zurück. Es gab keine Unterbrechung des Dienstes.
Test der Ausfallsicherheit des Racks mit sämtlicher Hardware
In diesem Fall sank die Leistung ebenfalls für einige Sekunden aufgrund der Neuausrichtung der Verbindungen und kehrte dann auf die Hälfte des ursprünglichen Wertes zurück. Das Ergebnis fiel auf die Hälfte des ursprünglichen Wertes, weil ein Anwendungsserver außer Betrieb war. Auch hier gab es keine Unterbrechung des Dienstes.
Wenn es Anforderungen für die Implementierung einer ausfallsicheren Cross-Rack-Disaster-Recovery-Lösung für Oracle zu angemessenen Kosten und mit geringem Aufwand bei der Bereitstellung/Administration gibt, dann wird die Zusammenarbeit von Oracle RAC und der Architektur eine der besten Optionen sein. Statt Oracle RAC kann jede andere Software verwendet werden, die Clusterbildung unterstützt, wie beispielsweise dieselben DBMS oder Virtualisierungslösungen. Das Prinzip der Lösung bleibt dasselbe. Das Endergebnis ist ein Nullwert für RTO und RPO.
Quelle: habr.com
