1. 소개
최종 업데이트: 2022년 9월 22일
DNS 라우팅 정책이란 무엇인가요?
Cloud DNS 라우팅 정책을 통해 사용자는 가중치, 지리적 위치 또는 상태 점검과 같은 특정 기준에 따라 DNS 기반 트래픽 조정을 구성할 수 있습니다.
Cloud DNS는 다음 라우팅 정책을 지원합니다.
- 가중치가 적용된 라운드 로빈 라우팅 정책
- 위치정보 라우팅 정책
- 지오펜싱 라우팅 정책
- 장애 조치 라우팅 정책
이 실습에서는 장애 조치 라우팅 정책을 구성하고 테스트합니다.
장애 조치 라우팅 정책
Cloud DNS는 전역 액세스가 사용 설정된 내부 TCP/UDP 부하 분산기의 상태 확인을 지원합니다. 장애 조치 라우팅 정책을 사용하면 리소스 레코드의 기본 및 백업 IP를 구성할 수 있습니다. 정상 작동 시 Cloud DNS는 기본 세트에 프로비저닝된 IP 주소로 쿼리에 응답합니다. 기본 세트의 모든 IP 주소가 실패 (상태가 비정상으로 변경됨)하면 Cloud DNS가 백업 세트의 IP 주소를 제공하기 시작합니다.
상태 확인
DNS 라우팅 정책은 네이티브 내부 부하 분산기 통합 상태 점검(UHC)에 따라 달라집니다. 백엔드의 20% 이상이 정상인 경우 내부 부하 분산기는 정상으로 간주됩니다. 내부 TCP/UDP 및 내부 HTTP(S) 부하 분산기의 상태 점검은 서로 다른 정보를 제공합니다. 내부 HTTP(S) 부하 분산기의 경우 UHC가 모든 Envoy 프록시의 상태를 제공하지만, 내부 TCP/UDP 부하 분산기의 경우 Cloud DNS가 개별 백엔드 인스턴스에서 직접 상태 신호를 가져옵니다. 상태 점검에 대한 자세한 내용은 여기에서 확인할 수 있습니다 .
빌드할 항목
이 Codelab에서는 두 리전에서 실행되는 웹사이트를 빌드하고 장애 조치 DNS 라우팅 정책을 여기에 연결합니다. 설정에는 다음이 포함됩니다.
활성 리소스 -
- REGION_1의 L4 내부 부하 분산기
- REGION_1에서 Apache 웹 서버를 실행하는 VM
백업 리소스 -
- REGION_2의 L4 내부 부하 분산기
- REGION_2에서 Apache 웹 서버를 실행하는 VM
설정은 아래와 같습니다.
학습할 내용
- 장애 조치 라우팅 정책을 만드는 방법
- DNS 장애 조치 트리거
- 트래픽을 백업 세트로 유인하는 방법
필요한 항목
- DNS에 관한 기본 지식
- Google Compute Engine의 기본 지식
- L4 내부 부하 분산기에 관한 기본 지식
2. 설정 및 요구사항
- Google Cloud Console에 로그인하여 새 프로젝트를 만들거나 기존 프로젝트를 재사용합니다. 아직 Gmail이나 Google Workspace 계정이 없는 경우 계정을 만들어야 합니다.
- 프로젝트 이름은 이 프로젝트 참가자의 표시 이름입니다. 이는 Google API에서 사용하지 않는 문자열이며 언제든지 업데이트할 수 있습니다.
- 프로젝트 ID는 모든 Google Cloud 프로젝트에서 고유해야 하며, 변경할 수 없습니다(설정된 후에는 변경할 수 없음). Cloud 콘솔이 고유한 문자열을 자동으로 생성합니다. 보통은 그게 뭔지 상관하지 않습니다. 대부분의 Codelab에서는 프로젝트 ID (일반적으로
PROJECT_ID
로 식별됨)를 참조해야 합니다. 생성된 ID가 마음에 들지 않으면 무작위로 다른 ID를 생성할 수 있습니다. 또는 직접 시도해 보고 사용 가능한지 확인할 수도 있습니다. 이 단계 이후에는 변경할 수 없으며 프로젝트 기간 동안 유지됩니다. - 참고로 세 번째 값은 일부 API에서 사용하는 프로젝트 번호입니다. 이 세 가지 값에 대한 자세한 내용은 문서를 참고하세요.
- 다음으로 Cloud 리소스/API를 사용하려면 Cloud 콘솔에서 결제를 사용 설정해야 합니다. 이 Codelab 실행에는 많은 비용이 들지 않습니다. 이 튜토리얼이 끝난 후에 요금이 청구되지 않도록 리소스를 종료하려면 만든 리소스를 삭제하거나 전체 프로젝트를 삭제하면 됩니다. Google Cloud 새 사용자에게는 미화 $300 상당의 무료 체험판 프로그램에 참여할 수 있는 자격이 부여됩니다.
Cloud Shell 시작
Google Cloud를 노트북에서 원격으로 실행할 수 있지만, 이 Codelab에서는 Cloud에서 실행되는 명령줄 환경인 Google Cloud Shell을 사용합니다.
Google Cloud Console의 오른쪽 상단 툴바에 있는 Cloud Shell 아이콘을 클릭합니다.
환경을 프로비저닝하고 연결하는 데 몇 분 정도 소요됩니다. 완료되면 다음과 같이 표시됩니다.
가상 머신에는 필요한 개발 도구가 모두 들어있습니다. 영구적인 5GB 홈 디렉터리를 제공하고 Google Cloud에서 실행되므로 네트워크 성능과 인증이 크게 개선됩니다. 이 Codelab의 모든 작업은 브라우저 내에서 수행할 수 있습니다. 아무것도 설치할 필요가 없습니다.
3. Google Cloud SDK 버전
이 문서 작성 시점의 401.0.0
는 최신 Google Cloud SDK 버전입니다. 이 실습의 모든 명령어는 최신 버전의 Google Cloud SDK로 테스트되었습니다. 계속하기 전에 Cloud Shell에서 최신 버전의 SDK를 사용 중인지 확인하세요.
SDK 버전 확인
gcloud version
명령어를 사용하여 SDK 버전을 확인합니다. Cloud Shell에서 다음 명령어를 실행합니다.
명령어
gcloud version | grep "Google Cloud SDK"
출력 예시
Google Cloud SDK 401.0.0
다음 단계
- SDK 버전이
401.0.0
이상이면 다음 섹션으로 건너뜁니다. - SDK 버전이
401.0.0
보다 낮으면 아래 나열된 명령어를 실행하여 SDK를 업데이트합니다.
선택적 명령어
sudo apt-get update && sudo apt-get install google-cloud-sdk
4. 시작하기 전에
위에서 설명한 아키텍처를 배포하기 전에 Cloud Shell이 올바르게 구성되었고 모든 필수 API가 사용 설정되어 있는지 확인하겠습니다.
프로젝트 ID 설정
Cloud Shell 내에서 프로젝트 ID가 설정되어 있는지 확인합니다. Cloud Shell 프롬프트가 아래 출력과 같고 프로젝트 ID를 변경할 계획이 없으면 다음 단계 (환경 변수 설정)로 건너뛸 수 있습니다.
USER@cloudshell:~ (PROJECT_ID)$
그래도 프로젝트 ID를 변경하려는 경우 아래 나열된 명령어를 사용하면 Cloud Shell 프롬프트가 (PROJECT_ID)
에서 (YOUR-PROJECT-ID)
로 변경됩니다.
선택적 명령어
gcloud config set project [YOUR-PROJECT-ID]
출력 예시
Updated property [core/project]. USER@cloudshell:~ (YOUR-PROJECT-ID)$
환경 변수 설정
환경 변수 설정
export
명령어를 사용하여 환경 변수를 설정합니다. Cloud Shell에서 다음 명령어를 실행합니다.
명령어
export REGION_1=us-west1
export REGION_1_ZONE=us-west1-a
export REGION_2=us-east4
export REGION_2_ZONE=us-east4-a
확인
이제 환경 변수가 설정되었으므로 echo
명령어를 사용하여 확인해 보겠습니다. 각 명령어의 출력은 위에서 export
명령어를 사용하여 구성한 값이어야 합니다. Cloud Shell에서 다음 명령어를 실행합니다.
명령어
echo $REGION_1
echo $REGION_1_ZONE
echo $REGION_2
echo $REGION_2_ZONE
필요한 모든 서비스 사용 설정
gcloud services enable
명령어를 사용하여 Compute API 및 DNS API를 사용 설정합니다. Cloud Shell에서 다음 명령어를 실행합니다.
Compute API 사용 설정
명령어
gcloud services enable compute.googleapis.com
DNS API 사용 설정
명령어
gcloud services enable dns.googleapis.com
확인
이제 서비스가 사용 설정되었으므로 gcloud services list
명령어를 사용하여 사용 설정된 모든 API를 나열해 보겠습니다.
명령어
gcloud services list | grep -E 'compute|dns'
출력 예시
NAME: compute.googleapis.com NAME: dns.googleapis.com
5. VPC 네트워크, 서브넷, 방화벽 규칙 만들기
이 섹션에서는 VPC 네트워크, 2개의 서브넷 (각 리전에 하나씩), 필수 방화벽 규칙을 만듭니다.
VPC 네트워크 만들기
gcloud compute networks create
명령어를 사용하여 VPC 네트워크를 만듭니다. 다음 단계에서 자체 서브넷을 만들 것이기 때문에 서브넷 모드를 커스텀으로 설정합니다. Cloud Shell에서 다음 명령어를 실행합니다.
명령어
gcloud compute networks create my-vpc --subnet-mode custom
서브넷 만들기
gcloud compute networks subnets create
명령어를 사용하여 REGION_1 및 REGION_2에 하나씩 총 2개의 서브넷을 만듭니다. Cloud Shell에서 다음 명령어를 실행합니다.
REGION_1 서브넷
명령어
gcloud compute networks subnets create ${REGION_1}-subnet \ --network my-vpc \ --range 10.1.0.0/24 \ --region $REGION_1
REGION_2 서브넷
명령어
gcloud compute networks subnets create ${REGION_2}-subnet \ --network my-vpc \ --range 10.2.0.0/24 \ --region $REGION_2
방화벽 규칙 만들기
포트 80에서 VPC 서브넷 및 부하 분산기 상태 점검 IP 범위의 트래픽을 허용해야 합니다.
또한 클라이언트 VM에서 SSH 트래픽을 허용하는 방화벽 규칙도 만들어야 합니다.
gcloud compute firewall-rules create
명령어를 사용하여 방화벽 규칙을 만듭니다. Cloud Shell에서 다음 명령어를 실행합니다.
포트 80에서 트래픽 허용
명령어
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
클라이언트 VM에서 SSH 트래픽 허용
명령어
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. Cloud NAT 만들기
비공개 VM이 인터넷에서 패키지를 다운로드하고 설치하려면 두 리전 모두에 Cloud NAT 게이트웨이가 있어야 합니다.
- 웹 서버 VM은 Apache 웹 서버를 다운로드하고 설치해야 합니다.
- 클라이언트 VM은 테스트에 사용할 dnsutils 패키지를 다운로드하고 설치해야 합니다.
각 Cloud NAT 게이트웨이는 단일 VPC 네트워크, 리전, Cloud Router와 연결됩니다. 따라서 NAT 게이트웨이를 만들기 전에 각 리전에 Cloud Router를 만들어야 합니다.
Cloud Router 만들기
gcloud compute routers create
명령어를 사용하여 us-west1 및 us-east4 리전에 Cloud Router를 만듭니다. Cloud Shell에서 다음 명령어를 실행합니다.
Region_1 Cloud Router
명령어
gcloud compute routers create "${REGION_1}-cloudrouter" \ --region $REGION_1 --network=my-vpc --asn=65501
Region_2 Cloud Router
명령어
gcloud compute routers create "${REGION_2}-cloudrouter" \ --region $REGION_2 --network=my-vpc --asn=65501
NAT 게이트웨이 만들기
gcloud compute routers nat create
명령어를 사용하여 us-west1 및 us-east4 리전에 NAT 게이트웨이를 만듭니다. Cloud Shell에서 다음 명령어를 실행합니다.
Region_1 NAT 게이트웨이
명령어
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
Region_2 NAT 게이트웨이
명령어
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. Compute Engine VM 만들기
이 섹션에서는 웹 서버, 웹 서버 및 클라이언트 VM을 위한 비관리형 인스턴스 그룹을 만듭니다.
웹 서버 VM 만들기
gcloud compute instances create
명령어를 사용하여 웹 서버를 만듭니다. REGION_1 및 REGION_2에 하나씩 두 개의 웹 서버를 만들어야 합니다. 우리는 시작 스크립트를 사용하여 웹 서버에 Apache를 설치하고 구성합니다.
REGION_1 웹 서버
Cloud Shell에서 다음 명령어를 실행합니다.
명령어
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 웹 서버
Cloud Shell에서 다음 명령어를 실행합니다.
명령어
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'
비관리형 인스턴스 그룹 만들기
이 섹션에서는 비관리형 인스턴스 그룹 2개를 만듭니다. 다음 섹션에서는 이러한 인스턴스 그룹을 사용하여 ILB 백엔드 서비스를 구성합니다. 인스턴스 그룹이 생성되면 이러한 인스턴스 그룹에 웹 서버 VM을 추가합니다.
비관리형 인스턴스 그룹 만들기
gcloud compute instance-groups unmanaged create
명령어를 사용하여 us-west1 웹 서버와 us-east4 웹 서버용으로 각각 하나씩 비관리형 인스턴스 그룹 두 개를 만듭니다.
Region_1 인스턴스 그룹
명령어
gcloud compute instance-groups unmanaged create \ "${REGION_1}-instance-group" --zone=$REGION_1_ZONE
Region_2 인스턴스 그룹
명령어
gcloud compute instance-groups unmanaged create \ "${REGION_2}-instance-group" --zone=$REGION_2_ZONE
인스턴스 그룹에 VM 추가
gcloud compute instance-groups unmanaged add-instances
명령어를 사용하여 방금 만든 인스턴스 그룹에 인스턴스를 추가합니다. REGION_1 인스턴스 그룹에 REGION_1 웹 서버를, REGION_2 인스턴스 그룹에 REGION_2 웹 서버를 추가합니다.
Region_1 인스턴스 그룹
명령어
gcloud compute instance-groups unmanaged add-instances \ "${REGION_1}-instance-group" --instances $REGION_1-instance \ --zone=$REGION_1_ZONE
Region_2 인스턴스 그룹
명령어
gcloud compute instance-groups unmanaged add-instances \ "${REGION_2}-instance-group" --instances $REGION_2-instance \ --zone=$REGION_2_ZONE
클라이언트 VM 만들기
이 VM을 사용하여 테스트를 실행하고 DNS 구성을 확인합니다. 시작 스크립트를 사용하여 dnsutils 패키지를 설치합니다. Cloud Shell에서 다음 명령어를 실행합니다.
명령어
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. L4 내부 부하 분산기 만들기
L4 ILB를 만들려면 상태 점검, 백엔드 서비스, 전달 규칙을 만들어야 합니다.
상태 확인 만들기
gcloud compute health-checks create
명령어를 사용하여 상태 점검을 만듭니다. 기본 http 상태 점검을 생성하고 대상 포트는 포트 80입니다. Cloud Shell에서 다음 명령어를 실행합니다.
명령어
gcloud compute health-checks create http http-hc --port 80
백엔드 서비스 구성
gcloud compute backend-services create
명령어를 사용하여 백엔드 서비스를 만듭니다. 백엔드 서비스가 생성되면 gcloud compute backend-services add-backend
명령어를 사용하여 비관리형 인스턴스 그룹을 백엔드 서비스에 추가합니다. Cloud Shell에서 다음 명령어를 실행합니다.
백엔드 서비스 만들기
명령어
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
백엔드 추가
명령어
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
전달 규칙 만들기
gcloud compute forwarding-rules create
명령어를 사용하여 두 리전에서 전달 규칙을 만듭니다. Cloud Shell에서 다음 명령어를 실행합니다.
REGION_1 전달 규칙
명령어
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
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. DNS 구성
이 섹션에서는 장애 조치 라우팅 정책을 사용하여 비공개 영역과 DNS 레코드 세트를 만듭니다.
비공개 DNS 영역 만들기
gcloud dns managed-zones create
명령어를 사용하여 example.com과 같은 비공개 영역을 만듭니다. 이 영역을 사용하여 장애 조치 라우팅 정책이 있는 리소스 레코드 세트를 만듭니다. Cloud Shell에서 다음 명령어를 실행합니다.
명령어
gcloud dns managed-zones create example-com \ --dns-name example.com. --description="My private zone" \ --visibility=private --networks my-vpc
장애 조치 라우팅 정책으로 DNS 레코드 만들기
gcloud dns record-sets create
명령어를 사용하여 장애 조치 라우팅 정책으로 DNS 레코드를 만듭니다. 기본 대상은 REGION_1의 부하 분산기입니다. Cloud DNS는 지역 기반 백업 대상만 지원합니다. 백업 세트는 REGION_1 및 REGION_2 모두의 대상으로 REGION_2 부하 분산기가 있는 위치정보 정책입니다. Cloud Shell에서 다음 명령어를 실행합니다.
명령어
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
출력 예시
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. DNS 변환 테스트
장애 조치 설정을 테스트하기 전에 두 내부 부하 분산기의 IP 주소를 기록해 둡니다. Cloud Shell에서 다음 명령어를 실행합니다.
명령어
gcloud compute forwarding-rules list --filter="name:($REGION_1-ilb $REGION_2-ilb)"
출력 예시
이 예시에서 us-west1-ilb
의 IP 주소는 10.1.0.4
이고 us-east4-ilb
의 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
이제 클라이언트 인스턴스에 로그인하여 DNS 변환을 테스트합니다. 웹 콘솔에서 'Compute Engine | VM 인스턴스'
SSH 버튼을 클릭하여 콘솔에서 클라이언트 인스턴스에 로그인합니다.
이제 클라이언트 VM에서 dig
명령어를 사용하여 failover.example.com
도메인 이름을 확인합니다.
루프는 6초의 절전 타이머로 명령어를 10번 실행하도록 구성됩니다.
명령어
for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done
DNS 레코드의 TTL이 5초로 설정되어 있으므로 6초의 절전 타이머가 추가되었습니다. 절전 모드 타이머를 사용하면 각 DNS 요청에 대해 캐시되지 않은 DNS 응답을 받을 수 있습니다. 이 명령어는 실행하는 데 약 1분 정도 걸립니다.
출력에서 리소스 레코드의 기본 세트에 있는 부하 분산기의 IP 주소를 확인할 수 있습니다. 이 설정에서 이것은 us-west1 리전에 있는 부하 분산기의 IP입니다.
11. 장애 조치 테스트
REGION_1 VM에서 네트워크 태그를 삭제하여 장애 조치를 시뮬레이션합니다. 이렇게 하면 포트 80에 대한 액세스가 차단되고, 결과적으로 상태 점검이 실패하기 시작합니다.
네트워크 태그 삭제
gcloud compute instances remove-tags
명령어를 사용하여 VM에서 네트워크 태그를 삭제합니다. Cloud Shell에서 다음 명령어를 실행합니다.
명령어
gcloud compute instances remove-tags $REGION_1-instance \ --zone=$REGION_1_ZONE --tags=allow-http
상태 점검은 10초 후에 실패합니다. DNS 확인 테스트를 다시 실행합니다.
DNS 변환
클라이언트 인스턴스에서 다음 명령어를 실행합니다.
명령어
for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done
출력에서 리소스 레코드의 백업 세트에 있는 부하 분산기의 IP 주소를 확인할 수 있습니다. 이 설정에서 이것은 us-east4 리전에 있는 부하 분산기의 IP입니다.
12. 트래픽 트릭링 테스트
기본적으로 장애 조치 정책은 모든 DNS 요청에 대해 기본 엔드포인트 IP를 반환하고 기본 IP가 상태 점검에 실패한 경우에만 백업 IP를 반환합니다. Cloud DNS에서는 사용자가 기본 대상이 정상인 경우에도 Cloud DNS가 트래픽의 일부를 백업 대상으로 전송할 수 있도록 트리클 비율을 구성할 수 있습니다. 비율은 0
에서 1
사이의 값이어야 합니다. 기본값은 0
입니다.
이를 테스트하기 위해 네트워크 태그를 REGION_1 웹 서버에 다시 추가해 보겠습니다.
네트워크 태그 추가
태그를 웹 서버 VM에 다시 추가하여 기본 리전 VM에 대한 HTTP 트래픽을 허용합니다. Cloud Shell에서 다음 명령어를 실행합니다.
명령어
gcloud compute instances add-tags $REGION_1-instance \ --zone $REGION_1_ZONE --tags allow-http
10초 후에 상태 점검이 통과됩니다.
DNS 변환이 기본 부하 분산기를 가리키는지 확인합니다. 이 설정에서는 us-west1 리전에 있는 부하 분산기의 IP 주소입니다.
클라이언트 인스턴스에서 다음 명령어를 실행합니다.
명령어
dig +short failover.example.com
DNS 레코드 업데이트
이제 기본 인스턴스가 정상인 경우에도 트래픽의 30% 가 백업 세트로 전달되도록 failover.example.com
의 DNS 레코드를 수정하겠습니다. Cloud Shell에서 다음 명령어를 실행합니다.
명령어
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
DNS 변환
클라이언트 VM에서 다음 명령어를 실행합니다. DNS 레코드 failover.example.com
이 기본 부하 분산기 IP(근사치)로 확인됩니다. 약 70% 의 시간이 소요될 수 있으며 30% 입니다.
for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done
13. 정리 단계
이 실습에 사용된 리소스를 삭제하려면 CloudShell에서 다음 명령어를 실행합니다.
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. 축하합니다
수고하셨습니다. Cloud DNS 장애 조치 라우팅 정책을 성공적으로 배포하고 테스트했습니다.
학습한 내용
- Cloud DNS 장애 조치 라우팅 정책을 구성하는 방법
- DNS 장애 조치 테스트
- 트래픽을 백업 세트로 유인하는 방법
다음 단계
- 활성 및 백업 세트에 여러 IP 설정 시도
- 비관리형 인스턴스 그룹에 여러 백엔드 VM을 추가해 보세요.
- 백업 세트의 위치정보 정책에 대해 서로 다른 리전에 여러 부하 분산기를 설정해 봅니다.
자세히 알아보기
https://cloud.google.com/dns/docs/zones/manage-routing-policies