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

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

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

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

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

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

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

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

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

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

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

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

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

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

Azure автоматически заменяет неработоспособные экземпляры на основе сигналов проб работоспособности или расширений работоспособности приложений.

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

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

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

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

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

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

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

Для очереди Service Bus используйте следующий формат 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 и Быстрый старт работы с Azure Monitor в мультиплатформенном CLI.

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

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

В качестве метрики, для которой будут устанавливаться оповещения, можно выбрать любой счетчик производительности виртуальной машины. Дополнительные сведения см. в разделе Метрики гостевой ОС для виртуальных машин под управлением 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-адрес и имя хранилища секретов) в список, связанный с хранилищем.

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

Пароли не нужно жестко кодировать в скриптах. Их можно динамически извлечь на основе разрешений, используемых для выполнения скрипта развертывания. При наличии скрипта, который перемещает сертификат из хранилища секретов (key vault), команда 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 перезагрузка всех виртуальных машин завершается сбоем. Эта ошибка возникает, так как поставщик вычислительных ресурсов пытается получить секрет из хранилища ключей, но он больше недоступен. Чтобы устранить эту проблему, можно удалить сертификаты из модели масштабируемого набора виртуальных машин.

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

Эта проблема не возникает во время горизонтальной операции масштабирования, так как кэшируемая копия секрета сохраняется в Azure Service 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 поверх CRP. Оба компонента входят в состав вычислительной платформы в дереве службы Azure.

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

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

Да. Дополнительные сведения см. в обзоре управляемых удостоверений. Некоторые примеры шаблонов управляемого удостоверения службы (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, Azure автоматически обновляет расширения на всех виртуальных машинах. Однако если 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политика автоматического обновления, необходимо вручную выбрать и обновить отдельные экземпляры виртуальных машин. Если задано Automaticзначение, расширение обновляется автоматически. Дополнительные сведения см. в разделе "Автоматическое обновление расширений".

  Используйте следующий пример 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-адреса. Для этого освободите общедоступный IP-адрес от каждого масштабируемого набора и переназначьте его другому. Дополнительную информацию см. в статье VIP Swap: Blue-green deployment in Azure Resource Manager (Переключение виртуальных IP-адресов: сине-зеленое развертывание в Azure Resource Manager). Вы можете столкнуться с задержкой, так как ресурсы освобождаются или выделяются на уровне сети. Другой, более быстрый вариант — воспользоваться Шлюзом приложений Azure с двумя серверными пулами и правилом маршрутизации. Также можно разместить приложение в Службе приложений Azure, которая обеспечивает быстрое переключение между промежуточными и рабочими слотами.

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

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

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

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

"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-адрес для каждой виртуальной Microsoft.Compute/virtualMachineScaleSets машины, убедитесь, что версия API ресурса — 2017-03-30и добавьте publicipaddressconfiguration пакет JSON в раздел масштабируемого набора ipConfigurations . Приведем пример:

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

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

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

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

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

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

Обработкой оповещений при достижении определенных пороговых значений можно управлять несколькими способами. Например, вы можете определить настраиваемые вебхуки. Ниже приведен пример объекта 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 на следующем URI ресурса: /subscriptions/<subscription_id>/resourceGroups/<resource_group_name>/providers/Microsoft.Compute/virtualMachineScaleSets/<scaleset_name>/virtualMachines?$expand=instanceView&$select=instanceView

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

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

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

Для этого свойства можно задать значение 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')