Определить, заняты ли другие экземпляры ролей и/или исправлены ли они?

На основе этого вопроса/ответа на StackOverflow, Я хочу, чтобы один экземпляр Azure запускал определенный код одновременно, а не каждый экземпляр запускал код.

Однако я не могу найти, как определить, заняты ли роли, которые все еще находятся в RoleEnvironment.CurrentRoleInstance.Role.Instances, и/или исцеляются. Мне нужно это, чтобы передать контроль над запуском моего кода другому экземпляру, если он выйдет из строя.

RoleInstance, похоже, не имеет никаких свойств для определения текущего статуса роли.


azure c# azure-role-environment azure-sdk-.net
person David Pfeffer    schedule 22.08.2013    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

У меня есть пример кода и описание в моем блоге по адресу: http://brentdacodemonkey.wordpress.com/2012/07/27/the-traffic-cop-pattern/

person BrentDaCodeMonkey    schedule 22.08.2013
comment
У smarx есть библиотека для этого. Однако меня беспокоит то, что происходит при сбое службы хранилища Azure, как это случалось в прошлом. - person David Pfeffer; 22.08.2013
comment
Уже есть несколько зависимостей от Storage, так что еще один. В худшем случае с этим шаблоном действие просто не будет выполнено, так как ни один из экземпляров не сможет установить аренду. - person BrentDaCodeMonkey; 22.08.2013
comment
У меня нет никаких зависимостей от хранилища в моем приложении. - person David Pfeffer; 22.08.2013
comment
Вы можете не указывать, но существуют взаимозависимости между различными службами Windows Azure. С PaaS ваша диагностическая информация сохраняется в хранилище, плюс ваши развертывания также зависят от хранилища (там размещаются cspkg). Таким образом, если произошел сбой хранилища (был только один глобальный сбой, и он затронул только HTTPS-трафик), вы, скорее всего, потеряете возможность развертывания новых обновлений облачных служб, и существует риск того, что если обновление экземпляры могут не запускаться должным образом (например, изменения топологии, от которых вы зависите). - person BrentDaCodeMonkey; 22.08.2013
comment
Справедливо. Меня все еще интересует прямой ответ на мой вопрос, но я, вероятно, в конечном итоге реализую вашу методологию для своего программного обеспечения. - person David Pfeffer; 22.08.2013
comment
Я считаю, что вы можете получить состояние из Management API. msdn.microsoft.com/en-us/library/windowsazure/ee460806. aspx Если для свойства imbedded-detail установлено значение true, вы заметите, что возвращаете состояние всех экземпляров в службе. Если это ТОЛЬКО текущий экземпляр, о котором вы беспокоитесь, вы можете отслеживать свой собственный статус на основе других событий, которые присутствуют в RoleEntryPoint. Вы будете событиями проблем, которые вы можете перехватывать/отвечать на такие вещи, как Stopping Starting, и вы контролируете занятой ответ через событие RoleEnvironmentStatusCheck. - person BrentDaCodeMonkey; 22.08.2013
comment
На самом деле я пробовал стратегию блокировки больших двоичных объектов раньше, но я также всегда сталкивался с этой проблемой: stackoverflow.com/questions/8057951/ - person David Pfeffer; 22.08.2013

arrow_upward
0
arrow_downward

Вы пробовали подход на основе служебной шины? вставьте задачу, которую нужно выполнить, в тему. Экземпляр может создать подписку с именем на основе номера экземпляра. (который вы можете получить из RoleEnvironment.CurrentInstance.Id). Таким образом, даже если экземпляр выйдет из строя, сообщение все равно будет доставлено в подписку, чтобы экземпляр мог получить его после восстановления.

Подписки также могут быть отфильтрованными подписками на основе данных о сообщении.

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

person Dennis Burton    schedule 22.08.2013
comment
Мне нужно, чтобы сервис был высокодоступным. - person David Pfeffer; 22.08.2013