Procedimientos recomendados de Azure Operator Service Manager para grupos de configuración

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 de esquemas de grupo de configuración y el funcionamiento de los valores del grupo de configuración. Tenga en cuenta estos procedimientos al incorporar e implementar las NF.

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.