Azure Virtual Machines-Basisarchitektur

Dieser Artikel enthält eine grundlegende Referenzarchitektur für eine Workload, die auf Azure Virtual Machines bereitgestellt wird.

Die von dieser Architektur angenommene Beispielarbeitsauslastung ist eine webbasierte Webanwendung mit mehreren Ebenen, die auf separaten Gruppen virtueller Computer (VMs) bereitgestellt wird. VMs werden als Teil von Azure Virtual Machine Scale Sets-Bereitstellungen bereitgestellt. Diese Architektur kann für diese Szenarien verwendet werden:

• Private Anwendungen. Zu diesen Anwendungen gehören interne Geschäftsanwendungen oder kommerzielle Off-the-Shelf-Lösungen.
• Öffentliche Anwendungen. Diese Anwendungen sind internetorientierte Anwendungen. Diese Architektur ist nicht für Hochleistungsrechner, unternehmenskritische Workloads, Anwendungen, die von Latenz oder anderen speziellen Anwendungsfällen stark betroffen sind.

Der Hauptfokus dieser Architektur ist nicht die Anwendung. Stattdessen enthält dieser Artikel Anleitungen zum Konfigurieren und Bereitstellen der Infrastrukturkomponenten, mit denen die Anwendung interagiert. Zu diesen Komponenten gehören Compute-, Speicher-, Netzwerk- und Überwachungskomponenten.

Diese Architektur dient als Ausgangspunkt für eine Infrastruktur-as-a-Service (IaaS)-gehostete Workload. Die Datenebene wird absichtlich von dieser Anleitung ausgeschlossen, um den Schwerpunkt weiterhin auf die Recheninfrastruktur zu legen.

Artikel-Layout

Aufbau	Entwurfsentscheidung	Hochwertiger Frameworkansatz
▪ Architekturdiagramm ▪ Workloadressourcen ▪ Unterstützende Ressourcen Benutzerflows	▪ VM-Entwurfsmöglichkeiten ▪ Disks ▪ Netzwerk ▪ Überwachung ▪ Updateverwaltung	▪ Zuverlässigkeit ▪ Sicherheit ▪ Kostenoptimierung

Aufbau

Laden Sie eine Visio-Datei dieser Architektur herunter.

Informationen zu diesen Ressourcen finden Sie in der Azure-Produktdokumentation, die in verwandten Ressourcen aufgeführt ist.

Komponenten

Diese Architektur besteht aus mehreren Azure-Diensten für Workloadauslastungsressourcen und Workload-Unterstützende Ressourcen. Die Dienste für jede von ihnen und ihre Rollen werden in den folgenden Abschnitten beschrieben.

Workloadressourcen

• Virtuelle Azure-Computer dienen als Computeressource für die Anwendung und werden über Verfügbarkeitszonen verteilt. Zur Veranschaulichung wird eine Kombination aus Windows- und Linux-VMs verwendet.

  Azure Virtual Machine Scale Sets im Orchestrierungsmodus Flexible werden zum Bereitstellen und Verwalten der VMs verwendet.

  Die Beispielanwendung kann in zwei Ebenen dargestellt werden, die jeweils eine eigene Berechnung erfordern.

  • Das Front-End führt den Webserver aus und empfängt Benutzeranforderungen.
  • Das Back-End führt einen anderen Webserver aus, der als Web-API fungiert und einen einzelnen Endpunkt verfügbar macht, auf dem die Geschäftslogik ausgeführt wird.

  Die Front-End-VMs verfügen über angefügte Datenträger (Premium_LRS), die zum Bereitstellen einer zustandslosen Anwendung verwendet werden können. Die Back-End-VMs speichern Daten in Premium_ZRS lokalen Datenträgern als Teil des Vorgangs. Dieses Layout kann erweitert werden, um eine Datenbankebene zum Speichern des Zustands aus dem Front-End- und Back-End-Compute einzuschließen. Diese Ebene liegt außerhalb des Umfangs dieser Architektur.

• Azure Virtual Network bietet ein privates Netzwerk für alle Workloadressourcen. Das Netzwerk wird in Subnetze unterteilt, die als Isolationsgrenzen dienen.

• Azure Application Gateway ist der einzelne Ausgangspunkt, der Anforderungen an die Front-End-Server weitergibt. Die ausgewählte SKU enthält integrierte Azure Web Application Firewall (WAF) für zusätzliche Sicherheit.

• Der interne Azure Load Balancer leitet Datenverkehr von der Front-End-Ebene an die Back-End-Server weiter.

• Azure Load Balancer Standard-SKU bietet ausgehenden Internetzugriff auf die VMs mit drei öffentlichen IP-Adressen.

• Azure Key Vault speichert die Zertifikate, die für die Tls-Kommunikation (End-to-End Transport Layer Security, TLS) verwendet werden. Es kann auch für Anwendungsgeheimnisse verwendet werden.

Workload, die Ressourcen unterstützt

• Azure Bastion bietet betriebsbereiten Zugriff auf die VMs über sichere Protokolle.

• Application Insights sammelt Protokolle und Metriken von der Anwendung. Da die Anwendung nicht den Fokus dieser Architektur hat, wird die Protokollsammlung in der Implementierung nicht veranschaulicht.

• Log Analytics ist die Überwachungsdatensenke, die Protokolle und Metriken aus den Azure-Ressourcen und Application Insights sammelt. Ein Speicherkonto wird als Teil des Workspace bereitgestellt.

Benutzerabläufe

Es gibt zwei Arten von Benutzern, die mit den Workloadressourcen interagieren: den Workload-Benutzer und den Operator. Die Flows für diese Benutzer werden im vorherigen Architekturdiagramm angezeigt.

Workload-Benutzer

1. Der Benutzer greift mithilfe der verfügbar gemachten öffentlichen IP-Adresse des Application Gateways auf die Website zu.

2. Das Application Gateway empfängt HTTPS-Datenverkehr, entschlüsselt Daten mithilfe eines externen Zertifikats für die WAF-Inspektion und verschlüsselt sie erneut mithilfe des internen Wildcard-Zertifikats für den Transport an das Front-End.

3. Das Application Gateway bezieht sich auf Front-End-VMs und leitet die Anforderung an eine Front-End-VM weiter.

4. Die ausgewählte Front-End-VM kommuniziert mit einer Back-End-VM mithilfe der privaten IP-Adresse des Load Balancer, nicht mit der IP einer einzelnen VM. Diese Kommunikation wird auch mit dem internen Wildcard-Zertifikat verschlüsselt.

5. Die Back-End-VM entschlüsselt die Anforderung mithilfe des internen Zertifikats. Nachdem das Back-End die Anforderung verarbeitet hat, gibt es das Ergebnis an das Front-End zurück, das das Ergebnis an das Application Gateway zurückgibt und schließlich das Ergebnis an den Benutzer zurückgibt.

Operator

Die virtuellen Computer in dieser Architektur erfordern möglicherweise direkten Zugriff durch Operatoren, es wird jedoch empfohlen, dass der Remotezugriff durch Automatisierung minimiert wird und dass der Zugriff überwacht wird. Der Zugriff kann sich auf Unterbrechungssituationen, Problembehandlung oder einen Teil eines automatisierten Bereitstellungsprozesses auswirken. Diese Architektur verfügt nicht über öffentliche IPs zum Steuern des Zugriffs auf die Ebene. Azure Bastion fungiert als serverloses Gateway, sodass Vorgänge über SSH oder RDP auf VMs zugreifen können. Durch diese Einrichtung wird eine sichere und effiziente Zugriffsverwaltung sichergestellt.

1. Der Operator meldet sich bei der Azure-Portal oder Azure CLI an.
2. Der Operator greift auf den Azure Bastion-Dienst zu und stellt remote eine Verbindung mit der gewünschten VM her.

VM-Entwurfsmöglichkeiten

Bei der Auswahl von SKUs ist es wichtig, eine grundlegende Leistungserwartungen zu haben. Verschiedene Merkmale beeinflussen den Entscheidungsprozess, darunter:

• CPU-, Arbeitsspeicher- und Datenträgereingabe-/Ausgabevorgänge pro Sekunde (IOPS).
• Architektur des Prozessors.
• Imagegröße des Betriebssystems (OS).

Wenn Sie beispielsweise eine Workload von einer lokalen Umgebung migrieren, die Intel-Prozessorcomputer erfordert, wählen Sie VM-SKUs aus, die Intel-Prozessoren unterstützen.

Informationen zu den unterstützten VM-SKUs finden Sie unter Größen für virtuelle Computer in Azure.

Bootstrapping

VMs müssen häufig bootstrapped sein, bei dem es sich um einen Prozess handelt, in dem VMs vorbereitet und für die Ausführung der Anwendung optimiert werden. Zu den allgemeinen Bootstrapping-Aufgaben gehören: Installieren von Zertifikaten, Konfigurieren des Remotezugriffs, Installieren von Paketen, Optimieren und Härtung der Betriebssystemkonfiguration sowie Formatierung und Montage von Datenträgern. Es ist wichtig, den Bootstrapping-Prozess so weit wie möglich zu automatisieren, damit die Anwendung ohne Verzögerung oder manuelle Intervention auf dem virtuellen Computer gestartet werden kann. Hier sind die Empfehlungen für die Automatisierung:

