Tupperware: Ο δολοφόνος των Kubernetes του Facebook;

Αποτελεσματική και αξιόπιστη διαχείριση συμπλεγμάτων σε οποιαδήποτε κλίμακα με το Tupperware

Tupperware: Ο δολοφόνος των Kubernetes του Facebook;

Σήμερα στις Συνέδριο Systems@Scale παρουσιάσαμε το Tupperware, το σύστημα διαχείρισης συμπλεγμάτων μας που ενορχηστρώνει κοντέινερ σε εκατομμύρια διακομιστές που εκτελούν σχεδόν όλες τις υπηρεσίες μας. Εγκαταστήσαμε για πρώτη φορά την Tupperware το 2011 και από τότε η υποδομή μας έχει αναπτυχθεί 1 κέντρο δεδομένων έως ολόκληρο 15 γεωδιανεμημένα κέντρα δεδομένων. Όλο αυτό το διάστημα, η Tupperware δεν έμεινε ακίνητη και αναπτύχθηκε μαζί μας. Θα σας δείξουμε πώς η Tupperware παρέχει διαχείριση συμπλέγματος πρώτης κατηγορίας, συμπεριλαμβανομένης της βολικής υποστήριξης για κρατικές υπηρεσίες, ενός ενιαίου πίνακα ελέγχου για όλα τα κέντρα δεδομένων και της δυνατότητας διανομής χωρητικότητας μεταξύ υπηρεσιών σε πραγματικό χρόνο. Θα μοιραστούμε επίσης τα μαθήματα που μάθαμε καθώς εξελίσσεται η υποδομή μας.

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

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

Αρχιτεκτονική Tupperware

Tupperware: Ο δολοφόνος των Kubernetes του Facebook;

Η αρχιτεκτονική PRN της Tupperware είναι μια από τις περιοχές των κέντρων δεδομένων μας. Η περιοχή αποτελείται από πολλά κτίρια κέντρων δεδομένων (PRN1 και PRN2) που βρίσκονται κοντά. Σκοπεύουμε να δημιουργήσουμε έναν πίνακα ελέγχου που θα διαχειρίζεται όλους τους διακομιστές σε μία περιοχή.

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

Η Tupperware είναι υπεύθυνη για την παροχή δοχείων και τη διαχείριση του κύκλου ζωής τους. Αποτελείται από πολλά συστατικά:

  • Το frontend του Tupperware παρέχει API για τη διεπαφή χρήστη, το CLI και άλλα εργαλεία αυτοματισμού μέσω των οποίων μπορείτε να αλληλεπιδράσετε με το Tupperware. Κρύβουν ολόκληρη την εσωτερική δομή από τους ιδιοκτήτες θέσεων εργασίας της Tupperware.
  • Το Tupperware Scheduler είναι ένας πίνακας ελέγχου υπεύθυνος για τη διαχείριση του κοντέινερ και του κύκλου ζωής της εργασίας. Αναπτύσσεται σε περιφερειακό και παγκόσμιο επίπεδο, όπου ο περιφερειακός προγραμματιστής διαχειρίζεται διακομιστές σε μια περιοχή και ο παγκόσμιος προγραμματιστής διαχειρίζεται διακομιστές από διαφορετικές περιοχές. Ο προγραμματιστής χωρίζεται σε θραύσματα και κάθε θραύσμα διαχειρίζεται ένα σύνολο εργασιών.
  • Ο διακομιστής μεσολάβησης Scheduler της Tupperware αποκρύπτει τον εσωτερικό διαμοιρασμό και παρέχει ένα βολικό μονό τζάμι για τους χρήστες του Tupperware.
  • Ο εκχωρητής Tupperware εκχωρεί κοντέινερ σε διακομιστές. Ο προγραμματιστής χειρίζεται τη διακοπή, την εκκίνηση, την ενημέρωση και την αποτυχία των κοντέινερ. Επί του παρόντος, ένας κατανεμητής μπορεί να διαχειριστεί ολόκληρη την περιοχή χωρίς να χωριστεί σε θραύσματα. (Σημειώστε τη διαφορά στην ορολογία. Για παράδειγμα, ο προγραμματιστής στο Tupperware αντιστοιχεί στον πίνακα ελέγχου στο Kubernetes, και ο εκχωρητής Tupperware ονομάζεται προγραμματιστής στο Kubernetes.)
  • Ο μεσίτης πόρων αποθηκεύει την πηγή της αλήθειας για τα συμβάντα διακομιστή και υπηρεσίας. Εκτελούμε έναν μεσίτη πόρων για κάθε κέντρο δεδομένων και αποθηκεύει όλες τις πληροφορίες σχετικά με τους διακομιστές σε αυτό το κέντρο δεδομένων. Ο μεσίτης πόρων και το σύστημα διαχείρισης χωρητικότητας, ή το σύστημα παροχής πόρων, αποφασίζουν δυναμικά ποιος προγραμματιστής παράδοσης ελέγχει ποιον διακομιστή. Η υπηρεσία ελέγχου υγείας παρακολουθεί τους διακομιστές και αποθηκεύει δεδομένα σχετικά με την υγεία τους στον μεσίτη πόρων. Εάν ένας διακομιστής έχει προβλήματα ή χρειάζεται συντήρηση, ο μεσίτης πόρων λέει στον εκχωρητή και τον προγραμματιστή να σταματήσουν τα κοντέινερ ή να τα μετακινήσουν σε άλλους διακομιστές.
  • Το Tupperware Agent είναι ένας δαίμονας που τρέχει σε κάθε διακομιστή που προετοιμάζει και αφαιρεί κοντέινερ. Οι εφαρμογές τρέχουν μέσα σε ένα δοχείο, το οποίο τους δίνει μεγαλύτερη απομόνωση και αναπαραγωγιμότητα. Επί το περσινό συνέδριο Systems @Scale Έχουμε ήδη περιγράψει πώς δημιουργούνται μεμονωμένα κοντέινερ Tupperware χρησιμοποιώντας εικόνες, btrfs, cgroupv2 και systemd.

Διακριτικά χαρακτηριστικά του Tupperware

Το Tupperware είναι παρόμοιο από πολλές απόψεις με άλλα συστήματα διαχείρισης συμπλέγματος όπως τα Kubernetes και Μέσος, αλλά υπάρχουν και διαφορές:

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

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

Ενσωματωμένη υποστήριξη για κρατικές υπηρεσίες.

Η Tupperware λειτουργεί μια ποικιλία κρίσιμων κρατικών υπηρεσιών που αποθηκεύουν μόνιμα δεδομένα προϊόντων για το Facebook, το Instagram, το Messenger και το WhatsApp. Αυτά θα μπορούσαν να είναι μεγάλα καταστήματα ζευγών κλειδιών-τιμών (π.χ. ZippyDB) και παρακολούθηση των αποθετηρίων δεδομένων (για παράδειγμα, ODS Gorilla и Scuba). Η διατήρηση κρατικών υπηρεσιών δεν είναι εύκολη, επειδή το σύστημα πρέπει να διασφαλίζει ότι η παροχή εμπορευματοκιβωτίων μπορεί να αντέξει μεγάλης κλίμακας διακοπές, συμπεριλαμβανομένων διακοπών δικτύου ή διακοπών ρεύματος. Και ενώ οι συμβατικές τεχνικές, όπως η διανομή κοντέινερ σε τομείς σφαλμάτων, λειτουργούν καλά για υπηρεσίες χωρίς πολιτεία, οι κρατικές υπηρεσίες χρειάζονται πρόσθετη υποστήριξη.

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

Η διεπαφή TaskControl επιτρέπει στις κρατικές υπηρεσίες να επηρεάζουν αποφάσεις που επηρεάζουν τη διαθεσιμότητα δεδομένων. Χρησιμοποιώντας αυτήν τη διεπαφή, ο προγραμματιστής ειδοποιεί τις εξωτερικές εφαρμογές σχετικά με τις λειτουργίες του κοντέινερ (επανεκκίνηση, ενημέρωση, μετεγκατάσταση, συντήρηση). Μια υπηρεσία κατάστασης υλοποιεί έναν ελεγκτή που ενημερώνει την Tupperware πότε είναι ασφαλές να εκτελεστεί κάθε λειτουργία και αυτές οι λειτουργίες μπορούν να αντικατασταθούν ή να καθυστερήσουν προσωρινά. Στο παραπάνω παράδειγμα, ο ελεγκτής βάσης δεδομένων θα μπορούσε να πει στην Tupperware να ενημερώσει 49 από τους 50 διακομιστές, αλλά να αφήσει μόνο έναν συγκεκριμένο διακομιστή (X) προς το παρόν. Ως αποτέλεσμα, εάν παρέλθει η περίοδος ενημέρωσης του πυρήνα και η βάση δεδομένων εξακολουθεί να μην μπορεί να επαναφέρει το προβληματικό αντίγραφο, η Tupperware θα συνεχίσει να ενημερώνει τον διακομιστή X.

Tupperware: Ο δολοφόνος των Kubernetes του Facebook;

