I-Teco OpenStack Cloud: Проектирование сетевой части OpenStack

    Как выяснилось, большое количество наших с вами коллег не только интересуются OpenStack, но и имеют достаточный опыт по его сборке и настройке: к нам приходит большое количество самых разных вопросов – от борьбы с багами в разных библиотеках до концептуальных вопросов ИБ и планирования пользовательской среды. На часть вопросов мы отвечаем в частном порядке, а на те, которые интересуют многих, ответим здесь.

    Сегодня поговорим о том, какие внутри 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. Общая сеть

    Самый простой вариант – одна общая подсеть для размещения ВМ.

    image

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

    Вариант 2. Множество общих сетей


    image

    Этот вариант почти не отличается от варианта 1, за исключением того, что тенанты могут видеть множество общих сетей и иметь возможность выбрать, к какой подключиться. В этом случае тоже о серьезной сетевой безопасности говорить не приходится, однако в прикладном случае единой тестовой среды, например, для команды разработчиков, Cloud может иметь свои «вкусности». Для публичного облака этот вариант, естественно, также не подходит.

    Вариант 3. Смешанные общие и приватные сети


    image

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

    Вариант 4. Общий роутер с приватными сетями


    image

    Вот мы подошли к первой реально значимой сетевой архитектуре для публичного облака. Эта схема позволяет каждому тенанту быть подключенным к одной или более приватных сетей, которые маршрутизируются в интернет через роутер. Данная модель поддерживает назначение floating IPs, которые на стороне маршрутизатора транслируют публичный IP-адрес во внутренний адрес ВМ. Без Floating IPs ВМ могут подключаться к внешним для них сетям через роутер, выполняющий SNAT. Роутер обеспечивает L3 соединения между приватными сетями. Таким образом, разные тенанты могут видеть друг друга, если не применены дополнительные правила фильтрации траффика при помощи Security Group. Т.к. роутер в данной схеме один, тенанты не могут создавать повторяющиеся диапазоны сетей. Прошу обратить внимание на эту особенность. Иными словами, пользователь облака не может выбрать себе тот IP-адрес, который он захочет (он банально может быть уже занят другой ВМ). Большинство известных мне облаков построены именно на такой схеме. Она позволяет обеспечить требуемый уровень безопасности пользовательских данных на сетевых интерфейсах, объединять несколько ВМ в один vLan, как и в предыдущем варианте, можно сделать часть ВМ внутренними (без публичного IP-адреса), но в то же время не усложнять схему работы для облачного провайдера. Гуд. Пошли дальше.

    Вариант 5. Приватные роутеры с приватными сетями


    image

    Наиболее продвинутый вариант реализации сетевой инфраструктуры, в котором каждый(!) тенант получает приватный роутер, с возможностью создания дополнительных роутеров для каждого тенанта через Quantum API. Тенант может создавать свои сети, с возможностью подключения к роутеру. Теперь самое главное: данная схема позволяет каждому тенанту использовать любые сети, т.к. доступ вовне обеспечивается или через SNAT или Floating IPs. Иными словами, в облаке может быть несколько ВМ с одинаковыми(!) внутренними IP-адресами. Это может пригодиться, например, при переходе с одного облака на другое – запаковал машины, слил образ, настроил требуемую инфраструктуру на другом облаке, назначил IP-адреса, которые у тебя были ранее, развернул образы и все полетело без дополнительных изменений. Тот, кто часто вынужден был переносить сервера из одной подсети в другую, наверняка оценят эту возможность. С другой стороны, как часто вам может потребоваться таскать свою инфраструктуру между разными облаками?

    Фактически, других топологий сети в облаке на базе OpenStack нет. Если вы задались целью построить свое собственное облако, определите сперва его цели. Что это будет? Если публичное облако – тогда вам подходят варианты 4 и 5 на выбор. Если вам требуется облако для тестирования разных программных сред в процессе разработки ПО, сертифицированному по CMMI на уровне зрелости начиная с 3-го, я бы предложил подумать над вариантами номер 2 или 3, чтобы не заморачиваться со сложностями построения и реализации. Кстати, 2-й и 3-й варианты вполне могут подойти для частного корпоративного облака при не слишком сильных требованиях от Службы Информационной Безопасности компании. Словом, «думайте сами, решайте сами, иметь или не иметь».

    А напоследок хотелось бы задать вам вопрос. Нам очень интересно ваше мнение. Скажите, пожалуйста, насколько, с Вашей точки зрения, принципиально востребована функциональная возможность, предоставляемая в варианте № 5? Понятно, что реализация варианта № 5 сложнее, чем варианта № 4, и более затратная по ресурсам. А с другой стороны, может быть это настолько интересно, что эти затраты окупятся сторицей? Большая просьба, оставьте в комментариях свое мнение по этому вопросу.

    Дмитрий Митрофанов
    Вячеслав Самарин
    Ай-Теко
    Company
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 9

      0
      Работаю сисадмином в небольшой компании, обслуживаю небольшую ферму виртуальных серверов. В собственном облаке вариант №5 возможно избыточен. А вот если рассматривать возможность перевода серверов из собственной серверной на сторонний хостинг (как это сделал ROLF), то этот вариант может быть очень даже приемлемым. Особенно ценным будет возможность сохранения схемы назначения адресов в процессе переноса, т.к. позволит минимизировать простои.
        0
        А эта система не поддерживает множественные таблицы маршрутизации?
        Что вам мешает поднять на роутере провайдера в 4 схеме несколько VRF и пусть разные клиенты используют одинаковые адреса сколько им будет угодно? Фактически реализуется та же схема 5, но с меньшим количеством оборудования.
          0
          Физически оборудование используется одинаково — только 1 роутер.
          остальное — виртуальные машины — роутеры. не думаю, что у них есть функционал VRF.
          0
          Только схема 5 представляет собой публичное облако.

          Остальные 4 схемы — частные облака. Насколько я понимаю, вы продаете i-oblako — т.е. свое публичное облако — там реализована 5я схема?

          И есть еще вопрос по 4й схеме — почему вы решили, что " Большинство известных мне облаков построены именно на такой схеме." и не могли бы вы привести примеры?

            0
            Публичное облако отличается от частного только контингентом пользователей. Если это сотрудники одной компании — это частное облако. Если кто угодно — публичное. Определения здесь. Поэтому сетевая инфраструктура любого облака может быть построена по любому из 5 вариантов.
            Варианты 4 и 5 имеют защиту сетевого трафика от соседей, поэтому подходят для публичного облака в силу менталитета пользователей, которые заботятся о защите своего трафика. Публичное облако с сетью по 1,2 или 3 варианту не будут привлекательны на рынке, но так же будут публичными облаками.

            Далее о терминологии: i-oblako — это витрина SaaS сервисов. Там есть один IaaS сервисI-Teco OpenStack Cloud, который мы и обсуждаем. Т.е. i-oblako — это не публичное облако.

            Теперь о технике: I-Teco OpenStack Cloud это общее название. Там есть среда построеная на 4 варианте и среда, построенная на 5 варианте, но вариант реализации возможности выбора пользователем произвольной сети и IP адреса не реализован. Сейчас пользователю назначается внутренний адрес, который выбирается по умолчанию.

            Мой вопрос как раз и был в том, чтобы определить — а нужна ли админам, которые потом будут работать с этим облаком, возможность самому назначать внутренние IP адреса своей инфраструктуры, или ценность этой возможности факультативна.

            Примеры, о которых могу говорить — Гарант, Scalaxy, Rackspace и др. В них нет возможности задать требуемый пользователю IP адрес на ВМ. (ну или я о такой возможности не знаю) На Амазоне такая возможность есть в виде создания собственной частной сети.
            0
            Все приведенные схемы имеют проблемы при реализации в больших масштабах, 5 — наиболее простая для преодоления базового набора косяков, и при высокой сегментации машин клиента (в разных L3) сегментах, без использования туннелей она тоже работать перестанет.
              0
              Склонен с вами полностью согласиться в оценке проблем масштабирования.
              Мне самому импонирует 5-я схема ровно потому, что через несколько лет и сотнях тысяч пользователей у меня останется свобода маневра. Однако сейчас вопрос в другом — давать или не давать пользователю возможность самому назначать произвольные сети и IP адреса для своей инфраструктуры в облаке. Это дополнительная фича, но и дополнительные затраты.
              На ваш взгляд — такая доп. услуга была бы востребована?
              А если эта фича будет платной?
                0
                Что подразумевается под произвольными сетями? У пользователя должен быть общий для всех его машин L2 сегмент, даже в случае географического разделения, а сеть «облака» должна уметь эти объединения строить без лишнего оверхеда. Можно взять более простые случаи, когда на уровне стойки заканчивается масштабирование всех сегментов второго уровня и в соседнюю уже требуется роутить — строить такое на любом классическом IGP провально из-за объемов правил. Ну и естественно, это должно быть бесплатно.
              0
              Естественно, облако умеет строить пользователю L2 сегмент поверх своей реальной географически распределенной сети и разнесенных ресурсов.
              Пользователь в рамках своего L2, которая будет использоваться как внутренняя сеть, может настроить любую сеть: 192.168.0.0, 10.0.0.0, она принципиально может быть даже реальной сетью, на которой сервера стояли раньше. А на выходе будет натится в реальные IP.

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

              Only users with full accounts can post comments. Log in, please.