Odnoklassniki là người dùng Apache Cassandra lớn nhất trên RuNet và là một trong những người dùng lớn nhất trên thế giới. Chúng tôi bắt đầu sử dụng Cassandra vào năm 2010 để lưu trữ xếp hạng ảnh và hiện tại Cassandra quản lý hàng petabyte dữ liệu trên hàng nghìn nút, trên thực tế, chúng tôi thậm chí còn phát triển của riêng mình .
Vào ngày 12 tháng XNUMX tại văn phòng St. Petersburg, chúng tôi sẽ tổ chức . Diễn giả chính của sự kiện sẽ là kỹ sư trưởng của Odnoklassniki Oleg Anastasyev. Oleg là một chuyên gia trong lĩnh vực hệ thống phân tán và có khả năng chịu lỗi, anh ấy đã làm việc với Cassandra hơn 10 năm và nhiều lần .
Trước cuộc gặp mặt, chúng tôi đã nói chuyện với Oleg về khả năng chịu lỗi của hệ thống phân tán với Cassandra, hỏi anh ấy sẽ nói gì tại cuộc gặp mặt và tại sao lại đáng tham dự sự kiện này.
Oleg bắt đầu sự nghiệp lập trình của mình từ năm 1995. Ông đã phát triển phần mềm về ngân hàng, viễn thông và vận tải. Anh ấy đã làm việc với tư cách là nhà phát triển hàng đầu tại Odnoklassniki từ năm 2007 trong nhóm nền tảng. Trách nhiệm của ông bao gồm phát triển kiến trúc và giải pháp cho hệ thống tải cao, kho dữ liệu lớn và giải quyết các vấn đề về hiệu suất và độ tin cậy của cổng thông tin. Ông cũng đào tạo các nhà phát triển trong công ty.
- Oleg, xin chào! Vào tháng 5 đã diễn ra , dành riêng cho Apache Cassandra, những người tham gia nói rằng các cuộc thảo luận diễn ra đến tận đêm khuya, vui lòng cho tôi biết ấn tượng của bạn về buổi gặp mặt đầu tiên là gì?
Các nhà phát triển có nền tảng khác nhau từ các công ty khác nhau đã đưa ra nỗi đau của riêng họ, những giải pháp bất ngờ cho các vấn đề và những câu chuyện thú vị. Chúng tôi đã cố gắng tiến hành hầu hết cuộc gặp gỡ theo hình thức thảo luận, nhưng có quá nhiều cuộc thảo luận nên chúng tôi chỉ có thể đề cập đến một phần ba số chủ đề đã lên kế hoạch. Chúng tôi rất chú ý đến cách thức và nội dung chúng tôi giám sát bằng cách sử dụng ví dụ về các dịch vụ sản xuất thực tế của mình.
Tôi quan tâm và thực sự thích nó.
- Xét theo thông báo, sẽ hoàn toàn tập trung vào khả năng chịu lỗi, tại sao bạn lại chọn chủ đề này?
Cassandra là một hệ thống phân tán bận rộn điển hình với số lượng chức năng khổng lồ ngoài việc phục vụ trực tiếp các yêu cầu của người dùng: tin đồn, phát hiện lỗi, truyền bá các thay đổi lược đồ, mở rộng/giảm cụm, chống entropy, sao lưu và phục hồi, v.v. Giống như trong bất kỳ hệ thống phân tán nào, khi số lượng phần cứng tăng lên, khả năng xảy ra lỗi cũng tăng lên, do đó, hoạt động của cụm sản xuất Cassandra đòi hỏi sự hiểu biết sâu sắc về cấu trúc của nó để dự đoán hành vi trong trường hợp xảy ra lỗi và hành động của người vận hành. Sau khi sử dụng Cassandra trong nhiều năm, chúng tôi , điều mà chúng tôi sẵn sàng chia sẻ và chúng tôi cũng muốn thảo luận về cách các đồng nghiệp trong cửa hàng giải quyết những vấn đề điển hình.
— Khi nói đến Cassandra, bạn hiểu khả năng chịu lỗi là gì?
Tất nhiên, trước hết là khả năng tồn tại của hệ thống trong các lỗi phần cứng điển hình: mất máy, ổ đĩa hoặc kết nối mạng với các nút/trung tâm dữ liệu. Nhưng bản thân chủ đề này rộng hơn nhiều và đặc biệt bao gồm việc khắc phục sau các lỗi, bao gồm cả những lỗi mà mọi người hiếm khi chuẩn bị cho, chẳng hạn như lỗi của người vận hành.
— Bạn có thể đưa ra ví dụ về cụm dữ liệu lớn nhất và được tải nhiều nhất không?
Một trong những cụm lớn nhất của chúng tôi là cụm quà tặng: hơn 200 nút và hàng trăm TB dữ liệu. Nhưng nó không phải là thứ được tải nhiều nhất vì nó được bao phủ bởi bộ đệm phân tán. Các cụm bận rộn nhất của chúng tôi xử lý hàng chục nghìn RPS để ghi và hàng nghìn RPS để đọc.
- Ồ! Bao lâu thì một cái gì đó bị hỏng?
! Tổng cộng, chúng tôi có hơn 6 nghìn máy chủ và mỗi tuần có một vài máy chủ và vài chục đĩa được thay thế (không tính đến các quá trình song song nâng cấp và mở rộng đội máy). Đối với mỗi loại lỗi đều có hướng dẫn rõ ràng về những việc cần làm và theo thứ tự, mọi thứ đều được tự động hóa bất cứ khi nào có thể, vì vậy lỗi là chuyện thường ngày và trong 99% trường hợp xảy ra mà người dùng không nhận thấy.
- Bạn xử lý thế nào trước những lời từ chối như vậy?
Ngay từ khi bắt đầu hoạt động Cassandra và những sự cố đầu tiên, chúng tôi đã nghiên cứu các cơ chế sao lưu và phục hồi từ chúng, xây dựng các quy trình triển khai có tính đến trạng thái của cụm Cassandra và chẳng hạn như không cho phép khởi động lại các nút nếu có thể mất dữ liệu. Chúng tôi dự định sẽ nói về tất cả những điều này tại cuộc gặp mặt.
— Như bạn đã nói, không có hệ thống nào đáng tin cậy tuyệt đối. Những loại thất bại nào bạn chuẩn bị và có thể xử lý?
Nếu chúng ta nói về việc cài đặt cụm Cassandra, người dùng sẽ không nhận thấy bất cứ điều gì nếu chúng ta mất một số máy trong một DC hoặc toàn bộ một DC (điều này đã xảy ra). Với sự gia tăng số lượng DC, chúng tôi đang nghĩ đến việc bắt đầu đảm bảo khả năng hoạt động trong trường hợp hai DC bị hỏng.
— Bạn nghĩ Cassandra thiếu gì về khả năng chịu lỗi?
Cassandra, giống như nhiều cửa hàng NoSQL đầu tiên khác, đòi hỏi sự hiểu biết sâu sắc về cấu trúc bên trong của nó và các quy trình động diễn ra. Tôi có thể nói rằng nó thiếu tính đơn giản, khả năng dự đoán và khả năng quan sát. Nhưng sẽ rất thú vị khi nghe ý kiến của những người tham gia cuộc họp khác!
Oleg, cảm ơn bạn rất nhiều vì đã dành thời gian trả lời các câu hỏi!
Chúng tôi đang chờ đợi tất cả những ai muốn giao lưu với các chuyên gia trong lĩnh vực vận hành Apache Cassandra tại cuộc gặp mặt vào ngày 12 tháng XNUMX tại văn phòng St. Petersburg của chúng tôi.
Hãy đến, nó sẽ rất thú vị!
Nguồn: www.habr.com