Журнал о компьютерных сетях и телекоммуникационных технологиях
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК:
    Домой
 
   
АРХИВ ЖУРНАЛА
   

2008: 1 2 3 4 5 6 7 8 9 10 11 12 13
2007: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2006: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2005: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2004: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2003: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2002: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2001: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2000: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
1999: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1998: 1 2 3 4 5 6 7 8 9 10 11 12
1997: 1 2 3 4 5 6 7 8 9 10 11 12
1996: 1 2 3 4 5 6 7 8 9 10


Rambler's Top100

  

SOA и виртуализация — идеальная пара

Энди Дорнан

Объединение архитектуры SOA с технологией виртуализации позволяет добиться идеальной «маневренности» бизнеса. Можно ли интегрировать их, не наломав дров? Эти две технологии являются на сегодняшний день самыми прогрессивными, и тому есть достаточно объяснений. Виртуализация серверов обеспечивает не только высокую гибкость, но и экономию затрат, тогда как сервис-ориентированная архитектура (Service-Oriented Architecture — SOA) позволяет повторно использовать приложения в виде сервисов и быстро реагировать на изменяющиеся потребности бизнеса. Однако преимущества объединения данных технологий не столь очевидны.

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

Но, хотя SOA и виртуализация — «идеальная пара», вся беда в том, что на пути их единения слишком много препятствий. Так, если вы объединяете эти технологии, приложения управления виртуализацией начинают испытывать коммуникационные проблемы, в то время как их веб-сервисные аналоги не так хороши, когда требуется распознать границы функционирования виртуальных машин (ВМ). И тем не менее ИТ-специалистам нужно иметь в виду, что обсуждаемая интеграция рано или поздно произойдет. У таких крупных производителей платформ приложений, как BEA Systems, IBM, Microsoft, Red Hat и Sun Microsystems, объединение технологий SOA и виртуализации уже давно на уме, так что и вам не следует упускать из виду эту тенденцию.

Полную версию данной статьи смотрите в 9-м номере журнала за 2008 год.

Брак, заключенный на небесах

Говоря о виртуализации серверов, большинство специалистов ИТ имеют в виду их консолидацию, и нетрудно понять, почему: использование одной машины там, где раньше требовались две, четыре или даже десять машин, — это существенная экономия затрат, с точки зрения как приобретения оборудования, так и энергозатрат, управления, охлаждения и т. п. Однако консолидация всего лишь первый шаг. Огромным преимуществом виртуализации является ее высокая гибкость, реализуемая благодаря выделению разнообразных ресурсов сервера — в частности, процессоров, памяти и дискового пространства, которые затем объединяются в пулы и выделяются приложениям по требованию.

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

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

Виртуализация, без сомнения, упрощает SOA за счет быстрого предоставления приложениям новых аппаратных ресурсов. К сожалению, это не всегда просто сделать, переменные нагрузки на архитектуру SOA требуют выделения сервисам серверных ресурсов с высокой степенью дискретизации, начиная с небольших долей ресурсов одного сервера и кончая большим числом серверов. Что касается виртуализации, то в основном предприятия все еще находятся на стадии внутреннего консолидирования серверов, фокусируя свое внимание на расщеплении ресурсов одного сервера между несколькими ОС. Создание пула ресурсов множества серверов уже совсем иной подход, больше напоминающий «коммунальные» распределенные вычисления (или кластеризацию), нежели то, что предоставляют сегодня компании VMware и Xen.

Кроме того, поистине «живая» (agile) инфраструктура требует создания таких ВМ, которые могли бы быстро перемещаться между серверами, а это повлечет за собой использование виртуальных устройств хранения данных и виртуальных сетей. Еще более важным является обеспечение интеграции управления в масштабе всего программного стека. Хотя производители средств виртуализации и предоставляют инструментальные средства управления, упрощающие быструю инсталляцию/удаление ВМ, описываемые системы по-прежнему не интегрируются с ПО управления приложениями и ПО управления архитектурой SOA.

Виртуализация может оказаться полезной для двух основных категорий продуктов SOA, таких, как связующее ПО и базовые сервисы. Большинство широко классифицируемых сегодня в качестве SOA продуктов, включая ПО ESB (Enterprise Service Bus, или корпоративная сервисная шина), управления и безопасности, подпадают под первую категорию. Однако главные, связанные с повышением гибкости преимущества виртуализации SOA связаны со второй категорией продуктов SOA, включающей в себя не только серверы Java и .Net, но и «коннекторы» для унаследованных платформ. Это объясняется тем, что сервисы потребляют больший, чем связующее ПО, объем вычислительных ресурсов, а также тем, что спрос на конкретные сервисы может меняться с большей вероятностью.

Производители и продукты виртуализации

Выпускаемые такими компаниями, как BEA, IBM, Microsoft, Red Hat и Sun, прикладные серверные платформы должны быть относительно простыми в виртуализации. В принципе они уже отчасти виртуализированы, т. е. способны работать на виртуальных машинах Java или .Net, изолирующих приложения от базовой ОС. Изначально это было сделано с целью упрощения разработки приложений путем обеспечения их более высокой безопасности и переносимости с машины на машину, однако виртуализация должна также способствовать повышению «маневренности» этих приложений. Кро-ме того, все крупные производители платформ серверных приложений, за исключением BEA, продают технологию виртуализации уровня ОС (см. «Производители платформ веб-сервисов и их продукты виртуализации) и, следовательно, в состоянии обеспечивать более эффективную совместную работу двух технологий.

Объединение виртуализации уровня ОС с ВМ Java, по существу, является проблемой управления. В настоящее время виртуальные копии ОС создаются и управляются посредством ПО, поставляемого в комплекте с гипервизорами таких производителей, как VMware и XenSource. Хотя такое ПО уровня гипервизора способно понимать, как ресурсы виртуального сервера соотносятся с физическим оборудованием, оно не в состоянии заглядывать внутрь приложений.

В противоположность этому инструментальные средства управления SOA и веб-сервисами не могут видеть, что делается за пределами прикладной платформы. Большинство из них имеют работающие в рамках Java-ВМ агенты управления, но они ничего не знают о том, является ли базовый сервер виртуализированным или нет.

Компания IBM — крупный производитель ВМ Java, выпускающий свою линию продуктов WebSphere. Вот уже 40 лет корпорация предоставляет продукты виртуализации для мэйнфреймов и все еще продвигает свои серверы System i и System p как платформы для Java-приложений. Оба сервера обеспечивают полную виртуализацию уровня ОС, встроенную в их ОС AIX и i5/OS соответственно, и способны поддерживать веб-сервисы либо с помощью работающей на ВМ ОС Linux или Windows, либо непосредственно самими ВМ Java. Хотя это и обеспечивает высокую гибкость виртуальной среды, необходимость использовать фирменное оборудование и ПО IBM может стать препятствием в использовании этих серверов многими предприятиями.

Надо отметить, что IBM не имеет своего собственного гипервизора для стандартных серверов x86, однако она участвует в разработке проекта Xen с открытым исходным кодом и сотрудничает с производителями гипервизоров, в том числе с VMware. Основным ее продуктом виртуализации является WebSphere Extended Deployment (XD), обеспечивающий кластеризацию множеств ВМ Java. Системные администраторы могут составить для конкретных сервисов внутреннее соглашение об уровне обслуживания; после этого, исходя из спроса на ресурсы, система сконфигурирует виртуальные Java-машины, распределив приоритеты доступа каждой из них к конкретным ресурсам. Эта возможность не ограничена одними лишь продуктами IBM, поэтому ПО WebSphere XD будет работать с большинством ВМ Java и операционных систем. Тем не менее с точки зрения управления, будучи не способным «заглянуть» внутрь гипервизора, оно вынуждено «довольствоваться» лишь приложениями Java.

В большинстве веб-сервисных инсталляций сегодня используются серверы Windows со средой .Net, поэтому Microsoft строит в отношении SOA и виртуализации большие планы. Что касается SOA, то в прошлом году компания анонсировала свою долгосрочную стратегию Oslo, нацеленную на упрощение создания приложений за счет замены программирования на использование среды разработки типа Visio. Относительно же планов Microsoft, касающихся виртуализации можно сказать следующее: компания уже предоставляет Virtual Server, позволяющий пользователям запускать поверх новейшей версии Windows Server его более старые версии, оно также предлагает свой гипервизор Hyper-V в качестве компонента Windows Server 2008 (а в ближайшем будущем выпустит его и как самостоятельный продукт). На сегодняшний день интеграция между Oslo и Hyper-V практически отсутствует — главным образом потому, что Oslo все еще остается «концептуальным» продуктом.

Компания Red Hat стала важным игроком рынка Java-продуктов благодаря приобретению фирмы JBoss и ее одноименного сервера, программный стек которого компания расширяет сегодня с целью обеспечения его работы в качестве не только платформы, но и связующего ПО SOA. Будучи бесплатным продуктом с открытым исходным кодом, сервер JBoss быстро стал весьма популярным. По утверждению сотрудников Red Hat, сервер JBoss сегодня так же востребован на предприятиях, как и серверы BEA и IBM.

Кроме того, чтобы полностью укомплектовать свой программный стек (который, однако, не является реальным соперником стеков XenSource и VMware, поскольку должен управлять работой ОС Red Hat Enterprise Linux — RHEL), Red Hat интегрировала со своей ОС RHEL гипервизор Xen. Как нам сказали в Red Hat, виртуальные сервисы сегодня используются в основном для поддержки сценариев тестирования. Если учесть относительную простоту создания веб-сервисов и потенциально сильное влияние их на другие компоненты аппаратной и программной инфраструктуры наряду с необходимостью обеспечения их совместимости с отраслевыми стандартами и внутренней системной политикой, тестирование их в виртуальных средах является обязательным.

ОС Sun Solaris имеет свою собственную встроенную технологию виртуализации под названием Containers, по существу являющуюся технологией виртуализации приложений: хотя работает всего одна копия ОС, тем не менее приложения изолированы друг от друга. Несмотря на то что изначально они должны были поддерживать OS Solaris, компания предоставляет интерфейсы API Linux для обеспечения совместимости программ.

Sun также выходит на рынок гипервизоров со своим ПО управления с открытым исходным кодом xVM, которое, как она надеется, сможет в некоторой степени снять проблему, называемую ею «бесконтрольным размножением ВМ» и состоящую в быстром увеличении в масштабе предприятия числа неуправляемых (а иногда и полностью неизвестных) ВМ. ПО xVM построено на основе гипервизора Xen, но оно включает в себя технологию аварийного восстановления и упреждающего самовосстановления (Predictive Self-Healing), позволяющую изолировать неисправные аппаратные компоненты без какого-либо влияния на отдельные ВМ. Выпуская комбинированную систему с гипервизором Xen и ПО управления, компания Sun конкурирует непосредственно со специализированными производителями гипервизора Xen (XenSource и Virtual Iron Software) и компанией VMware. Хотя большая часть отличной от Xen технологии была привнесена в xVM из Solaris, она не требует ни Solaris, ни какого-либо другого оборудования или ПО Sun.

Когда OC больше не нужна

Несмотря на то что компания BEA сама не поставляет гипервизор, выпустив сервер WebLogic Server Virtual Edition (WLS-VE), она продвинулась в области виртуализации серверов приложений гораздо дальше своих соперников. WebLogic заполняет существенный пробел в линии продуктов Oracle и является одной из главных мотиваций покупки фирмой Oracle компании BEA Systems. Сервер WLS-VE может работать непосредственно поверх ПО VMware, вообще не требуя никакой ОС. Главная идея состоит в том, что, поскольку Java-приложения уже работают на ВМ Java, ОС является попросту излишней. Гипервизор включает функциональность ОС более низкого уровня, такую, как управление драйверами устройств, тогда как BEA добавила в новую версию Java-ВМ JRockit (которую она называет LiquidVM), обеспечивающую функции более высокого уровня, — в частности, управление вводом-выводом данных и хранением файлов.

По мнению специалистов BEA, исключение ОС позволяет добиться за счет экономии системных ресурсов почти 50%-ного увеличения производительности. Однако компания не смогла связать нас с кем-либо из своих клиентов, которые подтвердили бы это ее заявление, тогда как ее конкуренты отмечают, что системные ресурсы, включая процессорную мощность, оперативную память и дисковое пространство, являются относительно дешевыми и продолжают падать в цене. Реальные преимущества исключения ОС должны лежать в области управления, поскольку устранение ОС упрощает создание и перемещение Java-приложений, а также создание системы управления, способной просматривать весь программный стек, начиная с гипервизора и кончая прикладным уровнем.

К сожалению, заявляемое упрощение управления не так-то легко измерить количественно, но это станет более доступным с выходом ПО управления LOC (Liquid Operations Control) компании BEA. В настоящее время управляющее ПО LOC наряду с внешними приложениями контролирует также и приложения, работающие в рамках LiquidVM, тогда как VMware контролирует ВМ. Платформы управления представляют собой главным образом генераторы предупреждающих сообщений, но не более того. Когда некий процесс пересекает установленный для него порог, он просто уведомляет об этом администратора, никакой реальной автоматической обратной связи здесь нет.

