Series blog này bao gồm 3 phần và sẽ thảo luận về các chiến lược khôi phục sau thảm họa (DR) mà bạn có thể thực hiện để đảm bảo dữ liệu của bạn luôn được an toàn và khối lượng công việc của bạn sẽ luôn sẵn sàng trong khi xảy ra thảm họa. Trong Phần I, chúng ta sẽ thảo luận về chiến lược AWS Region/multi-Availability Zone (AZ) DR.

Chiến lược được nêu trong bài đăng trên blog này đề cập đến cách tích hợp các dịch vụ được AWS quản lý vào chiến lược DR cho một Region. Điều này sẽ giảm thiểu chi phí bảo trì và vận hành, tạo ra các hệ thống có khả năng chịu lỗi, đảm bảo tính sẵn sàng cao và bảo vệ dữ liệu của bạn bằng các quy trình sao lưu / phục hồi mạnh mẽ. Chiến lược này sao chép khối lượng công việc trên nhiều AZ và liên tục sao lưu dữ liệu của bạn sang một Region khác với khả năng khôi phục tại thời điểm, vì vậy ứng dụng của bạn vẫn an toàn ngay cả khi tất cả AZ trong Region nguồn của bạn không thành công.

Implementing the single Region/multi-AZ strategy

Các phần sau liệt kê các thành phần của ứng dụng ví dụ được trình bày trong Hình 1, minh họa môi trường đa AZ với Region phụ được sử dụng để sao lưu. Kiến trúc ví dụ này đề cập đến một ứng dụng xử lý các giao dịch thanh toán đã được hiện đại hóa với AMS. Chúng tôi sẽ cho bạn biết dịch vụ AWS nào sử dụng và cách chúng hoạt động để duy trì chiến lược Region/multi-AZ.

Hình 1. Single Region / multi-AZ với Region phụ nhằm để sao lưu

Amazon EKS control plane

Amazon Elastic Kubernetes Service (Amazon EKS) chạy cơ sở hạ tầng quản lý Kubernetes trên nhiều AZ để loại bỏ một điểm lỗi duy nhất.

Điều này có nghĩa là nếu cơ sở hạ tầng của bạn hoặc AZ bị lỗi, nó sẽ tự động mở rộng các control plane nodes dựa trên tải, tự động phát hiện và thay thế các control plane instances không lành mạnh và khởi động lại chúng trên các AZ trong Region nếu cần.

Amazon EKS data plane

Thay vì tạo các Amazon Elastic Compute Cloud (Amazon EC2) instance riêng lẻ, hãy tạo các worker nodes bằng cách sử dụng nhóm Amazon EC2 Auto Scaling. Kết nối nhóm vào một cụm và nhóm sẽ tự động thay thế bất kỳ nodes nào bị tắt hoặc bị lỗi nếu AZ bị lỗi. Điều này đảm bảo rằng cụm luôn có thể chạy khối lượng công việc của bạn.

Amazon ElastiCache

Amazon ElastiCache liên tục giám sát trạng thái của primary node. Nếu primary node bị lỗi, nó sẽ thăng cấp read replica với độ trễ sao chép ít nhất thành bản chính. Sau đó, một read replica thay thế được tạo và cung cấp trong cùng một AZ với primary node bị lỗi. Điều này nhằm đảm bảo tính khả dụng cao của dịch vụ và ứng dụng.

Một cụm ElastiCache for Redis (đã tắt chế độ cụm) với nhiều nodes sẽ có ba loại endpoints: primary endpoint, reader endpoint và node endpoints. Primary endpoint là tên DNS luôn phân giải đến primary node trong cụm.

Amazon Redshift

Hiện tại,  Amazon Redshift chỉ hỗ trợ triển khai  từ một AZ. Mặc dù có nhiều cách để giải quyết vấn đề này, nhưng chúng tôi đang tập trung vào việc di dời cụm. Phần II và III của loạt bài này sẽ chỉ cho bạn cách triển khai dịch vụ này trong triển khai DR nhiều Region.

Việc di chuyển cụm cho phép Amazon Redshift di chuyển một cụm đến một AZ khác mà không bị mất dữ liệu hoặc thay đổi đối với các ứng dụng của bạn. Khi Amazon Redshift chuyển một cụm đến một AZ mới, cụm mới có cùng endpoint với cụm ban đầu. Các ứng dụng của bạn có thể kết nối lại với endpoint và tiếp tục hoạt động mà không cần sửa đổi hoặc mất dữ liệu.

Lưu ý: Amazon Redshift cũng có thể định vị lại các cụm trong các tình huống lỗi không phải do AZ, chẳng hạn như khi các vấn đề trong AZ hiện tại ngăn cản hoạt động tối ưu của cụm hoặc để cải thiện tính khả dụng của dịch vụ.

Amazon OpenSearch Service

Việc triển khai các data nodes của bạn ở ba AZ với Amazon OpenSearch Service (trước đây là Amazon Elasticsearch Service) có thể cải thiện tính khả dụng của miền và tăng khả năng chịu đựng các lỗi AZ của khối lượng công việc của bạn.

Amazon OpenSearch Service của Amazon tự động triển khai tại ba AZ khi bạn chọn triển khai multi-AZ. Phân phối này giúp ngăn chặn thời gian ngừng hoạt động của cụm nếu AZ gặp sự cố gián đoạn dịch vụ. Khi bạn triển khai trên ba AZ, Dịch vụ Amazon OpenSearch Service sẽ phân phối các master nodes đều trên cả ba AZ. Bằng cách đó, trong trường hợp hiếm hoi xảy ra sự cố ở AZ, hai master nodes sẽ vẫn sẵn sàng.

Amazon OpenSearch Service cũng phân phối các primary shards và các replica shards tương ứng của chúng đến các khu vực khác nhau. Ngoài việc phân phối các shards theo AZ, Amazon OpenSearch Service còn phân phối chúng theo từng node. Khi bạn triển khai các data nodetrên ba AZ với một bản sao được kích hoạt, các shards được phân phối trên ba AZ.

Lưu ý: Để biết thêm thông tin về cấu hình đa AZ, vui lòng tham khảo AZ disruptions table.

Amazon RDS PostgreSQL

Amazon Relational Database Service (Amazon RDS) tự động xử lý các failover để bạn có thể tiếp tục các hoạt động cơ sở dữ liệu nhanh nhất có thể.

Trong triển khai Multi-AZ, Amazon RDS tự động cung cấp và duy trì một bản sao dự phòng đồng bộ ở một AZ khác. Phiên bản DB chính được sao chép đồng bộ trên các AZ thành một bản sao dự phòng. Nếu AZ hoặc cơ sở hạ tầng bị lỗi, Amazon RDS sẽ thực hiện failover tự động sang chế độ standby. Điều này giảm thiểu sự gián đoạn cho các ứng dụng của bạn mà không cần sự can thiệp của quản trị viên.

Sao lưu dữ liệu trên các Regions

Dưới đây là cách các dịch vụ được quản lý sao lưu dữ liệu vào Region phụ:

• Quản lý snapshots nhanh của khối lượng liên tục cho Amazon EKS với Velero. Amazon Simple Storage Service (Amazon S3) lưu trữ các snapshot này trong một bucketS3 ở primary Region. Amazon S3 sao chép các snapshot này sang một bucket S3 ở một Region khác thông qua tính năng sao chép giữa các Region của S3.
• Tạo snapshot thủ công của các cụm Amazon OpenSearch Service, được lưu trữ trong một kho lưu trữ đã đăng ký như Amazon S3. Bạn có thể thực hiện việc này theo cách thủ công hoặc tự động hóa thông qua hàm AWS Lambda , hàm này tự động sao chép không đồng bộ các objects sang các Regions.
• Sử dụng sao lưu thủ công và sao chép lệnh gọi API cho Amazon ElastiCache để thiết lập chiến lược khôi phục và snapshot trong Region phụ. Bạn có thể sao lưu dữ liệu của mình vào một bucket S3 theo cách thủ công hoặc tự động thông qua Lambda. Sau khi dữ liệu của bạn được sao lưu, snapshot của cụm ElastiCache sẽ được lưu trữ trong bucket S3. Sau đó, cross-Region replication của S3 sẽ sao chép không đồng bộ bản sao lưu vào một bucket S3 trong Region phụ.
• Tự động chụp incremental snapshot dữ liệu của bạn theo định kỳ với Amazon Redshift và lưu chúng vào Amazon S3. Bạn có thể kiểm soát chính xác thời điểm tạo snapshot và có thể tạo lịch chụp snapshot và đính kèm nó vào một hoặc nhiều cụm. Bạn cũng có thể định cấu hình bản sao cross-Region snapshot, tự động sao chép các snapshots thủ công và tự động của bạn sang một Region khác.
• Sử dụng AWS Backup  để hỗ trợ các tài nguyên AWS và các ứng dụng của bên thứ ba. AWS Backup sao chép các bản sao lưu RDS sang nhiều Region theo yêu cầu hoặc tự động như một phần của kế hoạch sao lưu theo lịch trình.

Lưu ý: Bạn có thể thêm một lớp bảo vệ cho các bản sao lưu của mình thông qua AWS Backup Vault Lock và S3 Object Lock.

Kết luận

Chiến lược single Region/multi-AZ bảo vệ khối lượng công việc của bạn trước thảm họa làm gián đoạn trung tâm dữ liệu Amazon bằng cách sao chép khối lượng công việc trên nhiều AZ trong cùng một Region. Blog này cho bạn biết cách các dịch vụ được AWS quản lý tự động không thành công giữa các AZ mà không bị gián đoạn khi gặp thảm họa cục bộ và cách sao lưu vào một Khu vực riêng biệt đảm bảo bảo vệ dữ liệu.

Trong bài đăng tiếp theo, chúng ta sẽ thảo luận về chiến lược dự phòng ấm đa Region cho cùng một ngăn xếp ứng dụng được minh họa trong bài đăng này.

Thông tin liên quan

• Disaster Recovery on AWS Series
• Use Fault Isolation to Protect Your Workload
• Design your Workload to Withstand Component Failures

---

Bài được dịch từ bài viết trên AWS Blogs, bạn có thể xem bài viết gốc tại đây.