Load Balancing στο Openstack (Μέρος 2)

В τελευταίο άρθρο μιλήσαμε για τις προσπάθειές μας να χρησιμοποιήσουμε το Watcher και παρείχαμε μια αναφορά δοκιμής. Πραγματοποιούμε περιοδικά τέτοιες δοκιμές για εξισορρόπηση και άλλες κρίσιμες λειτουργίες ενός cloud μεγάλης επιχείρησης ή χειριστή.

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

Κάποια ορολογία

Η εταιρεία VmWare παρουσίασε το βοηθητικό πρόγραμμα DRS (Distributed Resource Scheduler) για να εξισορροπήσει το φόρτο του περιβάλλοντος εικονικοποίησης που ανέπτυξε και πρόσφερε.

Όπως γράφει searchvmware.techtarget.com/definition/VMware-DRS
«Το VMware DRS (Distributed Resource Scheduler) είναι ένα βοηθητικό πρόγραμμα που εξισορροπεί τα υπολογιστικά φορτία με τους διαθέσιμους πόρους σε ένα εικονικό περιβάλλον. Το βοηθητικό πρόγραμμα είναι μέρος μιας σουίτας εικονικοποίησης που ονομάζεται VMware Infrastructure.

Με το VMware DRS, οι χρήστες ορίζουν κανόνες για τη διανομή φυσικών πόρων μεταξύ εικονικών μηχανών (VM). Το βοηθητικό πρόγραμμα μπορεί να διαμορφωθεί για χειροκίνητο ή αυτόματο έλεγχο. Οι ομάδες πόρων VMware μπορούν εύκολα να προστεθούν, να αφαιρεθούν ή να αναδιοργανωθούν. Εάν είναι επιθυμητό, ​​οι ομάδες πόρων μπορούν να απομονωθούν μεταξύ διαφορετικών επιχειρηματικών μονάδων. Εάν ο φόρτος εργασίας σε μία ή περισσότερες εικονικές μηχανές αλλάξει δραματικά, το VMware DRS ανακατανέμει τις εικονικές μηχανές σε φυσικούς διακομιστές. Εάν ο συνολικός φόρτος εργασίας μειωθεί, ορισμένοι φυσικοί διακομιστές ενδέχεται να τεθούν προσωρινά εκτός σύνδεσης και ο φόρτος εργασίας να ενοποιηθεί."

Γιατί χρειάζεται εξισορρόπηση;


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

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

Ιδιωτικά σύννεφα / Πελάτες μεγάλων επιχειρήσεων
Δημόσια σύννεφα / Μεσαίες και μικρές επιχειρήσεις, άνθρωποι

Το κύριο κριτήριο και οι στόχοι του χειριστή
Παροχή αξιόπιστης υπηρεσίας ή προϊόντος
Μείωση του κόστους των υπηρεσιών στον αγώνα σε μια ανταγωνιστική αγορά

Απαιτήσεις υπηρεσιών
Αξιοπιστία σε όλα τα επίπεδα και σε όλα τα στοιχεία του συστήματος

Εγγυημένη απόδοση

Δώστε προτεραιότητα στις εικονικές μηχανές σε διάφορες κατηγορίες 

Ασφάλεια πληροφοριών και φυσικών δεδομένων

SLA και υποστήριξη XNUMX/XNUMX
Μέγιστη ευκολία λήψης της υπηρεσίας

Σχετικά απλές υπηρεσίες

Η ευθύνη για τα δεδομένα ανήκει στον πελάτη

Δεν απαιτείται ιεράρχηση VM

Ασφάλεια πληροφοριών σε επίπεδο τυπικών υπηρεσιών, ευθύνη στον πελάτη

Μπορεί να υπάρχουν δυσλειτουργίες

Χωρίς SLA, η ποιότητα δεν είναι εγγυημένη

Υποστήριξη μέσω email

Η δημιουργία αντιγράφων ασφαλείας δεν είναι απαραίτητη

Χαρακτηριστικά πελάτη
Πολύ μεγάλη γκάμα εφαρμογών.

Εφαρμογές παλαιού τύπου που κληρονομήθηκαν στην εταιρεία.

Πολύπλοκες προσαρμοσμένες αρχιτεκτονικές για κάθε πελάτη.

Κανόνες συγγένειας.

Το λογισμικό λειτουργεί χωρίς διακοπή σε λειτουργία 7x24. 

Εργαλεία δημιουργίας αντιγράφων ασφαλείας on-the-fly.

Προβλέψιμο κυκλικό φορτίο πελατών.
Τυπικές εφαρμογές – εξισορρόπηση δικτύου, Apache, WEB, VPN, SQL

Η εφαρμογή μπορεί να σταματήσει για λίγο

Επιτρέπει την αυθαίρετη διανομή των VM στο cloud

Δημιουργία αντιγράφων ασφαλείας πελάτη

Προβλέψιμο στατιστικά μέσο φόρτο με μεγάλο αριθμό πελατών.

Επιπτώσεις για την αρχιτεκτονική
Γεωσύνθεση

Κεντρική ή κατανεμημένη αποθήκευση

Διατηρήθηκε IBS
Τοπική αποθήκευση δεδομένων σε κόμβους υπολογιστών

Εξισορρόπηση Στόχων
Ομοιόμορφη κατανομή φορτίου

Μέγιστη ανταπόκριση εφαρμογής 

Ελάχιστος χρόνος καθυστέρησης για την εξισορρόπηση

Εξισορρόπηση μόνο όταν είναι σαφώς απαραίτητο

Βγάζοντας λίγο εξοπλισμό για προληπτική συντήρηση
Μείωση του κόστους υπηρεσιών και του κόστους χειριστή 

Απενεργοποίηση ορισμένων πόρων σε περίπτωση χαμηλού φορτίου

Εξοικονόμησης ενέργειας

Μείωση του κόστους προσωπικού

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

Για ιδιωτικά σύννεφαπου παρέχεται σε μεγάλους εταιρικούς πελάτες, το DRS μπορεί να χρησιμοποιηθεί υπό τους ακόλουθους περιορισμούς:

  • ασφάλεια πληροφοριών και λαμβάνοντας υπόψη τους κανόνες συγγένειας κατά την εξισορρόπηση·
  • διαθεσιμότητα επαρκών πόρων σε αποθεματικό σε περίπτωση ατυχήματος·
  • τα δεδομένα εικονικής μηχανής βρίσκονται σε ένα κεντρικό ή κατανεμημένο σύστημα αποθήκευσης.
  • συγκλονιστικές διαδικασίες διαχείρισης, δημιουργίας αντιγράφων ασφαλείας και εξισορρόπησης με την πάροδο του χρόνου.
  • εξισορρόπηση μόνο σε ένα σύνολο κεντρικών υπολογιστών πελατών.
  • εξισορρόπηση μόνο όταν υπάρχει ισχυρή ανισορροπία, οι πιο αποτελεσματικές και ασφαλείς μεταναστεύσεις VM (εξάλλου, η μετανάστευση μπορεί να αποτύχει).
  • εξισορρόπηση σχετικά «αθόρυβων» εικονικών μηχανών (η μετεγκατάσταση των «θορυβωδών» εικονικών μηχανών μπορεί να διαρκέσει πολύ χρόνο).
  • εξισορρόπηση λαμβάνοντας υπόψη το «κόστος» - το φορτίο στο σύστημα αποθήκευσης και στο δίκτυο (με προσαρμοσμένες αρχιτεκτονικές για μεγάλους πελάτες).
  • εξισορρόπηση λαμβάνοντας υπόψη τα μεμονωμένα χαρακτηριστικά συμπεριφοράς κάθε VM·
  • Η εξισορρόπηση γίνεται κατά προτίμηση σε μη εργάσιμες ώρες (νύχτες, Σαββατοκύριακα, αργίες).

Για δημόσια σύννεφαπαρέχοντας υπηρεσίες σε μικρούς πελάτες, το DRS μπορεί να χρησιμοποιηθεί πολύ πιο συχνά, με προηγμένες δυνατότητες:

  • απουσία περιορισμών ασφάλειας πληροφοριών και κανόνων συγγένειας·
  • ισορροπία μέσα στο σύννεφο.
  • εξισορρόπηση σε οποιαδήποτε εύλογη στιγμή·
  • εξισορρόπηση οποιουδήποτε VM.
  • εξισορρόπηση "θορυβωδών" εικονικών μηχανών (ώστε να μην ενοχλείτε άλλους)
  • Τα δεδομένα εικονικής μηχανής βρίσκονται συχνά σε τοπικούς δίσκους.
  • λαμβάνοντας υπόψη τη μέση απόδοση των συστημάτων αποθήκευσης και των δικτύων (η αρχιτεκτονική cloud είναι ενοποιημένη)·
  • εξισορρόπηση σύμφωνα με τους γενικούς κανόνες και τα διαθέσιμα στατιστικά στοιχεία συμπεριφοράς του κέντρου δεδομένων.

Πολυπλοκότητα του προβλήματος

Η δυσκολία της εξισορρόπησης είναι ότι το DRS πρέπει να λειτουργεί με έναν μεγάλο αριθμό αβέβαιων παραγόντων:

  • συμπεριφορά των χρηστών του καθενός από τα πληροφοριακά συστήματα των πελατών·
  • αλγόριθμοι για τη λειτουργία διακομιστών πληροφοριακών συστημάτων.
  • συμπεριφορά των διακομιστών DBMS.
  • Φορτίο σε υπολογιστικούς πόρους, συστήματα αποθήκευσης, δίκτυο.
  • αλληλεπίδραση των διακομιστών μεταξύ τους στον αγώνα για πόρους cloud.

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

