Контроллер домена на VPS как резервный узел для небольшого офиса

Представьте офис, из которого пропал интернет, или хуже: пропало электричество, и серверная в шкафу молча остывает. Люди разошлись по домам с ноутбуками. Вопрос, который здесь важен, звучит не как «работает ли у нас сервер», а точнее: какие доменные операции должны продолжиться вне офиса? Войти под своей учётной записью? Сменить забытый пароль? Получить доступ к общей папке? Открыть бухгалтерскую базу? Это разные задачи, и второй контроллер домена на VPS решает только часть из них.

Эта статья про трезвые ожидания. Мы разберём, что даёт дополнительный контроллер в облаке, от каких соседей он зависит, почему репликация не равна резервной копии и в каких сценариях отказа он действительно спасает, а в каких стоит рядом с сервером без дела.

Аутентификация отдельно, офис отдельно

Контроллер домена отвечает за конкретный набор вещей: хранит каталог учётных записей и компьютеров, проверяет пароли и выдаёт билеты для доступа к службам, а также обычно держит DNS-зону домена. Всё остальное в офисе — файловый сервер, терминальный сервер, принтеры, 1С, почта — живёт на других машинах и к контроллеру лишь обращается за ответом на вопрос «кто это и можно ли ему сюда».

Отсюда главное разграничение. Резервирование аутентификации означает, что у вас появляется второе место, где можно спросить «кто это». Копирование всей офисной инфраструктуры означает, что где-то лежат и могут быть подняты сами файлы, базы и серверы приложений. Первое — это один небольшой сервис, второе — совсем другой объём работы, дисков и денег. Дополнительный контроллер на VPS относится к первому. Он не унесёт с собой ни общую папку, ни базу, ни принтер.

Если такая граница кажется очевидной, учтите: именно на ней чаще всего строятся неверные ожидания. «У нас же есть второй сервер в облаке» легко превращается в «значит, если офис отключится, всё продолжит работать». Не продолжит. Продолжится то, что умеет работать без офиса само по себе.

Сцена: Анна входит в систему и открывает внутреннее имя

Возьмём условный пример. Анна, бухгалтер, работает дома на ноутбуке, присоединённом к домену. Офисный канал недоступен, но у неё поднят VPN до VPS, где стоит второй контроллер. Проследим, что происходит, когда она делает два действия.

Вход в Windows. Если Анна уже входила на этом ноутбуке, Windows может пустить её по кэшированным учётным данным даже вообще без связи с контроллером. Это удобно, но это не проверка пароля сервером: смену пароля, блокировку учётной записи или отключение сотрудника ноутбук в таком режиме не увидит. Если же VPN поднят до входа и ноутбук видит второй контроллер, вход проходит по-настоящему: клиент находит контроллер через DNS, получает билет, и актуальное состояние учётной записи учитывается. Чтобы это сработало, VPN должен подниматься на этапе входа, а не после него, иначе до экрана рабочего стола клиент контроллера не увидит.

Обращение к внутреннему имени. Допустим, Анне нужна общая папка по адресу вида \\files\docs. Чтобы её открыть, происходит цепочка: клиент спрашивает DNS, где находится files; получает адрес; идёт по этому адресу; предъявляет билет, полученный от контроллера. Второй контроллер на VPS разрешит первое и третье звено, если он же держит копию DNS-зоны. Но четвёртое звено — сам файловый сервер — остался в офисе. Имя разрешится, билет выдастся, а соединение упрётся в то, что сервер недоступен. Пользователь увидит ошибку, но другую: не «домен недоступен», а «сетевой путь не найден» или таймаут.

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

Три нити: DNS, время и защищённый канал

Второй контроллер почти никогда не отказывает сам по себе красиво. Чаще ломается то, на чём он держится. Таких опор три.

DNS: адресная книга домена

Клиенты находят контроллеры не по магии, а по записям в DNS. Если второй контроллер не является DNS-сервером для зоны домена или клиенты о нём ничего не знают, то при недоступности офиса они спросят старый DNS, не получат ответа и сообщат, что домен не найден — хотя живой контроллер стоит в соседнем дата-центре. Поэтому для полезного резервного узла нужны два условия: на нём размещена копия зоны, и клиенты получают его адрес среди DNS-серверов.

Второе условие тоньше. Ноутбуки, которые работают из дома, получают настройки сети от домашнего роутера, а не от офисного DHCP. Значит, поверх VPN-подключения нужно, чтобы клиент использовал DNS-серверы домена, включая тот, что на VPS. Как именно это настраивается, зависит от выбранного VPN-клиента и его возможностей, поэтому проверять придётся на конкретных устройствах, а не полагаться на общее правило. Полезно также помнить про порядок: клиент обычно предпочитает первый указанный DNS-сервер и переходит ко второму после тайм-аута, так что пока офис жив, резервный узел будет отвечать редко.

Время: тихий источник отказов

Проверка подлинности в доменной среде чувствительна к расхождению часов: если часы клиента и контроллера сильно расходятся, билеты перестают приниматься. С виртуальными машинами это не теоретическая проблема. Microsoft в разборе размещения контроллеров в виртуальной среде отдельно называет время среди тем, которые нужно продумать при виртуализации (контроллеры домена в виртуальной среде). Тот же документ ставит рядом диски, выделение ресурсов, резервирование и вопрос запуска инфраструктуры при недоступном контроллере.

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

Защищённая связь: VPN как обязательное условие

Контроллер домена не должен выставляться в интернет напрямую. Службам каталога нужен целый набор портов, и открывать их всему миру — плохая идея независимо от того, насколько хорош пароль администратора. Поэтому канал между офисом и VPS строится как защищённый туннель, и по нему идёт и репликация, и клиентские обращения удалённых пользователей. Конкретный тип туннеля — выбор администратора: подойдёт то, что поддерживается вашим офисным шлюзом и самим VPS с root-доступом, а в VPS MAATRIX он доступен.

Важно, что VPN в этой схеме — единая точка зависимости. Если туннель лёг, второй контроллер перестаёт получать изменения и перестаёт быть досягаемым для тех, кто идёт к нему через этот туннель. Дальше мы вернёмся к этому, когда разделим отказ канала и отказ самого контроллера.

Репликация: передача изменений, в том числе ненужных

Теперь о главном слове в теме. Второй контроллер получает данные не копированием диска, а репликацией: каждое изменение в каталоге — новая учётная запись, смена пароля, перемещение объекта в другое подразделение, удаление группы — записывается на одном контроллере и пересылается на другие. Если у вас два контроллера, они постоянно обмениваются описанием того, что поменялось.

Это отличное свойство, пока меняется то, что должно меняться. Но у репликации нет понятия «хорошо» и «плохо». Она передаёт любое изменение. Случайно удалили организационное подразделение с сорока пользователями? Удаление честно доедет до второго контроллера. Сотрудник с лишними правами добавил в группу не того человека? Это тоже будет реплицировано. Сбой приложения, которое массово переписывает атрибуты, продублируется на обоих узлах за считанные минуты.

Из этого следует простая и неприятная мысль: второй контроллер защищает от потери узла, но не от потери данных каталога. Если сломалось железо, в офисе второй контроллер выручит. Если сломали сам каталог — нет, потому что ломать будут обе копии одновременно.

Откат виртуальной машины как отдельный риск

У виртуализации есть особая ловушка. Контроллер хранит внутренние счётчики порядковых номеров изменений (USN), и репликация опирается на то, что они только растут. Если виртуальную машину откатить на старое состояние, счётчик «вернётся назад», и контроллер может начать выдавать номера, которые уже использовались. По документации Microsoft, механизм VM-GenerationID на совместимом гипервизоре позволяет AD DS обнаружить откат виртуальной машины и принять меры, чтобы не допустить повторного использования USN (виртуализация AD DS). Из этого вытекают два практических вопроса к VPS: поддерживает ли гипервизор этот механизм и что делает панель управления при восстановлении состояния машины. Ответ нужно получить до того, как кто-нибудь нажмёт кнопку «вернуть снимок» на рабочем контроллере.

Тот же документ отдельно оговаривает, что снимок виртуальной машины не рекомендуется как замена поддерживаемому резервному копированию контроллера домена. Это стоит запомнить, потому что в панелях управления VPS снимок — самая заметная и самая простая кнопка. Удобство не делает её правильным инструментом именно для этой роли.

Отказ канала и отказ контроллера — разные беды

Слово «отказ» в разговоре про резервный контроллер обычно собирает в одну кучу минимум три разных события. Их полезно развести, потому что реакция на каждое своя.

Обратите внимание на вторую строку. Когда рвётся канал, но оба контроллера целы, возникает «разделённый мозг» в мягкой форме: пока связи нет, администратор может изменить пароль на одном контроллере, а пользователь тем временем попробует войти через другой. Репликация сойдётся, когда связь вернётся, но на время обрыва картина разная. Для маленького офиса это обычно терпимо, но знать об этом нужно, чтобы не удивляться жалобе «я сменил пароль, а он ещё старый».

В третьей строке схема раскрывается лучше всего, и вместе с тем становится очевидной её граница. Если офис полностью выпал, а сотрудники работают удалённо, VPS-контроллер действительно нужен: без него клиенты, которым нужна проверка у сервера, остаются без неё. Но «работать дальше» им предстоит с теми ресурсами, которые не лежат в офисе. Это повод честно перечислить, что именно у вас уже живёт вне офиса, и отнести к этому списку лишь реально вынесенные службы. Если вы рассматриваете перенос рабочих мест на сервер, о схеме удалённых рабочих столов рассказывает материал про терминальный сервер на своём гипервизоре: там обратная ситуация, где всё центральное находится в одном месте, и контроллеру домена тоже нужно решить, где ему жить.

Сколько нужно VPS и где его размещать

Для небольшого домена контроллер — служба нетребовательная по сравнению с файловыми и прикладными серверами, но «нетребовательная» не значит «нулевая». Из тарифов MAATRIX отправной точкой для эксперимента можно взять план Uab: 2 vCPU, 4 ГБ RAM и 80 ГБ NVMe, или более скромный Ba с 1 vCPU, 2 ГБ и 40 ГБ. Это стартовая точка для проверки, а не обещание ёмкости: реальные потребности зависят от размера каталога, числа клиентов и того, какие ещё роли вы повесите на машину. Мерьте на своём домене: смотрите память, дисковые задержки и загрузку процессора при типичной нагрузке и при массовом входе в начале рабочего дня.

Диск стоит обсудить отдельно. Исходя из того, что Microsoft выделяет диски как отдельную тему для виртуальных контроллеров, базу каталога и журналы стоит разместить с оглядкой на то, как гипервизор и хранилище обрабатывают запись; конкретные рекомендации по размещению файлов вы найдёте в документации по эксплуатации AD DS. NVMe, который указан в предложении MAATRIX, обычно хорошо подходит для таких операций, но выбор конфигурации диска и поведение при сбое питания — вопросы, которые лучше проверить на тестовой машине.

Локация — отдельное решение. В публичном предложении перечислены UK, US, RU и FR. Для связи с офисом важна не география сама по себе, а задержка и стабильность туннеля: репликация и вход терпят умеренную задержку, но не любят потерь пакетов. Если сотрудников и офис вы обслуживаете в России, логично сначала проверить именно ближайшую к ним локацию, а требования к размещению персональных данных и учётных сведений нужно сверять с вашими юридическими обязательствами отдельно — выбор страны сервера сам по себе их не закрывает.

Как ввести узел в работу и не навредить

Порядок действий проще удержать в голове, чем кажется. Он не требует знания всего устройства каталога, но требует дисциплины.

1. Сначала связь, потом роль. Поднимите туннель между офисом и VPS и убедитесь, что имена офисных серверов разрешаются с VPS, а адрес VPS достижим из офиса. Только после этого добавляйте на машину роль контроллера домена.
2. Проверьте время до повышения роли. Часы на VPS должны согласовываться с источником времени домена. Выясните, откуда виртуальная машина берёт время, пока она ещё обычный сервер.
3. Добавьте узел в существующий домен как дополнительный контроллер и дайте первой репликации завершиться полностью, прежде чем что-либо менять.
4. Назначьте DNS. Убедитесь, что на новом узле есть копия зоны, затем добавьте его адрес в DNS-настройки клиентов, включая те, что подключаются по VPN.
5. Проверьте репликацию в обе стороны. Создайте тестового пользователя на одном узле и найдите его на другом; смените пароль и убедитесь, что вход работает через оба контроллера.
6. Отрепетируйте отказ. В согласованное окно отключите офисный контроллер или туннель и пройдите путь Анны: вход, разрешение имени, открытие ресурса. Запишите, что действительно сработало.

