한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

คู่มือเกมแลค › L13 สถาปัตยกรรมเซิร์ฟเวอร์และการดูแลระบบ

นาฬิการะหว่างเซิร์ฟเวอร์ไม่ตรงกัน Clock skew between servers

ID สาเหตุ in-clock-skew · ผู้รับผิดชอบหลัก อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)

เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →

ถ้านาฬิกาของแต่ละเซิร์ฟเวอร์ต่างกันเล็กน้อย การตัดสินคูลดาวน์, บัฟ และเวลาเริ่มอีเวนต์จะไม่ตรงกันระหว่างเซิร์ฟเวอร์

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

อาการ
กดไม่ติด/โรลแบ็ค
ปัจจัย
ความหน่วง
ใครเจอ
เราคนเดียว
เกิดเมื่อไร
ระหว่างเดินทาง/ย้ายแมพ
ผู้รับผิดชอบ
ผู้รับผิดชอบหลัก อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
งานฝั่งทีมพัฒนาเกม
ส่งเวลาที่เหลือระหว่างเซิร์ฟเวอร์ แทนเวลาสัมบูรณ์
งานฝั่งทีมอินฟรา
มอนิเตอร์การซิงก์เวลา (NTP, chrony), ตั้ง alert เมื่อนาฬิการะหว่างเซิร์ฟเวอร์ต่างกัน
ตัวเลขที่ควรรู้
ถ้าการซิงก์เวลา (NTP, chrony) ปกติ เซิร์ฟเวอร์ในดาต้าเซ็นเตอร์เดียวกันมักต่างกันไม่เกินไม่กี่ ms แต่ถ้าการซิงก์หยุด หรือ VM หยุดไปนานแล้วกลับมาทำงาน จะห่างกันหลายร้อย ms ถึงหลายวินาที
บนกราฟ
ค่อย ๆ สูงขึ้น · offset ของนาฬิกาแยกตามเซิร์ฟเวอร์
จุดที่ต้องดู
รวบรวม System time (ส่วนต่างระหว่างนาฬิการะบบกับนาฬิกา NTP), Last offset และ Ref time (เวลาที่นำค่าวัดล่าสุดจากแหล่งเวลามาใช้) จาก chronyc tracking ของแต่ละเซิร์ฟเวอร์มาเทียบกัน
สัญญาณว่าใช่
offset ของเซิร์ฟเวอร์ที่มีปัญหาห่างจากเซิร์ฟเวอร์อื่นตั้งแต่หลายร้อย ms ขึ้นไป หรือ Ref time หยุดอยู่ที่เวลานานมาแล้ว และการตัดสินคลาดเคลื่อนเกิดเฉพาะเมื่อย้ายเข้าออกเซิร์ฟเวอร์นั้น
สัญญาณว่าไม่ใช่
offset ของทุกเซิร์ฟเวอร์อยู่ในหลักหน่วย ms: น่าจะเป็นการคำนวณเวลาฝั่งเกม หรือซิงก์นาฬิกาคลาดเคลื่อนฝั่งไคลเอนต์
วิธีตรวจ
ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
รายละเอียดเพิ่มเติม
กรณีที่นาฬิกาของเซิร์ฟเวอร์เครื่องหนึ่งกระโดดไปข้างหน้าหรือถอยหลังทีเดียว อธิบายไว้ในการ์ด “นาฬิการะบบกระโดด (NTP step)” ของชั้น OS ของเซิร์ฟเวอร์

แหล่งอ้างอิง

  1. RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification IETF
    NTP client บน LAN ความเร็วสูงมักตรงกันภายในหลายร้อย µs
  2. chrony – Frequently Asked Questions chrony
    drift ของนาฬิกาคอมพิวเตอร์ทั่วไปต่ำกว่า 100 ppm แต่ VM อาจมากกว่านั้น, VM ที่ถูก pause แล้ว resume อาจเวลาคลาดจนต้องแก้แบบ step
  3. clock_gettime(2) — Linux manual page Linux man-pages
    CLOCK_REALTIME อาจกระโดดไม่ต่อเนื่องจากการแก้เวลาด้วยมือหรือการปรับของ NTP ส่วน CLOCK_MONOTONIC ไม่ได้รับผลจากการกระโดดแบบนั้น
  4. chronyc(1) chrony
    System time (ส่วนต่างระหว่างนาฬิกา NTP กับนาฬิการะบบ), Last offset (offset ที่ประมาณไว้ตอนปรับครั้งล่าสุด), Ref time (เวลาที่นำค่าวัดล่าสุดจากแหล่งเวลามาใช้) ของ chronyc tracking

สาเหตุที่ควรดูประกอบ

ชั้นเดียวกัน: L13 สถาปัตยกรรมเซิร์ฟเวอร์และการดูแลระบบ

สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (กดไม่ติด/โรลแบ็ค)

ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง