Failover: η τελειομανία και η... τεμπελιά μας καταστρέφουν

Το καλοκαίρι, τόσο η αγοραστική δραστηριότητα όσο και η ένταση των αλλαγών στην υποδομή των διαδικτυακών έργων μειώνονται παραδοσιακά, μας λέει ο Captain Obvious. Απλά γιατί ακόμα και οι ειδικοί της πληροφορικής μερικές φορές πάνε διακοπές. Και ΚΟΤ επίσης. Είναι ακόμη πιο δύσκολο για όσους παραμένουν στη θέση τους, αλλά δεν είναι αυτό το θέμα τώρα: ίσως γι' αυτό το καλοκαίρι είναι η καλύτερη περίοδος για να σκεφτείτε σιγά σιγά το υπάρχον πρόγραμμα κρατήσεων και να καταρτίσετε ένα σχέδιο για τη βελτίωσή του. Και η εμπειρία του Yegor Andreev από Διεύθυνση Διοίκησης, για το οποίο μίλησε στο συνέδριο Ημέρα λειτουργίας.

Υπάρχουν πολλές παγίδες στις οποίες μπορείτε να πέσετε κατά τη δημιουργία αντιγράφων ασφαλείας τοποθεσιών. Και είναι απολύτως αδύνατο να πιαστείς σε αυτά. Και αυτό που μας καταστρέφει σε όλο αυτό, όπως και σε πολλά άλλα, είναι η τελειομανία και η... τεμπελιά. Προσπαθούμε να κάνουμε τα πάντα, τα πάντα, τα πάντα τέλεια, αλλά δεν χρειάζεται να το κάνουμε τέλεια! Χρειάζεται μόνο να κάνετε ορισμένα πράγματα, αλλά να τα κάνετε σωστά, να τα ολοκληρώσετε ώστε να λειτουργούν σωστά.

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

Failover: η τελειομανία και η... τεμπελιά μας καταστρέφουν

Πρώτη παγίδα: όταν κατασκευάζουμε μεγάλα, αξιόπιστα συστήματα και εμπλακούμε σε πλεονασμό, μειώνουμε τον αριθμό των ατυχημάτων. Αυτή είναι μια τρομερή παρανόηση. Όταν εμπλακούμε σε απολύσεις, είναι πιθανό να αυξήσουμε τον αριθμό των ατυχημάτων. Και αν κάνουμε τα πάντα σωστά, τότε συλλογικά θα μειώσουμε το χρόνο διακοπής λειτουργίας. Θα υπάρξουν περισσότερα ατυχήματα, αλλά θα συμβούν με χαμηλότερο κόστος. Τι είναι η κράτηση; - αυτό είναι μια επιπλοκή του συστήματος. Οποιαδήποτε επιπλοκή είναι κακή: έχουμε περισσότερα γρανάζια, περισσότερα γρανάζια, με μια λέξη, περισσότερα στοιχεία - και, επομένως, μεγαλύτερη πιθανότητα βλάβης. Και πραγματικά θα σπάσουν. Και θα σπάνε πιο συχνά. Ένα απλό παράδειγμα: ας πούμε ότι έχουμε έναν ιστότοπο με PHP και MySQL. Και πρέπει επειγόντως να κρατηθεί.

Shtosh (γ) Παίρνουμε τη δεύτερη τοποθεσία, χτίζουμε ένα πανομοιότυπο σύστημα... Η πολυπλοκότητα γίνεται διπλάσια - έχουμε δύο οντότητες. Διαθέτουμε επίσης μια συγκεκριμένη λογική για τη μεταφορά δεδομένων από έναν ιστότοπο σε έναν άλλο - δηλαδή, αναπαραγωγή δεδομένων, αντιγραφή στατικών δεδομένων κ.λπ. Έτσι, η λογική αντιγραφής είναι συνήθως πολύ περίπλοκη, και ως εκ τούτου, η συνολική πολυπλοκότητα του συστήματος μπορεί να είναι όχι 2, αλλά 3, 5, 10 φορές μεγαλύτερη.

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

Πώς μπορείς να το πολεμήσεις αυτό; Πρέπει να σταματήσουμε να λέμε ψέματα στους εαυτούς μας, να σταματήσουμε να κολακεύουμε τον εαυτό μας ότι πρόκειται να κατασκευάσουμε ένα διαστημόπλοιο εδώ τώρα, αλλά να κατανοήσουμε επαρκώς πόσο καιρό μπορεί να διαρκέσει το έργο. Και για αυτόν τον μέγιστο χρόνο, θα επιλέξουμε ποιες μεθόδους θα χρησιμοποιήσουμε πραγματικά για να αυξήσουμε την αξιοπιστία του συστήματός μας.

Failover: η τελειομανία και η... τεμπελιά μας καταστρέφουν

Ήρθε η ώρα για “ιστορίες από το w”... από τη ζωή, φυσικά.

Παράδειγμα νούμερο ένα

Φανταστείτε έναν ιστότοπο επαγγελματικής κάρτας για το εργοστάσιο έλασης σωλήνων Νο. 1 στην πόλη του Ν. Λέει με τεράστια γράμματα - Εργοστάσιο έλασης ΣΩΛΗΝΩΝ Νο. 1. Ακριβώς από κάτω είναι το σύνθημα: "Οι σωλήνες μας είναι οι πιο στρογγυλοί σωλήνες στο Ν." Και παρακάτω είναι ο αριθμός τηλεφώνου του CEO και το όνομά του. Κατανοούμε ότι πρέπει να κάνετε κράτηση - αυτό είναι πολύ σημαντικό! Ας αρχίσουμε να καταλαβαίνουμε από τι αποτελείται. Html-statics - δηλαδή, μερικές φωτογραφίες όπου ο γενικός διευθυντής, στην πραγματικότητα, συζητά για κάποιο είδος επόμενης συμφωνίας στο τραπέζι στο λουτρό με τη σύντροφό του. Αρχίζουμε να σκεφτόμαστε το χρόνο διακοπής. Μου έρχεται στο μυαλό: πρέπει να ξαπλώσεις εκεί για πέντε λεπτά, όχι περισσότερο. Και τότε τίθεται το ερώτημα: πόσες πωλήσεις υπήρξαν γενικά από αυτό το site μας; Πόσο-πόσο; Τι σημαίνει «μηδέν»; Και αυτό σημαίνει: γιατί ο στρατηγός έκανε και τις τέσσερις συναλλαγές πέρυσι στο ίδιο τραπέζι, με τα ίδια άτομα με τα οποία πάνε στο λουτρό και κάθονται στο τραπέζι. Και καταλαβαίνουμε ότι ακόμα κι αν ο ιστότοπος καθίσει για μια μέρα, δεν θα συμβεί τίποτα τρομερό.

Με βάση τις εισαγωγικές πληροφορίες, υπάρχει μια μέρα για να αναφερθεί αυτή η ιστορία. Ας αρχίσουμε να σκεφτόμαστε ένα πρόγραμμα απολύσεων. Και επιλέγουμε το ιδανικότερο σχήμα πλεονασμού για αυτό το παράδειγμα: δεν χρησιμοποιούμε πλεονασμό. Όλο αυτό το θέμα μπορεί να το σηκώσει οποιοσδήποτε διαχειριστής σε μισή ώρα με διαλείμματα καπνού. Εγκαταστήστε έναν διακομιστή ιστού, προσθέστε αρχεία - αυτό είναι. Θα δουλέψει. Δεν χρειάζεται να παρακολουθείτε τίποτα, δεν χρειάζεται να δίνετε ιδιαίτερη σημασία σε τίποτα. Δηλαδή, το συμπέρασμα από το παράδειγμα νούμερο ένα είναι αρκετά προφανές: οι υπηρεσίες που δεν χρειάζεται να γίνουν κράτηση δεν χρειάζεται να γίνουν κράτηση.

Failover: η τελειομανία και η... τεμπελιά μας καταστρέφουν

Παράδειγμα νούμερο δύο

Εταιρικό ιστολόγιο: ειδικά εκπαιδευμένοι άνθρωποι γράφουν ειδήσεις εκεί, πήραμε μέρος σε μια τέτοια έκθεση, αλλά κυκλοφορήσαμε ένα άλλο νέο προϊόν κ.ο.κ. Ας πούμε ότι αυτή είναι τυπική PHP με WordPress, μια μικρή βάση δεδομένων και λίγο στατικό. Φυσικά, μου έρχεται ξανά στο μυαλό ότι σε καμία περίπτωση δεν πρέπει να ξαπλώνετε - "όχι περισσότερο από πέντε λεπτά!" Αυτό είναι όλο. Αλλά ας σκεφτούμε περαιτέρω. Τι κάνει αυτό το blog; Οι άνθρωποι έρχονται εκεί από το Yandex, από την Google με βάση κάποια ερωτήματα, οργανικά. Εξαιρετική. Οι πωλήσεις έχουν σχέση με αυτό; Epiphany: όχι πραγματικά. Η διαφημιστική κίνηση πηγαίνει στον κύριο ιστότοπο, ο οποίος βρίσκεται σε διαφορετικό μηχάνημα. Ας αρχίσουμε να σκεφτόμαστε ένα πρόγραμμα κρατήσεων. Με την καλή έννοια, πρέπει να αυξηθεί σε μερικές ώρες και θα ήταν ωραίο να προετοιμαστείτε για αυτό. Θα ήταν λογικό να πάρετε ένα μηχάνημα από άλλο κέντρο δεδομένων, να βάλετε το περιβάλλον πάνω του, δηλαδή έναν διακομιστή web, PHP, WordPress, MySQL και να το αφήσετε εκεί. Τη στιγμή που καταλαβαίνουμε ότι όλα έχουν χαλάσει, πρέπει να κάνουμε δύο πράγματα - να ανοίξουμε τη χωματερή mysql 50 μέτρα, θα πετάξει εκεί σε ένα λεπτό και να ανοίξουμε έναν ορισμένο αριθμό εικόνων από το αντίγραφο ασφαλείας εκεί. Αυτό επίσης δεν υπάρχει για έναν Θεό ξέρει πόσο καιρό. Έτσι, σε μισή ώρα το όλο πράγμα ανεβαίνει. Χωρίς αναπαραγωγή, ή Θεέ μου συγχώρεσέ με, αυτόματο failover. Συμπέρασμα: αυτό που μπορούμε να δημιουργήσουμε γρήγορα από ένα αντίγραφο ασφαλείας δεν χρειάζεται να δημιουργηθεί αντίγραφο ασφαλείας.

Failover: η τελειομανία και η... τεμπελιά μας καταστρέφουν

Παράδειγμα νούμερο τρία, πιο περίπλοκο

Ηλεκτρονικό κατάστημα. Το PhP με ανοιχτή καρδιά είναι λίγο τροποποιημένο, το mysql με σταθερή βάση. Αρκετά στατικά (άλλωστε, το ηλεκτρονικό κατάστημα έχει όμορφες εικόνες HD και όλα αυτά), Redis για τη συνεδρία και Elasticsearch για αναζήτηση. Αρχίζουμε να σκεφτόμαστε το χρόνο διακοπής. Και εδώ, βέβαια, είναι προφανές ότι ένα ηλεκτρονικό κατάστημα δεν μπορεί να ξαπλώσει ανώδυνα για μια μέρα. Άλλωστε, όσο περισσότερο μένει, τόσο περισσότερα χρήματα χάνουμε. Αξίζει να επιταχύνουμε. Πόσο? Νομίζω ότι αν ξαπλώσουμε μια ώρα δεν θα τρελαθεί κανείς. Ναι, κάτι θα χάσουμε, αλλά αν αρχίσουμε να δουλεύουμε σκληρά, θα χειροτερέψει. Καθορίζουμε ένα πρόγραμμα επιτρεπόμενου χρόνου διακοπής ανά ώρα.

Πώς μπορεί να κρατηθεί όλο αυτό; Χρειάζεστε ένα αυτοκίνητο σε κάθε περίπτωση: μια ώρα χρόνου είναι αρκετά μικρή. Mysql: εδώ χρειαζόμαστε ήδη αναπαραγωγή, ζωντανή αναπαραγωγή, γιατί σε μια ώρα πιθανότατα δεν θα προστεθούν 100 GB στο dump. Στατικά, εικόνες: και πάλι, σε μια ώρα 500 GB μπορεί να μην έχουν χρόνο για προσθήκη. Επομένως, είναι καλύτερο να αντιγράψετε τις εικόνες αμέσως. Redis: εδώ γίνονται ενδιαφέροντα τα πράγματα. Στο Redis, οι συνεδρίες αποθηκεύονται - δεν μπορούμε απλώς να το πάρουμε και να το θάψουμε. Γιατί αυτό δεν θα είναι πολύ καλό: όλοι οι χρήστες θα αποσυνδεθούν, τα καλάθια τους θα αδειάσουν και ούτω καθεξής. Οι άνθρωποι θα αναγκαστούν να εισαγάγουν ξανά το όνομα χρήστη και τον κωδικό πρόσβασής τους και πολλά άτομα ενδέχεται να απομακρυνθούν και να μην ολοκληρώσουν την αγορά. Και πάλι, οι μετατροπές θα μειωθούν. Από την άλλη πλευρά, το Redis είναι άμεσα ενημερωμένο, με τους τελευταίους συνδεδεμένους χρήστες πιθανότατα να μην χρειάζονται ούτε. Και ένας καλός συμβιβασμός είναι να πάρετε το Redis και να το επαναφέρετε από ένα αντίγραφο ασφαλείας από χθες, ή, αν το κάνετε κάθε ώρα, από μια ώρα πριν. Ευτυχώς, η επαναφορά του από ένα αντίγραφο ασφαλείας σημαίνει αντιγραφή ενός αρχείου. Και η πιο ενδιαφέρουσα ιστορία είναι το Elasticsearch. Ποιος έχει πάρει ποτέ την αναπαραγωγή MySQL; Ποιος έχει βρει ποτέ την αναπαραγωγή του Elasticsearch; Και για ποιον λειτούργησε κανονικά μετά; Αυτό που εννοώ είναι ότι βλέπουμε μια συγκεκριμένη οντότητα στο σύστημά μας. Φαίνεται να είναι χρήσιμο - αλλά είναι πολύπλοκο.
Πολύπλοκο με την έννοια ότι οι συνάδελφοί μας μηχανικοί δεν έχουν εμπειρία να δουλέψουν μαζί του. Ή υπάρχει μια αρνητική εμπειρία. Ή καταλαβαίνουμε ότι αυτή είναι ακόμα μια αρκετά νέα τεχνολογία με αποχρώσεις ή ωμότητα. Σκεφτόμαστε... Γαμώτο, το ελαστικό είναι και υγιεινό, θέλει και πολύ καιρό να το επαναφέρω από εφεδρικό, τι να κάνω; Καταλαβαίνουμε ότι το ελαστικό στην περίπτωσή μας χρησιμοποιείται για αναζήτηση. Πώς πουλάει το ηλεκτρονικό μας κατάστημα; Πηγαίνουμε σε εμπόρους και ρωτάμε από πού προέρχονται οι άνθρωποι. Απαντούν: "Το 90% από το Yandex Market έρχεται απευθείας στην κάρτα προϊόντος." Και είτε το αγοράζουν είτε όχι. Επομένως, η αναζήτηση χρειάζεται από το 10% των χρηστών. Και η διατήρηση ελαστικής αναπαραγωγής, ειδικά μεταξύ διαφορετικών κέντρων δεδομένων σε διαφορετικές ζώνες, έχει πραγματικά πολλές αποχρώσεις. Ποια έξοδο; Παίρνουμε λάστιχο από μια δεσμευμένη τοποθεσία και δεν κάνουμε τίποτα με αυτό. Εάν το θέμα καθυστερήσει, μπορεί να το θέσουμε κάποια μέρα, αλλά αυτό δεν είναι σίγουρο. Στην πραγματικότητα, το συμπέρασμα είναι το ίδιο, συν ή πλην: εμείς, πάλι, δεν επιφυλάσσουμε υπηρεσίες που δεν επηρεάζουν τα χρήματα. Για να είναι πιο απλό το διάγραμμα.

Failover: η τελειομανία και η... τεμπελιά μας καταστρέφουν

Παράδειγμα νούμερο τέσσερα, ακόμα πιο δύσκολο

Integrator: πώληση λουλουδιών, κλήση ταξί, πώληση αγαθών, γενικά, οτιδήποτε. Ένα σοβαρό πράγμα που λειτουργεί 24/7 για μεγάλο αριθμό χρηστών. Με μια ολοκληρωμένη ενδιαφέρουσα στοίβα, όπου υπάρχουν ενδιαφέρουσες βάσεις, λύσεις, υψηλό φορτίο και το πιο σημαντικό, πονάει να ξαπλώνεις για περισσότερα από 5 λεπτά. Όχι μόνο και όχι τόσο επειδή οι άνθρωποι δεν θα αγοράσουν, αλλά επειδή οι άνθρωποι θα δουν ότι αυτό το πράγμα δεν λειτουργεί, θα εκνευριστούν και μπορεί να μην επιστρέψουν καθόλου.

