Руководство компании утверждает, что внедрение концепции SONA позволит снизить корпоративные издержки и открыть пользователям доступ к многочисленным виртуальным услугам (включая защиту данных, передачу голоса, мобильную связь и доступ к бизнес-приложениям, средства управления, вычислений и хранения данных). При этом сеть начнет играть роль «фундамента» таких сервисов. В интервью вице-президента Cisco по современным сервисам Билла Раха старшему редактору Network World Денису Даби обсуждались причины, по которым сетевые инженеры уже сегодня должны учитывать при проектировании сетей элементы SONA — архитектуры, заметно упрощающей развертывание и мониторинг сетей следующего поколения.

Не могли бы Вы в общих чертах обрисовать принципы архитектуры SONA?

В последние годы Cisco предложила несколько инновационных архитектурных подходов к проектированию сетей. SONA появилась на свет 18 месяцев назад в ответ на изменения в мире корпоративных сетей. Одновременно мы стремились упорядочить широчайший ассортимент выпускаемых компанией устройств и найти способ их эффективного сочетания в сетевой среде, назначение которой вышло далеко за рамки коммутации и маршрутизации. В SONA нашли воплощение компоненты технологий передачи голоса, коллективной работы, информационной безопасности и центров обработки данных, которым отныне предстоит сосуществовать в единой интегрированной сетевой среде. Кроме того, появление SONA отвечает общему движению ИТ-индустрии к сервис-ориентированной архитектуре (SOA).

На какой стадии находится разработка SONA в самой Cisco?

По всей видимости, эта деятельность будет завершена не скоро. Идет процесс эволюции наших представлений о том, что такое сервис с точки зрения сетевых устройств. Далеко не все сервисы нуждаются в программируемом интерфейсе. Это обстоятельство влияет на выпускаемые компанией продукты: одни сервисы могут рассматриваться как «черные ящики», а другие требуют настройки на программном уровне. В то время как другие производители создают программные модули, позволяющие реализовать идеи SOA на практике, мы ведем параллельную работу на сетевом уровне, чтобы сделать возможным развертывание высокомасштабируемых и очень надежных распределенных SOA-услуг.

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

В какой мере движение к архитектуре SOA, которая основана на повторном использовании программных компонентов, повлияет на вашу компанию, традиционно фокусирующуюся на производстве сетевых устройств?

Сегодня заказчики интересуются тем, какие сервисы поддерживает наше оборудование или его отдельные компоненты. Ключевая роль корпоративной сети все больше смещается в область услуг, а отсюда — вопросы о реализованных в ней сервисах, их наполнении и предоставлении пользователям, их соответствии общей архитектуре SOA. Архитектура SONA определяет функционирование сети и обеспечиваемые ею сервисы. Одновременно она помогает разработчикам SOA-решений изменять их мышление и начинать самостоятельно «открывать» продукты для интеграции в другие системы, создавая программируемые интерфейсы, которые значительно превосходят возможности традиционной командной строки.

Привязана ли архитектура SONA к какому-то набору устройств или конкретному оборудованию Cisco?

Всякий раз, когда наша компания что-либо анонсирует, заказчики спрашивают, идет ли речь о конкретном продукте или определенной сетевой «коробке». Причина проста: на протяжении всего срока своего существования Cisco специализировалась на производстве сетевого оборудования. Однако в случае с SONA ответ — отрицательный. Эта архитектура возникла как результат множества изменений, которые нашли отражение в наших устройствах. Подобно любой другой сетевой архитектуре, SONA определяет подход к структурированию сети и сетевых устройств. Возьмите в качестве примера технологии обработки голоса, которые, возможно, активнее других продвигаются к открытости. На их базе можно создавать приложения, используя среду разработки CUAE (Cisco Unified Application Environment). Это — наглядная иллюстрация расширения отдельных продуктовых линеек с целью их интеграции в сервис-ориентированную среду.

Как вы намерены сподвигнуть пользователей к применению SONA в корпоративных сетях?

Идея сервисной ориентации и использования архитектуры SONA через какое-то время будет пронизывать любой компонент нашего ассортимента. Прежде всего, существуют так называемые сетевые проекты, одобренные Cisco: это сети филиалов, центров обработки данных, кампусные сети т.д. Мы демонстрируем образцы проектов и предлагаем лучшие практики в области построения конкретных частей корпоративной сети. Отметьте: сегодня приходится говорить уже не об отдельной сети как таковой, а о множестве взаимодействующих сетей. Одобренные нами проекты сетей формируют основу архитектуры SONA и, в свою очередь, диктуют изменения продуктовых семейств. И мы начинаем рассматривать все многообразие наших продуктов с точки зрения сервисов.

А почему такое изменение в восприятии сети важно для заказчиков?

Несмотря на многочисленные рассуждения о распределенных приложениях, в крупных масштабах они появились лишь в последние годы, да и то лишь у наиболее «продвинутых» заказчиков. В качестве примера я люблю упоминать Google Maps. Сегодня не составляет труда экспортировать в это приложение ваши данные и получить собственную систему, что заметно повысило популярность данного программного обеспечения. Идея использования Internet совместно с приложениями и Web-сервисами реализуется на практике, и мы можем наблюдать появление в большой степени распределенных приложений. В итоге появляется множество любопытных вариантов сетевого поведения, которые прежде никому не приходили в голову.

Какие именно типы сетевого поведения могут удивить сетевых менеджеров?

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

Какую область сетевого проектирования в наибольшей степени затронут изменения?

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

Как соотносится концепция SONA с технологиями виртуализации?

SONA помогает найти способ виртуализации имеющейся среды. Существуют несколько областей виртуализации. Можно начать с виртуализации систем хранения, а затем распространить эту технологию на серверы. Куда больше усилий требует виртуализация приложений. Разобравшись с виртуализацией относительно простых компонентов вычислительной среды, можно постепенно переходить к полной виртуализации прикладного ПО. Архитектура SONA играет здесь двоякую роль. С одной стороны, она позволяет понять, что виртуализация — это путь к архитектурам следующего поколения. С другой, лучшие практики реализации компонентов SONA показывают, с чего следует начать виртуализацию, чтобы получить осязаемый результат, и какие шаги предпринять в дальнейшем.

Как SONA помогает повысить производительность корпоративных приложений?

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

В какой степени SONA подразумевает интеллектуальность сети?

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

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

Сети становятся все сложнее и сложнее. Как Cisco помогает клиентам совладать с их нарастающей сложностью?

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

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

Наконец, внутренняя сложность присуща и архитектуре SOA, основанной на взаимодействующих компонентах. Выигрыш от ее применения заключается в уменьшении времени реакции, в ускорении внедрения приложений и росте их возможностей, но за это приходится платить повышением сложности. Жизнь требует разработки принципиально новых подходов к управлению такими средами и обеспечению их прозрачности в целях управления (в частности — на уровне одиночных пакетов). Администратор должен располагать информацией о том, кто с кем взаимодействует, в какое время, как часто и по каким причинам. Только объединив технологии виртуализации, функции прикладного уровня и архитектуру SOA, организации смогут совладать со сложностью современных сетей.

Коротко о SOA

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

Архитектура SOA базируется на трех фундаментальных элементах:

  • компонентная модель построения приложений «по требованию». Благодаря разбиению приложений на ключевые «строительные блоки» создается библиотека бизнес-объектов, каждый из которых выполняет специфическую функцию;
  • реестр, содержащий актуальную информацию обо всех доступных компонентах, в том числе об их базовых возможностях и совместимости с другими компонентами;
  • поисковый механизм, позволяющий находить компоненты, которые необходимы в данный момент для работы с определенным набором других компонентов либо для построения приложения «по требованию».

Появление SOA знаменует собой третий этап эволюции ИТ-архитектур в направлении виртуализации информационных систем. Содержанием первого этапа — интеграции корпоративных приложений (EAI) — была собственно виртуализация. Поставщиками приложений разработано множество патентованных коннекторов (аналогичных API-интерфейсам), способных взаимодействовать с ограниченными наборами приложений. Со временем многообразие программных компонентов, их патентованная природа и сложность визуального отображения колоссальных объемов разрозненной информации лишили информационные системы столь необходимой им гибкости.

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

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

В отличие от традиционных процессов обработки транзакций компоненты SOA «текучи» и требуют «содействия», а не жесткого контроля. Эти свойства как нельзя лучше вписываются в изменяющуюся парадигму бизнеса, в соответствии с которой гибкость сотрудничества и информационные потоки становятся новыми факторами конкурентоспособности. При этом архитектуру SOA следует рассматривать исключительно как катализатор новых процессов, а не как самоцель. Ее появление — отражение особенностей современной бизнес-среды: компании стремятся уйти от жестких организационных схем, а рыночное преимущество все чаще определяется продуктивностью работы виртуальных команд сотрудников.