Khi nào là thời điểm thích hợp để giới thiệu tính sẵn sàng cao cho trang web?

Khi nào là thời điểm thích hợp để giới thiệu tính sẵn sàng cao cho trang web?

Có nhiều bài viết về các tùy chọn có sẵn cao. Tuy nhiên, đó không phải là điều hiển nhiên khi KHI là thời điểm thích hợp để chuyển từ máy chủ đơn sang cấu hình khả dụng cao.

Vui lòng xem xét tình huống của tôi:
http://www.postjobfree.com là trang web 24/7 với lưu lượng truy cập đáng kể:
http://www.similarweb.com/website/postjobfree.com

Hiện tại tôi chạy nó trên một máy chủ duy nhất: cả máy chủ web IIS 7.0 và SQL Server 2008 đều chạy trên cùng một hộp phần cứng.

Thỉnh thoảng (~ một lần mỗi tháng) ~ 5 phút ngừng hoạt động thường do khởi động lại được yêu cầu bởi một số cập nhật Windows Server. Thông thường thời gian chết được lên kế hoạch và xảy ra vào ban đêm. Vẫn còn khó chịu, vì Google Bot và một số người dùng vẫn hoạt động vào ban đêm.

Doanh thu trang web hiện tại ở mức ~ $ 8K / tháng.

Tôi xem xét chuyển sang cấu hình hai máy chủ (cụm máy chủ web gồm 2 máy chủ web và cụm 2 Máy chủ SQL được lưu trữ trên hai máy chủ phần cứng).

Ưu điểm:
1) Tính sẵn sàng cao (về lý thuyết không có thời gian chết). Ngay cả khi một trong các máy chủ ngừng hoạt động - một máy chủ khác sẽ tiếp quản.
2) Không mất dữ liệu: không có cụm SQL, có thể mất tối đa một ngày dữ liệu trong trường hợp lỗi phần cứng (chúng tôi thực hiện sao lưu hàng ngày).

Nhược điểm:
1) Nhiều nỗ lực hơn để thiết lập và duy trì cấu hình như vậy.
2) Chi phí lưu trữ cao hơn. Thay vì ~ $ 600 / tháng, nó sẽ là khoảng $ 1200 / tháng.

Bạn có đề xuất gì?

Câu trả lời ngắn gọn: Khi hết thời gian hoặc rủi ro của nó khiến bạn tốn nhiều tiền hơn sẽ khiến bạn phải trả giá cao.

Nó về cơ bản là một quyết định kinh tế. Làm ví dụ $ 8k / tháng ngụ ý rằng việc ngừng hoạt động trong 2 giờ sẽ khiến bạn mất 22 đô la. Nếu bạn có thể định cấu hình hệ thống của mình sao cho bạn có thể đi từ đầu đến một trang web đầy đủ chức năng trong 2 giờ, thì tính sẵn sàng cao sẽ chỉ mang lại cho bạn 22 đô la chức năng trên mức đó.

Nói cách khác, bạn có thể tiết kiệm tiền trừ khi / cho đến khi bạn có 54 giờ thời gian ngừng hoạt động không thể chấp nhận được trong một tháng nhất định.

Các bên liên quan / dân kinh doanh của bạn (có thể là bạn!) Phải quyết định

• mất doanh thu chấp nhận được
• hậu quả mất danh tiếng, sự kính trọng vv
• mất dữ liệu chấp nhận được ( mục tiêu điểm khôi phục )
• thời gian chết chấp nhận được ( Mục tiêu thời gian phục hồi )

Mất doanh thu rất dễ để định lượng: phần còn lại không thể được trả lời ở đây xin lỗi ...

Tôi nghĩ rằng hầu hết người dùng có thể xử lý một chút thời gian chết theo lịch trình. Hãy xem xét rằng ebay có cập nhật hàng tuần vào các tối thứ sáu và đôi khi giá thầu đôi khi không hoạt động. Ngân hàng trực tuyến của ngân hàng (australian) của tôi đã lên kế hoạch ngừng hoạt động hàng giờ mỗi tuần. Twitter luôn ngoại tuyến mọi lúc. Heroku / EC2 đã ngừng hoạt động trong nhiều ngày gần đây.

Tôi sẽ giữ nó trong viễn cảnh đó, nếu bạn thực sự chỉ nói 5 phút mỗi tháng, thì bạn đang làm một công việc khá tốt như một sysadmin.

Bạn đã từng đề cập đến Google như một yếu tố về lập chỉ mục, nhưng cũng có thể đáng để xem xét tác động mà độ trễ / phản ứng của trang web có thể gây ra đối với SEO. Đó là một hộp đen và tất cả những thứ đó, rất khó để định lượng - mặc dù với giá trị của nó, Matt Cutts cho rằng đó là một người chơi . Tôi sẽ quan tâm nhiều hơn đến danh tiếng, như những người khác đã tuyên bố.

Hãy nhớ rằng HA, giống như bảo mật, không phải là một sản phẩm, mà là một quá trình.

Ví dụ, sao chép cơ sở dữ liệu sẽ chỉ đưa bạn đến điểm mà mỗi gương của cơ sở dữ liệu sẽ có thể tự tiếp tục, nhưng bạn cũng sẽ cần một chiến lược để đồng bộ hóa sau khi các thành phần bị lỗi được thay thế.

Hãy xem xét một hệ thống đặt hàng làm ví dụ: khách hàng gửi đơn đặt hàng và trong quá trình xử lý, hệ thống vật lý mà anh ta đã nói không thành công sau khi lưu trữ thông tin đơn hàng trong bản sao cơ sở dữ liệu. Không kiên nhẫn, khách hàng nhấn "gửi" lại và được chuyển đến một máy chủ khác chấp nhận đơn đặt hàng. Nếu cơ sở dữ liệu của bạn đồng bộ hóa lại bằng cách đơn giản phát lại các câu lệnh INSERT bị thiếu ở phía bên kia, thì thứ tự sẽ được sao chép, có thể không phải là điều bạn muốn.

Như @Slartibartfast đã đề xuất, tất cả đều đi đến một quyết định kinh tế, tuy nhiên tôi khuyên bạn cũng nên lên kế hoạch một vài năm trong tương lai ở đây. Nếu bạn muốn có một thiết lập HA thích hợp thì bây giờ sẽ là thời điểm tốt để dành tài nguyên cho công việc chuẩn bị.

Trong khi bạn nghĩ về điều này, tôi nghĩ rằng bạn xem xét việc thiết lập một trang "cá voi thất bại".

Có rất nhiều cách để làm điều này nhưng combo aws của route53 và s3 hoạt động tốt trên các trang web nhỏ của tôi.

Tôi thiết lập tên miền với các kiểm tra sức khỏe để khi thất bại DNS sẽ gửi người dùng đến người dùng đến một trang html tĩnh ngồi trong s3; Chi phí bên cạnh không có gì.

Theo kinh nghiệm của tôi, trang web của bạn nói rằng "xin lỗi mọi thứ đã bị hỏng nhưng chúng tôi đang làm việc với nó" tạo ra một thế giới khác biệt cho người dùng. Một tài khoản Twitter nơi bạn có thể giao tiếp với người dùng thậm chí còn tốt hơn.

Điều này đi một thời gian dài để giảm thiểu "mất danh tiếng" có thể là tác động đáng kể nhất của việc ngừng hoạt động.

xem: https://aws.amazon.com/bloss/aws/create-a-backup-website-USE-route-53-dns-failover-and-s3-website-hosting/ để biết hướng dẫn về cách thiết lập.

Chuyển đổi dự phòng xã hội của DynDns http://dyn.com/managed-dns/social-failover/ là một loại mô phỏng.

Bạn có thể tự cuộn và thực hiện kiểm tra sức khỏe của mình và sau đó kịch bản thay đổi DNS, miễn là các bản ghi DNS của bạn có chỉ số TTL thấp và bạn có một số cách để thao tác chúng theo chương trình.

Bạn đã từng cân nhắc sử dụng thứ gì đó như EC2 sẽ cho phép bạn mở rộng quy mô linh hoạt và cũng phủ nhận khuyết điểm của bạn chưa? Cuối cùng, đó là một quyết định kinh tế nếu sử dụng EC2 có đáng hay không, nhưng ít nhất, đó là một lựa chọn để xem xét.

Để tránh mất dữ liệu, bạn nên xem xét cấu hình Raid trước các cụm. Bạn cũng nên định cấu hình IP Failover mà bạn có thể chuyển từ máy chủ này sang máy chủ khác trong trường hợp xảy ra thảm họa mà không phải chờ lan truyền DNS.