Блог

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

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

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

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

У меня похожая ситуация, которую вы могли бы счесть полезной:

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

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