Быстрее сквозь облака

Когда речь заходит об «облачных» вычислениях, большинство людей представляют себе преимущественно внешние, или общедоступные, «облака» (Public Cloud): предложения по предоставлению инфраструктуры в виде сервиса (Infrastructure as a Service, IaaS) наподобие EC2 от Amazon; платформ в виде сервиса (Platform as a Service, PaaS) вроде платформы Force.com от Salaforce, которая благодаря партнерству поставщика с VMware недавно пополнилась средствами разработки VMforce на базе Java, или многочисленные предложения по предоставлению программного обеспечения в виде сервиса (Software as a Service, SaaS), такие как Microsoft Office Live, Lotus Live компании IBM, а также решения CRM, хостируемые в «облаке глобальной сети», к примеру Saleforce.com или Microsoft Dynamics CRM.

Вместе с тем многочисленные ИТ-компании пытаются воспользоваться преимуществами «облачных» вычислений для своих внутрикорпоративных сред ИТ, ведь ключевые характеристики «облачных» сред включают в себя различные возможности, необходимые и во внутренних ИТ: динамичность (agility, то есть быстрое и беспроблемное перераспределение ресурсов), столь же быстрое и автоматизированное масштабирование, коллективную аренду (Multi-Tenancy) с возможностью динамического выделения вычислительных мощностей по мере потребности (и прежде всего в соответствии с соглашениями об уровне сервиса — Service Level Agreement, SLA), учет потребления ресурсов (по вычислительной мощности, занимаемому на дисках месту, трафику, количеству пользователей, промежутку времени и другим параметрам). И наконец, реклама «облачных» вычислений обещает снижение затрат (если уж не на необходимое для этого новое аппаратное и программное обеспечение, то хотя бы на его эксплуатацию).

СЕТЬ ДОЛЖНА СООТВЕТСТВОВАТЬ

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

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

Еще одно последствие виртуализированных ландшафтов ИТ — существенно возросшая плотность серверов: на одном аппаратном устройстве теперь могут располагаться восемь, десять, двенадцать или более виртуальных машин, каждой из которых требуется доступ к сети, и все они активно порождают трафик данных. Неудивительно, что спрос на 10 Gigabit Ethernet (10GbE) стремительно растет: аналитики Dell’Oro недавно сообщили, что количество портов 10GbE, проданных в 2009 году, превысило 2 млн. Согласно отчету Dell’Oro, 10GbE является единственным сегментом на рынке коммутаторов, который в 2009 году — в период экономического спада — смог продемонстрировать стабильный рост по количеству поставленных портов и объему продаж. По мнению экспертов, и в текущем году наибольший рост оборота придется на устройства 10GbE. «В 2010 году мы ожидаем дальнейшего расширения рынка, — говорит Алан Векель, директор отдела по исследованиям коммутаторов Ethernet в Dell’Oro Group, — тем более что 10 Gigabit Ethernet становится все популярнее не только в качестве технологии для подключения серверов, но и как средство агрегации в центрах обработки данных». Таким образом, будучи стандартом для магистральных коммутаторов, 10GbE — не в последнюю очередь благодаря виртуализации — все активнее используется в оборудовании для установки в конце ряда стоек (End of Row, EoR) или в их верхней части (Top of Rack, ToR).

Коммутаторы с портами 10GbE — в том числе и небольшие устройства, имеющие фиксированную конфигурацию и монтируемые по принципу ToR, — уже давно предлагаются всеми ведущими производителями, начиная с Cisco и его соперника, недавно объединившейся компании HP ProCurve/3Com, и заканчивая Brocade, Force10 и Extreme. Поскольку серверным фермам необходим доступ к системам хранения посредством Ethernet, технология Fibre Channel over Ethernet (FСoE) тоже стала стандартным требованием. Ровно год назад стандарт FСoE был официально ратифицирован и теперь занял прочное место в разработках специализированных производителей: он присутствует у Cisco в продукте Nexus, у Brocade в Brocade 8000, а Blade Network Technologies в феврале представила первый модульный коммутатор FCoE. В качестве альтернативы FCoE предпринимаются попытки утвердить стандарт iSCSI. В таких устройствах, как Nexus компании Cisco, предлагается концепция объединенной архитектуры (Unified Fabric), то есть одновременно поддерживаются FCoC, iSCSI и Fibre Channel.

ДЛЯ ДИНАМИЧНОСТИ «ОБЛАЧНЫХ» ВЫЧИСЛЕНИЙ ТРЕБУЕТСЯ ИНТЕЛЛЕКТУАЛЬНАЯ СЕТЬ

Для подвижности, необходимой при «облачных» вычислениях, — динамического перемещения серверов, приложений и систем хранения без изменения сетевых ссылок — от сети требуется как можно более тесное взаимодействие с внутренними системами (Back-End). Не зря некоторые производители объединяют серверы, системы хранения и виртуальные коммутаторы в единую систему. Именно так поступили компании Cisco, создавшая систему Unified Computing System (UCS), и HP, разработавшая продукт Matrix.

Для реализации сетей с поддержкой виртуальных машин (Virtual-Machine-Aware Networking), то есть умеющих отслеживать состояние виртуальных машин и соответствующим образом реагировать, лидер рынка коммутаторов Cisco использует технологию VN-Link, благодаря которой система UCS может интегрироваться в программное обеспечение VSphere компании VMware, поэтому коммутаторы и ресурсы хранения всегда осведомлены об особенностях работы существующих виртуальных машин. Cisco обещает, что эта технология обеспечит конфигурацию в реальном времени на базе правил (Policy-Based), динамическую реализацию одинаковых с VMotion сетевых директив и политики безопасности, а также сквозную модель администрирования от виртуальной машины до сети и систем хранения. В противовес этому решению компания HP предлагает конкурирующую технологию Virtual Connect.

Как раз на стыке между сетью и приложениями и располагаются контроллеры доставки приложений (Application Delivery Controller, ADC). Их основная задача заключается в освобождении — в соответствии с заданными правилами — физических или виртуальных серверов от несвойственных им задач для ускорения доступа к приложениям. Производительность контроллеров ADC тоже неуклонно возрастает: лидирующее положение в сегменте ADC с явным отрывом занимает система Viprion на базе шасси, выпускаемая компанией F5, — ее пропускная способность на уровне приложений (Layer 7) составляет 72 Гбит/с. Этот же вендор, лидер в данном сегменте рынка, недавно представил самое мощное отдельное (Standalone) устройство — контроллер доставки приложений Big-IP 11050, который способен обрабатывать 42 Гбит/с (см. Рисунок 1).

К настоящему времени такого же высокого уровня производительности достигло семейство устройств для масштабирования сети MPX от Citrix: флагманская модель MPX 21500 поддерживает скорость до 50 Гбит/с на седьмом уровне. Для обеспечения столь высокой степени масштабирования Citrix делает ставку на процессоры Intel и собственную технологию Ncore, которая для каждого процессорного ядра предлагает собственный механизм обработки пакетов (Packet Engine). По информации Citrix, настройку можно производить с помощью шаблонов приложений (App Template), которые легко внедряются в рабочую среду со страниц сообщества (Community Site) или из среды разработки (Staging Environment).

C помощью инструментов Reg Ex Creator и Reg Ex Evaluator администратор может осуществлять тестирование правил и регулярных выражений напрямую на устройстве (см. Рисунок 2).

ДИНАМИКА ВИРТУАЛЬНЫХ МАШИН ПРЕДЪЯВЛЯЕТ НОВЫЕ ТРЕБОВАНИЯ

Как и виртуальные коммутаторы, устройства ADC при выполнении своих задач сталкиваются с необходимостью получения информации о статусе виртуальных серверов, даже если их миграция осуществляется посредством механизмов VMotion или XenMotion. Кроме того, ADC может контролировать работающие виртуальные машины с помощью различных средств, начиная с эхо-запросов ICMP и заканчивая сложными вызовами приложений: если найти приложение не удается, контроллер исключает сервер из объединения, не важно, идет ли речь о поврежденном физическом или расформированном виртуальном сервере. По сведениям F5 и Citrix, если IP-адрес виртуального сервера остается неизменным, проблем обычно не возникает. Однако на практике могут встречаться и более сложные сценарии: к примеру, целенаправленное масштабирование фермы серверов Web за пределы диапазона IP-адресов базовой конфигурации для проведения какой-то кампании, или миграция виртуальных машин между несколькими площадками для обеспечения аварийного восстановления данных.

У Citrix за интеграцию в виртуальную среду отвечает инструмент Workflow Studio: посредством него администратор может, например, сообщить устройству Netscaler, какая именно внутренняя система будет проходить техническое обслуживание в ближайшее время. Тогда ADC сможет исключить все виртуальные машины и физические серверы из серверной фермы, как только все пользователи отключатся от нее.

Для более сложных сценариев F5 предлагает интеграцию своего оборудования в административное решение VMware vCenter посредством интерфейса iControl. Благодаря взаимодействию vCenter Site Recovery Manager с выпускаемым F5 модулем управления глобальным трафиком (Global Traffic Manager, GTM) виртуальные машины можно перемещать с помощью решения VMware Long Distance VМotion в другие ЦОД, не прерывая при этом сеансы с их участием. В Big-IP также предлагаются функции для оптимизации глобальной сети и дедупликации данных (Data Deduplication).

ВИРТУАЛЬНЫЕ ADC

Мода на виртуализацию привела к тому, что контроллеры ADC стали появляться на рынке в виде виртуальных устройств (Virtual Appliance). Такие устройства (готовые к работе образы виртуальных машин) очень полезны, поскольку в виртуализированные среды они внедряются проще, чем классические аппаратные решения. К тому же их легче отправить заинтересованной стороне для тестирования. В этой связи стоит упомянуть недавно появившееся решение Netscaler VPX компании Citrix с пропускной способностью до 3 Гбит/с, а в будущем этот показатель, согласно заверениям производителя, должен увеличиться до 15 Гбит/с.

F5 решила не отставать и представила контроллер Big-IP LTM VE (Local Traffic Manager Virtual Edition), рассчитанный, правда, лишь на 1 Гбит/с. Big-IP LTM VE служит исключительно для локального балансирования нагрузки, в то время как Netscaler в виде образа VPX, согласно заверениям Citrix, способен предоставить такой же объем функций, как и аппаратные устройства серии MPX. Естественно, исключением являются аппаратно реализуемые функции снижения нагрузки, в частности сжатие SSL и HTTP-трафика.

При создании развернутых инсталляций для достижения высокой масштабируемости и сохранения полной функциональности оба производителя решений ADC советуют прибегать к каскадированию физических и виртуальных контроллеров ADC в рамках гибридных архитектур: физический ADC отвечает за разгрузку, а его виртуальный коллега обеспечивает распределение нагрузки между виртуальными машинами и при необходимости может быть динамично перенесен вместе с серверной фермой. Для этого придется использовать на один уровень ADC больше, зато будет достигнута полная гибкость при оптимизации «облачной» инфраструктуры. Кстати, компания F5 обещает реализовать в решениях Viprion и Big-IP (начиная с версии 11.0, появление которой запланировано на конец 2010 года) возможность их разделения на виртуальные экземпляры.

Вильгельм Грайнер — редактор LANline.