Глава 1. Подготовка сети для OpenStack
Содержание
Как большие, так и малые предприятия запускают свои облака используя программное обеспечение OpenStack. В то время как сами облака могут различаться по сложности одна вещь является общей: они стали возможными благодаря масштабируемости и гибкости вычислительных и сетевых служб OpenStack.
Современные облачные вычислительных платформы, таких как OpenStack, полагаются на сетевые методы, называемые определяемой программным обеспечением сетевой средой, или SDN (software-defied networking). Традиционное администрирование сети в основном полагается на то, что администратор вручную настраивает и обслуживает физическое оборудование сетевой среды и подключения. С другой стороны, SDN позволяет сетевым администраторам управлять сетевыми службами абстрактно и автоматизированно. Программно определяемы сетевые среды и целиком программно определяемы центр обработки данных часто рассматриваются в качестве необходимой основы для масштабируемых и эффективных облачных вычислений.
В этой главе вы познакомитесь с различными компонентами и функциями сетевой среды OpenStack с кодовым названием Neutron, а также различные методы при помощи которых Neutron может быть развернута и настроена как с точки зрения программного обеспечения, так и со стороны оборудования. Псевдоним Neutron будет использоваться на протяжении всей книги будет часто использоваться вместо официального названия.
OpenStack Networking является автономной службой, которая может быть установлена независимо от других служб в облаке. Другие службы OpenStack, подпадающе под эту категорию включают вычислительную службу (Compute - Nova), службу образов (Image - Glance), службу идентификации (Identity - Keystone), службу блочного хранилища (Block Storage - Cinder) и инструментальную панель (Dashboard - Horizon). Сетевые службы OpenStack могут быть разделены между несколькими узлами для обеспечения устойчивости и избыточности, или могут быть настроены для работы на одном узле.
Сетевая среда OpenStack использует службу под названием neutron-server для выделения программируемого интерфейса, или API, для пользователей и передачи запросов в настроенные сетевые подключаемые программы (plugin) для дополнительной обработки. Пользователи имеют возможность определять сетевые подключения в облаке, а также операторы облака могут использовать различные сетевые технологии для расширения и придания дополнительной мощности облаку.
Как и многие другие службы OpenStack, сетевая среда (Networking) требует доступа к базе данных для постоянного хранения сетевых настроек.
Сетевая среда OpenStack в Havana содержит многие технологии, которые характерны для центров обработки данных, в том числе коммутацию, маршрутизацию, балансировку нагрузки, межсетевое экранирование и виртуальные частные сети. Эти функции могут быть настроены для усиления программного обеспечения с открытым исходным кодом или коммерческого ПО, а также предоставить оператору облака все инструменты, необходимые для построения функционального и самодостаточного облака. Сетевая среда OpenStack также обеспечивает сторонним поставщикам каркас для построения облака и расширения его возможностей.
Виртуальные коммутаторы определяются как программные приложения, которые подключают виртуальные машины к виртуальным сетям на 2м уровне, или канальном уровне (data link) в модели OSI. Neutron поддерживает множество платформ виртуальной коммутации, включая встроенные мосты Linux и Open vSwitch. Open vSwitch, также называемый OVS, является виртуальным коммутатором с открытым исходным кодом, который поддерживает стандартные интерфейсы управления и протоколы, в том числе NetFlow, SPAN, RSPAN, LACP {Прим. пер.: 802.3ad}, 802.1Q, хотя многие из этих функций не являются открытыми для пользователя в API облака. В дополнение к разметке VLAN, пользователи могут создавать перекрывающиеся (overlay) сети в программном обеспечении с применением туннельных протоколов L2 в L3, подобных GRE или VXLAN. Open vSwitch может использоваться для облегчения связи между экземплярами и устройствами за пределами управления OpenStack, которые включают аппаратные коммутаторы, межсетевые экраны сетевой среды, устройства хранения, выделенные серверы и многое другое. Дополнительную информацию об использовании мостов Linux и Open vSwitch в качестве коммутаторов платформ для OpenStack можно найти в Главе 4. Построение инфраструктуры виртуальной коммутации.
Сетевая среда OpenStack обеспечивает маршрутизацию и возможности
NAT.
с помощью переадресации IP, iptables
и сетевых пространств имен.
Пространство имен сети аналогично
chroot для сетевого стека.
Внутри пространства имен сети вы можете найти сокеты, связанные порты и интерфейсы, которые были созданы в пространстве имен.
Каждое пространство имен сети имеет свою собственную таблицу маршрутизации и процесс iptables, которые обеспечивают фильтрацию и
преобразование адресов сети, также известные как NAT. Сетевые пространства имен сопоставимы с
VRF в Cisco,
экземплярами маршрутизации
в Juniper JunOS или доменами маршрутов в F5 BIG-IP. при применении пространств сетевых имен нет связи перекрывающихся подсетей
между сетями, созданных владельцами. Настройка маршрутизатора в Neutron позволяет экземплярам взаимодействовать и общаться с внешними сетями.
Дополнительные сведения о маршрутизации в рамках OpenStack можно найти в
Главе 6. Создание маршрутизатора в Neutron.
Впервые представленная в редакции OpenStack Grizzly, Load-Balancing-as-a-Service (балансировка-нагрузки-как-служба), также сокращенно именуемая как LBaaS, предоставляет пользователям возможность распределять запросы клиентов по множеству экземпляров серверов. Havana оснащена подключаемой программой (plugin), которая применяет HAProxy в качестве балансировщика нагрузки. Более подробную информацию по использованию балансировки нагрузки в пределах Нейтрон можно найти в Главе 7. Балансировка нагрузки обмена в Neutron.
В Havana существует два способа обеспечения безопасности для экземпляров или сетевых сред: группы безопасности (security group) и межсетевые экраны (fiewall). Группы безопасности первоначально были созданы в nova-network из OpenStack Compute. Это способ обеспечения безопасноти трафика к- или от- экземпляра посредством применения iptables на вычислительных узлах. С введением Firewall-as-a-Service (межсетевой-экран-как-служба), также сокращенно называемой FWaaS, работы по обеспечению безопасности выполняются на маршрутизаторе, а не на вычислительном узле. В редакции OpenStack Havana FWaaS это экспериментальное расширение без гарантии обратной совместимости в последующих версиях. Более подробная информация по обеспечению безопасности экземпляров может быть найдена в Главе 8. Безопасность экземпляров в сетевой среде.
Virtual private network виртуальная частная сеть (VPN) распространяет частную сеть в сети общего пользования подобные Интернет. VPN позволяет компьютеру отправлять и получать данные по сетям общего пользования, как будто они напрямую связаны с данной частной сетью. Neutron предоставляет набор API, позволяющий владельцам (tenant) создать VPN туннели к удаленным шлюзам на основе IPSec. In the Havana release of OpenStack, VPNaaS is an experimental extension with no guaranteed backwards compatibility in future releases; it will not be covered in this book. В редакции OpenStack Havana, VPNaaS является экспериментальным расширение, не гарантирующим обратную совместимость в будущих версиях; он не будет рассматриваться в этой книге.
При проектировании сети важно для начала определить цель данного облака. Существует ли задача построения высоко масштабируемой среды с несколькими уровнями резервирования сети? Или: существует ли цель обеспечения песочницы для разработчиков с небольшими заботами об устойчивости такой сети или вычислительной платформы? Вам нужна среда, которая использует всю мощь, которую OpenStack Networking должен предложить в плане маршрутизации, коммутации и сетевых приложений? Предусматривается ли в среде расширение существующей физической сети?
Сетевая среда OpenStack может обслуживать много ролей в пределах различных облаков, но в некоторых технологиях является лучше других. Цель облака самого по себе, заключается в том, что наряду с требованиями безопасности и доступности оборудования, оно будет играть большое значение в определении архитектуры сети и роли OpenStack в сетевой среде.
Портал OpenStack www.openstack.org.
предоставляет эталонные архитектуры для облаков на основе Neutron, которые содержат комбинацию из следующих узлов:- Узел контроллера
- Сетевой узел
- Вычислительный узел (узлы)
Перед установкой OpenStack, должна быть настроена физическая сетевая инфраструктура для поддержки сетевых потребностей работающего облака. На следующей диаграмме, автор выделил зону ответственности для администратора сети:
Физическая сетевая инфраструктура должна быть настроена для поддержки OpenStack Networking. На данной схеме область, отмеченная пунктиром в верхней части, находится в ответственности администратора сети. Она может включать в себя необходимость настройки физических коммутаторов, межсетевых экранов или маршрутизаторов, а также интерфейсы на самих серверах.
В следующих нескольких главах автор определил сетевые среды и VLAN, которые будут использоваться на протяжении всей этой книги чтобы продемонстрировать различные компоненты OpenStack Networking. Общая информация о настройке портов коммутатора, маршрутизаторов или межсетевых экранов также можно найти в последующих главах.
Эталонный проект OpenStack Networking определяет по крайней мере четыре различных типа сетевого обмена:
- Управление
- API
- Внешний
- Гостевой
Эти различные типы сетевого обмена не требуют специализированных интерфейсов и часто сворачиваются в один интерфейс. В зависимости от выбранной модели развертывания, проект облака может распространять сетевые службы на множество узлов. Часто требования безопасности предприятия, внедряющего облако, диктуют как строится это облако.
Сеть управления используется для внутренней связи между хостами для предоставления услуг, таких как службы обмена сообщениями и службы базы данных. Все хосты будут общаться друг с другом через эту сеть. Управляющая сеть может быть выполнена в виде отдельной сети на выделенном интерфейс или в сочетании с другой сетью, как это описано ниже.
Сеть API используется для открытия OpenStack API пользователям облака и службам в данном облаке. Адреса конечных точек служб, таких как Keystone, Neutron, Glance и Horizon, доставляются из сети API.
Общей практикой является настройка одного IP-адреса на выделенный интерфейс, который будет служить в качестве адреса обработчиков для различных служб, а также адрес управления для самого хоста. Схема такой настройки предоставляется далее в этой главе.
Внешняя сеть предоставляет маршрутизаторам Neutron доступ к сети. После того, как маршрутизатор был настроен, эта сеть становится источником однородных IP-адресов для экземпляров и балансировщика нагрузки VIP. IP-адреса из этой сети должны быть доступны любому клиенту в Интернете.
Гостевая сеть призвана обеспечить обмен экземпляров. Варианты гостевых сетей включают в себя локальные сети ограниченные определенными узлами, однородной или выделенной в VLAN сетью, или с применением инкапсуляции GRE или VXLAN становится возможным использование виртуальных перекрывающихся сетей. Для получения более подробной информации о гостевых сетях, пожалуйста, обратитесь к Главе 5. Создание сетевой среды с применением Neutron.
Интерфейсы, используемые для внешних и гостевых сетей могут быть выделенными интерфейсами или интерфейсами, которые являются совместными с другими типами обмена. Каждый подход имеет свои преимущества и недостатки, и все они описываются более подробно, по мере нашего продвижения в данной главе.
Количество интерфейсов, необходимых для каждого хоста зависит от типа строимого облака, а также требований безопасности и производительности для данной организации.
Все, что необходимо для полностью функционального облака OpenStack, это один интерфейс на сервер, который в результате объединяет уровни управления и данных. Многие организации предпочитают развертавыть свое облако таким путем, в особенности, когда плотность портов стоит дорого или среда используется просто для тестирования. В промышленных облаках, однако, рекомендуются отдельные интерфейсы управления и данных.
Для хостов, испуользующих один интерфейс весь обмен к экземпляру или от него, а также внутреннее управление OpenStack, SSH а также трафик API проходят через один и тот же интерфейс. Такая настройка может в результате может привести к серьезной деградации, поскольку гости могут созать атака с целью нарушения нормального обслуживания пользователей (DOS-атаку) на свой хосты, потребляя всю доступную полосу пропускания. Данный тип настройки не рекомендуется для промышленного применения и может быть использован тольо для тестирования или проверки правильности концепции.
Следующая диаграмма демонстрирует использование одного физического интерфейса для всего обмена с применением подключаемой программы Open vSwitch. Физический интерфейс расположен в сети моста и обрабатывает внешний и гостевой обмен, а также трафик управления и API:
На данной диаграмме обмен служб OpenStack и управления проходят через тот же физический интерфейс, что и гостевой трафик.
Чтобы уменьшить влияние потребления полосы пропускания гостевой сетью на обмен управления и поддерживать надлежащий уровень безопасности, рекомендуется разделение обмена между несколькими физическими интерфейсами. По крайней мере должно использоваться два интерфейса: один обслуживает интерфейсы управления и API, а второй работает как внешний и гостевой интерфейс. Если необходимо, могут использоваться дополнительные интерфейсы для дальнейшего разделения трафика. Следующая диаграмма показывает использование двух физических интерфейсов применяющих подключаемую программу Open vSwitch:
На этойдиаграмме выделенный физический интерфейс обрабатывает весь обмен, направляющийся к интерфейсам или от них или других служб OpenStack Networking,таких как LBaaS и FWaaS, вто время как другой интерфейс обрабатывает трафик OpenStack API и управления.
Соединение NIC предлагает пользователям умножать доступную полосу пропускания путем агрегации связей. Два или более физических интерфейса могут быть объединены для создания единого виртуального интерфейса или соединения (bond), который далее может быть помещен в мост. Физическая инфраструктура коммутации, однако, должна быть способна поддерживать такой тип соединения. В дополнение к агрегации связей, соединение также рассматривается как возможность создавать избыточные связи активным/ пассивным образом. Обе связи одновременно подключаются кабелями к коммутатору или паре коммутаторов, однако только один является активным в любой определенный момент времени. Оба типа соединений могут быть созданы в рамках CentOS или Ubuntu при установке соответствующего модуля ядра. Вместо встроенных методов соединения, при желании может быть настроено соединение в Open vSwitch.
Как это делается и с другими службами OpenStack, операторы облака могут разделить службы OpenStack Networking на несколько узлов. Небольшие реализации могут использовать один узел для размещения всех служб, в том числе сетевой среды, среды вычислений, базы данных и обмена сообщениями, в то время как могут воспользоваться преимуществами от использования выделенного узла для обработки гостевого трафика, направляемого через программный маршрутизатор и разгружающий службы Neutron DHCP и метаданных. Следующие диаграммы отражают несколько моделей развертывания общего обслуживания.
В среде, состоящей из одного контроллера и одного или более вычислительных узлов, контроллер, скорее всего, обрабатывает все сетевые службы и другие службы OpenStack, в то время как вычислительные узлы строго обеспечивают вычислительные ресурсы.
Следующая диаграмма показывает контроллер узла, размещающий все службы управления OpenStack и сетевой среды, в которых не используется агент 3 уровня. Два физических интерфейса используются для обеспечения раздельных уровне управления и данных:
Эта диаграмма отражает использование одного контроллера и одного или более вычислительных узлов, в котором Neutron обеспечивает только соединения с экземплярами 2 уровня. Для обработки маршрутизации между сегментами сети необходим внешний маршрутизатор.
Следующая диаграмма демонстрирует контроллер узла, который размещает все службы управления и сетевой среды OpenStack, в том числе агента Neutron L3. Два физических интерфейсов используются для обеспечения раздельных уровней управления и данных:
Эта диаграмма отражает использование одного узла контроллера, а также одного или более вычислительных узлов в конфигурации сети, которые используют агент Neutron L3. Программный маршрутизатор, созданный Neutron расположенным на узле контроллера и обрабатывает маршрутизацию между подключенными сетями владельцев (tenant).
Сетевой узел является выделенным для обработки большинства или всех служб сетевой среды OpenStack, в том числе агента L3, DHCP агента, агента метаданных и многих других. Использование выделенного сетевого узла обеспечивает дополнительную безопасность и устойчивость, вто время как узел контроллера будет менее подвержен риску насыщения сетевой среды и ресурсов.
Следующий рисунок демонстрирует сетевой узел размещающий все сетевые службы OpenStack, включая агента Neutron L3. Neutron API, однако, установлен на узле контроллера. Два физических интерфейса используются для обеспечения разделения уровней управления и данных::
Эта диаграмма отражает использование выделенного узла сети в ее конфигурации, которая использует агента Neutron L3. Программные маршрутизаторы, созданные Neutron находятся на сетевом узле и обрабатывают маршрутизации между подключенными сетями владельцев. Служба API, neutron-server, остается на узле контроллера.
OpenStack Networking предлагает возможность использования различных найденных в центре обработки данных технологий виртуально и в виде программ. Если встроенных функций оказывается недостаточно, архитектура подключаемых программ OpenStack Networking допускает дополнительную функциональность, предоставляемую третьими сторонами, будь то коммерческая организация или сообщество с открытым исходным кодом. Требования безопасности строящегося облака масштаба предпрития, а также варианты его использования, в конечном счете, определяют физическое расположение и разделение услуг в узлах инфраструктуры.
В этой книге вы узнаете как построить функциональное облако OpenStack использующее передовую сетевую функциональноть, доступную в редакции Havana. В следующей главе вы будете проведены сквозь пакетную установку OpenStack в операционной системе CentOS. Обсуждаемые темы включают установку, настройку и верификацию базы данных, обмена сообщениями, а также служб OpenStack: идентификации (Identity), образов (Image), вычислений (Compute) и приборной панели (Dashboard). Описание установки и настройки служб OpenStack Networking может быть найдена в Главе 3. Установка Neutron.