• VM-Erweiterungen. Diese Erweiterungen sind Azure Resource Manager-Objekte, die über Ihre Infrastructure-as-Code (IaC)-Bereitstellung verwaltet werden. Auf diese Weise wird jeder Fehler als fehlgeschlagene Bereitstellung gemeldet, für die Sie Maßnahmen ergreifen können. Wenn für Ihre Bootstrapping-Anforderungen keine Erweiterung vorhanden ist, erstellen Sie benutzerdefinierte Skripts. Es wird empfohlen, die Skripts über die Azure Custom Script Extension auszuführen.

  Im Folgenden finden Sie einige weitere Erweiterungen, die zum automatischen Installieren oder Konfigurieren von Funktionen auf den virtuellen Computern verwendet werden können.

  • Der Azure Monitor-Agent (AMA) sammelt Überwachungsdaten vom Gastbetriebssystem und übermittelt sie an Azure Monitor.
  • Die Azure Custom Script Extension (Windows, Linux) Version 2 lädt Skripts herunter und führt sie auf virtuellen Azure-Maschinen (VMs) aus. Diese Erweiterung ist hilfreich für die Automatisierung der Konfiguration nach der Bereitstellung, bei der Softwareinstallation oder bei anderen Konfigurations- oder Verwaltungsaufgaben.
  • Die Azure Key Vault-Erweiterung für VMs (Windows, Linux) ermöglicht die automatische Aktualisierung von in einem Key Vault gespeicherten Zertifikaten, indem sie Änderungen erkennt und die entsprechenden Zertifikate installiert.
  • Anwendungsintegritätserweiterung mit Virtual Machine Scale Sets für virtuelle Computer sind wichtig, wenn Azure Virtual Machine Scale Sets automatische Rollupgrades durchführt. Azure basiert auf der Integritätsüberwachung der einzelnen Instanzen, um die Updates zu erledigen. Sie können die Erweiterung auch verwenden, um den Anwendungszustand jeder Instanz in Ihrer Skalierungsgruppe zu überwachen und Instanzreparaturen mithilfe der automatischen Instanzreparaturen durchzuführen.
  • Microsoft Entra ID und OpenSSH (Windows, Linux) sind in die Microsoft Entra-Authentifizierung integriert. Sie können jetzt Microsoft Entra ID als zentrale Authentifizierungsplattform und Zertifizierungsstelle verwenden, um mithilfe von Microsoft Entra ID und der auf OpenSSH-Zertifikaten basierenden Authentifizierung eine SSH-Verbindung mit einer Linux-VM herzustellen. Mit dieser Funktion können Sie den Zugriff auf VMs mit der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) von Azure und Richtlinien für bedingten Zugriff verwalten.

• Agentbasierte Konfiguration. Linux-VMs können eine einfache systemeigene Zustandskonfiguration verwenden, die über cloud-init auf verschiedenen von Azure bereitgestellten VM-Images verfügbar ist. Die Konfiguration wird angegeben und mit Ihren IaC-Artefakten versioniert. Die Bereitstellung Ihrer eigenen Konfigurationsverwaltungslösung ist eine weitere Möglichkeit. Die meisten Lösungen folgen einem deklarativen ersten Ansatz zum Bootstrapping, unterstützen jedoch benutzerdefinierte Skripts für Flexibilität. Beliebte Auswahlmöglichkeiten sind die gewünschte Zustandskonfiguration für Windows, die gewünschte Zustandskonfiguration für Linux, Ansible, Chef, Puppet und andere. Alle diese Konfigurationslösungen können mit VM-Erweiterungen kombiniert werden, um eine optimale Benutzererfahrung zu erzielen.

In der Referenzimplementierung erfolgt die gesamte Bootstrapping über VM-Erweiterungen und benutzerdefinierte Skripts, einschließlich eines benutzerdefinierten Skripts zum Automatisieren der Formatierung und Montage von Datendatenträgern.

Weitere Informationen finden Sie unter Well-Architected Framework: RE:02 - Empfehlungen für automatisierungsdesign.

VM-Konnektivität

Um eine private Kommunikation zwischen einer VM und anderen Geräten in einem bestimmten virtuellen Netzwerk zu ermöglichen, wird die Netzwerkschnittstellenkarte (NIC) der VM mit einem der Subnetze des virtuellen Netzwerks verbunden. Wenn Sie mehrere Netzwerkschnittstellenkarten für Ihre VM benötigen, müssen Sie wissen, dass für jede VM-Größe eine maximale Anzahl von NICs definiert ist.

Wenn die Workload die Kommunikation zwischen VMs im virtuellen Netzwerk mit geringer Latenz benötigt, sollten Sie eine beschleunigte Netzwerkverbindung in Betracht ziehen, die von Azure VM NICs unterstützt wird. Weitere Informationen finden Sie unter Vorteile beschleunigter Netzwerke.

VM-Skalierungsgruppen mit flexibler Orchestrierung

VMs werden als Teil von Virtual Machine Scale Sets mit flexibler Orchestrierung bereitgestellt. Virtual Machine Scale Sets sind logische Gruppierungen von VMs, die für die Erfüllung geschäftlicher Anforderungen verwendet werden. Die Typen von VMs in einer Gruppierung können identisch oder unterschiedlich sein. Sie ermöglichen es Ihnen, den Lebenszyklus von Computern, Netzwerkschnittstellen und Datenträgern mithilfe standardmäßiger Azure-VM-APIs und -Befehle zu verwalten.

Der flexible Orchestrierungsmodus erleichtert die Skalierung und hilft bei präzisen Skalierungsentscheidungen.

Die Konfiguration der Fehlerdomäne ist erforderlich, um die Auswirkungen von physischen Hardwareausfällen, Netzwerkausfällen oder Stromunterbrechungen zu begrenzen. Mit Skalierungssätzen verteilt Azure Instanzen gleichmäßig auf Fehlerdomänen, um die Ausfallsicherheit gegenüber einem einzelnen Hardware- oder Infrastrukturproblem zu gewährleisten.

Wir empfehlen, dass Sie die Fehlerdomänenzuweisung nach Azure verlagern, um eine maximale Instanzverteilung zu erreichen und die Ausfallsicherheit und Verfügbarkeit zu verbessern.

Datenträger

Zum Ausführen der Betriebssystem- und Anwendungskomponenten sind Speicherdatenträger an die VM angefügt. Erwägen Sie die Verwendung von kurzlebigen Datenträgern für das Betriebssystem und verwaltete Datenträger für die Datenspeicherung.

Azure bietet eine Reihe von Optionen hinsichtlich Leistung, Vielseitigkeit und Kosten. Beginnen Sie mit Premium SSD für die meisten Produktionsworkloads. Ihre Wahl hängt von der VM-SKU ab. SKUs, die Premium SSD unterstützen, enthalten einen s im Ressourcennamen, z. B. Dsv4, aber nicht Dv4.

Weitere Informationen zu den Datenträgeroptionen mit Metriken wie Kapazität, IOPS und Durchsatz finden Sie im Datenträgertypvergleich.

Berücksichtigen Sie die Datenträgermerkmale und Leistungserwartungen beim Auswählen eines Datenträgers.

• VM SKU-Einschränkungen. Datenträger arbeiten innerhalb der VM, an die sie angefügt sind, die IOPS- und Durchsatzgrenzwerte aufweisen. Stellen Sie sicher, dass der Datenträger die Grenzen des virtuellen Computers nicht begrenzt und umgekehrt. Wählen Sie die Datenträgergröße, Leistung und VM-Funktionen (Kern, CPU, Arbeitsspeicher) aus, die die Anwendungskomponente optimal ausführen. Vermeiden Sie die Überlastung, da sie sich auf Kosten auswirkt.

• Konfigurationsänderungen. Sie können einige Datenträgerleistungs- und Kapazitätskonfigurationen ändern, während eine VM ausgeführt wird. Viele Änderungen können jedoch eine erneute Bereitstellung und Neuerstellung von Datenträgerinhalten erfordern, was sich auf die Workloadauslastungsverfügbarkeit auswirkt. Planen Sie daher die Auswahl von Datenträgern und VM-SKU sorgfältig, um die Auswirkungen auf die Verfügbarkeit und ie Überarbeitung zu minimieren.

• Kurzlebige Betriebssystemdatenträger Bereitstellen von Betriebssystemdatenträgern als kurzlebige Datenträger. Verwenden Sie verwaltete Datenträger nur, wenn Betriebssystemdateien beibehalten werden müssen. Vermeiden Sie die Verwendung von kurzlebigen Datenträgern zum Speichern von Anwendungskomponenten und -zustand.

  Die Kapazität von kurzlebigen Betriebssystemdatenträgern hängt von der ausgewählten VM-SKU ab. Stellen Sie sicher, dass die Größe des Betriebssystemimagedatenträgers kleiner als der verfügbare Cache oder der temporäre Datenträger der SKU ist. Den verbleibenden Platz können Sie zur Zwischenspeicherung nutzen.

• Datenträgerleistung. Der Vorabbereitstellungsspeicher basierend auf Spitzenlasten ist üblich, kann jedoch zu nicht genutzten Ressourcen führen, da die meisten Workloads Spitzenlasten nicht erhalten.

  Überwachen Sie die Verwendungsmuster Ihrer Workload, notieren Sie Spitzen oder anhaltende Lesevorgänge, und berücksichtigen Sie diese Muster in Ihre VM und die Auswahl der verwalteten Datenträger-SKU.

  Sie können die Leistung bei Bedarf anpassen, indem Sie Leistungsstufen ändern oder die in einigen verwalteten Datenträger-SKUs angebotenen Platzfunktionen verwenden.

  Während die Überprovisionierung den Bedarf an Platzen reduziert, kann dies zu nicht genutzter Kapazität führen, für die Sie bezahlen. Kombinieren Sie idealerweise beide Features für optimale Ergebnisse.

• Optimieren sie die Zwischenspeicherung für die Workload. Konfigurieren Sie Cacheeinstellungen für alle Datenträger basierend auf der Anwendungskomponentenverwendung.

  Komponenten, die hauptsächlich Lesevorgänge ausführen, erfordern keine Transaktionskonsistenz auf hoher Festplatte. Diese Komponenten können von der schreibgeschützten Zwischenspeicherung profitieren. Bei schreibintensiven Komponenten, die eine hohe Transaktionskonsistenz auf der Festplatte erfordern, ist das Zwischenspeichern häufig deaktiviert.

  Die Verwendung der Zwischenspeicherung mit Lese-/Schreibzugriff kann zu Datenverlust führen, wenn die VM abstürzt und für die meisten Datenträgerszenarien nicht empfohlen wird.

In diesem Architekturmodell:

• Die Betriebssystemdatenträger aller virtuellen Computer sind kurzlebig und befinden sich auf dem Cachedatenträger.

  Die Workload-Anwendung im Front-End (Linux) und Back-End (Windows Server) sind tolerant für einzelne VM-Fehler und verwenden beide kleine Images (ca. 30 GB). Durch solche Attribute sind sie für die Verwendung kurzlebiger Betriebssystemdatenträger geeignet, die als Teil des lokalen VM-Speichers (Cache-Partition) erstellt wurden, anstelle von persistenten Betriebssystemdatenträgern, die in Remote-Azure-Speicherressourcen gespeichert sind. Diese Situation verursacht keine Speicherkosten für Betriebssystemdatenträger und verbessert auch die Leistung, indem niedrigere Latenzen bereitgestellt und die Vm-Bereitstellungszeit reduziert wird.

• Jede VM verfügt über einen eigenen verwalteten Premium SSD P1-Datenträger, der einen basisbereitstellungsgesteuerten Durchsatz bereitstellt, der für die Workload geeignet ist.

Netzwerklayout

Diese Architektur stellt die Workload in einem einzelnen virtuellen Netzwerk bereit. Netzwerksteuerelemente sind ein wichtiger Bestandteil dieser Architektur und werden im Abschnitt Sicherheit beschrieben.

Dieses Layout kann in eine Unternehmenstopologie integriert werden. Dieses Beispiel wird in der Basisarchitektur des virtuellen Computers in einer Azure-Zielzone gezeigt.

Virtuelles Netzwerk

Eine Ihrer anfänglichen Netzwerklayoutentscheidungen bezieht sich auf den Netzwerkadressbereich. Denken Sie daran, dass das erwartete Netzwerkwachstum während der Kapazitätsplanungsphase zu erwarten ist. Das Netzwerk sollte groß genug sein, um das Wachstum aufrechtzuerhalten, was möglicherweise zusätzliche Netzwerkkonstrukte benötigt. Beispielsweise sollte das virtuelle Netzwerk über die Kapazität verfügen, um die anderen virtuellen Computer aufzunehmen, die aus einem Skalierungsvorgang resultieren.

Passen Sie umgekehrt die Größe Ihres Adressraums an. Ein übermäßig großes virtuelles Netzwerk kann zu Unternutzung führen. Es ist wichtig zu beachten, dass der Adressbereich nicht geändert werden kann, nachdem das virtuelle Netzwerk erstellt wurde.

In dieser Architektur wird der Adressraum auf /21 festgelegt, eine Entscheidung basierend auf dem projizierten Wachstum.

Überlegungen zur Subnetzierung

Innerhalb des virtuellen Netzwerks werden Subnetze basierend auf Den Funktionalitäts- und Sicherheitsanforderungen unterteilt, wie hier beschrieben:

• Ein Subnetz zum Hosten des Anwendungsgateways, das als Reverseproxy dient. Für Application Gateway ist standardmäßig ein dediziertes Subnetz erforderlich.
• Ein Subnetz zum Hosten des internen Lastenausgleichs zum Verteilen von Datenverkehr an Back-End-VMs.
• Subnetze zum Hosten der Workload-VMs, eines für Front-End und eines für Back-End. Diese Subnetze werden gemäß den Ebenen der Anwendung erstellt.
• Ein Subnetz für den Azure Bastion-Host, um den betriebsbereiten Zugriff auf die VMs der Workload zu erleichtern. Standardmäßig benötigt der Azure Bastion-Host ein dediziertes Subnetz.
• Ein Subnetz zum Hosten privater Endpunkte, die für den Zugriff auf andere Azure-Ressourcen über Azure Private Link erstellt wurden. Obwohl dedizierte Subnetze für diese Endpunkte nicht obligatorisch sind, werden sie empfohlen.

Ähnlich wie bei virtuellen Netzwerken müssen Subnetze die richtige Größe aufweisen. Sie können beispielsweise die maximale Grenze von virtuellen Computern anwenden, die von flexiblen Orchestrierung unterstützt werden, um die Skalierungsanforderungen der Anwendung zu erfüllen. Die Workload-Subnetze sollten in der Lage sein, diesen Grenzwert zu berücksichtigen.

Ein weiterer zu berücksichtigende Anwendungsfall ist VM-Betriebssystemupgrades, die möglicherweise temporäre IP-Adressen erfordern. Mit der richtigen Größenanpassung erhalten Sie die gewünschte Segmentierungsebene, indem Sie sicherstellen, dass ähnliche Ressourcen gruppiert werden, damit sinnvolle Sicherheitsregeln über Netzwerksicherheitsgruppen (NSGs) auf die Subnetzgrenzen angewendet werden können. Weitere Informationen finden Sie unter Sicherheit: Segmentierung.

Eingehender Datenverkehr

Zwei öffentliche IP-Adressen werden für Eingangsflows verwendet. Eine Adresse ist für das Anwendungsgateway, das als Reverseproxy dient. Benutzer stellen eine Verbindung mit dieser öffentlichen IP-Adresse her. Der Reverse-Proxy verteilt den eingehenden Datenverkehr auf die privaten IP-Adressen der VMs. Die andere Adresse ist für den betriebsbereiten Zugriff über Azure Bastion vorgesehen.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Ausgehender Datenverkehr

Diese Architektur verwendet standardmäßige SKU-Load Balancer mit ausgehenden Regeln, die von den VM-Instanzen definiert sind. Der Load Balancer wurde ausgewählt, da er zonenredundant ist.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Mit dieser Konfiguration können Sie die öffentlichen IP(s) Ihres Load Balancers verwenden, um ausgehende Internetkonnektivität für die VMs bereitzustellen. Mit den ausgehenden Regeln können Sie explizit SNAT-Ports (Source Network Address Translation) definieren. Mit den Regeln können Sie diese Möglichkeit durch manuelle Portzuweisung skalieren und optimieren. Die manuelle Zuweisung des SNAT-Ports basierend auf der Back-End-Poolgröße und der Anzahl von davon frontendIPConfigurationskann dazu beitragen, eine SNAT-Erschöpfung zu vermeiden.

Es wird empfohlen, Ports basierend auf der maximalen Anzahl von Back-End-Instanzen zuzuweisen. Wenn mehr Instanzen hinzugefügt werden, als die verbleibenden SNAT-Ports zulassen, werden möglicherweise Skalierungsvorgänge für Virtual Machine Scale Sets blockiert oder die neuen VMs erhalten nicht genügend SNAT-Ports.

CBerechnen Sie Ports pro Instanz wie folgt: Number of front-end IPs * 64K / Maximum number of back-end instances.

Es gibt weitere Optionen, die Sie verwenden können, z. B. das Bereitstellen einer Azure NAT-Gatewayressource, die an das Subnetz angefügt ist. Eine weitere Option besteht darin, Azure Firewall oder eine andere virtuelle Netzwerk-Appliance mit einer benutzerdefinierten Route (UDR) als nächsten Hop durch die Firewall zu verwenden. Diese Option wird in der Basisarchitektur des virtuellen Computers in einer Azure-Zielzone gezeigt.

DNS-Auflösung

Azure DNS wird als grundlegender Dienst für alle Lösungsanwendungsfälle verwendet, z. B. das Auflösen vollqualifizierter Do Standard Namen (FQDN), die den Workload-VMs zugeordnet sind. In dieser Architektur verwenden die VMs die DNS-Werte, die in der virtuellen Netzwerkkonfiguration festgelegt sind, was Azure DNS ist.

Private Azure-DNS-Zonen werden zum Auflösen von Anforderungen an die privaten Endpunkte verwendet, die für den Zugriff auf die benannten Private Link-Ressourcen verwendet werden.

Überwachung

Diese Architektur verfügt über einen Überwachungsstapel, der vom Dienstprogramm der Workload entkoppelt wird. Der Schwerpunkt liegt in erster Linie auf den Datenquellen- und Sammlungsaspekten.

Metriken und Protokolle werden in verschiedenen Datenquellen generiert, wodurch Erkenntnisse zur Observierbarkeit in verschiedenen Höhen bereitgestellt werden:

• Zugrunde liegende Infrastruktur und Komponenten werden berücksichtigt, z. B. VMs, virtuelle Netzwerke und Speicherdienste. Azure-Plattformprotokolle enthalten Informationen zu Vorgängen und Aktivitäten innerhalb der Azure-Plattform.

• Die Anwendungsebene bietet Einblicke in die Leistung und das Verhalten der Anwendungen, die auf Ihrem System ausgeführt werden.

Der Log Analytics-Arbeitsbereich ist die empfohlene Überwachungsdatensenke, die zum Sammeln von Protokollen und Metriken aus den Azure-Ressourcen und Application Insights verwendet wird.

Diese Abbildung zeigt den Überwachungsstapel für den Basisplan mit Komponenten zum Sammeln von Daten aus der Infrastruktur und Anwendung, Datensenken und verschiedenen Verbrauchstools für Analyse und Visualisierung. Die Implementierung stellt einige Komponenten bereit, z. B. Application Insights, VM-Start Diagnose und Log Analytics. Andere Komponenten werden dargestellt, um die Erweiterbarkeitsoptionen wie Dashboards und Warnungen darzustellen.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Überwachung auf Infrastrukturebene

Diese Tabelle enthält Links zu Protokollen und Metriken, die von Azure Monitor gesammelt werden. Die verfügbaren Warnungen helfen Ihnen dabei, Probleme proaktiv zu beheben, bevor sie sich auf Benutzer auswirken.

Azure-Ressource	Metriken und Protokolle	Alerts
Application Gateway	Beschreibung der Application Gateway-Metriken und -Protokolle	Application Gateway-Warnungen
Application Insights	Metriken und Protokollierungs-API für Application Insights	Application Insights-Warnungen
Azure Bastion	Azure Bastion-Metriken
Schlüsseltresor	Beschreibungen der Key Vault-Metriken und -Protokolle	Key Vault-Warnungen
Load Balancer Standard	Load Balancer-Protokolle und Metriken	Load Balancer-Warnungen
Öffentliche IP-Adresse	Beschreibung der Metriken und Protokolle für öffentliche IP-Adressen	Warnungen zu Metriken für öffentliche IP-Adressen
Virtual Network	Referenz zu Metriken und Protokollen für virtuelle Netzwerke	Warnungen für virtuelle Netzwerke
Virtuelle Computer und VM-Skalierungsgruppen	Referenz zu VM-Metriken und Protokollen	VM-Warnungen und Lernprogramme
Web Application Firewall	Beschreibung der Web Application Firewall-Metriken und -Protokolle	Web Application Firewall-Warnungen

Weitere Informationen zu den Kosten für das Sammeln von Metriken und Protokollen finden Sie unter Log Analytics-Kostenberechnungen und -Optionen und Preise für den Log Analytics-Arbeitsbereich. Die Art der Workload und die Häufigkeit und Anzahl der erfassten Metriken und Protokolle wirken sich erheblich auf die Kosten der Metrik- und Protokollsammlung aus.

Virtuelle Computer

Die Azure-Startdiagnoseist aktiviert, um den Status der VMs während des Startvorgangs zu beobachten, indem serielle Protokollinformationen und Screenshots erfasst werden. In dieser Architektur können auf diese Daten über Azure-Portal und den Azure CLI-VM-Start-Diagnose Get-boot-log-Befehl zugegriffen werden. Die Daten werden von Azure verwaltet, und Sie haben keine Kontrolle oder keinen Zugriff auf die zugrunde liegende Speicherressource. Wenn Ihre geschäftlichen Anforderungen jedoch mehr Kontrolle erfordern, können Sie Ihr eigenes Speicherkonto bereitstellen, um die Startdiagnose zu speichern.

VM Insights bietet eine effiziente Möglichkeit, VMs und Skalierungssätze zu überwachen. Es sammelt Daten aus Log Analytics-Arbeitsbereichen und stellt vordefinierte Arbeitsmappen für leistungsdatentrendende Daten bereit. Diese Daten können pro VM angezeigt oder auf mehreren virtuellen Computern aggregiert werden.

Das Anwendungsgateway und der interne Lastenausgleich verwenden Integritätssonden, um den Endpunktstatus der virtuellen Computer zu erkennen, bevor Datenverkehr gesendet wird.

Netzwerk

In dieser Architektur werden Protokolldaten aus mehreren Netzwerkkomponenten gesammelt, die am Flow teilnehmen. Zu diesen Komponenten gehören Application Gatway, Lastenausgleichsgeräte und Azure Bastion. Sie umfassen auch Netzwerksicherheitskomponenten wie virtuelle Netzwerke, NSGs, öffentliche IP-Adressen und private Verknüpfungen.

Verwaltete Datenträger

Datenträgermetriken hängen von Ihrer Workload ab, wobei eine Mischung aus wichtigen Metriken erforderlich ist. Die Überwachung sollte diese Perspektiven kombinieren, um Betriebssystem- oder Anwendungsdurchsatzprobleme zu isolieren.

• Die Perspektive der Azure-Plattform stellt die Metriken dar, die den Azure-Dienst angeben, unabhängig von der Workload, die mit dem Dienst verbunden ist. Datenträgerleistungsmetriken (IOPS und Durchsatz) können einzeln oder gemeinsam für alle vm-angefügten Datenträger angezeigt werden. Verwenden Sie Speicher-E/A-Auslastungsmetriken für die Problembehandlung oder Warnung bei potenziellen Datenträgerkappings. Wenn Sie Platz für die Kostenoptimierung verwenden, überwachen Sie Guthabenprozentmetriken, um Chancen für eine weitere Optimierung zu identifizieren.

• Die Perspektive des Gastbetriebssystems stellt Metriken dar, die der Workloadoperator unabhängig von der zugrunde liegenden Datenträgertechnologie anzeigen würde. VM-Einblicke werden für wichtige Metriken auf angefügten Datenträgern empfohlen, wie z. B. verwendeter logischer Speicherplatz, und die Perspektive des Betriebssystem-Kernels auf Datenträger-IOPS und -Durchsatz.

Überwachung auf Anwendungsebene

Obwohl die Referenzimplementierung nicht verwendet wird, wird Application Insights als Application Performance Management (APM) für Erweiterungszwecke bereitgestellt. Application Insights sammelt Daten aus einer Anwendung und sendet diese Daten an den Log Analytics-Workspace. Sie kann diese Daten auch aus den Workloadanwendungen visualisieren.

Die Anwendungsintegritätserweiterung wird für VMs bereitgestellt, um den binären Integritätszustand jeder VM-Instanz im Skalierungssatz zu überwachen und Instanzreparaturen durchzuführen, falls erforderlich, mithilfe der automatischen Instanzreparatur von Skalierungssatz. Es testet die gleiche Datei wie das Anwendungsgateway und den internen Integritätstest für den Azure Load Balancer, um zu überprüfen, ob die Anwendung reaktionsfähig ist.

Updateverwaltung

VMs müssen regelmäßig aktualisiert und gepatcht werden, damit sie den Sicherheitsstatus der Workload nicht schwächen. Wir empfehlen automatische und regelmäßige VM-Bewertungen für die frühzeitige Ermittlung und Anwendung von Patches.

Infrastrukturupdates

Azure aktualisiert seine Plattform regelmäßig, um die Zuverlässigkeit, Leistung und Sicherheit der Host-Infrastruktur für virtuelle Maschinen zu verbessern. Zu diesen Updates gehören Patches für Softwarekomponenten in der Hostumgebung über Upgrades von Netzwerkkomponenten bis hin zur Außerbetriebnahme von Hardware und mehr. Weitere Informationen zum Update-Prozess, finden Sie unter Wartung virtueller Computer in Azure.

Wenn ein Update ohne Neustart möglich ist, wird die VM angehalten, während der Host aktualisiert wird, oder sie wird in Echtzeit zu einem bereits aktualisierten Host migriert. Wenn die Wartung einen Neustart erfordert, werden Sie über die geplante Wartung informiert. Azure bietet auch ein Zeitfenster, in dem Sie die Wartung nach Belieben starten können. Informationen zum Selbstwartungsfenster und zur Konfiguration der verfügbaren Optionen finden Sie unter Verwaltung geplanter Wartungsbenachrichtigungen.

