RabbitMQ'nun Kubernetes'e sorunsuz geçişi

RabbitMQ, Erlang'da yazılmış ve her düğümün okuma ve yazma isteklerine hizmet verebileceği birden çok düğümde tam veri çoğaltma ile bir yük devretme kümesi düzenlemenize olanak tanıyan bir mesaj aracısıdır. Üretim operasyonunda çok sayıda Kubernetes kümesine sahip olduğumuz için çok sayıda RabbitMQ kurulumunu destekliyoruz ve verileri bir kümeden diğerine kesinti olmaksızın taşıma ihtiyacıyla karşı karşıya kaldık.

Bu operasyona en az iki durumda ihtiyacımız vardı:

1. Kubernetes'te bulunmayan bir RabbitMQ kümesinden verileri zaten "kubernetleştirilmiş" (yani K8s bölmelerinde çalışan) yeni bir kümeye aktarma.
2. RabbitMQ'nun Kubernetes içinde bir ad alanından diğerine taşınması (örneğin, devreler ad alanlarıyla sınırlandırılmışsa altyapıyı bir devreden diğerine aktarmak için).

Makalede önerilen tarif, halihazırda K3'lerde veya bazı eski sunucularda bulunan eski bir RabbitMQ kümesinin (örneğin, 8 düğümden oluşan) bulunduğu durumlara odaklanmıştır (ancak bunlarla sınırlı değildir). Kubernetes'te barındırılan bir uygulama (zaten orada veya gelecekte) onunla çalışır:

... ve bunu Kubernetes'teki yeni üretime taşıma göreviyle karşı karşıyayız.

Öncelikle geçişe genel yaklaşım anlatılacak, ardından uygulamanın teknik detayları anlatılacak.

Taşıma algoritması

Herhangi bir eylemden önceki ilk ön aşama, eski RabbitMQ kurulumunda yüksek kullanılabilirlik modunun etkinleştirilip etkinleştirilmediğini kontrol etmektir (HA). Nedeni açık; hiçbir veriyi kaybetmek istemiyoruz. Bu kontrolü gerçekleştirmek için RabbitMQ yönetici paneline gidebilir ve Yönetici → Politikalar sekmesinde değerin ayarlandığından emin olabilirsiniz. ha-mode: all:

Bir sonraki adım, Kubernetes pod'larında yeni bir RabbitMQ kümesi oluşturmaktır (bizim durumumuzda örneğin 3 düğümden oluşur, ancak sayıları farklı olabilir).

Bundan sonra, eski ve yeni RabbitMQ kümelerini birleştirerek tek bir küme (6 düğümden oluşan) elde ederiz:

Eski ve yeni RabbitMQ kümeleri arasında veri senkronizasyonu süreci başlatılır. Tüm veriler kümedeki tüm düğümler arasında senkronize edildikten sonra uygulamayı yeni kümeyi kullanacak şekilde değiştirebiliriz:

Bu işlemlerden sonra eski düğümleri RabbitMQ kümesinden kaldırmak yeterlidir ve taşıma tamamlanmış sayılabilir:

Bu şemayı üretimde birçok kez kullandık. Ancak kendi rahatlığımız için bunu, standart RMQ yapılandırmalarını birden fazla Kubernetes kümesine dağıtan özel bir sistem içinde uyguladık. (merak edenler için: bahsediyoruz eklenti operatörühangimiz hakkında az önce söylendi). Aşağıda, önerilen çözümü çalışırken denemek için herkesin kendi kurulumunda uygulayabileceği bireysel talimatlar sunacağız.

Hadi pratikte deneyelim

Gereksinimler

Ayrıntılar çok basit:

