Info zur Infrastruktur zum Hosting von Single-Tenant-SaaS-Anwendungen

Als unabhängiger Softwarehersteller (ISV), der Software als Service (SaaS) bereitstellt, benötigen Sie eine sichere, skalierbare, unternehmensgerechte Infrastruktur, um Ihre Services zu hosten und Ihre Mandanten zu verwalten. Diese Lösung stellt Beispiel-Terraform-Module für eine validierte Netzwerktopologie bereit, um mehrere Einzelmandanten-SaaS-Anwendungen in Oracle Cloud zu hosten.

Bevor Sie beginnen

Lesen Sie die Deployment-Muster für SaaS-Anwendungen, finden Sie Informationen zu einer allgemeinen Netzwerkarchitektur und Hinweise zum Design.Siehe Infrastruktur für das Hosting von SaaS-Anwendungen entwerfen.

Architektur

Diese Architektur zeigt die Beispielnetzwerktopologie, für die die Lösung Terraform-Code bereitstellt. Die Beispieltopologie unterstützt vier Mandanten. Alle Komponenten in der Topologie befinden sich in einem einzelnen Bereich in einem Oracle Cloud Infrastructure-Mandanten.

Die Managementinfrastruktur des SaaS-Herstellers und die Anwendungsressourcen jedes Mandanten sind in separaten Compartments und virtuellen Cloud-Netzwerken (VCNs) isoliert. Durch die Netzwerkisolierung wird sichergestellt, dass die Anwendungen und Daten von den anderen Deployments im Mandanten getrennt werden. Compartments stellen die logische Isolation der Ressourcen sicher und aktivieren eine granulare Zugriffskontrolle.

Diese Topologie enthält die folgenden Komponenten:

• Management-Compartment

  Das Management-Compartment ist ein logischer Container für alle ISV-spezifischen Ressourcen, die für die gemeinsame Infrastruktur erforderlich sind, mit der die einzelnen Mandantenanwendungs-Deployments verwaltet werden. Sie enthält die folgenden Ressourcen:

  • ISV VCN

    Die für SaaS ISV erforderlichen Ressourcen für den Zugriff und die Verwaltung ihrer Mandanten sind dem ISV VCN zugeordnet.

  • Bastion

    Der Basisserver ist eine Compute-Instanz in einem öffentlichen Subnetz in ISV VCN. Der Datenverkehr zwischen dem Internet und dem Basisserver wird über ein Internetgateway weitergeleitet.

    Die Benutzer mit Administratorrechten des ISV können auf alle Ressourcen in dem Mandanten zugreifen, einschließlich der privaten Adressen der Ressourcen in den Mandanten-Compartments über den Bastion-Host. Die Benutzer mit Administratorrechten des ISV können auch auf private Ressourcen im Mandanten zugreifen, indem sie einen IPSec-VPN-Tunnel oder einen Oracle Cloud Infrastructure FastConnect-Circuck verwenden.

  • Management Server

    Der Management Server ist eine Compute-Instanz in einem privaten Subnetz. Sie ist einem privaten Subnetz in der ISV VCN zugeordnet. Der Management Server kann mit den Servern in den Mandanten-Compartments über die Routing-Gateways kommunizieren.

    Mit dem Management Server können Sie eine Infrastructure-Überwachungsanwendung, wie Nagios Core, installieren und ausführen.

