Разработка Azure - как остановить экземпляр веб-роли

Question

Мне нужно проверить, как мой код будет обрабатывать сбой экземпляра веб-роли в среде разработки.

Как завершить один из экземпляров?Я не вижу никакой опции в пользовательском интерфейсе для этого.Похоже на странное упущение

Обновление

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

Возможно, мой реальный вопрос:

Насколько актуален RoleEnvironment.CurrentRoleInstance.Role.Instances

Answer 1

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

Я подозреваю, что лучший способ симулировать неудачу - это убить процессы.Если вы откроете диспетчер задач (или лучше Process Explorer), вы увидите «WatDebugger», на котором размещены «WaIISHost» или «WaWorkerHost».Если вы убьете этот процесс, я думаю, что он симулирует сбой.

Честно говоря, проще протестировать этот процесс в облаке.Вы можете включить RDP в один из экземпляров и уничтожить процесс WaAppAgent.Это убьет ваш RoleEntryPoint и агент контроллера ткани.Это будет настоящая неблагодарная неудача.

Answer 2

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

Answer 3

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

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

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

Есть еще один вопрос, касающийся состояния сеанса, который должен помочь: Как Microsoft Azure обрабатывает состояние сеанса?