n-schichtige Windows-Anwendung in Azure

Blob Storage
DNS
Load Balancer
Virtual Network
Virtual Machines

Diese Referenzarchitektur zeigt, wie Sie für eine n-schichtige Anwendung konfigurierte virtuelle Computer (VMs) und ein entsprechendes virtuelles Netzwerk mit SQL Server unter Windows für die Datenschicht bereitstellen. Stellen Sie diese Lösung bereit.

n-schichtige Architektur mit Microsoft Azure

Laden Sie eine Visio-Datei dieser Architektur herunter.

Aufbau

Diese Architektur besteht aus den folgenden Komponenten.

Allgemein

  • Ressourcengruppe. Ressourcengruppen dienen zum Gruppieren von Azure-Ressourcen, damit sie nach Lebensdauer, Besitzer oder anderen Kriterien verwaltet werden können.

  • Verfügbarkeitszonen. Verfügbarkeitszonen sind physische Standorte in einer Azure-Region. Jede Zone besteht aus mindestens einem Datencenter mit eigener Stromversorgung, Kühlung und Netzwerk. Wenn Sie VMs zonenübergreifend platzieren, wird die Anwendung in einer Zone resilient gegenüber Fehlern.

Netzwerk und Lastenausgleich

  • Virtuelles Netzwerk und Subnetze. Jede Azure-VM wird in einem virtuellen Netzwerk bereitgestellt, das in Subnetze segmentiert werden kann. Erstellen Sie für jede Schicht ein separates Subnetz.

  • Anwendungsgateway: Application Gateway ist ein Lastenausgleich auf Schicht 7 (Anwendungsschicht). Bei dieser Architektur werden HTTP-Anforderungen an das Web-Front-End geleitet. Mit Application Gateway wird auch eine Web Application Firewall (WAF) bereitgestellt, mit der die Anwendung vor häufig auftretenden Exploits und Sicherheitsrisiken geschützt wird.

  • Lastenausgleichsmodule. Verwenden Sie Azure Load Balancer Standard zum Verteilen von Netzwerkdatenverkehr von der Webebene auf die Geschäftsebene und von der Geschäftsebene an SQL Server.

  • Netzwerksicherheitsgruppen (NSGs). Verwenden Sie NSGs, um den Netzwerkdatenverkehr im virtuellen Netzwerk zu beschränken. In der hier gezeigten dreischichtigen Architektur akzeptiert die Datenbankschicht beispielsweise keinen Datenverkehr vom Web-Front-End, sondern nur von der Unternehmensschicht und dem Verwaltungssubnetz.

  • DDoS Protection. Obwohl die Azure-Plattform Schutz vor verteilten Denial-of-Service-Angriffen (DDoS) beinhaltet, empfehlen wir die Verwendung der Dienstebene DDoS Protection Standard, die erweiterte Funktionen für die DDoS-Entschärfung bietet. Weitere Informationen finden Sie unter Sicherheitshinweise.

  • Azure DNS: Azure DNS ist ein Hostingdienst für DNS-Domänen. Er ermöglicht eine Namensauflösung mithilfe der Microsoft Azure-Infrastruktur. Durch das Hosten Ihrer Domänen in Azure können Sie Ihre DNS-Einträge mithilfe der gleichen Anmeldeinformationen, APIs, Tools und Abrechnung wie für die anderen Azure-Dienste verwalten.

Virtuelle Computer

  • SQL Server Always On-Verfügbarkeitsgruppe. Stellt Hochverfügbarkeit in der Datenschicht durch Replikation und Failover bereit. Verwendet WSFC-Technologie (Windows Server-Failovercluster) für Failover.

  • AD DS-Server (Active Directory Domain Services): Die Computerobjekte für den Failovercluster und die zugehörigen Clusterrollen werden in Active Directory Domain Services (AD DS) erstellt.

  • Cloudzeuge. Bei einem Failovercluster muss mindestens die Hälfte der Knoten ausgeführt werden (Quorum). Enthält der Cluster nur zwei Knoten, kann eine Netzwerkpartition dazu führen, dass sich beide Knoten als Primärknoten betrachten. In diesem Fall benötigen Sie einen Zeugen, um den Konflikt zu lösen und ein Quorum festzulegen. Ein Zeuge ist eine Ressource (beispielsweise ein freigegebener Datenträger), der den Ausschlag für das Quorum gibt. Ein Cloudzeuge ist ein Zeugentyp, der Azure Blob Storage nutzt. Weitere Informationen zum Konzept des Quorums finden Sie unter Understanding cluster and pool quorum Weitere Informationen zu Cloudzeugen finden Sie unter Deploy a cloud witness for a Failover Cluster (Bereitstellen eines Cloudzeugen für einen Failovercluster).

  • Jumpbox: Wird auch als geschützter Host bezeichnet. Dies ist eine geschützte VM im Netzwerk, die von Administratoren zum Herstellen der Verbindung mit anderen VMs verwendet wird. Die Jumpbox verfügt über eine NSG, bei der Remotedatenverkehr nur von öffentlichen IP-Adressen zugelassen wird, die in einer Liste mit sicheren Adressen enthalten sind. Die NSG sollte Remotedesktop-Datenverkehr (RDP) zulassen.

Empfehlungen

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

Virtuelle Computer

Empfehlungen zum Konfigurieren der VMs finden Sie unter Ausführen eines virtuellen Windows-Computers in Azure.

Virtuelles Netzwerk

Legen Sie bei der Erstellung des virtuellen Netzwerks (VNET) fest, wie viele IP-Adressen Ihre Ressourcen in jedem Subnetz benötigen. Geben Sie mithilfe der CIDR eine Subnetzmaske und einen VNET-Adressbereich an, der für die erforderlichen IP-Adressen groß genug ist. Verwenden Sie einen Adressraum, der in die standardmäßigen privaten IP-Adressblöcke 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16 fällt.

Wählen Sie einen Adressbereich, der sich nicht mit Ihrem lokalen Netzwerk überschneidet, für den Fall, dass Sie später ein Gateway zwischen dem virtuellen Netzwerk und dem lokalen Netzwerk einrichten müssen. Sobald Sie das virtuelle Netzwerk erstellt haben, können Sie den Adressbereich nicht mehr ändern.

Entwerfen Sie Subnetze unter Berücksichtigung der Funktionalität und Sicherheitsanforderungen. Alle VMs innerhalb derselben Schicht oder Rolle sollten im selben Subnetz platziert werden, was eine Sicherheitsbegrenzung darstellen kann. Weitere Informationen zum Entwerfen von virtuellen Netzwerken und Subnetzen finden Sie unter Planen und Entwerfen von Azure Virtual Networks.

Application Gateway

Weitere Informationen zum Konfigurieren von Application Gateway finden Sie unter Application Gateway – Konfigurationsübersicht.

Load Balancer

Machen Sie die VMs nicht direkt über das Internet verfügbar. Weisen Sie stattdessen jeder VM eine private IP-Adresse zu. Clients stellen über die öffentliche IP-Adresse eine Verbindung her, die dem Application Gateway zugeordnet ist.

Definieren Sie Lastenausgleichsregeln, um Netzwerkdatenverkehr an die virtuellen Computer weiterzuleiten. Um HTTP-Datenverkehr zuzulassen, ordnen Sie beispielsweise den Port 80 in der Front-End-Konfiguration dem Port 80 im Back-End-Adresspool zu. Wenn ein Client eine HTTP-Anforderung an Port 80 sendet, wählt der Lastenausgleich mithilfe eines Hashalgorithmus, der die Quell-IP-Adresse enthält, eine Back-End-IP-Adresse aus. So werden Clientanforderungen auf alle VMs im Back-End-Adresspool verteilt.

Netzwerksicherheitsgruppen

Verwenden Sie NSG-Regeln, um den Datenverkehr zwischen den Schichten zu beschränken. In der oben gezeigten dreischichtigen Architektur kommuniziert die Internetschicht nicht direkt mit der Datenbankschicht. Um diese Regel zu erzwingen, sollte die Datenbankschicht eingehenden Datenverkehr aus dem Subnetz der Internetschicht blockieren.

  1. Verweigern Sie sämtlichen eingehenden Datenverkehr aus dem virtuellen Netzwerk. (Verwenden Sie den VIRTUAL_NETWORK-Tag in der Regel.)
  2. Lassen Sie eingehenden Datenverkehr aus dem Subnetz der Unternehmensschicht zu.
  3. Lassen Sie eingehenden Datenverkehr aus dem Subnetz der Datenbankschicht zu. Diese Regel ermöglicht die Kommunikation zwischen den virtuellen Datenbankcomputern, die für die Replikation und das Failover der Datenbank erforderlich ist.
  4. Lassen Sie RDP-Datenverkehr (Port 3389) aus dem Subnetz der Jumpbox zu. Diese Regel erlaubt Administratoren, über die Jumpbox eine Verbindung mit der Datenbankschicht herzustellen.

Erstellen Sie die Regeln 2–4 mit einer höheren Priorität als die erste Regel, damit sie Vorrang haben.

SQL Server Always On-Verfügbarkeitsgruppen

Um Hochverfügbarkeit von SQL Server zu erzielen, werden AlwaysOn-Verfügbarkeitsgruppen empfohlen. Bei früheren Versionen als Windows Server 2016 erfordern AlwaysOn-Verfügbarkeitsgruppen einen Domänencontroller, und alle Knoten in der Verfügbarkeitsgruppe müssen sich in der gleichen AD-Domäne befinden.

Andere Schichten stellen über einen Verfügbarkeitsgruppenlistener eine Verbindung mit der Datenbank her. Mit dem Listener kann ein SQL-Client eine Verbindung herstellen, ohne den Namen der physischen SQL Server-Instanz zu kennen. VMs, die auf die Datenbank zugreifen, müssen Mitglied der Domäne sein. Der Client (in diesem Fall eine andere Schicht) verwendet DNS, um den Namen des virtuellen Netzwerks des Listeners in IP-Adressen aufzulösen.

Konfigurieren Sie die SQL Server-Always On-Verfügbarkeitsgruppe wie folgt:

  1. Erstellen Sie einen WSFC-Cluster (Windows Server Failover Clustering), eine SQL Server Always On-Verfügbarkeitsgruppe und ein primäres Replikat. Weitere Informationen finden Sie unter Erste Schritte mit Always On-Verfügbarkeitsgruppen (SQL Server).

  2. Erstellen Sie ein internes Lastenausgleichsmodul mit einer statischen privaten IP-Adresse.

  3. Erstellen Sie einen Verfügbarkeitsgruppenlistener, und ordnen Sie den DNS-Namen des Listeners der IP-Adresse eines internen Lastenausgleichsmoduls zu.

  4. Erstellen Sie eine Lastenausgleichsregel für den SQL Server-Überwachungsport (standardmäßig TCP-Port 1433). Die Lastenausgleichsregel muss Floating IP, auch als „Direct Server Return“ bezeichnet, aktivieren. Dies bewirkt, dass die VM direkt auf den Client antwortet, was eine direkte Verbindung mit dem primären Replikat ermöglicht.

    Hinweis

    Wenn die Floating IP aktiviert ist, muss die Portnummer des Front-Ends mit der des Back-Ends in der Lastenausgleichsregel übereinstimmen.

Wenn ein SQL-Client versucht, eine Verbindung herzustellen, leitet das Lastenausgleichsmodul die Verbindungsanforderung an das primäre Replikat weiter. Bei einem Failover zu einem anderen Replikat leitet der Lastenausgleich neue Anforderungen automatisch an ein neues primäres Replikat weiter. Weitere Informationen finden Sie unter Konfigurieren eines ILB-Listeners für AlwaysOn-Verfügbarkeitsgruppen in Azure.

