ZFS-Speicher-, Standby- und Testumgebungen

- Haben wir ein Bild für Januar, näher am Februar?
- Jetzt mal sehen ... Ja, das gibt es! Jetzt öffnen.

Es kommt vor, dass es eine durchschnittliche Lebensdauer der Testbasis gibt, es gibt eine Lebensdauer für Schnappschüsse, auf die sich alle Interessierten geeinigt haben, aber einige der Umgebungen „verweilen“ zu lange in ihrem Bild, was nicht gelöscht werden kann ... und es stellt sich dann als nützlich für Kollegen heraus. Und Minus bis Minus gibt ein Plus.

Normalerweise müssen Sie für alle Systeme, auf denen etwas passieren kann, Sicherungen erstellen. Und wenn es noch entwickelt und finalisiert wird, ist es auch notwendig, irgendwo Entwicklungs- und Testumgebungen bereitzustellen. Darüber hinaus benötigen Sie für Sicherungen und Testumgebungen, die tatsächlich mit denselben Daten arbeiten, viel Speicherplatz. Und doch müssen diese Umgebungen irgendwie zum aktuellen Zustand führen. Und all dies erfordert Hardware und Zeitressourcen.

In unserem Fall wurden diese Anforderungen von den Oracle ZFS Storage Appliance- und Oracle / Sun-Servern abgedeckt, die tatsächlich in dasselbe Ökosystem wie Exadata integriert wurden, das kurz vor ihnen erschien.

Da es in Exadata einen InfiniBand-Switch gibt, über den seine Komponenten kommunizieren, und ZFS Storage auch eine Oracle-Appliance ist, gilt Folgendes:

• Erstens war es über einen Teil seiner Ports direkt mit diesem Switch verbunden.
• Zweitens können Tablespace-Dateien mit Segmenten gespeichert werden, die in der Exadata Hybrid Columnar Compression (EHCC) komprimiert sind, wodurch wir viel Platz im Hauptsystem sparen. Wenn Sie versuchen, die Datenbank auf einem separaten Server wiederherzustellen, wird nach der Wiederherstellung unter Bezugnahme auf die komprimierten Daten die folgende Fehlermeldung angezeigt: "ORA-64307: Die hybride Spaltenkomprimierung wird für Tablespaces auf diesem Speichertyp nicht unterstützt" - aufgrund der Datendateien im EHCC komprimiert sollte in der Oracle Appliance gespeichert werden;
• Drittens eröffnet dies die Möglichkeit, ZFS-Kapazitäten zum Speichern von Testumgebungsdateien zu verwenden.

Was ist mit dem Ort? Doppelarbeit muss vermieden werden.

Testumgebungen benötigen dieselben Daten wie in Sicherungen. Können diese Daten beide Funktionen ausführen? Als Backup und Basis für jede privilegierte Testumgebung, die einen vollständigen Datensatz benötigt? Sie können!

Die Oracle ZFS Storage Appliance ist ein Array, das unter anderem die Möglichkeit bietet, Netzwerkfreigaben zu bilden, die unter dem ZFS-Dateisystem ausgeführt werden. Innerhalb des ZFS-Dateisystems können Snapshots erstellt werden, auf deren Grundlage Sie Klone bereitstellen können, die als neue Netzwerkfreigaben angezeigt werden. Wir nutzen diese Gelegenheit wie folgt:

