Глава 2. Руководство по SDN и NFV. 2. Архитектура

Глава 3. Руководство по SDN и NFV. 3. Инфраструктура NFV (NFVI) и менеджер VIM.

Глава 4. Руководство по SDN и NFV. 4. Менеджер VNF (VNFM).

Глава 5. Руководство по SDN и NFV. 5. Дескрипторы VNF (VNFD)

Глава 6. Руководство по SDN и NFV. 6. Оркестрация услуг EEO.

Глава 7. Руководство по SDN и NFV. 7. Дескрипторы комплексных сетевых услуг EENSD

Глава 8. Руководство по SDN/NFV. Глава 8. Структура политик.

Глава 9.1. Руководство по SDN/NFV. Глава 9.1  СТРУКТУРА КОНТРОЛЛЕРА SDN (Часть 1).

9.3       Контроллеры SDN для дата-центров

С появлением виртуализации, когда несколько виртуальных машин (VM) могут работать в одном физическом сервере, а создание и миграция VM обеспечивают масштабируемость и динамичность, требуются новые требования к коннективности. Один из примеров развёртывания показан на рис. 9.2:

Рисунок 9.2. Решение SDN для дата-центра.

Решение представляет собой «федеративный» SDN-контроллер, который управляет функцией передачи пакетов через коммутатор (forwarder) в сети дата-центра через открытые протоколы, такие как OpenFlow, OVSDB, или NETCONF. В зависимости от применения, эти проколы требуют расширения, или дополнительной адаптации, либо выбор протокола может изменяться в конкретном случае. Функция forwarder на каждом сервере или VNF может либо состоять из имеющейся в нём функциональности (“vSwitch”), либо может дополняться дополнительным агентом передачи, который может управляться теми же протоколами, либо через API, предоставленным вендором. От SDN-контроллера также может требоваться поддержка функции forwarder на физическом коммутаторе. Например, в случае сервера «bare metal», или устройства, подключенного к коммутатору ToR (Top of Rack), контроллер должен создавать наложенный туннель между ToR и виртуальной функцией forwarder.

«Северный» интерфейс (Or-Sdnc) определяется в зависимости от контроллера и предоставляется как API в сторону уровня оркестрации, чтобы передавать соответствующие примитивы сервисов, для текущей слуги. В свою очередь, «северный» интерфейс SDN-контроллера дата-центра предоставляет API, через который задаются параметры соединения (коннективность) в абстрагированном виде. Обычно это делается через API-интерфейс REST, Openstack Neutron или vSphere. В частности, в контексте NFV MANO, эти требования коннективности могут формулироваться в моделях YANG или TOSCA, которые являются частью сетевой услуги или VNF.

«Южный» интерфейс (Sdnc-Net и Sdnc-Vi, в зависимости от типа контроллера) используется для передачи команд на коммутаторы сети дата-центра. Он должен быть способен поддерживать новвый функционал без проблем «обратной совместимости». Позднее он будет описан позднее. В этом интерфесе также используются протоколы Openflow, OVSDB, NETCONF, или API вендора. При создании виртуальной машины, контроллер SDN использует требования коннективности и создает наложенные туннели между VM и всеми другими виртуальными машинами, к которым ей требуется под требуется подключиться. Обычно эти туннели используют инкапсуляцию VXLAN или GRE).

Как пример, можно рассмотреть случай виртуальных услуг (межсетевой экран, балансировщик нагрузки, и пр.). SDN-контроллер дата-центра создает коннективность для подключения виртуальной услуги сети согласно её установкам коннективности. Эта услуга либо может быть полностью виртуальной, либо частично использовать коннективность физической сети. Когда требования коннективности предусматривают использование физической сети, контроллер SDN программирует шлюзы между физической и виртуальной сетями (VXLAN to VRF mapping).

«Федеративность» между SDN-контроллерами дата-центра обычно основана на протоколе BGP и его вариациях, но исследуются также и более современные протоколы. Наложенная сеть, созданная SDN-контроллером дата-центра может быть независима от нижележащей сети, состоящей из классических роутеров и коммутаторов для дата-центров, или она может состоять из «white boxes» под управлением «нижележащих SDN-контроллеров».