Juniper NETWORKS NETCONF & YANG API programmatūras lietotāja rokasgrāmata

Šī dokumenta mērķis
Šajā dokumentācijā ir aprakstīts, kā integrēt Paragon Active Assurance ar tīkla pakalpojumu organizatoru, izmantojot vadības centra NETCONF & YANG API. Praktisks bijušaisampIr sniegti galvenie iesaistītie uzdevumi, tostarp: virtuālo testa aģentu izveide un izvietošana, testu un monitoru palaišana un šo darbību rezultātu izgūšana.
Šajā dokumentā organizētāja lomā tiek izmantots brīvi pieejamais Python NETCONF klienta ncclient.

konvencijas
Šajā dokumentā tiek lietoti šādi saīsinājumi:

Saīsinājums	Nozīme
CLI	Komandrindas interfeiss
EM	Elementu vadītājs
ES	Kļūda otrā
EP deputāts	MEG (Maintenance Entity Group) beigu punkts (ITU-T Y.1731 definīcija) vai uzturēšanas beigu punkts (Cisco definīcija)
NFV	Tīkla funkciju virtualizācija
NFVO	Tīkla funkciju virtualizācijas orķestrētājs
NSD	Tīkla pakalpojuma deskriptors
RPC	Attālās procedūras izsaukums
SIP	Sesijas uzsākšanas protokols
SLA	Pakalpojuma līmeņa līgums
S-VNFM	Īpašs VNF vadītājs
VNF	Virtuālā tīkla funkcija
vTA	Virtuālais testa aģents

Piezīmes par atpakaļejošu saderību

NETCONF & YANG API versijās 2.35.4/2.36.0 noteiktu pieprasījumu validācija tika padarīta stingrāka, lai ievērotu NETCONF standartu. Tas nozīmē, ka klienta kods, kas balstīts uz vecākām šīs rokasgrāmatas versijām, tagad var tikt noraidīts.
Piemēram,ample, iepriekšējā Python example kods, netika nodrošināts nosaukumvietas atribūts. Nosaukumvieta tagad ir jāiesniedz pieprasījuma XML, kad vēlaties modificēt ConfD resursu.

Priekšnoteikumi un sagatavošanās darbi

ConfD instalēšana
ConfD (produkts no Tail-f) tiek izmantots kā starpnieks starp Paragon Active Assurance sistēmu un NETCONF. ConfD savieno Paragon Active Assurance konfigurāciju un darbības datus ar NETCONF & YANG API.
ConfD bija jāinstalē kopā ar vadības centra programmatūru, kā aprakstīts instalēšanas rokasgrāmatā.

Pārbaude, vai ConfD darbojas
Lai pārbaudītu, vai ConfD ir izveidota un darbojas, palaidiet komandu
ssh -s @localhost -p 830 netconf
lai pārbaudītu, vai ConfD reaģē uz 830. portu. Komandā ir tāds, kā to definējis netconf lietotājs izveidot
komandu Instalēšanas rokasgrāmatas sadaļā ConfD instalēšana. Ievadiet paroli, kas noteikta ar to pašu komandu.
Izvadē pārbaudiet, vai ir iekļauts vadības centra modulis. Izvadē jāiekļauj šāda rinda:
http://ncc.netrounds.com?module=netrounds-ncc&revision=2017-06-15

Konfigurācijas datu bāzes sinhronizēšana ar vadības centru

Visbeidzot, mums ir jāatjaunina konfigurācijas datu bāze, izmantojot NETCONF. Mēs to darīsim šeit, izmantojot Python bibliotēku, ko sauc par ncclient (NETCONF klients). Tomēr uzdevumu var veikt arī citā programmēšanas valodā, ja vien tā izmanto NETCONF/YANG protokolu.
Ncclient uzdevums ir darboties kā klientam pret ConfD serveri, kas mitina NETCONF/YANG API.

Ir vērts norādīt, ka ncclient nekādā veidā nav saistīts ar vadības centru (iepriekš "Netrounds Control Center"), lai gan nosaukums sākas ar "ncc".
Lūk, kā instalēt ncclient:

Lejupielādējiet programmatūru no https://github.com/ncclient/ncclient.
Palaidiet šo komandu: pip install ncclient

Tagad mēs varam veikt sinhronizāciju šādi. Uzmanīgi ņemiet vērā, ka tas ir jādara atsevišķā datorā, nevis pašā vadības centra serverī:

#
# PIEZĪME:
# Šis skripts darbojas kā klients pret ConfD, kas darbojas NCC serverī.
# Saziņai tiks izmantota NETCONF/YANG API.

PIEZĪME: šī procedūra ir nepieciešama arī ikreiz, kad testa aģenti ir instalēti un reģistrēti neatkarīgi no NETCONF. Skatiet piezīmi sadaļā “Beigusiesview no Testa aģenta orķestrēšanas” 17. lpp., lai iegūtu papildinformāciju.

Vairāku NETCONF kontrolētu Paragon Active Assurance kontu iestatīšana

Tālāk norādītās darbības ir jāveic tikai tad, ja vēlaties iestatīt citus Paragon Active Assurance kontus, kurus kontrolē NETCONF, papildus kontam, kas šādi konfigurēts Instalācijas rokasgrāmatas sadaļā “ConfD instalēšana”.
Katram šādam kontam rīkojieties šādi:

Vadības centrā piesakieties kontā un dodieties uz Konts > Atļaujas.

Pievienojiet lietotāju "confd@netrounds.com“ un piešķiriet šim ConfD lietotājam administratora atļauju GUI, noklikšķinot uz pogas Uzaicināt.
Sinhronizējiet konfigurācijas datu bāzi ar vadības centru, kā aprakstīts sadaļā “Konfigurācijas datu bāzes sinhronizēšana ar vadības centru” 4. lpp.
Tagad jums vajadzētu būt iespējai kontrolēt vairākus Paragon Active Assurance kontus ar vienu un to pašu ConfD lietotāju.

PIEZĪME: kad sākat kontrolēt Paragon Active Assurance kontu, izmantojot ConfD, NEDRĪKST veikt izmaiņas šajā kontā, izmantojot web GUI attiecībā uz visiem Paragon Active Assurance līdzekļiem, kas ir “config” (skatiet nodaļu “Paragon Active Assurance atbalstītās funkcijas” 9. lpp.). Ja to izdarīsit, tiks zaudēta sinhronizācija.

Ievads NETCONF Orchestration API

Beigāsview

Trešās puses NFVO vai pakalpojumu organizētājs parasti ir komponents, kas uzsāk pārbaudes un uzraudzības sesijas, izmantojot vadības centra API. Šis orķestrētājs arī izgūst testēšanas aģenta darbību apkopotos mērījumu rezultātus. Veiktspējas KPI var izgūt trešās puses veiktspējas pārvaldības sistēmas, savukārt notikumus, ja tos izraisījuši vadības centrā iestatītie sliekšņa pārkāpumi, var nosūtīt uz trešās puses kļūdu pārvaldības sistēmām.
Apkopojot, zemāk esošajā attēlā parādīts, kā Paragon Active Assurance mijiedarbojas ar citām trešo pušu sistēmām OSS vidē.

NFVO/Service Orchestrator: uzdod VNF pārvaldniekam izvietot vTA un konfigurēt Paragon Active Assurance pakalpojumu ķēdē. Kad pakalpojums ir aktivizēts, orķestrētājs izmanto API virzienā uz vadības centru, lai aktivizētu pakalpojuma aktivizēšanas testus un izgūtu apstiprinājuma/neatteices rezultātus. Ja testi ir izturēti, orķestrētājs izmantos API virzienā uz vadības centru, lai sāktu aktīvu pakalpojuma uzraudzību. Uzraudzības KPI nepārtraukti izgūst vai nu orķestrētājs, vai atsevišķa veiktspējas pārvaldības platforma.
Vadības centrs: izvieto, mērogo un pārtrauc vTA saskaņā ar NFVO vai pakalpojumu organizatora norādījumiem.

Veiktspējas pārvaldības sistēma vai pakalpojumu kvalitātes vadības sistēma: nolasa KPI no aktīvās uzraudzības, izmantojot vadības centra API.
Kļūdu pārvaldības sistēma: saņem NETCONF, SNMP vai e-pasta paziņojumus no vadības centra, ja tiek pārkāpti SLA.

Paragon Active Assurance jēdzienu definīcijas

Testa aģenti: komponenti, kas veic mērījumus (pārbaudēm, kā arī monitoriem) Paragon Active Assurance sistēmā. Testa aģenti sastāv no programmatūras, kas spēj ģenerēt, saņemt un analizēt reālu tīkla trafiku.
Šajā dokumentā apskatītais testa aģenta veids ir virtuālais testa aģents (vTA), virtuālā tīkla funkcija (VNF), kas izvietota hipervizorā. Pastāv arī citi testa aģentu veidi.

Paragon Active Assurance ir divi galvenie mērījumu veidi: testi un monitori.
Pārbaude: tests sastāv no viena vai vairākiem posmiem, no kuriem katram ir noteikts, ierobežots ilgums. Darbības tiek veiktas secīgi. Katrs solis var ietvert vairāku uzdevumu vienlaicīgu izpildi.

Monitors: monitoram nav noteikta ilguma, bet tas darbojas bezgalīgi. Tāpat kā testa solis, monitors var izpildīt vairākus vienlaikus uzdevumus.
Veidne: ja Paragon Active Assurance kontrolē orķestrētājs, testi un monitori vienmēr tiek izpildīti, izmantojot veidnes, kurās ir definēts tests vai monitors. Parametru iestatījumus izpildlaikā var nodot kā ievadi veidnei.

Automatizācijas darbplūsma
Dizaina laiks

Projektēšanas laikā jūs sagatavojat mērījumus, izveidojot veidnes testiem un monitoriem pakalpojumā Paragon Active Assurance. Kā to izdarīt, ir aprakstīts sadaļā “Testēt un pārraudzīt veidnes” 15. lpp.

Izpildes laiks
Izpildes laikā jūs iestatāt savas ierīces un veicat faktiskos mērījumus.

Beigasview no visiem bijušajiemampdotais ir atrodams nodaļā “PiemampParagon Active Assurance kontrole, izmantojot NETCONF & YANG API” 15. lpp.
Pārbaudes aģentu izvietošana un konfigurēšana ir aprakstīta nodaļā “Piemamples: Testa aģenti” 16. lpp.

Kā importēt krājumu preces, piemēram, TWAMP atstarotāji un IPTV kanāli ir apskatīti nodaļā “Piemamples: Inventāra preces” 29. lpp.
Kā konfigurēt trauksmes signālus, ir paskaidrots nodaļā “Piemamples: Trauksmes” 35. lpp.

Kā palaist testus un monitorus, izpildot Paragon Active Assurance veidnes, izmantojot NETCONF, ir aprakstīts nodaļās “Piem.amples: Testi” 43. lpp. un „Piemamples: Monitori” 54. lpp.

Paragon Active Assurance atbalstītās funkcijas

Visus testu un monitoru veidus programmā Paragon Active Assurance var izveidot un izpildīt, izmantojot veidnes. Kā to izdarīt, ir aprakstīts lietotnes palīdzības sadaļā “Testi un monitori” > “Veidņu izveide”.

Paragon Active Assurance kontu izveide pašlaik netiek atbalstīta; tomēr lietotājam būs izveidots viens vai vairāki iepriekš definēti konti.
Tālāk esošajās tabulās ir detalizēti aprakstīts, kuras Paragon Active Assurance funkcijas ir pieejamas šajā laidienā un kā šīs funkcijas ir attēlotas YANG.

YANG konstrukciju skaidrojums

Ērtības labad šeit ir sniegtas funkciju tabulā minēto YANG konstrukciju definīcijas.

Config (config=true): konfigurācijas dati, kas nepieciešami, lai pārveidotu sistēmu no viena stāvokļa uz citu.
Stāvoklis (config=false): stāvokļa dati: papildu dati par sistēmu, kas nav konfigurācijas dati, piemēram, tikai lasāma statusa informācija un apkopotā statistika.
RPC: attālās procedūras izsaukums, ko izmanto NETCONF protokolā.
Paziņojums: notikumu paziņojumi, kas nosūtīti no NETCONF servera uz NETCONF klientu.

Orķestrēšanai pieejamas Paragon Active Assurance līdzekļu tabulas
Resurss: Monitorings
YANG ceļš:/konti/konts/monitori

Funkcija	Apakšfunkcija	YANG konstrukcija
Izveidot/mainīt/dzēst monitoru	Pamatojoties uz monitora veidni	Konfig
Start/stop monitors	–	Konfig
Monitora veidnes	Norādiet esošās monitora veidnes ar ieejām	valsts
NETCONF paziņojumi	Trauksmes stāvoklis mainīts	Paziņojums
Uzraudzīt rezultātus	SLA/ES skaitītājs augstākajam līmenim (%) SLA/ES skaitītājs uzdevuma līmenim (%)	valsts

Atšķirībā no testiem (salīdzināt resurss: testi tālāk), monitori netiek startēti ar RPC, bet gan, veicot monitora konfigurāciju.
Resurss: Testi
YANG ceļš: /accounts/account/tests

Funkcija	Apakšfunkcija	YANG konstrukcija
Sāciet testu	Pamatojoties uz testa veidni	RPC
Pārvaldīt testus	Uzskaitiet testus ar statusu	valsts
Testa veidnes	Norādiet esošās testa veidnes ar ievadi	valsts
NETCONF paziņojumi	Pārbaudes statuss ir mainīts	Paziņojums
Testa rezultāti	Iegūstiet testa soļa statusu (nokārtots, neizdevies, kļūda utt.)	valsts

Resurss: Testa aģenti
YANG ceļi:

/accounts/account/test-agents (Config)
/accounts/account/registred-test-agents (štats)

Testa aģenti sadaļā /accounts/account/test-agents ir tie, kas ir konfigurēti kontā. Orķestris var konfigurēt un izmantot testos un monitoros, izmantojot NETCONF tikai šos testa aģentus.
Kad esat konfigurējis testa aģentu un tas ir reģistrējies kontā, testa aģents parādīsies sadaļā /accounts/account/registered-test-agents. Jūs varat atrast visus reģistrētos testa aģentus, izmantojot NETCONF komandu “get” (salīdziniet nodaļu Piemamples: Testa aģenti).
Sadaļā /accounts/account/registered-test-agents varat atrast arī testēšanas aģentus, kas vēl nav konfigurēti. Jebkurš šāds testa aģents ir jākonfigurē, pirms tos var izmantot.
Orķestrācijas scenārijā parasti ir ieteicams visu sava Paragon Active Assurance konta konfigurēšanu veikt, izmantojot NETCONF. Tas nodrošina, ka testa aģenti un reģistrētie testa aģenti neatšķiras.

Funkcija	Apakšfunkcija	YANG konstrukcija
Serverī iepriekš izveidojiet testa aģentu	–	Konfig
Konfigurējiet bezsaistes testa aģentu	(Vadības centrs nospiež konfigurāciju testa aģentam kad tas ir tiešsaistē)	Konfig
Izmantojiet esošos/ārēji konfigurētos testa aģentus	Izmantot testā/monitorā	Konfig
	Konfigurēt saskarnes	Konfig
	Iegūstiet statusu	valsts
Konfigurēt testa aģentu (tikai testa ierīcei)	Konfigurējiet NTP	Konfig
	Konfigurēt tiltus	Konfig
	Konfigurējiet VLAN saskarnes	Konfig
	Konfigurējiet SSH atslēgas	Konfig
	IPv6	Konfig
Utils	Reboot	RPC
	Atjaunināt	RPC
NETCONF paziņojumi	Tiešsaistes statuss ir mainīts	Paziņojums
Statuss	Iegūstiet sistēmas statusu (darbspējas laiku, atmiņas lietojumu, vidējā slodze, versija)	valsts

Resurss: Inventārs
YANG ceļš: /accounts/account/twamp- atstarotāji

Atbalstītās NETCONF iespējas

Tālāk esošajā tabulā ir norādīts uz IETF RFC, kas apraksta NETCONF iespējas, kas tiek izmantotas Paragon Active Assurance orķestrēšanai.

ietf-netconf.yang
IETF RFC 6241, tīkla konfigurācijas protokols (NETCONF), https://tools.ietf.org/html/rfc6241
Vienīgā atbalstītā kļūdu apstrādes metode ir atcelšana kļūdas gadījumā.
Vienīgais atbalstītais datu veikals ir rakstāms.
ietf-netconf-notifications.yang
IETF RFC 5277, NETCONF notikumu paziņojumi, https://tools.ietf.org/html/rfc5277

Pārbaudīt un pārraudzīt veidnes
Pārbaužu un monitoru veidu veidnes ir jāiestata manuāli, izmantojot Paragon Active Assurance priekšgala lietotāja interfeisu. Kā to izdarīt, ir aprakstīts lietotnes palīdzības sadaļā “Testi un monitori” > “Veidņu izveide”.

ExampParagon Active Assurance kontrole, izmantojot NETCONF un YANG API

Nākamajās nodaļās tiek pieņemts, ka ir definētas piemērotas testa un monitora veidnes saskaņā ar norādījumiem, kas sniegti nodaļā “Pārbaudes un monitora veidnes” 15. lpp.

Rīki, kas izmantoti piemamples
Visi bijušieampturpmākajās nodaļās ir veidotas, izmantojot šādus brīvi pieejamus rīkus:

Pang: izmanto, lai vizualizētu un pārlūkotu YANG modeļus.
Pieejams plkst https://github.com/mbj4668/pyang (klonējiet no git un palaidiet python setup.py install).
Python NETCONF klients “ncclient”: izmanto, lai sazinātos ar vadības centru, izmantojot NETCONF.

Pieejams vietnē https://github.com/ncclient/ncclient (palaist pip install ncclient).
Netrounds-ncc.yang datu modelis ir atrodams mapē /opt/netrounds-confd, kad ConfD ir instalēts saskaņā ar instalēšanas rokasgrāmatu).

Beigāsview no galvenajiem veiktajiem uzdevumiem

(Turpmāk ir parādīti arī daži papildu uzdevumi.)

“Jauna testa aģenta izveide un izvietošana” 16. lpp
“Inventāra priekšmetu (piem., atstarotāju) izveide” 29. lpp
“Trauksmes veidņu iestatīšana un trauksmes signālu sūtīšanas vieta” 35. lpp

“Pārbaudes izveide un izpilde” 45. lpp
“Pārbaudes rezultātu izgūšana” 50. lpp
“Monitora palaišana (ietver trauksmju iestatīšanu)” 60. lpp
“SLA statusa izgūšana monitoram” 67. lpp
“Strādājot ar tags”71. lpp

Examples: Testa aģenti

Beigāsview testa aģentu orķestrēšana
Pārbaudes aģenti programmā Paragon Active Assurance tiek uzskatīti par “konfigurāciju” orķestrēšanas kontekstā. Tas nozīmē, ka testa aģentu izveide, kontrole un dzēšana jāveic, izmantojot orķestrētāju un NETCONF, nevis Paragon Active Assurance GUI.
SVARĪGI! Ja testēšanas aģentu instalējis tehniķis un reģistrējis vadības centrā, vispirms to neizveidojot, izmantojot NETCONF & YANG API, testa aģents nepastāvēs konfigurācijas datu bāzē un sistēma netiks sinhronizēta. Lai ConfD uzzinātu par testa aģentu šajā gadījumā, būs jāveic jauna sinhronizācija ar vadības centru, kā norādīts sadaļā “Konfigurācijas datu bāzes sinhronizācija ar vadības centru” 4.

Tāpēc virtuālo testa aģentu (vTA) organizēšana jāveic šādās darbībās:

Izveidojiet virtuālo testa aģentu, ieskaitot tā interfeisa konfigurāciju, izmantojot vadības centra saskarni NETCONF & YANG. Testa aģenta nosaukums būs tā unikālā atslēga.
Izvietojiet vTA virtualizācijas platformā. Izpildiet norādījumus tiešsaistes palīdzības sadaļā Testa aģenti > Instalēšana. Pamata saskarnes konfigurācija, kas ļauj vTA izveidot savienojumu ar vadības centru, kā arī autentifikācijas akreditācijas dati tiek nodrošināti vTA, izmantojot mākoņa iniciatora lietotāja datus.
Kad vTA ir sāknēts, tas automātiski izveidos savienojumu ar vadības centru, izmantojot šifrētu OpenVPN savienojumu. Tiek nosūtīts NETCONF paziņojums, jo vTA testa aģenta statusa maiņas parametra vērtība tagad ir mainīta uz “online”.
PIEZĪME: Tā kā vTA nosaukums ir tā identifikators vadības centrā, šim nosaukumam ir jābūt tādam pašam kā tas, kas definēts vadības centrā “1. darbībā” 17. lpp.
Kad vTA ir pievienots vadības centram un autentificēts, interfeisa konfigurācija tiek pārsūtīta uz vTA. Šī ir saskarnes konfigurācija, kas sniegta “1. solī” 17. lpp., kad vTA tika izveidots vadības centrā.

Kad vTA ir pildījis savu mērķi, izdzēsiet vTA.

Jauna testa aģenta izveide un izvietošana

Vispirms mums ir jāizveido testa aģents, izmantojot vadības centra saskarni NETCONF & YANG. Kad testa aģents ir izveidots šādā veidā, nav nepieciešama sinhronizācija ar vadības centru.
Testa aģenta YANG modelis ir tāds, kā parādīts zemāk. To iegūst kā komandas izvadi
pyang -f tree netrounds-ncc.yang
Pilns YANG modelis ir sniegts sadaļā “Pielikums: Pilna YANG modeļa koka struktūra” 81. lpp., kurā ir arī leģenda, kas izskaidro konvencijas, kas izmantotas šajā un citās YANG modeļa ilustrācijās šajā dokumentā.

Mēs turpinām šādas darbības, kas sīkāk aprakstītas tālāk.

Sākumā Paragon Active Assurance konta “demonstrācija” krājumos nav neviena testa aģenta.
Testa aģents ar nosaukumu “vta1” tiek izveidots, izmantojot ncclient. Šajā stage, īsts testa aģents vēl nepastāv (tas ir, tas vēl nav palaists).
Testa aģents ir izvietots programmā OpenStack. (Izvietošana šajā platformā šeit ir izvēlēta kā viena iespēja starp citām.)

Testa aģents izveido savienojumu ar Control Center konta “demonstrāciju” un tagad ir gatavs lietošanai.
1. darbība. Sākumā kontā “demonstrācija” nav neviena testa aģenta. Skatiet tālāk redzamo ekrānuzņēmumu no vadības centra GUI.2. darbība. Kontroles centrā tiek izveidots pārbaudes aģents, izmantojot Python NETCONF klientu “ncclient”. Tālāk ir sniegts ncclient kods testa aģenta izveidei ar vienu fizisko saskarni ar DHCP adresi:

importēt argparse
no ncclient importa pārvaldnieka
parser = argparse.ArgumentParser(description='Pārbaudīt testa aģenta izveidi')
parser.add_argument('–host', help='Resursdatora nosaukums, kurā tiek atrasts ConfD', required=True)
parser.add_argument('–port', help='Ports, lai izveidotu savienojumu ar ConfD', required=True)
parser.add_argument('–lietotājvārds', help='Lietotājvārds, lai izveidotu savienojumu ar ConfD', required=True)
parser.add_argument('–password', help='ConfD konta parole', required=True)
parser.add_argument('–netrounds-account', help='NCC konta īsais nosaukums', required=True)
parser.add_argument('–test-agent-name', help='Testēšanas aģenta nosaukums',obligāts = True)
args = parser.parse_args()
ar manager.connect(host=args.host, port=args.port, lietotājvārds=args.lietotājvārds,
password=args.password, hostkey_verify=False) kā m:
# Izveidojiet pārbaudes aģentu vadības centrā
xml = """

)print m.edit_config(target='darbojas', config=xml)

PIEZĪME: Kods, kas ir priekšā ar manager.connect(…), tiek izlaists nākamajā piemample koda fragmentus.
NTP serveris ir konfigurēts uz eth0, un eth0 ir arī pārvaldības saskarne (tas ir, saskarne, kas savieno ar vadības centru).
Testa aģenta lietojumprogramma pašlaik neļauj konfigurēt saskarnes. Šī iemesla dēļ, sākot no versijas 2.34.0, YANG shēmā ir iespējams izlaist saskarnes konfigurāciju. Tāpēc šajā gadījumā atbilstošais XML ir radikāli vienkāršots:Kad testa aģents ir izveidots, tas pastāv konfigurācijas datu bāzē un vadības centrā. Skatiet zemāk esošo ekrānuzņēmumu ar testa aģenta inventāru, kurā parādīts testa aģents “vta1”.

3. darbība. Tagad ir pienācis laiks OpenStack izvietot testa aģentu “vta1”.
Testa aģents izmantos mākoņa iniciatora lietotāja datus, lai izgūtu informāciju par savienojuma izveidi ar vadības centru. Konkrēti, lietotāja datu teksts file ir šāds saturs (Ņemiet vērā, ka ir jābūt rindiņām #cloud-config un netrounds_test_agent un ka pārējām rindām jābūt atkāpēm):

Lai iegūtu papildinformāciju, lūdzu, skatiet dokumentu Kā izvietot virtuālos testa aģentus programmā OpenStack.
Kad testa aģents ir izvietots un ir izveidots savienojums ar vadības centru, konfigurācija tiks pārsūtīta no vadības centra uz testa aģentu.

4. darbība. Testa aģents tagad ir tiešsaistē vadības centrā un ir ieguvis konfigurāciju. Testa līdzeklis ir gatavs lietošanai pārbaudēs un uzraudzībā. Skatiet šīs sadaļas:

“Pārbaudes sākšana” 45. lpp
“Monitora palaišana” 60. lpp

Pārbaudes aģentu uzskaitījums jūsu Paragon Active Assurance kontā
Zemāk ir bijušaisample ncclient Python kods testa aģentu uzskaitīšanai Paragon Active Assurance kontā:

Palaižot šo kodu, tiek iegūta šāda izvade:

Testa aģenta dzēšana
Pēc testa pabeigšanas dažos lietošanas gadījumos var būt svarīgi dzēst testa aģentu.
Tālāk ir sniegts koda fragments, kas parāda, kā to izdarīt ar ncclient:

NETCONF paziņojumi
Zemāk mēs piedāvājam vienkāršu bijušoampskripts visu ienākošo NETCONF paziņojumu noklausīšanai no vadības centra. Šie paziņojumi tiek nosūtīti ikreiz, kad notiek noteikti notikumi, piemēram, testa aģents pāriet bezsaistē vai tiek pabeigta lietotāja iniciēta pārbaude. Pamatojoties uz paziņojumos sniegto informāciju, lietotāji var orķestratorā piešķirt automatizētas turpmākās darbības.

Kad iepriekš minētais skripts ir izpildīts, NC klients uzrādīs saņemto paziņojumu strukturētā XML formātā. Skatīt bijušoample izvade, kas parāda, ka testa aģents negaidīti pāriet bezsaistē.

2017-02-03T15:09:55.939156+00:00</eventTime>
<test-agent-status-change xmlns=’http://ncc.netrounds.com'>
demo
HW1
bezsaistē

Examples: Inventāra preces

Inventāra vienumu, piemēram, TW, izveide (importēšana) un pārvaldībaAMP atstarotāji un Y.1731 MEP tiek veikti līdzīgi kā testēšanas aģentiem. Tālāk ir norādīts XML un NETCONF kods šādu entītiju definēšanai programmā Paragon Active Assurance, izmantojot NETCONF & YANG API, un definēto vienumu sarakstu izgūšanai.

TW izveideAMP Atstarotājs

Y.1731 EP deputāta izveide

IPTV kanāla izveide

Ping resursdatora izveide

SIP konta izveide

Inventāra preču izgūšana
Tālāk ir norādīts Python kods visu kontā definēto krājumu vienumu izgūšanai. (Visu veidu krājumu preces šeit tiek ienestas vienā piegājienā, lai izvairītos no atkārtošanās dokumentā. Protams, jebkuru krājumu vienību apakškopu var ielādēt, atstājot dažas no tālāk norādītajām rindiņām.)

Palaižot šo kodu, tiek iegūta šāda izvade:

Examples: Signalizācijas

Trauksmes veidnes un saistītie vienumi (SNMP pārvaldnieki, trauksmes e-pasta saraksti) tiek izveidoti un pārvaldīti līdzīgi kā inventāra preces. Šajā nodaļā ir XML un NETCONF kods šādu entītiju definēšanai programmā Paragon Active Assurance, izmantojot NETCONF & YANG API, un definēto vienumu sarakstu izgūšanai.
Trauksmes e-pasta saraksti
Trauksmes e-pasta saraksta izveide

Visu trauksmes e-pasta sarakstu izgūšana

SNMP pārvaldnieki
SNMP pārvaldnieka izveide

Visu SNMP pārvaldnieku izgūšana

Trauksmes veidnes
Trauksmes veidnes izveide

Notiek visu trauksmes veidņu izgūšana

Examples: SSH atslēgas

Varat pievienot SSH publiskās atslēgas testa aģentam, izmantojot NETCONF & YANG API. Izmantojot atbilstošo privāto atslēgu, varat pieteikties testa aģentā, izmantojot SSH.
Pilns pieejamo darbību saraksts ar SSH atslēgām ir šāds:

Pievienojiet SSH atslēgu
Modificējiet SSH atslēgu
Pārbaudiet SSH atslēgu
Uzskaitiet SSH atslēgas
Izdzēsiet SSH atslēgu.
Tālāk ir sniegts pievienošanas un dzēšanas darbību piemērs.

SSH atslēgas pievienošana

Lūk, kā izveidot jaunu SSH atslēgu.

Juniper NETWORKS NETCONF & YANG API programmatūra — atslēga

SSH atslēgas dzēšana
Ja vēlaties izdzēst SSH atslēgu, izmantojiet šo komandu:

Examples: Testi

Šeit tiek pieņemts, ka testa aģenti (tik daudz, cik nepieciešams testiem) ir izveidoti saskaņā ar sadaļu “Jauna testa aģenta izveide un izvietošana” 17. lpp.
YANG modeļu ceļi testiem

Vienums	YANG modeļa ceļš: /accounts/account/tests…
testiem	/.
tests[id]	/tests
id	/test/id
nosaukums	/tests/nosaukums
statusu	/tests/statuss
sākuma laiks	/tests/sākuma laiks
beigu laiks	/test/beigu laiks
atskaite-url	/testa ziņojums-url
soļi	/test/soļi
solis[id]	/test/soļi/solis
nosaukums	/test/soļi/solis/nosaukums
id	/test/steps/step/id
sākuma laiks	/test/steps/step/start-time
beigu laiks	/test/steps/step/end-time
statusu	/test/steps/step/status
statusa ziņojums	/test/steps/step/status-message
veidnes	/veidnes
veidne[vārds]	/templates/template
nosaukums	/templates/template/name
apraksts	/templates/template/description
parametrus	/templates/template/parameters
parametrs [atslēga]	/templates/template/parameters/parameter
taustiņu	/templates/template/parameters/parameter/key
veids	/templates/template/parameters/parameter/type

Priekšnosacījumi testa orķestrēšanai

Lai sāktu testu, izmantojot NETCONF, izmantojot NC klientu, vispirms ir jāizveido testa veidne, izmantojot vadības centra GUI, kā aprakstīts lietotnes palīdzībā sadaļā “Testi un monitori” > “Veidņu izveide”. Visi lauki, kas šajā veidnē norādīti kā “Veidnes ievade”, būs nepieciešami kā parametri XML, organizējot testa veidnes sākšanu.

Pārbaužu veikšana programmā Paragon Active Assurance tiek uzskatīta par “stāvokli” orķestrēšanas kontekstā. Stāvokļa dati ir neierakstāmi dati, kas netiek glabāti konfigurācijas datu bāzē, atšķirībā no konfigurācijas datiem, kas minēti sadaļā “Overview Tas nozīmē, ka izmaiņas testos vai veidnēs vadības centra GUI neradīs nekādas ar sinhronizāciju saistītas problēmas starp vadības centru un konfigurācijas datu bāzi.
Lai saņemtu atskaiti -URL tieši testa pārskatos, jums ir jāpārliecinās, ka vadības centrs URL ir pareizi konfigurēts. Tas tiek darīts file /opt/netrounds-confd/settings.py. Pēc noklusējuma vadības centra resursdatora nosaukums tiek izgūts, izmantojot socket.gethostname(): skatiet tālāk. Ja tas nedod pareizo rezultātu, jums jāiestata resursdatora nosaukums (vai viss URL) manuāli šajā file.

# URL no vadības centra bez slīpsvītras.
# Tas ir paredzēts piemampizmantots testa ziņojumā-url.
HOSTNAME = socket.gethostname()
NETROUNDS_URL = 'https://%s' % HOSTNAME
Pārbaudes sākšana
Kā aprakstīts sadaļā “Jauna testa aģenta izveide un izvietošana” 17. lpp., palaidiet komandu pang -f tree netrounds-ncc.yang
no direktorijas /opt/netrounds-confd/, lai izvadītu YANG modeli. Šajā modelī RPC testa sākšanai, izmantojot NC klientu, izskatās šādi:

Paskaidrojumus skatiet sadaļā “Leģenda” 81. lpp pielikumā.

Tālāk ir parādītas šādas darbības.

Pārbaudes aģenti ir reģistrēti Paragon Active Assurance kontā, taču testi vēl nav sākti.
Nepieciešamie ievades parametri ir norādīti testa veidnē, kas tiks izpildīta.

Tiek sākts 60 sekunžu HTTP tests, izmantojot ncclient.

Solis 1: Sākumā Paragon Active Assurance kontā netika uzsākta neviena pārbaude. Skatiet tālāk redzamo ekrānuzņēmumu no vadības centra GUI.
Solis 2: veidne, ko izmantosim, lai sāktu pārbaudi šajā piemample ir HTTP testa veidne. Tam ir divi obligāti ievades lauki ( Klienti un URL), kuru kā tādu esam norādījuši, veidojot veidni vadības centra GUI.

Mēs definēsim šos parametrus (cita starpā) XML konfigurācijā, ko mūsu NETCONF pārvaldnieks (ncclient) paziņojis konfigurācijas datu bāzei.
3. darbība: HTTP pārbaude tiek uzsākta, izmantojot ncclient.
Zemāk ir bijušaisample kods, kur HTTP testa veidnei ir norādīta nepieciešamā konfigurācijas informācija un parametri. Atkarībā no tā, kā veidne ir izveidota, šeit sniegtā informācija var atšķirties.
Katram parametram ir jānorāda atribūts. Atslēga ir identiska parametram
Mainīgā nosaukums vadības centrā. Varat pārbaudīt mainīgo nosaukumus šādi:

Sānu joslā noklikšķiniet uz Testi un atlasiet Jauna testa secība.

Noklikšķiniet uz Manas veidnes.
Noklikšķiniet uz saites Rediģēt zem interesējošās veidnes.
Augšējā labajā stūrī noklikšķiniet uz pogas Rediģēt ievadi.

Mūsu bijušajāample, un pēc noklusējuma mainīgo nosaukumi ir vienkārši vadības centrā redzamo parādāmo nosaukumu mazo burtu versijas (“url"pret"URL” utt.). Tomēr vadības centra GUI varat pārdēvēt mainīgos uz to, ko vēlaties.
Papildus atslēgai katram parametram ir jānorāda tā veids: piemēramample, priekš URL.
Lūdzu, ņemiet vērā, ka jums ir nepieciešams atkārtotiview pilnu YANG modeli, lai iegūtu pilnu informāciju par veidiem. Testa aģenta saskarnēm tipam ir sarežģītāka struktūra, kā norādīts tālāk zemāk esošajā kodā.

Tagad mēs varam palaist skriptu, izmantojot ncclient. Pieņemot, ka viss ir pareizi, tests tiks uzsākts un tā izpilde tiks parādīta vadības centrā:Ja pārbaude ir veiksmīgi sākta, vadības centrs atbildēs ar testa ID. Šajā bijušajāample, testa ID ir 3:Testa ID var atrast arī URL pārbaudei vadības centra GUI. Šajā bijušajāample, tas URL ir https://host/demo/testing/3/.
Pārbaudes rezultātu izgūšana
Vienkāršākais veids, kā iegūt testa rezultātus, ir norādīt uz testa ID.
Zemāk ir Python kods, lai iegūtu rezultātus no iepriekš minētā HTTP testa ar ID = 3:
ar menedžeri. Connect(host=args.host, port=args.port, username=args.username,password=args.password, hostkey_verify=False) kā m:

Izvade izskatīsies apmēram šādi:

Testa veidņu eksportēšana un importēšana
Testa veidnes var eksportēt JSON formātā un atkārtoti importēt šajā formātā vadības centrā. Tas ir noderīgi, ja vēlaties izmantot testa veidnes citā vadības centra instalācijā. (Sākotnējo veidņu izveidi vislabāk var veikt, izmantojot vadības centra GUI.)
Zemāk ir kods eksporta un importa veikšanai.
Pārbaudes veidņu eksportēšana

# Iegūstiet json konfigurāciju no atbildes
sakne = ET.fromstring(atbilde._neapstrādāts)
json_config = root[0].text
izdrukāt json_config
Veidne ir ietverta objektā json_config.
Testa veidņu importēšana
JSON konfigurācijas objektu, kurā ir testa veidnes, var atkārtoti importēt vadības centrā šādi.

Examples: Monitori

Šajā sadaļā tiek pieņemts, ka testa aģenti (tik daudz, cik nepieciešams monitoriem) ir izveidoti saskaņā ar sadaļu “Jauna testa aģenta izveide un izvietošana” 17. lpp.
YANG modeļu ceļi monitoriem

Vienums	YANG modeļa ceļš: /accounts/account/monitors…
monitori	/.
monitors[vārds]	/ monitors
nosaukums	/monitors/nosaukums
apraksts	/monitor/description
sākās	/monitor/started
veidni	/monitor/template
modinātāja konfigurācijas	/monitor/alarm-configs
Vienums	YANG modeļa ceļš: /accounts/account/monitors/monitor/alarm-configs…
alarm-config[identifikators]	/alarm-config
identifikators	/alarm-config/identifier
veidni	/alarm-config/template
e-pasts	/alarm-config/email
snmp	/alarm-config/snmp
th-es-kritisks	/alarm-config/thr-es-critical
thr-es-critical-clear	/alarm-config/thr-es-critical-clear
thr-es-major	/alarm-config/thr-es-major
thr-es-major-clear	/alarm-config/thr-es-major-clear
th-es-minor	/alarm-config/thr-es-minor
thr-es-minor-clear	/alarm-config/thr-es-minor-clear
thr-es-brīdinājums	/alarm-config/thr-es-warning
thr-es-warning-clear	/alarm-config/thr-es-warning-clear
bezdatu-nopietnība	/alarm-config/no-data-severity
no-datu taimauts	/alarm-config/no-data-timeout
darbība	/alarm-config/action
loga izmērs	/alarm-config/window-size
intervāls	/alarm-config/interval
sūtīt tikai vienu reizi	/alarm-config/send-only-one
snmp-trap-per-stream	/alarm-config/snmp-trap-per-stream
Vienums	YANG modeļa ceļš: /accounts/account/monitors…
parametrus	/monitor/parameters
Vienums	YANG modeļa ceļš: /accounts/account/monitors/monitor/parameters…
parametrs [atslēga]	/parametrs
taustiņu	/parameter/key
(vērtības veids)	/parametrs
:(vesels skaitlis)	/parametrs
vesels skaitlis	/parametrs/vesels skaitlis
:(peldēt)	/parametrs
peldēt	/parametrs/pludiņš
:(virkne)	/parametrs
Vienums	YANG modeļa ceļš: /accounts/account/monitors/monitor/parameters…
virkne	/parameter/string
:(testa aģenta saskarnes)	/parametrs
testa aģenta saskarnes	/parameter/test-agent-interfaces
test-agent-interface [“1” 58. lpp	/parameter/test-agent-interfaces/
kontu	/parameter/test-agent-interfaces/test-agent-interface/account
testa aģents	/parameter/test-agent-interfaces/test-agent-interface/test-agent
saskarne	/parameter/test-agent-interfaces/test-agent-interface/interface
ip versija	/parameter/test-agent-interfaces/test-agent-interface/ip-version
:(twamp-atstarotāji)	/parametrs
twamp- atstarotāji	/parameter/twamp- atstarotāji
twamp-atstarotājs [vārds]	/parameter/twamp-atstarotāji/twamp- atstarotājs
nosaukums	/parameter/twamp-atstarotāji/twamp-atstarotājs/nosaukums
:(y1731-meps)	/parametrs
y1731-meps	/parameter/y1731-meps
y1731-mep[vārds]	/parameter/y1731-meps/y1731-mep
nosaukums	/parameter/y1731-meps/y1731-mep/name
:(sip-konti)	/parametrs
sip-konti	/parameter/sip-accounts
sip-account [“2” 58. lpp.]	/parameter/sip-accounts/sip-account
kontu	/parameter/sip-accounts/sip-account/account
testa aģents	/parameter/sip-accounts/sip-account/test-agent
saskarne	/parameter/sip-accounts/sip-account/interface
sip-adrese	/parameter/sip-accounts/sip-account/sip-address
:(iptv-kanāli)	/parametrs
iptv kanāli	/parameter/iptv-channels
iptv-kanāls [nosaukums]	/parameter/iptv-channels/iptv-channel
nosaukums	/parameter/iptv-channels/iptv-channel/name

konta testa aģenta saskarne
konta testa aģenta saskarnes sip-adrese

Vienums	YANG modeļa ceļš: /accounts/account/monitors…
statusu	/monitor/statuss
pēdējās 15 minūtes	/monitor/status/pēdējās 15 minūtes
statusu	/monitor/status/pēdējās 15 minūtes/statuss
statusa vērtība	/monitor/status/last-15-minutes/status-value
pēdējā stunda	/monitor/status/pēdējā stunda
statusu	/monitor/status/last-hour/status
statusa vērtība	/monitor/status/last-hour/status-value
pēdējās 24 stundas	/monitor/status/pēdējās 24 stundas
statusu	/monitor/status/last-24-hours/status
statusa vērtība	/monitor/status/last-24-hours/status-value
veidnes	/veidnes
veidne[vārds]	/templates/template
nosaukums	/templates/template/name
apraksts	/templates/template/description
parametrus	/templates/template/parameters
parametrs [atslēga]	/templates/template/parameters/parameter
taustiņu	/templates/template/parameters/parameter/key
veids	/templates/template/parameters/parameter/type

Priekšnosacījumi monitoru orķestrēšanai
Lai varētu palaist monitoru, izmantojot NETCONF, izmantojot ncclient, vadības centra GUI ir jāizveido monitora veidne, kā paskaidrots lietotnes palīdzības sadaļā “Testi un monitori” > “Veidņu izveide”. Visi lauki, kas šajā veidnē norādīti kā “Veidnes ievade”, būs nepieciešami kā parametri XML, organizējot veidnes iniciēšanu.
Ievades parametru iegūšana no monitora veidnēm
Zemāk ir parādītas divas veidnes. Pirmais ir paredzēts UDP uzraudzībai starp divām testa aģenta saskarnēm, bet otrais ir HTTP, izmantojot vienu testa aģenta saskarni.
Lai uzzinātu veidnes ievades parametrus, noklikšķiniet uz lodziņa, kas apzīmē veidni. HTTP veidnei parametri var izskatīties šādi:

Šie parametri mums ir jādefinē nākamajā darbībā, startējot monitoru.
Monitora palaišana
Izmantojot pārbaudes aģentus, ko definējām un izvietojām sadaļā “Jauna testa aģenta izveide un izvietošana” 17. lpp., mēs varam palaist monitoru no veidnes “HTTP”, kā parādīts tālāk.
Katram parametram ir jānorāda atribūts. Atslēga ir identiska parametra mainīgā nosaukumam vadības centrā. Varat pārbaudīt mainīgo nosaukumus šādi:

Sānu joslā noklikšķiniet uz Monitoring un atlasiet New Monitor.

Noklikšķiniet uz Manas veidnes.
Noklikšķiniet uz saites Rediģēt zem interesējošās veidnes.
Augšējā labajā stūrī noklikšķiniet uz pogas Rediģēt ievadi.

Mūsu bijušajāample, un pēc noklusējuma mainīgo nosaukumi ir vienkārši vadības centrā redzamo parādāmo nosaukumu mazo burtu versijas (“url"pret"URL” utt.). Tomēr vadības centra GUI varat pārdēvēt mainīgos uz to, ko vēlaties.
Papildus atslēgai katram parametram ir jānorāda tā veids: piemēramample, priekš URL. Lūdzu, ņemiet vērā, ka visa informācija par parametra veidu ir atrodama YANG modelī. Testa aģenta saskarnēm tipam ir sarežģītāka struktūra, par ko liecina tālāk sniegtais kods.
BijušajāampPēc tam ar monitoru nav saistīta neviena trauksme. Piemēram,ampJa ir iesaistīti trauksmes signāli, dodieties uz sadaļu “Monitora palaišana ar trauksmi” 62. lpp.

Monitora palaišana ar trauksmi
Lai saistītu trauksmi ar monitoru, varat norādīt uz definētu trauksmes veidni, vai arī varat norādīt visu trauksmes konfigurāciju, veidojot monitoru. Mēs iedosim vienu bijušoampkatrai pieejai zemāk.
Monitora trauksmes iestatīšana, norādot uz trauksmes veidni
Lai izmantotu trauksmes veidni, jums jāzina tās ID. Šim nolūkam vispirms izgūstiet visas trauksmes veidnes, kā aprakstīts sadaļā “Visu trauksmes veidņu izgūšana” 39. lpp., un atzīmējiet attiecīgās veidnes nosaukumu. Pēc tam varat atsaukties uz šo veidni šādi:

Monitora trauksmes iestatīšana, konfigurējot to tiešiy
Varat arī iestatīt trauksmi monitoram, monitora izveides laikā norādot visu tā konfigurāciju, neatsaucoties uz trauksmes veidni. Tas tiek darīts, kā parādīts nākamajā piemample.

Skriešanas monitoru izgūšana
Lai izgūtu visus pašlaik izpildāmos monitorus, palaidiet šo skriptu:
ar menedžeri. connect(host=args.host, port=args.port, lietotājvārds=args. lietotājvārds, parole=args.password, hostkey_verify=False) kā m:

Izvade ir visu darbojošos monitoru saraksts, kā parādīts zemāk:

SLA statusa izgūšana monitoram
Tālāk ir norādīts, kā izgūt monitora SLA statusu. Šajā bijušajāample, mēs izgūstam SLA statusu monitoram “Tīkla kvalitāte” trīs laika intervālos: pēdējās 15 minūtes, pēdējā stunda un pēdējās 24 stundas.

Izvade izskatīsies apmēram šādi:

NETCONF paziņojumi
NETCONF paziņojumus monitoriem aktivizē SLA pārkāpumi. Tās rodas, ja monitora SLA noteiktā laika periodā, pēc noklusējuma pēdējo 15 minūšu laikā, nokrītas zem SLA sliekšņa (“Laba” vai “Pieņemama”). Jāņem vērā, ka paziņojumi par SLA pārkāpumiem ātri parādās pēc tam, kad pakalpojumu ir skārusi problēma, savukārt SLA statuss tiks atgriezts uz “Labs” tikai pēc 15 minūtēm un tikai tad, ja turpmāki pārkāpumi nenotiks.
Laika logu var mainīt, rediģējot iestatījumu SLA_STATUS_WINDOW (vērtība sekundēs) /etc/netrounds/netrounds.conf.
Monitora veidņu eksportēšana un importēšana
Tas tiek darīts tieši tāpat kā testa veidnēm; salīdziniet sadaļu “Pārbaudes veidņu eksportēšana un importēšana” 52. lpp. Tālāk esošie koda fragmenti parāda, kā eksportēt un importēt monitoru veidnes.
Monitora veidņu eksportēšana

Monitora veidņu importēšana

Izmantojot Tags

Tags Paragon Active Assurance definēto var piemērot:

monitori
monitora veidnes
Testa aģenti
TWAMP atstarotāji
Ping saimnieki.
Piemēram,ample, tu vari tag monitoru ar tādu pašu tag kā testa aģentu apakškopu, kas darbinās monitoru. Šī funkcija ir īpaši noderīga, ja ir definēts liels monitoru un veidņu skaits.

Ja monitoram esat iestatījis trauksmi ar SNMP slazdiem, SNMP slazdiem tiks piešķirts tas pats tags kā monitoru, ja tāds ir.
Izveidojot Tags
Zemāk mēs parādīsim, kā izveidot a tag ar nosaukumu un krāsu, kā noteikts XMLtag> apakšstruktūra.

Piešķirot a Tag
Lai piešķirtu a tag resursam, jūs to pievienojat kā jaunutag> elements zemtags> šī resursa elements.
Lūk, kā piešķirt a tag testa aģentam:

Lai piešķirtu a tag uz TWAMP atstarotājs, rīkojieties šādi:

Piešķirot a tag uz monitoru tiek apstrādāts līdzīgi:

Varat arī piešķirt esošu tag uz kādu no šiem resursu veidiem, veidojot resursu, iekļaujottags> elements, kas satur tag jautājumā.
Atjaunināšana a Tag
Esoša atjaunināšana tag ar jauniem atribūtiem ir analogs a izveidei tag:

Piešķiršanas atcelšana a Tag
Lai atceltu piešķiršanu a tag no resursa, pievienojiet atribūtu nc:operation=”delete”.tag> resursam piederošs elements. Tālāk mēs atceļam a piešķiršanu tag no monitora.

Dzēšot a Tag
Lai dzēstu a tag no vadības centra atkal tiek izmantots atribūts nc:operation=”delete”, taču šoreiz tas tiek lietots tag pati, kas definēta zemāk .

Problēmu novēršana

Problēma: Orchestrator un Paragon Active Assurance nav sinhronizētas
Piemēram, orķestris un Paragon Active Assurance var nebūt sinhronizētiample, ja vadības centra GUI ir veiktas konfigurācijas izmaiņas vai ja konfigurācijas pielietošana nebija veiksmīga un atgriešana uz iepriekšējo stāvokli neizdevās.
Neveiksmīgas atcelšanas gadījumā NETCONF serveris vairs nepieņems konfigurācijas izmaiņas; tas atbildēs ar kļūdas ziņojumu, kurā norādīts, ka konfigurācija ir bloķēta, līdz atkal tiks sinhronizēta. Lai atjaunotu sinhronizāciju un atbloķētu konfigurācijas izmaiņas, jums ir jāpalaiž komanda rpc sync-from-ncc, kas sinhronizē visu konfigurāciju no vadības centra uz konfigurācijas datu bāzi.
PIEZĪME: The confd@netrounds.com lietotājam (vai jebkuram citam, kas ir konfigurēts) ir jābūt superlietotāja privilēģijām, lai viss tiktu veiksmīgi sinhronizēts. To var panākt ar komandu ncc user-update confd@netrounds.com –is-superuser Ja lietotājs nav superlietotājs, tiks parādīts brīdinājums, ka ne visu var sinhronizēt, bet viss, ko var apstrādāt, ir bijis.
PIEZĪME: Ja jūsu orķestrētājs saglabā arī konfigurāciju, jums tā arī būs atkārtoti jāsinhronizē, jo pieprasītā konfigurācija (konfigurācija, kuru orķestrētājs sagaida vadības centram) netiks lietota.
Problēma: sākotnējā sinhronizācija (sinhronizācija no ncc) neizdevās neatbalstītu resursu dēļ
Ja mēģināt palaist rpc sync-from-ncc kontā, kura konfigurācija ir izveidota vadības centra GUI, var rasties problēmas, ja kontā ir neatbalstīti resursi. Ieteicams sākt ar tukšu kontu un veikt visu tā konfigurēšanu, izmantojot NETCONF. Pretējā gadījumā, ja rodas problēmas ar resursu konfliktiem, jums būs jānoņem konfliktējošie resursi no konta.
Problēma: NETCONF komandas neizdodas ar ncclient.operations.rpc.RPCError: lietojumprogrammas komunikācijas kļūme
Ja vadības centrs tiek restartēts, NETCONF serveris automātiski neatjauno savienojumu ar vadības centra serveri. Lai atjaunotu savienojumu ar vadības centru, restartējiet NETCONF procesu: sudo systemctl restart netrounds-confd

Piezīmes par testa aģentu lietojumprogrammām un testa aģentu ierīcēm

Testa aģentu lietojumprogrammas ConfD
Starp testa aģentiem (jaunākā) testa aģenta lietojumprogramma darbojas nedaudz savādāk nekā (vecākā) testa aģenta ierīce.
Testa aģenta lietojumprogrammas pašlaik neatbalsta interfeisa konfigurāciju. Tāpēc YANG shēma ļauj norādīt tukšu interfeisa konfigurāciju šādiem testa aģentiem. Skatiet “šo fragmentu” 23. lppample.
Sinhronizējot ConfD datu bāzi ar vadības centru, izmantojot komandu sync-from-ncc, vēlaties, lai interfeisa konfigurācija paliktu tukša un netiktu pārrakstīta ar to, kas atrodas vadības centrā. Tāpēc, strādājot ar testa aģenta lietojumprogrammām, ar šo komandu ir jāizmanto īpašs karodziņš -without_interface_config.
Tukša testa aģenta ierīces saskarnes konfigurācija
Kā minēts iepriekš, testa aģenta lietojumprogramma neatbalsta saskarnes konfigurāciju, un tāpēc YANG shēmā ir iespējams izlaist saskarnes.
Taču ir arī lietošanas gadījumi, kad testa aģenta ierīcē var vēlēties izlaist saskarnes konfigurāciju. BijušaisampTas varētu būt orķestrēšanas scenārijs, kurā jūs izveidojat testa aģentu, izmantojot mākoņa iniciatoru, un vēlaties, lai tiktu izmantota interfeisa konfigurācija no tā, nevis ļautu ConfD to pārrakstīt, kad testa aģents ir tiešsaistē.
YANG shēmas izmaiņas attiecībā uz nenoteiktām saskarnēm
Tā kā tagad ir atļauta tukša saskarnes konfigurācija (sākot no versijas 2.34.0), ir iespējams norādīt jebkuru saskarnes nosaukumu kā ievadi uzdevumam, kas darbojas kā testa vai monitora daļa.
Tas ir nepieciešams, lai varētu izmantot testa aģenta lietojumprogrammu, jo šīm programmām ConfD nav definēti saskarnes nosaukumi. Tomēr ņemiet vērā, ka tas arī nozīmē, ka var rasties problēmas, ja nejauši konfigurējat testu vai monitoru, lai izmantotu neesošu saskarni. Tāpēc, lūdzu, ņemiet to vērā.
Ierobežojumi, reģistrējot pārbaudes aģentu, kas izveidots ConfD
Veidojot testa aģentu, izmantojot REST vai NETCONF/YANG API, mēs nevaram iepriekš zināt, kurš tā tips ir: Test Agent Appliance vai Test Agent Application. Tas kļūst skaidrs tikai pēc testa aģenta reģistrēšanās.
Kad testa aģents ir reģistrēts un ir kļuvis par kādu no šiem konkrētajiem veidiem, jums nav atļauts to atkārtoti reģistrēt kā cita veida testa aģentu. Tas nozīmē, ka jums nav atļauts to vispirms reģistrēt kā testa aģenta ierīci, pēc tam atkārtoti reģistrēt kā testa aģenta lietojumprogrammu vai otrādi. Ja jums ir nepieciešams cita veida testa aģents, jums būs jāizveido jauns testa aģents.

Pielikums: Pilna YANG modeļa koka struktūra

Šajā pielikumā sadaļā “Leģenda” 81. lpp. ir izskaidrota YANG modeļa koka struktūras sintakse, kas ģenerēta ar komandu pyang -f tree.
Sadaļā “YANG modeļa koka struktūra” 82. lpp. sniegta šīs komandas izvade, kas lietota netrounds-ncc.yang. Daļa no šīs produkcijas ir reproducēta citur dokumentā.
Leģenda

YANG modeļa koka struktūra

Juniper Networks, Juniper Networks logotips, Juniper un Junos ir Juniper Networks, Inc. reģistrētas preču zīmes Amerikas Savienotajās Valstīs un citās valstīs. Visas pārējās preču zīmes, pakalpojumu zīmes, reģistrētās preču zīmes vai reģistrētās pakalpojumu zīmes ir to attiecīgo īpašnieku īpašums. Juniper Networks neuzņemas atbildību par neprecizitātēm šajā dokumentā. Juniper Networks patur tiesības bez brīdinājuma mainīt, modificēt, nodot vai citādi pārskatīt šo publikāciju. Autortiesības © 2023 Juniper Networks, Inc. Visas tiesības aizsargātas.

Dokumenti / Resursi

Juniper NETWORKS NETCONF & YANG API programmatūra [pdfLietotāja rokasgrāmata
NETCONF YANG API programmatūra, YANG API programmatūra, API programmatūra, programmatūra

Atsauces

Lietotāja rokasgrāmata

Ievads