Capacidad de proceso de Azure Stack Hub

Los tamaños de máquina virtual (VM) admitidos en Azure Stack Hub son un subconjunto de los admitidos en Azure. Azure impone límites de recursos junto con varios vectores para evitar el consumo excesivo de recursos (nivel de servicio y local del servidor). Sin imponer algunos límites en el consumo de los inquilinos, las experiencias de los inquilinos sufren cuando otros inquilinos sobreconsumen recursos. En el caso de la salida de red de la máquina virtual, hay límites de ancho de banda en Azure Stack Hub que coinciden con las limitaciones de Azure. En el caso de los recursos de almacenamiento en Azure Stack Hub, los límites de IOPS de almacenamiento evitan el consumo excesivo básico de recursos por parte de los inquilinos por el acceso al almacenamiento.

Selección de ubicación de VM

El motor de ubicación de Azure Stack Hub coloca máquinas virtuales de cliente en los hosts disponibles.

Azure Stack Hub usa dos consideraciones al colocar máquinas virtuales. ¿Hay suficiente memoria en el host para ese tipo de máquina virtual? Y dos, ¿las máquinas virtuales forman parte de un conjunto de disponibilidad o son conjuntos de escalado de máquinas virtuales?

Para lograr una alta disponibilidad de una carga de trabajo de producción de varias máquinas virtuales en Azure Stack Hub, las máquinas virtuales (VM) se colocan en un conjunto de disponibilidad que los distribuye entre varios dominios de error. Un dominio de error en un conjunto de disponibilidad se define como un único nodo en la unidad de escalado. Azure Stack Hub admite un conjunto de disponibilidad con un máximo de tres dominios de error para ser coherente con Azure. Las máquinas virtuales colocadas en un conjunto de disponibilidad están aisladas físicamente entre sí extendiéndolos lo más uniformemente posible en varios dominios de error (nodos de Azure Stack Hub). Si se produce un fallo de hardware, las máquinas virtuales del dominio erróneo se reinician en otros dominios de fallo. Si es posible, se conservan en dominios de error independientes de las otras máquinas virtuales del mismo conjunto de disponibilidad. Cuando el host vuelve a estar en línea, las máquinas virtuales se reequilibran para mantener la alta disponibilidad.

Los conjuntos de escalado de máquinas virtuales usan conjuntos de disponibilidad en el back-end y comprueban que cada instancia de conjunto de escalado de máquinas virtuales se coloque en un dominio de error distinto. Esto significa que usan nodos de infraestructura de Azure Stack Hub independientes. Por ejemplo, en un sistema de Azure Stack Hub de cuatro nodos, podría haber una situación en la que se produce un error en un conjunto de escalado de máquinas virtuales de tres instancias al crearse debido a la falta de la capacidad de cuatro nodos para colocar tres instancias del conjunto de escalado de máquinas virtuales en tres nodos independientes de Azure Stack Hub. Además, los nodos de Azure Stack Hub se pueden completar a distintos niveles antes de intentar seleccionar su ubicación.

Azure Stack Hub no sobrecommite la memoria. Sin embargo, se permite una asignación excesiva del número de núcleos físicos.

Dado que los algoritmos de ubicación no consideran la relación de sobreaprovisionamiento entre los núcleos virtuales y físicos existentes como un factor, cada host podría tener una relación diferente. Como Microsoft, no proporcionamos instrucciones sobre la relación de núcleos físicos a virtuales debido a la variación de las cargas de trabajo y los requisitos de nivel de servicio.

Consideración del número total de máquinas virtuales

Hay un límite en el número total de máquinas virtuales que se pueden crear. El número máximo de máquinas virtuales en Azure Stack Hub es de 700 y 60 por nodo de unidad de escalado. Por ejemplo, un límite de máquina virtual de Azure Stack Hub de ocho servidores sería 480 (8 * 60). Para una solución de Azure Stack Hub de 12 a 16 servidores, el límite sería 700. Este límite fue creado teniendo en cuenta todas las consideraciones de capacidad de cálculo, como la reserva de resiliencia y la relación entre CPU virtual y física que un operador desea mantener en el entorno.

Si se alcanza el límite de escalado de máquinas virtuales, se devuelven los siguientes códigos de error como resultado: VMsPerScaleUnitLimitExceeded, VMsPerScaleUnitNodeLimitExceeded.

Consideración para la implementación por lotes de máquinas virtuales

