none
Требования к пропускной способности канала между копиями баз RRS feed

  • Вопрос

  • Коллеги,

    Планируется развернуть Exchange 2010 в следующей архитектуре:

    В основном дата-центре активная копия базы и одна пассивная копия, во втором дата-центре вторая пассивная копия. Известен объем почтовой базы (баз). 

    Необходимо сформулировать требования к каналу между дата-центрами.

    Подскажите, пожалуйста, каким образом рассчитать?

    31 октября 2011 г. 12:21

Ответы

  • Нижняя граница меня не интересует, так как она точно соблюдается - канал 100 Мбит\с.

    Но планируемый общий объем активных баз ~30ТВ и 10000 ящиков. Надо понять хватит или нет.

    По поводу объема почтового трафика понятно, но, как я понимаю это не единственный показатель.


    Вы не совсем поняли: если загрузите канал в 100 Мбит/с под завязку, то задержки будут даже больше 500 мс :-)

    Можно с другой стороны посмотреть. У вас логи баз пишутся? Если включено циклическое логирование, то выключите его - получите логи размером 5 Мб с временной меткой за сутки/неделю - по этим данным можно рассчитать трафик репликации для любого момента времени и даже нарисовать график нагрузки в Excel.

     

    Какой у вас еще трафик помимо почтового, это вам лучше знать - варианты я указал выше.

     

     


    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    • Помечено в качестве ответа Valery Grishko 2 ноября 2011 г. 9:54
    1 ноября 2011 г. 12:01
    Модератор

Все ответы

  • Нижняя граница канала указана в документации http://technet.microsoft.com/en-us/library/dd979802.aspx

    Database copies aren't supported between Mailbox servers with round trip network latency greater than 500 milliseconds (ms).

    Сам же канал должен прокачивать ваш трафик, как минимум почтовый.

     


    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    31 октября 2011 г. 13:22
    Модератор
  • Нижняя граница в 500мс не очень интересна.

    Интересует общая методика рассчета, исходя из профиля пользователя, кол-ва почтовых ящиков, размера баз.

    1 ноября 2011 г. 5:52
  • В русской документации указана другое время.

    Копии баз данных не поддерживаются на серверах почтовых ящиков, задержка сетевого кругового пути между которыми превышает 250 миллисекунд.

    Поэтому ориентировался на цифру до 250.

    В рекомендациях по сети для DAG (http://technet.microsoft.com/ru-ru/library/dd638104.aspx#NR) упоминаеться 500мс.


    MCITP. Знание - не уменьшает нашей глупости.
    1 ноября 2011 г. 6:53
    Модератор
  • Нижняя граница в 500мс не очень интересна.

    Интересует общая методика рассчета, исходя из профиля пользователя, кол-ва почтовых ящиков, размера баз.


    Как раз нижняя граница для вас это самое главное: если канал будет хуже, то репликация DAG будет нарушаться.

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

    Либо можете сделать замеры роста базы/почтовых ящиков в ЧНН. Это даже лучше.

     


    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    1 ноября 2011 г. 7:51
    Модератор
  • Нижняя граница в 500мс не очень интересна.

    Интересует общая методика рассчета, исходя из профиля пользователя, кол-ва почтовых ящиков, размера баз.


    Как раз нижняя граница для вас это самое главное: если канал будет хуже, то репликация DAG будет нарушаться.

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

    Либо можете сделать замеры роста базы/почтовых ящиков в ЧНН. Это даже лучше.

     


    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/

    Илья,

    Нижняя граница меня не интересует, так как она точно соблюдается - канал 100 Мбит\с.

    Но планируемый общий объем активных баз ~30ТВ и 10000 ящиков. Надо понять хватит или нет.

    По поводу объема почтового трафика понятно, но, как я понимаю это не единственный показатель.

    1 ноября 2011 г. 10:18
  • При реализации 3-х Цодового расположения DAG основной проблемой была стабильность данного канала и нагрузка на ядро в пиковые часы.

    Если реализуеться проект у вас с территориально распределенными цодами, то одним из камней преткновения будет построение GEO NLB. 


    MCITP. Знание - не уменьшает нашей глупости.
    1 ноября 2011 г. 11:01
    Модератор
  • Нижняя граница меня не интересует, так как она точно соблюдается - канал 100 Мбит\с.

    Но планируемый общий объем активных баз ~30ТВ и 10000 ящиков. Надо понять хватит или нет.

    По поводу объема почтового трафика понятно, но, как я понимаю это не единственный показатель.


    Вы не совсем поняли: если загрузите канал в 100 Мбит/с под завязку, то задержки будут даже больше 500 мс :-)

    Можно с другой стороны посмотреть. У вас логи баз пишутся? Если включено циклическое логирование, то выключите его - получите логи размером 5 Мб с временной меткой за сутки/неделю - по этим данным можно рассчитать трафик репликации для любого момента времени и даже нарисовать график нагрузки в Excel.

     

    Какой у вас еще трафик помимо почтового, это вам лучше знать - варианты я указал выше.

     

     


    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    • Помечено в качестве ответа Valery Grishko 2 ноября 2011 г. 9:54
    1 ноября 2011 г. 12:01
    Модератор
  • Спасибо.
    2 ноября 2011 г. 9:54