Thursday, November 23rd, 2017

Децентрализованное управление обновлениями (Patch Management)

Published on Февраль 19, 2009 by   ·   Комментариев нет

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

За последние несколько лет, кажется, что термин “централизованное управление обновлениями” звучал повсюду. В большинстве случаев, централизованное управление обновлениями означает один сервер, который отвечает за установку обновлений по всей организации. Централизованное управление изменениями звучит хорошо в теории, но существуют некоторые организации, в которых централизованное управление изменениями – это всего лишь хорошая идея. Например, централизованное управление изменениями плохо применимо в больших организациях, или в организациях, которые разнесены географически. В этой статье я расскажу о некоторых альтернативных соглашениях для организаций такого типа.

Почему не стоит использовать централизованное управление обновлениями?

В последнем параграфе я упоминал, что централизованное управление изменениями может плохо применяться в больших организациях или в организациях, которые разнесены географически. Для начала я хочу объяснить, почему так происходит. В больших организациях это просто вопрос запросов и поддержки. Единственный сервер, управляющий установкой обновлений, вероятно, будет не в состоянии удовлетворить все запросы в большой корпоративной сети.

Например, представьте, что Microsoft выпускает новое обновление для безопасности (security patch), который имеет размер 1 MB. Если в сети около 5,000 рабочих станций, то ваш сервер для управления изменениями должен передать около 5 GB данных, для того чтобы послать это 1 MB обновление всем клиентам (в действительности, это будет гораздо больше, т.к. часть трафика уйдет на процедуру аутентификации и установку обновления). Даже если вы не против того, чтобы иметь единственный сервер, который будет посылать 5 GB данных, то вы должны представить себе, что будет твориться в сети, когда неожиданно придется установить обновление размером 200 MB (терабайт данных в сети).

Если для кого-то из вас не важен объем трафика, который потребляет единственный сервер для управления установкой обновлений в крупных сетях, то вы должны также учитывать количество времени, необходимого этому единственному серверу для того, чтобы установить обновления на всех рабочих станциях в сети. Даже очень быстрый сервер должен потратить некоторое время для того, чтобы установить обновление на всех 5,000 рабочих станциях, в результате ограничений на пропускную способность и неэффективности работы самих рабочих станций. Но т.к. большинство обновлений от Microsoft – это критичные обновления для безопасности, очень важно иметь возможность быстрой установки.

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

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

Когда необходимо будет установить обновление размером 1 MB, которое я упоминал ранее, примерно такой же объем трафика по-прежнему будет проходить по сети. В конце концов, число рабочих станций, для которых необходимо передать обновление, осталось неизменным, и даже немного больше, чем прежде. Различие заключается в том, каким образом этот трафик будет распределяться. Теперь у вас не будет одного сервера, который передает 5 GB данных. Вместо этого, каждый из подчиненных серверов будет передавать немногим более 1 GB данных. А что более важно, эти подчиненные сервера могут размещаться в той же подсети, где и обслуживаемые ими клиенты. Таким образом, основной сетевой трафик, относящийся к процессу управления обновлениями, будет изолирован в единственной подсети, а не проходить через всю сеть. Конечный результат заключается в том, что трафик будет меньше влиять на сеть в целом.

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

Большая область сети.

Теперь, после того как я рассказал о нескольких причинах, по которым централизованное управление обновлениями обычно не очень удачная идея для больших сетей, я хочу рассказать о нескольких причинах, почему это не очень хорошо в географически распределенных сетях. Многие из тех же самых принципов, о которых я уже рассказал по отношению к большим сетям, также применимы к географически распределенным сетям, т.к. они часто также являются очень большими. Однако, проблемы появляются в географически распределенных сетях вне зависимости от размеров. Но с увеличением размера сети, проблемы также увеличиваются.

Для того, чтобы увидеть, почему централизованное управление обновлений проблематично даже для маленьких географически распределенных сетей, давайте представим, что есть компания, у которой два офиса – первый в Miami, Florida а второй в Las Vegas, Nevada (почему не использовать веселые места). Т.к. между этими двумя офисами пара тысяч миль, то компания выбирает арендованную линию для связи между этими двумя офисами. Компания небольшая – по 25 сотрудников в каждом офисе. Т.к. компания небольшая, и имеет небольшой бюджет, то она использует T-1 линию для WAN соединения, пропускная способность которой 1.544 MBPS.

Хорошо, так что за проблемы с компанией такого типа при использовании централизованного управлениями обновлениями? Давайте представим, что у компании есть сервер, управляющий установкой обновлений, в офисе в Las Vegas, но нет в офисе Miami. Теперь давайте представим, что Microsoft выпускает обновление для безопасности размером 1 MB, который необходимо установить на все рабочие станции. Сервер, управляющий установкой обновлений, загружает обновление и без проблем устанавливает его на все рабочие станции в офисе в Las Vegas. Затем, сервер начинает установку обновления на рабочие станции в офисе в Miami. Проблема заключается в том, что в офисе в Miami 25 рабочих станций. Сервер, управляющий установкой обновлениями, должен переслать все то же обновление размером 1 MB по медленному WAN соединению двадцать пять раз. Это значит, что медленное соединение будет перегружено 25 MB трафиком. Пока все обновления не будут переданы, другие взаимодействия между офисами будут серьезно затруднены.

В реальной сети, я вероятно бы разместил по одному независимому серверу, управляющим установкой обновлений, в каждом офисе. Таким образом, обновления никогда не придется передавать по медленному WAN соединению. Если бы WAN соединение было бы быстрее, или если централизованный административный контроль был более важным, то сервер в Miami мог бы быть настроен, как подчиненный сервер для сервера в Las Vegas. Таким образом, сервер в Las Vegas мог бы загружать обновления и устанавливать их на рабочие станции в Las Vegas. Он мог бы также посылать копию каждого обновления серверу в Miami, который в свою очередь устанавливал обновление на рабочие станции в Miami.

Заключение

В этой статье я объяснил, что хотя централизованное управление обновлениями с недавнего времени очень популярно, иногда оно непрактично. Я рассказал о нескольких причинах, по которым централизованное управление изменениями часто неэффективно в больших и географических распределенных сетях. Затем я рассказал о некоторых альтернативных решениях.

www.windowsnetworking.com


Смотрите также:

Readers Comments (Комментариев нет)




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]