Bearbeiten

Share via

Hosten einer Murex MX.3-Workload in Azure mithilfe von SQL

Azure Firewall
Azure ExpressRoute
Azure-Schlüsseltresor
Azure Storage
Azure Monitor

Das Ziel dieses Artikels besteht darin, technische Details zur Implementierung von Murex-Workloads in Microsoft Azure bereitzustellen.

Murex ist ein weltweit führender Softwareanbieter von Lösungen für Handel, Risikomanagement, Abwicklung und Post-Trade für Kapitalmärkte. Viele Banken stellen die dritte Generation der MX.3-Plattform von Murex bereit, um Risiken zu managen, die Transformation zu beschleunigen und die Einhaltung von Vorschriften zu vereinfachen – und das alles bei gleichzeitiger Steigerung der Erträge. Die Murex-Plattform ermöglicht es Kunden, bessere Kontrolle über ihre Abläufe zu erlangen, die Effizienz zu steigern und die Betriebskosten zu senken.

Aufbau

Murex MX.3-Workloads können mit Datenbanken wie Oracle, Sybase oder SQL Server ausgeführt werden. Mit Version V3.1.48 wird SQL Server 2019 Standard für MX.3 unterstützt, wodurch Sie von der Leistung, Skalierbarkeit, Resilienz und von den Kosteneinsparungen profitieren können, die SQL Server mit sich bringt. MX.3 ist nur auf virtuellen Azure-Computern (VMs) unter Windows OS verfügbar.

Abbildung, die eine Azure-Architektur für eine Murex MX.3-Anwendung zeigt.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

  • Die MX.3-Präsentationsebene wird in Azure gehostet und ist über ExpressRoute oder ein Site-to-Site-VPN von einer lokalen Umgebung aus zugänglich.
  • Die Anwendungsebene enthält die Präsentationsebene, die Geschäftsebene, die Orchestrierungsebene und die Rasterebene. Sie greift auf SQL Server auf Windows-VMs zu, um Daten zu speichern und abzurufen. Für zusätzliche Sicherheit empfehlen wir Ihnen, Azure Virtual Desktop oder Windows 365 Cloud-PC zu verwenden und eine Desktopanwendung auszuführen, um auf die Präsentationsebene zuzugreifen. Sie können auf sie jedoch auch über eine Weboberfläche zugreifen.
  • Die Präsentationsschicht greift auf Komponenten der Geschäftsebene, der Orchestrierungsebene und der Rasterebene zu, um den Geschäftsprozess abzuschließen.
  • Die Anwendungsebene greift auf Azure Key Vault-Dienste zu, um Verschlüsselungsschlüssel und Geheime sicher zu speichern.
  • Administratorbenutzer greifen sicher auf die Murex MX.3-Server zu, indem Sie den Azure Bastion-Dienst verwenden.

Komponenten

  • Azure Bastion: Azure Bastion ist ein vollständig verwalteter Dienst, der sichereren und nahtloseren VM-Zugriff per RDP (Remotedesktopprotokoll) und SSH (Secure Shell-Protokoll) ohne jegliche Verfügbarkeit über öffentliche IP-Adressen bietet.
  • Azure Monitor: Mit Azure Monitor können Sie Telemetriedaten aus Ihren Azure- und lokalen Umgebungen sammeln, analysieren und auf sie reagieren.
  • Azure Firewall: Azure Firewall ist ein cloudnativer, intelligenter Netzwerkfirewall-Sicherheitsdienst, der erstklassigen Bedrohungsschutz für Ihre cloudbasierten, in Azure ausgeführten Workloads bietet.
  • Azure ExpressRoute: Mithilfe von Azure ExpressRoute können Sie private Verbindungen zwischen Azure-Rechenzentren und Infrastrukturen erstellen, die sich an einem lokalen Standort oder in einer Colocationumgebung befinden.
  • Azure Files: Vollständig verwaltete Dateifreigaben in der Cloud, auf die über die SMB- und NFS-Branchenstandardprotokolle zugegriffen werden kann.
  • Azure Disk Storage: Azure Disk Storage bietet hochleistungsfähigen, permanenten Blockspeicher für unternehmenskritische Anwendungen.
  • Azure Site Recovery: Stellen Sie Replikations-, Failover- und Wiederherstellungsprozesse über Site Recovery bereit, damit Ihre Anwendungen während geplanter und ungeplanter Ausfälle weiterhin ausgeführt werden.
  • Mit SQL Server auf Windows-VMs: Mit SQL Server auf Azure-VMs können Sie Vollversionen von SQL Server in der Cloud nutzen, ohne lokale Hardware verwalten zu müssen. Virtuelle SQL Server-Computer vereinfachen außerdem die Lizenzierungskosten, wenn Sie eine nutzungsbasierte Bezahlung verwenden.
  • Azure Key Vault: Verwenden von Azure Key Vault, um Geheimnisse sicher zu speichern und darauf zuzugreifen.
  • Azure VPN Gateway: VPN Gateway sendet verschlüsselten Datenverkehr zwischen einem virtuellen Azure-Netzwerk und einem lokalen Standort über das öffentliche Internet.
  • Azure Policy: Verwenden von Azure Policy zum Erstellen, Zuweisen und Verwalten von Richtliniendefinitionen in Ihrer Azure-Umgebung.
  • Azure Backup: Azure Backup ist eine kostengünstige, sichere Sicherungslösung mit einem Klick, die basierend auf Ihren Sicherungsspeicheranforderungen skalierbar ist.

Alternativen

Alternativ können Sie statt SQL Murex MX.3 mit Oracle als Datenbank verwenden. Weitere Informationen finden Sie unter Hosten einer Murex MX.3-Workload in Azure.

Szenariodetails

MX.3 ist eine Client-/Serveranwendung, die auf einer dreistufigen Architekturstruktur mit drei Ebenen basiert. Banken nutzen MX.3 für ihre geschäftlichen Anforderungen, wie etwa Vertrieb und Handel, Risikomanagement sowie Sicherheitsleistungen und Investitionen.

Azure bietet eine schnelle und einfache Möglichkeit zum Erstellen und Skalieren einer MX.3-Infrastruktur. Es bietet eine sichere, zuverlässige und effiziente Umgebung für Produktions-, Entwicklungs- und Testsysteme und reduziert erheblich die Infrastrukturkosten, die für den Betrieb der MX.3-Umgebung erforderlich sind.

Um detaillierte Informationen zu den verschiedenen Schichten und Ebenen der Murex MX.3-Anwendungs-, Compute- und Speicheranforderungen zu erhalten, wenden Sie sich an das technische Team von Murex.

Mögliche Anwendungsfälle

Diese Lösung eignet sich ideal für den Einsatz in der Finanzbranche, und besonders für die folgenden potenziellen Anwendungsfälle:

  • Bessere Kontrolle des Betriebs, höhere Effizienz und geringere Infrastrukturkosten.
  • Schaffen einer sicheren, zuverlässigen und effizienten Umgebung für Produktion und Entwicklung.

Voraussetzungen und Einschränkungen

Murex MX.3 ist eine komplexe Workload mit hohen Arbeitsspeicher-, geringen Latenz- und hohen Verfügbarkeitsanforderungen. Nachfolgend werden einige der technischen Einschränkungen und Anforderungen erläutert, die Sie analysieren müssen, wenn Sie eine Murex MX.3-Workload in Azure implementieren.

  • MX.3 verwendet eine Client-/Serverarchitektur. Sobald diese in Azure implementiert wurde, kann sie auf virtuellen Computern ausgeführt werden, und für die Anwendung werden keine PaaS-Dienste unterstützt. Analysieren Sie sorgfältig alle nativen Azure-Dienste, um sicherzustellen, dass sie die technischen Anforderungen für Murex erfüllen.
  • Die MX.3-Anwendung erfordert externe (Internet) und interne (lokale) Konnektivität, um Aufgaben auszuführen. Die Azure-Architektur für die MX.3-Anwendung muss ein sicheres Konnektivitätsmodell unterstützen, um in interne und externe Dienste integriert zu werden. Verwenden Sie ein Azure-Site-to-Site-VPN oder ExpressRoute (empfohlen), um eine Verbindung mit lokalen Diensten herzustellen.
  • Sie können die MX.3-Lösung vollständig in Azure bereitstellen oder eine Teilmenge von Azure-Komponenten mithilfe eines Hybridmodells bereitstellen (dieses Szenario wird in diesem Artikel nicht behandelt). Sie sollten die Architektur und die technischen Anforderungen sorgfältig analysieren, bevor Sie ein hybrides Bereitstellungsmodell verwenden. Hybride Bereitstellungsmodelle für MX.3 unterliegen der technischen Überprüfung durch das Murex-Team.

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie in der Überblick über die Säule „Zuverlässigkeit“.

