Εισαγωγή

Πριν από λίγο καιρό μου ανατέθηκε η ανάπτυξη ενός συμπλέγματος ανακατεύθυνσης για PostgreSQL, που λειτουργούν σε πολλαπλά κέντρα δεδομένων συνδεδεμένα με οπτικές ίνες εντός μιας πόλης και είναι ικανά να αντέξουν σε βλάβη (π.χ. διακοπή ρεύματος) ενός κέντρου δεδομένων. Ως λογισμικό υπεύθυνο για την ανοχή σφαλμάτων, επέλεξα Βηματοδότης, επειδή είναι η επίσημη λύση από την RedHat για τη δημιουργία συμπλεγμάτων ανακατεύθυνσης (failover). Είναι καλό επειδή το RedHat παρέχει υποστήριξη για αυτό και επειδή είναι μια καθολική (modular) λύση. Με τη βοήθειά του, θα είναι δυνατό να διασφαλιστεί η ανοχή σφαλμάτων όχι μόνο για την PostgreSQL, αλλά και για άλλες υπηρεσίες, είτε χρησιμοποιώντας τυπικές ενότητες είτε δημιουργώντας τες για συγκεκριμένες ανάγκες.

Αυτή η απόφαση έθεσε ένα εύλογο ερώτημα: πόσο ανεκτικό σε σφάλματα θα είναι το σύμπλεγμα failover; Για να διερευνήσω αυτό, ανέπτυξα μια πλατφόρμα δοκιμών που προσομοιώνει διάφορες αποτυχίες σε κόμβους συμπλέγματος, περιμένει την αποκατάσταση, αποκαθιστά τον αποτυχημένο κόμβο και συνεχίζει τις δοκιμές σε έναν βρόχο. Αυτό το έργο ονομαζόταν αρχικά hapgsql, αλλά με την πάροδο του χρόνου βαρέθηκα το όνομα που είχε μόνο ένα φωνήεν. Γι' αυτό άρχισα να καλώ βάσεις δεδομένων ανεκτικές σε σφάλματα (και τις διευθύνσεις IP float που δείχνουν προς αυτές) Κρογκάν (ένας χαρακτήρας από ένα παιχνίδι υπολογιστή που έχει όλα τα ζωτικά του όργανα διπλασιασμένα), και οι κόμβοι, οι συστάδες και το ίδιο το έργο είναι Τουτάνκα (ο πλανήτης όπου ζουν οι κρόγκαν).

Τώρα η διοίκηση έδωσε την άδεια ανοίξτε το έργο στην κοινότητα ανοιχτού κώδικα με την άδεια MIT. Το README θα μεταφραστεί σύντομα στα Αγγλικά (επειδή οι κύριοι καταναλωτές αναμένεται να είναι οι προγραμματιστές Pacemaker και PostgreSQL), και αποφάσισα να μορφοποιήσω το παλιό ρωσικό README (μερικώς) ως αυτό το άρθρο.

Τα συμπλέγματα αναπτύσσονται σε εικονικές μηχανές VirtualBox. Θα αναπτυχθούν συνολικά 12 εικονικές μηχανές (36GiB συνολικά), οι οποίες θα σχηματίσουν 4 ασφαλείς συστάδες (διαφορετικές επιλογές). Τα δύο πρώτα clusters αποτελούνται από δύο διακομιστές PostgreSQL, οι οποίοι βρίσκονται σε διαφορετικά κέντρα δεδομένων, και έναν κοινό διακομιστή. μάρτυρας c συσκευή απαρτίας (φιλοξενείται σε μια φθηνή εικονική μηχανή σε ένα τρίτο κέντρο δεδομένων) που επιλύει την αβεβαιότητα 50% / 50%, δίνοντας την ψήφο τους σε ένα από τα κόμματα. Το τρίτο σύμπλεγμα σε τρία κέντρα δεδομένων: ένα master, δύο slaves, κανένα συσκευή απαρτίας. Το τέταρτο σύμπλεγμα αποτελείται από τέσσερις διακομιστές PostgreSQL, δύο ανά κέντρο δεδομένων: ένας κύριος, οι υπόλοιποι αντίγραφα, και επίσης χρησιμοποιεί μάρτυρας c συσκευή απαρτίας. Το τέταρτο μπορεί να αντέξει την αποτυχία δύο διακομιστών ή ενός κέντρου δεδομένων. Αυτή η λύση μπορεί να κλιμακωθεί σε περισσότερα αντίγραφα, εάν χρειάζεται.

Ακριβής υπηρεσία ώρας ntpd επίσης αναδιαμορφωμένο για ανοχή σφαλμάτων, αλλά χρησιμοποιεί τη μέθοδο των πιο ntpd (ορφανή λειτουργία). Κοινόχρηστος διακομιστής μάρτυρας Λειτουργεί ως κεντρικός διακομιστής NTP, κατανέμοντας τον χρόνο του σε όλα τα clusters, συγχρονίζοντας έτσι όλους τους διακομιστές μεταξύ τους. Αν μάρτυρας αποτύχει ή απομονωθεί, τότε ένας από τους διακομιστές συμπλέγματος (εντός του συμπλέγματος) θα ξεκινήσει την κατανομή του χρόνου του. Βοηθητική προσωρινή αποθήκευση HTTP proxy επίσης τέθηκε σε μάρτυρας, με τη βοήθειά του άλλες εικονικές μηχανές έχουν πρόσβαση στα αποθετήρια Yum. Στην πραγματικότητα, υπηρεσίες όπως η ακριβής ώρα και το proxy πιθανότατα θα φιλοξενούνται σε αποκλειστικούς διακομιστές, ενώ στο περίπτερο φιλοξενούνται σε μάρτυρας απλώς για να εξοικονομήσουμε τον αριθμό των εικονικών μηχανών και χώρο.

Εκδόσεις

έκδοση 0. Λειτουργεί με CentOS 7 και PostgreSQL 11 σε VirtualBox 6.1.

Δομή συστάδας

Όλα τα clusters έχουν σχεδιαστεί για να βρίσκονται σε πολλά κέντρα δεδομένων, είναι συνδεδεμένα σε ένα ενιαίο επίπεδο δίκτυο και πρέπει να αντέχουν σε αστοχία ή απομόνωση δικτύου ενός κέντρου δεδομένων. Γι' αυτό είναι αδύνατο χρήση για προστασία από διχασμένος εγκέφαλος Η τυπική τεχνολογία του βηματοδότη, η οποία ονομάζεται ΣΤΟΝΙΘ (Πυροβολήστε τον άλλο κόμβο στο κεφάλι) ή ξιφασκία. Η ουσία του: εάν οι κόμβοι στο σύμπλεγμα αρχίσουν να υποψιάζονται ότι κάτι δεν πάει καλά με κάποιον κόμβο, δεν ανταποκρίνεται ή συμπεριφέρεται λανθασμένα, τότε τον απενεργοποιούν βίαια μέσω "εξωτερικών" συσκευών, για παράδειγμα, μιας κάρτας ελέγχου IPMI ή UPS. Αλλά αυτό θα λειτουργήσει μόνο σε περιπτώσεις όπου, ακόμη και με μία μόνο βλάβη διακομιστή, το IPMI ή το UPS συνεχίζουν να λειτουργούν. Εδώ, η προστασία σχεδιάζεται έναντι μιας πολύ πιο καταστροφικής βλάβης, όταν ολόκληρο το κέντρο δεδομένων παρουσιάσει βλάβη (για παράδειγμα, απενεργοποιηθεί). Και με μια τέτοια άρνηση, όλα πέτρινος-οι συσκευές (IPMI, UPS, κ.λπ.) επίσης δεν θα λειτουργούν.

Αντίθετα, το σύστημα βασίζεται στην ιδέα της απαρτίας. Όλοι οι κόμβοι έχουν δικαίωμα ψήφου και μόνο όσοι μπορούν να δουν περισσότερους από τους μισούς κόμβους μπορούν να λειτουργήσουν. Αυτή η ποσότητα "μισό+1" ονομάζεται απαρτία. Εάν δεν επιτευχθεί απαρτία, ο κόμβος αποφασίζει ότι βρίσκεται σε απομόνωση δικτύου και πρέπει να απενεργοποιήσει τους πόρους του, δηλαδή έχει ως εξής: Προστασία από διχασμένο εγκέφαλο. Εάν το λογισμικό που ευθύνεται για μια τέτοια συμπεριφορά δεν λειτουργεί, τότε θα πρέπει να ενεργοποιηθεί ένας watchdog (φύλακας), για παράδειγμα, βασισμένος στο IPMI.

Εάν ο αριθμός των κόμβων είναι ζυγός (συστάδα σε δύο κέντρα δεδομένων), τότε μπορεί να προκύψει η λεγόμενη αβεβαιότητα 50% / 50% (πενήντα-πενήντα), όταν η απομόνωση δικτύου διαιρεί το σύμπλεγμα ακριβώς στο μισό. Επομένως, για άρτιο αριθμό κόμβων, προσθέστε συσκευή απαρτίας — ένας δαίμονας χωρίς απαιτήσεις που μπορεί να εκτελεστεί στην φθηνότερη εικονική μηχανή στο τρίτο κέντρο δεδομένων. Δίνει την ψήφο του σε ένα από τα τμήματα (αυτό που βλέπει) και έτσι επιλύει την αβεβαιότητα 50%/50%. Ονόμασα τον διακομιστή στον οποίο θα εκκινηθεί η συσκευή απαρτίας μάρτυρας (ορολογία από το repmgr, μου άρεσε).

Οι πόροι μπορούν να μετακινηθούν από τόπο σε τόπο, για παράδειγμα, από ελαττωματικούς διακομιστές σε λειτουργικούς ή κατόπιν εντολής διαχειριστών συστήματος. Για να διασφαλιστεί ότι οι πελάτες γνωρίζουν πού βρίσκονται οι πόροι που χρειάζονται (πού να συνδεθούν;), κινητή IP (κινητή IP). Αυτές είναι διευθύνσεις IP που μπορεί να μετακινήσει το Pacemaker μεταξύ κόμβων (όλα βρίσκονται σε ένα επίπεδο δίκτυο). Κάθε ένα από αυτά συμβολίζει έναν πόρο (υπηρεσία) και θα βρίσκεται στο σημείο όπου πρέπει να συνδεθείτε για να αποκτήσετε πρόσβαση σε αυτήν την υπηρεσία (στην περίπτωσή μας, τη βάση δεδομένων).

Tuchanka1 (σχέδιο με συμπύκνωση)

Δομή

Η ιδέα ήταν ότι έχουμε πολλές μικρές βάσεις δεδομένων με χαμηλό φόρτο εργασίας, για τις οποίες δεν είναι επικερδές να διατηρούμε έναν αποκλειστικό διακομιστή slave σε λειτουργία αναμονής για συναλλαγές μόνο για ανάγνωση (δεν υπάρχει λόγος για τέτοια σπατάλη πόρων).

Κάθε κέντρο δεδομένων διαθέτει έναν διακομιστή. Κάθε διακομιστής έχει δύο στιγμιότυπα PostgreSQL (στην ορολογία της PostgreSQL ονομάζονται συστάδες, αλλά για να αποφευχθεί η σύγχυση θα τα ονομάσω στιγμιότυπα (κατ' αναλογία με άλλες βάσεις δεδομένων) και θα ονομάσω μόνο τα συμπλέγματα Pacemaker συστάδες). Μία παρουσία λειτουργεί σε λειτουργία master και μόνο αυτή παρέχει υπηρεσίες (η IP float δείχνει μόνο σε αυτήν). Η δεύτερη περίπτωση λειτουργεί ως υποτελής μονάδα (slave) για το δεύτερο κέντρο δεδομένων και θα παρέχει υπηρεσίες μόνο εάν ο κύριος υπολογιστής του αποτύχει. Δεδομένου ότι τις περισσότερες φορές μόνο μία από τις δύο (η κύρια) θα παρέχει υπηρεσίες (εκτελώντας αιτήματα), όλοι οι πόροι του διακομιστή βελτιστοποιούνται για την κύρια (η μνήμη εκχωρείται για την προσωρινή μνήμη shared_buffers, κ.λπ.), αλλά έτσι ώστε η δεύτερη παρουσία να έχει επίσης αρκετούς πόρους (ακόμα και για μη βέλτιστη εργασία μέσω της προσωρινής μνήμης του συστήματος αρχείων) σε περίπτωση που ένα από τα κέντρα δεδομένων αποτύχει. Ο slave δεν παρέχει υπηρεσίες (δεν εκτελεί αιτήματα μόνο για ανάγνωση) κατά τη διάρκεια της κανονικής λειτουργίας του cluster, έτσι ώστε να μην υπάρχει πόλεμος για πόρους με τον master στον ίδιο υπολογιστή.

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

Άρνηση μάρτυρα

Άρνηση μάρτυρα (συσκευή απαρτίας) Θα το εξετάσω μόνο για το σύμπλεγμα Tuchanka1, με όλα τα άλλα θα είναι η ίδια ιστορία. Εάν ο μάρτυρας αποτύχει, τίποτα δεν θα αλλάξει στη δομή του συμπλέγματος. όλα θα συνεχίσουν να λειτουργούν όπως πριν. Αλλά η απαρτία θα είναι 2 στα 3, και έτσι οποιαδήποτε περαιτέρω αποτυχία θα είναι μοιραία για το σύμπλεγμα. Θα πρέπει να επισκευαστεί επειγόντως ούτως ή άλλως.

Η άρνηση του Tuchanka1

Αποτυχία ενός από τα κέντρα δεδομένων για το Tuchanka1. Σε αυτήν την περίπτωση μάρτυρας ψηφίζει τον δεύτερο κόμβο στο δεύτερο κέντρο δεδομένων. Εκεί, ο πρώην slave μετατρέπεται σε master, με αποτέλεσμα και οι δύο masters να εργάζονται σε έναν server και οι δύο float IP τους να δείχνουν προς αυτούς.

Tuchanka2 (κλασικό)

Δομή

Κλασικός σχεδιασμός δύο κόμβων. Ο αφέντης εργάζεται στο ένα, ο σκλάβος στο άλλο. Και οι δύο μπορούν να εκτελέσουν αιτήματα (ο slave είναι μόνο για ανάγνωση), επομένως και οι δύο έχουν float IPs: krogan2 - προς τον master, krogan2s1 - προς τον slave. Τόσο ο κύριος όσο και ο σκλάβος θα είναι ανεκτικοί σε σφάλματα.

Στην περίπτωση δύο κόμβων, η ανοχή σφαλμάτων είναι δυνατή μόνο με ασύγχρονη αναπαραγωγή, επειδή με τη σύγχρονη αναπαραγωγή, μια βλάβη του slave θα οδηγήσει στη διακοπή του master.

Η άρνηση του Tuchanka2

Εάν ένα από τα κέντρα δεδομένων παρουσιάσει βλάβη μάρτυρας ψήφους για το δεύτερο. Το μόνο λειτουργικό κέντρο δεδομένων θα έχει έναν κύριο διακομιστή σε λειτουργία και και οι δύο διευθύνσεις IP float θα δείχνουν σε αυτόν: ο κύριος και ο δευτερεύων διακομιστής. Φυσικά, η παρουσία πρέπει να ρυθμιστεί με τέτοιο τρόπο ώστε να διαθέτει αρκετούς πόρους (όρια σύνδεσης κ.λπ.) για να δέχεται ταυτόχρονα όλες τις συνδέσεις και τα αιτήματα από την κύρια και την δευτερεύουσα διεύθυνση float. Δηλαδή, κατά την κανονική λειτουργία θα πρέπει να έχει επαρκές απόθεμα ορίων.

Tuchanka4 (πολλοί σκλάβοι)

Δομή

Αυτό είναι ένα άλλο άκρο. Υπάρχουν βάσεις δεδομένων που λαμβάνουν πολλά αιτήματα μόνο για ανάγνωση (μια τυπική περίπτωση ιστότοπου με υψηλό φόρτο εργασίας). Το Tuchanka4 είναι μια κατάσταση όπου μπορεί να υπάρχουν τρεις ή περισσότεροι slaves για να χειριστούν τέτοια αιτήματα, αλλά και πάλι όχι πάρα πολλοί. Με έναν πολύ μεγάλο αριθμό slaves, θα είναι απαραίτητο να εφευρεθεί ένα ιεραρχικό σύστημα αναπαραγωγής. Στην ελάχιστη περίπτωση (στην εικόνα), καθένα από τα δύο κέντρα δεδομένων περιέχει δύο διακομιστές, ο καθένας με μια παρουσία PostgreSQL.

Ένα άλλο χαρακτηριστικό αυτού του σχήματος είναι ότι είναι ήδη δυνατή η οργάνωση μίας σύγχρονης αντιγραφής. Έχει ρυθμιστεί ώστε να αναπαράγει, εάν είναι δυνατόν, σε άλλο κέντρο δεδομένων, αντί για ένα αντίγραφο στο ίδιο κέντρο δεδομένων με το κύριο. Ο κύριος και κάθε υποτελής υποδεικνύονται από μια IP με κινητή χωρητικότητα. Ιδανικά, θα ήταν απαραίτητο να εξισορροπηθούν τα αιτήματα μεταξύ των slaves με κάποιο τρόπο. sql proxy, για παράδειγμα, από την πλευρά του πελάτη. Διαφορετικοί τύποι πελατών ενδέχεται να απαιτούν διαφορετικούς τύπους sql proxyκαι μόνο οι προγραμματιστές-πελάτες γνωρίζουν ποιος χρειάζεται ποιον. Αυτή η λειτουργικότητα μπορεί να υλοποιηθεί είτε από έναν εξωτερικό δαίμονα είτε από μια βιβλιοθήκη-πελάτη (connection pool), κ.λπ. Όλα αυτά είναι πέρα από το πεδίο εφαρμογής του θέματος ενός συμπλέγματος βάσης δεδομένων failover (failover SQL proxy μπορεί να υλοποιηθεί ανεξάρτητα, μαζί με την ανοχή σφαλμάτων του πελάτη).

Η άρνηση του Tuchanka4

Εάν ένα κέντρο δεδομένων (δηλαδή δύο διακομιστές) παρουσιάσει βλάβη, ο μάρτυρας ψηφίζει για το δεύτερο. Ως αποτέλεσμα, στο δεύτερο κέντρο δεδομένων λειτουργούν δύο διακομιστές: ο κύριος διακομιστής εκτελείται σε έναν και η διεύθυνση IP του κύριου float δείχνει σε αυτόν (για λήψη αιτημάτων ανάγνωσης-εγγραφής). και στον δεύτερο διακομιστή εκτελείται ένας δευτερεύων διακομιστής με σύγχρονη αναπαραγωγή και μία από τις διευθύνσεις IP του δευτερεύοντος διακομιστή υποδεικνύει αυτόν (για αιτήματα μόνο για ανάγνωση).

Το πρώτο πράγμα που πρέπει να σημειωθεί είναι ότι δεν θα λειτουργούν όλες οι διευθύνσεις IP slave float, αλλά μόνο μία. Και για σωστή εργασία με αυτό θα είναι απαραίτητο sql proxy ανακατεύθυνσε όλα τα αιτήματα στην μόνη εναπομένουσα IP float. και αν sql proxy όχι, τότε μπορείτε να παραθέσετε όλες τις υποτελείς IP float διαχωρισμένες με κόμματα στη διεύθυνση URL για σύνδεση. Σε αυτή την περίπτωση, με libpq Η σύνδεση θα γίνει με την πρώτη λειτουργική IP, έτσι γίνεται στο αυτόματο σύστημα δοκιμών. Ίσως σε άλλες βιβλιοθήκες, για παράδειγμα, στο JDBC, να μην λειτουργεί με αυτόν τον τρόπο και είναι απαραίτητο. sql proxy. Αυτό γίνεται επειδή η διεύθυνση IP float για τους slaves απαγορεύεται να αυξάνεται ταυτόχρονα σε έναν διακομιστή, έτσι ώστε να κατανέμονται ομοιόμορφα σε όλους τους slave servers εάν εκτελούνται αρκετοί από αυτούς.

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

Tuchanka3 (3 κέντρα δεδομένων)

Δομή

Αυτό είναι ένα σύμπλεγμα για μια περίπτωση όπου υπάρχουν τρία πλήρως λειτουργικά κέντρα δεδομένων, καθένα από τα οποία διαθέτει έναν πλήρως λειτουργικό διακομιστή βάσης δεδομένων. Σε αυτήν την περίπτωση συσκευή απαρτίας δεν χρειάζεται. Ένα κέντρο δεδομένων έχει έναν κύριο (master), ενώ τα άλλα δύο έχουν slaves (εξαρτώμενους) κεντρικούς υπολογιστές (slaves). Η αντιγραφή είναι σύγχρονη, τύπου ANY (slave1, slave2), που σημαίνει ότι ο πελάτης θα λάβει μια επιβεβαίωση υποβολής όταν κάποιος από τους slaves απαντήσει για πρώτη φορά ότι έχει αποδεχτεί την υποβολή. Οι πόροι υποδεικνύονται από μία IP float για τον κύριο και δύο για τους υποτελείς. Σε αντίθεση με το Tuchanka4, και οι τρεις διευθύνσεις IP float είναι ανεκτικές σε σφάλματα. Για να εξισορροπήσετε τα ερωτήματα SQL μόνο για ανάγνωση, μπορείτε να χρησιμοποιήσετε sql proxy (με ξεχωριστή ανοχή σφαλμάτων) ή αντιστοιχίστε μία IP slave float στους μισούς πελάτες και την άλλη μισή στον δεύτερο.

Η άρνηση του Tuchanka3

Αν ένα κέντρο δεδομένων αποτύχει, μένουν δύο. Στη μία, η κύρια και η διεύθυνση IP float από την κύρια αυξάνονται, στη δεύτερη - η διεύθυνση IP float του slave και και οι δύο διευθύνσεις IP float του slave (η παρουσία πρέπει να έχει διπλό απόθεμα πόρων για να δεχτεί όλες τις συνδέσεις και από τις δύο διευθύνσεις IP float του slave). Υπάρχει σύγχρονη αντιγραφή μεταξύ masters και slaves. Το σύμπλεγμα θα αποθηκεύει επίσης πληροφορίες σχετικά με τις δεσμευμένες και επιβεβαιωμένες συναλλαγές (δεν θα υπάρξει απώλεια πληροφοριών) σε περίπτωση καταστροφής δύο κέντρων δεδομένων (εάν δεν καταστραφούν ταυτόχρονα).

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

Αυτόματο σύστημα δοκιμών

Για να ελεγχθεί η ανοχή σφαλμάτων των συστάδων μέσω προσομοίωσης διαφόρων σφαλμάτων, δημιουργήθηκε ένα αυτόματο σύστημα δοκιμών. Εκτέλεση από σενάριο test/failure. Το σενάριο μπορεί να λάβει ως παραμέτρους τον αριθμό των συστάδων που θέλετε να ελέγξετε. Για παράδειγμα, αυτή η εντολή:

test/failure 2 3

θα ελέγξει μόνο το δεύτερο και το τρίτο σύμπλεγμα. Εάν δεν καθοριστούν παράμετροι, θα ελεγχθούν όλες οι συστάδες. Όλα τα clusters ελέγχονται παράλληλα και τα αποτελέσματα εμφανίζονται στον πίνακα tmux. Το Tmux χρησιμοποιεί έναν αποκλειστικό διακομιστή tmux, επομένως το σενάριο μπορεί να εκτελεστεί από την προεπιλεγμένη ρύθμιση tmux, με αποτέλεσμα ένα nested tmux. Συνιστώ να χρησιμοποιείτε το τερματικό σε ένα μεγάλο παράθυρο και με μικρή γραμματοσειρά. Πριν από την έναρξη των δοκιμών, όλες οι εικονικές μηχανές επανέρχονται σε ένα στιγμιότυπο της στιγμής που ολοκληρώθηκε το σενάριο. setup.

Το τερματικό χωρίζεται σε στήλες με βάση τον αριθμό των δοκιμασμένων συστάδων, από προεπιλογή (στο στιγμιότυπο οθόνης) υπάρχουν τέσσερις. Θα περιγράψω τα περιεχόμενα των στηλών χρησιμοποιώντας το Tuchanka2 ως παράδειγμα. Τα πάνελ στο στιγμιότυπο οθόνης είναι αριθμημένα:

Τα στατιστικά στοιχεία για τις δοκιμές εμφανίζονται εδώ. Στήλες:
- αποτυχία — το όνομα της δοκιμής (συνάρτηση στο σενάριο) που μιμείται το σφάλμα.
- αντίδραση — ο μέσος αριθμητικός χρόνος σε δευτερόλεπτα που χρειάζεται το σύμπλεγμα για να αποκαταστήσει τη λειτουργικότητά του. Μετράται από την έναρξη του σεναρίου που προσομοιώνει την αποτυχία μέχρι τη στιγμή που το σύμπλεγμα αποκαθιστά τη λειτουργικότητά του και είναι σε θέση να συνεχίσει να παρέχει υπηρεσίες. Εάν ο χρόνος είναι πολύ μικρός, για παράδειγμα, έξι δευτερόλεπτα (αυτό συμβαίνει σε ομάδες με αρκετούς υποτελείς (Tuchanka3 και Tuchanka4)), αυτό σημαίνει ότι το σφάλμα ήταν στον ασύγχρονο υποτελή και δεν επηρέασε την απόδοση με κανέναν τρόπο. Δεν υπήρχαν διακόπτες κατάστασης συμπλέγματος.
- απόκλιση — δείχνει την εξάπλωση (ακρίβεια) της τιμής αντίδραση με τη μέθοδο της «τυπικής απόκλισης».
- μετράνε - πόσες φορές πραγματοποιήθηκε αυτή η δοκιμή.
Το σύντομο αρχείο καταγραφής σάς επιτρέπει να αξιολογήσετε τι κάνει το σύμπλεγμα αυτήν τη στιγμή. Εμφανίζονται ο αριθμός επανάληψης (δοκιμής), η χρονική σήμανση και το όνομα της λειτουργίας. Η υπερβολική καθυστέρηση στην ολοκλήρωση (> 5 λεπτά) υποδηλώνει κάποιο πρόβλημα.
καρδιά (καρδιά) - τρέχουσα ώρα. Για οπτική αξιολόγηση της απόδοσης μάστορες Η τρέχουσα ώρα εγγράφεται συνεχώς στον πίνακά της χρησιμοποιώντας την IP float της κύριας διεύθυνσης. Εάν είναι επιτυχής, το αποτέλεσμα εμφανίζεται σε αυτόν τον πίνακα.
κτύπησε (παλμός) - "τρέχουσα ώρα", η οποία είχε καταγραφεί προηγουμένως από το σενάριο καρδιά στην κύρια έκδοση, τώρα διαβάζεται από δούλος μέσω της float IP του. Σας επιτρέπει να αξιολογήσετε οπτικά την απόδοση του slave και της αναπαραγωγής. Στο Tuchanka1 δεν υπάρχουν slaves με float IP (δεν υπάρχουν slaves που να παρέχουν υπηρεσίες), αλλά υπάρχουν δύο instances (DB), επομένως δεν θα εμφανίζονται εδώ. κτύπησεΚαι καρδιά δεύτερη περίπτωση.
Παρακολούθηση της κατάστασης του συμπλέγματος χρησιμοποιώντας το βοηθητικό πρόγραμμα pcs mon. Δείχνει τη δομή, την κατανομή πόρων σε όλους τους κόμβους και άλλες χρήσιμες πληροφορίες.
Αυτό εμφανίζει την παρακολούθηση συστήματος από κάθε εικονική μηχανή στο σύμπλεγμα. Μπορεί να υπάρχουν περισσότερα τέτοια πάνελ - ανάλογα με το πόσες εικονικές μηχανές έχει το σύμπλεγμα. Δύο γραφήματα CPU Load (σε εικονικές μηχανές με δύο επεξεργαστές), όνομα εικονικής μηχανής, Φορτίο συστήματος (ονομάζεται Μέσος Όρος Φόρτωσης επειδή υπολογίζεται κατά μέσο όρο σε διάστημα 5, 10 και 15 λεπτών), δεδομένα διεργασίας και κατανομή μνήμης.
Παρακολουθήστε το σενάριο που εκτελεί τις δοκιμές. Σε περίπτωση δυσλειτουργίας - ξαφνικής διακοπής της εργασίας ή ατελείωτου κύκλου αναμονής - ο λόγος για μια τέτοια συμπεριφορά μπορεί να φανεί εδώ.

Η δοκιμή διεξάγεται σε δύο στάδια. Αρχικά, το σενάριο υποβάλλεται σε όλους τους τύπους δοκιμών, επιλέγοντας τυχαία μια εικονική μηχανή για να εφαρμόσει αυτήν τη δοκιμή. Στη συνέχεια, εκτελείται ένας άπειρος κύκλος δοκιμών, με τις εικονικές μηχανές και το σφάλμα να επιλέγονται τυχαία κάθε φορά. Ένας απότομος τερματισμός του σεναρίου δοκιμής (κάτω πλαίσιο) ή ένας ατέρμονος βρόχος αναμονής για κάτι (χρόνος εκτέλεσης > 5 λεπτά μιας λειτουργίας, αυτό μπορεί να φανεί στην ιχνηλάτηση) υποδεικνύει ότι μία από τις δοκιμές σε αυτό το σύμπλεγμα έχει αποτύχει.

Κάθε δοκιμή αποτελείται από τις ακόλουθες λειτουργίες:

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

Ακολουθεί μια λίστα με δοκιμές με μια περιγραφή του τι κάνουν:

ForkBomb: δημιουργεί το "Out of memory" χρησιμοποιώντας μια βόμβα fork.
Εκτός Διαστήματος: ο σκληρός δίσκος είναι γεμάτος. Αλλά η δοκιμασία είναι μάλλον συμβολική. Με το ασήμαντο φορτίο που δημιουργείται κατά τη διάρκεια των δοκιμών, όταν ο σκληρός δίσκος είναι γεμάτος, η PostgreSQL συνήθως δεν αποτυγχάνει.
Postgres-KILL: τερματίζει την PostgreSQL με εντολή killall -KILL postgres.
Postgres-STOP: κολλάει την PostgreSQL με την εντολή killall -STOP postgres.
Απενεργοποίηση: "απενεργοποιεί" την εικονική μηχανή με την εντολή VBoxManage controlvm "виртуалка" poweroff.
Επαναφορά: υπερφορτώνει την εικονική μηχανή με την εντολή VBoxManage controlvm "виртуалка" reset.
SBD-STOP: κρεμάει τον δαίμονα SBD με την εντολή killall -STOP sbd.
ΤΕΡΜΑΤΙΣΜΟΣ ΛΕΙΤΟΥΡΓΙΑΣ: στέλνει μια εντολή στην εικονική μηχανή μέσω SSH systemctl poweroff, το σύστημα απενεργοποιείται σωστά.
Αποσύνδεση: απομόνωση δικτύου, εντολή VBoxManage controlvm "виртуалка" setlinkstate1 off.

Ολοκληρώστε τη δοκιμή είτε με την τυπική εντολή tmux "kill-window" Ctrl-b &, ή με την εντολή "detach-client" Ctrl-b d: σε αυτό το σημείο η δοκιμή ολοκληρώνεται, το tmux κλείνει και οι εικονικές μηχανές απενεργοποιούνται.

Προβλήματα που εντοπίστηκαν κατά τη διάρκεια των δοκιμών

Αυτή τη στιγμή δαίμονας φύλακας sbd χειρίζεται το σταμάτημα των παρατηρούμενων δαιμόνων, αλλά όχι το πάτημα του κουμπιού στο οποίο αναστείλουν την λειτουργία τους. Και, ως αποτέλεσμα, τα σφάλματα δεν υποβάλλονται σωστά σε επεξεργασία, οδηγώντας μόνο σε πάγωμα Corosync и Βηματοδότης, αλλά δεν κρέμεται sbd. Για επαλήθευση Corosync έχει ήδη PR # 83 (στο GitHub στη διεύθυνση sbd), έγινε δεκτός στο υποκατάστημα κύριος. Υποσχέθηκαν (στην PR#83) ότι θα υπήρχε κάτι παρόμοιο για το Pacemaker, ελπίζω ότι μέχρι κόκκινο καπέλο 8 θα το κάνουν. Αλλά τέτοιες «δυσλειτουργίες» είναι εικασίες και μπορούν εύκολα να προσομοιωθούν τεχνητά χρησιμοποιώντας, για παράδειγμα, killall -STOP corosync, αλλά δεν συναντιούνται ποτέ στην πραγματική ζωή.
У Βηματοδότης στην έκδοση για 7 CentOS λανθασμένα ρυθμισμένο συγχρονισμός_χρόνου у συσκευή απαρτίας, ως αποτέλεσμα Εάν ένας κόμβος αποτύγχανε, υπήρχε μια ορισμένη πιθανότητα να επανεκκινηθεί και ο δεύτερος κόμβος., στο οποίο υποτίθεται ότι θα μετακινηθεί ο πλοίαρχος. Θεραπεύτηκε με αύξηση συγχρονισμός_χρόνου у συσκευή απαρτίας κατά την ανάπτυξη (σε σενάριο setup/setup1). Αυτή η τροπολογία δεν έγινε δεκτή από τους κατασκευαστές. Βηματοδότης, αντ' αυτού υποσχέθηκαν να αναδιαμορφώσουν την υποδομή έτσι ώστε (σε κάποιο απροσδιόριστο μέλλον) αυτό το χρονικό όριο να υπολογίζεται αυτόματα.
Εάν η διαμόρφωση της βάσης δεδομένων καθορίζει ότι LC_MESSAGES (μηνύματα κειμένου) Μπορεί να χρησιμοποιηθεί Unicode, για παράδειγμα, ru_RU.UTF-8, τότε όταν ξεκινήσετε postgres σε ένα περιβάλλον όπου η τοπική ρύθμιση δεν είναι UTF-8, ας πούμε, σε ένα κενό περιβάλλον (εδώ βηματοδότης+pgsqlms(paf) λανσάρει postgres), Οτι στο αρχείο καταγραφής αντί για γράμματα UTF-8 θα υπάρχουν ερωτηματικά. Οι προγραμματιστές της PostgreSQL δεν έχουν ακόμη συμφωνήσει για το τι πρέπει να κάνουν σε αυτήν την περίπτωση. Κοστίζει, πρέπει να το εγκαταστήσετε LC_MESSAGES=en_US.UTF-8 κατά τη διαμόρφωση (δημιουργία) μιας παρουσίας βάσης δεδομένων.
Εάν έχει οριστεί η τιμή wal_receiver_timeout (από προεπιλογή είναι 60 δευτερόλεπτα), τότε κατά τη διάρκεια της δοκιμής PostgreSQL-STOP στον κύριο φάκελο στα συμπλέγματα tuchanka3 και tuchanka4 Η αναπαραγωγή δεν επανασυνδέεται με τον νέο κύριο κώδικα. Η αντιγραφή εκεί είναι σύγχρονη, επομένως όχι μόνο ο slave σταματά, αλλά και ο νέος master. Λύση: ορίστε την τιμή wal_receiver_timeout=0 κατά τη ρύθμιση παραμέτρων του PostgreSQL.
Σπάνια παρατηρήθηκε πάγωμα αντιγραφής στην PostgreSQL στη δοκιμή ForkBomb (υπερχείλιση μνήμης). Μετά το ForkBomb, μερικές φορές οι slaves ενδέχεται να μην επανασυνδεθούν με τον νέο master.. Το έχω συναντήσει αυτό μόνο στα clusters tuchanka3 και tuchanka4, όπου ο master κολλούσε λόγω του γεγονότος ότι η αναπαραγωγή ήταν σύγχρονη. Το πρόβλημα εξαφανίστηκε από μόνο του μετά από κάποιο χρονικό διάστημα (περίπου δύο ώρες). Απαιτείται περαιτέρω έρευνα για να διορθωθεί αυτό. Τα συμπτώματα είναι παρόμοια με το προηγούμενο σφάλμα, το οποίο προκαλείται από διαφορετική αιτία, αλλά με τις ίδιες συνέπειες.