Автоматическое масштабирование Azure. Уменьшение после завершения процесса в экземпляре

Question

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

Проблема возникает, когда масштабирование и лазурь устраняют хосты;есть ли способ для него масштабировать только в экземпляре, когда этот экземпляр выполняет свою задачу?

Answer 1

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

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

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

Answer 2

Kwill, спасибо за ссылки / информацию, верхний элемент во второй ссылке был лучшим компромиссом.

Продолжительность работы процесса обычно составляла менее 5 минут, и служба уже имела повторную обработку сбойных процессов.поэтому после некоторого исследования было решено отслеживать состояние, когда служба обрабатывает элемент очереди, и использовать цикл while в событии RoleEnvironment.Stopping , чтобы отложить события перезапуска и масштабирования, пока процесс не получилшанс закончить.

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

Answer 3

Нет способа сделать это автоматически.Azure всегда будет масштабироваться с наибольшим числом экземпляров.

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

Сказав это, вы можете вручную создать решение для масштабирования, которое удаляет только те экземпляры, которыене выполнять работу, но для этого потребуется немало кода с вашей стороны.По сути, вы будете использовать механизм сигнализации, работающий в каждом экземпляре, который позволит некоторому внешнему сервису (приложению логики или WebJob или что-то в этом роде) узнать, когда экземпляр свободен или занят, и что внешний сервис может удалить свободные экземпляры с помощью роли удаленияAPI экземпляров (https://docs.microsoft.com/en-us/rest/api/compute/cloudservices/rest-delete-role-instances).

Подробнее об этой теме см .:

• Как остановить один экземпляр / виртуальную машину WebRole / WorkerRole
• Масштаб Azure в масштабах убийств в случаях использования