1.4 Застосування SUS при проектуванні системи оновлень

Розгортання сервер SUS в невеликій мережі, зосередженій на одному фізичному ділянці не представляє складності: виправлення завантажуються автоматично, для цього ви їх тестуєте і вирішуєте до розповсюдження, далі вони розповсюджуються серед клієнтів і встановлюються на них. У великих мережах структура складніша. Як оновлювати віддалені системи і лептопи, які чаші всього відключені або підключені через повільні лінії? У яких випадках можна обійтися однією ієрархією, а коли потрібно декілька батьківських серверів? Як оновлювати системи, не підключені до Інтернету? При проектуванні інфраструктури оновлень з використанням служб SUS враховуйте наступні рекомендації.

При проектуванні мережевої інфраструктури SUS:

· визначите джерело виправлень. Сервер SUS може отримувати виправлення сайту Windows Update, від іншого сервера SLJS або від сервера управління контентом - IIS- сервера. що зберігає копії дозволених виправлень. Такі сервери застосовуються для синхронізації Sus-серперов, розташованих в сегментах, не підключених до Інтернету;

· настроюйте батьківський і дочірні сервери SUS для розповсюдження однакових виправлень. У ієрархії тільки батьківський сервер може завантажувати виправлення безпосередньо з сайту Microsoft;

· розмістіть сервери SUS у всіх важливих центрах обробки даних і представництвах організації;

· продумайте розміщення серверів в мережі. Дочірні сервери рекомендується розміщувати ближче до обслуговуваних ними клієнтів, а розміщення батьківських серверів залежить від підключення до Інтернету; дочернім серверам і клієнтам доступ до Інтернету для оновлення не потрібний;

· SUS-серверы в сегментах, не підключених до Інтернету, слід набудувати для отримання виправлень від сервера управління контентом;

· використовуйте балансування навантаження на мережу (Network Load Balancing, NLB) для серверів SUS. NLB автоматично розподіляє навантаження між серверами SUS якщо один з серверів вийде з ладу, останні продовжать роботу.

Застосування NLB оптимальне, якщо інфраструктура включає безліч серверів SUS які повинні бути постійно доступними. Проте NLB - дороге рішення оскільки вимагає установки декількох серверів, тому NLB краще набудувати для дочірніх серверів, а для завантаження оновлень використовувати батьківський сервер (мал. 4).

При проектуванні розгортання SUS:

· зясуєте обмеження ПО і устаткування;

· встановлюйте SUS на захищений сервер, на який встановлені всі необхідні виправлення і пакети оновлень;

Мал. 4. Використання NLB для забезпечення надмірності SUS

· створіть ізольоване середовище для тестування сервера SUS і оновлень;

· спочатку встановіть і перевірте служби SUS в тестовому середовищі. Це дозволить адміністраторам відпрацювати застосування SUS без збитку для робочої мережі;

· на сервері не повинно бути додатків окрім SUS. US здатні забезпечувати роботу різних застосувань, але з SUS сумісні далеко не всі вони. До сумісних відносяться додатки ASP.NET, серверні розширення Frontpage служби Sharepoini. Якщо сервер страждає із-за збоїв додатків, що працюють в US, під загрозою вся інфраструктура SLJS;

· забезпечте антивірусну зашиту сервера, але врахуйте, що при установці SUS антивірусний захист повинен бути відключений;

· використовуйте IIS Lockdown на серверах під управлінням Windows 2000. Утиліти US Lockdown і Urlscan забезпечують додатковий захист служб US. Якщо вони не встановлені з SUS SPI, слід встановити їх пізніше;

· якщо планується зробити сервер SUS контролером домена, зробіть це до установки SUS, інакше видалити SUS буде неможливо;

· становите в мережі US-сервер для розміщення сайту сервера SUS. Не рекомендується використовувати цей сервер для розміщення інших Web-сайтів, оскільки атака відкритого Web-сайту, розташований на одному сервері з SUS поставить під загрозу всю інфраструктура оновлень;

· якщо ви не бажаєте встановлювати SUS поверх Web-сайту за умовчанням,

· відключите або видалите його. SUS завжди встановлюється на Web-сайт за умовчанням якщо той працює, відсутність такого SUS створить новий Web-сайт, встановить його і призначить йому порт 80.

При плануванні роботи SUS:

· досвід вимагає завантажувати виправлення регулярно, бажано щодня. Щоб набудувати графік синхронізації, з сайту адміністрування SUS відкрийте сторінку Synchronize Server (Синхронізація сервера), викличте вікно Schedule Synchronization (Планування синхронізації), див. мал. 5. Можна також виконувати синхронізацію уручну;

· набудуйте періодичність завантаження на дочірніх серверах так. щоб вони як можна швидше отримували виправлення, завантажені батьківським сервером з сервера Microsoft;

· не включайте автоматичне отримання дозволу для отриманих виправлень, оскільки перед розповсюдженням їх слід протестувати;

· сплануйте тестування оновлень. Конфігурація тестових компютерів повинна співпадати з такою робочих серверів і клієнтів. Для розповсюдження виправлення повинне бути схвалене (дозволено до розповсюдження) на сторінці Approve Updates (мал. 6). Дозволені виправлення автоматично стають доступними для клієнтів:

Мал. 5 Синхронізація.

При проектуванні інфраструктури клієнтів:

· врахуйте, що деякі оновлення вступають в силу тільки після перезавантаження. Користувачам, що працюють в цей час, можна не турбуватися, оскільки SUS перезавантажують компютер тільки після виходу з системи всіх користувачів;

· продумайте оновлення віддалених компютерів, користувачі яких не являються адміністраторами. Адміністратори отримують повідомлення про невдале оновленнях і виконують їх уручну Оновлення не відбудеться, якщо компютер не буде підключений до мережі під час розповсюдження оновлень;