Почніть з того, що я погоджуюся з багатьма іншими - або переконую клієнта в іншому, або бігайте.
Однак, враховуючи перераховані вами вимоги (існує безліч незареєстрованих), я можу придумати (і частково перевірити) принаймні основи для здійснення цього.
Є кілька конкретних аспектів, які потрібно враховувати.
- Реплікація доменних служб Active Directory
- Процес пошуку локальних клієнтів / серверів-членів
- Дозвіл імен та трафік для послуг, що не належать до DS
Один і два мають багато спільного - загалом ми на цьому примха Microsoft, і нам доводиться працювати в межах процесів AD DS від Microsoft.
Номер три ми маємо трохи місця для роботи. Ми можемо вибрати мітки, які використовуються для доступу до служб (файли, екземпляри бази даних тощо).
Ось що я пропоную:
Створіть контролери домену (DC)
- Ймовірно, щонайменше два.
- Кожен DC матиме два NIC, по одному у кожній IP-мережі / AD-DS-сайті - називаючи їх на даний момент clt та srv.
- Налаштуйте лише один NIC у кожному постійному струмі зараз у srv-мережі.
Налаштуйте веб-сайти та служби AD належним чином
- сайт і підмережа srv
- clt-сайт та підмережа
- зніміть прапорець "Перемістити всі посилання на сайт" від Сайтів -> Міжміські перевезення -> Клацніть правою кнопкою миші "IP"
- видаліть DEFAULTIPSITELINK, якщо він існує (або якщо ви перейменували його), щоб не було налаштовано посилання на сайт. Зауважте, що для мене це невідоме - KCC, ймовірно, скидає помилки в журнал подій Служби каталогів, кажучи, що два сайти (srv і clt) не підключені через різні інтервали часу. Однак реплікація все ще триватиме між двома постійними користувачами, оскільки вони можуть контактувати один з одним за допомогою IP-адрес на одному і тому ж сайті.
Налаштування додаткової зони в AD DS Integrated DNS
- Якщо ваш домен AD DS є acme.local , створіть другу первинну інтегровану зону AD з увімкненими динамічними оновленнями під назвою clt.acme.local .
Налаштуйте другий NIC на своєму постійному тоці
- Ці NIC будуть NIC в мережі / сайті clt.
- Встановити свої IP-адреси
- Ось магічна частина - Властивості адаптера -> Властивості IPv4 -> Додатково -> Вкладка DNS -> Встановити суфікс DNS для цього з'єднання на clt.acme.local -> перевірити Зареєструвати це з'єднання ... -> Перевірити Використовувати це з'єднання Суфікс DNS ... -> ОК на всьому протязі.
- ipconfig / registerdns
- Це зареєструє IP-адресу NTC clt в зоні clt.acme.local - надавши нам спосіб контролювати, який IP / мережу буде використано пізніше.
Налаштування сервера-членів сервера-членів
- NIC-сервер учасника на сайті clt має встановити відповідний суфікс і прапорці DNS, як і вище.
- Ці параметри можна використовувати зі статичними та DHCP, не має значення.
Налаштуйте DNS [заглушку] поведінку роздільної здатності на сайтах
- DC -> Налаштування DC srv NIC для використання себе та інших DC srv NIC IP. Залиште DC clt NIC DNS порожнім (хоча статичний IP потрібен). (DC DNS-сервер все ще прослуховуватиме всі IP адреси за замовчуванням).
- Сервери-учасники -> Налаштувати сервер-учасник сервера NIC для використання IP-адрес веб-сайту DC srv. Залиште сервер-член clt NIC DNS порожнім (може використовуватися статичний IP).
- Клієнти / робочі станції -> Налаштувати DNS (або через DHCP, або статичну) для використання NIC IP-адреси Clt DC.
Налаштуйте відображення / ресурси відповідним чином
- Коли сервери спілкуються один з одним, обов'язково використовуйте .acme.local -> буде вирішувати IP-адресу мережі srv.
- Коли клієнти розмовляють із серверами, обов'язково використовуйте .clt.acme.local -> вирішить зупинити мережевий IP.
Про що я говорю?
- Реплікація AD DS все ще відбуватиметься, оскільки DC можуть вирішувати один одного та підключатися один до одного. Зона acme.local та _msdcs.acme.local буде містити лише DC srv NIC IP ND-реплікація AD DS відбуватиметься лише в srv-мережі.
- Процес локатора постійного струму для серверів-членів та робочих станцій буде функціонувати - хоча існує можливість затримок у різних частинах різних процесів AD DS, коли сайт невідомий, якщо повернуто кілька IP-адрес постійного струму - вони будуть намагатися, виходити з ладу та рухатись далі поки один не працює. Ефекти щодо DFS-N також не були повністю оцінені - але вони все ще будуть функціонувати.
- Послуги DS AD, які не належать до AD, будуть функціонувати чудово, якщо ви використовуєте вищезазначені мітки .acme.local та .clt.acme.local, як описано.
Я не до кінця перевірив це, оскільки це досить смішно. Однак суть цієї (вау, тривалої) відповіді полягає в тому, щоб почати оцінювати, чи це можливо чи ні - чи не слід це робити.
@Коменти
@ Массімо 1/2 Не плутайте кілька сайтів AD DS в зоні acme.local, і, таким чином, SRV-записи записуються DC в цих сайтах у зоні acme.local з необхідністю запису SRV в зоні clt.acme.local. Основний суфікс DNS клієнта (та домен Windows, до якого він приєднався) все ще буде acme.local. Клієнт / робочі станції мають лише один NIC з основним суфіксом DNS, ймовірно, похідним від DHCP, встановленим на acme.local.
Зоні clt.acme.local не потрібні записи SRV, оскільки вони не будуть використовуватися в процесі локатора постійного струму. Він використовується лише клієнтами / робочими станціями для підключення до сервісів-членів, що не належать до DS-сервісів, використовуючи IP-адреси сервера-члена в мережі clt. Процеси, пов'язані з AD DS (локатор постійного струму), будуть використовувати не clt.acme.local зону, а сайти AD DS (і підмережі) в зоні acme.local.
@Massimo 3
Існуватимуть записи SRV як для сайтів clt, так і для srv AD DS - тільки те, що вони будуть існувати в зоні acme.local - див. Примітку вище. Зоні clt.acme.local не потрібні записи SRV, пов'язані з постійним струмом.
Клієнти зможуть визначити штраф у розмірі постійного струму. Клієнтські DNS-сервери вказують на IP-адреси clt постійного струму.
Коли процес локатора постійного струму на клієнті починається
- Якщо клієнт знає свій сайт, запит DNS буде _ldap._tcp. [Site] ._ sites.dc._msdcs.acme.local SRV. Це поверне назад конкретні DC-адреси, у яких зареєстровані записи SRV.
- Якщо клієнт не знає свого сайту, питанням DNS буде _ldap._tcp.dc._msdcs.acme.local SRV. Це поверне всі DC постійного струму. Клієнт намагатиметься прив’язатись до LDAP DC, поки не знайде відповідний. Коли клієнт знайде його, він здійснює пошук сайту, щоб визначити сайт клієнта, і кешує сайт у реєстрі, щоб майбутні екземпляри DC-локатора відбувалися швидше.
@Massimo 4
Фу, приємний улов. Як я це бачу, існує два шляхи навколо цієї проблеми.
- Менший вплив (порівняно з 2 нижче) полягає у створенні запису у файлі хостів на клієнтах / робочих станціях для dc1.acme.local та dc2.acme.local, що вказують на NTC IP NTC DC.
або
- Створіть вручну необхідні записи SRV у файлі netlogon.dns на кожному з постійного струму. Це, ймовірно, матиме певні наслідки для серверної мережі. Сервери-учасники можуть часом спілкуватися з постійним струмом в мережі clt, якщо це налаштовано.
Загалом, нічого з цього не є гарним, але це не обов'язково є кінцевою метою. Можливо, клієнт просто тестує ваші технічні відбитки. Закладіть його на їхній конференц-стіл і скажіть їм "Ось, це спрацює, але я стягую з вас 4 рази мою нормальну швидкість, щоб налаштувати та підтримувати його. Ви можете зменшити його до 1,5x моєї нормальної ставки - .5x ПДФО, виконавши [правильне рішення]. "
Як зазначалося раніше, моя рекомендація - переконати в іншому чи бігти. Але це, звичайно, весела маленька вправа в смішному. :)