За сродни статии, споделени от мен за мрежова автоматизация, моля, вижте каталога „NetDevOps от нулата“
През последните години, с непрекъснатото развитие на глобалното поле за облачни изчисления и непрекъснатия растеж на бизнеса, мрежовата технология също продължи да се развива и се появи SDN технологията. От първоначалната основна идея за разделяне на препращането и контрола, базирано на Openflow, хората продължават да се разширяват В разширяването на SDN хората в момента могат да постигнат консенсус, че Openflow вече не е необходимо условие (но разделянето на препращането и контрола е все още е основно условие), а мрежовата програмируемост бавно се превърна в един от важните критерии за измерване на SDN архитектура.
Програмируемите операции на традиционното мрежово оборудване обикновено се основават на CLI и SNMP протоколи. Независимо дали са скриптове или софтуер за управление на мрежата, всички те са разработени на тази основа за постигане на широка гама от възможности за мрежово програмиране, за която ще говорим днес. възможности, като по този начин се реализира автоматизацията на много сценарии. Някои устройства поддържат конфигурацията на някои уеб интерфейси и подмяната на цялостната конфигурация чрез xml. Те са много редки и няма да бъдат описани подробно в тази статия.
КлИ
CLI (интерфейс на командния ред) осъществява взаимодействието човек-компютър чрез командния ред. Това е необходимо умение за мрежовите работници. Хората отварят софтуера SSH или Telnet към устройството всеки ден, след това поставят конфигурация, запазват я и влизат в сила. Един ден хората се умориха от този вид повторение и използваха програма за автоматично генериране на конфигурационни скриптове, влизане в устройството на партиди и издаване на конфигурации, които да влязат в сила, реализирайки автоматизация. Това е мрежов програмируем метод. Нека поговорим за предимствата, които са много съвместими с мисленето, идеите и съществуващите технически системи на хората. Но в крайна сметка този подход предпочита хората пред мрежовите устройства. Той има следните недостатъци:
-Има огромни разлики в наборите от команди между производителите. Не само производителите, но и различните софтуерни версии на един и същи модел може да имат много различни разлики.
-Разработчиците трябва да са запознати с набора от команди и как да го използват. Има рискове за сигурността на ниво конфигурация. Например с едно движение на ръката портът, който исках да отворя, се превърна в затваряне на порта...
-Няма задължителни изисквания за протоколи за предаване (SSH и Telnet) и съществуват рискове за сигурността на производството.
-Процесът на анализиране и генериране на конфигурации е изключително сложен. В много случаи редовните написани правила могат да бъдат само безкрайно близки до „истината“, но не и цялата „истина“.
-Няма транзакционност и дадена конфигурация може частично да влезе в сила и частично да не влезе в сила.
-Няма автоматичен механизъм за проверка и зависи изцяло от хората. Например, искам да тествам дали генерираният скрипт е правилен. Има начин, но той е много труден и често е труден за лесно изпълнение.
-Няма идея за моделиране на данни
CLI винаги е начин за взаимодействие човек-компютър. Той може да даде на мрежата определени възможности за програмиране чрез програми, но в края на краищата това не е метод, който по своята същност е мрежово програмируем. При настоящата вълна от облачни изчисления и SDN, той не е подходящ за широкомащабно автоматизирано внедряване в мрежата и възможностите за програмиране са ограничени. За външни хора е трудно да разберат трудността на развитието.
СНМП
SNMP (SNMP, Simple Network Management Protocol), този протокол може да поддържа системи за управление на мрежата, за да следи дали устройствата, свързани към мрежата, имат ситуация, която предизвиква вниманието на ръководството. Състои се от набор от стандарти за управление на мрежата, включително протокол на приложния слой, схема на база данни и набор от обекти с данни.
За част от съдържанието в Wikipedia, ние подчертаваме управление на мрежата, наблюдение и обекти с данни. Използва се за управление на мрежата, може да се конфигурира и събира и се използва главно за наблюдение. Има моделиране на данни за структуриране на някои модули, характеристики и данни за състоянието на мрежовото оборудване. Използва се главно за системи за управление на мрежата (предимно мониторинг). Тогава нека поговорим за неговите недостатъци:
- Слаба четливост. Предпочита "машината" в човек-машина. Не се чете, когато се използва, както и данните за моделиране също не се четат. Той използва надмножество на ASN.1.
- Сигурността е ограничена. Има три версии: v1, v2c и v3, като сигурността се подобрява последователно. Въпреки това, най-често срещаният е v2c, който има ограничена сигурност. Версията v3 е много безопасна по дизайн, но не е универсална. . .
-Няма механизъм за архивиране, възстановяване или връщане назад. Имаме и show run и други методи за архивиране на командния ред, но snmp. . .
- Много малко пише. Четете много, пишете малко, използва се предимно за наблюдение.
- Елементите от данни, които могат да бъдат събрани, са ограничени и не може да бъде получена конфигурацията на цялото устройство. Много пъти откриваме, че можем да използваме cli, за да го съберем, но не можем да използваме snmp, за да го съберем.
-Има пречки в производителността. Горната граница на събраните данни е 64K, а детайлността на събирането е твърде голяма. В големи и сложни мрежи това може да отнеме минути или повече. Това също подчертава важния момент. Нашите изисквания за детайлност също са много строги. Много пъти се надяваме да събираме пристанищен трафик на всеки няколко секунди. В големите мрежи мисля, че традиционният софтуер за управление на мрежата е... За да разширя още едно изречение, текущият метод е телеметрия (като gRPC), който може да постигне ниво на микросекунда, а някои изискват комбинация от софтуер и хардуер. Все още не е популярно, но в бъдеще трябва да бъде тенденция. Колкото до това кога ще стане това в бъдеще...
-От раждането си SNMP се използва широко в областта на мрежовото наблюдение за получаване на данни за наблюдение. Липсата и сложността на възможностите за конфигуриране доведоха до малкото му използване в мрежовата конфигурация. Програмируема мрежа само за четене.
Протокол Netconf и YANG модел
Изправени пред следващото поколение мрежи, какви протоколи за управление на мрежата са ни необходими, за да реализираме по-добре мрежовата програмируемост и да подобрим нивото на автоматизация?
IETF предложи следните идеи в RFC3535 през 2002 г. (всъщност има 33 от тях. Въз основа на онлайн информация и знанията на автора, написах следните идеи):
1. Има програмируем интерфейс за мрежова конфигурация
2. Една и съща конфигурация може да се използва при различни производители и модели
3. Необходимост от унифициране на език за моделиране с добра четливост
4. Пълна проверка на грешки и функции за възстановяване
5. Транзакционен
Ако имате идея, просто я реализирайте. През 2006 г. IETF предложи протокола Netconf, който реши проблемите, повдигнати от RFC3535. Първоначалният Netconf определя само основната рамка и операциите на протокола и дефинира решения, които вземат предвид някои проблеми на RFC3535. Той не предвижда унифициран език за моделиране. Следователно оборудването на някои ранни производители поддържа само някои основни операции на Netconf и не използва унифициран долен слой. Език за моделиране на данни.
RFC6020 беше издаден през 2010 г., предлагайки езика за моделиране на YANG Model и метод за комбинирането му с NETCONF. Едната дефиниция е език за моделиране на данни, който обединява основната логика на ресурсите между производителите, а другата дефиниция е унифициран набор от команди за операциите на всеки производител върху конфигурационни данни и данни за състоянието. Екземплярите на данни, създадени от модела YANG, са обвити в протокола Netconf. Предаване, двете се комбинират помежду си, за да изградят нов набор от универсални мрежови програмируеми интерфейси за новата ера, базирани на модела YANG и управлявани от протокола Netconf.
След 2016 г. протоколът Netconf беше тясно интегриран с модела YANG и стана популярен. Досега, когато разглеждаме някои софтуерни аспекти на SDN архитектурата, повече или по-малко сме чували тези два термина.
YANG и Netconf, единият е статичен, а другият е динамичен, точно като ин и ян. Двамата са извели мрежовия програмируем свят на следващата ера. (Когато разгледаме склада YANG в github, ще открием също, че неговата икона е Tai Chi и връзката между името му и „Yang“ донякъде разкрива дизайнерските идеи на оригиналния дизайнер).
След това ще говорим накратко за модела YANG и протокола Netconf. Нека първо да поговорим за езика за моделиране на данни YANG, за да видим как той описва цифровия близнак на този мрежов свят.
Модел YANG
В документа RFC6020 началната глава ясно посочва YANG, език за моделиране на данни за протокола за мрежова конфигурация. Това е съкращението от Yet Another Next Generation (Yang) Data Modeling Language. Това е език за моделиране, използван за описание на мрежови концепции.
Поддържа дефиниране на списъци, речници и дори по-сложни структури от данни, поддържа ограничения, изброявания, импортиране на справки, управление на версии и пространства от имена. Поради място, ще дадем кратко обяснение. За подробна информация можете да се обърнете към:
Той може да опише това мрежово устройство много просто на структуриран език. Например, за дефиницията на порт:
Като професионален персонал по експлоатация и поддръжка, с малко основи на мрежата и малко основи на програмирането, можете да разберете дефиницията на порт относително ясно. Това е списъчна структура и може да има няколко. Един от неговите атрибути е име на интерфейс (също ключ). , уникален, неповтарящ се), както и атрибута скорост и дуплексния атрибут, като и двата са низове.
Много атрибути на мрежово устройство са описани от модела YANG, включително състояние на конфигурация и работно състояние.
По този начин моделът YANG описва онлайн света, използвайки структуриран език. Ако се интересувате, можете да прочетете горната публикация в интернет блог, която има много задълбочено описание.
Той може да бъде конвертиран в XML данни много добре и увит в протокола Netconf за предаване (ще го обясним по-късно):
В същото време, за да изравнят разликите между доставчиците, Openconfig, ръководен от Google, стандартизира модела на данни. От официалния уебсайт виждаме слогана „Неутрално спрямо доставчика, управлявано от модели управление на мрежата, проектирано от потребители“, което е проектирано от потребители и между платформи. Често срещано, управлявано от модела мрежово програмиране (нека първо го преведем по този начин). Казано по-просто, това е да се направи моделирането между различните производители еднакво, така че когато конфигурирате определени данни, да не се налага да преглеждате личния ян модел на всеки производител един по един. Но Интернет винаги има частни протоколи и различните производители винаги ще създават нови и по-добри частни протоколи за „по-добро потребителско изживяване“ и „по-добра бизнес стратегия“ (това наистина е първородният грях на производителите на мрежи). Картината показва някои от по-често използваните реализации на модела openconfig yang.
Съдейки по снимката, мисля, че има доста от тях и често използваните конфигурации са сравнително пълни. Но на практика зависи дали производителят поддържа и тези ян модели. Някои устройства с по-висока версия на определена тема се поддържат основно. Домашните все още не съм ги загледал по-подробно.
Мрежите не могат да бъдат абсолютно еднакви. За инженер, който се занимава с разработване на експлоатация и поддръжка на мрежата, е благословия да може да постигне същата цел!
openconfig може да се намери в https://github.com/openconfig/public/tree/master/release/models
Можете да намерите частни ян модели на различни официални уебсайтове.
Протокол Netconf
След като говорихме за модела Ян, нека да поговорим за протокола Netconf. Моделът yang дефинира цифровото описание на мрежовия свят, а Netconf дефинира придобиването (get) и коригирането (config) на данни.
Netconf капсулира данните от света, описан от модела Ян, за да реализира управлението на мрежовия свят.
Данните от Yang се капсулират в xml и след това се управляват чрез протокола Netconf. Това е протокол със страхотна многопластова идея, описваща някои подробности от протокола по йерархичен начин. Нека погледнем снимката по-горе.
-Предаване: Netconf се предава чрез SSH протокола, ориентиран е към свързване и има гаранции за сигурност.
-Съобщение: Направете дистанционно повикване до мрежовото устройство чрез RPC, мрежовият мениджър издава rpc заявка и мрежовото устройство възобновява rpc-отговора.
-Операция: Това е душата на Netconf. Поддържа get (конфигурация и текущи данни), get-config (получаване на конфигурационни данни и едно устройство може да има множество конфигурационни данни, едно работещо, едно стартиране, множество кандидати), edit -config (конфигуриране на параметри на мрежово устройство, поддържа добавяне, изтриване и модифициране), delete-config, copy-config (копирайте конфигурацията в дестинацията, дестинацията може да бъде ftp, файл или работеща конфигурация и т.н.), заключване\отключване (заключване на конфигурацията за предотвратяване на конфликти или грешки в конфигурацията, причинени от многопроцесни операции) и така нататък.
-Данни: данните са данни, обвити в xml. Подобно на порта, който описахме по-горе, структурираните данни са лесни за програмиране. Използва се за описание на данните, които трябва да бъдат конфигурирани, изтрити или получени.
Това са четирите слоя на Netconf. Контролният край и мрежовото устройство комуникират чрез Netconf, чрез традиционния ssh протокол, използвайки подсистемата Netconf, а портът по подразбиране е 830. Както е показано по-долу:
Тази фигура демонстрира взаимодействието с помощта на необработен ssh, но всъщност ние прилагаме този процес чрез програмиране. По-късно ще ви демонстрирам метода за внедряване на програмирането.
Netconf конфигурира мрежови устройства. Процесът на взаимодействие е приблизително както следва:
Тази снимка е толкова ниска, можете също да видите, че е нарисувана от мен... Моето разбиране за Netconf е както по-горе. Мисля, че има много снимки в интернет, които не са правилни, и много поведения на сървърния агент не са правилни. Това е, което усещам интуитивно, когато влизам в устройството и, разбира се, отговаря едно към едно на официалната документация.
Можем да разгледаме някои примери за Netconf:
Здравейте, създайте връзка.
Видяхме няколко ключови думи, версия на Netconf, поддържан YANG модел, идентификатор на сесия. В същото време hello показва в какво пространство от имена работим. В този случай това е съответната версия на Netconf.
Вземете конфигурация
Един параметър на get-cofig е източникът, където се получават данните за конфигурацията (работи, стартиране или друго). Друг параметър е филтър, т.е. кои данни се получават от модела на данни, описан от кой ян модел. Това съответства на възможността, първоначално изпратена от мрежовото устройство. При успех ще бъдат върнати съответните конфигурационни данни.
Вземете конфигурация или текущи данни
Подобно на get-config, но това, което се получава, е изпълняваща се конфигурация (лично разбиране) или изпълняващи се данни. Може да се посочи филтър.
Копиране на конфигурация
Операцията за копиране има два параметъра, източник и дестинация. Успешният отговор е с етикет ok.
Редактиране на конфигурация
Когато редактирате конфигурацията, укажете елемента от данни за редактиране, пространството от имена на възможността и съответния етикет. Например, това е да конфигурирате dhcp, който е описан от модела yang http://tail-f.com/ns/example/dhcp.
Затворете сесията елегантно
Това е този вид съобщение, което се предава напред и назад в ssh. Ние просто извличаме част от съобщението, за да улесним разбирането на всички.
След това просто добавете малко съдържание за справка.
-Netconf се основава на сесия и всеки успех ще има идентификатор на сесия.
-Всяка заявка има идентификатор на съобщение, стига постепенно да се увеличава
- Конфигурацията на данни може да бъде заключена, изключителна и управлявана чрез заключване.
-Netconf е транзакционен и всички операции са или внедрени, или никакви. В същото време, според официалната документация на уебсайта, тази транзакционност е за конфигуриране на N мрежови устройства, тоест еднократният конфигурационен полиморфизъм може да поддържа транзакционност. Но още не съм го направил…
-Netconf поддържа абонамент. По отношение на производителността на устройството, порядъкът на величината е около 5 сесии. Мога да се абонирам за определен елемент от данни и устройството ще ме уведоми, когато се промени.
-Възможност, аз така го разбирам. Мрежовото устройство изпраща версията на Netconf и YANG Model, а контролният терминал изпраща версията на Netconf. Само когато версията на Netconf съвпада с двете, можем да продължим. Това е моето интуитивно усещане. Всеки съвет е добре дошъл.
-Операции като получаване на редактиране ще определят данните, които трябва да бъдат променени, които могат да бъдат филтрирани с филтър.
-copy-config поддържа копиране на пълен набор от конфигурации от някъде на някъде. Мястото може да бъде FTP файл, работещ, стартиращ и кандидатски конфигурации на устройството.
-Netconf също така поддържа проверка на конфигурацията, като използва операцията валидиране.
Тази статия все още се надява да популяризира науката и няма да навлизам в подробности. Можете да прочетете съответните протоколи на RFC, който всъщност не е много дълъг.
На практика, въз основа на софтуер с отворен код, като ncclient на python, можем лесно да конфигурираме мрежовите устройства автоматично и да постигнем мрежова програмируемост. Това е мисията на Netconf и YANG Model.
Мрежовият персонал чете добре форматираните дефиниции на модела YANG и използва съответните езици за програмиране, за да извършва програмируеми операции на мрежови устройства въз основа на операциите, дефинирани от Netconf. По този начин се проправя пътят към мрежовата програмируемост.
Нека разширим и си представим, че моделът YANG е дефинирал структурата на данните на мрежовото устройство. Можем да го управляваме чрез Netconf. Може ли да се управлява и чрез други протоколи?
Отговорът е да. Всъщност много други протоколи са извлечени от Netconf, като RESTConf. Както е показано по-долу,
Моделът YANG (публичен и естествен) дефинира структурата на данните, над която са новите протоколи за управление на мрежата, Netconf, RESTCon, gRPC и т.н. По този начин можем да управляваме мрежови устройства чрез RESTConf на базата на HTTP RESTful API, можем също да управляваме мрежа устройства чрез Netconf, базирани на SSH, или можем да управляваме мрежови устройства чрез gRPC, базирани на HTTP2.0. Всички те са базирани на YANG с добра структура на данните. Моделирайте, напишете съответните данни, капсулирайте ги в xml или json, за да програмирате мрежови устройства. Това е бъдещето на мрежовата програмируемост. За да бъдем точни, това е управлявана от модела програма, базирана на модел мрежова програмируемост. Мрежовите инженери постепенно се фокусират върху параметрите на устройството, вместо върху набора от команди, и конфигурират мрежовите параметри, като четат съответния модел на данни.
Накрая пиша, защо трябва да отворя този публичен акаунт. Учих компютърни науки и технологии, когато бях в училище. След като постъпих на работното място, бях ангажиран с работа по експлоатация и поддръжка на мрежата. Като се замисля, причината, поради която бях разделен на екипи, може да е, че бях аспирант в Изследователския институт за мрежови технологии (ръчно смешно). От самото начало се занимавах с мрежови операции. В по-късния етап на експлоатация и поддръжка бяха използвани инструменти за опростяване на работата и подобряване на ефективността, базирани на CLI. По-късно инструментите постепенно бяха разработени в BS-структурирани уеб приложения. Те бяха постоянно изложени на нови технологии и продължиха да обогатяват нови функции.
За щастие те наваксаха с развитието на технологията с отворен код и SDN и постепенно преминах към работа в NetDevOps и използвах уменията си за програмиране, за да подобря възможностите за работа и поддръжка на екипа. Също така ми хареса да напиша този ред код. С напредването на писането постепенно се открива, че NetDevOps трябва да бъде умение, което всеки мрежов инженер трябва да притежава в бъдеще (всеки налива масло в огъня), така че да могат да постигнат както планиране на високо ниво, така и бързо внедряване. Поглеждайки назад към малко информация в Интернет, честно казано, има много малко в Китай и вътрешната атмосфера не е много силна. Много местни софтуери са базирани на стария CLI и snmp и всеки все още използва текстови инструменти и SSH инструменти за работа. Така че се надявам, че азмога да науча другите как да ловят риба, да споделя своя опит (ями) и умения с повече инженери по експлоатация и поддръжка на мрежатаи правя всичко възможно. Xiao Chu каза, че можете да научите нещо, за да намалите работното си натоварване, и като се фокусирате върху далечното бъдеще, работата и поддръжката на вътрешната мрежа може наистина да се развие към автоматизация.
В бъдеще ще запиша няколко видеоклипа и ще напиша някои статии. Написването на документ е наистина напрегнато. Можете да се абонирате, да събирате, да щракате като харесвате и да гледате.
приложение: Общи операции на Netconf
Дизайн на DWDM OTN решение и оферта за разходите, моля свържете се с мен, Тейлър Хуанг
