Preguntas frecuentes sobre los conjuntos de escalado de máquinas virtuales de Azure

Un conjunto de escalado puede tener entre 0 y 1000 máquinas virtuales basadas en imágenes de plataforma, o entre 0 y 600 basadas en imágenes personalizadas.

Sí. Un conjunto de escalado puede definir una configuración de discos de datos conectados que se aplica a todas las máquinas virtuales del conjunto. Para más información, consulte Conjuntos de escalado de máquinas virtuales de Azure y discos de datos conectados. Otras opciones para almacenar datos son las siguientes:

• Archivos de Azure (unidades compartidas SMB)
• Discos compartidos de Azure
• Unidad de sistema operativo
• Unidad temporal (local, sin el respaldo de Azure Storage)
• Servicio de datos de Azure (por ejemplo, tablas y blobs de Azure)
• Servicio de datos externos (por ejemplo, una base de datos remota)

Todas las regiones admiten conjuntos de escalado.

Cree y capture una imagen de máquina virtual y, a continuación, úsela como origen para el conjunto de escalado. Para obtener un tutorial sobre cómo crear y usar una imagen de máquina virtual personalizada, puede usar la CLI de Azure o Azure PowerShell.

De forma predeterminada, las máquinas virtuales se quitan del conjunto de escalado uniformemente entre zonas de disponibilidad (si el conjunto de escalado está implementado con una configuración por zonas) y los dominios de error para maximizar la disponibilidad. Primero se quitan las máquinas virtuales que tengan los identificadores más altos.

Para cambiar el orden de eliminación de máquinas virtuales, especifique una directiva de reducción horizontal para el conjunto de escalado.

Si aumenta la capacidad a 18, se crearán 3 máquinas virtuales. Cada vez, el identificador de la instancia de máquina virtual se aumenta a partir del mayor valor anterior (por ejemplo, 20, 21 y 22). Las VM se equilibran entre dominios de error.

Sí, puede usar el conjunto de escalado secuenciación de extensión.

Un conjunto de escalado regional (no de zona) usa grupos de selección de ubicación, donde cada uno actúa como un conjunto de disponibilidad implícito con cinco dominios predeterminados y cinco dominios de actualización. Los conjuntos de escalado con más de 100 máquinas virtuales abarcan varios grupos de selección de ubicación. Para más información, consulte Uso de grandes conjuntos de escalado de máquinas virtuales. Puede existir un conjunto de disponibilidad de máquinas virtuales en la misma red virtual que un conjunto de escalado de máquinas virtuales. Una configuración común consiste en colocar máquinas virtuales de nodos de control (que a menudo necesitan una configuración única) en un conjunto de disponibilidad y nodos de datos en el conjunto de escalado.

Sí. Para más información, consulte el documento sobre las zonas de conjunto de escalado.

Para procedimientos recomendados para el escalado automático, consulte Procedimientos recomendados de escalado automático en elementos virtuales.

Para nombres de métrica para un escalado automático que use métricas basadas en host, consulte Métricas compatibles con Azure Monitor.

Sí. Para ejemplos de escalado automático basados en un tema de Service Bus y una longitud de cola, consulte Métricas comunes de escalado automático de Azure Monitor.

Para una cola de Service Bus, use el siguiente JSON:

"metricName": "MessageCount",
"metricNamespace": "",
"metricResourceUri": "/subscriptions/s1/resourceGroups/rg1/providers/Microsoft.ServiceBus/namespaces/mySB/queues/myqueue"

Para una cola de almacenamiento, use el siguiente JSON:

"metricName": "ApproximateMessageCount",
"metricNamespace": "",
"metricResourceUri": "/subscriptions/s1/resourceGroups/rg1/providers/Microsoft.ClassicStorage/storageAccounts/mystorage/services/queue/queues/mystoragequeue"

Reemplace los valores de ejemplo con los identificadores uniformes de recursos (URI) del recurso.

Puede crear una configuración de escalado automático en una máquina virtual para usar las métricas de nivel de host, o usar las métricas basadas en SO invitado.

Para obtener una lista de métricas admitidas, consulte Métricas comunes de escalado automático de Azure Monitor.

Para obtener un ejemplo completo para conjuntos de escalado de máquinas virtuales, consulte Configuración avanzada de escalado automático con plantillas de Resource Manager para conjuntos de escalado de máquinas virtuales.

El ejemplo utiliza la métrica de CPU de nivel de host y una métrica de recuento de mensajes.

