Rất thường thấy các cơ sở dữ liệu được phân phối trên nhiều vị trí địa lý. Một tình huống để thực hiện kiểu thiết lập này là phục hồi sau thảm họa, trong đó trung tâm dữ liệu dự phòng của bạn được đặt ở một vị trí riêng biệt với trung tâm dữ liệu chính của bạn. Nó cũng có thể được yêu cầu để cơ sở dữ liệu được đặt gần người dùng hơn.
Thách thức chính để đạt được thiết lập này là thiết kế cơ sở dữ liệu theo cách giảm nguy cơ xảy ra các sự cố liên quan đến phân vùng mạng.
MariaDB Cluster có thể là một lựa chọn tốt để xây dựng một môi trường như vậy vì một số lý do. Chúng tôi muốn thảo luận về chúng ở đây và cũng nói một chút về cách một môi trường như vậy có thể trông như thế nào.
Tại sao sử dụng Cụm MariaDB cho Môi trường Phân tán Địa lý?
Lý do đầu tiên là MariaDB Cluster có thể hỗ trợ nhiều người viết. Điều này làm cho cách thiết kế định tuyến ghi dễ dàng hơn - bạn chỉ cần ghi vào các nút MariaDB cục bộ. Tất nhiên, với việc sao chép đồng bộ, độ trễ ảnh hưởng đến hiệu suất ghi và bạn có thể thấy rằng quá trình ghi của mình ngày càng chậm hơn nếu bạn trải rộng cụm của mình quá xa về mặt địa lý. Rốt cuộc, bạn không thể bỏ qua các định luật vật lý và họ nói, ít nhất cho đến bây giờ, ngay cả tốc độ ánh sáng trong các kết nối sợi quang cũng bị giới hạn. Bất kỳ bộ định tuyến nào được thêm vào bên trên cũng sẽ làm tăng độ trễ ngay cả khi chỉ vài mili giây.
Thứ hai, xử lý độ trễ trong MariaDB Cluster. Sao chép không đồng bộ là một đối tượng của độ trễ sao chép - các nô lệ có thể không cập nhật dữ liệu nếu họ cố gắng áp dụng tất cả các thay đổi kịp thời. Trong MariaDB Cluster thì khác - điều khiển luồng là một cơ chế nhằm giữ cho cụm được đồng bộ. Chà, hầu như - trong một số trường hợp cạnh, bạn vẫn có thể quan sát thấy độ trễ. Chúng ta đang nói ở đây, thông thường, mili giây, tối đa là vài giây trong khi trong bầu trời sao chép không đồng bộ là giới hạn.
Thứ ba, phân đoạn. Theo mặc định, MariaDB CLuster sử dụng tất cả cho tất cả các giao tiếp và mọi tập ghi được gửi bởi nút tới tất cả các nút khác trong cụm. Hành vi này có thể được thay đổi bằng cách sử dụng các phân đoạn. Phân đoạn cho phép người dùng chia các Cụm MariaDB thành nhiều phần. Mỗi phân đoạn có thể chứa nhiều nút và nó chọn một trong số chúng làm nút chuyển tiếp. Các nút như vậy nhận các bản ghi từ các phân đoạn khác và phân phối lại chúng trên các nút MariaDB cục bộ cho phân đoạn. Kết quả là, như bạn có thể thấy trên biểu đồ trên, có thể giảm lưu lượng sao chép qua WAN ba lần - chỉ có hai “bản sao” của luồng nhân bản đang được gửi qua WAN:một trên mỗi trung tâm dữ liệu so với một trên mỗi nô lệ trong sao chép không đồng bộ.
Cuối cùng, nơi MariaDB Cluster thực sự tỏa sáng là việc xử lý phân vùng mạng. MariaDB Cluster liên tục giám sát trạng thái của các nút trong cụm. Mọi nút đều cố gắng kết nối với các đồng nghiệp của nó và trao đổi trạng thái của cụm. Nếu một tập hợp con các nút không thể truy cập được, MariaDB sẽ cố gắng chuyển tiếp thông tin liên lạc để nếu có cách để tiếp cận các nút đó, chúng sẽ được tiếp cận.
Có thể thấy một ví dụ trên sơ đồ trên:DC 1 mất kết nối với DC2 nhưng DC2 và DC3 có thể kết nối. Trong trường hợp này, một trong các nút trong DC3 sẽ được sử dụng để chuyển tiếp dữ liệu từ DC1 sang DC2, đảm bảo rằng liên lạc nội bộ có thể được duy trì.
MariaDB có thể thực hiện các hành động dựa trên trạng thái của cụm. Nó thực hiện túc số - phần lớn các nút phải có sẵn để cụm có thể hoạt động. Nếu nút bị ngắt kết nối khỏi cụm và không thể kết nối với bất kỳ nút nào khác, nó sẽ ngừng hoạt động.
Như có thể thấy trên sơ đồ trên, có một phần mất kết nối mạng trong DC1 và nút bị ảnh hưởng sẽ bị xóa khỏi cụm, đảm bảo rằng ứng dụng sẽ không truy cập vào dữ liệu lỗi thời.
Điều này cũng đúng trên quy mô lớn hơn. DC1 đã bị cắt tất cả liên lạc của nó. Do đó, toàn bộ trung tâm dữ liệu đã bị xóa khỏi cụm và không có nút nào của nó sẽ phục vụ lưu lượng truy cập. Phần còn lại của cụm duy trì đa số (6 trong số 9 nút có sẵn) và nó tự cấu hình lại để giữ kết nối giữa DC 2 và DC3. Trong sơ đồ trên, chúng tôi giả định rằng người viết truy cập vào nút trong DC2 nhưng xin lưu ý rằng MariaDB có khả năng chạy với nhiều người viết.
Thiết kế Cụm MariaDB được phân phối theo địa lý
Chúng ta đã xem qua một số tính năng giúp MariaDB Cluster trở nên phù hợp với môi trường phân tán theo địa lý, bây giờ chúng ta hãy tập trung một chút vào thiết kế. Ở phần đầu, hãy giải thích môi trường mà chúng ta đang làm việc. Chúng tôi sẽ sử dụng ba trung tâm dữ liệu từ xa, được kết nối qua Mạng diện rộng (WAN). Mỗi trung tâm dữ liệu sẽ nhận được ghi từ các máy chủ ứng dụng cục bộ. Đọc cũng sẽ chỉ ở địa phương. Điều này nhằm tránh lưu lượng không cần thiết băng qua mạng WAN.
Để làm cho blog này bớt phức tạp hơn, chúng tôi sẽ không đi sâu vào chi tiết về kết nối sẽ như thế nào. Chúng tôi giả định một số loại kết nối được định cấu hình đúng, an toàn trên tất cả các trung tâm dữ liệu. VPN hoặc các công cụ khác có thể được sử dụng để triển khai điều đó.
Chúng tôi sẽ sử dụng MaxScale làm bộ cân bằng tải. MaxScale sẽ được triển khai cục bộ trong mỗi trung tâm dữ liệu. Nó cũng sẽ chỉ định tuyến lưu lượng đến các nút cục bộ. Các nút từ xa luôn có thể được thêm theo cách thủ công và chúng tôi sẽ giải thích các trường hợp mà đây có thể là một giải pháp tốt. Các ứng dụng có thể được định cấu hình để kết nối với một trong các nút MaxScale cục bộ bằng cách sử dụng thuật toán tổng hợp. Chúng tôi cũng có thể sử dụng Keepalived và Virtual IP để định tuyến lưu lượng truy cập đến nút MaxScale duy nhất, miễn là một nút MaxScale duy nhất có thể xử lý tất cả lưu lượng truy cập.
Một giải pháp khả thi khác là kết hợp MaxScale với các nút ứng dụng và định cấu hình ứng dụng để kết nối với proxy trên máy chủ cục bộ. Cách tiếp cận này hoạt động khá tốt với giả định rằng không có khả năng MaxScale sẽ không khả dụng nhưng ứng dụng sẽ hoạt động tốt trên cùng một nút. Thông thường những gì chúng ta thấy là lỗi nút hoặc lỗi mạng, điều này sẽ ảnh hưởng đến cả MaxScale và ứng dụng cùng một lúc.
Biểu đồ trên hiển thị phiên bản của môi trường, nơi MaxScale hình thành các trang trại proxy - tất cả các nút proxy có cùng cấu hình, cân bằng tải bằng Keepalived hoặc chỉ đơn giản là quay vòng từ ứng dụng trên tất cả các nút MaxScale. MaxScale được định cấu hình để phân phối khối lượng công việc trên tất cả các nút MariaDB trong trung tâm dữ liệu cục bộ. Một trong những nút đó sẽ được chọn làm nút để gửi ghi trong khi SELECT sẽ được phân phối trên tất cả các nút. Có một nút ghi chuyên dụng trong trung tâm dữ liệu giúp giảm thiểu số lượng xung đột chứng chỉ có thể xảy ra, dẫn đến hiệu suất tốt hơn, điển hình là. Để giảm điều này hơn nữa, chúng tôi sẽ phải bắt đầu gửi lưu lượng qua kết nối WAN, điều này không lý tưởng vì việc sử dụng băng thông sẽ tăng lên đáng kể. Ngay bây giờ, với các phân đoạn đã sẵn sàng, chỉ có hai bản sao của tập ghi đang được gửi qua các trung tâm dữ liệu - mỗi bản sao cho mỗi DC.
Kết luận
Như bạn có thể thấy, MariaDB Cluster có thể dễ dàng được sử dụng để tạo các cụm phân tán theo địa lý có thể hoạt động trên toàn thế giới. Yếu tố hạn chế sẽ là độ trễ mạng. Nếu nó quá cao, bạn có thể phải xem xét sử dụng các cụm MariaDB riêng biệt được kết nối bằng cách sử dụng sao chép không đồng bộ.