Load Balancing στο Openstack (Μέρος 2)

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

Load Balancing στο Openstack (Μέρος 2)

Ιστορία των εξελίξεων μας

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

Στάδιο 1

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

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

Ξεκινήσαμε το σύστημα και αρχίσαμε πραγματικά να εξισορροπούμε. Η κλίμακα του cloud μας δεν μας επέτρεψε να έχουμε τα αισιόδοξα αποτελέσματα που δήλωσαν οι προγραμματιστές, αλλά ήταν σαφές ότι η εξισορρόπηση λειτουργούσε.

Ταυτόχρονα, είχαμε αρκετά σοβαρούς περιορισμούς:

  • Για να εκπαιδεύσουν ένα νευρωνικό δίκτυο, οι εικονικές μηχανές πρέπει να λειτουργούν χωρίς σημαντικές αλλαγές για εβδομάδες ή μήνες.
  • Ο αλγόριθμος έχει σχεδιαστεί για βελτιστοποίηση με βάση την ανάλυση προηγούμενων «ιστορικών» δεδομένων.
  • Η εκπαίδευση ενός νευρωνικού δικτύου απαιτεί αρκετά μεγάλο όγκο δεδομένων και υπολογιστικών πόρων.
  • Η βελτιστοποίηση και η εξισορρόπηση μπορούν να γίνουν σχετικά σπάνια - μία φορά κάθε λίγες ώρες, κάτι που σαφώς δεν είναι αρκετό.

Στάδιο 2

Επειδή δεν ήμασταν ικανοποιημένοι με την κατάσταση των πραγμάτων, αποφασίσαμε να τροποποιήσουμε το σύστημα και για να το κάνουμε αυτό, απαντήστε κύριο ερώτημα – για ποιον το φτιάχνουμε;

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

Δεύτερη ερώτηση – τι εννοείτε με τη λέξη «αμέσως»; Ως αποτέλεσμα μιας σύντομης συζήτησης, αποφασίσαμε ότι μπορούσαμε να ξεκινήσουμε με χρόνο απόκρισης 5–10 λεπτών, έτσι ώστε οι βραχυπρόθεσμες υπερτάσεις να μην εισάγουν το σύστημα σε συντονισμό.

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

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

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

Load Balancing στο Openstack (Μέρος 2)

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

Εφαρμόσαμε και λανσάραμε αυτό το σύστημα και λάβαμε ενθαρρυντικά αποτελέσματα - τώρα αναλύει τακτικά το φόρτο του cloud και κάνει συστάσεις για τη μετακίνηση εικονικών μηχανών, οι οποίες είναι σε μεγάλο βαθμό σωστές. Ακόμη και τώρα είναι σαφές ότι μπορούμε να επιτύχουμε 10-15% απελευθέρωση πόρων για νέες εικονικές μηχανές βελτιώνοντας παράλληλα την ποιότητα εργασίας των υπαρχόντων.

Load Balancing στο Openstack (Μέρος 2)

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

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

Στάδιο 3

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

  1. Στατιστικά, για παράδειγμα, εδώ и εδώ δείχνει ότι τα συστήματα δύο και τεσσάρων επεξεργαστών είναι σημαντικά χαμηλότερα σε απόδοση από τα συστήματα ενός επεξεργαστή. Αυτό σημαίνει ότι όλοι οι χρήστες λαμβάνουν σημαντικά λιγότερη έξοδο από CPU, RAM, SSD, LAN, FC που αγοράζονται σε συστήματα πολλαπλών επεξεργαστών σε σύγκριση με τα συστήματα ενός επεξεργαστή.
  2. Οι ίδιοι οι προγραμματιστές πόρων μπορεί να έχουν σοβαρά σφάλματα, εδώ είναι ένα από τα άρθρα σχετικά με το θέμα αυτό.
  3. Οι τεχνολογίες που προσφέρονται από την Intel και την AMD για την παρακολούθηση της μνήμης RAM και της προσωρινής μνήμης καθιστούν δυνατή τη μελέτη της συμπεριφοράς των εικονικών μηχανών και την τοποθέτησή τους με τέτοιο τρόπο ώστε οι "θορυβώδεις" γείτονες να μην παρεμβαίνουν σε "ήσυχες" εικονικές μηχανές.
  4. Επέκταση του συνόλου των παραμέτρων (δίκτυο, σύστημα αποθήκευσης, προτεραιότητα της εικονικής μηχανής, κόστος μετανάστευσης, ετοιμότητά της για μετεγκατάσταση).

Σε συνολικά

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

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

Θα σας πούμε περισσότερα για τις δυνατότητες των επεξεργαστών, των προγραμματιστών και της εξισορρόπησης υψηλού επιπέδου στα ακόλουθα άρθρα.

Πηγή: www.habr.com

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