• Peering-Compartment

  Für die private Kommunikation zwischen den Ressourcen in ISV VCN und den Mandantenressourcen ist eine lokale Peering-Beziehung zwischen ISV VCN und jedem Mandanten-VCN erforderlich. Ein VCN kann jedoch bis zu 10 lokale Peering-Beziehungen haben. Um diese Skalierungseinschränkung zu überwinden, verwendet die Architektur Routinggateways, die eine Verbindung zu mehreren VCNs mit Peering herstellen können. Jede Peering-VCN kann über eine lokale Peering-Beziehung mit bis zu 10 Mandanten-VCNs verfügen. So können Sie die Topologie vertikal skalieren, indem Sie Routinggateways hinzufügen und VCNs im Peering-Compartment hinzufügen.

  • Peering-Subnetz

    Das Peering-Subnetz ist Teil von ISV VCN. Alle Routinggateways sind diesem Subnetz zugeordnet.

  • Routinggateways und Peering von VCNs

    Jedes Routinggateway ist eine Oracle Linux Compute-Instanz, die Datenverkehr vom Managementserver über VCN mit Peering an die Mandanten-VNs weiterleitet.

    Zur Demonstration der High Availability (HA) des Routinggateways wird ein Aktiv-Passiv-Paar von Compute-Instanzen mit einer verschiebbaren IP-Adresse für eines der Routinggateways verwendet. Pacemaker und Corosync werden installiert, um automatisches Failover sicherzustellen. Das zweite Routinggateway ist eine einzelne (Nicht-HA-) Instanz.

    Die primäre VNIC jeder Routinggatewayinstanz wird dem Peering-Subnetz im ISV VCN zugeordnet.

    Die Routing-Gateway-Instanzen verwenden den Leistungseinheit VM.Standard.2.2, der eine sekundäre VNIC unterstützt. Die sekundäre VNIC jeder Routing-Gatewayinstanz wird einem Subnetz eines Peering-VCN zugeordnet. Jedes Peering-VCN kann mit maximal 10 Mandanten-VCNs verbunden werden. In der Beispieltopologie ist jede Peering-VCN mit zwei Mandanten-VCNs verbunden.

    • Wenn Sie größere Formen für die Routing-Gateway-Instanzen verwenden, können Sie die Topologie erweitern, um weitere VCNs zu unterstützen. Beispiel: Wenn Sie die Form VM.Standard.2.4 für eine Routing-Gatewayinstanz verwenden, können Sie bis zu drei sekundäre VNICs an die Instanz anhängen und das Routing-Gateway mit maximal drei Peering-VCNs verbinden. Das Routinggateway kann also maximal 30 Mandanten-VCNs unterstützen. Denken Sie daran, dass die verfügbare Netzwerkbandbreite der Routing-Gateway-Instanz von allen VNICs gemeinsam verwendet wird.

    • Die Netzwerkbandbreite zwischen jedem Mandanten-VCN und dem ISV VCN hängt von der Rechenleistungseinheit ab, die Sie für das Routinggateway auswählen. Die verfügbare Netzwerkbandbreite wird über alle VNICs der Gatewayinstanz hinweg gemeinsam verwendet. Beispiel: Wenn Sie die Leistungseinheit VM.Standard2.4 für die Routing-Gatewayinstanz auswählen, beträgt die maximal verfügbare Bandbreite 4.1 Gbit/s, die von der primären VNIC gemeinsam verwendet wird und bis zu drei sekundäre VNICs. Berücksichtigen Sie diesen Faktor, wenn Sie die Form der Gatewayinstanz und die Anzahl der Peering-VCNs festlegen, die jedes Gateway bedienen soll.

• Mandanten-Compartments

  Die Ressourcen für jeden der vier Mandanten in dieser Topologie befinden sich in einem separaten Compartment. Jedes Mandanten-Compartment enthält eine VCN, an die alle Ressourcen für diesen Mandanten angehängt sind. Die Ressourcen für jeden Mandanten verwenden also einen eindeutigen Adressraum in einem Netzwerk, der von allen anderen Mandanten in der Topologie isoliert ist.

  In jedem Mandanten-Compartment wird eine Compute-Instanz erstellt. Mit dieser Instanz können Sie einen Infrastructure-Überwachungs-Agent installieren und ausführen. Beispiel: Wenn Sie Nagios Core auf dem Management Server in ISV VCN installieren, können Sie den Nagios Agent in der Compute-Instanz in jedem Mandanten-Compartment installieren. Der Agent kann die Server im Compartment überwachen und Metriken an den Nagios-Überwachungsserver senden.

  Wenn Sie neue Anwendungsmandanten hinzufügen, werden die erforderlichen Ressourcen für den neuen Mandanten in einem neuen Compartment bereitgestellt.

  Mandanten können über das öffentliche Internet oder über eine private Verbindung (IPSec VPN oder FastConnect) auf ihre Anwendung zugreifen. Für den Zugriff über das öffentliche Internet benötigt jede Mandanten-VCN ein Internetgateway. Für den Zugriff über VPN oder FastConnect ist eine DRG erforderlich. Das Architekturdiagramm zeigt nicht die Internetgateways und die DRGs für die Mandanten-VCNs an.

Erforderliche Services und Policys

Diese Lösung erfordert die folgenden Services und Policys zur Verwaltung von Zugriffsberechtigungen:

Service	Policys erforderlich für...
Oracle Cloud Infrastructure Identity and Access Management	Compartments erstellen und verwalten.
Oracle Cloud Infrastructure Networking	VCNs, Subnetze, Internetgateways, Routentabellen, Sicherheitslisten, LPGs und DRGs erstellen und verwalten
Oracle Cloud Infrastructure Compute	Erstellen und verwalten Sie Compute-Instanzen.

In wird beschrieben, wie Sie Oracle Cloud-Services für Oracle-Lösungen erhalten, um die benötigten Cloud-Services zu erhalten.