Планування архітектури WSUS, Просто про складне

БЛОГ ПЕРЕЇХАВ - http://gpo-planet.com

Планування архітектури WSUS

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

Просте розгортання WSUS-серверів

Багато маленьких і середніх організацій у своїй виробничій середовищі поширення оновлень, використовують саме цю модель. Прості рішення розгортання WSUS-серверів зазвичай являють собою модель з розгорнутим сервером оновлень, який розташований всередині інтрамережі, захищеної міжмережевим екраном і клієнтом обслуговує інтрамережі. Для завантаження оновлень WSUS-сервер синхронізується із серверами Центруоновлення Microsoft. Як було сказано вище, під час синхронізації WSUS визначає, чи не було випущено нові оновлення з часу останньої синхронізації. Якщо ж з'явилися нові оновлення, вони будуть завантажені в базу даних WSUS. А якщо синхронізація виконується вперше, то WSUS-сервер завантажить усі оновлення, доступні для завантаження. Вперше синхронізація може затягнутися на кілька годин. Після завершення першої синхронізації на всі наступні синхронізації буде витрачено значно менше часу. За замовчуванням, для завантаження оновлень із серверів Microsoft сервер WSUS використовує або порт 80, або 443, відповідно, для протоколів HTTP або HTTPS. Крім портів, що використовуються за замовчуванням, ви також можете вказати порти користувача, які при необхідності вам доведеться відкрити на зовнішньому міжмережевому екрані.

Мал. 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 Update, підключений до мережі Інтернет, але повинен бути ізольований від інтрамережі. Після завантаження оновлень на цьому сервері експорт оновлень на зовнішній дисковий накопичувач, а потім шляхом підключення зовнішнього накопичувача до підлеглого сервера ви імпортуєте всі завантажені раніше оновлення. Таке рішення також вигідно застосовувати в організаціях, що мають високу вартість і низьку пропускну здатність Інтернет каналу. Якщо для підтримки клієнтів у багатьох офісах використовується лише один WSUS-сервер, то кожному клієнтському комп'ютеру доведеться завантажувати оновлення через підключення WAN. З часом, розміри файлів і пакетів оновлень досягнуто до сотень мегабайт, і так як пропускна здатність WAN зазвичай значно нижча за пропускну здатність локальної мережі організації, регулярне завантаження великих пакетів може негативно вплинути на продуктивність всієї мережі організації. Експортування завантажених оновлень з подальшим імпортом останніх на підлеглі WSUS-сервери дозволить вам значно розвантажити Інтернет-канал. Дане рішення проілюстровано нижче:

Мал. 4. Розгортання WSUS-серверів для користувачів, які не підключені до Інтернету

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

Мал. 5. Балансування мережного навантаження з стійким до відмов SQL кластером

Моделі керування серверами оновлень

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

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

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

Мал. 6. Приклад централізованого управління серверами оновлень

Розподілене управління

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

Мал. 7. Приклад розподіленого управління серверами оновлень