Active Directory и вопросы архитектуры Exchange и вопросы

Вот предыстория нашей ситуации ...

Прямо сейчас мы настроены как три отдельные компании с тремя полными системами Active Directory и Exchange. Три офиса (один в США, два в Европе) подключены через трехстороннюю настройку VPN (поэтому каждый офис имеет защищенную связь с двумя другими). В Active Directory существует двусторонняя настройка доверительных отношений для каждой настройки. Все системы работают под управлением Server 2003 и Exchange 2003.

Между компаниями и 80 пользователями существует около 160 почтовых ящиков (дополнительные почтовые ящики предназначены либо для ИТ-подсистем, для пересылки учетных записей или для других целей).

Компании официально объединяются (вместо того, чтобы просто иметь доверительные отношения). Поэтому мы ищем комбинированное решение (на основе нового имени), в котором каждый офис будет работать на одних и тех же системах (Exchange и Active Directory), а также консолидируем нашу ИТ-инфраструктуру (много дублирования).

Они наняли внешнюю компанию для проверки нашей ИТ-инфраструктуры. Они сделали официальную рекомендацию отдать на аутсорсинг ИТ-инфраструктуру (и угадайте, что они хотят предоставить услугу).

Мне было поручено выяснить, что делать. Я немного подумал об этом, и у меня есть два варианта. Основное различие заключается в том, где размещается Exchange (внутри нашего аутсорсинга). Поскольку аутсорсинг легко понять, я просто подробно опишу внутреннюю настройку.

Поскольку требуется высокая доступность, нам нужна встроенная географическая избыточность. Итак, я пришел к следующему (я назову офисы Site1, Site2 и Site3):

site1:

• FSMO Active Directory Роль
• Роль почтового ящика Exchange - первичная
• Клиентский доступ Exchange, роли транспортного сервера-концентратора
• Роль общего доступа к файлам DFS (для общих дисков)

site2:

• Роль Active Directory - реплицируется с сайта 1
• Роль почтового ящика Exchange - вторичная, реплицируется с использованием репликации CCR
• Клиентский доступ Exchange, роли транспортного сервера-концентратора
• Роль общего доступа к файлам DFS

site3:

• Роль Active Directory - реплицируется с сайта 1
• Клиентский доступ Exchange, роли транспортного сервера-концентратора
• Свидетель общего доступа к файлам (для аварийного переключения)
• Роль общего доступа к файлам DFS

Таким образом, в основном кластер должен быть в состоянии пережить один сбой сайта, не останавливая ни один из других сайтов (или любой из систем). В случае двойного сбоя сайта Exchange полностью остановится.

Итак, мои опасения заключаются в следующем:

1. Это разумная установка? Или я слишком усложняю вещи?
2. Требуемое количество серверов (по 3 на каждом сайте, так как роли почтовых ящиков CCR должны быть единственной установленной ролью).
3. Будет ли он работать даже как суммированный (где он автоматически переключится на доступный узел, если сайт или сервер выйдет из строя)?
4. Поскольку каждый офис будет указывать локальный сервер клиентского доступа для своих пользователей, этот сервер становится единой точкой отказа для всех локальных запросов (но это можно решить путем изменения DNS вручную)
5. Все ли эти серверы должны быть в одной IP-подсети, чтобы это работало? Или я могу использовать для этого высокотехнологичный DNS (clientaccess.site1.foo.com и т. Д.)?
6. Это позволит мне установить каждый офис в качестве записи MX (поскольку в каждом офисе есть транспортный сервер-концентратор для подключения к Интернету), поэтому, если один офис выйдет из строя, мы все равно сможем получать электронную почту в других, правильно?
7. Ремонтопригодность. У меня есть страх, что эта настройка будет слишком сложной для поддержки в долгосрочной перспективе (добавление офисов, удаление офисов, обновление серверов (как ОС, так и оборудования) и т. Д.). Это оправданный страх?

Теперь также возникает вопрос о том, стоит ли использовать сервер 2003 или 2008 ... Если мы пойдем по внутреннему маршруту Exchange, я думаю, что смогу убедить его в возможности перейти на 2008 год (на самом деле нам нужно будет обновить его, чтобы использовать Exchange 2010) ... Но действительно ли это необходимо или это просто одно из моих "желаний", подкрадывающихся к планам (а не оправданное обновление) ...