Einige Workloads tolerieren möglicherweise nicht einmal ein paar Sekunden, in denen eine VM einfriert oder die Verbindung zu Wartungszwecken getrennt wird. Eine bessere Kontrolle über alle Wartungsaktivitäten, einschließlich Zero-Impact- und Neustart-Updates, finden Sie unter Wartungskonfigurationen. Durch das Erstellen einer Wartungskonfiguration haben Sie die Möglichkeit, alle Plattformaktualisierungen zu überspringen und die Aktualisierungen nach Belieben anzuwenden. Wenn diese benutzerdefinierte Konfiguration festgelegt ist, überspringt Azure alle Updates, die keine Auswirkungen haben, einschließlich Updates ohne Neustart. Weitere Informationen finden Sie unter Verwalten von Plattformupdates mit Wartungskonfigurationen.

Upgrades von Betriebssystem-Images

Wenn Sie Betriebssystemupgrades durchführen, haben Sie ein goldenes Image, das getestet wird. Erwägen Sie die Verwendung der Azure Shared Image Gallery und des Azure Compute Gallery zum Veröffentlichen Ihrer benutzerdefinierten Bilder. Sie sollten über einen Prozess verfügen, der Batches von Instanzen jedes Mal fortlaufend aktualisiert, wenn ein neues Image vom Herausgeber veröffentlicht wird.

Setzen Sie VM-Images aus, bevor sie das Ende der Lebensdauer erreichen, um den Oberflächenbereich zu reduzieren.

Ihr Automatisierungsprozess sollte die Überlastung mit zusätzlicher Kapazität berücksichtigen.

Sie können Azure Update Management verwenden, um Betriebssystemupdates für Ihre virtuellen Windows- und Linux-Computer in Azure.Azure Update Manager zu verwalten und zu steuern, um Softwareupdates für Windows- und Linux-Computer in Azure-, lokalen und Multicloud-Umgebungen zu verwalten und zu steuern.

Patches für Gastbetriebssysteme

Azure-VMs bieten die Möglichkeit des automatischen VM-Gastpatching. Wenn dieser Dienst aktiviert ist, werden virtuelle Computer regelmäßig ausgewertet und verfügbare Patches klassifiziert. Es wird empfohlen, dass der Bewertungsmodus aktiviert ist, um eine tägliche Auswertung für ausstehende Patches zu ermöglichen. On-Demand-Bewertungen können jedoch nicht ausgelöst werden, um die Anwendung von Patches auszulösen. Wenn der Bewertungsmodus nicht aktiviert ist, haben Sie manuelle Möglichkeiten, ausstehende Updates zu erkennen.

Nur die Patches, die als kritisch oder sicherheitskritisch klassifiziert werden, werden automatisch in allen Azure-Regionen angewendet. Definieren Sie benutzerdefinierte Updateverwaltungsprozesse, die andere Patches anwenden.

Berücksichtigen Sie bei der Governance die Azure-Richtlinie für automatischeS Betriebssystemimagepatching auf vm-Skalierungssätzen .

Das automatische Patchen kann das System belasten und störend sein, da VMs Ressourcen verwenden und während Updates neu starten können. Die Überbereitstellung wird für die Lastverwaltung empfohlen. Stellen Sie VMs in verschiedenen Availability Zones bereit, um gleichzeitige Updates zu vermeiden, und verwalten Sie mindestens zwei Instanzen pro Zone für Hochverfügbarkeit. Virtuelle Computer in derselben Region erhalten möglicherweise unterschiedliche Patches, die im Laufe der Zeit abgestimmt werden sollten.

Beachten Sie die mit einer Überbereitstellung verbundenen Kostenkompromisse.

Integritätsprüfungen werden als Teil des automatischen VM-Gastpatchings eingeschlossen. Diese Überprüfungen überprüfen die erfolgreiche Patchanwendung und erkennen Probleme.

Wenn es benutzerdefinierte Prozesse zum Anwenden von Patches gibt, verwenden Sie private Repositorys für Patchquellen. Auf diese Weise können Sie die Patches besser testen, um sicherzustellen, dass sich das Update nicht negativ auf die Leistung oder Sicherheit auswirkt.

Weitere Informationen finden Sie unter Automatisches VM-Gastpatching für Azure-VMs.

Zuverlässigkeit

Diese Architektur verwendet Verfügbarkeitszonen als grundlegendes Element, um Zuverlässigkeitsbedenken zu beheben.

In diesem Setup sind einzelne VMs an eine einzelne Zone gebunden. Wenn ein Fehler auftritt, können diese virtuellen Computer mithilfe von VM-Skalierungssätzen leicht durch andere VM-Instanzen ersetzt werden.

Alle anderen Komponenten in dieser Architektur sind:

• Zonenredundanz, d. h. sie werden in mehreren Zonen für hohe Verfügbarkeit repliziert, z. B. Anwendungsgateway oder öffentliche IPs.
• Zonenresilienz, was bedeutet, dass sie Zonenfehlern standhalten können, z. B. Key Vault.
• Regionale oder globale Ressourcen, die über Regionen oder global verfügbar sind, z. B. Microsoft Entra ID.

Der Entwurf von Workloads sollte Zuverlässigkeitsgarantien in Anwendungscode, Infrastruktur und Operationen umfassen. In den folgenden Abschnitten werden einige Strategien veranschaulicht, um sicherzustellen, dass die Arbeitsauslastung ausfallsicher ist und sich wiederherstellen kann, wenn Ausfalle auf Infrastrukturebene vorliegen.

Die in der Architektur verwendeten Strategien basieren auf der Prüfliste der Zuverlässigkeitsdesignüberprüfung in Azure Well-Architected Framework. Die Abschnitte werden mit Empfehlungen aus dieser Checkliste kommentiert.

Da keine Anwendung bereitgestellt wird, liegt die Resilienz im Anwendungscode außerhalb des Umfangs dieser Architektur. Es wird empfohlen, alle Empfehlungen in der Checkliste zu überprüfen und gegebenenfalls in Ihrer Workload zu übernehmen.

Priorisieren der Zuverlässigkeitsüberprüfungen pro Benutzerflow

In den meisten Designs gibt es mehrere Benutzerflows mit jeweils eigenen Geschäftsanforderungen. Nicht alle diese Flows erfordern die höchste Zuverlässigkeitsebene, daher wird die Segmentierung als Zuverlässigkeitsstrategie empfohlen. Jedes Segment kann unabhängig verwaltet werden, um sicherzustellen, dass sich ein Segment nicht auf andere auswirkt und die richtige Resilienzstufe in jeder Ebene bereitstellt. Dieser Ansatz macht das System auch flexibel.

In dieser Architektur implementieren Anwendungsebenen die Segmentierung. Separate Skalierungssätze werden für die Front-End- und Back-End-Ebenen bereitgestellt. Diese Trennung ermöglicht eine unabhängige Skalierung jeder Ebene, sodass Designmuster basierend auf ihren spezifischen Anforderungen unter anderem umgesetzt werden können.

Weitere Informationen finden Sie unter Well-Architected Framework: RE:02 - Empfehlungen zum Identifizieren und Bewerten von Flows.

Identifizieren der potenziellen Fehlerpunkte

Jede Architektur ist anfällig für Fehler. Mit der Übung der Fehlermodusanalyse können Sie Fehler antizipieren und mit Entschärfungen vorbereitet werden. Hier sind einige mögliche Fehlerpunkte in dieser Architektur:

Komponente	Risiko	Wahrscheinlichkeit	Effekt/Entschärfung/Hinweis	Outage
Microsoft Entra ID	Fehlkonfiguration	Medium	Ops-Benutzer können sich nicht anmelden. Kein nachgeschalteter Effekt. Das Konfigurationsproblem des Helpdesks wird an das Identitätsteam gemeldet.	Keine
Application Gateway	Fehlkonfiguration	Medium	Fehlkonfigurationen sollten während der Bereitstellung abgefangen werden. Wenn diese Fehler während eines Konfigurationsupdates auftreten, muss das DevOps-Team Änderungen zurücksetzen. Die Bereitstellung von Instanzen mit der v2-SKU dauert in der Regel etwa sechs Minuten. Bei manchen Bereitstellungsarten kann sie jedoch auch mehr Zeit beanspruchen. Bereitstellungen, die sich über mehrere Verfügbarkeitszonen erstrecken und viele Instanzen umfassen, können beispielsweise länger als 6 Minuten dauern.	Vollständig
Application Gateway	DDoS-Angriff	Medium	Potenzial für Unterbrechungen. Microsoft verwaltet den DDoS-Schutz (L3 und L4). Potenzielles Wirkungsrisiko von L7-Angriffen.	Vollständig
Skalierungsgruppen für virtuelle Computer	Dienstunterbrechung	Niedrig	Potenzieller Workloadausfall, wenn fehlerhafte VM-Instanzen vorhanden sind, die autorepair auslösen. Abhängig von Microsoft zur Behebung.	Potenzieller Ausfall
Skalierungsgruppen für virtuelle Computer	Ausfall der Verfügbarkeitszone	Niedrig	Keine Auswirkung. Skalierungssätze werden als zonenredundant bereitgestellt.	Keine

