Unternehmenskritische Basisarchitektur in einer Azure-Zielzone
Diese Referenzarchitektur bietet Anleitungen für die Bereitstellung einer unternehmenskritischen Workload, die zentralisierte gemeinsame Dienste verwendet, lokale Konnektivität benötigt und in andere Workloads eines Unternehmens integriert wird. 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 Azure-Anwendungslandzone bereitstellen möchte, die die Gruppe "Corp. Management" erbt. Die Workload wird voraussichtlich in vorab bereitgestellte freigegebene Ressourcen in der Zielzone der Azure-Plattform integriert, die von zentralisierten Teams verwaltet werden.
Wichtig
Was ist eine Azure-Zielzone? Eine Anwendungslandzone ist ein Azure-Abonnement, in dem die Workload ausgeführt wird. Sie ist mit den freigegebenen Ressourcen der Organisation verbunden. Über diese Verbindung verfügt sie über Zugriff auf die grundlegende Infrastruktur, die zum Ausführen der Workload erforderlich ist, z. B. Netzwerk, Identitätszugriffsverwaltung, Richtlinien und Überwachung. Die Plattform-Landungszonen sind eine Sammlung verschiedener Abonnements, die jeweils eine bestimmte Funktion enthalten. Das Konnektivitätsabonnement bietet z. B. eine zentrale 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 Entlastung der Verwaltung gemeinsam genutzter Ressourcen in zentrale Teams und konzentrieren sich auf die Arbeitsauslastungsentwicklung. Die Organisation profitiert von der Anwendung konsistenter Governance und der Kostenaufschreibung über mehrere Workloads hinweg.
Es wird dringend empfohlen, das Konzept von Azure-Landezonen zu verstehen.
Bei diesem Ansatz ist maximale Zuverlässigkeit eine gemeinsame Verantwortung zwischen Ihnen und dem Plattformteam. Die zentral verwalteten Komponenten müssen sehr zuverlässig sein, damit eine unternehmenskritische Arbeitsauslastung erwartungsgemäß funktioniert. Sie müssen über eine vertrauenswürdige Beziehung zum Plattformteam verfügen, damit Nichtverfügbarkeitsprobleme in den zentralen Diensten, die sich auf die Arbeitsauslastung auswirken, auf Plattformebene verringert werden. Ihr Team ist jedoch für die Fahreranforderungen mit dem Plattformteam verantwortlich, um Ihre Ziele zu erreichen.
Diese Architektur basiert auf der unternehmenskritischen Basisarchitektur mit Netzwerksteuerelementen. Es wird empfohlen, sich mit der Basisarchitektur vertraut zu machen, bevor Sie mit diesem Artikel fortfahren.
Hinweis
Die Anleitung wird durch eine Beispielimplementierung auf Produktionsniveau unterstützt, die die unternehmenskritische Anwendungsentwicklung in Azure veranschaulicht. Diese Implementierung kann als Grundlage für die Weitere Lösungsentwicklung als erster Schritt in Richtung Produktion verwendet werden.
Wichtige Designstrategien
Wenden Sie diese Strategien auf den basiskritischen Basisplan an:
Kritischer Weg
Nicht alle Komponenten der Architektur müssen gleichermaßen zuverlässig sein. Kritischer Pfad enthält die Komponenten, die funktionsfähig bleiben müssen, damit die Workload keine Downzeit oder beeinträchtigte Leistung erlebt. Wenn Sie diesen Pfad schlanker halten, werden Fehlerpunkte minimiert.
Lebenszyklus von Komponenten
Berücksichtigen Sie den Lebenszyklus kritischer Komponenten, da sie auswirkungen auf Ihr Ziel hat, nahezu Null-Down-Zeit zu erreichen. Komponenten können kurzlebige oder kurzlebige Ressourcen sein, die nach Bedarf erstellt und zerstört werden können; Nicht-kurzlebige oder langlebige Ressourcen, die die Lebensdauer mit dem System oder der Region teilen.
Externe Abhängigkeiten
Minimieren Sie externe Abhängigkeiten von Komponenten und Prozessen, wodurch Fehlerpunkte auftreten können. Die Architektur verfügt über Ressourcen im Besitz verschiedener Teams außerhalb Ihres Teams. Diese Komponenten (falls kritisch) sind für diese Architektur im Gültigkeitsbereich.
Abonnementtopologie
Azure-Zielzonen bedeuten keine einzige Abonnementtopologie. Planen Sie ihren Abonnementbedarf im Voraus mit Ihrem Plattformteam, um anforderungen an die Arbeitsauslastungszulässigkeit in allen Umgebungen zu erfüllen.
Autonome Observierbarkeit in den kritischen Weg
Verfügen Sie über dedizierte Überwachungsressourcen, die es dem Team ermöglichen, ihre Datensammlung (insbesondere den kritischen Pfad) schnell abzufragen und auf Korrekturen zu reagieren.
Architektur
Laden Sie eine Visio-Datei dieser Architektur herunter.
Die Komponenten dieser Architektur sind identisch mit der unternehmenskritischen Basisarchitektur mit Netzwerksteuerelementen. Die Beschreibungen sind kurz für Kürze. Wenn Sie weitere Informationen benötigen, lesen Sie die verknüpften Artikel. Produktdokumentation zu Azure-Diensten finden Sie unter "Verwandte Ressourcen".
Globale Ressourcen
Diese Ressourcen befinden sich in den Abonnementen der Anwendungs-Zielzone.These resources live in the application landing zone subscription(s). Globale Ressourcen sind nicht kurzlebig und teilen die Lebensdauer des Systems. Die Azure-Dienste und ihre Konfiguration bleiben mit den grundlegenden globalen Ressourcen identisch.
Regionale Netzwerkressourcen
Diese Ressourcen befinden sich in den Abonnements der Plattform-Landezone und den Abonnements der Anwendungslandzone.These resources live across the platform landing zone subscriptions(s). Die Basisarchitektur stellt alle Ressourcen bereit, die Ihnen gehören. In dieser Architektur werden jedoch Netzwerkressourcen über das Konnektivitätsabonnement bereitgestellt, die als Teil der Plattform-Zielzone bereitgestellt werden.
In diesem Artikel finden Sie im Abschnitt "Virtuelles Netzwerk für regionale Hubs ".
Regionale Stempelressourcen
Diese Ressourcen befinden sich in den Abonnementen der Anwendungs-Zielzone.These resources live in the application landing zone subscription(s). Diese Ressourcen teilen nichts mit anderen Ressourcen, außer den globalen Ressourcen.
Die meisten Azure-Dienste und ihre Konfiguration bleiben mit der Basisstempelarchitektur identisch, mit Ausnahme der Netzwerkressourcen, die vom Plattformteam vorab bereitgestellt werden.
Lesen Sie in diesem Artikel den Abschnitt " Virtuelles Netzwerk", "Regional spoke virtual network ".
Externe Ressourcen
Die Workload interagiert mit lokalen Ressourcen. Einige davon befinden sich auf dem kritischen Pfad für die Workload, z. B. eine lokale Datenbank. Diese Ressourcen und die Kommunikation mit ihnen werden in den gesamt zusammengesetzten Service Level Agreement (SLA) der Arbeitsauslastung einbezogen. Die gesamte Kommunikation erfolgt über das Konnektivitätsabonnement. Es gibt andere externe Ressourcen, die die Workload erreichen kann, aber sie werden nicht als kritisch betrachtet.
Bereitstellungspipelineressourcen
Erstellen und Freigeben von Pipelines für eine unternehmenskritische Anwendung müssen vollständig automatisiert sein, um eine konsistente Möglichkeit zur Bereitstellung eines validierten Stempels zu gewährleisten. Diese Ressourcen bleiben identisch mit der geplanten Bereitstellungspipeline.
Regionale Überwachungsressourcen
Diese Ressourcen befinden sich in den Abonnementen der Anwendungs-Zielzone.These resources live in the application landing zone subscription(s). Überwachungsdaten für globale Ressourcen und regionale Ressourcen werden unabhängig voneinander gespeichert. Die Azure-Dienste und ihre Konfiguration bleiben mit den Basisüberwachungsressourcen identisch.
Lesen Sie in diesem Artikel den Abschnitt "Überlegungen zur Überwachung" .
Verwaltungsressourcen
Um Zugriff auf den privaten Computecluster und andere Ressourcen zu erhalten, verwendet diese Architektur private Build-Agents und Sprungfeldinstanzen für virtuelle Computer. Azure Bastion bietet sicheren Zugriff auf die Sprungfelder. Die Ressourcen innerhalb der Stempel bleiben identisch mit den Basisverwaltungsressourcen.
Überlegungen zum Netzwerk
In diesem Design wird die Workload in der Anwendungslandzone bereitgestellt und benötigt Konnektivität mit den Verbundressourcen in der Plattform-Zielzone. Der Zweck könnte der Zugriff auf lokale Ressourcen sein, das Steuern des Ausgehenden Datenverkehrs usw.
Netzwerktopologie
Das Plattformteam entscheidet die Netzwerktopologie für die gesamte Organisation. Die Hub-Spoke-Topologie wird in dieser Architektur angenommen. 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 und werden vom Plattformteam verwaltet.
Aus unternehmenskritischer Sicht ist dieses Netzwerk nicht kurzlebig, und diese Ressourcen befinden sich auf dem kritischen Weg.
| Azure-Ressource | Zweck |
|---|---|
| Azure ExpressRoute | Bietet private Konnektivität von lokaler zu Azure-Infrastruktur. |
| Azure Firewall | Dient als NVA, die den Ausgangsverkehr prüft und einschränkt. |
| Azure DNS | Stellt eine lokale Namensauflösung bereit. |
| VPN Gateway | Verbindet Remoteorganisationszweige über das öffentliche Internet mit der Azure-Infrastruktur. Dient auch als Alternative zur Sicherung der Konnektivität zum Hinzufügen von Resilienz. |
Die Ressourcen werden in jeder Region bereitgestellt und mit dem virtuellen Speichennetzwerk (weiter unten beschrieben) verknüpft. Stellen Sie sicher, dass Sie die Updates von NVA, Firewallregeln, Routingregeln, ExpressRoute-Failover auf VPN-Gateway, DNS-Infrastruktur usw. verstehen und zustimmen.
Hinweis
Ein wichtiger Vorteil bei der Verwendung des Verbundhubs besteht darin, dass die Workload entweder in Azure oder lokal mit anderen Workloads integriert werden kann, indem sie die vom Unternehmen verwalteten Netzwerkhubs durchlaufen. Diese Änderung senkt auch Ihre Betriebskosten, da ein Teil der Verantwortung in das Plattformteam verschoben wird.
Virtuelles Regionales Speichennetzwerk
Die Anwendungslandzone 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. Einer dient dem Produktionsdatenverkehr und den anderen Zielen der vNext-Bereitstellung. Dieser Ansatz bietet Ihnen die Möglichkeit, zuverlässige und sichere Bereitstellungsmethoden auszuführen.
Virtuelles Betriebsnetzwerk
Der Betriebsdatenverkehr ist in einem separaten virtuellen Netzwerk isoliert. Dieses virtuelle Netzwerk ist nicht kurzlebig und Sie besitzen dieses Netzwerk. Diese Architektur behält das gleiche Design wie die Basisarchitektur mit Netzwerksteuerelementen bei.
Es gibt kein Peering zwischen dem Betriebsnetzwerk und dem Speichennetzwerk. Die gesamte Kommunikation erfolgt über private Links.
Gemeinsame Verantwortung
Sie haben ein klares Verständnis dafür, welches Team für jedes Designelement der Architektur verantwortlich ist. Hier sind 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 sie das Netzwerk entsprechend bereitstellen können.
Plattformteam
Stellen Sie unterschiedliche Adressen für virtuelle Netzwerke bereit, die an Peerings teilnehmen. Überlappende Adressen, z. B. lokale Netzwerke und Arbeitsauslastungsnetzwerke, können zu Unterbrechungen führen, die zu Einem Ausfall führen.
Weisen Sie IP-Adressräume zu, die groß genug sind, um die Laufzeit- und Bereitstellungsressourcen zu enthalten, Failover zu behandeln und Skalierbarkeit zu unterstützen.
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 mit dem Plattformteam regelmäßig bewerten. Weitere Informationen finden Sie unter "Konnektivität mit Azure".
Subnetz für regionale Speichennetzwerke
Sie sind für die Zuordnung 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 mithilfe privater Endpunkte eingeschränkt, genau wie die Basisarchitektur mit Netzwerksteuerelementen. Diese Endpunkte werden in einem dedizierten Subnetz platziert. Private IP-Adressen an die privaten Endpunkte werden von diesem Subnetz zugewiesen.
Cluster-Subnetz Die Skalierbarkeitsanforderungen der Workload beeinflussen, wie viel Adressraum für die Subnetze zugeordnet werden soll. Wenn AKS-Knoten und Pods skaliert werden, werden IP-Adressen aus diesem Subnetz zugewiesen.
Netzwerksegmentierung
Sorgen Sie für eine ordnungsgemäße Segmentierung, sodass die Zuverlässigkeit Ihrer Workload nicht durch nicht autorisierten Zugriff beeinträchtigt wird.
Diese Architektur verwendet Netzwerksicherheitsgruppen (Network Security Groups, NSGs), um den Datenverkehr über Subnetze und das 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.
Achten Sie auf den Workloadentwurf. Es gibt keinen direkten Datenverkehr zwischen den Stempeln. Außerdem gibt es keine regionenübergreifenden Flüsse. Wenn diese Pfade erforderlich sind, muss der Datenverkehr über das Konnektivitätsabonnement fließen.
Verhindern Sie unnötigen Hubdatenverkehr, der von anderen Workloads in den unternehmenskritischen Workload stammt.
Ausgehender Datenverkehr von regionalen Stempeln
Der gesamte ausgehende Datenverkehr aus jedem regionalen Speichennetzwerk wird über die zentrale Azure-Firewall im regionalen Hubnetzwerk weitergeleitet. Sie fungiert als nächster Hop, der den 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 Routentabelle verfügen.
Weisen Sie dem Anwendungsteam angemessene rollenbasierte Zugriffssteuerungsberechtigungen (RBAC) zu, damit sie die Routen basierend auf den Anforderungen der Workload erweitern können.
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 zentrale Netzwerkressourcen pro Region bereit. Die missionskritische Designmethodik erfordert regionale Isolation.
Arbeiten Sie mit dem Anwendungsteam zusammen, um ausgeblendete regionale Abhängigkeiten aufzudecken, damit sich eine beeinträchtigte Plattformressource in einer Region nicht auf Workloads in einer anderen Region auswirkt.
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 sind. Stellen Sie Ihre eigenen DNS-Zonen bereit und verknüpfen Sie den regionalen Stempel. Wenn das Anwendungsteam nicht über DNS verfügt, wird die Verwaltung privater Links für globale Ressourcen wie Azure Cosmos DB herausfordernd.
Plattformteam
Delegieren Sie die Azure Private DNS-Zonen an das Anwendungsteam, um ihre Anwendungsfälle abzudecken.
Legen Sie für das regionale Hubnetzwerk den DNS-Serverwert auf "Standard" (von Azure bereitgestellt) fest, um private DNS-Zonen zu unterstützen, die vom Anwendungsteam verwaltet werden.
Überlegungen zur Umgebungsgestaltung
Es ist eine allgemeine Methode, Workloads in separaten Umgebungen für Die Produktion, Vorproduktion und Entwicklung zu platzieren. Im Folgenden finden Sie einige wichtige Überlegungen.
Wie wird die Isolation beibehalten?
Die Produktionsumgebung muss von anderen Umgebungen isoliert werden. Niedrigere Umgebungen sollten auch eine Isolationsstufe beibehalten. Vermeiden Sie die Freigabe anwendungseigener Ressourcen zwischen Umgebungen.
Eine Produktionsumgebung ist für globale, regionale und Stempelressourcen erforderlich, die im Besitz des Anwendungsteams sind. Vorproduktionsumgebungen wie Staging und Integration sind erforderlich, um sicherzustellen, dass die Anwendung in einer Umgebung getestet wird, in der die Produktion so weit wie möglich simuliert wird. Die Entwicklungsumgebung sollte eine verkleinerte Version der Produktion sein.
Was ist der erwartete Lebenszyklus?
Vorproduktionsumgebungen können zerstört werden, nachdem Validierungstests abgeschlossen wurden. Es wird empfohlen, dass Entwicklungsumgebungen die Lebensdauer eines Features teilen und nach Abschluss der Entwicklung zerstört werden. Diese Aktionen werden durch die Automatisierung der kontinuierlichen Integration/kontinuierlichen Bereitstellung (CI/CD) durchgeführt.
Was sind die Kompromisse?
Berücksichtigen Sie die Kompromisse zwischen der Isolierung von Umgebungen, der Komplexität des Managements und der Kostenoptimierung.
Tipp
Alle Umgebungen sollten Abhängigkeiten von Produktionsinstanzen externer Ressourcen einschließlich Plattformressourcen übernehmen. Beispielsweise ein produktionsregionaler Hub im Konnektivitätsabonnement. Sie können das Delta zwischen Vorproduktions- und Produktionsumgebungen minimieren.
Abonnementtopologie für Workloadinfrastruktur
Abonnements erhalten Sie vom Plattformteam. Je nach 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 können Sie mit dem Plattformteam eine Topologie entwerfen, die das Gesamtzulässigkeitsziel für die Workload erfüllt. Es besteht der Vorteil, die von der Plattform bereitgestellten Ressourcen zwischen Umgebungen im selben Abonnement freizugeben, da sie die Produktionsumgebung widerspiegeln.
Hinweis
Wenn Sie mehrere Abonnements verwenden, um die Umgebungen zu enthalten, kann die erforderliche Isolationsstufe erreicht werden. Zielzonenabonnements werden von derselben Verwaltungsgruppe geerbt. Die Konsistenz mit der Produktion wird also für Tests und Validierungen sichergestellt.
Produktionsabonnement
Möglicherweise gibt es Ressourcenbeschränkungen für das Abonnement, das Sie erhalten haben. Wenn Sie alle diese Ressourcen in einem Abonnement verlagern, erreichen Sie diese Grenzwerte möglicherweise. Berücksichtigen Sie basierend auf Ihren Skalierungseinheiten und der erwarteten Skalierung ein verteiltes Modell. Beispiel:
Ein Abonnement, das sowohl Azure DevOps-Build-Agents als auch globale Ressourcen enthält.
Ein Abonnement pro Region. Sie enthält die regionalen Ressourcen, die Stempelressourcen und Sprungfelder für die regionalen Stempel.
Hier ist eine Beispiel-Abonnementtopologie, die in dieser Architektur verwendet wird.
Vorproduktionsabonnement
Mindestens ein Abonnement ist erforderlich. Es kann jedoch viele unabhängige Umgebungen ausführen, wenn mehrere Umgebungen in dedizierten Abonnements vorhanden sind. Dieses Abonnement kann auch Ressourcenbeschränkungen wie das oben beschriebene Produktionsabonnement unterliegen.
Entwicklungsabonnement
Mindestens ein Abonnement ist erforderlich. Dieses Abonnement kann Ressourcenbeschränkungen unterliegen, wenn alle unabhängigen Umgebungen ausgeführt werden. Sie können also mehrere Abonnements anfordern. Es wird empfohlen, einzelne Umgebungen in ihren dedizierten Abonnements zu verwenden.
Versuchen Sie, die Produktionstopologie so weit wie möglich abzugleichen.
Bereitstellungsüberlegungen
Fehlerhafte Bereitstellungen oder fehlerhafte Versionen 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 Ihr Design in die von der Plattform bereitgestellten Ressourcen und Governance integrieren.
Weitere Informationen finden Sie unter: Gut konzipierte, unternehmenskritische Workloads: Bereitstellung und Tests.
Bereitstellungsinfrastruktur
Zuverlässigkeit der Bereitstellungsinfrastruktur, z. B. Build-Agents und ihr Netzwerk, ist häufig so wichtig wie die Laufzeitressourcen der Workload.
Diese Architektur verwendet private Build-Agents, um unbefugten Zugriff zu verhindern, der sich auf die Verfügbarkeit der Anwendung auswirken kann.
Es wird dringend empfohlen, die Isolation zwischen Bereitstellungsressourcen aufrechtzuerhalten. Eine Bereitstellungsinfrastruktur sollte an Ihre Workloadabonnements für diese Umgebung gebunden sein. Wenn Sie mehrere Umgebungen in Vorabproduktionsabonnements verwenden, erstellen Sie eine weitere Trennung, indem Sie den Zugriff nur auf diese einzelnen Umgebungen beschränken. Bereitstellungsressourcen pro Region könnten berücksichtigt werden, um die Bereitstellungsinfrastruktur zuverlässiger zu gestalten.
Bereitstellung ohne Ausfallzeiten
Aktualisierungen der Anwendung können zu Ausfällen führen. Durch das Erzwingen konsistenter Bereitstellungen wird die Zuverlässigkeit gesteigert. Diese Ansätze werden empfohlen:
- Verfügen Sie über vollständig automatisierte Bereitstellungspipelinen.
- Bereitstellen von Updates in Vorproduktionsumgebungen auf einem sauberen Stempel.
Weitere Informationen finden Sie unter Unternehmenskritische Bereitstellungs- und Testrichtlinien.
In der Basisarchitektur werden diese Strategien implementiert, indem sie die Bereitstellung aufheben und dann den Stempel mit jedem Update abreißen. In diesem Design ist die vollständige Bereitstellung nicht möglich, da das Plattformteam einige Ressourcen besitzt. Das Bereitstellungsmodell wurde also geändert.
Bereitstellungsmodell
Die Basisarchitektur verwendet Blue-Green Modell zum Bereitstellen von Anwendungsupdates. 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 Peer-Netzwerk nicht kurzlebig. Der Stempel darf das virtuelle Netzwerk oder peering nicht 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 Zurücksetzen 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, fügt private Endpunkte hinzu. Anschließend verschiebt es den Datenverkehr in diese Subnetze in diesem vorab bereitgestellten virtuellen Netzwerk.
Wenn der vorhandene Stempel nicht mehr erforderlich ist, werden alle Stempelressourcen von der Pipeline gelöscht, mit Ausnahme der plattformeigenen Ressourcen. Das virtuelle Netzwerk, Diagnoseeinstellungen, Peering, IP-Adressraum, DNS-Konfiguration und rollenbasierte Zugriffssteuerung (RBAC) bleiben erhalten. An diesem Punkt befindet sich der Stempel in einem sauberen Zustand und kann für die nächste neue Bereitstellung bereit sein.
Azure-Richtlinien für DINE (deploy-if-not-exists)
Azure-Anwendungslandzonen verfügen möglicherweise über DINE-Richtlinien (deploy-if-not-exists) Azure-Richtlinien. Diese Überprüfungen stellen sicher, dass bereitgestellte Ressourcen unternehmensinterne Standards in Anwendungslandzonen erfüllen, auch wenn sie im Besitz des Anwendungsteams sind. Es kann ein Konflikt zwischen Ihrer Bereitstellung und der endgültigen Ressourcenkonfiguration geben.
Verstehen Sie die Auswirkungen aller DINE-Richtlinien, die auf Ihre Ressourcen angewendet werden. Wenn Änderungen an der Ressourcenkonfiguration vorliegen, integrieren Sie die Absicht der Richtlinien frühzeitig im Entwicklungszyklus der Workload in Ihre deklarativen Bereitstellungen. Andernfalls kann es zu einer Abweichung kommen, die zwischen dem gewünschten Zustand und dem bereitgestellten Zustand zu Delta führt.
Verwaltung des Bereitstellungsabonnementszugriffs
Behandeln Sie Abonnementgrenzen als Ihre Sicherheitsgrenzen, um den Strahlradius einzuschränken. 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 Abonnement der Anwendungslandzone beschränken.
Wenn Sie mehrere Bereitstellungen in einem einzigen Abonnement ausführen, wirkt sich eine Verletzung auf beide Bereitstellungen aus. Das Ausführen von Bereitstellungen in dedizierten Abonnements wird empfohlen. Erstellen Sie Dienstprinzipale pro Umgebung, um die logische Trennung aufrechtzuerhalten.
Der Dienstprinzipal sollte autonomie über Arbeitsauslastungsressourcen verfügen. Außerdem sollte es Einschränkungen geben, die eine übermäßige Manipulation der Plattformressourcen innerhalb des Abonnements verhindern.
Aspekte der Überwachung
Die Azure-Zielzonenplattform bietet gemeinsam genutzte Observability-Ressourcen als Teil der Verwaltungsabonnements. Das zentrale Betriebsteam ermutigt die Anwendungsteams, das Verbundmodell zu verwenden. Für unternehmenskritische Workloads wird jedoch ein einzelner, zentraler Observability-Speicher nicht empfohlen, da es sich möglicherweise um einen einzelnen Fehlerpunkt handeln kann. Unternehmenskritische Workloads generieren auch Telemetrie, die für zentralisierte Betriebsteams möglicherweise nicht anwendbar oder umsetzbar ist.
Daher wird ein autonomer Ansatz für die Überwachung dringend empfohlen. Arbeitsauslastungsoperatoren sind letztendlich für die Überwachung verantwortlich und müssen Zugriff auf alle Daten haben, die die gesamtintegrität darstellen.
Die Basisarchitektur 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 ist für Ihr Team im Bereich. Nutzen Sie die Azure Diagnostics-Funktionen, die Metriken und Protokolle an verschiedene Senken senden, um Plattformanforderungen für die Protokoll- und Metriksammlung zu unterstützen.
Integritätsmodell
Eine missionskritische Designmethodik erfordert ein Systemintegritätsmodell. Wenn Sie eine allgemeine Integritätsbewertung definieren, schließen Sie in den Bereich der Plattform-Landungszone flüsse ein, von denen die Anwendung abhängig ist. Erstellen Sie Protokoll-, Integritäts- und Warnungsabfragen, um arbeitsbereichübergreifende Überwachung durchzuführen.
Plattformteam
Gewähren Sie rollenbasierte Zugriffssteuerungsabfragen (RBAC) Abfragen und Leseprotokollen für relevante Plattformressourcen, die im kritischen Pfad der unternehmenskritischen Anwendung verwendet werden.
Unterstützen Sie das organisatorische Ziel der Zuverlässigkeit gegenüber der unternehmenskritischen Arbeitsauslastung, indem Sie dem Anwendungsteam genügend Berechtigung zum Ausführen ihrer 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 eine Datenbank zu erreichen, muss das Integritätsmodell eine Netzwerkkonnektivität mit dieser Ressource enthalten, einschließlich Sicherheitsgrenzen wie virtuelle Netzwerkgeräte in Azure und lokal. Diese Informationen sind wichtig, um die Ursache schnell zu ermitteln und die Auswirkungen auf die Zuverlässigkeit zu beheben. Hat der Fehler beispielsweise beim Versuch, an die Datenbank weiterzuleiten, oder gab es ein Problem mit der Datenbank?
Siehe: Gut konzipierte, unternehmenskritische Workloads: Integritätsmodellierung.
Integration mit den von der Plattform bereitgestellten Richtlinien und Regeln
Das Abonnement der Anwendungszielzone erbt Azure-Richtlinien, Azure Network Manager-Regeln und andere Steuerelemente aus der Verwaltungsgruppe. Das Plattformteam stellt diese Schutzschienen bereit.
Für Bereitstellungen hängen Sie nicht ausschließlich von den von der Plattform bereitgestellten Richtlinien ab, da:
- 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 und können sich auf die Zuverlässigkeit auswirken.
Es wird dringend empfohlen, Azure-Richtlinien in Ihren Bereitstellungen zu erstellen und zuzuweisen. Dieser Aufwand kann zu einer Duplizierung führen, aber das ist akzeptabel, und zwar unter Berücksichtigung der potenziellen Auswirkungen auf die Zuverlässigkeit des Systems. Wenn Sich die Plattformrichtlinien ändern, werden die Workloadrichtlinien weiterhin lokal wirksam.
Plattformteam
- Binden Sie das Anwendungsteam in den Änderungsverwaltungsprozess von Richtlinien ein, während sie sich entwickeln.
- Beachten Sie die vom Anwendungsteam verwendeten Richtlinien. Bewerten Sie, ob sie der Verwaltungsgruppe hinzugefügt werden sollen.
Bereitstellen dieser Architektur
Die Vernetzungsaspekte dieser Architektur werden in der mission-critical Connected-Implementierung implementiert.
Hinweis
Die connected-Implementierung soll eine unternehmenskritische Workload veranschaulichen, die auf Organisationsressourcen basiert, in andere Workloads integriert und gemeinsame Dienste verwendet. Bei der Implementierung wird davon ausgegangen, dass bereits ein Konnektivitätsabonnement vorhanden ist.
Nächste Schritte
Überprüfen Sie den Entwurfsbereich "Netzwerk und Konnektivität" in Azure Well-Architected Framework.
Verwandte Ressourcen
Zusätzlich zu den Azure-Diensten, die in der Basisarchitektur verwendet werden, sind diese Dienste für diese Architektur wichtig.