🥇Di chuyển dễ dàng RabbitMQ sang Kubernetes

RabbitMQ là một trình chuyển đổi tin nhắn được viết bằng Erlang, cho phép bạn tổ chức một cụm chuyển đổi dự phòng với khả năng sao chép dữ liệu đầy đủ trên nhiều nút, trong đó mỗi nút có thể phục vụ các yêu cầu đọc và ghi. Có nhiều cụm Kubernetes trong hoạt động sản xuất, chúng tôi hỗ trợ một số lượng lớn cài đặt RabbitMQ và phải đối mặt với nhu cầu di chuyển dữ liệu từ cụm này sang cụm khác mà không có thời gian ngừng hoạt động.

Chúng tôi cần thao tác này trong ít nhất hai trường hợp:

Chuyển dữ liệu từ cụm RabbitMQ không nằm trong Kubernetes sang cụm mới – đã được “kubernetized” (tức là hoạt động trong nhóm K8s).
Di chuyển RabbitMQ trong Kubernetes từ không gian tên này sang không gian tên khác (ví dụ: nếu các mạch được phân cách bằng không gian tên thì sẽ chuyển cơ sở hạ tầng từ mạch này sang mạch khác).

Công thức được đề xuất trong bài viết tập trung vào các tình huống (nhưng hoàn toàn không giới hạn ở chúng) trong đó có cụm RabbitMQ cũ (ví dụ: gồm 3 nút), đã có trong K8 hoặc trên một số máy chủ cũ. Một ứng dụng được lưu trữ trên Kubernetes (đã có hoặc trong tương lai) hoạt động với nó:

... và chúng tôi phải đối mặt với nhiệm vụ chuyển nó sang sản phẩm mới trong Kubernetes.

Đầu tiên, cách tiếp cận chung đối với việc di chuyển sẽ được mô tả và sau đó sẽ mô tả các chi tiết kỹ thuật về việc triển khai nó.

Thuật toán di chuyển

Giai đoạn đầu tiên, sơ bộ trước bất kỳ hành động nào là kiểm tra xem chế độ sẵn sàng cao có được bật trong bản cài đặt RabbitMQ cũ hay không (HA). Lý do rất rõ ràng - chúng tôi không muốn mất bất kỳ dữ liệu nào. Để thực hiện kiểm tra này, bạn có thể truy cập bảng quản trị RabbitMQ và trong tab Quản trị → Chính sách, hãy đảm bảo rằng giá trị được đặt ha-mode: all:

Bước tiếp theo là tạo một cụm RabbitMQ mới trong nhóm Kubernetes (ví dụ: trong trường hợp của chúng tôi, bao gồm 3 nút, nhưng số lượng của chúng có thể khác nhau).

Sau đó, chúng tôi hợp nhất các cụm RabbitMQ cũ và mới, thu được một cụm duy nhất (gồm 6 nút):

Quá trình đồng bộ hóa dữ liệu giữa cụm RabbitMQ cũ và mới được bắt đầu. Sau khi tất cả dữ liệu được đồng bộ hóa giữa tất cả các nút trong cụm, chúng ta có thể chuyển ứng dụng sang sử dụng cụm mới:

Sau các hoạt động này, việc loại bỏ các nút cũ khỏi cụm RabbitMQ là đủ và việc di chuyển có thể được coi là hoàn tất:

Chúng tôi đã sử dụng sơ đồ này nhiều lần trong sản xuất. Tuy nhiên, để thuận tiện cho chúng tôi, chúng tôi đã triển khai nó trong một hệ thống chuyên dụng phân phối cấu hình RMQ tiêu chuẩn trên nhiều cụm Kubernetes (dành cho những ai tò mò: chúng ta đang nói về toán tử bổ sungvề cái mà chúng tôi vừa mới kể). Dưới đây chúng tôi sẽ trình bày các hướng dẫn riêng lẻ mà bất kỳ ai cũng có thể áp dụng cho quá trình cài đặt của mình để thử giải pháp được đề xuất trong thực tế.

Hãy thử nó trong thực tế

Yêu cầu

Các chi tiết rất đơn giản:

Cụm Kubernetes (minikube cũng sẽ hoạt động);
Cụm RabbitMQ (có thể được triển khai trên kim loại trần và được tạo giống như một cụm thông thường trong Kubernetes từ biểu đồ Helm chính thức).

Với ví dụ bên dưới, tôi đã triển khai RMQ cho Kubernetes và gọi nó là rmq-old.

Chuẩn bị gian hàng

1. Tải biểu đồ Helm và chỉnh sửa một chút:

helm fetch --untar stable/rabbitmq-ha

Để thuận tiện, chúng tôi đặt mật khẩu, ErlangCookie và làm chính trị ha-allđể theo mặc định, hàng đợi được đồng bộ hóa giữa tất cả các nút của cụm RMQ:

rabbitmqPassword: guest
rabbitmqErlangCookie: mae9joopaol7aiVu3eechei2waiGa2we
definitions:
policies: |-
  {
    "name": "ha-all",
    "pattern": ".*",
    "vhost": "/",
    "definition": {
      "ha-mode": "all",
      "ha-sync-mode": "automatic",
      "ha-sync-batch-size": 81920
    }
  }

2. Cài đặt biểu đồ:

helm install . --name rmq-old --namespace rmq-old

3. Đi tới bảng quản trị RabbitMQ, tạo hàng đợi mới và thêm một số tin nhắn. Chúng sẽ cần thiết để sau khi di chuyển, chúng tôi có thể đảm bảo rằng tất cả dữ liệu được bảo toàn và chúng tôi không bị mất bất cứ thứ gì:

Bàn thử nghiệm đã sẵn sàng: chúng ta có RabbitMQ “cũ” với dữ liệu cần được chuyển.

Di chuyển cụm RabbitMQ

1. Trước tiên, hãy triển khai RabbitMQ mới trong bạn bè không gian tên với tương tự ErlangCookie và mật khẩu cho người dùng. Để thực hiện việc này, chúng tôi sẽ thực hiện các thao tác được mô tả ở trên, thay đổi lệnh cuối cùng để cài đặt RMQ thành lệnh sau:

helm install . --name rmq-new --namespace rmq-new

2. Bây giờ bạn cần hợp nhất cụm mới với cụm cũ. Để thực hiện việc này, hãy đi tới từng nhóm mới RabbitMQ và thực hiện các lệnh:

export OLD_RMQ=rabbit@rmq-old-rabbitmq-ha-0.rmq-old-rabbitmq-ha-discovery.rmq-old.svc.cluster.local && 
  rabbitmqctl stop_app && 
  rabbitmqctl join_cluster $OLD_RMQ && 
  rabbitmqctl start_app

Trong biến OLD_RMQ địa chỉ của một trong các nút được tìm thấy cũ Cụm RMQ.

Các lệnh này sẽ dừng nút hiện tại mới Cụm RMQ, gắn nó vào cụm cũ và khởi chạy lại.

3. Cụm RMQ gồm 6 nút đã sẵn sàng:

Bạn phải đợi trong khi tin nhắn được đồng bộ hóa giữa tất cả các nút. Không khó để đoán rằng thời gian đồng bộ hóa tin nhắn phụ thuộc vào dung lượng của phần cứng mà cụm được triển khai và vào số lượng tin nhắn. Trong kịch bản được mô tả, chỉ có 10 trong số đó nên dữ liệu được đồng bộ hóa ngay lập tức, nhưng với số lượng tin nhắn đủ lớn, quá trình đồng bộ hóa có thể kéo dài hàng giờ.

Vì vậy, trạng thái đồng bộ hóa:

Здесь +5 có nghĩa là tin nhắn đã có sẵn щё trên 5 nút (ngoại trừ những gì được chỉ định trong trường Node). Như vậy là việc đồng bộ đã thành công.

4. Tất cả những gì còn lại là chuyển địa chỉ RMQ trong ứng dụng sang cụm mới (các hành động cụ thể ở đây phụ thuộc vào ngăn xếp công nghệ bạn đang sử dụng và các thông tin cụ thể khác của ứng dụng), sau đó bạn có thể tạm biệt địa chỉ cũ.

Đối với thao tác cuối cùng (tức là đã sau khi chuyển ứng dụng sang một cụm mới) đi tới từng nút cũ cụm và thực hiện các lệnh:

rabbitmqctl stop_app
rabbitmqctl reset

Cụm “quên” các nút cũ: bạn có thể xóa RMQ cũ, lúc đó quá trình di chuyển sẽ hoàn tất.

Ghi: Nếu bạn sử dụng RMQ với chứng chỉ thì về cơ bản không có gì thay đổi - quá trình di chuyển sẽ được thực hiện giống hệt nhau.

Những phát hiện

Sơ đồ được mô tả phù hợp với hầu hết mọi trường hợp khi chúng ta cần di chuyển RabbitMQ hoặc đơn giản là chuyển sang một cụm mới.

Trong trường hợp của chúng tôi, khó khăn chỉ nảy sinh một lần, khi RMQ được truy cập từ nhiều nơi và chúng tôi không có cơ hội thay đổi địa chỉ RMQ sang địa chỉ mới ở mọi nơi. Sau đó, chúng tôi đã khởi chạy một RMQ mới trong cùng một không gian tên với cùng các nhãn để nó nằm trong các dịch vụ và Ingresses hiện có, đồng thời khi khởi chạy nhóm, chúng tôi đã thao tác các nhãn bằng tay, loại bỏ chúng ngay từ đầu để các yêu cầu không rơi vào RMQ trống và thêm chúng trở lại sau khi tin nhắn được đồng bộ hóa.

Chúng tôi đã sử dụng chiến lược tương tự khi cập nhật RabbitMQ lên phiên bản mới với cấu hình đã thay đổi - mọi thứ đều hoạt động giống như một chiếc đồng hồ.

PS

Để tiếp tục hợp lý tài liệu này, chúng tôi đang chuẩn bị các bài viết về MongoDB (di chuyển từ máy chủ phần cứng sang Kubernetes) và MySQL (cách chúng tôi chuẩn bị DBMS này bên trong Kubernetes). Chúng sẽ được xuất bản trong những tháng tới.

PPS

Đọc thêm trên blog của chúng tôi:

Nguồn: www.habr.com

Di chuyển liền mạch RabbitMQ sang Kubernetes