Таку серверну роль як Windows Server Update Services (WSUS) доцільно використовувати як в дрібних компаніях, які налічують від 10 комп'ютерів, так і у великих корпораціях. На відміну від таких серверних ролей, як доменні служби або серверів електронної пошти, для серверів оновлень WSUS вам не обов'язково розгортати відмовостійкі сервера, так як автоматизація поновлення клієнтських комп'ютерів не є самою критичною завданням в бізнес процесах. Вам, як системному адміністратору варто пам'ятати про те, що бази даних таких серверів як WSUS необхідно регулярно архівувати для того, щоб в разі несправності або заміни сервера ви могли все відновити протягом одного тижня. Так як оновлення рідко мають статус критичних, а на роботі кінцевих користувачів збій WSUS сервера ніяк не відіб'ється, за великим рахунком, ви можете сміливо позбавити ваших користувачів можливості синхронізації з сервером оновлень на кілька днів. У кожній організації є сенс розгортати сервера WSUS в залежності від розташування підрозділів і філій, кількості користувачів, швидкості мережі і т.д. У цій статті ви дізнаєтеся про основні сценарії розгортання серверів оновлень.
Просте розгортання WSUS-серверів
Багато маленькі і середні організації в своїй виробничій середовищі для розповсюдження оновлень, використовують саме цю модель. Прості рішення розгортання WSUS-серверів зазвичай представляють собою модель з розгорнутим сервером оновлень, який розташований всередині інтрамережі, захищеної брандмауером і обслуговуючим клієнтські комп'ютери локальної мережі. Для завантаження оновлень WSUS-сервер синхронізується з серверами служби Windows 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-сервер у тій частині мережі, у якому відсутня доступу до мережі Інтернет. В цьому випадку, розгортання оновлень буде забезпечуватися наступним чином: сервер, який синхронізується зі службою Windows Microsoft, підключений до мережі Інтернет, але повинен бути ізольований від интрасети. Після завантаження оновлень на даному сервері виконується експорт оновлень на зовнішній дисковий накопичувач, а потім шляхом підключення зовнішнього накопичувача до підлеглого сервера ви імпортуєте всі завантажені раніше оновлення. Таке рішення також вигідно застосовувати в організаціях, що володіють високою вартістю і низькою пропускною здатністю Інтернет каналу. Якщо для підтримки клієнтів в безлічі офісів використовується лише один WSUS-сервер, то кожному клієнтського комп'ютера доведеться завантажувати оновлення через підключення WAN. Згодом, розміри файлів і пакетів оновлень досягнутий до сотень мегабайт, і так як пропускна здатність WAN зазвичай значно нижче пропускної здатності локальної мережі організації, регулярна завантаження великих пакетів може негативно вплинути на продуктивність всієї мережі організації. Експорт завантажених оновлень з подальшим імпортом останніх на підлеглі WSUS-сервера дозволить вам значно розвантажити Інтернет-канал. Дане рішення проілюстровано нижче:
Мал. 4. Розгортання WSUS-серверів для користувачів, які не підключені до мережі Інтернет
Незважаючи на те, що у серверів оновлень немає необхідності в реалізації балансування мережного навантаження, то якщо перед вами стоїть завдання реалізації забезпечення надійності і продуктивності мережі серверів WSUS, ви можете налаштувати декілька WSUS-серверів, що розділяють один SQL кластер, як ви можете побачити з наступної ілюстрації.
Мал. 5. Балансування мережевого навантаження з ВІДМОВОСТІЙКО SQL кластером
Моделі управління серверами оновлень
Сервера WSUS підтримують дві моделі управління: централізовану і розподілену. Ці моделі дозволяють вам найкращим чином, в залежності від топології вашої організації, управляти рішеннями розподілу оновлень. По суті, ніхто вас не зобов'язує застосовувати в своїй виробничій середовищі зазначені далі моделі, але на підставі наступних моделей ви можете побудувати оптимальне для своєї інфраструктури рішення.
централізоване управління
В основі централізованого управління серверами оновлень лежить принцип управління серверами на основі реплік. Ви не можете управляти безпосередньо підлеглими серверами, так як вони використовуються тільки для поширення затверджених оновлень на зазначені вами групи. Всі настроюються групи та затвердження оновлень налаштовуються на вищому WSUS-сервері, які потім поширюються на всі підлеглі сервери в організації. Часто можна зустріти таку ситуацію, коли не всі сайти вашого лісу потребують створення груп комп'ютерів. Основна мета централізованого управління полягає в тому, щоб ви створили на керованому сервері таку кількість груп комп'ютерів, яке задовольнить потреби всього парку комп'ютерів вашої організації. Незважаючи на те, що комп'ютери можуть переміщатися по будь-яким відділам або навіть офісах вашої організації, групи комп'ютерів, створені на керованому сервері завжди повинні залишатися без будь-яких змін, причому, всі оновлення повинні здійснюватися на головному (вищому) керованому сервері. Крім усього сказаного раніше, на вищому WSUS-сервері вам потрібно вказати таку кількість мов для завантажуваних з серверів Центру оновлень Microsoft оновлень, яке буде поширюватися на всі репліки у вашій організації. Схема централізованого управління серверами оновлень зображена на наступній ілюстрації:
Мал. 6. Приклад централізованого управління серверами оновлень
розподілене управління
Розподілене управління WSUS-серверами дозволяє вам повністю розподілити контроль над усіма твердженнями і групами комп'ютерів між усіма філіями вашої організації. За допомогою даної моделі ви можете вказати індивідуальні мови для оновлень, групи комп'ютерів, додавати комп'ютери в настроюються групи для кожного сайту, а також поширювати для відповідних комп'ютерів поновлення тільки всередині зони дії свого WSUS-сервера. Модель розподіленого управління серверами оновлень є налаштуванням за замовчуванням при установці кожного WSUS-сервера. Приклад реалізації даної моделі ви можете побачити нижче:
Мал. 7. Приклад розподіленого управління серверами оновлень