Apache Tomcat bereitstellen, das mit MySQL Database Service verbunden ist
MySQL Database Service ist ein vollständig verwalteter nativer Oracle Cloud Infrastructure-Service. Es wurde vom MySQL-Team in Oracle entwickelt, verwaltet und unterstützt. Aufgaben wie Backup und Recovery, Datenbank- und Betriebssystem-Patching usw. werden automatisiert. Sie sind ausschließlich für die Verwaltung Ihrer Daten, Schemadesigns und Zugriffsrichtlinien verantwortlich.
Architektur
Die Referenzarchitektur enthält einen Load Balancer, eine Anwendungsebene mit Apache Tomcat und eine Datenbankebene mit einem HA-fähigen MySQL Database-Service.
Die Komponenten befinden sich in verschiedenen Subnetzen. Der Load Balancer befindet sich in einem öffentlichen Subnetz. Die Tomcat-Server teilen sich ein privates Subnetz und die Datenbank befindet sich in einem eigenen privaten Subnetz. Der gesamte externe Zugriff erfolgt über den Load Balancer über ein Internetgateway.
Der HA-fähige MySQL Database-Service ist eine Abstraktion eines Clusters. Es verfügt über drei MySQL-Instanzen, jedoch mit einem einzigen Endpunkt. Eine Instanz ist die primäre Instanz, und die anderen beiden Instanzen sind die sekundären Instanzen. Der primäre Endpunkt ermöglicht Lesevorgänge und Schreibvorgänge in die Datenbank. Die Sekundärdateien erhalten replizierte Daten vom Primären. Es ist kein direkter Zugriff auf die Sekundärdateien zulässig.
Bei Ausfall oder manueller Umstellung wird einer der Sekundärwerte zum neuen Primären und der Endpunkt wird zu ihm umgeleitet. Dies bedeutet, dass sich die Endpunkt-IP-Adresse nie ändert und die Anwendung nicht aktualisiert werden muss.
Eine Beispielanwendung, die die Anwendungssitzungsverwaltung mit der Datenbank anzeigt, ist enthalten.
Das folgende Diagramm veranschaulicht diese Referenzarchitektur.