En las versiones anteriores e incluidas a 2002, de 2 a 5 máquinas virtuales por lote con un intervalo de 5 minutos entre lotes proporcionaban implementaciones de máquinas virtuales confiables para escalar hasta 700 máquinas virtuales. Con la versión 2005 de Azure Stack Hub en adelante, podemos aprovisionar máquinas virtuales de forma confiable en tamaños de lote de 40 con un intervalo de 5 minutos entre implementaciones por lotes. Las operaciones Start, Stop-Deallocate y Update deben realizarse en un tamaño de lote de 30, lo que deja 5 minutos entre lote y lote.

Consideración de las máquinas virtuales de GPU

Azure Stack Hub reserva memoria para la conmutación por error de las máquinas virtuales de la infraestructura y del inquilino. A diferencia de otras máquinas virtuales, las máquinas virtuales de GPU se ejecutan en un modo que no es de alta disponibilidad (HA) y, por tanto, no conmutan por error. Como resultado, la memoria reservada para una marca de solo máquina virtual de GPU es lo que requiere la infraestructura para la conmutación por error, en lugar de tener en cuenta también la memoria de la máquina virtual del inquilino de alta disponibilidad.

Memoria de Azure Stack Hub

Azure Stack Hub está diseñado para mantener las máquinas virtuales en ejecución que se aprovisionaron correctamente. Por ejemplo, si un host está sin conexión debido a un error de hardware, Azure Stack Hub intenta reiniciar esa máquina virtual en otro host. El segundo ejemplo se da durante la revisión y actualización del software de Azure Stack Hub. Si es necesario reiniciar un host físico, se intenta mover las máquinas virtuales que se ejecutan en ese host a otro host disponible en la solución.

Esta administración o movimiento de máquinas virtuales solo se puede lograr si hay capacidad de memoria reservada para permitir que se produzca el reinicio o la migración. Una parte de la memoria total del host está reservada y no está disponible para la ubicación de la máquina virtual del inquilino.

Puede revisar un gráfico circular en el portal de administración que muestra la memoria libre y ocupada en Azure Stack Hub. El siguiente diagrama muestra la capacidad de memoria física en una unidad de escalado de Azure Stack Hub en Azure Stack Hub:

La memoria usada está formada por varios componentes. Los componentes siguientes consumen la memoria de la sección de uso del gráfico circular.

• Uso o reserva del sistema operativo del host: La memoria usada por el sistema operativo (SO) en el host, las tablas de páginas de memoria virtual, los procesos que se ejecutan en el sistema operativo host y la caché de memoria de Spaces Direct. Dado que este valor depende de la memoria usada por los distintos procesos de Hyper-V que se ejecutan en el host, puede fluctuar.
• Servicios de infraestructura: Máquinas virtuales de infraestructura que componen Azure Stack Hub. Como se explicó anteriormente, estas máquinas virtuales forman parte del máximo de 700 máquinas virtuales. La utilización de la memoria del componente de servicios de infraestructura puede cambiar a medida que trabajamos para que los servicios de infraestructura sean más escalables y resistentes. Para más información, consulte Planeamiento de capacidad de Azure Stack Hub.
• Reserva de resistencia: Azure Stack Hub reserva una parte de la memoria para permitir la disponibilidad del inquilino durante un error de host único, así como durante la revisión y actualización para permitir la correcta migración en vivo de las máquinas virtuales.
• Máquinas virtuales de inquilino: Las máquinas virtuales de inquilino creadas por los usuarios de Azure Stack Hub. Además de ejecutar máquinas virtuales, cualquier máquina virtual que haya aterrizado en la infraestructura consume memoria. Esto significa que las máquinas virtuales con el estado "Creando" o "Error", o las máquinas virtuales apagadas desde el invitado, consumirán memoria. Sin embargo, las máquinas virtuales que se han desasignado mediante la opción de detención de desasignación del portal, PowerShell o la CLI no consumirán memoria de Azure Stack Hub.
• Proveedores de recursos de valor agregado (CSP): Máquinas virtuales implementadas para los CSP de valor agregado, como SQL, MySQL, App Service, etc.

La mejor manera de comprender el consumo de memoria en el portal es usar Capacity Planner de Azure Stack Hub para ver el impacto de las diversas cargas de trabajo. El siguiente cálculo es el mismo que usa la herramienta de planeación.

Este cálculo da como resultado la memoria total disponible que se puede usar para la ubicación de la máquina virtual del inquilino. Esta capacidad de memoria es para la totalidad de la unidad de escalado de Azure Stack Hub.

Memoria disponible para la colocación de la máquina virtual = memoria total del host - reserva de resiliencia - memoria usada por máquinas virtuales de inquilinos en ejecución - sobrecarga de la infraestructura de Azure Stack Hub ¹

