У меня есть несколько вопросов по поводу конфигурации серверов и DNS. 1. Если у нас около 50 пользователей, то лучше использовать один сервер, поскольку использование DAG может создать дополнительные сложности для администратора, особенно при миграциях. Правильно ли я понимаю, что стоит рассматривать внедрение DAG только при количестве пользователей от 500 до 1000? 2. У нас есть пять объектов, связанных через чистый IPsec в архитектуре "звезда". Если центральный сервер выйдет из строя, DNS и доступ в интернет везде перестанут работать. Стоит ли тогда рассмотреть возможность организации еще одного-двух DNS-серверов с ролью только для чтения (RO) в наиболее критичных объектах? Предположим, центральный сервер и два DNS в офисе перестают функционировать. В такой ситуации будут ли два удаленных офиса продолжать работать со своим DNS RO, или это не так просто?
1. **Внедрение DAG (Database Availability Group)**: Вы правы в своих размышлениях по этому вопросу. Для небольшой организации с 50 пользователями использование одного сервера Exchange обычно вполне достаточно, и внедрение DAG может действительно внести ненужные сложности в управление и администрирование, особенно в контексте миграций и обновлений. DAG имеет смысл рассматривать в больших разветвленных средах, где требуется высокая доступность и устойчивость, что чаще встречается при количестве пользователей от 500 до 1000 и более, когда можно обосновать затраты на экипировку и управление несколькими серверами. 2. **DNS-серверы в критических местах**: В ситуации, когда у вас есть центральный сервер, от которого зависят DNS и доступ в интернет для удаленных офисов, может быть полезным рассмотреть развертывание дополнительных DNS-серверов с ролью "только для чтения" (RO). Эти серверы могут хранить кэшированные данные и реплицировать необходимую информацию, что позволит сохранить доступ к важной информации, если центральный сервер выходит из строя. Если, как вы описали, центральный сервер и два DNS в офисе перестанут функционировать, два удаленных офиса с развернутыми DNS RO смогут продолжать работать, если на этих DNS-серверах есть актуальные записи кэша. Однако важно помнить, что при этом может возникнуть проблема, если динамические записи DNS были созданы на центральном сервере, так как они не обновятся на RO-серверах. Поэтому целесообразно иметь стабильную инфраструктуру DNS, где к каждому офису будет доступен хотя бы один DNS-сервер, чтобы минимизировать точки отказа и повысить доступность ресурсов. Таким образом, создание дополнительного DNS-сервера с ролью только для чтения в критических объектах может быть целесообразным решением для повышения отказоустойчивости вашей инфраструктуры.
Вообще задавать несколько вопросов в одном это такое себе..
про AD
RODC нужен не только для DNS. Чисто ради DNS вы можете и кеширующий dnsmasq поднять - это и дешевле, и проще, если чисто ради резолвинга.
RODC нужен больше для безопасности, плюс его функция так же включает, в случае отвала основных DC, кеширование паролей пользователей и ридонли копию каталога.
Если вы сильно завязаны на использование домена, что пользователи без входа в AD не смогут работать с локальными ресурсами\приложениями - то RODC лучше поднять. Или настроить резервный канал между основным и удаленным офисом. Кроме того, помните про настройку сайтов в AD
Если у вас, скажем, 5 удаленных офисов, а настроены и прописаны 2 RODC в двух из них, то весь трафик AD на сайтах где они настроены RODC будут пропускать через себя - возможны ненужные маршруты между удаленными офисами перед походом на центральный RODC для аутентификации и получении данных AD
Лучше изучите еще раз вопрос по планированию AD, RODC и вашей ситуации с сетью офисов и определите какую конкретно задачу вы будете решать и какие риски ее возникновения, прежде чем приниматься за решение.
DAG
Exchange DAG он немного не про производительность, а про высокодоступность. Поэтому, если ваши 1000 пользователей обслуживаются одним сервером без DAG и процедуры восстановления данных отработаны и восстановление происходит в допустимое время, то можно жить и на одном. Однако если ресурсы позволяют - я бы в случае корпоративной почты все таки задумался о высокодоступности, при любом количестве пользователей.