Preguntas frecuentes sobre Virtual Machine Scale Sets de Azure

Se paga por los recursos subyacentes que usa el conjunto de escalado, como máquinas virtuales, almacenamiento y recursos de red. No hay ningún cargo adicional por el propio conjunto de escalado.

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

Sí. Un conjunto de escalado puede definir la configuración de un disco de datos conectado 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:

• Azure Managed Disks (Premium v2, Premium, Estándar, Ultra)
• Azure Files: unidades compartidas de Bloque de mensajes de servidor (SMB) o Sistema de archivos de red (NFS)
• Azure NetApp Files
• Discos compartidos de Azure
• Unidad de sistema operativo
• Unidad temporal (local, sin el respaldo de Azure Storage)
• Servicio de datos de Azure (por ejemplo, Azure Table Storage o Azure Blob Storage)
• Servicio de datos externo (por ejemplo, una base de datos remota)

Todas las regiones admiten conjuntos de escalado.

Todas las SKU son compatibles con Virtual Machine Scale Sets.

Cree y capture una imagen de máquina virtual (VM) 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.

La actualización de imágenes del sistema operativo es un proceso gradual y no disruptivo que actualiza la imagen del sistema operativo de todo el conjunto de escalado de máquinas virtuales a lo largo del tiempo, lo que garantiza un impacto mínimo en las cargas de trabajo en ejecución.

El restablecimiento de la imagen inicial es una acción más inmediata y perjudicial que afecta solo a la instancia de máquina virtual seleccionada, ya que la detiene temporalmente y reinstala el sistema operativo.

Obtenga más información sobre la diferencia entre la actualización de imágenes del sistema operativo y el restablecimiento de la imagen inicial.

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 de error 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 obtener más información sobre los grupos de selección de ubicació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.

Consulte Procedimientos recomendados de escalado automático.

Consulte Métricas compatibles con Azure Monitor.

Sí. Para estos ejemplos, 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 escalabilidad automática en una máquina virtual para usar métricas de nivel de host o métricas basadas en un sistema operativo 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 de Virtual Machine Scale Sets, 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 Virtual Machine Scale Sets mediante PowerShell o la 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.

Consulte el escalado automático de Virtual Machine Scale Sets. También puede configurar la escalabilidad automática con la CLI de Azure y las plantillas de Azure.

No. Si las reglas de escalado automático requieren más instancias 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 escalabilidad automática. Sin embargo, las máquinas virtuales detenidas (desasignadas) se pueden eliminar como parte de un evento de escalabilidad automática que escale 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 una instancia de Virtual Machine Scale Sets.

Para el ejemplo más reciente, en un shell de Azure, use la siguiente instrucción de la CLI de Azure, que se imprime en stdout:

az sf cluster create -h

Los certificados autofirmados no se pueden usar para la confianza distribuida proporcionada por una entidad de certificación y no se deben usar para ningún clúster de Service Fabric que esté destinado a hospedar soluciones de producción empresariales. Para ver más instrucciones de seguridad, consulte Procedimientos recomendados de seguridad de Azure Service Fabric y Escenarios de seguridad de los clústeres de Service Fabric.

Sí. La API REST para osProfile es similar a la API 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 una instancia de Virtual Machine Scale Sets.

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. Esta acción no quita el certificado de todas las máquinas virtuales. Tampoco agrega el certificado a las nuevas máquinas virtuales que se crean en Virtual Machine Scale Sets.

Para quitar el certificado de las máquinas virtuales existentes, utilice una extensión de script personalizado para quitar manualmente el certificado 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 Azure 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.

Este error 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 va a agregar más secretos.

Para agregar más secretos desde el mismo almacén de claves, actualice la lista siguiente: $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.

Localice el secreto en el objeto de Virtual Machine Scale Sets 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, tienen el certificado antiguo.

No es necesario codificar 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 esté presente una referencia de certificado de administración remota de Windows (WinRM) en la propiedad Secrets del perfil de sistema operativo.

El propósito de indicar el almacén de origen es aplicar las directivas de lista de control de acceso (ACL) que existen en el modelo de Azure Cloud Services de un usuario. Si no se especifica el almacén de origen, 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 Virtual Machine Scale Sets 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 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 modelo de Virtual Machine Scale Sets.

