Αυτό το έγγραφο προορίζεται για αρχιτέκτονες και άτομα που εργάζονται σε επιχειρησιακές και διοικητικές ομάδες. Το έγγραφο περιγράφει ένα παράδειγμα μοτίβου που μπορείτε να χρησιμοποιήσετε για τις δικές σας αναπτύξεις στο Google Cloud

Σε αυτό το μοτίβο, το Cloud DNS κατευθύνει την επισκεψιμότητα σε παρουσίες του Compute Engine σε ομάδες διαχειριζόμενων παρουσιών που εξυπηρετούν το περιεχόμενο. Σε περίπτωση διακοπής λειτουργίας, ενημερώνετε τη ζώνη Cloud DNS και αποτυγχάνετε σε μια στατική τοποθεσία στο Cloud Storage

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

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

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

Για μια εναλλακτική προσέγγιση που χρησιμοποιεί εξωτερική εξισορρόπηση φορτίου HTTP(S) αντί για Cloud DNS για τον έλεγχο της ανακατεύθυνσης, ανατρέξτε στην ενότητα Ανάπτυξη ενός ζεστού ανακτήσιμου διακομιστή ιστού με Μηχανή Υπολογιστών και Αποθήκευση Cloud. Αυτό το μοτίβο είναι χρήσιμο εάν δεν έχετε ή δεν θέλετε να χρησιμοποιήσετε το Cloud DNS

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

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

## Στόχοι

- Δημιουργήστε τοπικές ομάδες διαχειριζόμενων παρουσιών με προσαρμοσμένη εικόνα VM

- Δημιουργήστε έναν κάδο αποθήκευσης Cloud

- Δημιουργήστε και διαμορφώστε μια ζώνη Cloud DNS

- Δοκιμάστε το ζεστό σφάλμα διακομιστή ιστού με ενημερωμένες εγγραφές Cloud DNS

- Δοκιμάστε την ανάκτηση και την αποτυχία με ενημερωμένες εγγραφές Cloud DNS

## Κόστος
Αυτός ο οδηγός χρησιμοποιεί τα ακόλουθα χρεώσιμα στοιχεία του Google Cloud:
Για να δημιουργήσετε μια εκτίμηση κόστους με βάση την προβλεπόμενη χρήση σας,
χρησιμοποιήστε τον υπολογιστή τιμολόγησης

## Πριν ξεκινήσεις
Ορισμένα από τα βήματα σε αυτό το έγγραφο ενδέχεται να μην λειτουργούν σωστά εάν ο οργανισμός σας εφαρμόζει περιορισμούς στο περιβάλλον σας στο Google Cloud. Σε αυτήν την περίπτωση, ενδέχεται να μην μπορείτε να ολοκληρώσετε εργασίες όπως η δημιουργία δημόσιων διευθύνσεων IP ή κλειδιών λογαριασμού υπηρεσίας. Εάν υποβάλετε ένα αίτημα που επιστρέφει ένα σφάλμα σχετικά με περιορισμούς, δείτε πώς μπορείτε να αναπτύξετε εφαρμογές σε ένα περιορισμένο περιβάλλον Google Cloud

- Συνδεθείτε στον λογαριασμό σας στο Google Cloud. Εάν είστε νέοι στο Google Cloud, δημιουργήστε έναν λογαριασμό για να αξιολογήσετε την απόδοση των προϊόντων μας σε πραγματικές συνθήκες. Οι νέοι πελάτες λαμβάνουν επίσης δωρεάν πιστώσεις 300 $ για εκτέλεση, δοκιμή και ανάπτυξη φόρτου εργασίας

-
Στην κονσόλα Google Cloud, στη σελίδα επιλογής έργου, επιλέξτε ή δημιουργήστε ένα έργο Google Cloud

-
Βεβαιωθείτε ότι η χρέωση είναι ενεργοποιημένη για το έργο σας στο Cloud. Μάθετε πώς μπορείτε να ελέγξετε εάν η χρέωση είναι ενεργοποιημένη σε ένα έργο

-
Ενεργοποιήστε το Compute Engine API

- Εγκαταστήστε και αρχικοποιήστε το Google Cloud CLI

-
Στην κονσόλα Google Cloud, στη σελίδα επιλογής έργου, επιλέξτε ή δημιουργήστε ένα έργο Google Cloud