Теперь, часть меня просто хочет пойти на внешний Exchange, поскольку это облегчит некоторые из этих проблем (или большинство из них). Однако после оценки затрат точка безубыточности составляет около 1 года, поэтому после этого аутсорсинг будет значительно дороже. Соедините это с тем фактом, что некоторые функции, от которых мы зависим, не могут быть переданы на аутсорсинг - по крайней мере, с компаниями, на которые мы смотрели (например, общие почтовые ящики, соединение Active Directory, включая SSO, централизованное управление, безопасность данных и т. Д.). Так что я очень расстроен тем, куда идти с этим ...

Это первый проект такого масштаба, который я пробую, поэтому любая помощь будет принята с благодарностью ...

Заранее спасибо (и извините за книгу) ...

Мы находимся в аналогичной ситуации, за исключением того, что в нашем случае мы уже одна компания. Но у нас есть офисы в Кембридже, Лондоне, Стокгольме, Шанхае и Атланте. Все подключено через VPN. Три из них имеют серверы Exchange (2 на Exchange 2010, третий будет обновлен в ближайшее время). Большинство наших контроллеров домена работают под управлением Windows 2003, но мы находимся на пути их обновления до Windows 2008. У нас около 150 сотрудников, разбросанных по всему миру. Так что очень похоже на вашу ситуацию.

Итак, вот несколько ответов с моей точки зрения:

1. Если у вас есть достойная команда ИТ, то я бы никогда не подумал об аутсорсинге. На самом деле, даже если ваша команда не приличная, я бы потратил немного усилий, чтобы сделать ее приличной. Время отклика будет намного лучше, настройки безопасности проще, но самое главное: ваша ИТ-команда будет сосредоточена на том, чтобы поддерживать ИТ-инфраструктуру в наилучшем рабочем состоянии. Основное внимание аутсорсинг-провайдера заключается в том, чтобы максимально использовать ваши деньги, а не предоставлять лучший сервис.
2. Ваша запланированная установка очень выполнима. Ваша главная задача - перенести все в общий домен, но это можно сделать шаг за шагом.
3. Серверы для большинства того, что вам нужно, не будут стоить руки и ноги. Если вам нужно купить дополнительные серверы, капитальные затраты на это будут небольшими.
4. Работает ли он или нет, в общем, зависит от того, насколько хорошо вы настроили публичный DNS и настроили внутреннюю маршрутизацию. Это определенно можно заставить работать.
5. Я очень рекомендую иметь отдельные подсети для каждого офиса. Делает жизнь как сисадмин ЛОТ проще. Используйте одну подсеть приличного размера для каждого офиса, а затем либо используйте статическую маршрутизацию для трафика между сайтами, либо OSPF (большинство приличных VPN-маршрутизаторов предлагают OSPF с полки). На самом деле у нас есть две отдельные подсети в большинстве офисов, в которых обычный корпоративный трафик отделен от инженерного трафика (поскольку наши инженеры, как правило, делают много интересных вещей с DNS, DHCP, потоковым видео и чем-то еще). И это прекрасно работает. На самом деле, мы даже дошли до того, что инженеры в любом офисе могут использовать видеопоток со стримера где угодно, не зная, откуда он.
6. НЕ пытайтесь разместить все компьютеры в одной большой подсети. Вы вырвете свои волосы. Promise.
7. У нас есть три общедоступных почтовых шлюза (расположенных в офисах с самой высокой пропускной способностью интернет-соединения), которые настроены одинаково и все перенаправляются на ближайший сервер Exchange, откуда почта распределяется в конечные почтовые ящики. Совершенно никаких проблем.
8. Как только вы овладеете основными навыками маршрутизации и тому подобного, вы обнаружите, что это не сложно поддерживать. У меня есть около 150 серверов, распределенных по всем этим сайтам, около полудюжины VPN-маршрутизаторов, несколько десятков управляемых коммутаторов. У нас смешанная установка (30% Windows, 70% Linux, на серверах и рабочих станциях), и мне подчиняются 4 человека. Без проблем.

Доверьтесь своей способности учиться, и у вас все получится. План хороший. Я хотел бы перейти с Windows Server 2008 и перенести серверы Exchange по одному на Exchange 2010. Для миграции Exchange вам может потребоваться некоторая внешняя помощь (она нам нужна, и мои ребята в целом неплохо справляются с Exchange), но если вы боясь начального расположения капитала, вы также можете перенести все по одному. Нет необходимости делать все это одним большим взмахом.