Bei einem Failover werden bestehende Clientverbindungen geschlossen. Nachdem das Failover abgeschlossen ist, werden neue Verbindungen an das neue primäre Replikat weitergeleitet.

Wenn Ihre Anwendung deutlich mehr Lesezugriffe als Schreibzugriffe tätigt, können Sie einige der schreibgeschützten Abfragen in ein sekundäres Replikat auslagern. Weitere Informationen finden Sie unter Verwenden eines Listeners zum Herstellen einer Verbindung mit einem schreibgeschützten sekundären Replikat (schreibgeschütztes Routing).

Testen Sie Ihre Bereitstellung, indem Sie ein manuelles Failover der Verfügbarkeitsgruppe erzwingen.

Jumpbox

Verweigern Sie den RDP-Zugriff (Remotedesktopprotokoll) über das öffentliche Internet auf die VMs, auf denen die Anwendungsworkload ausgeführt wird. Der gesamte RDP-Zugriff auf diese VMs muss stattdessen über die Jumpbox erfolgen. Ein Administrator meldet sich bei der Jumpbox und von der Jumpbox aus dann bei der anderen VM an. Die Jumpbox lässt RDP-Datenverkehr aus dem Internet zu, jedoch nur von bekannten, sicheren IP-Adressen.

Die Jumpbox hat sehr geringe Leistungsanforderungen. Wählen Sie daher einen virtuellen Computer mit geringer Größe. Erstellen Sie eine öffentliche IP-Adresse für die Jumpbox. Platzieren Sie die Jumpbox im selben virtuellen Netzwerk wie die anderen VMs, jedoch in einem separaten Verwaltungssubnetz.

Fügen Sie zum Schutz der Jumpbox eine NSG-Regel hinzu, die ausschließlich RDP-Verbindungen von einer sicheren Gruppe öffentlicher IP-Adressen zulässt. Konfigurieren Sie die NSGs für die anderen Subnetze, um RDP-Datenverkehr aus dem Verwaltungssubnetz zuzulassen.

Überlegungen zur Skalierbarkeit

Skalierungsgruppen

Erwägen Sie für die Internet- und Unternehmensschichten die Verwendung von Skalierungsgruppen für virtuelle Computer, anstatt separate VMs bereitzustellen. Eine Skalierungsgruppe erleichtert die Bereitstellung und Verwaltung einer Gruppe identischer VMs und ermöglicht die automatische Skalierung der VMs auf der Grundlage von Leistungsmetriken. Mit zunehmender Last auf den virtuellen Computern werden dem Lastenausgleich automatisch zusätzliche virtuelle Computer hinzugefügt. Erwägen Sie die Verwendung von Skalierungsgruppen, wenn Sie VMs schnell aufskalieren müssen oder eine automatische Skalierung benötigen.

Es gibt zwei grundlegende Methoden für das Konfigurieren von virtuellen Computern in einer Skalierungsgruppe:

  • Verwenden Sie Erweiterungen, um die VM nach ihrer Bereitstellung zu konfigurieren. Bei diesem Ansatz dauert das Starten neuer VM-Instanzen länger als bei virtuellen Computern ohne Erweiterungen.

  • Stellen Sie einen verwalteten Datenträger mit einem benutzerdefinierten Datenträgerimage bereit. Diese Option kann möglicherweise schneller bereitgestellt werden. Allerdings müssen Sie das Image auf dem neuesten Stand halten.

Weitere Informationen finden Sie unter Überlegungen zum Entwurf von Skalierungsgruppen.

Tipp

Wenn Sie eine Lösung für die automatische Skalierung verwenden, testen Sie diese im Voraus mit Workloads auf Produktionsebene.

Grenzwerte für Abonnements

