Εισαγωγή

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

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

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

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

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

Εκδόσεις

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

Δομή συμπλέγματος

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

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

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

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

Tuchanka1 (συμπιεσμένο σχήμα)

Δομή

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

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

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

αποτυχία μαρτυρίας

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

Απόρριψη Tuchanka1

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

Tuchanka2 (κλασικό)

Δομή

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

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

Απόρριψη Tuchanka2

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

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

Δομή

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

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

Απόρριψη Tuchanka4

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

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

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

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

Δομή

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

Απόρριψη Tuchanka3

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

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

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

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

test/failure 2 3

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

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

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

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

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

1. Εκκίνηση μιας λειτουργίας που εξομοιώνει ένα σφάλμα.
2. Έτοιμοι; - αναμονή για την αποκατάσταση της υγείας του συμπλέγματος (όταν παρέχονται όλες οι υπηρεσίες).
3. Εμφανίζεται το χρονικό όριο ανάκτησης συμπλέγματος (αντίδραση).
4. σταθερός - το σύμπλεγμα «επισκευάζεται». Μετά από αυτό θα πρέπει να επιστρέψει σε κατάσταση πλήρως λειτουργική και έτοιμο για την επόμενη δυσλειτουργία.

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

• Forkbomb: Δημιουργεί "Out of memory" με βόμβα πιρουνιού.
• Δίχως χώρο: ο σκληρός δίσκος είναι γεμάτος. Αλλά η δοκιμή είναι μάλλον συμβολική, με το ασήμαντο φορτίο που δημιουργείται κατά τη δοκιμή, όταν ο σκληρός δίσκος ξεχειλίζει, η 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&, ή με την εντολή "detch-client" ctrl-bd: ταυτόχρονα, ολοκληρώνεται η δοκιμή, κλείνει το tmux, απενεργοποιούνται οι εικονικές μηχανές.

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

• Αυτή τη στιγμή φύλακας δαίμονας sbd χειρίζεται να σταματήσει τους παρατηρούμενους δαίμονες, αλλά όχι να τους παγώσει. Και, ως αποτέλεσμα, οι δυσλειτουργίες επιλύονται εσφαλμένα, οδηγώντας μόνο σε πάγωμα Corosync и Βηματοδότης, αλλά όχι κρεμασμένο sbd. Για έλεγχο Corosync έχει ήδη PR # 83 (στο GitHub στη διεύθυνση sbd), έγινε δεκτός στο υποκατάστημα κύριος. Υποσχέθηκαν (στο PR#83) ότι θα υπήρχε κάτι παρόμοιο για το Pacemaker, ελπίζω ότι μέχρι κόκκινο καπέλο 8 θα κάνω. Αλλά τέτοιες «δυσλειτουργίες» είναι κερδοσκοπικές, μιμούνται εύκολα τεχνητά χρησιμοποιώντας, για παράδειγμα, killall -STOP corosyncαλλά ποτέ δεν συναντιούνται στην πραγματική ζωή.

• У Βηματοδότης στην έκδοση για 7 CentOS έχει ρυθμιστεί λανθασμένα sync_timeout у συσκευή απαρτίας, σαν άποτέλεσμα Εάν ένας κόμβος απέτυχε, ο δεύτερος κόμβος επανεκκινούσε με κάποια πιθανότητα, στο οποίο έπρεπε να μετακινηθεί ο πλοίαρχος. Θεραπεύεται με αύξηση sync_timeout у συσκευή απαρτίας κατά την ανάπτυξη (σε σενάριο setup/setup1). Αυτή η τροπολογία δεν έγινε αποδεκτή από τους προγραμματιστές Βηματοδότης, αντίθετα υποσχέθηκαν να δουλέψουν ξανά την υποδομή με τέτοιο τρόπο (σε κάποιο απροσδιόριστο μέλλον) ώστε αυτό το χρονικό όριο να υπολογίζεται αυτόματα.

• Εάν καθορίσατε κατά τη διαμόρφωση της βάσης δεδομένων ότι LC_MESSAGES (μηνύματα κειμένου) Μπορεί να χρησιμοποιηθεί Unicode, για παράδειγμα, ru_RU.UTF-8, στη συνέχεια κατά την εκκίνηση postgres σε ένα περιβάλλον όπου η τοπική ρύθμιση δεν είναι UTF-8, ας πούμε, σε ένα κενό περιβάλλον (εδώ βηματοδότης+pgsqlms(παφ) ξεκινά postgres), Οτι στο αρχείο καταγραφής αντί για γράμματα UTF-8 θα υπάρχουν ερωτηματικά. Οι προγραμματιστές της PostgreSQL δεν συμφώνησαν ποτέ τι να κάνουν σε αυτήν την περίπτωση. Κοστίζει, πρέπει να βάλεις LC_MESSAGES=en_US.UTF-8 κατά τη διαμόρφωση (δημιουργία) μιας παρουσίας DB.

• Εάν έχει οριστεί το wal_receiver_timeout (από προεπιλογή είναι 60 δευτερόλεπτα), τότε κατά τη δοκιμή του PostgreSQL-STOP στο master στα συμπλέγματα tuchanka3 και tuchanka4 Η αναπαραγωγή δεν επανασυνδέεται σε νέο κύριο. Η αναπαραγωγή εκεί είναι σύγχρονη, επομένως δεν σταματά μόνο ο slave, αλλά και ο νέος κύριος. Λαμβάνεται ορίζοντας wal_receiver_timeout=0 κατά τη διαμόρφωση του PostgreSQL.

• Περιστασιακά παρατηρούσα την αντιγραφή PostgreSQL να κρέμεται στη δοκιμή ForkBomb (υπερχείλιση μνήμης). Μετά το ForkBomb, μερικές φορές οι σκλάβοι ενδέχεται να μην επανασυνδεθούν με τον νέο κύριο. Το έχω δει μόνο στα συμπλέγματα tuchanka3 και tuchanka4, όπου λόγω του ότι η αναπαραγωγή είναι σύγχρονη, ο κύριος κρεμάστηκε. Το πρόβλημα εξαφανίστηκε από μόνο του, μετά από αρκετό καιρό (περίπου δύο ώρες). Απαιτείται περισσότερη έρευνα για να διορθωθεί αυτό. Τα συμπτώματα είναι παρόμοια με το προηγούμενο σφάλμα, το οποίο προκαλείται από διαφορετική αιτία, αλλά με τις ίδιες συνέπειες.

Φωτογραφία Krogan που λαμβάνεται από αποκλίνουσα Τέχνης με την άδεια του συγγραφέα:

Πηγή: www.habr.com