Виртуализация и компьютерная сеть

Строим гибкие сети для растущих компаний: сетевая виртуализация с SDN и NFV

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

В таких случаях виртуализация сетевых устройств, то есть запуск функций сети в виде виртуальных машин или контейнеров, привлекательна — на первый взгляд. Однако ряд экспертов считает, что сетевая виртуализация переоценена.

Мы решили рассмотреть разные точки зрения, а также сравнить возможности SDN и NFV в построении динамичной сетевой архитектуры.

Плюсы: гибкое управление, масштабируемость, оптимизация затрат

Выделяют две модели сетевой виртуализации — программно-определяемые сети (SDN) и виртуализацию сетевых функций (NFV).

SDN подразумевает разделение плоскости управления и плоскости данных. Для управления трафиком используют контроллеры на базе ПО или API-интерфейсы.

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

Мнения о работе с SDN и NFV сложились полярные. В пользу технологий сетевой виртуализации говорит тот факт, что их уже используют операторы дата-центров и корпорации для развертки высокопроизводительных приложений.

Организации со сложными распределенными сетями передачи задействуют SDN и NFV с целью модернизации телеком-инфраструктуры.

Еще с помощью программно-определяемых сетей и виртуальных сетевых функций компании упрощают конфигурацию и масштабирование сетей, которые становятся все более требовательными к качеству сервиса (QoS). По данным аналитиков Sandvine, в прошлом году «тяжёлый» контент видеосервисов и стриминговых площадок составил 65% от всего интернет-трафика, а SDN и NFV эффективно его приоритезирует.

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

Минусы: централизация, безопасность, порог входа

В индустрии можно встретить мнение, что сетевая виртуализация не оправдала ожиданий. IP-сети разрабатывали как устойчивое решение, способное функционировать даже при отказе отдельных узлов и линий связи. Но SDN и NFV, наоборот, централизуют управление, что противоречит данной парадигме. Если злоумышленнику удастся получить доступ к серверам с управляющим ПО, он может перехватить контроль и проводить атаки типа man-in-the-middle.

Есть и другая проблема — управление виртуальными сетями происходит с помощью кода и API. Но здесь, как и в любом другом программном обеспечении, могут возникать ошибки. Они приводят к появлению уязвимостей и незапланированному поведению инфраструктуры. Однако справедливости ради стоит заметить, что существуют способы повысить безопасность SDN-экосистемы. В первую очередь речь идет о многофакторной аутентификации и регулярных аудитах с целью поиска некорректно настроенных компонентов.

Хороший пример — наше решение для организации распределенной сетевой инфраструктуры Cloud SD-WAN, в котором есть физическое устройство с функциями безопасности. Фактически это маршрутизатор, который может заменить уже размещенные в филиалах аппаратные системы или работать с ними в тандеме. Он поддерживает функции сетевого шлюза, Site-to-Site VPN, DHCP-сервера, NAT и файрвола, а также различные протоколы маршрутизации для интеграции с физической сетью.

Облачный провайдер берет на себя все задачи построения инфраструктуры SD-WAN. Это — настройка политик безопасности, обеспечение инфраструктуры и её круглосуточный мониторинг, администрирование сети и защищенных распределенных ЦОД, выполнение SLA. В то же время специалисты облачного поставщика помогают выбрать оптимальное оборудование и дают рекомендации по модернизации сети, чтобы она соответствовала всем требованиям качества и надежности.

Если говорить о NFV, то технология была призвана упростить сетевую экосистему, но на практике это явление не стало всеобъемлющим. При этом сам по себе переход на виртуальные сети требует переосмысления инфраструктуры и парадигмы управления. Даже крупная компания или интернет-провайдер не может просто взять и реализовать стратегию по виртуализации сети. Миграция на SDN и NFV — это пошаговый процесс, но он не всегда приводит к желаемым результатам. По статистике экспертов компании Cloudify, проваливаются 70% таких инициатив.

Наконец, нельзя не отметить, что многие решения по виртуализации строятся на свободном ПО. Однако для работы с ними необходима экспертиза, в том числе для взаимодействия с протоколами вроде OpenFlow, NETCONF, OVSDB.

Несмотря на скепсис

Схема архитектуры AI-SDIN (AI-enabled Software-Defined Industrial Internet of Things Networks)

Сегмент виртуальных сетей развивается. Одним из ключевых драйверов называют системы ИИ, повышающие безопасность виртуальных и программно-определяемых сетей. Архитектуру такого решения в прошлом году предложила рабочая группа китайских и британских инженеров. Они обучили ML-модель и развернули её на SDN-контроллере. В такой конфигурации умная сеть идентифицирует вредоносные пакеты и приложения, а также на лету формирует адаптивные сетевые политики.

Общая архитектура SDN-интегрированной граничной вычислительной среды

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

Количество IoT-девайсов растет — по данным Statista, их число достигнет 30 млрд уже к 2030 году. В таких условиях обмен петабайтами информации между подключёнными системами, личными устройствами и элементами городской инфраструктуры может превратиться в нетривиальную задачу. Доставка данных в разумное время потребует высокой производительности и управляемости. Их как раз способны предоставить технологии SDN и NFV.

Что дальше

В качестве драйвера развития сетевой виртуализации в Deloitte также называют классические cloud-технологии. С помощью программно-определяемых сетей и виртуальных сетевых функций проще развернуть надежную облачную инфраструктуру по запросу.

Сегодня облачные провайдеры признают перспективность сетевой виртуализации. Количество рабочих групп в индустрии, развивающих SDN и NVF велико. Среди них можно выделить Industry Specification Group, которая прорабатывают фреймворки для работы с компонентами виртуальных сетей. Также существуют фонды Open Networking Foundation и European Telecommunications Standards Institute. Однако пройдет еще какое-то время, прежде чем технология полностью войдет в мейнстрим.

Что еще читать по сетевым технологиям:

Источник

Организация сетевого взаимодействия физических и виртуальных машин

В статье расскажу опыт построения сетевого взаимодействия между физическими компьютерами и виртуальными машины, созданными в среде VMWare Esxi 6.7. Организация маршрутизации между всеми устройствами осуществляется с помощью Mikrotik CHR.

Введение

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

Приведу первоначальную топологию.

• Коммутатор D-Link. К нему подключены физические машины и сервер с VMWare ESXI. Сам коммутатор подключен к вышестоящему оборудованию организации.
• Некоторый парк физических машин.
• Набор виртуальных машин.
• Одна виртуальная машины, на которой установлен Windows Server и AD.

Задача

Необходимо по 2 физические машины и 2 виртуальные машины объединить в одно адресное пространство. При этом нельзя затрагивать общую инфраструктуру организации. Каждый сформированный набор машин должен быть изолирован друг от друга, но должны быть обеспечены выходом в интернет и доступом к AD.

Реализация

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

На виртуальном switch VMWare получаем следующую структуру:

Для того, чтобы организовать маршрутизацию и разделение на подсети используем Mikrotik CHR. На сервере VMWare разнесем созданные VLAN между виртуальными машинами и Mikrotik. В итоге получаем следующим вид для каждого VLAN:

Новая топологию с Mikrotik CHR выглядит следующим образом:

На виртуальный маршрутизатор в итоге приходят следующие интерфейсы:

1. Интерфейс для доступа к внутренней сети организации
2. Интерфейс с реальным IP адресов
3. Интерфейс каждого созданного VLAN

Настройка Mikrotik CHR

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

/interface ethernet set [ find default-name=ether1 ] comment="VLAN ID 361 Uplink to Org" name=Class_VM set [ find default-name=ether2 ] comment="Interface Vlan 2025 Real_Outside" name=Real_Outside set [ find default-name=ether3 ] comment="Interface WSR_4001 for StudentWSR #1" name=WSR_4001 set [ find default-name=ether4 ] comment="Interface WSR_4002 for StudentWSR #2" name=WSR_4002 set [ find default-name=ether5 ] comment="Interface WSR_4003 for StudentWSR #3" name=WSR_4003 set [ find default-name=ether6 ] comment="Interface WSR_4004 for StudentWSR #4" name=WSR_4004 set [ find default-name=ether7 ] comment="Interface WSR_4005 for StudentWSR #5" name=WSR_4005 set [ find default-name=ether8 ] comment="Interface WSR_4006 for StudentWSR #6" name=WSR_4006 set [ find default-name=ether9 ] comment="Interface WSR_4007 for WinServerDC" name=WSR_4007 /interface list add comment="Interface List All Local Vlan" name=local_vm /interface list member add interface=WSR_4001 list=local_vm add interface=WSR_4002 list=local_vm add interface=WSR_4003 list=local_vm add interface=WSR_4004 list=local_vm add interface=WSR_4005 list=local_vm add interface=WSR_4006 list=local_vm add disabled=yes interface=WSR_4007 list=local_vm

Теперь для каждого интерфейса можем определить собственное адресное пространство, в каждом адресном пространстве DNS сервером будет являться виртуальная машина с Windows Server и AD. Тем самым каждое устройство сможет быть добавлено в созданную AD. Внутри AD дополнительно укажем DNS сервера организации.

/ip address add address=*.*.*.*/27 interface=Class_VM network=*.*.*.* add address=10.0.35.1/29 interface=WSR_4001 network=10.0.35.0 add address=10.0.36.1/29 interface=WSR_4002 network=10.0.36.0 add address=10.0.37.1/29 interface=WSR_4003 network=10.0.37.0 add address=10.0.38.1/29 interface=WSR_4004 network=10.0.38.0 add address=10.0.39.1/29 interface=WSR_4005 network=10.0.39.0 add address=10.0.40.1/29 interface=WSR_4006 network=10.0.40.0 add address=10.0.41.1/29 interface=WSR_4007 network=10.0.41.0 add address=*.*.*.*/27 interface=Real_Outside network=*.*.*.*

Для обеспечения изолированности каждой подсети друг от друга создадим соответствующее правило, но при этом обеспечим доступ к сети где располагаются Windows Server с AD (цепочка forward). Также запретим ICMP пакеты между сетями (цепочка input).

/ip firewall filter add action=accept chain=forward in-interface-list=local_vm out-interface=WSR_4007 add action=accept chain=forward in-interface=WSR_4007 out-interface-list=local_vm add action=drop chain=input comment="Block ping between interface" in-interface-list=local_vm protocol=\ icmp add action=drop chain=forward comment="Block traffic between interface" in-interface-list=local_vm \ out-interface-list=local_vm /ip firewall nat add action=masquerade chain=srcnat out-interface=Class8_509_VM

Для упрощения работы помещаем нужные интерфейсы в один список, тем самым обеспечиваем удобства в настройке firewall.

После всех настроек получаем следующую ситуация из DHCP сервера:

Как видим машины занимают адреса из определенных сетей.

Итог

Используя виртуальный Mikrotik CHR обеспечивается возможность взаимодействия между физическими машинами и виртуальными. Разделение каждого набора машин в собственное адресное пространство позволяет изолировать созданные объекты.

Источник