Главная Exchange/UC, Новое Отказоустойчивый Exchange 2010 (DAG + NLB)
  • Отказоустойчивый Exchange 2010 (DAG + NLB)

    exchange20102

    UPD: Исправлен недочет в разделе организации NLB-массива.

    Сегодня ни кто уже не будет спорить, что почтовая система в каждой организации является одним из самых важных и уязвимых мест. Сточки зрения бизнеса, корпоративная почта должна быть доступна в режиме 24/7, т.к. часто запоздалая отправка, либо несвоевременное получение всего одного письма может принести компании ощутимый финансовый и имиджевый урон. В связи с этим, ИТ-администраторы предпринимают всяческие меры по обеспечению отказоустойчивости почтовых серверов. До выхода Exchange 2007 это было достаточно не простой задачей. Затем в 2007-м Exchange`е компания Microsoft изменила эту ситуацию, введя две новые функции CCR и SCR, которые, надо заметить, были весьма успешными в деле организации безаварийной работы.

    С выходом Exchange 2010, Microsoft пошла ещё дальше и улучшила функции CCR и SCR, соединив две функции в одном компоненте DAG (Database Availability Group), DAG стала новой функцией непрерывной доступности баз данных почтовых ящиков. Функция DAG, как и CCR, зависит от ограниченного набора компонентов отказоустойчивой кластеризации Windows (Failover Cluster), в основном, от базы данных кластера, файлового ресурса-свидетеля и функции импульса синхронизации. Группы DAG обеспечивают защиту на уровне базы, сервера и узла и делают развертывание решения высокой доступности и аварийного восстановления на уровне сайта гораздо проще, нежели в предыдущих версиях Exchange.

    Но обеспечить отказоустойчивость баз данных это ещё пол дела, также нужно обеспечить непрерывный доступ самих пользователей к этим базам данных. Как известно, за работу с почтовыми клиентами в Exchange отвечает CAS (Client Access Service). Для организации отказоустойчивости этой службы существует Client Access Array, который позволяет объединить несколько CAS серверов в массив, а затем настроить доступ к FQDN этого массива при помощи стандартного Windows NLB (Network Load Balancing) кластера.

    Кроме ролей Mailbox Server и Client Access Server существует ещё и роль транспортного сервера-концентратора (Hub Transport Server), как же быть с ней в плане отказоустойчивости? А с ней совсем делать ни чего не надо, достаточно установить на два или более сервера Exchange 2010 эту роль и отказоустойчивость будет обеспечена автоматически, т.к. транспортные серверы-концентраторы Exchange отказоустойчивы по умолчанию. То есть, при наличии более чем одного транспортного сервера-концентратора, развернутого на сайте Active Directory, и в случае недоступности одного из транспортных серверов-концентраторов в этом сайте Active Directory исходный транспортный сервер-концентратор, пытающийся доставить сообщение, перейдет к следующему транспортному серверу-концентратору в этом сайте Active Directory. Это проделывается с помощью механизмов циклического опроса DNS (если первый транспортный сервер-концентратор в списке не отвечает, переходим к следующему). Так что когда речь заходит о связи между двумя транспортными серверами-концентраторами или между сервером почтового ящика и транспортным сервером-концентратором (то есть внутренней), нам не нужно заботиться о высокой доступности (или балансировке, если на то пошло), поскольку это собственные функции Exchange 2010. Но не забывайте, что в случае установки роли транспортного сервера-концентратора на компьютере, где также установлена роль сервера почтовых ящиков, роль сервера почтовых ящиков будет предпочитать локальный транспортный сервер-концентратор любым другим транспортным серверам-концентраторам в сайте Active Directory (даже если локально установленный транспортный сервер-концентратор недоступен), когда служба отправки почты Microsoft Exchange отправляет сообщения. Но данный факт не относится к серверам, включенным в DAG группу. В случае, если Hub Transport`ы установлены на сервера MailBox, входящие в DAG, то сервера почтовых ящиков будет предпочитать любой другой Hub Transport в сайте AD, и только в последнюю очередь будут обращаться к локальным.

    Теперь перейдем от теории к практике и посмотрим, как обеспечить отказоустойчивость Exchange 2010.

    Для этого построим принципиальную схему организации почтовой системы предприятия:

    Рис.1. Принципиальная схема почтовой системы предприятия

    Примечание: Настройку сервера EDGE Transport в этой статье рассматривать не будем (о ней можно почитать тут). Так же не будем рассматривать процедуру установки Exchange серверов (это совсем не сложно), единственное, в чем хочу вас предостеречь, так это в том, что не стоит пытаться устанавливать несколько серверов одновременно (даже в тестовой среде), необходимо дождаться окончания установки одного сервера, а затем приступать к инсталляции другого, в противном случае системные ошибки неизбежны.

    Перейдем к настройке Database Availability Group

    Важно отметить, что в каждую DAG группу может входить до 16 серверов почтовых ящиков, таким образом, вы сможете иметь до 16 копий каждой базы (хранение более одной копии базы почтовых ящиков на каждом сервере не поддерживается, а также активной может быть только одна копия), причем нужно не забывать, что каждый Exchange 2010 Standard может поддерживать только 5 баз данных, а Enterprise версия – до 100 баз. Время переключение между базами в Exchange 2010 заметно снижено, и теперь составляет порядка 30 секунд, а если учесть тот факт, что клиенты общаются с базами данных через Client Access Servers, то они совсем не заметят этого перехода. Также в Exchange 2010 предпринята попытка отказаться от публичных папок (Public Folders), и хотя они все ещё поддерживаются, но теперь их нельзя включить в группу DAG и обеспечивать их доступность придется при помощи стандартных механизмов репликации баз данных публичных папок.

    Как уже говорилось выше, группы DAG в своей работе используют часть компонентов системы отказоустойчивых кластеров (Failover Clusters), таким образом, как и в классическом отказоустойчивом кластере, серверам нужно иметь по два сетевых интерфейса: один для MAPI-доступа клиентов, другой для трафика heartbeat/replication, по которому будет отслеживаться состояние узлов кластера. Хотя решения с одним сетевым интерфейсом на каждом сервере поддерживаются, но мы не будем экспериментировать и возьмем две сетевых карты, одна будет смотреть в локальную сеть предприятия и будет иметь адрес из диапазона 192.168.0.0/24, другая – в изолированную сеть с адресным пространством 192.168.1.0/24.

    Рис.2: Принципиальная схема Database Availability Group

    На интерфейсе для Heartbeat`ов можно отключить такие компоненты сетевого взаимодействия, как TCP/IPv6, Client for Microsoft Network, File and Printer Sharing и
    даже QoS. Затем надо проверить что локальный сетевой интерфейс находится первым в списке порядка привязки, для этого пойдем в меню Advanced (Дополнительно) > Advanced Settings (Дополнительные параметры) и посмотрим в раздел Connections.

    Что касается организации хранилищ для баз данных почтовых ящиков, то теперь вам не придется приобретать высокоскоростные, а, следовательно, и дорогие жесткие диски. В связи с изменениями в механизме расширяемого хранилища (ESE), с Exchange 2010 вы получаете вариант использования таких дисков с низкой производительностью, как диски SATA 7200! Фактически, вы можете размещать активную копию базы данных на одном SATA диске, а все остальные копии вместе – на другом, и ни каких проблема с производительность дисковой подсистемы у вас быть не должно. Правда тут надо заметить, что вместе с улучшениями в организации работы с жесткими дисками, у Exchange 2010 ещё более возрос аппетит к оперативной памяти сервера и теперь, Microsoft говорит, что !каждую роль! Exchange 2010 необходимо обеспечить 4 Гб оперативной памяти. Возможно это и некоторое преувеличение, но практика покажет, как дела обстоят на самом деле.

    Для функционирования DAG, кроме самих серверов Exchange 2010 необходим ещё один сервер, не входящий в группу DAG, он будет выполнять роль сервера-свидетеля, это что-то вроде кворума в классическом отказоустойчивом кластере и именно с помощью него отслеживается состояние серверов, входящих в DAG. Для организации сервера-свидетеля подойдет любой сервер в сайте Active Directory, даже без установленного Exchange 2010, единственным условием его функционирования является то, что в группу его локальных администраторов должна входить доменная группа Exchange Trusted Subsystem.

    Рис.3: Доменная группа
    Exchange Trusted Subsystem в группе локальных администраторов сервера-свидетеля.

    Итак, все подготовительные работы завершены, теперь давайте создадим новую DAG-группу. Для этого перейдем в раздел Organization Configuration (DAG находится именно на уровне организации), откроем вкладку Database Availability Groups и в меню Действия выберем New Database Availability Group… Откроется мастер конфигурирования DAG:

    Рис.4: Мастер настройки DAG

    Здесь нужно вписать имя группы, имя сервера-свидетеля (не забываем, что он не должен входить в DAG) и имя папки, где будет храниться информация о состоянии Exchange серверов (мастер создаст папку на удаленном сервере сам). Далее, если все настроено правильно, то мастер создаст группу и следующим шагом нам нужно будет добавить в неё сервера, для этого нажмем на группе правой кнопкой мыши и выберем пункт Manage Database Availability Group. В данном мастере необходимо добавить сервера с установленной ролью Mailbox, которым мы хотим обеспечить высокую доступность:

    Рис.5: Добавление серверов в группу DAG

    После нажатия кнопки Manage будет произведена настройка и конфигурирование выбранных серверов, в частности, на них будут установлены необходимые составляющие компонента Диспетчер отказоустойчивости кластеров и сконфигурирован сам кластер.

    Примечание: Если что-то пошло не так и кластер не собрался, то часто бывает трудно оценить проблему по тексту ошибки, выданному Exchange`м, в такой ситуации может помочь функция проверки узлов кластера в Диспетчере отказоустойчивости кластеров, которая дает гораздо больше информации по присутствующим проблемам:

    Рис.6: Проверка кластера.

    Если у вас в сети нет DHCP сервера, то DAG соберется, но будет в неактивном состоянии, т.к. группе не будет назначен IP адрес (состояние кластера можно также посмотреть в Диспетчер отказоустойчивости), чтобы исправить эту неприятность, необходимо воспользоваться командлетом New-DatabaseAvailabilityGroup с параметром DatabaseAvailabilityGroupIPAddresses, вот как-то так:

    New-DatabaseAvailabilityGroup -Name DAG1 -DatabaseAvailabilityGroupIPAddresses 192.168.0.5

    Когда группа DAG у вас будет собрана и активна, необходимо сделать копии баз данных на «соседних» серверах (не забывайте, что каждый сервер может хранить только одну копию базы). Чтобы создать копию базы данных, нажмите правой кнопкой мыши на исходной базе и выберите пункт меню Add Mailbox Database Copy…, далее откроется мастер, в котором нужно указать на каком сервере будет размещена копия и приоритет её активации:

    Рис.7: Создание копии базы данных.

    Если вам не нравится GUI, то можно это сделать с помощью командлета:

    Add-MailboxDatabaseCopy -Identity MDB2 -MailboxServer Server3 -ActivationPreference 2

    Создать копию базы данных с временем задержки воспроизведения и временем задержки усечения можно только из командной консоли Exchange (здесь 10 и 15 минут соответственно):

    Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX3 -ReplayLagTime 00:10:00 -TruncationLagTime 00:15:00 -ActivationPreference 2

    Таким образом, мы получаем несколько копий исходной базы данных, расположенные на разных серверах и в разных хранилищах. Чтобы активировать одну из копий, нужно нажать на ней правой кнопкой мыши и из выпадающего меню выбрать Activate Database Copy, после чего в открывшемся окне решить стоит ли перезаписывать параметры базы и нажать ОК, далее база данных будет автоматически смонтирована на другом сервере и её состояние измениться с Healthy на Mounted:

    Рис.8: Переключение баз почтовых ящиков.

    Примечание: Если вам необходимо сделать заполнение (обновление) одной из копий баз данных, то перед этим нужно приостановить её работу командой Suspend Database Copy, а затем выбрать пункт Update Database Copy…

    Рис.9: Обновление копии базы данных почтовых ящиков.

    Перейдем к настройке массива серверов CAS

     

    Принципиальная схема взаимодействия серверов в массиве будет выглядеть следующим образом:

    Рис.10: Принципиальная схема взаимодействия серверов в CAS массиве.

    Смысл в том, что клиенты, вместо подключения непосредственно к CAS серверу, будут подключаться к FQDN CAS-массива и при «падении» одного из серверов клиентские запросы возьмет на себя другой.

    Т.к. массив CAS используется только клиентами Outlook MAPI, то для обеспечения отказоустойчивости таких сервисов как Outlook Webb App, Exchange ActiveSync, Autodiscover и других, необходимо решить, что именно у вас будет выполнять роль балансировщика сетевой нагрузки (NLB). Microsoft рекомендует использовать для этих целей внешние аппаратные устройства, но если у вас таковых нет, то служба Windows Network Load Balancing вполне подойдет. Здесь нужно иметь в виду, что службы Windows NLB и Failover Cluster на одном сервере не живут!

    Для работы WNLB (как и других систем балансировки), необходимо иметь на DNS сервере запись, указывающую на виртуальный IP-адрес этой системы:

    Рис.11: Настройка DNS сервера.

    Далее давайте настроим Windows NLB кластер, для этого установим соответствующие компоненты в диспетчере сервера, затем откроем Диспетчер балансировки сетевой нагрузки в меню Администрирование и создадим новый кластер.

    Рис.12: Создание нового кластера NLB.

    В открывшемся мастере введем имя первого узла кластера и укажем локальный сетевой интерфейс. В следующем окне менять ни чего не нужно. Далее, добавим IP-адрес нашего кластера и укажем маску. Затем нужно настроить параметры кластера:

    Рис.12: Настройка параметров кластера.

    Снова введем IP-адрес и FQDN имя, указанное ранее в DNS сервере. Следующим шагом, нужно будет определить, какой режим работы выбрать, если кратко, то в одноадресном режиме, МАС адрес сетевого адаптера каждого сервера будет заменен виртуальным МАС адресом кластера и будет использоваться всеми серверами кластера. В многоадресном режиме МАС адрес добавляется в адаптер кластера на каждом сервере и каждый сервер сохраняет свой МАС адрес. Рекомендуется использовать Одноадресный режим!

    Подробнее про принцип работы NLB можно посмотреть здесь.
     Отдельное спасибо Александру Станкевичу за детальное описание данного механизма!

    Примечание: Если вы развертываете Exchange 2010 сервера в виртуальной среде, то при работе WNLB могут возникнуть проблемы, поэтому, если вы разворачиваете узлы кластера на платформе виртуализации VMware ESX Server, то вам придется использовать Многоадресный режим. Если же вы работаете с MicrosoftHyper-V, то лучше включить Одноадресный режим, но при этом внести некоторые изменения в настройки виртуального сетевого адаптера, а именно – настроить Статический МАС-адрес и включить функцию спуфинга МАС адресов.

    Рис.14: Настройка сетевых интерфейсов в Hyper-V

    В следующем окне мастера нужно определить какие порты будут использоваться в данном кластере. Вы можете по-умолчанию оставить открытыми все порты, а можете открыть следующие:

    • TCP/135 – для работы CAS-массива (убедитесь, что в Filtering Mode свойство Affinity включено в Single);
    • TCP/1024-65535 – диапазон RPC портов для MAPI-клиентов и CAS (если у вас не указаны статические порты);
    • TCP/443 — для Outlook Anywhere, Exchange ActiveSync и Outlook Web App;
    • TCP/993 – для Secure IMAP (Affinity включено в None);
    • TCP/995 – для Secure POP (Affinity включено в None);
    • TCP/80 – для внутреннего IIS перенаправления (HTTP > HTTPS).

    Далее нажимаем Готово и добавляем ещё один узел к кластеру, нажав на созданном кластере правой кнопкой мыши и выбрав пункт Добавить узел к кластеру. У нового узла значение приоритета выставляем в 2 и все остальные параметры оставляем по-умолчанию.

    Теперь осталось только собрать сам CAS массив.

    Для этой цели воспользуемся командлетом New-ClientAccessArray:

    New-ClientAccessArray -FQDN "mail.test-mail.local" -Site "Default-First-Site-Name"

    И подключить к массиву базы данных почтовых ящиков командлетом Set-MilboxDatabase:

    Set-MailboxDatabase -RpcClientAccessServer "mail.test-mail.local"

    Рис.15: Создание CAS массива.

    Проверить результат можно командлетом Get-MilboxDatabase.

    На этом настройка массива CAS серверов заканчивается, проверить работоспособность массива можно запустив MS Outlook, служба Autodiscover должна разрешить имя сервера как FQDN массива.

    Рис.16: Настройка MS Outlook.

    Статьи для подробного изучения:

     

    PS. Нужно иметь ввиду, что отказоустойчивые решения для систем виртуализации, в частности Failover Cluster для Hyper-V, использующие Live Migration, нельзя комбинировать с решениями репликации Exchange (ССR или DAG). Рекомендуется настраивать CCR или DAG на узлах Hyper-V не включенных в Failover Cluster и, соответственно, не использующих Cluster Shared Volumes.

    Запуск CCR или DAG на кластере с Live Migration не поддерживается!

    PPS. Если вам потребуется изменить URL`ы таких служб, как OWA (Outlook Web App), ECP (Exchange Control Panel), Exchange ActiveSync (EAS) и Outlook Anywhere (OA), то об этом вы сможете почитать тут.

    Алексей Богомолов (Alexx)

Комментарии

  1. под фразой «веб-узле Active Directory» видимо имелся в виду сайт «Active Directory»

  2. >веб-узле Active Directory

    Видимо промт подвел) По контексту пожоже на сайт AD. А он с веб-узлом ничего общего не имеет.

    >Также в Exchange 2010 предпринята попытка отказаться от публичных папок

    Песня такая была — «Моя попытка №5». А еще вспоминается «последнее китайское предупреждение»)

    >но теперь их нельзя включить в группу DAG и обеспечивать их доступность придется при помощи стандартных механизмов репликации баз данных публичных папок.

    А раньше было можно? ) Так было всегда, только репликация.

    >активную копию базы данных на одном SATA диске

    Уверены, что скорости диска хватит? Ну сервер с 5-ю ящиками я расчет не беру.

    Хорошая статья. Для тех кому нужно больше есть неплохой DeepDive: blogs.technet.com/ferris/...r-deep-dive.aspx

  3. Владимир, Илья, спасибо за комментарии.

    Насчет «опечатки» «веб-узле Active Directory» — нет, тут не Промт подвел, такая формулировка используется на официальном сайте MS — technet.microsoft.com/ru- ...exchangeqa.aspx. Согласен, надо было более детально обдумать фразу, прежде чем копировать, учту на будущее.

    Насчет скорости диска — конечно её не хватит, если баз не 5, а 50, но ведь и в ситуации когда их 50 врятли вы в ЦОДе найдете хоть одну СХД с такими дисками 🙂

  4. Ну значит течнетовским переводчикам Promt не чужд))))

  5. Блин...

    Как раз статью о таком внедрении на конкурс готовил :- (

  6. Хочу добавить несколько слов на счёт SATA-дисков.

    Есть слайд у Микрософта, на котором показано снижение нагрузки на жесткие диски.

    И я видел СХД с SATA дисками, хотя эти полки предназначались для тестовых целей, для «быстрых» резервных копий и для отказоустойчивых файловых серверов с небольшой нагрузкой. Но вполне реальный вариант.

    К тому же Микрософт обещала в SP1 сделать возможность хранения архивных папок в других базах данных.

  7. Евгений, в данном продукте столько тем, что у вас остался выбор еще из 99999...

    Для справки: Уже прислали статьи но еще не публиковали про архивный ящик и две про хранилища.

  8. > Как раз статью о таком внедрении на конкурс готовил :- (

    Евгений, у вас есть возможность сделать лучше, тем более, если вы уже внедрили подобную схему в реальную жизнь. Я же, пока все эксперименты делал только на тестовой инсталляции и возможно в продакшин-среде всплывут какие-то проблемы.

  9. Тоже вариант. Знаете есть хорошая фраза: «Выбирайте самый сложный путь и Вы не встретите на нем конкурентов»

  10. Кстати, очень печально, что Exchange не может быть установлен на Server Core, тем более при такой конфигурации, когда мы имеем много серверов и одновременно можем управлять им из одно консоли. Как-то не логично получается, в плане экономии ресурсов, держать 4 и более полноценных Windows Server 2008 R2 Enterprise, когда нам к ним даже и подключаться не нужно.

  11. Кто то кидал ссылку на шаманства по установке на Core и вроде даже все закончилось успешно, но это пока unsupported конфигурация.

  12. Вот тут — www.proexchange.be/blogs/...server-core.aspx, Johan Delimon пытался поставить Exchange 2010 на Windows Server 2008 R2 Core, но не удачно 🙁

    Наверно все потому, что «Server Core isn't really designed for application server–type roles.»...

  13. Коллеги, кто разбирается в лицензировании, подскажите, сколько мне лицензий на сервер Exchange 2010 надо? Если у меня 2 сервера Mailbox в DAG-группе, 2 CAS в CAS-array, один Edge Transport, таким образом, суммарно, 5 инсталляций.

  14. Смотря каких лицензий, серверных 5.

  15. Ух ты как... неожиданный ответ... я вообще думал 2 или 3 🙂

    А тут получается, что я могу купить одну лицензию и установить полноценный Exchange на один сервер, либо, если у меня нет достаточно мощного сервера, то купить 3 лицензии и разнести этот один Exchange ролями на разные физические сервера (Unified Messaging и Edge Transport не считаем)... не логично как-то... 🙁

  16. Я моу ошибаться. Но помойму Exchange лицензируется по схеме Сервер + Клиент. При этом если мы разносим роли, то покупаем лицензии на каждую роль.

  17. Я бы отметил, что NLB в такой конфигурации необходим при большом числе пользователей. И жесткого требования в наличии NLB для работы CAS Array нет.

  18. Дело в том, что массив CAS используется только клиентами Outlook MAPI, а вот для обеспечения отказоустойчивости таких сервисов как Outlook Webb App, Exchange ActiveSync, Autodiscover и других, кк раз и необходим NLB.

  19. >Уверены, что скорости диска хватит? Ну сервер с 5-ю ящиками я расчет не беру.

    в среднем нормальные SATA диски 7.2K выдают 60-70 IOPS. Этого достаточноч, чтобы в Exchange 2010 обеспечить комфортную работу примерно 200-300 пользователям со средними профилями... как-то так =)

    да — цыферки проверял. но, правда, в виртуалке. Jetstress'у оснований не доверять нет.

  20. >Дело в том, что массив CAS используется только клиентами Outlook MAPI, а вот для обеспечения отказоустойчивости таких сервисов как Outlook Webb App, Exchange ActiveSync, Autodiscover и других, кк раз и необходим NLB.

    Т.е. Вы хотите сказать, что OWA, EAS и Autodiscover используют не CAS для подключения? NLB нужен для балансировки траффика и не более. Которую он выполняет кстати достаточно примитивно и сильно проигрывает в этом HLB высокого уровня, всяким там Content Switсhing System.

    В данном сценарии NLB хорош для Hub Transport серверов при наличии в сети большого количества SMTP-клиентов, которые не умеют авторизоваться, должны отсылать почту наружу и в настройках не позволяют ввести FQDN или диапазон адресов. Это часто бывает при использовании сетевых сканеров с функцией отправки сканов на почту

    По поводу SATA-дисков. Да, их можно использовать. Они дешевле, больше и медленнее. Но это не значит -"Используйте SATA и все тут". С умом надо подходить к вопросу. Мне кажется, что с выходом SP1, который, кстати, уже анонсирован официально, и с разнесением основного и архивного ящика по разным базам можно SATA-диски использовать как раз для хранения архивов. Т.е. быстрый диск для основного ящика, с которым происходит постоянная работа, медленный для архива, к которому обращений будет знчительно меньше. Вот как-то так.

  21. > Т.е. Вы хотите сказать, что OWA, EAS и Autodiscover используют не CAS для подключения?

    Здесь имеется ввиду, что они используют для подключения FQDN массива CAS. Конечно можно просто в DNS прописать два IP адреса для одного FQDN и таким образом, вроде как, клиенты должны будут случайным образом попадать на тот или иной сервер CAS по их IP, но что если одни сервер упадет, вы даете гарантию, что тот-же OWA будет подключаться к другому, а не будет продолжать резолвить FQDN в «упавший» IP адрес?

    Насчет NLB — Microsoft сама говорит, что вместо Windows NLB лучше использовать аппаратные решения для балансировки (и об этом я писал в сатье), но что если таковых нет в наличии? ИМХО, в таком случае, WNLB — оптимальный вариант.

    PS Ждем SP1 с нетерпением, действительно, должно много измениться...

  22. >По поводу SATA-дисков. Да, их можно использовать. Они дешевле, больше и медленнее. Но это не значит -"Используйте SATA и все тут". С умом надо подходить к вопросу.

    Да! Да! Да! и ещё раз Да! Вооружившись Jetstress'ом и калькулятором расчёта роли почтовых ящиков. О своих результатах тестирования на десктопном железе я написал выше. С нетерпением жду сервера для экспериментов.

  23. Спасибо за статью.

    Неточность: на рисунке 2 ip для dag 192.168.0.10, а в соответствующем командлете

    используется 192.168.0.5 почему-то.

  24. 2chw: Спасибо за замечание. Неточность действительно имеет место быть. Просто дело в том, что статья писалась уже много позже того дня, когда проводилась настройка и тестирование, да и сама схема немного отличалась, собственно поэтому, встречаются даже места, где имена серверов на скриншотах и на соответствующих им схемах различаются. Прошу с пониманием отнестись к данным недочетам.

    PS. На самом деле, очень приятно, что вы так внимательно читаете. 🙂

  25. Не нужно опираться на предрассудки по поводу SATA дисков — они медленные поэтому существуют для бэкапов. Ничего подобного. В midrange СХД (EMC Clarrion CX4, NetApp FAS3xxx, FAS2xxx) они будут отлично работать и с прилично нагруженным файловым сервером (кстати, что скрывается под этим понятием?) и с Exchange 2010. Если кто-то со мной не согласен я могу ответить, что «вы просто не умеете их готовить». Я лично видел (и продолжаю наблюдать :)) на что способны midrange СХД c SATA дисками (количество пользователей 7000+).

  26. Полностью согласен с Александром!

    Многое зависит не только от SATA-дисков, но и еще от той железки, которая ими управляет.

    Нельзя сравнивать скорость SATA-дисков, например, массивов MSA 20 и EVA 4400, поскольку в последнем данные пишутся в кэш и затем на все диски, а не напрямую да и только на те диски, из которых построен RAID-том.

    Спасибо за отличную статью!

  27. Ну ничего, вот дождемся выхода SP1, разнесем архивы и почтовые ящики по разным базам и будет совсем хорошо 🙂

  28. Есть два удаленных офиса (и, соответственно, два сайта AD). Канал между ними отличный! Нужно обеспечить отказоустойчивость Exchange 2010 с МИНИМАЛЬНЫМ кол-вом серверов.

    Хочу сделать так:

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

    Куда ставить HubTransport? Можно ли на эти же сервера? Что произойдет, если упадет хаб в сайте?

    Хочется также по одному CAS'у поставить. И чтобы по умолчанию клиенты ходили на CAS в своем сайте, но если он отвалится, автоматически переключались на CAS в другом сайте. Это возможно?

    Прокомментируйте, пожалуйста.

  29. >Это возможно?

    Не получится так как вы хотите. Невозможно.

    Малой кровью отказоустойчивость не сделаете. Минимум 2 сервера Exch на сайт и то если аппаратный балансировщих есть. В противном случае 4 на сайт. Это не считая Edge.

  30. akamac, если у вас стоит задача использовать как можно меньше серверов, то возможно вам не стоит усложнять инфраструктуру с целью обеспечить немедленное восстановление после аварии, а посмотреть в сторону сценариев резервного копирования, которые бы позволили в течении минут 15 вернуть сервера в строй.

    Обратите внимание на Data Protection Manager 2010.

  31. >"Но не забывайте, что в случае установки роли транспортного сервера-концентратора на компьютере, где также установлена роль сервера почтовых ящиков, роль сервера почтовых ящиков всегда будет предпочитать локальный транспортный сервер-концентратор любым другим транспортным серверам-концентраторам в сайте Active Directory (даже если локально установленный транспортный сервер-концентратор недоступен), когда служба отправки почты Microsoft Exchange отправляет сообщения."

    First, let me assure you that the Exchange product group has considered this kind of scenario. Early on in Exchange 2010 development the team made a design change. If the Exchange Mail Submission service detects that it’s running on a mailbox server part of a DAG, it won’t prefer the local HT server. Instead, it will load balance across other HT servers in the same Active Directory site. If it doesn’t find any, it will fall back to the local HT server.

    technet.microsoft.com/ru- ...0%28en-us%29.asp

    что-то не могу понять кто прав ? =)

  32. Илья, спасибо замечание. Я уже исправил эту неточность в тексте статьи.

    Предыдущая фраза относилась к серверам, не входящим в DAG группу.

  33. >Малой кровью отказоустойчивость не сделаете. Минимум 2 сервера Exch на сайт и то если аппаратный балансировщих есть. В противном случае 4 на сайт. Это не считая Edge.

    тоже есть два офиса и потребность в отказоустойчивости. Аппаратного балансировщика нагрузки нет. Вопроса у меня два:

    1.учитывая, что минимальный комплект на один сайт (CAS + HUB) и MAILBOX

    можно ли объединить CAS в разных сайтах в массив с NLB?

    2. можно ли объединять CAS массив с NLB, если роли CAS совмещены с HUb?

    и если ответы отрицательные, то каков минимальный комплект серверов с отказоустойчивостью (по ролям)?

    заранее благодарен 🙂

  34. 1. Нельзя, т.к. при создании CAS массива вам нужно указать сайт, в котором он будет работать.

    2. Роль HUB можно совместить с любой другой ролью. Если в сайте будет больше одного HUB-а, то отказоустойчивость этой роли будет активарована автоматически.

    Минимально надо:

    — либо 2 сервера, на каждом по 3 роли + аппаратный NLB,

    — либо 4 сервера: 2 Mailbox в DAG`e + 2 CAS в массиве и 2-е роли HUB, установленные на любые из этих 4-х серверов.

  35. 1. Нельзя, т.к. при создании CAS массива вам нужно указать сайт, в котором он будет работать.

    2. Роль HUB можно совместить с любой другой ролью. Если в сайте будет больше одного HUB-а, то отказоустойчивость этой роли будет активарована автоматически.

    Минимально надо:

    — либо 2 сервера, на каждом по 3 роли + аппаратный NLB,

    — либо 4 сервера: 2 Mailbox в DAG`e + 2 CAS в массиве и 2-е роли HUB, установленные на любые из этих 4-х серверов.

  36. спасибо за ответ.

    ну и напоследок: между сайтами (два офиса) канал 100Mbit с близкой перспективой 1Gbit

    в этой ситуации есть ли смысл поднимать по два mailbox в пределах каждого сайта или достаточно 1-го MAILBOX на сайт и потом объединить их в DAG?

  37. А смысл делить на сайты офисы, если между ними канал 100 мегабит?

    Пользователей в офисах много? Профили какие у них?

  38. Подскажите пожалуйста, почему рекомендуется размещать базы данных Mailbox в Exchange 2010 в разных местах, на разных дисках? Чем обусловлено приемущество использования данной функции в Exchange 2010, это повышает производительность, хотелось бы услышать обоснованный ответ от специалистов.

  39. Не совсем так.

    Рекомендуется размещать базы данных и лог-файлы на разных физических дисках. Это повысит производительность, т.к. во время своей работы информация сначала обрабатывается в оперативной памяти и сохраняется в лог-файл, и только спустя время она из логов копируется в файл базы данных. Соответственно чтобы избежать лишних операций записи рекомендуется перенести сам файл базы данных на другой диск.

  40. > 4 сервера: 2 Mailbox в DAG`e + 2 CAS в массиве и 2-е роли HUB, установленные на любые из этих 4-х серверов

    Если капнуть глубже, то возможно еще варианты, например: 2 физических сервера с ролями Hyper-V (Mailbox в DAG`e, Unified Messaging и HUB) и предложим по 1 виртуальному (2 CAS в массиве) на каждом физическом.

    Вопросы:

    1. Будет ли работоспособна данная конфигурация?

    2. Если да, то, если я правильно понимаю, редакции Windows Server д.б. EE?

  41. Да, для DAG`a вам в любом случачае надо Win Ent. Работоспособна конфигурация будет, но лучше уж тогда все в виртуале делать. Не рекомендуется совмещать Hyper-V с другими ролями и службами.

  42. 1. Где бы почитать «что рекомендуется», а что нет?

    2. Mailbox виртуализировать целесообразно? Есть статистика и\или описание какой процент теряется при виртуализации роли Mailbox?

Опубликовать

Я не робот.