Jedes Azure-Abonnement verfügt über Standardeinschränkungen, zu denen auch eine maximale Anzahl von virtuellen Computern pro Region gehört. Sie können den Grenzwert erhöhen, indem Sie eine Supportanfrage einreichen. Weitere Informationen finden Sie unter Grenzwerte für Azure-Abonnements, -Dienste und -Kontingente sowie allgemeine Beschränkungen.

Application Gateway

Application Gateway unterstützt den Modus mit fester Kapazität oder den Modus mit automatischer Skalierung. Der Modus mit fester Kapazität empfiehlt sich für Szenarien mit einheitlichen und vorhersagbaren Workloads. Verwenden Sie den Modus mit automatischer Skalierung für Workloads mit variablem Datenverkehr. Weitere Informationen finden Sie unter Automatische Skalierung und zonenredundantes Application Gateway v2.

Überlegungen zur Verfügbarkeit

Verfügbarkeitszonen bieten die beste Resilienz innerhalb einer einzelnen Region. Wenn Sie eine noch höhere Verfügbarkeit benötigen, erwägen Sie, die Anwendung über zwei Regionen zu replizieren und Azure Traffic Manager für das Failover zu verwenden. Weitere Informationen finden Sie unter Ausführen einer n-schichtigen Anwendung in mehreren Azure-Regionen für Hochverfügbarkeit.

Nicht alle Regionen unterstützen Verfügbarkeitszonen, und nicht alle VM-Größen werden in allen Zonen unterstützt. Führen Sie den folgenden Azure CLI-Befehl aus, um die unterstützten Zonen für jede VM-Größe innerhalb einer Region zu ermitteln:

az vm list-skus --resource-type virtualMachines --zone false --location <location> \
    --query "[].{Name:name, Zones:locationInfo[].zones[] | join(','@)}" -o table

Wenn Sie diese Architektur in einer Region bereitstellen, die keine Verfügbarkeitszonen unterstützt, platzieren Sie die VMs für jede Ebene in einer Verfügbarkeitsgruppe. VMs innerhalb derselben Verfügbarkeitsgruppe werden aus Redundanzgründen auf mehreren physischen Servern, Computerracks, Speichereinheiten und Netzwerkswitches bereitgestellt. Skalierungsgruppen verwenden automatisch Platzierungsgruppen, die als eine implizite Verfügbarkeitsgruppe fungieren.

Wenn Sie in Verfügbarkeitszonen bereitstellen, verwenden Sie die Standard-SKU von Azure Load Balancer und die SKU v2 von Application Gateway. Diese SKUs unterstützen die zonenübergreifende Redundanz. Weitere Informationen finden Sie unter

In einer einzelnen Application Gateway-Bereitstellung können mehrere Instanzen des Gateways ausgeführt werden. Führen Sie für Produktionsworkloads mindestens zwei Instanzen aus.

Integritätstests

Application Gateway und Load Balancer überwachen mit Integritätstests die Verfügbarkeit von VM-Instanzen.

  • Application Gateway verwendet immer einen HTTP-Test.
  • Load Balancer kann sowohl HTTP-Tests als auch TCP-Tests ausführen. Verwenden Sie generell einen HTTP-Test, wenn auf einer VM ein HTTP-Server ausgeführt wird. Verwenden Sie andernfalls TCP.

Kann eine Instanz bei einem Test nicht innerhalb des jeweiligen Zeitlimits erreicht werden, beendet das Gateway oder der Lastenausgleich das Senden von Datenverkehr an die betreffende VM. Der Test wird fortgesetzt. und die VM wird an den Back-End-Pool zurückgegeben, wenn sie wieder verfügbar wird.

HTTP-Tests senden eine HTTP GET-Anforderung an einen angegebenen Pfad und lauschen auf eine HTTP 200-Antwort. Bei diesem Pfad kann es sich um den Stammpfad („/“) oder einen Endpunkt zur Integritätsüberwachung handeln, der benutzerdefinierte Logik zum Überprüfen der Integrität der Anwendung implementiert. Der Endpunkt muss anonyme HTTP-Anforderungen zulassen.

Weitere Informationen zu Integritätstests finden Sie in folgenden Artikeln:

Überlegungen zum Entwerfen eines Integritätstest-Endpunkts finden Sie unter Muster für Überwachung der Integrität von Endpunkten.

Kostenbetrachtung

Verwenden Sie den Azure-Preisrechner, um die Kosten zu ermitteln. Hier finden Sie einige weitere Überlegungen dazu.

VM-Skalierungsgruppen

VM-Skalierungsgruppen sind für alle Windows-VM-Größen verfügbar. Ihnen werden nur die Azure-VMs in Rechnung gestellt, die Sie bereitstellen, sowie alle zusätzlichen zugrunde liegenden Infrastrukturressourcen, die Sie genutzt haben, etwa Speicher und Netzwerk. Für den VM-Skalierungsgruppendienst fallen keine inkrementellen Gebühren an.

Preisoptionen für einzelne VMs finden Sie unter Virtuelle Windows-Computer – Preise.

Datenbank importieren

Wenn Sie Azure SQL DBaas auswählen, können Sie Kosten sparen, da Sie keine Always On-Verfügbarkeitsgruppen und Domänencontrollercomputer konfigurieren müssen. Es gibt mehrere Bereitstellungsoptionen, beginnend mit einer einzelnen Datenbank bis hin zu einer verwalteten Instanz oder Pools für elastische Datenbanken. Weitere Informationen finden Sie in der Azure-Preisübersicht.

Die Preisoptionen für virtuelle SQL Server-Computer finden Sie unter Preisübersicht für SQL-VMs.

Load Balancer

Die Gebühren werden nur anhand der Anzahl von konfigurierten Lastenausgleichsregeln und Ausgangsregeln berechnet. Für NAT-Regeln für eingehenden Datenverkehr fallen keine Gebühren an. Für Load Balancer Standard fallen keine Kosten auf Stundenbasis an, wenn keine Regeln konfiguriert sind.

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

Sicherheitshinweise

Virtuelle Netzwerke stellen in Azure eine Isolationsbegrenzung für Datenverkehr dar. VMs in einem virtuellen Netzwerk können standardmäßig nicht direkt mit VMs in einem anderen virtuellen Netzwerk kommunizieren. Sie können virtuelle Netzwerke jedoch durch Peering virtueller Netzwerke explizit verbinden.

NSGs. Verwenden Sie Netzwerksicherheitsgruppen (NSGs), um den Datenverkehr in das und aus dem Internet zu beschränken. Weitere Informationen finden Sie unter Microsoft Cloud Services und Netzwerksicherheit.

DMZ. Für die Erstellung einer DMZ zwischen dem Internet und dem virtuellen Azure-Netzwerk sollten Sie eventuell eine virtuelle Netzwerkappliance (Network Virtual Appliance, NVA) hinzufügen. NVA ist ein Oberbegriff für eine virtuelle Appliance, die netzwerkbezogene Aufgaben wie Erstellung von Firewalls, Paketüberprüfung, Überwachung und benutzerdefiniertes Routing ausführen kann. Weitere Informationen finden Sie unter Implementieren einer DMZ zwischen Azure und dem Internet.

Verschlüsselung. Verschlüsseln Sie sensible ruhende Daten, und verwalten Sie die Datenbankverschlüsselungsschlüssel mithilfe von Azure Key Vault. Key Vault kann Verschlüsselungsschlüssel in Hardwaresicherheitsmodulen (HSMs) speichern. Weitere Informationen finden Sie unter Konfigurieren der Azure-Schlüsseltresor-Integration für SQL Server auf virtuellen Azure-Computern. Es empfiehlt sich außerdem, Anwendungsgeheimnisse wie Datenbankverbindungszeichenfolgen in Key Vault zu speichern.

DDoS Protection. Die Azure-Plattform stellt DDoS Protection Basic-Schutz standardmäßig bereit. Dieser Basisschutz ist dafür ausgelegt, die Azure-Infrastruktur als Ganzes zu schützen. Obwohl der DDoS Protection Basic-Schutz automatisch aktiviert ist, empfehlen wir die Verwendung von DDoS Protection Standard. DDoS Protection Standard wendet basierend auf den Mustern des Netzwerkdatenverkehrs Ihrer Anwendung eine adaptive Optimierung an, um Bedrohungen zu erkennen. Dadurch können DDoS-Angriffe entschärft werden, die von den infrastrukturweiten DDoS-Richtlinien möglicherweise nicht erkannt werden. DDoS Protection Standard stellt über Azure Monitor auch Warnungen, Telemetrie und Analysen bereit. Weitere Informationen finden Sie unter Azure DDoS Protection – Bewährte Methoden und Referenzarchitekturen.

Überlegungen zu DevOps

Bei dieser Architektur verwenden Sie [Vorlagen für Azure-Bausteine][azbb-template], um die Azure-Ressourcen und die zugehörigen Abhängigkeiten bereitzustellen. Da sich alle Hauptressourcen und die zugehörigen Abhängigkeiten in demselben virtuellen Netzwerk befinden, sind sie in derselben grundlegenden Workload isoliert. Dies vereinfacht die Zuordnung der spezifischen Ressourcen der Workload zu einem Team, damit es alle Aspekte dieser Ressourcen separat verwalten kann. Diese Isolation ermöglicht DevOps die Durchführung von Continuous Integration und Continuous Delivery (CI/CD).

Außerdem können Sie verschiedene Bereitstellungsvorlagen verwenden und in Azure DevOps Services integrieren, um in wenigen Minuten unterschiedliche Umgebungen bereitzustellen. Beispielsweise können Sie das Replizieren von produktionsähnlichen Szenarien oder das Laden von Testumgebungen nur bei Bedarf durchführen, um Kosten zu sparen.

In diesem Fall werden Ihre virtuellen Computer mit VM-Erweiterungen konfiguriert, da sie die Installation von bestimmter zusätzlicher Software ermöglichen, z. B. Antischadsoftware und Sicherheits-Agents. VM-Erweiterungen werden nur während der Erstellung einer VM installiert und ausgeführt. Dies bedeutet Folgendes: Wenn das Betriebssystem zu einem späteren Zeitpunkt nicht richtig konfiguriert wird, ist manuelles Eingreifen erforderlich, um es wieder in den korrekten Zustand zu versetzen.

Tools für die Konfigurationsverwaltung, z. B. Desired State Configuration (DSC), werden in dieser Architektur verwendet, um Active Directory und eine SQL Server Always On-Verfügbarkeitsgruppe zu konfigurieren.

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 virtuellen Computern anmelden müssen. Application Insights ist tatsächlich einer der Komponenten von Azure Monitor, die Ihnen umfassende Metriken und Protokolle zum Überprüfen des Status Ihrer gesamten Azure-Landschaft an die Hand gibt. Mit Azure Monitor können Sie den Status Ihrer Infrastruktur verfolgen.

Achten Sie darauf, nicht nur die Compute-Elemente zu überwachen, die Ihren Anwendungscode unterstützen, sondern auch Ihre Datenplattformen. Dies gilt vor allem für Ihre Datenbanken, da eine schlechte Leistung der Datenebene einer Anwendung schwerwiegende Folgen haben kann.

Um die Umgebung zu testen, in der die Anwendungen ausgeführt werden, sollte eine Versionskontrolle vorhanden sein, und für die Bereitstellung sollten die gleichen Mechanismen wie für den Anwendungscode verwendet werden. Dies ermöglicht es, die Umgebung ebenfalls anhand von DevOps-Testparadigmen zu testen und zu validieren.

