Compartir a través de

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 (NF) 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 NF.

Consideraciones generales

Se recomienda incorporar e implementar primero las NF 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 consulte los inicios rápidos, tenga en cuenta los siguientes puntos:

  • Estructure 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.
  • Garantice la composición del servicio de varias NF con un conjunto de parámetros que se ajuste a 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 aborda más ampliamente en las siguientes secciones) solo expone 100.
  • Piense desde el principio en 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 Kubernetes para las funciones de red en contenedores (CNF) o una ubicación personalizada extendida de Azure Operator Nexus para las funciones de red virtualizadas (VNF). 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 de 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 varias 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 artefactos para determinar cuáles están marcados como inmutables. Para obtener más información, consulte Inquilinos, suscripciones, regiones y administración de versiones preliminares del publicador.

    Tenga en cuenta la siguiente lógica:

    • Si la versión de diseño del servicio de red (NSDV) está marcada como inmutable, el CGS también debe marcarse como inmutable. De lo contrario, se produce un error en la llamada de implementación.
    • Si la versión del diseño de la función de red (NFDV) está marcada 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 del artefacto o el CGS está marcado como inmutable, la llamada de implementación se realiza correctamente independientemente de si la NFDV y el 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 marquen también como inmutables mediante la aplicación de permisos necesarios en el almacén de artefactos.

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

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

El grupo de definición de funciones de red (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 una única NF compuesta 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 todas ellas. Los NFDG únicos pueden tener varias NFDV.

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

Para las versiones de definición de funciones de red virtualizadas (VNF NFDV), la lista de networkFunctionApplications debe contener al menos un 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 una única 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 contengan algo más que la lista anterior, todas las llamadas PUT y Re-PUT en la 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 del deployParametersMappingRuleProfile.
  • Actualización de valores codificados de forma rígida en la NFDV.
  • Marcar componentes inactivos para evitar que se implementen a través de applicationEnablement: Disabled.
  • Nuevo lanzamiento de NF, como gráficos e imágenes.

Nota:

Número mínimo de cambios necesarios cada vez que cambia la carga útil de una NF determinada. Una versión menor o mayor de una NF sin exponer nuevos parámetros del CGS solo requiere actualizar el manifiesto de artefactos, enviar nuevas imágenes y gráficos, y actualizar la versión de la NFDV.

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

El grupo de diseño del servicio de red (NSDG) es una composición de uno o varios NFDG y cualquier componente de infraestructura (como clústeres y máquinas virtuales de Nexus Azure Kubernetes Service [NAKS] o Azure Kubernetes Service [AKS]) 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:

  • NF del servidor de autenticación (AUSF)
  • NF de administración de datos unificados (UDM)
  • Máquina virtual de administración compatible con AUSF o UDM
  • NF de administración de sesiones de Unity Cloud (UC) (SMF)
  • Clúster de NAKS, en el que están implementados AUSF, UDM y SMF

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

Casos de uso comunes que activan la actualización de versiones menores o mayores del diseño del servicio de red

  • Crear o eliminar CGS.
  • Cambios en la plantilla de ARM de la NF asociada a una de las NF que se están implementando.
  • Cambios en la plantilla de ARM de infraestructura, por ejemplo, AKS o NAKS o VM.

Nota:

Los cambios en la NFDV no deben desencadenar una actualización de NSDV. El valor de la NFDV debe exponerse como parámetro dentro del CGS, para que los operadores puedan controlar qué implementar mediante el 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 haya varios componentes (raramente NF, más comúnmente, infraestructura) o configuraciones que se compartan entre varias NF. El número de CGS define el número de CGV.

Escenario

  • FluentD, Kibana y Splunk (componentes comunes de terceros) siempre se implementan para todas las 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, recomendamos usar un único CGS global para exponer las configuraciones comunes de la NF y de componentes de terceros. Puede definir un CGS específico de NF según sea necesario.

Elección de parámetros para exponer

  • El CGS solo debe tener parámetros usados por las NF (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 que los parámetros se solapen poco o nada. Si es necesario el solapamiento, asegúrese de que los nombres de los parámetros se distinguen claramente entre los CGS.
  • Lo que puede definirse a través de API (Azure Operator Nexus, Azure Operator Service Manager) debe considerarse para el CGS. En lugar de, por ejemplo, definir esos valores de configuración a través de archivos CloudInit.
  • Si no está seguro, un buen punto de partida es exponer el parámetro y especificar un valor predeterminado razonable en el CGS. En el siguiente ejemplo 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 del CGS.

Carga del CGS:

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

Carga del CGV correspondiente pasada por el operador:

{
"qwe": 20
}

Carga del CGV resultante generada por Azure Operator Service Manager:

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

Consideraciones sobre los valores del grupo de configuración

Antes de enviar la creación de recursos del 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 Azure Operator Service Manager ayuda con la publicación de NFD 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 y máquinas virtuales de NAKS o AKS) y, a continuación, implementar las NF 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 la NFDV y debe tener el rol de Operador de identidad administrada en sí misma. 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 siguientes dos escenarios se muestra la asignación de recursos de Azure Operator Service Manager.

Escenario: Función de red única

Una 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 anteriores "Casos de uso comunes" que desencadenan actualizaciones de versiones menores o mayores de la NFDV.
  • NSDG: único. Combina las NF 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 "Casos de uso comunes" que desencadenan actualizaciones de versiones menores o mayores de NSDV.
  • CGS: único. Se recomienda que el CGS tenga subsecciones para cada componente e infraestructura que se esté implementando para facilitar la administración, e incluya las versiones para las NFD.
  • CGV: único basado en el número de CGS.
  • SNS: único por NSDV.

Escenario: Varias funciones de red

Se implementan varias 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últiples por cada NFDG por caso de uso mencionado en las secciones anteriores "Casos de uso comunes" que desencadenan actualizaciones de versiones menores o mayores de la NFDV.
  • NSDG: único. Combina todas las NF, 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 "Casos de uso comunes" que desencadenan actualizaciones de versiones menores o mayores 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 NF admiten actualizaciones en contexto o en servicio, para CNF:

  • 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 la NFDV.
  • Azure Operator Service Manager valida que la NFDV o el NSDV se originó en el mismo NFDG o NSDG y, por tanto, en 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 una nueva VNF con una imagen actualizada en paralelo. A continuación, elimine la VNF anterior mediante la eliminación del SNS.
  • Si la 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 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 del 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 la NFDV, deployParameters y templateParameters deben parametrizarse de tal manera que pueda proporcionar los valores únicos mediante un 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 Elija la región de Azure adecuada para usted.

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 las NF. 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) una NF mediante recursos de publicador en otra región. Suponiendo que los artefactos y los recursos sean idénticos entre los editores, sólo tendrá que cambiar el valor networkServiceDesignVersionOfferingLocation en la carga útil del recurso del 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 la actualización, de manera predeterminada, las opciones atómicas y de espera se establecen en true, y el tiempo de espera de la operación se establece en 27 minutes. Durante la incorporación inicial, solo mientras sigue depurando y desarrollando artefactos, se recomienda establecer la marca de atomic en false. Esto evita una reversión de Helm tras un error y conserva los registros o errores que pueden perderse. La manera óptima de lograr esto es en la plantilla de ARM de una 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 la NFDV:

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

