Виртуализация сетей и сети для виртуализации. Проектирование

Данным постом, я начинаю серию посвященную следующим технологиям/продуктам/технологиям:

• Виртуализация сетей (Network Virtualisation); 
• SDN (software defined networking); 
• OpenFlow; 
• Инкапсуляция трафика (VXLAN, Stateless Transport Tunneling (STT)); 
• Nicira NVP; 
• Vmware NSX.

Поводом к написанию стал выход Vmware NSX. Однако попробовав писать о данном продукте, я понял, что либо пост получится исключительно маркетинговый, либо, если упоминать все связанные технологии, - "заклинание друида 80-го уровня" (достаточно сложный технический текст, постоянно отсылающий к англоязычным статьям). Отсюда родилась мысль, что двигаться нужно "от простого к сложному" - сначала осветить используемые технологии и стандарты, а уж потом браться за сам продукт.

Применение серверной виртуализации породило достаточно парадоксальный дуализм: логическая сложность системы выросла, а физическая - уменьшилась. С точки зрения внешнего наблюдателя (читай не специалиста) структура вычислительного комплекса в целом, и  физической сети в частности, стала проще. Более того, какой-нибудь Hi-End комплекс (например IBM zSeries, или топовый IBM POWER) вообще выглядит как три шкафа: сервер, СХД, ленточная библиотека. При это внутри них могут существовать тысячи виртуальных машин и сотни сетей.

Однако на сколько упростилось "снаружи", во столько же раз усложнилось "внутри". Если для физических серверов, аудит взаимодействия с ЛВС, состоял в отслеживании откуда и куда идет каждый патчкорд, то для виртуальной инфраструктуры (а особенно если применяются блейды + горячая миграция + технологии отказоустойчивости каналов) это далеко не факт.

Проектирование и эксплуатация виртуальной инфраструктуры резко повышают требования к дисциплинированности и аккуратности как проектировщика, так и администратора. Если в процессе поддержания актуальности документации на систему нет "орднунга", то смена администратора может принести множество сюрпризов. А отследить сетевую топологию "по шнурочкам", как ранее, вряд ли удастся. В итоге, перед достаточно небольшой компанией, могут встать проблемы, ранее характерные только для корпораций с множеством отделов, причем малой компании решать их не чем, да и не за что.

В моей практике был случай, когда у большой компании, большинство правил внутренних межсетевых экранов заканчивали разрешающим "any to any". Причина была достаточно проста: большая сеть, огромное количество приложений (точное количество которых не знал никто и приложения были "размазаны" между отделами, причем, как мы шутили: "Уже уволились, те кто помнил тех, кто разворачивал данные приложения"). В общем все это породило нездоровую ситуацию ситуацию  - все знают, что она есть, все боятся туда лазить (никто не хотел быть крайним), никто не знает что с этим делать.

Корректно разделить физические и виртуальные сети, при проектировании, возможно только одним способом – считать трафик виртуальных сетей еще одним приложением (например, таким же, как VoIP, iSCSI, DNS или любое другое «инфраструктурное приложение») транспортируемым физической сетью. При таком подходе виртуальные коммутаторы инкапсулируют L2 или L3 трафик при помощи протоколов UDP (VXLAN) или GRE (NVGRE/Open vSwitch).

Так как с точки зрения физической сети, обмен трафиком идет практически исключительно между IP -хостами (хостами виртуализации - серверами, на которых развернуты гипервизоры и виртуальные коммутаторы), то получаются два взаимозависимых сетевых контура:

·         контур физической сети, отвечающий за связь гипервизоров друг с другом и транспортирующий в основном инкапсулирующие протоколы (его часто называют физической сетью - physical network);

·         контур виртуальной сети, отвечающий за связь виртуальных машин друг с другом и транспортирующий все протоколы «общения» (его, а точнее каждую виртуальную сеть, часто называют наложенной сетью - overlay network).

Такая формализация очень сильно упрощает проектирование и, более того, позволяет проводить проектирование разных контуров разными специалистами. В противном случае пришлось бы решать задачу «взаимной рекурсии», причем силами крайне высококвалифицированных (соответственно редких и дорогих) специалистов.

Для контура физической сети, все это дало возможность использовать проверенные временем технологии проектирования крупномасштабных сетей. В свою очередь, для контура виртуальной сети, это сильно упростило модель сети (т. к. за многие сервисы отвечает физический контур, например маршрутизация и отказоустойчивость) и позволило сконцентрироваться именно на приложениях.

Хорошим примером является работа с STP (Spanning Tree Protocol). Известно, что при классическом подходе к проектированию большой, распределенной, отказоустойчивой и высокоскоростной ЛВС, как минимум одна глава технического проекта должна быть посвящена STP (принципы назначения RootBridge и резервного RootBridge, разнесение по VLAN, выбор диалекта STP), в противном случае, в сети будут, при нормальной работе - постоянно возникать мелкие глюки, а при возникновении незапланированных путей (местный «тру-админ» воткнул незапланированный патчкорд между коммутаторами) даже ступор ЛВС из-за широковещательного шторма. В гипервизорах же STP просто отсутствует, т. к. проблема петель и избыточного широковещательного трафика там решается другими способами.

Такой подход позволяет построить действительно масштабируемые сети уровня ЦОД.

Такой подход, кстати, не является чем-то эксклюзивным, например можно легко найти аналогии между вышеописанной ситуацией и VPN IPSec –сетью связывающей множество площадок, где так же, по сути, используются два сетевых контура.

Между площадками циркулирует исключительно IP Sec VPN-трафик, формирующий туннели, связывающий площадки. Отказоустойчивость и маршрутизация возлагается именно на данную часть сети. В свою очередь, внутри туннелей «бегает» трафик приложений площадок. Шлюз – устройство, отвечающее за связь сетевых контуров между собой. Так же обычно на шлюзе, точнее, на его «внутренней» стороне граничащей с  контуром сети площадки, реализуются функции безопасности (фильтрация) и QoS. Соответственно на «внешней» стороне граничащей с контуром VPN-сети реализуются инкапсуляция (+ шифрование), маршрутизация и отказоустойчивость.