Práticas recomendadas do Azure Operator Service Manager para integrar e implantar funções de rede

A Microsoft desenvolveu muitas práticas comprovadas para gerenciar funções de rede (NFs) usando o Azure Operator Service Manager. Este artigo fornece diretrizes que os fornecedores de NF, operadores de telecomunicações e seus parceiros podem seguir para otimizar o design. Tenha essas práticas em mente ao integrar e implantar suas NFs.

Considerações gerais

Recomendamos que você primeiro integre e implante seus NFs mais simples (um ou dois gráficos) usando os inícios rápidos para se familiarizar com o fluxo geral. Você pode adicionar os detalhes de configuração necessários em iterações subsequentes. Ao passar pelos inícios rápidos, considere os seguintes pontos:

• Estruture seus artefatos para alinhá-los com o uso planejado. Considere separar artefatos globais dos artefatos que você deseja variar por local ou instância.
• Garanta a composição do serviço de várias NFs com um conjunto de parâmetros que corresponda às necessidades da sua rede. Por exemplo, você pode ter um gráfico com 1.000 valores e personalizar apenas 100 deles. Certifique-se de que, na camada CGS (Configuration Group Schema) (abordada mais extensivamente nas seções a seguir), você exponha apenas 100.
• Pense desde cedo em como você deseja separar a infraestrutura (por exemplo, clusters) ou lojas de artefatos e o acesso entre fornecedores, em particular dentro de um único serviço. Faça com que seu conjunto de recursos do editor corresponda a esse modelo.
• O site do Azure Operator Service Manager é um conceito lógico, uma representação de um destino de implantação. Exemplos são um cluster Kubernetes para CNFs (Funções de Rede Conteinerizadas) ou um local personalizado estendido do Azure Operator Nexus para Funções de Rede Virtualizadas (VNFs). Ele não é uma representação de um site de borda físico, portanto, você tem casos de uso em que vários sites compartilham o mesmo local físico.
• O Azure Operator Service Manager fornece várias APIs, simplificando a combinação com o ADO ou outras ferramentas de pipeline.

Considerações do editor

• Recomendamos que você crie um único editor por fornecedor de NF. Essa prática fornece suporte ideal, manutenção e experiência de governança em todos os fornecedores e simplifica seu projeto de serviço de rede quando composto por vários NFs de vários fornecedores.

• Depois que o conjunto desejado de recursos e artefatos do editor do Azure Operator Service Manager for testado e aprovado para uso em produção, recomendamos marcar todo o conjunto como imutável para evitar alterações acidentais e garantir uma experiência de implantação consistente. Considere confiar em recursos de imutabilidade para distinguir entre recursos e artefatos usados na produção e aqueles usados para fins de teste e desenvolvimento. Você pode consultar o estado dos recursos do editor e os manifestos do artefato para determinar quais são marcados como imutáveis. Para obter mais informações, consulte Locatários do Publisher, assinaturas, regiões e gerenciamento de visualização.

  Tenha em mente a seguinte lógica:

  • Se a Network Service Design Version (NSDV) estiver marcada como imutável, o CGS também deverá ser marcado como imutável. Caso contrário, a chamada de implantação falhará.
  • Se a Versão de Design de Função de Rede (NFDV) estiver marcada como imutável, o manifesto do artefato também deverá ser marcado como imutável. Caso contrário, a chamada de implantação falhará.
  • Se apenas o manifesto do artefato ou o CGS estiver marcado como imutável, a chamada de implantação será bem-sucedida, independentemente de NFDV e NSDV estarem marcados como imutáveis.
  • Marcar um manifesto de artefato como imutável garante que todos os artefatos listados nesse manifesto (normalmente, gráficos, imagens e modelos do Azure Resource Manager [modelos ARM]) também sejam marcados como imutáveis impondo as permissões necessárias no repositório de artefatos.

• Considere o uso de convenções de nomenclatura acordadas e técnicas de governança para ajudar a resolver quaisquer lacunas remanescentes.

Considerações sobre Grupo de Definição de Função de Rede e Versão

O Grupo de Definição de Função de Rede (NFDG) representa o menor componente que você planeja reutilizar independentemente em vários serviços. Todas as partes de um NFDG são sempre implantadas juntas. Essas partes são chamadas de networkFunctionApplications. Por exemplo, é natural integrar um único NF composto por vários gráficos e imagens Helm como um único NFDG se você sempre implantar esses componentes juntos. Nos casos em que vários NFs são sempre implantados juntos, é razoável ter um único NFDG para todos eles. Um único NFDG pode ter vários NFDVs.

Para Containerized Network Function Definition Versions (CNF NFDVs), a networkFunctionApplications lista só pode conter pacotes helm. É razoável incluir vários pacotes de leme se eles forem sempre implantados e excluídos juntos.

Para Virtualized Network Function Definition Versions (VNF NFDVs), a networkFunctionApplications lista deve conter pelo menos um VhdImageFile modelo ARM e um. O modelo ARM deve implantar uma única máquina virtual (VM). Para implantar várias VMs para uma única VNF, certifique-se de usar modelos ARM separados para cada VM.

O modelo ARM só pode implantar recursos do Gerenciador de Recursos dos seguintes provedores de recursos:

• Microsoft.Compute
• Microsoft.Network
• Microsoft.NetworkCloud
• Microsoft.Storage
• Microsoft.NetworkFabric
• Microsoft.Authorization
• Microsoft.ManagedIdentity

Casos de uso comuns que acionam a atualização da versão secundária ou principal da Versão de Design de Função de Rede

• Atualização de CGS/Valores de Grupo de Configuração (CGVs) para uma versão existente que aciona a alteração do deployParametersMappingRuleProfile.
• Atualização de valores codificados no NFDV.
• Marcação de componentes inativos para impedir que sejam implantados via applicationEnablement: Disabled.
• Nova versão NF, como gráficos e imagens.

Considerações sobre Grupo de Design de Serviço de Rede e Versão

O NSDG (Network Service Design Group) é composto por um ou mais NFDGs e quaisquer componentes de infraestrutura (como clusters e máquinas virtuais do Serviço Kubernetes do Azure Nexus [NAKS]/Serviço Kubernetes do Azure [AKS]) implantados ao mesmo tempo. Um serviço de rede de site (SNS) refere-se a um único NSDV. Tal conceção garante a implantação consistente e repetível do serviço de rede para um determinado local a partir de um único SNS PUT.

Um exemplo de um NSDG é:

• Função de servidor de autenticação (AUSF) NF
• NF de Gerenciamento Unificado de Dados (UDM)
• Admin VM com suporte para AUSF/UDM
• Função de gerenciamento de sessão (SMF) Unity Cloud (UC) NF
• Cluster NAKS, no qual AUSF, UDM e SMF são implantados

Estes cinco componentes formam um único NSDG. Um único NSDG pode ter vários NSDVs.

Casos de uso comuns que acionam a atualização da versão secundária ou principal da Versão de Design do Serviço de Rede

• Criação ou exclusão de CGSs.
• Alterações no modelo ARM da NF associado a uma das NFs que estão sendo implantadas.
• Alterações no modelo ARM de infraestrutura, por exemplo, AKS/NAKS ou VM.

Considerações sobre o esquema do grupo de configuração

Recomendamos que comece sempre com um único CGS para todo o NF. Se houver parâmetros específicos do site ou da instância, ainda recomendamos que você os mantenha em um único CGS. Recomendamos a divisão em vários CGSs quando houver vários componentes (raramente NFs, mais comumente, infraestrutura) ou configurações compartilhadas entre vários NFs. O número de CGSs define o número de CGVs.

Cenário

• FluentD, Kibana e Splunk (componentes comuns de terceiros) são sempre implantados para todos os NFs dentro de um NSD. Recomendamos agrupar esses componentes em um único NFDG.
• A NSD tem vários NFs que compartilham algumas configurações (local de implantação, nome do editor e algumas configurações de gráfico).

Nesse cenário, recomendamos que você use um único CGS global para expor as configurações comuns de NF e componentes de terceiros. Você pode definir CGS específicos de NF conforme necessário.

Escolha parâmetros para expor

• O CGS só deve ter parâmetros que sejam usados por NFs (configuração do dia 0/N) ou componentes compartilhados.
• Os parâmetros que raramente são configurados devem ter valores padrão definidos.
• Se vários CGSs forem usados, recomendamos pouca ou nenhuma sobreposição entre os parâmetros. Se for necessária sobreposição, certifique-se de que os nomes dos parâmetros são claramente distinguíveis entre os CGSs.
• O que pode ser definido via API (Azure Operator Nexus, Azure Operator Service Manager) deve ser considerado para o CGS. Ao contrário, por exemplo, de definir esses valores de configuração por meio de arquivos CloudInit.
• Quando não tenho certeza, um bom ponto de partida é expor o parâmetro e ter um padrão razoável especificado no CGS. O exemplo a seguir mostra o CGS de exemplo e as cargas úteis CGV correspondentes.
• Uma única identidade gerenciada atribuída pelo usuário deve ser usada em todos os modelos NF ARM e deve ser exposta via CGS.

Carga útil CGS:

{ 
  "type": "object", 
  "properties": { 
    "abc": { 
    "type": "integer", 
    "default": 30
    }, 
    "xyz": { 
    "type": "integer", 
    "default": 40
    },
    "qwe": {
    "type": "integer" //doesn't have defaults
    }
  }
  "required": "qwe"
}

Carga útil CGV correspondente passada pelo operador:

{
"qwe": 20
}

Carga CGV resultante gerada pelo Azure Operator Service Manager:

{
"abc": 30,
"xyz": 40,
"qwe": 20
}

Considerações sobre os valores do grupo de configuração

Antes de enviar a criação do recurso CGV, você pode validar se o esquema e os valores do arquivo YAML ou JSON subjacente correspondem ao que o CGS correspondente espera. Para fazer isso, uma opção é usar a extensão YAML para Visual Studio Code.

Considerações sobre CLI

A extensão CLI do Azure Operator Service Manager ajuda com a publicação de NFDs e NSDs. Use esta ferramenta como ponto de partida para criar novos NFDs e NSDs. Considere usar a CLI para criar os arquivos iniciais. Em seguida, edite-os para incorporar componentes de infraestrutura antes de publicar.

Considerações sobre o serviço de rede do site

Recomendamos que tenha um único SNS para todo o site, incluindo a infraestrutura. O SNS deve implantar qualquer infraestrutura necessária (por exemplo, clusters NAKS/AKS e máquinas virtuais) e, em seguida, implantar as NFs necessárias na parte superior. Tal conceção garante a implantação consistente e repetível do serviço de rede para um determinado local a partir de um único SNS PUT.

Recomendamos que cada SNS seja implantado com uma identidade gerenciada atribuída pelo usuário em vez de uma identidade gerenciada atribuída pelo sistema. Essa identidade gerenciada atribuída pelo usuário deve ter permissões para acessar o NFDV e precisa ter a função de Operador de Identidade Gerenciada por si só. Para obter mais informações, consulte Criar e atribuir uma identidade gerenciada atribuída pelo usuário.

Mapeamento de recursos do Azure Operator Service Manager por caso de uso

Os dois cenários a seguir ilustram o mapeamento de recursos do Azure Operator Service Manager.

Cenário: Função de rede única

Um NF com um ou dois componentes de aplicativo é implantado em um cluster NAKS.

Repartição dos recursos:

• NFDG: Se os componentes puderem ser usados independentemente, dois NFDGs, um por componente. Se os componentes são sempre implantados juntos, então um único NFDG.
• NFDV: conforme necessário com base nos casos de uso mencionados nas seções anteriores "Casos de uso comuns" que acionam atualizações de versões secundárias ou principais do NFDV.
• NSDG: Único. Combina as definições de cluster NFs e Kubernetes.
• NSDV: Conforme necessário com base nos casos de uso mencionados nas seções anteriores "Casos de uso comuns" que acionam atualizações de versões secundárias ou principais do NSDV.
• CGS: Solteiro. Recomendamos que o CGS tenha subseções para cada componente e infraestrutura que está sendo implantado para facilitar o gerenciamento e inclua as versões para NFDs.
• CGV: Único com base no número de CGSs.
• SNS: Único por NSDV.

Cenário: Várias funções de rede

Vários NFs com alguns componentes compartilhados e independentes são implantados em um cluster NAKS.

Repartição dos recursos:

• NFDG:
  • NFDG para todos os componentes compartilhados.
  • NFDG para cada componente independente ou NF.
• NFDV: múltiplo por cada NFDG por caso de uso mencionado nas seções anteriores "Casos de uso comuns" que acionam atualizações de versões secundárias ou principais do NFDV.
• NSDG: Único. Combina todos os NFs, componentes compartilhados e independentes e infraestrutura (cluster Kubernetes ou qualquer VM de suporte).
• NSDV: Conforme necessário com base nos casos de uso mencionados nas seções anteriores "Casos de uso comuns" que acionam atualizações de versões secundárias ou principais do NSDV.
• CGS:
  • Solteiro. Global para todos os componentes que têm valores de configuração compartilhados.
  • NF CGS por NF, incluindo a versão do NFD.
  • Dependendo do número total de parâmetros, considere combinar todos os CGSs em um único CGS.
• CGV: Igual ao número de CGSs.
• SNS: Único por NSDV.

Considerações sobre a atualização de software

Supondo que os NFs suportem atualizações in-loco/em serviço, para CNFs:

• Se forem adicionados novos gráficos e imagens, o Azure Operator Service Manager instalará os novos gráficos.
• Se alguns gráficos e imagens forem removidos, o Azure Operator Service Manager excluirá os gráficos que não são mais declarados no NFDV.
• O Azure Operator Service Manager valida que o NFDV/NSDV se originou do mesmo NFDG/NSDG e, portanto, do mesmo editor. Não há suporte para atualizações entre editores.

Para os VNF:

• Atualmente, não há suporte para atualizações in-loco. Você precisa instanciar um novo VNF com uma imagem atualizada lado a lado. Em seguida, exclua o VNF mais antigo excluindo o SNS.
• Se o VNF for implantado como um par de VMs para alta disponibilidade, você poderá projetar o serviço de rede de tal forma que possa excluir e atualizar VMs uma a uma. Recomendamos o design a seguir para permitir a exclusão e a atualização de VMs individuais:
  • Cada VM é implantada usando um modelo ARM dedicado.
  • A partir do modelo ARM, dois parâmetros precisam ser expostos via CGS: nome da VM, para permitir indicar qual instância é primária/secundária, e política de implantação, controlando se a implantação da VM é permitida ou não.
  • No NFDV, deployParameters e templateParameters precisa ser parametrizado de tal forma que você possa fornecer os valores exclusivos usando CGVs para cada um.

Considerações sobre alta disponibilidade e recuperação de desastres

O Azure Operator Service Manager é um serviço regional implantado em zonas de disponibilidade em regiões que oferecem suporte a elas. Para todas as regiões onde o Azure Operator Service Manager está disponível, consulte Produtos do Azure por região. Para obter a lista de regiões do Azure que têm zonas de disponibilidade, consulte Escolher a região do Azure certa para você.

Considere os seguintes requisitos de alta disponibilidade e recuperação de desastres:

• Para fornecer redundância geográfica, certifique-se de ter um editor em todas as regiões onde planeja implantar NFs. Considere o uso de pipelines para garantir que os artefatos e recursos do editor sejam mantidos sincronizados entre as regiões.
• O nome do editor deve ser exclusivo por região por locatário do Microsoft Entra.

resource sns 'Microsoft.HybridNetwork/sitenetworkservices@2023-09-01’ = {
 name: snsName
 location: location
 identity: {
  type: 'SystemAssigned'
 }
 properties: {
   publisherName: publisherName
   publisherScope: 'Private'
   networkServiceDesignGroupName: nsdGroup
   networkServiceDesignVersionName: nsdvName
   networkServiceDesignVersionOfferingLocation: location

Considerações de resolução de problemas

Durante a instalação e a atualização por padrão, as opções atômica e de espera são definidas como true, e o tempo limite da operação é definido como 27 minutes. Durante a integração inicial, somente enquanto você ainda estiver depurando e desenvolvendo artefatos, recomendamos que você defina o sinalizador atômico como false. Isso evita uma reversão de leme em caso de falha e retém quaisquer logs ou erros que, de outra forma, poderiam ser perdidos. A melhor maneira de fazer isso é no modelo ARM do NF.

No modelo ARM, adicione a seguinte seção:

"roleOverrideValues": [
    "{\"name\":\"NF_component_name>\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"false\",\"wait\":\"true\",\"timeout\":\"100\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"4\"}}}}}"
]

O nome do componente é definido no NFDV:

     networkFunctionTemplate: {
      nfviType: 'AzureArcKubernetes'
      networkFunctionApplications: [
        {
          artifactType: 'HelmPackage'
          name: 'fed-crds'
          dependsOnProfile: null
          artifactProfile: {
            artifactStore: {
              id: acrArtifactStore.id
            }

Considerações sobre limpeza

Recursos do Operador

Como primeiro passo para limpar um ambiente implantado, comece excluindo os recursos do operador na seguinte ordem:

• SNS
• Site
• CGV

Somente quando esses recursos do operador forem excluídos com sucesso, um usuário deverá continuar a excluir outros recursos do ambiente, como o cluster NAKS.

Recursos do Publisher

Como primeiro passo para limpar um ambiente integrado, comece excluindo os recursos do editor na seguinte ordem:

• NSDV
• NSDG

• NFDV
• NFDG
• Manifesto de Artefactos
• Armazém de Artefactos
• Publisher

Comportamento de ordenação sequencial NfApp

Descrição geral

Por padrão, os aplicativos de função de rede em contêineres (NfApps) são instalados ou atualizados com base na ordem sequencial em que aparecem na versão de design de função de rede (NFDV). Para exclusão, os NfApps são excluídos na ordem inversa sepcified. Quando um editor precisa definir uma ordem específica de NfApps, diferente do padrão, um dependsOnProfile é usado para definir uma sequência exclusiva para operações de instalação, atualização e exclusão.

Como usar dependsOnProfile

Um editor pode usar dependsOnProfile no NFDV para controlar a sequência de execuções de leme para NfApps. Dado o exemplo a seguir, na operação de instalação o NfApps será implantado na seguinte ordem: dummyApplication1, dummyApplication2 e, em seguida, dummyApplication. Na operação de atualização, o NfApps será atualizado na seguinte ordem: dummyApplication2, dummyApplication1 e, em seguida, dummyApplication. Na operação de exclusão, o NfApps será excluído na seguinte ordem: dummyApplication2, dummyApplication1 e, em seguida, dummyApplication.

{
    "location": "eastus",
    "properties": {
        "networkFunctionTemplate": {
            "networkFunctionApplications": [
                {
                  "dependsOnProfile": {
                        "installDependsOn": [
                            "dummyApplication1",
                            "dummyApplication2"
                        ],
                        "uninstallDependsOn": [
                            "dummyApplication1"
                        ],
                        "updateDependsOn": [
                            "dummyApplication1"
                        ]
                    },
                    "name": "dummyApplication"
                },
                {
                  "dependsOnProfile": {
                        "installDependsOn": [
                        ],
                        "uninstallDependsOn": [
                            "dummyApplication2"
                        ],
                        "updateDependsOn": [
                            "dummyApplication2"
                        ]
                    },
                    "name": "dummyApplication1"
                },
                {
                    "dependsOnProfile": null,
                    "name": "dummyApplication2"
                }
            ],
            "nfviType": "AzureArcKubernetes"
        },
        "networkFunctionType": "ContainerizedNetworkFunction"
    }
}

Erros Comuns

A partir de hoje, se dependsOnProfile fornecido no NFDV for inválido, a operação NF falhará com um erro de validação. A mensagem de erro de validação é mostrada no recurso de status da operação e é semelhante ao exemplo a seguir.

 {
  "id": "/providers/Microsoft.HybridNetwork/locations/EASTUS2EUAP/operationStatuses/ca051ddf-c8bc-4cb2-945c-a292bf7b654b*C9B39996CFCD97AB3A121AE136ED47F67BB13946C573EF90628C47628BC5EF5F",
  "name": "ca051ddf-c8bc-4cb2-945c-a292bf7b654b*C9B39996CFCD97AB3A121AE136ED47F67BB13946C573EF90628C47628BC5EF5F",
  "resourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/xinrui-publisher/providers/Microsoft.HybridNetwork/networkfunctions/testnfDependsOn02",
  "status": "Failed",
  "startTime": "2023-07-17T20:48:01.4792943Z",
  "endTime": "2023-07-17T20:48:10.0191285Z",
  "error": {
    "code": "DependenciesValidationFailed",
    "message": "CyclicDependencies: Circular dependencies detected at hellotest."
  }
}

considerações injectArtifactStoreDetails

Em alguns casos, gráficos de leme de terceiros podem não ser totalmente compatíveis com os requisitos do AOSM para registryURL. Nesse caso, o recurso injectArtifactStoreDetails pode ser usado para evitar fazer alterações nos pacotes de leme.

Como ativar

Para usar injectArtifactStoreDetails, defina o parâmetro installOptions na seção NF resource roleOrverrides como true e, em seguida, use qualquer valor registryURL necessário para manter a URL do Registro válida. Veja o exemplo a seguir do parâmetro injectArtifactStoreDetails habilitado.

resource networkFunction 'Microsoft.HybridNetwork/networkFunctions@2023-09-01' = {
  name: nfName
  location: location
  properties: {
    nfviType: 'AzureArcKubernetes'
    networkFunctionDefinitionVersionResourceReference: {
      id: nfdvId
      idType: 'Open'
    }
    allowSoftwareUpdate: true
    nfviId: nfviId
    deploymentValues: deploymentValues
    configurationType: 'Open'
    roleOverrideValues: [
      // Use inject artifact store details feature on test app 1
      '{"name":"testapp1", "deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"atomic":"false","wait":"false","timeout":"60","injectArtifactStoreDetails":"true"},"upgradeOptions": {"atomic": "false", "wait": "true", "timeout": "100", "injectArtifactStoreDetails": "true"}}}}}'
    ]
  }
}