Сеть ЦОД на проверку

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

Пожалуй, главная специфика ЦОД применительно к тестированию и мониторингу состоит в масштабном внедрении технологий виртуализации.Представим такую ситуацию: два важных приложения развернуты на двух виртуальных машинах в рамках одного физического сервера, а трафик между ними передается через виртуальный коммутатор, не покидая пределов сервера (см. Рисунок 1). Если бы трафик проходил через обычную (физическую) сеть, то при возникновении проблем в работе приложений его всегда можно было бы проанализировать традиционными способами, выявив источник неприятностей. Но как провести диагностику в виртуальной инфраструктуре?!

И это далеко не единственный вопрос, который встает перед службами эксплуатации ЦОД. Виртуализация и облачные сервисы кардинально меняют структуру и направления передачи трафика: если раньше доминировали потоки между клиентами и серверами (север — юг), то теперь основные потоки передаются между серверами, а также между серверами и системами хранения (запад — восток). В результате растет необходимость во внедрении все более скоростных вариантов технологии Ethernet, включая 40 и 100 Gigabit Ethernet. Компаниям приходится поддерживать в ЦОД две, а то и три отдельные сетевые инфраструктуры (локальная сеть Ethernet, сеть хранения SAN на базе Fibre Channel и сеть внутри высокопроизводительных кластеров на базе InfiniBand), но при этом растет интерес к их конвергенции на основе Ethernet (FСoE, IBoE). Добавим к этому кардинальный пересмотр самих архитектур построения сетей и переход к решениям вида «Ethernet-фабрика», а также необходимость создания территориально распределенных ЦОД — и тогда в полной мере станет понятна вся сложность и многогранность задач, встающих перед сетевыми архитекторами и службами эксплуатации.

Решение этих задач кажется невозможным без современных систем тестирования и мониторинга. Однако на практике спрос на них применительно к ЦОД в России пока невелик. Что это: незрелость рынка или надежда на «русский авось»? Риски слишком серьезны, чтобы оставаться в бездействии.

ПРЕДВАРИТЕЛЬНОЕ ТЕСТИРОВАНИЕ

Создание любой сети начинается с ее проектирования и выбора компонентов. Казалось бы, на этапе выбора логично проводить нагрузочное и функциональное тестирование оборудования, но в России это, скорее, исключение, а не правило.

По мнению Алексея Засецкого, директора по развитию бизнеса компании Syrus Systems, предварительное тестирование оборудования позволяет не только снизить затраты на его покупку, но и минимизировать риск того, что оно не будет работать должным образом. «Во всем мире в крупных организациях есть собственные тестовые лаборатории, которые проводят входной контроль покупаемого оборудования, — рассказывает он. — Что же касается России, чаще всего проверка требуемого оборудования или сетевого решения осуществляется в лаборатории производителя, куда приглашаются представители заказчика. Они составляют программу тестирования, которое выполняется совместно со специалистами производителя, претендующего на поставку».

Тем не менее некоторые российские организации приходят к убеждению в том, что перед масштабными закупками и при проведении конкурсов нужно самим тестировать оборудование. «Это особенно характерно для крупных государственных предприятий, которые, согласно Федеральному закону № 223-ФЗ, не должны выходить на конкурс с намерением купить конкретные модели оборудования определенного производителя, — продолжает специалист Syrus Systems. — Государственным организациям надлежит определить технические требования и выбрать оборудование, соответствующее данным требованиям. При этом производители могут заявлять о наличии нужных характеристик, но это не всегда соответствует действительности».

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

Хотя поставщики контрольноизмерительного оборудования (КИО), очевидно, заинтересованы в том, чтобы обосновать важность предварительного тестирования, далеко не все из них видят необходимость в проверке отдельных компонентов. «Современный ЦОД — это большая комплексная система, макропоказатели которой существенно — на 60–70% — зависят от человеческого фактора. По этой причине проверка отдельного компонента «при выборе» или «до закупки» не имеет естественной мотивации, — считает Игорь Бакланов, генеральный директор PR Group. — Владельцы ЦОД доверяют техническим характеристикам вендоров. Можно говорить о слепоте этой веры, но в ней есть и правда — даже замечательное «железо» может быть «убито» неправильными настройками. В нашей практике был случай, когда магистральный маршрутизатор Juniper из-за неправильной конфигурации демонстрировал характеристики не лучше дешевого абонентского коммутатора, и причина была вовсе не в вендоре, а в квалификации инженера».

Но называя «спорной» ценность предварительного нагрузочного тестирования отдельных компонентов, Игорь Бакланов отмечает важность выполнения такой процедуры для всего ЦОД. «В мире такие тесты делаются часто, если не сказать постоянно. В России измерения подобного уровня вообще не выполняются», — с горечью констатирует он.

БЫСТРЫЙ ETHERNET МОЖНО НЕ ПРОВЕРЯТЬ?

Помимо общих факторов, приводящих к росту объемов трафика, необходимость во все более скоростных интерфейсах в сетевом оборудовании ЦОД стимулирует и технология виртуализации. Чем больше виртуальных машин формируется в рамках одного физического сервера, тем больше становится нагрузка на его систему ввода/вывода — следовательно, необходим более скоростной сетевой интерфейс. Неудивительно, что, по некоторым данным, в Европе уже до 80% новых подключений в ЦОД осуществляется по 10-гигабитной технологии. Насколько большое внимание заказчики уделяют тестированию новых решений 10GbE, 40GbE и 100GbE? Как свидетельствуют опрошенные нами эксперты, не слишком большое.

«Наши приборы для тестирования каналов 10G и 100G покупают и широко используют и в России, и в других странах, но только не владельцы ЦОД, а операторы, — рассказывает Игорь Бакланов. — По интерфейсам Ethernet — 10GbE или 100GbE — проходит граница ответственности между операторами, клиентами и самим ЦОД. Там, где есть граница ответственности, есть место измерениям, контролю качества, SLA и поиску возможных неисправностей — там требуются приборы. Из иерархии я бы исключил 40G — складывается ощущение, что эту промежуточную остановку наши операторы могут перескочить, перейдя сразу от 10- к 100-гигабитным каналам. Внутри ЦОД тесты систем Ethernet 10GbE и 100GbE, как правило, не выполняются».

О проведении приемо-сдаточных испытаний каналов 40G и 100G (не обязательно Ethernet) в сетях операторов связи, а также о периодической их проверке в соответствии с установленным регламентом говорит и Алексей Засецкий. Отсутствие тестирования высокоскоростных систем Ethernet в ЦОД он объясняет следующим обстоятельством: заказчик полагается на то, что в случае возникновения неполадок, системный интегратор выполнит свои обязательства по их устранению (в рамках контрактов по поддержке поставленного решения).

И SAN ТОЖЕ?

Схожая ситуация имеет место и с решениями для сетей хранения (SAN). Ведущие российские поставщики КИО отмечают, что за все время ими были проданы лишь единицы анализаторов Fibre Channel.

Возможно, отсутствие потребности в тестировании сетей SAN связано с тем обстоятельством, что в России в подавляющем большинстве случаев эти сети являются локальными, то есть связывают серверы и хранилища данных, находящиеся в одном и том же помещении или в разных помещениях одного здания. Кроме того, как отмечает Алексей Засецкий, сети SAN, как правило, проектируются с огромным запасом и в реальности используются лишь на 1–3% от своей максимальной производительности, так что проблем в них обычно не возникает. Поэтому потребность в их тестировании невелика, она несравненно меньше потребности в тестировании сетей Ethernet».

Эта ситуация существенно отличается от той, что имеет место в Европе.

Согласно европейскому законодательству, публичные компании должны иметь географически разнесенные резервные хранилища данных или ЦОД, поэтому многие сети SAN являются территориально распределенными с протяженными волоконно-оптическими линиями связи, в которых могут возникать ошибки при передаче длинных кадров протокола Fibre Channel (FC).

«Европейским компаниям приходится тестировать ВОЛС на пригодность для передачи трафика FC и проверять способность оборудования SAN передавать трафик на относительно большие расстояния, а также осуществлять мониторинг работы ВОЛС, по которым передается трафик FC, — рассказывает Алексей Засецкий. — Как показывает общение с европейскими операторами связи, аренда оптических каналов для передачи трафика FC — это довольно востребованная услуга. Когда же я спрашивал представителей российских операторов о том, сдают ли они в аренду каналы для пропуска трафика FC, ни один из них даже не смог вспомнить, что это такое и зачем это нужно».

Потребность в тестировании конвергентных решений, позволяющих передавать трафик FC по сетям Ethernet (FCoE), в которых дополнительно реализованы механизмы передачи без потерь (DCB), пока также минимальна. Такие решения к тому же еще не получили широкого распространения — согласно опросу, проведенному в сентябре 2012 года «Журналом сетевых решений/LAN», их используют только в 10% ЦОД. Кроме того, в большинстве случаев FCoE применяется на уровне доступа, то есть на каналах между серверами и коммутаторами, а заказчики полностью полагаются на производителей и системных интеграторов.

«Отдельно взятое тестирование решений FCoE/DCB не имеет смысла, если мы не занимаемся научнотехническими исследованиями новых технологий в лаборатории, — полагает Игорь Бакланов. — Тесты FCoE/DCB — это путь производителя, но не владельца ЦОД. Можно эффективно ставить эксперименты по использованию FCoE/ DCB и аналогичных технологий для оптимизации показателей PASS (см. «PASS — пропуск на рынок»). Но делать это нужно комплексно: измерили показатели PASS — внедрили новую технологию — опять измерили PASS — сделали вывод, стало лучше или нет, — соответственно, приняли или не приняли оптимизацию за счет новой технологии».

ВСЕ ВНИМАНИЕ — МОНИТОРИНГУ

Если интерес к предварительному тестированию не слишком велик, то вот на системы мониторинга наблюдается устойчивый рост спроса. Как отмечает Владимир Демиденко, эта тенденция не зависит от экономической ситуации — более того, в период всеобщего сокращения издержек компании как никогда нуждаются в инструментах контроля затрачиваемых средств. Но и здесь внедрение, к сожалению, носит «случайный» характер — пока не произойдет какой-нибудь инцидент, раскрытие которого существующими средствами займет непозволительно много времени. По этой причине системы мониторинга зачастую разрозненны, не предполагают корреляцию событий и предлагают заказчику весьма ограниченный обзор. Основной недостаток подавляющего большинства существующих систем мониторинга, по мнению экспертов компании Fluke Networks, — это привязка к тому или иному производителю оборудования. «Часто в современных ЦОД можно насчитать сотни различных систем мониторинга, не связанных друг с другом и не позволяющих сделать правильный вывод просто потому, что все они следят исключительно за «своим» продуктом», — говорит Владимир Демиденко.

Тем не менее эксперты отмечают повышение интереса заказчиков к средствам мониторинга, которые смогут обеспечить постепенное расширение области обзора, а также корреляцию событий и интеграцию со средствами мониторинга других вендоров. Примером одного из таких решений «на вырост» может служить система Visual Performance Manager компании Fluke Networks. Она реализует распределенную модульную концепцию мониторинга — начиная с одного сервера до сети национального масштаба, — при этом хорошо интегрируется с такими известными системами, как Tivoli, OpenView и др.

Рисунок 2. Один из вариантов зондов, используемых в системе wiSLA.

Системы мониторинга особенно актуальны в распределенной среде, например при взаимодействии территориально распределенных ЦОД или при доступе к услугам ЦОД. В частности, они позволяют контролировать выполнение соглашений об уровне обслуживания (SLA). «Заключаемые сегодня SLA можно разделить на две категории, — рассказывает Алексей Засецкий. — Традиционные SLA регулируют доступность сервиса. SLA второго типа призваны обеспечить уверенность пользователей в том, что при перемещении в другой ЦОД приложения не будут работать хуже, чем до этого. Такие SLA нужны, чтобы убедить потенциальных клиентов в том, что инфраструктура нового ЦОД не станет источником проблем для переносимых в него приложений». Для активного мониторинга сетей специалисты Syrus Systems разработали решение «Рентген для IP-сетей», которое основано на ПО IxChariot компании Ixia. Они отмечают, что в России спрос на это ПО и решения на его основе растет. Кроме того, все больше компаний встраивают IxChariot в свои продукты.

Соглашение SLA обычно привязано к точке демаркации (разделения ответственности): это могут быть внутренние точки демаркации ЦОД (например, между оборудованием разных производителей, между двумя зданиями и пр.) или внешние точки демаркации (ЦОД — оператор, ЦОД — клиент). «В точках разделения ответственности измерения не просто желательны — они необходимы, — настаивает Игорь Бакланов. — В противном случае неизбежно возникает конфликт, который существенно тормозит развитие бизнеса».

Компания PR Group успешно развивает российскую систему мониторинга и управления конфликтами wiSLA. Она используется, в частности, в двух первых проектах электронных городов и в обоих случаях непосредственно способствовала реализации облачных систем. Особенность системы wiSLA — сочетание метрологии измерений качества, документооборота SLA, процессного подхода к оповещению и системы структурирования и отображения информации. В настоящее время количество зондов системы превысило 15 тыс. (см. Рисунок 2). Но, по мнению Игоря Бакланова, это далеко не предел, особенно с учетом количества потенциальных конфликтов.

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

КАК ЗАХВАТИТЬ ТРАФИК В ФИЗИЧЕСКОЙ СЕТИ

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

Эксперты рекомендуют предусмотреть возможности захвата трафика еще на этапе проектирования и построения сети ЦОД. «Сегодня в Европе и Азии при создании кабельных инфраструктур крупных ЦОД все чаще планируется изначальная установка пассивных ответвителей на все волоконно-оптические магистрали, — рассказывает Алексей Засецкий. — Эти ответвители размещают в стойке рядом с оптическим кроссом, и число их равно числу линий на кроссе. Важность этой новой тенденции возрастает в связи с внедрением в ЦОД высокоскоростных технологий 40G и 100G. Они позволяет значительно уменьшить число линий связи в ЦОД и снизить стоимость обслуживания сети, но при этом повышаются требования к надежности каждой высокоскоростной линии, поскольку ее отказ повлияет на работу большего числа пользователей и приложений».

Рисунок 3. Схема подключения анализатора к линии через пассивный ответвитель.

Очевидно, что в процессе эксплуатации ЦОД магистральную линию нельзя разъединить даже на несколько секунд, чтобы вставить в нее ответвитель для подачи трафика на устройство мониторинга. Поэтому и необходимо изначально провести все волоконно-оптические линии ЦОД через пассивные ответвители. При возникновении каких-либо сетевых проблем через эти ответвители можно будет быстро подключить нужные диагностические устройства к интересующим линиям без их разъединения (см. Рисунок 3). «Если не установить пассивные ответвители заранее, то потом сделать это будет гораздо труднее, и не только из-за сложностей с разъединением высокоскоростных линий: в шкафу рядом с кроссом может просто не найтись ни одного свободного юнита, — объясняет специалист Syrus Systems. — Цена этих ответвителей невелика по сравнению со стоимостью портов 40G и 100G и с возможными суммами убытков из-за вынужденного простоя сети».

В любой работающей системе рано или поздно возникает потребность захвата трафика, утверждает Владимир Демиденко. «Хорошо еще, если в проект было заложено развертывание системы обнаружения и предотвращения вторжения, тогда, скорее всего, точки контрольного подключения предусмотрены, — продолжает он. — Но чаще всего инженеры просто забывают о необходимости установить ответвители, надеясь на существующие возможности регенерации трафика самими сетевыми устройствами. Такой подход чреват серьезными осложнениями: во-первых, в момент, когда снятие трафика окажется необходимым, на сетевом устройстве могут попросту отсутствовать ресурсы для такой операции, во-вторых, организация такого ответвления требует изменения конфигурации критичного оборудования, на что не всякий оператор ЦОД согласится. В результате во многих случаях оказывается невозможно быстро сузить область поиска в случае возникновения аномалий в работе сетевых приложений, которые не вызваны падением канала или отключением оборудования».

Рисунок 4. В специальное шасси высотой 1U можно установить до 24 ультракомпактных пассивных волоконно-оптических ответвителей Flex Tap производства Net Optics.

Производители чутко реагируют на запросы со стороны отрасли ЦОД. Так, например, компания Net Optics в сентябре 2012 года выпустила семейство ультракомпактных пассивных волоконнооптических ответвителей Flex Tap. В специальное шасси высотой 1U можно установить до 24 (!) ответвителей этого семейства (см. Рисунок 4). В нем есть модели для многомодового и одномодового волокна, имеющие разные коэффициенты деления мощности (от 50/50 до 90/10) и предназначенные для использования на каналах с пропускной способностью 1, 10, 40 или 100 Гбит/с.

Помимо ответвителей, в состав инфраструктуры мониторинга могут входить специальные коммутаторы — например, выпускаемые той же Net Optics или компанией Ixia: они обеспечат агрегирование, разветвление и переключение отводимого трафика на различные сетевые анализаторы.

А В ВИРТУАЛЬНОЙ СРЕДЕ?

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

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

Так каким же образом «извлечь» трафик из виртуального коммутатора? На самом деле ситуация не безнадежна, и поставщики сред виртуализации уже реализуют в таких коммутаторах SPANпорты, через которые трафик может быть выведен наружу. Однако, как утверждает Алексей Засецкий, при этом на выводе трафика может теряться до половины производительности виртуального коммутатора.

Рисунок 5. Виртуальный ответвитель Phantom компании Net Optics копирует и выводит наружу передаваемый между виртуальными машинами трафик для анализа, не загружая виртуальный коммутатор.

Специалисты Syrus Systems рекомендуют использовать виртуальный ответвитель Phantom компании Net Optics, который не загружает виртуальный коммутатор (см. Рисунок 5). «На рынке нет другого такого решения, которое было бы совместимо со всеми платформами виртуализации и обеспечивало бы полный контроль передаваемого между ними трафика без установки какого-либо ПО на виртуальные машины. Кстати, VMware лицензирует его и поставляет в составе одного из своих решений. В мире этот продукт очень востребован, но в России спрос на него пока невелик (еще ни один Phantom здесь не продан), но ряд компаний успешно протестировали его, — рассказывает Алексей Засецкий. — Phantom — не дешевый продукт (этот виртуальный ответвитель стоит дороже физического), а у нас еще немногие компании готовы платить большие деньги за ПО, и особенно за дополнительное».

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

Александр Барсков — ведущий редактор «Журнала сетевых решений/LAN». С ним можно связаться по адресу: ab@lanmag.ru.