Глава 7. Сетевая среда виртуальных сетей

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

В данной книге мы в основном сосредоточимся на внутренней сетевой виртуализации в вашем гипервизоре Proxmox. Мы также рассмотрим некоторые схемы сетевых сред для комбинаций внутренних и внешних сетей позже в этой книге в Главе 13, Установка Proxmox промышленного уровня.

Теперь мы рассмотрим различия между физической и виртуальной сетевыми средами. Следующая схема представляет физическую среду без какой- либо виртуальной среды:

Следующая схема предоставляет виртуализацию как главную инфраструктуру:

Перед тем, как мы погрузимся в построение блоков виртуальных сетей, нам нужно понять как сетевые среды устанавливаются на предыдущих схемах. обе схемы представляют оду и ту же начальную установку учреждения в котором главное административное подразделение находится на втором этаже, а подразделение ведения учётных записей на четвёртом этаже того же здания. Из диаграммы очевидно, что физическая сетевая среда менее сложна чем виртуальная сеть, однако при возрастании виртуализации мы можем сокращать стоимости, увеличивать эффективность, снижать сложность сопровождения аппаратных средств, а также увеличивать переносимость.

На схеме физической сетевой среды отсутствуют установленные виртуальные платформы. Сетевая среда настраивается с применением физических устройств, таких как межсетевые экраны, коммутаторы, серверы, а также наполненные рабочие станции. Каждое подразделение имеет свои собственные серверы и сегменты сетевой среды. Централизованное управление всей компанией отсутствует. Это затратное решение из- за всех имеющихся физических аппаратных средств. Если необходима избыточность, оно претерпит удвоение стоимости, поскольку нуждается в идентичных физических серверах. Все коммуникации в этой сети выполняются соединением физических кабелей. Резервное копирование в подобной сети является достаточно вызывающим, так как все физические серверы в обоих подразделениях должны выполнять резервное копирование на основе подискового подхода.

Схема виртуальной сетевой среды представляет то, как Proxmox может обрабатывать установку со множеством подразделений. Все соединения между серверами и виртуальными машинами пользователей осуществляются виртуально без физических устройств физической сетевой среды. Использование виртуальных мостов и vNIC обоими подразделениями и администрирования, и ведения учётных записей, могут сосуществовать в одном и том же кластере Proxmox. Так как все вычисления производятся гипервизором, конечные пользователи могут иметь тонких клиентов для существенной минимизации стоимости. Пользователи могут соединяться со своими виртуальными машинами по протоколам удалённого доступа, таким как SPICE, VNC и RDP. {Прим. пер.: а также HDX, советуем обратиться к содержательному обзору различных протоколов доступа, проведённому фирмой Huawei: }.

В данной установке все серверы и машины пользователей виртуализованы. Если существует необходимость в новом сервере, это всего- лишь вопрос создания виртуального сервера с vNIC за несколько кликов. Так как Proxmox является гипервизором, который был построен из группы с возможностью избыточности, в подобном сценарии все виртуальные машины могут просто мигрировать на другие доступные узлы Proxmox и при этом все остаётся включённым и выполняется должным образом. Оба подразделения разделяются двумя виртуальными мостами.

С применением GUI Proxmox всё управление может быть выполнено из одной точки, включая резервное копирование и восстановление. Виртуальные серверы могут мигрировать по сетевым соединениям, которые могут распространяться на большие и малые физические расстояния. Хотя настройка виртуальных сетевых сред является намного более надёжной и обогащённой функциональностью, она имеет существенно меньшие требования к бюджету. Новое подразделения могут быть добавлены путём создания новых виртуальных мостов и использования виртуальных LAN и VLAN в существующих коммутаторах физической сетевой среды.

Теперь мы рассмотрим все сетевые компоненты Proxmox, которые позволят виртуальным машинам взаимодействовать или быть сегментированными от прочих внутренних машин, а также от Интернета.

vNIC (Virtual Network Interface Card) является программно определяемым представлением интерфейса MAC (Media Access Control) интерфейса физической сетевой среды. В основном это виртуальные сетевые карты для виртуальных машин. Множество vNIC может совместно использовать физический сетевой интерфейс узла хоста. В некотором смысле сетевая среда начинает с vNIC когда виртуальная машина отправляет данные, которые должны достичь других виртуальных машин или сетевых устройств в пределах виртуальной среды или физического окружения. На следующей схеме виртуальная машина имеет два виртуальных сетевых интерфейса назначенных на драйвер Intel e1000. Они оба настроены на работу с мостом vmbr601:

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

Чтобы добавить ВМ интерфейс виртуальной сети мы можем открыть блок диалога сетевого устройства примените кнопку Add в закладке ВМ Hardware. Этот блок диалога аналогичен блоку диалога сетевой среды, который мы изучали в Главе 5, Виртуальные машины KVM в разделе Создание KVM.

Если параметр Hotplug для сетевого интерфейса разрешён для данной ВМ, мы можем добавлять или удалять интерфейс без выключения ВМ. Следующий снимок экрана показывает параметр Hotplug для ВМ KVM:

В точности также как мост из реального мира соединяет два берега реки, виртуальный мост соединяет виртуальную сеть Proxmox с физической сетью. Виртуальный мост подобен коммутатору физической сети в которой коммуницируют все виртуальные машины и может настраиваться с использованием STP (Spanning Tree Protocol, протокол связующего дерева). Виртуальный мост является прекрасным способом для создания отдельных подсетей. Все ВМ в одной и той же подсети могут быть соединены со своими соответствующими мостами. Proxmox создаёт один мост по умолчанию в процессе установки. Каждый узел Proxmox может поддерживать до 4094 мостов. Когда одна и та же настройка моста вводится для всех узлов, этот мост может применяться на всех узлах в этом кластере, тем самым делая возможной миграцию в реальном времени без прерывания коммуникации сетевой среды. Формат именования мостов по умолчанию представлен в виде vmbrX, где X представляет целое число в диапазоне от 0 до 4094.

Proxmox делает возможным создание моста не подключённого к физической NIC. Это делает доступной изолированную среду, которая не имеет возможности взаимодействовать с физической или любой другой сетевой средой в вашей LAN. Используя Open vSwitch, однако, мы можем настроить один мост со множеством VLAN, так как в реальном физическом коммутаторе. Мы рассмотрим реализацию Open vSwitch позже в этой главе.

Мы можем изменить виртуальный мост ВМ в реальном времени без необходимости выполнения цикла выключения- включения. Например, если ВМ настроена с виртуальным мостом vmbr0, а мы захотим позже изменить этот мост на vmbr10, мы можем сделать это без выключения данной ВМ.

 

Добавление виртуального моста

Мы можем добавить новый виртуальный мост с применением GUI или CLI Proxmox. Отметим, что если для создания моста используется GUI, то узел должен быть перезапущен для применения изменённых настроек. Это происходит по той причине, что новые настройки сетевого интерфейса через GUI записываются в /etc/network/interfaces.new и только путём перезагрузки новая настройка будет на постоянной основе записана в /etc/network/interface. Следующий снимок экрана показывает находящуюся в рассмотрении информацию об изменениях после создания моста с названием vmbr2:

Для возвращения изменений до фиксации перезагрузки мы просто можем кликнуть на кнопку Revert change.

Для создания нового моста в GUI нам нужно кликнуть поCreate в Network, а затем нам нужно выбрать Bridge option Linux для открытия блока диалога создания моста, как это показано на следующем снимке экрана:

В предыдущем снимке для нашего упражнения мы создаём мост с названием vmbr2. Целью текстового блока Bridge ports является ввод интерфейса физической сети хоста к которому будет подключён этот мост.

В нашем примере присутствует мост vmbr0, который уже настроен на использование интерфейса eth0. Мы не можем использовать этот физический интерфейс для создания нового моста. Таким образом, в нашем примере мы должны применять другой интерфейс, eth1, в качестве порта моста. Также мы можем настраивать только один шлюз и только для одного моста на узел. Так как мост vmbr0 уже настроен на работу с шлюзом, мы должны оставить данный текстовый блок шлюза пустым для своего нового моста.

Флаговая кнопка осведомлённости о VLAN является новым добавлением, которое позволяет Proxmox выступать в качестве транкового канала в коммутаторе, что позволит провести множество VLAN в одном соединении. Хотя и не обязательно разрешать это поле, это, тем не менее, новый способ обработки VLAN через мост. Например, если нам нужно реализовать 10 VLAN, при традиционном подходе Linux настройки моста нам понадобится создавать 10 виртуальных мостов. Однако, применяя опцию осведомлённости о VLAN мы можем создать один мост и просто добавить идентификатор VLAN к нему, тем самым воздержавшись от значительного набора данных множества настроек моста. Следующая таблица отображает настройку базового примера в сопоставлении традиционного и осведомлённого о VLAN мостов:

Традиционный режим	Режим осведомлённый о VLAN
auto vlan0 iface vlan0 inet manual   vlan_raw_device eth0 auto vmbr0 iface vmbr0 inet manual   bridge_ports vlan0   bridge_stp off   bridge_fd 0 ......... ......... auto vlan10 iface vlan10 inet manual   vlan_raw_device eth0 auto vmbr10 iface vmbr10 inet manual   bridge_ports vlan10   bridge_stp off   bridge_fd 0	auto vmbr0 iface vmbr0 inet manual   bridge_vlan_aware yes   bridge_ports eth0   bridge_vids 1-10   bridge_pvid 1   bridge_stp off   bridge_fd 0

В предыдущей таблице мы можем увидеть, что существует множество экземпляров моста при традиционном подходе Linux. Однако, применяя опцию осведомлённости о VLAN, мы можем уменьшить всю настройку всего лишь до нескольких строк.

Преимущество применения традиционного метода linux состоит в том, что каждая VLAN получает свой собственный виртуальный мост, тем самым изолируя последующий сетевой обмен. Например, когда перенастраивается мост с определённым идентификатором VLAN, участвуют только этот мост и все подключённые к этому мосту ВМ. При использовании режима осведомлённости о VLAN, если существует ошибка в настройке, это может повлечь за собой прерывание соединения для всех связанных с этим мостом ВМ. Режим осведомлённости о VLAN предоставляет аналогичную Open vSwitch функциональность, однако при этом не требует дополнительного пакета. Позже в этой главе мы изучим Open vSwitch.

При использовании моста с разрешённой осведомлённостью о VLAN мы должны пометить каждый виртуальный интерфейс идентификатором VLAN, как это отображено на следующем снимке экрана:

При использовании традиционного режима без опции осведомлённости о VLAN, мы должны выбрать сам помеченный VLAN мост в качестве интерфейса виртуальной сети, как это отражается на следующем снимке экрана:

Для создания виртуального моста в CLI выполните следующие шаги:

Теперь новый виртуальный мост должен быть активирован и находиться в работе. Если виртуальные машины должны быть перемещены на другие узлы, то данные настройки должны быть дублированы на всех этих узлах.

Существуют два дополнительных параметра моста, которые обычно применяются при настройке виртуального моста.

 

bridge_stp

Эта опция делает возможной взаимодействие множества мостов друг с другом для обнаружения сетевой среды и при этом избегать зацикливаний. Это полезно для прекращения зацикливания данных для предоставления оптимальной маршрутизации пакетов, потому что при включённом STP мосты могут общаться друг с другом и определять то, как они соединены, а затем предоставлять наилучшую из возможных маршрутизацию для обмена пакетами данных. STP также делает возможной устойчивость к ошибкам, так как протокол проверяет топологию сетевой среды в случае отказов моста. Чтобы включить опцию STP просто измените настройку моста следующим образом:

bridge_stp on
 	   

STP увеличивает эффективность полосы пропускания при определении проблем безопасности. Не используйте STP в случае, когда подсеть требует изоляции от остальных виртуальных подсетей в том же самом кластере, а также когда вы не хотите чтобы ваши мосты общались друг с другом. Это полезная опция в случае при работе в виртуальной среде одной и той же компании когда данные могут свободно перемещаться между подсетями подразделений.

STP не имеет никакой аутентификации и считает все сетевые интерфейсы заслуживающими доверия. Когда мост запрашивает сетевую топологию у другого моста, информация свободно используется совместно без какой- либо аутентификации. Таким образом, пользователь этого моста потенциально может получить данные о топологии всей сети и других мостах в этой сетевой среде. Это приводит к опасной ситуации при соединении мостом внутренней среды и Интернета.

 

bridge_fd

FD обозначает Forwarding Delay (задержку переадресации). Опция bridge_fd устанавливает задержку для того сколько времени должно пройти до готовности интерфейса. В течение этой задержки мост пытается отыскать другие мосты и проверить существуют ли сетевые циклы если включён STP. По умолчанию задержка переадресации установлена в значение 0, как это показано в следующем коде:

bridge_fd 0
 	   

В большинстве случаев значения по умолчанию 0 достаточно. Для очень сложных виртуальных сред с несколькими десятками мостов увеличение этого значение до 3 или 4 может быть полезным. При отсутствии такой задержки данный мост начнёт обмен пакетами данных вне зависимости от того доступен другой мост получателя или нет. Увеличение времени задержки позволяет мосту источника проверить все другие мосты и не передавать никакие данные если такой мост получателя отключён, тем самым предотвращая ненужное потребление полосы пропускания сетевой среды.

VLAN (Virtual Local Area Network, виртуальная локальная сеть) является логической локальной сетью в пределах физической локальной сети. Её можно сравнить с разделом в пределах физического дискового хранилища. Физический сетевой интерфейс может быть разделён для обмена данными по множеству отдельных подсетей. Такие разделы получаются путём использования идентификаторов VLAN. Подробнее о VLAN или стандарте IEEE 802.1q в http://en.wikipedia.org/wiki/IEEE_802.1Q.

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

VLAN также предоставляют дополнительный уровень безопасности для сетевых сред со множеством доменов, так как пользователь больше не сможет просто подключиться к сетевой среде и перехватывать практически любые данные любого домена данной сети. Сегментация сетевой среды обычно выполняется на третьем уровне устройств, например, маршрутизаторов. Однако применение VLAN может достичь значительной экономии средств на уже существующем 2 уровне устройств сетевой среды, таких как управляемые или интеллектуальные коммутаторы. Всего существует семь уровней, определяемых моделью OSI (Open Systems Interconnection, взаимодействия открытых систем), на которых происходит сетевое взаимодействие. Для более глубокого изучения OSI рекомендуем http://en.wikipedia.org/wiki/OSI_model. {Прим. пер.: см. ru.wikipedia.org/wiki/Сетевая_модель_OSI.}

 

Добавление виртуальной сети

VLAN может быть настроен как на виртуальных машинах, так и на мостах. Если сетевой обмен покидает виртуальную среду, всем коммутаторам и физическим сетевым устройствам важно быть осведомлёнными о VLAN и помечать пакеты надлежащим образом. Пометка ВМ идентификатором VLAN выполняется напрямую в GUI Proxmox. Просто введите идентификатор VLAN при добавлении сетевого интерфейса к ВМ или измените уже существующий vNIC. Следующий снимок экрана отображает виртуальный интерфейс ВМ после его пометки идентификатором VLAN:

В предыдущем примере мы пометили свой интерфейс для VLAN ID 2. Такая пометка работает, когда мост имеет включённой осведомлённость о VLAN или когда реализован Open vSwitch. В случае, когда каждый виртуальный мост настраивается с отдельным идентификатором VLAN, вместо того чтобы назначать пометку идентификатором, мы настраиваем интерфейс на использование такого моста для данного VLAN. На следующем снимке экрана мы настроили свой сетевой интерфейс на использование нашего моста vmbr2 вместо пометки идентификатором:

Мы также можем настроить VLAN для связанных сетевых интерфейсов. Для этого вместо назначения физического интерфейса в качестве простого устройства VLAN нам нужно создать новый связанный интерфейс, а затем применить его в качестве материального устройства VLAN, как это показано в следующем примере настройки:

auto bond0
iface bond0 inet manual
  slaves eth0 eth1
auto vlan1
ifaec vlan1 inet manual
        vlan-raw-device bond0

auto vmbr1
iface vmbr1 inet manual
        bridge_ports vlan1
        bridge_stp off
        bridge_fd 0
 	   

В предыдущем примере мы создаём связанный интерфейс применяя физические порты eth0 и eth1. Затем мы создаём интерфейс VLAN vlan1 применяя связанный интерфейс в качестве материального устройства. Из такого vlan1 строится новый виртуальный мост vmbr1. Отметим, что мы нигде не использовали пометку VLAN. Вместо этого мы создали создали материальное устройство VLAN на основе нужной пометки. В данном случае имя моста не существенно, а вот имя вашего интерфейса VLAN важно. Если нам нужно создать мост для VLAN ID 9, то наша настройка будет выглядеть так:

auto vlan9
ifaec vlan9 inet manual
        vlan-raw-device bond0
		
auto vmbr9
iface vmbr9 inet manual
        bridge_ports vlan9
        bridge_stp off
        bridge_fd 0
 	   

Помимо пометки виртуального моста и виртуального сетевого интерфейса, чтобы заставить работать VLAN мы также должны настроить физический коммутатор. Без VLAN эффективная коммутация сетевого обмена не будет доступна между узлами или покидать локальную сетевую среду. Обмен будет ограничен только пределами одного узла. Каждый физический коммутатор приходит со своим собственным GUI для настройки коммутации, однако основная идея настройки VLAN остаётся одной и той же для всех коммутаторов.

Настройка VLAN выполняется в физическом коммутаторе путём настройки транков или общих портов. Обычно параметры отыскиваются путём навигации по меню GUI Switching | VLAN. Следующий снимок является примером настройки интеллектуального коммутатора Netgear GS748T:

В предыдущем примере демонстрационная VLAN с ID #9

настраивается для моста vmbr9. Далее мы должны настроить порты, которые являются частью VLAN 9 в меню участников VLAN, как это показано на следующем снимке экрана, на котором мы помечаем порты 2, 3, 4 и 5 для VLAN 9:

NAT (Network Address Translation/Translator, трансляция сетевых адресов) является методологией переадресации пространства IP адресов путём изменения информации о сетевых адресах в заголовках пакетов дейтаграмм IP в процессе их прохождения сквозь устройства маршрутизации обмена.

NAT обеспечивает безопасность устройству опосредованным выставлением его в Интернет или общедоступную сетевую среду. Она также позволяет коммуницировать больше физических устройств без необходимости иметь индивидуальные общедоступные IPV4 адреса в Интернете. NAT обычно настраивается в маршрутизаторе или межсетевом экране сетевой среды, там, где создаются политики для соответствия локальных-к-глобальным и глобальных-к-локальным адресов IP.

 

Добавление NAT/ маскарадинга

NAT является способом сокрытия адресов IP внутренней сетевой среды от внешней, например, Интернет. Весь исходящий обмен использует IP адрес главного хоста вместо применения своего собственного локального IP адреса. Добавьте последние три строки следующих установок после-входа (post-up) и посл-выхода (post-down) файла настройки /etc/network/interfaces. Просто добавьте эти строки под настройкой виртуального моста, которому требуются подобные опции NAT:

auto vmbr0
iface vmbr0 inet static
address 192.168.145.1
netmask 255.255.255.0
bridge_ports none
bridge_stp off
bridge_fd 0post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -t nat -A POSTROUTING -s '192.168.145.0/24' -o
  eth0 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '192.168.145.0/24' -o
  eth0 -j MASQUERADE
 	   

Сетевое сцепление (Network bonding), группирование (Teaming) или агрегация связей (LAG, Link aggregation) является концепцией, при которой множество интерфейсов объединяются для увеличения пропускной способности, настройки избыточности сети, а также для балансировки нагрузки. Данная концепция интенсивно применяется в средах в высоким требованиями, в которых не приемлемы простои и медленный сетевой ввод/ вывод. GUI Proxmox предоставляет замечательную функциональность для создания сцеплений и управления ими в пределах узла кластера. Proxmox поддерживает режимы сцепления balance-rr, activebackup, balance-xor, broadcast, LACP (Link Aggregation Control Protocol) или 802.3ad, balance-tlb и balance-alb. Следующая таблица перечисляет различные режимы сцепления, а также их политики и описания:

Режим сцепления	Политика	Описание
balance-rr или Mode 0	Round robin (карусельная)	Передача пакетов происходит последовательно от первого к последнему участвующим сетевым интерфейсам. Это предоставляет балансировку нагрузки и устойчивость к отказам.
active-backup или Mode 1	Active backup (активное резервное копирование)	Только один участвующий интерфейс является активным. Следующий интерфейс становится активным при отказе предыдущего. Это предоставляет только устойчивость к отказам.
balance-xor или Mode 2	XOR (исключающее ИЛИ)	Этот режим выбирает один и тот же интерфейс участника для каждого адреса MAC получателя. Передача имеет место на основе сцепленных сетевых интерфейсов адресов MAC, сравнивающихся по исключающему ИЛИ с адресом MAC получателя. Это предоставляет и балансировку нагрузки, и устойчивость к отказам.
broadcast или Mode 3	Broadcast (широковещательная)	Передача осуществляется по всем участвующим в сцеплении сетевым интерфейсам. Это предоставляет только устойчивость к отказам.
802.3ad или Mode 4	Динамичное соединение связей	Все интерфейсы- участники в группе агрегации совместно используют одни и те же установки скорости и дуплекса. Все интерфейсы используются в соответствии со спецификацией 802.3ad. Необходим сетевой коммутатор с поддержкой 802.3ad или функциональностью LACP. Это предоставляет устойчивость к отказам.
balance-tlb или Mode 5	Балансировка нагрузки адаптивным обменом	Исходящие пакеты распределяются согласно текущей нагрузке на каждом участвующем интерфейсе. Входящие пакеты принимаются текущим интерфейсом, а если этот интерфейс отказывает, тогда вступает в дело следующий интерфейс. Это предоставляет устойчивость к отказам и балансировку нагрузки только для исходящих пакетов.
balance-alb или Mode 6	Адаптивная балансировка нагрузки	Аналогична balance-tlb с включением балансировки нагрузки входящих пакетов для всех интерфейсов.Это предоставляет устойчивость к отказам и балансировку нагрузки как для входящих, так и для исходящих пакетов.

Следующий снимок экрана показывает систему меню Proxmox, применяемую для создания нового Bond

 

Добавление сцепленного интерфейса

Теперь мы увидим как добавлять сцепленные интерфейсы в кластер. Существуют различные типы доступных возможностей сцепления. Однако достаточно широко применяются только balance-rr, active-backup и LACP (802.3ad). Параметр balance-rr предоставляет карусельный метод для увеличения общей пропускной способности интерфейса при его отказоустойчивости. Опция balance-rr не требует специального сетевого коммутатора. Практически любой коммутатор может быть применён для данной работы. Основным недостатком balance-rr является потеря пакетов данных. LACP является общепринятым индустриальным стандартом сцепления.

В данной книге мы рассмотрим только протокол связывания LACP. Однако, чтобы дать вам представление о том, как выглядит связывание balance-rr, следующая схема показывает сцепление balance-rr между узлами Proxmox и распределённым кластером хранения Ceph. В данном примере общедоступная сетевая среда Proxmox это 192.168.10.0/24, в то время как сервера хранения находятся в частной подсети 192.168.201.0/24. Для увеличения избыточности применяется отдельный коммутатор для сетевой среды хранения Ceph. Каждый узел Proxmox имеет три NIC с 1-гигибит. Один применяется в нашем главном кластере для обслуживания виртуальных машин, а остальные два применяются для сцепленного канала balance-rr. Этот тип является очень экономичным способом предоставления избыточности:

LACP может объединять множество интерфейсов для увеличения общей пропускной способности, хотя при этом и не для одного реального соединения. Например, LACP сцепление четырёх 1-гигабитных сетевых интерфейсов всё равно будет иметь общую скорость для соединения 1 гигабит, однако оно будет способно отвечать на большее число одновременных запросов на близкой к 1 гигабит скорости.

Для того, чтобы LACP работал, очень важно знать поддерживает ли коммутатор эту функцию. Быстрый просмотр на сайте производителя снабжает нас информацией поддерживается ли функциональность LACP. Некоторые производители перечисляют эту характеристику как 802.3ad.

Как и в случае с виртуальным мостом, мы также можем настроить сетевое сцепление через GUI или CLI Proxmox. Сцепление, созданное через GUI будет активировано после перезагрузки узла, в то время как объединение, добавляемое через CLI путём прямого изменения файла настройки сети может быть просто активировано через CLI. Мы можем открыть блок диалога создания сцепления интерфейса в закладке Hardware данного узла. Следующий снимок экрана отображает блок диалога для интерфейса сцепления, bond0 для нашего примера узла Proxmox:

В нашем предыдущем примере мы использовали физические интерфейсы, eth0 и eth1 для нашего сцепленного интерфейса, bond0. Мы не использовали никакой информации IP поскольку этот сцепленный интерфейс не будет соединяться напрямую, однако мы создадим интерфейсы VLAN и виртуальных мостов на основе этого сцепленного интерфейса. В качестве режима сцепления мы применяем LACP с политикой хеширования уровня 2+3. Существует три политики хеширования для выбора из ниспадающего списка:

Для получения максимальной производительности и стабильности сетевого соединения важно понимать разницу между этими политиками.

 

Политика хеширования 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 в следующий интерфейс сцепления:

auto eth1
iface eth1 inet manual
auto eth2
iface eth2 inet manual

# bonding interfaces
auto bond0
iface bond0 inet manual
        slaves eth1 eth2
        bond_miimon 100
        bond_mode 802.3ad
 	   

Мы собираемся добавить следующие строки кода для создания виртуального моста с использованием порта сцепления:

auto vmbr1
iface vmbr1 inet static
        address 192.168.10.1
        netmask 255.255.255.0
        bridge_ports bond0
        bridge_stp off
        bridge_fd 0
 	   

Активируйте мост перезагрузкой данного узла или из CLI остановив мост и повторно его запустив. Воспользуйтесь следующими командами:

# ifup bond0
# ifdown vmbr1
# ifup vmbr1
 	   

После настройки узлов Proxmox со сцеплением LACP, мы теперь должны настроить LACP на физическом коммутаторе. Каждый коммутатор приходит со своей собственной документацией того, как настраивать агрегацию связей LACP. В данном разделе мы собираемся рассмотреть интеллектуальный коммутатор Netgear GS748T с функциональностью LACP. Опция включения LACP может быть найдена путём навигации по Switching | LAG в GUI Netgear. Вначале мы должны разрешить LACP для каждой группы связей. Следующий экранный снимок отображает LACP, включённый для групп с 1 по 3 в меню LAG Configuration:

После того, как группы соединений включены, мы назначим порты коммутатора для каждой группы. В нашем примере мы назначаем порты 1 и 2 в группу 1 с именем ch1, 2 и 3 в группу с именем ch2, а порты 5 и 6 в группу с именем ch3. Следующий снимок экрана отображает включение портов для группы 1:

Сцепление также может быть использовано с VLAN. Отсылаем к разделу Виртуальная сеть в этой главе для изучения того, как интегрировать сцепление с VLAN.

Начиная с Proxmox VE 4.0 и в последующих версиях для надлежащего взаимодействия в кластере теперь необходима множественная адресация. Говоря простыми словами, множественная адресация доставляет единственную пересылку множеству узлов в сети одновременно, в то время как индивидуальная адресация отсылает пакеты данных единичным получателям из одного источника. Чем больше узлов присутствует в кластере, тем больше отдельных индивидуальных пакетов необходимо пересылать в кластере. Применяя множественную адресацию, такой дополнительный объём обмена существенно минимизируется. Из- за существенного увеличения числа пакетов в сетевой среде при использовании уникальной адресации, следует избегать её реализация в кластере с пятью и более узлами. Для надлежащей работы множественной адресации, физические коммутаторы в сетевой среде должны поддерживать множественную адресацию и быть способными к отслеживанию IGMP (IGMP snoop)

Отслеживание IGMP просто является процессом, при котором физические коммутаторы прослушивают или отслеживают IGMP взаимодействие между узлами и таким коммутатором. Это делает возможным коммутатору поддерживать таблицу или карту определения того, как и куда отправлять запросы множественной адресации. Чтобы подобный коммутатор установил таблицу после получения достаточную для получения достаточных данных для всех портов коммутации со включённой многоадресной коммутацией требуется несколько часов после разрешения отслеживания IGMP.

Если во всей среде Proxmox не представляется возможным применением множественной адресации, тогда индивидуальная адресация является единственным вариантом. Для проверки того, работает ли в нашем кластере множественная адресация, мы можем выполнить следующую команду:

# omping >node1_ip> <node2_ip> .....
 	   

Если множественная адресация полностью функциональна, вывод продемонстрирует отклики множественной адресации, как это показано на следующем снимке экрана:

root@pm4-2:~# omping -c 10 172.16.0.171 172.16.0.172 
172.16.0.171 : waiting for response msg 
172.16.0.171 : joined (S,G) = (*, 232.43.211.234), pinging 
172.16.0.171 :   unicast, seq=1, size=69 bytes, dist=0, time=0.192ms 
172.16.0.171 : multicast, seq=1, size=69 bytes, dist=0, time=0.322ms 
172.16.0.171 :   unicast, seq=2, size=69 bytes, dist=0, time=0.235ms 
172.16.0.171 : multicast, seq=2, size=69 bytes, dist=0, time=0.278ms 
172.16.0.171 :   unicast, seq=3, size=69 bytes, dist=8, time=0.816ms 
172.16.0.171 : multicast, seq=3, size=69 bytes, dist=8, time=0.843ms 
172.16.0.171 :   unicast, seq=4, size=69 bytes, dist=0, time=0.212ms 
172.16.0.171 : multicast, seq=4, size=69 bytes, dist=0, time=0.311ms 
172.16.0.171 :   unicast, seq=5, size=69 bytes, dist=0, time=0.364ms 
172.16.0.171 : multicast, seq=5, size=69 bytes, dist=0, time=0.378ms 
172.16.0.171 :   unicast, seq=6, size=69 bytes, dist=8, time=0.263ms 
172.16.0.171 : multicast, seq=6, size=69 bytes, dist=0, time=0.276ms 
172.16.0.171 :   unicast, seq=7, size=69 bytes, dist=8, time=0.230ms 
172.16.0.171 : multicast, seq=7, size=69 bytes, dist=0, time=0.240ms 
172.16.0.171 :   unicast, seq=8, size=69 bytes, dist=8, time=0.242ms 
172.16.0.171 : multicast, seq=8, size=69 bytes, dist=8, time=0.304ms 
172.16.0.171 :   unicast, seq=9, size=69 bytes, dist=8, time=0.283ms 
172.16.0.171 : multicast, seq=9, size=69 bytes, dist=0, time=0.297ms 
172.16.0.171 :   unicast, seq=10, size=69 bytes, dist=8, time=0.219ms 
172.16.0.171 : multicast, seq=18, size=69 bytes, dist=8, time=0.232ms 
172.16.0.171 : given amount of query messages was sent 

172.16.0.171 :   unicast, xmt/rcu/%loss = 10/10/0%, min/aug/max/std-dev = 0.192/0.306/0.016/0.186 
172.16.0.171 : multicast, xmt/rcu/%loss = 10/10/0%, min/aug/max/std-dev = 0.232/0.348/0.043/0.179 
root@pm4-2:~# _ 

 	   

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

 

Настройка множественной адресации в Netgear

В данном разделе мы ознакомимся с настройкой множественной маршрутизации для интеллектуального коммутатора Netgear GS748T. Для настройки множественной адресации переместитесь в Switching | Multicast Вначале мы собираемся разрешить состояние отслеживания IGMP в опции IGMP Snooping Configuration, как это отображено на следующем снимке экрана:

Далее мы должны разрешить режим администратора для интерфейсов, которые будут применяться для отслеживания IGMP. Мы можем разрешить их в опции IGMP Snooping Interface Configuration. Как показано на следующем экранном снимке, мы включаем отслеживание IGMP для портов с 1 по 6, которые являются присоединёнными к узлам Proxmox:

Последняя подлежащая исполнению настройка заключается в разрешении многоадресного обмена для портов коммутатора в опции Multicast Router Configuration. В нашем примере мы включаем многоадресную адресацию для портов 1 по 6, как это показано на следующем снимке экрана:

Лицензируемый в соответствии с Apache 2.0, Open vSwitch является многоуровневым виртуальным коммутатором корпоративного уровня, появившийся на свет специально для применения в современных виртуальных сетях виртуальных сред. Он аналогичен виртуальному мосту Linux, однако имеет больше возможностей при большей надёжности. Часто задаваемый вопрос состоит в том, почему следует выбирать Open vSwitch вместо обычного проверенного временем и индустрией моста и сетевой среды Linux. Когда мы поймём функциональность и преимущества Open vSwitch, предоставляемые для виртуальной сетевой среды, ответ станет очевидным.

Ниже приводятся некоторые основные свойства, которые делают Open vSwitch лучшим вариантом, чем стандартные сетевые среды Linux.

Допускается построение кластера Proxmox полностью на мостах Linux полностью без использования Open vSwitch. Однако, для крупных окружений Open vSwitch имеет большой смысл, так как это может уменьшить утомительное управление виртуальной сетью, предоставляя отличную визуализацию сетевого обмена. В средах со множеством владельцев очень важно наличие общего управления над тем, что происходит в сети.

По умолчанию Open vSwitch не установлен в Proxmox. Он должен быть установлен и настроен вручную. На вновь установленном узле Proxmox мы должны настроить обычным образом сетевую среду с тем, чтобы узел мог иметь связь с Интернетом. Затем выполните следующую команду для установки Open vSwitch:

# apt-get install Open vSwitch-switch
 	   

Даже если Open vSwitch не установлен, GUI Proxmox всё равно отображает параметры меню для моста Open vSwitch и интерфейса в закладке Create меню каждого узла Network.

Существует три компонента, которые мы можем применять в Open vSwitch:

Мост Open vSwitch похож на мост Linux, за исключением того, что мы можем настроить один мост Open vSwitch, такой как физический коммутатор, в котором мы можем пропускать различные vlans. У нас нет необходимости создавать отдельные мосты для каждой vlans, как это делается в мостах Linux. Настройка моста Open vSwitch слегка более сложная, чем настройка моста Linux. Вначале, перед созданием действительного моста, нам нужно настроить отдельный порт. В нашем примере мы собираемся настроить свой порт, eth1, который является тем, на чём будет основан наш мост Open vSwitch, vmbr2. Для этого нам нужно добавить следующие строки в код /etc/network/interfaces:

allow-vmbr2 eth1
iface eth1 inet manual
  ovs_type OVSPort
  ovs_bridge vmbr2

auto vmbr2
allow-ovs vmbr2
iface vmbr2 inet static
  address 192.168.0.171
  netmask 255.255.255.0
  ovs_type OVSBridge
  ovs_ports eth1
 	   

В отличие от моста Linux, в котором мы можем пропускать vlans через соответственно тегированные мосты, в open vSwitch мы можем пропускать vlans через порты напрямую. Транки VLAN настраиваются как дополнительные опции Open vSwitch в конфигурации, как это демонстрируется в следующем примере, где мы осуществляем проброс VLAN 2, 3 и 4:

allow-vmbr2 eth1
iface eth1 inet manual
  ovs_type OVSPort
  ovs_bridge vmbr2
  ovs_options trunks=2,3,4
 	   

Мы также можем настроить мост Open vSwitch при помощи GUI Proxmox. Однако нам нужно иметь в виду, что любая выполненная через GUI Proxmox настройка сети не будет активирована пока не будет выполнен перезапуск узла.

Мы можем открыть блок диалога создания моста Open vSwitch в закладке сетевой среды узла, как это отображено на следующем снимке экрана:

На следующем снимке экрана отображён блок диалога создания нашего моста Open vSwitch со всей необходимой информацией:

В параметрах OVS мы можем включить дополнительные опции для этого моста.

Как и для моста Linux, мы можем создавать различные сцепленные интерфейсы Open vSwitch. В данном примере мы собираемся создать сцепленный LACP интерфейс для Open vSwitch. Для создания моста Open vSwitch применяются следующие параметры настройки для создания сцепленного интерфейса при помощи данного интерфейса:

allow-vmbr2 bond0
iface bond0 inet manual
  ovs_type OVSBond
  ovs_bridge vmbr2
  ovs_bonds eth0 eth1
  pre-up (ifconfig eth0 mtu 8996 && ifconfig eth1 mtu 8996)
  ovs_options bond_mode=balance-tcp lacp=active trunks=2,3,4
  mtu 8996
auto vmbr2
iface vmbr2 inet manual
  ovs_type OVSBridge
  ovs_ports bond0
  mtu 8996
 	   

В предыдущем примере был добавлен новый параметр, pre-up. Он используется для настройки пакетов jumbo. Значение mtu по умолчанию для всех интерфейсов 1500. Если настроены пакеты jumbo, более безопасно применять значение 8996 вместо 9000, поскольку поверх настроенного mtu добавляются некоторые дополнительные байты, из- за которых пакеты данных могут отвергаться в случае, когда mtu выходит за пределы 9000.

Мы можем настроить те же самые сцепления Open vSwitch с применением GUI Proxmox воспользовавшись блоком диалога создания сцепления, как это показано на следующем снимке экрана:

Через GUI Proxmox невозможно добавлять дополнительные параметры, например, настройку нужного mtu. Поэтому перед перезапуском данного узла мы можем добавить соответствующий параметр в /etc/network/interfaces.new и соответствующие настройки будут зафиксированы в /etc/network/interfaces при перезагрузке данного узла.

В Open vSwitch можно предоставить хосту или физическому узлу доступ к VLAN через настроенный мост Open vSwitch. Это осуществляется путём создания компонента Open vSwitch, называемого IntPort. Проще говоря, IntPort расщепляет VLAN, который мы можем настроить для назначения информации IP. Это полезно для предоставления узлу Proxmox доступа к VLAN. Например, в нашем упражнении узел Proxmox pm4-1 в настоящее время настроен на применение моста Linux, vmbr0. Если мы хотим использовать вместо этого Open vSwitch, мы будем должны создать IntPort Open vSwitch чтобы предоставить данному узлу доступ к мосту Open vSwitch с использованием VLAN. В настройку сетевой среды должны быть добавлены следующие параметры:

auto vmbr0
allow-ovs vmbr0
iface vmbr0 inet manual
  ovs_type OVSBridge
  ovs_ports eth0 vlan1

allow-vmbr0 vlan1
iface vlan1 inet static
  ovs_type OVSIntPort
  ovs_bridge vmbr0
  ovs_options tag=50
  ovs_extra set interface ${IFACE} external-ids:iface-id=$(hostname -s)-${IFACE}-vif
  address 172.16.0.171
  netmask 255.255.255.0
  gateway 172.16.3.254
  mtu 1500
 	   

Отметим, что при настройке данного порта мы добавили оба интерфейса, и eth0, и IntPort vlan1 следующим образом:

ovs_ports eth0 vlan1
 	   

Помимо параметров создания и редактирования устройств Open vSwitch при помощи GUI Proxmox, Open vSwitch поставляется с опциями командной строки для управления и получения информации по определённому мосту, сцеплению или интерфейсу. В Open vSwitch присутствует четыре типа команд:

Обсуждение подробностей всех доступных команд Open vSwitch выходит за рамки настоящей книги. В данном разделе мы рассмотрим только команды, которые могут оказаться очень полезными при управлении кластером Proxmox:

Для ознакомления с полным перечнем доступных команд Open vSwitch посетите http://www.pica8.com/document/v2.3/pdf/ovs-commands-reference.pdf.

Если вы впервые используете Open vSwitch, это может казаться вам поначалу непростым. Однако по мере приобретения практики и непосредственного общения действительно становится проще создавать управлять комплексом виртуальной сетевой среды, полностью вооружённым Open vSwitch. В данном разделе вам будет предоставлена задача создания настройки сетевой среды для узла Proxmox при помощи всех сетевых компонентов, которые мы изучили к настоящему моменту. Полная настройка представлена в последующем разделе, однако попробуйте вначале создать её самостоятельно.

 

Требования настройки

Узел Proxmox имеет три порта интерфейсов физической сетевой среды eth0, eth1 и eth2, а также один интерфейс Infiniband ib0.

Мы должны настроить сцепленный LACP интерфейс Open vSwitch с двумя физическими портами. Мост должен быть настроен в виде транка для VLAN 11, 12, 13 и 14. Все тегироаванные интерфейсы ВМ будут подключаться к этому мосту. Третий физический интерфейс должен будет настроен на цели резервного копирования в отдельной подсети без VLAN.

Интерфейс infiniband должен быть настроен на использование с Ceph в отдельной подсети. Этот узел должен применять VLAN 12 для всех связанных с хостом взаимодействий при помощи моста Open vSwitch.

 

Решения

Ниже приводятся полные настройки сетевой среды для заданных требований:

auto lo
iface lo inet loopback

# LACP Bonded Open vSwitch Interface
allow-vmbr0 bond0
iface bond0 inet manual
  ovs_bridge vmbr0
  ovs_type OVSBond
  ovs_bonds eth0 eth1
  pre-up (ifconfig eth0 mtu 8996 && ifconfig eth1 mtu 8996)
  ovs_options bond_mode=balance-tcp lacp=active other_config:lacp-time=fast trunks=11,12,13,14 
  mtu 8996

# Creating Open vSwitch bridge
auto vmbr0
allow-ovs vmbr0
iface vmbr0 inet manual
  ovs_type OVSBridge
  ovs_ports bond0 vlan12
  mtu 8996

# Creating IntPort for physical node
allow-vmbr0 vlan12
iface vlan12 inet static
  ovs_type OVSIntPort
  ovs_bridge vmbr0
  ovs_options tag=12
  ovs_extra set interface ${IFACE} external-ids:iface-id=$(hostname–s)-${IFACE}-vif
  address 172.16.0.171
  netmask 255.255.252.0
  gateway 172.16.3.254
  mtu 1500

# Creating Infiniband interface
auto ib0
iface ib0 inet static
  address 192.168.0.171
  netmask 255.255.255.0
  pre-up modprobe ib_ipoib
  pre-up echo connected > /sys/class/net/ib0/mode
  mtu 65520

# Creating dedicated interface for backup
auto eth2
iface eth2 inet static
  address 192.168.10.171
  netmask 255.255.255.0
 	   

На данный момент мы рассмотрели компоненты виртуальной среды в рамках среды кластера Proxmox. Мы знаем все компоненты применяемые Proxmox для совместной поддержки всего.

Мы собираемся рассмотреть несколько сценариев виртуальных окружений для закрепления нашего понимания сетевых сред в виртуальных окружениях Proxmox. Такие схемы на основе сценариев и кое- что в них взято из реальных промышленных сред.

Это небольшой кластер Proxmox с тремя узлами и двумя подсетями в пределах нашей виртуальной среды. Каждый узел Proxmox имеет два NIC, причём оба моста vmbr0 и vmbr1 подключены к eth0 и eth1 соответственно. Каждый мост имеет три подключённых к нему виртуальные машины. За пределами виртуальной среды присутствует физический коммутатор, который соединяет узлы Proxmox и консоль администратора для вей работы управления. Такой Proxmox является простейшим в производственной среде. Такой тип сетевой среды может использоваться для обучающей платформы или для очень маленького бизнес- окружения с небольшими запросами на рабочую нагрузку. Связь с Интернетом предоставляется второй подсети напрямую из межсетевого экрана вторым NIC, как это показано на следующей схеме:

Эта установка сетевой среды почти та же самая, что и предыдущая сеть с добавлением преимуществ виртуальной платформы полностью ориентированной на множество владельцев. В физическом межсетевом экране мы можем добавлять только очень небольшое число NIC для предоставления связности с Интернет изолированным подсетям. Применяя виртуальный межсетевой экран мы можем добавить столько межсетевых экранов или vNIC, сколько нам нужно. Данная настройка особенно полезна, когда необходимо поддерживать множественные изолированные подсети клиентов, причём каждая подсеть требует своё собственное управление межсетевым экраном для целей фильтрации. В данном примере vmbr0 напрямую обслуживается нашим физическим межсетевым экраном. Мосты vmbr1 и vmbr200 имеют свои собственные виртуальные межсетевые экраны. Межсетевые экраны также работают как мосты между мостами. Например, межсетевой экран для подсети 2 имеет два vNIC. Одна из этих установок была WAN, в которой vmbr0 работал как поставщик Интернет. Второй vNIC был развёрнут в сторону LAN, которая обслуживала подсеть 2.

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

Для виртуализации межсетевого экрана наилучшим выбором для установки является pfsense. Он прост в настройке и при этом всё ещё мощен и приспособлен для индивидуальной настройки. Для получения pfsense и дополнительной информации отсылаем к pfsense.org {Прим. пер.: также рекомендуем ознакомиться с нашим переводом Книги 2, pfSense из руководства Ли Р. Сюрбера Полная виртуализация (февраль 2016).}

Следующая схема является примером виртуальной среды со множеством владельцев.

Данная схема сетевой среды является примером сети академического института. Следующая схема отображает сетевые связи между административным офисом, библиотекой, а также удалённым кампусом. Существует два физических межсетевых экрана, предоставляющих избыточность связи с Интернетом. Главная виртуальная сетевая среда состоит из сервера базы данных, файлового сервера, сервера учётных записей, а также сервера каталога библиотеки. Сервер базы данных и файловый сервер соединены с мостом, vmbr0. Сервер учётных записей соединён со своим мостом vmbr10 и VLAN с идентификатором 10. Сервер библиотеки соединяется со своим мостом vmbr20 и VLAN с идентификатором 20. Главный коммутатор установлен на работу с VLAN 10 и 20. Коммутатор библиотеки настроен на работу с VLAN 20. В данной установке данные сервера учётных записей поступают напрямую в административный офис, а данные сервера каталога библиотеки идут в здание библиотеки не создавая дополнительной нагрузки на общую сетевую среду. Студенты и персонал удалённого кампуса могут осуществлять доступ к главной сетевой среде кампуса через VPN, тем самым ограничивая потребность в настройке отдельной виртуальной среды.

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

Множество владельцев (арендаторов) очень часто применяется в мире облачных вычислений, в котором виртуальные среды постоянно используются различными пользователями из установок различных организаций при полной изолированности сетевых сред. Среда со множеством владельцев является неотъемлемой частью служб поставщика, который предоставляет IaaS (Infrastructure-as-a-Service) множеству пользователей.

При данном типе установки, поставщик услуг осуществляет хостинг или "сдаёт в аренду" вычислительное время и пространство хранения своим клиентам. Поскольку для данного вида услуг требуется стандартная ежемесячная подписка или платежи на основе SLA, термин множества владельцев (multitenancy) быстро приобретает популярность. Обычно виртуальные среды со множеством пользователей появляются там, где одновременно существует несколько изолированных сетевых сред на одной и той же платформе без их пересечения друг с другом. Почти все общедоступные центры обработки данных являются платформами с множеством владельцев (арендаторов).

Множественность владельцев (арендаторов) не является новой в мире информации. Первые среды со множеством владельцев уходят назад к 1960м, когда компании арендовали машинное время и пространство хранения мэйнфрейм компьютеров для уменьшения гигантских затрат работы на больших ЭВМ. Виртуальные среды всего лишь экспоненциально форсируют ту же идею, усиливая все свойства виртуализации, предоставляемые Proxmox. Комбинируя виртуализацию с облачными вычислениями, многопользовательская среда способна получить очень сильное соответствие лучшему обслуживанию пользователей при их большем количестве без увеличения финансовых накладных расходов. До эпохи виртуализации требования физического пространства и мощности для потребителей хостинга в средах IAAS {инфраструктуры как службы} означали, что они были редки при непомерно высокой стоимости, таким образом, мало кто ими пользовался.

Гипервизор Proxmox способен настраивать стабильные и масштабные виртуальные среды со множеством владельцев. Поскольку мы осознаём взаимосвязь между виртуальными машинами и виртуальными мостами, будет довольно просто создать при помощи Proxmox виртуальную среду со множеством владельцев.

Ниже приводится пример схемы сети типичного поставщика облачных услуг, который предоставляет IAAS своим клиентам. Вся сетевая среда является виртуальной в рамках виртуального окружения поставщика услуг:

С клиентской стороны они просто имеют простые настольные компьютеры и мобильные устройства для доступа к своим виртуальным облачным ресурсам, таким как рабочие столы, хранилища, мощность процессоров и тому подобное. Клиенты осуществляют доступ к этим ресурсам виртуально, например, через VNC (Virtual Network Computing), SPICE или RDP Remote Desktop Protocol {Прим. пер.: а также Huawei HDP или Nice DCV и ряд других протоколов.}

Виртуальные сети изолированы отдельными подсетями. VLAN является настройкой (не показанной на схеме) для уменьшения массивного широковещательного обмена. Все данные виртуальных машин хранятся в отдельном кластере хранения с полной избыточностью. Кластер резервных копий выполняет регулярное резервное копирование всех виртуальных машин, а гранулярное резервное копирование файлов с их историями выполняется программным обеспечением резервного копирования сторонних производителей. Кластер виртуального межсетевого экрана настраивается между виртуальной средой и интерфейсом Ethernet хоста предоставляя связь с Интернетом всем пользователям виртуальных машин. Каждый виртуальный межсетевой экран имеет несколько vNIC, соединённых с каждой подсетью. Типичный виртуальный межсетевой экран со множеством vNIC будет выглядеть так, как это показано на следующем снимке экрана:

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

Данная среда обслуживает множество клиентов или организаций, поэтому время работы без простоев является большим предметом беспокойства. Для исключения этой проблемы, целые виртуальные среды реплицируются в другие центры обработки данных для гарантирования 99.9 процентов времени работы. Предыдущая схема является упрощённой версией с перекрытием от того, что в действительности происходит внутри очень занятых виртуальных сред Proxmox. Изучение этой схемы даст ясное понимание механики виртуальных сетевых сред. Из предыдущей схемы мы можем увидеть, что эта сетевая среда интенсивно использует виртуальные мосты. Поэтому очень важно понимать роль мостов и планировать черновые схемы перед реальной установкой этого уровня сложной виртуальной сети.

Мы были очень заняты в этой интенсивной главе. Мы рассмотрели различия между физическими и виртуальными сетями. Мы изучили сетевые компоненты Proxmox, которые создают виртуальную сеть на основе Proxmox. Также мы ознакомились с Open vSwitch и его компонентами для создания действительно сложных виртуальных сетей. Мы даже проанализировали несколько схем сетевых сред начиная с базовой до самых передовых для получения лучшего представления о том как виртуальные сети Proxmox в действительности приходят в жизнь.

Proxmox предоставляет все необходимые нам инструменты для построения виртуальной сети любого уровня. Как сформировать хорошо спроектированную и эффективную виртуальную сеть зависит только от воображения сетевого администратора, бюджета компании, а также необходимости предвидения того, как все части должны быть собраны вместе. Самое приятное то, что любую ошибку легко исправить в виртуальной сети. Мы всегда можем вернуться назад и изменить порядок, пока не будем удовлетворены. Именно по этой причине виртуальная сеть постоянно развивается. Со временем виртуальная сеть становится расширением сетевого сознания администратора. Настройка и архитектура инфраструктуры виртуальной сети может дать нам окно в то, о чём думает администратор и используемую им логику для конструирования среды.

В следующей главе мы собираемся изучить построение межсетевого экрана Proxmox и того, как защищать весь кластер вплоть до отдельной виртуальной машины.