Beschreibung der Abbildung Architecte-deploy-tomcat-mds-ha.png
architektur-deploy-tomcat-mds-oracle.zip
Wenn das Subnetz regional ist, werden die drei MySQL-Instanzen in verschiedenen Availability-Domains und Fault-Domains platziert. In Regionen mit einer einzelnen Availability-Domain werden die MySQL-Instanzen in verschiedenen Fault-Domains innerhalb derselben Availability-Domain platziert.
Die Architektur verfügt über folgende Komponenten:
- Region
Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Rechenzentrum (Availability-Domains) enthält. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie trennen (über Länder oder sogar Kontinente).
- Verfügbarkeitsdomains
Availability-Domains sind eigenständige, unabhängige Rechenzentren innerhalb einer Region. Die physischen Ressourcen in jeder Availability-Domain werden von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz bietet. Verfügbarkeitsdomänen teilen keine Infrastruktur wie Strom oder Kühlung oder das interne Availability-Domänennetzwerk. Somit ist es unwahrscheinlich, dass ein Fehler bei einer Availability-Domain die anderen Availability-Domains in der Region beeinträchtigt.
- Fault-Domains
Eine Faultdomain ist eine Gruppierung von Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain verfügt über drei Fault-Domains mit unabhängiger Leistung und Hardware. Wenn Sie Ressourcen auf mehrere Faultdomains verteilen, können Ihre Anwendungen physischen Serverausfall, Systemwartung und Stromausfälle innerhalb einer Faultdomain tolerieren.
- Virtuelles Cloud-Netzwerk (VCN) und Subnetze
Ein VCN ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten. Wie bei traditionellen Data Center-Netzwerken erhalten Sie mit VCNs die vollständige Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere sich nicht überschneidende CIDR-Blöcke aufweisen, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die einer Region oder einer Availability-Domain zugeordnet werden können. Jedes Subnetz besteht aus einem fortlaufenden Adressbereich, der sich mit den anderen Subnetzen im VCN nicht überschneidet. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz kann öffentlich oder privat sein.
- Load Balancer
Der Oracle Cloud Infrastructure Load Balancing-Service bietet eine automatisierte Trafficverteilung von einem einzigen Einstiegspunkt an mehrere Server im Backend.
- Sicherheitsliste
Für jedes Subnetz können Sie Sicherheitsregeln erstellen, die die Quelle, das Ziel und den Traffictyp angeben, die im Subnetz und außerhalb des Subnetzes zulässig sein müssen.
- Routentabelle
Virtuelle Routentabellen enthalten Regeln zur Weiterleitung des Traffics von Subnetzen an Ziele außerhalb eines VCN, typischerweise über Gateways.
- Internetgateway
Das Internetgateway ermöglicht den Datenverkehr zwischen den öffentlichen Subnetzen in einem VCN und dem öffentlichen Internet.
- Tomcat-Server
Die Tomcat-Server hosten das Java-Servlet, JavaServer Pages, Java Expression Language und Java WebSockets. Ihre Anwendungen sind in dieser Ebene vorhanden.
- Datenbankserver
Tomcat kann sich bei jeder Datenbank anmelden, die Java Database Connectivity (JDBC) anbietet. Diese Architektur verwendet MySQL Database Service.
- Bastionshost
Der Bastionshost ist eine Compute-Instanz, die als sicherer, kontrollierter Einstiegspunkt zur Topologie von außerhalb der Cloud dient. Der Bastionshost wird normalerweise in einer entmilitarisierten Zone (DMZ) bereitgestellt. Dadurch können Sie sensible Ressourcen schützen, indem Sie sie in private Netzwerke platzieren, auf die Sie nicht direkt von außerhalb der Cloud zugreifen können. Die Topologie hat einen einzigen bekannten Einstiegspunkt, den Sie regelmäßig überwachen und auditieren können. So können Sie vermeiden, die sensibleren Komponenten der Topologie freizugeben, ohne den Zugriff auf sie zu beeinträchtigen.
Empfehlungen
Ihre Anforderungen können von der hier beschriebenen Architektur abweichen. Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt.
- VCN
Legen Sie beim Erstellen eines VCN die Anzahl der erforderlichen CIDR-Blöcke und die Größe jedes Blocks basierend auf der Anzahl der Ressourcen fest, die Sie den Subnetzen im VCN zuordnen möchten. Verwenden Sie CIDR-Blöcke, die sich im privaten Standard-IP-Adressraum befinden.
Wählen Sie CIDR-Blöcke aus, die sich nicht mit anderen Netzwerken (in Oracle Cloud Infrastructure, Ihrem On-Premise-Data Center oder einem anderen Cloud-Provider) überschneiden, für die Sie private Verbindungen einrichten möchten.
Nachdem Sie ein VCN erstellt haben, können Sie dessen CIDR-Blöcke ändern, hinzufügen und entfernen.
Wenn Sie die Subnetze entwerfen, berücksichtigen Sie Ihre Verkehrsfluss- und Sicherheitsanforderungen. Ordnen Sie alle Ressourcen innerhalb einer bestimmten Ebene oder Rolle an dasselbe Subnetz zu, das als Sicherheitsgrenze dienen kann.
- Load Balancer
Diese Architektur verwendet einen 10-Mbps-Load Balancer, der in der Stufe Immer kostenlos enthalten ist. Je nach Anzahl der benötigten gleichzeitigen Verbindungen und dem Gesamtdurchsatz können Sie größere Formen verwenden. Der Durchsatz kann jederzeit bearbeitet werden.
Wir empfehlen Ihnen, DNS-Namen zu verwenden, weil die IP-Adresse des Load Balancers nicht reserviert werden kann.
- Instanzen
Alle Mandanten erhalten zwei Instanzen von Always Free Compute Virtual Machine (VM), die diese Architektur für die Tomcat-Server verwendet.
Wenn mehr Verarbeitungsleistung erforderlich ist, können Sie verschiedene Formen auswählen.
- Datenbanksysteme
Bei MySQL anmelden: Installieren Sie den neuesten MySQL-Client, und installieren Sie MySQL Shell auch aus dem MySQL Yum-Repository. Im Abschnitt "Weitere Informationen" finden Sie einen Link zur Verwendung des MySQL Yum-Repositorys.
- Speicherung
Die Instanzen in dieser Architektur verwenden regulären Blockspeicher. Es ist keine zusätzliche Performance erforderlich.
- Netzwerkverbindungen
Sie können die Umgebung verwalten, indem Sie eine Verbindung zu Ihrer vorhandenen On-Premise-Infrastruktur herstellen, indem Sie ein Site-to-Site-VPN oder eine dedizierte Verbindung mit FastConnect verwenden.
Wenn die Umgebung von der vorhandenen Infrastruktur getrennt oder extern aufgerufen werden muss, kann ein Bastionshost die Managementverbindungen sichern. Der Bastionshost wird normalerweise in einer entmilitarisierten Zone (DMZ) bereitgestellt. Sie schützt sensible Ressourcen, indem sie in private Netzwerke platziert werden, auf die nicht direkt von außerhalb der Cloud zugegriffen werden kann. Sie können vermeiden, die sensibleren Komponenten der Architektur freizugeben, ohne den Zugriff auf sie zu beeinträchtigen.
Überlegungen
Beachten Sie die folgenden Punkte beim Deployment dieser Referenzarchitektur.
- Performance
Sie können die Performance an die anwendungsspezifischen Anforderungen anpassen, indem Sie die Instanzformen (wenn Sie Intel-Serie verwenden) oder OCPU und Speicher separat ändern (wenn Sie AMD-Serie verwenden).
Die Datenbankinstanz kann derzeit nicht geändert werden. Wählen Sie die entsprechende Größe, wenn Sie sie erstellen.
- Sicherheit
Außer dem Bastionshost (falls vorhanden) und Load Balancern sollten alle Komponenten in privaten Subnetzen platziert werden.
Wenn strenge Sicherheit erforderlich ist, sollten Sie die Vorteile der Oracle-Sicherheitszonen in Betracht ziehen. Es ist ohne Aufpreis enthalten.
- Verfügbarkeit
Der Load Balancer wird mit einer Standby-Instanz geliefert und erfordert keine Intervention, wenn Failover auftritt.
Die Tomcat-Server werden als Paar bereitgestellt und vom Load Balancer ausgeglichen. Jede Tomcat-Instanz befindet sich in einer anderen Faultdomain.
Sichern Sie Ihre Datenbank so oft wie erforderlich, um das angestrebte Recovery Point-Ziel (RPO) zu erfüllen.
Wenn auch nur selten, passen Sie das Wartungsfenster für MySQL Database Service an die Anforderungen Ihrer Organisation an.
- Kostenfaktor
Die Kosten dieser Architektur ändern sich basierend auf der Größe und den Formen der Instanzen, Datenbanken und Load Balancer. Es sind keine Komponenten mit variablen Kosten vorhanden.
Bereitstellen
Der für das Deployment dieser Referenzarchitektur erforderliche Code ist in GitHub verfügbar. Sie können den Code mit einem einzigen Klick in Oracle Cloud Infrastructure Resource Manager ziehen, den Stack erstellen und bereitstellen. Alternativ können Sie den Code von GitHub auf Ihren Computer herunterladen, den Code anpassen und die Architektur mit der Terraform-CLI bereitstellen.
- Mit Oracle Cloud Infrastructure Resource Manager bereitstellen:
- KlickenSie auf
Wenn Sie noch nicht angemeldet sind, geben Sie die Mandanten- und Benutzerzugangsdaten ein.
- Prüfen und akzeptieren Sie die Allgemeinen Geschäftsbedingungen.
- Wählen Sie den Bereich, in dem Sie den Stack bereitstellen möchten.
- Befolgen Sie die Prompts und Anweisungen auf dem Bildschirm, um den Stack zu erstellen.
- Klicken Sie nach dem Erstellen des Stacks auf Terraform-Aktionen, und wählen Sie Plan aus.
- Warten Sie, bis der Job abgeschlossen ist, und prüfen Sie den Plan.
Um Änderungen vorzunehmen, kehren Sie zur Seite "Stackdetails" zurück, klicken Sie auf Stack bearbeiten, und nehmen Sie die erforderlichen Änderungen vor. Führen Sie dann die Aktion Plan erneut aus.
- Wenn keine weiteren Änderungen erforderlich sind, kehren Sie zur Seite "Stackdetails" zurück, klicken Sie auf Terraform-Aktionen, und wählen Sie Anwenden aus.
- KlickenSie auf
- Deployment mit dem Terraform-Code in GitHub:
- Gehen Sie zu GitHub.
- Klonen oder laden Sie das Repository auf Ihren lokalen Computer herunter.
- Befolgen Sie die Anweisungen im Dokument
README
.
Weitere Informationen
- Tomcat-Cluster mit MySQL-Sessionpersistenz erstellen
- JDBCStore für Sessionpersistenz verwenden
- Erste Schritte mit MySQL Database-Service
- Kurzanleitung zur Verwendung des MySQL Yum-Repositorys (zum Aktualisieren des MySQL-Clients und zur Installation von MySQL Shell)
Änderungslog
In diesem Log werden nur die wesentlichen Änderungen aufgeführt:
24. Februar 2022 |
|
7. Januar 2021 | Anweisungen zum Deployment der Architektur mit Oracle Cloud Infrastructure Resource Manager hinzugefügt. |