Το cloud computing διεισδύει όλο και πιο βαθιά στη ζωή μας και πιθανότατα δεν υπάρχει ούτε ένα άτομο που να μην έχει χρησιμοποιήσει καμία υπηρεσία cloud τουλάχιστον μία φορά. Ωστόσο, τι ακριβώς είναι ένα σύννεφο και πώς λειτουργεί, λίγοι γνωρίζουν, ακόμη και σε επίπεδο ιδέας. Το 5G γίνεται ήδη πραγματικότητα και η τηλεπικοινωνιακή υποδομή αρχίζει να μετακινείται από λύσεις πυλώνων σε λύσεις cloud, όπως ακριβώς έγινε όταν πέρασε από λύσεις εντελώς υλικού σε εικονικοποιημένους «πυλώνες».
Σήμερα θα μιλήσουμε για τον εσωτερικό κόσμο της υποδομής cloud, ειδικότερα θα δούμε τα βασικά του τμήματος δικτύου.
Τι είναι ένα σύννεφο; Η ίδια εικονικοποίηση - προβολή προφίλ;
Κάτι παραπάνω από μια λογική ερώτηση. Όχι - αυτό δεν είναι εικονικοποίηση, αν και δεν θα μπορούσε να γίνει χωρίς αυτό. Ας δούμε δύο ορισμούς:
Cloud computing (εφεξής καλούμενο Cloud) είναι ένα μοντέλο για την παροχή φιλικής προς τον χρήστη πρόσβασης σε κατανεμημένους υπολογιστικούς πόρους που πρέπει να αναπτυχθούν και να εκκινηθούν κατόπιν ζήτησης με τη χαμηλότερη δυνατή καθυστέρηση και ελάχιστο κόστος για τον πάροχο υπηρεσιών.
Εικονικοποίηση - αυτή είναι η δυνατότητα να διαιρέσετε μια φυσική οντότητα (για παράδειγμα, έναν διακομιστή) σε πολλές εικονικές, αυξάνοντας έτσι τη χρήση των πόρων (για παράδειγμα, είχατε 3 διακομιστές φορτωμένους στο 25-30 τοις εκατό, μετά την εικονικοποίηση έχετε φορτώσει 1 διακομιστή στο 80-90 τοις εκατό). Φυσικά, η εικονικοποίηση καταναλώνει μερικούς από τους πόρους - πρέπει να τροφοδοτήσετε τον hypervisor, ωστόσο, όπως έχει δείξει η πρακτική, το παιχνίδι αξίζει το κερί. Ιδανικό παράδειγμα εικονικοποίησης είναι το VMWare, που προετοιμάζει τέλεια τις εικονικές μηχανές, ή για παράδειγμα το KVM, το οποίο προτιμώ, αλλά αυτό είναι θέμα γούστου.
Χρησιμοποιούμε εικονικοποίηση χωρίς να το καταλαβαίνουμε, και ακόμη και οι σιδερένιοι δρομολογητές χρησιμοποιούν ήδη εικονικοποίηση - για παράδειγμα, στην τελευταία έκδοση του JunOS, το λειτουργικό σύστημα εγκαθίσταται ως εικονική μηχανή πάνω από μια διανομή Linux σε πραγματικό χρόνο (Wind River 9). Αλλά η εικονικοποίηση δεν είναι το σύννεφο, αλλά το σύννεφο δεν μπορεί να υπάρξει χωρίς εικονικοποίηση.
Η εικονικοποίηση είναι ένα από τα δομικά στοιχεία πάνω στα οποία είναι χτισμένο το σύννεφο.
Το να δημιουργήσετε ένα σύννεφο συλλέγοντας απλώς αρκετούς hypervisors σε έναν τομέα L2, προσθέτοντας μερικά yaml playbooks για αυτόματη εγγραφή vlans μέσω κάποιου είδους ansible και παρεμβολές κάτι σαν ένα σύστημα ενορχήστρωσης σε όλα για την αυτόματη δημιουργία εικονικών μηχανών, δεν θα λειτουργήσει. Θα είναι πιο ακριβές, αλλά το Φρανκενστάιν που προκύπτει δεν είναι το σύννεφο που χρειαζόμαστε, αν και μπορεί να είναι το απόλυτο όνειρο για άλλους. Επιπλέον, αν πάρετε το ίδιο Openstack, ουσιαστικά εξακολουθεί να είναι Frankenstein, αλλά ω, καλά, ας μην το συζητήσουμε προς το παρόν.
Αλλά καταλαβαίνω ότι από τον ορισμό που παρουσιάστηκε παραπάνω δεν είναι απολύτως σαφές τι μπορεί στην πραγματικότητα να ονομαστεί σύννεφο.
Επομένως, ένα έγγραφο από το NIST (Εθνικό Ινστιτούτο Προτύπων και Τεχνολογίας) παρέχει 5 βασικά χαρακτηριστικά που πρέπει να έχει μια υποδομή cloud:
Παροχή υπηρεσιών κατόπιν αιτήματος. Ο χρήστης πρέπει να έχει ελεύθερη πρόσβαση στους πόρους του υπολογιστή που του έχουν διατεθεί (όπως δίκτυα, εικονικοί δίσκοι, μνήμη, πυρήνες επεξεργαστή κ.λπ.) και αυτοί οι πόροι πρέπει να παρέχονται αυτόματα - δηλαδή χωρίς παρέμβαση του παρόχου υπηρεσιών.
Ευρεία διαθεσιμότητα υπηρεσίας. Η πρόσβαση στους πόρους πρέπει να παρέχεται με τυπικούς μηχανισμούς που θα επιτρέπουν τη χρήση τόσο τυπικών υπολογιστών όσο και thin clients και φορητών συσκευών.
Συνδυασμός πόρων σε δεξαμενές. Οι ομάδες πόρων πρέπει να μπορούν να παρέχουν πόρους σε πολλούς πελάτες ταυτόχρονα, διασφαλίζοντας ότι οι πελάτες είναι απομονωμένοι και απαλλαγμένοι από αμοιβαία επιρροή και ανταγωνισμό για πόρους. Τα δίκτυα περιλαμβάνονται επίσης στα pools, γεγονός που υποδηλώνει τη δυνατότητα χρήσης επικαλυπτόμενων διευθύνσεων. Οι πισίνες πρέπει να μπορούν να κλιμακώνονται κατά παραγγελία. Η χρήση των pools καθιστά δυνατή την παροχή του απαραίτητου επιπέδου ανοχής σφαλμάτων πόρων και αφαίρεσης φυσικών και εικονικών πόρων - στον παραλήπτη της υπηρεσίας παρέχεται απλώς το σύνολο των πόρων που ζήτησε (όπου αυτοί οι πόροι βρίσκονται φυσικά, σε πόσα διακομιστές και μεταγωγείς - δεν έχει σημασία για τον πελάτη). Ωστόσο, πρέπει να λάβουμε υπόψη το γεγονός ότι ο πάροχος πρέπει να διασφαλίζει τη διαφανή κράτηση αυτών των πόρων.
Γρήγορη προσαρμογή σε διαφορετικές συνθήκες. Οι υπηρεσίες πρέπει να είναι ευέλικτες - ταχεία παροχή πόρων, ανακατανομή τους, προσθήκη ή μείωση πόρων κατόπιν αιτήματος του πελάτη και από την πλευρά του πελάτη θα πρέπει να υπάρχει η αίσθηση ότι οι πόροι του cloud είναι ατελείωτοι. Για ευκολία κατανόησης, για παράδειγμα, δεν βλέπετε μια προειδοποίηση ότι μέρος του χώρου στο δίσκο σας στο Apple iCloud έχει εξαφανιστεί επειδή ο σκληρός δίσκος του διακομιστή έχει υποστεί βλάβη και οι μονάδες δίσκου παρουσιάζουν βλάβη. Επιπλέον, από την πλευρά σας, οι δυνατότητες αυτής της υπηρεσίας είναι σχεδόν απεριόριστες - χρειάζεστε 2 TB - κανένα πρόβλημα, την πληρώσατε και την παραλάβατε. Ένα παρόμοιο παράδειγμα μπορεί να δοθεί με το Google.Drive ή το Yandex.Disk.
Δυνατότητα μέτρησης της παρεχόμενης υπηρεσίας. Τα συστήματα cloud πρέπει να ελέγχουν και να βελτιστοποιούν αυτόματα τους πόρους που καταναλώνονται και αυτοί οι μηχανισμοί πρέπει να είναι διαφανείς τόσο για τον χρήστη όσο και για τον πάροχο υπηρεσιών. Δηλαδή, μπορείτε πάντα να ελέγχετε πόσους πόρους καταναλώνετε εσείς και οι πελάτες σας.
Αξίζει να ληφθεί υπόψη το γεγονός ότι αυτές οι απαιτήσεις είναι ως επί το πλείστον απαιτήσεις για ένα δημόσιο cloud, επομένως για ένα ιδιωτικό σύννεφο (δηλαδή, ένα σύννεφο που εκτοξεύεται για τις εσωτερικές ανάγκες της εταιρείας), αυτές οι απαιτήσεις μπορούν να προσαρμοστούν ελαφρώς. Ωστόσο, πρέπει να γίνουν ακόμα, διαφορετικά δεν θα έχουμε όλα τα οφέλη του υπολογιστικού νέφους.
Γιατί χρειαζόμαστε ένα σύννεφο;
Ωστόσο, οποιαδήποτε νέα ή υπάρχουσα τεχνολογία, οποιοδήποτε νέο πρωτόκολλο δημιουργείται για κάτι (καλά, εκτός από το RIP-ng, φυσικά). Κανείς δεν χρειάζεται ένα πρωτόκολλο για χάρη ενός πρωτοκόλλου (καλά, εκτός από το RIP-ng, φυσικά). Είναι λογικό το Cloud να δημιουργείται για να παρέχει κάποιου είδους υπηρεσία στον χρήστη/πελάτη. Όλοι είμαστε εξοικειωμένοι με τουλάχιστον μερικές υπηρεσίες cloud, για παράδειγμα το Dropbox ή το Google.Docs, και πιστεύω ότι οι περισσότεροι άνθρωποι τις χρησιμοποιούν με επιτυχία - για παράδειγμα, αυτό το άρθρο γράφτηκε χρησιμοποιώντας την υπηρεσία cloud Google.Docs. Αλλά οι υπηρεσίες cloud που γνωρίζουμε είναι μόνο ένα μέρος των δυνατοτήτων του cloud — πιο συγκεκριμένα, είναι μόνο μια υπηρεσία τύπου SaaS. Μπορούμε να παρέχουμε μια υπηρεσία cloud με τρεις τρόπους: με τη μορφή SaaS, PaaS ή IaaS. Ποια υπηρεσία χρειάζεστε εξαρτάται από τις επιθυμίες και τις δυνατότητές σας.
Ας δούμε το καθένα με τη σειρά:
Λογισμικό ως υπηρεσία (SaaS) είναι ένα μοντέλο για την παροχή μιας ολοκληρωμένης υπηρεσίας στον πελάτη, για παράδειγμα, μια υπηρεσία email όπως το Yandex.Mail ή το Gmail. Σε αυτό το μοντέλο παροχής υπηρεσιών, εσείς, ως πελάτης, στην πραγματικότητα δεν κάνετε τίποτα εκτός από τη χρήση των υπηρεσιών - δηλαδή, δεν χρειάζεται να σκεφτείτε τη ρύθμιση της υπηρεσίας, την ανοχή σφαλμάτων ή τον πλεονασμό της. Το κύριο πράγμα είναι να μην θέσετε σε κίνδυνο τον κωδικό πρόσβασής σας· ο πάροχος αυτής της υπηρεσίας θα κάνει τα υπόλοιπα για εσάς. Από την πλευρά του παρόχου υπηρεσιών, είναι πλήρως υπεύθυνος για ολόκληρη την υπηρεσία - από το υλικό διακομιστή και τα λειτουργικά συστήματα κεντρικού υπολογιστή έως τις ρυθμίσεις βάσεων δεδομένων και λογισμικού.
Πλατφόρμα ως υπηρεσία (PaaS) — όταν χρησιμοποιείτε αυτό το μοντέλο, ο πάροχος υπηρεσιών παρέχει στον πελάτη ένα κομμάτι εργασίας για την υπηρεσία, για παράδειγμα, ας πάρουμε έναν διακομιστή Web. Ο πάροχος υπηρεσιών παρείχε στον πελάτη έναν εικονικό διακομιστή (στην πραγματικότητα, ένα σύνολο πόρων, όπως RAM/CPU/Αποθήκευση/Δίκτυα, κ.λπ.), και μάλιστα εγκατέστησε το λειτουργικό σύστημα και το απαραίτητο λογισμικό σε αυτόν τον διακομιστή, ωστόσο, η διαμόρφωση του όλα αυτά τα κάνει ο ίδιος ο πελάτης και για την απόδοση της υπηρεσίας απαντά ο πελάτης. Ο πάροχος υπηρεσιών, όπως και στην προηγούμενη περίπτωση, είναι υπεύθυνος για την απόδοση του φυσικού εξοπλισμού, των hypervisors, της ίδιας της εικονικής μηχανής, της διαθεσιμότητας του δικτύου κ.λπ., αλλά η ίδια η υπηρεσία δεν είναι πλέον στην περιοχή ευθύνης της.
Υποδομή ως υπηρεσία (IaaS) - αυτή η προσέγγιση είναι ήδη πιο ενδιαφέρουσα, στην πραγματικότητα, ο πάροχος υπηρεσιών παρέχει στον πελάτη μια πλήρη εικονική υποδομή - δηλαδή ένα σύνολο (δεξαμενή) πόρων, όπως πυρήνες CPU, RAM, δίκτυα κ.λπ. Όλα τα άλλα εξαρτώνται από ο πελάτης - τι θέλει να κάνει ο πελάτης με αυτούς τους πόρους εντός του κατανεμημένου pool (ποσόστωση) - δεν είναι ιδιαίτερα σημαντικό για τον προμηθευτή. Είτε ο πελάτης θέλει να δημιουργήσει το δικό του vEPC είτε ακόμα και να δημιουργήσει έναν μίνι χειριστή και να παρέχει υπηρεσίες επικοινωνίας - χωρίς αμφιβολία - κάντε το. Σε ένα τέτοιο σενάριο, ο πάροχος υπηρεσιών είναι υπεύθυνος για την παροχή πόρων, την ανοχή και τη διαθεσιμότητά τους σε σφάλματα, καθώς και το λειτουργικό σύστημα που του επιτρέπει να συγκεντρώσει αυτούς τους πόρους και να τους κάνει διαθέσιμους στον πελάτη με τη δυνατότητα να αυξάνει ή να μειώνει τους πόρους ανά πάσα στιγμή. κατόπιν αιτήματος του πελάτη. Ο υπολογιστής-πελάτης διαμορφώνει μόνος του όλες τις εικονικές μηχανές και άλλα κουπόνια μέσω της πύλης και της κονσόλας αυτοεξυπηρέτησης, συμπεριλαμβανομένης της ρύθμισης δικτύων (εκτός από εξωτερικά δίκτυα).
Τι είναι το OpenStack;
Και στις τρεις επιλογές, ο πάροχος υπηρεσιών χρειάζεται ένα λειτουργικό σύστημα που θα επιτρέπει τη δημιουργία μιας υποδομής cloud. Στην πραγματικότητα, με το SaaS, περισσότερα από ένα τμήματα είναι υπεύθυνα για ολόκληρη τη στοίβα τεχνολογιών - υπάρχει ένα τμήμα που είναι υπεύθυνο για την υποδομή - δηλαδή, παρέχει το IaaS σε άλλο τμήμα, αυτό το τμήμα παρέχει SaaS στον πελάτη. Το OpenStack είναι ένα από τα λειτουργικά συστήματα cloud που σας επιτρέπει να συλλέξετε μια δέσμη μεταγωγέων, διακομιστών και συστημάτων αποθήκευσης σε μια ενιαία ομάδα πόρων, να χωρίσετε αυτήν την κοινή ομάδα σε υποομάδες (ενοικιαστές) και να παρέχετε αυτούς τους πόρους σε πελάτες μέσω του δικτύου.
OpenStack είναι ένα λειτουργικό σύστημα cloud που σας επιτρέπει να ελέγχετε μεγάλες ομάδες υπολογιστικών πόρων, αποθήκευσης δεδομένων και πόρων δικτύου, που παρέχονται και διαχειρίζονται μέσω API χρησιμοποιώντας τυπικούς μηχανισμούς ελέγχου ταυτότητας.
Με άλλα λόγια, αυτό είναι ένα σύνολο έργων ελεύθερου λογισμικού που έχει σχεδιαστεί για τη δημιουργία υπηρεσιών cloud (τόσο δημόσιες όσο και ιδιωτικές) - δηλαδή ένα σύνολο εργαλείων που σας επιτρέπουν να συνδυάσετε διακομιστή και εναλλαγή εξοπλισμού σε μια ενιαία ομάδα πόρων, διαχείριση αυτούς τους πόρους, παρέχοντας το απαραίτητο επίπεδο ανοχής σφαλμάτων.
Κατά τη στιγμή της σύνταξης αυτού του υλικού, η δομή του OpenStack μοιάζει με αυτό:
Φωτογραφία από
Κάθε ένα από τα στοιχεία που περιλαμβάνονται στο OpenStack εκτελεί μια συγκεκριμένη λειτουργία. Αυτή η κατανεμημένη αρχιτεκτονική σάς επιτρέπει να συμπεριλάβετε στη λύση το σύνολο των λειτουργικών στοιχείων που χρειάζεστε. Ωστόσο, ορισμένα συστατικά είναι συστατικά ρίζας και η αφαίρεσή τους θα οδηγήσει σε πλήρη ή μερική αλειτουργία του διαλύματος στο σύνολό του. Αυτά τα εξαρτήματα ταξινομούνται συνήθως ως:
- Πίνακας διαχείρισης — Βασισμένο στο Web GUI για τη διαχείριση υπηρεσιών OpenStack
- Θεμέλιο είναι μια κεντρική υπηρεσία ταυτότητας που παρέχει λειτουργίες ελέγχου ταυτότητας και εξουσιοδότησης για άλλες υπηρεσίες, καθώς και διαχείριση των διαπιστευτηρίων χρήστη και των ρόλων τους.
- Νετρόνιο - μια υπηρεσία δικτύου που παρέχει συνδεσιμότητα μεταξύ των διεπαφών διαφόρων υπηρεσιών OpenStack (συμπεριλαμβανομένης της συνδεσιμότητας μεταξύ των VM και της πρόσβασής τους στον έξω κόσμο)
- Ασβόλη — παρέχει πρόσβαση σε μπλοκ αποθήκευσης για εικονικές μηχανές
- Nova — διαχείριση του κύκλου ζωής των εικονικών μηχανών
- Ματιά — αποθήκη εικόνων και στιγμιότυπων εικονικής μηχανής
- Swift — παρέχει πρόσβαση στο αντικείμενο αποθήκευσης
- Κιλόμετρο — υπηρεσία που παρέχει τη δυνατότητα συλλογής τηλεμετρίας και μέτρησης διαθέσιμων και καταναλωμένων πόρων
- θερμότητα — ενορχήστρωση βασισμένη σε πρότυπα για αυτόματη δημιουργία και παροχή πόρων
Μπορείτε να δείτε μια πλήρη λίστα όλων των έργων και τον σκοπό τους .
Κάθε στοιχείο OpenStack είναι μια υπηρεσία που εκτελεί μια συγκεκριμένη λειτουργία και παρέχει ένα API για τη διαχείριση αυτής της λειτουργίας και την αλληλεπίδραση με άλλες υπηρεσίες λειτουργικού συστήματος cloud για τη δημιουργία μιας ενοποιημένης υποδομής. Για παράδειγμα, η Nova παρέχει διαχείριση υπολογιστικών πόρων και ένα API για πρόσβαση στη διαμόρφωση αυτών των πόρων, το Glance παρέχει διαχείριση εικόνας και ένα API για τη διαχείρισή τους, το Cinder παρέχει αποθήκευση μπλοκ και ένα API για τη διαχείρισή του κ.λπ. Όλες οι λειτουργίες συνδέονται με πολύ στενό τρόπο.
Ωστόσο, αν το κοιτάξετε, όλες οι υπηρεσίες που εκτελούνται στο OpenStack είναι τελικά κάποιο είδος εικονικής μηχανής (ή κοντέινερ) συνδεδεμένο στο δίκτυο. Τίθεται το ερώτημα - γιατί χρειαζόμαστε τόσα πολλά στοιχεία;
Ας δούμε τον αλγόριθμο για τη δημιουργία μιας εικονικής μηχανής και τη σύνδεσή της με το δίκτυο και τη μόνιμη αποθήκευση στο Openstack.
- Όταν δημιουργείτε ένα αίτημα για τη δημιουργία ενός μηχανήματος, είτε πρόκειται για αίτημα μέσω του Horizon (Dashboard) είτε για αίτημα μέσω του CLI, το πρώτο πράγμα που συμβαίνει είναι η εξουσιοδότηση του αιτήματός σας στο Keystone - μπορείτε να δημιουργήσετε ένα μηχάνημα, έχει το το δικαίωμα χρήσης αυτού του δικτύου, το προσχέδιο της ποσόστωσής σας κ.λπ.
- Το Keystone ελέγχει την ταυτότητα του αιτήματός σας και δημιουργεί ένα διακριτικό ταυτότητας στο μήνυμα απάντησης, το οποίο θα χρησιμοποιηθεί περαιτέρω. Έχοντας λάβει απάντηση από την Keystone, το αίτημα αποστέλλεται στη Nova (nova api).
- Το Nova-api ελέγχει την εγκυρότητα του αιτήματός σας επικοινωνώντας με την Keystone χρησιμοποιώντας το διακριτικό εξουσιοδότησης που δημιουργήθηκε προηγουμένως
- Το Keystone εκτελεί έλεγχο ταυτότητας και παρέχει πληροφορίες σχετικά με τα δικαιώματα και τους περιορισμούς που βασίζονται σε αυτό το διακριτικό ελέγχου ταυτότητας.
- Το Nova-api δημιουργεί μια καταχώρηση για το νέο VM στη βάση δεδομένων nova και μεταβιβάζει το αίτημα για τη δημιουργία του μηχανήματος στο nova-scheduler.
- Το Nova-scheduler επιλέγει τον κεντρικό υπολογιστή (κόμβο υπολογιστή) στον οποίο θα αναπτυχθεί το VM με βάση τις καθορισμένες παραμέτρους, βάρη και ζώνες. Μια εγγραφή αυτού και το αναγνωριστικό VM εγγράφονται στη nova-database.
- Στη συνέχεια, το nova-scheduler επικοινωνεί με το nova-compute με ένα αίτημα για ανάπτυξη μιας παρουσίας. Το Nova-compute έρχεται σε επαφή με το nova-conductor για να λάβει πληροφορίες σχετικά με τις παραμέτρους του μηχανήματος (το nova-conductor είναι ένα στοιχείο nova που λειτουργεί ως διακομιστής μεσολάβησης μεταξύ της βάσης δεδομένων nova και του nova-compute, περιορίζοντας τον αριθμό των αιτημάτων στη βάση δεδομένων nova για την αποφυγή προβλημάτων με τη βάση δεδομένων μείωση του φορτίου συνέπειας).
- Το Nova-conductor λαμβάνει τις ζητούμενες πληροφορίες από τη βάση δεδομένων nova και τις μεταβιβάζει στο nova-compute.
- Στη συνέχεια, οι κλήσεις nova-compute ρίχνουν μια ματιά για να αποκτήσουν το αναγνωριστικό εικόνας. Η Glace επικυρώνει το αίτημα στο Keystone και επιστρέφει τις ζητούμενες πληροφορίες.
- Η Nova-compute συνδέει το νετρόνιο για να λάβει πληροφορίες σχετικά με τις παραμέτρους του δικτύου. Παρόμοια με μια ματιά, το νετρόνιο επικυρώνει το αίτημα στο Keystone, μετά από αυτό δημιουργεί μια καταχώρηση στη βάση δεδομένων (αναγνωριστικό θύρας, κ.λπ.), δημιουργεί ένα αίτημα για τη δημιουργία μιας θύρας και επιστρέφει τις ζητούμενες πληροφορίες στο nova-compute.
- Nova-υπολογίστε τις επαφές με ένα αίτημα να εκχωρηθεί ένας τόμος στην εικονική μηχανή. Παρόμοια με μια ματιά, ο μηλίτης επικυρώνει το αίτημα στο Keystone, δημιουργεί ένα αίτημα δημιουργίας τόμου και επιστρέφει τις ζητούμενες πληροφορίες.
- Οι επαφές Nova-compute libvirt με αίτημα ανάπτυξης μιας εικονικής μηχανής με τις καθορισμένες παραμέτρους.
Στην πραγματικότητα, μια φαινομενικά απλή λειτουργία δημιουργίας μιας απλής εικονικής μηχανής μετατρέπεται σε μια τέτοια δίνη κλήσεων API μεταξύ στοιχείων της πλατφόρμας cloud. Επιπλέον, όπως μπορείτε να δείτε, ακόμη και οι προηγουμένως καθορισμένες υπηρεσίες αποτελούνται επίσης από μικρότερα στοιχεία μεταξύ των οποίων υπάρχει αλληλεπίδραση. Η δημιουργία ενός μηχανήματος είναι μόνο ένα μικρό μέρος αυτού που σας επιτρέπει να κάνετε η πλατφόρμα cloud - υπάρχει μια υπηρεσία υπεύθυνη για την εξισορρόπηση της κυκλοφορίας, μια υπηρεσία υπεύθυνη για την αποθήκευση μπλοκ, μια υπηρεσία υπεύθυνη για DNS, μια υπηρεσία υπεύθυνη για την παροχή γυμνών μεταλλικών διακομιστών κ.λπ. Το cloud σάς επιτρέπει να αντιμετωπίζετε τις εικονικές μηχανές σας σαν ένα κοπάδι προβάτων (σε αντίθεση με την εικονικοποίηση). Εάν συμβεί κάτι στο μηχάνημά σας σε εικονικό περιβάλλον - το επαναφέρετε από αντίγραφα ασφαλείας κ.λπ., αλλά οι εφαρμογές cloud είναι κατασκευασμένες με τέτοιο τρόπο ώστε η εικονική μηχανή να μην παίζει τόσο σημαντικό ρόλο - η εικονική μηχανή "πέθανε" - κανένα πρόβλημα - δημιουργείται απλά ένα νέο το όχημα βασίζεται στο πρότυπο και, όπως λένε, η ομάδα δεν παρατήρησε την απώλεια του μαχητή. Φυσικά, αυτό προβλέπει την παρουσία μηχανισμών ενορχήστρωσης - χρησιμοποιώντας πρότυπα Heat, μπορείτε εύκολα να αναπτύξετε μια σύνθετη λειτουργία που αποτελείται από δεκάδες δίκτυα και εικονικές μηχανές.
Αξίζει πάντα να έχετε κατά νου ότι δεν υπάρχει υποδομή cloud χωρίς δίκτυο - κάθε στοιχείο με τον ένα ή τον άλλο τρόπο αλληλεπιδρά με άλλα στοιχεία μέσω του δικτύου. Επιπλέον, το cloud έχει ένα απολύτως μη στατικό δίκτυο. Φυσικά, το δίκτυο υποστρώματος είναι ακόμη περισσότερο ή λιγότερο στατικό - νέοι κόμβοι και διακόπτες δεν προστίθενται κάθε μέρα, αλλά το στοιχείο επικάλυψης μπορεί και θα αλλάζει αναπόφευκτα συνεχώς - νέα δίκτυα θα προστεθούν ή θα διαγραφούν, νέες εικονικές μηχανές θα εμφανιστούν και οι παλιές θα καλούπι. Και όπως θυμάστε από τον ορισμό του cloud που δίνεται στην αρχή του άρθρου, οι πόροι θα πρέπει να κατανέμονται στον χρήστη αυτόματα και με την ελάχιστη (ή καλύτερα, χωρίς) παρέμβαση από τον πάροχο υπηρεσιών. Δηλαδή, ο τύπος παροχής πόρων δικτύου που υπάρχει τώρα με τη μορφή front-end με τη μορφή του προσωπικού σας λογαριασμού προσβάσιμου μέσω http/https και του εφημερεύοντος μηχανικού δικτύου Vasily ως backend δεν είναι σύννεφο, ακόμη και αν ο Βασίλι έχει οκτώ χέρια.
Το Neutron, ως υπηρεσία δικτύου, παρέχει ένα API για τη διαχείριση του τμήματος δικτύου της υποδομής cloud. Η υπηρεσία τροφοδοτεί και διαχειρίζεται το τμήμα δικτύωσης του Openstack παρέχοντας ένα επίπεδο αφαίρεσης που ονομάζεται Network-as-a-Service (NaaS). Δηλαδή, το δίκτυο είναι η ίδια εικονική μετρήσιμη μονάδα όπως, για παράδειγμα, οι εικονικοί πυρήνες της CPU ή η ποσότητα της μνήμης RAM.
Αλλά προτού προχωρήσουμε στην αρχιτεκτονική του τμήματος δικτύου του OpenStack, ας εξετάσουμε πώς λειτουργεί αυτό το δίκτυο στο OpenStack και γιατί το δίκτυο είναι σημαντικό και αναπόσπαστο μέρος του cloud.
Έτσι έχουμε δύο RED client VMs και δύο GREEN client VM. Ας υποθέσουμε ότι αυτά τα μηχανήματα βρίσκονται σε δύο hypervisors με αυτόν τον τρόπο:
Αυτή τη στιγμή, πρόκειται απλώς για εικονικοποίηση 4 διακομιστών και τίποτα περισσότερο, αφού μέχρι στιγμής το μόνο που έχουμε κάνει είναι να εικονικοποιήσουμε 4 διακομιστές, τοποθετώντας τους σε δύο φυσικούς διακομιστές. Και μέχρι στιγμής δεν είναι καν συνδεδεμένοι στο δίκτυο.
Για να δημιουργήσουμε ένα σύννεφο, πρέπει να προσθέσουμε πολλά στοιχεία. Αρχικά, εικονικοποιούμε το τμήμα δικτύου - πρέπει να συνδέσουμε αυτά τα 4 μηχανήματα σε ζεύγη και οι πελάτες θέλουν μια σύνδεση L2. Μπορείτε να χρησιμοποιήσετε έναν διακόπτη και να διαμορφώσετε έναν κορμό προς την κατεύθυνσή του και να επιλύσετε τα πάντα χρησιμοποιώντας μια γέφυρα linux ή, για πιο προχωρημένους χρήστες, το openvswitch (θα επιστρέψουμε σε αυτό αργότερα). Αλλά μπορεί να υπάρχουν πολλά δίκτυα και η συνεχής ώθηση του L2 μέσω ενός διακόπτη δεν είναι η καλύτερη ιδέα - υπάρχουν διαφορετικά τμήματα, ένα γραφείο εξυπηρέτησης, μήνες αναμονής για την ολοκλήρωση μιας αίτησης, εβδομάδες αντιμετώπισης προβλημάτων - στον σύγχρονο κόσμο αυτό η προσέγγιση δεν λειτουργεί πλέον. Και όσο πιο γρήγορα μια εταιρεία το καταλάβει αυτό, τόσο πιο εύκολο είναι για αυτήν να προχωρήσει. Επομένως, μεταξύ των hypervisors θα επιλέξουμε ένα δίκτυο L3 μέσω του οποίου θα επικοινωνούν οι εικονικές μας μηχανές και πάνω από αυτό το δίκτυο L3 θα δημιουργήσουμε εικονικά δίκτυα επικάλυψης L2 όπου θα τρέχει η κίνηση των εικονικών μας μηχανών. Μπορείτε να χρησιμοποιήσετε GRE, Geneve ή VxLAN ως ενθυλάκωση. Ας επικεντρωθούμε στο τελευταίο προς το παρόν, αν και δεν είναι ιδιαίτερα σημαντικό.
Πρέπει να εντοπίσουμε το VTEP κάπου (ελπίζω όλοι να είναι εξοικειωμένοι με την ορολογία VxLAN). Δεδομένου ότι έχουμε ένα δίκτυο L3 που προέρχεται απευθείας από τους διακομιστές, τίποτα δεν μας εμποδίζει να τοποθετήσουμε το VTEP στους ίδιους τους διακομιστές και το OVS (OpenvSwitch) είναι εξαιρετικό στο να το κάνει αυτό. Ως αποτέλεσμα, πήραμε αυτό το σχέδιο:
Δεδομένου ότι η κίνηση μεταξύ των VM πρέπει να διαιρεθεί, οι θύρες προς τις εικονικές μηχανές θα έχουν διαφορετικούς αριθμούς vlan. Ο αριθμός ετικέτας παίζει ρόλο μόνο μέσα σε έναν εικονικό διακόπτη, αφού όταν ενσωματωθεί σε VxLAN μπορούμε εύκολα να τον αφαιρέσουμε, αφού θα έχουμε VNI.
Τώρα μπορούμε να δημιουργήσουμε τα μηχανήματα και τα εικονικά δίκτυά μας για αυτούς χωρίς κανένα πρόβλημα.
Ωστόσο, τι γίνεται αν ο πελάτης έχει άλλο μηχάνημα, αλλά βρίσκεται σε διαφορετικό δίκτυο; Χρειαζόμαστε rooting μεταξύ δικτύων. Θα εξετάσουμε μια απλή επιλογή όταν χρησιμοποιείται κεντρική δρομολόγηση - δηλαδή, η κυκλοφορία δρομολογείται μέσω ειδικών αποκλειστικών κόμβων δικτύου (καλά, κατά κανόνα, συνδυάζονται με κόμβους ελέγχου, οπότε θα έχουμε το ίδιο πράγμα).
Δεν φαίνεται τίποτα περίπλοκο - φτιάχνουμε μια διεπαφή γέφυρας στον κόμβο ελέγχου, οδηγούμε την κυκλοφορία σε αυτόν και από εκεί τη δρομολογούμε όπου τη χρειαζόμαστε. Αλλά το πρόβλημα είναι ότι ο πελάτης RED θέλει να χρησιμοποιήσει το δίκτυο 10.0.0.0/24 και ο πελάτης GREEN θέλει να χρησιμοποιήσει το δίκτυο 10.0.0.0/24. Δηλαδή, αρχίζουμε να τέμνουμε χώρους διευθύνσεων. Επιπλέον, οι πελάτες δεν θέλουν οι άλλοι πελάτες να μπορούν να δρομολογούνται στα εσωτερικά τους δίκτυα, κάτι που είναι λογικό. Για να διαχωρίσουμε τα δίκτυα και την κίνηση δεδομένων πελατών, θα διαθέσουμε έναν ξεχωριστό χώρο ονομάτων για καθένα από αυτά. Ο χώρος ονομάτων είναι στην πραγματικότητα ένα αντίγραφο της στοίβας δικτύου Linux, δηλαδή, οι πελάτες στο χώρο ονομάτων RED είναι εντελώς απομονωμένοι από πελάτες από το χώρο ονομάτων GREEN (καλά, είτε η δρομολόγηση μεταξύ αυτών των δικτύων πελατών επιτρέπεται μέσω του προεπιλεγμένου χώρου ονομάτων είτε στον εξοπλισμό μεταφοράς ανάντη).
Δηλαδή, παίρνουμε το ακόλουθο διάγραμμα:
Οι σήραγγες L2 συγκλίνουν από όλους τους κόμβους υπολογιστών στον κόμβο ελέγχου. κόμβος όπου βρίσκεται η διεπαφή L3 για αυτά τα δίκτυα, το καθένα σε έναν ειδικό χώρο ονομάτων για απομόνωση.
Ωστόσο, ξεχάσαμε το πιο σημαντικό. Η εικονική μηχανή πρέπει να παρέχει μια υπηρεσία στον πελάτη, δηλαδή να έχει τουλάχιστον μία εξωτερική διεπαφή μέσω της οποίας μπορεί να προσεγγιστεί. Δηλαδή, πρέπει να βγούμε στον έξω κόσμο. Υπάρχουν διάφορες επιλογές εδώ. Ας κάνουμε την πιο απλή επιλογή. Θα προσθέσουμε ένα δίκτυο σε κάθε πελάτη, το οποίο θα ισχύει στο δίκτυο του παρόχου και δεν θα επικαλύπτεται με άλλα δίκτυα. Τα δίκτυα μπορούν επίσης να τέμνονται και να κοιτάζουν διαφορετικά VRF στο πλάι του δικτύου παρόχου. Τα δεδομένα δικτύου θα βρίσκονται επίσης στον χώρο ονομάτων κάθε πελάτη. Ωστόσο, θα εξακολουθούν να βγαίνουν στον έξω κόσμο μέσω μιας φυσικής (ή δεσμού, που είναι πιο λογικό) διεπαφής. Για να διαχωρίσετε την επισκεψιμότητα των πελατών, η κίνηση που πηγαίνει έξω θα επισημαίνεται με μια ετικέτα VLAN που εκχωρείται στον πελάτη.
Ως αποτέλεσμα, πήραμε αυτό το διάγραμμα:
Ένα εύλογο ερώτημα είναι γιατί να μην δημιουργήσουμε πύλες στους ίδιους τους κόμβους υπολογισμού; Αυτό δεν είναι μεγάλο πρόβλημα· επιπλέον, εάν ενεργοποιήσετε τον κατανεμημένο δρομολογητή (DVR), αυτό θα λειτουργήσει. Σε αυτό το σενάριο, εξετάζουμε την απλούστερη επιλογή με μια κεντρική πύλη, η οποία χρησιμοποιείται από προεπιλογή στο Openstack. Για λειτουργίες υψηλού φορτίου, θα χρησιμοποιούν τόσο κατανεμημένο δρομολογητή όσο και τεχνολογίες επιτάχυνσης όπως το SR-IOV και το Passthrough, αλλά όπως λένε, αυτή είναι μια εντελώς διαφορετική ιστορία. Αρχικά, ας ασχοληθούμε με το βασικό μέρος και μετά θα μπούμε στις λεπτομέρειες.
Στην πραγματικότητα, το πρόγραμμά μας είναι ήδη εφαρμόσιμο, αλλά υπάρχουν μερικές αποχρώσεις:
- Πρέπει να προστατεύσουμε με κάποιο τρόπο τα μηχανήματα μας, δηλαδή να βάλουμε ένα φίλτρο στη διεπαφή διακόπτη προς τον πελάτη.
- Δώστε τη δυνατότητα σε μια εικονική μηχανή να αποκτά αυτόματα μια διεύθυνση IP, έτσι ώστε να μην χρειάζεται να συνδέεστε σε αυτήν μέσω της κονσόλας κάθε φορά και να καταχωρείτε τη διεύθυνση.
Ας ξεκινήσουμε με την προστασία του μηχανήματος. Για αυτό μπορείτε να χρησιμοποιήσετε banal iptables, γιατί όχι.
Δηλαδή, τώρα η τοπολογία μας έχει γίνει λίγο πιο περίπλοκη:
Ας προχωρήσουμε. Πρέπει να προσθέσουμε έναν διακομιστή DHCP. Το πιο ιδανικό μέρος για να εντοπίσετε διακομιστές DHCP για κάθε πελάτη θα ήταν ο κόμβος ελέγχου που αναφέρθηκε ήδη παραπάνω, όπου βρίσκονται οι χώροι ονομάτων:
Ωστόσο, υπάρχει ένα μικρό πρόβλημα. Τι θα συμβεί αν όλα επανεκκινηθούν και όλες οι πληροφορίες σχετικά με την ενοικίαση διευθύνσεων στο DHCP εξαφανιστούν. Είναι λογικό να δίνονται νέες διευθύνσεις στα μηχανήματα, κάτι που δεν είναι πολύ βολικό. Υπάρχουν δύο τρόποι εξόδου εδώ - είτε χρησιμοποιήστε ονόματα τομέα και προσθέστε έναν διακομιστή DNS για κάθε πελάτη, τότε η διεύθυνση δεν θα είναι ιδιαίτερα σημαντική για εμάς (παρόμοια με το τμήμα δικτύου στο k8s) - αλλά υπάρχει πρόβλημα με τα εξωτερικά δίκτυα, καθώς Οι διευθύνσεις μπορούν επίσης να εκδοθούν σε αυτές μέσω DHCP - χρειάζεστε συγχρονισμό με διακομιστές DNS στην πλατφόρμα cloud και έναν εξωτερικό διακομιστή DNS, που κατά τη γνώμη μου δεν είναι πολύ ευέλικτο, αλλά είναι αρκετά δυνατό. Ή η δεύτερη επιλογή είναι να χρησιμοποιήσετε μεταδεδομένα - δηλαδή να αποθηκεύσετε πληροφορίες σχετικά με τη διεύθυνση που έχει εκδοθεί στο μηχάνημα, έτσι ώστε ο διακομιστής DHCP να γνωρίζει ποια διεύθυνση θα εκδώσει στο μηχάνημα, εάν το μηχάνημα έχει ήδη λάβει μια διεύθυνση. Η δεύτερη επιλογή είναι απλούστερη και πιο ευέλικτη, καθώς σας επιτρέπει να αποθηκεύσετε πρόσθετες πληροφορίες για το αυτοκίνητο. Τώρα ας προσθέσουμε μεταδεδομένα πράκτορα στο διάγραμμα:
Ένα άλλο θέμα που αξίζει επίσης να συζητηθεί είναι η δυνατότητα χρήσης ενός εξωτερικού δικτύου από όλους τους πελάτες, καθώς τα εξωτερικά δίκτυα, εάν πρέπει να ισχύουν σε ολόκληρο το δίκτυο, θα είναι δύσκολο - πρέπει να εκχωρείτε και να ελέγχετε συνεχώς την κατανομή αυτών των δικτύων. Η δυνατότητα χρήσης ενός ενιαίου εξωτερικού προρυθμισμένου δικτύου για όλους τους πελάτες θα είναι πολύ χρήσιμη κατά τη δημιουργία ενός δημόσιου νέφους. Αυτό θα διευκολύνει την ανάπτυξη μηχανημάτων, επειδή δεν χρειάζεται να συμβουλευόμαστε μια βάση δεδομένων διευθύνσεων και να επιλέξουμε έναν μοναδικό χώρο διευθύνσεων για το εξωτερικό δίκτυο κάθε πελάτη. Επιπλέον, μπορούμε να καταχωρήσουμε ένα εξωτερικό δίκτυο εκ των προτέρων και κατά τη στιγμή της ανάπτυξης θα χρειαστεί μόνο να συσχετίσουμε εξωτερικές διευθύνσεις με μηχανήματα πελατών.
Και εδώ το NAT μας βοηθάει - απλώς θα καταστήσουμε δυνατή στους πελάτες την πρόσβαση στον έξω κόσμο μέσω του προεπιλεγμένου χώρου ονομάτων χρησιμοποιώντας μετάφραση NAT. Λοιπόν, εδώ είναι ένα μικρό πρόβλημα. Αυτό είναι καλό εάν ο διακομιστής πελάτη λειτουργεί ως πελάτης και όχι ως διακομιστής - δηλαδή, εκκινεί αντί να δέχεται συνδέσεις. Αλλά για εμάς θα είναι το αντίστροφο. Σε αυτήν την περίπτωση, πρέπει να κάνουμε NAT προορισμού έτσι ώστε κατά τη λήψη της κυκλοφορίας, ο κόμβος ελέγχου να κατανοεί ότι αυτή η κίνηση προορίζεται για την εικονική μηχανή Α του πελάτη Α, πράγμα που σημαίνει ότι πρέπει να κάνουμε μετάφραση NAT από μια εξωτερική διεύθυνση, για παράδειγμα 100.1.1.1 .10.0.0.1, σε μια εσωτερική διεύθυνση 100. Σε αυτήν την περίπτωση, αν και όλοι οι πελάτες θα χρησιμοποιούν το ίδιο δίκτυο, η εσωτερική απομόνωση διατηρείται πλήρως. Δηλαδή, πρέπει να κάνουμε dNAT και sNAT στον κόμβο ελέγχου. Το εάν θα χρησιμοποιήσετε ένα μεμονωμένο δίκτυο με κινούμενες διευθύνσεις ή εξωτερικά δίκτυα, ή και τα δύο ταυτόχρονα, εξαρτάται από το τι θέλετε να φέρετε στο cloud. Δεν θα προσθέσουμε κινούμενες διευθύνσεις στο διάγραμμα, αλλά θα αφήσουμε τα εξωτερικά δίκτυα που έχουν ήδη προστεθεί νωρίτερα - κάθε πελάτης έχει το δικό του εξωτερικό δίκτυο (στο διάγραμμα υποδεικνύονται ως vlan 200 και XNUMX στην εξωτερική διεπαφή).
Ως αποτέλεσμα, λάβαμε μια ενδιαφέρουσα και ταυτόχρονα καλά μελετημένη λύση, η οποία έχει κάποια ευελιξία αλλά δεν διαθέτει ακόμη μηχανισμούς ανοχής σφαλμάτων.
Πρώτον, έχουμε μόνο έναν κόμβο ελέγχου - η αποτυχία του θα οδηγήσει στην κατάρρευση όλων των συστημάτων. Για να διορθώσετε αυτό το πρόβλημα, πρέπει να δημιουργήσετε απαρτία τουλάχιστον 3 κόμβων. Ας προσθέσουμε αυτό στο διάγραμμα:
Φυσικά, όλοι οι κόμβοι συγχρονίζονται και όταν ένας ενεργός κόμβος αποχωρεί, ένας άλλος κόμβος θα αναλάβει τις ευθύνες του.
Το επόμενο πρόβλημα είναι οι δίσκοι εικονικής μηχανής. Προς το παρόν, αποθηκεύονται στους ίδιους τους hypervisor και σε περίπτωση προβλημάτων με τον hypervisor, χάνουμε όλα τα δεδομένα - και η παρουσία μιας επιδρομής δεν θα βοηθήσει εδώ εάν χάσουμε όχι τον δίσκο, αλλά ολόκληρο τον διακομιστή. Για να γίνει αυτό, πρέπει να δημιουργήσουμε μια υπηρεσία που θα λειτουργεί ως το μπροστινό μέρος για κάποιο είδος αποθήκευσης. Τι είδους αποθήκευση θα είναι δεν είναι ιδιαίτερα σημαντικό για εμάς, αλλά θα πρέπει να προστατεύει τα δεδομένα μας από αστοχία τόσο του δίσκου όσο και του κόμβου, και πιθανώς ολόκληρου του ντουλαπιού. Υπάρχουν πολλές επιλογές εδώ - υπάρχουν, φυσικά, δίκτυα SAN με Fiber Channel, αλλά ας είμαστε ειλικρινείς - το FC είναι ήδη ένα λείψανο του παρελθόντος - ένα ανάλογο του E1 στις μεταφορές - ναι, συμφωνώ, εξακολουθεί να χρησιμοποιείται, αλλά μόνο όπου είναι απολύτως αδύνατο χωρίς αυτό. Ως εκ τούτου, δεν θα αναπτύξω οικειοθελώς ένα δίκτυο FC το 2020, γνωρίζοντας ότι υπάρχουν άλλες πιο ενδιαφέρουσες εναλλακτικές λύσεις. Αν και για τον καθένα το δικό του, μπορεί να υπάρχουν εκείνοι που πιστεύουν ότι το FC με όλους τους περιορισμούς του είναι το μόνο που χρειαζόμαστε - δεν θα διαφωνήσω, ο καθένας έχει τη δική του γνώμη. Ωστόσο, η πιο ενδιαφέρουσα λύση κατά τη γνώμη μου είναι να χρησιμοποιήσετε ένα SDS, όπως ο Ceph.
Το Ceph σάς επιτρέπει να δημιουργήσετε μια εξαιρετικά διαθέσιμη λύση αποθήκευσης δεδομένων με μια δέσμη πιθανών εφεδρικών επιλογών, ξεκινώντας με κωδικούς με έλεγχο ισοτιμίας (ανάλογα με το raid 5 ή 6) και τελειώνοντας με πλήρη αναπαραγωγή δεδομένων σε διαφορετικούς δίσκους, λαμβάνοντας υπόψη τη θέση των δίσκων στο διακομιστές και διακομιστές σε ντουλάπια κ.λπ.
Για να δημιουργήσετε το Ceph χρειάζεστε 3 ακόμα κόμβους. Η αλληλεπίδραση με το χώρο αποθήκευσης θα πραγματοποιείται επίσης μέσω του δικτύου χρησιμοποιώντας υπηρεσίες αποθήκευσης μπλοκ, αντικειμένων και αρχείων. Ας προσθέσουμε χώρο αποθήκευσης στο σχήμα:
Σημείωση: μπορείτε επίσης να δημιουργήσετε υπερσυγκλινόμενους κόμβους υπολογισμού - αυτή είναι η έννοια του συνδυασμού πολλών συναρτήσεων σε έναν κόμβο - για παράδειγμα, αποθήκευση+υπολογισμός - χωρίς να αφιερώνετε ειδικούς κόμβους για αποθήκευση ceph. Θα λάβουμε το ίδιο σύστημα ανοχής σε σφάλματα - αφού το SDS θα δεσμεύσει δεδομένα με το επίπεδο κράτησης που καθορίζουμε. Ωστόσο, οι υπερσυγκλίνοντες κόμβοι είναι πάντα ένας συμβιβασμός - καθώς ο κόμβος αποθήκευσης δεν θερμαίνει απλώς τον αέρα όπως φαίνεται με την πρώτη ματιά (καθώς δεν υπάρχουν εικονικές μηχανές σε αυτόν) - ξοδεύει πόρους της CPU για την εξυπηρέτηση του SDS (στην πραγματικότητα, τα κάνει όλα η αναπαραγωγή και η ανάκτηση μετά από αστοχίες κόμβων, δίσκων κ.λπ.). Δηλαδή, θα χάσετε μέρος της ισχύος του κόμβου υπολογισμού εάν τον συνδυάσετε με αποθήκευση.
Όλα αυτά τα πράγματα πρέπει να τα διαχειριστούμε με κάποιο τρόπο - χρειαζόμαστε κάτι μέσω του οποίου μπορούμε να δημιουργήσουμε ένα μηχάνημα, ένα δίκτυο, έναν εικονικό δρομολογητή κ.λπ. Για να γίνει αυτό, θα προσθέσουμε μια υπηρεσία στον κόμβο ελέγχου που θα λειτουργεί ως πίνακας εργαλείων - το Ο πελάτης θα μπορεί να συνδεθεί σε αυτήν την πύλη μέσω http/ https και να κάνει ό,τι χρειάζεται (καλά, σχεδόν).
Ως αποτέλεσμα, έχουμε πλέον ένα σύστημα ανοχής σε σφάλματα. Όλα τα στοιχεία αυτής της υποδομής πρέπει να διαχειρίζονται με κάποιο τρόπο. Έχει περιγραφεί προηγουμένως ότι το Openstack είναι ένα σύνολο έργων, καθένα από τα οποία παρέχει μια συγκεκριμένη λειτουργία. Όπως βλέπουμε, υπάρχουν περισσότερα από αρκετά στοιχεία που πρέπει να ρυθμιστούν και να ελεγχθούν. Σήμερα θα μιλήσουμε για το κομμάτι του δικτύου.
Αρχιτεκτονική νετρονίων
Στο OpenStack, η Neutron είναι αυτή που είναι υπεύθυνη για τη σύνδεση των θυρών εικονικής μηχανής σε ένα κοινό δίκτυο L2, διασφαλίζοντας τη δρομολόγηση της κυκλοφορίας μεταξύ VM που βρίσκονται σε διαφορετικά δίκτυα L2, καθώς και τη δρομολόγηση προς τα έξω, παρέχοντας υπηρεσίες όπως NAT, Floating IP, DHCP κ.λπ.
Σε υψηλό επίπεδο, η λειτουργία της υπηρεσίας δικτύου (το βασικό μέρος) μπορεί να περιγραφεί ως εξής.
Κατά την εκκίνηση του VM, η υπηρεσία δικτύου:
- Δημιουργεί μια θύρα για ένα δεδομένο VM (ή θύρες) και ειδοποιεί την υπηρεσία DHCP σχετικά.
- Δημιουργείται μια νέα εικονική συσκευή δικτύου (μέσω libvirt).
- Το VM συνδέεται με τις θύρες που δημιουργήθηκαν στο βήμα 1.
Παραδόξως, το έργο του Neutron βασίζεται σε τυπικούς μηχανισμούς που είναι γνωστοί σε όλους όσους έχουν βουτήξει ποτέ στο Linux - χώρους ονομάτων, iptables, γέφυρες Linux, openvswitch, conntrack κ.λπ.
Θα πρέπει να διευκρινιστεί αμέσως ότι το Neutron δεν είναι ελεγκτής SDN.
Το νετρόνιο αποτελείται από πολλά διασυνδεδεμένα συστατικά:
Openstack-neutron-server είναι ένας δαίμονας που λειτουργεί με αιτήματα χρηστών μέσω του API. Αυτός ο δαίμονας δεν συμμετέχει στην καταχώρηση οποιωνδήποτε συνδέσεων δικτύου, αλλά παρέχει τις απαραίτητες πληροφορίες για αυτό στα πρόσθετά του, τα οποία στη συνέχεια διαμορφώνουν το επιθυμητό στοιχείο δικτύου. Οι πράκτορες νετρονίων στους κόμβους OpenStack εγγράφονται στον διακομιστή Neutron.
Ο διακομιστής νετρονίων είναι στην πραγματικότητα μια εφαρμογή γραμμένη σε python, που αποτελείται από δύο μέρη:
- Υπηρεσία REST
- Πρόσθετο Neutron (πυρήνας/υπηρεσία)
Η υπηρεσία REST έχει σχεδιαστεί για να λαμβάνει κλήσεις API από άλλα στοιχεία (για παράδειγμα, αίτημα παροχής ορισμένων πληροφοριών κ.λπ.)
Οι προσθήκες είναι πρόσθετα στοιχεία λογισμικού/ενότητες που καλούνται κατά τη διάρκεια αιτημάτων API - δηλαδή, η απόδοση μιας υπηρεσίας πραγματοποιείται μέσω αυτών. Τα πρόσθετα χωρίζονται σε δύο τύπους - υπηρεσία και root. Κατά κανόνα, η προσθήκη ίππου είναι κυρίως υπεύθυνη για τη διαχείριση του χώρου διευθύνσεων και των συνδέσεων L2 μεταξύ των εικονικών μηχανών, και τα πρόσθετα υπηρεσιών παρέχουν ήδη πρόσθετες λειτουργίες, όπως VPN ή FW.
Για παράδειγμα, μπορείτε να δείτε τη λίστα με τα πρόσθετα που είναι διαθέσιμα σήμερα
Μπορεί να υπάρχουν πολλά πρόσθετα υπηρεσιών, αλλά μπορεί να υπάρχει μόνο ένα πρόσθετο ίππου.
openstack-neutron-ml2 είναι η τυπική ρίζα του Openstack. Αυτό το πρόσθετο έχει αρθρωτή αρχιτεκτονική (σε αντίθεση με τον προκάτοχό του) και διαμορφώνει την υπηρεσία δικτύου μέσω προγραμμάτων οδήγησης που είναι συνδεδεμένα σε αυτό. Το ίδιο το πρόσθετο θα το δούμε λίγο αργότερα, αφού στην πραγματικότητα δίνει την ευελιξία που έχει το OpenStack στο κομμάτι του δικτύου. Το root plugin μπορεί να αντικατασταθεί (για παράδειγμα, το Contrail Networking κάνει μια τέτοια αντικατάσταση).
Υπηρεσία RPC (rabbitmq-server) — μια υπηρεσία που παρέχει διαχείριση ουράς και αλληλεπίδραση με άλλες υπηρεσίες OpenStack, καθώς και αλληλεπίδραση μεταξύ πρακτόρων υπηρεσιών δικτύου.
Πράκτορες δικτύου — πράκτορες που βρίσκονται σε κάθε κόμβο, μέσω των οποίων διαμορφώνονται οι υπηρεσίες δικτύου.
Υπάρχουν διάφοροι τύποι πρακτόρων.
Ο κύριος πράκτορας είναι Πράκτορας L2. Αυτοί οι πράκτορες εκτελούνται σε καθέναν από τους hypervisors, συμπεριλαμβανομένων των κόμβων ελέγχου (ακριβέστερα, σε όλους τους κόμβους που παρέχουν οποιαδήποτε υπηρεσία στους ενοικιαστές) και η κύρια λειτουργία τους είναι να συνδέουν εικονικές μηχανές σε ένα κοινό δίκτυο L2 και επίσης να δημιουργούν ειδοποιήσεις όταν συμβαίνουν γεγονότα ( για παράδειγμα απενεργοποιήστε/ενεργοποιήστε τη θύρα).
Ο επόμενος, όχι λιγότερο σημαντικός πράκτορας είναι Πράκτορας L3. Από προεπιλογή, αυτός ο πράκτορας εκτελείται αποκλειστικά σε έναν κόμβο δικτύου (συχνά ο κόμβος δικτύου συνδυάζεται με έναν κόμβο ελέγχου) και παρέχει δρομολόγηση μεταξύ δικτύων μισθωτών (τόσο μεταξύ των δικτύων του όσο και των δικτύων άλλων ενοικιαστών και είναι προσβάσιμος στον έξω κόσμο, παρέχοντας NAT, καθώς και υπηρεσία DHCP). Ωστόσο, όταν χρησιμοποιείτε ένα DVR (κατανεμημένο δρομολογητή), η ανάγκη για ένα πρόσθετο L3 εμφανίζεται επίσης στους κόμβους υπολογιστών.
Ο πράκτορας L3 χρησιμοποιεί χώρους ονομάτων Linux για να παρέχει σε κάθε μισθωτή ένα σύνολο δικών του απομονωμένων δικτύων και τη λειτουργικότητα εικονικών δρομολογητών που δρομολογούν την κίνηση και παρέχουν υπηρεσίες πύλης για δίκτυα επιπέδου 2.
βάση δεδομένων — μια βάση δεδομένων με αναγνωριστικά δικτύων, υποδικτύων, θυρών, πισινών κ.λπ.
Στην πραγματικότητα, το Neutron δέχεται αιτήματα API από τη δημιουργία οποιωνδήποτε οντοτήτων δικτύου, επαληθεύει την ταυτότητα του αιτήματος και μέσω RPC (αν έχει πρόσβαση σε κάποιο πρόσθετο ή πράκτορα) ή REST API (εάν επικοινωνεί σε SDN) μεταδίδει στους πράκτορες (μέσω πρόσθετων) οδηγίες που είναι απαραίτητες για την οργάνωση της ζητούμενης υπηρεσίας.
Τώρα ας στραφούμε στη δοκιμαστική εγκατάσταση (πώς αναπτύσσεται και τι περιλαμβάνεται σε αυτήν, θα δούμε αργότερα στο πρακτικό μέρος) και θα δούμε πού βρίσκεται κάθε στοιχείο:
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$
Στην πραγματικότητα, αυτή είναι η όλη δομή του Νετρονίου. Τώρα αξίζει να αφιερώσετε λίγο χρόνο στην προσθήκη ML2.
Αρθρωτό στρώμα 2
Όπως αναφέρθηκε παραπάνω, το πρόσθετο είναι ένα τυπικό ριζικό πρόσθετο OpenStack και έχει αρθρωτή αρχιτεκτονική.
Ο προκάτοχος της προσθήκης ML2 είχε μια μονολιθική δομή, η οποία δεν επέτρεπε, για παράδειγμα, τη χρήση συνδυασμού πολλών τεχνολογιών σε μία εγκατάσταση. Για παράδειγμα, δεν θα μπορούσατε να χρησιμοποιήσετε ταυτόχρονα το openvswitch και το linuxbridge - είτε το πρώτο είτε το δεύτερο. Για το λόγο αυτό δημιουργήθηκε το πρόσθετο ML2 με την αρχιτεκτονική του.
Το ML2 έχει δύο στοιχεία - δύο τύπους προγραμμάτων οδήγησης: προγράμματα οδήγησης τύπου και προγράμματα οδήγησης μηχανισμού.
Πληκτρολογήστε προγράμματα οδήγησης καθορίστε τις τεχνολογίες που θα χρησιμοποιηθούν για την οργάνωση των συνδέσεων δικτύου, για παράδειγμα VxLAN, VLAN, GRE. Ταυτόχρονα, ο οδηγός επιτρέπει τη χρήση διαφορετικών τεχνολογιών. Η τυπική τεχνολογία είναι η ενθυλάκωση VxLAN για δίκτυα επικάλυψης και εξωτερικά δίκτυα vlan.
Τα προγράμματα οδήγησης τύπου περιλαμβάνουν τους ακόλουθους τύπους δικτύου:
Διαμέρισμα - δίκτυο χωρίς σήμανση
VLAN - δίκτυο με ετικέτα
τοπικός — ειδικός τύπος δικτύου για εγκαταστάσεις all-in-one (τέτοιες εγκαταστάσεις χρειάζονται είτε για προγραμματιστές είτε για εκπαίδευση)
GRE — δίκτυο επικάλυψης που χρησιμοποιεί σήραγγες GRE
VxLAN — επικάλυψη δικτύου χρησιμοποιώντας σήραγγες VxLAN
Οδηγοί μηχανισμών ορίστε εργαλεία που διασφαλίζουν την οργάνωση των τεχνολογιών που καθορίζονται στο πρόγραμμα οδήγησης τύπου - για παράδειγμα, openvswitch, sr-iov, opendaylight, OVN κ.λπ.
Ανάλογα με την υλοποίηση αυτού του προγράμματος οδήγησης, είτε θα χρησιμοποιηθούν πράκτορες που ελέγχονται από το Neutron είτε θα χρησιμοποιηθούν συνδέσεις με έναν εξωτερικό ελεγκτή SDN, ο οποίος φροντίζει για όλα τα θέματα που σχετίζονται με την οργάνωση δικτύων L2, τη δρομολόγηση κ.λπ.
Παράδειγμα: αν χρησιμοποιήσουμε το ML2 μαζί με το OVS, τότε εγκαθίσταται ένας πράκτορας L2 σε κάθε κόμβο υπολογιστών που διαχειρίζεται το OVS. Ωστόσο, αν χρησιμοποιήσουμε, για παράδειγμα, OVN ή OpenDayLight, τότε ο έλεγχος του OVS περιέρχεται στη δικαιοδοσία τους - το Neutron, μέσω του root plugin, δίνει εντολές στον ελεγκτή και κάνει ήδη αυτό που του είπαν.
Ας ξεκινήσουμε το Open vSwitch
Προς το παρόν, ένα από τα βασικά στοιχεία του OpenStack είναι το Open vSwitch.
Όταν εγκαθιστάτε το OpenStack χωρίς πρόσθετο SDN προμηθευτή, όπως το Juniper Contrail ή το Nokia Nuage, το OVS είναι το κύριο στοιχείο δικτύου του δικτύου cloud και, μαζί με τα iptables, το conntrack, τους χώρους ονομάτων, σας επιτρέπει να οργανώνετε πλήρη δίκτυα επικάλυψης πολλαπλών ενοικίων. Φυσικά, αυτό το στοιχείο μπορεί να αντικατασταθεί, για παράδειγμα, όταν χρησιμοποιείτε λύσεις SDN ιδιόκτητων (προμηθευτών) τρίτων.
Το OVS είναι ένας διακόπτης λογισμικού ανοιχτού κώδικα που έχει σχεδιαστεί για χρήση σε εικονικά περιβάλλοντα ως εικονικός προωθητής κίνησης.
Αυτή τη στιγμή, το OVS έχει πολύ αξιοπρεπή λειτουργικότητα, η οποία περιλαμβάνει τεχνολογίες όπως QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK κ.λπ.
Σημείωση: Το OVS δεν σχεδιάστηκε αρχικά ως soft switch για λειτουργίες τηλεπικοινωνιών με υψηλή φόρτωση και σχεδιάστηκε περισσότερο για λειτουργίες πληροφορικής που απαιτούν λιγότερο εύρος ζώνης, όπως ο διακομιστής WEB ή ο διακομιστής αλληλογραφίας. Ωστόσο, το OVS αναπτύσσεται περαιτέρω και οι τρέχουσες υλοποιήσεις του OVS έχουν βελτιώσει σημαντικά την απόδοση και τις δυνατότητές του, γεγονός που επιτρέπει τη χρήση του από τηλεπικοινωνιακούς φορείς με λειτουργίες υψηλής φόρτωσης, για παράδειγμα, υπάρχει μια υλοποίηση OVS με υποστήριξη για επιτάχυνση DPDK.
Υπάρχουν τρία σημαντικά στοιχεία του OVS που πρέπει να γνωρίζετε:
- Μονάδα πυρήνα — ένα στοιχείο που βρίσκεται στο χώρο του πυρήνα που επεξεργάζεται την κυκλοφορία με βάση τους κανόνες που λαμβάνονται από το στοιχείο ελέγχου·
- vSwitch Ο δαίμονας (ovs-vswitchd) είναι μια διαδικασία που εκκινείται στο χώρο του χρήστη και είναι υπεύθυνη για τον προγραμματισμό της μονάδας πυρήνα - δηλαδή, αντιπροσωπεύει άμεσα τη λογική της λειτουργίας του διακόπτη
- Διακομιστής βάσης δεδομένων - μια τοπική βάση δεδομένων που βρίσκεται σε κάθε κεντρικό υπολογιστή που εκτελεί OVS, στον οποίο είναι αποθηκευμένη η διαμόρφωση. Οι ελεγκτές SDN μπορούν να επικοινωνούν μέσω αυτής της μονάδας χρησιμοποιώντας το πρωτόκολλο OVSDB.
Όλα αυτά συνοδεύονται από ένα σύνολο βοηθητικών προγραμμάτων διάγνωσης και διαχείρισης, όπως ovs-vsctl, ovs-appctl, ovs-ofctl κ.λπ.
Επί του παρόντος, το Openstack χρησιμοποιείται ευρέως από τηλεπικοινωνιακούς φορείς για τη μετεγκατάσταση λειτουργιών δικτύου σε αυτό, όπως EPC, SBC, HLR, κ.λπ. ένας τεράστιος όγκος κίνησης (τώρα ο όγκος της κυκλοφορίας φτάνει αρκετές εκατοντάδες gigabit ανά δευτερόλεπτο). Φυσικά, η οδήγηση μιας τέτοιας κίνησης μέσω του χώρου του πυρήνα (καθώς ο προωθητής βρίσκεται εκεί από προεπιλογή) δεν είναι η καλύτερη ιδέα. Ως εκ τούτου, το OVS συχνά αναπτύσσεται εξ ολοκλήρου στο χώρο του χρήστη χρησιμοποιώντας την τεχνολογία επιτάχυνσης DPDK για την προώθηση της κυκλοφορίας από το NIC στον χώρο χρήστη παρακάμπτοντας τον πυρήνα.
Σημείωση: για ένα σύννεφο που έχει αναπτυχθεί για τηλεπικοινωνιακές λειτουργίες, είναι δυνατή η έξοδος κίνησης από έναν υπολογιστικό κόμβο παρακάμπτοντας το OVS απευθείας στον εξοπλισμό μεταγωγής. Για το σκοπό αυτό χρησιμοποιούνται μηχανισμοί SR-IOV και Passthrough.
Πώς λειτουργεί αυτό σε μια πραγματική διάταξη;
Λοιπόν, τώρα ας περάσουμε στο πρακτικό μέρος και ας δούμε πώς λειτουργούν όλα στην πράξη.
Αρχικά, ας αναπτύξουμε μια απλή εγκατάσταση Openstack. Δεδομένου ότι δεν έχω διαθέσιμο σύνολο διακομιστών για πειράματα, θα συναρμολογήσουμε το πρωτότυπο σε έναν φυσικό διακομιστή από εικονικές μηχανές. Ναι, φυσικά, μια τέτοια λύση δεν είναι κατάλληλη για εμπορικούς σκοπούς, αλλά για να δείτε ένα παράδειγμα για το πώς λειτουργεί το δίκτυο στο Openstack, μια τέτοια εγκατάσταση είναι αρκετή για τα μάτια. Επιπλέον, μια τέτοια εγκατάσταση είναι ακόμη πιο ενδιαφέρουσα για εκπαιδευτικούς σκοπούς - αφού μπορείτε να πιάσετε κίνηση κ.λπ.
Δεδομένου ότι χρειάζεται να δούμε μόνο το βασικό μέρος, δεν μπορούμε να χρησιμοποιήσουμε πολλά δίκτυα αλλά να αυξήσουμε τα πάντα χρησιμοποιώντας μόνο δύο δίκτυα και το δεύτερο δίκτυο σε αυτήν τη διάταξη θα χρησιμοποιηθεί αποκλειστικά για πρόσβαση στο διακομιστή undercloud και DNS. Δεν θα αγγίξουμε τα εξωτερικά δίκτυα προς το παρόν - αυτό είναι ένα θέμα για ένα ξεχωριστό μεγάλο άρθρο.
Λοιπόν, ας ξεκινήσουμε με τη σειρά. Πρώτον, μια μικρή θεωρία. Θα εγκαταστήσουμε το Openstack χρησιμοποιώντας το TripleO (Openstack on Openstack). Η ουσία του TripleO είναι ότι εγκαθιστούμε το Openstack all-in-one (δηλαδή σε έναν κόμβο), που ονομάζεται undercloud, και στη συνέχεια χρησιμοποιούμε τις δυνατότητες του αναπτυγμένου Openstack για να εγκαταστήσουμε το Openstack που προορίζεται για λειτουργία, που ονομάζεται overcloud. Το Undercloud θα χρησιμοποιήσει την εγγενή του ικανότητα να διαχειρίζεται φυσικούς διακομιστές (γυμνό μέταλλο) - το έργο Ironic - για να παρέχει υπερεπόπτες που θα εκτελούν τους ρόλους κόμβων υπολογισμού, ελέγχου και αποθήκευσης. Δηλαδή, δεν χρησιμοποιούμε εργαλεία τρίτων για την ανάπτυξη του Openstack - αναπτύσσουμε το Openstack χρησιμοποιώντας το Openstack. Θα γίνει πολύ πιο ξεκάθαρο όσο προχωρά η εγκατάσταση, επομένως δεν θα σταματήσουμε εκεί και θα προχωρήσουμε.
Σημείωση: Σε αυτό το άρθρο, για λόγους απλότητας, δεν χρησιμοποίησα απομόνωση δικτύου για εσωτερικά δίκτυα Openstack, αλλά όλα αναπτύσσονται χρησιμοποιώντας μόνο ένα δίκτυο. Ωστόσο, η παρουσία ή η απουσία απομόνωσης δικτύου δεν επηρεάζει τη βασική λειτουργικότητα της λύσης - όλα θα λειτουργούν ακριβώς όπως όταν χρησιμοποιείτε την απομόνωση, αλλά η κυκλοφορία θα ρέει στο ίδιο δίκτυο. Για μια εμπορική εγκατάσταση, είναι φυσικά απαραίτητο να χρησιμοποιηθεί η απομόνωση χρησιμοποιώντας διαφορετικά vlans και διεπαφές. Για παράδειγμα, η κίνηση διαχείρισης αποθήκευσης ceph και η ίδια η κίνηση δεδομένων (πρόσβαση μηχανήματος σε δίσκους κ.λπ.) όταν είναι απομονωμένα χρησιμοποιούν διαφορετικά υποδίκτυα (Διαχείριση αποθήκευσης και αποθήκευση) και αυτό σας επιτρέπει να κάνετε τη λύση πιο ανεκτική σε σφάλματα διαιρώντας αυτήν την κίνηση, για παράδειγμα , σε διαφορετικές θύρες ή χρησιμοποιώντας διαφορετικά προφίλ QoS για διαφορετική κίνηση, έτσι ώστε η κυκλοφορία δεδομένων να μην αποκόπτει την κυκλοφορία σηματοδότησης. Στην περίπτωσή μας θα πάνε στο ίδιο δίκτυο και μάλιστα αυτό δεν μας περιορίζει σε καμία περίπτωση.
Σημείωση: Εφόσον πρόκειται να τρέξουμε εικονικές μηχανές σε εικονικό περιβάλλον που βασίζεται σε εικονικές μηχανές, πρέπει πρώτα να ενεργοποιήσουμε την ένθετη εικονικοποίηση.
Μπορείτε να ελέγξετε εάν η ένθετη εικονικοποίηση είναι ενεργοποιημένη ή όχι ως εξής:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Εάν βλέπετε το γράμμα N, τότε ενεργοποιούμε την υποστήριξη για ένθετη εικονικοποίηση σύμφωνα με οποιονδήποτε οδηγό που βρίσκετε στο δίκτυο, για παράδειγμα .
Πρέπει να συναρμολογήσουμε το ακόλουθο κύκλωμα από εικονικές μηχανές:
Στην περίπτωσή μου, για να συνδέσω τις εικονικές μηχανές που αποτελούν μέρος της μελλοντικής εγκατάστασης (και πήρα 7 από αυτές, αλλά μπορείτε να τα βγάλετε πέρα με 4 αν δεν έχετε πολλούς πόρους), χρησιμοποίησα το OpenvSwitch. Δημιούργησα ένα ovs bridge και σύνδεσα εικονικές μηχανές σε αυτό μέσω ομάδων θυρών. Για να γίνει αυτό, δημιούργησα ένα αρχείο xml όπως αυτό:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>Εδώ δηλώνονται τρεις ομάδες θυρών - δύο πρόσβαση και ένας κορμός (το τελευταίο χρειαζόταν για τον διακομιστή DNS, αλλά μπορείτε να το κάνετε χωρίς αυτό ή να το εγκαταστήσετε στον κεντρικό υπολογιστή - όποιο είναι πιο βολικό για εσάς). Στη συνέχεια, χρησιμοποιώντας αυτό το πρότυπο, δηλώνουμε το δικό μας μέσω virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Τώρα επεξεργαζόμαστε τις διαμορφώσεις της θύρας hypervisor:
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# Σημείωση: σε αυτό το σενάριο, η διεύθυνση στη θύρα ovs-br1 δεν θα είναι προσβάσιμη επειδή δεν έχει ετικέτα vlan. Για να το διορθώσετε αυτό, πρέπει να εκδώσετε την εντολή sudo ovs-vsctl set port ovs-br1 tag=100. Ωστόσο, μετά από μια επανεκκίνηση, αυτή η ετικέτα θα εξαφανιστεί (αν κάποιος ξέρει πώς να την κάνει να παραμείνει στη θέση της, θα είμαι πολύ ευγνώμων). Αλλά αυτό δεν είναι τόσο σημαντικό, γιατί θα χρειαστούμε μόνο αυτή τη διεύθυνση κατά την εγκατάσταση και δεν θα τη χρειαστούμε όταν το Openstack αναπτυχθεί πλήρως.
Στη συνέχεια, δημιουργούμε μια μηχανή undercloud:
virt-install -n undercloud --description "undercloud" --os-type=Linux --os-variant=centos7.0 --ram=8192 --vcpus=8 --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0Κατά την εγκατάσταση, ορίζετε όλες τις απαραίτητες παραμέτρους, όπως το όνομα του μηχανήματος, τους κωδικούς πρόσβασης, τους χρήστες, τους διακομιστές ntp κ.λπ., μπορείτε να ρυθμίσετε αμέσως τις θύρες, αλλά προσωπικά για μένα, μετά την εγκατάσταση, είναι πιο εύκολο να συνδεθείτε στο μηχάνημα μέσω την κονσόλα και διορθώστε τα απαραίτητα αρχεία. Εάν έχετε ήδη μια έτοιμη εικόνα, μπορείτε να τη χρησιμοποιήσετε ή να κάνετε ό,τι έκανα εγώ - κατεβάστε την ελάχιστη εικόνα Centos 7 και χρησιμοποιήστε την για να εγκαταστήσετε το VM.
Μετά την επιτυχή εγκατάσταση, θα πρέπει να έχετε μια εικονική μηχανή στην οποία μπορείτε να εγκαταστήσετε το undercloud
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningΑρχικά, εγκαταστήστε τα απαραίτητα εργαλεία για τη διαδικασία εγκατάστασης:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Εγκατάσταση undercloud
Δημιουργούμε έναν χρήστη στοίβας, ορίζουμε έναν κωδικό πρόσβασης, τον προσθέτουμε στο sudoer και του δίνουμε τη δυνατότητα να εκτελεί εντολές root μέσω του sudo χωρίς να χρειάζεται να εισάγει κωδικό πρόσβασης:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackΤώρα καθορίζουμε το πλήρες όνομα undercloud στο αρχείο hosts:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Στη συνέχεια, προσθέτουμε αποθετήρια και εγκαθιστούμε το λογισμικό που χρειαζόμαστε:
sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansibleΣημείωση: εάν δεν σκοπεύετε να εγκαταστήσετε το ceph, τότε δεν χρειάζεται να εισάγετε εντολές που σχετίζονται με το ceph. Χρησιμοποίησα την έκδοση του Queens, αλλά μπορείτε να χρησιμοποιήσετε όποια άλλη θέλετε.
Στη συνέχεια, αντιγράψτε το αρχείο διαμόρφωσης undercloud στη στοίβα οικιακού καταλόγου του χρήστη:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confΤώρα πρέπει να διορθώσουμε αυτό το αρχείο, προσαρμόζοντάς το στην εγκατάστασή μας.
Πρέπει να προσθέσετε αυτές τις γραμμές στην αρχή του αρχείου:
vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10Λοιπόν, ας περάσουμε από τις ρυθμίσεις:
undercloud_hostname — το πλήρες όνομα του διακομιστή undercloud, πρέπει να ταιριάζει με την καταχώρηση στον διακομιστή DNS
local_ip — τοπική διεύθυνση undercloud προς παροχή δικτύου
network_gateway — η ίδια τοπική διεύθυνση, η οποία θα λειτουργεί ως πύλη πρόσβασης στον έξω κόσμο κατά την εγκατάσταση κόμβων overcloud, συμπίπτει επίσης με την τοπική διεύθυνση IP
undercloud_public_host — εξωτερική διεύθυνση API, εκχωρείται οποιαδήποτε δωρεάν διεύθυνση από το δίκτυο παροχής
undercloud_admin_host εσωτερική διεύθυνση API, εκχωρείται οποιαδήποτε δωρεάν διεύθυνση από το δίκτυο παροχής
undercloud_nameservers - Διακομιστής DNS
Generate_service_certificate - αυτή η γραμμή είναι πολύ σημαντική στο τρέχον παράδειγμα, γιατί αν δεν την ορίσετε σε false, θα λάβετε ένα σφάλμα κατά την εγκατάσταση, το πρόβλημα περιγράφεται στον εντοπισμό σφαλμάτων Red Hat
τοπική_διασύνδεση διεπαφή στην παροχή δικτύου. Αυτή η διεπαφή θα διαμορφωθεί εκ νέου κατά την ανάπτυξη του undercloud, επομένως πρέπει να έχετε δύο διεπαφές στο undercloud - μία για πρόσβαση σε αυτό, η δεύτερη για παροχή
local_mtu — MTU. Δεδομένου ότι έχουμε ένα εργαστήριο δοκιμών και έχω MTU 1500 στις θύρες του μεταγωγέα OVS, είναι απαραίτητο να το βάλω στο 1450 ώστε να μπορούν να περάσουν πακέτα που είναι ενσωματωμένα στο VxLAN.
network_cidr — δίκτυο παροχής
μεταμφίεση — χρήση NAT για πρόσβαση σε εξωτερικό δίκτυο
μεταμφίεση_δίκτυο - δίκτυο που θα είναι NATed
dhcp_start — η αρχική διεύθυνση του χώρου συγκέντρωσης διευθύνσεων από την οποία οι διευθύνσεις θα εκχωρηθούν σε κόμβους κατά την ανάπτυξη overcloud
dhcp_end — την τελική διεύθυνση του συνόλου διευθύνσεων από το οποίο οι διευθύνσεις θα εκχωρηθούν σε κόμβους κατά την ανάπτυξη overcloud
inspection_iprange — μια ομάδα διευθύνσεων που είναι απαραίτητες για ενδοσκόπηση (δεν πρέπει να επικαλύπτονται με την παραπάνω ομάδα)
scheduler_max_ttempts — μέγιστος αριθμός προσπαθειών εγκατάστασης overcloud (πρέπει να είναι μεγαλύτερος ή ίσος με τον αριθμό των κόμβων)
Αφού περιγραφεί το αρχείο, μπορείτε να δώσετε την εντολή για ανάπτυξη undercloud:
openstack undercloud install
Η διαδικασία διαρκεί από 10 έως 30 λεπτά ανάλογα με το σίδερο σας. Τελικά θα πρέπει να δείτε την έξοδο ως εξής:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################Αυτή η έξοδος λέει ότι έχετε εγκαταστήσει με επιτυχία το undercloud και μπορείτε τώρα να ελέγξετε την κατάσταση του undercloud και να προχωρήσετε στην εγκατάσταση του overcloud.
Αν κοιτάξετε την έξοδο ifconfig, θα δείτε ότι έχει εμφανιστεί μια νέα διεπαφή γέφυρας
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Η ανάπτυξη Overcloud θα πραγματοποιείται πλέον μέσω αυτής της διεπαφής.
Από την παρακάτω έξοδο μπορείτε να δείτε ότι έχουμε όλες τις υπηρεσίες σε έναν κόμβο:
(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name | Service | Zone |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute | nova |
+--------------------------+-----------+----------+Παρακάτω είναι η διαμόρφωση του τμήματος δικτύου undercloud:
(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.168.255.1/24"
}
],
"members": [
{
"dns_servers": [
"192.168.255.253"
],
"mtu": 1450,
"name": "eth0",
"primary": "true",
"type": "interface"
}
],
"mtu": 1450,
"name": "br-ctlplane",
"ovs_extra": [
"br-set-external-id br-ctlplane bridge-id br-ctlplane"
],
"routes": [],
"type": "ovs_bridge"
}
]
}
(undercloud) [stack@undercloud ~]$Εγκατάσταση Overcloud
Αυτή τη στιγμή έχουμε μόνο undercloud και δεν έχουμε αρκετούς κόμβους από τους οποίους θα συναρμολογηθεί το overcloud. Επομένως, πρώτα απ 'όλα, ας αναπτύξουμε τις εικονικές μηχανές που χρειαζόμαστε. Κατά τη διάρκεια της ανάπτυξης, το ίδιο το undercloud θα εγκαταστήσει το λειτουργικό σύστημα και το απαραίτητο λογισμικό στο μηχάνημα overcloud - δηλαδή, δεν χρειάζεται να αναπτύξουμε πλήρως το μηχάνημα, αλλά μόνο να δημιουργήσουμε έναν δίσκο (ή δίσκους) για αυτό και να καθορίσουμε τις παραμέτρους του - δηλαδή , στην πραγματικότητα, έχουμε έναν γυμνό διακομιστή χωρίς εγκατεστημένο λειτουργικό σύστημα σε αυτόν.
Ας πάμε στο φάκελο με τους δίσκους των εικονικών μηχανών μας και ας δημιουργήσουμε δίσκους του απαιτούμενου μεγέθους:
cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160GΕφόσον λειτουργούμε ως root, πρέπει να αλλάξουμε τον κάτοχο αυτών των δίσκων για να μην έχουμε πρόβλημα με τα δικαιώματα:
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]#
[root@hp-gen9 images]#
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# Σημείωση: εάν δεν σκοπεύετε να εγκαταστήσετε το ceph για να το μελετήσετε, τότε οι εντολές δεν δημιουργούν τουλάχιστον 3 κόμβους με τουλάχιστον δύο δίσκους, αλλά στο πρότυπο υποδεικνύουν ότι θα χρησιμοποιηθούν εικονικοί δίσκοι vda, vdb κ.λπ.
Ωραία, τώρα πρέπει να ορίσουμε όλα αυτά τα μηχανήματα:
virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml
virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml
virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml
virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml
virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml Στο τέλος υπάρχει μια εντολή -print-xml > /tmp/storage-1.xml, η οποία δημιουργεί ένα αρχείο xml με μια περιγραφή κάθε μηχανής στο φάκελο /tmp/, αν δεν το προσθέσετε, δεν θα είστε σε θέση να αναγνωρίσει εικονικές μηχανές.
Τώρα πρέπει να ορίσουμε όλα αυτά τα μηχανήματα στο virsh:
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Τώρα μια μικρή απόχρωση - το tripleO χρησιμοποιεί IPMI για τη διαχείριση διακομιστών κατά την εγκατάσταση και την ενδοσκόπηση.
Η ενδοσκόπηση είναι η διαδικασία επιθεώρησης του υλικού προκειμένου να ληφθούν οι παράμετροι που είναι απαραίτητες για την περαιτέρω παροχή των κόμβων. Η ενδοσκόπηση πραγματοποιείται χρησιμοποιώντας το ironic, μια υπηρεσία που έχει σχεδιαστεί για να λειτουργεί με γυμνούς μεταλλικούς διακομιστές.
Αλλά εδώ είναι το πρόβλημα - ενώ οι διακομιστές IPMI υλικού έχουν μια ξεχωριστή θύρα (ή μια κοινή θύρα, αλλά αυτό δεν είναι σημαντικό), τότε οι εικονικές μηχανές δεν διαθέτουν τέτοιες θύρες. Εδώ μας βοηθάει ένα δεκανίκι που ονομάζεται vbmc - ένα βοηθητικό πρόγραμμα που σας επιτρέπει να μιμηθείτε μια θύρα IPMI. Αυτή η απόχρωση αξίζει να προσέξετε ειδικά για όσους θέλουν να δημιουργήσουν ένα τέτοιο εργαστήριο σε έναν hypervisor ESXI - για να είμαι ειλικρινής, δεν ξέρω αν έχει ανάλογο του vbmc, οπότε αξίζει να αναρωτηθείτε για αυτό το ζήτημα πριν αναπτύξετε τα πάντα .
Εγκαταστήστε το vbmc:
yum install yum install python2-virtualbmcΕάν το λειτουργικό σας σύστημα δεν μπορεί να βρει το πακέτο, τότε προσθέστε το αποθετήριο:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmΤώρα ρυθμίζουμε το βοηθητικό πρόγραμμα. Όλα εδώ είναι μπανάλ μέχρι ντροπής. Τώρα είναι λογικό να μην υπάρχουν διακομιστές στη λίστα vbmc
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Για να εμφανιστούν, πρέπει να δηλωθούν χειροκίνητα ως εξής:
[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1 | down | :: | 7004 |
| compute-2 | down | :: | 7005 |
| control-1 | down | :: | 7001 |
| storage-1 | down | :: | 7002 |
| storage-2 | down | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#Νομίζω ότι η σύνταξη της εντολής είναι σαφής χωρίς εξήγηση. Ωστόσο, προς το παρόν όλες οι συνεδρίες μας είναι σε κατάσταση DOWN. Για να μεταβούν στην κατάσταση UP, πρέπει να τα ενεργοποιήσετε:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#Και η τελευταία πινελιά - πρέπει να διορθώσετε τους κανόνες του τείχους προστασίας (ή να το απενεργοποιήσετε εντελώς):
firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload
Τώρα ας πάμε στο undercloud και ας ελέγξουμε ότι όλα λειτουργούν. Η διεύθυνση του κεντρικού υπολογιστή είναι 192.168.255.200, στο undercloud προσθέσαμε το απαραίτητο πακέτο ipmitool κατά την προετοιμασία για ανάπτυξη:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningΌπως μπορείτε να δείτε, εκκινήσαμε με επιτυχία τον κόμβο ελέγχου μέσω vbmc. Τώρα ας το απενεργοποιήσουμε και ας προχωρήσουμε:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Το επόμενο βήμα είναι η ενδοσκόπηση των κόμβων στους οποίους θα εγκατασταθεί το overcloud. Για να γίνει αυτό, πρέπει να ετοιμάσουμε ένα αρχείο json με περιγραφή των κόμβων μας. Λάβετε υπόψη ότι, σε αντίθεση με την εγκατάσταση σε γυμνούς διακομιστές, το αρχείο υποδεικνύει τη θύρα στην οποία εκτελείται το vbmc για κάθε μηχάνημα.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27Σημείωση: ο κόμβος ελέγχου έχει δύο διεπαφές, αλλά σε αυτήν την περίπτωση αυτό δεν είναι σημαντικό, σε αυτήν την εγκατάσταση θα μας αρκεί μία.
Τώρα ετοιμάζουμε το αρχείο json. Πρέπει να υποδείξουμε τη διεύθυνση poppy της θύρας μέσω της οποίας θα πραγματοποιηθεί η παροχή, τις παραμέτρους των κόμβων, να τους δώσουμε ονόματα και να υποδείξουμε πώς να φτάσετε στο ipmi:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}Τώρα πρέπει να προετοιμάσουμε εικόνες για ειρωνεία. Για να το κάνετε αυτό, κατεβάστε τα μέσω wget και εγκαταστήστε:
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack 916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack 15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack 53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$Μεταφόρτωση εικόνων στο undercloud:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Έλεγχος ότι έχουν φορτωθεί όλες οι εικόνες
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Κάτι ακόμα - πρέπει να προσθέσετε έναν διακομιστή DNS:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Τώρα μπορούμε να δώσουμε την εντολή για ενδοσκόπηση:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$Όπως μπορείτε να δείτε από την έξοδο, όλα ολοκληρώθηκαν χωρίς σφάλματα. Ας ελέγξουμε ότι όλοι οι κόμβοι βρίσκονται στη διαθέσιμη κατάσταση:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Εάν οι κόμβοι βρίσκονται σε διαφορετική κατάσταση, συνήθως διαχειρίσιμη, τότε κάτι πήγε στραβά και πρέπει να κοιτάξετε το αρχείο καταγραφής και να καταλάβετε γιατί συνέβη αυτό. Λάβετε υπόψη ότι σε αυτό το σενάριο χρησιμοποιούμε εικονικοποίηση και ενδέχεται να υπάρχουν σφάλματα που σχετίζονται με τη χρήση εικονικών μηχανών ή vbmc.
Στη συνέχεια, πρέπει να υποδείξουμε ποιος κόμβος θα εκτελέσει ποια λειτουργία - δηλαδή, να υποδείξουμε το προφίλ με το οποίο θα αναπτυχθεί ο κόμβος:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | None | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | None | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | None | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | None | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | None | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | True |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | True |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | True |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | True |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | True |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | True |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$Καθορίστε το προφίλ για κάθε κόμβο:
openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167Ας ελέγξουμε ότι τα κάναμε όλα σωστά:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | control | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | ceph-storage | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | ceph-storage | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | compute | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | compute | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$Εάν όλα είναι σωστά, δίνουμε την εντολή ανάπτυξης του overcloud:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuΣε μια πραγματική εγκατάσταση, φυσικά θα χρησιμοποιηθούν προσαρμοσμένα πρότυπα, στην περίπτωσή μας αυτό θα περιπλέξει πολύ τη διαδικασία, καθώς κάθε τροποποίηση στο πρότυπο θα πρέπει να εξηγείται. Όπως γράφτηκε νωρίτερα, ακόμη και μια απλή εγκατάσταση θα είναι αρκετή για να δούμε πώς λειτουργεί.
Σημείωση: η μεταβλητή qemu τύπου --libvirt είναι απαραίτητη σε αυτήν την περίπτωση, αφού θα χρησιμοποιήσουμε ένθετη εικονικοποίηση. Διαφορετικά, δεν θα μπορείτε να εκτελέσετε εικονικές μηχανές.
Τώρα έχετε περίπου μία ώρα, ή ίσως περισσότερο (ανάλογα με τις δυνατότητες του υλικού) και μπορείτε μόνο να ελπίζετε ότι μετά από αυτό το διάστημα θα δείτε το ακόλουθο μήνυμα:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE completed successfully
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$Τώρα έχετε μια σχεδόν πλήρη έκδοση του openstack, στην οποία μπορείτε να μελετήσετε, να πειραματιστείτε κ.λπ.
Ας ελέγξουμε ότι όλα λειτουργούν σωστά. Στη στοίβα του αρχικού καταλόγου του χρήστη υπάρχουν δύο αρχεία - ένα stackrc (για διαχείριση undercloud) και το δεύτερο overcloudrc (για διαχείριση overcloud). Αυτά τα αρχεία πρέπει να προσδιορίζονται ως πηγή, καθώς περιέχουν πληροφορίες απαραίτητες για τον έλεγχο ταυτότητας.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$Η εγκατάστασή μου απαιτεί ακόμα ένα μικρό άγγιγμα - προσθήκη διαδρομής στον ελεγκτή, καθώς το μηχάνημα με το οποίο εργάζομαι είναι σε διαφορετικό δίκτυο. Για να το κάνετε αυτό, μεταβείτε στο control-1 στον λογαριασμό διαχείρισης θερμότητας και καταχωρήστε τη διαδρομή
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Λοιπόν, τώρα μπορείτε να πάτε στον ορίζοντα. Όλες οι πληροφορίες - διευθύνσεις, σύνδεση και κωδικός πρόσβασης - βρίσκονται στο αρχείο /home/stack/overcloudrc. Το τελικό διάγραμμα μοιάζει με αυτό:
Παρεμπιπτόντως, στην εγκατάστασή μας, οι διευθύνσεις μηχανών εκδόθηκαν μέσω DHCP και, όπως μπορείτε να δείτε, εκδίδονται «τυχαία». Μπορείτε να ορίσετε αυστηρά στο πρότυπο ποια διεύθυνση θα πρέπει να επισυναφθεί σε ποιο μηχάνημα κατά την ανάπτυξη, εάν τη χρειάζεστε.
Πώς ρέει η κίνηση μεταξύ εικονικών μηχανών;
Σε αυτό το άρθρο θα εξετάσουμε τρεις επιλογές για τη διέλευση κίνησης
- Δύο μηχανές σε έναν hypervisor σε ένα δίκτυο L2
- Δύο μηχανές σε διαφορετικούς hypervisors στο ίδιο δίκτυο L2
- Δύο μηχανές σε διαφορετικά δίκτυα (rooting μεταξύ δικτύων)
Περιπτώσεις με πρόσβαση στον έξω κόσμο μέσω εξωτερικού δικτύου, με χρήση κινητών διευθύνσεων, καθώς και κατανεμημένης δρομολόγησης, θα εξετάσουμε την επόμενη φορά, προς το παρόν θα επικεντρωθούμε στην εσωτερική κίνηση.
Για έλεγχο, ας συνθέσουμε το ακόλουθο διάγραμμα:
Έχουμε δημιουργήσει 4 εικονικές μηχανές - 3 σε ένα δίκτυο L2 - net-1 και 1 ακόμη στο δίκτυο net-2
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Ας δούμε σε ποιους hypervisors βρίσκονται τα μηχανήματα που δημιουργήθηκαν:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 |
(overcloud) [stack@undercloud ~]$
Οι μηχανές vm-1 και vm-3 βρίσκονται στο compute-0, οι μηχανές vm-2 και vm-4 βρίσκονται στον κόμβο compute-1.
Επιπλέον, ένας εικονικός δρομολογητής έχει δημιουργηθεί για να ενεργοποιήσει τη δρομολόγηση μεταξύ των καθορισμένων δικτύων:
(overcloud) [stack@undercloud ~]$ openstack router list --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID | Name | Status | State | Distributed | HA | Project |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP | False | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ Ο δρομολογητής έχει δύο εικονικές θύρες, οι οποίες λειτουργούν ως πύλες για δίκτυα:
(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ Αλλά προτού δούμε πώς ρέει η κυκλοφορία, ας δούμε τι έχουμε αυτήν τη στιγμή στον κόμβο ελέγχου (που είναι επίσης κόμβος δικτύου) και στον κόμβο υπολογισμού. Ας ξεκινήσουμε με τον κόμβο υπολογισμού.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Αυτή τη στιγμή, ο κόμβος έχει τρεις γέφυρες ovs - br-int, br-tun, br-ex. Ανάμεσά τους, όπως βλέπουμε, υπάρχει ένα σύνολο διεπαφών. Για ευκολία κατανόησης, ας σχεδιάσουμε όλες αυτές τις διεπαφές στο διάγραμμα και ας δούμε τι συμβαίνει.
Εξετάζοντας τις διευθύνσεις στις οποίες ανυψώνονται οι σήραγγες VxLAN, μπορεί να φανεί ότι ένα τούνελ έχει ανυψωθεί στο compute-1 (192.168.255.26), το δεύτερο τούνελ φαίνεται στο control-1 (192.168.255.15). Αλλά το πιο ενδιαφέρον είναι ότι το br-ex δεν έχει φυσικές διεπαφές και αν κοιτάξετε ποιες ροές έχουν διαμορφωθεί, μπορείτε να δείτε ότι αυτή η γέφυρα μπορεί να μειώσει μόνο την κυκλοφορία αυτή τη στιγμή.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Όπως μπορείτε να δείτε από την έξοδο, η διεύθυνση βιδώνεται απευθείας στη φυσική θύρα και όχι στη διεπαφή εικονικής γέφυρας.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-ex
cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$
Σύμφωνα με τον πρώτο κανόνα, ό,τι προήλθε από τη θύρα phy-br-ex πρέπει να απορριφθεί.
Στην πραγματικότητα, προς το παρόν δεν υπάρχει πουθενά αλλού για κυκλοφορία κίνησης σε αυτήν τη γέφυρα εκτός από αυτήν τη διεπαφή (τη διεπαφή με το br-int) και, αν κρίνουμε από τις πτώσεις, η κίνηση BUM έχει ήδη πετάξει στη γέφυρα.
Δηλαδή, η κίνηση μπορεί να φύγει από αυτόν τον κόμβο μόνο μέσω της σήραγγας VxLAN και τίποτα άλλο. Ωστόσο, αν ενεργοποιήσετε το DVR, η κατάσταση θα αλλάξει, αλλά θα το αντιμετωπίσουμε άλλη φορά. Όταν χρησιμοποιείτε απομόνωση δικτύου, για παράδειγμα χρησιμοποιώντας vlans, δεν θα έχετε μία διεπαφή L3 στο vlan 0, αλλά πολλές διεπαφές. Ωστόσο, η κίνηση VxLAN θα εγκαταλείψει τον κόμβο με τον ίδιο τρόπο, αλλά και θα ενσωματωθεί σε κάποιο είδος αποκλειστικού vlan.
Τακτοποιήσαμε τον κόμβο υπολογισμού, ας προχωρήσουμε στον κόμβο ελέγχου.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (internal)
eth0 1/2: (system)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$Στην πραγματικότητα, μπορούμε να πούμε ότι όλα είναι ίδια, αλλά η διεύθυνση IP δεν βρίσκεται πλέον στη φυσική διεπαφή αλλά στην εικονική γέφυρα. Αυτό γίνεται επειδή αυτό το λιμάνι είναι το λιμάνι μέσω του οποίου η κυκλοφορία θα εξέρχεται προς τον έξω κόσμο.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ Αυτή η θύρα είναι συνδεδεμένη με τη γέφυρα br-ex και επειδή δεν υπάρχουν ετικέτες vlan σε αυτήν, αυτή η θύρα είναι μια θύρα κορμού στην οποία επιτρέπονται όλα τα vlan, τώρα η κυκλοφορία πηγαίνει έξω χωρίς ετικέτα, όπως υποδεικνύεται από το vlan-id 0 στο έξοδος παραπάνω.
Όλα τα άλλα αυτή τη στιγμή είναι παρόμοια με τον κόμβο υπολογισμού - οι ίδιες γέφυρες, οι ίδιες σήραγγες που πηγαίνουν σε δύο κόμβους υπολογισμού.
Δεν θα εξετάσουμε τους κόμβους αποθήκευσης σε αυτό το άρθρο, αλλά για να κατανοήσουμε, είναι απαραίτητο να πούμε ότι το τμήμα δικτύου αυτών των κόμβων είναι κοινότοπο σε σημείο ντροπής. Στην περίπτωσή μας, υπάρχει μόνο μία φυσική θύρα (eth0) με μια διεύθυνση IP που της έχει εκχωρηθεί και αυτό είναι. Δεν υπάρχουν σήραγγες VxLAN, γέφυρες σήραγγας κ.λπ. - δεν υπάρχουν καθόλου ovs, αφού δεν έχει νόημα. Όταν χρησιμοποιείτε απομόνωση δικτύου, αυτός ο κόμβος θα έχει δύο διεπαφές (φυσικές θύρες, bodny ή μόνο δύο vlans - δεν πειράζει - εξαρτάται από το τι θέλετε) - μια για διαχείριση, η δεύτερη για κίνηση (εγγραφή στο δίσκο VM , ανάγνωση από δίσκο κ.λπ.)
Καταλάβαμε τι έχουμε στους κόμβους ελλείψει υπηρεσιών. Τώρα ας ξεκινήσουμε 4 εικονικές μηχανές και ας δούμε πώς αλλάζει το σχήμα που περιγράφεται παραπάνω - θα πρέπει να έχουμε θύρες, εικονικούς δρομολογητές κ.λπ.
Μέχρι στιγμής το δίκτυό μας μοιάζει με αυτό:
Έχουμε δύο εικονικές μηχανές σε κάθε κόμβο υπολογιστή. Χρησιμοποιώντας το compute-0 ως παράδειγμα, ας δούμε πώς περιλαμβάνονται τα πάντα.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Το μηχάνημα έχει μόνο μία εικονική διεπαφή - tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Αυτή η διεπαφή εμφανίζεται στη γέφυρα linux:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Όπως μπορείτε να δείτε από την έξοδο, υπάρχουν μόνο δύο διεπαφές στη γέφυρα - tap95d96a75-a0 και qvb95d96a75-a0.
Εδώ αξίζει να σταθούμε λίγο στους τύπους συσκευών εικονικού δικτύου στο OpenStack:
vtap - εικονική διεπαφή συνδεδεμένη σε μια παρουσία (VM)
qbr - Γέφυρα Linux
Το ζεύγος qvb και qvo - vEth συνδέεται σε γέφυρα Linux και Open vSwitch bridge
br-int, br-tun, br-vlan — Ανοίξτε τις γέφυρες vSwitch
patch-, int-br-, phy-br- - Άνοιγμα διασυνδέσεων ενημέρωσης κώδικα vSwitch που συνδέουν γέφυρες
qg, qr, ha, fg, sg - Ανοίξτε τις θύρες vSwitch που χρησιμοποιούνται από εικονικές συσκευές για σύνδεση στο OVS
Όπως καταλαβαίνετε, αν έχουμε μια θύρα qvb95d96a75-a0 στη γέφυρα, η οποία είναι ένα ζεύγος vEth, τότε κάπου υπάρχει το αντίστοιχο της, που λογικά θα έπρεπε να ονομάζεται qvo95d96a75-a0. Ας δούμε ποιες θύρες υπάρχουν στο OVS.
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ Όπως μπορούμε να δούμε, το λιμάνι είναι σε br-int. Το Br-int λειτουργεί ως διακόπτης που τερματίζει τις θύρες εικονικής μηχανής. Εκτός από το qvo95d96a75-a0, η θύρα qvo5bd37136-47 είναι ορατή στην έξοδο. Αυτή είναι η θύρα για τη δεύτερη εικονική μηχανή. Ως αποτέλεσμα, το διάγραμμά μας μοιάζει τώρα με αυτό:
Μια ερώτηση που πρέπει να ενδιαφέρει αμέσως τον προσεκτικό αναγνώστη - ποια είναι η γέφυρα linux μεταξύ της θύρας της εικονικής μηχανής και της θύρας OVS; Γεγονός είναι ότι για την προστασία του μηχανήματος χρησιμοποιούνται ομάδες ασφαλείας, που δεν είναι παρά iptables. Το OVS δεν λειτουργεί με iptables, έτσι εφευρέθηκε αυτό το «δεκανίκι». Ωστόσο, είναι ξεπερασμένο - αντικαθίσταται από το conntrack σε νέες εκδόσεις.
Δηλαδή, τελικά το σχήμα μοιάζει με αυτό:
Δύο μηχανές σε έναν hypervisor σε ένα δίκτυο L2
Δεδομένου ότι αυτά τα δύο VM βρίσκονται στο ίδιο δίκτυο L2 και στον ίδιο hypervisor, η κίνηση μεταξύ τους θα ρέει λογικά τοπικά μέσω br-int, καθώς και τα δύο μηχανήματα θα βρίσκονται στο ίδιο VLAN:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$ Δύο μηχανές σε διαφορετικούς hypervisors στο ίδιο δίκτυο L2
Ας δούμε τώρα πώς θα πάει η κίνηση μεταξύ δύο μηχανών στο ίδιο δίκτυο L2, αλλά βρίσκονται σε διαφορετικούς υπερεπόπτες. Για να είμαι ειλικρινής, τίποτα δεν θα αλλάξει πολύ, απλώς η κίνηση μεταξύ των hypervisors θα περνά μέσα από το τούνελ vxlan. Ας δούμε ένα παράδειγμα.
Διευθύνσεις εικονικών μηχανών μεταξύ των οποίων θα παρακολουθούμε την κίνηση:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface Type Source Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Εξετάζουμε τον πίνακα προώθησης σε br-int στο compute-0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]Η κίνηση πρέπει να πηγαίνει στη θύρα 2 - ας δούμε τι είδους λιμάνι είναι:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$Αυτό είναι το patch-tun - δηλαδή η διεπαφή στο br-tun. Ας δούμε τι συμβαίνει με το πακέτο στο br-tun:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ Το πακέτο συσκευάζεται σε VxLAN και αποστέλλεται στη θύρα 2. Ας δούμε πού οδηγεί η θύρα 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$Αυτό είναι ένα vxlan τούνελ στο compute-1:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Ας πάμε στο compute-1 και ας δούμε τι θα συμβεί στη συνέχεια με το πακέτο:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
2 1 fa:16:3e:44:98:20 1
[heat-admin@overcloud-novacompute-1 ~]$ Το Mac βρίσκεται στον πίνακα προώθησης br-int στο compute-1, και όπως φαίνεται από την παραπάνω έξοδο, είναι ορατό μέσω της θύρας 2, που είναι η θύρα προς το br-tun:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46Λοιπόν, τότε βλέπουμε ότι στο br-int στο compute-1 υπάρχει μια παπαρούνα προορισμού:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
3 1 fa:16:3e:72:ad:53 0
[heat-admin@overcloud-novacompute-1 ~]$ Δηλαδή, το ληφθέν πακέτο θα πετάξει στη θύρα 3, πίσω από την οποία υπάρχει ήδη ένα παράδειγμα εικονικής μηχανής-00000003.
Η ομορφιά της ανάπτυξης του Openstack για εκμάθηση σε εικονική υποδομή είναι ότι μπορούμε εύκολα να συλλάβουμε την κίνηση μεταξύ των υπερβάσεων και να δούμε τι συμβαίνει με αυτό. Αυτό θα κάνουμε τώρα, τρέξτε το tcpdump στη θύρα vnet προς το compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************Η πρώτη γραμμή δείχνει ότι το Patek από τη διεύθυνση 10.0.1.85 πηγαίνει στη διεύθυνση 10.0.1.88 (κυκλοφορία ICMP) και είναι τυλιγμένο σε ένα πακέτο VxLAN με vni 22 και το πακέτο πηγαίνει από τον κεντρικό υπολογιστή 192.168.255.19 (υπολογισμός-0) στον κεντρικό υπολογιστή 192.168.255.26 .1 (υπολογισμός-XNUMX). Μπορούμε να ελέγξουμε ότι το VNI ταιριάζει με αυτό που καθορίζεται στο ovs.
Ας επιστρέψουμε σε αυτήν τη γραμμή actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. Το 0x16 είναι vni στο δεκαεξαδικό σύστημα αριθμών. Ας μετατρέψουμε αυτόν τον αριθμό στο 16ο σύστημα:
16 = 6*16^0+1*16^1 = 6+16 = 22Δηλαδή, το vni αντιστοιχεί στην πραγματικότητα.
Η δεύτερη γραμμή δείχνει την κυκλοφορία επιστροφής, καλά, δεν έχει νόημα να το εξηγήσω, όλα είναι ξεκάθαρα εκεί.
Δύο μηχανές σε διαφορετικά δίκτυα (δρομολόγηση μεταξύ δικτύου)
Η τελευταία περίπτωση για σήμερα είναι η δρομολόγηση μεταξύ δικτύων μέσα σε ένα έργο χρησιμοποιώντας έναν εικονικό δρομολογητή. Εξετάζουμε μια περίπτωση χωρίς DVR (θα την δούμε σε άλλο άρθρο), επομένως η δρομολόγηση γίνεται στον κόμβο δικτύου. Στην περίπτωσή μας, ο κόμβος δικτύου δεν τοποθετείται σε ξεχωριστή οντότητα και βρίσκεται στον κόμβο ελέγχου.
Αρχικά, ας δούμε ότι η δρομολόγηση λειτουργεί:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msΕφόσον σε αυτήν την περίπτωση το πακέτο πρέπει να πάει στην πύλη και να δρομολογηθεί εκεί, πρέπει να μάθουμε τη διεύθυνση poppy της πύλης, για την οποία εξετάζουμε τον πίνακα ARP στην περίπτωση:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] on eth0Τώρα ας δούμε πού πρέπει να αποστέλλεται η κίνηση με προορισμό (10.0.1.254) fa:16:3e:c4:64:70:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$ Ας δούμε πού οδηγεί η θύρα 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ Όλα είναι λογικά, η κίνηση πηγαίνει στο br-tun. Ας δούμε σε ποιο τούνελ vxlan θα είναι τυλιγμένο:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ Η τρίτη θύρα είναι μια σήραγγα vxlan:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ Το οποίο κοιτάζει τον κόμβο ελέγχου:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ Η κίνηση έχει φτάσει στον κόμβο ελέγχου, επομένως πρέπει να πάμε σε αυτόν και να δούμε πώς θα γίνει η δρομολόγηση.
Όπως θυμάστε, ο κόμβος ελέγχου στο εσωτερικό έμοιαζε ακριβώς με τον κόμβο υπολογιστών - οι ίδιες τρεις γέφυρες, μόνο το br-ex είχε μια φυσική θύρα μέσω της οποίας ο κόμβος μπορούσε να στείλει κίνηση έξω. Η δημιουργία παρουσιών άλλαξε τη διαμόρφωση στους κόμβους υπολογιστών - στους κόμβους προστέθηκαν linux bridge, iptables και διεπαφές. Η δημιουργία δικτύων και ενός εικονικού δρομολογητή άφησε επίσης το στίγμα της στη διαμόρφωση του κόμβου ελέγχου.
Έτσι, είναι προφανές ότι η διεύθυνση MAC της πύλης πρέπει να βρίσκεται στον πίνακα προώθησης br-int στον κόμβο ελέγχου. Ας ελέγξουμε ότι είναι εκεί και πού κοιτάζει:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
5 1 fa:16:3e:c4:64:70 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Το Mac είναι ορατό από τη θύρα qr-0c52b15f-8f. Αν επιστρέψουμε στη λίστα των εικονικών θυρών στο Openstack, αυτός ο τύπος θύρας χρησιμοποιείται για τη σύνδεση διαφόρων εικονικών συσκευών στο OVS. Για να είμαστε πιο ακριβείς, το qr είναι μια θύρα στον εικονικό δρομολογητή, η οποία αναπαρίσταται ως χώρος ονομάτων.
Ας δούμε ποιοι χώροι ονομάτων υπάρχουν στον διακομιστή:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Μέχρι και τρία αντίτυπα. Κρίνοντας όμως από τα ονόματα, μπορείτε να μαντέψετε τον σκοπό καθενός από αυτά. Θα επιστρέψουμε σε περιπτώσεις με ID 0 και 1 αργότερα, τώρα μας ενδιαφέρει ο χώρος ονομάτων qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254
[heat-admin@overcloud-controller-0 ~]$ Αυτός ο χώρος ονομάτων περιέχει δύο εσωτερικούς που δημιουργήσαμε νωρίτερα. Και οι δύο εικονικές θύρες έχουν προστεθεί στο br-int. Ας ελέγξουμε τη διεύθυνση mac της θύρας qr-0c52b15f-8f, αφού η κίνηση, κρίνοντας από τη διεύθυνση mac προορισμού, πήγε σε αυτή τη διεπαφή.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ Δηλαδή, σε αυτή την περίπτωση, όλα λειτουργούν σύμφωνα με τους νόμους της τυπικής δρομολόγησης. Εφόσον η κίνηση προορίζεται για τον κεντρικό υπολογιστή 10.0.2.8, πρέπει να εξέλθει από τη δεύτερη διεπαφή qr-92fa49b5-54 και να περάσει από τη σήραγγα vxlan στον κόμβο υπολογισμού:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address HWtype HWaddress Flags Mask Iface
10.0.1.88 ether fa:16:3e:72:ad:53 C qr-0c52b15f-8f
10.0.1.90 ether fa:16:3e:83:ad:a4 C qr-0c52b15f-8f
10.0.2.8 ether fa:16:3e:6c:ad:9c C qr-92fa49b5-54
10.0.2.42 ether fa:16:3e:f5:0b:29 C qr-92fa49b5-54
10.0.1.85 ether fa:16:3e:44:98:20 C qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ Όλα είναι λογικά, χωρίς εκπλήξεις. Ας δούμε πού είναι ορατή η διεύθυνση poppy του κεντρικού υπολογιστή 10.0.2.8 σε br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Όπως ήταν αναμενόμενο, η κίνηση πηγαίνει στο br-tun, ας δούμε σε ποια σήραγγα πηγαίνει η κίνηση στη συνέχεια:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ Η κυκλοφορία πηγαίνει στη σήραγγα για τον υπολογισμό-1. Λοιπόν, στο compute-1 όλα είναι απλά - από το br-tun το πακέτο πηγαίνει στο br-int και από εκεί στη διεπαφή εικονικής μηχανής:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
4 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ Ας ελέγξουμε ότι αυτή είναι όντως η σωστή διεπαφή:
[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02429c001e1c no
qbr3210e8ec-c0 8000.ea27f45358be no qvb3210e8ec-c0
tap3210e8ec-c0
qbre7e23f1b-07 8000.b26ac0eded8a no qvbe7e23f1b-07
tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface Type Source Model MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge qbr3210e8ec-c0 virtio fa:16:3e:6c:ad:9c
[heat-admin@overcloud-novacompute-1 ~]$
Στην πραγματικότητα, περάσαμε μέχρι το πακέτο. Νομίζω ότι προσέξατε ότι η κίνηση περνούσε από διαφορετικές σήραγγες vxlan και έβγαινε με διαφορετικά VNI. Ας δούμε τι είδους VNI είναι αυτά, μετά από το οποίο θα συλλέξουμε μια χωματερή στη θύρα ελέγχου του κόμβου και θα βεβαιωθούμε ότι η κυκλοφορία ρέει ακριβώς όπως περιγράφεται παραπάνω.
Έτσι, η σήραγγα για τον υπολογισμό-0 έχει τις ακόλουθες ενέργειες=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],έξοδος:3. Ας μετατρέψουμε το 0x16 στο σύστημα δεκαδικών αριθμών:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Η σήραγγα για τον υπολογισμό-1 έχει το ακόλουθο VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],έξοδος:2. Ας μετατρέψουμε το 0x63 στο δεκαδικό σύστημα αριθμών:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Λοιπόν, τώρα ας δούμε τη χωματερή:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
*****************omitted*******************Το πρώτο πακέτο είναι ένα πακέτο vxlan από τον κεντρικό υπολογιστή 192.168.255.19 (υπολογισμός-0) στον κεντρικό υπολογιστή 192.168.255.15 (control-1) με vni 22, μέσα στον οποίο συσκευάζεται ένα πακέτο ICMP από τον κεντρικό υπολογιστή 10.0.1.85 στον κεντρικό υπολογιστή 10.0.2.8. Όπως υπολογίσαμε παραπάνω, το vni ταιριάζει με αυτό που είδαμε στην έξοδο.
Το δεύτερο πακέτο είναι ένα πακέτο vxlan από τον κεντρικό υπολογιστή 192.168.255.15 (control-1) στον κεντρικό υπολογιστή 192.168.255.26 (υπολογισμός-1) με vni 99, μέσα στον οποίο συσκευάζεται ένα πακέτο ICMP από τον κεντρικό υπολογιστή 10.0.1.85 στον κεντρικό υπολογιστή 10.0.2.8. Όπως υπολογίσαμε παραπάνω, το vni ταιριάζει με αυτό που είδαμε στην έξοδο.
Τα επόμενα δύο πακέτα είναι κυκλοφορία επιστροφής από την 10.0.2.8 και όχι την 10.0.1.85.
Δηλαδή, στο τέλος πήραμε το ακόλουθο σχήμα κόμβου ελέγχου:
Φαίνεται ότι είναι αυτό; Ξεχάσαμε δύο χώρους ονομάτων:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Καθώς μιλήσαμε για την αρχιτεκτονική της πλατφόρμας cloud, θα ήταν καλό οι μηχανές να λάμβαναν διευθύνσεις αυτόματα από έναν διακομιστή DHCP. Αυτοί είναι δύο διακομιστές DHCP για τα δύο δίκτυά μας 10.0.1.0/24 και 10.0.2.0/24.
Ας ελέγξουμε ότι αυτό είναι αλήθεια. Υπάρχει μόνο μία διεύθυνση σε αυτόν τον χώρο ονομάτων - 10.0.1.1 - η διεύθυνση του ίδιου του διακομιστή DHCP, και περιλαμβάνεται επίσης στο br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Ας δούμε αν οι διεργασίες που περιέχουν qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 στο όνομά τους στον κόμβο ελέγχου:
[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
root 640420 0.0 0.0 4220 348 ? Ss 11:31 0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+ 951620 0.0 0.0 112944 980 pts/0 S+ 18:50 0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ Υπάρχει μια τέτοια διαδικασία και με βάση τις πληροφορίες που παρουσιάζονται στην παραπάνω έξοδο, μπορούμε, για παράδειγμα, να δούμε τι έχουμε αυτή τη στιγμή προς ενοικίαση:
[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$Ως αποτέλεσμα, λαμβάνουμε το ακόλουθο σύνολο υπηρεσιών στον κόμβο ελέγχου:
Λοιπόν, να έχετε κατά νου - αυτό είναι μόνο 4 μηχανήματα, 2 εσωτερικά δίκτυα και ένας εικονικός δρομολογητής... Δεν έχουμε εξωτερικά δίκτυα εδώ τώρα, ένα σωρό διαφορετικά έργα, το καθένα με τα δικά του δίκτυα (επικαλυπτόμενα) και έχουμε ένας κατανεμημένος δρομολογητής απενεργοποιήθηκε και στο τέλος, υπήρχε μόνο ένας κόμβος ελέγχου στον πάγκο δοκιμών (για ανοχή σφαλμάτων πρέπει να υπάρχει απαρτία τριών κόμβων). Είναι λογικό ότι στο εμπόριο όλα είναι «λίγο» πιο περίπλοκα, αλλά σε αυτό το απλό παράδειγμα καταλαβαίνουμε πώς πρέπει να λειτουργεί - είναι φυσικά σημαντικό αν έχετε 3 ή 300 χώρους ονομάτων, αλλά από την άποψη της λειτουργίας του συνόλου δομή, τίποτα δεν θα αλλάξει πολύ... αν και μέχρι να το κάνετε, δεν θα συνδέσετε κάποιο SDN προμηθευτή. Αλλά αυτό είναι μια εντελώς διαφορετική ιστορία.
Ελπίζω να ήταν ενδιαφέρον. Εάν έχετε σχόλια/προσθήκες ή κάπου είπα ξεκάθαρα ψέματα (είμαι άνθρωπος και η γνώμη μου θα είναι πάντα υποκειμενική) - γράψτε τι πρέπει να διορθωθεί/προστεθεί - θα διορθώσουμε/προσθέσουμε τα πάντα.
Εν κατακλείδι, θα ήθελα να πω λίγα λόγια σχετικά με τη σύγκριση του Openstack (τόσο βανίλιας όσο και προμηθευτή) με τη λύση cloud από τη VMWare - μου έκαναν αυτή την ερώτηση πολύ συχνά τα τελευταία δύο χρόνια και, ειλικρινά, είμαι ήδη το έχω βαρεθεί, αλλά ακόμα. Κατά τη γνώμη μου, είναι πολύ δύσκολο να συγκρίνουμε αυτές τις δύο λύσεις, αλλά μπορούμε σίγουρα να πούμε ότι υπάρχουν μειονεκτήματα και στις δύο λύσεις και όταν επιλέγετε μία λύση πρέπει να σταθμίσετε τα υπέρ και τα κατά.
Εάν το OpenStack είναι μια λύση που βασίζεται στην κοινότητα, τότε η VMWare έχει το δικαίωμα να κάνει μόνο ό,τι θέλει (διαβάστε - τι είναι κερδοφόρο γι 'αυτό) και αυτό είναι λογικό - επειδή είναι μια εμπορική εταιρεία που έχει συνηθίσει να βγάζει χρήματα από τους πελάτες της. Αλλά υπάρχει ένα μεγάλο και παχύ ΑΛΛΑ - μπορείτε να κατεβείτε από το OpenStack, για παράδειγμα από τη Nokia, και με λίγα έξοδα να μεταβείτε σε μια λύση από, για παράδειγμα, το Juniper (Contrail Cloud), αλλά είναι απίθανο να μπορέσετε να βγείτε από το VMWare . Για μένα, αυτές οι δύο λύσεις μοιάζουν κάπως έτσι - Το Openstack (πωλητής) είναι ένα απλό κλουβί στο οποίο σε βάζουν, αλλά έχεις ένα κλειδί και μπορείς να φύγεις ανά πάσα στιγμή. Το VMWare είναι ένα χρυσό κλουβί, ο ιδιοκτήτης έχει το κλειδί του κλουβιού και θα σας κοστίσει πολύ.
Δεν προωθώ ούτε το πρώτο προϊόν ούτε το δεύτερο - εσείς επιλέγετε αυτό που χρειάζεστε. Αλλά αν είχα μια τέτοια επιλογή, θα επέλεγα και τις δύο λύσεις - VMWare για το cloud IT (χαμηλά φορτία, εύκολη διαχείριση), OpenStack από κάποιο προμηθευτή (η Nokia και η Juniper παρέχουν πολύ καλές λύσεις με το κλειδί στο χέρι) - για το cloud Telecom. Δεν θα χρησιμοποιούσα το Openstack για καθαρό IT - είναι σαν να πυροβολείς σπουργίτια με ένα κανόνι, αλλά δεν βλέπω άλλες αντενδείξεις στη χρήση του εκτός από πλεονασμό. Ωστόσο, η χρήση του VMWare στις τηλεπικοινωνίες είναι σαν να μεταφέρεις θρυμματισμένη πέτρα σε ένα Ford Raptor - είναι όμορφο από έξω, αλλά ο οδηγός πρέπει να κάνει 10 διαδρομές αντί για ένα.
Κατά τη γνώμη μου, το μεγαλύτερο μειονέκτημα του VMWare είναι το πλήρες κλειστό του - η εταιρεία δεν θα σας δώσει καμία πληροφορία για το πώς λειτουργεί, για παράδειγμα, vSAN ή τι υπάρχει στον πυρήνα του hypervisor - απλά δεν είναι κερδοφόρο για αυτό - δηλαδή, θα Ποτέ μην γίνετε ειδικός στο VMWare - χωρίς την υποστήριξη προμηθευτών, είστε καταδικασμένοι (πολύ συχνά συναντώ ειδικούς του VMWare που μπερδεύονται από ασήμαντες ερωτήσεις). Για μένα, η VMWare αγοράζει ένα αυτοκίνητο με το καπό κλειδωμένο - ναι, μπορεί να έχετε ειδικούς που μπορούν να αλλάξουν τον ιμάντα χρονισμού, αλλά μόνο αυτός που σας πούλησε αυτή τη λύση μπορεί να ανοίξει το καπό. Προσωπικά, δεν μου αρέσουν οι λύσεις που δεν μπορώ να χωρέσω. Θα πείτε ότι μπορεί να μην χρειαστεί να μπείτε κάτω από την κουκούλα. Ναι, αυτό είναι δυνατό, αλλά θα σας κοιτάξω όταν χρειαστεί να συναρμολογήσετε μια μεγάλη συνάρτηση στο cloud από 20-30 εικονικές μηχανές, 40-50 δίκτυα, τα μισά από τα οποία θέλουν να βγουν έξω και το δεύτερο μισό ζητά Επιτάχυνση SR-IOV, διαφορετικά θα χρειαστείτε περισσότερα από μερικές δεκάδες από αυτά τα αυτοκίνητα - διαφορετικά η απόδοση δεν θα είναι αρκετή.
Υπάρχουν και άλλες απόψεις, οπότε μόνο εσείς μπορείτε να αποφασίσετε τι θα επιλέξετε και, το πιο σημαντικό, τότε θα είστε υπεύθυνοι για την επιλογή σας. Αυτή είναι απλώς η γνώμη μου - ένα άτομο που έχει δει και αγγίξει τουλάχιστον 4 προϊόντα - Nokia, Juniper, Red Hat και VMWare. Δηλαδή έχω κάτι να συγκρίνω.
Πηγή: www.habr.com