Γεια σου, Χαμπρ! Είμαι ο Artem Karamyshev, επικεφαλής της ομάδας διαχείρισης συστήματος . Είχαμε πολλά λανσαρίσματα νέων προϊόντων τον περασμένο χρόνο. Θέλαμε να διασφαλίσουμε ότι οι υπηρεσίες API ήταν εύκολα επεκτάσιμες, ανεκτικές σε σφάλματα και έτοιμες για ταχεία αύξηση του φόρτου των χρηστών. Η πλατφόρμα μας υλοποιείται στο OpenStack και θέλω να σας πω ποια προβλήματα ανοχής σφαλμάτων εξαρτημάτων έπρεπε να λύσουμε για να αποκτήσουμε ένα σύστημα ανοχής σε σφάλματα. Νομίζω ότι αυτό θα είναι ενδιαφέρον για όσους αναπτύσσουν επίσης προϊόντα στο OpenStack.
Η συνολική ανοχή σφαλμάτων μιας πλατφόρμας συνίσταται στην ανθεκτικότητα των στοιχείων της. Άρα σταδιακά θα περάσουμε από όλα τα επίπεδα όπου εντοπίσαμε κινδύνους και τους κλείσαμε.
Έκδοση βίντεο αυτής της ιστορίας, η κύρια πηγή της οποίας ήταν μια αναφορά στο συνέδριο Uptime day 4, που διοργανώθηκε από , μπορείς να δεις .
Ανθεκτικότητα της φυσικής αρχιτεκτονικής
Το δημόσιο τμήμα του cloud MCS βασίζεται πλέον σε δύο κέντρα δεδομένων Tier III, μεταξύ τους υπάρχει η δική του σκοτεινή ίνα, δεσμευμένη σε φυσικό επίπεδο από διαφορετικές διαδρομές, με απόδοση 200 Gbit/s. Η βαθμίδα III παρέχει το απαραίτητο επίπεδο ανοχής σφαλμάτων για τη φυσική υποδομή.
Το Dark Fiber διατηρείται τόσο σε φυσικό όσο και σε λογικό επίπεδο. Η διαδικασία κράτησης καναλιού ήταν επαναληπτική, προέκυψαν προβλήματα και βελτιώνουμε συνεχώς την επικοινωνία μεταξύ των κέντρων δεδομένων.
Για παράδειγμα, πριν από λίγο καιρό, ενώ εργαζόταν σε ένα πηγάδι κοντά σε ένα από τα κέντρα δεδομένων, ένας εκσκαφέας έσπασε έναν σωλήνα και μέσα σε αυτόν τον σωλήνα υπήρχε ένα κύριο και ένα εφεδρικό οπτικό καλώδιο. Το ανεκτικό σε σφάλματα κανάλι επικοινωνίας μας με το κέντρο δεδομένων αποδείχθηκε ευάλωτο σε ένα σημείο, στο πηγάδι. Αντίστοιχα, έχουμε χάσει μέρος των υποδομών. Βγάλαμε συμπεράσματα και κάναμε μια σειρά από ενέργειες, συμπεριλαμβανομένης της εγκατάστασης πρόσθετων οπτικών στο παρακείμενο φρεάτιο.
Στα κέντρα δεδομένων υπάρχουν σημεία παρουσίας παρόχων επικοινωνίας στους οποίους μεταδίδουμε τα προθέματά μας μέσω BGP. Για κάθε κατεύθυνση δικτύου, επιλέγεται η καλύτερη μέτρηση, η οποία επιτρέπει σε διαφορετικούς πελάτες να παρέχεται η καλύτερη ποιότητα σύνδεσης. Εάν η επικοινωνία μέσω ενός παρόχου διακοπεί, αναδημιουργούμε τη δρομολόγηση μέσω των διαθέσιμων παρόχων.
Εάν ένας πάροχος αποτύχει, μεταβαίνουμε αυτόματα στον επόμενο. Σε περίπτωση βλάβης ενός από τα κέντρα δεδομένων, έχουμε ένα αντίγραφο των υπηρεσιών μας στο δεύτερο κέντρο δεδομένων, το οποίο αναλαμβάνει ολόκληρο το φορτίο.
Ανθεκτικότητα φυσικής υποδομής
Τι χρησιμοποιούμε για την ανοχή σφαλμάτων σε επίπεδο εφαρμογής
Η υπηρεσία μας βασίζεται σε μια σειρά από στοιχεία ανοιχτού κώδικα.
ExaBGP είναι μια υπηρεσία που υλοποιεί έναν αριθμό λειτουργιών χρησιμοποιώντας το πρωτόκολλο δυναμικής δρομολόγησης που βασίζεται σε BGP. Το χρησιμοποιούμε ενεργά για να διαφημίσουμε τις διευθύνσεις IP που περιλαμβάνονται στη λίστα επιτρεπόμενων μέσω των οποίων οι χρήστες έχουν πρόσβαση στο API.
HAProxy είναι ένας εξισορροπητής υψηλού φορτίου που σας επιτρέπει να διαμορφώνετε πολύ ευέλικτους κανόνες εξισορρόπησης κυκλοφορίας σε διαφορετικά επίπεδα του μοντέλου OSI. Το χρησιμοποιούμε για να εξισορροπούμε μπροστά από όλες τις υπηρεσίες: βάσεις δεδομένων, μεσίτες μηνυμάτων, υπηρεσίες API, υπηρεσίες web, εσωτερικά έργα μας - όλα βρίσκονται πίσω από το HAProxy.
Εφαρμογή API — μια διαδικτυακή εφαρμογή γραμμένη σε python, με την οποία ο χρήστης διαχειρίζεται την υποδομή του και την υπηρεσία του.
Αίτηση εργαζομένων (εφεξής απλώς εργαζόμενος) - στις υπηρεσίες OpenStack, αυτός είναι ένας δαίμονας υποδομής που σας επιτρέπει να μεταδώσετε εντολές API στην υποδομή. Για παράδειγμα, η δημιουργία δίσκου λαμβάνει χώρα στον εργαζόμενο και το αίτημα δημιουργίας εμφανίζεται στο API της εφαρμογής.
Τυπική Αρχιτεκτονική Εφαρμογών OpenStack
Οι περισσότερες υπηρεσίες που αναπτύσσονται για το OpenStack προσπαθούν να ακολουθήσουν ένα μόνο παράδειγμα. Μια υπηρεσία συνήθως αποτελείται από 2 μέρη: API και εργάτες (backend executors). Κατά κανόνα, ένα API είναι μια εφαρμογή WSGI σε python, η οποία εκκινείται είτε ως ανεξάρτητη διεργασία (daemon), είτε χρησιμοποιώντας έναν έτοιμο διακομιστή web Nginx ή Apache. Το API επεξεργάζεται το αίτημα χρήστη και διαβιβάζει περαιτέρω οδηγίες στην εφαρμογή εργαζόμενου για εκτέλεση. Η μεταφορά πραγματοποιείται χρησιμοποιώντας έναν μεσίτη μηνυμάτων, συνήθως RabbitMQ, ενώ οι άλλοι υποστηρίζονται ελάχιστα. Όταν τα μηνύματα φτάνουν στον μεσίτη, τα επεξεργάζονται οι εργαζόμενοι και, εάν είναι απαραίτητο, επιστρέφουν μια απάντηση.
Αυτό το παράδειγμα περιλαμβάνει μεμονωμένα κοινά σημεία αποτυχίας: το RabbitMQ και τη βάση δεδομένων. Αλλά το RabbitMQ είναι απομονωμένο σε μία υπηρεσία και, θεωρητικά, μπορεί να είναι ατομικό για κάθε υπηρεσία. Έτσι, στο MCS διαχωρίζουμε αυτές τις υπηρεσίες όσο το δυνατόν περισσότερο· για κάθε μεμονωμένο έργο δημιουργούμε μια ξεχωριστή βάση δεδομένων, ένα ξεχωριστό RabbitMQ. Αυτή η προσέγγιση είναι καλή γιατί σε περίπτωση ατυχήματος σε ορισμένα ευάλωτα σημεία, δεν χαλάει ολόκληρη η υπηρεσία, αλλά μόνο μέρος της.
Ο αριθμός των εργαζομένων εφαρμογών είναι απεριόριστος, επομένως το API μπορεί εύκολα να κλιμακωθεί οριζόντια πίσω από τους εξισορροπητές προκειμένου να αυξήσει την απόδοση και την ανοχή σφαλμάτων.
Ορισμένες υπηρεσίες απαιτούν συντονισμό εντός της υπηρεσίας όταν συμβαίνουν πολύπλοκες διαδοχικές λειτουργίες μεταξύ API και εργαζομένων. Σε αυτήν την περίπτωση, χρησιμοποιείται ένα ενιαίο κέντρο συντονισμού, ένα σύστημα συμπλέγματος όπως το Redis, το Memcache, κ.λπ., το οποίο επιτρέπει σε έναν εργαζόμενο να πει στον άλλον ότι αυτή η εργασία του έχει ανατεθεί ("παρακαλώ μην το λάβετε"). Χρησιμοποιούμε etcd. Κατά κανόνα, οι εργαζόμενοι επικοινωνούν ενεργά με τη βάση δεδομένων, γράφουν και διαβάζουν πληροφορίες από εκεί. Χρησιμοποιούμε το mariadb ως βάση δεδομένων, η οποία βρίσκεται σε ένα σύμπλεγμα multimaster.
Αυτή η κλασική μεμονωμένη υπηρεσία είναι οργανωμένη με τρόπο γενικά αποδεκτό για το OpenStack. Μπορεί να θεωρηθεί ως ένα κλειστό σύστημα, για το οποίο οι μέθοδοι κλιμάκωσης και ανοχής σφαλμάτων είναι αρκετά προφανείς. Για παράδειγμα, για την ανοχή σφαλμάτων API, αρκεί να βάλετε έναν εξισορροπητή μπροστά τους. Η κλιμάκωση των εργαζομένων επιτυγχάνεται με την αύξηση του αριθμού τους.
Το αδύνατο σημείο σε όλο το σχήμα είναι το RabbitMQ και το MariaDB. Η αρχιτεκτονική τους αξίζει ένα ξεχωριστό άρθρο.Σε αυτό το άρθρο θέλω να εστιάσω στην ανοχή σφαλμάτων API.
Αρχιτεκτονική εφαρμογών Openstack. Εξισορρόπηση και ανοχή σφαλμάτων της πλατφόρμας cloud
Κάνοντας το HAProxy balancer ανεκτικό σε σφάλματα χρησιμοποιώντας το ExaBGP
Για να κάνουμε τα API μας επεκτάσιμα, γρήγορα και ανεκτικά σε σφάλματα, βάζουμε μπροστά τους έναν εξισορροπητή φορτίου. Επιλέξαμε το HAProxy. Κατά τη γνώμη μου, έχει όλα τα απαραίτητα χαρακτηριστικά για την εργασία μας: εξισορρόπηση σε πολλά επίπεδα OSI, διεπαφή διαχείρισης, ευελιξία και επεκτασιμότητα, μεγάλο αριθμό μεθόδων εξισορρόπησης, υποστήριξη για πίνακες συνεδρίας.
Το πρώτο πρόβλημα που έπρεπε να λυθεί ήταν η ανοχή σφαλμάτων του ίδιου του εξισορροπητή. Η απλή εγκατάσταση ενός εξισορροπητή δημιουργεί επίσης ένα σημείο αστοχίας: ο εξισορροπητής σπάει και η υπηρεσία διακόπτεται. Για να μην συμβεί αυτό, χρησιμοποιήσαμε το HAProxy σε συνδυασμό με το ExaBGP.
Το ExaBGP σάς επιτρέπει να εφαρμόσετε έναν μηχανισμό για τον έλεγχο της κατάστασης μιας υπηρεσίας. Χρησιμοποιήσαμε αυτόν τον μηχανισμό για να ελέγξουμε τη λειτουργικότητα του HAProxy και, σε περίπτωση προβλημάτων, να απενεργοποιήσουμε την υπηρεσία HAProxy από το BGP.
Σχέδιο ExaBGP+HAProxy
- Εγκαθιστούμε το απαραίτητο λογισμικό, ExaBGP και HAProxy, σε τρεις διακομιστές.
- Δημιουργούμε μια διεπαφή loopback σε κάθε διακομιστή.
- Και στους τρεις διακομιστές εκχωρούμε την ίδια λευκή διεύθυνση IP σε αυτήν τη διεπαφή.
- Μια λευκή διεύθυνση IP διαφημίζεται στο Διαδίκτυο μέσω του ExaBGP.
Η ανοχή σφαλμάτων επιτυγχάνεται με τη διαφήμιση της ίδιας διεύθυνσης IP και από τους τρεις διακομιστές. Από πλευράς δικτύου, η ίδια διεύθυνση είναι προσβάσιμη από τρία διαφορετικά επόμενα άλματα. Ο δρομολογητής βλέπει τρεις ίδιες διαδρομές, επιλέγει την υψηλότερη προτεραιότητα από αυτές με βάση τη δική του μέτρηση (αυτή είναι συνήθως η ίδια επιλογή) και η κίνηση πηγαίνει μόνο σε έναν από τους διακομιστές.
Σε περίπτωση προβλημάτων με τη λειτουργία του HAProxy ή αποτυχίας διακομιστή, το ExaBGP σταματά να ανακοινώνει τη διαδρομή και η κίνηση αλλάζει ομαλά σε άλλο διακομιστή.
Έτσι, πετύχαμε ανοχή σφάλματος του εξισορροπητή.
Ανοχή σφαλμάτων των εξισορροπητών HAProxy
Το σχήμα αποδείχθηκε ατελές: μάθαμε πώς να κάνουμε κράτηση για το HAProxy, αλλά δεν μάθαμε πώς να διανέμουμε το φορτίο στις υπηρεσίες. Επομένως, επεκτείναμε λίγο αυτό το σχήμα: προχωρήσαμε στην εξισορρόπηση μεταξύ πολλών λευκών διευθύνσεων IP.
Εξισορρόπηση βάσει DNS συν BGP
Το ζήτημα της εξισορρόπησης φορτίου για το HAProxy μας παραμένει άλυτο. Ωστόσο, μπορεί να λυθεί πολύ απλά, όπως κάναμε εδώ.
Για να εξισορροπήσετε τρεις διακομιστές θα χρειαστείτε 3 λευκές διευθύνσεις IP και παλιό καλό DNS. Κάθε μία από αυτές τις διευθύνσεις καθορίζεται στη διεπαφή επαναφοράς κάθε HAProxy και διαφημίζεται στο Διαδίκτυο.
Στο OpenStack, για τη διαχείριση πόρων, χρησιμοποιείται ένας κατάλογος υπηρεσιών, ο οποίος καθορίζει το API τελικού σημείου μιας συγκεκριμένης υπηρεσίας. Σε αυτόν τον κατάλογο καταχωρούμε ένα όνομα τομέα - public.infra.mail.ru, το οποίο επιλύεται μέσω DNS από τρεις διαφορετικές διευθύνσεις IP. Ως αποτέλεσμα, παίρνουμε κατανομή φορτίου μεταξύ τριών διευθύνσεων μέσω DNS.
Αλλά επειδή όταν ανακοινώνουμε λευκές διευθύνσεις IP δεν ελέγχουμε τις προτεραιότητες επιλογής διακομιστή, αυτό δεν εξισορροπείται ακόμη. Συνήθως, μόνο ένας διακομιστής θα επιλέγεται με βάση την αρχαιότητα της διεύθυνσης IP και οι άλλοι δύο θα είναι αδρανείς επειδή δεν καθορίζονται μετρήσεις στο BGP.
Ξεκινήσαμε να στέλνουμε διαδρομές μέσω ExaBGP με διαφορετικές μετρήσεις. Κάθε εξισορροπητής διαφημίζει και τις τρεις λευκές διευθύνσεις IP, αλλά μία από αυτές, η κύρια για αυτόν τον εξισορροπητή, διαφημίζεται με την ελάχιστη μέτρηση. Έτσι, ενώ και οι τρεις εξισορροπητές βρίσκονται σε λειτουργία, οι κλήσεις στην πρώτη διεύθυνση IP πηγαίνουν στον πρώτο εξισορροπητή, στον δεύτερο στον δεύτερο και στον τρίτο στον τρίτο.
Τι συμβαίνει όταν ένας από τους ισορροπιστές πέσει; Εάν οποιοσδήποτε εξισορροπητής αποτύχει, η κύρια διεύθυνσή του εξακολουθεί να διαφημίζεται από τα άλλα δύο και η κίνηση ανακατανέμεται μεταξύ τους. Έτσι, δίνουμε στο χρήστη πολλές διευθύνσεις IP ταυτόχρονα μέσω DNS. Εξισορροπώντας με DNS και διαφορετικές μετρήσεις, έχουμε μια ομοιόμορφη κατανομή του φορτίου και στους τρεις εξισορροπητές. Και ταυτόχρονα δεν χάνουμε την ανοχή σφαλμάτων.
Εξισορρόπηση HAProxy με βάση DNS + BGP
Αλληλεπίδραση μεταξύ ExaBGP και HAProxy
Έτσι, εφαρμόσαμε ανοχή σφαλμάτων σε περίπτωση αποχώρησης του διακομιστή, με βάση τη διακοπή της ανακοίνωσης δρομολογίων. Αλλά το HAProxy μπορεί να τερματιστεί για άλλους λόγους εκτός από την αποτυχία διακομιστή: σφάλματα διαχείρισης, αποτυχίες εντός της υπηρεσίας. Θέλουμε να αφαιρέσουμε το σπασμένο εξισορροπητή από κάτω από το φορτίο και σε αυτές τις περιπτώσεις και χρειαζόμαστε διαφορετικό μηχανισμό.
Επομένως, επεκτείνοντας το προηγούμενο σχήμα, εφαρμόσαμε τον καρδιακό παλμό μεταξύ ExaBGP και HAProxy. Αυτή είναι μια εφαρμογή λογισμικού της αλληλεπίδρασης μεταξύ ExaBGP και HAProxy, όταν το ExaBGP χρησιμοποιεί προσαρμοσμένα σενάρια για να ελέγξει την κατάσταση των εφαρμογών.
Για να το κάνετε αυτό, πρέπει να διαμορφώσετε έναν έλεγχο υγείας στη διαμόρφωση ExaBGP, ο οποίος μπορεί να ελέγξει την κατάσταση του HAProxy. Στην περίπτωσή μας, διαμορφώσαμε το σύστημα υποστήριξης υγείας στο HAProxy και από την πλευρά του ExaBGP ελέγχουμε με ένα απλό αίτημα GET. Εάν η ανακοίνωση σταματήσει να συμβαίνει, τότε το HAProxy πιθανότατα δεν λειτουργεί και δεν χρειάζεται να το διαφημίσετε.
Έλεγχος υγείας HAProxy
HAProxy Peers: συγχρονισμός συνεδρίας
Το επόμενο πράγμα που έπρεπε να κάνετε ήταν να συγχρονίσετε τις συνεδρίες. Όταν εργάζεστε μέσω κατανεμημένων εξισορροπητών, είναι δύσκολο να οργανώσετε την αποθήκευση πληροφοριών σχετικά με τις περιόδους λειτουργίας πελατών. Αλλά το HAProxy είναι ένας από τους λίγους εξισορροπητές που μπορούν να το κάνουν αυτό λόγω της λειτουργικότητας Peers - της δυνατότητας μεταφοράς πινάκων συνεδρίας μεταξύ διαφορετικών διεργασιών HAProxy.
Υπάρχουν διάφορες μέθοδοι εξισορρόπησης: απλές όπως π.χ , και επεκτείνεται, όταν απομνημονεύεται η συνεδρία του πελάτη και κάθε φορά που καταλήγει στον ίδιο διακομιστή με πριν. Θέλαμε να εφαρμόσουμε τη δεύτερη επιλογή.
Το HAProxy χρησιμοποιεί stick-tables για να αποθηκεύει συνεδρίες πελάτη αυτού του μηχανισμού. Αποθηκεύουν την αρχική διεύθυνση IP του πελάτη, την επιλεγμένη διεύθυνση προορισμού (backend) και ορισμένες πληροφορίες υπηρεσίας. Συνήθως, οι πίνακες stick χρησιμοποιούνται για την αποθήκευση ενός ζεύγους πηγής-IP + προορισμού-IP, το οποίο είναι ιδιαίτερα χρήσιμο για εφαρμογές που δεν μπορούν να μεταφέρουν το περιβάλλον περιόδου λειτουργίας χρήστη κατά τη μετάβαση σε άλλο εξισορροπητή, για παράδειγμα, σε λειτουργία εξισορρόπησης RoundRobin.
Εάν ένα stick stick διδαχτεί να κινείται μεταξύ διαφορετικών διεργασιών HAProxy (μεταξύ των οποίων πραγματοποιείται η εξισορρόπηση), οι εξισορροπητές μας θα μπορούν να λειτουργούν με ένα σύνολο τραπεζιών stick. Αυτό θα καταστήσει δυνατή την απρόσκοπτη εναλλαγή του δικτύου του πελάτη εάν αποτύχει ένας από τους εξισορροπητές· η εργασία με τις περιόδους σύνδεσης πελάτη θα συνεχιστεί στα ίδια backends που είχαν επιλεγεί νωρίτερα.
Για σωστή λειτουργία, πρέπει να επιλυθεί το πρόβλημα της διεύθυνσης IP προέλευσης του εξισορροπητή από τον οποίο δημιουργήθηκε η περίοδος λειτουργίας. Στην περίπτωσή μας, αυτή είναι μια δυναμική διεύθυνση στη διεπαφή loopback.
Η σωστή εργασία των συνομηλίκων επιτυγχάνεται μόνο υπό ορισμένες προϋποθέσεις. Δηλαδή, τα χρονικά όρια TCP πρέπει να είναι αρκετά μεγάλα ή η εναλλαγή πρέπει να είναι αρκετά γρήγορη, ώστε η περίοδος TCP να μην έχει χρόνο να τερματιστεί. Ωστόσο, επιτρέπει την απρόσκοπτη εναλλαγή.
Στο IaaS έχουμε μια υπηρεσία που έχει κατασκευαστεί χρησιμοποιώντας την ίδια τεχνολογία. Αυτό , που ονομάζεται Octavia. Βασίζεται σε δύο διαδικασίες HAProxy και αρχικά περιλαμβάνει υποστήριξη για peers. Έχουν αποδειχθεί εξαιρετικοί σε αυτή την υπηρεσία.
Η εικόνα δείχνει σχηματικά την κίνηση των ομότιμων πινάκων μεταξύ τριών περιπτώσεων HAProxy, προτείνεται μια διαμόρφωση για το πώς μπορεί να διαμορφωθεί:
HAProxy Peers (συγχρονισμός περιόδου σύνδεσης)
Εάν εφαρμόσετε το ίδιο σχήμα, η λειτουργία του πρέπει να ελεγχθεί προσεκτικά. Δεν είναι γεγονός ότι θα λειτουργήσει με τον ίδιο τρόπο 100% του χρόνου. Τουλάχιστον, όμως, δεν θα χάσετε τους πίνακες stick όταν πρέπει να θυμάστε την IP πηγής του πελάτη.
Περιορισμός του αριθμού των ταυτόχρονων αιτημάτων από τον ίδιο πελάτη
Οποιεσδήποτε υπηρεσίες είναι δημόσια διαθέσιμες, συμπεριλαμβανομένων των API μας, μπορεί να υπόκεινται σε χιονοστιβάδες αιτημάτων. Οι λόγοι για αυτούς μπορεί να είναι εντελώς διαφορετικοί, από σφάλματα χρήστη έως στοχευμένες επιθέσεις. Είμαστε περιοδικά DDoSed από διευθύνσεις IP. Οι πελάτες συχνά κάνουν λάθη στα σενάρια τους και μας δίνουν mini-DDoS.
Με τον ένα ή τον άλλο τρόπο, πρέπει να παρέχεται πρόσθετη προστασία. Η προφανής λύση είναι να περιορίσετε τον αριθμό των αιτημάτων API και να μην σπαταλήσετε χρόνο CPU στην επεξεργασία κακόβουλων αιτημάτων.
Για την εφαρμογή τέτοιων περιορισμών, χρησιμοποιούμε όρια ποσοστών, οργανωμένα με βάση το HAProxy, χρησιμοποιώντας τους ίδιους πίνακες κολλήματος. Η ρύθμιση ορίων είναι αρκετά απλή και σας επιτρέπει να περιορίσετε τον χρήστη με τον αριθμό των αιτημάτων στο API. Ο αλγόριθμος θυμάται την IP πηγής από την οποία γίνονται τα αιτήματα και περιορίζει τον αριθμό των ταυτόχρονων αιτημάτων από έναν χρήστη. Φυσικά, υπολογίσαμε το μέσο προφίλ φόρτωσης API για κάθε υπηρεσία και ορίσαμε ένα όριο ≈ 10 φορές αυτήν την τιμή. Συνεχίζουμε να παρακολουθούμε στενά την κατάσταση και κρατάμε το δάχτυλό μας στον παλμό.
Πώς φαίνεται αυτό στην πράξη; Έχουμε πελάτες που χρησιμοποιούν συνεχώς τα API αυτόματης κλιμάκωσης. Δημιουργούν περίπου διακόσιες έως τριακόσιες εικονικές μηχανές το πρωί και τις διαγράφουν το βράδυ. Για το OpenStack, η δημιουργία μιας εικονικής μηχανής, επίσης με υπηρεσίες PaaS, απαιτεί τουλάχιστον 1000 αιτήματα API, καθώς η αλληλεπίδραση μεταξύ των υπηρεσιών πραγματοποιείται επίσης μέσω του API.
Μια τέτοια μεταφορά εργασιών προκαλεί ένα αρκετά μεγάλο φορτίο. Αξιολογήσαμε αυτό το φορτίο, συλλέξαμε τις ημερήσιες κορυφές, τις δεκαπλασιάσαμε και αυτό έγινε το όριο ρυθμού μας. Κρατάμε το δάχτυλό μας στον παλμό. Βλέπουμε συχνά bots και σαρωτές που προσπαθούν να μας κοιτάξουν για να δουν εάν έχουμε σενάρια CGA που μπορούν να εκτελεστούν, τα κόβουμε ενεργά.
Πώς να ενημερώσετε τη βάση κώδικα χωρίς να το αντιληφθούν οι χρήστες
Εφαρμόζουμε επίσης ανοχή σφαλμάτων σε επίπεδο διαδικασιών ανάπτυξης κώδικα. Ενδέχεται να υπάρχουν σφάλματα κατά τη διάρκεια της διάθεσης, αλλά ο αντίκτυπός τους στη διαθεσιμότητα της υπηρεσίας μπορεί να ελαχιστοποιηθεί.
Ενημερώνουμε συνεχώς τις υπηρεσίες μας και πρέπει να διασφαλίζουμε ότι η βάση κώδικα ενημερώνεται χωρίς να επηρεάζονται οι χρήστες. Καταφέραμε να λύσουμε αυτό το πρόβλημα χρησιμοποιώντας τις δυνατότητες διαχείρισης του HAProxy και την εφαρμογή του Graceful Shutdown στις υπηρεσίες μας.
Για την επίλυση αυτού του προβλήματος, ήταν απαραίτητο να διασφαλιστεί ο έλεγχος του εξισορροπητή και η "σωστή" διακοπή λειτουργίας των υπηρεσιών:
- Στην περίπτωση του HAProxy, ο έλεγχος πραγματοποιείται μέσω ενός αρχείου στατιστικών στοιχείων, το οποίο είναι ουσιαστικά μια υποδοχή και ορίζεται στη διαμόρφωση HAProxy. Μπορείτε να του στείλετε εντολές μέσω του stdio. Αλλά το κύριο εργαλείο ελέγχου διαμόρφωσης μας είναι ansible, επομένως έχει μια ενσωματωμένη μονάδα για τη διαχείριση του HAProxy. Το οποίο χρησιμοποιούμε ενεργά.
- Οι περισσότερες από τις υπηρεσίες μας API και Engine υποστηρίζουν χαριτωμένες τεχνολογίες τερματισμού λειτουργίας: κατά τον τερματισμό της λειτουργίας, περιμένουν να ολοκληρωθεί η τρέχουσα εργασία, είτε πρόκειται για αίτημα http είτε για εργασία υπηρεσίας. Το ίδιο συμβαίνει και με τον εργαζόμενο. Γνωρίζει όλες τις εργασίες που κάνει και τελειώνει όταν έχει ολοκληρώσει επιτυχώς τα πάντα.
Χάρη σε αυτά τα δύο σημεία, ο ασφαλής αλγόριθμος για την ανάπτυξή μας μοιάζει με αυτόν.
- Ο προγραμματιστής συγκεντρώνει ένα νέο πακέτο κώδικα (για εμάς αυτό είναι το RPM), το δοκιμάζει στο περιβάλλον dev, το δοκιμάζει στο στάδιο και το αφήνει στο αποθετήριο σταδίου.
- Ο προγραμματιστής ορίζει την εργασία για την ανάπτυξη με την πιο λεπτομερή περιγραφή των "τεχνουργημάτων": την έκδοση του νέου πακέτου, μια περιγραφή της νέας λειτουργικότητας και άλλες λεπτομέρειες σχετικά με την ανάπτυξη, εάν είναι απαραίτητο.
- Ο διαχειριστής συστήματος ξεκινά την ενημέρωση. Εκκινεί το βιβλίο παιχνιδιού Ansible, το οποίο με τη σειρά του κάνει τα εξής:
- Παίρνει ένα πακέτο από το αποθετήριο σταδίου και το χρησιμοποιεί για να ενημερώσει την έκδοση του πακέτου στο αποθετήριο προϊόντων.
- Συγκεντρώνει μια λίστα με backend της ενημερωμένης υπηρεσίας.
- Τερματίζει την πρώτη υπηρεσία που θα ενημερωθεί στο HAProxy και περιμένει να ολοκληρωθούν οι διεργασίες της. Χάρη στον χαριτωμένο τερματισμό λειτουργίας, είμαστε βέβαιοι ότι όλα τα τρέχοντα αιτήματα πελατών θα ολοκληρωθούν με επιτυχία.
- Μετά την πλήρη διακοπή του API και των εργαζομένων και την απενεργοποίηση του HAProxy, ο κώδικας ενημερώνεται.
- Υπηρεσίες εκτέλεσης Ansible.
- Για κάθε σέρβις, τραβιούνται ορισμένες «λαβές», οι οποίες πραγματοποιούν δοκιμές μονάδας σε έναν αριθμό προκαθορισμένων δοκιμών κλειδιών. Γίνεται ένας βασικός έλεγχος του νέου κωδικού.
- Εάν δεν βρέθηκαν σφάλματα στο προηγούμενο βήμα, ενεργοποιείται το backend.
- Ας περάσουμε στο επόμενο backend.
- Αφού ενημερωθούν όλα τα backend, ξεκινούν οι λειτουργικές δοκιμές. Εάν λείπουν, τότε ο προγραμματιστής εξετάζει οποιαδήποτε νέα λειτουργικότητα που δημιούργησε.
Αυτό ολοκληρώνει την ανάπτυξη.
Κύκλος ενημέρωσης υπηρεσίας
Αυτό το σχήμα δεν θα λειτουργούσε αν δεν είχαμε έναν κανόνα. Υποστηρίζουμε τόσο την παλιά όσο και τη νέα έκδοση στη μάχη. Εκ των προτέρων, στο στάδιο της ανάπτυξης λογισμικού, ορίζεται ότι ακόμη και αν υπάρξουν αλλαγές στη βάση δεδομένων υπηρεσιών, δεν θα παραβιάσουν τον προηγούμενο κώδικα. Ως αποτέλεσμα, η βάση κώδικα ενημερώνεται σταδιακά.
Συμπέρασμα
Μοιράζοντας τις δικές μου σκέψεις σχετικά με μια αρχιτεκτονική WEB με ανοχή σε σφάλματα, θα ήθελα να σημειώσω για άλλη μια φορά τα βασικά της σημεία:
- ανοχή φυσικών σφαλμάτων.
- ανοχή σφαλμάτων δικτύου (εξισορροπητές, BGP).
- ανοχή σφαλμάτων του λογισμικού που χρησιμοποιείται και αναπτύσσεται.
Σταθερό χρόνο λειτουργίας σε όλους!
Πηγή: www.habr.com
