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

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

Με αυτό το άρθρο θα ξεκινήσω μια σειρά για το πώς μου φαίνεται ο αυτοματισμός.
Στην πορεία, θα κατανοήσουμε τα στάδια αυτοματισμού, αποθήκευση μεταβλητών, επισημοποίηση σχεδίασης, RestAPI, NETCONF, YANG, YDK και θα κάνουμε πολύ προγραμματισμό.
Μου σημαίνει ότι α) δεν είναι μια αντικειμενική αλήθεια, β) δεν είναι άνευ όρων η καλύτερη προσέγγιση, γ) η γνώμη μου, ακόμη και κατά τη διάρκεια της μετακίνησης από το πρώτο στο τελευταίο άρθρο, μπορεί να αλλάξει - για να είμαι ειλικρινής, από το στάδιο του σχεδίου στο δημοσίευση, τα ξαναέγραψα όλα εντελώς δύο φορές.

περιεχόμενο

1. Στόχοι
   1. Το δίκτυο είναι σαν ένας ενιαίος οργανισμός
   2. Δοκιμή διαμόρφωσης
   3. Εκδόσεις
   4. Παρακολούθηση και αυτοθεραπεία των υπηρεσιών

2. Μέσα
   1. Σύστημα απογραφής
   2. Σύστημα διαχείρισης χώρου IP
   3. Σύστημα περιγραφής υπηρεσιών δικτύου
   4. Μηχανισμός αρχικοποίησης συσκευής
   5. Προμηθευτής-αγνωστικό μοντέλο διαμόρφωσης
   6. Διεπαφή προγράμματος οδήγησης για συγκεκριμένο προμηθευτή
   7. Μηχανισμός παράδοσης διαμόρφωσης στη συσκευή
   8. CI / CD
   9. Μηχανισμός δημιουργίας αντιγράφων ασφαλείας και αναζήτησης αποκλίσεων
   10. Σύστημα παρακολούθησης

3. Συμπέρασμα

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

Πόσο αστείο είναι που τη δεύτερη φορά πρέπει να διανύσεις τον ίδιο δρόμο.

Στην αρχή έπρεπε να γράψω άρθρα για τα δίκτυα ο ίδιος λόγω του γεγονότος ότι δεν ήταν στο RuNet.

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

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

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

Δεν θα πρωτοτυπήσω στις ιδέες και τα εργαλεία που περιγράφονται εδώ. Ο Ντμίτρι Φιγκόλ έχει ένα εξαιρετικό κανάλι με ροές για αυτό το θέμα.
Τα άρθρα θα επικαλύπτονται μαζί τους από πολλές απόψεις.

Το LAN DC έχει 4 DC, περίπου 250 μεταγωγείς, μισή ντουζίνα δρομολογητές και μερικά τείχη προστασίας.
Όχι Facebook, αλλά αρκετά για να σε κάνουν να σκεφτείς βαθιά την αυτοματοποίηση.
Υπάρχει, ωστόσο, η άποψη ότι εάν έχετε περισσότερες από 1 συσκευές, χρειάζεται ήδη αυτοματισμός.
Στην πραγματικότητα, είναι δύσκολο να φανταστεί κανείς ότι κάποιος μπορεί πλέον να ζήσει χωρίς τουλάχιστον ένα πακέτο σεναρίων.
Παρόλο που άκουσα ότι υπάρχουν γραφεία όπου οι διευθύνσεις IP διατηρούνται στο Excel και καθεμία από τις χιλιάδες συσκευές δικτύου έχει ρυθμιστεί με μη αυτόματο τρόπο και έχει τη δική της μοναδική διαμόρφωση. Αυτό, φυσικά, μπορεί να περάσει ως σύγχρονη τέχνη, αλλά τα συναισθήματα του μηχανικού σίγουρα θα προσβληθούν.

Στόχοι

Τώρα θα θέσουμε τους πιο αφηρημένους στόχους:

• Το δίκτυο είναι σαν ένας ενιαίος οργανισμός
• Δοκιμή διαμόρφωσης
• Εκδόσεις κατάστασης δικτύου
• Παρακολούθηση και αυτοθεραπεία των υπηρεσιών

Αργότερα σε αυτό το άρθρο θα δούμε ποια μέσα θα χρησιμοποιήσουμε και στη συνέχεια θα δούμε αναλυτικά τους στόχους και τα μέσα.

Το δίκτυο είναι σαν ένας ενιαίος οργανισμός

Η καθοριστική φράση της σειράς, αν και με την πρώτη ματιά μπορεί να μην φαίνεται τόσο σημαντική: θα διαμορφώσουμε το δίκτυο, όχι μεμονωμένες συσκευές.
Τα τελευταία χρόνια, έχουμε δει μια μετατόπιση της έμφασης προς την αντιμετώπιση του δικτύου ως ενιαίας οντότητας, ως εκ τούτου Δίκτυο που ορίζεται από λογισμικό, Δίκτυα με γνώμονα την πρόθεση и Αυτόνομα Δίκτυα.
Εξάλλου, τι χρειάζονται οι εφαρμογές παγκοσμίως από το δίκτυο: συνδεσιμότητα μεταξύ των σημείων Α και Β (καλά, μερικές φορές +Β-Ζ) και απομόνωση από άλλες εφαρμογές και χρήστες.

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

Δηλαδή, για παράδειγμα, εάν αποφασίσαμε ότι από τώρα και στο εξής οι διακόπτες rack στο Καζάν θα πρέπει να ανακοινώνουν δύο δίκτυα αντί για ένα,

1. Αρχικά τεκμηριώνουμε τις αλλαγές στα συστήματα
2. Δημιουργία της στοχευόμενης διαμόρφωσης όλων των συσκευών δικτύου
3. Εκκινούμε το πρόγραμμα ενημέρωσης διαμόρφωσης δικτύου, το οποίο υπολογίζει τι πρέπει να αφαιρεθεί σε κάθε κόμβο, τι να προσθέσει και φέρνει τους κόμβους στην επιθυμητή κατάσταση.

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

Δοκιμή διαμόρφωσης

Γνωστόςότι το 80% των προβλημάτων παρουσιάζονται κατά τις αλλαγές διαμόρφωσης - έμμεση απόδειξη αυτού είναι ότι κατά τις διακοπές της Πρωτοχρονιάς όλα είναι συνήθως ήρεμα.
Έχω δει προσωπικά δεκάδες παγκόσμιες διακοπές λειτουργίας λόγω ανθρώπινου λάθους: λάθος εντολή, η ρύθμιση παραμέτρων εκτελέστηκε σε λάθος κλάδο, η κοινότητα ξεχάστηκε, MPLS καταργήθηκε παγκοσμίως στο δρομολογητή, πέντε κομμάτια υλικού διαμορφώθηκαν, αλλά το σφάλμα δεν ήταν παρατηρήθηκε την έκτη, έγιναν παλιές αλλαγές που έγιναν από άλλο άτομο. Υπάρχουν πάρα πολλά σενάρια.

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

Από αμνημονεύτων χρόνων, οι παππούδες μας έλεγχαν την ορθότητα των αλλαγών που έγιναν με έντονο μάτι, μπάλες από χάλυβα και τη λειτουργικότητα του δικτύου μετά την κυκλοφορία τους.
Αυτοί οι παππούδες των οποίων η εργασία οδήγησε σε διακοπές και καταστροφικές απώλειες άφησαν λιγότερους απογόνους και θα πρέπει να πεθάνουν με την πάροδο του χρόνου, αλλά η εξέλιξη είναι μια αργή διαδικασία και επομένως δεν δοκιμάζουν όλοι πρώτα τις αλλαγές στο εργαστήριο.
Ωστόσο, στην πρώτη γραμμή της προόδου βρίσκονται αυτοί που έχουν αυτοματοποιήσει τη διαδικασία δοκιμής της διαμόρφωσης και την περαιτέρω εφαρμογή της στο δίκτυο. Με άλλα λόγια, δανείστηκα τη διαδικασία CI/CD (Συνεχής Ενοποίηση, Συνεχής Ανάπτυξη) από τους προγραμματιστές.
Σε ένα από τα μέρη θα δούμε πώς να το εφαρμόσουμε χρησιμοποιώντας ένα σύστημα ελέγχου έκδοσης, πιθανώς Github.

Μόλις συνηθίσετε στην ιδέα του δικτύου CI/CD, η μέθοδος ελέγχου μιας διαμόρφωσης με την εφαρμογή της σε ένα δίκτυο παραγωγής θα μοιάζει με πρώιμη μεσαιωνική άγνοια. Κάτι σαν να χτυπάς μια κεφαλή με ένα σφυρί.

Μια οργανική συνέχεια ιδεών για Σύστημα διαχείριση δικτύου και CI/CD γίνεται μια πλήρης έκδοση της διαμόρφωσης.

Εκδόσεις

Θα υποθέσουμε ότι με οποιεσδήποτε αλλαγές, όσο μικρές κι αν είναι, ακόμη και σε μια μη αντιληπτή συσκευή, ολόκληρο το δίκτυο μετακινείται από τη μια κατάσταση στην άλλη.
Και πάντα δεν εκτελούμε εντολή στη συσκευή, αλλάζουμε την κατάσταση του δικτύου.
Ας ονομάσουμε λοιπόν αυτές τις καταστάσεις εκδόσεις;

Ας υποθέσουμε ότι η τρέχουσα έκδοση είναι 1.0.0.
Έχει αλλάξει η διεύθυνση IP της διεπαφής Loopback σε έναν από τους ToR; Αυτή είναι μια δευτερεύουσα έκδοση και θα αριθμηθεί 1.0.1.
Αναθεωρήσαμε τις πολιτικές για την εισαγωγή δρομολογίων στο BGP - λίγο πιο σοβαρά - ήδη 1.1.0
Αποφασίσαμε να απαλλαγούμε από το IGP και να μεταβούμε μόνο στο BGP - αυτή είναι ήδη μια ριζική αλλαγή σχεδιασμού - 2.0.0.

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

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

Επαναλαμβάνω - οποιαδήποτε αλλαγή (εκτός από τις εντολές εντοπισμού σφαλμάτων) είναι ενημέρωση έκδοσης. Οι διαχειριστές πρέπει να ειδοποιούνται για τυχόν αποκλίσεις από την τρέχουσα έκδοση.

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

Παρακολούθηση και αυτοθεραπεία των υπηρεσιών

Αυτό το αυτονόητο έργο έχει φτάσει σε νέο επίπεδο στα σύγχρονα δίκτυα.
Συχνά, οι μεγάλοι πάροχοι υπηρεσιών υιοθετούν την προσέγγιση ότι μια αποτυχημένη υπηρεσία πρέπει να επιδιορθωθεί πολύ γρήγορα και να δημιουργηθεί μια νέα, αντί να καταλάβουν τι συνέβη.
"Πολύ" σημαίνει ότι πρέπει να επικαλυφθείτε γενναιόδωρα από όλες τις πλευρές με παρακολούθηση, η οποία μέσα σε δευτερόλεπτα θα ανιχνεύσει τις παραμικρές αποκλίσεις από τον κανόνα.
Και εδώ οι συνήθεις μετρήσεις, όπως η φόρτωση της διεπαφής ή η διαθεσιμότητα κόμβου, δεν είναι πλέον αρκετές. Δεν αρκεί ούτε η χειρωνακτική παρακολούθησή τους από τον αξιωματικό υπηρεσίας.
Για πολλά πράγματα πρέπει να υπάρχουν Αυτοθεραπεία — τα φώτα παρακολούθησης έγιναν κόκκινα και πήγαμε και απλώσαμε μόνοι μας το plantain όπου πονούσε.

Και εδώ παρακολουθούμε επίσης όχι μόνο μεμονωμένες συσκευές, αλλά και την υγεία ολόκληρου του δικτύου, τόσο του whitebox, που είναι σχετικά κατανοητό, όσο και του blackbox, το οποίο είναι πιο περίπλοκο.

Τι θα χρειαστούμε για να υλοποιήσουμε τέτοια φιλόδοξα σχέδια;

• Έχετε μια λίστα με όλες τις συσκευές στο δίκτυο, τη θέση τους, τους ρόλους, τα μοντέλα, τις εκδόσεις λογισμικού.
  kazan-leaf-1.lmu.net, Kazan, φύλλο, Juniper QFX 5120, R18.3.
• Έχετε ένα σύστημα για την περιγραφή των υπηρεσιών δικτύου.
  IGP, BGP, L2/3VPN, Πολιτική, ACL, NTP, SSH.
• Να είστε σε θέση να αρχικοποιήσετε τη συσκευή.
  Όνομα κεντρικού υπολογιστή, Mgmt IP, Mgmt Route, Users, RSA-Keys, LLDP, NETCONF
• Διαμορφώστε τη συσκευή και φέρτε τη διαμόρφωση στην επιθυμητή (συμπεριλαμβανομένης της παλιάς) έκδοσης.
• Διαμόρφωση δοκιμής
• Ελέγχετε περιοδικά την κατάσταση όλων των συσκευών για αποκλίσεις από τις τρέχουσες και αναφέρετε σε ποιον πρέπει να είναι.
  Κατά τη διάρκεια της νύχτας, κάποιος πρόσθεσε αθόρυβα έναν κανόνα στο ACL.
• Παρακολούθηση απόδοσης.

Μέσα

Ακούγεται αρκετά περίπλοκο για να ξεκινήσει η αποσύνθεση του έργου σε στοιχεία.

Και θα είναι δέκα από αυτά:

1. Σύστημα απογραφής
2. Σύστημα διαχείρισης χώρου IP
3. Σύστημα περιγραφής υπηρεσιών δικτύου
4. Μηχανισμός αρχικοποίησης συσκευής
5. Προμηθευτής-αγνωστικό μοντέλο διαμόρφωσης
6. Διεπαφή προγράμματος οδήγησης για συγκεκριμένο προμηθευτή
7. Μηχανισμός παράδοσης διαμόρφωσης στη συσκευή
8. CI / CD
9. Μηχανισμός δημιουργίας αντιγράφων ασφαλείας και αναζήτησης αποκλίσεων
10. Σύστημα παρακολούθησης

Αυτό, παρεμπιπτόντως, είναι ένα παράδειγμα του πώς άλλαξε η άποψη για τους στόχους του κύκλου - υπήρχαν 4 στοιχεία στο προσχέδιο.

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

Συνιστώσα 1: Σύστημα απογραφής

Προφανώς, θέλουμε να μάθουμε ποιος εξοπλισμός βρίσκεται πού, με τι συνδέεται.
Το σύστημα απογραφής αποτελεί αναπόσπαστο μέρος κάθε επιχείρησης.
Τις περισσότερες φορές, μια επιχείρηση διαθέτει ξεχωριστό σύστημα απογραφής για συσκευές δικτύου, το οποίο επιλύει πιο συγκεκριμένα προβλήματα.
Ως μέρος αυτής της σειράς άρθρων, θα το ονομάσουμε DCIM - Data Center Infrastructure Management. Αν και ο ίδιος ο όρος DCIM, αυστηρά μιλώντας, περιλαμβάνει πολλά περισσότερα.

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

• Αριθμός αποθέματος
• Περιγραφή Τίτλου
• μοντέλο (Huawei CE12800, Juniper QFX5120 κ.λπ.)
• Χαρακτηριστικές παράμετροι (πίνακες, διεπαφές κ.λπ.)
• ρόλος (Leaf, Spine, Border Router κ.λπ.)
• Τοποθεσία (περιοχή, πόλη, κέντρο δεδομένων, ράφι, μονάδα)
• Διασυνδέσεις μεταξύ συσκευών
• Τοπολογία δικτύου

Είναι απολύτως σαφές ότι εμείς οι ίδιοι θέλουμε να τα μάθουμε όλα αυτά.
Θα βοηθήσει όμως αυτό για σκοπούς αυτοματισμού;
Βεβαίως.
Για παράδειγμα, γνωρίζουμε ότι σε ένα δεδομένο κέντρο δεδομένων σε διακόπτες Leaf, εάν είναι Huawei, θα πρέπει να εφαρμόζονται ACL για το φιλτράρισμα συγκεκριμένης κυκλοφορίας στο VLAN και εάν είναι Juniper, τότε στη μονάδα 0 της φυσικής διεπαφής.
Εναλλακτικά, πρέπει να ανοίξετε έναν νέο διακομιστή Syslog σε όλα τα σύνορα της περιοχής.

Σε αυτό θα αποθηκεύσουμε συσκευές εικονικού δικτύου, για παράδειγμα εικονικούς δρομολογητές ή ανακλαστήρες ρίζας. Μπορούμε να προσθέσουμε διακομιστές DNS, NTP, Syslog και γενικά οτιδήποτε σχετίζεται με τον ένα ή τον άλλο τρόπο με το δίκτυο.

Συστατικό 2: Σύστημα διαχείρισης χώρου IP

Ναι, και σήμερα υπάρχουν ομάδες ανθρώπων που παρακολουθούν τα προθέματα και τις διευθύνσεις IP σε ένα αρχείο Excel. Αλλά η σύγχρονη προσέγγιση εξακολουθεί να είναι μια βάση δεδομένων, με front-end σε nginx/apache, API και εκτεταμένες λειτουργίες για την εγγραφή διευθύνσεων IP και δικτύων χωρισμένα σε VRF.
IPAM - Διαχείριση διευθύνσεων IP.

Για τους σκοπούς μας, θα αποθηκεύσουμε τις ακόλουθες πληροφορίες σε αυτό:

• VLAN
• Επέκταση VRF
• Δίκτυα/Υποδίκτυα
• διευθύνσεις IP
• Σύνδεση διευθύνσεων σε συσκευές, δικτύων σε τοποθεσίες και αριθμούς VLAN

Και πάλι, είναι σαφές ότι θέλουμε να βεβαιωθούμε ότι όταν εκχωρούμε μια νέα διεύθυνση IP για το Loopback ToR, δεν θα σκοντάψουμε στο γεγονός ότι είχε ήδη εκχωρηθεί σε κάποιον. Ή ότι χρησιμοποιήσαμε το ίδιο πρόθεμα δύο φορές σε διαφορετικά άκρα του δικτύου.
Πώς όμως βοηθάει αυτό στον αυτοματισμό;
Είναι εύκολο.
Ζητάμε ένα πρόθεμα στο σύστημα με το ρόλο Loopbacks, το οποίο περιέχει διευθύνσεις IP διαθέσιμες για εκχώρηση - εάν βρεθεί, εκχωρούμε τη διεύθυνση, εάν όχι, ζητάμε τη δημιουργία νέου προθέματος.
Ή κατά τη δημιουργία μιας διαμόρφωσης συσκευής, μπορούμε να μάθουμε από το ίδιο σύστημα σε ποιο VRF θα πρέπει να βρίσκεται η διεπαφή.
Και κατά την εκκίνηση ενός νέου διακομιστή, το σενάριο συνδέεται στο σύστημα, ανακαλύπτει σε ποιο διακόπτη βρίσκεται ο διακομιστής, σε ποια θύρα και ποιο υποδίκτυο έχει εκχωρηθεί στη διεπαφή - και θα εκχωρήσει τη διεύθυνση διακομιστή από αυτήν.

Αυτό υποδηλώνει την επιθυμία να συνδυαστούν το DCIM και το IPAM σε ένα σύστημα, έτσι ώστε να μην αντιγραφούν λειτουργίες και να μην εξυπηρετηθούν δύο παρόμοιες οντότητες.
Αυτό θα κάνουμε.

Στοιχείο 3. Σύστημα για την περιγραφή των υπηρεσιών δικτύου

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

• Υποδομή
• Πελάτης.

Τα πρώτα έχουν σχεδιαστεί για να παρέχουν βασική συνδεσιμότητα και έλεγχο συσκευής. Αυτά περιλαμβάνουν VTY, SNMP, NTP, Syslog, AAA, πρωτόκολλα δρομολόγησης, CoPP κ.λπ.
Οι τελευταίοι οργανώνουν την υπηρεσία για τον πελάτη: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP κ.λπ.
Φυσικά, υπάρχουν και οριακές περιπτώσεις - πού να συμπεριληφθούν MPLS LDP, BGP; Ναι, και τα πρωτόκολλα δρομολόγησης μπορούν να χρησιμοποιηθούν για πελάτες. Αυτό όμως δεν είναι σημαντικό.

Και οι δύο τύποι υπηρεσιών αναλύονται σε αρχέγονα παραμέτρων:

• φυσικές και λογικές διεπαφές (tag/anteg, mtu)
• Διευθύνσεις IP και VRF (IP, IPv6, VRF)
• ACL και πολιτικές επεξεργασίας κίνησης
• Πρωτόκολλα (IGP, BGP, MPLS)
• Πολιτικές δρομολόγησης (λίστες προθεμάτων, κοινότητες, φίλτρα ASN).
• Βοηθητικές υπηρεσίες (SSH, NTP, LLDP, Syslog...)
• Και τα λοιπά.

Πώς ακριβώς θα το κάνουμε αυτό, δεν έχω ιδέα ακόμα. Θα το εξετάσουμε σε ξεχωριστό άρθρο.

Αν είναι λίγο πιο κοντά στη ζωή, τότε θα μπορούσαμε να το περιγράψουμε
Ο διακόπτης Leaf πρέπει να έχει περιόδους λειτουργίας BGP με όλους τους συνδεδεμένους διακόπτες Spine, να εισάγει συνδεδεμένα δίκτυα στη διαδικασία και να δέχεται μόνο δίκτυα από ένα συγκεκριμένο πρόθεμα από διακόπτες Spine. Περιορίστε το CoPP IPv6 ND σε 10 pps, κ.λπ.
Με τη σειρά τους, τα spines πραγματοποιούν συνεδρίες με όλα τα συνδεδεμένα καλώδια, λειτουργώντας ως ανακλαστήρες ρίζας και δέχονται από αυτά μόνο διαδρομές συγκεκριμένου μήκους και με μια συγκεκριμένη κοινότητα.

Εξάρτημα 4: Μηχανισμός εκκίνησης συσκευής

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

1. Εισαγάγετε τη συσκευή στο σύστημα απογραφής.
2. Επιλέξτε μια διεύθυνση IP διαχείρισης.
3. Ρυθμίστε τη βασική πρόσβαση σε αυτό:
   Όνομα κεντρικού υπολογιστή, διεύθυνση IP διαχείρισης, διαδρομή προς το δίκτυο διαχείρισης, χρήστες, κλειδιά SSH, πρωτόκολλα - telnet/SSH/NETCONF

Υπάρχουν τρεις προσεγγίσεις:

• Όλα είναι εντελώς χειροκίνητα. Η συσκευή φέρεται στο περίπτερο, όπου ένας συνηθισμένος οργανικός άνθρωπος θα την εισάγει στα συστήματα, θα συνδεθεί στην κονσόλα και θα τη διαμορφώσει. Μπορεί να λειτουργήσει σε μικρά στατικά δίκτυα.
• ZTP - Zero Touch Provisioning. Το υλικό έφτασε, σηκώθηκε, έλαβε μια διεύθυνση μέσω DHCP, πήγε σε έναν ειδικό διακομιστή και διαμορφώθηκε.
• Η υποδομή των διακομιστών κονσόλας, όπου η αρχική διαμόρφωση πραγματοποιείται μέσω της θύρας της κονσόλας σε αυτόματη λειτουργία.

Θα μιλήσουμε και για τα τρία σε ξεχωριστό άρθρο.

Στοιχείο 5: Προμηθευτής-αγνωστικό μοντέλο διαμόρφωσης

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

1. Μην προσαρμόζεστε σε μια συγκεκριμένη διεπαφή για αλληλεπίδραση με τη συσκευή. Είτε πρόκειται για CLI, NETCONF, RESTCONF, SNMP - το μοντέλο θα είναι το ίδιο.
2. Μην κρατάτε τον αριθμό των προτύπων/σεναρίων σύμφωνα με τον αριθμό των προμηθευτών στο δίκτυο και εάν αλλάξει η σχεδίαση, αλλάξτε το ίδιο πράγμα σε πολλά σημεία.
3. Φορτώστε τη διαμόρφωση από τη συσκευή (backup), βάλτε την στο ίδιο ακριβώς μοντέλο και συγκρίνετε απευθείας τη διαμόρφωση προορισμού με την υπάρχουσα για να υπολογίσετε το δέλτα και να προετοιμάσετε ένα patch διαμόρφωσης που θα αλλάξει μόνο εκείνα τα μέρη που είναι απαραίτητα ή θα εντοπίσει αποκλίσεις.

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

Στοιχείο 6. Διεπαφή προγράμματος οδήγησης για συγκεκριμένο προμηθευτή

Δεν πρέπει να κολακεύετε τον εαυτό σας με ελπίδες ότι μια μέρα θα είναι δυνατό να διαμορφώσετε ένα ciska με τον ίδιο ακριβώς τρόπο όπως ένα Juniper, απλά στέλνοντας ακριβώς τις ίδιες κλήσεις σε αυτούς. Παρά την αυξανόμενη δημοτικότητα των whiteboxes και την εμφάνιση υποστήριξης για τα NETCONF, RESTCONF, OpenConfig, το συγκεκριμένο περιεχόμενο που παρέχουν αυτά τα πρωτόκολλα διαφέρει από προμηθευτή σε προμηθευτή και αυτή είναι μια από τις ανταγωνιστικές διαφορές τους που δεν θα εγκαταλείψουν τόσο εύκολα.
Αυτό είναι περίπου το ίδιο με το OpenContrail και το OpenStack, που έχουν το RestAPI ως διεπαφή NorthBound, αναμένουν τελείως διαφορετικές κλήσεις.

Έτσι, στο πέμπτο βήμα, το ανεξάρτητο από τον προμηθευτή μοντέλο πρέπει να λάβει τη μορφή με την οποία θα πάει στο υλικό.
Και εδώ όλα τα μέσα είναι καλά (όχι): CLI, NETCONF, RESTCONF, SNMP απλά.

Επομένως, θα χρειαστούμε ένα πρόγραμμα οδήγησης που θα μεταφέρει το αποτέλεσμα του προηγούμενου βήματος στην απαιτούμενη μορφή ενός συγκεκριμένου προμηθευτή: ένα σύνολο εντολών CLI, μια δομή XML.

Εξάρτημα 7. Μηχανισμός παράδοσης διαμόρφωσης στη συσκευή

Δημιουργήσαμε τη διαμόρφωση, αλλά πρέπει ακόμα να παραδοθεί στις συσκευές - και, προφανώς, όχι με το χέρι.
Πρώτα, βρισκόμαστε αντιμέτωποι με το ερώτημα τι μεταφορικό μέσο θα χρησιμοποιήσουμε; Και σήμερα η επιλογή δεν είναι πια μικρή:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (αν και είναι ακραίο γιατί είναι ένας τρόπος να παραδοθούν FIB και όχι ρυθμίσεις)

Ας σημειωθεί το t είναι εδώ. Το CLI είναι κληρονομιά. SNMP... βήχας.
Το RESTCONF είναι ακόμα ένα άγνωστο ζώο· το REST API δεν υποστηρίζεται σχεδόν από κανέναν. Επομένως, θα επικεντρωθούμε στο NETCONF στη σειρά.

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

κατά δεύτερο λόγο, και με ποια εργαλεία θα το κάνουμε αυτό;
Υπάρχει επίσης μια μεγάλη επιλογή εδώ:

• Αυτογραφικό σενάριο ή πλατφόρμα. Ας οπλιστούμε με ncclient και asyncIO και ας κάνουμε τα πάντα μόνοι μας. Τι μας κοστίζει η κατασκευή ενός συστήματος ανάπτυξης από την αρχή;
• Η Ansible με την πλούσια βιβλιοθήκη μονάδων δικτύωσης.
• Το αλάτι με την πενιχρή δουλειά του με το δίκτυο και τη σύνδεση με το Napalm.
• Στην πραγματικότητα, η Napalm, η οποία γνωρίζει μερικούς πωλητές και αυτό είναι, αντίο.
• Το Nornir είναι ένα άλλο ζώο που θα ανατέμνουμε στο μέλλον.

Εδώ το φαβορί δεν έχει επιλεγεί ακόμα - θα ψάξουμε.

Τι άλλο είναι σημαντικό εδώ; Συνέπειες εφαρμογής της διαμόρφωσης.
Επιτυχημένος ή όχι. Υπάρχει ακόμα πρόσβαση στο υλικό ή όχι;
Φαίνεται ότι το commit θα βοηθήσει εδώ με την επιβεβαίωση και την επικύρωση του τι λήφθηκε στη συσκευή.
Αυτό, σε συνδυασμό με τη σωστή εφαρμογή του NETCONF, περιορίζει σημαντικά το εύρος των κατάλληλων συσκευών - πολλοί κατασκευαστές δεν υποστηρίζουν κανονικές δεσμεύσεις. Αλλά αυτό είναι μόνο ένα από τα προαπαιτούμενα RFP. Στο τέλος, κανείς δεν ανησυχεί ότι ούτε ένας Ρώσος πωλητής δεν θα συμμορφωθεί με την προϋπόθεση της διεπαφής 32*100GE. Ή μήπως ανησυχεί;

Εξάρτημα 8. CI/CD

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

Αλλά, όπως ειπώθηκε ήδη παραπάνω, δεν είμαστε κάποιου είδους βάρβαροι που θέλουν να κυλήσουν τα πάντα κατευθείαν στην παραγωγή.
Η παραγόμενη διαμόρφωση πρέπει πρώτα να περάσει από το Pipeline CI/CD.

Το CI/CD σημαίνει Συνεχής Ενοποίηση, Συνεχής Ανάπτυξη. Αυτή είναι μια προσέγγιση στην οποία η ομάδα όχι μόνο βγάζει μια νέα σημαντική έκδοση κάθε έξι μήνες, αντικαθιστώντας πλήρως την παλιά, αλλά εφαρμόζει τακτικά σταδιακά (Deployment) νέα λειτουργικότητα σε μικρές μερίδες, καθεμία από τις οποίες ελέγχεται διεξοδικά για συμβατότητα, ασφάλεια και απόδοση (Integration).

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

Με εξαίρεση τις εντολές εντοπισμού σφαλμάτων, απολύτως όλες οι αλλαγές στο δίκτυο πρέπει να περάσουν από τη γραμμή CI/CD - αυτή είναι η εγγύηση μας για μια ήσυχη ζωή και μια μακρά, ευτυχισμένη καριέρα.

Εξάρτημα 9. Σύστημα ανίχνευσης αντιγράφων ασφαλείας και ανωμαλιών

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

Αλλά το δεύτερο μέρος είναι πιο ενδιαφέρον - κάποιος πρέπει να παρακολουθεί αυτά τα αντίγραφα ασφαλείας. Και σε ορισμένες περιπτώσεις, αυτός ο κάποιος πρέπει να πάει και να τα γυρίσει όλα όπως ήταν, και σε άλλες, να νιαουρίσει σε κάποιον ότι κάτι δεν πάει καλά.
Για παράδειγμα, εάν έχει εμφανιστεί ένας νέος χρήστης που δεν είναι εγγεγραμμένος στις μεταβλητές, πρέπει να τον αφαιρέσετε από το hack. Και αν είναι καλύτερο να μην αγγίξετε έναν νέο κανόνα τείχους προστασίας, ίσως κάποιος μόλις ενεργοποίησε τον εντοπισμό σφαλμάτων ή ίσως η νέα υπηρεσία, ένα bungler, να μην έχει καταχωρηθεί σύμφωνα με τους κανονισμούς, αλλά οι άνθρωποι έχουν ήδη εγγραφεί σε αυτήν.

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

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

Συνιστώσα 10. Σύστημα παρακολούθησης

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

Η εξελισσόμενη σκέψη είναι ένα οργανικό μέρος της διαδικασίας CI/CD. Μετά την κυκλοφορία της διαμόρφωσης στο δίκτυο, πρέπει να είμαστε σε θέση να προσδιορίσουμε εάν όλα είναι εντάξει με αυτήν τώρα.
Και μιλάμε όχι μόνο και όχι τόσο για χρονοδιαγράμματα χρήσης διεπαφής ή διαθεσιμότητα κόμβων, αλλά για πιο λεπτά πράγματα - την παρουσία των απαραίτητων διαδρομών, τα χαρακτηριστικά σε αυτά, τον αριθμό των συνεδριών BGP, τους γείτονες OSPF, την απόδοση από άκρο σε άκρο των υπερκείμενων υπηρεσιών.
Σταμάτησαν να προστίθενται τα syslogs στον εξωτερικό διακομιστή ή χάλασε ο παράγοντας SFlow ή άρχισαν να αυξάνονται οι πτώσεις στις ουρές ή χάλασε η συνδεσιμότητα μεταξύ κάποιου ζεύγους προθεμάτων;

Θα αναλογιστούμε αυτό σε ξεχωριστό άρθρο.

Συμπέρασμα

Ως βάση, επέλεξα ένα από τα σύγχρονα σχέδια δικτύου κέντρων δεδομένων - το L3 Clos Fabric με πρωτόκολλο δρομολόγησης BGP.
Αυτή τη φορά θα δημιουργήσουμε το δίκτυο στο Juniper, γιατί τώρα η διεπαφή JunOs είναι ένα vanlove.

Ας κάνουμε τη ζωή μας πιο δύσκολη χρησιμοποιώντας μόνο εργαλεία Ανοιχτού Κώδικα και ένα δίκτυο πολλών προμηθευτών - επομένως, εκτός από το Juniper, θα επιλέξω έναν ακόμη τυχερό στην πορεία.

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

Και ναι, δεν υπόσχομαι να τελειώσω με χάρη αυτόν τον κύκλο με μια έτοιμη λύση. 🙂

χρήσιμοι σύνδεσμοι

• Πριν εμβαθύνουμε στη σειρά, αξίζει να διαβάσετε το βιβλίο της Natasha Samoilenko Python για Μηχανικούς Δικτύων. Και ίσως περάσει πορεία.
• Θα είναι επίσης χρήσιμο να διαβάσετε RFC σχετικά με το σχεδιασμό εργοστασίων κέντρων δεδομένων από το Facebook από τον Peter Lapukhov.
• Η τεκμηρίωση της αρχιτεκτονικής θα σας δώσει μια ιδέα για το πώς λειτουργεί το Overlay SDN. Ύφασμα βολφραμίου (πρώην Open Contrail).

Ευχαριστώ

Ρωμαϊκό φαράγγι. Για σχόλια και επεξεργασίες.
Αρτιόμ Τσερνομπάι. Για το KDPV.

Πηγή: www.habr.com