Sẵn có máy chủ cao cho một doanh nghiệp nhỏ

Sau khi có một chút sợ hãi với một máy chủ sẽ không xuất hiện vào một buổi sáng, các cấp cao hơn đã quyết định rằng doanh nghiệp cần tính sẵn sàng cao / thất bại so với thiết lập.

Chúng tôi có 5 máy chủ chính (4x Linux, 1x OpenBSD) tất cả đều cần được chạy để công ty hoạt động. Ba trong số các máy chủ khá chuẩn (Tệp / Web / Cơ sở dữ liệu), máy chủ thứ tư xử lý hầu hết các định tuyến web và proxy web, trong khi máy chủ thứ năm hỗ trợ hệ thống điện thoại của chúng tôi và có phần cứng không chuẩn.

Sếp của tôi đã tuyên bố rằng thời gian quay vòng cho sự cố máy chủ nên dưới 30 phút.

Kinh nghiệm của tôi trong lĩnh vực này là không tồn tại (Tôi chỉ là một lập trình viên được 'thăng cấp'), vì vậy tôi đoán câu hỏi của tôi thực sự sôi nổi:

• Đây có phải là thứ mà thậm chí nên được cố gắng bởi một người có kỹ năng quản trị máy chủ trung bình. Nếu vậy, tôi nên đọc cái gì, và tôi nên nói chuyện với ai?

Cảm ơn.

Tôi nghĩ bạn nên bắt đầu bằng cách tập hợp các con số để mô tả chi phí liên quan đến việc thực hiện "yêu cầu" đã nêu để xem liệu nó có nằm trong ngân sách hay không. Nếu bạn không thoải mái với tất cả các phương pháp "thông thường" sẽ được sử dụng để đáp ứng yêu cầu (phân cụm chuyển đổi dự phòng, trình ảo hóa với khả năng "di chuyển nóng", v.v.), thì có lẽ bạn nên tìm một chuyên gia tư vấn có thể giúp đỡ.

Sẽ có một số chi phí liên quan đến nghiên cứu khả thi, nhưng sẽ tốn ít chi phí hơn khi phát hiện ra rằng một giải pháp tốt sẽ không phù hợp với yêu cầu đã nêu (có nghĩa là các kỳ vọng cần được quản lý thực tế hơn - hoặc chúng cần phải đầu tư nhiều tiền hơn) sẽ tốn kém để làm một việc gì đó nửa vời mà cuối cùng không hoàn thành yêu cầu và thổi một tấn tiền trong quá trình này.

Có vẻ như ông chủ của bạn vừa kéo con số đó ra khỏi không khí. Có lẽ anh ấy đã thực hiện một số phân tích và biết chi phí mỗi giờ liên quan đến thời gian chết của các hệ thống khác nhau là gì, nhưng tôi nghi ngờ điều đó. Nghe có vẻ như một số số trên trời không gắn liền với thực tế. Tôi sẽ ngạc nhiên nếu tất cả các hệ thống của bạn cần loại sẵn có đó. Trong quá trình nghiên cứu kinh doanh, có thể bạn phát hiện ra rằng chỉ một tập hợp con của chức năng cần phải có mức độ thời gian hoạt động và khả năng chịu lỗi như vậy (và do đó, một giải pháp như vậy cuối cùng sẽ có chi phí thấp hơn). Tôi chắc chắn rằng điện thoại và ứng dụng kinh doanh trực tuyến đang hoạt động, nhưng bạn có thể có một số dung sai cho thời gian chết trên một số hệ thống khác.

Chú ruột của tôi nói rằng có lẽ bạn sẽ tìm thấy một chiến thắng trong việc sử dụng các công nghệ ảo hóa để tạo ra một hệ thống chuyển đổi dự phòng dựa trên việc di chuyển các máy ảo giữa phần cứng dự phòng. Việc nó có phù hợp với ngân sách của bạn hay không sẽ phụ thuộc vào doanh nghiệp của bạn, vì chắc chắn bạn sẽ cần một số loại SAN để làm cho hoạt động đó hiệu quả.

