Опыт разработки и внедрения Распределенной единой системы удаленных рабочих столов

Содержание

Краткие сведения

Распределенная единая система удаленных рабочих столов (РЕСУРС) — IT решение, представляющее из себя совокупность серверов удаленных рабочих столов, обеспечивающих работу пользователей в общей идентичной рабочей среде. Решение имеет отказоустойчивое ядро, построенное по принципу избыточности, с обеспечением прозрачной отработки отказа серверов ядра. Решение построено на базе серверов суперкомпьютеров Neclus и ВККС. Серверы работают под управлением Windows Server 2008, 2008 R2. Идея предложена и реализована сотрудниками вычислительного центра ДонНТУ в 2014 г. Реализацией проекта и обслуживанием системы с 2014 по 2017 гг. занимались сотрудники ВЦ, затем ЦИКТ. В 2015 году решение представлено в ДонНТУ как инновация [1].

История появления РЕСУРС

Я начал карьеру системного администратора в ДонНТУ в 2010 году. Первое время в мои задачи входило поддержание работоспособности программной и аппаратной части компьютерной техники в учебных аудиториях 11 корпуса, которые были закреплены за Вычислительным центром. Всего насчитывалось 7 таких аудиторий, компьютеров — не более 10-15 в каждой. Работал я не один, у нас предусматривалось разделение труда, при котором один специалист занимался только программной частью, а другой только аппаратной. Я начинал с программной. Принимая территорию, мне понадобилось время привести все системы в порядок, было не просто, я до этого никогда не работал с системами 95/98 года, к слову, синий экран из-за отсутствующей дискеты меня сильно пугал в первое время…

Шел 2013 год, количество компьютеров на обслуживаемой территории сокращалось с каждым семестром. Этому способствовало множество факторов, преобладающим был типичный износ. Политическая и финансовая обстановка в стране оставляла желать лучшего, как следствие, возможности обновить парк компьютеров университет не имел. При этом, работать на машинах, имеющих характеристики: ЦП 100 МГц, ОЗУ 16 МБ — становилось невозможно, к тому же состояние поверхностей жестких дисков было, сами понимаете, крайне изношенным. Поэтому, такие машины уже не рассматривались как рабочие инструменты.

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

Меня посвятили в то, что такие разработки ВЦ уже делал, и все закончилось нехваткой ресурсов, не хватало оперативной памяти на конечных машинах. Такие эксперименты проводили на базе Linux, требовалось всего лишь 256 Мб на каждой машине, мощный сервер и производительная сеть. На самом деле, такой размер оперативной памяти в общем-то позволял спокойно работать с компьютером под управлением Windows XP, просто не перегружая систему всяким мусором. Такой проект не увенчался успехом.

В моем распоряжении были машины с 16 мегабайтами оперативной памяти, и я не терял надежду использовать их в роли терминалов. В результате тщательного поиска решение было найдено, на тот момент WTware выпускали клиент, для которого было достаточно 16 МБ ОЗУ [2]. К слову, у этих ребят очень много полезной документации по развертыванию решений на базе серверов удаленных рабочих столов. Мной был развернут сервер удаленных рабочих столов на базе Windows Server 2003 на виртуальной машине, на ноутбуке, и были проведены первые эксперименты в ауд. 11.426. Была загружена целая аудитория. Для меня это было первым достижением. Стоит отметить, что образ Windows Server 2003 был получен в рамках программы DreamSpark от Microsoft, по которой студенты учебных заведений в образовательных целях могли получить лицензионное ПО Microsoft бесплатно [3].

Дальнейшие эксперименты проводились уже с использованием более мощного сервера, а в качестве ОС терминалов был подготовлен специальный образ на базе ThinStation, для более мощных терминалов (460 МГц, 64 МБ) [4]. Отличие от WTware в основном заключалось в наличии более производительной графической системы и возможностью подключать к сеансу съемные носители. WTware так же умеет работать со сменными носителями, но это доступно только в коммерческой версии. Именно это и способствовало прочтению уймы мануалов по сборке ThinStation.

Руководством были рассмотрены и проанализированы результаты. Стоит отметить, что все понимали одну тонкость — остановка работы сервера удаленных рабочих столов или потеря соединения с ним вызовет остановку работы во всех аудиториях. Такое нарушение в работе ВЦ не мог себе позволить и так появился новый ряд требований:

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

Отказоустойчивость

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

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

Сделаю небольшое отступление, хочу обратить внимание на вопрос, возникающий у множества начинающих специалистов в области системной инженерии и администрирования, когда они горят желанием использовать десктопное железо для серверных задач — почему нет, ведь оно дешевле?. Я тоже таким вопросом задавался, пока не углубился в компьютерную инженерию, а именно, не начал изучать тему Конструирование высокоскоростных цифровых устройств (она не входит в курс учебной программы по моей специальности). Как пишут авторы в своей книге, описывая работу логических элементов на высоких частотах, — элементам присуща метастабильность [5]. В книге предлагается пример предварительного расчета времени возникновения ошибки переключения триггера из одного состояния в другое. Так, в книге представлен пример расчетов возникновения ошибки и сделан вывод:

При тактовой частоте синхронизации, равной 35 МГц, вероятность сбоя составит 4х10^12. Если логический уровень сигнала на входе схемы меняется 3,5 миллиона раз в секунду, то отказ будет происходить один раз за 19 часов (примерно раз в день).

Хочу отметить, что при проектировании компьютерного железа таких тонкостей на практике наблюдается гораздо больше, и, при проектировании серверного железа, им уделяется больше внимания. На опыте эксплуатации серверов второго суперкомпьютера ДонНТУ (ВККС), построенного на десктопном железе и видеокартах, данный факт подтвердился.

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

Рассмотрение программной отказоустойчивости я бы хотел начать с примера ее организации на базе циклического обслуживания клиентов. Циклическое обслуживание предусматривает поочередную обработку запросов всеми серверами по очереди. Это удобный метод, если транзакции независимы и длительность одной транзакции не велика. В случае выхода из строя одного из серверов, запрос будет повторно направлен на новый сервер и он выполнит обработку. Данный метод так же отлично подходит для наращивания производительности. Когда один сервер не справляется, вы можете добавить сколько угодно серверов и разделить нагрузку между ними. Такой метод так же называют Горизонтальным масштабированием. Различают также и Вертикальное масштабирование, оно заключается в наращивании ресурсов одного сервера (расширение памяти, замене ЦП на более быстрый…).

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

Хочу заметить, что на примере удаленных рабочих столов такой транзакцией является сеанс. Начало транзакции — начало сеанса, конец транзакции — конец сеанса. Протеканию транзакции соответствует ряд операций, которые пользователь выполняет в течение сеанса, следовательно, если происходит отказ сервера во время работы — транзакция обрывается, и, соответственно, все несохраненные пользователем данные теряются. Таким образом, подключение на следующий сервер не является отработкой аварийной ситуации, а является лишь ее локализацией.

Построение РЕСУРС

Понимая, что предотвратить сбой в программном обеспечении для нашей задачи скорее не возможно, было решено использовать горизонтальное масштабирование. Для начальных экспериментов руководством было выделено несколько серверов суперкомпьютера Neclus. Данные серверы не обладали особой производительностью, но их плюс был в том, что их много и они идентичны. Было решено использовать в качестве ОС Windows Server 2008, 32 битную редакцию, к слову, последнюю 32-битную редакцию в своем роде, т.к. 2008 R2 уже работали только на 64 бита. Нужно отметить, что данная редакция основана на ядре Windows Vista — первые эксперименты Майкрософт с новым ядром, и в целом, после SP2 с ней кое как уже можно было работать. Из плюсов, она занимала в оперативной памяти всего-то около 512 МБ на холостом ходу, на серверах было установлено по 3 ГБ. Эмпирически было установлено, что на одном сервере может работать около 7 человек одновременно.

Замечу, что для развертывания служб удаленных рабочих столов требовалось развернуть Active Directory. Это удобно в том плане, что не требуется создавать пользователей по несколько раз на каждом сервере. К тому же, это позволяет грамотно управлять правами и параметрами, определять политики домена.

Решено было отказаться от стандартных средств распределения клиентов по серверам и использовать стороннее решение. Так мне приглянулся HAproxy (High Available proxy) — это балансировщик сетевой нагрузки 4 уровня (модели OSI), т.е. балансировщик TCP сессий. Существуют специальные аппаратные балансировщики, где данный пакет является частью прошивки устройства и использует аппаратную таблицу распределения сессий, что работает более надежно и быстро. У меня в распоряжении были лишь исходники HAproxy, и он был мной собран под Windows.

Было организовано 2 сервера, которые с помощью NLB (кластер балансировки сетевой нагрузки Windows) обслуживают 1 IP-адрес, на котором висит HAproxy. Он по нескольким признакам формирует таблицу распределения клиентов. Она является общей для обоих серверов. В результате, настройка сделана так, что отказ одного балансировщика оказывается прозрачным для работы клиентов, атказ рабочего сервера приводит к перераспределению клиентов по свободным серверам, по истечении небольшого таймаута. Эта часть отказоустойчивости реализована так.

Реализация независимой работы заключается в разграничение прав пользователей, с обеспечением их доступа только в пределах их профиля. Стоит отметить возможность равномерного распределения ресурсов среди пользователей с помощь Диспетчера системных ресурсов. Хочу заметить, что из некоторых соображений, начиная с версии Windows Server 2012 R2 это средство отсутствует, соответственно, со всеми вытекающими из этого последствиями — один пользователь может вызывать зависание всего сервера.

В РЕСУРС работа с сеансами пользователей построена таким образом, что при каждом подключении пользователя сервер забирает переносимый профиль пользователя из общего хранилища и по выходу пользователя сохраняет изменения. Так, не зависимо от того, на каком сервере работал пользователь в прошлый раз, в нынешний у него будет тоже самое окружение.

Важной частью РЕСУРС является клиент-серверная система виртуальных приложений — AppV, она обеспечивает работу множества приложений в изолированной среде. Так, запуск приложения одним пользователем не вызовет проблем у другого. AppV работает следующим образом: клиент, установленный на сервере удаленных рабочих столов, подключается к серверу и получает в оперативную память необходимый пакет, вернее, минимум, необходимый для запуска приложения, обеспечивая при этом изолированную среду выполнения приложения. Серверы AppV обслуживают клиентов в отказоустойчивом режиме, используется NLB, тот же принцип что и для HAproxy. Но для их работы требуется отказоустойчивый сервер MS SQL, его экземпляр развернут на базе двух серверов, с помощью Отказоустойчивых кластеров Windows.

РЕСУРС позволяет наращивать количество серверов в автоматизированном режиме, для чего системному администратору достаточно просто загрузить сервер по сети, по PXE. Он получит загрузчик и начнет установку специально-подготовленного образа Windows Server, приблизительно через пару часов сервер войдет в работу, и, изменив конфигурацию HAproxу, если этого не было сделано ранее, администратор сможет добавить сервер к системе.

Новым витком в развитии РЕСУРС стало добавление удаленных графических приложений, за счет задействования дополнительного оборудования — серверов ВККС. Был собран еще один Пул серверов удаленных рабочих столов и использована функция удаленных приложений. Они добавлены в систему. Так, появилась возможность на рабочем месте, где стоит терминал с частотой процессора в 100 МГц и с 16 МБ оперативной памяти запускать современные пакеты, требующие для работы аппаратное ускорение 3D графики.

Хочу заметить, что администрирование такого IT решения требует тщательного изучения журналов событий, анализа производительности, своевременного получения информации о сбоях и своевременного их устранения. Для этого развернут ряд серверов и служб, таких как System Center 2012, NEC ESMPRO и Zabbix.