1. Kubernetes kümesi (minikube de çalışacaktır);
2. RabbitMQ kümesi (çıplak metal üzerine dağıtılabilir ve resmi Helm grafiğinden Kubernetes'te normal bir küme gibi yapılabilir).

Aşağıdaki örnekte, RMQ'yu Kubernetes'e dağıttım ve onu aradım rmq-old.

Stand hazırlığı

1. Helm grafiğini indirin ve biraz düzenleyin:

helm fetch --untar stable/rabbitmq-ha

Kolaylık sağlamak için bir şifre belirledik, ErlangCookie ve siyaset yap ha-allböylece kuyruklar varsayılan olarak RMQ kümesinin tüm düğümleri arasında senkronize edilir:

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. Grafiği yükleyin:

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

3. RabbitMQ yönetici paneline gidin, yeni bir sıra oluşturun ve birkaç mesaj ekleyin. Taşıma sonrasında tüm verilerin korunduğundan ve hiçbir şey kaybetmediğimizden emin olabilmemiz için bunlara ihtiyaç duyulacaktır:

Test tezgahı hazır: aktarılması gereken verileri içeren “eski” RabbitMQ'ya sahibiz.

RabbitMQ kümesini geçirme

1. Öncelikle yeni RabbitMQ'yu dağıtalım. другом ile ad alanı aynı ErlangCookie ve kullanıcı için şifre. Bunu yapmak için, RMQ'yu yüklemek için son komutu aşağıdaki şekilde değiştirerek yukarıda açıklanan işlemleri gerçekleştireceğiz:

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

2. Şimdi yeni kümeyi eskisiyle birleştirmeniz gerekiyor. Bunu yapmak için bölmelerin her birine gidin Yeni RabbitMQ'yu açın ve komutları yürütün:

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

bir değişkende OLD_RMQ düğümlerden birinin adresi bulunur eski RMQ kümesi.

Bu komutlar mevcut düğümü durduracak Yeni RMQ kümesini eski kümeye ekleyin ve yeniden başlatın.

3. 6 düğümden oluşan RMQ kümesi hazır:

Mesajlar tüm düğümler arasında senkronize edilirken beklemeniz gerekir. Mesaj senkronizasyon süresinin, kümenin konuşlandırıldığı donanımın kapasitesine ve mesaj sayısına bağlı olduğunu tahmin etmek zor değil. Açıklanan senaryoda bunlardan yalnızca 10 tanesi var, dolayısıyla veriler anında senkronize edildi, ancak yeterince fazla sayıda mesajla senkronizasyon saatlerce sürebilir.

Yani senkronizasyon durumu:

öyle +5 mesajların zaten var olduğu anlamına gelir daha 5 düğümde (alanda belirtilenler hariç) Node). Böylece senkronizasyon başarılı oldu.

4. Geriye kalan tek şey, uygulamadaki RMQ adresini yeni kümeye geçirmektir (buradaki belirli eylemler, kullandığınız teknoloji yığınına ve diğer uygulama özelliklerine bağlıdır), ardından eskisine veda edebilirsiniz.

Son işlem için (yani zaten sonra uygulamayı yeni bir kümeye geçirmek) her düğüme gidin eski kümeleyin ve komutları yürütün:

rabbitmqctl stop_app
rabbitmqctl reset

Küme eski düğümleri "unutmuştur": eski RMQ'yu silebilirsiniz, bu noktada taşıma işlemi tamamlanacaktır.

Dikkat: RMQ'yu sertifikalarla birlikte kullanırsanız temelde hiçbir şey değişmez; taşıma işlemi tamamen aynı şekilde gerçekleştirilecektir.

Bulgular

Açıklanan şema, RabbitMQ'yu taşımamız veya sadece yeni bir kümeye geçmemiz gerektiğinde neredeyse tüm durumlar için uygundur.

Bizim durumumuzda, RMQ'ya birçok yerden erişildiğinde zorluklar yalnızca bir kez ortaya çıktı ve RMQ adresini her yerde yenisiyle değiştirme fırsatımız olmadı. Daha sonra, mevcut hizmetlerin ve Girişlerin kapsamına girmesi için aynı ad alanında aynı etiketlere sahip yeni bir RMQ başlattık ve bölmeyi başlatırken, isteklerin listeye düşmemesi için başlangıçta etiketleri kaldırarak manipüle ettik. RMQ'yu boşaltın ve mesajlar senkronize edildikten sonra bunları tekrar ekleyin.

RabbitMQ'yu değiştirilmiş konfigürasyonla yeni bir sürüme güncellerken aynı stratejiyi kullandık; her şey saat gibi çalıştı.

PS

Bu materyalin mantıksal devamı olarak MongoDB (donanım sunucusundan Kubernetes'e geçiş) ve MySQL (bu DBMS'yi Kubernetes içinde nasıl hazırlarız) hakkında makaleler hazırlıyoruz. Önümüzdeki aylarda yayınlanacaklar.

PPS

Blogumuzda da okuyun:

• «Veritabanları ve Kubernetes (inceleme ve video raporu)";
• «K8'in ipuçları ve püf noktaları: Büyük veritabanları için önyüklemeyi hızlandırma'.

Kaynak: habr.com