주:

이 자습서에서는 Oracle Cloud에 액세스해야 합니다. 무료 계정에 등록하려면 Oracle Cloud Infrastructure Free Tier 시작하기를 참조하십시오.
Oracle Cloud Infrastructure 자격 증명, 테넌시 및 구획에 예제 값을 사용합니다. 실습을 완료했으면 이러한 값을 자신의 클라우드 환경과 관련된 값으로 대체하십시오.

Oracle Cloud Infrastructure의 BIND9 도메인 네임 시스템에서 고가용성 구현

소개

OraStage 재생 에너지 솔루션과 혁신적인 전력 기술을 전문으로 하는 에너지 분야의 선도적인 기업인 이 회사는 성능, 확장성 및 보안을 강화하기 위해 워크로드를 Oracle Cloud Infrastructure(OCI)로 마이그레이션하는 전략적 결정을 발표했습니다.

OraStage에서 설명한 특정 요구 사항 및 조건을 고려할 때 회사는 하이브리드 DNS(Domain Name System)가 필요합니다. 클라우드의 솔루션과 하이브리드 방식은 자체 Berkeley Internet Name Domain 버전 9(BIND9) DNS 시스템을 OCI DNS 서비스와 함께 사용하는 것을 의미하며, 구축하려는 최종 아키텍처는 다음 이미지에 나와 있습니다.

OraStage DNS 요구 사항:

이 회사는 여러 내부 도메인과 하위 도메인을 보유하고 있으며, 이 모든 도메인은 OCI의 BIND9 DNS를 통해 해결되어야 하며, 여기서 OraStage는 모든 관련 영역과 레코드를 관리합니다. 이러한 도메인 중 하나는 이 자습서에서 사용할 orastage.com입니다. 따라서 orastage.com에 대한 질의를 BIND9로 전달해야 합니다.
경우에 따라 OCI 네이티브 도메인(oraclevcn.com, oraclecloud.com 등)을 계속 분석해야 하며, 이는 OCI 프라이빗 DNS 구성요소(프라이빗 뷰, 전달 끝점 및 규칙, 수신 끝점)를 사용하여 수행됩니다.
모든 질의는 pfSense 방화벽 인스턴스에서 검사해야 합니다.
단일 장애 지점을 방지하기 위해 OraStage는 다른 DNS 서버를 사용하고 OCI 로드 밸런서를 활용하여 기본 DNS와 보조 DNS 간에 쿼리를 분산할 계획입니다.

이 자습서 시리즈는 위의 요약된 요구 사항을 충족하고 전체 솔루션을 처음부터 구축할 수 있도록 단계별로 안내합니다. 아래 목록에서 각 자습서로 쉽게 이동할 수 있습니다.

자습서 1: OCI에서 BIND9 DNS를 구성합니다. BIND9를 OCI의 두 테스트 환경용 로컬 DNS 서버로 만들어 컴퓨팅 인스턴스에 설치하고 구성하는 방법을 알아봅니다. 이러한 환경은 각각 별도의 스포크 네트워크에서 호스팅되는 "프론트엔드" 및 "백엔드" 서버로 구성됩니다. BIND9 서버는 orastage.com로 지정된 모든 DNS 질의를 처리합니다.
자습서 2: OCI의 BIND9 DNS 시나리오에서 고가용성 구현. 이 사용지침서에서는 보조 BIND9 서버를 추가하고 NLB(네트워크 로드 밸런서)를 구성하여 두 서버 간에 DNS 트래픽을 분산하는 방법을 중점적으로 설명합니다. orastage.com에 대한 DNS 질의는 기본 서버와 보조 BIND9 서버 간의 로드 균형을 조정하는 NLB IP로 지정됩니다. 한 서버를 사용할 수 없게 되면 서비스 중단 없이 DNS 확인이 계속됩니다.
자습서 3: OCI DNS를 사용하여 네이티브 도메인 확인. oraclevcn.com 및 oraclecloud.com와 같은 네이티브 도메인을 분석해야 하는 경우를 대비해 OCI에서 네이티브 DNS 구성요소를 활용하는 특정 사용 사례에만 집중할 수 있습니다. BIND9 DNS는 이 자습서에서 사용되지 않습니다.
자습서 4: pfSense 방화벽을 사용하여 DNS 구조에 보안 추가. OCI의 허브 VCN에 pfSense 방화벽을 설치하는 데 중점을 두고, 검사할 방화벽을 통해 DNS 쿼리를 포함한 모든 동서 트래픽(이전 자습서에서 완료)을 라우팅하는 데 필요한 네트워크 구성을 수행합니다.

