RabbitMQ-ის უწყვეტი მიგრაცია Kubernetes-ში

RabbitMQ არის Erlang-ში დაწერილი შეტყობინებების ბროკერი, რომელიც საშუალებას გაძლევთ მოაწყოთ წარუმატებელი კლასტერი მონაცემთა სრული რეპლიკაციით მრავალ კვანძში, სადაც თითოეულ კვანძს შეუძლია წაიკითხოს და ჩაწეროს მოთხოვნები. მრავალი Kubernetes კლასტერი საწარმოო ოპერაციებში, ჩვენ მხარს ვუჭერთ RabbitMQ ინსტალაციის დიდ რაოდენობას და დაგვხვდა მონაცემების გადატანა ერთი კლასტერიდან მეორეზე შეფერხების გარეშე.

ეს ოპერაცია სულ მცირე ორ შემთხვევაში გვჭირდებოდა:

1. მონაცემების გადატანა RabbitMQ კლასტერიდან, რომელიც არ მდებარეობს Kubernetes-ში, ახალ – უკვე „კუბერნეტიზებულ“ (ანუ მოქმედი K8s პოდებში) – კლასტერზე.
2. RabbitMQ-ის მიგრაცია Kubernetes-ში ერთი სახელთა სივრციდან მეორეში (მაგალითად, თუ სქემები შემოიფარგლება სახელთა სივრცით, შემდეგ ინფრასტრუქტურის გადატანა ერთი წრედან მეორეზე).

სტატიაში შემოთავაზებული რეცეპტი ორიენტირებულია სიტუაციებზე (მაგრამ სულაც არ შემოიფარგლება მათზე), რომლებშიც არის ძველი RabbitMQ კლასტერი (მაგალითად, 3 კვანძისგან), რომელიც მდებარეობს უკვე K8-ებში ან ზოგიერთ ძველ სერვერზე. კუბერნეტესზე განთავსებული აპლიკაცია (უკვე იქ ან მომავალში) მუშაობს მასთან:

... და ჩვენ წინაშე დგას ამოცანა, გადავიტანოთ იგი ახალ წარმოებაში Kubernetes-ში.

ჯერ იქნება აღწერილი თავად მიგრაციის მიმართ ზოგადი მიდგომა, შემდეგ კი მისი განხორციელების ტექნიკური დეტალები.

მიგრაციის ალგორითმი

პირველი, წინასწარი ეტაპი, ნებისმიერი ქმედების წინ არის იმის შემოწმება, რომ მაღალი ხელმისაწვდომობის რეჟიმი ჩართულია ძველ RabbitMQ ინსტალაციაში (HA). მიზეზი აშკარაა - ჩვენ არ გვინდა რაიმე მონაცემების დაკარგვა. ამ შემოწმების განსახორციელებლად, შეგიძლიათ გადახვიდეთ RabbitMQ ადმინისტრაციულ პანელზე და ჩანართში Admin → Policies დარწმუნდით, რომ მნიშვნელობა დაყენებულია ha-mode: all:

შემდეგი ნაბიჯი არის ახალი RabbitMQ კლასტერის ამაღლება Kubernetes pods-ში (ჩვენს შემთხვევაში, მაგალითად, შედგება 3 კვანძისგან, მაგრამ მათი რაოდენობა შეიძლება განსხვავებული იყოს).

ამის შემდეგ, ჩვენ ვაერთებთ ძველ და ახალ RabbitMQ კლასტერებს, ვიღებთ ერთ კლასტერს (6 კვანძისგან):

დაწყებულია მონაცემთა სინქრონიზაციის პროცესი ძველ და ახალ RabbitMQ კლასტერებს შორის. მას შემდეგ, რაც ყველა მონაცემი სინქრონიზდება კლასტერის ყველა კვანძს შორის, ჩვენ შეგვიძლია შევცვალოთ აპლიკაცია ახალი კლასტერის გამოსაყენებლად:

ამ ოპერაციების შემდეგ, საკმარისია ძველი კვანძების ამოღება RabbitMQ კლასტერიდან და გადაადგილება შეიძლება ჩაითვალოს დასრულებულად:

ჩვენ არაერთხელ გამოვიყენეთ ეს სქემა წარმოებაში. თუმცა, ჩვენი მოხერხებულობისთვის, ჩვენ განვახორციელეთ ის სპეციალიზებულ სისტემაში, რომელიც ანაწილებს სტანდარტულ RMQ კონფიგურაციებს Kubernetes-ის მრავალ კლასტერში. (მათთვის, ვისაც აინტერესებს: ჩვენ ვსაუბრობთ დანამატის ოპერატორირომლის შესახებაც ჩვენ ახლახანს განუცხადა). ქვემოთ წარმოგიდგენთ ინდივიდუალურ ინსტრუქციებს, რომლებიც ნებისმიერს შეუძლია გამოიყენოს თავის ინსტალაციაზე, რათა სცადოს შემოთავაზებული გადაწყვეტა მოქმედებაში.

პრაქტიკაში ვცადოთ

მოთხოვნები

დეტალები ძალიან მარტივია:

1. Kubernetes კლასტერი (მინიკუბეც იმუშავებს);
2. RabbitMQ კასეტური (შეიძლება განლაგდეს შიშველ მეტალზე და დამზადდეს ჩვეულებრივი კასეტურივით Kubernetes-ში Helm-ის ოფიციალური ჩარტიდან).

ქვემოთ მოყვანილი მაგალითისთვის მე განვათავსე RMQ Kubernetes-ში და დავურეკე rmq-old.

სადგამის მომზადება

1. ჩამოტვირთეთ Helm სქემა და ოდნავ შეცვალეთ იგი:

helm fetch --untar stable/rabbitmq-ha

მოხერხებულობისთვის, ჩვენ დავაყენეთ პაროლი, ErlangCookie და გააკეთე პოლიტიკა ha-allისე, რომ ნაგულისხმევად რიგები სინქრონიზებულია 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. დააინსტალირეთ სქემა:

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

3. გადადით RabbitMQ ადმინისტრაციულ პანელზე, შექმენით ახალი რიგი და დაამატეთ რამდენიმე შეტყობინება. ისინი საჭირო იქნება იმისთვის, რომ მიგრაციის შემდეგ დავრწმუნდეთ, რომ ყველა მონაცემი დაცულია და არაფერი დაგვიკარგავს:

ტესტის სკამი მზად არის: ჩვენ გვაქვს "ძველი" RabbitMQ მონაცემებით, რომლებიც უნდა გადავიდეს.

RabbitMQ კლასტერის მიგრაცია

1. პირველი, მოდით განვათავსოთ ახალი RabbitMQ მეგობარი სახელთა სივრცესთან ერთად იგივე ErlangCookie და პაროლი მომხმარებლისთვის. ამისათვის ჩვენ შევასრულებთ ზემოთ აღწერილ ოპერაციებს, შევცვლით RMQ ინსტალაციის საბოლოო ბრძანებას შემდეგზე:

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

2. ახლა თქვენ უნდა გააერთიანოთ ახალი კლასტერი ძველთან. ამისათვის გადადით თითოეულ ღვეზელზე ახალი RabbitMQ და შეასრულეთ ბრძანებები:

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

ცვლადში OLD_RMQ ნაპოვნია ერთ-ერთი კვანძის მისამართი ძველი RMQ კლასტერი.

ეს ბრძანებები შეაჩერებს მიმდინარე კვანძს ახალი RMQ კლასტერი, მიამაგრეთ იგი ძველ კლასტერზე და ხელახლა გაუშვით.

3. RMQ კლასტერი 6 კვანძისგან მზად არის:

თქვენ უნდა დაელოდოთ სანამ შეტყობინებები სინქრონიზდება ყველა კვანძს შორის. ძნელი მისახვედრი არ არის, რომ შეტყობინებების სინქრონიზაციის დრო დამოკიდებულია იმ აპარატურის სიმძლავრეზე, რომელზედაც განლაგებულია კლასტერი და შეტყობინებების რაოდენობაზე. აღწერილ სცენარში მხოლოდ 10 მათგანია, ამიტომ მონაცემები მყისიერად სინქრონიზდა, მაგრამ საკმარისად დიდი რაოდენობის შეტყობინებებით, სინქრონიზაცია შეიძლება გაგრძელდეს საათობით.

ასე რომ, სინქრონიზაციის სტატუსი:

აქ +5 ნიშნავს, რომ შეტყობინებები უკვე შედის მეტი 5 კვანძზე (გარდა ველში მითითებულისა Node). ამრიგად, სინქრონიზაცია წარმატებული იყო.

4. რჩება მხოლოდ აპლიკაციაში RMQ მისამართის გადართვა ახალ კლასტერზე (აქ კონკრეტული მოქმედებები დამოკიდებულია თქვენს მიერ გამოყენებული ტექნოლოგიის სტეკზე და აპლიკაციის სხვა სპეციფიკაზე), რის შემდეგაც შეგიძლიათ დაემშვიდობოთ ძველს.

ბოლო ოპერაციისთვის (ანუ უკვე შემდეგ აპლიკაციის ახალ კლასტერზე გადართვა) გადადით თითოეულ კვანძზე ძველი დააჯგუფეთ და შეასრულეთ ბრძანებები:

rabbitmqctl stop_app
rabbitmqctl reset

კლასტერს „დაავიწყდა“ ძველი კვანძები: შეგიძლიათ წაშალოთ ძველი RMQ, რა დროსაც გადაადგილება დასრულდება.

შენიშვნა: თუ იყენებთ RMQ-ს სერთიფიკატებთან, მაშინ ძირეულად არაფერი იცვლება - გადაადგილების პროცესი ზუსტად იგივე განხორციელდება.

დასკვნები

აღწერილი სქემა შესაფერისია თითქმის ყველა შემთხვევისთვის, როდესაც გვჭირდება RabbitMQ მიგრაცია ან უბრალოდ ახალ კლასტერზე გადასვლა.

ჩვენს შემთხვევაში, სირთულეები წარმოიშვა მხოლოდ ერთხელ, როდესაც RMQ-ზე წვდომა მრავალი ადგილიდან იყო და ჩვენ არ გვქონდა შესაძლებლობა ყველგან შეგვეცვალა RMQ მისამართი ახლით. შემდეგ ჩვენ გავუშვით ახალი RMQ იმავე სახელების სივრცეში იგივე ლეიბლებით, რათა ის მოხვდებოდა არსებულ სერვისებსა და Ingresses-ში, ხოლო pod-ის გაშვებისას ჩვენ მანიპულირებდით ეტიკეტებზე ხელით, ამოვიღეთ ისინი თავიდან ისე, რომ მოთხოვნები არ დაემთხვა ცარიელია RMQ და დაამატეთ ისინი შეტყობინებების სინქრონიზაციის შემდეგ.

ჩვენ იგივე სტრატეგია გამოვიყენეთ RabbitMQ-ის ახალ ვერსიაზე შეცვლილი კონფიგურაციის განახლებისას - ყველაფერი მუშაობდა საათის მსგავსად.

PS

როგორც ამ მასალის ლოგიკური გაგრძელება, ჩვენ ვამზადებთ სტატიებს MongoDB-ის (მიგრაცია აპარატურის სერვერიდან Kubernetes-ში) და MySQL-ის (როგორ ვამზადებთ ამ DBMS-ს Kubernetes-ში) შესახებ. ისინი უახლოეს თვეებში გამოქვეყნდება.

PPS

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «მონაცემთა ბაზები და Kubernetes (მიმოხილვა და ვიდეო ანგარიში)";
• «K8s რჩევები და ხრიკები: ჩატვირთვის დაჩქარება დიდი მონაცემთა ბაზებისთვის".

წყარო: www.habr.com