MariaDB
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> MariaDB

Cân bằng tải cơ sở dữ liệu:Thiết lập phân tán so với tập trung

Bộ cân bằng tải cơ sở dữ liệu, hoặc proxy ngược cơ sở dữ liệu, phân phối khối lượng công việc cơ sở dữ liệu đến trên nhiều máy chủ cơ sở dữ liệu chạy phía sau nó. Mục tiêu của việc có bộ cân bằng tải cơ sở dữ liệu là cung cấp một điểm cuối cơ sở dữ liệu duy nhất cho các ứng dụng để kết nối, tăng thông lượng truy vấn, giảm thiểu độ trễ và tối đa hóa việc sử dụng tài nguyên của các máy chủ cơ sở dữ liệu.

Có thể có hai cách cấu trúc liên kết cân bằng tải cơ sở dữ liệu:

  • Cấu trúc liên kết tập trung
  • Cấu trúc liên kết phân tán

Trong bài đăng trên blog này, chúng tôi sẽ đề cập đến cả hai cấu trúc liên kết và hiểu một số ưu và nhược điểm của mỗi thiết lập. Ngoài ra, liệu có thể kết hợp cả hai cấu trúc liên kết với nhau không?

Tôpô Tập trung

Trong thiết lập tập trung, proxy ngược được đặt ở giữa tầng dữ liệu và tầng trình bày, như được biểu diễn bằng sơ đồ sau:

Để loại bỏ một điểm lỗi duy nhất, người ta phải đặt lên hai hoặc nhiều nút cân bằng tải cho các mục đích dự phòng. Nếu ứng dụng của bạn có thể xử lý nhiều điểm cuối cơ sở dữ liệu, ví dụ:ứng dụng hoặc trình điều khiển cơ sở dữ liệu có khả năng thực hiện kiểm tra tình trạng nếu bộ cân bằng tải hoạt động tốt để xử lý truy vấn, bạn có thể bỏ qua phần địa chỉ IP ảo. Nếu không, cả hai nút cân bằng tải phải được gắn với nhau bằng một tên máy chủ chung hoặc địa chỉ IP ảo, để cung cấp tính minh bạch cho các máy khách cơ sở dữ liệu nơi nó chỉ cần sử dụng một điểm cuối cơ sở dữ liệu duy nhất để truy cập tầng dữ liệu. Bạn cũng có thể sử dụng ánh xạ DNS hoặc máy chủ lưu trữ nếu bạn muốn bỏ qua việc sử dụng địa chỉ IP ảo.

Cách tiếp cận dựa trên cấp độ này dễ quản lý hơn nhiều vì nó có vị trí máy chủ lưu trữ tĩnh độc lập. Rất khó có khả năng cấp cân bằng tải bị thu nhỏ (thêm nhiều nút hơn) vì nền tảng vững chắc của nó về khả năng phục hồi, dự phòng và minh bạch đối với cấp ứng dụng. Bạn có thể cần mở rộng quy mô máy chủ lưu trữ (thêm nhiều tài nguyên hơn vào máy chủ lưu trữ), điều này thường xảy ra trong tương lai, sau khi khối lượng công việc của bộ cân bằng tải ngày càng trở nên đòi hỏi nhiều hơn khi doanh nghiệp của bạn phát triển.

Cấu trúc liên kết này yêu cầu một tầng và máy chủ bổ sung, có thể tốn kém trong một cơ sở hạ tầng kim loại trần với các máy chủ vật lý. Thiết lập này dễ quản lý hơn trong môi trường đám mây hoặc ảo, nơi bạn có thể linh hoạt thêm một tầng bổ sung giữa tầng ứng dụng và tầng cơ sở dữ liệu, mà không làm bạn tốn quá nhiều chi phí cơ sở hạ tầng vật lý như điện, dung lượng rack và chi phí mạng.

Cấu trúc liên kết phân tán

Trong thiết lập cấu trúc liên kết phân tán, các bộ cân bằng tải được đặt cùng vị trí trong tầng trình bày (ứng dụng hoặc máy chủ web), như được đơn giản hóa bằng sơ đồ sau:

Các ứng dụng xử lý bộ cân bằng tải cơ sở dữ liệu tương tự như máy chủ cơ sở dữ liệu cục bộ, trong đó bộ cân bằng tải trở thành đại diện của cơ sở dữ liệu từ xa từ quan điểm của ứng dụng. Thông thường, bộ cân bằng tải sẽ lắng nghe giao diện mạng cục bộ như 127.0.0.1 hoặc "localhost", điều này sẽ hợp lý hóa máy chủ cơ sở dữ liệu điểm cuối cơ sở dữ liệu cho các ứng dụng.

Một trong những lợi thế của việc chạy trong cấu trúc liên kết này là bạn không cần thêm máy chủ cho mục đích cân bằng tải. Bằng cách kết hợp tầng cân bằng tải trong tầng bản trình bày, chúng tôi có thể lưu ít nhất hai máy chủ. Trong môi trường kim loại trần, cấu trúc liên kết này có thể giúp bạn tiết kiệm rất nhiều tiền trong suốt nhiều năm. Nói chung, khối lượng công việc của bộ cân bằng tải ít đòi hỏi hơn nhiều nếu so với khối lượng công việc của cơ sở dữ liệu hoặc ứng dụng, điều này khiến việc chia sẻ cùng tài nguyên phần cứng với các ứng dụng là điều hợp lý.

Khi được đặt cùng vị trí với máy chủ ứng dụng, bạn đưa proxy ngược lại gần ứng dụng hơn và loại bỏ điểm lỗi duy nhất. Điều này có thể cải thiện đáng kể hiệu suất ứng dụng khi bạn có khoảng cách địa lý giữa ứng dụng và tầng dữ liệu, đặc biệt là đối với các bộ cân bằng tải cơ sở dữ liệu hỗ trợ bộ đệm kết quả như ProxySQL và MaxScale. Mặt khác, số lượng bộ cân bằng tải cơ sở dữ liệu thường bằng số lượng nút ứng dụng, có nghĩa là nếu cấp ứng dụng được mở rộng, số lượng bộ cân bằng tải cơ sở dữ liệu sẽ tăng lên và có thể làm giảm hiệu suất của tình trạng cơ sở dữ liệu. kiểm tra dịch vụ. Lưu ý rằng việc kiểm tra tình trạng của bộ cân bằng tải có vẻ hơi ồn ào hơn vì nó có trách nhiệm theo kịp trạng thái chính xác của các nút cơ sở dữ liệu.

Với sự trợ giúp của các công cụ tự động hóa cơ sở hạ tầng CNTT như Chef, Puppet và Ansible cùng với các công cụ điều phối vùng chứa, việc tự động hóa việc triển khai và quản lý nhiều phiên bản cân bằng tải cho cấu trúc liên kết này không còn là nhiệm vụ bất khả thi. Tuy nhiên, sẽ có một đường cong học tập khác dành cho nhóm vận hành để đưa ra chính sách quản lý và triển khai cấp sản xuất, đã được thử nghiệm trong trận chiến để giảm bớt công việc quá mức khi xử lý nhiều nút cân bằng tải. Đừng bỏ lỡ tất cả các khía cạnh quản lý quan trọng cho bộ cân bằng tải cơ sở dữ liệu như sao lưu / khôi phục, nâng cấp / hạ cấp, quản lý cấu hình, kiểm soát dịch vụ, quản lý lỗi, v.v.

Cấu trúc liên kết phân tán có thể được trộn cùng với cấu trúc liên kết tập trung cho một số bộ cân bằng tải cơ sở dữ liệu được hỗ trợ như ProxySQL, như được minh họa trong sơ đồ sau:

Các "máy chủ" phụ trợ của một phiên bản ProxySQL có thể là một bộ ProxySQL khác thay vào đó. Với cấu hình này, địa chỉ IP ảo là không cần thiết để truy cập điểm cuối duy nhất vào các nút cơ sở dữ liệu, vì cá thể ProxySQL cục bộ được lưu trữ cục bộ trên máy chủ ứng dụng sẽ là truy cập điểm cuối duy nhất từ ​​quan điểm ứng dụng.

Tuy nhiên, điều này yêu cầu hai phiên bản của cấu hình bộ cân bằng tải - một phiên bản nằm trên tầng ứng dụng và một phiên bản khác nằm trên các tầng của bộ cân bằng tải. Nó cũng yêu cầu nhiều máy chủ hơn, ngoại trừ nhu cầu tìm hiểu về công nghệ địa chỉ IP ảo, chuyển đổi dự phòng IP, v.v. Ưu điểm và nhược điểm của cả thiết lập phân tán và tập trung là hợp nhất với nhau trong cấu trúc liên kết này.

Kết luận

Mỗi cấu trúc liên kết đều có ưu và nhược điểm riêng và phải được lên kế hoạch tốt ngay từ đầu. Quyết định ban đầu này rất quan trọng và có thể ảnh hưởng lớn đến hiệu suất ứng dụng, khả năng mở rộng, độ tin cậy và tính khả dụng của bạn về lâu dài.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Cách DATE_FORMAT () hoạt động trong MariaDB

  2. MariaDB TX là gì? Cách quản lý MariaDB MySQL Fork mới!

  3. Cách cài đặt và bảo mật MariaDB trên Debian 9

  4. Hướng dẫn sao chép luồng trực tuyến cụm MySQL Galera:Phần thứ hai

  5. Cách CRC32 hoạt động trong MariaDB