Способ автоматизированного предоставления виртуального канала оператором связи между цод

Изобретение относится к области вычислительной техники. Технический результат заключается в повышении стабильности созданных виртуальных каналов связи. Технический результат достигается за счет способа формирования виртуального канала между центрами обработки данных (ЦОД) с использованием контроллера программно-конфигурируемой сети (ПКС), в котором контроллер ПКС: получает запрос на создание записи арендатора виртуальных каналов и признака соответствия режиму обслуживания виртуальных каналов арендатора, формирует набор данных арендаторов виртуальных каналов, получает запрос на формирование виртуального канала, выполняет построение маршрута виртуального канала, добавляет в набор данных организации трафика записи о виртуальном канале, добавляет в набор данных арендаторов виртуальных каналов записи о принадлежности виртуального канала арендатору, выполняет серию запросов к коммутаторам для настройки коммутаторов по построенному маршруту виртуального канала с формированием виртуального канала в одном направлении, и в ответ на условие завершения виртуального канала выполняет серию запросов к коммутаторам по построенному маршруту виртуального канала для удаления правил обработки и маршрутизации трафика виртуального канала. 21 з.п. ф-лы, 7 ил., 2 табл.

 

ОБЛАСТЬ ТЕХНИКИ

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

УРОВЕНЬ ТЕХНИКИ

Требования к Центрам Обработки Данных (ЦОД) для предоставления услуг IaaS (от англ. Infrastructure as a Service - инфраструктура как услуга), PaaS (от англ. Platform as a Service - платформа как услуга), SaaS (от англ. software as a service - программное обеспечение как услуга) постоянно растут, поскольку эти услуги позволяют предприятиям оптимизировать общую стоимость владения (TСO, от англ. total cost of ownership) и экономят время развёртывания вычислительной инфраструктуры.

В общем случае система управления ЦОД (101, ФИГ. 1) включает взаимодействующие программные модули: компоненты, обеспечивающие хранение и обработку данных, например, инфраструктурные облачные службы, такие как: управление гипервизорами Nova, служба аутентификации Keystone, распределённое хранилище Swift, интерфейс к базам данных Trove или компонент управления сетевой инфраструктурой Neutron, обеспечивающий связь между всеми компонентами, реализованными в системе управления OpenStack.

Физическая память, где фактически хранятся цифровые данные, может быть распределена между несколькими серверами и иметь, например, интерфейс службы сетевого хранилища данных (NAS, Network Attached Storage) или другой. Обработка данных также может быть распределена между несколькими серверами. Распределённая обработка данных при такой организации может напоминать схему полносвязной сети, в которой каждый узел взаимодействует с каждым, как показано на ФИГ. 1, изображающей вариант схемы связей системы компьютерной обработки информации, реализованной в ЦОД.

На ФИГ. 1 изображен вариант логической полносвязной сети, схемы передачи данных между инфраструктурными облачными сервисами (в частности, обработки и хранения данных) 131, 141, 151, 161, применяемыми в ЦОД 101 и клиентами 111, 121 – арендаторами вычислительных ресурсов.

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

Построение туннелей между программными компонентами внутри системы ЦОД выполняется автоматически. Построение туннелей для взаимодействия между программными компонентами различных ЦОД может выполняться в автоматизированном режиме с выполнением вызовов API к системам управления ЦОД (202, 212, ФИГ. 2). Например, на ФИГ. 2 изображена схема связей между ЦОД по предварительно предоставленной в аренду оператором связи выделенной линии, имеющей гарантированную полосу пропускания, рассчитанной на максимальную интенсивность трафика. Так, для передачи данных между программными компонентами (модулями) различных ЦОД выполняется вызов API к системам управления ЦОД, после обработки которого между сетевыми модулями удаленных ЦОД создаётся туннель или туннели, позволяющие передавать данные. Выбор точной реализации на этом уровне зависит от системы управления ЦОД и применяемых протоколов туннелирования.

При объединении ресурсов, при условии обмена данными между удаленными ЦОД, на выходе сетевой компоненты (в частности, модуля системы управления ЦОД, например, модуля «Neutron» из системы управления «OpenStack») в сеть передачи данных поступают инкапсулированные данные (по крайней мере по модели ISO/OSI для L2 или L3 туннелирования), организовано L2 или L3 туннелирование (222, ФИГ. 2). Выбор (осуществляемый автоматически, причем алгоритм выбирается в зависимости от вариантов реализации системы управления) точной реализации на этом уровне зависит от системы управления ЦОД и применяемых протоколов туннелирования.

Для построения туннелей между программными компонентами удалённых ЦОД возможно, так же, решение без предварительно предоставленной в аренду выделенной линии: с использованием разделяемых каналов оператора связи, но такой способ построения туннелей между программными компонентами удалённых ЦОД не гарантирует стабильную ширину полосы пропускания и приемлемое время отклика. Поэтому для организации связи между ЦОД оператор связи предоставляет в аренду выделенную линию с гарантированной полосой пропускания. Как правило, для объединения ЦОД оператор связи выделяет L2, L3 канал или физический канал с пропускной способностью, рассчитанной на максимальную интенсивность трафика.

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

Решение с предварительно предоставленной в аренду линией оператора связи в общем случае также не позволяет гарантировать своевременный транзит отдельных потоков данных, чувствительного к временным задержкам трафика, т. к. в рамках арендованного канала с гарантированной общей полосой пропускания транзит отдельных потоков выполняется согласно модели негарантированной доставки QoS (от англ. quality of service - «качество обслуживания»).

СУЩНОСТЬ ТЕХНИЧЕСКОГО РЕШЕНИЯ

Технический результат, достигаемый предлагаемым техническим решением, состоит в повышении эффективности создания виртуальных каналов, повышении эффективности использования сетевого оборудования, повышении стабильности созданных виртуальных каналов

Согласно одному из вариантов реализации, предлагается способ автоматического формирования виртуального канала между центрами обработки данных (ЦОД) с использованием контроллера программно-конфигурируемой сети (ПКС), в котором:

- коммутаторы, управляемые контроллером ПКС, выполняют обмен пакетами протоколов обнаружение соединения;

- контроллер ПКС периодически выполняет опрос, заданных с помощью механизма межпроцессного взаимодействия, коммутаторов о существующих на коммутаторах интерфейсах, пропускной способности линий и о подключенных к их интерфейсам устройствах с формированием первого набора данных;

- на основании первого набора данных контроллер ПКС формирует набор данных организации трафика, содержащий данные о топологии и ресурсах сети коммутаторов;

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

- контроллер ПКС формирует набор данных арендаторов виртуальных каналов, содержащий: идентификаторы арендаторов виртуальных каналов, идентификаторы виртуальных каналов и признак соответствия режиму обслуживания каналов арендатора;

- контроллер ПКС с помощью механизма межпроцессного взаимодействия получает запрос на формирование виртуального канала, содержащий, по меньшей мере: данные о точках входа трафика виртуального канала, признак трафика, попадающего в виртуальный канал, информацию о начале и завершении виртуального канала, данные о принадлежности виртуального канала арендатору и данные о требуемых параметрах QoS;

- контроллер ПКС выполняет построение маршрута виртуального канала с учётом: признака соответствия режиму обслуживания каналов арендатора, ресурса пропускной способности домена коммутаторов, информации о начале и завершении виртуальных каналов и параметров QoS, запрошенных для виртуальных каналов;

- контроллер ПКС добавляет в набор данных организации трафика записи о виртуальном канале: маршруте виртуального канала, признаке трафика, попадающего в виртуальный канал, информацию о начале и завершении виртуального канала и занятой виртуальным каналом пропускной способности;

- контроллер ПКС добавляет в набор данных арендаторов виртуальных каналов записи о принадлежности виртуального канала арендатору;

- контроллер ПКС выполняет серию запросов к коммутаторам для настройки коммутаторов по построенному маршруту виртуального канала с формированием, по меньшей мере одного виртуального канала по меньшей мере в одном направлении, где настройка включает правила обработки и маршрутизации трафика с учетом ресурса пропускной способности сети и параметров QoS;

- в ответ на условие завершения виртуального канала контроллер ПКС по выполняет серию запросов к коммутаторам по построенному маршруту виртуального канала для удаления правил обработки и маршрутизации трафика виртуального канала.

В одном из частных вариантов реализации информация для формирования первого набора данных задаётся статически.

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

В одном из частных вариантов реализации запрос на формирование виртуального канала, в качестве информации о начале и завершении виртуального канала, содержит максимальное значение объёма данных, переданных по виртуальному каналу.

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

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

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

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

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

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

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

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

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

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

В одном из частных вариантов реализации функции контроллера ПКС дублируются дополнительным контроллером ПКС по принципу основного и резервного контроллера ПКС.

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

В одном из частных вариантов реализации серия запросов от контроллера ПКС к коммутаторам является серией NETCONF запросов.

В одном из частных вариантов реализации серия запросов от контроллера ПКС к коммутаторам является серией RESTCONF запросов.

В одном из частных вариантов реализации для формирования контроллером ПКС запросов к коммутаторам применяются yang модели openConfig, yang модели, созданные производителем коммутаторов или yang модели, созданные третьими лицами.

В одном из частных вариантов реализации серия запросов от контроллера ПКС к коммутаторам является серией запросов ofConfig.

В одном из частных вариантов реализации серия запросов от контроллера ПКС к подконтрольным коммутаторам является серией openFlow запросов.

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

КРАТКОЕ ОПИСАНИЕ ГРАФИЧЕСКИХ МАТЕРИАЛОВ

ФИГ. 1 иллюстрирует вариант логической полносвязной сети, схемы передачи данных между инфраструктурными облачными сервисами, применяемыми в ЦОД и клиентами – арендаторами вычислительных ресурсов;

ФИГ. 2 иллюстрирует схему связей между ЦОД по предварительно предоставленной в аренду оператором связи выделенной линии, имеющей гарантированную полосу пропускания, рассчитанной на максимальную интенсивность трафика;

ФИГ. 3 иллюстрирует пример автоматизированного предоставления виртуального канала с функциями QoS, согласно одного из вариантов осуществления;

ФИГ. 4 иллюстрирует функциональную схему контроллера ПКС, согласно одного из вариантов осуществления настоящего технического решения;

ФИГ. 5 иллюстрирует вариант схемы базы данных TED, согласно одному из вариантов осуществления настоящего технического решения;

ФИГ. 6 иллюстрирует пример случая превышения пропускной способности интерфейса;

ФИГ. 7 иллюстрирует примерный вариант осуществления настоящего технического решения.

ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ

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

Далее в описании термины «коммутатор» и «маршрутизатор» используются как синонимы и обозначают устройство, выполняющее обработку заголовков пакетных данных второго, третьего и/ или четвертого уровня модели сетевого взаимодействия OSI/ISO.

На ФИГ. 3 показан пример автоматизированного предоставления виртуального канала с функциями QoS, согласно одного из вариантов осуществления, в частности, показан вариант схемы автоматизированного предоставления виртуального канала оператором связи между ЦОД с применением элементов дифференцированной и интегрированной моделей обслуживания QoS.

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

Одной из задач настоящего технического решения является автоматизация предоставления оператором связи виртуального канала между ЦОД.

На ФИГ. 3 показаны две группы клиентов, программные компоненты в составе системы управления ЦОД А 202 и программные компоненты в составе системы управления ЦОД B 212. В исходном состоянии программные компоненты двух систем управления ЦОД (клиент и сервер) не могут передавать данные друг другу, для организации обмена выполняется несколько API вызовов (в частности, нескольких API вызовов к системам управления ЦОД 202, 212 и к контроллеру ПКС 313).

Пусть первый вызов API (373), обеспечивающем построение туннелей для взаимодействия между программными компонентами различных ЦОД, выполняется к системам управления ЦОД А 202 и ЦОД B 212, теперь данные, поступающие от клиентов, направляются в туннель /туннели 222 и могут поступать на коммутатор R1 343 и коммутатор R2 353, как результат выполнения вызова, обеспечивающего построение туннелей для взаимодействия между программными компонентами различных ЦОД.

Второй вызов API (363), в частности, API вызов, уведомляющий контроллер ПКС о необходимости формирования виртуального канала, выполняется к контроллеру ПКС 313, контроллер ПКС 313 выполняет настройку виртуальных каналов на подконтрольных коммутаторах: R1 343 и R2 353, причем API вызов содержит, как минимум, данные для упомянутой настройки, в том числе данные о точках входа трафика виртуального канала, признак трафика, попадающего в виртуальный канал, информацию о начале и завершении виртуального канала, данные о принадлежности виртуального канала арендатору и данные о требуемых параметрах QoS. Виртуальные каналы позволяют добавить функциональность управления временем существования, пропускной способностью - обеспечить функции моделей обслуживания QoS в разных комбинациях составляющих, а также выполнять отказоустойчивую маршрутизацию и балансировку нагрузки. Коммутатор R1 343 маршрутизирует туннель в сеть подконтрольных коммутаторов. Через условную сеть, в данном случае напрямую, данные направляются от коммутатора R1 343 коммутатору R2 353. Однако, следует понимать, количество узлов и топология сети коммутаторов (343, 353), управляемых контроллером ПКС 313, может быть любым и ограничиваться, в некоторых вариантах осуществления, только числом одновременно открытых файловых дескрипторов на уровне архитектуры операционной системы контроллера ПКС 313. Маршрутизация виртуальных каналов может выполняться с применением дополнительного туннелирования, например QinQ, в этом случае коммутатор R2 353 извлекает данные (в случае применения дополнительного туннелирования данных, передаваемых по виртуальному каналу, например, QinQ), передаваемые по туннелю и передаёт сетевой компоненте системы управления ЦОД B 212. Сетевой программный компонент (в частности, сетевая служба) системы управления ЦОД B 212 извлекает данные, переданные программным компонентом системы управления ЦОД из туннеля и передаёт адресу назначения, программному компоненту системы управления ЦОД B. То же происходит в обратном направлении, обрабатываются данные поступающие от программного компонента системы управления ЦОД B программному компоненту системы управления ЦОД А.

Поскольку данные между ЦОД передаются по линиям оператора связи, может появиться необходимость в дополнительной функциональности, которая позволит оперативно создавать каналы, управлять скоростью, назначить приоритет отдельных потоков данных и т.п., как показано на ФИГ. 3. Указанные функции могут быть включены в функциональность наложенной сети 303, поскольку их реализация не зависит от применяемых протоколов передачи данных, логической и физической организации линий связи и выполняется за счёт централизованного управления, как описано далее.

Контроллер программно-конфигурируемой сети (ПКС) 313 позволяет в автоматическом режиме с использованием конфигурационных запросов/ответов 333 создавать на подконтрольных коммутаторах виртуальные каналы 323 – правила обработки и маршрутизации трафика, добавлять функциональность управления временем существования и пропускной способностью виртуальных каналов 323, обеспечивать другие функции моделей обслуживания QoS в разных комбинациях составляющих, а также выполнять отказоустойчивую маршрутизацию и балансировку нагрузки, как показано на ФИГ. 3.

Упомянутые виртуальные каналы 323 включают (в частном случае являются) правила обработки и маршрутизации трафика, установленные на коммутаторах по маршруту транзита трафика, созданные путём централизованной настройки (в частности, управлением) коммутаторов контроллером ПКС 313.

Функциональность наложенной сети 303 включает (в частном случае является) правила обработки и маршрутизации трафика, установленные на коммутаторах по маршруту транзита трафика, созданные путём централизованной настройки (в частности, управлением) коммутаторов контроллером ПКС 313.

На ФИГ. 4 показана функциональная схема контроллера ПКС, согласно одного из вариантов осуществления настоящего технического решения.

Как показано на функциональной схеме, ФИГ. 4, контроллер ПКС 313 состоит из логики, обеспечивающей маршрутизацию виртуальных каналов (управляющее приложение 404) и программных библиотек, в частности, библиотек взаимодействия с коммутатором 434, взаимодействия с коммутатором 343, 353, обеспечивающих централизованное управление, настройку коммутаторов на маршруте прохождения данных между ЦОД. Количество и тип библиотек взаимодействия с коммутатором 434, определяет количество поддерживаемых контроллером ПКС 313 протоколов, используемых для взаимодействия контроллера ПКС с коммутаторами 343, 353. Порядок и содержание конфигурационных запросов/ответов (в частности, вызовов RPC) 333 также зависит от протокола, используемого для взаимодействия контроллера ПКС 313 с коммутатором 343, 353.

Управляющее приложение контроллера ПКС 404, в описываемом варианте с применением протокола NETCONF (сетевой протокол конфигурации, протокол сетевого управления устройствами), при старте выполняет первичную инициализацию, происходит опрос коммутаторов по заданным адресам. В разных вариантах осуществления адреса коммутаторов могут храниться в конфигурации контроллера ПКС 313 или задаваться динамически с помощью механизмов межпроцессного взаимодействия. Выполняются вызовы RPC 333, 444, позволяющие определить существующие на коммутаторах интерфейсы, пропускную способность линий и информацию о соседних коммутаторах, доступную по протоколам обнаружения соединений. С использованием полученных данных контроллер ПКС 313 осуществляет построение графа, соответствующего топологии связей и пропускной способности линий между коммутаторами.

Управляющее приложение контроллера ПКС 404 ведёт записи базы данных TED 414 (базы данных организации трафика (TED, от англ. Trafic Engeneering Data)), полученных в ходе опроса коммутаторов и полученных в результате обработки запросов на формирование виртуальных каналов. Информационный обмен между управляющим приложением 404 и базой данных TED 414 может состоять из данных о топологии и ресурсах домена подконтрольных коммутаторов, информации о маршруте виртуальных каналов. Информация базы данных TED 414 может использоваться управляющим приложением контроллера ПКС 404 в некоторых вариантах осуществления для расчёта маршрута виртуального канала или в случае аварийного восстановления (где фактом аварийного завершения, требующего аварийного восстановления, может являться, например, содержание в базе TED данных). База данных TED может быть расположена на одной программно-аппаратной платформе с контроллером ПКС или размещена за пределами, удалённо. Граф топологии домена подконтрольных коммутаторов в базе данных TED в некоторых вариантах осуществления может храниться в виде записей таблиц «switch_tbl» (535) и «interfaces_tbl» (545).

Управляющее приложение контроллера ПКС ведёт записи базы данных арендаторов виртуальных каналов 424. Информационный обмен между управляющим приложением 404 и базой данных арендаторов виртуальных каналов в некоторых вариантах осуществления может состоять из идентификаторов арендаторов виртуальных каналов, идентификаторов виртуальных каналов и признака привилегированного режима обслуживания виртуальных каналов арендатора. Информация базы данных арендаторов 424 может использоваться управляющим приложением контроллера ПКС 404 в некоторых вариантах осуществления для построения или перестроения маршрута виртуальных каналов, или в случае аварийного восстановления. Признак привилегированного режима обслуживания задает приоритет при маршрутизации виртуальных каналов 323, который в некоторых вариантах осуществления, например, может являться признаком, позволяющим управляющему приложению 404 при маршрутизации виртуальных каналов вытеснять из графа топологии виртуальные каналы других арендаторов.

Вызов REST API (363), в некоторых вариантах осуществления, может содержать, например, запрос на создание или удаление виртуального канала (323).

