Если вам в Proxmox надо подать в виртуальные машины несколько vlan-ов, то удобней будет использовать Open vSwitch.
Содержание
Подготовка [ править ]
Для начала сделайте бэкап сетевых настроек:
Настройка openvswitch [ править ]
Установите Open vSwitch на каждой ноде кластера:
После чего в GUI ноды удалите старый мост, создать новый в следующем виде:
Здесь «внутреннему» порту дали имя proxmox.
Нажав Apply configuration будет произведен перезапуск сервера (не сети).
После перезапуска всё должно работать.
Смысл происходящего [ править ]
Дальше создаётся мост, в этот мост включены все остальные порты.
Но если мы так и оставим, у нашего сервера не будет IP-адреса и в Proxmox для управления не достучаться. Чтобы достучаться, создаем «внутренний» порт с IP-адресом сервера, включаем его в мост и указываем vlan (access vlan в терминах cisco) на этот порт, если трафик в сети управления Proxmox тегированный.
Пример конфигурации Open vSwitch в Proxmox [ править ]
На всякий случай привожу содержимое файла /etc/network/interfaces, в котором адрес сервера proxmox 172.16.1.2/24 и эта сеть тегирована vlan 123:
Назначаем ВМ и контейнерам их vlan [ править ]
Чтобы сеть в ВМ и контейнерах ходила в своих vlan, надо теперь просто зайти в настройки сети ВМ/контейнера и назначить нужный access vlan. Больше нигде этот vlan в Open vSwitch вводить не надо. Исходящий трафик из порта ВМ/контейнера будет Open vSwitch тегироваться соответствующим vlan, а с входящего тег сниматься (т.е. внутри ВМ ничего с тегами настраивать не надо).
Open vSwitch в кластере Proxmox [ править ]
Чтобы работала миграция, Open vSwitch должен быть развернут на всех узлах кластера.
У себя в компании я часто сталкиваюсь, что нужно поднять какой-то сервис, чтобы «общупать» его досконально. Хотя PCшники у нас довольно мощные, но большую часть ресурсов съедают PyCharm и Chrome, а на виртуалки с экспериментами очень часто остаётся совсем мало.
Поэтому мы завели у себя небольшую стойку с парой-тройкой серверов для экспериментов и локального Gitlab’а. Но что-то пошло не так и очень захотелось поиграться с чем-то новым.
Disclaimer
Я далеко не журналист, поэтому прошу заранее простить меня за возможные ошибки в тексте. Хотя я и пробежался по тексту, но всё равно мог что-то упустить. Всегда открыт к исправлениям в личном сообщении.
Помимо всего прочего «о вкусах не спорят» и я ничего не рекламирую, а просто хочу поделиться тем, как мы решили нашу задачу. Ну и конечно же всё это можно было сделать иначе, но мне захотелось именно так.
Лирика
Ещё очень огорчало поедание ресурсов просто работающего кластера (фактически 2-3 сервера по 4CPU/16GbRAM чисто под работу пустого кластера) и необходимость держать контроллер отдельно от compute-ноды, чтобы не мешать работе (AIO отъедает в простое 35Гб ОЗУ — это как-то многовато для сервера в офисе).
Конечно можно было бы всё вынести в AWS/DO/Azure/GCE, но если есть 3-4 сервера, то почему бы их не использовать, ведь так или иначе уже имеющееся оборудование выйдет дешевле «облака».
Оборудование
Собственно об железе:
Помимо всего прочего, есть:
Последние 2 сервера были успешно оккупированы после того, как очередной внезапный ночной сбой по питанию привёл Ceph в OpenStack’е в негодность и было принято вынести их на независимые ноды. Впрочем, ничего не мешает их потом перенести в VM.
HITACHI вообще 2 шт, но мы всё вгрузили в одну машину и позже я поясню почему. Я так подробно расписываю, просто, чтобы было понятно принятое решение.
Муки выбора
Основная проблема с OpenStack была в том, что AIO был слишком прожорливым и конкурировал с виртуалками, а размазывание по хостам… Короче говоря, ванильный OpenStack как бы нам ни нравился, но не подходил под наши нужды и возможности.
Логично было бы предположить, что может стоит перейти на VMWare ESXi (как многие товарищи и предлагали). Но не лежала душа у меня к этому продукту.
Нужно было то, что можно будет хорошо закастомизировать под наши нужды (где-то в пересечении дёшево, производительно и гибко), а так же, чтобы этим было удобно пользоваться простым разработчикам, которые не хотят ничего настраивать, а только делать «фыр-фыр-фыр» кодить и ставить эксперименты.
Выбор пал на Proxmox VE, потому что:
Настройка Proxmox
Публикация далее описывает то, как я настраивал инфраструктуру только сервера с Proxmox практически в живом режиме. Перенос серверов Gitlab’а никак не описывается, потому что к этой теме никак не относится.
Сеть и маршрутизатор
Есть некоторое legacy после OpenStack по нарезке сети, в частности публичная сеть и настройки OSPF на Mikrotik’ах. Хотелось следующего:
Буду описывать как это сделать «с нуля»:
Нельзя сказать, что это прям очень правильное правило, но если кто из знатоков подскажет как правильно его написать, то буду премного благодарен. Вообще нам изоляция нужна только на L2, но на L3 привожу больше для ознакомления.
Настройка сервера
Сервер будет настроен так, чтобы получить максимальную производительность от текущих дисков. Однако мы не забываем, что всё может случиться и ночью свет может резко на час-другой пропасть пока все спят.
Так как мы ничего не хотим покупать, то следует отключить всё, что связано с подпиской:
На этом пока закончим основную настройку.
Магия сетевых интерфейсов
Вообще настройка Proxmox Bridge для работы достаточно простая. Но я не я, если не удалю гланды ректально сделаю что-нибудь экстравагантное. Мне очень хотелось, чтобы работал OVSBridge и на OVSBond. Но проблема в том, что мне так же не хотелось бы, чтобы пользователи каждый раз назначали VLAN при создании VM/LXC. Поэтому порядок настройки следующий для всех 6ти интерфейсов:
Настройка LVM + lvmcache
Добавляем второй раздел к нашему volume group:
Создаём новый раздел как нас учит документация Proxmox + небольшой хак для оптимизации snapshot’ов:
Теперь нам нужно подключить lvmcache, но в целях оптимизации ресурса SSD, я специально выделил раздел на нём размером 241Гб. Этого объёма вполне хватит для кеша, а оставшаяся часть диска будет ресурсом для убитых блоков. Правда это в теории, потому что лично мне до конца не понятно работает ли это. В любом случае, кеш в 465Гб потом будет вдвое дольше и сложнее удалять (например, чтобы заменить диск или расширить массив).
Поначалу всё работало, но потом почему-то перестало. Видимо с обновлением удалили эти модули.
Финальные штрихи
Обычно я перед перезагрузкой делаю, чтобы быть уверенным, что всё обновлено и ядро самое свежее:
К слову, в 6ой версии ядро 5.0, а на подходе (на момент публикации) вроде как 5.3.7. Всё, теперь отправляем систему в ребут. Если мы всё правильно сделали, то после перезагрузки наш сервер будет доступен извне по обоим адресам. Так же можно будет загрузить свежие шаблоны контейнеров и радоваться жизни.
Делаем красивые графики
Ну мы же не просто админы, а DevOps’ы (что это вообще значит?), поэтому нам нужно знать, когда какая-то из виртуалок взбесится и будет творить непотребства.
Контейнер с InfluxDB и Grafana
Вообще все эти действия проще всего сделать в GUI, но на меня внезапно напала агрессивная форма лени, чтобы делать скриншоты, поэтому опишу командами.
Смотрим доступные нам шаблоны:
Думаю для начала можно загрузить ubuntu-18.04-standard_18.04.1-1_amd64.tar.gz :
Создадим контейнер для InfluxDB и Grafana:
Устанавливаем пакеты InfluxDB и Grafana:
Настраиваем InfluxDB для работы. Нам для этого нужно будет сперва создать базу:
Далее, нам необходимо настроить UDP-порт, на который Proxmox будет слать запросы:
… и теперь перезапустим influx: systemctl restart influxdb
Настройка Proxmox и Dashboard
Тут всё предельно просто. На сервере с proxmox’ом нужно создать файл следующего содержания:
Файла там по умолчанию нет.
По какой-то мне неведомой причине метрики пошли не сразу, поэтому пришлось вызвать systemctl restart pvestatd на сервере проксмокса.
Теперь нам нужно всё это визуализировать. Заходим в нашу grafana по адресу http://172.16.1.101:3000/ (admin:admin), меняем пароль. Нашёл в дебрях сайта графаны, что можно прикрутить красивый дашборд для визуализации Proxmox, но его пришлось немного подпилить напильником исправить, чтобы учесть все наши реалии.
Теперь нам нужно импортировать Dashboard:
В общем-то всё. Для удобства, я дополнительно туда же подключил Dashboard’ы из Gitlab. Описывать этот процесс нет смысла, надо только иметь в виду, что Prometheus должен быть доступен с этого контейнера, его необходимо подключить как Datastore в Grafana и при экспорте дашбордов указывать, что они external, чтобы выбрать нужный datastore.
Со скриншотами из свежей Grafana косяк вышел, поэтому простите за качество.
Разделяй и властвуй. Используем Open vSwitch для разделения виртуалок между VLAN
Содержание статьи
Представь, что у тебя есть готовая инфраструктура с гипервизорами и виртуалками внутри. Задача: предоставить определенной группе виртуальных машин IP-адрес в одном широковещательном домене, другой группе — в другом, а самому гипервизору — в третьем. То есть разместить их в различных сетях.
Такая ситуация может возникнуть по разным причинам. Приведу несколько примеров.
Самый простой способ реализовать такую схему — это включить один сетевой интерфейс в одну сеть, другой в другую и настроить мосты соответствующим образом. Нельзя сказать, что такой подход на 100% правильный или неправильный, но он вполне рабочий. И значит, имеет право на жизнь. А как быть тем, у кого всего один сетевой интерфейс? В любом случае наиболее правильный метод, если есть коммутатор второго уровня (L2), — это разделить сеть на логические сегменты. Проще говоря, построить сеть на VLAN’ах.
Что нужно знать о VLAN
VLAN — это виртуальные сети, которые существуют на втором уровне модели OSI и реализуются с помощью коммутаторов второго уровня. Не вдаваясь в подробности, можно сказать, что это группа портов коммутатора, разделенная на логические сегменты сети. Каждый такой сегмент имеет свой маркер (тег PVID). Каждая группа портов VLAN’а знает о своей принадлежности к определенной группе благодаря этим тегам.
Существует два типа портов: access и trunk. В access подключаются конечные сетевые устройства, в trunk подключаются только другие trunk-порты. Если с компьютера пакет попадает на access-порт, то он помечается тегом (PVID), и далее коммутатор отправляет этот пакет только на порты точно с такими же VLAN ID или на trunk-порт. При отправке кадра конечному узлу тег снимается, так что они понятия не имеют о том, что находятся в каком-либо VLAN’е.
Когда пакет попадает на trunk-порт, он передается как есть, тег не снимается. Таким образом, внутри trunk-порта передаются пакеты с несколькими тегами (PVID).
Стоит заметить, что access-порт можно настроить так, чтобы тег на выходе не снимался, тогда для принятия пакета конечный клиент должен знать, в какой VLAN он подключен. Не все сетевые карты и/или ОС поддерживают работу с VLAN по умолчанию. Как правило, это зависит от драйвера сетевой карты.
Приступаем к настройке
Напоминаю, что в одной из предыдущих статей мы рассматривали построение виртуализации на базе Ubuntu/Debian и KVM. Поэтому исходить будем из того, что система установлена и настроена, есть два физических интерфейса, один подключен к виртуальному мосту и есть виртуальные машины, которые им пользуются. Второй интерфейс не сконфигурирован.
Теперь вернемся к нашим VLAN’ам. Чтобы наша идея работала, нам нужно подключить первый физический интерфейс нашей машины к trunk-порту коммутатора, но при этом заблаговременно разделить (а точнее, протегировать) трафик виртуалок по разным VLAN’ам.
Самый простой и примитивный вариант это сделать — создавать виртуальные сетевые карты, каждую настраивать на определенный VLAN и для каждой виртуальной карты поднять отдельный виртуальный сетевой мост, через который и подключать нужную виртуальную машину. Способ рабочий, правда есть несколько недостатков:
Но если у нас виртуальные машины, почему бы не воспользоваться виртуальным коммутатором второго уровня, в который и воткнуть все виртуальные проводки? Это решение гораздо лучше, позволяет более гибко настроить систему. Ну и использовать такой коммутатор, как самый обычный!
Гугление привело к трем наиболее популярным решениям. Одно входит в состав Hyper-V, который платный и не умеет OpenFlow. Второе: MikroTik, с помощью которого можно не только создать виртуальный коммутатор, но и перенести его конфигурацию на железный. Отпугивает только, что он базируется на полноценной операционной системе — RouterOS. А это уже совсем не то. И наконец, встречай — Open vSwitch.
Open vSwitch
Open vSwitch — программный многоуровневый коммутатор с открытым исходным текстом, предназначенный для работы с гипервизорами. Работает в Linux начиная с версии 2.6.15. Основные возможности коммутатора:
Open vSwitch используется в составе Xen Server, Xen Cloud Platform, KVM, VirtualBox, QEMU, ProxMox (начиная с 2.3).
В качестве наглядного примера будем виртуализировать сервер Kerio 9.1.4. Итак, чтобы понимать, как сейчас все устроено до переделки. Железный сервер Kerio — второй сервер виртуализации, в котором работает несколько сетевых сервисов организации: клиентские сети net1, net2, net3 и net4, серверная сеть net5. Каждый сегмент сети подключен в отдельный сетевой интерфейс «железного» Kerio.
Схема, которую будем реализовывать
Xakep #222. Логика подлога
Напоминаю: исходим из того, что сервер виртуализации уже установлен и настроен. Также установлен пакет bridge-utils и настроен сетевой мост br0. В системе присутствуют некоторые виртуальные машины, подключенные через этот сетевой мост.
Установка и первоначальная настройка
На самом деле установка Open vSwitch сводится к установке одного пакета:
После установки никаких изменений не происходит, кроме запуска сервиса OVS. Создадим коммутатор:
Посмотрим, что к нему подключено:
Схема подключения OVS и физического интерфейса
По умолчанию этот порт начинает работать как обычный и транковый порт, пропуская все VLAN’ы. Далее можно сделать этот порт транковым для указанных VLAN ID. Или можно оставить как есть, тогда порт будет пропускать все VLAN ID. У нас структура большая, сеть может каждый день меняться, поэтому оставим как есть.
Следующим шагом обнуляем конфигурацию интерфейса eth0 и отключаем его от TCP/IP-стека операционной системы:
И все! Никаких дополнительных настроек bridge, как в случае с мостом.
Проверяем пингами доступность.
Посмотрим, что изменилось у нас на виртуальном коммутаторе:
Как видим, в коммутатор подключено уже два интерфейса: физический интерфейс коммутатора eth0 и интерфейс операционной системы br1.
Теперь займемся виртуальными машинами.
Настройка групп адресов KVM
Второй путь более гибкий. Он заключается в создании групп портов KVM для OVS. Каждая группа будет принадлежать к соответствующему VLAN ID. К сожалению, настройка таких групп из Archipel или virt-manager пока недоступна. Поэтому потребуется вручную подготовить XML-файл, описывающий необходимые группы, и после этого с помощью virsh применить его.
Далее запускаем саму сеть:
И делаем запуск автоматическим:
Для удаления ненужных сетей можно воспользоваться Archipel (раздел NETWORK), virt-manager или выполнить команды
Далее переходим к созданию виртуалок через virt-manager или открываем существующую остановленную виртуальную машину.
Подключение виртуальных сетевых машин к порту коммутатора OVS
Мы же хотим настроить Kerio, но на определенных VLAN ID. Здесь существует несколько вариантов. Можно создавать несколько сетевых интерфейсов с разными VLAN ID. Или создать trunk-порт и внутри Kerio «нарезать» VLAN. Этот вариант предпочтительнее благодаря возможности более гибко маневрировать, не выключая и не перезагружая саму виртуальную машину для применения настроек.
После того как все успешно настроено, запускаем виртуальную машину и смотрим, что у нас изменилось на нашем коммутаторе:
Переходим к интерфейсу управления Kerio. Идем в раздел «Интерфейсы», далее выбираем наш интерфейс, который подключили к VLAN. Открываем его двойным кликом, выбираем вкладку «Виртуальная ЛВС → Добавить или удалить виртуальные ЛВС» и перечисляем нужные VLAN’ы. После этого жмем ОK, и у нас появляются требуемые виртуальные интерфейсы. Далее настраиваем их, как обычные физические интерфейсы, подключенные напрямую в нужные коммутаторы.
Обзор интерфейсов Kerio с подключенными VLAN ID
Заключение
Описанная в статье конфигурация позволяет очень гибко и быстро добавлять любое количество сетевых интерфейсов практически любой конфигурации. Таким же образом можно переносить виртуальные серверы в сети клиентов, держа сам гипервизор далеко. Как видишь, настройка не сложнее, чем стандартный сетевой мост, а функциональность намного больше!
Александр «Plus» Рак
Участник сообщества OmskLUG. Инженер отдела электронного взаимодействия МКУ «Информационно-технического управления».
Сетевые компоненты Proxmox, такие как мосты, vNIC, VLAN, связывание и тому подобное
Файл настройки сетевой среды Proxmox
Реализацию Open vSwitch
Добавление сетевых компонентов к ВМ
Примеры вируальных сетевых сред
Виртуальные среды со множеством владельцев
Исследование виртуальной сети
Виртуальная сеть это программно определяемая сетевая среда в которой все соединения и компоненты могут иметь, могут и не иметь прямое взаимодействие с физическим оборудованием. В большинстве случаев прямое взаимодействие с оборудованием осуществляется гипервизором или контроллером хоста. Все соединения между виртуальными машинами, виртуальными коммутаторами, виртуальными мостами и виртуальными сетевыми интерфейсами сделаны полностью виртуальными. Далее приводятся два типа сетевой виртуализации:
Внешняя виртуализация сетевой среды : Состоит из ряда локальных сетей, которые работают как одна виртуальная сетевая среда. Физические LAN могут находиться в одном месте или будут разбросаны по различным местоположениям. Обычно внешняя виртуализация является моделью на основе облачных сетевых служб, которые множество компаний могут применять для своих виртуальных сред со множеством площадок для платы за услуги. Внешняя сетевая виртуализация легко может быть получена путём объединения нескольких виртуальных сетевых сред в единую виртуальную сетевую среду при помощи WAN или Интернета с применением технологий, аналогичных VPN.
Внутренняя виртуализация сетевой среды : Обычно происходит локально в рамках гипервизора между виртуальными машинами. Не стоит путать её с локальной сетевой средой. В данном случае внутренняя сетевая виртуализация относится к коммуникации между ВМ, мостами, vNIC и тому подобными устройствами, которые не обязательно должны применять внешнюю LAN. Она предоставляет ИТ персоналу компании полный контроль над работой виртуальной сетевой среды. Проблемы сетевой среды могут диагностироваться быстрее; персональная подстройка расширения или уменьшения может осуществляться без задержки. Внутренняя виртуализация интенсивно использует виртуальные компоненты, такие как виртуальные мосты и vNIC, для формирования виртуальной сетевой среды.
Для более глубокого изучения внешней и внутренней сетевой виртуализации отсылаем вас к http://en.wikipedia.org/wiki/Network_virtualization. В особенности обратите внимание на References и список книг для Further reading внизу этой Wiki- страницы. < Прим. пер.: см. также ru.wikipedia.org/wiki/Виртуализация. >
В данной книге мы в основном сосредоточимся на внутренней сетевой виртуализации в вашем гипервизоре Proxmox. Мы также рассмотрим некоторые схемы сетевых сред для комбинаций внутренних и внешних сетей позже в этой книге в Главе 13, Установка Proxmox промышленного уровня.
Сопоставление физической и виртуальной сетевых сред
Теперь мы рассмотрим различия между физической и виртуальной сетевыми средами. Следующая схема представляет физическую среду без какой- либо виртуальной среды:
Рисунок 1
Следующая схема предоставляет виртуализацию как главную инфраструктуру:
Рисунок 2
Перед тем, как мы погрузимся в построение блоков виртуальных сетей, нам нужно понять как сетевые среды устанавливаются на предыдущих схемах. обе схемы представляют оду и ту же начальную установку учреждения в котором главное административное подразделение находится на втором этаже, а подразделение ведения учётных записей на четвёртом этаже того же здания. Из диаграммы очевидно, что физическая сетевая среда менее сложна чем виртуальная сеть, однако при возрастании виртуализации мы можем сокращать стоимости, увеличивать эффективность, снижать сложность сопровождения аппаратных средств, а также увеличивать переносимость.
Физическая сетевая среда
На схеме физической сетевой среды отсутствуют установленные виртуальные платформы. Сетевая среда настраивается с применением физических устройств, таких как межсетевые экраны, коммутаторы, серверы, а также наполненные рабочие станции. Каждое подразделение имеет свои собственные серверы и сегменты сетевой среды. Централизованное управление всей компанией отсутствует. Это затратное решение из- за всех имеющихся физических аппаратных средств. Если необходима избыточность, оно претерпит удвоение стоимости, поскольку нуждается в идентичных физических серверах. Все коммуникации в этой сети выполняются соединением физических кабелей. Резервное копирование в подобной сети является достаточно вызывающим, так как все физические серверы в обоих подразделениях должны выполнять резервное копирование на основе подискового подхода.
Виртуальная сетевая среда
Схема виртуальной сетевой среды представляет то, как Proxmox может обрабатывать установку со множеством подразделений. Все соединения между серверами и виртуальными машинами пользователей осуществляются виртуально без физических устройств физической сетевой среды. Использование виртуальных мостов и vNIC обоими подразделениями и администрирования, и ведения учётных записей, могут сосуществовать в одном и том же кластере Proxmox. Так как все вычисления производятся гипервизором, конечные пользователи могут иметь тонких клиентов для существенной минимизации стоимости. Пользователи могут соединяться со своими виртуальными машинами по протоколам удалённого доступа, таким как SPICE, VNC и RDP. < Прим. пер.: а также HDX, советуем обратиться к содержательному обзору различных протоколов доступа, проведённому фирмой Huawei: >.
Рабочие станции являются чрезвычайно низко энергопотребляющими, экономичными и базовыми компонентами для конечных пользователей, предоставляющие только самое необходимое для соединения с выделенными ресурсами серверов. Поскольку вся работа происходит в виртуальной среде, тонкие клиенты не требуют значительной производительности. Основная задача тонких клиентов состоит в предоставлении пользователям доступа к периферийным устройствам, таким как мониторы, клавиатура, мышь и сетевой кабель. Тонкие клиенты могут быть приобретены по цене ниже 200$.
В данной установке все серверы и машины пользователей виртуализованы. Если существует необходимость в новом сервере, это всего- лишь вопрос создания виртуального сервера с vNIC за несколько кликов. Так как Proxmox является гипервизором, который был построен из группы с возможностью избыточности, в подобном сценарии все виртуальные машины могут просто мигрировать на другие доступные узлы Proxmox и при этом все остаётся включённым и выполняется должным образом. Оба подразделения разделяются двумя виртуальными мостами.
С применением GUI Proxmox всё управление может быть выполнено из одной точки, включая резервное копирование и восстановление. Виртуальные серверы могут мигрировать по сетевым соединениям, которые могут распространяться на большие и малые физические расстояния. Хотя настройка виртуальных сетевых сред является намного более надёжной и обогащённой функциональностью, она имеет существенно меньшие требования к бюджету. Новое подразделения могут быть добавлены путём создания новых виртуальных мостов и использования виртуальных LAN и VLAN в существующих коммутаторах физической сетевой среды.
Сетевые компоненты в Proxmox
Теперь мы рассмотрим все сетевые компоненты Proxmox, которые позволят виртуальным машинам взаимодействовать или быть сегментированными от прочих внутренних машин, а также от Интернета.
Интерфейс виртуальной сети (vNIC)
vNIC ( Virtual Network Interface Card ) является программно определяемым представлением интерфейса MAC ( Media Access Control ) интерфейса физической сетевой среды. В основном это виртуальные сетевые карты для виртуальных машин. Множество vNIC может совместно использовать физический сетевой интерфейс узла хоста. В некотором смысле сетевая среда начинает с vNIC когда виртуальная машина отправляет данные, которые должны достичь других виртуальных машин или сетевых устройств в пределах виртуальной среды или физического окружения. На следующей схеме виртуальная машина имеет два виртуальных сетевых интерфейса назначенных на драйвер Intel e1000. Они оба настроены на работу с мостом vmbr601 :
Рисунок 3
Intel e1000 является драйвером ядра Linux применяемым для виртуализации виртуальных сетевых интерфейсов на основе архитектуры Intel. Это vNIC по умолчанию для вновь создаваемых виртуальных машин в Proxmox, поскольку он поддерживается всеми основными операционными системами, такими как s Linux, Windows и Mac OS X без необходимости дополнительных драйверов. Proxmox имеет четыре модели виртуальных сетевых интерфейсов: Intel e1000, VirtIO, Realtek RTL8139, а также VMware vmxnet3. За пределами этих четырёх моделей VirtIO предоставляет максимум сетевой производительности для ВМ. Все операционные системы на основе Linux поставляются вооружёнными драйверами VirtIO. Для Windows VirtIO драйвер может быть загружен с http://www.linuxkvm.org/page/WindowsGuestDrivers/Download_Drivers.
Для Mac OS VirtIO драйвер может быть загружен с https://github.com/pmj/virtio-net-osx.
Добавление vNIC
Если параметр Hotplug для сетевого интерфейса разрешён для данной ВМ, мы можем добавлять или удалять интерфейс без выключения ВМ. Следующий снимок экрана показывает параметр Hotplug для ВМ KVM:
Рисунок 4
Виртуальный мост
Proxmox делает возможным создание моста не подключённого к физической NIC. Это делает доступной изолированную среду, которая не имеет возможности взаимодействовать с физической или любой другой сетевой средой в вашей LAN. Используя Open vSwitch, однако, мы можем настроить один мост со множеством VLAN, так как в реальном физическом коммутаторе. Мы рассмотрим реализацию Open vSwitch позже в этой главе.
Добавление виртуального моста
Рисунок 5
Рисунок 6
Важно отметить здесь, что мы можем настраивать только один виртуальный мост для интерфейса физической сети.
Флаговая кнопка осведомлённости о VLAN является новым добавлением, которое позволяет Proxmox выступать в качестве транкового канала в коммутаторе, что позволит провести множество VLAN в одном соединении. Хотя и не обязательно разрешать это поле, это, тем не менее, новый способ обработки VLAN через мост. Например, если нам нужно реализовать 10 VLAN, при традиционном подходе Linux настройки моста нам понадобится создавать 10 виртуальных мостов. Однако, применяя опцию осведомлённости о VLAN мы можем создать один мост и просто добавить идентификатор VLAN к нему, тем самым воздержавшись от значительного набора данных множества настроек моста. Следующая таблица отображает настройку базового примера в сопоставлении традиционного и осведомлённого о VLAN мостов:
Традиционный режим
Режим осведомлённый о VLAN
iface vlan0 inet manual
iface vmbr0 inet manual
iface vlan10 inet manual
iface vmbr10 inet manual
iface vmbr0 inet manual
В предыдущей таблице мы можем увидеть, что существует множество экземпляров моста при традиционном подходе Linux. Однако, применяя опцию осведомлённости о VLAN, мы можем уменьшить всю настройку всего лишь до нескольких строк.
Отметим здесь, что для традиционного моста Linux мы должны должны воспользоваться дополнительными строками настройки для создания вначале порта VLAN, а затем мы передаём этот порт в качестве порта моста для создаваемого моста. Параметр настройки выглядит как vlan_raw_device
. Хотя существует более одного способа создания моста с поддержкой VLAN, это наиболее предпочтительный способ настройки.
Преимущество применения традиционного метода linux состоит в том, что каждая VLAN получает свой собственный виртуальный мост, тем самым изолируя последующий сетевой обмен. Например, когда перенастраивается мост с определённым идентификатором VLAN, участвуют только этот мост и все подключённые к этому мосту ВМ. При использовании режима осведомлённости о VLAN, если существует ошибка в настройке, это может повлечь за собой прерывание соединения для всех связанных с этим мостом ВМ. Режим осведомлённости о VLAN предоставляет аналогичную Open vSwitch функциональность, однако при этом не требует дополнительного пакета. Позже в этой главе мы изучим Open vSwitch.
При использовании моста с разрешённой осведомлённостью о VLAN мы должны пометить каждый виртуальный интерфейс идентификатором VLAN, как это отображено на следующем снимке экрана:
Рисунок 7
При использовании традиционного режима без опции осведомлённости о VLAN, мы должны выбрать сам помеченный VLAN мост в качестве интерфейса виртуальной сети, как это отражается на следующем снимке экрана:
Рисунок 8
Для создания виртуального моста в CLI выполните следующие шаги:
Зарегистрируйтесь на соответствующем узле Proxmox через консоль.
Откройте файл интерфейса при помощи редактора:
В конец этого файла добавьте строки настройки используя следующий формат:
Сохраните файл и выйдите из редактора:
Активируйте данный мост в CLI воспользовавшись следующей командой:
Теперь новый виртуальный мост должен быть активирован и находиться в работе. Если виртуальные машины должны быть перемещены на другие узлы, то данные настройки должны быть дублированы на всех этих узлах.
Дополнительные параметры моста
Существуют два дополнительных параметра моста, которые обычно применяются при настройке виртуального моста.
bridge_stp
Эта опция делает возможной взаимодействие множества мостов друг с другом для обнаружения сетевой среды и при этом избегать зацикливаний. Это полезно для прекращения зацикливания данных для предоставления оптимальной маршрутизации пакетов, потому что при включённом STP мосты могут общаться друг с другом и определять то, как они соединены, а затем предоставлять наилучшую из возможных маршрутизацию для обмена пакетами данных. STP также делает возможной устойчивость к ошибкам, так как протокол проверяет топологию сетевой среды в случае отказов моста. Чтобы включить опцию STP просто измените настройку моста следующим образом:
STP увеличивает эффективность полосы пропускания при определении проблем безопасности. Не используйте STP в случае, когда подсеть требует изоляции от остальных виртуальных подсетей в том же самом кластере, а также когда вы не хотите чтобы ваши мосты общались друг с другом. Это полезная опция в случае при работе в виртуальной среде одной и той же компании когда данные могут свободно перемещаться между подсетями подразделений.
По умолчанию STP выключена.
STP не имеет никакой аутентификации и считает все сетевые интерфейсы заслуживающими доверия. Когда мост запрашивает сетевую топологию у другого моста, информация свободно используется совместно без какой- либо аутентификации. Таким образом, пользователь этого моста потенциально может получить данные о топологии всей сети и других мостах в этой сетевой среде. Это приводит к опасной ситуации при соединении мостом внутренней среды и Интернета.
bridge_fd
В большинстве случаев значения по умолчанию 0 достаточно. Для очень сложных виртуальных сред с несколькими десятками мостов увеличение этого значение до 3 или 4 может быть полезным. При отсутствии такой задержки данный мост начнёт обмен пакетами данных вне зависимости от того доступен другой мост получателя или нет. Увеличение времени задержки позволяет мосту источника проверить все другие мосты и не передавать никакие данные если такой мост получателя отключён, тем самым предотвращая ненужное потребление полосы пропускания сетевой среды.
Виртуальная сеть
Когда данные VLAN покидают виртуальную среду, физический сетевой коммутатор с функциями VLAN помечает все данные идентификатором и затем направляет эти данные их соответствующим получателям. Каждая подсеть должна иметь один и тот же идентификатор (ID) VLAN в виртуальной среде и соответствующем физическом сетевом коммутаторе. VLAN способствует уменьшению широковещательного обмена множества областей в одной и той же сети. Сегментируя большую сетевую среду на VLAN меньшего размера, широковещательные сообщения могут отсылаться только в подходящие VLAN без прерывания остального обмена данными в сетевой среде.
Добавление виртуальной сети
VLAN может быть настроен как на виртуальных машинах, так и на мостах. Если сетевой обмен покидает виртуальную среду, всем коммутаторам и физическим сетевым устройствам важно быть осведомлёнными о VLAN и помечать пакеты надлежащим образом. Пометка ВМ идентификатором VLAN выполняется напрямую в GUI Proxmox. Просто введите идентификатор VLAN при добавлении сетевого интерфейса к ВМ или измените уже существующий vNIC. Следующий снимок экрана отображает виртуальный интерфейс ВМ после его пометки идентификатором VLAN:
Рисунок 9
В предыдущем примере мы пометили свой интерфейс для VLAN ID 2. Такая пометка работает, когда мост имеет включённой осведомлённость о VLAN или когда реализован Open vSwitch. В случае, когда каждый виртуальный мост настраивается с отдельным идентификатором VLAN, вместо того чтобы назначать пометку идентификатором, мы настраиваем интерфейс на использование такого моста для данного VLAN. На следующем снимке экрана мы настроили свой сетевой интерфейс на использование нашего моста vmbr2 вместо пометки идентификатором:
Рисунок 10
Мы также можем настроить VLAN для связанных сетевых интерфейсов. Для этого вместо назначения физического интерфейса в качестве простого устройства VLAN нам нужно создать новый связанный интерфейс, а затем применить его в качестве материального устройства VLAN, как это показано в следующем примере настройки:
Помимо пометки виртуального моста и виртуального сетевого интерфейса, чтобы заставить работать VLAN мы также должны настроить физический коммутатор. Без VLAN эффективная коммутация сетевого обмена не будет доступна между узлами или покидать локальную сетевую среду. Обмен будет ограничен только пределами одного узла. Каждый физический коммутатор приходит со своим собственным GUI для настройки коммутации, однако основная идея настройки VLAN остаётся одной и той же для всех коммутаторов.
Рисунок 11
В предыдущем примере демонстрационная VLAN с ID #9
Рисунок 12
Трансляция виртуальных адресов
NAT обеспечивает безопасность устройству опосредованным выставлением его в Интернет или общедоступную сетевую среду. Она также позволяет коммуницировать больше физических устройств без необходимости иметь индивидуальные общедоступные IPV4 адреса в Интернете. NAT обычно настраивается в маршрутизаторе или межсетевом экране сетевой среды, там, где создаются политики для соответствия локальных-к-глобальным и глобальных-к-локальным адресов IP.
Отметим, что NAT присуща для сетевых сред IPv4. IPv6 сокращает потребность в применении NAT, поскольку адреса IPv6 всегда являются общедоступными. < Прим. пер.: некоторые поставщики услуг Интернет практикуют ограничение диапазонов IPv6 выделением определённых значений для их использования, мотивируя это политиками безопасности. Такая практика расширяет необходимость применения NAT и для IPv6.>
Добавление NAT/ маскарадинга
Настоятельно рекомендуется чтобы все настройки NAT требовали обработки выделенным физическим или виртуальным межсетевым экраном. Большинство имеющихся межсетевых экранов имеют параметры NAT в своей поставке. Кроме того, применяя виртуальные межсетевые экраны мы можем создавать полностью изолированные виртуальные сетевые среды для множества клиентов в одном и том же кластере Proxmox. Наличие виртуального межсетевого экрана предоставляет клиенту управление его собственной фильтрацией оставляя его сетевую среду скрытой от прочих сетевых сред в этом кластере.
Сцепление сетевых сред
Режим сцепления
Политика
Описание
Передача пакетов происходит последовательно от первого к последнему участвующим сетевым интерфейсам. Это предоставляет балансировку нагрузки и устойчивость к отказам.
(активное резервное копирование)
Только один участвующий интерфейс является активным. Следующий интерфейс становится активным при отказе предыдущего. Это предоставляет только устойчивость к отказам.
Этот режим выбирает один и тот же интерфейс участника для каждого адреса MAC получателя. Передача имеет место на основе сцепленных сетевых интерфейсов адресов MAC, сравнивающихся по исключающему ИЛИ с адресом MAC получателя. Это предоставляет и балансировку нагрузки, и устойчивость к отказам.
Передача осуществляется по всем участвующим в сцеплении сетевым интерфейсам. Это предоставляет только устойчивость к отказам.
Динамичное соединение связей
Все интерфейсы- участники в группе агрегации совместно используют одни и те же установки скорости и дуплекса. Все интерфейсы используются в соответствии со спецификацией 802.3ad. Необходим сетевой коммутатор с поддержкой 802.3ad или функциональностью LACP. Это предоставляет устойчивость к отказам.
Балансировка нагрузки адаптивным обменом
Исходящие пакеты распределяются согласно текущей нагрузке на каждом участвующем интерфейсе. Входящие пакеты принимаются текущим интерфейсом, а если этот интерфейс отказывает, тогда вступает в дело следующий интерфейс. Это предоставляет устойчивость к отказам и балансировку нагрузки только для исходящих пакетов.
Адаптивная балансировка нагрузки
Аналогична balance-tlb с включением балансировки нагрузки входящих пакетов для всех интерфейсов.Это предоставляет устойчивость к отказам и балансировку нагрузки как для входящих, так и для исходящих пакетов.
Следующий снимок экрана показывает систему меню Proxmox, применяемую для создания нового Bond
Рисунок 13
Добавление сцепленного интерфейса
Рисунок 14
LACP может объединять множество интерфейсов для увеличения общей пропускной способности, хотя при этом и не для одного реального соединения. Например, LACP сцепление четырёх 1-гигабитных сетевых интерфейсов всё равно будет иметь общую скорость для соединения 1 гигабит, однако оно будет способно отвечать на большее число одновременных запросов на близкой к 1 гигабит скорости.
Для того, чтобы LACP работал, очень важно знать поддерживает ли коммутатор эту функцию. Быстрый просмотр на сайте производителя снабжает нас информацией поддерживается ли функциональность LACP. Некоторые производители перечисляют эту характеристику как 802.3ad.
Как и в случае с виртуальным мостом, мы также можем настроить сетевое сцепление через GUI или CLI Proxmox. Сцепление, созданное через GUI будет активировано после перезагрузки узла, в то время как объединение, добавляемое через CLI путём прямого изменения файла настройки сети может быть просто активировано через CLI. Мы можем открыть блок диалога создания сцепления интерфейса в закладке Hardware данного узла. Следующий снимок экрана отображает блок диалога для интерфейса сцепления, bond0 для нашего примера узла Proxmox:
Рисунок 15
Для получения максимальной производительности и стабильности сетевого соединения важно понимать разницу между этими политиками.
Политика хеширования 2 уровня
Если не выбрана никакая политика, Proxmox использует по умолчанию политику 2 уровня. Данная политика генерирует хеш передачи на основании MAC адресов сетевого интерфейса. Эта политика помещает весь сетевой обмен отдельный подчинённый интерфейс в ващем сцепленном LACP.
Политика хеширования уровня 2 + 3
Данная политика создаёт хеш передачи на основе объединения адресов MAC и IP. Существуют также протоколы 2 и 3 уровней сетевого уровня. Данная политика также помещает весь сетевой обмен получателю в один и тот же подчинённый интерфейс. Однако, он предоставляет более сбалансированную передачу по сети чем в случае простого применения политики 2 уровня. Для лучшей производительности и надёжности применяйте эту политику.
Политика хеширования уровня 3 + 4
Эта политика создаёт хеш передачи на основе более высоких сетевых уровней когда это возможно. Объединение уровней 3 и 4 делает возможным рассредоточение множественного сетевого обмена или соединения по множеству подчинённых интерфейсов в сцепленной LACP. Однако, отдельное соединение не охватывает множество подчинённых интерфейсов. Для сетевого обмена без IP данная политика использует политику хеширования 2 уровня. Имейте в виду, что политика уровня 3 + 4 не полностью совместима с LACP или 802.3ad.
Чтобы создать интерфейс сцепления, необходимо добавить следующие строки в файл настройки. В нашем примере мы добавляем порты физических интерфейсов, eth0 и eth1 в следующий интерфейс сцепления:
Мы собираемся добавить следующие строки кода для создания виртуального моста с использованием порта сцепления:
Активируйте мост перезагрузкой данного узла или из CLI остановив мост и повторно его запустив. Воспользуйтесь следующими командами:
После настройки узлов Proxmox со сцеплением LACP, мы теперь должны настроить LACP на физическом коммутаторе. Каждый коммутатор приходит со своей собственной документацией того, как настраивать агрегацию связей LACP. В данном разделе мы собираемся рассмотреть интеллектуальный коммутатор Netgear GS748T с функциональностью LACP. Опция включения LACP может быть найдена путём навигации по Switching | LAG в GUI Netgear. Вначале мы должны разрешить LACP для каждой группы связей. Следующий экранный снимок отображает LACP, включённый для групп с 1 по 3 в меню LAG Configuration :
Рисунок 16
Рисунок 17
Сцепление также может быть использовано с VLAN. Отсылаем к разделу Виртуальная сеть в этой главе для изучения того, как интегрировать сцепление с VLAN.
Множественная адресация
Начиная с Proxmox VE 4.0 и в последующих версиях для надлежащего взаимодействия в кластере теперь необходима множественная адресация. Говоря простыми словами, множественная адресация доставляет единственную пересылку множеству узлов в сети одновременно, в то время как индивидуальная адресация отсылает пакеты данных единичным получателям из одного источника. Чем больше узлов присутствует в кластере, тем больше отдельных индивидуальных пакетов необходимо пересылать в кластере. Применяя множественную адресацию, такой дополнительный объём обмена существенно минимизируется. Из- за существенного увеличения числа пакетов в сетевой среде при использовании уникальной адресации, следует избегать её реализация в кластере с пятью и более узлами. Для надлежащей работы множественной адресации, физические коммутаторы в сетевой среде должны поддерживать множественную адресацию и быть способными к отслеживанию IGMP ( IGMP snoop )
Имейте в виду, что Open vSwitch в настоящее время не поддерживает обработку множественной адресации. Поэтому для сред с Open vSwitch в физическом коммутаторе должен быть настроен опрашивающий маршрутизатор со множественной адресацией (multicast querier router).
Если во всей среде Proxmox не представляется возможным применением множественной адресации, тогда индивидуальная адресация является единственным вариантом. Для проверки того, работает ли в нашем кластере множественная адресация, мы можем выполнить следующую команду:
Если множественная адресация полностью функциональна, вывод продемонстрирует отклики множественной адресации, как это показано на следующем снимке экрана:
Неудачные отклики множественной адресации отобразят потерю пакетов для данного узла. Поставляемая с каждым физическим коммутатором документация должна содержать соответствующую информацию, если коммутатор поддерживает множественную адресацию. Однако, на сегодняшний день, практически все интеллектуальные или управляемые коммутаторы имеют функциональность множественной адресации. Однако, она запрещена для всех портов и должна быть включена для надлежащего взаимодействия в кластере Proxmox.
Настройка множественной адресации в Netgear
Рисунок 19
Рисунок 20
Рисунок 21
Open vSwitch
Лицензируемый в соответствии с Apache 2.0, Open vSwitch является многоуровневым виртуальным коммутатором корпоративного уровня, появившийся на свет специально для применения в современных виртуальных сетях виртуальных сред. Он аналогичен виртуальному мосту Linux, однако имеет больше возможностей при большей надёжности. Часто задаваемый вопрос состоит в том, почему следует выбирать Open vSwitch вместо обычного проверенного временем и индустрией моста и сетевой среды Linux. Когда мы поймём функциональность и преимущества Open vSwitch, предоставляемые для виртуальной сетевой среды, ответ станет очевидным.
Функциональность Open vSwitch
Ниже приводятся некоторые основные свойства, которые делают Open vSwitch лучшим вариантом, чем стандартные сетевые среды Linux.
Безопасность : Open vSwitch предоставляет наивысший уровень безопасности разрешая вам устанавливать политики для виртуальных интерфейсов ВМ.
LACP и осведомлённость о VLAN : Open vSwitch полностью поддерживает агрегацию связей LACP и пометку VLAN. Мы можем настраивать один отдельный Open vSwitch со множеством тегов VLAN, тем самым уменьшая накладные расходы управления множеством виртуальных мостов для тегов VLAN.
Quality of Service : Полная поддержка QoS или уровней сервисов.
Мониторинг сетевой среды : Мы можем получить наивысший уровень управления прохождением пакетов через Open vSwitch путём реализации мощного мониторинга с применением Netflow и sFlow.
IPv6 : Open vSwitch полностью поддерживает IPv6.
Протокол туннелирования : он имеет полную поддержку множества протоколов туннелирования, например, GRE, VXLAN, STT, IPsec и тому подобных.
Поддержка Proxmox : Open vSwitch полностью интегрирован и поддерживается Proxmox, делая его жизнеспособным выбором для настройки виртуальной сети.
Для ознакомления со всеми подробностями технологии Open vSwitch посетите официальный сайт OpenvSwitch.org/.
Допускается построение кластера Proxmox полностью на мостах Linux полностью без использования Open vSwitch. Однако, для крупных окружений Open vSwitch имеет большой смысл, так как это может уменьшить утомительное управление виртуальной сетью, предоставляя отличную визуализацию сетевого обмена. В средах со множеством владельцев очень важно наличие общего управления над тем, что происходит в сети.
По умолчанию Open vSwitch не установлен в Proxmox. Он должен быть установлен и настроен вручную. На вновь установленном узле Proxmox мы должны настроить обычным образом сетевую среду с тем, чтобы узел мог иметь связь с Интернетом. Затем выполните следующую команду для установки Open vSwitch:
Важный момент, о котором следует помнить при использовании Open vSwitch, состоит в том, что никогда нельзя смешивать обычные компоненты Linux, такие как мост, сцепление и VLAN с компонентами Open vSwitch. Например, мы не должны создавать мост Open vSwitch на основе сцепления Linux и наоборот.
Существует три компонента, которые мы можем применять в Open vSwitch:
Сцепление Open vSwitch
IntPort Open vSwitch
Добавление моста Open vSwitch
Мы также можем настроить мост Open vSwitch при помощи GUI Proxmox. Однако нам нужно иметь в виду, что любая выполненная через GUI Proxmox настройка сети не будет активирована пока не будет выполнен перезапуск узла.
Мы можем открыть блок диалога создания моста Open vSwitch в закладке сетевой среды узла, как это отображено на следующем снимке экрана:
Рисунок 22
На следующем снимке экрана отображён блок диалога создания нашего моста Open vSwitch со всей необходимой информацией:
Рисунок 23
В параметрах OVS мы можем включить дополнительные опции для этого моста.
При добавлении моста через GUI нам не нужно настраивать порт сам по себе в начале настроек, как мы это делали при добавлении моста при помощи CLI. GUI автоматически определяет для нас такой порт.
Добавление соединения Open vSwitch
Как и для моста Linux, мы можем создавать различные сцепленные интерфейсы Open vSwitch. В данном примере мы собираемся создать сцепленный LACP интерфейс для Open vSwitch. Для создания моста Open vSwitch применяются следующие параметры настройки для создания сцепленного интерфейса при помощи данного интерфейса:
Мы можем настроить те же самые сцепления Open vSwitch с применением GUI Proxmox воспользовавшись блоком диалога создания сцепления, как это показано на следующем снимке экрана:
Рисунок 24
Добавление IntPort Open vSwitch
Даже не смотря на то, что мы определили мост Open vSwitch при помощи vlan1 для своего IntPort, нам всё ещё необходимо описать его в определениях Open vSwitch или, в противном случае этот интерфейс никогда не будет запущен.
CLI для Open vSwitch
Помимо параметров создания и редактирования устройств Open vSwitch при помощи GUI Proxmox, Open vSwitch поставляется с опциями командной строки для управления и получения информации по определённому мосту, сцеплению или интерфейсу. В Open vSwitch присутствует четыре типа команд:
ovs-appctl : Применяются для запросов к демону Open vSwitch и управления им
ovs-vsctl : Используются для управления базой данных настройки вашего Open vSwitch
ovs-appctl : Этот инструмент служит для мониторинга и управления коммутатором OpenFlow
ovs-appctl : Применяется для управления путями данных Open vSwitch
Обсуждение подробностей всех доступных команд Open vSwitch выходит за рамки настоящей книги. В данном разделе мы рассмотрим только команды, которые могут оказаться очень полезными при управлении кластером Proxmox:
Чтобы просмотреть перечень настроенных мостов, портов и интерфейсов Open vSwitch, воспользуйтесь следующими командами:
Для отображения списка всех ваших интерфейсов Open vSwitch выполните следующую команду:
Для изменения параметров времени исполнения без перезагрузки данного узла:
Например, если мы хотим добавить идентификатор VLAN в наш сцепленный интерфейс Open vSwitch, выполните следующую команду:
Для отслеживания и отображения обмена в сторону моста open vSwitch и от него выполните следующую команду:
Для просмотра состояния любого компонента Open vSwitch примените следующую команду:
Для дампа потоков OpenFlow, включая скрытые, воспользуйтесь командой:
Для вывода версии Open vSwitch выполниет следующую команду:
Для ознакомления с полным перечнем доступных команд Open vSwitch посетите http://www.pica8.com/document/v2.3/pdf/ovs-commands-reference.pdf.
Практика Open vSwitch
Если вы впервые используете Open vSwitch, это может казаться вам поначалу непростым. Однако по мере приобретения практики и непосредственного общения действительно становится проще создавать управлять комплексом виртуальной сетевой среды, полностью вооружённым Open vSwitch. В данном разделе вам будет предоставлена задача создания настройки сетевой среды для узла Proxmox при помощи всех сетевых компонентов, которые мы изучили к настоящему моменту. Полная настройка представлена в последующем разделе, однако попробуйте вначале создать её самостоятельно.
Требования настройки
Интерфейс infiniband должен быть настроен на использование с Ceph в отдельной подсети. Этот узел должен применять VLAN 12 для всех связанных с хостом взаимодействий при помощи моста Open vSwitch.
Решения
Ниже приводятся полные настройки сетевой среды для заданных требований:
Примеры виртуальных сетей
На данный момент мы рассмотрели компоненты виртуальной среды в рамках среды кластера Proxmox. Мы знаем все компоненты применяемые Proxmox для совместной поддержки всего.
Мы собираемся рассмотреть несколько сценариев виртуальных окружений для закрепления нашего понимания сетевых сред в виртуальных окружениях Proxmox. Такие схемы на основе сценариев и кое- что в них взято из реальных промышленных сред.
Это небольшой кластер Proxmox с тремя узлами и двумя подсетями в пределах нашей виртуальной среды. Каждый узел Proxmox имеет два NIC, причём оба моста vmbr0 и vmbr1 подключены к eth0 и eth1 соответственно. Каждый мост имеет три подключённых к нему виртуальные машины. За пределами виртуальной среды присутствует физический коммутатор, который соединяет узлы Proxmox и консоль администратора для вей работы управления. Такой Proxmox является простейшим в производственной среде. Такой тип сетевой среды может использоваться для обучающей платформы или для очень маленького бизнес- окружения с небольшими запросами на рабочую нагрузку. Связь с Интернетом предоставляется второй подсети напрямую из межсетевого экрана вторым NIC, как это показано на следующей схеме:
Рисунок 25
Это обычный сценарий для инфраструктуры поставщика услуг, который размещает виртуальные сетевые среды множества клиентов. Так как множество компаний может осуществлять удалённый доступ к своим виртуальным сетям, это накладывает дополнительную рабочую нагрузку на наш физический межсетевой экран. Следует избегать отказов единой точки межсетевого экрана для всех стоимостей путём создания кластера физических межсетевых экранов для обеспечения балансировки нагрузки и отказоустойчивой службы межсетевого экранирования.
Никогда не применяйте виртуальный межсетевой экран в том же самом кластере для соединения с Интернетом напрямую. Всегда используйте отдельное физическое оборудование в качестве главного межсетевого экрана для выставления его в качестве барьера между Интернетом и внутренней сетевой средой.
Следующая схема является примером виртуальной среды со множеством владельцев.
Рисунок 26
Конечно, следующая схема является очень упрощённой формой реальной сетевой топологии академического института. Однако основы применения VLAN и мостов те же самые для любого размера сетевой среды.
Рисунок 27
Виртуальная среда со множеством владельцев
Множество владельцев (арендаторов) очень часто применяется в мире облачных вычислений, в котором виртуальные среды постоянно используются различными пользователями из установок различных организаций при полной изолированности сетевых сред. Среда со множеством владельцев является неотъемлемой частью служб поставщика, который предоставляет IaaS ( Infrastructure-as-a-Service ) множеству пользователей.
Для получения дополнительных сведений по облачным вычислениям посетите en.wikipedia.org/wiki/Cloud_computing.
При данном типе установки, поставщик услуг осуществляет хостинг или «сдаёт в аренду» вычислительное время и пространство хранения своим клиентам. Поскольку для данного вида услуг требуется стандартная ежемесячная подписка или платежи на основе SLA, термин множества владельцев (multitenancy) быстро приобретает популярность. Обычно виртуальные среды со множеством пользователей появляются там, где одновременно существует несколько изолированных сетевых сред на одной и той же платформе без их пересечения друг с другом. Почти все общедоступные центры обработки данных являются платформами с множеством владельцев (арендаторов).
Множественность владельцев (арендаторов) не является новой в мире информации. Первые среды со множеством владельцев уходят назад к 1960м, когда компании арендовали машинное время и пространство хранения мэйнфрейм компьютеров для уменьшения гигантских затрат работы на больших ЭВМ. Виртуальные среды всего лишь экспоненциально форсируют ту же идею, усиливая все свойства виртуализации, предоставляемые Proxmox. Комбинируя виртуализацию с облачными вычислениями, многопользовательская среда способна получить очень сильное соответствие лучшему обслуживанию пользователей при их большем количестве без увеличения финансовых накладных расходов. До эпохи виртуализации требования физического пространства и мощности для потребителей хостинга в средах IAAS <инфраструктуры как службы>означали, что они были редки при непомерно высокой стоимости, таким образом, мало кто ими пользовался.
Гипервизор Proxmox способен настраивать стабильные и масштабные виртуальные среды со множеством владельцев. Поскольку мы осознаём взаимосвязь между виртуальными машинами и виртуальными мостами, будет довольно просто создать при помощи Proxmox виртуальную среду со множеством владельцев.
При настройке виртуальных сред со множеством владельцев очень важно принимать особые меры для того, чтобы один сетевой обмен не пересекался с другим сетевым обменом. Без соответствующих VLAN и подсетей будет возможным одной сетевой среде перехватывать (sniff, вынюхивать) пакты во всём сетевом окружении и таким образом похищать данные из других арендующих организаций в этой сетевой среде.
Схема сетевой среды со множеством владельцев
Ниже приводится пример схемы сети типичного поставщика облачных услуг, который предоставляет IAAS своим клиентам. Вся сетевая среда является виртуальной в рамках виртуального окружения поставщика услуг:
Рисунок 28
Виртуальные сети изолированы отдельными подсетями. VLAN является настройкой (не показанной на схеме) для уменьшения массивного широковещательного обмена. Все данные виртуальных машин хранятся в отдельном кластере хранения с полной избыточностью. Кластер резервных копий выполняет регулярное резервное копирование всех виртуальных машин, а гранулярное резервное копирование файлов с их историями выполняется программным обеспечением резервного копирования сторонних производителей. Кластер виртуального межсетевого экрана настраивается между виртуальной средой и интерфейсом Ethernet хоста предоставляя связь с Интернетом всем пользователям виртуальных машин. Каждый виртуальный межсетевой экран имеет несколько vNIC, соединённых с каждой подсетью. Типичный виртуальный межсетевой экран со множеством vNIC будет выглядеть так, как это показано на следующем снимке экрана:
Рисунок 29
Поскольку межсетевой экран виртуальный, мы можем добавлять любое число виртуальных сетевых интерфейсов без того, чтобы беспокоиться о выходе за пределы доступного числа физических разъёмов. Виртуальный кластеризованный межсетевой экран предоставляет максимальное время работы без простоев. Каждая сеть компании в таком примере имеет свой собственный виртуальный мост, который общается только с виртуальными машинами этой компании, а также интерфейс межсетевого экрана, исключающий любую возможность воровства пакетов сетевой средой другой компании.
Перехват пакетов ( packet sniffing ) является процессом, при котором проходящие через сетевой интерфейс пакеты захватываются и анализируются. Программное обеспечение перехвата пакетов может быть помещено в подсеть для перехвата данных. Это общая практика кого-то со злонамеренным умыслом для перехвата существенных проходящих не зашифрованных данных, например, имён пользователей и их паролей в простых текстах.
Данная среда обслуживает множество клиентов или организаций, поэтому время работы без простоев является большим предметом беспокойства. Для исключения этой проблемы, целые виртуальные среды реплицируются в другие центры обработки данных для гарантирования 99.9 процентов времени работы. Предыдущая схема является упрощённой версией с перекрытием от того, что в действительности происходит внутри очень занятых виртуальных сред Proxmox. Изучение этой схемы даст ясное понимание механики виртуальных сетевых сред. Из предыдущей схемы мы можем увидеть, что эта сетевая среда интенсивно использует виртуальные мосты. Поэтому очень важно понимать роль мостов и планировать черновые схемы перед реальной установкой этого уровня сложной виртуальной сети.
При работе со сложной виртуальной сетью всегда имейте схему сетевой среды в руках и обновляйте её при всяком выполняемом вами изменении. В особенности при возникновении проблемы вам будет проще локализовать причину проблемы при помощи схемы.
Выводы
Мы были очень заняты в этой интенсивной главе. Мы рассмотрели различия между физическими и виртуальными сетями. Мы изучили сетевые компоненты Proxmox, которые создают виртуальную сеть на основе Proxmox. Также мы ознакомились с Open vSwitch и его компонентами для создания действительно сложных виртуальных сетей. Мы даже проанализировали несколько схем сетевых сред начиная с базовой до самых передовых для получения лучшего представления о том как виртуальные сети Proxmox в действительности приходят в жизнь.
Proxmox предоставляет все необходимые нам инструменты для построения виртуальной сети любого уровня. Как сформировать хорошо спроектированную и эффективную виртуальную сеть зависит только от воображения сетевого администратора, бюджета компании, а также необходимости предвидения того, как все части должны быть собраны вместе. Самое приятное то, что любую ошибку легко исправить в виртуальной сети. Мы всегда можем вернуться назад и изменить порядок, пока не будем удовлетворены. Именно по этой причине виртуальная сеть постоянно развивается. Со временем виртуальная сеть становится расширением сетевого сознания администратора. Настройка и архитектура инфраструктуры виртуальной сети может дать нам окно в то, о чём думает администратор и используемую им логику для конструирования среды.
В следующей главе мы собираемся изучить построение межсетевого экрана Proxmox и того, как защищать весь кластер вплоть до отдельной виртуальной машины.
Схема, которую будем реализовывать
Схема подключения OVS и физического интерфейса
Подключение виртуальных сетевых машин к порту коммутатора OVS
Настройка сетевого интерфейса ВМ в virt-manager
Обзор интерфейсов Kerio с подключенными VLAN ID