개요

오늘날의 안정적이고 효율적인 DNS 인프라는 원활한 네트워크 운영을 보장하는 데 중요합니다. 첫번째 사용지침서 Configure BIND9 Domain Name System in Oracle Cloud Infrastructure에서는 DNS 서비스를 관리할 수 있는 강력한 기능과 유연성을 제공하는 가장 널리 사용되는 DNS 소프트웨어 중 하나인 BIND9를 OCI에서 배포하고 사용하는 방법에 대해 이미 설명했습니다. 단일 BIND9 서버가 DNS 요청을 효과적으로 처리할 수 있지만, 두번째 BIND9 서버를 추가하면 네트워크의 전반적인 성능과 안정성을 향상시킬 수 있는 다양한 이점이 있습니다.

이 사용지침서에서는 이 구성의 이점을 강조하면서 보조 BIND9 서버 및 로드 밸런서를 OCI에 설정하는 프로세스를 안내합니다. 이를 구현함으로써 다음을 달성할 수 있습니다.

중복성: 기본 서버가 실패하더라도 DNS 서비스의 지속적인 가용성을 보장합니다.
로드 밸런싱: 서버 간에 DNS 쿼리 로드를 분산하여 응답 시간을 개선하고 과부하 위험을 줄입니다.
지리적 분포: 필요한 경우 DNS 서버를 다른 위치에 배치하면 전역 사용자의 응답 시간이 빨라질 수 있습니다.
보안 강화: 여러 서버에서 DNS 서비스를 분리하고 보호하여 위험을 완화합니다.

OCI 네트워크 로드 밸런서

OCI NLB(Flexible Network Load Balancer)는 수신 트래픽을 여러 백엔드 리소스에 분산하는 데 도움이 되는 서비스입니다. 이는 트래픽이 많은 볼륨을 관리하고 하나 이상의 서버에 장애가 발생하더라도 애플리케이션의 가용성과 응답성을 유지하는 데 특히 유용합니다.

OCI 네트워크 로드 밸런서는 OSI(Open Systems Interconnection) 모델의 계층 3 및 계층 4에서 작동하며 TCP(Transmission Control Protocol), UDP(User Datagram Protocol) 및 ICMP(Internet Control Message Protocol)와 같은 프로토콜을 처리합니다. 로드 밸런싱을 효율적으로 수행함으로써 응용 프로그램 성능을 향상시키고 고가용성을 제공하며 시스템의 전반적인 확장성을 향상시킬 수 있습니다. 또한 이 서비스는 백엔드 서버의 상태를 모니터링하기 위한 상태 검사와 같은 기능을 제공하여 트래픽이 정상 및 운영 인스턴스로만 전달되도록 합니다.

요약하자면, OCI 네트워크 로드 밸런서는 네트워크 트래픽을 여러 리소스에 지능적으로 배포하여 애플리케이션의 안정성과 확장성을 유지하는 데 중요한 역할을 합니다. 앞서 언급한 모든 이점으로 인해 DNS 솔루션을 최적화하기 위해 네트워크 로드 밸런서를 설정에 추가할 것입니다.

목표

OCI Network Load Balancer 및 보조 BIND9 서버를 네트워크에 원활하게 통합하여 강력하고 탄력적인 DNS 인프라를 보장합니다.
이 자습서의 주요 목적은 FE-VM 클라이언트(fe.orastage.com)가 BE-VM(be.orastage.com)을 질의할 수 있도록 하는 것입니다. 그 반대의 경우도 마찬가지입니다. DNS-NLB는 Primary-DNS(primary-dns.orastage.com)와 Secondary-DNS(secondary-dns.orastage.com) 간에 클라이언트 요청을 분배하여 모든 질의에 응답합니다.

최종 아키텍처

필요 조건

