Семь великих сетевых битв

1. Пропускная способность или QoS.

2. Java vs .Net. (Sun vs Microsoft на рынке распределенного ПО).

3. Службы каталогов масштаба предприятия.

4. Linux против титанов операционных систем.

5. IP PBX или шлюз VoIP?

6. Cтандарт передачи данных для хранения по IP.

7. Управление сетями: интегрированные системы или отдельные продукты.

Java vs .Net

Автор: Даниил Фертф

Sun и Microsoft яростно соперничают на рынке распределенного ПО. Обе компании оказывают все возрастающее давление на IT-менеджеров предприятий, чтобы те выбирали соответственно Java или .Net - технологии этих компаний для построения распределенных Web-приложений.

Технологии Microsoft отнюдь не являются доминирующими при построении Web-систем, как это порой стараются представить маркетологи корпорации. По оценке фирмы Giga Information Group, занимающейся исследованиями рынка, от 35 до 40% заказчиков применяют продукты Microsoft для небольших коммерческих Web-сайтов. Как правило, используются операционные системы Windows NT и Windows 2000 Datacenter, встроенные службы сообщений и транзакций, Visual Basic и Visual C++, Component Object Model и Microsoft API. Однако для сайтов с интенсивным трафиком и большими объемами транзакций эта доля, согласно Giga Information Group, падает до 20%. Здесь доля Unix-серверов и Java почти в два раза больше и продолжает расти. Microsoft здесь явно проигрывает, так что ей есть о чем беспокоиться. Судя по всему, в результате этого беспокойства и появилась стратегия .Net.

Схватка Sun с Microsoft начала разгораться примерно в середине 2000 года. Именно тогда Microsoft обнародовала свою стратегию .Net. Как заявлено, .Net включает в себя четыре технологических направления. Первое из них - это Visual Studio.Net вместе с .Net Framework и новым языком под названием C#. Этот новый язык основан на C и C++ и, подобно языку Java, использует виртуальную машину. Второе - это корпоративные серверы .Net с новыми версиями продуктов, например Microsoft SQL Server. Они служат для выполнения прикладных программ .Net и управления ими. Третье направление - это набор многофункциональных служб на основе .Net, таких как Microsoft Passport, которая хранит номера кредитных карточек и прочую персональную информацию. Эти службы призваны избавить пользователя от необходимости вводить свои данные для каждой транзакции. И последнее направление - это Windows, Office и другое клиентское ПО на всем спектре конечных устройств для конечных пользователей, включая PDA и сотовые телефоны. Microsoft надеется, что .Net привлечет внимание всех пользователей, которые будут переходить на следующий уровень развития Web. Ей уже удалось добиться неожиданно высокого доверия опытных программистов к своей стратегии .Net, которая пока обнародована только частично.

Окончательные версии всех технологий .Net должны появится в 2001 году, но из того, что заявлено, на сегодня сделано немного. Доступны пока только бета-версия комплекта инструментов Visual Studio.Net., несколько корпоративных серверов и технология программирования серверных систем ASP+ (см. "Сетевые шаги Microsoft", "Сетевой журнал", № 1/2001).

Первоначально Visual Studio.Net будет использоваться для построения программ, предназначенных для работы в операционных системах Microsoft. Правда, Microsoft заявляет, что в конечном счете разработчики ПО на основе технологий .Net смогут писать программы на нескольких языках, а не только на C#. Чтобы это стало возможным, Microsoft планирует встроить в архитектуру .Net язык XML для описания данных и обмена ими через Интернет, а также другие стандарты Web, такие как протокол SOAP (Simple Object Access Protocol - упрощенный протокол доступа к объектам; читайте о нем в следующем номере "Сетевого журнала").

Язык Java, несмотря на быстрое развитие в последние пять лет, еще не интегрирован с XML и другими ключевыми стандартами Web. Однако у Java есть серьезное преимущество, поскольку Sun выпустила Java точно в тот момент, когда возникла необходимость в подобной технологии (некоторые считают, что даже немного раньше, но это не принципиально), а Microsoft снова явно опоздала. Сегодня для Java доступно множество средств разработки и этот язык лежит в основе многих прикладных серверов, например WebLogic фирмы BEA Systems. Эти серверы, на которых работают Java-компоненты, успешно работают как посредники между браузерами клиентов и внутренними корпоративными базами данных.

Рекомендации на будущее. Если Java продолжит свое столь стремительное развитие, то Microsoft будет крайне трудно перехватить у Sun инициативу. "Если бы я работал только с решениями Microsoft, то в качестве платформы я бы со временем выбрал.Net, - говорит Грег Дюпертьюс (Greg DuPertuis), президент фирмы The Adrenaline Group, которая разрабатывает Web-приложения. - Но мы будем продолжать работать с Java-программами на серверах Linux и Solaris. Мы может делать это, поскольку знаем, что использующие .Net смогут взаимодействовать с ними". Это и есть наиболее правильная стратегия -- ставьте на совместимость и взаимодействие, а не на технологию какой-либо компании.

Такое взаимодействие будет возможным в будущем, когда программы станут "службами" - идея, которую сегодня защищают и Microsoft, и Sun. В рамках этой модели обращение к функциям программ-служб производится через Интернет с использованием стандартных форматов, скажем XML, и стандартных протоколов типа HTTP. Совместимость должна улучшиться благодаря новым стандартам, таким как UDDI (Universal Description, Discovery and Integration - универсальное описание, поиск и интеграция; см. "Проект UDDI", "Сетевой журнал", № 1/2001), XML и SOAP. Вы сможете создать программу или службу и зарегистрировать через UDDI в оперативном реестре. После этого любая другая программа может сделать запрос к этому реестру через XML, потом запросить объект, при помощи SOAP обратиться к нему и через XML обменяться с ним данными.

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

Вы примете правильную стратегию, если не будете связывать судьбу только с Sun или только с Microsoft. Используйте те средства, которые представляются вам правильными при данных вложениях в технологию и данных целях бизнеса.

Службы каталогов масштаба предприятия

Автор: Глеб Галкин

Конфликт по поводу служб каталогов -- это не только проявление конкуренции между Microsoft Active Directory и Novell eDirectory (прежнее название - NDS), как вы могли бы подумать. Это было бы слишком просто.

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

Но только на словах. Подавляющее большинство IT-менеджеров испытывают огромные трудности со службами каталогов. Согласно общему мнению пользователей и аналитиков, проблема состоит в том, что службы каталогов по отношению к сетям развиваются с запозданием, оставляя пользователей в настоящем сетевом аду. "С развитием этой области в каждой программе будут встроенные возможности работы со службами каталогов, - объясняет Дэниел Блам (Daniel Blum), старший вице-президент The Burton Group. - Но пока прикладные программы работают с дублирующейся или каким-то образом взаимосвязанной информацией в разных каталогах. В крупной компании порой больше сотни объектов, которые можно было бы назвать каталогами, и ваше имя найдется в 20, а то и в 50 из них".

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

Правильным было бы использование служб каталогов общего назначения, например eDirectory или Active Directory, и во многих случаях это действительно так. "Цель службы каталогов масштаба предприятия, такой как eDirectory, проста, - объясняет Чип ди Комо (Chip DiComo), менеджер по глобальным сетям фирмы Hellmann Worldwide Logistics, которая уже давно распространяет продукты Novell. - Это единый источник всего в вашей сети. Он дает вам единое место для управления всей информационной средой, что необходимо для глобальных действий". Служба каталогов используется в первую очередь потому, что она устанавливает единое место хранения (называемое также репозиторием) для информации, которая используется для аутентификации и установления различных компонентов, а также для прослеживания и администрирования привилегий доступа к этой информации для пользователей и приложений. Репозиторий с доступом к службам, серверам, системам баз данных и другим приложениям должен обеспечивать постоянную связь между пользователями (или серверными приложениями) и определенной службой приложения, иначе его наличие не имеет смысла.

В теории опять все красиво, однако объединить множество отдельных каталогов в нечто типа Active Directory или eDirectory отнюдь не просто. "Это большая перестройка, - говорит Блам. -- Каталоги, которые требуется объединить и интегрировать, выполняют массу функций на предприятии. Это кадровые вопросы, защита, работа с заказчиками и информация. Такой проект требует множества разноплановых усилий". Добавьте сюда еще интеграцию новых прикладных программ, и задача организации единых каталогов предстанет во всем своем масштабе.

Но это только полбеды. Главную проблему составляют сами производители служб каталогов. "Даже те поставщики, которые давно занимаются каталогами, никак не могут выработать для них прочную основу, - жалуется Дэйв Кернс (Dave Kearns), IT-консультант из Остина. - Последняя поставляемая версия Exchange использует другую структуру каталогов по сравнению с Windows 2000, а последняя версия GroupWise - другую систему каталогов по сравнению с eDirectory. В обоих случаях приходится как-то синхронизировать их, а это не то, что хотелось бы иметь". Пользователи согласны с этим. "Я устал твердить об этом поставщикам", - говорит ди Комо.

Но и это еще не все проблемы. Кроме недостаточно четкого понимания нужд пользователей, разработчики еще и не решаются во всем полагаться на службы каталогов. "Разработчики до сих пор не хотят ориентироваться на то, что каталог общего назначения будет доступен при установке их продукта, - сетует Кернс. - И даже если такой каталог есть, они не уверены, что смогут читать этот каталог и писать в него. Они предпочитают перестраховываться". В некоторых случаях это приводит к старому варианту, когда в каждый продукт включаются собственные службы аутентификации и ведения каталогов. Иногда компании пытаются обезопасить себя с помощью протокола LDAP (Lightweight Directory Access Protocol).

Выбор LDAP означает, что прикладные программы смогут использовать любой из основных LDAP-совместимых каталогов, например eDirectory, Active Directory, Directory Server фирмы iPlanet (бывший Netscape Directory Server, теперь разрабатываемый совместно с Sun) или InJoin фирмы Critical Path. Но и этот выход плох. Проблема в том, что для LDAP не установлено жесткого стандарта и каждый из основных разработчиков вносит в этот протокол собственные усовершенствования. "Разработчики могут полагаться на LDAP, если им просто нужно получать только некую базовую информацию, стандартизованную для различных LDAP-каталогов, - говорит Блам. - Но если они хотят большего, они рискуют нарваться на серьезные проблемы".

Разработчикам прикладных программ вся эта катавасия тоже добавляет много проблем. Решения поставщиков служб каталогов различаются в основном по способу внесения изменений в схему каталога и управления разрешениями на доступ. "Если разработчикам надо создавать нестандартные информационные структуры и менять схему каталога, они вынуждены ориентироваться на определенного поставщика служб каталогов, - объясняет Блам. - А когда им нужны специальные списки защиты для управления данными прикладных программ, им приходится работать с системами управления доступом каталога. Все это означает, что разработчики должны выбрать определенную службу каталогов. Необходимость ориентироваться на три - четыре различных каталога существенно усложняет работу. И когда неизвестно, какой каталог будет стоять у пользователя, некоторые разработчики могут поддаться соблазну легкого пути - реализации собственных функций каталога".

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

Но еще важнее стандартизовать возможности, которые выходят за рамки чистого LDAP. "Однако в этом направлении нет никакого реального продвижения, - говорит Блам. - Microsoft даже не участвует в работе комитета Internet Engineering Task Force по управлению доступом и репликацией. А без этой компании шансы на установление стандарта невелики". Незаинтересованность Microsoft в работе над единым открытым стандартом понятна, ведь компания всячески продвигает свой вариант интерфейса -- ADSI (Active Directory Services Interface, см. врезку "Интерфейс ADSI").

