Параметры аварийного восстановления для RD Connection Broker 2012 (HA)

Введение

Как вы, наверное, знаете, посредник подключений к удаленному рабочему столу в развертывании VDI/RDS играет центральную и важную (если не решающую) роль в Windows Server 2012. Большая часть конфигурации развертывания хранится в базе данных подключений к удаленному рабочему столу. А при переводе в режим высокой доступности эта база данных хранится на центральном сервере SQL, где несколько серверов посредников подключений к удаленному рабочему столу могут читать и записывать в нее. Дополнительные сведения о настройке высокой доступности посредника подключений к удаленному рабочему столу см. в разделе Настройка высокой доступности для посредника подключений к удаленному рабочему столу в Windows 8.

Поскольку роль посредника подключений к удаленному рабочему столу очень важна, значительно улучшена возможность создания решения высокой доступности (HA) типа «активный-активный». Однако, поскольку все посредники подключений к удаленному рабочему столу в решении высокой доступности используют одну и ту же центральную базу данных SQL Server, эта база данных (и экземпляр, на котором она работает) внезапно становится вашей единой точкой отказа. Чтобы преодолеть это, важно также внимательно изучить варианты настройки среды SQL Server высокой доступности для ваших посредников подключений к удаленному рабочему столу. Кроме того, регулярное резервное копирование базы данных посредника подключений к удаленному рабочему столу, очевидно, также настоятельно рекомендуется и избавит вас от многих проблем в случае серьезного сбоя SQL Server.

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

В любом из сценариев, которые мы будем описывать, результат с точки зрения посредника подключений к удаленному рабочему столу одинаков. Серверы посредника подключений к удаленному рабочему столу не могут подключиться к базе данных. При открытии службы управления удаленным рабочим столом (RDMS) в составе диспетчера серверов мы увидим следующую ошибку.

Рисунок 1: Сообщение об ошибке RDMS

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

Рисунок 2: Служба RDMS остановлена

И все серверы посредника подключений к удаленному рабочему столу, которые являются частью развертывания, будут отображать следующую ошибку в журнале событий с идентификатором события 2048.

Рис. 3. Идентификатор события 2048.

Сценарии восстановления

Рассмотрим различные сценарии восстановления.

1. Восстановите только базу данных посредника подключений к удаленному рабочему столу.

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

Сначала убедитесь, что служба RDMS на всех серверах посредника подключений к удаленному рабочему столу остановлена. Затем восстановите базу данных RDMS из резервной копии. В этом случае я использовал диспетчер SQL Server, но, очевидно, это может быть любое решение для резервного копирования SQL.

Рисунок 4: Восстановление базы данных RDMS

Теперь снова запустите службы RDMS на всех посредниках подключений к удаленному рабочему столу. Если мы снова откроем (или обновим) консоль RDMS в диспетчере серверов, развертывание должно быть видимым и полностью восстановленным.

2. Восстановите экземпляр SQL Server посредника подключений к удаленному рабочему столу.

В случае, если экземпляр SQL Server полностью потерян, но у вас все еще есть резервная копия базы данных, необходимо несколько параметров конфигурации, но вы, скорее всего, сможете получить все параметры конфигурации. Сначала необходимо перестроить сам экземпляр SQL Server. Поскольку мы собираемся восстанавливать исходную базу данных, убедитесь, что вы перестроили сервер SQL с той же версией и что имя сервера и экземпляра SQL такое же, как и раньше. Базовая установка SQL Server 2012 выходит за рамки статьи. С этого момента мы предполагаем, что SQL Server снова работает.

Убедитесь, что вы установили правильные разрешения для сервера посредника подключений к удаленному рабочему столу, чтобы иметь возможность создавать базу данных. В этом случае я использовал группу безопасности AD, содержащую серверы посредника подключений к удаленному рабочему столу, и добавил ее в качестве субъекта безопасности в SQL Server.

Также убедитесь, что SQL Server доступен для серверов посредников подключений к удаленному рабочему столу через TCP-порт 1433.

Также убедитесь, что служба RDMS на всех серверах посредника подключений к удаленному рабочему столу остановлена. Теперь мы восстанавливаем базу данных в SQL Server. В зависимости от вашего механизма резервного копирования и используемой версии SQL Server необходимые шаги могут различаться. В этом случае я прилагаю копию.mdf и соответствующего файла.ldf.

Рисунок 5: Восстановление базы данных RDMS

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

Рисунок 6: Разрешения для восстановленной базы данных

Теперь мы снова запускаем службу RDMS на всех серверах посредников подключений к удаленному рабочему столу.

Рисунок 7: запуск сервисов RDMS

Если мы снова откроем (или обновим) консоль RDMS в диспетчере серверов, развертывание должно быть видимым и полностью восстановленным.

Рисунок 8: RDMS восстановлена

3. Перестройте все посредники подключений к удаленному рабочему столу.

Если база данных SQL Server полностью потеряна и нет пригодной для использования резервной копии базы данных, то конфигурация, которая хранилась в базе данных, очевидно, потеряна. В этом случае вам потребуется перестроить базу данных посредника подключений к удаленному рабочему столу с нуля, а также переустановить как минимум роли посредника подключений к удаленному рабочему столу.

Первый шаг — удалить роли посредника подключений к удаленному рабочему столу со всех серверов, на которых выполнялась роль посредника подключений к удаленному рабочему столу и которые были частью развертывания. Однако, прежде чем мы это сделаем, если у вас нет документации о том, что было настроено, вы можете просмотреть реестр посредника подключений к удаленному рабочему столу. Это все еще должно показывать части конфигурации. Вы можете создать резервную копию этой части реестра, чтобы на более позднем этапе использовать эту информацию для ручного воссоздания части конфигурации. Например, вы можете просмотреть информацию о ранее опубликованных удаленных приложениях.

Рисунок 9: Реестр посредника подключений к удаленному рабочему столу

Давайте продолжим, удалив сейчас роли брокера подключения к удаленному рабочему столу. Мы можем сделать это централизованно с сервера управления, если все серверы добавлены в диспетчер серверов, или путем индивидуального входа на каждый сервер посредника подключений к удаленному рабочему столу.

Рисунок 10: Удаление ролей посредника подключений к удаленному рабочему столу

Теперь нам, очевидно, нужно перестроить SQL Server. Процесс установки Windows Server 2012 и базовой установки SQL Server 2012 выходит за рамки статьи. С этого момента мы будем предполагать, что Windows Server 2012 установлена и выполнена базовая установка SQL Server 2012.

Убедитесь, что вы установили правильные разрешения для сервера посредника подключений к удаленному рабочему столу, чтобы иметь возможность создавать базу данных. В этом случае я использовал группу безопасности AD, содержащую серверы посредников подключений к удаленному рабочему столу, и добавил ее в качестве субъекта безопасности в SQL Server с ролью dbcreator.

Рисунок 11: Добавление разрешений SQL для баз данных посредника подключений к удаленному рабочему столу

Также убедитесь, что SQL Server доступен для серверов посредников подключений к удаленному рабочему столу через TCP-порт 1433.

Теперь мы готовы переустановить наше развертывание Session-Based Desktop. Мы возвращаемся к нашему серверу управления и выполняем развертывание на основе сценария, выбрав установку служб удаленных рабочих столов в мастере добавления ролей и компонентов. Мы не будем рассматривать все детали в мастере, но убедитесь, что вы выбрали те же самые параметры, что и при предыдущем развертывании. Это означает, что мы выбираем один и тот же (первый) сервер для запуска роли посредника подключений к удаленному рабочему столу, тот же (первый) сервер для запуска роли веб-доступа к удаленному рабочему столу и те же серверы для запуска ролей узла сеансов удаленных рабочих столов.

Рисунок 12: Повторный запуск развертывания

Когда мастер закончит, развертывание будет завершено. Не то чтобы единственная роль, которую мы действительно переустановили, — это роль посредника подключений к удаленному рабочему столу. Мастер обнаружит, что другие роли уже установлены, и добавит в развертывание только эти серверы. По завершении работы мастера RDMS снова становится работоспособной, и мы снова можем управлять нашим развертыванием с помощью диспетчера серверов. Однако все настройки, которые были настроены через RDMS, очевидно, исчезли, так как сейчас мы работаем над новой, чистой базой данных. Поэтому нам будет представлено развертывание по умолчанию, содержащее только наши серверы RD Connection Broker, RD Web Access и RD Session Host.

Рисунок 13: Развертывание по умолчанию

Это означает, что с этого момента вам придется перенастроить удаленные приложения, параметры сеанса, сертификаты и т. д. Обратите внимание, что часть этой конфигурации вы можете восстановить вручную, просмотрев параметры реестра, резервные копии которых были созданы ранее. Также обратите внимание, что это развертывание теперь использует базу данных SQL Server Express на выбранном нами посреднике подключений к удаленному рабочему столу. Это означает, что настройку High Availability также необходимо выполнить повторно. Однако это действие не затрагивает две роли: шлюз удаленных рабочих столов и роль лицензирования удаленных рабочих столов. Эти две роли настраиваются не с помощью RDMS, а с помощью отдельных оснасток MMC на самом сервере. Таким образом, сохраняется такая информация, как конфигурация RD CAP, RD RAP и RDS CAL.

Этот последний сценарий, конечно, самый сложный, поскольку нам приходится вручную перенастраивать каждый параметр в RDMS. В зависимости от размера среды и количества настроек и изменений, выполненных после первоначального развертывания, время, необходимое для повторной настройки до исходного состояния, может варьироваться.

Вывод

Как упоминалось во введении к этой статье, роль посредника подключений к удаленному рабочему столу играет очень важную роль в средах RDS/VDI в Windows Server 2012. Поэтому крайне важно обеспечить высокую доступность базы данных SQL, чтобы она не стала единой точкой отказа. Если создание какой-либо формы SQL Server High Availability не является вариантом в вашей среде, по крайней мере убедитесь, что вы регулярно создаете резервные копии базы данных SQL. Как мы видели, аварийное восстановление данных вашего посредника подключений к удаленному рабочему столу (и, следовательно, данных RDMS) возможно, но насколько быстрое и насколько точное восстановление сильно зависит от ваших решений SQL HA и резервного копирования.