Начало работы с практиками безопасного обновления

В этой статье приведены рекомендации по безопасному обновлению Azure Operator Service Manager (SUP). Эти практики позволяют выполнять сложные обновления сетевых функций, размещенных на Azure Operator Nexus. Поддерживается соответствие обновлениям программного обеспечения без прерывания работы (ISSU), понижению версии программного обеспечения без прерывания работы (ISSD) и откату без прерывания работы (ISSR) в пределах задокументированных ограничений. В этой статье обсуждаются основные концепции обновления, ищите другие статьи для углублённого изучения более продвинутых возможностей.

Общие сведения о безопасных обновлениях

Определенная сетевая функция контейнера состоит из нескольких приложений nf (nfApps), которые с течением времени требуют управления версиями программного обеспечения жизненного цикла и управлением подготовкой конфигурации. Для этого обычно требуется выполнение соответствующих операций helm для каждого nfApp, чтобы установить активную версию программного обеспечения или конфигурации. SUP интеллектуально автоматизирует управление этими операциями в большом масштабе, обеспечивая их выполнение в определенной последовательности и таким образом, чтобы минимизировать влияние на сетевую службу. В следующем списке функций приведены общие сведения о доступных возможностях SUP. Эти функции следует учитывать на соответствующем этапе публикации, проектирования и эксплуатации.

  • Поддержка SNS Reput — расчет и выполнение правильных операций Helm последовательно для ряда nfApps.
  • Кластер Azure Operator Nexus — поддержка рабочих нагрузок, размещенных кластерами Kubernetes с поддержкой Arc и Nexus.
  • Параметр Helm — возможность устанавливать рабочие параметры Helm, такие как атомарность, время ожидания и режим ожидания для каждой операции nfApp.
  • Синхронные операции — возможность последовательного выполнения одной операции над одним nfApp единовременно.
  • Порядок обновления элемента управления— определение различных последовательностей nfApp для установки, обновления и удаления.
  • Проверка nfApp — выполнение операции тестового перехватчика helm после операции создания или обновления helm.
  • Приостановка при сбое. Если nfApp завершается сбоем, приостанавливайте последовательность операций для проведения диагностики.
  • Откат при отказе - если nfApp завершается сбоем, выполните откат всех ранее завершенных nfApps до начального состояния.
  • Пропустить nfApp при отсутствии изменений — вручную или автоматически пропускать nfApps, где изменения не требуются.
  • Прерывание. Установите флаг отмены, чтобы остановить последовательность операций перед следующим вызовом nfApp.

Безопасный подход к обновлению

Чтобы обновить существующую сетевую службу оператора Azure Service Manager (SNS), оператор начинает с выполнения запроса PUT к ранее развернутому ресурсу SNS. Где SNS содержит несколько nfApps, для каждой nfpp вычисляется правильная операция helm. Эти операции затем распределяются по всем nfApps, заданным в версии определения сетевой функции (NFDV). По умолчанию в порядке, который они отображаются, или при необходимости в порядке, определенном параметром updateDependsOn . Запрос reput поддерживает различные изменения для каждого nfApp, включая увеличение версии чарта helm, добавление и удаление значений helm и/или добавление и удаление любых nfApps. Некоторые параметры helm, например atomic, timeout и wait, можно установить на уровне nfApp. Основная логика, используемая операцией репутации, происходит следующим образом:

  • nfApps обрабатываются в порядке updateDependsOn упорядочивания или в той последовательности, в которой они появляются.
  • nfApps с набором параметров applicationEnabled для отключения пропускаются.
  • nfApps с параметром skipUpgrade, установленным в enabled, пропускаются, если изменения не обнаружены.
  • nfApps, которые являются общими для старых и новых NFDV, обновляются с помощью helm upgrade.
  • Приложения nfApps, которые есть только в новом NFDV, устанавливаются с помощью helm install.
  • Развернутые nfApps, но не на которые ссылается новый NFDV, удаляются с помощью helm delete.

Чтобы обеспечить результаты, тестирование nfApp поддерживается с помощью методов helm, либо тестов, инициируемых helm pre или post hook, либо с помощью автономного тестового перехватчика helm. Для отказа предварительного или последующего перехватчика параметр atomic учитывается. В случае параметров атомарности или истинности, при сбое диаграммы выполняется откат. С атомарным или ложным значением откат не выполняется. При сбое автономного тестового крюка helm rollbackOnTestFailure соблюдается аналогичная логика, как и для атомарных. Дополнительные сведения об автономном тестировании Helm см. в следующей статье: Запуск тестов после установки или обновления

При сбое операции nfApp и после обработки неудачного nfApp оператор может управлять поведением тех nfApps, которые были изменены до сбоя этого приложения. При приостановке при сбое оператор может принудительно завершить операцию повторного выполнения после сбоя. Это лучше всего позволяет диагностике, так как неисправная среда сохраняется. При откате при сбое оператор может принудительно выполнить откат операции любого nfApp, завершенного до сбоя. Это восстанавливает исходное состояние окружения и минимально влияет на работающую службу. Дополнительные сведения об управлении поведением сбоя обновления см. в следующей статье: управление поведением сбоя обновления

Рекомендации по обновлению в службе

Диспетчер служб Azure обычно поддерживает три этапа операций обслуживания. На этих этапах выполняется обновление, понижение версии или возврат к предыдущей версии развернутого приложения с минимальным прерыванием работы службы.

  • ISSU: обновления в службе. Переадресация версий программного обеспечения или конфигурации в конкретный целевой объект NFDV.
  • ISSD: понижение уровня в службе. Уменьшите версию программного обеспечения или конфигурации назад до определенного целевого объекта NFDV.
  • ISSR: откат в службе. Откат версий программного обеспечения или конфигурации до последнего релиза Helm.

Хотя операции ISSU и ISSD осуществляются операторами, ISSR применяется только при сбоях в выполнении операций ISSU или ISSD. Учитывайте следующие требования высокого уровня, чтобы обеспечить желаемое поведение сетевой функции во время выполнения этапов ISSU, ISSD или ISSR.

  • Операция "reput" сначала обновляет или устанавливает новые nfApps, а затем в последнюю очередь удаляет отсутствующие nfApps.
    • Этот подход гарантирует, что на работу службы не влияет до тех пор, пока все новые nfApps не будут готовы.
    • Этот подход требует достаточной емкости платформы для временного размещения старых и новых nfApps.
  • Операция reput предусматривает соответствие профилю развертывания Helm с параметрами качения или повторного создания для приложения nfApp.
    • Убедитесь, что правильный параметр используется для сохранения функциональности службы во время операций с Helm.
    • При использовании роллирования, подразумевается предоставлять значения maxUnavailable и maxSurge как параметры CGS.

В конечном счете возможность обновления данной сетевой функции без прерывания службы требует тщательной координации между диспетчером служб Azure и сетевой функцией. Обратитесь к издателю сетевых функций, чтобы лучше понять поддерживаемые возможности обновления без остановки обслуживания и убедиться, что они соответствуют соответствующим параметрам конфигурации программы Azure Operator Service Manager. Все операции ISSU, ISSD и ISSU должны сначала тестироваться в управляемой лабораторной среде.

Предварительные требования для безопасного обновления

При планировании обновления необходимо заранее решить следующие требования, чтобы оптимизировать время, затраченное на попытку и обеспечить успешность обновления.

  • Подключение обновленных артефактов с помощью рабочих процессов издателя и(или) конструктора.
    • В большинстве случаев используйте существующего издателя для размещения новой версии артефактов.
      • Использование существующего издателя позволяет helm upgrade обновить SNS до более поздней версии.
      • Для использования нового издателя требуется выполнение helm delete на текущей SNS, а затем выполнение helm install для новой версии SNS.
    • Хранилище артефактов, группа разработки сетевых служб (NSDG) и группа проектирования сетевых функций (NFDG) являются неизменяемыми и не могут измениться.
      • Для изменения одного из этих ресурсов требуется развертывание новой SNS.
    • Для хранения новых диаграмм или изображений требуется новый манифест артефакта.
    • Требуется новая версия NFDV и при необходимости версия проектирования сетевой службы (NSDV).
      • Изменения NFDV могут быть сложными. Мы охватываем только основные изменения в этой статье.
      • Новый NSDV требуется только в том случае, если появилась новая версия схемы группы конфигурации (CGS).
    • При необходимости новые системы CGS.
      • Требуется, если обновление вводит новые доступные параметры конфигурации.

Примечание.

NSDVs и NFDV с разными основными версиями можно поддерживать в одной NSDG и NFDG.

  • Создавайте обновленные артефакты с помощью рабочих процессов операторов.
    • При необходимости создайте новые значения группы конфигурации (CGV) на основе новых CGS.
    • Повторно используйте и создавайте полезную нагрузку, подтвердив существующие объекты службы сайта и сети сайта.
  • Обновите шаблоны, чтобы обеспечить настройку параметров обновления на основе уверенности в обновлении и желаемого поведения в случае сбоя.
    • Параметры, используемые для рабочей среды, могут подавлять сведения о сбоях, а параметры, используемые для отладки или тестирования, могут предоставлять эти сведения.

Процедура безопасного обновления

Выполните следующий процесс, чтобы активировать обновление с помощью AOSM.

  • Создайте новый ресурс NFDV
    • Для новых версий NFDV он должен быть в допустимом формате SemVer. Новая версия может быть обновлением, более ценным вариантом по сравнению с развернутой версией, или понижением версии, с меньшим значением по сравнению с развернутой версией. Новая версия может отличаться по основным, незначительным или исправленным значениям.
  • Обновление новых параметров NFDV
    • Версии диаграмм Helm можно обновить, или при необходимости можно обновить или параметризовать значения helm. Новые nfApps можно также добавить там, где они не существовали в развернутой версии.
  • Обновите NFDV для желаемого порядка nfApp
    • UpdateDependsOn — это параметр NFDV, используемый для указания порядка nfApps во время операций обновления. Если updateDependsOn не указан, используется последовательное упорядочение приложений CNF, как указано в NFDV.
  • Обновление шаблона ARM для требуемого поведения обновления
    • Не забудьте задать все нужные значения для timeout, параметра atomic и параметра rollbackOnTestFailure. Может быть полезно изменять эти параметры со временем по мере возрастания уверенности в процессе обновления.
  • Проблема с репутацией SNS
    • После завершения подключения выполняется операция повторного копирования. В зависимости от количества, размера и сложности nfApps, операция reput может занять некоторое время (до нескольких часов).
  • Проверка результатов репутации
    • Если репут сообщает об успешном результате, обновление завершено, и пользователь должен проверить состояние и доступность сервиса, а также версию компонента, указанных для всех nfApps. Если репут сообщает о сбое, выполните действия, описанные в разделе по восстановлению после сбоя обновления, чтобы продолжить.

Процедура безопасной повторной попытки обновления

В случаях, когда обновление завершается сбоем, можно выполнить следующий процесс для повторного выполнения операции.

  • Выполните диагностику неисправного nfApp
    • Устраните первопричину сбоя nfApp, анализируя журналы и другие сведения об отладке. Предварительные и пост хуки являются распространенной точкой отказа.
  • Вручную пропускать завершенные диаграммы
    • После исправления сбоя в nfApp, но перед повторной попыткой обновления, рассмотрите возможность изменения параметра applicationEnablement для ускорения повторных попыток.
      • Этот параметр может быть задан как false, где следует пропустить nfApp.
      • Этот параметр может быть полезен, если nfApp не требует обновления.
  • Отправка повторных запросов SNS (повторять до успешного выполнения).
    • По умолчанию повторные попытки обработки nfApps выполняются в объявленном порядке обновления, если они не пропускаются с помощью флага applicationEnablement.

Управляйте временем ожидания с помощью installOptions и UpgradeOptions

При запуске операции SNS, будь то helm install или helm upgrade, используется значение времени ожидания по умолчанию в 27 минут. Хотя это значение можно настроить на уровне глобальной сетевой функции (NF), рекомендуется настроить это значение на уровне компонента NF с помощью roleOverrideValues шаблона полезных данных NF. Дальнейшее отображение roleOverrideValues в CGS/CGV позволяет управление оператором во время выполнения программы. В следующем примере показаны поддерживаемые параметры installOptions и upgradeOptions, применяемые между двумя компонентами nfApp;

{
  "roleOverrideValues": [
    {
      "name": "nfApplication1",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            } } } } },
    {
      "name": "nfApplication2",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            } } } } }
  ]
}

Пропуск nfApps с помощью applicationEnablement

В ресурсе NFDV под deployParametersMappingRuleProfile есть поддерживаемое свойство типа перечисления applicationEnablement, которое принимает значения Unknown, Enabled или Disabled. Его можно использовать для ручного исключения операций nfApp во время развертывания сетевых функций. В следующем примере демонстрируется универсальный метод для параметризации applicationEnablement в качестве включенного значения в roleOverrideValues свойстве.

Изменения шаблона NFDV

Хотя изменения NFDV не обязательно требуются, при необходимости издатель может использовать NFDV для задания значения по умолчанию для applicationEnablement свойства. Значение по умолчанию используется, пока его не изменят через roleOverrideValues. Используйте шаблон NFDV для задания значения applicationEnablementпо умолчанию. В следующем примере устанавливается состояние enabled в качестве значения по умолчанию для hellotest networkfunctionApplication.

      "location":"<location>", 
      "properties": {
      "networkFunctionTemplate": {
        "networkFunctionApplications": [
            "deployParametersMappingRuleProfile": {
              "applicationEnablement": "Enabled"
            },
            "name": "hellotest"
        ],
        "nfviType": "AzureArcKubernetes"
        },
      }

Чтобы управлять applicationEnablement значением более динамически, оператор может передать значение в режиме реального времени с помощью свойства шаблона roleOverrideValues NF. Хотя оператор может напрямую управлять шаблоном NF, лучше параметризовать roleOverrideValues, чтобы значения можно было передавать через шаблон CGV во время выполнения. В следующих примерах показаны необходимые изменения в шаблонах CGS, NF и, наконец, CGV.

Изменения шаблона CGS

Шаблон CGS должен быть обновлен, чтобы включить одно объявление переменной для каждой строки для параметризации под roleOverrideValues. В следующем примере показаны три переопределения значений.

        "roleOverrideValues0": {
          "type": "string"        
        },    
        "roleOverrideValues1": {
          "type": "string"        
        },        
        "roleOverrideValues2": {
          "type": "string"
        }

Изменения шаблона полезной нагрузки NF

Шаблон NF должен быть обновлен тремя способами. Во-первых, неявный параметр конфигурации должен быть определен как объект type. Во-вторых, roleOverrideValues0roleOverrideValues1и roleOverrideValues2 должны быть объявлены как переменные, сопоставленные с параметром конфигурации. Третьи, roleOverrideValues0, roleOverrideValues1 и roleOverrideValues2 должны быть упомянуты для подстановки roleOverrideValues в правильном порядке и с соблюдением правильного синтаксиса.

  "parameters": {
    "config": {
      "type": "object",
      "defaultValue": {}
    }
  }
  "variables": {
    "roleOverrideValues0": "[string(parameters('config').roleOverrideValues1)]",
    "roleOverrideValues1": "[string(parameters('config').roleOverrideValues1)]",
    "roleOverrideValues2": "[string(parameters('config').roleOverrideValues2)]"
  },
  "resources": [
  {
<snip>
     "roleOverrideValues": [
          "[variables('roleOverrideValues0')]",
          "[variables('roleOverrideValues1')]",
          "[variables('roleOverrideValues2')]"
        ]
   }

Изменения шаблона CGV

Теперь шаблон CGV можно обновить, чтобы включить содержимое каждой переменной, которое будет вставлено в свойство roleOverrideValues во время выполнения программы. В следующем примере устанавливается значение rollbackEnabled в true, а затем переопределяются значения для hellotest и hellotest1 в nfApplications.

{
    "roleOverrideValues0": "{\"nfConfiguration\":{\"rollbackEnabled\":true}}",
    "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\"}}"
}

С помощью этой платформы оператор может управлять любой из roleOverrideValues, выполняя простые обновления CGV, после чего следует присоединение этого CGV к требуемой операции SNS.

Пропустить nfApps, в которых нет изменений

Эта skipUpgrade функция предназначена для оптимизации времени обновления CNF. Если издатель включает этот флаг в roleOverrideValues разделе upgradeOptions, уровень службы AOSM выполняет определенные предварительные проверки, чтобы определить, можно ли пропустить обновление для определенного объекта nfApplication . Если выполнены все условия предварительной проверки, обновление пропускается для этого приложения. В противном случае обновление выполняется на уровне кластера.

Критерии предварительной проверки

Обновление можно пропустить, если выполнены все следующие условия:

  • Состояние nfApplication подготовки выполнено успешно.
  • Нет изменений в имени или версии диаграммы Helm.
  • Нет изменений в значениях Helm.

Включение или отключение функции skipUpgrade

Эта skipUpgrade функция отключена по умолчанию. Если этот необязательный параметр не указан в roleOverrideValues разделе upgradeOptions, обновления CNF выполняются в традиционном режиме, где nfApplications обновляются на уровне кластера.

Включение SkipUpgrade в ресурсе сетевой функции

Чтобы включить функцию SkipUpgrade, см. следующий пример roleOverrideValues.

{
    "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\"}}}}}"
        ]
    }
}

Объяснение примера

  • nfApplication: hellotest
    • Флаг skipUpgrade включен. Если запрос на обновление соответствует hellotest критериям предварительной проверки, обновление не выполняется.
  • nfApplication: runnerTest
    • Флаг skipUpgrade не указан. Поэтому runnerTest выполняет традиционное обновление Helm на уровне кластера, даже если выполнены критерии предварительной проверки.

Полный справочник по параметру roleOverrideValues

Объединяя все примеры в этой и других статьях, следующая ссылка демонстрирует все поддерживаемые в настоящее время варианты, доступные через механизм roleOverrideValues.

{
  "roleOverrideValues": [
    {
      "nfConfiguration": {
        "rollbackEnabled": "true"
      }
    },
    {
      "name": "nfApplication1",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "skipUpgrade": "true",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            }
          }
        }
      }
    },
    {
      "name": "nfApplication2",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "skipUpgrade": "true",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            }
          }
        }
      }
    }
  ]
}
  • Last updated on