El componente del CRP no hace persistentes los secretos de los clientes. Si ejecuta stop deallocate para todas las máquinas virtuales en Virtual Machine Scale Sets, 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 de un solo tejido).

El propósito es aclarar al usuario 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 este problema, se le pide que haga referencia a una versión del secreto.

Para implementar las claves públicas .cer en un conjunto de escalado de máquinas virtuales, puede generar un archivo .pfx que contenga solo los archivos .cer mediante 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 obtener 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 Virtual Machine Scale Sets 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.

Virtual Machine Scale Sets 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, Virtual Machine Scale Sets son una parte fundamental de la plataforma de proceso de Azure. Comparten la siguiente información con el propio CRP: un equipo, herramientas, procesos, metodología de implementación, controles de seguridad, compilación Just-In-Time (JIT), supervisión y alertas. Virtual Machine Scale Sets es compatible 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í. Para más información, consulte ¿Qué son las identidades administradas de recursos de Azure? Puede ver algunas plantillas de ejemplo de identidad del servicio administrado (MSI) 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 varias instancias de forma masiva y cualquiera de ellas tiene un bloqueo en vigor, los bloqueos no se respetan. 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 esa instancia no se puede eliminar.

Para eliminar una extensión de Virtual Machine Scale Sets, 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 de extensionName en $vmss.

Para obtener un ejemplo de una plantilla de Virtual Machine Scale Sets que se integre con registros de Azure Monitor, consulte el segundo ejemplo de 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, se actualizan todas máquinas virtuales al volver a implementar la plantilla con las nuevas propiedades de extensión.

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 se actualiza la definición de extensión del modelo de Virtual Machine Scale Sets, y se establece la propiedad upgradePolicy en automatic, actualiza las máquinas virtuales. Si la propiedad upgradePolicy se establece en manual, las extensiones se marcan como no coincidentes 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 se restablece la imagen inicial de una máquina virtual, el proceso es similar a sustituir la unidad de sistema operativo por la imagen de origen. Cualquier especialización del modelo más reciente, como las extensiones, se ejecuta de nuevo.

Para combinar una instancia de Virtual Machine Scale Sets a un dominio de Active Directory, puede definir una extensión.

Para definir una extensión, use 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')]"
                }
            }
        }
    ]
}

Puede usar la extensión Desired State Configuration de Azure Automation. 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.

Configure las opciones protegidas con la clave y el nombre de la cuenta de almacenamiento. Para más información, consulte la sección sobre la Extensión del script personalizado.

Puede:

• Cambiar directamente el modelo de Virtual Machine Scale Sets. Esta opción solo está disponible con la API 2017-12-01 y versiones posteriores.

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

• Restablezca la contraseña mediante las extensiones de acceso de máquina virtual. Asegúrese de seguir los requisitos de contraseña que se describen en las Preguntas frecuentes.

  El uso de una extensión de acceso de máquina virtual no requiere el restablecimiento de la imagen inicial porque la extensión no actualiza la contraseña en el modelo. La extensión ejecuta un script para anexar la contraseña a la contraseña o al archivo de clave SSH. La extensión no quita la clave SSH original. Una vez actualizada la extensión, haga lo mismo con las instancias para aplicar las actualizaciones al nombre de usuario y la contraseña en todas las instancias de máquina virtual.

  Nota

  Si la directiva de actualización automática está establecida en manual, seleccione manualmente la instancia para realizar una operación de actualización en instancias de máquina virtual individuales. Si la actualización automática se establece en Auto, la extensión se actualizará automáticamente. Para más información, consulte Actualizaciones automáticas de extensiones.

  Use el siguiente ejemplo de PowerShell para una instancia de Virtual Machine Scale Sets de Windows:

  $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
  

  Use el siguiente ejemplo de la CLI de Azure para un conjunto de escalado de máquinas virtuales Linux:

  az vmss extension set \
    --resource-group myResouceGroup \ 
    --vmss-name myScaleSet \
    --publisher Microsoft.OSTCExtensions \
    --name VMAccessForLinux \
    --version 1.5 \
    --protected-settings "{'username': 'newUser', 'password': 'newPassword'}"
  

Sí. Puede aplicar un NSG directamente a un conjunto de escalado haciendo referencia a él en la sección networkInterfaceConfigurations del perfil de red. Este es un 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 instancias de Virtual Machine Scale Sets con 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. Para más información, consulte Intercambio de VIP: implementación azul-verde en Azure Resource Manager. Sin embargo, puede que experimente 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 admite 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 Virtual Machine Scale Sets 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.

Consulte Implementación de una instancia de Virtual Machine Scale Sets en una red virtual existente.

Sí. Para usar redes aceleradas, establezca enableAcceleratedNetworking en true en la configuración networkInterfaceConfigurations del conjunto de escalado. Por ejemplo:

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

Para crear una instancia de Virtual Machine Scale Sets con una configuración DNS personalizada, agregue el paquete JSON dnsSettings a la sección networkInterfaceConfigurations del conjunto de escalado. Este es un ejemplo:

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

Para crear una instancia de Virtual Machine Scale Sets 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 la 2017-03-30 y agregue el paquete JSON publicipaddressconfiguration a la sección ipConfigurations del conjunto de escalado. Este es un ejemplo:

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

Sí. Puede agregar los identificadores de recurso de varios grupos de direcciones de back-end de puerta de enlace de aplicación a la lista applicationGatewayBackendAddressPools de la sección ipConfigurations del perfil de red del conjunto de escalado.

Una de las razones para crear una instancia de Virtual Machine Scale Sets con menos de dos máquinas virtuales es usar las propiedades elásticas que esta tiene. Por ejemplo, puede implementar una instancia de Virtual Machine Scale Sets con cero máquinas virtuales a fin de definir su infraestructura sin pagar los costos de ejecución de las máquinas virtuales. A continuación, cuando esté listo para implementar máquinas virtuales, puede aumentar 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 una instancia de Virtual Machine Scale Sets 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. Virtual Machine Scale Sets le proporciona una forma de trabajar con unidades de proceso indiscriminadas que son fungibles. Esta uniformidad es un diferenciador clave entre Virtual Machine Scale Sets 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 de una instancia de Virtual Machine Scale Sets en Azure Portal, en la sección Propiedades del conjunto de escalado de máquinas virtuales, seleccione el panel 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 hacerlo.

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

Para actualizar la instancia de Virtual Machine Scale Sets 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 una instancia de Virtual Machine Scale Sets hace referencia a una imagen de plataforma con version = latest, la máquina virtual se puede actualizar a una imagen del sistema operativo posterior cuando llame a reimage.

Sí, puede hacerlo instalando la extensión de Azure Monitor en las máquinas virtuales del conjunto de escalado. Este es un ejemplo que usa la 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 necesarios workspaceId y workspaceKey en el área de trabajo de Log Analytics de Azure Portal. En la página Información general, seleccione el icono Configuración. Seleccione 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. A continuación, coloque este bloque JSON en el elemento virtualMachineProfile de Virtual Machine Scale Set y actualice el conjunto:

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

Cuando se crea una nueva máquina virtual, la propiedad InstanceView de la máquina virtual muestra los detalles de la captura de pantalla. 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"
}

Visite la página Solución de problemas comunes con Virtual Machine Scale Sets.

Puede llamar a ListVMInstanceViews mediante una llamada GET a la API REST en el siguiente identificador URI de recursos:

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

El dominio de error no se devuelve cuando el conjunto de escalado usa la propagación máxima (platformFaultDomainCount = 1), ya que no hay ninguna garantía de cuántos dominios de error se usarían con esta configuración.

No, no puede. 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.

Los huecos se deben a que la propiedad overprovision de Virtual Machine Scale Sets se establece en el valor predeterminado 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. En el caso de conjuntos de escalado de máquinas virtuales pequeños, la confiabilidad de la implementación no se verá afectada significativamente.

La diferencia principal 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 una instancia de Virtual Machine Scale Sets.
  • Relacionado con este escenario, puede haber creado su propio motor de escalado automático y quiere un escalado completo más rápido.
• Tiene una instancia de Virtual Machine Scale Sets que se distribuye de forma irregular a través de dominios de error o dominios de actualización. Esta distribución desigual puede ser porque eliminó de forma selectiva máquinas virtuales, o porque se eliminaron las máquinas virtuales después del sobreaprovisionamiento. Ejecutar stop deallocate seguido de start en la instancia de Virtual Machine Scale Sets 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. Este es un ejemplo:

$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. Este es un ejemplo:

$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')