ความเกี่ยวข้องของ ECMP และความคงอยู่

การกำหนดเส้นทางแบบ Equal-Cost Multi-Path (ECMP) จะกระจายโฟลว์เครือข่าย แต่ไม่ได้มีความเข้าใจเกี่ยวกับผู้ใช้ คุกกี้ เซสชันการเข้าสู่ระบบ หรือธุรกรรมของแอปพลิเคชัน ให้ทำการออกแบบความคงอยู่ของแอปพลิเคชัน (application persistence) ที่เลเยอร์ที่รับรู้ในระดับแอปพลิเคชัน (application-aware layer) แทนที่จะถือว่าแฮช ECMP ที่มีความเสถียรเป็นฟีเจอร์ความคงอยู่

แฮชจะระบุโฟลว์ ไม่ใช่ผู้ใช้

เราเตอร์หลายตัวจะเลือกเส้นทางที่มีต้นทุนเท่ากันจากฟิลด์ต่างๆ ในส่วนหัวของอินเทอร์เน็ตโปรโตคอล (IP) และโปรโตคอลการขนส่ง (transport headers) ข้อมูลนำเข้าทั่วไปคือ 5-tuple ซึ่งประกอบไปด้วย: ที่อยู่ต้นทาง, ที่อยู่ปลายทาง, โปรโตคอล, พอร์ตต้นทาง และพอร์ตปลายทาง โดยฟิลด์ข้อมูลที่แน่นอน ค่าสุ่ม (seed) และพฤติกรรมการทำงานจะมีความเฉพาะเจาะจงไปตามแต่ละแพลตฟอร์ม

แพ็กเก็ตที่มีฟิลด์ที่เลือกเหมือนกันตามปกติจะใช้เส้นทางเดียวกันในขณะที่ชุด ECMP มีความเสถียร การเชื่อมต่อใหม่อาจใช้พอร์ตต้นทางที่แตกต่างกัน ส่งผลให้เลือก CE อื่นได้ ทั้ง HTTP/1.0, HTTP/1.1, HTTP/2, การนำการเชื่อมต่อเบราว์เซอร์กลับมาใช้ใหม่, พร็อกซี และ Network Address Translation (NAT) ล้วนเปลี่ยนจำนวนการเชื่อมต่อการขนส่งที่เป็นตัวแทนของเซสชันผู้ใช้รายเดียวที่ปรากฏ

พฤติกรรมดังกล่าวเป็นเพียงความเกี่ยวข้องในระดับโฟลว์ (flow affinity) เท่านั้น ไม่ใช่ความคงอยู่ของที่อยู่ต้นทาง (source-address persistence), ความคงอยู่ของคุกกี้ (cookie persistence) หรือการจำลองสถานะเซสชัน (session-state replication)

การละเว้นพอร์ตต้นทางจะเปลี่ยนข้อแลกเปลี่ยน

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

การกำหนดค่านี้ยังคงไม่สามารถรับประกันความคงอยู่ของแอปพลิเคชันได้:

• การเปลี่ยนแปลงชุดเส้นทางสามารถแมปแฮชใหม่ได้;
• ความล้มเหลวของ CE จะย้ายทราฟฟิกใหม่ไปยัง CE อื่น;
• ที่อยู่ของไคลเอ็นต์สามารถเปลี่ยนแปลงได้;
• เราเตอร์ไม่ได้คัดลอกสถานะแอปพลิเคชันระหว่าง CE ต่างๆ

อย่ากำหนดแฮชแบบเดียวสำหรับทุกเครือข่าย

การควบคุมแฮชและค่าเริ่มต้นจะแตกต่างกันไปตามเราเตอร์ เลือกฟิลด์ข้อมูลหลังจากวัดผลรูปแบบไคลเอ็นต์, NAT, โปรโตคอล และรูปแบบการนำการเชื่อมต่อกลับมาใช้ใหม่ที่คาดไว้เท่านั้น การเปลี่ยนแปลงที่ปรับปรุงความเกี่ยวข้องแบบหยาบ (coarse affinity) อาจทำให้เกิดความไม่สมดุลของโหลดอย่างรุนแรง

กำหนดความคงอยู่ที่เข้มงวดไว้ที่เลเยอร์ที่ถูกต้อง

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

ระบุข้อกำหนดอย่างแม่นยำ:

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

ตรวจสอบด้วยทราฟฟิกจริง ไม่ใช่ข้อสมมติฐาน

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

สำหรับด้านการกำหนดเส้นทางของการเปลี่ยนแปลงชุดเส้นทาง โปรดดู การกำหนดเส้นทางและการถ่ายโอนข้อมูลเมื่อเกิดความล้มเหลว

ข้อมูลอ้างอิงมาตรฐาน

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