Подписаться
Читать в телеграм
Если задуматься, процесс вполне естественный: системы становятся все сложнее, происходит укрупнение их элементов, концентрация ресурсов. Только в таком случае можно ожидать достижения управляемости системы, ее надежного и эффективного функционирования (вспомним известное наблюдение о 7 объектах, которые человек способен удерживать одновременно в сфере своего внимания). Такой путь прошли электрические сети, телефонные сети. Еще раньше водопровод заменил индивидуальные колодцы. Зачем иметь собственный дизель-генератор, если в доме есть электрическая розетка? Даже Интернет максимально, казалось бы, распределенная система, тяготеет к централизации: укрупнение провайдеров, организация
порталов.
Интересно, что еще два-три года назад не было такого интереса к данным решениям, хотя они, разумеется, существовали и использовались (например, в информационной системе компании «Инфосистемы Джет» X-терминалы и централизованные серверы используются с 1993 года). Администраторы сетей, конечно, были не против, но законные опасения вызывала реакция пользователей на то, что при переходе к централизованным решениям они будут существенно урезаны в правах. Сейчас видно, что и пользователи уже устали бороться с компьютером, они уже готовы пожертвовать частью своей свободы ради того, чтобы кто-то избавил их от этой головной боли. («Больше свободы – больше ответственности» – эта истина справедлива и здесь.)
Для наглядности – пара примеров.
Представим себе типовую информационную систему небольшого предприятия: прикладное ПО, написанное на Delphi, взаимодействующее с сервером баз данных Oracle, клиентские места на Windows 98, 20-30 рабочих мест. Знакомо? Все работает, интерфейс современный, технологии «клиент/сервер» – передний край.
Проблем не видно. Даже если они и возникают разработчики и администраторы под рукой, все могут быстро поправить. Рабочие места достаточно мощные, чтобы держать нагрузку, приложений немного – буквально 4-5, хранятся централизованно на файловом сервере.
Теперь попробуем промасштабировать систему. Хотя бы на порядок: 300-500 рабочих мест. Несколько зданий, десятки приложений, сотни гигабайт информации. Два десятка файловых серверов, разбросанных по отделам, несколько почтовых серверов, с трудом взаимодействующих друг с другом. Четыре версии MS Word, две версии Novell Netware и три версии Windows, не считая тех «Beta-pre3Build-5467», которые пользователи установили самостоятельно. Теперь представьте: Вы отвечаете за то, чтобы все это работало. Неуютно, не правда ли?
И в том, и в другом случае – самые современные технологии «клиент/сервер», квалифицированные специалисты, большое желание добиться надежного функционирования всей системы. В чем разница Просто-напросто в масштабах.
На лицо хрестоматийный переход количества в качество: системы крупного масштаба должны управляться принципиально по-другому, на первый план выходят организационные, архитектурные, а не технологические проблемы. Спасает только наведение порядка, сведение системы к крупным блокам, максимальная унификация и строгая дисциплина для типовых элементов (рабочих мест, хабов, принтеров и т.п.).
Серверной части таких решений была посвящена статья «Настоящий Вычислительный Центр» (JI 12-1999). В этой статье мы рассмотрим решения для клиентских рабочих мест. Здесь есть, что обсудить.
2. Тридцать три причины, почему клиенты должны быть тонкими
Вы знаете, Джим, в последнее время я стал замечать, что голые клиенты гораздо сговорчивее. Из «Откровений суперсервера» Клиентских рабочих мест во много раз больше, чем других (серверных и инфраструктурных) компонентов корпоративных информационных систем. Поэтому каждый лишний рубль (или, если быть реалистом, доллар), затраченный на одного клиента, в масштабах большой компании оборачивается сотнями и тысячами у.е. Вот почему важно точно представлять себе, во что каждый клиент обходится, причем не только в момент приобретения аппаратуры и программ, но и на протяжении всего жизненного цикла. Данная величина называется полной стоимостью владения (Total Cost of Ownership,TCO).
Типичное разбиение полной стоимости владения клиентским рабочим местом по статьям расходов представлено на рис. 1. Видно, что начальные затраты составляют относительно небольшую долю. Главное – повседневное администрирование, происходящее изо дня в день, из года в год, выполняемое штатным системным администратором. Можно спорить о младших цифрах, упирать на национальные особенности, но общая картина во всех странах выглядит сходным образом.
Разные источники называют разные значения для полной стоимости владения традиционным персональным компьютером, но среднее значение близко к десяти тысячам долларов в год из расчета пятилетнего срока эксплуатации. Это более чем заметная величина, которую, напомним, нужно умножить на число клиентских рабочих мест, после чего становится абсолютно непонятным, как же все это еще удается содержать...
Итак, первый побудительный мотив для борьбы с толщиной клиентов – стремление уменьшить полную стоимость владения информационной системой. Мотив экономический, а не научно-технический, понятный руководителям и бухгалтерам, не связанный с абстрактными достоинствами Web, Java или еще какой-нибудь технологии. Мотив, весомость которого каждая организация может примерить на себя самостоятельно, если аккуратно подсчитает произведенные расходы. Даже если в год получится не десять, а две-три тысячи, это все равно будет много по сравнению со стоимостью оборудования.
Существенного уменьшения полной стоимости владения можно достичь только путем резкого снижения расходов на администрирование (поскольку бороться нужно с основной статьей расходов, а не с второстепенными). Здесь возможны технические меры двух видов:
- упрощение администрирования рабочих мест при сохранении достаточной функциональности;
- внедрение централизованных систем администрирования распределенных конфигураций, максимальная автоматизация рутинных действий.
Конечно, инструменты администрирования нужно развивать, активнее внедрять их в корпоративные системы, но реальность такова, что пока на этом пути решающей победы достичь не удалось (см., например, [3 JI-99-3]). Приходится идти на (само)ограничения, урезая возможности конфигурирования на рабочих местах, делая клиентов тонкими, почти не нуждающимися в администрировании и, следовательно, допускающими экономичную эксплуатацию.
Важной составной частью администрирования корпоративной информационной системы является распространение нового или модернизация существующего программного обеспечения. В последнее время в этой области достигнут заметный прогресс, но от возможных конфликтов в настройках такой сложной сущности, как персональный компьютер, полностью избавиться пока не удалось. Тонкий клиент не хранит у себя ничего – ни данных, ни прикладного ПО, поэтому, например, смена версий используемых приложений может быть выполнена весьма быстро, в течение минут, просто путем изменения соответствующих файлов на сервере. (Правда, остается необходимость обучения пользователей новым возможностям.)
Особенно актуально встает проблема быстрого обновления ПО на клиентских рабочих местах, когда требуется не введение новых возможностей, а устранение ошибок в программах.
Такие моменты, как отсутствие данных, хранимых на рабочих местах пользователей, невозможность (в силу отсутствия дисководов и модемов) унести конфиденциальные файлы или принести вредоносные программы, также существенно упрощают администрирование и уменьшают вероятность несанкционированного доступа. Все это положительным образом сказывается на всех аспектах информационной безопасности – доступности, целостности и конфиденциальности, хотя и не освобождает, например, от противодействия сетевым угрозам.
Надежность централизованного хранения данных, без сомнения, гораздо выше, чем надежность их хранения на персональных рабочих местах. И главной угрозой здесь, по-видимому, являются не аппаратные сбои дисков, а сами пользователи, совершенно недисциплинированно относящиеся к своим рабочим местам. Строго говоря, данные, с которыми работает пользователь на своем рабочем месте, принадлежат компании, следовательно, и заботиться об ихсохранности должна компания. Доверять эту задачу пользователю – слишком рискованно.
Известна компания, которая внедрила у себя технологию тонких клиентов на базе обычных ПК: все данные и конфигурации хранятся централизованно. Для того, чтобы отучить пользователей что-либо хранить на жестких дисках своих компьютеров, администраторы ввели политику, согласно которой каждую ночь происходит полная очистка всех жестких дисков ПК. Оказалось весьма действенно.
Тонкий клиент, без дисков, вентиляторов, вообще без движущейся механики, может быть более эргономичным и надежным, чем ПК. Правда, данные показатели у современных персональных компьютеров весьма высоки, и страдают они (ПК), в первую очередь, не столько от аппаратного, сколько от «программного» старения – новое программное обеспечение не работает на компьютерах, возраст которых больше, чем два-три года. У тонких клиентов меньше компонентов, подвергающихся такому старению, многие характеристики у них определяются не технологией, а человеческой физиологией и психологией (напомним: основная функция у тонких клиентов – интерфейсная). По этой причине тонкие клиенты могут служить дольше, не вызывая отторжения.
В компании «Инфосистемы Джет» до сих пор находятся в эксплуатации на рабочих местах Хтерминалы, приобретенные в 1993 году (на базе процессора Intel 960, 16 МГц) и нельзя сказать, чтобы их пользователи чем-то отличались от других, у которых терминалы более продвинутые, на процессоре с частотой 25 МГц. По стоимости они не отличались от ПК в момент закупки, но где теперь те ПК, купленные в 1993 году? А Х-терминалы – стоят, работают. Жизненный цикл оказался заметно длиннее (и еще далек от завершения).
Справедливости ради отметим, что и у персональных компьютеров при правильной организации жизненный цикл может быть долгим. Постепенное перемещение техники от самых требовательных пользователей к их более «терпимым» коллегам позволяет продлить век компьютеров, обеспечивая в то же время наращивание ресурсов у пользователей.
Следует помнить и о законе сохранения функций. Если мы перемещаем (не устраняя полностью) что-то с пользовательского рабочего места, это «что-то» должно осесть на серверах, создавая дополнительную нагрузку на их аппаратуру и усложняя их администрирование. Если серверы способны выдержать такие нагрузки без заметного снижения производительности, то никаких проблем не возникает. Если же мощности серверов не хватает, если постоянно перегружается сеть, зачастую идут на компромисс, «утолщая» клиентов и передавая им соответствующие функции.
Разумнее, однако, двигаться в сторону повышения производительности сервера – это позволяет более эффективно использовать ресурсы за счет многопользовательской эксплуатации. Действительно, можно утверждать, что 95% времени персональный компьютер используется на 5%, имея ярко выраженный пиковый характер загрузки. Если встает вопрос повышения производительности, то гораздо эффективнее увеличить ресурсы сервера на 50% вместо наращивания ресурсов 50-ти клиентов по 20% на каждого.
Рекомендации компании Citrix (http://www.citrix.com), производящей ПО для многопользовательских серверов Windows, говорят о том, что для работы 50 клиентов, использующих Microsoft Office, достаточно сервера с процессором на 500 МГц и 256 МБ оперативной памяти. При этом клиентами могут быть компьютеры на базе процессора i386 с 4 МБ оперативной памяти.
Вернемся к ключевому термину данного раздела: «полная стоимость владения». Именно по этому показателю тонкие клиенты имеют бесспорное преимущество. Важные следствия в виде безопасности данных, быстроты и экономичности развертывания новых рабочих мест служат весомыми дополнительными аргументами в пользу тонких клиентов.
Каково числовое выражение «бесспорного преимущества» тонких клиентов? Согласно данным Gartner Group, приведенным в [4 IBM Tctcfassaf], полная стоимость владения тонкими клиентами примерно на 25%-30% меньше, чем у персональных компьютеров, объединенных в локальную сеть. Две-три тысячи долларов в год на одно рабочее место – это весьма заметная экономия.
На рис. 2 приведены сравнительные данные корпорации IBM, также взятые из [4], содержащие разбиение полной стоимости владения по основным статьям расходов для сетевых ПК и тонких клиентов. Суммарная экономия составляет те же 25%. Видно, что основная экономия достигается за счет разгрузки пользователей (у них оказывается существенно меньше «рычагов», за которые можно дергать) и за счет снижения издержек на техническую поддержку.
3. Ранжирование клиентов по толщине
Голые клиенты, конечно, сговорчивее. Но что с них возьмешь? Из «Откровений суперсервера» Историческими предшественниками современных тонких клиентов были алфавитно-цифровые терминалы. Они подключались к компьютерам через специализированные интерфейсы или через универсальные последовательные порты. Терминалы корпорации IBM, такие как IBM 3270, обладали довольно высоким интеллектом, поддерживали локальное редактирование содержимого экрана. Другие терминалы также обладали собственной системой команд (хотя и более простой, чем у IBM), умели позиционировать курсор, оперировать со строками и т.п. На серверной стороне терминалы могли подключаться непосредственно в нужный компьютер, в терминальный концентратор или во фронтальную машину, являвшуюся прослойкой между пользователями и «большими машинами».
Несмотря на относительную простоту функций, выполнявшихся алфавитно-цифровыми терминалами, их система команд не была стандартизована. Конечно, существовали фактические стандарты (обычно в этом качестве называют терминалы семейства vt), но и самостоятельных «веточек» было немало. Некоторые терминалы умели эмулировать несколько систем команд, то есть в одном физическом терминале как бы содержалось несколько логических, но всех проблем это, разумеется, не решало. Существовал и фактический стандарт программного интерфейса к терминалам – библиотека curses в ОС Unix, однако, многие авторы экранных редакторов считали, что работы через нее замедляет редактор и предпочитали взаимодействовать с терминалами напрямую. В результате подобные редакторы оказывались немобильными не только по отношению к смене компьютерной платформы, но и по отношению к замене терминалов.
Отдельную проблему для алфавитно-цифровых терминалов составляла поддержка русских символов при вводе и выводе. В частности, если терминалы были достаточно интеллектуальными и поддерживали загрузку шрифтов, требовалось эти шрифты разработать, поскольку у каждой модели терминалов формат загружаемых символов был свой. Если в организации эксплуатировались разные терминалы, то управление шрифтами (для терминалов и принтеров) выливалось в отдельную, довольно неприятную проблему. Создавало это проблемы и для пользователей. Если шрифты загружались в память, не являющуюся энергонезависимой, при случайном выключении терминала они пропадали, а оперативная загрузка шрифтов из файлов для большинства пользователей была непосильной задачей. Требовалась помощь технического персонала.
Таким образом, даже в случае такого сверхтонкого клиента, как алфавитно-цифровой терминал, существовали проблемы программирования, локализации, администрирования. Даже для терминала администрирование не являлось «нулевым».
Но самое главное – алфавитно-цифровой терминал как рабочее место «убил» графический интерфейс, который был основой современного прикладного ПО.
В наше время алфавитно-цифровые терминалы мало кого устроят. Пользователю нужна полноцветная графика, ввод с помощью не только клавиатуры, но и мыши. Да и требования поддержки аудио со стороны пользователей звучат все настойчивее.
Подключаться такой терминал должен к локальной сети, а не напрямую к компьютеру.
На рис. 3 представлено ранжирование клиентов по толщине.
Самый тонкий клиент умеет отображать на цветном экране растровое изображение и передавать на сервер ввод с клавиатуры и мыши. С вводом особых проблем нет (битву за локализацию можно считать успешно завершенной), а вот вывод сопряжен с определенными сложностями. Допустим, нужно поддерживать разрешение 1280 на 1024, 24 бита на пиксел. Образ одного экрана занимает при этом 30 Мбит (4 МБ).
Понятно, что нужно либо компрессировать растровое изображение, либо передавать не всю картинку, а только разность с предыдущим кадром (в более общем случае – использовать какой-либо стандарт передачи движущихся изображений).
Мы видим, что даже от самого тонкого клиента – цветного графического терминала – требуется интеллект (для компрессии/декомпрессии изображений), а также наличие высокоскоростного сетевого соединения. Очевидно, высокие требования к сети тонкого клиента оборачиваются проблемами для сервера, ограничивая реальное число обслуживаемых терминалов.
Если взглянуть на самого тонкого клиента с другой стороны (со стороны сервера приложений), то, конечно, должна быть видна не растровая картинка, а стандартная оконная система (стандартный компонент представления в трехуровневой архитектуре клиент/сервер). Такая оконная система может быть реализована только программно на сервере, к которому подключаются терминалы. Это создает значительную нагрузку на процессор и еще больше ограничивает число обслуживаемых терминалов.
Следующими в иерархии тонких клиентов идут устройства, способные поддерживать определенную оконную систему (например, X Window). В этом случае устройство должно обладать существенно большим интеллектом, чем «отображатели растра» (X-сервер – сложная программа), но зато объем передаваемой клиенту информации значительно снижается (поскольку обмен ведется в терминах более высокого уровня).
Поддержка определенной оконной системы снижает универсальность тонкого клиента, однако не так сильно, как может показаться на первый взгляд. При необходимости сервер может взять на себя роль эмулятора и обеспечить, например, доступ с Windows-терминалов (имеются в виду Microsoft Windows) к Unix-приложениям, ориентированным на X Window.
X-терминалы, ориентированные только на X Window, оказались в стороне от магистральной линии развития. Не случайно основные производители Х-терминалов (Wyse, Neoware) стали выпускать устройства, одинаково хорошо подходящие для работы и в Unix и в Windows-сетях. С другой стороны, появились и специализированные, так называемые Windows-Based терминалы (WBT), служащие для многопользовательской работы с серверами на платформе Windows NT.
На следующем уровне располагаются Javaстанции, сочетающие интерфейс на основе Интернет-навигатора с возможностью загрузки и выполнения Java-аплетов и самостоятельных Java-приложений. Здесь к функциям ввода/вывода добавляются возможности загрузки программ по сети и их локального (на клиенте) выполнения.
К сожалению, платформно-независимая основа (навигатор с виртуальной Java-машиной) не гарантирует возможность работы с произвольными HTTP-серверами и Java-приложениями (это знает каждый посетитель неординарно выполненных серверов). Причина – использование нестандартных возможностей протоколов, языков разметки или Java-окружения. В результате в окне навигатора в лучшем случае появляется диагностическое сообщение вида «объект не продекларирован» или «метод отсутствует». В худшем случае навигатор рушится. Конечно, в рамках корпоративной системы можно (и нужно) навести порядок, так что все приложения будут нормально работать на пользовательских Java-станциях, однако, при попытке обращения к внешним приложениям проблемы могут остаться.
Мысль о том, что клиентская сторона неразрывно связана с серверной, банальна. Концепция клиента произвольной толщины может быть реализована только при соответствующей серверной архитектуре. Однако, для Java-станций эта серверная архитектура оказывается особенно специфической, что, вообще говоря, может уменьшить выгоды от внедрения технологии тонких клиентов. Подробно этот вопрос рассматривался в Jet Info в статьях [2] и [5 JI-99-5-1].
Несколько лет назад казалось, что устройства с навигационным интерфейсом и поддержкой Java, по крайней мере, сравняются по массовости с терминалами для Windows. Пока этого не произошло. Корпоративные информационные системы весьма инерционны, так что зачастую главную цель их развития можно сформулировать в виде парадокса: «Пусть система станет дешевле и лучше, а в остальном все останется по-прежнему». Подобное желание вполне понятно. Предположим, что это возможно: массовые тонкие клиенты вырастут не из «немного других» компьютеров, а из потребительских устройств с сетевым доступом. Одно дело «урезать» клиентские компьютеры и утверждать, что без этих частей пользователю будет только лучше, и совсем другое – давать владельцам потребительских устройств новые возможности, контролируя при этом издержки на администрирование.
4. Графический терминал Sun Ray 1
Клиентов, конечно, надо любить. Только не всех сразу.
Из «Откровений суперсервера»
Чем тоньше клиент, тем чаще в его описании фигурирует сервер. Sun Ray 1 – наглядное тому подтверждение.
Sun Ray 1 является элементом архитектуры, которую компания Sun Microsystems назвала Sun Ray Hot Desk. Эта архитектура охватывает клиентскую и серверную стороны и взаимодействие между ними.
С аппаратной точки зрения терминал Sun Ray 1 представляет собой небольшой (180*50*180 мм) системный блок, в который встроено устройство считывания смарт-карт (в стандарте ISO-7816-1, для аутентификации пользователей). К системному блоку подключаются монитор, клавиатура, мышь, и, возможно, устройства аудио-ввода/вывода (то есть присутствует «джентльменский» мультимедийный набор). Имеются резервные USB-порты для подключения принтера и сканера. Для взаимодействия с сервером используются выделенные Ethernet-соединения на 10/100 Мбит/с.
Рекомендуемая схема подключения устройств Sun Ray 1 к серверу представлена на рис. 4. Разумеется, сервер входит в локальную сеть (и, тем самым, в некоторую область администрирования) и способен взаимодействовать с другими серверами (рис. 5).
Наибольший интерес в Sun Ray 1 представляет не аппаратная, а программная архитектура, так как именно она определяет возможности и показатели производительности терминала; на ней мы и сосредоточим внимание.
Основная идея тонкого клиента проста: на сервер выносится все, вплоть до уровня виртуальных драйверов устройств и, в частности, виртуального драйвера дисплея (рис. 6). На Sun Ray 1 функционируют лишь физические драйверы устройств и другое встроенное программное обеспечение (самотестирование при включении, коммуникации с сервером, аутентификация, управление для аудио и видео). Sun Ray обеспечивает работу с приложениями, написанными по X Window, MS Windows, Java и Web-интерфейс. На клиентское место по протоколу Hot Desk (детали которого, к сожалению, не раскрываются) поступает картинка, готовая к отображению на дисплее.
Подчеркнем, что Sun Ray 1 является устройством без состояния. На него не загружаются какие-либо программы или, например, шрифты, все это живет на сервере. Значит, в случае поломки один терминал можно заменить другим без потери транзакций и аналогичных неудобств. После подключения устройство оказывается готовым к работе через 10 секунд (это время прогрева монитора). С другой стороны, вероятность выхода Sun Ray 1 из строя крайне низка, поскольку в нем нет движущихся частей.
В Sun Ray 1 может быть реализована концепция вечного выполнения (см. рис. 7). Когда пользователь хочет начать работу и вставляет в устройство чтения свою смарт-карту (действие 1 на рисунке), Sun Ray 1 посылает на сервер менеджеру аутентификации номер этой карты (действие 2). В соответствии с выбранной политикой, этот менеджер проводит процедуру аутентификации и затем передает менеджеру сеансов идентификатор сеанса (действие 3), характеризующий пользователя (например, это может быть все тот же номер смарт-карты). Менеджер сеансов может открыть новый сеанс или возобновить старый (если были отложенные, действие 4). Наконец, когда пользователь вынимает смарт-карту из устройства чтения (действие 5), сеанс, в зависимости от выбранной политики, завершается или «замораживается» с возможностью последующего возобновления.
Если вернуться к «внешнему» взгляду на архитектуру Sun Ray Hot Desk, следует отметить, что реализация клиента в виде логического X-терминала позволяет организовать взаимодействие практически с любым приложением. Набор разного рода эмуляторов и клиентов для X Window чрезвычайно богат, так что речь может идти и о подключении к мэйнфреймам путем эмуляции терминала IBM 3270, и о доступе к приложениям для Microsoft Windows. На рис. 8. представлена схема подключения Sun Ray 1 к серверу Windows NT с помощью программного обеспечения компании Citrix Systems. Конечно, до NT приходится добираться «на перекладных», но для офисных приложений это не имеет большого значения.
Мы рассмотрели программную и аппаратную архитектуру Sun Ray, реализующую концепцию самого тонкого из возможных клиентов. Попытаемся оценить, насколько подход, избранный компанией Sun Microsystems, можно считать удачным и перспективным.
Во-первых, все больше и больше прикладных систем (западных и отечественных) начинают поддерживать Web-интерфейс. Вначале это было вызвано просто модой на интернет-коммерцию, потом пришло понимание его реальной пользы и удобства. Наличие Web-интерфейса означает, что пользователь не обязательно должен сидеть за компьютером с Windows, а может пользоваться Unix, Macintosh, Palm Pilot и другими платформами. И тогда пользователь может выбрать ту, которая ему более удобна.
Во-вторых, появилась альтернатива Microsoft Office – пакет StarOffice, который бесплатно раздает Sun Microsystems. Последняя его версия поддерживает русский язык (включая меню и подсказки) и способна обмениваться файлами с MS Office. Возможно, ему еще не хватает стабильности, но разве может похвастаться большой стабильностью MS Office? Практическим подтверждением жизнеспособности StarOffice служит то, что весь московский офис Sun Microsystems полностью перешел на StarOffice: документы, презентации, таблицы делаются отныне только в нем.
Наконец, похоже, что пользователи уже и сами хотят избавиться от повседневной головной боли, связанной с борьбой с компьютером. И эта психологическая проблема была главным препятствием на пути к тонким клиентам. Сейчас сдвиги налицо.
Перейдем к техническим вопросам. В материалах по Sun Ray указывается, что для поддержки одного пользователя на сервере требуется 10–20 МБ оперативной памяти. Эта оценка представляется правдоподобной. А вот способность одного процессора с тактовой частотой 300 МГц обеспечить одновременную работу 25–65 пользователей Sun Ray 1 сильно зависит от рода используемых приложений. Очевидно, что эти устройства разработаны для использования в основном в офисных приложениях, не требующих интенсивной графики, поэтому верхняя оценка справедлива именно для таких приложений. Платформа SPARC/Solaris известна своей уникальной масштабируемостью, способностью поддерживать десятки процессоров, гигабайты ОЗУ и терабайты долговременной памяти. Для особо требовательных пользователей в роли терминального концентратора может быть задействован сервер Ultra Enterprise 10000.
Судя по прессе, системы Sun Ray внедряются весьма активно, получают лестные отзывы, побеждают в конкурсах и т.п. Будет очень интересно последить за продвижением и эволюцией Sun Ray 1 – самых тонких графических клиентов.
5. Многопользовательский доступ к Microsoft Windows
Клиент клиенту рознь. Зато сервер серверу – друг, товарищ и брат. Из «Откровений суперсервера» В данном разделе будут рассмотрены устройства, получившие наименование Windows-Based Terminals (WBT). Как часто бывает с компьютерной терминологией, WBT-терминалы – «это не то, о чем Вы подумали». Их операционная платформа не имеет принципиального значения, это может быть Windows CE, а может быть и нечто совсем иное, например, ОС реального времени. Речь пойдет об устройствах, поддерживающих графический многопользовательский доступ к серверным операционным системам Microsoft Windows – Windows NT Server Terminal Server Edition (TSE) или Windows 2000. (Строго говоря, в этом контексте должен быть упомянут еще один продукт – MetaFrame компании Citrix Systems, но мы предпочитаем отложить его рассмотрение до следующего раздела.)
WBT-терминал играет роль окна в сервер, отображая результаты работы приложений и передавая пользовательский ввод. Все данные хранятся и все приложения функционируют на сервере (см. рис. 9), поэтому никаких сомнений в тонкости рассматриваемого клиента нет и быть не может. Более того, на сегодняшний день WBT-терминалы являются самым распространенным видом тонких клиентов, хотя, возможно, в перспективе положение изменится (см. рис. 10).
Возвращаясь к рис. 9, можно увидеть много общего в идеологии Sun Ray и WBT-терминалов. Общими являются и достоинства: минимальная общая стоимость владения, практически нулевое администрирование, высокая надежность, отсутствие необходимости в частых модернизациях и т.п. Основное различие состоит в том, где осуществляется работа с графикой. Архитектура Sun Ray Hot Desk оставляет эту функцию серверу, WBT-терминалы берут ее на себя.
Перераспределение графических функций способствует также уменьшению требований к полосе пропускания между сервером и графическим терминалом, так что в WBT-случае возможно подключение даже по асинхронным линиям. Для коммуникаций используются протоколы RDP (Remote Desktop (Display) Protocol) от Microsoft или ICA (Independent Computing Architecture) от Citrix. В результате становится возможным подключение терминалов, расположенных в удаленных офисах, к центральным серверам.
Впрочем, WBT-терминалам приходится заботиться о конкуренции не с Sun Ray, а с традиционными персональными компьютерами и их урезанными разновидностями, такими как NetPC. При этом суть доводов сводится к тому, что ПК, даже урезанные, остаются толстыми клиентами со всеми присущими им недостатками. Было бы странно, если бы события в мире ПК развивались по-другому: не станут же Intel и Microsoft пилить сук частых модернизаций, на котором они удобно устроились?
Аппаратная организация WBT-терминалов выглядит вполне естественной (см. рис. 11), по сути той же, что и у Sun Ray 1 (с точностью до графического устройства). Сходный набор устройств ввода/вывода и коммуникационных портов. Похожие габариты, так что, например, модель начального уровня 3200LE семейства Winterm компании Wyse Technology можно укрепить на стене, освободив тем самым место на рабочем столе пользователя. Wyse занимается производством терминалов уже больше двадцати лет и в настоящее время является одним из ведущих игроков на WBT-рынке. По данным этой компании, наработка на отказ для WBTтерминала составляет 170 000 часов, что почти на порядок больше, чем у обычного ПК. Несложные подсчеты показывают, что даже если пользователи будут эксплуатировать WBT-терминал лет десять, большинству из них не придется столкнуться с отказами аппаратуры.
Встроенное программное обеспечение WBTтерминала располагается во флэш-памяти, допускающей централизованную перезапись с сервера. Для повседневной работы никаких программ с сервера загружать не нужно. Встроенное ПО обеспечивает поддержку протоколов RDP и ICA; иногда в него включают дополнительные компоненты, такие как Интернет-навигатор или эмуляторы алфавитноцифровых терминалов. Строго говоря, в этом нет необходимости, поскольку Windows NT содержит все необходимые компоненты. Например, возможен доступ к Unix-приложениям по схеме, являющейся зеркальным отражением способа доступа Sun Ray 1 к приложениям под Windows (см. выше рис. 8).
К недостаткам подобного подхода следует отнести возможность потери транзакций или даже данных в случае аппаратного сбоя устройства или сети, так как при этом теряется соединение с сервером. Но все же ситуация здесь гораздо лучше, чем со стандартными ПК.
Известно, что потенциал масштабируемости платформы Wintel по сравнению, например, с платформой SPARC/Solaris, является довольно ограниченным. Это значит, что для поддержки большого числа пользователей необходимо применять группы серверов. Впрочем, группирование серверов важно и по многим другим причинам, в числе которых обеспечение высокой доступности и балансировка нагрузки.
В свое время Глеб Ладыженский, пропагандируя идеи программного обеспечения промежуточного слоя (в совокупности с трехуровневой архитектурой и тонкими клиентами), в качестве одного из аргументов привел возможную экономию средств на закупку серверов СУБД за счет мультиплексирования соединений и уменьшения видимого серверу числа пользователей. Реакция корпорации Oracle была хотя и несколько запоздалой, но весьма энергичной (желающие могут обратиться к архиву журнала СУБД – http://www.osp.ru/dbms/1997/01/96.htm). Смысл реакции сводился к тому, что пользователей нужно считать честно.
Мы далеки от мысли, что корпорация Microsoft могла оставить какие-то пробелы и неясности в политике лицензирования собственного ПО, так что со стороны покупателей WBT-терминалов было бы наивным надеяться на какую-то экономию средств при закупке программного обеспечения для многопользовательского доступа. Пользователи будут подсчитаны аккуратно и честно. Продукты компании Citrix также недешевы. Экономия здесь, как и вообще для тонких клиентов, достигается за счет снижения полной стоимости владения, а не начальных затрат.
Желающим ознакомиться со сравнительным анализом графических терминалов и, в частности, WBT, можно порекомендовать статью [7 PC Mag on ZDnet]). В этой статье много внимания уделяется семейству NeoStation компании Neoware Systems – очень интересному и перспективному, рассмотрение которого, к сожалению, выходит за рамки настоящего раздела.
6. Независимая вычислительная архитектура компании Citrix Systems
Клиент для меня – как открытая книга. Жаль, читать не умею. Из «Откровений суперсервера» Мы позволим себе отступить от канонического порядка изложения «от общего к частному», «от концепции к решению» и описать независимую вычислительную архитектуру (Independent Computing Architecture, ICA) компании Citrix Systems. Эта архитектура на сегодняшний день является индустриальным стандартом организации многопользовательского графического доступа к серверам Microsoft Windows. Имеются реализации ICA (клиентских и серверных компонентов) для ОС Unix. По данным компании Citrix на 1999 год, установлено около 15 миллионов экземпляров ее клиентского ПО.
В разное время технологию ICA лицензировали такие компании, как Tektronix (реализовавшая семейство продуктов WinDD), Insignia (NTrigue), NCD (WinCenter PRO), Wyse Technology (Winterm). Первые три предоставляют доступ к приложениям Microsoft Windows
для Unix-платформ и X-терминалов.
Любопытна история развития взаимоотношений компаний Citrix и Microsoft. Сначала Citrix лицензировала Windows NT Server версии 3.51 и реализовала продукт WinFrame, предоставляющий графический многопользовательский доступ. Увидев, что дела Citrix идут весьма успешно, корпорация Microsoft, в свою очередь, лицензировала у Citrix технологию многопользовательского доступа и встроила ее в Windows NT Server 4.0 Terminal Server Edition (TSE), правда, реализовав собственный протокол взаимодействия клиентов и сервера – Remote Desktop (Display) Protocol (RDP). Мы рассматриваем ICA, а не RDP, потому что продукты компании Citrix являются универсальными, многоплатформными.
Идейным стержнем архитектуры, продвигаемой Citrix, является протокол ICA. По своей роли (не по реализации) он близок к X Window, отделяя прикладную логику от интерфейсной и позволяя приложениям под Windows взаимодействовать с удаленными пользователями даже по низкоскоростным линиям. Протокол ICA позволяет передавать:
- представление текстовых экранов;
- представление графических экранов Windowsприложений;
- аудио/видео потоки;
- ввод с клавиатуры и мыши.
Кроме того, с помощью ICA можно управлять сеансами, проводить сжатие и шифрование данных, перенаправлять вывод на печать и т.п.
С современных позиций протокол ICA представляется старомодным, избыточным (например, он может взять на себя управление потоками, обеспечение надежной передачи с восстановлением после ошибок), рассчитанным на самостоятельную поддержку разной среды передачи, разных протоколов канального и транспортного уровней. Общий вид ICA-пакета представлен на рис. 12. С другой стороны, реализация ICA выполнена весьма грамотно, по модульному принципу, так что лишние компоненты могут быть удалены и избыточных действий производиться не будет.
Среди команд, поддерживаемых протоколом ICA, мы кратко опишем управление виртуальными каналами. Разумеется, передается не весь текстовый экран, а только его изменения. Кроме того, может выполняться управление режимами, атрибутами символов, скроллирование, управление курсором.
Виртуальные каналы позволяют передавать данные различных типов (например, графику, аудио и т.п.). Виртуальный канал поддерживает сеанс взаимодействия приложения и пользователя. ICA не пытается разбираться в структуре потока, передаваемого по такому каналу, так что его можно использовать для расширения функциональности клиента без изменения протокола ICA (например, речь может идти о поддержке потокового видео). Если оперировать терминами эталонной модели взаимодействия открытых систем, то можно сказать, что ICA действует на уровне сеансов, а протокол, обслуживающий определенный виртуальный канал, – на уровне представления.
Одним из протоколов виртуального канала является Thinware, обслуживающий передачу графики от Windows-приложений клиентам (см. рис. 13). На сервере обработка графики доходит до уровня интерфейса с графическими устройствами (GDI), после чего в дело вступает Thinware, являющийся с точки зрения приложения частью графической подсистемы Windows. Thinware генерирует оптимизированные графические примитивы, а затем соответствующие данные «подхватываются» протоколом ICA, переносятся на пользовательское рабочее место и отображаются на дисплее с помощью клиентской части ICA и Thinware.
Thinware – это протокол, который обеспечивает кэширование на клиентской стороне графических объектов Windows, таких как битовые карты, курсоры, кисти и т.п. В результате, по утверждению компании Citrix, для удобной работы пользователя достаточно канала с пропускной способностью порядка 20 Кбит/с (рис. 14).
Компания Citrix постоянно развивает свои продукты, стараясь идти в ногу со временем. Технология прикладных порталов NFuse (детальное рассмотрение которой, к сожалению, выходит за рамки настоящей статьи) позволяет встраивать интерактивные приложения в HTML-страницы и затем работать с ними в окне Web-навигатора (при этом компоненты программного обеспечения Citrix должны присутствовать на сервере приложений, Web-сервере и клиенте). В сочетании с выходом основного продукта Citrix – MetaFrame – для операционной платформы Solaris, наличие NFuse позволяет говорить об универсальности архитектуры ICA и o совместимости продуктов Citrix с современными открытыми стандартами.
7. Тонкие клиенты, Web-навигаторы и Java
Не правильно это, когда тонкий клиент берется серверы под себя перестраивать. Из «Откровений суперсервера» Внедрение тонких клиентов затронуло не только область программно-аппаратной платформы, но и привело к пересмотру подходов к построению прикладных систем. Эта волна удивительно удачно совпала с волной интернет-технологий, всеобщего перевода приложений в Web-среду. Попросту говоря, Web-навигатор – это тот же тонкий клиент, только в мире прикладных программ: он так же не имеет состояния и может быть «отключен» от приложения в любой момент; он настолько же может быть сделан управляемым из центра путем загрузки исполняемых кодов (Java или JavaScript). В случае, когда приложение полностью переведено на интернет-технологии, идеальным клиентом для него становится стандартный Web-навигатор. Если говорить о системах «одного приложения» (торговые точки, справочные киоски и т.п.), то для них идеальным клиентским решением становится «аппаратный» навигатор – система с единственной программой.
В жизни чаще бывает, что приложений много, созданы они в разное время и разными людьми, поэтому задача перехода к универсальному Webинтерфейсу для всех приложений приводит к необходимости серьезных вложений в переработку используемых прикладных систем.
Это подтверждается и мнением Aberdeen Group (см. [x1 AGP SunRay]), согласно которому основная причина неудачи «ортодоксальных» сетевых компьютеров и Java-станций кроется в чрезмерном объеме изменений, которые приходится единовременно вносить в серверную часть корпоративной информационной системы. В Jet Info рассматривался опыт компании Sun Microsystems по внедрению Java-станций, анализировалась соответствующая серверная архитектура (см. [JI опыт внедрения, JI98-11-12]), так что читатель легко сможет убедиться в справедливости мнения Aberdeen Group.
Поскольку компьютерных платформ, в том числе клиентских, много, весьма соблазнительным выглядит основной лозунг Java «пишется однажды, выполняется везде». К сожалению, сейчас уже можно говорить о том, что первоначальные прогнозы, выданные на волне Web-революции и всеобщей поддержки Java, не оправдались. Навигационный интерфейс, Java-аплеты не вытеснили традиционного ПО.
Впрочем, значительные изменения налицо и движение в предсказанную сторону происходит, хотя и заметно медленнее, чем ожидалось.
Более практичным представляется подход, при котором навигационные и Java-возможности предлагаются не вместо, а вместе с другими, такими, например, как рассмотренный выше графический терминальный доступ. По такому пути пошла корпорация IBM, выпустившая семейство тонких клиентов Network Station (см. рис. 15).
Аппаратная организация семейства Network Station вполне традиционна. В младших моделях используется процессор Power PC, в старших -Pentium. Объем оперативной памяти лежит в диапазоне 32-256 МБ, присутствует обычный набор коммуникационных интерфейсов. Больший интерес представляет операционное ядро – Network Station Manager.
Network Station Manager содержит серверные и клиентские компоненты. Сервер, как и положено, отвечает за управление клиентами и их администрирование. На клиентской стороне располагаются операционное ядро, средства поддержки пользовательского интерфейса, эмуляторы терминалов (в их число входит X-сервер), навигатор (Netscape Communicator), виртуальная Java-машина. Обеспечивается поддержка ICA-технологии и, тем самым, доступ к Windows-приложениям. В результате клиент, оставаясь тонким, оказывается универсальным в смысле спектра доступных приложений, а возможности локального выполнения вложены в рамки навигатора и Java-машины, то есть остаются контролируемыми с минимальными затратами.
8. Клиенты всякие важны
Иногда, особенно к вечеру, от этих клиентов просто в глазах рябит. Из «Откровений суперсервера» Даже в рамках достаточно небольшой статьи мы увидели широкий спектр самых разных решений, которые можно отнести к тонким клиентам. Попытаемся в заключение провести сравнительную классификацию этих решений, определить наиболее подходящие для них задачи.
В одной из самых простых ситуаций, когда сеть однородна, полностью построена на Windowsсерверах и клиентах, приложения работают исключительно под Windows и никаких сдвигов в этом не планируется, оптимальным решением будет использование Windows NT Terminal Server Edition с какими-либо Windows-Based Terminals (WBT). Единственным «но» в этом решении является его исключительная Windows-ориентированность со всеми вытекающими последствиями: недостаточной надежностью, стабильностью и масштабируемостью. Кроме того, надо отметить, что вопрос применения тонких клиентов встает обычно в сетях достаточно большого размера (больше 100-200 узлов), которые почти никогда не бывают абсолютно однородными.
Решение от Citrix, базирующееся на ICA, гораздо более приспособлено к неоднородным сетям, в которых помимо Windows-машин присутствуют и Unix-серверы, и X-терминалы, и старые 386-е персональные компьютеры. Это решение гораздо шире по возможностям, чем Windows NT TSE (поддержка протоколов IPX/SPX, помимо TCP/IP, расширенная поддержка мультимедиа, широкие возможности по управлению приложениями и пользователями). Протокол ICA поддерживается большим количеством производителей сетевых терминалов, клиентские части реализованы практически для всех использующихся сегодня платформ (DOS, Windows 3.1, Windows 95/98/NT/CE, все распространенные версии Unix, включая Linux, MacOS и другие).
Сетевые терминалы SunRay не имеют себе равных по части безопасности. Аутентификация пользователя по смарт-карте, полная централизация данных и приложений на сервере, защищенный сетевой протокол связи с сервером – все это делает их идеальным рабочим местом для систем с повышенными требованиями к информационной безопасности. Кроме того, в случае перевода большей части приложений в Web-среду это решение было бы предпочтительным, по сравнению с Windows-терминалами в силу гораздо большей стабильности операционной системы Solaris. Возможность работы с Windows-приложениями обеспечивается через сервер Citrix.
Одно из самых старых решений графических тонких клиентов – Х-терминалы – отлично подходит для сильно гетерогенных сред, где имеются несколько версий Unix, Windows NT серверы, приложения для самых разных платформ. Терминалы от Wyse, Neoware прекрасно поддерживают как Xпротокол, так и ICA, имеют набор встроенных клиентов для подключения к Windows-серверам, Webнавигации.
Web-приложения – тонкий клиент из мира программ. Их идеальное применение – многочисленные рабочие места операционистов (в широком смысле – пользователей, заполняющих несколько фиксированных форм и выполняющих с ними несколько фиксированных операций), различные справочные системы (вплоть до систем публичного доступа). Главное достоинство этих систем – никакими действиями пользователь не может ничего «испортить» в самом приложении или его данных. А тот факт, что для его работы достаточно одного лишь Web-навигатора, позволяет сделать аппаратное решение максимально простым и надежным.
Как видно из приведенного анализа, выбор решений достаточно богат, практически под любую из распространенных задач можно подобрать конфигурацию клиента, удобную и для пользователя, и для администратора.
9. Заключение
Клиент, конечно, всегда прав. Ну и что? Из «Откровений суперсервера» В концептуальном плане достоинства тонких клиентов неоспоримы. Это уменьшение полной стоимости владения, простота администрирования, быстрота и экономичность развертывания новых приложений и новых пользовательских рабочих мест, надежная работа без частых модернизаций, информационная безопасность и т.д. Тонкие клиенты развиваются давно, имеются стабильные, проверенные продукты, предлагаемые крупнейшими компаниями. В общем, технических «противопоказаний» тонким клиентам нет. Есть организационнопсихологические.
Проведение в жизнь концепции тонких клиентов требует продумывания архитектуры корпоративной информационной системы, тщательного планирования ее развития. Это сложно. Гораздо проще организовать «автоматизированные рабочие места» с персональными компьютерами, после чего каждый пользователь выкручивается как может. Все постоянно чем-то заняты, к руководству не пристают, разве что денег «на апгрейд» просят (или требуют).
Маленькие системы могут быть построены как угодно. Достоинства тонких клиентов проявляются на больших конфигурациях, которых в России пока не так много. (Не нужно путать размер организации с размером ее информационной системы. Нередко организация оказывается поделенной на небольшие «островки информатизации», между собой практически не связанные.) Тем не менее, несомненно, интеграционные тенденции будут нарастать, что сделает внедрение тонких клиентов более актуальным.
Все описанные выше «тонкие» решения являются открытыми в том смысле, что, по крайней мере, принципиально делают доступными для пользователей приложения на всех платформах. Возможно, что из соображений минимальной новизны многие сначала предпочтут многопользовательский доступ к Windows с WBT-терминалов. Это вполне понятный выбор, который, повторим, по сути не ограничивает возможности пользователей.
На наш взгляд, в долгосрочном плане наиболее перспективными являются универсальные тонкие клиенты на платформе Linux. Помимо технических, они имеют существенные ценовые достоинства, а будущее ОС Linux сейчас не вызывает опасений.
10. Литература
1. Елисеев В., Ладыженский Г. Введение в Интранет. – Jet Info, 1996, 20. 2.
2. Tarakam P., Littlepage J., Ferris C. Опыт внедрения Java-технологии в компании Sun Microsystems. – Jet Info, 1997, 22. 3.
3. Столяров М., Трифаленков И. На пути к управляемым информационным системам. – Jet Info, 1999, 3. 4.
4. Thin clients: the choice for access, simplicity, savings and flexibility. – International Business Machines Corporation, 1999. http://www.ibm. com/nc. 5.
5. Москаленко О. Java-технология как средство создания современных корпоративных систем. – Jet Info, 1999, 5. 6.
6. Бабернов В., Тоботрас Б. Микросерверы. – Jet Info, 1999, 10. 7.
7. Metz C. Editors' Choice: Thin Clients. – PC Magazine, March 22, 2000. http://www.zdnet. com/pcmag/stories/reviews/ 0,6755,2455867,00.html. 8.
8. Sun Ray Hot Desk Architecture: A New Appliance Model Ushers In the Services-Driven Network. – Aberdeen Group, 1999. http://www.sun.com/ products/sunray1/whitepapers/aberdeen/hotdesk-aberdeen.pdf. 9.
9. Таранов А., Цишевский В. Java в три года. – Jet Info, 1998, 11-12. 10.
10. Sun Ray 1 Enterprise Appliance Overview & Technical Brief. – Sun Microsystems, 1999. http://www.sun.com/products/sunray1/whitepa pers/sunray1.overview.wp.pdf. 11.
11. Thin Clients, Windows Terminals, NCs. What's the Difference? – A Wyse Technology White Paper, 1997. http://www.wyse.com/solution/ pdf/whatdif.pdf. 12.
12. Server-based Computing White Paper. – Citrix Systems, 1999. http://www.citrix.com/products/ server_based_computing/default.htm. 13.
13. NeoLinux and Eon – The Anything Box. – Neoware Systems, 2000. http://www.neoware. com/neolinux.
