Сенсоры в невидимом мире

Виртуальные среды используют внутреннюю коммуникацию посредством коммутаторов и сетевых карт, реализованных программными средствами. Такой сетевой трафик невидим для традиционных инструментов анализа, размещенных перед хостом виртуализации (см. Рисунок 1). Некоторые процессы, происходящие внутри виртуальных коммутаторов, создают дополнительные затруднения при анализе, даже если виртуальные машины оснащаются снифферами. Так, режим приема всех пакетов (Promiscuous Mode) по умолчанию отключен. Это значит, что виртуальные машины не способны видеть целевой (Unicast) трафик, направленный к другим узлам в сети. Кроме того, виртуальные коммутаторы компании VMware способны блокировать сетевой трафик от узлов, маскирующихся под другие сетевые узлы (функция блокировки передачи с «поддельных» адресов — Forged Transmit Blocking). В результате уязвимые места или активное вредоносное программное обеспечение могут остаться незамеченными, а поиск неполадок затрудняется. Изолированный мир внутренней коммуникации между виртуальными компонентами порождает проблемы, когда пользователям требуются статистические данные о нагрузке на сеть или нужно произвести анализ правовых аспектов передаваемого трафика.

Рисунок 1. Сетевой трафик между виртуальными машинами не удастся захватить посредством традиционных решений для анализа сети.

ГИПЕРВИЗОР: ВИРТУАЛЬНЫЙ ДИСПЕТЧЕРСКИЙ ПУЛЬТ

В плане функциональности виртуальные коммутаторы уже давно достигли уровня своих физических прототипов. Располагаясь внутри гипервизора хоста виртуализации, они обладают существенно более широкими возможностями, чем «реальный» физический коммутатор. Благодаря прямой привязке к гипервизору, виртуальный коммутатор «знает» больше, чем физическое устройство: ему не нужно узнавать MAC-адреса, адреса для целевой передачи трафика или информацию об участниках групповой рассылки (Multicast) — он получает эти сведения напрямую от гипервизора. Поскольку обмен данными осуществляется в оперативной памяти (RAM), настройки скорости и дуплексного режима не имеют «реальных» последствий. Здесь не может быть никаких коллизий или ошибок сигнализации, как это бывает в случае использования физических соединений Ethernet.

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

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

Аналогично портам доступа для тестирования (Test Access Port, TAP) физических устройств, теперь доступно программное обеспечение с функциями TAP, предназначенное для работы на гипервизоре. TAP включается в сетевое соединение и транслирует проходящие сквозь него пакеты на выделенный высокоскоростной порт. Программные TAP (к примеру, Phantom Monitor для VMware компании Net Optics) размещаются в гипервизоре под виртуальными коммутаторами. Такие TAP позволяют осуществлять репликацию всего сетевого трафика внутри виртуального коммутатора и использовать фильтры. Кроме того, они могут копировать данные на выделенный физический сетевой интерфейс. При этом система генерирует данные NetFlow, и полученную информацию можно интегрировать в существующую среду управления (Management Framework).

Важно, чтобы программный TAP мог однозначно идентифицировать и те виртуальные машины, которые перемещаются между физическими хост-системами посредством VMotion. Phantom Monitor способен отслеживать действия VMotion и предоставлять верные данные даже после переезда виртуальной машины в другое место (см. Рисунок 2). Особенно в крупных средах с множеством хостов необходимо собрать все отдельные экземпляры TAP воедино и объединить их в централизованной консоли, иначе будет утрачен общий контроль над потоками данных. Само собой разумеется, виртуальный TAP должен соответствовать чрезвычайно высоким требованиям к стабильности, ведь он работает в святая святых хоста виртуализации — в гипервизоре. Поэтому при внедрении такого программного TAP в рабочую среду следует обратить внимание на наличие надлежащей сертификации от производителя гипервизора. Кроме того, данное программное обеспечение должно довольствоваться минимальными ресурсами, ведь каждый лишний процент вычислительной мощности будет отниматься от виртуальных машин и их приложений. Посредством протокола общей инкапсуляции маршрутизации (Generic Routing Encapsulation, GRE) аналитические данные можно передать от хоста через изолированный туннель на другой IP-адрес в сети, и тогда анализ может осуществляться на любом специально выделенном компьютере. Для этого виртуальный TAP упаковывает данные в туннель GRE и отправляет трафик через физический сетевой интерфейс на сетевую карту системы, выполняющей анализ. Туннель GRE заканчивается на компьютере, выполняющем измерения, а инкапсулированный трафик может анализироваться по мере необходимости.

Рисунок 2. Взгляд за «виртуальные» кулисы.

ПРИМЕР ИСПОЛЬЗОВАНИЯ: МУЛЬТИСЕГМЕНТНЫЙ АНАЛИЗ

Рисунок 3. Синим цветом выделен пакет с IP 50776: слева — на стороне глобальной сети, а справа — оригинал из виртуальной машины.

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

Мультисегментный анализ локальной сети позволяет очень наглядно сравнить трафик данных в виртуальной среде с трафиком в реальном мире (см. Рисунок 3). Слева показан трафик данных перед физическим коммутатором, справа — в виртуальной среде.

К удивлению всех участников выяснилось, что виртуальный сервер почему-то создает кадры увеличенного — свыше 30 тыс. байт — размера (Jumbo Frames), хотя не должен этого делать. При переходе в физическую среду эти увеличенные кадры дробились на пакеты данных размером 1514 байт, попадали в Интернет, и клиент на стороне WAN квитировал их правильно. Так происходило до тех пор, пока при передаче по соединению глобальной сети не терялся какой-нибудь пакет.

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

ЗАКЛЮЧЕНИЕ

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

Тимур Ёцкан — менеджер по развитию каналов сбыта и бизнеса в регионе ЕМЕА в компании Network Performance Channel, Маттиас Лихтенеггер — менеджер по региону DACH (Германия, Австрия, Швейцария)/Центральная и Восточная Европа в компании Wildpackets, а Штефан Хаберланд — инженер по продажам (сетевые технологии нового поколения) в Brainworks Computer Technologie.