Disaster Recovery trên AWS
- Tháng Mười Hai 28, 2021
- Posted by: Huyền Khánh
- Category: Uncategorized
Một số người đã làm về AWS, nhưng có thể các bạn chưa biết biết Disaster Recovery là gì. Vậy thì hôm nay chúng ta cùng trò chuyện qua một chút về Disaster Recovery trên Cloud nhé.
Disaster Recovery trong tiếng Việt thì hơi “chuối” 1 chút, tuy nhiên cũng có cái tên, gọi là phục hồi sau thảm họa. Nghe tên tiếng Việt thì có vẻ hơi kỳ kỳ, và làm người ta liên tưởng đến mấy anh quân đội giúp đỡ người dân, nên là trong kỹ thuật người ta thường sử dụng tên DR hay gọi là những chiến lược DR. Nói tới DR, thì các bên kỹ thuật xây dựng các hệ thống on-premise sẽ nghĩ tới việc di chuyển các thiết bị vật lý hoặc đồng bộ dữ liệu tới các Site khác. Tuy nhiên khi làm việc với các hệ thống trên Cloud, đặc biệt là AWS, việc này sẽ có 1 vài điểm hơi khác 1 chút.
Nhìn chung, các hệ thống phục hồi trên Cloud nói chung và AWS nói riêng sẽ ở mức đơn giản, nhanh chóng, có thể thực hiện test thường xuyên, liên tục và tránh việc phải quản lý resource quá nhiều. Thậm chí chúng ta còn có thể phục hồi một cách tự động nếu có thời gian và công sức nghiên cứu thêm.
Khi học AWS cơ bản, chúng ta rất dễ bắt gặp khái niệm high availability (HA). Vậy HA và DR có gì giống và khác nhau?
Cả 2 tiêu chí này đều tập trung vào những best practice cho hệ thống, phòng tránh và giải quyết những vấn đề liên quan đến lỗi hệ thống và tự động failover. Tuy nhiên khi nói tới HA, chúng ta sẽ tập trung vào các thành phần con nhỏ lẻ và khả năng phục hồi của từng thành phần này khi có sự tác động bởi những sự kiện nào đó, giúp hệ thống vẫn hoạt động trơn tru và không có vấn đề xảy ra. Ngược lại, khi nói tới DR, chúng ta nói tới việc thảm họa xảy ra trên diện rộng, dẫn tới toàn bộ hệ thống sẽ không thể truy cập được, nên sẽ cần 1 vài cách tiếp cận khác HA, rộng lớn hơn HA thông thường, chẳng hạn là deploy cả hệ thống lên một khu vực khác.
DR không phải là thứ được nhận định một cách độc lập. DR nên là 1 thành phần nằm trong một Business Continuous Plan (BCP). Một BCP sẽ liên quan tới rất nhiều bên khác nhau, tuy nhiên khi nói tới hệ thống, đặc biệt là sử dụng AWS, sẽ cần đánh giá 1 vài thành phần chính như sau:
- Business Impact Analysis: Phân tích mức độ ảnh hưởng tới business. Phần này sẽ đánh giá đến việc hệ thống bị ảnh hưởng tới đâu, phạm vi thế nào, tổn thất bao nhiêu.
- Risk assessment: Đánh giá rủi ro đưa ra tần suất xuất hiện của rủi ro, loại rủi ro, ảnh hưởng của rủi ro.
Trong quá trình đánh giá chiến lược DR trên Cloud, người ta quan tâm tới 2 yếu tố: RPO và RTO.
- RPO (Recovery Point Objective) là khoảng thời gian tối đa mà hệ thống có thể chấp nhận được khi phục hồi về điểm dữ liệu gần nhất. Nói đơn giản, là việc hệ thống của chúng ta sẽ phục hồi về thời điểm nào. Khi nói RPO của hệ thống là 5 phút, chúng ta hiểu Hệ thống có khả năng tối đa là phục hồi về thời điểm trước 5 phút trước thảm họa..
- RTO (Recovery Time Objective) là khoảng thời gian tối đa mà hệ thống có thể chấp nhận được để phục hồi dữ liệu kể từ khi hệ thống bị ngưng hoạt động. Nói đơn giản là hệ thống của chúng ta mất bao lâu để có thể hoạt động lại bình thường. Khi nói RTO của hệ thống là 2 phút, chúng ta hiểu, hệ thống sẽ cần 2 phút để có thể hoạt động lại bình thường (kể từ khi phát hiện ra thảm họa).
Phục hồi dữ liệu từ Single Region và Multi Region.
Phục hồi dữ liệu từ Single Region nhìn chung là bảo đảm được những vấn đề về 1 data center trên từng AZ. Đây là phương án thường được sử dụng khi chúng ta muốn hệ thống đảm bảo HA, khắc phục được 1 số thành phần bị lỗi hoặc bị ảnh hưởng trên hệ thống. Tuy nhiên với mức độ ảnh hưởng lớn được coi là thảm họa, ảnh hưởng trên cả 1 Region, thì việc thiết lập hệ thống (hoặc các thành phần) trên 1 Region khác sẽ được coi là cần thiết. Lúc này chúng ta có Multi Region.
Trên AWS, người ta định nghĩa ra 4 kiểu chiến lược như sau:
1. Backup & Restore:
Đây là một chiến lược DR phổ biến cho các doanh nghiệp muốn giảm thiểu các tổn thất và hư hỏng dữ liệu. Đối với chiến lược loại này, chúng ta tiến hành lưu trữ các thành phần “có thể rebuild lại hệ thống tự động” trên các Region khác của AWS, ví dụ như template của CloudFormation, hay 1 vài loại backup, snapshot có thể dựng lên cả 1 thành phần resource 1 cách nhanh chóng.
Chiến lược DR kiểu này nhìn chung là có chi phí thấp, đặc biệt trên AWS việc này lại rất đơn giản, chỉ cần lưu trữ các thiết lập, template, … sẵn có chứ không cần 1 hệ thống thực tế đang chạy. Khi có vấn đề xảy ra thì có thể phục hồi lại trạng thái bình thường một cách nhanh chóng. RTO và RPO của phương án này rơi vào khoảng vài giờ đồng hồ, để rebuild hoàn toàn hệ thống.
2. Pilot Light:
Đây là một chiến lược DR được sử dụng nhằm đẩy nhanh tốc độ phục hồi dữ liệu bằng cách đưa các thành phần core của hệ thống, các thành phần có chứa dữ liệu phải thiết lập sang 1 bên Region khác. Ở phương án này, các thành phần có chứa dữ liệu sẽ đồng bộ sang các nơi khác như Database, Storage. Các thành phần liên quan đến process có thể tái tạo lại một cách nhanh chóng thì chưa cần tạo ngay (vì thời gian tái tạo của những thành phần này rất nhanh). Đối với AWS, việc này hiện đang ngày càng được cải thiện và nâng cao với 1 số tính năng như Global Database, Auto Sync, Auto backup, …
Chiến lược DR này có chi phí cao hơn Backup & Restore 1 chút, tuy nhiên nó có thể giúp đảm bảo các tham số RTO và RPO của hệ thống giảm xuống tới mức vài chục phút đối với các hệ thống trên AWS. Nếu có vấn đề xảy ra, hệ thống chỉ việc tiến hành scale hệ thống lên sẽ mất 1 thời gian ngắn.
Với chiến lược Pilot Light, chúng ta có thể sử dụng CloudEndure DR, thành phần cho phép chúng ta tiến hành backup hệ thống từ On Premise hoặc các hệ thống Cloud khác, lên AWS. Hoặc nếu hệ thống của chúng ta chỉ bao gồm các EC2 instance, thì chúng ta cũng có thể migrate ngay lập tức lên hệ thống Cloud của AWS.
3. Warm Standby:
Đây là chiến lược DR được sử dụng nhằm đưa được thông tin sang một Region khác trong một thời gian rất ngắn. Tương tự với Pilot Light, chiến lược này yêu cầu ở 1 bên Region backup khác cũng sẽ có các thành phần Core và backup được Synchronize ngay lập tức. Tuy nhiên khác với Pilot Light, kiểu DR này yêu cầu hệ thống backup ở Region khác phải có các thành phần process, xử lý thông tin. Có thể các thành phần này chưa cần scale ở mức cao, nhưng hệ thống nằm bên phía Region backup phải đảm bảo có thể chạy được ngay lập tức, không cần thiết lập gì thêm.
Hệ thống dạng này yêu cầu RTO và RPO trong khoảng vài phút để có thể clear cache hoặc 1 vài các thao tác scaling để đảm bảo hệ thống chạy ổn định. Tuy nhiên trước đó, hệ thống cần đảm bảo có thể hoạt động bình thường ở mức độ scale thấp. Chi phí của hệ thống theo chiến lược này đương nhiên cao hơn so với Pilot Light.
4. Multi-site active/active and Hot Standby active/passive:
Đây là chiến lược được sử dụng đối với các hệ thống chạy liên tục và cần phục hồi càng sớm càng tốt. Để thực hiện được điều này, phía Region backup phải đảm bảo có 1 hệ thống y hệt như hệ thống ở Region hiện tại, đảm bảo có scaling, các thành phần có thể hoạt động đầy đủ. Tại đây Multi-site active/active có hơi khác 1 chút, đó là Multi-site active/active sẽ không có Region nào là backup, mà là có nhiều Region hoạt động và tương hỗ lẫn nhau nếu có bất kỳ Region nào có vấn đề. Ngược lại với Hot Standby, mặc dù có tối thiểu 2 hệ thống trên 2 Region, nhưng chỉ có 1 hệ thống là chạy, còn 1 hệ thống là thực hiện phòng chờ trường hợp có vấn đề thì có thể chuyển hướng ngay lại tức.
RTO và RPO đối với hệ thống kiểu này gần như là Real time, hay còn gọi là zero down-time. Đương nhiên việc tổ chức hệ thống DR theo chiến lược này là rất tốn kém. Tuy nhiên trong 1 số trường hợp mà Business của chúng ta không thể dừng lại vì bất cứ lý do gì, thì việc chúng ta phải đánh đổi chi phí và Zero Downtime cũng là điều cần cân nhắc khi sử dụng các chiến lược DR.
Ok, trên đây là một số những hiểu biết cơ bản về Disaster Recovery từ AWS. Hy vọng sẽ giúp mọi người có thêm thông tin cho quá trình làm việc của mình.
Nếu sau bài viết này các bạn muốn được học và tìm hiểu thêm về các service của hệ thống AWS thì có tham khảo khóa học AWS Cơ bản của CodeStar Academy tại đây nhé: https://codestar.vn/product/aws-co-ban/