Единственная область стандартизации, которой, видимо, занимаются все поставщики, - это XML и его расширение для работы с каталогами - DSML (Directory Services Markup Language). "XML - определенно хорошая возможность для интеграции, - считает Блам. - Он позволяет программам легче связываться с каталогами. Вместо того чтобы передавать сами данные, ваши программы и каталоги будут обмениваться метаданными, т. е. данными о данных". Блам полагает, что это повысит совместимость каталогов. "Однако, - добавляет он, - кто-то, опять же, должен стандартизировать эти метаданные". В настоящее время основные поставщики служб каталогов участвуют в работе группы DSML.org, которая разрабатывает такие стандарты. "Они продвигаются вперед, но до нашего идеала, когда каталоги станут прозрачными для программ, им еще далеко", - говорит Блам.

Рекомендации на будущее. Увы, но пользователям остается работать с тем, что есть, и требовать от разработчиков, чтобы они поддерживали по крайней мере LDAP, а от поставщиков служб каталогов -- большей последовательности и решительности. Не поддавайтесь на давление Microsoft по поводу Active Directory и ADSI. Деятельность DSML.org может привести к успеху. Принятие содержательного стандарта типа DSML существенно улучшит ситуацию с интерфейсом к службе каталогов. Надежда на лучшее есть, но страдания пользователей могут продлиться еще какое-то время.

Интерфейс ADSI

ADSI -- Active Directory Services Interface - это разработанная Microsoft спецификация интерфейса для Active Directory. ADSI представляет собой не слишком сложный (если вы знакомы с технологией COM, которая используется для компонентов ActiveX, вы сможете легко освоить ADSI), и в то же время очень мощный объектно-ориентированный интерфейс. Причем это заявка на значительно большее, чем просто интерфейс к одной из служб каталогов. Подобно LDAP и в отличие от обычных интерфейсов служб каталогов, ADSI построен как общий интерфейс служб каталогов, абсолютно не зависящий от конкретной службы или языка программирования. Естественно, ADSI очень хорошо работает с Active Directory благодаря гибкости в определении объектов.

ADSI позволяет вам отделять объекты и интерфейсы от самой службы каталога, на базе которой они функционируют. Структура ADSI базируется на модели COM, разработанной Microsoft. Для определения, просмотра и расширения объектов ADSI используется инструмент Schema Management, позволяющий администраторам модифицировать классы контейнерных объектов, свойства объектов и объекты синтаксиса. Помимо абстрактного слоя, ADSI предоставляет несколько однородных COM-объектов и интерфейсов.

ADSI позволяет программистам разрабатывать приложения для работы с каталогом с помощью инструментов высокого уровня, таких как C, Visual Basic и Java. Более того, ADSI обеспечивает полную поддержку сценариев, так что вы можете работать с ним посредством VBScript, JavaScript или Perl. Многие администраторы предпочитают эти сценарии полноценным языкам программирования.

ADSI поддерживает расширения схем от сторонних производителей, так что разработчики программного обеспечения могут создавать собственные свойства объектов для своих конкретных приложений. Это означает, что потенциально ADSI не ограничивается Active Directory -- это открытая среда, в которую можно добавлять поддержку других типов каталогов, неважно, базируются ли они на доменах NT, NDS или на чем-либо еще. Таким образом, вы можете применять один и тот же программный код сразу для всех служб каталогов, для которых разработан провайдер ADSI.

Протокол LDAP

Первоначально LDAP -- Lightweight Directory Access Protocol -- был разработан в Мичиганском университете как упрощенный метод доступа клиентов для X.500-серверов. Вскоре LDAP привлек такое большое внимание, что была учреждена группа стандартизации под покровительством Internet Engineering Task Force (IETF), в которую тогда вошли и представители Microsoft. Вторая версия LDAP (RFC 1777 и RFC 1778) описывала, как клиент и сервер могут обмениваться X.500-посланиями через сеть TCP/IP. LDAP 2 не мог управлять взаимодействием сервер -- сервер между различными каталогами, но последняя, третья версия протокола LDAP (RFC 2251) исправила этот недостаток. LDAP 3 включила спецификации для протокола реплицирования и для взаимодействия между каталогами с различными схемами. Кроме того, в LDAP 3 встроена возможность взаимного изменения каталогами схем друг друга посредством LDAP-сообщений. Как утверждает Microsoft, серверная часть ее реализации LDAP подходит для управления синхронизацией каталогов и взаимодействия с другими приложениями (а также другими операционными системами и службами каталогов). Сегодня поддержка LDAP 3 фактически стала стандартом среди служб каталогов.

Пропускная способность или QoS

Автор: Даниил Фертф

Уже пару лет вопрос стоит так: что лучше, увеличивать пропускную способность сети, чтобы обслуживать растущие запросы программ, или добавлять механизмы повышения качества обслуживания? Однако, похоже, споры заканчиваются.

Аргументом в пользу QoS всегда было то, что определенные типы трафика, такие как голос и видео, должны пропускаться через сеть без задержек. Поэтому подобные пакеты приложений реального времени должны получать более высокий приоритет, чем остальные данные, чтобы гарантировать их передачу. Аргумент против QoS - если пропускной способности достаточно, назначение приоритетов не требуется. Каждый пакет и так получит необходимую ему часть полосы пропускания.

Последний аргумент особенно убедительно звучит для локальных сетей, так как здесь быстрое распространение Gigabit Ethernet при постоянно снижающихся ценах обеспечивает настольным компьютерам и серверам больше пропускной способности, чем они могут переварить. "Трудно найти такое сетевое оборудование, которое не давало бы избыточной пропускной способности, - говорит Стивен Хоуп (Stephen Hope), консультант по сетям компании Energis Integration Services. - Даже оборудование начального уровня обеспечивает достаточную скорость". "Большинство наших заказчиков руководствуется принципом чем больше, тем лучше,- подтверждает Брайан Стенгел (Brian Stengel), исполнительный вице-президент компании IntelliNet, предоставляющей услуги по управлению сетями. - Они определили, что при большой пропускной способности гораздо проще управлять сетью, планировать использование прикладных систем, разрабатывать и устанавливать сетевые средства и работать с обслуживающими организациями или внутренним персоналом".

Аргументы в пользу QoS продолжают оставаться в силе для глобальных сетей, где пропускная способность часто близка к пределу и существенно дороже, чем в локальных. Но и это постепенно меняется. "Приобретение дополнительной пропускной способности на каналах связи вместо QoS-устройств лучше отвечает целям нашей фирмы, - говорит Дэйв Буджейсайюс (Dave Bujaucius), старший IT-менеджер биотехнологической фирмы Gliatech. - Мы обнаружили, что для окупаемости вложений в QoS потребуется несколько лет, так что мы просто приобрели дополнительную пропускную способность". Скорости передачи данных по одному каналу оптоволокна удваиваются каждый год, а число каналов, которые поставщики могут передавать по одной оптоволоконной линии, удваивается за два года. Это означает, что цены, без сомнения, будут быстро падать, так как пропускная способность дешевеет, а конкуренция между телекоммуникационными компаниями приводит к необходимости еще большего снижения цен. Пропускная способность глобальных сетей растет очень быстро благодаря "оптической революции в сетях", как отмечает Дэйв Пассмоур (Dave Passmore), директор по исследованиям The Burton Group, и в ближайшие несколько лет при снижающейся цене станет доступно много новых возможностей. Такое явление, видимо, наблюдается повсюду, кроме отдаленных районов, куда оптоволокно нельзя протянуть достаточно быстро.

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

Но вопрос качества нельзя отбросить так просто. Даже когда доступна избыточная пропускная способность, но нет QoS, есть вероятность, что передача файлов будет порой мешать голосовому и видеотрафику. Это происходит потому, что протокол TCP был разработан для использования всей доступной пропускной способности для любой задачи, полагает Майк Басс (Mike Bass), главный инженер по проектированию сетей крупной телекоммуникационной компании. "Независимо от того, какая у вас пропускная способность, за сутки бывает несколько пиков нагрузки продолжительностью, возможно, в считанные секунды, - поясняет он. - Если в этот момент идет передача голоса, звонящий может услышать пропуски или несколько секунд тишины". И очень многие пользователи соглашаются на это.

Рекомендации на будущее. Если вы собираетесь передавать по сети голос и видео вместе с данными, самым благоразумным будет сочетание обоих подходов. Вместо того чтобы создавать восемь уровней QoS для трафика различной важности, ограничьтесь двумя: один для голоса и видео, другой для всего остального. Одновременно продолжайте наращивать пропускную способность. При таком подходе сложность управления и обслуживания растет не очень сильно и в то же время пики нагрузки не мешают телефонным разговорам. "В наших планах - использовать QoS для голоса и не дифференцировать уровни QoS для данных, - говорит Майкл Аллен (Michael Allen), менеджер информационных служб города Визалии. - Если бы мы передавали только данные, мы бы не связывались с QoS".

Linux против титанов операционных систем

Автор: Глеб Галкин

Для Linux, операционной системы с открытым кодом, 2000 год стал рекордным. Одна за другой ее поддержали ведущие компании IT-индустрии, в том числе IBM, Dell Computer и Oracle. Но даже при этом Linux пока не нашла дороги на корпоративный рынок.

Нельзя сказать, что показатели Linux были плохими. В 1999 году это была вторая по объему продаж после Windows NT операционная система для серверов (24,6 и 38,1%, согласно данным IDC). Linux потеснила Novell NetWare и все другие клоны Unix, которым досталось меньше чем по 20% рынка. IDC предсказывает, что Windows и Linux не уступят соответственно первое и второе места вплоть до 2004 года.

И если Linux все же суждено вторгнуться на предприятия, то надлежащая репутация у этой системы уже есть. Впервые солидного прорыва в этом направлении Linux добилась с IBM, которая обнародовала свою стратегию в отношении данной ОС в конце 1999 года. В течение 2000 года IBM вложила в Linux $200 млн., и теперь она доступна для всей линейки серверов компании - от мейнфреймов до PC. IBM также адаптировала для Linux такие свои программные продукты, как DB2 Universal Database и система для электронной торговли WebSphere. По словам Дана Фрая (Dan Frye), директора программы по Linux фирмы IBM, в 2000 году Linux явно добилась решительного прорыва. В 1998 году Фрай написал первый отчет по Linux для IBM, а через год принял участие в разработке амбициозной стратегии фирмы в отношении Linux. "В начале 2000 года в IBM над Linux работало 15 инженеров, а сейчас их больше 100. Linux теперь такая же часть стратегии IBM в отношении серверов, как AIX и OS/400", -- говорит он.

Кроме IBM, теперь Compaq, Dell и Hewlett-Packard продают предустановленную Linux на Intel-серверах и осуществляют ее техническую поддержку. Главные поставщики приложений масштаба предприятия, Oracle и SAP, адаптировали для этой платформы свои основные программы.

Плюсы

Для тех, кто рассчитывает на Linux, положительными моментами являются цена, надежность и гибкость. Разработчики могут загружать дистрибутивы Linux из Интернета бесплатно, а IT-менеджеры могут купить версии для предприятий у таких компаний, как Red Hat и Caldera, меньше чем за $200 (сравните с Microsoft Windows 2000 и Novell NetWare 5, которые стоят до $4000 и $11 000 соответственно). Поскольку Linux лицензируется на условиях общедоступности, у нее нет ограничений на число пользователей, связанных с сервером, или на число серверов, на которых может быть установлена одна копия.

Приверженцы открытых кодов и Linux, например Фрай из фирмы IBM, утверждают, что открытое тестирование Linux уменьшает число ошибок в коде и делает ее более надежной по сравнению с коммерческим программным обеспечением. Кроме того, Linux, как система с открытым кодом, легко подвергается изменениям. Для обеспечения необходимых функций разработчики могут вносить в исходный программный код любые изменения. Возможность изменения программного кода сервера для многих крайне важна. Так, Морис Смайли (Maurice Smiley), системный администратор фирмы Gulf State Engineering, уже два года эксплуатирует в компании Red Hat Linux на файл-сервере, сервере печати, Интернет-сервере и сервере баз данных. "Для нас важна открытость Linux; если не нравится, как что-то работает, это легко исправить. Практически ни одна из наших систем не использует оригинальное ядро Red Hat. Мы берем последнюю версию ядра и рекомпилируем его в соответствии с потребностями", - рассказывает Смайли.

