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

2023

5G 특화망

포탈

Private 5G/이음 5G

 포탈홈

  넷매니아즈 5G 특화망 분석글 (128)   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의 5G 특화망 솔루션 (my5G)  Updated   | HFR 5G 특화망 뉴스HFR my5G 자료

  스폰서채널 서비스란?
Enterprise를 위한 GSLB 서비스 - 2편: Site/Server 선택 정책 (1)
Global Server Load Balancing for Enterprise - Part 2: Site/Server Selection Policy (1)
October 08, 2012 | By 유창모 (cmyoo@netmanias.com)
코멘트 (5)
12

지난 시간에 이어 오늘은 "GSLB가 어떤 기준으로 사이트/서버를 선택하는지?" GSLB Policy에 대해서 설명 드리도록 하겠습니다.

 

GSLB Policy

 

오늘과 다음 시간을 통해 소개해 드리는 Policy Metrics는 총 8가지이며, 이는 외산 벤더 기술문서 몇개를 참조하여 정리한 내용입니다. 

  ① Server Health -  살아있는 사이트 선택

  ② SLB Session & Network Capacity Threshold - 과부하 상태가 아닌 사이트 선택

   Network Proximity - 응답 속도가 빠른(Low Latency) 사이트 선택

   Geographic Proximity - 지리적으로 가까운 사이트 선택

   SLB Connection Load - 새로운 연결 요청이 적은 사이트 선택

   Site Preference - 운영자의 정책에 의해 특정 사이트 선택

   Least Selected - 균등하게 사이트 선택

   Static Load Balancing - 균등하게 사이트 선택

 

 

 

사이트/서버 선택 과정은 1번 단계를 시작으로 8번 단계까지 순차적으로 진행되며, 만약 1번 단계에서 사이트/서버가 선택이 되면 2번 단계로 넘어가지 않고 종료 되며 1번에서 결정이 나지 않으면 2번으로 넘어 가는 식입니다. 또한 운영자는 설정을 통해 각 단계를 enable/disable 할 수 있으며, 1번 ~ 8번의 순서 변경도 가능합니다.

 

1. Server Health

 

SLB(Server Load Balancing)가 서버들로 Layer 3 ICMP, Layer 4 TCP or UDP, Layer 7 HTTP Health Check 메시지를 보내어 서버 & 응용의 Health 상태를 모니터링하고, 그 결과를 GSLB로 전달하여 GSLB는 Server Health 상태를 기반으로 사이트를 선택합니다.

 

  1. 한국 사이트에 SLB1은 Server 1, 2의 Health 상태를, 미국 사이트에 SLB2는 Server 3, 4의 Health 상태를 주기적으로 모니터링하고,
  2. 그 결과를 GSLB로 주기적으로 보고합니다. 따라서 GSLB는 각 서버의 현재 Health 상태를 알고 있게 됩니다.
  3. 사용자가 Local DNS 서버로 DNS Query를 보내면
  4. Local DNS 서버는 DNS Query를 GSLB로 전달하고 (설명의 편의상 DNS Proxy 과정 생략),
  5. GSLB는 각 서버의 현재 Health 상태를 기반으로 사이트를 선택합니다. 현재 미국 사이트의 Server 3, 4가 모두 다운된 상태이고 따라서 GSLB는 한국 사이트 SLB1의 주소(Virtual IP) 1.1.1.1을 DNS Response에 실어 응답합니다. 
  6. DNS Response를 수신한 Local DNS 서버는 그 값을 사용자에게 전달하고,
  7. 사용자는 SLB1으로 HTTP GET 요청을 합니다.
  8. 이를 수신한 SLB1은 나름의 정책(서버 Health/부하 상태 등 고려)에 따라 Server 1, 2 중에 하나를 선택하여(여기서는 Server 1이라 가정), 사용자가 보낸 HTTP GET의 Destination IP = 1.1.1.1을 10.1.1.10으로 변경하여 Server 1으로 전달합니다.

 

2. SLB Session & Network Capacity Threshold

 

