Meta แพตช์ Linux ขนาดมหาศาลได้อย่างไร

 (thenewstack.io)
8 คะแนน โดย GN⁺ 2023-12-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การแพตช์เซิร์ฟเวอร์ Linux นั้นเป็นเรื่องง่าย แต่การแพตช์เซิร์ฟเวอร์หลายหมื่นเครื่องโดยไม่มี downtime ไม่ใช่เรื่องง่าย
  • Meta ใช้ Kpatch และ KLP (Kernel Live Patching) ของ Red Hat เพื่อแพตช์เซิร์ฟเวอร์ Linux หลายล้านเครื่อง
    • KLP สามารถนำอัปเดตความปลอดภัยล่าสุดไปใช้กับเคอร์เนล Linux ได้โดยไม่ต้องรีบูต

การแพตช์เคอร์เนลแบบสด

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

Kpatch

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

ในกรณีของ Meta

  • แน่นอนว่าในความเป็นจริงมันไม่ได้ง่ายขนาดนั้น
  • ที่ Meta การใช้ไลฟ์แพตช์กับโฮสต์โดยทั่วไปใช้เวลา 1–2 วินาที
  • เวลา 1–2 วินาทีต่อโฮสต์นั้นเร็วมากเมื่อเทียบกับ kexec ซึ่งเป็นกลไกของเคอร์เนล Linux สำหรับบูตเคอร์เนลใหม่
  • ไม่จำเป็นต้องมี downtime หรือย้าย workload เพียงแค่นำไลฟ์แพตช์ไปใช้ก็พร้อมใช้งานได้ทันที

วิธีแพตช์เครื่องหลายล้านเครื่อง

  • เมื่อแพตช์เครื่องหลายล้านเครื่อง เรื่องราวไม่ได้จบแค่นี้
  • ที่ Meta อาจพบบั๊กระหว่างการ rollout แพตช์ ดังนั้นผู้ดูแลระบบจึงแพตช์จาก release candidate tier ก่อน
  • Package roller ที่จัดส่งแพตช์แบบ RPM-based จะตรวจสอบสุขภาพของเซิร์ฟเวอร์โดยอัตโนมัติด้วย
  • Meta เฝ้าติดตามการแครช การแจ้งเตือนสำคัญ ปัญหาแอปพลิเคชัน และประสิทธิภาพบนเคอร์เนลใหม่ และหากอัตราข้อผิดพลาดเกิน 1 การแครชต่อเซิร์ฟเวอร์ 1,000 เครื่อง แพตช์จะถูกหยุดและย้อนกลับไปยังเคอร์เนลก่อนหน้า
  • Meta ใช้ Kpatch แต่ก็มีทางเลือกอื่นเช่นกัน
    • SUSE มี kGraft, Oracle ใช้ Ksplice และ Canonical รองรับ Livepatch
    • ไม่ว่าจะเป็นโค้ดแบบใด ทั้งหมดก็ให้ผลลัพธ์ที่คล้ายกัน

ความเห็นของ GN⁺

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-12-05
ความคิดเห็นบน Hacker News
  • Ksplice คือเทคโนโลยีแพตช์แบบสดดั้งเดิมที่ภายหลัง Oracle เข้าซื้อกิจการ และในช่วงที่ฉันทำงานอยู่มันได้ขยายไปสู่โปรแกรมใน user space ด้วย เป็นเทคโนโลยีที่เจ๋งมากและไม่ล้าสมัย แม้จะมีการย้ายไปสู่คลาวด์ เพราะไม่จำเป็นต้องรีสตาร์ตทั้งระบบในวงกว้าง
  • การที่ Meta ไม่ได้พูดถึงว่าต้องใช้เวลานานแค่ไหนในการทำให้ครอบคลุมทั้งดีพลอยเมนต์ด้วยวิธีนี้ ดูเหมือนจะตกหล่นรายละเอียดสำคัญไป การใช้ live patching ทำให้สามารถดำเนินงานได้โดยไม่มี downtime ของเซิร์ฟเวอร์ ดาต้าเซ็นเตอร์ หรือคลาวด์
  • หากคุณทำงานในสเกลแบบ Meta การทำ live patching ก็อาจสมเหตุสมผล แต่บริการและแอปพลิเคชันส่วนใหญ่ที่ออกแบบมาดีควรจะทนต่อการรีบูตเซิร์ฟเวอร์ทั้งเครื่องได้ ความซับซ้อนของการจัดการเซิร์ฟเวอร์หลายล้านเครื่องนั้นยากจะจินตนาการ
  • KernelCare คือบริการสำหรับทำ kernel live patching ที่รองรับลินุกซ์ดิสทริบิวชันส่วนใหญ่
  • ฉันเคยใช้ Kpatch กับ virtual machine จำนวนมาก และมันทำงานได้ค่อนข้างดี
  • ตอนนี้พวกเขารันเซิร์ฟเวอร์อยู่ราว 13 ล้านเครื่อง และวางแผนใช้เงิน 2 หมื่นล้านดอลลาร์กับอุปกรณ์ดาต้าเซ็นเตอร์ใหม่ในปี 2023 และอีก 2 หมื่นล้านดอลลาร์ในปี 2024 ตอนนี้ใช้ CentOS 8 Stream อยู่ และจะย้ายไปเวอร์ชัน 9 เร็ว ๆ นี้
  • มีคนบอกว่าการ draining และ undraining โฮสต์เป็นเรื่องยาก ซึ่งในทางปฏิบัติหมายถึงการเอาโฮสต์ออกจากบริการและนำกลับคืนมาไม่ใช่เรื่องง่าย นั่นหมายความว่าเคอร์เนลลินุกซ์ไม่ได้ถูกออกแบบมาสำหรับ live patching และการพยายามทำแบบนั้นย่อมเป็นแหล่งของความไม่แน่นอนเสมอ อีกทั้งมีต้นทุนสูงในแง่งานวิศวกรรมและเสี่ยงต่อหายนะอยู่ตลอด ในทางกลับกัน การปรับปรุงระบบสำหรับ draining และกู้คืนบริการของโฮสต์ให้แข็งแกร่งและเชื่อถือได้มาก จะให้ประโยชน์ด้านความน่าเชื่อถืออย่างมาก แนวทางนี้ดูเหมือนเป็นการปกปิดความบกพร่องเชิงหน้าที่ขององค์กร ทีมหนึ่งอาจแพตช์เคอร์เนลทั้งหมดได้ แต่การทำให้ทุกโฮสต์รองรับการ draining และกู้คืนบริการนั้นเป็นไปไม่ได้ และเพราะไม่มีแรงจูงใจจริงในการแก้ไข จึงไม่มีใครพยายามแก้ มีแต่การแฮ็กเท่ ๆ และโปรเจกต์ใหม่ ๆ เท่านั้นที่ได้รับผลตอบแทนอย่างเหมาะสม
  • องค์กรส่วนใหญ่ไม่ได้ประโยชน์จากการเลียนแบบ Meta และก็ไม่จำเป็นต้องทำเช่นนั้น
  • เพิ่งเคยได้ยินแนวคิดเรื่อง "hyperscale" เป็นครั้งแรก เลยสงสัยว่ามันต่างจากการขยายระบบตามปกติอย่างไร