Кластер балансировки сетевой нагрузки для хаб-серверов DFSR?

У меня есть один хаб-сервер DFSR с около 80 подключениями к 80 удаленным офисам.

Я хочу добавить еще один хаб-сервер для балансировки нагрузки и избыточности, но я не хочу разделять соединения между двумя хаб-серверами. Мне не нравится идея поддерживать \ администрировать два разных блока соединений на двух серверах.

отредактируйте лучшие практики Microsoft, например, для разделения соединений DFSR между несколькими серверами (если имеется много соединений с большим объемом, как в топологии концентратора и луча), потому что слишком много одновременных соединений с одним сервером может вызвать проблемы с производительностью. Единственная рекомендация - разделять соединения между серверами вручную. Я бы предпочел, чтобы несколько серверов-концентраторов были настроены одинаково (все концентраторы были настроены с подключениями ко всем удаленным офисам) и что-то вроде службы NLB автоматически делило соединения для меня.


Я хочу иметь 2 (или, возможно, больше) хаб-сервера, каждый из которых сконфигурирован со всеми 80 нечетными соединениями, выполняющими балансировку нагрузки с помощью чего-то вроде службы NLB. Я предполагаю, что это будет работать, потому что концентраторы DFSR могут динамически разделять соединения между собой и просто реплицировать обновления, полученные на любом из их подключений, к другому концентратору.

Я знаю, что вы можете сделать отказоустойчивый кластер DFSR, но из того, что я прочитал, отказоустойчивый кластер Windows не выполняет балансировку нагрузки. Таким образом, только один узел в отказоустойчивом кластере DFSR фактически активен одновременно - это правильно? Если так, то это не соответствует моим требованиям по балансировке нагрузки.

Я не нашел документов, связанных с настройкой кластера NLB с помощью службы DFSR. Это вообще возможно \ поддерживается? Если да, может ли кто-нибудь предоставить информацию о передовых методах работы с этим документом?

Если кластер NLB невозможен, есть ли способ сделать как циклический перебор DNS с записями SVR DNS или, возможно, какую-то настройку балансировки нагрузки "переднего плана".

Большое спасибо.

** редактировать Я думаю, я просто искал набор и забыл настройки. Единственный хаб пока что отлично справляется, но мы планируем добавить в нашу инфраструктуру DFSR.

Я думаю, мне придется решить, сохранить ли один концентратор и выполнить отказоустойчивый кластер со вторым, или разорвать соединения со вторым концентратором.

Я думаю, что я сделаю один концентратор с отказоустойчивым кластером на данный момент. Затем, если я решу разделить соединения в будущем, я всегда могу добавить еще один отказоустойчивый кластер (требующий еще 2 физических сервера) и разделить соединения между двумя отказоустойчивыми кластерами. Больше сложности, чем я хотел, но я думаю, что это единственный способ.

2 ответа

Решение

Это не может быть сделано. Поскольку топология DFS-R хранится в Active Directory, невозможно настроить членов группы репликации для использования имени / адреса кластера NLB или любого другого типа балансировщика нагрузки. Если вам нужна настраиваемая топология репликации, которую вы описываете с двойным концентратором, из соображений производительности, вам придется настроить ее вручную. DFS в масштабе, который вы описываете, может стать очень сложным и потребовать упреждающего управления. К сожалению, в таком размере нет "поставь и забудь".

Может быть, я не совсем понимаю ваш вариант использования здесь. Но позвольте мне нанести удар, так как никто не ответил.

Я предполагаю, что у вас есть 80 офисов, каждый с одним набором репликации для связи с вашим хабом. Поскольку вы можете установить "отправляющий элемент" в DFSR, вы сможете добавить другой сервер для передачи реплицированных данных на удаленные серверы. Это то, что называется "Mutli-Master Replication"

Таким образом, если у вас есть два "хаба" DFSR-сервера (или любое другое число), они должны быть в группе репликации. После настройки серверы "удаленных подключений" должны будут указывать на все "узловые" серверы и при необходимости будут реплицироваться. Они просто синхронизируются с первым доступным сервером.

Одна вещь, которую вам нужно решить, - убедиться, что удаленные устройства не пытаются синхронизировать данные обратно на оба "концентратора хоста". Сайты и службы должны быть правильно настроены для решения этой проблемы.

Я пропустил то, что вы спрашивали?

Другие вопросы по тегам