1. Wprowadzenie
Ostatnia aktualizacja: 22.09.2022 r.
Co to jest zasada routingu DNS
Zasady routingu Cloud DNS umożliwiają użytkownikom konfigurowanie sterowania ruchem opartego na DNS w zależności od określonych kryteriów, takich jak waga, lokalizacja geograficzna czy kontrole stanu.
Cloud DNS obsługuje te zasady routingu:
- Zasada routingu ważonego typu „round robin”
- Zasada routingu geolokalizacji
- Zasada routingu z obsługą geofencingu
- Zasada routingu przełączania awaryjnego
W tym module skonfigurujesz i przetestujesz zasadę routingu przełączania awaryjnego.
Zasady routingu awaryjnego
Cloud DNS obsługuje kontrole stanu wewnętrznych systemów równoważenia obciążenia TCP/UDP, które mają włączony dostęp globalny. Dzięki zasadzie routingu przełączania awaryjnego możesz skonfigurować podstawowe i zapasowe adresy IP dla rekordu zasobu. W normalnym działaniu Cloud DNS będzie odpowiadać na zapytania przy użyciu adresów IP udostępnionych w zbiorze podstawowym. Gdy wszystkie adresy IP w zestawie podstawowym awansują (stan zmienia się na nieprawidłowy), Cloud DNS rozpoczyna obsługę adresów IP z zestawu kopii zapasowych.
Kontrole stanu
Zasady routingu DNS będą zależeć od natywnych ujednoliconych kontroli stanu wewnętrznego systemu równoważenia obciążenia(UHC). Wewnętrzny system równoważenia obciążenia uznaje się za sprawny, jeśli przynajmniej 20% backendów jest sprawnych. Kontrole stanu wewnętrznych systemów równoważenia obciążenia TCP/UDP i wewnętrznych systemów równoważenia obciążenia HTTP(S) podają różne informacje. W przypadku wewnętrznego systemu równoważenia obciążenia HTTP(S) UHC udostępnia stan wszystkich serwerów proxy Envoy, ale w przypadku wewnętrznego systemu równoważenia obciążenia TCP/UDP Cloud DNS otrzymuje bezpośrednie sygnały dotyczące stanu z poszczególnych instancji backendowych. Szczegółowe informacje o kontroli stanu znajdziesz tutaj .
Co utworzysz
W ramach tego ćwiczenia w Codelabs utworzysz witrynę działającą w 2 regionach i powiążesz z nią zasadę routingu DNS. Konfiguracja obejmuje:
Aktywne zasoby –
- Wewnętrzny system równoważenia obciążenia L4 w regionie REGION_1
- Maszyna wirtualna z serwerem WWW Apache w regionie REGION_1
Tworzenie kopii zapasowych zasobów –
- Wewnętrzny system równoważenia obciążenia L4 w regionie REGION_2
- Maszyna wirtualna z serwerem WWW Apache w regionie REGION_2
Konfiguracja wygląda tak:
Czego się nauczysz
- Jak utworzyć zasadę routingu przełączania awaryjnego
- Aktywuj przełączanie awaryjne DNS
- Jak przekierować ruch do zestawu kopii zapasowych
Czego potrzebujesz
- Podstawowa znajomość systemu DNS
- Podstawowa znajomość Google Compute Engine
- Podstawowa znajomość wewnętrznego systemu równoważenia obciążenia L4
2. Konfiguracja i wymagania
- Zaloguj się w konsoli Google Cloud i utwórz nowy projekt lub wykorzystaj już istniejący. Jeśli nie masz jeszcze konta Gmail ani Google Workspace, musisz je utworzyć.
- Nazwa projektu jest wyświetlaną nazwą uczestników tego projektu. To ciąg znaków, który nie jest używany przez interfejsy API Google. W każdej chwili możesz ją zmienić.
- Identyfikator projektu musi być unikalny we wszystkich projektach Google Cloud i nie można go zmienić (nie można go zmienić po ustawieniu). Cloud Console automatycznie wygeneruje unikalny ciąg znaków. zwykle nieważne, co ona jest. W większości ćwiczeń z programowania konieczne jest odwołanie się do identyfikatora projektu (zwykle nazywa się on
PROJECT_ID). Jeśli nie podoba Ci się wygenerowany identyfikator, możesz wygenerować kolejny losowy. Możesz też spróbować własnych sił i sprawdzić, czy jest dostępna. Potem nie będzie można go zmienić. Pozostanie ono przez czas trwania projektu. - Dostępna jest trzecia wartość, numer projektu, z którego korzystają niektóre interfejsy API. Więcej informacji o wszystkich 3 wartościach znajdziesz w dokumentacji.
- Następnie musisz włączyć płatności w Cloud Console, aby korzystać z zasobów Cloud/interfejsów API. Ukończenie tego ćwiczenia z programowania nie powinno kosztować zbyt wiele. Aby wyłączyć zasoby, aby nie naliczać opłat po zakończeniu tego samouczka, możesz usunąć utworzone zasoby lub cały projekt. Nowi użytkownicy Google Cloud mogą skorzystać z programu bezpłatnego okresu próbnego o wartości 300 USD.
Uruchamianie Cloud Shell
Google Cloud można obsługiwać zdalnie z laptopa, ale w ramach tego ćwiczenia z programowania wykorzystasz Google Cloud Shell – środowisko wiersza poleceń działające w chmurze.
W konsoli Google Cloud kliknij ikonę Cloud Shell na górnym pasku narzędzi:
Uzyskanie dostępu do środowiska i połączenie się z nim powinno zająć tylko kilka chwil. Po zakończeniu powinno pojawić się coś takiego:
Ta maszyna wirtualna ma wszystkie potrzebne narzędzia dla programistów. Zawiera stały katalog domowy o pojemności 5 GB i działa w Google Cloud, znacząco zwiększając wydajność sieci i uwierzytelnianie. Wszystkie zadania w ramach tego ćwiczenia z programowania można wykonywać w przeglądarce. Nie musisz niczego instalować.
3. Wersja pakietu SDK Google Cloud
W momencie pisania wiadomości pakiet 401.0.0 jest najnowszą wersją pakietu SDK Google Cloud. Wszystkie polecenia w tym module zostały przetestowane przy użyciu najnowszej wersji pakietu SDK Google Cloud. Zanim przejdziesz dalej, sprawdź, czy Cloud Shell używa najnowszej wersji pakietu SDK.
Sprawdzanie wersji pakietu SDK
Aby sprawdzić wersję pakietu SDK, użyj polecenia gcloud version. Uruchom te polecenia w Cloud Shell
Polecenie
gcloud version | grep "Google Cloud SDK"
Przykład wyjściowy
Google Cloud SDK 401.0.0
Następne kroki
- Jeśli wersja pakietu SDK to
401.0.0lub nowsza, przejdź do następnej sekcji. - Jeśli wersja pakietu SDK jest niższa niż
401.0.0, uruchom podane poniżej polecenie, aby zaktualizować pakiet SDK.
Polecenie opcjonalne
sudo apt-get update && sudo apt-get install google-cloud-sdk
4. Zanim zaczniesz
Zanim zaczniesz wdrażać architekturę, którą omówiliśmy powyżej, sprawdźmy, czy Cloud Shell jest poprawnie skonfigurowana i czy wszystkie wymagane interfejsy API są włączone.
Skonfiguruj identyfikator projektu
Sprawdź w Cloud Shell, czy identyfikator projektu jest skonfigurowany. Jeśli prompt Cloud Shell przypomina poniższe dane wyjściowe i nie planujesz zmieniać identyfikatora projektu, możesz przejść do następnego kroku (ustawiania zmiennych środowiskowych).
USER@cloudshell:~ (PROJECT_ID)$
Jeśli nadal chcesz zmienić identyfikator projektu, użyj polecenia wymienionego poniżej. Prompt Cloud Shell zmieni się z (PROJECT_ID) na (YOUR-PROJECT-ID)
Polecenie opcjonalne
gcloud config set project [YOUR-PROJECT-ID]
Przykład wyjściowy
Updated property [core/project]. USER@cloudshell:~ (YOUR-PROJECT-ID)$
Ustawianie zmiennych środowiskowych
Ustawianie zmiennych środowiskowych
Do ustawiania zmiennych środowiskowych użyjemy polecenia export. Uruchom te polecenia w Cloud Shell
Polecenia
export REGION_1=us-west1
export REGION_1_ZONE=us-west1-a
export REGION_2=us-east4
export REGION_2_ZONE=us-east4-a
Potwierdź
Zmienne środowiskowe są już skonfigurowane, przejdźmy więc do weryfikacji za pomocą polecenia echo. Dane wyjściowe każdego polecenia powinny być zgodne z wartością skonfigurowaną powyżej za pomocą polecenia export. Uruchom te polecenia w Cloud Shell
Polecenia
echo $REGION_1
echo $REGION_1_ZONE
echo $REGION_2
echo $REGION_2_ZONE
Włączanie wszystkich wymaganych usług
Włącz interfejsy Compute API i DNS za pomocą polecenia gcloud services enable. Uruchom te polecenia w Cloud Shell
Włączanie interfejsu Compute API
Polecenie
gcloud services enable compute.googleapis.com
Włączanie interfejsu DNS API
Polecenie
gcloud services enable dns.googleapis.com
Potwierdź
Skoro usługi są już włączone, sprawdźmy za pomocą polecenia gcloud services list, aby wyświetlić listę wszystkich włączonych interfejsów API.
Polecenie
gcloud services list | grep -E 'compute|dns'
Przykład wyjściowy
NAME: compute.googleapis.com NAME: dns.googleapis.com
5. Tworzenie sieci VPC, podsieci i reguł zapory sieciowej
W tej sekcji utworzymy sieć VPC, 2 podsieci (po 1 w każdym regionie) i wymagane reguły zapory sieciowej.
Tworzenie sieci VPC
Aby utworzyć sieć VPC, użyj polecenia gcloud compute networks create. Ustawiamy tryb podsieci na niestandardowy, ponieważ w następnym kroku utworzymy własne podsieci. Uruchom podane niżej polecenia w Cloud Shell.
Polecenie
gcloud compute networks create my-vpc --subnet-mode custom
Utwórz podsieci
Za pomocą polecenia gcloud compute networks subnets create utwórz 2 podsieci – jedną w regionie REGION_1, a drugą w regionie REGION_2. Uruchom te polecenia w Cloud Shell
Podsieć REGION_1
Polecenie
gcloud compute networks subnets create ${REGION_1}-subnet \
--network my-vpc \
--range 10.1.0.0/24 \
--region $REGION_1
Podsieć REGION_2
Polecenie
gcloud compute networks subnets create ${REGION_2}-subnet \
--network my-vpc \
--range 10.2.0.0/24 \
--region $REGION_2
Tworzenie reguł zapory sieciowej
Musisz zezwolić na ruch na porcie 80 z podsieci VPC i z zakresów adresów IP kontroli stanu systemu równoważenia obciążenia.
Oprócz tego musisz też utworzyć regułę zapory sieciowej zezwalającą na ruch SSH w maszynach wirtualnych klienta.
Użyj polecenia gcloud compute firewall-rules create, aby utworzyć reguły zapory sieciowej. Uruchom te polecenia w Cloud Shell
Zezwalaj na ruch przez port 80
Polecenie
gcloud compute firewall-rules create allow-http-lb-hc \ --allow tcp:80 --network my-vpc \ --source-ranges 10.1.0.0/24,10.2.0.0/24,35.191.0.0/16,130.211.0.0/22 \ --target-tags=allow-http
Zezwalaj na ruch SSH w maszynie wirtualnej klienta
Polecenie
gcloud compute firewall-rules create allow-ssh \ --allow tcp:22 --network my-vpc \ --source-ranges 0.0.0.0/0 \ --target-tags=allow-ssh
6. Utwórz Cloud NAT
Aby prywatne maszyny wirtualne mogły pobierać i instalować pakiety z internetu, potrzebujesz bram Cloud NAT w obu regionach.
- Nasze maszyny wirtualne serwera WWW muszą pobrać i zainstalować serwer WWW Apache.
- Klient maszyny wirtualnej musi pobrać i zainstalować pakiet dnsutils, którego użyjemy do testowania.
Każda brama Cloud NAT jest powiązana z jedną siecią VPC, jednym regionem i routerem Cloud Router. Zanim utworzymy bramy NAT, musimy utworzyć routery Cloud Router w każdym regionie.
Tworzenie routerów Cloud Router
Za pomocą polecenia gcloud compute routers create utwórz routery Cloud Router w regionach us-west1 i us-east4. Uruchom podane niżej polecenia w Cloud Shell.
Region_1, router Cloud Router
Polecenia
gcloud compute routers create "${REGION_1}-cloudrouter" \
--region $REGION_1 --network=my-vpc --asn=65501
Region_2 Cloud Router
Polecenia
gcloud compute routers create "${REGION_2}-cloudrouter" \
--region $REGION_2 --network=my-vpc --asn=65501
Tworzenie bram NAT
Za pomocą polecenia gcloud compute routers nat create utwórz bramy NAT w regionach us-west1 i us-east4. Uruchom podane niżej polecenia w Cloud Shell.
Brama NAT Region_1
Polecenia
gcloud compute routers nats create "${REGION_1}-nat-gw" \
--router="${REGION_1}-cloudrouter" \
--router-region=$REGION_1 \
--nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips
Brama NAT Region_2
Polecenia
gcloud compute routers nats create "${REGION_2}-nat-gw" \
--router="${REGION_2}-cloudrouter" \
--router-region=$REGION_2 \
--nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips
7. Tworzenie maszyn wirtualnych Compute Engine
W tej sekcji utworzysz serwery WWW, niezarządzane grupy instancji dla serwerów WWW i maszynę wirtualną klienta.
Tworzenie maszyn wirtualnych serwera WWW
Aby utworzyć serwery WWW, użyj polecenia gcloud compute instances create. Musimy utworzyć dwa serwery WWW, jeden w regionie REGION_1, a drugi w regionie REGION_2. Do instalowania i konfigurowania serwera Apache na serwerach WWW używamy skryptów startowych.
REGION_1 Serwer WWW
Uruchom to polecenie w Cloud Shell
Polecenie
gcloud compute instances create "${REGION_1}-instance" \
--image-family=debian-11 --image-project=debian-cloud \
--zone=$REGION_1_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_1}-subnet,no-address \
--tags=allow-http \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2'
REGION_2 Serwer WWW
Uruchom to polecenie w Cloud Shell
Polecenie
gcloud compute instances create "${REGION_2}-instance" \
--image-family=debian-11 --image-project=debian-cloud \
--zone=$REGION_2_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_2}-subnet,no-address \
--tags=allow-http \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2'
Tworzenie niezarządzanych grup instancji
W tej sekcji utworzymy 2 niezarządzane grupy instancji. Użyjemy tych grup instancji w następnej sekcji, aby skonfigurować usługi backendu wewnętrznego systemu równoważenia obciążenia. Po utworzeniu grup instancji dodamy do nich maszyny wirtualne serwera WWW.
Tworzenie niezarządzanych grup instancji
Za pomocą polecenia gcloud compute instance-groups unmanaged create utwórz 2 niezarządzane grupy instancji – jedną dla serwera WWW us-west1 i jedną dla serwera WWW us-east4.
Grupa instancji Region_1
Polecenia
gcloud compute instance-groups unmanaged create \
"${REGION_1}-instance-group" --zone=$REGION_1_ZONE
Grupa instancji Region_2
Polecenia
gcloud compute instance-groups unmanaged create \
"${REGION_2}-instance-group" --zone=$REGION_2_ZONE
Dodawanie maszyn wirtualnych do grup instancji
Za pomocą polecenia gcloud compute instance-groups unmanaged add-instances dodaj instancje do właśnie utworzonych grup instancji. Dodaj serwer WWW REGION_1 do grupy instancji REGION_1 i serwer WWW REGION_2 do grupy instancji REGION_2
Grupa instancji Region_1
Polecenia
gcloud compute instance-groups unmanaged add-instances \
"${REGION_1}-instance-group" --instances $REGION_1-instance \
--zone=$REGION_1_ZONE
Grupa instancji Region_2
Polecenia
gcloud compute instance-groups unmanaged add-instances \
"${REGION_2}-instance-group" --instances $REGION_2-instance \
--zone=$REGION_2_ZONE
Tworzenie klienckiej maszyny wirtualnej
Użyjemy tej maszyny wirtualnej do przeprowadzania testów i sprawdzania konfiguracji DNS. Do zainstalowania pakietu dnsutils używamy skryptu startowego. Uruchom podane niżej polecenia w Cloud Shell.
Polecenie
gcloud compute instances create client-instance --image-family=debian-11 \
--image-project=debian-cloud \
--zone=$REGION_1_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_1}-subnet,no-address \
--tags=allow-ssh \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install dnsutils -y'
8. Tworzenie wewnętrznych systemów równoważenia obciążenia L4
Aby utworzyć wewnętrzny system równoważenia obciążenia L4, musimy utworzyć kontrolę stanu, usługę backendu i regułę przekierowania.
Utwórz kontrolę stanu
Aby utworzyć kontrolę stanu, użyj polecenia gcloud compute health-checks create. Tworzymy podstawową kontrolę stanu HTTP i portem docelowym jest port 80. Uruchom te polecenia w Cloud Shell
Polecenie
gcloud compute health-checks create http http-hc --port 80
Konfigurowanie usług backendu
Utwórz usługę backendu za pomocą polecenia gcloud compute backend-services create. Gdy usługi backendu zostaną utworzone, dodamy niezarządzane grupy instancji do usług backendu za pomocą polecenia gcloud compute backend-services add-backend. Uruchom podane niżej polecenia w Cloud Shell.
Utwórz usługę backendu
Polecenia
gcloud compute backend-services create $REGION_1-backend-service \ --load-balancing-scheme=INTERNAL --protocol=TCP \ --health-checks=http-hc --region=$REGION_1
gcloud compute backend-services create $REGION_2-backend-service \ --load-balancing-scheme=INTERNAL --protocol=TCP \ --health-checks=http-hc --region=$REGION_2
Dodaj backend
Polecenie
gcloud compute backend-services add-backend $REGION_1-backend-service \ --instance-group=$REGION_1-instance-group \ --region=$REGION_1 \ --instance-group-zone=$REGION_1_ZONE
gcloud compute backend-services add-backend $REGION_2-backend-service \ --instance-group=$REGION_2-instance-group \ --region=$REGION_2 \ --instance-group-zone=$REGION_2_ZONE
Tworzenie reguł przekierowania
Użyj polecenia gcloud compute forwarding-rules create, aby utworzyć reguły przekierowania w obu regionach. Uruchom te polecenia w Cloud Shell
REGION_1 – reguła przekierowania
Polecenia
gcloud compute forwarding-rules create $REGION_1-ilb \
--region=$REGION_1 \
--load-balancing-scheme=internal \
--network=my-vpc \
--subnet=$REGION_1-subnet \
--ip-protocol=TCP \
--ports=80 \
--backend-service=$REGION_1-backend-service \
--backend-service-region=$REGION_1 \
--allow-global-access
Reguła przekierowania REGION_2
gcloud compute forwarding-rules create $REGION_2-ilb \
--region=$REGION_2 \
--load-balancing-scheme=internal \
--network=my-vpc \
--subnet=$REGION_2-subnet \
--ip-protocol=TCP \
--ports=80 \
--backend-service=$REGION_2-backend-service \
--backend-service-region=$REGION_2 \
--allow-global-access
9. Skonfiguruj DNS
W tej sekcji utworzymy strefę prywatną i zestaw rekordów DNS z zasadą routingu przełączania awaryjnego.
Tworzenie prywatnej strefy DNS
Za pomocą polecenia gcloud dns managed-zones create utwórz strefę prywatną dla domeny example.com. Użyjemy tej strefy do utworzenia zestawu rekordów zasobów z zasadą routingu przełączania awaryjnego. Uruchom to polecenie w Cloud Shell
Polecenia
gcloud dns managed-zones create example-com \ --dns-name example.com. --description="My private zone" \ --visibility=private --networks my-vpc
Tworzenie rekordu DNS z zasadą routingu przełączania awaryjnego
Utwórz rekord DNS z zasadą routingu przełączania awaryjnego za pomocą polecenia gcloud dns record-sets create. Podstawowym miejscem docelowym jest system równoważenia obciążenia w regionie REGION_1. Cloud DNS obsługuje tylko cele kopii zapasowych oparte na danych geograficznych, a zbiór kopii zapasowych to zasada geolokalizacji z systemem równoważenia obciążenia REGION_2 jako miejscem docelowym dla regionów REGION_1 i REGION_2. Uruchom te polecenia w Cloud Shell
Polecenie
gcloud dns record-sets create failover.example.com --ttl 5 --type A \
--routing-policy-type=FAILOVER \
--routing-policy-primary-data=$REGION_1-ilb \
--routing-policy-backup-data="${REGION_1}=${REGION_2}-ilb;${REGION_2}=${REGION_2}-ilb" \
--routing-policy-backup-data-type=GEO \
--zone=example-com \
--enable-health-checking
Przykład wyjściowy
NAME: failover.example.com. TYPE: A TTL: 5 DATA: Primary: "10.1.0.4, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-west1, regionalL4ilb" Backup: us-west1: "10.2.0.3, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-east4, regionalL4ilb";us-east4: "10.2.0.3, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-east4, regionalL4ilb"
10. Testowanie rozpoznawania nazw DNS
Zanim przetestujemy konfigurację przełączania awaryjnego, zwróćmy uwagę na adresy IP obu wewnętrznych systemów równoważenia obciążenia. Uruchom podane niżej polecenia w Cloud Shell.
Polecenie
gcloud compute forwarding-rules list --filter="name:($REGION_1-ilb $REGION_2-ilb)"
Przykład wyjściowy
W tym przykładzie sieć us-west1-ilb ma adres IP 10.1.0.4, a us-east4-ilb ma adres IP 10.2.0.3
NAME: us-west1-ilb REGION: us-west1 IP_ADDRESS: 10.1.0.4 IP_PROTOCOL: TCP TARGET: us-west1/backendServices/us-west1-backend-service NAME: us-east4-ilb REGION: us-east4 IP_ADDRESS: 10.2.0.3 IP_PROTOCOL: TCP TARGET: us-east4/backendServices/us-east4-backend-service
Zalogujemy się teraz do instancji klienta i przetestujemy rozpoznawanie nazw DNS. W konsoli internetowej przejdź do pozycji „Compute Engine | „Instancje maszyn wirtualnych”
Kliknij przycisk SSH, aby zalogować się do instancji klienta z poziomu konsoli.
Jesteśmy już w maszynie wirtualnej klienta. Użyj polecenia dig, aby znaleźć nazwę domeny failover.example.com.
Pętla jest skonfigurowana tak, aby polecenie było uruchamiane 10 razy z wyłącznikiem czasowym ustawionym na 6 sekund.
Polecenie
for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done
Wartość TTL w rekordzie DNS jest ustawiona na 5 sekund, dlatego dodano 6-sekundowy wyłącznik czasowy. Wyłącznik czasowy sprawia, że dla każdego żądania DNS otrzymasz niebuforowaną odpowiedź DNS. Wykonanie tego polecenia zajmie około jednej minuty.
W danych wyjściowych zobaczysz adres IP systemu równoważenia obciążenia w podstawowym zbiorze rekordu zasobu. W naszej konfiguracji będzie to adres IP systemu równoważenia obciążenia w regionie us-west1.
11. Testowanie przełączania awaryjnego
Przeprowadzimy symulację przełączania awaryjnego, usuwając tag sieci z maszyny wirtualnej REGION_1. Spowoduje to zablokowanie dostępu do portu 80 i w związku z tym kontrole stanu zaczną kończyć się niepowodzeniem.
Usuwanie tagu sieci
Aby usunąć tag sieci z maszyny wirtualnej, użyj polecenia gcloud compute instances remove-tags. Uruchom to polecenie w Cloud Shell
Polecenie
gcloud compute instances remove-tags $REGION_1-instance \ --zone=$REGION_1_ZONE --tags=allow-http
Kontrola stanu zakończy się niepowodzeniem za 10 sekund. Ponownie uruchom test rozpoznawania nazw DNS.
Rozwiązywanie nazw DNS
W instancji klienta uruchom następujące polecenie
Polecenie
for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done
W danych wyjściowych zobaczysz adres IP systemu równoważenia obciążenia w zestawie kopii zapasowej rekordu zasobu. W naszej konfiguracji będzie to adres IP systemu równoważenia obciążenia w regionie us-east4.
12. Sprawdzanie przepływu ruchu
Domyślnie zasada przełączania awaryjnego zwraca adres IP głównego punktu końcowego dla wszystkich żądań DNS i zwraca zapasowe adresy IP tylko wtedy, gdy podstawowy punkt końcowy nie przejdzie kontroli stanu. Cloud DNS umożliwia użytkownikom skonfigurowanie współczynnika dryfu, co umożliwia Cloud DNS wysyłanie części ruchu do celów kopii zapasowych, nawet jeśli cele główne są sprawne. Procent musi mieć wartość z zakresu od 0 do 1. Wartość domyślna to 0.
Aby to przetestować, dodajmy tag sieci z powrotem do serwera WWW REGION_1.
Dodaj tag sieci
Dodaj tag z powrotem do maszyny wirtualnej serwera WWW, aby umożliwić ruch http do maszyny wirtualnej regionu głównego. Uruchom podane niżej polecenie w Cloud Shell.
Polecenie
gcloud compute instances add-tags $REGION_1-instance \ --zone $REGION_1_ZONE --tags allow-http
Kontrole stanu zostaną zaliczone w ciągu 10 sekund
Sprawdź, czy rozpoznawanie nazw DNS wskazuje podstawowy system równoważenia obciążenia. W naszej konfiguracji będzie to adres IP systemu równoważenia obciążenia w regionie us-west1.
W instancji klienta uruchom następujące polecenie
Polecenie
dig +short failover.example.com
Aktualizowanie rekordu DNS
Teraz zmodyfikujemy rekord DNS domeny failover.example.com, aby spływać 30% ruchu do zestawu kopii zapasowych, nawet jeśli podstawowy nie ma problemów. Uruchom to polecenie w Cloud Shell
Polecenie
gcloud dns record-sets update failover.example.com --ttl 30 --type A \
--routing-policy-type=FAILOVER \
--routing-policy-primary-data=$REGION_1-ilb \
--routing-policy-backup-data="${REGION_1}=${REGION_2}-ilb;${REGION_2}=${REGION_2}-ilb" \
--routing-policy-backup-data-type=GEO \
--zone=example-com --enable-health-checking \
--backup-data-trickle-ratio=0.3
Rozwiązywanie nazw DNS
Uruchom to polecenie z klienckiej maszyny wirtualnej. Zauważysz, że rekord DNS failover.example.com przejdzie pod adres IP podstawowego systemu równoważenia obciążenia ok. przez 70% czasu i na adres IP zapasowego systemu równoważenia obciążenia, ok. W 30% przypadków.
for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done
13. Procedura czyszczenia
Aby wyczyścić zasoby używane w tym module, uruchom w CloudShell te polecenia
gcloud dns record-sets delete failover.example.com --type=A \ --zone=example-com --quiet gcloud dns managed-zones delete example-com --quiet gcloud compute forwarding-rules delete $REGION_1-ilb \ --region=$REGION_1 --quiet gcloud compute forwarding-rules delete $REGION_2-ilb \ --region=$REGION_2 --quiet gcloud compute backend-services delete $REGION_1-backend-service \ --region=$REGION_1 --quiet gcloud compute backend-services delete $REGION_2-backend-service \ --region=$REGION_2 --quiet gcloud compute health-checks delete http-hc --quiet gcloud compute instances delete client-instance --zone=$REGION_1_ZONE --quiet gcloud compute instance-groups unmanaged delete $REGION_1-instance-group \ --zone=$REGION_1_ZONE --quiet gcloud compute instance-groups unmanaged delete $REGION_2-instance-group \ --zone=$REGION_2_ZONE --quiet gcloud compute instances delete $REGION_1-instance \ --zone=$REGION_1_ZONE --quiet gcloud compute instances delete $REGION_2-instance \ --zone=$REGION_2_ZONE --quiet gcloud compute routers nats delete $REGION_1-nat-gw \ --router=$REGION_1-cloudrouter --region=$REGION_1 --quiet gcloud compute routers nats delete $REGION_2-nat-gw \ --router=$REGION_2-cloudrouter --region=$REGION_2 --quiet gcloud compute routers delete $REGION_1-cloudrouter \ --region=$REGION_1 --quiet gcloud compute routers delete $REGION_2-cloudrouter \ --region=$REGION_2 --quiet gcloud compute firewall-rules delete allow-ssh allow-http-lb-hc --quiet gcloud compute networks subnets delete $REGION_1-subnet \ --region=$REGION_1 --quiet gcloud compute networks subnets delete $REGION_2-subnet \ --region=$REGION_2 --quiet gcloud compute networks delete my-vpc --quiet
14. Gratulacje
Gratulujemy! Udało Ci się wdrożyć i przetestować zasadę routingu przełączania awaryjnego Cloud DNS
Omówione zagadnienia
- Jak skonfigurować zasadę routingu przełączania awaryjnego Cloud DNS
- Przetestuj przełączanie awaryjne DNS
- Jak skierować ruch do zestawu kopii zapasowych
Co dalej?
- Spróbuj skonfigurować wiele adresów IP dla zestawów aktywnych i kopii zapasowych
- Spróbuj dodać wiele maszyn wirtualnych backendu do niezarządzanych grup instancji
- Spróbuj skonfigurować wiele systemów równoważenia obciążenia w różnych regionach dla zasady geolokalizacji w zestawie kopii zapasowych.
Więcej informacji
https://cloud.google.com/dns/docs/zones/manage-routing-policies