Децентрализация управления исправлениями
За последние год или два кажется, что термин «централизованное управление исправлениями» используется довольно часто. В большинстве случаев централизованное управление исправлениями означает наличие сервера, отвечающего за развертывание исправлений во всей организации. Централизованное управление исправлениями в теории звучит хорошо, но есть организации, в которых централизованное управление исправлениями не является хорошей идеей. Например, централизованное управление исправлениями часто является плохой идеей в крупных организациях или в организациях, которые географически разбросаны. В этой статье я расскажу о некоторых альтернативных механизмах для этих типов организаций.
Почему бы не использовать централизованное управление исправлениями?
В последнем абзаце я упомянул, что централизованное управление исправлениями может быть плохой идеей в больших организациях или в организациях, которые географически разбросаны. Я хочу начать с объяснения, почему это так. В крупных организациях это просто вопрос спроса и предложения. Один сервер управления исправлениями, вероятно, не сможет удовлетворить требования большой сети корпоративного класса.
Например, представьте, что Microsoft выпускает новое исправление безопасности размером 1 МБ. Если в сети 5000 рабочих станций, то вашему серверу управления исправлениями придется передать около 5 ГБ данных только для того, чтобы разослать этот 1-мегабайтный патч всем клиентам (на самом деле это будет гораздо больше данных, чем из-за накладных расходов на процессы аутентификации и исправления). Даже если вы не возражаете против того, чтобы один сервер рассылал исправления объемом 5 ГБ за раз, вы должны учитывать, каковы будут последствия развертывания пакета обновлений объемом 200 МБ (терабайт данных, внезапно переполнивших вашу сеть).
Даже если вас не беспокоит объем трафика, с которым одному серверу управления исправлениями придется иметь дело в большой сети (вы должны быть обеспокоены), вы должны учитывать количество времени, которое потребуется одному серверу для внесения исправлений. все эти рабочие станции. Даже быстрому серверу потребуется некоторое время для исправления 5000 рабочих станций из-за ограничений пропускной способности и неэффективности самих рабочих станций. Поскольку так много исправлений, выпускаемых Microsoft, являются критически важными исправлениями безопасности, важно иметь возможность быстро применять исправления.
Итак, централизованный сервер управления исправлениями обычно не является хорошей идеей для больших сетей, так что же есть альтернатива? В крупной организации обычно лучше децентрализовать управление исправлениями. Идея состоит в том, что у вас по-прежнему есть центральный сервер управления исправлениями, но этот сервер никогда не отправляет исправления непосредственно на рабочие станции. Вместо этого он действует как главный сервер управления исправлениями и отправляет исправления на подчиненные серверы управления исправлениями. Это позволяет иметь отдельный сервер управления исправлениями для каждого основного отдела.
Чтобы увидеть, как это работает, давайте вернемся к моему предыдущему примеру организации с 5000 рабочих станций, которые необходимо установить. Вместо того чтобы использовать один сервер для исправления всех 5000 рабочих станций, давайте представим, что организация установила главный сервер управления исправлениями и пять подчиненных серверов управления исправлениями, каждый из которых обслуживает около 1000 пользователей.
Когда необходимо применить патч размером 1 МБ, который я использовал в своем предыдущем примере, тот же приблизительный объем трафика все еще размещается в сети. В конце концов, количество рабочих станций, получающих исправление, остается прежним, а накладные расходы немного больше, чем раньше. Разница в способе распределения трафика. Во-первых, у вас не будет ни одного сервера, отправляющего 5 ГБ данных. Вместо этого каждый из подчиненных серверов будет отправлять гораздо более управляемый 1 ГБ данных каждый. Что еще более важно, эти подчиненные серверы могут быть размещены в тех же подсетях, что и клиенты, которых они обслуживают. Таким образом, большая часть сетевого трафика, связанного с процессом управления исправлениями, будет изолирована в одной подсети, а не будет проходить по всей сети. Конечным результатом является то, что трафик будет иметь гораздо меньшее влияние на сеть в целом.
Использование пяти подчиненных серверов для распространения исправлений вместо использования одного центрального сервера также позволяет быстрее распространять исправления. Все пять серверов могут работать одновременно, и при условии, что все равны, процесс установки исправлений может быть завершен примерно в пять раз быстрее, чем если бы использовался только один сервер управления исправлениями.
Глобальная сеть
Теперь, когда я обсудил некоторые причины, по которым централизованное управление исправлениями обычно не является хорошей идеей для больших сетей, я хочу обсудить некоторые причины, по которым оно также не очень хорошо подходит для географически рассредоточенных сетей. Многие из тех же принципов, которые я уже обсуждал в отношении больших сетей, также имеют тенденцию применяться к географически рассредоточенным сетям, поскольку они также часто имеют тенденцию быть большими. Однако централизованное управление исправлениями обычно вызывает проблемы в географически рассредоточенных сетях независимо от их размера. Однако по мере увеличения размера сетей проблемы, как правило, усугубляются.
Чтобы понять, почему централизованное управление исправлениями проблематично даже для небольших географически рассредоточенных сетей, давайте представим, что есть компания, имеющая два офиса; один в Майами, штат Флорида, и другой в Лас-Вегасе, штат Невада (почему бы не использовать забавные места). Поскольку расстояние между двумя офисами составляет пару тысяч миль, компания решила использовать выделенную линию для соединения двух объектов. Компания небольшая, по 25 сотрудников в каждом офисе. Из-за небольшого размера компании и бюджетных ограничений компания использует линию T-1 для подключения к глобальной сети с пропускной способностью 1,544 Мбит/с.
Итак, в чем проблема с такой компанией, использующей централизованное управление исправлениями? Предположим, что у компании есть сервер управления исправлениями в офисе в Лас-Вегасе, а не в офисе в Майами. Теперь давайте представим, что Microsoft выпускает исправление безопасности объемом 1 МБ, которое необходимо установить на все рабочие станции. Сервер управления исправлениями загружает это исправление и без проблем развертывает его на всех рабочих станциях в Лас-Вегасе. Затем сервер управления исправлениями начинает развертывание исправления на рабочих станциях в Майами. Проблема в том, что в Майами 25 рабочих станций. Сервер управления исправлениями должен отправить одно и то же исправление размером 1 МБ по медленному каналу глобальной сети двадцать пять раз. Это означает, что медленная ссылка перегружена 25 МБ трафика. Пока все исправления не будут отправлены, связь между двумя офисами может быть серьезно затруднена.
Если бы это была реальная сеть, я бы, наверное, разместил в каждом офисе независимый сервер управления исправлениями. Таким образом, исправления никогда не должны отправляться по каналу WAN, поскольку скорость канала очень низкая. Если бы канал WAN был быстрее или если бы был важен централизованный административный контроль, то сервер в Майами можно было бы настроить как подчиненный серверу в Лас-Вегасе. Таким образом, сервер в Лас-Вегасе загружал исправления и развертывал их на рабочих станциях в Лас-Вегасе. Он также отправлял копию каждого исправления на сервер в Майами, который, в свою очередь, развертывал исправления на рабочих станциях в Майами.
Вывод
В этой статье я объяснил, что хотя централизованное управление исправлениями в последнее время приобрело популярность, иногда оно нецелесообразно. Я объяснил некоторые причины, по которым централизованное управление исправлениями часто оказывается неэффективным в больших или географически рассредоточенных сетях. Затем я перешел к обсуждению некоторых альтернативных механизмов.