none
Как разбить диски на Mailbox-серверах (члены DAG) RRS feed

  • Вопрос

  • Коллеги, поделитесь опытом.

    Планируем инсталляцию на большое кол-во ящиков, рассчитали требования с помощью калькулятора, получается по 20 баз на сервер (максимальный размер базы поставили 1000 Гб). Теперь необходимо определиться как разбить диски. В качестве основного варианта у меня такой:

    LUN1 - 500 Гб система (диск C)

    LUN2 - 2000 Гб (диск D)

    LUN3 - 2000 Гб раздел под базу 1 + логи (смонтировать в D:\MailboxDatabase1)

    LUN4 - 2000 Гб раздел под базу 2 + логи (смонтировать в D:\MailboxDatabase2)

    .

    .

    LUN22 - 2000 Гб раздел под базу 2 + логи (смонтировать в D:\MailboxDatabase20)

    Интересует ваше мнение, нормально, соответствует общим практикам?

    31 августа 2012 г. 8:15

Ответы

Все ответы

  • День добрый.

    Understanding Storage Configuration

    Understanding Mailbox Database and Log Capacity Factors

    Смоте столбец High availability: supported or best practice

    Если у вас DAG на 3 сервера, то логи цыклические и базы данных можно увеличить до 1800Mb.


    MCITP. Знание - не уменьшает нашей глупости.

    31 августа 2012 г. 8:35
    Модератор
  • Полезная ссылка, спасибо.

    >Если у вас DAG на 3 сервера, то логи цыклические и базы данных можно увеличить до 1800Mb.

    В принципе, да, но в этом случае инкрементный и дифференциальный бэкапы будут недуступны, пока не решил, критично для нас это или нет.

    Вы поддерживаете меня в части отдельный LUN для каждой базы и монтирование их на D?

    31 августа 2012 г. 9:03
  • Да, отдельный LUN для каждой базы, так всегда реализуется, обьяснения в первой ссылке.

    Circular Logging and Mailbox Database Copies


    MCITP. Знание - не уменьшает нашей глупости.

    • Помечено в качестве ответа Valery Grishko 31 августа 2012 г. 10:54
    31 августа 2012 г. 9:24
    Модератор
  • Да, отдельный LUN для каждой базы, так всегда реализуется, обьяснения в первой ссылке.

    Circular Logging and Mailbox Database Copies


    MCITP. Знание - не уменьшает нашей глупости.


    Я добавлю, что дело не в названии "LUN", а что за ним стоит, т.е. хотя Exchange 2010 достаточно неприхотлив параметрам хранилища по сравнению с предыдущими версиями, хранилище должно давать реальные, а не "виртуальные" параметры.

    Сазонов Илья http://isazonov.wordpress.com/

    31 августа 2012 г. 15:46
    Модератор
  • Полезная ссылка, спасибо.

    >Если у вас DAG на 3 сервера, то логи цыклические и базы данных можно увеличить до 1800Mb.

    В принципе, да, но в этом случае инкрементный и дифференциальный бэкапы будут недуступны, пока не решил, критично для нас это или нет.

    Вы поддерживаете меня в части отдельный LUN для каждой базы и монтирование их на D?

    1. Основная задача DAG - повысить доступность почтовых баз, что DAG и делает с успехом. Как следствие при правильном проекте DAG целиком исключает необходимость в циклическом логировании и инкрементном бакапе. Но совсем DAG не перекрывает возможности полного бакапа. Например, если вам нужно будет восстановить документ двух годовой давности, то без бакапа тут не обойтись. Нет, теоретически DAG может и это перекрыть, но с практической точки зрения это не оптимально, т.к. приводит к неоправданному раздутию баз информацией, которая на 99% не нужна. Как часто делать полный бакап базы, это уже отдельная история.

    2. Если у вас уже 20 баз из расчета по 1 ТБ, то вам уже не принципиально 20-ть их или 80-т. Во-первых, вам в любом случае нужна версия Enterprice с поддержкой до 100 баз. Во-вторых, обслуживать два десятка баз или восемь абсолютно одинаковые трудозатраты. Это я все к тому, что сделайте базы как можно меньше и пусть их будет много: чем меньше размер базы, тем меньше потерь при ее отказе (DAG развалилися, репликация не прошла) и тем быстрее вы можете ее восстановить. Например, если вам нужно 30 минут на восстановлении 100 ГБ базы вместе в перекурами, то на базу в 1 ТБ вам придется потратить целый рабочий день или всю ночь.

    3. Следует из п.2. Сделайте не три, а большее число MB серверов. Тут как с RAID5: чем больше дисков, тем меньше потери; только в случае с серверами растут системные расходы, но полагаю они виртуальные, и это скрадывает подобные накладные издержки.

    Плюс ко всему такой подход облегчит миграцию на Exchange 2013. Верьте :-)


    Сазонов Илья http://isazonov.wordpress.com/

    31 августа 2012 г. 16:22
    Модератор
  • Илья, все это правда, что вы говорите.

    Но по пункту 2 и 3, все упирается в SLA/OLA и если у заказчика эти критерии описаны и эти требования диктует бизнес, то все это реализуется. При отсутствии у бизнеса понимания SLA/OLA, а в приоритете стоит стоимость оплаты лицензий, очень сложно доносить им информацию о рекомендации 3 серверов в DAG.


    MCITP. Знание - не уменьшает нашей глупости.

    3 сентября 2012 г. 5:48
    Модератор
  • Подскажите, пожалуйста, принципиально ли использовать отдельную сеть для репликации? Сделать реально независимую сеть нет возможности, скорость интерфейсов 1000Гб. Нужно ли городить огород со вторыми сетевухами?

    У нас 3 Mailbox сервера, аппаратные.

    3 сентября 2012 г. 12:33
  • Два сетевых адаптера повышают отказоустойчивость.

    В случае выхода из строя DAG Network, dag автоматически переключаеся на Mapi Network.

    Exchange 2010: Collapsing DAG Networks

    REF: Planning Exchange 2010 DAG – Part 1 – Network Requirements


    MCITP. Знание - не уменьшает нашей глупости.

    3 сентября 2012 г. 12:44
    Модератор
  • Если нет возможности аппаратно вынести сеть DAG на отдельное оборудование, то городить огород со вторыми картами смысла нет вообще: достаточно того, что при отказе база станет активной на другом MB сервере.

    Сазонов Илья http://isazonov.wordpress.com/

    • Помечено в качестве ответа Valery Grishko 24 октября 2012 г. 14:17
    5 сентября 2012 г. 3:22
    Модератор