ГЛАВА 6

Проектирование сети

Пользуйтесь переводом существенно переработанной и дополенной 2й редакции (12-дек-2014),
находящейся теперь и в режиме постоянно обновляемой документации
(последняя пока доступна только на англ.яз.).

OpenStack предоставляет богатое сетевое окружение, а данная глава подробно излагает требования и варианты для рассмотрения при проектировании вашего облака.

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

Например, вы должны планировать количество IP-адресов, которые вам потребуется как для гостевых экземпляров, так и для инфраструктуры управления. Кроме того, вам необходимо изучить и обсудить сетевые подключения облака через прокси-серверы и межсетевые экраны.

Управляющая сеть

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

Рассмотрите возможность создания других частных сетей для связи между внутренними компонентами OpenStack, такими как очереди сообщений (Message Queue) и OpenStack Compute. Для таких сценариев прекрасно подходят VLAN.

Опции адресации из адресного пространства интернет

Существуют два основных типа IP-адресов для гостевых виртуальных машин: фиксированные IP и плавающие IP. Фиксированные IP-адреса присваиваются экземплярам при загрузке, в то время как плавающие IP-адреса могут менять свои связи с экземплярами в результате действий пользователя. Оба типа IP-адресов могут быть либо общедоступными (public), либо частными, в зависимости от вашего варианта использования.

При потребности запуска OpenStack без плавающих IP-адресов, необходимы фиксированные 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 Compute, и Object Storage при доступных диапазонах частных адресов 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 предоставляет несколько приложений сетевого администрирования, каждое обладает своими сильными и слабыми сторонами. Выбор менеджера сети изменяеет топологию вашей сети, следовательно он должен быть тщательно продуманным.

тип	Преимущества	недостатки
Flat	Чрезвычайно простой. Отсутствует широковещательный DHCP.	Требует инъекции файлов в экземпляр Огранечен на ряд дистрибутивов Linux. Сложен в настройке и не рекомендуется.
FlatDHCP	Относительно прост в настройке. Стандартное подключение к сети. Работает со всеми операционными системами.	Требует свой собственный домен DHCP.
VlanManager	Каждому владельцу выделяется своя собственная VLAN.	Более сложен в настройке. Требуется свой широковещательный домен DHCP. Для создания магистрального порта (транкинга на один порт) требуется много VLAN. Стандартное ограничение на число VLAN. Коммутаторы должны поддерживать расстановку тегов 802.1q VLAN
FlatDHCP Multihost HA	Сетевой отказ изолируется на виртуальных машинах, работающих на пострадавшем гипервизоре. DHCP- трафик может быть ограничен в пределах одного хоста. Сетевой трафик распределяется на вычислительные узлы.	Более сложная настройка. По умолчанию для вычислительных узлов требуются общедоступные IP адреса. Для работы с миграцией в реальном масштабе времени при работе с сетью требуется тщательная настройка опций.

VLAN-ы

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

Например, если в соответствии с вашими оценками данное облако должно поддерживать максимально 100 проектов, найдите не используемый в настоящее время инфраструктурой свободный диапазон VLAN (например, VLAN 200 - 299). Вы должны настроить OpenStack на работу с этим диапазоном, а также настроить порты коммутатора на допуск трафика VLAN для этого диапазона.

Множественные NIC

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

Работа в сети с многими хостами и с одним хостом

Служба nova-network имеет возможность работы в режиме многими хостами или с одним хостом. При режиме с многими хостами каждый вычислительный узел работает с копией nova-network, а экземпляры на этом вычислительном узле используют вычислительный узел в качестве шлюза в интернет. Вычислительные узлы для экземпляров на этом узле также размещают плавающие IP-адреса и группы безопасности. При режиме с центральным сервером в качестве единого хоста, контроллер облака, например, запускает службу nova-network . Все вычислительные узлы передают трафик от экземпляров в контроллер облака. Затем контроллер облака передает трафик в сеть Интернет. Контроллер облака размещает плавающие IP-адреса и группы безопасности для всех экземпляров на всех вычислительных узлах в облаке.

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

Службы для функционирования сети

>OpenStack, как и любое сетевое приложение, имеет ряд необходимых к применению стандартных факторов например, таких как DNS и NTP.

NTP

Синхронизация времени является важнейшим элементом для обеспечения бесперебойной работы компонентов OpenStack. Чтобы избежать ошибок при планировании необходимо правильное время, например при репликации объектов в хранилище объектов, а также согласованных меток времени для отладки.

Все серверы, выполняющие компоненты OpenStack должны быть в состоянии обеспечить доступ к соответствующему серверу NTP. Вы можете принять решение о настройке локального сервера, или использовать общественные пулы, доступные с http://www.pool.ntp.org/

DNS

OpenStack в настоящее время не предоставляет услуги DNS, помимо демона dnsmasq, который расположен на хостах nova-network. Вы можете рассмотреть вопрос о предоставлении динамической службы DNS для предоставления возможности экземплярам обновлять запись DNS новыми IP-адресами. Вы также можете рассмотреть создание общего прямого и обратного отображения DNS для IP-адресов экземпляра, например vm-203-0-113-123.example.com.

Глава 5	Оглавление	Глава 7

Перевод: Copyright © 2014 . All rights reserved. Ссылки обязательны (Refs and links obligatory).		http://www.mdl.ru