Proceso de Azure Operator Nexus

Azure Operator Nexus se basa en construcciones básicas como servidores de proceso, dispositivos de almacenamiento y dispositivos del tejido de red. Estos servidores de proceso, también denominados máquinas sin sistema operativo (BMM), representan las máquinas físicas del bastidor. Ejecutan el sistema operativo Linux (anteriormente CBL-Mariner) de Azure y proporcionan compatibilidad de integración cerrada para cargas de trabajo de alto rendimiento.

Estos BMM se implementan como parte del conjunto de automatización de Azure Operator Nexus. Existen como nodos en un clúster de Kubernetes para atender varias cargas de trabajo virtualizadas y en contenedores en el ecosistema.

Cada BMM de una instancia de Azure Operator Nexus se representa como un recurso de Azure. Los operadores obtienen acceso para realizar varias operaciones para administrar el ciclo de vida de BMM como cualquier otro recurso de Azure.

Funcionalidades clave del proceso de Azure Operator Nexus

Alineación de NUMA.

La alineación de acceso a memoria no uniforme (NUMA) es una técnica para optimizar el rendimiento y el uso de recursos en servidores de varios sockets. Implica alinear los recursos de memoria y proceso para reducir la latencia y mejorar el acceso a los datos dentro de un sistema de servidor.

A través de la colocación estratégica de componentes de software y cargas de trabajo de forma compatible con NUMA, los operadores pueden mejorar el rendimiento de las funciones de red, como enrutadores virtualizados y firewalls. Esta ubicación da lugar a una mejor entrega de servicios y capacidad de respuesta en sus entornos en la nube.

De forma predeterminada, todas las cargas de trabajo implementadas en una instancia de Azure Operator Nexus están alineadas con NUMA.

Anclaje de CPU

La asignación de CPU es una técnica para asignar núcleos de CPU específicos a tareas o cargas de trabajo dedicadas, lo que ayuda a garantizar un rendimiento y aislamiento de recursos coherentes. Anclar funciones críticas de red o aplicaciones en tiempo real a núcleos de CPU específicos permite a los operadores minimizar la latencia y mejorar la previsibilidad en su infraestructura. Este enfoque es útil en escenarios en los que existen requisitos estrictos de calidad de servicio, ya que estas tareas pueden recibir potencia de procesamiento dedicada para un rendimiento óptimo.

Todas las máquinas virtuales creadas para la función de red virtual (VNF) o las cargas de trabajo de función de red en contenedor (CNF) en el proceso de Nexus del operador de Azure Operator Nexus se anclan a núcleos virtuales específicos. Este anclaje proporciona un mejor rendimiento y evita el robo de CPU.

Aislamiento de CPU

El aislamiento de CPU proporciona una separación clara entre las CPU asignadas para las cargas de trabajo y las CPU asignadas para las actividades del plano de control y de la plataforma. El aislamiento de CPU impide la interferencia y limita la previsibilidad del rendimiento de las cargas de trabajo críticas. Al aislar los núcleos de CPU o grupos de núcleos, los operadores pueden mitigar el efecto de los vecinos ruidosos. Ayuda a garantizar la potencia de procesamiento necesaria para las aplicaciones sensibles a la latencia.

Azure Operator Nexus reserva un pequeño conjunto de CPU para el sistema operativo host y otras aplicaciones de plataforma. Las CPU restantes están disponibles para ejecutar cargas de trabajo reales.

Compatibilidad con páginas enormes

El uso enorme de páginas en cargas de trabajo hace referencia al uso de páginas de memoria grandes, normalmente de 2 MB o 1 GB de tamaño, en lugar de las páginas estándar de 4 KB. Este enfoque ayuda a reducir la sobrecarga de memoria y mejora el rendimiento general del sistema. Reduce la tasa de errores del búfer de búsqueda de reserva de traducción (TLB) y mejora la eficacia del acceso a la memoria.

Las cargas de trabajo que implican grandes conjuntos de datos o operaciones de memoria intensiva, como el procesamiento de paquetes de red, pueden beneficiarse del uso de páginas enorme, ya que mejora el rendimiento de la memoria y reduce los cuellos de botella relacionados con la memoria. Como resultado, los usuarios ven un rendimiento mejorado y una latencia reducida.

Todas las máquinas virtuales creadas en Azure Operator Nexus pueden usar páginas enormes de 2 MB o 1 GB, en función del tipo de máquina virtual.

Compatibilidad con pila doble

La compatibilidad con doble pila hace referencia a la capacidad de los equipos y protocolos de red para controlar simultáneamente el tráfico IPv4 e IPv6. Con el agotamiento de las direcciones IPv4 disponibles y la creciente adopción de IPv6, la compatibilidad con doble pila es fundamental para la transición sin problemas y la coexistencia entre los dos protocolos.

Los operadores de telecomunicaciones usan compatibilidad con doble pila para garantizar la compatibilidad, la interoperabilidad y la prueba futura de sus redes. Les permite dar cabida tanto a dispositivos IPv4 como a servicios IPv6 mientras se realiza la transición gradual hacia la implementación completa de IPv6.

