One-cloud - OS σε επίπεδο κέντρου δεδομένων στην Odnoklassniki

Aloha, άνθρωποι! Ονομάζομαι Oleg Anastasyev, εργάζομαι στην Odnoklassniki στην ομάδα της Πλατφόρμας. Και εκτός από μένα, υπάρχει πολύ υλικό που δουλεύει στην Odnoklassniki. Έχουμε τέσσερα κέντρα δεδομένων με περίπου 500 rack με περισσότερους από 8 χιλιάδες διακομιστές. Σε κάποιο σημείο, συνειδητοποιήσαμε ότι η εισαγωγή ενός νέου συστήματος διαχείρισης θα μας επέτρεπε να φορτώνουμε τον εξοπλισμό πιο αποτελεσματικά, να διευκολύνουμε τη διαχείριση πρόσβασης, να αυτοματοποιήσουμε την (ανα)κατανομή των υπολογιστικών πόρων, να επιταχύνουμε την εκκίνηση νέων υπηρεσιών και να επιταχύνουμε τις απαντήσεις σε ατυχήματα μεγάλης κλίμακας.

Τι προέκυψε από αυτό;

Εκτός από εμένα και ένα σωρό υλικό, υπάρχουν επίσης άνθρωποι που εργάζονται με αυτό το υλικό: μηχανικοί που βρίσκονται απευθείας σε κέντρα δεδομένων. δικτυωτές που δημιουργούν λογισμικό δικτύου· διαχειριστές, ή SRE, που παρέχουν ανθεκτικότητα υποδομής· και τις ομάδες ανάπτυξης, καθεμία από αυτές είναι υπεύθυνη για μέρος των λειτουργιών της πύλης. Το λογισμικό που δημιουργούν λειτουργεί κάπως έτσι:

Τα αιτήματα των χρηστών λαμβάνονται και στις δύο προσόψεις της κύριας πύλης www.ok.ru, και σε άλλα, για παράδειγμα στα μέτωπα του μουσικού API. Για να επεξεργαστούν την επιχειρηματική λογική, καλούν τον διακομιστή εφαρμογών, ο οποίος, κατά την επεξεργασία του αιτήματος, καλεί τις απαραίτητες εξειδικευμένες μικροϋπηρεσίες - ένα γράφημα (γράφημα κοινωνικών συνδέσεων), cache χρήστη (cache προφίλ χρηστών) κ.λπ.

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

Γιατί αυτό? Αυτή η προσέγγιση είχε πολλά πλεονεκτήματα:

• Ανακουφισμένος μαζική διαχείριση. Ας υποθέσουμε ότι μια εργασία απαιτεί κάποιες βιβλιοθήκες, κάποιες ρυθμίσεις. Στη συνέχεια, ο διακομιστής εκχωρείται ακριβώς σε μια συγκεκριμένη ομάδα, περιγράφεται η πολιτική cfengine για αυτήν την ομάδα (ή έχει ήδη περιγραφεί) και αυτή η διαμόρφωση διατίθεται κεντρικά και αυτόματα σε όλους τους διακομιστές αυτής της ομάδας.
• Απλοποιημένη διάγνωση. Ας υποθέσουμε ότι κοιτάτε το αυξημένο φορτίο στον κεντρικό επεξεργαστή και συνειδητοποιείτε ότι αυτό το φορτίο θα μπορούσε να δημιουργηθεί μόνο από την εργασία που εκτελείται σε αυτόν τον επεξεργαστή υλικού. Η αναζήτηση για κάποιον που φταίει τελειώνει πολύ γρήγορα.
• Απλοποιημένη мониторинг. Εάν κάτι δεν πάει καλά με τον διακομιστή, η οθόνη το αναφέρει και ξέρετε ακριβώς ποιος φταίει.

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

Αυτή η προσέγγιση μας επέτρεψε επίσης να το κάνουμε εξειδικευμένες διαμορφώσεις σιδήρου για μια εργασία που εκτελείται σε αυτόν τον διακομιστή. Εάν η εργασία αποθηκεύει μεγάλες ποσότητες δεδομένων, τότε χρησιμοποιούμε διακομιστή 4U με πλαίσιο με 38 δίσκους. Εάν η εργασία είναι καθαρά υπολογιστική, τότε μπορούμε να αγοράσουμε έναν φθηνότερο διακομιστή 1U. Αυτό είναι υπολογιστικά αποδοτικό. Μεταξύ άλλων, αυτή η προσέγγιση μας επιτρέπει να χρησιμοποιούμε τέσσερις φορές λιγότερα μηχανήματα με φορτίο συγκρίσιμο με ένα φιλικό κοινωνικό δίκτυο.

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

Συνειδητοποιώντας ότι αυτό συνέβαινε, αποφασίσαμε να υπολογίσουμε πόσο αποτελεσματικά χρησιμοποιούσαμε τα ράφια.
Πήραμε την τιμή του πιο ισχυρού διακομιστή από τους οικονομικά δικαιολογημένους, υπολογίσαμε πόσους τέτοιους διακομιστές θα μπορούσαμε να τοποθετήσουμε σε rack, πόσες εργασίες θα εκτελούσαμε σε αυτούς με βάση το παλιό μοντέλο "one server = one task" και πόσα τέτοια εργασίες θα μπορούσαν να χρησιμοποιούν τον εξοπλισμό. Μέτρησαν και δάκρυσαν. Αποδείχθηκε ότι η αποτελεσματικότητά μας στη χρήση ραφιών είναι περίπου 11%. Το συμπέρασμα είναι προφανές: πρέπει να αυξήσουμε την αποτελεσματικότητα της χρήσης κέντρων δεδομένων. Φαίνεται ότι η λύση είναι προφανής: πρέπει να εκτελέσετε πολλές εργασίες σε έναν διακομιστή ταυτόχρονα. Εδώ όμως αρχίζουν τα δύσκολα.

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

Αλλά το κύριο πράγμα είναι ότι δεν υπάρχει απομόνωση μεταξύ εργασιών που εκτελούνται στο ίδιο μηχάνημα. Εδώ, για παράδειγμα, είναι ένα γράφημα του μέσου χρόνου απόκρισης μιας εργασίας διακομιστή πριν και μετά την εκκίνηση μιας άλλης υπολογιστικής εφαρμογής στον ίδιο διακομιστή, σε καμία περίπτωση που δεν σχετίζεται με την πρώτη - ο χρόνος απόκρισης της κύριας εργασίας έχει αυξηθεί σημαντικά.

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

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

Επιπλέον, ένα έτοιμο μητρώο και ετικέτες εικόνας στο Docker μας δίνουν έτοιμα πρωτόγονα για την έκδοση και την παράδοση κώδικα στην παραγωγή.

Το Docker, όπως και κάθε άλλη παρόμοια τεχνολογία, μας παρέχει κάποιο επίπεδο απομόνωσης κοντέινερ εκτός συσκευασίας. Για παράδειγμα, απομόνωση μνήμης - σε κάθε κοντέινερ δίνεται ένα όριο στη χρήση της μνήμης μηχανής, πέρα ​​από το οποίο δεν θα καταναλώνει. Μπορείτε επίσης να απομονώσετε κοντέινερ με βάση τη χρήση της CPU. Για εμάς, όμως, η τυπική μόνωση δεν ήταν αρκετή. Αλλά περισσότερα για αυτό παρακάτω.

Η απευθείας εκτέλεση κοντέινερ σε διακομιστές είναι μόνο ένα μέρος του προβλήματος. Το άλλο μέρος σχετίζεται με τη φιλοξενία κοντέινερ σε διακομιστές. Πρέπει να καταλάβετε ποιο κοντέινερ μπορεί να τοποθετηθεί σε ποιο διακομιστή. Αυτό δεν είναι τόσο εύκολο έργο, επειδή τα κοντέινερ πρέπει να τοποθετούνται σε διακομιστές όσο το δυνατόν πιο πυκνά χωρίς να μειώνεται η ταχύτητά τους. Μια τέτοια τοποθέτηση μπορεί επίσης να είναι δύσκολη από την άποψη της ανοχής σφαλμάτων. Συχνά θέλουμε να τοποθετήσουμε αντίγραφα της ίδιας υπηρεσίας σε διαφορετικά rack ή ακόμα και σε διαφορετικά δωμάτια του κέντρου δεδομένων, έτσι ώστε, εάν ένα rack ή δωμάτιο αποτύχει, να μην χάσουμε αμέσως όλα τα αντίγραφα της υπηρεσίας.

Η μη αυτόματη διανομή κοντέινερ δεν είναι επιλογή όταν έχετε 8 χιλιάδες διακομιστές και 8-16 χιλιάδες κοντέινερ.

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

Προφανώς, χρειαζόμαστε ένα επίπεδο ελέγχου που θα το έκανε αυτόματα.

Καταλήξαμε λοιπόν σε μια απλή και κατανοητή εικόνα που λατρεύουν όλοι οι αρχιτέκτονες: τρία τετράγωνα.

Το one-cloud masters είναι ένα σύμπλεγμα failover υπεύθυνο για την ενορχήστρωση του cloud. Ο προγραμματιστής στέλνει ένα μανιφέστο στον κύριο, το οποίο περιέχει όλες τις απαραίτητες πληροφορίες για τη φιλοξενία της υπηρεσίας. Με βάση αυτό, ο κύριος δίνει εντολές σε επιλεγμένα minions (μηχανήματα σχεδιασμένα να λειτουργούν κοντέινερ). Τα minions έχουν τον πράκτορά μας, ο οποίος λαμβάνει την εντολή, εκδίδει τις εντολές του στο Docker και ο Docker ρυθμίζει τον πυρήνα του linux για να εκκινήσει το αντίστοιχο κοντέινερ. Εκτός από την εκτέλεση εντολών, ο πράκτορας αναφέρει συνεχώς στον κύριο για αλλαγές στην κατάσταση τόσο της μηχανής minion όσο και των κοντέινερ που εκτελούνται σε αυτήν.

Κατανομή των πόρων

Τώρα ας δούμε το πρόβλημα της πιο περίπλοκης κατανομής πόρων για πολλά minions.

Ένας υπολογιστικός πόρος σε ένα σύννεφο είναι:

• Η ποσότητα ισχύος του επεξεργαστή που καταναλώνεται από μια συγκεκριμένη εργασία.
• Η ποσότητα μνήμης που είναι διαθέσιμη για την εργασία.
• Κυκλοφορία δικτύου. Κάθε ένα από τα minions έχει μια συγκεκριμένη διεπαφή δικτύου με περιορισμένο εύρος ζώνης, επομένως είναι αδύνατη η διανομή εργασιών χωρίς να ληφθεί υπόψη ο όγκος των δεδομένων που μεταδίδουν μέσω του δικτύου.
• Δίσκοι. Επιπλέον, προφανώς, στον χώρο για αυτές τις εργασίες, διαθέτουμε και τον τύπο του δίσκου: HDD ή SSD. Οι δίσκοι μπορούν να εξυπηρετήσουν έναν πεπερασμένο αριθμό αιτημάτων ανά δευτερόλεπτο - IOPS. Επομένως, για εργασίες που δημιουργούν περισσότερα IOPS από αυτά που μπορεί να χειριστεί ένας μεμονωμένος δίσκος, διαθέτουμε επίσης "άτρακτους" - δηλαδή συσκευές δίσκου που πρέπει να δεσμεύονται αποκλειστικά για την εργασία.

Στη συνέχεια, για κάποια υπηρεσία, για παράδειγμα για την προσωρινή μνήμη χρήστη, μπορούμε να καταγράψουμε τους πόρους που καταναλώνονται με αυτόν τον τρόπο: 400 πυρήνες επεξεργαστή, 2,5 TB μνήμης, κίνηση 50 Gbit/s και προς τις δύο κατευθύνσεις, 6 TB χώρου στον σκληρό δίσκο που βρίσκεται σε 100 άξονες . Ή με μια πιο γνωστή μορφή όπως αυτή:

alloc:
    cpu: 400
    mem: 2500
    lan_in: 50g
    lan_out: 50g
    hdd:100x6T

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

Ας επιστρέψουμε στο πολύ απλοποιημένο διάγραμμα της αλληλεπίδρασης των εξαρτημάτων και ας το σχεδιάσουμε ξανά με περισσότερες λεπτομέρειες - όπως αυτό:

Τι τραβάει τα βλέμματα:

• Η διεπαφή ιστού και η μουσική χρησιμοποιούν απομονωμένα συμπλέγματα του ίδιου διακομιστή εφαρμογών.
• Μπορούμε να διακρίνουμε τα λογικά επίπεδα στα οποία ανήκουν αυτά τα συμπλέγματα: μέτωπα, κρυφές μνήμες, επίπεδο αποθήκευσης και διαχείρισης δεδομένων.
• Το frontend είναι ετερογενές· αποτελείται από διαφορετικά λειτουργικά υποσυστήματα.
• Οι κρυφές μνήμες μπορούν επίσης να είναι διάσπαρτες στο υποσύστημα του οποίου τα δεδομένα αποθηκεύουν στην κρυφή μνήμη.

Ας ξανασχεδιάσουμε την εικόνα:

Μπα! Ναι, βλέπουμε μια ιεραρχία! Αυτό σημαίνει ότι μπορείτε να διανείμετε πόρους σε μεγαλύτερα κομμάτια: αντιστοιχίστε έναν υπεύθυνο προγραμματιστή σε έναν κόμβο αυτής της ιεραρχίας που αντιστοιχεί στο λειτουργικό υποσύστημα (όπως η "μουσική" στην εικόνα) και επισυνάψτε ένα όριο στο ίδιο επίπεδο της ιεραρχίας. Αυτή η ιεραρχία μας επιτρέπει επίσης να οργανώνουμε τις υπηρεσίες πιο ευέλικτα για ευκολία διαχείρισης. Για παράδειγμα, χωρίζουμε όλο τον ιστό, καθώς πρόκειται για μια πολύ μεγάλη ομαδοποίηση διακομιστών, σε πολλές μικρότερες ομάδες, που εμφανίζονται στην εικόνα ως group1, group2.

Αφαιρώντας τις επιπλέον γραμμές, μπορούμε να γράψουμε κάθε κόμβο της εικόνας μας σε πιο επίπεδη μορφή: group1.web.front, api.music.front, user-cache.cache.

Έτσι φτάνουμε στην έννοια της «ιεραρχικής ουράς». Έχει ένα όνομα όπως "group1.web.front". Το όριο για πόρους και δικαιώματα χρήστη έχει εκχωρηθεί σε αυτό. Θα δώσουμε στο άτομο από το DevOps τα δικαιώματα να στείλει μια υπηρεσία στην ουρά και ένας τέτοιος υπάλληλος μπορεί να ξεκινήσει κάτι στην ουρά και το άτομο από το OpsDev θα έχει δικαιώματα διαχειριστή και τώρα μπορεί να διαχειρίζεται την ουρά, να αναθέτει άτομα εκεί, δώστε σε αυτά τα άτομα δικαιώματα κ.λπ. Οι υπηρεσίες που εκτελούνται σε αυτήν την ουρά θα εκτελούνται εντός του ορίου της ουράς. Εάν το όριο υπολογισμού της ουράς δεν είναι αρκετό για να εκτελεστούν όλες οι υπηρεσίες ταυτόχρονα, τότε αυτές θα εκτελεστούν διαδοχικά, σχηματίζοντας έτσι την ίδια την ουρά.

Ας ρίξουμε μια πιο προσεκτική ματιά στις υπηρεσίες. Μια υπηρεσία έχει ένα πλήρως αναγνωρισμένο όνομα, το οποίο περιλαμβάνει πάντα το όνομα της ουράς. Στη συνέχεια, η μπροστινή υπηρεσία web θα έχει το όνομα ok-web.group1.web.front. Και θα καλείται η υπηρεσία διακομιστή εφαρμογών στην οποία έχει πρόσβαση ok-app.group1.web.front. Κάθε υπηρεσία έχει ένα μανιφέστο, το οποίο καθορίζει όλες τις απαραίτητες πληροφορίες για τοποθέτηση σε συγκεκριμένα μηχανήματα: πόσους πόρους καταναλώνει αυτή η εργασία, ποια διαμόρφωση απαιτείται για αυτήν, πόσα αντίγραφα πρέπει να υπάρχουν, ιδιότητες για τον χειρισμό αστοχιών αυτής της υπηρεσίας. Και αφού τοποθετηθεί η υπηρεσία απευθείας στα μηχανήματα, εμφανίζονται τα στιγμιότυπά της. Ονομάζονται επίσης με σαφήνεια - ως αριθμός παρουσίας και όνομα υπηρεσίας: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front,…

Αυτό είναι πολύ βολικό: κοιτάζοντας μόνο το όνομα του κοντέινερ που τρέχει, μπορούμε να μάθουμε αμέσως πολλά.

Τώρα ας ρίξουμε μια πιο προσεκτική ματιά στο τι εκτελούν πραγματικά αυτές οι περιπτώσεις: εργασίες.

Μαθήματα απομόνωσης εργασιών

Όλες οι εργασίες στο ΟΚ (και, πιθανώς, παντού) μπορούν να χωριστούν σε ομάδες:

• Εργασίες σύντομης καθυστέρησης - προτ. Για τέτοιες εργασίες και υπηρεσίες, η καθυστέρηση απόκρισης (λανθάνουσα κατάσταση) είναι πολύ σημαντική, πόσο γρήγορα θα επεξεργαστεί κάθε ένα από τα αιτήματα από το σύστημα. Παραδείγματα εργασιών: προσόψεις ιστού, κρυφές μνήμες, διακομιστές εφαρμογών, αποθήκευση OLTP κ.λπ.
• Προβλήματα υπολογισμού - παρτίδα. Εδώ, η ταχύτητα επεξεργασίας κάθε συγκεκριμένου αιτήματος δεν είναι σημαντική. Για αυτούς, είναι σημαντικό πόσους υπολογισμούς θα κάνει αυτή η εργασία σε μια συγκεκριμένη (μεγάλη) χρονική περίοδο (διακίνηση). Αυτές θα είναι οποιεσδήποτε εργασίες του MapReduce, Hadoop, μηχανικής εκμάθησης, στατιστικών.
• Εργασίες παρασκηνίου - αδράνεια. Για τέτοιες εργασίες, ούτε η καθυστέρηση ούτε η απόδοση είναι πολύ σημαντικά. Αυτό περιλαμβάνει διάφορες δοκιμές, μετεγκαταστάσεις, επανυπολογισμούς και μετατροπή δεδομένων από τη μια μορφή στην άλλη. Αφενός, μοιάζουν με τα υπολογισμένα, αφετέρου, δεν μας έχει σημασία πόσο γρήγορα ολοκληρώνονται.

Ας δούμε πώς τέτοιες εργασίες καταναλώνουν πόρους, για παράδειγμα, τον κεντρικό επεξεργαστή.

Εργασίες σύντομης καθυστέρησης. Μια τέτοια εργασία θα έχει ένα μοτίβο κατανάλωσης CPU παρόμοιο με αυτό:

Λαμβάνεται ένα αίτημα από τον χρήστη για επεξεργασία, η εργασία αρχίζει να χρησιμοποιεί όλους τους διαθέσιμους πυρήνες της CPU, την επεξεργάζεται, επιστρέφει μια απάντηση, περιμένει για το επόμενο αίτημα και σταματά. Έφτασε το επόμενο αίτημα - και πάλι επιλέξαμε ό,τι υπήρχε, το υπολογίσαμε και περιμένουμε το επόμενο.

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

alloc: cpu = 4 (max)

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

Εργασίες υπολογισμού. Το μοτίβο τους θα είναι ελαφρώς διαφορετικό:

Η μέση κατανάλωση πόρων CPU για τέτοιες εργασίες είναι αρκετά υψηλή. Συχνά θέλουμε μια εργασία υπολογισμού να ολοκληρωθεί σε ένα ορισμένο χρονικό διάστημα, επομένως πρέπει να δεσμεύσουμε τον ελάχιστο αριθμό επεξεργαστών που χρειάζεται, ώστε ολόκληρος ο υπολογισμός να ολοκληρωθεί σε αποδεκτό χρόνο. Ο τύπος κράτησής του θα μοιάζει με αυτό:

alloc: cpu = [1,*)

"Παρακαλώ τοποθετήστε το σε ένα minion όπου υπάρχει τουλάχιστον ένας ελεύθερος πυρήνας και μετά όσοι είναι, θα καταβροχθίσει τα πάντα."

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

Αλλά πώς να το κάνεις αυτό;

Αρχικά, ας δούμε το prod και την κατανομή του: cpu = 4. Πρέπει να κρατήσουμε τέσσερις πυρήνες. Στην εκτέλεση Docker αυτό μπορεί να γίνει με δύο τρόπους:

• Χρησιμοποιώντας την επιλογή --cpuset=1-4, δηλαδή να διαθέσετε τέσσερις συγκεκριμένους πυρήνες στο μηχάνημα στην εργασία.
• Χρήση --cpuquota=400_000 --cpuperiod=100_000, εκχωρήστε ένα όριο για το χρόνο του επεξεργαστή, δηλαδή υποδεικνύετε ότι κάθε 100 ms πραγματικού χρόνου η εργασία δεν καταναλώνει περισσότερο από 400 ms χρόνο επεξεργαστή. Λαμβάνονται οι ίδιοι τέσσερις πυρήνες.

Ποια όμως από αυτές τις μεθόδους είναι κατάλληλη;

Το cpuset φαίνεται αρκετά ελκυστικό. Η εργασία έχει τέσσερις αποκλειστικούς πυρήνες, πράγμα που σημαίνει ότι οι κρυφές μνήμες του επεξεργαστή θα λειτουργούν όσο το δυνατόν πιο αποτελεσματικά. Αυτό έχει επίσης ένα μειονέκτημα: θα έπρεπε να αναλάβουμε το έργο της διανομής υπολογισμών στους άφορτους πυρήνες του μηχανήματος αντί για το λειτουργικό σύστημα, και αυτό είναι μια μάλλον μη τετριμμένη εργασία, ειδικά αν προσπαθούμε να τοποθετήσουμε ομαδικές εργασίες σε ένα τέτοιο μηχανή. Οι δοκιμές έδειξαν ότι η επιλογή με ποσόστωση ταιριάζει καλύτερα εδώ: με αυτόν τον τρόπο το λειτουργικό σύστημα έχει μεγαλύτερη ελευθερία στην επιλογή του πυρήνα για την εκτέλεση της εργασίας την τρέχουσα στιγμή και ο χρόνος του επεξεργαστή κατανέμεται πιο αποτελεσματικά.

Ας μάθουμε πώς να κάνετε κρατήσεις στο Docker με βάση τον ελάχιστο αριθμό πυρήνων. Η ποσόστωση για ομαδικές εργασίες δεν ισχύει πλέον, γιατί δεν χρειάζεται να περιοριστεί το μέγιστο, αρκεί απλώς να εγγυηθεί το ελάχιστο. Και εδώ η επιλογή ταιριάζει καλά docker run --cpushares.

Συμφωνήσαμε ότι εάν μια παρτίδα απαιτεί εγγύηση για τουλάχιστον έναν πυρήνα, τότε το αναφέρουμε --cpushares=1024, και αν υπάρχουν τουλάχιστον δύο πυρήνες, τότε υποδεικνύουμε --cpushares=2048. Τα μερίδια Cpu δεν παρεμβαίνουν με κανέναν τρόπο στη διανομή του χρόνου του επεξεργαστή, εφόσον υπάρχει αρκετός. Έτσι, εάν το prod δεν χρησιμοποιεί αυτήν τη στιγμή και τους τέσσερις πυρήνες του, δεν υπάρχει τίποτα που να περιορίζει τις εργασίες παρτίδας και μπορούν να χρησιμοποιήσουν επιπλέον χρόνο επεξεργαστή. Αλλά σε μια κατάσταση όπου υπάρχει έλλειψη επεξεργαστών, εάν το prod έχει καταναλώσει και τους τέσσερις πυρήνες του και έχει φτάσει στο όριο του, ο υπολειπόμενος χρόνος επεξεργαστή θα διαιρεθεί αναλογικά με τα cpushares, δηλαδή σε μια κατάσταση τριών ελεύθερων πυρήνων, ο ένας θα είναι δίνεται σε μια εργασία με 1024 cpushares και τα υπόλοιπα δύο θα δοθούν σε μια εργασία με 2048 cpushares.

Αλλά η χρήση ποσοστώσεων και μετοχών δεν αρκεί. Πρέπει να βεβαιωθούμε ότι μια εργασία με μικρή καθυστέρηση λαμβάνει προτεραιότητα έναντι μιας ομαδικής εργασίας κατά την κατανομή του χρόνου του επεξεργαστή. Χωρίς αυτή την ιεράρχηση προτεραιοτήτων, η εργασία δέσμης θα καταλαμβάνει όλο το χρόνο του επεξεργαστή τη στιγμή που χρειάζεται από τον παραγωγό. Δεν υπάρχουν επιλογές ιεράρχησης κοντέινερ στην εκτέλεση Docker, αλλά οι πολιτικές χρονοπρογραμματισμού CPU Linux είναι χρήσιμες. Μπορείτε να διαβάσετε για αυτά λεπτομερώς εδώ, και στο πλαίσιο αυτού του άρθρου θα τα δούμε εν συντομία:

• SCHED_OTHER
  Από προεπιλογή, λαμβάνονται όλες οι κανονικές διεργασίες χρήστη σε μια μηχανή Linux.
• SCHED_BATCH
  Σχεδιασμένο για διαδικασίες έντασης πόρων. Κατά την τοποθέτηση μιας εργασίας σε έναν επεξεργαστή, εισάγεται μια λεγόμενη ποινή ενεργοποίησης: μια τέτοια εργασία είναι λιγότερο πιθανό να λάβει πόρους επεξεργαστή εάν αυτή τη στιγμή χρησιμοποιείται από μια εργασία με SCHED_OTHER
• SCHED_IDLE
  Μια διαδικασία παρασκηνίου με πολύ χαμηλή προτεραιότητα, ακόμη και χαμηλότερη από το ωραίο -19. Χρησιμοποιούμε τη βιβλιοθήκη ανοιχτού κώδικα ένα-νιό, προκειμένου να ορίσετε την απαραίτητη πολιτική κατά την εκκίνηση του κοντέινερ με κλήση

one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )

Αλλά ακόμα κι αν δεν προγραμματίζετε σε Java, το ίδιο πράγμα μπορεί να γίνει χρησιμοποιώντας την εντολή chrt:

chrt -i 0 $pid

Ας συνοψίσουμε όλα τα επίπεδα απομόνωσής μας σε έναν πίνακα για σαφήνεια:

Κατηγορία μόνωσης
Παράδειγμα κατανομής
Επιλογές εκτέλεσης Docker
sched_setscheduler chrt*

Prod
cpu = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

Batch
Cpu = [1, *)
--cpushares=1024
SCHED_BATCH

Idle
Cpu= [2, *)
--cpushares=2048
SCHED_IDLE

*Εάν κάνετε chrt μέσα από ένα κοντέινερ, μπορεί να χρειαστείτε τη δυνατότητα sys_nice, επειδή από προεπιλογή το Docker αφαιρεί αυτήν τη δυνατότητα κατά την εκκίνηση του κοντέινερ.

Αλλά οι εργασίες καταναλώνουν όχι μόνο τον επεξεργαστή, αλλά και την κίνηση, γεγονός που επηρεάζει τον λανθάνοντα χρόνο μιας εργασίας δικτύου ακόμη περισσότερο από την εσφαλμένη κατανομή των πόρων του επεξεργαστή. Επομένως, φυσικά θέλουμε να έχουμε ακριβώς την ίδια εικόνα για την κυκλοφορία. Δηλαδή, όταν μια εργασία παραγωγής στέλνει κάποια πακέτα στο δίκτυο, περιορίζουμε τη μέγιστη ταχύτητα (τύπος κατανομή: lan=[*,500mbps) ), με το οποίο ο παραγωγός μπορεί να το κάνει αυτό. Και για παρτίδες εγγυόμαστε μόνο την ελάχιστη απόδοση, αλλά δεν περιορίζουμε τη μέγιστη (τύπος κατανομή: lan=[10 Mbps,*) ) Σε αυτήν την περίπτωση, η κυκλοφορία προϊόντων θα πρέπει να έχει προτεραιότητα έναντι των εργασιών παρτίδας.
Εδώ το Docker δεν έχει κανένα πρωτόγονο που μπορούμε να χρησιμοποιήσουμε. Αλλά έρχεται σε βοήθειά μας Linux Traffic Control. Καταφέραμε να πετύχουμε το επιθυμητό αποτέλεσμα με τη βοήθεια της πειθαρχίας Ιεραρχική Καμπύλη Δίκαιης Υπηρεσίας. Με τη βοήθειά του, διακρίνουμε δύο κατηγορίες επισκεψιμότητας: υψηλής προτεραιότητας prod και χαμηλής προτεραιότητας batch/idle. Ως αποτέλεσμα, η διαμόρφωση για την εξερχόμενη κυκλοφορία έχει ως εξής:

Εδώ το 1:0 είναι το "root qdisc" της πειθαρχίας hsfc. 1:1 - θυγατρική τάξη hsfc με συνολικό όριο εύρους ζώνης 8 Gbit/s, κάτω από την οποία τοποθετούνται οι θυγατρικές κατηγορίες όλων των κοντέινερ. 1:2 - η θυγατρική τάξη hsfc είναι κοινή για όλες τις εργασίες παρτίδας και αδράνειας με ένα «δυναμικό» όριο, το οποίο συζητείται παρακάτω. Οι υπόλοιπες θυγατρικές τάξεις hsfc είναι αποκλειστικές κλάσεις για κοντέινερ προϊόντων που τρέχουν αυτήν τη στιγμή με όρια που αντιστοιχούν στις δηλώσεις τους - 450 και 400 Mbit/s. Σε κάθε κλάση hsfc εκχωρείται μια ουρά qdisc fq ή fq_codel, ανάλογα με την έκδοση του πυρήνα του Linux, για να αποφευχθεί η απώλεια πακέτων κατά τη διάρκεια εκρήξεων κίνησης.

Συνήθως, οι κλάδοι tc χρησιμεύουν για να δίνουν προτεραιότητα μόνο στην εξερχόμενη κίνηση. Θέλουμε, όμως, να δώσουμε προτεραιότητα στην εισερχόμενη επισκεψιμότητα - σε τελική ανάλυση, κάποια ομαδική εργασία μπορεί εύκολα να επιλέξει ολόκληρο το εισερχόμενο κανάλι, λαμβάνοντας, για παράδειγμα, μια μεγάλη παρτίδα δεδομένων εισόδου για χαρτογράφηση&μείωση. Για αυτό χρησιμοποιούμε το module ανβ, το οποίο δημιουργεί μια εικονική διεπαφή ifbX για κάθε διεπαφή δικτύου και ανακατευθύνει την εισερχόμενη κίνηση από τη διεπαφή στην εξερχόμενη κίνηση στο ifbX. Επιπλέον, για το ifbX, όλοι οι ίδιοι κλάδοι λειτουργούν για τον έλεγχο της εξερχόμενης κυκλοφορίας, για την οποία η διαμόρφωση hsfc θα είναι πολύ παρόμοια:

Κατά τη διάρκεια των πειραμάτων, ανακαλύψαμε ότι το hsfc δείχνει τα καλύτερα αποτελέσματα όταν η κατηγορία 1:2 της κυκλοφορίας χωρίς προτεραιότητα παρτίδας/αδράνειας περιορίζεται σε μηχανές minion σε όχι περισσότερο από μια συγκεκριμένη ελεύθερη λωρίδα. Διαφορετικά, η κίνηση χωρίς προτεραιότητα έχει υπερβολικό αντίκτυπο στον λανθάνοντα χρόνο των εργασιών παραγωγής. Το miniond καθορίζει την τρέχουσα ποσότητα ελεύθερου εύρους ζώνης κάθε δευτερόλεπτο, μετρώντας τη μέση κατανάλωση κίνησης όλων των εργασιών παραγωγής ενός δεδομένου minion και αφαιρώντας το από το εύρος ζώνης της διεπαφής δικτύου με μικρό περιθώριο, δηλ.

Οι ζώνες ορίζονται ανεξάρτητα για την εισερχόμενη και την εξερχόμενη κίνηση. Και σύμφωνα με τις νέες τιμές, το miniond επαναδιαμορφώνει το όριο κλάσης μη προτεραιότητας 1:2.

Έτσι, εφαρμόσαμε και τις τρεις κατηγορίες απομόνωσης: prod, batch και idle. Αυτές οι κατηγορίες επηρεάζουν σε μεγάλο βαθμό τα χαρακτηριστικά απόδοσης των εργασιών. Ως εκ τούτου, αποφασίσαμε να τοποθετήσουμε αυτό το χαρακτηριστικό στην κορυφή της ιεραρχίας, έτσι ώστε όταν κοιτάζετε το όνομα της ιεραρχικής ουράς να είναι αμέσως σαφές με τι έχουμε να κάνουμε:

Όλοι οι φίλοι μας ιστός и μουσική τα μέτωπα τοποθετούνται στη συνέχεια στην ιεραρχία υπό προτ. Για παράδειγμα, κάτω από παρτίδα, ας τοποθετήσουμε την υπηρεσία μουσικός κατάλογος, το οποίο συγκεντρώνει περιοδικά έναν κατάλογο κομματιών από ένα σύνολο αρχείων mp3 που ανεβαίνουν στην Odnoklassniki. Ένα παράδειγμα υπηρεσίας σε κατάσταση αδράνειας θα ήταν μετασχηματιστής μουσικής, το οποίο κανονικοποιεί το επίπεδο έντασης της μουσικής.

Με την αφαίρεση των επιπλέον γραμμών ξανά, μπορούμε να γράψουμε τα ονόματα των υπηρεσιών μας πιο επίπεδα προσθέτοντας την κλάση απομόνωσης εργασιών στο τέλος του πλήρους ονόματος υπηρεσίας: web.front.prod, catalog.music.batch, μετασχηματιστής.μουσική.αδράνεια.

Και τώρα, κοιτάζοντας το όνομα της υπηρεσίας, καταλαβαίνουμε όχι μόνο τη λειτουργία που εκτελεί, αλλά και την κλάση απομόνωσής της, που σημαίνει την κρισιμότητα της κ.λπ.

Όλα είναι υπέροχα, αλλά υπάρχει μια πικρή αλήθεια. Είναι αδύνατο να απομονωθούν πλήρως οι εργασίες που εκτελούνται σε ένα μηχάνημα.

Τι καταφέραμε να πετύχουμε: εάν η παρτίδα καταναλώνεται εντατικά μόνο Πόροι CPU, τότε ο ενσωματωμένος προγραμματιστής CPU Linux κάνει πολύ καλά τη δουλειά του και πρακτικά δεν υπάρχει καμία επίδραση στην εργασία παραγωγής. Αλλά αν αυτή η ομαδική εργασία αρχίσει να λειτουργεί ενεργά με τη μνήμη, τότε εμφανίζεται ήδη η αμοιβαία επιρροή. Αυτό συμβαίνει επειδή η εργασία παραγωγής "ξεπλένεται" από τις κρυφές μνήμες μνήμης του επεξεργαστή - ως αποτέλεσμα, οι ελλείψεις της προσωρινής μνήμης αυξάνονται και ο επεξεργαστής επεξεργάζεται την εργασία παραγωγής πιο αργά. Μια τέτοια εργασία παρτίδας μπορεί να αυξήσει τον λανθάνοντα χρόνο του τυπικού κοντέινερ παραγωγής μας κατά 10%.

Η απομόνωση της κυκλοφορίας είναι ακόμη πιο δύσκολη λόγω του γεγονότος ότι οι σύγχρονες κάρτες δικτύου έχουν μια εσωτερική ουρά πακέτων. Εάν το πακέτο από την εργασία δέσμης φτάσει εκεί πρώτο, τότε θα είναι το πρώτο που θα μεταδοθεί μέσω του καλωδίου και δεν μπορεί να γίνει τίποτα γι' αυτό.

Επιπλέον, μέχρι στιγμής έχουμε καταφέρει μόνο να λύσουμε το πρόβλημα της ιεράρχησης της κυκλοφορίας TCP: η προσέγγιση hsfc δεν λειτουργεί για το UDP. Και ακόμη και στην περίπτωση της κυκλοφορίας TCP, εάν η ομαδική εργασία δημιουργεί μεγάλη επισκεψιμότητα, αυτό δίνει επίσης περίπου 10% αύξηση στην καθυστέρηση της εργασίας παραγωγής.

ανοχή σε σφάλματα

Ένας από τους στόχους κατά την ανάπτυξη του one-cloud ήταν η βελτίωση της ανοχής σφαλμάτων της Odnoklassniki. Επομένως, στη συνέχεια θα ήθελα να εξετάσω λεπτομερέστερα πιθανά σενάρια αστοχιών και ατυχημάτων. Ας ξεκινήσουμε με ένα απλό σενάριο - μια αστοχία κοντέινερ.

Το ίδιο το δοχείο μπορεί να αποτύχει με διάφορους τρόπους. Αυτό θα μπορούσε να είναι κάποιο είδος πειράματος, σφάλμα ή σφάλμα στο μανιφέστο, λόγω του οποίου η εργασία παραγωγής αρχίζει να καταναλώνει περισσότερους πόρους από αυτούς που υποδεικνύονται στο μανιφέστο. Είχαμε μια περίπτωση: ένας προγραμματιστής εφάρμοσε έναν πολύπλοκο αλγόριθμο, τον ξαναδούλεψε πολλές φορές, σκέφτηκε τον εαυτό του και μπερδεύτηκε τόσο πολύ που τελικά το πρόβλημα πήγε σε έναν πολύ μη τετριμμένο βρόχο. Και δεδομένου ότι η εργασία παραγωγής έχει μεγαλύτερη προτεραιότητα από όλες τις άλλες στα ίδια minions, άρχισε να καταναλώνει όλους τους διαθέσιμους πόρους επεξεργαστή. Σε αυτήν την κατάσταση, η απομόνωση, ή μάλλον το όριο χρόνου της CPU, έσωσε την κατάσταση. Εάν σε μια εργασία εκχωρηθεί ποσόστωση, η εργασία δεν θα καταναλώσει περισσότερο. Επομένως, οι εργασίες παρτίδας και άλλες εργασίες παραγωγής που εκτελούνταν στο ίδιο μηχάνημα δεν παρατήρησαν τίποτα.

Το δεύτερο πιθανό πρόβλημα είναι η πτώση του δοχείου. Και εδώ οι πολιτικές επανεκκίνησης μας σώζουν, όλοι τις γνωρίζουν, ο ίδιος ο Docker κάνει εξαιρετική δουλειά. Σχεδόν όλες οι εργασίες παραγωγής έχουν μια πολιτική πάντα επανεκκίνησης. Μερικές φορές χρησιμοποιούμε το on_failure για ομαδικές εργασίες ή για εντοπισμό σφαλμάτων κοντέινερ προϊόντων.

Τι μπορείτε να κάνετε εάν ένα ολόκληρο minion δεν είναι διαθέσιμο;

Προφανώς, τρέξτε το δοχείο σε άλλο μηχάνημα. Το ενδιαφέρον μέρος εδώ είναι τι συμβαίνει με τις διευθύνσεις IP που έχουν εκχωρηθεί στο κοντέινερ.

Μπορούμε να εκχωρήσουμε σε κοντέινερ τις ίδιες διευθύνσεις IP με τις μηχανές minion στις οποίες λειτουργούν αυτά τα κοντέινερ. Στη συνέχεια, όταν το κοντέινερ εκκινείται σε άλλο μηχάνημα, η διεύθυνση IP του αλλάζει και όλοι οι πελάτες πρέπει να καταλάβουν ότι το κοντέινερ έχει μετακινηθεί και τώρα πρέπει να μεταβούν σε διαφορετική διεύθυνση, η οποία απαιτεί ξεχωριστή υπηρεσία εντοπισμού υπηρεσίας.

Το Service Discovery είναι βολικό. Υπάρχουν πολλές λύσεις στην αγορά διαφορετικών βαθμών ανοχής σφαλμάτων για την οργάνωση ενός μητρώου υπηρεσιών. Συχνά τέτοιες λύσεις εφαρμόζουν λογική εξισορρόπησης φορτίου, αποθηκεύουν πρόσθετες ρυθμίσεις με τη μορφή αποθήκευσης KV κ.λπ.
Ωστόσο, θα θέλαμε να αποφύγουμε την ανάγκη εφαρμογής ενός ξεχωριστού μητρώου, διότι αυτό θα σήμαινε την εισαγωγή ενός κρίσιμου συστήματος που χρησιμοποιείται από όλες τις υπηρεσίες στην παραγωγή. Αυτό σημαίνει ότι αυτό είναι ένα πιθανό σημείο αποτυχίας και πρέπει να επιλέξετε ή να αναπτύξετε μια πολύ ανεκτική λύση σε σφάλματα, η οποία είναι προφανώς πολύ δύσκολη, χρονοβόρα και δαπανηρή.

Και ένα ακόμη μεγάλο μειονέκτημα: για να λειτουργήσει η παλιά μας υποδομή με τη νέα, θα έπρεπε να ξαναγράψουμε όλες τις εργασίες για να χρησιμοποιήσουμε κάποιου είδους σύστημα Service Discovery. Υπάρχει ΠΟΛΛΗ δουλειά και σε ορισμένα σημεία είναι σχεδόν αδύνατο όταν πρόκειται για συσκευές χαμηλού επιπέδου που λειτουργούν σε επίπεδο πυρήνα λειτουργικού συστήματος ή απευθείας με το υλικό. Εφαρμογή αυτής της λειτουργικότητας χρησιμοποιώντας καθιερωμένα μοτίβα λύσεων, όπως π.χ αμάξι μοτοσυκλέττας θα σήμαινε σε ορισμένα σημεία ένα πρόσθετο φορτίο, σε άλλα - μια επιπλοκή της λειτουργίας και πρόσθετα σενάρια αστοχίας. Δεν θέλαμε να περιπλέκουμε τα πράγματα, γι' αυτό αποφασίσαμε να κάνουμε τη χρήση του Service Discovery προαιρετική.

Σε ένα σύννεφο, η IP ακολουθεί το κοντέινερ, δηλαδή κάθε στιγμιότυπο εργασίας έχει τη δική της διεύθυνση IP. Αυτή η διεύθυνση είναι "στατική": εκχωρείται σε κάθε περίπτωση όταν η υπηρεσία αποστέλλεται για πρώτη φορά στο cloud. Εάν μια υπηρεσία είχε διαφορετικό αριθμό παρουσιών κατά τη διάρκεια της ζωής της, τότε στο τέλος θα της εκχωρηθούν τόσες διευθύνσεις IP όσες υπήρχαν οι μέγιστες παρουσίες.

Στη συνέχεια, αυτές οι διευθύνσεις δεν αλλάζουν: εκχωρούνται μία φορά και συνεχίζουν να υπάρχουν καθ' όλη τη διάρκεια της υπηρεσίας στην παραγωγή. Οι διευθύνσεις IP ακολουθούν κοντέινερ σε όλο το δίκτυο. Εάν το κοντέινερ μεταφερθεί σε άλλο minion, τότε η διεύθυνση θα το ακολουθήσει.

Έτσι, η αντιστοίχιση ενός ονόματος υπηρεσίας στη λίστα διευθύνσεων IP της αλλάζει πολύ σπάνια. Αν κοιτάξετε ξανά τα ονόματα των παρουσιών υπηρεσιών που αναφέραμε στην αρχή του άρθρου (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod,…), θα παρατηρήσουμε ότι μοιάζουν με τα FQDN που χρησιμοποιούνται στο DNS. Αυτό είναι σωστό, για να αντιστοιχίσουμε τα ονόματα των παρουσιών υπηρεσιών στις διευθύνσεις IP τους, χρησιμοποιούμε το πρωτόκολλο DNS. Επιπλέον, αυτό το DNS επιστρέφει όλες τις δεσμευμένες διευθύνσεις IP όλων των κοντέινερ - τόσο σε λειτουργία όσο και σε διακοπή (ας πούμε ότι χρησιμοποιούνται τρία αντίγραφα και έχουμε δεσμευμένες πέντε διευθύνσεις εκεί - και οι πέντε θα επιστραφούν). Οι πελάτες, έχοντας λάβει αυτές τις πληροφορίες, θα προσπαθήσουν να δημιουργήσουν μια σύνδεση και με τα πέντε αντίγραφα - και έτσι να καθορίσουν αυτά που λειτουργούν. Αυτή η επιλογή για τον προσδιορισμό της διαθεσιμότητας είναι πολύ πιο αξιόπιστη· δεν περιλαμβάνει ούτε DNS ούτε Service Discovery, πράγμα που σημαίνει ότι δεν υπάρχουν δύσκολα προβλήματα προς επίλυση όσον αφορά τη διασφάλιση της συνάφειας των πληροφοριών και της ανοχής σφαλμάτων αυτών των συστημάτων. Επιπλέον, σε κρίσιμες υπηρεσίες από τις οποίες εξαρτάται η λειτουργία ολόκληρης της πύλης, δεν μπορούμε να χρησιμοποιήσουμε καθόλου DNS, αλλά απλώς να εισάγουμε διευθύνσεις IP στη διαμόρφωση.

Η υλοποίηση μιας τέτοιας μεταφοράς IP πίσω από κοντέινερ μπορεί να είναι μη τετριμμένη - και θα δούμε πώς λειτουργεί με το ακόλουθο παράδειγμα:

Ας υποθέσουμε ότι ο κύριος ενός σύννεφου δίνει την εντολή στο minion M1 να τρέξει 1.ok-web.group1.web.front.prod με διεύθυνση 1.1.1.1. Λειτουργεί στο minion ΠΟΥΛΙ, το οποίο διαφημίζει αυτήν τη διεύθυνση σε ειδικούς διακομιστές ανακλαστήρας διαδρομής. Οι τελευταίοι έχουν μια περίοδο λειτουργίας BGP με το υλικό δικτύου, στην οποία μεταφράζεται η διαδρομή της διεύθυνσης 1.1.1.1 στο M1. Το M1 δρομολογεί πακέτα μέσα στο κοντέινερ χρησιμοποιώντας Linux. Υπάρχουν τρεις διακομιστές ανακλαστήρα διαδρομής, καθώς αυτό είναι ένα πολύ κρίσιμο μέρος της υποδομής ενός νέφους - χωρίς αυτούς, το δίκτυο σε ένα σύννεφο δεν θα λειτουργήσει. Τα τοποθετούμε σε διαφορετικά rack, αν είναι δυνατόν σε διαφορετικά δωμάτια του κέντρου δεδομένων, για να μειώσουμε την πιθανότητα να αποτύχουν και τα τρία ταυτόχρονα.

Ας υποθέσουμε τώρα ότι η σύνδεση μεταξύ της κύριας μονάδας ενός σύννεφου και του Minion M1 έχει χαθεί. Η κύρια μονάδα ενός νέφους θα ενεργήσει τώρα με την υπόθεση ότι το M1 έχει αποτύχει εντελώς. Δηλαδή θα δώσει την εντολή στο M2 minion να εκτοξευτεί web.group1.web.front.prod με την ίδια διεύθυνση 1.1.1.1. Τώρα έχουμε δύο αντικρουόμενες διαδρομές στο δίκτυο για το 1.1.1.1: στο M1 και στο M2. Για να επιλύσουμε τέτοιες διενέξεις, χρησιμοποιούμε το Multi Exit Discriminator, το οποίο καθορίζεται στην ανακοίνωση BGP. Αυτός είναι ένας αριθμός που δείχνει το βάρος της διαφημιζόμενης διαδρομής. Μεταξύ των διαδρομών που βρίσκονται σε διένεξη, θα επιλεγεί η διαδρομή με τη χαμηλότερη τιμή MED. Η κύρια μονάδα ενός νέφους υποστηρίζει το MED ως αναπόσπαστο μέρος των διευθύνσεων IP του κοντέινερ. Για πρώτη φορά, η διεύθυνση γράφεται με ένα αρκετά μεγάλο MED = 1. Στην περίπτωση μιας τέτοιας μεταφοράς κοντέινερ έκτακτης ανάγκης, ο πλοίαρχος μειώνει το MED και το M000 θα λάβει ήδη την εντολή να διαφημίσει τη διεύθυνση 000 με MED = 2. Το στιγμιότυπο που τρέχει στο M1.1.1.1 θα παραμείνει σε αυτήν την περίπτωση δεν υπάρχει σύνδεση και η περαιτέρω μοίρα του μας ενδιαφέρει ελάχιστα μέχρι να αποκατασταθεί η σύνδεση με τον κύριο, όταν θα σταματήσει σαν παλιά λήψη.

Συντρίβει

Όλα τα συστήματα διαχείρισης κέντρων δεδομένων χειρίζονται πάντα με αποδεκτό τρόπο τις μικρές βλάβες. Η υπερχείλιση κοντέινερ είναι ο κανόνας σχεδόν παντού.

Ας δούμε πώς χειριζόμαστε μια έκτακτη ανάγκη, όπως μια διακοπή ρεύματος σε ένα ή περισσότερα δωμάτια ενός κέντρου δεδομένων.

Τι σημαίνει ένα ατύχημα για ένα σύστημα διαχείρισης κέντρου δεδομένων; Πρώτα απ 'όλα, πρόκειται για μια τεράστια αστοχία πολλών μηχανημάτων και το σύστημα ελέγχου πρέπει να μεταφέρει πολλά κοντέινερ ταυτόχρονα. Αλλά αν η καταστροφή είναι πολύ μεγάλης κλίμακας, τότε μπορεί να συμβεί ότι όλες οι εργασίες δεν μπορούν να ανακατανεμηθούν σε άλλα minions, επειδή η χωρητικότητα πόρων του κέντρου δεδομένων πέφτει κάτω από το 100% του φορτίου.

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

Τι μπορείτε να κάνετε για όλα αυτά;

Οι μαζικές μεταναστεύσεις σημαίνουν ότι υπάρχει μεγάλος αριθμός δραστηριοτήτων, μεταναστεύσεων και αναπτύξεων στην υποδομή. Καθεμία από τις μετεγκαταστάσεις μπορεί να χρειαστεί κάποιο χρόνο που απαιτείται για την παράδοση και την αποσυσκευασία εικόνων κοντέινερ σε minions, την εκκίνηση και την προετοιμασία κοντέινερ κ.λπ. Επομένως, είναι επιθυμητό να εκκινούνται πιο σημαντικές εργασίες πριν από λιγότερο σημαντικές.

Ας δούμε ξανά την ιεραρχία των υπηρεσιών που γνωρίζουμε και ας προσπαθήσουμε να αποφασίσουμε ποιες εργασίες θέλουμε να εκτελέσουμε πρώτα.

Φυσικά, αυτές είναι οι διεργασίες που εμπλέκονται άμεσα στην επεξεργασία των αιτημάτων των χρηστών, π.χ. Αυτό το υποδεικνύουμε με προτεραιότητα τοποθέτησης — έναν αριθμό που μπορεί να εκχωρηθεί στην ουρά. Εάν μια ουρά έχει μεγαλύτερη προτεραιότητα, οι υπηρεσίες της τοποθετούνται πρώτες.

Στο prod εκχωρούμε υψηλότερες προτεραιότητες, 0; σε παρτίδα - λίγο χαμηλότερα, 100. στο ρελαντί - ακόμη χαμηλότερα, 200. Οι προτεραιότητες εφαρμόζονται ιεραρχικά. Όλες οι εργασίες χαμηλότερα στην ιεραρχία θα έχουν αντίστοιχη προτεραιότητα. Εάν θέλουμε οι κρυφές μνήμες εντός του προϊόντος να εκκινούνται πριν από τα frontends, τότε εκχωρούμε προτεραιότητες στην κρυφή μνήμη = 0 και στις μπροστινές υποουρές = 1. Εάν, για παράδειγμα, θέλουμε η κύρια πύλη να εκκινηθεί πρώτα από τα μπροστινά μέρη και μόνο το μέτωπο της μουσικής τότε, τότε μπορούμε να εκχωρήσουμε χαμηλότερη προτεραιότητα στο τελευταίο - 10.

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

Σε αντίθεση με την προτεραιότητα τοποθέτησης, δεν μπορούμε να θυσιάσουμε αδιακρίτως όλες τις εργασίες παρτίδας· ορισμένες από αυτές είναι σημαντικές για τη λειτουργία της πύλης. Ως εκ τούτου, έχουμε επισημάνει ξεχωριστά προτεραιότητα προκαταβολής καθήκοντα. Όταν τοποθετηθεί, μια εργασία υψηλότερης προτεραιότητας μπορεί να προδικάσει, δηλαδή να σταματήσει, μια εργασία χαμηλότερης προτεραιότητας, εάν δεν υπάρχουν περισσότερα δωρεάν minions. Σε αυτήν την περίπτωση, μια εργασία χαμηλής προτεραιότητας πιθανότατα θα παραμείνει αδιάθετη, δηλαδή δεν θα υπάρχει πλέον ένα κατάλληλο minion για αυτό με αρκετούς ελεύθερους πόρους.

Στην ιεραρχία μας, είναι πολύ απλό να ορίσουμε μια προτεραιότητα προκοπής, έτσι ώστε οι εργασίες προώθησης και παρτίδας να προλαμβάνουν ή να διακόπτουν τις εργασίες αδράνειας, αλλά όχι η μία την άλλη, ορίζοντας μια προτεραιότητα για την αδράνεια ίση με 200. Όπως και στην περίπτωση της προτεραιότητας τοποθέτησης, μπορεί να χρησιμοποιήσει την ιεραρχία μας για να περιγράψει πιο σύνθετους κανόνες. Για παράδειγμα, ας υποδείξουμε ότι θυσιάζουμε τη λειτουργία μουσικής εάν δεν έχουμε αρκετούς πόρους για την κύρια διαδικτυακή πύλη, θέτοντας την προτεραιότητα για τους αντίστοιχους κόμβους χαμηλότερα: 10.

Ολόκληρα ατυχήματα DC

Γιατί μπορεί να αποτύχει ολόκληρο το κέντρο δεδομένων; Στοιχείο. Ήταν μια καλή ανάρτηση ο τυφώνας επηρέασε το έργο του κέντρου δεδομένων. Τα στοιχεία μπορούν να θεωρηθούν άστεγοι που κάποτε έκαψαν τα οπτικά στοιχεία στην πολλαπλή και το κέντρο δεδομένων έχασε εντελώς την επαφή με άλλους ιστότοπους. Η αιτία της αποτυχίας μπορεί επίσης να είναι ένας ανθρώπινος παράγοντας: ο χειριστής θα εκδώσει μια τέτοια εντολή ώστε ολόκληρο το κέντρο δεδομένων να πέσει. Αυτό μπορεί να συμβεί λόγω ενός μεγάλου σφάλματος. Γενικά, η κατάρρευση των κέντρων δεδομένων δεν είναι ασυνήθιστη. Αυτό μας συμβαίνει μια φορά κάθε λίγους μήνες.

Και αυτό κάνουμε για να εμποδίσουμε οποιονδήποτε να κάνει tweet #live.

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

Αυτή η προσέγγιση όχι μόνο προστατεύει από φυσική αστοχία, αλλά μπορεί επίσης να προστατεύσει από σφάλματα χειριστή.

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

Αποτελέσματα της

Χαρακτηριστικά του one-cloud:

• Ιεραρχικό και οπτικό σχήμα ονοματοδοσίας για υπηρεσίες και κοντέινερ, το οποίο σας επιτρέπει να μάθετε πολύ γρήγορα ποια είναι η εργασία, με τι σχετίζεται και πώς λειτουργεί και ποιος είναι υπεύθυνος για αυτήν.
• Εφαρμόζουμε το δικό μας τεχνική συνδυασμού παραγωγής και παρτίδαςεργασίες σε minions για τη βελτίωση της αποτελεσματικότητας της κοινής χρήσης μηχανών. Αντί για cpuset χρησιμοποιούμε ποσοστώσεις CPU, κοινόχρηστα στοιχεία, πολιτικές προγραμματισμού CPU και QoS Linux.
• Δεν ήταν δυνατό να απομονωθούν πλήρως τα κοντέινερ που λειτουργούσαν στο ίδιο μηχάνημα, αλλά η αμοιβαία επιρροή τους παραμένει εντός 20%.
• Η οργάνωση των υπηρεσιών σε μια ιεραρχία βοηθά στην αυτόματη ανάκτηση από καταστροφές χρησιμοποιώντας προτεραιότητες τοποθέτησης και προκαταβολής.

Συχνές ερωτήσεις

Γιατί δεν πήραμε μια έτοιμη λύση;

• Διαφορετικές κατηγορίες απομόνωσης εργασιών απαιτούν διαφορετική λογική όταν τοποθετούνται σε minions. Εάν οι εργασίες παραγωγής μπορούν να τοποθετηθούν απλώς δεσμεύοντας πόρους, τότε πρέπει να τοποθετηθούν εργασίες παρτίδας και αδράνειας, παρακολουθώντας την πραγματική χρήση των πόρων σε μηχανές minion.
• Η ανάγκη να λαμβάνονται υπόψη οι πόροι που καταναλώνονται από εργασίες, όπως:
  • Εύρος ζώνης δικτύου?
  • τύπους και «άξονες» δίσκων.
• Η ανάγκη να υποδεικνύονται οι προτεραιότητες των υπηρεσιών κατά την απόκριση έκτακτης ανάγκης, τα δικαιώματα και οι ποσοστώσεις εντολών για πόρους, η οποία επιλύεται χρησιμοποιώντας ιεραρχικές ουρές σε ένα σύννεφο.
• Η ανάγκη να υπάρχει ανθρώπινη ονομασία των εμπορευματοκιβωτίων για να μειωθεί ο χρόνος απόκρισης σε ατυχήματα και συμβάντα
• Η αδυναμία μιας εφάπαξ ευρείας εφαρμογής του Service Discovery. την ανάγκη συνύπαρξης για μεγάλο χρονικό διάστημα με εργασίες που φιλοξενούνται σε κεντρικούς υπολογιστές υλικού - κάτι που λύνεται με «στατικές» διευθύνσεις IP που ακολουθούν τα κοντέινερ και, κατά συνέπεια, η ανάγκη για μοναδική ενοποίηση με μια μεγάλη υποδομή δικτύου.

Όλες αυτές οι λειτουργίες θα απαιτούσαν σημαντικές τροποποιήσεις των υπαρχουσών λύσεων για να μας ταιριάζουν και, έχοντας αξιολογήσει τον όγκο της εργασίας, συνειδητοποιήσαμε ότι μπορούσαμε να αναπτύξουμε τη δική μας λύση με περίπου το ίδιο κόστος εργασίας. Αλλά η λύση σας θα είναι πολύ πιο εύκολη στη λειτουργία και την ανάπτυξη - δεν περιέχει περιττές αφαιρέσεις που υποστηρίζουν λειτουργικότητα που δεν χρειαζόμαστε.

Σε όσους διάβασαν τις τελευταίες γραμμές, σας ευχαριστώ για την υπομονή και την προσοχή σας!

Πηγή: www.habr.com