Deployment-Architekturoptionen
Beim ersten Provisioning werden alle Instanzen von Oracle Content Management auf Oracle Cloud Infrastructure bereitgestellt. Diese Architektur ist eine High-Availability-Topologie über mehrere Availability-Domains in einer geografischen Region hinweg. Sie nutzt Oracle Container Engine for Kubernetes (OKE) mit elastisch skalierbaren Kubernetes-Clustern über diese Availability-Domains hinweg.
- Availability-Domains: Bei einer Availability-Domain handelt es sich um mindestens ein Data Center innerhalb einer Region. Availability-Domains sind voneinander isoliert und fehlertolerant. Es ist sehr unwahrscheinlich, dass sie gleichzeitig ausfallen. Da Availability-Domains keine gemeinsame physische Infrastruktur haben, wie Stromversorgung oder Kühlung, und nicht das interne Availability-Domainnetzwerk teilen, hat ein Ausfall einer Availability-Domain wahrscheinlich keine Auswirkungen auf andere. Availability-Domains in einer Region sind über ein Netzwerk mit niedriger Latenz und hoher Bandbreite miteinander verbunden. Diese vorhersagbare, verschlüsselte Verbindung zwischen Availability-Domains stellt die Grundlage für High Availability und Disaster Recovery dar.
- Faultdomains: Eine Faultdomain ist eine Gruppierung aus Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain umfasst drei Faultdomains. Mit Faultdomains können Sie Ihre Instanzen so verteilen, dass sie sich nicht auf derselben physischen Hardware innerhalb einer Availability-Domain befinden. So haben Hardwareausfälle oder Wartungsereignisse, die sich auf eine Faultdomain auswirken, keine Auswirkungen auf Instanzen in anderen Faultdomains. Sie können optional die Faultdomain für eine neue Instanz zur Startzeit angeben oder das System eine für Sie auswählen lassen.
In einem Standard-Deployment erstellt OKE automatisch mehrere Cluster (oder Knoten) auf mehreren Availability-Domains. Alle Sites und Assets werden mit jeder Availability-Domain synchronisiert. Wenn eine Availability-Domain ausfällt, leitet OKE automatisch den gesamten eingehenden Traffic zu den funktionsfähigen Availability-Domains um. So bemerken Endbenutzer Serviceausfälle nicht, während die nicht erfolgreiche Availability-Domain wiederhergestellt wird.
Wir empfehlen die Verwendung der Option Upgradezeitplan, um zu steuern, wann Ihre Instanz ein neues Release von Oracle Content Management erhält. In den meisten Fällen sollten Instanzen, die Produktionstraffic verarbeiten, die Option Verzögertes Upgrade verwenden. Instanzen für Entwicklungs- und Testzwecke sollten die Option Upgrade sofort ausführen verwenden. Mit dieser Kombination aus Einstellungen erhalten Sie einen vollständigen Releasezyklus, der sicherstellt, dass Ihr Code robust ist und Sie ausreichend Zeit zum Beheben von Problemen haben, bevor diese sich auf Ihren Produktionstraffic auswirken. Die Option "Upgradezeitplan" wird festgelegt, wenn Sie Ihre Oracle Content Management-Instanz erstellen.
Natives Disaster Recovery in Oracle Content Management
Oracle Content Management stellt eine native Produktoption für Disaster Recovery bereit. Die Oracle Content Management-Produktfunktion für Disaster Recovery bietet im Wesentlichen eine Full-Stack-Orchestrierung des Service, der umfassende Disaster Recovery Failover-Funktionen für alle Schichten des Oracle Content Management-Anwendungsstacks enthält, einschließlich der Oracle Content Management-Anwendungsebenen, der Datenbank, des Suchindex und des Objektspeichers.
Die Begriffe "Oracle Content Management Full-Stack-Disaster Recovery", "Full-Stack-Disaster Recovery" und "Disaster Recovery" werden in dieser Dokumentation synonym verwendet. Alle Begriffe beziehen sich auf denselben Service.
Die Full-Stack-Disaster Recovery gewährleistet eine umfassende Geschäftskontinuität bei verschiedenen Data-Center-Ausfällen, um sicherzustellen, dass Organisationen nur einen geringen Einfluss auf regionale Ausfälle haben.
Das Disaster Recovery von Oracle Content Management ist für Ihre Oracle Content Management-Instanz einfach als Add-on-Produktserviceoption aktiviert. Sie können Oracle Content Management-fähige Disaster-Recovery-Instanzen über Vorgänge in der Oracle Cloud-Konsole aktiv überwachen. Sie können auch die Verfügbarkeit und Compliance der Geschäftskontinuität validieren und überwachen, indem Sie regelmäßig Switchover-Tests für Disaster Recovery ausführen.
Vorteile von Oracle Content Management Disaster Recovery
Oracle Content Management Disaster Recovery bietet mehrere Vorteile im Bereich der Geschäftskontinuität.
- Vollständiges Anwendungs-Recovery: Das Oracle Content Management-Disaster Recovery stellt ein Recovery für den gesamten Anwendungsstack bereit, der die Komponenten wie Datenbank, Suchindizes, Objektspeicher und Anwendungsebene umfasst. Dieses Full-Stack-Disaster Recovery ermöglicht eine Geschäftskontinuität, die von der Wiederherstellung des gesamten Anwendungsstacks und nicht von wenigen ausgewählten Komponenten abhängt.
- Minimiert die Disaster Recovery-Zeit: Mit dem Oracle Content Management-Disaster Recovery müssen Sie kein manuelles Disaster Recovery für einzelne Ressourcen durchführen.
- Es sind keine besonderen Kenntnisse erforderlich: Operatoren und Administratoren benötigen keine besonderen Kenntnisse oder Fachkenntnisse in Bereichen wie Anwendungen und Speicherreplikation.
- Einzelne Überwachung und Verwaltung von Glas: Das Oracle Content Management-Disaster Recovery bietet eine zentrale Überwachung und Verwaltung für alle Instanzen, die für Oracle Content Management Disaster Recovery aktiviert sind. Sie können Disaster-Recovery-Instanzen erstellen, die Disaster-Recovery-Bereitschaft überwachen und den Status mit der Oracle Cloud-Konsole prüfen.
Disaster Recovery - Terminologie und Konzepte
Bevor Sie Oracle Content Management Disaster Recovery verwenden, machen Sie sich mit den folgenden Schlüsselbegriffen und -konzepten vertraut.
- Disaster Recovery (DR) - Der Prozess zum Wiederherstellen einiger oder aller Teile eines Geschäftssystems (ein Service) nach einem Ausfall. Die Wiederherstellung dieses Geschäftssystems erfolgt über Data Center innerhalb desselben lokalisierten geografischen Bereichs.
- Vollständiger Stack - Ein Begriff, mit dem alle Funktionsschichten eines Geschäftssystems, einer Anwendung oder eines Softwareservice gemeinsam bezeichnet werden. Eine Anwendung kann aus verschiedenen Funktionsschichten oder -ebenen wie Anwendungsschicht, Middleware-Schicht, Datenbankschicht und Infrastrukturschicht bestehen.
- Recovery Point Objective (RPO) - Das RPO definiert den maximalen Datenverlust, der im Rahmen der DR-Wiederherstellung toleriert werden kann. Das RPO wird normalerweise in Zeiteinheiten ausgedrückt.
- Recovery Time Objective (RTO): Das RTO definiert, wie lange die Anwendung oder der Service unter DR-Schutz maximal nicht verfügbar sein kann, bis der Service wiederhergestellt wird. Das RTO wird normalerweise in Zeiteinheiten ausgedrückt.
- Primär: Die Produktionsversion einer Anwendung oder eines Service, die derzeit verwendet wird. Disaster Recovery bezeichnet die primäre Version einer Anwendung als primäre Rolle.
- Standby: Die reservierte Version einer Anwendung oder eines Service. Mit Standby wird auch die alternative Region referenziert, in der die Anwendung oder der Service wiederhergestellt wird. Disaster Recovery bezeichnet die Standby-Version einer Anwendung als Standby-Rolle.
- Warm Standby - Ein DR-Modell, bei dem einige oder alle Komponenten einer Anwendung oder eines Service in der Standbyregion vorab bereitgestellt werden, um sich auf einen zukünftigen DR-Übergang vorzubereiten. Dieses Modell bringt höhere Betriebskosten, aber ein niedrigeres RTO mit sich. Oracle Content Management DR-Support verwendet eine warme Standbyimplementierung.
- Cold Standby - Ein DR-Modell, bei dem nur wenige oder keine der Komponenten einer Anwendung oder eines Service in der Standbyregion vorab bereitgestellt werden müssen, um einen zukünftigen DR-Übergang vorzubereiten. Die Anwendungskomponenten werden im Rahmen des DR-Übergangs bereitgestellt. Dieses Modell bringt niedrigere Betriebskosten, aber ein höheres RTO mit sich.
- Rolle - Gibt an, ob eine Anwendung und ihre Region derzeit die primäre (Produktions-)Version oder die reservierte Standbyversion sind. Die Rolle einer Anwendung und ihre Region ändert sich aufgrund eines DR-Übergangs.
- Verknüpfung: Eine Paarbeziehung, die zwischen zwei Oracle Content Management-Instanzen definiert ist. Eine Oracle Content Management DR-fähige Instanz ist in einer Primär- und Standby-Beziehung verknüpft (gepaart), bevor sie zur Implementierung von DR-Services verwendet werden kann.
- Switchover: Bei Oracle Content Management ist dies ein geplantes DR-Ereignis, das einen geplanten Übergang von Oracle Content Management von der primären DR-Instanz zur Standby-DR-Instanz ausführt. Beim Switchover wird ein geordneter Übergang ausgeführt, indem der Anwendungs-Stack in der primären Region heruntergefahren und dann der Standby-Service aktiviert wird, damit er aktiv wird.
- Failover: Bei Oracle Content Management wäre dies ein ungeplantes Ereignis, bei dem Oracle einen Failover-Übergang durchführen muss, indem die warme Standbyinstanz von Oracle Content Management in der Standbyregion aktiviert wird, falls ein Serviceausfall in der primären Region auftritt.
Failover-Recovery-Prozess
Oracle steuert, wann das Failover für Ihren Oracle Content Management-Service aktiviert wird. Für Oracle Content Management lauten die Performanceziele für das Disaster Recovery wie folgt:
- Recovery Time Objective (RTO) = eine Stunde: Das RTO ist die Zielzeit, die erforderlich ist, um die Funktionalität einer Anwendung nach einem Ausfall wiederherzustellen.
RTO ist das Ziel von Oracle für den maximalen Zeitraum zwischen der Entscheidung von Oracle, die Disaster Recovery-Prozesse zu aktivieren, und dem Zeitpunkt, an dem Sie die Produktionsvorgänge an einem alternativen Standort wiederaufnehmen können. Wenn die Entscheidung zur Aktivierung von Disaster Recovery-Prozessen während des Zeitraums getroffen wird, in dem ein Upgrade ausgeführt wird, nimmt das RTO die Zeit auf, die für den Abschluss des Upgrades erforderlich ist.
- Recovery Point Objective (RPO) = eine Stunde - Das RPO ist der Zielzeitrahmen von verlorenen Daten von Oracle, den Ihre Anwendungen bei einem Failover-Ereignis potenziell verlieren können.
Das Ziel von Oracle für den maximalen Zeitraum des Datenverlusts, gemessen als der Zeitpunkt, zu dem die erste Transaktion verloren geht, bis zur Erklärung von Oracle zur Katastrophe. Das RPO gilt nicht für Dataloads, die im Notfall ausgeführt werden.
Switchover-Testprozess
Mit Oracle können Kunden ein Switchover ihrer Instanzen mit Oracle Content Management-Disaster Recovery testen. Um Switchover zu testen, protokollieren Sie eine Serviceanfrage für Ihre Oracle Content Management-Instanz, und das Oracle-Supportteam arbeitet zur Planung des Tests.
Disaster Recovery implementieren
Um Disaster Recovery zu implementieren, müssen Sie beim Erstellen einer Oracle Content Management-Instanz die folgenden Optionen auswählen:
- Advanced Hosting - Sie müssen die Lizenzoption Advanced Hosting aktivieren. Das erweiterte Hosting ermöglicht eine dedizierte autonome Transaktionsverarbeitungs-(ATP-)Datenbank, die zur Unterstützung des Disaster Recovery-Features von Oracle Content Management erforderlich ist. Das erweiterte Hosting ist eine optionale Funktion, die Sie beim Erstellen einer Oracle Content Management-Instanz mit einer Premium-Edition- oder BYOL-Lizenz hinzufügen können. Für diese Option fallen zusätzliche Fakturierungsgebühren an. Weitere Kosten finden Sie in Ihrem vorausbezahlten Abonnementvertrag oder Ihrem Universal-Credits-Vertrag.
- Disaster Recovery - Unter "Erweiterte Optionen" müssen Sie die Option Disaster Recovery aktivieren. Disaster Recovery ist ein optionales Feature, das Sie beim Erstellen einer Oracle Content Management-Instanz mit einer Premium-Edition- oder BYOL-Lizenz hinzufügen können.
Nur neue Instanzen - Disaster Recovery kann nur für neue, nicht vorhandene Instanzen aktiviert werden.
Data Center-Unterstützung für Disaster Recovery
Die Unterstützung für Disaster Recovery ist in den folgenden Oracle Content Management-Data-Center-Kombinationen verfügbar:
| Primäre Region | Standby-Region |
|---|---|
| Ashburn | Phoenix |
| Phoenix | Ashburn |
| Provinz | Phoenix |
| Toronto | Montreal |
| Montreal | Toronto |
| Tokio | Osaka |
| Osaka | Tokio |
| Mumbai | Hyderabad |
| Hyderabad | Mumbai |
| Frankfurt | Amsterdam |
| Amsterdam | Frankfurt |
| Seoul | Chuncheon |
| Chuncheon | Seoul |
| Dubai | Abu Dhabi |
| Abu Dhabi | Dubai |
| Sydney | Melbourne |
| Melbourne | Sydney |
| - Paulo | Vinhedo |
| Vinhedo | - Paulo |
| Santiago | - Paulo |
| Zürich | Stockholms |
| Stockholms | Zürich |
| Cardiff | London |
| London | Cardiff |
| Singapur | Hyderabad |
| Jeddah | Abu Dhabi |
| Johannesburg | Bezirk Jerusalem |
| Bezirk Jerusalem | Johannesburg |
| Mailand | Marseille |
| Marseille | Mailand |
| Paris (Zukunft) | Madrid (Zukunft) |
| Neom (Zukunft) | Jeddah |
| Queretaro (Zukunft) | Santiago |
| Chicago (Zukunft) | Ashburn |
| Madrid (Zukunft) | Paris (Zukunft) |
Mehr Verfügbarkeit
Während ein High-Availability-Service hohe Betriebszeit und Verfügbarkeit liefert, haben viele Kunden zusätzliche Anforderungen, die mit unterschiedlichen Architekturen erfüllt werden können. Diese zusätzlichen Architekturen profitieren weiterhin von der High Availability, die out-of-the-box von Oracle Cloud Infrastructure und OKE bereitgestellt wird, und können zudem Entwicklungsprozesse oder sogar regionsübergreifenden Failover unterstützen oder durch leistungsstarke private Verbindungen ergänzt werden. Um die richtige Architektur für Ihre Anforderungen zu finden, müssen Sie die erforderlichen Entwicklungsprozesse Ihrer Organisation, Ihre akzeptablen Recovery Time Objectives (RTO) und Ihre Recovery Point Objectives (RPO) bestimmen.
Private Instanz mit Oracle Cloud Infrastructure FastConnect
Einige Kunden benötigen unter Umständen zusätzliche Performance- oder Sicherheitsfunktionen, die über das öffentliche Internet nicht verfügbar sind. Mit Oracle Cloud Infrastructure FastConnect erhalten Sie eine leistungsstärkere, robustere und sichere Verbindung zu Ihrer Oracle Content Management-Instanz. Dieser Verbindungstyp wird oft von Kunden genutzt, die den Zugriff auf interne Netzwerke einschränken oder sicherstellen möchten, dass Endbenutzer eine optimale und zuverlässige Verbindung erhalten.
Wenn Sie eine solche Instanz erstellen möchten, müssen Sie Oracle Cloud Infrastructure FastConnect einrichten und einige zusätzliche Vorbereitungsschritte ausführen. FastConnect bietet im Vergleich zu internetbasierten Verbindungen eine dedizierte private Verbindung mit höherer Bandbreite und eine zuverlässigere und konsistentere Netzwerkerfahrung.
Siehe Private Instanz mit FastConnect erstellen.
Entwicklungsprozess
Dies ist der Prozess, mit dem Ihre Organisation neue Funktionen und Inhalte für Oracle Content Management entwickelt und bereitstellt. Er kann mehrere Umgebungen umfassen, die neue Funktionen und Inhalte durchlaufen müssen, bevor sie für übergeordnete Umgebungen und die Produktion genehmigt werden. Ein gängiges Setup umfasst Umgebungen für Entwicklung, Tests, Staging und schließlich Produktion. Die genauen Anforderungen hängen von Ihrer Organisation ab.
Kunden, die ihre Entwicklungsprozesse mit mehreren Instanzen unterstützen möchten, sollten die zusätzlichen Instanzen wie in diesem Dokument beschrieben bereitstellen. Sie müssen jedoch keine Web Application Firewall (WAF) davor bereitstellen, da direkt auf diese Instanzen zugegriffen wird. Nach der Entwicklung von Inhalt in einer Ihrer Instanzen können Sie die Befehlszeilenschnittstelle (CLI) von Oracle Content Management Toolkit verwenden, um diesen Inhalt von einer Oracle Content Management-Instanz zu einer anderen zu propagieren.
Wenn Sie eine zusätzliche Instanz erstellen, die keinen Produktionstraffic verarbeitet, müssen Sie diese als nicht primär markieren, damit Sie nicht für doppelte Assets bezahlen. Bei primären Instanzen wird die Gesamtanzahl der enthaltenen Assets in Rechnung gestellt. Bei nicht primären Assets wird ein einzelner Block von Assets pro Monat in Rechnung gestellt (z.B. 5.000 Assets und mit Video Plus 250 Video Plus-Assets), unabhängig davon, wie viele Assets insgesamt repliziert werden. Weitere Informationen finden Sie unter Servicebeschreibungen für Oracle PaaS und IaaS Universal Credits.
Bei der Propagierung von Änderungen können Sie Oracle Content Management Toolkit-Befehle verwenden, um Sites zu erstellen und deren Lebenszyklen auf Entwicklungs-, Test- und Produktionsservern zu verwalten. Sie können Änderungen an Sites in einer Entwicklungsumgebung vornehmen und diese Änderungen zu Test- und Produktionsumgebungen propagieren. Sie können dieses Set aus Befehlszeilenutilitys auch in Ihre Scripting-Umgebungen integrieren, um Deployments zu verwalten. Mit den CLI-Utilitys können Sie neue Elemente wie Assets und Komponenten einführen sowie vorhandenen Inhalt aktualisieren.