Часто задаваемые вопросы о Azure Масштабируемые наборы виртуальных машин

Вы оплачиваете базовые ресурсы, используемые масштабируемым набором, например виртуальные машины, хранилище и сетевые ресурсы. За сам масштабируемый набор не взимается дополнительная плата.

В масштабируемый набор может входить от 0 до 1000 виртуальных машин на базе образов платформы или от 0 до 600 виртуальных машин на базе пользовательских образов.

Да. Масштабируемый набор может определять конфигурацию подключенных дисков с данными, применяемую ко всем виртуальным машинам в наборе. Дополнительные сведения см. в статье Масштабируемые наборы ВМ Azure и подключенные диски данных. Ниже перечислены другие варианты хранения данных.

• Azure Управляемые диски — premium версии 2, Premium, Standard, Ultra
• Файлы Azure — общий диск сетевой файловой системы (SMB) или сетевой файловой системы (NFS)
• Azure NetApp Files
• Общие диски Azure
• Диск операционной системы
• Временный диск — локальный, не поддерживаемый служба хранилища Azure
• Служба данных Azure— например, хранилище таблиц Azure или Хранилище BLOB-объектов Azure
• Внешняя служба данных — например, удаленная база данных

Все регионы Azure поддерживают масштабируемые наборы.

Все номера SKU поддерживаются для Масштабируемые наборы виртуальных машин.

Создайте и захватить образ виртуальной машины, а затем используйте его в качестве источника для масштабируемого набора. Для обучения созданию и использованию пользовательского образа виртуальной машины можно воспользоваться Azure CLI или Azure PowerShell.

Обновление образа ОС — это постепенный и неразрывный процесс, который обновляет образ ОС для всего масштабируемого набора виртуальных машин со временем, обеспечивая минимальное влияние на выполнение рабочих нагрузок.

Повторное создание образа — это более немедленное и разрушительное действие, которое влияет только на выбранный экземпляр виртуальной машины, остановив его временно и переустановив ОС.

Узнайте больше о разнице между обновлением образа ОС и повторной версией.

По умолчанию виртуальные машины удаляются из масштабируемого набора равномерно между зонами доступности (если масштабируемый набор развертывается в зональной конфигурации) и доменами сбоя для максимальной доступности. Сначала удаляются виртуальные машины с самым высоким уровнем идентификатора.

Вы можете изменить порядок удаления виртуальных машин, указав политику масштабирования для масштабируемого набора.

Если увеличить емкость до 18, то будут созданы 3 новые виртуальные машины. При этом идентификатор экземпляра виртуальной машины будет каждый раз увеличиваться, начиная с предыдущего наибольшего значения (например, 20, 21, 22). Виртуальные машины распределяются между доменами сбоя.

Да, вы можете использовать последовательность расширений для масштабируемого набора.

Региональный (незональный) масштабируемый набор использует группы размещения, которые действуют как неявная группа доступности с пятью доменами сбоя и пятью доменами обновления. Масштабируемые наборы, содержащие более 100 виртуальных машин, охватывают несколько групп размещения. Дополнительные сведения о группах размещения см. в статье "Работа с большими Масштабируемые наборы виртуальных машин". Группа доступности виртуальных машин может находиться в той же виртуальной сети, что и набор масштабирования виртуальных машин. Типичная конфигурация — это размещение виртуальных машин узла управления (для которых часто требуется уникальная конфигурация) в группе доступности, а узлов данных — в масштабируемом наборе.

Да. Дополнительные сведения см. в документации по зонам масштабируемых наборов.

См. рекомендации по автоматическому масштабированию виртуальных машин.

См. сведения о метриках, поддерживаемых Azure Monitor.

Да. Такие примеры см. в статье Общие метрики автомасштабирования в Azure Monitor.

Для очереди служебной шины используйте следующий код JSON:

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

Для очереди хранилища используйте следующий код JSON:

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

Замените примеры значений соответствующими универсальными кодами ресурсов (URI).

Вы можете создать на виртуальной машине конфигурацию автомасштабирования с использованием метрик уровня узла или метрик на основе гостевой ОС.

Список поддерживаемых метрик см. в статье Общие метрики автомасштабирования Azure Monitor.

Полный пример Масштабируемые наборы виртуальных машин см. в статье "Расширенная настройка автомасштабирования" с помощью шаблонов Resource Manager для Масштабируемые наборы виртуальных машин.

В этой конфигурации используется метрика ЦП уровня узла и метрика количества сообщений.

Вы можете создавать оповещения о метриках для Масштабируемые наборы виртуальных машин с помощью PowerShell или Azure CLI. Дополнительные сведения см. в статье Примеры для быстрого запуска Azure Monitor с помощью PowerShell и разделе Работа с оповещениями.

Масштабируемый TargetResourceId набор виртуальных машин выглядит следующим образом:

/subscriptions/идентификатор_подписки/resourceGroups/группа_ресурсов/providers/Microsoft.Compute/virtualMachineScaleSets/имя_набора_ВМ

В качестве метрики, для которой будут устанавливаться оповещения, можно выбрать любой счетчик производительности виртуальной машины. Дополнительные сведения см. в разделе Метрики гостевой ОС для виртуальных машин под управлением Windows, развернутых с помощью Resource Manager и Метрики гостевой ОС для виртуальных машин под управлением Linux статьи Общие метрики автомасштабирования Azure Monitor.

См . автоматическое масштабирование масштабируемого набора виртуальных машин. Вы можете также настроить автомасштабирование с помощью Azure CLI и шаблонов Azure.

№ Если правила автомасштабирования требуют дополнительных экземпляров виртуальной машины в рамках масштабируемого набора, создается новый экземпляр виртуальной машины. Остановленные (освобожденные) экземпляры виртуальных машин не запускаются в рамках события автомасштабирования. Однако остановленные (освобожденные) виртуальные машины можно удалить как часть события автомасштабирования, которое масштабируется в количестве экземпляров, так же, как и любой экземпляр виртуальной машины, который можно удалить в зависимости от порядка идентификаторов экземпляров виртуальной машины.

Чтобы безопасно отправить сертификат на виртуальную машину, вы можете установить сертификат клиента из хранилища ключей непосредственно в хранилище сертификатов Windows.

Используйте следующий код 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"
            }
        ]
    }
]

Этот код поддерживает операционные системы Linux и Windows.

Дополнительные сведения см. в статье "Создание или обновление масштабируемого набора виртуальных машин".

В последнем примере в оболочке Azure используйте следующую инструкцию Azure CLI, которая печатается в stdout:

az sf cluster create -h

Самозаверяющие сертификаты нельзя использовать для распределенного доверия, предоставляемого центром сертификации, и не следует использовать для любого кластера Service Fabric, предназначенного для размещения корпоративных производственных решений. Дополнительные рекомендации по безопасности см. в статьях Рекомендации по безопасности Azure Service Fabric и Сценарии обеспечения безопасности кластеров Service Fabric.

Да. REST API для osProfile аналогичен REST API для стандартной виртуальной машины.

Включите в свой шаблон osProfile:

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

Этот блок JSON используется в этом шаблоне быстрого запуска Azure.

Дополнительные сведения см. в статье "Создание или обновление масштабируемого набора виртуальных машин".

Чтобы удалить устаревший сертификат, его необходимо удалить из списка сертификатов в хранилище. Не удаляйте сертификаты, которые вы хотите оставить на компьютере. Это действие не удаляет сертификат со всех виртуальных машин. Он также не добавляет сертификат в новые виртуальные машины, созданные в масштабируемом наборе виртуальных машин.

Чтобы удалить сертификат из существующих виртуальных машин, используйте расширение пользовательского скрипта, которое позволяет удалить сертификат из хранилища сертификатов вручную.

Если вы устанавливаете на виртуальные машины только открытый ключ SSH, его не нужно отправлять в Azure Key Vault. Открытые ключи не являются секретными.

При создании виртуальной машины Linux открытые ключи SSH можно указать в обычном текстовом формате.

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

Пример см. в шаблоне быстрого запуска vm-sshkey на сайте GitHub.

Эта ошибка может произойти, если вы попытаетесь прочитать то же хранилище вместо использования нового сертификата хранилища для существующего исходного хранилища. Команда Add-AzVmssSecret не работает должным образом при добавлении дополнительных секретов.

Чтобы добавить дополнительные секреты из того же хранилища ключей, обновите следующий список: $vmss.properties.osProfile.secrets[0].vaultCertificates.

Ожидаемую структуру входных данных см. в разделе о создании и обновлении масштабируемого набора виртуальных машин.

Найдите секрет в объекте масштабируемого набора виртуальных машин, который находится в хранилище ключей. Затем добавьте ссылку на сертификат (URL-адрес и имя хранилища секретов) в список, связанный с хранилищем.

Новые виртуальные машины не будут иметь старый сертификат. но на уже развернутых виртуальных машинах, где он установлен, этот сертификат останется.

Пароли не нужно жестко определять в скриптах. Их можно динамически извлечь на основе разрешений, используемых для выполнения скрипта развертывания. При выполнении скрипта, который перемещает сертификат из хранилища секретов в хранилище ключей, команда get certificate, выполняемая в хранилище секретов, также возвращает пароль для доступа к PFX-файлу.

В свойстве Secrets профиля ОС должна находиться ссылка на сертификат службы удаленного управления Windows (WinRM).

Указав исходное хранилище, вы сможете применить политики списка управления доступом (ACL), определенные в модели Облачных служб Azure пользователя. Если его не указать, пользователи без необходимых разрешений смогут развертывать или использовать секреты в хранилище ключей с помощью поставщика вычислительных ресурсов (CRP). Списки управления доступом существуют даже для несуществующих ресурсов.

Если указать неправильный идентификатор исходного хранилища, но допустимый URL-адрес хранилища ключей, при опросе операции отобразится ошибка.

Сертификаты добавляются на все виртуальные машины, в том числе на имеющиеся. Если для свойства масштабируемого набора upgradePolicy виртуальных машин задано manualзначение, сертификат добавляется на виртуальную машину при выполнении ручного обновления на виртуальной машине.

Дополнительные сведения о развертывании сертификатов виртуальных машин Linux из хранилища ключей, управляемого клиентом, см. в этой записи блога.

Чтобы добавить сертификат хранилища в имеющийся секрет, используйте приведенный ниже пример сценария PowerShell. Используйте только один объект секрета.

$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

После пересоздания образа виртуальной машины сертификаты удаляются. При пересоздании образа удаляется весь диск операционной системы.

Если секрет удаляется из хранилища ключей, а затем все stop deallocate виртуальные машины, а затем снова запускаете их, возникает сбой. Этот сбой связан с тем, что CRP не может получить необходимые секреты из хранилища ключей. В этом сценарии можно удалить сертификаты из модели масштабируемого набора виртуальных машин.

Компонент CRP не сохраняет секреты клиента. При запуске stop deallocate для всех виртуальных машин в масштабируемом наборе виртуальных машин кэш удаляется. В этом случае секреты извлекаются из хранилища ключей.

При горизонтальном увеличении масштаба эта проблема не возникает, так как в Azure Service Fabric хранится кэшированная копия секрета (в модели с одним клиентом Fabric).

Это позволяет пользователям четко понять, какой сертификат развернут на их виртуальных машинах.

Если вы создаете виртуальную машину, а затем обновляете секрет в хранилище ключей, новый сертификат на ваши виртуальные машины не загружается, но ссылка на него отображается. При создании виртуальных машин на них устанавливается новый секрет. Чтобы избежать этой проблемы, необходимо ссылаться на секретную версию.

Чтобы развернуть открытые ключи .cer в масштабируемом наборе виртуальных машин, можно создать PFX-файл, содержащий только .cer файлы с помощью X509ContentType = Pfx. Например, загрузите CER-файл как объект x509Certificate2 в C# или PowerShell, а затем вызовите метод.

Дополнительные сведения о методе X509Certificate.Export (X509ContentType, String) см. в этой статье.

Чтобы выполнить эмуляцию передачи сертификата в виде строки в формате Base64, можно извлечь последнюю версию URL-адреса в шаблоне Resource Manager. Включите в шаблон Resource Manager следующее свойство JSON:

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

В Масштабируемые наборы виртуальных машин и виртуальных машинах сертификаты должны быть упакованы в объекты JSON.

Мы также поддерживаем тип содержимого application/x-pkcs12.

Сейчас мы не поддерживаем CER-файлы. Чтобы использовать CER-файлы, экспортируйте их в PFX-контейнеры.

