GSLB 개요 #
오늘날 IT 서비스의 높은 가용성은 필수이며, 이것이 바로 기업과 조직이 전 세계에 분산된 컴퓨팅 시스템을 개발하고 여러 데이터 센터에서 서비스를 호스팅하는 이유입니다. 이는 다음과 같은 이점을 제공하기 때문입니다.
결함 허용: 데이터 센터에 호스팅된 서비스에 장애가 발생하면 사용 가능한 다른 사이트에서 서비스가 계속 진행됩니다.
자동 데이터 센터 복구: 한 데이터 센터에 장애가 발생하면 서비스는 사용 가능한 다른 데이터 센터로 자동으로 리디렉션됩니다.
로드 균형 조정: 모든 사이트에 부하를 분산시켜 트래픽을 최적화하고, 지연 시간을 개선하며 서비스 제공을 더 빠르게 할 수 있습니다.
향상된 지연 시간: 클라이언트 애플리케이션 트래픽이 실제 서버와 직접 이루어지므로 모든 애플리케이션 데이터를 로드 밸런서를 통해 전달할 필요가 없습니다.
클라우드에서 IT 서비스를 도입하고 구현하려면 지리적으로 위치한 고가용성 솔루션을 제공하는 데 있어 WAN 기반 방식이 최선의 선택이어야 합니다. 이를 우리는 "WAN 기반"이라고 부릅니다. 글로벌 서비스 부하 분산 or GSLB.
GSLB를 사용할 때 #
GSLB 서비스는 다음과 같은 사용 사례에 사용하는 것이 좋습니다.
WAN을 통해 두 개 이상의 데이터 센터에서 서비스를 호스팅하는 회사.
서비스나 데이터 센터의 고가용성을 구축해야 하는 회사.
인터넷 서비스 제공자는 사용자가 사용할 인바운드 로드 밸런싱 서비스를 만듭니다.
확실히, 장애 지점 없이 전 세계의 서버 간에 사용자와 트래픽을 공유해야 하는 경우 GSLB가 적합한 솔루션입니다.
GSLB는 어떻게 작동합니까? #
GSLB 부하 분산 메커니즘입니다 DNS 프로토콜은 빠르고 안정적입니다. UDP 프로토콜과 클라이언트 응답이 거의 실시간입니다.
예를 들어 일반적인 DNS 요청에서 www.zvnlb.net, 클라이언트는 DNS 요청 확인을 로컬로 구성된 DNS 서버(예: 8.8.8.8 8.8.4.4 ) 그런 다음 클라이언트 시스템은 요청에 대해 무작위로 서버 중 하나를 선택하고 쿼리를 보냅니다.
선택된 DNS 서버는 클라이언트로부터 요청을 수신합니다(예: IP 주소는 무엇입니까? www.zvnlb.net? ) 및 로컬로 구성된 DNS 서버는 DNS 영역을 확인할 책임이 있는 사람을 찾으려고 합니다. zvnlb.net.
클라이언트가 사용하는 DNS 8.8.8.8 or 8.8.4.4 이 경우에는 다음을 감지합니다. ns1.zvnlb.net ns2.zvnlb.net 영역 해결에 대한 책임이 있습니다 zvnlb.net 그래서 그들은 클라이언트가 받은 DNS 쿼리를 보냅니다(예를 들어, IP 주소는 무엇입니까? www.zvnlb.net? ) 그 중 한 명에게.
네임 서버 중 하나 ns1.zvnlb.net or ns2.zvnlb.net DNS 쿼리를 수신합니다 8.8.8.8 or 8.8.4.4 그리고 요청을 수신한 네임 서버는 호스트에 사용 가능한 서버를 확인합니다. www.zvnlb.net 그리고 호스트의 실제 애플리케이션을 제공하기 위해 사용 가능한 애플리케이션 서버 목록으로 DNS 쿼리에 응답합니다. www.zvnlb.net따라서 이 정보는 최종적으로 클라이언트에게 전달됩니다.
이제 클라이언트는 DNS 쿼리에서 수신한 목록에서 임의로 애플리케이션 서버 중 하나를 선택하고 해당 요청을 애플리케이션에 직접 전송합니다. http://www.zvnlb.net.
네임 서버 ns1.zvnlb.net (우리의 예에서는 프랑크푸르트에 위치) ns2.zvnlb.net (예시에서는 토론토에 위치) 호스트의 실제 애플리케이션의 상태를 꾸준히 점검하고 있습니다. www.zvnlb.net (192.235.113.3 194.23.52.21 우리의 경우). ns1.zvnlb.net or ns2.zvnlb.net 일부 실제 서버의 상태를 점검하는 중 문제가 감지되면 사용할 수 없는 서버는 일정 시간 동안 비활성화되고 해당 IP 주소는 다시 사용 가능해질 때까지 DNS 쿼리에 나열되지 않습니다.
다음 다이어그램은 GSLB 기능을 갖춘 DNS 트래픽을 보여줍니다.
데이터 센터 재해 복구를 위한 GSLB 구성 #
이 구성은 재해 복구를 위해 높은 데이터 센터 가용성이 필요한 서비스에 권장됩니다. 즉, 특정 회사의 모든 서비스가 하나의 데이터 센터에 있고 해당 데이터 센터에 장애가 발생하면 시스템은 영향을 받는 모든 서비스를 사용 가능한 다른 데이터 센터로 이동합니다.
재해 복구를 위한 액티브-패시브 데이터 센터를 구축하려면 GSLB 구성의 실제 예를 따르세요.
우리는 두 개를 배치했습니다 RELIANOID 프랑크푸르트의 다른 사이트에 있는 두 개의 데이터 센터에 걸친 로드 밸런서 159.89.7.124 그리고 토론토 159.203.12.35 그리고 우리는 DNS 호스트에 응답하는 웹 서비스를 가지고 있습니다. www.zvnlb.net, 구성됨 데이터 센터 1 데이터 센터 2. 이 아키텍처의 설계는 모든 클라이언트 트래픽을 다음으로 보낼 수 있도록 허용합니다. 데이터 센터 1 하지만 실패하면 클라이언트를 다음으로 리디렉션합니다. 데이터 센터 2.
이 구성을 달성하려면 아래 절차를 따르세요.
에 연결 RELIANOID 웹 패널에서 데이터 센터 1 (우리의 경우 프랑크푸르트) 메인 메뉴를 클릭하세요 GSLB 모듈을 만들고 새 모듈을 만듭니다. 농장, 우리의 예에서는 호출됩니다 DNS1-프랑크푸르트 가상 포트에서 53.
농장이 생성되면 편집하고 탭으로 이동하세요. 영역 그리고 이 경우 GSLB 모듈에서 관리할 DNS 영역을 생성합니다. zvnlb.net, 다음과 같이 :
이 영역을 만든 후 아래에 표시된 대로 첫 번째 구성을 하세요.
참고 ns1 ns2 해당 영역의 DNS 확인을 담당하는 이름 서버입니다. zvnlb.net (우리의 경우 프랑크푸르트에 GSLB 서비스가 하나 있고 토론토에 또 하나가 있습니다).
그런 다음 연결하세요 RELIANOID 데이터 센터 2의 웹 패널에서 메인 메뉴를 선택하세요 GSLB 새로운 농장우리의 경우에는 라고 불릴 것입니다. DNS2-토론토 가상 포트에서 53.
새로운 GSLB 팜을 편집하고 탭으로 이동하세요. 영역, 이 GSLB 서비스에서 관리할 DNS 영역을 여기에 생성합니다. zvnlb.net 다음과 같이 :
새로운 영역이 생성되면 다음과 같이 첫 번째 구성을 하세요.
GSLB의 경우와 같이 데이터 센터 1, 네임 서버 n1 n2 두 가지 모두 GSLB 서비스를 가리킵니다. 데이터 센터 1 데이터 센터 2각각.
그런 다음 탭을 클릭하세요 서비스 예를 들어 새로운 서비스를 생성합니다. 웹 우선순위:
선택 암호알고리즘 option 우선순위: 항상 가장 우선적으로 사용 가능한 연결 다음과 같이 서비스를 구성하세요.
변경 사항을 적용하려면 팜을 다시 시작하세요. 두 데이터 센터 모두에 동일한 GSLB 서비스 구성을 적용해야 합니다.
만약 농장 수호자 상태 검사를 적용하도록 구성되지 않은 경우 GSLB 서비스는 기본값을 사용합니다. check_tcp 서비스 구성의 상태 점검 필드에 정의된 TCP 포트로.
새로운 서비스를 활성화하려면 생성된 영역으로 이동하세요(zvnlb.net 우리의 경우) 그리고 새로운 것을 만듭니다 자원. 그런 다음 새 항목을 선택하여 만듭니다. 예배 아래에 표시된 대로입니다.
마지막으로 변경 사항을 저장하세요. 이 구성은 두 데이터 센터 모두에 적용해야 합니다.
이 시점에서 호스트 www.zvnlb.net GSLB 모듈에서 관리됩니다. 우선 모드이므로 모든 트래픽이 다음으로 전송됩니다. 데이터 센터 1 그리고 실패하면 트래픽은 다른 사용 가능한 곳으로 리디렉션됩니다. 데이터 센터 2.
TTL은 5로 설정되었습니다. 이는 DNS 레코드에 기록되는 만료일과 같은 종류입니다. TTL은 재귀 서버 또는 로컬 리졸버가 해당 레코드를 캐시에 얼마나 오래 보관해야 하는지 알려줍니다. 따라서 TTL 값을 낮게 설정하면 변경 사항을 더 빨리 감지할 수 있습니다.
이 방법을 적용하면 GSLB 서비스에 새로운 네임 서버를 포함하여 필요한 만큼 많은 데이터 센터를 추가할 수 있습니다.
다음 DNS 요청은 네임서버 구성을 보여줍니다. zvnlb.net 그리고 호스트에 대한 DNS 확인 www.zvnlb.net.
user@client:# host -t ns zvnlb.net zvnlb.net 네임 서버 ns2.zvnlb.net. zvnlb.net 네임 서버 ns1.zvnlb.net.
두 네임서버 모두 GSLB 팜에 구성된 가상 IP 주소를 사용합니다.
이제 현재 DNS 서버를 사용하여 호스트를 확인합니다(예: WWW) 이 구역에서:
user@client:# nslookup www.zvnlb.net 서버: 8.8.8.8 주소: 8.8.8.8#53 권한 없는 답변: 이름: www.zvnlb.net 주소: 188.166.230.211
표시된 대로 현재 호스트 188.166.230.211 활성 실제 애플리케이션 노드는 다음과 같습니다. 데이터 센터 1. 호스트에 접근할 수 없게 되면(예: http 서비스) 188.166.230.211 (다운되면) DNS 확인이 아래와 같이 변경됩니다.
user@client:# nslookup www.zvnlb.net 서버: 8.8.8.8 주소: 8.8.8.8#53 권한 없는 답변: 이름: www.zvnlb.net 주소: 139.59.186.84
애플리케이션 서버에 장애가 발생하면 DNS 확인이 호스트를 다음으로 변경합니다. 데이터 센터 2. 호스트가 데이터 센터 1 장애 복구가 자동으로 적용됩니다.
액티브-액티브 데이터 센터를 위한 GSLB 구성 #
모드 우선순위를 적용한 고가용성은 재해 복구 시스템에 적합한 옵션이지만, 복구에 사용되는 백업 데이터 센터는 사용량이 많지 않으므로 일반적으로 사용 가능한 데이터 센터 간에 모든 트래픽의 부하를 분산하는 것이 더 효율적입니다.
이러한 경우 GSLB 서비스에 대한 공유 방법을 사용하세요. 라운드 로빈 로드 밸런싱 새로운 서비스에 대한 예에서 보여지는 것처럼 웹:
이제 영역에 추가하세요 zvnlb.net 리소스 구성을 변경합니다 WWW 다음과 같이 :
변경 사항을 저장하고 요청 시 팜을 다시 시작합니다.
테스트하려면 호스트를 확인해 보세요. www.zvnlb.net 출력은 다음과 같습니다.
user@client:# nslookup www.zvnlb.net 서버: 8.8.8.8 주소: 8.8.8.8#53 권한 없는 답변: 이름: www.zvnlb.net 주소: 188.166.230.211 이름: www.zvnlb.net 주소: 139.59.186.84
DNS 확인자는 재해 복구의 경우처럼 하나만 반환하는 것이 아니라 두 개의 애플리케이션 서버를 모두 반환한다는 점에 유의하세요.
호스트에 장애가 발생하면 DNS 확인이 자동으로 변경됩니다. 아래에서 어떤 일이 일어나는지 확인하세요.
root@client:# nslookup www.zvnlb.net 서버: 8.8.8.8 주소: 8.8.8.8#53 권한이 없는 답변: 이름: www.zvnlb.net 주소: 139.59.186.84
사용할 수 없는 애플리케이션 서버는 DNS 응답 목록에서 비활성화됩니다.
호스트가 188.166.230.211 다시 사용할 수 있게 되면 DNS 확인에 다시 포함됩니다.
영역 위임 RELIANOID GSLB 서비스 #
공공 구역의 경우(예: zvnlb.net)는 해당 도메인의 공용 DNS 서버에서 인식되어야 하는 네임 서버 리졸버 역할을 하는 GSLB 서비스를 제공하는 경우, GSLB 서비스가 사용하는 공용 IP 주소를 도메인 등록기관(NameCheap, Goddady 등)에 등록해야 합니다. 다음 링크에서는 도메인 등록 절차에서 GSLB IP를 네임 서버로 등록하는 방법을 설명합니다.
주어진 절차에 따라 등록해야 합니다. ns1.zvnlb.net ns2.zvnlb.net 주어진 IP를 사용하여.
GSLB를 위한 전용 하위 구역 생성 #
DNS 확인을 GSLB 서비스에 위임할 수 없는 경우 RELIANOID아래 설명된 구성을 수행할 수 있습니다. 다음 예에서는 빌드 방법을 보여줍니다. 하위 구역 을 통한 zvnlb.net 이는 GSLB 서비스의 새로운 하위 영역의 네임서버를 가리킵니다.
노드 1 (예를 들면 ns1.zvnlb.net IP로 162.243.5.109) and 노드 2 (예를 들면 ns2.zvnlb.net IP로 178.62.233.104) 네임서버가 구성되어 해당 영역에 대한 DNS 확인 서비스를 제공합니다. zvnlb.net, 이 영역은 Bind9 공용 DNS 서비스에 속하며 인프라의 일부 호스트에 GSLB 기능을 제공하고자 하므로 DNS 하위 영역을 생성하기로 결정했습니다. cluster.zvnlb.net 이 목적을 위해 DNS 네임서버와 같은 2개의 GSLB 팜을 구성합니다.
우리는 도메인에 대한 하위 영역을 생성했습니다. cluster.zvnlb.net Bind9 DNS 서버에서는 다음과 같습니다.
이제 섹션을 따르세요 영역 위임 RELIANOID GSLB 서비스 유지하기 위해 159.89.7.124 159.203.12.35 우리의 예에서는 영역에 대한 인식된 네임서버로서 cluster.zvnlb.net 공용 DNS 서버를 통해.
그런 다음 도메인에 대해 설명된 것과 같은 구성을 적용할 수 있습니다. zvnlb.net 위 섹션에서 데이터 센터 재해 복구를 위한 GSLB 구성.
GSLB 서비스를 참조하는 자체 DNS의 호스트를 가리킴 #
이전 섹션에서 우리는 다음과 같은 이름의 호스트를 생성했습니다. www.zvnlb.net 우선순위 및 라운드 로빈 모드에서 부하 분산을 수행하므로 이 구성을 재사용하여 기본적으로 이 기능을 지원하지 않는 다른 DNS 네임 서버에 GSLB 기능을 제공할 수 있습니다.
이 구성을 달성하려면 새 것을 생성하기만 하면 됩니다. 자원 GSLB 옵션을 지원하지 않는 DNS 영역에서(예: 렐리아노이드.io Bind9)에 의해 관리됩니다 정식 이름 or CNAME 아래에 표시된 대로:
변경 사항이 적용되면 www.relianoid.io 가리킬 것이다 www.zvnlb.net, 하지만 호스트 해상도가 www.zvnlb.net 그러면 자동으로 변경됩니다 www.relianoid.io 도 바뀔 것입니다.
이 예제는 Bind9 DNS 서버에서 수행되었지만 정식 이름 또는 CNAME은 모든 DNS 서버 서비스 구현에서 지원되는 DNS 호스트 구성입니다.
이 간단한 설명은 현재 DNS 서비스가 GSLB 기능을 제공하지 않더라도 GSLB 서비스를 사용할 수 있음을 보여줍니다. GSLB가 아닌 영역에 있는 주어진 호스트의 해상도만 GSLB 서비스로 전달하면 됩니다. RELIANOID 로드 밸런서.