Личный опыт

Во время построения системы всплыло очень много подводных камней.

Так, например, распределять клиентов сначала было решено стандартными средствами служб терминалов. В соответствии с руководством от Майкрософт для этого специально существует некий Посредник сеансов служб терминалов, который позволяет собрать серверы в Ферму (правильно это называется Пул, но, Ферма — это термин из документации Майкрософт). Клиент должен уметь работать при наличии посредника, это вызвано тем, что после подключения к любому из серверов происходит передача информации RDP клиенту о рабочем сервере. По идее, получается, что информацию о сеансе хранит посредник, и каждый сервер ведет своего клиента на основе этой информации. Все бы хорошо (почти), да было замечено, что в случае пропадания одного из серверов, клиентов никто из остальных серверов не подхватывал, вместо этого им сообщался адрес пропавшего сервера, и новый сеанс не начинался до появления сервера в строю.

Поучительно было столкнуться с проблемой восстановления контроллера домена из резервной копии. Дело в том, что каждый сервер Active Directory хранит номер последней записи, и в случае несоответствия репликация останавливается. Это является защитным механизмом. Интересно было столкнуться с тем, что такой механизм не сработал и прошла репликация, это привело к тому, что в базе случилась каша. Контроллеры были восстановлены в паре.

За время эксплуатации серверов Active Directory я пришел к выводу, что стоит стремиться к использованию одного, но надежного сервера. Не стоит на него вообще ничего лишнего устанавливать. Надо хранить ему питание и беречь его RAID. Главное вовремя мониторить все его показатели, журналы, и следить за состоянием записей в BMC. В свою очередь, за счет наличия дублирующих серверов Active Directory, мы неоднократно имели возможность продолжать работу и спокойно чинить вышедший из строя контроллер. Но эксплуатация двух и более серверов нам стоила головной боли с их репликацией.

Отказоустойчивые кластеры Windows весьма капризная вещь, они не умеют сами себя чинить и восстанавливать если что-то идет не так. За ними нужно активное наблюдение. Так, мне до сих пор не понятно почему возникают ситуации, когда инициатор iscsi не всегда восстанавливает соединение к диску, это нужно делать вручную. Как и службы, они не всегда восстанавливаются в работу самостоятельно, иногда нужно зайти запустить службу. Не смотря на определённые правила перезапуска служб.

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

Опыт внедрения такой инновации в ДонНТУ показал, что для начала работы пользователей в новой среде требуется проводить консультации по работе в многопользовательской среде. Это особенно касается простых пользователей, не имеющих продвинутого уровня. Можно заметить, что даже пользователи Windows, работающие дома так же в среде Windows, теряются при работе на другом компьютере.

Важным этапом обучения пользователей является научить их грамотно сообщать о сбоях. В реалиях ДонНТУ это делается проще чем где-либо потому, что в каждой аудитории с тонкими клиентами есть оператор. По сравнению с другими компьютерными аудиториями, тут существует особенность, если придет инженер на место, то сделать он почти ничего не сможет, при этом, у администратора есть возможность подключиться к сеансу удаленно и вместе с пользователем решить проблему.

Большинство наших тонких клиентов не имеют возможности подключения USB-накопителей, это связано с тем что в 90-х годах такие устройства не особо то были распространены и интерфейсы USB почти у всех ПК тех времен отсутствуют. В свою очередь, РЕСУРС имеет подключение к Интернет на скорости более 200 Мбит. Это дает удобную возможность использовать облачные хранилища. Однако, как показывает практика, далеко не все пользователи, имеют доступ к Интернет. Это в основном пользователи, для которых компьютерные дисциплины не являются профильными. Нужно еще учитывать и тот факт, что множество пользователей в учебной среде лишь учится работать с компьютером, отсюда — не умение работать с облаками. Отсутствие возможности в подключении съемных носителей все еще оказывается проблемой.

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

За время работы в ДонНТУ я получил колоссальный опыт в системной инженерии, в системном администрировании. И это не было следствием необходимости интенсивно постоянно в чем-то сложном ковыряться. Это было следствием моего желания искать разные способы решения задач. Я определил для себя правило — искать способы и идти к цели, просто потому что это эффективно.

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

Даты

  • В сентябре 2014 г. РЕСУРС введена в учебный процесс [1].
  • В ноябре 2015 г. РЕСУРС представлена как инновация [1].
  • С сентября 2015 г. по нынешнее время РЕСУРС развивается.
  • В 2016 году ВЦ становится частью Центра информационных компьютерных технологий (ЦИКТ).
  • В августе 2017 г. мной принимается решение о поступлении в магистратуру ДонНТУ, на момент моего ухода с системой одновременно работают 144 терминала + личные учетные записи.
  • В сентябре 2017 г. РЕСУРС переходит под контроль Отдела телекоммуникационных систем и сетей ЦИКТ.

Эксперимент

На следующем видео я бы хотел продемонстрировать результаты нашего эксперимента по организации рабочих мест с Windows 10 (вернее, Windows Server 2016) с использованием наших терминалов (ЦП: 100 МГц, ОЗУ: 16 МБ). На момент написания данной статьи внедрение Windows Server 2016 в инфраструктуру РЕСУРС не выполнено. Эксперимент проведен для анализа работы терминала.

Обзор аналогичных разделов

Мною были проанализированы аналогичные разделы выпускников магистратуры предыдущих лет. Ниже я привел список наиболее интересных работ:

  1. Концепция библиотечно-информационного центра ДонНТУ (Воропаева А.А.)
  2. Современный взгляд на системы с терминальным доступом (Репрынцев А.А.)

Список источников

  1. Отдел технического обслуживания компьютерной техники / ЦИКТ спешит на помощь // Донецкий политехник. — 2017. — № 12. — с. 6-7. https://docplayer.ru/71113136-Uspeshnaya-zashchita-dissertaciy-v-donntu-v-doneckom-nacionalnom-12-2356-noyabr-2017-g-vyhodit-s-aprelya-1922-g.html
  2. WTware [Электронный ресурс]. — Режим доступа: http://wtware.ru/
  3. DreamSpark теперь и по студенческим билетам [Электронный ресурс]. — Режим доступа: https://habr.com/post/45619/
  4. ThinStation — A framework for making thin and light Linux based images for x86 based PC's, thin clients, kiosks, and maybe even your own Cloud VDI. [Электронный ресурс]. — Режим доступа: https://thinstation.github.io/thinstation/
  5. Джонсон, Говард В., Грэхем, Мартин. Конструирование высокоскоростных цифровых устройств: начальный курс черной магии. : Пер. с англ. — М. : Издательский дом “Вильямс”, 2006. — 624 с. : ил. — Парал. тит. англ. ISBN 5-8459-0807-8 (рус.) c. 195-197

Полезные ссылки

  1. Терминальный сервер
  2. Пошаговая наглядная инструкция (как настроить терминальный сервер в облаке)
  3. Терминальный сервер
  4. Сервер терминалов на Windows 10
  5. FAQ: RDP и сервер терминалов
  6. Сервер терминалов
  7. Роль сервера терминалов
  8. Сервер терминалов для 1С по протоколу RDP на linux: рекомендации по настройке с учетом опыта реальной эксплуатации
  9. Установка сервера терминалов в Windows Server 2012 R2
  10. Ошибки терминального сервера
  11. Терминальный сервер (сервер терминалов), преимущества использования
  12. Записки IT специалиста Технический блог специалистов ООО"Интерфейс" &mdash Windows Server. Настройка сервера терминалов
  13. Тонкий клиент
  14. Тонкий клиент — что это и с чем его едят (на примере WTWare)
  15. Построение отказоустойчивой (fault tolerant) системы
  16. Отказоустойчивые ИТ-системы: принципы построения
  17. Отказоустойчивость сайтов и веб-приложений
  18. Отказоустойчивые решения
  19. Отказоустойчивые сети