1번 과정(Server Health 기반 사이트 선택)에서 한국과 미국 사이트 서버가 모두 살아 있는 경우, (1) SLB의 현재 Session 수와 (2) SLB의 Network Usage 값을 참조하여 과부하(Over-loaded) 상태가 아닌 사이트를 선택합니다. 여기서 SLB의 Session 수란 SLB에 오픈되어 있는(유지하고 있는) TCP 혹은 UDP 연결수이고(예. SLB1을 통해 Sever1에 300,000개 TCP 세션 연결, Server2에 100,000개 TCP 세션이 연결되어 있으면 현재 SLB1의 Session 수는 총 400,000개임), Network Usage란 현재 SLB를 통해 송수신되는 트래픽 대역폭(bps)입니다.

 

  1. 각 사이트에 SLB1과 SLB2는 자신의 현재 Session 수와 Network Usage를 GSLB로 주기적으로 보고합니다. 
  2. 사용자가 Local DNS 서버로 DNS Query를 보내면
  3. Local DNS 서버는 DNS Query를 GSLB로 전달하고 (설명의 편의상 DNS Proxy 과정 생략),
  4. GSLB는 SLB1과 SLB2의 현재 Session 수와 Network Usage를 기반으로 사이트를 선택합니다. 이를 위해 각 SLB에는 Session 수 및 Network Usage에 대한 임계치(Threshold)가 미리 설정되어 있고 그 값은 GSLB도 알고 있습니다(Session 수 임계치=900,000, Network Usage 임계치=900Mbps). 미국 사이트 SLB2의 현재 Session 수가 임계치 수준까지 올라간 상황이므로 GSLB는 Session 수에 여유가 있는 한국 사이트 SLB1의 주소(Virtual IP) 1.1.1.1을 DNS Response에 실어 응답합니다. 
  5. DNS Response를 수신한 Local DNS 서버는 그 값을 사용자에게 전달하고,
  6. 사용자는 SLB1으로 HTTP GET 요청을 합니다.
  7. 이를 수신한 SLB1은 정책(서버 Health/부하 상태 등 고려)에 따라 Server 1, 2 중에 하나를 선택하여 해당 Server로 HTTP GET을 전달합니다.

 

3. Network Proximity

 

2번 과정(SLB Session & Network Capacity Threshold 기반 사이트 선택)에서 한국과 미국 사이트의 Session/Network Usage가 임계치를 넘지 않은 경우, Network Proximity 기반으로 사이트를 선택합니다. Network Proximity란 "네트워크 관점에서(지리적 관점이 아님)" 사용자와 가까운 사이트를 선택해 주는 것으로 여기서 "가까움"이란 Delay가 작음(Low Latency)를 의미합니다.

 

  1. 사용자가 Local DNS 서버로 DNS Query를 보내면
  2. Local DNS 서버는 DNS Query를 GSLB로 전달하고 (설명의 편의상 DNS Proxy 과정 생략),
  3. GSLB는 SLB1과 SLB2에게 Local DNS 서버의 IP 주소를 전달하여, RTT(Round Trip Time) 측정을 요청합니다.
  4. 이제 한국과 미국 사이트의 SLB는 ICMP를 이용하여 자신과 Local DNS 서버 간의 RTT를 측정하고,
  5. 그 결과를 GSLB에게 전달합니다. 현재 사용자는 미국에 위치해 있으므로(그래서 Local DNS 서버도 미국에 있다고 가정) SLB1에서 측정한 RTT는 200ms인 반면 SLB2에서 측정한 RTT는 30ms입니다. 따라서 GSLB는 미국 사이트를 선택하고 그 결과로 SLB2의 주소(Virtual IP) 2.2.2.2를 DNS Response에 실어 응답합니다. 
  6. DNS Response를 수신한 Local DNS 서버는 그 값을 사용자에게 전달하고,
  7. 사용자는 SLB2로 HTTP GET 요청을 합니다.
  8. 이를 수신한 SLB2는 정책(서버 Health/부하 상태 등 고려)에 따라 Server 3, 4 중에 하나를 선택하여 해당 Server로 HTTP GET을 전달합니다.

 

▶ 역자 주 1: 정확한 Network Proximity 측정을 위해서는 측정 구간이 "SLB ~ Local DNS 서버"가 아닌 "SLB ~ 사용자 단말"이어야 하겠으나, 현 DNS 프로토콜 표준은 사용자의 IP 주소를 상위 DNS 서버(여기서는 GSLB)로 전달하지 않습니다. 따라서 GSLB가 사용자 단말의 IP 주소를 알 수 없어 Local DNS 서버로 대신합니다. 하지만 보통 DHCP를 통해 IP 주소를 할당 받는 사용자 단말 환경에서는 사용자와 인접한 DNS 서버가 설정되기 때문에 Network Proximity 측면에서 큰 문제는 없습니다. (예. 한국 KT망 사용자는 DHCP에 의해서 KT DNS 서버가 Local DNS로 자동 설정이 되고, 미국 AT&T 사용자는 AT&T DNS 서버가 Local DNS로 자동 설정됨)

 

▶ 역자 주 2: ICMP(Ping) 요청을 막아 놓은 Local DNS 서버의 경우(Ping 응답을 안하는 경우), RTT 측정이 불가능하며, 이 경우 아래 4번 과정으로 넘어 가게 됩니다.

 

4. Geographic Proximity

 

3번 과정(Network Proximity 기반 사이트 선택)에서 Local DNS 서버가 ICMP에 응답을 하지 않거나 혹은 두 사이트의 RTT 결과가 유사한 경우, 지리적으로 사용자와 가까운 사이트를 선택하게 됩니다.

 

  1. 사용자가 Local DNS 서버로 DNS Query를 보내면
  2. Local DNS 서버는 DNS Query를 GSLB로 전달하고 (설명의 편의상 DNS Proxy 과정 생략),
  3. GSLB는 Local DNS 서버의 IP 주소로 IP Geolocation DB를 검색하여 지리적으로 가까운 사이트를 선택합니다. 사용자는 홍콩에 위치해 있으며 Local DNS 서버의 IP 주소는 홍콩 대역인 11.1.1.1입니다. GSLB는 IP Goelocation DB를 검색하여 이 IP 주소는 Asia 대역이며 한국 사이트 SLB1으로 지정되어 있음을 알게 되고, 따라서 GSLB는 SLB1의 주소(Virtual IP) 1.1.1.1을 DNS Response에 실어 응답합니다. 
  4. DNS Response를 수신한 Local DNS 서버는 그 값을 사용자에게 전달하고,
  5. 사용자는 SLB1으로 HTTP GET 요청을 합니다.
  6. 이를 수신한 SLB1은 정책(서버 Health/부하 상태 등 고려)에 따라 Server 1, 2 중에 하나를 선택하여 해당 Server로 HTTP GET을 전달합니다.

 

다음 시간에는 나머지 5번 ~ 8번 과정에 대해서 설명 드리도록 하겠습니다.

 

전득진 2013-07-16 10:44:18
글 잘봤습니다. 고맙습니다.
김현숙 2014-09-01 15:19:27

궁금한 부분이 있어 코멘트 남깁니다.

 

설명 중 그림으로 보면 GSLB가 개별적으로 나타나있는데요 

센터1, 센터2 외의 개별적으로 존재해야하는 장치인가요?

 

아니면 센터1, 센터2에서 흡수해서 가지고 있는 기능인가요?

Netmanias 2014-09-01 19:18:00

Deploy 자료를 실제로 접한 적이 없어 확신은 없지만 아마도 GSLB는 센터1, 2에 위치하게 될 듯 합니다.

아래 KT GSLB 그림을 참고하세요.

https://www.netmanias.com/ko/?m=view&id=blog&no=5617 

김희민 2017-04-23 20:14:48

김현숙님의 질문에 대한 답변을 드리자면 어떻게 설계하느냐에 따라 조금씩 다른 것이라 생각합니다. KT GLSB 그림을 보면 각 site에 GSLB1, GSLB2이 존재하고 있지만 실제로는 이중화되어 서버의 health condition 정보는 두 GSLB가 동일하게 가지고 있습니다. 이중화하지 않는다면 이론적으로는 하나의 GSLB로도 운용이 가능할 것이고 위치는 상황에 따라 적합하게 선택될 것입니다. 

챌린저 2020-05-19 18:42:44

7번에 운영자가 직접 사이트를 선택할 수 있다고 하는데, 그렇다면 운영자의 설정으로 source에 따라서 고정적으로 같은 사이트를 선택할 수 있나요? ex) a source ip가 요청하면 무조건 a사이트에만

 

그리고, 혹시 local dns가 요청한 사이트의 a레코드인 ip를 가지고 있으면 root ns에게 쿼리안하고 바로 응답해주나요?

 

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
View All (1195)
5G (127) 5G 특화망 (40) 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 (51) 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 (21)

 

 

     
         
     

 

     
     

넷매니아즈 회원 가입 하기

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

 

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

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

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

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

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

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