Erstellen Sie eine Failover-Lösung, die auf der Oracle RAC- und AccelStor Shared-Nothing-Architektur basiert

Eine beträchtliche Anzahl von Unternehmensanwendungen und Virtualisierungssystemen verfügt über eigene Mechanismen zum Erstellen fehlertoleranter Lösungen. Insbesondere ist Oracle RAC (Oracle Real Application Cluster) ein Cluster aus zwei oder mehr Oracle-Datenbankservern, die zusammenarbeiten, um die Last auszugleichen und Fehlertoleranz auf Server- / Anwendungsebene bereitzustellen. Um in diesem Modus zu arbeiten, ist ein gemeinsamer Speicher erforderlich, dessen Rolle normalerweise der Speicher ist.

Wie wir bereits in einem unserer Artikel besprochen haben, weisen Speichersysteme trotz des Vorhandenseins doppelter Komponenten (einschließlich Steuerungen) immer noch Fehlerquellen auf - hauptsächlich in Form eines einzelnen Datensatzes. Um eine Oracle-Lösung mit erhöhten Zuverlässigkeitsanforderungen zu erstellen, muss das Schema „N Server - ein Speicher“ daher kompliziert sein.

Zunächst müssen Sie natürlich entscheiden, gegen welche Risiken wir uns versichern möchten. In diesem Artikel wird der Schutz vor Bedrohungen wie dem Eintreffen eines Meteoriten nicht berücksichtigt. Der Aufbau einer geografisch verteilten Disaster Recovery-Lösung bleibt daher ein Thema für einen der folgenden Artikel. Hier sehen wir uns die sogenannte Cross-Rack-Disaster-Recovery-Lösung an, bei der der Schutz auf der Ebene von Serverschränken aufgebaut wird. Die Schränke selbst können sich im selben Raum oder in verschiedenen Räumen befinden, normalerweise jedoch im selben Gebäude.

Diese Schränke sollten alle erforderlichen Geräte und Software enthalten, die den Betrieb von Oracle-Datenbanken unabhängig vom Status des „Nachbarn“ gewährleisten. Mit anderen Worten, mit der Cross-Rack-Disaster-Recovery-Lösung eliminieren wir die Ausfallrisiken:

• Oracle-Anwendungsserver
• Speichersysteme
• Vermittlungssysteme
• Vollständiger Ausfall aller Geräte im Schrank:
  
  • Stromausfall
  • Ausfall des Kühlsystems
  • Externe Faktoren (Mensch, Natur usw.)

Die Duplizierung von Oracle-Servern impliziert das Prinzip von Oracle RAC und wird über die Anwendung implementiert. Das Duplizieren von Schaltwerkzeugen ist ebenfalls kein Problem. Aber mit der Verdoppelung des Speichersystems ist nicht alles so einfach.

Am einfachsten ist es, Daten vom Primärspeicher in die Sicherung zu replizieren. Abhängig von den Speicherfunktionen synchron oder asynchron. Die asynchrone Replikation wirft sofort die Frage auf, ob die Datenkonsistenz mit Oracle sichergestellt werden kann. Aber selbst wenn eine Software in die Anwendung integriert ist, müssen Administratoren im Falle eines Unfalls auf dem Hauptspeichersystem manuell eingreifen, um den Cluster auf den Sicherungsspeicher umzustellen.

Eine komplexere Option sind Software- und / oder Hardware-Virtualisierer von Speichersystemen, die Probleme mit der Konsistenz und manuellen Eingriffen beseitigen. Die Komplexität der Bereitstellung und der anschließenden Verwaltung sowie die sehr unanständigen Kosten solcher Lösungen machen vielen jedoch Angst.

Nur für Szenarien wie die Cross-Rack-Notfallwiederherstellung ist das All Flash AccelStor NeoSapphire ™ H710-Array mit der Shared-Nothing-Architektur perfekt . Dieses Modell ist ein Zwei-Einzel-Speichersystem, das seine eigene FlexiRemap®-Technologie für die Arbeit mit Flash-Laufwerken verwendet. Dank des FlexiRemap® NeoSapphire ™ H710 können bis zu 600K IOPS @ 4K Random Write und 1M + IOPS @ 4K Random Read bereitgestellt werden, was mit klassischem RAID-basiertem Speicher nicht möglich ist.

Das Hauptmerkmal des NeoSapphire ™ H710 ist jedoch die Ausführung von zwei Knoten als separate Gehäuse, von denen jedes eine eigene Kopie der Daten hat. Die Knotensynchronisation erfolgt über die externe InfiniBand-Schnittstelle. Dank dieser Architektur können Knoten über Entfernungen von bis zu 100 m auf verschiedene Standorte verteilt werden, wodurch die Cross-Rack-Disaster-Recovery-Lösung bereitgestellt wird. Beide Knoten arbeiten vollständig im synchronen Modus. Auf der Hostseite sieht das H710 wie ein gewöhnlicher Dual-Controller-Speicher aus. Daher müssen keine zusätzlichen Software- und Hardwareoptionen und besonders komplexen Einstellungen vorgenommen werden.

Wenn Sie alle oben beschriebenen Cross-Rack-Disaster-Recovery-Lösungen vergleichen, hebt sich die AccelStor-Version von den anderen ab:

* AccelStor NeoSapphire ™ ist immer noch ein All-Flash-Array, das per Definition keine „3 Kopeken“ kostet, zumal es eine doppelte Kapazitätsreserve hat. Wenn man jedoch die Gesamtkosten der darauf basierenden Lösung mit ähnlichen Kosten anderer Anbieter vergleicht, können die Kosten als niedrig angesehen werden.

Die Topologie zum Verbinden von Anwendungsservern und allen Flash-Array-Knoten sieht folgendermaßen aus:

Bei der Planung der Topologie wird außerdem dringend empfohlen, Verwaltungsschalter und Serververbindungen zu duplizieren.

Im Folgenden werden wir über die Verbindung über Fibre Channel sprechen. Bei Verwendung von iSCSI ist alles gleich, angepasst an die verwendeten Switch-Typen und leicht unterschiedliche Array-Einstellungen.

Vorarbeiten am Array

Bevor Sie ein Array verwenden, müssen Sie es initialisieren. Standardmäßig ist die Steueradresse beider Knoten identisch (192.168.1.1). Sie müssen nacheinander eine Verbindung zu ihnen herstellen, neue (bereits unterschiedliche) Verwaltungsadressen festlegen und die Zeitsynchronisierung konfigurieren. Anschließend können die Verwaltungsports mit einem einzelnen Netzwerk verbunden werden. Danach werden die Knoten zu einem HA-Paar zusammengefasst, indem Interlink-Verbindungen Subnetze zugewiesen werden.

Nach Abschluss der Initialisierung können Sie das Array von jedem Knoten aus steuern.

Erstellen Sie als Nächstes die erforderlichen Volumes und veröffentlichen Sie sie für Anwendungsserver.

Es wird dringend empfohlen, mehrere Volumes für Oracle ASM zu erstellen, da dies die Anzahl der Ziele für die Server erhöht, was letztendlich die Gesamtleistung verbessert (mehr zu Warteschlangen in einem anderen Artikel ).

Einige Erklärungen zu den Betriebsarten des Arrays und den Prozessen, die in Notsituationen auftreten

Jeder Knotendatensatz verfügt über einen Parameter "Versionsnummer". Nach der anfänglichen Initialisierung ist sie gleich und gleich 1. Wenn die Versionsnummer aus irgendeinem Grund unterschiedlich ist, werden immer Daten von der älteren Version zur jüngeren Version synchronisiert, wonach die Nummer für die jüngere Version ausgerichtet wird, d. H. Dies bedeutet, dass die Kopien identisch sind. Gründe, warum Versionen variieren können:

