Πολλά έργα Google Cloud, ένα υβριδικό VPN; Αποφασίστε πρώτα

Όταν πολλά έργα Google Cloud χρειάζονται υβριδική πρόσβαση, το ένστικτο είναι ένα VPN ανά έργο, και αυτό είναι σχεδόν πάντα το λάθος σχήμα. Η ιδιοκτησία του έργου και η δρομολόγηση πακέτων είναι συναφή αλλά διαφορετικά ζητήματα, και η χρήσιμη αρχιτεκτονική διατηρεί τα διοικητικά όρια που χρειάζεστε ενώ δίνει στα προβλεπόμενα προθέματα μία συνειδητή διαδρομή προς το γραφείο ή το κέντρο δεδομένων. Αυτοί οι έλεγχοι καθορίζουν ποιο μοντέλο δικτύου θέλετε πραγματικά, με τη σειρά που αποφεύγει την επανάληψη εργασίας. Καθένας τους μπορεί να τερματίσει τη συζήτηση νωρίς, και αυτό είναι το νόημα.

Ένα όριο έργου δεν απαιτεί αυτόματα δικό του τούνελ.

Ελέγξτε αν το κοινόχρηστο αντικείμενο είναι το δίκτυο

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

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

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

Ελέγξτε αν τα ανεξάρτητα VPC μπορούν να παραμείνουν ανεξάρτητα

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

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

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

Ελέγξτε αν ένα μοντέλο κόμβου ταιριάζει στην τοπολογία

Για ένα μεγαλύτερο ή διαφορετικά τμηματοποιημένο σχέδιο, η επισκόπηση του Google Network Connectivity Center περιγράφει τα μοντέλα κόμβου και ακτίνας. Διαβάστε την για το τι υποστηρίζει η τρέχουσα έκδοση και όχι για το τι υπονοεί το διάγραμμα: ποιοι συνδυασμοί VPC και υβριδικών, ποιες οικογένειες διαδρομών και ποιες πολιτικές επιτρέπει κάθε τύπος ακτίνας.

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

Ο παρακάτω πίνακας είναι η σύνοψη των τριών μοντέλων και του ερωτήματος που καθορίζει καθένα.

Ελέγξτε τι δεν παρέχει η δρομολόγηση

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

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

Καταγράψτε την απόφαση και τον ιδιοκτήτη της

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

Το να μετράτε έργα και να αγοράζετε ένα VPN για το καθένα δεν υποκαθιστά αυτή την απόφαση ιδιοκτησίας. Είναι η ίδια απόφαση, παρμένη αργότερα, από όποιον κληρονομήσει τον λογαριασμό και τον πίνακα δρομολόγησης.