Speichermodernisierung mit Oracle Cloud Infrastructure Object Storage

In diesem Lösungshandbuch erfahren Sie, wie Sie die Migration von Langzeitspeicher von lokalen oder NFS-Dateisystemen zu Oracle Cloud Infrastructure Object Storage (OCI Object Storage) entwerfen und ausführen. Eine solche Lösung kann dazu beitragen, Kosten zu senken und die Aufbewahrung, Lebenszyklusregeln und vorab authentifizierte Anforderungen als zusätzliche Features anzuwenden.

In diesem Lösungshandbuch heben wir anhand eines Kundenanwendungsfalls den Ausgangspunkt für eine erfolgreiche Modernisierung hervor.

Wir sprechen oft im selben Gespräch über Cloud-Migration und -Modernisierung und durchlaufen alle verfügbaren Methoden, Services und Angebote. Das Gespräch beinhaltet oft einen schrittweisen Ansatz, bei dem ein gesamtes Rechenzentrum systematisch in die Cloud verlagert, wie es ist gehoben und verschoben wird, und dann folgt alles andere.

Sobald die erste Phase abgeschlossen ist, verliert die Anwendungsmodernisierung oft an Bedeutung im Vergleich zu Sicherheits-, Überwachungs-, aktuellen und laufenden Integrationsherausforderungen. Es hebt auch eine Verschiebung von der Arbeit hervor, die Infrastrukturteams zu der von Anwendungsteams erledigen können. Budgets, Timing und andere Prioritäten haben Vorrang, sodass Anwendungen unverändert in der Cloud ausgeführt werden können. Um das wahre Einsparpotenzial der Cloud zu nutzen, sollten Unternehmen auf Technologien wie Objektspeicher zurückgreifen, um Kosten zu sparen.

Dateiarchive sind ein guter Ausgangspunkt, da sie mit minimalem Entwicklungsaufwand und minimalen Tests von NFS zu OCI Object Storage umgestellt werden können. Die Implementierung einer solchen Lösung kann je nach Anwendungsfall in der Reihenfolge 10-50x auf dem Speicher sparen. Unternehmen haben erkannt, dass der Betrieb von Rechenzentren immer mehr zur Verantwortung gezogen wird und zu unsichtbaren zusätzlichen Kosten führen kann, wobei die wachsende Anzahl potenzieller Angriffe, Serviceverluste und Wettbewerber ständig innovieren.

Dies sollte die Verwendung cloudnativer Services wie OCI Object Storage zu einer Priorität machen, um Kosten zu sparen, das Unternehmen zu schützen, die Belastung durch den Betrieb einer Vielzahl unterschiedlicher Workloads mit einem Hyperscaler und mehr zu teilen.

Herausforderungen nach der Migration verstehen

Der Schlüssel war hier, sich auf einen Schmerzpunkt nach der Migration zu konzentrieren und ein großes Stück der Anwendung neu zu gestalten, um wirkungsvoll zu sein, aber klein genug, um in einem einzigen Design-Sprint anzugehen. Auf diese Weise erzielt das Unternehmen sowohl Einsparungen als auch Seelenfrieden, während die Entwicklungs- und Testkosten niedrig bleiben.

Für den Anwendungsfall in diesem Lösungs-Playbook wurden die Kosten für Shared File Storage (NFS) zu einem Problem in der Cloud, und das ursprüngliche Design der Anwendung wurde zum Grund dafür, dass es nicht so einfach zu ändern war. Während des Projekts zur Migration von On-Premises in die Cloud sprachen wir über Object Storage als billigere und zuverlässigere Alternative zu File Storage, auf dem Papier über Einsparungen von 10x. Wenn Sie Backups und Replikation hinzufügen, ist 10x wahrscheinlich höher. Effiziente Features wie regionsübergreifende Replikation, Aufbewahrungssperre und Lebenszyklus-Policys können alle zusammenarbeiten, um Object Storage zur Grundlage für ein kostengünstiges, zuverlässiges und sicheres System zu machen, auf dem wichtige Dokumente gespeichert werden können. Wenn die Anwendung jedoch auf das NFS-Dateisystem für die Dokumentenspeicherung ausgelegt ist und eine POSIX-Semantik erwartet, werden die Dinge schwieriger.