OCI 테넌시 및 필요한 네트워크 및 컴퓨트 서비스를 관리할 수 있는 권한에 액세스합니다.
OCI 네트워크 라우팅 및 보안과 기능에 대한 기본적인 이해: VCN(가상 클라우드 네트워크), 라우트 테이블, DRG(동적 라우팅 게이트웨이), 보안 목록, 배스천 및 OCI 네트워크 로드 밸런서.
OCI 로깅 서비스에 대한 기본적인 이해
일반적으로 Ubuntu Linux 및 DNS에 대한 기본적인 이해
첫번째 자습서 Configure BIND9 Domain Name System in Oracle Cloud Infrastructure을 완료하십시오. 이때 다음 아키텍처가 이미 구축되어 있어야 합니다.

작업 1: 보조 DNS 인스턴스 프로비전 및 BIND9 구성

첫번째 자습서 Configure BIND9 Domain Name System in Oracle Cloud Infrastructure을 참조하십시오. 여기서 작업 2 및 작업 3은 Primary-DNS 인스턴스의 생성 및 구성을 보여 줍니다. Secondary-DNS를 구성하려면 동일한 작업을 수행해야 합니다. 다음 정보를 고려하십시오.

인스턴스 이름은 Secondary-DNS가 됩니다.
Primary-DNS와 동일한 서브넷에 상주하며 IP 주소 10.0.0.20을 지정해야 합니다.
구성 프로세스를 통해 Primary-DNS 10.0.0.10가 언급될 때마다 Secondary-DNS 10.0.0.20로 바꿔야 합니다. 예를 들어, 이 인스턴스의 FQDN은 secondary-dns.orastage.com여야 합니다.
동일한 SSH 키를 사용합니다.
기본 DNS에 액세스하는 데 사용되는 동일한 OCI 배스천을 사용하여 보조 DNS에 액세스하지만 새 세션을 사용할 수도 있습니다.
기본 및 보조 인스턴스에 대한 /var/lib/bind/db.orastage.com 파일에서 다음 레코드가 모두 있는지 확인하여 두 DNS 서버가 FE-VM 및 BE-VM 인스턴스와 함께 서로를 확인할 수 있도록 합니다.
```
primary-dns                 IN  A       10.0.0.10
secondary-dns               IN  A       10.0.0.20
fe                          IN  A       10.1.0.5
be                          IN  A       10.2.0.5
```

이 작업이 끝나면 구조는 다음과 같아야 합니다.

작업 2: OCI 네트워크 로드 밸런서 구성

태스크 2.1: 세부정보 추가

왼쪽 상단 모서리에서 햄버거 메뉴 (≡)를 클릭합니다.
1. 네트워킹을 누릅니다.
2. 네트워크 로드 밸런서를 누릅니다.
네트워크 로드 밸런서 생성을 누릅니다.
1. 로드 밸런서 이름: 이름을 입력합니다.
2. 가시성 유형 선택: 비공개를 선택합니다.
3. 네트워킹 선택: 네트워크 로드 밸런서를 배치할 DNS-VCN 및 해당 프라이빗 서브넷을 선택합니다.
4. 다음을 누릅니다.

작업 2.2: 리스너 구성

리스너는 특정 포트(예: TCP/포트 80, UDP/포트 21)로 특정 유형의 트래픽을 수신하여 백엔드 서버로 전달하는 로드 밸런서의 필수 구성 요소입니다. 이 자습서에서는 리스너가 포트 53(TCP) 및 (UDP)에서 수신하기를 원합니다. DNS는 이 두 가지를 모두 사용합니다.

다음 정보를 입력하십시오.
1. 리스너 이름: 이름을 입력합니다.
2. 리스너가 처리하는 트래픽의 유형 지정: UDP/TCP를 선택합니다.
3. 포트를 지정합니다. 포트 번호 53을 입력합니다.
4. 다음을 누릅니다.

작업 2.3: 백엔드 집합 선택

백엔드 집합은 네트워크 로드 밸런서가 트래픽 경로를 지정하는 백엔드 서버의 논리적 그룹입니다. 여기에 있는 백엔드 서버는 기본 DNS 및 보조 DNS가 됩니다.

다음 정보를 입력하십시오.
1. 백엔드 집합 이름: 백엔드 집합 이름을 입력합니다.
2. 백엔드 추가를 누릅니다.
3. 백엔드 유형: 컴퓨트 인스턴스를 선택합니다.
4. 백엔드 IPv4 컴퓨트 인스턴스: DNS 서버 기본 DNS와 보조 DNS를 모두 선택합니다.
5. 백엔드 추가를 누릅니다.
6. 백엔드 서버가 집합에 추가된 것을 확인할 수 있습니다.
7. 건전성 검사 정책 지정: 건전성 검사 정책은 요청을 하거나 접속을 시도하여 백엔드 서버의 가용성을 확인하는 데 사용됩니다. 네트워크 로드 밸런서는 지정된 정기적으로 이러한 상태 검사를 수행합니다. 이 정책을 사용하여 백엔드 서버의 상태를 지속적으로 모니터합니다.
8. 다음을 누릅니다.

작업 2.4: 검토 및 생성

모든 세부정보를 검토하고 네트워크 로드 밸런서 생성을 누릅니다.
DNS-NLB가 만들어졌으며 작업 3에서 사용할 수 있으므로 개인 IP 주소를 기록해 둡니다.

작업 2.5: 보안 규칙 추가

건전성 검사 실패를 방지하고 트래픽 중단 없이 원활한 통신을 보장합니다.

DNS-Private-Subnet 보안 목록에 다음 규칙을 추가합니다. 그러면 네트워크 로드 밸런서에서 백엔드로 전송된 DNS 트래픽이 허용됩니다.
아키텍처는 다음 그림과 같이 표시되어야 합니다.

작업 3: OCI DNS 전달 규칙 구성

작업 3.1: 프론트엔드-VCN 전달 규칙 구성

왼쪽 상단 모서리에서 햄버거 메뉴 (≡)를 클릭합니다.
1. 네트워킹을 누릅니다.
2. 가상 클라우드 네트워크를 누릅니다.
Frontend-VCN을 누릅니다.
VCN의 DNS 분석기를 누릅니다.
아래로 이동
1. 규칙을 누릅니다.
2. 규칙 관리를 누릅니다.
3. 대상 IP 주소를 Primary-DNS IP 주소에서 작업 2에서 만든 DNS-NLB IP 주소(10.0.0.110)로 변경합니다.
4. 변경사항 저장을 누릅니다.
5. 대상 IP 주소가 성공적으로 변경되었습니다. 따라서 이제 FE-VM의 모든 질의가 DNS-NLB IP 주소로 전달되어 기본 DNS 서버와 보조 DNS 서버 간에 분산됩니다.

작업 3.2: 백엔드-VCN 전달 규칙 구성

왼쪽 상단 모서리에서 햄버거 메뉴 (≡)를 클릭합니다.
1. 네트워킹을 누릅니다.
2. 가상 클라우드 네트워크를 누릅니다.
백엔드-VCN을 누릅니다.
VCN의 DNS 분석기를 누릅니다.
아래로.
1. 규칙을 누릅니다.
2. 규칙 관리를 누릅니다.
3. 대상 IP 주소를 Primary-DNS IP 주소에서 작업 2에서 만든 DNS-NLB IP 주소(10.0.0.110)로 변경합니다.
4. 변경사항 저장을 누릅니다.
5. 대상 IP 주소가 성공적으로 변경되었습니다. 따라서 이제 BE-VM의 모든 질의가 DNS-NLB IP 주소로 전달되어 기본 및 보조 DNS 서버 간에 분산됩니다.

작업 4: 테스트 및 검증

필요 조건

로그 사용: 트래픽 플로우를 확인하기 위해 서브넷 플로우 로그를 사용으로 설정하여 특정 서브넷에 들어오거나 나가는 네트워크 트래픽을 모니터하고 추적할 수 있습니다. 이러한 로그는 소스 및 대상 IP 주소, 포트 번호 및 전송 중인 데이터 양과 같은 네트워크 트래픽에 대한 세부정보를 캡처합니다. 로그를 사용으로 설정하려면 다음 단계를 수행하십시오.
1. 기본 DNS, 보조 DNS 및 DNS-NLB가 상주하는 DNS-VCN 전용 서브넷으로 이동합니다.
2. 로그를 누릅니다.
3. 로그 사용을 선택합니다.
OCI에서 로그 및 로그 활용 방법에 대한 자세한 내용은 다음을 참조하십시오.
- VCN 플로우 로그.
- VCN 플로우 로그에 대한 세부정보 - 로그 콘텐츠를 읽는 방법을 알아봅니다.
- OCI 내부의 허브 및 스포크 VCN 라우팅 아키텍처에서 패킷 팔로우하기 - 방화벽 패킷 캡처, 서브넷 로그, TCPdump 등 다양한 방법을 사용하여 OCI 환경에서 네트워크 패킷을 추적하는 방법을 알아보는 유용한 사용지침서입니다. 작업 6 및 작업 13을 따릅니다.
  - 작업 6: 스포크 A 프라이빗 서브넷에서 로깅(모든 로그)을 사용으로 설정합니다.
  - 작업 13: 모든 로깅 지점 및 패킷 캡처를 살펴보고 경로 - 로깅 지점 B를 따르십시오.

이제 이 서브넷에 대한 모든 수신 및 송신 트래픽이 기록됩니다.

테스트 시나리오 1: 보조 DNS가 작동 중지될 때 기본 DNS가 FE-VM 질의에 응답함

Secondary-DNS에서 오류가 발생할 경우 DNS-NLB가 트래픽을 전달하므로 Primary-DNS가 FE-VM에서 오는 질의에 응답하는지 확인해야 합니다.

다음 이미지는 우리가 달성하고자 하는 테스트 시나리오를 보여줍니다.
현재 모든 인스턴스가 작동되어 실행 중입니다. 먼저 보조 DNS 인스턴스를 종료합니다. 왼쪽 상단 모서리에서 햄버거 메뉴 (≡)를 클릭합니다.
1. Compute(컴퓨트)를 누릅니다.
2. 인스턴스를 누릅니다.
1. 인스턴스 옆에 있는 체크박스를 선택합니다.
2. 작업을 누릅니다.
3. 정지를 누릅니다.
4. 정지를 누릅니다.
5. 인스턴스가 이제 정지됨 상태입니다.
FE-VM에 액세스하여 질의를 실행하여 테스트를 수행합니다. 이를 위해 OCI Bastion 서비스를 사용합니다. 왼쪽 상단 모서리에서 햄버거 메뉴 (≡)를 클릭합니다.
1. ID 및 보안을 누릅니다.
2. 배스천을 누릅니다.
FEBastion을 누릅니다.
세션 생성을 누릅니다.
다음 정보를 입력하십시오.
1. 세션 유형: Managed SSH session을 선택합니다.
2. 세션 이름: 세션의 이름을 입력합니다.
3. 사용자 이름: 사용자 이름을 입력하십시오. Oracle Linux 인스턴스의 경우 기본 사용자 이름은 opc입니다.
4. 컴퓨트 인스턴스: FE-VM 인스턴스를 선택합니다.
5. 자습서 1에서 생성된 것과 동일한 퍼블릭 키를 붙여넣습니다. 작업 2.1: SSH 키 쌍 생성
6. 세션 생성을 누릅니다.

세션이 생성된 후 세 개의 점과 Copy SSH command를 누릅니다.

명령은 다음과 같아야 합니다.

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5aiaxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzo2q7dka@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.1.0.5

OCI Cloud Shell을 엽니다.
1. cd .ssh 명령을 사용하여 .ssh 디렉토리로 이동합니다.
2. SSH 명령을 붙여넣습니다. <privateKey>를 개인 키 파일 이름 id_rsa로 바꿔야 합니다.
3. yes를 입력합니다.
성공적으로 로그인되었습니다. 이제 host 명령을 사용하여 FE-VM에서 be.orastage.com까지 테스트 질의를 수행합니다. query가 성공하고 응답이 수신되었는지 확인합니다.
요청을 처리할 정상 백엔드 서버는 기본 DNS 하나만 있습니다. 이제 DNS 쿼리의 흐름을 확인하고 OCI 서브넷 로그를 사용하여 해당 쿼리에 어떤 서버가 응답했는지 확인할 것입니다.
1. 로그를 누릅니다.
2. 요청은 FE-VM과 동일한 서브넷에 있는 Forwarding Endpoint(10.1.0.6)에서 DNS-VCN의 NLB IP 주소(10.0.0.110)로 이동했습니다.
3. 그런 다음 NLB IP 주소(10.0.0.110)에서 요청이 Primary-DNS(10.0.0.10)로 전송됩니다.
테스트를 성공했습니다. Primary-DNS는 Secondary-DNS의 작동이 중지된 경우 DNS 쿼리를 처리할 수 있었습니다.