• Memoria total del host = Suma de memoria de todos los nodos
• Reserva de resistencia = H + R * ((N-1) * H) + V * (N-2)
• Memoria usada por máquinas virtuales de inquilino = Memoria real consumida por la carga de trabajo del inquilino, no depende de la configuración de alta disponibilidad
• Sobrecarga de infraestructura de Azure Stack Hub = 268 GB + (4 GB x N)

Donde:

• H = Tamaño de la memoria de servidor único
• N = Tamaño de la unidad de escalado (número de servidores)
• R = La reserva del sistema operativo para la sobrecarga del sistema operativo, que es .15 en esta fórmula²
• V = máquina virtual de alta disponibilidad más grande en la unidad de escala

¹ Sobrecarga de infraestructura de Azure Stack Hub = 268 GB + (4 GB x # de nodos). Se usan aproximadamente 31 máquinas virtuales para hospedar la infraestructura de Azure Stack Hub y, en total, consumen aproximadamente 268 GB + (4 GB x # de nodos) de memoria y 146 núcleos virtuales. La justificación de este número de máquinas virtuales es satisfacer la separación de servicios necesaria para cumplir los requisitos de seguridad, escalabilidad, mantenimiento y aplicación de revisiones. Esta estructura de servicio interno permite la futura introducción de nuevos servicios de infraestructura mientras se desarrollan.

² Reserva del sistema operativo para la sobrecarga = 15 % (0,15) de la memoria del nodo. El valor de reserva del sistema operativo es una estimación y varía en función de la capacidad de memoria física del servidor y la sobrecarga general del sistema operativo.

El valor V, la máquina virtual con alta disponibilidad más grande de la unidad de escalado, se basa dinámicamente en el tamaño más grande de memoria de la máquina virtual del inquilino. Por ejemplo, el valor de máquina virtual de alta disponibilidad más grande es un mínimo de 12 GB (teniendo en cuenta la máquina virtual de infraestructura) o 112 GB o cualquier otro tamaño de memoria de máquina virtual compatible en la solución de Azure Stack Hub. Cambiar la máquina virtual de alta disponibilidad más grande en el tejido de Azure Stack Hub da lugar a un aumento de la reserva de resistencia y también al aumento de la memoria de la propia máquina virtual. Recuerde que las máquinas virtuales de GPU se ejecutan en un modo que no es de alta disponibilidad.

Cálculo de ejemplo

Tenemos una implementación pequeña de Azure Stack Hub de cuatro nodos con 768 GB de RAM en cada nodo. Tenemos previsto colocar una máquina virtual para SQL Server con 128 GB de RAM (Standard_E16_v3). ¿Cuál es la memoria disponible para la selección de ubicación de la máquina virtual?

• Memoria total del host = suma de memoria de todos los nodos = 4 * 768 GB = 3072 GB
• Reserva de resistencia = H + R * ((N-1) * H) + V * (N-2) = 768 + 0,15 * ((4 - 1) * 768) + 128 * (4 - 2) = 1370 GB
• Memoria usada por máquinas virtuales de inquilino = Memoria real consumida por la carga de trabajo del inquilino, no depende de la configuración de alta disponibilidad = 0 GB
• Sobrecarga de infraestructura de Azure Stack Hub = 268 GB + (4 GB x N) = 268 + (4 * 4) = 284 GB

Memoria disponible para la selección de ubicación de máquina virtual = memoria total del host: reserva de resistencia: memoria usada por la ejecución de máquinas virtuales de inquilino: sobrecarga de infraestructura de Azure Stack Hub

Memoria disponible para la selección de ubicación de máquina virtual = 3072 - 1370 - 0 - 284 = 1418 GB

Consideraciones para la desasignación

Cuando una máquina virtual está en estado desasignado , no se usan recursos de memoria. Esto permite colocar otras máquinas virtuales en el sistema.

Si la máquina virtual desasignada se inicia de nuevo, el uso o la asignación de memoria se tratan como una nueva máquina virtual colocada en el sistema y se consume la memoria disponible. Si no hay memoria disponible, la máquina virtual no se iniciará.

Las máquinas virtuales grandes implementadas actualmente muestran que la memoria asignada es de 112 GB, pero la demanda de memoria de estas máquinas virtuales es de aproximadamente 2 a 3 GB.

Hay tres maneras de desasignar memoria para la colocación de máquinas virtuales mediante la fórmula Reserva de resistencia = H + R * ((N-1) * H) + V * (N-2):

• Reducción del tamaño de la máquina virtual más grande
• Aumento de la memoria de un nodo
• Agregar un nodo

Reducción del tamaño de la máquina virtual más grande

Reducir el tamaño de la máquina virtual más grande a la siguiente máquina virtual más pequeña en el conjunto (24 GB) reduce el tamaño de la reserva de resiliencia.

Reserva de resistencia = 384 + 172,8 + 48 = 604,8 GB

Agregar un nodo

Al agregar un nodo de Azure Stack Hub , se desasigna la memoria mediante la distribución de la memoria entre los dos nodos.

Reserva de resistencia = 384 + (0,15) ((5)*384) + 112 * (3) = 1008 GB

Aumento de la memoria en cada nodo a 512 GB

Aumentar la memoria de cada nodo aumenta la memoria total disponible.

Reserva de resistencia = 512 + 230,4 + 224 = 966,4 GB

Preguntas más frecuentes

P: Mi inquilino implementó una nueva máquina virtual, ¿cuánto tiempo tarda el gráfico de funcionalidades en el portal de administración para mostrar la capacidad restante?

R: La hoja de capacidad se actualiza cada 15 minutos, por lo tanto, tenga esto en cuenta.

P: ¿Cómo puedo ver los núcleos disponibles y los núcleos asignados?

R: en PowerShell, ejecute test-azurestack -include AzsVmPlacement -debug, que genera una salida similar a la siguiente:

    Starting Test-AzureStack
    Launching AzsVmPlacement
     
    Azure Stack Scale Unit VM Placement Summary Results
     
    Cluster Node    VM Count VMs Running Physical Core Total Virtual Co Physical Memory Total Virtual Mem
    ------------    -------- ----------- ------------- ---------------- --------------- -----------------
    LNV2-Node02     20       20          28            66               256             119.5            
    LNV2-Node03     17       16          28            62               256             110              
    LNV2-Node01     11       11          28            47               256             111              
    LNV2-Node04     10       10          28            49               256             101              
    
    PASS : Azure Stack Scale Unit VM Placement Summary

P: El número de máquinas virtuales implementadas en mi instancia de Azure Stack Hub no ha cambiado, pero mi capacidad está fluctuando. ¿Por qué?

A: La memoria disponible para la colocación de VM tiene varias dependencias, una de las cuales es la reserva del sistema operativo host. Este valor depende de la memoria usada por los distintos procesos de Hyper-V que se ejecutan en el host, que no es un valor constante.

P: ¿En qué estado deben estar las máquinas virtuales de los inquilinos para consumir memoria?

A: Además de ejecutar VM, las VM que llegan al tejido también consumen memoria. Esto significa que las máquinas virtuales que tengan el estado "Creando" o "Error" consumirán memoria. Las máquinas virtuales que se apaguen desde el invitado, en lugar de detener la desasignación desde el portal o PowerShell o la cli, consumirán memoria.

P: Tengo una instancia de Azure Stack Hub de cuatro hosts. Mi inquilino tiene 3 máquinas virtuales que consumen 56 GB de RAM (D5_v2) cada una. Una de las máquinas virtuales cambia de tamaño a 112 GB de RAM (D14_v2) y los informes de memoria disponibles en el panel dieron como resultado un aumento de 168 GB de uso en la hoja de capacidad. El reajuste posterior de tamaño de cada una de las otras dos máquinas virtuales D5_v2 a D14_v2 resultó en un aumento de solo 56 GB de RAM cada una. ¿Por qué es así?

A: La memoria disponible es una función de la reserva de resiliencia mantenida por Azure Stack Hub. La reserva de resistencia es una función del mayor tamaño de máquina virtual en la unidad de escalado de Azure Stack Hub. Al principio, la máquina virtual más grande en la marca tenía 56 GB de memoria. Cuando se cambió de tamaño la máquina virtual, la más grande de la marca pasó a 112 GB de memoria, lo que no solo aumentó la memoria utilizada por la máquina virtual del inquilino, sino que también aumentó la reserva de resistencia. Este cambio dio lugar a un aumento de 56 GB de memoria de la máquina virtual del arrendatario (de 56 GB a 112 GB) más un aumento de 112 GB en la memoria de reserva de resiliencia. Cuando se cambiaba el tamaño de las máquinas virtuales posteriores, el tamaño de máquina virtual más grande seguía siendo la máquina virtual de 112 GB y, por tanto, no había ningún aumento resultante de la reserva de resistencia. El aumento del consumo de memoria fue debido únicamente al incremento de la memoria de la VM del arrendatario (56 GB).

Pasos siguientes

Más información sobre el almacenamiento de Azure Stack Hub