Теория и практика Open vSwitch. Часть 1. Виртуальный распределенный коммутатор

 АЛЕКСАНДР РУДЕНКО, системный администратор, работает в Молдавии на крупном энергетическом предприятии. Предпочтения - виртуализация на базе ядра Linux (KVM, Xen, ESXi) и все, что с ней связано. Много читает, активно занимается спортом

Теория и практика Open vSwitch
Часть 1. Виртуальный распределенный коммутатор

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

Зачем и для чего?

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

Какое-то время в средах виртуализации на базе KVM и Xen для решения данной задачи использовался встроенный в ядро Linux коммутатор второго уровня – Linux Bridge (мост, он же разновидность коммутатора) [1]. В принципе он и сейчас используется по умолчанию в некоторых дистрибутивах как наиболее простое решение. Linux-мост позволяет создавать виртуальные интерфейсы для ВМ, а также коммутировать их между собой и внешним миров через физические интерфейсы узла.

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

Связанность состояний и правил, таких как правила маршрутизации, ACL, QoS, мониторинга, закрепленные за сетевым объектом (ВМ) при перемещении на другой физический узел, – это основной список требований к коммутатору ввиртуальной среде. Здесь нам на помощь и приходит распределенный, управляемый, многоуровневый виртуальный коммутатор, каковым и является Open vSwitch (далее OVS).

OVS – это свободный аналог коммерческих VMware Distributed vSwitch и Cisco Nexus 1000v, изначально развиваемый компанией Citrix, а теперь уже и многочисленным сообществом, включающим специалистов из Red Hat, Canonical, Oracle идругих компаний. Он базируется на некоторых уже имеющихся в ядре компонентах, например, том же Linux Bridge и штатном стеке QoS плюс собственных разработках, реализующих дополнительный функционал.

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

Управление коммутаторами, создание правил и их перемещения на каждом из узлов осуществляются централизованно с помощью протокола OpenFlow. Поддержка NetFlow [2] и s++Flow [3] позволяет мониторить и анализировать состояние сети по множеству аспектов, учитывать трафик ВМ. Также реализована сетевая база данных состояний (OVSDB), которая поддерживает удаленные триггеры. Поэтому часть программного обеспечения оркестровки может наблюдать различные аспекты сети и сообщать об их изменениях, например, отслеживать миграцию ВМ.

Кроме всего, OVS может работать с логическими тегами, так же как и его коммерческие конкуренты. Поддержка логического контекста в сети достигается посредством добавления тегов или управления ими в сетевых пакетах. Это может использоваться, например, чтобы однозначно определить ВМ (способ, стойкий к аппаратному спуфингу).

Также имеется реализация GRE-туннелирования, способная обрабатывать тысячи одновременных GRE-туннелей. Она полезна для объединения частных сетей ВМ в различных центрах обработки данных.

Статью целиком читайте в журнале «Системный администратор», №10 за 2013 г. на страницах 14-18.

Комментарии могут оставлять только зарегистрированные пользователи