Минусы

Однако Смайли полагает, что у открытости есть и обратная сторона. "Стандартам не хватает необходимой жесткости", - говорит он, добавляя, что дистрибутивы Linux могут значительно различаться не только у разных поставщиков, но даже и в разных версиях программного обеспечения у одной и той же компании. "Открытость Linux - один из многих факторов, которые не позволяют Microsoft рассматривать Linux в качестве серьезного конкурента на рынке больших предприятий", - считает Дуг Миллер (Doug Miller), директор группы Windows-серверов компании Microsoft. Но Miller признает, что Linux может потеснить Microsoft на рынке систем низшего класса.

Действительно, масса компаний типа Gulf State Engineering использует Linux. Но это относительно небольшая компания, ее Linux-серверы поддерживают меньше 300 пользователей. И такое положение дел можно назвать типичным. Однако в больших компаниях Linux в настоящее время в основном используется для того, что называется инфраструктурой или фоновыми задачами: файловая служба, служба печати и Интернет. "Linux еще просто не готов для обслуживания всех частей предприятия. Если у вас действительно большое предприятие, которому требуется компьютер с 16- или 32-канальной SMP (симметричной многопроцессорной обработкой), то Linux не для вас. Решением остается Unix", - соглашается Фрай.

Однако, по словам Джона Холла (John Hall), директора Linux International, некоммерческой группы, координирующей усилия по разработке Linux, пользователи обходят ограничения SMP. Некоторые правительственные исследовательские агентства, например Sandia National Laboratories и Human Genome Project, используют серверы Linux, кластеризованные по технологии Beowulf, для выполнения таких суперкомпьютерных задач, как моделирование ядерных взрывов и составление карты человеческой ДНК. Коммерческие кластерные программные продукты Linux поставляются такими компаниями, как Linux NetworX, Red Hat и VA Linux.

И все же большинство специалистов считают, что Linux до сих пор малопригодна для вычислительных задач больших корпораций (в том числе ведения "журнальной" файловой системы всего предприятия с записью данных на диски большой емкости), для развитых средств управления системой и ей недостает надежной поддержки производителей периферийного оборудования. "Linux-серверы используются широко, но не для приложений уровня предприятия. Никто не собирается выкидывать существующие системы и заменять их на Linux", -- полагает Дан Куснецки (Dan Kusnetzky), сотрудник IDC. Это была бы слишком крупная перестройка.

Майкл Мак-Вог (Michael McVaugh), старший системный аналитик компании Sunoco, соглашается, что полная замена систем требует слишком больших усилий. В штаб-квартире Sunoco Маквог управляет более чем 150 серверами с Windows NT, поддерживающими почти все аспекты бизнеса этой газовой компании. "Есть у нас несколько человек, присматривающихся к Linux, но все это неофициально", - говорит Маквог. Он отмечает, что Sunoco требуется что-нибудь вроде подхода Microsoft с упрощенным управлением серверами и прикладными программами, поскольку квалификация сотрудников оставляет желать лучшего, но добавляет, что по мере обучения она улучшается.

Рекомендации на будущее. Аналитики в один голос предсказывают продолжение роста Linux, но утверждают, что она никогда не займет доминирующего положения в корпоративном секторе. Это значит, что Linux будет продолжать оставаться дешевой альтернативой Unix для небольших задач и конечных пользователей, но не сможет решить всех проблем IT.

Переход с Windows NT или NetWare на Linux для большинства организаций маловероятен. И дело отнюдь не только в том, что это было бы настоящим переворотом для компании. После первоначальной экономии на низкой цене дистрибутива Linux затраты на поддержание сети на ее основе становятся такими же, как и при работе с любой другой ОС.

Кроме того, по словам Билла Клейбрука (Bill Claybrook), директора исследовательского отдела Aberdeen Group, хотя для Linux в настоящее время существует много мест по обучению и сертификации, найти квалифицированного IT-профессионала -- задача непростая.

IP PBX или шлюз VoIP?

Автор: Даниил Фертф

Эволюция или революция? IP PBX или шлюз VoIP? Вот главный выбор, который следует сделать, решив использовать передачу голоса по IP в корпоративных сетях. Традиционные поставщики PBX, такие как Nortel Networks, строят на базе шлюзов сочетание старого и нового подходов, в то время как Cisco и ее IP-силы пытаются организовать полный переворот.

Несколько лет эти дебаты шли в теоретическом плане, однако в 2000 году, когда объем продаж IP PBX начал расти, перешли в практическую область. Cisco начала поставки своей платформы AVVID (Architecture for Voice and Integrated Data) - первого IP PBX корпоративного класса - в середине 1999 года. Успешно продает свои продукты NBX для малого и среднего бизнеса компания 3Com. По подсчетам фирмы Synergy Research Group, занимающейся исследованиями рынка, со второго квартала 1999 года до второго квартала 2000-го объем продаж LAN-телефонии вырос с $2,9 млн. до $40,7 млн. "Мы слышали все больше жалоб от традиционных поставщиков PBX в третьем квартале 2000 года, когда угроза со стороны новых конкурентов стала реальной, - говорит Джереми Дьюк (Jeremy Duke), президент Synergy. - Эта технология окажет разрушительное влияние на рынок, и большую часть бизнеса PBX ждет застой или даже упадок".

Шлюзовой подход к передаче голоса по IP в корпоративных сетях более осторожен и постепенен, он сохраняет вложения в традиционные платформы PBX и усиливает их признанную стабильность и надежность уровня "пять девяток". При этом PBX продолжает обрабатывать вызовы, а функциональность линий передачи переносится в сеть IP. Шлюзовая плата в вашем PBX сжимает и разбивает на пакеты голос для передачи по IP и работает как прокси-сервер для IP-телефонов, подключаемых к Ethernet. Шлюзовая плата с 24 портами может поддерживать до 96 таких телефонов, так что вы можете получить от PBX больше, переводя пользователей на передачу голоса по IP.

