Conceitos básicos para o Gerenciador de Serviços de Operador do Azure

Este artigo captura recomendações de práticas recomendadas para integrar e implantar NFs (funções de rede) com o Gerenciador de Serviços de Operador do Azure. Seguindo essas diretrizes básicas, fornecedores, operadores e seus parceiros podem otimizar os serviços de rede implantados no Nexus do Operador do Azure. Considere esses conceitos no início de qualquer processo de planejamento de integração de função de rede.

Considerações gerais

Recomendamos que você, primeiro, integre e implante suas NFs mais simples (um ou dois gráficos) usando os guias de início rápido para se familiarizar com o fluxo geral. Você poderá adicionar os detalhes de configuração necessários em iterações subsequentes. Ao percorrer os guias de início rápido, leve em conta os seguintes pontos:

• Estruture seus artefatos para alinhá-los ao uso planejado. Considere separar os artefatos globais daqueles que você deseja variar por site ou instância.
• Garanta uma composição de serviço de várias NFs com um conjunto de parâmetros que corresponda às necessidades da rede. Por exemplo, você pode personalizar 100 valores em um gráfico que contém 1.000 valores. Certifique-se de que, na camada do esquema do grupo de configuração (CGS) — abordada com mais detalhes nas seções seguintes, — apenas 100 sejam expostos.
• Decida logo no início como você quer separar a infraestrutura (por exemplo, os clusters) ou os repositórios de artefatos do acesso entre fornecedores, em particular dentro de um único serviço. Faça com que seu conjunto de recursos de distribuidor 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 incluem um cluster do Kubernetes para funções de rede conteinerizadas (CNFs) ou uma localização personalizada estendida do Azure Operator Nexus para funções de rede virtualizadas (VNFs). Não se trata de 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 oferece várias APIs que ajudam a combiná-lo com o Azure DevOps ou outras ferramentas de pipeline.
• A extensão da interface de linha de comando (CLI) do Azure Operator Service Manager auxilia na publicação das definições de função de rede (NFDs) e dos NSDs. Use essa ferramenta como ponto de partida para criar novos NFDs e NSDs. Pense em usar a CLI para criar os arquivos iniciais. Em seguida, edite-os para incorporar componentes de infraestrutura antes de publicar.

Considerações para o fornecedor

• Recomendamos que você crie um único fornecedor por fornecedor NF ou por tipo de NF por fornecedor NF, em que o fornecedor NF pode fornecer mais de um tipo de NF. Essa prática;
  • Fornece o suporte, a manutenção e a experiência de governança mais ideais, impedindo a proliferação de editores. Especialmente durante as atividades de atualização em que a mesma ação geralmente é executada em muitos NFs.
  • Reduz os custos operacionais totais reduzindo o número de recursos de suporte do editor, como o Registro de Contêiner do Azure (ACR) ou contas de armazenamento.
  • Isso simplifica o design do serviço de rede (NSD), que pode incluir várias NFs de diferentes fornecedores.
• Após testar e aprovar o conjunto desejado de recursos de fornecedor do Azure Operator Service Manager para uso em produção, recomendamos marcar todo o conjunto como imutável. Marcar o conjunto como imutável ajuda a evitar alterações acidentais e garante uma experiência de implantação consistente. As marcações de imutabilidade ajudam a distinguir entre:
  • Recursos e artefatos usados em produção
  • Recursos e artefatos usados para teste e desenvolvimento

Você pode consultar o estado dos recursos do distribuidor e os manifestos do artefato para determinar quais estão marcados como imutáveis. Para mais informações, confira Recurso de gerenciamento de Visualização do Fornecedor.

Tenha em mente a seguinte lógica:

• Se a versão do design do serviço de rede (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 da definição da função de rede (NFDV) estiver marcada como imutável, o manifesto de artefato também deverá ser marcado como imutável. Caso contrário, a chamada de implantação falhará.
• Se apenas o manifesto de artefato ou o CGS estiver marcado como imutável, a chamada de implantação será bem-sucedida independentemente de o NFDV e o NSDV estarem marcados como imutáveis.
• Marcar um manifesto de artefato como imutável garante que todos os artefatos listados nesse manifesto também sejam marcados como imutáveis, aplicando as permissões necessárias no repositório de artefatos. Os artefatos listados normalmente incluem gráficos, imagens e modelos do Azure Resource Manager (modelos do ARM).
• Pense em usar as convenções de nomenclatura aceitas de comum acordo e as técnicas de governança para ajudar a abordar quaisquer lacunas restantes.

Alta disponibilidade e recuperação de desastre do fornecedor

O editor do Gerenciador de Serviços de Operador do Azure é um serviço regional implantado apenas em zonas de disponibilidade locais em regiões com suporte. Considere os seguintes requisitos para alta disponibilidade e recuperação de desastre do publicador.

• Para fornecer redundância geográfica, verifique se você tem um distribuidor em cada uma das regiões em que estiver planejando implantar NFs. Considere usar pipelines para manter os artefatos e recursos do fornecedor em sincronia entre as regiões.
• O nome do fornecedor deve ser exclusivo para cada locatário do Microsoft Entra em cada região.

Considerações sobre NFDG e NFDV

O grupo de definição da função de rede (NFDG) representa o menor componente que você planeja reutilizar de forma independente em vários serviços. Todas as partes de um NFDG são sempre implantadas juntas. Essas partes são chamadas de itens networkFunctionApplications. Por exemplo, é natural integrar uma única NF composta por vários pacotes Helm e imagens como um único NFDG, se você sempre implantar esses componentes juntos. Nos casos em que várias NFs são sempre implantadas juntas, é razoável ter um único NFDG para todas elas. Um único NFDG pode ter várias NFDVs.

• Para NFDVs de CNF, a lista networkFunctionApplications pode conter apenas pacotes Helm.
  • É razoável incluir vários pacotes Helm se eles sempre forem implantados e excluídos juntos.
• Para NFDVs de VNF, a lista networkFunctionApplications deve conter pelo menos um valor VhdImageFile e um modelo do ARM.
  • Para implantar várias VMs (máquinas virtuais) para uma única VNF, use um modelo separado do ARM para cada VM.

O modelo do ARM pode implantar apenas recursos do Resource Manager dos seguintes provedores de recursos:

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

Para modelos do ARM que contenham qualquer elemento além da lista anterior, todas as chamadas PUT na VNF resultarão em erro de validação.

Atualizações secundárias ou principais do NFDV

O NFDV representa uma versão do NFDG base e está associado a uma versão exclusiva. À medida que a NF altera ao longo do tempo, muitos NFDVs são usados para capturar capacidades, em um dado momento. Alterações típicas que disparam um novo NFDV podem incluir:

• Atualizando artefatos NF, como novos gráficos ou versões de imagem.
• Atualizando CGSs ou CGVs (valores de grupo de configuração) que alteram deployParametersMappingRuleProfile.
• Atualizando os valores padrão embutidos em código no NFDV.
• Atualizando a habilitação dos componentes para evitar sua implantação por meio de applicationEnablement: Disabled.

Considerações sobre NSDG e NSDV

Um grupo de design de serviço de rede (NSDG) é uma composição de um ou mais NFDGs e de quaisquer componentes de infraestrutura implantados ao mesmo tempo. Esses componentes podem incluir clusters e VMs no Nexus Kubernetes ou no Serviço de Kubernetes do Azure (AKS). Um serviço de rede de site (SNS) se refere a uma única NSDV. Esse design oferece uma implantação consistente e reproduzível do serviço de rede em um site a partir de uma única chamada SNS PUT.

Um exemplo de NSDG pode incluir:

• NF Função de Servidor de Autenticação (AUSF)
• NF de gerenciamento unificado de dados (UDM)
• VM de administração que dá suporte a AUSF ou UDM
• NF de função de gerenciamento de sessão Unity Cloud (SMF)
• Cluster do Nexus Kubernetes no qual AUSF, UDM e SMF são implantados

Esses cinco componentes formam um único NSDG. Um único NSDG pode ter várias NSDVs.

Atualização menor ou maior do NSDV

O NSDV representa uma versão do NSD base e está associado a uma versão exclusiva. As alterações de NSDV são menos frequentes do que as alterações de NFDV e, em alguns casos, um único NSDV dá suporte a todo o ciclo de vida de um serviço de rede de site. No entanto, as seguintes alterações de serviço exigem um novo NSDV:

• Criando, excluindo ou adicionando valores em CGSs.
• Alterando o modelo ARM NF usado por um recurso de serviço de rede implantado no site.
• Alterando o modelo do ARM de infraestrutura usado por um recurso de site de implantação.

Considerações sobre o SNS

Recomendamos que você tenha um único SNS para todo o site, incluindo a infraestrutura. O SNS deve implantar toda a infraestrutura necessária (por exemplo, clusters e VMs no Nexus Kubernetes ou AKS) e, em seguida, implantar as NFs exigidas sobre ela. Esse design oferece uma implantação consistente e reproduzível do serviço de rede em um site a partir de uma única chamada SNS PUT.

Recomendamos implantar cada SNS 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 a função de Operador de Identidade Gerenciada em si mesma. Para obter mais informações, confira Criar e atribuir uma identidade gerenciada atribuída pelo usuário.

Considerações sobre o esquema de recursos

Os dois cenários a seguir ilustram o mapeamento de recursos do Gerenciador de Serviços do Operador do Azure.

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

Uma NF com um ou dois componentes de aplicativo é implantada em um cluster Nexus Kubernetes. Veja o detalhamento dos recursos:

• NFDG: Se os componentes puderem ser usados de forma independente, dois NFDG com um por componente. Se os componentes forem sempre implantados juntos, então use um único NFDG.
• NFDV: conforme necessário, com base nos casos de uso que disparam atualizações de versão secundária ou principal do NFDV.
• NSDG: único. Combina as definições de NFs e de cluster do Kubernetes.
• NSDV: conforme necessário, com base nos casos de uso que disparam atualizações de versão secundária ou principal do NSDV.
• CGS: único. Para facilitar o gerenciamento, recomendamos que o CGS tenha subseções para cada componente e infraestrutura que você estiver implantando. Também recomendamos que o CGS inclua as versões dos NFDs.
• CGV: único com base no número de CGSs.
• SNS: um único por NSDV.

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

Várias NFs com alguns componentes compartilhados e outros independentes são implantadas em um cluster Nexus Kubernetes. Veja o detalhamento dos recursos:

• NFDG:
  • Simples para todos os componentes compartilhados.
  • Simples para cada componente ou NF independente.
• NFDV: múltiplos para cada NFDG, conforme o caso de uso que acione atualizações de versão secundária ou principal do NFDV.
• NSDG: único. Combina todas as NFs, componentes compartilhados e independentes e infraestrutura (cluster do Kubernetes ou quaisquer VMs de apoio).
• NSDV: conforme necessário, com base nos casos de uso que disparam atualizações de versão secundária ou principal do NSDV.
• CGS:
  • Único. Global para todos os componentes.
  • Simples por NF, incluindo a versão do NFD.
  • Dependendo do número total de parâmetros, pense em combinar todos os CGSs em um único CGS.
• CGV: igual ao número de CGSs.
• SNS: um único por NSDV.

Considerações sobre atualização

Supondo que as NFs ofereçam suporte a atualizações no local e em serviço, aplicam-se as seguintes considerações para CNFs:

• Se você adicionar novos gráficos e imagens, o Azure Operator Service Manager instala os novos gráficos.
• Se você remover alguns gráficos e imagens, o Azure Operator Service Manager excluirá os gráficos que não estão mais declarados no NFDV.
• O Gerenciador de Serviços do Operador do Azure valida que a NFDV/NSDV se originou do mesmo NFDG/NSDG e, portanto, do mesmo distribuidor. Não há suporte para upgrades multidistribuidor.

As seguintes considerações se aplicam a VNFs:

• Atualmente, não há suporte para upgrades in-loco. Você precisa criar uma instância de uma nova VNF com uma imagem atualizada lado a lado. Em seguida, exclua a VNF antiga excluindo o SNS.
• Se uma VNF for implantada como um par de VMs para alta disponibilidade, é possível projetar o serviço de rede de modo que as VMs possam ser excluídas e atualizadas uma por vez. Recomendamos o design a seguir para permitir a exclusão e o upgrade de VMs individuais:
  • Implantar cada VM usando um modelo do ARM dedicado.
  • No modelo do ARM, é preciso expor dois parâmetros por meio do CGS:
    • Nome da VM, para indicar qual instância é primária ou secundária
    • Política de implantação, para controlar se a implantação da VM é permitida ou não
  • No NFDV, é preciso parametrizar deployParameters e templateParameters de modo que seja possível fornecer valores exclusivos usando CGVs para cada um.

Considerações sobre solução de problemas

Durante a instalação e atualização, por padrão:

• As opções atomic e wait são definidas como true.
• O tempo limite da operação é definido como 27 minutes.

Durante a integração inicial, apenas enquanto você ainda estiver depurando e desenvolvendo artefatos, recomendamos definir o sinalizador atomic como false. Essa configuração evita uma reversão do Helm em caso de falha e mantém quaisquer logs ou erros que poderiam ser perdidos. A melhor forma de fazer isso é no modelo do ARM da NF. No modelo do ARM, adicione a seguinte seção:

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

O nome do componente é definido na NFDV:

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

Considerações de limpeza

Ao limpar os recursos, a ordem é importante. Excluir recursos fora de ordem pode resultar em recursos órfãos deixados para trás.

Recursos do operador

Como primeira etapa na limpeza de um ambiente implantado, excluir os recursos do operador na seguinte ordem:

1. SNS
2. Sítio
3. CGV

Você só poderá prosseguir para excluir outros recursos do ambiente, como o cluster Nexus Kubernetes, depois de excluir com sucesso esses recursos do operador.

Recursos do fornecedor

Como primeira etapa para limpar um ambiente incorporado, exclua os recursos do fornecedor na seguinte ordem:

1. NSDV
2. NSDG
3. NFDV
4. NFDG
5. Manifesto do artefato
6. Repositório de artefatos
7. Publicador

O Gerenciador de Serviços de Operador do Azure não exclui namespaces como parte de qualquer operação de exclusão. Assim, depois que todos os recursos forem excluídos, alguns artefatos poderão permanecer no cluster. Para remover quaisquer artefatos restantes, exclua os namespaces de carga de trabalho criados no cluster. Incluir a operação de exclusão de namespace como parte do pipeline de fluxo de trabalho é uma recomendação para automatizar a ação.

Considerações sobre limites globais do Azure

O Azure impõe determinados limites e restrições de serviço globais em todos os serviços do Azure. Veja a seguir uma lista selecionada desses limites que devem ser considerados ao integrar, projetar ou operar cargas de trabalho usando o Gerenciador de Serviços do Operador do Azure.

Limites de modelo do ARM

Esses limites se aplicariam a modelos do ARM renderizados usados com o Gerenciador de Serviços de Operador do Azure.

Limites do Azure RBAC

Esses limites se aplicariam à assinatura de destino usada para a implantação do Azure Operator Service Manager.

Geralmente, o AOSM requer 8 vezes mais operações simultâneas do SNS em uma assinatura de destino.

Outros limites

Esses limites foram observados em certos casos de uso do mundo real.

Para obter uma lista abrangente, consulte o seguinte artigo: assinatura do Azure e limites de serviço, cotas e restrições.