Στο Citymobil χρησιμοποιούμε μια βάση δεδομένων MySQL ως την κύρια μόνιμη αποθήκευση δεδομένων. Έχουμε πολλά συμπλέγματα βάσεων δεδομένων για διάφορες υπηρεσίες και σκοπούς.

Η συνεχής διαθεσιμότητα του πλοιάρχου είναι ένας κρίσιμος δείκτης της απόδοσης ολόκληρου του συστήματος και των επιμέρους τμημάτων του. Η αυτόματη ανάκτηση συμπλέγματος σε περίπτωση αποτυχίας του κύριου συστήματος μειώνει σημαντικά τον χρόνο απόκρισης περιστατικού και το χρόνο διακοπής λειτουργίας του συστήματος. Σε αυτό το άρθρο, θα εξετάσω έναν σχεδιασμό υψηλής διαθεσιμότητας (HA) για ένα σύμπλεγμα MySQL που βασίζεται σε MySQL Orchestrator και εικονικές διευθύνσεις IP (VIP).

Λύση HA βασισμένη σε VIP

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

Χρησιμοποιούμε ένα κλασικό σχήμα αναπαραγωγής με ένα master προσβάσιμο για εγγραφή και πολλαπλά αντίγραφα μόνο για ανάγνωση. Ένα σύμπλεγμα μπορεί να περιέχει ένα ενδιάμεσο κύριο - έναν κόμβο που είναι ταυτόχρονα αντίγραφο και κύριος για άλλους. Οι πελάτες έχουν πρόσβαση σε αντίγραφα μέσω του HAProxy, το οποίο επιτρέπει την ομοιόμορφη κατανομή του φορτίου και την εύκολη κλιμάκωση. Η χρήση του HAProxy οφείλεται σε ιστορικούς λόγους και αυτή τη στιγμή βρισκόμαστε στη διαδικασία μετεγκατάστασης στο ProxySQL.

Η αναπαραγωγή εκτελείται σε ημι-σύγχρονη λειτουργία με βάση GTID. Αυτό σημαίνει ότι τουλάχιστον ένα αντίγραφο πρέπει να καταγράψει μια συναλλαγή πριν θεωρηθεί επιτυχής. Αυτή η λειτουργία αναπαραγωγής παρέχει μια βέλτιστη ισορροπία μεταξύ απόδοσης και ασφάλειας δεδομένων σε περίπτωση αποτυχίας του κύριου κόμβου. Βασικά όλες οι αλλαγές μεταφέρονται από το master στα αντίγραφα χρησιμοποιώντας Row Based Replication (RBR), αλλά ορισμένοι κόμβοι μπορεί να έχουν mixed binlog format.

Ο ενορχηστρωτής ενημερώνει περιοδικά την κατάσταση της τοπολογίας του συμπλέγματος, αναλύει τις πληροφορίες που λαμβάνει και εάν προκύψουν προβλήματα, μπορεί να ξεκινήσει μια αυτόματη διαδικασία ανάκτησης. Ο προγραμματιστής είναι υπεύθυνος για την ίδια τη διαδικασία, καθώς μπορεί να εφαρμοστεί με διαφορετικούς τρόπους: με βάση VIP, DNS, χρησιμοποιώντας υπηρεσίες εντοπισμού υπηρεσίας ή αυτογραφικούς μηχανισμούς.

Ένας απλός τρόπος για να επαναφέρετε έναν κύριο σε περίπτωση αποτυχίας είναι να χρησιμοποιήσετε κινούμενες διευθύνσεις VIP.

Τι πρέπει να γνωρίζετε για αυτήν τη λύση πριν προχωρήσετε:

• Το VIP είναι μια διεύθυνση IP που δεν σχετίζεται με μια συγκεκριμένη φυσική διεπαφή δικτύου. Εάν ένας κόμβος αποτύχει ή κατά τη διάρκεια της προγραμματισμένης συντήρησης, μπορούμε να αλλάξουμε το VIP σε άλλο πόρο με ελάχιστο χρόνο διακοπής λειτουργίας.
• Η απελευθέρωση και η έκδοση μιας εικονικής διεύθυνσης IP είναι μια φθηνή και γρήγορη λειτουργία.
• Για να εργαστείτε με VIP, χρειάζεστε πρόσβαση στον διακομιστή μέσω SSH ή τη χρήση ειδικών βοηθητικών προγραμμάτων, για παράδειγμα, keepalived.

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

Η συνδεσιμότητα δικτύου με το κύριο έχει εξαφανιστεί ή έχει προκύψει πρόβλημα σε επίπεδο υλικού και ο διακομιστής δεν είναι διαθέσιμος

1. Ο ενορχηστρωτής ενημερώνει την τοπολογία του συμπλέγματος, κάθε αντίγραφο αναφέρει ότι το master δεν είναι διαθέσιμο. Ο ενορχηστρωτής ξεκινά τη διαδικασία επιλογής ενός αντίγραφου κατάλληλου για το ρόλο του νέου master και ξεκινά την ανάκτηση.
2. Προσπαθούμε να αφαιρέσουμε το VIP από τον παλιό κύριο - χωρίς επιτυχία.
3. Το αντίγραφο μεταβαίνει στο ρόλο του κύριου. Η τοπολογία ανακατασκευάζεται.
4. Προσθήκη νέας διεπαφής δικτύου με VIP. Επειδή δεν ήταν δυνατή η κατάργηση του VIP, αρχίζουμε να στέλνουμε περιοδικά ένα αίτημα στο παρασκήνιο δωρεάν ARP. Αυτός ο τύπος αιτήματος/απόκρισης σάς επιτρέπει να ενημερώσετε τον πίνακα αντιστοίχισης διευθύνσεων IP και MAC στους συνδεδεμένους διακόπτες, ειδοποιώντας έτσι ότι το VIP μας έχει μετακινηθεί. Αυτό ελαχιστοποιεί την πιθανότητα split brain όταν επέστρεφε τον παλιό κύριο.
5. Όλες οι νέες συνδέσεις ανακατευθύνονται αμέσως στο νέο κύριο. Οι παλιές συνδέσεις αποτυγχάνουν και οι επαναλαμβανόμενες κλήσεις στη βάση δεδομένων πραγματοποιούνται σε επίπεδο εφαρμογής.

Ο διακομιστής λειτουργεί σε κανονική λειτουργία, παρουσιάστηκε αποτυχία σε επίπεδο DBMS

Ο αλγόριθμος είναι παρόμοιος με την προηγούμενη περίπτωση: ενημέρωση της τοπολογίας και έναρξη της διαδικασίας ανάκτησης. Εφόσον ο διακομιστής είναι διαθέσιμος, απελευθερώνουμε με επιτυχία το VIP στο παλιό κύριο, το μεταφέρουμε στο νέο και στέλνουμε πολλά αιτήματα ARP. Η πιθανή επιστροφή του παλιού κύριου δεν θα πρέπει να επηρεάσει το ανακατασκευασμένο σύμπλεγμα και τη λειτουργία της εφαρμογής.

Άλλα προβλήματα

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

Μια διεπαφή εικονικού δικτύου προστίθεται πάντα προσωρινά, δηλαδή, μετά την επανεκκίνηση του διακομιστή, το VIP δεν εκχωρείται αυτόματα. Κάθε στιγμιότυπο βάσης δεδομένων ξεκινά από προεπιλογή σε λειτουργία μόνο για ανάγνωση, ο ενορχηστρωτής αλλάζει αυτόματα το νέο κύριο σε εγγραφή και προσπαθεί να εγκαταστήσει read only στον παλιό κύριο. Αυτές οι ενέργειες στοχεύουν στη μείωση της πιθανότητας split brain.

Ενδέχεται να προκύψουν προβλήματα κατά τη διαδικασία ανάκτησης, η οποία θα πρέπει επίσης να ειδοποιηθεί μέσω της διεπαφής χρήστη ενορχηστρωτή εκτός από τα τυπικά εργαλεία παρακολούθησης. Επεκτείναμε το REST API προσθέτοντας αυτό το χαρακτηριστικό (PR επί του παρόντος υπό εξέταση).

Το γενικό διάγραμμα του διαλύματος ΗΑ παρουσιάζεται παρακάτω.

Επιλογή νέου πλοιάρχου

Ο ενορχηστρωτής είναι αρκετά έξυπνος και προσπαθεί να επιλέξει το καταλληλότερο αντίγραφο ως νέος πλοίαρχος σύμφωνα με τα ακόλουθα κριτήρια:

• το αντίγραφο υστερεί από τον κύριο.
• Έκδοση MySQL του master και του replica.
• τύπος αναπαραγωγής (RBR, SBR ή μικτός).
• τοποθεσία στο ίδιο ή διαφορετικά κέντρα δεδομένων·
• διαθεσιμότητα errant GTID — συναλλαγές που εκτελέστηκαν στο αντίγραφο και δεν βρίσκονται στο κύριο·
• Οι κανόνες προσαρμοσμένης επιλογής λαμβάνονται επίσης υπόψη.

Δεν είναι κάθε σύνθημα ιδανικός υποψήφιος για master. Για παράδειγμα, ένα αντίγραφο μπορεί να χρησιμοποιηθεί για τη δημιουργία αντιγράφων ασφαλείας δεδομένων ή ο διακομιστής έχει ασθενέστερη διαμόρφωση υλικού. Ενορχηστρωτής υποστηρίζει χειροκίνητους κανόνες με τους οποίους μπορείτε να προσαρμόσετε τις προτιμήσεις επιλογής υποψηφίου από τις πιο προτιμώμενες έως τις αγνοημένες.

Χρόνος απόκρισης και αποκατάστασης

Σε περίπτωση συμβάντος, είναι σημαντικό να ελαχιστοποιηθεί ο χρόνος διακοπής λειτουργίας του συστήματος, επομένως ας εξετάσουμε τις παραμέτρους της MySQL που επηρεάζουν τη δημιουργία και την ενημέρωση της τοπολογίας του συμπλέγματος από τον ενορχηστρωτή:

• slave_net_timeout — ο αριθμός των δευτερολέπτων κατά τη διάρκεια των οποίων το αντίγραφο περιμένει να φθάσουν νέα δεδομένα ή σήμα καρδιακού παλμού από τον κύριο προτού αναγνωριστεί η σύνδεση ως χαμένη και επανασυνδεθεί. Όσο χαμηλότερη είναι η τιμή, τόσο πιο γρήγορα το αντίγραφο μπορεί να προσδιορίσει ότι η επικοινωνία με τον κύριο έχει διακοπεί. Ορίσαμε αυτή την τιμή στα 5 δευτερόλεπτα.
• MASTER_CONNECT_RETRY — αριθμός δευτερολέπτων μεταξύ των προσπαθειών επανασύνδεσης. Σε περίπτωση προβλημάτων δικτύου, μια χαμηλή τιμή για αυτήν την παράμετρο θα επιτρέψει τη γρήγορη επανασύνδεση και θα αποτρέψει την έναρξη της διαδικασίας ανάκτησης συμπλέγματος. Η συνιστώμενη τιμή είναι 1 δευτερόλεπτο.
• MASTER_RETRY_COUNT — μέγιστος αριθμός προσπαθειών επανασύνδεσης.
• MASTER_HEARTBEAT_PERIOD — διάστημα σε δευτερόλεπτα μετά το οποίο ο κύριος στέλνει ένα σήμα καρδιακού παλμού. Προεπιλογή στο μισό της τιμής slave_net_timeout.

Παράμετροι ενορχηστρωτή:

• DelayMasterPromotionIfSQLThreadNotUpToDate - εάν είναι ίσο true, τότε ο κύριος ρόλος δεν θα εφαρμοστεί στο υποψήφιο αντίγραφο έως ότου το νήμα SQL του αντιγράφου ολοκληρώσει όλες τις μη εφαρμοσμένες συναλλαγές από το αρχείο καταγραφής αναμετάδοσης. Χρησιμοποιούμε αυτήν την επιλογή για να αποφύγουμε την απώλεια συναλλαγών όταν όλα τα υποψήφια αντίγραφα μένουν πίσω.
• InstancePollSeconds — συχνότητα δόμησης και ενημέρωσης της τοπολογίας.
• RecoveryPollSeconds — συχνότητα ανάλυσης τοπολογίας. Εάν εντοπιστεί πρόβλημα, ξεκινά η ανάκτηση τοπολογίας. Αυτό σταθερή, ίσο με 1 δευτερόλεπτο.

Κάθε κόμβος συμπλέγματος μετράται από τον ενορχηστρωτή μία φορά InstancePollSeconds δευτερόλεπτα Όταν εντοπιστεί ένα πρόβλημα, η κατάσταση συμπλέγματος επιβάλλεται ΕΠΙΚΑΙΡΟΠΟΙΗΜΕΝΟ, και στη συνέχεια λαμβάνεται η τελική απόφαση για την πραγματοποίηση αποκατάστασης. Πειραματιζόμενοι με διαφορετικές παραμέτρους βάσης δεδομένων και ενορχηστρωτή, μπορέσαμε να μειώσουμε τον χρόνο απόκρισης και ανάκτησης στα 30 δευτερόλεπτα.

Περίπτερο δοκιμής

Ξεκινήσαμε να δοκιμάζουμε το σχήμα HA με την ανάπτυξη ενός τοπικού πάγκος δοκιμών και περαιτέρω εφαρμογή σε περιβάλλοντα δοκιμής και παραγωγής. Το τοπικό περίπτερο είναι πλήρως αυτοματοποιημένο με βάση το Docker και σας επιτρέπει να πειραματιστείτε με τη διαμόρφωση του ενορχηστρωτή και του δικτύου, να κλιμακώσετε το σύμπλεγμα από 2-3 διακομιστές σε αρκετές δεκάδες και να διεξάγετε ασκήσεις σε ασφαλές περιβάλλον.

Κατά τη διάρκεια των ασκήσεων, επιλέγουμε μία από τις μεθόδους εξομοίωσης προβλημάτων: πυροβολήστε αμέσως τον κύριο χρησιμοποιώντας kill -9, τερματίστε απαλά τη διαδικασία και σταματήστε τον διακομιστή (docker-compose stop), προσομοίωση προβλημάτων δικτύου χρησιμοποιώντας iptables -j REJECT ή iptables -j DROP. Αναμένουμε τα ακόλουθα αποτελέσματα:

• ο ενορχηστρωτής θα εντοπίσει προβλήματα με τον κύριο και θα ενημερώσει την τοπολογία σε όχι περισσότερο από 10 δευτερόλεπτα.
• η διαδικασία ανάκτησης θα ξεκινήσει αυτόματα: η διαμόρφωση του δικτύου θα αλλάξει, ο ρόλος του master θα περάσει στο αντίγραφο, η τοπολογία θα ξαναχτιστεί.
• ο νέος κύριος θα γίνει εγγράψιμος, τα ζωντανά αντίγραφα δεν θα χαθούν κατά τη διαδικασία ανακατασκευής.
• Τα δεδομένα θα αρχίσουν να γράφονται στο νέο κύριο και να αναπαράγονται.
• Ο συνολικός χρόνος αποκατάστασης δεν θα είναι μεγαλύτερος από 30 δευτερόλεπτα.

Όπως γνωρίζετε, το σύστημα μπορεί να συμπεριφέρεται διαφορετικά σε περιβάλλοντα δοκιμής και παραγωγής λόγω διαφορετικών διαμορφώσεων υλικού και δικτύου, διαφορών στο συνθετικό και πραγματικό φορτίο κ.λπ. Επομένως, πραγματοποιούμε περιοδικά ασκήσεις σε πραγματικές συνθήκες, ελέγχοντας πώς συμπεριφέρεται το σύστημα όταν χάνεται η συνδεσιμότητα του δικτύου ή υποβαθμίζονται τα επιμέρους μέρη του. Στο μέλλον, θέλουμε να δημιουργήσουμε μια εντελώς πανομοιότυπη υποδομή και για τα δύο περιβάλλοντα και να αυτοματοποιήσουμε τις δοκιμές της.

Ευρήματα

Η υγεία του κύριου κόμβου του συστήματος αποθήκευσης είναι ένα από τα κύρια καθήκοντα της ομάδας SRE και των λειτουργιών. Η υλοποίηση της λύσης ενορχηστρωτή και HA με βάση το VIP μας επέτρεψε να επιτύχουμε τα ακόλουθα αποτελέσματα:

• αξιόπιστη ανίχνευση προβλημάτων με την τοπολογία του συμπλέγματος βάσεων δεδομένων.
• αυτόματη και γρήγορη απόκριση σε συμβάντα που σχετίζονται με τον κύριο, μειώνοντας τον χρόνο διακοπής λειτουργίας του συστήματος.

Ωστόσο, η λύση έχει τους περιορισμούς και τα μειονεκτήματά της:

• Η κλιμάκωση του σχήματος HA σε πολλά κέντρα δεδομένων θα απαιτήσει ένα ενιαίο δίκτυο L2 μεταξύ τους.
• Πριν εκχωρήσουμε VIP στο νέο κύριο, πρέπει να το απελευθερώσουμε στο παλιό. Η διαδικασία είναι διαδοχική, γεγονός που αυξάνει τον χρόνο ανάκτησης.
• Η απελευθέρωση του VIP απαιτεί πρόσβαση SSH στον διακομιστή ή οποιαδήποτε άλλη μέθοδο κλήσης απομακρυσμένων διαδικασιών. Δεδομένου ότι ο διακομιστής ή η βάση δεδομένων αντιμετωπίζει προβλήματα που προκάλεσαν τη διαδικασία ανάκτησης, δεν μπορούμε να είμαστε σίγουροι ότι η αφαίρεση VIP θα ολοκληρωθεί με επιτυχία. Και αυτό μπορεί να οδηγήσει στην εμφάνιση δύο διακομιστών με την ίδια εικονική διεύθυνση IP και ένα πρόβλημα split brain.

Να αποφύγω split brain, μπορείτε να χρησιμοποιήσετε τη μέθοδο ΣΤΟΝΙΘ ("Shoot The Other Node In The Head"), το οποίο απομονώνει ή απενεργοποιεί πλήρως τον προβληματικό κόμβο. Υπάρχουν άλλοι τρόποι για την εφαρμογή υψηλής διαθεσιμότητας συμπλέγματος: συνδυασμός VIP και DNS, υπηρεσίες εντοπισμού υπηρεσιών και διακομιστή μεσολάβησης, σύγχρονη αναπαραγωγή και άλλες μέθοδοι που έχουν τα δικά τους μειονεκτήματα και πλεονεκτήματα.

Μίλησα για την προσέγγισή μας στη δημιουργία ενός συμπλέγματος ανακατεύθυνσης MySQL. Είναι εύκολο να εφαρμοστεί και παρέχει ένα αποδεκτό επίπεδο αξιοπιστίας υπό τις τρέχουσες συνθήκες. Καθώς αναπτύσσεται ολόκληρο το σύστημα γενικά και η υποδομή ειδικότερα, αυτή η προσέγγιση αναμφίβολα θα εξελιχθεί.

Πηγή: www.habr.com