Новим серверів зазвичай приділяють достатньо уваги, але з часом рівень моніторингу неминуче знижується. Однак у міру старіння надійність сервера істотно падає. Exchange Server 2003 - стабільний продукт, деякі його екземпляри знаходяться в експлуатації вже майже чотири роки. І навіть Exchange Server 2007 з'явився на ринку більше року тому. Якщо забути про старіючого сервері в надії, що він завжди буде функціонувати справно, можна зіткнутися з неприємним сюрпризом. Пам'ятаючи про це, розглянемо заходи підвищення надійності Exchange Server.
1. Перевірка цілісності бази даних
Не секрет, що версії, що передують Exchange Server 2003, були дуже вразливі. Спочатку проблема не носила катастрофічного характеру, але з часом посилювалася. На одному великому підприємстві співробітники, самі того не відаючи, протягом декількох місяців архівували зіпсовані дані Exchange Server. Масштаб проблеми наростав, поки нарешті зіпсована база даних не перестала монтуватися.
Кращий засіб тестування баз даних - ISINTEG, утиліта командного рядка, за допомогою якої можна перевірити цілісність Information Store і усунути неполадки, пов'язані зі збоями і невідповідностями. Для тестування Information Stores потрібно демонтувати сховище, відкривши диспетчер Exchange System Manager і пройшовши по дереву консолі до Administrative Groups, потрібної адміністративної групі, Servers, потрібного сервера і, нарешті, групі зберігання, що містить демонтується сховище. Клацніть правою кнопкою миші на сховище і виберіть команду Dismount Store з контекстного меню (але збережіть активної службу Information Store; це необхідно для ISINTEG). Переконайтеся, що архівна копія в порядку, а на томі, що містить сховище, багато вільного місця. Корисне правило - мати достатньо вільного місця для запису копії бази даних плюс ще 20%.
Відкрийте вікно командного рядка і перейдіть в папку Program Filesexchsrvrin. Щоб перевірити бази даних і усунути виявлені несправності, потрібно виконати наступну команду:
ISINTEG -S servername
-fix -test alltests
У цій команді ключ -S вказує ім'я сервера, що містить базу даних, яку потрібно перевірити чи відновити, ключ -ALLTESTS налаштовує утиліту на виконання повного набору тестів сховища, а завдяки ключу -FIX будуть зроблені спроби виправити всі виявлені неполадки. Слід пам'ятати, що ISINTEG усуває тільки неузгодженості в базах даних. Інструмент не усуває фізичні неполадки всередині бази даних, такі як пошкоджені сторінки бази даних. Для цього потрібно використовувати утиліту ESEUTIL, яка буде описана нижче.
Настійно рекомендується спочатку виконати команду ISINTEG без ключа -FIX. Зазвичай дієвий, цей ключ іноді призводить до руйнування бази даних Exchange. Тому обов'язково слід зробити повну резервну копію, перш ніж запускати команду з ключем -FIX.
За допомогою ISINTEG можна перевіряти тільки бази даних, перекладені в автономний режим. Просто введіть число перевіряються баз даних у відповідь на запит. ISINTEG просить підтвердити імена баз даних, які належить перевірити, а потім починає тестування. Час перевірки залежить від розміру бази даних і можливостей обладнання, але для перевірки великої бази даних може знадобитися кілька годин.
2. Тестування цілісності бази даних
ISINTEG перевіряє загальну цілісність баз даних Exchange, але не виконує глибокого тестування бази даних. Детальний аналіз можна виконати за допомогою утиліти ESEUTIL, яка перевіряє правильність контрольних сум на окремих сторінках бази даних. ISINTEG і ESEUTIL виконують різні завдання, але обидві утиліти важливі.
Перевірка за допомогою ESEUTIL не принесе шкоди базі даних, але може зайняти більше часу, ніж перевірка ISINTEG. Якщо ESEUTIL виявляє неполадки, можна використовувати ключ / P, щоб перебудувати базу даних і виправити помилку. Ключ / P слід використовувати тільки як останню міру, оскільки (як і ключ -FIX команди ISINTEG) він може пошкодити базу даних. Ви завжди можете мати хорошу резервну копію, перш ніж вносити будь-які виправлення за допомогою ESEUTIL. Але для загального тестування можна вільно використовувати ESEUTIL. При цьому потрібно переконатися, що база даних працює в автономному режимі, відкрити вікно командного рядка, перейти в папку Program FilesExchsrvrBin і ввести команду:
ESEUTIL / G імя_бази_данних
3. Автономна дефрагментація
За допомогою ESEUTIL корисно час від часу виконувати автономну дефрагментацію сховищ Exchange Information Stores. Exchange Server 2003 щоночі виконує оперативну дефрагментацію Information Stores. По суті, автономна дефрагментація призначена для того ж, але база даних при цьому стає більш компактною.
Серед фахівців з Exchange йдуть гарячі суперечки про користь автономної дефрагментації. На мій погляд, автономна дефрагментація корисна, якщо з бази даних недавно було видалено велику кількість об'єктів і потрібно звільнити вільний простір.
Я проводжу автономну дефрагментацію один раз на рік. По суті, в процесі дефрагментації база даних перебудовується, що дозволяє експлуатувати її з максимальною ефективністю. Однак для автономної дефрагментації потрібно перевести базу даних в автономний режим, на що, як правило, потрібно багато часу. Тому більшість адміністраторів Exchange рідко або взагалі ніколи не проводять автономну дефрагментацію.
Перш ніж виконати автономну дефрагментацію, обов'язково потрібно зробити хорошу резервну копію. Як зазначалося, в процесі дефрагментації база даних перебудовується і завжди є невелика ймовірність збою. В ході дефрагментації можна використовувати різні ключі команди ESEUTIL. У простій формі процес дефрагментації запускається за допомогою такої команди:
ESEUTIL / D імя_бази_данних
4. Регулярне тестування архівних копій
Сподіваюся, що, прочитавши цю статтю, читачі засвоять, що час впливає на сервер Exchange 2003, а серверні апаратні засоби не вічні (про те, як продовжити термін експлуатації обладнання, розказано в урізанні «Чотири ради з обслуговування апаратних засобів сервера»). Оскільки відмови сервера не завжди прогнозовані, важливо регулярно тестувати архівні копії. Таким чином, адміністратор буде впевнений, що зможе відновити втрачені дані в разі аварії.
Опис різних способів тестування архівних копій вимагає окремої статті, тут недостатньо місця, щоб описати всі деталі. Я перевіряю архівні копії щомісяця. Для цього використовуються лабораторні сервери, налаштовані як виробничі. Коли приходить час перевірки, я просто відновлюю архівні копії виробничих серверів на лабораторних аналогах, перевіряю, чи коректно монтуються бази даних Exchange Server і чи можна зареєструватися і відкрити поштову скриньку з лабораторної робочої станції.
Щодня копіювати дані не менш важливо, ніж тестувати архівні копії. Регулярно перевіряючи, чи виконано копіювання, адміністратор може запобігти не тільки вашій роботі у випадку аварії, а й надмірне розростання журналів транзакцій, яке може привести до нестачі дискового простору на сервері. Якщо використовуються журнали, відмінні від циклічних, Exchange буде зберігати всі журнали транзакцій до тих пір, поки їх дані не будуть записані в архівні копії. Якщо архівне копіювання виконується нерегулярно, з часом накопичення журналів транзакцій може привести до нестачі дискового простору на сервері.
5. Перевірка регулярності циклу нічного обслуговування
Exchange Server 2003 проектувався як цілком самодостатній продукт. Наступні 11 завдань обслуговування виконуються автоматично:
1). Очищення індексів сховищ поштових скриньок і загальних папок.
2). Обслуговування «міток на видалення» поштових скриньок і загальних папок.
3). Видалення прострочених повідомлень з «кошика» сховищ поштових скриньок і загальних папок.
4). Видалення прострочених повідомлень із загальних папок.
5). Остаточне видалення загальних папок з «мітками на видалення» віком понад 180 днів.
6). Вирішення конфліктів повідомлень в загальних папках.
7). Оновлення інформації про версії сервера для загальних папок.
8). Перевірка і видалення дубльованих папок сайту в сховищах загальних папок.
9). Остаточне видалення поштових скриньок в сховищах поштових скриньок.
10). Перевірка таблиці повідомлень для повідомлень-сиріт (повідомлення зі значенням лічильника посилань 0).
11). Оперативна дефрагментація сховища.
Виконання всіх 11 завдань у великому інформаційному сховищі може зайняти багато часу, і Exchange повинен виконувати завдання обслуговування, не перериваючи звичайної роботи. У більшості випадків для цього доводиться проводити обслуговування вночі. Через брак часу для виконання всіх завдань щоночі Exchange Server вирішує завдання в порядку пріоритету з урахуванням їх важливості і часу попереднього виконання. У перших 10 завдань пріоритет однаковий. Але 11-я задача (оперативна дефрагментація сховища) вважається набагато більш важливою, ніж інші.
У першому циклі обслуговування Exchange починає з першого завдання списку і виконує стільки завдань, скільки встигає за відведений час. Якщо у вікні обслуговування залишається тільки 15 хвилин, а всі завдання не виконані, програмою належить зробити вибір.
Якщо єдине завдання зайняла весь період обслуговування і ще не завершена, то Exchange проведе залишок періоду обслуговування за цим завданням. Однак, якщо хоча б одна задача завершена, Exchange відзначає останню виконану задачу як повністю завершену. На даному етапі Exchange припиняє виконання поточної задачі обслуговування і починає оперативну дефрагментацію. Оскільки оперативна дефрагментація вважається більш важливою, ніж інші завдання обслуговування, вона може виконуватися протягом години після закінчення періоду обслуговування.
У наступному плановому періоді обслуговування Exchange з'ясовує, яке завдання було успішно завершена останньої (не рахуючи оперативної дефрагментації), а потім запускає наступну задачу в списку. Завдяки тому що щодобове нічна перевірка не обов'язково починається з першого завдання списку, кожне завдання обов'язково виконується час від часу.
Надзвичайно важливо, що Exchange здійснює обслуговування щоночі, і його можна навіть керувати часом обслуговування, щоб не заважати щоночі резервного копіювання. Перш ніж показати, як скорегувати розклад обслуговування, хочу відзначити дві речі. По-перше, обслуговування проводиться на рівні сховища. Тому, якщо Exchange Server містить кілька сховищ, потрібно запланувати обслуговування окремо для кожного з них. По-друге, для обслуговування, як правило, потрібно чимало ресурсів, зокрема при обслуговуванні сховища - часу диска і процесора. Це необхідно враховувати при плануванні обслуговування.
За замовчуванням обслуговування кожного сховища планується з півночі до 4:00 ранку. Щоб змінити розклад, відкрийте диспетчер Exchange System Manager і перейдіть по дереву консолі до Administrative Groups, потрібної адміністративної групі, Servers, потрібного сервера, групі сховищ і сховища. Клацніть на сховище правою кнопкою миші і виберіть команду Properties з контекстного меню. Зі списку властивостей сховища виберіть вкладку Database. Як показано на екрані, вкладка Database містить список, що розкривається Maintenance Interval, який використовується для вибору чотиригодинного блоку часу для щоденного або щоночі періоду обслуговування. Або ж можна натиснути кнопку Customize, щоб вказати інший інтервал обслуговування.
6. Щоденна перевірка журналів подій
Для контролю серверів Exchange широко використовуються такі продукти, як Microsoft Operations Manager (MOM) і System Center Operations Manager 2007. Якщо ці програми не застосовуються, слід щодня перевіряти журнали подій. Іноді події, внесені в історію послуги, вказують на потенційні проблеми. Запобіжні перевірки журналів дають можливість усунути аномалії, перш ніж вони перетворяться в несправності. Простий приклад: журнали подій можуть попередити про те, що на диску залишається мало місця. Адміністратор може перемістити якісь об'єкти або встановити диск більшої ємності, перш ніж ситуація вийде з-під контролю.
Перевіряючи журнали подій, звертайте увагу на записи, які стосуються описаного вище процесу обслуговування. У таблиці перераховані події обслуговування, що представляють особливий інтерес як індикатори незвичайної активності.
Ліки від старості
Поступово надійність серверів знижується. Тому за старіючим сервером необхідно стежити так само уважно, як за новим, ще не випробуваним пристроєм. Регулярно виконуючи цикл завдань обслуговування, можна продовжити термін експлуатації сервера і виявити неполадки, перш ніж вони призведуть до неприємних наслідків.
Брайен Поус ( http://www.brienposey.com ) - віце-президент з досліджень компанії Relevant Technologies. Автор статей на технічні теми для різних видань і Web-сайтів
Чотири ради з обслуговування апаратних засобів сервера
Апаратні засоби не вічні. Але термін експлуатації серверного обладнання можна продовжити, якщо виконувати практичні рекомендації по обслуговуванню
1. Вивчіть свій сервер
Освіжіть в пам'яті відомості про Exchange Server. Найбільш схильний до відмов компонент - жорсткі диски, так як вони містять рухомих деталей і майже постійно використовуються. Згодом жорсткі диски просто зношуються.
Більшість серверів містять механізми для прогнозування відмов дисків. Ці механізми не бездоганні з точки зору надійності, але до їх попереджень потрібно прислухатися. Проблема в тому, що не існує галузевого стандарту для попереджень про відмови дисків. Один з найбільш широко використовуваних механізмів - SMART, але навіть цю технологію різні виробники реалізують по-різному, тому важко вгадати, яким буде попередження про наближення відмову. Одні сервери можуть видати попередження через операційну систему, інші - тільки через BIOS або світлодіод. Важливо знати, який метод використовується в сервері, щоб розпізнати ознаки кризи, що насувається відмови і періодично перевіряти стан дисків сервера.
2. Перевіряйте наявність дисків
Компанія Microsoft рекомендує об'єднувати бази даних Exchange Server в масиви RAID, що забезпечують як підвищену швидкодію, так і відмовостійкість. Але в деяких випадках відмовостійкий масив створює помилкове відчуття безпеки.
В одній відомій мені компанії був старий сервер, підключений до відмовостійкості масиву. Хоча масив експлуатувався вже кілька років, жоден з його дисків ніколи не виходив з ладу. Але коли диск нарешті зламався, з'ясувалося, що виробник припинив випуск потрібних дисків. Адміністратор спробував знайти заміну в Internet, але другий диск відмовив раніше, ніж він зміг знайти підходяще пристрій. Масив забезпечував захист від відмови одного диска, але в ньому не було механізму захисту даних від відмов декількох дисків. У цьому випадку надійність масиву виявилася не вище, ніж у єдиного диска, а все тому, що не вдалося знайти потрібних запасних частин.
Якщо Exchange Server працює на старому обладнанні, слід періодично перевіряти, чи є в продажу потрібні компоненти. Навіть якщо здається, що потрібні диски будуть доступні завжди, тримайте під рукою пару запасних, щоб вчасно усунути будь-які неполадки. Хоча відмовостійкі масиви спроектовані в розрахунку на те, щоб робота тривала навіть після відмови, рекомендується замінити відмовив диск якомога швидше. Залежно від типу масиву, продуктивність сервера може істотно постраждати, якщо не замінити відмовив диск.
3. Видаляйте пил
На перший погляд пил - дрібниці порівняно з іншими проблемами обслуговування, але надмірне скупчення пилу може привести до перегріву, а це в свою чергу - до псування даних, поломок устаткування й перервами в роботі, пов'язаних з випадковими помилками.
З пилом пов'язані три типи серверних неполадок. По-перше, пил порушує роботу накопичувачів CD і DVD. Пил може покрити лінзу лазера або перешкодити її правильному переміщенню. В результаті лінза буде переміщатися повільно або ненадійно або навіть зовсім перестане працювати.
Друга і, ймовірно, найпоширеніша проблема, пов'язана з пилом, - нею забиваються вентилятори. Згодом, якщо вентилятор працює погано, джерело живлення перегрівається і виходить з ладу. Якщо сервер не оснащений надлишковими джерелами живлення, відразу ж виникає просте.
Нарешті, пил може привести до перегріву процесора. У міру накопичення пилу знижується ефективність вентиляторів корпусу і процесорів; вони можуть зовсім припинити працювати. Забиваються пилом і радіатори, що зменшує потік проходить через них повітря. Коли процесори перегріваються, трапляються дивні помилки, в тому числі обчислювальні. Надійний комп'ютер починає видавати «блакитні екрани» без видимої причини. Кілька разів мені доводилося бачити, як база даних псувалася безпосередньо в результаті перегріву комп'ютера. Інші симптоми перегріву - відмови відеоадаптерів та інших компонентів.
Багато сервери оснащуються внутрішніми датчиками температури, які повинні відключити сервер, перш ніж може бути завдано серйозної шкоди. Але тим не менш простий сервера в цьому випадку неминучий. Для боротьби з пилом я чищу сервери раз на півроку: відкриваю корпус і витягую пил пилососом. При цьому корисно переконатися, що працюють всі вентилятори.
4. Перевірте батареї
Вище були розглянуті проблеми, пов'язані зі старінням серверів. Але процес старіння набагато сильніше позначається на джерелах безперебійного живлення, ніж на серверах. Незважаючи на значне поліпшення конструкції ДБЖ, батареї з часом втрачають заряд. В кінцевому підсумку старіючий ДБЖ не може підтримати роботу сервера більш ніж протягом однієї-двох хвилин після відключення електромережі.
Запобігти втраті заряду батарей не можна, але корисно знати, чого можна очікувати від ДБЖ в разі відмови електропостачання. Два рази на рік я тестую ІБП і фіксую час, протягом якого вони забезпечують роботу сервера. При цьому не тільки з'ясовується, як довго сервери збережуть працездатність в разі збою живлення, але і можна визначити, коли батареї стають непридатними для експлуатації, і прийняти рішення про заміну ДБЖ.
Таблиця. Корисні події обслуговування
