Diese Referenzarchitektur bietet Leitfäden für die Bereitstellung einer unternehmenskritischen Workload, die zentralisierte freigegebene Dienste nutzt, lokale Konnektivität benötigt und sich in andere Workloads eines Unternehmens integriert. Dieser Leitfaden richtet sich an einen Workloadbesitzer, der Teil eines Anwendungsteams in der Organisation ist.
Möglicherweise befinden Sie sich in dieser Situation, wenn Ihre Organisation die Workload in einer Zielzone für Azure-Anwendungen bereitstellen möchte, die die Unternehmensverwaltungsgruppe erbt. Die Workload soll in vorab bereitgestellte freigegebene Ressourcen in der Zielzone der Azure-Plattform integriert werden, die von zentralisierten Teams verwaltet werden.
Wichtig
Was ist eine Azure-Zielzone? Eine Anwendungszielzone ist ein Azure-Abonnement, in dem die Workload ausgeführt wird. Sie ist mit den freigegebenen Ressourcen der Organisation verbunden. Über diese Verbindung hat sie Zugriff auf die grundlegende Infrastruktur, die zum Ausführen der Workload erforderlich ist, z. B. Netzwerk, Identitätszugriffsverwaltung, Richtlinien und Überwachung. Die Plattformzielzonen sind eine Sammlung verschiedener Abonnements mit jeweils einer bestimmten Funktion. Das Konnektivitätsabonnement bietet z. B. eine zentralisierte DNS-Auflösung, lokale Konnektivität und virtuelle Netzwerkgeräte (Network Virtual Appliances, NVAs), die für die Verwendung durch Anwendungsteams verfügbar sind.
Als Workloadbesitzer profitieren Sie von der Auslagerung der Verwaltung freigegebener Ressourcen an zentrale Teams und konzentrieren sich auf die Workloadentwicklung. Die Organisation profitiert von einer konsistenten Governance und der Amortisierung der Kosten über mehrere Workloads hinweg.
Es wird dringend empfohlen, das Konzept der Azure-Zielzonen zu verstehen.
Bei diesem Ansatz liegt die maximale Zuverlässigkeit in der gemeinsamen Verantwortung zwischen Ihnen und dem Plattformteam. Die zentral verwalteten Komponenten müssen sehr zuverlässig sein, damit eine unternehmenskritische Workload erwartungsgemäß funktioniert. Sie müssen eine vertrauenswürdige Beziehung zum Plattformteam haben, damit Probleme mit der Nichtverfügbarkeit in den zentralisierten Diensten, die sich auf die Workload auswirken, auf Plattformebene verringert werden. Ihr Team ist jedoch dafür verantwortlich, die Anforderungen mit dem Plattformteam zu erfüllen, um Ihre Ziele zu erreichen.
Diese Architektur baut auf der unternehmenskritischen Basisarchitektur mit Netzwerksteuerelementen auf. Es wird empfohlen, dass Sie sich mit der Baseline-Architektur vertraut machen, bevor Sie mit diesem Artikel fortfahren.
Hinweis
Der Leitfaden basiert auf einer Beispielimplementierung für die Produktion, die die Entwicklung einer unternehmenskritischen Anwendung in Azure veranschaulicht. Diese Implementierung kann als Grundlage für die weitere Lösungsentwicklung bei Ihrem ersten Schritt zur Produktion verwendet werden.
Wichtige Entwurfsstrategien
Wenden Sie diese Strategien zusätzlich zur unternehmenskritischen Baseline an:
Kritischer Pfad
Nicht alle Komponenten der Architektur müssen gleich zuverlässig sein. Der kritische Pfad umfasst die Komponenten, die funktionsfähig bleiben müssen, damit die Workload keine Ausfallzeiten oder Leistungseinbußen aufweist. Wenn Sie diesen Pfad schlank halten, werden Fehlerpunkte minimiert.
Lebenszyklus der Komponenten
Berücksichtigen Sie den Lebenszyklus kritischer Komponenten, da dies Auswirkungen auf Ihr Ziel hat, nahezu null Ausfallzeiten zu erreichen. Komponenten können kurzlebige oder flüchtige Ressourcen sein, die bei Bedarf erstellt und zerstört werden können. Nicht kurzlebige oder langlebige Ressourcen, die sich die Lebensdauer mit dem System oder der Region teilen.
Externe Abhängigkeiten
Minimieren Sie externe Abhängigkeiten von Komponenten und Prozessen, die zu Fehlern führen können. Die Architektur weist Ressourcen auf, die verschiedenen Teams außerhalb Ihres Teams gehören. Diese Komponenten (falls kritisch) befinden sich für diese Architektur im Projektumfang.
Abonnementtopologie
Azure-Zielzonen implizieren keine Einzelabonnementtopologie. Planen Sie Ihren Abonnementbedarf im Voraus mit Ihrem Plattformteam, um die Anforderungen an die Workloadzulässigkeit in allen Umgebungen zu erfüllen.
Autonome Einblicke in den kritischen Pfad
Dedizierte Überwachungsressourcen, mit denen das Team seine Datensammlung (insbesondere den kritischen Pfad) schnell abfragen und auf Korrekturen reagieren kann.
Aufbau
Laden Sie eine Visio-Datei dieser Architektur herunter.
Die Komponenten dieser Architektur sind identisch mit der unternehmenskritischen Basisarchitektur mit Netzwerksteuerelementen. Die Beschreibungen sind kurz. Weitere Informationen finden Sie in den verknüpften Artikeln. Eine Produktdokumentation zu Azure-Diensten finden Sie unter Zugehörige Ressourcen.
Globale Ressourcen
Diese Ressourcen befinden sich in den Zielzonenabonnements der Anwendung. Globale Ressourcen sind nicht kurzlebig und während der gesamten Lebensdauer des Systems verfügbar. Die Azure-Dienste und ihre Konfiguration bleiben identisch mit den globalen Baselineressourcen.
Regionale Netzwerkressourcen
Diese Ressourcen werden auf die Plattform-Zielzonenabonnements und die Anwendungs-Zielzonenabonnements verteilt. Die Baselinearchitektur stellt alle Ressourcen bereit, die Ihnen gehören. In dieser Architektur werden Netzwerkressourcen jedoch über das Konnektivitätsabonnement bereitgestellt, das als Teil der Plattformzielzone bereitgestellt wird.
Lesen Sie in diesem Artikel den Abschnitt Virtuelles Netzwerk des regionalen Hubs.
Regionale Stempelressourcen
Diese Ressourcen befinden sich in den Zielzonenabonnements der Anwendung. Diese Ressourcen geben nichts für andere Ressourcen frei außer den globalen Ressourcen.
Die meisten Azure-Dienste und ihre Konfiguration bleiben mit der Baselinestempelarchitektur identisch. Eine Ausnahme stellen die Netzwerkressourcen dar, die vom Plattformteam vorab bereitgestellt werden.
Lesen Sie in diesem Artikel den Abschnitt Virtuelles regionales Spoke-Netzwerk.
Externe Ressourcen
Die Workload interagiert mit lokalen Ressourcen. Einige davon befinden sich im kritischen Pfad für die Workload, z. B. eine lokale Datenbank. Diese Ressourcen und die Kommunikation mit ihnen werden in die gesamte zusammengesetzte Vereinbarung zum Servicelevel der Workload einbezogen. Die gesamte Kommunikation erfolgt über das Konnektivitätsabonnement. Es gibt andere externe Ressourcen, die die Workload möglicherweise erreicht, sie werden allerdings nicht als kritisch betrachtet.
Pipelineressourcen der Bereitstellung
Build- und Releasepipelines für eine unternehmenskritische Anwendung müssen vollständig automatisiert sein, um eine konsistente Bereitstellung eines überprüften Stempels zu gewährleisten. Diese Ressourcen bleiben dieselben wie die Baselinebereitstellungspipeline.
Regionale Überwachungsressourcen
Diese Ressourcen befinden sich in den Zielzonenabonnements der Anwendung. Überwachungsdaten für globale und regionale Ressourcen werden unabhängig voneinander gespeichert. Die Azure-Dienste und ihre Konfiguration bleiben dieselben wie die Baseline-Überwachungsressourcen.
Lesen Sie in diesem Artikel den Abschnitt Aspekte der Überwachung.
Verwaltungsressourcen
Um Zugriff auf den privaten Computecluster und andere Ressourcen zu erhalten, verwendet diese Architektur private Build-Agents und Jumpbox-VM-Instanzen. Azure Bastion bietet sicheren Zugriff auf die Jumpboxen. Die Ressourcen in den Stempeln bleiben dieselben wie die Baseline-Verwaltungsressourcen.
Überlegungen zum Netzwerkbetrieb
Bei diesem Entwurf wird die Workload in der Anwendungszielzone bereitgestellt und benötigt Konnektivität mit den Verbundressourcen in der Plattformzielzone. Der Zweck könnte der Zugriff auf lokale Ressourcen oder die Steuerung des ausgehenden Datenverkehrs usw. sein.
Netzwerktopologie
Das Plattformteam entscheidet über die Netzwerktopologie für die gesamte Organisation. Die Hub-Spoke-Topologie wird in dieser Architektur verwendet. Eine Alternative könnte Azure Virtual WAN sein.
Virtuelles Netzwerk des regionalen Hubs
Das Konnektivitätsabonnement enthält ein virtuelles Hubnetzwerk mit Ressourcen, die von der gesamten Organisation gemeinsam genutzt werden. Diese Ressourcen sind Eigentum des Plattformteams und werden von diesem verwaltet.
Aus unternehmenskritischer Sicht ist dieses Netzwerk nicht kurzlebig, und diese Ressourcen befinden sich auf dem kritischen Pfad.
| Azure-Ressource | Zweck |
|---|---|
| Azure ExpressRoute | Stellt private Konnektivität von der lokalen Infrastruktur zur Azure-Infrastruktur bereit. |
| Azure Firewall | Fungiert als NVA, der ausgehenden Datenverkehr prüft und einschränkt. |
| Azure DNS | Stellt eine standortübergreifende Namensauflösung bereit. |
| VPN Gateway | Verbindet Remoteorganisationsbranches über das öffentliche Internet mit der Azure-Infrastruktur. Dient auch als Alternative zur Sicherungskonnektivität, um die Resilienz zu erhöhen. |
Die Ressourcen werden in jeder Region bereitgestellt und mit dem virtuellen Spoke-Netzwerk verknüpft (nachfolgend beschrieben). Stellen Sie sicher, dass Sie die Updates für NVA, Firewallregeln, Routingregeln, ExpressRoute-Failover auf VPN Gateway, DNS-Infrastruktur usw. verstehen und ihnen zustimmen.
Hinweis
Ein wichtiger Vorteil bei der Verwendung des Verbundhubs besteht darin, dass die Workload entweder in Azure oder standortübergreifend in andere Workloads integriert werden kann, indem sie die von der Organisation verwalteten Netzwerkhubs durchläuft. Diese Änderung senkt auch Ihre Betriebskosten, da ein Teil der Verantwortung auf das Plattformteam übertragen wird.
Virtuelles regionales Spoke-Netzwerk
Die Anwendungszielzone verfügt über mindestens zwei vorab bereitgestellte virtuelle Azure-Netzwerke pro Region, auf die von den regionalen Stempeln verwiesen wird. Diese Netzwerke sind nicht kurzlebig. Eines dient dem Produktionsdatenverkehr, das andere dient der vNext-Bereitstellung. Dieser Ansatz bietet Ihnen die Möglichkeit, zuverlässige und sichere Bereitstellungsmethoden durchzuführen.
Virtuelles Betriebsnetzwerk
Der Betriebsdatenverkehr wird in einem separaten virtuellen Netzwerk isoliert. Dieses virtuelle Netzwerk ist nicht kurzlebig, und Sie besitzen dieses Netzwerk. Diese Architektur behält den gleichen Entwurf wie die Baselinearchitektur mit Netzwerksteuerelementen bei.
Es gibt kein Peering zwischen dem Betriebsnetzwerk und dem Spoke-Netzwerk. Die gesamte Kommunikation erfolgt über Private Links.
Gemeinsame Verantwortung
Ein klares Verständnis dafür, welches Team für jedes Designelement der Architektur verantwortlich ist. Im Anschluss finden Sie einige wichtige Bereiche.
IP-Adressplanung
Nachdem Sie die für die Ausführung Ihrer Workload erforderliche Größe geschätzt haben, arbeiten Sie mit dem Plattformteam zusammen, damit es das Netzwerk entsprechend bereitstellen kann.
Plattformteam
Stellen Sie unterschiedliche Adressen für virtuelle Netzwerke bereit, die an Peerings teilnehmen. Überlappende Adressen, z. B. von lokalen Netzwerken und Workloadnetzwerken, können zu Unterbrechungen führen, die wiederum zu Ausfällen führen.
Ordnen Sie IP-Adressräume zu, die groß genug für die Runtime- und Bereitstellungsressourcen, für die Verarbeitung von Failovers und für die Unterstützung der Skalierbarkeit sind.
Das vorab bereitgestellte virtuelle Netzwerk und Peerings müssen in der Lage sein, das erwartete Wachstum der Workload zu unterstützen. Sie müssen dieses Wachstum regelmäßig mit dem Plattformteam bewerten. Weitere Informationen finden Sie unter Konnektivität mit Azure.
Subnetz für regionale Spoke-Netzwerke
Sie sind für die Zuweisung von Subnetzen im regionalen virtuellen Netzwerk verantwortlich. Die Subnetze und die darin enthaltenen Ressourcen sind kurzlebig. Der Adressraum sollte groß genug sein, um potenzielles Wachstum zu berücksichtigen.
Subnetz für private Endpunkte Nachdem der Datenverkehr das virtuelle Netzwerk erreicht hat, wird die Kommunikation mit PaaS-Diensten innerhalb des Netzwerks durch die Verwendung privater Endpunkte eingeschränkt, genau wie die Baselinearchitektur mit Netzwerksteuerelementen. Diese Endpunkte werden in einem dedizierten Subnetz platziert. Die privaten IP-Adressen für die privaten Endpunkte werden aus diesem Subnetz zugewiesen.
Clustersubnetz Die Skalierbarkeitsanforderungen der Workload beeinflussen, wie viel Adressraum für die Subnetze zugewiesen werden soll. Wenn AKS-Knoten und -Pods horizontal hochskaliert werden, werden IP-Adressen aus diesem Subnetz zugewiesen.
Netzwerksegmentierung
Sorgen Sie für eine ordnungsgemäße Segmentierung, damit die Zuverlässigkeit Ihrer Workload nicht durch nicht autorisierten Zugriff beeinträchtigt wird.
Diese Architektur verwendet Netzwerksicherheitsgruppen (NSGs), um den Datenverkehr zwischen Subnetzen und dem Konnektivitätsabonnement einzuschränken. NSGs verwenden ServiceTags für die unterstützten Dienste.
Plattformteam
Erzwingen Sie die Verwendung von NSGs über Azure Network Manager-Richtlinien.
Beachten Sie den Workloadentwurf. Es gibt keinen direkten Datenverkehr zwischen den Stempeln. Außerdem gibt es keine regionsübergreifenden Flows. Wenn diese Pfade benötigt werden, muss der Datenverkehr über das Konnektivitätsabonnement fließen.
Verhindern Sie unnötigen Hubdatenverkehr von anderen Workloads in die unternehmenskritische Workload.
Ausgehender Datenverkehr von regionalen Stempeln
Der gesamte ausgehende Datenverkehr von jedem regionalen Spoke-Netzwerk wird über die zentrale Azure Firewall im regionalen Hubnetzwerk weitergeleitet. Er fungiert als nächster Hop, der Datenverkehr überprüft und dann zulässt oder verweigert.
Plattformteam
Erstellen Sie UDRs für diese benutzerdefinierte Route.
Weisen Sie Azure-Richtlinien zu, die das Anwendungsteam daran hindern, Subnetze zu erstellen, die nicht über die neue Routingtabelle verfügen.
Erteilen Sie dem Anwendungsteam geeignete Berechtigungen für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC), damit es die Routen basierend auf den Anforderungen der Workload erweitern kann.
Redundanz für mehrere Regionen
Ihre unternehmenskritischen Workloads müssen in mehreren Regionen bereitgestellt werden, um regionalen Ausfällen standzuhalten. Arbeiten Sie mit dem Plattformteam zusammen, um sicherzustellen, dass die Infrastruktur zuverlässig ist.
Plattformteam
Stellen Sie zentralisierte Netzwerkressourcen pro Region bereit. Die unternehmenskritische Entwurfsmethodik erfordert regionale Isolation.
Arbeiten Sie mit dem Anwendungsteam zusammen, um versteckte regionale Abhängigkeiten aufzudecken, damit eine beeinträchtigte Plattformressource in einer Region keine Auswirkungen auf Workloads in einer anderen Region hat.
DNS-Auflösung
Das Konnektivitätsabonnement stellt private DNS-Zonen bereit. Dieser zentralisierte Ansatz kann jedoch nicht die DNS-Anforderungen berücksichtigen, die für Ihren Anwendungsfall spezifisch sein können. Stellen Sie Ihre eigenen DNS-Zonen bereit, und verknüpfen Sie sie mit dem regionalen Stempel. Wenn das Anwendungsteam nicht im Besitz von DNS ist, wird die Verwaltung privater Links für globale Ressourcen wie Azure Cosmos DB zu einer Herausforderung.
Plattformteam
Delegieren Sie die Privates Azure DNS-Zonen an das Anwendungsteam, um ihre Anwendungsfälle abzudecken.
Legen Sie für das regionale Hub-Netzwerk den DNS-Serverwert auf „Standard“ (von Azure bereitgestellt) fest, um private DNS-Zonen zu unterstützen, die vom Anwendungsteam verwaltet werden.
Aspekte des Umgebungsentwurfs
Es ist gängige Praxis, Workloads in separaten Umgebungen für Produktion, Vorproduktion und Entwicklung zu platzieren. Hier einige wichtige Überlegungen dazu:
Wie wird die Isolation aufrechterhalten?
Die Produktionsumgebung muss von anderen Umgebungen isoliert werden. Niedrigere Umgebungen sollten auch eine Isolationsstufe aufrechterhalten. Vermeiden Sie die gemeinsame Nutzung anwendungseigener Ressourcen zwischen Umgebungen.
Eine Produktionsumgebung ist für globale, regionale und Stempelressourcen im Besitz des Anwendungsteams erforderlich. Vorproduktionsumgebungen wie Staging und Integration sind erforderlich, um sicherzustellen, dass die Anwendung in einer Umgebung getestet wird, die die Produktion so weit wie möglich simuliert. Die Entwicklungsumgebung sollte eine herunterskalierte Version der Produktion sein.
Was ist der erwartete Lebenszyklus?
Vorproduktionsumgebungen können nach Abschluss der Validierungstests zerstört werden. Es wird empfohlen, dass Entwicklungsumgebungen die Lebensdauer eines Features gemeinsam nutzen und nach Abschluss der Entwicklung zerstört werden. Diese Aktionen werden anhand von CI/CD-Automatisierung (Continuous Integration/Continuous Deployment) durchgeführt.
Welche Nachteile gibt es?
Berücksichtigen Sie die Kompromisse zwischen der Isolation von Umgebungen, der Komplexität der Verwaltung und der Kostenoptimierung.
Tipp
Alle Umgebungen sollten Abhängigkeiten von Produktionsinstanzen externer Ressourcen aufweisen, einschließlich Plattformressourcen. Beispielsweise ein regionaler Produktionshub im Konnektivitätsabonnement. Sie können das Delta zwischen Vorproduktions- und Produktionsumgebungen minimieren.
Abonnementtopologie für die Workloadinfrastruktur
Abonnements werden Ihnen vom Plattformteam erteilt. Abhängig von der Anzahl der Umgebungen fordern Sie mehrere Abonnements für nur eine Workload an. Abhängig vom Typ der Umgebung benötigen einige Umgebungen möglicherweise dedizierte Abonnements, während andere Umgebungen in einem Abonnement konsolidiert werden können.
Unabhängig davon: Arbeiten Sie mit dem Plattformteam zusammen, um eine Topologie zu entwerfen, die das Gesamtzulässigkeitsziel für die Workload erfüllt. Es birgt Vorteile, die von der Plattform bereitgestellten Ressourcen zwischen Umgebungen im selben Abonnement freizugeben, da sie die Produktionsumgebung widerspiegeln.
Hinweis
Wenn Sie mehrere Abonnements verwenden, die die Umgebungen enthalten, kann die erforderliche Isolationsstufe erreicht werden. Zielzonenabonnements werden von derselben Verwaltungsgruppe geerbt. Daher wird die Konsistenz mit der Produktion für Tests und Validierungen sichergestellt.
Produktionsabonnement
Möglicherweise gibt es Ressourcenlimits für das Abonnement, das Ihnen zugewiesen wurde. Wenn Sie alle diese Ressourcen in einem Abonnement zusammenstellen, erreichen Sie möglicherweise diese Grenzwerte. Basierend auf Ihren Skalierungseinheiten und der erwarteten Skalierung sollten Sie ein stärker verteiltes Modell in Betracht ziehen. Beispiel:
Ein Abonnement, das sowohl Azure DevOps-Build-Agents als auch globale Ressourcen enthält.
Ein Abonnement pro Region Es enthält die regionalen Ressourcen, die Stempelressourcen und Jumpboxen für die regionalen Stempel.
Hier sehen Sie eine Beispieltopologie für Abonnements, die in dieser Architektur verwendet wird.
Vorproduktionsabonnement
Mindestens ein Abonnement ist erforderlich. Es können viele unabhängige Umgebungen ausgeführt werden, es wird jedoch empfohlen, mehrere Umgebungen in dedizierten Abonnements zu verwenden. Dieses Abonnement unterliegt möglicherweise auch Ressourcenlimits wie das oben beschriebene Produktionsabonnement.
Entwicklungsabonnement
Mindestens ein Abonnement ist erforderlich. Dieses Abonnement unterliegt möglicherweise Ressourcengrenzwerten, wenn alle unabhängigen Umgebungen ausgeführt werden. Daher müssen Sie möglicherweise mehrere Abonnements anfordern. Es wird empfohlen, einzelne Umgebungen in ihren dedizierten Abonnements zu verwenden.
Versuchen Sie, die Produktionstopologie so weit wie möglich einzuhalten.
Überlegungen zur Bereitstellung
Fehlerhafte Bereitstellungen oder fehlerhafte Releases sind häufige Ursachen für Anwendungsausfälle. Testen Sie Ihre Anwendung (und neue Features) im Rahmen des Anwendungslebenszyklus gründlich. Wenn Sie die Workload in einer Zielzone bereitstellen, müssen Sie Ihren Entwurf in die von der Plattform bereitgestellten Ressourcen und die Governance integrieren.
Weitere Informationen finden Sie unter Unternehmenskritische Well-Architected Framework-Workloads: Bereitstellung und Tests.
Bereitstellungsinfrastruktur
Die Zuverlässigkeit der Bereitstellungsinfrastruktur, z. B. Build-Agents und deren Netzwerk, ist häufig genauso wichtig wie die Runtimeressourcen der Workload.
Diese Architektur verwendet private Build-Agents, um nicht autorisierten Zugriff zu verhindern, der sich auf die Verfügbarkeit der Anwendung auswirken kann.
Die Aufrechterhaltung der Isolation zwischen Bereitstellungsressourcen wird dringend empfohlen. Eine Bereitstellungsinfrastruktur muss an Ihre Workloadabonnements für diese Umgebung gebunden sein. Wenn Sie mehrere Umgebungen in Vorproduktionsabonnements verwenden, erstellen Sie eine weitere Trennung, indem Sie den Zugriff auf diese einzelnen Umgebungen beschränken. Regionsspezifische Bereitstellungsressourcen können in Betracht gezogen werden, um die Bereitstellungsinfrastruktur zuverlässiger zu machen.
Bereitstellung ohne Ausfallzeit
Updates der Anwendung können zu Ausfällen führen. Das Erzwingen konsistenter Bereitstellungen erhöht die Zuverlässigkeit. Folgende Ansätze werden empfohlen:
- Vollständig automatisierte Bereitstellungspipelines.
- Bereitstellen von Updates in Vorproduktionsumgebungen mit einem sauberen Stempel.
Weitere Informationen finden Sie unter Unternehmenskritische Bereitstellungs- und Testrichtlinien.
In der Baselinearchitektur werden diese Strategien implementiert, indem die Bereitstellung aufgehoben und dann mit dem jeweiligen Update aufgehoben wird. In diesem Entwurf ist die vollständige Aufhebung der Bereitstellung nicht möglich, da das Plattformteam über einige Ressourcen verfügt. Daher wurde das Bereitstellungsmodell geändert.
Bereitstellungsmodell
Die Baselinearchitektur verwendet das Blue-Green Modell, um Anwendungsupdates bereitzustellen. Neue Stempel mit Änderungen werden zusammen mit vorhandenen Stempeln bereitgestellt. Nachdem der Datenverkehr in den neuen Stempel verschoben wurde, wird der vorhandene Stempel zerstört.
In diesem Fall ist das angegebene virtuelle Netzwerk mit Peering nicht kurzlebig. Der Stempel darf kein virtuelles Netzwerk oder Peering mit dem regionalen Hub erstellen. Sie müssen diese Ressourcen in jeder Bereitstellung wiederverwenden.
Das Canary-Modell kann eine sichere Bereitstellung mit der Option zum Rollback erreichen. Zunächst wird ein neuer Stempel mit Codeänderungen bereitgestellt. Die Bereitstellungspipeline verweist auf das vorab bereitgestellte virtuelle Netzwerk und weist Subnetze zu, stellt Ressourcen bereit und fügt private Endpunkte hinzu. Anschließend verschiebt sie Datenverkehr an diese Subnetze in diesem vorab bereitgestellten virtuellen Netzwerk.
Wenn der vorhandene Stempel nicht mehr benötigt wird, werden alle Stempelressourcen mit Ausnahme der plattformeigenen Ressourcen von der Pipeline gelöscht. Das virtuelle Netzwerk, Diagnoseeinstellungen, Peering, IP-Adressraum, DNS-Konfiguration und rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) bleiben erhalten. An diesem Punkt befindet sich der Stempel in einem sauberen Zustand und ist für die nächste neue Bereitstellung bereit.
DINE-Azure-Richtlinien (deploy-if-not-exists; Richtlinien für Bereitstellen, falls nicht vorhanden)
Azure-Anwendungszielzonen verfügen möglicherweise über DINE-Azure-Richtlinien. Diese Überprüfungen stellen sicher, dass bereitgestellte Ressourcen den Unternehmensstandards in Anwendungszielzonen entsprechen, auch wenn sie sich im Besitz des Anwendungsteams befinden. Möglicherweise besteht ein Konflikt zwischen Ihrer Bereitstellung und der endgültigen Ressourcenkonfiguration.
Machen Sie sich mit den Auswirkungen aller DINE-Richtlinien vertraut, die auf Ihre Ressourcen angewendet werden. Wenn Änderungen an der Ressourcenkonfiguration vorgenommen werden, integrieren Sie die Absicht der Richtlinien frühzeitig im Entwicklungszyklus der Workload in Ihre deklarativen Bereitstellungen. Andernfalls kann es zu einer Abweichung zwischen dem gewünschten Zustand und dem bereitgestellten Zustand kommen.
Zugriffsverwaltung für Bereitstellungsabonnements
Behandeln Sie Abonnementgrenzen als Ihre Sicherheitsgrenzen, um den Auswirkungsgrad zu begrenzen. Bedrohungen können sich auf die Zuverlässigkeit der Workload auswirken.
Plattformteam
- Erteilen Sie den Anwendungsteams die Autorisierung für Vorgänge mit Berechtigungen, die auf das Zielzonenabonnement der Anwendung ausgerichtet sind.
Wenn Sie mehrere Bereitstellungen innerhalb eines einzelnen Abonnements ausführen, wirkt sich eine Sicherheitsverletzung auf beide Bereitstellungen aus. Die Ausführung von Bereitstellungen in dedizierten Abonnements wird empfohlen. Erstellen Sie Dienstprinzipale pro Umgebung, um die logische Trennung aufrechtzuerhalten.
Der Dienstprinzipal sollte Autonomie gegenüber Workloadressourcen bereitstellen. Außerdem sollten Einschränkungen gelten, die eine übermäßige Manipulation der Plattformressourcen innerhalb des Abonnements verhindern.
Aspekte der Überwachung
Die Azure-Zielzonenplattform stellt freigegebene Einblickressourcen im Rahmen der Verwaltungsabonnements bereit. Das zentralisierte Betriebsteam ermutigt die Anwendungsteams, das Verbundmodell zu verwenden. Für unternehmenskritische Workloads wird jedoch kein einzelner, zentralisierter Einblickspeicher empfohlen, da es sich möglicherweise um einen Single Point of Failure handelt. Unternehmenskritische Workloads generieren auch Telemetriedaten, die für zentralisierte Betriebsteams möglicherweise nicht anwendbar oder umsetzbar sind.
Daher wird ein autonomer Ansatz für die Überwachung dringend empfohlen. Workloadoperatoren sind letztendlich für die Überwachung verantwortlich und müssen Zugriff auf alle Daten haben, die die allgemeine Integrität darstellen.
Die Baselinearchitektur folgt diesem Ansatz und wird in dieser Referenzarchitektur fortgesetzt. Azure Log Analytics und Azure Application Insights werden regional und global bereitgestellt, um Ressourcen in diesen Bereichen zu überwachen. Das Aggregieren von Protokollen, das Erstellen von Dashboards und Warnungen liegt im Projektumfang Ihres Teams. Nutzen Sie Azure-Diagnose-Funktionen, die Metriken und Protokolle an verschiedene Senken senden, um die Plattformanforderungen für die Protokoll- und Metriksammlung zu unterstützen.
Integritätsmodell
Unternehmenskritische Entwurfsmethodik erfordert ein Systemintegritätsmodell. Wenn Sie eine allgemeine Integritätsbewertung definieren, schließen Sie sie in den Bereich der Plattformzielzonenflows ein, von denen die Anwendung abhängt. Erstellen Sie Protokoll-, Integritäts- und Warnungsabfragen, um eine arbeitsbereichsübergreifende Überwachung durchzuführen.
Plattformteam
Gewähren Sie RBAC-Abfrage- und Leseprotokollsenken für relevante Plattformressourcen, die im kritischen Pfad der unternehmenskritischen Anwendung verwendet werden.
Unterstützen Sie das Organisationsziel der Zuverlässigkeit in Bezug auf die unternehmenskritische Workload, indem Sie dem Anwendungsteam genügend Berechtigungen für seine Vorgänge erteilen.
In dieser Architektur enthält das Integritätsmodell Protokolle und Metriken aus Ressourcen, die im Konnektivitätsabonnement bereitgestellt werden. Wenn Sie diesen Entwurf erweitern, um eine lokale Ressource wie z. B. eine Datenbank zu erreichen, muss das Integritätsmodell Netzwerkkonnektivität zu dieser Ressource haben, einschließlich Sicherheitsgrenzen wie virtuelle Netzwerkgeräte in Azure und lokal. Diese Informationen sind wichtig, um die Grundursache schnell zu ermitteln und die Auswirkungen auf die Zuverlässigkeit zu beheben. Ist der Fehler beispielsweise aufgetreten, wenn versucht wurde, an die Datenbank weiterzuleiten, oder gab es ein Problem mit der Datenbank?
Weitere Informationen finden Sie unter Unternehmenskritische Well-Architected Framework-Workloads: Integritätsmodellierung.
Integration in die von der Plattform bereitgestellten Richtlinien und Regeln
Das Anwendungszielzonenabonnement erbt Azure-Richtlinien, Azure Network Manager-Regeln und andere Steuerelemente von der Verwaltungsgruppe. Das Plattformteam stellt diese Schutzmaßnahmen bereit.
Für Bereitstellungen sind sie aus folgenden Gründen nicht ausschließlich von den von der Plattform bereitgestellten Richtlinien abhängig:
- Sie sind nicht so konzipiert, dass sie die Anforderungen einzelner Workloads abdecken.
- Die Richtlinien und Regeln werden möglicherweise außerhalb Ihres Teams aktualisiert oder entfernt, was sich auf die Zuverlässigkeit auswirken kann.
Es wird dringend empfohlen, dass Sie Azure-Richtlinien in Ihren Bereitstellungen erstellen und zuweisen. Diese Bemühungen können zu einer gewissen Duplizierung führen, aber das ist angesichts der potenziellen Auswirkungen auf die Zuverlässigkeit des Systems akzeptabel. Wenn Änderungen an den Plattformrichtlinien vorgenommen werden, sind die Workloadrichtlinien weiterhin lokal gültig.
Plattformteam
- Binden Sie das Anwendungsteam in den Änderungsverwaltungsprozess von Richtlinien ein.
- Beachten Sie die Richtlinien, die vom Anwendungsteam verwendet werden. Bewerten Sie, ob sie der Verwaltungsgruppe hinzugefügt werden sollen.
Bereitstellen dieser Architektur
Die Netzwerkaspekte dieser Architektur werden in der Implementierung „Unternehmenskritische Verbindung“ umgesetzt.
Hinweis
Die Implementierung vom Typ „Verbindung“ soll eine unternehmenskritische Workload veranschaulichen, die auf organisatorische Ressourcen angewiesen ist, mit anderen Workloads integriert wird und freigegebene Dienste verwendet. Bei der Implementierung wird davon ausgegangen, dass bereits ein Konnektivitätsabonnement vorhanden ist.
Nächste Schritte
Sehen Sie sich den Entwurfsbereich für Netzwerke und Konnektivität in Azure Well-Architected Framework an.
Zugehörige Ressourcen
Zusätzlich zu den Azure-Diensten, die in der Baselinearchitektur verwendet werden, sind diese Dienste für diese Architektur wichtig.