ความน่าเชื่อถือ 99.9999999% (เก้าเก้า) ของ Erlang

มีรายงานว่าErlangถูกใช้ในระบบการผลิตมานานกว่า 20 ปีโดยมีเปอร์เซ็นต์เวลาทำงาน 99.9999999%

ฉันทำคณิตศาสตร์ดังต่อไปนี้:

20*365.25*24*60*60*(1 - 0.999999999) == 0.631 s

นั่นหมายความว่าระบบมีเวลาหยุดทำงานน้อยกว่าหนึ่งวินาทีในช่วง 20 ปี ฉันไม่ได้พยายามที่จะท้าทายความถูกต้องของสิ่งนี้ฉันแค่อยากรู้ว่าเราจะปิดระบบได้อย่างไร (โดยตั้งใจหรือโดยบังเอิญ) เพียง 0.631 วินาที ใครที่คุ้นเคยกับระบบซอฟต์แวร์ขนาดใหญ่ช่วยอธิบายเรื่องนี้ให้เราฟังได้ไหม ขอบคุณ.

ไม่มีใครรู้วิธีคำนวณเวลาหยุดทำงานของบริการบนคลัสเตอร์ของหน่วยประมวลผล (หรือเครื่องจักร)

ตัวเลขความน่าเชื่อถือไม่ควรวัดเวลาทั้งหมดของAXD301(โครงการที่มีปัญหา) เคยปิดตัวลงมานานกว่า 20 ปี ซึ่งแสดงถึงเวลาทั้งหมดในช่วง 20 ปีที่ระบบให้บริการAXD301แบบออฟไลน์ ความแตกต่างที่ลึกซึ้ง ดังที่ Joe Armstrong กล่าวไว้ที่นี่ :

AXD301 มีความน่าเชื่อถือเก้าเก้า (ใช่คุณอ่านถูกต้อง 99.9999999%) ลองใส่สิ่งนี้ในบริบท: 5 เก้าถูกคิดว่าดี (เวลาหยุดทำงาน 5.2 นาที / ปี) 7 เก้าแทบไม่น่าเชื่อ ... แต่เราทำได้ 9

ทำไมถึงเป็นแบบนี้? ไม่มีสถานะที่ใช้ร่วมกันรวมทั้งโมเดลการกู้คืนข้อผิดพลาดที่ซับซ้อน

หากคุณเจาะลึกลงไปอีกนิดในวิทยานิพนธ์ปริญญาเอกที่เขียนโดยโจผู้เขียนต้นฉบับของ Erlang (ซึ่งรวมถึงกรณีศึกษาAXD301) คุณอ่าน:

หนึ่งในโครงการที่ศึกษาในบทนี้คือ Ericsson AXD301 สวิตช์ ATM ประสิทธิภาพสูงที่มีความน่าเชื่อถือสูง

ดังนั้นตราบเท่าที่เครือข่ายที่สวิตช์เป็นส่วนหนึ่งของการทำงานโดยไม่มีเวลาหยุดทำงานผู้เขียนสามารถระบุ "เก้าเก้าความน่าเชื่อถือ" สำหรับAXD301(ซึ่งก็คือทั้งหมดที่เขาเคยพูดโดยหลีกเลี่ยงข้อมูลจำเพาะ) ไม่ได้แปลว่า Erlang เป็นสาเหตุเดียวของความน่าเชื่อถือสูงเช่นนี้

แก้ไข: อันที่จริง "20 ปี" ดูเหมือนจะเป็นการตีความที่ผิด โจกล่าวถึงตัวเลข 20 ปีในบทความเดียวกัน แต่จริงๆแล้วมันไม่ได้เชื่อมโยงกับตัวเลขความน่าเชื่อถือเก้าเก้าซึ่งอาจมาจากการศึกษาที่สั้นกว่ามาก (ตามที่คนอื่น ๆ กล่าวถึง)

ในขณะที่คนอื่นพูดถึงกรณีเฉพาะที่คุณกำลังถามคำถามของคุณดูเหมือนจะมาจากความเข้าใจผิด วิธีที่คุณถามคำถามนี้ทำให้ฉันเชื่อว่าคุณกำลังคิดว่ามีขั้นตอนด้วยตนเองในการทำให้ระบบทำงานอีกครั้งหลังจากที่เกิดปัญหาหรือถูกนำออกไปเพื่อการบำรุงรักษา

Erlang มีคุณสมบัติหลายประการที่ลบเวลาการทำงานของมนุษย์อันเป็นสาเหตุของการหยุดทำงาน:

1. โหลดรหัสร้อน ในระบบ Erlang ง่ายต่อการรวบรวมและโหลดโมดูลทดแทนสำหรับโมดูลที่มีอยู่ โปรแกรมจำลอง BEAM จะทำการสลับโดยอัตโนมัติโดยไม่ได้หยุดอะไรเลย ไม่ต้องสงสัยเลยว่ามีช่วงเวลาเล็กน้อยที่การถ่ายโอนนี้เกิดขึ้น แต่จะเกิดขึ้นโดยอัตโนมัติในเวลาคอมพิวเตอร์แทนที่จะเป็นเวลามนุษย์ด้วยตนเอง ซึ่งทำให้สามารถอัพเกรดได้โดยไม่มีเวลาหยุดทำงานเป็นหลัก (คุณอาจหยุดทำงานได้หากโมดูลทดแทนมีข้อบกพร่องที่ทำให้ระบบขัดข้อง แต่นั่นเป็นเหตุผลที่คุณทดสอบก่อนที่จะปรับใช้กับการผลิต)

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

3. กระบวนการ สิ่งเหล่านี้สอดคล้องกับเธรดในภาษาอื่น ๆ โดยประมาณยกเว้นว่าจะไม่แชร์สถานะยกเว้นผ่านที่เก็บข้อมูลถาวร นอกเหนือจากนั้นการสื่อสารเกิดขึ้นผ่านการส่งข้อความ เนื่องจากกระบวนการ Erlang มีราคาไม่แพงมาก (ถูกกว่าเธรด OS มาก) สิ่งนี้จึงกระตุ้นให้เกิดการออกแบบควบคู่กันไปอย่างหลวม ๆ ดังนั้นหากกระบวนการตายลงเพียงส่วนเล็ก ๆ ของระบบจะประสบกับการหยุดทำงาน โดยปกติหัวหน้างานจะรีสตาร์ทกระบวนการนั้นใหม่โดยไม่มีผลกระทบต่อส่วนที่เหลือของระบบเพียงเล็กน้อยหรือไม่มีเลย

4. ข้อความผ่านไม่ตรงกัน เมื่อกระบวนการหนึ่งต้องการบอกอีกสิ่งหนึ่งมีตัวดำเนินการชั้นหนึ่งในภาษาเออร์แลงที่ให้มันทำเช่นนั้น กระบวนการส่งข้อความไม่จำเป็นต้องรอให้ผู้รับประมวลผลข้อความและไม่จำเป็นต้องประสานการเป็นเจ้าของข้อมูลที่ส่ง ลักษณะการทำงานแบบอะซิงโครนัสของระบบส่งข้อความของ Erlang จะดูแลทั้งหมดนั้น สิ่งนี้ช่วยรักษาเวลาทำงานให้สูงขึ้นเนื่องจากช่วยลดผลกระทบที่การหยุดทำงานในส่วนหนึ่งของระบบอาจมีต่อส่วนอื่น ๆ

5. การจัดกลุ่ม สิ่งนี้ต่อจากจุดก่อนหน้า: กลไกการส่งข้อความของ Erlang ทำงานอย่างโปร่งใสระหว่างเครื่องบนเครือข่ายดังนั้นกระบวนการส่งจึงไม่จำเป็นต้องสนใจว่าเครื่องรับจะอยู่ในเครื่องแยกต่างหาก สิ่งนี้เป็นกลไกที่ง่ายในการแบ่งภาระงานระหว่างเครื่องจำนวนมากซึ่งแต่ละเครื่องสามารถลงแยกกันได้โดยไม่เป็นอันตรายต่อเวลาทำงานโดยรวมของระบบ

ตัวเลขความพร้อมใช้งาน 99.9999999% เป็นสถิติที่มักอ้างถึง แต่โดยพื้นฐานแล้วทำให้เข้าใจผิด Mats Cronqvist หนึ่งในสมาชิกทีม AXD-301 ได้นำเสนอ (วิดีโอ) (ซึ่งฉันเข้าร่วม) ในการประชุม Erlang Factory ปี 2010 ที่ซานฟรานซิสโกโดยพูดถึงสถิติความพร้อมที่แม่นยำนี้ ตามที่เขากล่าวอ้างโดย British Telecom สำหรับช่วงทดลองใช้งาน (ฉันเชื่อว่าตั้งแต่เดือนมกราคมถึงกันยายน 2545) เป็น "5 ปีโหนด" โดยใช้ AXD-301 มี 14 โหนดที่มีปริมาณการใช้งานจริงเมื่อสิ้นสุดการทดลองใช้

Cronqvist ระบุเป็นพิเศษว่านี่ไม่ได้เป็นตัวแทนของประวัติ AXD-301 ทั้งหมดหรือ Erlang โดยทั่วไปและเขาไม่พอใจที่ Joe Armstrong ยังคงอ้างถึงสิ่งนี้ซึ่งนำไปสู่ความคาดหวังที่มากเกินไปเกี่ยวกับความน่าเชื่อถือของ Erlang คนอื่น ๆ เขียนว่าเก้าเก้าเป็นรูปที่เหมือนจริงมากขึ้น

ควรระบุว่าฉันเป็นผู้สนับสนุนและพัฒนา Erlang ที่กระตือรือร้นซึ่งเชื่อว่าการใช้ Erlang อย่างเชี่ยวชาญสามารถนำไปสู่ระบบที่มีอยู่สูงมาก แต่ต้องการลดการโฆษณา แน่นอนฉันคิดว่าการเป็นตัวแทนของ Cronqvist นั้นถูกต้องและไม่มีเหตุผลที่จะเชื่อเป็นอย่างอื่น

ความเข้าใจของฉันเกี่ยวกับสถิติเหล่านั้นคือคำนวณจากระบบ AXD301 ทั้งหมดในการผลิต เราสามารถคาดหวังได้ว่าเมื่อ AXD301 มีปัญหารุนแรงมันจะหยุดทำงานนานกว่า 0.631 วินาที ในระหว่างขั้นตอนนี้ AXD301 อื่น ๆ จะเข้ามาควบคุมเพื่อให้เครือข่ายทำงานต่อไป

อย่างไรก็ตามเมื่อคุณรวมจำนวนชั่วโมงทั้งหมดของ AXD301 ที่รันทั้งหมดให้สร้างอัตราส่วนสำหรับ AXD301 ที่ล้มเหลวคุณจะพบ 99.999999%

นั่นคือสิ่งที่ฉันเข้าใจตัวเลขนี้

หวังว่าจะช่วยได้