Auf Englisch lesen

Teilen über

Erste Schritte mit den Methoden für sichere Upgrades

  • Artikel

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 (Container Network Function, Containernetzwerkfunktion), die in Azure Operator Nexus gehostet werden, sicher und, sofern zutreffend, in Übereinstimmung mit den ISSU-Anforderungen (In-Service-Softwareupgrade) 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 in sichere Upgrades

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: Möglichkeit, betriebliche 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.
  • 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“ auf NF-Ebene ausführen: Basierend auf einem Flag bei einem Fehler ein Rollback für alle abgeschlossenen NfApps durchführen.
  • Images im Voraus laden: Möglichkeit, Images im Voraus in das Edgerepository herunterzuladen.

Ansatz für sichere Upgrades

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 deaktiviert festgelegt ist, werden übersprungen.
  • NfApps, für die der skipUpgrade-Parameter auf aktiviert festgelegt ist, werden übersprungen, wenn keine Änderungen ermittelt werden.
  • NFApps, die in der alten und neuen NFDV gleich sind, werden aktualisiert.
  • NFApps, die sich nur in der neuen NFDV befinden, werden installiert.
  • Vorhandene NFApps, auf die nicht in der neuen NFDV verwiesen wird, werden gelöscht.

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. Weitere Informationen zu eigenständigen Helmtests finden Sie im folgenden Artikel: Ausführen von Tests nach der Installation oder dem Upgrade

Überlegungen bei In-Service-Upgrades

Azure Operator Service Manager unterstützt allgemein In-Service-Upgrades, sprich eine Upgrademethode, bei der eine Bereitstellungsversion ohne Unterbrechung des ausgeführten Diensts aktualisiert wird. Es sind einige Überlegungen erforderlich, um das ordnungsgemäße Verhalten von AOSM während des ISSU-Betriebs sicherzustellen.

  • Wenn AOSM ein Upgrade für einen sortierten Satz von mehreren nfApps durchführt, wird AOSM zuerst aktualisiert oder es erstellt alle neuen nfApps und löscht dann alle alten nfApps. Dieser Ansatz stellt sicher, dass der Dienst nicht beeinträchtigt wird, bis alle neuen nfApps bereit sind. Dies erfordert jedoch zusätzliche Plattformkapazität, um alte und neue nfApps vorübergehend zu hosten.
  • Wenn AOSM eine NfApp mit mehreren Replikaten aktualisiert, berücksichtigt AOSM die Profileinstellungen der Bereitstellung für die Rolling-Option oder Neuinstallation. Wenn Sie die Rolling-Option verwenden, machen Sie die Werte maxUnavailable und maxSurge als CGS-Parameter verfügbar, die dann zur Laufzeit über den Operator CGV festgelegt werden können.

Die Möglichkeit, einen bestimmten Dienst unterbrechungsfrei zu aktualisieren, ist letztendlich ein Feature des Diensts selbst. Wenden Sie sich an den Herausgeber, um die In-Service-Upgradefunktionen zu verstehen und sicherzustellen, dass sie an den richtigen AOSM-Optionen ausgerichtet sind.

Voraussetzungen für sichere Upgrades

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.

Verfahren für sichere Upgrades

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.

Wiederholungsverfahren für sichere Upgrades

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.

NfApps mithilfe von applicationEnablement überspringen

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.

JSON 
{ 
      "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 festzulegen, dass zur Laufzeit die roleOverrideValues-Variable vom Operator angegeben werden muss. RoleOverrideValues kann Einstellungen für applicationEnablement enthalten, die vom Standard abweichen.

JSON 
{
  "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-Variable zur Laufzeit festzulegen. RoleOverrideValues enthält Einstellungen für applicationEnablement, die vom Standard abweichen.

JSON 
{
  "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 festgelegte Variable für roleOverrideValues an den Ressourcenanbieter (RP) 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.

JSON 
{
  "$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')]"
        ]
      }
    }
  ]
}

NfApps ohne Änderungen überspringen

Das skipUpgrade-Feature wurde entwickelt, um die für CNF-Upgrades benötigte Zeit zu optimieren. Wenn der Herausgeber dieses Flag im roleOverrideValues unter upgradeOptions aktiviert, führt die AOSM-Dienstebene bestimmte Vorabüberprüfungen durch, um zu bestimmen, ob ein Upgrade für eine bestimmte nFApplication übersprungen werden kann. Wenn alle Vorüberprüfungskriterien erfüllt sind, wird das Upgrade für diese Anwendung übersprungen. Andernfalls wird ein Upgrade auf Clusterebene ausgeführt.

Vorüberprüfungskriterien

Ein Upgrade kann übersprungen werden, wenn alle folgenden Bedingungen erfüllt sind:

  1. Der nfApplication-Bereitstellungsstatus ist „erfolgreich“.
  2. Es gibt keine Änderung bei dem Namen oder der Version des Helm-Diagramms.
  3. Es gibt keine Änderung bei den Helm-Werten.

Aktivieren oder Deaktivieren des skipUpgrade-Features

Das skipUpgrade-Feature ist standardmäßig deaktiviert. Wenn dieser optionale Parameter nicht in roleOverrideValues unter upgradeOptions angegeben ist, werden CNF-Upgrades auf herkömmliche Weise fortgesetzt, wobei die nfApplications auf Clusterebene aktualisiert werden.

Aktivieren von SkipUpgrade innerhalb einer Netzwerkfunktionsressource

Informationen zum Aktivieren des SkipUpgrade-Features über roleOverrideValues finden Sie im folgenden Beispiel.

JSON 
{
    "location": "eastus2euap",
    "properties": {
        "publisherName": "xyAzureArcRunnerPublisher",
        "publisherScope": "Private",
        "networkFunctionDefinitionGroupName": "AzureArcRunnerNFDGroup",
        "networkFunctionDefinitionVersion": "1.0.0",
        "networkFunctionDefinitionOfferingLocation": "eastus2euap",
        "nfviType": "AzureArcKubernetes",
        "nfviId": "/subscriptions/4a0479c0-b795-4d0f-96fd-c7edd2a2928f/resourcegroups/ashutosh_test_rg/providers/microsoft.extendedlocation/customlocations/ashutosh_test_cl",
        "deploymentValues": "",
        "roleOverrideValues": [
            "{\"name\":\"hellotest\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"1\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"4\",\"skipUpgrade\":\"true\"}}}}}",
            "{\"name\":\"runnerTest\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"5\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"5\"}}}}}"
        ]
    }
}

Erläuterung des Beispiels

  • NfApplication: hellotest
    • Das skipUpgrade-Flag ist aktiviert. Wenn die Upgradeanforderung für hellotest die Vorüberprüfungskriterien erfüllt, wird das Upgrade übersprungen.
  • NfApplication: runnerTest
    • Das skipUpgrade-Flag ist nicht angegeben. Daher führt runnerTest ein herkömmliches Helm-Upgrade auf Clusterebene aus, auch wenn die Vorabüberprüfungskriterien erfüllt sind.