การจัดระเบียบ NETCONF และ YANG API
แนะนำที่ตีพิมพ์
2023-07-07
รุ่น 4.2
การแนะนำ
วัตถุประสงค์ของเอกสารนี้
เอกสารนี้อธิบายวิธีผสานรวม Paragon Active Assurance เข้ากับตัวจัดการบริการเครือข่ายผ่านศูนย์ควบคุม NETCONF & YANG API การลงมือปฏิบัติampจะได้รับมอบหมายงานหลักที่เกี่ยวข้อง ได้แก่ การสร้างและปรับใช้ Virtual Test Agents การรันการทดสอบและมอนิเตอร์ และการดึงผลลัพธ์จากกิจกรรมเหล่านี้
ในเอกสารนี้ nclient ไคลเอนต์ Python NETCONF ที่พร้อมใช้งานอย่างอิสระถูกใช้ในบทบาทของผู้ควบคุม
อนุสัญญา
มีการใช้คำย่อต่อไปนี้ในเอกสารนี้:
คำย่อ | ความหมาย |
ซีแอลไอ | อินเทอร์เฟซบรรทัดคำสั่ง |
EM | ผู้จัดการองค์ประกอบ |
ES | ผิดพลาดประการที่สอง |
ส.ส. | จุดสิ้นสุด MEG (กลุ่มเอนทิตีการบำรุงรักษา) (คำจำกัดความ ITU-T Y.1731) หรือจุดสิ้นสุดการบำรุงรักษา (คำจำกัดความของ Cisco) |
เอ็นเอฟวี | การจำลองเสมือนระบบเครือข่าย |
เอ็นเอฟวีโอ | Orchestrator การจำลองเสมือนของฟังก์ชันเครือข่าย |
นสพ. | ตัวอธิบายบริการเครือข่าย |
อาร์พีซี | การเรียกขั้นตอนระยะไกล |
จิบ | โปรโตคอลการเริ่มต้นเซสชั่น |
ข้อกำหนดการให้บริการ | ข้อตกลงระดับการบริการ |
ส-วีเอ็นเอฟเอ็ม | ผู้จัดการ VNF พิเศษ |
วีเอ็นเอฟ | ฟังก์ชั่นเครือข่ายเสมือน |
วีทีเอ | ตัวแทนการทดสอบเสมือน |
หมายเหตุเกี่ยวกับความเข้ากันได้แบบย้อนหลัง
ในเวอร์ชัน 2.35.4/2.36.0 ของ NETCONF & YANG API การตรวจสอบความถูกต้องของคำขอบางอย่างได้รับการปรับปรุงให้เข้มงวดยิ่งขึ้นเพื่อให้เป็นไปตามมาตรฐาน NETCONF ซึ่งหมายความว่ารหัสไคลเอ็นต์ที่ใช้เวอร์ชันเก่าของคู่มือนี้อาจถูกปฏิเสธในขณะนี้
เช่นample ใน Python ก่อนหน้า เช่นampรหัส le ไม่ได้ระบุแอตทริบิวต์เนมสเปซไว้ ตอนนี้ต้องระบุเนมสเปซในคำขอ XML ทุกครั้งที่คุณต้องการแก้ไขทรัพยากร ConfD
ข้อกำหนดเบื้องต้นและการเตรียมการ
การติดตั้ง ConfD
ConfD (ผลิตภัณฑ์จาก Tail-f) ใช้เป็นตัวกลางระหว่างระบบ Paragon Active Assurance และ NETCONF ConfD เชื่อมต่อการกำหนดค่า Paragon Active Assurance และข้อมูลการปฏิบัติงานกับ NETCONF & YANG API
ConfD ควรได้รับการติดตั้งพร้อมกับซอฟต์แวร์ Control Center ตามที่อธิบายไว้ในคู่มือการติดตั้ง
การตรวจสอบว่า ConfD กำลังทำงานอยู่
หากต้องการตรวจสอบว่า ConfD ทำงานอยู่ ให้รันคำสั่ง
สช -ส @localhost -p 830 netconf
เพื่อตรวจสอบว่า ConfD ตอบสนองบนพอร์ต 830 ในคำสั่ง เป็นไปตามที่กำหนดโดยผู้ใช้ netconf ที่สร้าง
คำสั่งในคู่มือการติดตั้ง ส่วนการติดตั้ง ConfD ให้รหัสผ่านที่กำหนดโดยคำสั่งเดียวกัน
ในเอาต์พุต ตรวจสอบว่ามีโมดูลศูนย์ควบคุมรวมอยู่ด้วย ผลลัพธ์ควรมีบรรทัดดังนี้:
http://ncc.netrounds.com?module=netrounds-ncc&แก้ไข=2017-06-15
การซิงโครไนซ์ฐานข้อมูลการกำหนดค่ากับศูนย์ควบคุม
สุดท้ายเราจำเป็นต้องอัปเดตฐานข้อมูลการกำหนดค่าผ่าน NETCONF เราจะดำเนินการดังกล่าวโดยใช้ไลบรารี Python ที่เรียกว่า ncclient (NETCONF Client) อย่างไรก็ตาม งานนี้สามารถทำได้สำเร็จในภาษาการเขียนโปรแกรมอื่น ตราบใดที่ใช้โปรโตคอล NETCONF/YANG
บทบาทของ ncclient คือทำหน้าที่เป็นไคลเอนต์ไปยังเซิร์ฟเวอร์ ConfD ที่โฮสต์ NETCONF/YANG API
เป็นที่น่าสังเกตว่า nclient ไม่เกี่ยวข้องกับ Control Center แต่อย่างใด (ก่อนหน้านี้คือ "Netrounds Control Center") แม้ว่าชื่อจะขึ้นต้นด้วย "ncc" ก็ตาม
นี่คือวิธีการติดตั้ง nclient:
- ดาวน์โหลดซอฟต์แวร์จาก https://github.com/ncclient/ncclient.
- รันคำสั่งนี้: pip install nclient
ตอนนี้เราสามารถทำการซิงโครไนซ์ได้ดังนี้ โปรดทราบว่าจะต้องดำเนินการนี้บนคอมพิวเตอร์เครื่องอื่น ไม่ใช่บนเซิร์ฟเวอร์ศูนย์ควบคุม:
#
# บันทึก:
# สคริปต์นี้ทำหน้าที่เป็นไคลเอ็นต์สำหรับ ConfD ที่ทำงานบนเซิร์ฟเวอร์ NCC
# จะใช้ NETCONF/YANG API เพื่อการสื่อสาร
บันทึก: ขั้นตอนนี้จำเป็นเช่นกันทุกครั้งที่ติดตั้งและลงทะเบียน Test Agent โดยไม่ขึ้นกับ NETCONF ดูหมายเหตุในส่วน “เกินview ของการจัดการตัวแทนทดสอบ” บนหน้าที่ 17 สำหรับข้อมูลเพิ่มเติม
การตั้งค่าบัญชี Paragon Active Assurance ที่ควบคุมโดย NETCONF หลายบัญชี
ขั้นตอนด้านล่างนี้จำเป็นต่อเมื่อคุณต้องการตั้งค่าบัญชี Paragon Active Assurance เพิ่มเติมเพื่อให้ NETCONF ควบคุม นอกเหนือจากบัญชีที่กำหนดค่าในลักษณะนี้ในคู่มือการติดตั้ง ส่วน “การติดตั้ง ConfD”
สำหรับแต่ละบัญชีดังกล่าว ให้ดำเนินการดังนี้:
- ในศูนย์ควบคุม ให้เข้าสู่ระบบบัญชีแล้วไปที่บัญชี > การอนุญาต
- เพิ่มผู้ใช้ “ติดต่อเราได้ที่ confd@netrounds.com“ และให้สิทธิ์ผู้ดูแลระบบผู้ใช้ ConfD นี้ใน GUI โดยคลิกปุ่มเชิญ
- ซิงโครไนซ์ฐานข้อมูลการกำหนดค่ากับศูนย์ควบคุมตามที่อธิบายไว้ในส่วน “การซิงโครไนซ์ฐานข้อมูลการกำหนดค่ากับศูนย์ควบคุม” บนหน้าที่ 4
ตอนนี้คุณควรจะสามารถควบคุมบัญชี Paragon Active Assurance หลายบัญชีด้วยผู้ใช้ ConfD คนเดียวกันได้แล้ว
บันทึก: เมื่อคุณเริ่มควบคุมบัญชี Paragon Active Assurance ผ่าน ConfD คุณจะต้องไม่ทำการเปลี่ยนแปลงกับบัญชีนี้ผ่านทาง web GUI ที่เกี่ยวข้องกับคุณสมบัติ Paragon Active Assurance ที่เป็น "การกำหนดค่า" (ดูบท "คุณสมบัติที่รองรับใน Paragon Active Assurance" บนหน้าที่ 9) หากคุณทำเช่นนั้น จะส่งผลให้สูญเสียการซิงค์
ข้อมูลเบื้องต้นเกี่ยวกับ NETCONF Orchestration API
เกินview
โดยทั่วไป NFVO หรือผู้ประสานงานบริการของบริษัทอื่นจะเป็นองค์ประกอบที่เริ่มต้นเซสชันการทดสอบและการตรวจสอบโดยใช้ Control Center API ผู้เรียบเรียงนี้ยังดึงผลการวัดแบบรวมจากกิจกรรมตัวแทนการทดสอบอีกด้วย KPI ประสิทธิภาพอาจถูกเรียกค้นโดยระบบการจัดการประสิทธิภาพของบริษัทอื่น ในขณะที่เหตุการณ์ต่างๆ ซึ่งเมื่อถูกกระตุ้นโดยการละเมิดเกณฑ์ที่กำหนดในศูนย์ควบคุม สามารถส่งไปยังระบบการจัดการข้อบกพร่องของบริษัทอื่นได้
โดยสรุป รูปภาพด้านล่างแสดงให้เห็นว่า Paragon Active Assurance โต้ตอบกับระบบของบริษัทอื่นอื่นๆ ในภาพรวม OSS อย่างไร
- NFVO/Service Orchestrator: สั่งให้ VNF Manager ปรับใช้ vTA และกำหนดค่า Paragon Active Assurance ในห่วงโซ่บริการ เมื่อเปิดใช้งานบริการแล้ว ผู้จัดทำจะใช้ API ไปยังศูนย์ควบคุมเพื่อทริกเกอร์การทดสอบการเปิดใช้งานบริการและรับผลลัพธ์ที่ผ่าน/ไม่ผ่าน หากผ่านการทดสอบ ผู้จัดทำจะใช้ API ไปยังศูนย์ควบคุมเพื่อเริ่มการตรวจสอบบริการอย่างแข็งขัน KPI จากการมอนิเตอร์จะถูกดึงข้อมูลอย่างต่อเนื่องโดยผู้จัดทำหรือโดยแพลตฟอร์มการจัดการประสิทธิภาพที่แยกต่างหาก
- ศูนย์ควบคุม: ปรับใช้ ปรับขนาด และยุติ vTA ตามคำแนะนำของ NFVO หรือผู้ให้บริการ
- ระบบการจัดการประสิทธิภาพหรือระบบการจัดการคุณภาพการบริการ: อ่าน KPI จากการตรวจสอบที่ใช้งานอยู่ผ่าน Control Center API
- ระบบการจัดการข้อผิดพลาด: รับ NETCONF, SNMP หรือการแจ้งเตือนทางอีเมลจากศูนย์ควบคุมหากมีการละเมิด SLA
คำจำกัดความของแนวคิดใน Paragon Active Assurance
- สารทดสอบ: ส่วนประกอบที่ทำการวัด (สำหรับการทดสอบและจอภาพ) ในระบบ Paragon Active Assurance ตัวแทนการทดสอบประกอบด้วยซอฟต์แวร์ที่สามารถสร้าง รับ และวิเคราะห์การรับส่งข้อมูลเครือข่ายจริง
- ประเภทของ Test Agent ที่กล่าวถึงในเอกสารนี้คือ Virtual Test Agent (vTA) ซึ่งเป็นฟังก์ชันเครือข่ายเสมือน (VNF) ที่ใช้งานบนไฮเปอร์ไวเซอร์ มีสารทดสอบประเภทอื่นๆ อยู่ด้วย
- การวัดพื้นฐานใน Paragon Active Assurance มีสองประเภท ได้แก่ การทดสอบ และการตรวจติดตาม
- การทดสอบ: การทดสอบประกอบด้วยหนึ่งขั้นตอนหรือหลายขั้นตอน ซึ่งแต่ละขั้นตอนมีระยะเวลาจำกัดตามที่ระบุ ขั้นตอนจะดำเนินการตามลำดับ แต่ละขั้นตอนอาจมีการทำงานหลายอย่างพร้อมกัน
- จอภาพ: จอภาพไม่มีระยะเวลาที่ระบุ แต่ดำเนินการอย่างไม่มีกำหนด เช่นเดียวกับขั้นตอนในการทดสอบ จอภาพอาจดำเนินงานหลายอย่างพร้อมกัน
- แม่แบบ: เมื่อ Paragon Active Assurance ถูกควบคุมโดยผู้ดำเนินการ การทดสอบและการตรวจสอบจะดำเนินการโดยใช้แม่แบบที่กำหนดการทดสอบหรือการตรวจสอบเสมอ การตั้งค่าพารามิเตอร์สามารถส่งผ่านเป็นอินพุตไปยังเทมเพลตขณะรันไทม์ได้
ขั้นตอนการทำงานสำหรับระบบอัตโนมัติ
เวลาออกแบบ
ในขณะออกแบบ คุณเตรียมการวัดโดยการสร้างเทมเพลตสำหรับการทดสอบและการตรวจสอบใน Paragon Active Assurance วิธีการดังกล่าวมีอยู่ในบท “ทดสอบและตรวจสอบเทมเพลต” บนหน้าที่ 15
รันไทม์
ขณะรันไทม์ คุณตั้งค่าอุปกรณ์ของคุณและทำการวัดตามจริง
- โอเวอร์view ของอดีตทั้งหมดampบทที่ให้ไว้มีอยู่ในบท “อพยampของการควบคุม Paragon Active Assurance ผ่าน NETCONF & YANG API” บนหน้าที่ 15
- วิธีการปรับใช้และกำหนดค่า Test Agents มีอยู่ในบท “เช่นamples: สารทดสอบ” บนหน้าที่ 16
- วิธีนำเข้าสินค้าคงคลัง เช่น TWAMP ตัวสะท้อนและช่อง IPTV ผ่านไปแล้วในบท “เช่นampเล: รายการสินค้าคงคลัง” บนหน้าที่ 29
- วิธีกำหนดค่าการเตือนมีอธิบายไว้ในบท “เช่นampเล: สัญญาณเตือน” บนหน้าที่ 35
- วิธีรันการทดสอบและมอนิเตอร์โดยการรันเทมเพลต Paragon Active Assurance ผ่าน NETCONF มีอธิบายไว้ในบท “ตัวอย่างamples: การทดสอบ” บนหน้าที่ 43 และ “เช่นampเล: จอภาพ” บนหน้าที่ 54
คุณสมบัติที่รองรับใน Paragon Active Assurance
การทดสอบและการตรวจสอบทุกประเภทใน Paragon Active Assurance สามารถสร้างและดำเนินการได้ผ่านการใช้เทมเพลต วิธีการทำเช่นนี้มีอยู่ในวิธีใช้ภายในแอปภายใต้ “การทดสอบและการตรวจสอบ” > “การสร้างเทมเพลต”
ขณะนี้ยังไม่รองรับการสร้างบัญชี Paragon Active Assurance อย่างไรก็ตาม จะมีการตั้งค่าบัญชีที่กำหนดไว้ล่วงหน้าหนึ่งบัญชีหรือหลายบัญชีสำหรับผู้ใช้
ตารางด้านล่างแสดงรายละเอียดว่าฟีเจอร์ใดบ้างใน Paragon Active Assurance ที่พร้อมใช้งานในรุ่นนี้ และวิธีแสดงคุณสมบัติเหล่านี้ใน YANG
คำอธิบายของ YANG Constructs
เพื่อความสะดวก ให้คำจำกัดความของโครงสร้าง YANG ที่อ้างถึงในตารางคุณลักษณะที่นี่
- Config (config=true): ข้อมูลการกำหนดค่า จำเป็นในการแปลงระบบจากสถานะหนึ่งไปอีกสถานะหนึ่ง
- สถานะ (config=false): ข้อมูลสถานะ: ข้อมูลเพิ่มเติมบนระบบที่ไม่ใช่ข้อมูลการกำหนดค่า เช่น ข้อมูลสถานะแบบอ่านอย่างเดียวและสถิติที่รวบรวม
- RPC: การเรียกขั้นตอนระยะไกลตามที่ใช้ภายในโปรโตคอล NETCONF
- การแจ้งเตือน: การแจ้งเตือนเหตุการณ์ที่ส่งจากเซิร์ฟเวอร์ NETCONF ไปยังไคลเอนต์ NETCONF
ตารางคุณสมบัติ Paragon Active Assurance ที่พร้อมใช้งานสำหรับการเรียบเรียง
แหล่งข้อมูล: การติดตามผล
เส้นทาง YANG:/accounts/account/monitors
คุณสมบัติ | คุณสมบัติย่อย | ยางก่อสร้าง |
สร้าง/แก้ไข/ลบจอภาพ | ขึ้นอยู่กับเทมเพลตจอภาพ | การกำหนดค่า |
จอภาพเริ่ม/หยุด | – | การกำหนดค่า |
ตรวจสอบเทมเพลต | แสดงรายการเทมเพลตจอภาพที่มีอยู่พร้อมอินพุต | สถานะ |
การแจ้งเตือนของ NETCONF | สถานะการปลุกเปลี่ยนไป | การแจ้งเตือน |
ติดตามผล | ตัวนับ SLA/ES สำหรับระดับบนสุด (%) ตัวนับ SLA/ES สำหรับระดับงาน (%) |
สถานะ |
ต่างจากการทดสอบ (เปรียบเทียบทรัพยากร: การทดสอบด้านล่าง) จอภาพไม่ได้เริ่มต้นด้วย RPC แต่จะเริ่มต้นด้วยการกำหนดค่าจอภาพ
แหล่งข้อมูล: การทดสอบ
เส้นทาง YANG: /accounts/account/tests
คุณสมบัติ | คุณสมบัติย่อย | ยางก่อสร้าง |
เริ่มการทดสอบ | ขึ้นอยู่กับเทมเพลตการทดสอบ | อาร์พีซี |
จัดการการทดสอบ | รายการการทดสอบที่มีสถานะ | สถานะ |
เทมเพลตการทดสอบ | แสดงรายการเทมเพลตการทดสอบที่มีอยู่พร้อมอินพุต | สถานะ |
การแจ้งเตือนของ NETCONF | สถานะการทดสอบเปลี่ยนไป | การแจ้งเตือน |
ผลการทดสอบ | รับสถานะขั้นตอนการทดสอบ (ผ่าน, ไม่ผ่าน, ผิดพลาด, …) | สถานะ |
แหล่งข้อมูล: ตัวแทนทดสอบ
เส้นทางยาง:
- /accounts/account/test-agents (กำหนดค่า)
- /accounts/account/registered-test-agents (สถานะ)
ตัวแทนการทดสอบภายใต้ /accounts/account/test-agents คือตัวแทนที่ได้รับการกำหนดค่าในบัญชี เฉพาะตัวแทนการทดสอบเหล่านี้เท่านั้นที่สามารถกำหนดค่าและใช้ในการทดสอบและติดตามผ่าน NETCONF โดยผู้ดำเนินการ
หลังจากที่คุณกำหนดค่าตัวแทนการทดสอบและได้ลงทะเบียนกับบัญชีแล้ว ตัวแทนทดสอบจะปรากฏใต้ /accounts/account/registered-test-agents คุณสามารถค้นหา Test Agents ที่ลงทะเบียนไว้ทั้งหมดได้โดยใช้คำสั่ง “get” ใน NETCONF (เปรียบเทียบบท Examples: ตัวแทนการทดสอบ)
ภายใต้ /accounts/account/registered-test-agents คุณยังอาจพบ Test Agents ที่ยังไม่ได้กำหนดค่าอีกด้วย ต้องกำหนดค่าสารทดสอบดังกล่าวก่อนจึงจะสามารถใช้งานได้
ในสถานการณ์การจัดการประสาน โดยทั่วไปขอแนะนำให้คุณกำหนดค่าบัญชี Paragon Active Assurance ทั้งหมดผ่าน NETCONF เพื่อให้แน่ใจว่าตัวแทนทดสอบและตัวแทนทดสอบที่ลงทะเบียนจะไม่แตกต่างกัน
คุณสมบัติ | คุณสมบัติย่อย | ยางก่อสร้าง |
สร้างตัวแทนการทดสอบล่วงหน้าบนเซิร์ฟเวอร์ | – | การกำหนดค่า |
กำหนดค่าตัวแทนการทดสอบออฟไลน์ | (ศูนย์ควบคุมผลักดันการกำหนดค่าไปที่ตัวแทนทดสอบ เมื่อออนไลน์) |
การกำหนดค่า |
ใช้ตัวแทนการทดสอบที่มีอยู่/กำหนดค่าภายนอก | ใช้ในการทดสอบ/ตรวจสอบ | การกำหนดค่า |
กำหนดค่าอินเทอร์เฟซ | การกำหนดค่า | |
รับสถานะ | สถานะ | |
กำหนดค่าตัวแทนการทดสอบ (อุปกรณ์ทดสอบเท่านั้น) | กำหนดค่า NTP | การกำหนดค่า |
กำหนดค่าบริดจ์ | การกำหนดค่า | |
กำหนดค่าอินเทอร์เฟซ VLAN | การกำหนดค่า | |
กำหนดค่าคีย์ SSH | การกำหนดค่า | |
IPv6 | การกำหนดค่า | |
ยูทิลิตี้ | รีบูต | อาร์พีซี |
อัปเดต | อาร์พีซี | |
การแจ้งเตือนของ NETCONF | สถานะออนไลน์มีการเปลี่ยนแปลง | การแจ้งเตือน |
สถานะ | รับสถานะระบบ (สถานะการออนไลน์ การใช้หน่วยความจำ โหลดเฉลี่ย, เวอร์ชัน) |
สถานะ |
ทรัพยากร: สินค้าคงคลัง
เส้นทาง YANG: /accounts/account/twamp-ตัวสะท้อนแสง
รองรับความสามารถของ NETCONF
ตารางด้านล่างชี้ไปที่ IETF RFC ที่อธิบายความสามารถของ NETCONF ที่ใช้เพื่อวัตถุประสงค์ในการจัดการ Paragon Active Assurance
- ietf-netconf.หยาง
- IETF RFC 6241, โปรโตคอลการกำหนดค่าเครือข่าย (NETCONF), https://tools.ietf.org/html/rfc6241
- วิธีการจัดการข้อผิดพลาดที่สนับสนุนเพียงอย่างเดียวคือการย้อนกลับเมื่อเกิดข้อผิดพลาด
- ที่เก็บข้อมูลที่รองรับเพียงแห่งเดียวคือการทำงานแบบเขียนได้
- ietf-netconf-notifications.หยาง
- IETF RFC 5277, การแจ้งเตือนเหตุการณ์ NETCONF, https://tools.ietf.org/html/rfc5277
ทดสอบและตรวจสอบเทมเพลต
เทมเพลตสำหรับประเภทการทดสอบและการตรวจสอบจะต้องตั้งค่าด้วยตนเองผ่านอินเทอร์เฟซผู้ใช้ส่วนหน้าของ Paragon Active Assurance วิธีการทำเช่นนี้มีอยู่ในวิธีใช้ภายในแอปภายใต้ “การทดสอบและการตรวจสอบ” > “การสร้างเทมเพลต”
Exampของการควบคุม Paragon Active Assurance ผ่าน NETCONF & YANG API
ในบทต่อๆ ไป จะถือว่ามีการกำหนดเทมเพลตการทดสอบและการตรวจสอบที่เหมาะสมตามคำแนะนำที่ให้ไว้ในบท “เทมเพลตการทดสอบและการตรวจสอบ” บนหน้าที่ 15
เครื่องมือที่ใช้ในตัวอย่างampเลส
อดีตทั้งหมดampไฟล์ในบทต่อๆ ไปได้รับการสร้างขึ้นโดยใช้เครื่องมือที่หาได้ฟรีดังต่อไปนี้:
- แป้ง: ใช้เพื่อแสดงภาพและเรียกดูโมเดล YANG
- มีจำหน่ายที่ https://github.com/mbj4668/pyang (โคลนจาก git และรัน python setup.py install)
- ไคลเอนต์ Python NETCONF “ncclient”: ใช้เพื่อสื่อสารกับศูนย์ควบคุมโดยใช้ NETCONF
- มีให้ที่ https://github.com/ncclient/ncclient (เรียกใช้ pip install ncclient)
พบโมเดลข้อมูล netrounds-ncc.yang ใน /opt/netrounds-confd เมื่อติดตั้ง ConfD ตามคู่มือการติดตั้ง)
เกินview ของงานหลักที่ดำเนินการ
(งานเพิ่มเติมบางงานมีตัวอย่างดังต่อไปนี้ด้วย)
- “การสร้างและการปรับใช้ตัวแทนทดสอบใหม่” บนหน้าที่ 16
- “การสร้างรายการสินค้าคงคลัง (เช่น ตัวสะท้อนแสง)” บนหน้าที่ 29
- “การตั้งค่าเทมเพลตการเตือนและตำแหน่งที่จะส่งการเตือน” บนหน้าที่ 35
- “การสร้างและดำเนินการทดสอบ” บนหน้าที่ 45
- “การดึงผลการทดสอบ” บนหน้าที่ 50
- “การเริ่มต้นจอภาพ (รวมถึงการตั้งค่าการเตือน)” บนหน้าที่ 60
- “การดึงข้อมูลสถานะ SLA สำหรับมอนิเตอร์” บนหน้าที่ 67
- “การทำงานร่วมกับ tags” บนหน้าที่ 71
Examples: ตัวแทนทดสอบ
เกินview ของการประสานตัวแทนทดสอบ
สารทดสอบใน Paragon Active Assurance ถือเป็น "การกำหนดค่า" ในบริบทของการจัดการ ซึ่งหมายความว่าการสร้าง การควบคุม และการลบตัวแทนการทดสอบควรทำผ่านตัวจัดการและ NETCONF แทนที่จะดำเนินการผ่าน Paragon Active Assurance GUI
สิ่งสำคัญ: หากมีการติดตั้งตัวแทนการทดสอบโดยช่างเทคนิคและลงทะเบียนกับศูนย์ควบคุมโดยไม่ได้สร้างผ่าน NETCONF & YANG API ก่อน ตัวแทนการทดสอบจะไม่มีอยู่ในฐานข้อมูลการกำหนดค่า และระบบจะไม่ซิงค์กัน เพื่อให้ ConfD ทราบถึงตัวแทนการทดสอบในกรณีนี้ จะต้องทำการซิงโครไนซ์ใหม่กับศูนย์ควบคุม ดังรายละเอียดในส่วน “การซิงโครไนซ์ฐานข้อมูลการกำหนดค่ากับศูนย์ควบคุม” บนหน้าที่ 4
ดังนั้นการประสานตัวแทนการทดสอบเสมือน (vTA) จึงควรดำเนินการในขั้นตอนต่อไปนี้:
- สร้าง Virtual Test Agent รวมถึงการกำหนดค่าอินเทอร์เฟซ โดยใช้อินเทอร์เฟซ NETCONF & YANG ไปยังศูนย์ควบคุม ชื่อของ Test Agent จะเป็นคีย์เฉพาะของมัน
- ปรับใช้ vTA บนแพลตฟอร์มการจำลองเสมือน ทำตามคำแนะนำในวิธีใช้ออนไลน์ภายใต้ตัวแทนการทดสอบ > การติดตั้ง การกำหนดค่าอินเทอร์เฟซพื้นฐานที่อนุญาตให้ vTA เชื่อมต่อกับศูนย์ควบคุม รวมถึงข้อมูลประจำตัวสำหรับการตรวจสอบสิทธิ์นั้นมอบให้ใน vTA โดยใช้ข้อมูลผู้ใช้ cloud-init
เมื่อ vTA บูตแล้ว มันจะเชื่อมต่อกับศูนย์ควบคุมโดยอัตโนมัติโดยใช้การเชื่อมต่อ OpenVPN ที่เข้ารหัส การแจ้งเตือน NETCONF ถูกส่งไปเนื่องจากค่าของพารามิเตอร์ test-agent-statuschange ของ vTA เปลี่ยนเป็น “ออนไลน์” แล้ว
บันทึก: เนื่องจากชื่อของ vTA เป็นตัวระบุใน Control Center ชื่อนี้จึงต้องเหมือนกับชื่อที่กำหนดใน Control Center ใน “ขั้นตอนที่ 1” ในหน้า 17 - เมื่อ vTA เชื่อมต่อและรับรองความถูกต้องกับศูนย์ควบคุมแล้ว การกำหนดค่าอินเทอร์เฟซจะถูกส่งไปยัง vTA นี่คือการกำหนดค่าอินเทอร์เฟซที่ให้ไว้ใน “ขั้นตอนที่ 1” ในหน้า 17 เมื่อมีการสร้าง vTA ในศูนย์ควบคุม
- หลังจากที่ vTA บรรลุวัตถุประสงค์แล้ว ให้ลบ vTA ออก
การสร้างและการปรับใช้ตัวแทนทดสอบใหม่
ก่อนอื่นเราต้องสร้าง Test Agent โดยใช้อินเทอร์เฟซ NETCONF & YANG ไปยัง Control Center เมื่อตัวแทนการทดสอบถูกสร้างขึ้นในลักษณะนี้ ไม่จำเป็นต้องซิงโครไนซ์กับศูนย์ควบคุม
โมเดล YANG สำหรับตัวแทนการทดสอบดังที่แสดงด้านล่าง ได้รับเป็นเอาท์พุตจากคำสั่ง
pyang -f tree netrounds-ncc.yang
แบบจำลอง YANG แบบเต็มมีระบุไว้ใน “ภาคผนวก: โครงสร้างแบบต้นไม้ของแบบจำลอง YANG แบบเต็ม” ในหน้า 81 ซึ่งยังมีคำอธิบายที่อธิบายแบบแผนที่ใช้ในภาพประกอบนี้และภาพประกอบแบบจำลอง YANG อื่นๆ ในเอกสารปัจจุบัน
เราดำเนินการตามขั้นตอนต่อไปนี้ซึ่งมีรายละเอียดดังต่อไปนี้:
- ในตอนแรก บัญชี Paragon Active Assurance “สาธิต” ไม่มีตัวแทนการทดสอบอยู่ในสินค้าคงคลัง
- ตัวแทนการทดสอบที่เรียกว่า "vta1" ถูกสร้างขึ้นโดยใช้ nclient ที่สtage ยังไม่มีตัวแทนการทดสอบจริง (นั่นคือ ยังไม่ได้เริ่มต้น)
- ตัวแทนการทดสอบถูกปรับใช้ใน OpenStack (การปรับใช้งานบนแพลตฟอร์มนั้นถูกเลือกที่นี่ว่าเป็นหนึ่งในความเป็นไปได้ในบรรดาแพลตฟอร์มอื่นๆ)
- ตัวแทนทดสอบเชื่อมต่อกับบัญชี “สาธิต” ของศูนย์ควบคุม และตอนนี้พร้อมใช้งานแล้ว
ขั้นตอนที่ 1: ในตอนแรก ไม่มีตัวแทนการทดสอบในบัญชี “สาธิต” ดูภาพหน้าจอด้านล่างจาก GUI ของศูนย์ควบคุมขั้นตอนที่ 2: สร้างตัวแทนทดสอบในศูนย์ควบคุมโดยใช้ไคลเอนต์ Python NETCONF “ncclient” ด้านล่างนี้คือโค้ด nclient สำหรับการสร้างเอเจนต์ทดสอบที่มีอินเทอร์เฟซทางกายภาพเดียวกับที่อยู่ DHCP:
นำเข้า argparse
จากผู้จัดการการนำเข้าของ nclient
parser = argparse.ArgumentParser (คำอธิบาย = 'ทดสอบการสร้างตัวแทนทดสอบ')
parser.add_argument('–host', help='ชื่อโฮสต์ที่พบ ConfD', required=True)
parser.add_argument('–port', help='พอร์ตสำหรับเชื่อมต่อกับ ConfD', required=True)
parser.add_argument('–username', help='ชื่อผู้ใช้เพื่อเชื่อมต่อกับ ConfD', required=True)
parser.add_argument('–password', help='รหัสผ่านไปยังบัญชี ConfD', required=True)
parser.add_argument('–netrounds-account', help='ชื่อย่อของบัญชี NCC', required=True)
parser.add_argument('–test-agent-name', help='Name of Test Agent', required=True)
args = ตัววิเคราะห์.parse_args()
ด้วย manager.connect(host=args.host, port=args.port, ชื่อผู้ใช้=args.username,
รหัสผ่าน=args.password, hostkey_verify=False) เป็น m:
# สร้างตัวแทนทดสอบในศูนย์ควบคุม
xml = “””
)พิมพ์ m.edit_config(target='running', config=xml)
บันทึก: รหัสที่นำหน้าด้วย manager.connect(…) จะถูกละเว้นจากตัวอย่างที่ตามมาampข้อมูลโค้ดของ le
เซิร์ฟเวอร์ NTP ได้รับการกำหนดค่าบน eth0 และ eth0 ยังเป็นอินเทอร์เฟซการจัดการด้วย (นั่นคือ อินเทอร์เฟซที่เชื่อมต่อกับศูนย์ควบคุม)
แอปพลิเคชันตัวแทนทดสอบไม่อนุญาตให้กำหนดค่าอินเทอร์เฟซในขณะนี้ ด้วยเหตุนี้ ตั้งแต่เวอร์ชัน 2.34.0 เป็นต้นไป จึงเป็นไปได้ที่จะละเว้นการกำหนดค่าอินเทอร์เฟซในสคีมา YANG XML ที่สอดคล้องกันจึงทำให้ง่ายขึ้นอย่างมากในกรณีนี้:เมื่อสร้าง Test Agent แล้ว จะมีอยู่ในฐานข้อมูลการกำหนดค่าและใน Control Center ดูภาพหน้าจอด้านล่างของรายการสารตัวแทนทดสอบ ซึ่งแสดงสารทดสอบ “vta1”:
ขั้นตอนที่ 3: ถึงเวลาปรับใช้ Test Agent “vta1” ใน OpenStack แล้ว
เอเจนต์ทดสอบจะใช้ข้อมูลผู้ใช้ cloud-init เพื่อดึงข้อมูลเกี่ยวกับวิธีการเชื่อมต่อกับศูนย์ควบคุม โดยเฉพาะข้อความข้อมูลผู้ใช้ file มีเนื้อหาดังต่อไปนี้ (โปรดทราบว่าต้องมีบรรทัด #cloud-config และ netrounds_test_agent และบรรทัดที่เหลือจะต้องเยื้อง):
สำหรับข้อมูลเพิ่มเติม โปรดดูเอกสารวิธีการปรับใช้ Virtual Test Agents ใน OpenStack
เมื่อตัวแทนทดสอบถูกปรับใช้และเชื่อมต่อกับศูนย์ควบคุมแล้ว การกำหนดค่าจะถูกผลักจากศูนย์ควบคุมไปยังตัวแทนทดสอบ
ขั้นตอนที่ 4: ขณะนี้ตัวแทนทดสอบออนไลน์อยู่ในศูนย์ควบคุมและได้รับการกำหนดค่าแล้ว สารทดสอบพร้อมสำหรับการใช้งานในการทดสอบและการตรวจสอบ ดูส่วนเหล่านี้:
- “การเริ่มการทดสอบ” บนหน้าที่ 45
- “การเริ่มต้นจอภาพ” บนหน้าที่ 60
รายชื่อตัวแทนการทดสอบในบัญชี Paragon Active Assurance ของคุณ
ด้านล่างนี้เป็นตัวอย่างampรหัส Python ของไคลเอนต์สำหรับแสดงรายการตัวแทนการทดสอบในบัญชี Paragon Active Assurance:
การรันโค้ดนี้จะให้ผลลัพธ์ดังนี้:
การลบตัวแทนทดสอบ
หลังจากการทดสอบเสร็จสิ้น อาจมีความเกี่ยวข้องในบางกรณีในการลบตัวแทนการทดสอบ
ด้านล่างนี้คือข้อมูลโค้ดที่แสดงวิธีดำเนินการนี้กับ nclient:
การแจ้งเตือนของ NETCONF
ด้านล่างนี้เรานำเสนอตัวอย่างง่ายๆampสคริปต์สำหรับการฟังการแจ้งเตือน NETCONF ขาเข้าทั้งหมดจากศูนย์ควบคุม การแจ้งเตือนเหล่านี้จะถูกส่งเมื่อใดก็ตามที่มีเหตุการณ์บางอย่างเกิดขึ้น เช่น เอเจนต์การทดสอบออฟไลน์หรือการทดสอบที่เริ่มต้นโดยผู้ใช้เสร็จสมบูรณ์ ตามข้อมูลที่ดำเนินการในการแจ้งเตือน ผู้ใช้สามารถกำหนดการดำเนินการติดตามผลแบบอัตโนมัติในตัวจัดการได้
เมื่อสคริปต์ข้างต้นถูกดำเนินการ ไคลเอนต์ NC จะแสดงการแจ้งเตือนที่ได้รับในรูปแบบ XML ที่มีโครงสร้าง ดูแฟนเก่าampเอาต์พุตด้านล่าง ซึ่งแสดงว่าตัวแทนทดสอบออฟไลน์โดยไม่คาดคิด
2017-02-03T15:09:55.939156+00:00</eventTime>
<test-agent-status-change xmlns=’http://ncc.netrounds.com-
การสาธิต
HW1
ออฟไลน์
Examples: รายการสินค้าคงคลัง
การสร้าง (นำเข้า) และการจัดการรายการสินค้าคงคลัง เช่น TWAMP ตัวสะท้อนแสงและ MEP ของ Y.1731 ดำเนินการในลักษณะเดียวกันกับสารทดสอบ ด้านล่างนี้คือโค้ด XML และ NETCONF สำหรับกำหนดเอนทิตีดังกล่าวใน Paragon Active Assurance ผ่าน NETCONF & YANG API และสำหรับการดึงข้อมูลรายการของรายการที่กำหนดไว้
การสร้าง TWAMP แผ่นสะท้อนแสง
การสร้าง Y.1731 MEP
การสร้างช่อง IPTV
การสร้างโฮสต์ปิง
การสร้างบัญชี SIP
การเรียกค้นรายการสินค้าคงคลัง
ด้านล่างนี้คือรหัส Python สำหรับดึงรายการสินค้าคงคลังทั้งหมดที่กำหนดไว้ในบัญชี (รายการสินค้าคงคลังทุกประเภทจะถูกดึงมาในครั้งเดียวที่นี่เพื่อหลีกเลี่ยงการซ้ำซ้อนในเอกสาร โดยปกติแล้ว รายการสินค้าคงคลังชุดย่อยใดๆ สามารถดึงออกมาได้โดยละบรรทัดบางส่วนภายใต้บัญชีด้านล่าง)
การรันโค้ดนี้จะให้ผลลัพธ์ดังนี้:
Exampเล: สัญญาณเตือน
เทมเพลตการแจ้งเตือนและรายการที่เกี่ยวข้อง (ผู้จัดการ SNMP รายชื่ออีเมลแจ้งเตือน) จะถูกสร้างและจัดการในลักษณะเดียวกันกับรายการสินค้าคงคลัง บทนี้ประกอบด้วยโค้ด XML และ NETCONF สำหรับกำหนดเอนทิตีดังกล่าวใน Paragon Active Assurance ผ่าน NETCONF & YANG API และสำหรับการดึงข้อมูลรายการของรายการที่กำหนดไว้
รายการอีเมลปลุก
การสร้างรายการอีเมลแจ้งเตือน
การดึงรายการอีเมลแจ้งเตือนทั้งหมด
ผู้จัดการ SNMP
การสร้างตัวจัดการ SNMP
การเรียกข้อมูลผู้จัดการ SNMP ทั้งหมด
เทมเพลตการเตือน
การสร้างเทมเพลตการเตือน
กำลังดึงเทมเพลตการเตือนทั้งหมด
Exampไฟล์: คีย์ SSH
คุณสามารถเพิ่มคีย์สาธารณะ SSH ให้กับตัวแทนการทดสอบผ่านทาง NETCONF & YANG API การใช้คีย์ส่วนตัวที่เกี่ยวข้องทำให้คุณสามารถเข้าสู่ระบบตัวแทนทดสอบผ่าน SSH ได้
รายการการดำเนินการทั้งหมดที่มีบนคีย์ SSH มีดังต่อไปนี้:
- เพิ่มคีย์ SSH
- แก้ไขคีย์ SSH
- ตรวจสอบคีย์ SSH
- แสดงรายการคีย์ SSH
- ลบคีย์ SSH
ด้านล่างนี้คือตัวอย่างการดำเนินการเพิ่มและลบ

การลบคีย์ SSH
หากคุณต้องการลบคีย์ SSH ให้ใช้คำสั่งต่อไปนี้:
Exampเล: การทดสอบ
ที่นี่สันนิษฐานว่าสารทดสอบ (จำนวนเท่าที่จำเป็นสำหรับการทดสอบ) ได้ถูกสร้างขึ้นตามส่วน “การสร้างและการปรับใช้สารทดสอบใหม่” บนหน้าที่ 17
เส้นทางแบบจำลอง YANG สำหรับการทดสอบ
รายการ | เส้นทางโมเดล YANG: /accounts/account/tests … |
การทดสอบ | /. |
ทดสอบ [รหัส] | /ทดสอบ |
id | /ทดสอบ/รหัส |
ชื่อ | /ทดสอบ/ชื่อ |
สถานะ | /ทดสอบ/สถานะ |
เวลาเริ่มต้น | /ทดสอบ/เวลาเริ่มต้น |
เวลาสิ้นสุด | /ทดสอบ/เวลาสิ้นสุด |
รายงาน-url | /รายงานผลการทดสอบ-url |
ขั้นตอน | /ทดสอบ/ขั้นตอน |
ขั้นตอน [รหัส] | /ทดสอบ/ขั้นตอน/ขั้นตอน |
ชื่อ | /ทดสอบ/ขั้นตอน/ขั้นตอน/ชื่อ |
id | /ทดสอบ/ขั้นตอน/ขั้นตอน/id |
เวลาเริ่มต้น | /ทดสอบ/ขั้นตอน/ขั้นตอน/เวลาเริ่มต้น |
เวลาสิ้นสุด | /ทดสอบ/ขั้นตอน/ขั้นตอน/สิ้นสุดเวลา |
สถานะ | /ทดสอบ/ขั้นตอน/ขั้นตอน/สถานะ |
ข้อความสถานะ | /ทดสอบ/ขั้นตอน/ขั้นตอน/ข้อความสถานะ |
เทมเพลต | /แม่แบบ |
แม่แบบ[ชื่อ] | /แม่แบบ/แม่แบบ |
ชื่อ | /แม่แบบ/แม่แบบ/ชื่อ |
คำอธิบาย | /แม่แบบ/แม่แบบ/คำอธิบาย |
พารามิเตอร์ | /เทมเพลต/เทมเพลต/พารามิเตอร์ |
พารามิเตอร์ [คีย์] | /เทมเพลต/เทมเพลต/พารามิเตอร์/พารามิเตอร์ |
สำคัญ | /เทมเพลต/เทมเพลต/พารามิเตอร์/พารามิเตอร์/คีย์ |
พิมพ์ | /เทมเพลต/เทมเพลต/พารามิเตอร์/พารามิเตอร์/ชนิด |
ข้อกำหนดเบื้องต้นสำหรับการเตรียมการทดสอบ
- ในการเริ่มการทดสอบผ่าน NETCONF โดยใช้ไคลเอนต์ NC จะต้องสร้างเทมเพลตการทดสอบก่อนโดยใช้ Control Center GUI ตามรายละเอียดในความช่วยเหลือในแอปภายใต้ “การทดสอบและการตรวจสอบ” > “การสร้างเทมเพลต” ช่องทั้งหมดที่ระบุในเทมเพลตนั้นเป็น "อินพุตเทมเพลต" จะต้องใช้เป็นพารามิเตอร์ใน XML เมื่อเตรียมการเริ่มต้นเทมเพลตการทดสอบ
- การรันการทดสอบใน Paragon Active Assurance ถือเป็น "สถานะ" ในบริบทของการจัดการ ข้อมูลสถานะเป็นข้อมูลที่ไม่สามารถเขียนได้ซึ่งไม่ได้จัดเก็บไว้ในฐานข้อมูลการกำหนดค่าซึ่งตรงข้ามกับข้อมูลการกำหนดค่าที่กล่าวถึงในส่วน “มากกว่าview ของ Test Agent Orchestration” บนหน้าที่ 17 โดยพื้นฐานแล้วหมายความว่าการเปลี่ยนแปลงการทดสอบหรือเทมเพลตใน Control Center GUI จะไม่ทำให้เกิดปัญหาใดๆ ที่เกี่ยวข้องกับการซิงค์ระหว่าง Control Center และฐานข้อมูลการกำหนดค่า
- เพื่อรับรายงาน-URL ในรายงานการทดสอบ คุณต้องตรวจสอบให้แน่ใจว่าศูนย์ควบคุม URL ได้รับการกำหนดค่าอย่างถูกต้อง โดยจะทำใน file /opt/netrounds-confd/settings.py ตามค่าเริ่มต้น ชื่อโฮสต์ของศูนย์ควบคุมจะถูกดึงข้อมูลโดยใช้ socket.gethostname(): ดูด้านล่าง หากไม่ได้ผลลัพธ์ที่ถูกต้อง คุณจะต้องตั้งชื่อโฮสต์ (หรือทั้งหมด URL) ด้วยตนเองในสิ่งนี้ file.
# URL ของศูนย์ควบคุมโดยไม่มีเครื่องหมายทับต่อท้าย
# นี่สำหรับอดีตampเลอที่ใช้ในรายงานการทดสอบ-url.
ชื่อโฮสต์ = socket.gethostname()
เน็ตรอบ_URL = 'https://%s' % ชื่อโฮสต์
เริ่มการทดสอบ
ตามที่อธิบายไว้ในส่วน “การสร้างและการปรับใช้ตัวแทนการทดสอบใหม่” ในหน้า 17 ให้รันคำสั่ง pang -f tree netrounds-ncc.yang
จากไดเร็กทอรี /opt/netrounds-confd/ เพื่อส่งออกโมเดล YANG ในแบบจำลองนี้ RPC สำหรับเริ่มการทดสอบโดยใช้ไคลเอนต์ NC มีลักษณะดังนี้:
สำหรับคำอธิบาย โปรดดูในส่วน “ตำนาน” บนหน้าที่ 81 ในภาคผนวก
ขั้นตอนต่อไปนี้แสดงไว้ด้านล่าง:
- ตัวแทนการทดสอบได้รับการลงทะเบียนในบัญชี Paragon Active Assurance แล้ว แต่ยังไม่มีการเริ่มต้นการทดสอบ
- พารามิเตอร์อินพุตที่จำเป็นจะถูกระบุในเทมเพลตการทดสอบที่จะเรียกใช้
- การทดสอบ HTTP 60 วินาทีเริ่มต้นโดยใช้ nclient
ขั้นตอน 1: ในตอนแรก ไม่มีการเริ่มต้นการทดสอบในบัญชี Paragon Active Assurance ดูภาพหน้าจอด้านล่างจาก GUI ของศูนย์ควบคุม
ขั้นตอน 2: เทมเพลตที่เราจะใช้เพื่อเริ่มต้นการทดสอบในตัวอย่างนี้ample เป็นเทมเพลตการทดสอบ HTTP มีช่องป้อนข้อมูลบังคับสองช่อง ( Clients และ URL) ซึ่งเราได้ระบุไว้เมื่อสร้างเทมเพลตใน Control Center GUI
เราจะกำหนดพารามิเตอร์เหล่านี้ (อื่นๆ) ในการกำหนดค่า XML ที่สื่อสารกับฐานข้อมูลการกำหนดค่าโดยผู้จัดการ NETCONF ของเรา (ncclient)
ขั้นตอนที่ 3: การทดสอบ HTTP เริ่มต้นโดยใช้ nclient
ด้านล่างนี้เป็นตัวอย่างampรหัส le โดยระบุข้อมูลการกำหนดค่าและพารามิเตอร์ที่จำเป็นสำหรับเทมเพลตการทดสอบ HTTP รายละเอียดที่นี่อาจแตกต่างกันไป ขึ้นอยู่กับวิธีการสร้างเทมเพลต
สำหรับแต่ละพารามิเตอร์ จำเป็นต้องระบุแอตทริบิวต์ คีย์จะเหมือนกับของพารามิเตอร์
ชื่อตัวแปรในศูนย์ควบคุม คุณสามารถตรวจสอบชื่อตัวแปรได้ดังนี้:
- คลิกการทดสอบบนแถบด้านข้างและเลือกลำดับการทดสอบใหม่
- คลิกเทมเพลตของฉัน
- คลิกลิงก์แก้ไขด้านล่างเทมเพลตที่สนใจ
- คลิกปุ่มแก้ไขการป้อนข้อมูลที่มุมขวาบน
ในอดีตของเราampไฟล์ และตามค่าเริ่มต้น ชื่อตัวแปรเป็นเพียงชื่อที่แสดงในรูปแบบตัวพิมพ์เล็กที่เห็นในศูนย์ควบคุม (“url” กับ “URL” ฯลฯ ) อย่างไรก็ตาม ใน Control Center GUI คุณสามารถเปลี่ยนชื่อตัวแปรเป็นอะไรก็ได้ที่คุณต้องการ
นอกจากคีย์แล้ว แต่ละพารามิเตอร์ยังต้องมีการระบุประเภท: เช่นampเลอ สำหรับ URL.
โปรดทราบว่าคุณต้องอีกครั้งview แบบจำลอง YANG ที่สมบูรณ์เพื่อให้ได้ข้อมูลที่สมบูรณ์เกี่ยวกับประเภทต่างๆ สำหรับอินเทอร์เฟซของตัวแทนทดสอบ ประเภทนี้มีโครงสร้างที่ซับซ้อนมากขึ้น ดังที่เห็นได้ด้านล่าง ในรหัสด้านล่าง
ตอนนี้เราสามารถรันสคริปต์โดยใช้ nclient ได้แล้ว สมมติว่าทุกอย่างถูกต้อง การทดสอบจะเริ่มขึ้นและการดำเนินการจะแสดงในศูนย์ควบคุม:หากเริ่มการทดสอบสำเร็จ ศูนย์ควบคุมจะตอบกลับด้วยรหัสการทดสอบ ในตัวอย่างนี้ampเลอ รหัสการทดสอบคือ 3:
รหัสการทดสอบยังสามารถพบได้ใน URL สำหรับการทดสอบใน Control Center GUI ในตัวอย่างนี้ampเลอ นั่น URL คือ https://host/demo/testing/3/
กำลังดึงผลการทดสอบ
วิธีที่ตรงไปตรงมาที่สุดในการรับผลการทดสอบคือการชี้ไปที่รหัสการทดสอบ
ด้านล่างนี้คือโค้ด Python สำหรับรับผลลัพธ์จากการทดสอบ HTTP ข้างต้นด้วย ID = 3:
กับผู้จัดการ เชื่อมต่อ (host=args.host, port=args.port, ชื่อผู้ใช้=args.username,password=args.password, hostkey_verify=False) เป็น m:
ผลลัพธ์จะมีลักษณะดังนี้:
การส่งออกและการนำเข้าเทมเพลตการทดสอบ
เทมเพลตการทดสอบสามารถส่งออกในรูปแบบ JSON และนำเข้าอีกครั้งในรูปแบบนั้นไปยังศูนย์ควบคุม สิ่งนี้มีประโยชน์หากคุณต้องการใช้เทมเพลตทดสอบในการติดตั้งศูนย์ควบคุมอื่น (การสร้างเทมเพลตครั้งแรกจะได้รับการจัดการที่ดีที่สุดผ่าน Control Center GUI)
ด้านล่างนี้เป็นโค้ดสำหรับดำเนินการส่งออกและนำเข้า
การส่งออกเทมเพลตการทดสอบ
# รับการกำหนดค่า json จากการตอบกลับ
root = ET.fromstring (ตอบกลับ._raw)
json_config = รูท[0].ข้อความ
พิมพ์ json_config.php
เทมเพลตมีอยู่ในวัตถุ json_config
การนำเข้าเทมเพลตการทดสอบ
เทมเพลตการทดสอบการเก็บออบเจ็กต์การกำหนดค่า JSON สามารถนำเข้าอีกครั้งไปยังศูนย์ควบคุมได้ดังต่อไปนี้
Exampเล: จอภาพ
ส่วนนี้จะถือว่าสารทดสอบ (มากเท่าที่จอภาพต้องการ) ได้ถูกสร้างขึ้นตามส่วน “การสร้างและการปรับใช้สารทดสอบใหม่” บนหน้าที่ 17
YANG Model Paths สำหรับจอภาพ
รายการ | เส้นทางโมเดล YANG: /accounts/account/monitors … |
จอภาพ | /. |
มอนิเตอร์ [ชื่อ] | /เฝ้าสังเกต |
ชื่อ | /มอนิเตอร์/ชื่อ |
คำอธิบาย | /ตรวจสอบ/คำอธิบาย |
เริ่ม | /ตรวจสอบ/เริ่มต้น |
เทมเพลต | /จอภาพ/เทมเพลต |
สัญญาณเตือน-configs | /monitor/การตั้งค่าการเตือนภัย |
รายการ | เส้นทางโมเดล YANG: /accounts/account/monitors/monitor/alarm-configs … |
สัญญาณเตือนการกำหนดค่า [ตัวระบุ] | /alarm-config.php |
ตัวระบุ | /alarm-config/ตัวระบุ |
เทมเพลต | /การตั้งค่าการเตือนภัย/เทมเพลต |
อีเมล | /alarm-config/อีเมล |
ส.เอ็น.เอ็ม. | /การตั้งค่าการเตือนภัย/snmp |
th-es-ที่สำคัญ | /การตั้งค่าการเตือนภัย/thr-es-สำคัญ |
th-es-สำคัญ-ชัดเจน | /การตั้งค่าการเตือนภัย/thr-es-การล้างข้อมูลที่สำคัญ |
th-es-วิชาเอก | /การตั้งค่าการเตือนภัย/thr-es-สำคัญ |
th-es-major-clear | /การตั้งค่าการเตือนภัย/thr-es-สำคัญ-ชัดเจน |
th-es-ไมเนอร์ | /การตั้งค่าการเตือนภัย/thr-es-minor |
th-es-ไมเนอร์-ชัดเจน | /การตั้งค่าการเตือนภัย/thr-es-minor-clear |
th-es-คำเตือน | /การตั้งค่าการเตือน/thr-es- |
th-es-คำเตือนชัดเจน | /การตั้งค่าการเตือน/thr-es-การเตือนที่ชัดเจน |
ไม่มีความรุนแรงของข้อมูล | /alarm-config/ไม่มีความรุนแรงของข้อมูล |
ไม่มีข้อมูลหมดเวลา | /การตั้งค่าการเตือน/ไม่มีข้อมูลหมดเวลา |
การกระทำ | /การตั้งค่าการเตือนภัย/การกระทำ |
ขนาดหน้าต่าง | /การตั้งค่าการเตือนภัย/ขนาดหน้าต่าง |
ช่วงเวลา | /alarm-config/ช่วงเวลา |
ส่งเพียงครั้งเดียว | /alarm-config/ส่งเพียงครั้งเดียว |
snmp-trap-ต่อ-สตรีม | /alarm-config/snmp-trap-ต่อสตรีม |
รายการ | เส้นทางโมเดล YANG: /accounts/account/monitors … |
พารามิเตอร์ | /จอภาพ/พารามิเตอร์ |
รายการ | เส้นทางโมเดล YANG: /accounts/account/monitors/monitor/parameters … |
พารามิเตอร์ [คีย์] | /พารามิเตอร์ |
สำคัญ | /พารามิเตอร์/คีย์ |
(ประเภทค่า) | /พารามิเตอร์ |
:(จำนวนเต็ม) | /พารามิเตอร์ |
จำนวนเต็ม | /พารามิเตอร์/จำนวนเต็ม |
:(ลอย) | /พารามิเตอร์ |
ลอย | /พารามิเตอร์/ลอย |
:(สตริง) | /พารามิเตอร์ |
รายการ | เส้นทางโมเดล YANG: /accounts/account/monitors/monitor/parameters … |
สตริง | /พารามิเตอร์/สตริง |
:(อินเทอร์เฟซตัวแทนทดสอบ) | /พารามิเตอร์ |
อินเทอร์เฟซตัวแทนทดสอบ | /พารามิเตอร์/อินเทอร์เฟซตัวแทนทดสอบ |
อินเทอร์เฟซตัวแทนการทดสอบ [“1” บนหน้าที่ 58 | /พารามิเตอร์/อินเทอร์เฟซตัวแทนทดสอบ/ |
บัญชี | /พารามิเตอร์/ทดสอบ-ตัวแทน-อินเตอร์เฟซ/ทดสอบ-ตัวแทน-อินเตอร์เฟซ/บัญชี |
ตัวแทนทดสอบ | /พารามิเตอร์/อินเตอร์เฟซตัวแทนทดสอบ/อินเตอร์เฟซตัวแทนทดสอบ/ตัวแทนทดสอบ |
อินเทอร์เฟซ | /พารามิเตอร์/ทดสอบ-ตัวแทน-อินเตอร์เฟซ/ทดสอบ-ตัวแทน-อินเตอร์เฟซ/อินเตอร์เฟซ |
เวอร์ชัน ip | /พารามิเตอร์/ทดสอบ-ตัวแทน-อินเตอร์เฟซ/ทดสอบ-ตัวแทน-อินเตอร์เฟซ/รุ่น IP |
:(ทamp-ตัวสะท้อนแสง) | /พารามิเตอร์ |
twamp-ตัวสะท้อนแสง | /พารามิเตอร์/twamp-ตัวสะท้อนแสง |
twamp-ตัวสะท้อนแสง[ชื่อ] | /พารามิเตอร์/twamp-ตัวสะท้อนแสง/twamp-ตัวสะท้อนแสง |
ชื่อ | /พารามิเตอร์/twamp-ตัวสะท้อนแสง/twamp-ตัวสะท้อนแสง/ชื่อ |
:(y1731-เมปส์) | /พารามิเตอร์ |
y1731-เมพส์ | /พารามิเตอร์/y1731-meps |
y1731-mep[ชื่อ] | /พารามิเตอร์/y1731-meps/y1731-mep |
ชื่อ | /พารามิเตอร์/y1731-meps/y1731-mep/ชื่อ |
:(บัญชีจิบ) | /พารามิเตอร์ |
บัญชีจิบ | /พารามิเตอร์/บัญชี SIP |
บัญชี sip[“2” ในหน้า 58] | /พารามิเตอร์/บัญชี SIP/บัญชี SIP |
บัญชี | /พารามิเตอร์/บัญชี SIP/บัญชี SIP/บัญชี |
ตัวแทนทดสอบ | /พารามิเตอร์/บัญชี SIP/บัญชี SIP/ตัวแทนทดสอบ |
อินเทอร์เฟซ | /พารามิเตอร์/บัญชี SIP/บัญชี SIP/อินเทอร์เฟซ |
ที่อยู่จิบ | /พารามิเตอร์/บัญชี SIP/บัญชี SIP/ที่อยู่ SIP |
:(ช่อง iptv) | /พารามิเตอร์ |
ช่อง iptv | /พารามิเตอร์/ช่อง iptv |
ช่อง iptv [ชื่อ] | /พารามิเตอร์/ช่อง iptv/ช่อง iptv |
ชื่อ | /พารามิเตอร์/ช่อง iptv/ช่อง iptv/ชื่อ |
- อินเทอร์เฟซตัวแทนทดสอบบัญชี
- ที่อยู่ sip ของอินเทอร์เฟซตัวแทนทดสอบบัญชี
รายการ | เส้นทางโมเดล YANG: /accounts/account/monitors … |
สถานะ | /มอนิเตอร์/สถานะ |
15 นาทีสุดท้าย | /monitor/status/15 นาทีสุดท้าย |
สถานะ | /monitor/status/15 นาทีสุดท้าย/status |
สถานะค่า | /monitor/status/15 นาทีสุดท้าย/status-value |
ชั่วโมงสุดท้าย | /monitor/status/ชั่วโมงสุดท้าย |
สถานะ | /monitor/status/ชั่วโมงสุดท้าย/status |
สถานะค่า | /monitor/status/ชั่วโมงสุดท้าย/status-value |
24 ชั่วโมงที่ผ่านมา | /monitor/status/24 ชั่วโมงที่ผ่านมา |
สถานะ | /ตรวจสอบ/สถานะ/24ชั่วโมงล่าสุด/สถานะ |
สถานะค่า | /monitor/status/24-hours/status-value |
เทมเพลต | /แม่แบบ |
แม่แบบ[ชื่อ] | /แม่แบบ/แม่แบบ |
ชื่อ | /แม่แบบ/แม่แบบ/ชื่อ |
คำอธิบาย | /แม่แบบ/แม่แบบ/คำอธิบาย |
พารามิเตอร์ | /เทมเพลต/เทมเพลต/พารามิเตอร์ |
พารามิเตอร์ [คีย์] | /เทมเพลต/เทมเพลต/พารามิเตอร์/พารามิเตอร์ |
สำคัญ | /เทมเพลต/เทมเพลต/พารามิเตอร์/พารามิเตอร์/คีย์ |
พิมพ์ | /เทมเพลต/เทมเพลต/พารามิเตอร์/พารามิเตอร์/ชนิด |
ข้อกำหนดเบื้องต้นสำหรับ Monitor Orchestration
ก่อนที่คุณจะสามารถเริ่มมอนิเตอร์ผ่าน NETCONF โดยใช้ ncclient ได้ คุณต้องสร้างเทมเพลตมอนิเตอร์ใน Control Center GUI ตามที่อธิบายไว้ในวิธีใช้ภายในแอปภายใต้ “การทดสอบและมอนิเตอร์” > “การสร้างเทมเพลต” ฟิลด์ทั้งหมดที่ระบุเป็น "อินพุตเทมเพลต" ในเทมเพลตนั้นจะต้องใช้เป็นพารามิเตอร์ใน XML เมื่อเตรียมการเริ่มต้นเทมเพลต
การรับพารามิเตอร์อินพุตจากเทมเพลตจอภาพ
ด้านล่างนี้จะแสดงเทมเพลตสองแบบ อินเทอร์เฟซแรกใช้สำหรับการตรวจสอบ UDP ระหว่างอินเทอร์เฟซตัวแทนการทดสอบสองตัว และอินเทอร์เฟซที่สองสำหรับ HTTP โดยใช้อินเทอร์เฟซตัวแทนการทดสอบเดียว
หากต้องการค้นหาพารามิเตอร์อินพุตของเทมเพลต ให้คลิกกล่องที่แสดงเทมเพลต สำหรับเทมเพลต HTTP พารามิเตอร์อาจมีลักษณะดังนี้:
เราจำเป็นต้องกำหนดพารามิเตอร์เหล่านี้ในขั้นตอนถัดไปเมื่อเริ่มต้นจอภาพ
การเริ่มต้นจอภาพ
การใช้สารทดสอบที่เรากำหนดและใช้งานในส่วน “การสร้างและการปรับใช้สารทดสอบใหม่” ในหน้า 17 เราสามารถเริ่มการตรวจสอบจากเทมเพลต “HTTP” ดังที่แสดงด้านล่าง
สำหรับแต่ละพารามิเตอร์ จำเป็นต้องระบุแอตทริบิวต์ คีย์จะเหมือนกับชื่อตัวแปรของพารามิเตอร์ในศูนย์ควบคุม คุณสามารถตรวจสอบชื่อตัวแปรได้ดังนี้:
- คลิกการตรวจสอบบนแถบด้านข้างและเลือกจอภาพใหม่
- คลิกเทมเพลตของฉัน
- คลิกลิงก์แก้ไขด้านล่างเทมเพลตที่สนใจ
- คลิกปุ่มแก้ไขการป้อนข้อมูลที่มุมขวาบน
ในอดีตของเราampไฟล์ และตามค่าเริ่มต้น ชื่อตัวแปรเป็นเพียงชื่อที่แสดงในรูปแบบตัวพิมพ์เล็กที่เห็นในศูนย์ควบคุม (“url” กับ “URL” ฯลฯ ) อย่างไรก็ตาม ใน Control Center GUI คุณสามารถเปลี่ยนชื่อตัวแปรเป็นอะไรก็ได้ที่คุณต้องการ
นอกจากคีย์แล้ว แต่ละพารามิเตอร์ยังต้องมีการระบุประเภท: เช่นampเลอ สำหรับ URL. โปรดทราบว่าข้อมูลทั้งหมดเกี่ยวกับประเภทพารามิเตอร์มีอยู่ในโมเดล YANG สำหรับอินเทอร์เฟซของตัวแทนทดสอบ ประเภทนี้มีโครงสร้างที่ซับซ้อนมากขึ้น ดังที่เห็นในโค้ดด้านล่าง
ในอดีตampที่ตามมา ไม่มีการเตือนที่เกี่ยวข้องกับจอภาพ สำหรับเช่นampที่เกี่ยวข้องกับสัญญาณเตือน ให้ไปที่ส่วน “การเริ่มจอภาพด้วยสัญญาณเตือน” บนหน้าที่ 62
การเริ่มต้นจอภาพด้วยการเตือน
หากต้องการเชื่อมโยงการเตือนกับจอภาพ คุณสามารถชี้ไปที่เทมเพลตการเตือนที่กำหนดไว้ หรือคุณสามารถระบุการกำหนดค่าการเตือนทั้งหมดเมื่อสร้างจอภาพ เราจะให้อดีตหนึ่งอันampของแต่ละแนวทางด้านล่าง
การตั้งค่าการเตือนของจอภาพโดยชี้ไปที่เทมเพลตการเตือน
หากต้องการใช้เทมเพลตการเตือน คุณต้องทราบ ID ของเทมเพลตนั้น ในการสิ้นสุดนี้ ขั้นแรกเรียกเทมเพลตการเตือนทั้งหมดของคุณตามที่อธิบายไว้ในส่วน “การเรียกเทมเพลตการเตือนทั้งหมด” บนหน้าที่ 39 และจดบันทึกชื่อของเทมเพลตที่เกี่ยวข้อง จากนั้นคุณสามารถอ้างอิงถึงเทมเพลตนั้นได้ดังต่อไปนี้:
การตั้งค่าการแจ้งเตือนของจอภาพโดยการกำหนดค่าโดยตรงy
หรือคุณสามารถตั้งค่าการเตือนสำหรับจอภาพโดยระบุการกำหนดค่าทั้งหมดเมื่อสร้างจอภาพ โดยไม่ต้องอ้างอิงถึงเทมเพลตการเตือน นี้จะกระทำตามที่แสดงในตัวอย่างต่อไปนี้ampเล.
การเรียกข้อมูลจอภาพที่กำลังทำงานอยู่
หากต้องการดึงข้อมูลจอภาพทั้งหมดที่กำลังดำเนินการอยู่ ให้รันสคริปต์นี้:
กับผู้จัดการ เชื่อมต่อ (host=args.host, port=args.port, ชื่อผู้ใช้=args. ชื่อผู้ใช้, รหัสผ่าน=args.password, hostkey_verify=False) เป็น m:
ผลลัพธ์คือรายการของมอนิเตอร์ที่ทำงานอยู่ทั้งหมดดังที่แสดงด้านล่าง:
การดึงสถานะ SLA สำหรับมอนิเตอร์
ต่อไปนี้เป็นวิธีดึงสถานะ SLA สำหรับจอภาพ ในตัวอย่างนี้ampในตอนนี้ เรากำลังดึงสถานะ SLA สำหรับมอนิเตอร์ “คุณภาพเครือข่าย” เป็นเวลาสามช่วง: 15 นาทีที่ผ่านมา ชั่วโมงสุดท้าย และ 24 ชั่วโมงที่ผ่านมา
ผลลัพธ์จะมีลักษณะดังนี้:
การแจ้งเตือนของ NETCONF
การแจ้งเตือน NETCONF สำหรับจอภาพถูกทริกเกอร์โดยการละเมิด SLA สิ่งเหล่านี้เกิดขึ้นเมื่อ SLA สำหรับจอภาพลดลงต่ำกว่าเกณฑ์ SLA (“ดี” หรือ “ยอมรับได้”) ภายในกรอบเวลาที่กำหนด ตามค่าเริ่มต้นในช่วง 15 นาทีที่ผ่านมา ควรสังเกตว่าการแจ้งเตือนการละเมิด SLA จะปรากฏขึ้นอย่างรวดเร็วหลังจากที่บริการได้รับผลกระทบจากปัญหา ในขณะที่สถานะ SLA จะเปลี่ยนกลับเป็น "ดี" หลังจากผ่านไป 15 นาทีเท่านั้น และเฉพาะในกรณีที่ไม่มีการละเมิดเกิดขึ้นอีกเท่านั้น
สามารถเปลี่ยนกรอบเวลาได้โดยแก้ไขการตั้งค่า SLA_STATUS_WINDOW (ค่าเป็นวินาที) /etc/netrounds/netrounds.conf.
การส่งออกและการนำเข้าเทมเพลตจอภาพ
ทำได้ในลักษณะเดียวกับเทมเพลตการทดสอบ เปรียบเทียบส่วน “การส่งออกและการนำเข้าเทมเพลตการทดสอบ” ในหน้า 52 ข้อมูลโค้ดด้านล่างนี้แสดงวิธีการส่งออกและนำเข้าเทมเพลตสำหรับจอภาพ
การส่งออกเทมเพลตจอภาพ
การนำเข้าเทมเพลตจอภาพ
Tags ที่กำหนดไว้ใน Paragon Active Assurance สามารถนำไปใช้กับ:
- จอภาพ
- ตรวจสอบเทมเพลต
- ตัวแทนทดสอบ
- TWAMP แผ่นสะท้อนแสง
- ปิงเจ้าภาพ.
เช่นampเล คุณทำได้ tag มอนิเตอร์เหมือนกัน tag เป็นส่วนย่อยของ Test Agents ที่จะรันมอนิเตอร์ คุณลักษณะนี้มีประโยชน์อย่างยิ่งหากคุณกำหนดจอภาพและเทมเพลตจำนวนมาก
หากคุณได้ตั้งค่าการเตือนด้วยกับดัก SNMP สำหรับมอนิเตอร์ กับดัก SNMP จะถูกกำหนดเหมือนกัน tags เป็นจอภาพ ถ้ามี
การสร้าง Tags
ด้านล่างเราจะแสดงวิธีการสร้าง tag ด้วยชื่อและสีตามที่กำหนดโดย XMLtag> โครงสร้างย่อย
การมอบหมายงาน Tag
ในการมอบหมาย a tag ลงในทรัพยากร คุณเพิ่มเป็นทรัพยากรใหม่tag> องค์ประกอบภายใต้tags> องค์ประกอบสำหรับทรัพยากรนั้น
นี่คือวิธีการกำหนด tag ไปยังตัวแทนทดสอบ:
ในการมอบหมาย a tag ถึง TWAMP ตัวสะท้อนแสง ให้ปฏิบัติดังนี้:
การมอบหมายงาน tag ไปยังจอภาพได้รับการจัดการในทำนองเดียวกัน:
หรือคุณสามารถกำหนดที่มีอยู่ได้ tag ไปยังประเภททรัพยากรใดๆ เหล่านี้เมื่อสร้างทรัพยากร โดยรวมtags> องค์ประกอบที่มี tag อยู่ในคำถาม.
การอัพเดต Tag
กำลังปรับปรุงที่มีอยู่ tag ด้วยคุณลักษณะใหม่จะคล้ายคลึงกับการสร้าง tag:
การยกเลิกการกำหนด Tag
เพื่อยกเลิกการมอบหมาย tag จากทรัพยากร ให้เพิ่มแอตทริบิวต์ nc:operation=”delete” ลงในtag> องค์ประกอบที่เป็นของทรัพยากร ด้านล่าง เรายกเลิกการมอบหมาย tag จากจอภาพ
การลบ Tag
เพื่อที่จะลบ tag จากศูนย์ควบคุม แอตทริบิวต์ nc:operation=”delete” จะถูกใช้อีกครั้ง แต่คราวนี้ใช้กับ tag เอง ซึ่งกำหนดไว้ภายใต้ .
การแก้ไขปัญหา
ปัญหา: Orchestrator และ Paragon Active Assurance ไม่ซิงค์กัน
ผู้เรียบเรียงและ Paragon Active Assurance อาจไม่ซิงค์กัน เช่นampหากมีการเปลี่ยนแปลงการกำหนดค่าใน Control Center GUI หรือหากการใช้การกำหนดค่าไม่สำเร็จและการย้อนกลับไปยังสถานะก่อนหน้าล้มเหลว
ในกรณีที่การย้อนกลับล้มเหลว เซิร์ฟเวอร์ NETCONF จะไม่ยอมรับการเปลี่ยนแปลงการกำหนดค่าอีกต่อไป มันจะตอบกลับพร้อมข้อความแสดงข้อผิดพลาดที่ระบุว่าการกำหนดค่าถูกล็อคจนกว่าจะกลับมาซิงค์อีกครั้ง หากต้องการกลับมาซิงค์และปลดล็อกการเปลี่ยนแปลงการกำหนดค่า คุณจะต้องเรียกใช้คำสั่ง rpc sync-from-ncc ซึ่งจะซิงโครไนซ์การกำหนดค่าทั้งหมดจากศูนย์ควบคุมไปยังฐานข้อมูลการกำหนดค่า
บันทึก: การ ติดต่อเราได้ที่ confd@netrounds.com ผู้ใช้ (หรืออะไรก็ตามที่ได้รับการกำหนดค่า) ต้องมีสิทธิ์ผู้ใช้ขั้นสูงเพื่อให้ทุกอย่างซิงค์ได้สำเร็จ ซึ่งสามารถทำได้ด้วยคำสั่ง ncc user-update ติดต่อเราได้ที่ confd@netrounds.com –is-superuser หากผู้ใช้ไม่ใช่ superuser คำเตือนจะปรากฏขึ้นโดยบอกว่าไม่สามารถซิงค์ทุกอย่างได้ แต่สามารถจัดการได้ทั้งหมด
บันทึก: หากผู้ดำเนินการจัดเก็บการกำหนดค่าไว้ด้วย คุณจะต้องซิงโครไนซ์สิ่งนั้นอีกครั้ง เนื่องจากการกำหนดค่าที่ร้องขอ (การกำหนดค่าที่ผู้ควบคุมคาดว่าศูนย์ควบคุมจะมี) จะไม่ถูกนำมาใช้
ปัญหา: การซิงค์ครั้งแรก (sync-from-ncc) ล้มเหลวเนื่องจากทรัพยากรที่ไม่รองรับ
หากคุณพยายามเรียกใช้ rpc sync-from-ncc บนบัญชีที่มีการกำหนดค่าที่สร้างไว้ใน Control Center GUI คุณอาจประสบปัญหาหากบัญชีมีทรัพยากรที่ไม่รองรับ ขอแนะนำให้คุณเริ่มต้นด้วยบัญชีว่างและกำหนดค่าทั้งหมดผ่าน NETCONF มิฉะนั้น หากคุณพบปัญหาเกี่ยวกับความขัดแย้งของทรัพยากร คุณจะต้องลบทรัพยากรที่ขัดแย้งออกจากบัญชี
ปัญหา: คำสั่ง NETCONF ล้มเหลวด้วย ncclient.operations.rpc.RPCError: การสื่อสารของแอปพลิเคชันล้มเหลว
เซิร์ฟเวอร์ NETCONF จะไม่คืนค่าการเชื่อมต่อกับเซิร์ฟเวอร์ศูนย์ควบคุมโดยอัตโนมัติหากรีสตาร์ทศูนย์ควบคุม หากต้องการคืนค่าการเชื่อมต่อกับ Control Center ให้รีสตาร์ทกระบวนการ NETCONF: sudo systemctl รีสตาร์ท netrounds-confd
หมายเหตุเกี่ยวกับการประยุกต์ใช้สารทดสอบและอุปกรณ์ของสารทดสอบ
ทดสอบแอปพลิเคชันตัวแทนใน ConfD
ในบรรดาสารทดสอบ แอปพลิเคชันตัวแทนการทดสอบ (ใหม่กว่า) ทำงานแตกต่างไปจากอุปกรณ์ตัวแทนทดสอบ (เก่ากว่า) เล็กน้อย
แอปพลิเคชันตัวแทนทดสอบไม่รองรับการกำหนดค่าอินเทอร์เฟซในขณะนี้ ดังนั้น สคีมา YANG อนุญาตให้ระบุการกำหนดค่าอินเทอร์เฟซว่างสำหรับตัวแทนการทดสอบดังกล่าว ดู “ข้อความนี้” ในหน้า 23 สำหรับตัวอย่างampเล.
เมื่อซิงโครไนซ์ฐานข้อมูล ConfD กับ Control Center โดยใช้คำสั่ง sync-from-ncc คุณต้องการให้การกำหนดค่าอินเทอร์เฟซว่างเปล่าและไม่ถูกเขียนทับด้วยสิ่งที่พบใน Control Center ดังนั้น คุณจึงจำเป็นต้องใช้แฟล็กพิเศษ –without_interface_config กับคำสั่งนั้นเมื่อทำงานกับ Test Agent Applications
การกำหนดค่าอินเทอร์เฟซว่างเปล่าสำหรับ Test Agent Appliance
ตามที่ระบุไว้ข้างต้น แอปพลิเคชันตัวแทนการทดสอบไม่รองรับการกำหนดค่าอินเทอร์เฟซ ดังนั้นจึงเป็นไปได้ที่จะละเว้นอินเทอร์เฟซในสคีมา YANG
แต่ยังมีกรณีการใช้งานที่คุณอาจต้องการละเว้นการกำหนดค่าอินเทอร์เฟซจาก Test Agent Appliance อดีตampสิ่งนี้อาจเป็นสถานการณ์การจัดประสานที่คุณกำลังสร้างตัวแทนการทดสอบโดยใช้ cloud-init และคุณต้องการให้มีการใช้การกำหนดค่าอินเทอร์เฟซจากที่นั่น แทนที่จะปล่อยให้ ConfD เขียนทับเมื่อตัวแทนการทดสอบออนไลน์
YANG Schema เปลี่ยนแปลงเกี่ยวกับอินเทอร์เฟซที่ไม่ได้กำหนด
เนื่องจากขณะนี้อนุญาตให้ใช้การกำหนดค่าอินเทอร์เฟซที่ว่างเปล่า (ตั้งแต่เวอร์ชัน 2.34.0 เป็นต้นไป) จึงเป็นไปได้ที่จะระบุชื่ออินเทอร์เฟซใดๆ ให้เป็นอินพุตสำหรับงานที่ทำงานโดยเป็นส่วนหนึ่งของการทดสอบหรือจอภาพ
สิ่งนี้จำเป็นเพื่อให้สามารถใช้แอปพลิเคชันตัวแทนทดสอบได้ เนื่องจากไม่มีการกำหนดชื่ออินเทอร์เฟซใน ConfD อย่างไรก็ตาม โปรดทราบว่านี่ยังหมายความว่าคุณอาจประสบปัญหาได้ หากคุณกำหนดค่าการทดสอบหรือจอภาพให้ใช้อินเทอร์เฟซที่ไม่มีอยู่โดยไม่ได้ตั้งใจ ดังนั้นโปรดคำนึงถึงเรื่องนี้ด้วย
ข้อจำกัดเมื่อลงทะเบียนตัวแทนทดสอบที่สร้างใน ConfD
เมื่อสร้าง Test Agent ผ่าน REST หรือ NETCONF/YANG API เราไม่สามารถทราบล่วงหน้าได้ว่าเป็นประเภทใด: Test Agent Appliance หรือ Test Agent Application สิ่งนี้จะชัดเจนหลังจากที่ตัวแทนทดสอบได้ลงทะเบียนแล้วเท่านั้น
เมื่อลงทะเบียนสารทดสอบแล้วและได้เปลี่ยนเป็นประเภทใดประเภทหนึ่งที่เป็นรูปธรรมแล้ว คุณจะไม่ได้รับอนุญาตให้ลงทะเบียนซ้ำในฐานะสารทดสอบประเภทอื่น ซึ่งหมายความว่าคุณไม่ได้รับอนุญาตให้ลงทะเบียนเป็น Test Agent Appliance ก่อน จากนั้นจึงลงทะเบียนใหม่เป็นแอปพลิเคชันตัวแทนทดสอบ หรือในทางกลับกัน หากคุณต้องการตัวแทนการทดสอบประเภทอื่น คุณจะต้องสร้างตัวแทนการทดสอบใหม่
ภาคผนวก: โครงสร้างต้นไม้ของแบบจำลอง YANG แบบเต็ม
ในภาคผนวกนี้ ส่วน “คำอธิบาย” ในหน้า 81 อธิบายไวยากรณ์ของโครงสร้างโมเดลทรี YANG ที่สร้างด้วยคำสั่ง pyang -f tree
ส่วน “YANG Model Tree Structure” ในหน้า 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 [พีดีเอฟ] คู่มือการใช้งาน ซอฟต์แวร์ NETCONF YANG API, ซอฟต์แวร์ YANG API, ซอฟต์แวร์ API, ซอฟต์แวร์ |