Знакомство с OpenStack

компонент Networking (Neutron)

Джон Ротон
Опубликовано 19.05.2014

В статье описывается компонент OpenStack Networking (Neutron), который обеспечивает связь между другими компонентами OpenStack.

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

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

По указанной причине разработка OpenStack пошла по пути создания уровня абстрагирования под названием OpenStack Networking, поддерживающего обширный ассортимент плагинов, которые обеспечивают интеграцию с другими сетевыми сервисами. Этот уровень предоставляет арендаторам облачных ресурсов API-интерфейс, с помощью которого они могут конфигурировать гибкие политики и создавать изощренные сетевые топологии — например, для поддержки многоуровневых веб-приложений.

OpenStack Networking позволяет сторонним поставщикам создавать плагины для поддержки расширенных сетевых возможностей, таких как L2/L3-туннелирование и сквозная поддержка качества обслуживания (QoS). Эти поставщики также могут создавать различные сетевые сервисы (балансировщики нагрузки, виртуальные частные сети, брандмауэры и т. д.), включаемые в сети арендаторов OpenStack.

На определенном этапе развития платформы OpenStack ее сетевые компоненты входили в состав проекта OpenStack Compute (Nova). В релизе Folsom большая часть этих компонентов была выделена в отдельный проект. Этот новый проект первоначально имел название Quantum, однако впоследствии он получил название Neutron во избежание смешения с товарными знаками компании Quantum Corporation. Поэтому не удивляйтесь, когда увидите названия Nova, Quantum и Neutron применительно к проекту OpenStack Networking.

Модель

API-интерфейс компонента OpenStack Networking базируется на простой модели абстракций (виртуальные сети, подсети, порты) для описания сетевых ресурсов. Сеть представляет собой изолированный сегмент уровня 2 (L2), аналогичный виртуальной локальной сети (VLAN) в мире физических сетей. Точнее, это широковещательный домен, зарезервированный за арендатором, который создал его или в явном виде сконфигурировал его как совместно используемый. Эта сеть также является первичным объектом для API-интерфейса компонента Neutron. Другими словами, порты и подсети всегда назначаются определенной сети.

Подсеть — это совокупность IP-адресов (v4 или v6) и ассоциированных с ними конфигураций. IP-адреса из этого пула платформа OpenStack может назначать виртуальным машинам. Каждая подсеть специфицируется как CIDR-диапазон (Classless Inter-Domain Routing) IP-адресов и должен быть ассоциирована с какой-либо сетью. Помимо подсети, арендатор может при желании указать шлюз, список DNS-серверов (Domain Name System) и набор маршрутов хостов. Все экземпляры виртуальных машин в этой подсети автоматически унаследуют эту конфигурацию.

Порт — это точка подключения к виртуальному коммутатору. Экземпляр виртуальной машины способен подключить свой сетевой адаптер к виртуальной сети через этот порт. После создания порта он получает фиксированный IP-адрес от одной из указанных подсетей. Эта задача решается одним из двух способов: пользователь API-интерфейса запрашивает определенный адрес из пула или Neutron выделяет IP-адрес из числа доступных адресов. Кроме того, платформа OpenStack позволяет задавать MAC-адреса, которые должен использовать этот интерфейс. После высвобождения порта все выделенные ему IP-адреса также высвобождаются и возвращаются в пул адресов.

Плагины

Первоначальная реализация сети в OpenStack Compute исходила из базовой модели Linux®, согласно которой вся изоляция выполнялась посредством VLAN-сетей и IP-таблиц. В проекте OpenStack Networking появилась концепция плагина, который представляет собой внутреннюю реализацию API-интерфейса OpenStack Networking. Плагин может использовать разнообразные механизмы для реализации запросов к логическому API-интерфейсу.

Некоторые плагины OpenStack Networking могут использовать базовые Linux-механизмы (IP-таблицы и VLAN-сети). Обычно этих механизмов достаточно для небольших и простых сетей, однако арендаторы более крупного масштаба вполне могут иметь более изощренные потребности, включая многоуровневые веб-приложения и необходимость внутренней изоляции между несколькими частными сетями. Таким арендаторам может быть нужна собственная схема IP-адресации (адреса в которой могут перекрываться с адресами, используемыми другими арендаторами) — например, для поддержки миграции приложений в облако без изменения IP-адресов. В этих случаях могут потребоваться более продвинутые технологии, такие как L2/L3-туннелирование или OpenFlow.

Архитектура на основе плагинов предлагает администратору облачной среды более высокую степень гибкости при настройке возможностей сети. Сторонние поставщики способны предоставлять дополнительные API-возможности посредством API-расширений, которые со временем могут стать частью API-интерфейса OpenStack Networking.

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

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

• Open vSwitch
• Cisco UCS/Nexus
• Linux Bridge
• Nicira Network Virtualization Platform
• Ryu OpenFlow Controller
• NEC OpenFlow

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

Архитектура

neutron-server— это основной процесс сервера OpenStack Networking. Это написанный на Python демон, перенаправляющий запросы из API-интерфейса OpenStack Networking в сконфигурированный плагин. Кроме того, в состав OpenStack Networking входят три агента, которые взаимодействуют с основным процессом Neutron через очередь сообщений или через стандартный API-интерфейс OpenStack Networking.

• Агент neutron-dhcp-agent предоставляет DHCP-сервисы (Dynamic Host Configuration Protocol) всем сетям арендатора.
• Агент neutron-l3-agent поддерживает функциональность L3/NAT, чтобы обеспечить виртуальным машинам в сетях арендаторов доступ к внешней сети
• Необязательный определяемый плагином агент (neutron-*-agent) выполняет конфигурирование локального виртуального коммутатора на каждом гипервизоре.

Необходимо иметь представление о взаимодействии между OpenStack Networking и другими компонентами OpenStack. Как и в случае других проектов OpenStack, инструментальная панель OpenStack Dashboard (Horizon) предоставляет графический пользовательский интерфейс администраторам и представителям арендатора для обращения к соответствующей функциональности — в данном случае, к функциям для создания сетевых сервисов и управления ими. Эти сервисы также подчиняются компоненту OpenStack Identity (Keystone) по вопросам аутентификации и авторизации любого API-запроса.

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

Установка и настройка

Реальные инструкции по установке существенно зависят от дистрибутивов и от релиза OpenStack. В общем случае эти инструкции предоставляются в составе дистрибутива. Однако вне зависимости от дистрибутива/релиза вам придется выполнять одни и те же основные задачи, которые рассматриваются в этом разделе.

Системные требования

Платформа OpenStack ориентирована на 64-разрядную x86-архитектуру; другими словами, она рассчитана на применение массовых аппаратных средств, поэтому минимальные системные требования весьма скромны. Весь пакет проектов OpenStack способен исполняться на одной системе, имеющей 8 ГБ оперативной памяти. Тем не менее при необходимости выполнения какой-либо серьезной работы рекомендуется использовать выделенный вычислительный узел, имеющий не менее 8 ГБ оперативной памяти, два диска по 2 ТБ и два сетевых адаптера. Распространенным явлением является применение Controller-хоста для централизованного исполнения компонентов OpenStack Compute. В этом случае сервер OpenStack Networking может исполняться как на том же хосте, так и на отдельном сервере.

Установка

Инструкции по установке зависят от дистрибутива, в частности, от выбранной вами утилиты управления пакетами. Во многих случаях при установке необходимо объявить репозитарий. Так, например, в случае утилиты Zypper необходимо объявлять libzypp с параметром zypper ar:

# zypper ar -f http://download.opensuse.org/repositories/Cloud:/OpenStack:/Grizzly/SLE_11_SP3/Cloud:OpenStack:Grizzly.repo

В качестве иллюстрации я показал основные команды для следующих ОС: Ubuntu, Red Hat (Red Had Enterprise Linux, CentOS, Fedora) и openSUSE:

• Ubuntu: Установите сервер neutron-server и клиента для доступа к API:

  $sudo apt-get install neutron-server python-neutronclient

  Установите плагин:

  $sudo apt-get install neutron-plugin-<plugin-name>

  Пример.

  $sudo apt-get install neutron-plugin-openvswitch-agent

• Red Hat: Как и в случае Ubuntu, необходимо установить Neutron-сервер и плагин, например:

  $sudo yum install openstack-neutron
  $sudo yum install openstack-neutron-openvswitch

• openSUSE: Введите следующие команды:

  $sudo zypper install openstack-neutron
  $sudo zypper install openstack-neutron-openvswitch-agent

Конфигурация

Большинству плагинов требуется база данных. В пакет Fedora для OpenStack Networking включены скрипты для утилиты установки сервера, которые обеспечивают полную установку и конфигурирование базы данных:

$sudo neutron-server-setup --plugin openvswitch

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

$sudo apt-get install mysql-server python-mysqldb python-sqlalchemy

Если база данных уже была установлена для других сервисов OpenStack, вам необходимо лишь создать базу данных Neutron:

$mysql -u <user> -p <pass> -e "create database neutron"

Эту базу данных необходимо указать в конфигурационном файле плагина. Для этого найдите конфигурационный файл плагина в следующем местоположении: /etc/neutron/plugins/plugin-name (например, /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini), и настройте связывающую строку:

sql_connection = mysql://<user>:<password>@localhost/neutron?charset=utf8

Сценарии использования

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

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

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

1. Войдите в панель OpenStack Dashboard в качестве пользователя с ролью Member. В навигационной панели под заголовком Manage Compute сначала нажмите Networks, а затем нажмите Create Network.

   Рисунок 1. Окно Networks

   

   Кликните, чтобы увидеть увеличенное изображение

   
2. Введите имя сети, а также имя первой подсети.

   Рисунок 2. Создание сети

   

   Кликните, чтобы увидеть увеличенное изображение

   

   В данном случае подсеть— это пространство сетевых адресов (например, 10.2.0.0/16) и адрес шлюза по умолчанию.

   Рисунок 3. Создание подсети

   

   Кликните, чтобы увидеть увеличенное изображение

   
3. Вы также можете сконфигурировать DHCP и DNS.

   Рисунок 4. Детали подсети

   

   Кликните, чтобы увидеть увеличенное изображение

   
4. При желании можно создать маршрутизатор, для чего сначала нажмите Routers под Manage Network, а затем нажмите Create Router. Затем вы можете соединить интерфейсы маршрутизатора, чтобы задать маршруты протекания трафика.

   Рисунок 5. Данные маршрутизатора

   

   Кликните, чтобы увидеть увеличенное изображение

   
5. Присвоение IP-адреса порту происходит при запуске образа. Компонент Nova обращается к компоненту Neutron с целью создания порта в подсети. Каждый виртуальный экземпляр автоматически получает частный IP-адрес. При желании экземплярам можно присвоить публичные IP-адреса с помощью концепции т. н. плавающих IP-адресов, которая поддерживается на платформе OpenStack.

   Рисунок 6. Управление связыванием плавающих IP-адресов

   

   Кликните, чтобы увидеть увеличенное изображение

   
6. После того как проект запросит плавающий IP-адрес из пула, он будет владеть этим адресом и сможет беспрепятственно отсоединять его от одного экземпляра и присоединять к другому экземпляру.

   Рисунок 7. Доступ и безопасность

   

   Кликните, чтобы увидеть увеличенное изображение

   

Заключение

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

Этот подход в точности повторяет тот, который используется в большинстве проектов OpenStack, включая проекты Object Storage (Swift) и Block Storage (Cinder), которые рассматриваются в следующей статье этого цикла.

Ресурсы для скачивания

• этот контент в PDF

Похожие темы

• Оригинал статьи: Discover OpenStack: The Networking component Neutron.
• Другие статьи в этом цикле, посвященном OpenStack.
• Документация по OpenStack.
• Информация по OpenStack в Твиттере.
• Статья об открытой облачной архитектуре IBM.
• Опробуйте OpenStack самостоятельно.
• Для начала работы с продуктом IBM SmartCloud Application Services посмотрите видеодемонстрацию.
• Раздел developerWorks Labs: Экспериментируйте с новыми направлениями в разработке программного обеспечения.