На моём предприятии была поставлена задача развернуть для системы 1С серверную инфраструктуру. Одной из частей которой оказалась терминальная ферма. Но, так как, кроме виртуальных, другие серверы делать мы уже разучились, пришлось задуматься о нюансах реализации. В данной статье опишу моменты, касающиеся балансировки сетевой нагрузки и обеспечения надежности.
Как будем балансировать?
Для балансировки сессий Windows Server 2008(R2) достаточно далеко продвинулся в сравнении 2003, получив развитие Session Directory в виде службы Session(Connection) Broker, который размещает сессии пропорционально заданным весам.
Для балансировки сетевых подключений в Windows Server есть две стандартные функции: Network Load Balancing(NLB) и Domain Name System Round Robin (DNS RR).
На мой взгляд, NLB достаточна сложна в настройке, особенно в виртуальных средах, и требует дополнительных настроек сетевого оборудования. Для рекомендованного режима MultiCast вы настраиваете физические коммутаторы, для режима UniCast меняете режим нотификации vSwitch. К сожалению, в нашей сети с кучей VLAN, мы не смогли добиться стабильной работы терминальной фермы на основе Windows 2003 Server TS при операции vMotion – происходит кратковременный развал NLB-кластера, после восстановления которого отсоединяется часть клиентских сессий.
Посидев с коллегой на обеде и порассуждав о сетевой балансировке, мы решили, что потребности в NLB на текущий момент нет. Поиск в интернете выдал замечательную статью Ильи Сазонова “Анти NLB в ферме терминальных серверов“.
Соответственно, наш выбор лёг на DNS RR, которая требует минимум действий – добавление нескольких А-записей для узлов и отключения у них кэширования. Отличное описание механизма и настроек описано в статье Алексея Горбунова “Что такое DNS Round robin?”
Как будем обеспечивать надежность компонентов?
Для терминальной фермы важно обеспечить защиту при отказах следующих компонентов: каталога терминальных профилей и сам брокер сессий(подключений) (Session(Connection) Broker). Ноды масштабируются путём увеличения их количества и за счет сетевой балансировки, так что особого внимания к себе не требуют.
Данные компоненты на текущий момент, пока не вышел Windows Server 2012, можно защитить через функцию Failover Cluster(MSCS).
IMHO, использование данного типа кластера в VMware vSphere представляет собой наступание на нехилый комплект граблей. Поэтому читаем и перечитываем следующие документы:
- Поддерживаемые конфигурации MSCS в vSphere
- Настройка Failover-кластера в vSphere 5, а также в прочих версиях
- Что делать, если хосты с пассивными нодами MSCS загружаются по полчаса
- Пошаговая инструкция по настройке MS Failover Cluster
Схема решения
Основные нюансы осветили, остаётся продемонстрировать получившуюся у нас архитектуру:
То есть Вы не советуете строить Failover Cluster(MSCS) для кластеризации брокера подключений на vSphere 5.1 (ESXi 5.1) ?
Я такого не говорил ;), более того, мы используем данную технологию для брокера подключений, о чём написано в статье.
Для использования Failover Cluster в vSphere нужно дотошно разобраться, как и что настроить. Примеры нюансов:
Пример 1: https://vmind.ru/2013/02/19/vmware-vsphere-5-1-vs-emc-vnx-vs-multipathing-vs-mscswsfc/
Пример 2: vSphere 5.1 (U1) официально не поддерживает Failover Cluster в Windows Server 2012 на текущий момент, хотя у некоторых работает http://www.thelowercasew.com/windows-2012-failover-clusters-and-vsphere-5-1
Спасибо, за ссылочки, у меня vMware 5.1, сделал 5 терминалок на W8KR2, и кластеризовал на них службу брокера подключений MSCS. Периодически кластер сыпался (редко), но не приятно. Общего диска нет.
Сейчас настроил vMware по документу:
http://pubs.vmware.com/vsphere-51/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-51-setup-mscs.pdf
Понаблюдаем, если будет опять шалить, думаю отказаться от MSCS кластера, а брокера вывести на отдельную ВМ.