Gần đây chúng tôi đã viết một số blog về cách các nhà cung cấp dịch vụ đám mây khác nhau xử lý chuyển đổi dự phòng cơ sở dữ liệu. Chúng tôi đã so sánh hiệu suất chuyển đổi dự phòng trong Amazon Aurora, Amazon RDS và ClusterControl, kiểm tra hành vi chuyển đổi dự phòng trong Amazon RDS và cả trên Google Cloud Platform. Mặc dù các dịch vụ đó cung cấp các tùy chọn tuyệt vời khi chuyển đổi dự phòng, nhưng chúng có thể không phù hợp với mọi ứng dụng.
Trong bài đăng trên blog này, chúng tôi sẽ dành một chút thời gian để phân tích ưu và nhược điểm của việc sử dụng các giải pháp DBaaS so với việc thiết kế môi trường theo cách thủ công hoặc bằng cách sử dụng nền tảng quản lý cơ sở dữ liệu, như ClusterControl.
Triển khai Cơ sở dữ liệu Khả dụng Cao với Giải pháp được Quản lý
Lý do chính để sử dụng các giải pháp hiện có là dễ sử dụng. Bạn có thể triển khai một giải pháp có tính khả dụng cao với tính năng chuyển đổi dự phòng tự động chỉ trong một vài cú nhấp chuột. Không cần kết hợp các công cụ khác nhau với nhau, quản lý cơ sở dữ liệu bằng tay, triển khai công cụ, viết tập lệnh, thiết kế giám sát hoặc bất kỳ hoạt động quản lý cơ sở dữ liệu nào khác. Tất cả mọi thứ đã được thực hiện. Điều này có thể làm giảm nghiêm trọng đường cong học tập và đòi hỏi ít kinh nghiệm hơn để thiết lập một môi trường có tính khả dụng cao cho cơ sở dữ liệu; về cơ bản cho phép tất cả mọi người triển khai các thiết lập như vậy.
Trong hầu hết các trường hợp với các giải pháp này, quá trình chuyển đổi dự phòng được thực hiện trong một khoảng thời gian hợp lý. Nó có thể nhanh như chớp với Amazon Aurora hoặc chậm hơn một chút như với các nút SQL của Google Cloud Platform. Đối với phần lớn các trường hợp, các loại kết quả này có thể chấp nhận được.
Điểm mấu chốt. Nếu bạn có thể chấp nhận thời gian ngừng hoạt động từ 30 - 60 giây, bạn có thể yên tâm sử dụng bất kỳ nền tảng DBaaS nào.
Nhược điểm của việc Sử dụng Giải pháp được Quản lý cho HA
Mặc dù các giải pháp DBaaS dễ sử dụng nhưng chúng cũng có một số nhược điểm nghiêm trọng. Đối với người mới bắt đầu, luôn có một thành phần khóa nhà cung cấp để xem xét. Sau khi bạn triển khai một cụm trong Amazon Web Services, việc di chuyển ra khỏi nhà cung cấp đó khá khó khăn. Không có phương pháp dễ dàng nào để tải xuống toàn bộ tập dữ liệu thông qua một bản sao lưu vật lý. Với hầu hết các nhà cung cấp, chỉ có các bản sao lưu logic được thực thi thủ công. Chắc chắn, luôn có các tùy chọn để đạt được điều này, nhưng nó thường là một quá trình phức tạp, tốn thời gian và sau cùng vẫn có thể yêu cầu một số thời gian chết.
Việc sử dụng nhà cung cấp như Amazon RDS cũng có những hạn chế. Không thể dễ dàng thực hiện một số hành động, điều này sẽ rất đơn giản để thực hiện trên các môi trường được triển khai theo cách hoàn toàn do người dùng kiểm soát (ví dụ:AWS EC2). Một số hạn chế này đã được đề cập trong các blog khác, nhưng tóm lại là không có dịch vụ DBaaS nào cung cấp cho bạn mức độ linh hoạt như sao chép dựa trên MySQL GTID thông thường. Bạn có thể thúc đẩy bất kỳ nô lệ nào, bạn có thể tái nô lệ hóa mọi nút tắt bất kỳ nút nào khác ... hầu như mọi hành động đều có thể thực hiện được. Với các công cụ như RDS, bạn phải đối mặt với những hạn chế do thiết kế gây ra, bạn không thể bỏ qua.
Vấn đề cũng nằm ở khả năng hiểu chi tiết về hiệu suất. Khi bạn thiết kế thiết lập có tính khả dụng cao của riêng mình, bạn trở nên hiểu biết về các vấn đề hiệu suất tiềm ẩn có thể xuất hiện. Mặt khác, RDS và các môi trường tương tự là “hộp đen” khá nhiều. Có, chúng tôi đã biết rằng Amazon RDS sử dụng DRBD để tạo bản sao bóng tối của bản chính, chúng tôi biết rằng Aurora sử dụng bộ nhớ được chia sẻ, sao chép để thực hiện chuyển đổi dự phòng rất nhanh. Đó chỉ là kiến thức chung. Chúng tôi không thể biết tác động hiệu suất của các giải pháp đó là gì ngoài những gì chúng tôi có thể tình cờ nhận thấy. Những vấn đề chung liên quan đến chúng là gì? Làm thế nào ổn định là các giải pháp? Chỉ những nhà phát triển đằng sau giải pháp mới biết chắc chắn.
Giải pháp thay thế cho các giải pháp DBaaS là gì?
Bạn có thể tự hỏi, có giải pháp thay thế cho DBaaS không? Rốt cuộc, thật tiện lợi khi chạy dịch vụ được quản lý, nơi bạn có thể truy cập hầu hết các hành động điển hình thông qua giao diện người dùng. Bạn có thể tạo và khôi phục các bản sao lưu, việc chuyển đổi dự phòng được xử lý tự động cho bạn. Môi trường dễ sử dụng có thể hấp dẫn đối với các công ty không có đội ngũ nhân viên tận tâm và giàu kinh nghiệm để xử lý cơ sở dữ liệu.
ClusterControl cung cấp một giải pháp thay thế tuyệt vời cho các dịch vụ DBaaS dựa trên đám mây. Nó cung cấp cho bạn giao diện người dùng đồ họa, có thể được sử dụng để triển khai, quản lý và giám sát cơ sở dữ liệu nguồn mở.
Chỉ với vài cú nhấp chuột, bạn có thể dễ dàng triển khai một cụm cơ sở dữ liệu có tính khả dụng cao, với tính năng tự động chuyển đổi dự phòng (nhanh hơn hầu hết các dịch vụ DBaaS), quản lý sao lưu, giám sát nâng cao và các tính năng khác như tích hợp với các công cụ bên ngoài (ví dụ:Slack hoặc PagerDuty) hoặc quản lý nâng cấp. Tất cả điều này trong khi hoàn toàn tránh bị khóa nhà cung cấp.
ClusterControl không quan tâm vị trí đặt cơ sở dữ liệu của bạn miễn là nó có thể kết nối với chúng bằng SSH. Bạn có thể thiết lập trên đám mây, tại chỗ hoặc trong môi trường hỗn hợp của nhiều nhà cung cấp đám mây. Miễn là có kết nối, ClusterControl sẽ có thể quản lý môi trường. Sử dụng các giải pháp bạn muốn (chứ không phải những giải pháp bạn không quen thuộc cũng như không biết) cho phép bạn kiểm soát hoàn toàn môi trường tại bất kỳ thời điểm nào.
Bất kỳ thiết lập nào bạn đã triển khai với ClusterControl, bạn có thể dễ dàng quản lý nó theo cách truyền thống, thủ công hoặc theo kịch bản. ClusterControl thậm chí còn cung cấp cho bạn giao diện dòng lệnh, cho phép bạn kết hợp các tác vụ được thực thi bởi ClusterControl vào các tập lệnh shell của bạn. Bạn có tất cả quyền kiểm soát mà bạn muốn - không có gì là hộp đen, mọi phần của môi trường sẽ được xây dựng bằng các giải pháp nguồn mở được kết hợp với nhau và được triển khai bởi ClusterControl.
Hãy cùng xem bạn có thể dễ dàng triển khai cụm Nhân bản MySQL bằng ClusterControl như thế nào. Giả sử bạn đã chuẩn bị sẵn môi trường với ClusterControl được cài đặt trên một phiên bản và tất cả các nút khác có thể truy cập thông qua SSH từ máy chủ ClusterControl.
Chúng ta sẽ bắt đầu với việc chọn trình hướng dẫn "Triển khai".
Ở bước đầu tiên, chúng ta phải xác định cách ClusterControl sẽ kết nối với các nút trên cơ sở dữ liệu nào sẽ được triển khai. Cả quyền truy cập root hoặc sudo (có hoặc không có mật khẩu) đều được hỗ trợ.
Sau đó, chúng tôi muốn chọn nhà cung cấp, phiên bản và chuyển mật khẩu cho người dùng quản trị trong cơ sở dữ liệu MySQL của chúng tôi.
Cuối cùng, chúng tôi muốn xác định cấu trúc liên kết cho cụm mới của chúng tôi. Như bạn có thể thấy, đây là cách thiết lập khá phức tạp, không giống như thứ bạn có thể triển khai bằng cách sử dụng nút AWS RDS hoặc GCP SQL.
Tất cả những gì chúng ta phải làm bây giờ là đợi quá trình hoàn tất. ClusterControl sẽ cố gắng hết sức để hiểu môi trường mà nó đang triển khai và cài đặt bộ gói yêu cầu, bao gồm cả chính cơ sở dữ liệu.
Khi cụm được thiết lập và chạy, bạn có thể tiếp tục triển khai lớp proxy (sẽ cung cấp cho ứng dụng của bạn một điểm vào duy nhất vào lớp cơ sở dữ liệu). Đây ít nhiều là những gì xảy ra đằng sau hậu trường với DBaaS, nơi bạn cũng có các điểm cuối để kết nối với cụm cơ sở dữ liệu. Việc sử dụng một điểm cuối duy nhất để ghi và nhiều điểm cuối để tiếp cận các bản sao cụ thể là điều khá phổ biến.
Ở đây chúng ta sẽ sử dụng ProxySQL, sẽ thực hiện công việc khó khăn cho chúng ta - nó sẽ hiểu cấu trúc liên kết, chỉ gửi các lần ghi cho chính và các truy vấn chỉ đọc cho cân bằng tải trên tất cả các bản sao mà chúng tôi có.
Để triển khai ProxySQL, chúng ta sẽ chuyển đến Quản lý -> Bộ cân bằng tải.
Chúng ta phải điền vào tất cả các trường bắt buộc:máy chủ để triển khai, thông tin đăng nhập cho người dùng quản trị và giám sát, chúng tôi có thể nhập người dùng hiện có từ MySQL vào ProxySQL hoặc tạo một người dùng mới. Bạn có thể dễ dàng tìm thấy tất cả thông tin chi tiết về ProxySQL trong nhiều blog trong phần blog của chúng tôi.
Chúng tôi muốn triển khai ít nhất hai nút ProxySQL để đảm bảo tính khả dụng cao. Sau đó, khi chúng được triển khai, chúng tôi sẽ triển khai Keepalived trên ProxySQL. Điều này sẽ đảm bảo rằng IP ảo sẽ được định cấu hình và trỏ đến một trong các phiên bản ProxySQL, miễn là sẽ có ít nhất một nút khỏe mạnh.
Đây là vấn đề tiềm ẩn duy nhất nếu bạn sử dụng môi trường đám mây nơi định tuyến hoạt động theo cách mà bạn không thể dễ dàng đưa ra một giao diện mạng. Trong trường hợp đó, bạn sẽ phải sửa đổi cấu hình của Keepalived, giới thiệu tập lệnh 'Inform_master' và sử dụng tập lệnh, tập lệnh này sẽ thực hiện các thay đổi IP cần thiết - trong trường hợp EC2, nó sẽ phải tách IP đàn hồi khỏi một máy chủ và gắn nó vào máy chủ khác.
Có rất nhiều hướng dẫn về cách thực hiện điều đó bằng cách sử dụng phần mềm nguồn mở đã được thử nghiệm rộng rãi trong các thiết lập do ClusterControl triển khai. Bạn có thể dễ dàng tìm thấy thông tin bổ sung, mẹo và cách thực hiện có liên quan đến môi trường cụ thể của bạn.
Kết luận
Chúng tôi hy vọng bạn tìm thấy bài đăng blog này sâu sắc. Nếu bạn muốn thử nghiệm ClusterControl, nó đi kèm với bản dùng thử doanh nghiệp 30 ngày, nơi bạn có sẵn tất cả các tính năng. Bạn có thể tải xuống miễn phí và kiểm tra xem nó có phù hợp với môi trường của bạn không.
