คู่มือเกมแลค › L6 การ์ดเครือข่ายของเซิร์ฟเวอร์
การซ่อมบำรุงโฮสต์คลาวด์/live migration Cloud host maintenance / live migration
ID สาเหตุ nic-host-maintenance · ผู้รับผิดชอบหลัก อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม), ภายนอก (ภายนอก)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
เมื่อผู้ให้บริการคลาวด์ซ่อมบำรุงเครื่องจริง (โฮสต์) จะย้าย VM ไปโฮสต์อื่น (live migration) หรือหยุด VM ชั่วคราว ระหว่างนั้นทั้งเซิร์ฟเวอร์จะหยุด และถ้าหยุดนาน การเชื่อมต่อจะขาด
ทำไม ผู้ให้บริการย้าย VM ไปโฮสต์อื่นหรือพักการทำงานชั่วคราว เพราะซ่อมบำรุงโฮสต์หรือคาดว่าฮาร์ดแวร์จะเสีย → ผลคือ ระหว่างย้าย CPU หน่วยความจำ และเครือข่ายช้าลง และช่วงท้าย VM จะหยุดสนิทชั่วครู่ (ไม่ถึง 1 วินาทีจนถึงราว 30 วินาที ขึ้นกับผู้ให้บริการและวิธี) → บนหน้าจอ ทุกคนในเซิร์ฟเวอร์ค้างพร้อมกันแล้วกรอเร็วหรือวาร์ป ถ้าหยุดนานกว่าไทม์เอาต์ จะหลุดจำนวนมาก
อาการ ค้าง , กรอเร็ว , วาร์ป , หลุด ปัจจัย การหยุดชะงัก, แพ็กเก็ตหาย
ใครเจอ ทั้งเซิร์ฟเวอร์
เกิดเมื่อไร สุ่มเป็นครั้งคราว
ผู้รับผิดชอบ ผู้รับผิดชอบหลัก อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม), ภายนอก (ภายนอก)
งานฝั่งทีมพัฒนาเกม ตั้งไทม์เอาต์ที่ทนการหยุดหลายวินาทีได้, ตั้งเพดานจำนวนทิกที่เร่งคำนวณให้ทันหลังหยุด, คำนวณเวลาที่ผ่านไปด้วย monotonic clock, มีขั้นตอนบันทึกความคืบหน้าและย้ายผู้เล่นไปเซิร์ฟเวอร์อื่นเมื่อได้รับแจ้งการซ่อมบำรุง
งานฝั่งทีมอินฟรา สมัครรับและตั้ง alert การแจ้งซ่อมบำรุง (Google Cloud maintenance-event, AWS scheduled event และ AWS Health, Azure Scheduled Events), เมื่อได้รับแจ้งให้เปลี่ยนเซิร์ฟเวอร์ล่วงหน้าในช่วงที่ผู้เล่นน้อย, ปรับเวลาซ่อมบำรุงถ้าผู้ให้บริการอนุญาต (Azure Maintenance Configuration, AWS scheduled event บางประเภท), เทียบประวัติการซ่อมบำรุงกับบันทึกเหตุขัดข้อง
งานฝั่งภายนอก สอบถามผู้ให้บริการคลาวด์ถึงกำหนดการซ่อมบำรุงและขอบเขตผลกระทบ, แจ้งผู้ให้บริการถ้าอินสแตนซ์เดิมหยุดซ้ำ ๆ
ตัวเลขที่ควรรู้ Google Compute Engine ระบุว่าการหยุดระหว่าง live migration ปกติสั้นกว่า 1 วินาทีมาก และระหว่างหยุด นาฬิการะบบอาจกระโดดไปข้างหน้าได้สูงสุด 5 วินาที ค่า maintenance-event ใน metadata จะเปลี่ยน 60 วินาทีก่อนย้าย (กรณีที่เคยอ่านค่านี้ไว้อย่างน้อยหนึ่งครั้งก่อนหน้านั้น) Azure ระบุว่าการซ่อมบำรุงที่ไม่ต้องรีบูตแทบทุกครั้งหยุดไม่ถึง 10 วินาที นาน ๆ ครั้ง (ขนาดทั่วไปไม่เกินหนึ่งครั้งใน 18 เดือน) หยุดราว 30 วินาที และ live migration ปกติไม่เกิน 5 วินาที Azure Scheduled Events แจ้งการหยุดแบบนี้ (Freeze) ล่วงหน้าอย่างน้อย 15 นาที แต่ถ้าฮาร์ดแวร์ของโฮสต์เสียกะทันหัน จะเริ่มกู้คืนทันทีโดยไม่แจ้ง
บนกราฟ จุดที่ต้องดู เทียบเวลาที่หยุดกับบันทึกของผู้ให้บริการ Google Cloud ดู compute.instances.migrateOnHostMaintenance ใน audit log, AWS ดู scheduled event ใน describe-instance-status และ AWS Health, Azure ดูเวลาที่มี Microsoft.Compute/virtualMachines/liveMigration/action ใน Activity Log และเวลาที่เมตริกความพร้อมใช้งานของ VM (VmAvailabilityMetric) ลดลงเป็น 0 ภายในเซิร์ฟเวอร์ให้ดูว่าเมตริกและ log ว่างไปในช่วงที่หยุดหรือไม่ และนาฬิกากระโดดทันทีหลังจากนั้นหรือไม่ (log การซิงก์เวลา) สัญญาณว่าใช่ เวลาที่ทั้งเซิร์ฟเวอร์หยุดตรงกับเวลาซ่อมบำรุงหรือ migration ที่ผู้ให้บริการบันทึกไว้ และในไม่กี่วินาทีนั้นเมตริกและ log ในเซิร์ฟเวอร์ว่างหมด สัญญาณว่าไม่ใช่ ถ้าไม่มีในบันทึกของผู้ให้บริการ และมีการหยุดสั้น ๆ ซ้ำบ่อย น่าจะเป็น “CPU steal (VM)” ถ้า log ของเคอร์เนลมีประวัติรีเซ็ต NIC น่าจะเป็น “ปัญหาไดรเวอร์/เฟิร์มแวร์ของ NIC” วิธีตรวจ ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
รายละเอียดเพิ่มเติม AWS แจ้งผ่าน scheduled event โดย system-reboot หมายถึงรีบูตพร้อมย้ายไปโฮสต์ใหม่ และ system-maintenance หมายถึงอาจได้รับผลกระทบชั่วครู่จากการซ่อมบำรุงเครือข่ายหรือไฟฟ้า แม้จะหยุดแค่ไม่กี่วินาที ไคลเอนต์ที่ไม่ได้รับ ACK ของแพ็กเก็ตที่ส่งไปยังเซิร์ฟเวอร์ระหว่างนั้นจะเพิ่มเวลารอส่งซ้ำเป็นสองเท่าไปเรื่อย ๆ แม้เซิร์ฟเวอร์จะกลับมาทำงานแล้ว การเชื่อมต่อ TCP จึงอาจยังหยุดอยู่ต่ออีกพักหนึ่ง (“TCP RTO และ exponential backoff”) เมื่อตื่นจากการหยุด นาฬิกาอาจกระโดดจนกลายเป็น “นาฬิการะบบกระโดด (NTP step)” และ health check ของโหลดบาลานเซอร์อาจล้มเหลวจนถอดเซิร์ฟเวอร์นั้นออกชั่วคราว อินสแตนซ์ที่ย้ายไม่ได้ (เช่น bare metal instance ของ Google Cloud) จะถูกหยุดหรือเริ่มใหม่เมื่อมีการซ่อมบำรุง
แหล่งอ้างอิง Live migration process during maintenance events Google Cloud การหยุดระหว่าง live migration ปกติสั้นกว่า 1 วินาทีมาก, ระหว่างหยุดนาฬิการะบบกระโดดไปข้างหน้าได้สูงสุด 5 วินาที, ระหว่างย้าย ประสิทธิภาพดิสก์ CPU หน่วยความจำ และเครือข่ายลดลงชั่วครู่, VM ที่ไม่ใช้ live migration จะถูกปิดเมื่อซ่อมบำรุง (bare metal instance ไม่รองรับ) Query metadata server for maintenance event notices Google Cloud ค่า metadata ของ maintenance-event เปลี่ยน 60 วินาทีก่อน live migration (กรณีตั้งค่าเป็น live migration และเคยอ่านค่านี้อย่างน้อยหนึ่งครั้งหลังการซ่อมบำรุงครั้งก่อน) Monitor and plan for a host maintenance event Google Cloud เมื่อซ่อมบำรุงจะมี system event compute.instances.migrateOnHostMaintenance ใน audit log Scheduled events for Amazon EC2 instances AWS ประเภทของ scheduled event (system-reboot คือรีบูตพร้อมย้ายไปโฮสต์ใหม่, system-maintenance คือได้รับผลกระทบชั่วครู่จากการซ่อมบำรุงเครือข่ายหรือไฟฟ้า), แจ้งทางอีเมลและ AWS Health, ดูได้ด้วย describe-instance-status, บางประเภทปรับเวลาได้ Maintenance and updates Microsoft Azure การซ่อมบำรุงที่ไม่ต้องรีบูตแทบทุกครั้งหยุดไม่ถึง 10 วินาที, นาน ๆ ครั้ง (ขนาดทั่วไปไม่เกินหนึ่งครั้งใน 18 เดือน) ราว 30 วินาที, live migration ปกติไม่เกิน 5 วินาที, หลังหยุดนาฬิกาซิงก์อัตโนมัติ, การเชื่อมต่อ TCP ที่เปิดไว้นานอาจขาด หรืออีกฝั่งส่งซ้ำข้อมูลที่ส่งไปยัง VM ที่หยุดอยู่แบบ exponential backoff ทำให้กู้คืนช้าลงอีก, health check ของโหลดบาลานเซอร์ตัดสินว่าผิดปกติภายในราว 10 วินาที, ตรวจได้จาก Microsoft.Compute/virtualMachines/liveMigration/action ใน Activity Log และ VmAvailabilityMetric ที่เป็น 0 ระหว่างหยุด, เลือกเวลาที่จะใช้การซ่อมบำรุงได้ด้วย Maintenance Configuration Scheduled Events for Linux VMs in Azure Microsoft Azure Freeze (หยุดไม่กี่วินาที CPU และเครือข่ายอาจหยุด) แจ้งล่วงหน้าอย่างน้อย 15 นาที, กรณีฮาร์ดแวร์ของโฮสต์เสีย จะเริ่มกู้คืนทันทีโดยไม่มีช่วงแจ้งล่วงหน้า สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: L6 การ์ดเครือข่ายของเซิร์ฟเวอร์
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (ค้าง)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง