Eine beträchtliche Anzahl von Unternehmensanwendungen und Virtualisierungssystemen verfügen über eigene Mechanismen zum Aufbau fehlertoleranter Lösungen. Konkret handelt es sich bei Oracle RAC (Oracle Real Application Cluster) um einen Cluster aus zwei oder mehr Oracle-Datenbankservern, die zusammenarbeiten, um die Last auszugleichen und Fehlertoleranz auf Server-/Anwendungsebene bereitzustellen. Um in diesem Modus arbeiten zu können, benötigen Sie einen gemeinsamen Speicher, bei dem es sich in der Regel um ein Speichersystem handelt.
Wie wir bereits in einem unserer besprochen haben Das Speichersystem selbst weist trotz des Vorhandenseins doppelter Komponenten (einschließlich Controller) immer noch Fehlerquellen auf – hauptsächlich in Form eines einzelnen Datensatzes. Um eine Oracle-Lösung mit erhöhten Zuverlässigkeitsanforderungen aufzubauen, muss daher das Schema „N Server – ein Speichersystem“ kompliziert sein.
Zunächst müssen wir natürlich entscheiden, gegen welche Risiken wir uns versichern wollen. In diesem Artikel gehen wir nicht auf den Schutz vor Bedrohungen wie „Ein Meteorit ist eingetroffen“ ein. Daher wird der Aufbau einer geografisch verteilten Disaster-Recovery-Lösung weiterhin ein Thema für einen der folgenden Artikel sein. Hier betrachten wir die sogenannte Cross-Rack-Disaster-Recovery-Lösung, bei der der Schutz auf der Ebene der Serverschränke erfolgt. Die Schränke selbst können im selben Raum oder in verschiedenen Räumen, meist jedoch im selben Gebäude, aufgestellt werden.
Diese Schränke müssen die gesamte erforderliche Ausrüstung und Software enthalten, die den Betrieb von Oracle-Datenbanken unabhängig vom Status des „Nachbarn“ ermöglicht. Mit anderen Worten: Mit der Disaster-Recovery-Lösung von Cross-Rack eliminieren wir das Ausfallrisiko:
- Oracle-Anwendungsserver
- Speichersysteme
- Schaltsysteme
- Komplettausfall aller Geräte im Schrank:
- Machtverweigerung
- Ausfall des Kühlsystems
- Äußere Faktoren (Mensch, Natur usw.)
Die Duplizierung von Oracle-Servern impliziert das eigentliche Funktionsprinzip von Oracle RAC und wird über eine Anwendung implementiert. Auch die Verdopplung von Vermittlungsanlagen ist kein Problem. Doch bei der Duplizierung des Speichersystems ist nicht alles so einfach.
Die einfachste Option ist die Datenreplikation vom Hauptspeichersystem zum Backup-System. Synchron oder asynchron, abhängig von den Fähigkeiten des Speichersystems. Bei der asynchronen Replikation stellt sich sofort die Frage nach der Sicherstellung der Datenkonsistenz in Bezug auf Oracle. Aber selbst wenn eine Software-Integration mit der Anwendung besteht, ist bei einem Ausfall des Hauptspeichersystems in jedem Fall ein manueller Eingriff durch Administratoren erforderlich, um den Cluster auf Backup-Speicher umzustellen.
Eine komplexere Option sind Software- und/oder Hardware-Speichervirtualisierungen, die Konsistenzprobleme und manuelle Eingriffe beseitigen. Doch die Komplexität der Bereitstellung und anschließenden Verwaltung sowie die sehr unangemessenen Kosten solcher Lösungen schrecken viele ab.
Die AccelStor NeoSapphire™ All-Flash-Array-Lösung eignet sich perfekt für Szenarien wie die Rack-übergreifende Notfallwiederherstellung unter Verwendung der Shared-Nothing-Architektur. Bei diesem Modell handelt es sich um ein Speichersystem mit zwei Knoten, das die proprietäre FlexiRemap®-Technologie verwendet, um mit Flash-Laufwerken zu arbeiten. Dank an NeoSapphire™ H710 ist in der Lage, eine Leistung von bis zu 600 IOPS bei 4K zufälligem Schreiben und 1M+ IOPS bei 4K zufälligem Lesen zu liefern, was bei Verwendung klassischer RAID-basierter Speichersysteme unerreichbar ist.
Das Hauptmerkmal von NeoSapphire™ H710 ist jedoch die Ausführung von zwei Knoten in Form separater Gehäuse, von denen jeder über eine eigene Kopie der Daten verfügt. Die Synchronisierung der Knoten erfolgt über die externe InfiniBand-Schnittstelle. Dank dieser Architektur ist es möglich, Knoten auf verschiedene Standorte in einer Entfernung von bis zu 100 m zu verteilen und so eine Rack-übergreifende Disaster-Recovery-Lösung bereitzustellen. Beide Knoten arbeiten vollständig synchron. Von der Host-Seite aus sieht der H710 wie ein gewöhnliches Dual-Controller-Speichersystem aus. Es sind daher keine zusätzlichen Software- oder Hardwareoptionen oder besonders aufwändige Einstellungen erforderlich.
Wenn wir alle oben beschriebenen Cross-Rack-Disaster-Recovery-Lösungen vergleichen, dann sticht die Option von AccelStor deutlich hervor:
AccelStor NeoSapphire™ Shared Nothing-Architektur
Software- oder Hardware-„Virtualisierer“-Speichersystem
Replikationsbasierte Lösung
Verfügbarkeit
Serverausfall
Keine Ausfallzeiten
Keine Ausfallzeiten
Keine Ausfallzeiten
Schalterfehler
Keine Ausfallzeiten
Keine Ausfallzeiten
Keine Ausfallzeiten
Ausfall des Speichersystems
Keine Ausfallzeiten
Keine Ausfallzeiten
Ausfallzeit
Kompletter Schrankausfall
Keine Ausfallzeiten
Keine Ausfallzeiten
Ausfallzeit
Kosten und Komplexität
Lösungskosten
Niedrig*
Hoch
Hoch
Komplexität der Bereitstellung
niedrig
Hoch
Hoch
*AccelStor NeoSapphire™ ist immer noch ein All-Flash-Array, das per Definition keine „3 Kopeken“ kostet, zumal es über eine doppelte Kapazitätsreserve verfügt. Wenn man jedoch die Endkosten einer darauf basierenden Lösung mit ähnlichen Lösungen anderer Anbieter vergleicht, können die Kosten als niedrig angesehen werden.
Die Topologie zum Verbinden von Anwendungsservern und All-Flash-Array-Knoten sieht folgendermaßen aus:
Bei der Planung der Topologie wird außerdem dringend empfohlen, Management-Switches zu duplizieren und Server miteinander zu verbinden.
Hier und weiter werden wir über die Verbindung über Fibre Channel sprechen. Wenn Sie iSCSI verwenden, ist alles gleich, angepasst an die verwendeten Switch-Typen und leicht unterschiedliche Array-Einstellungen.
Vorbereitende Arbeiten am Array
Verwendete Ausrüstung und Software
Server- und Switch-Spezifikationen
Komponenten
Beschreibung
Oracle Database 11g-Server
Zwei
Server-Betriebssystem
Oracle Linux
Oracle-Datenbankversion
11g (RAC)
Prozessoren pro Server
Zwei 16-Kerne Intel® Xeon® CPU E5-2667 v2 bei 3.30 GHz
Physischer Speicher pro Server
128GB
FC-Netzwerk
16 Gbit/s FC mit Multipathing
FC HBA
Emulex Lpe-16002B
Dedizierte öffentliche 1GbE-Ports für die Clusterverwaltung
Intel-Ethernet-Adapter RJ45
16 Gbit/s FC-Switch
Brokat 6505
Dedizierte private 10-GbE-Ports für die Datensynchronisierung
Intel X520
AccelStor NeoSapphire™ All-Flash-Array-Spezifikation
Komponenten
Beschreibung
Speichersystem
NeoSapphire™ Hochverfügbarkeitsmodell: H710
Bildversion
4.0.1
Gesamtzahl der Laufwerke
48
Laufwerksgröße
1.92TB
Laufwerkstyp
SSD
FC-Zielports
16x 16-Gbit-Ports (8 pro Knoten)
Management-Ports
Das 1-GbE-Ethernet-Kabel verbindet sich über einen Ethernet-Switch mit Hosts
Heartbeat-Port
Das 1GbE-Ethernet-Kabel verbindet zwei Speicherknoten
Datensynchronisierungsport
56 Gbit/s InfiniBand-Kabel
Bevor Sie ein Array verwenden können, müssen Sie es initialisieren. Standardmäßig ist die Steueradresse beider Knoten gleich (192.168.1.1). Sie müssen nacheinander eine Verbindung zu ihnen herstellen, neue (bereits unterschiedliche) Verwaltungsadressen festlegen und die Zeitsynchronisierung einrichten. Anschließend können die Verwaltungsports mit einem einzigen Netzwerk verbunden werden. Anschließend werden die Knoten zu einem HA-Paar zusammengefasst, indem Subnetze für Interlink-Verbindungen zugewiesen werden.
Nach Abschluss der Initialisierung können Sie das Array von jedem Knoten aus verwalten.
Als nächstes erstellen wir die erforderlichen Volumes und veröffentlichen sie auf Anwendungsservern.
Es wird dringend empfohlen, mehrere Volumes für Oracle ASM zu erstellen, da dadurch die Anzahl der Ziele für die Server erhöht wird, was letztendlich die Gesamtleistung verbessert (mehr zu Warteschlangen in einem anderen Artikel). ).
Konfiguration testen
Name des Speicher-Volumes
Volumengröße
Daten01
200GB
Daten02
200GB
Daten03
200GB
Daten04
200GB
Daten05
200GB
Daten06
200GB
Daten07
200GB
Daten08
200GB
Daten09
200GB
Daten10
200GB
Grid01
1GB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Grid05
1GB
Grid06
1GB
Redo01
100GB
Redo02
100GB
Redo03
100GB
Redo04
100GB
Redo05
100GB
Redo06
100GB
Redo07
100GB
Redo08
100GB
Redo09
100GB
Redo10
100GB
Einige Erläuterungen zu den Betriebsarten des Arrays und den in Notfallsituationen ablaufenden Abläufen
Der Datensatz jedes Knotens verfügt über einen Parameter „Versionsnummer“. Nach der Erstinitialisierung ist sie gleich und gleich 1. Wenn aus irgendeinem Grund die Versionsnummer unterschiedlich ist, werden die Daten immer von der älteren Version mit der jüngeren synchronisiert, wonach die Nummer der jüngeren Version angeglichen wird, d. h. das bedeutet, dass die Kopien identisch sind. Gründe, warum Versionen unterschiedlich sein können:
- Geplanter Neustart eines der Knoten
- Ein Unfall an einem der Knoten aufgrund einer plötzlichen Abschaltung (Stromversorgung, Überhitzung usw.).
- InfiniBand-Verbindung unterbrochen und Synchronisierung nicht möglich
- Ein Absturz auf einem der Knoten aufgrund von Datenbeschädigung. Hier müssen Sie eine neue HA-Gruppe erstellen und die Synchronisierung des Datensatzes abschließen.
In jedem Fall erhöht der Knoten, der online bleibt, seine Versionsnummer um eins, um seinen Datensatz zu synchronisieren, nachdem die Verbindung mit dem Paar wiederhergestellt ist.
Wenn die Verbindung über die Ethernet-Verbindung unterbrochen wird, wechselt Heartbeat vorübergehend zu InfiniBand und kehrt nach der Wiederherstellung innerhalb von 10 Sekunden zurück.
Hosts einrichten
Um Fehlertoleranz sicherzustellen und die Leistung zu verbessern, müssen Sie die MPIO-Unterstützung für das Array aktivieren. Dazu müssen Sie Zeilen zur Datei /etc/multipath.conf hinzufügen und dann den Multipath-Dienst neu starten
Versteckter TextGeräte {
Gerät {
Anbieter „AStor“
path_grouping_policy „group_by_prio“
path_selector „Warteschlangenlänge 0“
path_checker „tur“
Merkmale „0“
hardware_handler „0“
Priorität „const“
sofortiges Failback
fast_io_fail_tmo 5
dev_loss_tmo 60
user_freundliche_namen ja
discover_prio ja
rr_min_io_rq 1
no_path_retry 0
}
}
Damit ASM mit MPIO über ASMLib funktioniert, müssen Sie als Nächstes die Datei /etc/sysconfig/oracleasm ändern und dann /etc/init.d/oracleasm scandisks ausführen
Versteckter Text
# ORACLEASM_SCANORDER: Übereinstimmende Muster zur Reihenfolge des Festplattenscans
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Übereinstimmende Muster, um Festplatten vom Scan auszuschließen
ORACLEASM_SCANEXCLUDE="sd"
Beachten
Wenn Sie ASMLib nicht verwenden möchten, können Sie die UDEV-Regeln verwenden, die die Grundlage für ASMLib bilden.
Ab Version 12.1.0.2 der Oracle-Datenbank steht die Option zur Installation als Teil der ASMFD-Software zur Verfügung.
Es muss unbedingt sichergestellt werden, dass die für Oracle ASM erstellten Festplatten auf die Blockgröße abgestimmt sind, mit der das Array physisch arbeitet (4 KB). Andernfalls kann es zu Leistungsproblemen kommen. Daher ist es notwendig, Volumes mit den entsprechenden Parametern zu erstellen:
parted /dev/mapper/device-name mklabel gpt mkpart Primary 2048s 100 % Align-Check optimal 1
Verteilung der Datenbanken auf erstellte Volumes für unsere Testkonfiguration
Name des Speicher-Volumes
Volumengröße
Zuordnung von Volume-LUNs
Details zum ASM-Volume-Gerät
Größe der Zuordnungseinheiten
Daten01
200GB
Ordnen Sie alle Speichervolumes dem Speichersystem und allen Datenports zu
Redundanz: Normal
Name:DGDATA
Zweck: Datendateien
4MB
Daten02
200GB
Daten03
200GB
Daten04
200GB
Daten05
200GB
Daten06
200GB
Daten07
200GB
Daten08
200GB
Daten09
200GB
Daten10
200GB
Grid01
1GB
Redundanz: Normal
Name: DGGRID1
Zweck: Raster: CRS und Abstimmung
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundanz: Normal
Name: DGGRID2
Zweck: Raster: CRS und Abstimmung
4MB
Grid05
1GB
Grid06
1GB
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-Speicherplatz = 16 GB
- AMM (Automatische Speicherverwaltung) deaktivieren
- Deaktivieren Sie transparente große Seiten
Andere 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 # Legen Sie dies nicht fest, wenn Sie Linux x86 verwenden
✓ vm.vfs_cache_pression=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ Grid Soft Nproc 2047
✓ Grid Hard Nproc 16384
✓ Grid Soft Nofile 1024
✓ Gitterhartnofile 65536
✓ Gitter-Softstack 10240
✓ Gitter-Hardstack 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
✓ Hart-Memlock 120795954
sqlplus „/as sysdba“
Alter System Set Processes=2000 Scope=SPFile;
alter system set open_cursors=2000scope=spfile;
alter system set session_cached_cursors=300scope=spfile;
alter system set db_files=8192scope=spfile;
Fehlertest
Zu Demonstrationszwecken wurde HammerDB verwendet, um eine OLTP-Last zu emulieren. HammerDB-Konfiguration:
Anzahl der Lager
256
Gesamttransaktionen pro Benutzer
1000000000000
Virtuelle Benutzer
256
Das Ergebnis war ein TPM von 2.1 Mio., was weit von der Leistungsgrenze des Arrays entfernt ist , stellt aber eine „Obergrenze“ für die aktuelle Hardwarekonfiguration von Servern (hauptsächlich aufgrund von Prozessoren) und deren Anzahl dar. Der Zweck dieses Tests besteht weiterhin darin, die Fehlertoleranz der Lösung als Ganzes zu demonstrieren und nicht darin, maximale Leistung zu erzielen. Daher bauen wir einfach auf dieser Zahl auf.
Testen Sie, ob einer der Knoten ausgefallen ist
Die Hosts verloren einen Teil der Pfade zum Speicher und arbeiteten die verbleibenden Pfade weiterhin mit dem zweiten Knoten ab. Aufgrund der Neuerstellung der Pfade sank die Leistung für einige Sekunden und normalisierte sich dann wieder. Es kam zu keiner Betriebsunterbrechung.
Schrankausfalltest mit allen Geräten
Auch in diesem Fall sank die Leistung aufgrund der Umstrukturierung der Pfade für einige Sekunden und fiel dann wieder auf die Hälfte des ursprünglichen Wertes zurück. Aufgrund des Ausschlusses eines Anwendungsservers vom Betrieb halbierte sich das Ergebnis gegenüber dem ursprünglichen Ergebnis. Es gab auch keine Unterbrechung im Dienst.
Wenn Bedarf besteht, eine fehlertolerante Cross-Rack-Disaster-Recovery-Lösung für Oracle zu angemessenen Kosten und mit geringem Bereitstellungs-/Verwaltungsaufwand zu implementieren, dann arbeiten Oracle RAC und Architektur zusammen wird eine der besten Optionen sein. Anstelle von Oracle RAC kann es jede andere Software geben, die Clustering bereitstellt, beispielsweise dasselbe DBMS oder Virtualisierungssysteme. Das Prinzip der Konstruktion der Lösung bleibt gleich. Und das Endergebnis ist Null für RTO und RPO.
Source: habr.com