Bạn sẽ cảm thấy thế nào nếu một ngày hè đẹp trời, trung tâm dữ liệu với thiết bị của bạn trông như thế này?
Chào mọi người! Tên tôi là Dmitry Samsonov, tôi làm quản trị viên hệ thống hàng đầu tại "" Bức ảnh chụp một trong bốn trung tâm dữ liệu nơi lắp đặt thiết bị phục vụ dự án của chúng tôi. Đằng sau những bức tường này có khoảng 4 nghìn thiết bị: máy chủ, hệ thống lưu trữ dữ liệu, thiết bị mạng, v.v. - gần ⅓ tất cả các thiết bị của chúng tôi.
Hầu hết các máy chủ đều là Linux. Ngoài ra còn có vài chục máy chủ trên Windows (MS SQL) - di sản của chúng tôi, thứ mà chúng tôi đã từ bỏ một cách có hệ thống trong nhiều năm.
Vì vậy, vào lúc 5:2019 ngày 14 tháng 35 năm XNUMX, các kỹ sư tại một trong các trung tâm dữ liệu của chúng tôi đã báo cáo có chuông báo cháy.
Từ chối
14:45. Sự cố khói nhỏ trong trung tâm dữ liệu phổ biến hơn bạn nghĩ. Các chỉ số bên trong hội trường vẫn bình thường, vì vậy phản ứng đầu tiên của chúng tôi tương đối bình tĩnh: họ đưa ra lệnh cấm làm việc với sản xuất, tức là đối với bất kỳ thay đổi cấu hình nào, tung ra các phiên bản mới, v.v., ngoại trừ công việc liên quan đến sửa chữa thứ gì đó.
Anger
Bạn đã bao giờ cố gắng tìm hiểu từ lính cứu hỏa chính xác nơi xảy ra đám cháy trên mái nhà hoặc tự mình lên mái nhà đang cháy để đánh giá tình hình chưa? Mức độ tin cậy đối với thông tin nhận được qua năm người sẽ như thế nào?
14: 50. Nhận được thông tin đám cháy đang tiến đến hệ thống làm mát. Nhưng nó sẽ đến chứ? Quản trị viên hệ thống đang làm nhiệm vụ loại bỏ lưu lượng truy cập bên ngoài khỏi mặt trước của trung tâm dữ liệu này.
Hiện tại, mặt trước của tất cả các dịch vụ của chúng tôi được sao chép ở ba trung tâm dữ liệu, tính năng cân bằng được sử dụng ở cấp DNS, cho phép chúng tôi xóa địa chỉ của một trung tâm dữ liệu khỏi DNS, từ đó bảo vệ người dùng khỏi các sự cố tiềm ẩn khi truy cập dịch vụ . Nếu sự cố đã xảy ra trong trung tâm dữ liệu, nó sẽ tự động rời khỏi vòng quay. Bạn có thể đọc thêm ở đây:
Vụ cháy chưa ảnh hưởng đến chúng tôi dưới bất kỳ hình thức nào - cả người dùng và thiết bị đều không bị hư hại. Đây có phải là một tai nạn? Phần đầu tiên của tài liệu “Kế hoạch hành động cho tai nạn” xác định khái niệm “Tai nạn” và phần này kết thúc như sau:
«Nếu nghi ngờ có tai nạn hay không thì đó là tai nạn!»
14:53. Một điều phối viên khẩn cấp được bổ nhiệm.
Điều phối viên là người kiểm soát việc liên lạc giữa tất cả những người tham gia, đánh giá quy mô của vụ tai nạn, sử dụng Kế hoạch hành động khẩn cấp, thu hút nhân sự cần thiết, giám sát việc hoàn thành việc sửa chữa và quan trọng nhất là giao mọi nhiệm vụ. Nói cách khác, đây là người quản lý toàn bộ quá trình ứng phó khẩn cấp.
Trả giá
15:01. Chúng tôi bắt đầu vô hiệu hóa các máy chủ không liên quan đến sản xuất.
15:03. Chúng tôi tắt chính xác tất cả các dịch vụ dành riêng.
Điều này không chỉ bao gồm các mặt trận (mà đến thời điểm này người dùng không còn truy cập nữa) và các dịch vụ phụ trợ của họ (logic nghiệp vụ, bộ đệm, v.v.), mà còn bao gồm các cơ sở dữ liệu khác nhau có hệ số sao chép 2 trở lên (, , , vân vân.).
15: 06. Đã nhận được thông tin rằng một đám cháy đang đe dọa một trong các hội trường của trung tâm dữ liệu. Chúng tôi không có thiết bị trong căn phòng này, nhưng thực tế là ngọn lửa có thể lan từ mái nhà đến các hành lang làm thay đổi đáng kể bức tranh về những gì đang xảy ra.
(Sau này hóa ra không có mối đe dọa vật chất nào đối với hội trường vì nó được bịt kín từ mái nhà. Mối đe dọa chỉ đối với hệ thống làm mát của hội trường này.)
15:07. Chúng tôi cho phép thực thi lệnh trên máy chủ ở chế độ tăng tốc mà không cần kiểm tra bổ sung ().
15:08. Nhiệt độ trong hội trường nằm trong giới hạn bình thường.
15: 12. Sự gia tăng nhiệt độ trong hội trường đã được ghi lại.
15:13. Hơn một nửa số máy chủ trong trung tâm dữ liệu đã bị tắt. Tiếp tục đi.
15:16. Một quyết định đã được đưa ra là tắt tất cả các thiết bị.
15:21. Chúng tôi bắt đầu tắt nguồn đối với các máy chủ không trạng thái mà không tắt ứng dụng và hệ điều hành một cách chính xác.
15:23. Một nhóm người chịu trách nhiệm về MS SQL được phân bổ (có rất ít người trong số họ, sự phụ thuộc của các dịch vụ vào họ không lớn, nhưng quy trình khôi phục chức năng mất nhiều thời gian hơn và phức tạp hơn, chẳng hạn như Cassandra).
Trầm cảm
15: 25. Đã nhận được thông tin về việc mất điện ở 16 hội trường trong số 6 (số 7, 8, 9, XNUMX). Thiết bị của chúng tôi được đặt tại hội trường 7 và 8. Không có thông tin về hai hội trường của chúng tôi (số 1 và 3).
Thông thường, khi xảy ra hỏa hoạn, nguồn điện sẽ bị tắt ngay lập tức, nhưng trong trường hợp này, nhờ sự phối hợp của lực lượng cứu hỏa và nhân viên kỹ thuật của trung tâm dữ liệu, nó không bị tắt ở mọi nơi và không phải ngay lập tức mà là khi cần thiết.
(Sau này người ta phát hiện ra điện ở sảnh 8 và 9 không hề bị tắt.)
15:28. Chúng tôi đang bắt đầu triển khai cơ sở dữ liệu MS SQL từ các bản sao lưu ở các trung tâm dữ liệu khác.
Làm cái đó mất bao lâu? Có đủ dung lượng mạng cho toàn bộ tuyến đường không?
15: 37. Việc tắt một số phần của mạng đã được ghi lại.
Việc quản lý và mạng lưới sản xuất bị cô lập về mặt vật lý với nhau. Nếu mạng sản xuất có sẵn, bạn có thể truy cập máy chủ, dừng ứng dụng và tắt HĐH. Nếu không có thì bạn có thể đăng nhập qua IPMI, dừng ứng dụng và tắt HĐH. Nếu không có mạng thì bạn không thể làm gì được. “Cảm ơn, Cap!”, bạn sẽ nghĩ vậy.
“Và nhìn chung, có rất nhiều xáo trộn,” bạn cũng có thể nghĩ như vậy.
Vấn đề là các máy chủ, ngay cả khi không có lửa, vẫn tạo ra một lượng nhiệt rất lớn. Chính xác hơn, khi có sự làm mát, chúng tạo ra nhiệt, và khi không làm mát, chúng tạo ra một địa ngục khủng khiếp, tốt nhất sẽ làm tan chảy một phần thiết bị và tắt một phần khác, và tệ nhất là... gây cháy bên trong hội trường, nơi gần như chắc chắn sẽ phá hủy mọi thứ.
15:39. Chúng tôi khắc phục sự cố với cơ sở dữ liệu conf.
Cơ sở dữ liệu conf là phần phụ trợ cho dịch vụ cùng tên, được tất cả các ứng dụng sản xuất sử dụng để nhanh chóng thay đổi cài đặt. Nếu không có cơ sở này, chúng ta không thể kiểm soát hoạt động của cổng nhưng bản thân cổng vẫn có thể hoạt động.
15:41. Cảm biến nhiệt độ trên thiết bị mạng lõi ghi lại số đọc gần mức tối đa cho phép. Đây là một hộp chiếm toàn bộ một tủ rack và đảm bảo hoạt động của tất cả các mạng bên trong trung tâm dữ liệu.
15:42. Trình theo dõi vấn đề và wiki không khả dụng, hãy chuyển sang chế độ chờ.
Đây không phải là sản xuất, nhưng trong trường hợp xảy ra tai nạn, sự sẵn có của bất kỳ nền tảng kiến thức nào đều có thể rất quan trọng.
15:50. Một trong những hệ thống giám sát đã tắt.
Có một số người trong số họ và họ chịu trách nhiệm về các khía cạnh khác nhau của dịch vụ. Một số trong số chúng được cấu hình để hoạt động tự chủ trong mỗi trung tâm dữ liệu (nghĩa là chúng chỉ giám sát trung tâm dữ liệu của riêng mình), một số khác bao gồm các thành phần phân tán có thể tồn tại một cách minh bạch khi mất bất kỳ trung tâm dữ liệu nào.
Trong trường hợp này nó ngừng hoạt động , hoạt động ở chế độ chờ chính. Đã chuyển sang chế độ chờ.
Nhận con nuôi
15:51. Tất cả các máy chủ ngoại trừ MS SQL đều bị tắt qua IPMI mà không tắt đúng cách.
Bạn đã sẵn sàng quản lý máy chủ lớn thông qua IPMI nếu cần thiết chưa?
Thời điểm việc cứu hộ thiết bị trong trung tâm dữ liệu được hoàn thành ở giai đoạn này. Mọi việc có thể làm đều đã được thực hiện. Một số đồng nghiệp có thể nghỉ ngơi.
16: 13. Đã nhận được thông tin rằng các đường ống freon từ máy điều hòa không khí bị vỡ trên mái nhà - điều này sẽ làm trì hoãn việc khởi động trung tâm dữ liệu sau khi ngọn lửa được dập tắt.
16:19. Theo dữ liệu nhận được từ nhân viên kỹ thuật của trung tâm dữ liệu, nhiệt độ trong hội trường đã ngừng tăng.
17:10. Cơ sở dữ liệu conf đã được khôi phục. Bây giờ chúng ta có thể thay đổi cài đặt ứng dụng.
Tại sao điều này lại quan trọng nếu mọi thứ đều có khả năng chịu lỗi và hoạt động ngay cả khi không có một trung tâm dữ liệu?
Thứ nhất, không phải mọi thứ đều có khả năng chịu lỗi. Có nhiều dịch vụ thứ cấp khác nhau vẫn chưa tồn tại tốt sau sự cố của trung tâm dữ liệu và có những cơ sở dữ liệu ở chế độ dự phòng chính. Khả năng quản lý cài đặt cho phép bạn thực hiện mọi thứ cần thiết để giảm thiểu tác động của hậu quả tai nạn đối với người dùng ngay cả trong điều kiện khó khăn.
Thứ hai, rõ ràng là hoạt động của trung tâm dữ liệu sẽ không được khôi phục hoàn toàn trong những giờ tới, vì vậy cần phải thực hiện các biện pháp để đảm bảo rằng việc không có bản sao trong thời gian dài không dẫn đến những rắc rối khác như đầy đĩa trong trung tâm dữ liệu còn lại.
17:29. Hiện bánh pizza! Chúng tôi tuyển dụng con người chứ không phải robot.
Phục hồi chức năng
18:02. Tại các hội trường số 8 (của chúng tôi), 9, 10 và 11, nhiệt độ đã ổn định. Một trong những nơi vẫn ngoại tuyến (số 7) chứa thiết bị của chúng tôi và nhiệt độ ở đó tiếp tục tăng.
18:31. Họ cho phép khởi động thiết bị ở sảnh số 1 và 3 - những sảnh này không bị ảnh hưởng bởi đám cháy.
Hiện tại, các máy chủ đang được triển khai tại các sảnh số 1, 3, 8, bắt đầu từ những máy chủ quan trọng nhất. Hoạt động chính xác của tất cả các dịch vụ đang chạy được kiểm tra. Hội trường số 7 vẫn còn vấn đề.
18:44. Nhân viên kỹ thuật của trung tâm dữ liệu phát hiện tại phòng số 7 (nơi chỉ đặt thiết bị của chúng tôi) nhiều máy chủ không bị tắt. Theo dữ liệu của chúng tôi, 26 máy chủ vẫn trực tuyến ở đó. Sau lần kiểm tra thứ hai, chúng tôi tìm thấy 58 máy chủ.
20:18. Các kỹ thuật viên của trung tâm dữ liệu thổi không khí qua một căn phòng không có điều hòa thông qua các ống dẫn di động chạy qua hành lang.
23:08. Quản trị viên đầu tiên đã được gửi về nhà. Ai đó cần phải ngủ vào ban đêm để tiếp tục làm việc vào ngày mai. Tiếp theo, chúng tôi sẽ phát hành thêm một số quản trị viên và nhà phát triển.
02:56. Chúng tôi đã tung ra mọi thứ có thể được tung ra. Chúng tôi thực hiện kiểm tra tất cả các dịch vụ bằng cách sử dụng các bài kiểm tra tự động.
03:02. Máy điều hòa ở sảnh thứ 7 vừa qua đã được sửa chữa lại.
03:36. Chúng tôi đã đưa các mặt trận trong trung tâm dữ liệu vào luân chuyển trong DNS. Từ thời điểm này lưu lượng truy cập của người dùng bắt đầu đến.
Chúng tôi đang gửi hầu hết đội ngũ hành chính về nhà. Nhưng chúng tôi để lại một vài người ở lại.
Câu hỏi thường gặp nhỏ:
Hỏi: Chuyện gì đã xảy ra từ 18:31 đến 02:56?
Đáp: Tuân theo “Kế hoạch hành động sau thảm họa”, chúng tôi triển khai tất cả các dịch vụ, bắt đầu từ những dịch vụ quan trọng nhất. Trong trường hợp này, điều phối viên trong cuộc trò chuyện sẽ cấp dịch vụ cho quản trị viên miễn phí, người này sẽ kiểm tra xem hệ điều hành và ứng dụng đã khởi động hay chưa, có lỗi nào không và các chỉ báo có bình thường hay không. Sau khi quá trình ra mắt hoàn tất, anh ấy báo cáo trong cuộc trò chuyện rằng anh ấy đang rảnh và nhận được dịch vụ mới từ điều phối viên.
Quá trình này còn bị chậm lại do phần cứng bị lỗi. Ngay cả khi việc dừng hệ điều hành và tắt máy chủ diễn ra đúng cách, một số máy chủ vẫn không hoạt động trở lại do ổ đĩa, bộ nhớ và khung máy bị lỗi đột ngột. Khi mất điện, tỷ lệ hỏng hóc tăng lên.
Hỏi: Tại sao bạn không thể chạy mọi thứ cùng một lúc rồi khắc phục những gì xảy ra trong quá trình giám sát?
Đáp: Mọi thứ phải được thực hiện dần dần vì có sự phụ thuộc giữa các dịch vụ. Và mọi thứ cần được kiểm tra ngay lập tức, không cần chờ giám sát - bởi vì tốt hơn hết bạn nên giải quyết vấn đề ngay lập tức, không nên đợi chúng trở nên trầm trọng hơn.
7h40. Quản trị viên (điều phối viên) cuối cùng đã đi ngủ. Công việc của ngày đầu tiên đã hoàn thành.
8:09. Các nhà phát triển, kỹ sư trung tâm dữ liệu và quản trị viên đầu tiên (bao gồm cả điều phối viên mới) đã bắt đầu công việc khôi phục.
09:37. Chúng tôi bắt đầu nâng sảnh số 7 (phòng cuối cùng).
Đồng thời, chúng tôi tiếp tục khôi phục những gì chưa được sửa trong các phòng khác: thay thế đĩa/bộ nhớ/máy chủ, sửa mọi thứ “cháy” trong quá trình giám sát, chuyển đổi vai trò trở lại trong sơ đồ dự phòng chính và những việc nhỏ khác, trong đó có tuy nhiên khá nhiều.
17:08. Chúng tôi cho phép tất cả các công việc thường xuyên với sản xuất.
21:45. Công việc của ngày thứ hai đã hoàn thành.
09:45. Hôm nay là thứ Sáu. Vẫn còn khá nhiều vấn đề nhỏ trong công tác giám sát. Cuối tuần sắp đến rồi, ai cũng muốn thư giãn. Chúng tôi tiếp tục sửa chữa ồ ạt mọi thứ có thể. Các nhiệm vụ quản trị thông thường lẽ ra có thể bị hoãn lại đã bị hoãn lại. Điều phối viên là người mới.
15:40. Đột nhiên một nửa ngăn xếp thiết bị mạng Core trong trung tâm dữ liệu KHÁC khởi động lại. Các mặt trận đã được đưa ra khỏi vòng quay để giảm thiểu rủi ro. Không có tác dụng gì cho người dùng. Sau đó hóa ra đó là một khung gầm bị lỗi. Điều phối viên đang tiến hành khắc phục hai vụ tai nạn cùng một lúc.
17:17. Hoạt động mạng ở một trung tâm dữ liệu khác đã được khôi phục, mọi thứ đã được kiểm tra. Trung tâm dữ liệu được đưa vào luân chuyển.
18:29. Công việc của ngày thứ ba và nói chung là việc khôi phục sau tai nạn đã hoàn thành.
bạt
04.04.2013 , "Bạn cùng lớp" —trong ba ngày, cổng thông tin hoàn toàn hoặc một phần không khả dụng. Trong suốt thời gian này, hơn 100 người từ các thành phố khác nhau, từ các công ty khác nhau (một lần nữa xin cảm ơn rất nhiều!), từ xa và trực tiếp tại các trung tâm dữ liệu, theo cách thủ công và tự động, đã sửa chữa hàng nghìn máy chủ.
Chúng tôi đã rút ra kết luận. Để ngăn điều này xảy ra lần nữa, chúng tôi đã và đang tiếp tục thực hiện nhiều công việc sâu rộng cho đến ngày nay.
Sự khác biệt chính giữa vụ tai nạn hiện tại và 404 là gì?
- Chúng tôi có “Kế hoạch hành động khi xảy ra tai nạn”. Mỗi quý một lần, chúng tôi tiến hành các bài tập - chúng tôi đóng vai một tình huống khẩn cấp mà một nhóm quản trị viên (lần lượt) phải loại bỏ bằng cách sử dụng “Kế hoạch hành động khẩn cấp”. Các quản trị viên hệ thống hàng đầu thay phiên nhau đóng vai trò điều phối viên.
- Hàng quý, ở chế độ thử nghiệm, chúng tôi cách ly các trung tâm dữ liệu (lần lượt) thông qua mạng LAN và WAN, điều này cho phép chúng tôi xác định kịp thời các điểm nghẽn cổ chai.
- Ít đĩa bị hỏng hơn vì chúng tôi đã thắt chặt các tiêu chuẩn: ít giờ hoạt động hơn, ngưỡng chặt chẽ hơn cho SMART,
- Chúng tôi đã hoàn toàn từ bỏ BerkeleyDB, một cơ sở dữ liệu cũ và không ổn định, cần nhiều thời gian để khôi phục sau khi khởi động lại máy chủ.
- Chúng tôi đã giảm số lượng máy chủ có MS SQL và giảm sự phụ thuộc vào những máy chủ còn lại.
- Chúng tôi có cái riêng của mình , nơi chúng tôi đã tích cực di chuyển tất cả các dịch vụ trong hai năm nay. Đám mây đơn giản hóa đáng kể toàn bộ chu trình làm việc với ứng dụng và trong trường hợp xảy ra sự cố, nó cung cấp các công cụ độc đáo như:
- dừng chính xác tất cả các ứng dụng chỉ bằng một cú nhấp chuột;
- dễ dàng di chuyển các ứng dụng từ các máy chủ bị lỗi;
- tự động xếp hạng (theo thứ tự ưu tiên dịch vụ) của toàn bộ trung tâm dữ liệu.
Vụ tai nạn được mô tả trong bài viết này là vụ tai nạn lớn nhất kể từ ngày thứ 404. Tất nhiên, không phải mọi thứ đều suôn sẻ. Ví dụ: trong thời gian không có trung tâm dữ liệu bị hỏa hoạn ở một trung tâm dữ liệu khác, một đĩa trên một trong các máy chủ bị lỗi, tức là chỉ một trong ba bản sao trong cụm Cassandra vẫn có thể truy cập được, đó là lý do tại sao 4,2% số người dùng di động người dùng ứng dụng không thể đăng nhập. Đồng thời, người dùng đã kết nối vẫn tiếp tục làm việc. Tổng cộng, do vụ tai nạn, hơn 30 vấn đề đã được xác định - từ những lỗi tầm thường đến những thiếu sót trong kiến trúc dịch vụ.
Nhưng điểm khác biệt quan trọng nhất giữa vụ tai nạn hiện tại và vụ 404 là trong khi chúng tôi đang khắc phục hậu quả của vụ cháy, người dùng vẫn nhắn tin và gọi điện video tới , chơi game, nghe nhạc, tặng quà nhau, xem video, phim bộ và các kênh truyền hình trong , và cũng được phát trực tuyến .
Tai nạn của bạn diễn ra như thế nào?
Nguồn: www.habr.com