Freigeben über

Erste Schritte mit den Methoden für sichere Upgrades

  • Artikel

Übersicht

In diesem Artikel werden die Methoden für sichere Upgrades (Safe Upgrade Practices, SUP) von Azure Operator Service Manager (AOSM) vorgestellt. Mit diesem Featuresatz kann ein Endbenutzer komplexe Upgrades von CNF-Workloads (Containernetzwerkfunktion), die in Azure Operator Nexus gehostet werden, sicher und, sofern zutreffend, in Übereinstimmung mit den In-Service-Softwareupgrade (ISSU)-Anforderungen von Partnern ausführen. In zukünftigen Artikeln zu diesen Diensten erfahren Sie mehr über die Features und Funktionen für Methoden für sichere Upgrades.

Einführung

Ein von Azure Operator Service Manager unterstützter Netzwerkdienst besteht aus einer oder beliebig vielen containerbasierten Netzwerkfunktionen (CNFs), die im Laufe der Zeit Softwareupdates erfordern. Für jedes Update müssen Sie einen oder mehrere Helm-Vorgänge ausführen, die abhängige Netzwerkfunktionsanwendungen (NfApps) in einer bestimmten Reihenfolge und auf eine Weise aktualisieren, die die Auswirkungen auf den Netzwerkdienst minimiert. In Azure Operator Service Manager stellen die Methoden für sichere Upgrades eine Reihe von Features dar, die die erforderlichen CNF-Vorgänge zum Aktualisieren eines Netzwerkdiensts in Azure Operator Nexus automatisieren können.

  • SNS-Reput-Update (Site Network Service, Standortnetzwerkdienst): Führt den Helm-Upgradevorgang für alle NfApps in der Netzwerkfunktions-Entwurfsversion (Network Function Design Version, NFDV) aus.
  • Nexus-Plattform: Unterstützt SNS-Reput-Vorgänge für Nexus-Plattformziele.
  • Vorgangstimeouts: Bietet die Möglichkeit, Timeouts für jeden NfApp-Vorgang festzulegen.
  • Synchrone Vorgänge: Bietet die Möglichkeit, jeweils einen seriellen NfApp-Vorgang auszuführen.
  • Anhalten bei Fehler: Legen Sie basierend auf dem Flag das Fehlerverhalten so fest, dass nur für den letzten NfApp-Vorgang ein Rollback ausgeführt wird.
  • Testüberprüfung eines einzelnen Charts: Dient zum Ausführen eines Helm-Testvorgangs nach der Erstellung oder einem Update.
  • Umgestalteter SNS-Reput-Vorgang: Verbesserte Methoden, die eine Updatereihenfolge und eine Bereinigungsüberprüfung hinzufügen.

Upgradeansatz

Um einen vorhandenen Azure Operator Service Manager-Standortnetzwerkdienst (SNS) zu aktualisieren, führt der Operator eine Reput-Updateanforderung für die bereitgestellte SNS-Ressource aus. Wenn der SNS CNFs mit mehreren NfApps enthält, wird die Anforderung an alle NfApps verteilt, die in der Netzwerkfunktions-Entwurfsversion (NFDV) definiert sind. Standardmäßig erfolgt die Verarbeitung in der Reihenfolge, in der diese aufgeführt sind, oder optional in der durch den UpdateDependsOn-Parameter definierten Reihenfolge.

Für jede NfApp unterstützt die Reput-Updateanforderung das Erhöhen einer Helm-Chart-Version, das Hinzufügen/Entfernen von Helm-Werten und/oder das Hinzufügen/Entfernen von NfApps. Timeouts können basierend auf bekannten zulässigen Laufzeiten pro NfApp festgelegt werden, NfApps können jedoch nur in serieller Reihenfolge nacheinander verarbeitet werden. Das Reput-Update implementiert die folgende Verarbeitungslogik:

  • NfApps werden entweder in der updateDependsOn-Reihenfolge verarbeitet oder in der sequenziellen Reihenfolge, in der sie aufgeführt sind.
  • NfApps, für die der applicationEnabled-Parameter auf „disable“ festgelegt ist, werden übersprungen.
  • Vorhandene NFApps, auf die nicht in der neuen NFDV verwiesen wird, werden gelöscht.
  • NFApps, die in der alten und neuen NFDV gleich sind, werden aktualisiert.
  • NFApps, die sich nur in der neuen NFDV befinden, werden installiert.

Um Ergebnisse zu gewährleisten, werden NfApp-Tests mit Helm unterstützt, entweder Test vor/nach einem Helm-Upgrade oder eigenständige Helm-Tests. Für Fehler bei Vorher-/Nachher-Tests wird der atomic-Parameter berücksichtigt. Bei atomic/true wird das fehlerhafte Chart zurückgesetzt. Bei atomisch/false wird kein Rollback ausgeführt. Bei eigenständigen Helm-Tests wird der rollbackOnTestFailure-Parameter berücksichtigt. Bei rollbackOnTestFailure/true wird das fehlerhafte Chart zurückgesetzt. Bei rollbackOnTestFailure/false wird kein Rollback ausgeführt.

Voraussetzungen

Bei der Planung eines Upgrades mit Azure Operator Service Manager sollten Sie die folgenden Anforderungen vor der Ausführung des Upgrades berücksichtigen, um den Zeitaufwand für die Durchführung des Upgrades zu optimieren.

  • Führen Sie das Onboarding aktualisierter Artefakte mithilfe von Herausgeber- und/oder Designerworkflows durch.

    • Herausgeber, Speicher, Netzwerkdienstentwurf (Network Service Design, NSDg) und Netzwerkfunktionsentwurfs-Gruppe (Network Function Design Group, NFDg) sind statisch und müssen sich nicht ändern.
      • Zum Speichern der neuen Charts und Images ist ein neues Artefaktmanifest erforderlich. Weitere Informationen zum Hochladen neuer Charts und Images finden Sie in der Dokumentation zum Onboarding.
    • Unter der vorhandenen NFDg und dem vorhandenen NSDg sind eine neue NFDV und eine neue Netzwerkdienst-Entwurfsversion (Network Service Design Version, NSDV) erforderlich.
      • Grundlegende Änderungen der NFDV werden im Abschnitt mit der Schritt-für-Schritt-Anleitung behandelt.
      • Eine neue NSDV ist nur erforderlich, wenn eine neue Konfigurationsgruppenschema-Version (Configuration Group Schema, CGS) eingeführt wird.
    • Falls erforderlich, ein neues Konfigurationsgruppenschema (CGS).
      • Ist erforderlich, wenn ein Upgrade neue verfügbar gemachte Konfigurationsparameter einführt.

  • Erstellen Sie aktualisierte Artefakte mithilfe des Operator-Workflows.

    • Erstellen Sie bei Bedarf neue Konfigurationsgruppenwerte (Configuration Group Values, CGVs) basierend auf dem neuen Konfigurationsgruppenschema (CGS).
    • Verwenden Sie Nutzdaten wieder, und erstellen Sie Nutzdaten, indem Sie die vorhandenen Standort- und Standortnetzwerkdienst-Objekte bestätigen.

  • Aktualisieren Sie Vorlagen, um sicherzustellen, dass Upgradeparameter basierend auf der Konfidenz des Upgrades und dem gewünschten Fehlerverhalten festgelegt werden.

    • In Einstellungen, die für die Produktion verwendet werden, werden Fehlerdetails möglicherweise unterdrückt. In Debug- oder Testeinstellungen können diese Details dagegen angezeigt werden.

Upgradeverfahren

Folgen Sie dem folgenden Prozess, um ein Upgrade mit Azure Operator Service Manager auszulösen.

Erstellen einer neuen NFDV-Ressource

Neue NFDV-Versionen müssen in einem gültigen SemVer-Format vorliegen, und es sind nur höhere Werte von Patch- und Nebenversionsupdates zulässig. Eine niedrigere NFDV-Version ist nicht zulässig. Bei einer mit NFDV 2.0.0 bereitgestellten CNF kann es sich bei der neuen NFDV um Version 2.0.1 oder 2.1.0 handeln, aber nicht um Version 1.0.0 oder 3.0.0.

Aktualisieren neuer NFDV-Parameter

Helm-Chartversionen können aktualisiert werden, und Helm-Werte können bei Bedarf aktualisiert oder parametrisiert werden. Neue NfApps können auch hinzugefügt werden, wenn sie in der bereitgestellten Version nicht vorhanden waren.

Aktualisieren der NFDV mit der gewünschten NfApp-Reihenfolge

UpdateDependsOn ist ein NFDV-Parameter, der zum Angeben der Reihenfolge von NfApps während Updatevorgängen verwendet wird. Wenn UpdateDependsOn nicht angegeben ist, wird die serielle Reihenfolge verwendet, in der CNF-Anwendungen in der verwendeten NFDV aufgeführt sind.

Aktualisieren der NFDV mit dem gewünschten Upgradeverhalten

Stellen Sie sicher, dass Sie alle gewünschten CNF-Anwendungstimeouts, den atomic-Parameter und den rollbackOnTestFailure-Parameter festlegen. Es kann sinnvoll sein, diese Parameter im Laufe der Zeit zu ändern, wenn Sie mehr Vertrauen in das Upgrade gewonnen haben.

Ausgeben des SNS-Reput-Vorgangs

Nach Abschluss des Onboardings wird der Reput-Vorgang übermittelt. Je nach Anzahl, Größe und Komplexität der NfApps kann der Reput-Vorgang einige Zeit in Anspruch nehmen (mehrere Stunden).

Untersuchen der Ergebnisse des Reput-Vorgangs

Wenn der Reput-Vorgang ein erfolgreiches Ergebnis meldet, ist das Upgrade abgeschlossen, und der Benutzer sollte den Status und die Verfügbarkeit des Diensts überprüfen. Wenn für den Reput-Vorgang ein Fehler gemeldet wird, führen Sie die Schritte im Abschnitt zur Wiederherstellung nach Upgradefehlern aus, um den Vorgang fortzusetzen.

Wiederholungsprozedur

In Fällen, in denen ein Reput-Update fehlschlägt, können Sie die folgenden Schritte ausführen, um den Vorgang zu wiederholen.

Diagnostizieren der fehlerhaften NfApp

Beheben Sie die Grundursache für NfApp-Fehler, indem Sie Protokolle und andere Debuginformationen analysieren.

Manuelles Überspringen abgeschlossener Charts

Nach dem Beheben der Probleme mit der fehlerhaften NfApp, aber vor dem Wiederholen des Upgrades, sollten Sie ggf. den applicationEnablement-Parameter ändern, um das Wiederholungsverhalten zu beschleunigen. Dieser Parameter kann auf „false“ festgelegt werden, wenn eine NfApp übersprungen werden soll. Dieser Parameter kann hilfreich sein, wenn für eine NfApp kein Upgrade erforderlich ist.

Ausgeben einer SNS-Reput-Wiederholung (Wiederholen bis zur erfolgreichen Ausführung)

Standardmäßig erfolgen die Reput-Wiederholungen für NfApps in der deklarierten Updatereihenfolge, es sei denn, sie werden mit dem applicationEnablement-Flag übersprungen.

Verwenden von applicationEnablement

In der NFDV-Ressource unter deployParametersMappingRuleProfile ist die applicationEnablement-Eigenschaft vom Typ „enum“ verfügbar, die folgende Werte akzeptiert: „unknown“, „enabled“ oder „disabled“ Sie kann verwendet werden, um NfApp-Vorgänge während der Bereitstellung von Netzwerkfunktionen (NFs) auszuschließen.

Herausgeberänderungen

Für die applicationEnablement-Eigenschaft verfügt der Herausgeber über zwei Optionen: einen Standardwert angeben oder die Eigenschaft parametrisieren.

Beispiel-NFDV

NFDV wird vom Herausgeber verwendet, um Standardwerte für applicationEnablement festzulegen.

{ 
      "location":"<location>", 
      "properties": {
      "networkFunctionTemplate": {
        "networkFunctionApplications": [
          {
            "artifactProfile": {
              "helmArtifactProfile": { 
                "var":"var"
              },
              "artifactStore": {
                "id": "<artifactStore id>"
              }
            },
            "deployParametersMappingRuleProfile": {
              "helmMappingRuleProfile": {
                "releaseNamespace": "{deployParameters.role1releasenamespace}",
                "releaseName": "{deployParameters.role1releasename}"
              },
              "applicationEnablement": "Enabled"
            },
            "artifactType": "HelmPackage",
            "dependsOnProfile": "null",
            "name": "hellotest"
          },
          {
            "artifactProfile": {
              "helmArtifactProfile": {
                 "var":"var"
              },
              "artifactStore": {
                "id": "<artifactStore id>"
              }
            },
            "deployParametersMappingRuleProfile": {
              "helmMappingRuleProfile": {
                "releaseNamespace": "{deployParameters.role2releasenamespace}",
                "releaseName": "{deployParameters.role2releasename}"
              },
              "applicationEnablement": "Enabled"
            },
            "artifactType": "HelmPackage",
            "dependsOnProfile": "null",
            "name": "hellotest1"
          }
        ],
        "nfviType": "AzureArcKubernetes"
      },
      "description": "null",
      "deployParameters": {"type":"object","properties":{"role1releasenamespace":{"type":"string"},"role1releasename":{"type":"string"},"role2releasenamespace":{"type":"string"},"role2releasename":{"type":"string"}},"required":["role1releasenamespace","role1releasename","role2releasenamespace","role2releasename"]},
      "networkFunctionType": "ContainerizedNetworkFunction"
    }
}

Beispiel für eine Konfigurationsgruppenschema-Ressource (CGS-Ressource)

CGS wird vom Herausgeber verwendet, um die roleOverrideValues-Variablen(n) zur Laufzeit vom Operator zur Verfügung zu stellen. roleOverrideValues können nicht standardmäßige Einstellungen für applicationEnablement enthalten.

{
  "type": "object",
  "properties": {
    "location": {
      "type": "string"
    },
    "nfviType": {
      "type": "string"
    },
    "nfdvId": {
      "type": "string"
    },
    "helloworld-cnf-config": {
      "type": "object",
      "properties": {
        "role1releasenamespace": {
          "type": "string"
        },
        "role1releasename": {
          "type": "string"
        },
        "role2releasenamespace": {
          "type": "string"
        },
        "role2releasename": {
          "type": "string"
        },
        "roleOverrideValues1": {
          "type": "string"
        },
        "roleOverrideValues2": {
          "type": "string"
        }
      },
      "required": [
        "role1releasenamespace",
        "role1releasename",
        "role2releasenamespace",
        "role2releasename",
        "roleOverrideValues1",
        "roleOverrideValues2"
      ]
    }
  },
  "required": [
    "nfviType",
    "nfdvId",
    "location",
    "helloworld-cnf-config"
  ]
}

Operatoränderungen

Operatoren erben applicationEnablement-Standardwerte wie von NFDV definiert. Wenn applicationEnablement in CGS parametrisiert wird, muss sie zur Laufzeit über die deploymentValues-Eigenschaft übergeben werden.

Beispiel für eine Konfigurationsgruppenwert-Ressource ( (CGV-Ressource)

CGV wird vom Operator verwendet, um die roleOverrideValues-Variablen(n) zur Laufzeit festzulegen. roleOverrideValues enthält eine nicht standardmäßige Einstellung für applicationEnablement.

{
  "location": "<location>",
  "nfviType": "AzureArcKubernetes",
  "nfdvId": "<nfdv_id>",
  "helloworld-cnf-config": {
    "role1releasenamespace": "hello-test-releasens",
    "role1releasename": "hello-test-release",
    "role2releasenamespace": "hello-test-2-releasens",
    "role2releasename": "hello-test-2-release",
    "roleOverrideValues1": "{\"name\":\"hellotest\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\":\"Enabled\",\"helmMappingRuleProfile\":{\"releaseName\":\"override-release\",\"releaseNamespace\":\"override-namespace\",\"helmPackageVersion\":\"1.0.0\",\"values\":\"\",\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"30\",\"injectArtifactStoreDetails\":\"true\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"30\",\"injectArtifactStoreDetails\":\"true\"}}}}}",
    "roleOverrideValues2": "{\"name\":\"hellotest1\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\" : \"Enabled\"}}"
  }
}

NF ARM-Beispielvorlage

Die NF ARM-Vorlage wird vom Operator verwendet, um die von CGV festgelegten roleOverrideValues-Variablen an den Ressourcenanbieter zu übermitteln. Der Operator kann die Einstellung applicationEnablement in CGV bei Bedarf ändern und dieselbe NF ARM-Vorlage erneut übermitteln, um das Verhalten zwischen Iterationen zu ändern.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "nameValue": {
      "type": "string",
      "defaultValue": "HelloWorld"
    },
    "locationValue": {
      "type": "string",
      "defaultValue": "eastus"
    },
    "nfviTypeValue": {
      "type": "string",
      "defaultValue": "AzureArcKubernetes"
    },
    "nfviIdValue": {
      "type": "string"
    },
    "config": {
      "type": "object",
      "defaultValue": {}
    },
    "nfdvId": {
      "type": "string"
    }
  },
  "variables": {
    "deploymentValuesValue": "[string(createObject('role1releasenamespace', parameters('config').role1releasenamespace, 'role1releasename',parameters('config').role1releasename, 'role2releasenamespace', parameters('config').role2releasenamespace, 'role2releasename',parameters('config').role2releasename))]",
    "nfName": "[concat(parameters('nameValue'), '-CNF')]",
    "roleOverrideValues1": "[string(parameters('config').roleOverrideValues1)]",
    "roleOverrideValues2": "[string(parameters('config').roleOverrideValues2)]"
  },
  "resources": [
    {
      "type": "Microsoft.HybridNetwork/networkFunctions",
      "apiVersion": "2023-09-01",
      "name": "[variables('nfName')]",
      "location": "[parameters('locationValue')]",
      "properties": {
        "networkFunctionDefinitionVersionResourceReference": {
          "id": "[parameters('nfdvId')]",
          "idType": "Open"
        },
        "nfviType": "[parameters('nfviTypeValue')]",
        "nfviId": "[parameters('nfviIdValue')]",
        "allowSoftwareUpdate": true,
        "configurationType": "Open",
        "deploymentValues": "[string(variables('deploymentValuesValue'))]",
        "roleOverrideValues": [
          "[variables('roleOverrideValues1')]",
          "[variables('roleOverrideValues2')]"
        ]
      }
    }
  ]
}

Unterstützung für In-Service-Upgrades

Azure Operator Service Manager unterstützt nach Möglichkeit In-Service-Upgrades des Diensts, d. h. eine Upgrademethode, die eine Bereitstellungsversion ohne Dienstunterbrechung erhöht. Die Möglichkeit, einen bestimmten Dienst unterbrechungsfrei zu aktualisieren, ist jedoch ein Feature des Diensts selbst. Wenden Sie sich an den Dienstherausgeber, wenn Sie weitere Informationen zu den Funktionen für In-Service-Upgrades benötigen.

Weiterleitung von Suchzielen

Azure Operator Service Manager baut den Featuresatz „Methoden für sichere Upgrades“ weiter aus und fördert Verbesserungen der angebotenen Updatedienste. Die folgenden Features werden derzeit für eine zukünftige Verfügbarkeit geprüft:

  • Verbessern der Steuerung der Upgradeoptionen: Parameter effektiver verfügbar machen
  • NfApps ohne Änderung überspringen: Verarbeitung von NfApps überspringen, bei denen keine Änderungen vorliegen
  • „Rollback bei Fehler“ für die NFDV ausführen: Basierend auf einem Flag bei einem Fehler ein Rollback für alle abgeschlossenen NfApps durchführen
  • Asynchron ausführen: Die Möglichkeit, mehrere NfApp-Vorgänge gleichzeitig auszuführen
  • Images herunterladen: Die Möglichkeit, Images vorab in das Edgerepository herunterzuladen
  • Zielcharts für die Überprüfung: Die Möglichkeit, einen Helm-Test nur für eine bestimmte NfApp auszuführen