OpenVPN ต้องใช้กี่คอร์? ขึ้นอยู่กับเส้นทาง

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

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

หนึ่งคอร์ต่อหนึ่งการไหลบนเส้นทางพื้นที่ผู้ใช้

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

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

อีกเส้นทางหนึ่ง: แพ็กเก็ตในเคอร์เนล

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

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

การเปรียบเทียบตัดสินอะไรจริง ๆ

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

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

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

วัดเพื่อให้ตัวเลขมีความหมาย

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

จากนั้นเหลือที่ว่างสำหรับแชนเนลควบคุม การเจรจาใหม่ และทุกสิ่งอื่นที่ทำงานบนโฮสต์

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