Централизованное управление коммутаторами на маршруте прохождения данных между удаленными ЦОД выполняется с применением протокола NETCONF (RFC4741 https://tools.ietf.org/html/rfc4741, RFC6241 https://tools.ietf.org/html/rfc6241). Контроллер ПКС 313 может формировать запрос NETCONF с применением языка моделирования данных YANG (RFC6020 https://tools.ietf.org/html/rfc6020https://tools.ietf.org/html/rfc7950, RFC7950). В некоторых вариантах осуществления взаимодействие между контроллером ПКС 313 и подконтрольными коммутаторами может выполняться с применением протокола RESTCONF (RFC8040 https://tools.ietf.org/html/rfc8040, RFC8527 https://tools.ietf.org/html/rfc8527). В некоторых вариантах осуществления взаимодействие между контроллером ПКС 313 и подконтрольными коммутаторами может выполняться с применением протокола openConfig. В некоторых вариантах осуществления взаимодействие между контроллером ПКС 313 и подконтрольными коммутаторами может выполняться с применением протокола ofConfig В некоторых вариантах осуществления взаимодействие между контроллером ПКС 313 и подконтрольными коммутаторами также может выполняться с применением протокола PCEP (RFC5440 https://tools.ietf.org/html/rfc5440, RFC7896 https://tools.ietf.org/html/rfc7896, RFC8253 https://tools.ietf.org/html/rfc8253, RFC8356 https://tools.ietf.org/html/rfc8356, RFC8408 https://tools.ietf.org/html/rfc8408, RFC8664 https://tools.ietf.org/html/rfc8664, RFC7420 https://tools.ietf.org/html/rfc7420). В некоторых вариантах осуществления взаимодействие между контроллером ПКС 313 и подконтрольными коммутаторами также может выполняться с применением протокола OpenFlow (OpenFlow® Switch Specification 1.3.0 https://opennetworking.org/wp-content/uploads/2014/10/openflow-spec-v1.3.0.pdf).

Функции централизованного управления обеспечивают:

- опрос коммутаторов при первичной инициализации контроллера ПКС 313;

- автоматическое создание и удаление виртуальных каналов 323 между ЦОД (в частности, между системами управления ЦОД);

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

Так, с использованием централизованного управления осуществляется опрос коммутаторов при первичной инициализации контроллера ПКС 313; автоматическое создание и удаление виртуальных каналов 323 между ЦОД и отслеживание состояния и топологии связей домена подконтрольных коммутаторов.

Функции управляющего приложения 404 обеспечивают:

- построение и перестроение маршрута виртуальных каналов 323 в сети подконтрольных коммутаторов между удалёнными ЦОД;

- планирование, моменты времени начала и завершения существования виртуальных каналов 323 в сети подконтрольных коммутаторов между удалёнными ЦОД;

- построение и перестроение маршрута с учётом признака привилегированного режима обслуживания виртуального канала (323);

- балансировку нагрузки с автоматическим перестроением маршрутов виртуальных каналов 323 в сети подконтрольных коммутаторов;

- отказоустойчивость при передаче данных по виртуальным каналам 323 в случае отказа одной или нескольких физических линий передачи данных за счёт автоматического перестроения маршрута виртуального канала (323).

Так, управляющее приложение 404 осуществляет построение и перестроение маршрутов виртуальных каналов 323 в сети подконтрольных коммутаторов между удалёнными ЦОД; планирование, моменты времени начала и завершения существования виртуальных каналов 323 в сети подконтрольных коммутаторов между удалёнными ЦОД; построение и перестроение маршрута с учётом признака привилегированного режима обслуживания виртуального канала (323); балансировку нагрузки с автоматическим перестроением маршрутов виртуальных каналов 323 в сети подконтрольных коммутаторов; обеспечение отказоустойчивости при передаче данных по виртуальным каналам 323 в случае отказа одной или нескольких физических линий передачи данных или коммутаторов за счёт автоматического перестроения маршрута виртуального канала (323).

Функции, обеспечиваемые коммутаторами:

- в некоторых вариантах осуществления функции интегрированной модели обслуживания QoS (гарантированную пропускную способность);

- в некоторых вариантах осуществления функции дифференцированной модели обслуживания QoS (обслуживание на основе разделения трафика по классам);

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

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

Автоматическое создание виртуальных каналов 323 (функции централизованного управления) обеспечивается выполнением REST API запроса (363) к контроллеру ПКС 313. В некоторых вариантах осуществления API запрос (363) на создание виртуального канала (323) должен включать идентификаторы коммутаторов и интерфейсов начала и конца маршрута, моменты времени начала и завершения существования виртуального канала (323), признак принадлежности виртуального канала (323) арендатору и признак трафика, попадающего в виртуальный канал (323).

В некоторых вариантах осуществления в качестве признака трафика, попадающего в виртуальный канал (323), могут использоваться поля заголовка сетевого кадра (L2), на основе которых коммутатором поддерживается маршрутизация, например, MAC destination, MAC source, IEEE 802.1Q tag и/или Ethertype. В некоторых вариантах осуществления в качестве признака трафика, попадающего в виртуальный канал (323), могут использоваться поля заголовка сетевого пакета (L3), на основе которых коммутатором поддерживается маршрутизация, например, на основе полей version, type of service, time to live, protocol, source ip address, destination ip address, ip options полей заголовка пакета IPv4. В некоторых вариантах осуществления в качестве признака трафика, попадающего в виртуальный канал (323), могут использоваться поля заголовка транспортного уровня (L4), на основе которых коммутатором поддерживается маршрутизация, например, source port, destination port, ACK, PSH, RST, SYN, FIN протокола TCP, source port, destination port протокола UDP. Также, в некоторых вариантах осуществления в качестве признака трафика, попадающего в виртуальный канал (323), могут использоваться другие поля пакетов других протоколов или их комбинации, на основе которых коммутатором поддерживается маршрутизация.

Выполнение запросов к контроллеру ПКС 313 на создание виртуального канала (323) передачи данных в варианте с применением протокола NETCONF вызывает выполнение серии NETCONF запросов (333) от контроллера ПКС 313 к подконтрольным коммутаторам. В зависимости от признака трафика, попадающего в виртуальный канал (323) и выбранной модели QoS, тип и последовательность выполняемых запросов могут отличаться. Например, в некоторых вариантах осуществления для обеспечения гарантированной полосы пропускания виртуального канала (323) на каждом коммутаторе построенного маршрута может быть выполнен (являющийся для этого достаточным) запрос по настройке фильтра, отделяющего выбранный трафик и запрос по настройке шейпера (от англ. traffic shaping), осуществляющего ограничение пропускной способности для выбранного трафика. Гарантию требуемой пропускной способности виртуального канала обеспечивает управляющее приложение 404 на основе записей базы данных TED 414 с применением в разных вариантах осуществления как типовых (алгоритмы Дейкстры, Беллмана-Форда и т.п.), так и новых (Maximally Redundant Trees) алгоритмов маршрутизации, как и с помощью алгоритмов, которые могут быть разработаны поздней, в зависимости от применяемого в контроллере ПКС. После выполнения запросов коммутаторы на маршруте прохождения данных между ЦОД настроены для передачи трафика между ЦОД (как показано на ФИГ. 3), в базу данных TED (в графе, соответствующем топологии связей между коммутаторами и пропускной способности линий) добавляется запись о маршруте виртуального канала и занятой им полосе пропускания. В некоторых вариантах осуществления схема базы данных TED может соответствовать приведенной на ФИГ. 5.

На ФИГ. 5 показан вариант схемы базы данных TED, согласно одному из вариантов осуществления настоящего технического решения. В этом варианте осуществления база данных TED состоит из таблиц: таблица, содержащая список арендаторов виртуальных каналов «holder_tbl» 505; таблица, содержащая список виртуальных каналов «channel_tbl» 515; таблица, содержащая список признаков трафика, попадающего в виртуальный канал «properties_tbl» 525; таблица, содержащая список коммутаторов «switch_tbl» 535; таблица, содержащая список интерфейсов коммутаторов «interfaces_tbl» 545; таблица, содержащая список маршрутов виртуальных каналов «hop_tbl» 555. Таблицы на схеме базы данных TED связаны между собой по ключевым полям (по уникальным идентификаторам записей).

В приведенном на ФИГ. 5 варианте осуществления базы данных TED, запись об участке маршрута виртуального канала может иметь вид, приведенный в таблице 1.

Таблица 1. Пример записи об участке маршрута виртуального канала базы данных TED.

hop_ident	7
channel_ident	2
hop_number	0
switch_dpid	00:1f:d0:00:ba:9b
switch_prev_dpid	null
switch_next_dpid	00:1f:d0:00:ba:9c
switch_interface_in	ge-0/0/3.1
switch_interface_out	ge-0/0/0.1
switch_state	TRUE

В этом примере запись об участке маршрута виртуального канала сообщает что: уникальный идентификатор этой записи имеет значение «7»; идентификатор виртуального канала, к которому относится запись равен «2»; порядковый номер участка маршрута «0»; идентификатор коммутатора «00:1f:d0:00:ba:9b»; идентификатор предыдущего коммутатора «null»; идентификатор следующего коммутатора «00:1f:d0:00:ba:9c»; данные виртуального канала поступают с интерфейса «ge-0/0/3.1»; данные виртуального канала маршрутизируются на интерфейс «ge-0/0/0.1»; значение поля switch_state, установленное в «TRUE» говорит о том, что настройка коммутатора для маршрутизации данных виртуального канала выполнена.

Таблица 2. Пример выборки о маршруте созданного виртуального канала из базы данных TED.

hop_ident	7	8	9	10
channel_ident	2	2	2	2
hop_number	0	1	2	3
switch_dpid	00:1f:d0:00:ba:9b	00:1f:d0:00:ba:9c	00:1f:d0:00:ba:9d	00:1f:d0:00:ba:9e
switch_prev_dpid	null	00:1f:d0:00:ba:9b	00:1f:d0:00:ba:9c	00:1f:d0:00:ba:9d
switch_next_dpid	00:1f:d0:00:ba:9c	00:1f:d0:00:ba:9d	00:1f:d0:00:ba:9e	null
switch_interface_in	ge-0/0/3.1	ge-0/0/0.1	ge-0/0/0.1	ge-0/0/2.1
switch_interface_out	ge-0/0/0.1	ge-0/0/2.1	ge-0/0/2.1	ge-0/0/3.1
switch_state	TRUE	TRUE	TRUE	TRUE

По завершении времени существования виртуального канала или по запросу (363) контроллер ПКС 313 удаляет хранящуюся на коммутаторах информацию о маршрутизируемых между ЦОД виртуальных каналах. Какая именно информация о маршрутизируемых между ЦОД виртуальных каналов удаляется из конфигурации коммутаторов зависит от признака трафика, попадающего в виртуальный канал и, выбранной модели QoS. Путём направления коммутаторам серии NETCONF запросов выполняется изменение конфигурации коммутаторов и, таким образом, трафик туннелей между ЦОД перестаёт передаваться, запись о маршруте и полосе виртуального канала в базе данных TED удаляется. Тип и последовательность запросов может отличаться в зависимости от признака трафика, попадающего в виртуальный канал и выбранной модели QoS. В случае удаления записи арендатора выполняется удаление всех виртуальных каналов, сопоставленных с его идентификатором.

Отслеживание состояния и топологии связей домена подконтрольных коммутаторов, обеспечивающее функции централизованного управления, в разных вариантах осуществления может выполняться как с применением периодического опроса коммутаторов о соседних сетевых устройствах, так и (например, в варианте осуществления с применением протокола NETCONF) с применением механизма «подписки на события» (NETCONF Event Notifications, RFC5277, YANG Module for NETCONF Monitoring, RFC 6022; NETCONF Base Notifications, RFC 6470). Информацию о связях между сетевыми устройствами коммутатор может получать (в частности, запрашивать), например, с помощью одного из протоколов канального уровня, таких как LLDP (Link Layer Discovery Protocol, IEEE 802.1ab), в зависимости от поддерживаемых коммутаторами.

Построение и перестроение маршрутов виртуальных каналов, обеспечивающее функции управляющего приложения 404, в разных вариантах осуществления может выполняться с применением как типовых (алгоритмы Дейкстры, Беллмана-Форда и т.п.), так и новых (Maximally Redundant Trees) алгоритмов маршрутизации, а также алгоритмов, которые могут быть разработаны поздней, в зависимости от применяемого в контроллере ПКС 313.

Моменты времени начала и завершения существования виртуальных каналов с заданным периодом отслеживает планировщик контроллера ПКС 313. В разных вариантах осуществления функции планировщика могут обеспечиваться, например, API вызовами управляющего приложения 404 к операционной системе контроллера ПКС 313 или иначе. По наступлении моментов начала или завершения существования выполняется RPC вызов на создание или удаление виртуальных каналов. Отслеживание моментов времени начала и завершения обеспечивают функции управляющего приложения 404.

Построение и перестроение маршрута с учетом признака привилегированного режима обслуживания каналов арендатора, выполняется управляющим приложением 404 контроллера ПКС 313, обеспечивает функции управляющего приложения 404. В некоторых случаях при поступлении запроса на создание виртуального канала управляющее приложение 404 может выполнить перестроение маршрутов всех виртуальных каналов, например, в соответствие оптимизирующего алгоритма маршрутизации, описанного ниже. Признак привилегированного режима обслуживания может определять порядок построения маршрутов. Признак привилегированного режима обслуживания содержится в базе данных TED 414 таблице «holder_tbl» (505), поле «holder_privilege». В случае если построение или перестроение маршрутов виртуальных каналов 605, 614 ограничено пропускной способностью линии связи (интерфейсов коммутатора) 607, то маршрутизация виртуальных каналов 611, 610 будет выполнена с учётом признака привилегированного режима обслуживания, и, например, API вызов на создание виртуального канала (363) для виртуального канала 2 (610, 614) может быть отклонен или маршрутизация виртуального канала 2 (610, 614) может быть перепланирована на другое время, как показано на ФИГ. 6.

На ФИГ. 6 показан пример случая превышения пропускной способности интерфейса: управляющее приложение контроллера ПКС обрабатывает запросы на создание виртуального канала_1 605, 611 с пропускной способностью 300 мб/с и виртуального канала_2 614, 610 с пропускной способностью 750 мб/с. Согласно топологии, указанной на ФИГ. 6 маршрут виртуального канала_1 605, 611 проходит через коммутатор 1 603, линию связи 604, коммутатор 2 606, линию связи 607 и коммутатор 3 609, маршрут виртуального канала_2 614, 610 проходит через коммутатор 4 612, линию связи 613, коммутатор 2 606, линию связи 607 и коммутатор 3 609. Пропускная способность линий связи и интерфейсов коммутаторов 1000 мб/с. Таким образом суммарная пропускная способность запрошенных виртуальных каналов 611, 610 на участке маршрута коммутатор 2 606 – коммутатор 3 609 превышает пропускную способность линии связи 607.

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

Балансировка нагрузки с автоматическим перестроением маршрутов виртуальных каналов в сети подконтрольных коммутаторов, обеспечивающая функции управляющего приложения 404, осуществляется в соответствии с выстроенным графом топологии и пропускной способности линий связи между коммутаторами, таблицей маршрутов существующих виртуальных каналов (Таблица 2), занимающих часть общей пропускной способности сети подконтрольных коммутаторов и остаточным графом, который складывается из графа топологии и пропускной способности линий связи и таблицы маршрутов существующих виртуальных каналов за счёт оптимизации маршрутов при поступлении новых запросов на создание виртуальных каналов, в частности, посредством использования оптимизирующего алгоритма маршрутизации. В некоторых вариантах осуществления за основу оптимизирующего алгоритма маршрутизации берется идея поиска дополняющих путей с заданной пропускной способностью из метода масштабирования потока. Так, осуществляется поиск дополняющих путей с заданной пропускной способностью из метода масштабирования потока. Если для нового запроса на создание виртуального канала не удается построить маршрут в остаточном графе сети подконтрольных коммутаторов, то маршрут ищется с использованием потенциальных ребер. Потенциальным ребром называется ребро, задействованное в маршруте проложенного виртуального канала и имеющее пропускную способность этого виртуального канала. На маршруте виртуального канала между одной и той же парой соседних вершин в графе топологии связей может быть одновременно использовано остаточное и потенциальное ребро, чтобы удовлетворить требование по пропускной способности. Если в маршруте для нового запроса задействовано потенциальное ребро, то осуществляется (необходимо) перестроение маршрутов соответствующих виртуальных каналов. Наряду с этим, в частном случае, можно рассматривать перестроение маршрута виртуального канала как поступление нового запроса, поэтому может быть использован этот же алгоритм для задачи перестроения маршрута, но с фиксированными маршрутами для уже рассмотренных виртуальных каналов. Так как перестроение маршрута может затронуть рассмотрение большого количества виртуальных каналов, алгоритм имеет настраиваемый параметр «k» – максимальное количество виртуальных каналов, маршруты которых можно перестроить. При помощи указанного алгоритма может быть увеличено использование пропускной способности сети, в частности, поскольку динамическое перестроение маршрутов, в частном случае, может помочь в ситуации, когда отсутствует маршрут в остаточном графе сети.

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

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

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

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

В результате обработки запросов подконтрольными коммутаторами по маршруту транзита данных создаётся виртуальный канал для GRE-туннеля (L3) с идентификатором GREKEY 579, выполняющий передачу пакетных данных с ограничением пропускной способности 20 Мбит/с.

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

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

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

На ФИГ. 7 показан примерный вариант осуществления настоящего технического решения.

В шаге 705 коммутаторы, управляемые контроллером ПКС, выполняют обмен пакетами протоколов обнаружение соединения.

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

В частном случае информация для формирования первого набора данных задаётся статически.

В шаге 715 на основании первого набора данных контроллер ПКС формирует набор данных организации трафика, содержащий данные о топологии и ресурсах сети коммутаторов.

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

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

В шаге 725 контроллер ПКС формирует набор данных арендаторов виртуальных каналов, содержащий: идентификаторы арендаторов виртуальных каналов, идентификаторы виртуальных каналов и признак соответствия режиму обслуживания каналов арендатора.

В частном случае набор данных арендаторов виртуальных каналов сохраняется в формате базы данных арендаторов виртуальных каналов, размещённой локально или удалённо.

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

В частном случае запрос на формирование виртуального канала, в качестве информации о начале и завершении виртуального канала, содержит время существования виртуального канала.

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

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

В частном случае запрос на формирование виртуального канала, в качестве информации о начале и завершении виртуального канала, содержит максимальное значение объёма данных, переданных по виртуальному каналу.

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

В шаге 735 контроллер ПКС выполняет построение маршрута виртуального канала с учётом: признака соответствия режиму обслуживания каналов арендатора, ресурса пропускной способности домена коммутаторов, информации о начале и завершении виртуальных каналов и параметров QoS, запрошенных для виртуальных каналов.

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

В шаге 745 контроллер ПКС добавляет в набор данных арендаторов виртуальных каналов записи о принадлежности виртуального канала арендатору.

В шаге 750 контроллер ПКС выполняет серию запросов к коммутаторам для настройки коммутаторов по построенному маршруту виртуального канала с формированием, по меньшей мере одного виртуального канала по меньшей мере в одном направлении, где настройка включает правила обработки и маршрутизации трафика с учетом ресурса пропускной способности сети и параметров QoS.

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

В частном случае серия запросов от контроллера ПКС к коммутаторам является серией NETCONF запросов.

В частном случае серия запросов от контроллера ПКС к коммутаторам является серией RESTCONF запросов.

В частном случае для формирования контроллером ПКС запросов к коммутаторам применяются yang модели openConfig, yang модели, созданные производителем коммутаторов или yang модели, созданные третьими лицами.

В частном случае серия запросов от контроллера ПКС к коммутаторам является серией запросов ofConfig.

В частном случае серия запросов от контроллера ПКС к подконтрольным коммутаторам является серией openFlow запросов.

В шаге 755 в ответ на условие завершения виртуального канала контроллер ПКС по выполняет серию запросов к коммутаторам по построенному маршруту виртуального канала для удаления правил обработки и маршрутизации трафика виртуального канала.

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

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

В частном случае пропускная способность по маршруту виртуального канала обеспечивается за счет применения алгоритмов маршрутизации.

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

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

В частном случае функции контроллера ПКС дублируются дополнительным контроллером ПКС по принципу основного и резервного контроллера ПКС.

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

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

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

1. Способ формирования виртуального канала между центрами обработки данных (ЦОД) с использованием контроллера программно-конфигурируемой сети (ПКС), в котором:

- коммутаторы, управляемые контроллером ПКС, выполняют обмен пакетами протоколов обнаружение соединения;

- контроллер ПКС периодически выполняет опрос, заданных с помощью механизма межпроцессного взаимодействия, коммутаторов о существующих на коммутаторах интерфейсах, пропускной способности линий и о подключенных к их интерфейсам устройствах с формированием первого набора данных;

- на основании первого набора данных контроллер ПКС формирует набор данных организации трафика, содержащий данные о топологии и ресурсах сети коммутаторов;

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

- контроллер ПКС формирует набор данных арендаторов виртуальных каналов, содержащий: идентификаторы арендаторов виртуальных каналов, идентификаторы виртуальных каналов и признак соответствия режиму обслуживания каналов арендатора;

- контроллер ПКС с помощью механизма межпроцессного взаимодействия получает запрос на формирование виртуального канала, содержащий, по меньшей мере: данные о точках входа трафика виртуального канала, признак трафика, попадающего в виртуальный канал, информацию о начале и завершении виртуального канала, данные о принадлежности виртуального канала арендатору и данные о требуемых параметрах QoS;

- контроллер ПКС выполняет построение маршрута виртуального канала с учётом: признака соответствия режиму обслуживания каналов арендатора, ресурса пропускной способности домена коммутаторов, информации о начале и завершении виртуальных каналов и параметров QoS, запрошенных для виртуальных каналов;

- контроллер ПКС добавляет в набор данных организации трафика записи о виртуальном канале: маршруте виртуального канала, признаке трафика, попадающего в виртуальный канал, информацию о начале и завершении виртуального канала и занятой виртуальным каналом пропускной способности;

- контроллер ПКС добавляет в набор данных арендаторов виртуальных каналов записи о принадлежности виртуального канала арендатору;

- контроллер ПКС выполняет серию запросов к коммутаторам для настройки коммутаторов по построенному маршруту виртуального канала с формированием, по меньшей мере одного виртуального канала по меньшей мере в одном направлении, где настройка включает правила обработки и маршрутизации трафика с учетом ресурса пропускной способности сети и параметров QoS;

- в ответ на условие завершения виртуального канала контроллер ПКС выполняет серию запросов к коммутаторам по построенному маршруту виртуального канала для удаления правил обработки и маршрутизации трафика виртуального канала.

2. Способ по п.1, в котором информация для формирования первого набора данных задаётся статически.

3. Способ по п.1, в котором запрос на формирование виртуального канала, в качестве информации о начале и завершении виртуального канала, содержит время существования виртуального канала.

4. Способ по п.1, в котором запрос на формирование виртуального канала, в качестве информации о начале и завершении виртуального канала, содержит максимальное значение объёма данных, переданных по виртуальному каналу.

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

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

7. Способ по п.1, в котором признаком трафика, попадающего в виртуальный канал, являются поля заголовка пакетных данных второго уровня модели сетевого взаимодействия OSI/ISO, на основе которых коммутатором поддерживается маршрутизация; или признаком трафика являются поля заголовка третьего уровня модели сетевого взаимодействия OSI/ISO, на основе которых коммутатором поддерживается маршрутизация; или признаком трафика являются поля заголовка четвертого уровня модели сетевого взаимодействия OSI/ISO, на основе которых коммутатором поддерживается маршрутизация.

8. Способ по п.1, в котором пропускная способность по маршруту виртуального канала обеспечивается за счет применения алгоритмов маршрутизации.

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

10. Способ по п.1, в котором при поступлении запроса на создание виртуального канала контроллер ПКС выполняет поиск оптимального распределения нагрузки (балансировку нагрузки) согласно применяемому алгоритму маршрутизации с использованием интервала времени существования виртуальных каналов и признака режима обслуживания каналов арендатора, определяющего порядок построения маршрутов.

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

12. Способ по п.1, в котором при построении маршрутов виртуальных каналов признак приоритетного режима обслуживания виртуальных каналов используется для вытеснения из графа топологии виртуальных каналов арендаторов.

13. Способ по п.1, в котором набор данных организации трафика сохраняется в формате базы данных организации трафика, размещённой локально или удалённо.

14. Способ по п.1, в котором набор данных арендаторов виртуальных каналов сохраняется в формате базы данных арендаторов виртуальных каналов, размещённой локально или удалённо.

15. Способ по п.1, в котором функции контроллера ПКС дублируются дополнительным контроллером ПКС по принципу основного и резервного контроллера ПКС.

16. Способ по п.1, в котором создание виртуального канала инициируется с применением механизма 'подписки на события', при котором коммутаторы информируют контроллер ПКС о поступлении данных, имеющих заданный признак, при поступлении которых коммутатор оповещает контроллер ПКС, а контроллер ПКС на основе заданных параметров создаёт для этого трафика виртуальный канал.

17. Способ по п.1, в котором серия запросов от контроллера ПКС к коммутаторам является серией NETCONF запросов.

18. Способ по п.1, в котором серия запросов от контроллера ПКС к коммутаторам является серией RESTCONF запросов.

19. Способ по п.1, в котором для формирования контроллером ПКС запросов к коммутаторам применяются yang модели openConfig, yang модели, созданные производителем коммутаторов или yang модели, созданные третьими лицами.

20. Способ по п.1, в котором серия запросов от контроллера ПКС к коммутаторам является серией запросов ofConfig.

21. Способ по п.1, в котором серия запросов от контроллера ПКС к подконтрольным коммутаторам является серией openFlow запросов.

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