1. Auf dem ZFS-Speicher (wie wir das Array nennen werden, um nicht mit dem Dateisystem verwechselt zu werden) werden zwei Freigaben erstellt - Archivelog wird zu einer und Datenbankdateien zu der anderen hinzugefügt;
2. Die Freigabe wird auf dem Oracle / Sun-Server (der auch die Appliance ist) bereitgestellt, und auf dem Server selbst steigt eine Instanz der Oracle-Datenbank an, die als kaskadierter physischer Standby fungiert. Sie empfängt Protokolle von einer bedingten Sicherungssite und wendet die Änderungen auf die Dateien in der Freigabe an.
3. Die Verwendung von Protokollen ist nach dem Prinzip der Arbeitseinheit organisiert (Hallo an alle Teilnehmer am verteilten Rechnen!). Auf der Ebene des Algorithmus wird das Konzept der Arbeitseinheit eingeführt, das einem bestimmten Zeitintervall entspricht. Nachdem die Protokolle für das erforderliche Intervall gerollt wurden, wird die Instanz angehalten und die Dateien verbleiben in der Freigabe in einem konsistenten Zustand relativ zueinander und zur Steuerdatei. In der Tat ist dies ein kaltes Backup, es ist auch eine Image-Kopie, auf der ein Schnappschuss erstellt wird.
4. Wenn die Testumgebung neu erstellt werden muss, wird aus dem gewünschten Snapshot ein Klon erstellt. Es wird auf dem Server bereitgestellt, auf dem die Umgebung ausgeführt wird. Anschließend werden die darin enthaltenen Dateien als Datenbank unter einem anderen Namen und im Lese- / Schreibmodus geöffnet.
5. Während der Arbeit in der Testbasis werden Änderungen vorgenommen, die als Teil des Klons verschoben werden und langsam wachsen. Am Ende des Lebenszyklus wächst das Medium maximal.
6. Um den Speicherplatzverbrauch zu reduzieren, verwenden wir die LZJB-Komprimierung, die ZFS Storage im laufenden Betrieb ausführt.

Zusammenfassend:

1. In der aktuellen Konfiguration können Testumgebungen E / A bis zu 3,75 Gbit / s ausführen.
   Das Maximum für das Lesen wird durch die vorhandenen InfiniBand-Porteinstellungen auf dem Server begrenzt, das Maximum für das Schreiben beträgt die CPU auf ZFS-Speichercontrollern und erreicht etwa 2 Gbit / s. (Ja, ja! Da 10 GbE nicht ausreichten, wurden separate Switches für Testserver gekauft, darunter ZFS Storage und die Server selbst.)
2. Pro Tag werden mehrere Schnappschüsse erstellt, die nun je nach Basis zwischen 2 Wochen und 2 Monaten gespeichert werden. Danach werden sie alle gelöscht, mit Ausnahme der Schnappschüsse, die am 1. eines jeden Monats um 00:00 Uhr erstellt wurden. Diese werden länger als ein Viertel gespeichert. Es gab Fälle, in denen sich Schnappschüsse, die etwa sechs Monate lang aufbewahrt wurden, als nützlich erwiesen.
3. Bei Bedarf kann die gesamte Industriedatenbank aus dem gewünschten Snapshot wiederhergestellt werden. Auch mit einer Geschwindigkeit in der Größenordnung von 1 ... 3 Gbit / s, aber die Option, einen Klon aus dem gewünschten Snapshot zu erstellen, ist viel beliebter, aus dem die Daten der gewünschten Tabellen dann entladen werden.
4. Die Zeit zum Wiederherstellen der Testumgebung beträgt ca. 1 Stunde (mit der Übertragung einer Reihe zusätzlicher Schaltkreise usw.).
5. Die Zeit, um Kollegen einen Klon zur Verfügung zu stellen, von dem Sie Daten für die Wiederherstellung oder nur eine Art von Analyse sammeln können, beträgt 15 Minuten (mit einer idealen Kombination von Bedingungen) bis 1-2 Stunden (mit einer großen parallelen Belastung von ZFS Storage oder us J).
6. Bei Bedarf können Sie aus dem Snapshot und Klon sowie der gesamten Datenbank wiederherstellen.
7. Eine wesentliche Leistungsbeschränkung ist die Anzahl der IOPS, die von Testumgebungen oder Instanzen von kaskadiertem Standby generiert werden. Und hier verhält sich das System absolut angemessen und vorhersehbar - sobald die Anzahl auf 75 IOPS pro Festplatte (es enthält 3,5-Zoll-Festplatten mit 7200 U / min) bei längerer Last eingestellt wird, beginnt das System allmählich durchzuhängen. Und zeitlich klein - Write- und Read-Flash sind spürbar einfacher;
8. Die Anzahl der IOPS, die Gesamtmenge der eingehenden Daten, die Belastung der CPU, die Anzahl der Lesevorgänge aus den Caches im RAM und in Flash sowie mehrere Dutzend (wenn nicht Hunderte) Metriken können in der Webverwaltungsoberfläche angezeigt werden.
9. Sie können mit ZFS-Speicherobjekten mithilfe der in der Dokumentation beschriebenen REST-Anforderungen arbeiten. Mit ihrer Hilfe war es möglich, das Entfernen veralteter Schnappschüsse zu automatisieren, aber es kann noch viel mehr getan werden!