| 리포트 | 기술문서 | 테크-블로그 | 원샷 갤러리 | 링크드인 | 스폰서 컨텐츠 | 네트워크/통신 뉴스 | 인터넷자료실 | 자유게시판    한국 ICT 기업 총람 |

제품 검색

|

통신 방송 통계

 
 
 
섹션 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/UHD IoT SDN/NFV Wi-Fi Video Streaming KT SK Telecom LG U+ OTT Network Protocol CDN YouTube Data Center
 

2024

5G 특화망

포탈

Private 5G/이음 5G

 포탈홈

  넷매니아즈 5G 특화망 분석글 (136)   5G 특화망 4가지 구축모델   산업계 5G 응용   산업분야별 5G 특화망 활용사례  [5G 특화망 벤더Samsung | HFR | Nokia | more
 

해외

  국가별 사설5G 주파수 [국가별 구축현황] 일본 | 독일 | 미국 | 프랑스 | 영국  [사설5G 사업자] Verizon | AT&T | DT | Telefonica | AWS | Microsoft | NTT동일본 | NTT Com    
 

국내

  5G 특화망 뉴스 | 국내 5G 특화망 구축 현황 | 국내 5G 특화망사업자 현황 (19개사) | 국내 자가구축사례 일람 | 국내 특화망 실증사업사례 일람 | 5G 특화망 정책
 
 

[5G 특화망 구축 사례] 한국식품산업클러스터 | 반월시화산단 삼성서울병원 | 롯데월드 | 한국수력원자력 | 해군본부 | 한국전력공사 | more  [이통사] KT

 
 
스폰서채널 |

 HFR Mobile의 5G 특화망 솔루션 (my5G)  Updated   |   뉴젠스의 5G 특화망 구축 및 운영 서비스  NEW  

  스폰서채널 서비스란?
banner
banner
KT 유클라우드, GSLB로 무중단 서비스 지원
Global Server Load Balancing (GSLB) Service for KT ucloud
September 19, 2012 | By 유창모 (cmyoo@netmanias.com)
코멘트 (6)
19

올 9월 초에 KT에서 기업용 유클라우드(ucloud) 고객 대상으로 GSLB를 이용한 무중단 서비스를 출시하였다고 밝힌 바 있습니다. (기사 링크)

기사(아래)에 따르면 본 서비스를 통해 다음과 같은 장점을 제공할 수 있다고 설명 되어 있는데요. 

이번 시간에는 KT 유클라우드에 적용된 GSLB 서비스 로직에 대해서 알아보도록 하겠습니다.

 


"GSLB 서비스는 동일한 기능을 수행할 수 있는 여러 대의 클라우드 서버 중 최적 상태의 서버와 연결함으로써 고객 시스템의 안정성을 향상시키며, 부하를 분산시켜 일부 서버에 트래픽이 집중되는 것을 막기 때문에 서버의 가용성을 높일 수 있다.

클라우드 환경에서의 기존 로드밸런싱 솔루션은 서버의 상태와 관계없이 서비스 요청을 하는 것에 비해 유클라우드의 GSLB 서비스는 서버의 상태 확인 후 정상적인 서버에만 연결하므로 보다 신속한 트래픽 처리 및 장애 대응이 가능해진다."

 

※ Active-Backup 구성 예시이며, Active-Active 구성시에는 부하분산 서비스가 가능합니다.


 

KT GSLB 서비스 흐름도

 

위 그림을 좀 더 자세히 그려 보았습니다.

 

 

■ 준비 작업 (Pre-Configuration)

  • 위 그림에서 www.abc.com은 KT 클라우드 서버(가상 머신)에 호스팅되어 있으며 천안과 목동에 위치한 KT 클라우트 데이터센터(CDC)에 지역 이중화 되어 있음
  • 천안 CDC(Cloud Data Center)에 www.abc.com의 IP 주소는 1.1.1.1이고, 목동 CDC의 IP 주소는 2.2.2.2임
  • abc.com DNS 서버에는 아래와 같이 "www.abc.com에 대한 CNAME = abc.g.ucloudbiz.com"이 설정되어 있음
    • abc.com DNS 서버의 BIND 설정: www  IN  CNAME  abc.g.ucloudbiz.com.
  • KT GSLB 1, 2에는 abc.g.ucloudbiz.com에 대한 서버 IP 주소 1.1.1.1, 2.2.2.2가 등록되어 있음
■ 서비스 로직 (Service Logic)
  1. 사용자가 www.abc.com에 접속하기 위해 Local DNS 서버로 DNS Query를 보내고, Local DNS 서버는 Root DNS, .com DNS 서버를 거쳐
  2. abc.com DNS 서버로 www.abc.com에 대한 DNS Query를 보냅니다.
  3. 앞서 설명드린 바와 같이 abc.com DNS 서버에는 CNAME이 등록되어 있어, abc.com DNS 서버는 Local DNS 서버에게 "www.abc.com 대신에 abc.g.ucloudbiz.com 이름으로 DNS Query를 해라"라로 알립니다.
  4. Local DNS 서버는 이제 abc.g.ucloudbiz.com에 대해 DNS Query를 하고 그 요청은 천안 혹은 목동에 위치한 GSLB가 수신합니다. (위 그림에서는 GSLB 1이 수신)
  5. 이제 이 부분이 가장 중요합니다. DNS Query를 수신한 GSLB 1은 abc.g.ucloudbiz.com에 대한 host IP 주소로 1.1.1.1과 2.2.2.2가 있음을 알고 있으며, GSLB Policy에 따라 이 중에 하나의 서버를 선택합니다. 자세한 설명은 뒤에서 하도록 하고  일단 천안 CDC에 있는 서버(VM)를 선택했다고 하겠습니다.
  6. GSLB 1은 DNS Response에 Host IP = 1.1.1.1(천안 CDC의 Server 1)을 실어 Local DNS로 전달하고,
  7. Local DNS는 사용자 단말에게 Host IP = 1.1.1.1을 전달합니다.
  8. 이제 사용자는 www.abc.com의 IP 주소 1.1.1.1을 목적지로 하여 천안 CDC에 있는 Server 1에 접속합니다.

 

 

GSLB는 어떤 기준으로 서버를 선택할까? (GSLB Policy)

 

위 그림 5번에서 GSLB의 "서버 선택 기준"에 대해서 알아 보도록 하겠습니다. 일단 일반적인 GSLB 기능에 대해서 설명 드린 후, KT에서 적용한 방법을 소개해 드리겠습니다.

 

Server Health Check

GSLB는 서버들로 IGMP(Ping), UDP, TCP, HTTP 메시지를 보내고 그 응답 여부를 통해 서버 혹은 서버의 응용(예. HTTP server)이 살아 있음을 주기적으로 확인하여 서비스가 가능한 서버를 선택합니다.

▶ 그림에서 GSLB 1은 1.1.1.1, 2.2.2.2 서버에 대해 TCP 및 HTTP Health Check 수행

    GSLB 2 역시 1.1.1.1, 2.2.2.2 서버에 대해 TCP 및 HTTP Health Check 수행

 

■ Geographic Proximity (between Local DNS and Server)

DNS Query를 보낸 Local DNS 서버의 IP 주소를 확인하여 지역적으로 가까운 서버를 선택합니다. 우리나라와 같이 전국 어디에서나 RTT(Round Trip Time) 10ms 이하 수준인 경우 별 상관이 없지만 미국과 같이 동부-서부간에 RTT가 큰 나라의 경우 사용자(정확히는 사용자 단말에 설정된 Local DNS 서버)에게 가까운 서버를 선택해 줌으로써 빠른 응답 속도를 제공합니다.

 

Admin Policy

운영자의 정책에 따라 서버를 선택합니다. 그 정책의 예는 다음과 같습니다.

     1. Random하게 서버 선택

     2. Round-Robin 방식으로 서버 선택 (예. 1.1.1.1 -> 2.2.2.2 -> 1.1.1.1 -> 2.2.2.2 -> ....)

     3. Weighted Round Robin 방식으로 서버 선택 (예. 1.1.1.1 서버 성능이 높아 1.1.1.1과 2.2.2.2 서버에 2:1로 배분)

 

 

KT의 GSLB Policy

 

KT GSLB 방식은 크게 2가지 입니다. 하나는 Active-Backup 방식(한 서버만 서비스 제공)이고, 또 하나는 Active-Active 방식(두 서버 모두 서비스 제공)입니다.

 

■ Active-Backup 방식에서의 GSLB Policy

Server Health Check을 통해 Active Server가 살아 있으면 항상 그 서버를 선택합니다.

 

■ Active-Active 방식에서의 GSLB Policy

Server Health Check을 통해 Active Server들(1.1.1.1과 2.2.2.2)이 살아 있으면 Round-Robin으로 서버를 선택합니다.

 

아래 그림은 KT GSLB 설정 화면입니다.

 

 

 

3줄 요약

  • KT GSLB는 사이트 이중화(Disaster Recovery) 혹은 서버 부하 분산(Server Load Balancing) 기능을 제공함
  • KT GSLB는 사용자(Local DNS)로 부터 DNS Query를 수신하여,
  • 서버의 상태(Health) 및 운영자의 정책(Round-Robin)에 따라 서버를 선택하고 그 주소를 DNS Response에 실어 사용자(Local DNS)에게 전달함으로써 서비스 가용성을 높임

 

다음 시간에는 Citrix, Broacade, F5 등의 Enterprise 대상 GSLB 솔루션 개념에 대해서 알아 보도록 하겠습니다.

 

nexpert 2012-09-19 14:16:38
User 로컬 DNS에서 GSLB서버로 DNS쿼리하여 응답받은 바인딩 정보를 일정시간 로컬 DNS에서 캐싱하게 되는 것으로 알고 있습니다. 즉, User의 쿼리에 대해 로컬 DNS의 캐싱 TTL이 time-out될때까지는 GSLB서버로 쿼리하는 단계를 거치지 않고 로컬 DNS가 캐싱된 바인딩 정보를 참조하여 바로 User에게 응답을 해줄거라 생각됩니다.

이 경우에도 서버의 상태(Health) 및 운영자의 정책(Round-Robin)에 따라 서버를 선택하는 것이 가능할런지요??
넷매니아즈 2012-09-19 15:21:34
좋은 말씀이십니다. KT GSLB의 TTL 값이 얼마로 설정되어 있는지는 잘 모르겠는데요.
Brocade GSLB 자료를 보면, TTL 값을 10초로 (default value) 짧게 설정하여 이 문제를 해결하였습니다.

아래는 관련 내용입니다.

The client’s local DNS server might cache DNS replies from the authoritative server. Normally, these cached
responses would prevent the global SLB from taking place, since the local DNS server would respond directly to
the client without sending a recursive query to the authoritative DNS server. However, the GSLB ServerIron, as a
proxy for the authoritative DNS server, automatically resets the Time-to-Live (TTL) parameter in each DNS record
from the authoritative server. By default, the GSLB ServerIron sets the TTL to 10 seconds. As a result, other DNS
servers that receive the records retain them in their databases for only 10 seconds. After the ten seconds expire,
subsequent requests from the client initiate another query to the authoritative DNS server. As a result, the client
always receives fresh information and the address of the site that is truly the best site for the client.

NOTE: You also can change the TTL if needed. However, Brocade Communications Systems recommends that
you do not change the TTL to 0, because this can be interpreted as an error by some older DNS servers.
nexpert 2012-09-20 17:22:40
네 잘 읽었습니다.
결국 로컬 DNS의 TTL이 time-out되기 전까지 다른 서버는 선택할 수 없다..라는 의미로 볼 수 있겠군요.
GSLB에 의해 최초 선택된 서버 장애 시 일정 시간은(Brocade GSLB는 최소 10초 이상 이겠죠) 서비스 장애를 겪을 수 밖에 없는데(TTL을 "0"으로 하는건 비추이므로..), KT에서 표현한 무중단 서비스 지원이라는 말은 좀 과장(?)된 면이 있는 듯 합니다. ^^;
켈틱 2012-09-21 13:19:39
GLB의 경우 대부분 최종 서버군을 보고 있지 않고 각 노드별로 내부의 SLB (L4 vip)를 바라보게 구성하기 때문에 SLB 하단의 모든 서버에 장애가 발생하는 경우, 혹은 2중화된 SLB가 모두 장애가 발생하는 경우를 제외하면 TTL 값에 어느정도는 자유로울 수 있습니다.

하지만 GLB를 노드 내부 SLB 역할까지 맡기게 되면 되면 nexpert님 말씀대로 캐시타임아웃 까지는 장애이니 TTL 값을 극단적으로 낮춰야 장애시간이 짧아지겠죠. F5 Big IP의 경우 30초가 기본 설정이었던 기억입니다.
켈틱 2012-09-21 13:21:43
그나저나 넷매니아즈님 나누고 사시는 모습 진심으로 존경합니다 정말 큰 도움 받고 있습니다. ^^;
GSLB성능은? 2013-12-06 15:43:37
GSLB는 서버군들의 lineup 정보(vm servers)를 어떻게 관리하는지??? 결국, 서버군에 서버가 추가될 때마다, GSLB에도 추가 서버에 대한 매핑정보를 갱신해야 하는 건 아닌건가요? ... 기존의 L4가 서버군들의 heath check하여 개별 서버들의 생존을 체크하는 방식이 아닌, 확장되어 GSLB라는게 다른 노드의 서버군들까지 heath check해서 dns resloving과정에서 disable된 서버를 제외시킨다는 거군요...?
Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
View All (1207)
5G (130) 5G 특화망 (43) AI (16) ALTO (1) AR (2) ARP (6) AT&T (1) Akamai (5) Authentication (5) BT (1) Backhaul (2) Big Data (2) Bridging (5) C-RAN/Fronthaul (19) CDN (20) CIoT (2) CPRI (6) Carrier Aggregation (5) Charging (2) China Mobile (2) Cisco (6) CoMP (3) Comcast (1) DHCP (6) DNS (15) Data Center (15) EDGE (14) EMM (1) EPS Bearer (7) Ethernet (3) FTTH (8) GSLB (5) Gigabit Internet (17) Google (17) Google Global Cache (8) Google TV (1) HLS (5) HTTP (5) HTTP Adaptive Streaming (7) HTTP Progressive Download (2) Handover (5) Huawei (1) IGMP (3) IP (6) IP Allocation (8) IP Routing (20) IPSec (4) IPTV (25) IoST (2) IoT (63) KT (46) Korea (8) Korea ICT Vendor (1) L3 Switch (5) LG U+ (24) LTE (99) LTE-A (10) LTE-A Pro (1) LTE-M (1) LTE-U (3) LoRa (5) MEC (15) MPLS (3) MWC 2013 (1) MWC 2015 (3) MWC 2016 (2) MWC 2017 (1) Mobile IPTV (1) Multi-Screen (1) Multicast (2) NAT (9) NB-IoT (6) NTT Docomo (1) Netflix (5) Network Protocol (49) Network Slicing (3) O-RAN (2) OSPF (3) OTT (20) Operator CDN (1) P2P (3) PS-LTE (3) Pooq (2) Private 5G (54) QoS (5) RCS (1) RRH (1) Request Routing (3) SD-WAN (8) SDN/NFV (42) SK Broadband (1) SK Telecom (38) Samsung (2) Security (8) Self-Driving (3) Shortest Path Tree (2) Small Cell (3) Spectrum Sharing (1) TAU (2) Transparent Caching (9) UHD (7) VLAN (2) VPN (3) VR (3) Video Streaming (22) VoLTE (1) VoWiFi (1) WAN Optimization (1) Wi-Fi (30) WiBro(WiMAX) (2) YouTube (16) eICIC (1) eMBMS (1) ePDG (6) u+ tv G (4) 로컬 5G (3) 이음 5G (24)

 

 

     
         
     

 

     
     

넷매니아즈 회원 가입 하기

2023년 6월 현재 넷매니아즈 회원은 55,000+분입니다.

 

넷매니아즈 회원 가입을 하시면,

► 넷매니아즈 신규 컨텐츠 발행 소식 등의 정보를

   이메일 뉴스레터로 발송해드립니다.

► 넷매니아즈의 모든 컨텐츠를 pdf 파일로 다운로드

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

비밀번호 확인
코멘트 작성시 등록하신 비밀번호를 입력하여주세요.
비밀번호