การจัดตารางคิว QoS ของ Cisco Catalyst 9200/9300: แบนด์วิดท์ถ่วงน้ำหนัก (WTD) และการแก้ไขปัญหาความแออัด

“Weighted Round Robin” ใน Catalyst 9200/9300 หมายความว่าอย่างไร

สวิตช์อาจมีคลาสการรับส่งข้อมูลหลายประเภทที่แย่งกันใช้พอร์ตส่งออกเดียวกัน เมื่อพอร์ตเกิดความแออัด แพ็กเก็ตจะถูกจัดเรียงลงในคิว และตัวจัดตารางเวลาจะพิจารณาว่าคิวใดจะได้รับการประมวลผลเป็นลำดับถัดไป

การกำหนดค่าน้ำหนักการจัดตารางเวลาที่สูงขึ้นจะทำให้คิวมีโอกาสใช้แบนด์วิดท์ที่มีอยู่มากขึ้น นี่คือแนวคิดที่ผู้ใช้หลายคนเรียกว่าการจัดลำดับแบบวนรอบถ่วงน้ำหนัก (weighted round robin)

บนแพลตฟอร์ม Catalyst 9200 และ 9300 การกำหนดค่าใช้งานจริงโดยทั่วไปจะอิงตาม bandwidth percent, bandwidth remaining percent, bandwidth remaining ratioรวมถึงคิวลำดับความสำคัญ ขีดจำกัดของคิว และการจัดสรรบัฟเฟอร์คิว

คำสั่งและพารามิเตอร์ที่รองรับนั้นขึ้นอยู่กับเวอร์ชันและแพลตฟอร์มของ IOS XE โปรดตรวจสอบเอกสารซอฟต์แวร์ที่เกี่ยวข้องก่อนที่จะนำนโยบาย QoS ไปใช้งานบนระบบ สวิตช์ Cisco Catalyst 9200.

การจัดลำดับคิว, คิวลำดับความสำคัญ และ WTD

การจัดลำดับคิว การจัดการลำดับความสำคัญ และ Weighted Tail Drop แก้ปัญหาที่แตกต่างกัน การเพิ่มน้ำหนักคิวจะไม่แก้ไขการแมป DSCP กับคิวที่ไม่ถูกต้อง และการเปลี่ยนเกณฑ์ WTD จะไม่สร้างแบนด์วิดท์ทางกายภาพเพิ่มเติม

WTD ใช้การกำหนดเครื่องหมายจราจรเพื่อกำหนดเกณฑ์คิวที่แตกต่างกัน เมื่อคิวถึงเกณฑ์ที่เกี่ยวข้องกับคลาสจราจร แพ็กเก็ตใหม่ๆ อาจถูกทิ้งแม้ว่าอินเทอร์เฟซทางกายภาพจะยังคงใช้งานได้ก็ตาม

ซิสโก้ คู่มือการกำหนดค่า QoS สำหรับ Catalyst 9300 อธิบายเกี่ยวกับการจัดสรรแบนด์วิดท์ การจัดลำดับคิว การจัดการลำดับความสำคัญ และพฤติกรรม WTD สำหรับนโยบาย QoS ของ Catalyst

น้ำหนักแบนด์วิดท์ส่งผลต่อคิวขาออกอย่างไร

เปอร์เซ็นต์แบนด์วิดท์

bandwidth percent กำหนดเปอร์เซ็นต์แบนด์วิดท์ขั้นต่ำให้กับแต่ละคลาส หากเปอร์เซ็นต์ที่กำหนดไว้ไม่ใช้แบนด์วิดท์ทั้งหมดที่มีอยู่ แบนด์วิดท์ที่เหลืออาจถูกแบ่งใช้โดยคิวแบนด์วิดท์อื่นๆ

วิธีการนี้มีประโยชน์เมื่อนโยบายจำเป็นต้องสงวนส่วนหนึ่งของอินเทอร์เฟซขาออกที่คาดการณ์ได้สำหรับคลาสการรับส่งข้อมูล

