Несколько лет назад директор фирмы (торговавшей компьютерным хламом и немножко занимавшейся серверами), где я работал системным администратором, загорелся идеей делать и продавать тонкие клиенты. После некоторого количества не очень удачных попыток полного аутсорса разработки, меня привлекли к процессу, как человека, знающего зачем это и как его едят (я не занимался разработкой ПО, я ругался с халтурящими разработчиками и по мере возможности консультировал по.тому, что нужно, а что нет в ТК).
Два года я занимался тонкими клиентами. Сейчас я ухожу в другое место, а пока напишу то, что я знаю о тонких клиентах. Как со стороны пользователя, так и создателя.
Начнём с теории, точнее, с того, зачем тонкие клиенты и с чем их едят. Перед этим нам придётся понять, зачем все эти танцы с удалёнными рабочими столами, местами, VDI, облаками, кластерами и фермами приложений и т.д. и т.п.
Основной идеей удалённого доступа (будь это тривиальный RDP или нетривиальный доступ к приложению в облаке через бридж-сервер узла) является разделение пользовательского железа (кнопочек и монитора) от данных и приложений. Пользовательское железо имеет привычку умирать, портиться, быть украденным, изъятым сотрудниками (не)законных банд-формирований. Это с одной стороны. С другой стороны, в условиях, когда административный контроль работает плохо, пользователи могут иметь желание использовать компьютер «не так». Например, ставить игрушки, смотреть кино и т.д. Любые меры по защите от этого либо уходят в экстремизм (заклёпывание корпуса), либо в бесконечную борьбу инициативных хакеров и задолбавшихся админов.
Обычный десктоп (кстати, совсем не важно, Mac, Windows или Linux) обладает всеми возможными средствами испортить жизнь системному администратору, начальнику отдела безопасности (если таковой есть) или даже гендиректору.
Данные и приложения хранятся в коробке под столом, где много пыли, где в него тыкают всякой ерундой, вроде флешек. Внутри коробки обычно комплектующие… средней степени надёжности, которые от тыкания флешки могут и помереть. Не говоря уже про прочее: пыль, грязь и т.д. Эти данные уязвимы по отношению к постороннему ПО, посторонним людям.
Ставить надёжные комплектующие в пользовательский компьютер? Рейд, ежедневный бэкап? Это тупиковый путь (хотя, да, RAID1 в компьютере у главбуха может быть не такой уж плохой идеей, особенно в марте каждого года — когда приближается дедлайн сдачи готовых налоговых деклараций).
Очевидным решением был вынос данных за пределы компьютера. Есть три принципиально разных метода выноса: либо приложение знает, что данные лежат на сервере и работает с ним само (например, так работает любое SQL-based приложение, все веб-приложения), когда данные лежат на сервере, но имитируется их локальное наличие (сетевые шары) и когда происходит синхронизация данных, хранимых локально, и удалённых (roaming profiles). Каждый из методов имеет свои плюсы и минусы.
«Прямая работа приложения с сервером» выглядит интереснее всего, но это требует «понимающего» приложения. В то время, когда у нас банк-клиенты до сих пор не могут отучиться работать из-под администратора и хотят иметь право писать к себе в каталог, что уж требовать от них работу с серверами так, как удобно администратору…
Сетевые шары интереснее, но у них есть масса ограничений по производительности. Если некая программа (например, почтовый клиент) решит переиндексировать 16Гб архив почты у нескольких человек, то любая вменяемая по цене железка заткнётся. А ведь пользователя не волнует что происходит _там_. Его волнует, что у него тормозит _тут_. И чем больше пользователей, тем острее становится проблема производительности.
Перемещаемые профили (windows) имеют так же существенный минус: долгая загрузка профиля (те самые 16 поменявшихся гигабайт) каждое утро и каждый вечер. Плюс, локальная копия, которая таки может быть интересна вломившимся в офис вооружённым банд-формированиям экономической направленности.
И, главное, ни один из этих методов не решает проблему с приложениями. Приложения могут быть невероятной степени капризности (я как-то имел дело с особой программой по распечатыванию специфичных документов какой-то программы по заполнению таможенных деклараций, которая переставала работать, если раскладкой по-умолчанию был не русский язык). Помимо взбрыков программистов, может быть и объективно сложное по настройке приложение, которое требует несколько часов до приведения его в рабочее состояние.
Всё это приводит к мысли, а почему бы нам приложения не вынести туда же, куда и данные — на сервера? А из рабочего места сделать плоскую и примитивную доску с кнопками, способную только показывать то, что нарисовали программы на сервере.
Так красиво эта идея выглядела в середине 1990ых, когда только-только начинали набирать популярность терминальные решения (более от цитрикса, но постепенно и от майкрософт). На самом деле, проблем там много, и решением их занимаются до сих пор… Впрочем, топик о тонких клиентах.
Итак, тонкий клиент должен давать интерфейс к серверу. Почему именно тонкий клиент, а не «просто рабочее место с терминальной сессией»? Помимо маркетингового жужжания об энергоэффективности, надёжности, бесшумности (что есть правда, но никого не волнует), главная причина применения тонких клиентов — стандартизация рабочих мест с минимизацией их возможностей до уровня «не более, чем необходимо». Чем меньше свобод, тем меньше вероятность, что оно пойдёт в разнос. Изготовление ТК своими силами возможно, но куда более проблемно, чем кажется человеку, способному настроить X-server с автозапуском rdesktop. (надеюсь, я потом напишу чуть больше о «самострое» и проблемах, которые ожидают взявшихся за это).
На рынке много производителей тонких клиентов (слишком много, как кажется с позиции одного из производителей), но по большому счёту, все тонкие клиенты, от монстров уровня HP до локальных небольших производителей (в одном из которых я и работал) более менее похожи в своей основе.
Лет пять назад весь функционал ТК можно было свести к «настроить», «запустить», «работать». Список протоколов был скромен: RDP, ICA, SSH, NX (nomachines), X11/XDM, VNC… Возможно, веб-браузер. Сейчас ситуация начала склоняться в сторону всякого рода облаков и виртуализации, но с точки зрения ТК это означает лишь ещё один клиент к ещё одному сервису удалённого доступа. Куда более серьёзным изменением современности стали web2.0 приложения, т.е. приложения, хранящие данные на сервере, а исполняющиеся (частично) в веб-браузере пользователя. Это малозаметное изменение привело к существенному переосмыслению, чем должен быть ТК. Он не должен только рисовать, он должен ещё и считать. Впрочем, подобное изменение снова открыло вопрос о приватности уязвимости рабочего места.
Ещё одним серьёзным изменением стало появление встроенных SIP/Skype клиентов, попытки (пока не очень успешные) сделать хорошую мультимедиа (в частности, видео).
С точки зрения загрузки, ТК делятся на два класса: с локальной и с сетевой загрузкой. По понятным причинам, сетевая загрузка преимущественно у линукса, т.к. грузить гиг по сети ради windows никому не хочется, а про PXE для CE я не слышал (хотя интересно, т.к. средний размер установленной CE — 15-30Мб).
Итак, в чём плюсы локальной загрузки? Основной (как показывает мне мой опыт, довольно серьёзный с точки зрения многих покупателей) — оно работает из коробки. Никаких DHCP/TFTP серверов, никакой возни с преднастройками. Воткнул, включил, указал адрес сервера, работай. Второй плюс — отсутствие «утренних лагов» (когда все одновременно начинают грузиться).
Плюс сетевой загрузки в некотором снижении цены (на цену DOM'а, т.е. 10-30 долларов), в автоматической загрузке самой свежей версии. Минусы — утренние лаги, особая возня с DHCP, и проистекающая из неё неприменимость таких тонких клиентов в малых филиалах (где весь интернет делается SOHO-коробочкой, возможно, по wifi).
За исключением экспериментальных решений (о которых, возможно, я расскажу потом), все тонкие клиенты делают на одной из трёх платформ: Windows CE, Linux и Windows Embedded Standard (особая версия Windows XP, отличающаяся довольно прилично от десктопов). До определённого момента флаг первенства был на стороне Linux, но сейчас ситуация повернулась в сторону CE6. Причина: rdesktop не умеет RDP версии 6 и выше. А CE умеет. А это довольно серьёзное преимущество, потому что, как минимум, это поддержка микрофона. (в RDP 5.2 её нет, её нет в CE5 и в rdesktop). Но, с другой стороны, VMView Client есть только под linux и WES, и все его версии под CE являются «доморощенными» (т.е. написанными не VMWare) и очень страдают от… от того, что их писали не авторы сервера. Ещё одним недостатком CE является очень фиговая поддержка WWW. она есть, но IE6 из CE ужасает ещё больше, чем обычный IE. файрфокс на линуксе и полный ассортимент браузеров на WES куда больше радует.
Куда более важным (чем режим загрузки) для ТК является наличие управления.
Управление может быть:
Первое является стандартом де-факто для ТК с локальной загрузкой, но часто может отсутствовать у PXE-тонких клиентов (т.к. они грузятся с сервера, от оттуда же и берут настройки).
Второе и третье для клиентов с локальной загрузкой — фича. Т.е. она есть совсем не у всех производителей. Отдельно нужно говорить про централизованное управление. Это много более сложная вещь, чем кажется на первый взгляд, так как дело не в том, чтобы задать всем ТК одинаковые настройки, а в том, чтобы иметь возможность указать, какие настройки одинаковы, а какие нет (например, настройки железа у всех разные, настройки сессий могут отличаться от группы к группе).
Для ТК, которые работают в windows-сети самым шиком считается интеграция в AD, т.е. возможность либо получать данные из active directory, либо (это высший пилотаж) интегрировать ТК как компьютеры в оснастку AD, применять к ним групповые политики на основании OU/Site и т.д. Надо сказать, каким-то странным образом WES умеет это всё «из коробки». Однако, WES, при всей своей внешней привлекательности, самая плохая платформа для ТК (т.к. слишком похожа на обычные винды и уязвима для всего того, что может быть на виндах сделано плохого...)
Большинство производителей работают в очень закрытом режиме (т.е. не публикуют ничего, хотя и потребляют очень много от open source community). Единственное исключение, которое я знаю, это openthinclient.org, довольно симпатичный и навороченный PXE-based тонкий клиент с централизованным управлением. Его минусом является размер — около 150 мегабайт грузится по сети для каждого тонкого клиента.
(продолжение про то, как тонкие клиенты делаются, следует).
Два года я занимался тонкими клиентами. Сейчас я ухожу в другое место, а пока напишу то, что я знаю о тонких клиентах. Как со стороны пользователя, так и создателя.
Начнём с теории, точнее, с того, зачем тонкие клиенты и с чем их едят. Перед этим нам придётся понять, зачем все эти танцы с удалёнными рабочими столами, местами, VDI, облаками, кластерами и фермами приложений и т.д. и т.п.
Основной идеей удалённого доступа (будь это тривиальный RDP или нетривиальный доступ к приложению в облаке через бридж-сервер узла) является разделение пользовательского железа (кнопочек и монитора) от данных и приложений. Пользовательское железо имеет привычку умирать, портиться, быть украденным, изъятым сотрудниками (не)законных банд-формирований. Это с одной стороны. С другой стороны, в условиях, когда административный контроль работает плохо, пользователи могут иметь желание использовать компьютер «не так». Например, ставить игрушки, смотреть кино и т.д. Любые меры по защите от этого либо уходят в экстремизм (заклёпывание корпуса), либо в бесконечную борьбу инициативных хакеров и задолбавшихся админов.
Обычный десктоп (кстати, совсем не важно, Mac, Windows или Linux) обладает всеми возможными средствами испортить жизнь системному администратору, начальнику отдела безопасности (если таковой есть) или даже гендиректору.
Данные и приложения хранятся в коробке под столом, где много пыли, где в него тыкают всякой ерундой, вроде флешек. Внутри коробки обычно комплектующие… средней степени надёжности, которые от тыкания флешки могут и помереть. Не говоря уже про прочее: пыль, грязь и т.д. Эти данные уязвимы по отношению к постороннему ПО, посторонним людям.
Ставить надёжные комплектующие в пользовательский компьютер? Рейд, ежедневный бэкап? Это тупиковый путь (хотя, да, RAID1 в компьютере у главбуха может быть не такой уж плохой идеей, особенно в марте каждого года — когда приближается дедлайн сдачи готовых налоговых деклараций).
Очевидным решением был вынос данных за пределы компьютера. Есть три принципиально разных метода выноса: либо приложение знает, что данные лежат на сервере и работает с ним само (например, так работает любое SQL-based приложение, все веб-приложения), когда данные лежат на сервере, но имитируется их локальное наличие (сетевые шары) и когда происходит синхронизация данных, хранимых локально, и удалённых (roaming profiles). Каждый из методов имеет свои плюсы и минусы.
«Прямая работа приложения с сервером» выглядит интереснее всего, но это требует «понимающего» приложения. В то время, когда у нас банк-клиенты до сих пор не могут отучиться работать из-под администратора и хотят иметь право писать к себе в каталог, что уж требовать от них работу с серверами так, как удобно администратору…
Сетевые шары интереснее, но у них есть масса ограничений по производительности. Если некая программа (например, почтовый клиент) решит переиндексировать 16Гб архив почты у нескольких человек, то любая вменяемая по цене железка заткнётся. А ведь пользователя не волнует что происходит _там_. Его волнует, что у него тормозит _тут_. И чем больше пользователей, тем острее становится проблема производительности.
Перемещаемые профили (windows) имеют так же существенный минус: долгая загрузка профиля (те самые 16 поменявшихся гигабайт) каждое утро и каждый вечер. Плюс, локальная копия, которая таки может быть интересна вломившимся в офис вооружённым банд-формированиям экономической направленности.
И, главное, ни один из этих методов не решает проблему с приложениями. Приложения могут быть невероятной степени капризности (я как-то имел дело с особой программой по распечатыванию специфичных документов какой-то программы по заполнению таможенных деклараций, которая переставала работать, если раскладкой по-умолчанию был не русский язык). Помимо взбрыков программистов, может быть и объективно сложное по настройке приложение, которое требует несколько часов до приведения его в рабочее состояние.
Всё это приводит к мысли, а почему бы нам приложения не вынести туда же, куда и данные — на сервера? А из рабочего места сделать плоскую и примитивную доску с кнопками, способную только показывать то, что нарисовали программы на сервере.
Так красиво эта идея выглядела в середине 1990ых, когда только-только начинали набирать популярность терминальные решения (более от цитрикса, но постепенно и от майкрософт). На самом деле, проблем там много, и решением их занимаются до сих пор… Впрочем, топик о тонких клиентах.
Итак, тонкий клиент должен давать интерфейс к серверу. Почему именно тонкий клиент, а не «просто рабочее место с терминальной сессией»? Помимо маркетингового жужжания об энергоэффективности, надёжности, бесшумности (что есть правда, но никого не волнует), главная причина применения тонких клиентов — стандартизация рабочих мест с минимизацией их возможностей до уровня «не более, чем необходимо». Чем меньше свобод, тем меньше вероятность, что оно пойдёт в разнос. Изготовление ТК своими силами возможно, но куда более проблемно, чем кажется человеку, способному настроить X-server с автозапуском rdesktop. (надеюсь, я потом напишу чуть больше о «самострое» и проблемах, которые ожидают взявшихся за это).
На рынке много производителей тонких клиентов (слишком много, как кажется с позиции одного из производителей), но по большому счёту, все тонкие клиенты, от монстров уровня HP до локальных небольших производителей (в одном из которых я и работал) более менее похожи в своей основе.
Лет пять назад весь функционал ТК можно было свести к «настроить», «запустить», «работать». Список протоколов был скромен: RDP, ICA, SSH, NX (nomachines), X11/XDM, VNC… Возможно, веб-браузер. Сейчас ситуация начала склоняться в сторону всякого рода облаков и виртуализации, но с точки зрения ТК это означает лишь ещё один клиент к ещё одному сервису удалённого доступа. Куда более серьёзным изменением современности стали web2.0 приложения, т.е. приложения, хранящие данные на сервере, а исполняющиеся (частично) в веб-браузере пользователя. Это малозаметное изменение привело к существенному переосмыслению, чем должен быть ТК. Он не должен только рисовать, он должен ещё и считать. Впрочем, подобное изменение снова открыло вопрос о приватности уязвимости рабочего места.
Ещё одним серьёзным изменением стало появление встроенных SIP/Skype клиентов, попытки (пока не очень успешные) сделать хорошую мультимедиа (в частности, видео).
С точки зрения загрузки, ТК делятся на два класса: с локальной и с сетевой загрузкой. По понятным причинам, сетевая загрузка преимущественно у линукса, т.к. грузить гиг по сети ради windows никому не хочется, а про PXE для CE я не слышал (хотя интересно, т.к. средний размер установленной CE — 15-30Мб).
Итак, в чём плюсы локальной загрузки? Основной (как показывает мне мой опыт, довольно серьёзный с точки зрения многих покупателей) — оно работает из коробки. Никаких DHCP/TFTP серверов, никакой возни с преднастройками. Воткнул, включил, указал адрес сервера, работай. Второй плюс — отсутствие «утренних лагов» (когда все одновременно начинают грузиться).
Плюс сетевой загрузки в некотором снижении цены (на цену DOM'а, т.е. 10-30 долларов), в автоматической загрузке самой свежей версии. Минусы — утренние лаги, особая возня с DHCP, и проистекающая из неё неприменимость таких тонких клиентов в малых филиалах (где весь интернет делается SOHO-коробочкой, возможно, по wifi).
За исключением экспериментальных решений (о которых, возможно, я расскажу потом), все тонкие клиенты делают на одной из трёх платформ: Windows CE, Linux и Windows Embedded Standard (особая версия Windows XP, отличающаяся довольно прилично от десктопов). До определённого момента флаг первенства был на стороне Linux, но сейчас ситуация повернулась в сторону CE6. Причина: rdesktop не умеет RDP версии 6 и выше. А CE умеет. А это довольно серьёзное преимущество, потому что, как минимум, это поддержка микрофона. (в RDP 5.2 её нет, её нет в CE5 и в rdesktop). Но, с другой стороны, VMView Client есть только под linux и WES, и все его версии под CE являются «доморощенными» (т.е. написанными не VMWare) и очень страдают от… от того, что их писали не авторы сервера. Ещё одним недостатком CE является очень фиговая поддержка WWW. она есть, но IE6 из CE ужасает ещё больше, чем обычный IE. файрфокс на линуксе и полный ассортимент браузеров на WES куда больше радует.
Куда более важным (чем режим загрузки) для ТК является наличие управления.
Управление может быть:
- локальным (подошёл к ТК, нажал F2, оказался в конфигураторе).
- удалённым (подключился к ТК, настроил, отключился)
- централизованным (выбрал группу ТК, задал настройки, дальше оно всё само).
Первое является стандартом де-факто для ТК с локальной загрузкой, но часто может отсутствовать у PXE-тонких клиентов (т.к. они грузятся с сервера, от оттуда же и берут настройки).
Второе и третье для клиентов с локальной загрузкой — фича. Т.е. она есть совсем не у всех производителей. Отдельно нужно говорить про централизованное управление. Это много более сложная вещь, чем кажется на первый взгляд, так как дело не в том, чтобы задать всем ТК одинаковые настройки, а в том, чтобы иметь возможность указать, какие настройки одинаковы, а какие нет (например, настройки железа у всех разные, настройки сессий могут отличаться от группы к группе).
Для ТК, которые работают в windows-сети самым шиком считается интеграция в AD, т.е. возможность либо получать данные из active directory, либо (это высший пилотаж) интегрировать ТК как компьютеры в оснастку AD, применять к ним групповые политики на основании OU/Site и т.д. Надо сказать, каким-то странным образом WES умеет это всё «из коробки». Однако, WES, при всей своей внешней привлекательности, самая плохая платформа для ТК (т.к. слишком похожа на обычные винды и уязвима для всего того, что может быть на виндах сделано плохого...)
Большинство производителей работают в очень закрытом режиме (т.е. не публикуют ничего, хотя и потребляют очень много от open source community). Единственное исключение, которое я знаю, это openthinclient.org, довольно симпатичный и навороченный PXE-based тонкий клиент с централизованным управлением. Его минусом является размер — около 150 мегабайт грузится по сети для каждого тонкого клиента.
(продолжение про то, как тонкие клиенты делаются, следует).