테스트 시나리오 2: 1차 DNS가 작동 중지될 때 2차 DNS가 FE-VM 질의에 응답함

Primary-DNS에서 오류가 발생할 경우 DNS-NLB가 트래픽을 지정하므로 Secondary-DNS가 FE-VM에서 오는 질의에 응답하도록 해야 합니다.

다음 이미지는 우리가 달성하고자 하는 테스트 시나리오를 보여줍니다.
먼저 기본 DNS 인스턴스를 종료합니다. 왼쪽 상단 모서리에서 햄버거 메뉴 (≡)를 클릭합니다.
1. Compute(컴퓨트)를 누릅니다.
2. 인스턴스를 누릅니다.
1. 인스턴스 옆에 있는 체크박스를 선택합니다.
2. 작업을 누릅니다.
3. 정지를 누릅니다.
4. 정지를 누릅니다.
5. 인스턴스가 이제 정지됨 상태입니다.
Secondary-DNS 인스턴스를 시작합니다.
1. 인스턴스 옆에 있는 체크박스를 선택합니다.
2. 작업을 누릅니다.
3. 시작을 누릅니다.
4. 시작을 누릅니다.
5. 인스턴스가 이제 실행 중 상태입니다.
다음으로 FE-VM에 액세스하여 질의를 실행하여 테스트를 수행합니다. 이를 위해 OCI Bastion 서비스를 사용합니다. 왼쪽 상단 모서리에서 햄버거 메뉴 (≡)를 클릭합니다.
1. ID 및 보안을 누릅니다.
2. 배스천을 누릅니다.
FEBastion을 누릅니다.
세션 생성을 누릅니다.
다음 정보를 입력하십시오.
1. 세션 유형: Managed SSH session을 선택합니다.
2. 세션 이름: 세션의 이름을 입력합니다.
3. 사용자 이름: 사용자 이름을 입력하십시오. Oracle Linux 인스턴스의 경우 기본 사용자 이름은 opc입니다.
4. 컴퓨트 인스턴스: FE-VM 인스턴스를 선택합니다.
5. 자습서 1에서 생성된 것과 동일한 퍼블릭 키를 붙여넣습니다. 작업 2.1: SSH 키 쌍 생성
6. 세션 생성을 누릅니다.

세션이 생성된 후 세 개의 점과 Copy SSH command를 누릅니다.

명령은 다음과 같아야 합니다.

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5axxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzo2q7dka@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.1.0.5

OCI Cloud Shell을 엽니다.
1. cd .ssh 명령을 사용하여 .ssh 디렉토리로 이동합니다.
2. SSH 명령을 붙여넣습니다. <privateKey>를 개인 키 파일 이름 id_rsa로 바꿔야 합니다.
3. yes를 입력합니다.
성공적으로 로그인되었습니다. 이제 host 명령을 사용하여 FE-VM에서 be.orastage.com까지 테스트 질의를 수행합니다. query가 성공하고 응답이 수신되었는지 확인합니다.
요청을 처리할 정상 백엔드 서버는 보조 DNS가 하나뿐임을 알고 있습니다. 이제 DNS 쿼리의 흐름을 확인하고 OCI 서브넷 로그를 사용하여 해당 쿼리에 어떤 서버가 응답했는지 확인할 것입니다.
1. 로그를 누릅니다.
2. 요청은 FE-VM과 동일한 서브넷에 있는 Forwarding Endpoint(10.1.0.6)에서 DNS-VCN의 NLB IP 주소(10.0.0.110)로 이동했습니다.
3. 그런 다음 NLB(10.0.0.110)에서 요청이 보조 DNS(10.0.0.20)로 전송됩니다.
테스트를 성공했습니다. Secondary-DNS는 Primary-DNS가 다운된 경우 DNS 쿼리를 처리할 수 있습니다.

테스트 시나리오 3: 보조 DNS가 작동 중지될 때 기본 DNS가 BE-VM 질의에 응답함

Secondary-DNS에서 오류가 발생할 경우 DNS-NLB가 트래픽을 전달하므로 Primary-DNS가 BE-VM에서 가져온 쿼리에 응답하는지 확인해야 합니다.