Weitere Informationen finden Sie unter Azure Well-Architected Framework im Abschnitt mit den Informationen zum optimalen Betrieb.

Bereitstellen der Lösung

Eine Bereitstellung für diese Referenzarchitektur ist auf GitHub verfügbar. Die gesamte Bereitstellung, die die Ausführung der Skripts zum Konfigurieren von Active Directory Domain Services (AD DS), des Windows Server-Failoverclusters und der SQL Server-Verfügbarkeitsgruppe umfasst, kann bis zu einer Stunde dauern.

Wenn Sie eine Region angeben, die Verfügbarkeitszonen unterstützt, werden die VMs in Verfügbarkeitszonen bereitgestellt. Andernfalls werden die VMs in Verfügbarkeitsgruppen bereitgestellt. Eine Liste der Regionen, die Verfügbarkeitszonen unterstützen, finden Sie unter Unterstützung der Dienste nach Region.

Voraussetzungen

  1. Klonen oder Forken Sie das GitHub-Repository Referenzarchitekturen, oder laden Sie die entsprechende ZIP-Datei herunter.

  2. Installieren Sie Azure CLI 2.0.

  3. Installieren Sie Node und NPM.

  4. Installieren Sie das npm-Paket mit den Azure Bausteinen.

    npm install -g @mspnp/azure-building-blocks
    
  5. Melden Sie sich über eine Eingabeaufforderung, eine Bash-Eingabeaufforderung oder die PowerShell-Eingabeaufforderung folgendermaßen bei Ihrem Azure-Konto an:

    az login
    

Bereitstellungsschritte

  1. Navigieren Sie zum Ordner virtual-machines\n-tier-windows des GitHub-Repositorys für Referenzarchitekturen.

  2. Öffnen Sie die Datei n-tier-windows.json .

  3. Suchen Sie in der Datei n-tier-windows.json nach allen Vorkommen von [replace-with-password] und [replace-with-safe-mode-password], und ersetzen Sie sie durch ein sicheres Kennwort. Speichern Sie die Datei .

    Hinweis

    Wenn Sie den Administratorbenutzernamen ändern, müssen Sie auch die extensions-Blöcke in der JSON-Datei aktualisieren.

  4. Führen Sie den folgenden Befehl aus, um die Architektur bereitzustellen:

    azbb -s <your subscription_id> -g <resource_group_name> -l <location> -p n-tier-windows.json --deploy
    
  5. Wenn die Bereitstellung abgeschlossen ist, öffnen Sie das Azure-Portal und navigieren Sie zur Ressourcengruppe. Suchen Sie das Speicherkonto, das mit „sqlcw“ beginnt. Dies ist das Speicherkonto, das für den Cloudzeugen des Clusters erstellt und verwendet wird. Navigieren Sie zum Speicherkonto, wählen Sie Zugriffsschlüssel aus, und kopieren Sie den Wert von key1. Kopieren Sie auch den Namen des Speicherkontos.

  6. Öffnen Sie die Datei n-tier-windows-sqlao.json .

  7. Suchen Sie in der Datei n-tier-windows-sqlao.json nach allen Vorkommen von [replace-with-password] und [replace-with-sql-password], und ersetzen Sie sie durch ein sicheres Kennwort.

    Hinweis

    Wenn Sie den Administratorbenutzernamen ändern, müssen Sie auch die extensions-Blöcke in der JSON-Datei aktualisieren.

  8. Suchen Sie in der Datei n-tier-windows-sqlao.json nach allen Vorkommen von [replace-with-storageaccountname] und [replace-with-storagekey], und ersetzen Sie sie durch die Werte aus Schritt 5. Speichern Sie die Datei .

  9. Führen Sie den folgenden Befehl aus, um SQL Server Always On zu konfigurieren.

    azbb -s <your subscription_id> -g <resource_group_name> -l <location> -p n-tier-windows-sqlao.json --deploy
    

Nächste Schritte