High Availability RD Connection Broker на базе Windows Server 2012–выявленная закономерность в конфигурации с более чем 3 серверами

imageВ процессе тестирования конфигурации описанной в предыдущей статье выявлена странная закономерность в поведении работы высоко-доступного экземпляра RD Connection Broker (RDCB). Обнаружено, что если роль RDCB (в режиме High Availability) добавлена в развёртывании RDS более чем на три сервера (в нашем случае - на пяти серверах), то адекватно работают с общей базой данных RDCB не более трёх серверов, на которые раньше всего была развёрнута эта роль.

Чтобы стало понятней, о чём я говорю, опишу ситуацию, когда завершив все настройки развёртывания RDS мы начали тестировать работу механизма высокой доступности RDCB, эмитируя поочерёдную недоступность серверов. Как известно, в ферме RDCB всегда какой-то один сервер выступает в роли активного сервера управления.

image

После того, как активный сервер управления становится недоступен, служба RDCB назначает эту роль другому доступному серверу RDCB. Было решено протестировать механизм передачи этой роли от одного сервера к другому. Сначала были выключены все сервера, а затем мы стали по одному включать каждый сервер, чтобы убедиться в том, что включённый сервер, находясь в "гордом одиночестве", успешно захватывает роль активного сервера управления, успешно принимает и делает перенаправление клиентских подключений. Начали в том же порядке что и выполняли добавление серверов в High Availability RDCB, то есть первым включили KOM-AD01-RDS21…

image

Первые тесты порадовали и показали, что сервер выполняет все свои функции так, как мы от него этого ожидаем. Затем таким же образом проверили сервера KOM-AD01-RDS22 и KOM-AD01-RDS23…всё удачно. Однако при попытке завести в одиночестве KOM-AD01-RDS24 или KOM-AD01-RDS25 получили полный облом – RDCB не мог выполнить перенаправление клиентов, хотя роль активного сервера управления вроде как захватывалась сервером, по крайней мере об это свидетельствовали данные консоли Server Manager и результат выполнения вышеприведённого PS-командлета. Эти два сервера не перенаправляли клиентов даже если были включены оба…
Как только мы включали любой из первых трёх серверов – всё начинало работать как ни в чём не бывало… Дальше было много экспериментов в попытках понять такое поведение RCDB… Дойдя до того момента когда все сервера по очереди были исключены из High Availability Connection Broker стало очевидно то, что теперь с БД начали нормально работать другие три сервера – те которые по времени добавления в High Availability Connection Broker оказались самыми старшими. То есть исключали/включали сервера в HA RDCB мы в обратном порядке (c KOM-AD01-RDS25 по KOM-AD01-RDS21). И так как в итоге самыми “бывалыми” тремя серверами оказались KOM-AD01-RDS25,KOM-AD01-RDS24,KOM-AD01-RDS23, они без проблем в одиночестве справлялись с задачами перенаправления клиентов, а сервера KOM-AD01-RDS22 и KOM-AD01-RDS21 стали вести себя как ранее себя вели сервера KOM-AD01-RDS25 и KOM-AD01-RDS24.

Таким образом стало очевидно, что с БД вменяемо работают только три (самых старших по времени включения в High Availability RDCB) сервера…

Получается, что в рассмотренной нами ранее конфигурации, для того, чтобы ферма RDS (состоящая из пяти серверов) была "живой" и успешно принимала и перенаправляла клиентов, нам необходимо обеспечить доступность хотя бы одного из трёх "бывалых" серверов…

Учитывая то, что нигде в официальной документации я не смог найти упоминания о таком ограничении, теперь даже не знаю как трактовать этот факт. Считать это багом или фичей … не знаю. С одной стороны такую логику можно понять, если рассматривать концепцию, при которой в больших развёртываниях RDS роль RDCB выносится на отдельные сервера. В таком случае иметь более трёх серверов действительно может быть бессмысленно. Но если следовать этой логике, то отдельная установка роли RDCB на выделенный сервер не должна вызывать вопросов, однако что мы видим вместо этого… При развёртывании RDS на первым же сервере в развёртывании нас вынуждают (без вариантов выбора) "корячить" сразу все три роли -RD Connection Broker, RD Session Host, RD Web Access. Да и потом, когда мы добавляем в уже существующий High Availability RDCB с тремя серверами четвёртый, пятый и т.д. сервер – мы не получаем никаких предупреждений о том, что это бессмысленно. Как-то не укладывается вся эта логика у меня в голове… Собственно, всё что я хотел сказать этим постом – констатировать факт, чтобы другим не пришлось разбивать голову об эти же грабли, ибо у меня с коллегой по работе ушёл не один день на то, чтобы выявить такую вот странную закономерность в работе High Availability RDCB на базе Windows Server 2012…Вот такая вот Харе Кришна Улыбка

Очень интересно будет услышать другие мнения и наблюдения по поводу работы High Availability RDCB на базе Windows Server 2012…

Всего комментариев: 6 Комментировать

  1. volk1234 /

    Согласен странно, но это явно заложено в дизайне.
    Заинтересовался бы, если бы считал Сервер 2012 жизнеспособной системой ;)
    А так.... RDS в 2008 сервере достигла своего апогея, все нововведения мне не понравились,
    считаю их вредными :) Вот такой я консерватор.

  2. Dmitry Kotomin (@itdimko) /

    У меня 2 сервера настроены по такой схеме, не работает =\
    Если на 1-с сервере показывает активный сервер RDCB, то при его отключении на втором сервере выдает вот такую гадость:

    PS C:\Windows\system32> Get-RDConnectionBrokerHighAvailability
    Get-RDConnectionBrokerHighAvailability : Активный сервер управления удаленными рабочими столами недоступен.
    строка:1 знак:1
    + Get-RDConnectionBrokerHighAvailability
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Get-RDConnectionBrokerHighAvailability

    1. Алексей Максимов / Автор записи

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

  3. Dmitry Kotomin (@itdimko) /

    Алексей,
    1-й сервер еще не включал, вот только что проверил на 2-ом - роль активного брокера передалась. Спасибо.

    Но каков смысл отказоустойчивости, если при внезапном выходе из строя одного из серверов (или только активного брокера?) зависнет сеанс и переподключение к 2-му серверу не будет возможным, это не говоря о том что пользовательский сеанс так или иначе умирает. Я не очень знаком с возможностями ферм рабочих столов, но судя по изученному материалу (RDS на основе Windows Server 2008R2-2012) однозначного решения нет, чтобы обеспечить беспрерывный доступ к сеансам пользователей или быстрого переключения.
    Если я не понимаю смысл всей этой затеи, то хотел бы Вам попросить растолковать по какому принципу должна функционировать рабочая ферма в различных вариантах отказа. Заранее спасибо.

    В голове лишь кластеризация Hyper-V хостов с фишками Live Migration, но это совсем другая тема которую пока что не могу применить, так как нет для этих нужд СХД.

    Зы. Спасибо за внятные статьи, по которым и производил настройки фермы.

    1. Алексей Максимов / Автор записи

      Первое что хочется сказать, - правильнее всё-таки будет применять термин "высокодоступный" нежели "отказоустойчивый", так как RD брокер не способен избавить нас от отказов в обсуживании, а лишь служит для повышения шансов клиентов на подключение к пулу RDSH серверов с простейшим механизмом распределения активных сессий между этими серверами.
      По поводу отсутсвия однозначного решения не соглашусь, на Technet оно вполне явно позиционируется в виде использования связки HA RDCB (несколько серверов с ролью RDCB подключенных к общей БД) и DNS Round Robin. Однако использование DNS RR по моему мнению это ещё бОльшая лажа чем предложенный мной вариант с NLB.
      По поводу оперативности срабатывания механизма переключения роли активного брокера сам считаю, что он в Windows Server 2012 реализован недостаточно вменяемо... теплется надежда на то, что в WS 2012 R2 есть какие-то улучшения в этом плане (пока не добрался до RDS новой версии).
      Кластеризация Hyper-V это конечно хорошо, но она обеспечит высокую доступность лишь на нижнем уровне, т.е. самих виртуальных серверов, в то время как HA RDCB это более высокий уровень повышения доступности со всеми вытекающими. И кстати, насколько я знаю, кластер Hyper-V в Windows Server 2012 R2 можно строить и без дорогостоящих выделенных СХД, если есть хорошая сеть и быстрый файловый сервер с SMB 3.0.
      Если у Вас остаются какие-то вопросы, можем продолжить их более развёртнутое обсуждение на нашем форуме.

      1. Dmitry Kotomin (@itdimko) /

        Написал на форуме, Алексей. Давайте обсуждать http://forum.it-kb.ru/viewtopic.php?f=5&t=23

Добавить комментарий