Trong phần I của series này, chúng tôi đã giới thiệu khái niệm khôi phục sau thảm họa (DR) bằng việc sử dụng các dịch vụ được quản lý thông qua chiến lược single AWS Region. Trong phần hai, chúng tôi giới thiệu cách tiếp cận sao lưu và khôi phục multi-Region. Với cách tiếp cận này, bạn có thể triển khai giải pháp DR trong nhiều Region, nhưng nó sẽ được liên kết với RPO/RTO dài hơn. Sử dụng chiến lược sao lưu và khôi phục sẽ bảo vệ các ứng dụng và dữ liệu trước các sự kiện quy mô lớn là một giải pháp hiệu quả về chi phí, nhưng sẽ dẫn đến thời gian ngừng hoạt động lâu hơn và mất nhiều dữ liệu hơn trong trường hợp xảy ra thảm họa so với các chiến lược khác như thể hiện trong Hình 1 .
Hình 1. Các chiến lược DR
Thực hiện chiến lược multi-Region/sao lưu và khôi phục
Sử dụng nhiều Region để đảm bảo khả năng phục hồi trong những trường hợp mất điện nghiêm trọng trên diện rộng. Region phụ bảo vệ khối lượng công việc khỏi việc không thể chạy trong một Region nhất định, vì chúng rộng và phân tán về mặt địa lý.
Tổng quan kiến trúc
Sơ đồ ứng dụng được trình bày trong Hình 2.1 và 2.2 đề cập đến một ứng dụng xử lý các giao dịch thanh toán, được hiện đại hóa để sử dụng các dịch vụ được quản lý trong AWS Cloud. Trong bài đăng này, chúng tôi sẽ cho bạn thấy các dịch vụ AWS nào sử dụng và cách chúng hoạt động để duy trì chiến lược multi-Region/sao lưu và khôi phục.
Những hình sau cho thấy cách thực hiện thành công chiến lược sao lưu và khôi phục và failover thành công đối với khối lượng công việc của bạn. 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 các hình, hoạt động như sau:
- Amazon Route 53 giám sát kiểm tra tình trạng các endpointscủa ứng dụng
- Nếu kiểm tra tình trạng của Route 53 không thành công, cảnh báo Amazon CloudWatch sẽ nhắc nhở Amazon Simple Notification Service (Amazon SNS) topic
- Chủ đề SNS này gọi hàm AWS Lambda, hàm này sẽ gọi pipeline cơ sở hạ tầng để bắt đầu cung cấp cụm trong Region thứ cấp.
Hình 2.1. Sao lưu Multi-Region
Hình 2.2. Khôi phục Multi-Region
Route 53
Route 53 health checks theo dõi tình trạng và hiệu suất của các ứng dụng web, máy chủ web và các tài nguyên khác của bạn. Health checks là cần thiết để định cấu hình chuyển đổi dự phòng DNS trong Route 53. Khi một ứng dụng hoặc tài nguyên ngưng hoạt động, bạn sẽ cần bắt đầu quy trình chuyển đổi dự phòng thủ công để tạo tài nguyên trong Region phụ. Trong kiến trúc của chúng tôi, chúng tôi sử dụng cảnh báo CloudWatch để tự động thông báo về những thay đổi trong tình trạng hoạt động.
Vui lòng xem bài đăng trên blog Creating Disaster Recovery Mechanisms Using Amazon Route 53 để biết thêm về các cơ chế DR sử dụng Amazon Route 53.
Amazon EKS control plane
Amazon Elastic Kubernetes Service (Amazon EKS) tự động điều chỉnh các control plane instances dựa trên tải trọng, tự động phát hiện và thay thế các control plane không hoạt động tốt, đồng thời khởi động lại chúng trên các Availability Zones trong Region nếu cần. Bởi vì các cụm on-demand được cung cấp trong Region thứ cấp, AWS cũng quản lý control plane theo cách tương tự.
Amazon EKS data plane
Cách tốt nhất là tạo các worker nodes bằng cách sử dụng các nhóm Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling thay vì tạo các phiên bản EC2 riêng lẻ và kết hợp chúng vào cụm. Điều này là do nhóm Amazon EC2 Auto Scaling tự động thay thế bất kỳ nodes nào bị terminate hoặc bị lỗi, điều này đảm bảo rằng cụm luôn có khả năng chạy khối lượng công việc của bạn.
Amazon EKS control plane và data plane sẽ được tạo theo yêu cầu ở Region phụ trong thời gian ngừng hoạt động thông qua Infrastructure-as-a-Code (IaaC) như AWS CloudFormation, Terraform, v.v. Bạn nên chuẩn bị trước tất cả các yêu cầu mạng như virtual private cloud (VPC), subnets, route tables, gateways và triển khai cụm Amazon EKS trong thời gian ngừng hoạt động ở Region chính.
Như được hiển thị trong the Backup and restore your Amazon EKS cluster resources using Velero, bạn có thể sử dụng công cụ của bên thứ ba như Velero để quản lý snapshots của các persistent volumes. Những snapshots này có thể được lưu trữ trong bucket Amazon Simple Storage Service (Amazon S3) ở Region chính, sẽ được sao chép sang bucket S3 ở Region khác thông qua sao chép cross-Region
Trong thời gian ngừng hoạt động ở Region chính, bạn có thể sử dụng công cụ trong Region phụ để khôi phục volumes từ snapshots trong cụm chờ.
OpenSearch Service
Đối với các miền chạy Amazon OpenSearch Service, OpenSearch Service sẽ tạo snapshots tự động hàng giờ và lưu giữ tới 336 trong 14 ngày. Những snapshots này chỉ có thể được sử dụng để khôi phục cụm trong cùng Region với cụm OpenSearch chính.
Bạn có thể sử dụng API OpenSearch để tạo snapshots thủ công từ một cụm OpenSearch, có thể được lưu 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ạo một hàm Lambda đã lên lịch dựa trên RPO của cụm, hàm này sẽ tự tạo snapshots thủ công và lưu vào bucket S3. Sau đó, sao chép cross-Region của Amazon S3 sẽ tự động asynchronous copy các objects trong bucket S3.
Bạn có thể khôi phục các cụm OpenSearch Service bằng cách tạo cụm theo yêu cầu thông qua CloudFormation và sử dụng các API OpenSearch để khôi phục snapshots từ bucket S3.
Amazon RDS Postgres
Amazon Relational Database Service (Amazon RDS) có thể sao chép các bản sao lưu liên tục giữa các Region. Bạn có thể cấu hình cơ sở dữ liệu Amazon RDS của mình để sao chép snapshot và transaction logs đến Region mà bạn chọn.
Nếu quy tắc sao lưu liên tục cũng chỉ định tạo bản sao cross-account hoặc cross-Region, thì AWS Backup sẽ tạo snapshots từ bản backup , sao chép snapshots đó vào kho, sau đó xóa snapshot nguồn. Để sao lưu liên tục Amazon RDS, AWS Backup tạo snapshot cứ 24 giờ một lần và lưu trữ transaction logs 5 phút một lần trong Region. Cài đặt Backup Frequency chỉ áp dụng cho các bản sao lưu cross-Region của các bản sao lưu này. Backup Frequency xác định tần suất sao lưu AWS:
- Tạo snapshot tại thời điểm đó từ snapshots hiện có cộng với tất cả transaction logs mới
- Sao chép snapshots sang các Region khác
- Xóa snapshots (vì nó chỉ được tạo để sao chép)
Để biết thêm thông tin, hãy tham khảo bài đăng trên blog về Point-in-time recovery and continuous backup for Amazon RDS with AWS Backup.
ElastiCache
Bạn có thể xuất và nhập các lệnh gọi API sao lưu và sao chép cho Amazon ElastiCache để phát triển chiến lược khôi phục và chụp nhanh trong Region phụ. Bạn có thể sao lưu thủ công và sao lưu bản sao lưu đó vào bucket S3 hoặc tạo một cặp hàm Lambda để chạy theo lịch trình nhằm đáp ứng các yêu cầu của RPO. Các hàm Lambda sẽ tạo một bản sao lưu thủ công, bằng cách tạo một file .rdb vào bucket S3. Sau đó, tính năng sao chép cross-Region của Amazon S3 sẽ tạo asynchronous copy của bản sao lưu vào bucket S3 trong Region phụ.
Bạn có thể sử dụng CloudFormation để tạo một cụm ElastiCache theo yêu cầu và sử dụng các properties CloudFormation như SnapshotArns and SnapshotName để trỏ đến bản sao lưu ElastiCache mong muốn được lưu trữ trong Amazon S3 để bắt đầu cụm trong Region phụ.
Amazon Redshift
Amazon Redshift chụp nhanh tự động, gia tăng dữ liệu của bạn theo định kỳ và lưu chúng vào Amazon S3. Ngoài ra, bạn có thể chụp nhanh thủ công dữ liệu của mình bất cứ khi nào bạn muốn.
Để kiểm soát chính xác thời điểm chụp nhanh, bạn có thể tạo lịch chụp nhanh và đính kèm vào một hoặc nhiều cụm. Bạn cũng có thể định cấu hình cross-Region snapshot copy, sẽ tự động sao chép tất cả các snapshots thủ công và tự động của bạn sang Region khác.
Trong thời gian ngừng hoạt động, bạn có thể tạo cụm Amazon Redshift theo yêu cầu thông qua CloudFormation và sử dụng các thuộc tính CloudFormation như SnapshotIdentifier để khôi phục cụm mới từ snapshots đó.
Lưu ý: Bạn có thể thêm một lớp bảo vệ bổ sung cho các bản sao lưu của mình thông qua AWS Backup Vault Lock, S3 Object Lock, và Encrypted Backups.
Kết luận
Với việc áp dụng nhiều hơn các dịch vụ được quản lý trong cloud, bạn cần phải nghĩ ra những cách sáng tạo để triển khai giải pháp DR tiết kiệm chi phí. Cách tiếp cận sao lưu và khôi phục được cung cấp trong bài đăng này sẽ giảm chi phí thông qua các yêu cầu RPO / RTO, đồng thời cung cấp giải pháp để sử dụng các dịch vụ được AWS quản lý.
Trong bài đăng tiếp theo, chúng ta sẽ thảo luận về chiến lược hoạt động/ multi-Region active cho cùng một ngăn xếp ứng dụng được minh họa trong bài đăng này.
Các bài viết khác trong loạt bài này
Thông tin liên quan
Tìm kiếm thêm nội dung kiến trúc? AWS Architecture Center cung cấp các sơ đồ kiến trúc tham chiếu, các giải pháp kiến trúc đã được hiệu chỉnh, các phương pháp hay nhất được kiến trúc tốt nhất, các mẫu, biểu tượng và hơn thế nữa!
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.
AWS Study Group 