Доброго времени суток, уважаемые коллеги!
Совсем недавно у нас в Microsoft, в офисе на Крылатском было мероприятие посвященное System Center 2012 SP1, многим новинкам которые появились в сервис-паки были представлены на данном мероприятии. Однако, мы с коллегами проанализировали данные мероприятия, посмотрели что у людей вокруг с SP1 творится и пришли к выводу… что тему виртуализации сетей, концепт этой технологии плохо понятен рядовому системному администратору. Я имею в виду не саму технологию, а как она реализуется в продуктах MS и какие технологии отвечают за виртуализацию сети в Windows Server 2012 и System Center 2012 SP1.
У нас недавно было несколько постов на Хабре на тему виртуализации сети, но мы решили уделить особое внимание этому вопросу, так как тема действительно сложная и критично необходимая.
И так, давайте обо всем по порядку.
Виртуализация сети
Виртуализация сети — это технология, механизм виртуализации который позволяет абстрагироваться от физического уровня работы с сетью до уровня логического, т.е. до уровня программных софтверных механизмов. Также под виртуализацией понимается и типичная консолидация, но здесь она носит немного другой характер. Под консолидацией сети подразумевается возможность создать несколько, множество виртуальных сетей поверх общей телекоммуникационной среды, проще говоря — поверх обычных сетевых адаптеров. Таким образом можно разнести инфраструктуру поверх очень большого количества оборудования. Решение скорее для провайдеров, чем для средних компаний, или для крупных компаний со сложной гетерогенной инфраструктурой.
Однако виртуальные сети — это, конечно, хорошо — но что на счет безопасности? Да и вопросы масштабируемости закрытыми не назовешь такой технологии. И вот для этого в технологиях виртуализации сети присутствует понятие изоляции — простыми словами это механизм, который позволяет работать множеству изолированных сетей поверх общего физического канала таким образом, что ни один канал не знает о существовании друг друга и ведет себя так, как будто он работает поверх собственного выделенного физического канала. Это очень важный момент, поскольку он позволяет реализовывать такие нынче популярные тренды, как BYOIP (Bring Your Own IP) и BYON (Bring Your Own Network) на практике. Эти подходы интересны в первую очередь для провайдеров и представляют собой возможность полностью перенести и сохранить всю сетевую адресацию при миграции инфраструктуры в облако на базе System Center 2012 SP1 и Windows Server 2012 SP1, а второй механизм позволяет также перенести и всю конфигурацию сети за счет ее виртуализации (самой сети и ее компонентов — шлюзов, адресов, виртуальных адаптеров, создание логических коммутаторов и категоризация портов сетевых адаптеров по определенным параметрам и т.п.). Но это уже совсем сложные сценарии, так что пока давайте разберемся с самыми основами, про более сложные вещи погорим с вами в следующих постах на Хабре.
Who is Ху или как-бы понаглядней
Не мудрствуя лукаво, перед тем как рассказывать про всякие там элементы инфраструктуры и дабы не вгонять читателя в больший конфуз, предлагаю в начале ознакомиться с принципиальной схемы устройства компонентов сети с точки зрения вопросов виртуализации сети и возможностей Windows Server 2012 и System Center 2012 SP1.
Рисунок 1. Принципиальная схема виртуализации сети
Я специально не стал убирать англоязычные названия, так как многим они пригодятся в работе с WS и SC. Ну а перевод прилагается — так что все понятно. Ну и глядя на схему, давайте кратко опишем принцип работы такой сети, начиная с физического уровня и заканчивая уровнем клиентов (в данном случае это уровень ВМ). На самом низком уровне, как оно и положено, находится физическая есть, сама среда передачи данных, аппаратная инфраструктура, физические каналы, железо, сеть — называйте как хотите.
Дальше у нас с вами есть хосты виртуализации Hyper-V и они у нас включают в себя два важных элемента — логические коммутаторы (logical switches) и профили Uplink-порта на физическом сетевом адаптере. То есть хост Hyper-V представляет собой интерфейс для доступа к физической среде — с одной стороны, виртуализацию сети и предоставление интерфейса для ВМ — с другой. Поскольку логический коммутатор представляет с собой набор виртуальных коммутаторов Hyper-V с идентичными настройками то мы можем с вами говорить о том, что логические коммутаторы в совокупности представляют собой логическую сеть (logical network). По логике вещей конфигурация из логических коммутаторов составляющее логическую сеть можно классифицировать как сайт (site) — единое непрерывное сетевое пространство.
А вот дальше, уже, на уровень выше, у нас с вами начинается уже непосредственно виртуализация сети (даже лучше «сетей»). Следующий уровень — Сеть ВМ. Сеть виртуальных машин представляет собой следующий уровень виртуализации уже именно сетей — поскольку сети виртуальных машин, как уровень виртуализации, способны к изоляции собственной инфраструктуры, то есть именно этот слой позволяет создавать нам виртуальные изолированные сети, которые не имеют доступа друг к другу — фактически каждая сеть воспринимает себя как единственно-физическую в своем окружении.
Поверх сетей у нас находятся виртуальные машины, а общаются они с сетью средствами виртуального сетевого адаптера. Собственно говоря с точки зрения вопросов управления и развертывания (System Center 2012 VMM SP1) — есть профили портов и они применяются поверх сетевых адаптеров виртуальных машин, задавая им необходимые сетевые настройки.
Это если вкратце как оно работает — теперь давайте подробней посмотрим какие новшества в VMM 2012 SP1 помогают нам в работе.
Компоненты VMM
Теперь давайте рассмотрим компоненты VMM 2012 SP1 с точки зрения всего вышесказанного.
Итак, в порядке появления в VMM:
1) Логические сети (logical networks) — в контексте VMM, логическая сеть это необходимое условие для дальнейшего создания сетей ВМ, то есть механизм который использует виртуализацию сети хостов и представляет его как единое непрерывное сетевое пространство, поверх которого можно «нарезать» виртуальные изолированные сети. Этот объект мы создаем всегда в первую очередь, когда говорим о виртуализации сети в VMM 2012 SP1.
Рисунок 2. Логические сети в VMM 2012 SP1
Сам по себе механизм виртуализации сети заложен в Windows Server 2012 — и по сему 12-ый сервер — единственная ОС от MS которая позволяет реализовать виртуализацию сети без пресловутого метода VLAN'ов, но также позволяет использовать данный метод самим конечным пользователям внутри их виртуальной сети. Сама фишка поддерживается на уровне драйвера сетевого адаптера — поэтому не забудете его активировать на самом физическом адаптере, поверх которого вы будете назначать виртуальный коммутатор.
Рисунок 3. Активация драйвера сетевой фильтрации для виртуализации в Windows Server 2012
Далее мы как раз-таки и создаем саму логическую сеть — а после нехитрых манипуляций с драйвером мы можем использовать и виртуализацию сетей для их изоляции.
Рисунок 4. Создание логической сети с возможностью последующего создания изолированных сетей ВМ
2) В простейшей конфигурации для реализации виртуализации сетей все, что было бы необходимым сделать для «нарезания» бесконечного числа (образно) изолированных сеток — это воздание сети ВМ (VM Networks). Это по сути объект логической сети которая строится поверх логической сети и предоставляется как инфраструктура сети для обмена данными между ВМ. B вот теперь мы можем создавать изолированные виртуальные сети (сети ВМ) для выделенных изолированных инфраструктур.
Рисунок 5. Создание сетей ВМ в SC VMM 2012 SP1
Как вы видите, изоляция распространяется на адреса IPv4 и IPv6 выборочно или же единовременно. Также есть возможность создать сеть без изоляции — в этом случае область сети ВМ будет совпадать с областью логической сети — такие конфигурации сетей ВМ используют с целью предоставление доступа к объектам инфраструктуры VMM и частного облака.
3) Далее в VMM мы с вами встретим еще один интересный компонент — это пулы MAC-адресов (MAC Address Pool). Данный механизм интересен с точки зрения управления и развертывания инфраструктурой. Проще гововря — у каждого производителя оборудования есть свой пул MAC-адресов, которые они назначают своим устройствам. Поскольку в пределах одного вендора оборудования, как правило, используются схожие драйвера и компоненты — это позволяет автоматизировать задачи развертывания кластеров Hyper-V с нуля, включая необходимые компоненты для категории серверов. Допустим, у нас есть 3 вендора оборудования: Dell, IBM и HP.
Рисунок 6. Пулы MAC-адресов
Мы можем подготовить свои образы развертывания для каждой группы серверов, тем самым исключив вероятность дисконфигурации хоста, а благодаря MAC-адресам мы гарантируем соответствие образа с нужными драйверами и компонентами с оборудованием, на которое они разворачиваются.
4) Дальше в VMM у нас присутствует такой элемент, как балансировщики нагрузки (load balancers) — это могут быть как аппаратные, так и виртуальные элементы инфраструктуры, которые позволяют обеспечивать как отказоустойчивую, так и увеличенную полосу пропускания к необходимому сервису, который запущен на виртуальных машинах. Иными словами — привычный балансировщик. По умолчанию поддерживает работу с Microsoft NLB (а кто бы сомневался!?), но поддержка сторонних балансировщиков осуществлена через провайдер — допустим, вы можете поставить Citrix NetScaler и использовать его. Только помните — прежде чем использовать балансировщик — вы должны установить провайдер для работы с ним на сервере VMM и перезапустить его службу (VMM). Также вам понадобятся реквизиты доступа к вашему балансировщику.
Рисунок 7. Регистрация баласнировщика Citrix NetScaler
5) Сам по себе балансировщик — штука полезная, но в данному случае неэффективная, а вот если мы будем использовать профили VIP (Virtual IP) — виртуальных IP-адресов в сочетании с балансировщиками и задействуем их при развертывании и масштабирования наших сервисов — инструмент отличный. Иными словами профиль VIP — это виртуальный IP-адрес, который получает ваш сервис при развертывании из шаблона VMM. Этот адрес скрывает под собой все компоненты инфраструктуры сервиса (web-сервера, СУБД и прочие) и позволяет таким образом внутри сервиса организовать ферму и кластер для решения вопросов доступности и масштабируемости, ведь при развертывании сервиса из шаблона и использовании балансировщиков с VIP-профилями мы можем на лету создавать необходимые компоненты сервиса (в виде ВМ) — и сразу же добавлять их в общий пул для работы, а поскольку VIP-шаблон производит по сути виртуализацию IP-адреса внешней среды — того канала, откуда пользователи получают услугу.
6) Перед тем как подробнее говорить про логические коммутаторы (logical switches), давайте посмотрим на одну картинку ниже:
Рисунок 8. Требования для создания логического коммутатора в VMM
Из того, что мы видим следует то, что просто так создать логический коммутатор нам никто не даст — есть ряд некоторых условий:
a) Сначала нам необходимо создать логическую сеть и сети ВМ — ну с этим мы уже разобрались.
б) Дальше нам необходимо понимать, будем ли мы использовать расширения виртуального коммутатора Hyper-V из Windows Server 2012 — и если да, то нам нужно необходимо зарегистрировать провайдер в VMM для работы с ними. Здесь речь идет именно о механизмах расширенных возможностей коммутатора — фильтрация трафика или же дополнительных возможностей за счет сторонних дополнений.
в) Если же мы не планируем использовать прошлый сценарий ни на базе WS2012, ни на базе сторонних решений интеллектуального перенаправления, то нам не остается ничего другого, кроме как создать профили нативных портов (native port profiles) и портов для виртуальных машин для дальнейшего их сопоставления друг другу. Данный механизм фактически предъявляет требования по настройкам именно драйвера сетевого адаптера и сопоставления требований с фактическими возможностями драйвера. Иными словами мы можем логически разделить трафик по его типу (служебный, коммуникационный, SAN-трафик и прочие его типы) и применять эти настройки с точки зрения сети как механизм сопоставления настроек и поведения адаптеров хостов Hyper-V, который подключены к нему (физические адаптеры) с профилями портов виртуальных адаптеров внутри ВМ. Иными словами это механизм который с одной стороны разделяет логически трафик от комутатора до хоста, назначает физическим адаптерам определенную кофигурацию для обработки того или иного типа трафика, а на виртуальных машинах этот же механизм используется для определения свойств виртуальных адаптеров внутри ВМ, чтобы сопоставить их со свойствами адаптеров хоста — как крезультат — автоматическое назначение портов.
Рисунок 9. Создания профиля типа uplink
Как вы видите, при создании профиля нативного порта вы можете выбрать тип профиля, и собственно область его действия. Uplink — для применения на сетевые адаптеры, которые обеспечивают работу виртуального коммутатора, а профили виртуальных адаптеров — собственно работают на уровне адаптеров виртуальных машин. Область действия профиля же назначается на уровне логической сети.
И вот тут наступает самый интересный и связующий момент. Есть еще один компонент — классификация портов (Port Classification) — это собственно говоря, механизм для группирования профилей нативных портов. То есть вы создаете различные профили портов, допустим с низкой скоростью, но для разного типа трафика — и объединяете дальше эти порты в классификацию «Slow». И когда вы создаете логический коммутатор, вы указываете сразу в нем канал для выхода во вне (uplink) и задаете сразу классификации портов, включая все необходимые профили. Так как профиль распространяется на логическую сеть, то область его действия определяет и область действия логического коммутатора. Классификации портов также применяются при создании облака в VMM.
7) И последний механизм-компонент в VMM — это шлюзы (gateways). Шлюзы, как ясно из их названия, предназначены соединять между собой разрозненные и изолированные сети в единую непрерывную сеть. Иначе говоря, это механизмы удаленного доступа и взаимодействия на уровне сетей и их границ. Компонент шлюзов в VMM также использует сторонние инструменты и провайдеры для работы со шлюзами. Шлюзы могут быть как аппаратные так и программные. Шлюзы также могут использовать механизмы VPN для обеспечения своей деятельности. Также шлюзы позволяют использовать сценарии гибридного облака при создании гибридной сети Windows Azure VM. А если проще и по основному — то вы можете с помощью шлюзов соединять между собой виртуальные изолированные сети или же виртуальные сети с внешними сетями клиентов с помощью привычных для них инструментов (ну это если железо идентичное либо с функционалом и механизмами взаимодействия).
Ну что же, уважаемые коллеги!
На этом рассказ про концепцию виртуализации сетей окончен, но только на сегодня.
В дальнейшем я планирую рассказать про более сложные сценарии и варианты использования всех этих и сторонних компонентов в комплексе.
Так что следите за новостями и держите руку на пульсе!
С уважением,
человек-огонь
Георгий А. Гаджиев
Эксперт по информационной инфраструктуре
Microsoft Corporation
Автор: GeorgyGadzhiev
