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

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

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

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

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

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

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

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

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

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

Изменения в проектировании, архитектуре или компонентах экземпляров роли отсутствуют.

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

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

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

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

Облачные службы (расширенная поддержка) использует Общедоступные IP-адреса Azure Key Vault и Базовый (Azure Resource Manager). Клиентам, которым требуются сертификаты, необходимо использовать 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 виртуальной сети.

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

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

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

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

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

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

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

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