NETCONF & YANG API Orchestration
ຄູ່ມືຈັດພີມມາ
2023-07-07
ປ່ອຍ 4.2

ແນະນຳ

ຈຸດປະສົງຂອງເອກະສານນີ້
ເອກະສານນີ້ອະທິບາຍວິທີການລວມ Paragon Active Assurance ກັບຜູ້ໃຫ້ບໍລິການເຄືອຂ່າຍຜ່ານ Control Center NETCONF & YANG API. Hands-on examples ແມ່ນມອບໃຫ້ວຽກງານຕົ້ນຕໍທີ່ກ່ຽວຂ້ອງ, ລວມທັງ: ການສ້າງແລະນໍາໃຊ້ຕົວແທນການທົດສອບ Virtual, ແລ່ນການທົດສອບແລະຕິດຕາມກວດກາ, ແລະການດຶງຜົນໄດ້ຮັບຈາກກິດຈະກໍາເຫຼົ່ານີ້.
ໃນເອກະສານນີ້, ncclient ລູກຄ້າ Python NETCONF ທີ່ມີຢູ່ຢ່າງເສລີແມ່ນຖືກນໍາໃຊ້ໃນບົດບາດຂອງນັກດົນຕີ.

ສົນທິສັນຍາ
ຕົວຫຍໍ້ຕໍ່ໄປນີ້ຖືກໃຊ້ໃນເອກະສານນີ້:

ຕົວຫຍໍ້	ຄວາມຫມາຍ
CLI	ການໂຕ້ຕອບເສັ້ນຄໍາສັ່ງ
EM	ຜູ້ຈັດການອົງປະກອບ
ES	ຜິດ​ພາດ​ຄັ້ງ​ທີ​ສອງ​
MEP	MEG (Maintenance Entity Group) ຈຸດສິ້ນສຸດ (ຄໍານິຍາມ ITU-T Y.1731) ຫຼື Maintenance End Point (ຄໍານິຍາມ Cisco)
NFV	Virtualization ຟັງຊັນເຄືອຂ່າຍ
NFVO	ຟັງຊັນເຄືອຂ່າຍ Virtualization Orchestrator
NSD	ລາຍລະອຽດການບໍລິການເຄືອຂ່າຍ
RPC	ໂທຂັ້ນຕອນໄລຍະໄກ
SIP	Session Initiation Protocol
SLA	ຂໍ້ຕົກລົງລະດັບການບໍລິການ
S-VNFM	ຜູ້ຈັດການພິເສດ VNF
VNF	ຟັງຊັນເຄືອຂ່າຍສະເໝືອນ
vTA	ຕົວແທນທົດສອບ Virtual

ຫມາຍເຫດກ່ຽວກັບຄວາມເຂົ້າກັນໄດ້ກັບກັບຄືນໄປບ່ອນ

ໃນເວີຊັ່ນ 2.35.4/2.36.0 ຂອງ NETCONF & YANG API, ການກວດສອບການຮ້ອງຂໍບາງຢ່າງໄດ້ຖືກເຮັດໃຫ້ເຂັ້ມງວດຂຶ້ນເພື່ອປະຕິບັດຕາມມາດຕະຖານ NETCONF. ນີ້ຫມາຍຄວາມວ່າລະຫັດລູກຄ້າໂດຍອີງໃສ່ສະບັບເກົ່າຂອງຄໍາແນະນໍານີ້ອາດຈະຖືກປະຕິເສດໃນປັດຈຸບັນ.
ຕົວຢ່າງample, ໃນ Python example ລະຫັດ, ບໍ່ມີຄຸນລັກສະນະ namespace ໄດ້ຖືກສະຫນອງໃຫ້. ດຽວນີ້ namespace ຕ້ອງໄດ້ຮັບການສະຫນອງໃນ 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 ສ້າງ
ຄໍາສັ່ງໃນຄູ່ມືການຕິດຕັ້ງ, ພາກ ການຕິດຕັ້ງ ConfD. ໃຫ້ລະຫັດຜ່ານທີ່ກໍານົດໂດຍຄໍາສັ່ງດຽວກັນ.
ໃນຜົນໄດ້ຮັບ, ກວດສອບວ່າໂມດູນສູນຄວບຄຸມໄດ້ຖືກລວມເຂົ້າ. ຜົນຜະລິດຄວນຈະມີເສັ້ນເຊັ່ນ:
http://ncc.netrounds.com?module=netrounds-ncc&revision=2017-06-15

ການຊິ້ງຂໍ້ມູນຖານຂໍ້ມູນການຕັ້ງຄ່າກັບສູນຄວບຄຸມ

ສຸດທ້າຍ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ປັບປຸງຖານຂໍ້ມູນການຕັ້ງຄ່າໂດຍຜ່ານ NETCONF. ພວກເຮົາຈະເຮັດແນວນັ້ນຢູ່ທີ່ນີ້ໂດຍວິທີການຂອງຫ້ອງສະຫມຸດ Python ທີ່ເອີ້ນວ່າ ncclient (NETCONF Client). ຢ່າງໃດກໍ່ຕາມ, ວຽກງານດັ່ງກ່າວຍັງສາມາດສໍາເລັດໃນພາສາການຂຽນໂປຼແກຼມທີ່ແຕກຕ່າງກັນຕາບໃດທີ່ມັນໃຊ້ໂປໂຕຄອນ NETCONF/YANG.
ບົດບາດຂອງ ncclient ແມ່ນເພື່ອປະຕິບັດເປັນລູກຄ້າຕໍ່ກັບເຊີບເວີ ConfD ທີ່ເປັນເຈົ້າພາບ NETCONF/YANG API.

ມັນເປັນມູນຄ່າທີ່ຊີ້ໃຫ້ເຫັນວ່າ ncclient ບໍ່ກ່ຽວຂ້ອງກັບສູນຄວບຄຸມ (ໃນເມື່ອກ່ອນ "Netrounds Control Center"), ເຖິງແມ່ນວ່າຊື່ຈະເລີ່ມຕົ້ນດ້ວຍ "ncc".
ນີ້ແມ່ນວິທີການຕິດຕັ້ງ ncclient:

• ດາວນ໌ໂຫລດຊອບແວຈາກ https://github.com/ncclient/ncclient.
• ດໍາເນີນການຄໍາສັ່ງນີ້: pip ຕິດຕັ້ງ ncclient

ໃນປັດຈຸບັນພວກເຮົາສາມາດດໍາເນີນການ synchronization ດັ່ງຕໍ່ໄປນີ້. ຈົ່ງຈື່ໄວ້ຢ່າງລະມັດລະວັງວ່າອັນນີ້ຕ້ອງເຮັດຢູ່ໃນຄອມພິວເຕີແຍກຕ່າງຫາກ, ແລະບໍ່ແມ່ນຢູ່ໃນເຊີບເວີຂອງສູນຄວບຄຸມເອງ:

#
# ຫມາຍ​ເຫດ​:
# script ນີ້ເຮັດຫນ້າທີ່ເປັນລູກຄ້າໄປສູ່ ConfD ແລ່ນຢູ່ໃນເຄື່ອງແມ່ຂ່າຍ NCC.
# ມັນຈະໃຊ້ NETCONF/YANG API ສໍາລັບການສື່ສານ.

ໝາຍເຫດ: ຂັ້ນຕອນນີ້ຍັງຕ້ອງການທຸກຄັ້ງທີ່ຕົວແທນທົດສອບໄດ້ຖືກຕິດຕັ້ງ ແລະລົງທະບຽນເປັນເອກະລາດຈາກ NETCONF. ເບິ່ງບັນທຶກໃນພາກ “Overview of Test Agent Orchestration” ຢູ່ໜ້າ 17 ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມ.

ການຕັ້ງຄ່າບັນຊີ Paragon Active Assurance ຄວບຄຸມຫຼາຍ NETCONF

ຂັ້ນຕອນຂ້າງລຸ່ມນີ້ແມ່ນຕ້ອງການພຽງແຕ່ຖ້າທ່ານຕ້ອງການຕັ້ງບັນຊີ Paragon Active Assurance ເພີ່ມເຕີມທີ່ຈະຄວບຄຸມໂດຍ NETCONF, ນອກເຫນືອຈາກບັນຊີທີ່ຖືກຕັ້ງຄ່າດ້ວຍວິທີນີ້ໃນຄູ່ມືການຕິດຕັ້ງ, ພາກ "ການຕິດຕັ້ງ ConfD".
ສໍາລັບແຕ່ລະບັນຊີດັ່ງກ່າວ, ດໍາເນີນການດັ່ງຕໍ່ໄປນີ້:

• ໃນສູນຄວບຄຸມ, ເຂົ້າສູ່ລະບົບບັນຊີ ແລະໄປຫາບັນຊີ > ສິດອະນຸຍາດ.
• ເພີ່ມຜູ້ໃຊ້ "confd@netrounds.com“, ແລະໃຫ້ສິດຜູ້ເບິ່ງແຍງຜູ້ໃຊ້ ConfD ນີ້ໃນ GUI ໂດຍການຄລິກທີ່ປຸ່ມເຊີນ.
• synchronize ຖານຂໍ້ມູນການຕັ້ງຄ່າກັບ Control Center ດັ່ງທີ່ອະທິບາຍໄວ້ໃນພາກ “Synchronizing the Configuration Database with Control Center” ໃນໜ້າທີ 4.
  ໃນປັດຈຸບັນທ່ານຄວນຈະສາມາດຄວບຄຸມບັນຊີ Paragon Active Assurance ຫຼາຍບັນຊີກັບຜູ້ໃຊ້ ConfD ດຽວກັນ.

ໝາຍເຫດ: ເມື່ອທ່ານເລີ່ມຄວບຄຸມບັນຊີ Paragon Active Assurance ຜ່ານ ConfD, ທ່ານຕ້ອງບໍ່ປ່ຽນແປງບັນຊີນີ້ຜ່ານທາງ web GUI ກ່ຽວກັບຄຸນສົມບັດການຮັບປະກັນການເຄື່ອນໄຫວຂອງ Paragon ທີ່ເປັນ “config” (ເບິ່ງບົດ “ຄຸນສົມບັດທີ່ຮອງຮັບໃນ Paragon Active Assurance” ຢູ່ໜ້າ 9). ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ເຮັດ​ໄດ້​, ການ​ສູນ​ເສຍ​ການ​ຊິງ​ຈະ​ສົ່ງ​ຜົນ​.

ການແນະນໍາ NETCONF Orchestration API

ເກີນview

NFVO ພາກສ່ວນທີສາມ ຫຼື ຜູ້ໃຫ້ບໍລິການ orchestrator ໂດຍທົ່ວໄປແລ້ວແມ່ນອົງປະກອບທີ່ລິເລີ່ມການສອບເສັງ ແລະການຕິດຕາມໂດຍນຳໃຊ້ Control Center API. ນັກດົນຕີນີ້ຍັງດຶງເອົາຜົນການວັດແທກລວມຈາກກິດຈະກໍາຂອງຕົວແທນທົດສອບ. ການປະຕິບັດ KPIs ອາດຈະຖືກດຶງມາໂດຍລະບົບການຄຸ້ມຄອງການປະຕິບັດຂອງພາກສ່ວນທີສາມ, ໃນຂະນະທີ່ເຫດການ - ເມື່ອຖືກກະຕຸ້ນໂດຍການລະເມີດຂອບເຂດທີ່ກໍານົດໄວ້ໃນສູນຄວບຄຸມ - ສາມາດຖືກສົ່ງໄປຫາລະບົບການຄຸ້ມຄອງຄວາມຜິດຂອງພາກສ່ວນທີສາມ.
ເພື່ອສະຫຼຸບ, ຮູບຂ້າງລຸ່ມນີ້ສະແດງໃຫ້ເຫັນວິທີການ Paragon Active Assurance ພົວພັນກັບລະບົບພາກສ່ວນທີສາມອື່ນໆໃນພູມສັນຖານ OSS.

• NFVO/Service Orchestrator: ແນະນຳໃຫ້ຜູ້ຈັດການ VNF ນຳໃຊ້ vTAs ແລະ configure Paragon Active Assurance ເຂົ້າໃນຕ່ອງໂສ້ການບໍລິການ. ເມື່ອການບໍລິການຖືກເປີດໃຊ້ງານແລ້ວ, ນັກປະພັນຈະໃຊ້ API ໄປຫາສູນຄວບຄຸມເພື່ອກະຕຸ້ນການທົດສອບການເປີດໃຊ້ການບໍລິການ ແລະດຶງເອົາຜົນໄດ້ຮັບຜ່ານ/ລົ້ມເຫລວ. ຖ້າການທົດສອບຜ່ານໄປ, ນັກສະແດງຈະໃຊ້ API ໄປຫາສູນຄວບຄຸມເພື່ອເລີ່ມຕົ້ນການກວດສອບການບໍລິການ. KPIs ຈາກການຕິດຕາມຈະຖືກດຶງມາຢ່າງຕໍ່ເນື່ອງໂດຍນັກ orchestrator ຫຼືໂດຍແພລະຕະຟອມການຄຸ້ມຄອງການປະຕິບັດແຍກຕ່າງຫາກ.
• ສູນຄວບຄຸມ: ນຳໃຊ້, ປັບຂະໜາດ, ແລະຢຸດຕິການ vTA ຕາມການແນະນຳໂດຍ NFVO ຫຼື ວົງດົນຕີບໍລິການ.
• ລະບົບການຄຸ້ມຄອງການປະຕິບັດຫຼືລະບົບການຄຸ້ມຄອງຄຸນນະພາບການບໍລິການ: ອ່ານ KPIs ຈາກການຕິດຕາມການເຄື່ອນໄຫວຜ່ານ API ຂອງສູນຄວບຄຸມ.
• ລະບົບການຄຸ້ມຄອງຄວາມຜິດ: ໄດ້ຮັບການແຈ້ງເຕືອນ NETCONF, SNMP, ຫຼືອີເມວຈາກສູນຄວບຄຸມຖ້າ SLAs ຖືກລະເມີດ.

ຄໍານິຍາມຂອງແນວຄວາມຄິດໃນ Paragon Active Assurance

• ຕົວແທນທົດສອບ: ອົງປະກອບທີ່ປະຕິບັດການວັດແທກ (ສໍາລັບການທົດສອບເຊັ່ນດຽວກັນກັບການຕິດຕາມ) ໃນລະບົບ Paragon Active Assurance. ຕົວແທນທົດສອບປະກອບດ້ວຍຊອບແວທີ່ມີຄວາມສາມາດໃນການສ້າງ, ຮັບ, ແລະວິເຄາະການຈະລາຈອນເຄືອຂ່າຍທີ່ແທ້ຈິງ.
• ປະເພດຂອງຕົວແທນທົດສອບທີ່ສົນທະນາໃນເອກະສານນີ້ແມ່ນຕົວແທນທົດສອບ Virtual (vTA), ຫນ້າທີ່ເຄືອຂ່າຍ virtual (VNF) ທີ່ໃຊ້ໃນ hypervisor. ຕົວແທນທົດສອບປະເພດອື່ນໆກໍ່ມີຢູ່.
• ມີສອງປະເພດພື້ນຖານຂອງການວັດແທກຢູ່ໃນ Paragon Active Assurance, ການທົດສອບແລະການຕິດຕາມ.
• ການທົດສອບ: ການທົດສອບປະກອບດ້ວຍຂັ້ນຕອນຫນຶ່ງຫຼືຫຼາຍຂັ້ນຕອນ, ແຕ່ລະຄົນມີໄລຍະເວລາກໍານົດ, ກໍານົດ. ຂັ້ນຕອນຖືກປະຕິບັດຕາມລໍາດັບ. ແຕ່​ລະ​ບາດ​ກ້າວ​ອາດ​ຈະ​ມີ​ການ​ແລ່ນ​ຫຼາຍ​ວຽກ​ງານ​ພ້ອມ​ກັນ​.
• ຈໍສະແດງຜົນ: ຈໍສະແດງຜົນບໍ່ມີໄລຍະເວລາທີ່ລະບຸໄວ້ແຕ່ດໍາເນີນການຢ່າງບໍ່ມີກໍານົດ. ເຊັ່ນດຽວກັນກັບຂັ້ນຕອນໃນການທົດສອບ, ຈໍສະແດງຜົນອາດຈະປະຕິບັດຫຼາຍຫນ້າວຽກພ້ອມກັນ.
• ແມ່ແບບ: ເມື່ອ Paragon Active Assurance ຖືກຄວບຄຸມໂດຍນັກ orchestrator, ການທົດສອບແລະການຕິດຕາມຈະຖືກປະຕິບັດສະເຫມີໂດຍແມ່ແບບທີ່ການທົດສອບຫຼືຕິດຕາມກວດກາຖືກກໍານົດ. ການຕັ້ງຄ່າພາລາມິເຕີສາມາດຖືກສົ່ງຜ່ານເປັນວັດສະດຸປ້ອນໄປຫາແມ່ແບບໃນເວລາແລ່ນ.

ຂະບວນການເຮັດວຽກສໍາລັບອັດຕະໂນມັດ
ເວລາອອກແບບ

ໃນເວລາອອກແບບ, ທ່ານກະກຽມການວັດແທກໂດຍການສ້າງແມ່ແບບສໍາລັບການທົດສອບແລະການຕິດຕາມໃນ Paragon Active Assurance. ວິທີ​ເຮັດ​ແບບ​ນັ້ນ​ມີ​ຢູ່​ໃນ​ບົດ “ການ​ທົດ​ສອບ​ແລະ​ການ​ຕິດ​ຕາມ​ແມ່​ແບບ” ໃນ​ໜ້າ 15.

ເວລາແລ່ນ
ໃນເວລາແລ່ນ, ທ່ານຕັ້ງຄ່າອຸປະກອນຂອງທ່ານແລະປະຕິບັດການວັດແທກຕົວຈິງ.

• ຫຼາຍກວ່າview ຂອງທັງຫມົດ examples ໄດ້ຖືກພົບເຫັນຢູ່ໃນບົດ “Examples of Controlling Paragon Active Assurance via NETCONF & YANG API” ຢູ່ໜ້າ 15.
• ວິທີການນຳໃຊ້ ແລະກຳນົດຄ່າຕົວແທນທົດສອບແມ່ນຜ່ານໄປໃນບົດ “Examples: Test Agents” ໃນໜ້າທີ 16.
• ວິທີການນໍາເຂົ້າສິນຄ້າຄົງຄັງເຊັ່ນ TWAMP ເຄື່ອງສະທ້ອນແສງແລະຊ່ອງ IPTV ແມ່ນຜ່ານໃນບົດ "Examples: ລາຍການສາງ” ໃນໜ້າທີ 29.
• ວິທີການປັບຄ່າໂມງປຸກໄດ້ຖືກອະທິບາຍໄວ້ໃນບົດ “Examples: ປຸກ” ໃນໜ້າທີ 35.
• ວິທີການດໍາເນີນການທົດສອບແລະການຕິດຕາມໂດຍການປະຕິບັດແມ່ແບບ Paragon Active Assurance ຜ່ານ NETCONF ໄດ້ຖືກອະທິບາຍໄວ້ໃນບົດ "Examples: ການທົດສອບ” ໃນໜ້າທີ 43 ແລະ “Examples: Monitors” ໃນໜ້າ 54.

ຄຸນສົມບັດທີ່ຮອງຮັບໃນ Paragon Active Assurance

ທຸກໆປະເພດການທົດສອບແລະການຕິດຕາມໃນ Paragon Active Assurance ສາມາດສ້າງແລະປະຕິບັດໄດ້ໂດຍຜ່ານການນໍາໃຊ້ແມ່ແບບ. ວິທີການເຮັດນີ້ແມ່ນກວມເອົາໃນການຊ່ວຍເຫຼືອໃນແອັບຯພາຍໃຕ້ "ການທົດສອບແລະການຕິດຕາມ" > "ການສ້າງແມ່ແບບ".

ການສ້າງບັນຊີ Paragon Active Assurance ແມ່ນບໍ່ຮອງຮັບໃນປັດຈຸບັນ; ແນວໃດກໍ່ຕາມ, ໜຶ່ງ ຫຼືຫຼາຍບັນຊີທີ່ກຳນົດໄວ້ລ່ວງໜ້າຈະຖືກຕັ້ງໃຫ້ຜູ້ໃຊ້.
ຕາຕະລາງຂ້າງລຸ່ມນີ້ໃຫ້ລາຍລະອຽດວ່າຄຸນສົມບັດໃດແດ່ໃນ Paragon Active Assurance ມີຢູ່ໃນລຸ້ນນີ້, ແລະລັກສະນະເຫຼົ່ານີ້ຖືກສະແດງຢູ່ໃນ YANG ແນວໃດ.

ຄໍາອະທິບາຍກ່ຽວກັບການກໍ່ສ້າງ YANG

ເພື່ອຄວາມສະດວກ, ຄໍານິຍາມແມ່ນໃຫ້ຢູ່ທີ່ນີ້ຂອງໂຄງສ້າງ YANG ທີ່ອ້າງອີງໃນຕາຕະລາງຄຸນສົມບັດ.

• Config (config=true): ຂໍ້​ມູນ​ການ​ຕັ້ງ​ຄ່າ, ຕ້ອງ​ການ​ເພື່ອ​ຫັນ​ປ່ຽນ​ລະ​ບົບ​ຈາກ​ລັດ​ຫນຶ່ງ​ໄປ​ອີກ​.
• State (config=false): ຂໍ້ມູນຂອງລັດ: ຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບລະບົບທີ່ບໍ່ແມ່ນຂໍ້ມູນການຕັ້ງຄ່າ, ເຊັ່ນ: ຂໍ້ມູນສະຖານະແບບອ່ານຢ່າງດຽວ ແລະສະຖິຕິທີ່ເກັບກໍາ.
• RPC: A Remote Procedure Call, ດັ່ງທີ່ໃຊ້ພາຍໃນ NETCONF protocol.
• ການແຈ້ງເຕືອນ: ການແຈ້ງເຕືອນເຫດການຖືກສົ່ງຈາກເຊີບເວີ NETCONF ໄປຫາລູກຄ້າ NETCONF.

ຕາຕະລາງຂອງ Paragon Active Assurance ຄຸນນະສົມບັດທີ່ມີຢູ່ສໍາລັບການ Orchestration
ຊັບພະຍາກອນ: ການຕິດຕາມ
ເສັ້ນທາງຢາງ:/accounts/account/monitors

ຄຸນສົມບັດ	ຄຸນສົມບັດຍ່ອຍ	YANG ກໍ່ສ້າງ
ສ້າງ/ແກ້ໄຂ/ລຶບຈໍພາບ	ອີງໃສ່ແມ່ແບບຕິດຕາມກວດກາ	ກຳນົດຄ່າ
ຈໍສະແດງຜົນເລີ່ມຕົ້ນ / ຢຸດ	–	ກຳນົດຄ່າ
ຕິດຕາມແມ່ແບບ	ລາຍຊື່ແມ່ແບບຈໍພາບທີ່ມີຢູ່ກັບວັດສະດຸປ້ອນ	ລັດ
ການແຈ້ງເຕືອນ NETCONF	ປ່ຽນສະຖານະປຸກແລ້ວ	ແຈ້ງການ
ຕິດຕາມຜົນໄດ້ຮັບ	ຕົວນັບ SLA/ES ສໍາລັບລະດັບສູງສຸດ (%) ຕົວນັບ SLA/ES ສຳລັບລະດັບໜ້າວຽກ (%)	ລັດ

ບໍ່ເຫມືອນກັບການທົດສອບ (ປຽບທຽບຊັບພະຍາກອນ: ການທົດສອບຂ້າງລຸ່ມນີ້), ຈໍສະແດງຜົນບໍ່ໄດ້ເລີ່ມຕົ້ນດ້ວຍ RPC ແຕ່ແທນທີ່ຈະເຮັດການຕັ້ງຄ່າຈໍພາບ.
ຊັບພະຍາກອນ: ການທົດສອບ
ເສັ້ນທາງ YANG: /accounts/account/tests

ຄຸນສົມບັດ	ຄຸນສົມບັດຍ່ອຍ	YANG ກໍ່ສ້າງ
ເລີ່ມການທົດສອບ	ອີງໃສ່ແບບທົດສອບ	RPC
ຈັດການການທົດສອບ	ລາຍຊື່ການທົດສອບທີ່ມີສະຖານະພາບ	ລັດ
ແມ່ແບບທົດສອບ	ລາຍຊື່ແມ່ແບບທົດສອບທີ່ມີຢູ່ແລ້ວດ້ວຍການປ້ອນຂໍ້ມູນ	ລັດ
ການແຈ້ງເຕືອນ NETCONF	ປ່ຽນສະຖານະການທົດສອບແລ້ວ	ແຈ້ງການ
ຜົນການທົດສອບ	ໄດ້​ຮັບ​ສະ​ຖາ​ນະ​ພາບ​ຂັ້ນ​ຕອນ​ການ​ທົດ​ສອບ (ຜ່ານ​, ລົ້ມ​ເຫຼວ​, ຄວາມ​ຜິດ​ພາດ​, ... )	ລັດ

ຊັບພະຍາກອນ: ຕົວແທນທົດສອບ
ເສັ້ນທາງ YANG:

• /accounts/account/test-agents (Config)
• /accounts/account/registered-test-agents (ລັດ)

ຕົວແທນທົດສອບພາຍໃຕ້ /accounts/account/test-agents ແມ່ນຜູ້ທີ່ຖືກ config ໃນບັນຊີ. ພຽງແຕ່ຕົວແທນທົດສອບເຫຼົ່ານີ້ສາມາດຖືກຕັ້ງຄ່າແລະໃຊ້ໃນການທົດສອບແລະຕິດຕາມກວດກາຜ່ານ NETCONF ໂດຍນັກສະແດງ.
ຫຼັງຈາກທີ່ທ່ານໄດ້ຕັ້ງຄ່າຕົວແທນທົດສອບ ແລະມັນໄດ້ລົງທະບຽນເຂົ້າໃນບັນຊີ, ຕົວແທນທົດສອບຈະປາກົດພາຍໃຕ້ /accounts/account/registered-test-agents. ທ່ານສາມາດຊອກຫາຕົວແທນທົດສອບທັງຫມົດທີ່ລົງທະບຽນໂດຍໃຊ້ຄໍາສັ່ງ "get" ໃນ NETCONF (ປຽບທຽບບົດ Examples: ຕົວແທນທົດສອບ).
ພາຍໃຕ້ /accounts/account/registered-test-agents ທ່ານອາດຈະຊອກຫາຕົວແທນທົດສອບທີ່ຍັງບໍ່ທັນໄດ້ກຳນົດຄ່າ. ຕົວແທນທົດສອບດັ່ງກ່າວຈະຕ້ອງຖືກຕັ້ງຄ່າກ່ອນທີ່ຈະສາມາດນຳໃຊ້ໄດ້.
ໃນສະຖານະການ orchestration, ໂດຍທົ່ວໄປແລ້ວແນະນໍາໃຫ້ທ່ານເຮັດການຕັ້ງຄ່າທັງຫມົດຂອງບັນຊີ Paragon Active Assurance ຂອງທ່ານໂດຍຜ່ານ NETCONF. ນີ້ຮັບປະກັນວ່າຕົວແທນທົດສອບແລະຕົວແທນການທົດສອບທີ່ລົງທະບຽນບໍ່ແຕກຕ່າງກັນ.

ຄຸນສົມບັດ	ຄຸນສົມບັດຍ່ອຍ	YANG ກໍ່ສ້າງ
ສ້າງຕົວແທນທົດສອບລ່ວງໜ້າໃນເຊີບເວີ	–	ກຳນົດຄ່າ
ຕັ້ງຄ່າຕົວແທນທົດສອບອອບລາຍ	(Control Center pushes config to Test Agent ເມື່ອ​ມັນ​ມາ​ອອນ​ໄລ​ນ​໌​)	ກຳນົດຄ່າ
ໃຊ້ຕົວແທນທົດສອບທີ່ມີຢູ່ແລ້ວ / ຕັ້ງຄ່າພາຍນອກ	ໃຊ້ໃນການທົດສອບ / ຕິດຕາມກວດກາ	ກຳນົດຄ່າ
	ຕັ້ງຄ່າການໂຕ້ຕອບ	ກຳນົດຄ່າ
	ໄດ້ຮັບສະຖານະພາບ	ລັດ
