Новости

Сховище Exchange в деталях

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

сегментування сховища

Сервер Exchange 5.5 використовує єдину базу даних, при цьому на кожному сервері може бути не більше трьох баз: база поштових скриньок, база загальних папок і база каталогу. Такий принцип дозволяє створювати майже немислимі конфігурації; наприклад, у мене був один клієнт, у якого розмір бази поштових скриньок на сервері Exchange 5.5 становив близько 140 Гбайт.

Розробники Exchange 2000 на свою чергу запропонували концепцію множинних груп зберігання, кожна з яких може містити множинні бази даних;  Exchange 2003 використовує аналогічний механізм Розробники Exchange 2000 на свою чергу запропонували концепцію множинних груп зберігання, кожна з яких може містити множинні бази даних; Exchange 2003 використовує аналогічний механізм. Група зберігання SG (логічний об'єкт) - це сутність інформаційного сховища Exchange (IS), яке функціонує всередині процесу store.exe і контролює журнали транзакцій всіх поштових скриньок і бази даних загальних папок в групі. Кожна база даних є окремим логічним об'єктом, якому фізично на диску відповідають два файла.edb і.stm. Під час оновлення з Exchange 5.5 до Exchange 2000 або Exchange 2003 багато хто сприймає установки міграції за замовчуванням. Насправді це не кращий варіант, оскільки в даному випадку замість того, щоб повною мірою скористатися тими перевагами, які надають множинні бази даних, ми отримуємо у спадок від Exchange 5.5 величезну монолітну базу даних поштових повідомлень.

Для однієї групи зберігання в один і той же час можна проводити резервне копіювання або відновлення тільки однієї бази даних. Якщо ж у вас є множинні групи зберігання, можна одночасно архівувати або відновлювати множинні бази даних. Припустимо, в компанії є база даних розміром 140 Гбайт, яка розділена на чотири групи зберігання, по 35 Гбайт на базу даних кожної. Резервне копіювання розділеної подібним чином бази даних займає стільки ж часу, скільки резервне копіювання єдиної бази даних на 140 Гбайт; проте резервне копіювання індивідуальної бази даних кожної з груп зберігання займе вчетверо менше часу. Якщо ви використовуєте для архівації стрічку Стриммер, то можна додати другий привід і проводити резервне копіювання двох баз даних паралельно, скорочуючи таким чином час архівування вдвічі. Але найбільший виграш в продуктивності можна отримати, якщо здійснювати паралельне відновлення з резервної копії множинних баз даних. Якщо ви раніше зробили резервні копії множинних груп зберігання, то можна одночасно відновлювати по одній базі даних з кожної групи зберігання і значно скоротити загальний час відновлення.

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

У рекомендаціях Microsoft до першого випуску Exchange 2000 значилося побажання створювати найменш можливу кількість додаткових груп зберігання, оскільки для кожної такої групи було потрібно резервування додаткових 100-250 Мбайт оперативної пам'яті, а це дуже великий обсяг для того часу. Пакет оновлень 3 для Exchange 2000 вносить модифікації в процес резервування в вимогах до оперативної пам'яті, завдяки чому її обсяг, необхідний для додаткових груп зберігання, істотно скоротився. Нинішня рекомендація Microsoft - створювати якомога більше груп зберігання. Як показано на наведеному вище прикладі, Microsoft рекомендує створення чотирьох груп зберігання c однією базою даних для кожної замість однієї групи зберігання c чотирма базами даних, оскільки кожна група зберігання Exchange має свій набір журналів.

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

RAID

Давним-давно системні адміністратори сперечалися - а чи такий хороший масив дисків RAID в поєднанні з Exchange? Сперечалися довго, поки нарешті не вирішили: RAID-масив грає істотну роль в захисті даних Exchange. Нинішні дебати зводяться до того, який тип RAID-масиву краще використовувати.

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

Коли цілісність даних варто на першому місці (наприклад, для журналів транзакцій, системного томи), фахівці Microsoft рекомендують використовувати віддзеркалення томів. Коли і цілісність даних, і швидкість доступу до них однаково важливі, можна застосовувати RAID 5 або RAID 0 + 1. При цьому RAID 0 + 1 є більш бюджетним рішенням.

Журнали та бази даних

Якщо під час розгортання або поновлення Exchange ви приймаєте запропоновані за замовчуванням шляху розміщення файлів журналу і бази даних, то всі дані Exchange будуть розміщені на одному томі. Однак Microsoft рекомендує розміщувати журнали транзакцій і бази даних на різних томах через відмінності в механізмах доступу. Файли журналів завжди пишуться послідовно і під час зчитування журналу читаються так само. У свою чергу бази даних і пишуться, і читаються довільно, відповідно до запитів користувачів. Таким чином, існує дві причини для того, щоб не розміщувати файли журналів і баз даних на одному дисковому томі: значно знижується продуктивність і ставиться під сумнів сама можливість відновити дані у разі дискового збою. Цей ризик зберігається, навіть якщо замість звичайних дисків використовуються RAID-масиви. Розглянемо випадок, коли у нас є один великий масив RAID 5 з десяти фізичних дисків, на якому розміщені журнали транзакцій і бази даних двох груп зберігання. З точки зору високої продуктивності і можливості відновлення при збої в даному випадку можна буде використовувати два фізичних диска для створення віддзеркалювати томи для зберігання журналів транзакцій, сім дисків відвести під RAID 5 для розміщення баз даних і один диск залишити нерозмічену на випадок гарячої заміни. З огляду на особливості механізму доступу до баз даних, можна створити для їх роздільного проживання різні томи RAID 5 (кожен зі своїм набором фізичних дисків).

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

циклічне журнал

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

Однак існує пара ситуацій, в яких включення циклічного журналирования для групи зберігання може бути виправданим. Перший такий випадок - зовнішні сервери SMTP. Служба SMTP в Exchange 2003 вимагає підключення бази даних поштових скриньок для створення звітів про що не відбулася доставці. З плином часу, якщо циклічне журнал не включене, журнали транзакцій цієї бази даних займуть весь вільний дисковий простір. Ще циклічне журнал може знадобитися, якщо вам необхідно вирішити задачу, пов'язану з великою кількістю транзакцій. Наприклад, якщо вам потрібно перемістити 500 поштових скриньок з одного сервера на інший за одну ніч. Подібна дія породжує на обох серверах зростання обсягу журналів транзакцій, який можна порівняти за розміром з об'ємом переміщеної пошти. Щоб вирішити цю проблему, потрібно виконати повне резервне копіювання на обох серверах, а потім включити циклічне журнал для групи зберігання, з якої переміщаються поштові скриньки. Можна також включити циклічне журнал і на приймаючому сервері, хоча з міркувань безпеки краще цього не робити. У всіх інших випадках краще залишати циклічне журнал вимкненим щоб уникнути перезапису транзакційних даних, які можуть знадобитися в майбутньому.

SAN

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

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

Рекомендації постачальників SAN, як правило, відповідають рекомендаціям Microsoft, про які говорилося вище. Основні розбіжності в думках стосуються головним чином розміру і типу дисків, що використовуються в певних конфігураціях, а також організації масивів RAID (наприклад, пристрої від Network Applicance зазвичай використовують RAID 4, а не RAID 5). Перш ніж довірити поштові скриньки Exchange рішенням SAN, слід оцінити його продуктивність за допомогою інструменту Microsoft Jetstress tool (jetstress.msi). Завантажити цей інструмент можна за адресою http://www.microsoft.com/downloads/details.aspx?familyid=94b9810b-670e-433ab5ef-b47054595e9c&displaylang=en. Рекомендується залучити до процесу розгортання інженерів постачальника SAN. Це забезпечить впевненість в тому, що запропоноване рішення і його конкретна реалізація повністю відповідають всім вимогам, а також убезпечить від неприємних і, можливо, вельми недешевих сюрпризів в майбутньому, коли вам, може бути, буде потрібно збільшити розміри сховища.

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

Поль Робішо - в їде інженер компанії 3sharp, має сертифікати MCSE і Exchange MVP. Творець Web-сайту
http://www.exchangefaq.org . [email protected]

Перевірочна таблиця для створення ефективного сховища Exchange

  • Створіть множинні групи зберігання з однією базою даних на кожну.

  • Визначте, який тип RAID-масиву оптимально підійде для наявної конфігурації.

  • Додайте журнали транзакцій і бази даних на різних томах.

  • Увімкніть при необхідності циклічне журнал.

  • Дізнайтеся рекомендації постачальника рішення SAN по організації сховища Exchange.

Aspx?

Уважаемые партнеры, если Вас заинтересовала наша продукция, мы готовы с Вами сотрудничать. Вам необходимо заполнить эту форму и отправить нам. Наши менеджеры в оперативном режиме обработают Вашу заявку, свяжутся с Вами и ответят на все интересующее Вас вопросы.

Или позвоните нам по телефонам: (048) 823-25-64

Организация (обязательно) *

Адрес доставки

Объем

Как с вами связаться:

Имя

Телефон (обязательно) *

Мобильный телефон

Ваш E-Mail

Дополнительная информация: