[Эта статья была первоначально написана Ноа Куперберг.]
OpenStack Networking
Neutron, проект Openstack Networking (ранее называвшийся Quantum) — это проект, направленный на обеспечение программного стека, определяемого сетью. Другими словами, он реализует сетевое обеспечение и управление в облаках OpenStack. Как обсуждалось в предыдущих статьях , Neutron предоставляет функциональные возможности настройки сети, которые ранее не были доступны пользователям. До появления Neutron виртуальные машины, конечно, всегда были как-то подключены к сети (в противном случае они не были бы доступны для клиента, создающего их или для других виртуальных машин), а сеть раньше настраивалась с помощью nova-network, ранее и более базовый сервис, который изначально был интегрирован в Nova Compute.
Нова Сеть
Участие службы nova-network в процессе подготовки виртуальных машин может удивить многих пользователей. Это связано с тем, что когда-то, до появления Neutron, работа с сетями была достаточно эффективной даже для пользователей, использующих Nova API. С точки зрения пользователя не было необходимости или возможности беспокоиться о настройке сети. За кулисами Nova Compute использовала сервис nova-network для автоматического подключения виртуальных машин к существующей сети, определенной администратором Openstack.
Даже сегодня пользователи Openstack могут продолжать использовать базовые сервисы, предоставляемые nova-network, если, например, у них есть существующее облако или им не требуется поддержка сложных сетевых топологий. Поддержка двух разных сервисов сетевого обеспечения не была первоначальным планом Openstack, и ожидалось, что сервис nova-network будет объявлен устаревшим, но в его нынешнем виде оба варианта все еще поддерживаются, и в предстоящем выпуске Icehouse также не рекомендуется использовать nova-network. Итак … давайте посмотрим, что он может предложить.
Топологии
Сеть Nova поддерживает три типа сетевых топологий (также называемых «типами сетевого менеджера») — Flat, Flat DHCP или VLAN. Выбор используемой топологии находится в руках администратора облака Openstack.
Плоский и плоский DHCP
В этом случае все виртуальные машины размещаются в одной сети с использованием одной подсети и моста, созданных ранее администратором. По сути, это означает, что все виртуальные машины совместно используют одну и ту же сеть, следовательно, визуальное выражение — Flat. Типы сети Flat и Flat DHCP очень похожи, за исключением того, что распределение IP-адресов виртуальным машинам осуществляется через DHCP в так называемой сети Flat DHCP. В отношении сетей — обе описывают одну и ту же топологию. Нет разделения сети между виртуальными машинами разных арендаторов, что означает, что их виртуальные машины могут быть связаны между собой, если они не ограничены другими средствами (такими как группы безопасности, которые будут подробно описаны в моем следующем посте).
Рисунок 1: Одна плоская сеть
Другим вариантом является использование нескольких плоских сетей (показано ниже), где виртуальные машины подключены к отдельным сетям через несколько интерфейсов («множественные»). Это может создать видимость отдельной сети и подсети на каждого арендатора, но факт остается фактом, что все арендаторы могут по-прежнему иметь доступ ко всем сетям, поэтому, хотя это может быть полезно для целей высокой доступности, лучшего распределения пропускной способности или разделения трафика, оно все же остается не дает много с точки зрения разделения арендаторов.
Рисунок 2: Несколько плоских сетей: все сети по-прежнему используются совместно
VLAN
Сети VLAN предлагают решение для полностью разделяемой и незащищенной структуры, описанной выше, обеспечивая хорошее средство разделения. Он основан на использовании физического коммутатора, который поддерживает тегирование VLAN, чтобы предоставить каждому арендатору отдельную виртуальную сеть, используя выделенную подсеть, с отдельным диапазоном IP-адресов и мостом для каждого арендатора. Это эффективно создает частные сети, доступные только разрешенному арендатору, через VPN. Такое разделение сред арендаторов делает VLAN разумным выбором для многопользовательской среды, и это действительно режим по умолчанию, используемый Nova-net.
Рисунок 3: Мультитенантность
Также возможно создать сочетание плоских и частных сетей, где виртуальная машина может получить доступ к общей сети в дополнение к частной сети арендатора. Это в основном позволяет пользователю создавать простую многоуровневую топологию, разделяющую различные части приложения в соответствии с их ограничениями безопасности.
Так что это основные топологии сети Nova. С точки зрения администратора, существует ограниченный выбор возможных типов сетей, и управление сетью не может использовать сторонние решения. Как я уже упоминал ранее, с точки зрения пользователя, сеть Nova является бесшовной, и, следовательно, позволяет легко управлять виртуальными машинами без проблем с сетью. Это просто потому, что все сетевые настройки предопределены сетевым администратором, в лучшую или в худшую сторону.
нейтрон
С этим новым проектом сеть становится очень настраиваемой. Изменение пользовательского опыта (UX) является существенным, поскольку пользователи теперь могут настраивать даже сложные топологии с помощью таких абстракций, как маршрутизаторы, сети, подсети и порты. Все это обеспечивает огромное разнообразие сетевых конфигураций, настраиваемых для каждого клиента и, самое главное, для клиента.
Это имеет существенное значение с точки зрения пользователя. Теперь у каждого арендатора есть своя (настоящая) игровая площадка, на которой он полностью контролирует управление сетью. Это новый уровень управления, который не был доступен ранее, и состоит из различных новых объектов и отношений. Это требует, чтобы пользователь получил хотя бы базовые знания о сетевых компонентах, чтобы создать рабочую среду.
Проектирование сложных структур — дело непростое, и Openstack принял вызов и интегрировал новые сетевые опции Neutron в Horizon, панель инструментов Openstack. Это делает управление сетью наглядным и довольно простым, если вы все делаете в правильном порядке…. (есть небольшая кривая обучения). Со стороны администратора Neutron также поддерживается новыми параметрами настройки, такими как интеграция сторонних сетевых служб. Но давайте останемся с пользователем.
Рисунок 4: Маршрутизаторы для арендаторов с частными сетями
Теперь пользователи могут создавать подробные, специфические сетевые архитектуры, даже позволяя копировать архитектуру своего центра обработки данных до облачных вычислений. Каждый арендатор может создать один или несколько маршрутизаторов (до ограничения квоты учетной записи), а также создать частные сети арендаторов и подсети, которые подключаются к этим маршрутизаторам. В конечном итоге маршрутизаторы-арендаторы обычно подключаются к внешней сети Openstack, через которую виртуальные машины имеют доступ к «миру» (виртуальные машины никогда не создаются непосредственно во внешней сети).
Эта конфигурация позволяет развертывать многоуровневые приложения для каждого клиента, где каждый уровень находится в отдельной сети за маршрутизатором клиента. С точки зрения безопасности маршрутизатор арендатора обеспечивает хорошее разделение на уровне сети. Кроме того, он позволяет перекрывать диапазоны сетевых подсетей разных арендаторов.
Это самая сложная и четко определенная топология. Он обеспечивает высочайшую степень безопасности благодаря включению разделения сети (но это никоим образом не заменяет настройку групп безопасности на виртуальных машинах).
Цена
Конечно, за эту свободу выбора приходится платить, и это сложность. Создание виртуальных машин и управление ими теперь заставляют пользователя также управлять сетью. Во-первых, сначала создайте хотя бы одну сеть для виртуальных машин-арендаторов, затем создайте маршрутизатор и подключите его к внешней сети облака. Затем определите подсеть с диапазоном IP-адресов для внутренней сети арендатора, подключите ее к маршрутизатору, настройте столько сетей, сколько необходимо, и в конечном итоге … создайте виртуальную машину в выбранной сети.
Управление сетями может стать еще более сложной задачей, если настройка сложной среды с несколькими сетями и предоставление виртуальных машин в этой инфраструктуре могут привести к путанице. Обработка сбоев ВМ, процедур отработки отказа или масштабирования работающей системы — это очень сложно и подвержено ошибкам.
Было добавлено новое измерение, и именно здесь игра меняется, и концепция сетевой автоматизации становится реальной необходимостью.
Введите Cloudify
Cloudify автоматизирует создание сетей, маршрутизаторов, подсетей и, конечно, вычислительных экземпляров, на которых развертываются приложения. По умолчанию Cloudify создает маршрутизатор для каждого арендатора, подключает его к внешней сети и создает сеть для каждого уровня, т.е. службы, приложения.
Как упоминалось ранее — если не автоматизировать, настройка сложных сетевых сред может занять много времени и потенциально рискованно. После первоначальной настройки системы крайне важно выполнить некоторые рутинные проверки системы и ответить соответствующим образом. Хорошее определение свойств вычислений и топологии сети позволяет Cloudify отслеживать, выполнять автоматическое масштабирование по мере необходимости и выполнять аварийное переключение с учетом сети для обеспечения высокой доступности приложений. Ниже приведен пример общей конфигурации сети в Cloudify.
cloudNetwork {
// Details of the management network, which is shared among all instances of the Cloudify Cluster.
management {
networkConfiguration {
name "Cloudify-Management-Network"
subnets ([
subnet {
name "Cloudify-Management-Subnet"
range "177.86.0.0/24"
options ([ "gateway" : "177.86.0.111" ])
}
])
custom ([ "associateFloatingIpOnBootstrap" : "true" ])
}
}
...
}
Определенная сеть будет создана автоматически и впоследствии может использоваться приложениями, которые к ней относятся. Дополнительные параметры, такие как использование существующих маршрутизаторов или сетей, также могут быть установлены в конфигурации сети приложения, как показано здесь:
// Optional. Set the name to search to find openstack compute endpoint. "computeServiceName" : "nova", // Optional. Set the name to search to find openstack networking endpoint. "networkServiceName" : "neutron", // Optional. Set the network api version . "networkApiVersion" : "v2.0", // Optional. Specify an existing external router name to use. "externalRouterName" : "MyNetwork", // Optional. Specify an external network name to use. "externalNetworkName": "MyTenantPresetNetwork"
В моем следующем посте я расскажу о группах безопасности, почему они так важны и как их использовать с Cloudify для защиты ваших виртуальных машин.