Partilhar via

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

  • Artigo

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

Nota

Para modelos ARM contendo algo além da lista anterior, todas as chamadas PUT e Re-PUT no VNF resultam em um erro de validação.

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.

Nota

Número mínimo de alterações necessárias sempre que a carga útil de um determinado novo alimento seja alterada. Uma versão menor ou maior de NF sem expor novos parâmetros CGS requer apenas a atualização do manifesto do artefato, o envio de novas imagens e gráficos e o aumento da versão NFDV.

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.

Nota

As alterações no NFDV não devem desencadear uma atualização do NSDV. O valor NFDV deve ser exposto como um parâmetro dentro do CGS, para que os operadores possam controlar o que implantar usando CGVs.

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.

Nota

Se uma região ficar indisponível, você poderá implantar (mas não atualizar) uma NF usando recursos do editor em outra região. Supondo que os artefatos e recursos sejam idênticos entre os editores, você só precisa alterar o networkServiceDesignVersionOfferingLocation valor na carga útil do recurso SNS.

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, recomendamos que você defina o sinalizador atômico para false evitar a reversão do Helm em caso de falha. 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

Exclua os recursos do operador na seguinte ordem para garantir que nenhum recurso órfão seja deixado para trás:

  • SNS
  • Site
  • CGV

Importante

Certifique-se de que o SNS é eliminado antes de eliminar o NFDV.

Exclua os recursos do editor na seguinte ordem para garantir que nenhum recurso órfão seja deixado para trás:

  • CGS
  • NSDV
  • NSDG
  • NFDV
  • NFDG
  • Manifesto de Artefactos
  • Armazém de Artefactos
  • Publisher

Considerações se sua NF executa o cert-manager

Importante

Estas orientações aplicam-se apenas a determinadas versões. Verifique a sua versão para o comportamento adequado.

Da versão 1.0.2728-50 à versão 2.0.2777-132, o AOSM usa o cert-manager para armazenar e girar certificados. Como parte dessa alteração, o AOSM implanta um operador cert-manager e CRDs associados no namespace azurehybridnetwork. Como ter vários operadores cert-manager, mesmo implantados em namespaces separados, observará todos os namespaces, apenas um cert-manager pode ser executado efetivamente no cluster.

Qualquer usuário que tente instalar o cert-manager no cluster, como parte de uma implantação de carga de trabalho, obterá uma falha de implantação com um erro de que o CRD "existe e não pode ser importado para a versão atual". Para evitar esse erro, a recomendação é ignorar a instalação do cert-manager, em vez disso, dependa do operador do cert-manager e do CRD já instalado pelo AOSM.

Outras alterações de configuração a serem consideradas

Além de desativar o NfApp associado ao antigo usuário cert-manager, descobrimos que outras alterações podem ser necessárias;

  1. Se um NfApp contiver o cert-manager e a instalação da autoridade de certificação, eles deverão ser divididos em dois NfApps, para que o parceiro possa desabilitar o cert-manager, mas habilitar a instalação da autoridade de certificação.
  2. Se quaisquer outros NfApps tiverem referências DependsOn ao antigo usuário cert-manager NfApp, elas precisarão ser removidas.
  3. Se qualquer outro NfApps fizer referência ao antigo valor do namespace cert-manager do usuário, isso precisará ser alterado para o novo valor do namespace azurehybridnetwork.

Compatibilidade de versões do Cert-Manager & Management

Para o operador cert-manager, nossa versão atual implantada é 1.14.5. Os usuários devem testar a compatibilidade com esta versão. As futuras atualizações do operador do gestor de certificados serão suportadas através do processo de atualização da extensão NFO.

Para os recursos CRD, nossa versão implantada atual é 1.14.5. Os usuários devem testar a compatibilidade com esta versão. Como o gerenciamento de um CRD de cluster comum é algo normalmente tratado por um administrador de cluster, estamos trabalhando para habilitar atualizações de recursos CRD por meio do processo padrão de complementos do Nexus.