Введение

Такую серверную роль как Windows Server Update Services (WSUS) целесообразно использовать как в мелких компаниях, насчитывающих от 10 компьютеров, так и в крупных корпорациях. В отличие от таких серверных ролей, как доменные службы или серверов электронной почты, для серверов обновлений WSUS вам не обязательно разворачивать отказоустойчивые сервера, так как автоматизация обновления клиентских компьютеров не является самой критичной задачей в бизнес-процессах. Вам, как системному администратору стоит помнить о том, что базы данных таких серверов как WSUS необходимо регулярно архивировать для того, чтобы в случае неисправности или замены сервера вы могли все восстановить в течение одной недели. Так как обновления редко имеют статус критических, а на работе конечных пользователей сбой WSUS сервера никак не отразится, по большому счету, вы можете смело лишить ваших пользователей возможности синхронизации с сервером обновлений на несколько дней. В каждой организации есть смысл разворачивать сервера WSUS в зависимости от расположения подразделений и филиалов, количества пользователей, скорости сети и т.д. В этой статье вы узнаете об основных сценариях развертывания серверов обновлений.

Простое развертывание WSUS-серверов

Многие маленькие и средние организации в своей производственной среде для распространения обновлений, используют именно данную модель. Простые решения развертывания WSUS-серверов обычно представляют собой модель с развернутым сервером обновлений, который расположен внутри интрасети, защищенной межсетевым экраном и обслуживающим клиентские компьютеры интрасети. Для загрузки обновлений WSUS-сервер синхронизируется с серверами центра обновления Microsoft. Как было уже сказано выше, во время синхронизации WSUS определяет, не были ли выпущены новые обновления со времени последней синхронизации. Если же появились новые обновления, то они будут загружены в базу данных WSUS. А если синхронизация производится в первый раз, то WSUS-сервер загрузит все обновления, которые доступны для загрузки. Стоит обратить внимание на то, что в первый раз синхронизация может затянуться на несколько часов. После того как первая синхронизация будет завершена, на все последующие синхронизации будет затрачиваться значительно меньше времени. По умолчанию, для загрузки обновлений с серверов Microsoft, сервер WSUS использует или порт 80, или 443, соответственно, для протоколов HTTP или HTTPS. Помимо портов, используемых по умолчанию, вы также можете указать пользовательские порты, которые при необходимости вам придется открыть на внешнем межсетевом экране.

К клиентскому компоненту WSUS относится автоматическое обновление, которое использует тот порт, который вы назначаете в Microsoft Internet Information Services для сайта WSUS. В случае отсутствия такового сайта на сервере, где установлена роль WSUS, вы можете использовать или веб-сайт по умолчанию, который прослушивает автоматически обновления по 80 порту, или пользовательский веб-сайт, для которого WSUS использует порт 8530 или 8531. В том случае, если вы используете пользовательский веб-сайт, вам все равно нужно, чтобы на 80-ом порту  был развернут веб-сайт, который предназначен для размещения устаревших обновлений для автоматической установки обновлений клиентского программного обеспечения. Пример простого развертывания WSUS-серверов вы можете увидеть на следующей иллюстрации:

Рис. 1. Простое развертывание серверовWSUS

Для всех моделей развертывания серверов WSUS, и модель простого развертывания не исключение, важнейшей частью при развертывании являются группы компьютеров. В большинстве организаций, одновременно все обновления не развертываются на все компьютеры. А для управления компьютерами, которые будут получать обновления, серверы WSUS позволяют настраивать группы компьютеров, а сами обновления уже развертывать для одной или нескольких групп одновременно. По умолчанию, в консоли WSUS вы можете найти две группы компьютеров: «Все компьютеры» и «Не назначенные компьютеры». По умолчанию, когда клиентский компьютер синхронизируется с WSUS-сервером, он автоматом добавляется в обе группы, созданные по умолчанию. Затем, из группы «Не назначенные компьютеры», вы можете переместить компьютеры в специально отведенную для них группу, так как данная группа содержит только те компьютеры, для которых не было назначено членство в созданных вами группах. В свою очередь, группа «Все компьютеры» позволяет распространять целевые обновления на все компьютеры вашей организации, независимо от того, членами каких групп являются компьютеры. На следующей иллюстрации вы видите пример простого развертывания WSUS с тремя настраиваемыми группами, которые называются «Тестирование», «Пилотная группа» и «Производство». Группа тестирования содержит несколько компьютеров, которые находятся в лабораторной среде и предназначены для проверки корректности работы механизма распространения обновлений. Если тестирование проходит удачно, то обновления будут развертываться в следующей группе. После тестирования обновления разворачиваются в пилотной группе, которая состоит из компьютеров ИТ-отдела, где квалифицированные специалисты могут устранить появившиеся после развертывания обновлений неисправности. Затем, если пилотное развертывание прошло без инцидентов, то вы можете развертывать обновления на производственных компьютерах, которые расположены в среде «Производство».

Рис. 2. Развертывание с использованием групп компьютеров

Иерархическое развертывание WSUS-серверов

Как понятно с названия модели, предыдущая модель развертывания WSUS-серверов является базовой, но при необходимости вы можете создавать сложные иерархии серверов WSUS. Прежде всего, стоит учесть, что для синхронизации с центром обновлений Microsoft вам достаточно иметь только один WSUS-сервер, а все остальные WSUS-серверы должны подключаться к текущему. При связывании нескольких WSUS-серверов у вас образуется так называемая иерархия, состоящая из вышестоящего и подчиненного WSUS-серверов. Существует два способа установки связи между WSUS-серверами.

• Автономные серверыWSUS. В этом случае, в процессе синхронизации вышестоящий WSUS-сервер предоставляет все свои загруженные обновления одному или нескольким подчиненным серверам, но при этом процессе состояния утверждений или информация о группе компьютеров на клиентские рабочие места не передается. Администрирование всех подчиненных серверов WSUS выполняется отдельно от развертывания обновлений на клиентские компьютеры;
• Режим репликации. В случае развертывания данной модели, вышестоящий сервер WSUS передает все свои обновления, состояния утверждений и информацию о группах своим подчиненным серверам. При этом, подчиненные реплицируемые сервера наследуют все утверждения, причем они не могут выполнять административные задачи на своих вышестоящих WSUS-серверах.

Данная конфигурация развертывания серверов обновлений удобна для большинства производственных случаев, включая организации с филиалами. Модель иерархического развертывания WSUS-серверов рационально использовать для загрузки обновлений из центра обновлений Microsoft и последующей установки этих обновлений посредством подчиненных серверов, тем самым разгружая широкополосное соединение с Интернетом. Целесообразно использовать такую конфигурацию в окружении, где один WSUS-сервер не в состоянии самостоятельно обеспечить развертывание обновлений в существующем парке компьютеров. По всем рекомендациям желательно использовать не более чем трехуровневую иерархию WSUS-серверов, так как при последующем распространении обновлений время задержки постоянно увеличивается. В любой модели и при любой конфигурации, подчиненный сервер обязан регулярно выполнять синхронизацию с вышестоящим сервером обновлений, образуя между собой неподдерживаемый замкнутый цикл. При изменении протокола соединений между серверами, для обеспечения максимальной защиты всей цепочки серверов обновлений, во время настройки иерархии WSUS-серверов, для настройки автоматических обновлений вам нужно указать наиболее удаленный подчиненный сервер. В том случае, если в вашей организации насчитывается несколько подчиненных серверов обновлений, вам не стоит настраивать на них синхронизацию с вышестоящими серверами обновлений в одно и то же время, что может привести к перегрузке вышестоящего сервера. Для этой конфигурации лишь один WSUS-сервер загружает и управляет обновлениями непосредственно с серверов Microsoft, а все остальные серверы конфигурируются как реплики. Реализацию иерархического развертывания серверов обновлений вы можете увидеть на следующей иллюстрации:

Рис. 3. Режим репликацииWSUS-серверов

Развертывание WSUS-серверов для пользователей, которые не подключены к сети Интернет

