Статьи

Сховище Exchange 2013

  1. Вступ
  2. структура файлів
  3. .edb
  4. .log
  5. .chk
  6. .jrs
  7. Принцип роботи
  8. B +-дерево
  9. сторінка даних
  10. транзакції
  11. стану бази
  12. Покращення в Exchange 2013
  13. функціональні
  14. архітектурні
  15. покращення продуктивності
  16. Кращі практики
  17. планування розгортання
  18. Віртуалізація
  19. Повсякденні завдання адміністрування

www.microsoft.com

Сховище Exchange 2013 викликає традиційно багато питань з приводу свого принципу роботи, обслуговування та траблшутінга - Як все влаштовано? Чому в папці з базою стільки файлів? Чи можу я ці файли видалити? А що значить Dirty Shutdown? і багато інших. Ця стаття створена з метою пролити світло на принцип роботи цього складного і дуже важливого компонента поштового сервера Microsoft.

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

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

Вступ

Бази даних Exchange 2013 - це напевно найперше, з чим адміністраторам доводиться стикатися при роботі зі сховищем. Багато питань викликає велика кількість файлів в каталогах з базами. Ще більш сильне здивування відчувають досвідчені адміністратори СУБД, яким доводилося працювати не більше ніж з двома файлами БД наприклад у MS SQL.

Саме з огляду структури файлів я і планую почати статтю, пізніше перейшовши до теоретичних основ і закінчу порадами з адміністрування і розгортання.

структура файлів

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

Примітка: Насправді ім'я каталогу і бази даних можуть відрізнятися. Ім'я БД міститься в атрибуті Name, а ім'я каталогу фігурує в рядку шляху до бази даних і до журналів транзакцій. Значення цих параметрів містяться в атрибутах EdbFilePath і LogFolderPath відповідно і можуть вказувати на будь-які локальні розташування

У цільовому каталозі БД знаходиться безліч файлів. Це і файл самої бази, і файли журналів транзакцій (якщо звичайно ви не розмістили їх окремо) і багато інших. Залежно від розширення, всіх їх можна згрупувати в 4 типи. Уявімо ієрархію сховища на прикладі однієї БД:

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

До теперішнього моменту у читача в голові напевно велика плутанина, а тому потрібно розставити все на свої місця. Почнемо з того, що опишемо для чого призначений кожен файл.

.edb

Розширення .edb мають файли баз даних, яких у каталозі кожної БД буває не більше двох штук.

  • Database 1.edb (ім'я взято для прикладу) - основний файл БД. Є сховищем корисних даних і їх кінцевим місцем призначення. Файл, як я і згадував раніше, зазвичай збігається з ім'ям каталогу, в якому він знаходиться. На практиці розмір БД обмежений лише можливостями обладнання та файлової системи. Теоретичний максимум становить 16ТБ (обмеження ntfs);
  • tmp.edb - також файл БД, але його завдання відрізняється. Він призначений для проміжного зберігання даних в процесі виконання транзакцій. Файл існує лише в той момент, коли база змонтована і пропадає в момент від'єднання БД. Важить не більше декількох мегабайт.

Якщо ім'я tmp.edb встановлено системою і адміністраторам не дано його змінити, то ім'я основного файлу БД ви можете вибрати на свій розсуд. По суті це єдиний файл в каталозі, ім'ям якого ви можете управляти.

Всі інші файли мають в своєму імені однаковий префікс E nn, в якому букви nn означають порядковий номер бази. Найперша база на сервері буде мати номер 00, друга база - 01, третя 02 і так далі.

Примітка: Якщо будь-яку базу видалити, то її порядковий номер звільниться і надалі присвоїти наступної створеній базі. Тобто, якщо на сервері були бази з префіксами E00, E01, E02 і в якийсь момент база з префіксом E01 була видалена, то коли на сервері буде створена ще одна база, їй буде призначений префікс E01

Нумерація йде в десятковій системі числення і, як можна легко здогадатися, максимальна кількість баз на сервері становить 100 штук для версії Enterprise (до Exchange 2013 CU2 - 50 БД для Enterprise), в версії Standard максимальна кількість активних баз даних штучно обмежена 5 шт.

.log

Лог-файли бувають трьох видів:

  • E nn .log - поточний файл журналу транзакцій. Саме в нього йде безперервний запис всіх транзакцій і як тільки досягається розмір в 1 МБ (1024КБ), він перейменовується і на його місці створюється новий E nn .log;

Примітка: розмір логів в 1 МБ був введений в Exchange Server 2007, більш ранні версії використовували дефолтний розмір в 5МБ.

  • E nn tmp.log - проміжний файл журналу транзакцій. Коли E nn .log наближається до граничного обсягу, створюється файл E nn tmp.log розміром в 1 МБ. Як тільки поточний файл логу транзакцій заповнюється повністю, движок сховища перейменовує його для подальшого зберігання, привласнюючи наступний усе своєю чергою номер (див. Нижче). Файл E nn tmp.log при цьому також змінює ім'я і стає поточним файлом журналу транзакцій (E nn .log). Цей механізм необхідний для забезпечення безперервного запису даних в журнали;
  • Enn00000001.log - EnnFFFFFFFF.log - архівні файли журналу транзакцій. Будь поточний файл логів - E nn .log - в момент досягнення свого максимального обсягу перейменовується в архівний файл. Нумерація файлів йде в шістнадцятковій системі числення і може забезпечити одночасне існування більш ніж 4 мільярдів файлів журналу транзакцій. Ці файли потрібні для відновлення даних у разі збоїв. Якщо у вас є повна резервна копія, то необхідність в журналах, зроблених до її створення, відпадає. Саме тому при правильному виконанні резервного копіювання відбувається автоматичне усічення логів транзакцій.

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

.chk

У каталозі з БД завжди знаходиться всього лише один файл .chk:

  • E nn .chk - файл контрольної точки. Інформація, що зберігається в логах транзакцій, може не відразу записуватися в базу даних і після збоїв в роботі движок сховища не знатиме в яких журналах і які саме транзакції вже застосовані до бази, а які ні. Саме для цього і існує файл контрольної точки, який містить актуальні відомості про останню застосованої транзакції і журналі, в якому вона знаходиться.

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

З опису принципу роботи контрольних точок зрозуміло, що транзакції в журналах старше контрольної точки будуть застосовані до бази, а всі транзакції з більш свіжою відміткою часу будуть знаходитися в журналах і оперативної пам'яті сервера, але не в самій базі:

З опису принципу роботи контрольних точок зрозуміло, що транзакції в журналах старше контрольної точки будуть застосовані до бази, а всі транзакції з більш свіжою відміткою часу будуть знаходитися в журналах і оперативної пам'яті сервера, але не в самій базі:

Виникає цілком логічне запитання - «До якої межі сервер може тримати дані в оперативній пам'яті і журналах, які не скидаючи їх у БД?» Для Exchange 2013 порогове значення становить 100МБ (тобто 100 журналів транзакцій) для кожної бази даних і в технічній термінології має назву глибина контрольної точки (Checkpoint Depth).

.jrs

Переходимо до останнього типу файлів:

  • E nn res0001.jrs - E nn res000A.jrs (всього 10 штук) - резервні файли журналу транзакцій. По суті не містять в собі будь-якої корисної інформації, а лише резервують необхідне місце на той випадок, якщо дисковий простір закінчиться. У процесі перейменування поточного файлу журналу в архівний повинен створюватися файл E nn tmp.log, але якщо з причини відсутності вільного місця драйвер сховища не зможе його створити, він почне писати дані в резервні файли журналу.

Ось так виглядає каталог із середньостатистичною базою даних Exchange 2013:

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

Принцип роботи

В основі сховища Exchange 2013 лежить ESE (Extensible Storage Engine) - движок на базі індексного-послідовного методу доступу до даних (скорочено ISAM - Indexed Sequential Access Method), який використовує модель зберігання інформації у вигляді збалансованих дерев (B +-дерево).

B +-дерево

Структура B-tree вдає із себе перевернуте дерево з коренем - батьком елементів (сторінок даних) - у верхній частині і листям в нижній і виглядає наступним чином:

На рівні Root і Internal розташовуються сторінки зі службовими даними - покажчиками. «Листя» - Leaf - містять сторінки з корисними даними (наприклад з поштою користувачів). Завдяки такій структурі забезпечується швидкий доступ до даних, минаючи необхідність послідовного перебору всієї інформації до того моменту, поки не буде знайдено потрібну.

Плюс ( «+«) в назві B + -tree означає деякі поліпшення в класичній моделі B-tree, а саме покажчики на попереднього і наступного сусіда у кожного аркуша. Це необхідно для швидкого отримання корисних даних замість того, щоб для зчитування кожної наступної сторінки даних знову проходити шлях від кореня дерева. Таке удосконалення має і негативну сторону - для підтримки покажчиків в актуальному стані доводиться витрачати додаткові ресурси, логіка роботи движка сховища ускладнюється.

Буква «B» - скорочення від Balanced (збалансоване) - означає, що довжина двох будь-яких шляхів від кореня до листя у всьому дереві збігається.

В БД знаходиться безліч збалансованих дерев, з яких, в свою чергу, складаються таблиці, а безліч таблиць утворює схему бази даних ::

В БД знаходиться безліч збалансованих дерев, з яких, в свою чергу, складаються таблиці, а безліч таблиць утворює схему бази даних ::

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

сторінка даних

Сторінка даних складається з заголовка, покажчиків на інші сторінки, контрольної суми (механізм визначення факту пошкодження даних) і безпосередньо з самих даних (у разі якщо сторінка є листом в ієрархії дерева). Сервер не може вважати половину або півтори сторінки, оскільки вони є неподільними одиницями. Розмір сторінки в Exchange 2013 і 2010 року становить 32КБ, в більш ранніх версіях використовувався розмір 8Кб, що вимагало більше операцій введення / виводу для зчитування одного і того ж обсягу даних.

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

У підтримці всієї цієї структури в нормальному вигляді якраз і полягає головне завдання ESE.

транзакції

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

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

Примітка: розглянемо приклад - ви видалили лист із вкладенням, але в логах транзакцій продовжить існувати інформація про те, що ви колись отримали цей лист. Більш того, в транзакціях позначиться і факт видалення цього листа.

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

стану бази

В процесі роботи корисні дані (наприклад ваша пошта) на сервері зазвичай знаходяться в різних місцях - в оперативній пам'яті, на жорсткому диску в журналах транзакцій і в файлах баз даних. Все це призводить до того, що база даних знаходиться в неузгоджену стані і це абсолютно нормально. Коректне відключення бази призведе до того, що інформація в журналах і в тимчасовій базі даних скинуться в основну БД, база размонтіруйте і буде перебувати в стані Clean Shutdown:

Якщо ж робота сервера була завершена аварійно або відбулося некоректне відключення БД, то стан бази буде Dirty Shutdown:

Це означає, що база даних знаходиться в неузгоджену стані і для виправлення цієї ситуації необхідно застосувати до неї відсутні транзакції, які перебували в журналах на момент збою (рядок Log Required явно натякає на це). Цей процес називається м'яке відновлення (Soft Recovery) і має на увазі, що дотримані кілька умов:

  1. Файл бази даних знаходиться в справному стані;
  2. Існують і знаходяться в справному стані всі необхідні журнали транзакцій.

В іншому випадку необхідно проводити грубе відновлення (Hard Recovery), в процесі якого неминуче буде втрата даних. Скільки саме інформації не вдасться відновити, залежить від конкретної ситуації.

Примітка: докладніше про принцип роботи сховища ви зможете знайти в офіційній документації, в тому числі і для попередніх версій Exchange Server.Але будьте уважні - між версіями є істотні відмінності, особливо це стосується Exchange 2007 і старше.

Покращення в Exchange 2013

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

функціональні

В Exchange 2013 були додані наступні нові функції:

  • Кілька баз даних на одному логічному диску. Дана можливість дозволяє більш ефективно використовувати дисковий простір;
  • Автоматичне повторне заповнення (AutoReseed). У разі збою диска для копій бази даних (на будь-якому сервері DAG), що зберігаються на ньому, автоматично виконується повторне заповнення на попередньо налаштованому вільному диску на сервері поштових скриньок.

Примітка: на думку спадає аналогія з диском гарячого резерву (hot spare) для масивів raid.

  • Автоматична настройка мережі в DAG. Адміністратору більше не потрібно підтримувати окремо мережу для DAG, за нього це робить система. Проте, можливість ручного налаштування залишилася (командлет Set-DatabaseAvailabilityGroup, значення - ManualDagNetworkConfiguration $ true).

У 2013 версії Exchange є і маса інших функціональних поліпшень, у тому числі і не пов'язаних зі сховищем.

архітектурні

Основні поліпшення в архітектурі сховища Exchange 2013:

  • Поділ примірника процесу сховища. Тепер для обслуговування кожної бази даних виділяється окремий робочий процес сховища (Microsoft.Exchange.Store.Worker.exe), замість одного єдиного для всіх БД в Exchange 2010. Керує ними окремий процес служби сховища (Microsoft.Exchange.Store.Service.exe) , реплікація даних здійснюється через процес служби реплікації Microsoft Exchange (MSExchangeRepl.exe).

exe)

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

  • Активний моніторинг. Сервіс створений для безперервного моніторингу і усунення виникаючих проблем в автоматичному режимі. Лише після невдалих спроб відновлення працездатності йде оповіщення адміністратора через журнал подій. Існує можливість тонкої настройки. Реалізовано двома службами:
    • Служба диспетчера працездатності Exchange (MSExchangeHMHost.exe). Використовується для побудови, виконання, відновлення, запуску і зупинки робочих процесів в міру необхідності;
    • Робочий процес диспетчера працездатності Exchange (MSExchangeHMWorker.exe).

exe)

Примітка: на мій погляд сервіс ще досить «сирий» і якісну діагностичну інформацію вдається отримати не завжди. Проте, унікальними в діагностиці можуть виявитися командлети Get-ServerHealth, Get-HealthReport. У будь-якому випадку ігнорувати такий функціонал було б неправильним рішенням.

  • Служба управління DAG (доступна після CU2). Розширює функцію внутрішнього моніторингу DAG, яка раніше виконувалася в службі реплікації Microsoft Exchange (MSExchangeRepl).
  • DAG без адміністративної точки доступу (AAP - Administrative Access Point) кластера. У Windows Server 2012 R2 з'явилася можливість створювати кластери DAG без використання окремого ip-адреси (Командлети New-DatabaseAvailabilityGroup з параметром - DatabaseAvailabilityGroupIPAddresses None). Нововведення спрощує адміністрування, а також істотно знижує поверхню атаки, адже ні додаткового адреси, ні додаткової записи в DNS більше не буде.

Це далеко не повний список поліпшень сховища. Для більш детального вивчення рекомендую звернутися до офіційної документації.

покращення продуктивності

Нововведення, що сприяють зменшенню операцій введення / виводу для виконання одних і тих же завдань у порівнянні з попередніми версіями Exchange:

  • Глибина контрольних точок пасивних копій DAG збільшена з 5 до 100МБ. Раніше підтримувався лише невеликий кеш в 5МБ, чого було явно недостатньо. Як наслідок - пасивна копія бази даних потребувала такого ж кількості операцій введення / виводу, як і активні БД. Також це забезпечує швидшу відпрацювання відмови в разі проблем з активною копією;
  • Оптимізація фонового обслуговування баз даних. Швидкість зменшена з 5 до 1 МБ / сек, що позитивним чином позначилося на загальне навантаження на дискову підсистему.

Є й маса інших поліпшень продуктивності сховища, але Microsoft не надає докладних описів і обмежується лише короткими формулюваннями.

Кращі практики

Нижче сформульовані основні рекомендації щодо розгортання та обслуговування сховища Exchange 2013.

планування розгортання

Перед розгортанням Exchange 2013 важливо правильно спланувати і налаштувати сховище:

  • Між завданнями повного бекапа дисковий простір неодмінно буде заповнюватися логами транзакцій. Важливо, щоб при цьому завжди залишалося вільне місце, інакше ви ризикуєте зіткнутися з простоями в роботі. Розрахуйте необхідну вільне місце на кожному диску з базами даних в залежності від політик резервного копіювання вашої організації і тримайте необхідний запас;
  • Сховище Exchange 2013 оптимізовано для роботи з великими поштовими скриньками, аж до десятків гігабайт. При цьому реальне навантаження на дискову підсистему значно зменшена в порівнянні з Exchange 2010. Самою оптимальною стратегією в цьому випадку буде покупка ємних сховищ з дешевими enterprise-дисками SATA великого обсягу. Міцні та надійність рішення забезпечується на прикладному рівні технологією DAG;
  • Кожна база даних не повинна перевищувати обсяг в 2ТБ. У невеликих організаціях Exchange 2013 обсяг навіть в 200ГБ на кожну БД може здатися великою - визначте оптимальний для своєї інфраструктури обсяг БД, врахуйте пропускну здатність мережі, продуктивність дискової підсистеми серверів і сховищ бекапа і приймайте остаточні технічні рішення в контексті забезпечення SLA.
  • Обов'язково розносите на різні диски ОС і бази даних.

Додаткові рекомендації і вимоги по сховищу дивіться в офіційній документації.

Віртуалізація

Рекомендації для віртуальної інфраструктури:

  • Не використовуйте знімки віртуальних машин для серверів Exchange 2013 ні за яких обставин;
  • Використовуйте тільки .vhdx-диски фіксованого обсяг. Fixed .vhdx забезпечать кращу продуктивність. Крім цього, вони ще й більш функціональні:

Крім цього, вони ще й більш функціональні:

  • Використовуйте віртуальні машини другого покоління для забезпечення більш гнучкого технічного обслуговування і більш високої продуктивності завдяки кращій оптимізації для роботи в віртуалізованому середовищі;

Не забудьте відвідати розділ документації на technet з планування віртуального Exchange 2013.

Повсякденні завдання адміністрування

Правильно сплановане сховище Exchange 2013 позбавить вас від багатьох неприємних проблем в майбутньому. Проте, при повсякденному адмініструванні важливо пам'ятати деякі нюанси:

  • Необхідність в резервному копіюванні БД теоретично відпадає в тому випадку, якщо кожна база існує як мінімум в трьох онлайн копіях DAG;
  • Функція автоматичного повторного заповнення може підвищити надійність і поліпшити захист від потенційної втрати даних. Розгляньте можливість впровадження цієї опції, доступною вперше в Exchange 2013;
  • Використовуйте циклічне ведення журналу тільки в тому випадку, якщо база даних існує як мінімум в трьох активних копіях DAG. У всіх інших випадках забудьте про circular loging, якщо не хочете ризикувати безпекою даних;

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

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

comments powered by HyperComments
Чому в папці з базою стільки файлів?
Чи можу я ці файли видалити?
А що значить Dirty Shutdown?

Новости