Управління даними Microsoft Exchange

1. Як тримати дані Exchange під контролем Ефективно управляти даними Microsoft Exchange Server - непроста...
2. Робота з даними на сервері
3. Управління даними користувача
4. Резервування і відновлення
5. Все про архівування
6. Висновок
7. Комплексне управління даними Exchange
8. Управління даними: статистика

Як тримати дані Exchange під контролем

Ефективно управляти даними Microsoft Exchange Server - непроста робота. Завдання підтримки балансу між запитами користувачів і стабільністю і продуктивністю роботи сервера Exchange завжди входила в обов'язки адміністратора системи. Але з часом електронна пошта перетворилася в життєво важливе для бізнесу додаток, і діючі розпорядчі документи ставлять адміністраторів в скрутне становище, буквально між Сциллою і Харибдою.

Щоб тримати під контролем дані Exchange, потрібен комплексний підхід, в якому поєднуватимуться ясно описані політики і підходять для певного режиму технології (обладнання для зберігання даних, утиліти моніторингу і залишення звітів, програми управління даними). З чого ж почати?

Спочатку хочу пояснити, що я маю на увазі під словами «ефективне управління даними». Я розумію це як якусь практику безпечного маніпулювання зберігаються в Exchange даними, до певної міри оптимізує зберігання даних і забезпечує адекватний доступ до них. Отже, краще за все почати з вивчення фінансових, технічних і розпорядчих обмежень, прийнятих в організації. Ці фактори вплинуть на те, як буде здійснюватися управління даними в групах зберігання (SG), базах даних і поштових скриньках користувачів (включаючи автономні сховища - OST і персональні сховища - PST) при дотриманні вимог, що пред'являються до резервування, відновлення та архівації даних.

обмеження

Всякий, хто займається обслуговуванням Exchange, звик мати справу з взаємовиключними вимогами. Намагаючись знайти рішення для управління даними, слід взяти до уваги три міркування: вартість пропонованих доповнень, технічні обмеження і типи розпорядчих обмежень компанії.

Фінансові обмеження. У міру того як трафік поштових повідомлень зростає (з точки зору обсягу та розміру) і все частіше приймаються рішення про зберігання повідомлень в базах даних Exchange в оперативному стані або постійно перевіряються автономних сховищах, вимоги до сховищ даних, а отже, і до їх вартості ростуть . Фінансові обмеження - це не просто витрати на додаткові диски для підтримки більш великих баз даних. Доведеться платити за необхідну інфраструктуру зберігання (додаткові дискові масиви, стрічкові пристрої, Storage Area Network - SAN) і технічний персонал, що обслуговує зрослий обсяг даних. Ці витрати різняться в залежності від розміру і профілю організації. Підприємства малого бізнесу з декількома сотнями користувачів, швидше за все, обмежаться збільшенням обсягу сховища, але більші організації з декількома тисячами користувачів можуть бути залучені в істотні витрати.

Якщо вимоги, що пред'являються до сховищ даних, випереджають можливості компанії щодо закупівлі додаткового обладнання, можна розглянути питання про реалізацію більш строгих політик резервування і зберігати менше непотрібних даних або ж вибрати рішення архівації, оптимізує політику зберігання даних. В обох випадках витрати часто виявляються істотно нижче в порівнянні з вартістю обладнання, придбаного заради бездумного задоволення будь-яких запитів.

Технічні обмеження. Навіть якщо організація в змозі витратити чималі гроші на закупівлю додаткового обладнання і реально збирається це зробити, неконтрольоване зростання даних позначиться на можливості обслуговувати рішення резервування і відновлення даних. Хоча стрічкові технології (якщо ми говоримо про них) продовжують удосконалюватися, зрослий обсяг даних буде займати все більше і більше часу для виконання завдань резервування і відновлення. В результаті спроба задовольнити один запит (простий доступ до даних) призведе до погіршення показників при виконанні інших запитів (швидке відновлення).

Потрібно спробувати знайти таке технічне рішення, при якому ці вимоги будуть збалансовані. Оптимальний підхід комбінує управління оперативними сховищами Exchange з майже оперативними або автономними рішеннями архівування даних. Такий підхід є досить привабливим - ви встигаєте за зростаючим обсягом даних основних підсистем зберігання Exchange, архівуєте критичні дані відповідно до вимог прийнятої політики, і в той же час зберігається можливість простого доступу до даних.

Розпорядчі обмеження. Багато організацій використовують політики, за допомогою яких виконується архівування поштової інформації. Там, де рішення архівування використовуються для виконання вимог внутрішніх стандартів компанії, проходження розробленим політикам у величезній мірі залежить від рішень внутрішнього корпоративного управління. В організаціях, діяльність яких регламентується зовнішніми органами, що пред'являються до рішень архівування вимоги виявляються набагато більш жорсткими. У тій системі, де строго дотримується відповідність прийнятим технічним умовам, вся електронна пошта, яка потрапляє в організацію, залишає її або циркулює в ній, береться до уваги. Коли використовується така система, можна гарантувати, що всі дані електронної пошти, де б вони не знаходилися (наприклад, в персональних сховищах - PST, або на мобільних пристроях), будуть заархівовані.

Отже, які обмеження застосовуються в організації, відомо. Тепер можна приступати до розробки керівних принципів, відповідно до яких дані будуть розміщуватися в файлах баз даних Exchange, в кеш-файлах Microsoft Outlook (т. Е. В OST-файлах) і PST-файлах. Одночасно з цим вибираються найбільш повно задовольняють специфіці конкретної обчислювальної середовища рішення резервування, відновлення та архівування.

Робота з даними на сервері

Exchange зберігає поштові дані в базах даних на одному або декількох серверах Exchange. Ці бази даних, ймовірно, слід вважати найкращим місцем зберігання поштового контенту, і не в останню чергу через наявність в кожній базі єдиного механізму зберігання (хоча між різними базами єдиний механізм зберігання відсутній). У загальному випадку дані на сервері доступніші, ніж дані в файлах PST, хоча б з позиції обслуговування. Інформацію загального користування найкраще розміщувати в загальних папках баз даних Exchange. На сервері Exchange Server 2003 або на станції Exchange 2000 Server може міститися до чотирьох груп зберігання (SG) і в межах однієї групи може бути до п'яти баз даних; виходить, що один сервер може містити до 20 баз даних. Як показує практика, розмір бази даних не повинен перевищувати 40 Гбайт, щоб процедура резервування і, що більш важливо, відновлення укладалася в відведений час.

Саме можливості зберігання визначають максимальне число активних користувачів, яких в змозі обслужити одна система Exchange. Підсистеми зберігання Exchange повинні справлятися із завантаженням каналів введення / виводу, що ініціюється користувачами. У керівництві Microsoft «Optimizing Storage for Exchange 2003» наводяться рекомендації щодо створення підсистеми, яка може забезпечити середній показник приблизно 0,75 операцій введення / виводу в секунду на одного активного користувача. Для більшості підсистем зберігання - і це справедливо навіть для потужних платформ SAN - в цьому посібнику називається цифра не більше 4000 активних користувачів на один сервер.

Слід дотримуватися певного балансу при дотриманні рекомендацій щодо розміру бази даних і обмежень числа користувачів, а також враховувати інші фактори, що впливають на продуктивність системи (наприклад, розмір файлів - журналів транзакцій) при модернізації серверів, розміщенні систем зберігання та встановлення обмежень на поштові скриньки користувачів. на екрані представлена ​​типова таблиця, яку я використовую при розрахунку вимог, що пред'являються до системи зберігання. Наприклад, для сервера, на якому розміщено близько 4000 поштових скриньок, відповідна дискова квота встановлюється рівною 200 Мбайт.

Крім використання поштових квот (які можна накласти на базу в цілому або на окремого користувача), для управління даними, розміщеними на сервері Exchange, можна задіяти Group Policy для настройки Exchange Mailbox Manager з метою виявлення і видалення старих або дуже великих повідомлень з поштових скриньок користувачів . Такий підхід дозволяє контролювати розміри поштових скриньок і не доводити до появи повідомлення про перевищення квоти - mailbox quota exceeded. Якщо ви побоюєтеся видалити випадково щось важливе, функція Deleted Items Recovery (якщо вона включена) дасть користувачам можливість відновити повідомлення навіть після того, як папка Deleted Items виявиться порожньою. Цей потужний інструмент адміністратора допоможе боротися з помилками користувачів. Якби його не було, довелося б вдатися до дорогих операцій відновлення. Однак потрібно бути обережним - активізація функції Deleted Items Recovery може привести до надмірного розростання баз даних. З власного досвіду можу сказати, що утримання видалених повідомлень протягом всього лише семи днів може викликати зростання бази даних на 10-30%.

Управління даними користувача

Дані, які користувачі зберігають у файлах OST і PST на своєму робочому місці - в настільній системі або ноутбуці, є найбільш складними даними Exchange з точки зору обслуговування, оскільки це розподілені дані, найчастіше недоступні (з позиції адміністратора Exchange). З файлами OST клопоту менше, оскільки це просто копія вмісту поштової скриньки сервера Exchange. При використанні режиму Microsoft Office Outlook 2003 Cached Exchange Mode файл OST - повна реплікація оперативного поштової скриньки Exchange; при використанні інших режимів роботи Microsoft Office Outlook 2003 (або при роботі з більш ранніми версіями Outlook) локальний файл OST містить деяку підмножину даних серверного поштової скриньки.

З PST все інакше. Квотування розміру поштової скриньки на сервері часто змушує користувачів зберігати важливі для них дані в файлах PST, при цьому розмір файлів стає величезним (кілька сотень мегабайтів або більше) і - при локальному зберіганні - вони, як правило, обходяться процедурами резервування локальних жорстких дисків, якщо резервування використовується взагалі. Нерідко користувачі розміщують файли PST на мережевих дисках, що, природно, краще, ніж тримати їх у себе. Але хоча завдання резервування в цьому випадку спрощується, неконтрольоване зростання розміру PST-файлів як і раніше не дає адміністраторам спокою. У міру збільшення розміру PST зростає ймовірність його руйнування без можливості відновлення. Насправді виходить, що в порівнянні зі зберіганням на локальному диску у мережевого зберігання PST-файлів виявляється зовсім небагато переваг. Більш того, дані в PST, по суті, не захищені. Можна зашифрувати файли PST, але утиліти дешифрування добре відомі і доступні. Якщо користувач зберігає конфіденційні корпоративні дані в PST, скажімо, на ноутбуці, він ризикує цими даними в тому випадку, якщо ноутбук буде втрачений або вкрадений. Навіть дані PST, що зберігаються на мережевих дисках, необхідно належним чином захищати від несанкціонованого доступу. До того ж треба пам'ятати, що при наявності узаконених вимог щодо процедур архівування та тривалості використання даних обслуговуються файли PST можуть створювати масу проблем.

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

Вибір рішень для виконання резервування та, що ще важливіше, для відновлення даних буде залежати від обсягу даних, які належить обробити, і від швидкості обробки. Для даних, розміщених на сервері, багато великих компаній реалізують процедури, які дозволяють відновлювати бази даних протягом години (параметри угоди про рівень обслуговування - Service Level Agreements, SLA - в кожному конкретному випадку можуть дещо відрізнятися). Наприклад, щоб протягом години виконати відновлення бази даних розміром 40 Гбайт, розміщеної на сервері, стрічкове пристрій повинен забезпечувати швидкість відновлення (не плутати зі швидкістю резервування) не менше 10 Мбайт / с. Багато рішень резервування тепер використовують проміжну запис даних на диск перед тим, як записувати дані на стрічку, тому початкова швидкість резервування (т. Е. Швидкість передачі даних на диск) і швидкість відновлення часто істотно вище, ніж при використанні традиційного підходу за участю тільки стрічкових накопичувачів.

Рішення на базі SAN нерідко забезпечують високу швидкість передачі даних при відновленні з стрічки; цифри в діапазоні від 100 до 140 Гбайт на годину вже не є чимось незвичайним. Така продуктивність може вплинути на допустимі розміри баз даних, які призначає адміністратор. Можливість резервувати і відновлювати великі обсяги даних за більш короткий час означає, що можна створювати більші бази даних, і це тягне за собою або можливість збільшення квот на поштові скриньки, або підключення до сервера більшого числа користувачів.

Windows Server 2003 забезпечує підтримку Volume Shadow Copy Services (VSS), завдяки чому Exchange 2003 в будь-який момент може надати несуперечливу копію - знімок (snapshot) бази даних протягом декількох секунд. Слід розуміти, що це всього лише моментальний знімок диска, де розміщений файл бази даних, і якщо фізичні томи, на яких розміщується база даних, недоступні, використовувати знімок марно (хоча багато вендори постійно роблять спроби вирішити цю проблему). Отже, навіть з урахуванням тієї обставини, що знімки баз даних можуть бути отримані за кілька секунд, знімок томи як і раніше доводиться копіювати на магнітний носій (зазвичай це стрічка). Проте «відзняті» томи можуть бути відновлені протягом секунд. Підсистеми зберігання і рішення резервування / відновлення, що підтримують технологію VSS, в стані радикально вплинути на всю архітектуру управління даними, однак слід найретельнішим чином досліджувати і протестувати можливості використання VSS, перш ніж впроваджувати цю технологію в реальний бізнес.

Exchange 2003 (особливо при розгортанні Service Pack 1, SP1) пропонує нову функціональність в формі Recovery Storage Group (RSG). Призначення нової функції очевидно: якщо після збою база даних в деякій групі зберігання стає недоступною і належить виконати відновлення даних з резервної копії, для користувачів, на роботу яких вплинув цей збій, на час відновлення втрачених даних заводиться порожня аварійна база (recovery database). Хоча жодне з існуючих повідомлень користувачів протягом усього часу відновлення не буде доступно, по крайней мере забезпечується відправка і отримання електронної пошти. Після завершення відновлення вміст аварійної бази даних можна об'єднати з даними відновленої бази. При правильній організації робіт і грамотно складеному плані на випадок виникнення аварійних ситуацій концепція RSG може позитивно позначитися на дотриманні вимог SLA, а що з'явився в SP1 майстер Recover Mailbox Data Wizard спрощує завдання об'єднання відновлених і новостворених даних.

Раніше вже зазначалося, що резервування призначених для користувача даних, таких як PST, справа нелегка. Створення резервних копій PST на локальних дисках практично неможливо проконтролювати, оскільки це завдання майже повністю покладається на самого користувача. Файли PST, розміщені на мережевих дисках, можуть бути зарезервовані централізовано, але коли поштові скриньки користувачів досягають величезних розмірів, всі переваги мережевого розміщення PST пропадають.

Все про архівування

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

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

Відомо, що в Outlook є рудиментарний форма ведення архіву, за допомогою якої користувач може задати необхідність переміщення повідомлень, час зберігання яких перевищує деякий заданий термін, в файл PST. Однак при цьому відбувається просте переміщення даних з одного незахищеного місця в інше. Спеціально виділене для цих цілей надійне архівне сховище не використовується. Outlook не може розглядатися як серйозний кандидат для організації та ведення архівів.

Більш продумані рішення, наприклад KVS Enterprise Vault від компанії VERITAS Software, пропонують систему архівування, ініційовану як самим користувачем, так і на базі політик архівації, причому дані переміщаються на пристрої зберігання другого (або більш високого) рівня зберігання. Подібні рішення досить ефективні, оскільки вони можуть залишати спеціальні заглушки для повідомлення (message stub) в поштовій скриньці користувача Exchange, поки відбувається переміщення вкладень чи повідомлення в сховище. Якщо користувач хоче переглянути вміст архіву, зазвичай буває достатньо простого клацання мишкою по заглушці, після чого заархівувати повідомлення витягується. Таким чином, оптимізується використання власного сховища Exchange - величезні обсяги даних вивантажуються в систему, забезпечену запам'ятовують великої місткості і більш придатну для довготривалого зберігання інформації.

Такий тип архівного рішення нерідко інтегрується з функцією Exchange Journaling для перехоплення і відстеження всіх повідомлень, що циркулюють в середовищі Exchange. Але якщо очікується дуже великий поштовий трафік або в організації строго дотримуються вимог розпорядчих документів, то навіть системи архівування, інтегровані з Exchange Journaling, повинні бути повністю замінені більш сучасними технологіями архівування або ж уміти працювати з такими технологіями. У звичайних системах, інтегрованих з Exchange Journaling, може не забезпечуватися захист даних від перезапису або видалення, про що йдеться в більшості розпорядчих документів.

