Σήμερα, η υπηρεσία Bitrix24 δεν έχει εκατοντάδες gigabit κίνηση, ούτε έχει τεράστιο στόλο διακομιστών (αν και, φυσικά, υπάρχουν αρκετοί ήδη υπάρχοντες). Αλλά για πολλούς πελάτες είναι το κύριο εργαλείο για να εργαστούν στην εταιρεία· είναι μια πραγματική εφαρμογή κρίσιμης σημασίας για τις επιχειρήσεις. Επομένως, δεν υπάρχει τρόπος να πέσεις. Τι θα γινόταν αν η συντριβή συνέβη, αλλά η υπηρεσία «ανάκαμψε» τόσο γρήγορα που κανείς δεν παρατήρησε τίποτα; Και πώς είναι δυνατόν να εφαρμοστεί failover χωρίς να χαθεί η ποιότητα της εργασίας και ο αριθμός των πελατών; Ο Alexander Demidov, διευθυντής υπηρεσιών cloud στο Bitrix24, μίλησε για το ιστολόγιό μας για το πώς έχει εξελιχθεί το σύστημα κρατήσεων τα 7 χρόνια ύπαρξης του προϊόντος.
«Ξεκινήσαμε το Bitrix24 ως SaaS πριν από 7 χρόνια. Η κύρια δυσκολία ήταν πιθανώς η ακόλουθη: πριν κυκλοφορήσει δημόσια ως SaaS, αυτό το προϊόν υπήρχε απλώς σε μορφή κουτιού λύσης. Οι πελάτες το αγόρασαν από εμάς, το φιλοξενούσαν στους διακομιστές τους, δημιούργησαν μια εταιρική πύλη - μια γενική λύση για την επικοινωνία των εργαζομένων, την αποθήκευση αρχείων, τη διαχείριση εργασιών, το CRM, αυτό είναι όλο. Και μέχρι το 2012, αποφασίσαμε ότι θέλαμε να το λανσάρουμε ως SaaS, διαχειρίζοντάς το μόνοι μας, διασφαλίζοντας ανοχή και αξιοπιστία σε σφάλματα. Αποκτήσαμε εμπειρία στην πορεία, γιατί μέχρι τότε απλά δεν την είχαμε - ήμασταν μόνο κατασκευαστές λογισμικού, όχι πάροχοι υπηρεσιών.
Κατά την εκκίνηση της υπηρεσίας, καταλάβαμε ότι το πιο σημαντικό πράγμα είναι να διασφαλίσουμε την ανοχή σφαλμάτων, την αξιοπιστία και τη συνεχή διαθεσιμότητα της υπηρεσίας, γιατί αν έχετε έναν απλό συνηθισμένο ιστότοπο, ένα κατάστημα, για παράδειγμα, και πέφτει πάνω σας και κάθεται εκεί για μια ώρα, μόνο εσείς υποφέρετε, χάνετε παραγγελίες, χάνετε πελάτες, αλλά για τον ίδιο τον πελάτη σας, αυτό δεν είναι πολύ κρίσιμο για αυτόν. Στενοχωρήθηκε βέβαια, αλλά πήγε και το αγόρασε σε άλλο site. Και αν πρόκειται για μια εφαρμογή στην οποία είναι δεμένη όλη η δουλειά μέσα στην εταιρεία, οι επικοινωνίες, οι αποφάσεις, τότε το πιο σημαντικό είναι να κερδίσεις την εμπιστοσύνη των χρηστών, δηλαδή να μην τους απογοητεύσεις και να μην πέσουν. Επειδή όλες οι εργασίες μπορούν να σταματήσουν αν κάτι μέσα δεν λειτουργεί.
Bitrix.24 ως SaaS
Συγκεντρώσαμε το πρώτο πρωτότυπο ένα χρόνο πριν από τη δημόσια κυκλοφορία, το 2011. Το συναρμολογήσαμε σε περίπου μια εβδομάδα, το κοιτάξαμε, το περιστρέψαμε - λειτουργούσε ακόμη και. Δηλαδή, θα μπορούσατε να μπείτε στη φόρμα, να εισαγάγετε το όνομα της πύλης εκεί, να ανοίξει μια νέα πύλη και να δημιουργηθεί μια βάση χρηστών. Το εξετάσαμε, αξιολογήσαμε το προϊόν κατ' αρχήν, το καταργήσαμε και συνεχίσαμε να το τελειοποιούμε για έναν ολόκληρο χρόνο. Επειδή είχαμε ένα μεγάλο καθήκον: δεν θέλαμε να δημιουργήσουμε δύο διαφορετικές βάσεις κώδικα, δεν θέλαμε να υποστηρίξουμε ένα ξεχωριστό συσκευασμένο προϊόν, ξεχωριστές λύσεις cloud - θέλαμε να τα κάνουμε όλα μέσα σε έναν κώδικα.
Μια τυπική διαδικτυακή εφαρμογή εκείνη την εποχή ήταν ένας διακομιστής στον οποίο εκτελείται κάποιος κώδικας PHP, μια βάση δεδομένων mysql, ανεβαίνουν αρχεία, έγγραφα, φωτογραφίες τοποθετούνται στο φάκελο μεταφόρτωσης - καλά, όλα λειτουργούν. Δυστυχώς, είναι αδύνατο να ξεκινήσει μια εξαιρετικά σταθερή υπηρεσία Ιστού χρησιμοποιώντας αυτήν. Εκεί, η κατανεμημένη κρυφή μνήμη δεν υποστηρίζεται, η αναπαραγωγή της βάσης δεδομένων δεν υποστηρίζεται.
Διατυπώσαμε τις απαιτήσεις: αυτή είναι η δυνατότητα να βρίσκεται σε διαφορετικές τοποθεσίες, να υποστηρίζει την αναπαραγωγή και ιδανικά να βρίσκεται σε διαφορετικά γεωγραφικά κατανεμημένα κέντρα δεδομένων. Διαχωρίστε τη λογική του προϊόντος και, στην πραγματικότητα, την αποθήκευση δεδομένων. Να είναι σε θέση να κλιμακώνεται δυναμικά ανάλογα με το φορτίο και να ανέχεται πλήρως τη στατική. Από αυτές τις εκτιμήσεις, μάλιστα, προέκυψαν οι απαιτήσεις για το προϊόν, τις οποίες βελτιώσαμε κατά τη διάρκεια του έτους. Σε αυτό το διάστημα, στην πλατφόρμα, η οποία αποδείχθηκε ενιαία - για λύσεις σε κουτί, για τη δική μας υπηρεσία - κάναμε υποστήριξη για εκείνα τα πράγματα που χρειαζόμασταν. Υποστήριξη για αναπαραγωγή mysql στο επίπεδο του ίδιου του προϊόντος: δηλαδή, ο προγραμματιστής που γράφει τον κώδικα δεν σκέφτεται πώς θα διανεμηθούν τα αιτήματά του, χρησιμοποιεί το api μας και γνωρίζουμε πώς να διανέμουμε σωστά τα αιτήματα εγγραφής και ανάγνωσης μεταξύ των κύριων και σκλάβοι.
Έχουμε υποστηρίξει σε επίπεδο προϊόντος για διάφορους χώρους αποθήκευσης αντικειμένων cloud: google storage, amazon s3, καθώς και υποστήριξη για open stack swift. Επομένως, αυτό ήταν βολικό τόσο για εμάς ως υπηρεσία όσο και για τους προγραμματιστές που εργάζονται με μια συσκευασμένη λύση: εάν χρησιμοποιούν απλώς το API μας για εργασία, δεν σκέφτονται πού θα αποθηκευτεί τελικά το αρχείο, τοπικά στο σύστημα αρχείων ή στην αποθήκευση αρχείου αντικειμένου.
Ως αποτέλεσμα, αποφασίσαμε αμέσως ότι θα κάνουμε κράτηση σε επίπεδο ολόκληρου του κέντρου δεδομένων. Το 2012, ξεκινήσαμε εξ ολοκλήρου στο Amazon AWS επειδή είχαμε ήδη εμπειρία με αυτήν την πλατφόρμα - ο δικός μας ιστότοπος φιλοξενήθηκε εκεί. Μας προσέλκυσε το γεγονός ότι σε κάθε περιοχή η Amazon έχει πολλές ζώνες διαθεσιμότητας - στην πραγματικότητα, (στην ορολογία τους) αρκετά κέντρα δεδομένων που είναι λίγο πολύ ανεξάρτητα μεταξύ τους και μας επιτρέπουν να κάνουμε κράτηση σε επίπεδο ολόκληρου κέντρου δεδομένων: Εάν αποτύχει ξαφνικά, οι βάσεις δεδομένων αναπαράγονται κύρια-κύρια, δημιουργούνται αντίγραφα ασφαλείας των διακομιστών εφαρμογών Ιστού και τα στατικά δεδομένα μετακινούνται στον χώρο αποθήκευσης αντικειμένων s3. Το φορτίο είναι ισορροπημένο - εκείνη την εποχή από το Amazon elb, αλλά λίγο αργότερα καταλήξαμε στους δικούς μας load balancers, γιατί χρειαζόμασταν πιο περίπλοκη λογική.
Αυτό που ήθελαν είναι αυτό που πήραν...
Όλα τα βασικά πράγματα που θέλαμε να διασφαλίσουμε - ανοχή σφαλμάτων των ίδιων των διακομιστών, εφαρμογές web, βάσεις δεδομένων - όλα λειτουργούσαν καλά. Το απλούστερο σενάριο: εάν μια από τις διαδικτυακές εφαρμογές μας αποτύχει, τότε όλα είναι απλά - απενεργοποιούνται από την εξισορρόπηση.
Ο εξισορροπητής (εκείνη την εποχή ήταν το elb της Amazon) σημείωσε μηχανήματα που ήταν εκτός λειτουργίας ως ανθυγιεινά και απενεργοποίησε την κατανομή φορτίου σε αυτά. Η αυτόματη κλιμάκωση της Amazon λειτούργησε: όταν αυξήθηκε το φορτίο, προστέθηκαν νέα μηχανήματα στην ομάδα αυτόματης κλιμάκωσης, το φορτίο διανεμήθηκε σε νέα μηχανήματα - όλα ήταν εντάξει. Με τους εξισορροπητές μας, η λογική είναι περίπου η ίδια: αν συμβεί κάτι στον διακομιστή εφαρμογών, αφαιρούμε αιτήματα από αυτόν, πετάμε αυτά τα μηχανήματα, ξεκινάμε νέα και συνεχίζουμε να εργαζόμαστε. Το σχήμα έχει αλλάξει λίγο με τα χρόνια, αλλά συνεχίζει να λειτουργεί: είναι απλό, κατανοητό και δεν υπάρχουν δυσκολίες με αυτό.
Εργαζόμαστε σε όλο τον κόσμο, οι αιχμές φόρτωσης πελατών είναι εντελώς διαφορετικές και, με φιλικό τρόπο, θα πρέπει να είμαστε σε θέση να εκτελούμε ορισμένες εργασίες σέρβις σε οποιοδήποτε στοιχείο του συστήματός μας ανά πάσα στιγμή - απαρατήρητο από τους πελάτες. Επομένως, έχουμε την ευκαιρία να απενεργοποιήσουμε τη βάση δεδομένων, ανακατανέμοντας το φορτίο σε ένα δεύτερο κέντρο δεδομένων.
Πώς λειτουργούν όλα; — Μεταφέρουμε την κυκλοφορία σε ένα λειτουργικό κέντρο δεδομένων - εάν συμβεί ατύχημα στο κέντρο δεδομένων, τότε εντελώς, εάν αυτή είναι η προγραμματισμένη εργασία μας με μία βάση δεδομένων, τότε μεταφέρουμε μέρος της κίνησης που εξυπηρετεί αυτούς τους πελάτες σε ένα δεύτερο κέντρο δεδομένων, αναστέλλοντας αναδιπλασιάζεται. Εάν χρειάζονται νέα μηχανήματα για εφαρμογές web επειδή έχει αυξηθεί το φορτίο στο δεύτερο κέντρο δεδομένων, θα ξεκινήσουν αυτόματα. Τελειώνουμε την εργασία, αποκαθίσταται η αναπαραγωγή και επιστρέφουμε ολόκληρο το φορτίο πίσω. Εάν πρέπει να αντικατοπτρίσουμε κάποια εργασία στο δεύτερο DC, για παράδειγμα, να εγκαταστήσουμε ενημερώσεις συστήματος ή να αλλάξουμε ρυθμίσεις στη δεύτερη βάση δεδομένων, τότε, γενικά, επαναλαμβάνουμε το ίδιο πράγμα, ακριβώς προς την άλλη κατεύθυνση. Και αν πρόκειται για ατύχημα, τότε τα κάνουμε όλα επιπόλαια: χρησιμοποιούμε τον μηχανισμό χειρισμού συμβάντων στο σύστημα παρακολούθησης. Εάν ενεργοποιηθούν αρκετοί έλεγχοι και η κατάσταση μεταβεί σε κρίσιμη, τότε εκτελούμε αυτόν τον χειριστή, έναν χειριστή που μπορεί να εκτελέσει αυτήν ή εκείνη τη λογική. Για κάθε βάση δεδομένων, καθορίζουμε ποιος διακομιστής είναι το failover για αυτήν και πού πρέπει να αλλάξει η κυκλοφορία εάν δεν είναι διαθέσιμη. Ιστορικά, χρησιμοποιούμε νάγιο ή μερικά από τα πιρούνια του με τη μια ή την άλλη μορφή. Κατ' αρχήν, παρόμοιοι μηχανισμοί υπάρχουν σχεδόν σε κάθε σύστημα παρακολούθησης· δεν χρησιμοποιούμε κάτι πιο περίπλοκο ακόμα, αλλά ίσως κάποια μέρα θα το κάνουμε. Τώρα η παρακολούθηση ενεργοποιείται από τη μη διαθεσιμότητα και έχει τη δυνατότητα να αλλάξει κάτι.
Έχουμε κρατήσει τα πάντα;
Έχουμε πολλούς πελάτες από τις ΗΠΑ, πολλούς πελάτες από την Ευρώπη, πολλούς πελάτες που είναι πιο κοντά στην Ανατολή - Ιαπωνία, Σιγκαπούρη και ούτω καθεξής. Φυσικά, ένα τεράστιο μερίδιο πελατών βρίσκεται στη Ρωσία. Δηλαδή, η δουλειά δεν είναι σε μία περιοχή. Οι χρήστες θέλουν γρήγορη απόκριση, υπάρχουν απαιτήσεις για συμμόρφωση με διάφορους τοπικούς νόμους και σε κάθε περιοχή δεσμεύουμε δύο κέντρα δεδομένων, καθώς και ορισμένες πρόσθετες υπηρεσίες, οι οποίες, πάλι, είναι βολικό να τοποθετηθούν σε μία περιοχή - για πελάτες που βρίσκονται σε αυτή η περιοχή λειτουργεί. REST χειριστές, διακομιστές εξουσιοδότησης, είναι λιγότερο κρίσιμοι για τη λειτουργία του πελάτη στο σύνολό του, μπορείτε να τους μεταβείτε με μια μικρή αποδεκτή καθυστέρηση, αλλά δεν θέλετε να ανακαλύψετε ξανά τον τροχό σχετικά με το πώς να τους παρακολουθείτε και τι να κάνετε με αυτούς. Ως εκ τούτου, προσπαθούμε να χρησιμοποιήσουμε τις υπάρχουσες λύσεις στο μέγιστο, αντί να αναπτύξουμε κάποιου είδους ικανότητα σε πρόσθετα προϊόντα. Και κάπου επιπόλαια χρησιμοποιούμε την εναλλαγή σε επίπεδο DNS και προσδιορίζουμε τη ζωντάνια της υπηρεσίας από το ίδιο DNS. Η Amazon διαθέτει μια υπηρεσία Route 53, αλλά δεν είναι απλώς ένα DNS στο οποίο μπορείτε να κάνετε καταχωρίσεις και αυτό είναι - είναι πολύ πιο ευέλικτο και βολικό. Μέσω αυτού μπορείτε να δημιουργήσετε γεωδιανεμημένες υπηρεσίες με γεωγραφικές τοποθεσίες, όταν το χρησιμοποιείτε για να προσδιορίσετε από πού προέρχεται ο πελάτης και να του δώσετε ορισμένες εγγραφές - με τη βοήθειά του μπορείτε να δημιουργήσετε αρχιτεκτονικές ανακατεύθυνσης. Οι ίδιοι έλεγχοι υγείας διαμορφώνονται στην ίδια τη Διαδρομή 53, ορίζετε τα τελικά σημεία που παρακολουθούνται, ορίζετε μετρήσεις, ορίζετε ποια πρωτόκολλα θα καθορίσουν τη «ζωντανότητα» της υπηρεσίας - tcp, http, https. ορίστε τη συχνότητα των ελέγχων που καθορίζουν εάν η υπηρεσία είναι ζωντανή ή όχι. Και στο ίδιο το DNS καθορίζετε τι θα είναι πρωτεύον, τι θα είναι δευτερεύον, πού να αλλάξετε εάν ενεργοποιηθεί ο έλεγχος υγείας στη διαδρομή 53. Όλα αυτά μπορούν να γίνουν με κάποια άλλα εργαλεία, αλλά γιατί είναι βολικό - το έχουμε ορίσει μια φορά και μετά μην το σκέφτεσαι καθόλου πώς κάνουμε ελέγχους, πώς αλλάζουμε: όλα λειτουργούν από μόνα τους.
Το πρώτο "αλλά": πώς και με τι να κάνω κράτηση για τη διαδρομή 53; Ποιος ξέρει, αν του συμβεί κάτι; Ευτυχώς, δεν πατήσαμε ποτέ αυτή τη γκανιότα, αλλά και πάλι, θα έχω μια ιστορία μπροστά για το γιατί πιστεύαμε ότι έπρεπε ακόμα να κάνουμε κράτηση. Εδώ απλώσαμε καλαμάκια για τον εαυτό μας εκ των προτέρων. Αρκετές φορές την ημέρα κάνουμε πλήρη εκφόρτωση όλων των ζωνών που έχουμε στη διαδρομή 53. Το API της Amazon σάς επιτρέπει να τα στέλνετε εύκολα σε JSON και έχουμε αρκετούς εφεδρικούς διακομιστές όπου το μετατρέπουμε, το ανεβάζουμε με τη μορφή ρυθμίσεων και έχουμε, χοντρικά, μια διαμόρφωση αντιγράφων ασφαλείας. Εάν συμβεί κάτι, μπορούμε να το αναπτύξουμε γρήγορα με μη αυτόματο τρόπο χωρίς να χάσουμε τα δεδομένα ρυθμίσεων DNS.
Δεύτερο "αλλά": Τι σε αυτήν την εικόνα δεν έχει ακόμη κρατηθεί; Ο ίδιος ο ισορροπιστής! Η κατανομή των πελατών μας ανά περιοχή είναι πολύ απλή. Έχουμε τους τομείς bitrix24.ru, bitrix24.com, .de - τώρα υπάρχουν 13 διαφορετικοί, που λειτουργούν σε διάφορες ζώνες. Καταλήξαμε στο εξής: κάθε περιοχή έχει τους δικούς της εξισορροπητές. Αυτό καθιστά πιο βολική τη διανομή σε περιοχές, ανάλογα με το πού βρίσκεται το φορτίο αιχμής στο δίκτυο. Αν πρόκειται για αστοχία σε επίπεδο μεμονωμένου εξισορροπητή, τότε απλά βγαίνει εκτός λειτουργίας και αφαιρείται από το dns. Εάν υπάρχει κάποιο πρόβλημα με μια ομάδα εξισορροπητών, τότε δημιουργούνται αντίγραφα ασφαλείας σε άλλους ιστότοπους και η εναλλαγή μεταξύ τους γίνεται χρησιμοποιώντας την ίδια διαδρομή53, επειδή λόγω του σύντομου TTL, η εναλλαγή πραγματοποιείται εντός 2, 3, 5 λεπτών το πολύ. .
Τρίτο "αλλά": Τι δεν έχει κρατηθεί ακόμα; S3, σωστά. Όταν τοποθετήσαμε τα αρχεία που αποθηκεύουμε για τους χρήστες στο s3, πιστεύαμε ειλικρινά ότι ήταν διαπεραστικό και δεν χρειαζόταν να κρατήσουμε τίποτα εκεί. Όμως η ιστορία δείχνει ότι τα πράγματα συμβαίνουν διαφορετικά. Σε γενικές γραμμές, η Amazon περιγράφει το S3 ως μια θεμελιώδη υπηρεσία, επειδή η ίδια η Amazon χρησιμοποιεί το S3 για να αποθηκεύει εικόνες μηχανών, ρυθμίσεις παραμέτρων, εικόνες AMI, στιγμιότυπα... Και αν το s3 κολλήσει, όπως συνέβη μια φορά σε αυτά τα 7 χρόνια, όσο χρησιμοποιούμε bitrix24, το ακολουθεί σαν θαυμαστής Υπάρχουν πολλά πράγματα που προκύπτουν – αδυναμία εκκίνησης εικονικών μηχανών, αποτυχία api και ούτω καθεξής.
Και το S3 μπορεί να πέσει - συνέβη μια φορά. Επομένως, καταλήξαμε στο εξής σχέδιο: πριν από μερικά χρόνια δεν υπήρχαν σοβαρές εγκαταστάσεις αποθήκευσης δημόσιων αντικειμένων στη Ρωσία και σκεφτήκαμε την επιλογή να κάνουμε κάτι δικό μας... Ευτυχώς, δεν ξεκινήσαμε να το κάνουμε αυτό, γιατί θα έχουμε εμβαθύνει στην τεχνογνωσία που δεν έχουμε, και πιθανότατα θα μπερδεύαμε. Τώρα το Mail.ru έχει αποθηκευτικό χώρο συμβατό με s3, το έχει η Yandex και πολλοί άλλοι πάροχοι τον έχουν. Τελικά καταλήξαμε στην ιδέα ότι θέλαμε να έχουμε, πρώτον, backup, και δεύτερον, τη δυνατότητα να δουλεύουμε με τοπικά αντίγραφα. Για την περιοχή της Ρωσίας συγκεκριμένα, χρησιμοποιούμε την υπηρεσία Mail.ru Hotbox, η οποία είναι συμβατή με API με s3. Δεν χρειαζόμασταν σημαντικές τροποποιήσεις στον κώδικα μέσα στην εφαρμογή και κάναμε τον εξής μηχανισμό: στο s3 υπάρχουν ενεργοποιητές που ενεργοποιούν τη δημιουργία/διαγραφή αντικειμένων, η Amazon έχει μια υπηρεσία που ονομάζεται Lambda - αυτή είναι μια εκκίνηση κώδικα χωρίς διακομιστή που θα εκτελεστεί ακριβώς όταν ενεργοποιηθούν ορισμένοι εναύσματα.
Το κάναμε πολύ απλά: αν ενεργοποιηθεί η σκανδάλη μας, εκτελούμε κώδικα που θα αντιγράψει το αντικείμενο στον χώρο αποθήκευσης Mail.ru. Για να ξεκινήσουμε πλήρως την εργασία με τοπικά αντίγραφα δεδομένων, χρειαζόμαστε επίσης αντίστροφο συγχρονισμό, έτσι ώστε οι πελάτες που ανήκουν στο ρωσικό τμήμα να μπορούν να εργαστούν με χώρο αποθήκευσης που είναι πιο κοντά τους. Η αλληλογραφία πρόκειται να ολοκληρώσει τις ενεργοποιήσεις στην αποθήκευσή της - θα είναι δυνατή η εκτέλεση αντίστροφου συγχρονισμού σε επίπεδο υποδομής, αλλά προς το παρόν το κάνουμε αυτό στο επίπεδο του δικού μας κώδικα. Αν δούμε ότι ένας πελάτης έχει δημοσιεύσει ένα αρχείο, τότε σε επίπεδο κώδικα τοποθετούμε το συμβάν σε μια ουρά, το επεξεργαζόμαστε και κάνουμε αντίστροφη αναπαραγωγή. Γιατί είναι κακό: αν κάνουμε κάποιο είδος εργασίας με τα αντικείμενά μας εκτός του προϊόντος μας, δηλαδή με κάποιο εξωτερικό τρόπο, δεν θα το λάβουμε υπόψη. Ως εκ τούτου, περιμένουμε μέχρι το τέλος, όταν εμφανιστούν triggers σε επίπεδο αποθήκευσης, έτσι ώστε από όπου και αν εκτελέσουμε τον κώδικα, το αντικείμενο που μας ήρθε να αντιγραφεί προς την άλλη κατεύθυνση.
Σε επίπεδο κώδικα, καταχωρούμε και τις δύο αποθήκες για κάθε πελάτη: η μία θεωρείται η κύρια, η άλλη θεωρείται εφεδρική. Αν όλα είναι καλά, εργαζόμαστε με τον αποθηκευτικό χώρο που είναι πιο κοντά μας: δηλαδή, οι πελάτες μας που βρίσκονται στο Amazon, εργάζονται με το S3 και όσοι εργάζονται στη Ρωσία, δουλεύουν με το Hotbox. Εάν ενεργοποιηθεί η σημαία, τότε θα πρέπει να συνδεθεί το failover και θα αλλάξουμε τους πελάτες σε άλλο χώρο αποθήκευσης. Μπορούμε να ελέγξουμε αυτό το πλαίσιο ανεξάρτητα ανά περιοχή και να τα αλλάξουμε εμπρός και πίσω. Δεν το έχουμε χρησιμοποιήσει ακόμα στην πράξη, αλλά έχουμε προβλέψει αυτόν τον μηχανισμό και πιστεύουμε ότι κάποια μέρα θα χρειαστούμε αυτόν τον διακόπτη και θα μας φανεί χρήσιμος. Αυτό έχει συμβεί ήδη μια φορά.
Α, και η Amazon έφυγε τρέχοντας...
Αυτός ο Απρίλιος σηματοδοτεί την επέτειο από την έναρξη του αποκλεισμού του Telegram στη Ρωσία. Ο πιο επηρεασμένος πάροχος που εμπίπτει σε αυτό είναι η Amazon. Και, δυστυχώς, οι ρωσικές εταιρείες που δούλευαν για ολόκληρο τον κόσμο υπέφεραν περισσότερο.
Εάν η εταιρεία είναι παγκόσμια και η Ρωσία είναι ένα πολύ μικρό τμήμα για αυτήν, 3-5% - καλά, με τον ένα ή τον άλλο τρόπο, μπορείτε να τους θυσιάσετε.
Εάν πρόκειται για μια καθαρά ρωσική εταιρεία - είμαι σίγουρος ότι πρέπει να βρίσκεται τοπικά - θα είναι απλά βολικό για τους ίδιους τους χρήστες, άνετο και θα υπάρχουν λιγότεροι κίνδυνοι.
Τι θα συμβεί αν πρόκειται για μια εταιρεία που δραστηριοποιείται παγκοσμίως και έχει περίπου ίσο αριθμό πελατών από τη Ρωσία και κάπου σε όλο τον κόσμο; Η συνδεσιμότητα των τμημάτων είναι σημαντική και πρέπει να συνεργάζονται μεταξύ τους με τον ένα ή τον άλλο τρόπο.
Στα τέλη Μαρτίου 2018, η Roskomnadzor έστειλε επιστολή στους μεγαλύτερους παρόχους δηλώνοντας ότι σχεδίαζαν να μπλοκάρουν πολλά εκατομμύρια IP της Amazon προκειμένου να μπλοκάρουν... τον αγγελιοφόρο Zello. Χάρη σε αυτούς τους ίδιους παρόχους - διέρρευσαν με επιτυχία την επιστολή σε όλους και έγινε κατανοητό ότι η σύνδεση με την Amazon θα μπορούσε να καταρρεύσει. Ήταν Παρασκευή, τρέξαμε πανικόβλητοι στους συναδέλφους μας από το servers.ru, με τα λόγια: "Φίλοι, χρειαζόμαστε αρκετούς διακομιστές που θα βρίσκονται όχι στη Ρωσία, όχι στο Amazon, αλλά, για παράδειγμα, κάπου στο Άμστερνταμ." για να μπορέσουμε τουλάχιστον με κάποιο τρόπο να εγκαταστήσουμε το δικό μας VPN και διακομιστή μεσολάβησης εκεί για ορισμένα τελικά σημεία που δεν μπορούμε να επηρεάσουμε με κανέναν τρόπο, για παράδειγμα endponts του ίδιου s3 - δεν μπορούμε να προσπαθήσουμε να δημιουργήσουμε μια νέα υπηρεσία και να λάβουμε μια διαφορετική ip, πρέπει ακόμα να φτάσετε εκεί. Μέσα σε λίγες μόνο μέρες, δημιουργήσαμε αυτούς τους διακομιστές, τους βάλαμε σε λειτουργία και, γενικά, προετοιμαστήκαμε για τη στιγμή που άρχισε ο αποκλεισμός. Είναι περίεργο που ο RKN, κοιτάζοντας τη φασαρία και τον πανικό, είπε: «Όχι, δεν θα μπλοκάρουμε τίποτα τώρα». (Αλλά αυτό ακριβώς μέχρι τη στιγμή που άρχισε να μπλοκάρεται το Telegram.) Έχοντας ρυθμίσει τις δυνατότητες παράκαμψης και συνειδητοποιώντας ότι ο αποκλεισμός δεν είχε εισαχθεί, δεν αρχίσαμε, ωστόσο, να λύνουμε το όλο θέμα. Ναι, για παν ενδεχόμενο.
Και το 2019 ζούμε ακόμα σε συνθήκες αποκλεισμού. Κοίταξα χθες το βράδυ: περίπου ένα εκατομμύριο IP εξακολουθούν να είναι μπλοκαρισμένα. Αλήθεια, το Amazon ξεμπλοκαρίστηκε σχεδόν εντελώς, στο απόγειό του έφτασε τις 20 εκατομμύρια διευθύνσεις... Γενικά, η πραγματικότητα είναι ότι μπορεί να μην υπάρχει συνοχή, καλή συνοχή. Ξαφνικά. Μπορεί να μην υπάρχει για τεχνικούς λόγους - πυρκαγιές, εκσκαφείς, όλα αυτά. Ή, όπως είδαμε, όχι εντελώς τεχνικό. Επομένως, κάποιος μεγάλος και μεγάλος, με τα δικά του AS, μπορεί πιθανώς να το διαχειριστεί αυτό με άλλους τρόπους - η απευθείας σύνδεση και άλλα πράγματα βρίσκονται ήδη στο επίπεδο l2. Αλλά σε μια απλή έκδοση, όπως η δική μας ή ακόμη μικρότερη, μπορείτε, για κάθε ενδεχόμενο, να έχετε πλεονασμό σε επίπεδο διακομιστών που έχουν δημιουργηθεί κάπου αλλού, ρυθμισμένους εκ των προτέρων vpn, διακομιστή μεσολάβησης, με τη δυνατότητα γρήγορης εναλλαγής της διαμόρφωσης σε αυτούς σε αυτά τα τμήματα που είναι κρίσιμα για τη συνδεσιμότητα σας. Αυτό μας βοήθησε περισσότερες από μία φορές, όταν άρχισε ο αποκλεισμός της Amazon· στη χειρότερη περίπτωση, επιτρέψαμε μόνο την κυκλοφορία S3 μέσω αυτών, αλλά σταδιακά όλα αυτά επιλύθηκαν.
Πώς να κρατήσω... έναν ολόκληρο πάροχο;
Αυτή τη στιγμή δεν έχουμε σενάριο σε περίπτωση που πέσει ολόκληρος ο Αμαζόνιος. Έχουμε ένα παρόμοιο σενάριο για τη Ρωσία. Στη Ρωσία, φιλοξενηθήκαμε από έναν πάροχο, από τον οποίο επιλέξαμε να έχουμε πολλούς ιστότοπους. Και πριν από ένα χρόνο αντιμετωπίσαμε ένα πρόβλημα: παρόλο που πρόκειται για δύο κέντρα δεδομένων, μπορεί να υπάρχουν ήδη προβλήματα στο επίπεδο της διαμόρφωσης δικτύου του παρόχου που θα εξακολουθήσουν να επηρεάζουν και τα δύο κέντρα δεδομένων. Και μπορεί να καταλήξουμε μη διαθέσιμοι και στους δύο ιστότοπους. Φυσικά αυτό έγινε. Καταλήξαμε να επανεξετάσουμε την αρχιτεκτονική μέσα. Δεν έχει αλλάξει πολύ, αλλά για τη Ρωσία έχουμε τώρα δύο ιστότοπους, οι οποίοι δεν προέρχονται από τον ίδιο πάροχο, αλλά από δύο διαφορετικούς. Εάν το ένα αποτύχει, μπορούμε να μεταβούμε στο άλλο.
Υποθετικά, για την Amazon εξετάζουμε τη δυνατότητα κράτησης σε επίπεδο άλλου παρόχου. ίσως η Google, ίσως κάποιος άλλος... Αλλά μέχρι στιγμής έχουμε παρατηρήσει στην πράξη ότι ενώ το Amazon έχει ατυχήματα σε επίπεδο μιας ζώνης διαθεσιμότητας, τα ατυχήματα σε επίπεδο ολόκληρης περιοχής είναι αρκετά σπάνια. Ως εκ τούτου, θεωρητικά έχουμε την ιδέα ότι μπορεί να κάνουμε μια κράτηση «Το Amazon δεν είναι Amazon», αλλά στην πράξη αυτό δεν ισχύει ακόμη.
Λίγα λόγια για τον αυτοματισμό
Είναι πάντα απαραίτητος ο αυτοματισμός; Εδώ είναι σκόπιμο να θυμηθούμε το φαινόμενο Dunning-Kruger. Στον άξονα «x» είναι η γνώση και η εμπειρία μας που αποκτούμε και στον άξονα «y» η εμπιστοσύνη στις πράξεις μας. Στην αρχή δεν ξέρουμε τίποτα και δεν είμαστε καθόλου σίγουροι. Τότε ξέρουμε λίγο και αποκτάμε μεγάλη αυτοπεποίθηση - αυτή είναι η λεγόμενη «αιχμή της βλακείας», που φαίνεται καλά από την εικόνα «άνοια και θάρρος». Μετά μάθαμε λίγα και είμαστε έτοιμοι να πάμε στη μάχη. Έπειτα πατάμε σε μερικά πολύ σοβαρά λάθη και βρισκόμαστε σε μια κοιλάδα απελπισίας, όταν φαίνεται να γνωρίζουμε κάτι, αλλά στην πραγματικότητα δεν ξέρουμε πολλά. Στη συνέχεια, καθώς αποκτούμε εμπειρία, αποκτούμε μεγαλύτερη αυτοπεποίθηση.
Η λογική μας σχετικά με διάφορους αυτόματους διακόπτες σε ορισμένα ατυχήματα περιγράφεται πολύ καλά σε αυτό το γράφημα. Ξεκινήσαμε - δεν ξέραμε πώς να κάνουμε τίποτα, σχεδόν όλη η δουλειά έγινε με το χέρι. Τότε συνειδητοποιήσαμε ότι μπορούσαμε να συνδέσουμε τον αυτοματισμό σε όλα και, όπως, να κοιμηθούμε ήσυχοι. Και ξαφνικά πατάμε σε ένα μέγα-σημαντικό: ενεργοποιείται ένα ψευδές θετικό και αλλάζουμε κίνηση πέρα δώθε όταν, με την καλή έννοια, δεν έπρεπε να το είχαμε κάνει αυτό. Κατά συνέπεια, η αναπαραγωγή καταρρέει ή κάτι άλλο - αυτή είναι η ίδια η κοιλάδα της απόγνωσης. Και τότε καταλαβαίνουμε ότι πρέπει να προσεγγίζουμε τα πάντα με σύνεση. Δηλαδή, είναι λογικό να βασιζόμαστε στον αυτοματισμό, προβλέποντας τη δυνατότητα ψευδών συναγερμών. Αλλά! αν οι συνέπειες μπορεί να είναι καταστροφικές, τότε καλύτερα να το αφήσουμε στη βάρδια, στους εφημερεύοντες μηχανικούς, οι οποίοι θα φροντίσουν και θα παρακολουθήσουν ότι υπάρχει όντως ατύχημα και θα κάνουν τις απαραίτητες ενέργειες χειροκίνητα...
Συμπέρασμα
Μέσα σε 7 χρόνια, φτάσαμε από το γεγονός ότι όταν έπεφτε κάτι, επικρατούσε πανικός-πανικός, στην κατανόηση ότι προβλήματα δεν υπάρχουν, υπάρχουν μόνο καθήκοντα, πρέπει - και μπορούν - να λυθούν. Όταν δημιουργείτε μια υπηρεσία, κοιτάξτε την από ψηλά, αξιολογήστε όλους τους κινδύνους που μπορεί να συμβούν. Εάν τα δείτε αμέσως, τότε προνοήστε για πλεονασμό εκ των προτέρων και τη δυνατότητα κατασκευής υποδομής με ανοχή σε σφάλματα, γιατί οποιοδήποτε σημείο μπορεί να αποτύχει και να οδηγήσει σε αλειτουργία της υπηρεσίας σίγουρα θα το κάνει. Και ακόμα κι αν σας φαίνεται ότι ορισμένα στοιχεία της υποδομής σίγουρα δεν θα αποτύχουν - όπως το ίδιο s3, έχετε κατά νου ότι μπορούν. Και τουλάχιστον θεωρητικά, να έχετε μια ιδέα για το τι θα κάνετε με αυτά αν συμβεί κάτι. Έχετε ένα σχέδιο διαχείρισης κινδύνου. Όταν σκέφτεστε να κάνετε τα πάντα αυτόματα ή χειροκίνητα, αξιολογήστε τους κινδύνους: τι θα συμβεί εάν ο αυτοματισμός αρχίσει να αλλάζει τα πάντα - δεν θα οδηγήσει αυτό σε μια ακόμη χειρότερη κατάσταση σε σύγκριση με ένα ατύχημα; Ίσως κάπου είναι απαραίτητο να χρησιμοποιηθεί ένας εύλογος συμβιβασμός μεταξύ της χρήσης του αυτοματισμού και της αντίδρασης του μηχανικού υπηρεσίας, ο οποίος θα αξιολογήσει την πραγματική εικόνα και θα καταλάβει αν κάτι πρέπει να αλλάξει επί τόπου ή «ναι, αλλά όχι τώρα».
Ένας λογικός συμβιβασμός μεταξύ τελειομανίας και πραγματικής προσπάθειας, χρόνου, χρήματος που μπορείτε να ξοδέψετε για το σχέδιο που θα έχετε τελικά.
Αυτό το κείμενο είναι μια ενημερωμένη και διευρυμένη έκδοση της έκθεσης του Alexander Demidov στο συνέδριο .
Πηγή: www.habr.com