ПО LOC может изменить эту ситуацию путем предоставления LiquidVM выделенной платформы, способной не только запускать и останавливать ВМ и протекающие в них процессы, но и отслеживать, какие приложения где работают. В силу того что ВМ LiquidVM должна мирно сосуществовать с другими серверами Java, она сможет также контролировать приложения на поддерживающих спецификацию Java Management Extensions физических серверах и даже отображать взаимозависимость сервисов.

Большинство сервис-ориентированных архитектур отслеживают требования и взаимозависимости приложений посредством SOA-реестра — специализированной базы данных в составе ПО управления SOA. Несмотря на то что BEA поставляет свой продукт управления SOA, ПО Liquid Operations Control не способно извлекать информацию из его реестра. Администраторам необходимо вводить параметры о требованиях и взаимозависимостях разных сервисов вручную, что может приводить к дублированию работ. Представители компании BEA заявляют, что собираются интегрировать LOC со своим ПО SOA-реестра, основанным на лицензионной технологии HP Systinet.

Платформа LiquidVM затыкает важную «дыру» в портфеле продуктов Oracle, предоставляя ей возможность конкурировать с производителями ОС, что называется, лоб в лоб. В BEA планируют расширить сферу действия LiquidVM на другие свои приложения, выпустив не содержащие операционную систему редакции своих продуктов WebLogic Portal и AquaLogic Service Bus одновременно с Liquid Operations Control. Теперь, после вхождения BEA в состав Oracle, можно предположить, что ВМ LiquidVM будет также использоваться и с виртуализированными версиями продуктов Oracle.

В настоящее время LiquidVM совместно работает только с VMware, тем не менее в BEA Systems нам сказали, что планируется реализовать поддержку Xen в новой версии LiquidVM, а затем обеспечить и поддержку Hyper-V. Компания Oracle уже выпустила свой основанный на Xen продукт виртуализации, что, возможно, сделает задачу по обеспечению совместной работы LiquidVM и Xen приоритетной. Однако концентрация внимания исключительно на этих двух продуктах может отрицательно сказаться на одном из наиболее весомых коммерческих аргументов в пользу LiquidVM — его способности работать совместно с VMware.

SOA-реестры в подарок

Поскольку совсем не обязательно привязывать SOA-реестр к прикладной платформе, производители автономных продуктов управления SOA также могут упростить виртуализацию веб-сервисов. Основным игроком здесь является компания Software AG, купившая в прошлом году конкурирующую фирму WebMethods. Компания Software AG осуществляет сегодня объединение реестра Infravio фирмы WebMethods со своим реестром CentraSite, разработанным ею совместно с Fujitsu. Вместо того чтобы работать непосредственно с ПО управления, компания Software AG стремится расширить реестр в полную базу данных конфигурационной информации, способную отслеживать не только веб-сервисы, но и ИТ-инфраструктуру в целом, разделяя информацию с основными платформами сетевого управления.

Компания VMware весьма успешно раскрутила идею виртуальных устройств, противоположную на первый взгляд концепции SOA: вместо разбиения приложений на небольшие, многократно встраиваемые в новые приложения части виртуальное устройство комплектуется приложением вместе с операционной системой — обычно версией Linux, имеющей упрощенную конфигурацию. Однако две эти концепции могут прекрасно уживаться друг с другом. Например, производители шлюзов безопасности SOA — фирмы Vordel и Layer 7 Technologies — приступили в прошлом году к поставке своих продуктов в качестве виртуальных устройств — весьма значительное изменение, если учесть, что шлюзы безопасности обычно предоставляются как физические устройства.

Первоначально шлюзы безопасности SOA использовались как межсетевые экраны (МЭ) XML, и по сей день эта их функция является самой популярной. Подобно традиционным МЭ, они обычно продаются в качестве аппаратных устройств, зачастую с применением специализированных микросхем акселерации. Сдвиг в сторону виртуальных устройств отчасти стимулируется агрессивной XML-стратегией Intel. Последняя начала рекламировать программную обработку XML-документов лишь как один из способов повышения спроса на свои универсальные процессоры, тем не менее затем сама вышла на корпоративный рынок XML, конкурируя непосредственно с некоторыми своими клиентами — разработчиками устройств.

