Виртуализация центров обработки данных

Андрей Робачевский

Андрей Робачевсий

Рецепт успешного развития современных центров обработки и хранения данных (ЦОДов), похоже, ясен – виртуализация. Но какая из многочисленных технологий наиболее эффективна в конкретной ситуации? Это и вопрос инвестиций, и обучения персонала – какая из них будет доминировать на рынке через пять лет?

Постоянно растущие требования к сокращению операционных затрат, времени развертывания услуг и бизнес-приложений, а также к их масштабируемости определяют тенденцию развития IT-инфраструктуры предприятий. Достижение этих требований возможно путем виртуализации – абстрагирования вычислительных ресурсов, инфраструктуры хранения данных и сети от физической инфраструктуры. При этом виртуализация серверов, хранения данных и сети могут быть обеспечены на различных уровнях компьютерных систем или сети.
Такой подход, совместно с тенденцией аутсорсинга IT-услуг, определяет архитектуру и развитие современных центров хранения и обработки данных (ЦОД/ЦХОД): виртуализация и концентрация.
С сетевой точки зрения, ключевым требованием к архи­тектуре многоклиентного ЦОДа – ЦОДа, обслуживающего сотни, а то и тысячи арендаторов ресурсов, – является изоляция трафика, так что трафик одного арендатора недоступен никакому другому арендатору. Другим требованием является изоляция адресного пространства, благодаря чему разные арендаторы могут использовать одно и то же адресное пространство в разных виртуальных сетях. Изоляция трафика и адресного пространства достигается путем присвоения каждому арендатору одной или нескольких виртуальных сетей; при этом трафик из одной виртуальной сети может обмениваться с другой виртуальной сетью только через ограниченные контроли­руемые точки – например, через маршрутизатор или шлюз безопасности.
Однако для решения вопроса масштабируемости в современных ЦОДах необходимо удовлетворить дополни­тельное требование – возможность быстрого размещения (и перемещения) вычислительных ресурсов внутри дата-цен­тра. Вычислительные ресурсы в этом случае представлены виртуальными машинами (ВМ). Задача состоит в том, чтобы иметь возможность перемещать виртуальные машины без привязки их адресации к адресной структуре сети самого дата-центра и такими образом, – без необходимости переадресации.
Более того, виртуальная машина может быть перенесена с одного сервера на другой в режиме реального времени – без необходимости остановки и перезапуска в новом местоположении и прерывания вычислительной задачи. Это может быть необходимо для оптимизации нагрузки и определенных параметров качества/производительности.
Ключевым требованием для живой миграции является то, что ВМ сохраняет параметры состояния сети в своем новом местоположении, включая его IP- и MAC-адреса. Сохранение MAC-адресов может потребоваться, поскольку любое изменение MAC-адресов виртуальных машин, воз­никающих в результате перемещения, будет видимым для виртуальной машины и, таким образом, может привести к неожиданным последствиям. Сохранение IP-адресов после перемещения необходимо для предотвращения обрыва существующих транспортных соединений (например, TCP) и их повторного запуска.
Одним из основных элементов достижения требований современных ЦОДов является сетевая инфраструктура. Эта инфраструктура также виртуализирована, предоставляя каждому клиенту-арендатору собственную сетевую инфраструктуру второго или третьего уровня, полностью изолированную от инфраструктуры других клиентов и самого ЦОДа. Обмен данными между этими сетями воз­можен, но происходит через контрольные узлы, например, маршрутизаторы или шлюзы, в соответствии с политикой, определенной клиентом.

Технологии виртуализации
Технологии виртуализации стремительно развиваются, но суть их примерно одинакова и сводится к созданию виртуальных сетей поверх существующей инфраструктуры, так называемых сетевых оверлеев. Опорная инфраструк­тура может использовать различные технологии передачи данных, пример – IP или MPLS. В контрольной плоскости для создания топологии и построения маршрутов могут исполь­зоваться различные протоколы маршрутизации, например, IS-IS, OSPF или BGP.
Оверлеи также могут существенно различаться – это могут быть виртуальные сети уровня 3 – IP VPN, или же уровня 2, эмулирующие Ethernet.
Помимо удовлетворения требований, о которых я рассказал в начале статьи, технологии виртуализации решают две основные задачи: в плоскости контроля – как осуществить обмен маршрутизационной информацией и привязать топологию оверлея к опорной инфраструктуре, а в плоскости передачи данных – вопрос инкапсуляции изначального трафика (пакетов IP или фреймов Ethernet) в данные для передачи в опорной сети.
Мы начнем разговор с оверлейных IP-сетей, а затем перейдем к сетям уровня 2. Применительно к ЦОДам виртуализация сетей Ethernet является наиболее популярной, так как позволяет упростить архитектуру клиентских сетей и эффективно обеспечить мобильность ВМ. С момента появления технология Ethernet не перестает развиваться, охва­тывая все более широкий класс задач, как с точки зрения скоростей передачи, так и с точки зрения виртуализации. Живучесть и эволюция этой технологии впечатляют, см. рис 1.

BGP/MPLS IP VPNs
VPN-сети, основанные на технологии BGP/MPLS уровня 3, позволяют поддерживать сложные топологии и решают проблему масштабируемости обычных VPN точка-точка, таких как IPSec VPN. Для добавления нового сайта в BGP/MPLS VPN требуется одно изменение на граничном маршрутизаторе провайдера (PE), к которому подключен клиентский маршрутизатор. Маршрутизаторы клиента (CE) обмениваются маршрутной информацией с маршрутизато­ром PE с использованием BGP и не знают о существовании VPN. VPN создаются между PE-маршрутизаторами, которые используют BGP с мультипротокольным расширением (MP-BGP, RFC 4760) для обмена префиксами клиентов и связанных с ними меток VPN.
На граничных маршрутизаторах провайдера PE для каждого подключенного клиента создается виртуальная таблица маршрутизации с использованием технологии VRF (VPN Routing and Forwarding). VRF позволяет одно­временно использовать несколько экземпляров таблицы маршрутизации на одном и том же маршрутизаторе. Поскольку экземпляры таблицы маршрутизации незави­симы, одинаковые или перекрывающиеся IP-адреса могут использоваться без конфликта друг с другом. Благодаря этому достигается полная изоляция и независимость виртуальных сетей клиентов друг от друга.
На рис. 2 представлена схема реализации виртуальных сетей для двух клиентов – A и B.
Граничный маршрутизатор PE1 обслуживает две виртуаль­ные таблицы VRF для двух клиентов. Обмен маршрутной информацией между граничными маршрутизаторами осуществляется с помощью iBGP. Однако возникает про­блема – каким образом различить адресные пространства различных VPN, которые к тому же могут пересекаться?
Использование MP-BGP позволяет обмениваться маршру­тами из различных «семейств адресов». Для IPv4-адресов VPN вводится понятие «семейство адресов VPN-IPv4».

Адрес VPN-IPv4 представляет собой 12-байтовое поле, состоящее из 8-байтового селектора маршрута (Route Distinguisher, RD) и 4-байтного адреса IPv4. Если несколько VPN используют один и тот же префикс адреса IPv4, PE преобразуют их в уникальные префиксы адресов VPN-IPv4. Это гарантирует, что если даже один и тот же адрес исполь­зуется в разных VPN, маршрутизаторы могут обмениваться совершенно разными маршрутами для этого адреса, по одному для каждого VPN.
Для передачи трафика используется технология мульти­протокольной коммутации меток (MPLS). Трафик следует через предопределенный путь коммутации меток (LSP), который является однонаправленным туннелем между двумя маршрутизаторами PE. Каждый из PE является т.н. граничным маршрутизатором меток (Label Edge Router, LER), который инкапсулирует IP-пакеты VPN в пакеты MPLS с соответствующими метками.
Коммутацию меток осуществляют опорные маршрутиза­торы провайдера (P). Эти маршрутизаторы не подключены к каким-либо CE-маршрутизаторам и также не содержат маршруты VPN-IPv4, а только внутренние маршруты к другим маршрутизаторам P и PE. P-маршрутизаторы проверяют только самую верхнюю (внешнюю) LSP-метку и заменяют ее новой меткой LSP перед пересылкой пакета.
VPN-сети уровня L3 масштабируются до тысяч VPN и миллионов префиксов. BGP/MPLS IP VPN применяются в крупных корпоративных центрах обработки данных. Потен­циальным ограничением для применения этой технологии в ЦОДах является практичность использования, особенно для доступа к серверам или гипервизорам. По мере роста ЦОДа трудно решаемыми становятся вопросы масштабиру­емости (поддержка полносвязной топологии MPLS), а также сходимости и согласованности BGP.
Оверлеи EVPN
Виртуальные сети Ethernet – EVPN (RFC7348) – представляют собой эмулированную услугу L2, в которой каждый арендатор имеет свою собственную сеть – Ethernet-оверлей через общую IP-инфраструктуру.
Так же, как в случае BGP IP VPN, для обмена информацией о MAC-адресах и идентификаторов виртуальных сетей участвующих устройств (ими могут быть хосты, маршрути­заторы или коммутаторы) используется MP-BGP. Граничный маршрутизатор PE обслуживает отдельную таблицу MAC-VRF для каждого клиента, обеспечивая требуемую изоляцию.
Поскольку EVPN обеспечивает эмуляцию сети уровня L2, возникает вопрос обработки широковещательного трафика типа бродкаст, малтикаст и «неизвестный юникаст» – так называемого трафика BUM (Broadcast, multicast, unknown unicast). Одним из вариантов является репликация такого трафика на входном PE. Более оптимальным подходом, однако, является использование малтикаста. В этом случае для каждого широковещательного домена создаются соответствующие малтикаст-группы.
Технология EVPN позволяет значительно увеличить утилизацию инфраструктуры. Дело в том, что в нату­ральных L2-сетях используются два механизма, которые плохо масштабируются. Первый, о котором мы только что говорили, связан с обслуживанием BUM-трафика. В сетях Ethernet для этого используется механизм «наводнения» (flooding), когда пакеты рассылаются по всей связующей инфраструктуре. Второй – механизм исключения «петель» – циклического обмена маршрутной информацией L2. Для этого в сетях Ethernet используется протокол STP (Spanning Tree Protocol), с помощью которого в сети отключаются отдельные каналы связи для предотвращения петель. В результате часть инфраструктуры не используется. При­менение L3 поддерживающей инфраструктуры позволяет избежать этой проблемы, а использование технологии ECMP обеспечивает максимальную утилизацию.

