Commit von Workflow v2 in Azure Operator Nexus – Network Fabric

Commit-Workflow v2 führt einen modernisierten und transparenten Ansatz für die Anwendung von Konfigurationsänderungen auf Azure Operator Nexus - Network Fabric-Ressourcen ein. Dieser erweiterte Workflow bietet eine bessere Betriebssteuerung, Sichtbarkeit und Fehlerbehandlung während des Konfigurationsaktualisierungsprozesses.

Mit diesem Update können Sie Konfigurationszustände sperren, Änderungen auf Geräteebene in der Vorschau anzeigen, Updates überprüfen und mit Sicherheit übernehmen. Sie können frühere Einschränkungen überwinden, z. B. die Unfähigkeit, Vor- oder Nachkonfigurationen zu prüfen, und Schwierigkeiten bei der Diagnose von Fehlern.

Wichtige Konzepte und Funktionen

Commit-Workflow v2 basiert auf einem strukturierten Änderungsmanagementablauf. Die folgenden Kernfunktionen sind verfügbar:

• Explizite Konfigurationssperre: Erfordert, dass Sie die Konfiguration einer Network Fabric-Ressource explizit sperren, nachdem Änderungen vorgenommen wurden. Dieser Prozess stellt sicher, dass Updates vorhersehbar und kontrolliert angewendet werden.
• Vollständige Gerätekonfigurationsvorschau: Ermöglicht die Sichtbarkeit der genauen Konfiguration, die vor dem Commit auf jedes Gerät angewendet wird. Dieser Schritt hilft, Absichten zu überprüfen und Probleme frühzeitig abzufangen.
• Konfiguration auf Geräte übertragen: Überträgt Änderungen auf Geräte nach der Validierung. In diesem letzten Schritt werden die gesperrten Konfigurations-Updates in der gesamten Infrastruktur angewendet.
• Batchaktualisierungen verwerfen: Ermöglicht das Rollback aller nicht abgeschlossenen Ressourcenänderungen an den letzten bekannten Zustand.
• Erweiterte Einschränkungen: Erzwingt strenge Updateregeln während der Sperr-, Wartungs- und Upgradephasen für Stabilität.

Voraussetzungen

Bevor Sie Commit-Workflow v2 verwenden, stellen Sie sicher, dass die folgenden Umgebungsanforderungen erfüllt sind.

Commit für workflowkompatible Versionen

Die unterstützte Commit-Workflowversion hängt von der Kombination der verwendeten Network Fabric-Laufzeit, der Portalversion und der verwendeten API-Version ab. Verwenden Sie die folgende Tabelle, um zu ermitteln, welcher Commit-Workflow für Ihre Umgebung gilt.

Erforderliche Versionen

Wenn Sie nicht sicher sind, welche Commit-Workflow-Version für Ihr Setup gilt, schlagen Sie die mit dem Workflow kompatiblen Versionen nach.

• Laufzeitversion: Version 5.0.1 oder höher ist für commit-Workflow v2 erforderlich.
• Network Fabric-API-Version: Version 2024-06-15-Preview.
• AzCLI-Version: Version 8.0.0.b3 oder höher.

Unterstützte Upgradepfade zur Laufzeitversion 5.0.1

• Direktes Upgrade: Von 4.0.0 auf 5.0.1 oder von 5.0. bis 5.0.1
• Sequenzielles Upgrade: Von 4.0.0 auf 5.0.0 auf 5.0.1

Verhalten und Einschränkungen

Commit-Workflow v2 führt neue betriebliche Erwartungen und Einschränkungen ein, um Konsistenz und Sicherheit im Konfigurationsmanagement sicherzustellen.

Verfügbarkeits- und Sperrregeln

• Nur für Laufzeitversion 5.0.1+ verfügbar. Downgrade zu v1 wird nicht unterstützt.

• Sperrung ist nur zulässig, wenn:

  • Es ist kein Commit-Vorgang im Gange.
  • Network Fabric wird nicht gewartet oder aktualisiert.
  • Network Fabric befindet sich in einem administratorfähigen Zustand.

Nicht unterstützt während der Wartung oder des Upgrades

Die Lock, ViewDeviceConfiguration, und related post-actions Vorgänge sind bei Wartungs- oder Aktualisierungsfenstern nicht zulässig.

Endgültigkeit des Commits

Nachdem Änderungen übernommen wurden, können sie nicht zurückgesetzt werden. Alle weiteren Änderungen erfordern einen neuen Sperren-Validieren-Commit-Zyklus.

Batchverhalten verwerfen

• Der discard-commit-batch Vorgang:

  • Setzt alle Änderungen der Azure Resource Manager-Ressource auf ihren letzten bekannten guten Zustand zurück.
  • Aktualisiert Administrative/Konfigurationszustände (z. B. werden externe/interne Netzwerke deaktiviert und abgelehnt).
  • Löscht keine Ressourcen. Sie müssen sie bei Bedarf manuell löschen.
  • Ermöglicht das erneute Anwenden von Änderungen durch Patches.

• Wenn die Aktion "Stapel verwerfen" ausgeführt wird:

  • Der Administrative Status der internen/externen Netzwerkressourcen wird auf "deaktiviert" verschoben. Der Konfigurationsstatus wird zurückgewiesen. Die Ressourcen werden nicht automatisch gelöscht. Zum Entfernen ist ein separater Löschvorgang erforderlich.
  • Die an eine Fabric angefügten aktivierten Netzwerkmonitorressourcen können nicht an eine andere Fabric angefügt werden, es sei denn, sie werden zuerst getrennt und zugesichert.
  • Der Konfigurationsstatus wird für Netzwerkmonitorressourcen abgelehnt, die sich in einem deaktivierten Administratorstatus befinden (in der Commit-Warteschlange). Sie können Updates erneut anwenden (PUT/Patch) und den Commit erneut ausführen, um dies zu aktivieren.

Einschränkungen für die Ressourcenaktualisierung

Nach der Sperre: Es werden nur eine begrenzte Gruppe von Erstellungs-, Aktualisierungs- und Löschaktionen (CUD) unterstützt. Beispiele sind nicht angefügte Zugriffssteuerungslisten (ACLs) oder TAP-Regeln (Test Access Point).

Ressourcen, die sich auf Geräte auswirken, z. B. Netzwerk-zu-Netzwerk-Verbindungsverbindungen (Network-to-Network Interconnect, NNI), Isolationsdomäne (ISD), Routingrichtlinie oder ACLs, die an übergeordnete Ressourcen angefügt sind, werden während der Konfigurationssperre blockiert.

Unterstützte Ressourcenaktionen über Commit-Workflow v2 (wenn sich übergeordnete Ressourcen im aktivierten Administratorstatus befinden)

Zulässige Aktionen nach der Konfigurationssperre

In der folgenden Tabelle sind unterstützte Aktionen aufgeführt, nachdem die Konfigurationssperre auf der Fabric aktiviert wurde. Die Aktionen werden nach Typ und Supportstatus kategorisiert.

Unterstützte und nicht unterstützte Aktionen nach der Konfigurationssperre

Verwandte Inhalte

• Verwenden von Commit-Workflow v2 in Azure Operator Nexus