OpenStack предоставляет богатое сетевое окружение, а данная глава подробно излагает требования и варианты для рассмотрения при проектировании вашего облака.
![[Предостережение]](../common/images/admon/warning.png)
Например, вы должны планировать количество IP-адресов, которые вам потребуется как для гостевых экземпляров, так и для инфраструктуры управления. Кроме того, вам необходимо изучить и обсудить сетевые подключения облака через серверы прокси и межсетевые экраны.
В даннойглаве мы примедем некоторые примеры реализаций сетей для анализа и предоставления информации а некоторых сетевых макетах, которые использует OpenStack. Наконец, мы изложим некоторые короткие замечания о сетевых службах, которые необходимы для стабильной работы.
A управляющая сеть (выделенная сеть для использования операторами вашего облака) обычно состоит из отдельных комутаторов и отдельных NIC (сетевых интерфейсных плат, network interface cards) и является рекомендуемым параметром. Такое разделение предотвращает системное администрирование и мониторинг системы от от воздействия обмена, генерируемого гостями.
Рассмотрите возможность создания других частных сетей для связи между внутренними компонентами OpenStack, такими как очереди сообщений и вычислительная среда OpenStack. Использование виртуальных локальных сетей прекрасно работает в таких сценариях, поскольку оно предоставляет метод для создания множества виртуальных сетей в физической сети.
Существуют два основных типа IP-адресов для гостевых виртуальных машин: фиксированные IP и плавающие IP. Фиксированные IP-адреса присваиваются экземплярам при загрузке, в то время как плавающие IP-адреса могут менять свои связи с экземплярами в результате действий пользователя. Оба типа IP-адресов могут быть либо общедоступными (public), либо частными, в зависимости от вашего варианта использования.
При потребности запуска OpenStack без плавающих IP-адресов, необходимы фиксированные IP-адреса. Одним из самых распространенных вариантов использования плавающих IP-адресов является предоставление общедоступных IP-адресов в частном облаке при существовании ограничения на число доступных IP-адресов. Другим вариантом для пользователя общедоступного облака является необходимость наличия "статического" IP-адреса, который может быть переназначен при обновлении или перемещении экземпляра.
Фиксированные IP-адреса могут быть частными для частных облаков и общедоступными для общедоступных облаков. Фиксированный IP теряется после завершения работы экземпляра. Не стоит беспокоиться новым пользователям облачных вычислений, которые могут быть расстроены такой эфемерностью.
Инсталляция OpenStack потенциально может иметь много подсетей, причем каждая подсеть может предоставлять различные виды услуг. Планирование IP адресов может помочь общему пониманию задач разделов сети и их масштабируемости. Службы управления могут иметь общедоступные и частные IP-адреса, и, как отмечалось выше, есть несколько вариантов для адресации экземпляра в общедоступном адресном пространстве.
Планирование IP адресов может быть разбито на следующие разделы:
- Маршрутизация подсетей
-
Покидающие подсеть пакеты следуют через этот адрес, который может быть выделенным маршрутизатором или службой
nova-network - Управляющая службы общедоступных интерфейсов
-
Через эти адреса осуществляется общий доступ к
swift-proxy,nova-api,glance-apiи horizon, причем адреса могут быть по одну сторону за балансировщиком нагрузки или указывать на отдельные компьютеры. - Внутренние коммуникации кластера хранилища объектов
-
Эту частную сеть использует обмен между серверами объектов/ учетных записей / контейнеров, а также между ними и внутренним интерфейсом серверов прокси.
- Взаимодействие компьютеров и хранилищ
-
Эта сеть используется, если эфемерные или блочные хранилища являются внешними для вычислительных узлов.
- Внеполосное удаленное управление
-
Эта сеть обычно выделяется в отдельную, если в серверах имеется выделенная микросхема контроллера удаленного доступа (прим. пер.: например, с использованием протокола IPMI).
- Внутриполосное удаленное управление
-
Для системного администрирования или средств мониторинга на вычислительных узлах или узлах хранения обычно используется дополнительный интерфейс (например, 1Гб) вместо общедоступного интерфейса.
- Свободное пространство дальнейшего роста
-
Часть вашего планирования всегда должна предусматривать добавление дополнительных услуг служб управления на общедоступной стороне или дополнительных IP гостевых экземпляров.
В качестве примера рассмотрим развертывание и вычислительной среды, и хранилище объектов OpenStack при доступных диапазонах частных адресов 172.22.42.0/24 и 172.22.87.0/26. Одним из вариантов деления пространства может быть следующий:
172.22.42.0/24:
172.22.42.1 - 172.22.42.3 - маршрутизаторы подсети
172.22.42.4 - 172.22.42.20 - резерв для сетей
172.22.42.21 - 172.22.42.104 - Контроллеры удаленного доступа вычислительных узлов
(включая резерв)
172.22.42.105 - 172.22.42.188 - Интерфейсы управления вычислительными узлами
(включая резерв)
172.22.42.189 - 172.22.42.208 - Контроллеры удаленного доступа прокси Swift
(включая резерв)
172.22.42.209 - 172.22.42.228 - Интерфейсы управления прокси Swift (включая резерв)
172.22.42.229 - 172.22.42.252 - Контроллеры удаленного доступа серверов хранения Swift
(включая резерв)
172.22.42.253 - 172.22.42.254 - резерв
172.22.87.0/26:
172.22.87.1 - 172.22.87.3 - маршрутизаторы подсети
172.22.87.4 - 172.22.87.24 - Внутренние интерфейсы серверов прокси Swift
(включая резерв)
172.22.87.25 - 172.22.87.63 - Внутренние интерфейсы серверов объектов Swift
(включая резерв)
Аналогичный подход может быть принят для общедоступных IP-адресов,
принимая во внимание, что крупные, диапазоны без сегментации являются предпочтительными
к использованию для IP-адресов гостевых экземпляров. Учтите, что для определенных
сетевых вариантов OpenStack, хостам nova-compute
назначаются общедоступные IP адреса в диапазоне общедоступных IP адресов
гостевых экземпляров.
Вычислительная среда OpenStack совместно с nova-network
обеспечивает предопределенные модели развертывания сети, причем у каждой
из них есть свои сильные и слабые стороны. Выбор управления сетью изменяет
топологию сети, соответственно он должен быть выполнен тщательным образом.
Вы также должны выбрать между проверенными на практике установками традиционной
nova-network или проектом neutron
для сетевой среды OpenStack. Оба варианта предлагают сетевые средства для
запуска экземпляров для различных реализаций и требований.
Для сетевых средств OpenStack в рамках проекта neutron, типовые настройки документированы с идеей, что любую установку, которую вы можете настроить с реальным оборудованием, можно воссоздать с помощью управляемого программным обеспечением эквивалента. Каждый владелец может содержать типовые сетевые компоненты, такие как маршрутизаторы и службы, например, DHCP.
Таблица 7.1., “Варианты развертывания сети” описывает варианты развертывания сети как для
традиционного варианта nova-network, так и для эквивалентной
конфигурации neutron.
| Модель развертывания сети | Преимущества | Недостатки | Эквивалент neutron |
|---|---|---|---|
Flat |
Чрезвычайно простая топология. Отсутствует широковещательный DHCP. |
Требует инъекции файлов в экземпляр для настройки сетевого интерфейсов. |
Настройка одного моста в качестве моста интеграции(br-int) идеей его подключение к физическому интерфейсу пр помощи плагина Modular Layer 2 (ML2), который по умолчанию использует Open vSwitch. |
FlatDHCP |
Относительно прост в настройке. Стандартное подключение к сети. Работает со всеми гостевыми операционными системами. |
Требует свой собственный домен DHCP. |
Настройка агентов DHCP и агентов маршрутизации. Трансляция сетевых адресов (NAT, Network Address Translation) выполняется вне вычислительных узлов, обычно на одном или нескольких сетевых узлах. |
VlanManager |
Каждому владельцу выделяется своя собственная VLAN. |
Более сложен в настройке. Требует свой широковещательный домен DHCP. Требует объединения (транкинга) многих VLAN в один порт. Стандартное ограничение на число VLAN. Коммутаторы должны поддерживать расстановку тегов 802.1q VLAN |
Изолированные сети владельцев реализуют некий вид изоляции обмена 2 уровня между различными сетями. Маркированные VLAN являются ключевой концепцией, при которой обмен "помечается" простым идентификатором VLAN. Реализация изолированных сетей может содержать, а может не включать в себя дополнительные службы, подобные DHCP, NAT и маршрутизации. |
Многохостовый FlatDHCP с высокой доступностью (HA) |
Сетевой отказ изолируется для виртуальных машин, работающих на пострадавшем гипервизоре. DHCP- трафик может быть ограничен в пределах одного хоста. Сетевой трафик распределяется на вычислительные узлы. |
Более сложная настройка. Вычислительные узлы обычно нуждаются в IP адресах, доступных из внешних сетей. Для работы с миграцией в реальном масштабе времени при работе с сетью требуется тщательная настройка опций. |
Настройка neutron с множеством DHCP и агентами 3 уровня. Сетевые узлы не имеют возможности обрабатывать отказы друг друга, следовательно сетевые службы, например,DHCP, выполняет контроллер. Вычислительные узлы выполняют плагин ML2 с поддержкой для агентов, подобных Open vSwitch или Linux Bridge. |
И службы nova-network, и службы neutron предоставляют
аналогичные возможности, такие как VLAN между виртуальными машинами. Вы также можете предоставить
множественные NICs для виртуальных машин с любыми службами. Далее идет
дополнительное обсуждение.
Конфигурация VLAN, в зависимости от желания, может быть простой или сложной. Использование VLAN, имеет то преимущество, что обеспечивает каждому проекту свою собственную подсеть и отделяет широковещательные сообщения от других проектов. Для эффективного использования сети VLAN со стороны OpenStack, необходимо выделить диапазон VLAN (один для каждого проекта) и сосредоточить все порты вычислительных узлов в коммутаторе в единый магистральный порт (trunk port).
Например, если в соответствии с вашими оценками данное облако должно поддерживать максимально 100 проектов, найдите не используемый в настоящее время инфраструктурой свободный диапазон VLAN (например, VLAN 200 - 299). Вы должны настроить OpenStack на работу с этим диапазоном, а также настроить порты коммутатора на допуск трафика VLAN для этого диапазона.
OpenStack Networking with neutron and
OpenStack Compute with nova-network have the ability to assign
multiple NICs to instances. For nova-network this can be done
on a per-request basis, with each additional NIC using up an
entire subnet or VLAN, reducing the total number of supported
projects.
Служба nova-network имеет возможность
работать в режиме с многими или одним хостом. Режим с многими хостами, это
когда каждый вычислительный узел выполняет копию nova-network и
экземпляр на вычислительном узле использует вычислительный узел в качестве шлюза в
интернет. Вычислительные узлы также размещают плавающие IP и
группы безопасности для экземпляров на данном узле. Режим с одним хостом
это когда, например, существует центральный сервер для контроллера облака,
выполняющий службу nova-network. Все
вычислительные узлы переправляют обмен от экземпляров к контроллеру облака.
Контроллер облака затем переправляет обмен в интернет. Контроллер облака
размещает плавающие IP и группы безопасности для всех экземпляров на всех
вычислительных узлах в облаке.
У каждого режима существуют свои преимущества. Лучай с одним узлом оборотной стороной имеет единую точку отказа. Если контроллер выходит из строя, экземпляры не могут осуществлять сетевой обмен. Это не верно для случая с несколькими хостами, однако в этом варианте требуется, чтобы каждый вычислительный узел имел общедоступный IP адрес для взаимодействия с интернетом. Если у вас нет возможности получить значительный блок общедоступных IP адресов, режим с многими хостами не может рассматриваться как вариант.
OpenStack, как и любое сетевое приложение, имеет ряд необходимых к применению стандартных факторов например, таких как DNS и NTP.
Синхронизация времени является важнейшим элементом для обеспечения бесперебойной работы компонентов OpenStack. Чтобы избежать ошибок при планировании необходимо правильное время, например при репликации объектов в хранилище объектов, а также согласованных меток времени для отладки.
Все серверы, выполняющие компоненты OpenStack должны быть в состоянии обеспечить доступ к соответствующему серверу NTP. Вы можете принять решение о настройке локального сервера, или использовать общественные пулы, доступные из Проекта сетевого протокола службы времени.
OpenStack в настоящее время не предоставляет услуги DNS, помимо демона dnsmasq,
который расположен на хостах nova-network. Вы можете
рассмотреть вопрос о предоставлении динамической службы DNS для обеспечения
возможности экземплярам обновлять запись DNS новыми IP-адресами. Вы также можете рассмотреть
возможность создания общего прямого и обратного отображения DNS для IP-адресов экземпляра,
например vm-203-0-113-123.example.com.
Вооружившись своим планом IP- адресов и их значениями, а также знаниями о топологиях и службах, которые вы можете использовать, вы готовы к подготовке сети для своей установки. Не забудьте также проверить Руководство по безопасности OpenStack на предмет советов по безопасности вашей сети. Мы желаем вам хорошего взаимодействия с вашей сетевой командой!