Перевод http://blogs.msdn.com/b/kwill/archive/2013/02/28/heartbeats-recovery-and-the-load-balancer.aspx. Ниже приведены ответы на наиболее популярные вопросы, которые я получал о heartbeats/probes, о том, как Fabric-контроллер производит восстановление после проб с ошибками и о том, как балансировщик управляет трафиком, идущим на экземпляры.

В: Как Fabric узнает, что с экземпляром произошла ошибка? Что он предпринимает для его восстановления? О: Для проверки здоровья экземпляра происходит череда проб, забирающих сведения о здоровье, со стороны Fabric, в следующей последовательности: Fabric <-> Агент на хосте <-> Агент на госте (WaAppAgent.exe) <-> Host Bootstrapper (WaHostBootstrapper.exe) <-> Процесс хоста (обычно WallSHost.exe или WaWorkerHost.exe).
а. Если ошибка с пробой происходит на стадии Fabric <-> Агент на хосте, то Fabric пытается перезагрузить хост. У Fabric есть определенные методы, которые используются по отношению к хосту в том случае, если перезагрузка не помогла решить проблему, а именно - более агрессивные действия по решению проблем вплоть до того, что Fabric может пометить сам сервер как дефектный - в этом случае будет создан новый хост на совершенно новом сервере, после чего на нем будут запущены все проблемные гостевые виртуальные машины. б. Если ошибка с пробой происходит на стадии Агент хоста <-> Гостевой агент, то хост пытается перезагрузить гостевую операционную систему. В этом случае также присутствуют дополнительные методы, вплоть до запуска гостевой виртуальной  машины на новом сервере. Если проба на стадии Хост <-> Гость успешна, то Fabric больше не предпринимает никаких действий, предоставляя агенту на госте восстанавливать все остальное. с. Единственное действие по восстановлению, которое предпринимает агет на госте, это перезапуск стека хоста (WaHostBootstrapper и все потомки). Если проба проваливается по таймауту, то агент на госте предполагает, что процесс хоста чем-то занят и оставляет его. Агент на госте не будет перезагружать виртуальную машину.
В: Как балансировщик нагрузки определяет, что экземпляр нездоров? О: Есть два механизма определения балансировщиком состояния здоровья экземпляра, а также того, включать ли этот экземпляр в механизм балансировки нагрузки (round robin) и ротации трафика.
а. Механизм, который используется по умолчанию, это пробы, которые отправляются балансировщиком агенту гостя, в которых запрашивается состояние здоровье экземпляра. Если агент гостя возвращает что-то, непохожее на "Ready", то балансировщик помечает экземпляр как нездоровый (unhealthy) и убирает его из ротации трафика и балансировки нагрузки. б. Другой механизм - определение собственного механизма LoadBalancerProbe внутри определения сервиса разработчика. LoadBalancerProbe предоставляет разработчику гораздо больший контроль над тем, как балансировщик опрежелеяет здоровье экземпляра, и позвлояет разработчику более аккуратно реагировать и отображать статус сервиса. Тут нужно, однако, убедиться, что путь к пробе не является простой HTML-страницей, но включает какую-то логику определения здоровья сервиса (например, подключение к SQL Server).
В: Что делает балансировщик нагрузки, когда экземпляр нездоров?

О: Балансировщик маршрутизирует входящие TCP-подключения к эезмплярам, которые находятся в ротации, а именно тем, кто возвращает состояние "Ready" (для тех ролей, которые не имеют собственного LoadBalancerProbe), и тех, кто возвращает 200 или TCP ACK из LoadBalancerProbe. Если экземпляр устраняется из ротации, балансировщик не прерывает существующие TCP-подключения, поэтому, если уже есть обмен данными между клиентом и сервером, то балансировщик не прервет подключения между клиентом и сервером-экземпляром, выкинутым из ротации. Если TCP-подключение прерывается сервером (например, виртуальная машина перезагружает процесс, который использует это подключение), то клиент должен переподключиться, и в это время получивший новый TCP-запрос балансировщик маршрутизирует этот запрос на экземпляр в ротации. Обратите внимание, что для развертываний �� одним экземпляром балансировщик рассматривает этот экземпляр как всегда находящийся в ротации, поэтому вне зависимости от его статуса и здоровья балансировщик будет направлять запросы и трафик на этот экземпляр.  

В: Как можно определить, что экземпляр роли был переработан (recycled) или перенесен на новый сервер? О: Нет прямого способа определения того, что экземпляр был переработан. Fabric инициирует перезагрузку, например, для обновления операционной системы, и инициирует события Stopping/OnStop, но в случае непредвиденных перезагрузок и выключений эти события вызваны не будут. Есть определенные стратегии для отслеживания этих событий:
а. Наиболее распространенный способ - запись в лог в методе RoleEntryPoint.OnStart. Если вы неожиданно увидите этот лог, то это будет значить, что экземпляр роли был переработан. б. Если экземпляр был перенесен на новый сервер или виртуальную машину, то на всех других ролях и экземплярах инициируются события Changing/Changed типа RoleEnvironmentTopologyChange. Это происходит только при имеющихся определенных InternalEndpoint. InternalEndpoint также определяются неявно при включенном RDP. в. Логи агента гостя содержат данные о всех перезагрузках, как запланированных так и нет, но эти логи не документируются и интерпретировать их - нетривильная задача. Но, если использовать первую стратегию, то можно ориентироваться на временной штамп. г. Логи host bootstrapper содержат информацию об ошибках со startup-задачами и процессами хоста