Το επόμενο συνέδριο HighLoad++ θα πραγματοποιηθεί στις 6 και 7 Απριλίου 2020 στην Αγία Πετρούπολη Λεπτομέρειες και εισιτήρια . HighLoad++ Μόσχα 2018. Αίθουσα «Μόσχα». 9 Νοεμβρίου, 15:00. Διατριβές και .
* Παρακολούθηση - διαδικτυακά και αναλυτικά στοιχεία.
* Βασικοί περιορισμοί της πλατφόρμας ZABBIX.
* Λύση για την κλιμάκωση της αποθήκευσης αναλυτικών στοιχείων.
* Βελτιστοποίηση του διακομιστή ZABBIX.
* Βελτιστοποίηση διεπαφής χρήστη.
* Εμπειρία στη λειτουργία του συστήματος κάτω από φορτία άνω των 40k NVPS.
* Σύντομα συμπεράσματα.
Mikhail Makurov (εφεξής – ΜΜ): - Γεια σε όλους!
Maxim Chernetsov (εφεξής – MCH): - Καλό απόγευμα!
ΜΜ: – Επιτρέψτε μου να σας συστήσω τον Μαξίμ. Ο Μαξ είναι ένας ταλαντούχος μηχανικός, ο καλύτερος δικτυωτής που ξέρω. Η Maxim ασχολείται με δίκτυα και υπηρεσίες, την ανάπτυξη και λειτουργία τους.
MCH: – Και θα ήθελα να σας πω για τον Μιχαήλ. Ο Mikhail είναι προγραμματιστής C. Έγραψε πολλές λύσεις επεξεργασίας κίνησης υψηλού φορτίου για την εταιρεία μας. Ζούμε και εργαζόμαστε στα Ουράλια, στην πόλη των σκληρών ανδρών Τσελιάμπινσκ, στην εταιρεία Intersvyaz. Η εταιρεία μας είναι πάροχος υπηρεσιών Διαδικτύου και καλωδιακής τηλεόρασης για ένα εκατομμύριο άτομα σε 16 πόλεις.
ΜΜ: – Και αξίζει να πούμε ότι η Intersvyaz είναι πολύ περισσότερα από έναν πάροχο, είναι μια εταιρεία πληροφορικής. Οι περισσότερες από τις λύσεις μας γίνονται από το τμήμα πληροφορικής μας.
Α: από διακομιστές που επεξεργάζονται κίνηση σε τηλεφωνικό κέντρο και εφαρμογή για κινητά. Το τμήμα Πληροφορικής έχει τώρα περίπου 80 άτομα με πολύ, πολύ διαφορετικές ικανότητες.
Σχετικά με το Zabbix και την αρχιτεκτονική του
MCH: – Και τώρα θα προσπαθήσω να σημειώσω ένα προσωπικό ρεκόρ και να πω σε ένα λεπτό τι είναι το Zabbix (εφεξής «Zabbix»).
Το Zabbix τοποθετείται ως ένα σύστημα παρακολούθησης out-of-the-box σε επίπεδο επιχείρησης. Διαθέτει πολλές δυνατότητες που διευκολύνουν τη ζωή: προηγμένους κανόνες κλιμάκωσης, API για ενοποίηση, ομαδοποίηση και αυτόματη ανίχνευση κεντρικών υπολογιστών και μετρήσεων. Το Zabbix έχει τα λεγόμενα εργαλεία κλιμάκωσης - proxies. Το Zabbix είναι ένα σύστημα ανοιχτού κώδικα.
Εν συντομία για την αρχιτεκτονική. Μπορούμε να πούμε ότι αποτελείται από τρία συστατικά:
- Υπηρέτης. Γραμμένο στο Γ. Με αρκετά περίπλοκη επεξεργασία και μεταφορά πληροφοριών μεταξύ νημάτων. Όλη η επεξεργασία πραγματοποιείται σε αυτό: από τη λήψη έως την αποθήκευση στη βάση δεδομένων.
- Όλα τα δεδομένα αποθηκεύονται στη βάση δεδομένων. Το Zabbix υποστηρίζει MySQL, PostreSQL και Oracle.
- Η διεπαφή ιστού είναι γραμμένη σε PHP. Στα περισσότερα συστήματα έρχεται με διακομιστή Apache, αλλά λειτουργεί πιο αποτελεσματικά σε συνδυασμό με nginx + php.
Σήμερα θα θέλαμε να πούμε μια ιστορία από τη ζωή της εταιρείας μας που σχετίζεται με το Zabbix...
Μια ιστορία από τη ζωή της εταιρείας Intersvyaz. Τι έχουμε και τι χρειαζόμαστε;
5 ή 6 μήνες πριν. Μια μέρα μετά τη δουλειά...
MCH: - Μίσα, γεια! Χαίρομαι που κατάφερα να σε πιάσω - υπάρχει μια κουβέντα. Είχαμε πάλι προβλήματα με την παρακολούθηση. Κατά τη διάρκεια ενός μεγάλου ατυχήματος, όλα ήταν αργά και δεν υπήρχαν πληροφορίες για την κατάσταση του δικτύου. Δυστυχώς, δεν είναι η πρώτη φορά που συμβαίνει αυτό. Χρειάζομαι τη βοήθειά σου. Ας κάνουμε την παρακολούθηση μας να λειτουργεί υπό οποιεσδήποτε συνθήκες!
ΜΜ: - Αλλά ας συγχρονιστούμε πρώτα. Δεν έχω κοιτάξει εκεί εδώ και δύο χρόνια. Από όσο θυμάμαι, εγκαταλείψαμε το Nagios και μεταβήκαμε στο Zabbix πριν από περίπου 8 χρόνια. Και τώρα φαίνεται να έχουμε 6 ισχυρούς διακομιστές και περίπου δώδεκα proxies. Μπερδεύω τίποτα;
MCH: - Σχεδόν. 15 διακομιστές, μερικοί από τους οποίους είναι εικονικές μηχανές. Το πιο σημαντικό είναι ότι δεν μας σώζει τη στιγμή που το χρειαζόμαστε περισσότερο. Σαν ατύχημα - οι διακομιστές επιβραδύνουν και δεν μπορείτε να δείτε τίποτα. Προσπαθήσαμε να βελτιστοποιήσουμε τη διαμόρφωση, αλλά αυτό δεν παρείχε τη βέλτιστη αύξηση απόδοσης.
ΜΜ: - Είναι σαφές. Κοίταξες κάτι, έχεις ήδη ξεθάψει κάτι από τα διαγνωστικά;
MCH: – Το πρώτο πράγμα που πρέπει να αντιμετωπίσετε είναι η βάση δεδομένων. Η MySQL φορτώνεται συνεχώς, αποθηκεύει νέες μετρήσεις, και όταν το Zabbix αρχίζει να δημιουργεί μια δέσμη συμβάντων, η βάση δεδομένων περνά σε υπερένταση για κυριολεκτικά μερικές ώρες. Σας είπα ήδη για τη βελτιστοποίηση της διαμόρφωσης, αλλά κυριολεκτικά φέτος ενημέρωσαν το υλικό: οι διακομιστές έχουν περισσότερα από εκατό gigabyte μνήμης και συστοιχίες δίσκων σε SSD RAID - δεν έχει νόημα να το μεγαλώσουμε γραμμικά μακροπρόθεσμα. Τι κάνουμε?
ΜΜ: - Είναι σαφές. Γενικά, η MySQL είναι μια βάση δεδομένων LTP. Προφανώς, δεν είναι πλέον κατάλληλο για την αποθήκευση ενός αρχείου μετρήσεων του μεγέθους μας. Ας το καταλάβουμε.
MCH: - Ας!
Ενσωμάτωση του Zabbix και του Clickhouse ως αποτέλεσμα του hackathon
Μετά από λίγο καιρό λάβαμε ενδιαφέροντα στοιχεία:
Το μεγαλύτερο μέρος του χώρου στη βάση δεδομένων μας καταλάμβανε το αρχείο μετρήσεων και λιγότερο από το 1% χρησιμοποιήθηκε για τη διαμόρφωση, τα πρότυπα και τις ρυθμίσεις. Μέχρι τότε, λειτουργούσαμε τη λύση Big data που βασίζεται στο Clickhouse για περισσότερο από ένα χρόνο. Η κατεύθυνση της κίνησης ήταν προφανής για εμάς. Στο ανοιξιάτικο Hackathon μας, έγραψα την ενοποίηση του Zabbix με το Clickhouse για τον διακομιστή και το frontend. Εκείνη την εποχή, το Zabbix είχε ήδη υποστήριξη για το ElasticSearch και αποφασίσαμε να τα συγκρίνουμε.
Σύγκριση Clickhouse και Elasticsearch
ΜΜ: – Για σύγκριση, δημιουργήσαμε το ίδιο φορτίο που παρέχει ο διακομιστής Zabbix και εξετάσαμε πώς θα συμπεριφερθούν τα συστήματα. Γράψαμε δεδομένα σε παρτίδες των 1000 γραμμών, χρησιμοποιώντας CURL. Υποθέσαμε εκ των προτέρων ότι το Clickhouse θα ήταν πιο αποτελεσματικό για το προφίλ φόρτωσης που κάνει το Zabbix. Τα αποτελέσματα ξεπέρασαν ακόμη και τις προσδοκίες μας:
Κάτω από τις ίδιες συνθήκες δοκιμής, το Clickhouse έγραψε τρεις φορές περισσότερα δεδομένα. Ταυτόχρονα, και τα δύο συστήματα κατανάλωναν πολύ αποτελεσματικά (μικρό ποσό πόρων) κατά την ανάγνωση δεδομένων. Αλλά το Elastics απαιτούσε μεγάλη ποσότητα επεξεργαστή κατά την εγγραφή:
Συνολικά, το Clickhouse υπερτερούσε σημαντικά του Elastix σε κατανάλωση και ταχύτητα επεξεργαστή. Ταυτόχρονα, λόγω της συμπίεσης δεδομένων, το Clickhouse χρησιμοποιεί 11 φορές λιγότερο στον σκληρό δίσκο και εκτελεί περίπου 30 φορές λιγότερες λειτουργίες δίσκου:
MCH: – Ναι, η εργασία του Clickhouse με το υποσύστημα δίσκου υλοποιείται πολύ αποτελεσματικά. Μπορείτε να χρησιμοποιήσετε τεράστιους δίσκους SATA για βάσεις δεδομένων και να έχετε ταχύτητες γραφής εκατοντάδων χιλιάδων γραμμών ανά δευτερόλεπτο. Το σύστημα out-of-the-box υποστηρίζει τη διαμοιρασμό, την αναπαραγωγή και είναι πολύ εύκολο να διαμορφωθεί. Είμαστε περισσότερο από ικανοποιημένοι με τη χρήση του καθ' όλη τη διάρκεια του έτους.
Για να βελτιστοποιήσετε τους πόρους, μπορείτε να εγκαταστήσετε το Clickhouse δίπλα στην υπάρχουσα κύρια βάση δεδομένων σας και έτσι να εξοικονομήσετε πολύ χρόνο CPU και λειτουργίες δίσκου. Μεταφέραμε το αρχείο μετρήσεων σε υπάρχοντα συμπλέγματα Clickhouse:
Ανακουφίσαμε τόσο πολύ την κύρια βάση δεδομένων MySQL που μπορέσαμε να τη συνδυάσουμε σε ένα μηχάνημα με τον διακομιστή Zabbix και να εγκαταλείψουμε τον αποκλειστικό διακομιστή για την MySQL.
Πώς λειτουργεί η ψηφοφορία στο Zabbix;
4 μήνες πριν
ΜΜ: – Λοιπόν, μπορούμε να ξεχάσουμε τα προβλήματα με τη βάση;
MCH: - Αυτό είναι σίγουρο! Ένα άλλο πρόβλημα που πρέπει να λύσουμε είναι η αργή συλλογή δεδομένων. Τώρα και οι 15 διακομιστές μεσολάβησης είναι υπερφορτωμένοι με SNMP και διαδικασίες δημοσκόπησης. Και δεν υπάρχει άλλος τρόπος εκτός από την εγκατάσταση νέων και νέων διακομιστών.
ΜΜ: - Εξαιρετική. Αλλά πρώτα, πείτε μας πώς λειτουργεί η δημοσκόπηση στο Zabbix;
MCH: – Εν ολίγοις, υπάρχουν 20 τύποι μετρήσεων και δώδεκα τρόποι απόκτησής τους. Το Zabbix μπορεί να συλλέξει δεδομένα είτε στη λειτουργία "αίτημα-απόκριση" ή να περιμένει νέα δεδομένα μέσω της "Διεπαφής Trapper".
Αξίζει να σημειωθεί ότι στο πρωτότυπο Zabbix αυτή η μέθοδος (Trapper) είναι η πιο γρήγορη.
Υπάρχουν διακομιστές μεσολάβησης για διανομή φορτίου:
Οι διακομιστής μεσολάβησης μπορούν να εκτελούν τις ίδιες λειτουργίες συλλογής με τον διακομιστή Zabbix, λαμβάνοντας εργασίες από αυτόν και στέλνοντας τις μετρήσεις που συλλέγονται μέσω της διεπαφής Trapper. Αυτός είναι ο επίσημα προτεινόμενος τρόπος κατανομής του φορτίου. Οι διακομιστής μεσολάβησης είναι επίσης χρήσιμοι για την παρακολούθηση απομακρυσμένης υποδομής που λειτουργεί μέσω NAT ή ενός αργού καναλιού:
ΜΜ: – Όλα είναι ξεκάθαρα με την αρχιτεκτονική. Πρέπει να δούμε τις πηγές...
Μια δυο μέρες αργότερα
Η ιστορία του πώς κέρδισε το nmap fping
ΜΜ: «Νομίζω ότι ξέθαψα κάτι».
MCH: - Πες μου!
ΜΜ: – Ανακάλυψα ότι κατά τον έλεγχο της διαθεσιμότητας, το Zabbix ελέγχει το πολύ 128 κεντρικούς υπολογιστές κάθε φορά. Προσπάθησα να αυξήσω αυτόν τον αριθμό σε 500 και να αφαιρέσω το διάστημα μεταξύ των πακέτων στο ping τους (ping) - αυτό διπλασίασε την απόδοση. Αλλά θα ήθελα μεγαλύτερους αριθμούς.
MCH: – Στην πρακτική μου, μερικές φορές πρέπει να ελέγξω τη διαθεσιμότητα χιλιάδων κεντρικών υπολογιστών και δεν έχω δει ποτέ κάτι πιο γρήγορο από το nmap για αυτό. Είμαι σίγουρος ότι αυτός είναι ο πιο γρήγορος τρόπος. Ας το προσπαθήσουμε! Πρέπει να αυξήσουμε σημαντικά τον αριθμό των κεντρικών υπολογιστών ανά επανάληψη.
ΜΜ: – Έλεγχος πάνω από πεντακόσια; 600?
MCH: - Τουλάχιστον μερικές χιλιάδες.
ΜΜ: - ΕΝΤΑΞΕΙ. Το πιο σημαντικό πράγμα που ήθελα να πω είναι ότι ανακάλυψα ότι οι περισσότερες δημοσκοπήσεις στο Zabbix γίνονται συγχρονισμένα. Πρέπει οπωσδήποτε να το αλλάξουμε σε ασύγχρονη λειτουργία. Τότε μπορούμε να αυξήσουμε δραματικά τον αριθμό των μετρήσεων που συλλέγονται από τους δημοσκόπους, ειδικά αν αυξήσουμε τον αριθμό των μετρήσεων ανά επανάληψη.
MCH: - Εξαιρετική! Και πότε?
ΜΜ: – Ως συνήθως, χθες.
MCH: – Συγκρίναμε και τις δύο εκδόσεις του fping και του nmap:
Σε μεγάλο αριθμό κεντρικών υπολογιστών, το nmap αναμενόταν να είναι έως και πέντε φορές πιο αποτελεσματικό. Δεδομένου ότι το nmap ελέγχει μόνο τη διαθεσιμότητα και τον χρόνο απόκρισης, μεταφέραμε τον υπολογισμό των απωλειών σε έναυσμα και μειώσαμε σημαντικά τα διαστήματα ελέγχου διαθεσιμότητας. Βρήκαμε ότι ο βέλτιστος αριθμός κεντρικών υπολογιστών για το nmap είναι περίπου 4 χιλιάδες ανά επανάληψη. Το Nmap μας επέτρεψε να μειώσουμε το κόστος της CPU των ελέγχων διαθεσιμότητας κατά τρεις φορές και να μειώσουμε το διάστημα από 120 δευτερόλεπτα σε 10.
Βελτιστοποίηση δημοσκοπήσεων
ΜΜ: «Μετά αρχίσαμε να κάνουμε pollers. Μας ενδιέφερε κυρίως η ανίχνευση SNMP και οι παράγοντες. Στο Zabbix, η ψηφοφορία γίνεται συγχρονισμένα και έχουν ληφθεί ειδικά μέτρα για την αύξηση της αποτελεσματικότητας του συστήματος. Στη σύγχρονη λειτουργία, η μη διαθεσιμότητα του κεντρικού υπολογιστή προκαλεί σημαντική υποβάθμιση της ψηφοφορίας. Υπάρχει ένα ολόκληρο σύστημα πολιτειών, υπάρχουν ειδικές διαδικασίες - οι λεγόμενοι μη προσβάσιμοι δημοσκόποι, οι οποίοι λειτουργούν μόνο με μη προσβάσιμους κεντρικούς υπολογιστές:
Αυτό είναι ένα σχόλιο που δείχνει τον πίνακα καταστάσεων, όλη την πολυπλοκότητα του συστήματος των μεταβάσεων που απαιτούνται για να παραμείνει το σύστημα αποτελεσματικό. Επιπλέον, η ίδια η σύγχρονη δημοσκόπηση είναι αρκετά αργή:
Αυτός είναι ο λόγος για τον οποίο χιλιάδες ροές δημοσκόπησης σε δεκάδες πληρεξούσιους δεν μπορούσαν να συλλέξουν τον απαιτούμενο όγκο δεδομένων για εμάς. Η ασύγχρονη υλοποίηση έλυσε όχι μόνο τα προβλήματα με τον αριθμό των νημάτων, αλλά και απλοποίησε σημαντικά το σύστημα κατάστασης των μη διαθέσιμων κεντρικών υπολογιστών, επειδή για οποιονδήποτε αριθμό ελεγχόταν σε μία επανάληψη ψηφοφορίας, ο μέγιστος χρόνος αναμονής ήταν 1 χρονικό όριο:
Επιπλέον, τροποποιήσαμε και βελτιώσαμε το σύστημα δημοσκοπήσεων για αιτήματα SNMP. Το γεγονός είναι ότι οι περισσότεροι άνθρωποι δεν μπορούν να ανταποκριθούν σε πολλαπλά αιτήματα SNMP ταυτόχρονα. Επομένως, δημιουργήσαμε μια υβριδική λειτουργία, όταν η δημοσκόπηση SNMP του ίδιου κεντρικού υπολογιστή γίνεται ασύγχρονα:
Αυτό γίνεται για ολόκληρο το πακέτο των κεντρικών υπολογιστών. Αυτή η λειτουργία δεν είναι τελικά πιο αργή από μια εντελώς ασύγχρονη, καθώς η μέτρηση μιάμιση εκατό τιμών SNMP εξακολουθεί να είναι πολύ πιο γρήγορη από 1 timeout.
Τα πειράματά μας έδειξαν ότι ο βέλτιστος αριθμός αιτημάτων σε μία επανάληψη είναι περίπου 8 χιλιάδες με δημοσκόπηση SNMP. Συνολικά, η μετάβαση στην ασύγχρονη λειτουργία μας επέτρεψε να επιταχύνουμε την απόδοση της ψηφοφορίας κατά 200 φορές, αρκετές εκατοντάδες φορές.
MCH: – Οι βελτιστοποιήσεις δημοσκόπησης που προέκυψαν έδειξαν ότι όχι μόνο μπορούμε να απαλλαγούμε από όλους τους διακομιστές μεσολάβησης, αλλά και να μειώσουμε τα διαστήματα για πολλούς ελέγχους και ότι οι πληρεξούσιοι δεν θα χρειάζονται πλέον ως τρόπος κοινής χρήσης του φορτίου.
Πριν από περίπου τρεις μήνες
Αλλάξτε την αρχιτεκτονική - αυξήστε το φορτίο!
ΜΜ: - Λοιπόν, Μαξ, ήρθε η ώρα να γίνεις παραγωγικός; Χρειάζομαι έναν ισχυρό διακομιστή και έναν καλό μηχανικό.
MCH: - Εντάξει, ας το προγραμματίσουμε. Ήρθε η ώρα να μετακινηθείτε από το νεκρό σημείο των 5 χιλιάδων μετρήσεων ανά δευτερόλεπτο.
Πρωί μετά την αναβάθμιση
MCH: - Μίσα, ενημερωθήκαμε, αλλά μέχρι το πρωί γυρίσαμε πίσω... Μαντέψτε τι ταχύτητα καταφέραμε να πετύχουμε;
ΜΜ: – 20 χιλιάδες κατ’ ανώτατο όριο.
MCH: - Ναι, 25! Δυστυχώς βρισκόμαστε εκεί που ξεκινήσαμε.
ΜΜ: - Γιατί? Έκανες κανένα διαγνωστικό;
MCH: - Ναι σίγουρα! Εδώ, για παράδειγμα, είναι μια ενδιαφέρουσα κορυφή:
ΜΜ: - Ας δούμε. Βλέπω ότι έχουμε δοκιμάσει έναν τεράστιο αριθμό νημάτων δημοσκοπήσεων:
Αλλά την ίδια στιγμή δεν μπορούσαν να ανακυκλώσουν το σύστημα ούτε στο μισό:
Και η συνολική απόδοση είναι αρκετά μικρή, περίπου 4 χιλιάδες μετρήσεις ανά δευτερόλεπτο:
Υπάρχει κάτι άλλο?
MCH: – Ναι, στράτσα ενός από τους δημοσκόπους:
ΜΜ: – Εδώ μπορείτε να δείτε ξεκάθαρα ότι η διαδικασία ψηφοφορίας περιμένει «σηματοφόρους». Αυτές είναι οι κλειδαριές:
MCH: - Ασαφές.
ΜΜ: – Κοιτάξτε, αυτό μοιάζει με μια κατάσταση όπου μια δέσμη νημάτων προσπαθούν να εργαστούν με πόρους με τους οποίους μόνο ένας μπορεί να εργαστεί κάθε φορά. Τότε το μόνο που μπορούν να κάνουν είναι να μοιράζονται αυτόν τον πόρο με την πάροδο του χρόνου:
Και η συνολική απόδοση της εργασίας με έναν τέτοιο πόρο περιορίζεται από την ταχύτητα ενός πυρήνα:
Υπάρχουν δύο τρόποι για να λυθεί αυτό το πρόβλημα.
Αναβαθμίστε το υλικό του μηχανήματος, μεταβείτε σε ταχύτερους πυρήνες:
Ή αλλάξτε την αρχιτεκτονική και ταυτόχρονα αλλάξτε το φορτίο:
MCH: – Παρεμπιπτόντως, στη δοκιμαστική μηχανή θα χρησιμοποιήσουμε λιγότερους πυρήνες από ό,τι στη μάχη, αλλά είναι 1,5 φορές πιο γρήγοροι σε συχνότητα ανά πυρήνα!
ΜΜ: - Σαφή? Πρέπει να κοιτάξετε τον κωδικό διακομιστή.
Διαδρομή δεδομένων στον διακομιστή Zabbix
MCH: – Για να το καταλάβουμε, αρχίσαμε να αναλύουμε πώς μεταφέρονται τα δεδομένα μέσα στον διακομιστή Zabbix:
Ωραία εικόνα, σωστά; Ας το δούμε βήμα-βήμα για να το ξεκαθαρίσουμε λίγο πολύ. Υπάρχουν νήματα και υπηρεσίες υπεύθυνες για τη συλλογή δεδομένων:
Μεταδίδουν τις μετρήσεις που συλλέγονται μέσω μιας υποδοχής στον διαχειριστή προεπεξεργαστή, όπου αποθηκεύονται σε μια ουρά:
Ο "διαχειριστής προεπεξεργαστή" μεταδίδει δεδομένα στους εργαζομένους του, οι οποίοι εκτελούν εντολές προεπεξεργασίας και τις επιστρέφουν πίσω από την ίδια υποδοχή:
Μετά από αυτό, ο διαχειριστής προεπεξεργαστή τα αποθηκεύει στην κρυφή μνήμη ιστορικού:
Από εκεί λαμβάνονται από τους δίσκους ιστορικού, οι οποίοι εκτελούν πολλές λειτουργίες: για παράδειγμα, υπολογισμό κανόνων, πλήρωση της προσωρινής μνήμης τιμών και, το πιο σημαντικό, αποθήκευση μετρήσεων στην αποθήκευση ιστορικού. Γενικά, η διαδικασία είναι πολύπλοκη και πολύ μπερδεμένη.
ΜΜ: – Το πρώτο πράγμα που είδαμε ήταν ότι τα περισσότερα νήματα ανταγωνίζονται για τη λεγόμενη «cache διαμόρφωσης» (η περιοχή μνήμης όπου αποθηκεύονται όλες οι διαμορφώσεις διακομιστή). Τα νήματα που είναι υπεύθυνα για τη συλλογή δεδομένων εμποδίζουν ιδιαίτερα πολύ:
...καθώς η διαμόρφωση αποθηκεύει όχι μόνο μετρήσεις με τις παραμέτρους τους, αλλά και ουρές από τις οποίες οι δημοσκόποι λαμβάνουν πληροφορίες σχετικά με το τι πρέπει να κάνουν στη συνέχεια. Όταν υπάρχουν πολλοί pollers και ένας μπλοκάρει τη διαμόρφωση, οι άλλοι περιμένουν αιτήματα:
Οι δημοσκόποι δεν πρέπει να συγκρούονται
Επομένως, το πρώτο πράγμα που κάναμε ήταν να χωρίσουμε την ουρά σε 4 μέρη και να επιτρέψουμε στους δημοσκόπους να μπλοκάρουν αυτές τις ουρές, αυτά τα μέρη ταυτόχρονα, υπό ασφαλείς συνθήκες:
Αυτό αφαίρεσε τον ανταγωνισμό για τη μνήμη cache διαμόρφωσης και η ταχύτητα των pollers αυξήθηκε σημαντικά. Στη συνέχεια, όμως, συναντήσαμε το γεγονός ότι ο διαχειριστής προεπεξεργαστή άρχισε να συγκεντρώνει μια ουρά εργασιών:
Ο διαχειριστής προεπεξεργαστή πρέπει να είναι σε θέση να θέτει προτεραιότητες
Αυτό συνέβαινε σε περιπτώσεις που του έλειπαν οι επιδόσεις. Τότε το μόνο που μπορούσε να κάνει ήταν να συσσωρεύσει αιτήματα από διαδικασίες συλλογής δεδομένων και να προσθέσει το buffer τους μέχρι να καταναλώσει όλη τη μνήμη και να διακοπεί:
Για να λύσουμε αυτό το πρόβλημα, προσθέσαμε μια δεύτερη πρίζα που ήταν αφιερωμένη ειδικά στους εργαζόμενους:
Έτσι, ο διαχειριστής προεπεξεργαστή είχε την ευκαιρία να δώσει προτεραιότητα στην εργασία του και, εάν το buffer μεγαλώσει, το καθήκον είναι να επιβραδύνει την αφαίρεση, δίνοντας στους εργαζόμενους την ευκαιρία να πάρουν αυτό το buffer:
Στη συνέχεια ανακαλύψαμε ότι ένας από τους λόγους για την επιβράδυνση ήταν οι ίδιοι οι εργαζόμενοι, αφού ανταγωνίζονταν για έναν πόρο που ήταν εντελώς ασήμαντος για την εργασία τους. Καταγράψαμε αυτό το πρόβλημα ως επιδιόρθωση σφαλμάτων και έχει ήδη επιλυθεί σε νέες εκδόσεις του Zabbix:
Αυξάνουμε τον αριθμό των υποδοχών - παίρνουμε το αποτέλεσμα
Επιπλέον, ο ίδιος ο διαχειριστής προεπεξεργαστή έγινε εμπόδιο, καθώς είναι ένα νήμα. Βασιζόταν στην ταχύτητα του πυρήνα, δίνοντας μέγιστη ταχύτητα περίπου 70 χιλιάδων μετρήσεων ανά δευτερόλεπτο:
Επομένως, φτιάξαμε τέσσερις, με τέσσερα σετ πριζών, εργάτες:
Και αυτό μας επέτρεψε να αυξήσουμε την ταχύτητα σε περίπου 130 χιλιάδες μετρήσεις:
Η μη γραμμικότητα της ανάπτυξης εξηγείται από το γεγονός ότι έχει εμφανιστεί ανταγωνισμός για την κρυφή μνήμη ιστορικού. 4 διευθυντές προεπεξεργαστή και ιστορικοί οπαδοί διαγωνίστηκαν για αυτό. Σε αυτό το σημείο, λαμβάναμε περίπου 130 χιλιάδες μετρήσεις ανά δευτερόλεπτο στο μηχάνημα δοκιμής, χρησιμοποιώντας το από το 95% περίπου του επεξεργαστή:
Πριν από περίπου 2,5 μήνες
Η άρνηση από την κοινότητα snmp αύξησε τα NVP κατά μιάμιση φορά
ΜΜ: – Μαξ, χρειάζομαι ένα νέο αυτοκίνητο δοκιμής! Δεν χωράμε πια στο σημερινό.
MCH: -Τι έχεις τώρα;
ΜΜ: – Τώρα – 130 NVP και επεξεργαστής έτοιμος για αποθήκευση.
MCH: - Ουάου! Δροσερός! Περίμενε, έχω δύο ερωτήσεις. Σύμφωνα με τους υπολογισμούς μου, η ανάγκη μας είναι γύρω στις 15-20 χιλιάδες μετρήσεις ανά δευτερόλεπτο. Γιατί χρειαζόμαστε περισσότερα;
ΜΜ: «Θέλω να τελειώσω τη δουλειά». Θα ήθελα να δω πόσα μπορούμε να αποσπάσουμε από αυτό το σύστημα.
MCH: - Αλλά…
ΜΜ: «Αλλά είναι άχρηστο για δουλειές».
MCH: - Είναι σαφές. Και το δεύτερο ερώτημα: μπορούμε να υποστηρίξουμε αυτό που έχουμε τώρα μόνοι μας, χωρίς τη βοήθεια προγραμματιστή;
ΜΜ: - Δεν νομίζω. Η αλλαγή του τρόπου λειτουργίας της προσωρινής μνήμης διαμόρφωσης είναι ένα πρόβλημα. Επηρεάζει τις αλλαγές στα περισσότερα νήματα και είναι αρκετά δύσκολο να διατηρηθεί. Το πιθανότερο είναι ότι θα είναι πολύ δύσκολο να το διατηρήσετε.
MCH: «Τότε χρειαζόμαστε κάποιου είδους εναλλακτική».
ΜΜ: - Υπάρχει μια τέτοια επιλογή. Μπορούμε να μεταβούμε σε γρήγορους πυρήνες, ενώ εγκαταλείπουμε το νέο σύστημα κλειδώματος. Θα έχουμε ακόμα απόδοση 60-80 χιλιάδων μετρήσεων. Ταυτόχρονα, μπορούμε να αφήσουμε όλο τον υπόλοιπο κώδικα. Το Clickhouse και η ασύγχρονη δημοσκόπηση θα λειτουργήσουν. Και θα είναι εύκολο να διατηρηθεί.
MCH: - Φοβερο! Προτείνω να σταματήσουμε εδώ.
Μετά τη βελτιστοποίηση της πλευράς του διακομιστή, μπορέσαμε τελικά να ξεκινήσουμε τον νέο κώδικα στην παραγωγή. Εγκαταλείψαμε ορισμένες από τις αλλαγές υπέρ της μετάβασης σε ένα μηχάνημα με γρήγορους πυρήνες και την ελαχιστοποίηση του αριθμού των αλλαγών κώδικα. Απλοποιήσαμε επίσης τη διαμόρφωση και εξαλείψαμε τις μακροεντολές στα στοιχεία δεδομένων όπου είναι δυνατόν, καθώς εισάγουν πρόσθετο κλείδωμα.
Για παράδειγμα, η εγκατάλειψη της μακροεντολής κοινότητας snmp, η οποία βρίσκεται συχνά σε τεκμηρίωση και παραδείγματα, στην περίπτωσή μας κατέστησε δυνατή την περαιτέρω επιτάχυνση των NVP κατά περίπου 1,5 φορές.
Μετά από δύο ημέρες στην παραγωγή
Αφαίρεση αναδυόμενων παραθύρων ιστορικού συμβάντων
MCH: – Misha, χρησιμοποιούμε το σύστημα για δύο ημέρες και όλα λειτουργούν. Αλλά μόνο όταν όλα λειτουργούν! Είχαμε προγραμματίσει εργασίες με τη μεταφορά ενός αρκετά μεγάλου τμήματος του δικτύου και ελέγξαμε ξανά με τα χέρια μας τι ανέβηκε και τι όχι.
ΜΜ: - Δεν γίνεται! Ελέγξαμε τα πάντα 10 φορές. Ο διακομιστής χειρίζεται άμεσα ακόμη και την πλήρη μη διαθεσιμότητα του δικτύου.
MCH: - Ναι, καταλαβαίνω τα πάντα: διακομιστής, βάση δεδομένων, κορυφή, austat, αρχεία καταγραφής - όλα είναι γρήγορα... Αλλά κοιτάμε τη διεπαφή ιστού και υπάρχει ένας επεξεργαστής "στο ράφι" στον διακομιστή και αυτό:
ΜΜ: - Είναι σαφές. Ας δούμε τον Ιστό. Βρήκαμε ότι σε μια κατάσταση όπου υπήρχε μεγάλος αριθμός ενεργών περιστατικών, τα περισσότερα ζωντανά γραφικά στοιχεία άρχισαν να λειτουργούν πολύ αργά:
Ο λόγος για αυτό ήταν η δημιουργία αναδυόμενων παραθύρων ιστορικού συμβάντων που δημιουργούνται για κάθε στοιχείο της λίστας. Επομένως, εγκαταλείψαμε τη δημιουργία αυτών των παραθύρων (σχολιάσαμε 5 γραμμές στον κώδικα) και αυτό έλυσε τα προβλήματά μας.
Ο χρόνος φόρτωσης για τα γραφικά στοιχεία, ακόμη και όταν δεν είναι εντελώς διαθέσιμα, έχει μειωθεί από αρκετά λεπτά στα αποδεκτά για εμάς 10-15 δευτερόλεπτα και το ιστορικό μπορεί ακόμα να προβληθεί κάνοντας κλικ στην ώρα:
Μετά τη δουλειά. 2 μήνες πριν
MCH: - Μίσα, φεύγεις; Πρέπει να μιλήσουμε.
ΜΜ: - Δεν είχα σκοπό. Πάλι κάτι με το Zabbix;
MCH: - Όχι, χαλάρωσε! Ήθελα απλώς να πω: όλα λειτουργούν, ευχαριστώ! Έχω μια μπύρα.
Το Zabbix είναι αποτελεσματικό
Το Zabbix είναι ένα αρκετά καθολικό και πλούσιο σύστημα και λειτουργία. Μπορεί να χρησιμοποιηθεί για μικρές εγκαταστάσεις εκτός συσκευασίας, αλλά όσο αυξάνονται οι ανάγκες, πρέπει να βελτιστοποιηθεί. Για να αποθηκεύσετε ένα μεγάλο αρχείο μετρήσεων, χρησιμοποιήστε έναν κατάλληλο χώρο αποθήκευσης:
- μπορείτε να χρησιμοποιήσετε ενσωματωμένα εργαλεία με τη μορφή ενοποίησης με το Elasticsearch ή μεταφόρτωσης ιστορικού σε αρχεία κειμένου (διαθέσιμο από την έκδοση 4).
- Μπορείτε να επωφεληθείτε από την εμπειρία και την ενσωμάτωσή μας με το Clickhouse.
Για να αυξήσετε δραματικά την ταχύτητα συλλογής μετρήσεων, συλλέξτε τις χρησιμοποιώντας ασύγχρονες μεθόδους και μεταδώστε τις μέσω της διεπαφής trapper στον διακομιστή Zabbix. ή μπορείτε να χρησιμοποιήσετε μια ενημερωμένη έκδοση κώδικα για να κάνετε τους Zabbix pollers ασύγχρονους.
Το Zabbix είναι γραμμένο σε C και είναι αρκετά αποτελεσματικό. Η επίλυση πολλών αρχιτεκτονικών σημείων συμφόρησης σάς επιτρέπει να αυξήσετε περαιτέρω την απόδοσή του και, σύμφωνα με την εμπειρία μας, να αποκτήσετε περισσότερες από 100 χιλιάδες μετρήσεις σε ένα μηχάνημα ενός επεξεργαστή.
Το ίδιο έμπλαστρο Zabbix
ΜΜ: – Θέλω να προσθέσω μερικά σημεία. Ολόκληρη η τρέχουσα αναφορά, όλες οι δοκιμές, οι αριθμοί δίνονται για τη διαμόρφωση που χρησιμοποιούμε. Τώρα παίρνουμε περίπου 20 χιλιάδες μετρήσεις ανά δευτερόλεπτο από αυτό. Εάν προσπαθείτε να καταλάβετε εάν αυτό θα λειτουργήσει για εσάς, μπορείτε να συγκρίνετε. Αυτό που συζητήθηκε σήμερα δημοσιεύεται στο GitHub με τη μορφή ενημέρωσης κώδικα:
Το patch περιλαμβάνει:
- πλήρης ενοποίηση με το Clickhouse (τόσο διακομιστή Zabbix όσο και frontend).
- επίλυση προβλημάτων με τον διαχειριστή προεπεξεργαστή.
- ασύγχρονη δημοσκόπηση.
Το patch είναι συμβατό με όλες τις εκδόσεις 4, συμπεριλαμβανομένων των lts. Πιθανότατα, με ελάχιστες αλλαγές θα λειτουργήσει στην έκδοση 3.4.
Σας ευχαριστώ για την προσοχή σας.
ερωτήσεις
Ερώτηση του κοινού (εφεξής – Α): – Καλησπέρα! Παρακαλώ πείτε μου, έχετε σχέδια για εντατική αλληλεπίδραση με την ομάδα του Zabbix ή μαζί τους μαζί σας, ώστε αυτό να μην είναι ένα έμπλαστρο, αλλά φυσιολογική συμπεριφορά του Zabbix;
ΜΜ: – Ναι, σίγουρα θα κάνουμε κάποιες από τις αλλαγές. Κάτι θα γίνει, κάτι θα μείνει στο μπάλωμα.
Α: – Ευχαριστώ πολύ για την εξαιρετική αναφορά! Πείτε μου, μετά την εφαρμογή της ενημέρωσης κώδικα, η υποστήριξη από το Zabbix θα παραμείνει και πώς να συνεχίσετε την ενημέρωση σε υψηλότερες εκδόσεις; Θα είναι δυνατή η ενημέρωση του Zabbix μετά την ενημέρωση κώδικα σε 4.2, 5.0;
ΜΜ: – Δεν μπορώ να πω τίποτα για υποστήριξη. Αν ήμουν η τεχνική υποστήριξη του Zabbix, πιθανότατα θα έλεγα όχι, γιατί αυτός είναι ο κωδικός κάποιου άλλου. Όσον αφορά τη βάση κωδικών 4.2, η θέση μας είναι: «Θα προχωρήσουμε με τον καιρό και θα ενημερώσουμε τους εαυτούς μας στην επόμενη έκδοση». Επομένως, για κάποιο χρονικό διάστημα θα δημοσιεύουμε μια ενημέρωση κώδικα για ενημερωμένες εκδόσεις. Είπα ήδη στην αναφορά: ο αριθμός των αλλαγών με τις εκδόσεις είναι ακόμα αρκετά μικρός. Νομίζω ότι η μετάβαση από το 3.4 στο 4 μας πήρε περίπου 15 λεπτά. Κάτι άλλαξε εκεί, αλλά όχι πολύ σημαντικό.
Α: – Σκοπεύετε λοιπόν να υποστηρίξετε την ενημερωμένη έκδοση κώδικα και μπορείτε να την εγκαταστήσετε με ασφάλεια στην παραγωγή και να λαμβάνετε ενημερώσεις με κάποιο τρόπο στο μέλλον;
ΜΜ: – Το συνιστούμε ανεπιφύλακτα. Αυτό μας λύνει πολλά προβλήματα.
MCH: – Για άλλη μια φορά, θα ήθελα να επιστήσω την προσοχή στο γεγονός ότι οι αλλαγές που δεν αφορούν την αρχιτεκτονική και δεν αφορούν το μπλοκάρισμα ή τις ουρές είναι αρθρωτές, είναι σε ξεχωριστές ενότητες. Ακόμα και με μικρές αλλαγές μπορείτε να τις διατηρήσετε πολύ εύκολα.
ΜΜ: – Αν σας ενδιαφέρουν οι λεπτομέρειες, τότε το «Clickhouse» χρησιμοποιεί τη λεγόμενη βιβλιοθήκη ιστορίας. Είναι λυμένο - είναι αντίγραφο της υποστήριξης Elastics, είναι δηλαδή διαμορφώσιμο. Η ψηφοφορία αλλάζει μόνο τους δημοσκόπους. Πιστεύουμε ότι αυτό θα λειτουργήσει για μεγάλο χρονικό διάστημα.
Α: - Ευχαριστώ πολύ. Πείτε μου, υπάρχει κάποια τεκμηρίωση των αλλαγών που έγιναν;
ΜΜ: – Η τεκμηρίωση είναι ενημερωμένη έκδοση. Προφανώς, με την εισαγωγή του Clickhouse, με την εισαγωγή νέων τύπων pollers, προκύπτουν νέες επιλογές διαμόρφωσης. Ο σύνδεσμος από την τελευταία διαφάνεια έχει μια σύντομη περιγραφή του τρόπου χρήσης του.
Σχετικά με την αντικατάσταση του fping με το nmap
Α: – Πώς τελικά το εφαρμόσατε αυτό; Μπορείτε να δώσετε συγκεκριμένα παραδείγματα: έχετε strappers και εξωτερικό σενάριο; Τι καταλήγει να ελέγχει τόσο γρήγορα έναν τόσο τεράστιο αριθμό κεντρικών υπολογιστών; Πώς εξορύσσετε αυτούς τους οικοδεσπότες; Πρέπει να τα τροφοδοτήσουμε για να κάνουν nmap κάπως, να τα πάρουμε από κάπου, να τα βάλουμε, να τρέξουν κάτι;..
ΜΜ: - Δροσερός. Πολύ σωστή ερώτηση! Το θέμα είναι αυτό. Τροποποιήσαμε τη βιβλιοθήκη (ICMP ping, μέρος του Zabbix) για ελέγχους ICMP, οι οποίοι υποδεικνύουν τον αριθμό των πακέτων - ένα (1) και ο κώδικας προσπαθεί να χρησιμοποιήσει το nmap. Δηλαδή, αυτό είναι το εσωτερικό έργο του Zabbix, το οποίο έχει γίνει το εσωτερικό έργο του pinger. Συνεπώς, δεν απαιτείται συγχρονισμός ή χρήση παγιδευτή. Αυτό έγινε σκόπιμα για να μείνει το σύστημα άθικτο και να μην χρειαστεί να ασχοληθούμε με το συγχρονισμό δύο συστημάτων βάσης δεδομένων: τι να ελέγξουμε, να ανεβάσουμε μέσω του poller και είναι χαλασμένο το ανέβασμα μας;... Αυτό είναι πολύ πιο απλό.
Α: – Λειτουργεί και για πληρεξούσιους;
ΜΜ: – Ναι, αλλά δεν ελέγξαμε. Ο κωδικός ψηφοφορίας είναι ο ίδιος τόσο στο Zabbix όσο και στον διακομιστή. Πρέπει να λειτουργεί. Επιτρέψτε μου να τονίσω για άλλη μια φορά: η απόδοση του συστήματος είναι τέτοια που δεν χρειαζόμαστε πληρεξούσιο.
MCH: – Η σωστή απάντηση στην ερώτηση είναι: "Γιατί χρειάζεστε έναν πληρεξούσιο με ένα τέτοιο σύστημα;" Μόνο λόγω ΝΑΤ ή παρακολούθησης μέσω κάποιου είδους αργού καναλιού...
Α: – Και χρησιμοποιείτε το Zabbix ως allertor, αν καταλαβαίνω καλά. Ή τα γραφικά σας (όπου βρίσκεται το επίπεδο αρχειοθέτησης) έχουν μετακινηθεί σε άλλο σύστημα, όπως το Grafana; Ή δεν χρησιμοποιείτε αυτή τη λειτουργία;
ΜΜ: – Θα τονίσω για άλλη μια φορά: επιτύχαμε την πλήρη ολοκλήρωση. Ρίχνουμε ιστορία στο Clickhouse, αλλά ταυτόχρονα αλλάξαμε το frontend της php. Το frontend Php πηγαίνει στο Clickhouse και κάνει όλα τα γραφικά από εκεί. Ταυτόχρονα, για να είμαστε ειλικρινείς, έχουμε ένα εξάρτημα που δημιουργεί δεδομένα σε άλλα συστήματα απεικόνισης γραφικών από το ίδιο Clickhouse, από τα ίδια δεδομένα Zabbix.
MCH: – Και στο “Grafan”.
Πώς ελήφθησαν οι αποφάσεις για την κατανομή των πόρων;
Α: – Μοιραστείτε λίγο από την εσωτερική σας κουζίνα. Πώς πάρθηκε η απόφαση ότι ήταν απαραίτητο να διατεθούν πόροι για σοβαρή μεταποίηση του προϊόντος; Αυτοί είναι, γενικά, ορισμένοι κίνδυνοι. Και πείτε μου, στο πλαίσιο του γεγονότος ότι πρόκειται να υποστηρίξετε νέες εκδόσεις: πώς δικαιολογεί αυτή η απόφαση από διαχειριστική άποψη;
ΜΜ: – Προφανώς, δεν είπαμε πολύ καλά το δράμα της ιστορίας. Βρεθήκαμε σε μια κατάσταση που έπρεπε να γίνει κάτι και ουσιαστικά πήγαμε με δύο παράλληλες ομάδες:
- Το ένα ήταν το λανσάρισμα ενός συστήματος παρακολούθησης χρησιμοποιώντας νέες μεθόδους: παρακολούθηση ως υπηρεσία, ένα τυπικό σύνολο λύσεων ανοιχτού κώδικα που συνδυάζουμε και στη συνέχεια προσπαθούμε να αλλάξουμε την επιχειρηματική διαδικασία προκειμένου να συνεργαστούμε με το νέο σύστημα παρακολούθησης.
- Ταυτόχρονα, είχαμε έναν ενθουσιώδη προγραμματιστή που το έκανε αυτό (για τον εαυτό του). Έτυχε να κερδίσει.
Α: – Και ποιο είναι το μέγεθος της ομάδας;
MCH: - Είναι μπροστά σου.
Α: – Λοιπόν, όπως πάντα, χρειάζεστε έναν παθιασμένο;
ΜΜ: – Δεν ξέρω τι είναι παθιασμένος.
Α: - Σε αυτή την περίπτωση, προφανώς, εσείς. Ευχαριστώ πολύ, είσαι υπέροχος.
ΜΜ: - Ευχαριστώ.
Σχετικά με τα patches για το Zabbix
Α: – Για ένα σύστημα που χρησιμοποιεί διακομιστή μεσολάβησης (για παράδειγμα, σε ορισμένα κατανεμημένα συστήματα), είναι δυνατή η προσαρμογή και η ενημέρωση κώδικα, ας πούμε, των pollers, των proxies και εν μέρει του προεπεξεργαστή του ίδιου του Zabbix; και την αλληλεπίδρασή τους; Είναι δυνατό να βελτιστοποιηθούν οι υπάρχουσες εξελίξεις για ένα σύστημα με πολλαπλούς μεσολάβησης;
ΜΜ: – Γνωρίζω ότι ο διακομιστής Zabbix συναρμολογείται με χρήση διακομιστή μεσολάβησης (ο κώδικας μεταγλωττίζεται και λαμβάνεται). Δεν το έχουμε δοκιμάσει στην παραγωγή. Δεν είμαι σίγουρος για αυτό, αλλά νομίζω ότι ο διαχειριστής προεπεξεργαστή δεν χρησιμοποιείται στον διακομιστή μεσολάβησης. Η αποστολή του διακομιστή μεσολάβησης είναι να πάρει ένα σύνολο μετρήσεων από το Zabbix, να τις συγχωνεύσει (καταγράφει επίσης τη διαμόρφωση, την τοπική βάση δεδομένων) και να το επιστρέψει στον διακομιστή Zabbix. Ο ίδιος ο διακομιστής θα κάνει τότε την προεπεξεργασία όταν τη λάβει.
Το ενδιαφέρον για πληρεξούσιους είναι κατανοητό. Θα το ελέγξουμε. Αυτό είναι ένα ενδιαφέρον θέμα.
Α: – Η ιδέα ήταν η εξής: εάν μπορείτε να επιδιορθώσετε τους δημοσκόπους, μπορείτε να τους επιδιορθώσετε στο διακομιστή μεσολάβησης και να επιδιορθώσετε την αλληλεπίδραση με τον διακομιστή και να προσαρμόσετε τον προεπεξεργαστή για αυτούς τους σκοπούς μόνο στον διακομιστή.
ΜΜ: – Νομίζω ότι είναι ακόμα πιο απλό. Παίρνετε τον κώδικα, εφαρμόζετε μια ενημερωμένη έκδοση κώδικα και, στη συνέχεια, τη διαμορφώνετε με τον τρόπο που χρειάζεστε - συλλέγετε διακομιστές μεσολάβησης (για παράδειγμα, με ODBC) και διανέμετε τον διορθωμένο κώδικα σε όλα τα συστήματα. Όπου είναι απαραίτητο - συλλέξτε έναν διακομιστή μεσολάβησης, όπου είναι απαραίτητο - έναν διακομιστή.
Α: – Πιθανότατα, δεν θα χρειαστεί να επιδιορθώσετε τη μετάδοση του διακομιστή μεσολάβησης επιπλέον στον διακομιστή;
MCH: - Όχι, είναι στάνταρ.
ΜΜ: – Στην πραγματικότητα, μια από τις ιδέες δεν ακούστηκε. Διατηρούσαμε πάντα μια ισορροπία μεταξύ της έκρηξης των ιδεών και του όγκου των αλλαγών και της ευκολίας υποστήριξης.
Μερικές διαφημίσεις 🙂
Σας ευχαριστούμε που μείνατε μαζί μας. Σας αρέσουν τα άρθρα μας; Θέλετε να δείτε πιο ενδιαφέρον περιεχόμενο; Υποστηρίξτε μας κάνοντας μια παραγγελία ή προτείνοντας σε φίλους, , ένα μοναδικό ανάλογο διακομιστών εισαγωγικού επιπέδου, το οποίο εφευρέθηκε από εμάς για εσάς: (διατίθεται με RAID1 και RAID10, έως 24 πυρήνες και έως 40 GB DDR4).
Το Dell R730xd 2 φορές φθηνότερο στο κέντρο δεδομένων Equinix Tier IV στο Άμστερνταμ; Μόνο εδώ στην Ολλανδία! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - από 99$! Διαβάστε σχετικά
Πηγή: www.habr.com