Особенности реализации терминальных систем на основе архитектуры среды ОС Windows

Отметим, что удаленный доступ к приложениям с помощью средств Windows не предполагает применения отличных от Windows платформ в качестве серверов, а выбор клиентских платформ в этом случае весьма ограничен. При необходимости использования для терминального доступа платформ, отличных от перечисленных, применяются продукты независимых производителей. Ниже мы рассмотрим наиболее популярный продукт этого класса — Citrix MetaFrame Presentation Server.

Особенности реализации терминальных систем на основе архитектуры среды ОС Linux.

В зависимости от ситуации администратор может выбрать различные способы организации терминального доступа к серверу. В качестве протокола подключения могут быть использованы XDMCP, VNC, RDP, NX или какие-то другие протоколы. Каждый из них имеет свои преимущества, свою историю развития и своих сторонников. Мы из всего этого многообразия вариантов будем рассматривать именно NX.

Чем же так хорош NX? Он обеспечивает комфортную работу на терминальном сервере, при этом не предъявляя высоких требований ни к скорости сетевого соединения, ни к его стабильности. NX удобен для подключения удалённых пользователей: сотрудников, работающих из дома, и целых филиалов, находящихся в других точках города или регионах. Решения на базе NX позволяют использовать на сервере локальные пользовательские принтеры, подключать дисковые ресурсы. Клиентские приложения существуют для разных операционных систем, поэтому не важно, Linux или Windows стоит на компьютере пользователя. Очень удобным оказывается режим одного приложения, где терминальный сеанс используется для запуска конкретной программы (например, 1С:Предприятие), в этом случае программа выглядит так, как будто она запущена локально на компьютере пользователя.

Изначально технология NX была представлена продуктами NX NoMachine — это проект итальянской компании Medialogic S.p.A. Коммерческие версии NX NoMachine ориентированы на корпоративных клиентов, а их стоимость составляет от 700$ до 3500$. Существует свободная версия, известная под названием FreeNX. Именно её чаще всего берут за основу решений, организовывая терминальный Linux-сервер.

Сервер FreeNX входит в состав многих дистрибутивов Linux. Для каких-то задач хватает простой его установки, когда-то приходится настраивать и дорабатывать функционал под свои задачи. Следствием проводимых доработок является регулярное появление патченных версий freenx-server и создание собственных проектов, имеющих в своей основе FreeNX. Одним из таких проектов стал проект компании Etersoft — RX@Etersoft.

RX@Etersoft является решением, основанном на FreeNX. Существовав на  первом этапе развития в виде  патченного freenx-server, со временем  проект преобразован в отдельный  продукт, позиционирующийся как самостоятельное решение на базе NX. В числе главных отличий RX от FreeNX можно назвать уверенную работу с локальными принтерами и папками, корректную работу кодировок и удобный rootless-режим (режим одного приложения).

RX@Etersoft распространяется  под лицензией GPL, как и его предок, что позволяет получить и использовать решение бесплатно. Наряду с бесплатным продуктом есть и его коммерческая версия — тот же самый RX, только с предоставлением сборок под множество систем и правом воспользоваться технической поддержкой.

Что касается клиентских приложений, то они являются общими и для RX@Etersoft, и для FreeNX, и для коммерческой NX NoMachine. Как правило, клиентские программы пишутся кроссплатформенными, что даёт возможность использовать одного и того же клиента в разных операционных системах.

NXClient. Продукт компании NoMachine, является самым популярным для  организации подключения к NX-серверу. Обладает богатыми настройками  и высокой надёжностью. Есть сборки  под Windows и Linux. Главным недостатком  этого клиента является отсутствие развития и закрытость кода программы — в случае возникновения ошибок, обходить их приходится разными, не всегда логичными методами.

OpenNX. NX клиент с открытым  кодом, написан на C++ с использованием wxWidgets. Существуют сборки под Linux, Windows и MAC OS. Открытость кода даёт проекту стремительно развиваться, и за последние несколько лет перспективный клиент превратился в одну из самых используемых программ для подключения к NX-серверам.

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

Есть и другие проекты, но они пока не могут конкурировать с OpenNX и NXClient.