다음 이미지는 우리가 달성하고자 하는 테스트 시나리오를 보여줍니다.
현재 모든 인스턴스가 작동되어 실행 중입니다. 먼저 보조 DNS 인스턴스를 종료합니다. 왼쪽 상단 모서리에서 햄버거 메뉴 (≡)를 클릭합니다.
1. Compute(컴퓨트)를 누릅니다.
2. 인스턴스를 누릅니다.
1. 인스턴스 옆에 있는 체크박스를 선택합니다.
2. 작업을 누릅니다.
3. 정지를 누릅니다.
4. 정지를 누릅니다.
5. 인스턴스가 이제 정지됨 상태입니다.
다음으로 BE-VM에 액세스하여 질의를 실행하여 테스트를 수행합니다. 이를 위해 OCI Bastion 서비스를 사용합니다. 왼쪽 상단 모서리에서 햄버거 메뉴 (≡)를 클릭합니다.
1. ID 및 보안을 누릅니다.
2. 배스천을 누릅니다.
BEBastion을 누릅니다.
세션 생성을 누릅니다.
다음 정보를 입력하십시오.
1. 세션 유형: Managed SSH session을 선택합니다.
2. 세션 이름: 세션의 이름을 입력합니다.
3. 사용자 이름: 사용자 이름을 입력하십시오. Oracle Linux 인스턴스의 경우 기본 사용자 이름은 opc입니다.
4. 컴퓨트 인스턴스: BE-VM 인스턴스를 선택합니다.
5. 자습서 1에서 생성된 것과 동일한 퍼블릭 키를 붙여넣습니다. 작업 2.1: SSH 키 쌍 생성
6. 세션 생성을 누릅니다.

세션이 생성된 후 세 개의 점과 Copy SSH command를 누릅니다.

명령은 다음과 같아야 합니다.

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5axxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxuk7pafla@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.2.0.5

OCI Cloud Shell을 엽니다.
1. cd .ssh 명령을 사용하여 .ssh 디렉토리로 이동합니다.
2. SSH 명령을 붙여넣습니다. <privateKey>를 개인 키 파일 이름 id_rsa로 바꿔야 합니다.
3. yes를 입력합니다.
성공적으로 로그인되었습니다. 이제 host 명령을 사용하여 BE-VM에서 fe.orastage.com까지 테스트 질의를 수행합니다. query가 성공하고 응답이 수신되었는지 확인합니다.
요청을 처리할 정상 백엔드 서버는 기본 DNS 하나만 있습니다. 이제 DNS 쿼리의 흐름을 확인하고 OCI 서브넷 로그를 사용하여 해당 쿼리에 어떤 서버가 응답했는지 확인할 것입니다.
1. 로그를 누릅니다.
2. 요청은 BE-VM과 동일한 서브넷에 있는 Forwarding Endpoint(10.2.0.6)에서 DNS-VCN의 NLB IP 주소(10.0.0.110)로 이동했습니다.
3. 그런 다음 NLB(10.0.0.110)에서 요청이 Primary-DNS(10.0.0.10)로 전송됩니다.
테스트를 성공했습니다. Primary-DNS는 Secondary-DNS의 작동이 중지된 경우 DNS 쿼리를 처리할 수 있었습니다.

테스트 시나리오 4: 1차 DNS가 작동 중지될 때 2차 DNS가 BE-VM 질의에 응답함

Primary-DNS에서 오류가 발생할 경우 DNS-NLB가 트래픽을 전달하므로 Secondary-DNS가 BE-VM에서 오는 질의에 응답하도록 해야 합니다.