• Geplanter Neustart eines der Knoten
• Ein Unfall an einem der Knoten aufgrund eines plötzlichen Herunterfahrens (Stromversorgung, Überhitzung usw.).
• Unterbrochene InfiniBand-Verbindung mit Unfähigkeit zur Synchronisierung
• Absturz auf einem der Knoten aufgrund von Datenbeschädigung. Es ist bereits die Erstellung einer neuen HA-Gruppe und die vollständige Synchronisierung des Datensatzes erforderlich.

In jedem Fall erhöht der online verbleibende Knoten seine Versionsnummer um eins, sodass er nach erneuter Verbindung mit dem Paar seinen Datensatz synchronisiert.

Wenn die Verbindung über die Ethernet-Verbindung unterbrochen wird, wechselt Heartbeat vorübergehend zu InfiniBand und kehrt nach Wiederherstellung innerhalb von 10 Sekunden zurück.

Host-Konfiguration

Um Fehlertoleranz sicherzustellen und die Leistung zu erhöhen, müssen Sie die MPIO-Unterstützung für das Array aktivieren. Fügen Sie dazu der Datei /etc/multipath.conf Zeilen hinzu und laden Sie den Multipath-Dienst neu

Damit ASM über ASMLib mit MPIO arbeiten kann, müssen Sie die Datei / etc / sysconfig / oracleasm ändern und anschließend /etc/init.d/oracleasm scandisks ausführen

Stellen Sie sicher, dass die für Oracle ASM erstellten Datenträger an der Größe des Blocks ausgerichtet sind, mit dem das Array physisch arbeitet (4 KB). Andernfalls können Leistungsprobleme auftreten. Daher müssen Sie Volumes mit den entsprechenden Parametern erstellen:

parted / dev / mapper / Gerätename mklabel gpt mkpart primary 2048s 100% Align-Check Optimal 1

Verteilung von Datenbanken auf erstellten Volumes für unsere Testkonfiguration

Fehlertoleranztest

Zu Demonstrationszwecken wurde HammerDB verwendet, um die OLTP-Last zu emulieren. HammerDB-Konfiguration:

Als Ergebnis wurde der 2.1M TPM-Indikator erhalten, der weit von der Leistungsgrenze des H710- Arrays entfernt ist, aber die „Obergrenze“ für die aktuelle Hardwarekonfiguration von Servern (hauptsächlich aufgrund von Prozessoren) und deren Anzahl darstellt. Der Zweck dieses Tests besteht weiterhin darin, die Fehlertoleranz der gesamten Lösung zu demonstrieren und nicht die maximale Leistung zu erzielen. Deshalb werden wir einfach auf dieser Zahl aufbauen.

Test auf Ausfall eines der Knoten

Die Hosts haben einige der Pfade zum Speicher verloren und die verbleibenden Pfade mit dem zweiten Knoten weiter bearbeitet. Die Leistung ging aufgrund der Umstrukturierung der Pfade für einige Sekunden zurück und normalisierte sich dann wieder. Es ist keine Dienstunterbrechung aufgetreten.

Schrankausfalltest mit allen Geräten

In diesem Fall sank die Leistung aufgrund der Umstrukturierung der Pfade ebenfalls für einige Sekunden und kehrte dann auf die Hälfte des Werts des ursprünglichen Indikators zurück. Das Ergebnis wurde aufgrund des Ausschlusses vom Betrieb eines Anwendungsservers vom Original halbiert. Eine Dienstunterbrechung ist ebenfalls nicht aufgetreten.

Wenn Sie eine fehlertolerante Cross-Rack-Disaster-Recovery-Lösung für Oracle zu angemessenen Kosten und mit geringem Aufwand für Bereitstellung / Verwaltung implementieren müssen , ist die Zusammenarbeit mit Oracle RAC und der AccelStor Shared-Nothing- Architektur eine der besten Optionen. Anstelle von Oracle RAC kann es auch eine andere Software geben, die Clustering bereitstellt, z. B. dasselbe DBMS oder dieselben Virtualisierungssysteme. Das Prinzip der Konstruktion der Lösung bleibt gleich. Und das Endergebnis ist Null für RTO und RPO.