Migrierte MongoDB-Workload in Oracle Autonomous Transaction Processing Serverless@Azure bereitstellen
Workloads und Anwendungen, die Dokumente und Dokumentdatenbanken verwenden, um Datenschemas und Anwendungen zu entwickeln, sind aufgrund der Flexibilität, die sie Entwicklern bieten, beliebt. Die Flexibilität des Schemas, die schnelle Entwicklung und die Skalierbarkeit ermöglichen ein beschleunigtes Prototyping von Anwendungsfunktionen, eine einfachere Anwendungsentwicklung und die Möglichkeit, iterativ kleinere Anwendungen und Funktionen zu erstellen, die Entwickler skalieren können, um eine große Benutzerbasis zu erreichen. Diese Arten von Workloads haben jedoch ihre Herausforderungen, darunter schwächere Transaktionsgarantien, Vielseitigkeit der Datenabfrage und die Unfähigkeit, andere Workloads in Dokumenten wie Analysen oder maschinelles Lernen zu unterstützen.
Was ist, wenn diese Workloads von den Vorteilen herkömmlicher Dokumentendatenbanken profitieren und die Vorteile relationaler Datenbanken nutzen können? Sie verfügen beispielsweise über stärkere Transaktionsgarantien und zusätzliche Funktionen wie Analysen und maschinelles Lernen, ohne dass Daten in eine andere Datenbank oder ein anderes System repliziert werden müssen.
Autonomous Transaction Processing (ATP) Serverless ist ein vollständig automatisierter Datenbankservice, der für die gleichzeitige Ausführung von Transaktions-, Analyse- und Batch-Workloads optimiert ist. Um die Performance zu beschleunigen, ist es für Zeilenformat, Indizes und Daten-Caching vorkonfiguriert und bietet gleichzeitig Skalierbarkeit, Verfügbarkeit, transparente Sicherheit und Betriebsanalysen in Echtzeit. Anwendungsentwickler und DBAs können Anwendungen schnell und kostengünstig entwickeln und bereitstellen, ohne dabei auf Funktionalität oder Atomizität, Konsistenz, Isolation und Dauerhaftigkeit (ACID) verzichten zu müssen.
Funktionale Architektur
Diese Architektur setzt als Ausgangspunkt voraus, dass eine Workload mit einer Anwendung und einer MongoDB-Datenbank vorhanden ist, entweder ein On-Premise- oder ein Cloud-Deployment, und zu Azure und Oracle Database@Azure migriert wird. Es beschreibt die zukünftige Statusarchitektur, ihre Vorteile, wie sie bereitgestellt werden kann und welche zusätzlichen Funktionen Sie zur Erweiterung der vorhandenen Workload verwenden können.
Eines der wichtigsten Features in dieser Architektur ist die Oracle Database API for MongoDB, mit der Anwendungen mit Sammlungen von JSON-Dokumenten in Oracle Database mit MongoDB-Treibern, -Tools und -SDKs interagieren können. Vorhandener Anwendungscode kann mit Daten arbeiten, die in Oracle Autonomous Transaction Processing Serverless gespeichert sind, ohne dass Code umgestaltet werden muss.
Das folgende Diagramm zeigt eine typische Anwendung, die sich aus einer Datenbank-, Backend- und Frontend-Ebene zusammensetzt.
mongodb-atp-s-azure-logical-arch-migration.zip
Der MEAN-Stack ist ein beliebter Stack, mit dem dieses Muster implementiert wird:
- MongoDB: Dokumentdatenbank
- Express: Backend-Framework
- Winkel: Frontend-Rahmen
Node.js: Backend-Server
In diesem Dokument wird ein MEAN-Stack als Beispiel für ein vorhandenes Deployment verwendet, das zu Azure und ATP Serverless migriert wird.
Die Migration dieser Workload zu Azure und ATP Serverless ist unkompliziert und umfasst auf hoher Ebene die folgenden Schritte:
- Stellen Sie eine ATP Serverless-Instanz bereit, und aktivieren Sie beim Erstellen die Oracle Database-API MongoDB.
- Migrieren Sie Metadaten und Daten von MongoDB zu ATP Serverless.
- Stellen Sie Anwendungsserver bereit, um
Node.jsund Express mit Azure App Service, VMs, Containern oder Kubernetes in derselben Region und Availability-Domain wie ATP Serverless auszuführen. - Stellen Sie den Backend-Anwendungscode auf den Anwendungsservern bereit.
- Verbinden Sie die Backend-Anwendung mit ATP Serverless, indem Sie dieselben MongoDB-Tools und -Treiber verwenden, die in der aktuellen Anwendung verwendet werden.
- Verbinden Sie Benutzer mit der neuen Anwendungs-URI.
Diese Referenzarchitektur konzentriert sich auf das Deployment der migrierten Workload und nicht auf den Migrationsprozess selbst. Weitere Informationen zum Migrationsprozess finden Sie im Abschnitt Weitere Informationen.
Nachdem die Workload zu ATP Serverless migriert wurde, stehen mehrere Funktionen zur Verfügung, um die vorhandene Funktionalität zu erweitern, unabhängig davon, ob dies 1) zusätzliche nicht funktionale Anforderungen unterstützt, wie die einfache Verbesserung der Skalierbarkeit, Resilienz oder Hochverfügbarkeit, oder 2) zusätzliche funktionale Funktionen wie Betriebsberichte, Analysen und maschinelles Lernen haben, ohne Daten aus der Datenbank kopieren zu müssen.
Um die Skalierbarkeit und High Availability zu verbessern, verwenden Sie das serverlose Autoscaling-Feature von Autonomous Transaction Processing. Mit einem einzigen Klick oder API-Aufruf kann die Workload bis zum 3-fachen der Basiskapazität ohne Ausfallzeiten nutzen. Beachten Sie, dass Autonomous Transaction Processing Serverless die Oracle Real Application Clusters-(Oracle RAC-)Technologie für High Availability verwendet. Verwenden Sie für die Backend-Tier entweder Azure-VM-Skalierungssets mit Autoscaling-Setup oder einen PaaS-Service, wie App Service mit automatischer Skalierung, um High Availability und Skalierbarkeit der Anwendung zu ermöglichen.
Da ATP Serverless auf Multi-Modell-, Multi-Workload-Datenbanktechnologie basiert, können Sie Funktionen hinzufügen, die auf relationalen, räumlichen, Diagramm- oder Vektordatentypen basieren, die neben der vorhandenen Anwendung funktionieren.
Physische Architektur
Die physische Architektur umfasst Autonomous Transaction Processing Serverless, das mit delegierten Subnetzen in zwei Azure-Regionen bereitgestellt wird, um High Availability zu unterstützen. OCI-Services unterstützen automatisches Backup in Oracle Cloud Infrastructure Object Storage.
Die Architektur unterstützt Folgendes:
- Frontend-Tier
- Anwendungsbenutzer können über das Internet oder das Unternehmensnetzwerk eine Verbindung herstellen.
- Die Benutzerverbindung wird über Azure Front Door an die aktive Region weitergeleitet, in der die Anwendung ausgeführt wird.
- Die Benutzerverbindung wird mit der Azure-Web Application Firewall gesichert.
- Die Benutzerverbindung zur Anwendung wird mit dem App-Service ausgeglichen.
- Backend-Tier
- Die Anwendung wird mit dem Azure-App-Service hochverfügbar bereitgestellt.
- Azure App Service AutoScale wird verwendet, um eine horizontale Skalierbarkeit zu erreichen.
- Datenbankebene
- ATP Serverless bietet High Availability, da Oracle Real Application Clusters (Oracle RAC) und mehrere Datenbankknoten die Serviceinstanz untermauern. Daher ist die Datenbankebene standardmäßig hochverfügbar und resilient.
- Mit der in ATP Serverless aktivierten Oracle Database API for MongoDB können Sie vorhandenen Anwendungscode ohne Änderungen verwenden.
- Die Oracle Database API for MongoDB ist äußerst resilient und die Resilienz wird intern von ATP Serverless garantiert.
- ATP Serverless kann die automatische Skalierung verwenden, um die Systemlast zu erhöhen und zu verringern.
- ATP Serverless-Geschäftskontinuität wird durch regionsübergreifendes Autonomous Data Guard erreicht.
- Disaster Recovery
- Die zweite Region wird mit einer ähnlichen Topologie bereitgestellt, um das Gesamtziel für die Recovery-Zeit zu reduzieren.
- Verwenden Sie eine warme DR-Strategie, um das gesamte RTO zu reduzieren. In einer Warm-DR-Strategie werden die Cloud-Ressourcen der Backend-Ebene bereits zusammen mit der ATP Serverless-Standbydatenbank bereitgestellt.
- Alternativ können Sie die Backend-Tierressourcen im Falle eines Fehlers bereitstellen. Dadurch werden die Kosten für die Ausführung der DR-Ressourcen gesenkt, aber das RTO insgesamt erhöht.
- Networking
- Der gesamte eingehende Datenverkehr der Anwendung von On-Premises und aus dem Internet wird von Azure Front Door geleitet.
- ATP Serverless wird mit einem privaten Endpunkt bereitgestellt, um den Sicherheitsstatus zu erhöhen.
- Azure App Service Web App wird mit einem Integrationssubnetz und VNet bereitgestellt, um die ATP Serverless-Instanz zu erreichen.
- Die Anwendung VNet wird mit der Datenbank VNet per Peering verbunden, und Traffic kann zwischen der Webanwendung und dem ATP-Serverless fließen.
- Sicherheit
- Alle Daten sind während der Übertragung und im Ruhezustand sicher.
Die folgenden potenziellen Konstruktionsverbesserungen sind in diesem Deployment aus Gründen der Einfachheit nicht dargestellt:
- Automatisieren Sie die Anwendungs-Disaster Recovery mit Azure Automation-Runbooks, um Front Door-Endpunkte zu wechseln und den Zustand der Post-Failover-App zu validieren.
- Nutzen Sie eine Hub- und Spoke-Topologie, um eine zentrale Netzwerksicherheit durchzusetzen.
- Nutzen Sie eine Netzwerkfirewall, die im Hub VNet bereitgestellt wird, um den allgemeinen Sicherheitsstatus zu verbessern, indem Sie den gesamten Traffic prüfen und Policys durchsetzen.
mongodb-atp-s-azure-physical-arch.zip
Die Architektur enthält die folgenden Microsoft-Komponenten:
- Azure-Firewallmanager
Azure Firewall Manager ist ein zentralisierter Sicherheitsverwaltungsservice, der die Bereitstellung und Konfiguration der Azure Firewall über mehrere Regionen und Abonnements hinweg vereinfacht. Es ermöglicht hierarchisches Policy-Management, sodass globale und lokale Firewall-Policys konsistent angewendet werden können. Wenn Azure Virtual WAN (vWAN) und ein sicherer Hub integriert sind, verbessert Azure Firewall Manager die Sicherheit, indem es das Traffic-Routing und die Filterung automatisiert, ohne dass benutzerdefinierte Routen erforderlich sind. Durch diese Integration wird sichergestellt, dass der Datenverkehr zwischen virtuellen Netzwerken, Niederlassungen und dem Internet sicher verwaltet und überwacht wird. Dies bietet eine robuste und optimierte Netzwerksicherheitslösung.
- Azure-Vordertür
Azure Front Door ist ein cloudbasierter Service, der als globaler Einstiegspunkt für Webanwendungen fungiert und leistungsstarke Inhaltsbereitstellung, intelligentes Layer-7-Load Balancing sowie integrierte Sicherheitsfunktionen wie Web Application Firewall (WAF) und DDoS-Schutz bietet, um eine schnelle, zuverlässige und sichere Benutzererfahrung zu gewährleisten.
- Azure-Region
Eine Azure-Region ist ein geografischer Bereich, in dem sich mindestens ein physisches Azure-Data Center, die sogenannten Availability Zones, befindet. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können über Länder oder Kontinente voneinander getrennt werden.
Azure- und OCI-Regionen sind lokalisierte geografische Gebiete. Bei Oracle Database@Azure ist eine Azure-Region mit einer OCI-Region verbunden, wobei Availability Zones (AZs) in Azure mit Availability-Domains (ADs) in OCI verbunden sind. Azure- und OCI-Regionspaare werden ausgewählt, um Entfernung und Latenz zu minimieren.
- Azure-Verfügbarkeitszone
Azure-Verfügbarkeitszonen sind physisch getrennte Standorte innerhalb einer Azure-Region, die durch unabhängige Stromversorgung, Kühlung und Vernetzung eine hohe Verfügbarkeit und Resilienz gewährleisten.
- Virtuelles Azure-Netzwerk (VNet)
Azure Virtual Network (VNet) ist der grundlegende Baustein für Ihr privates Netzwerk in Azure. Mit VNet können viele Arten von Azure-Ressourcen, wie z. B. virtuelle Azure-Maschinen (VMs), sicher miteinander, mit dem Internet und On-Premises-Netzwerken kommunizieren.
- Microsoft Azure-App-Service
Mit Microsoft Azure App Service können Sie Webanwendungen, APIs und mobile Backends erstellen, hosten und skalieren, ohne die zugrunde liegende Infrastruktur zu verwalten.
- Azure App Service-Integrationssubnetz
Ein dediziertes Subnetz in einem virtuellen Azure-Netzwerk, das speziell für die Verwendung durch App Service-Pläne delegiert wird. Dadurch können Webanwendungen ausgehende Verbindungen zu privaten Ressourcen innerhalb des virtuellen Netzwerks oder seiner Peer-Netzwerke herstellen, aber keinen eingehenden Traffic von der VNet empfangen.
- Delegiertes Azure-Subnetz
Mit einem delegierten Subnetz können Sie einen verwalteten Service, insbesondere einen Platform-as-a-Service-(PaaS-)Service, direkt als Ressource in Ihr virtuelles Netzwerk einfügen. Sie haben die vollständige Integrationsverwaltung externer PaaS-Services in Ihren virtuellen Netzwerken.
Die Architektur umfasst die folgenden Oracle-Komponenten:
- OCI-region
Eine OCI-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Centre enthält, das Availability-Domains hostet. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können über Länder oder Kontinente voneinander getrennt werden.
- Oracle Autonomous Database
Oracle Autonomous Database ist eine vollständig verwaltete, vorkonfigurierte Datenbankumgebung, die Sie für Transaktionsverarbeitungs- und Data Warehousing-Workloads verwenden können. Sie müssen weder Hardware konfigurieren oder verwalten noch Software installieren. OCI übernimmt das Erstellen, Sichern, Patchen, Upgraden und Optimieren der Datenbank.
- Oracle Autonomous Data Guard
Mit Oracle Autonomous Data Guard kann eine Standbydatenbank (Peerdatenbank) Datenschutz und Disaster Recovery für Ihre Autonomous Database-Instanz bereitstellen. Es bietet zahlreiche Services, die eine oder mehrere Standbydatenbanken erstellen, verwalten und überwachen, damit Oracle-Produktionsdatenbanken ohne Unterbrechung verfügbar bleiben können. Oracle Data Guard verwaltet diese Standbydatenbanken als Kopien der Produktionsdatenbank. Wenn die Produktionsdatenbank aufgrund eines geplanten oder ungeplanten Ausfalls nicht mehr verfügbar ist, können Sie jede Standbydatenbank auf die Produktionsrolle umstellen und so die mit dem Ausfall verbundenen Ausfallzeiten minimieren.
- OCI Object Storage
Mit OCI Object Storage können Sie 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 sicher direkt aus Anwendungen oder aus der Cloud-Plattform speichern. Sie können den Storage skalieren, ohne dass die Performance oder Servicezuverlässigkeit beeinträchtigt wird.
Verwenden Sie den Standardspeicher für "Hot Storage", auf die Sie schnell, sofort und häufig zugreifen müssen. Verwenden Sie Archivspeicherung für "Cold Storage", die Sie über lange Zeiträume beibehalten und nur selten darauf zugreifen.
- Privater OCI-Endpunkt
OCI Private Endpoint bietet kostenlosen, privaten und sicheren Zugriff auf einen von vielen OCI-Services über ein virtuelles Cloud-Netzwerk (VCN) oder ein On-Premise-Netzwerk.
Architekturvariante
Diese Variante der vorgeschlagenen physischen Architektur verwendet ein vom Kunden verwaltetes Oracle REST Data Services-Deployment, das auf jedem Anwendungsserver ausgeführt wird. Die vollständig verwaltete MongoDB-API, die von ATP Serverless bereitgestellt wird, ist jedoch die beste Lösung für die meisten Workloads, da sie einfacher zu verwalten ist.
Wenn die Konfiguration und Verwaltung von Oracle REST Data Services manuell gesteuert werden muss, ist die Verwendung von vom Kunden verwalteten Oracle REST Data Services eine Option. Beispiel: Damit die Anwendung größere Connection Pools verwenden kann.
Hinweis:
Verwenden Sie diese Architekturvariante, wenn dafür eine bestimmte Workload erforderlich ist. Nur fortgeschrittene Benutzer sollten diese Architekturvariante bereitstellen.In diesem Abschnitt werden nur die Unterschiede zur zuvor beschriebenen physischen Architektur beschrieben. Daher sind alle Prinzipien des physischen Architekturdesigns gültig, sofern nicht anders angegeben.
Das folgende Architekturdiagramm zeigt, wie die Variante bereitgestellt wird. Der Einfachheit halber werden nur die im JSON-Workload-VCN bereitgestellten Cloud-Ressourcen dargestellt, da der Rest des Deployments mit der zuvor beschriebenen physischen Architektur identisch ist.
mongodb-atp-s-azure-arch-variant.zip
- Die eingehenden Benutzeranforderungen werden vom App Service Load Balancer verteilt, sodass die Frontend-Tier horizontal skalierbar ist und keinen Single Point of Failure aufweist.
- Die Backend-Anwendung wird in den Workern der App Service Scale Unit bereitgestellt.
- Die Anwendung wird mit dem Container als Veröffentlichungsmethode bereitgestellt.
- Erstellen, installieren und konfigurieren Sie den Container mit der Anwendung und Oracle REST Data Services, sodass beide in demselben Container ausgeführt werden können.
- Jeder Worker führt das Containerimage aus, das die Anwendung und Oracle REST Data Services in derselben Laufzeitumgebung kolokalisiert.
- Vom Kunden verwaltete Oracle REST Data Services-Worker sind so konfiguriert, dass die MongoDB-API aktiviert wird, sodass die Anwendung mit MongoDB-Tools und -Treibern eine Verbindung zur Datenbank herstellen kann.
- Vom Kunden verwaltete Oracle REST Data Services sind so konfiguriert, dass sie an die nicht funktionalen Workload-Anforderungen angepasst werden, z.B. durch die Konfiguration größerer Verbindungspools oder die Verwendung eines anderen Datenbankservice.
- Sowohl der Backend-Code als auch die vom Kunden verwalteten Oracle REST Data Services sind im Containerimage vorinstalliert und vorkonfiguriert, das für die Worker verwendet wird. Wenn App Service horizontal skaliert wird, können neue Worker die Backend-Anwendung ausführen und nach dem Provisioning eine Verbindung zur Datenbank herstellen.
Empfehlungen
- Anwendungs-Deployment
- Sie sollten ein containerbasiertes Deployment mit Azure Kubernetes Service (AKS) verwenden, wenn Sie erweiterte Orchestrierungs-, Netzwerk- und Sicherheitsfunktionen benötigen, die möglicherweise nicht in App Service verfügbar sind.
- Sicherheit
- Verwenden Sie Oracle Data Safe, um den Sicherheitsstatus der Workload weiter zu erhöhen und Datenbankauditing auszuführen.
- Beobachtbarkeit
- Verwenden Sie Azure Monitor, um Serverless-Metriken von ATP neben allen anderen Überwachungsdaten von Azure-Diensten zu überwachen.
- Disaster Recovery
- Erwägen Sie die Automatisierung und Orchestrierung der Disaster- und Recovery-Vorgänge für alle Ebenen des Stacks mit Azure Site Recovery oder benutzerdefinierten Skripten, die Fehler erkennen und Failover-Prozesse auslösen.
- Betriebliche Effizienz
- Wenn die ATP Serverless-Workload Teil einer größeren Datenbankflotte ist, sollten Sie Elastic Pools verwenden, um die Kosteneffizienz zu erhöhen.
- Sie sollten Oracle Cloud Infrastructure Database Management aktivieren, einen OCI-Service, der umfassende Features zur Überwachung und Verwaltung der Datenbankperformance bereitstellt, um die Verwaltung der ATP Serverless-Instanz zu optimieren.
- Anwendungsentwicklung
- Erwägen Sie die Bereitstellung von Betriebsanalysen und Echtzeitberichten in ATP Serverless mit SQL und einem Frontend wie APEX oder PowerBI, ohne Daten aus der Datenbank zu verschieben, für eine vertrauenswürdige und Echtzeitdatenanalyse
- Ziehen Sie in Betracht, ATP Serverless für maschinelles Lernen mit Oracle Machine Learning (OML) zu verwenden, um Modelle mit JSON-Daten zu erstellen und zu trainieren, ohne dass Daten verschoben werden müssen, und die Modelle neben der vorhandenen Workload bereitzustellen, um eine effiziente Inferenzierung zu ermöglichen.
- Für zusätzliche Anwendungsfälle, die über den Anwendungskern hinausgehen, sollten Sie ATP Serverless Select AI und Datenbankansichten verwenden, die JSON abfragen und Metadaten speichern, damit Benutzer JSON-Daten in natürlicher Sprache abfragen können.
- Ziehen Sie die Verwendung von ATP Serverless in Betracht, um zusätzliche Datentypen (relational, vektor, räumlich oder grafisch) für zusätzliche Workload-Funktionalität und Flexibilität zu speichern.
Mehr erfahren
Weitere Informationen zu den Features dieser Architektur:
Prüfen Sie die folgenden zusätzlichen Ressourcen:
- Oracle Datenplattform
- Oracle Autonomous Transaction Processing Serverless - Dokumentation
- Autonomous Database-Services für Azure
- Oracle Database API für MongoDB
- Oracle Autonomous Database Serverless verwenden
Prüfen Sie die folgenden zusätzlichen Ressourcen: