Аркестрацыя NETCONF & YANG API
Кіраўніцтва
Апублікавана
2023-07-07
РЭЛІЗ 4.2
Уводзіны
Мэта гэтага дакумента
У гэтай дакументацыі апісваецца, як інтэграваць Paragon Active Assurance з аркестратарам сеткавых службаў праз Control Center NETCONF & YANG API. Практычны эксampДаюцца асноўныя задачы, звязаныя з гэтым, у тым ліку: стварэнне і разгортванне віртуальных тэставых агентаў, запуск тэстаў і манітораў і атрыманне вынікаў гэтых дзеянняў.
У гэтым дакуменце бясплатна даступны кліент Python NETCONF ncclient выкарыстоўваецца ў ролі аркестратара.
Умоўнасці
У гэтым дакуменце выкарыстоўваюцца наступныя скарачэнні:
| Абрэвіятура | Сэнс |
| CLI | Інтэрфейс каманднага радка |
| EM | Менеджэр элементаў |
| ES | Памылка Другая |
| Еўрапарламент | Канчатковая кропка MEG (Maintenance Entity Group) (вызначэнне ITU-T Y.1731) або канчатковая кропка тэхнічнага абслугоўвання (вызначэнне Cisco) |
| НФВ | Функцыя віртуалізацыі сеткі |
| NFVO | Аркестратар віртуалізацыі сеткавых функцый |
| НСД | Дэскрыптар сеткавай службы |
| RPC | Выклік аддаленых працэдур |
| СЫПЦЬ | Пратакол ініцыяцыі сеанса |
| SLA | Пагадненне аб узроўні абслугоўвання |
| С-ВНФМ | Спецыяльны менеджэр VNF |
| ВНФ | Функцыя віртуальнай сеткі |
| vTA | Віртуальны тэставы агент |
Заўвагі па зваротнай сумяшчальнасці
У версіях 2.35.4/2.36.0 NETCONF & YANG API праверка некаторых запытаў была зроблена больш жорсткай, каб адпавядаць стандарту NETCONF. Гэта азначае, што кліенцкі код, заснаваны на старых версіях гэтага кіраўніцтва, цяпер можа быць адхілены.
Напрыкладample, у папярэднім прыкладзе Pythonampкода файла, атрыбут прасторы імёнаў не быў прадстаўлены. Цяпер прастора імёнаў павінна быць прадастаўлена ў XML-запыту кожны раз, калі вы хочаце змяніць рэсурс ConfD.
Перадумовы і падрыхтоўка
Ўстаноўка ConfD
ConfD (прадукт ад Tail-f) выкарыстоўваецца як пасярэднік паміж сістэмай Paragon Active Assurance і NETCONF. ConfD падключае канфігурацыю Paragon Active Assurance і аператыўныя даныя да NETCONF & YANG API.
ConfD павінен быць усталяваны разам з праграмным забеспячэннем Цэнтра кіравання, як апісана ў Кіраўніцтве па ўстаноўцы.
Праверка таго, што ConfD працуе
Каб пераканацца, што ConfD запушчаны і працуе, выканайце каманду
ssh -s @localhost -p 830 netconf
каб праверыць, што ConfD адказвае на порт 830. У камандзе, вызначаецца карыстальнікам netconf create
каманда ў Кіраўніцтве па ўстаноўцы, раздзел Усталёўка ConfD. Дайце пароль, вызначаны той жа камандай.
У вывадзе пераканайцеся, што модуль Цэнтра кіравання ўключаны. Выхад павінен змяшчаць наступны радок:
http://ncc.netrounds.com?module=netrounds-ncc&версія=2017-06-15
Сінхранізацыя базы дадзеных канфігурацыі з Цэнтрам кіравання
Нарэшце, нам трэба абнавіць базу дадзеных канфігурацыі праз NETCONF. Мы зробім гэта тут з дапамогай бібліятэкі Python пад назвай ncclient (кліент NETCONF). Аднак задача таксама можа быць выканана на іншай мове праграмавання, калі яна выкарыстоўвае пратакол NETCONF/YANG.
Роля ncclient - выступаць у якасці кліента ў адносінах да сервера ConfD, які размяшчае API NETCONF/YANG.
Варта адзначыць, што ncclient ніякім чынам не звязаны з Цэнтрам кіравання (раней «Цэнтр кіравання Netrounds»), хоць назва пачынаецца з «ncc».
Вось як усталяваць ncclient:
- Спампаваць праграмнае забеспячэнне з https://github.com/ncclient/ncclient.
- Выканайце гэтую каманду: pip install ncclient
Цяпер мы можам выканаць сінхранізацыю наступным чынам. Звярніце ўвагу, што гэта трэба рабіць на асобным кампутары, а не на самім серверы Цэнтра кіравання:
#
# НАТАТКА:
# Гэты скрыпт дзейнічае як кліент для ConfD, які працуе на серверы NCC.
# Ён будзе выкарыстоўваць NETCONF/YANG API для сувязі.
УВАГА: Гэтая працэдура таксама патрабуецца кожны раз, калі тэставыя агенты былі ўсталяваны і зарэгістраваны незалежна ад NETCONF. Глядзіце заўвагу ў раздзеле «Заview аркестрацыі тэставага агента» на старонцы 17 для атрымання дадатковай інфармацыі.
Настройка некалькіх уліковых запісаў Paragon Active Assurance пад кантролем NETCONF
Прыведзеныя ніжэй дзеянні патрабуюцца толькі ў тым выпадку, калі вы жадаеце наладзіць дадатковыя ўліковыя запісы Paragon Active Assurance, якія будуць кантралявацца NETCONF, у дадатак да ўліковага запісу, наладжанага такім чынам у раздзеле «Устаноўка ConfD» Кіраўніцтва па ўсталёўцы.
Для кожнага такога ўліковага запісу дзейнічайце наступным чынам:
- У Цэнтры кіравання ўвайдзіце ва ўліковы запіс і перайдзіце да Уліковы запіс > Дазволы.
- Дадаць карыстальніка "confd@netrounds.com“, і дайце гэтаму карыстальніку ConfD дазвол адміністратара ў графічным інтэрфейсе, націснуўшы кнопку Запрасіць.
- Сінхранізуйце базу дадзеных канфігурацыі з Цэнтрам кіравання, як апісана ў раздзеле «Сінхранізацыя базы дадзеных канфігурацыі з Цэнтрам кіравання» на старонцы 4.
Цяпер вы павінны мець магчымасць кіраваць некалькімі ўліковымі запісамі Paragon Active Assurance з адным і тым жа карыстальнікам ConfD.
УВАГА: Як толькі вы пачнеце кіраваць уліковым запісам Paragon Active Assurance праз ConfD, вы НЕ павінны ўносіць змены ў гэты ўліковы запіс праз web Графічны інтэрфейс у дачыненні да любых функцый Paragon Active Assurance, якія знаходзяцца ў «канфігурацыі» (гл. раздзел «Функцыі, якія падтрымліваюцца ў Paragon Active Assurance» на старонцы 9). Калі вы гэта зробіце, сінхранізацыя будзе страчана.
Уводзіны ў NETCONF Orchestration API
Скончанаview
Старонні NFVO або аркестратар службы звычайна з'яўляецца кампанентам, які ініцыюе сеансы тэставання і маніторынгу з дапамогай API Цэнтра кіравання. Гэты аркестратар таксама атрымлівае агрэгаваныя вынікі вымярэнняў з дзеянняў тэставага агента. KPI прадукцыйнасці могуць быць атрыманы староннімі сістэмамі кіравання прадукцыйнасцю, у той час як падзеі, выкліканыя парушэннем парогавых значэнняў, устаноўленых у Цэнтры кіравання, могуць быць адпраўлены ў сістэмы кіравання няспраўнасцямі іншых вытворцаў.
Падводзячы вынік, малюнак ніжэй паказвае, як Paragon Active Assurance ўзаемадзейнічае з іншымі сістэмамі іншых вытворцаў у ландшафце OSS.
- NFVO/Service Orchestrator: даручае дыспетчару VNF разгарнуць vTA і наладзіць Paragon Active Assurance ў ланцужку абслугоўвання. Пасля актывацыі сэрвісу аркестрант выкарыстоўвае API для Цэнтра кіравання, каб запусціць тэсты актывацыі сэрвісу і атрымаць вынікі "прайшло/не прайшло". Калі тэсты пройдзены, аркестрант будзе выкарыстоўваць API для Цэнтра кіравання, каб пачаць актыўны маніторынг службы. Ключавыя паказчыкі эфектыўнасці маніторынгу бесперапынна здабываюцца аркестрантам або асобнай платформай кіравання прадукцыйнасцю.
- Цэнтр кіравання: разгортвае, маштабуе і спыняе vTA паводле ўказанняў NFVO або аркестратара службы.
- Сістэма кіравання прадукцыйнасцю або сістэма кіравання якасцю паслуг: счытвае KPI з актыўнага маніторынгу праз API Цэнтра кіравання.
- Сістэма кіравання няспраўнасцямі: атрымлівае паведамленні NETCONF, SNMP або электронную пошту ад Цэнтра кіравання, калі парушаюцца SLA.
Вызначэнні паняццяў у Paragon Active Assurance
- Тэставыя агенты: кампаненты, якія выконваюць вымярэнні (для тэстаў, а таксама для манітораў) у сістэме Paragon Active Assurance. Тэставыя агенты складаюцца з праграмнага забеспячэння з магчымасцю генераваць, атрымліваць і аналізаваць рэальны сеткавы трафік.
- Тып тэставага агента, які абмяркоўваецца ў гэтым дакуменце, - гэта віртуальны тэставы агент (vTA), функцыя віртуальнай сеткі (VNF), разгорнутая на гіпервізары. Існуюць і іншыя тыпы тэставых агентаў.
- У Paragon Active Assurance ёсць два асноўныя тыпы вымярэнняў: тэсты і маніторы.
- Тэст: Тэст складаецца з аднаго або некалькіх этапаў, кожны з якіх мае абмежаваную працягласць. Крокі выконваюцца паслядоўна. Кожны крок можа цягнуць за сабой выкананне некалькіх задач адначасова.
- Манітор: Манітор не мае вызначанай працягласці, але выконваецца бясконца. Як крок у тэсце, манітор можа выконваць некалькі адначасовых задач.
- Шаблон: Калі Paragon Active Assurance кіруецца аркестрантам, тэсты і маніторы заўсёды выконваюцца з дапамогай шаблонаў, у якіх вызначаны тэст або манітор. Налады параметраў могуць быць перададзены ў якасці ўваходных дадзеных у шаблон падчас выканання.
Рабочы працэс для аўтаматызацыі
Час дызайну
Падчас распрацоўкі вы рыхтуеце вымярэнні, ствараючы шаблоны для тэстаў і манітораў у Paragon Active Assurance. Як гэта зрабіць, апісана ў главе «Шаблоны тэсціравання і маніторынгу» на старонцы 15.
Час выканання
Падчас выканання вы наладжваеце прылады і выконваеце фактычныя вымярэнні.
- Надview усіх эксampлес дадзены знаходзіцца ў главе «Выхampаб кіраванні Paragon Active Assurance праз NETCONF & YANG API» на старонцы 15.
- Пра тое, як разгарнуць і наладзіць тэставыя агенты, распавядаецца ў главе «НапрampLes: Test Agents” на старонцы 16.
- Як імпартаваць элементы інвентара, такія як TWAMP адбівальнікаў і каналаў IPTV разглядаецца ў главе «ПрыкладampLes: Inventory Items” на старонцы 29.
- Як наладзіць будзільнікі тлумачыцца ў главе «Прыкладampлес: Будзільнікі” на старонцы 35.
- Пра тое, як запускаць тэсты і маніторы праз выкананне шаблонаў Paragon Active Assurance праз NETCONF, апісана ў раздзелах «Напр.amples: Tests” на старонцы 43 і “Exampлес: Маніторы» на старонцы 54.
Функцыі, якія падтрымліваюцца ў Paragon Active Assurance
Усе тыпы тэстаў і манітораў у Paragon Active Assurance можна ствараць і выконваць з дапамогай шаблонаў. Як гэта зрабіць, апісана ў даведцы праграмы ў раздзеле «Тэсты і маніторы» > «Стварэнне шаблонаў».
Стварэнне ўліковых запісаў Paragon Active Assurance зараз не падтрымліваецца; аднак для карыстальніка будуць настроены адзін або некалькі прадвызначаных уліковых запісаў.
У табліцах ніжэй падрабязна апісана, якія функцыі Paragon Active Assurance даступныя ў гэтым выпуску і як гэтыя функцыі прадстаўлены ў YANG.
Тлумачэнне канструкцый ЯН
Для зручнасці тут прыводзяцца азначэнні канструкцый ЯН, якія згадваюцца ў табліцы функцый.
- Config (config=true): даныя канфігурацыі, неабходныя для пераўтварэння сістэмы з аднаго стану ў іншы.
- Стан (config=false): Даныя аб стане: дадатковыя даныя аб сістэме, якія не з'яўляюцца данымі канфігурацыі, такія як інфармацыя пра статус толькі для чытання і сабраная статыстыка.
- RPC: аддалены выклік працэдуры, які выкарыстоўваецца ў пратаколе NETCONF.
- Апавяшчэнне: апавяшчэнні аб падзеях, якія адпраўляюцца з сервера NETCONF кліенту NETCONF.
Табліцы функцый Paragon Active Assurance, даступных для аркестроўкі
Рэсурс: Маніторынг
Шлях ЯН:/рахункі/рахунак/маніторы
| Асаблівасць | Падфункцыя | ЯН канструкцыя |
| Стварыць/змяніць/выдаліць манітор | На аснове шаблону манітора | Канфігурацыя |
| Пуск/стоп манітора | – | Канфігурацыя |
| Шаблоны манітора | Спіс існуючых шаблонаў манітораў з уводам | Дзяржава |
| Апавяшчэнні NETCONF | Стан будзільніка зменены | Апавяшчэнне |
| Сачыце за вынікамі | Лічыльнік SLA/ES для верхняга ўзроўню (%) Лічыльнік SLA/ES для ўзроўню задачы (%) |
Дзяржава |
У адрозненне ад тэстаў (параўнайце Рэсурс: Тэсты ніжэй), маніторы запускаюцца не з дапамогай RPC, а шляхам фіксацыі канфігурацыі манітора.
Рэсурс: Тэсты
Шлях YANG: /accounts/account/tests
| Асаблівасць | Падфункцыя | ЯН канструкцыя |
| Пачаць тэст | На аснове тэставага шаблону | RPC |
| Кіраваць тэстамі | Спіс тэстаў са статусам | Дзяржава |
| Тэставыя шаблоны | Спіс існуючых тэставых шаблонаў з уводам | Дзяржава |
| Апавяшчэнні NETCONF | Статус тэсту зменены | Апавяшчэнне |
| Вынікі выпрабаванняў | Атрымаць стан тэставага этапу (прайшло, не прайшло, памылка, ...) | Дзяржава |
Рэсурс: Тэставыя агенты
Шляхі ЯН:
- /accounts/account/test-agents (канфігурацыя)
- /accounts/account/registered-test-agents (штат)
Тэставыя агенты ў /accounts/account/test-agents - гэта тыя, якія канфігуруюцца ва ўліковым запісе. Толькі гэтыя тэставыя агенты могуць быць настроены і выкарыстаны ў тэстах і маніторах праз NETCONF аркестратарам.
Пасля таго як вы наладзілі тэставы агент і ён зарэгістраваўся ва ўліковым запісе, тэставы агент з'явіцца ў раздзеле /accounts/account/registered-test-agents. Вы можаце знайсці ўсе зарэгістраваныя тэставыя агенты з дапамогай каманды "атрымаць" у NETCONF (параўнайце главу Examples: Тэставыя агенты).
У раздзеле /accounts/account/registered-test-agents вы таксама можаце знайсці тэставыя агенты, якія яшчэ не былі настроены. Любыя такія тэставыя агенты павінны быць сканфігураваны перад іх выкарыстаннем.
У сцэнарыі аркестроўкі звычайна рэкамендуецца выконваць усю канфігурацыю ўліковага запісу Paragon Active Assurance праз NETCONF. Гэта гарантуе, што тэст-агенты і зарэгістраваныя тэст-агенты не разыходзяцца.
| Асаблівасць | Падфункцыя | ЯН канструкцыя |
| Папярэдне стварыце тэставы агент на серверы | – | Канфігурацыя |
| Наладзьце аўтаномны тэставы агент | (Цэнтр кіравання адпраўляе канфігурацыю ў тэставы агент калі выйдзе ў сетку) |
Канфігурацыя |
| Выкарыстоўваць існуючыя/настроеныя знешне тэставыя агенты | Выкарыстанне ў тэсце/маніторынгу | Канфігурацыя |
| Налада інтэрфейсаў | Канфігурацыя | |
| Атрымаць статус | Дзяржава | |
| Наладзіць тэставы агент (толькі тэставая прылада) | Наладзьце NTP | Канфігурацыя |
| Налада мастоў | Канфігурацыя | |
| Наладзьце інтэрфейсы VLAN | Канфігурацыя | |
| Наладзьце ключы SSH | Канфігурацыя | |
| IPv6 | Канфігурацыя | |
| Камунальныя паслугі | Перазагрузка | RPC |
| Абнаўленне | RPC | |
| Апавяшчэнні NETCONF | Інтэрнэт-статус зменены | Апавяшчэнне |
| Статус | Атрымаць стан сістэмы (працягласць, выкарыстанне памяці, сярэдняя загрузка, версія) |
Дзяржава |
Рэсурс: Інвентар
Шлях ЯН: /accounts/account/twamp-адбівальнікі
Падтрымліваюцца магчымасці NETCONF
Табліца ніжэй паказвае на IETF RFC, якія апісваюць магчымасці NETCONF, якія выкарыстоўваюцца ў мэтах аркестрацыі Paragon Active Assurance.
- ietf-netconf.yang
- IETF RFC 6241, Пратакол канфігурацыі сеткі (NETCONF), https://tools.ietf.org/html/rfc6241
- Адзіным падтрымліваемым метадам апрацоўкі памылак з'яўляецца адкат у выпадку памылкі.
- Адзінае сховішча дадзеных, якое падтрымліваецца, - гэта праца з магчымасцю запісу.
- ietf-netconf-notifications.yang
- IETF RFC 5277, апавяшчэнні аб падзеях NETCONF, https://tools.ietf.org/html/rfc5277
Шаблоны тэсціравання і маніторынгу
Шаблоны для тыпаў тэстаў і манітораў неабходна наладжваць уручную праз карыстацкі інтэрфейс Paragon Active Assurance. Як гэта зрабіць, апісана ў даведцы праграмы ў раздзеле «Тэсты і маніторы» > «Стварэнне шаблонаў».
Exampпадрабязнасці аб кіраванні Paragon Active Assurance праз NETCONF & YANG API
Мяркуецца, што ў наступных раздзелах прыдатныя шаблоны тэстаў і манітораў былі вызначаны ў адпаведнасці з інструкцыямі ў раздзеле «Шаблоны тэстаў і манітораў» на старонцы 15.
Інструменты, якія выкарыстоўваюцца ў Exampлес
Усе былыяampфайлы ў наступных раздзелах былі створаны з выкарыстаннем наступных бясплатна даступных інструментаў:
- Pang: выкарыстоўваецца для візуалізацыі і прагляду мадэляў YANG.
- Даступны па адрасе https://github.com/mbj4668/pyang (клон з git і запусціце python setup.py install).
- Кліент Python NETCONF “ncclient”: выкарыстоўваецца для сувязі з Цэнтрам кіравання з дапамогай NETCONF.
- Даступна на https://github.com/ncclient/ncclient (запусціце pip install ncclient).
Мадэль даных netrounds-ncc.yang знаходзіцца ў /opt/netrounds-confd пасля ўсталявання ConfD у адпаведнасці з Кіраўніцтвам па ўсталёўцы).
Скончанаview ключавых выкананых задач
(Некаторыя дадатковыя задачы таксама прыведзены ў якасці прыкладаў далей.)
- «Стварэнне і разгортванне новага тэставага агента» на старонцы 16
- «Стварэнне прадметаў інвентара (напрыклад, адбівальнікаў)» на старонцы 29
- “Наладжванне шаблонаў сігналаў трывогі і куды адпраўляць сігналы трывогі” на старонцы 35
- “Стварэнне і запуск тэсту” на старонцы 45
- «Атрыманне вынікаў тэсту» на старонцы 50
- «Запуск манітора (уключае наладжванне будзільнікаў)» на старонцы 60
- “Атрыманне стану SLA для манітора” на старонцы 67
- «Праца з tags» на старонцы 71
ExampLes: Тэставыя агенты
Скончанаview аркестроўкі тэставага агента
Тэставыя агенты ў Paragon Active Assurance разглядаюцца як «канфігурацыя» ў кантэксце аркестроўкі. Гэта азначае, што стварэнне, кіраванне і выдаленне тэставых агентаў павінны выконвацца праз аркестратар і NETCONF, а не праз графічны інтэрфейс Paragon Active Assurance.
ВАЖНА: Калі тэставы агент усталяваны спецыялістам і зарэгістраваны ў Цэнтры кіравання без папярэдняга стварэння праз NETCONF & YANG API, тэставы агент не будзе існаваць у базе дадзеных канфігурацыі, і сістэма выйдзе з сінхранізацыі. Каб ConfD даведаўся аб тэставым агенте ў гэтым выпадку, неабходна выканаць новую сінхранізацыю з Цэнтрам кіравання, як падрабязна апісана ў раздзеле «Сінхранізацыя базы дадзеных канфігурацыі з Цэнтрам кіравання» на старонцы 4.
Арганізацыя віртуальных тэставых агентаў (vTA) павінна выконвацца ў наступныя этапы:
- Стварыце віртуальны тэставы агент, уключаючы канфігурацыю яго інтэрфейсу, выкарыстоўваючы інтэрфейс NETCONF & YANG для Цэнтра кіравання. Імя тэставага агента будзе яго унікальным ключом.
- Разгарніце vTA на платформе віртуалізацыі. Выконвайце інструкцыі ў інтэрактыўнай даведцы ў раздзеле Тэставыя агенты > Усталяванне. Базавая канфігурацыя інтэрфейсу, якая дазваляе vTA падключацца да Цэнтра кіравання, а таксама ўліковыя дадзеныя для аўтэнтыфікацыі прадастаўляюцца ў vTA з выкарыстаннем карыстальніцкіх даных воблака.
Пасля таго, як vTA загрузіцца, ён аўтаматычна падключыцца да Цэнтра кіравання, выкарыстоўваючы зашыфраванае злучэнне OpenVPN. Апавяшчэнне NETCONF адпраўляецца, паколькі значэнне параметра test-agent-statuschange vTA цяпер зменена на «online».
УВАГА: Паколькі імя vTA з'яўляецца яго ідэнтыфікатарам у Цэнтры кіравання, гэта імя павінна супадаць з назвай, вызначанай у Цэнтры кіравання ў «кроку 1» на старонцы 17. - Пасля падключэння vTA і аўтэнтыфікацыі ў Цэнтры кіравання канфігурацыя інтэрфейсу перадаецца ў vTA. Гэта канфігурацыя інтэрфейсу, прадстаўленая ў «кроку 1» на старонцы 17, калі vTA быў створаны ў Цэнтры кіравання.
- Пасля таго, як vTA адслужыць сваю мэту, выдаліце vTA.
Стварэнне і разгортванне новага тэставага агента
Спачатку нам трэба стварыць тэставы агент з дапамогай інтэрфейсу NETCONF & YANG для Цэнтра кіравання. Калі тэставы агент створаны такім чынам, сінхранізацыя з Цэнтрам кіравання не патрабуецца.
Мадэль YANG для тэставага агента паказана ніжэй. Яно атрымліваецца як выхад з каманды
pyang -f дрэва netrounds-ncc.yang
Поўная мадэль YANG прыведзена ў «Дадатку: Дрэвападобная структура поўнай мадэлі YANG» на старонцы 81, якая таксама змяшчае легенду, якая тлумачыць пагадненні, якія выкарыстоўваюцца ў гэтай і іншых ілюстрацыях мадэлі YANG у гэтым дакуменце.
Мы выконваем наступныя крокі, якія падрабязна апісаны ў наступным:
- З самага пачатку дэма-версія ўліковага запісу Paragon Active Assurance не мае тэставых агентаў.
- Тэставы агент пад назвай "vta1" ствараецца з дапамогай ncclient. На гэтым сtage, пакуль не існуе сапраўднага тэставага агента (гэта значыць, ён яшчэ не запушчаны).
- Тэставы агент разгортваецца ў OpenStack. (Разгортванне на гэтай платформе выбрана тут як адна з іншых магчымасцей.)
- Тэставы агент падключаецца да дэма-версіі ўліковага запісу Цэнтра кіравання і гатовы да выкарыстання.
Крок 1: З самага пачатку, у «дэма-версіі» ўліковага запісу няма тэставых агентаў. Глядзіце скрыншот ніжэй з графічнага інтэрфейсу Цэнтра кіравання.
Крок 2: Тэставы агент ствараецца ў Цэнтры кіравання з дапамогай кліента Python NETCONF «ncclient». Ніжэй прыведзены код ncclient для стварэння тэставага агента з адным фізічным інтэрфейсам з адрасам DHCP:
імпартаваць разбор аргументаў
з дыспетчара імпарту ncclient
парсер = argparse.ArgumentParser(апісанне='Тэставанне стварэння тэставага агента')
parser.add_argument('–host', help='Імя хаста, дзе знойдзены ConfD', патрабуецца=Праўда)
parser.add_argument('–port', help='Порт для падлучэння да ConfD', патрабуецца=True)
parser.add_argument('–username', help='Імя карыстальніка для падлучэння да ConfD', патрабуецца=True)
parser.add_argument('–password', help='Пароль да ўліковага запісу ConfD', патрабуецца=True)
parser.add_argument('–netrounds-account', help='Кароткая назва ўліковага запісу NCC', патрабуецца=Праўда)
parser.add_argument('–test-agent-name', help='Імя тэставага агента', патрабуецца=True)
аргументы = парсер.парсаванне_аргументаў()
з manager.connect(host=args.host, port=args.port, username=args.username,
пароль=args.password, hostkey_verify=False) як m:
# Стварыце тэставы агент у Цэнтры кіравання
xml = “””
)print m.edit_config(target='running', config=xml)
УВАГА: код, які папярэднічае manager.connect(…), апускаецца з наступных exampфрагменты кода.
NTP-сервер настроены на eth0, і eth0 таксама з'яўляецца інтэрфейсам кіравання (гэта значыць інтэрфейсам, які падключаецца да Цэнтра кіравання).
Прыкладанне тэставага агента зараз не дазваляе канфігураваць інтэрфейсы. Па гэтай прычыне, пачынаючы з версіі 2.34.0, можна апусціць канфігурацыю інтэрфейсу ў схеме YANG. Такім чынам, адпаведны XML у гэтым выпадку радыкальна спрошчаны:
Пасля таго, як тэставы агент быў створаны, ён існуе ў базе дадзеных канфігурацыі і ў Цэнтры кіравання. Глядзіце скрыншот ніжэй інвентарызацыі тэставага агента, на якім паказаны тэставы агент «vta1»:
Крок 3: Надышоў час разгарнуць тэставы агент «vta1» у OpenStack.
Тэставы агент будзе выкарыстоўваць даныя карыстальніка воблачнай ініцыялізацыі для атрымання інфармацыі аб тым, як падключыцца да Цэнтра кіравання. У прыватнасці, тэкст дадзеных карыстальніка file мае наступнае змесціва (Звярніце ўвагу, што радкі #cloud-config і netrounds_test_agent павінны прысутнічаць, а астатнія радкі павінны быць з водступам):
Для атрымання дадатковай інфармацыі, калі ласка, звярніцеся да дакумента Як разгарнуць віртуальныя тэставыя агенты ў OpenStack.
Пасля разгортвання агента тэставання і падключэння да Цэнтра кіравання канфігурацыя будзе перададзена з Цэнтра кіравання ў агент тэставання.
Крок 4: Тэст-агент зараз знаходзіцца онлайн ў Цэнтры кіравання і атрымаў сваю канфігурацыю. Тэставы агент гатовы да выкарыстання ў тэстах і маніторынгу. Глядзіце гэтыя раздзелы:
- «Пачатак тэсту» на старонцы 45
- “Запуск манітора” на старонцы 60
Пералік тэставых агентаў у вашым уліковым запісе Paragon Active Assurance
Ніжэй эксample ncclient Код Python для пераліку тэставых агентаў ва ўліковым запісе Paragon Active Assurance:
Запуск гэтага кода дае наступны вынік:
Выдаленне тэставага агента
Пасля завяршэння тэсту ў некаторых выпадках можа спатрэбіцца выдаліць тэставы агент.
Ніжэй прыведзены фрагмент кода, які паказвае, як гэта зрабіць з дапамогай ncclient:
Апавяшчэнні NETCONF
Ніжэй мы прадстаўляем просты прыкладampскрыпт для праслухоўвання ўсіх уваходных апавяшчэнняў NETCONF з Цэнтра кіравання. Гэтыя апавяшчэнні адпраўляюцца кожны раз, калі адбываюцца пэўныя падзеі, напрыклад, адключэнне тэставага агента ў аўтаномным рэжыме або завяршэнне тэсту, ініцыяванага карыстальнікам. На аснове інфармацыі, якая змяшчаецца ў апавяшчэннях, карыстальнікі могуць прызначаць аўтаматызаваныя наступныя дзеянні ў аркестратары.
Калі прыведзены вышэй скрыпт будзе выкананы, кліент NC прадставіць атрыманае апавяшчэнне ў структураваным XML. Глядзіце эксampВывад ніжэй, які паказвае, што тэставы агент нечакана адключаецца ад сеткі.
2017-02-03T15:09:55.939156+00:00</eventTime>
<test-agent-status-change xmlns=’http://ncc.netrounds.com'>
дэма
HW1
у аўтаномным рэжыме
Examples: Інвентарныя прадметы
Стварэнне (імпарт) і кіраванне прадметамі інвентара, такімі як TWAMP адбівальнікі і Y.1731 MEPs робіцца такім жа чынам, як і для тэставых агентаў. Ніжэй прыведзены код XML і NETCONF для вызначэння такіх аб'ектаў у Paragon Active Assurance праз API NETCONF & YANG і для атрымання спісаў вызначаных элементаў.
Стварэнне TWAMP Адбівальнік
Стварэнне Y.1731 MEP
Стварэнне IPTV канала
Стварэнне хоста Ping
Стварэнне ўліковага запісу SIP
Атрыманне прадметаў інвентара
Ніжэй прыведзены код Python для атрымання ўсіх элементаў інвентара, вызначаных ва ўліковым запісе. (Усе тыпы элементаў інвентара выбіраюцца тут за адзін раз, каб пазбегнуць паўтарэння ў дакуменце. Натуральна, любую падмноства элементаў інвентара можна атрымаць, прапусціўшы некаторыя з радкоў ва ўліковым запісе ніжэй.)
Запуск гэтага кода дае наступны вынік:
Examples: Будзільнікі
Шаблоны сігналаў трывогі і звязаныя з імі элементы (менеджэры SNMP, спісы электроннай пошты сігналізацыі) ствараюцца і кіруюцца такім жа чынам, што і элементы інвентара. У гэтай главе змяшчаецца код XML і NETCONF для вызначэння такіх аб'ектаў у Paragon Active Assurance праз NETCONF & YANG API і для атрымання спісаў вызначаных элементаў.
Спісы электроннай пошты сігналізацыі
Стварэнне спіса паведамленняў электроннай пошты
Атрыманне ўсіх спісаў электроннай пошты для трывог
Менеджэры SNMP
Стварэнне дыспетчара SNMP
Атрыманне ўсіх кіраўнікоў SNMP
Шаблоны будзільнікаў
Стварэнне шаблона будзільніка
Атрыманне ўсіх шаблонаў будзільнікаў
Exampфайлы: Ключы SSH
Вы можаце дадаць адкрытыя ключы SSH да тэставага агента праз NETCONF & YANG API. Выкарыстоўваючы адпаведны закрыты ключ, вы можаце ўвайсці ў тэставы агент праз SSH.
Поўны спіс даступных аперацый з ключамі SSH выглядае наступным чынам:
- Дадайце ключ SSH
- Змяніць ключ SSH
- Праверце ключ SSH
- Спіс ключоў SSH
- Выдаліць ключ SSH.
Ніжэй прыведзены прыклады аперацый дадання і выдалення.
Выдаленне ключа SSH
Калі вы хочаце выдаліць ключ SSH, выкарыстоўвайце наступную каманду:
Exampлес: Тэсты
Мяркуецца, што тэставыя агенты (столькі, колькі патрабуецца для тэстаў) былі створаны ў адпаведнасці з раздзелам «Стварэнне і разгортванне новага тэставага агента» на старонцы 17.
Шляхі мадэлі YANG для тэстаў
| Пункт | Шлях мадэлі YANG: /accounts/account/tests … |
| тэсты | /. |
| тэст [id] | /тэст |
| id | /тэст/ідэнтыфікатар |
| імя | /test/імя |
| статус | /test/статус |
| Час пачатку | /тэст/час пачатку |
| канец часу | /test/канчатковы час |
| справаздача-url | /пратакол выпрабаванні-url |
| крокі | /test/крокі |
| крок [ідэнтыфікатар] | /test/steps/step |
| імя | /test/steps/step/name |
| id | /test/steps/step/id |
| Час пачатку | /test/steps/step/start-time |
| канец часу | /test/steps/step/канец часу |
| статус | /test/steps/step/status |
| статус-паведамленне | /test/steps/step/status-message |
| шаблоны | / шаблоны |
| шаблон [імя] | /templates/template |
| імя | /templates/template/name |
| апісанне | /templates/template/description |
| параметры | /templates/template/parameters |
| параметр [ключ] | /templates/template/parameters/parameter |
| ключ | /templates/template/parameters/parameter/key |
| тыпу | /templates/template/parameters/parameter/type |
Перадумовы для аркестроўкі тэсту
- Каб пачаць тэст праз NETCONF з дапамогай кліента NC, неабходна спачатку стварыць тэставы шаблон з дапамогай графічнага інтэрфейсу Цэнтра кіравання, як падрабязна апісана ў даведцы праграмы ў раздзеле «Тэсты і маніторы» > «Стварэнне шаблонаў». Усе палі, указаныя ў гэтым шаблоне як «Увод шаблона», будуць неабходныя ў якасці параметраў у XML пры арганізацыі ініцыяцыі тэставага шаблону.
- Запуск тэстаў у Paragon Active Assurance разглядаецца як «стан» у кантэксце аркестроўкі. Даныя аб стане - гэта недаступныя для запісу даныя, якія не захоўваюцца ў базе даных канфігурацыі, у адрозненне ад даных канфігурацыі, згаданых у раздзеле «Надview Аркестрацыі тэставага агента” на старонцы 17. Гэта ў асноўным азначае, што змены ў тэстах або шаблонах у графічным інтэрфейсе Цэнтра кіравання не выклічуць ніякіх праблем, звязаных з сінхранізацыяй паміж Цэнтрам кіравання і базай дадзеных канфігурацыі.
- Каб атрымаць справаздачу -URL прама ў справаздачах аб выпрабаваннях, вам трэба пераканацца, што Цэнтр кіравання URL правільна наладжаны. Гэта зроблена ў в file /opt/netrounds-confd/settings.py. Па змаўчанні імя хоста Control Center атрымліваецца з дапамогай socket.gethostname(): гл. ніжэй. Калі гэта не дае правільнага выніку, вам трэба ўсталяваць імя хаста (або ўвесь файл URL) уручную ў гэтым file.
# URL Цэнтра кіравання без касой рысы ў канцы.
# Гэта, напрыкладampфайл, які выкарыстоўваецца ў справаздачы аб выпрабаванні-url.
HOSTNAME = socket.gethostname()
NETROUNDS_URL = 'https://%s' % HOSTNAME
Пачатак тэсту
Як апісана ў раздзеле «Стварэнне і разгортванне новага тэставага агента» на старонцы 17, выканайце каманду pang -f tree netrounds-ncc.yang
з каталога /opt/netrounds-confd/, каб вывесці мадэль YANG. У гэтай мадэлі RPC для запуску тэсту з дапамогай кліента NC выглядае наступным чынам:
Тлумачэнні глядзіце ў раздзеле “Легенда” на старонцы 81 у Дадатку.
Наступныя крокі паказаны ніжэй:
- Тэставыя агенты былі зарэгістраваны ва ўліковым запісе Paragon Active Assurance, але тэсты яшчэ не пачыналіся.
- Неабходныя ўваходныя параметры вызначаны ў тэставым шаблоне, які будзе запушчаны.
- Тэст HTTP працягласцю 60 секунд запускаецца з дапамогай ncclient.
Крок 1: З самага пачатку ніякіх тэстаў ва ўліковым запісе Paragon Active Assurance не было. Глядзіце скрыншот ніжэй з графічнага інтэрфейсу Цэнтра кіравання.
Крок 2: Шаблон, які мы будзем выкарыстоўваць для пачатку тэсту ў гэтым выпадкуample - тэставы шаблон HTTP. Ён мае два абавязковых палі для ўводу (Кліенты і URL), які мы пазначылі як такі пры стварэнні шаблону ў графічным інтэрфейсе Цэнтра кіравання.
Мы вызначым гэтыя параметры (сярод іншых) у канфігурацыі XML, якую перадае ў базу дадзеных канфігурацыі наш менеджэр NETCONF (ncclient).
Крок 3: Тэст HTTP запускаецца з дапамогай ncclient.
Ніжэй эксample код, у якім указваецца неабходная інфармацыя аб канфігурацыі і параметры тэставага шаблону HTTP. У залежнасці ад таго, як быў пабудаваны шаблон, дэталі тут могуць адрознівацца.
Для кожнага параметру, атрыбут павінен быць пастаўлены. Ключ ідэнтычны параметру
Імя зменнай у Цэнтры кіравання. Вы можаце праверыць імёны зменных наступным чынам:
- Націсніце «Тэсты» на бакавой панэлі і выберыце «Новая паслядоўнасць тэстаў».
- Націсніце Мае шаблоны.
- Пстрыкніце спасылку "Рэдагаваць" пад цікавым шаблонам.
- Націсніце кнопку «Рэдагаваць увод» у правым верхнім куце.
У нашай былойample, і па змаўчанні імёны зменных - гэта проста версіі імёнаў, якія адлюстроўваюцца ў малым рэгістры ў Цэнтры кіравання ("url"супраць"URL», і г.д.). Аднак у графічным інтэрфейсе Цэнтра кіравання вы можаце перайменаваць зменныя як заўгодна.
Акрамя ключа, у кожнага параметра павінен быць указаны тып: напрыклад,ampле, для URL.
Звярніце ўвагу, што вам трэба паўторнаview поўную мадэль YANG, каб атрымаць поўную інфармацыю аб тыпах. Для інтэрфейсаў Test Agent тып мае больш складаную структуру, як паказана ніжэй у кодзе ніжэй.
Цяпер мы можам запусціць скрыпт з дапамогай ncclient. Пры ўмове, што ўсё правільна, тэст будзе пачаты, і яго выкананне будзе адлюстравана ў Цэнтры кіравання:
Калі тэст паспяхова запушчаны, Цэнтр кіравання адкажа ідэнтыфікатарам тэсту. У гэтым эксample, ідэнтыфікатар тэсту роўны 3:
Тэст ID таксама можна знайсці ў URL для тэсту ў графічным інтэрфейсе Цэнтра кіравання. У гэтым эксampле, што URL гэта https://host/demo/testing/3/.
Атрыманне вынікаў тэсту
Самы просты спосаб атрымання вынікаў тэсту - указанне на ідэнтыфікатар тэсту.
Ніжэй прыведзены код Python для атрымання вынікаў прыведзенага вышэй тэсту HTTP з ID = 3:
з кіраўніком. Connect(host=args.host, port=args.port, username=args.username,password=args.password, hostkey_verify=False) як m:
Выхад будзе выглядаць прыкладна так:
Экспарт і імпарт тэставых шаблонаў
Тэставыя шаблоны можна экспартаваць у фармат JSON і паўторна імпартаваць у гэтым фармаце ў Цэнтр кіравання. Гэта карысна, калі вы хочаце выкарыстоўваць тэставыя шаблоны ў іншай устаноўцы Цэнтра кіравання. (Першапачатковае стварэнне шаблонаў лепш за ўсё апрацоўваць праз графічны інтэрфейс Цэнтра кіравання.)
Ніжэй прыведзены код для выканання экспарту і імпарту.
Экспарт тэставых шаблонаў
# Атрымаць канфігурацыю json з адказу
корань = ET.fromstring(response._raw)
json_config = корань[0].тэкст
раздрукаваць json_config
Шаблон змяшчаецца ў аб'екце json_config.
Імпарт шаблонаў тэстаў
Канфігурацыйны аб'ект JSON, які змяшчае тэставыя шаблоны, можна паўторна імпартаваць у Цэнтр кіравання наступным чынам.
Exampлес: Маніторы
У гэтым раздзеле мяркуецца, што тэставыя агенты (столькі, колькі патрабуецца маніторам) былі створаны ў адпаведнасці з раздзелам «Стварэнне і разгортванне новага тэставага агента» на старонцы 17.
Шляхі мадэлі YANG для манітораў
| Пункт | Шлях мадэлі YANG: /accounts/account/monitors … |
| маніторы | /. |
| манітор [імя] | /манітор |
| імя | /манітор/імя |
| апісанне | /манітор/апісанне |
| пачаўся | /monitor/started |
| шаблон | /манітор/шаблон |
| будзільнік-канфігурацыі | /monitor/alarm-configs |
| Пункт | Шлях мадэлі YANG: /accounts/account/monitors/monitor/alarm-configs … |
| alarm-config[ідэнтыфікатар] | /канфігурацыя трывогі |
| ідэнтыфікатар | /alarm-config/identifier |
| шаблон | /alarm-config/template |
| электронная пошта | /alarm-config/email |
| SNMP | /alarm-config/snmp |
| трэ-эс-крытычны | /alarm-config/thr-es-critical |
| thr-es-critical-clear | /alarm-config/thr-es-critical-clear |
| тр-эс-мажор | /alarm-config/thr-es-major |
| тр-эс-мажор-ясна | /alarm-config/thr-es-major-clear |
| трэ-эс-мінор | /alarm-config/thr-es-minor |
| трэ-эс-мінор-ясны | /alarm-config/thr-es-minor-clear |
| thr-es-папярэджанне | /alarm-config/thr-es-warning |
| thr-es-warning-clear | /alarm-config/thr-es-warning-clear |
| без сур'ёзнасці дадзеных | /alarm-config/no-data-severity |
| тайм-аўт без дадзеных | /alarm-config/no-data-timeout |
| дзеянне | /alarm-config/action |
| памер акна | /alarm-config/window-size |
| інтэрвал | /alarm-config/interval |
| адправіць толькі адзін раз | /alarm-config/send-only-once |
| snmp-trap-per-stream | /alarm-config/snmp-trap-per-stream |
| Пункт | Шлях мадэлі YANG: /accounts/account/monitors … |
| параметры | /манітор/параметры |
| Пункт | Шлях да мадэлі YANG: /accounts/account/monitors/monitor/parameters … |
| параметр [ключ] | /параметр |
| ключ | /параметр/ключ |
| (тып значэння) | /параметр |
| :(цэлы лік) | /параметр |
| цэлы лік | /параметр/цэлы лік |
| :(плаваць) | /параметр |
| паплавок | /параметр/float |
| :(радок) | /параметр |
| Пункт | Шлях да мадэлі YANG: /accounts/account/monitors/monitor/parameters … |
| радок | /параметр/радок |
| :(інтэрфейсы тэставага агента) | /параметр |
| тэст-агент-інтэрфейсы | /parameter/test-agent-interfaces |
| інтэрфейс тэставага агента[“1” на старонцы 58 | /parameter/test-agent-interfaces/ |
| рахунак | /parameter/test-agent-interfaces/test-agent-interface/account |
| тэст-агент | /parameter/test-agent-interfaces/test-agent-interface/test-agent |
| інтэрфейс | /parameter/test-agent-interfaces/test-agent-interface/interface |
| ip-версія | /parameter/test-agent-interfaces/test-agent-interface/ip-version |
| :(твamp-адбівальнікі) | /параметр |
| twamp-адбівальнікі | /параметр/твamp-адбівальнікі |
| twamp-адбівальнік [імя] | /параметр/твamp-адбівальнікі/твamp-адбівальнік |
| імя | /параметр/твamp-адбівальнікі/твamp-адбівальнік / наз |
| :(y1731-meps) | /параметр |
| y1731-мепс | /параметр/y1731-meps |
| y1731-mep [імя] | /параметр/y1731-meps/y1731-mep |
| імя | /параметр/y1731-meps/y1731-mep/імя |
| :(сіп-акаўнты) | /параметр |
| sip-акаўнты | /parameter/sip-рахункі |
| sip-рахунак [«2» на старонцы 58] | /parameter/sip-accounts/sip-account |
| рахунак | /parameter/sip-accounts/sip-account/account |
| тэст-агент | /parameter/sip-accounts/sip-account/test-agent |
| інтэрфейс | /parameter/sip-accounts/sip-account/interface |
| sip-адрас | /parameter/sip-accounts/sip-account/sip-address |
| :(IPTV-каналы) | /параметр |
| iptv-каналы | /parameter/iptv-каналы |
| iptv-канал [імя] | /parameter/iptv-channels/iptv-channel |
| імя | /parameter/iptv-channels/iptv-channel/name |
- інтэрфейс тэставага агента ўліковага запісу
- sip-адрас інтэрфейсу тэставага агента ўліковага запісу
| Пункт | Шлях мадэлі YANG: /accounts/account/monitors … |
| статус | /манітор/статус |
| апошнія 15 хвілін | /monitor/status/last-15-minutes |
| статус | /monitor/status/last-15-minutes/status |
| статус-значэнне | /monitor/status/last-15-minutes/status-value |
| апошняя гадзіна | /monitor/status/last-hour |
| статус | /monitor/status/last-hour/status |
| статус-значэнне | /monitor/status/last-hour/status-value |
| апошнія 24 гадзіны | /манітор/статус/апошнія 24 гадзіны |
| статус | /monitor/status/last-24-hours/status |
| статус-значэнне | /monitor/status/last-24-hours/status-value |
| шаблоны | / шаблоны |
| шаблон [імя] | /templates/template |
| імя | /templates/template/name |
| апісанне | /templates/template/description |
| параметры | /templates/template/parameters |
| параметр [ключ] | /templates/template/parameters/parameter |
| ключ | /templates/template/parameters/parameter/key |
| тыпу | /templates/template/parameters/parameter/type |
Перадумовы для аркестравання манітора
Перш чым вы зможаце запусціць манітор праз NETCONF з дапамогай ncclient, вам трэба стварыць шаблон манітора ў графічным інтэрфейсе Цэнтра кіравання, як тлумачыцца ў даведцы праграмы ў раздзеле «Тэсты і маніторы» > «Стварэнне шаблонаў». Усе палі, вызначаныя як «Увод шаблона» ў гэтым шаблоне, будуць неабходныя ў якасці параметраў у XML пры арганізацыі ініцыяцыі шаблона.
Атрыманне ўваходных параметраў з шаблонаў манітора
Ніжэй паказаны два шаблоны. Першы прызначаны для маніторынгу UDP паміж двума інтэрфейсамі тэставага агента, а другі прызначаны для HTTP з выкарыстаннем аднаго інтэрфейсу тэставага агента.
Каб даведацца ўваходныя параметры шаблона, пстрыкніце поле, якое прадстаўляе шаблон. Для шаблону HTTP параметры могуць выглядаць так:
Нам трэба вызначыць гэтыя параметры на наступным этапе пры запуску манітора.
Запуск манітора
Выкарыстоўваючы тэставыя агенты, якія мы вызначылі і разгарнулі ў раздзеле «Стварэнне і разгортванне новага тэставага агента» на старонцы 17, мы можам запусціць манітор з шаблона «HTTP», як паказана ніжэй.
Для кожнага параметру, атрыбут павінен быць пастаўлены. Ключ ідэнтычны назве зменнай параметра ў Цэнтры кіравання. Вы можаце праверыць імёны зменных наступным чынам:
- Націсніце Маніторынг на бакавой панэлі і абярыце Новы манітор.
- Націсніце Мае шаблоны.
- Пстрыкніце спасылку "Рэдагаваць" пад цікавым шаблонам.
- Націсніце кнопку «Рэдагаваць увод» у правым верхнім куце.
У нашай былойample, і па змаўчанні імёны зменных - гэта проста версіі імёнаў, якія адлюстроўваюцца ў малым рэгістры ў Цэнтры кіравання ("url"супраць"URL», і г.д.). Аднак у графічным інтэрфейсе Цэнтра кіравання вы можаце перайменаваць зменныя як заўгодна.
Акрамя ключа, у кожнага параметра павінен быць указаны тып: напрыклад,ampле, для URL. Звярніце ўвагу, што поўная інфармацыя аб тыпе параметру знаходзіцца ў мадэлі YANG. Для інтэрфейсаў Test Agent гэты тып мае больш складаную структуру, як паказана ў кодзе ніжэй.
У эксampдалей, сігналізацыя не звязана з маніторам. Напрыкладampзвязаныя з будзільнікамі, перайдзіце да раздзела «Запуск манітора з сігналізацыяй» на старонцы 62.
Запуск манітора з будзільнікам
Каб звязаць сігнал трывогі з маніторам, вы можаце паказаць на шаблон сігналу, які быў вызначаны, або падаць поўную канфігурацыю сігналу пры стварэнні манітора. Дамо адну эксampле кожнага падыходу ніжэй.
Настройка сігналізацыі манітора, паказваючы на шаблон сігналізацыі
Каб выкарыстоўваць шаблон будзільніка, вы павінны ведаць яго ID. Для гэтага спачатку атрымайце ўсе шаблоны сігналаў, як апісана ў раздзеле «Атрыманне ўсіх шаблонаў сігналаў» на старонцы 39, і запішыце назву адпаведнага шаблону. Затым вы можаце звярнуцца да гэтага шаблону наступным чынам:
Настройка сігналізацыі манітора шляхам яго прамой канфігурацыіy
Акрамя таго, вы можаце наладзіць будзільнік для манітора, указаўшы ўсю яго канфігурацыю пры стварэнні манітора, не спасылаючыся на шаблон сігналізацыі. Гэта робіцца, як паказана ў наступным прыкладзеampле.
Атрыманне запушчаных манітораў
Каб атрымаць усе маніторы, якія зараз выконваюцца, запусціце гэты скрыпт:
з кіраўніком. падключыцца(host=args.host, port=args.port, username=args. user name, password=args.password, hostkey_verify=False) як m:
Выхад - спіс усіх запушчаных манітораў, як паказана ніжэй:
Атрыманне статусу SLA для манітора
Вось як атрымаць статус SLA для манітора. У гэтым эксample, мы атрымліваем статус SLA для манітора «Якасць сеткі» за тры прамежкі часу: апошнія 15 хвілін, апошнюю гадзіну і апошнія 24 гадзіны.
Выхад будзе выглядаць прыкладна так:
Апавяшчэнні NETCONF
Апавяшчэнні NETCONF для манітораў выклікаюцца парушэннем SLA. Яны адбываюцца, калі SLA для манітора апускаецца ніжэй за парогавае значэнне SLA («Добра» або «Прымальна») на працягу зададзенага часовага акна, па змаўчанні апошнія 15 хвілін. Варта адзначыць, што апавяшчэнні аб парушэнні SLA хутка з'яўляюцца пасля таго, як у сэрвісе ўзнікла праблема, у той час як статус SLA вернецца да "Добра" толькі праз 15 хвілін і толькі ў тым выпадку, калі больш не будзе парушэнняў.
Часовае акно можна змяніць шляхам рэдагавання параметра SLA_STATUS_WINDOW (значэнне ў секундах) у /etc/netrounds/netrounds.conf.
Экспарт і імпарт шаблонаў манітора
Робіцца гэта сапраўды гэтак жа, як і для тэставых шаблонаў; параўнайце раздзел «Экспарт і імпарт тэставых шаблонаў» на старонцы 52. Прыведзеныя ніжэй фрагменты кода ілюструюць, як экспартаваць і імпартаваць шаблоны для манітораў.
Экспарт шаблонаў манітора
Імпарт шаблонаў манітора
Tags вызначанае ў Paragon Active Assurance можа прымяняцца да:
- маніторы
- Шаблоны манітораў
- Тэставыя агенты
- TWAMP адбівальнікі
- Пінг хасты.
Напрыкладampле, ты можаш tag манітор з такім жа tag як падмноства тэставых агентаў, якія будуць запускаць манітор. Гэтая функцыя асабліва карысная, калі ў вас вызначана вялікая колькасць манітораў і шаблонаў.
Калі вы наладзілі сігнал трывогі з пасткамі SNMP для манітора, то пасткі SNMP будуць прызначаны аднолькава tags як манітор, калі такі маецца.
Стварэнне Tags
Ніжэй мы пакажам, як стварыць a tag з імем і колерам, вызначанымі ў XMLtag> падбудова.
Прызначэнне Tag
Каб прызначыць а tag да рэсурсу, вы дадаеце яго як новыtag> элемент падtags> элемент для гэтага рэсурсу.
Вось як прызначыць a tag Тэставаму агенту:
Каб прызначыць а tag да TWAMP адбівальнік, зрабіце наступнае:
Прызначэнне tag да манітора апрацоўваецца аналагічна:
Акрамя таго, вы можаце прызначыць існуючы tag да любога з гэтых тыпаў рэсурсаў пры стварэнні рэсурсу, уключыўшыtags> элемент, які змяшчае tag пад пытаннем.
Абнаўленне Tag
Абнаўленне існуючага tag з новымі атрыбутамі аналагічна стварэнню a tag:
Адмена прызначэння Tag
Адмяніць прызначэнне a tag з рэсурсу, дадайце атрыбут nc:operation=”delete” уtag> элемент, які належыць рэсурсу. Ніжэй мы адмяняем прызначэнне a tag з манітора.
Выдаленне a Tag
Каб выдаліць tag увогуле з Цэнтра кіравання зноў выкарыстоўваецца атрыбут nc:operation=”delete”, але на гэты раз да tag сам, вызначаны пад .
Ліквідацыю непаладак
Праблема: Orchestrator і Paragon Active Assurance не сінхранізаваны
Напрыклад, аркестратар і Paragon Active Assurance могуць не сінхранізаваццаample, калі змены канфігурацыі былі зроблены ў графічным інтэрфейсе Цэнтра кіравання, або калі прымяненне канфігурацыі не было паспяховым і адкат да папярэдняга стану не атрымаўся.
У выпадку няўдалага адкату сервер NETCONF больш не будзе прымаць змены канфігурацыі; ён адкажа паведамленнем пра памылку аб тым, што канфігурацыя заблакіравана да вяртання ў сінхранізацыю. Каб аднавіць сінхранізацыю і разблакіраваць змены канфігурацыі, вам трэба запусціць каманду rpc sync-from-ncc, якая сінхранізуе ўсю канфігурацыю з Цэнтра кіравання з базай даных канфігурацыі.
УВАГА: The confd@netrounds.com Карыстальнік (або тое, што было настроена) павінен мець прывілеі суперпользователя, каб усё было паспяхова сінхранізавана. Гэтага можна дасягнуць з дапамогай каманды ncc user-update confd@netrounds.com –is-superuser Калі карыстальнік не з'яўляецца суперкарыстальнікам, з'явіцца папярэджанне аб тым, што не ўсё можа быць сінхранізавана, але ўсё, што можа быць апрацавана, было сінхранізавана.
УВАГА: Калі ваш аркестратар таксама захоўвае канфігурацыю, вам трэба будзе паўторна сінхранізаваць і яе, паколькі запытаная канфігурацыя (канфігурацыя, якую аркестрант чакае, што будзе мець Цэнтр кіравання) не будзе прыменена.
Праблема: першапачатковая сінхранізацыя (sync-from-ncc) не атрымалася з-за непадтрымоўваных рэсурсаў
Калі вы паспрабуеце запусціць rpc sync-from-ncc ва ўліковым запісе, канфігурацыя якога створана ў графічным інтэрфейсе Цэнтра кіравання, вы можаце сутыкнуцца з праблемамі, калі ўліковы запіс змяшчае непадтрымоўваныя рэсурсы. Рэкамендуецца пачынаць з пустога ўліковага запісу і выконваць усю яго наладу праз NETCONF. У адваротным выпадку, калі ў вас узнікнуць праблемы з канфліктамі рэсурсаў, вам прыйдзецца выдаліць канфліктуючыя рэсурсы з уліковага запісу.
Праблема: каманды NETCONF не выконваюцца з ncclient.operations.rpc.RPCError: збой сувязі прыкладання
Сервер NETCONF не аднаўляе злучэнне з серверам Цэнтра кіравання аўтаматычна пры перазапуску Цэнтра кіравання. Каб аднавіць злучэнне з Цэнтрам кіравання, перазапусціце працэс NETCONF: sudo systemctl restart netrounds-confd
Заўвагі аб праграмах тэставых агентаў і прыладах тэставых агентаў
Тэставыя праграмы агента ў ConfD
Сярод тэставых агентаў (навейшае) прыкладанне тэставага агента працуе трохі інакш, чым (старэйшае) прылада тэставага агента.
Праграмы тэставага агента зараз не падтрымліваюць канфігурацыю інтэрфейсу. Такім чынам, схема YANG дазваляе ўказваць пустую канфігурацыю інтэрфейсу для такіх тэставых агентаў. Глядзіце «гэты ўрывак» на старонцы 23 для прыкладуampле.
Пры сінхранізацыі базы дадзеных ConfD з Цэнтрам кіравання з дапамогай каманды sync-from-ncc вы хочаце, каб канфігурацыя інтэрфейсу заставалася пустой і не перазапісвалася тым, што знаходзіцца ў Цэнтры кіравання. Таму вам трэба выкарыстоўваць спецыяльны сцяг –without_interface_config з гэтай камандай пры працы з праграмамі тэставага агента.
Пустая канфігурацыя інтэрфейсу для Test Agent Appliance
Як было адзначана вышэй, праграма Test Agent не падтрымлівае канфігурацыю інтэрфейсу, і таму можна апусціць інтэрфейсы ў схеме YANG.
Але ёсць таксама выпадкі выкарыстання, калі вы можаце апусціць канфігурацыю інтэрфейсу з прылады Test Agent. БылыampГэта можа быць сцэнар аркестроўкі, калі вы раскручваеце тэставы агент з дапамогай cloud-init і хочаце выкарыстоўваць канфігурацыю інтэрфейсу адтуль, а не дазваляць ConfD перазапісваць яго, калі тэставы агент выходзіць у сетку.
Змены ў схеме YANG адносна нявызначаных інтэрфейсаў
Паколькі пустая канфігурацыя інтэрфейсу цяпер дазволена (з версіі 2.34.0), можна ўказаць любое імя інтэрфейсу ў якасці ўваходных дадзеных для задачы, якая выконваецца як частка тэсту або манітора.
Гэта неабходна для таго, каб мець магчымасць выкарыстоўваць прыкладанне тэставага агента, бо для гэтага ў ConfD не вызначаны назвы інтэрфейсаў. Звярніце ўвагу, аднак, што гэта таксама азначае, што вы можаце сутыкнуцца з праблемамі, калі выпадкова наладзіце тэст або манітор на выкарыстанне неіснуючага інтэрфейсу. Таму памятайце пра гэта.
Абмежаванні пры рэгістрацыі тэставага агента, створанага ў ConfD
Пры стварэнні тэставага агента праз REST або NETCONF/YANG API мы не можам ведаць загадзя, які гэта тып: Test Agent Appliance або Test Agent Application. Гэта становіцца зразумела толькі пасля рэгістрацыі Тэст-агента.
Пасля таго, як тэставы агент быў зарэгістраваны і ператварыўся ў адзін з гэтых канкрэтных тыпаў, вы не маеце права паўторна зарэгістраваць яго як іншы тып тэставага агента. Гэта азначае, што вам не дазволена спачатку зарэгістраваць яго як прыладу Test Agent, а потым паўторна зарэгістраваць яе як праграму Test Agent і наадварот. Калі вам патрэбен тэставы агент іншага тыпу, вам трэба будзе стварыць новы тэставы агент.
Дадатак: Дрэвавая структура поўнай мадэлі YANG
У гэтым дадатку раздзел «Легенда» на старонцы 81 тлумачыць сінтаксіс дрэвападобнай структуры мадэлі YANG, створанай з дапамогай каманды pyang -f tree.
У раздзеле «Дрэвападобная структура мадэлі YANG» на старонцы 82 прадстаўлены вынікі гэтай каманды, прымененай да netrounds-ncc.yang. Часткі гэтага выхаду ўзнаўляюцца ў іншых месцах дакумента.
Легенда
Структура дрэва мадэлі YANG
Juniper Networks, лагатып Juniper Networks, Juniper і Junos з'яўляюцца зарэгістраванымі гандлёвымі маркамі Juniper Networks, Inc. у ЗША і іншых краінах. Усе іншыя гандлёвыя маркі, знакі абслугоўвання, зарэгістраваныя знакі або зарэгістраваныя знакі абслугоўвання з'яўляюцца ўласнасцю іх адпаведных уладальнікаў. Juniper Networks не нясе адказнасці за любыя недакладнасці ў гэтым дакуменце. Juniper Networks пакідае за сабой права змяняць, мадыфікаваць, перадаваць або іншым чынам пераглядаць гэтую публікацыю без папярэдняга паведамлення. Аўтарскае права © Juniper Networks, Inc., 2023. Усе правы абаронены.
Дакументы / Рэсурсы
 |
Праграмнае забеспячэнне Juniper NETWORKS NETCONF & YANG API [pdfКіраўніцтва карыстальніка Праграмнае забеспячэнне API NETCONF YANG, праграмнае забеспячэнне YANG API, праграмнае забеспячэнне API, праграмнае забеспячэнне |