การกำหนดหมายเลขคลาส / ตัวกรอง Linux TC


12

ขณะนี้ฉันกำลังทำงานเกี่ยวกับโซลูชันสร้างรูปแบบการจราจรสำหรับ บริษัท ระดับ ISP และมาถึงปัญหาที่น่าสนใจ

เมื่อมองหาจำนวนปลายทางที่ระบบควรจัดการ (ซึ่งประมาณ ~ 20k) ฉันมีความกังวลเล็กน้อยว่าจะเกิดอะไรขึ้นเมื่อฉันต้องการนโยบาย / การรับส่งข้อมูลรูปร่างของผู้ใช้มากขึ้น ในขณะที่ฉันกำลังใช้ HFSC shaping tree (ดู tc-hfsc ซึ่งส่วนใหญ่เป็นสิ่งเดียวกัน แต่เย็นกว่าที่รู้จักกันดีกว่า HTB) สำหรับเครือข่ายทั้งหมดฉันต้องใช้ ClassID เพิ่มเติม (อย่างน้อยหนึ่งรายการสำหรับผู้ใช้แต่ละคนบน ระบบเครือข่าย) ปัญหาที่ฉันพบคือ TC ClassID นั้นมีจำนวน จำกัด - พวกเขาเป็นตัวเลข 16 บิตซึ่งทำให้ฉันมีผู้ใช้มากที่สุด 64k ที่กำหนดโดยโซลูชันนี้

ในทำนองเดียวกันถ้าฉันต้องการจัดการตัวกรอง TC อย่างมีประสิทธิภาพ (เช่นไม่ได้ใช้ 'ล้างเทคนิคทั้งหมด') ฉันต้องสามารถลบหรือแก้ไขรายการตัวกรองแต่ละรายการได้ (ฉันใช้สิ่งที่คล้ายกับตารางแฮชจาก LARTC [1]) อีกวิธีเดียวที่ดูเหมือนว่าจะทำงานกับเรื่องนี้คือการเรียงลำดับตัวกรองทั้งหมดโดยใช้ลำดับความสำคัญของแต่ละบุคคล (tc filter เพิ่ม dev ... prio 1) ไม่มีพารามิเตอร์อื่น ๆ ที่สามารถนำมาใช้เพื่อจุดประสงค์นี้ได้และน่าเสียดายที่ Prio นั้นเป็นแบบ 16 บิตเท่านั้นเช่นกัน

คำถามของฉันมีดังต่อไปนี้: มีวิธีการที่ดีบ้างไหมในการขยาย "ตัวระบุพื้นที่" ที่มีอยู่เช่น clsid 32- บิตสำหรับคำสั่ง 'tc class' และลำดับความสำคัญ 32 บิต (หรือตัวจัดการการปรับเปลี่ยนอื่น ๆ ) สำหรับ 'tc filter' คำสั่ง?

ขอบคุณมาก ๆ,

-mk

(btw ฉันหวังว่านี่จะไม่ไปสู่สถานการณ์ "ผู้ใช้ 64k น่าจะเพียงพอสำหรับทุกคน")


ค่าทั้งหมดเหล่านั้นจะถูกเก็บไว้ในพื้นที่เคอร์เนลเพื่อให้มีขนาดใหญ่ขึ้นคุณจะต้องคอมไพล์เคอร์เนลและยูทิลิตี้ของผู้ใช้ใหม่อีกครั้ง คุณลองใช้เคอร์เนล 64 บิตแล้วหรือยัง? พวกเขาอาจถูกกำหนดเป็น 32 บิตที่นั่น
Hubert Kario

เคอร์เนล 64 บิตใช้ขนาดเท่ากัน ตัวอย่างเช่นหมายเลขตัวกรองเป็นจำนวนเต็ม u32 ซึ่งประกอบด้วยส่วนบน (โปรโตคอล) และส่วนล่าง (prio) ทั้ง 16 บิตที่เห็นได้ชัด รหัสประจำคลาสจะถูกฮาร์ดโค้ดเป็น u16 อาจลองถามคนใน LKML
exa

1
แม้จะใช้แฮชสำหรับตัวกรองของคุณคุณจะมีปัญหา IO มากมายหากคุณใช้ตัวกรองจำนวนมาก (ฉันเดาว่าสำหรับอัปสตรีมและดาวน์สตรีม) ฉันใช้เวลามากและต้องแก้ไขการใช้คิวภายในเคอร์เนลเพื่อให้สิ่งต่าง ๆ ทำงานร่วมกับคุณ ksoftirqd ฉันใช้ปะจากคนที่เรียกว่า Simon Lodal ที่ฉันพบบน LARTC 4 ปีที่แล้ว ลองดูที่แพตช์mail-archive.com/lartc@mailman.ds9a.nl/msg16279.html ของเขา คุณสามารถลองส่งอีเมลให้เขาได้เพราะเขามีเวอร์ชันที่อัปเดตเสมอ (เทียบกับเคอร์เนลตัวสุดท้าย) กับเขา
Pabluez

@Pabluez ขอบคุณมากฉันจะพยายามทำให้ดีที่สุด
exa

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

คำตอบ:


2

ฉันคิดว่าคุณไม่ควรให้ผู้ใช้ 64k ที่มีคลาสต้นน้ำและปลายน้ำและตัวกรองสำหรับผู้ใช้แต่ละคนในอินเทอร์เฟซเดียวกัน คุณสามารถทำซ้ำตัวจัดการสำหรับแต่ละอินเตอร์เฟสที่คุณมีดังนั้นเพิ่มอินเทอร์เฟซเพิ่มเติม คุณจะต้องมีงาน / เซิร์ฟเวอร์ / NIC อย่างไม่น่าเชื่อเพื่อให้ได้สิ่งนี้ หากเซิร์ฟเวอร์ล้มเหลวคุณจะมีผู้ใช้ 64k ออฟไลน์ (และจะล้มเหลวได้อย่างง่ายดายด้วยปริมาณการรับส่งข้อมูลนั้น) อย่าลืมว่าแพ็กเก็ต EACH ที่ผ่านการ์ดเครือข่ายของคุณจะถูกตรวจสอบและจำแนกโดยตัวกรองและส่งไปยังคลาสที่จะเข้าคิว นี่เป็นงานจำนวนมากสำหรับ NIC ของเกตเวย์ ISP ที่มีลูกค้า 64k ส่วนใหญ่กับสตรีมวิดีโอทั้งหมดที่เรามีในปัจจุบัน (ซึ่งยากต่อการจัดคิวอย่างเหมาะสม)


ฉันรับประกันความพร้อมให้บริการในระดับอื่น แต่ขอขอบคุณสำหรับความกังวล จริงๆแล้วด้วย NIC ที่ดีมันไม่ยากเลยที่จะมีเราเตอร์ linux ที่สามารถส่งต่อ 10Gbits
exa

สำหรับคำถามเดิมฉันสนใจสิ่งต่าง ๆ เช่นการเพิ่ม 5 คลาสที่แตกต่างกันสำหรับผู้ใช้แต่ละคนซึ่งจะช่วยให้ฉันทำงาน QOS ที่ดีจริง ๆ (เช่นการจัดการสตรีมและการรับส่งข้อมูลเรียลไทม์แยกต่างหาก) แต่ส่วนใหญ่คิดไม่ถึงในสภาพปัจจุบัน กรณีการใช้งานในปัจจุบันของจุดปลาย ~ 20k ฉันจะเกินขีด จำกัด แล้ว)
exa

1
ตกลงเพื่อส่งต่อ 10Gbits ไม่ใช่ปัญหาใด ๆ ปัญหาคือมีตัวกรองและคลาส 64k * 2 (อัพดาวน์) จำนวนมาก ขอให้โชคดี: D
Pabluez

0

คุณสามารถแยกการจัดการทราฟฟิกเป็นสองเครื่อง (ใช้อันที่สาม) แทนการจัดการทราฟฟิกทั้งหมดในเครื่องเดียว การรับส่งข้อมูลสามารถกำหนดเส้นทางได้อย่างง่ายดายตามที่อยู่ IP ต้นทาง ดังนั้นคุณจะมีผู้ใช้ที่ดีที่สุด 10k หากคุณสามารถแบ่งช่วง IP อย่างสม่ำเสมอ

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.