🥇Ομαλή μετανάστευση του RabbitMQ στο Kubernetes

Το RabbitMQ είναι ένας μεσίτης μηνυμάτων γραμμένος στο Erlang που σας επιτρέπει να οργανώσετε ένα σύμπλεγμα ανακατεύθυνσης με πλήρη αναπαραγωγή δεδομένων σε πολλούς κόμβους, όπου κάθε κόμβος μπορεί να εξυπηρετεί αιτήματα ανάγνωσης και εγγραφής. Έχοντας πολλά συμπλέγματα Kubernetes σε λειτουργία παραγωγής, υποστηρίζουμε μεγάλο αριθμό εγκαταστάσεων RabbitMQ και αντιμετωπίσαμε την ανάγκη μετεγκατάστασης δεδομένων από το ένα σύμπλεγμα στο άλλο χωρίς διακοπές λειτουργίας.

Χρειαζόμασταν αυτήν την επέμβαση σε τουλάχιστον δύο περιπτώσεις:

Μεταφορά δεδομένων από ένα σύμπλεγμα RabbitMQ που δεν βρίσκεται στο Kubernetes σε ένα νέο - ήδη "kubernetized" (δηλαδή που λειτουργεί σε K8s pods) - σύμπλεγμα.
Μετανάστευση του RabbitMQ μέσα στο Kubernetes από έναν χώρο ονομάτων σε έναν άλλο (για παράδειγμα, εάν τα κυκλώματα οριοθετούνται από χώρους ονομάτων, στη συνέχεια για μεταφορά υποδομής από το ένα κύκλωμα στο άλλο).

Η συνταγή που προτείνεται στο άρθρο επικεντρώνεται σε καταστάσεις (αλλά δεν περιορίζεται καθόλου σε αυτές) στις οποίες υπάρχει ένα παλιό σύμπλεγμα RabbitMQ (για παράδειγμα, 3 κόμβων), που βρίσκεται ήδη είτε σε K8 είτε σε μερικούς παλιούς διακομιστές. Μια εφαρμογή που φιλοξενείται στο Kubernetes (ήδη εκεί ή στο μέλλον) λειτουργεί με αυτήν:

... και βρισκόμαστε αντιμέτωποι με το καθήκον να το μεταφέρουμε στη νέα παραγωγή στο Kubernetes.

Αρχικά, θα περιγραφεί η γενική προσέγγιση της ίδιας της μετανάστευσης και στη συνέχεια θα περιγραφούν οι τεχνικές λεπτομέρειες της εφαρμογής της.

Αλγόριθμος μετανάστευσης

Το πρώτο, προκαταρκτικό, στάδιο πριν από οποιαδήποτε ενέργεια είναι να ελέγξετε ότι η λειτουργία υψηλής διαθεσιμότητας είναι ενεργοποιημένη στην παλιά εγκατάσταση RabbitMQ (HA). Ο λόγος είναι προφανής - δεν θέλουμε να χάσουμε δεδομένα. Για να πραγματοποιήσετε αυτόν τον έλεγχο, μπορείτε να μεταβείτε στον πίνακα διαχείρισης RabbitMQ και στην καρτέλα Διαχειριστής → Πολιτικές βεβαιωθείτε ότι η τιμή έχει οριστεί ha-mode: all:

Το επόμενο βήμα είναι να δημιουργήσετε ένα νέο σύμπλεγμα RabbitMQ σε pods Kubernetes (στην περίπτωσή μας, για παράδειγμα, που αποτελείται από 3 κόμβους, αλλά ο αριθμός τους μπορεί να είναι διαφορετικός).

Μετά από αυτό, συγχωνεύουμε τα παλιά και τα νέα συμπλέγματα RabbitMQ, λαμβάνοντας ένα ενιαίο σύμπλεγμα (από 6 κόμβους):

Ξεκινά η διαδικασία συγχρονισμού δεδομένων μεταξύ του παλιού και του νέου συμπλέγματος RabbitMQ. Μόλις συγχρονιστούν όλα τα δεδομένα μεταξύ όλων των κόμβων στο σύμπλεγμα, μπορούμε να αλλάξουμε την εφαρμογή για να χρησιμοποιήσει το νέο σύμπλεγμα:

Μετά από αυτές τις λειτουργίες, αρκεί να αφαιρέσετε τους παλιούς κόμβους από το σύμπλεγμα RabbitMQ και η μετακίνηση μπορεί να θεωρηθεί ολοκληρωμένη:

Έχουμε χρησιμοποιήσει αυτό το σχήμα πολλές φορές στην παραγωγή. Ωστόσο, για δική μας διευκόλυνση, το εφαρμόσαμε σε ένα εξειδικευμένο σύστημα που διανέμει τυπικές διαμορφώσεις RMQ σε πολλαπλά συμπλέγματα Kubernetes (για όσους είναι περίεργοι: μιλάμε για addon-operatorγια το οποίο εμείς μόλις πρόσφατα είπε). Παρακάτω θα παρουσιάσουμε μεμονωμένες οδηγίες που μπορεί να εφαρμόσει ο καθένας στις εγκαταστάσεις του για να δοκιμάσει την προτεινόμενη λύση στην πράξη.

Ας το δοκιμάσουμε στην πράξη

Απαιτήσεις

Οι λεπτομέρειες είναι πολύ απλές:

Το σύμπλεγμα Kubernetes (το minikube θα λειτουργήσει επίσης).
Το σύμπλεγμα 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). Θα δημοσιευτούν τους επόμενους μήνες.

ΜΑΔ

Διαβάστε επίσης στο blog μας:

Πηγή: www.habr.com

Ομαλή μετανάστευση του RabbitMQ στο Kubernetes