Прикладами розвинених технологій можуть служити EMC Centera і Reference Information Storage System (RISS) компанії HP. Вони дозволяють зберігати статичний контент в незмінному форматі - на диску і на RAID-масивах, гарантувати цілісність даних і їх автентичність завдяки цифровим підписам і позначці про час роботи з даними. Як правило, в таких рішеннях реалізовані системи ієрархічного зберігання Hierarchical Storage Management (HSM), що додатково дає переваги індексації контенту і швидкого пошуку. Якщо організація дотримується вимог розпорядчих документів, використання HSM стає дуже важливим, оскільки величезні масиви даних електронної пошти можуть бути дуже швидко змонтовані, і чим більша організація, тим важливіше цей фактор. Припустимо, що в середньому один користувач відправляє в день близько 20 листів, кожне розміром 25 Кбайт. Виходячи з цих оцінок виходить, що в організації, що нараховує 10 тис. Користувачів, в день відправляється близько 200 тис. Повідомлень - 4,7 Гбайт в день або 1,7 Тбайт на рік. Якщо потрібно архівувати і вхідну кореспонденцію, вимоги до підсистеми зберігання істотно зростають. Звичайно, ці розрахунки - усереднені, але мені відома компанія, де працює 9400 осіб, які щомісяця отримують від 120 до 150 Гбайт поштових повідомлень.

Багато організацій розгортають рішення архівування в якості самого першого кроку при міграції з однієї версії Exchange на іншу або при зміні всієї поштової організації. Такий підхід дозволяє прискорити міграцію і скоротити обсяг даних, задіяний при її проведенні.

Висновок

Не можна недооцінювати важливість завдання управління даними Exchange, особливо якщо поштовий трафік і розмір повідомлень продовжує зростати, а дотримання вимог розпорядчих документів стає загальною практикою. Користувачі продовжують наполягати, щоб в системі залишалося все більше і більше даних - а вони мають право цього вимагати - і щоб відновлення відбувалося швидко, а час простоїв було мінімальним. Кожен адміністратор повинен намагатися задовольнити всі побажання користувачів в рамках існуючих фінансових, технічних і розпорядчих обмежень. На щастя, того сприяє багато можливостей: квотування розміру поштових скриньок, технології зберігання, рішення архівації. Додаткова інформація про ці функції і про те, як їх можна оцінити, міститься у виразках «Комплексне управління даними Exchange» и «Управління даними: статистика» .

Кіран МакКоррі - Головний консультант підрозділу HP Advanced Technology Group в Ірландії. kieran. [email protected]

Комплексне управління даними Exchange

Неможливо розглядати проблему управління даними Exchange у відриві від всього іншого. Коли планується розгортання відповідного рішення, необхідно брати до уваги наступне.

• Одна і та ж інфраструктура зберігання часто використовується кількома програмами, тому підсистема зберігання Exchange і платформа, на якій вона працює, може вплинути на всі заходи, пов'язані з політикою компанії в області управління даними.
• Угоди про рівень сервісного обслуговування, Service Level Agreements (SLAs), що відносяться до питань зберігання даних в Exchange, тісно пов'язані з усім бізнесом компанії.
• Зберігання даних в Exchange невідривно пов'язане з питаннями архівування інформації та проходження технічним вимогам - питаннями, які вирішуються на рівні компанії в цілому.
• Всі ініціативи, що стосуються управління даними Exchange, в кінцевому рахунку є похідними бізнесу компанії і факторів її розвитку

По суті, багато організацій розглядають управління даними Exchange просто як один з компонентів в структурі управління даними компанії, яка в свою чергу є компонентом в глобальну структуру сервісного обслуговування.

Формальні рекомендації, які можуть допомогти при написанні внутрішніх процедур компанії для підвищення якості сервісного обслуговування підрозділів IT, включені в рекомендації ITIL. Рекомендації ITIL - частина загальної ініціативи IT Service Management Forum (itSMF); часто в компаніях намагаються слідувати цим рекомендаціям з урахуванням вимог стандарту BS15000. Повний опис ініціативи itSMF і її положень, що відносяться до управління даними Exchange, виходить за рамки даної статті. Але буде цілком достатньо для будь-якої організації, яка прагне рухатися шляхом сертифікації itSMF, реалізувати політики і процедури, що сприяють ефективному управлінню даними. Дізнатися докладніше про ITIL можна за адресою http://www.ogc.gov.uk/index.asp?id=2261 .