-
Βεβαιωθείτε ότι η χρέωση είναι ενεργοποιημένη για το έργο σας στο Cloud. Μάθετε πώς μπορείτε να ελέγξετε εάν η χρέωση είναι ενεργοποιημένη σε ένα έργο

-
Ενεργοποιήστε το Compute Engine API

- Εγκαταστήστε και αρχικοποιήστε το Google Cloud CLI

Μπορείτε να εκτελέσετε το Google Cloud CLI στην κονσόλα Google Cloud χωρίς να εγκαταστήσετε το Google Cloud CLI. Για να εκτελέσετε το gcloud CLI στην κονσόλα Google Cloud, χρησιμοποιήστε το Cloud Shell

## Προετοιμάστε το περιβάλλον
Σε αυτήν την ενότητα, ορίζετε ορισμένες μεταβλητές για τα ονόματα των πόρων και τις τοποθεσίες σας. Αυτές οι μεταβλητές χρησιμοποιούνται από τις εντολές CLI του Google Cloud καθώς αναπτύσσετε τους πόρους

Σε όλο αυτό το σεμινάριο, εκτός αν αναφέρεται διαφορετικά, εισάγετε όλες τις εντολές στο Cloud Shell ή στο τοπικό σας περιβάλλον ανάπτυξης

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


εφαρμογή
Καθορίστε δύο περιοχές, όπως π.χ
και
ΗΠΑ-δυση1
, και μια ζώνη εντός μιας από αυτές τις περιοχές, όπως π.χ
ΗΠΑ-δυση2
. Αυτή η ζώνη ορίζει πού δημιουργείται η αρχική βάση VM που χρησιμοποιείται για τη δημιουργία μιας εικόνας για την ομάδα διαχειριζόμενων παρουσιών

us-west1-a
Τέλος, ορίστε έναν τομέα που χρησιμοποιείται για τον στατικό ιστότοπό σας, όπως π.χ
example.com
PROJECT_ID=
PROJECT_IDNAME_SUFFIX= appREGION1= us-west1REGION2= us-west2ZONE= us-west1-aDOMAIN= example.com
## Δημιουργήστε ένα VPC και ένα υποδίκτυο
Για να παρέχετε πρόσβαση δικτύου στα VM, δημιουργείτε Virtual Private Cloud (VPC) και υποδίκτυα. Καθώς χρειάζεστε ομάδες διαχειριζόμενων παρουσιών σε δύο περιοχές, δημιουργείτε ένα υποδίκτυο σε κάθε περιοχή. Για περισσότερες πληροφορίες σχετικά με τα πλεονεκτήματα της λειτουργίας προσαρμοσμένου υποδικτύου για τη διαχείριση των περιοχών διευθύνσεων IP που χρησιμοποιούνται στο περιβάλλον σας, ανατρέξτε στο θέμα Χρήση δικτύων VPC προσαρμοσμένης λειτουργίας

Δημιουργήστε το VPC με μια προσαρμοσμένη λειτουργία υποδικτύου:
Τα υπολογιστικά δίκτυα gcloud δημιουργούν δίκτυο-$NAME_SUFFIX --subnet-mode=custom
Τώρα δημιουργήστε δύο υποδίκτυα στο νέο VPC, ένα για κάθε περιοχή. Καθορίστε τα δικά σας εύρη διευθύνσεων, όπως π.χ
και
10.1.0.0/20
, που ταιριάζουν στην περιοχή του δικτύου σας:
10.2.0.0/20
gcloud υπολογιστικά δίκτυα υποδίκτυα δημιουργία \ subnet-$NAME_SUFFIX-$REGION1 \ --network=network-$NAME_SUFFIX \ --range=
10.1.0.0/20\ --region=$REGION1 υποδίκτυα υπολογιστικών δικτύων gcloud δημιουργούν \ subnet-$NAME_SUFFIX-$REGION2 \ --network=network-$NAME_SUFFIX \ --range= 10.2.0.0/20\ --region=$ ΠΕΡΙΟΧΗ2
## Δημιουργία κανόνων τείχους προστασίας
Για να αφήσετε την κυκλοφορία δικτύου να ρέει σωστά στο VPC, χρησιμοποιήστε κανόνες τείχους προστασίας

Δημιουργήστε κανόνες τείχους προστασίας για να επιτρέψετε την κυκλοφορία στον ιστό και τους ελέγχους υγείας για το πρόγραμμα εξισορρόπησης φορτίου και τις ομάδες διαχειριζόμενων παρουσιών:
gcloud compute firewall-rules create allow-http-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=ALLOW \ --rules=tcp:80 \ -- source-ranges=0.0.0.0/0 \ --target-tags=http-server gcloud compute firewall-rules create allow-health-check-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --action=allow \ - -direction=ingress \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=allow-health-check \ --rules=tcp:80
Ο κανόνας HTTP επιτρέπει την κυκλοφορία σε οποιαδήποτε εικονική μηχανή όπου η
Το http-servertag εφαρμόζεται και από οποιαδήποτε πηγή που χρησιμοποιεί το
0.0.0.0/0 εύρος. Για τον κανόνα ελέγχου υγείας, τα προεπιλεγμένα εύρη για το Google Cloud έχουν ρυθμιστεί ώστε να επιτρέπουν στην πλατφόρμα να ελέγχει σωστά την υγεία των πόρων

Για να επιτρέψετε την κυκλοφορία SSH για την αρχική διαμόρφωση μιας βασικής εικόνας VM, εμβέλεια του κανόνα του τείχους προστασίας στο περιβάλλον σας χρησιμοποιώντας το
--source-rangeparameter. Ίσως χρειαστεί να συνεργαστείτε με την ομάδα του δικτύου σας για να προσδιορίσετε ποιες περιοχές πηγών χρησιμοποιεί ο οργανισμός σας

Αντικαθιστώ
με τα δικά σας πεδία διεύθυνσης IP:
IP_ADDRESS_SCOPE
gcloud compute firewall-rules create allow-ssh-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=ALLOW \ --rules=tcp:22 \ -- πηγή-εύρη=
IP_ADDRESS_SCOPE
Αφού δημιουργήσετε τους κανόνες του τείχους προστασίας, βεβαιωθείτε ότι έχουν προστεθεί οι τρεις κανόνες:
gcloud compute firewall-rules list \ --project=$PROJECT_ID \ --filter="NETWORK=network-$NAME_SUFFIX"Το ακόλουθο παράδειγμα εξόδου δείχνει ότι οι τρεις κανόνες έχουν δημιουργηθεί σωστά:
ΟΝΟΜΑ ΚΑΤΕΥΘΥΝΣΗ ΔΙΚΤΥΟΥ ΠΡΟΤΕΡΑΙΟΤΗΤΑ ΕΠΙΤΡΕΠΕΤΑΙ άδεια-έλεγχος υγείας-εφαρμογή δικτύου-εφαρμογή INGRESS 1000 tcp:80 επιτρέπω-http-εφαρμογή δικτύου-εφαρμογή INGRESS 1000 tcp:80 επιτρέπω-ssh-εφαρμογή δικτύου-εφαρμογή INGRESS 1000 tcp:22
## Δημιουργήστε και διαμορφώστε μια βασική εικόνα VM
Για να δημιουργήσετε πανομοιότυπα VM που αναπτύσσετε χωρίς πρόσθετες ρυθμίσεις παραμέτρων, χρησιμοποιείτε μια προσαρμοσμένη εικόνα VM. Αυτή η εικόνα καταγράφει τη διαμόρφωση του λειτουργικού συστήματος και του Apache και χρησιμοποιείται για τη δημιουργία κάθε VM στην ομάδα διαχειριζόμενων παρουσιών στα επόμενα βήματα

Στο VM, δημιουργείτε ένα βασικό
index.html στον μόνιμο δίσκο και
τοποθετήστε το σε
/var/www/example.com. Ένα αρχείο διαμόρφωσης Apache στο
Το /etc/apache2/sites-available/example.com.conf εξυπηρετεί περιεχόμενο ιστού από το
τοποθετημένη μόνιμη θέση δίσκου

Το παρακάτω διάγραμμα δείχνει τη βασική σελίδα HTML που εξυπηρετείται από τον Apache και είναι αποθηκευμένη στον μόνιμο δίσκο:
Μπορείτε να δημιουργήσετε αυτό το περιβάλλον στα ακόλουθα βήματα

Δημιουργήστε ένα βασικό VM με έναν συνδεδεμένο μόνιμο δίσκο:
Οι παρουσίες υπολογισμού gcloud δημιουργούν vm-base-$NAME_SUFFIX \ --zone=$ZONE \ --machine-type=n1-standard-1 \ --subnet=subnet-$NAME_SUFFIX-$REGION1 \ --tags=http-server \ --image=debian-10-buster-v20210420 \ --image-project=debian-cloud \ --boot-disk-size=10GB \ --boot-disk-type=pd-balanced \ --boot-disk- device-name=vm-base-$NAME_SUFFIX \ --create-disk=type=pd-ssd,name=disk-base-$NAME_SUFFIX,size=10GB,device-name=disk-base-$NAME_SUFFIX
Χρησιμοποιείτε παραμέτρους που ορίζονται στην αρχή αυτού του εγγράφου για να ονομάσετε το VM και να συνδεθείτε στο σωστό υποδίκτυο. Τα ονόματα εκχωρούνται επίσης από τις παραμέτρους για το δίσκο εκκίνησης και το δίσκο δεδομένων

Για να εγκαταστήσετε και να διαμορφώσετε τον απλό ιστότοπο, συνδεθείτε πρώτα στο βασικό VM χρησιμοποιώντας SSH:
gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$ZONE
Στην περίοδο λειτουργίας SSH στο VM, δημιουργήστε ένα σενάριο για να διαμορφώσετε το VM σε ένα πρόγραμμα επεξεργασίας της επιλογής σας. Το παρακάτω παράδειγμα χρησιμοποιεί το Nano ως επεξεργαστή:
nano configure-vm.
Επικολλήστε την ακόλουθη δέσμη ενεργειών διαμόρφωσης στο αρχείο:
bin/bash NAME_SUFFIX=
app# Δημιουργία καταλόγου για τα βασικά αρχεία ιστότοπου sudo mkdir -p /var/www/example.com sudo chmod a+w /var/www/example.com sudo chown -R www-data: /var/www/example.com # Βρείτε το όνομα του δίσκου, στη συνέχεια μορφοποιήστε και προσαρτήστε τον DISK_NAME="google-disk-base-$NAME_SUFFIX"DISK_PATHfind /dev/disk/by-id -name DISK_NAME}"| xargs -Ireadlink -fsudo mkfs.ext4 -m 0 - E lazy_itable_init=0,lazy_journal_init=0,discard $DISK_PATH sudo mount -o discard,defaults $DISK_PATH /var/www/example.com # Install Apache sudo apt-get update&& sudo apt-get -y install apache2 # Γράψτε ένα βασικό αρχείο HTML στον προσαρτημένο μόνιμο δίσκο sudo tee -a /var/ www/example.com/index.html >/dev/null EOF'     Παράδειγμα HA / DR   
Καλώς ορίσατε σε έναν ιστότοπο του Compute Engine με θερμή ανακατεύθυνση στο Cloud Storagep>
*:80> ServerName www.example.com ServerAdmin webmaster@localhost DocumentRoot /var/www/example.com ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined  EOF # Ενεργοποίηση του αρχείου διαμόρφωσης Apache και επαναφόρτωση της υπηρεσίας sudo a2dissite 000-default sudo a2ensite example.com.conf sudo systemctl reload apache2
Ενημερώστε το
μεταβλητή για να ταιριάζει με την τιμή που ορίστηκε στην αρχή αυτού του εγγράφου, όπως π.χ
Εφαρμογή NAME_SUFFIX

Καταγράψτε το αρχείο και βγείτε από τον επεξεργαστή σας. Για παράδειγμα, στο Nano χρησιμοποιείτε
Ctrl-Oto να γράψετε το αρχείο και μετά να βγείτε με
Ctrl-X

Κάντε το σενάριο διαμόρφωσης εκτελέσιμο και, στη συνέχεια, εκτελέστε το:
chmod +x configure-vm../configure-vm.
Έξοδος από τη συνεδρία SSH στο VM:
έξοδος
Λάβετε τη διεύθυνση IP του VM και χρησιμοποιήστε
curl για να δείτε τη βασική ιστοσελίδα:
curl $(παρουσίες υπολογισμού gcloud περιγράφουν το vm-base-$NAME_SUFFIX \ --zone $ZONE \ --format="value(networkInterfaces.accessConfigs.[0].natIP.
Ο βασικός ιστότοπος επιστρέφεται, όπως φαίνεται στο ακόλουθο παράδειγμα εξόδου:
     Παράδειγμα HA / DR   
Καλώς ορίσατε σε έναν ιστότοπο του Compute Engine με θερμή ανακατεύθυνση στο Cloud Storagep>

# Δημιουργήστε τις βασικές εικόνες VM gcloud compute images δημιουργία εικόνας-$NAME_SUFFIX \ --source-disk=vm-base-$NAME_SUFFIX \ --source-disk-zone=$ZONE gcloud compute images create image-disk-$NAME_SUFFIX \ - -source-disk=disk-base-$NAME_SUFFIX \ --source-disk-zone=$ZONE # Create instance templates gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION1 \ --machine-type=n1-standard- 1 \ --subnet=projects/$PROJECT_ID/regions/$REGION1/subnetworks/subnet-$NAME_SUFFIX-$REGION1 \ --region=$REGION1 \ --tags=http-server \ --metadatastartup-script /bin/bashn 'echo\ UUIDblkid\ -s\ UUID\ -o\ value\ /dev/sdb /var/www/example.com\ ext4\ discard,defaults,nofail\ 0\ 2 ee\ -a\ /etc/fstabn'mount \ -a \ --image=image-$NAME_SUFFIX \ --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION2 \ --machine -type=n1-standard-1 \ --subnet=projects/$PROJECT_ID/regions/$REGION2/subnetworks/subnet-$NAME_SUFFIX-$REGION2 \ --region=$REGION2 \ --tags=http-server \ --metadatastartup-script /bin/bashn'echo\ UUIDblkid\ -s\ UUID\ -o\ value\ /dev/sdb /var/www/example.com\ ext4\ απόρριψη, προεπιλογές ,nofail\ 0\ 2 ee\ -a\ /etc/fstabn'mount\ -a \ --image=image-$NAME_SUFFIX \ --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes # Δημιουργία υγειονομικού ελέγχου για παρουσίες VM gcloud compute health-checks δημιουργία http-basic-check-$NAME_SUFFIX \ --port 80 # Δημιουργία των διαχειριζόμενων ομάδων παρουσίας gcloud compute παρουσία-ομάδες διαχείρισης δημιουργία παρουσίας-ομάδας-$NAME_SUFFIX-$REGION1 \ --template=template-$NAME_SUFFIX-$REGION1 \ --size=2 \ --region=$REGION1 \ --health-check=http-basic-check-$NAME_SUFFIX gcloud compute instance-groups διαχείριση δημιουργία παρουσίας-ομάδας -$NAME_SUFFIX-$REGION2 \ --template=template-$NAME_SUFFIX-$REGION2 \ --size=2 \ --region=$REGION2 \ --health-check=http-basic-check-$NAME_SUFFIX
## Δημιουργήστε και διαμορφώστε έναν εξισορροπητή φορτίου
Για να έχουν πρόσβαση οι χρήστες στον ιστότοπό σας, πρέπει να επιτρέψετε την επισκεψιμότητα στα VM που εκτελούνται στις ομάδες διαχειριζόμενων παρουσιών. Θέλετε επίσης να ανακατευθύνετε αυτόματα την κυκλοφορία σε νέα εικονικά μηχανήματα, εάν υπάρχει αποτυχία ζώνης σε μια ομάδα διαχειριζόμενων παρουσιών

Στην παρακάτω ενότητα, δημιουργείτε έναν εξωτερικό εξισορροπητή φορτίου HTTPS με μια υπηρεσία υποστήριξης για την κυκλοφορία HTTP στη θύρα 80, χρησιμοποιείτε τον έλεγχο υγείας που δημιουργήθηκε στα προηγούμενα βήματα και αντιστοιχίζετε μια εξωτερική διεύθυνση IP στην υπηρεσία υποστήριξης

Για περισσότερες πληροφορίες, ανατρέξτε στο θέμα Τρόπος ρύθμισης ενός απλού εξωτερικού εξισορροπητή φορτίου HTTP

Δημιουργήστε και διαμορφώστε το load balancer για την εφαρμογή σας:
# Διαμόρφωση κανόνων θύρας για θύρα HTTP 80 gcloud compute instance-groups set-named-ports \ instance-group-$NAME_SUFFIX-$REGION1 \ --named-ports http:80 \ --region $REGION1 gcloud compute instance-groups set- named-ports \ instance-group-$NAME_SUFFIX-$REGION2 \ --named-ports http:80 \ --region $REGION2 # Δημιουργήστε μια υπηρεσία υποστήριξης και προσθέστε τις ομάδες διαχειριζόμενων παρουσιών σε αυτήν gcloud compute backend-services create \ web- backend-service-$NAME_SUFFIX \ --protocol=HTTP \ --port-name=http \ --health-checks=http-basic-check-$NAME_SUFFIX \ --global gcloud compute backend-services add-backend \ web- backend-service-$NAME_SUFFIX \ --instance-group=instance-group-$NAME_SUFFIX-$REGION1 \ --instance-group-region=$REGION1 \ --global gcloud compute backend-services add-backend \ web-backend- service-$NAME_SUFFIX \ --instance-group=instance-group-$NAME_SUFFIX-$REGION2 \ --instance-group-region=$REGION2 \ --global # Δημιουργία χάρτη διεύθυνσης URL για την υπηρεσία backend gcloud compute url-maps create web-map-http-$NAME_SUFFIX \ --default-service web-backend-service-$NAME_SUFFIX # Διαμόρφωση προώθησης για την κυκλοφορία HTTP gcloud compute target-http-proxies δημιουργία \ http-lb-proxy-$NAME_SUFFIX \ --url-map web-map-http- $NAME_SUFFIX gcloud compute προώθησης-κανόνες δημιουργία \ http-content-rule-$NAME_SUFFIX \ --global \ --target-http-proxy=http-lb-proxy-$NAME_SUFFIX \ --ports=80
Λάβετε τη διεύθυνση IP του κανόνα προώθησης για την κυκλοφορία ιστού:
IP_ADDRESSgcloud compute forwarding-rules περιγράφουν το http-content-rule-$NAME_SUFFIX \ --global \ --format="value(IPAddress
Χρήση
κυρτώστε ή ανοίξτε το πρόγραμμα περιήγησής σας για να προβάλετε τον ιστότοπο χρησιμοποιώντας τη διεύθυνση IP του προγράμματος εξισορρόπησης φορτίου από το προηγούμενο βήμα:
curl $IP_ADDRESS
Χρειάζονται μερικά λεπτά για να ολοκληρωθεί η ανάπτυξη του προγράμματος εξισορρόπησης φορτίου και να κατευθύνει σωστά την κυκλοφορία στο backend σας. Επιστρέφεται ένα σφάλμα HTTP 404 εάν το πρόγραμμα εξισορρόπησης φορτίου εξακολουθεί να αναπτύσσεται. Εάν χρειάζεται, περιμένετε λίγα λεπτά και προσπαθήστε να αποκτήσετε ξανά πρόσβαση στον ιστότοπο

Ο βασικός ιστότοπος επιστρέφεται, όπως φαίνεται στο ακόλουθο παράδειγμα εξόδου:
     Παράδειγμα HA / DR   
Καλώς ορίσατε σε έναν ιστότοπο του Compute Engine με θερμή ανακατεύθυνση στο Cloud Storagep>
< index.html     HA / DR example   
Welcome to a test static web server with warm failover from Cloud Storagep> 

example.com
Get the details of the Cloud DNS zone:
gcloud dns managed-zones describe zone-$NAME_SUFFIX
The following example output shows the
nameServersfor the zone, such as
ns-cloud-b1.googledomains.com

 kind: dns#managedZone name: zone-app nameServers: - ns-cloud-b1.googledomains.com. - ns-cloud-b2.googledomains.com. - ns-cloud-b3.googledomains.com. - ns-cloud-b4.googledomains.com

Cloud DNS must be authoritative for your domain. Create nameserver (NS) records with your domain registrar that point to your Cloud DNS zone. Use the nameserver addresses returned in the previous step

For more information and an example using Google Domains, see How to update name servers

In your Cloud DNS zone, add a record for
wwwusing the load balancer IP address obtained in a previous section:
gcloud dns record-sets transaction start \ --zone=zone-$NAME_SUFFIX gcloud dns record-sets transaction add $IP_ADDRESS \ --name=www.$DOMAIN \ --ttl=300 \ --type=A \ --zone=zone-$NAME_SUFFIX
This record directs user requests for the website through the load balancer to the managed instance groups. A TTL of 300 seconds is set to reduce the length of time the cached DNS record exists for a user

Create a record to be used by the Cloud Storage bucket for the static website:
gcloud dns record-sets transaction add c.storage.googleapis.com. \ --name=static-web.$DOMAIN \ --ttl=300 \ --type=CNAME \ --zone=zone-$NAME_SUFFIX
This example uses
static-webas the subdomain. Leave the
c.storage.googleapis.com.Again, a TTL of 300 seconds is set to reduce the length of time the cached DNS record exists for a user
Finally,the DNS record additions to the zone:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
## Verify and test the DNS zone and records
Let's review the resource deployments before simulating a zone failure. All of the resources have been created to support the environment, as shown in the following image:
- Cloud DNS zone records direct users to the load balancer for distribution across the managed instance group VMs

- A Cloud Storage bucket is configured to host static web pages if there's an outage with the managed instance groups

- The Cloud DNS zone is configured to use the static site in Cloud Storage, but doesn't currently resolve requests to the storage bucket

To view the DNS records and test resolution, you must resolve addresses against the Cloud DNS servers. In production deployments, make sure you test and verify the addresses resolve correctly, then update your own DNS servers to resolve appropriately. This document doesn't detail the steps to update your own DNS servers, only how to verify traffic flows correctly under normal and failover conditions

Get the details of the Cloud DNS zone again:
gcloud dns managed-zones describe zone-$NAME_SUFFIX
The following example output shows the
nameServersfor the zone, such as
ns-cloud-b1.googledomains.com

 kind: dns#managedZone name: zone-app nameServers: - ns-cloud-b1.googledomains.com. - ns-cloud-b2.googledomains.com. - ns-cloud-b3.googledomains.com. - ns-cloud-b4.googledomains.com

To resolve the
wwwrecord for your Cloud DNS zone against one of these name servers, use the
digcommand:
dig @ns-cloud-b1.googledomains.com www.$DOMAIN
This example uses the
ns-cloud-b1.googledomains.comnameserver address returned from the previous
describecommand. Provide your own nameserver address shown in the output of the previous command
The following example output shows that the record resolves to the IP address of the load balancer. If you used this nameserver to access the address, such as using
curland the
--resolveparameter with the Cloud DNS nameserver, the default page would be displayed from one of the managed instance groups behind the load balancer

;DiG [email protected] www.example.com ; (1 server found);; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 300 IN A 35.227.253.90
Use the
digcommand again to verify the DNS record for the static website in Cloud Storage:
dig @ns-cloud-b1.googledomains.com static-web.$DOMAIN
The following example output shows that the record resolves to Cloud Storage that can serve the static content from the storage bucket:
;DiG [email protected] static-web.example.com ; (1 server found);; QUESTION SECTION: ;static-web.example.com. IN A ;; ANSWER SECTION: static-web.example.com. 300 IN CNAME c.storage.googleapis.com

## Fail over to the Cloud Storage bucket
In a production environment, you might get an alert using Cloud Monitoring or other monitoring solution when there's a problem with the managed instance groups. This alert prompts a human to understand the scope of the failure before you update the Cloud DNS records to redirect traffic to the Cloud Storage-hosted static website. An alternative approach is to use your monitoring solution to automatically respond to outages with the managed instance groups

When you fail over, Cloud DNS resolves traffic to the Cloud Storage-hosted static website, as shown in the following image:
When you or your monitoring solution determine the most appropriate action

is to update the Cloud DNS records to direct traffic to Cloud Storage,
update the existing DNS
A record. In this document, you manually update the
Cloud DNS records to redirect traffic to the Cloud Storage-hosted
static website

To fail over the Cloud DNS records, remove the existing
Arecord that resolves to the load balancer:
gcloud dns record-sets transaction start \ --zone=zone-$NAME_SUFFIX gcloud dns record-sets transaction remove $IP_ADDRESS \ --name=www.$DOMAIN \ --ttl=300 \ --type=A \ --zone=zone-$NAME_SUFFIX
Create a
CNAMErecord for
wwwthat points to the Cloud Storage-hosted content:
gcloud dns record-sets transaction add static-web.$DOMAIN \ --name=www.$DOMAIN. \ --ttl=30 \ --type=CNAME \ --zone=zone-$NAME_SUFFIX
the updates to the Cloud DNS zone:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
Use the
digcommand to confirm the
wwwrecord now resolves to the address of the Cloud Storage static website:
dig @ns-cloud-b1.googledomains.com www.$DOMAIN
The following example output shows that the
www.example.comrecord resolves to the CNAME record of the Cloud Storage static website. Requests to access
www.example.comare redirected to the Cloud Storage bucket, which displays the static website:
;DiG [email protected] www.example.com ; (1 server found);; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 30 IN CNAME static-web.example.com. static-web.example.com. 300 IN CNAME c.storage.googleapis.com

## Fail back to the managed instance groups
After issues with the managed instance groups are resolved, you can fail back to serving content from the load-balanced managed instance groups by updating the Cloud DNS records again. Again, a human might make this decision using Cloud Monitoring insights for the health of the managed instance groups. Or, you could use automation to respond to the restored health of the managed instance group. In this document, you manually update the Cloud DNS records

When you fail back, Cloud DNS resolves traffic to the managed instance groups again, as shown in the following image:
Remove the
wwwCNAME record that redirects traffic to the Cloud Storage-hosted content:
gcloud dns record-sets transaction start \ --zone=zone-$NAME_SUFFIX gcloud dns record-sets transaction remove static-web.$DOMAIN \ --name=www.$DOMAIN \ --ttl=30 \ --type=CNAME \ --zone=zone-$NAME_SUFFIX
Add an
Arecord to point to the load balancer in front of the managed instance groups again:

gcloud dns record-sets transaction add $IP_ADDRESS \ --name=www.$DOMAIN \ --ttl=300 \ --type=A \ --zone=zone-$NAME_SUFFIX
the updates to the Cloud DNS zone:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
Use the
digcommand one more time to confirm the
wwwrecord resolves to the address of the load balancer in front of the managed instance groups again:
dig @ns-cloud-b1.googledomains.com www.$DOMAIN
The following example output shows that the record resolves to the IP address of the load balancer and traffic would be served from one of the managed instance groups:
;DiG [email protected] www.example.com ; (1 server found);; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 300 IN A 35.227.253.90
## Clean up
To avoid incurring charges to your Google Cloud account for the resources used in this tutorial, either delete the project that contains the resources, or keep the project and delete the individual resources

To delete the individual resources created in this document, complete the following steps:
Delete the DNS zone and records:
touch empty-file gcloud dns record-sets import -z zone-$NAME_SUFFIX \ --delete-all-existing \ empty-file rm empty-file gcloud dns managed-zones delete zone-$NAME_SUFFIX
Delete the Cloud Storage bucket:
gsutil rm -r gsstatic-web.$DOMAIN
Delete the load balancer configuration:
gcloud compute forwarding-rules delete \ http-content-rule-$NAME_SUFFIX --global --quiet gcloud compute target-http-proxies delete \ http-lb-proxy-$NAME_SUFFIX --quiet gcloud compute url-maps delete web-map-http-$NAME_SUFFIX --quiet gcloud compute backend-services delete \ web-backend-service-$NAME_SUFFIX --global --quiet
Delete the managed instance groups and health check:
gcloud compute instance-groups managed delete \ instance-group-$NAME_SUFFIX-$REGION1 \ --region=$REGION1 --quiet gcloud compute instance-groups managed delete \ instance-group-$NAME_SUFFIX-$REGION2 \ --region=$REGION2 --quiet gcloud compute health-checks delete http-basic-check-$NAME_SUFFIX --quiet
Delete the instance templates, images, base VM, and persistent disks:
gcloud compute instance-templates delete \ template-$NAME_SUFFIX-$REGION1 --quiet gcloud compute instance-templates delete \ template-$NAME_SUFFIX-$REGION2 --quiet gcloud compute images delete image-$NAME_SUFFIX --quiet gcloud compute images delete image-disk-$NAME_SUFFIX --quiet gcloud compute instances delete vm-base-$NAME_SUFFIX \ --zone=$ZONE --quiet
Delete the firewall rules


gcloud compute firewall-rules delete \ allow-health-check-$NAME_SUFFIX --quiet gcloud compute firewall-rules delete \ allow-ssh-$NAME_SUFFIX --quiet gcloud compute firewall-rules delete \ allow-http-$NAME_SUFFIX --quiet
Delete the subnet and VPC

gcloud compute networks subnets delete \ subnet-$NAME_SUFFIX-$REGION1 --region=$REGION1 --quiet gcloud compute networks subnets delete \ subnet-$NAME_SUFFIX-$REGION2 --region=$REGION2 --quiet gcloud compute networks delete network-$NAME_SUFFIX --quiet
## What's next
- For an alternative approach that uses external HTTP(S) Load Balancing instead of Cloud DNS to control the failover, see Deploy a warm recoverable web server with Compute Engine and Cloud Storage. This pattern is useful if you don't have, or don't want to use, Cloud DNS

- To learn how how to determine the best approach for your own applications and which recovery method to use, see the Disaster recovery planning guide

- To see other patterns for applications, such as cold and hot failover, see Disaster recovery scenarios for applications

- For more ways to handle scale and availability, see the Patterns for scalable and resilient apps

- Explore reference architectures, diagrams, tutorials, and best practices about Google Cloud. Take a look at our Cloud Architecture Center.