Масштабируемые наборы виртуальных машин — это тонкий слой API на вершине СРБ. Оба компонента входят в состав вычислительной платформы в дереве службы Azure.

С точки зрения соответствия требованиям Масштабируемые наборы виртуальных машин являются основной частью вычислительной платформы Azure. Они делятся следующими сведениями с самимИРБ: командой, инструментами, процессами, методологией развертывания, средствами обеспечения безопасности, JIT-компиляцией, мониторингом и оповещениями. Масштабируемые наборы виртуальных машин соответствуют стандарту PCI, так как ОНА является частью текущей аттестации стандарта безопасности данных PCI (DSS).

Дополнительные сведения см. в Центре управления безопасностью Майкрософт.

Да. Дополнительные сведения см. в обзоре управляемых удостоверений. Некоторые примеры шаблонов управляемого удостоверения службы (MSI) можно увидеть в шаблонах быстрого запуска Azure для Linux и Windows.

На портале Azure можно удалить отдельный экземпляр или выполнить групповое удаление, выбрав несколько экземпляров. При попытке удалить один экземпляр, к которому применена блокировка, блокировка будет учтена и вы не сможете удалить этот экземпляр. Однако если выбрать несколько экземпляров и в каком-то из них есть блокировка, она не будет соблюдаться. Все выбранные экземпляры будут удалены.

В Azure CLI есть возможность удаления только отдельного экземпляра. При попытке удалить один экземпляр, к которому применена блокировка, блокировка будет учтена и вы не сможете удалить этот экземпляр.

Чтобы удалить расширение масштабируемого набора виртуальных машин, используйте следующий пример 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

Значение extensionName можно найти в $vmss.

Пример шаблона масштабируемого набора виртуальных машин, который интегрируется с журналами Azure Monitor, см. второй пример развертывания кластера Azure Service Fabric и включения мониторинга с помощью журналов Azure Monitor.

Если политика обновления настроена на автоматическое обновление, при повторном развертывании шаблона новые свойства расширения применяются на всех виртуальных машинах.

Если политика обновления настроена на обновление вручную, сначала обновите расширение, а затем вручную обновите все экземпляры на виртуальных машинах.

Если определение расширения в модели масштабируемого набора виртуальных машин обновляется, а upgradePolicy свойство задано automatic, оно обновляет виртуальные машины. Если для свойства upgradePolicy установлено значение manual, расширения помечаются как не соответствующие модели.

Если виртуальная машина восстановлена, она рассматривается как прошедшая перезагрузку, и расширения не запускаются повторно. В случае пересоздания образа виртуальной машины процесс аналогичен замене диска операционной системы на исходный образ. В этом случае повторно запускаются все специализации, например расширения, из последней модели.

Чтобы присоединить масштабируемый набор виртуальных машин к домену Active Directory, можно определить расширение.

Чтобы определить расширение, используйте свойство 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')]"
                }
            }
        }
    ]
}

Вы можете использовать расширение Desired State Configuration службы автоматизации Azure. При использовании операционной системы Windows Server 2012 R2 Azure запрашивает установку и перезагрузку Windows Management Framework (WMF) 5.0, а затем выполняет настройку.

Настройте защищенные параметры с помощью ключа и имени учетной записи хранения. Дополнительные сведения см. в статье Расширение пользовательских скриптов.

Вы можете:

• Измените модель масштабируемого набора виртуальных машин напрямую. Этот параметр доступен только в API 2017-12-01 и более поздних версиях.

  Обновите учетные данные администратора непосредственно в модели масштабируемого набора (например, с помощью обозревателя ресурсов Azure, PowerShell или CLI). После обновления масштабируемого набора у всех новых виртуальных машин будут новые учетные данные. Существующие виртуальные машины имеют только новые учетные данные, если они переимыкаются.

• Сбросьте пароль с помощью расширений доступа к виртуальной машине. Обязательно следуйте требованиям к паролю, как описано в разделе вопросов и ответов .

  При использовании расширения для доступа к виртуальной машине повторно создавать образ не требуется, так как расширение не обновляет пароль в модели. Расширение запускает скрипт, который добавляет пароль к паролю или к файлу ключа SSH. Расширение не удаляет исходный ключ SSH. После обновления расширения обновите экземпляры, чтобы применить обновления к имени пользователя и паролю на всех экземплярах виртуальной машины.

  Примечание.

  Если для политики автоматического обновления задано значение manual, вручную выберите экземпляр для выполнения операции обновления на отдельных экземплярах виртуальных машин. Если для параметра автоматического обновления задано значение Auto, расширение будет автоматически обновлено. Дополнительные сведения приведены в статье Автоматические обновления расширения

  Используйте следующий пример PowerShell для масштабируемого набора виртуальных машин 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
  

  Используйте следующий пример Azure CLI для масштабируемого набора виртуальных машин 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'}"
  

Да. Вы можете применить NSG непосредственно к масштабируемому набору, указав ее в разделе networkInterfaceConfigurations сетевого профиля. Приведем пример:

"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'))]"
                }
            }
        }
    ]
}

Если у вас есть два Масштабируемые наборы виртуальных машин с Azure Load Balancer, и они в одной подписке и регионе, вы можете освободить общедоступные IP-адреса от каждого из них и назначить другим. Пример приведен в статье VIP Swap: Blue-green deployment in Azure Resource Manager (Переключение виртуальных IP-адресов: сине-зеленое развертывание в Azure Resource Manager). Однако может возникнуть задержка, так как ресурсы освобождены или выделены на уровне сети. Другой, более быстрый вариант — воспользоваться Шлюзом приложений Azure с двумя серверными пулами и правилом маршрутизации. Также можно разместить приложение в Службе приложений Azure, которая обеспечивает быстрое переключение между промежуточными и рабочими слотами.

IP-адреса выбираются из указанной подсети.

Метод выделения IP-адресов масштабируемого набора виртуальных машин всегда динамический, но это не означает, что эти IP-адреса могут измениться. В этом случае под динамическим методом подразумевается лишь то, что вы не указываете IP-адрес в запросе PUT. Укажите статический набор на основе подсети.

См. статью "Развертывание масштабируемого набора виртуальных машин в существующей виртуальной сети".

Да. Чтобы использовать ускорение сети, в параметрах networkInterfaceConfigurations своего масштабируемого набора задайте для enableAcceleratedNetworkingзначение true. Например:

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

Чтобы создать масштабируемый набор виртуальных машин с настраиваемой конфигурацией DNS, добавьте dnsSettings пакет JSON в раздел масштабируемого набора networkInterfaceConfigurations . Приведем пример:

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

Чтобы создать масштабируемый набор виртуальных машин, который назначает общедоступный IP-адрес для каждой виртуальной машины, убедитесь, что версия API ресурса Microsoft.Compute/virtualMachineScaleSets — 2017-03-30 и добавьте publicipaddressconfiguration пакет JSON в раздел масштабируемого набора ipConfigurations . Приведем пример:

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

Да. Вы можете добавить идентификаторы ресурсов для нескольких пулов серверных адресов шлюза приложений в список applicationGatewayBackendAddressPools в разделе ipConfigurations сетевого профиля своего масштабируемого набора.

Одна из причин создания масштабируемого набора виртуальных машин с менее чем двумя виртуальными машинами заключается в использовании эластичных свойств масштабируемого набора виртуальных машин. Например, можно развернуть масштабируемый набор виртуальных машин с нулевыми виртуальными машинами, чтобы определить инфраструктуру без оплаты затрат на виртуальную машину. Затем, когда вы будете готовы к развертыванию виртуальных машин, можно увеличить емкость масштабируемого набора виртуальных машин до количества рабочих экземпляров.

Другая причина, по которой можно создать масштабируемый набор виртуальных машин с менее чем двумя виртуальными машинами, заключается в том, что при использовании группы доступности с дискретными виртуальными машинами. Масштабируемые наборы виртуальных машин вы можете работать с неифференцированными вычислительными единицами, которые являются взаимозаменяемыми. Эта единообразие является ключевым фактором для Масштабируемые наборы виртуальных машин и групп доступности. Многие рабочие нагрузки без отслеживания состояния не учитывают отдельные единицы. Если рабочая нагрузка снижается, вы можете уменьшить масштаб до одной единицы вычисления, а при увеличении нагрузки — снова увеличить количество этих единиц.

Чтобы изменить количество виртуальных машин в масштабируемом наборе виртуальных машин в портал Azure, в разделе "Свойства масштабируемого набора виртуальных машин" выберите область масштабирования и используйте ползунок.

Обработкой оповещений при достижении определенных пороговых значений можно управлять несколькими способами. Например, вы можете определить настраиваемые объекты webhook. Ниже приведен пример объекта webhook из шаблона 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"
                        }
                    }
                ]
            }
        ]
    }
}

Да, вы можете.

Да, ресурсы масштабируемого набора можно переместить в новую подписку или группу ресурсов.

Сведения об обновлении масштабируемого набора виртуальных машин до нового образа и управлении исправлениями см. в статье Об обновлении масштабируемого набора виртуальных машин.

Да. Операцию пересоздания образа можно использовать, чтобы сбросить параметры виртуальной машины, не изменяя образ. Однако если масштабируемый набор виртуальных машин ссылается на образ платформы, version = latestвиртуальная машина может обновиться до последующего образа операционной системы при вызове reimage.

Да, установив расширение Azure Monitor на виртуальных машинах масштабируемого набора. Ниже приведен пример использования Azure CLI:

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'}"

Необходимые данные workspaceId и workspaceKey можно найти в рабочей области Log Analytics портала Azure. На странице Обзор щелкните плитку Параметры. Откройте расположенную сверху вкладку Подключенные источники.

Чтобы включить диагностику загрузки, сначала создайте учетную запись хранения. Затем поместите этот блок JSON в масштабируемый набор virtualMachineProfileвиртуальных машин и обновите масштабируемый набор виртуальных машин:

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

После создания виртуальной машины в ее свойстве InstanceView отобразятся сведения для снимка экрана. Приведем пример:

"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"
}

Посетите страницу "Устранение распространенных проблем с Масштабируемые наборы виртуальных машин".

Вы можете вызвать ListVMInstanceViews, выполнив запрос REST API GET к следующему универсальному коду ресурса:

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

Домен сбоя не возвращается, если масштабируемый набор использует максимальное распространение (platformFaultDomainCount = 1), так как с этим параметром нет гарантии, сколько доменов сбоя будет использоваться.

Нет, нельзя. Однако расширения могут действовать на основе уникальных свойств виртуальной машины, на которую они работают, например на имени компьютера. Кроме того, расширения могут запрашивать метаданные экземпляра на сайте http://169.254.169.254, чтобы получить дополнительные сведения о виртуальной машине.

Пробелы связаны с тем, что свойство масштабируемого набора overprovision виртуальных машин имеет значение trueпо умолчанию. Если значение избыточной подготовки — true, создается большее количество виртуальных машин, чем запрашивалось. Лишние виртуальные машины удаляются. Это позволит повысить надежность развертывания, но за счет правил непрерывности для преобразования сетевых адресов и именования.

Для этого свойства можно задать значение false. Для небольших Масштабируемые наборы виртуальных машин надежность развертывания не будет существенно затронута.

Основное отличие заключается в том, что при deallocate виртуальные жесткие диски (VHD) не удаляются. При выполнении команды stop deallocate взимается плата за хранение. Причины выбора того или иного варианта заключаются в следующем:

• Вы хотите прекратить платить за вычислительные ресурсы, но сохранить состояние диска виртуальных машин.
• Вы хотите быстрее запустить набор виртуальных машин, чем можно масштабировать масштабируемый набор виртуальных машин.
  • Вы создали собственную подсистему автомасштабирования и хотите быстрее выполнить сквозное масштабирование (касательно этого сценария).
• У вас есть масштабируемый набор виртуальных машин, который неравномерно распределяется между доменами сбоя или доменами обновления. Это неравномерное распределение может быть связано с тем, что вы выборочно удалили виртуальные машины или из-за того, что виртуальные машины были удалены после избыточной подготовки. За stop deallocate которым следует start масштабируемый набор виртуальных машин, равномерно распределяет виртуальные машины между доменами сбоя или доменами обновления.

Создайте моментальный снимок из экземпляра масштабируемого набора виртуальных машин. Приведем пример:

$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

Создайте управляемый диск на основе моментального снимка. Приведем пример:

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