1. Wprowadzenie
Ostatnia aktualizacja: 22.09.2022
Czym jest zasada routingu DNS
Zasady routingu Cloud DNS umożliwiają użytkownikom konfigurowanie kierowania ruchem na podstawie 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 oparta na ważonym algorytmie karuzelowym
- Zasada routingu geolokalizacji
- Zasada routingu z obsługą geofencingu
- Zasady routingu przełączania awaryjnego
W tym module skonfigurujesz i przetestujesz zasady routingu awaryjnego.
Zasady routingu przełączania awaryjnego
Cloud DNS obsługuje kontrole stanu wewnętrznych systemów równoważenia obciążenia TCP/UDP z włączonym dostępem globalnym. W przypadku zasad routingu przełączania awaryjnego możesz skonfigurować podstawowe i zapasowe adresy IP dla rekordu zasobu. W normalnych warunkach Cloud DNS odpowiada na zapytania adresami IP udostępnionymi w podstawowym zbiorze. Gdy wszystkie adresy IP w podstawowym zbiorze ulegną awarii (stan zmieni się na „nieprawidłowy”), Cloud DNS zacznie obsługiwać adresy IP w zbiorze zapasowym.
Kontrole stanu
Zasady routingu DNS będą zależeć od ujednoliconych kontroli stanu(UHC) natywnego wewnętrznego systemu równoważenia obciążenia. Wewnętrzny system równoważenia obciążenia jest uznawany za sprawny, jeśli co najmniej 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) dostarczają różnych informacji. W przypadku wewnętrznego systemu równoważenia obciążenia HTTP(S) UHC podaje 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 o stanie poszczególnych instancji backendu. Szczegółowe informacje o sprawdzaniu stanu znajdziesz tutaj .
Co utworzysz
W tym ćwiczeniu z programowania utworzysz witrynę działającą w 2 regionach i powiążesz z nią zasadę routingu DNS w przypadku przełączania awaryjnego. Konfiguracja będzie obejmować:
Aktywne zasoby –
- Wewnętrzny system równoważenia obciążenia L4 w REGION_1
- Maszyna wirtualna z serwerem WWW Apache w regionie REGION_1
Zasoby kopii zapasowych –
- Wewnętrzny system równoważenia obciążenia L4 w REGION_2
- maszyna wirtualna z serwerem WWW Apache w REGION_2,
Konfiguracja wygląda tak:
Czego się nauczysz
- Tworzenie zasady routingu przełączania awaryjnego
- Uruchamianie przełączania awaryjnego DNS
- Jak stopniowo kierować ruch do zestawu kopii zapasowych
Czego potrzebujesz
- Podstawowa wiedza o DNS
- Podstawowa znajomość Google Compute Engine
- Podstawowa wiedza o wewnętrznym systemie równoważenia obciążenia L4
2. Konfiguracja i wymagania
- Zaloguj się w konsoli Google Cloud i utwórz nowy projekt lub użyj istniejącego. Jeśli nie masz jeszcze konta Gmail ani Google Workspace, musisz je utworzyć.
- Nazwa projektu to wyświetlana nazwa uczestników tego projektu. Jest to ciąg znaków, który nie jest używany przez interfejsy API Google. Możesz ją zaktualizować w dowolnym momencie.
- Identyfikator projektu musi być unikalny we wszystkich projektach Google Cloud i jest niezmienny (nie można go zmienić po ustawieniu). Konsola Cloud automatycznie generuje unikalny ciąg znaków. Zwykle nie musisz się nim przejmować. W większości ćwiczeń z programowania musisz odwoływać się do identyfikatora projektu (zwykle jest on oznaczony jako
PROJECT_ID). Jeśli wygenerowany identyfikator Ci się nie podoba, możesz wygenerować inny losowy identyfikator. Możesz też spróbować własnej nazwy i sprawdzić, czy jest dostępna. Po tym kroku nie można go zmienić i będzie obowiązywać przez cały czas trwania projektu. - Warto wiedzieć, że istnieje też trzecia wartość, czyli numer projektu, z której korzystają niektóre interfejsy API. Więcej informacji o tych 3 wartościach znajdziesz w dokumentacji.
- Następnie musisz włączyć płatności w konsoli Cloud, aby korzystać z zasobów i interfejsów API Google Cloud. Ukończenie tego laboratorium nie powinno wiązać się z dużymi kosztami, a nawet z żadnymi. Aby wyłączyć zasoby i uniknąć naliczania opłat po zakończeniu tego samouczka, możesz usunąć utworzone zasoby lub cały projekt. Nowi użytkownicy Google Cloud mogą skorzystać z bezpłatnego okresu próbnego, w którym mają do dyspozycji środki w wysokości 300 USD.
Uruchamianie Cloud Shell
Z Google Cloud można korzystać zdalnie na laptopie, ale w tym module praktycznym będziesz używać Google Cloud Shell, czyli środowiska wiersza poleceń działającego w chmurze.
W konsoli Google Cloud kliknij ikonę Cloud Shell na pasku narzędzi w prawym górnym rogu:
Uzyskanie dostępu do środowiska i połączenie się z nim powinno zająć tylko kilka chwil. Po zakończeniu powinno wyświetlić się coś takiego:
Ta maszyna wirtualna zawiera wszystkie potrzebne narzędzia dla programistów. Zawiera również stały katalog domowy o pojemności 5 GB i działa w Google Cloud, co znacznie zwiększa wydajność sieci i usprawnia proces uwierzytelniania. Wszystkie zadania w tym laboratorium możesz wykonać w przeglądarce. Nie musisz niczego instalować.
3. Wersja (pakietu) SDK Google Cloud
W momencie pisania tego artykułu najnowszą wersją pakietu SDK Google Cloud jest 401.0.0. Wszystkie polecenia w tym module zostały przetestowane przy użyciu najnowszej wersji pakietu Google Cloud SDK. 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:
Command
gcloud version | grep "Google Cloud SDK"
Przykładowe dane wyjściowe
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 poniższe polecenie, aby zaktualizować pakiet SDK.
Opcjonalne polecenie
sudo apt-get update && sudo apt-get install google-cloud-sdk
4. Zanim zaczniesz
Zanim zaczniesz wdrażać opisaną powyżej architekturę, upewnij się, że Cloud Shell jest prawidłowo skonfigurowany i wszystkie wymagane interfejsy API są włączone.
Konfigurowanie identyfikatora projektu
W Cloud Shell sprawdź, czy identyfikator projektu jest skonfigurowany. Jeśli wiersz poleceń Cloud Shell wygląda jak poniższy przykład i nie planujesz zmieniać identyfikatora projektu, możesz przejść do następnego kroku (Ustawianie zmiennych środowiskowych).
USER@cloudshell:~ (PROJECT_ID)$
Jeśli nadal chcesz zmienić identyfikator projektu, użyj polecenia podanego poniżej. Wiersz poleceń Cloud Shell zmieni się z (PROJECT_ID) na (YOUR-PROJECT-ID).
Opcjonalne polecenie
gcloud config set project [YOUR-PROJECT-ID]
Przykładowe dane wyjściowe
Updated property [core/project]. USER@cloudshell:~ (YOUR-PROJECT-ID)$
Ustawianie zmiennych środowiskowych
Ustaw zmienne środowiskowe
Do ustawienia 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 zostały już ustawione. Sprawdźmy to za pomocą polecenia echo. Wynikiem każdego polecenia powinna być wartość skonfigurowana 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łącz wszystkie niezbędne usługi
Aby włączyć interfejsy Compute API i DNS API, użyj polecenia gcloud services enable. Uruchom te polecenia w Cloud Shell:
Włączanie interfejsu Compute API
Command
gcloud services enable compute.googleapis.com
Włączanie interfejsu DNS API
Command
gcloud services enable dns.googleapis.com
Potwierdź
Teraz, gdy usługi są włączone, sprawdźmy to za pomocą polecenia gcloud services list, aby wyświetlić listę wszystkich włączonych interfejsów API.
Command
gcloud services list | grep -E 'compute|dns'
Przykładowe dane wyjściowe
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 jednej w każdym regionie) i wymagane reguły zapory sieciowej.
Utwórz sieć VPC
Aby utworzyć sieć VPC, użyj polecenia gcloud compute networks create. Ustawiamy tryb podsieci jako niestandardowy, ponieważ w następnym kroku utworzymy własne podsieci. Uruchom te polecenia w Cloud Shell.
Command
gcloud compute networks create my-vpc --subnet-mode custom
Tworzenie podsieci
Użyj polecenia gcloud compute networks subnets create, aby utworzyć 2 podsieci: jedną w REGION_1 i jedną w REGION_2. Uruchom te polecenia w Cloud Shell:
Podsieć REGION_1
Command
gcloud compute networks subnets create ${REGION_1}-subnet \
--network my-vpc \
--range 10.1.0.0/24 \
--region $REGION_1
Podsieć REGION_2
Command
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, która zezwala na ruch SSH na maszynach wirtualnych klienta.
Aby utworzyć reguły zapory sieciowej, użyj polecenia gcloud compute firewall-rules create. Uruchom te polecenia w Cloud Shell:
Zezwalanie na ruch na porcie 80
Command
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
Zezwalanie na ruch SSH na maszynie wirtualnej klienta
Command
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. Tworzenie Cloud NAT
Aby prywatne maszyny wirtualne mogły pobierać i instalować pakiety z internetu, musisz mieć bramy Cloud NAT w obu regionach.
- Maszyny wirtualne serwera WWW będą musiały pobrać i zainstalować serwer WWW Apache.
- Na maszynie wirtualnej klienta trzeba pobrać i zainstalować pakiet dnsutils, który będzie używany do testowania.
Każda brama Cloud NAT jest powiązana z jedną siecią VPC, regionem i routerem Cloud Router. Zanim utworzymy bramy NAT, musimy utworzyć routery Cloud Router w każdym regionie.
Tworzenie routerów Cloud Router
Użyj polecenia gcloud compute routers create, aby utworzyć routery Cloud Router w regionach us-west1 i us-east4. Uruchom te polecenia w Cloud Shell.
Region_1 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
Utwórz bramy NAT
Użyj polecenia gcloud compute routers nat create, aby utworzyć bramy NAT w regionach us-west1 i us-east4. Uruchom te polecenia w Cloud Shell.
Brama NAT w regionie 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 w regionie_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 kliencką maszynę wirtualną.
Tworzenie maszyn wirtualnych serwera WWW
Aby utworzyć serwery WWW, użyj polecenia gcloud compute instances create. Musimy utworzyć 2 serwery WWW: jeden w REGION_1, a drugi w REGION_2. Do instalowania i konfigurowania Apache na serwerach WWW używamy skryptów startowych.
REGION_1 Web Server
Uruchom w Cloud Shell to polecenie:
Command
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'
Serwer internetowy REGION_2
Uruchom w Cloud Shell to polecenie:
Command
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. W następnej sekcji użyjemy tych grup instancji do skonfigurowania usług backendu ILB. Po utworzeniu grup instancji dodamy do nich maszyny wirtualne serwera WWW.
Tworzenie niezarządzanych grup instancji
Użyj polecenia gcloud compute instance-groups unmanaged create, aby utworzyć 2 niezarządzane grupy instancji: jedną dla serwera WWW w regionie us-west1 i jedną dla serwera WWW w regionie 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
Użyj polecenia gcloud compute instance-groups unmanaged add-instances, aby dodać instancje do utworzonych przez nas grup instancji. Dodaj serwer WWW REGION_1 do grupy instancji REGION_1, a 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 przeprowadzenia testów i sprawdzenia konfiguracji DNS. Do zainstalowania pakietu dnsutils używamy skryptu startowego. Uruchom te polecenia w Cloud Shell.
Command
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 warstwy 4, 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, a port docelowy to port 80. Uruchom te polecenia w Cloud Shell:
Command
gcloud compute health-checks create http http-hc --port 80
Konfigurowanie usług backendu
Aby utworzyć usługę backendu, użyj polecenia gcloud compute backend-services create. Po utworzeniu usług backendu dodamy do nich niezarządzane grupy instancji za pomocą polecenia gcloud compute backend-services add-backend. Uruchom te 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
Command
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
Aby utworzyć reguły przekierowania w obu regionach, użyj polecenia gcloud compute forwarding-rules create. Uruchom te polecenia w Cloud Shell:
Reguła przekierowania REGION_1
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. Konfigurowanie DNS
W tej sekcji utworzymy strefę prywatną i zbiór rekordów DNS z zasadą routingu przełączania awaryjnego.
Tworzenie prywatnej strefy DNS
Użyj polecenia gcloud dns managed-zones create, aby utworzyć strefę prywatną dla domeny example.com. Użyjemy tej strefy do utworzenia zestawu rekordów zasobów z zasadami routingu przełączania awaryjnego. Uruchom w Cloud Shell to polecenie:
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
Użyj polecenia gcloud dns record-sets create, aby utworzyć rekord DNS z zasadą routingu przełączania awaryjnego. Głównym celem jest system równoważenia obciążenia w REGION_1. Cloud DNS obsługuje tylko zapasowe cele oparte na danych geograficznych. Zapasowy zestaw to zasada geolokalizacji z systemem równoważenia obciążenia REGION_2 jako celem zarówno dla REGION_1, jak i REGION_2. Uruchom te polecenia w Cloud Shell:
Command
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ładowe dane wyjściowe
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, zanotujmy adresy IP obu wewnętrznych systemów równoważenia obciążenia. Uruchom te polecenia w Cloud Shell.
Command
gcloud compute forwarding-rules list --filter="name:($REGION_1-ilb $REGION_2-ilb)"
Przykładowe dane wyjściowe
W tym przykładzie 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
Teraz zalogujemy się na instancję klienta i przetestujemy rozpoznawanie nazw DNS. W konsoli internetowej otwórz „Compute Engine | Instancje maszyn wirtualnych”.
Kliknij przycisk SSH, aby zalogować się w instancji klienta z konsoli.
Gdy znajdziesz się na maszynie wirtualnej klienta, użyj polecenia dig, aby rozpoznać nazwę domeny failover.example.com.
Pętla jest skonfigurowana tak, aby uruchamiać polecenie 10 razy z wyłącznikiem czasowym ustawionym na 6 sekund.
Command
for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done
Wartość TTL rekordu DNS jest ustawiona na 5 sekund, więc dodano czas uśpienia wynoszący 6 sekund. Wyłącznik czasowy zapewni, że w przypadku każdego żądania DNS otrzymasz odpowiedź DNS bez pamięci podręcznej. Wykonanie tego polecenia zajmie około minuty.
W danych wyjściowych zobaczysz adres IP systemu równoważenia obciążenia w podstawowym zestawie 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
Symulujemy przełączenie awaryjne, usuwając tag sieci z maszyny wirtualnej REGION_1. Zablokuje to dostęp do portu 80, w wyniku czego kontrole stanu zaczną się kończyć niepowodzeniem.
Usuwanie tagu sieciowego
Użyj polecenia gcloud compute instances remove-tags, aby usunąć tag sieciowy z maszyny wirtualnej. Uruchom w Cloud Shell to polecenie:
Command
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
Na instancji klienta uruchom to polecenie:
Command
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 zapasowych rekordu zasobu. W naszej konfiguracji będzie to adres IP systemu równoważenia obciążenia w regionie us-east4.
12. Testowanie stopniowego zwiększania ruchu
Domyślnie zasady przełączania awaryjnego zwracają adres IP podstawowego punktu końcowego dla wszystkich żądań DNS i zwracają adresy IP kopii zapasowej tylko wtedy, gdy podstawowy punkt końcowy nie przejdzie kontroli stanu. Cloud DNS umożliwia użytkownikom skonfigurowanie współczynnika Trickle Ratio, który pozwala Cloud DNS wysyłać część ruchu do celów zapasowych, nawet gdy cele podstawowe są w dobrej kondycji. Współczynnik musi być wartością z zakresu od 0 do 1. Wartością domyślną jest 0.
Aby to sprawdzić, dodajmy tag sieci z powrotem do serwera WWW REGION_1.
Dodawanie tagu sieci
Dodaj tag z powrotem do maszyny wirtualnej serwera WWW, aby zezwolić na ruch HTTP do maszyny wirtualnej w regionie podstawowym. Uruchom w Cloud Shell to polecenie:
Command
gcloud compute instances add-tags $REGION_1-instance \ --zone $REGION_1_ZONE --tags allow-http
Kontrole stanu zakończą się za 10 sekund.
Sprawdź, czy rozpoznawanie nazw DNS wskazuje na 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.
Na instancji klienta uruchom to polecenie:
Command
dig +short failover.example.com
Aktualizowanie rekordu DNS
Teraz zmodyfikujemy rekord DNS dla failover.example.com, aby kierować 30% ruchu do zestawu kopii zapasowych, nawet gdy główny zestaw jest sprawny. Uruchom w Cloud Shell to polecenie:
Command
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 na maszynie wirtualnej klienta. Zauważysz, że rekord DNS failover.example.com będzie rozpoznawany jako adres IP głównego systemu równoważenia obciążenia w około 70% przypadków, a jako adres IP zapasowego systemu równoważenia obciążenia w około 30% przypadków.
for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done
13. Procedura czyszczenia
Aby zwolnić miejsce zajmowane przez zasoby użyte w tym module, uruchom te polecenia w Cloud Shell:
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
Gratulacje, udało Ci się wdrożyć i przetestować zasadę routingu awaryjnego Cloud DNS
Omówione zagadnienia
- Konfigurowanie zasady routingu przełączania awaryjnego Cloud DNS
- Testowanie przełączania awaryjnego DNS
- Jak stopniowo przekierowywać ruch do zestawu kopii zapasowych
Co dalej?
- Spróbuj skonfigurować wiele adresów IP dla zestawów aktywnych i 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 zasad geolokalizacji w zestawie kopii zapasowych.
Więcej informacji
https://cloud.google.com/dns/docs/zones/manage-routing-policies