В отличие от этого, системы IP PBX заменяют центральную коммутирующую фабрику в традиционном PBX и переносят обработку вызовов на сервер - обычно Windows NT. Обработка вызовов и функции PBX, такие как переключение, транкинг и вызов станции, могут распределяться по различным платформам или даже выноситься наружу системы. Естественно, такая гибкость означает повышение сложности и расходов на интеграцию.

Вообще говоря, "LAN PBX" более точный термин, чем "IP PBX", поскольку некоторые из этих коммутаторов используют "родные" возможности Ethernet. Сторонники традиционных PBX ставят под вопрос надежность инфраструктуры данных, но признают, что правильно сконфигурированные сети Ethernet с современными коммутаторами достигают той же степени работоспособности - 99,999% - что и голосовые сети. Слабое место здесь - сервер NT, который работает нестабильно и требует регулярной перезагрузки. Традиционные PBX по сравнению с этим - закрытые системы, однако могут работать без перезагрузки неопределенно долго и допускают исправление без перерыва в обслуживании.

Эволюционный подход

Фирма Symantec, чье основное внимание сейчас сосредоточено вокруг удаленных компьютеров, придерживается эволюционных взглядов и принимает шлюзовой подход. Сама фирма расположена в центре Силиконовой долины, где трафик в часы пик растет головокружительно, и ей нужен был способ обеспечения всех возможностей традиционных PBX для большого числа сотрудников, работающих из дома по линиям DSL. Поскольку у Symantec есть голосовая сеть, куда входят более 40 PBX фирмы Nortel по всему миру, Symantec решила провести тестирование шлюзовой платы Nortel для передачи голоса по IP удаленным сотрудникам. В каждом доме был установлен небольшой хаб, к которому подключались и компьютеры, и телефоны, голос и данные передавались одновременно по одному соединению DSL, так что для данных не требовалась вторая линия. У сотрудников был один и тот же телефонный номер в офисе и дома, и когда на корпоративную PBX поступал вызов, оба телефона звонили одновременно.

Локальный и удаленный IP-телефоны поддерживали одинаковые функции, в том числе переадресацию вызовов, конференц-связь и индикаторы ожидающих сообщений. Кроме того, шлюзы VoIP обеспечили четырехкратную портовую емкость по сравнению с традиционной платой в PBX, так что Symantec использовала их и для расширения. "Это большая экономия, когда можно не покупать еще одно устройство PBX", - говорит Нил Коул (Neil Kole), директор Symantec по связи и инжинирингу. Расходы сокращаются также благодаря тому, что устанавливать и перемещать телефоны несложно. "Вы просто включаете их в разъем, - объясняет он. - Для обычных телефонов нужен человек с определенным опытом, который переложил бы кабель или перепрограммировал PBX". По его словам, последний апгрейд устранил все претензии к качеству передачи голоса по IP, и теперь нет никаких оговорок относительно развертывания системы.

Чтобы сделать обоснованный выбор, Symantec испытала и IP PBX. "Мы немного пробовали IP PBX, но у нас вызывают сомнение вопросы надежности. Даже если бы я начинал с нуля в новом офисе филиала, я бы выбрал PBX со шлюзовой платой для передачи голоса по IP на настольные системы", - говорит Коул.

Революционный подход

Многие, напротив, не приемлют половинчатого подхода. Например, Министерство социальной политики Новой Зеландии недавно заменило национальную сеть из 160 PBX фирмы Nortel на систему, использующую технологию VoIP на основе платформы AVVID фирмы Cisco. Эта инфраструктура поддерживает около 8000 IP-телефонов в двух сотнях правительственных офисов и обслуживает более 150 000 телефонных звонков в день. Если не считать внутренней сети Cisco, это самая крупная система на платформе AVVID в мире. "Телефония становится системой, - объясняет Нэйл Миранда (Neil Miranda), координатор министерства. -- Как не имеет смысла реализовать наполовину новую социальную или финансовую систему, так не стоит поступать подобным образом и с телефонной системой". Решение использовать только IP-телефонию было принято, когда правительство постановило расширить министерство с шести до восьми тысяч сотрудников, но при этом не увеличило финансирование инфраструктуры. Объединение голоса и данных в одну инфраструктуру, видимо, было единственным способом добиться требуемой экономии.

Сеть была развернута за три месяца, обучение конечных пользователей не потребовалось, и Миранда утверждает, что его персонал получает меньше жалоб, чем с прежней PBX. "Кроме выгод от того, что у нас единая сеть, мы получили и много новых возможностей. Я выступал на последней CIO-конференции и сказал специалистам по IT, что им надо переходить на эту технологию", - говорит он.

Рекомендации на будущее. Для передачи голоса вовсе не обязательно выбирать какое-либо одно решение. Официальная риторика сильно поляризована, но на самом деле оба лагеря страхуют свои риски, расширяя диапазон своих продуктов. Компания Cisco - главный защитник идеи IP PBX, но также и ведущий поставщик голосовых шлюзов. Nortel разрабатывает собственную линию IP PBX. События вполне могут развиваться по пути мирного сосуществования. Если вы достигли максимальной емкости имеющейся сети PBX, ее можно нарастить при помощи IP PBX и использовать старую и новую платформы вместе. В зависимости от ваших потребностей можно использовать и IP PBX, и шлюзы VoIP.

Cтарший аналитик IDC Пол Штраусс (Paul Strauss) дает некоторые советы и предостережения:

Интегрированные беспроводные сети

