คู่มือเกมแลค › L5 อุปกรณ์เครือข่ายในดาต้าเซ็นเตอร์
idle timeout ของโหลดบาลานเซอร์ Load balancer idle timeout
ID สาเหตุ dc-lb-idle · ผู้รับผิดชอบหลัก อินฟราเครือข่าย (ทีมอินฟรา) · ร่วมกับ พัฒนาไคลเอนต์ (ทีมพัฒนาเกม), พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
โหลดบาลานเซอร์ลบการเชื่อมต่อที่ idle ทิ้งหลังผ่านไประยะหนึ่ง ฝั่งเกมยังคิดว่าการเชื่อมต่อยังอยู่ จนกระทั่งหลุด
ทำไม ผู้เล่นไม่ส่งแพ็กเก็ตใด ๆ อยู่พักหนึ่ง (เปิดหน้าต่างสนทนา, ไม่อยู่หน้าจอ) → ผลคือ โหลดบาลานเซอร์เก็บกวาดการเชื่อมต่อที่ idle (ค่าเริ่มต้นที่พบบ่อย 60–350 วินาที) → บนหน้าจอ หลุดทันทีที่กลับมาขยับอีกครั้ง
- อาการ
- หลุด
- ปัจจัย
- แพ็กเก็ตหาย
- ใครเจอ
- เราคนเดียว, ทั้งเซิร์ฟเวอร์
- เกิดเมื่อไร
- หลังอยู่เฉย ๆ สักพัก
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก อินฟราเครือข่าย (ทีมอินฟรา) · ร่วมกับ พัฒนาไคลเอนต์ (ทีมพัฒนาเกม), พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
- งานฝั่งทีมพัฒนาเกม
- ไคลเอนต์: ส่ง heartbeat ทุกช่วงไม่เกินครึ่งหนึ่งของ idle timeout ที่สั้นที่สุด (ถ้าอยู่หลัง ALB ที่ 60 วินาที ก็ไม่เกิน 30 วินาที), เชื่อมต่อใหม่อัตโนมัติเมื่อหลุด เซิร์ฟเวอร์: ตอบ heartbeat และถ้าไม่ได้รับตามเวลาที่กำหนดให้เก็บกวาดการเชื่อมต่อก่อน, ใช้ session token รับต่อ
- งานฝั่งทีมอินฟรา
- ตรวจค่า idle timeout ของโหลดบาลานเซอร์ในเส้นทางแล้วแชร์ให้ทีมพัฒนาเกม และเพิ่มค่าถ้าจำเป็น
- ตัวเลขที่ควรรู้
- ค่าเริ่มต้นของ AWS ALB คือ 60 วินาที, NLB คือ TCP 350 วินาทีและ UDP 120 วินาที, Azure Load Balancer คือ TCP 4 นาที ค่า TCP ของ ALB และ NLB ปรับได้ แต่ UDP 120 วินาทีของ NLB ปรับไม่ได้ เมื่อครบเวลา ALB จะปิดการเชื่อมต่อฝั่งเซิร์ฟเวอร์ด้วย ส่วน NLB ลบทิ้งเงียบ ๆ การเชื่อมต่อจึงมักยังเหลืออยู่ฝั่งเซิร์ฟเวอร์โดยที่เซิร์ฟเวอร์ไม่รู้
- บนกราฟ
- การเชื่อมต่อหลุดพร้อมกัน · จำนวนครั้งที่หลุด, ระยะเวลา idle ก่อนหลุด
- จุดที่ต้องดู
- ตรวจค่า idle timeout ที่ตั้งไว้ของโหลดบาลานเซอร์ในเส้นทาง แล้วรวบรวมเวลาตั้งแต่แพ็กเก็ตสุดท้ายจนหลุดของแต่ละการเชื่อมต่อที่หลุด ถ้าเป็น AWS NLB ให้ดู TCP_ELB_Reset_Count (จำนวน RST ที่โหลดบาลานเซอร์ส่ง) ใน CloudWatch ด้วย
- สัญญาณว่าใช่
- ระยะเวลา idle ของการเชื่อมต่อที่หลุดกระจุกอยู่หลังค่าที่ตั้งไว้พอดี (ALB 60 วินาที, NLB TCP 350 วินาที ฯลฯ) และทำซ้ำได้เมื่ออยู่เฉย ๆ นานกว่านั้นแล้วขยับ ถ้าเป็น NLB TCP_ELB_Reset_Count จะเพิ่มในเวลานั้น
- สัญญาณว่าไม่ใช่
- ถ้าหลุดโดยไม่เกี่ยวกับระยะเวลา idle ก็ไม่ใช่สาเหตุนี้ ถ้าเซิร์ฟเวอร์ที่ผู้เล่นเชื่อมต่อตรงโดยไม่มีโหลดบาลานเซอร์หลุดกระจุกแถว 350 วินาที น่าจะเป็น “connection tracking ของ security group บนคลาวด์หมดอายุ” ถ้าเป็นฝั่งเราเตอร์ที่บ้านผู้เล่น น่าจะเป็น “NAT mapping หมดอายุ”
- วิธีตรวจ
- ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
แหล่งอ้างอิง
- Edit attributes for your Application Load Balancer AWS
idle timeout ของ ALB ค่าเริ่มต้น 60 วินาที (1–4,000 วินาที) ถ้าการเชื่อมต่อฝั่งไคลเอนต์หรือฝั่ง target เงียบตลอดช่วงนี้ โหลดบาลานเซอร์จะปิดการเชื่อมต่อ - Network Load Balancers AWS
idle timeout ของ TCP ใน NLB ค่าเริ่มต้น 350 วินาที (60–6,000 วินาที) เมื่อเลยไปจะหยุดติดตามเท่านั้น ถ้ามีข้อมูลมาหลังจากนั้นจะตอบด้วย RST, flow ของ UDP 120 วินาทีปรับไม่ได้ - Configure load balancer TCP reset and idle timeout Microsoft Azure
idle timeout ของ Azure Load Balancer ค่าเริ่มต้น 4 นาที (4–100 นาที) ถ้าเกินจะไม่รับประกันว่าเซสชันยังอยู่, TCP reset เป็นตัวเลือกที่เปิดเพิ่มได้ - CloudWatch metrics for your Network Load Balancer AWS
TCP_ELB_Reset_Count: จำนวนแพ็กเก็ต RST ที่โหลดบาลานเซอร์สร้างและส่งออกไป
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: L5 อุปกรณ์เครือข่ายในดาต้าเซ็นเตอร์
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (หลุด)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง