Ο σύγχρονος ιστός είναι σχεδόν αδιανόητος χωρίς περιεχόμενο πολυμέσων: σχεδόν κάθε γιαγιά έχει smartphone, όλοι είναι στα κοινωνικά δίκτυα και ο χρόνος διακοπής της συντήρησης είναι δαπανηρός για τις εταιρείες. Εδώ είναι μια απομαγνητοφώνηση της ιστορίας της εταιρείας για το πώς οργάνωσε την παράδοση των φωτογραφιών χρησιμοποιώντας μια λύση υλικού, ποια προβλήματα απόδοσης αντιμετώπισε στη διαδικασία, τι τα προκάλεσε και πώς αυτά τα προβλήματα επιλύθηκαν χρησιμοποιώντας μια λύση λογισμικού βασισμένη στο Nginx, διασφαλίζοντας παράλληλα ανοχή σφαλμάτων σε όλα τα επίπεδα (). Ευχαριστούμε τους συγγραφείς της ιστορίας του Oleg Efimova και Alexandra Dymova, που μοιράστηκαν την εμπειρία τους στο συνέδριο .
— Ας ξεκινήσουμε με μια μικρή εισαγωγή σχετικά με τον τρόπο αποθήκευσης και αποθήκευσης φωτογραφιών. Έχουμε ένα επίπεδο όπου τα αποθηκεύουμε και ένα στρώμα όπου αποθηκεύουμε τις φωτογραφίες. Ταυτόχρονα, εάν θέλουμε να επιτύχουμε υψηλό ποσοστό κόλπων και να μειώσουμε το φόρτο στον χώρο αποθήκευσης, είναι σημαντικό για εμάς κάθε φωτογραφία ενός μεμονωμένου χρήστη να βρίσκεται σε έναν διακομιστή προσωρινής αποθήκευσης. Διαφορετικά, θα έπρεπε να εγκαταστήσουμε τόσες φορές περισσότερους δίσκους όσες έχουμε περισσότερους διακομιστές. Το ποσοστό κόλπων μας είναι γύρω στο 99%, δηλαδή μειώνουμε το φόρτο στον αποθηκευτικό μας χώρο κατά 100 φορές και για να το κάνουμε αυτό, πριν από 10 χρόνια, όταν κατασκευάζονταν όλα αυτά, είχαμε 50 διακομιστές. Αντίστοιχα, για να εξυπηρετήσουμε αυτές τις φωτογραφίες χρειαζόμασταν ουσιαστικά 50 εξωτερικούς τομείς που εξυπηρετούν αυτοί οι διακομιστές.
Φυσικά, προέκυψε αμέσως το ερώτημα: εάν ένας από τους διακομιστές μας πέσει και γίνει μη διαθέσιμος, ποιο μέρος της επισκεψιμότητας χάνουμε; Κοιτάξαμε τι κυκλοφορούσε στην αγορά και αποφασίσαμε να αγοράσουμε ένα κομμάτι υλικού για να μας λύσει όλα τα προβλήματα. Η επιλογή έπεσε στη λύση της εταιρείας δικτύου F5 (η οποία, παρεμπιπτόντως, αγόρασε πρόσφατα την NGINX, Inc): BIG-IP Local Traffic Manager.
Τι κάνει αυτό το κομμάτι υλικού (LTM): είναι ένας σιδερένιος δρομολογητής που κάνει πλεονασμό σιδήρου στις εξωτερικές του θύρες και σας επιτρέπει να δρομολογείτε την κυκλοφορία με βάση την τοπολογία του δικτύου, σε ορισμένες ρυθμίσεις και κάνει ελέγχους υγείας. Ήταν σημαντικό για εμάς ότι αυτό το κομμάτι υλικού μπορούσε να προγραμματιστεί. Αντίστοιχα, θα μπορούσαμε να περιγράψουμε τη λογική του πώς οι φωτογραφίες ενός συγκεκριμένου χρήστη εξυπηρετούνταν από μια συγκεκριμένη κρυφή μνήμη. Πως μοιάζει? Υπάρχει ένα κομμάτι υλικού που κοιτάζει το Διαδίκτυο σε έναν τομέα, μια IP, κάνει εκφόρτωση ssl, αναλύει τα αιτήματα http, επιλέγει έναν αριθμό κρυφής μνήμης από το IRule, πού να πάει και αφήνει την κυκλοφορία να πάει εκεί. Ταυτόχρονα, κάνει υγειονομικούς ελέγχους και σε περίπτωση που κάποιο μηχάνημα δεν ήταν διαθέσιμο, τότε το κάναμε έτσι ώστε η κίνηση να πηγαίνει σε έναν backup server. Από την άποψη της διαμόρφωσης, υπάρχουν, φυσικά, ορισμένες αποχρώσεις, αλλά γενικά όλα είναι πολύ απλά: καταχωρούμε μια κάρτα, αντιστοιχία ενός συγκεκριμένου αριθμού στην IP μας στο δίκτυο, λέμε ότι θα ακούσουμε στις θύρες 80 και 443, λέμε ότι εάν ο διακομιστής δεν είναι διαθέσιμος, τότε πρέπει να στείλετε κίνηση στον εφεδρικό, σε αυτήν την περίπτωση τον 35ο, και περιγράφουμε μια δέσμη λογικής για το πώς θα πρέπει να αποσυναρμολογηθεί αυτή η αρχιτεκτονική. Το μόνο πρόβλημα ήταν ότι η γλώσσα στην οποία είχε προγραμματιστεί το υλικό ήταν η Tcl. Αν κάποιος το θυμάται καθόλου αυτό... αυτή η γλώσσα είναι περισσότερο μόνο για εγγραφή παρά μια γλώσσα κατάλληλη για προγραμματισμό:
Τι πήραμε; Λάβαμε ένα κομμάτι υλικού που διασφαλίζει υψηλή διαθεσιμότητα της υποδομής μας, δρομολογεί όλη την κυκλοφορία μας, παρέχει οφέλη για την υγεία και απλώς λειτουργεί. Επιπλέον, λειτουργεί για αρκετό καιρό: τα τελευταία 10 χρόνια δεν υπήρξαν παράπονα για αυτό. Στις αρχές του 2018, στέλναμε ήδη περίπου 80 χιλιάδες φωτογραφίες ανά δευτερόλεπτο. Πρόκειται για περίπου 80 gigabit κίνησης και από τα δύο κέντρα δεδομένων μας.
Ωστόσο…
Στις αρχές του 2018, είδαμε μια άσχημη εικόνα στα charts: ο χρόνος που χρειαζόταν για την αποστολή φωτογραφιών είχε σαφώς αυξηθεί. Και έπαψε να μας ταιριάζει. Το πρόβλημα είναι ότι αυτή η συμπεριφορά ήταν ορατή μόνο κατά τη διάρκεια της αιχμής της κυκλοφορίας - για την εταιρεία μας αυτή είναι η νύχτα από Κυριακή έως Δευτέρα. Αλλά τον υπόλοιπο χρόνο το σύστημα συμπεριφέρθηκε ως συνήθως, χωρίς σημάδια αποτυχίας.
Ωστόσο, το πρόβλημα έπρεπε να λυθεί. Εντοπίσαμε πιθανά σημεία συμφόρησης και αρχίσαμε να τα εξαλείφουμε. Πρώτα απ 'όλα, φυσικά, επεκτείναμε τα εξωτερικά uplinks, πραγματοποιήσαμε πλήρη έλεγχο των εσωτερικών uplinks και βρήκαμε όλα τα πιθανά σημεία συμφόρησης. Όλα αυτά όμως δεν έδωσαν προφανές αποτέλεσμα, το πρόβλημα δεν εξαφανίστηκε.
Ένα άλλο πιθανό πρόβλημα ήταν η απόδοση των ίδιων των κρυφών φωτογραφιών. Και αποφασίσαμε ότι ίσως το πρόβλημα έγκειται σε αυτούς. Λοιπόν, επεκτείναμε την απόδοση - κυρίως θύρες δικτύου σε κρυφές μνήμες φωτογραφιών. Αλλά και πάλι δεν παρατηρήθηκε εμφανής βελτίωση. Στο τέλος, δώσαμε μεγάλη προσοχή στην απόδοση του ίδιου του LTM και εδώ είδαμε μια θλιβερή εικόνα στα γραφήματα: το φορτίο σε όλες τις CPU αρχίζει να πηγαίνει ομαλά, αλλά στη συνέχεια ξαφνικά φτάνει σε ένα οροπέδιο. Ταυτόχρονα, το LTM σταματά να ανταποκρίνεται επαρκώς σε ελέγχους υγείας και uplinks και αρχίζει να τα απενεργοποιεί τυχαία, γεγονός που οδηγεί σε σοβαρή υποβάθμιση της απόδοσης.
Δηλαδή, έχουμε εντοπίσει την πηγή του προβλήματος, εντοπίσαμε το σημείο συμφόρησης. Μένει να αποφασίσουμε τι θα κάνουμε.
Το πρώτο, πιο προφανές πράγμα που θα μπορούσαμε να κάνουμε είναι να εκσυγχρονίσουμε με κάποιο τρόπο το ίδιο το LTM. Αλλά υπάρχουν ορισμένες αποχρώσεις εδώ, επειδή αυτό το υλικό είναι αρκετά μοναδικό, δεν θα πάτε στο πλησιέστερο σούπερ μάρκετ και δεν θα το αγοράσετε. Αυτή είναι μια ξεχωριστή σύμβαση, μια ξεχωριστή σύμβαση άδειας χρήσης και θα χρειαστεί πολύς χρόνος. Η δεύτερη επιλογή είναι να αρχίσετε να σκέφτεστε μόνοι σας, να βρείτε τη δική σας λύση χρησιμοποιώντας τα δικά σας στοιχεία, κατά προτίμηση χρησιμοποιώντας ένα πρόγραμμα ανοιχτής πρόσβασης. Το μόνο που μένει είναι να αποφασίσουμε τι ακριβώς θα επιλέξουμε για αυτό και πόσο χρόνο θα αφιερώσουμε για την επίλυση αυτού του προβλήματος, επειδή οι χρήστες δεν λάμβαναν αρκετές φωτογραφίες. Επομένως, πρέπει να τα κάνουμε όλα αυτά πολύ, πολύ γρήγορα, θα έλεγε κανείς χθες.
Δεδομένου ότι η εργασία ακουγόταν σαν "κάντε κάτι όσο το δυνατόν γρηγορότερα και χρησιμοποιώντας το υλικό που έχουμε", το πρώτο πράγμα που σκεφτήκαμε ήταν απλώς να αφαιρέσουμε μερικά όχι πολύ ισχυρά μηχανήματα από το μπροστινό μέρος, να βάλουμε το Nginx εκεί, με το οποίο ξέρουμε πώς να εργαστείτε και προσπαθήστε να εφαρμόσετε την ίδια λογική που συνήθιζε να κάνει το υλικό. Δηλαδή, στην πραγματικότητα, αφήσαμε το υλικό μας, εγκαταστήσαμε 4 ακόμη διακομιστές που έπρεπε να ρυθμίσουμε, δημιουργήσαμε εξωτερικούς τομείς για αυτούς, όπως ήταν πριν από 10 χρόνια... Χάσαμε λίγο σε διαθεσιμότητα αν έπεφταν αυτά τα μηχανήματα, αλλά ακόμα λιγότερο, έλυσαν το πρόβλημα των χρηστών μας τοπικά.
Αντίστοιχα, η λογική παραμένει η ίδια: εγκαθιστούμε το Nginx, μπορεί να κάνει εκφόρτωση SSL, μπορούμε με κάποιο τρόπο να προγραμματίσουμε τη λογική δρομολόγησης, ελέγχους υγείας στις ρυθμίσεις και απλά να αντιγράψουμε τη λογική που είχαμε πριν.
Ας καθίσουμε να γράψουμε ρυθμίσεις. Στην αρχή φαινόταν ότι όλα ήταν πολύ απλά, αλλά, δυστυχώς, είναι πολύ δύσκολο να βρείτε εγχειρίδια για κάθε εργασία. Ως εκ τούτου, δεν συνιστούμε απλώς να κάνετε google "πώς να ρυθμίσετε το Nginx για φωτογραφίες": είναι καλύτερο να ανατρέξετε στην επίσημη τεκμηρίωση, η οποία θα δείξει ποιες ρυθμίσεις πρέπει να αγγίξετε. Αλλά είναι καλύτερο να επιλέξετε τη συγκεκριμένη παράμετρο μόνοι σας. Λοιπόν, όλα είναι απλά: περιγράφουμε τους διακομιστές που έχουμε, περιγράφουμε τα πιστοποιητικά... Αλλά το πιο ενδιαφέρον πράγμα είναι, στην πραγματικότητα, η ίδια η λογική δρομολόγησης.
Στην αρχή μας φάνηκε ότι απλώς περιγράφαμε την τοποθεσία μας, ταιριάζαμε τον αριθμό της κρυφής μνήμης φωτογραφιών μας, χρησιμοποιούσαμε τα χέρια μας ή μια γεννήτρια για να περιγράψουμε πόσα upstream χρειαζόμαστε, σε κάθε upstream υποδεικνύουμε τον διακομιστή στον οποίο θα έπρεπε η κίνηση πηγαίνετε και έναν εφεδρικό διακομιστή - εάν ο κύριος διακομιστής δεν είναι διαθέσιμος:
Αλλά, μάλλον, αν όλα ήταν τόσο απλά, απλά θα πηγαίναμε σπίτι και δεν θα λέγαμε τίποτα. Δυστυχώς, με τις προεπιλεγμένες ρυθμίσεις Nginx, οι οποίες, γενικά, έγιναν κατά τη διάρκεια πολλών ετών ανάπτυξης και δεν είναι απολύτως κατάλληλες για αυτήν την περίπτωση... η διαμόρφωση μοιάζει με αυτό: εάν κάποιος διακομιστής upstream έχει σφάλμα αιτήματος ή χρονικό όριο λήξης, το Nginx πάντα αλλάζει την κυκλοφορία στο επόμενο. Επιπλέον, μετά την πρώτη αποτυχία, εντός 10 δευτερολέπτων ο διακομιστής θα απενεργοποιηθεί επίσης, τόσο κατά λάθος όσο και λόγω χρονικού ορίου - δεν μπορεί καν να ρυθμιστεί με κανέναν τρόπο. Δηλαδή, εάν αφαιρέσουμε ή επαναφέρουμε την επιλογή χρονικού ορίου στην upstream οδηγία, τότε, αν και το Nginx δεν θα επεξεργαστεί αυτό το αίτημα και θα απαντήσει με κάποιο όχι πολύ καλό σφάλμα, ο διακομιστής θα κλείσει.
Για να το αποφύγουμε αυτό, κάναμε δύο πράγματα:
α) απαγόρευσαν στο Nginx να το κάνει αυτό χειροκίνητα - και δυστυχώς, ο μόνος τρόπος για να γίνει αυτό είναι απλώς να ορίσετε τις ρυθμίσεις μέγιστων αποτυχιών.
β) θυμηθήκαμε ότι σε άλλα έργα χρησιμοποιούμε μια ενότητα που μας επιτρέπει να κάνουμε ιατρικούς ελέγχους ιστορικού - κατά συνέπεια, κάναμε αρκετά συχνούς υγειονομικούς ελέγχους, ώστε ο χρόνος διακοπής λειτουργίας σε περίπτωση ατυχήματος να είναι ελάχιστος.
Δυστυχώς, ούτε αυτό είναι όλο, επειδή κυριολεκτικά οι δύο πρώτες εβδομάδες λειτουργίας αυτού του σχήματος έδειξαν ότι ο έλεγχος υγείας TCP είναι επίσης αναξιόπιστος: στον διακομιστή upstream μπορεί να μην είναι Nginx ή Nginx σε κατάσταση D και σε Σε αυτή την περίπτωση ο πυρήνας θα αποδεχτεί τη σύνδεση, ο έλεγχος υγείας θα περάσει, αλλά δεν θα λειτουργήσει. Επομένως, το αντικαταστήσαμε αμέσως με το Health-check http, φτιάξαμε ένα συγκεκριμένο, το οποίο, αν επιστρέψει 200, τότε όλα λειτουργούν σε αυτό το σενάριο. Μπορείτε να κάνετε πρόσθετη λογική - για παράδειγμα, στην περίπτωση αποθήκευσης διακομιστών προσωρινής αποθήκευσης, ελέγξτε ότι το σύστημα αρχείων έχει τοποθετηθεί σωστά:
Και αυτό θα μας ταίριαζε, εκτός από το ότι αυτή τη στιγμή το κύκλωμα επαναλάμβανε εντελώς αυτό που έκανε το υλικό. Αλλά θέλαμε να πάμε καλύτερα. Προηγουμένως, είχαμε έναν εφεδρικό διακομιστή και αυτό μάλλον δεν είναι πολύ καλό, γιατί εάν έχετε εκατό διακομιστές, τότε όταν αποτυγχάνουν αρκετοί ταυτόχρονα, ένας διακομιστής αντιγράφων ασφαλείας είναι απίθανο να αντιμετωπίσει το φόρτο. Ως εκ τούτου, αποφασίσαμε να διανείμουμε την κράτηση σε όλους τους διακομιστές: απλώς δημιουργήσαμε έναν άλλο ξεχωριστό ανάντη, γράψαμε όλους τους διακομιστές εκεί με συγκεκριμένες παραμέτρους σύμφωνα με το φορτίο που μπορούν να εξυπηρετήσουν, προσθέσαμε τους ίδιους ελέγχους υγείας που είχαμε πριν:
Δεδομένου ότι είναι αδύνατο να μεταβείτε σε άλλη ανοδική ροή εντός ενός ανοδικού ρεύματος, ήταν απαραίτητο να βεβαιωθούμε ότι εάν η κύρια ανάντη, στην οποία απλώς καταγράψαμε τη σωστή, απαραίτητη προσωρινή μνήμη φωτογραφιών, δεν ήταν διαθέσιμη, απλώς περάσαμε από τη σελίδα σφάλματος στην εναλλακτική, από όπου πήγαμε στο backup upstream:
Και προσθέτοντας κυριολεκτικά τέσσερις διακομιστές, αυτό είναι που πήραμε: αντικαταστήσαμε μέρος του φορτίου - το αφαιρέσαμε από το LTM σε αυτούς τους διακομιστές, εφαρμόσαμε την ίδια λογική εκεί, χρησιμοποιώντας τυπικό υλικό και λογισμικό, και αμέσως λάβαμε το μπόνους που μπορούν αυτοί οι διακομιστές να κλιμακωθούν, γιατί μπορούν απλά να προμηθεύονται όσο χρειάζεται. Λοιπόν, το μόνο αρνητικό είναι ότι έχουμε χάσει την υψηλή διαθεσιμότητα για εξωτερικούς χρήστες. Αλλά εκείνη τη στιγμή έπρεπε να το θυσιάσουμε αυτό, γιατί ήταν απαραίτητο να λυθεί άμεσα το πρόβλημα. Έτσι, αφαιρέσαμε μέρος του φορτίου, ήταν περίπου 40% εκείνη τη στιγμή, η LTM ένιωθε καλά και κυριολεκτικά δύο εβδομάδες μετά την έναρξη του προβλήματος, αρχίσαμε να στέλνουμε όχι 45 χιλιάδες αιτήματα ανά δευτερόλεπτο, αλλά 55 χιλιάδες. Στην πραγματικότητα, αυξηθήκαμε κατά 20% - αυτή είναι ξεκάθαρα η επισκεψιμότητα που δεν δώσαμε στον χρήστη. Και μετά από αυτό άρχισαν να σκέφτονται πώς να λύσουν το πρόβλημα που απομένει - να εξασφαλίσουν υψηλή εξωτερική προσβασιμότητα.
Κάναμε κάποια παύση, κατά την οποία συζητήσαμε ποια λύση θα χρησιμοποιούσαμε για αυτό. Υπήρχαν προτάσεις για τη διασφάλιση αξιοπιστίας με χρήση DNS, με χρήση ορισμένων οικιακών σεναρίων, πρωτοκόλλων δυναμικής δρομολόγησης... υπήρχαν πολλές επιλογές, αλλά έγινε ήδη σαφές ότι για πραγματικά αξιόπιστη παράδοση φωτογραφιών, πρέπει να εισαγάγετε ένα άλλο επίπεδο που θα το παρακολουθεί . Αυτά τα μηχανήματα ονομάσαμε σκηνοθέτες φωτογραφιών. Το λογισμικό στο οποίο βασιστήκαμε ήταν το Keepalived:
Αρχικά, σε τι αποτελείται το Keepalived; Το πρώτο είναι το πρωτόκολλο VRRP, ευρέως γνωστό στους δικτυωτές, που βρίσκεται σε εξοπλισμό δικτύου που παρέχει ανοχή σφαλμάτων στην εξωτερική διεύθυνση IP στην οποία συνδέονται οι πελάτες. Το δεύτερο μέρος είναι το IPVS, ο εικονικός διακομιστής IP, για εξισορρόπηση μεταξύ δρομολογητών φωτογραφιών και διασφάλιση ανοχής σφαλμάτων σε αυτό το επίπεδο. Και τρίτο - υγειονομικοί έλεγχοι.
Ας ξεκινήσουμε με το πρώτο μέρος: VRRP - πώς μοιάζει; Υπάρχει μια συγκεκριμένη εικονική IP, η οποία έχει μια καταχώρηση στο dns badoocdn.com, όπου συνδέονται οι πελάτες. Κάποια στιγμή, έχουμε μια διεύθυνση IP σε έναν διακομιστή. Τα πακέτα Keepalived εκτελούνται μεταξύ των διακομιστών χρησιμοποιώντας το πρωτόκολλο VRRP και εάν το master εξαφανιστεί από το ραντάρ - ο διακομιστής έχει επανεκκινηθεί ή κάτι άλλο, τότε ο διακομιστής αντιγράφων ασφαλείας λαμβάνει αυτόματα αυτήν τη διεύθυνση IP - δεν απαιτούνται μη αυτόματες ενέργειες. Η διαφορά μεταξύ master και backup είναι κυρίως προτεραιότητα: όσο υψηλότερη είναι, τόσο μεγαλύτερη είναι η πιθανότητα το μηχάνημα να γίνει master. Ένα πολύ μεγάλο πλεονέκτημα είναι ότι δεν χρειάζεται να διαμορφώσετε διευθύνσεις IP στον ίδιο τον διακομιστή, αρκεί να τις περιγράψετε στη διαμόρφωση και εάν οι διευθύνσεις IP χρειάζονται κάποιους προσαρμοσμένους κανόνες δρομολόγησης, αυτό περιγράφεται απευθείας στη διαμόρφωση, χρησιμοποιώντας το ίδια σύνταξη όπως περιγράφεται στο πακέτο VRRP. Δεν θα συναντήσετε άγνωστα πράγματα.
Πώς φαίνεται αυτό στην πράξη; Τι συμβαίνει εάν ένας από τους διακομιστές αποτύχει; Μόλις εξαφανιστεί ο κύριος, το αντίγραφο ασφαλείας μας σταματά να λαμβάνει διαφημίσεις και γίνεται αυτόματα κύριος. Μετά από κάποιο χρονικό διάστημα, επισκευάσαμε το κύριο, επανεκκινήσαμε, αυξήσαμε το Keepalived - οι διαφημίσεις φτάνουν με μεγαλύτερη προτεραιότητα από το αντίγραφο ασφαλείας και το αντίγραφο ασφαλείας επιστρέφει αυτόματα, αφαιρεί τις διευθύνσεις IP, δεν χρειάζεται να γίνουν μη αυτόματες ενέργειες.
Έτσι, έχουμε εξασφαλίσει την ανοχή σφαλμάτων της εξωτερικής διεύθυνσης IP. Το επόμενο μέρος είναι να εξισορροπήσετε με κάποιο τρόπο την κίνηση από την εξωτερική διεύθυνση IP στους δρομολογητές φωτογραφιών που ήδη την τερματίζουν. Όλα είναι ξεκάθαρα με τα πρωτόκολλα εξισορρόπησης. Αυτό είναι είτε ένα απλό round-robin, είτε λίγο πιο περίπλοκα πράγματα, wrr, σύνδεση λίστας και ούτω καθεξής. Αυτό περιγράφεται βασικά στην τεκμηρίωση, δεν υπάρχει τίποτα ιδιαίτερο. Αλλά η μέθοδος παράδοσης... Εδώ θα ρίξουμε μια πιο προσεκτική ματιά στο γιατί επιλέξαμε ένα από αυτά. Αυτά είναι τα NAT, Direct Routing και TUN. Γεγονός είναι ότι σχεδιάσαμε αμέσως να παραδώσουμε 100 gigabit επισκεψιμότητας από τους ιστότοπους. Αν υπολογίζετε, χρειάζεστε κάρτες 10 gigabit, σωστά; 10 κάρτες gigabit σε έναν διακομιστή είναι ήδη εκτός του πεδίου εφαρμογής, τουλάχιστον, της αντίληψής μας για τον «τυποποιημένο εξοπλισμό». Και μετά θυμηθήκαμε ότι δεν δίνουμε απλώς λίγη κίνηση, χαρίζουμε φωτογραφίες.
Τι το ιδιαίτερο; — Τεράστια διαφορά μεταξύ εισερχόμενης και εξερχόμενης κίνησης. Η εισερχόμενη κίνηση είναι πολύ μικρή, η εξερχόμενη κίνηση είναι πολύ μεγάλη:
Αν κοιτάξετε αυτά τα γραφήματα, μπορείτε να δείτε ότι αυτή τη στιγμή ο σκηνοθέτης λαμβάνει περίπου 200 MB ανά δευτερόλεπτο, αυτή είναι μια πολύ συνηθισμένη μέρα. Επιστρέφουμε 4,500 MB ανά δευτερόλεπτο, η αναλογία μας είναι περίπου 1/22. Είναι ήδη σαφές ότι για την πλήρη παροχή εξερχόμενης κίνησης σε 22 διακομιστές εργαζομένων, χρειαζόμαστε μόνο έναν που αποδέχεται αυτήν τη σύνδεση. Εδώ είναι που μας βοηθάει ο αλγόριθμος άμεσης δρομολόγησης.
Πως μοιάζει? Ο διευθυντής φωτογραφίας μας, σύμφωνα με τον πίνακα του, μεταδίδει συνδέσεις σε δρομολογητές φωτογραφιών. Αλλά οι δρομολογητές φωτογραφιών στέλνουν την κυκλοφορία επιστροφής απευθείας στο Διαδίκτυο, την στέλνουν στον πελάτη, δεν επιστρέφει μέσω του διευθυντή φωτογραφιών, επομένως, με έναν ελάχιστο αριθμό μηχανημάτων, διασφαλίζουμε πλήρη ανοχή σφαλμάτων και άντληση όλης της κυκλοφορίας. Στις ρυθμίσεις μοιάζει με αυτό: καθορίζουμε τον αλγόριθμο, στην περίπτωσή μας είναι ένα απλό rr, παρέχουμε τη μέθοδο άμεσης δρομολόγησης και μετά αρχίζουμε να απαριθμούμε όλους τους πραγματικούς διακομιστές, πόσους από αυτούς έχουμε. Το οποίο θα καθορίσει αυτήν την κίνηση. Εάν έχουμε έναν ή δύο περισσότερους διακομιστές εκεί ή πολλούς διακομιστές, προκύπτει μια τέτοια ανάγκη - απλώς προσθέτουμε αυτήν την ενότητα στη διαμόρφωση και μην ανησυχείτε πολύ. Από την πλευρά των πραγματικών διακομιστών, από την πλευρά του δρομολογητή φωτογραφιών, αυτή η μέθοδος απαιτεί την πιο ελάχιστη διαμόρφωση, περιγράφεται τέλεια στην τεκμηρίωση και δεν υπάρχουν παγίδες εκεί.
Αυτό που είναι ιδιαίτερα ωραίο είναι ότι μια τέτοια λύση δεν συνεπάγεται ριζικό επανασχεδιασμό του τοπικού δικτύου· αυτό ήταν σημαντικό για εμάς· έπρεπε να το λύσουμε με ελάχιστο κόστος. Αν κοιτάξεις , τότε θα δούμε πώς μοιάζει. Εδώ έχουμε έναν συγκεκριμένο εικονικό διακομιστή, στη θύρα 443, ακούει, αποδέχεται τη σύνδεση, παρατίθενται όλοι οι διακομιστές που λειτουργούν και μπορείτε να δείτε ότι η σύνδεση είναι, δώστε ή λάβετε, η ίδια. Αν δούμε τα στατιστικά στοιχεία στον ίδιο εικονικό διακομιστή, έχουμε εισερχόμενα πακέτα, εισερχόμενες συνδέσεις, αλλά καμία απολύτως εξερχόμενη. Οι εξερχόμενες συνδέσεις πηγαίνουν απευθείας στον πελάτη. Εντάξει, μπορέσαμε να το εξισορροπήσουμε. Τώρα, τι συμβαίνει εάν ένας από τους δρομολογητές φωτογραφιών μας αποτύχει; Άλλωστε ο σίδηρος είναι σίδηρος. Μπορεί να πάει σε πανικό πυρήνα, μπορεί να σπάσει, να καεί το τροφοδοτικό. Οτιδήποτε. Γι' αυτό χρειάζονται υγειονομικοί έλεγχοι. Μπορούν να είναι τόσο απλοί όσο ο έλεγχος του τρόπου λειτουργίας της θύρας ή κάτι πιο περίπλοκο, έως και κάποια οικιακά σενάρια που θα ελέγχουν ακόμη και την επιχειρηματική λογική.
Σταματήσαμε κάπου στη μέση: έχουμε ένα αίτημα https σε μια συγκεκριμένη τοποθεσία, το σενάριο καλείται, αν απαντήσει με 200η απάντηση, πιστεύουμε ότι όλα είναι καλά με αυτόν τον διακομιστή, ότι είναι ζωντανός και μπορεί να ενεργοποιηθεί αρκετά εύκολα.
Πώς φαίνεται αυτό, πάλι, στην πράξη; Ας απενεργοποιήσουμε τον διακομιστή για συντήρηση - αναβοσβήνει το BIOS, για παράδειγμα. Στα αρχεία καταγραφής, έχουμε αμέσως ένα χρονικό όριο, βλέπουμε την πρώτη γραμμή, μετά από τρεις προσπάθειες επισημαίνεται ως "αποτυχία" και απλώς αφαιρείται από τη λίστα.
Μια δεύτερη επιλογή συμπεριφοράς είναι επίσης δυνατή, όταν το VS είναι απλώς μηδενικό, αλλά αν επιστραφεί η φωτογραφία, αυτό δεν λειτουργεί καλά. Ο διακομιστής εμφανίζεται, το Nginx ξεκινά εκεί, το Health-check καταλαβαίνει αμέσως ότι η σύνδεση λειτουργεί, ότι όλα είναι καλά και ο διακομιστής εμφανίζεται στη λίστα μας και το φορτίο αρχίζει αμέσως να εφαρμόζεται σε αυτόν. Δεν απαιτούνται χειροκίνητες ενέργειες από τον διαχειριστή υπηρεσίας. Ο διακομιστής επανεκκινήθηκε τη νύχτα - το τμήμα παρακολούθησης δεν μας καλεί για αυτό το βράδυ. Σε πληροφορούν ότι έγινε αυτό, όλα καλά.
Έτσι, με έναν αρκετά απλό τρόπο, με τη βοήθεια ενός μικρού αριθμού διακομιστών, λύσαμε το πρόβλημα της ανοχής εξωτερικών σφαλμάτων.
Το μόνο που μένει να πούμε είναι ότι όλα αυτά, φυσικά, πρέπει να παρακολουθούνται. Ξεχωριστά, θα πρέπει να σημειωθεί ότι το Keepalivede, ως λογισμικό που γράφτηκε εδώ και πολύ καιρό, έχει πολλούς τρόπους για να το παρακολουθεί, τόσο χρησιμοποιώντας ελέγχους μέσω DBus, SMTP, SNMP και τυπικού Zabbix. Επιπλέον, ο ίδιος ξέρει να γράφει γράμματα σχεδόν για κάθε φτάρνισμα, και για να είμαι ειλικρινής, κάποια στιγμή σκεφτήκαμε να το απενεργοποιήσουμε, γιατί γράφει πολλά γράμματα για οποιαδήποτε αλλαγή κίνησης, ενεργοποίηση, για κάθε σύνδεση IP, και ούτω καθεξής. Φυσικά, αν υπάρχουν πολλοί διακομιστές, τότε μπορείτε να κατακλύσετε τον εαυτό σας με αυτά τα γράμματα. Παρακολουθούμε το nginx σε δρομολογητές φωτογραφιών χρησιμοποιώντας τυπικές μεθόδους και η παρακολούθηση υλικού δεν έχει εξαφανιστεί. Φυσικά, θα συμβουλεύαμε δύο ακόμη πράγματα: πρώτον, εξωτερικούς ελέγχους υγείας και διαθεσιμότητας, γιατί ακόμα κι αν όλα λειτουργούν, στην πραγματικότητα, ίσως οι χρήστες να μην λαμβάνουν φωτογραφίες λόγω προβλημάτων με εξωτερικούς παρόχους ή κάτι πιο περίπλοκο. Αξίζει πάντα να διατηρείτε κάπου σε άλλο δίκτυο, στο Amazon ή κάπου αλλού, ένα ξεχωριστό μηχάνημα που μπορεί να κάνει ping στους διακομιστές σας από το εξωτερικό, και αξίζει επίσης να χρησιμοποιήσετε είτε ανίχνευση ανωμαλιών, για όσους ξέρουν πώς να κάνουν δύσκολη μηχανική εκμάθηση ή απλή παρακολούθηση , τουλάχιστον για να παρακολουθείται εάν τα αιτήματα έχουν μειωθεί απότομα ή, αντίθετα, έχουν αυξηθεί. Μπορεί επίσης να είναι χρήσιμο.
Ας συνοψίσουμε: στην πραγματικότητα, αντικαταστήσαμε τη σιδερένια λύση, η οποία κάποια στιγμή έπαψε να μας ταιριάζει, με ένα αρκετά απλό σύστημα που κάνει τα πάντα το ίδιο, δηλαδή παρέχει τερματισμό της κίνησης HTTPS και περαιτέρω έξυπνη δρομολόγηση με το απαραίτητους υγειονομικούς ελέγχους. Έχουμε αυξήσει τη σταθερότητα αυτού του συστήματος, δηλαδή, εξακολουθούμε να έχουμε υψηλή διαθεσιμότητα για κάθε επίπεδο, καθώς και το μπόνους ότι είναι πολύ εύκολο να τα κλιμακώσουμε όλα σε κάθε επίπεδο, επειδή είναι τυπικό υλικό με τυπικό λογισμικό, δηλαδή , έχουμε απλοποιήσει τη διάγνωση πιθανών προβλημάτων.
Με τι καταλήξαμε; Είχαμε ένα πρόβλημα στις διακοπές του Ιανουαρίου του 2018. Τους πρώτους έξι μήνες, ενώ θέσαμε σε λειτουργία αυτό το σχήμα, το επεκτείναμε σε όλη την επισκεψιμότητα προκειμένου να αφαιρέσουμε όλη την κίνηση από το LTM, αυξήσαμε μόνο την επισκεψιμότητα σε ένα κέντρο δεδομένων από 40 gigabit σε 60 gigabit, και ταυτόχρονα για ολόκληρο το έτος 2018 μπόρεσαν να στείλουν σχεδόν τρεις φορές περισσότερες φωτογραφίες ανά δευτερόλεπτο.
Πηγή: www.habr.com