Сегодня поговорим о том, какие внутри OpenStack есть варианты планирования виртуальных сетей, подсетей, внутренних IP-адресов виртуальных машин, способов трансляции их в реальные IP-адреса и обеспечения безопасности разделения сред между ВМ разных клиентов.
За работу с сетевой частью OpenStack отвечает библиотека Quantum, которая обеспечивает функцию «сеть как сервис» между сетевыми интерфейсами ВМ (vNIC) под управлением других сервисов OpenStack, фактически предоставляя API, позволяющее управлять всей сетевой частью облака. В зависимости от поставленных задач и спроектированной целевой конфигурации облака, к Quantum можно подключать плагины, обеспечивающие те или иные сетевые функции. Обязательно стоит внимательно рассмотреть такие плагины, как Open vSwith, Cisco UCS/Nexus, Linux Brige, NEC OpenFlow, Nicira Network Virtualization Platform (NVP) и некоторые другие. После чего станет понятно, как именно вы будете проектировать сеть своего Cloud’а. Более подробно о конфигурации Quantum можно прочитать, например, в Administration Guide по Quantum — написано хорошо и достаточно полно. Цель сегодняшнего поста в том, чтобы осветить возможности проектирования различных вариантов построения виртуальной сетевой инфраструктуры OpenStack’а и их основных отличий друг от друга.
Вариант 1. Общая сеть
Самый простой вариант – одна общая подсеть для размещения ВМ.
Каждая ВМ находится в собственном тенанте с IP-адресом из общей сети, которая может быть только одна. Понятно, что данные на всех интерфейсах ВМ доступны на всех других сетевых интерфейсах, подключенных в эту сеть. Tcpdump рулит. Это скорее тестовая среда, нежели реальный рабочий workaround.
Вариант 2. Множество общих сетей
Этот вариант почти не отличается от варианта 1, за исключением того, что тенанты могут видеть множество общих сетей и иметь возможность выбрать, к какой подключиться. В этом случае тоже о серьезной сетевой безопасности говорить не приходится, однако в прикладном случае единой тестовой среды, например, для команды разработчиков, Cloud может иметь свои «вкусности». Для публичного облака этот вариант, естественно, также не подходит.
Вариант 3. Смешанные общие и приватные сети
Этот вариант является дополнением к вышеприведенным вариантам с общими сетями, в котором тенанты опционально могут иметь доступ к приватным для каждого тенанта сетям. Данный вариант позволяет создавать многоуровневые топологии с использованием нескольких сетевых интерфейсов на каждой ВМ. В дополнение к этому можно построить модель сети, где одна из ВМ используется как шлюз и обеспечивает такие сервисы, как маршрутизацию, NAT, или балансировку сетевого траффика. Однако одновременную работу в нескольких общих сетях здесь мы уже так просто, как в предыдущем варианте, не получим. Тоже очень любопытный вариант для специфичной платформы среды разработки, как мне кажется. К реальности публичных облаков никакого отношения не имеет.
Вариант 4. Общий роутер с приватными сетями
Вот мы подошли к первой реально значимой сетевой архитектуре для публичного облака. Эта схема позволяет каждому тенанту быть подключенным к одной или более приватных сетей, которые маршрутизируются в интернет через роутер. Данная модель поддерживает назначение floating IPs, которые на стороне маршрутизатора транслируют публичный IP-адрес во внутренний адрес ВМ. Без Floating IPs ВМ могут подключаться к внешним для них сетям через роутер, выполняющий SNAT. Роутер обеспечивает L3 соединения между приватными сетями. Таким образом, разные тенанты могут видеть друг друга, если не применены дополнительные правила фильтрации траффика при помощи Security Group. Т.к. роутер в данной схеме один, тенанты не могут создавать повторяющиеся диапазоны сетей. Прошу обратить внимание на эту особенность. Иными словами, пользователь облака не может выбрать себе тот IP-адрес, который он захочет (он банально может быть уже занят другой ВМ). Большинство известных мне облаков построены именно на такой схеме. Она позволяет обеспечить требуемый уровень безопасности пользовательских данных на сетевых интерфейсах, объединять несколько ВМ в один vLan, как и в предыдущем варианте, можно сделать часть ВМ внутренними (без публичного IP-адреса), но в то же время не усложнять схему работы для облачного провайдера. Гуд. Пошли дальше.
Вариант 5. Приватные роутеры с приватными сетями
Наиболее продвинутый вариант реализации сетевой инфраструктуры, в котором каждый(!) тенант получает приватный роутер, с возможностью создания дополнительных роутеров для каждого тенанта через Quantum API. Тенант может создавать свои сети, с возможностью подключения к роутеру. Теперь самое главное: данная схема позволяет каждому тенанту использовать любые сети, т.к. доступ вовне обеспечивается или через SNAT или Floating IPs. Иными словами, в облаке может быть несколько ВМ с одинаковыми(!) внутренними IP-адресами. Это может пригодиться, например, при переходе с одного облака на другое – запаковал машины, слил образ, настроил требуемую инфраструктуру на другом облаке, назначил IP-адреса, которые у тебя были ранее, развернул образы и все полетело без дополнительных изменений. Тот, кто часто вынужден был переносить сервера из одной подсети в другую, наверняка оценят эту возможность. С другой стороны, как часто вам может потребоваться таскать свою инфраструктуру между разными облаками?
Фактически, других топологий сети в облаке на базе OpenStack нет. Если вы задались целью построить свое собственное облако, определите сперва его цели. Что это будет? Если публичное облако – тогда вам подходят варианты 4 и 5 на выбор. Если вам требуется облако для тестирования разных программных сред в процессе разработки ПО, сертифицированному по CMMI на уровне зрелости начиная с 3-го, я бы предложил подумать над вариантами номер 2 или 3, чтобы не заморачиваться со сложностями построения и реализации. Кстати, 2-й и 3-й варианты вполне могут подойти для частного корпоративного облака при не слишком сильных требованиях от Службы Информационной Безопасности компании. Словом, «думайте сами, решайте сами, иметь или не иметь».
А напоследок хотелось бы задать вам вопрос. Нам очень интересно ваше мнение. Скажите, пожалуйста, насколько, с Вашей точки зрения, принципиально востребована функциональная возможность, предоставляемая в варианте № 5? Понятно, что реализация варианта № 5 сложнее, чем варианта № 4, и более затратная по ресурсам. А с другой стороны, может быть это настолько интересно, что эти затраты окупятся сторицей? Большая просьба, оставьте в комментариях свое мнение по этому вопросу.
Дмитрий Митрофанов
Вячеслав Самарин
ссылка на оригинал статьи http://habrahabr.ru/company/iteco/blog/166729/
Добавить комментарий