Лучшие практики для топологии Exchange 2010 HA с учетом 6 x лицензий Exchange и TMG 2010

Какова была бы лучшая топология, учитывая, что:

6 стандартных лицензий Exchange 2010
2 x Отдельные места, которые должны поддерживать избыточность в случае проблем со связью
4 x Forefront TMG 2010 с Forefront Security и Forefront Protection / Безопасность

Несколько мест по всему миру, используя эти биржи. Большинство местоположений будет связано с VPN-туннелем (те, где размещен Exchange, наверняка).

Я думал что-то вроде этого:

Расположение ГЛАВНАЯ (около 70-100 человек):

2x TMG 2010 в НЛБ
1x Exchange 2010 CAS / HUB Роль
2x Роль почтового ящика Exchange 2010 (активная + пассивная)

Расположение SUPPORT (около 20 человек):

2x TMG 2010 в НЛБ
1x Exchange 2010 CAS / HUB Роль
2x Роль почтового ящика Exchange 2010 (активная + пассивная)

Руководство хочет убедиться, что в случае проблем в основном местоположении (сбой питания, потеря связи и т. Д.) Второе местоположение может поддерживать весь трафик со всего мира и наоборот. У нас есть 6-7 локаций и больше (не больших, но более 10 человек на каждую локацию).

Я знаю, что CAS / HUB - это единая точка отказа (и нет NLB), но мне просто не хватает лицензий для некоторой избыточности.

Что вы думаете об этом подходе? Что было бы лучше подойти по вашему мнению?

exchange-2010 best-practices topology

— Сумасшедший мальчик
источник

Это не звучит слишком смешно для меня, и я бы не сильно изменился. Я предполагаю, что вся подготовительная работа была проделана (например, несколько сайтов Active Directory, контроллеры домена на каждом сайте и т. Д.), Поэтому я не буду вдаваться в подробности этого. Если вы можете немного увеличить свой бюджет, я бы немного подправил вашу топологию CAS, чтобы устранить SPOF.

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

Если ваш бюджет может вместить 2 аппаратных балансировщика нагрузки, вы также можете установить роль CAS на серверах почтовых ящиков. Затем вы создадите записи A в DNS для своих балансировщиков нагрузки и сконфигурируете соответствующие базы данных почтовых ящиков на каждом сайте для использования массива CAS для сайта.
Для этого New-ClientAccessArray -Fqdn "ex-sitename-casarray.acme-widgets.com" -Site "AD-Site-MAIN"введите команду для каждого сайта (при необходимости заменив свои записи A и реальные имена сайтов AD).
Затем Set-MailboxDatabase "<<Appropriate Database>>" -RpcClientAccessServer <<site-casarray-name.acme-widgets.com>>выполните команду, чтобы убедиться, что базы данных почтовых ящиков используют массив CAS.

Лучше иметь локальную копию почтового ящика пользователя на том же сайте, что и пользователь, поэтому я бы создал 2 базы данных почтовых ящиков, каждая из которых реплицируется на сервер почтовых ящиков на том же сайте, а также на другом сайте (я сделал диаграмма, чтобы визуализировать это для вас). Для пользователей на ГЛАВНОМ сайте разместите свой почтовый ящик на главной базе данных почтовых ящиков, а для пользователей на сайте ПОДДЕРЖКИ разместите свои почтовые ящики на базе поддержки почтовых ящиков. альтернативный текст

— Бен Пилброу
источник

Я не совсем уверен, что согласен с вашим утверждением, что сервер почтовых ящиков пользователя должен находиться на том же сайте. Это могло быть правдой 10 лет назад, но все версии Exchange, начиная с 2003 года, поддерживают режим кэширования. Объедините это с небольшим количеством пользователей на сайте поддержки, и я сомневаюсь, что кто-нибудь заметит разницу. Лучше всего создавать базы данных, основанные на других факторах, помимо физического местоположения. Пределы хранения, уровень классификации, потребность в архивировании или цели времени восстановления лучше использовать для разделения почтовых ящиков в базы данных.

— Джейсон Берг

Спасибо за комментарий @ Джейсон Берг, я ценю ваш вклад. Если сайт SUPPORT готов обрабатывать трафик с сайта MAIN, я предполагаю, что канал WAN будет довольно хорошим, так что да, пользователи, вероятно, не заметят разницы. Причина, по которой я это назвал, проста, и это потому, что инструктор на моем учебном курсе сказал, что должен это сделать. Честно говоря, это было скорее мимолетным «когда вы создаете базу данных почтовых ящиков, размещаете ее на том же сайте, что и пользователи», а затем она перешла к чему-то другому. Это не звучало как глупое предположение, поэтому я не думал больше об этом.

— Бен Пилброу

TMG 2010 (новый ISA) имеет балансировку нагрузки, так что это не будет большой проблемой, но размещение каждой роли на каждом блоке кажется немного излишним. Я знаю, что роль CAS - это SPOF, и я не совсем уверен, что с этим делать, не складывая все в одну корзину. Мы получаем 6 лицензий от партнерства бесплатно, и нам придется купить некоторое оборудование, а также некоторые клиентские лицензии, поэтому я не думаю, что мой клиент хотел бы заплатить за это дополнительную цену. Но я обязательно внесу это в документ, чтобы убедиться, что они понимают риски (то есть время простоя).

— MadBoy

Если TMG может балансировать нагрузку на серверы CAS, это здорово (я не буду притворяться, что узнаю что-нибудь о TMG). Могу ли я спросить, почему вы не хотите распределить все роли по всем коробкам? Как вы думаете, будет ли это большой успех? Не пытаясь казаться придурком (я действительно не хочу с этим сталкиваться), на мой взгляд, нет такой вещи, как избыточное убийство - вы создаете более избыточное решение, которое в конце концов является тем, что вам нужно. Не могли бы вы предложить разместить дополнительный Hub Transport на 1 сервере почтовых ящиков, а CAS - на другом, чтобы немного его осветить? (Учитывая, что CAS все еще нуждается в балансировке нагрузки).

— Бен Пилброу

Я мог бы сделать это также 4 сервера в основном месте, и 2 со всеми ролями в другом с балансировщиком нагрузки. Это может обеспечить основное местоположение с лучшими практическими книгами и поддержку местоположения с универсальным решением.

— MadBoy