Máy chủ dự phòng nóng vs máy chủ dự phòng lạnh?

Chúng tôi có một số máy chủ lưu trữ, nơi chúng tôi có một máy chủ dự phòng nóng giống hệt nhau, được vá và cập nhật để nó rất gần với cùng một phần mềm và cấu hình. Trong trường hợp thất bại, cáp mạng được chuyển đổi và máy chủ DHCP được cập nhật với địa chỉ MAC mới. Đây là trường hợp tốt nhất, vì thường có thêm một chút cần sửa đổi.

Tôi cảm thấy thật lãng phí điện khi có một máy chủ dự phòng nóng và lãng phí thời gian để duy trì nó, và vì việc sửa đổi cấu hình là cần thiết trong trường hợp chuyển đổi dự phòng, tôi muốn hỏi như sau:

Là phụ tùng nóng chủ trường cũ và có những cách tốt hơn bây giờ?

Thay vì có một máy chủ dự phòng nóng, sẽ rất hợp lý nếu biến nó thành một máy dự phòng lạnh, lấy các ổ đĩa cứng và đặt chúng vào máy chủ chính và thay đổi RAID từ 1 thành 1 + 1. Trong trường hợp thất bại, tất cả những gì tôi phải làm là thay đổi cáp mạng, cập nhật máy chủ DHCP, lấy ổ cứng và lắp chúng vào phụ tùng lạnh và bật nguồn. Lợi ích, như tôi thấy, là các đĩa 2x2 luôn được đồng bộ hóa, do đó chỉ có một máy chủ để duy trì và không cần thay đổi cấu hình khi không thành công.

Đó có phải là một ý tưởng tốt?

Sobrique giải thích cách can thiệp thủ công làm cho giải pháp được đề xuất của bạn trở nên tối ưu và ewwhite nói về khả năng thất bại của các thành phần khác nhau . Cả hai IMO này đều có những điểm rất tốt và cần được xem xét mạnh mẽ.

Tuy nhiên, có một vấn đề mà dường như không ai có thể nhận xét gì cả, điều này làm tôi ngạc nhiên một chút. Bạn đề xuất:

biến [máy chủ dự phòng nóng hiện tại] thành phụ tùng lạnh, lấy ổ cứng và đặt chúng vào máy chủ chính và thay đổi RAID từ 1 thành 1 + 1.

Điều này không bảo vệ bạn trước mọi thứ mà HĐH thực hiện trên đĩa.

Nó chỉ thực sự bảo vệ bạn khỏi sự cố hỏng đĩa, bằng cách di chuyển từ gương (RAID 1) sang gương của gương (RAID 1 + 1), bạn sẽ giảm đáng kể tác động của việc bắt đầu. Bạn có thể nhận được kết quả tương tự bằng cách tăng số lượng đĩa trong mỗi bộ nhân bản (ví dụ: từ RAID 2 đĩa sang RAID 4 đĩa), cùng với khả năng cải thiện hiệu suất đọc trong các hoạt động thông thường.

Vậy thì, hãy xem xét một số cách có thể thất bại .

