Tính khả dụng của cơ sở dữ liệu là một trong những khía cạnh quan trọng nhất của kiến trúc ứng dụng. Mặc dù việc ngăn chặn thời gian ngừng hoạt động của trung tâm dữ liệu là điều nên làm, nhưng cuối cùng thì điều đó sẽ xảy ra với tất cả mọi người. Ngay cả những trung tâm dữ liệu hoạt động tốt nhất thỉnh thoảng cũng sẽ ngừng hoạt động. Ví dụ:Amazon AWS ngừng hoạt động 26/8/13 và 13/9/13. Câu hỏi quan trọng cần đặt ra là liệu điều này có được chấp nhận cho ứng dụng của bạn không? Hầu hết các ứng dụng thỉnh thoảng có thể chịu được một số thời gian chết, tuy nhiên, một số ứng dụng nhất định yêu cầu thời gian hoạt động gần 100% và kiến trúc cơ sở dữ liệu của các ứng dụng này yêu cầu một cách tiếp cận thiết kế có chủ ý hơn. Độ trễ giữa các trung tâm dữ liệu có xu hướng khá lớn, vì vậy bạn phải suy nghĩ cẩn thận khi thiết kế triển khai lưu trữ MongoDB của mình.
Mục tiêu thời gian hoạt động của MongoDB
- Cơ sở dữ liệu của bạn phải hoạt động và có thể ghi được, ngay cả khi một trung tâm dữ liệu hoàn chỉnh bị hỏng.
- Chuyển đổi dự phòng cơ sở dữ liệu của bạn phải tự động trong trường hợp máy chủ / trung tâm dữ liệu bị lỗi.
- Một lỗi máy chủ không thể khiến máy chủ chính chuyển sang một trung tâm dữ liệu khác.
Thiết kế Trung tâm Dữ liệu
Để đáp ứng mục tiêu của mình, chúng tôi đã đưa ra ba thiết kế trung tâm dữ liệu sử dụng bộ bản sao 4 + 1:
- Trung tâm dữ liệu 1: Sơ cấp (Ưu tiên 10), Trung học 0 (Chính 9)
- Trung tâm dữ liệu 2: Phụ 1 (Ưu tiên 8), Phụ 2 (Ưu tiên 7)
- Trung tâm dữ liệu 3: Trọng tài viên
Chúng tôi đặt hai thành viên đầy đủ vào mỗi trung tâm dữ liệu trong hai trung tâm dữ liệu đầu tiên và một trọng tài ở trung tâm dữ liệu thứ ba. Chúng tôi cũng định cấu hình mức độ ưu tiên cho từng máy chủ để chúng tôi có thể kiểm soát thành viên nào trở thành thành viên chính trong trường hợp máy chủ bị lỗi.
Địa lý này có một vài nhược điểm kiến trúc phân tán:
- Nếu bạn có ứng dụng nhiều ghi, các bản thứ hai trong một trung tâm dữ liệu khác sẽ luôn bị tụt hậu do độ trễ lớn hơn. Nếu một số dữ liệu là quan trọng, bạn có thể muốn sử dụng MongoDB ghi mối quan tâm là "Đa số" để đảm bảo rằng tất cả các nút đều xác nhận dữ liệu.
- Các bản dựng cộng đồng MongoDB không được bật SSL. Bạn có thể muốn tạo một bản dựng có bật SSL hoặc sử dụng MongoDB DBaaS tại ScaleGrid để dữ liệu truyền qua các vùng được mã hóa.
Tính khả dụng của Amazon AWS / EC2
Nếu bạn đang triển khai MongoDB trên AWS, mỗi trung tâm dữ liệu trong hình này tương ứng với một vùng Amazon chứ không phải một vùng khả dụng. Amazon không cung cấp đảm bảo tính khả dụng trong một khu vực sẵn có duy nhất, SLA dành cho toàn bộ khu vực. Nếu bạn triển khai trên các vùng khả dụng SLA của bạn là 99,95%, đây vẫn là SLA tuyệt vời - tuy nhiên, nếu toàn bộ khu vực gặp sự cố, cơ sở dữ liệu của bạn sẽ đi xuống. Ngoài ra, một số khu vực AWS nhất định chỉ có hai khu vực khả dụng, vì vậy cần đặc biệt chú ý đến việc đặt nút thứ ba ở một khu vực khác để thời gian ngừng hoạt động của một khu vực không làm toàn bộ cơ sở dữ liệu ngừng hoạt động.
Tính sẵn có của chi phí thấp hơn trên các khu vực địa lý
Một phiên bản đơn giản hơn của cùng một kiến trúc chỉ sử dụng ba máy chủ và chỉ đặt một bản sao vào mỗi trung tâm dữ liệu. Nhược điểm của phương pháp này là một lỗi máy chủ duy nhất sẽ khiến máy chủ chính di chuyển qua các trung tâm dữ liệu. Tuy nhiên, kiến trúc này có chi phí thấp hơn so với kiến trúc đầu tiên. Tùy thuộc vào tình huống của bạn, nó có thể phù hợp với bạn.
Có nhiều cách để đạt được thời gian hoạt động cao với MongoDB và đây chỉ là cách phù hợp với nhu cầu của chúng tôi. Nếu bạn có những kiến trúc thú vị khác, vui lòng gửi email cho chúng tôi theo địa chỉ [email protected]. Chúng tôi rất muốn nghe những suy nghĩ của bạn!