Хотя изначально архитектура EVPN была разработана с использованием MPLS для передачи данных, на сегодня различные типы инкапсуляции данных нашли свое приме­нение.
Наиболее используемыми являются технологии Virtual Extensible LAN (VXLAN, RFC7348), Network Virtualization using Generic Routing Encapsulation (NVGRE, RFC7637) и MPLS over Generic Routing Encapsulation (GRE, RFC4023). В настоящее время разрабатывается более общий и гибкий подход к построению оверлеев (туннелей), так называемый GENEVE (Generic Network Virtualization Encapsulation). Давайте рассмотрим некоторые из них.
Virtual eXtensible Local Area Network (VXLAN)
VXLAN является методом построения туннелей уровня L2 на опорной IP-инфраструктуре (L3) на основе EVPN. Эта технология документирована в RFC7348. VXLAN использует инкапсуляцию IP/ UDP. 24-разрядный идентификатор сегмента VXLAN, или VNI, обеспечивает до 16 миллионов сегментов VXLAN для изоляции и сегментации трафика, в отличие от 4000 сегментов, доступных в VLAN. Каждый из этих сегментов представляет собой уникальный широковещательный домен уровня 2, изолированный от сегментов других клиентов. Таким образом, использование клиентами пересекающегося адресного пространства, как IP, так и MAC, не представляет проблемы.
Опорная IP-инфраструктура использует внутренний протокол маршрутизации, такой как OSPF или IS-IS, для определения внутренней топологии и обеспечения связности. Также используется протокол PIM для создания малтикаст-инфраструктуры, необходимой для обработки BUM-трафика.
В плоскости передачи данных используется инкапсуляция IP/UDP для туннелирования трафика через опорную инфраструктуру. Граничные маршрутизаторы обычно также выполняют роль т.н. VTEP (VXLAN tunnel endpoint), обеспечи­вая инкапсуляцию и декапсуляцию трафика.
Каждое из устройств VTEP обменивается информацией о MAC-адресах подключенных к ним устройств и связанных с ними VNI с другими VTEP с помощью MP-BGP. При этом для каждого сегмента с уникальным VNI создается собственная таблица MAC-VRF, благодаря чему обеспечивается изоляция адресных пространств различных VXLAN.
Схема поддерживающей IP-инфраструктуры и оверлея VXLAN представлена на рис 3. Голубым цветом показана VXLAN VNI 10008. Хотя различные виртуальные сети исполь­зуют ту же инфраструктуру, их адресное пространство и топология полностью независимы. Например, устройства «оранжевой» VXLAN используют то же адресное простран­ство, что и «голубой».
Поддержка BUM-трафика показана на рис 4. Хотя устройства виртуальной сети для получения информации о MAC-адресах других устройств традиционно используют такие методы, как ARP, эти запросы не проходят дальше устройства VTEP. Как мы только что видели, все устройства VTEP виртуальной сети используют MP-BGP для получения этой информации. Поэтому, когда приходит запрос ARP, VTEP уже знает ответ, который он и отправляет запрашива­ющему устройству.

Однако BUM-трафик не исчерпывается запросами ARP. Для его обработки для каждого широковещательного домена (другими словами, для каждой VXLAN) создается отдельная малтикаст-группа. Этот процесс невидим для устройств VXLAN и реализуется с помощью таких протоколов, как PIM в опорной IP-инфраструктуре.

Network Virtualization using Generic Routing Encapsulation (NVGRE)

Сетевая виртуализация с использованием универсальной инкапсуляции маршрутизации, или NVGRE, позволяет создавать виртуальные сети уровня 2 поверх опорной инфраструктуры уровня 3. Это достигается путем туннели­рования Ethernet-фреймов внутри IP-пакета по физической сети. Подобно VXLAN, NVGRE поддерживает идентификатор 24-битного сегмента или идентификатор виртуальной подсети (VSID), предоставляя до 16 миллионов виртуальных сегментов, которые могут однозначно идентифицировать сетевой сегмент и соответствующее ему адресное про­странство отдельного клиента.

Технология NVGRE очень похожа на VXLAN. Основное различие заключается в том, что заголовок NVGRE содержит необязательное поле идентификатора потока. В многосвязных опорных сетях маршрутизаторы и коммутато­ры могут анализировать заголовок пакетов и использовать это поле вместе с VSID для трафик-инжиниринга, хотя для этой функции требуются дополнительные возможности аппаратного обеспечения.

Как и в случае с VXLAN, в стандарте NVGRE не указывается метод обнаружения достижимости конечной точки. Для этого применяются решения типа EVPN.

Программно-конфигурируемая сеть

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

Концепция SDN (Software Defined Network, программ­но-конфигурируемая сеть) предусматривает передачу управляющих функций центральному устройству — т.н. контроллеру, таким образом заменяя традиционную распределенную модель маршрутизации на централи­зованную. Соответственно, и процесс управления сетью, включающий создание маршрутов, является не чем иным, как программированием сети в целом.

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

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

На первый взгляд, SDN является привлекательной технологией в достижении целей виртуализации, стоящими перед современным ЦОДом, по крайней мере, в архитектурном плане. Однако успех внедрения той или иной технологии зависит от многих факторов: знание и опыт использования сотрудниками, существующая инфра­структура, доступность решений и оборудования, их цена и производительность и т.п.

Увидим ли мы дальнейшее развитие оверлеев на базе традиционных технологий и существующей инфраструкту­ры или централизованные программные решения станут более популярными – покажет будущее.