Độ tin cậy 99,9999999% (chín nines) của Erlang

Erlang được báo cáo đã được sử dụng trong các hệ thống sản xuất hơn 20 năm với tỷ lệ thời gian hoạt động là 99,9999999%.

Tôi đã làm phép toán như sau:

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

Điều đó có nghĩa là hệ thống chỉ có ít hơn một giây ngừng hoạt động trong khoảng thời gian 20 năm. Tôi không cố gắng thách thức tính hợp lệ của điều này, tôi chỉ tò mò về cách chúng ta có thể tắt một hệ thống (cố ý hoặc do vô tình) chỉ trong 0,631 giây. Có thể bất cứ ai quen thuộc với hệ thống phần mềm lớn giải thích điều này cho chúng tôi? Cảm ơn bạn.

Có ai biết cách tính thời gian ngừng hoạt động của một dịch vụ trên một cụm đơn vị xử lý (hoặc máy móc) không?

Con số độ tin cậy không được cho là để đo tổng thời gian bất kỳ phần nào của AXD301(dự án được đề cập) đã từng ngừng hoạt động trong hơn 20 năm. Nó thể hiện tổng thời gian trong 20 năm mà dịch vụ do AXD301hệ thống cung cấp đã từng ngoại tuyến. Sự khác biệt tinh tế. Như Joe Armstrong nói ở đây :

AXD301 đã đạt được độ tin cậy NINE nines (vâng, bạn đọc đúng, 99,9999999%). Hãy đặt điều này trong bối cảnh: 5 chín được cho là tốt (5,2 phút ngừng hoạt động / năm). 7 chín hầu như không thể đạt được ... nhưng chúng tôi đã làm được 9.

Tại sao thế này? Không có trạng thái được chia sẻ, cộng với một mô hình khôi phục lỗi phức tạp.

Nếu bạn tìm hiểu sâu hơn một chút, trong luận án Tiến sĩ được viết bởi Joe, tác giả gốc của Erlang (bao gồm một nghiên cứu điển hình AXD301), bạn đọc:

Một trong những dự án được nghiên cứu trong chương này là Ericsson AXD301, một thiết bị chuyển mạch ATM hiệu suất cao có độ tin cậy cao .

Vì vậy, miễn là mạng mà công tắc là một phần của nó đang chạy mà không có thời gian chết, tác giả có thể nêu "độ tin cậy chín chín" cho AXD301(đó là tất cả những gì anh ta từng nói, tránh các chi tiết cụ thể). Nó không nhất thiết có nghĩa là Erlang là nguyên nhân duy nhất của độ tin cậy cao như vậy.

CHỈNH SỬA: Trên thực tế, bản thân "20 năm" có vẻ như là một cách hiểu sai. Joe đề cập đến con số 20 năm trong cùng một bài báo, nhưng nó không thực sự liên quan đến con số độ tin cậy chín chín, có khả năng xuất phát từ một nghiên cứu ngắn hơn nhiều (như những người khác đã đề cập).

Trong khi những người khác đã giải quyết trường hợp cụ thể mà bạn đang hỏi, câu hỏi của bạn dường như dựa trên sự hiểu nhầm. Cách bạn đặt câu hỏi khiến tôi tin rằng bạn đang nghĩ rằng có một quy trình thủ công để hệ thống chạy lại sau khi nó gặp sự cố hoặc bị gỡ xuống để bảo trì.

Erlang có một số tính năng loại bỏ thời gian làm việc của con người như một nguồn thời gian chết:

1. Đang tải lại mã nóng . Trong hệ thống Erlang, có thể dễ dàng biên dịch và tải mô-đun thay thế cho mô-đun hiện có. Trình giả lập BEAM thực hiện việc hoán đổi tự động mà dường như không dừng lại bất cứ điều gì. Chắc chắn sẽ có một khoảng thời gian nhỏ mà quá trình chuyển này xảy ra, nhưng nó diễn ra tự động trong thời gian của máy tính, thay vì theo cách thủ công trong thời gian của con người. Điều này làm cho nó có thể thực hiện nâng cấp mà về cơ bản là không có thời gian chết. (Bạn có thể có thời gian chết nếu mô-đun thay thế có lỗi làm hỏng hệ thống, nhưng đó là lý do tại sao bạn kiểm tra trước khi triển khai sản xuất.)

2. Người giám sát . Thư viện OTP của Erlang có một khung giám sát được tích hợp sẵn trong đó cho phép bạn xác định cách hệ thống sẽ phản ứng nếu một mô-đun gặp sự cố. Hành động tiêu chuẩn ở đây là khởi động lại mô-đun bị lỗi. Giả sử mô-đun được khởi động lại không gặp sự cố lại ngay lập tức, thì tổng thời gian ngừng hoạt động được tính vào hệ thống của bạn có thể chỉ bằng mili giây. Một hệ thống vững chắc hiếm khi gặp sự cố có thể chỉ tích lũy một phần nhỏ của tổng thời gian ngừng hoạt động trong suốt nhiều năm thời gian chạy.

3. Các quy trình . Những thứ này gần tương ứng với các luồng bằng các ngôn ngữ khác, ngoại trừ việc chúng không chia sẻ trạng thái ngoại trừ thông qua các kho lưu trữ dữ liệu liên tục. Ngoài ra, giao tiếp diễn ra thông qua việc chuyển tin nhắn. Bởi vì các quy trình Erlang rất rẻ (rẻ hơn nhiều so với các luồng hệ điều hành), điều này khuyến khích một thiết kế kết hợp lỏng lẻo, để nếu một quy trình chết, chỉ một phần nhỏ của hệ thống gặp thời gian chết. Thông thường, người giám sát khởi động lại một quá trình đó, ít hoặc không ảnh hưởng đến phần còn lại của hệ thống.

4. Truyền thông điệp không đồng bộ . Khi một tiến trình muốn nói với điều gì đó khác, có một toán tử hạng nhất trong ngôn ngữ Erlang cho phép nó làm điều đó. Quá trình gửi tin nhắn không phải đợi người nhận xử lý tin nhắn và nó không phải điều phối quyền sở hữu dữ liệu được gửi. Bản chất chức năng không đồng bộ của hệ thống truyền thông điệp của Erlang đảm nhận tất cả những điều đó. Điều này giúp duy trì thời gian hoạt động cao vì nó làm giảm ảnh hưởng mà thời gian ngừng hoạt động ở một bộ phận của hệ thống có thể gây ra đối với các bộ phận khác.

5. Phân cụm . Điều này tiếp theo từ điểm trước: Cơ chế truyền thông điệp của Erlang hoạt động minh bạch giữa các máy trong mạng, vì vậy quá trình gửi thậm chí không cần quan tâm đến việc người nhận đang ở trên một máy riêng biệt. Điều này cung cấp một cơ chế dễ dàng để phân chia khối lượng công việc giữa nhiều máy, mỗi máy có thể giảm xuống riêng biệt mà không làm tổn hại đến thời gian hoạt động chung của hệ thống.

Con số khả dụng 99,9999999% là một thống kê thường được trích dẫn nhưng về cơ bản là sai lầm. Mats Cronqvist, một trong những thành viên nhóm AXD-301, đã thuyết trình (video) (mà tôi đã tham dự) tại hội nghị Nhà máy Erlang năm 2010 ở San Francisco, thảo luận về thống kê tính khả dụng chính xác này. Theo ông, nó đã được British Telecom tuyên bố trong thời gian thử nghiệm (tôi tin rằng từ tháng 1 đến tháng 9 năm 2002) là "5 năm nút" bằng cách sử dụng AXD-301. Đã có 14 nút thực hiện lưu lượng truy cập trực tiếp vào cuối thời gian thử nghiệm.

Cronqvist đặc biệt tuyên bố rằng đây không phải là đại diện cho toàn bộ lịch sử AXD-301, hay nói chung là Erlang, và ông không hài lòng khi Joe Armstrong tiếp tục trích dẫn điều này, dẫn đến kỳ vọng quá mức về độ tin cậy của Erlang. Những người khác đã viết rằng năm số chín là một con số thực tế hơn.

Cần phải nói rằng tôi là một nhà phát triển và ủng hộ Erlang nhiệt thành, người tin rằng việc sử dụng Erlang một cách chuyên nghiệp thực sự có thể dẫn đến các hệ thống rất sẵn có, nhưng chỉ muốn giảm sự cường điệu. Tất nhiên tôi giả định rằng sự trình bày của Cronqvist về các sự kiện là chính xác và không có lý do gì để tin khác.

Sự hiểu biết của tôi về những thống kê đó là nó được tính toán trên TẤT CẢ các hệ thống AXD301 trong quá trình sản xuất. Chúng tôi có thể mong đợi rằng khi AXD301 gặp sự cố nghiêm trọng, nó sẽ ngừng hoạt động trong hơn 0,631 giây. Trong thời gian này, AXD301 khác sẽ tiếp quản để duy trì mạng hoạt động.

Tuy nhiên, khi bạn tính tổng số giờ của tất cả AXD301 đang chạy, tạo tỷ lệ cho một AXD301 không thành công, bạn thấy 99,999999%

Đó là cách tôi hiểu con số này.

Hy vọng điều này giúp đỡ.