Классическое терминальное решение с удаленной загрузкой – это набор нескольких стандартных для Linux (и для любой Unix-подобной операционной системы) сервисов: dhcp, tftp, nfs, X-сервера и xfs-сервера (как правило, использование сервера шрифтов является опциональным, и от него можно отказаться, предоставив доступ к шрифтам через NFS). Рассмотрим в общих чертах алгоритм загрузки бездисковой станции на примере LTSP (Linux Terminal Server Project, ltsp.org), как известнейшего и крупнейшего проекта данного класса среди ореn source. Условно его можно разделить на три этапа: загрузка ядра, инициализация и запуск.

Загрузка ядра выполняется с помощью кода, описываемого спецификацией удаленной загрузки Etherboot, за которую отвечает одноименный проект ореn source (etherboot.org). Готовые прошивки имеются для огромного числа сетевых карт, при этом обеспечивается обратная совместимость с протоколом PXE, т. е. через сетевую карту с установленным PXE bootprom можно загружать сетевые образы, созданные для спецификации Etherboot. Существует несколько способов запустить подобный код: с внешних носителей (дискета, жесткий диск, CD-ROM), с помощью микросхемы удаленной загрузки (bootprom) или уже упомянутого протокола PXE.

В любом случае управление в конце концов передается Etherboot-коду. Он, в свою очередь, посылает в сеть широковещательный запрос, предназначенный для dhcp-сервера и содержащий MAC-адрес сетевой карты. Используя последний, dhcp-сервер ищет в собственном конфигурационном файле соответствующие данные и возвращает пакет с информацией о параметрах настройки сетевого соединения, с путями к образу ядра и к сетевой файловой системе, которая, если нужно, будет использоваться в качестве корневой, и специальные параметры загрузки ядра (например, IRQ для сетевых карт, работающих на ISA-шине, номер порта и т. п.).

После получения параметров, необходимых для настройки сетевого подключения, Etherboot-код устанавливает соединение с tftp-сервером, получает образ ядра ОС, загружает его в оперативную память и передает ему управление.

Инициализация. Особенность загружаемого ядра – поддержка работы с NFS, которая не реализована в виде отдельного модуля, а встраивается непосредственно в ядро на этапе компиляции, более того, изначально сетевая файловая система является корневой. Детали процесса загрузки мы опустим, укажем лишь, что поначалу используется небольшой образ файловой системы, который загружается вместе с ядром (именно так!), а затем, после инициализации оборудования (и повторной настройки сетевых параметров), происходит пере монтирование, и в дальнейшем в качестве корневой применяется уже экспортируемая файловая система. Плюс к тому (и это важно) создается RAM-диск, который форматируется и монтируется к каталогу /tmp, где и хранятся файлы, которые будут создаваться в процессе работы бездисковой станции. Если же их необходимо хранить в другом месте, предварительно создаются соответствующие символические ссылки.

Запуск. После окончания инициализации оборудования загружается среда, указанная в настройках LTSP. Это может быть либо графическая, либо текстовая оболочка, последняя чаще всего используется при отладке. Графическая подсистема запускается с ключом query – эта опция заставляет экземпляр X-сервера, выполняющийся на бездисковой станции, подключаться к X-серверу на терминальном сервере и все запросы переадресовывать ему.

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

Хотя терминальные решения можно оценивать и с точки зрения функциональности, в случае open source стоит в первую очередь уделить внимание более узкому, но очень принципиальному моменту – эффективности использования оперативной памяти, в том числе и с точки зрения ее «утечек». Эта традиционная для многих типов ПО ошибка может привести к быстрому исчерпанию свободного объема ОЗУ, и решить данную проблему поможет лишь перезагрузка или своевременное отключение процесса-виновника. Для системного мониторинга вполне подойдут простейшие системные утилиты top или ps, однако гораздо эффективнее будет установка системных лимитов для пользователей и процессов.

В случае перехода на терминальную систему, особенно совмещенную с миграцией с Windows на Linux, главная проблема – найти адекватную замену тому ПО, которое использовалось прежде. Для типичной офисной работы отыскать все необходимое (текстовый процессор, электронная таблица, браузер и пр.) сегодня не составляет труда. Наиболее частая причина невозможности смены платформы – деловое ПО «1С», однако и эта проблема в настоящее время решаема. Так, российская компания «Этерсофт» разработала специальную «заплатку» для эмулятора WINE – к сожалению, не бесплатную, – которая позволяет использовать «1С:Предприятие 7.7» в среде Linux.