Виртуализация сетевых функций(NFV)

⇐ ПредыдущаяСтр 6 из 9Следующая ⇒

Суть идеи виртуализация сетевых функций – NFV – в новом подходе к построению сетевой архитектуры, при котором на унифицированной физической среде работают программные приложения, реализующие всевозможные сетевые функции. NFV позволяет операторам разворачивать сетевые решения (DPI, NAT, Firewall и т.д.) как программные приложения, а не как отдельные сетевые устройства.

Работа приложений NFV и сама реализация виртуальных функций возможна на высокопроизводительных сетевых платформах и серверах, которые расположены в центрах обработки данных, сетевых узлах и оборудовании клиентов.

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

Взаимосвязь с концепцией SDN

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

Самым важным отличием NFV от SDN является конечная цель концепции. Если в NFV планируется взять конкретные сетевые функции и реализовать их программно, а затем управлять ими как программными объектами, то технология программно- коммутируемых сетей – это идеология работы всей сети, где все управление и ответственность за принятие решений (маршрутизация, коммутация и т.д.) вынесены на отдельный централизованный уровень. NFV – это конкретные программные компоненты, которые реализуют конкретные сетевые функции, а SDN – идеология работы всей сети и взаимодействия ее функциональных уровней.

Вывод

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

В следующей главе будут представлены алгоритмы модернизации традиционной сети в программно-коммутируемую сеть.

Введение

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

1) В начале в документации должно быть изложено:

¾ Поведение сети с разработанными инструкциями и рекомендациями.

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

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

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

2) На основе стандарта OpenFlow должны быть отражены следующие требования к программному обеспечению:

¾ Целевая сеть должна иметь возможность дополнения функционала благодаря Application Programming Interfaces (API).

¾ Целевая сеть должна поддерживать динамические обновления программного обеспечения с минимальными прерываниями работы, а также автоматический возврат в случае неверной установки (rollback).

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

¾ Целевая сеть должна быть реализована инструментами, программным обеспечением и симуляторами. Или существующие инструменты должны демонстрировать работу целевой сети, или альтернативные инструменты, или должна быть полная ясность в операционной работе.

¾ Исходной сети может потребоваться подготовка, и необходимо ее трансформировать в промежуточное состояние, из которого миграция сети будет проходить безопасно.

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

Подходы миграции

Есть два подхода по осуществлению миграции: [9]

1)
Первый подход изображен на рисунке. Это прямой метод обновления существующего сетевого оборудования с OpenFlow Agents (оборудование, которое поддерживает программное обеспечение OpenFlow) и вывод управление в OpenFlow контроллер и конфигуратор.

Рис. 16. Прямое обновление.

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

Рис. 17. Поэтапная миграция.

3)
Еще существует частичный метод миграции в рамках сетевых устройств, где OpenFlow поддерживается между уровнем доступа и метро уровнем, или внедрение программно-коммутируемой сети в пределах сети, где есть поддержка OpenFlow, но в соседних зонах ее нет.

Рис. 18. Метод частичной миграции, где соседние устройства не поддерживают OpenFlow.

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

Процесс миграции дополнительно включает в себя:

1)
включение контроллеров поверх сети

Рис. 19. Внедрение устройств поверх сети.

2) иерархичное управление OpenFlow

Рис. 20. Иерархичное управление.

⇐ Предыдущая 1 2 3 4 567 8 9 Следующая ⇒