Назад | Перейти на главную страницу

График исправлений Sane для кластера Windows 2003

У нас есть кластер из 75 узлов Win2k3, работающих в крупномасштабном вычислительном кластере. Кластер находится за горой межсетевых экранов и находится в собственной VLAN. В кластере выполняются задания всех размеров и типов, и все выполняемые исполняемые файлы создаются по индивидуальному заказу.

(ред: дополнительные примечания к нашим исполняемым файлам) Задания имеют продолжительность от 30 секунд до 7 дней и могут содержать одно исполняемое или 2000 подзадач (краткосрочных). Очевидно, мы пытаемся избежать ситуации, когда наши ИТ-специалисты планируют перезагрузку в течение 7 дней производственной работы.

У нас есть программное обеспечение для планирования, которое включает в себя все обычные задачи для крупнозернистого кластера, и мы можем контролировать, какие машины активны для отправки и т. Д. Если WSUS каким-либо образом был скриптовым (или клиент мог заявить, что он доступен для завершения), мы могли бы координировать две системы и выручайте.

В настоящее время расписание исправлений - воскресенье после супервторника, независимо от того, что выполняется в кластере. Нам приходится запрашивать освобождение каждый раз, когда мы хотим отложить исправление машины для длительной производственной работы. По сути, хотя наша группа отвечает за машины, мы мало контролируем график исправлений ИТ.

  1. Разумно ли ежемесячно вносить исправления по расписанию MS для производственного кластера Windows?
  2. Есть ли программные перехватчики в WSUS, где мы могли бы сказать: «Пожалуйста, пока не перезагружайтесь»?

Используя Config Mgr для управления развертыванием обновлений, вы можете остановить перезагрузку серверов. Таким образом, обновления применяются (но могут не вступать в силу до перезагрузки), и ИТ-специалисты будут иметь отчеты, показывающие те серверы, которые ожидают перезагрузки. Они могут легко предоставить вам этот список, и я надеюсь, что вы легко сможете вручную запланировать перезагрузку определенных узлов без особых перерывов. ИТ-отдел может легко обеспечить отказоустойчивое развертывание (с принудительной перезагрузкой) и длительный срок, так что в конечном итоге это приведет к принудительным обновлениям и перезагрузкам, если вы не сможете выполнить свою часть сделки!

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

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

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

1. Разумно ли ежемесячно вносить исправления по расписанию MS для производственного кластера Windows?

Да, однако кластер не должен иметь простоев, связанных с исправлением, поскольку он должен приводить к сбою задания на другой узел - я НЕ буду исправлять весь кластер одновременно (это было бы безумием)

2. Есть ли в WSUS программные хуки, на которых можно было бы сказать: «Пожалуйста, пока не перезагружайтесь»?

Конечные пользователи не могут остановить обновление или перезагрузку WSUS, но мне кажется, что у вас есть реальная проблема связи между вашей группой и ИТ-группой; однако вы должны иметь возможность терять по 1 узлу за раз с небольшим влиянием на производство.

Похоже, ваш ИТ-отдел постоянно говорит о вас. Вам нужно усадить их (или подкупить их пивом?), Объяснить свою ситуацию и посмотреть, смогут ли они сделать что-то вроде создания подчиненного сервера WSUS с ручным утверждением исправлений.

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

Если вы не можете решить проблему со своим ИТ-отделом, удалите компьютеры из домена?