Kiến trúc cơ sở dữ liệu đa vùng (multi-region) phục hồi thảm họa dành cho MySQL.

Các doanh nghiệp mong đợi độ tin cậy cao của cơ sở hạ tầng cơ sở dữ liệu mà ứng dụng của họ truy cập. Mặc dù chúng ta chú ý và kỹ cẩn thận trong kỹ thuật, nhưng vẫn có thể xảy ra lỗi cơ sở dữ liệu, hoặc là do máy chủ bị sập hoặc là do phân vùng mạng. Lập kế hoạch tốt có thể giúp chúng ta giải quyết và phục hồi nhanh hơn khi có vấn đề xảy ra.

Bài này cho thấy một cách tiếp cận triển khai kiến ​​trúc cơ sở dữ liệu giúp thực hiện khả năng phục hồi và khắc phục thảm họa cao cho MySQL trên Compute Engine, sử dụng các ổ cứng khu vực (regional disk) cũng như các bộ cân bằng tải.

Bất kỳ kiến ​​trúc cơ sở dữ liệu nào cũng phải cung cấp các cách tiếp cận để khắc phục lỗi và phục hồi nhanh chóng từ các lỗi đó mà không mất dữ liệu. Các cách tiếp cận này được thể hiện trong RTO (recovery time objective-mục tiêu thời gian phục hồi) và RPO (recovery point objective-mục tiêu điểm khôi phục), cung cấp các cách để thiết lập và sau đó đo thời gian dịch vụ bị gián đoạn, và mốc thời gian giữ liệu được phục hồi.

Sau khi cơ sở dữ liệu gặp thảm họa, cơ sở dữ liệu phải phục hồi nhanh nhất có thể với RTO càng nhỏ càng tốt, lý tưởng là trong vài giây. Ít mất dữ liệu nhất, lý tưởng là không mất chút dữ liệu nào. RPO mong muốn là trạng thái cơ sở dữ liệu nhất quán cuối cùng.

Nhìn từ kiến ​​trúc cơ sở dữ liệu và quan điểm triển khai, điều này có thể được thực hiện với hai khái niệm riêng biệt: tính sẵn sàng cao và khả năng khắc phục thảm họa. Sử dụng cả hai cùng một lúc để đạt được một kiến ​​trúc mà sẵn sàng đáp ứng xử lý lỗi trên phạm vi rộng hoặc thảm họa.

Tạo một kiến ​​trúc cơ sở dữ liệu linh hoạt

Một kiến ​​trúc cơ sở dữ liệu có tính sẵn sàng cao có các instances cơ sở dữ liệu trong hai hoặc nhiều vùng. Nếu một máy chủ trên một vùng bị lỗi hoặc vùng đó không thể truy cập được, thì các instances ở các vùng khác có sẵn để tiếp tục xử lý. Hình dưới đây cho thấy hai trường hợp, một trong khu vực zn1 và một trong khu vực zn2. Bộ cân bằng tải ở phía trước hỗ trợ hướng lưu lượng truy cập đến một instances cơ sở dữ liệu tốt, không có lỗi để đọc và ghi truy vấn.

Kến ​​trúc phục hồi thảm họa bổ sung một thiết lập cơ sở dữ liệu sẵn sàng cao thứ hai trong khu vực (region) thứ hai. Nếu một trong các khu vực trở nên không thể truy cập hoặc thất bại, khu vực khác sẽ thay thế. Hình dưới đây cho thấy hai khu vực, chính và DR. Dữ liệu được sao chép từ vùng chính sang vùng DR để vùng DR có thể tiếp quản từ trạng thái cơ sở dữ liệu nhất quán mới nhất. Bộ cân bằng tải ở phía trước các vùng sẽ điều hướng lưu lượng đến vùng chịu trách nhiệm về lưu lượng đọc và ghi. Hình dưới mô tả kiến ​​trúc này.

Ngoài thiết lập instance cơ sở dữ liệu, một ổ cứng khu vực (regional disk) được triển khai để dữ liệu được ghi đồng thời ở hai vùng, cung cấp fail-safe trong trường hợp xảy ra lỗi vùng (zone). Đây là một lợi thế rất lớn của Google Cloud, cho phép bạn bỏ qua MySQL replication trong một khu vực. Mỗi thao tác ghi vào đĩa được thực hiện đồng bộ trong hai vùng. Khi primary instance thất bại, một instance dự phòng được gắn với (các) persistent disk khu vực và dịch vụ cơ sở dữ liệu (MySQL) sau đó được bắt đầu sử dụng bình thường. Điều này mang lại sự an tâm về việc không lo lắng về độ trễ replication hoặc trạng thái cơ sở dữ liệu cho tính sẵn sàng cao.

Từ quan điểm quá trình khắc phục thảm họa, những điều sau đây xảy ra theo thời gian trong tình huống xuất hiện sự cố:

• Hoạt động cơ sở dữ liệu trạng thái ổn định bình thường
• Một lỗi xảy ra và một khu vực (region) làm cho cơ sở dữ liệu trở nên không sẵn sàng hoặc cơ sở dữ liệu không thể truy cập
• Một quyết định phải được đưa ra xem có nên đưa tới fail over hay không (trong trường hợp có kỳ vọng rằng khu vực sẽ sớm có sẵn hoặc trường hợp instance hoạt động trở lại)
• DNS được cập nhật thủ công, do đó nó chuyển hướng lưu lượng ứng dụng đến khu vực thứ hai
• Quay lại khu vực chính sau khi nó trở nên khả dụng một lần nữa là tùy chọn, vì khu vực thứ hai đã được triển khai được xây dựng đầy đủ.

Từ quan điểm quy trình có tính sẵn sàng cao, những điều sau đây xảy ra theo thời gian trong tình huống xuất hiện sự cố:

• Hoạt động cơ sở dữ liệu trạng thái ổn định bình thường
• Instance của cơ sở dữ liệu bị lỗi hoặc không khả dụng
• Khởi chạy instance dự phòng
• Gắn regional SSD và bắt đầu cơ sở dữ liệu
• Tự động chuyển hướng lưu lượng ứng dụng sang chế độ dự phòng thông qua bộ cân bằng tải
• Sau khi trường hợp instance thất bại hoặc không có sẵn hoạt động trở lại, chúng ta có thể quay về instance đó hoặc không

Kiến trúc cơ sở dữ liệu cho thấy một kiến ​​trúc khả dụng cao và hỗ trợ khắc phục thảm họa. Thật đơn giản để cung cấp một triển khai cơ sở dữ liệu linh hoạt, với các ổ cứng khu vực (regional disks) và bộ cân bằng tải.

Hãy tìm hiểu thêm về cân bằng tải và ổ cứng khu vực (regional disks). Kiểm tra các quy trình HA và DR chung và các bước chi tiết trong phần đầu của hướng dẫn tham khảo. Hãy thử để làm quen với kiến ​​trúc cũng như hai quá trình chuyển đổi dự phòng chính.

Nguồn: Google Cloud Blog