Τα σύγχρονα κέντρα δεδομένων έχουν εγκατεστημένες εκατοντάδες ενεργές συσκευές, που καλύπτονται από διαφορετικούς τύπους παρακολούθησης. Αλλά ακόμη και ένας ιδανικός μηχανικός με τέλεια παρακολούθηση στο χέρι θα είναι σε θέση να ανταποκριθεί σωστά σε μια αστοχία δικτύου μέσα σε λίγα μόνο λεπτά. Σε μια αναφορά στο συνέδριο Next Hop 2020, παρουσίασα μια μεθοδολογία σχεδιασμού δικτύου DC, η οποία έχει ένα μοναδικό χαρακτηριστικό - το κέντρο δεδομένων αυτοθεραπεύεται σε χιλιοστά του δευτερολέπτου. Πιο συγκεκριμένα, ο μηχανικός διορθώνει ήρεμα το πρόβλημα, ενώ οι υπηρεσίες απλά δεν το αντιλαμβάνονται.
Για πολλούς μηχανικούς δικτύου, ένα δίκτυο κέντρων δεδομένων ξεκινά, φυσικά, με ToR, με έναν διακόπτη στο rack. Το ToR έχει συνήθως δύο τύπους συνδέσμων. Οι μικροί πάνε στους διακομιστές, άλλοι -είναι Ν φορές περισσότεροι- πάνε προς τις ράχες του πρώτου επιπέδου, δηλαδή στους ανοδικούς συνδέσμους του. Οι uplinks συνήθως θεωρούνται ίσες και η κίνηση μεταξύ των uplinks εξισορροπείται με βάση έναν κατακερματισμό από το 5-tup, το οποίο περιλαμβάνει proto, src_ip, dst_ip, src_port, dst_port. Δεν υπάρχουν εκπλήξεις εδώ.
Στη συνέχεια, πώς μοιάζει η αρχιτεκτονική του σχεδίου; Οι σπονδυλικές στήλες του πρώτου επιπέδου δεν συνδέονται μεταξύ τους, αλλά συνδέονται μέσω υπεράκανθων. Το γράμμα X θα είναι υπεύθυνο για τα superspines, είναι σχεδόν σαν μια διασταύρωση.
Και είναι ξεκάθαρο ότι, από την άλλη, τα tori συνδέονται με όλες τις ράχες του πρώτου επιπέδου. Τι είναι σημαντικό σε αυτή την εικόνα; Αν έχουμε αλληλεπίδραση μέσα στο rack, τότε η αλληλεπίδραση, φυσικά, περνάει από το ToR. Εάν η αλληλεπίδραση συμβαίνει μέσα στη μονάδα, τότε η αλληλεπίδραση λαμβάνει χώρα μέσω των ακίδων πρώτου επιπέδου. Εάν η αλληλεπίδραση είναι διαρθρωτική - όπως εδώ, ToR 1 και ToR 2 - τότε η αλληλεπίδραση θα περάσει μέσα από ακίδες τόσο του πρώτου όσο και του δεύτερου επιπέδου.
Θεωρητικά, μια τέτοια αρχιτεκτονική είναι εύκολα επεκτάσιμη. Εάν έχουμε χωρητικότητα θύρας, ελεύθερο χώρο στο κέντρο δεδομένων και προκαθορισμένη οπτική ίνα, τότε ο αριθμός των λωρίδων μπορεί πάντα να αυξηθεί, αυξάνοντας έτσι τη συνολική χωρητικότητα του συστήματος. Αυτό είναι πολύ εύκολο να γίνει σε χαρτί. Θα ήταν έτσι στη ζωή. Αλλά η σημερινή ιστορία δεν αφορά αυτό.
Θέλω να βγουν τα σωστά συμπεράσματα. Έχουμε πολλά μονοπάτια μέσα στο κέντρο δεδομένων. Είναι υπό όρους ανεξάρτητοι. Μία διαδρομή μέσα στο κέντρο δεδομένων είναι δυνατή μόνο εντός ToR. Μέσα στη μονάδα, έχουμε τον αριθμό των μονοπατιών ίσο με τον αριθμό των λωρίδων. Ο αριθμός των διαδρομών μεταξύ των μονάδων είναι ίσος με το γινόμενο του αριθμού των επιπέδων και του αριθμού των υπεράκρων σε κάθε επίπεδο. Για να το κάνω πιο σαφές, για να κατανοήσω την κλίμακα, θα δώσω αριθμούς που ισχύουν για ένα από τα κέντρα δεδομένων Yandex.
Υπάρχουν οκτώ αεροπλάνα, κάθε αεροπλάνο έχει 32 superspines. Ως αποτέλεσμα, αποδεικνύεται ότι υπάρχουν οκτώ μονοπάτια μέσα στη μονάδα και με την αλληλεπίδραση μεταξύ των μονάδων υπάρχουν ήδη 256 από αυτά.
Δηλαδή, εάν αναπτύσσουμε το Cookbook, προσπαθώντας να μάθουμε πώς να χτίζουμε κέντρα δεδομένων με ανοχή σε σφάλματα που αυτοθεραπεύονται, τότε η επίπεδη αρχιτεκτονική είναι η σωστή επιλογή. Λύνει το πρόβλημα της κλιμάκωσης και θεωρητικά είναι εύκολο. Υπάρχουν πολλά ανεξάρτητα μονοπάτια. Το ερώτημα παραμένει: πώς επιβιώνει μια τέτοια αρχιτεκτονική από αποτυχίες; Υπάρχουν διάφορες αστοχίες. Και αυτό θα το συζητήσουμε τώρα.
Ας «αρρωστήσει» ένας από τους υπεράκανθους μας. Εδώ επέστρεψα στην αρχιτεκτονική των δύο επιπέδων. Θα παραμείνουμε σε αυτά ως παράδειγμα γιατί απλά θα είναι πιο εύκολο να δούμε τι συμβαίνει με λιγότερα κινούμενα μέρη. Αφήστε το Χ11 να αρρωστήσει. Πώς θα επηρεάσει αυτό τις υπηρεσίες που ζουν μέσα σε κέντρα δεδομένων; Πολλά εξαρτώνται από το πώς φαίνεται στην πραγματικότητα η αποτυχία.
Αν η αστοχία είναι καλή, πιάνεται στο επίπεδο αυτοματισμού του ίδιου BFD, ο αυτοματισμός βάζει ευχάριστα τις προβληματικές αρθρώσεις και απομονώνει το πρόβλημα, τότε όλα είναι καλά. Έχουμε πολλά μονοπάτια, η κυκλοφορία μεταφέρεται άμεσα σε εναλλακτικές διαδρομές και οι υπηρεσίες δεν θα παρατηρήσουν τίποτα. Αυτό είναι ένα καλό σενάριο.
Ένα κακό σενάριο είναι αν έχουμε συνεχείς απώλειες, και ο αυτοματισμός δεν παρατηρεί το πρόβλημα. Για να κατανοήσουμε πώς αυτό επηρεάζει μια εφαρμογή, θα πρέπει να αφιερώσουμε λίγο χρόνο συζητώντας πώς λειτουργεί το TCP.
Ελπίζω να μην σοκάρω κανέναν με αυτές τις πληροφορίες: Το TCP είναι ένα πρωτόκολλο επιβεβαίωσης μετάδοσης. Δηλαδή, στην απλούστερη περίπτωση, ο αποστολέας στέλνει δύο πακέτα και λαμβάνει μια αθροιστική αποδοχή σε αυτά: "Έλαβα δύο πακέτα".
Μετά από αυτό, θα στείλει άλλα δύο πακέτα και η κατάσταση θα επαναληφθεί. Ζητώ προκαταβολικά συγγνώμη για κάποια απλοποίηση. Αυτό το σενάριο είναι σωστό εάν το παράθυρο (ο αριθμός των πακέτων κατά την πτήση) είναι δύο. Φυσικά, στη γενική περίπτωση αυτό δεν ισχύει απαραίτητα. Αλλά το μέγεθος του παραθύρου δεν επηρεάζει το πλαίσιο προώθησης πακέτων.
Τι θα συμβεί αν χάσουμε το πακέτο 3; Σε αυτήν την περίπτωση, ο παραλήπτης θα λάβει τα πακέτα 1, 2 και 4. Και θα πει ρητά στον αποστολέα χρησιμοποιώντας την επιλογή SACK: "Ξέρετε, έφτασαν τρία, αλλά η μέση χάθηκε." Λέει, "Ack 2, SACK 4."
Αυτή τη στιγμή, ο αποστολέας χωρίς κανένα πρόβλημα επαναλαμβάνει ακριβώς το πακέτο που χάθηκε.
Αλλά αν χαθεί το τελευταίο πακέτο στο παράθυρο, η κατάσταση θα φαίνεται εντελώς διαφορετική.
Ο παραλήπτης λαμβάνει τα τρία πρώτα πακέτα και πρώτα από όλα αρχίζει να περιμένει. Χάρη σε ορισμένες βελτιστοποιήσεις στη στοίβα TCP του πυρήνα του Linux, θα περιμένει για ένα ζευγαρωμένο πακέτο εκτός εάν οι σημαίες υποδεικνύουν ρητά ότι είναι το τελευταίο πακέτο ή κάτι παρόμοιο. Θα περιμένει μέχρι να λήξει το χρονικό όριο καθυστέρησης ACK και στη συνέχεια θα στείλει μια επιβεβαίωση για τα τρία πρώτα πακέτα. Τώρα όμως ο αποστολέας θα περιμένει. Δεν ξέρει αν το τέταρτο πακέτο έχει χαθεί ή πρόκειται να φτάσει. Και για να μην υπερφορτωθεί το δίκτυο, θα προσπαθήσει να περιμένει μια ρητή ένδειξη ότι το πακέτο έχει χαθεί ή να λήξει το χρονικό όριο RTO.
Τι είναι το χρονικό όριο RTO; Αυτό είναι το μέγιστο του RTT που υπολογίζεται από τη στοίβα TCP και κάποια σταθερά. Τι είδους σταθερά είναι αυτή, θα συζητήσουμε τώρα.
Αλλά το σημαντικό είναι ότι αν είμαστε πάλι άτυχοι και χαθεί ξανά το τέταρτο πακέτο, τότε το RTO διπλασιάζεται. Δηλαδή, κάθε αποτυχημένη προσπάθεια σημαίνει διπλασιασμό του τάιμ άουτ.
Τώρα ας δούμε με τι ισούται αυτή η βάση. Από προεπιλογή, το ελάχιστο RTO είναι 200 ms. Αυτό είναι το ελάχιστο RTO για πακέτα δεδομένων. Για τα πακέτα SYN είναι διαφορετικό, 1 δευτερόλεπτο. Όπως μπορείτε να δείτε, ακόμη και η πρώτη προσπάθεια επανάληψης αποστολής πακέτων θα διαρκέσει 100 φορές περισσότερο από το RTT μέσα στο κέντρο δεδομένων.
Τώρα ας επιστρέψουμε στο σενάριο μας. Τι συμβαίνει με την υπηρεσία; Η υπηρεσία αρχίζει να χάνει πακέτα. Αφήστε την υπηρεσία να είναι υπό όρους τυχερή στην αρχή και να χάσει κάτι στη μέση του παραθύρου, μετά λαμβάνει ένα SACK και στέλνει ξανά τα πακέτα που χάθηκαν.
Αλλά αν η κακή τύχη επαναληφθεί, τότε έχουμε RTO. Τι είναι σημαντικό εδώ; Ναι, έχουμε πολλά μονοπάτια στο δίκτυό μας. Αλλά η κίνηση TCP μιας συγκεκριμένης σύνδεσης TCP θα συνεχίσει να περνά από την ίδια σπασμένη στοίβα. Οι απώλειες πακέτων, με την προϋπόθεση ότι αυτό το μαγικό X11 μας δεν σβήνει από μόνο του, δεν οδηγεί σε ροή κυκλοφορίας σε περιοχές που δεν είναι προβληματικές. Προσπαθούμε να παραδώσουμε το πακέτο μέσα από την ίδια σπασμένη στοίβα. Αυτό οδηγεί σε μια διαδοχική αποτυχία: ένα κέντρο δεδομένων είναι ένα σύνολο εφαρμογών που αλληλεπιδρούν και ορισμένες από τις συνδέσεις TCP όλων αυτών των εφαρμογών αρχίζουν να υποβαθμίζονται - επειδή το superspine επηρεάζει όλες τις εφαρμογές που υπάρχουν μέσα στο κέντρο δεδομένων. Όπως λέει και η παροιμία: αν δεν πέταξες ένα άλογο, το άλογο ήταν κουτσό. το άλογο ήταν κουτσό - η αναφορά δεν παραδόθηκε. η έκθεση δεν παραδόθηκε - χάσαμε τον πόλεμο. Μόνο που εδώ η καταμέτρηση είναι σε δευτερόλεπτα από τη στιγμή που θα παρουσιαστεί το πρόβλημα μέχρι το στάδιο της υποβάθμισης που αρχίζουν να νιώθουν οι υπηρεσίες. Αυτό σημαίνει ότι οι χρήστες μπορεί να χάνουν κάτι κάπου.
Υπάρχουν δύο κλασικές λύσεις που αλληλοσυμπληρώνονται. Το πρώτο είναι υπηρεσίες που προσπαθούν να βάλουν καλαμάκια και να λύσουν το πρόβλημα ως εξής: «Ας τροποποιήσουμε κάτι στη στοίβα TCP. Ας κάνουμε χρονικά όρια σε επίπεδο εφαρμογής ή μακροχρόνιες περιόδους σύνδεσης TCP με εσωτερικούς ελέγχους υγείας." Το πρόβλημα είναι ότι τέτοιες λύσεις: α) δεν κλιμακώνονται καθόλου. β) ελέγχονται πολύ κακώς. Δηλαδή, ακόμα κι αν η υπηρεσία ρυθμίσει κατά λάθος τη στοίβα TCP με τρόπο που την κάνει καλύτερη, πρώτον, είναι απίθανο να εφαρμοστεί για όλες τις εφαρμογές και όλα τα κέντρα δεδομένων και δεύτερον, πιθανότατα, δεν θα καταλάβει ότι έγινε σωστά, και τι όχι. Δουλεύει δηλαδή, αλλά δουλεύει άσχημα και δεν κλιμακώνεται. Και αν υπάρχει πρόβλημα δικτύου, ποιος φταίει; Φυσικά, NOC. Τι κάνει η NOC;
Πολλές υπηρεσίες πιστεύουν ότι στο NOC η δουλειά συμβαίνει κάτι τέτοιο. Αλλά για να είμαι ειλικρινής, όχι μόνο αυτό.
Το NOC στο κλασικό σχήμα ασχολείται με την ανάπτυξη πολλών συστημάτων παρακολούθησης. Πρόκειται για παρακολούθηση μαύρου και λευκού κουτιού. Σχετικά με ένα παράδειγμα παρακολούθησης της σπονδυλικής στήλης μαύρου κουτιού Ο Alexander Klimenko στο τελευταίο Next Hop. Παρεμπιπτόντως, αυτή η παρακολούθηση λειτουργεί. Αλλά ακόμα και η ιδανική παρακολούθηση θα έχει χρονική καθυστέρηση. Συνήθως αυτό είναι λίγα λεπτά. Αφού σβήσει, οι εφημερεύοντες μηχανικοί χρειάζονται χρόνο για να ελέγξουν ξανά τη λειτουργία του, να εντοπίσουν το πρόβλημα και στη συνέχεια να σβήσουν την προβληματική περιοχή. Δηλαδή, στην καλύτερη περίπτωση, η αντιμετώπιση του προβλήματος διαρκεί 5 λεπτά, στη χειρότερη περίπτωση, 20 λεπτά, εάν δεν είναι άμεσα εμφανές πού συμβαίνουν οι απώλειες. Είναι σαφές ότι όλο αυτό το διάστημα - 5 ή 20 λεπτά - οι υπηρεσίες μας θα συνεχίσουν να υποφέρουν, κάτι που μάλλον δεν είναι καλό.
Τι πραγματικά θα θέλατε να λάβετε; Έχουμε πολλούς τρόπους. Και τα προβλήματα προκύπτουν ακριβώς επειδή οι ροές TCP που είναι άτυχες συνεχίζουν να χρησιμοποιούν την ίδια διαδρομή. Χρειαζόμαστε κάτι που θα μας επιτρέπει να χρησιμοποιούμε πολλαπλές διαδρομές σε μία μόνο σύνδεση TCP. Φαίνεται ότι έχουμε μια λύση. Υπάρχει TCP, το οποίο ονομάζεται TCP πολλαπλών διαδρομών, δηλαδή TCP για πολλαπλές διαδρομές. Είναι αλήθεια ότι αναπτύχθηκε για μια εντελώς διαφορετική εργασία - για smartphone που έχουν πολλές συσκευές δικτύου. Για να μεγιστοποιήσετε τη μεταφορά ή να κάνετε την κύρια/εφεδρική λειτουργία, αναπτύχθηκε ένας μηχανισμός που δημιουργεί πολλαπλά νήματα (περιόδους σύνδεσης) με διαφάνεια στην εφαρμογή και σας επιτρέπει να κάνετε εναλλαγή μεταξύ τους σε περίπτωση αποτυχίας. Ή, όπως είπα, μεγιστοποιήστε το σερί.
Αλλά υπάρχει μια απόχρωση εδώ. Για να καταλάβουμε τι είναι, θα πρέπει να δούμε πώς δημιουργούνται τα νήματα.
Τα νήματα εγκαθίστανται διαδοχικά. Το πρώτο νήμα εγκαθίσταται πρώτα. Στη συνέχεια ορίζονται τα επόμενα νήματα χρησιμοποιώντας το cookie που έχει ήδη συμφωνηθεί σε αυτό το νήμα. Και εδώ είναι το πρόβλημα.
Το πρόβλημα είναι ότι αν το πρώτο νήμα δεν εδραιωθεί, το δεύτερο και το τρίτο νήμα δεν θα προκύψουν ποτέ. Δηλαδή, το TCP πολλαπλών διαδρομών δεν επιλύει την απώλεια ενός πακέτου SYN στην πρώτη ροή. Και αν χαθεί το SYN, το TCP πολλαπλών διαδρομών μετατρέπεται σε κανονικό TCP. Αυτό σημαίνει ότι σε ένα περιβάλλον κέντρου δεδομένων δεν θα μας βοηθήσει να λύσουμε το πρόβλημα των απωλειών στο εργοστάσιο και να μάθουμε να χρησιμοποιούμε πολλαπλές διαδρομές σε περίπτωση βλάβης.
Τι μπορεί να μας βοηθήσει; Μερικοί από εσάς έχετε ήδη μαντέψει από τον τίτλο ότι ένα σημαντικό πεδίο στην περαιτέρω ιστορία μας θα είναι το πεδίο κεφαλίδας ετικέτας ροής IPv6. Πράγματι, αυτό είναι ένα πεδίο που εμφανίζεται στο v6, δεν είναι στο v4, καταλαμβάνει 20 bit και υπάρχει διαμάχη για τη χρήση του εδώ και πολύ καιρό. Αυτό είναι πολύ ενδιαφέρον - υπήρξαν διαφωνίες, κάτι διορθώθηκε στο RFC και ταυτόχρονα εμφανίστηκε μια υλοποίηση στον πυρήνα του Linux, η οποία δεν τεκμηριώθηκε πουθενά.
Σας προσκαλώ να πάτε μαζί μου για μια μικρή έρευνα. Ας ρίξουμε μια ματιά στο τι συμβαίνει στον πυρήνα του Linux τα τελευταία χρόνια.
έτος 2014. Ένας μηχανικός από μια μεγάλη και σεβαστή εταιρεία προσθέτει στη λειτουργικότητα του πυρήνα Linux την εξάρτηση της τιμής της ετικέτας ροής από τον κατακερματισμό υποδοχής. Τι προσπαθούσαν να διορθώσουν εδώ; Αυτό σχετίζεται με το RFC 6438, το οποίο συζήτησε το ακόλουθο θέμα. Μέσα στο κέντρο δεδομένων, το IPv4 ενσωματώνεται συχνά σε πακέτα IPv6, επειδή το ίδιο το εργοστάσιο είναι IPv6, αλλά το IPv4 πρέπει με κάποιο τρόπο να δοθεί έξω. Για μεγάλο χρονικό διάστημα υπήρχαν προβλήματα με διακόπτες που δεν μπορούσαν να κοιτάξουν κάτω από δύο κεφαλίδες IP για να φτάσουν στο TCP ή στο UDP και να βρουν εκεί τα src_ports, dst_ports. Αποδείχθηκε ότι ο κατακερματισμός, αν κοιτάξετε τις δύο πρώτες κεφαλίδες IP, αποδείχθηκε ότι ήταν σχεδόν σταθερός. Για να αποφευχθεί αυτό, έτσι ώστε η εξισορρόπηση αυτής της ενθυλακωμένης κυκλοφορίας να λειτουργεί σωστά, προτάθηκε να προστεθεί ο κατακερματισμός του πακέτου των 5 ενθυλακωμένων στην τιμή του πεδίου ετικέτας ροής. Περίπου το ίδιο έγινε και για άλλα σχήματα ενθυλάκωσης, για το UDP, για το GRE, το τελευταίο χρησιμοποίησε το πεδίο κλειδιού GRE. Με τον ένα ή τον άλλο τρόπο, οι στόχοι εδώ είναι ξεκάθαροι. Και τουλάχιστον σε εκείνο το σημείο του χρόνου ήταν χρήσιμοι.
Το 2015, ένα νέο patch προέρχεται από τον ίδιο σεβαστό μηχανικό. Είναι πολύ ενδιαφέρον. Λέει το εξής - θα τυχαιοποιήσουμε τον κατακερματισμό σε περίπτωση αρνητικού συμβάντος δρομολόγησης. Τι είναι ένα αρνητικό συμβάν δρομολόγησης; Αυτό είναι το RTO που συζητήσαμε νωρίτερα, δηλαδή η απώλεια της ουράς του παραθύρου είναι ένα γεγονός που είναι πραγματικά αρνητικό. Είναι αλήθεια ότι είναι σχετικά δύσκολο να μαντέψει κανείς ότι είναι αυτό.
2016, άλλη μια αξιόπιστη εταιρεία, επίσης μεγάλη. Αποσυναρμολογεί τα τελευταία δεκανίκια και το κάνει έτσι ώστε ο κατακερματισμός, που προηγουμένως κάναμε τυχαία, τώρα να αλλάζει για κάθε αναμετάδοση SYN και μετά από κάθε timeout RTO. Και σε αυτήν την επιστολή, για πρώτη και τελευταία φορά, δηλώνεται ο τελικός στόχος - να διασφαλιστεί ότι η κυκλοφορία σε περίπτωση απωλειών ή συμφόρησης καναλιών έχει τη δυνατότητα να επαναδρομολογηθεί ήπια και να χρησιμοποιήσει πολλαπλές διαδρομές. Φυσικά, μετά από αυτό υπήρξαν πολλές δημοσιεύσεις, μπορείτε να τις βρείτε εύκολα.
Αν και όχι, δεν μπορείτε, γιατί δεν έχει υπάρξει ούτε μία δημοσίευση για αυτό το θέμα. Αλλά ξέρουμε!
Και αν δεν καταλαβαίνετε πλήρως τι έγινε, θα σας το πω τώρα.
Τι έγινε, ποια λειτουργικότητα προστέθηκε στον πυρήνα του Linux; Το txhash αλλάζει σε τυχαία τιμή μετά από κάθε συμβάν RTO. Αυτό είναι το πολύ αρνητικό αποτέλεσμα της δρομολόγησης. Ο κατακερματισμός εξαρτάται από αυτό το txhash και η ετικέτα ροής εξαρτάται από τον κατακερματισμό skb. Υπάρχουν ορισμένοι υπολογισμοί για τις συναρτήσεις εδώ· όλες οι λεπτομέρειες δεν μπορούν να τοποθετηθούν σε μία διαφάνεια. Αν κάποιος είναι περίεργος, μπορείτε να διαβάσετε τον κώδικα του πυρήνα και να ελέγξετε.
Τι είναι σημαντικό εδώ; Η τιμή του πεδίου ετικέτας ροής αλλάζει σε τυχαίο αριθμό μετά από κάθε RTO. Πώς επηρεάζει αυτό την ατυχή ροή TCP μας;
Εάν παρουσιαστεί SACK, δεν αλλάζει τίποτα επειδή προσπαθούμε να στείλουμε ξανά ένα γνωστό χαμένο πακέτο. Μέχρι εδώ καλά.
Αλλά στην περίπτωση του RTO, με την προϋπόθεση ότι έχουμε προσθέσει μια ετικέτα ροής στη συνάρτηση κατακερματισμού στο ToR, η κίνηση μπορεί να ακολουθήσει διαφορετική διαδρομή. Και όσο περισσότερες λωρίδες, τόσο μεγαλύτερη είναι η πιθανότητα να βρει μια διαδρομή που δεν επηρεάζεται από μια αστοχία σε μια συγκεκριμένη συσκευή.
Ένα πρόβλημα παραμένει - RTO. Φυσικά, υπάρχει και άλλη διαδρομή, αλλά χάνεται πολύς χρόνος σε αυτό. 200 ms είναι πολλά. Ένα δεύτερο είναι απολύτως άγριο. Προηγουμένως, μίλησα για χρονικά όρια που διαμορφώνονται οι υπηρεσίες. Έτσι, ένα δεύτερο είναι ένα χρονικό όριο, το οποίο συνήθως ρυθμίζεται από την υπηρεσία σε επίπεδο εφαρμογής, και σε αυτό η υπηρεσία θα είναι ακόμη και σχετικά σωστή. Επιπλέον, επαναλαμβάνω, το πραγματικό RTT μέσα σε ένα σύγχρονο κέντρο δεδομένων είναι περίπου 1 χιλιοστό του δευτερολέπτου.
Τι μπορείτε να κάνετε με τα χρονικά όρια RTO; Το χρονικό όριο, το οποίο είναι υπεύθυνο για το RTO σε περίπτωση απώλειας πακέτων δεδομένων, μπορεί να ρυθμιστεί σχετικά εύκολα από το χώρο χρήστη: υπάρχει ένα βοηθητικό πρόγραμμα IP και μία από τις παραμέτρους του περιέχει το ίδιο rto_min. Λαμβάνοντας υπόψη ότι το RTO, φυσικά, πρέπει να προσαρμοστεί όχι συνολικά, αλλά για δεδομένα προθέματα, ένας τέτοιος μηχανισμός φαίνεται αρκετά λειτουργικός.
Είναι αλήθεια ότι με το SYN_RTO όλα είναι κάπως χειρότερα. Είναι φυσικά καρφωμένο. Ο πυρήνας έχει σταθερή τιμή 1 δευτερόλεπτο, και αυτό είναι. Δεν μπορείτε να φτάσετε εκεί από το χώρο χρήστη. Υπάρχει μόνο ένας τρόπος.
Το eBPF έρχεται στη διάσωση. Για να το θέσω απλά, αυτά είναι μικρά προγράμματα C. Μπορούν να εισαχθούν σε άγκιστρα σε διαφορετικά σημεία κατά την εκτέλεση της στοίβας πυρήνα και της στοίβας TCP, με τα οποία μπορείτε να αλλάξετε πολύ μεγάλο αριθμό ρυθμίσεων. Γενικά, το eBPF είναι μια μακροπρόθεσμη τάση. Αντί να κόψει δεκάδες νέες παραμέτρους sysctl και να επεκτείνει το βοηθητικό πρόγραμμα IP, η κίνηση κινείται προς το eBPF και επεκτείνει τη λειτουργικότητά του. Χρησιμοποιώντας το eBPF, μπορείτε να αλλάξετε δυναμικά τα στοιχεία ελέγχου συμφόρησης και διάφορες άλλες ρυθμίσεις TCP.
Αλλά είναι σημαντικό για εμάς να μπορεί να χρησιμοποιηθεί για την αλλαγή των τιμών SYN_RTO. Επιπλέον, υπάρχει ένα δημοσιευμένο παράδειγμα: . Τι έχει γίνει εδώ; Το παράδειγμα λειτουργεί, αλλά από μόνο του είναι πολύ τραχύ. Εδώ θεωρείται ότι μέσα στο κέντρο δεδομένων συγκρίνουμε τα πρώτα 44 bit· εάν ταιριάζουν, τότε είμαστε μέσα στο κέντρο δεδομένων. Και σε αυτήν την περίπτωση αλλάζουμε την τιμή χρονικού ορίου SYN_RTO σε 4ms. Το ίδιο έργο μπορεί να γίνει πολύ πιο κομψά. Αλλά αυτό το απλό παράδειγμα δείχνει ότι αυτό είναι α) δυνατό. β) σχετικά απλό.
Τι γνωρίζουμε ήδη; Το γεγονός ότι η αρχιτεκτονική επιπέδου επιτρέπει την κλιμάκωση, αποδεικνύεται εξαιρετικά χρήσιμο για εμάς όταν ενεργοποιούμε την ετικέτα ροής στο ToR και έχουμε τη δυνατότητα να ρέουμε γύρω από προβληματικές περιοχές. Ο καλύτερος τρόπος για να μειώσετε τις τιμές RTO και SYN-RTO είναι να χρησιμοποιήσετε προγράμματα eBPF. Το ερώτημα παραμένει: είναι ασφαλές να χρησιμοποιήσετε μια ετικέτα ροής για εξισορρόπηση; Και εδώ υπάρχει μια απόχρωση.
Ας υποθέσουμε ότι έχετε μια υπηρεσία στο δίκτυό σας που λειτουργεί σε anycast. Δυστυχώς, δεν έχω χρόνο να μπω σε λεπτομέρειες σχετικά με το τι είναι το anycast, αλλά είναι μια κατανεμημένη υπηρεσία με διαφορετικούς φυσικούς διακομιστές προσβάσιμους μέσω της ίδιας διεύθυνσης IP. Και εδώ υπάρχει ένα πιθανό πρόβλημα: το συμβάν RTO μπορεί να προκύψει όχι μόνο όταν η κίνηση διέρχεται από το ύφασμα. Μπορεί επίσης να συμβεί σε επίπεδο προσωρινής αποθήκευσης ToR: όταν συμβαίνει ένα συμβάν incast, μπορεί να συμβεί ακόμη και στον κεντρικό υπολογιστή όταν ο κεντρικός υπολογιστής χυθεί κάτι. Όταν συμβαίνει ένα συμβάν RTO και αλλάζει την ετικέτα ροής. Σε αυτήν την περίπτωση, η επισκεψιμότητα μπορεί να μεταφερθεί σε άλλη εμφάνιση anycast. Ας υποθέσουμε ότι πρόκειται για κατάσταση κατάστασης anycast, περιέχει μια κατάσταση σύνδεσης - θα μπορούσε να είναι ένα L3 Balancer ή κάποια άλλη υπηρεσία. Τότε προκύπτει ένα πρόβλημα, γιατί μετά το RTO η σύνδεση TCP φτάνει στον διακομιστή, ο οποίος δεν γνωρίζει τίποτα για αυτήν τη σύνδεση TCP. Και αν δεν έχουμε κοινή χρήση κατάστασης μεταξύ των διακομιστών anycast, τότε αυτή η κίνηση θα απορριφθεί και η σύνδεση TCP θα διακοπεί.
Τι μπορείτε να κάνετε εδώ; Μέσα στο ελεγχόμενο περιβάλλον σας, όπου ενεργοποιείτε την εξισορρόπηση ετικετών ροής, πρέπει να καταγράψετε την τιμή της ετικέτας ροής κατά την πρόσβαση σε διακομιστές anycast. Ο ευκολότερος τρόπος είναι να το κάνετε αυτό μέσω του ίδιου προγράμματος eBPF. Αλλά εδώ είναι ένα πολύ σημαντικό σημείο - τι πρέπει να κάνετε εάν δεν λειτουργείτε δίκτυο κέντρου δεδομένων, αλλά είστε τηλεπικοινωνιακός φορέας; Αυτό είναι και το πρόβλημά σας: ξεκινώντας με ορισμένες εκδόσεις των Juniper και Arista, περιλαμβάνουν από προεπιλογή μια ετικέτα ροής στις συναρτήσεις κατακερματισμού τους - ειλικρινά, για έναν λόγο που δεν είναι σαφής για μένα. Αυτό μπορεί να σας κάνει να απορρίψετε τις συνδέσεις TCP από χρήστες που διέρχονται από το δίκτυό σας. Επομένως, σας συνιστώ να ελέγξετε τις ρυθμίσεις των δρομολογητών σας εδώ.
Με τον ένα ή τον άλλο τρόπο, μου φαίνεται ότι είμαστε έτοιμοι να προχωρήσουμε σε πειράματα.
Όταν ενεργοποιήσαμε την ετικέτα ροής στο ToR, ετοιμάσαμε τον πράκτορα eBPF, που ζει πλέον στους οικοδεσπότες, αποφασίσαμε να μην περιμένουμε την επόμενη μεγάλη αποτυχία, αλλά να πραγματοποιήσουμε ελεγχόμενες εκρήξεις. Πήραμε το ToR, το οποίο έχει τέσσερις uplinks, και δημιουργήσαμε drops σε έναν από αυτούς. Έγραψαν έναν κανόνα και είπαν - τώρα χάνεις όλα τα πακέτα. Όπως μπορείτε να δείτε στα αριστερά, έχουμε παρακολούθηση ανά πακέτο, η οποία έχει πέσει στο 75%, δηλαδή χάνεται το 25% των πακέτων. Στα δεξιά υπάρχουν γραφήματα των υπηρεσιών που ζουν πίσω από αυτόν τον Όρο. Ουσιαστικά, αυτά είναι γραφήματα κίνησης των διεπαφών με διακομιστές μέσα στο rack. Όπως βλέπετε, βυθίστηκαν ακόμα πιο χαμηλά. Γιατί έπεσαν χαμηλότερα - όχι κατά 25%, αλλά σε ορισμένες περιπτώσεις κατά 3-4 φορές; Εάν η σύνδεση TCP είναι άτυχη, συνεχίζει να προσπαθεί να φτάσει μέσω της διασταυρούμενης διασταύρωσης. Αυτό επιδεινώνεται από την τυπική συμπεριφορά της υπηρεσίας μέσα στο DC - για ένα αίτημα χρήστη, δημιουργούνται N αιτήματα σε εσωτερικές υπηρεσίες και η απόκριση θα πάει στον χρήστη είτε όταν απαντήσουν όλες οι πηγές δεδομένων είτε όταν συμβεί ένα χρονικό όριο στην εφαρμογή επίπεδο, το οποίο πρέπει ακόμα να διαμορφωθεί. Δηλαδή όλα είναι πολύ πολύ άσχημα.
Τώρα το ίδιο πείραμα, αλλά με ενεργοποιημένη την τιμή της ετικέτας ροής. Όπως μπορείτε να δείτε, στα αριστερά η παρακολούθηση παρτίδας μας μειώθηκε κατά το ίδιο 25%. Αυτό είναι απολύτως σωστό, γιατί δεν γνωρίζει τίποτα για αναμεταδόσεις, στέλνει πακέτα και απλά μετράει την αναλογία του αριθμού των παραδοθέντων και χαμένων πακέτων.
Και στα δεξιά είναι το πρόγραμμα εξυπηρέτησης. Δεν θα βρείτε το αποτέλεσμα μιας προβληματικής άρθρωσης εδώ. Στα ίδια αυτά χιλιοστά του δευτερολέπτου, η κίνηση διοχετεύτηκε από την προβληματική περιοχή προς τις τρεις εναπομείνασες ανοδικές ζεύξεις που δεν επηρεάστηκαν από το πρόβλημα. Έχουμε ένα δίκτυο που αυτοθεραπεύεται.
Αυτή είναι η τελευταία μου διαφάνεια, ώρα να συνοψίσω. Τώρα, ελπίζω να ξέρετε πώς να δημιουργήσετε ένα δίκτυο κέντρων δεδομένων αυτοίασης. Δεν θα χρειαστεί να περάσετε από το αρχείο του πυρήνα του Linux και να αναζητήσετε ειδικές ενημερώσεις κώδικα εκεί· ξέρετε ότι η ετικέτα Flow σε αυτήν την περίπτωση λύνει το πρόβλημα, αλλά πρέπει να προσεγγίσετε προσεκτικά αυτόν τον μηχανισμό. Και τονίζω για άλλη μια φορά ότι εάν είστε τηλεπικοινωνιακός πάροχος, δεν πρέπει να χρησιμοποιείτε την ετικέτα ροής ως συνάρτηση κατακερματισμού, διαφορετικά θα διαταράξετε τις συνεδρίες των χρηστών σας.
Οι μηχανικοί δικτύων πρέπει να υποστούν μια εννοιολογική αλλαγή: το δίκτυο ξεκινά όχι με το ToR, όχι με τη συσκευή δικτύου, αλλά με τον κεντρικό υπολογιστή. Ένα αρκετά εντυπωσιακό παράδειγμα είναι το πώς χρησιμοποιούμε το eBPF τόσο για να αλλάξουμε το RTO όσο και για να καθορίσουμε την ετικέτα ροής προς τις υπηρεσίες anycast.
Οι μηχανικοί ετικετών ροής είναι σίγουρα κατάλληλοι για άλλες εφαρμογές εντός του ελεγχόμενου διοικητικού τμήματος. Αυτό μπορεί να είναι κίνηση μεταξύ κέντρων δεδομένων ή μπορείτε να χρησιμοποιήσετε τέτοιους μηχανισμούς με ειδικό τρόπο για να διαχειριστείτε την εξερχόμενη κίνηση. Αλλά θα σας πω για αυτό, ελπίζω, την επόμενη φορά. Σας ευχαριστώ πολύ για την προσοχή σας.
Πηγή: www.habr.com