La compatibilidad con doble pila ayuda a garantizar la conectividad ininterrumpida y la entrega sin problemas del servicio a los clientes independientemente de sus protocolos de direccionamiento de red. Azure Operator Nexus proporciona compatibilidad con la configuración de IPv4 e IPv6 en todas las capas de la pila.

Tarjetas adaptadoras de red

Los procesos de Azure Operator Nexus están diseñados para cumplir los requisitos para ejecutar aplicaciones críticas que son de nivel de telecomunicaciones. Pueden realizar una transferencia de datos rápida y eficaz entre servidores y redes.

Las cargas de trabajo pueden usar la virtualización de E/S de raíz única (SR-IOV). SR-IOV permite la asignación directa de recursos de E/S físicos, como interfaces de red, a máquinas virtuales. Esta asignación directa omite la capa de conmutador virtual del hipervisor.

Este acceso directo al hardware mejora el rendimiento de la red, reduce la latencia y permite un uso más eficaz de los recursos. Hace que SR-IOV sea una opción ideal para los operadores que ejecutan funciones de red virtualizadas y en contenedores.

Estado de BMM

Las siguientes propiedades reflejan el estado operativo de un BMM:

• Power State indica el estado como derivado de un controlador sin sistema operativo (BMC). El estado puede ser On o Off.

• Ready State proporciona una evaluación general de la preparación de BMM. Examina una combinación de Detailed Status, Power State, y el estado de aprovisionamiento del recurso para determinar si BMM está listo o no. Cuando Ready State es True, BMM está activado, Detailed Status se Provisioned, y el nodo que representa el BMM se ha unido correctamente al clúster de Kubernetes en la nube. Si no se cumple alguna de esas condiciones, Ready State se establece en False.

• Cordon State refleja la capacidad de ejecutar cualquier carga de trabajo en una máquina. Los valores válidos son Cordoned y Uncordoned. Cordoned aprovecha la creación de cargas de trabajo nuevas en la máquina. Uncordoned garantiza que las cargas de trabajo ahora se puedan ejecutar en este BMM.

• Detailed Status refleja el estado actual de la máquina:

  • Preparing: La máquina se está preparando para el aprovisionamiento.
  • Provisioning: El aprovisionamiento está en curso.
  • Provisioned: El sistema operativo se aprovisiona en la máquina.
  • Available: La máquina está disponible para participar en el clúster. La máquina se aprovisionó correctamente, pero actualmente está desactivada.
  • Error: No se pudo aprovisionar la máquina.

  Preparing y Provisioning son estados transitorios. Provisioned, Available, y Error son estados de estado final.

• MachineRoles ayuda a identificar los roles que BMM cumple en el clúster Nexus. Los siguientes roles se asignan a los recursos de BMM:

  • Control plane: BMM ejecuta los agentes del plano de control de Kubernetes para el clúster de la plataforma Nexus.
  • Management plane: BMM ejecuta los agentes de la plataforma Nexus, incluidos controladores y extensiones.
  • Compute plane: BMM responsable de ejecutar cargas de trabajo de inquilino reales, incluidos los clústeres de Kubernetes Nexus y las máquinas virtuales.

  Consulte este vínculo para obtener más información sobre los roles de máquina.

Operaciones BMM

• Update/Patch BareMetal Machine: Actualice las propiedades del recurso BMM.
• List/Show BareMetal Machine: Recuperar información de BMM.
• Reimage BareMetal Machine: Vuelva a aprovisionar un BMM que coincida con la versión de imagen que se usa en el clúster.
• Reemplazar BareMetal Machine: Reemplace un BMM como parte de un esfuerzo para atender la máquina.
• Reiniciar BareMetal Machine: Reinicie un BMM.
• Apagar BareMetal Machine: Desactive un BMM.
• Iniciar BareMetal Machine: Active un BMM.
• Cordon BareMetal Machine: Impedir la programación de cargas de trabajo en el nodo de Kubernetes de BMM especificado. Opcionalmente, permita la evacuación de las cargas de trabajo del nodo.
• Uncordon BareMetal Machine: Permitir la programación de cargas de trabajo en el nodo de Kubernetes de BMM especificado.
• Validar BareMetalMachine: Desencadena la validación de hardware de un BMM.
• Ejecutar BareMetalMachine: Permite al cliente ejecutar un script especificado directamente en la entrada del BMM de destino.
• Extracción de datos de ejecución de BareMetalMachine: Permitir que el cliente ejecute una o varias extracciones de datos en un BMM.
• Ejecutar BareMetalMachine de solo lectura: Permitir que el cliente ejecute uno o varios comandos de solo lectura en un BMM.

Nota:

Los clientes no pueden crear ni eliminar BMM directamente. Estas máquinas solo se crean como la realización del ciclo de vida del clúster. La implementación bloquea las solicitudes de creación o eliminación de cualquier usuario y solo permite operaciones de creación o eliminación internas o controladas por la aplicación.

Información específica del factor de forma

Azure Operator Nexus ofrece un grupo de soluciones en la nube locales que se adaptan tanto a entornos near-edge y far-edge.