Vorgänge für unternehmenskritische Workloads in Azure

Wie bei jeder Anwendung erfolgt eine Änderung in Ihren unternehmenskritischen Workloads. Die Anwendung wird sich im Laufe der Zeit weiterentwickeln, Schlüssel laufen ab, Patches werden veröffentlicht und vieles mehr. Alle Änderungen und die Wartung sollten mithilfe von Bereitstellungspipelines angewendet werden. Dieser Artikel enthält operative Anleitungen zum Vornehmen allgemeiner Änderungen und Updates.

Die Organisationsausrichtung ist ebenso wichtig für Betriebsprozeduren. Entscheidend für den operativen Erfolg einer unternehmenskritischen Arbeitsauslastung ist, dass die End-to-End-Verantwortlichkeiten in ein einzelnes Team, das DevOps-Team, fallen.

Die technische Ausführung sollte die Funktionen der systemeigenen Azure-Plattform und die Verwendung automatisierter Azure-Pipelines nutzen, um Änderungen an der Anwendung, Infrastruktur und Konfiguration bereitzustellen. Auch hier sollten Wartungsaufgaben automatisiert und manuelle Aufgaben vermieden werden.

In den folgenden Abschnitten werden Ansätze zur Behandlung verschiedener Arten von Änderungen beschrieben.

Anwendungsautomatisierung

Die kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) ermöglicht die ordnungsgemäße Bereitstellung und Überprüfung von unternehmenskritischen Workloads. CI/CD ist der bevorzugte Ansatz zur Einführung von Änderungen in jede Umgebung, einschließlich Entwicklungs-/Testsysteme, Produktion und andere. Bei unternehmenskritischen Workloads sollten die im nachfolgenden Abschnitt aufgeführten Änderungen zur Bereitstellung eines vollständig neuen Stempels führen. Der neue Stempel sollte im Rahmen des Releaseprozesses gründlich getestet werden, bevor der Datenverkehr über eine Blau-Grün-Bereitstellungsstrategie an den Stempel weitergeleitet wird.

In den folgenden Abschnitten werden Änderungen beschrieben, die nach Möglichkeit über CI/CD implementiert werden sollten.

Anwendungsänderungen

Alle Änderungen am Anwendungscode sollten über CI/CD bereitgestellt werden. Der Code sollte erstellt, liniert und anhand von Regressionen getestet werden. Anwendungsabhängigkeiten wie Laufzeitumgebung oder Pakete sollten überwacht werden, wobei Updates über CI/CD bereitgestellt werden.

Infrastrukturänderungen

Infrastruktur sollte modelliert und als Code bereitgestellt werden. Diese Vorgehensweise wird häufig als Infrastruktur als Code (IaC) bezeichnet. Alle Änderungen an der IaC sollten über die CI/CD-Pipelines bereitgestellt werden. Updates für die Infrastruktur, z. B. das Patchen des Betriebssystems, sollten auch über CI/CD-Pipelines verwaltet werden.

Konfigurationsänderungen

Konfigurationsänderungen sind eine häufige Ursache für Anwendungsausfälle. Um diese Ausfälle zu bekämpfen, sollte die Konfiguration für Anwendung oder Infrastruktur als Code erfasst werden. Diese Vorgehensweise wird als "Konfiguration als Code (CaC) bezeichnet.This practice is known as Configuration as Code (CaC). Änderungen an der CaC sollten über CI/CD-Pipelines bereitgestellt werden.

Bibliotheks-/SDK-Updates

Für unternehmenskritische Anwendungen ist es wichtig, dass Quellcode und Abhängigkeiten aktualisiert werden, wenn neue Versionen verfügbar sind. Der empfohlene Ansatz besteht darin, den Änderungsprozess der Konfigurationsverwaltung im Quellcode-Repository zu nutzen. Es sollte so konfiguriert werden, dass Pullanforderungen für verschiedene Abhängigkeitsupdates automatisch erstellt werden, z. B.:

• .NET NuGet-Pakete
• JavaScript Node Package Manager-Pakete
• Terraform-Anbieter

Das folgende Szenario ist ein Beispiel für die Automatisierung von Bibliotheksupdates mithilfe von dependabot- in einem GitHub-Repository.

1. Dependabot erkennt Updates von Bibliotheken und SDK, die im Anwendungscode verwendet werden

2. Dependabot aktualisiert den Anwendungscode in einem Branch und erstellt einen Pull Request (PR) mit diesen Änderungen für den Mainbranch. Die PR enthält alle relevanten Informationen und ist bereit für die endgültige Überprüfung.

3. Wenn der Code Review und die Tests abgeschlossen sind, kann der PR in den Mainbranch gemergt werden.

Für Abhängigkeiten, die dependabot nicht überwachen kann, stelle sicher, dass du Prozesse hast, um neue Versionen zu erkennen.

Schlüssel-/Geheimnis-/Zertifikatswechsel

Die Rotation (Erneuerung) von Schlüsseln und Geheimnissen sollte in jeder Workload eine Standardprozedur sein. Geheime Schlüssel müssen möglicherweise kurzfristig geändert werden, nachdem sie als bewährte Sicherheitspraxis offengelegt oder regelmäßig veröffentlicht wurden.

Da abgelaufene oder ungültige geheime Schlüssel zu Ausfällen der Anwendung (siehe Fehleranalyse)führen können, ist es wichtig, einen klar definierten und bewährten Prozess durchzuführen. Für Azure Mission-Critical werden Stempel nur einige Wochen lang live sein. Aus diesem Grund ist das Rotieren der Geheimnisse von Stempelressourcen kein Problem. Wenn Geheimnisse in einem Stempel ablaufen, würde die Anwendung als Ganzes weiterhin funktionieren.

Die Verwaltung von Geheimnissen für den Zugang zu langfristig lebenden globalen Ressourcen ist jedoch kritisch. Ein bemerkenswertes Beispiel ist die Azure Cosmos DB-API-Schlüssel. Wenn Azure Cosmos DB-API-Schlüssel ablaufen, sind alle Stempel gleichzeitig betroffen und verursachen einen vollständigen Ausfall der Anwendung.

Der folgende Ansatz ist ein missionskritisch getesteter und dokumentierter Ansatz von Azure zur Rotation von Azure Cosmos DB-Schlüsseln, ohne Ausfallzeiten für Dienste zu verursachen, die im Azure Kubernetes Service laufen.

1. Aktualisieren Sie Stempel mit dem sekundärem Schlüssel. Standardmäßig wird der primäre API-Schlüssel für Azure Cosmos DB in jedem Stempel als geheimer Schlüssel im Azure Key Vault gespeichert. Erstellen Sie eine PR, die den IaC-Vorlagencode aktualisiert, der den sekundären Azure Cosmos DB-API-Schlüssel verwendet. Führen Sie diese Änderung über das normale PR-Überprüfungs- und Updateverfahren aus, um als neue Version oder als Hotfix bereitgestellt zu werden.

2. (optional) Wenn das Update als Hotfix für eine vorhandene Version bereitgestellt wurde, übernimmt die Pods nach ein paar Minuten automatisch den neuen Geheimschlüssel aus Azure Key Vault. Der Azure Cosmos DB-Clientcode wird derzeit jedoch nicht mit einem geänderten Schlüssel neu initialisiert. Um dieses Problem zu beheben, starten Sie alle Pods manuell neu, indem Sie die folgenden Befehle in den Clustern verwenden:

   kubectl rollout restart deployment/CatalogService-deploy -n workload
   kubectl rollout restart deployment/BackgroundProcessor-deploy -n workload
   kubectl rollout restart deployment/healthservice-deploy -n workload
   

3. Neu bereitgestellte oder neu gestartete Pods verwenden jetzt den sekundären API-Schlüssel für die Verbindung mit Azure Cosmos DB.

4. Nachdem alle Pods auf allen Stempeln neu gestartet wurden oder ein neuer Stempel bereitgestellt wird, generieren Sie den primären API-Schlüssel für Azure Cosmos DB neu. Hier ist ein Beispiel für den Befehl:

   az cosmosdb keys regenerate --key-kind primary --name MyCosmosDBDatabaseAccount --resource-group MyResourceGroup
   

5. Ändern Sie die IaC-Vorlage so, dass der primäre API-Schlüssel für zukünftige Bereitstellungen verwendet wird. Alternativ können Sie den sekundären Schlüssel weiterhin verwenden und wieder zum primären API-Schlüssel wechseln, wenn es an der Zeit ist, das sekundäre Zu erneuern.

Alarmsignale

Warnungen sind wichtig, um zu verstehen, ob und wann Probleme mit Ihrer Umgebung auftreten. Änderungen an Warnungen und/oder Aktionsgruppen sollten über CI/CD-Pipelines implementiert werden. Weitere Informationen zu Warnungen finden Sie unter Integritätsmodellierung und Einblick in unternehmenskritische Workloads in Azure.

Automatisierung

Viele Plattformen und Dienste, die auf Azure ausgeführt werden, bieten Automatisierung für allgemeine betriebliche Aktivitäten. Diese Automatisierung umfasst die automatische Skalierung und die automatisierte Handhabung von Schlüsseln und Zertifikaten.

Skalierung

Im Rahmen des Anwendungsentwurfs sollten die Skalierungsanforderungen, die eine Skalierungseinheit für den Stempel als Ganzes definieren, festgelegt werden. Die einzelnen Dienste innerhalb des Systems müssen in der Lage sein, ihre Kapazitäten zu erweitern, um Spitzenanforderungen zu erfüllen, oder sie zu reduzieren, um Geld oder Ressourcen zu sparen.

Dienste, die nicht über genügend Ressourcen verfügen, können unterschiedliche Nebenwirkungen aufweisen, einschließlich der folgenden Liste:

• Eine unzureichende Anzahl von Pods, die Nachrichten aus einer Warteschlange/einem Artikel/einer Partition verarbeiten, führt zu einer wachsenden Anzahl nicht verarbeiteter Nachrichten. Dieses Ergebnis wird manchmal als wachsende Warteschlangentiefe bezeichnet.
• Unzureichende Ressourcen für einen Azure Kubernetes-Dienstknoten können dazu führen, dass Pods nicht ausgeführt werden können.
• Das folgende Ergebnis führt zu gedrosselten Anforderungen:
  • Unzureichende Anforderungseinheiten (RUs) für Azure Cosmos DB
  • Unzureichende Verarbeitungseinheiten (PUs) für Event Hubs Premium oder Durchsatzeinheiten (TUs) für Standard
  • Unzureichende Messagingeinheiten (MUs) für den Service Bus Premium-Tarif

Nutzen Sie die Vorteile der automatischen Skalierung der Dienste, sofern möglich, um sicherzustellen, dass Sie über genügend Ressourcen verfügen, um den Bedarf zu erfüllen. Im Folgenden finden Sie features für die automatische Skalierung, die Sie nutzen können:

• Horizontale automatische Podskalierung ermöglicht Ihnen das bedarfsgerechte Erhöhen oder Verringern der Anzahl von Pods, auf denen Workloads ausgeführt werden.
• Mit dem AKS-Cluster-Autoskaler- können Sie die Anzahl der Knoten im Cluster je nach Bedarf erhöhen oder verkleinern.
• Sie können Azure Event Hubs-Durchsatzeinheiten (Standard-Tarif) automatisch hochskalieren.
• Sie können nachrichteneinheiten eines Azure Service Bus-Namespaces automatisch aktualisieren

Verwalten von Schlüsseln, geheimen Schlüsseln und Zertifikaten

Verwenden Sie verwaltete Identitäten, um zu vermeiden, dass API-Schlüssel oder geheime Schlüssel wie Kennwörter verwaltet werden müssen.

Wenn Sie Schlüssel, geheime Schlüssel oder Zertifikate verwenden, verwenden Sie nach Möglichkeit Azure-native Plattformfunktionen. Im Folgenden sind einige Beispiele für diese Funktionen auf Plattformebene aufgeführt:

• Azure Front Door verfügt über integrierte Funktionen für die TLS-Zertifikatverwaltung und -erneuerung.
• Azure Key Vault unterstützt die automatische Drehung von Schlüsseln.

Manuelle Vorgänge

Es gibt operative Aktivitäten, die einen manuellen Eingriff erfordern. Diese Prozesse sollten getestet werden.

Unzustellbare Nachrichten

Nachrichten, die nicht verarbeitet werden können, sollten an eine Warteschleife mit einem für diese Warteschlange konfigurierten Warnhinweis weitergeleitet werden. Diese Nachrichten erfordern in der Regel einen manuellen Eingriff, um das Problem zu verstehen und zu beheben. Sie sollten die Möglichkeit einrichten, unzustellbare Nachrichten anzuzeigen, zu aktualisieren und erneut wiederzugeben.

Azure Cosmos DB-Wiederherstellung

Wenn Azure Cosmos DB-Daten unbeabsichtigt gelöscht, aktualisiert oder beschädigt werden, müssen Sie eine Wiederherstellung aus einer regelmäßigen Sicherung durchführen. Die Wiederherstellung aus einer regelmäßigen Sicherung kann nur über eine Supportanfrage durchgeführt werden. Dieser Vorgang sollte dokumentiert und regelmäßig getestet werden.

Kontingenterhöhungen

Azure-Abonnements haben Kontingentbeschränkungen. Bereitstellungen können fehlschlagen, wenn diese Grenzwerte erreicht werden. Einige Kontingente sind anpassbar. Im Azure-Portal können Sie auf der Seite Meine Kontingente eine Erhöhung für anpassbare Kontingente beantragen. Für nicht anpassbare Kontingente müssen Sie eine Supportanfrage einreichen. Das Azure-Supportteam arbeitet mit Ihnen zusammen, um eine Lösung zu finden.

Wichtig

Überlegungen und Empfehlungen für den operativen Entwurf finden Sie unter Betriebsprozeduren für unternehmenskritische Workloads in Azure.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautoren:

• Rob Bagby | Prinzipalinhaltsentwickler
• Allen Sudbring | Senior Content Developer

Um nicht-öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte

Stellen Sie die Referenzimplementierung bereit, um ein vollständiges Verständnis der Ressourcen und deren Konfiguration zu erhalten, die in dieser Architektur verwendet werden.

Implementierung: Mission-Critical Online