Віртуалізація функцій мережі

Віртуалізація функцій мережі (також віртуалізація мережевих функцій, англ. network function virtualization, NFV)[1] є концепцією мережевої архітектури, яка використовує технології віртуалізації інформаційних технологій для віртуалізації цілих класів функцій мережевих вузлів[en] у складові блоки, які можуть з'єднуватись або об'єднуватись у послідовність, створюючи послуги зв'язку.

Хоча віртуалізація функцій мережі має багато спільного з традиційними методами серверної віртуалізації, які використовуються великими корпораціями, вона також має деякі відмінності. Замість того, щоб мати власні апаратні засоби для кожної функції мережі, функції віртуалізованої мережі, або VNF, на додаток до стандартних серверів, комутаторів та пристроїв зберігання даних, можуть складатися з однієї або декількох віртуальних машин, які працюють з різними програмами та процесами, та навіть інфраструктури хмарних обчислень.

Наприклад, віртуальний контролер границі сеансу[en] може бути розгорнутий для захисту мережі без типових витрат і складності отримання та встановлення фізичних блоків мережевого захисту. Інші приклади функцій віртуалізованих мереж включають віртуалізовані балансери навантаження[en], брандмауери, системи для виявлення вторгнень та оптимізації WAN[en].[2]

Передумови ред.

Розробка продукту в галузі телекомунікацій традиційно вимагала дотримання строгих стандартів стабільності та якості. Це відображує використання терміну операторський клас[en] якості яким позначалось обладнання, яке демонструвало цю надійність.[3] Хоча ця модель працювала в минулому, вона призвела до тривалих циклів розробки продукту, повільних темпів розвитку та зав'язки на конкретних апаратних засобах, наприклад, інтегральних схем (ASIC). Через значне зростання конкуренції у сфері комунікаційних послуг великі організації, які швидко розвиваються та працюють у широкому масштабі у публічному Інтернеті (такі як Google Talk, Skype, Netflix) спонукали постачальників послуг шукати способи зрушити статус-кво.

Історія ред.

У жовтні 2012 року «Віртуалізація мережевих функцій»[4] — група, яка займалась специфікацією, опублікувала білу книгу[5] про програмно-конфігуровані мережі (SDN) та протокол OpenFlow[en] на конференції в Дармштадті, Німеччина. Група входить до складу Європейського інституту телекомунікаційних стандартів (ETSI), складалася з представників телекомунікаційної галузі з Європи та представників які були за її межами.[6][7]

З моменту публікації Білої книги, група підготувала декілька матеріалів, які більш глибоко висвітлюють цю галузь, включаючи стандартне визначення термінології[8] та випадки використання NFV. Ці матеріали діють як посилання для постачальників і операторів, які розглядають можливість перейти до віртуалізації мережі.

Каркас ред.

Каркас NFV складається з трьох основних компонентів:[9]

  1. Функції віртуалізованої мережі (VNF) є програмними реалізаціями мережевих функцій, які можуть бути розгорнуті на інфраструктурі віртуалізованих мережевих функцій (NFVI).[10]
  2. Інфраструктура віртуалізованих мережевих функцій (NFVI) є сукупністю всіх апаратних і програмних компонентів, з яких складається середовище, де розгортаються VNF. Інфраструктура NFV може знаходитись у декількох місцях. Мережа, що забезпечує зв'язок між цими місцями, розглядається як частина інфраструктури NFV.
  3. Компонент архітектурного управління та оркестрації[en] віртуалізованих мережевих функцій (NFV-MANO Architectural Framework) — це збірник всіх функціональних блоків, сховищ даних, які ці блоки використовують, опорних точок та інтерфейсів, за допомогою яких ці функціональні блоки обмінюються інформацією з метою управління та оркестрації NFVI та VNF.

Будівельний блок для NFVI і NFV-MANO є NFV платформа. У разі NFVI, вона складається з віртуальних та фізичних ресурсів обробки та зберігання, програмного забезпечення для їх віртуалізації. У разі NFV-MANO, вона складається з менеджерів VNF і NFVI та програмного забезпечення для віртуалізації, яке працює на апаратному контролері. Платформа NFV виконує такі функції як: керування та моніторинг компонентів платформи, відновлення після збоїв та забезпечення безпеки  — усе що необхідно для мережі публічних операторських класів.

Практичні аспекти ред.

Постачальник послуг, який використовує NFV, реалізує одну або більше функцій віртуалізованої мережі або VNF. VNF сам по собі не надає клієнту провайдера послугу чи якийсь продукт. Для того, аби збудувати складніші послуги використовується поняття ланцюг послуг, де кілька послідовних VNF використовуються для надання послуги.

Ще одним аспектом важливим для NFV є процес оркестрування. Для побудови високонадійних послуг, які масштабуються, NFV вимагає, щоб мережа могла створювати, контролювати, відновлювати екземпляри VNF, і (найважливіше для бізнесу постачальника послуг) стягувати гроші за надані послуги. Ці атрибути, які називаються характеристиками операторського класу[11], віддані рівню оркестрації, для того аби забезпечити високу доступність і безпеку, а також низькі експлуатаційні витрати та витрати на обслуговування мережі. Важливо те, що рівень оркестрації повинен мати можливість керувати VNF, незалежно від базової технології яку використовує VNF. Наприклад, рівень оркестрування повинен мати можливість керувати SBC[en] VNF від постачальника X, який працює на VMware vSphere так само, як і IMS VNF від постачальника Y, який працює на KVM.

Розподілення NFV ред.

Початкова ідея NFV полягала в тому, що можливості віртуалізації повинні бути реалізовані в центрах обробки даних. Цей підхід працює у багатьох, та не в усіх випадках. NFV передбачає і заохочує до гнучкості щодо фізичного розташування віртуалізованих функцій.

В ідеалі, таким чином, віртуалізовані функції повинні бути розташовані там, де вони є найбільш ефективними і дешевими. Це означає, що постачальник послуг повинен вільно розташовувати NFV у всіх можливих місцях, починаючи від центру обробки даних, продовжуючи вузлом мережі та закінчуючи приміщенням клієнта. Цей підхід, відомий як розподілення NFV, заохочувався з самого початку, коли NFV розроблявся і стандартизувався, є одним з найважливіших у недавно випущених документах NFV ISG.[12]

У деяких випадках для постачальника послуг є очевидні переваги розташувати віртуалізовані функціональності в приміщеннях клієнта. Ці переваги варіюються від економії до продуктивності, а також від можливості функцій бути віртуалізованою.[13]

Перше підтвердження концепції (PoC)[en], затверджене ETSI NFV ISG, D-NFV було розроблено Cyan, Inc.[en], RAD[en], Fortinet та Certes Networks, за підтримки CenturyLink[en] у Чикаго у червні 2014 року. Воно базувалось на спеціалізованому обладнанні D-NFV компанії RAD, яке працювало під керуванням Fortinet Firewall наступного покоління (NGFW) і віртуальним шифрувальним / дешифрувальним механізмом Certes Networks (Virtual Network Functions (VNF)) з системою Cyan's Blue Planet, яка керувала всією системою.[14] Модуль комунікації у мережі[en] 2 рівня / 3 рівня (NTU)[en] D-NFV RAD, оснащений модулем сервера D-NFV X86, який функціонував як рушій віртуалізації на стороні клієнта, став комерційно доступним до кінця цього місяця.[15] Протягом 2014 року RAD також організував альянс D-NFV — систему постачальників і міжнародних системних інтеграторів[en], які спеціалізуються на нових програмах NFV.[16]

Переваги модульності NFV ред.

При проектуванні та розробці програмного забезпечення з функціональністю VNF, постачальники можуть розділити це програмне забезпечення на компоненти (рівень програмної архітектури) та упаковувати ці компоненти в одне або більше зображень (рівень розгортки програмного забезпечення). Ці програмні компоненти, визначені виробником, називаються компонентами VNF (VNFCs). VNF складаються з одного або більше VNFC. Передбачається, що ці компоненти не втрачають спільність, та компоненти VNF відображаються до VM зображень як 1: 1.

VNFCs повинні мати можливість масштабуватись вертикально та / або горизонтально. Шляхом додавання гнучких (віртуальних) процесорів для кожного з компонентів VNFC, рівень керування мережею може масштабувати VNFC вгору (тобто масштабувати вертикально), для того щоб забезпечити необхідну пропускну здатність, продуктивність та масштабованість усієї системи або платформи. Аналогічно, рівень керування мережею може масштабувати компоненти вшир (тобто масштабувати горизонтально) шляхом активації ще декількох екземплярів VNFC на інших платформах таким чином, досягаючи необхідної продуктивності, не відмовляючись від інших переваг функцій VNFC.

Учасники таких архітектурних проектів вже впровадили принципи модульності NFV.[17]

Зв'язок з SDN ред.

Концепція SDN, або програмно-конфігурованих мереж пов'язані з NFV, але вони стосуються різних областей.[18] Віртуалізація функцій мережі (NFV) та Deep Packet Inspection (DPI) можуть ефективно доповнювати функції SDN.[19]

По суті, програмно-конфігуровані мережі (SDN) — це підхід до побудови мережевого обладнання та мережевого програмного забезпечення, яке відокремлює та абстрагує елементи цих систем. Він роз'єднує рівень управління та рівень даних один від одного, так що рівень управління знаходиться в одному місці, а компоненти комутації залишаються розподіленими. Контрольна площина взаємодіє як на північний інтерфейс[en], так і на південний інтерфейс[en]. У північному напрямку рівень управління забезпечує загальне, абстраговане управління мережею вищим рівням, таким як додатки та програми, які використовують його API. У південному напрямку рівень управління встановлює правила пересилання для рівня даних, використовуючи API фізичного пристрою мережевого обладнання, яке розподілене мережею.

Таким чином, NFV не залежить від концепцій або самого SDN. Цілком можливо реалізувати функцію віртуалізованої мережі (VNF) як автономний об'єкт, використовуючи чинні мережеві та оркеструвальні стандарти. Проте, існують переваги використання концепції програмно-конфігурованих мереж для впровадження та управління інфраструктурою NFV, особливо для управління та оркестровання функцій віртуалізованих мереж, і саме тому розробляються мультивендорні платформи, які включають SDN і NFV, які працюють як одна система.[20]

Інфраструктура NFV потребує централізованої системи оркестрування та управління, яка приймає запити від операторів VNF та проводить необхідну обробку, зберігання та конфігурацію мережі, яка необхідна для введення в експлуатацію VNF. Після введення в експлуатацію VNF має здійснювати моніторинг місткості та використання VNF та при необхідності змінюватись.[21]

Всі ці функції можуть бути реалізовані за допомогою SDN. NFV можна вважати одним з основних випадків використання SDN у системах постачальників послуг. Також очевидно, що багато випадків використання SDN можуть включати поняття, ініційовані NFV. Наприклад, централізований контролер управляє розподіленою функцією пересилання пакетів, яка фактично може бути також віртуалізованою на чинному пристрої обробки або маршрутизації.

Вплив на промисловість ред.

NFV завоював популярність ще на початку свого становлення. Він має багато безпосередніх додатків, такі як віртуалізація мобільних базових станцій, платформа як послуга (PaaS), мережі доставлення контенту (CDN), фіксований доступ та домашні середовища.[22] Передбачається, що NFV буде мати ще значніші переваги. Очікується, що віртуалізація мережевих функцій, розгорнута на уніфікованому апаратному забезпеченні загального призначення, зменшить економічні та операційні витрати, а також час впровадження послуг та продуктів.[23][24] Багато великих постачальників мережевого обладнання оголосили про підтримку NFV.[25] Це збіглось з повідомленнями основних постачальників програмного забезпечення NFV, які створюють свої NFV продукти.[26][27]

Постачальники мережевого обладнання вдосконалюють технології віртуалізації, для того щоб використовувати їх переваги, досягти операторського класу, високої доступності[en], масштабованості, продуктивності та ефективного управління мережею.[28] Щоб мінімізувати загальну вартість володіння (ЗВВ), специфікації операторського класу повинні бути реалізовані максимально ефективно. Це вимагає від додатків NFV ефективно використовувати надлишкові ресурси для досягнення максимальної доступності (99,999 %),[29] та максимального обчислювального ресурсу без шкоди для продуктивності.

Платформа NFV є основою для розробки ефективних NFV-рішень операторського класу.[30] Це програмна платформа, яка працює на стандартному багатоядерному апаратному забезпеченні. Вона побудована з використанням програмного забезпечення з відкритим вихідним кодом, яке відповідає стандартам операторського класу. Програмне забезпечення платформи NFV відповідає за динамічне коригування системи після помилок та при зміні навантаження трафіку, таким чином забезпечуючи високу доступність. Існують численні ініціативи щодо уточнення, узгодження та розвитку можливостей стандартів NFV, таких як ETSI NFV Proof of Concept,[31] ATIS[32] Open Platform for NFV Project,[33] Carrier Network Virtualization Awards[34] та інші.[35]

VSwitch- це ключовий компонент платформи NFV, який відповідає за забезпечення зв'язку між віртуальними машинами та з зовнішньою мережею. Його продуктивність визначає пропускну здатність і економічну ефективність рішень NFV. Open vSwitch (OVS) має недоліки, які необхідно вирішити для задоволення потреб NFVI.[36] Постачальники NFV повідомляють про значні покращення продуктивності як для версій OVS, так і для Accelerated Open vSwitch (AVS).[37][38]

Віртуалізація також змінює вимоги до доступності, яка вимірюється у NFV додатках. Оскільки VNF замінюють традиційне обладнання, існує перехід від доступності на основі обладнання до доступності на основі сервісів.[39][40] Віртуалізація мережевих функцій розриває зв'язок з конкретним обладнанням, тому доступність визначається доступністю послуг VNF. Оскільки технологія NFV може віртуалізувати широкий діапазон мережевих функцій, кожна з яких має свій рівень доступності послуг, платформи NFV повинні підтримувати широкий діапазон варіантів відмовостійкості. Така гнучкість дозволяє CSPs оптимізувати свої NFV рішення для будь-яких вимог до доступності VNF.

Управління та оркестрування (MANO) ред.

ETSI вже вказала, що важливу частину контролю та оркестрації навколишнього середовища NFV можна автоматизувати. Існує окремий проект в межах NFV, в якому викладено, як потрібно контролювати та оркеструвати NFV. Його назва MANO.[41]

Дослідження продуктивності ред.

Нещодавні дослідження роботи NFV були зосереджені на пропускній здатності, затримці та джиттері віртуалізованих мережевих функцій (VNF). Також були проведені дослідження можливості масштабування NFV, а саме скільки VNF може підтримувати один фізичний сервер.[42]

Див. також ред.

Список літератури ред.

  1. Архівована копія. Архів оригіналу за 20 грудня 2018. Процитовано 14 травня 2019. 
  2. Network Functions Virtualisation (NFV); Use NFV is present and SDN is future.Cases. Архів оригіналу за 26 липня 2019. Процитовано 6 Червня 2014. 
  3. How Low-Cost Telecom Killed Five 9s in Cloud Computing. wired.com. Архів оригіналу за 8 лютого 2018. Процитовано 27 червня 2016. 
  4. Network Functions Virtualisation. ISG web portal. Процитовано 20 Червня 2013. 
  5. Network Functions Virtualization— Introductory White Paper. ETSI. 22 Жовтня 2012. Архів оригіналу за 4 квітня 2019. Процитовано 20 Червня 2013. 
  6. Ray Le Maistre (22 Жовтня 2012). Tier 1 Carriers Tackle Telco SDN. Light Reading. Архів оригіналу за 14 червня 2013. Процитовано 20 Червня 2013. 
  7. Latest Agenda at SDN & OpenFlow World Congress. Layer123.com. Архів оригіналу за 14 Жовтня 2012. Процитовано 20 Червня 2013. 
  8. Mulligan, Ultan. ETSI Publishes First Specifications for Network Functions Virtualisation. Архів оригіналу за 15 грудня 2017. Процитовано 5 Грудня 2013. 
  9. Network-Functions Virtualization (NFV) Proofs of Concept; Framework [Архівовано 20 грудня 2018 у Wayback Machine.], GS NFV-PER 002 v1.1.1 (2013-10),
  10. What is Network Function Virtualization (NFV). blog.datapath.io. Архів оригіналу за 1 лютого 2017. Процитовано 14 травня 2019. 
  11. Don't Confuse ‘High Availability’ with Carrier Grade [Архівовано 3 липня 2017 у Wayback Machine.], Embedded Community, Charlie Ashton, Квітень, 2014
  12. Tom Nolle (18 Вересня 2013). Is "Distributed NFV" Teaching Us Something?. CIMI Corporation's Public Blog. Архів оригіналу за 2 січня 2014. Процитовано 2 Січня 2014. 
  13. Carol Wilson (3 Жовтня 2013). RAD Rolls Out Distributed NFV Strategy. Light Reading. Архів оригіналу за 18 листопада 2018. Процитовано 2 Січня 2014. 
  14. 4 Vendors Bring Distributed NFV to BTE. Light Reading. 11 Червня 2014. Архів оригіналу за 20 вересня 2018. Процитовано 3 Березня 2015. 
  15. RAD launches customer-edge distributed NFV solution based on ETX NTU platform. Optical Keyhole. 16 Червня 2014. Архів оригіналу за 29 червня 2017. Процитовано 3 Березня 2015. 
  16. RAD adds new partners to D-NFV Alliance. Telecompaper. 9 Грудня 2014. Архів оригіналу за 11 серпня 2018. Процитовано 3 Березня 2015. 
  17. TMCnet News (26 Червня 2014). Qosmos Awarded a 2014 INTERNET TELEPHONY NFV Pioneer Award. TMC. Архів оригіналу за 8 липня 2018. Процитовано 26 Червня 2014. 
  18. William, Stalling (2016). Foundations of Modern Networking: SDN, NFV, QoE, IoT, and Cloud. Pearson Education. 
  19. Rowayda, A. Sadek (May 2018). An Agile Internet of Things (IoT) based Software Defined Network (SDN) Architecture. Egyptian Computer Science Journal. 
  20. Platform to Multivendor Virtual and Physical Infrastructure
  21. Liyanage, Madhusanka (2015). Software Defined Mobile Networks (SDMN): Beyond LTE Network Architecture. UK: John Wiley. с. 1–438. ISBN 978-1-118-90028-4. 
  22. Network Functions Virtualization (NFV) Use Cases [Архівовано 26 липня 2019 у Wayback Machine.], ETSI GS NFV 001 v1.1.1 (2013-10)
  23. What's NFV [Архівовано 26 липня 2014 у Wayback Machine.] — Network Functions Virtualization?, SDN Central
  24. Carrier Network Virtualization [Архівовано 31 жовтня 2013 у Wayback Machine.], ETSI news
  25. Openwave Exec Discusses the Benefits, Challenges of NFV & SDN. Article. 12 Листопаду 2013. Архів оригіналу за 3 березня 2016. Процитовано 22 Листопаду 2013. 
  26. Middleware[недоступне посилання] for the NFV Generation, Service, Lee Doyle
  27. Wind River Launches [Архівовано 12 травня 2015 у Wayback Machine.] NFV Ecosystem Program with Five Industry Leaders, PCC Mobile Broadband, Ray Sharma
  28. 'Carrier-Grade Reliability—A «Must-Have [Архівовано 22 вересня 2020 у Wayback Machine.]» for NFV Success', Electronic Design, Charlie Ashton, Січень 2015
  29. '5 must-have attributes [Архівовано 26 травня 2015 у Wayback Machine.] of an NFV platform', Techzine, Alcatel-Lucent, Andreas Lemke, Листопад 2014
  30. 'Why Service Providers Need an NFV Platform' [Архівовано 26 травня 2015 у Wayback Machine.], Intel Strategic paper
  31. NFV Proof of Concept. Архів оригіналу за 27 червня 2018. Процитовано 14 травня 2019. 
  32. 'New NFV Forum [Архівовано 7 березня 2019 у Wayback Machine.] Focused on Interoperability', Light Reading, Carol Wilson, 16, 2015
  33. OPNFV, Linux Foundation Collaborative Projects Foundation webpage
  34. Carrier Network Virtualization Awards [Архівовано 2015-06-07 у Wayback Machine.] 2014, Грудень 2015
  35. 'Wind River's Ecosystemic Solution to NFV and Orchestration', CIMI Corporation Public Blog, Tom Nolle, Червень 2014
  36. 'Accelerating Open vSwitch [Архівовано 19 травня 2015 у Wayback Machine.] to «Ludicruos Speed», Network Heresy: Tales of the network reformation, Justin D Pettit, 13 Листопада 2014
  37. 'Wind River Delivers Breakthrough Performance for Accelerated vSwitch [Архівовано 24 квітня 2016 у Wayback Machine.] Optimized for NFV' Wind River News Room, Травень, 2014
  38. '6WIND Announces Open vSwitch Acceleration [Архівовано 20 жовтня 2015 у Wayback Machine.] for Red Hat Enterprise Linux OpenStack Platform', PRweb, Квітень, 2014
  39. 'NETWORK FUNCTIONS VIRTUALIZATION [Архівовано 14 серпня 2020 у Wayback Machine.] CHALLENGES AND SOLUTIONS', TMCNET webpage, Alcatel-Lucent Strategic paper, 2013
  40. 'NFV: The Myth of Application-Level High Availability [Архівовано 5 жовтня 2015 у Wayback Machine.]', Wind River White Paper, Травень 2015
  41. Mano at network-functions-virtualization.com. Архів оригіналу за 5 травня 2019. Процитовано 14 травня 2019. 
  42. Toward High-Performance and Scalable Network Functions Virtualization. Архів оригіналу за 26 жовтня 2020. Процитовано 14 травня 2019. 

Посилання ред.