Juniper NETWORKS NETCONF & YANG API Programaro Uzantgvidilo

Celo de Ĉi tiu Dokumento
Ĉi tiu dokumentaro priskribas kiel integri Paragon Active Assurance kun retserva orkestro per la Kontrolcentro NETCONF & YANG API. Praktika ekzampLes estas donitaj de la ĉefaj taskoj implikitaj, inkluzive de: kreado kaj deplojado de Virtualaj Testaj Agentoj, prizorgado de testoj kaj ekranoj, kaj reakiro de rezultoj de ĉi tiuj agadoj.
En ĉi tiu dokumento, la libere havebla Python NETCONF-kliento ncclient estas uzata en la rolo de orkestro.

Konvencioj
La sekvaj mallongigoj estas uzataj en ĉi tiu dokumento:

Mallongigo	Signifo
CLI	Komandlinia Interfaco
EM	Elementa Administranto
ES	Eraris Dua
MEP	MEG (Prizorga Entogrupo) Finpunkto (ITU-T Y.1731-difino) aŭ Maintenance End Point (Cisco-difino)
NFV	Reta Funkcio Virtualigo
NFVO	Network Function Virtualization Orchestrator
NSD	Reta Servo-Priskribilo
RPC	Fora Procedura Voko
SIP	Protokolo pri Sesia Iniciato
SLA	Interkonsento pri Serva Nivelo
S-VNFM	Speciala VNF-Manaĝero
VNF	Virtuala Reta Funkcio
vTA	Virtuala Testa Agento

Notoj pri Malantaŭa Kongrueco

En versioj 2.35.4/2.36.0 de la NETCONF & YANG API, la validumado de certaj petoj fariĝis pli strikta por aliĝi al la NETCONF-normo. Ĉi tio signifas, ke klientokodo bazita sur pli malnovaj versioj de ĉi tiu gvidilo nun eble estos malakceptita.
Por ekzample, en antaŭa Python ekzample-kodo, neniu nomspaca atributo estis disponigita. La nomspaco nun devas esti provizita en la peto XML kiam ajn vi volas modifi ConfD-rimedon.

Antaŭkondiĉoj kaj Preparoj

Instalado de ConfD
ConfD (produkto de Tail-f) estas uzata kiel peranto inter la Paragon Active Assurance-sistemo kaj NETCONF. ConfD ligas agordon de Paragon Active Assurance kaj operaciajn datumojn al la NETCONF & YANG API.
ConfD devus esti instalita kune kun la programaro de Kontrolcentro, kiel priskribite en la Instala Gvidilo.

Kontrolante Ke ConfD Funkcias
Por kontroli, ke la ConfD funkcias, rulu la komandon
ssh -s @localhost -p 830 netconf
por kontroli ke ConfD respondas sur la haveno 830. En la komando, estas kiel difinita de la netconf-uzanto krei
komando en la Instala Gvidilo, sekcio Instalado de ConfD. Donu la pasvorton difinitan per la sama komando.
En la eligo, kontrolu, ke la modulo de Kontrolcentro estas inkluzivita. La eligo devus enhavi linion kiel la jena:
http://ncc.netrounds.com?module=netrounds-ncc&revision=2017-06-15

Sinkronigante la Agordan datumbazon kun Kontrolcentro

Fine, ni devas ĝisdatigi la agordan datumbazon per NETCONF. Ni faros tion ĉi tie per Python-biblioteko nomata ncclient (NETCONF Kliento). Tamen, la tasko ankaŭ povus esti plenumita en malsama programlingvo kondiĉe ke ĝi uzas la NETCONF/YANG-protokolon.
La rolo de ncclient estas agi kiel kliento al la ConfD-servilo kiu gastigas la NETCONF/YANG API.

Indas atentigi, ke ncclient neniel rilatas al Kontrolcentro (antaŭe "Netrounds Control Center"), kvankam la nomo okazas komenciĝi per "ncc".
Jen kiel instali ncclient:

Elŝutu la programaron de https://github.com/ncclient/ncclient.
Rulu ĉi tiun komandon: pip install ncclient

Ni nun povas plenumi la sinkronigon jene. Rimarku zorge, ke tio devas esti farita sur aparta komputilo, kaj ne sur la servilo de la Kontrolcentro mem:

#
# NOTO:
# Ĉi tiu skripto funkcias kiel kliento al ConfD funkcianta sur la NCC-servilo.
# Ĝi uzos la NETCONF/YANG API por komunikado.

NOTO: Ĉi tiu proceduro ankaŭ estas postulata kiam ajn Testagentoj estis instalitaj kaj registritaj sendepende de NETCONF. Vidu la noton en la sekcio "Finview de Test Agent Orchestration” sur paĝo 17 por pliaj informoj.

Agordo de Multoblaj NETCONF-kontrolitaj Paragon Active Assurance Accounts

La ĉi-subaj paŝoj estas postulataj nur se vi volas agordi pliajn kontojn de Paragon Active Assurance por esti kontrolitaj de NETCONF, krom la konto agordita tiamaniere en la Instala Gvidilo, sekcio "Instalado de ConfD".
Por ĉiu tia konto, procedu jene:

En Kontrolcentro, ensalutu al la konto kaj navigu al Konto > Permesoj.

Aldonu la uzanton "confd@netrounds.com", kaj donu al ĉi tiu ConfD-uzanto-administran permeson en la GUI alklakante la butonon Inviti.
Sinkronigu la agordan datumbazon kun Kontrolcentro kiel priskribite en la sekcio "Sinkronigi la agordan datumbazon kun Kontrolcentro" sur paĝo 4.
Vi nun devus povi kontroli plurajn kontojn de Paragon Active Assurance kun la sama uzanto de ConfD.

NOTO: Post kiam vi komencas kontroli konton de Paragon Active Assurance per ConfD, vi NE devas fari ŝanĝojn al ĉi tiu konto per la web GUI rilate al iuj funkcioj de Paragon Active Assurance kiuj estas "agordaj" (vidu la ĉapitron "Subtenitaj Trajtoj en Paragon Active Assurance" sur paĝo 9). Se vi faros, perdo de sinkronigo rezultos.

Enkonduko al NETCONF Orchestration API

Finiteview

Triaparta NFVO aŭ serva orkestranto estas tipe la komponento kiu iniciatas testajn kaj monitorajn sesiojn uzante la Control Center API. Ĉi tiu orkestranto ankaŭ prenas la agregitajn mezurrezultojn de la Test Agent-agadoj. Efikec-KPI-oj povas esti prenitaj de triapartaj Performance Management Systems, dum eventoj - iam ekigitaj de sojlaj malobservoj fiksitaj en la Kontrolcentro - povas esti senditaj al triaj Fault Management-sistemoj.
Por resumi, la suba figuro montras kiel Paragon Active Assurance interagas kun aliaj triaj sistemoj en la OSS-pejzaĝo.

NFVO/Service Orchestrator: Instruas la VNF-Manaĝeron deploji la vTAojn kaj agordi Paragon Active Assurance en la servoĉenon. Post kiam la servo estas aktivigita, la orkestranto uzas la API al Kontrola Centro por ekigi servo-aktivigajn testojn kaj retrovi rezultojn de enirpermesilo/malsukceso. Se la testoj estas trapasitaj, la orkestranto uzos la API al Kontrola Centro por komenci aktivan monitoradon de la servo. KPIoj de la monitorado estas prenitaj ade aŭ fare de la orkestranto aŭ de aparta Performance Management-platformo.
Kontrolcentro: Deplojiĝas, skalas kaj finas la vTA laŭ instrukciaĵo de la NFVO aŭ serva orkestro.