Виртуальные версии устройств производства Vordel и Layer 7 первоначально предназначались для тестирования, теперь же некоторые их клиенты уже используют эти продукты в своих производственных средах. Оба производителя надеются, что данная тенденция будет продолжать расти. Виртуальные устройства по сравнению с аппаратными более просты в инсталляции и управлении, при этом серверные ресурсы выделяются ВМ по требованию. Например, партнер Layer 7 — компания Sun — продвигает концепцию обеспечения безопасности по требованию, согласно которой сервисы безопасности предоставляются виртуальным устройством по мере необходимости в них.

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

Разработка приложений

Чтобы производственная инфраструктура ИТ была действительно «живой», виртуализация должна позволять ИТ-подразделениям не просто разделять один сервер на несколько ВМ, но и распределять приложение по множеству серверов. Однако задача эта является куда более «крепким орешком», чем стандартная виртуализация серверов, поскольку большинство сегодняшних приложений созданы для последовательного, или линейного, выполнения и процесс их обработки не так-то легко расщепляется на параллельные операции. И хотя разработчики упорно трудятся над тем, чтобы распараллелить приложения для многоядерных процессоров, распределение приложений между несколькими серверами вносит дополнительные проблемы, связанные с сетевой задержкой и ограничением полосы пропускания. Так, если несколько ядер одного сервера могут быстро взаимодействовать друг с другом и получать доступ к общей памяти, то многочисленным серверам кластера приходится взаимодействовать через сеть, а значит, куда более медленно.

По этой причине большинство подходов к кластерным веб-сервисам не используют разбиение их на параллельно работающие части. Вместо этого в прикладных серверных фермах (application fabric) таких производителей, как Appistry и DataSynapse, приложение инсталлируется на множество серверов и нагрузка балансируется между его многочисленными копиями. Такая схема хорошо работает для большей части трафика SOA, поскольку веб-сервисы обычно включают в себя механизм реагирования на многочисленные пользовательские запросы, которые можно легко распределять между несколькими серверами.

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

В дополнение к продукту WebSphere XD компании IBM прикладные серверные фермы начали выпускать и две совсем новые фирмы. Продукт FabricServer фирмы DataSynapse работает с большинством приложений Microsoft и Java, при этом поддержка разработанных собственными силами приложений осуществляется с помощью традиционных ВМ Java и Microsoft .Net. Этот продукт также работает с ВМ VMware, позволяя ей в масштабе множества серверов эмулировать истинную, основанную на гипервизоре виртуализацию. В таком случае гипервизор и каждый образ ОС необходимо инсталлировать на каждый сервер в отдельности. При этом ПО DataSynapse разделяет процессорную мощность среди ОС точно так же, как и между приложениями.

Конкурирующая фирма Appistry поддерживает приложения, написанные не только для большей части сегодняшних ВМ Java и .Net, но и для популярной Java-платформы с открытым исходным кодом Spring. ПО EAF этой фирмы также предоставляет приложениям Java и .Net дополнительный API-интерфейс кластеризации, позволяющий им осуществлять доступ непосредственно к функциям прикладной серверной фермы.

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

Что же касается организаций, желающих внедрить SOA и виртуализацию, обеспечив максимальную их совместимость, то сегодня мы рекомендуем им придерживаться собственного принципа конструирования SOA, — принципа слабой связности (loose coupling). В условиях отсутствия стандартов, определяющих запуск веб-сервисов на ВМ, и в случаях когда даже фирменные системы все еще остаются совсем незрелыми, эти две технологии обречены на длительное «уживание» между собой. Однако продолжайте наблюдать за разработками в этой области, с тем чтобы не упустить тот момент, когда их «отношения» наконец-то окончательно определятся..

  
9 '2008
СОДЕРЖАНИЕ

инфраструктура

• Динамичный рынок монтажных конструктивов

• Энергосбережение в ЦОДах

• Городские сети Wi-Fi: многочисленные провалы и редкие успехи

информационные системы

• Управление производительностью распределенных приложений

• SOA и виртуализация — идеальная пара

• Знакомство с (*)

сети связи

• FTTx: где оптимальное место для «x»

• Мобильность — одно из главных преимуществ IP-телефонии

• Радиоинтерфейс LTE в деталях

кабельные системы

• Кабельные трассы на объектах со свободной планировкой

• Оптимальные приемы инсталляции экранированной кабельной системы

защита данных

• Боритесь с хищением данных


• Калейдоскоп


Реклама:
 Copyright © 1996-2008 ООО "Сети и Системы Связи". вверх