다음 이미지는 우리가 달성하고자 하는 테스트 시나리오를 보여줍니다.
먼저 기본 DNS 인스턴스를 종료합니다. 왼쪽 상단 모서리에서 햄버거 메뉴 (≡)를 클릭합니다.
1. Compute(컴퓨트)를 누릅니다.
2. 인스턴스를 누릅니다.
1. 인스턴스 옆에 있는 체크박스를 선택합니다.
2. 작업을 누릅니다.
3. 정지를 누릅니다.
4. 정지를 누릅니다.
5. 인스턴스가 이제 정지됨 상태입니다.
Secondary-DNS 인스턴스를 시작합니다.
1. 인스턴스 옆에 있는 체크박스를 선택합니다.
2. 작업을 누릅니다.
3. 시작을 누릅니다.
4. 시작을 누릅니다.
5. 인스턴스가 이제 실행 중 상태입니다.
다음으로 BE-VM에 액세스하여 질의를 실행하여 테스트를 수행합니다. 이를 위해 OCI Bastion 서비스를 사용합니다. 왼쪽 상단 모서리에서 햄버거 메뉴 (≡)를 클릭합니다.
1. ID 및 보안을 누릅니다.
2. 배스천을 누릅니다.
BEBastion을 누릅니다.
세션 생성을 누릅니다.
다음 정보를 입력하십시오.
1. 세션 유형: Managed SSH session을 선택합니다.
2. 세션 이름: 세션의 이름을 입력합니다.
3. 사용자 이름: 사용자 이름을 입력하십시오. Oracle Linux 인스턴스의 경우 기본 사용자 이름은 opc입니다.
4. 컴퓨트 인스턴스: BE-VM 인스턴스를 선택합니다.
5. 자습서 1에서 생성된 것과 동일한 퍼블릭 키를 붙여넣습니다. 작업 2.1: SSH 키 쌍 생성
6. 세션 생성을 누릅니다.

세션이 생성된 후 세 개의 점과 Copy SSH command를 누릅니다.

명령은 다음과 같아야 합니다.

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5aia73xcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxa@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.2.0.5

OCI Cloud Shell을 엽니다.
1. cd .ssh 명령을 사용하여 .ssh 디렉토리로 이동합니다.
2. SSH 명령을 붙여넣습니다. <privateKey>를 개인 키 파일 이름 id_rsa로 바꿔야 합니다.
3. yes를 입력합니다.
성공적으로 로그인되었습니다. 이제 host 명령을 사용하여 BE-VM에서 fe.orastage.com까지 테스트 질의를 수행합니다. query가 성공하고 응답이 수신되었는지 확인합니다.
요청을 처리할 정상 백엔드 서버는 보조 DNS가 하나뿐임을 알고 있습니다. 이제 DNS 쿼리의 흐름을 확인하고 OCI 서브넷 로그를 사용하여 해당 쿼리에 어떤 서버가 응답했는지 확인할 것입니다.
1. 로그를 누릅니다.
2. 요청은 BE-VM과 동일한 서브넷에 있는 Forwarding Endpoint(10.2.0.6)에서 DNS-VCN의 NLB IP 주소(10.0.0.110)로 이동했습니다.
3. 그런 다음 NLB(10.0.0.110)에서 요청이 보조 DNS(10.0.0.20)로 전송됩니다.
테스트를 성공했습니다. Secondary-DNS가 Primary-DNS의 작동이 중지된 경우 DNS 쿼리를 처리할 수 있었습니다.

다음 단계

이 사용지침서에서는 OCI 네트워크 로드 밸런서와 보조 DNS 서버를 통합하여 OCI에서 설정되는 간단한 클라이언트-서버 BIND9 DNS를 개선하여 기본 서버 장애 발생 시 지속적인 서비스 가용성을 보장합니다.

지금까지 orastage.com 도메인 쿼리를 처리하기 위한 고성능의 안정적인 DNS 아키텍처를 개발했습니다. 그러나 OraStage 회사에서는 oraclevcn.com 및 oraclecloud.com와 같은 OCI 고유 도메인 이름도 확인해야 합니다. 이를 위해서는 추가 단계가 필요합니다. 다음 사용지침서인 OCI DNS를 사용하여 네이티브 도메인 해결에서는 이 구성을 달성하는 방법을 시연합니다.

확인

작성자 - Anas abdallah(클라우드 네트워킹 전문가)

추가 학습 자원

docs.oracle.com/learn에서 다른 실습을 탐색하거나 Oracle Learning YouTube 채널에서 더 많은 무료 학습 콘텐츠에 액세스하세요. 또한 Oracle Learning Explorer가 되려면 education.oracle.com/learning-explorer을 방문하십시오.

제품 설명서는 Oracle Help Center를 참조하십시오.

제목 및 저작권 정보

Implement High Availability on BIND9 Domain Name System in Oracle Cloud Infrastructure

G14456-02