7 января 2009 г.
ОпросИТ-бюджет моей компании в следующем году:Значительно уменьшится (на 20% и более) 35% (24 голоса) Если и сократится, то не сильно 14% (10 голосов) В целом не изменится 7% (5 голосов) Увеличится 10% (7 голосов) Окончательно еще не решено 13% (9 голосов) Я не имею отношения к планированию корпоративного ИТ-бюджета 33% (23 голоса) Уже проголосовали: 69 В продаже с 23 декабря |
Терминальные решения на платформе Windows в Украине
Автор – Юрий Жуковский, 8 июля 2004 г.
Подобные решения в то время не получили распространения по целому ряду причин. Во-первых, они были ориентированы, скорее, на администраторов систем, чем на обычных клиентов, стремящихся к комфортной работе. Во-вторых, далеко не каждая программа могла быть запущена в терминальной среде, и еще меньшая часть - корректно и стабильно в ней исполняться. В третьих, само решение не отличалось изяществом - требовалась мощная серверная часть, использовались достаточно ресурсоемкие протоколы обмена. Но, наверное, основным тормозящим фактором на пути "в массы" оказалось банальное отсутствие в нашей стране крупных отечественных структур, которым подобная функциональность была бы необходима в реальной каждодневной работе. Тем не менее Windows NT 4.0 Terminal Server начал постепенно завоевывать украинские информационные просторы. Несмотря на закат "эпохи DOS", большинство приложений для платформы Windows несли в себе значительную часть унаследованного кода, плохо уживавшегося с Terminal Server. Один из самых ярких примеров тех лет - после завершения работы в клиентской сессии "родной" Microsoft Excel 97 не возвращал ресурсы оперативной памяти сервера, что приводило к ее серьезной "утечке" и вынуждало часто перезагружать сервер. В то же время были и продукты, которые "любили" терминальную среду. К ним можно отнести Word 97 и "1С:Предприятие 7.5". Так, последнее приложение, запущенное в терминальном режиме, позволяло достичь лучших показателей и в плане производительности, по максимальному количеству одновременно подключенных пользователей, и, самое важное, - по степени сохранности данных, стабильности работы системы в целом (напомним, что основная масса локальных вычислительных сетей в СНГ была выполнена на коаксиальном кабеле и высокой надежностью не отличалась). Применение терминального режима привносило набор уникальных возможностей, наиболее важными среди которых были:
Наш экскурс в историю остается актуальным и сегодня - не секрет, что в Украине до сих пор используются в "полулегальном" (с точки зрения лицензирования) режиме множество дешевых и слегка устаревших, но от этого не менее эффективных по своим возможностям терминальных решений типа "Windows NT 4.0 + Citrix MetaFrame 1.8", приводящих в трепет представителей контролирующих и надзирательных органов - нет никаких следов коммерческих данных на пользовательских ПК!
Переступив через рубеж тысячелетий... Некой поворотной точкой в развитии терминальных решений на платформе Windows можно считать 2000 г., причем не только благодаря выходу Windows 2000 Server, в котором компонент Terminal Server стал стандартным. Несомненно, создаваемая с его помощью терминальная среда оказалась более производительной и стабильной, снизились требования к системным ресурсам, упростился процесс администрирования. Однако по-прежнему отсутствовала возможность прозрачной работы с ресурсами локального ПК, протокол связи хотя и претерпел ряд позитивных изменений, оставался достаточно ресурсоемким, а стандартный буфер обмена Windows не позволял обмениваться данными между приложениями, запущенными в терминальной сессии и на локальном ПК. Наконец, в среднем один раз в две-три недели приходилось перезагружать сервер: Но благодаря выходу Microsoft Office 2000, рассчитанному на работу в терминальном режиме, общему обновлению прикладного программного обеспечения, ориентированного на работу в среде Windows (а не DOS), улучшению ситуации с каналами связи и развитием Internet процесс внедрения терминальных решений пошел. На первых порах наиболее интенсивно это происходило в динамично развивающихся коммерческих структурах, где уже накопился парк морально устаревшей компьютерной техники и имелись низкоскоростные локальные сети (10 Мbps) на коаксиальном кабеле или витой паре. Действительно, установка в таких компаниях одного достаточно производительного сервера позволяла отказаться от модернизации множества ПК и отодвинуть необходимость модернизации существующих ЛВС (что весьма актуально в арендуемых помещениях). А приверженцы freeware, используя ОС Linux на рабочих станциях, получили возможность существенно снизить затраты на закупку ПО и уменьшить вероятность поражения системы вирусами. При всем этом конечный пользователь продолжал работать в привычном для себя окружении Windows, причем самой последней версии, иногда даже и не догадываясь, что работает он в клиентской сессии (в терминальном режиме). Наибольший же эффект от применения терминальных решений получили различные приложения, содержащие значительные массивы информации, для которых пропускной способности интерфейсов "много не бывает". Что же дает сегодня терминальный режим работы пользователей при эксплуатации офисных приложений и систем автоматизации учета - например таких, как "1С:Предприятие 7"?
Современная практика Давайте посмотрим, где и каким образом могут быть реализованы выше-описанные преимущества. Пример 1. Офис предприятия с количеством пользователей 5-100
В итоге к набору наиболее ресурсоемких задач для IT-подразделения можно отнести: администрирование рабочих станций пользователей, их поддержку, создание резервных копий документов и БД, надзор за использованием конфиденциальной информации, контроль версий ПО и антивирусную защиту. Организация работы пользователей в режиме терминального подключения позволяет решать часть из них на качественно ином уровне (рис. 1). В связи с тем что физически вся работа пользователя выполняется на сервере с применением одних и тех же пакетов прикладного ПО и общего хранилища данных, вопрос контроля версий ПО решается автоматически, а создание резервных копий не вызывает никаких проблем. Уровень контроля прав пользователей соответствует возможностям серверной ОС, существенно снижая вероятность утечки конфиденциальной информации. Становится возможным осуществлять поддержку путем подключения администратора к сессии пользователя на сервере (естественно, при условии, что последний ему это позволит, так что конфиденциальность не страдает), не тратя время на перемещение по офису. Причем администратор вовсе не обязан сидеть за консолью сервера, а может зайти по стандартной "клиентской" схеме. Администрирование пользовательской рабочей среды производится путем конфигурирования клиентской учетной записи на сервере и фактически сводится к поддержанию прин-ципиальной способности терминального ПК загрузить ОС и запустить Remote Desktop Connection (RDC). В большинстве случаев процесс миграции сотрудников при замене ПК сводится к распаковке, установке, настройке сетевых интерфейсов и инсталляции приложения RDC (не требуя никакого специализированного ПО) и занимает не более получаса. В случае же выхода из строя ПК достаточно пересесть за любой другой ПК в сети организации и подключиться к серверу. Потеря информации в этом случае практически исключена. Заметно лучше становится ситуация и с антивирусной защитой критически важной информации, так как можно четко разграничить запуск соответствующих служебным обязанностям приложений на сервере и персонализировано-развлекательных - непосредственно на ПК. В некоторых ситуациях использование терминального доступа к приложениям позволяет сэкономить на лицензионных отчислениях, закупая вместо полноценных комплектов ПО лицензии на количество одновременных подключений. Особенно это эффективно в случае наличия большой группы пользователей, которым доступ к определенным приложениям необходим лишь время от времени (секретарю в строительной организации изредка может понадобиться возможность распечатать файл формата AutoCAD, менеджеру по рекламе - проект в Photoshop или Corel), или они работают посменно. Пример 2. Центральный офис холдинга и удаленные подразделения В данном случае рассматривается уже не одно здание или группа помещений, находящихся на расстоянии 50-100 м друг от друга, а предприятие с частично или полностью независимыми подразделениями в других городах. И, соответственно, все проблемы, описанные в Примере 1, "перемножаются" на расстояние между городами и приводят к необходимости содержать штат высококвалифицированных сотрудников "на местах" либо "командировочных специалистов", что обойдется еще дороже. И не факт, что именно в центральном офисе будут постоянно требоваться лучшие специалисты, ведь размеры информационных систем филиалов могут быть намного больше и сложнее в администрировании, чем у центрального офиса. Так что с точки зрения холдинга во главу угла ставятся надежность функционирования всей информационной инфраструктуры, защита конфиденциальной информации, рациональное использование высококлассных (и, соответственно, дорогих) специалистов, максимально эффективное применение аппаратного обеспечения и лицензий на ПО.
Но и на просторах СНГ, с гораздо менее глобальными задачами, применение терминальных решений может быть весьма эффективным. Представим себе некую консультационную фирму, офисы которой находятся в разных концах города или же в разных городах. В пределах одного населенного пункта они могут быть связаны между собой посредством выделенных цифровых каналов (или аналоговых выделенных линий), а между городами - через Internet, в том числе с применением VPN. А теперь вспомним, что лицензии на некоторые пакеты, например ту же базу правовой информации "Лига" или ПО "1С:Предприятие", можно приобрести не в виде отдельных пакетов в каждый офис, а в "сетевом" варианте, т. е. для всех пользователей, работающих в общем сетевом пространстве (в данном случае доступность ПО определяется наличием в сети аппаратного ключа защиты). Да и при условии наличия хотя бы одного квалифицированного пользователя в каждом офисе, повторимся, администрировать подобную ИС могут один-два системных администратора. Пример 3. Завод
Но не станем слишком углубляться в проблему. Независимо от применяемой технологии связи (Wi-Fi, xDSL, HomePNA) имеет смысл использовать именно терминальный вариант работы удаленных "точек доступа". Это разумно и по соображениям экономии пропускной способности протяженных сетевых интерфейсов, и с точки зрения сохранности данных - все они находятся и обрабатываются на сервере, а для работы одного пользователя достаточно канала в пару десятков килобит. В итоге нет необходимости передавать довольно объемные пакеты информации по медленным интерфейсам (блокируя на время передачи доступ к ним других пользователей) и подвергать информацию риску повреждения. Пример 4. Продажа запасных частей к автомобилям и сельскохозяйственной технике
Это как раз та ситуация, когда Ter--minal Server и аппаратные реализации терминального клиента являются фактически единственно возможным решением. Аппаратные терминалы с ПО Citrix способны только дозвониться по телефону и подключиться к серверу, зато вывести их из строя можно, разве что повредив физически, а обслуживание сводится к уборке пыли. Для приемлемой работы одного пользователя достаточно полосы пропускания 9-14 Kbps - вполне "подъемной" для аналоговых телефонных линий, GSM или CDMA (рис. 4). Установив в представительствах аппаратные терминалы и обучив сотрудников пользоваться фирменной БД, можно получить торговую сеть в сотни, а то и тысячи пользователей, имеющих доступ к постоянно актуальной информации в режиме реального времени. А заключив с Internet-провайдерами договор о QoS - дополнительно сэкономить на междугородных переговорах, сократить модемный пул в центральном офисе и существенно увеличить количество одновременно обрабатываемых заказов. Пример 5. Оптовый склад Если внимательнее приглядеться к работе "классического" оптового склада, то всплывает один крайне неприятный организационный нюанс. При получении товара кладовщик должен вначале, стоя возле входа, пересчитать получаемый товар, затем подойти к ПК, занести данные в ИС предприятия и лишь потом отпускать только что полученный товар. В жизни все получается совсем не так гладко. Товар, разгружаемый из фуры, часто вообще не пересекает ворот склада - сразу перегружается в другие автомобили (действительно, вначале завезти товар на склад, разгрузить и т. п. и потом вывезти, потеряв уйму времени,-- крайне непроизводительно, если рядом ждет машина под загрузку.) Кроме того, как правило, параллельно с получением товара идет его выдача. При интенсивной же работе склада оставить ворота открытыми и пойти набирать данные на ПК кладовщик позволить себе не может. Как результат - данные в БД предприятия он вносит вечером, уже после закрытия склада. При этом отдел сбыта работает практически вслепую, без оперативной информации о состоянии склада. Еще хуже бухгалтерии - она вынуждена работать в "режиме отрицательных остатков", так как остановить выдачу товара невозможно, а данные о приходе на склад поступят только в конце дня. Соответственно, корректный партионный учет обеспечивается беспрерывными перепроведениями документов по вечерам и "подвигов" в отчетный период. Представляете, как забавно выглядит отпуск со склада, на котором числится "минус 300" единиц товара? Проблема еще больше усугубляется при работе со скоропортящимися продуктами. В такой ситуации крупные компании часто вынуждены применять специализированные аппаратно-программные решения и в помощь кладовщику привлекать дополнительно операторов ПК. Terminal Server здесь предлагает эффективное решение за вполне приемлемые деньги. При небольшой модификации используемого на предприятии ПО (для удобства работы на маленьком экране) можно установить точку доступа Wi-Fi ($90-650) и подключить к ней по крайней мере четыре КПК с интерфейсом Wi-Fi ($290-450) или Table PC с Wi-Fi ($950-2400). В итоге сумма инвестиций вполне сравнима с затратами на установку четырех ПК и подведение к ним ЛВС, а эффективность: Кладовщик имеет возможность постоянно находиться на рампе и контролировать все происходящее, причем можно одновременно отслеживать несколько разгрузок-погрузок. При частичном проведении приходной накладной появляется возможность "без минусов" оформлять расходные накладные с реальным отслеживанием партий товара. Отдел сбыта всегда имеет оперативную информацию об остатках, отдел логистики - точные данные о времени разгрузки-погрузки, отправке и прибытии транспортных средств. Намного упрощается и жизнь бухгалтерии, и, что особенно приятно, снижается вероятность недоразумений с фискальными органами. Пример 6. Ресторан Всем известно, как неприятно в час пик вначале ждать, пока подойдет официант, затем - пока принесет заказ: Хотя вроде бы никто и не гуляет, все стараются. В некоторых ситуациях долгое обслуживание может быть вызвано чисто техническими причинами. Проследим за процессом. Официант подходит к клиенту и записывает заказ. Затем идет к электронному терминалу (перед которым в моменты наплыва клиентов выстраивается очередь из официантов) и вносит информацию в систему (т. е., по сути, делает двойную работу). Затем заказ поступает на исполнение в бар и на кухню, после чего официант вынужден постоянно подходить и интересоваться, готов ли он. Проблему можно частично решить путем установки дополнительных терминалов (а они недешевы - только чувствительный к нажатию экран стоит около $1000), но и это не отменяет бесконечных походов между кухней и баром. Давно известная и активно применяемая на Западе технология - выдача официантам специализированных КПК и использование беспроводных коммуникаций. И если сеть Wi-Fi в Украине можно развернуть без особых проблем и за разумные деньги, то специализированные КПК довольно дороги (около $700) и продаются со своим ПО, которое зачастую стоит не меньше. А такой уровень затрат для большинства отечественных предприятий общественного питания явно чрезмерен. Как ни странно, и здесь Terminal Server окажется весьма эффективным. Опять-таки, несколько доработав уже имеющееся ПО (оптимизация под экран КПК), можно установить одну-две точки доступа Wi-Fi ($90-650) и раздать официантам КПК с поддержкой Wi-Fi ($300-550). Так что каждый из них получает персональный терминал ввода (избавились от очереди перед общим терминалом), данные заносит непосредственно в систему (вводятся один раз и чуть-чуть раньше, что тоже экономит время), и отпадает необходимость бегать между кухней и баром (информация о готовности заказа поступает прямо к адресату без промедления). В итоге появляется возможность перевести обслуживание клиентов на качественно иной уровень со вполне разумными затратами, если не экономить. Но тут уж все зависит от политики лицензирования применяемого ПО. Кстати, имея в заведении беспроводную сеть, можно еще и "продавать" посетителям доступ в Internet. Пример 7. Торговый агент Представим себе работу "полевого" торгового агента. Утром он заходит в офис, берет список должников, определяет в CRM-системе, кто давно не закупал продукцию, получает информацию по остаткам на складе и отправляется на свой участок. Придя к клиенту, он проверяет ассортимент (мерчандайзинг), идет беседовать в бухгалтерию (если есть задолженность), далее согласует с товароведом ассортимент очередной закупки и звонит в офис с просьбой оформить заказ или отправить счет по факсу. Вечером все данные заносятся в ИС предприятия. Как и в предыдущем примере, крупные корпорации разработали (или разрабатывают) различные Web-ориентированные интерфейсы к своим ИС и снабжают сотрудников КПК c GSM/GPRS-модулями. Тем самым они добиваются сокращения времени, теряемого агентами на получении/внесение информации в ИС предприятия, а также обеспечивают всегда актуальной информацией и торговых агентов, и отдел логистики. А что же делать небольшой фирме, торгующей канцелярскими товарами в розницу и обслуживающей офисы с доставкой? Номенклатура составляет тысячи единиц товара, складские запасы изменяются несколько раз в час, а заказы поступают чаще всего непосредственно при доставке предыдущего заказа и классифицируются клиентом как срочные. Вот и получается, что продавец постоянно "висит на телефоне", уточняет наличие товара, меняет маршрут. А ведь применение терминального подключения КПК c GSM/GPRS или с Bluetooth через мобильный телефон к серверу компании и работа с актуальной информацией не только повышают качество обслуживания клиентов, но и позволяют избежать досадных недоразумений "не то услышал - не то сказал", согласовав заказ с клиентом и непосредственно оформив счет. И количество работников офиса, которым надо не только платить зарплату, но и обеспечить рабочее место, резко сокращается. При этом нет необходимости строить Web-портал, создавать IT-отдел-- с большинством приложений (например, та же "1С") можно хоть и не особенно комфортно, но все же работать без внесения каких-либо изменений в ПО и без оптимизации под КПК. Пример 8. Системный администратор Не секрет, что во многих крупных компаниях проблемы в работе почтовой системы, да и всей сети в целом, являются "красной тревогой" для системных администраторов и требуют от них в любое время и в любом месте незамедлительно приступить к восстановлению нормального функционирования системы. Традиционно этот вопрос решается либо организацией круглосуточного дежурства, либо выдачей системному администратору ноутбука и средств связи. И тот, и другой вариант недешев, и далеко не каждая организация может себе это позволить. Умеющие считать свои деньги компании еще года полтора назад начали снабжать системных администраторов набором из КПК и мобильного телефона с Bluetooth и организовали шлюзы для входа в систему через каналы мобильных операторов. При соответствующем конфигурировании серверов сразу, как только возникает проблема в сети, сервер безопасности отправляет SMS-сообщение администратору либо звонит и сообщает о проблемах по голосовой связи. Ад-ми-нистратор, используя КПК и мобильную связь практически откуда угодно и незамедлительно, имеет возможность входа в систему в режиме терминального клиента и приступает к устранению неисправности (даже находясь в этот момент в маршрутном такси). Стоимость такого решения заметно меньше и стоимости ноутбука, и организации круглосуточного дежурства, а эффективность в большинстве случаев достаточна. Да и носить с собой компактный и легкий КПК намного удобнее. Таким образом, относительно небольшие компании с приемлемым уровнем затрат могут снизить время простоев своих ИС, а большие-- имеют возможность сэкономить без ущерба стабильности работы. Обычно в терминальном режиме работают не все сотрудники организации, а только некоторые группы. Наибольший эффект можно получить при работе в таком режиме группы пользователей одного приложения с общей базой данных или нескольких однотипных групп, например, все менеджеры отдела продаж или все бухгалтеры. С технической точки зрения это самый правильный путь. В то же время довольно часто терминальный режим доступа к приложению применяется только для группы привилегированных пользователей, чьи функции требуют минимально возможного времени отклика системы. При этом проявляется одна неприятная особенность. В ситуации, когда сервер с данными одновременно является и сервером, на котором запускаются клиентские терминальные сессии (или имеет более скоростной канал к серверу с данными), "терминальные" пользователи получают существенное преимущество перед "сетевыми". Причем время отклика приложения при доступе к данным может отличаться в разы! И чем больше нагружен сервер, тем дольше придется ждать своей очереди "сетевым" клиентам. В некоторых случаях это приводит к отключению приложений от источников информации, и хорошо, если само приложение способно безболезненно перенести подобные экстренные отключения без повреждения данных (речи о выполненной, но не сохраненной работе пользователя никто даже не ведет)! Так что при высокой конкуренции на доступ к одной и той же информации имеет смысл всем пользователям применять терминальное подключение. К тому же почти наверняка количество сотрудников, получивших одновременно доступ к данным, будет в 1,5-2 раза больше. Еще одна особенность, которую необходимо учитывать при эксплуатации на одном и том же физическом сервере Terminal Server и других серверных приложений, - их "уживчивость" друг с другом. Во-первых, желательно, чтобы на уровне требований к аппаратным средствам они были критичны к быстродействию различных компонентов сервера. Примером функциональной сочетаемости может служить одновременное использование одного сервера в качестве Terminal Server и File Server, так как первый требователен к ресурсам процессора и памяти, а второй - к дисковой подсистеме и сетевым интерфейсам. Примером не слишком удачного соседства для терминального сервера является SQL Ser-ver, так как в этом случае возникает серьезная конкуренция за доступ к CPU и RAM. Во-вторых, на примере того же соседства можно наблюдать программную неуживчивость. Про-яв-ляется она в "привычке" Mi-cro-soft SQL Server при большой нагрузке захватывать 100% ресурсов CPU. Конечно, его мож-но сконфигурировать таким образом, чтобы он задействовал не все ресурсы сервера, но на практике это оказывается невозможно в однопроцессорных решениях и не всегда оправданно в двухпроцессорных. И в-третьих, при интенсивном взаимном обмене информацией между Terminal Server и другим серверным приложением в зависимости от характера и степени нагрузок работа на одном и том же физическом сервере может приводить как к повышению общей производительности, так и к ее существенному снижению. Если взять для примера то же соседство Terminal Server и MS SQL Server, то при малых и средних нагрузках и интенсивном взаимообмене общая производительность возрастает, а при больших нагрузках лучше запускать их на физически различных серверах. Ну и в-четвертых, окажется разумным оптимизировать аппаратную часть сервера терминалов под ту задачу, которая будет исполняться на сервере в терминальном режиме. По целому ряду технологических причин одним из лучших примеров "нерушимой дружбы" с сервером терминалов стал пакет "1С:Предпри--ятие 7.7". Работая в файловом режиме, каждый пользователь этого ПО открывает порядка 200 файлов форматов *.dbf и *.cdx (а в некоторых конфигурациях-- до 600). При среднем размере базы данных порядка 300 МВ и 5-10 активных пользователях (типичные характеристики небольшой фирмы) даже 100-мегабитные сети оказываются перегруженными. Кроме того, особенностью "1С:Предприятие 7.7" в файловом режиме является совместный доступ к файлам БД с разделением по времени. При таких условиях довольно частыми являются сбои в работе системы в результате захвата каким-либо пользователем таблицы данных на квант времени больший, чем тайм-аут для других пользователей, а отработать быстрее клиент "1С" не может, так как передача нескольких объемных файлов по ЛВС требует времени. Поставщики ПО "1С" в данной ситуации рекомендуют переходить на SQL-версии "1С:Предприятие 7.7" совместно с MS SQL Server, что требует совершенно иных затрат и решает проблему только частично - при количестве пользователей около 20 и объеме БД 1 GВ начинает сказываться недостаточная пропускная способность даже 100 Мbps ЛВС. В данной ситуации проявляется особенность реализации SQL-режима работы-- в большинстве случаев (зависит от конкретной конфигурации) SQL Server выступает в роли "умного" файл-сервера, и довольно большие блоки данных передаются на клиентские ПК, а на самом SQL Server выполняется только код, написанный с использованием языка запросов. (Нужно отметить, что в "1С:Предприятие 8.0" данный вопрос решен кардинально - применяется модель с выделенным сервером приложения, функционирующим отдельно от сервера БД.) И хотя в SQL-версии отключения пользователей по тайм-ауту происходят заметно реже и не приводят к повреждению индексных файлов и файлов данных, но на определенном этапе (большая БД или много пользователей) работать становится достаточно некомфортно. Кроме того, следует учитывать очень сильную неравномерность ("пиковость") уровня нагрузки, создаваемой пользователями при работе в "1С:Предприятие 7.7". Так что в реальной жизни для организаций, которым необходимо подключать к одной БД более 30-35 активных пользователей "1С:Пред-приятие 7.7", терминальный доступ - практически единственно возможное решение. В качестве довольно яркого примера можно рассмотреть применение "1С:Предприятие 7" в супермаркете, на кассах. При использовании стандартной конфигурации поставки (компонент "Оперативный учет") большинство тех, кто пытался внедрить такое решение, столкнулись с проблемой, что даже в SQL-режиме на двухпроцессорных серверах и ЛВС на Fast Ethernet при количестве касс 8-12 все начинает работать немного заторможенно. Традиционным, "прямым", решением являются установка более мощного сервера и переход на быстрые сетевые интерфейсы: Это частично решает вопрос, но необходимость подключения еще 4-6 касс приводит к повторению той же ситуации.
Microsoft Windows и Citrix MetaFrame Какие же пакеты для реализации терминального доступа к приложениям для платформы Windows на данный момент реально присутствуют на рынке? Во-первых, это несколько устаревшая, но продолжающая служить верой и правдой Windows 2000 Server и недавно вышедшие Windows Server 2003 и Citrix MetaFrame XP. Наиболее важные отличия между ними сведены в табл. 1. Из нее хорошо видно, какой большой шаг сделала Windows Server 2003 относительно Windows 2000 Server, в то же время прослеживается явное технологическое лидерство решения от Citrix. Важными эволюционными усовершенствованиями в Windows Server 2003 являются возможность "прозрачного" доступа к дискам, принтерам и портам клиентской машины, а также более высокие разрешения и количество цветов, поддерживаемых в терминальной сессии. Ведь для доступа к диску или принтеру клиентской станции в Windows 2000 Server необходимо было вначале сделать их доступными по сети для сервера, подключить к серверу как сетевой ресурс и только после этого работать с ресурсами из клиентской сессии. А отсутствие возможности общего доступа к порту исключало применение некоторого оборудования (например, считывателей штрихкодов), подключаемого к COM-порту. Повышение же разрешения и количества цветов позволяет нормально пользоваться ресурсами Internet и применять непрофессионально графические пакеты (например, для просмотра макетов) или AutoCAD.
В то же время нельзя не отметить существенных преимуществ Citrix перед решением от Microsoft. В серверной части среди них можно выделить следующие. Применяемый протокол связи Citrix ISA является более компактным и поэтому позволяет работать на каналах с меньшей пропускной способностью либо при той же ширине канала подключить в полтора-два раза больше пользователей. Этот момент может оказаться принципиальным для организаций, вынужденных использовать "слабые" каналы связи, и позволяет сэкономить всем остальным. Citrix Load Balancing (CLB) - механизм балансировки нагрузки между серверами - критичен для предприятий с большим количеством терминальных клиентов. Ведь наращивать мощность сервера до бесконечности невозможно, а реальный предел нагрузки для 2-4-процессорных серверов архитектуры х86 составляет 60-120 активных сессий. Даже при далеком от максимального числе пользователей весьма разумным выглядит переход к применению кластерных технологий. По сравнению с сервером надежность кластера существенно выше, а цена может оказаться ниже. И вот тут CLB предстает во всей красе. В отличие от аналогичной технологии от Microsoft CLB не ограничен восемью узлами в кластере, да и механизм распределения нагрузки у Citrix эффективнее. Будучи совершенно незаметным для пользователей, CLB оптимален для построения высокомасштабируемых (более 400 активных пользователей) отказоустойчивых кластерных решений. Вопрос же появления новых 50-80 клиентов решается добавлением еще одного узла в стойку. Кроме того, серверная составляющая Citrix менее ресурсоемка и удобнее в администрировании. Определенные преимущества имеются и в клиентской части. Она также менее ресурсоемка и удобнее в администрировании, использует более компактный протокол. Благодаря различным элементам тонкой настройки есть возможность максимально задействовать ресурсы самого клиента, тем самым снизив загрузку сервера. На клиентской станции может быть запущена и часть сервисов. Из наиболее востребованных функций стоит отметить печать прямо на подключенный к клиентской системе принтер (в то время как Windows Server вынужден передавать готовый образ в формате PCL или PS), что заметно снижает нагрузку на каналы связи и ускоряет работу. А для удаленного клиента (к примеру, КПК), подключенного к корпоративной системе через GSM/GPRS-интерфейс, это очень важно. В качестве примера можно привести таблицу, описывающую возможности работы различных решений с низкоскоростными интерфейсами (табл. 2).
Одним же из самых важных различий между терминальными решениями на базе Windows 2000 Server и Windows Server 2003 является несравнимо возросшая стабильность работы сервера. У Windows Server 2003 не было замечено утечек памяти в терминальные сессии и после терминальных сессий, что позволяет отказаться от ежемесячных перезагрузок сервера (или использования специализированного ПО). Не менее впечатляет и рост стабильности терминального клиента от Windows Server 2003 - при его применении совместно с Windows 2000 Server существенно снижаются утечки памяти на сервере и увеличивается устойчивость работы сервера вообще. Это действительно большой прогресс, отдадим должное Microsoft.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||