Часто задаваемые вопросы об Облачных службах Azure (расширенная поддержка)

• Облачные службы (классические): microsoft.classiccompute/domainnames
• Облачные службы (расширенная поддержка): microsoft.compute/cloudservices

Облачные службы (расширенная поддержка) доступны во всех регионах общедоступного и национального облака.

Клиентам потребуется запросить квоту, используя те же процессы, что и любой другой продукт Azure Resource Manager. Квота в Azure Resource Manager является региональной, и для каждого региона потребуется отдельный запрос квоты.

Облачные службы (расширенная поддержка) не поддерживает логическую концепцию размещенной службы, которая включала два слота (Рабочая и промежуточная). Каждое развертывание является независимым развертыванием Облачной службы (расширенная поддержка). Чтобы протестировать и разместить новый выпуск облачной службы, разверните облачную службу (расширенная поддержка) и пометьте ее как службу с возможностью переключения на виртуальный IP-адрес другой облачной службы (расширенная поддержка)

Концепция размещенных имен служб больше не существует, вы не можете создать пустую облачную службу (расширенную поддержку).

Нет, Облачные службы (расширенная поддержка) не поддерживает проверку Работоспособность ресурсов (RHC).

В метриках экземпляра роли изменений нет.

В конструировании, архитектуре или компонентах веб- и рабочих ролей изменений нет.

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

В проектировании, архитектуре или компонентах экземпляров ролей изменений нет.

В методе выпуска изменений нет. Облачные службы (классические) и Облачные службы (расширенная поддержка) получат одни и те же обновления.

Развертывание Облачных служб (расширенная поддержка) поддерживает только остановленное состояние с выделенным ресурсами, которое отображается как "Остановлено" на портале Azure. Остановлено— состояние deallocated не поддерживается.

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

Идентификатор развертывания, также известный как частный идентификатор, можно получить с помощью API CloudServiceInstanceView . Он также доступен на портале Azure в колонке Role and Instances (Роли и экземпляры) Облачной службы (расширенная поддержка).

Облачные службы (с расширенной поддержкой) используют Azure Key Vault и базовые (модель ARM) Общедоступные IP-адреса. Клиентам, которым требуются сертификаты, необходимо использовать Azure Key Vault для управления сертификатами (дополнительные сведения о ценах на Azure Key Vault).) Каждый общедоступный IP-адрес для Облачные службы (расширенная поддержка) взимается отдельно (дополнительные сведения о ценах на общедоступный IP-адрес).)

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

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

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

Key Vault, виртуальная сеть, общедоступные IP-адреса, группы безопасности сети и таблицы маршрутизации должны находиться в одном регионе.

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

Файлы шаблонов и параметров можно передавать в качестве параметров с помощью функции REST, PowerShell и CLI. Их также можно передать с помощью портала Azure.

Файлы шаблонов и параметров используются исключительно для автоматизации развертывания. Как и в случае с Облачными службами (классическими), сначала можно вручную создать зависимые ресурсы, а затем — развертывание Облачных служб (расширенная поддержка) с помощью PowerShell, команд CLI или портала с имеющимся CSDEF- и CSCFG-файлом.

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

Формат пакета CTP не поддерживается в Облачные службы (расширенная поддержка). Однако допускается ограничение размера расширенного пакета в 800 МБ.

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

Нет, развертывания Облачной службы (расширенная поддержка) привязаны к кластеру, как и Облачные службы (классические). Таким образом, ошибки распределения ресурсов будут по-прежнему существовать, если кластер полон.

Оценка необходимого времени и сложности миграции зависит от диапазона переменных. Планирование — это наиболее эффективный шаг для понимания объема работы, блокировщиков и сложности миграции.

Виртуальные сети являются обязательным ресурсом для любого развертывания в Azure Resource Manager. Развертывание Облачных служб (расширенная поддержка) должно находиться в виртуальной сети.

В Azure Resource Manager компоненты развертывания Облачных служб (расширенная поддержка) предоставляются в виде ресурса для лучшей видимости и упрощения контроля. В Облачных службах (классические) использовался тот же тип ресурсов, однако они были скрыты. Одним из примеров такого ресурса является общедоступный Load Balancer, который теперь является явным ресурсом только для чтения, создаваемым платформой автоматически.

Подсеть, содержащая развертывания Облачные службы (расширенная поддержка), невозможно предоставить общий доступ к развертываниям из других вычислительных продуктов, таких как Виртуальные машины, Виртуальные машины масштабируемые наборы, Service Fabric и т. д.

Облачные службы (расширенная поддержка) поддерживают методы распределения динамических и статических IP-адресов. Статические IP-адреса указываются в виде зарезервированных адресов в файле CSCFG.

Клиентам выставляются счета за использование IP-адресов в Облачных службах (расширенная поддержка) так же, как и пользователям выставляются счета за IP-адреса, связанные с виртуальными машинами.

Зарезервированный IP-адрес нельзя добавить, удалить или изменить во время обновления развертывания или обновления. Если необходимо изменить IP-адреса, используйте переключимую облачную службу или разверните два Облачные службы с именем CName в Azure DNS\Диспетчер трафика, чтобы ip-адрес можно было указать на любой из них.

Да. Облачным службам (расширенная поддержка) также можно присвоить DNS-имя. При использовании Azure Resource Manager метка DNS является дополнительным свойством общедоступного IP-адреса, назначенного Облачной службе. Формат DNS-имени для развертываний на основе Azure Resource Manager — <userlabel>.<region>.cloudapp.azure.com

№ Ссылка на виртуальную сеть при создании облачной службы является обязательной. Для имеющейся Облачной службы ссылку на виртуальную сеть невозможно изменить. Адресное пространство виртуальной сети можно изменить с помощью API-интерфейсов VNet.

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

№ Key Vault является региональным ресурсом и клиентам требуется по одному Key Vault в каждом регионе. Однако один Key Vault можно использован для всех развертываний в пределах заданного региона.

Да. Мы не разрешаем перекрестным ссылкам на хранилище ключей подписки в Облачные службы защищаться от эскалации атак привилегий через CS-ES. Подписка не является границей, которую CS-ES пересекает для ссылок на секреты. Причина, по которой не допускаются перекрестные ссылки на подписки, является важным заключительным этапом для предотвращения использования злоумышленниками CS-ES в качестве механизма повышения привилегий для доступа к секретам других пользователей. Подписка не является границей безопасности, но глубокая защита является обязательной. Тем не менее можно использовать расширение Key Vault для поддержки перекрестных сертификатов для подписок и регионов. Обратитесь к этой документации.

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

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

Этот сценарий не поддерживается с помощью Visual Studio. Разверните его с помощью PowerShell или портала.

Следующие шаги

Сведения о начале работы с Облачными службами (расширенная поддержка) см. в статье Развертывание Облачной службы (расширенная поддержка) с помощью PowerShell