Питання та проблеми з архітектурою Active Directory та Exchange

Ось історія нашої ситуації ...

Наразі ми створюємо як три різних компанії з трьома повноцінними системами Active Directory та Exchange. Три офіси (Один у США, два в Європі) з'єднані за допомогою третьої установки VPN (тому кожен офіс має безпечне спілкування з іншими двома). Існує двостороння настройка відносин довіри в Active Directory для кожної установки. Всі системи працюють під управлінням Server 2003 та Exchange 2003.

Між компаніями та 80 користувачами існує близько 160 поштових скриньок (додаткові поштові скриньки призначені або для ІТ-підсистем, облікових записів для переадресації чи іншого використання).

Компанії офіційно зливаються разом (замість того, щоб просто мати довірчі відносини). Тож ми розглядаємо комбіноване рішення (засноване на новій назві), де кожен офіс буде знаходитись в одних і тих же системах (Exchange і Active Directory), а також консолідуємо нашу ІТ-інфраструктуру (є багато дублювання).

Вони найняли зовнішню компанію, щоб зайти і перевірити нашу ІТ-інфраструктуру. Вони зробили офіційну рекомендацію щодо передачі в експлуатацію ІТ-інфраструктури (і здогадайтесь, що вони хочуть надати послугу).

Мені доручено розібратися, що робити. Я досить подумав про це, і придумав два варіанти. Основна відмінність полягає в тому, де розміщується біржа (внутрішньо наші аутсорсинги). Оскільки аутсорсинг легко зрозуміти, я детально деталізую внутрішні налаштування.

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

Site1:

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

Site2:

• Роль Active Directory - реплікується з Site1
• Роль обмінної скриньки - вторинна, реплікується за допомогою реплікації CCR
• Доступ до клієнтського обміну, ролі транспортного сервера-концентратора
• Роль файлу DFS

Site3:

• Роль Active Directory - реплікується з Site1
• Доступ до клієнтського обміну, ролі транспортного сервера-концентратора
• Файл Спілкування (для відмови)
• Роль файлу DFS

Таким чином, кластер повинен мати можливість пережити один зрив одного сайту, не знищуючи жодного з інших сайтів (або будь-якої із систем). У випадку подвійного збою сайту, Exchange повністю припиниться.

Отже, мої занепокоєння такі:

1. Це розумна установка? Або я над ускладненням речей?
2. Кількість необхідних серверів (3 на кожному сайті, оскільки ролі CCR Mailbox повинні бути встановлені єдиною).
3. Чи буде він навіть працювати як підсумований (де він автоматично перейде на доступний вузол, якщо сайт або сервер зійде)?
4. Оскільки кожен офіс визначає локальний сервер клієнтського доступу для своїх користувачів, цей сервер стає єдиною точкою відмови для всіх локальних запитів (Але це вирішується вручну в зміні DNS)
5. Чи всі ці сервери повинні бути в одній IP-підмережі, щоб це працювало? Або я можу піти від використання DNS-адреси для пошуку (clientaccess.site1.foo.com тощо)?
6. Це дозволить мені встановити кожен офіс як запис MX (оскільки в кожному офісі є сервер транспорту концентратора для підключення до Інтернету), тож якщо один офіс знизиться, ми все одно повинні мати можливість отримувати електронну пошту в інші, правильно?
7. Технічне обслуговування. У мене є побоювання, що ця налаштування буде занадто складною для підтримки в довгостроковій перспективі (додавання офісів, видалення офісів, оновлення серверів (як ОС, так і апаратних засобів) тощо). Це виправданий страх?

Тепер також виникає питання про те, чи варто їхати з сервером 2003 або 2008 ... Якщо ми підемо внутрішнім маршрутом Exchange, я думаю, що я можу переконати повноваження до оновлення до 2008 року (адже нам потрібно було б оновити, щоб використовувати Exchange 2010) ... Але чи справді це потрібно, чи просто один із моїх "бажань" прокрадається до планів (а не виправданого оновлення) ...

Тепер частина мене просто хоче піти з аутсорсингової біржі, оскільки це полегшить деякі з цих питань (або більшість з них). Однак, подивившись на витрати, точка беззбитковості становить близько 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. НЕ намагайтеся мати усі комп'ютери в одній великій підмережі. Ви зірвете волосся. Обіцяють.
7. У нас є три загальнодоступні поштові шлюзи (розташовані в офісах з найвищою пропускною здатністю підключення до Інтернету), які налаштовані абсолютно однаково і передаються на найближчий сервер Exchange, звідки пошта поширюється на кінцеві поштові скриньки. Не проблема взагалі.
8. Після того, як ви матимете основне захоплення щодо маршрутизації тощо, ви побачите, що це не важко зберегти. У мене загалом близько 150 серверів, розповсюджених на всіх цих сайтах, близько півдесяти VPN маршрутизаторів, кілька десятків керованих комутаторів. Ми - змішана установка (30% Windows, 70% Linux, на серверах і робочих станціях), і мені доводиться звітувати 4 людей. Зовсім не проблема.

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