У нас есть кластер из 75 узлов Win2k3, работающих в крупнозернистом вычислительном кластере. Кластер находится за горой брандмауэров и находится в собственной VLAN. Задания всех размеров и типов запускаются на кластере, и все исполняемые файлы запускаются на заказ.
(ред.: дополнительные примечания к нашим исполняемым файлам)Задания длятся от 30 секунд до 7 дней и могут содержать один исполняемый файл или 2000 подзаданий (короткой продолжительности). Очевидно, мы пытаемся избежать ситуации, когда наш ИТ-отдел планирует перезагрузку во время 7-дневного производственного задания.
У нас есть программное обеспечение для планирования, которое выполняет все обычные задачи для крупнозернистого кластера, и мы можем контролировать, какие машины активны для отправки и т. д. Если бы WSUS можно было каким-то образом запрограммировать (или клиент мог бы указать, что он готов к отключению), мы могли бы координировать работу двух систем и помогать.
В настоящее время график исправлений — воскресенье после Супервторника, независимо от того, что запущено на кластере. Нам приходится просить об исключении каждый раз, когда мы хотим отложить исправление машины для долгосрочного производственного задания. По сути, хотя наша группа отвечает за машины, мы мало контролируем график исправлений ИТ.
- Разумно ли ежемесячное обновление по графику MS для производственного кластера Windows?
- Есть ли в WSUS программные ловушки, с помощью которых можно было бы сказать: «Пожалуйста, не перезагружайтесь пока»?
решение1
1. Разумно ли ежемесячное обновление по графику MS для производственного кластера Windows?
Да, однако кластер не должен иметь простоев, связанных с исправлением, поскольку он должен перенести задания на другой узел. Я бы НЕ стал применять исправление ко всему кластеру одновременно (это было бы безумием).
2. Есть ли в WSUS программные хуки, с помощью которых можно было бы сказать: «Пожалуйста, пока не перезагружайтесь»?
У конечных пользователей нет возможности остановить обновление WSUS или перезагрузить его, но мне кажется, что у вас реальная проблема со связью между вашей группой и ИТ-группой. Тем не менее, вы должны иметь возможность терять по одному узлу за раз без существенного влияния на производительность.
решение2
Используя Config Mgr для управления развертыванием обновлений, вы можете остановить перезагрузку серверов. Таким образом, обновления применяются (но могут не вступить в силу до перезагрузки), и у ИТ-отдела будут отчеты, показывающие, какие серверы ожидают перезагрузки. Они могут легко предоставить вам этот список, и я ожидаю, что вы сможете легко вручную запланировать перезагрузки определенных узлов без слишком большого перерыва. ИТ-отдел может легко иметь отказоустойчивое развертывание (с принудительными перезагрузками) и также длительный срок выполнения, так что это в конечном итоге приведет к обновлениям и перезагрузкам, если вы не выполните свою часть сделки!
Для стандартных развертываний обновлений ИТ (и вы) вероятно захотите очень короткие сроки для полностью тихого развертывания (без перезагрузки), а также немного более длительное развертывание, которое не является тихим, поэтому вы увидите уведомление, если войдете на сервер. Ни одно из этих развертываний не должно принуждать к перезагрузке.
Вы все еще можете столкнуться с ситуацией, когда что-то дает сбой, например, библиотека или другой компонент кода были обновлены, когда не использовались, а затем использовались до того, как перезагрузка заставила остальные обновления вступить в силу.
Это эффективный способ получить то, что вы и ИТ хотите, и каждый из вас имеет некоторую видимость того, что происходит. Отчетность о том, какие серверы находятся в каком состоянии в соответствии с развертываниями, действительно полезна для вас обоих.
решение3
Похоже, ваш ИТ-отдел слишком часто использует подход «разговоров с рукой». Вам нужно усадить их (или подкупить пивом?), объяснить ситуацию и посмотреть, смогут ли они сделать что-то вроде создания нижестоящего сервера WSUS с ручным одобрением исправлений.
Настройки для WSUS устанавливаются групповыми политиками, они устанавливаются в Active Directory на уровне домена или OU. Если серверы находятся в корпоративном домене без отдельного OU, то они получают то же, что и все остальные, что звучит не совсем уместно.
Если вы не можете решить проблему с вашим ИТ-отделом, то удалите компьютеры из домена?