В некоторых случаях применение VoIP-шлюзов может быть более практичным, чем IP PBX. Фирма Symbol Technologies нашла удачную рыночную нишу - передача по беспроводным каналам голоса и данных там, где требуется мобильность пользователей, например в торговых центрах и в больницах. Базовые станции устанавливаются на стенах, образуя микросоты, с которыми связываются беспроводные телефоны, PDA и карманные компьютеры. Symbol совместно с поставщиками голосовых шлюзов работает над тем, чтобы как можно более гладко связать свою беспроводную сеть передачи голоса и данных со стандартной PBX. Торговые фирмы, такие как Rite-Aid, Sears и May, считают эту систему идеальной для связи с персоналом, перемещающимся по торговым залам. Персонал больниц использует беспроводные устройства для ввода данных о пациентах и доступа к информации из любой точки.

Cтандарт передачи данных для хранения по IP

Автор: Даниил Фертф

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

Проектов было много, но обозреватели предсказывают, что в конечном счете за раздел рынка будут бороться три предложения:

По общему мнению, новые предложения по хранению данных в сети, даже если они будут приняты в качестве стандарта, не имеют никаких шансов.

В стычках по поводу стандартов передачи данных на хранение по протоколу IP поставщики, ранее объединявшиеся для создания конечных систем хранения данных, часто оказываются по разные стороны баррикад. Некоторые готовы принять iSCSI, другим больше нравится Fibre Channel over IP, а третьи вообще не предпринимали никаких действий. Разбираться в этой свалке любезно предоставлено пользователям.

Защитники предложения iSCSI - это его разработчики: Adaptec, Cisco, Hewlett-Packard, IBM, Quantum и SANgate. iSCSI задает способ передачи по TCP данных, находящихся на SCSI-устройствах. Технология iSCSI не вносит изменений в каналы связи или в инфраструктуру сетей, а только требует добавления маршрутизатора Fibre Channel - Gigabit Ethernet и ПО для перевода данных с SCSI-устройства хранения данных в IP-данные. До появления Gigabit Ethernet скорости локальных сетей очень мало соответствовали необходимым для передачи этого типа блочных данных. Теперь, когда на горизонте неявно вырисовывается 10 Gigabit Ethernet, идея о передаче блочных данных по IP выглядит более привлекательной. Как ожидается, IETF окончательно одобрит проект iSCSI к концу 2001 года. Adaptec и Cisco планируют на этот же год начало поставок продуктов на основе iSCSI.

Однако Adaptec и некоторые другие компании утверждают, что iSCSI нуждается в дополнительных улучшениях. Эти компании расширяют спецификацию, добавляя базы управления SNMP-информацией, IP Security или транспортный протокол ATM под названием SEP (SCSI Encapsulation Protocol). Например, Adaptec намерена поддерживать спецификацию iSCSI, расширенную поддержкой SEP. Хотя она уверена в том, что ее продукция будет работать с iSCSI, когда он превратится в стандарт.

Сторонниками конкурирующей спецификации Fibre Channel over IP являются Brocade Communications Systems, Gadzoox Networks, Lucent Technologies, McData и QLogic. В этой технологии фреймы Fibre Channel инкапсулируются в IP-фреймы для передачи по сетям Gigabit Ethernet, SONET или ATM. Появление стандарта ожидается в середине 2001 года, но некоторые поставщики, не дожидаясь его принятия, уже продают продукты, сделанные по технологии Fibre Channel over IP, для объединения географически разделенных сетей хранения данных (SAN) и заявляют, что их оборудование можно будет программным способом привести в соответствие со стандартом.

Brocade и Gadzoox также входят в группу производителей, предложивших Fibre Channel Backbone. Технология Fibre Channel Backbone обеспечивает большие расстояния и большую производительность, чем Fibre Channel over IP. Каждое из этих трех предложений дополняет остальные. Fibre Channel over IP хороша для связи между сетями SAN, расположенными пределах одного города, Fibre Channel Backbone - для передачи данных на хранение на десятки километров, а iSCSI -- для передачи данных на хранение практически в любую точку земного шара. Все эти технологии существено различаются, и только один производитель -- компания Entrada Networks объявила о выпуске коммутатора, который будет включать в себя все три спецификации.

В лицо всем остальным брошено четвертое, весьма странное, предложение. Это предложение называется storage over IP и представляет собой объединенный вариант iSCSI и Fiber Channel over IP. Предложение исходит от Nishan Systems, новой фирмы, основанной Dell Computer, Quantum, Siemens и Sun. Nishan заявляет, что ее предложение выиграет войну стандартов, а такие гиганты, как Cisco, IBM и Lucent, просто этого еще не поняли. С этим согласны далеко не все. "Nishan витает в облаках, -- говорит Стив Дюплесси (Steve Duplessie), основатель Enterprise Storage Group, фирмы, занимающейся анализом хранения данных. -- Нереально полагать, что органы стандартизации могут превратить три коренным образом различающихся проекта в единый общий стандарт. И уж совсем странно думать, что одному новичку удастся изменить способы работы этих органов".

Рекомендации на будущее. Многие сходятся на том, что в ближайший год нас ждет баланс между тремя предложениями: SCSI over TCP, Fibre Channel over IP и Fibre Channel Backbone. После стандартизаций пользователи получат дополняющие друг друга способы передачи данных для сохранения по IP, соответствующие различным сетевым сценариям. В 2001 году баталии вокруг стандарта передачи данных на хранение по протоколу IP не кончатся и пользователям придется иметь дело с рыночной неразберихой.

Однако, например, Стив Дюплесси практически не сомневается, что в конечном счете iSCSI выиграет сражение. "Но цель этого сражения - не выявить лучшего, а определить, какой производитель выпустит все это на рынок. На сегодняшний момент это Cisco", -- считает он. По мнению Дюплесси, стандартизация Fibre Channel over IP может оказаться излишней. "Есть конкретные решения конкретных проблем, утверждения которых в качестве стандарта не требуется. Компания CNT, занимающаяся инфраструктурой для хранения данных, уже продает Fibre Channel over IP и ATM", -- говорит он. Используя технологию CNT, компания широкополосного спутникового телевидения EchoStar каждый день передает данные для хранения по городской IP-сети. "Наши потребности в сохранении данных возрастают на 400-500% в год, -- говорит Рик Нельсон (Rick Nelson), IT-директор в этой компании. -- Мы начали разработку SAN два года назад. Не будь у нас тогда такой возможности (т. е. если бы нас сдерживали стандарты), мы бы легко потеряли половину клиентов".

Управление сетями: интегрированные системы или отдельные продукты

Автор: Даниил Фертф

Выбор системы управления сетями по-прежнему непрост. Рынок переполнен множеством вариантов: интегрированные системы управления от таких разработчиков, как Aprisma, Computer Associates, Hewlett-Packard и Tivoli; отдельные продукты от Concord Communications, RiverSoft и Tavve Software; многоцелевые комплекты для управления от тех же поставщиков… Разработчики интегрированных систем управления стараются доказать их полезность, а производители отдельных продуктов претендуют на большее, чем просто заполнение пробелов в функциональности интегрированных систем.

Будущее - за интегрированными системами управления, которые объединяют отдельные продукты, говорит Дэйв Ферри (Dave Ferree), директор по электронной коммерции системного интегратора Aptia. Он обращает внимание на RiverSoft, которая лицензировала исходный код своей системы Network Management Operating System компании HP для использования в OpenView. Это придаст OpenView возможность работы с сетями различной топологии. "Это правильный шаг, поскольку теперь HP сможет быстро включить такую возможность в свои продукты", - считает Пол Эдмундс (Paul Edmunds), старший сетевой аналитик из Duke Energy, который использует как OpenView, так и отдельные продукты.

Но обозреватели не спешат провозгласить интегрированные системы управления абсолютным победителем. Поставщики отдельных продуктов часто предоставляют лучшие решения. Так например, некоторые владельцы HP OpenView, приобретя дополнительный продукт для управления Tavve, очень высоко оценили производительность, средства анализа и другие предоставляемые им возможности управления. "Фирма Tavve разработала свои продукты в помощь HP OpenView, однако в конечном счете они заменили OpenView", - говорит Франк Дзюбек (Frank Dzubeck), глава Communications Network Architects, фирмы, занимающейся анализом индустрии. Преданность брэнду может остаться в прошлом, добавляет он.

Поставщики интегрированных систем управления должны изменить мнение о том, что их предложения так же тяжеловесны, как их имена, и так же сложны в реализации, считает Джон Мак Коннелл (John McConnell), президент консультативной фирмы по управлению сетями McConnell Associates. "Большие компании не уделяют должного внимания интегрированным системам управления, - говорит он, - и из-за этого отдельные продукты становятся более привлекательными".

Однако, по словам Валери О'Коннелл (Valerie O'Connell), управляющего директора фирмы по исследованию рынков Aberdeen Group, пользователи не могут ожидать положительных результатов, просто навесив на свои инфраструктуры самые свежие управляющие программы. Пользователям необходим единый взгляд на все серверы, программы и сети. Им надо продумать управление не только сетью, но и системами и прикладными программами, стратегически объединив цели бизнеса и управления информацией. "С ростом числа отдельных продуктов сложность не будет уменьшаться", - считает О'Коннелл.

Она хвалит компанию CA за развитие своих продуктов в правильном направлении. По ее мнению, эта компания поставила все свои продукты на единую основу Jasmine ii, сделав шаг вперед по сравнению с классической интеграцией архитектуры и конструкции. Например, недавно компания выпустила комплект средств управления связями с заказчиками (CRM) и интегрировала это новое программное обеспечение с платформой для электронной коммерции Jasmine ii и своей технологией Neugents. Поскольку CA сделала Jasmine ii центром всех своих предложений, ей не приходится подгонять продукты под сегодняшние тенденции.

В наиболее уязвимом положении находится третья категория ПО -- многоцелевые комплекты для управления. Да, они пользуются спросом. Фирма Concord, например, планирует периодически выпускать программные модули для своего комплекта продуктов управления сетями и системами eHealth Suite. Первый такой модуль, AdvantEdge for Exchange, выпущенный в ноябре 2000 года, добавляет возможности мониторинга и управления прикладными программами групповой работы Microsoft Exchange. Однако многоцелевые комплекты для управления, при всей своей полезности, на самом деле не должны решать серьезных задач по интеграции - для этого служат стандарты.

Но поставщики средств управления сетями запаздывают с принятием таких стандартов, подчеркивает Дзюбек. Главное препятствие здесь -- это поставщики интегрированных систем, которые не признают, что нужно проводить стандартизацию, чтобы рынок средств управления сетями двинулся вперед. Однако им придется это делать, если они не хотят уступать этот рынок разработчикам отдельных продуктов, добавляет он.

Рекомендации на будущее. К сожалению, пользователям нельзя однозначно порекомендовать единую стратегию на все случаи жизни. Пока рано утверждать, что интегрированные системы управления, отдельные продукты или же многофункциональные комплекты для управления возьмут верх. Каждый производитель обещает программы «от всех болезней», но ни один не способен их сделать. "Не бывает «безразмерной»технологии, подходящей для всех. Это невозможно даже для ботинок, тем более для программных продуктов", - говорит О'Коннелл из Aberdeen Group. Кроме того, пользователи хотят, чтобы системы управления сетями позволяли им предупреждать возникновение проблем, а не просто реагировать на них.

Поставщики интегрированных систем не могут так быстро отвечать на новшества, как разработчики отдельных программ, но последние не могут предложить комплексных решений, и эта ситуация сохранится еще некоторое время. Чтобы выбрать лучшую систему управления сетями, необходимо стратегически учесть цели бизнеса и управления информацией. А это будет непросто.

Некоторые аналитики считают, что насыщенный рынок средств управления сетями прокладывает дорогу провайдерам услуг управления (management service providers, MSP). Действительно, учитывая нехватку персонала и времени, заказчики любого калибра могут всерьез рассматривать возможность прибегнуть к услугам сторонних фирм. Но подобно поставщикам интегрированных систем управления, MSP выходят на рынок с обещанием сделать для вас все. И есть шансы, что вместо прояснения ситуации ваш выбор станет еще сложнее.