Für die Sicherung können Sie native Azure-Sicherungsdienste in Kombination mit Azure-Speicher verwenden. Verwenden Sie diese Dienste für tägliche, wöchentliche oder monatliche Sicherungen der Anwendungs-VMs oder anderer Sicherungs-/Archivierungsanforderungen, die für die Logikschicht spezifisch sind. Für Datenbankanforderungen können Site Recovery verwenden, um den Notfallwiederherstellungsprozess und native Datenbankreplikation zu automatisieren. Sie können auch Sicherungstools verwenden, um die erforderliche Ebene von RPO-Metriken zu erreichen.

Um Hochverfügbarkeit und Resilienz der Murex-Lösung in Azure zu erhalten, führen Sie jede Ebene der Logikschicht in mindestens zwei VMs aus. Sie können eine Azure-Verfügbarkeitsgruppenkonfiguration verwenden, um Hochverfügbarkeit über mehrere VMs hinweg zu erreichen. Sie können Azure Virtual Machine Scale Sets auch für Redundanz und verbesserte Leistung von Anwendungen verwenden, die auf mehrere Instanzen verteilt sind. Sie können Hochverfügbarkeit für die Orchestrierungsebene erreichen, indem das Hosting in mehreren Instanzen erfolgt und die Instanzen mithilfe benutzerdefinierter Skripts aufgerufen werden. Verwenden Sie Datenbankfeatures für Hochverfügbarkeit wie SQL Server Always On-Verfügbarkeitsgruppen, um die Hochverfügbarkeitsanforderungen zu erreichen.

Sie können die SQL Server Always On-Verfügbarkeitsgruppe verwenden, um das DR-Failover zu automatisieren, indem Sie eine primäre SQL Server-Instanz und eine oder mehrere sekundäre Instanzen einrichten. Konfigurieren Sie die Funktion Always On-Verfügbarkeitsgruppe auf jeder Serverinstanz.

MX.3 erfordert, dass DTC in SQL Server aktiviert ist. Da der DTC-Support für die SQL Server Always On-Verfügbarkeitsgruppe in SQL Server unter RedHat Linux OS noch nicht verfügbar ist, wird empfohlen, SQL Server auf virtuellen Windows Server-Computern zu hosten, um DTC-Transaktionen zu unterstützen.

Für Notfallwiederherstellung sollten Sie die Notfallwiederherstellungswebsite in einer anderen Azure-Region ausführen. Für SQL Server können Sie Aktiv/Passiv-Notfallwiederherstellungskonfigurationen basierend auf den Anforderungen an Recovery Point Objective und Recovery Time Objective verwenden. Aktiv/Aktiv ist keine Option für SQL Server, da Schreibvorgänge in mehreren Regionen nicht möglich sind. Datenverlust aufgrund der Latenz und der Anzeigedauer von Sicherungen muss berücksichtigt werden. Sie können Site Recovery verwenden, um den Notfallwiederherstellungsprozess und native Datenbankreplikation zu automatisieren. Sie können auch Sicherungstools verwenden, um die erforderliche Ebene von RPO-Metriken zu erreichen.

Linux ist eine Marke des entsprechenden Unternehmens. Die Verwendung dieser Marke impliziert keine Empfehlung.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Greifen Sie auf die MX.3-Clientebene direkt vom Benutzerdesktop oder über virtuelle Desktoplösungen wie Azure Virtual Desktop, Windows 365 Cloud-PCs oder andere Nicht-Microsoft-Lösungen zu.

Verwenden Sie Dienste wie Azure Key Vault, um die Sicherheitsanforderungen der MX.3-Anwendung in Azure zu berücksichtigen, indem Schlüssel und Zertifikate gespeichert werden. Sie können virtuelle Netzwerke, Netzwerksicherheitsgruppen (NSGs) und Anwendungssicherheitsgruppen verwenden, um den Zugriff zwischen verschiedenen Ebenen und Schichten zu steuern. Verwenden Sie Azure Firewall, DDoS-Schutz und Azure Application Gateway- oder Web Application Firewall-Dienste, um die Front-End-Ebene in Abhängigkeit von den Sicherheitsanforderungen zu schützen.

Sehen Sie sich die SQL Server-Funktionen an, die eine Sicherheitsmethode auf Datenebene bieten. Darüber hinaus ist es mit den Azure-Sicherheitsmaßnahmen möglich, sensible Daten zu verschlüsseln, virtuelle Maschinen vor Viren und Malware zu schützen, den Netzwerkdatenverkehr abzusichern, Bedrohungen zu identifizieren, Complianceanforderungen zu erfüllen. Außerdem wird durch diese Sicherheitsmaßnahmen eine einheitliche Methode zur Verwaltung und Berichterstattung für sämtliche Sicherheitsanforderungen in der Hybrid Cloud bereitgestellt. Weitere Informationen zu diesen Sicherheitsüberlegungen finden Sie unter Sicherheitskonzepte für SQL Server auf Azure-VMs.

Weitere Informationen zu bewährten Methoden für SQL Server-VMs finden Sie in den anderen Artikeln dieser Reihe:

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Mit dem Azure-Hybridvorteil können Sie Ihre vorhandenen Lizenzen gegen reduzierte Tarife für Azure SQL-Datenbank und Azure SQL Managed Instance tauschen. Mit Ihren SQL Server-Lizenzen mit Software Assurance-Aktivierung in Azure können Sie bei einer SQL-Datenbank oder SQL Managed Instance bis zu 30 Prozent oder sogar mehr einsparen. Mit dem Kostenrechner auf der Seite Azure-Hybridvorteil können Sie Ihre möglichen Einsparungen ausrechnen.

Verschiedene Optionen können sich auf die Kosten auswirken, und es ist wichtig, das richtige VM-SKU auszuwählen, damit Kosten und Geschäftsanforderungen im Gleichgewicht sind.

Skalierungsgruppen für virtuelle Computer können die Anzahl von VM-Instanzen automatisch erhöhen, wenn der Bedarf für die Anwendung zunimmt, und sie dann wieder verringern, wenn der Bedarf sinkt.

Die automatische Skalierung minimiert die Anzahl unnötiger VM-Instanzen zur Ausführung Ihrer Anwendung, wenn die Nachfrage gering ist. Kunden profitieren durchgängig von einem akzeptablen Leistungsniveau, da bei steigender Nachfrage automatisch weitere VM-Instanzen hinzugefügt werden. Diese Möglichkeit trägt zur Reduzierung von Kosten und zur effizienten bedarfsabhängigen Erstellung von Azure-Ressourcen bei.

Weitere Informationen zu den Tarifen finden Sie unter Preisinformationen für SQL Server auf Azure-VMs. Sie können Ihre voraussichtlichen Kosten auch mithilfe des Azure-Preisrechners ermitteln.

Optimaler Betrieb

Die Säule „Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Übersicht über die Säule „Optimaler Betrieb“.

Verwenden Sie Azure Monitor, um die Azure-Infrastrukturkomponenten zu überwachen. Mithilfe des zugehörigen Warnungsmechanismus können Sie präventive Aktionen wie automatische Skalierung oder Benachrichtigungen ausführen.

Sie können Infrastrukturautomatisierung erreichen, indem Infrastructure-as-Code-Dienste wie Azure Resource Manager-Vorlagen oder Terraform-Skripts verwenden.

Mit Azure DevOps können Sie Azure SQL Server mit allen unterstützten IaC-Diensten bereitstellen, wie z. B. Terraform. Sie können Murex DevOps-Tools verwenden, um die DevOps-Anforderungen auf Anwendungsebene zu berücksichtigen. Wenden Sie sich direkt an Murex, um Anleitungen zu diesem Ansatz zu erhalten.

Effiziente Leistung

Leistungseffizienz ist die Fähigkeit Ihrer Workload, auf effiziente Weise eine den Anforderungen der Benutzer entsprechende Skalierung auszuführen. Weitere Informationen finden Sie unter Übersicht über die Säule „Leistungseffizienz“.

Mehrere Murex MX.3-Workloads in verschiedenen Ebenen erfordern bestimmte Arten von Computeressourcen, um die funktionalen und technischen Anforderungen zu erfüllen. Unter Murex MX.3-Architektur finden Sie Informationen zu den Compute-, Arbeitsspeicher- und Speicheranforderungen für eine MX.3-Workload.

Um die erforderlichen Leistungsmetriken für Murex-Workloads zu erreichen, sollten Sie das MX.3-Anwendungsverzeichnis und die -Datenbanken in Azure Managed Disks mit SSD Premium speichern. Sie können eine Näherungsplatzierungsgruppe und Netzwerkbeschleunigung in Azure verwenden, um einen hohen Netzwerkdurchsatz über Ebenen hinweg zu erreichen.

Verwenden Sie Premium- oder Ultra SSD-Speicher für SQL auf Azure-VMs. Weitere Informationen zu Premium SSD finden Sie in den Richtlinien zur Speicherkonfiguration für SQL Server auf Azure-VMs.

Ultra SSD dagegen ist ein weiteres in Azure verfügbares Speicherangebot für unternehmenskritische Workloads, die bei hohem Durchsatz Latenzzeiten im Submillisekundenbereich erreichen. Mit Ultra SSD benötigen wir nur einen Ultra SSD-Datenträger von 1 TB, der bis zu 50.000 IOPS skalieren kann. Ultra SSD kann flexibel konfiguriert werden, und die Größe und IOPS können unabhängig voneinander skaliert werden. Weitere Informationen zu Ultra SSD finden Sie unter Unternehmenskritische Leistung mit Ultra SSD für SQL Server auf Azure-VMs | Azure-Blog | Microsoft Azure.

Die Artikelprüfliste: Bewährte Methoden für SQL Server auf Azure-VMs ist eine schnelle Checkliste für bewährte Methoden und Richtlinien zur Optimierung der Leistung von SQL Server auf Azure-VMs. Weitere Informationen zu bewährten Methoden für SQL Server-VMs finden Sie in den anderen Artikeln dieser Reihe:

Aktivieren Sie SQL-Bewertung für SQL Server auf Azure-VMs, um Ihren SQL Server anhand bekannter bewährter Methoden auszuwerten und die Ergebnisse im Azure-Portal auf der Seite „SQL VM-Verwaltung“ anzuzeigen.

Wenn Sie Skalierungssätze für virtuelle Computer verwenden, ist es möglich, aufzuskalieren und zusätzliche VMs zu erstellen, um die Computeanforderungen für die Geschäftsebene zu erfüllen. Für Murex MX.3 muss dies jedoch geschehen, ohne dass die aktiven Sitzungen beendet werden. Murex MX.3-Kunden können sich an ihre Produktsupporttechniker wenden, die sie zu den Strategien für eine sichere VM-Skalierung beraten werden.

Hub-and-Spoke-Netzwerkmodell

Ein wichtiger Aspekt bei der Implementierung von MX.3-Workloads in Azure ist die Definition der Zielzonenarchitektur. Diese Architektur enthält das Abonnement, die Ressourcengruppe, die virtuelle Netzwerkisolation und die Konnektivität zwischen verschiedenen Komponenten der Lösung. Dieser Abschnitt behandelt die Zielzonenarchitektur für die Implementierung einer MX.3-Workload in Azure, basierend auf dem Microsoft Cloud Adoption Framework.

Diese Abbildung zeigt eine allgemeine Ansicht einer Zielzone, die die Hub-Spoke-Netzwerktopologie in Azure verwendet.

Abbildung, die ein Beispiel für ein Hub-and-Spoke-Modell mit Azure-Diensten zeigt.

  • Dieses Modell bietet eine starke Isolierung der Spoke-Netzwerke, die zur Ausführung verschiedener Umgebungen verwendet werden. Das Modell sieht auch sicheren Steuerungszugriff und eine gemeinsame Dienstebene im Hubnetzwerk vor.
  • Sie können das gleiche Hub-Spoke-Modell in einer anderen Region verwenden, da es sich um eine Lösung für mehrere Regionen handelt. Sie können einen Hub für jede Region erstellen, gefolgt von verschiedenen Spokes für Nichtproduktions- und Produktionsumgebungen.
  • Verwenden Sie diese Zielzone für ein einzelnes Abonnement oder mehrere Abonnements, je nachdem, wie Ihre Organisation Ihre Anwendungen kategorisiert.

Erläuterungen zu den einzelnen Komponenten in der Zielzone finden Sie hier:

Hub: Der Hub ist ein virtuelles Netzwerk, das als zentraler Ort für die Verwaltung der externen Konnektivität zum lokalen Netzwerk eines MX.3-Kunden und der von mehreren Workloads genutzten Hostingdienste dient.

Spoke: Die Spokes sind virtuelle Netzwerke, die die Azure-Workloads von MX.3 hosten und über Peering virtueller Netzwerke mit dem zentralen Hub verbunden sind.

Peering virtueller Netzwerke: Virtuelle Hub-and-Spoke-Netzwerke werden über Peering virtueller Netzwerke verbunden, das Verbindungen mit geringer Latenz zwischen den virtuellen Netzwerken unterstützt.

Gateway: Ein Gateway wird verwendet, um Datenverkehr vom lokalen Netzwerk eines MX.3-Clients an das virtuelle Azure-Netzwerk zu senden. Sie können den Datenverkehr verschlüsseln, bevor Sie ihn senden.

Gatewaysubnetz: Das Gateway, das Datenverkehr aus einer lokalen Umgebungen Azure sendet, verwendet ein bestimmtes Subnetz, das als Gatewaysubnetz bezeichnet wird. Das Gatewaysubnetz ist Teil des IP-Adressbereichs für das virtuelle Netzwerk, den Sie beim Konfigurieren Ihres virtuellen Netzwerks angeben. Es enthält die IP-Adressen, die von den Ressourcen und Diensten des Gateways für virtuelle Netzwerke verwendet werden.

Azure Jumpbox-VM: Jumpbox verbindet Azure-VMs der Anwendungs- und Persistenzebenen über eine dynamische IP-Adresse. Jumpbox verhindert, dass alle Anwendungs- und Datenbank-VMs öffentlich verfügbar gemacht werden. Diese Verbindung ist Ihr Einstiegspunkt, um aus dem lokalen Netzwerk eine RDP-Verbindung herzustellen.

Azure Firewall: Sie sollten die gesamte ein- und ausgehende Konnektivität zwischen MX.3-VMs und dem Internet über Azure Firewall weiterleiten. Typische Beispiele für eine solche Konnektivität sind Zeitsynchronisierung und Virenschutzdefinitionsupdates.

Azure Bastion: Durch die Verwendung von Azure Bastion können Sie die Anwendungs- und Datenbank-VMs über das Azure-Portal sicher verbinden. Stellen Sie den Azure Bastion-Host innerhalb des virtuellen Hubnetzwerks bereit, und greifen Sie dann in den virtuellen Spoke-Netzwerken mit Peering auf die VMs zu. Diese Komponente ist optional, und Sie können sie bei Bedarf verwenden.

Azure Bastion-Subnetz: Azure Bastion erfordert ein dediziertes Subnetz: AzureBastionSubnet. Sie müssen dieses Subnetz im Hub erstellen und den Bastion-Host in diesem Subnetz bereitstellen.

Azure-Verwaltungssubnetz: Azure Jumpbox muss sich im Verwaltungssubnetz befinden. Jumpbox enthält VMs, die Verwaltungs- und Überwachungsfunktionen für die Anwendungs- und Datenbank-VMs im virtuellen Spoke-Netzwerk implementieren.

Anwendungssubnetz: Sie können hier alle Komponenten unter der Logikschicht platzieren. Ein dediziertes Anwendungs-Subnetz hilft auch bei der Steuerung des Datenverkehrs zu den Geschäfts-, Orchestrierungs- und technischen Dienstebenen durch NSGs.

Datenbanksubnetz: Sie können die Komponenten im Datenbanksubnetz in einem dedizierten Subnetz platzieren, um den Datenverkehr rund um die Datenbank zu verwalten.

Private Link: Azure-Dienste wie Recovery Services-Tresor, Azure Cache for Redis und Azure Files werden alle über eine private Verbindung mit dem virtuellen Netzwerk verbunden. Durch eine private Verbindung zwischen diesen Diensten und dem virtuellen Netzwerk wird die Verbindung zwischen den Endpunkten in Azure gesichert, da die Daten nicht im Internet verfügbar sind.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte