Bearbeiten

Ausführen einer hoch verfügbaren SharePoint Server 2016-Farm in Azure

Azure ExpressRoute
Azure Managed Disks
Azure Virtual Machines
Azure Virtual Network
Azure VPN Gateway

In dieser Referenzarchitektur werden bewährte Methoden zum Bereitstellen einer SharePoint Server 2016-Hochverfügbarkeitsfarm in Azure mit der MinRole-Topologie und SQL Server AlwaysOn-Verfügbarkeitsgruppen veranschaulicht. Die SharePoint-Farm wird in einem geschützten virtuellen Netzwerk ohne Internetendpunkt bzw. -präsenz bereitgestellt.

Aufbau

Architecture diagram that shows a highly available SharePoint Server 2016 farm in Azure.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Diese Architektur baut auf der Architektur auf, die unter [Ausführen virtueller Windows-Computer für eine Anwendung mit n-Schichten][Windows-n-Schichten] dargestellt ist. Eine SharePoint Server 2016-Farm mit Hochverfügbarkeit wird in einem virtuellen Azure-Netzwerk bereitgestellt. Diese Architektur ist für eine Test- oder Produktionsumgebung, eine SharePoint-Hybridinfrastruktur mit Microsoft 365 oder als Basis für ein Szenario für die Notfallwiederherstellung geeignet.

Komponenten

  • Ressourcengruppen sind Container, die verwandte Azure-Ressourcen enthalten. Eine Ressourcengruppe wird für die SharePoint-Server verwendet, und eine andere Ressourcengruppe wird für Infrastrukturkomponenten genutzt, die unabhängig von virtuellen Computern (VMs) sind, z. B. das virtuelle Netzwerk und Lastenausgleichsmodule.

  • Azure Virtual Network ist der grundlegende Baustein für private Netzwerke in Azure. Die VMs werden in einem virtuellen Netzwerk mit einem eindeutigen Intranetadressraum bereitgestellt. Das virtuelle Netzwerk wird weiter in Subnetze unterteilt.

  • VMs sind bedarfsgesteuerte skalierbare Computeressourcen, die in Azure verfügbar sind. Die VMs werden im virtuellen Netzwerk bereitgestellt, und private statische IP-Adressen werden allen VMs zugewiesen. Statische IP-Adressen sind für die VMs zu empfehlen, auf denen SQL Server und SharePoint Server 2016 ausgeführt werden, um Probleme mit der Zwischenspeicherung von IP-Adressen und Adressänderungen nach einem Neustart zu vermeiden.

  • Verfügbarkeitsgruppen sind logische Gruppierungen von VMs. Ordnen Sie die virtuellen Computer für jede SharePoint-Rolle in separaten Verfügbarkeitsgruppen an, und stellen Sie mindestens zwei VMs für jede Rolle bereit. Aufgrund dieser Konfiguration können die VMs für eine höhere Vereinbarung zum Servicelevel (SLA) genutzt werden.

  • Über Azure Load Balancer wird Datenverkehr in Form von SharePoint-Anforderungen aus dem lokalen Netzwerk auf die Front-End-Webserver der SharePoint-Farm verteilt. Diese Lösung verwendet einen internen Lastenausgleich. Alternativ für HTTP-Datenverkehr könnte Azure Application Gateway verwendet werden.

  • Netzwerksicherheitsgruppen filtern den Datenverkehr in einem virtuellen Azure-Netzwerk. Für jedes Subnetz, das VMs enthält, wird eine Netzwerksicherheitsgruppe erstellt. Mithilfe von Netzwerksicherheitsgruppen werden der Netzwerkdatenverkehr innerhalb des virtuellen Netzwerks eingeschränkt, um Subnetze zu isolieren.

  • Azure ExpressRoute oder ein Site-to-Site-VPN wie Azure VPN Gateway stellt eine Verbindung zwischen Ihrem lokalen Netzwerk und dem virtuellen Azure-Netzwerk bereit. Weitere Informationen finden Sie unter Herstellen einer Verbindung zwischen einem lokalen Netzwerk und Azure.

  • Windows Server Active Directory-Domänencontroller (AD) authentifizieren Benutzer*innen in einer Domäne. Die Domänencontroller in dieser Referenzarchitektur werden im virtuellen Azure-Netzwerk ausgeführt und besitzen eine Vertrauensstellung mit der lokalen Windows Server AD-Gesamtstruktur. Clientwebanforderungen für Ressourcen von SharePoint-Farmen werden im virtuellen Netzwerk authentifiziert, anstatt den Datenverkehr des Authentifizierungsvorgangs über die Gatewayverbindung an das lokale Netzwerk zu senden. In DNS werden A- oder CNAME-Intraneteinträge erstellt, damit Intranetbenutzer den Namen der SharePoint-Farm in die private IP-Adresse des internen Lastenausgleichs auflösen können.

    SharePoint Server 2016 unterstützt auch die Verwendung Microsoft Entra Domain Services. Microsoft Entra Domain Services stellt verwaltete Domänendienste bereit, sodass Sie keine Domänencontroller in Azure bereitstellen und verwalten müssen.

  • SQL Server Always On-Verfügbarkeitsgruppen stellen eine Hochverfügbarkeits- und Notfallwiederherstellungslösung bereit. Es wird empfohlen, sie für die Hochverfügbarkeit der SQL Server-Datenbank zu verwenden. Zwei VMs werden für SQL Server verwendet. Einer enthält das primäre Datenbankreplikat und der andere das sekundäre Replikat.

  • Mit einer Hauptknoten-VM kann der Failovercluster ein Quorum festlegen. Weitere Informationen finden Sie unter Grundlegendes zu Quorumkonfigurationen in einem Failovercluster.

  • SharePoint Server bietet eine Plattform für den gemeinsamen Zugriff. Die SharePoint-Server übernehmen die Rollen für Web-Front-End, Caching, Anwendung und Suche.

  • Eine Jumpbox, die auch als Bastionhost bezeichnet wird, ist ein sicherer virtueller Computer im Netzwerk, den Administrator*innen verwenden, um eine Verbindung mit den anderen VMs herzustellen. Die Jumpbox verfügt über eine Netzwerksicherheitsgruppe, bei der Remotedatenverkehr nur von öffentlichen IP-Adressen zugelassen wird, die in einer Liste mit sicheren Adressen enthalten sind. Die Netzwerksicherheitsgruppe sollte Remotedesktopdatenverkehr (RDP) zulassen.

Empfehlungen

Ihre Anforderungen können von der hier beschriebenen Architektur abweichen. Verwenden Sie diese Empfehlungen als Startpunkt.

Empfehlungen für Ressourcengruppen

Wir empfehlen Ihnen, Ressourcengruppen nach der Serverrolle zu trennen und eine separate Ressourcengruppe für Infrastrukturkomponenten zu verwenden, bei denen es sich um globale Ressourcen handelt. Bei dieser Architektur bilden die SharePoint-Ressourcen eine Gruppe und SQL Server und andere Hilfsprogrammobjekte die andere Gruppe.

Empfehlungen für virtuelle Netzwerke und Subnetze

Verwenden Sie ein Subnetz für jede SharePoint-Rolle sowie zusätzlich jeweils ein Subnetz für das Gateway und für die Jumpbox.

Das Gatewaysubnetz muss den Namen GatewaySubnet haben. Weisen Sie den Gatewaysubnetz-Adressraum basierend auf dem letzten Teil des VNet-Adressraums zu. Weitere Informationen finden Sie unter Verbinden eines lokalen Netzwerks mit Azure über ein VPN-Gateway.

Empfehlungen für virtuelle Computer

Für diese Architektur sind mindestens 44 Kerne erforderlich:

  • 8 SharePoint-Server mit Standard_DS3_v2 (jeweils vier Kerne) = 32 Kerne
  • 2 Active Directory-Domänencontroller mit Standard_DS1_v2 (jeweils ein Kern) = 2 Kerne
  • 2 SQL Server-VMs mit Standard_DS3_v2 = 8 Kerne
  • Ein Hauptknoten mit Standard_DS1_v2 = 1 Kern
  • Ein Verwaltungsserver mit Standard_DS1_v2 = 1 Kern

Für alle SharePoint-Rollen mit Ausnahme des Search-Indexers empfehlen wir die Verwendung der VM-Größe Standard_DS3_v2. Der Search-Indexer sollte mindestens die Größe Standard_DS13_v2 haben. Weitere Informationen finden Sie unter Hardware- und Softwareanforderungen für SharePoint Server 2016. Für die virtuellen SQL Server-Computer werden mindestens vier Kerne und 8 GB RAM empfohlen. Weitere Informationen finden Sie unter Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server).

Empfehlungen für Netzwerksicherheitsgruppen

Es wird die Verwendung einer Netzwerksicherheitsgruppe pro Subnetz empfohlen, in dem VMs enthalten sind, um die Subnetzisolation zu ermöglichen. Gehen Sie wie folgt vor, wenn Sie die Subnetzisolation konfigurieren möchten: Fügen Sie Regeln für Netzwerksicherheitsgruppen hinzu, mit denen der zulässige bzw. unzulässige ein- und ausgehende Datenverkehr für jedes Subnetz definiert wird. Weitere Informationen finden Sie unter Filtern des Netzwerkdatenverkehrs mit Netzwerksicherheitsgruppen.

Weisen Sie dem Gatewaysubnetz keine Netzwerksicherheitsgruppe zu, sonst funktioniert das Gateway nicht mehr.

Empfehlungen für Speicher

Die Speicherkonfiguration für die VMs der Farm sollte den jeweiligen bewährten Methoden entsprechen, die für lokale Bereitstellungen verwendet werden. SharePoint-Server sollten über einen separaten Datenträger für Protokolle verfügen. Für SharePoint-Server, die Suchindexrollen hosten, wird zusätzlicher Speicherplatz zum Speichern des Suchindex benötigt. Für SQL Server besteht das Standardverfahren darin, Daten und Protokolle zu trennen. Fügen Sie weitere Datenträger für die Speicherung von Datenbanksicherungen hinzu, und verwenden Sie einen separaten Datenträger für tempdb.

Wir empfehlen die Verwendung von Azure Managed Disks, um die beste Zuverlässigkeit zu erzielen. Mit Managed Disks (verwalteten Datenträgern) stellen Sie sicher, dass die Datenträger für VMs in einer Verfügbarkeitsgruppe isoliert sind, um Single Points of Failure zu vermeiden.

Verwenden Sie verwaltete Premium-Datenträger für alle SharePoint- und SQL Server-VMs. Sie können verwaltete Standard-Datenträger für den Hauptknotenserver, die Domänencontroller und den Verwaltungsserver nutzen.

SharePoint Server-Empfehlungen

Stellen Sie vor dem Konfigurieren der SharePoint-Farm sicher, dass Sie über ein Windows Server Active Directory-Dienstkonto pro Dienst verfügen. Für diese Architektur benötigen Sie mindestens die folgenden Konten auf Domänenebene, um die Berechtigungen pro Rolle zu isolieren:

  • SQL Server-Dienstkonto
  • Konto für Setupbenutzer
  • Konto für Serverfarm
  • Konto für Suchdienst
  • Konto für Inhaltszugriff
  • Web-App-Pool-Konten
  • Service App-Pool-Konten
  • Administratorkonto für Cache
  • Lese-Administratorkonto für Cache

Achten Sie darauf, die Search-Architektur richtig zu planen, um die Supportanforderung für den Datenträgerdurchsatz von mindestens 200 MB pro Sekunde zu erfüllen. Informationen hierzu finden Sie unter Planen der Architektur der Unternehmenssuche in SharePoint Server 2013. Halten Sie sich auch an die Richtlinien unter Bewährte Methoden zum Durchsuchen per Crawler in SharePoint Server 2016.

Speichern Sie außerdem die Suchkomponentendaten auf einem separaten Speichervolume oder einer Partition mit hoher Leistung. Konfigurieren Sie die Objektcache-Benutzerkonten, die in dieser Architektur erforderlich sind, um die Last zu reduzieren und den Durchsatz zu verbessern. Teilen Sie die Dateien des Windows Server-Betriebssystems, die SharePoint Server 2016-Programmdateien und die Diagnoseprotokolle auf drei separate Speichervolumes oder Partitionen mit normaler Leistung auf.