เปอร์เซ็นต์แบนด์วิดท์ที่เหลืออยู่

bandwidth remaining percent มีประโยชน์เมื่อนโยบายนั้นมีคิวลำดับความสำคัญอยู่ด้วย โดยจะกำหนดสัดส่วนของแบนด์วิดท์ที่เหลืออยู่ให้กับคิวที่ไม่มีลำดับความสำคัญ

ตัวอย่างเช่น วิดีโอ ข้อมูลทางธุรกิจ และปริมาณการรับส่งข้อมูลจำนวนมาก อาจได้รับการกำหนดค่าสัมพัทธ์เป็น 40, 40 และ 20 ตามลำดับ ในกรณีที่มีการแย่งชิงทรัพยากร คิววิดีโอและข้อมูลทางธุรกิจจะได้รับส่วนแบ่งแบนด์วิดท์ที่เหลืออยู่มากกว่าคิวปริมาณการรับส่งข้อมูลจำนวนมาก

ค่าเหล่านี้เป็นค่าถ่วงน้ำหนัก ไม่ใช่ตัวเลขปริมาณงานที่รับประกัน คิวหนึ่งอาจใช้แบนด์วิธมากกว่าอีกคิวหนึ่งเมื่อคิวอื่นว่างอยู่ ขึ้นอยู่กับนโยบายและพฤติกรรมของแพลตฟอร์ม

การจัดสรรบัฟเฟอร์คิว

บัฟเฟอร์ของคิวแตกต่างจากน้ำหนักแบนด์วิดท์ คิวอาจมีน้ำหนักการจัดตารางเวลาที่เพียงพอ แต่ก็ยังอาจทิ้งแพ็กเก็ตในช่วงเวลาสั้นๆ หากบัฟเฟอร์ที่มีอยู่หมดลง

• ทราฟฟิกการจำลองการสำรองข้อมูลและการจัดเก็บข้อมูล
• วิดีโอแตกกระจาย
• ลิงก์อัปโหลดความเร็วสูงที่ส่งข้อมูลไปยังพอร์ตความเร็วต่ำ
• พอร์ตเชื่อมต่อหลายพอร์ตมาบรรจบกันที่อินเทอร์เฟซขาออกเดียว

ตัวอย่างนโยบายคุณภาพบริการ (QoS) ที่นำไปใช้ได้จริง

ตัวอย่างต่อไปนี้แสดงให้เห็นถึงวิธีการจัดระเบียบคลาสการรับส่งข้อมูลและน้ำหนักแบนด์วิดท์ที่เหลืออยู่ นี่ไม่ใช่แม่แบบการใช้งานทั่วไป โปรดตรวจสอบไวยากรณ์ที่รองรับสำหรับเวอร์ชัน iOS XE ที่ติดตั้งไว้ก่อนนำไปใช้งาน

ก่อนที่จะนำนโยบายที่คล้ายกันมาใช้ โปรดตรวจสอบให้แน่ใจว่าการกำหนดค่า DSCP นั้นเชื่อถือได้ แผนผังคลาสตรงกับปริมาณการรับส่งข้อมูลที่ต้องการ อินเทอร์เฟซรองรับคุณสมบัติ QoS ที่เลือก และนโยบายดังกล่าวไม่ได้ผสมผสานประเภทแบนด์วิดท์ที่ไม่เข้ากัน

ความหนาแน่นสูง Cisco Catalyst 9300L-48P-4X-E อาจรวบรวมปริมาณการรับส่งข้อมูลได้มากกว่า Catalyst 9200 ระดับ Access Layer ดังนั้นจุดที่เกิดความแออัดอาจเกิดขึ้นบนพอร์ตอัปลิงก์ 10G พอร์ตปลายทาง 1G หรือพอร์ตดาวน์สตรีม ขึ้นอยู่กับโทโพโลยี

วิธีการตรวจสอบพฤติกรรมของคิว

โปรดยืนยันว่าได้แนบเอกสารนโยบายมาแล้ว

เริ่มต้นด้วยการกำหนดค่าอินเทอร์เฟซและนโยบาย ตรวจสอบให้แน่ใจว่านโยบายถูกแนบในทิศทางที่ถูกต้อง และตัวนับคลาสที่คาดหวังเพิ่มขึ้นเรื่อยๆ

ตรวจสอบการลดระดับอินเทอร์เฟซ

โดยปกติแล้ว การลดลงของปริมาณข้อมูลขาออกจำนวนมากมักบ่งชี้ถึงความแออัดของขาออก แต่ตัวนับอินเทอร์เฟซเพียงอย่างเดียวอาจไม่สามารถระบุคิวหรือประเภทการรับส่งข้อมูลที่ได้รับผลกระทบได้

ตรวจสอบสถิติคิว

มองหาข้อมูลการดรอปเฉพาะคิว การใช้งานคิว ตัวนับเกณฑ์ และความแตกต่างระหว่างพฤติกรรมขาเข้าและขาออก ไวยากรณ์คำสั่งที่แน่นอนอาจแตกต่างกันไปตามเวอร์ชันของ IOS XE

ตรวจสอบการติดตั้งนโยบายในฮาร์ดแวร์

นโยบายอาจได้รับการยอมรับจากตัวแยกวิเคราะห์การกำหนดค่าแล้ว แต่ยังคงไม่สามารถติดตั้งลงในฮาร์ดแวร์ได้อย่างถูกต้อง สำหรับอินเทอร์เฟซแบบสแต็ก ให้เลือกสมาชิกสวิตช์ที่ถูกต้อง

สถานะเช่น VALID,SET_INHW แสดงว่าซอฟต์แวร์เข้าใจนโยบายและติดตั้งลงในฮาร์ดแวร์แล้ว ควรตรวจสอบสถานะที่ไม่ถูกต้องก่อนที่จะถือว่านโยบายนั้นใช้งานได้

ตรวจสอบทรัพยากรฮาร์ดแวร์

สำหรับสแต็ก ให้แทนที่ active พร้อมหมายเลขสวิตช์ที่เหมาะสมเมื่อจำเป็น นโยบายที่ติดตั้งไม่สำเร็จอาจได้รับผลกระทบจากไวยากรณ์ที่ไม่รองรับ ข้อจำกัดด้านทรัพยากรฮาร์ดแวร์ หรือข้อจำกัดของเวอร์ชัน IOS XE

เหตุใดคิว QoS จึงดรอปแพ็กเก็ต

การรับส่งข้อมูลเสียงหรือวิดีโอเกิดความล่าช้า

• ค่า DSCP จะไม่ถูกเก็บรักษาไว้
• การจราจรจะถูกจัดสรรไปยังคิวเริ่มต้น
• แผนผังคลาสที่ตั้งใจไว้ไม่ตรงกัน
• คิวลำดับความสำคัญยังไม่ได้ตั้งค่า
• ลิงก์ขาออกมีผู้ใช้งานเกินจำนวนที่กำหนด

เริ่มจากการกำหนดค่าตัวนับนโยบายและแผนที่คลาสก่อนที่จะเปลี่ยนค่าน้ำหนักของคิว

ปริมาณการรับส่งข้อมูลจำนวนมากใช้ทรัพยากรลิงก์ส่วนใหญ่

สาเหตุที่เป็นไปได้ ได้แก่ การรับส่งข้อมูลจำนวนมากเข้าสู่คลาสที่มีลำดับความสำคัญสูง การกำหนดค่าน้ำหนักแบนด์วิดท์ที่มากเกินไป การจำแนกประเภทการรับส่งข้อมูลทางธุรกิจที่ไม่ถูกต้อง หรือการนำนโยบายบริการไปใช้ในทิศทางที่ผิด

ผลผลิตลดลงแต่กลับเพิ่มขึ้นแม้ว่าอัตราการใช้ประโยชน์เฉลี่ยจะต่ำ

อัตราการใช้งานเฉลี่ยอาจซ่อนการใช้งานที่เพิ่มขึ้นอย่างรวดเร็วในช่วงเวลาสั้นๆ การใช้งานที่เพิ่มขึ้นอย่างรวดเร็วอาจทำให้คิวเต็มก่อนที่อัตราเฉลี่ยระดับอินเทอร์เฟซจะปรากฏสูงขึ้น

• ตรวจสอบสถิติคิว
• ตรวจสอบการจัดสรรบัฟเฟอร์
• สังเกตความไม่สอดคล้องกันของความเร็ว
• ตรวจสอบรูปแบบการจัดเก็บข้อมูล การสำรองข้อมูล และการรับส่งข้อมูลวิดีโอ
• ระบุพอร์ตความเร็วสูงหลายพอร์ตที่มาบรรจบกันที่พอร์ตขาออกความเร็วต่ำพอร์ตเดียว

ตั้งค่านโยบาย QoS แล้ว แต่ไม่มีผลใดๆ

ตรวจสอบว่าได้แนบ Service Policy แล้วหรือไม่ ทิศทางของอินเทอร์เฟซถูกต้องหรือไม่ Class-map ตรงกับแพ็กเก็ตหรือไม่ Policy ได้รับการติดตั้งในฮาร์ดแวร์แล้วหรือไม่ และคำสั่งที่เลือกได้รับการสนับสนุนโดย iOS XE เวอร์ชันใด

WTD ทำให้เกิดการสูญเสียแพ็กเก็ตโดยไม่คาดคิด

ตรวจสอบว่าป้ายกำกับ QoS ใดถูกกำหนดให้กับทราฟฟิก เกณฑ์ที่ป้ายกำกับนั้นใช้คืออะไร คิวได้รับปริมาณทราฟฟิกที่เพิ่มขึ้นอย่างฉับพลันหรือไม่ และการจัดสรรบัฟเฟอร์ของคิวเพียงพอหรือไม่

การเพิ่มเกณฑ์ WTD อาจช่วยลดปัญหาการหลุดการเชื่อมต่อได้ แต่ก็อาจทำให้คลาสการรับส่งข้อมูลหนึ่งใช้พื้นที่บัฟเฟอร์ร่วมกันมากขึ้นได้เช่นกัน ดังนั้นควรพิจารณาว่าเป็นaการเปลี่ยนแปลงด้านการออกแบบมากกว่าการแก้ไขปัญหาแบบครอบคลุม

คำถามที่พบบ่อย (FAQs)

รอบชิงชนะเลิศ Takeaway

สำหรับสวิตช์ Catalyst 9200 และ 9300 การวิเคราะห์ "weighted round robin" จะดีที่สุดเมื่อพิจารณาจากองค์ประกอบต่างๆ เช่น การจัดลำดับคิว น้ำหนักของแบนด์วิดท์ การจัดการลำดับความสำคัญ เกณฑ์ WTD และการจัดสรรบัฟเฟอร์

เมื่อแก้ไขปัญหาความแออัด ให้ทำตามขั้นตอนต่อไปนี้:

• ตรวจสอบว่าการจราจรถูกจัดประเภทอย่างไร
• ตรวจสอบว่าได้แนบเอกสารนโยบายมาแล้วหรือไม่
• ตรวจสอบตัวนับคิวและตัวนับอินเทอร์เฟซ
• ตรวจสอบน้ำหนักการจัดตารางเวลาและการตั้งค่าลำดับความสำคัญ
• ตรวจสอบพฤติกรรมของ WTD และบัฟเฟอร์
• ตรวจสอบว่าได้ติดตั้งนโยบายลงในฮาร์ดแวร์แล้ว
• ตรวจสอบทรัพยากรฮาร์ดแวร์และความเข้ากันได้กับ iOS XE

การเปลี่ยนแปลงน้ำหนักของคิวเพียงข้อเดียวจะไม่สามารถแก้ปัญหาที่เกิดจากการจำแนกประเภทที่ไม่ถูกต้อง การบัฟเฟอร์ไม่เพียงพอ หรือนโยบายที่ไม่เคยส่งไปถึง ASIC ได้