• Giả sử bạn đang cài đặt các bản cập nhật hệ thống và một cái gì đó khiến quá trình bị lỗi một nửa; có thể có sự cố về điện và UPS , hoặc có thể bạn gặp tai nạn kỳ lạ và gặp phải lỗi hạt nhân làm tê liệt (Linux ngày nay khá đáng tin cậy, nhưng vẫn có rủi ro).
• Có thể một bản cập nhật giới thiệu một vấn đề mà bạn không gặp phải trong quá trình kiểm tra (bạn có kiểm tra các bản cập nhật hệ thống không?) Yêu cầu chuyển đổi dự phòng sang hệ thống thứ cấp trong khi bạn sửa lỗi chính
• Có thể một lỗi trong mã hệ thống tệp gây ra giả, ghi không hợp lệ vào đĩa.
• Có thể một quản trị viên ngón tay mập (hoặc thậm chí độc hại) làm rm -rf ../*hoặc rm -rf /*thay vì rm -rf ./*.
• Có thể một lỗi trong phần mềm của riêng bạn khiến nó bị hỏng ồ ạt nội dung cơ sở dữ liệu.
• Có thể một virus quản lý để lẻn vào.

Có lẽ, có lẽ, có lẽ ... (và tôi chắc chắn còn nhiều cách khác mà cách tiếp cận được đề xuất của bạn có thể thất bại.) Tuy nhiên, cuối cùng, điều này làm cho "hai bộ luôn luôn đồng bộ" "lợi thế" của bạn. Đôi khi bạn không muốn chúng hoàn toàn đồng bộ.

Tùy thuộc vào chính xác những gì đã xảy ra, đó là khi bạn muốn một chế độ chờ nóng hoặc lạnh sẵn sàng được bật và chuyển sang, hoặc sao lưu thích hợp. Dù bằng cách nào, gương RAID của gương (hoặc gương RAID) sẽ không giúp bạn nếu chế độ lỗi liên quan đến nhiều thứ ngoài sự cố thiết bị lưu trữ phần cứng (sự cố đĩa). Một cái gì đó như raidzN của ZFS có thể có thể làm tốt hơn một chút trong một số khía cạnh nhưng không tốt hơn ở những người khác.

Đối với tôi, điều này sẽ làm cho cách tiếp cận được đề xuất của bạn không thành công ngay từ đầu nếu ý định là bất kỳ loại thảm họa nào.

Vâng, đó là một trường học hơi cũ. Phần cứng hiện đại không chỉ thất bại thường xuyên. Tập trung vào việc làm cho các ứng dụng của bạn có tính sẵn sàng cao hơn (không phải lúc nào cũng có thể) hoặc vào các mục cần thiết để làm cho các máy chủ cá nhân của bạn trở nên linh hoạt hơn ...

Đối với máy chủ lưu trữ:

• Mua phần cứng tốt hơn.
• Đảm bảo bạn có hợp đồng hỗ trợ.
• ĐĂNG KÝ hợp đồng hỗ trợ máy chủ của bạn (phụ tùng được dự trữ tại địa phương dựa trên dữ liệu đăng ký!)
• Sử dụng nguồn điện dự phòng, RAID (phần cứng?), Quạt dự phòng.
• Nếu máy chủ không có khả năng cung cấp các tính năng dư thừa ở trên, hãy giữ sẵn khung hoặc phụ tùng dự phòng để có thể tự sửa chữa trong trường hợp hỏng hóc.

Để giảm tần suất thất bại, tôi thấy: đĩa, RAM, nguồn điện, quạt thường xuyên nhất ... Đôi khi bo mạch hệ thống hoặc CPU. Nhưng hai cuối cùng là nơi hợp đồng hỗ trợ của bạn nên khởi động.

Nó khá không hiệu quả - nhất là do sự phụ thuộc vào can thiệp thủ công để thực hiện chuyển đổi.

Tôi đã làm việc tại những nơi điều hành một trang web DR nóng - theo nghĩa đen, các máy chủ giống hệt với máy chủ chính, sẵn sàng hoạt động ngay lập tức. Tuy nhiên, chuyển đổi DR là một quy trình tự động - chúng tôi không nói về hệ thống cáp, một chút nghịch ngợm và chuyển đổi, mà là một quá trình khi chúng tôi nhấn nút lật mọi thứ từ trang này sang trang khác.

Cách tiếp cận này cực kỳ tốn kém, nhưng đó là một quyết định kinh doanh - rủi ro chấp nhận được so với số tiền cần thiết để thực hiện mục tiêu. Theo quy định, có một đường cong theo cấp số nhân về mục tiêu thời gian phục hồi - càng gần bằng 0, chi phí càng cao.

Nhưng đó là những gì câu hỏi của bạn về, thực sự. Có gì là mục tiêu thời gian phục hồi của bạn, và cách hiệu quả nhất để đạt được nó là gì. Chờ đợi một máy chủ khởi động sẽ mất một vài phút. Mất bao lâu để ai đó thực hiện việc điều chỉnh và 'nhiệm vụ khôi phục' khi nó xuất hiện lúc 4 giờ sáng?

Và mất điện bao lâu là chấp nhận được?

Tôi sẽ đề nghị rằng nếu bạn đang thực hiện 'phục hồi nóng', bạn muốn nghĩ đến việc phân cụm. Bạn có thể khá rẻ khi phân cụm với việc sử dụng tốt VMWare - 'không thành công' với VM - ngay cả từ vật lý - có nghĩa là bạn không chạy phần cứng dự phòng. (Chà, N + 1 chứ không phải 2N).

Nếu RTO của bạn đủ dài, sau đó tắt hộp. Bạn có thể thấy rằng RTO là đủ để xây dựng lại lạnh từ sao lưu là ok.

Thực tế là trường học cũ không nhất thiết phải sử dụng phụ tùng nóng là một ý tưởng tồi.

Mối quan tâm chính của bạn nên là lý do căn bản, những rủi ro bạn gặp phải là gì và làm thế nào để chạy một phụ tùng nóng giảm thiểu chúng. Bởi vì theo nhận thức của tôi, phụ tùng nóng của bạn chỉ giải quyết được lỗi phần cứng, mặc dù điều này không phổ biến, không phải là rủi ro hoạt động duy nhất mà bạn chạy, cũng không có khả năng nhất. Mối quan tâm thứ hai là các chiến lược thay thế cung cấp giảm rủi ro nhiều hơn hoặc tiết kiệm đáng kể.

Chạy một phụ tùng nóng với nhiều bước chuyển đổi dự phòng thủ công sẽ mất nhiều thời gian và có khả năng bị lỗi, nhưng tôi cũng có vẻ như chuyển đổi dự phòng tự động với các bộ cụm HA chuyển thành cụm lớn f * cks.

Một điều nữa là chế độ chờ nóng hoặc lạnh ở cùng một vị trí không mang lại sự liên tục cho doanh nghiệp trong trường hợp thảm họa cục bộ.

Khái niệm có một phụ tùng nóng hoặc thậm chí lạnh phụ thuộc vào cách (các) ứng dụng được xây dựng ở nơi đầu tiên.

Ý tôi là nếu ứng dụng được xây dựng theo cách mà tải dữ liệu và dịch vụ được trải đều trên nhiều máy thì khái niệm về bất kỳ máy nào làm mất hệ thống sẽ biến mất. Trong tình huống đó, bạn không cần một phụ tùng nóng. Thay vào đó, bạn cần có đủ dung lượng để xử lý khi một máy / bộ phận riêng lẻ chết.

Ví dụ, một ứng dụng web tiêu chuẩn thường yêu cầu máy chủ web và máy chủ cơ sở dữ liệu. Đối với các máy chủ web, chỉ cần tải số dư 2 trở lên. Nếu một người chết, không có vấn đề lớn. Cơ sở dữ liệu thường khó khăn hơn vì nó phải được cấu trúc để trở thành đa chủ với tất cả các dữ liệu đồng bộ hóa trên các máy tham gia. Vì vậy, thay vì một máy chủ DB duy nhất, bạn kết thúc với 2 (hoặc nhiều hơn) vừa phục vụ nhu cầu dữ liệu của bạn. Các nhà cung cấp dịch vụ lớn như Google, Amazon, Facebook, v.v. đã đi theo con đường này. Có nhiều chi phí trả trước trong thời gian phát triển, nhưng nó trả cổ tức nếu bạn cần mở rộng quy mô.

Bây giờ, nếu ứng dụng của bạn không được cấu trúc theo cách như vậy hoặc đơn giản là nó bị cấm để phù hợp với ứng dụng thì có thể bạn sẽ muốn có một phụ tùng nóng.