Часто задаваемые вопросы о 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). Виртуальные машины распределяются между доменами сбоя.

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

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

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

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

Пароли не нужно жестко определять в скриптах. Их можно динамически извлечь на основе разрешений, используемых для выполнения скрипта развертывания. При выполнении скрипта, который перемещает сертификат из хранилища секретов в хранилище ключей, команда 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 на вершине СРБ. Оба компонента входят в состав вычислительной платформы в дереве службы 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, 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. Ниже приведен пример объекта 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": [
                        "[email protected]"
                    ]
                },
                "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, создается большее количество виртуальных машин, чем запрашивалось. Лишние виртуальные машины удаляются. Это позволит повысить надежность развертывания, но за счет правил непрерывности для преобразования сетевых адресов и именования.

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