Отазоустойчивость с помощью NLB

[serious]

Добрый день!

Подскажите, пожалуйста, как реализовать отказоустойчивость с помощью NLB на Server 2008 Standart

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

Если сервер, где я настраиваю Nlb, отключится, что тогда...?

[dimokkk]

Приветствую!
Вообще-то NLB - это балансировка нагрузки: т.е. размазывание общей нагрузки по нескольким серверам.
Отказоусточивость в Windows реализуется с помощью кластеров.
Что вам нужно получить в итоге. Опишите задачу подробнее!

[serious]

Балансировка нагрузки тоже не помешает, но основная задача это обеспечить отказоустойчивость. Сервер используется в качестве сервера терминалов с количеством пользователей 15 чел. Недавно вышел из строя и офис "повис" на длительное время..

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

Спасибо.

[dimokkk]

Если нужно сделать балансировку нагрузки именно терминального сервера - разворачивайте Connection Broker. Подробности тут.
Но это не совсем отказоустойчивость - при падении одного из серверов - вы потеряете сесии пользователей, но они смогут перелогиниться на другой сервер фермы.
Возникает вопрос - а обеспечивается ли отказоустойчивать самого приложения? Что будет если упадет Applicaion Server?

[serious]

У меня Windows Server 2008, а RD Connection Broker появился в R2..

Как быть с личными данными пользователя, если все же получится настроить перенаправление на другой сервер в кластере, то данные пользователя где храниться будут?

[itpro]

Вместо Connection Broker можно настроить NLB - но имхо оно того не стоит, проще сделать простейший DNS Round Robin как описано в ссылке, приведенной dimokkk. Т.е. настоящий баланисровки не будет, но по крайней мере каждый новый сеанс будет отправляться на разные терминалы.

Профили и личные папки пользователя в такой конфигурации обычно хранятся в некой сетевой папке (здесь опять вопрос отказоустойчивости файлового сервера с профилями и данными пользователя) и подключаются через перенаправление папок (Folder Redirection). Это настраивается с помощтю групповых политик - т.е. пользователь входит на терминальный сервер и ему подгружается его профиль и папки, которые реально хранятся на другом файловом сервере.

[dimokkk]

Вместо Connection Broker можно настроить NLB - но имхо оно того не стоит, проще сделать простейший DNS Round Robin как описано в ссылке, приведенной dimokkk. Т.е. настоящий баланисровки не будет, но по крайней мере каждый новый сеанс будет отправляться на разные терминалы.

Профили и личные папки пользователя в такой конфигурации обычно хранятся в некой сетевой папке (здесь опять вопрос отказоустойчивости файлового сервера с профилями и данными пользователя) и подключаются через перенаправление папок (Folder Redirection). Это настраивается с помощью групповых политик - т.е. пользователь входит на терминальный сервер и ему подгружается его профиль и папки, которые реально хранятся на другом файловом сервере.

Проблема в том, что при таком раскладе при выходе одного сервера из строя - сессии будут теряться, и все несохраненные данные пользователя будут потеряны. Следующую сессию (она по сути будет) новой он начнет только с теми данными. которые были сохранены в папке с его перемещаемым профилем.
Может быть вообще стоит задуматься о покупке двух мощных серверов с накатыванием туда гипервизоров (хоть VMWare ESXi, хоть Hyper-V) - на них таким образом можно сделать отказоустойчивыми сразу все задачи: и треминал и базу и файл-сервер.

[itpro]

Вместо Connection Broker можно настроить NLB - но имхо оно того не стоит, проще сделать простейший DNS Round Robin как описано в ссылке, приведенной dimokkk. Т.е. настоящий баланисровки не будет, но по крайней мере каждый новый сеанс будет отправляться на разные терминалы.

Профили и личные папки пользователя в такой конфигурации обычно хранятся в некой сетевой папке (здесь опять вопрос отказоустойчивости файлового сервера с профилями и данными пользователя) и подключаются через перенаправление папок (Folder Redirection). Это настраивается с помощью групповых политик - т.е. пользователь входит на терминальный сервер и ему подгружается его профиль и папки, которые реально хранятся на другом файловом сервере.

Проблема в том, что при таком раскладе при выходе одного сервера из строя - сессии будут теряться, и все несохраненные данные пользователя будут потеряны. Следующую сессию (она по сути будет) новой он начнет только с теми данными. которые были сохранены в папке с его перемещаемым профилем.
Может быть вообще стоит задуматься о покупке двух мощных серверов с накатыванием туда гипервизоров (хоть VMWare ESXi, хоть Hyper-V) - на них таким образом можно сделать отказоустойчивыми сразу все задачи: и треминал и базу и файл-сервер.

Конечно, можно! Вопрос в том, сколько будет стоить такая взрослая конфигурация, тут на одних серверных лицензиях можно разориться .
Вопрос к ТС: возможно ли обновление до 2008 R2, или нужно поместиться в рамках Server 2008?

[serious]

Вопрос к ТС: возможно ли обновление до 2008 R2, или нужно поместиться в рамках Server 2008?

Можно и обновить до R2..Если данные пользователей хранить на отдельном файловом сервере, то для отказоустойчивости можно использовать DFS (http://fedoseyev.ru/2010/02/undying-dfs-based-file-server/) ?

По-поводу лицензий, если я буду использовать два сервера с 2008 R2, CAL и RDS CAL нужно дублировать?

[itpro]

В принципе, DFS подойдет - тут стоит задуматься о том, будет ли успевать осуществляться репликация файлов между узлами DFS: если данные изменяются нечасто и не по многу, DFS сойдет.
По поводу лицензий - RDS CAL по идее дублировать не нужно, т.к. в один момент времени пользователем (или компьютером) инициируется только одна терминальная сессия. Как быть с обычными  CAL и нужно ли их дублировать - не подскажу.  Лучше обратиться к специалистам по лицензированию MS 

[serious]

В принципе, DFS подойдет - тут стоит задуматься о том, будет ли успевать осуществляться репликация файлов между узлами DFS: если данные изменяются нечасто и не по многу, DFS сойдет.
По поводу лицензий - RDS CAL по идее дублировать не нужно, т.к. в один момент времени пользователем (или компьютером) инициируется только одна терминальная сессия. Как быть с обычными  CAL и нужно ли их дублировать - не подскажу.  Лучше обратиться к специалистам по лицензированию MS 

Большое спасибо за помощь!

[itpro]

Хотя, насколько я помню, в 2008 роль Connection Broker была, просто она называлась немного по другому  - вроде Terminal Services Session Broker (TS Session Broker),

[serious]

Добрый день!

Установил Server 2008 R2, настроил терминальный доступ, поставил AD...приступил к настройке RD Connection Broker, как описано здесь
Но проблема возникла в ШАГ 2 : ДОБАВЛЯЕМ СЕРВЕРА RD SESSION HOST В ЛОКАЛЬНУЮ ГРУППУ SESSION BROKER COMPUTERS.

Для установки RD Connection Broker система попросила Active Directory, я его установил..как теперь добавить сервер в группу? Заходил в Active Directory Пользователи и компьютеры->Компьютеры посредника сеансов...туда добавить?



(Как я понимаю предварительно необходимо добавить второй сервер в домен?)

[itpro]

Бодрого утра!
На каждом из серверов с ролью терминального сервера и на сервере с ролью Connection Broker (если для него выделен отдельный сервер) нужно добавить все сервера фермы в локальную (не доменную) группу SESSION BROKER COMPUTERS
Для нормальной работы домен нужен обязательно (иначе каким образом сервера будут соотносить пользователей...).

[serious]

Нашел статью статью
Но здесь схема для 3-х серверов в кластере, получится ли реализовать для 2-х?
Смущает следующее

...исходя из нашей конфигурации, мастером будет автоматически создан кластер с моделью кворума большинства узлов – Node Majority. Это значит, что наш кластер будет оставаться в работоспособном состоянии (принимать запросы от клиентов) только в том случае, если будет доступно минимум два серверных узла из трёх...