ການເຄື່ອນຍ້າຍຂອງ RabbitMQ ໄປ Kubernetes ແບບບໍ່ຕິດຂັດ

RabbitMQ ແມ່ນນາຍຫນ້າຂໍ້ຄວາມທີ່ຂຽນໃນ Erlang ທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດຈັດກຸ່ມທີ່ລົ້ມເຫລວດ້ວຍການຈໍາລອງຂໍ້ມູນເຕັມທີ່ໃນທົ່ວຫຼາຍໂຫນດ, ບ່ອນທີ່ແຕ່ລະ node ສາມາດໃຫ້ບໍລິການອ່ານແລະຂຽນຄໍາຮ້ອງຂໍ. ມີກຸ່ມ Kubernetes ຫຼາຍກຸ່ມໃນການດໍາເນີນງານການຜະລິດ, ພວກເຮົາສະຫນັບສະຫນູນການຕິດຕັ້ງ RabbitMQ ຈໍານວນຫລາຍແລະປະເຊີນກັບຄວາມຕ້ອງການທີ່ຈະຍ້າຍຂໍ້ມູນຈາກກຸ່ມຫນຶ່ງໄປຫາອີກກຸ່ມຫນຶ່ງໂດຍບໍ່ມີການຢຸດເວລາ.

ພວກເຮົາຕ້ອງການການດໍາເນີນການນີ້ຢ່າງຫນ້ອຍສອງກໍລະນີ:

1. ການໂອນຂໍ້ມູນຈາກກຸ່ມ RabbitMQ ທີ່ບໍ່ຢູ່ໃນ Kubernetes ໄປຫາອັນໃໝ່ – ແລ້ວ “kubernetized” (ເຊັ່ນ: ປະຕິບັດການຢູ່ໃນ K8s pods) – cluster.
2. ການເຄື່ອນຍ້າຍຂອງ RabbitMQ ພາຍໃນ Kubernetes ຈາກ namespace ຫນຶ່ງໄປຫາອື່ນ (ຕົວຢ່າງ, ຖ້າວົງຈອນຖືກ delimited ໂດຍ namespaces, ຫຼັງຈາກນັ້ນເພື່ອໂອນໂຄງສ້າງພື້ນຖານຈາກວົງຈອນຫນຶ່ງໄປອີກ).

ສູດທີ່ສະເຫນີໃນບົດຄວາມແມ່ນເນັ້ນໃສ່ສະຖານະການ (ແຕ່ບໍ່ຈໍາກັດທັງຫມົດ) ເຊິ່ງມີກຸ່ມ RabbitMQ ເກົ່າ (ຕົວຢ່າງເຊັ່ນ 3 nodes), ທີ່ຕັ້ງຢູ່ໃນ K8s ຫຼືບາງເຄື່ອງແມ່ຂ່າຍເກົ່າ. ແອັບພລິເຄຊັນທີ່ໂຮດຢູ່ໃນ Kubernetes (ມີຢູ່ແລ້ວຫຼືໃນອະນາຄົດ) ເຮັດວຽກກັບມັນ:

... ແລະພວກເຮົາກໍາລັງປະເຊີນກັບວຽກງານຂອງການເຄື່ອນຍ້າຍມັນໄປສູ່ການຜະລິດໃຫມ່ໃນ Kubernetes.

ຫນ້າທໍາອິດ, ວິທີການທົ່ວໄປຂອງການເຄື່ອນຍ້າຍຕົວມັນເອງຈະຖືກອະທິບາຍ, ແລະຫຼັງຈາກນັ້ນລາຍລະອຽດດ້ານວິຊາການຂອງການປະຕິບັດຂອງມັນຈະຖືກອະທິບາຍ.

ຂັ້ນຕອນການຍ້າຍຖິ່ນຖານ

ຂັ້ນຕອນທໍາອິດ, ເບື້ອງຕົ້ນ, ກ່ອນທີ່ຈະດໍາເນີນການໃດຫນຶ່ງແມ່ນການກວດສອບວ່າຮູບແບບການມີຢູ່ສູງໄດ້ຖືກເປີດໃຊ້ໃນການຕິດຕັ້ງ RabbitMQ ເກົ່າ (HA). ເຫດຜົນແມ່ນຈະແຈ້ງ - ພວກເຮົາບໍ່ຕ້ອງການສູນເສຍຂໍ້ມູນໃດໆ. ເພື່ອດໍາເນີນການກວດສອບນີ້, ທ່ານສາມາດໄປທີ່ແຜງຄວບຄຸມ RabbitMQ ແລະໃນແຖບ Admin → Policies ໃຫ້ແນ່ໃຈວ່າໄດ້ກໍານົດຄ່າ. ha-mode: all:

ຂັ້ນຕອນຕໍ່ໄປແມ່ນເພື່ອຍົກສູງກຸ່ມ RabbitMQ ໃຫມ່ໃນຝັກ Kubernetes (ຕົວຢ່າງ, ໃນກໍລະນີຂອງພວກເຮົາ, ປະກອບດ້ວຍ 3 nodes, ແຕ່ຈໍານວນຂອງພວກເຂົາອາດຈະແຕກຕ່າງກັນ).

ຫຼັງຈາກນີ້, ພວກເຮົາລວມກຸ່ມ RabbitMQ ເກົ່າແລະໃຫມ່, ໄດ້ຮັບກຸ່ມດຽວ (ຂອງ 6 nodes):

ຂະບວນການ synchronization ຂໍ້ມູນລະຫວ່າງກຸ່ມ RabbitMQ ເກົ່າແລະໃຫມ່ແມ່ນເລີ່ມຕົ້ນ. ເມື່ອຂໍ້ມູນທັງຫມົດຖືກ synchronized ລະຫວ່າງ nodes ທັງຫມົດໃນ cluster, ພວກເຮົາສາມາດສະຫຼັບຄໍາຮ້ອງສະຫມັກທີ່ຈະນໍາໃຊ້ກຸ່ມໃຫມ່:

ຫຼັງຈາກການປະຕິບັດງານເຫຼົ່ານີ້, ມັນພຽງພໍທີ່ຈະເອົາໂຫນດເກົ່າອອກຈາກກຸ່ມ RabbitMQ, ແລະການເຄື່ອນໄຫວສາມາດຖືກພິຈາລະນາຢ່າງສົມບູນ:

ພວກເຮົາໄດ້ນໍາໃຊ້ໂຄງການນີ້ຫຼາຍຄັ້ງໃນການຜະລິດ. ຢ່າງໃດກໍຕາມ, ເພື່ອຄວາມສະດວກຂອງພວກເຮົາເອງ, ພວກເຮົາໄດ້ປະຕິບັດມັນພາຍໃນລະບົບພິເສດທີ່ແຈກຢາຍການຕັ້ງຄ່າ RMQ ມາດຕະຖານໃນທົ່ວກຸ່ມ Kubernetes ຫຼາຍກຸ່ມ. (ສໍາລັບຜູ້ທີ່ຢາກຮູ້ຢາກເຫັນ: ພວກເຮົາເວົ້າກ່ຽວກັບ addon-operatorກ່ຽວກັບການທີ່ພວກເຮົາ ຫາກໍບອກເມື່ອບໍ່ດົນມານີ້). ຂ້າງລຸ່ມນີ້ພວກເຮົາຈະນໍາສະເຫນີຄໍາແນະນໍາສ່ວນບຸກຄົນທີ່ທຸກຄົນສາມາດສະຫມັກຂໍເອົາໃນການຕິດຕັ້ງຂອງພວກເຂົາເພື່ອທົດລອງໃຊ້ວິທີແກ້ໄຂທີ່ສະເຫນີໃນການປະຕິບັດ.

ໃຫ້ພະຍາຍາມມັນຢູ່ໃນການປະຕິບັດ

ຄວາມຕ້ອງການ

ລາຍ​ລະ​ອຽດ​ແມ່ນ​ງ່າຍ​ດາຍ​ຫຼາຍ​:

1. ກຸ່ມ Kubernetes (minikube ຍັງຈະເຮັດວຽກ);
2. ກຸ່ມ RabbitMQ (ສາມາດຖືກນໍາໄປໃຊ້ໃນໂລຫະເປົ່າ, ແລະເຮັດຄືກັບກຸ່ມປົກກະຕິໃນ Kubernetes ຈາກຕາຕະລາງ Helm ຢ່າງເປັນທາງການ).

ຕົວຢ່າງຂ້າງລຸ່ມນີ້, ຂ້າພະເຈົ້າໄດ້ນໍາໃຊ້ RMQ ກັບ Kubernetes ແລະເອີ້ນມັນ rmq-old.

ການກະກຽມຢືນ

1. ດາວໂຫລດຕາຕະລາງ Helm ແລະແກ້ໄຂມັນເລັກນ້ອຍ:

helm fetch --untar stable/rabbitmq-ha

ເພື່ອຄວາມສະດວກ, ພວກເຮົາຕັ້ງລະຫັດຜ່ານ, ErlangCookie ແລະສ້າງການເມືອງ ha-allດັ່ງນັ້ນຕາມຄ່າເລີ່ມຕົ້ນ, ແຖວຈະຖືກ synchronized ລະຫວ່າງ nodes ທັງຫມົດຂອງກຸ່ມ 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 admin panel, ສ້າງແຖວໃຫມ່ແລະເພີ່ມຂໍ້ຄວາມຈໍານວນຫນຶ່ງ. ພວກເຂົາເຈົ້າຈະມີຄວາມຈໍາເປັນເພື່ອວ່າຫຼັງຈາກການເຄື່ອນຍ້າຍພວກເຮົາສາມາດໃຫ້ແນ່ໃຈວ່າຂໍ້ມູນທັງຫມົດໄດ້ຖືກເກັບຮັກສາໄວ້ແລະພວກເຮົາບໍ່ໄດ້ສູນເສຍຫຍັງ:

ບ່ອນນັ່ງທົດສອບພ້ອມແລ້ວ: ພວກເຮົາມີ RabbitMQ "ເກົ່າ" ທີ່ມີຂໍ້ມູນທີ່ຕ້ອງການໂອນ.

ການເຄື່ອນຍ້າຍກຸ່ມ RabbitMQ

1. ທຳອິດ, ໃຫ້ນຳໃຊ້ RabbitMQ ໃໝ່ໃນ ເພື່ອນ namespace ກັບ ດຽວກັນ 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 ທີ່ຢູ່ຂອງຫນຶ່ງຂອງ nodes ແມ່ນພົບເຫັນ ເກົ່າ ກຸ່ມ RMQ.

ຄໍາສັ່ງເຫຼົ່ານີ້ຈະຢຸດ node ໃນປັດຈຸບັນ ໃຫມ່ ກຸ່ມ RMQ, ແນບມັນໃສ່ກຸ່ມເກົ່າ ແລະເປີດມັນອີກຄັ້ງ.

3. ກຸ່ມ RMQ ຂອງ 6 nodes ພ້ອມແລ້ວ:

ທ່ານຕ້ອງລໍຖ້າໃນຂະນະທີ່ຂໍ້ຄວາມຖືກ synchronized ລະຫວ່າງ nodes ທັງຫມົດ. ມັນບໍ່ຍາກທີ່ຈະຄາດເດົາວ່າເວລາ synchronization ຂໍ້ຄວາມແມ່ນຂຶ້ນກັບຄວາມອາດສາມາດຂອງຮາດແວທີ່ cluster ຖືກນໍາໄປໃຊ້ແລະຈໍານວນຂໍ້ຄວາມ. ໃນສະຖານະການທີ່ອະທິບາຍ, ມີພຽງແຕ່ 10 ຂອງພວກເຂົາ, ດັ່ງນັ້ນຂໍ້ມູນໄດ້ຖືກ synchronized ທັນທີ, ແຕ່ມີຈໍານວນຂໍ້ຄວາມທີ່ພຽງພໍ, synchronization ສາມາດຢູ່ໄດ້ຫຼາຍຊົ່ວໂມງ.

ດັ່ງນັ້ນ, ສະຖານະການ synchronization:

ມັນເປັນ +5 ຫມາຍຄວາມວ່າຂໍ້ຄວາມຢູ່ໃນແລ້ວ ຫຼາຍ ໃນ 5 nodes (ຍົກເວັ້ນສິ່ງທີ່ລະບຸໄວ້ໃນພາກສະຫນາມ Node). ດັ່ງນັ້ນ, synchronization ໄດ້ປະສົບຜົນສໍາເລັດ.

4. ທັງຫມົດທີ່ຍັງເຫຼືອແມ່ນເພື່ອປ່ຽນທີ່ຢູ່ RMQ ໃນແອັບພລິເຄຊັນໄປຫາກຸ່ມໃຫມ່ (ການປະຕິບັດສະເພາະຢູ່ທີ່ນີ້ແມ່ນຂຶ້ນກັບເຕັກໂນໂລຢີທີ່ທ່ານກໍາລັງໃຊ້ແລະສະເພາະຄໍາຮ້ອງສະຫມັກອື່ນໆ), ຫຼັງຈາກນັ້ນທ່ານສາມາດເວົ້າວ່າ goodbye ກັບອັນເກົ່າ.

ສໍາລັບການປະຕິບັດງານສຸດທ້າຍ (i.e. ແລ້ວ после ສະຫຼັບແອັບພລິເຄຊັນໄປເປັນກຸ່ມໃໝ່) ໄປຫາແຕ່ລະ node ເກົ່າ cluster ແລະປະຕິບັດຄໍາສັ່ງ:

rabbitmqctl stop_app
rabbitmqctl reset

ກຸ່ມ "ລືມ" ກ່ຽວກັບຂໍ້ເກົ່າ: ທ່ານສາມາດລຶບ RMQ ເກົ່າ, ໃນເວລານັ້ນ, ການເຄື່ອນໄຫວຈະສໍາເລັດ.

Примечание: ຖ້າທ່ານໃຊ້ RMQ ກັບໃບຢັ້ງຢືນ, ຫຼັງຈາກນັ້ນບໍ່ມີຫຍັງປ່ຽນແປງໂດຍພື້ນຖານ - ຂະບວນການເຄື່ອນທີ່ຈະຖືກປະຕິບັດຄືກັນ.

ການຄົ້ນພົບ

ໂຄງການທີ່ອະທິບາຍແມ່ນເຫມາະສົມສໍາລັບເກືອບທຸກກໍລະນີໃນເວລາທີ່ພວກເຮົາຕ້ອງການຍ້າຍ RabbitMQ ຫຼືພຽງແຕ່ຍ້າຍໄປກຸ່ມໃຫມ່.

ໃນກໍລະນີຂອງພວກເຮົາ, ຄວາມຫຍຸ້ງຍາກເກີດຂື້ນພຽງແຕ່ຄັ້ງດຽວ, ເມື່ອ RMQ ຖືກເຂົ້າເຖິງຈາກຫຼາຍບ່ອນ, ແລະພວກເຮົາບໍ່ມີໂອກາດທີ່ຈະປ່ຽນທີ່ຢູ່ RMQ ໄປຫາທີ່ຢູ່ໃຫມ່ຢູ່ທົ່ວທຸກແຫ່ງ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາໄດ້ເປີດຕົວ RMQ ໃຫມ່ໃນ namespace ດຽວກັນກັບປ້າຍຊື່ດຽວກັນເພື່ອໃຫ້ມັນຕົກຢູ່ພາຍໃຕ້ການບໍລິການທີ່ມີຢູ່ແລະ Ingresses, ແລະເມື່ອເປີດຕົວຝັກ, ພວກເຮົາຈັດການປ້າຍດ້ວຍມື, ເອົາພວກມັນອອກໃນຕອນເລີ່ມຕົ້ນເພື່ອບໍ່ໃຫ້ຄໍາຮ້ອງຂໍຫຼຸດລົງ. RMQ ຫວ່າງເປົ່າ, ແລະເພີ່ມພວກມັນຄືນຫຼັງຈາກຂໍ້ຄວາມຖືກ synchronized.

ພວກເຮົາໄດ້ໃຊ້ຍຸດທະສາດດຽວກັນໃນເວລາທີ່ການປັບປຸງ RabbitMQ ໃຫ້ກັບຮຸ່ນໃຫມ່ທີ່ມີການຕັ້ງຄ່າທີ່ປ່ຽນແປງ - ທຸກສິ່ງທຸກຢ່າງເຮັດວຽກຄືກັບໂມງ.

PS

ໃນຖານະເປັນການສືບຕໍ່ຢ່າງມີເຫດຜົນຂອງເອກະສານນີ້, ພວກເຮົາກໍາລັງກະກຽມບົດຄວາມກ່ຽວກັບ MongoDB (ການເຄື່ອນຍ້າຍຈາກເຄື່ອງແມ່ຂ່າຍຂອງຮາດແວໄປຫາ Kubernetes) ແລະ MySQL (ວິທີທີ່ພວກເຮົາກະກຽມ DBMS ນີ້ພາຍໃນ Kubernetes). ພວກເຂົາເຈົ້າຈະຖືກຈັດພີມມາໃນເດືອນຂ້າງຫນ້າ.

PPS

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «ຖານຂໍ້ມູນ ແລະ Kubernetes (ການທົບທວນ ແລະລາຍງານວິດີໂອ)"
• «ເຄັດລັບ ແລະເຄັດລັບຂອງ K8s: ການເລັ່ງບູດສະເຕດສຳລັບຖານຂໍ້ມູນຂະໜາດໃຫຍ່".

ແຫຼ່ງຂໍ້ມູນ: www.habr.com