В большинстве случаев вам действительно не нужно беспокоиться об обновлениях на уровне узла, поскольку среда выполнения SF обрабатывает их внутренне, если настроена в режиме мониторинга. Это то, что мы использовали с большим успехом, и нам никогда особо не приходилось делать. Это также соответствует нашему требованию о том, что все домены (узлы) обновления должны соответствовать нашим политикам состояния работоспособности, прежде чем считаться работоспособными.
Если вы хотите иметь более расширенный контроль над своими обновлениями, например, с помощью дренажа запросов et c, используйте посмотрите информацию , как указано здесь . Но, честно говоря, мы были вполне довольны тем, что просто использовали контролируемый режим и выясняли, почему что-то не работает, если это происходит. У нас было несколько приложений, которые долго выполняли фоновую задачу в качестве актора с отслеживанием состояния, которая иногда не выполнялась при обновлении, и чаще всего это было связано с проблемой, которая была вызвана самой фоновой задачей, а не чем-либо, связанным с Service Fabri c.
Служба Fabri c знала, когда не выполнялись активные соединения и фоновые задачи, чтобы затем обновить узлы, и мы действительно могли видеть узлы, которые временно «зависли» из-за ожидания завершения sh активной фоновой задачи.