Как все мы прекрасно знаем, далеко не во всех организациях у всех пользователей есть доступ к сети Интернет и, соответственно, именно эти пользователи не в состоянии выполнять автоматические обновления своих операционных систем непосредственно из Интернета. Для того чтобы получать последние обновления, для вас нет необходимости предоставлять такой группе пользователей доступ в Интернет, так как вы можете развернуть конфигурацию, которая вкратце описана в данном подразделе. Для обеспечения предоставления последних обновлений этим пользователям, вам нужно развернуть дополнительный подчиненный WSUS-сервер в сегменте сети, в котором отсутствует доступ к сети Интернет. В этом случае, развертывание обновлений будет обеспечиваться следующим образом: сервер, который синхронизируется с центром обновления Microsoft, подключен к сети Интернет, но должен быть изолирован от интрасети. После загрузки обновлений на данном сервере выполняется экспорт обновлений на внешний дисковый накопитель, а затем путем подключения внешнего накопителя к подчиненному серверу вы импортируете все загруженные ранее обновления. Такое решения также выгодно применять в организациях с высокой стоимостью и низкой пропускной способностью Интернет-канала. Если для поддержки клиентов во множестве офисов используется лишь один WSUS-сервер, то каждому клиентскому компьютеру придется загружать обновления через подключения WAN. Со временем, размеры файлов и пакетов обновлений достигнут сотен мегабайт, и так как пропускная способность WAN обычно значительно ниже пропускной способности локальной сети организации, регулярная загрузка больших пакетов может негативно повлиять на производительность всей сети организации. Экспортирование загруженных обновлений с последующим импортом последних на подчиненные WSUS-сервера позволит вам значительно разгрузить Интернет-канал. Данное решение проиллюстрировано ниже:

Рис. 4. РазвертываниеWSUS-серверов для пользователей, которые не подключены к сети Интернет

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

Рис. 5. Балансировка сетевой нагрузки с отказоустойчивымSQL-кластером

Модели управления серверами обновлений

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

Централизованное управление

В основе централизованного управления серверами обновлений лежит принцип управления серверами на основе реплик. Вы не можете управлять непосредственно подчиненными серверами, так как они используются только для распространения утвержденных обновлений на указанные вами группы. Все настраиваемые группы и утверждения обновлений настраиваются на вышестоящем WSUS-сервере, которые затем распространяются на все подчиненные серверы в организации. Часто можно встретить такую ситуацию, когда не все сайты вашего леса нуждаются в создании групп компьютеров. Основная цель централизованного управления заключается в том, чтобы вы создали на управляемом сервере такое количество групп компьютеров, которое удовлетворит потребности всего парка компьютеров вашей организации. Несмотря на то, что компьютеры могут перемещаться по любым отделам или даже офисам вашей организации, группы компьютеров, созданные на управляемом сервере всегда должны оставаться без каких-либо изменений, причем, все обновления должны осуществляться на главном (вышестоящем) управляемом сервере. Помимо всего сказанного ранее, на вышестоящем WSUS-сервере вам нужно указать такое количество языков для загружаемых с серверов Центра обновлений Microsoft обновлений, какое будет распространяться на все реплики в вашей организации. Схема централизованного управления серверами обновлений изображена на следующей иллюстрации:

Рис. 6. Пример централизованного управления серверами обновлений

Распределенное управление

Распределенное управление WSUS-серверами позволяет вам полностью распределить контроль над всеми утверждениями и группами компьютеров между всеми филиалами организации. При помощи данной модели можно указать индивидуальные языки для обновлений, группы компьютеров, добавлять компьютеры в настраиваемые группы для каждого сайта, а также распространять для соответствующих компьютеров обновления только внутри зоны действия своего WSUS-сервера. Модель распределенного управления серверами обновлений является настройкой по умолчанию при установке каждого WSUS-сервера. Пример реализации данной модели показан ниже:

Рис. 7. Пример распределенного управления серверами обновлений

Об  авторе:

Дмитрий Буланов отвечает на вопросы участников конференции OSZone.net в форумах операционных систем Microsoft. Его статьи на сайте OSZone.net можно найти по этой ссылке. С декабря 2008 года Дмитрий ведет свой блог, посвященный клиентским и серверным операционным системам Microsoft.

В апреле 2010 года был награжден премией Microsoft Most Valuable Professional (MVP), присуждаемой за вклад в развитие технических сообществ. Также в 2010 году он получил статус MC ITP (Microsoft Certified IT Professional), сдав 3 экзамена Microsoft, после чего старается регулярно сертифицироваться по разным технологиям.

С 1 января 2011 года он ведет свой микроблог в Твиттере.

Вы можете задать Дмитрию любой полностью анонимный вопрос здесь.

Скачать Hyper-V Server вы сможете по этому адресу: https://www.microsoft.com/ru/ru/softmicrosoft/HyperVS2008r2SP1.aspx

Скачать Windows Server 2008 R2 SP1 вы сможете по этому адресу: https://www.microsoft.com/ru/ru/softmicrosoft/server2008.aspx