Компания
450,29
рейтинг
24 мая 2012 в 12:32

Разное → Сон внутри сна: смешиваем виртуальные и реальные сети в «облаке»

Представьте себе, что вы владелец банка, парохода и газеты, и у вас появилось одно «облако», которое нужно дать всем трём компаниям. Конечно же, оно предполагает виртуализацию серверов, плюс потребуется виртуализация сети как таковой.

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

Вторая задача — представьте, что у вас есть некий узел, который не может быть виртуализован, например, специальное хранилище данных или ещё что-то, что не переносится в «облако» без больших потерь. Хорошо было бы держать эту устройство так, чтобы она была видна из того же сегмента, что и виртуальные машины.

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

Начнём с уровня развёртывания виртуальной сети.


Есть разные технологии, которые позволяют это делать, все они имеют те или иные ограничения. Мы в своей практике остановились на Openflow: это один из механизмов реализации SDN (Software Defined Networking), когда сеть настраивается на уровне софта, а оборудование подстраивается под эту конфигурацию (чтобы не приходилось бегать и выставлять параметры руками). Вообще протокол Openflow — тема для отдельного топика. Сейчас важно отметить только то, что у нас используется реализация, разработанная компанией Nicira, созданная специально для виртуализации сети, совмещенной с виртуализацией серверов.

Особенности этой реализации в том, что виртуализация сети начинается сразу на гипервизоре, на том месте, где запущены контрольные машины. Используется подход Overlay networking, когда «облаку» совершенно не важна топология физической сети. Главное – чтобы там работал TCP, поверх которого и строятся логические сети. Есть TCP – можно применять любые решения в плане виртуализации сети как для машин в одной стойке, так и разнесённых в разные регионы. Стандарт Openflow хорошо известен крупным вендорам, а железо делают NEC, Extreme Networks, HP. К примеру, Google, Yahoo используют эти же технологии в своей работе.



Зачем нам программный коммутатор, позволяющий настраивать такие сети? Дело в том, что изначально у нас были разные варианты: можно было использовать VLAN (802.1q), но с ними была проблема: каждый используемый vlan надо прописывать на коммутаторах, плюс само количество VLAN’ов было ограничено на уровне железа. Поэтому мы не могли запустить большое количество коммутаторов. Пока решалась эта проблема, коллеги подсказали программный коммутатор для Linux, использующий Openflow. Мы связались с компанией Nicira, и в результате стали с ними работать в построении своего «облака».

Итог – мы смогли позволить пользователям строить сети любой сложности. То есть заказчик, встающий в наше «облако», получает не только виртуальные машины, но и определенную свободу действий, не ограниченную странными правилами. Это очень удобно для ряда компаний, которые строят ИТ-инфраструктуру далеко не с нуля.

Вот несколько примеров возможностей виртуализации сети:


  • Самый простой пример: в прошлом году мы проводили Олимпиаду для студентов. Работало две виртуальных машины, каждая в своей сети. Третья смотрела на первые две, то есть была маршрутизатором между сетями. Студенты выполняли задания для системных администраторов прямо в «облаке» так, как если бы они работали с реальными физическими сетями в разных городах.
  • Прибавляя машины и коммутаторы как в конструкторе, мы можем строить более сложные сети. Например, одно из интересных достижений – сеть, в которой работает только IPV6 (IPV4 там нет вообще). Стоит одна машина, которая смотрит в интернет, она dual stack, дальше машины уже не имеют IPV4 адресов, а в интернет IPV4’ой они могут ходить через маршрутизатор. Просто интересный опыт.
  • Практическое применение технологии очень логичное: в каждой сети мы предоставляем пользователю выделенный L2-сегмент, где он может гонять любой трафик произвольно, даже, например, IPX. Изоляция полная: перехватить трафик между сетями просто нереально. Затем мы позволяем подключать в сети «облака» физические сервера, например, такие, которые по ряду причин не могут быть виртуализованы. При помощи специального ПО физический сегмент сети расширяется в «облако», и виртуальные машины оказываются в одном сегменте с железными – это очень удобно при переносе инфраструктуры крупной компании в «облако».
  • Не так давно мы запустили такую штуку, как виртуальные частные «облака». Это аналог амазоновского VPC, только более гибкое. Пользователь запускает виртуальные машины в управляемой сети, там мы поднимаем наш DHCP-сервер, раздаем машинам адреса, выводим в Интернет через наш шлюз и так далее. Адресация сети в таких случаях определяется «облаком» и не всегда устраивает пользователя, поэтому он может создать виртуальное частное «облако», в нем создать себе сеть с произвольной адресацией, и запускать там свои машины. Плюс он может к этому «облаку» установить защищённое соединение от офиса и работать со своими виртуальными машинами. Более того, два разных пользователя могут создать себе сети с одинаковой адресацией, и они никак не будут между собой пересекаться. Это дает виртуализация сети Nicira + хитрые маршрутизаторы + изоляция сетевых стеков и другие подобные решения. И всем этим пользователи могут управлять сами без вмешательства администратора ЦОД.

  • Из последнего: совсем недавно мы начали использовать функционал еще одной разработки Nicira — High Availability кластера для подключения внешней сети в «облако». То есть от пользователя приходит 2 шнурка, мы их втыкаем в «облако». Если вдруг падает одна из линий подключения (например, клиентский коммутатор), то всё продолжает работать через второй. Это протокол 802.1ag: два узла осуществляют соединение виртуальной и физической сети, но работают в режиме active-passive, когда один узел работает, а второй отдыхает. Когда первый узел падает, второй (и очень быстро, так что даже пакеты не теряются) начинает пропускать трафик через себя.
Автор: @unkinddragon
КРОК
рейтинг 450,29

Комментарии (6)

  • –4
    Вспомнилось: lolpics.se/pics/5328.jpg
  • 0
    Используется подход Overlay networking, когда «облаку» совершенно не важна топология физической сети. Главное – чтобы там работал TCP

    А вот это уже реально здорово.
    Какую из техник туннелирования задействуете? Насколько я помню, там полно вариантов — от mac-in-mac до GRE или VXLAN.
      • 0
        Насколько я понял из tools.ietf.org/html/draft-davie-stt-01, STT работает поверх IP, а не TCP, и у него свой (отдаленно похожий на TCP) заголовок. Так прохождение через файрволы и тем более NATилки несколько сомнительно :) Ну это я так, придираюсь…

        С другой стороны, при использовании подобного туннелирования нет смысла пропускать его трафик через файрволы и тем более NAT.

        И все-таки возможность фактически свести к нулю L2 сегменты на физической сети ЦОДа не может не радовать :)
        • 0
          Через firewall этот STT проходит как обычный TCP, NAT внутри сети облака мы не используем. L2 мы не «сводим к нулю», нас просто не интересует подробная топология.

          Вот выступление Martin Casado на ONS 2012 — www.youtube.com/watch?v=MfUYdDJpEiU и opennetsummit.org/talks/ONS2012/casado-tue-overlays.pdf
          • 0
            По-моему, топик с детальным описанием работы сети на базе решений Nicira был бы весьма в тему… А то тут какой-то маркетинг сплошной…

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

Самое читаемое Разное

Интересные публикации