게시일: 16년 2018월 XNUMX일

내용

GSLB 개요

요즘 IT 서비스의 높은 가용성은 필수 요소이며 기업 및 조직이 전 세계에 분산되어있는 컴퓨팅 시스템을 개발하고 하나 이상의 데이터 센터에서 서비스를 호스팅하는 이유는 다음과 같은 이점이 있기 때문입니다.

결함 허용: 데이터 센터의 호스팅 서비스가 실패하면 서비스는 다른 사용 가능한 사이트 중 하나에서 계속됩니다.
자동 데이터 센터 복구: 하나의 데이터 센터에 장애가 발생하면 서비스는 자동으로 다른 사용 가능한 데이터 센터로 리디렉션됩니다.
로드 균형 조정: 사용 가능한 모든 사이트에로드를 분산시켜 대기 시간을 개선하고 서비스 제공을보다 빠르게 수행함으로써 트래픽을 최적화 할 수 있습니다.
향상된 지연 시간: 클라이언트 응용 프로그램 트래픽은 실제 서버와 직접적으로 연결되므로로드 밸런서를 통해 모든 응용 프로그램 데이터를 전달할 필요가 없습니다.

클라우드에서 IT 서비스를 채택하고 구현하려면 지리적 위치에있는 고 가용성 솔루션을 제공하는 데 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 쿼리를 보낸다. (예를 들어, 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 주소가 다시 사용할 수있을 때까지 해당 IP 주소가 DNS 쿼리에 나열되지 않습니다.

다음 다이어그램은 GSLB 기능이있는 설명 된 DNS 트래픽을 보여줍니다.

데이터 센터의 재해 복구를위한 GSLB 구성

이 구성은 재해 복구 용 데이터 센터의 고 가용성을 필요로하는 서비스에 권장됩니다. 따라서 특정 회사의 모든 서비스가 하나의 데이터 센터에 있고 그러한 데이터 센터가 실패하면 시스템은 영향을받은 모든 서비스를 다른 사용 가능한 데이터 센터로 이동합니다 .

재해 복구를위한 능동 - 수동 데이터 센터를 구축하려면 GSLB 구성의 실제 사례를 따르십시오.

우리는 두 개의 Zevenet로드 밸런서를 서로 다른 사이트의 두 데이터 센터, 프랑크푸르트 159.89.7.124 토론토 159.203.12.35 DNS 호스트에 응답하는 웹 서비스가 있습니다. www.zvnlb.net,에서 구성됨 데이터 센터 1 및 데이터 센터 2. 이 아키텍처의 설계는 모든 클라이언트 트래픽을 데이터 센터 1 하지만 실패하면 클라이언트를 다음으로 리디렉션합니다. 데이터 센터 2.

이 구성을 수행하려면 아래 절차를 따르십시오.

Zevenet 웹 패널에 연결 데이터 센터 1 (우리의 경우 프랑크푸르트) 메인 메뉴에서 클릭하십시오. GSLB 모듈을 만들고 새로운 농장, 우리의 예에서는 DNS1- 프랑크푸르트 가상 포트에서 53.

팜을 만든 후에는 팜을 편집하고 탭으로 이동하십시오. 영역 이 경우에는 GSLB 모듈에서 관리 할 DNS 영역을 만듭니다 zvnlb.net, 다음과 같이 :

이 영역이 생성되면 아래와 같이 첫 번째 구성을 만드십시오.

참고 ns1 및 ns2 영역의 DNS 확인을 담당하는 네임 서버 zvnlb.net (우리의 경우, 프랑크푸르트의 GSLB 서비스 1 개와 토론토의 GSLB 서비스 1 개).

그런 다음 데이터 센터 2에서 Zevenet 웹 패널에 연결하고 기본 메뉴에서 GSLB 새로운 농장, 우리의 경우에 호출됩니다 DNS2- 토론토 가상 포트에서 53.

새 GSLB 팜을 편집하고 탭으로 이동하십시오. 영역,이 GSLB 서비스에 의해 관리 될 DNS 영역을 여기에 생성하십시오. zvnlb.net 다음과 같이 :

이 새로운 영역이 생성되면 다음과 같이 첫 번째 구성을 작성하십시오.

GSLB의 경우처럼 데이터 센터 1, 이름 서버 n1 및 n2 둘 다에서 GSLB 서비스를 가리킬 것입니다 데이터 센터 1 및 데이터 센터 2각각.

그런 다음 탭을 클릭하십시오. 서비스 예를 들어 새로운 서비스를 만들 수 있습니다. 웹 우선 순위:

선택 암호알고리즘 선택권 우선 순위 : 항상 가장 가능성있는 연결로 연결 다음과 같이 서비스를 구성하십시오.

변경 사항을 적용하려면 팜을 다시 시작하십시오. 두 데이터 센터에서 동일한 GSLB 서비스 구성을 적용해야합니다.

만약 농장 수호자 상태 검사를 적용하도록 구성되지 않았 으면 GSLB 서비스는 기본값을 사용합니다 check_tcp 서비스 구성의 상태 점검 필드에 정의 된 TCP 포트에 연결하십시오.

새 서비스를 사용하려면 생성 된 영역으로 이동하십시오 (zvnlb.net 우리의 경우) 새로운 자원. 그런 다음 새 항목을 선택하여 만듭니다. 서비스 아래에 표시된대로.

마지막으로 변경 사항을 저장하십시오. 두 데이터 센터 모두에이 구성을 적용해야합니다.

이 시점에서 호스트 www.zvnlb.net GSLB 모듈에 의해 관리됩니다. 우선 모드로 전환되므로 모든 트래픽이 데이터 센터 1 그런 다음 실패하면 트래픽이 다른 사용 가능한 경로로 리디렉션됩니다. 데이터 센터 2.

TTL은 5로 구성되었으며 DNS 레코드에 저장되는 만료 날짜입니다. TTL은 재귀 서버 또는 로컬 리졸버에게 해당 레코드를 캐시에 얼마나 오래 보관해야하는지 알려줍니다. 따라서 값이 작을수록 빠르게 변경 사항이 감지됩니다.

이 방법을 적용하면 GSLB 서비스가있는 새로운 이름 서버를 포함하여 필요한만큼의 데이터 센터를 추가 할 수 있습니다.

다음 DNS 요청은 다음에 대한 Nameservers 구성을 보여줍니다. zvnlb.net 및 호스트에 대한 DNS 확인 www.zvnlb.net.

user@client:# host -t ns zvnlb.net
zvnlb.net name server ns2.zvnlb.net.
zvnlb.net name server ns1.zvnlb.net.

두 네임 서버 모두 GSLB 팜에 구성된 가상 IP 주소를 사용합니다.

이제 현재 DNS 서버를 사용하여 호스트를 해결하십시오 (예 : WWW)이 영역에서 :

user@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 188.166.230.211

그것이 보여 주므로, 현재 호스트 188.166.230.211 의 실제 활성 응용 프로그램 노드입니다. 데이터 센터 1. 곧 호스트에 연결할 수 없습니다 (예 : http 서비스 188.166.230.211 아래에 표시된대로 DNS 확인이 변경됩니다.

user@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 139.59.186.84

응용 프로그램 서버가 실패하자마자 DNS 확인은 호스트를 데이터 센터 2. 일단 호스트가 데이터 센터 1 최대 장애 복구가 자동으로 적용됩니다.

활성 - 활성 데이터 센터를위한 GSLB 구성

모드 우선 순위가있는 고 가용성은 재해 복구 시스템에 좋은 옵션이지만 복구에 사용되는 백업 데이터 센터는 사용량이 너무 많지 않으므로 일반적으로 사용 가능한 데이터 간의 모든 트래픽을로드 밸런싱하는 것이 더 효율적입니다. 센터.

그러한 경우 GSLB 서비스에 대한 공유 방법을 사용하십시오. 라운드 로빈로드 균형 조정 라는 새 서비스의 예에 표시된대로 웹:

이제 영역에 추가하십시오. zvnlb.net 자원 구성 변경 WWW 다음과 같이 :

변경 내용을 저장하고 요청 된 경우 팜을 다시 시작합니다.

이를 테스트하려면 호스트를 해결하십시오. www.zvnlb.net 출력은 다음과 같이 표시됩니다.

user@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 188.166.230.211
Name:	www.zvnlb.net
Address: 139.59.186.84

DNS 리졸버는 Disaster Recovery 케이스와 같은 애플리케이션 서버가 아닌 두 애플리케이션 서버를 모두 반환합니다.

호스트에 장애가 발생하면 DNS 확인이 자동으로 변경됩니다. 무슨 일이 일어나는지 아래를보십시오.

root@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 139.59.186.84

사용할 수없는 응용 프로그램 서버는 DNS 응답 목록에서 비활성화됩니다.

호스트가 되 자마자 188.166.230.211 다시 사용할 수 있으면 DNS 확인에 다시 포함됩니다.

Zevenet GSLB 서비스에서 영역 위임

공용 구역의 경우 (예 : zvnlb.net) GSLB 서비스를 해당 도메인에 대한 공용 DNS 서버에서 인식해야하는 이름 서버 확인 자로 제공하는 경우 GSLB 서비스에서 사용하는 공용 IP 주소를 도메인 등록 기관 (NameCheap, Goddady 등)에 등록해야합니다. . 다음 링크는 도메인 등록자 절차에서 GSLB IP를 네임 서버로 등록하는 방법을 설명합니다.

호스트를 NameServer로 등록

주어진 절차에 따라 등록해야합니다. ns1.zvnlb.net 및 ns2.zvnlb.net 주어진 IP로

GSLB 전용 서브 존 만들기

Zevenet의 GSLB 서비스에 DNS 확인을 위임 할 수없는 경우 아래 설명 된 구성을 수행 할 수 있습니다. 다음 예는 하위 영역 ...에 대한 zvnlb.net GSLB 서비스에서이 새로운 하위 영역의 NameServers를 가리 킵니다.

노드 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 서버에 있습니다.