ຕັ້ງຄ່າຕົວແທນທົດສອບ (ເຄື່ອງທົດສອບເທົ່ານັ້ນ)	ຕັ້ງຄ່າ NTP	ກຳນົດຄ່າ
	ຕັ້ງຄ່າຂົວ	ກຳນົດຄ່າ
	ຕັ້ງຄ່າການໂຕ້ຕອບ VLAN	ກຳນົດຄ່າ
	ຕັ້ງຄ່າຄີ SSH	ກຳນົດຄ່າ
	IPv6	ກຳນົດຄ່າ
ປະໂຫຍດ	ປິດເປີດໃໝ່	RPC
	ອັບເດດ	RPC
ການແຈ້ງເຕືອນ NETCONF	ປ່ຽນສະຖານະອອນລາຍແລ້ວ	ແຈ້ງການ
ສະຖານະ	​ໄດ້​ຮັບ​ສະ​ຖາ​ນະ​ພາບ​ຂອງ​ລະ​ບົບ (uptime​, ການ​ນໍາ​ໃຊ້​ຫນ່ວຍ​ຄວາມ​ຈໍາ​, ໂຫຼດສະເລ່ຍ, ຮຸ່ນ)	ລັດ

ຊັບພະຍາກອນ: ສາງ
ເສັ້ນທາງຢາງ: /accounts/account/twamp- ແສງສະທ້ອນ

ສະຫນັບສະຫນູນຄວາມສາມາດ NETCONF

ຕາຕະລາງຂ້າງລຸ່ມນີ້ຊີ້ໃຫ້ເຫັນ IETF RFCs ທີ່ອະທິບາຍຄວາມສາມາດຂອງ NETCONF ທີ່ໃຊ້ສໍາລັບຈຸດປະສົງຂອງ Paragon Active Assurance orchestration.

• ietf-netconf.yang
• IETF RFC 6241, Network Configuration Protocol (NETCONF), https://tools.ietf.org/html/rfc6241
• ວິທີຈັດການຄວາມຜິດພາດທີ່ຮອງຮັບແມ່ນ rollback-on-error.
• ບ່ອນເກັບຂໍ້ມູນທີ່ຮອງຮັບພຽງແຕ່ສາມາດຂຽນໄດ້.
• ietf-netconf-notifications.yang
• IETF RFC 5277, ການແຈ້ງເຕືອນເຫດການ NETCONF, https://tools.ietf.org/html/rfc5277

ການທົດສອບແລະຕິດຕາມກວດກາແມ່ແບບ
ແມ່ແບບສໍາລັບການທົດສອບແລະປະເພດຕິດຕາມກວດກາຈໍາເປັນຕ້ອງຖືກຕັ້ງຄ່າດ້ວຍຕົນເອງໂດຍຜ່ານສ່ວນຕິດຕໍ່ຜູ້ໃຊ້ດ້ານຫນ້າຂອງ Paragon Active Assurance. ວິທີການເຮັດນີ້ແມ່ນກວມເອົາໃນການຊ່ວຍເຫຼືອໃນແອັບຯພາຍໃຕ້ "ການທົດສອບແລະການຕິດຕາມ" > "ການສ້າງແມ່ແບບ".

Examples ຂອງການຄວບຄຸມ Paragon Active Assurance ຜ່ານ NETCONF & YANG API

ໃນບົດທີ່ຕິດຕາມມາ, ມັນສົມມຸດວ່າແມ່ແບບການທົດສອບແລະການຕິດຕາມທີ່ເຫມາະສົມໄດ້ຖືກກໍານົດໄວ້ຕາມຄໍາແນະນໍາທີ່ໄດ້ລະບຸໄວ້ໃນບົດ "ແບບທົດສອບແລະການຕິດຕາມ" ໃນຫນ້າ 15.

ເຄື່ອງມືທີ່ໃຊ້ໃນ Examples
ທັງຫມົດ examples ໃນບົດຕໍ່ໆໄປໄດ້ຖືກສ້າງຂື້ນໂດຍໃຊ້ເຄື່ອງມືທີ່ມີຢູ່ຢ່າງເສລີຕໍ່ໄປນີ້:

• Pang: ໃຊ້ເພື່ອສະແດງພາບ ແລະເບິ່ງຕົວແບບຂອງ YANG.
• ມີຢູ່ https://github.com/mbj4668/pyang (clone ຈາກ git ແລະດໍາເນີນການຕິດຕັ້ງ python setup.py).
• ລູກຄ້າ Python NETCONF "ncclient": ໃຊ້ເພື່ອຕິດຕໍ່ສື່ສານກັບສູນຄວບຄຸມໂດຍໃຊ້ NETCONF.
• ມີຢູ່ https://github.com/ncclient/ncclient (ແລ່ນ pip ຕິດຕັ້ງ ncclient).
  ຮູບແບບຂໍ້ມູນ netrounds-ncc.yang ແມ່ນພົບເຫັນຢູ່ໃນ /opt/netrounds-confd ເມື່ອ ConfD ໄດ້ຖືກຕິດຕັ້ງຕາມຄູ່ມືການຕິດຕັ້ງ).

ເກີນview ຂອງ​ວຽກ​ງານ​ທີ່​ສໍາ​ຄັນ​ປະ​ຕິ​ບັດ​

(ບາງວຽກງານເພີ່ມເຕີມແມ່ນໄດ້ຍົກຕົວຢ່າງໃນສິ່ງທີ່ຕໍ່ໄປນີ້.)

• “ການ​ສ້າງ​ແລະ​ນຳ​ໃຊ້​ຕົວ​ແທນ​ທົດ​ສອບ​ໃໝ່” ຢູ່​ໜ້າ 16
• “ການສ້າງລາຍການສິນຄ້າຄົງຄັງ (ເຊັ່ນ: ເຄື່ອງສະທ້ອນແສງ)” ໃນໜ້າທີ 29
• “ການຕັ້ງແມ່ແບບປຸກ ແລະບ່ອນທີ່ຈະສົ່ງສັນຍານເຕືອນ” ໃນໜ້າທີ 35
• “ການ​ສ້າງ​ແລະ​ການ​ທົດ​ສອບ” ໃນ​ຫນ້າ 45
• “ການດຶງເອົາຜົນການທົດສອບ” ຢູ່ໜ້າ 50
• “ການເລີ່ມຕົ້ນຈໍພາບ (ລວມທັງການຕັ້ງໂມງປຸກ)” ໃນໜ້າ 60
• “ການດຶງຂໍ້ມູນສະຖານະ SLA ສໍາລັບຈໍພາບ” ຢູ່ໜ້າ 67
• “ເຮັດ​ວຽກ​ກັບ tags” ຢູ່ໜ້າ 71

Examples: ຕົວແທນທົດສອບ

ເກີນview ຂອງ​ການ​ທົດ​ສອບ​ຕົວ​ແທນ Orchestration​
ຕົວແທນທົດສອບໃນ Paragon Active Assurance ຖືກພິຈາລະນາເປັນ "ການຕັ້ງຄ່າ" ໃນສະພາບການຂອງ orchestration. ນີ້ຫມາຍຄວາມວ່າການສ້າງ, ການຄວບຄຸມ, ແລະການລຶບຕົວແທນການທົດສອບຄວນຈະເຮັດຜ່ານ orchestrator ແລະ NETCONF ແທນທີ່ຈະຜ່ານ Paragon Active Assurance GUI.
ສິ່ງສໍາຄັນ: ຖ້າຕົວແທນທົດສອບຖືກຕິດຕັ້ງໂດຍນັກວິຊາການແລະລົງທະບຽນກັບ Control Center ໂດຍບໍ່ໄດ້ສ້າງຄັ້ງທໍາອິດຜ່ານ NETCONF & YANG API, Test Agent ຈະບໍ່ມີຢູ່ໃນຖານຂໍ້ມູນການຕັ້ງຄ່າ, ແລະລະບົບຈະອອກຈາກການຊິ້ງຂໍ້ມູນ. ເພື່ອໃຫ້ ConfD ຮູ້ຈັກຕົວແທນການທົດສອບໃນກໍລະນີນີ້, ມັນຈໍາເປັນຕ້ອງດໍາເນີນການ synchronization ໃຫມ່ກັບ Control Center, ຕາມລາຍລະອຽດໃນພາກ "Synchronizing the Configuration Database with Control Center" ໃນຫນ້າ 4.

ການຈັດວາງຕົວແທນທົດສອບສະເໝືອນ (vTAs) ຄວນເຮັດໃນຂັ້ນຕອນຕໍ່ໄປນີ້:

1. ສ້າງຕົວແທນທົດສອບ Virtual, ລວມທັງການຕັ້ງຄ່າການໂຕ້ຕອບຂອງມັນ, ໂດຍໃຊ້ການໂຕ້ຕອບ NETCONF & YANG ກັບສູນຄວບຄຸມ. ຊື່ຂອງຕົວແທນທົດສອບຈະເປັນກະແຈສະເພາະຂອງມັນ.
2. ນຳໃຊ້ vTA ໃນເວທີ virtualization. ປະຕິບັດຕາມຄໍາແນະນໍາໃນການຊ່ວຍເຫຼືອອອນໄລນ໌ພາຍໃຕ້ຕົວແທນການທົດສອບ > ການຕິດຕັ້ງ. ການຕັ້ງຄ່າອິນເຕີເຟດພື້ນຖານທີ່ອະນຸຍາດໃຫ້ vTA ເຊື່ອມຕໍ່ກັບສູນຄວບຄຸມ, ເຊັ່ນດຽວກັນກັບຂໍ້ມູນປະຈໍາຕົວສໍາລັບການພິສູດຢືນຢັນ, ໄດ້ຖືກສະຫນອງໃຫ້ຢູ່ໃນ vTA ໂດຍໃຊ້ຂໍ້ມູນຜູ້ໃຊ້ cloud-init.
   ເມື່ອ vTA ບູດແລ້ວ, ມັນຈະເຊື່ອມຕໍ່ໂດຍອັດຕະໂນມັດກັບສູນຄວບຄຸມໂດຍໃຊ້ການເຊື່ອມຕໍ່ OpenVPN ທີ່ເຂົ້າລະຫັດໄວ້. ການແຈ້ງເຕືອນ NETCONF ຖືກສົ່ງມາຕັ້ງແຕ່ຄ່າຂອງຕົວກໍານົດການປ່ຽນສະຖານະ test-agent-statuschange ຂອງ vTA ໄດ້ປ່ຽນເປັນ "ອອນໄລນ໌".
   ໝາຍເຫດ: ເນື່ອງຈາກຊື່ຂອງ vTA ແມ່ນຕົວລະບຸຂອງມັນຢູ່ໃນສູນຄວບຄຸມ, ຊື່ນີ້ຕ້ອງຄືກັບທີ່ກຳນົດໄວ້ໃນ Control Center ໃນ “ຂັ້ນຕອນທີ 1” ໃນໜ້າ 17.
3. ເມື່ອ vTA ໄດ້ເຊື່ອມຕໍ່ ແລະພິສູດຢືນຢັນກັບສູນຄວບຄຸມ, ການຕັ້ງຄ່າການໂຕ້ຕອບຈະຖືກຍູ້ໄປຫາ vTA. ນີ້ແມ່ນການຕັ້ງຄ່າການໂຕ້ຕອບທີ່ສະຫນອງໃຫ້ຢູ່ໃນ "ຂັ້ນຕອນ 1" ໃນຫນ້າ 17 ເມື່ອ vTA ຖືກສ້າງຂຶ້ນໃນ Control Center.
4. ຫຼັງຈາກ vTA ໄດ້ຮັບໃຊ້ຈຸດປະສົງຂອງມັນ, ໃຫ້ລຶບ vTA.

ການ​ສ້າງ​ແລະ​ການ​ນໍາ​ໃຊ້​ຕົວ​ແທນ​ການ​ທົດ​ສອບ​ໃຫມ່​

ທໍາອິດພວກເຮົາຈໍາເປັນຕ້ອງສ້າງຕົວແທນທົດສອບໂດຍໃຊ້ການໂຕ້ຕອບ NETCONF & YANG ກັບສູນຄວບຄຸມ. ເມື່ອຕົວແທນທົດສອບຖືກສ້າງຂື້ນດ້ວຍວິທີນີ້, ບໍ່ມີການ synchronization ກັບ Control Center ແມ່ນຈໍາເປັນ.
ຮູບແບບຂອງ YANG ສໍາລັບຕົວແທນການທົດສອບແມ່ນໄດ້ອະທິບາຍຂ້າງລຸ່ມນີ້. ມັນໄດ້ຮັບເປັນຜົນຜະລິດຈາກຄໍາສັ່ງ
pyang -f ຕົ້ນໄມ້ netrounds-ncc.yang
ຮູບແບບ YANG ເຕັມແມ່ນໃຫ້ຢູ່ໃນ "ເອກະສານຊ້ອນທ້າຍ: ໂຄງສ້າງຕົ້ນໄມ້ຂອງຕົວແບບ YANG ເຕັມ" ໃນຫນ້າທີ 81, ເຊິ່ງຍັງມີນິທານທີ່ອະທິບາຍເຖິງສົນທິສັນຍາທີ່ໃຊ້ໃນເລື່ອງນີ້ ແລະຮູບແຕ້ມແບບຈໍາລອງ YANG ອື່ນໆໃນເອກະສານປະຈຸບັນ.

ພວກເຮົາດໍາເນີນການໃນຂັ້ນຕອນຕໍ່ໄປນີ້, ເຊິ່ງມີລາຍລະອຽດດັ່ງຕໍ່ໄປນີ້:

1. ໃນຕອນຕົ້ນ, ບັນຊີ Paragon Active Assurance “ສາທິດ” ບໍ່ມີຕົວແທນທົດສອບຢູ່ໃນສິນຄ້າຄົງຄັງຂອງມັນ.
2.  ຕົວແທນທົດສອບທີ່ເອີ້ນວ່າ "vta1" ຖືກສ້າງຂື້ນໂດຍໃຊ້ ncclient. ໃນນີ້ stage, ບໍ່ມີຕົວແທນການທົດສອບທີ່ແທ້ຈິງມີຢູ່ (ນັ້ນແມ່ນ, ມັນຍັງບໍ່ທັນໄດ້ເລີ່ມຕົ້ນ).
3. ຕົວແທນທົດສອບຖືກນຳໃຊ້ໃນ OpenStack. (ການ​ນໍາ​ໃຊ້​ຢູ່​ໃນ​ເວ​ທີ​ນັ້ນ​ແມ່ນ​ໄດ້​ຮັບ​ຄັດ​ເລືອກ​ທີ່​ນີ້​ເປັນ​ຄວາມ​ເປັນ​ໄປ​ໄດ້​ໃນ​ບັນ​ດາ​ອື່ນໆ​.)
4. ຕົວແທນທົດສອບເຊື່ອມຕໍ່ກັບບັນຊີສູນຄວບຄຸມ “ສາທິດ” ແລະຕອນນີ້ພ້ອມນຳໃຊ້ແລ້ວ.
   ຂັ້ນຕອນທີ 1: ໃນຕອນເລີ່ມຕົ້ນ, ບໍ່ມີຕົວແທນທົດສອບຢູ່ໃນບັນຊີ "ຕົວຢ່າງ". ເບິ່ງພາບໜ້າຈໍຂ້າງລຸ່ມນີ້ຈາກ Control Center GUI.ຂັ້ນ​ຕອນ​ທີ 2​: ຕົວ​ແທນ​ການ​ທົດ​ສອບ​ໄດ້​ຖືກ​ສ້າງ​ຕັ້ງ​ຂຶ້ນ​ໃນ​ສູນ​ຄວບ​ຄຸມ​ໂດຍ​ນໍາ​ໃຊ້ Python NETCONF client "ncclient​"​. ຂ້າງລຸ່ມນີ້ແມ່ນລະຫັດ ncclient ສໍາລັບການສ້າງຕົວແທນທົດສອບທີ່ມີການໂຕ້ຕອບທາງດ້ານຮ່າງກາຍທີ່ມີທີ່ຢູ່ DHCP:

ນຳເຂົ້າ argparse
ຈາກຜູ້ຈັດການນໍາເຂົ້າ ncclient
parser = argparse.ArgumentParser(ລາຍລະອຽດ='ທົດສອບການສ້າງຕົວແທນທົດສອບ')
parser.add_argument('–host', help='ຊື່ເຈົ້າພາບທີ່ພົບ ConfD', ຕ້ອງການ=ແທ້)
parser.add_argument('–port', help='ພອດເພື່ອເຊື່ອມຕໍ່ກັບ ConfD', ຕ້ອງການ=True)
parser.add_argument('–ຊື່ຜູ້ໃຊ້', help='ຊື່ຜູ້ໃຊ້ເພື່ອເຊື່ອມຕໍ່ກັບ ConfD', ຕ້ອງການ=ຄວາມຈິງ)
parser.add_argument('–password', help='Password to the ConfD account', require=True)
parser.add_argument('–netrounds-account', help='ຊື່ຫຍໍ້ບັນຊີ NCC', ຕ້ອງການ=ຄວາມຈິງ)
parser.add_argument('–test-agent-name', help='ຊື່ຕົວແທນທົດສອບ', require=True)
args = parser.parse_args()
ກັບ manager.connect(host=args.host, port=args.port, username=args.ຊື່ຜູ້ໃຊ້,
password=args.password, hostkey_verify=False) ເປັນ m:
# ສ້າງຕົວແທນທົດສອບໃນສູນຄວບຄຸມ
xml = “””

)ພິມ m.edit_config(target='running', config=xml)

ໝາຍເຫດ: ລະຫັດທີ່ນຳໜ້າດ້ວຍ manager.connect(…) ຖືກລະເວັ້ນຈາກ ex ຕໍ່ໄປample snippets ຂອງລະຫັດ.
ເຊີບເວີ NTP ຖືກຕັ້ງຄ່າໃນ eth0, ແລະ eth0 ຍັງເປັນສ່ວນຕິດຕໍ່ການຈັດການ (ນັ້ນກໍຄື, ການໂຕ້ຕອບທີ່ເຊື່ອມຕໍ່ກັບສູນຄວບຄຸມ).
ຄໍາຮ້ອງສະຫມັກຕົວແທນທົດສອບບໍ່ອະນຸຍາດໃຫ້ຕັ້ງຄ່າການໂຕ້ຕອບ. ດ້ວຍເຫດຜົນນີ້, ຕັ້ງແຕ່ຮຸ່ນ 2.34.0 ເປັນຕົ້ນໄປ, ມັນເປັນໄປໄດ້ທີ່ຈະຍົກເລີກການຕັ້ງຄ່າການໂຕ້ຕອບໃນ YANG schema. ດັ່ງນັ້ນ XML ທີ່ສອດຄ້ອງກັນແມ່ນງ່າຍດາຍຫຼາຍໃນກໍລະນີນີ້:ເມື່ອຕົວແທນທົດສອບໄດ້ຖືກສ້າງຂື້ນ, ມັນມີຢູ່ໃນຖານຂໍ້ມູນການຕັ້ງຄ່າແລະໃນສູນຄວບຄຸມ. ເບິ່ງພາບໜ້າຈໍດ້ານລຸ່ມຂອງສິນຄ້າຄົງຄັງຕົວແທນທົດສອບ, ສະແດງໃຫ້ເຫັນຕົວແທນທົດສອບ “vta1”:

ຂັ້ນ​ຕອນ​ທີ 3​: ມັນ​ເປັນ​ເວ​ລາ​ທີ່​ຈະ​ນໍາ​ໃຊ້​ຕົວ​ແທນ​ການ​ທົດ​ສອບ "vta1​" ໃນ OpenStack​.
ຕົວແທນທົດສອບຈະໃຊ້ຂໍ້ມູນຜູ້ໃຊ້ cloud-init ເພື່ອດຶງຂໍ້ມູນວິທີການເຊື່ອມຕໍ່ກັບສູນຄວບຄຸມ. ໂດຍສະເພາະ, ຂໍ້ຄວາມຂໍ້ມູນຜູ້ໃຊ້ file ມີເນື້ອໃນຕໍ່ໄປນີ້ (ສັງເກດວ່າເສັ້ນ #cloud-config ແລະ netrounds_test_agent ຕ້ອງມີຢູ່, ແລະແຖວທີ່ຍັງເຫຼືອຈະຕ້ອງຖືກຫຍໍ້ໜ້າ):

ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມ, ກະລຸນາເບິ່ງເອກະສານ ວິທີການຕິດຕັ້ງຕົວແທນທົດສອບ Virtual ໃນ OpenStack.
ເມື່ອຕົວແທນທົດສອບໄດ້ຖືກນຳໃຊ້ ແລະໄດ້ເຊື່ອມຕໍ່ກັບສູນຄວບຄຸມ, ການຕັ້ງຄ່າຈະຖືກຍູ້ຈາກສູນຄວບຄຸມໄປຫາຕົວແທນທົດສອບ.

ຂັ້ນ​ຕອນ​ທີ 4​: ຕົວ​ແທນ​ການ​ທົດ​ສອບ​ແມ່ນ​ອອນ​ໄລ​ນ​໌​ໃນ​ສູນ​ຄວບ​ຄຸມ​ແລະ​ໄດ້​ຮັບ​ການ​ຕັ້ງ​ຄ່າ​ຂອງ​ຕົນ​. ຕົວແທນທົດສອບແມ່ນກຽມພ້ອມສໍາລັບການນໍາໃຊ້ໃນການທົດສອບແລະການຕິດຕາມ. ເບິ່ງພາກສ່ວນເຫຼົ່ານີ້:

• “ເລີ່ມການທົດສອບ” ໃນໜ້າ 45
•  “ການ​ເລີ່ມ​ຕົ້ນ​ການ​ຕິດ​ຕາມ” ໃນ​ຫນ້າ 60

ລາຍຊື່ຕົວແທນທົດສອບຢູ່ໃນບັນຊີ Paragon Active Assurance ຂອງທ່ານ
ຂ້າງລຸ່ມນີ້ແມ່ນ example ncclient ລະຫັດ Python ສໍາລັບລາຍຊື່ຕົວແທນທົດສອບໃນບັນຊີ Paragon Active Assurance:

ການແລ່ນລະຫັດນີ້ໃຫ້ຜົນໄດ້ຮັບຄືດັ່ງລຸ່ມນີ້:

ການລຶບຕົວແທນທົດສອບ
ຫຼັງຈາກການທົດສອບສໍາເລັດແລ້ວ, ມັນອາດຈະມີຄວາມກ່ຽວຂ້ອງໃນບາງກໍລະນີທີ່ໃຊ້ໃນການລຶບຕົວແທນທົດສອບ.
ຂ້າງລຸ່ມນີ້ແມ່ນຕົວຢ່າງຂອງລະຫັດສະແດງໃຫ້ເຫັນວິທີການເຮັດສິ່ງນີ້ກັບ ncclient:

ການແຈ້ງເຕືອນ NETCONF
ຂ້າງລຸ່ມນີ້, ພວກເຮົາສະເຫນີ ex ງ່າຍດາຍample script ສໍາລັບຟັງການແຈ້ງເຕືອນ NETCONF ຂາເຂົ້າທັງຫມົດຈາກສູນຄວບຄຸມ. ການແຈ້ງເຕືອນເຫຼົ່ານີ້ຖືກສົ່ງໄປທຸກຄັ້ງທີ່ເຫດການບາງຢ່າງເກີດຂຶ້ນ, ເຊັ່ນ: ຕົວແທນທົດສອບຈະໄປອອຟໄລ ຫຼືການທົດສອບທີ່ລິເລີ່ມໂດຍຜູ້ໃຊ້ສຳເລັດແລ້ວ. ອີງໃສ່ຂໍ້ມູນທີ່ດໍາເນີນຢູ່ໃນການແຈ້ງເຕືອນ, ຜູ້ໃຊ້ສາມາດກໍານົດການປະຕິບັດການຕິດຕາມອັດຕະໂນມັດໃນວົງດົນຕີ.

ເມື່ອ script ຂ້າງເທິງຖືກປະຕິບັດ, ລູກຄ້າ NC ຈະນໍາສະເຫນີການແຈ້ງເຕືອນທີ່ໄດ້ຮັບໃນ XML ທີ່ມີໂຄງສ້າງ. ເບິ່ງ example output ຂ້າງລຸ່ມນີ້, ເຊິ່ງສະແດງໃຫ້ເຫັນຕົວແທນການທົດສອບທີ່ກໍາລັງຈະອອບໄລນ໌ໂດຍບໍ່ຄາດຄິດ.



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 ຜ່ານ NETCONF & YANG API ແລະສໍາລັບການດຶງເອົາລາຍການລາຍການທີ່ກໍານົດ.

ການສ້າງ TWAMP ແສງສະທ້ອນ

ການສ້າງ Y.1731 MEP

ການສ້າງຊ່ອງ IPTV

ການສ້າງເຈົ້າພາບ Ping

ການສ້າງບັນຊີ SIP

ດຶງເອົາລາຍການສິນຄ້າຄົງຄັງ
ຂ້າງລຸ່ມນີ້ແມ່ນລະຫັດ Python ສໍາລັບການດຶງເອົາລາຍການສິນຄ້າຄົງຄັງທັງຫມົດທີ່ກໍານົດໄວ້ໃນບັນຊີ. (ທຸກປະເພດຂອງລາຍການສິນຄ້າຄົງຄັງຖືກດຶງມາໃນຄັ້ງດຽວເພື່ອຫຼີກເວັ້ນການຊໍ້າຄືນບາງອັນໃນເອກະສານ. ຕາມທໍາມະຊາດ, ຊຸດຍ່ອຍຂອງລາຍການສິນຄ້າຄົງຄັງສາມາດດຶງມາໄດ້ໂດຍການປະໄວ້ບາງແຖວພາຍໃຕ້ບັນຊີຂ້າງລຸ່ມນີ້.)

ການແລ່ນລະຫັດນີ້ໃຫ້ຜົນໄດ້ຮັບຄືດັ່ງລຸ່ມນີ້:

Examples: ປຸກ

ແມ່ແບບປຸກແລະລາຍການທີ່ກ່ຽວຂ້ອງ (ຜູ້ຈັດການ SNMP, ລາຍຊື່ອີເມລ໌ປຸກ) ຖືກສ້າງແລະຈັດການໃນລັກສະນະທີ່ຄ້າຍຄືກັນກັບລາຍການສິນຄ້າຄົງຄັງ. ບົດນີ້ປະກອບດ້ວຍລະຫັດ XML ແລະ NETCONF ສໍາລັບການກໍານົດຫນ່ວຍງານດັ່ງກ່າວໃນ Paragon Active Assurance ຜ່ານ NETCONF & YANG API ແລະສໍາລັບການດຶງເອົາລາຍການລາຍການທີ່ກໍານົດ.
ລາຍຊື່ອີເມວປຸກ
ການສ້າງລາຍຊື່ອີເມວປຸກ

ດຶງລາຍຊື່ອີເມວປຸກທັງໝົດ

ຜູ້ຈັດການ SNMP
ການສ້າງຜູ້ຈັດການ SNMP

ດຶງຂໍ້ມູນຜູ້ຈັດການ SNMP ທັງໝົດ

ແມ່ແບບປຸກ
ການສ້າງແມ່ແບບປຸກ

ກຳລັງດຶງເອົາແມ່ແບບປຸກທັງໝົດ

Examples: SSH Keys

ທ່ານສາມາດເພີ່ມລະຫັດສາທາລະນະ SSH ໃຫ້ກັບຕົວແທນທົດສອບຜ່ານ NETCONF & YANG API. ການນໍາໃຊ້ລະຫັດສ່ວນຕົວທີ່ສອດຄ້ອງກັນຫຼັງຈາກນັ້ນທ່ານສາມາດເຂົ້າສູ່ລະບົບຕົວແທນທົດສອບຜ່ານ SSH.
ບັນຊີລາຍຊື່ເຕັມຂອງການດໍາເນີນງານທີ່ມີຢູ່ໃນກະແຈ SSH ມີດັ່ງນີ້:

• ເພີ່ມລະຫັດ SSH
• ແກ້ໄຂກະແຈ SSH
• ກວດເບິ່ງລະຫັດ SSH
• ລາຍຊື່ກະແຈ SSH
• ລຶບກະແຈ SSH.
  ຂ້າງລຸ່ມນີ້, ການປະຕິບັດການເພີ່ມ ແລະລຶບໄດ້ຖືກຍົກຕົວຢ່າງ.

ການລຶບກະແຈ SSH
ຖ້າທ່ານຕ້ອງການລຶບລະຫັດ SSH, ໃຊ້ຄໍາສັ່ງຕໍ່ໄປນີ້:

Examples: ການທົດສອບ

ມັນສົມມຸດຢູ່ທີ່ນີ້ວ່າຕົວແທນທົດສອບ (ຫຼາຍເທົ່າທີ່ຕ້ອງການສໍາລັບການທົດສອບ) ໄດ້ຖືກສ້າງຂື້ນໂດຍອີງຕາມພາກ "ການສ້າງແລະນໍາໃຊ້ຕົວແທນການທົດສອບໃຫມ່" ໃນຫນ້າ 17.
YANG Model Paths ສໍາລັບການທົດສອບ

ລາຍການ	ເສັ້ນທາງຕົວແບບ YANG: /accounts/account/tests…
ການທົດສອບ	/.
ການທົດສອບ [id]	/ ທົດສອບ
id	/test/id
ຊື່	/test/ຊື່
ສະຖານະ	/test/ສະຖານະ
ເວລາເລີ່ມຕົ້ນ	/test/start-time
ເວລາສິ້ນສຸດ	/test/end-time
ລາຍງານ-url	/test/report-url
ຂັ້ນຕອນ	/test/ຂັ້ນຕອນ
ຂັ້ນຕອນ[id]	/test/steps/ຂັ້ນຕອນ
ຊື່	/test/steps/step/ຊື່
id	/test/steps/step/id
ເວລາເລີ່ມຕົ້ນ	/test/steps/step/start-time
ເວລາສິ້ນສຸດ	/test/steps/step/end-time
ສະຖານະ	/test/steps/step/ສະຖານະ
ຂໍ້​ຄວາມ​ສະ​ຖາ​ນະ​ພາບ​	/test/steps/step/status-message
ແມ່ແບບ	/ ແມ່ແບບ
ແມ່ແບບ[ຊື່]	/templates/ແມ່ແບບ
ຊື່	/templates/template/name
ລາຍລະອຽດ	/templates/template/description
ຕົວກໍານົດການ	/templates/template/parameters
ພາລາມິເຕີ[key]	/templates/template/parameters/parameter
ກະແຈ	/templates/template/parameters/parameter/key
ປະເພດ	/templates/template/parameters/parameter/type

ເງື່ອນໄຂເບື້ອງຕົ້ນສໍາລັບການສອບເສັງ Orchestration

•  ເພື່ອເລີ່ມຕົ້ນການທົດສອບຜ່ານ NETCONF ໂດຍໃຊ້ລູກຄ້າ NC, ມັນຈໍາເປັນຕ້ອງສ້າງແບບທົດສອບທໍາອິດໂດຍໃຊ້ Control Center GUI ຕາມລາຍລະອຽດໃນການຊ່ວຍເຫຼືອໃນແອັບຯພາຍໃຕ້ "ການທົດສອບແລະການຕິດຕາມ" > "ການສ້າງແມ່ແບບ". ຊ່ອງຂໍ້ມູນທັງໝົດທີ່ລະບຸໄວ້ໃນແມ່ແບບນັ້ນເປັນ “ການປ້ອນແມ່ແບບ” ຈະຕ້ອງເປັນພາລາມິເຕີໃນ XML ເມື່ອຈັດວາງການເລີ່ມຕົ້ນຂອງແມ່ແບບທົດສອບ.
• ການທົດສອບແລ່ນຢູ່ໃນ Paragon Active Assurance ແມ່ນຖືວ່າເປັນ "ລັດ" ໃນສະພາບການຂອງ orchestration. ຂໍ້ມູນຂອງລັດແມ່ນຂໍ້ມູນທີ່ບໍ່ສາມາດຂຽນໄດ້ທີ່ບໍ່ໄດ້ຖືກເກັບໄວ້ໃນຖານຂໍ້ມູນການຕັ້ງຄ່າ, ກົງກັນຂ້າມກັບຂໍ້ມູນການຕັ້ງຄ່າທີ່ໄດ້ກ່າວມາໃນພາກ "Overview of Test Agent Orchestration” ໃນໜ້າ 17. ໂດຍພື້ນຖານແລ້ວ ອັນນີ້ໝາຍຄວາມວ່າ ການປ່ຽນແປງການທົດສອບ ຫຼືແມ່ແບບໃນ Control Center GUI ຈະບໍ່ເຮັດໃຫ້ເກີດບັນຫາທີ່ກ່ຽວຂ້ອງກັບການຊິງຄ໌ລະຫວ່າງສູນຄວບຄຸມ ແລະຖານຂໍ້ມູນການຕັ້ງຄ່າ.
• ເພື່ອ​ໄດ້​ຮັບ​ບົດ​ລາຍ​ງານ -URL ຢູ່ໃນບົດລາຍງານການທົດສອບ, ທ່ານຈໍາເປັນຕ້ອງໃຫ້ແນ່ໃຈວ່າສູນຄວບຄຸມ URL ຖືກຕັ້ງຄ່າຢ່າງຖືກຕ້ອງ. ນີ້ແມ່ນເຮັດຢູ່ໃນ file /opt/netrounds-confd/settings.py. ໂດຍຄ່າເລີ່ມຕົ້ນ, ຊື່ເຈົ້າພາບຂອງສູນຄວບຄຸມຈະຖືກດຶງມາໂດຍໃຊ້ socket.gethostname(): ເບິ່ງຂ້າງລຸ່ມນີ້. ຖ້ານີ້ບໍ່ໄດ້ຜົນທີ່ຖືກຕ້ອງ, ທ່ານຈໍາເປັນຕ້ອງຕັ້ງຊື່ເຈົ້າພາບ (ຫຼືທັງຫມົດ URL) ດ້ວຍຕົນເອງໃນນີ້ file.

# URL ຂອງ​ສູນ​ຄວບ​ຄຸມ​ໂດຍ​ບໍ່​ມີ​ການ​ຕັດ​ຕໍ່​ຫນ້າ​.
# ນີ້ແມ່ນສໍາລັບ exampນໍາ​ໃຊ້​ໃນ​ບົດ​ລາຍ​ງານ​ການ​ທົດ​ສອບurl.
HOSTNAME = socket.gethostname()
NETROUNDS_URL = 'https://%s' % HOSTNAME
ກຳລັງເລີ່ມການທົດສອບ
ດັ່ງທີ່ໄດ້ອະທິບາຍໄວ້ໃນພາກ “ການສ້າງ ແລະ ນຳໃຊ້ຕົວແທນທົດສອບໃໝ່” ໃນໜ້າທີ 17, ໃຫ້ແລ່ນຄຳສັ່ງ pang -f tree netrounds-ncc.yang
ຈາກໄດເລກະທໍລີ /opt/netrounds-confd/ ເພື່ອສົ່ງອອກຮູບແບບ YANG. ໃນຮູບແບບນີ້, RPC ສໍາລັບການເລີ່ມຕົ້ນການທົດສອບການນໍາໃຊ້ລູກຄ້າ NC ມີລັກສະນະດັ່ງຕໍ່ໄປນີ້:

ສໍາລັບຄໍາອະທິບາຍ, ເບິ່ງພາກ “ນິທານ” ໃນໜ້າ 81 ໃນເອກະສານຊ້ອນທ້າຍ.

ຂັ້ນຕອນຕໍ່ໄປນີ້ແມ່ນສະແດງໃຫ້ເຫັນຂ້າງລຸ່ມນີ້:

1. ຕົວແທນທົດສອບໄດ້ລົງທະບຽນເຂົ້າບັນຊີ Paragon Active Assurance, ແຕ່ຍັງບໍ່ທັນມີການທົດສອບເທື່ອ.
2. ພາລາມິເຕີການປ້ອນຂໍ້ມູນທີ່ຈໍາເປັນຖືກກໍານົດຢູ່ໃນແບບທົດສອບທີ່ຈະດໍາເນີນການ.
3.  ການທົດສອບ HTTP 60 ວິນາທີແມ່ນເລີ່ມຕົ້ນໂດຍໃຊ້ ncclient.

ຂັ້ນຕອນ 1: ໃນຕອນຕົ້ນ, ບໍ່ມີການທົດສອບໃດໆໄດ້ຖືກລິເລີ່ມໃນບັນຊີ Paragon Active Assurance. ເບິ່ງພາບໜ້າຈໍຂ້າງລຸ່ມນີ້ຈາກ Control Center GUI.
ຂັ້ນຕອນ 2: ແມ່ແບບທີ່ພວກເຮົາຈະໃຊ້ເພື່ອລິເລີ່ມການທົດສອບໃນ ex ນີ້ample ເປັນແບບທົດສອບ HTTP. ມັນ​ມີ​ສອງ​ຊ່ອງ​ຂໍ້​ມູນ​ທີ່​ບັງ​ຄັບ​ໃຊ້ (ລູກ​ຄ້າ​ແລະ​ URL) ເຊິ່ງພວກເຮົາໄດ້ລະບຸໄວ້ເປັນເຊັ່ນນັ້ນເມື່ອສ້າງແມ່ແບບໃນ Control Center GUI.

ພວກເຮົາຈະກໍານົດພາລາມິເຕີເຫຼົ່ານີ້ (ໃນບັນດາສິ່ງອື່ນໆ) ໃນການຕັ້ງຄ່າ XML ທີ່ຕິດຕໍ່ກັບຖານຂໍ້ມູນການຕັ້ງຄ່າໂດຍຜູ້ຈັດການ NETCONF ຂອງພວກເຮົາ (ncclient).
ຂັ້ນຕອນທີ 3: ການທົດສອບ HTTP ແມ່ນເລີ່ມຕົ້ນໂດຍໃຊ້ ncclient.
ຂ້າງລຸ່ມນີ້ແມ່ນ example ລະ​ຫັດ​ທີ່​ຂໍ້​ມູນ​ການ​ຕັ້ງ​ຄ່າ​ທີ່​ຈໍາ​ເປັນ​ແລະ​ຕົວ​ກໍາ​ນົດ​ການ​ແມ່ນ​ໄດ້​ລະ​ບຸ​ໄວ້​ສໍາ​ລັບ​ແມ່​ແບບ​ການ​ທົດ​ສອບ HTTP​. ອີງຕາມວິທີການສ້າງແມ່ແບບ, ລາຍລະອຽດຢູ່ທີ່ນີ້ອາດຈະແຕກຕ່າງກັນ.
ສໍາລັບແຕ່ລະຕົວກໍານົດການ, the ຄຸນລັກສະນະຕ້ອງໄດ້ຮັບການສະຫນອງ. ກຸນແຈແມ່ນຄືກັນກັບຕົວກໍານົດການ
ຊື່ຕົວແປໃນສູນຄວບຄຸມ. ທ່ານສາມາດກວດສອບຊື່ຕົວແປໄດ້ດັ່ງນີ້:

• ກົດ Tests ໃນແຖບດ້ານຂ້າງແລະເລືອກລໍາດັບການທົດສອບໃຫມ່.
• ກົດ My Templates.
• ຄລິກທີ່ລິ້ງແກ້ໄຂດ້ານລຸ່ມຂອງແມ່ແບບທີ່ສົນໃຈ.
• ຄລິກປຸ່ມແກ້ໄຂການປ້ອນຂໍ້ມູນຢູ່ໃນມຸມຂວາເທິງ.

ໃນ ex ຂອງພວກເຮົາample, ແລະໂດຍຄ່າເລີ່ມຕົ້ນ, ຊື່ຕົວແປແມ່ນເປັນຕົວພິມນ້ອຍຂອງຊື່ທີ່ສະແດງຢູ່ໃນສູນຄວບຄຸມ (“url"ທຽບກັບ"URL”, ແລະອື່ນໆ). ຢ່າງໃດກໍຕາມ, ໃນ Control Center GUI, ທ່ານສາມາດປ່ຽນຊື່ຕົວແປເປັນອັນໃດກໍໄດ້ທີ່ທ່ານຕ້ອງການ.
ນອກເໜືອໄປຈາກຄີ, ແຕ່ລະພາລາມິເຕີຕ້ອງມີປະເພດຂອງມັນລະບຸໄວ້: ຕົວຢ່າງampເລ, ສໍາລັບ URL.
ກະລຸນາສັງເກດວ່າທ່ານຈໍາເປັນຕ້ອງ review ຮູບ​ແບບ YANG ທີ່​ສົມ​ບູນ​ເພື່ອ​ໃຫ້​ໄດ້​ຮັບ​ຂໍ້​ມູນ​ຢ່າງ​ເຕັມ​ທີ່​ກ່ຽວ​ກັບ​ປະ​ເພດ​. ສໍາ​ລັບ​ຕົວ​ແທນ​ການ​ທົດ​ສອບ​ການ​ໂຕ້​ຕອບ​ປະ​ເພດ​ທີ່​ມີ​ໂຄງ​ປະ​ກອບ​ການ​ສະ​ລັບ​ສັບ​ຊ້ອນ​ຫຼາຍ​, ເປັນ​ຫຼັກ​ຖານ​ພາຍ​ໃຕ້​ການ​ ໃນລະຫັດຂ້າງລຸ່ມນີ້.

ດຽວນີ້ພວກເຮົາສາມາດແລ່ນສະຄຣິບໂດຍໃຊ້ ncclient. ສົມມຸດວ່າທັງໝົດແມ່ນຖືກຕ້ອງ, ການທົດສອບຈະຖືກລິເລີ່ມ ແລະການປະຕິບັດຂອງມັນສະແດງຢູ່ໃນສູນຄວບຄຸມ:ຖ້າການທົດສອບໄດ້ຖືກເລີ່ມຕົ້ນຢ່າງສໍາເລັດຜົນ, ສູນຄວບຄຸມຈະຕອບສະຫນອງດ້ວຍ ID ການທົດສອບ. ໃນນີ້ example, ID ການທົດສອບແມ່ນ 3:ID ການທົດສອບຍັງສາມາດພົບເຫັນຢູ່ໃນ URL ສໍາລັບການທົດສອບໃນ Control Center GUI. ໃນນີ້ example, ວ່າ URL ແມ່ນ https://host/demo/testing/3/.
ດຶງຜົນໄດ້ຮັບການທົດສອບ
ວິທີທີ່ກົງໄປກົງມາທີ່ສຸດໃນການດຶງຜົນການທົດສອບແມ່ນໂດຍການຊີ້ໄປທີ່ ID ການທົດສອບ.
ຂ້າງລຸ່ມນີ້ແມ່ນລະຫັດ Python ສໍາລັບການໄດ້ຮັບຜົນໄດ້ຮັບຈາກການທົດສອບ HTTP ຂ້າງເທິງດ້ວຍ ID = 3:
ກັບຜູ້ຈັດການ. ເຊື່ອມຕໍ່(host=args.host, port=args.port, username=args.username,password=args.password, hostkey_verify=False) ເປັນ m:

ຜົນຜະລິດຈະມີລັກສະນະຄ້າຍຄືນີ້:

ການສົ່ງອອກແລະການນໍາເຂົ້າແບບທົດສອບ
ແມ່ແບບທົດສອບສາມາດຖືກສົ່ງອອກໃນຮູບແບບ JSON ແລະນໍາເຂົ້າໃຫມ່ໃນຮູບແບບນັ້ນເຂົ້າໄປໃນສູນຄວບຄຸມ. ອັນນີ້ເປັນປະໂຫຍດຖ້າທ່ານຕ້ອງການໃຊ້ແມ່ແບບທົດສອບໃນການຕິດຕັ້ງ Control Center ທີ່ແຕກຕ່າງກັນ. (ການສ້າງແມ່ແບບເບື້ອງຕົ້ນແມ່ນຈັດການໄດ້ດີທີ່ສຸດໂດຍຜ່ານ Control Center GUI.
ຂ້າງລຸ່ມນີ້ແມ່ນລະຫັດສໍາລັບການປະຕິບັດການສົ່ງອອກແລະການນໍາເຂົ້າ.
ກຳລັງສົ່ງອອກແມ່ແບບທົດສອບ

# ເອົາ json config ຈາກການຕອບສະຫນອງ
root = ET.fromstring(response._raw)
json_config = ຮາກ[0].text
ພິມ json_config
ແມ່ແບບແມ່ນມີຢູ່ໃນວັດຖຸ json_config.
ກຳລັງນຳເຂົ້າແມ່ແບບທົດສອບ
A JSON config object ຖື templates ການທົດສອບສາມາດຖືກນໍາເຂົ້າໃຫມ່ເຂົ້າໄປໃນ Control Center ດັ່ງຕໍ່ໄປນີ້.

Examples: ຈໍພາບ

ພາກນີ້ສົມມຸດວ່າຕົວແທນທົດສອບ (ຫຼາຍເທົ່າທີ່ຕ້ອງການໂດຍຜູ້ຕິດຕາມ) ໄດ້ຖືກສ້າງຂື້ນໂດຍອີງຕາມພາກ "ການສ້າງແລະນໍາໃຊ້ຕົວແທນການທົດສອບໃຫມ່" ໃນຫນ້າ 17.
YANG Model Paths ສໍາລັບ Monitors

ລາຍການ	ເສັ້ນທາງຕົວແບບ YANG: /accounts/account/monitors…
ຕິດຕາມກວດກາ	/.
ຕິດຕາມກວດກາ [ຊື່]	/ ຕິດຕາມກວດກາ
ຊື່	/monitor/name
ລາຍລະອຽດ	/monitor/description
ໄດ້ເລີ່ມຕົ້ນ	/monitor/started
ແມ່ແບບ	/monitor/ແມ່ແບບ
ການຕັ້ງຄ່າໂມງປຸກ	/monitor/alarm-configs
ລາຍການ	YANG model path: /accounts/account/monitors/monitor/alarm-configs …
alarm-config[ຕົວລະບຸ]	/alarm-config
ຕົວລະບຸ	/alarm-config/identifier
ແມ່ແບບ	/alarm-config/ແມ່ແບບ
ອີເມວ	/alarm-config/email
snmp	/alarm-config/snmp
thr-es-critical	/alarm-config/thr-es-critical
thr-es-critical-ຈະແຈ້ງ	/alarm-config/thr-es-critical-clear
thr-es-major	/alarm-config/thr-es-major
thr-es-major-ຈະແຈ້ງ	/alarm-config/thr-es-major-clear
thr-es-minor	/alarm-config/thr-es-minor
thr-es-ເລັກນ້ອຍຈະແຈ້ງ	/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-ຄັ້ງດຽວ
snmp-trap-per-stream	/alarm-config/snmp-trap-per-stream
ລາຍການ	ເສັ້ນທາງຕົວແບບ YANG: /accounts/account/monitors…
ຕົວກໍານົດການ	/monitor/parameters
ລາຍການ	ເສັ້ນທາງຕົວແບບ YANG: /accounts/account/monitors/monitor/parameters …
ພາລາມິເຕີ[key]	/ ພາລາມິເຕີ
ກະແຈ	/parameter/key
(ປະເພດມູນຄ່າ)	/ ພາລາມິເຕີ
:(ຈຳນວນເຕັມ)	/ ພາລາມິເຕີ
ຈຳນວນເຕັມ	/parameter/integer
:(ລອຍ)	/ ພາລາມິເຕີ
ລອຍ	/parameter/float
:(ສະຕຣິງ)	/ ພາລາມິເຕີ
ລາຍການ	ເສັ້ນທາງຕົວແບບ YANG: /accounts/account/monitors/monitor/parameters …
ສາຍ	/parameter/string
:(test-agent-interfaces)	/ ພາລາມິເຕີ
test-agent-interfaces	/parameter/test-agent-interfaces
test-agent-interface[“1” ໃນໜ້າ 58	/parameter/test-agent-interfaces/
ບັນຊີ	/parameter/test-agent-interfaces/test-agent-interface/ບັນຊີ
ຕົວແທນທົດສອບ	/parameter/test-agent-interfaces/test-agent-interface/test-agent
ການໂຕ້ຕອບ	/parameter/test-agent-interfaces/test-agent-interface/ການໂຕ້ຕອບ
ລຸ້ນ ip	/parameter/test-agent-interfaces/test-agent-interface/ip-version
:(ທamp- ແສງສະທ້ອນ)	/ ພາລາມິເຕີ
twamp- ແສງສະທ້ອນ	/parameter/twamp- ແສງສະທ້ອນ
twamp-reflector [ຊື່​]	/parameter/twamp- ສະທ້ອນແສງ / twamp- ແສງສະທ້ອນ
ຊື່	/parameter/twamp- ສະທ້ອນແສງ / twamp-reflector / ຊື່​
:(y1731-meps)	/ ພາລາມິເຕີ
y1731-meps	/parameter/y1731-meps
y1731-mep[ຊື່]	/parameter/y1731-meps/y1731-mep
ຊື່	/parameter/y1731-meps/y1731-mep/ຊື່
:(ບັນຊີຊິບ)	/ ພາລາມິເຕີ
ບັນຊີ sip	/parameter/sip-accounts
sip-account[“2” ໃນໜ້າ 58]	/parameter/sip-accounts/sip-account
ບັນຊີ	/parameter/sip-accounts/sip-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-channels
iptv-channel[ຊື່]	/parameter/iptv-channels/iptv-channel
ຊື່	/parameter/iptv-channels/iptv-channel/ຊື່

1. ການໂຕ້ຕອບຕົວແທນທົດສອບບັນຊີ
2. account test-agent interface sip-address

ລາຍການ	ເສັ້ນທາງຕົວແບບ YANG: /accounts/account/monitors…
ສະຖານະ	/monitor/ສະຖານະ
15 ນາທີສຸດທ້າຍ	/monitor/status/last-15-ນາທີ
ສະຖານະ	/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 ຊົ່ວໂມງສຸດທ້າຍ	/monitor/status/last-24-hours
ສະຖານະ	/monitor/status/last-24-hours/status
ສະຖານະພາບ - ມູນຄ່າ	/monitor/status/last-24-hours/status-value
ແມ່ແບບ	/ ແມ່ແບບ
ແມ່ແບບ[ຊື່]	/templates/ແມ່ແບບ
ຊື່	/templates/template/name
ລາຍລະອຽດ	/templates/template/description
ຕົວກໍານົດການ	/templates/template/parameters
ພາລາມິເຕີ[key]	/templates/template/parameters/parameter
ກະແຈ	/templates/template/parameters/parameter/key
ປະເພດ	/templates/template/parameters/parameter/type

ເງື່ອນໄຂເບື້ອງຕົ້ນສໍາລັບ Monitor Orchestration
ກ່ອນທີ່ທ່ານຈະສາມາດເລີ່ມຈໍພາບຜ່ານ NETCONF ໂດຍໃຊ້ ncclient, ທ່ານຈໍາເປັນຕ້ອງສ້າງແມ່ແບບຈໍພາບໃນ Control Center GUI ດັ່ງທີ່ໄດ້ອະທິບາຍໄວ້ໃນການຊ່ວຍເຫຼືອໃນແອັບຯພາຍໃຕ້ "ການທົດສອບແລະການຕິດຕາມ" > "ການສ້າງແມ່ແບບ". ຊ່ອງຂໍ້ມູນທັງໝົດທີ່ລະບຸເປັນ “ການປ້ອນຂໍ້ມູນແມ່ແບບ” ໃນແມ່ແບບນັ້ນຈະຕ້ອງເປັນພາລາມິເຕີໃນ XML ເມື່ອຈັດວາງການເລີ່ມຕົ້ນຂອງແມ່ແບບ.
ໄດ້ຮັບພາລາມິເຕີການປ້ອນຂໍ້ມູນຈາກ Monitor Templates
ຂ້າງລຸ່ມນີ້, ສອງແມ່ແບບແມ່ນສະແດງໃຫ້ເຫັນ. ທໍາອິດແມ່ນສໍາລັບການກວດສອບ UDP ລະຫວ່າງສອງຕົວຕິດຕໍ່ຕົວແທນທົດສອບ, ແລະທີສອງແມ່ນສໍາລັບ HTTP ໂດຍໃຊ້ການໂຕ້ຕອບຕົວແທນທົດສອບດຽວ.
ເພື່ອຊອກຫາຕົວກໍານົດການປ້ອນຂໍ້ມູນຂອງແມ່ແບບ, ໃຫ້ຄລິກໃສ່ປ່ອງທີ່ເປັນຕົວແທນຂອງແມ່ແບບ. ສໍາລັບແມ່ແບບ HTTP, ຕົວກໍານົດການອາດຈະຄ້າຍຄືນີ້:

ພວກເຮົາຈໍາເປັນຕ້ອງກໍານົດຕົວກໍານົດການເຫຼົ່ານີ້ໃນຂັ້ນຕອນຕໍ່ໄປໃນເວລາທີ່ເລີ່ມຕົ້ນຈໍພາບ.
ກຳລັງເລີ່ມຈໍພາບ
ການນໍາໃຊ້ຕົວແທນການທົດສອບທີ່ພວກເຮົາກໍານົດແລະນໍາໃຊ້ໃນພາກ "ການສ້າງແລະນໍາໃຊ້ຕົວແທນການທົດສອບໃຫມ່" ໃນຫນ້າ 17, ພວກເຮົາສາມາດເລີ່ມຕົ້ນການຕິດຕາມກວດກາຈາກແມ່ແບບ "HTTP" ດັ່ງທີ່ສະແດງຂ້າງລຸ່ມນີ້.
ສໍາລັບແຕ່ລະຕົວກໍານົດການ, ໄດ້ ຄຸນລັກສະນະຕ້ອງໄດ້ຮັບການສະຫນອງ. ປຸ່ມແມ່ນຄືກັນກັບຊື່ຕົວແປຂອງພາຣາມິເຕີໃນສູນຄວບຄຸມ. ທ່ານ​ສາ​ມາດ​ກວດ​ສອບ​ຊື່​ຕົວ​ປ່ຽນ​ແປງ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

• ກົດ Monitoring ໃນແຖບດ້ານຂ້າງ ແລະເລືອກ New Monitor.
• ກົດ My Templates.
• ຄລິກທີ່ລິ້ງແກ້ໄຂດ້ານລຸ່ມຂອງແມ່ແບບທີ່ສົນໃຈ.
• ຄລິກປຸ່ມແກ້ໄຂການປ້ອນຂໍ້ມູນຢູ່ໃນມຸມຂວາເທິງ.

ໃນ ex ຂອງພວກເຮົາample, ແລະໂດຍຄ່າເລີ່ມຕົ້ນ, ຊື່ຕົວແປແມ່ນເປັນຕົວພິມນ້ອຍຂອງຊື່ທີ່ສະແດງຢູ່ໃນສູນຄວບຄຸມ (“url"ທຽບກັບ"URL”, ແລະອື່ນໆ). ຢ່າງໃດກໍຕາມ, ໃນ Control Center GUI, ທ່ານສາມາດປ່ຽນຊື່ຕົວແປເປັນອັນໃດກໍໄດ້ທີ່ທ່ານຕ້ອງການ.
ນອກເໜືອໄປຈາກຄີ, ແຕ່ລະພາລາມິເຕີຕ້ອງມີປະເພດຂອງມັນລະບຸໄວ້: ຕົວຢ່າງampເລ, ສໍາລັບ URL. ກະລຸນາຮັບຊາບວ່າຂໍ້ມູນເຕັມກ່ຽວກັບປະເພດພາລາມິເຕີແມ່ນພົບເຫັນຢູ່ໃນຕົວແບບ YANG. ສໍາລັບການໂຕ້ຕອບຕົວແທນທົດສອບປະເພດມີໂຄງສ້າງທີ່ສັບສົນຫຼາຍ, ດັ່ງທີ່ສະແດງຢູ່ໃນລະຫັດຂ້າງລຸ່ມນີ້.
ໃນ exampຕໍ່ໄປ, ບໍ່ມີສັນຍານເຕືອນໃດໆທີ່ກ່ຽວຂ້ອງກັບຈໍພາບ. ຕົວຢ່າງamples ກ່ຽວຂ້ອງກັບການປຸກ, ໄປທີ່ພາກ “ການເລີ່ມຕົ້ນຈໍດ້ວຍໂມງປຸກ” ໃນຫນ້າ 62.

ກຳລັງເລີ່ມຈໍພາບດ້ວຍໂມງປຸກ
ເພື່ອເຊື່ອມໂຍງໂມງປຸກກັບຈໍພາບ, ທ່ານສາມາດຊີ້ໄປຫາແມ່ແບບປຸກທີ່ໄດ້ກໍານົດໄວ້, ຫຼືທ່ານສາມາດສະຫນອງການຕັ້ງຄ່າປຸກທັງຫມົດໃນເວລາສ້າງຈໍສະແດງຜົນ. ພວກເຮົາຈະໃຫ້ຫນຶ່ງ example ຂອງແຕ່ລະວິທີການຂ້າງລຸ່ມນີ້.
ການ​ຕັ້ງ​ຄ່າ​ການ​ຕິດ​ຕາມ​ປຸກ​ໂດຍ​ການ​ຊີ້​ໄປ​ທີ່​ແມ່​ແບບ​ການ​ປຸກ​
ເພື່ອໃຊ້ແມ່ແບບປຸກ, ທ່ານຕ້ອງຮູ້ ID ຂອງມັນ. ເພື່ອເຮັດສິ່ງນີ້, ທໍາອິດໃຫ້ດຶງເອົາແມ່ແບບປຸກທັງຫມົດຂອງທ່ານທີ່ໄດ້ອະທິບາຍໄວ້ໃນພາກ "ການດຶງເອົາແມ່ແບບປຸກທັງຫມົດ" ໃນຫນ້າ 39 ແລະສັງເກດຊື່ຂອງແມ່ແບບທີ່ກ່ຽວຂ້ອງ. ຈາກນັ້ນທ່ານສາມາດອ້າງອີງເຖິງແມ່ແບບນັ້ນດັ່ງນີ້:

ການຕັ້ງຄ່າ Monitor Alarm ໂດຍການຕັ້ງຄ່າມັນ Directly
ອີກທາງເລືອກ, ທ່ານສາມາດຕັ້ງຄ່າປຸກສໍາລັບຈໍສະແດງຜົນໂດຍການສະຫນອງການຕັ້ງຄ່າທັງຫມົດຂອງມັນໃນເວລາສ້າງຈໍພາບ, ໂດຍບໍ່ມີການອ້າງອີງເຖິງແມ່ແບບປຸກ. ນີ້ແມ່ນເຮັດໄດ້ດັ່ງທີ່ສະແດງຢູ່ໃນຕົວຢ່າງຕໍ່ໄປນີ້ampເລ.

ກຳລັງດຶງຕົວຕິດຕາມການແລ່ນ
ເພື່ອດຶງເອົາຈໍສະແດງຜົນທັງໝົດທີ່ກຳລັງດຳເນີນການຢູ່, ໃຫ້ແລ່ນສະຄຣິບນີ້:
ກັບຜູ້ຈັດການ. connect(host=args.host, port=args.port, username=args. ຊື່ຜູ້ໃຊ້, password=args.password, hostkey_verify=False) ເປັນ m:

ຜົນ​ໄດ້​ຮັບ​ແມ່ນ​ບັນ​ຊີ​ລາຍ​ການ​ຂອງ​ການ​ຕິດ​ຕາມ​ທັງ​ຫມົດ​ທີ່​ມີ​ຢູ່​ຂ້າງ​ລຸ່ມ​ນີ້​:

ກຳລັງດຶງຂໍ້ມູນສະຖານະ SLA ສຳລັບຈໍສະແດງຜົນ
ນີ້ແມ່ນວິທີການດຶງສະຖານະການ SLA ສໍາລັບຈໍສະແດງຜົນ. ໃນນີ້ exampດັ່ງນັ້ນ, ພວກເຮົາກໍາລັງດຶງຂໍ້ມູນສະຖານະພາບ SLA ສໍາລັບຈໍສະແດງຜົນ "ຄຸນະພາບເຄືອຂ່າຍ" ສໍາລັບສາມຊ່ວງເວລາ: 15 ນາທີສຸດທ້າຍ, ຊົ່ວໂມງສຸດທ້າຍ, ແລະ 24 ຊົ່ວໂມງສຸດທ້າຍ.

ຜົນຜະລິດຈະມີລັກສະນະຄ້າຍຄືນີ້:

ການແຈ້ງເຕືອນ NETCONF
ການແຈ້ງເຕືອນ NETCONF ສໍາລັບຈໍສະແດງຜົນຖືກກະຕຸ້ນໂດຍການລະເມີດ SLA. ສິ່ງເຫຼົ່ານີ້ເກີດຂຶ້ນເມື່ອ SLA ສໍາລັບຈໍສະແດງຜົນຫຼຸດລົງຕໍ່າກວ່າເກນ SLA ("ດີ" ຫຼື "ຍອມຮັບໄດ້") ພາຍໃນເວລາທີ່ກໍານົດໄວ້, ໂດຍຄ່າເລີ່ມຕົ້ນຂອງ 15 ນາທີສຸດທ້າຍ. ມັນຄວນຈະສັງເກດວ່າການແຈ້ງເຕືອນການລະເມີດ SLA ແມ່ນໄວທີ່ຈະປາກົດຫຼັງຈາກການບໍລິການໄດ້ຮັບຜົນກະທົບຈາກບັນຫາ, ໃນຂະນະທີ່ສະຖານະ SLA ຈະກັບຄືນໄປເປັນ "ດີ" ຫຼັງຈາກ 15 ນາທີເທົ່ານັ້ນ, ແລະຖ້າບໍ່ມີການລະເມີດອີກຕໍ່ໄປ.
ປ່ອງຢ້ຽມເວລາສາມາດປ່ຽນແປງໄດ້ໂດຍການແກ້ໄຂການຕັ້ງຄ່າ SLA_STATUS_WINDOW (ຄ່າເປັນວິນາທີ) ໃນ /etc/netrounds/netrounds.conf.
ການສົ່ງອອກແລະການນໍາເຂົ້າແມ່ແບບ Monitor
ນີ້ແມ່ນເຮັດໃນແບບດຽວກັນກັບແມ່ແບບການທົດສອບ; ປຽບທຽບພາກສ່ວນ “ການສົ່ງອອກ ແລະ ນຳເຂົ້າແມ່ແບບທົດສອບ” ໃນໜ້າ 52. ຂໍ້ມູນຫຍໍ້ຂອງລະຫັດຂ້າງລຸ່ມນີ້ສະແດງໃຫ້ເຫັນວິທີການສົ່ງອອກ ແລະນຳເຂົ້າແມ່ແບບສຳລັບຈໍພາບ.
ກຳລັງສົ່ງອອກແມ່ແບບ Monitor

ກຳລັງນຳເຂົ້າແມ່ແບບ Monitor

ການນໍາໃຊ້ Tags

Tags ກໍານົດໄວ້ໃນ Paragon Active Assurance ສາມາດຖືກນໍາໃຊ້ກັບ:

• ຕິດຕາມກວດກາ
• ຕິດຕາມແມ່ແບບ
• ຕົວແທນທົດສອບ
• TWAMP ເຄື່ອງສະທ້ອນແສງ
• Ping ເຈົ້າພາບ.
  ຕົວຢ່າງample, ເຈົ້າສາມາດ tag ຈໍພາບທີ່ມີອັນດຽວກັນ tag ເປັນຊຸດຍ່ອຍຂອງ Test Agents ທີ່ຈະແລ່ນຈໍພາບ. ຄຸນນະສົມບັດນີ້ແມ່ນເປັນປະໂຫຍດໂດຍສະເພາະຖ້າຫາກວ່າທ່ານມີຈໍານວນຂະຫນາດໃຫຍ່ຂອງຕິດຕາມກວດກາແລະແມ່ແບບທີ່ກໍານົດໄວ້.

ຖ້າທ່ານໄດ້ຕັ້ງການປຸກກັບດັກ SNMP ສໍາລັບຈໍພາບ, ຫຼັງຈາກນັ້ນກັບດັກ SNMP ຈະຖືກມອບຫມາຍຄືກັນ. tags ເປັນຈໍພາບ, ຖ້າມີ.
ການສ້າງ Tags
ຂ້າງລຸ່ມນີ້ພວກເຮົາສະແດງໃຫ້ເຫັນວິທີການສ້າງ a tag ດ້ວຍຊື່ ແລະສີຕາມທີ່ກຳນົດໂດຍ XMLtag> ໂຄງສ້າງຍ່ອຍ.

ການມອບໝາຍ ກ Tag
ມອບໝາຍ ກ tag ກັບຊັບພະຍາກອນ, ທ່ານເພີ່ມມັນເປັນໃຫມ່tag> ອົງປະກອບພາຍໃຕ້tags> ອົງປະກອບຂອງຊັບພະຍາກອນນັ້ນ.
ນີ້ແມ່ນວິທີການມອບຫມາຍ a tag ກັບຕົວແທນທົດສອບ:

ມອບໝາຍ ກ tag ກັບ TWAMP ເຄື່ອງສະທ້ອນແສງ, ເຮັດດັ່ງຕໍ່ໄປນີ້:

ການມອບໝາຍ ກ tag ຕໍ່ກັບຈໍສະແດງຜົນໄດ້ຖືກປະຕິບັດເຊັ່ນດຽວກັນ:

ອີກທາງເລືອກ, ທ່ານສາມາດມອບຫມາຍທີ່ມີຢູ່ແລ້ວ tag ກັບປະເພດຊັບພະຍາກອນເຫຼົ່ານີ້ໃນເວລາສ້າງຊັບພະຍາກອນ, ໂດຍລວມທັງtags> ອົງປະກອບທີ່ປະກອບດ້ວຍ tag ໃນຄໍາຖາມ.
ການປັບປຸງ ກ Tag
ການປັບປຸງທີ່ມີຢູ່ແລ້ວ tag ມີຄຸນລັກສະນະໃຫມ່ແມ່ນຄ້າຍຄືກັນກັບການສ້າງ a tag:

ຍົກເລີກການມອບໝາຍ ກ Tag
ເພື່ອຍົກເລີກການມອບໝາຍ ກ tag ຈາກຊັບພະຍາກອນ, ເພີ່ມຄຸນລັກສະນະ nc:operation=”delete” ໃສ່tag> ອົງປະກອບທີ່ເປັນຂອງຊັບພະຍາກອນ. ຂ້າງລຸ່ມນີ້, ພວກເຮົາຍົກເລີກການມອບຫມາຍ a tag ຈາກຈໍພາບ.

ການລຶບ ກ Tag
ເພື່ອລຶບ a tag ທັງຫມົດຈາກສູນຄວບຄຸມ, attribute nc:operation=”delete” ຖືກໃຊ້ອີກຄັ້ງ, ແຕ່ເວລານີ້ໃຊ້ກັບ tag ຕົວຂອງມັນເອງ, ກໍານົດພາຍໃຕ້ .

ການແກ້ໄຂບັນຫາ

ບັນຫາ: Orchestrator ແລະ Paragon Active Assurance Out of Sync
Orchestrator ແລະ Paragon Active Assurance ສາມາດຈົບລົງຈາກການ sync ສໍາລັບ exampຖ້າ​ຫາກ​ວ່າ​ການ​ປ່ຽນ​ແປງ​ການ​ຕັ້ງ​ຄ່າ​ໄດ້​ຖືກ​ເຮັດ​ໃຫ້​ຢູ່​ໃນ Control Center GUI​, ຫຼື​ຖ້າ​ຫາກ​ວ່າ​ການ​ນໍາ​ໃຊ້​ການ​ຕັ້ງ​ຄ່າ​ບໍ່​ສໍາ​ເລັດ​ແລະ rolling ກັບ​ຄືນ​ໄປ​ບ່ອນ​ທີ່​ຜ່ານ​ມາ​ບໍ່​ສໍາ​ເລັດ​.
ໃນກໍລະນີຂອງການ rollback ລົ້ມເຫລວ, ເຄື່ອງແມ່ຂ່າຍ NETCONF ຈະບໍ່ຍອມຮັບການປ່ຽນແປງການຕັ້ງຄ່າອີກຕໍ່ໄປ; ມັນ​ຈະ​ຕອບ​ກັບ​ຂໍ້​ຄວາມ​ຜິດ​ພາດ​ທີ່​ລະ​ບຸ​ວ່າ​ການ​ຕັ້ງ​ຄ່າ​ໄດ້​ຖືກ​ລັອກ​ຈົນ​ກ​່​ວາ​ຈະ​ກັບ​ຄືນ​ໄປ​ບ່ອນ sync ໄດ້​. ເພື່ອກັບຄືນໃນ sync ແລະປົດລັອກການປ່ຽນແປງການຕັ້ງຄ່າ, ທ່ານຈໍາເປັນຕ້ອງໄດ້ດໍາເນີນການຄໍາສັ່ງ rpc sync-from-ncc ທີ່ synchronizes ການຕັ້ງຄ່າທັງຫມົດຈາກ Control Center ກັບຖານຂໍ້ມູນການຕັ້ງຄ່າ.
ໝາຍເຫດ: ໄດ້ confd@netrounds.com ຜູ້​ໃຊ້ (ຫຼື​ອັນ​ໃດ​ກໍ​ຕາມ​ທີ່​ໄດ້​ຮັບ​ການ​ຕັ້ງ​ຄ່າ​) ຈະ​ຕ້ອງ​ມີ​ສິດ​ທິ​ພິ​ເສດ superuser ສໍາ​ລັບ​ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ທີ່​ຈະ​ຊິງ​ໄດ້​ສໍາ​ເລັດ​ຜົນ​. ນີ້ສາມາດເຮັດໄດ້ດ້ວຍຄໍາສັ່ງ ncc user-update confd@netrounds.com –is-superuser ຖ້າຜູ້ໃຊ້ບໍ່ແມ່ນ superuser, ການເຕືອນໄພຈະປາກົດຂຶ້ນວ່າບໍ່ແມ່ນທຸກສິ່ງທຸກຢ່າງສາມາດຖືກ synced, ແຕ່ວ່າທັງຫມົດທີ່ສາມາດໄດ້ຮັບການຈັດການ.
ໝາຍເຫດ: ຖ້າວົງດົນຕີຂອງທ່ານເກັບຮັກສາການຕັ້ງຄ່າ, ທ່ານຈະຕ້ອງ synchronize ຄືນໃໝ່ເຊັ່ນດຽວກັນ ເນື່ອງຈາກການຕັ້ງຄ່າທີ່ຮ້ອງຂໍ (ການຕັ້ງຄ່າທີ່ນັກດົນຕີຄາດວ່າສູນຄວບຄຸມຈະມີ) ຈະບໍ່ຖືກນຳໃຊ້.
ບັນຫາ: ການຊິ້ງຂໍ້ມູນເບື້ອງຕົ້ນ (sync-from-ncc) ລົ້ມເຫລວເນື່ອງຈາກຊັບພະຍາກອນທີ່ບໍ່ຮອງຮັບ
ຖ້າທ່ານພະຍາຍາມດໍາເນີນການ rpc sync-from-ncc ໃນບັນຊີທີ່ມີການຕັ້ງຄ່າຂອງມັນທີ່ສ້າງຂຶ້ນໃນ Control Center GUI, ທ່ານອາດຈະມີບັນຫາຖ້າບັນຊີມີຊັບພະຍາກອນທີ່ບໍ່ສະຫນັບສະຫນູນ. ມັນແນະນໍາໃຫ້ທ່ານເລີ່ມຕົ້ນດ້ວຍບັນຊີເປົ່າແລະເຮັດການຕັ້ງຄ່າທັງຫມົດຂອງມັນຜ່ານ NETCONF. ຖ້າບໍ່ດັ່ງນັ້ນ, ຖ້າທ່ານພົບບັນຫາຂັດແຍ້ງກ່ຽວກັບຊັບພະຍາກອນ, ທ່ານຈະຕ້ອງເອົາຊັບພະຍາກອນທີ່ຂັດແຍ້ງອອກຈາກບັນຊີ.
ບັນຫາ: ຄໍາສັ່ງ NETCONF ລົ້ມເຫລວກັບ ncclient.operations.rpc.RPCError: ແອັບພລິເຄຊັນການສື່ສານລົ້ມເຫລວ
ເຊີບເວີ NETCONF ບໍ່ຟື້ນຟູການເຊື່ອມຕໍ່ກັບເຊີບເວີຂອງສູນຄວບຄຸມໂດຍອັດຕະໂນມັດ ຖ້າສູນຄວບຄຸມຖືກຣີສະຕາດ. ເພື່ອຟື້ນຟູການເຊື່ອມຕໍ່ກັບ Control Center, restart the NETCONF process: sudo systemctl restart netrounds-confd

ຫມາຍເຫດກ່ຽວກັບຄໍາຮ້ອງສະຫມັກຕົວແທນທົດສອບແລະເຄື່ອງໃຊ້ຕົວແທນທົດສອບ

ທົດສອບຄໍາຮ້ອງສະຫມັກຕົວແທນໃນ ConfD
ໃນ​ບັນ​ດາ​ຕົວ​ແທນ​ການ​ທົດ​ສອບ, ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ (ໃຫມ່​) ຕົວ​ແທນ​ທົດ​ສອບ​ເຮັດ​ວຽກ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​ເລັກ​ນ້ອຍ​ຈາກ​ຕົວ​ແທນ​ການ​ທົດ​ສອບ (ເກົ່າ​)​.
ຄໍາຮ້ອງສະຫມັກຕົວແທນທົດສອບບໍ່ສະຫນັບສະຫນູນການຕັ້ງຄ່າສ່ວນຕິດຕໍ່. ດັ່ງນັ້ນ, schema YANG ອະນຸຍາດໃຫ້ກໍານົດການຕັ້ງຄ່າການໂຕ້ຕອບທີ່ຫວ່າງເປົ່າສໍາລັບຕົວແທນທົດສອບດັ່ງກ່າວ. ເບິ່ງ “ຂໍ້ນີ້” ໃນໜ້າ 23 ​​ສຳລັບຕົວຢ່າງampເລ.
ເມື່ອ synchronizing ຖານຂໍ້ມູນ ConfD ກັບ Control Center ໂດຍໃຊ້ຄໍາສັ່ງ sync-from-ncc, ທ່ານຕ້ອງການການຕັ້ງຄ່າສ່ວນຕິດຕໍ່ທີ່ຫວ່າງເປົ່າແລະບໍ່ຖືກຂຽນທັບກັບສິ່ງທີ່ພົບໃນ Control Center. ດັ່ງນັ້ນ, ທ່ານຈໍາເປັນຕ້ອງໃຊ້ທຸງພິເສດ -without_interface_config ກັບຄໍາສັ່ງນັ້ນໃນເວລາທີ່ເຮັດວຽກກັບຄໍາຮ້ອງສະຫມັກຕົວແທນທົດສອບ.
ການຕັ້ງຄ່າການໂຕ້ຕອບຫວ່າງເປົ່າສໍາລັບເຄື່ອງໃຊ້ຕົວແທນທົດສອບ
ດັ່ງທີ່ໄດ້ກ່າວໄວ້ຂ້າງເທິງ, Test Agent Application ບໍ່ຮອງຮັບການຕັ້ງຄ່າການໂຕ້ຕອບ, ແລະເພາະສະນັ້ນຈຶ່ງສາມາດຍົກເລີກການໂຕ້ຕອບໃນ YANG schema.
ແຕ່ກໍຍັງມີກໍລະນີການນຳໃຊ້ທີ່ທ່ານອາດຈະຕ້ອງການຍົກເລີກການຕັ້ງຄ່າການໂຕ້ຕອບຈາກ Test Agent Appliance. ອະດີດampນີ້ອາດຈະເປັນສະຖານະການ orchestration ບ່ອນທີ່ທ່ານກໍາລັງ spinning ຕົວແທນການທົດສອບໂດຍໃຊ້ cloud-init, ແລະທ່ານຕ້ອງການການຕັ້ງຄ່າການໂຕ້ຕອບຈາກບ່ອນນັ້ນ, ແທນທີ່ຈະໃຫ້ ConfD ຂຽນທັບມັນຍ້ອນວ່າຕົວແທນທົດສອບມາຮອດອອນໄລນ໌.
YANG Schema ການປ່ຽນແປງກ່ຽວກັບການໂຕ້ຕອບທີ່ບໍ່ໄດ້ກໍານົດ
ເນື່ອງຈາກການຕັ້ງຄ່າອິນເຕີເຟດຫວ່າງເປົ່າໄດ້ຖືກອະນຸຍາດແລ້ວ (ຕັ້ງແຕ່ເວີຊັນ 2.34.0 ເປັນຕົ້ນໄປ), ມັນເປັນໄປໄດ້ທີ່ຈະລະບຸຊື່ສ່ວນຕິດຕໍ່ໃດນຶ່ງທີ່ເປັນຂໍ້ມູນໃສ່ໃນໜ້າວຽກທີ່ເຮັດວຽກເປັນສ່ວນໜຶ່ງຂອງການທົດສອບ ຫຼືຈໍພາບ.
ນີ້ແມ່ນຈໍາເປັນເພື່ອສາມາດນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກຕົວແທນການທົດສອບ, ເນື່ອງຈາກວ່າສໍາລັບການເຫຼົ່ານີ້ບໍ່ມີຊື່ການໂຕ້ຕອບແມ່ນຖືກກໍານົດໄວ້ໃນ ConfD. ຢ່າງໃດກໍຕາມ, ໃຫ້ສັງເກດວ່ານີ້ຍັງຫມາຍຄວາມວ່າທ່ານສາມາດແລ່ນເຂົ້າໄປໃນບັນຫາຖ້າຫາກວ່າໂດຍບັງເອີນທ່ານ configure ການທົດສອບຫຼືຕິດຕາມກວດກາການນໍາໃຊ້ການໂຕ້ຕອບທີ່ບໍ່ມີທີ່ມີຢູ່ແລ້ວ. ດັ່ງນັ້ນກະລຸນາມີສະຕິໃນເລື່ອງນີ້.
ຂໍ້ຈໍາກັດໃນເວລາທີ່ລົງທະບຽນຕົວແທນການທົດສອບທີ່ສ້າງຂຶ້ນໃນ ConfD
ເມື່ອສ້າງຕົວແທນທົດສອບຜ່ານ REST ຫຼື NETCONF/YANG API, ພວກເຮົາບໍ່ສາມາດຮູ້ໄດ້ລ່ວງໜ້າວ່າມັນແມ່ນປະເພດໃດ: Test Agent Appliance ຫຼື Test Agent Application. ນີ້ຈະກາຍເປັນທີ່ຊັດເຈນພຽງແຕ່ຫຼັງຈາກຕົວແທນການທົດສອບໄດ້ລົງທະບຽນ.
ເມື່ອຕົວແທນທົດສອບໄດ້ຖືກລົງທະບຽນແລະກາຍເປັນຫນຶ່ງໃນປະເພດສີມັງເຫຼົ່ານີ້, ທ່ານບໍ່ໄດ້ຮັບອະນຸຍາດໃຫ້ລົງທະບຽນໃຫມ່ເປັນປະເພດຂອງຕົວແທນທົດສອບ. ນີ້ຫມາຍຄວາມວ່າທ່ານບໍ່ໄດ້ຮັບອະນຸຍາດໃຫ້ລົງທະບຽນມັນເປັນເຄື່ອງໃຊ້ຕົວແທນທົດສອບ, ຫຼັງຈາກນັ້ນລົງທະບຽນໃຫມ່ເປັນຄໍາຮ້ອງສະຫມັກຕົວແທນທົດສອບ, ຫຼືໃນທາງກັບກັນ. ຖ້າທ່ານຕ້ອງການຕົວແທນທົດສອບຂອງປະເພດທີ່ແຕກຕ່າງກັນ, ທ່ານຈະຕ້ອງສ້າງຕົວແທນທົດສອບໃຫມ່.

ເອກະສານຊ້ອນທ້າຍ: ໂຄງສ້າງຕົ້ນໄມ້ຂອງ Full YANG Model

ໃນເອກະສານຊ້ອນທ້າຍນີ້, ພາກ “ນິທານ” ໃນໜ້າທີ 81 ອະທິບາຍ syntax ຂອງໂຄງສ້າງຕົ້ນໄມ້ແບບ YANG ທີ່ສ້າງຂຶ້ນດ້ວຍຄຳສັ່ງ pyang -f tree.
ພາກສ່ວນ “ໂຄງສ້າງຕົ້ນໄມ້ຕົວແບບ YANG” ໃນໜ້າທີ 82 ໃຫ້ຜົນໄດ້ຮັບຈາກຄຳສັ່ງນັ້ນທີ່ໃຊ້ກັບ netrounds-ncc.yang. ບາງສ່ວນຂອງຜົນຜະລິດນີ້ຖືກຜະລິດຢູ່ບ່ອນອື່ນໃນເອກະສານ.
ນິທານ

ໂຄງສ້າງຕົ້ນໄມ້ແບບ YANG

Juniper Networks, ໂລໂກ້ Juniper Networks, Juniper, ແລະ Junos ແມ່ນເຄື່ອງໝາຍການຄ້າທີ່ຈົດທະບຽນຂອງ Juniper Networks, Inc. ໃນສະຫະລັດ ແລະປະເທດອື່ນໆ. ເຄື່ອງໝາຍການຄ້າອື່ນໆທັງໝົດ, ເຄື່ອງໝາຍການບໍລິການ, ເຄື່ອງໝາຍຈົດທະບຽນ ຫຼືເຄື່ອງໝາຍການບໍລິການທີ່ລົງທະບຽນແມ່ນເປັນຊັບສິນຂອງເຈົ້າຂອງຂອງເຂົາເຈົ້າ. Juniper Networks ຖືວ່າບໍ່ມີຄວາມຮັບຜິດຊອບຕໍ່ຄວາມບໍ່ຖືກຕ້ອງໃດໆໃນເອກະສານນີ້. Juniper Networks ສະຫງວນສິດໃນການປ່ຽນແປງ, ປັບປຸງແກ້ໄຂ, ໂອນ, ຫຼືແກ້ໄຂສິ່ງພິມນີ້ໂດຍບໍ່ມີການແຈ້ງລ່ວງໜ້າ. ສະຫງວນລິຂະສິດ © 2023 Juniper Networks, Inc. ສະຫງວນລິຂະສິດທັງໝົດ.

ເອກະສານ / ຊັບພະຍາກອນ

Juniper NETWORKS NETCONF & YANG API Software [pdf] ຄູ່ມືຜູ້ໃຊ້ ຊອບແວ NETCONF YANG API, ຊອບແວ YANG API, ຊອບແວ API, ຊອບແວ

ເອກະສານອ້າງອີງ

• ຄູ່ມືຜູ້ໃຊ້