Sistemo pri Efikeco-Administrado aŭ Serva Kvalita Administrado: Legas KPIojn de aktiva monitorado per la API de Kontrolcentro.
Sistemo pri Faŭlto-Administrado: Ricevas NETCONF, SNMP aŭ retpoŝtajn sciigojn de Kontrolcentro se SLA-oj estas malobservitaj.

Difinoj de Konceptoj en Paragon Active Assurance

Testagentoj: La komponentoj kiuj elfaras mezuradojn (por testoj same kiel monitoroj) en Paragon Active Assurance-sistemo. Testagentoj konsistas el programaro kun la kapablo generi, ricevi kaj analizi realan retan trafikon.
La speco de Testa Agento diskutita en ĉi tiu dokumento estas la Virtuala Testa Agento (vTA), virtuala reto-funkcio (VNF) deplojita sur hiperviziero. Aliaj specoj de Testagento ankaŭ ekzistas.

Estas du bazaj specoj de mezurado en Paragon Active Assurance, testoj kaj monitoroj.
Testo: Testo konsistas el unu aŭ pluraj paŝoj, ĉiu el kiuj havas specifitan, finhavan daŭron. Paŝoj estas ekzekutitaj sinsekve. Ĉiu paŝo povas implici funkcii plurajn taskojn samtempe.

Monitoro: Monitoro ne havas difinitan daŭron sed efektivigas senfine. Kiel paŝo en testo, monitoro povas plenumi plurajn samtempajn taskojn.
Ŝablono: Kiam Paragon Active Assurance estas kontrolita de orkestranto, testoj kaj monitoroj ĉiam estas efektivigitaj per ŝablonoj en kiuj la testo aŭ monitoro estas difinitaj. Parametraj agordoj povas esti transdonitaj kiel enigaĵoj al la ŝablono ĉe rultempo.

Laborfluo por Aŭtomatigo
Dezajna Tempo

En la tempo de projektado, vi preparas mezuradojn kreante ŝablonojn por testoj kaj monitoroj en Paragon Active Assurance. Kiel fari tion estas priskribita en la ĉapitro "Testaj kaj Monitoraj Ŝablonoj" sur paĝo 15.

Runtime
Ĉe rultempo, vi agordas viajn aparatojn kaj plenumas la realajn mezuradojn.

An superview de ĉiuj eksamples donitaj troviĝas en la ĉapitro “Ekzamples de Controlling Paragon Active Assurance per NETCONF & YANG API” sur paĝo 15.
Kiel disfaldi kaj agordi Testajn Agentojn estas trarigardita en la ĉapitro "Ekzamples: Testaj Agentoj” sur paĝo 16.

Kiel importi inventaraĵojn kiel TWAMP reflektoroj kaj IPTV-kanaloj estas trarigarditaj en la ĉapitro "Ekzamples: Stokregistraj Eroj” sur paĝo 29.
Kiel agordi alarmojn estas klarigita en la ĉapitro "Ekzamples: Alarmoj” sur paĝo 35.

Kiel ruli testojn kaj monitorojn per ekzekuto de ŝablonoj Paragon Active Assurance per NETCONF estas priskribita en la ĉapitroj "Eksamples: Testoj” sur paĝo 43 kaj “Ekzamples: Monitoroj” sur paĝo 54.

Subtenataj Trajtoj en Paragon Active Assurance

Ĉiuj testaj kaj monitoraj specoj en Paragon Active Assurance povas esti kreitaj kaj efektivigitaj per la uzo de ŝablonoj. Kiel fari tion ĉi estas priskribita en la en-apa helpo sub "Testoj kaj monitoroj" > "Kreante ŝablonojn".

Kreado de Paragon Active Assurance-kontoj nuntempe ne estas subtenata; tamen, unu aŭ pluraj antaŭdifinitaj kontoj estos starigitaj por la uzanto.
La subaj tabeloj detaligas kiajn funkciojn en Paragon Active Assurance estas disponeblaj en ĉi tiu eldono, kaj kiel ĉi tiuj funkcioj estas reprezentitaj en YANG.

Klarigo de YANG-Konstruoj

Por oportuno, difinoj estas donitaj ĉi tie de la YANG-konstruaĵoj referitaj en la trajtotabelo.

Agordo (config=vera): Agordaj datumoj, necesaj por transformi sistemon de unu ŝtato al alia.
State (config=false): Ŝtatdatenoj: kromaj datumoj pri sistemo, kiu ne estas agordaj datumoj, kiel nurlegeblaj statusinformoj kaj kolektitaj statistikoj.
RPC: Remote Procedure Call, kiel uzite ene de la NETCONF-protokolo.
Sciigo: Eventaj sciigoj senditaj de NETCONF-servilo al NETCONF-kliento.

Tabeloj de Paragon Active Assurance Trajtoj Disponeblaj por Orkestrado
Rimedo: Monitorado
YANG-vojo:/accounts/account/monitors

Karakterizaĵo	Subtrajto	YANG-konstruo
Krei/modifi/forigi monitoron	Bazita sur monitora ŝablono	Agordo
Komencu/haltigi monitoron	–	Agordo
Monitoraj ŝablonoj	Listigu ekzistantajn monitorajn ŝablonojn kun enigaĵoj	Ŝtato
NETCONF sciigoj	Alarmstato ŝanĝiĝis	Sciigo
Kontrolu rezultojn	SLA/ES-nombrilo por pinta nivelo (%) SLA/ES-nombrilo por tasknivelo (%)	Ŝtato

Male al testoj (komparu Rimedon: Testoj malsupre), monitoroj ne estas komencitaj per RPC sed prefere per farado de la monitora agordo.
Rimedo: Testoj
YANG-vojo: /accounts/account/tests

Karakterizaĵo	Subtrajto	YANG-konstruo
Komencu teston	Surbaze de testa ŝablono	RPC
Administri testojn	Listigu testojn kun statuso	Ŝtato
Testaj ŝablonoj	Listigu ekzistantajn testŝablonojn kun enigaĵoj	Ŝtato
NETCONF sciigoj	Teststatuso ŝanĝiĝis	Sciigo
Testrezultoj	Akiru testpaŝan staton (pasi, malsukcesi, eraro, ...)	Ŝtato

Rimedo: Testaj Agentoj
YANG-vojoj:

/accounts/account/test-agents (Agordo)
/accounts/account/registered-test-agents (Ŝtato)

Testaj Agentoj sub /accounts/account/test-agents estas tiuj, kiuj estas agordaj en konto. Nur ĉi tiuj Testaj Agentoj povas esti agorditaj kaj uzataj en testoj kaj monitoroj per NETCONF de la orkestro.
Post kiam vi agordis Testan Agenton kaj ĝi registriĝis al la konto, la Testa Agento aperos sub /accounts/account/registered-test-agents. Vi povas trovi ĉiujn registritajn Testagentojn uzante komandon "akiri" en NETCONF (komparu la ĉapitron Examples: Testagentoj).
Sub /accounts/account/registered-test-agents vi ankaŭ povas trovi Testagentojn kiuj ankoraŭ ne estis agorditaj. Ĉiuj tiaj Testaj Agentoj devas esti agordita antaŭ ol ili povas esti uzataj.
En orkestra scenaro, ĝenerale rekomendas, ke vi faru ĉiujn agordojn de via Paragon Active Assurance-konto per NETCONF. Ĉi tio certigas, ke test-agentoj kaj registritaj-test-agentoj ne diverĝas.

Karakterizaĵo	Subtrajto	YANG-konstruo
Antaŭkreu Testan Agenton sur servilo	–	Agordo
Agordi eksterrete Testagenton	(Kontrolcentro puŝas agordon al Testa Agento kiam ĝi enretas)	Agordo
Uzu ekzistantajn/ekstere agorditajn Testagentojn	Uzu en testo/monitoro	Agordo
	Agordi interfacojn	Agordo
	Akiru statuson	Ŝtato
Agordi Testan Agenton (nur Testa Aparato)	Agordu NTP	Agordo
	Agordi pontojn	Agordo
	Agordi VLAN-interfacojn	Agordo
	Agordi SSH-klavojn	Agordo
	IPv6	Agordo
Utiloj	Rekomencu	RPC
	Ĝisdatigo	RPC
NETCONF sciigoj	Enreta statuso ŝanĝiĝis	Sciigo
Statuso	Akiru sisteman staton (funkcitempo, uzado de memoro, ŝarĝo mezumo, versio)	Ŝtato

Rimedo: Inventaro
YANG-vojo: /accounts/account/twamp- reflektiloj

Subtenataj NETCONF Kapabloj

La tabelo malsupre montras al la IETF RFCoj priskribante la NETCONF-kapablojn uzitajn por la celo de Paragon Active Assurance-instrumentado.

ietf-netconf.yang
IETF RFC 6241, Network Configuration Protocol (NETCONF), https://tools.ietf.org/html/rfc6241
La nura subtenata erara traktadmetodo estas rollback-on-eraro.
La nura subtenata datumvendejo estas skribebla funkcianta.
ietf-netconf-notifications.yang
IETF RFC 5277, NETCONF Eventaj Sciigoj, https://tools.ietf.org/html/rfc5277

Testo kaj Monitoro Ŝablonoj
Ŝablonoj por testaj kaj monitoraj tipoj devas esti agorditaj permane per la antaŭa uzantinterfaco de Paragon Active Assurance. Kiel fari tion ĉi estas priskribita en la en-apa helpo sub "Testoj kaj monitoroj" > "Kreante ŝablonojn".

Examples de Controlling Paragon Active Assurance per NETCONF & YANG API

En la sekvaj ĉapitroj oni supozas, ke taŭgaj testaj kaj monitoraj ŝablonoj estis difinitaj laŭ la instrukcioj donitaj en la ĉapitro "Testaj kaj Monitoraj Ŝablonoj" sur paĝo 15.

Iloj Uzitaj en Ekzamples
Ĉiuj eksamples en la postaj ĉapitroj estis konstruitaj uzante la sekvajn libere haveblajn ilojn:

Pang: Uzita por bildigi kaj foliumi la YANG-modelojn.
Havebla ĉe https://github.com/mbj4668/pyang (klonu el git kaj rulu python setup.py install).
Python NETCONF-kliento "ncclient": Uzita por komuniki kun Kontrolcentro per NETCONF.

Havebla ĉe https://github.com/ncclient/ncclient (kuru pip install ncclient).
La datummodelo netrounds-ncc.yang troviĝas en /opt/netrounds-confd post kiam ConfD estis instalita laŭ la Instala Gvidilo).

Finiteview de Ŝlosilaj Taskoj Faritaj

(Kelkaj pliaj taskoj ankaŭ estas ekzempligitaj en kio sekvas.)

"Kreante kaj deplojante novan Testan Agenton" sur paĝo 16
"Kreante inventaraĵojn (ekz. reflektorojn)" sur paĝo 29
"Agordo de alarmŝablonoj kaj kie sendi alarmojn" sur paĝo 35

"Kreante kaj funkciigante teston" sur paĝo 45
"Reakiro de testrezultoj" sur paĝo 50
"Starti monitoron (inkludas agordon de alarmoj)" sur paĝo 60
"Reakiro de SLA-statuso por monitoro" sur paĝo 67
“Laborante kun tags”Sur paĝo 71

Examples: Testaj Agentoj

Finiteview de Test Agent Orchestration
Testagentoj en Paragon Active Assurance estas konsiderataj kiel "agordo" en la kunteksto de instrumentado. Ĉi tio signifas, ke kreado, kontrolo kaj forigo de Testagentoj devas esti faritaj per la orkestro kaj NETCONF prefere ol per la Paragon Active Assurance GUI.
GRAVA: Se Testa Agento estas instalita de teknikisto kaj registrita al Kontrola Centro sen unue esti kreita per la NETCONF & YANG API, la Testa Agento ne ekzistos en la agorda datumbazo, kaj la sistemo malsinkroniĝos. Por ke ConfD konsciiĝu pri la Testa Agento en ĉi tiu kazo, estos necese fari novan sinkronigon kun Kontrolcentro, kiel detale en la sekcio "Sinkronigi la Agordan Datumaron kun Kontrolcentro" sur paĝo 4.

Orkestrado de Virtualaj Testaj Agentoj (vTAs) devus do esti farita en la sekvaj paŝoj:

Kreu la Virtualan Testan Agenton, inkluzive de ĝia interfacagordo, uzante la NETCONF & YANG-interfacon al Kontrolcentro. La nomo de la Testa Agento estos ĝia unika ŝlosilo.
Deploji la vTA sur virtualiga platformo. Sekvu la instrukciojn en la interreta helpo sub Test Agentoj > Instalado. La baza interfacagordo kiu permesas al la vTA konektiĝi al Kontrolcentro, same kiel akreditaĵoj por aŭtentikigo, estas disponigita en la vTA uzante nub-init uzantdatenojn.
Post kiam la vTA ekfunkciigis, ĝi aŭtomate konektos al Kontrolcentro uzante ĉifritan OpenVPN-konekton. NETCONF-sciigo estas sendita ĉar la valoro de la parametro test-agent-statuschange de la vTA nun ŝanĝiĝis al "rete".
NOTO: Ĉar la nomo de la vTA estas ĝia identigilo en Kontrolcentro, ĉi tiu nomo devas esti la sama kiel tiu difinita en Kontrolcentro en "paŝo 1" sur paĝo 17.
Post kiam la vTA konektiĝis kaj aŭtentikigis al Kontrolcentro, la interfacagordo estas puŝita al la vTA. Ĉi tiu estas la interfaca agordo provizita en "paŝo 1" sur paĝo 17 kiam la vTA estis kreita en Kontrolcentro.

Post kiam la vTA plenumis sian celon, forigu la vTA.

Krei kaj Deploji Novan Testan Agenton

Ni unue devas krei Testan Agenton uzante la NETCONF & YANG-interfacon al Kontrola Centro. Kiam Testa Agento estas kreita tiamaniere, ne necesas sinkronigo kun Kontrolcentro.
La YANG-modelo por Testa Agento estas kiel prezentita malsupre. Ĝi estas akirita kiel eligo de la komando
pyang -f arbo netrounds-ncc.yang
La plena YANG-modelo estas donita en "Apendico: Arba Strukturo de Plena YANG-Modelo" sur paĝo 81, kiu ankaŭ enhavas legendon klarigantan la konvenciojn uzatajn en ĉi tiu kaj aliaj YANG-modelilustraĵoj en la nuna dokumento.

Ni daŭrigas la sekvajn paŝojn, kiuj estas detalaj jene:

Komence, la konto "demo" de Paragon Active Assurance ne havas Testagentojn en sia inventaro.
Testa Agento nomata "vta1" estas kreita per ncclient. Ĉe ĉi tiu stage, neniu vera Testa Agento ankoraŭ ekzistas (tio estas, ĝi ankoraŭ ne estis komencita).
La Testa Agento estas deplojita en OpenStack. (Deplojo sur tiu platformo estas elektita ĉi tie kiel unu ebleco inter aliaj.)

La Testa Agento konektas al la "demo"-konto de Kontrolcentro kaj nun estas preta por uzo.
Paŝo 1: Komence, ne estas Testaj Agentoj en la konto "demo". Vidu la ekrankopion malsupre de la Kontrolcentro GUI.Paŝo 2: Testa Agento estas kreita en Kontrolcentro uzante la Python NETCONF-klienton "ncclient". Malsupre estas ncklienta kodo por krei Testan Agenton havantan unu fizikan interfacon kun DHCP-adreso:

import argparse
de ncclient importmanaĝero
parser = argparse.ArgumentParser (description='Provo kreante Testagenton')
parser.add_argument('–host', help='La gastiga nomo kie ConfD troviĝas', bezonata=Vera)
parser.add_argument('–port', help='La pordo por konekti al ConfD', bezonata=Vera)
parser.add_argument('–username', help='La uzantnomo por konekti al ConfD', bezonata=Vera)
parser.add_argument('–pasvorto', help='Pasvorto al la konto ConfD', bezonata=Vera)
parser.add_argument('–netrounds-account', help='La mallonga nomo de la konto de NCC', bezonata=Vera)
parser.add_argument('–test-agent-name', help='Nomo de Testa Agento', bezonata=Vera)
args = parser.parse_args ()
kun manager.connect(gastiganto=args.host, port=args.port, uzantnomo=args.username,
password=args.password, hostkey_verify=Malvera) kiel m:
# Kreu Testan Agenton en Kontrola Centro
xml = """

)print m.edit_config(cel='kuranta', agordo=xml)

NOTO: La kodo antaŭanta kun manager.connect(…) estas preterlasita de posta ekzample kodo fragmentoj.
NTP-servilo estas agordita sur eth0, kaj eth0 ankaŭ estas la administrada interfaco (tio estas la interfaco, kiu konektas al Kontrolcentro).
Apliko de Testa Agento nuntempe ne permesas agordi interfacojn. Tial, ekde la versio 2.34.0, eblas preterlasi la interfacan agordon en la YANG-skemo. La ekvivalenta XML estas do radikale simpligita ĉi-kaze:Post kiam la Testa Agento estas kreita, ĝi ekzistas en la agorda datumbazo kaj en Kontrolcentro. Vidu la ekrankopion sube de la inventaro de Testa Agento, montrante la Testan Agenton "vta1":

Paŝo 3: Nun estas tempo por disfaldi la Testan Agenton "vta1" en OpenStack.
La Testa Agento uzos uzantajn datumojn de nubo-init por preni la informojn pri kiel konekti al Kontrolcentro. Specife, la uzanta datumo teksto file havas la sekvan enhavon (Notu, ke la linioj #cloud-config kaj netrounds_test_agent devas esti ĉeestantaj, kaj ke la ceteraj linioj devas esti indentitaj):

Por pliaj informoj, bonvolu raporti al la dokumento Kiel Deploji Virtualajn Testajn Agentojn en OpenStack.
Post kiam la Testa Agento estas deplojita kaj konektita al Kontrola Centro, la agordo estos puŝita de Kontrola Centro al la Testa Agento.

Paŝo 4: La Testa Agento nun estas enreta en Kontrola Centro kaj akiris sian agordon. La Testa Agento estas preta por uzo en testoj kaj monitorado. Vidu ĉi tiujn sekciojn:

"Komencante Teston" sur paĝo 45
"Starti Monitoron" sur paĝo 60

Listigi la Testajn Agentojn en Via Paragon Active Assurance Account
Malsupre estas ekzample ncclient Python-kodo por listigi la Testagentojn en konto de Paragon Active Assurance:

Ruli ĉi tiun kodon donas produktaĵon kiel ĉi sube:

Forigo de Testa Agento
Post kiam testo finiĝis, povus esti grava en iuj uzkazoj forigi la Testan Agenton.
Malsupre estas koda fragmento montranta kiel fari tion kun ncclient:

NETCONF Sciigoj
Malsupre, ni prezentas simplan ekzample skripto por aŭskulti ĉiujn envenantajn sciigojn de NETCONF de Kontrolcentro. Ĉi tiuj sciigoj estas senditaj kiam ajn certaj eventoj okazas, kiel Testa Agento malkonektanta aŭ uzanto-iniciata testo finiĝanta. Surbaze de la informoj kunportataj en la sciigoj, uzantoj povas asigni aŭtomatigitajn sekvajn agojn en la orkestro.

Kiam la supra skripto estas ekzekutita, NC-kliento prezentos la ricevitan sciigon en strukturita XML. Vidu la eksample eligo malsupre, kiu montras Testan Agenton neatendite eksterrete.

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

Examples: Inventaraj Eroj

Krei (importi) kaj administri inventaraĵojn kiel TWAMP reflektoroj kaj Y.1731 MEPs estas farita en simila maniero kiel por Test Agentoj. Malsupre estas XML kaj NETCONF-kodo por difini tiajn entojn en Paragon Active Assurance per la NETCONF & YANG API kaj por preni listojn de la difinitaj eroj.

Kreante TWAMP Reflektilo

Kreante Y.1731 MEP

Kreante IPTV-Kanalon

Kreante Ping Gastiganton

Kreante SIP-konton

Reakiro de Inventaraj Eroj
Malsupre estas Python-kodo por retrovi ĉiujn inventaraĵojn difinitajn en konto. (Ĉiuj specoj de stokregistraĵoj estas prenitaj unufoje ĉi tie por eviti iun ripeton en la dokumento. Kompreneble, ajna subaro de stokregistraĵoj povas esti prenita preterlasante kelkajn el la linioj sub konto malsupre.)

Ruli ĉi tiun kodon donas produktaĵon kiel ĉi sube:

Examples: Alarmoj

Alarmŝablonoj kaj rilataj eroj (SNMP-manaĝeroj, alarmaj retpoŝtlistoj) estas kreitaj kaj administritaj en simila maniero kiel stokregistraĵoj. Ĉi tiu ĉapitro enhavas XML kaj NETCONF-kodon por difini tiajn entojn en Paragon Active Assurance per la NETCONF & YANG API kaj por preni listojn de la difinitaj eroj.
Alarmaj Retpoŝtaj Listoj
Kreante Alarma Retpoŝta Listo

Reakiro de Ĉiuj Alarmaj Retpoŝtaj Listoj

SNMP-Manaĝeroj
Kreante SNMP-Administranton

Reakiro de Ĉiuj SNMP-Manaĝeroj

Alarmaj Ŝablonoj
Kreante AlarmŜablonon

Reakiro de Ĉiuj Alarmaj Ŝablonoj

Examples: SSH-Ŝlosiloj

Vi povas aldoni SSH-publikajn ŝlosilojn al Testa Agento per la NETCONF & YANG API. Uzante la respondan privatan ŝlosilon vi povas tiam ensaluti al la Testa Agento per SSH.
La plena listo de disponeblaj operacioj sur SSH-ŝlosiloj estas jena:

Aldonu SSH-ŝlosilon
Modifi SSH-ŝlosilon
Inspektu SSH-ŝlosilon
Listo de SSH-ŝlosiloj
Forigu SSH-ŝlosilon.
Malsupre, la aldono kaj forigo operacioj estas ekzempligita.

Aldonante SSH-Ŝlosilon

Jen kiel krei novan SSH-ŝlosilon.

Juniper NETWORKS NETCONF & YANG API Programaro - Ŝlosilo

Forigante SSH-Ŝlosilon
Se vi volas forigi SSH-ŝlosilon, uzu la jenan komandon:

Examples: Testoj

Oni supozas ĉi tie, ke Testaj Agentoj (tiom kiom necesas por la testoj) estis kreitaj laŭ la sekcio "Kreado kaj Deplojado de Nova Testa Agento" sur paĝo 17.
YANG Modelaj Vojetoj por Testoj

Ero	YANG-modelvojo: /accounts/account/tests...
provoj	/.
testo[id]	/testo
id	/testo/id
nomo	/testo/nomo
statuso	/testo/stato
komenca tempo	/testo/komenca tempo
fintempo	/testo/fino-tempo
raporto-url	/testo/raporto-url
paŝoj	/testo/paŝoj
paŝo[id]	/testo/paŝoj/paŝo
nomo	/testo/paŝoj/paŝo/nomo
id	/test/steps/step/id
komenca tempo	/test/steps/step/start-time
fintempo	/test/steps/step/end-time
statuso	/test/steps/step/status
status-mesaĝo	/test/steps/step/status-message
ŝablonoj	/ŝablonoj
ŝablono[nomo]	/ŝablonoj/ŝablono
nomo	/ŝablonoj/ŝablono/nomo
priskribo	/ŝablonoj/ŝablono/priskribo
parametroj	/templates/template/parameters
parametro[ŝlosilo]	/templates/template/parameters/parameter
ŝlosilo	/templates/template/parameters/parameter/key
tajpu	/templates/template/parameters/parameter/type

Antaŭkondiĉoj por Test Orchestration

Por komenci teston per NETCONF uzante NC-klienton, necesas unue konstrui testan ŝablonon uzante la GUI de Kontrolo-Centro kiel detale en la en-apa helpo sub "Testoj kaj monitoroj" > "Kreante ŝablonojn". Ĉiuj kampoj specifitaj en tiu ŝablono kiel "Ŝablona enigo" estos postulataj kiel parametroj en la XML kiam oni regas la komencon de la testa ŝablono.

Kuri testojn en Paragon Active Assurance estas konsiderata kiel "ŝtato" en la kunteksto de instrumentado. Ŝtataj datumoj estas ne-skribeblaj datumoj, kiuj ne estas konservitaj en la agorda datumbazo, kontraste al la agordaj datumoj menciitaj en la sekcio "Superview de Test Agent Orchestration” sur paĝo 17. Ĉi tio esence signifas, ke ŝanĝoj al testoj aŭ ŝablonoj en la GUI de Kontrolcentro ne kaŭzos problemojn pri sinkronigo inter Kontrolcentro kaj la agorda datumbazo.
Por ricevi raporton -URL ĝuste en testaj raportoj, vi devas certigi la Kontrolcentron URL estas ĝuste agordita. Ĉi tio estas farita en la file /opt/netrounds-confd/settings.py. Defaŭlte la gastiga nomo de la Kontrolcentro estas prenita per socket.gethostname(): vidu sube. Se ĉi tio ne donas la ĝustan rezulton, vi devas agordi la gastigan nomon (aŭ la tutan URL) permane en ĉi tio file.

# URL de Kontrolcentro sen malantaŭa oblikvo.
# Ĉi tio estas por ekzample uzata en testa raporto-url.
HOSTNAME = socket.gethostname ()
RETOUNDS_URL = 'https://%s' % HOSTNAME
Komencante Teston
Kiel priskribite en la sekcio "Kreado kaj Deplojado de Nova Testa Agento" sur paĝo 17, rulu la komandon pang -f tree netrounds-ncc.yang
el la dosierujo /opt/netrounds-confd/ por eligi la YANG-modelon. En ĉi tiu modelo, la RPC por komenci teston per NC-kliento aspektas jene:

Por klarigoj, vidu la sekcion "Legendo" sur paĝo 81 en la Apendico.

La sekvaj paŝoj estas montritaj sube:

Testaj Agentoj estis registritaj al la konto de Paragon Active Assurance, sed neniuj provoj ankoraŭ komenciĝis.
La bezonataj enigo-parametroj estas identigitaj en la testa ŝablono, kiu estos rulita.

60-sekunda HTTP-testo estas komencita uzante ncclient.

Paŝo 1: Komence, neniuj provoj estis komencitaj en la konto de Paragon Active Assurance. Vidu la ekrankopion malsupre de la Kontrolcentro GUI.
Paŝo 2: La ŝablono, kiun ni uzos por komenci la teston en ĉi tiu ekzample estas HTTP-testŝablono. Ĝi havas du devigajn enigkampojn ( Klientoj kaj URL) kiun ni specifis kiel tia dum konstruado de la ŝablono en la Kontrolcentro GUI.

Ni difinos ĉi tiujn parametrojn (inter aliaj) en la XML-agordo komunikita al la agorda datumbazo de nia NETCONF-administranto (ncclient).
Paŝo 3: La HTTP-testo estas komencita per ncclient.
Malsupre estas ekzample-kodo kie la bezonataj agordaj informoj kaj parametroj estas specifitaj por la HTTP-testŝablono. Depende de kiel la ŝablono estis konstruita, la detaloj ĉi tie povas varii.
Por ĉiu parametro, la atributo devas esti provizita. La ŝlosilo estas identa al la parametro
Variebla nomo en Kontrolcentro. Vi povas inspekti variajn nomojn jene:

Alklaku Testojn sur la flanka stango kaj elektu Novan Testan Sekvencon.

Klaku Miaj Ŝablonoj.
Alklaku la ligilon Redakti sub la interesa ŝablono.
Alklaku la butonon Redakti enigo en la supra dekstra angulo.

En nia eksample, kaj defaŭlte, la variablonomoj estas simple minusklaj versioj de la montraj nomoj viditaj en Kontrolcentro ("url" vs "URL", ktp.). Tamen, en la Kontrolcentro GUI, vi povas renomi la variablojn al kio ajn vi ŝatas.
Krom la ŝlosilo, ĉiu parametro devas havi sian tipon specifita: ekzample, por la URL.
Bonvolu noti, ke vi devas review la kompleta YANG-modelo por akiri plenajn informojn pri tipoj. Por Test Agent-interfacoj la tipo havas pli kompleksan strukturon, kiel konstatite sub en la suba kodo.

Ni nun povas ruli la skripton uzante ncclient. Supozante ke ĉio estas ĝusta, la testo estos komencita kaj ĝia ekzekuto montriĝas en Kontrola Centro:Se la testo estas sukcese komencita, Kontrolcentro respondos per la testa ID. En ĉi tiu ekzample, la testa ID estas 3:La testa ID ankaŭ troveblas en la URL por la testo en la Kontrolcentro GUI. En ĉi tiu ekzample, tio URL estas https://gastiganto/demo/testing/3/.
Reakiro de Testrezultoj
La plej simpla maniero por preni testrezultojn estas indikante la testan ID.
Malsupre estas Python-kodo por ricevi la rezultojn de la supra HTTP-testo kun ID = 3:
kun administranto. Konekti (gastiganto=args.host, haveno=args.port, uzantnomo=args.username, pasvorto=args.password, hostkey_verify=Malvera) kiel m:

La eligo aspektos kiel ĉi tio:

Eksporti kaj Importi TestŜablonojn
Testŝablonoj povas esti eksportitaj en JSON-formato kaj reimportitaj en tiu formato en Kontrolcentron. Ĉi tio estas utila se vi volas uzi testajn ŝablonojn en malsama instalado de Kontrolcentro. (La komenca kreado de la ŝablonoj estas plej bone pritraktita per la Kontrolcentro GUI.)
Malsupre estas kodo por plenumi la eksportadon kaj importon.
Eksportante Testo-Ŝablonoj

# Akiru json-agordon de respondo
radiko = ET.fromstring(response._raw)
json_config = radiko[0].teksto
presi json_config
La ŝablono estas enhavita en la objekto json_config.
Importado de Testo-Ŝablonoj
JSON-agorda objekto tenanta testajn ŝablonojn povas esti reimportita en Kontrolcentron jene.

Examples: Monitoroj

Ĉi tiu sekcio supozas, ke Testaj Agentoj (tiom kiom postulas la monitoroj) estis kreitaj laŭ la sekcio "Kreado kaj Deplojado de Nova Testa Agento" sur paĝo 17.
YANG Modelaj Vojetoj por Monitoroj

Ero	YANG-modelvojo: /accounts/account/monitors...
monitoroj	/.
monitoro[nomo]	/monitoro
nomo	/monitor/nomo
priskribo	/monitor/priskribo
komencis	/monitor/komencis
ŝablono	/monitor/ŝablono
alarm-agordoj	/monitor/alarm-configs
Ero	YANG-modelvojo: /accounts/account/monitors/monitor/alarm-configs ...
alarm-agordo[identigilo]	/alarm-config
identigilo	/alarm-config/identigilo
ŝablono	/alarm-config/template
retpoŝto	/alarm-config/retpoŝto
snmp	/alarm-config/snmp
thr-es-kritika	/alarm-config/thr-es-critical
thr-es-kritika-klara	/alarm-config/thr-es-critical-clear
thr-es-major	/alarm-config/thr-es-major
thr-es-major-clear	/alarm-config/thr-es-major-clear
thr-es-minor	/alarm-config/thr-es-minor
thr-es-minor-clear	/alarm-config/thr-es-minor-clear
thr-es-warning	/alarm-config/thr-es-warning
thr-es-warning-clear	/alarm-config/thr-es-warning-clear
sen-datumo-severeco	/alarm-config/no-data-severity
sen-datumo-tempo	/alarm-config/no-data-timeout
ago	/alarm-config/action
fenestrograndeco	/alarm-config/window-size
intervalo	/alarm-config/intervalo
sendi-nur-unufoje	/alarm-config/send-only-once
snmp-kaptilo-po-rivereto	/alarm-config/snmp-trap-per-stream
Ero	YANG-modelvojo: /accounts/account/monitors...
parametroj	/monitor/parameters
Ero	YANG-modela vojo: /accounts/account/monitors/monitor/parameters...
parametro[ŝlosilo]	/parametro
ŝlosilo	/parametro/ŝlosilo
(valor-speco)	/parametro
:(entjero)	/parametro
entjero	/parametro/entjero
:(flotu)	/parametro
flosi	/parametro/float
:(ŝnuro)	/parametro
Ero	YANG-modela vojo: /accounts/account/monitors/monitor/parameters...
ŝnuro	/parametro/ŝnuro
:(test-agent-interfacoj)	/parametro
test-agent-interfacoj	/parameter/test-agent-interfaces
test-agent-interface[“1” sur paĝo 58	/parametro/test-agent-interfacoj/
konto	/parameter/test-agent-interfaces/test-agent-interface/account
test-agento	/parameter/test-agent-interfaces/test-agent-interface/test-agent
interfaco	/parameter/test-agent-interfaces/test-agent-interface/interface
ip-versio	/parameter/test-agent-interfaces/test-agent-interface/ip-version
:(duamp- reflektiloj)	/parametro
twamp- reflektiloj	/parametro/twamp- reflektiloj
twamp-reflektilo[nomo]	/parametro/twamp-reflektiloj/twamp- reflektoro
nomo	/parametro/twamp-reflektiloj/twamp-reflektilo/nomo
:(y1731-meps)	/parametro
y1731-meps	/parametro/y1731-meps
y1731-mep[nomo]	/parameter/y1731-meps/y1731-mep
nomo	/parameter/y1731-meps/y1731-mep/name
:(sip-kontoj)	/parametro
sip-kontoj	/parametro/sip-kontoj
sip-account[“2” sur paĝo 58]	/parameter/sip-accounts/sip-account
konto	/parameter/sip-accounts/sip-account/konto
test-agento	/parameter/sip-accounts/sip-account/test-agent
interfaco	/parameter/sip-accounts/sip-account/interfaco
sip-adreso	/parametro/sip-accounts/sip-account/sip-adreso
:(iptv-kanaloj)	/parametro
iptv-kanaloj	/parametro/iptv-kanaloj
iptv-kanalo[nomo]	/parametro/iptv-channels/iptv-kanalo
nomo	/parametro/iptv-channels/iptv-channel/nomo

konto test-agenta interfaco
konto test-agento interfaco sip-adreso

Ero	YANG-modelvojo: /accounts/account/monitors...
statuso	/monitor/stato
lastaj-15-minutoj	/monitor/status/last-15-minutes
statuso	/monitor/status/last-15-minutes/status
status-valoro	/monitor/status/last-15-minutes/status-value
lasta horo	/monitor/status/last-hour
statuso	/monitor/status/last-hour/status
status-valoro	/monitor/status/last-hour/status-value
lastaj-24-horoj	/monitor/status/last-24-hours
statuso	/monitor/status/last-24-hours/status
status-valoro	/monitor/status/last-24-hours/status-value
ŝablonoj	/ŝablonoj
ŝablono[nomo]	/ŝablonoj/ŝablono
nomo	/ŝablonoj/ŝablono/nomo
priskribo	/ŝablonoj/ŝablono/priskribo
parametroj	/templates/template/parameters
parametro[ŝlosilo]	/templates/template/parameters/parameter
ŝlosilo	/templates/template/parameters/parameter/key
tajpu	/templates/template/parameters/parameter/type

Antaŭkondiĉoj por Monitor Orchestration
Antaŭ ol vi povas komenci monitoron per NETCONF uzante ncclient, vi devas konstrui monitoran ŝablonon en la Kontrola Centro GUI kiel klarigite en la en-apa helpo sub "Testoj kaj monitoroj" > "Kreante ŝablonojn". Ĉiuj kampoj specifitaj kiel "Ŝablona enigo" en tiu ŝablono estos postulataj kiel parametroj en la XML kiam oni regas la komencon de la ŝablono.
Akiro de Enigo-Parametroj de Monitoraj Ŝablonoj
Malsupre, du ŝablonoj estas montritaj. La unua estas por UDP-monitorado inter du Test Agent-interfacoj, kaj la dua estas por HTTP uzanta ununuran Test Agent-interfacon.
Por ekscii la enigajn parametrojn de ŝablono, alklaku la skatolon reprezentantan la ŝablonon. Por la HTTP-ŝablono, la parametroj povas aspekti jene:

Ni devas difini ĉi tiujn parametrojn en la sekva paŝo kiam vi komencas monitoron.
Lanĉante Monitoron
Uzante la Testajn Agentojn, kiujn ni difinis kaj disfaldis en la sekcio "Kreado kaj Deplojado de Nova Testa Agento" sur paĝo 17, ni povas komenci monitoron de la ŝablono "HTTP" kiel montrite sube.
Por ĉiu parametro, la atributo devas esti provizita. La ŝlosilo estas identa al la Variebla nomo de la parametro en Kontrolcentro. Vi povas inspekti variajn nomojn jene:

Alklaku Monitorado sur la flanka stango kaj elektu Novan Monitoron.

Klaku Miaj Ŝablonoj.
Alklaku la ligilon Redakti sub la interesa ŝablono.
Alklaku la butonon Redakti enigo en la supra dekstra angulo.

En nia eksample, kaj defaŭlte, la variablonomoj estas simple minusklaj versioj de la montraj nomoj viditaj en Kontrolcentro ("url" vs "URL", ktp.). Tamen, en la Kontrolcentro GUI, vi povas renomi la variablojn al kio ajn vi ŝatas.
Krom la ŝlosilo, ĉiu parametro devas havi sian tipon specifita: ekzample, por la URL. Bonvolu noti, ke plenaj informoj pri la parametrotipo troviĝas en la YANG-modelo. Por Test Agent-interfacoj la tipo havas pli kompleksan strukturon, kiel konstatite en la kodo malsupre.
En la eksample kiu sekvas, neniu alarmo estas asociita kun la monitoro. Por ekzamplesoj implikantaj alarmojn, iru al la sekcio "Starti Monitoron per Alarmo" sur paĝo 62.

Lanĉante Monitoron kun Alarmo
Por asocii alarmon kun monitoro, vi povas aŭ montri al alarmŝablono kiu estis difinita, aŭ vi povas provizi la tutan alarman agordon dum kreado de la monitoro. Ni donos unu eksample de ĉiu aliro malsupre.
Agordi Monitoran Alarmon montrante AlarmŜablonon
Por uzi alarmŝablonon, vi devas scii ĝian ID. Tiucele, unue prenu ĉiujn viajn alarmŝablonojn kiel priskribite en la sekcio "Reakiro de Ĉiuj Alarmaj Ŝablonoj" sur paĝo 39 kaj notu la nomon de la koncerna ŝablono. Vi povas tiam rilati al tiu ŝablono jene:

Agordi Monitoran Alarmon agordante ĝin Directly
Alternative, vi povas agordi alarmon por monitoro provizante ĝian tutan agordon dum kreado de la monitoro, sen rilati al alarmŝablono. Ĉi tio estas farita kiel montrite en la sekva ekzample.

Reakiro de Kurantaj Monitoroj
Por reakiri ĉiujn ekranojn, kiuj nun plenumas, rulu ĉi tiun skripton:
kun administranto. connect(gastiganto=args.host, port=args.port, uzantnomo=args. uzantnomo, pasvorto=args.password, hostkey_verify=False) kiel m:

La eligo estas listo de ĉiuj kurantaj monitoroj kiel montrite sube:

Reakiro de SLA-Statuso por Monitoro
Jen kiel reakiri la SLA-statuson por monitoro. En ĉi tiu ekzampLe, ni reakiras la SLA-statuson por la monitoro "Reto Kvalito" dum tri intervaloj de tempo: la lastaj 15 minutoj, la lasta horo, kaj la lastaj 24 horoj.

La eligo aspektos kiel ĉi tio:

NETCONF Sciigoj
NETCONF sciigoj por ekranoj estas ekigitaj de SLA-malobservoj. Ĉi tiuj okazas kiam la SLA por la monitoro falas sub SLA-sojlo ("Bona" aŭ "Akceptebla") ene de difinita tempofenestro, defaŭlte la lastaj 15 minutoj. Oni devas rimarki, ke SLA-malobservaj sciigoj rapide aperas post kiam servo estas trafita de problemo, dum la SLA-statuso revenos al "Bona" nur post 15 minutoj, kaj nur se neniuj pluaj malobservoj okazas.
La tempofenestro povas esti ŝanĝita redaktante la agordon SLA_STATUS_WINDOW (valoro en sekundoj) en /etc/netrounds/netrounds.conf.
Eksportante kaj Importado de Monitoraj Ŝablonoj
Ĉi tio estas farita ekzakte same kiel por testŝablonoj; komparu la sekcion "Eksporti kaj Importi TestŜablonojn" sur paĝo 52. La kodaj fragmentoj malsupre ilustras kiel eksporti kaj importi ŝablonojn por monitoroj.
Eksportante Monitoraj Ŝablonoj

Importado de Monitoraj Ŝablonoj

Uzanta Tags

Tags difinita en Paragon Active Assurance povas esti aplikata al:

monitoroj
monitoraj ŝablonoj
Testaj Agentoj
TWAMP reflektoroj
Ping gastigantoj.
Por ekzample, vi povas tag monitoro kun la sama tag kiel subaro de Testagentoj, kiuj funkcios la ekranon. Ĉi tiu funkcio estas precipe utila se vi havas grandan nombron da ekranoj kaj ŝablonoj difinitaj.

Se vi starigis alarmon kun SNMP-kaptiloj por monitoro, tiam la SNMP-kaptiloj estos asignitaj la samaj tags kiel la monitoro, se ekzistas.
Kreante Tags
Malsupre ni montras kiel krei a tag kun nomo kaj koloro kiel difinita de la XMLtag> substrukturo.

Asignante a Tag
Asigni a tag al rimedo, vi aldonas ĝin kiel novantag> elemento sub latags> elemento por tiu rimedo.
Jen kiel asigni a tag al Testa Agento:

Asigni a tag al TWAMP reflektoro, faru la jenon:

Asignante a tag al monitoro estas traktita simile:

Alternative, vi povas atribui ekzistantan tag al iu ajn el ĉi tiuj rimedotipoj dum kreado de la rimedo, inkludante latags> elemento enhavanta la tag en demando.
Ĝisdatigo a Tag
Ĝisdatigante ekzistantan tag kun novaj atributoj estas analoga al kreado de a tag:

Malasigni a Tag
Neasigni a tag de rimedo, aldonu la atributon nc:operation="forigi" al latag> elemento apartenanta al la rimedo. Malsupre, ni malesignas a tag de monitoro.

Forigo de a Tag
Por forigi a tag entute de Kontrolcentro, la atributo nc:operation="forigi" denove estas uzata, sed ĉi-foje aplikata al la tag mem, difinita sub .

Solvado de problemoj

Problemo: Orchestrator kaj Paragon Active Assurance Out of Sync
La orkestranto kaj Paragon Active Assurance povas finiĝi ne sinkronigitaj ekzample se agordaj ŝanĝoj estis faritaj en la Kontrolcentro GUI, aŭ se aplikado de agordo ne sukcesis kaj reveni al la antaŭa stato malsukcesis.
En kazo de malsukcesa malfunkciigo, la NETCONF-servilo ne plu akceptos agordajn ŝanĝojn; ĝi respondos per erarmesaĝo deklarante ke agordo estas ŝlosita ĝis reen sinkronigita. Por sinkronigi kaj malŝlosi agordajn ŝanĝojn, vi devas ruli la komandon rpc sync-from-ncc, kiu sinkronigas ĉiujn agordojn de Kontrolcentro al la agorda datumbazo.
NOTO: La confd@netrounds.com uzanto (aŭ kio ajn estis agordita) devas havi superuzantprivilegiojn por ĉio esti sinkronigita sukcese. Ĉi tio povas esti atingita per la komando ncc user-update confd@netrounds.com –is-superuzanto Se la uzanto ne estas superuzanto, aperos averto dirante ke ne ĉio povus esti sinkronigita, sed ke ĉio, kio povus esti pritraktata, estis.
NOTO: Se via orkestranto ankaŭ konservas la agordon, vi devos re-sinkronigi ankaŭ tion ĉar la petita agordo (la agordo kiun la orkestranto atendas ke Kontrolcentro) ne estos aplikita.
Problemo: Komenca Sinkronigo (sync-from-ncc) Malsukcesis Pro Nesubtenataj Rimedoj
Se vi provas ruli rpc sync-from-ncc sur konto kiu havas sian agordon kreitan en la Kontrolcentro GUI, vi eble havos problemojn se la konto enhavas nesubtenatajn rimedojn. Oni rekomendas, ke vi komencu kun malplena konto kaj faru ĉian agordon de ĝi per NETCONF. Alie, se vi renkontas problemojn kun resursaj konfliktoj, vi devos forigi la konfliktajn rimedojn de la konto.
Problemo: NETCONF-komandoj malsukcesas kun ncclient.operations.rpc.RPCError: fiasko de komunikado de aplikaĵo
La NETCONF-servilo ne restarigas konekteblecon al la Kontrolcentro-servilo aŭtomate se Kontrolcentro estas rekomencita. Por restarigi la konekton al Kontrolcentro, rekomencu la NETCONF-procezon: sudo systemctl restart netrounds-confd

Notoj pri Test Agent-Aplikoj kaj Test Agent Appliances

Testagentaj Aplikoj en ConfD
Inter Testaj Agentoj, la (pli nova) Testa Agento-Apliko funkcias iom malsame ol la (pli malnova) Testa Aparato.
Testagentaj Aplikoj nuntempe ne subtenas interfacagordon. Tial, la YANG-skemo permesas specifi malplenan interfacagordon por tiaj Testagentoj. Vidu "ĉi tiun trairejon" sur paĝo 23 por ekzample.
Kiam vi sinkronigas la datumbazon ConfD kun Kontrolcentro per la komando sync-from-ncc, vi volas, ke la interfaco-agordo restu malplena kaj ne estu anstataŭita per tio, kio troviĝas en Kontrolcentro. Tial vi devas uzi specialan flagon –without_interface_config kun tiu komando kiam vi laboras kun Testagentaj Aplikoj.
Malplena Interfaco-Agordo por Test Agent Appliance
Kiel notite supre, Test Agent Application ne subtenas interfacagordon, kaj estas do eble preterlasi interfacojn en la YANG-skemo.
Sed estas ankaŭ uzkazoj, kie vi eble volas preterlasi la interfacan agordon de Testa Agento. EksampĈi tio povus esti orkestra scenaro, kie vi ŝpinas Testan Agenton uzante cloud-init, kaj vi volas ke la interfaco de tie estu uzata, anstataŭ lasi ConfD anstataŭi ĝin kiam la Testa Agento enretas.
YANG-Skemaj Ŝanĝoj Rilate Nedifinitajn Interfacojn
Ĉar malplena interfacagordo nun estas permesita (de versio 2.34.0 pluen), estas eble specifi ajnan interfacnomon kiel enigaĵon al tasko funkcianta kiel parto de testo aŭ monitoro.
Ĉi tio estas postulata por povi uzi Testagendan Aplikaĵon, ĉar por ĉi tiuj neniuj interfacaj nomoj estas difinitaj en ConfD. Rimarku, tamen, ke tio ankaŭ signifas, ke vi povas renkonti problemojn se hazarde vi agordas teston aŭ monitoron por uzi neekzistantan interfacon. Do bonvolu atenti ĉi tion.
Limigoj Dum Registrado de Testa Agento Kreita en ConfD
Kiam oni kreas Testan Agenton per la REST aŭ NETCONF/YANG API, ni ne povas scii antaŭe, kiu tipo ĝi estas: Testa Agento aŭ Testa Agento. Ĉi tio evidentiĝas nur post kiam la Testa Agento registriĝis.
Post kiam la Testa Agento estas registrita kaj fariĝis unu el ĉi tiuj konkretaj specoj, vi ne rajtas reregistri ĝin kiel malsaman tipon de Testa Agento. Ĉi tio signifas, ke vi ne rajtas unue registri ĝin kiel Testa Agenta Aparato, poste reregistri ĝin kiel Testa Agenta Aplikaĵo, aŭ inverse. Se vi bezonas Testan Agenton de malsama tipo, vi devos krei novan Testan Agenton.

Apendico: Arba Strukturo de Plena YANG-Modelo

En ĉi tiu apendico, la sekcio "Legendo" sur paĝo 81 klarigas la sintakson de la YANG-modela arbostrukturo generita per la komando pyang -f arbo.
La sekcio "YANG Model Tree Structure" sur paĝo 82 donas la eligon de tiu komando aplikita al netrounds-ncc.yang. Partoj de ĉi tiu produktaĵo estas reproduktitaj aliloke en la dokumento.
Legendo

YANG Modela Arba Strukturo

Juniper Networks, la emblemo de Juniper Networks, Juniper kaj Junos estas registritaj varmarkoj de Juniper Networks, Inc. en Usono kaj aliaj landoj. Ĉiuj aliaj varmarkoj, servmarkoj, registritaj markoj aŭ registritaj servmarkoj estas la posedaĵo de iliaj respektivaj posedantoj. Juniper Networks prenas neniun respondecon pri iuj eraroj en ĉi tiu dokumento. Juniper Networks rezervas la rajton ŝanĝi, modifi, translokigi aŭ alimaniere revizii ĉi tiun publikaĵon sen avizo. Kopirajto © 2023 Juniper Networks, Inc. Ĉiuj rajtoj rezervitaj.

Dokumentoj/Rimedoj

Juniper NETWORKS NETCONF & YANG-API-Programaro [pdf] Uzantogvidilo
NETCONF YANG API Programaro, YANG API Programaro, API Programaro, Programaro

Referencoj

Uzanto Manlibro

Enkonduko