Weitere Informationen zu diesen Empfehlungen finden Sie unter Erstmalige Bereitstellung von Administrator- und Dienstkonten in SharePoint Server 2016.

Hybrid-Workloads

Mit dieser Referenzarchitektur wird eine SharePoint Server 2016-Farm bereitgestellt, die als SharePoint-Hybridumgebung zur Erweiterung von SharePoint Server 2016 auf SharePoint Online verwendet werden kann. Wenn Sie über Office Online Server verfügen, helfen Ihnen die Informationen unter Office Web Apps und Office für die Unterstützung von Webservern in Azure und anderen IaaS-Anbietern weiter.

Die Standarddienstanwendungen dieser Lösung sind für die Unterstützung von Hybridworkloads ausgelegt. Alle SharePoint Server 2016- und Microsoft 365-Hybridworkloads können bis auf eine Ausnahme ohne Änderungen der SharePoint-Infrastruktur für diese Farm bereitgestellt werden: Die Hybrid-Suchdienstanwendung für die Cloud darf nicht auf Servern bereitgestellt werden, die eine vorhandene Suchtopologie hosten. Aus diesem Grund muss der Farm mindestens eine VM hinzugefügt werden, die auf Suchrollen basiert, um dieses Hybridszenario zu unterstützen.

SQL Server Always On-Verfügbarkeitsgruppen

Für diese Architektur werden SQL Server-VMs genutzt, da Azure SQL-Datenbank für SharePoint Server 2016 nicht verwendet werden kann. Zur Unterstützung der Hochverfügbarkeit in SQL Server empfehlen wir die Verwendung von Always On-Verfügbarkeitsgruppen, mit denen eine Gruppe von Datenbanken angegeben wird, für die das Failover zusammen durchgeführt wird. Dies führt dazu, dass sie hoch verfügbar und wiederherstellbar sind. Weitere Informationen finden Sie unter Erstellen der Verfügbarkeitsgruppe und Hinzufügen der SharePoint-Datenbanken.

Außerdem wird empfohlen, dem Cluster eine Listener-IP-Adresse hinzuzufügen, bei der es sich um die private IP-Adresse des internen Lastenausgleichs für die SQL Server-VMs handelt.

Die empfohlenen VM-Größen und andere Leistungsempfehlungen für SQL Server in Azure finden Sie unter Leistungsrichtlinien für SQL Server in Azure Virtual Machines. Halten Sie sich auch an die Empfehlungen unter Bewährte Methoden für SQL Server in einer SharePoint Server-Farm.

Es wird empfohlen, den Hauptknotenserver auf einem andern Computer als die Replikationspartner anzuordnen. Mit dem Server kann der sekundäre Replikationspartnerserver in einer Hochsicherheitsmodus-Sitzung erkennen, ob ein automatisches Failover initiiert werden soll. Im Gegensatz zu den beiden Partnern dient der Hauptknotenserver nicht als Server für die Datenbank, sondern unterstützt das automatische Failover.

Ü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.

Skalierbarkeit

Ändern Sie die VM-Größe, um die vorhandenen Server hochzuskalieren.

Mit der Funktion MinRoles in SharePoint Server 2016 können Sie Server basierend auf der Rolle des Servers aufskalieren und außerdem Server aus einer Rolle entfernen. Wenn Sie die Server einer Rolle hinzufügen, können Sie beliebige einzelne Rollen oder eine kombinierte Rolle angeben. Sie müssen die Suchtopologie aber mit PowerShell neu konfigurieren, wenn Sie der Search-Rolle Server hinzufügen. Sie können Rollen auch mit MinRoles konvertieren. Weitere Informationen finden Sie unter Verwalten einer MinRole-Serverfarm in SharePoint Server 2016.

SharePoint Server 2016 unterstützt nicht die Verwendung von Virtual Machine Scale Sets für die automatische Skalierung.

Verfügbarkeit

Diese Referenzarchitektur unterstützt Hochverfügbarkeit in einer Azure-Region, da für jede Rolle in einer Verfügbarkeitsgruppe mindestens zwei VMs bereitgestellt werden.

Erstellen Sie als Schutz vor einem regionalen Ausfall eine separate Farm für die Notfallwiederherstellung in einer anderen Azure-Region. Ihre Recovery Time Objectives (RTOs) und Recovery Point Objectives (RPOs) bestimmen die Anforderungen für die Einrichtung. Ausführliche Informationen finden Sie unter Wählen einer Notfallwiederherstellungsstrategie für SharePoint Server 2016. Die sekundäre Region muss mit der primären Region gekoppelt sein und ein Regionspaar bilden. Im Falle eines umfassenden Ausfalls hat bei jedem Regionspaar die Wiederherstellung einer der Regionen Priorität. Weitere Informationen finden Sie unter Geschäftskontinuität und Notfallwiederherstellung: Azure-Regionspaare.

Verwaltbarkeit

Befolgen Sie die empfohlenen Methoden für SharePoint-Vorgänge zum Betreiben und Verwalten von Servern, Serverfarmen und Sites. Weitere Informationen finden Sie unter Vorgänge für SharePoint Server 2016.

Die erforderlichen Aufgaben beim Verwalten von SQL Server in einer SharePoint-Umgebung können sich von den Aufgaben unterscheiden, die normalerweise für eine Datenbankanwendung anfallen. Eine bewährte Methode ist das vollständige Sichern aller SQL-Datenbanken einmal pro Woche mit inkrementellen Sicherungen jede Nacht. Sichern Sie Transaktionsprotokolle alle 15 Minuten. Eine andere Methode ist das Implementieren von SQL Server-Wartungsaufgaben in den Datenbanken, während die integrierten SharePoint-Aufgaben deaktiviert werden. Weitere Informationen finden Sie unter Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server).

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“.

Für die Dienstkonten der Domänenebene zum Ausführen von SharePoint Server 2016 sind Windows Server AD-Domänencontroller oder Microsoft Entra Domain Services für den Domänenbeitritt und die Authentifizierung erforderlich. Zum Erweitern der Windows Server AD-Identitätsinfrastruktur, die im Intranet bereits vorhanden ist, nutzt diese bestimmte Architektur jedoch zwei virtuelle Computer als Windows Server AD-Replikatdomänencontroller einer vorhandenen lokalen Windows Server AD-Gesamtstruktur.

Außerdem ist es immer ratsam, mit Blick auf die Sicherheitshärtung zu planen. Weitere Empfehlungen sind:

  • Fügen Sie den Netzwerksicherheitsgruppen Regeln hinzu, um Subnetze und Rollen zu isolieren.
  • Vermeiden Sie es, VMs öffentliche IP-Adressen zuzuweisen.
  • Erwägen Sie für die Angriffserkennung und die Analyse von Nutzlasten die Verwendung eines virtuellen Netzwerkgeräts vor den Front-End-Webservern anstelle eines internen Azure Load Balancers.
  • Sie können optional IPsec-Richtlinien für die Verschlüsselung von Klartext-Datenverkehr zwischen Servern verwenden. Wenn Sie auch die Subnetzisolation durchführen, sollten Sie Ihre Netzwerksicherheitsgruppen-Regeln aktualisieren, um IPsec-Datenverkehr zuzulassen.
  • Installieren Sie Antischadsoftware-Agents für die VMs.

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“.

Verwenden Sie den Azure-Preisrechner, um die voraussichtlichen Kosten zu ermitteln. Hier sind einige Faktoren für die Optimierung der Kosten für diese Architektur aufgeführt.

Active Directory Domain Services

Ziehen Sie in Betracht, Active Directory Domain Services als gemeinsam genutzten Dienst zu verwenden, der von mehreren Workloads genutzt wird, um die Kosten zu senken. Weitere Informationen finden Sie unter Active Directory Domain Services – Preise.

VPN Gateway

Das Abrechnungsmodell basiert auf der Bereitstellungs- und Verfügbarkeitsdauer des Gateways. Weitere Informationen finden Sie unter VPN Gateway – Preise.

Der gesamte eingehende Datenverkehr ist kostenfrei. Der gesamte ausgehende Datenverkehr wird in Rechnung gestellt. Für ausgehenden VPN-Datenverkehr gelten Internetbandbreitenkosten.

Virtual Network

Virtual Network ist kostenlos. Mit jedem Abonnement können bis zu 50 virtuelle Netzwerke in allen Regionen erstellt werden. Der gesamte Datenverkehr, der innerhalb der Grenzen eines virtuellen Netzwerks entsteht, ist kostenlos. Die Kommunikation zwischen zwei virtuellen Computern im selben virtuellen Netzwerk ist also kostenlos.

Diese Architektur baut auf der Architektur auf, die in [Ausführen von Windows-VMs für eine n-schichtige Anwendung][Windows-n-Schichten] bereitgestellt ist.

Weitere Informationen finden Sie im Abschnitt zu Kosten im Microsoft Azure Well-Architected Framework.

DevOps

Verwenden Sie ggf. separate Ressourcengruppen für Produktions-, Entwicklungs- und Testumgebungen. Separate Ressourcengruppen erleichtern das Verwalten von Bereitstellungen, das Löschen von Testbereitstellungen und das Zuweisen von Zugriffsrechten. Platzieren Sie Ressourcen mit gleichem Lebenszyklus im Allgemeinen in der gleichen Ressourcengruppe. Verwenden Sie für Entwicklungs- und Testumgebungen den Developer-Tarif. Zur Kostenminimierung während der Präproduktion stellen Sie ein Replikat Ihrer Produktionsumgebung bereit, führen die Tests aus und fahren das Replikat dann herunter.

Verwenden Sie Azure Resource Manager-Vorlagen oder Azure-Bicep-Vorlagen zum Definieren der Infrastruktur. In beiden Fällen befolgen Sie die IaC-Praktiken (Infrastructure-as-a-Code) zum Bereitstellen der Ressourcen. Zum Automatisieren der Infrastrukturbereitstellung eignen sich Azure DevOps Services oder andere CI/CD-Lösungen. Darüber hinaus ist der Bereitstellungsprozess idempotent. Dies bedeutet, dass er wiederholbar ist, damit gleiche Ergebnisse erzeugt werden können. Azure Pipelines ist Teil von Azure DevOps Services und führt automatisierte Build-, Test- und Bereitstellungsvorgänge durch.

Strukturieren Sie Ihre Bereitstellungsvorlagen entsprechend den Workloadkriterien. Ermitteln Sie einzelne Arbeitseinheiten, und schließen Sie diese in eigene Vorlagen ein. In diesem Szenario werden mindestens sieben Workloads ermittelt und in eigenen Vorlagen isoliert: das virtuelle Azure-Netzwerk und das VPN-Gateway, die Verwaltungsjumpbox, AD-Domänencontroller und SQL Server-VMs, der Failovercluster und die Verfügbarkeitsgruppe sowie die übrigen VMs, der primäre SharePoint-Knoten, der SharePoint-Cache und die Regeln für Netzwerksicherheitsgruppen. Die Workloadisolation macht es leichter, die spezifischen Ressourcen einer Workload einem Team zuzuordnen, damit das Team unabhängig alle Aspekte dieser Ressourcen verwalten kann. Diese Isolation ermöglicht DevOps die Durchführung von Continuous Integration und Continuous Delivery (CI/CD). Diese Konfiguration ermöglicht auch das Staging Ihrer Workloads, d. h. die Bereitstellung in verschiedenen Stufen, für die jeweils Überprüfungen durchgeführt werden, bevor der Wechsel zur nächsten Stufe erfolgt. Auf diese Weise können Sie bei umfassender Kontrolle Aktualisierungen in Ihre Produktionsumgebungen pushen und unerwartete Bereitstellungsprobleme minimieren.

Erwägen Sie die Nutzung von Azure Monitor, um die Leistung Ihrer Infrastruktur zu analysieren und zu optimieren, die Überwachung durchzuführen und Netzwerkprobleme zu diagnostizieren, ohne dass Sie sich bei Ihren VMs anmelden müssen.

Weitere Informationen finden Sie unter Azure Well-Architected Framework im Abschnitt zu DevOps.

Nächste Schritte

Weitere Informationen zu den einzelnen Teilen der Lösungsarchitektur finden Sie in den folgenden Themen: