Những gì bạn đang yêu cầu là, về cơ bản, tính sẵn sàng cao. Để làm cho một hệ thống có sẵn cao, bạn cần ba điều:
- Loại bỏ những điểm thất bại duy nhất
- Một cơ chế để chuyển từ điểm cuối sang điểm khác
- Một cách để phát hiện thất bại
Loại bỏ những điểm thất bại duy nhất
Trong trường hợp của S3, điểm số 1 được giải quyết, như Evgeny đã chỉ ra, bằng cách sao chép vùng chéo S3 .
Tuy nhiên, sao chép không phải là tức thời và bạn sẽ muốn kiểm tra xem bạn có muốn nhân rộng ứng dụng của mình hay không. Trong trường hợp mất điện, có thể một cái gì đó được ghi vào thùng nguồn của bạn vẫn chưa được thực hiện (không được sao chép) sang nhóm đích. Bạn phải nghĩ làm thế nào ứng dụng sẽ xử lý một kịch bản như vậy. Điều đó thực sự phụ thuộc vào loại dữ liệu, những gì đang được thực hiện với nó và (có khả năng) người dùng cuối hoặc kỳ vọng quản lý.
Một cơ chế để chuyển từ điểm cuối sang điểm khác
Đối với S3, điều đó có nghĩa là trong trường hợp ngừng hoạt động, bạn muốn ứng dụng dừng đọc và viết từ / sang nhóm A và sử dụng nhóm B thay thế.
Làm thế nào để đạt được điều này là, theo như tôi biết, cho đến bây giờ. Một số dịch vụ AWS khác cung cấp dự phòng hoàn toàn minh bạch, nhưng hiện tại tôi không biết điều đó cho S3.
Có nhiều cách khác nhau để đạt được điều này. Một ví dụ là sử dụng proxy sẽ định tuyến lưu lượng đến nhóm thích hợp. Trong thời gian ngừng hoạt động, bạn sẽ cập nhật / thay đổi proxy để định tuyến lưu lượng truy cập đến một nhóm không bị ảnh hưởng bởi sự cố ngừng hoạt động. Một ví dụ khác là làm cho cấu hình ứng dụng của bạn động và lưu trữ nó trong kho lưu trữ khóa-giá trị. Nếu ứng dụng đọc lưu trữ KV cho các thuộc tính được cập nhật thường xuyên, bạn có thể chuyển đổi nơi bạn đọc và ghi vào (Spring Cloud có hỗ trợ cho trình nghe "Môi trường thay đổi" chẳng hạn).
Một cách để phát hiện thất bại
Vâng, đó là một điều dễ dàng, tôi nghĩ. Đơn giản chỉ cần thiết lập một vòng lặp ghi + đọc và cảnh báo ngay khi có gì đó không đúng :)
Ghi chú kết thúc
- Nếu ứng dụng của bạn được ghi vào thùng, bạn phải suy nghĩ về những gì sẽ xảy ra trong trường hợp không thành công. Có tất cả các ghi đã làm cho nó đến thùng đích (và bạn có thể nói)? Bạn có thể cho phép ghi vào nhóm đích (biến nó thành "chính" mới không? Lập kế hoạch cẩn thận sẽ tránh được tình trạng chia tách hoặc mất các bản cập nhật.
- Tùy thuộc vào SLA của bạn, bạn có thể muốn các điểm # 2 và # 3 được tự động hoặc tự động. Điều đó đòi hỏi phải lập kế hoạch, công cụ và thử nghiệm bổ sung, nhưng các kịch bản được viết tốt sẽ luôn phản ứng nhanh hơn và theo những cách dễ đoán hơn so với con người (thất bại cũng có thói quen khó chịu xảy ra vào giữa đêm khi sự can thiệp của con người là một điều nguy hiểm.
- Điều đáng nói là ngay cả việc sao chép xuyên khu vực cũng không loại bỏ hoàn toàn các điểm thất bại. Chắc chắn, nếu một khu vực đi xuống, bạn được bảo hiểm. Nhưng chuyện gì sẽ xảy ra nếu mất điện AWS trên toàn nước Mỹ? Azure đã ngừng hoạt động một phần nhưng toàn cầu vào năm ngoái và một năm 2014 cũng vậy.