Đừng giảm giá phân cụm chuyển đổi "truyền thống", mặc dù. Chắc chắn cũng có "chiến thắng" ở đó, nếu ứng dụng của bạn phù hợp với cấu hình như vậy.

Tôi tự hỏi nếu ông chủ của bạn đã nghĩ về các kịch bản thất bại thảm khốc (xây dựng bỏng, lũ lụt, lốc xoáy, trộm cắp, vv). Nếu điều đó chưa được lên kế hoạch, đây sẽ là cơ hội vàng để làm việc trong một số kế hoạch kinh doanh liên tục và dự phòng khắc phục thảm họa.

Nhận một số trợ giúp từ ai đó có thể đến và nghiên cứu doanh nghiệp của bạn và đưa ra khuyến nghị. Bạn sẽ không hối tiếc.

"Con đường này dẫn đến nhiều đau đớn và tổn thương ..."

Vậy, Kế hoạch liên tục của doanh nghiệp của bạn là gì? Bạn có kế hoạch khắc phục thảm họa?

Bạn đã thảo luận về nó? Viết nó xuống? KIỂM TRA NÓ?

Bạn cần có một cuộc trò chuyện thích hợp với "cao hơn" và thực sự đi đến tận cùng các yêu cầu về tính sẵn sàng cao vì nó khác nhau đối với các dịch vụ khác nhau.

Vậy điều gì thực sự là "điểm đau" mà họ cảm thấy sáng hôm đó?

Là nó?

• Điện thoại ngừng hoạt động? Vấn đề khá lớn (và có thể nhìn thấy). Và có - điều này sẽ cần một "giải pháp" nhưng hy vọng điều này nằm trong một thỏa thuận hỗ trợ?
• Trang web thất bại? OK - Hiển thị khá rõ nhưng không bất ngờ, và trừ khi bạn có sự hiện diện web LỚN thì không quan trọng. OK để có máy chủ này trong vài giờ.
• Cơ sở dữ liệu máy chủ xuống? Đáng sợ ... Hy vọng bạn có bản sao lưu tốt! Đừng để mất dữ liệu nếu không anh ta sẽ thất bại. Nhưng, miễn là dữ liệu được bảo mật thì đó là một máy chủ quan trọng và cần có kế hoạch khôi phục.
• Tập tin và in (và các ứng dụng nội bộ, vv). Đây là PITA cho hầu hết mọi người vì họ sẽ ngồi xung quanh và không làm gì cho một buổi sáng khi bạn sửa nó.

Tôi giả sử bạn đã mua phần cứng chất lượng cao cho các hệ thống chính của bạn? Tốt, vì lý do rẻ tiền trên phần cứng là một nền kinh tế sai lầm vì các máy chủ này đi kèm với mọi thứ "kép" trong hộp.

Tôi cũng sẽ giả sử bạn biết CÁCH xây dựng lại máy chủ, trao đổi quạt, cung cấp năng lượng, đặt giá máy chủ, định cấu hình mạng đường dẫn kép thành các thiết bị chuyển mạch dự phòng? Bạn đã làm điều này đủ lần để hiểu những gì hoạt động và những gì không, những gì là bình thường và những gì là sai lầm? Nếu không thì hãy nhờ giúp đỡ và đào tạo (hoặc ít nhất là thực hành và trải nghiệm).

Có lẽ rất nhiều vấn đề là CẢM XÚC. Họ không có manh mối rằng một vấn đề như vậy có thể xảy ra (và các máy chủ quan trọng như thế nào đối với doanh nghiệp của họ) và bạn không thực sự biết bạn đang làm gì (?) Một vấn đề về niềm tin?

Bạn cần phải có được tất cả các quyền trên TRƯỚC KHI đi xuống tuyến đường HA rất tốn kém. Doanh nghiệp có thể mua thiết bị đắt tiền này không (và hầu hết trong số đó, theo định nghĩa, sẽ chỉ được sử dụng trong một thất bại và thường không bao giờ được sử dụng!)

Evan đạt được một số điểm tốt, nhưng đây có thể là một số cách hiệu quả về chi phí cụ thể để có được thời gian phục hồi dưới 1 giờ khi đối mặt với thất bại.

Doanh nghiệp nhỏ có thể có nghĩa là phần cứng nhỏ, do đó, có thể không có nhiều chi phí để thực hiện một số điều đơn giản thực sự bổ sung một lượng đáng kể khả năng phục hồi khi gặp vấn đề. Ý tưởng chính là chỉ cần có thêm phần cứng sẵn sàng để đi.

Đầu tiên, hãy thoải mái với suy nghĩ về một IP ảo. Đó là địa chỉ IP mà người dùng sẽ nói chuyện, nhưng có thể cư trú trên bất kỳ máy chủ nào bạn cung cấp. Đây là địa chỉ IP mà bạn là người dùng và các ứng dụng sẽ muốn nói chuyện. Và nó sẽ là hữu ích nhất cho tối đa mọi giải pháp bạn đi. Có VIP nghĩa là bạn không cần phải cấu hình lại bất kỳ ứng dụng nào khi bị lỗi. Ngoài ra, hãy nhớ rằng việc có phần cứng dự phòng cũng có tác động làm tăng chi phí quản trị, thực hiện hai cập nhật cấu hình thay vì 1.

Nếu chúng tôi bắt đầu với máy chủ proxy định tuyến / web, thì có lẽ dễ nhất vì chúng sẽ không phải là bất kỳ trạng thái thực nào cần được lưu trữ trên chính hộp. Vì vậy, chỉ cần lấy một bản sao của cùng một hộp và cấu hình nó giống nhau. Tôi sẽ tiếp tục cắm cả vào phân đoạn mạng LAN và giả sử rằng internet của bạn đang ở trên một giao diện khác, hãy đổi cáp nếu chúng bị lỗi. Từ góc độ định tuyến, bạn đặt tất cả các máy khách lan của mình nhắm mục tiêu địa chỉ .1 (VIP) cho tuyến đường mặc định và máy chủ proxy cung cấp cho máy chủ A địa chỉ .2 và máy chủ B địa chỉ .3. Bằng cách này, cả hai có thể được quản lý để cập nhật cấu hình (áp dụng cho cả hai). Và tất cả những gì bạn phải làm để chuyển đổi dự phòng là xóa phần gán IP .1 khỏi .2 và chuyển nó sang .3 và di chuyển kết nối internet sang giao diện khác. Nó không quá phức tạp, dễ làm và dễ hiểu, và chi phí phần cứng thêm của hộp thứ hai. Nếu bạn có thể nhận được sự dư thừa ở phía internet, bạn có thể thêm một số phức tạp và nhận chuyển đổi dự phòng tự động bằng cách sử dụng một cái gì đó như VRRP.

Không có chi tiết cụ thể, thật khó để nói nhưng máy chủ web của bạn có thể đơn giản như vậy. Thêm máy chủ thứ hai với cấu hình giống hệt nhau, tạo vIP giữa hai máy và chuyển VIP sang bản sao lưu khi gặp sự cố. Tôi thường không bận tâm nếu trạng thái phiên bị mất khi chuyển đổi dự phòng (đó là một vấn đề nghiêm trọng để gây ra chuyển đổi dự phòng). Vì vậy, nếu người dùng phải đăng nhập lại, không có vấn đề lớn. Một lần nữa, vrrp có thể được sử dụng cho chuyển đổi dự phòng tự động.

Di chuyển lên DB của bạn, điều này phức tạp hơn đáng kể. Hầu hết các DB đều có một số loại mô hình chính / phụ, trong đó bạn sao lưu DB gốc vào thứ cấp, sau đó sao chép tất cả các nhật ký giao dịch hoặc các thay đổi DB sang thứ cấp. Một lần nữa, bạn có thể kết hợp điều này với VIP cho các ứng dụng / người dùng thực sự truy cập DB. Tuy nhiên, failover phức tạp hơn. Tùy thuộc vào sự thất bại của chính, bạn có thể cần phải thực sự đưa các ổ đĩa lên và chạy để sao chép và ghi nhật ký giao dịch còn sót lại. Sau đó đưa hoạt động thứ cấp. Nếu bạn có thể chịu đựng một số dữ liệu bị mất, thì bạn có thể mang lại hoạt động thứ cấp ngay lập tức. Sau khi chuyển đổi dự phòng, máy chủ B bây giờ là chính của bạn và bạn sẽ làm việc để khôi phục máy chủ A và biến nó thành bản sao lưu mới để sẵn sàng thất bại khi máy chủ b gặp sự cố.

Máy chủ tệp luôn là phần khó nhất, vì không giống như DB, rất khó để có được tính năng tích hợp của hệ thống tệp. Tuy nhiên, một số mức độ khả năng phục hồi có thể đạt được bằng cách có máy chủ thứ hai và viết một tập lệnh đơn giản để quét hệ thống tệp để thay đổi và sao chép bất kỳ tệp mới nào sang thứ cấp. Về cơ bản, bạn có thể chạy rsync trên một cron mà tôi tin tưởng để làm điều này. Một lần nữa, bạn sử dụng VIP mà bạn cung cấp cho người dùng, bạn sẽ chuyển sang nếu bạn thực hiện chuyển đổi dự phòng. Trong tập lệnh của bạn, tôi khuyên bạn nên kiểm tra để đảm bảo hệ thống là chủ sở hữu của VIP trước khi truyền tệp. Bạn thực sự thực sự thực sự không muốn rsync thực thi sai hướng và ghi đè lên bất kỳ thay đổi nào mà người dùng của bạn đang thực hiện. Điều này có thể mất một số tệp nếu chúng là một thất bại,

Tôi không biết bạn có thể làm gì với hệ thống điện thoại của mình ... điều đó thực sự phụ thuộc vào nhà cung cấp và cách thiết lập. Các nhà cung cấp có thể có một số giải pháp kệ cho khả năng phục hồi.

Một số lời cảnh báo cuối cùng. Hãy chắc chắn rằng bạn kiểm tra kỹ lưỡng bất kỳ thiết lập nào bạn sẽ thực hiện. Hãy chắc chắn rằng bạn biết làm thế nào để thất bại nó mà không mất thông tin quan trọng đó. Kiểm tra thử nghiệm để đảm bảo nó sẽ hoạt động khi bạn cần. Đảm bảo rằng bạn có các quy trình thay đổi cấu hình, cập nhật phần mềm, v.v ... được áp dụng đúng cho cả bản chính và bản sao lưu. Tin tốt là, có lẽ bạn có thể thực hiện chuyển đổi dự phòng khi bạn muốn đưa máy chủ xuống để nâng cấp, v.v. Đây không phải là thiết lập hoạt động tích cực, vì vậy bạn không biết liệu thứ cấp có hoạt động khi bạn cần không.

Tôi làm việc trong lĩnh vực viễn thông và thiết bị của chúng tôi rất dư thừa, kể cả trong hầu hết các trường hợp dự phòng địa lý đồ họa. Điểm thất bại số 1 của chúng tôi là sự dư thừa không được kiểm tra sau khi thay đổi và người dùng thực hiện các thay đổi không biết mô hình dự phòng hoạt động như thế nào. Tuy nhiên, chúng tôi có thêm một vấn đề là tất cả các thiết bị của chúng tôi cần hỗ trợ chuyển đổi dự phòng tự động trong không quá vài giây. Bạn có thể chấp nhận can thiệp thủ công vào các lỗi của bạn nếu bạn chỉ cần khởi động và chạy trong vòng 30 - 60 phút. Bạn chỉ cần chuẩn bị. Chúc may mắn.

Điểm của mọi người đều tuyệt vời nên chỉ cần một vài bình luận.

30 phút là không thể đảm bảo, đặc biệt là cho tất cả mọi thứ. Bạn có thể nói mục tiêu của nó, nhưng không có cách nào nó có thể là một sự đảm bảo, bởi vì luôn có yếu tố X. Bạn có thể có 2 đường dây ISP và một chiếc xe tải đâm vào tòa nhà và đưa cả hai ra ngoài vì bạn không nghĩ rằng việc chúng di chuyển từ hai đầu đối diện của tòa nhà là một ví dụ.

Khi bắt đầu cho chi phí, tăng gấp đôi mọi thứ. Bạn có 5 máy chủ nên bạn cần tăng gấp đôi. Tất cả không cần phải có trên phần cứng, bạn có thể ảo hóa, nhưng bạn hiểu ý tôi là gì. Trên hết, mọi thứ phải được HA nhận ra, điều này cũng sẽ làm tăng thêm chi phí, bạn có thể phát hiện ra rằng bạn sẽ phải thay thế bộ định tuyến của mình bằng một bộ định tuyến mới và ồ bạn cần 2 trong số chúng. Đừng quên tăng gấp đôi nguồn cấp điện và nhận máy phát điện, vì bạn không thể đảm bảo công ty điện sẽ sao lưu trong vòng 30 phút.

Những ví dụ này đang suy nghĩ ít nhiều là một thiết lập dự phòng nóng, đó là điều tôi nghi ngờ ông chủ của bạn đang nghĩ.

Điều tôi thấy tốt hơn cho doanh nghiệp nhỏ là thiết kế một kế hoạch để phục hồi và phân loại mọi thứ.

Chỉ ra các dịch vụ là

quan trọng (dừng kinh doanh)

quan trọng (kinh doanh chậm lại)

thói quen (kinh doanh có thể làm mà không cần nó trong một thời gian).

Chẳng hạn, điện thoại của trung tâm cuộc gọi của bạn rất quan trọng, vì vậy có thể một chiếc đáng để mua máy chủ thứ hai và ISP thứ hai và thời gian mất điện trung bình của bạn là khoảng 15 phút, vì vậy chúng tôi sẽ nhận được một UPS trong 60 phút (không nên quên các máy trạm hoặc). Bây giờ hãy nói rằng ERP chỉ quan trọng, có nghĩa là bạn có thể hoạt động mà không cần một chút. Có thể mọi người trong trung tâm cuộc gọi của bạn sử dụng nó, nhưng nếu nó bị hỏng, họ có thể quay lại bút và giấy hoặc notepad và sau đó cập nhật ERP sau. Thủ tục để làm điều đó nếu nó xuống có thể sẽ rẻ hơn sau đó cố gắng biến nó thành một dịch vụ quan trọng. Và những thứ thông thường có thể là một cái gì đó giống như máy in, ok nó là một nỗi đau nhưng chúng ta có thể làm cho một vài ngày nếu tất cả đi xuống.

Điều đó cũng cung cấp cho bạn lệnh để sửa chữa các công cụ nếu một ngày nào đó thực sự chạm vào người hâm mộ :)

Có thể không? Chắc chắn rồi. Có phải chăng? Có lẽ không phải là cho một "doanh nghiệp nhỏ", đặc biệt là nếu bạn có một ông chủ cho bạn những con số tùy ý để làm việc và anh ta đòi hỏi sự sẵn sàng cao từ một bộ phận CNTT bao gồm một lập trình viên bị suy đồi (nhìn thấy nó nhiều lần ở những nơi khác và không bao giờ đẹp cho mức độ căng thẳng của bạn, nếu tình huống của bạn giống như họ).

Có thể chuyển đổi dự phòng nhưng thường yêu cầu phần cứng dự phòng, SAN để chia sẻ dữ liệu giữa các máy chủ, v.v ... nói cách khác, chúc may mắn được tài trợ nếu họ không thuê một quản trị viên tận tâm để chăm sóc nó.

Phần cứng hệ thống cuộc gọi của bạn mà bạn đề cập là phần cứng chuyên dụng và bạn được ám chỉ là một người gọi. Bạn nên nói chuyện với nhà cung cấp về các tùy chọn để làm cho điều đó dư thừa. Đi cùng với điều đó có thể làm mất hỗ trợ ở nơi đầu tiên.

Các hệ thống khác mà bạn rất có thể có được một số dự phòng bằng cách đầu tư vào các giải pháp loại VMWare (hoặc Hyper-V hoặc XenServer, nhưng trước tiên tôi sẽ xem xét VMware và XenServer). Sau đó, bạn có thể xem xét việc nhận SAN, một vài máy chủ mạnh mẽ với chuyển mạch mạng nhanh và sử dụng LiveMotion để di chuyển các máy chủ ảo giữa các máy chủ phần cứng nếu có lỗi, cũng như cân bằng một số tải giữa các máy chủ khi có nhu cầu.

Bạn đã đề cập đến việc bạn đang chạy Linux trên các hệ thống đó. Thay vào đó, có tiền để có được nhiều máy chủ, thay vào đó, bạn có thể xem xét việc thiết lập DRBD bằng chương trình heartbeat và STONITH để sao chép dữ liệu giữa các máy chủ và tiếp quản khi không có sẵn; bạn sẽ xem xét việc thiết lập một hệ thống mà bạn đã sao chép từng máy chủ theo nghĩa đen, cũng như tăng gấp đôi mức tiêu thụ điện năng và tản nhiệt trong phòng máy chủ (nếu bạn có phòng máy chủ). Điều đó có thể được thực hiện cho chi phí phần cứng và sự tỉnh táo của bạn. Ngoài ra, bạn phải kiểm tra nó, bạn sẽ có thời gian chết trong khi định cấu hình nó và bạn vẫn có khả năng nó sẽ không hoạt động vì vẫn có khả năng các vấn đề cắt xén phải được xử lý (chia nhỏ não chẳng hạn).

Cuối cùng là kế hoạch để một vài hệ thống hoạt động như các hệ thống đá phiến trống và có một kế hoạch sao lưu thực sự tốt để cho phép bạn khôi phục dữ liệu vào một trong các hệ thống "trống" nếu máy chủ chết. Có phần cứng tại chỗ sẽ cung cấp cho bạn một số tùy chọn nếu / khi máy chủ chết; nhưng bạn vẫn sẽ có một số thời gian chết trong khi khôi phục dữ liệu và bạn cần hướng dẫn về cách cài đặt đúng ứng dụng của mình với máy chủ mới. Tùy thuộc vào tốc độ bạn làm việc và dữ liệu lớn như thế nào, bạn có thể có thời gian chết kéo dài từ vài giờ đến một hoặc hai ngày. Bạn làm có một, sao lưu được biết đến-tốt làm việc cho máy chủ của bạn, với một kế hoạch phục hồi tại chỗ, yeah?

Bạn có nên thử nó? Phản ứng đầu tiên của tôi là nếu bạn gãi đầu trước bất kỳ lời đề nghị nào hoặc cảm thấy một cái hố trong bụng khi cố gắng nghĩ ra những thứ này, thì bạn không nên. Bạn sẽ cần một công ty tư vấn để xem xét vấn đề và tính toán chi phí và thực hiện nó, hoặc bạn cần thuê một sysadmin chuyên dụng để làm việc đó cho công ty của bạn.

Thực tế là họ đang bảo bạn làm điều đó và bạn đang nói rằng bạn "chỉ là một lập trình viên được" thăng cấp "và bạn có PHB bảo bạn hãy dự phòng với thời gian thất bại tối đa là 30 phút là bạn tốt bụng của một con lạch.