Как прекратить работу конкретного экземпляра рабочей роли Azure

Question

Фон

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

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

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

Идея 1 :Я решаю, какой экземпляр остановить, и возвращаюсь из его Run ().Затем я говорю Azure уменьшить количество экземпляров на единицу и надеюсь, что он сделает вывод, что сломанный экземпляр - хороший кандидат.Кто-нибудь пробовал что-нибудь подобное?

Идея 2 : я заранее определил целую кучу разных рабочих ролей с одинаковым содержанием.Я могу по отдельности остановиться и запустить их, переключив количество экземпляров с нуля на единицу и обратно.Я думаю, что эта идея сработает, но мне она не нравится, потому что она, кажется, идет вразрез с естественным способом ведения дел в Azure, и потому что она требует от меня большого количества дополнительной бухгалтерии для управления дополнительными рабочими ролями.

Идея 3 : жить с этим.

Есть идеи получше?

Answer 1

В ответ на ваши идеи

Идея 1: Я не пытался делать именно то, что вы описываете, но по моему опыту у вашего первого экземпляра есть имя, которое заканчивается на _0, следующий _1, и я уверен, что вы можете угадать все остальное.Когда вы уменьшаете количество экземпляров, оно сбрасывает экземпляр с суффиксом наибольшего числа.Я был бы удивлен, если бы он учитывал состояние какого-либо конкретного экземпляра.

Идея 2: Как я думаю, вы намекаете на это, это создаст проблемы управления.Вы можете иметь только 5 разных работников на один размещенный сервис, поэтому вам понадобится сервис для каждой группы из 5 ролей, которые вы хотите масштабировать.Кроме того, при развертывании обновлений вам придется загружать в X раз больше сервисов, где X - максимальное количество поддерживаемых в данный момент экземпляров.

Идея 3: Технически проще всего.В ожидании некоторых разъяснений, это, вероятно, то, чем я сейчас буду заниматься.Чтобы уменьшить недостатки этой опции, стоит изучить способы более быстрой загрузки данных.Обычно в этом есть уровень параллелизма Златовласки (не слишком много, не слишком мало).

Answer 2

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

Если вам действительно нужно запустить заданиеВ одном случае (например, в планировщике) рассмотрите возможность использования блоб-аренды в качестве способа ограничения этого.Создайте блоб как мьютекс.Затем, когда каждый экземпляр раскручивается, задание планировщика пытается получить аренду записи для этого большого двоичного объекта.Если это удастся, это бежит.Если это не удается, он просто спит (возможно, на минуту) и пытается снова.В какой-то момент в будущем, когда вы уменьшите количество экземпляров, предположим, что экземпляр, на котором запущен планировщик, уничтожен.Спустя минуту (или любой другой промежуток времени, который вы выберете), другой экземпляр пытается получить аренду, завершается успешно и теперь запускает код планировщика.