SDN & NFV і при чому тут Хмари

Абревіатури SDN і NFV останнім часом звучать все частіше і звучать разом. У тендерах оператори зв'язку вимагають від виробників обов'язкової підтримки SDN і NFV, оскільки впевнені, що ці технології надають позитивний вплив на OPEX, CAPEX і TTM. Швидкий серфінг інтернету показує, що SDN — це Software-Defined Networking, а NFV — це Network Functions Virtualization. Обидві технології пов'язані з віртуалізацією і з мережами, тобто на перший погляд складається враження, що вони дуже схожі, якщо не одне і те ж. Давайте розбиратися, чи це так насправді! Перевірка з Google Trend спочатку підтверджує гіпотезу: тренд запиту «SDN and NFV» починається в 2013 році:



Але далі виявляється, що тема Програмно-визначається мережі починає підніматися набагато раніше — з 2008:



Починаємо розбиратися.

SDN — проблема і рішення

SDN народився в надрах Цодів. Якщо в двох словах, то проблема з мережею була наступна.

Класичний комутатор маршрутизує потоки трафіку за правилами, які необхідно вказати в самому комутаторі. Якщо комутаторів 10-20, то їх ще можна налаштувати вручну, а в ЦОДах з сотнями і тисячами комутаторів завдання перетворювалася в нерешаемую. Спрощена схема, що ілюструє життя до SDN:



Тобто щоб потік даних маршрутизировался через 3 комутатора, необхідно сконфігурувати кожен комутатор окремо. Що ж пропонує SDN? З сучасної точки зору на архітектуру — нічого нового: поділ на верстви і стандартизацію інтерфейсів:


У нижньому шарі «Інфраструктура» розташовуються прості комутатори, які вміють тільки маршрутизувати трафік. Таблиці маршрутизації розливаються з центрального контролера, розташованого в шарі «Управління». Для цього використовується стандартний протокол «OpenFlow». OpenFlow — стандарт, який з 2011 року розвиває організація Open Networking Foundation (ONF). А перша версія стандарту з'явилася в 2008, стає зрозуміло, звідки зростання тренду «Програмно-визначаються мережі». На верхньому шарі «Додатки» для управління, конфігурування та моніторингу. API до нього не стандартизовано. Таким чином, конфігурування комутаторів проводиться централізовано, конфігурації розливаються автоматично — перемога над OPEX і ТТМ. Комутатори стали дешеві і стандартні — економимо CAPEX. Для стандартних Цодів – велика перемога, але для операторів зв'язку щастя не настав.

NFV — проблема і рішення

У операторів є ще проблема – велика кількість і різноманітність мережевих функцій, приклади загальновідомих: NAT, firewall, DPI. Кожен виробник поставляє свої програми на своєму залозі, і в результаті у операторів накопичується зоопарк пропрієтарного заліза, який знову ж таки треба синхронно конфігурувати при введенні нових комерційних ініціатив для абонентів. Тобто це та ж проблема з комутаторами, але на більш високому рівні. Що ж придумали оператори? Вони об'єдналися і під егідою ETSI (Європейський Інститут Телекомунікаційних Стандартів) випустили стандарт ETSI NFV. Картинка з стандарту, ілюструє проблему та рішення:



Перша версія стандарту ETSI NFV вийшла в 2012 (ага, ось звідки Google Trend зростає). Подивимося уважніше на стандарт, спрощена схема з документа «ETSI GS NFV-EVE 003», ілюструє архітектуру:



Давайте розбиратися. Праворуч — NFV MANO (Management and Orchestration ) — це тільки та частина, яку специфікує ETSI. Той, що зліва — лише рекомендації. В принципі ця частина може відрізнятися у різних виробників, але, як показує практика, все вписують свої рішення у цю загальну схему.

Зверху OSS/BSS стандартні системи операторів зв'язку — біллінг, чарджинг, тарифікація, CRM, самообслуговування абонентів і т. д. Вони як були, так і залишаються, і пов'язані з NFV тільки одним специфицированным інтерфейсом (Os-Ma). Про функції інтерфейсів детальніше я краще розповім в іншій статті, зараз же треба зрозуміти загальну картину. Нижче розташовані VNF (Virtualized Network Functions) — це як раз мережеві функції, які тепер працюють на стандартному обладнанні у віртуальному середовищі. EM (Element Management) — управління мережними елементами. EM забезпечує для VNF функціональність FCAPS (fault, configuration, administration, performance, security). Не дуже зрозуміло, навіщо взагалі були введені в стандарт EM? Думаю, для того, щоб не виносити ці функції у OSS/BSS, щоб не лякати операторів необхідністю доробок у цьому контурі. Керують VNF — VNF Managers (VNFM).

Передбачається, що VNF Managers повинні реалізовуватися виробниками VNF, т. к. виробники найкраще знають, як управляти своїми VNF.

Під шаром VNF розташована NFV Infrastructure (NFVI) — стандартне (COTS) обладнання з шаром гіпервізора і віртуалізації. Обладнанням і віртуалізацією управляє VIM (Virtualized Infrastructure Manager). Виробники систем віртуалізації взялися саме за нижній шар. Linux, OpenStack ще кілька десятків компаній організували проект Open Platform for NFV (OPNFV). VMWare, зрозуміло, реалізувала свою альтернативу vCloud NFV:



Керує всім цим господарством головний елемент NFV — NFVO (NFV Orchestrator). Які виробники реалізують елементи NFV Orchestrator? На сьогоднішній день також є дві альтернативи. ETSI оголосив про запуск проекту – Open Source MANO (OSM) і компанія Cloudify пропонує свою чесну «pure-play cloud orchestration platform», яка працює як з OpenStack, так і з VMWare:



Ну все з NFV, начебто, розібралися, але поряд з перевагами NFV на сьогоднішній день бачимо і ряд проблем:

  • Тільки два виробники пропонують рішення для VIM: OpenStack і VMWare
  • Не виходить на системі виртуализациии IT побудувати NFV. Спочатку думали, що беремо систему віртуалізації IT, трохи докручиваем, і виходить NFV. Але завдання NFV дуже специфічні. Наприклад, розгортання на bare metal серверах, необхідність розподіленої структури, більша кількість WAN лінків і зовнішнього трафіку
  • Більш високі вимоги до обладнання, продуктивності, до затримки відгуку
  • Конфігурування NVF не вкладається в шаблони
  • не Можна уникнути vendor-lock, навіть використовуючи OpenStack т. к. потрібна технічна підтримка, а OpenStack кожен виробник точить під себе
Таким чином, бачимо, що стандартом NFV є куди рости! Зачекайте, а де тут SDN?

SDN і NFV

SDN забезпечує для NFV віртуалізацію мережних інтерфейсів і мережеву зв'язність для VNF. Візьмемо для прикладу елементи з OpenStack: віртуальний комутатор «Open vSwitch» і SDN контролер «Open Daylight». Помістимо їх в NFV, і тепер зрозуміло, де тут SDN:



Чи може існувати SDN без NFV? Звичайно, може — це ми бачили на початку статті. Чи може існувати NFV без SDN — відповідь той самий, але при цьому налаштувати мережеві інтерфейси і зв'язність потрібно буде вручну, тобто дійсно спостерігаємо синергію SDN і NFV. Стало зрозуміло, що це ніяк не синоніми, а дві великі різниці!

Таким чином, поки що спостерігаємо за розвитком стандарту і з нетерпінням чекаємо реальних success stories!

Хмари

А при чому тут хмари? Про це в наступній статті «Хмари як любов».

Трохи посилань

стаття

  • Хмари як любов
  • Інтерфейси і функціональні блоки NFV
  • Виробники і кейси використання SDN і NFV
  • Готуємо NFV в домашніх умовах
  • BigData і NFV — чи є зв'язок?
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.