Η παρακολούθηση σύνδεσης ("conntrack") είναι ένα βασικό χαρακτηριστικό της στοίβας δικτύωσης πυρήνα Linux. Επιτρέπει στον πυρήνα να παρακολουθεί όλες τις λογικές συνδέσεις ή ροές δικτύου και έτσι να προσδιορίζει όλα τα πακέτα που απαρτίζουν κάθε ροή, ώστε να μπορούν να υποβληθούν σε επεξεργασία μαζί διαδοχικά.
Το Conntrack είναι ένα σημαντικό χαρακτηριστικό του πυρήνα που χρησιμοποιείται σε ορισμένες βασικές περιπτώσεις:
- Το NAT βασίζεται σε πληροφορίες από το conntrack, ώστε να μπορεί να αντιμετωπίζει όλα τα πακέτα από την ίδια ροή εξίσου. Για παράδειγμα, όταν ένα pod αποκτά πρόσβαση σε μια υπηρεσία Kubernetes, το πρόγραμμα εξισορρόπησης φόρτου διακομιστή μεσολάβησης kube χρησιμοποιεί NAT για να κατευθύνει την κυκλοφορία σε μια συγκεκριμένη ομάδα διαφημίσεων εντός του συμπλέγματος. Το Conntrack καταγράφει ότι για μια δεδομένη σύνδεση, όλα τα πακέτα προς την υπηρεσία IP πρέπει να αποστέλλονται στον ίδιο pod και ότι τα πακέτα που επιστρέφονται από το backend pod πρέπει να επιστρέφουν NAT στο pod από το οποίο προήλθε το αίτημα.
- Τα κρατικά τείχη προστασίας όπως το Calico βασίζονται σε πληροφορίες από την επισκεψιμότητα "απόκρισης" από το connecttrack έως τη λίστα επιτρεπόμενων. Αυτό σας επιτρέπει να γράψετε μια πολιτική δικτύου που λέει "Να επιτρέπεται στο pod μου να συνδεθεί σε οποιαδήποτε απομακρυσμένη διεύθυνση IP" χωρίς να χρειάζεται να γράψετε μια πολιτική για να επιτρέπεται ρητά η κυκλοφορία απόκρισης. (Χωρίς αυτό, θα έπρεπε να προσθέσετε τον πολύ λιγότερο ασφαλή κανόνα "να επιτρέπω τα πακέτα στο pod μου από οποιαδήποτε IP".)
Επιπλέον, το conntrack συνήθως βελτιώνει την απόδοση του συστήματος (μειώνοντας την κατανάλωση της CPU και την καθυστέρηση πακέτων) αφού μόνο το πρώτο πακέτο σε μια ροή
πρέπει να περάσει από ολόκληρη τη στοίβα δικτύου για να καθορίσει τι να κάνει με αυτό. Δείτε την ανάρτηση""για να δείτε ένα παράδειγμα του πώς λειτουργεί.
Ωστόσο, το contrack έχει τους περιορισμούς του...
Λοιπόν, πού πήγαν όλα στραβά;
Ο πίνακας conntrack έχει ένα διαμορφώσιμο μέγιστο μέγεθος και εάν γεμίσει, οι συνδέσεις συνήθως αρχίζουν να απορρίπτονται ή να απορρίπτονται. Υπάρχει αρκετός ελεύθερος χώρος στον πίνακα για τη διαχείριση της κίνησης των περισσότερων εφαρμογών και αυτό δεν θα γίνει ποτέ πρόβλημα. Ωστόσο, υπάρχουν μερικά σενάρια στα οποία μπορεί να θέλετε να εξετάσετε τη χρήση του πίνακα conntrack:
- Η πιο προφανής περίπτωση είναι εάν ο διακομιστής σας χειρίζεται έναν εξαιρετικά μεγάλο αριθμό ταυτόχρονων ενεργών συνδέσεων. Για παράδειγμα, εάν ο πίνακας conntrack σας έχει ρυθμιστεί για 128k καταχωρήσεις, αλλά έχετε >128k ταυτόχρονες συνδέσεις, σίγουρα θα αντιμετωπίσετε πρόβλημα!
- Μια ελαφρώς λιγότερο προφανής περίπτωση: εάν ο διακομιστής σας επεξεργάζεται πολύ μεγάλο αριθμό συνδέσεων ανά δευτερόλεπτο. Ακόμα κι αν οι συνδέσεις είναι βραχύβιες, συνεχίζουν να παρακολουθούνται από το Linux για κάποιο χρονικό διάστημα (120 δευτερόλεπτα από προεπιλογή). Για παράδειγμα, εάν ο πίνακας conntrack έχει διαμορφωθεί για 128k καταχωρήσεις και προσπαθείτε να χειριστείτε 1100 συνδέσεις ανά δευτερόλεπτο, θα υπερβούν το μέγεθος του πίνακα conntrack, ακόμα κι αν οι συνδέσεις είναι πολύ βραχύβιες (128k/120s = 1092 συνδέσεις/ μικρό).
Υπάρχουν αρκετοί εξειδικευμένοι τύποι εφαρμογών που εμπίπτουν σε αυτές τις κατηγορίες. Επιπλέον, εάν έχετε πολλούς κακούς ηθοποιούς, η πλήρωση του πίνακα ελέγχου του διακομιστή σας με πολλές μισάνοιχτες συνδέσεις θα μπορούσε να χρησιμοποιηθεί ως μέρος μιας επίθεσης άρνησης υπηρεσίας (DOS). Και στις δύο περιπτώσεις, το conntrack μπορεί να γίνει περιοριστικό εμπόδιο στο σύστημά σας. Σε ορισμένες περιπτώσεις, η προσαρμογή των παραμέτρων του πίνακα conntrack μπορεί να είναι αρκετή για να καλύψει τις ανάγκες σας - αυξάνοντας το μέγεθος ή μειώνοντας τα χρονικά όρια conntrack (αλλά αν το κάνετε λάθος, θα αντιμετωπίσετε πολλά προβλήματα). Για άλλες περιπτώσεις θα είναι απαραίτητο να παρακάμψετε το contrack για επιθετική κυκλοφορία.
Πραγματικό παράδειγμα
Ας δώσουμε ένα συγκεκριμένο παράδειγμα: ένας μεγάλος πάροχος SaaS με τον οποίο συνεργαστήκαμε είχε πολλούς διακομιστές memcached σε κεντρικούς υπολογιστές (όχι εικονικές μηχανές), καθένας από τους οποίους επεξεργαζόταν 50K+ βραχυπρόθεσμες συνδέσεις ανά δευτερόλεπτο.
Πειραματίστηκαν με τη διαμόρφωση conntrack, αυξάνοντας τα μεγέθη του πίνακα και μειώνοντας τον χρόνο παρακολούθησης, αλλά η διαμόρφωση ήταν αναξιόπιστη, η κατανάλωση RAM αυξήθηκε σημαντικά, κάτι που ήταν πρόβλημα (της τάξης των GByte!) και οι συνδέσεις ήταν τόσο σύντομες που το conntrack δεν ήταν δημιουργεί το συνηθισμένο πλεονέκτημα απόδοσης (μειωμένη κατανάλωση CPU ή καθυστέρηση πακέτων).
Στράφηκαν στο Calico ως εναλλακτική. Οι πολιτικές δικτύου Calico σάς επιτρέπουν να μην χρησιμοποιείτε το conntrack για συγκεκριμένους τύπους κίνησης (χρησιμοποιώντας την επιλογή πολιτικής doNotTrack). Αυτό τους έδωσε το επίπεδο απόδοσης που χρειάζονταν, συν το πρόσθετο επίπεδο ασφάλειας που παρείχε η Calico.
Τι μήκη θα πρέπει να κάνετε για να παρακάμψετε το conntrack;
- Οι πολιτικές δικτύου χωρίς παρακολούθηση θα πρέπει γενικά να είναι συμμετρικές. Στην περίπτωση του παρόχου SaaS: οι εφαρμογές τους εκτελούνταν εντός μιας προστατευμένης ζώνης και επομένως, χρησιμοποιώντας την πολιτική δικτύου, μπορούσαν να βάλουν στη λίστα επιτρεπόμενων επισκεψιμότητας από άλλες συγκεκριμένες εφαρμογές που είχαν πρόσβαση σε memcached.
- Η πολιτική μη παρακολούθησης δεν λαμβάνει υπόψη την κατεύθυνση της σύνδεσης. Έτσι, εάν ο διακομιστής memcached έχει παραβιαστεί, μπορείτε θεωρητικά να προσπαθήσετε να συνδεθείτε σε οποιονδήποτε από τους πελάτες memcached, αρκεί να χρησιμοποιεί τη σωστή θύρα προέλευσης. Ωστόσο, εάν έχετε ορίσει σωστά την πολιτική δικτύου για τους υπολογιστές-πελάτες σας με προσωρινή μνήμη, τότε αυτές οι προσπάθειες σύνδεσης θα εξακολουθήσουν να απορρίπτονται από την πλευρά του πελάτη.
- Η πολιτική μη παρακολούθησης εφαρμόζεται σε κάθε πακέτο, σε αντίθεση με τις κανονικές πολιτικές, οι οποίες εφαρμόζονται μόνο στο πρώτο πακέτο σε μια ροή. Αυτό μπορεί να αυξήσει την κατανάλωση CPU ανά πακέτο, επειδή η πολιτική πρέπει να εφαρμόζεται για κάθε πακέτο. Αλλά για βραχύβιες συνδέσεις, αυτή η δαπάνη εξισορροπείται από τη μείωση της κατανάλωσης πόρων για την επεξεργασία contrack. Για παράδειγμα, στην περίπτωση ενός παρόχου SaaS, ο αριθμός των πακέτων για κάθε σύνδεση ήταν πολύ μικρός, επομένως η πρόσθετη κατανάλωση CPU κατά την εφαρμογή πολιτικών σε κάθε πακέτο ήταν δικαιολογημένη.
Ας ξεκινήσουμε τις δοκιμές
Πραγματοποιήσαμε τη δοκιμή σε ένα μεμονωμένο pod με έναν διακομιστή memcached και πολλαπλά pods πελάτη memcached που εκτελούνται σε απομακρυσμένους κόμβους, έτσι ώστε να μπορούμε να εκτελέσουμε έναν πολύ μεγάλο αριθμό συνδέσεων ανά δευτερόλεπτο. Ο διακομιστής με την ομάδα διακομιστή memcached είχε 8 πυρήνες και 512k καταχωρήσεις στον πίνακα conntrack (το τυπικό διαμορφωμένο μέγεθος πίνακα για τον κεντρικό υπολογιστή).
Μετρήσαμε τη διαφορά απόδοσης μεταξύ: χωρίς πολιτική δικτύου. με τακτική πολιτική Calico? και Calico πολιτική μη παρακολούθησης.
Για την πρώτη δοκιμή, ορίσαμε τον αριθμό των συνδέσεων σε 4.000 ανά δευτερόλεπτο, ώστε να μπορούμε να εστιάσουμε στη διαφορά στην κατανάλωση της CPU. Δεν υπήρχαν σημαντικές διαφορές μεταξύ χωρίς πολιτική και κανονικής πολιτικής, αλλά η μη παρακολούθηση αυξημένη κατανάλωση CPU κατά περίπου 20%:
Στη δεύτερη δοκιμή, ξεκινήσαμε όσες συνδέσεις μπορούσαν να δημιουργήσουν οι πελάτες μας και μετρήσαμε τον μέγιστο αριθμό συνδέσεων ανά δευτερόλεπτο που θα μπορούσε να χειριστεί ο memcached διακομιστής μας. Όπως ήταν αναμενόμενο, οι περιπτώσεις «χωρίς πολιτική» και «κανονική πολιτική» έφτασαν και οι δύο το όριο σύνδεσης των άνω των 4,000 συνδέσεων ανά δευτερόλεπτο (512k / 120s = 4,369 συνδέσεις/δευτερόλεπτα). Με μια πολιτική μη παρακολούθησης, οι πελάτες μας έστειλαν 60,000 συνδέσεις ανά δευτερόλεπτο χωρίς κανένα πρόβλημα. Είμαστε σίγουροι ότι θα μπορούσαμε να αυξήσουμε αυτόν τον αριθμό προσθέτοντας περισσότερους πελάτες, αλλά πιστεύουμε ότι αυτοί οι αριθμοί είναι ήδη αρκετοί για να επεξηγήσουν το νόημα αυτού του άρθρου!
Συμπέρασμα
Το Conntrack είναι ένα σημαντικό χαρακτηριστικό του πυρήνα. Κάνει τέλεια τη δουλειά του. Χρησιμοποιείται συχνά από βασικά στοιχεία του συστήματος. Ωστόσο, σε ορισμένα συγκεκριμένα σενάρια, η συμφόρηση που οφείλεται στο conntrack υπερτερεί των κανονικών οφελών που παρέχει. Σε αυτό το σενάριο, οι πολιτικές δικτύου Calico μπορούν να χρησιμοποιηθούν για την επιλεκτική απενεργοποίηση της χρήσης του conntrack αυξάνοντας παράλληλα την ασφάλεια του δικτύου. Για όλη την άλλη κίνηση, το conntrack συνεχίζει να είναι φίλος σας!
Διαβάστε επίσης άλλα άρθρα στο ιστολόγιό μας:
Πηγή: www.habr.com