Eine beträchtliche Anzahl von Unternehmensanwendungen und Virtualisierungssystemen verfügt über eigene Mechanismen zur Erstellung von ausfallsicheren Lösungen. Insbesondere stellt Oracle RAC (Oracle Real Application Cluster einen Cluster aus zwei oder mehr Oracle-Datenbankservern dar, die gemeinsam arbeiten, um die Last zu verteilen und die Ausfallsicherheit auf Server-/Anwendungsebene zu gewährleisten. Für den Betrieb in einem solchen Modus ist ein gemeinsamer Speicher erforderlich, der in der Regel durch ein Speicher-Array repräsentiert wird.
Wie bereits in einem meiner , ist das Speicher-Array selbst, trotz vorhandener redundanter Komponenten (einschließlich der Controller), dennoch anfällig – vor allem in Form eines einzigen Datensatzes. Daher muss das Konzept „N Server – ein Speicher-Array“ zur Schaffung einer Oracle-Lösung mit höheren Zuverlässigkeitsanforderungen komplizierter gestaltet werden.
Zuerst muss sichergestellt werden, vor welchen Risiken wir uns schützen möchten. In diesem Artikel werden wir nicht auf den Schutz vor Bedrohungen wie „der Meteor ist gefallen“ eingehen. Daher bleibt der Aufbau einer georedundanten Disaster-Recovery-Lösung Thema eines der nächsten Artikel. Hier werden wir das sogenannte Cross-Rack-Disaster-Recovery in Betracht ziehen, bei dem der Schutz auf der Ebene der Server-Schränke aufgebaut wird. Diese Schränke können sich sowohl in einem Raum als auch in verschiedenen Räumen befinden, üblicherweise jedoch innerhalb eines Gebäudes.
Diese Schränke sollten die gesamte erforderliche Ausrüstung und Software enthalten, die es ermöglichen, die Oracle-Datenbanken unabhängig vom Zustand des „Nachbarn“ zu betreiben. Mit anderen Worten: Wenn wir eine Cross-Rack-Disaster-Recovery-Lösung verwenden, schließen wir die Risiken eines Ausfalls aus:
- Oracle-Anwendungsserver
- Speichersysteme
- Vermittlungssysteme
- Vollständiger Ausfall aller Geräte im Schrank:
- Stromausfall
- Ausfall des Kühlsystems
- Äußere Faktoren (Mensch, Natur usw.)
Die Duplizierung der Oracle-Server impliziert das Grundprinzip der Funktionsweise von Oracle RAC und wird durch eine Anwendung realisiert. Auch die Duplizierung der Vermittlungsmittel stellt kein Problem dar. Bei der Duplizierung des Speichersystems sieht es jedoch komplizierter aus.
Die einfachste Variante besteht darin, Daten von der primären Speicherlösung auf die sekundäre zu replizieren. Synchron oder asynchron, je nach den Möglichkeiten der Speicherlösungen. Bei der asynchronen Replikation stellt sich sofort die Frage nach der Sicherstellung der Datenkonsistenz in Bezug auf Oracle. Selbst wenn eine Softwareintegration mit der Anwendung vorhanden ist, ist in jedem Fall, bei einem Ausfall der primären Speicherlösung, das Eingreifen von Administratoren im manuellen Modus erforderlich, um den Cluster auf den sekundären Speicher umzuschalten.
Eine kompliziertere Variante sind software- und/oder hardwaregestützte "Virtualisierer" der Speicherlösungen, die Probleme mit Konsistenz und manuellem Eingreifen beseitigen. Aber die Komplexität der Bereitstellung und anschließenden Verwaltung sowie die sehr hohen Kosten solcher Lösungen schrecken viele ab.
Gerade für solche Szenarien, wie die Cross-Rack-Disaster-Recovery, ist die All-Flash-Lösung AccelStor NeoSapphire™ hervorragend geeignet. unter Verwendung der Shared-Nothing-Architektur. Dieses Modell stellt ein zweiknotiges Speichersystem dar, das die eigene Technologie FlexiRemap® für die Arbeit mit Flash-Speichern nutzt. Dank ist NeoSapphire™ H710 in der Lage, eine Leistung von bis zu 600K IOPS@4K zufälligem Schreiben und über 1M IOPS@4K zufälligem Lesen zu erbringen, was mit herkömmlichen RAID-basierten Speicherlösungen unerreichbar ist.
Die Hauptmerkmale von NeoSapphire™ H710 sind jedoch die Ausführung der beiden Knoten in Form einzelner Gehäuse, von denen jedes eine eigene Kopie der Daten hat. Die Synchronisation der Knoten erfolgt über die externe InfiniBand-Schnittstelle. Dank dieser Architektur können die Knoten über verschiedene Standorte bis zu 100 m voneinander entfernt gebracht werden, wodurch eine Cross-Rack-Disaster-Recovery-Lösung gewährleistet wird. Beide Knoten arbeiten vollständig synchron. Für die Hosts wirkt die H710 wie eine gewöhnliche Dual-Controller-Speicherlösung. Daher sind keine zusätzlichen Software- oder Hardwareoptionen und besonders komplizierte Einstellungen erforderlich.
Wenn man alle oben beschriebenen Lösungen zur Cross-Rack-Disaster-Recovery vergleicht, sticht die Lösung von AccelStor deutlich hervor:
AccelStor NeoSapphire™ Shared Nothing Architecture
Software- oder Hardware-"Virtualisierer" der Speicherlösung
Replikationsbasiertes Konzept
Verfügbarkeit
Serverausfall
Kein Ausfall
Kein Ausfall
Kein Ausfall
Ausfall des Switches
Kein Ausfall
Kein Ausfall
Kein Ausfall
Ausfall des Speichersystems
Kein Ausfall
Kein Ausfall
Ausfall
Ausfall des ganzen Racks
Kein Ausfall
Kein Ausfall
Ausfall
Kosten und Komplexität
Kosten des Lösung
Niedrig*
Hoch
Hoch
Bereitstellungskomplexität
Niedrig
Hoch
Hoch
*AccelStor NeoSapphire™ ist dennoch ein All-Flash-Speichersystem, das definitionsgemäß nicht „3 Cent“ kostet, insbesondere bei einem zweimal so hohen Kapazitätsvorrat. Im Vergleich zu den Endkosten ähnlicher Lösungen anderer Anbieter kann der Preis jedoch als niedrig angesehen werden.
Die Topologie für den Anschluss von Anwendungsservern und Knoten des All-Flash-Speichersystems wird wie folgt aussehen:
Bei der Planung der Topologie wird dringend empfohlen, eine Duplizierung der Verwaltungs- und Interconnect-Switches der Server vorzunehmen.
Hier und im Folgenden wird über die Verbindung über Fibre Channel gesprochen. Bei Verwendung von iSCSI ist es dasselbe, mit Ausnahme der verwendeten Schaltertypen und etwas anderer Einstellungen des Systems.
Vorbereitungsarbeiten am System
Verwendete Hardware und Software
Spezifikationen für Server 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 Multipathing
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 zur Datensynchronisierung
Intel X520
Spezifikation des AccelStor NeoSapphire™ All-Flash-Systems
Komponenten
Beschreibung
Speichersystem
NeoSapphire™ Hochverfügbarkeitsmodell: H710
Bildversion
4.0.1
Gesamtanzahl der Laufwerke
48
Laufwerksgröße
1,92TB
Laufwerkstyp
SSD
FC-Zielports
16x 16Gb-Ports (8 pro Knoten)
Verwaltungsports
Das 1GbE-Ethernetkabel, das über einen Ethernet-Switch mit Hosts verbunden ist
Heartbeat-Port
Das 1GbE-Ethernetkabel, das zwischen zwei Speicherknoten verbunden ist
Daten-Synchronisierungsport
56Gb/s InfiniBand-Kabel
Vor der Nutzung des Systems muss es initialisiert werden. Standardmäßig haben beide Knoten dieselbe Verwaltungsadresse (192.168.1.1). Sie müssen nacheinander mit ihnen verbinden und neue (bereits unterschiedliche) Verwaltungsadressen angeben sowie die Zeitsynchronisation einrichten, bevor die Management-Ports in ein gemeinsames Netzwerk verbunden werden können. Danach erfolgt die Zusammenführung der Knoten zu einem HA-Paar durch die Zuweisung von Subnetzen für Interlink-Verbindungen.
Nach der Abschluss der Initialisierung kann das System von jedem Knoten aus verwaltet werden.
Im nächsten Schritt erstellen wir die benötigten Volumes und veröffentlichen diese für die Anwendungsserver.
Es wird dringend empfohlen, mehrere Volumes für Oracle ASM zu erstellen, da dies die Anzahl der Targets für die Server erhöht und letztendlich die Gesamtleistung verbessert (mehr zu den Warteschlangen in einer anderen) ).
Testkonfiguration
Speicher-Volume-Name
Volume-Größe
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
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 Betriebsmodi des Arrays und den Prozessen bei außergewöhnlichen Situationen
Jedes Datensatzset jeder Node verfügt über einen Parameter „Versionsnummer“. Nach der ersten Initialisierung ist dieser identisch und gleich 1. Falls aus irgendeinem Grund die Versionsnummer unterschiedlich ist, erfolgt stets eine Daten-Synchronisation von der höheren Version zur niedrigeren, wodurch die niedrigere Version ausgeglichen wird, d.h. dies bedeutet, dass die Kopien identisch sind. Gründe, aus denen die Versionen unterschiedlich sein können:
- Geplante Neuzuweisung einer der Nodes
- Ausfall einer der Nodes aufgrund plötzlicher Abschaltung (Stromausfall, Überhitzung usw.).
- Abbruch der InfiniBand-Verbindung mit der Unfähigkeit zur Synchronisation
- Ausfall einer der Nodes aufgrund von Datenbeschädigung. In diesem Fall muss eine neue HA-Gruppe erstellt und das Datensatzset vollständig synchronisiert werden.
In jedem Fall erhöht die Node, die online bleibt, ihre Versionsnummer um eins, damit sie nach der Wiederherstellung der Verbindung mit dem Paar ihr Datensatzset synchronisieren kann.
Wenn die Verbindung über die Ethernet-Leitung unterbrochen wird, wechselt Heartbeat vorübergehend zu InfiniBand und kehrt innerhalb von 10 Sekunden zurück, sobald es wiederhergestellt ist.
Host-Konfiguration
Um Hochverfügbarkeit und Leistungssteigerung zu gewährleisten, muss die Unterstützung von MPIO für das Array aktiviert werden. Dazu müssen Sie die Zeilen in die Datei /etc/multipath.conf hinzufügen und anschließend 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 und anschließend /etc/init.d/oracleasm scandisks ausgeführt werden.
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 sind.
Seit Version 12.1.0.2 ist die Oracle Database-Option als Teil der ASMFD-Software erhältlich.
Es sollte unbedingt sichergestellt werden, dass die zur Oracle ASM erstellten Festplatten in Bezug auf die Blockgröße, mit der das Array physisch arbeitet (4K), ausgerichtet sind. Andernfalls können Leistungsprobleme auftreten. Daher müssen Volumes mit den entsprechenden Parametern 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
Speicher-Volume-Name
Volume-Größe
Mapping der Volume-LUNs
ASM Volumengerätedetails
Zuweisungseinheitsgröße
Data01
200GB
Alle Speicher-Volumes auf das Speichersystem aller Datenports abbilden
Redundanz: Normal
Name: DGDATA
Zweck: Datendateien
4MB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
Grid01
1GB
Redundanz: Normal
Name: DGGRID1
Zweck: Grid: CRS und Abstimmung
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundanz: Normal
Name: DGGRID2
Zweck: Grid: 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-Speicher = 16GB
- AMM (Automatische Speicherverwaltung) deaktivieren
- Transparente große Seiten deaktivieren
Weitere 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 # setze dies nicht, wenn du Linux x86 verwendest
✓ 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 emulieren. Konfiguration von HammerDB:
Anzahl der Lagerhäuser
256
Gesamte Transaktionen pro Benutzer
1000000000000
Virtuelle Benutzer
256
Das Ergebnis war eine Leistung von 2,1M TPM, was weit vom Limit der Array-Leistung entfernt ist , aber es ist das „Limit“ für die derzeitige Hardwarekonfiguration der Server (vor allem wegen der Prozessoren) und deren Anzahl. Ziel dieses Tests ist jedoch die Demonstration der Ausfallsicherheit der Lösung als Ganzes und nicht das Erreichen von Leistungshöchstwerten. Daher orientieren wir uns einfach an dieser Zahl.
Test auf den Ausfall eines Knotens
Die Hosts haben Teile der Pfade zum Speicher verloren, arbeiteten aber über die verbleibenden mit dem zweiten Knoten weiter. Die Leistung sank für einige Sekunden aufgrund der Umstellung der Pfade und kehrte dann zu normalen Werten zurück. Es gab keine Ausfallzeit.
Test auf den Ausfall des Racks mit der gesamten Ausrüstung
In diesem Fall sank die Leistung ebenfalls für einige Sekunden aufgrund der Umstellung der Pfade und kehrte dann auf die Hälfte des ursprünglichen Wertes zurück. Das Ergebnis sank um die Hälfte des ursprünglichen Wertes aufgrund der Deaktivierung eines Anwendungsservers. Es gab auch keine Ausfallzeit.
Wenn die Anforderungen an die Implementierung einer ausfallsicheren Cross-Rack-Disaster-Recovery-Lösung für Oracle zu einem vernünftigen Preis und mit geringem Aufwand für Bereitstellung/Administration bestehen, wird die Zusammenarbeit von Oracle RAC und der Architektur eine der besten Optionen sein. Anstelle von Oracle RAC kann jede andere Software verwendet werden, die Clusterbildung ermöglicht, sei es von denselben DBMS oder Virtualisierungssystemen. Das Prinzip der Lösungsarchitektur bleibt dasselbe. Und das Endziel ist ein null Wert für RTO und RPO.
Quelle: habr.com
