Tags:
Node Thumbnail

GitHub รายงานเหตุการณ์เว็บล่มเมื่อวันที่ 22 ตุลาคมที่ผ่านมา พร้อมกับระบุถึงบทเรียนที่ได้จากการล่มครั้งนี้

เรื่องทั้งหมดเริ่มจากการบำรุงรักษาอุปกรณ์ไฟเบอร์ 100G ที่เริ่มทำงานไม่เต็มประสิทธิภาพ โดยการเปลี่ยนอุปกรณ์ทำให้เน็ตเวิร์คที่เชื่อมระหว่างศูนย์ข้อมูลหลัก คือฝั่งตะวันตก (US West) และฝั่งตะวันออก (US East) ดับไปเป็นเวลา 43 วินาที

ระบบฐานข้อมูลของ GitHub ใช้คลัสเตอร์ MySQL โดยก่อนเน็ตเวิร์คดับ เซิร์ฟเวอร์หลัก (primary) ที่รับข้อมูลเขียนฐานข้อมูลอยู่ที่ US East โดยคลัสเตอร์ถูกควบคุมด้วย Orchestrator ของ GitHub เอง เมื่อเน็ตเวิร์คดับไป ตัว Orchestrator ก็พยายามเลือกเซิร์ฟเวอร์ในศูนย์ข้อมูล US West เป็นเซิร์ฟเวอร์หลักใหม่ และส่งข้อมูลการเขียนลงฐานข้อมูลไปยัง US West อย่างไรก็ตาม มีข้อมูลการเขียนส่วนหนึ่งที่ US East เขียนไปแล้ว ไม่กี่วินาที แต่ US West ไม่ได้รับ ทำให้คลัสเตอร์ไม่สามารถกลับมาซิงก์กันได้

ทีมงานตัดสินใจหยุดงานที่ต้องเขียนลงฐานข้อมูล เช่น การรับ push เพื่อรักษาความถูกต้องของข้อมูลเอาไว้ โดยสถานะสุดท้ายคือ US West มีข้อมูลที่ US East ไม่มีอยู่นาน 40 นาที ขณะที่ US East มีข้อมูลที่ US West ไม่มีอยู่ไม่กี่วินาที

หลังจากนั้นทางออกคือการสร้างคลัสเตอร์ขึ้นใหม่จากไฟล์แบ็กอัพ กระบวนการ restore ฐานข้อมูลขนาดใหญ่ปกติก็ใช้เวลาหลายชั่วโมงอยู่แล้ว แม้นโยบายของ GitHub จะสำรองฐานข้อมูลทุก 4 ชั่วโมงและทดสอบไฟล์สำรองอย่างน้อยวันละครั้ง แต่ก็ไม่เคยมีการซ้อมสร้างคลัสเตอร์ใหม่ทั้งหมดจริงๆ ทำให้ใช้เวลานาน และหลังจากกู้เรียบร้อยแล้วก็ยังต้องวิเคราะห์ล็อก MySQL ว่ามีข้อมูลอะไรผิดพลาดหรือไม่

ทาง GitHub ระบุว่าหลังจากนี้จะคอนฟิก Orchestrator ใหม่ ให้เลี่ยงการเลือกเซิร์ฟเวอร์หลักข้ามทวีป ซึ่งทำให้คลัสเตอร์แยกเป็นสองส่วนในครั้งนี้ ทาง GitHub เชื่อว่าการย้ายเซิร์ฟเวอร์หลักในโซนเดียวกันโดยปกติค่อนข้างปลอดภัย

ในระยะยาว ทางบริษัทมีแนวทางจะออกแบบให้ระบบทนทานมากขึ้นโดยเตรียมออกแบบ active/active/active แนวคิดคือศูนย์ข้อมูลหนึ่งสามารถล่มไปทั้งศูนย์ได้โดยผู้ใช้ยังไม่ได้รับผลกระทบ

ที่มา - GitHub Blog

No Description

Get latest news from Blognone

Comments

By: Mekokung
ContributorAndroidWindows
on 31 October 2018 - 19:46 #1079572
Mekokung's picture

ก่อนเน็ตเวิร์คับ

เน็ตเวิร์คดับ


Mekokung's Story บล็อกส่วนตัวที่ย้ายไป Blogger แล้วนะ

By: lancaster
Contributor
on 31 October 2018 - 20:02 #1079577

พี่ไม่คิดจะจับดาวน์หน่อยเหรอ นาทีเดียวเอง - -'

By: orbitalz
ContributorWindows PhoneAndroidUbuntu
on 31 October 2018 - 21:04 #1079589 Reply to:1079577

คงมั่นใจว่าระบบตัวเองคงเอาอยู่รึเปล่าครับ เลยไม่อยากดาวน์ระบบเพื่อแก้ปัญหา

By: lancaster
Contributor
on 1 November 2018 - 01:44 #1079622 Reply to:1079589

ยังไงมันก็ต้องล่มอยู่ดีอะครับ เพราะ primary มันมีได้ที่เดียว split brain เมื่อไรก็ต้องหยุด

ระหว่างสั่ง down ฝั่ง slave vs. ปล่อยให้มันจัดการเอง ถ้าทำได้ก็ควรเลือกสั่ง down ครับ

By: massacre
AndroidUbuntu
on 31 October 2018 - 20:05 #1079579

งั้นแสดงว่า active/passive แบบเปลี่ยน mode เป็น passive/active ได้ ไม่ work สิครับ เพราะเกิดปัญหาแบบนี้ จะทำให้ข้อมูลไม่ตรงกัน

แต่ถ้า active/passive แบบไม่ต้องเปลี่ยน mode แล้วถ้าข้อมูลไม่ตรง ก็แค่ สร้าง passive ตัวใหม่ ขึ้นมา หรือเปล่าครับ

By: icez
ContributoriPhoneAndroidRed Hat
on 1 November 2018 - 00:19 #1079612 Reply to:1079579

ใช่ครับ กรณี split brain ขึ้นมาทีนึงคือ consistency พังพินาศกันง่ายๆ เลย

By: semiauto
AndroidRed HatUbuntu
on 31 October 2018 - 20:25 #1079583

อ่าว ก็นึกว่าจะเปลี่ยนไปใช้ MSSQL ซะอีก

By: whitebigbird
Contributor
on 31 October 2018 - 20:54 #1079588
whitebigbird's picture

สรุป ไม่เกี่ยวกับไมโครซอฟท์

By: toooooooon
iPhoneWindows PhoneAndroidBlackberry
on 1 November 2018 - 09:44 #1079656 Reply to:1079588

นั่นสิ ดูเหมือนเป็นแพะไปละ...

By: parkpaya
Windows PhoneAndroidSymbianUbuntu
on 31 October 2018 - 21:55 #1079595

แสดงว่าถ้าทีมงานตัดสินใจหยุดงานที่ต้องเขียนลงฐานข้อมูลตั้งแต่แรก(มี downtime) ก็จะไม่ล่มนานขนาดนี้สินะครับ

By: icharge on 1 November 2018 - 01:37 #1079619

Github ไม่ได้ใช้พวก NoSQL หรอกหรอนี่

By: btoy
ContributorAndroidWindows
on 1 November 2018 - 08:20 #1079641
btoy's picture

เข้ามาเก็บความรู้ ^^


..: เรื่อยไป

By: TeamKiller
ContributoriPhone
on 1 November 2018 - 08:33 #1079643
TeamKiller's picture

Link ระหว่างกัน ไม่มีสำรองหรอเนี่ยถึง down ได้