Microsoft Azure Master-Slave рабочие роли

Question

Я пытаюсь перенести приложение на платформу Azure. Я хочу запустить существующее приложение несколько раз. Моя первоначальная идея заключается в следующем: у меня есть master_process. У меня много slave_processes. Каждый процесс является рабочей ролью в Azure. Каждый slave_process будет запускать экземпляр приложения независимо. Я хочу, чтобы master_process запускал много slave_processes и предоставлял им входные аргументы. В конце master_process соберет результаты. В настоящее время у меня есть рабочая установка для вызова всего приложения из оболочки C #. Итак, для успеха мне нужны две вещи: во-первых, я должен найти способ запустить рабовладельцев внутри мастер-работника (точно так же, как потоки). Во-вторых, мне нужно найти способ хранить результаты работы подчиненных и получать эти файлы результатов от главного работника. Кто-нибудь может мне помочь?

Answer 1

У меня похожая ситуация, которая может оказаться полезной:

У меня есть большой последовательный пакетный процесс, который я запускаю в Azure, который требует предварительной и последующей обработки. Техника, которую я использовал, состояла в том, чтобы использовать экземпляры одной многофункциональной рабочей роли, но использовать «кворум» для назначения главного узла, который затем контролирует рабочий процесс.

Они, как я, используют в качестве кворума лазурную страницу блоб (в основном своего рода глобальный мьютекс / блокировку), потому что когда узел захватывает его для записи, он блокируется. Для обеспечения устойчивости в случае возникновения проблемы с головным узлом все узлы иногда пытаются восстановить кворум.

Answer 2

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

У меня был бы только один тип рабочей роли, который выполняет существующую логику, и столько экземпляров этой рабочей роли, которые вы определили, которые вам понадобятся. Какой бы ни был ваш клиент, он решит, что ему нужно разбить работу на определенное количество частей, скажем, 10 для аргументации. Каждому фрагменту работы будет присвоен идентификатор (например, гид), а затем помещено 10 сообщений, содержащих параметры и идентификатор, в очередь. Экземпляры вашей рабочей роли извлекают сообщения из очереди, выполняют свою работу и записывают свои результаты в хранилище (SQL Azure, хранилище таблиц Azure или, возможно, даже хранилище больших двоичных объектов в зависимости от результатов). Клиент опрашивает это хранилище, чтобы дождаться завершения всех результатов, а затем продолжает работу.

Если это процесс, который запускается редко, то вместо того, чтобы рабочие роли были развернуты постоянно, вы можете использовать тот же метод, который я описал, но в дополнение получите код клиента для deploy рабочие роли при запуске и затем удаление их по завершении через API управления. Есть образцов на MSDN о том, как использовать это.