Importante

Asegúrese de que atomic y wait se vuelvan a establecer en true una vez completada la incorporación inicial.

Consideraciones de limpieza

Recursos del operador

Como primer paso para limpiar un entorno implementado, empiece por eliminar los recursos del operador en el orden siguiente:

  • SNS
  • Sitio
  • CGV

Solo una vez eliminados correctamente estos recursos de operador, debe un usuario continuar con la eliminación de otros recursos de entorno, como el clúster de NAKS.

Importante

La eliminación de recursos fuera del orden puede dar lugar a que los recursos huérfanos se quede atrás.

Recursos del publicador

Como primer paso para limpiar un entorno incorporado, empiece por eliminar los recursos del publicador en el orden siguiente:

  • NSDV
  • NSDG

Importante

Asegúrese de que el SNS se elimina antes de eliminar la NFDV.

  • NFDV
  • NFDG
  • Manifiesto de artefacto
  • Almacenamiento de artefactos
  • Publicador

Importante

La eliminación de recursos fuera del orden puede dar lugar a que los recursos huérfanos se quede atrás.

Comportamiento de la ordenación secuencial de una NfApp

Información general

De forma predeterminada, las aplicaciones de funciones de red en contenedor (NfApps) se instalan o actualizan en función del orden secuencial en el que aparecen en la versión de diseño de la función de red (NFDV). En el caso de la eliminación, las NfApps se eliminan en el orden inverso especificado. Cuando un publicador debe definir una ordenación específica de las NfApps, diferente de la predeterminada, se usa un dependsOnProfile para definir una secuencia única para las operaciones de instalación, actualización y eliminación.

Cómo usar dependsOnProfile

Un publicador puede usar dependsOnProfile en la NFDV para controlar la secuencia de ejecuciones de Helm para las NfApps. Dado el siguiente ejemplo, en la operación de instalación las NfApps se implementarán en el siguiente orden: dummyApplication1, dummyApplication2, luego dummyApplication. En la operación de actualización, las NfApps se actualizarán en el siguiente orden: dummyApplication2, dummyApplication1, luego dummyApplication. En la operación de eliminación, las NfApps se eliminarán en el siguiente orden: dummyApplication2, dummyApplication1, luego 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"
    }
}

Errores comunes

A partir de hoy, si el dependsOnProfile proporcionado en la NFDV no es válido, la operación NF fallará con un error de validación. El mensaje de error de validación se muestra en el recurso de estado de la operación y es similar al siguiente ejemplo.

 {
  "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."
  }
}

consideraciones sobre injectArtifactStoreDetails

En algunos casos, es posible que los gráficos de Helm de terceros no sean totalmente compatibles con los requisitos de AOSM para registryURL. En este caso, se puede usar la característica injectArtifactStoreDetails para evitar realizar cambios en los paquetes de Helm.

Cómo habilitar

Para usar injectArtifactStoreDetails, establezca el parámetro installOptions en la sección roleOrverrides del recurso NF a true, después use cualquier valor de registryURL que sea necesario para mantener válida la URL del registro. Consulte el ejemplo siguiente del 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"}}}}}'
    ]
  }
}