Puede crear alertas en las métricas de los conjuntos de escalado de máquinas virtuales a través de PowerShell o CLI de Azure. Para obtener más información, consulte Ejemplos de inicio rápido de PowerShell de Azure Monitor y Ejemplos de inicio rápido de CLI multiplataforma de Azure Monitor.

El elemento TargetResourceId del conjunto de escalado de máquinas virtuales tiene el siguiente aspecto:

/subscriptions/yoursubscriptionid/resourceGroups/yourresourcegroup/providers/Microsoft.Compute/virtualMachineScaleSets/yourvmssname

Puede elegir cualquier contador de rendimiento de máquina virtual como métrica sobre la que establecer la alerta. Para más información, consulte Métricas de SO invitado para máquinas virtuales Windows basadas en Resource Manager y Métricas de SO invitado para máquinas virtuales Linux en el artículo Métricas comunes de escalado automático de Azure Monitor.

Para configurar el escalado automático en un conjunto de escalado de máquinas virtuales mediante PowerShell, consulte el tutorial de escalado automático de conjuntos de escalado de máquinas virtuales. También puede configurar el escalado automático con la CLI de Azure y las plantillas de Azure

No. Si las reglas de escalado automático requieren instancias adicionales de máquina virtual como parte de un conjunto de escalado, se crea una nueva instancia de máquina virtual. Las instancias de máquina virtual detenidas (desasignadas) no se inician como parte de un evento de escalado automático. Sin embargo, es posible que esas máquinas virtuales detenidas (desasignadas) se eliminen como parte de un evento de escalado automático que escala en el número de instancias, del mismo modo que se puede eliminar cualquier instancia de máquina virtual según el orden del identificador de instancia de máquina virtual.

Para enviar de forma segura un certificado a la máquina virtual, puede instalar un certificado de cliente directamente en un almacén de certificados de Windows desde el almacén de claves del cliente.

Use el siguiente JSON:

"secrets": [
    {
        "sourceVault": {
            "id": "/subscriptions/{subscriptionid}/resourceGroups/myrg1/providers/Microsoft.KeyVault/vaults/mykeyvault1"
        },
        "vaultCertificates": [
            {
                "certificateUrl": "https://mykeyvault1.vault.azure.net/secrets/{secretname}/{secret-version}",
                "certificateStore": "certificateStoreName"
            }
        ]
    }
]

El código admite Windows y Linux.

Para más información, consulte el artículo sobre la creación o actualización de un conjunto de escalado de máquinas virtuales.

Para el último ejemplo, utilice la siguiente instrucción de la CLI de Azure en el shell de Azure, lea la documentación de ejemplo del módulo de la CLI de Service Fabrics, que se imprimirá en stdout:

az sf cluster create -h

Los certificados autofirmados no pueden utilizarse para la confianza distribuida proporcionada por una entidad de certificación y no deben utilizarse para ningún clúster de Service Fabric destinado a hospedar soluciones de producción empresarial; para obtener orientación adicional sobre la seguridad de Service Fabric, revise Procedimientos recomendados de seguridad de Azure Service Fabric y Escenarios de seguridad de los clústeres de Service Fabric.

Sí. La API de REST para osProfile es similar a la API de REST de máquina virtual estándar.

Incluya osProfile en la plantilla:

"osProfile": {
    "computerName": "[variables('vmName')]",
    "adminUsername": "[parameters('adminUserName')]",
    "linuxConfiguration": {
        "disablePasswordAuthentication": "true",
        "ssh": {
            "publicKeys": [
                {
                    "path": "[variables('sshKeyPath')]",
                    "keyData": "[parameters('sshKeyData')]"
                }
            ]
        }
    }
}

Este bloque JSON se usa en esta plantilla de inicio rápido de Azure.

Para más información, consulte el artículo sobre la creación o actualización de un conjunto de escalado de máquinas virtuales.

Para quitar certificados en desuso, quite el certificado antiguo de la lista de certificados del almacén. Deje en la lista todos los certificados que desee que permanezcan en el equipo. Esto no quita el certificado de todas las máquinas virtuales. Tampoco agrega el certificado a las nuevas máquinas virtuales que se creen en el conjunto de escalado de máquinas virtuales.

Para quitar el certificado de las máquinas virtuales existentes, tiene que usar una extensión de script personalizado que quite manualmente los certificados del almacén de certificados.

Si va a proporcionar a las máquinas virtuales solo una clave SSH pública, no es necesario colocar las claves públicas en Key Vault. Las claves públicas no son secretas.

Puede proporcionar claves públicas SSH en texto sin formato al crear una máquina virtual Linux:

"linuxConfiguration": {
    "ssh": {
        "publicKeys": [
            {
                "path": "path",
                "keyData": "publickey"
            }
        ]
    }
}

Para ver un ejemplo, consulte la plantilla de inicio rápido vm-sshkey de GitHub.

Update-AzVmss: muestra secretos que contienen instancias repetidas de /subscriptions/<my-subscription-id>/resourceGroups/internal-rg-dev/providers/Microsoft.KeyVault/vaults/internal-keyvault-dev, lo que no se permite.

Esto puede ocurrir si se intenta volver a agregar el mismo almacén en lugar de utilizar un nuevo certificado de almacén para el almacén de origen existente. El comando Add-AzVmssSecret no funciona correctamente si agrega secretos adicionales.

Para agregar más secretos desde el mismo almacén de claves, actualice la lista $vmss.properties.osProfile.secrets[0].vaultCertificates.

Para la estructura de entrada esperada, consulte el articulo sobre creación o actualización de un conjunto de escalado de máquinas virtuales.

Busque el secreto en el objeto de conjunto de escalado de máquinas virtuales que se encuentra en el almacén de claves. Luego, agregue la referencia del certificado (la dirección URL junto con el nombre del secreto) a la lista asociada con el almacén.

Las nuevas máquinas virtuales no tendrán el certificado antiguo. Sin embargo, las máquinas virtuales que tienen el certificado y que ya se han implementado tendrán el certificado antiguo.

No es necesario codificar las contraseñas en los scripts. Puede recuperar dinámicamente las contraseñas con los permisos que usa para ejecutar el script de implementación. Si tiene un script que mueve un certificado del almacén de secretos al almacén de claves, el comando get certificate del almacén de secretos también genera la contraseña del archivo. pfx.

Es necesario que una referencia de certificado de administración remota de Windows (WinRM) esté presente en la propiedad de secretos del perfil de sistema operativo.

El propósito de indicar el almacén de origen es aplicar directivas de lista de control de acceso (ACL) que existen en el modelo de servicio de Azure Cloud de un usuario. Si el almacén de origen no está especificado, los usuarios que no tengan permisos para implementar secretos o acceder a ellos en un almacén de claves podrían hacerlo mediante un proveedor de recursos de proceso (CRP). Las ACL existen incluso para recursos que no existen.

Si proporciona un identificador de almacén de origen incorrecto pero una dirección URL de almacén de claves válida, se informará de un error cuando sondee la operación.

Los certificados se agregan a todas las máquinas virtuales, incluso a las ya existentes. Si la propiedad upgradePolicy de la máquina virtual está establecida en manual, el certificado se agrega a la máquina virtual al realizar una actualización manual en ella.

Para información sobre cómo implementar certificados para las máquinas virtuales Linux, consulte Deploy certificates to VMs from a customer-managed key vault (Implementación de certificados en máquinas virtuales desde un almacén de claves administrado por el cliente).

Para agregar un certificado del almacén a un secreto existente, vea el ejemplo siguiente de PowerShell. Use un solo objeto secreto.

$newVaultCertificate = New-AzVmssVaultCertificateConfig -CertificateStore MY -CertificateUrl https://sansunallapps1.vault.azure.net:443/secrets/dg-private-enc/55fa0332edc44a84ad655298905f1809

$vmss.VirtualMachineProfile.OsProfile.Secrets[0].VaultCertificates.Add($newVaultCertificate)

Update-AzVmss -VirtualMachineScaleSet $vmss -ResourceGroup $rg -Name $vmssName

Si restablece la imagen inicial de una máquina virtual, los certificados se eliminan. El restablecimiento de la imagen inicial elimina todo el contenido del disco del sistema operativo.

Si elimina el secreto del almacén de claves y ejecuta stop deallocate en todas las máquinas virtuales y las inicia de nuevo, se producirá un error. El error se produce porque el CRP necesita recuperar los secretos desde el almacén de claves, pero no puede. En este escenario, puede eliminar los certificados del conjunto de escalado de máquinas virtuales.

El componente de CRP no conserva los secretos de cliente. Si ejecuta stop deallocate para todas las máquinas virtuales en el conjunto de escalado de máquinas virtuales, se elimina la memoria caché. En este escenario, los secretos se recuperan del almacén de claves.

Este problema no se produce en el escalado horizontal porque hay una copia en caché del secreto en Azure Service Fabric (en el modelo de inquilino único de estructura).

El propósito del requisito de Key Vault de especificar la versión del certificado es que el usuario vea claramente qué certificado se implementa en sus máquinas virtuales.

Si crea una máquina virtual y luego actualiza el secreto en el almacén de claves, ese nuevo certificado no se descarga en las máquinas virtuales. Pero parece que las máquinas virtuales hacen referencia a él y las nuevas máquinas virtuales obtienen el nuevo secreto. Para evitar esta situación, se le pide la referencia de la versión de secreto.

Para implementar el conjunto de claves públicas .cer en un conjunto de escalado de máquinas virtuales, puede generar un archivo .pfx que contenga solo los archivos .cer. Para ello, use X509ContentType = Pfx. Por ejemplo, cargue el archivo .cer como un objeto x509Certificate2 en C# o PowerShell y, a continuación, llame al método.

Para más información, consulte Método X509Certificate.Export (X509ContentType, String).

Para emular el pase de un certificado como una cadena base64, puede extraer la última dirección URL con versiones en una plantilla de Resource Manager. Incluya la siguiente propiedad JSON en la plantilla de Resource Manager:

"certificateUrl": "[reference(resourceId(parameters('vaultResourceGroup'), 'Microsoft.KeyVault/vaults/secrets', parameters('vaultName'), parameters('secretName')), '2015-06-01').secretUriWithVersion]"

En los conjuntos de escalado de máquinas virtuales y las máquinas virtuales, los certificados se tienen que encapsular en objetos JSON.

También se admite el tipo de contenido application/x-pkcs12.

Actualmente no se admiten archivos .cer. Para usar archivos .cer, expórtelos en contenedores .pfx.

Los conjuntos de escalado de máquinas virtuales son una capa de API fina sobre el CRP. Ambos componentes forman parte de la plataforma de proceso en el árbol de servicio de Azure.

Desde la perspectiva del cumplimiento, los conjuntos de escalado de máquinas virtuales son una parte fundamental de la plataforma de proceso de Azure. Comparten un equipo, herramientas, procesos, metodología de implementación, controles de seguridad, compilación just-in-time (JIT), supervisión, alertas y así sucesivamente, con el CRP propio. Los conjuntos de escalado de máquinas virtuales son compatibles con la Industria de tarjetas de pago (PCI) porque el CRP forma parte de la certificación de estándares de seguridad de datos de PCI (DSS) actual.

Para más información, consulte el Centro de confianza de Microsoft.

Sí. Puede ver algunas plantillas de MSI de ejemplo en las plantillas de inicio rápido de Azure para Linux y Windows.

En Azure Portal, puede eliminar una instancia individual o realizar una eliminación masiva mediante la selección de varias instancias. Si intenta eliminar una única instancia que tiene un bloqueo, se respeta el bloqueo y la instancia no se puede eliminar. Sin embargo, si selecciona de forma masiva varias instancias y cualquiera de esas instancias tiene un bloqueo, no se respetarán los bloqueos y se eliminarán todas las instancias seleccionadas.

En la CLI de Azure, solo puede eliminar una instancia individual. Si intenta eliminar una única instancia que tiene un bloqueo, se respeta el bloqueo y la instancia no se puede eliminar.

Para eliminar una extensión del conjunto de escalado de máquinas virtuales, utilice el siguiente ejemplo de PowerShell:

$vmss = Get-AzVmss -ResourceGroupName "resource_group_name" -VMScaleSetName "vmssName"

$vmss=Remove-AzVmssExtension -VirtualMachineScaleSet $vmss -Name "extensionName"

Update-AzVmss -ResourceGroupName "resource_group_name" -VMScaleSetName "vmssName" -VirtualMacineScaleSet $vmss

Puede encontrar el valor extensionName en $vmss.

Para ver un ejemplo de una plantilla del conjunto de escalado de máquinas virtuales que se integre con registros de Azure Monitor, vea el segundo ejemplo de Deploy an Azure Service Fabric cluster and enable monitoring by using Azure Monitor logs (Implementar un clúster de Azure Service Fabric y habilitar la supervisión mediante el uso de registros de Azure Monitor).

Si la directiva de actualización se establece en automática, al volver a implementar la plantilla con las nuevas propiedades de extensión se actualizan todas máquinas virtuales.

Si la directiva de actualización se establece en manual, actualice primero la extensión y, a continuación, actualice manualmente todas las instancias en las máquinas virtuales.

Si la definición de extensión en el modelo del conjunto de escalado de máquinas virtuales se actualiza y se establece la propiedad upgradePolicy en automática, actualiza las máquinas virtuales. Si se establece la propiedad upgradePolicy en manual, las extensiones se marcan como que no coinciden con el modelo.

Si se ha recuperado el servicio de una máquina virtual existente, aparece como un reinicio y las extensiones no se ejecutan de nuevo. Si una VM restablece su imagen inicial, el proceso es como sustituir el disco de sistema operativo con la imagen de origen. Cualquier especialización del modelo más reciente, como las extensiones, se ejecuta de nuevo.

Para unir un conjunto de escalado de máquinas virtuales a un dominio de Active Directory (Azure AD), puede definir una extensión.

Para definir una extensión, utilice la propiedad JsonADDomainExtension:

"extensionProfile": {
    "extensions": [
        {
            "name": "joindomain",
            "properties": {
                "publisher": "Microsoft.Compute",
                "type": "JsonADDomainExtension",
                "typeHandlerVersion": "1.3",
                "settings": {
                    "Name": "[parameters('domainName')]",
                    "OUPath": "[variables('ouPath')]",
                    "User": "[variables('domainAndUsername')]",
                    "Restart": "true",
                    "Options": "[variables('domainJoinOptions')]"
                },
                "protectedsettings": {
                    "Password": "[parameters('domainJoinPassword')]"
                }
            }
        }
    ]
}

Si la extensión de conjunto de escalado de máquinas virtuales está intentando instalar algo que requiere un reinicio, puede usar la extensión de configuración de estado deseado de Azure Automation (DSC de Automatización). Si el sistema operativo es Windows Server 2012 R2, Azure extrae en el programa de instalación de Windows Management Framework (WMF) 5.0, reinicia y continúa con la configuración.

Para ejecutar un script personalizado que está hospedado en una cuenta de almacenamiento privado, establezca una configuración protegida con el nombre y la clave de la cuenta de almacenamiento. Para más información, consulte la sección sobre la Extensión del script personalizado.

Hay dos formas principales de cambiar la contraseña de las máquinas virtuales en conjuntos de escalado.

• Crear directamente un modelo de conjunto de escalado de máquinas virtuales. Disponible con API 2017-12-01 y versiones posteriores.

  Actualizar las credenciales de administrador directamente en el modelo del conjunto de escalado (por ejemplo, mediante Azure Resource Explorer, PowerShell o CLI). Una vez que el conjunto de escalado está actualizado, todas las nuevas máquinas virtuales tienen nuevas credenciales. Las máquinas virtuales existentes solo tienen las nuevas credenciales si se restablece la imagen inicial.

• Restablecer la contraseña mediante las extensiones de acceso de la máquina virtual. Asegúrese de seguir los requisitos de contraseña que se describen aquí.

  Utilice el siguiente ejemplo de PowerShell:

  $vmssName = "myvmss"
  $vmssResourceGroup = "myvmssrg"
  $publicConfig = @{"UserName" = "newuser"}
  $privateConfig = @{"Password" = "********"}
  
  $extName = "VMAccessAgent"
  $publisher = "Microsoft.Compute"
  $vmss = Get-AzVmss -ResourceGroupName $vmssResourceGroup -VMScaleSetName $vmssName
  $vmss = Add-AzVmssExtension -VirtualMachineScaleSet $vmss -Name $extName -Publisher $publisher -Setting $publicConfig -ProtectedSetting $privateConfig -Type $extName -TypeHandlerVersion "2.0" -AutoUpgradeMinorVersion $true
  Update-AzVmss -ResourceGroupName $vmssResourceGroup -Name $vmssName -VirtualMachineScaleSet $vmss
  

Sí. Un grupo de seguridad de red se puede aplicar directamente a un conjunto de escalado haciendo referencia a él en la sección networkInterfaceConfigurations del perfil de red. Ejemplo:

"networkProfile": {
    "networkInterfaceConfigurations": [
        {
            "name": "nic1",
            "properties": {
                "primary": "true",
                "ipConfigurations": [
                    {
                        "name": "ip1",
                        "properties": {
                            "subnet": {
                                "id": "[concat('/subscriptions/', subscription().subscriptionId,'/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Network/virtualNetworks/', variables('vnetName'), '/subnets/subnet1')]"
                            },
                            "loadBalancerInboundNatPools": [
                                {
                                    "id": "[concat('/subscriptions/', subscription().subscriptionId,'/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Network/loadBalancers/', variables('lbName'), '/inboundNatPools/natPool1')]"
                                }
                            ],
                            "loadBalancerBackendAddressPools": [
                                {
                                    "id": "[concat('/subscriptions/', subscription().subscriptionId,'/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Network/loadBalancers/', variables('lbName'), '/backendAddressPools/addressPool1')]"
                                }
                            ]
                        }
                    }
                ],
                "networkSecurityGroup": {
                    "id": "[concat('/subscriptions/', subscription().subscriptionId,'/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Network/networkSecurityGroups/', variables('nsgName'))]"
                }
            }
        }
    ]
}

Si tiene dos conjuntos de escalado de máquinas virtuales con servidores front-end de Azure Load Balancer, y están en la misma suscripción y región, puede desasignar las direcciones IP públicas de cada uno de ellos y asignarlas al otro. Consulte, por ejemplo, VIP Swap: Blue-green deployment in Azure Resource Manager (Intercambio de VIP: implementación azul-verde en Azure Resource Manager). Esto implica un retraso ya que los recursos se desasignan y asignan a nivel de red. Una opción más rápida es usar Azure Application Gateway con dos grupos de back-end y una regla de enrutamiento. También puede hospedar la aplicación con Azure App Service, que permite realizar un cambio rápido entre las ranuras de ensayo y las de producción.

Las direcciones IP se seleccionan de una subred que especifique.

El método de asignación de direcciones IP de un conjunto de escalado de máquinas virtuales siempre es "dinámico", pero eso no significa que estas direcciones IP puedan cambiar. En este caso, "dinámico" solo significa que no tiene que especificar la dirección IP en una solicitud PUT. Especifique el conjunto estático mediante el uso de la subred.

Para implementar un conjunto de escalado de máquinas virtuales en una red virtual de Azure existente, consulte el documento sobre implementación de un conjunto de escalado de máquinas virtuales en una red virtual existente.

Sí. Para usar las redes aceleradas, establezca enableAcceleratedNetworking en true en los ajustes de networkInterfaceConfigurations de su conjunto de escalado. Por ejemplo

"networkProfile": {
    "networkInterfaceConfigurations": [
        {
            "name": "niconfig1",
            "properties": {
                "primary": true,
                "enableAcceleratedNetworking" : true,
                "ipConfigurations": [
                ]
            }
        }
    ]
}

Para crear un conjunto de escalado de máquina virtual con una configuración de DNS personalizada, agregue un paquete JSON dnsSettings a la sección de networkInterfaceConfigurations del conjunto de escalado. Ejemplo:

    "dnsSettings":{
        "dnsServers":["10.0.0.6", "10.0.0.5"]
    }

Para crear un conjunto de escalado de máquina virtual que asigne una dirección IP pública a cada máquina virtual, asegúrese de que la versión de API del recurso Microsoft.Compute/virtualMachineScaleSets sea 2017-03-30 y agregue un paquete JSON publicipaddressconfiguration a la sección ipConfigurations del conjunto de escalado. Ejemplo:

    "publicipaddressconfiguration": {
        "name": "pub1",
        "properties": {
        "idleTimeoutInMinutes": 15
        }
    }

Sí. Puede agregar los id. de recurso de varios grupos de direcciones back-end de Application Gateway a la lista applicationGatewayBackendAddressPools de la sección ipConfigurations, en el perfil de red del conjunto de escalado.

Una de las razones para crear un conjunto de escalado de máquinas virtuales con menos de dos máquinas virtuales sería usar las propiedades elásticas de un conjunto de escalado de máquinas virtuales. Por ejemplo, podría implementar un conjunto de escalado de máquinas virtuales con cero máquinas virtuales a fin de definir su infraestructura sin pagar por los costos de ejecución de máquina virtual. A continuación, cuando esté listo para implementar máquinas virtuales, aumente la "capacidad" del conjunto de escalado de máquinas virtuales hasta el recuento de instancias de producción.

Otra razón por la que podría crear un conjunto de escalado de máquinas virtuales con menos de dos máquinas virtuales es si le preocupa menos la disponibilidad que el uso de un conjunto de disponibilidad con máquinas virtuales discretas. Los conjuntos de escalado de máquinas virtuales le proporcionan una forma de trabajar con unidades de proceso indiscriminadas que son fungibles. Esta uniformidad es un diferenciador clave entre los conjuntos de escalado de máquinas virtuales y los conjuntos de disponibilidad. Muchas cargas de trabajo sin estado no realizan seguimiento de unidades individuales. Si baja la carga de trabajo, puede reducir verticalmente a una unidad de proceso y escalar verticalmente a varias cuando aumente la carga de trabajo.

Para cambiar el número de máquinas virtuales en un conjunto de escalado de máquinas virtuales en Azure Portal, en la sección de propiedades del conjunto de escalado de máquinas virtuales, haga clic en la hoja "Escalado" y use el control deslizante.

Dispone de cierta flexibilidad en la manera de controlar las alertas de umbrales especificados. Por ejemplo, puede definir webhooks personalizados. El ejemplo del siguiente webhook procede de una plantilla de Resource Manager:

{
    "type": "Microsoft.Insights/autoscaleSettings",
    "apiVersion": "[variables('insightsApi')]",
    "name": "autoscale",
    "location": "[parameters('resourceLocation')]",
    "dependsOn": [
        "[concat('Microsoft.Compute/virtualMachineScaleSets/', parameters('vmSSName'))]"
    ],
    "properties": {
        "name": "autoscale",
        "targetResourceUri": "[concat('/subscriptions/',subscription().subscriptionId, '/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Compute/virtualMachineScaleSets/', parameters('vmSSName'))]",
        "enabled": true,
        "notifications": [
            {
                "operation": "Scale",
                "email": {
                    "sendToSubscriptionAdministrator": true,
                    "sendToSubscriptionCoAdministrators": true,
                    "customEmails": [
                        "youremail@address.com"
                    ]
                },
                "webhooks": [
                    {
                        "serviceUri": "<service uri>",
                        "properties": {
                            "key1": "custommetric",
                            "key2": "scalevmss"
                        }
                    }
                ]
            }
        ]
    }
}

Sí, puede crear un conjunto de escalado en un grupo de recursos existente.

Sí, se pueden mover recursos del conjunto de escalado a una nueva suscripción o a un nuevo grupo de recursos.

Para actualizar su conjunto de escalado de máquinas virtuales con una nueva imagen y para administrar la aplicación de revisiones consulte Actualización de un conjunto de escalado de máquinas virtuales.

Sí, puede usar la operación de restablecimiento de la imagen inicial para restablecer una máquina virtual sin cambiar la imagen. Sin embargo, si el conjunto de escalado de máquinas virtuales hace referencia a una imagen de plataforma con version = latest, la máquina virtual se puede actualizar a una imagen del SO posterior cuando llame a reimage.

Sí, puede hacerlo instalando la extensión de Azure Monitor en las máquinas virtuales del conjunto de escalado. A continuación se ofrece un ejemplo de CLI de Azure:

az vmss extension set --name MicrosoftMonitoringAgent --publisher Microsoft.EnterpriseCloud.Monitoring --resource-group Team-03 --vmss-name nt01 --settings "{'workspaceId': '<your workspace ID here>'}" --protected-settings "{'workspaceKey': '<your workspace key here'}"

Puede encontrar los elementos workspaceId y workspaceKey requeridos en el área de trabajo de Log Analytics de Azure Portal. En la página Información general, haga clic en el icono Configuración. Haga clic en la pestaña Orígenes conectados en la parte superior.

Para activar el diagnóstico de arranque, en primer lugar, cree una cuenta de almacenamiento. Luego coloque este bloque JSON en el elemento virtualMachineProfile del conjunto de escalado de máquinas virtuales y actualice el conjunto:

"diagnosticsProfile": {
    "bootDiagnostics": {
        "enabled": true,
        "storageUri": "http://yourstorageaccount.blob.core.windows.net"
    }
}

Cuando se crea una nueva máquina virtual, el elemento InstanceView de la máquina virtual, muestran los detalles de la captura de pantalla, etc. Este es un ejemplo:

"bootDiagnostics": {
    "consoleScreenshotBlobUri": "https://o0sz3nhtbmkg6geswarm5.blob.core.windows.net/bootdiagnostics-swarmagen-4157d838-8335-4f78-bf0e-b616a99bc8bd/swarm-agent-9574AE92vmss-0_2.4157d838-8335-4f78-bf0e-b616a99bc8bd.screenshot.bmp",
    "serialConsoleLogBlobUri": "https://o0sz3nhtbmkg6geswarm5.blob.core.windows.net/bootdiagnostics-swarmagen-4157d838-8335-4f78-bf0e-b616a99bc8bd/swarm-agent-9574AE92vmss-0_2.4157d838-8335-4f78-bf0e-b616a99bc8bd.serialconsole.log"
}

Para informarse sobre propiedad de cada máquina virtual sin realizar varias llamadas, puede llamar a ListVMInstanceViews realizando un GET de API de REST en el siguiente URI de recurso:

/subscriptions/<subscription_id>/resourceGroups/<resource_group_name>/providers/Microsoft.Compute/virtualMachineScaleSets/<scaleset_name>/virtualMachines?$expand=instanceView&$select=instanceView

No, no puede pasar diferentes argumentos de extensión a diferentes máquinas virtuales de un conjunto de escalado de máquinas virtuales. De todas formas, las extensiones pueden actuar en función de propiedades únicas de la máquina virtual en la que se ejecutan, como el nombre de la máquina. Además, las extensiones pueden consultar metadatos de instancias en http://169.254.169.254 para más información sobre la máquina virtual.

Hay huecos entre los nombres de máquina virtual del conjunto de escalado de máquinas virtuales y el identificador de la máquina virtual porque la propiedad overprovision del conjunto de escalado de máquinas virtuales está establecida en el valor predeterminado de true. Si la propiedad overprovision se establece en true, se crean más máquinas de las solicitadas. Las máquinas virtuales adicionales se eliminan a continuación. En este caso, lo que consigue es una mayor confiabilidad en la implementación a cambio de reglas de traducción de direcciones de red (NAT) contiguas y de nomenclatura contiguas.

Puede establecer esta propiedad en false. Para conjuntos de escalado de máquinas virtuales pequeños, esto no afecta significativamente a confiabilidad de la implementación.

La principal diferencia entre eliminar una máquina virtual en un conjunto de escalado de máquinas virtuales y cancelar la asignación de la máquina virtual es que deallocate no elimina los discos duros virtuales (VHD). Hay costos de almacenamiento asociados con la ejecución de stop deallocate. Puede usar uno de los dos por una de las siguientes razones:

• Quiere dejar de pagar por los costos de proceso pero mantener el estado del disco de las máquinas virtuales.
• Quiere iniciar un conjunto de máquinas virtuales más rápidamente de lo que puede escalar horizontalmente un conjunto de escalado de máquinas virtuales.
  • Relacionado con este escenario, puede haber creado su propio motor de escalado automático y quiere un escalado completo más rápido.
• Tiene un conjunto de escalado de máquinas virtuales que se distribuye de forma irregular a través de dominios de error o dominios de actualización. Esto puede ser porque eliminó de forma selectiva las máquinas virtuales, o porque se eliminaron las máquinas virtuales después proveer en exceso. Ejecutar stop deallocate seguido de start en el conjunto de escalado de máquinas virtuales distribuye de manera uniforme las máquinas virtuales a través de dominios de error o dominios de actualización.

Cree una instantánea de una instancia de un conjunto de escalado de máquinas virtuales.

$rgname = "myResourceGroup"
$vmssname = "myVMScaleSet"
$Id = 0
$location = "East US"

$vmss1 = Get-AzVmssVM -ResourceGroupName $rgname -VMScaleSetName $vmssname -InstanceId $Id
$snapshotconfig = New-AzSnapshotConfig -Location $location -AccountType Standard_LRS -OsType Windows -CreateOption Copy -SourceUri $vmss1.StorageProfile.OsDisk.ManagedDisk.id
New-AzSnapshot -ResourceGroupName $rgname -SnapshotName 'mySnapshot' -Snapshot $snapshotconfig

Cree un nuevo disco administrado a partir de la instantánea.

$snapshotName = "mySnapshot"
$snapshot = Get-AzSnapshot -ResourceGroupName $rgname -SnapshotName $snapshotName
$diskConfig = New-AzDiskConfig -AccountType Premium_LRS -Location $location -CreateOption Copy -SourceResourceId $snapshot.Id
$osDisk = New-AzDisk -Disk $diskConfig -ResourceGroupName $rgname -DiskName ($snapshotName + '_Disk')