Share via

Procedimientos recomendados de Azure Operator Service Manager para incorporar e implementar funciones de red

  • Artículo

Microsoft ha desarrollado muchas prácticas probadas para administrar funciones de red (FN) mediante Azure Operator Service Manager. En este artículo se proporcionan instrucciones que los proveedores de NF, los operadores de telecomunicaciones y sus asociados pueden seguir para optimizar el diseño. Tenga en cuenta estos procedimientos al incorporar e implementar las NFs.

Consideraciones generales

Se recomienda incorporar e implementar primero las FN más sencillas (uno o dos gráficos) mediante los inicios rápidos para familiarizarse con el flujo general. Puede agregar los detalles de configuración necesarios en iteraciones posteriores. A medida que pase por los inicios rápidos, tenga en cuenta los siguientes puntos:

  • Estructurar los artefactos para alinearse con el uso planeado. Considere la posibilidad de separar los artefactos globales de los artefactos que desea variar según el sitio o la instancia.
  • Asegúrese de que la composición del servicio de varias NF con un conjunto de parámetros que coincida con las necesidades de la red. Por ejemplo, puede tener un gráfico que tenga 1000 valores y que solo personalice 100 de ellos. Asegúrese de que en la capa Esquema de grupo de configuración (CGS) (que se trata más ampliamente en las secciones siguientes) que solo exponga 100.
  • Piense en lo temprano sobre cómo desea separar la infraestructura (por ejemplo, los clústeres) o los almacenes de artefactos y el acceso entre proveedores, en particular dentro de un único servicio. Haga que el conjunto de recursos del publicador coincida con este modelo.
  • El sitio de Azure Operator Service Manager es un concepto lógico, una representación de un destino de implementación. Algunos ejemplos son un clúster de Kubernetes para las funciones de red en contenedores (CNFs) o una ubicación personalizada extendida del operador de Azure Para las funciones de red virtualizadas (VNFs). No es una representación de un sitio perimetral físico, por lo que tiene casos de uso en los que varios sitios comparten la misma ubicación física.
  • Azure Operator Service Manager proporciona varias API, lo que facilita la combinación con ADO u otras herramientas de canalización.

Consideraciones sobre el publicador

  • Se recomienda crear un único publicador por proveedor NF. Esta práctica proporciona una experiencia óptima de soporte técnico, mantenimiento y gobernanza en todos los proveedores y simplifica el diseño del servicio de red cuando se compone de varios NF de varios proveedores.

  • Después de probar y aprobar el conjunto deseado de recursos y artefactos del publicador de Azure Operator Service Manager para su uso en producción, se recomienda marcar todo el conjunto como inmutable para evitar cambios accidentales y garantizar una experiencia de implementación coherente. Considere la posibilidad de confiar en funcionalidades de inmutabilidad para distinguir entre los recursos y los artefactos usados en producción frente a los que se usan con fines de prueba y desarrollo. Puede consultar el estado de los recursos del publicador y los manifiestos de artefacto para determinar cuáles se marcan como inmutables. Para obtener más información, consulte Inquilinos, suscripciones, regiones y administración de versión preliminar de Publisher.

    Tenga en cuenta la siguiente lógica:

    • Si la función de diseño del servicio de red (NSDV) está marcada como inmutable, CGS también debe marcarse como inmutable. De lo contrario, se produce un error en la llamada de implementación.
    • Si network Function Design Version (NFDV) está marcado como inmutable, el manifiesto del artefacto debe marcarse también como inmutable. De lo contrario, se produce un error en la llamada de implementación.
    • Si solo el manifiesto de artefacto o CGS está marcado como inmutable, la llamada de implementación se realiza correctamente independientemente de si NFDV y NSDV se marcan como inmutables.
    • Marcar un manifiesto de artefacto como inmutable garantiza que todos los artefactos enumerados en ese manifiesto (normalmente, gráficos, imágenes y plantillas de Azure Resource Manager [plantillas de ARM]) se marcan también inmutables mediante la aplicación de permisos necesarios en el almacén de artefactos.

  • Considere la posibilidad de usar convenciones de nomenclatura acordadas y técnicas de gobernanza para ayudar a abordar las brechas restantes.

Consideraciones sobre el grupo y la versión de la función de red

Network Function Definition Group (NFDG) representa el componente más pequeño que planea reutilizar de forma independiente en varios servicios. Todas las partes de un NFDG siempre se implementan juntas. Estas partes se denominan networkFunctionApplications. Por ejemplo, es natural incorporar un único NF compuesto por varios gráficos e imágenes de Helm como un único NFDG si siempre implementa esos componentes juntos. En los casos en los que varias NF siempre se implementan juntas, es razonable tener un único NFDG para todos ellos. Los NFDG únicos pueden tener varios NFDV.

En el caso de las versiones de definición de función de red en contenedor (NFDV de CNF), la networkFunctionApplications lista solo puede contener paquetes de Helm. Es razonable incluir varios paquetes de Helm si siempre se implementan y eliminan juntos.

Para las versiones de definición de funciones de red virtualizadas (NFDV de VNF), la networkFunctionApplications lista debe contener al menos una VhdImageFile y una plantilla de ARM. La plantilla de ARM debe implementar una sola máquina virtual (VM). Para implementar varias máquinas virtuales para un único VNF, asegúrese de usar plantillas de ARM independientes para cada máquina virtual.

La plantilla de ARM solo puede implementar recursos de Resource Manager desde los siguientes proveedores de recursos:

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

Nota:

En el caso de las plantillas de ARM que contienen algo más allá de la lista anterior, todas las llamadas PUT y Re-PUT en el VNF producen un error de validación.

Casos de uso comunes que desencadenan la versión secundaria del diseño de funciones de red o la actualización de la versión principal

  • Actualización de valores de grupo de configuración o CGS (CGV) para una versión existente que desencadena el cambio de deployParametersMappingRuleProfile.
  • Actualización de valores codificados de forma rígida en NFDV.
  • Marcar componentes inactivos para evitar que se implementen a través applicationEnablement: Disabledde .
  • Nueva versión NF, como gráficos e imágenes.

Nota:

Número mínimo de cambios necesarios cada vez que se realiza la carga de un determinado cambio nf. Una versión NF secundaria o principal sin exponer nuevos parámetros CGS solo requiere actualizar el manifiesto del artefacto, insertar nuevas imágenes y gráficos y aumentar la versión NFDV.

Consideraciones sobre el grupo de diseño y la versión del servicio de red

Network Service Design Group (NSDG) es una composición de uno o varios NFDG y cualquier componente de infraestructura (como Nexus Azure Kubernetes Service [NAKS]/Azure Kubernetes Service [AKS] clústeres y máquinas virtuales) implementados al mismo tiempo. Un servicio de red de sitio (SNS) hace referencia a un único NSDV. Este diseño garantiza una implementación coherente y repetible del servicio de red en un sitio determinado desde un único SNS PUT.

Un ejemplo de NSDG es:

  • Función del servidor de autenticación (AUSF) NF
  • NF de Administración de datos unificado (UDM)
  • Administración máquina virtual compatible con AUSF/UDM
  • Función de administración de sesiones de Unity Cloud (UC) (SMF) NF
  • Clúster de NAKS, en el que se implementaN AUSF, UDM y SMF

Estos cinco componentes forman un único NSDG. Un único NSDG puede tener varios NSDVs.

Casos de uso comunes que desencadenan la versión secundaria del diseño del servicio de red o la actualización de la versión principal

  • Crear o eliminar CGS.
  • Cambios en la plantilla de RESOURCE NF asociada a una de las NFs que se implementan.
  • Cambios en la plantilla de ARM de infraestructura, por ejemplo, AKS/NAKS o VM.

Nota:

Los cambios en NFDV no deben desencadenar una actualización de NSDV. El valor NFDV debe exponerse como parámetro dentro del CGS, por lo que los operadores pueden controlar qué implementar mediante CGV.

Consideraciones sobre el esquema del grupo de configuración

Se recomienda empezar siempre con un único CGS para toda la NF. Si hay parámetros específicos del sitio o específicos de una instancia, se recomienda mantenerlos en un único CGS. Se recomienda dividir en varios CGS cuando hay varios componentes (rara vez NFs, más comúnmente, infraestructura) o configuraciones que se comparten entre varios NFs. El número de CGS define el número de CGV.

Escenario

  • FluentD, Kibana y Splunk (componentes comunes de terceros) siempre se implementan para todos los NF dentro de un NSD. Se recomienda agrupar estos componentes en un único NFDG.
  • NSD tiene varias NF que comparten algunas configuraciones (ubicación de implementación, nombre del publicador y algunas configuraciones de gráfico).

En este escenario, se recomienda usar un único CGS global para exponer las configuraciones comunes de componentes NF y de terceros. Puede definir CGS específico de NF según sea necesario.

Elección de parámetros para exponer

  • CGS solo debe tener parámetros usados por NFs (configuración de día 0/N) o componentes compartidos.
  • Los parámetros que rara vez están configurados deben tener definidos valores predeterminados.
  • Si se usan varios CGS, se recomienda poco a no superponerse entre los parámetros. Si se requiere superposición, asegúrese de que los nombres de parámetro se distinguen claramente entre los CGS.
  • Lo que se puede definir a través de api (Azure Operator Nexus, Azure Operator Service Manager) debe tenerse en cuenta para CGS. En lugar de, por ejemplo, definir esos valores de configuración a través de archivos CloudInit.
  • Cuando no está seguro, un buen punto de partida consiste en exponer el parámetro y tener un valor predeterminado razonable especificado en el CGS. En el ejemplo siguiente se muestran los CGS de ejemplo y las cargas de CGV correspondientes.
  • Una única identidad administrada asignada por el usuario debe usarse en todas las plantillas de ARM de NF y debe exponerse a través de CGS.

Carga de CGS:

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

Carga de CGV correspondiente pasada por el operador:

{
"qwe": 20
}

Carga de CGV resultante generada por Azure Operator Service Manager:

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

Consideraciones sobre los valores de grupo de configuración

Antes de enviar la creación de recursos CGV, puede validar que el esquema y los valores del archivo YAML o JSON subyacente coincidan con lo que espera el CGS correspondiente. Para ello, una opción es usar la extensión YAML para Visual Studio Code.

Consideraciones de la CLI

La extensión de la CLI de Service Manager del operador de Azure ayuda con la publicación de NFDs y NSD. Use esta herramienta como punto de partida para crear nuevos NFD y NSD. Considere la posibilidad de usar la CLI para crear los archivos iniciales. Después, edítelos para incorporar componentes de infraestructura antes de publicarlos.

Consideraciones sobre el servicio de red del sitio

Se recomienda tener un único SNS para todo el sitio, incluida la infraestructura. El SNS debe implementar cualquier infraestructura necesaria (por ejemplo, clústeres de NAKS/AKS y máquinas virtuales) y, a continuación, implementar las NFs necesarias en la parte superior. Este diseño garantiza una implementación coherente y repetible del servicio de red en un sitio determinado desde un único SNS PUT.

Se recomienda implementar cada SNS con una identidad administrada asignada por el usuario en lugar de una identidad administrada asignada por el sistema. Esta identidad administrada asignada por el usuario debe tener permisos para acceder a NFDV y debe tener el rol de Operador de identidad administrada en sí mismo. Para obtener más información, consulte Creación y asignación de una identidad administrada asignada por el usuario.

Asignación de recursos de Azure Operator Service Manager por caso de uso

En los dos escenarios siguientes se muestra la asignación de recursos de Azure Operator Service Manager.

Escenario: Función de red única

Un NF con uno o dos componentes de aplicación se implementa en un clúster de NAKS.

Desglose de recursos:

  • NFDG: si los componentes se pueden usar de forma independiente, dos NFDG, uno por componente. Si los componentes siempre se implementan juntos, un único NFDG.
  • NFDV: según sea necesario en función de los casos de uso mencionados en las secciones "Casos de uso comunes" anteriores que desencadenan actualizaciones de versiones secundarias o principales de NFDV.
  • NSDG: único. Combina las NFs y las definiciones de clúster de Kubernetes.
  • NSDV: según sea necesario en función de los casos de uso mencionados en las secciones anteriores de "Casos de uso comunes" que desencadenan actualizaciones secundarias o principales de NSDV.
  • CGS: único. Se recomienda que CGS tenga subsecciones para cada componente e infraestructura que se implemente para facilitar la administración e incluye las versiones de NFD.
  • CGV: único basado en el número de CGS.
  • SNS: único por NSDV.

Escenario: Varias funciones de red

Se implementan varios NF con algunos componentes compartidos e independientes en un clúster de NAKS.

Desglose de recursos:

  • NFDG:
    • NFDG para todos los componentes compartidos.
    • NFDG para cada componente independiente o NF.
  • NFDV: múltiplo por cada NFDG por caso de uso mencionado en las secciones anteriores "Casos de uso comunes" que desencadenan actualizaciones de versiones secundarias o principales de NFDV.
  • NSDG: único. Combina todas las NFs, los componentes compartidos e independientes y la infraestructura (clúster de Kubernetes o cualquier máquina virtual compatible).
  • NSDV: según sea necesario en función de los casos de uso mencionados en las secciones anteriores de "Casos de uso comunes" que desencadenan actualizaciones secundarias o principales de NSDV.
  • CGS:
    • Soltero/a. Global para todos los componentes que tienen valores de configuración compartidos.
    • NF CGS por NF, incluida la versión de NFD.
    • En función del número total de parámetros, considere la posibilidad de combinar todos los CGS en un único CGS.
  • CGV: igual al número de CGS.
  • SNS: único por NSDV.

Consideraciones sobre la actualización de software

Suponiendo que las NFs admiten actualizaciones en contexto o en servicio, para cnfs:

  • Si se agregan nuevos gráficos e imágenes, Azure Operator Service Manager instala los nuevos gráficos.
  • Si se quitan algunos gráficos e imágenes, Azure Operator Service Manager elimina los gráficos que ya no se declaran en NFDV.
  • Azure Operator Service Manager valida que NFDV/NSDV se originó en el mismo NFDG/NSDG y, por tanto, el mismo publicador. No se admiten las actualizaciones entre publicadores.

Para las VNF:

  • Actualmente no se admiten las actualizaciones en contexto. Debe crear una instancia de un nuevo VNF con una imagen actualizada en paralelo. A continuación, elimine el VNF anterior mediante la eliminación del SNS.
  • Si VNF se implementa como un par de máquinas virtuales para alta disponibilidad, puede diseñar el servicio de red de forma que pueda eliminar y actualizar máquinas virtuales de una por una. Se recomienda el siguiente diseño para permitir la eliminación y actualización de máquinas virtuales individuales:
    • Cada máquina virtual se implementa mediante una plantilla de ARM dedicada.
    • En la plantilla de ARM, se deben exponer dos parámetros a través de CGS: nombre de máquina virtual, para permitir indicar qué instancia es principal o secundaria, y la directiva de implementación, controlando si se permite o no la implementación de la máquina virtual.
    • En NFDV y deployParameterstemplateParameters deben parametrizarse de tal manera que pueda proporcionar los valores únicos mediante CGV para cada uno.

Consideraciones acerca de la alta disponibilidad y la recuperación ante desastres

Azure Operator Service Manager es un servicio regional implementado en zonas de disponibilidad en regiones que los admiten. Para todas las regiones en las que Azure Operator Service Manager está disponible, consulte Productos de Azure por región. Para obtener la lista de regiones de Azure que tienen zonas de disponibilidad, consulte Elección de la región de Azure adecuada.

Tenga en cuenta los siguientes requisitos de alta disponibilidad y recuperación ante desastres:

  • Para proporcionar redundancia geográfica, asegúrese de que tiene un publicador en cada región donde planea implementar NFs. Considere la posibilidad de usar canalizaciones para asegurarse de que los artefactos y recursos del publicador se mantienen sincronizados entre las regiones.
  • El nombre del publicador debe ser único por región por inquilino de Microsoft Entra.

Nota:

Si una región deja de estar disponible, puede implementar (pero no actualizar) un NF mediante recursos de publicador en otra región. Suponiendo que los artefactos y los recursos son idénticos entre los publicadores, solo es necesario cambiar el networkServiceDesignVersionOfferingLocation valor de la carga del 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

Consideraciones de solución de problemas

Durante la instalación y actualización de forma predeterminada, las opciones atómicas y de espera se establecen en truey el tiempo de espera de la operación se establece en 27 minutes. Durante la incorporación, se recomienda establecer la marca atómica para false evitar la reversión de Helm tras un error. La manera óptima de lograr esto es en la plantilla de ARM de NF.

En la plantilla de ARM, agregue la siguiente sección:

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

El nombre del componente se define en NFDV:

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

Consideraciones de limpieza

Elimine los recursos del operador en el siguiente orden para asegurarse de que no quedan recursos huérfanos:

  • SNS
  • Sitio
  • CGV

Importante

Asegúrese de que SNS se elimina antes de eliminar nfDV.

Elimine los recursos del publicador en el siguiente orden para asegurarse de que no quedan recursos huérfanos:

  • CGS
  • NSDV
  • NSDG
  • NFDV
  • NFDG
  • Manifiesto de artefacto
  • Almacenamiento de artefactos
  • Publicador

Pasos siguientes