Този сайт използва бисквитки (cookies). Ако желаете можете да научите повече тук. Разбрах
Skip navigation

Виртуализация на мрежовите ресурси

С изключение на най-големите облачни доставчици всички останали внедряват SDN в орязан вид, като широко приложение намират т.нар. насложени мрежи, създадени на базата на технологиите VXLAN, NVGRE и GENEVE
207 прочитания, 0

През центровете за обработка на данни преминават всички големи обеми трафик. Но проблемът не е толкова в увеличените обеми на трафика от данни, колкото в промяната на неговата природа: основната част е облачен трафик. Именно затова мрежата е длъжна да съответства на изискванията към облачната инфраструктура, т.е. да е необичайно гъвкава и адаптируема. Софтуерно дефинираните мрежи позволяват създаване на динамична и програмируема мрежова инфраструктура. Ако първоначално SDN решенията намираха приложение предимно в ЦОД на големите облачни доставчици, днес те се използват във все повече корпоративни центрове за обработка на данни, така че остава да се разбере кое решение да бъде избрано.

Технологиите за програмируеми мрежи са сравнително „млади“, а виртуализацията на мрежата може да бъде реализирана чрез няколко способа. Много от големите компании имат значителна инсталирана база от мрежово оборудване, което обаче не поддържа OpenFlow. За да се възползват и тези организации от предимствата на мрежовата виртуализация/SDN, редица производители предлагат решения за разгръщане на насложени (overlay) мрежи. Този подход предполага организиране на логическа мрежа над съществуващата физическа инфраструктура. Пренасяйки интелигентността към периферията на мрежата, насложените мрежи позволяват да бъде получена функционалност на програмно дефинирани мрежи без замяна на физическото мрежово оборудване, макар че предвид нарастващите изисквания към пропускателната способност и измененията в трафика такава замяна е желателна и често наложителна.

Както твърдят от компанията Mellanox, първоначалният замисъл за реализиране на принципно нова централизирано управляема мрежова архитектура в рамките на разгърнатите SDN мрежи е реализиран само частично. Тотален преход към OpenFlow обаче не може да се очаква.

VMware“: „Засега никой не разбира как ще се развива в бъдеще SDN“

Според анкета на SDXcentral затворените частни решения засега преобладават над отворените. Това е свързано с факта, че качествено работещо решение, което може да се внедри в производство, трудно може да се „сглоби“ от компоненти с отворен изходен код, тъй като някой ще трябва да го поддържа. Отворените компоненти обаче са все по-широко разпространени, а решенията на базата на отворен изходен код и отворени стандарти се развиват доста интензивно. Съответно много производители, било то доставчици на мрежово оборудване или разработчици на софтуер, развиват паралелно двете направления — собствени затворени разработки и поддръжка на отворен код.

Такава неопределеност в кардинални направления за по-нататъшно развитие на SDN многократно усложнява избора на купувача. Същевременно необходимостта от използване на гъвкави мрежи, тяхното бързо разгръщане и адаптиране към променящите се изисквания става все по-реална. Разбира се, никакво описание не заменя непосредственото тестване или пилотни проект, но така може да се оцени доколко едно или друго решение отговаря на условията на конкретната мрежова среда. Не е възможно да се тестват всички достъпни решения, затова е желателно да имаме обща представа за това,какъв е даден продукт, технология или подход и в каква насока се развива.

Какво е мрежова виртуализация?

Допълнително неразбирателство внасят множеството термини и акроними. Все още много потребители се объркват във всички нови понятия: какво точно е мрежова виртуализация, SDN и NFV едно и също нещо ли е? SDN означава OpenFlow или негова поддръжка не е задължителна? SDN представлява ли изцяло софтуерна реализация? Ако това е така, то как тя е свързана с комутаторите (физическото оборудване)? От VMware обясняват следната разлика между SDN и мрежова виртуализация.

Софтуерно дефинираните мрежи е подход към архитектурата, който се състои в разделяне на плоскостта на данните, на контрола и на управлението (data, control&management planes). Мрежовата виртуализация представлява продукт, който се базира на тази архитектура.

Функциите в плоскостта на данните се възпроизвеждат изцяло на програмно ниво, а не на ниво комутатори. Те от своя страна се опростяват и става просто физически транспорт, тъй като цялата функционалност и логика се реализират програмно.

Исторически за мрежовата виртуализация основен стимул за развитие бе създаването на облачна инфраструктура по заявка. В ЦОД „командват“ приложените системи, а не инфраструктурата. Съответно изискванията към инфраструктурата зависят от приложенията, а не обратното. Приложения трябва да са защитени, да се осигури цялостност и съхранение на данните, те да се задействат и заменят бързо, ако това се наложи. И да бъдат достъпни – ако има прекъсване, възстановяването да става бързо и по възможност автоматично (виж фиг 1).

На базата на опита от използването на платформите NSX VMware разглежда 3 основни сценария за приложение на мрежовата виртуализация: безопасност, автоматизация и повишена достъпност.

Всяко внедряване на дадена технология в корпоративна организация трябва да е подкрепено от бизнес нужда. Например осигуряването на непрекъсваемост на виртуализирани среди е реална практическа задача, а мрежовата виртуализация позволява тя да се раздели между няколко ЦОД и да се резервират заедно с приложенията не само данните, а и всички мрежови настройки.

И ако задачата изглежда една и съща, условията за решаване й вече са променени. За все повече приложения външният достъп трябва да бъде осигурен от всяко място, а това води до промяна на шаблоните за взаимодействие с приложенията. Архитектурата на приложенията също търпи изменения в резултат на нови технологии като контейнерната виртуализация например. И накрая, преобразува се и инфраструктурата, тъй като класическата архитектура на мрежата не отговаря на архитектурата на приложенията. В резултат всички производители на мрежово оборудване предлагат едни или други варианти за реализация на L3 комутационни матрици. А класическото разгръщане на мрежи L2 отстъпва място на насложените мрежи.

Всичко това се отразява на решенията за виртуализация на мрежите. Доскоро, преди появата на мрежовата виртуализация, високо ниво на достъпност (5 деветки) бе необходимо само за плоскостта на данните. Изискванията за плоскостта на управлението бяха по-ниски. Сега ситуацията се промени, тъй като в компаниите, включително в банките, все по-голяма става ролята на разработчиците.

Дори плоскостта за управление трябва да е резервируема, разпределена, а и да реагира много бързо на промените.

Центърът за изследвания на VMware е разработил технология за подобрено разпределяне в плоскостта на управлението Corfu DB (проект с отворен изходен код). Това е разпределен каталог на транзакциите, който позволява реализиране на плоскостта на управлението чрез разпределена резервирана архитектура, т.е. в режим „активна-активна“.

Следващото направление при развитието на VMware NSX е поддръжката на DPDK. Натоварването става все по-голямо, телеком операторите искат да прехвърлят мрежовите функции на стандартни сървъри, затова се повишават изискванията към производителността на виртуалните комутатори, както и към тяхното времезакъснение. Intel разработи набор библиотеки и драйвери за бърза обработка на пакети, наречен „Развоен комплект за плоскостта на данните“ (Data Plane Developer Kit, DPDK). VMware планира да използва тази технология за свързване към физически мрежи. Това е нужно само там, тъй като във виртуална среда при нас всичко е разпределено, постигаме производителност чрез разпределение на цялото натоварване. Съответно се появява граничен клъстер в NSX в режим „активен-активен“ и средства за бързо известяване на физическата мрежа за прекъсвания“, обясняват от компанията.

3 варианта за реализиране на SDN

Предлаганият от VMware способ за реализация на SDN чрез насложени мрежи не е единственият възможен. Има още 3 варианта за реализации на софтуерно дефинирани мрежи в ЦОД.

Първо, това е реализация на SDN чрез софтуерна комутационна матрица, което предполага програмиране на ниско ниво на комутационната матрица чрез използване на отворения протокол OpenFlow. Логиката на мрежата се изнася в контролер, който програмира мрежата в съответствие със зададената политика. Този „класически“ подход се отличава с най-голяма гъвкавост и универсалност, но едновременно с това и изисква най-много разходи, тъй като налага замяна на остарялото оборудване в цялата мрежа — фактически мрежата трябва да се изгради наново, тъй като цялото мрежово оборудване трябва да поддържа определени интерфейси API. Един от примерите за отворена SDN е, разбира се, OpenFlow. Ако се използва протоколът OpenFlow, всички комутатори трябва да го поддържат. Редица производители, в частност BigSwitch, реализират подобен подход, но при някои има особености, например при Cisco това е Application Centric Infrastructure.

Вторият вариант е SDN във вид на насложени мрежи (overlay). Идеята е да се изнесе цялата програмна логика на SDN от крайните комутатори към сървъри. Този вариант е много по-прост за реализация, затова именно той се развива най-бързо днес - SDN може се разгръщат, без да се заменя съществуващото мрежово оборудване, а просто се инсталира нужният софтуер. Запазването на досегашното оборудване понижава разходите за нови устройства, но се купуват софтуерни приложения. Усложнява се обаче управлението на мрежата и нейната диагностика, тъй като се налага да управлява и основната физическа мрежа, и насложената логическа, да се корелира информацията от физическите и виртуалните устройства.

Този подход се ползва основно в центровете за обработка на данните. SD-WAN е още един пример за реализация на подобен подход във WAN мрежите. Този модел (overlay) е вграден в в решенията VMware NSX, Nuage Networks (днес част от Nokia), VSP, PLUMGrid ONS, OpenContrail и Midokura MidoNet. Насложените мрежи се реализират изцяло софтуерно на сървъра (на базата на виртуални комутатори) или се изнасят в комутационната матрица (в комутатори на върха на шкафа, ToR).

И накрая, SDN чрез API. Това е е най-очевидният вариант. Доскоро никой не го наричаше SDN, но днес той може да бъде отнесен към DevOps, който се използва като средство за автоматизиране и унифициране на управлението. Идеята е да се използва единен модел на данните за описание на конфигурацията, както и стандартни интерфейси за управление, налични в мрежовите устройства, това са класическият SNMP, Netconf, XML, REST и др. Различни програмни API позволяват прилагане на автоматизирани сценарии вместо управление чрез Web интерфейс и чрез СLI. Моделът предполага най-малки разходи. Функционалността обаче се ограничава от възможностите на CLI интерфейса в конкретното устройство. Този подход често се прилага като допълнение към първия и втория модел, още повече че на пазара има редица средства за автоматизация, например Chef, Puppet и Ansible.

Open Ethernet като допълнение към SDN

Ако доскоро мрежовите устройства представляваха „черна кутия“ със своя хардуерна архитектура и собствен софтуер, днес този подход постепенно остава в миналото.

Инициативата Open Ethernet предлага използване на мрежовото устройство като отворена платформа за задействане на ОС и приложения.

Ако си купите сървър от HPE, на него едва ли ще инсталирате само определена операционна система, можете да сложите Windows, Linux. Същото е възможно и при Open Ethernet - купувате комутатор и можете да инсталирате всяка ОС с необходимия ви набор приложения за поддръжка на избран вариант за реализация на софтуерна мрежа.

Самата употреба на Open Ethernet не дава толкова осезаеми предимства както SDN. Но, допълвайки SDN, той дава много по-голяма свобода - потребителят вече не е „заключен“ към конкретен производител на оборудване и софтуер. Това се постига с цял набор от средства и преди всичко на отворени хардуерни платформи. Микросхемите ASIC, които са в сърцето на комутатора, трябва да поддържат отворени интерфейси, осигуряващи управление на комутатора. С други думи, интерфейсите трябва да са отворени, общодостъпни, описани и документирани.

Пример за такъв интерфейс е интерфейсът за абстракция на комутатора (Switch Abstraction Interface, SAI). Той представлява набор библиотеки, които позволяват създаване на мултивендорна абстракция за управление на различни чипове - с помощта на един и същ код се управляват чипове на Mellanox, на Marvell и др. Под егидата на Linux Foundation в самата Linux общност се разработва Switchdev. Тази прослойка представлява напълно отворен драйвер вътре в Linux ядрото за комутатори. Чрез поддръжката на Switchdev в комутатори Mellanox, както и на обикновен сървър, може да се инсталира операционна система Linux (виж фиг. 2). Важно е да има само съответствие на версията на ядрото.

На практика по архитектурата си комутаторът представлява опростен сървър, състоящ се от процесор, памет, диск, като на PCI шината има и ASIC схема. Ако за ASIC има и драйвер, който можем да управляваме, за инсталирането на коя да е ОС е достатъчно да се възползваме от отворена дистрибуция. Тя бе създадена в рамките на проекта Open Compute и се нарича ONIE. Това е аналог на BIOS/UEFI в сървъра, само че за комутатори. С нейна помощ може да се инсталира всякаква операционна система, а след това да се ползват съответните приложения. Това води до обратната тенденция: сървърите се превръщат във (виртуални) комутатори, а комутаторите - в сървъри.

Мрежова матрица за SDN

Преди да се задействат всички необходими услуги, трябва правилно да се настрои инфраструктурата. Ако мрежата е изградена неефективно (губи пакети, на портовете често има грешки и т.н.), SDN няма да работи. Ключовата идея е обединяване на класически универсални устройства в топология на две нива Leaf-Spine, при която всеки комутатор от първо ниво (leaf) е свързан с всеки комутатор от второ ниво (spine). Тази топология бе предложена от Чарлз Клоз през 50-те години на миналия век за изграждане на мащабируеми телефонни мрежи.

Комутаторите за достъп (leaf, или „лист“) осигуряват свързване на крайните възли: сървъри, системи за съхранение, различни мрежови устройства като комутатори, системи за разпределение на натоварването, защитни стени и др. Комутаторите от ядрото (spine, или „ствол“) осъществяват свързването на „листата“ - всеки „лист“ е съединен с всеки друг ствол. Между „листата“, както и между „стволовете“ няма връзки. Това позволява организиране на множество резервни пътища между „листата“. Отказ на един от комутаторите води само до незначителна намаляване на производителността на мрежовата комутационна матрица.

Много производители предлагат свои частни решения, реализиращи топологията на Клоз. Днес са актуални и стандартни варианти за реализация ECMP матрица. Предвид достъпността на няколко маршрута трафикът трябва да се разпредели между тях, като за целта се използва протокол за равноотдалечени маршрути (Equal Cost MuptiPathing, ECMP). За реализиране на насложена мрежа е достатъчно да се съединят всички комутатори по топологията на Клоз и в тях да се настрои маршрутизация в съответствие със стандартните протоколи OSPF/BGP. По принцип над същата физическа топология може да се реализира и софтуерна мрежа на базата на протокола OpenFlow.

Сложното да стане по-просто

SDN предизвиква все по-голям практически интерес вследствие на нуждата облачните ЦОД да осигуряват виртуализация, стандартизация и автоматизация. Благодарение на отделянето на плоскостта на данните от контролната плоскост софтуерно дефинираните мрежи предоставят на ИТ администраторите съвършено нов инструмент за ефективно управление на критични мрежови ресурси. Решения за реализация на SDN и виртуализацията на мрежата предлагат много производители, но повечето им предложения се различават не само по детайлите, а и по принципите, на които са базирани решенията. Всички усилия обаче са насочени в крайна сметка към опростяване на мрежа и нейното управление.

(28.06.2017)

КОМЕНТАРИ

Трябва да сте регистриран потребител, за да коментирате статията
"Виртуализация на мрежовите ресурси"



    

© Ай Си Ти Медиа ЕООД 1997 - 2017 съгласно общи условия за ползване