Последний пункт отличает рабочую схему от схемы «на бумаге». Пока вы не отключили офисный узел и не проверили поведение реальных ноутбуков, у вас есть гипотеза, а не отказоустойчивость. Именно на репетиции обнаруживаются клиенты, у которых прописан только один DNS, или VPN, поднимающийся лишь после входа в систему.

Отдельно о ролях. Если в офисе контроллер совмещён с другими службами — например, DHCP или файловыми ресурсами, — эти службы не переедут на второй узел сами. Составьте список ролей, которые лежат на офисном контроллере, и для каждой решите: она должна пережить отказ или нет. Роли, которым нужно пережить, придётся устраивать отдельными средствами.

Реплика и копия: два разных ответа на два разных вопроса

Теперь можно сопоставить дополнительный узел с отдельной резервной копией. Они отвечают на разные вопросы.

Дополнительный контроллер отвечает на вопрос: что, если исчезнет одна машина или одна площадка? Его сила — в непрерывности: он уже работает и уже знает текущее состояние каталога. Его слабость мы разобрали: он знает и плохое состояние, если оно появилось.

Резервная копия отвечает на другой вопрос: что, если каталог оказался испорчен или потерян целиком, и нужно вернуться к известному хорошему моменту? Её сила — в возможности вернуться назад во времени. Её слабость — в том, что восстановление занимает время, а между копиями изменения пропадают.

Поэтому правильная схема использует оба инструмента, а не выбирает один. Реплика берёт на себя поломку железа и обрыв связи; копия — ошибки администрирования, вредоносные изменения и сбои самого каталога. Копию при этом стоит делать поддерживаемым способом для контроллера домена, а не снимком машины: как уже упоминалось, Microsoft не рекомендует снимок как замену такому резервному копированию. И хранить копию разумно не на том же VPS, чей диск она защищает, а в другом месте. В материалах MAATRIX нет подтверждения автоматических резервных копий для всех тарифов, так что считайте, что настройку копирования вы делаете сами и сами проверяете восстановление.

Есть ещё одна тонкость, связанная с возвратом. Если вы однажды восстанавливаете каталог из копии, при наличии нескольких контроллеров нужно заранее понимать порядок: какой узел считать авторитетным и как остальные будут приведены в соответствие. Этот сценарий лучше проработать на тестовой среде, потому что в аварии времени на эксперименты не будет. Принцип здесь простой: восстановление каталога — редкая и ответственная операция, и описывать её порядок надо до того, как она понадобится.

Что действительно переживёт отказ

Соберём результат без украшений. Ниже — то, что при аккуратной настройке второго контроллера на VPS за VPN действительно продолжит работать, если офисная площадка станет недоступной, и то, что не продолжит.

• Переживёт: проверка учётных записей на узле VPS для клиентов, которые до него дотягиваются по VPN, включая вход при поднятом на этапе входа туннеле.
• Переживёт: разрешение имён из доменной DNS-зоны, если на VPS есть её копия, а клиенты знают его адрес.
• Переживёт: административные операции с каталогом — сброс пароля, блокировка и отключение учётной записи, создание пользователя, — которые затем реплицируются в офис после восстановления связи.
• Не переживёт: файловые ресурсы, базы данных, принтеры, терминальный сервер и любые прикладные службы, оставшиеся в офисе: имя разрешится, но сервис по нему ответит только тогда, когда сам будет доступен.
• Не переживёт: роли офисного контроллера, которые вы не вынесли и не продублировали отдельно.
• Не защитит: от ошибочных или вредоносных изменений каталога — они реплицируются на оба узла, и для таких случаев нужна отдельная поддерживаемая копия, хранящаяся в другом месте.

Если в этом списке вы видите ровно то, что нужно вашему офису в день отключения, — второй контроллер на VPS оправдан и недорог по ресурсам. Если же вам нужно, чтобы продолжили работать сами рабочие данные и приложения, вопрос шире, и начинать надо с них, а не с каталога: контроллер лишь сообщит, что вы — это вы, а вот куда с этим идти, должно быть где-то живое.