Die Anwendung, die in diesem Anwendungsfall modernisiert wurde, ist eine standardmäßige 3-Tier-Anwendung, jedoch mit mehreren externen Komponenten, die einen koordinierten und CPU-intensiven Prozess ausführen müssen, um Kundenrechnungen zu generieren, in einer organisierten Verzeichnisstruktur zu posten und sie zum Download und zur langfristigen Speicherung zu katalogisieren. Diese PDF-Dateien und andere Dateien wurden auf einem großen NFS-Dateisystem mit einem sehr spezifischen Dateibenennungsmuster gespeichert, um über einen generierten Pfad aufgerufen zu werden. Eine weitere Anwendung wurde um den Apache HTTP-Server herum entwickelt, wobei der langfristige Speicherbereich dieser NFS-Freigabe als Dokument-Root verwendet wurde, sodass die generierten URLs aus der Anwendung verwendet werden konnten, um Dateien von jedem Punkt in den letzten 2 Jahren herunterzuladen. Schließlich könnten Dateien, die älter als ein bestimmtes Alter sind, aus dem Online-Archiv entfernt werden, aber dennoch von Auditoren angefordert werden, die Aufzeichnungen suchen.

So mussten alle Dateien bis 10 Jahre auf dem NFS-Dateisystem aufbewahrt werden, was das Unternehmen jeden Tag mehr Geld kostete, neue Dateien zu generieren. Das Problem bestand in mehreren verschiedenen Anwendungen, so dass sich das Kostenproblem im Laufe der Zeit nur verschlimmern würde.

OCI Object Storage nutzen

Object Storage eignet sich perfekt für Dateien, die sich nicht häufig ändern. Dies steht im Gegensatz zu NFS, das sich auf Shared Storage mit gemischter Verwendung konzentriert.

Durch die Nutzung mehrerer Object Storage-Designelemente und einiger spezifischer Features von OCI Object Storage Service können wir die Verfügbarkeit erhöhen und die Kosten für geeignete Workloads senken.

In diesem Anwendungsfall passen Dateien, die für den mittelfristigen Zugriff und das langfristige Archiv erstellt wurden, gut. Diese Dateien werden wahrscheinlich einmal geschrieben und müssen für Monate oder Jahre ohne Änderung gespeichert werden. Tatsächlich möchte das Unternehmen möglicherweise sichern, dass es für einen bestimmten Zeitraum unveränderlich ist.

Insgesamt gibt es eine Liste der grundlegenden Gründe, warum Object Storage Vorteile gegenüber dem herkömmlichen Dateispeicher für diese Dateitypen bietet.

  • Verfügbarkeit: Object Storage ist ein regionaler Service, d.h. er ist nicht an eine einzelne Availability-Domain gebunden.
  • Suchen: Die Verwendung von Objektmetadaten ist wahrscheinlich nützlicher, als sich ausschließlich auf Dateinamen und Suchbefehle im POSIX-Stil zu verlassen.
  • Aufbewahrungsregeln: Ein vollständiger Bucket kann nach dem Schreiben von Objekten nicht mehr geändert werden, um die sofortige Compliance sicherzustellen.
  • Storage Tiers: Object Storage Tiering (entweder automatisch oder manuell) führt zu einer enormen Kostensenkung für Objekte, auf die selten zugegriffen wird oder die für Geschäftsregeln erforderlich sind.
  • Lebenszyklus-Policys: Durch das Tuning der Verschiebung zwischen Speicherebenen und der automatischen Löschung (Bereinigung) nach der Aufbewahrung werden Speicher und Administration eingespart.
  • Replikation: Die einfache und automatische Replikation eines gesamten Buckets in eine andere Region kann die Verfügbarkeit und den Zugriff auf Daten erhöhen.
  • Kosten: Richtig konstruierter und verwalteter Objektspeicher kostet viel weniger als duplizierte und überladene NFS-Dateisysteme.

NFS ist weiterhin nützlich für Anwendungen, die ein gemountetes, gemeinsam genutztes POSIX-Dateisystem erfordern. Der Kunde benötigte weiterhin NFS für Shared Storage, aber die Verwendung war auf "operative" Dateien beschränkt, im Gegensatz zu "Archiv"-Dateien. Die hier beschriebene Lösung beschreibt, wie Sie Object Storage einrichten und darauf zugreifen und wie die Anwendung so geändert wurde, dass sie sowohl den NFS-Speicher als auch das neue Object Storage-Archiv verwendet, das für den langfristigen Speicher erstellt wurde.

Architektur

Diese Architektur zeigt das Design und die Ausführung, um langfristigen Speicher in OCI Object Storage zu verschieben. So können Sie Kosten senken und die Aufbewahrung, Lebenszyklusregeln und vorab authentifizierte Anforderungen als zusätzliche Features anwenden.

Die folgenden Bilder zeigen die Architektur "vor" und "nach" Implementierung. Oracle File System Service (FSS) wird für große gemeinsam genutzte Dateisysteme verwendet. Auf diesem Dateisystem, das von einem On-Premise-Data Center migriert wurde, verwenden die Anwendungskomponenten die Batchverarbeitung, um fortlaufend Archivdateien zu generieren. Somit enthält dasselbe NFS-Dateisystem sowohl die Anwendungselemente, die für die Zwischenverarbeitung (Skripte, temporäre Dateien usw.) erforderlich sind, und das eigentliche Dateiarchiv, das in einer Hierarchie gespeichert ist, die je nach Geschäftsanforderungen bis zu 10 Jahre lang gewartet werden muss.

Nach der Einrichtung werden OCI Object Storage-Buckets verwendet, um den Archivteil der NFS-Vorgänge zu hosten. Berechtigungen zum Lesen und Schreiben des Buckets sind eng definiert, und Aufbewahrungs- und Lebenszyklusregeln werden eingerichtet, um auf einen großen Datenfluss vorbereitet zu sein. Die große Hierarchie der Archivdateien wird in OCI Object Storage kopiert, und die Batchverarbeitung wird umgestaltet, um neue Archive im neuen Objekt-Bucket zu platzieren. Zugriffsmechanismen wurden auch leicht umgestaltet, um vom Objektspeicher auf die Dateien zuzugreifen, so dass der Rest der Anwendung und die Endkunden keine Änderungen vornehmen mussten, wie sie auf diese Archive zugreifen.

Das folgende Diagramm veranschaulicht die Architektur vor der Implementierung:



oci-object-storage-modernization-arch-oracle1.zip

Das folgende Diagramm veranschaulicht die Architektur nach der Implementierung:



OCI-Objekt-Speicher-Modernisierung-Arch-oracle.zip

a: OSS-Standard-Policy:
  • Mandantenadministratoren - Vollständiger Zugriff
  • App-Administratoren - Eingeschränkter Zugriff ohne Objektlesung
  • Schreibgeschützt - Bucket-Prüfung ohne Objektlesen
b: IAM-Policy für dynamische Gruppen:
  • Pro dynamischer Gruppe hinzugefügte Anweisungen
  • Eng definiert für bestimmte Ressourcen
c: Dynamische Gruppendefinition (entweder):
  • Liste der Instanz-OCIDs
  • Instanz-Compartment-OCID
d: Aufbewahrungsregeln:
  • 3650 Tage (10 Jahre)
  • gesperrt

e: Lebenszyklusregeln:

  • Nach 90 Tagen - Seltene Lagerung
  • Nach 180 Tagen - Archivspeicher
  • Nach 3651 Tagen - Löschen

Diese Architektur unterstützt die folgenden Komponenten:

  • Object Storage

    Mit Oracle Cloud Infrastructure Object Storage können Sie schnell auf große Mengen an strukturierten und unstrukturierten Daten eines beliebigen Inhaltstyps zugreifen, darunter Datenbankbackups, Analysedaten und umfangreiche Inhalte, wie Bilder und Videos. Sie können Daten sicher und geschützt speichern und dann direkt aus dem Internet oder aus der Cloud-Plattform abrufen. Sie können den Speicher skalieren, ohne dass die Performance oder Servicezuverlässigkeit beeinträchtigt wird. Verwenden Sie Standardspeicher für "guten" Speicher, auf den Sie schnell, sofort und häufig zugreifen müssen. Verwenden Sie Archivspeicher für "Cold Storage", den Sie über lange Zeiträume beibehalten und auf den Sie nur selten zugreifen.

  • File Storage

    Der Oracle Cloud Infrastructure File Storage Service stellt ein dauerhaftes, skalierbares, sicheres Netzwerkdateisystem der Unternehmensklasse bereit. Sie können über jede Bare-Metal-, VM- oder Containerinstanz in einem VCN eine Verbindung mit einem File Storage Service-Dateisystem herstellen. Sie können auch außerhalb des VCN mit Oracle Cloud Infrastructure FastConnect und IPSec-VPN auf ein Dateisystem zugreifen.

  • Identity and Access Management (IAM)

    Oracle Cloud Infrastructure Identity and Access Management (IAM) ist die Zugriffskontrollebene für Oracle Cloud Infrastructure (OCI) und Oracle Cloud Applications. Mit der IAM-API und der Benutzeroberfläche können Sie Identitätsdomains und die Ressourcen innerhalb der Identitätsdomain verwalten. Jede OCI-IAM-Identitätsdomain stellt eine eigenständige Identity and Access Management-Lösung oder eine andere Benutzerpopulation dar.

Überlegungen zu Identity Management

Wenn Sie private Objektspeicher-Buckets verwenden, müssen Sie die richtigen Berechtigungen für die Verwendung einrichten. Standardmäßig erhalten Benutzergruppen und dynamische Gruppen keinen Zugriff auf breite Berechtigungssets, wie object-family, es sei denn, sie haben einen Geltungsbereich für ein Compartment.

Bevor Sie mit dieser Lösung beginnen, sollten Sie sicherstellen, dass nur die Gruppen, auf die Sie Zugriff haben möchten, über Berechtigungen für den Objektspeicher verfügen. Eine Sache, die hier äußerst hilfreich ist, ist die Einhaltung der CIS-Landing-Zone-Methodik zur Einschränkung des Zugriffs. Bei der Implementierung dieser Lösung wird die Erstellung dynamischer Gruppen erläutert. Es lohnt sich also, sowohl die Compartment-Struktur Ihres Mandanten als auch die Konzepte zu verstehen, die in der Landing Zone diskutiert werden. Es lohnt sich auch, sich mit der OCI-Policy-Syntax vertraut zu machen, einschließlich der Möglichkeit, eine dynamische Gruppe und eine Policy-Anweisung eng zu definieren.

Obwohl sowohl RCLONE als auch OCIFS standardmäßige OCI-API-Schlüssel als Authentifizierungsmechanismus unterstützen, haben wir Instanz-Principals und dynamische Gruppen zur Authentifizierung ausgewählt. Dies verbessert die allgemeine Sicherheitslage - Schlüssel müssen nicht erstellt, verteilt oder rotiert werden. Stattdessen werden separate dynamische Gruppen verwendet, um die engsten Berechtigungen für jede dynamische Gruppe sicherzustellen. Beispiel: Das Zulassen der Bucket-Erstellung kann durch die Policy für die dynamische RCLONE-Gruppe zulässig sein, während für die dynamische Apache-Gruppe nur das Lesen von Objekten zulässig ist.

Überlegungen zu Archive Storage

Um Kosten zu sparen und die kostengünstigste Tier von OCI Object Storage zu nutzen, implementierte diese Lösung Lebenszyklusregeln, die Objekte in die seltene Tier und dann nach einem Zeitraum nach der Erstellung in die Archive Tier verschieben.

Nachdem die Objekte archiviert wurden, können sie nicht mehr direkt in die Standard-Tier klassifiziert werden. Aufgrund der Offlinebeschaffenheit von Archive Object Storage muss ein Prozess entwickelt werden, bei dem ein Audit (Geschäftsprozess) angefordert, bestimmte Dateien aus dem Archiv abgerufen und die Dateien dann für einen zeitgebundenen Zeitraum zugänglich werden.

Mit den inhärenten Features des Objektspeichers können Dateien vorübergehend abgerufen, in einen temporären Speicherort (einen anderen Bucket) kopiert und extern mit vorab authentifizierten Anforderungen (PARs) bereitgestellt werden. Dies sind obskure URLs (Sicherheit durch Dunkelheit), die den Zugriff auf bestimmte Dateien in einem Bucket ermöglichen und nach einer bestimmten Zeit ablaufen können, wodurch der Zugriff entzogen wird.

Während des Rückrufzeitraums können die Dateien in neue Standard-Tier-Buckets kopiert werden. Anschließend werden sie automatisch in den Archivierungsmodus zurückgesetzt, und es ist keine Wartung erforderlich. RCLONE und OCI-CLI, Java, REST oder Python können auf ähnliche Weise für die Hauptlösung verwendet werden, die wiederum Zugriff auf einen bestimmten Audit-Bucket erhält.