Πολλές κρατικές υπηρεσίες στο Tupperware χρησιμοποιούν το TaskControl όχι απευθείας, αλλά μέσω του ShardManager, μιας κοινής πλατφόρμας για τη δημιουργία κρατικών υπηρεσιών στο Facebook. Με το Tupperware, οι προγραμματιστές μπορούν να προσδιορίσουν την πρόθεσή τους για το πώς ακριβώς θα πρέπει να διανέμονται τα κοντέινερ στα κέντρα δεδομένων. Με το ShardManager, οι προγραμματιστές προσδιορίζουν την πρόθεσή τους για τον τρόπο διανομής των θραυσμάτων δεδομένων σε κοντέινερ. Το ShardManager γνωρίζει την τοποθέτηση δεδομένων και την αναπαραγωγή των εφαρμογών του και επικοινωνεί με την Tupperware μέσω της διεπαφής TaskControl για να προγραμματίσει λειτουργίες κοντέινερ χωρίς άμεση συμμετοχή της εφαρμογής. Αυτή η ενοποίηση απλοποιεί σημαντικά τη διαχείριση κρατικών υπηρεσιών, αλλά το TaskControl μπορεί να κάνει περισσότερα. Για παράδειγμα, η εκτεταμένη βαθμίδα ιστού μας είναι ανύπαρκτος και χρησιμοποιεί το TaskControl για να προσαρμόζει δυναμικά τον ρυθμό των ενημερώσεων στα κοντέινερ. Τελικά το επίπεδο Ιστού είναι ικανό να ολοκληρώσει γρήγορα πολλές εκδόσεις λογισμικού ανά ημέρα χωρίς συμβιβασμούς στη διαθεσιμότητα.

Διαχείριση διακομιστών σε κέντρα δεδομένων

Όταν το Tupperware κυκλοφόρησε για πρώτη φορά το 2011, κάθε σύμπλεγμα διακομιστών διαχειριζόταν ξεχωριστός προγραμματιστής. Τότε, ένα σύμπλεγμα Facebook ήταν μια ομάδα ραφιών διακομιστών συνδεδεμένων σε έναν διακόπτη δικτύου και το κέντρο δεδομένων στέγαζε πολλά συμπλέγματα. Ο προγραμματιστής μπορούσε να διαχειρίζεται διακομιστές μόνο σε ένα σύμπλεγμα, που σημαίνει ότι η εργασία δεν μπορούσε να εξαπλωθεί σε πολλά συμπλέγματα. Η υποδομή μας μεγάλωσε, διαγράψαμε όλο και περισσότερο τα clusters. Δεδομένου ότι η Tupperware δεν μπορούσε να μετακινήσει την εργασία από το παροπλισμένο σύμπλεγμα σε άλλα συμπλέγματα χωρίς αλλαγές, απαιτούσε πολλή προσπάθεια και προσεκτικό συντονισμό μεταξύ των προγραμματιστών εφαρμογών και των χειριστών κέντρων δεδομένων. Αυτή η διαδικασία είχε ως αποτέλεσμα τη σπατάλη πόρων όταν οι διακομιστές ήταν σε αδράνεια για μήνες λόγω διαδικασιών παροπλισμού.

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

Επεκτάσιμο για την υποστήριξη ολόκληρου του παγκόσμιου συστήματος

Ιστορικά, η υποδομή μας έχει χωριστεί σε εκατοντάδες αποκλειστικές ομάδες διακομιστών για μεμονωμένες ομάδες. Λόγω κατακερματισμού και έλλειψης προτύπων, είχαμε υψηλό λειτουργικό κόστος και οι αδρανείς διακομιστές ήταν πιο δύσκολο να χρησιμοποιηθούν ξανά. Στο περσινό συνέδριο Συστήματα @Scale παρουσιάσαμε υποδομή ως υπηρεσία (IaaS), το οποίο θα πρέπει να ενώσει την υποδομή μας σε ένα μεγάλο ενιαίο πάρκο διακομιστών. Αλλά ένα μεμονωμένο πάρκο διακομιστή έχει τις δικές του δυσκολίες. Πρέπει να πληροί ορισμένες απαιτήσεις:

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

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

Βελτιώστε την αποδοτικότητα χρήσης με Elastic Computing

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

  • Elastic computing - μειώστε τις διαδικτυακές υπηρεσίες κατά τις ώρες ησυχίας και χρησιμοποιήστε διακομιστές που έχουν ελευθερωθεί για φόρτους εργασίας εκτός σύνδεσης, όπως η μηχανική εκμάθηση και οι εργασίες MapReduce.
  • Υπερφόρτωση - Τοποθετήστε τις διαδικτυακές υπηρεσίες και τους ομαδικούς φόρτους εργασίας στους ίδιους διακομιστές, έτσι ώστε οι μαζικοί φόρτοι εργασίας να εκτελούνται σε χαμηλή προτεραιότητα.

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


Βασικά, βελτιώνουμε την αποδοτικότητα χρήσης χρησιμοποιώντας ελαστικούς υπολογιστές. Πολλές από τις κύριες υπηρεσίες μας, όπως η Ροή ειδήσεων, η δυνατότητα ανταλλαγής μηνυμάτων και το επίπεδο web front-end, ποικίλλουν ανάλογα με την ώρα της ημέρας. Μειώνουμε σκόπιμα τις διαδικτυακές υπηρεσίες σε ώρες ησυχίας και χρησιμοποιούμε δωρεάν διακομιστές για φόρτους εργασίας εκτός σύνδεσης, όπως η μηχανική εκμάθηση και οι εργασίες MapReduce.

Tupperware: Ο δολοφόνος των Kubernetes του Facebook;

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

Διδάγματα και σχέδια για το μέλλον

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

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

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

Πηγή: www.habr.com

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