Weitere Informationen finden Sie unter Well-Architected Framework: RE:03 – Empfehlungen für die Durchführung der Fehlermodusanalyse.

Zuverlässigkeitsziele

Um Entwurfsentscheidungen zu treffen, ist es wichtig, die Zuverlässigkeitsziele zu berechnen, z. B. die zusammengesetzten Ziele auf Dienstebene (SLOs) der Arbeitsauslastung. Dies umfasst das Verständnis der Vereinbarungen auf Service-Level-Vereinbarungen (SLAs), die von Azure-Diensten bereitgestellt werden, die in der Architektur verwendet werden. Workload-SLOs dürfen nicht höher sein als die von Azure garantierten SLAs. Untersuchen Sie jede Komponente sorgfältig anhand von VMs und deren Abhängigkeiten, Netzwerk- und Speicheroptionen.

Hier ist eine Beispielberechnung, bei der das Standard Ziel darin besteht, eine ungefähre zusammengesetzte SLO bereitzustellen. Obwohl dies eine grobe Richtlinie ist, sollten Sie etwas ähnliches erreichen. Sie sollten für dieselben Flows keinen höheren maximalen zusammengesetzten SLO erhalten, es sei denn, Sie nehmen Änderungen an der Architektur vor.

Operations-Flow

Komponente	SLO
Microsoft Entra ID	99,99 %
Azure Bastion	99,95 %

Verbund-SLO: 99,94 % | Ausfallzeiten pro Jahr: 0d 5h 15m 20s

App-Benutzerflow

Komponente	SLO
Application Gateway	99,95 %
Azure Load Balancer (intern)	99,99 %
Front-End-VMs mit Premiumspeicher (composite SLO)	99,70 %
Back-End-VMs mit Premiumspeicher (composite SLO)	99,70 %

Verbund-SLO: 99,34 % | Ausfallzeiten pro Jahr: 2d 9h 42m 18s

Im vorherigen Beispiel sind die Zuverlässigkeit von VMs und Abhängigkeiten enthalten, z. B. Datenträger, die VMs zugeordnet sind. Die SLAs, die mit dem Datenträgerspeicher verbunden sind, wirken sich auf die Gesamtsicherheit aus.

Beim Berechnen des zusammengesetzten SLO gibt es einige Herausforderungen. Es ist wichtig zu beachten, dass verschiedene Dienstebenen mit unterschiedlichen SLAs zusammenkommen können, und diese umfassen häufig finanziell gesicherte Garantien, die Zuverlässigkeitsziele festlegen. Schließlich gibt es möglicherweise Komponenten der Architektur, die keine SLAs definiert haben. Beispielsweise verfügen NICs und virtuelle Netzwerke nicht über eigene SLAs.

Die Geschäftsanforderungen und ihre Ziele müssen klar definiert und in die Berechnung eingegrenzt werden. Beachten Sie die von der Organisation auferlegten Dienstgrenzwerte und andere Einschränkungen. Die Freigabe Ihres Abonnements mit anderen Workloads könnte sich auf die Ressourcen auswirken, die für Ihre virtuellen Computer verfügbar sind. Die Workload kann eine begrenzte Anzahl von Kernen verwenden, die für die virtuellen Computer verfügbar sind. Wenn Sie die Ressourcennutzung Ihres Abonnements verstehen, können Sie Ihre virtuellen Computer effektiver gestalten.

Informationen zum Definieren von Zuverlässigkeitszielen finden Sie unter: RE:04 – Empfehlungen zur Definition von Zuverlässigkeitszielen.

Redundanz

Diese Architektur verwendet Zonenredundanz für mehrere Komponenten. Jede Zone besteht aus mindestens einem Rechenzentrum, dessen Stromversorgung, Kühlung und Netzwerkbetrieb unabhängig voneinander funktionieren. Wenn Instanzen in separaten Zonen ausgeführt werden, schützt die Anwendung vor Rechenzentrumsfehlern.

• Skalierungsgruppen für virtuelle Computer weisen eine bestimmte Anzahl von Instanzen zu und verteilen sie gleichmäßig über Verfügbarkeitszonen und Fehlerdomänen. Diese Verteilung wird durch die maximale Spread-Funktion erreicht, die empfohlen wird. Durch die Verteilung von VM-Instanzen auf Fehlerdomänen wird sichergestellt, dass nicht alle VMs gleichzeitig aktualisiert werden.

  Berücksichtigen Sie ein Szenario, in dem drei Verfügbarkeitszonen vorhanden sind. Wenn Sie drei Instanzen haben, wird jede Instanz einer anderen Verfügbarkeitszone zugeordnet und in eine andere Fehlerdomäne platziert. Azure garantiert, dass in jeder Verfügbarkeitszone jeweils nur eine Fehlerdomäne aktualisiert wird. Es kann jedoch vorkommen, dass alle drei Fehlerdomänen, die Ihre VMs in den drei Verfügbarkeitszonen hosten, gleichzeitig aktualisiert werden. Alle Zonen und Domänen sind betroffen. Wenn sie mindestens zwei Instanzen in jeder Zone haben, wird während Upgrades ein Puffer bereitgestellt.

• Verwaltete Datenträger können nur an einen virtuellen Computer in derselben Region angefügt werden. Ihre Verfügbarkeit wirkt sich in der Regel auf die Verfügbarkeit des virtuellen Computers aus. Bei Bereitstellungen mit einer Region können Datenträger für Redundanz konfiguriert werden, um Zonalfehlern standzuhalten. In dieser Architektur sind Datendatenträger auf den Back-End-VMs zonenredundanter Speicher (ZRS) konfiguriert. Es erfordert eine Wiederherstellungsstrategie, um die Verfügbarkeitszonen nutzen zu können. Die Wiederherstellungsstrategie besteht darin, die Lösung erneut bereitzustellen. Idealerweise vor der Bereitstellung in alternativen Verfügbarkeitszonen, die zur Wiederherstellung aus einem Zonalausfall bereit sind.

• Ein zonenredundantes Application Gateway oder ein Standard-Load-Balancer können den Datenverkehr mithilfe einer einzigen IP-Adresse zonenübergreifend an VMs weiterleiten und so die Kontinuität auch bei Zonenausfällen gewährleisten. Diese Dienste verwenden Integritätsüberprüfungen, um die Verfügbarkeit der VM zu überprüfen. Solange eine Zone in der Region betriebsbereit bleibt, wird das Routing trotz möglicher Ausfälle in anderen Zonen fortgesetzt. Das Routing zwischen Zonen kann jedoch im Vergleich zum intrazonenbasierten Routing eine höhere Latenz aufweisen.

  Alle öffentlichen IPs, die in dieser Architektur verwendet werden, sind zonenredundant.

• Azure bietet zonenresiliente Dienste für eine bessere Zuverlässigkeit, z. B. Key Vault.

• Globale Azure-Ressourcen sind immer verfügbar und können bei Bedarf zu einer anderen Region wechseln, z. B. der grundlegende Identitätsanbieter, Microsoft Entra ID.

Weitere Informationen finden Sie unter Well-Architected Framework: RE:05 - Empfehlungen für das Entwerfen von Redundanz.

Skalierungsstrategie

Um Beeinträchtigungen und Fehler auf Dienstebene zu verhindern, stellen Sie zuverlässige Skalierungsvorgänge sicher. Skalieren Sie die Workload horizontal (horizontal skalieren), vertikal (hochskalieren) oder verwenden Sie eine Kombination aus beiden Ansätzen. Verwenden Sie Azure Monitor Autoscale, um genügend Ressourcen bereitzustellen, um den Bedarf Ihrer Anwendung zu decken, ohne mehr Kapazität als nötig zuzuweisen und unnötige Kosten zu verursachen.

Mit Autoscale können Sie verschiedene Profile basierend auf unterschiedlichen Ereignistypen definieren, z. B. Zeit, Zeitplan oder Metriken. Metrikbasierte Profile können integrierte Metriken (hostbasiert) oder detailliertere Metriken (In-Guest-VM-Metriken) verwenden, die die Installation des Azure Monitor-Agent erfordern, um sie zu sammeln. Jedes Profil enthält Regeln zum Skalieren (Vergrößern) und Skalieren (Verkleinern). Erwägen Sie, alle verschiedenen Skalierungsszenarien basierend auf entworfenen Profilen zu untersuchen und sie für potenzielle Schleifenbedingungen zu bewerten, die zu einer Reihe von entgegengesetzten Skalierungsereignissen führen können. Azure Monitor versucht, diese Situation zu mindern, indem er auf den Abkühlzeitraum wartet, bevor er erneut skaliert wird.

Obwohl Azure Virtual Machine Scale Sets im flexiblen Modus heterogene Umgebungen unterstützt, wird die automatische Skalierung mehrerer Profile nicht unterstützt. Erwägen Sie, unterschiedliche Skalierungssätze zu erstellen, um sie separat zu verwalten, wenn Sie die automatische Skalierung mit mehr als einem VM-Typ verwenden möchten.

Berücksichtigen Sie andere Aspekte wie Bootstrapping, ordnungsgemäßes Herunterfahren, Installieren der Workload und aller Abhängigkeiten sowie Datenträgerverwaltung beim Erstellen oder Löschen von VMs-Instanzen.

Zustandsbehaftete Workloads erfordern möglicherweise eine zusätzliche Verwaltung für verwaltete Datenträger, die über eine Workloadinstanz hinausgehen müssen. Entwerfen Sie Ihre Workload für die Datenverwaltung unter Skalierungsereignissen für Konsistenz, Synchronisierung, Replikation und Integrität der Daten der Workload. In diesen Szenarien sollten Sie vorab aufgefüllte Datenträger hinzufügen, um Skalierungssätze zu skalieren. Für Anwendungsfälle, in denen die Skalierung verwendet wird, um Engpässe beim Zugriff auf Daten zu verhindern, planen Sie Partitionierung und Sharding. Weitere Informationen finden Sie unter Empfohlene Methoden für Autoscale.

Weitere Informationen finden Sie unter Well-Architected Framework: RE:06 - Empfehlungen für das Entwerfen einer zuverlässigen Skalierungsstrategie.

Selbstheilung und Wiederherstellbarkeit

Automatische Instanzreparaturen ist in den Virtual Machine Scale Sets aktiviert, um die Wiederherstellung nach VM-Ausfällen zu automatisieren. Die Anwendungsintegritätserweiterung wird für VMs bereitgestellt, um das Erkennen nicht reagierender VMs und Anwendungen zu unterstützen. Für diese Instanzen werden Reparaturaktionen automatisch ausgelöst.

Weitere Informationen finden Sie unter Well-Architected Framework: Empfehlungen zur Selbstheilung und Selbsterhaltung.

Sicherheit

Diese Architektur veranschaulicht einige der Sicherheitsüberprüfungen, die in der Prüfliste für die Sicherheitsdesignüberprüfung in Azure Well-Architected Framework angegeben wurden. Die Abschnitte werden mit Empfehlungen aus dieser Checkliste kommentiert.

Sicherheit bezieht sich nicht nur auf technische Kontrollen. Es wird empfohlen, die gesamte Checkliste zu befolgen, um die operativen Aspekte der Sicherheitssäule zu verstehen.

Segmentierung

• Netzwerksegmentierung Wokload-Ressourcen werden in einem virtuellen Netzwerk platziert, das eine Isolierung aus dem Internet ermöglicht. Innerhalb des virtuellen Netzwerks können Subnetze als Vertrauensgrenzen verwendet werden. Verlagern Sie verwandte Ressourcen, die für die Verarbeitung einer Transaktion in einem Subnetz erforderlich sind. In dieser Architektur wird das virtuelle Netzwerk basierend auf der logischen Gruppierung der Anwendung und des Zwecks verschiedener Azure-Dienste, die als Teil der Workload verwendet werden, in Subnetze unterteilt.

  Der Vorteil der Subnetzsegmentierung besteht darin, dass Sie Sicherheitskontrollen am Umkreis platzieren können, die den Datenverkehr steuern, der in und aus dem Subnetz fließt, wodurch der Zugriff auf die Workload-Ressourcen eingeschränkt wird.

• Identitätssegmentierung. Weisen Sie unterschiedlichen Identitäten unterschiedliche Rollen mit gerade ausreichend Berechtigungen zu, um ihre Aufgabe zu erledigen. Diese Architektur verwendet Identitäten, die von der Microsoft Entra-ID verwaltet werden, um den Zugriff auf Ressourcen zu segmentieren.

• Ressourcensegmentierung. Die Anwendung wird nach Ebenen in separate Skalierungssätze segmentiert, wodurch sichergestellt wird, dass Anwendungskomponenten nicht kolociert werden.

Weitere Informationen finden Sie unter Well-Architected Framework: SE:04 - Empfehlungen für die Erstellung einer Segmentierungsstrategie.

Identitäts- und Zugriffsverwaltung

Wir empfehlen Microsoft Entra-ID für die Authentifizierung und Autorisierung von Benutzern und Diensten.

Für den Zugriff auf VMs ist ein Benutzerkonto erforderlich, das von der Microsoft Entra-ID-Authentifizierung gesteuert und von Sicherheitsgruppen gesichert wird. Diese Architektur bietet Unterstützung durch die Bereitstellung der Microsoft Entra ID-Authentifizierungserweiterung für alle virtuellen Computer. Es wird empfohlen, dass benutzereigene Benutzer ihre Unternehmensidentitäten im Microsoft Entra ID-Mandanten ihrer Organisation verwenden. Stellen Sie außerdem sicher, dass der dienstprinzipalbasierte Zugriff nicht über Funktionen hinweg freigegeben wird.

Workload-Ressourcen, z. B. virtuelle Computer, authentifizieren sich selbst mithilfe ihrer zugewiesenen verwalteten Identitäten für andere Ressourcen. Diese Identitäten, basierend auf Microsoft Entra ID-Dienstprinzipalen, werden automatisch verwaltet.

Beispielsweise werden Key Vault-Erweiterungen auf virtuellen Computern installiert, die die virtuellen Computer mit Zertifikaten starten. In dieser Architektur werden vom Benutzer zugewiesene verwaltete Identitäten von Anwendungsgateway, Front-End-VMs und Back-End-VMs für den Zugriff auf Key Vault verwendet. Diese verwalteten Identitäten werden während der Bereitstellung konfiguriert und für die Authentifizierung gegen Key Vault verwendet. Zugriffsrichtlinien für Key Vault sind so konfiguriert, dass nur Anforderungen von den vorherigen verwalteten Identitäten akzeptiert werden.

Die Basisarchitektur verwendet eine Mischung aus vom System zugewiesenen und vom Benutzer zugewiesenen verwalteten Identitäten. Diese Identitäten sind erforderlich, um Microsoft Entra-ID für Autorisierungszwecke beim Zugriff auf andere Azure-Ressourcen zu verwenden.

Weitere Informationen finden Sie unter Well-Architected Framework: SE:05 - Empfehlungen für Identitäts- und Zugriffsverwaltung.

Netzwerksteuerungen

• Eingehender Datenverkehr: Die Workload-VMs werden nicht direkt im öffentlichen Internet verfügbar gemacht. Jede VM verfügt über eine private IP-Adresse. Workload-Benutzer stellen eine Verbindung über die öffentliche IP-Adresse des Application Gateway her.

  Mehr Sicherheit wird über die Web Application Firewall bereitgestellt, die in das Application Gateway integriert ist. Es enthält Regeln, die eingehenden Datenverkehr prüfen und geeignete Maßnahmen ergreifen können. WAF verfolgt Open Web Application Security Project (OWASP)-Sicherheitsrisiken, die bekannte Angriffe verhindern.

• Ausgehender Datenverkehr: Es gibt keine Steuerelemente für ausgehenden Datenverkehr, mit Ausnahme der ausgehenden NSG-Regeln für die VM-Subnetze. Es wird empfohlen, dass der gesamte ausgehende Internetdatenverkehr über eine einzelne Firewall fließt. Diese Firewall ist in der Regel ein zentraler Dienst, der von einer Organisation bereitgestellt wird. Dieses Fallbeispiel wird in der Basisarchitektur des virtuellen Computers in einer Azure-Zielzone gezeigt.

• Ost-West-Datenverkehr. Der Datenverkehrsfluss zwischen den Subnetzen wird durch die Anwendung präziser Sicherheitsregeln eingeschränkt.

  Netzwerksicherheitsgruppen (Network Security Groups, NSGs) werden platziert, um den Datenverkehr zwischen Subnetzen basierend auf Parametern wie IP-Adressbereich, Ports und Protokollen einzuschränken. Anwendungssicherheitsgruppen (Application Security Groups, ASG) werden auf Front-End- und Back-End-VMs platziert. Sie werden mit NSGs verwendet, um Datenverkehr zu und von den virtuellen Computern zu filtern.

• Betriebsverkehr. Wir empfehlen, den sicheren Betriebszugriff auf eine Workload über Azure Bastion zu gewährleisten, wodurch die Notwendigkeit einer öffentlichen IP-Adresse aufgehoben wird. In dieser Architektur erfolgt die Kommunikation über SSH und wird sowohl von Windows- als auch Linux-VMs unterstützt. Microsoft Entra-ID ist mit SSH für beide Arten von VMs integriert, indem die entsprechende VM-Erweiterung verwendet wird. Durch diese Integration kann die Identität eines Operators über die Microsoft Entra-ID authentifiziert und autorisiert werden.

  Alternativ können Sie einen separaten virtuellen Computer als Sprungfeld verwenden, das in einem eigenen Subnetz bereitgestellt wird, in dem Sie Ihre Wahl von Administrator- und Problembehandlungstools installieren können. Der Operator greift über den Azure Bastion-Host auf die Jumpbox zu. Anschließend melden sie sich über die Jump Box bei den virtuellen Computern hinter dem Lastenausgleich an.

  In dieser Architektur wird der Betriebsdatenverkehr mithilfe von NSG-Regeln zum Einschränken des Datenverkehrs geschützt, und der JIT-VM-Zugriff wird auf den virtuellen Computern aktiviert. Dieses Feature von Microsoft Defender für Cloud ermöglicht temporären eingehenden Zugriff auf ausgewählte Ports.

  Um die Sicherheit zu erhöhen, verwenden Sie Microsoft Entra Privileged Identity Management (PIM). PIM ist ein Dienst in Microsoft Entra ID, mit dem Sie den Zugriff auf wichtige Ressourcen in Ihrem Unternehmen verwalten, steuern und überwachen können. PIM bietet eine zeit- und genehmigungsbasierte Rollenaktivierung, um die Risiken durch übermäßige, unnötige oder missbrauchte Zugriffsberechtigungen für wichtige Ressourcen zu verringern.

• Private Konnektivität zu PaaS-Diensten (Platform-as-a-Service). Die Kommunikation zwischen den virtuellen Computern und dem Key Vault erfolgt über einen privaten Link. Dieser Dienst erfordert private Endpunkte, die in einem separaten Subnetz platziert werden.

• DDoS Protection. Erwägen Sie die Aktivierung von Azure DDoS Protection auf den öffentlichen IPs, die vom Anwendungsgateway und dem Azure Bastion-Host verfügbar gemacht werden, um Bedrohungen zu erkennen. Die DDoS Protection bietet über Monitor auch Warnungen, Telemetrie und Analysen. Weitere Informationen finden Sie unter Azure DDoS Protection – Bewährte Methoden und Referenzarchitekturen.

Weitere Informationen finden Sie unter Well-Architected Framework: SE:06 – Empfehlungen für Netzwerk und Konnektivität.

Verschlüsselung

• Daten während der Übertragung: Der Benutzerdatenverkehr zwischen Benutzern und der öffentlichen IP-Adresse des Applicaton Gaeway wird mit dem externen Zertifikat verschlüsselt. Der Datenverkehr zwischen dem Application Gateway und den Front-End-VMs und zwischen Front-End- und Back-End-VMs wird mit einem internen Zertifikat verschlüsselt. Beide Zertifikate werden im Key Vault gespeichert:

  • app.contoso.com: Ein externes Zertifikat, das von Clients und dem Application Gateway für den sicheren öffentlichen Internetdatenverkehr verwendet wird.
  • *.workload.contoso.com: Ein Wildcard-Zertifikat, das von den Infrastrukturkomponenten für den sicheren internen Datenverkehr verwendet wird.

• Ruhende Daten: Protokolldaten werden auf einem verwalteten Datenträger gespeichert, der an VMs angefügt ist. Diese Daten werden automatisch mit plattformbasierter Verschlüsselung in Azure verschlüsselt.

Weitere Informationen finden Sie unter Well-Architected Framework: SE:07 - Empfehlungen für die Datenverschlüsselung.

Verwaltung von Geheimnissen

Laden Sie eine Visio-Datei dieser Architektur herunter.

Key Vault bietet eine sichere Verwaltung von geheimen Schlüsseln, einschließlich TLS-Zertifikaten. In dieser Architektur werden die TLS-Zertifikate im Key Vault gespeichert und während des Bereitstellungsprozesses von den verwalteten Identitäten des Anwendungsgateways und der VMs abgerufen. Nach der Ersteinrichtung greifen diese Ressourcen nur auf Key Vault zu, wenn die Zertifikate aktualisiert werden.

Die virtuellen Computer verwenden die Key Vault VM Vm-Erweiterung, um die überwachten Zertifikate automatisch zu aktualisieren. Wenn Änderungen im lokalen Zertifikatspeicher erkannt werden, ruft die Erweiterung die entsprechenden Zertifikate aus dem Key Vault ab und installiert sie. Die Erweiterung unterstützt die Zertifikatinhaltstypen PKCS #12 und PEM.

Weitere Informationen finden Sie unter Well-Architected Framework: SE:09 - Empfehlungen zum Schutz von Anwendungsgeheimnissen.

Kostenoptimierung

Workloadanforderungen müssen erfüllt werden, wobei die Kostenbeschränkungen beachtet werden. Die in der Architektur verwendeten Strategien basieren auf der Checkliste zur Überprüfung des Kostenoptimierungsentwurfs im Azure Well-Architected Framework. In diesem Abschnitt werden einige Optionen zum Optimieren der Kosten beschrieben und mit Empfehlungen aus dieser Checkliste kommentiert.

Komponentenkosten

Wählen Sie VM-Images aus, die für die Workload optimiert sind, anstatt allgemeine Images zu verwenden. In dieser Architektur werden relativ kleine VM-Images sowohl für Windows als auch für Linux ausgewählt, die jeweils 30 GB groß sind. Bei kleineren Images sind VM-SKUs mit Datenträgern ebenfalls kleiner, was zu geringeren Kosten, geringerer Ressourcenverbrauch und schnelleren Bereitstellungs- und Startzeiten führt. Ein Vorteil ist aufgrund der reduzierten Fläche mehr Sicherheit.

Die Implementierung der Protokollrotation mit Größenbeschränkungen ist eine weitere kostensparende Strategie. Sie ermöglicht die Verwendung kleiner Datenträger, was zu geringeren Kosten führen kann. Die Implementierung dieser Architektur verwendet 4-GB-Datenträger.

Die Verwendung von ephemeralen Betriebssystemdatenträgern kann auch zu Kosteneinsparungen und einer verbesserten Leistung führen. Diese Datenträger sind für die Verwendung von VM-Ressourcen konzipiert, für die Sie bereits bezahlen, da sie auf dem Cachedatenträger installiert sind, der mit der VM bereitgestellt wird. Dadurch werden speicherkosten im Zusammenhang mit herkömmlichen persistenten Datenträgern beseitigt. Da diese Datenträger temporär sind, entstehen keine Kosten für die langfristige Datenspeicherung.

Weitere Informationen finden Sie unter Well-Architected Framework: CO:07 - Empfehlungen zur Optimierung der Komponentenkosten.

Flowkosten

Wählen Sie Computeressourcen basierend auf der Kritischität des Flows aus. Bei Flows, die eine unbestimmte Länge tolerieren sollen, sollten Sie Spot-VMs mit Virtual Machine Scale Sets Flexible Orchestrierungsmodus verwenden. Dieser Ansatz kann für das Hosten von Flows mit niedriger Priorität auf VMs mit niedrigerer Priorität effektiv sein. Diese Strategie ermöglicht die Kostenoptimierung, während gleichzeitig die Anforderungen verschiedener Flows erfüllt werden.

Weitere Informationen finden Sie unter Well-Architected Framework: CO:09 - Empfehlungen zur Optimierung der Flowkosten.

Skalierungskosten

Wenn der Haupt-Kostentreiber die Anzahl der Instanzen ist, kann es kosteneffizienter sein, eine Skalierung durchzuführen, indem die Größe oder Leistung der virtuellen Computer erhöht wird. Dieser Ansatz kann zu Kosteneinsparungen in mehreren Bereichen führen:

• Softwarelizenzierung Größere VMs können mehr Arbeitsauslastung bewältigen, wodurch die Anzahl der erforderlichen Softwarelizenzen reduziert werden kann.
• Wartungszeit: Weniger, größere VMs können die Betriebskosten senken.
• Lastenausgleich: Weniger VMs können zu niedrigeren Kosten für den Lastenausgleich führen. In dieser Architektur gibt es beispielsweise mehrere Ebenen des Lastenausgleichs, z. B. ein Application Gateway an der Vorderseite und einen internen Load Balancer in der Mitte. Die Kosten für den Load Balancer würden steigen, wenn eine höhere Anzahl von Instanzen verwaltet werden muss.
• Disk Storage. Wenn zustandsbehaftete Anwendungen vorhanden sind, benötigen mehr Instanzen mehr angefügte verwaltete Datenträger und erhöhen die Speicherkosten.

Weitere Informationen finden Sie unter Well-Architected Framework: CO:12 - Empfehlungen zur Optimierung der Skalierungskosten.

Betriebskosten

Automatisches VM-Gast-Patching reduziert den Aufwand für manuelles Patchen und die damit verbundenen Wartungskosten. Diese Aktion trägt nicht nur dazu bei, das System sicherer zu machen, sondern optimiert auch die Ressourcenzuordnung und trägt zur Gesamtkosteneffizienz bei.

Siehe Well-Architected Framework: CO:13 - Empfehlungen zur Optimierung der Personalzeit.

Bereitstellen dieses Szenarios

Eine Bereitstellung für diese Referenzarchitektur ist auf GitHub verfügbar.

Zugehörige Ressourcen

Details zu bestimmten Azure-Diensten finden Sie in der Produktdokumentation:

• Dokumentation zu virtuellen Computern
• Azure Virtual Machine Scale Sets
• Azure Virtual Network
• Azure Application Gateway-Standard_v2
• Azure-Lastenausgleich
• Azure Key Vault
• Azure Bastion
• Application Insights
• Log Analytics

Nächster Schritt

Überprüfen Sie die IaaS-Referenzarchitekturen, die Optionen für die Datenebene anzeigen:

• Windows-N-Tier-Anwendung mit SQL Server auf Azure