Η νόμιμη κίνηση στο δίκτυο DDoS-Guard υπερέβη πρόσφατα τα εκατό gigabit ανά δευτερόλεπτο. Επί του παρόντος, το 50% του συνόλου της επισκεψιμότητάς μας δημιουργείται από υπηρεσίες ιστού πελατών. Πρόκειται για πολλές δεκάδες χιλιάδες τομείς, πολύ διαφορετικούς και στις περισσότερες περιπτώσεις απαιτούν ατομική προσέγγιση.
Κάτω από την περικοπή είναι ο τρόπος με τον οποίο διαχειριζόμαστε τους μπροστινούς κόμβους και εκδίδουμε πιστοποιητικά SSL για εκατοντάδες χιλιάδες τοποθεσίες.
Η δημιουργία μιας πρόσοψης για έναν ιστότοπο, ακόμη και έναν πολύ μεγάλο, είναι εύκολο. Παίρνουμε nginx ή haproxy ή lighttpd, το ρυθμίζουμε σύμφωνα με τους οδηγούς και το ξεχνάμε. Αν χρειαστεί να αλλάξουμε κάτι, κάνουμε reload και ξεχνάμε ξανά.
Όλα αλλάζουν όταν επεξεργάζεστε μεγάλους όγκους επισκεψιμότητας εν κινήσει, αξιολογείτε τη νομιμότητα των αιτημάτων, συμπιέζετε και αποθηκεύετε προσωρινά το περιεχόμενο των χρηστών και ταυτόχρονα αλλάζετε παραμέτρους πολλές φορές ανά δευτερόλεπτο. Ο χρήστης θέλει να δει το αποτέλεσμα σε όλους τους εξωτερικούς κόμβους αμέσως αφού αλλάξει τις ρυθμίσεις στον προσωπικό του λογαριασμό. Ένας χρήστης μπορεί επίσης να κατεβάσει πολλές χιλιάδες (και μερικές φορές δεκάδες χιλιάδες) τομείς με μεμονωμένες παραμέτρους επεξεργασίας κίνησης μέσω του API. Όλα αυτά θα πρέπει επίσης να λειτουργήσουν αμέσως στην Αμερική, στην Ευρώπη και στην Ασία - το έργο δεν είναι το πιο ασήμαντο, δεδομένου ότι μόνο στη Μόσχα υπάρχουν αρκετοί φυσικά διαχωρισμένοι κόμβοι φιλτραρίσματος.
Γιατί υπάρχουν πολλοί μεγάλοι αξιόπιστοι κόμβοι σε όλο τον κόσμο;
-
Ποιότητα υπηρεσίας για την κίνηση πελατών - αιτήματα από τις ΗΠΑ πρέπει να διεκπεραιώνονται στις ΗΠΑ (συμπεριλαμβανομένων επιθέσεων, ανάλυσης και άλλων ανωμαλιών) και να μην έλκονται στη Μόσχα ή την Ευρώπη, αυξάνοντας απρόβλεπτα την καθυστέρηση επεξεργασίας.
-
Η κυκλοφορία επιθέσεων πρέπει να εντοπιστεί - οι φορείς εκμετάλλευσης συγκοινωνιών μπορούν να υποβαθμιστούν κατά τη διάρκεια επιθέσεων, ο όγκος των οποίων συχνά υπερβαίνει το 1 Tbps. Η μεταφορά κίνησης επίθεσης μέσω διατλαντικών ή υπερασιατικών συνδέσεων δεν είναι καλή ιδέα. Είχαμε πραγματικές περιπτώσεις όταν οι χειριστές Tier-1 είπαν: «Ο όγκος των επιθέσεων που λαμβάνετε είναι επικίνδυνος για εμάς». Γι' αυτό δεχόμαστε εισερχόμενες ροές όσο το δυνατόν πιο κοντά στις πηγές τους.
-
Οι αυστηρές απαιτήσεις για τη συνέχεια των υπηρεσιών - τα κέντρα καθαρισμού δεν πρέπει να εξαρτώνται ούτε το ένα από το άλλο ούτε από τοπικά γεγονότα στον ταχέως μεταβαλλόμενο κόσμο μας. Κόψατε το ρεύμα και στους 11 ορόφους του MMTS-9 για μια εβδομάδα; - κανένα πρόβλημα. Κανένας πελάτης που δεν έχει φυσική σύνδεση στη συγκεκριμένη τοποθεσία δεν θα υποφέρει και οι υπηρεσίες web δεν θα υποφέρουν σε καμία περίπτωση.
Πώς να τα διαχειριστείς όλα αυτά;
Οι διαμορφώσεις υπηρεσιών θα πρέπει να διανέμονται σε όλους τους μπροστινούς κόμβους όσο το δυνατόν γρηγορότερα (ιδανικά αμέσως). Δεν μπορείτε απλώς να λαμβάνετε και να αναδημιουργείτε παραμέτρους κειμένου και να επανεκκινείτε τους δαίμονες σε κάθε αλλαγή - το ίδιο nginx κρατά τις διεργασίες να κλείνουν (τερματισμός λειτουργίας του εργαζόμενου) για μερικά ακόμη λεπτά (ή ίσως ώρες, αν υπάρχουν μεγάλες περιόδους σύνδεσης websocket).
Κατά την επαναφόρτωση της διαμόρφωσης nginx, η ακόλουθη εικόνα είναι αρκετά φυσιολογική:
Σχετικά με τη χρήση μνήμης:
Οι παλιοί εργαζόμενοι τρώνε τη μνήμη, συμπεριλαμβανομένης της μνήμης που δεν εξαρτάται γραμμικά από τον αριθμό των συνδέσεων - αυτό είναι φυσιολογικό. Όταν κλείσουν οι συνδέσεις πελάτη, αυτή η μνήμη θα ελευθερωθεί.
Γιατί δεν ήταν αυτό ένα ζήτημα όταν το nginx μόλις ξεκινούσε; Δεν υπήρχε HTTP/2, ούτε WebSocket, ούτε τεράστιες μακροχρόνιες συνδέσεις. Το 70% της διαδικτυακής μας κίνησης είναι HTTP/2, που σημαίνει πολύ μεγάλες συνδέσεις.
Η λύση είναι απλή - μην χρησιμοποιείτε το nginx, μην διαχειρίζεστε μέτωπα με βάση αρχεία κειμένου και σίγουρα μην στέλνετε διαμορφώσεις συμπιεσμένου κειμένου σε κανάλια transpacific. Τα κανάλια είναι, φυσικά, εγγυημένα και δεσμευμένα, αλλά αυτό δεν τα κάνει λιγότερο διηπειρωτικά.
Έχουμε το δικό μας front server-balancer, για τα εσωτερικά του οποίου θα μιλήσω στα επόμενα άρθρα. Το κύριο πράγμα που μπορεί να κάνει είναι να εφαρμόζει χιλιάδες αλλαγές διαμόρφωσης ανά δευτερόλεπτο εν κινήσει, χωρίς επανεκκινήσεις, επαναφορτώσεις, ξαφνικές αυξήσεις στην κατανάλωση μνήμης και όλα αυτά. Αυτό μοιάζει πολύ με το Hot Code Reload, για παράδειγμα στο Erlang. Τα δεδομένα αποθηκεύονται σε μια γεωγραφικά κατανεμημένη βάση δεδομένων κλειδιών-τιμών και διαβάζονται αμέσως από τους μπροστινούς ενεργοποιητές. Εκείνοι. ανεβάζετε το πιστοποιητικό SSL μέσω της διεπαφής ιστού ή του API στη Μόσχα και σε λίγα δευτερόλεπτα είναι έτοιμο να μεταβείτε στο κέντρο καθαρισμού μας στο Λος Άντζελες. Εάν συμβεί ξαφνικά ένας παγκόσμιος πόλεμος και το Διαδίκτυο εξαφανιστεί σε όλο τον κόσμο, οι κόμβοι μας θα συνεχίσουν να λειτουργούν αυτόνομα και να επιδιορθώνουν τον διαχωρισμό του εγκεφάλου μόλις ένα από τα αποκλειστικά κανάλια Λος Άντζελες-Άμστερνταμ-Μόσχα, Μόσχα-Άμστερνταμ-Χονγκ Κονγκ- Το Los-Los γίνεται διαθέσιμο. Angeles ή τουλάχιστον μία από τις εφεδρικές επικαλύψεις GRE.
Αυτός ο ίδιος μηχανισμός μας επιτρέπει να εκδίδουμε και να ανανεώνουμε άμεσα πιστοποιητικά Let’s Encrypt. Πολύ απλά λειτουργεί ως εξής:
-
Μόλις δούμε τουλάχιστον ένα αίτημα HTTPS για τον τομέα του πελάτη μας χωρίς πιστοποιητικό (ή με πιστοποιητικό που έχει λήξει), ο εξωτερικός κόμβος που αποδέχτηκε το αίτημα το αναφέρει στην εσωτερική αρχή πιστοποίησης.
-
Εάν ο χρήστης δεν έχει απαγορεύσει την έκδοση του Let’s Encrypt, η αρχή πιστοποίησης δημιουργεί ένα CSR, λαμβάνει ένα διακριτικό επιβεβαίωσης από το LE και το στέλνει σε όλα τα μέτωπα μέσω ενός κρυπτογραφημένου καναλιού. Τώρα οποιοσδήποτε κόμβος μπορεί να επιβεβαιώσει ένα αίτημα επικύρωσης από το LE.
-
Σε λίγα λεπτά, θα λάβουμε το σωστό πιστοποιητικό και ιδιωτικό κλειδί και θα το στείλουμε στο μέτωπο με τον ίδιο τρόπο. Και πάλι, χωρίς επανεκκίνηση των δαιμόνων
-
7 ημέρες πριν από την ημερομηνία λήξης, ξεκινά η διαδικασία για την εκ νέου παραλαβή του πιστοποιητικού
Αυτήν τη στιγμή εναλλάσσουμε 350 χιλιάδες πιστοποιητικά σε πραγματικό χρόνο, εντελώς διαφανή στους χρήστες.
Στα επόμενα άρθρα της σειράς, θα μιλήσω για άλλα χαρακτηριστικά της επεξεργασίας σε πραγματικό χρόνο μεγάλης κυκλοφορίας ιστού - για παράδειγμα, για την ανάλυση RTT χρησιμοποιώντας ελλιπή δεδομένα για τη βελτίωση της ποιότητας της υπηρεσίας για πελάτες διαμετακόμισης και γενικά για την προστασία της συγκοινωνίας από επιθέσεις terabit, σχετικά με την παράδοση και τη συγκέντρωση πληροφοριών κυκλοφορίας, σχετικά με το WAF, σχεδόν απεριόριστο CDN και πολλούς μηχανισμούς για τη βελτιστοποίηση της παράδοσης περιεχομένου.
Μόνο εγγεγραμμένοι χρήστες μπορούν να συμμετάσχουν στην έρευνα. , Σας παρακαλούμε.
Τι θα θέλατε να μάθετε πρώτα;
-
14,3%Αλγόριθμοι για ομαδοποίηση και ανάλυση της ποιότητας της επισκεψιμότητας ιστού<3
-
33,3%Εσωτερικά των εξισορροπητών DDoS-Guard7
-
9,5%Προστασία της διαμετακομιστικής κυκλοφορίας L3/L4
-
0,0%Προστασία ιστότοπων σε συγκοινωνιακή κίνηση0
-
14,3%Τείχος προστασίας εφαρμογών Ιστού3
-
28,6%Προστασία από ανάλυση και κλικ6
Ψήφισαν 21 χρήστες. 6 χρήστες απείχαν.
Πηγή: www.habr.com