ΕΝΤΑΞΕΙ. Πέντε λεπτά. Τι θα κάνουμε για αυτό; Σε αυτήν την περίπτωση, εμείς, όπως οι ενήλικες, χρησιμοποιούμε όλα τα χρήματα για να δημιουργήσουμε έναν πραγματικό ιστότοπο δημιουργίας αντιγράφων ασφαλείας, με αναπαραγωγή των πάντων, και ίσως ακόμη και να αυτοματοποιήσουμε τη μετάβαση σε αυτόν τον ιστότοπο όσο το δυνατόν περισσότερο. Και επιπλέον αυτού, πρέπει να θυμάστε να κάνετε ένα σημαντικό πράγμα: στην πραγματικότητα, να γράψετε τους κανονισμούς μεταγωγής. Οι κανονισμοί, ακόμα κι αν τα έχετε όλα αυτοματοποιημένα, μπορεί να είναι πολύ απλοί. Από τη σειρά "τρέξτε αυτό και ένα τέτοιο σενάριο", "κάντε κλικ σε ένα τέτοιο πλαίσιο ελέγχου στη διαδρομή 53" και ούτω καθεξής - αλλά αυτό πρέπει να είναι κάποιο είδος ακριβούς λίστας ενεργειών.

Και όλα φαίνονται ξεκάθαρα. Η εναλλαγή αναπαραγωγής είναι μια ασήμαντη εργασία, διαφορετικά θα αλλάξει μόνη της. Η επανεγγραφή ενός ονόματος τομέα στο DNS είναι από την ίδια σειρά. Το πρόβλημα είναι ότι όταν ένα τέτοιο έργο αποτυγχάνει, αρχίζει ο πανικός, και ακόμη και οι πιο δυνατοί, γενειοφόροι διαχειριστές μπορεί να είναι επιρρεπείς σε αυτό. Χωρίς σαφείς οδηγίες «άνοιξε το τερματικό, έλα εδώ, η διεύθυνση του διακομιστή μας εξακολουθεί να είναι αυτή», είναι δύσκολο να τηρηθεί το χρονικό όριο των 5 λεπτών που έχει δοθεί για την ανάνηψη. Λοιπόν, συν, όταν χρησιμοποιούμε αυτούς τους κανονισμούς, είναι εύκολο να καταγράψουμε κάποιες αλλαγές στην υποδομή, για παράδειγμα, και να αλλάξουμε τους κανονισμούς ανάλογα.
Λοιπόν, εάν το σύστημα κρατήσεων είναι πολύ περίπλοκο και κάποια στιγμή κάναμε λάθος, τότε μπορούμε να καταστρέψουμε τον εφεδρικό ιστότοπό μας και επιπλέον να μετατρέψουμε τα δεδομένα σε κολοκύθα και στους δύο ιστότοπους - αυτό θα είναι εντελώς λυπηρό.

Failover: η τελειομανία και η... τεμπελιά μας καταστρέφουν

Παράδειγμα νούμερο πέντε, πλήρες σκληροπυρηνικό

Μια διεθνής υπηρεσία με εκατοντάδες εκατομμύρια χρήστες σε όλο τον κόσμο. Όλες οι ζώνες ώρας υπάρχουν, υψηλό φορτίο στη μέγιστη ταχύτητα, δεν μπορείτε να ξαπλώσετε καθόλου. Ένα λεπτό - και θα είναι λυπηρό. Τι να κάνω? Κάντε κράτηση, ξανά, σύμφωνα με το πλήρες πρόγραμμα. Κάναμε όλα όσα μίλησα στο προηγούμενο παράδειγμα, και λίγο περισσότερο. Ένας ιδανικός κόσμος και η υποδομή μας είναι σύμφωνα με όλες τις έννοιες του IaaC devop. Δηλαδή, όλα είναι in git, και απλά πατάς το κουμπί.

Τι ΛΕΙΠΕΙ? Ένα - ασκήσεις. Είναι αδύνατο χωρίς αυτούς. Φαίνεται ότι όλα είναι τέλεια μαζί μας, γενικά τα έχουμε όλα υπό έλεγχο. Πατάμε το κουμπί, όλα γίνονται. Ακόμα κι αν αυτό είναι έτσι - και καταλαβαίνουμε ότι δεν συμβαίνει έτσι - το σύστημά μας αλληλεπιδρά με κάποια άλλα συστήματα. Για παράδειγμα, αυτό είναι dns από τη διαδρομή 53, αποθήκευση s3, ενσωμάτωση με κάποιο api. Δεν θα είμαστε σε θέση να προβλέψουμε τα πάντα σε αυτό το κερδοσκοπικό πείραμα. Και μέχρι να τραβήξουμε πραγματικά τον διακόπτη, δεν θα ξέρουμε αν θα λειτουργήσει ή όχι.

Failover: η τελειομανία και η... τεμπελιά μας καταστρέφουν

Μάλλον αυτό είναι όλο. Μην είστε τεμπέληδες και μην το παρακάνετε. Και μπορεί ο χρόνος λειτουργίας να είναι μαζί σας!

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο