|
| |
| |
|
출처: http://www.cs.kookmin.ac.kr/project/project_2001/project2001_3/Project2001_03.htm#%EA%B3%BC%EC%A0%9C%EB%AA%85
1. 과제명 : 시스템 부하 모니터링을 통한 Dynamic한 Load Balancer 구현 및 Weight 산출
3. 개 요
다른 네트윅에 연결된 서버(server)들의 클러스터(cluster)는 성능이 뛰어나고 (high performance) 가용성이 높은 (highly available) 서버를 구축하는데 유효한 구조임이 판명되고 있다. 이러한 형태의 느슨하게 연관된 구조는 단일 프로세서(processor) 시스템이나 엄격한 다중 프로세서 시스템보다 확장성이 뛰어나고 (more scalable) 비용-효율성이 좋으며 (more cost-effective) 신뢰성이 높다(more reliable). 실제적으로 단일 서버가 처리할 수 있는 용량은 이미 한계치에 다다르고 있으며 이론적으로 CPU의 속도는 10THz를 넘을 수 없다. 때문에 클러스터링에 대한 연구와 개발이 활발하게 이루어 지고 있으며 다양한 방식의 클러스터링 기법이 발표되고 있다. 하지만 가장 큰 이슈는 서버의 가중치를 어떻게 얼마나 부여할 것인가와 서버의 장애시 어떠한 시나리오로 동작할 것인가이다.
4. 배 경
IP 클러스터링은 특정 사이트나 서버로 향하는 인터넷 트래픽을 적절히 분산하기 위한 것으로, 인터넷 사용자와 컨텐츠 제공자가 폭발적으로 증가하는 요즘, 핫 이슈로 부각되고 있다. 즉, 인기 있는 사이트들은 빠른 시일 내에 인터넷 사용자에게 소문이 퍼져 접속자 수가 하루가 다르게 증가함에 따라 자연히 서비스 반응 속도가 급격히 저하된다. 또한 네트워크 트래픽 과부하로 서버가 다운될 경우 서비스를 계속 할 수 없는 지경에 이른다. 특히 전자상거래와 같은 응용 분야에서 네트워크 서비스가 중단되는 문제는 매출액의 감소와 신뢰도 저하로 직결되므로 심각하지 않을 수 없다. 이렇듯 서비스 품질을 개선하기 위한 방법을 단순하게 생각하면 좀더 빠르고 처리율이 뛰어난 컴퓨터로 서버 자체를 교체하는 것이 최선이라고 생각할지 모른다. 그러나 세상에 존재하는 어떠한 고가의 컴퓨터라 하더라도 단일 기계에서 증가하는 네트워크 트래픽을 감당해내지 못할 것이다.
이에 대한 이유는 크게 두 가지가 있다. 먼저 네트워크 대역폭이 한정돼 있을 뿐 아니라 컴퓨팅 자원(메모리, CPU 등)이 한정돼 있기 때문이다. 특히 현재로서는 컴퓨팅 자원에서 주로 병목현상이 발생하는데, 아마도 Gbps급 백본에 직접 연결된 웹사이트라도 개개의 사용자들은 14.4Kbps에서 수 Mbps 정도의 네트워크를 이용해 접속하기 때문에 전체 스피드가 크게 저하된다. 이러한 네트워크 환경에서는 컴퓨팅 자원은 계속 고갈되고, 나아가 시스템이 다운될 경우 서비스가 중단되는 치명적 결과를 가져오기도 한다. 특히 메모리 자원의 고갈 현상이 심한데, 한 대의 컴퓨터에 장착할 수 있는 메모리의 용량은 제한돼 있으므로 여러 대의 서버로 클러스터링하는 것이 필수다.
인터넷에서의 트래픽은 매년 100%이상의 증가추세이며 이에 따라 서버에 접속하는 트랙픽이 빠르게 증가하면서 서버들은 짧은 시간내에 과부하가 발생함으로써 이에 따른 서버의 실행능력과 가용성을 높이는 문제가 대두된다. 그러므로 확장성이 있고 높은 가용성을 가진 서버에 대한 요구가 절실히 증가하고 있다. 이러한 형태의 서버들의 필요 조건을 요약하자면 다음과 같다:
추가 확장성
높은 가용성
비용-효율성
서버를 더 높은 성능의 서버로 개선 하는 단일 서버 솔루션은 이 필요 조건을 맞추기에 한계가 있다. 개선 작업이 복잡하고 원래의 기계가 낭비될 수도 있다. 만일 요구가 증가된다면 오래 지나지 않아 과부하가 되어 더 높은 성능의 서버로 다시 개선해 주어야 한다. 이 서버에 장애가 일어나면 전체 시스템에 영향을 미치는 곳이다. 개선해야할 목표가 높아지면 높아질수록 비용이 더욱 더 많이 든다.
빠른 네트워크에 연결된 서버들의 클러스터는 성능이 뛰어나고 가용성이 높은 서버를 구축하는데 유효한 구조임이 판명되고 있다. 이러한 형태의 느슨하게 연관된 구조는 단일 프로세서 시스템이나 엄격한 다중 프로세서 시스템보다 확장성이 뛰어나고 비용-효율성이 좋으며 신뢰성이 높다. 그러나 클러스터내 병렬 서비스의 투명성, 확장성, 그리고 높은 가용성을 제공해야 하는 어려움이 있다.
4. 1 일반적인 성능 향상 방안
수직적 성능 방안 : CPU, Memory 등의 업그레이드
수평적 성능 방안 : node 추가
비용적 문제로 인해 수직적 성능 보다 수평적 성능이 대안으로 대두됨
낮은 비용과 시스템의 확장성 및 시스템의 고가용성이 필요
4. 2 LVS(Linux Virtual Server)를 이용한 성능향상
리눅스 기반의 웹 클러스터링을 이용하여 고성능과 높은 고가용성의 서버를 구성함으로서 높은 확장성, 신뢰성 서비스를 제공하는 것으로서 가상 서버는 실제 서버를 클러스터로 구성하여 뛰어난 확장성과 신뢰성을 구현한다. 또한 클러스터의 구조는 최종사용자에게는 투명하며 사용자는 오직 하나의 가상서버만을 볼 수 있음.
가상 서버는 느슨하게 연관된 독립된 서버들의 클러스터에 구축되어 확장 가능하고 가용성이 높은 서버이다. 클러스터 구조는 클러스터 밖의 클라이언트에 투명하다. 클라이언트 응용 프로그램은 마치 클러스터가 하나의 고성능, 고가용성의 서버인 것처럼 클러스터와 상호작용한다. 클라이언트는 클러스터와의 상호작용에 의해 침범 받지 않으며 변형될 필요가 없다.
4. 3 가상 서버의 구조
실제 서버들은 고속 LAN 또는 지역적으로 분산된 WAN으로 연결된다. 실제 서버들의 외부 연결부는 부하 분산기(load balancer)이다. 부하 분산기는 요구를 각기 다른 서버들에게 작업 할당(schedule)하고 클러스터의 병렬 서비스들을 하나의 IP 주소상의 하나의 가상 서비스로 보이도록 만든다. 높은 가용성은 노드(node) 또는 데몬(daemon)의 장애나 시스템의 구조 변화를 적절히 감지해냄으로써 이루어진다.
4. 4 연관된 작업들
클라이언트/서버 환경(client/server applications)에서 한쪽 끝은 클라이언트고 다른 한쪽 끝은 서버가 된다. 그리고 중간에 웹 서비스에서의 프락시 서버같은 프락시(proxy)가 있을 수 있다. 이 시나리오를 바탕으로 각기 다른 계층에서 서버들의 클러스터에 요구(request)를 발송 (dispatch)하는 많은 방법이 있다는 것을 알 수 있다. 일반적으로 이러한 서버들은 같은 서비스 와 같은 서비스 내용을 가지고 잇다. 서비스 내용은 각 서버의 로칼 디스크(local disk)에 복제 되거나 넷트웍 파일 시스템으로 공유되어지거나 분산 파일 시스템으로 제공된다. 기존의 요구 발송 기술들(request dispatching techniques)은 다음과 같은 범주들로 나눌 수 있다.
4. 4. 1 클라이언트 측면의 방법
버클리(Berkeley)의 스마트 클라이언트(Smart Client)1는 클라이언트 측면에서 동작하는 애플릿 (applet)을 제공한다. 애플릿이 서버들의 클러스터에게 모든 서버들의 부하 정보(load information)를 모아 줄것을 요청한 후, 그 정보를 바탕으로 한 서버를 선택하여 그 서버에 요구(request)를 보낸다. 애플릿은 선택한 서버가 사용 불능 상태(down)가 되었다면 다른 서버를 시 도한다. 보스턴 대학(Boston University)은 클라이언트쪽에서 대역폭(bandwidth)을 시험하여 동 적으로 서버를 선택하는 기술2을 개발했다. 이 기술에서는 주어진 경로를 따라 가능한한 큰 대역폭과 경로상의 현재의 정체(congestion)를 실험을 통해 추정한다. 그러나 이러한 클라이언트 측면의 접근은 클라이언트-투명성을 가지지 못한다. 이들은 클라이언트 응용프로그램의 수정이 필요하기 때문에 모든 TCP/IP 서비스에 응용될 수는 없다. 게다가 이들은 부가적인 질문 또는 실험 때문에 넷트웍 정보 전송량을 증가시킬 가능성이 있다.
4. 4. 2 서버 측면의 Round-Robin DNS 방법
NCSA 확장 가능(scalable) 웹 서버는 Round-Robin DNS 방법3, 4, 5을 이용한 최초의 확장 가능 웹 서버의 원형이다. RRDNS 서버는 round-robin 방식으로 각기 다른 IP 주소들을 하나의 이름에 대응(map)시켜 이상적인 상황에서는 각기 다른 클라이언트들이 클러스터 안의 각기 다른 서버에 접근한다. 이런 방법으로 부하(load)가 서버들 사이에 분산된다. 그러나 클라이언트의 캐싱 (caching)과 DNS 시스템의 상속적 특성 때문에 서버들 사이에 동적 부하 불균형이 초래되기 쉽다. 따라서 서버들의 최고(peak) 부하를 제어하기가 쉽지 않다. PR-DNS에서 이름 대응(name mapping)의 생존 시간(Time To Live, TTL) 값을 잘 선택하기가 어렵다. 적은 값으로는 PR-DNS가 병목을 일으킬 것이고, 높은 값으로는 동적 부하 불균형이 더욱 나빠질 것이다. TTL값을 영으로 설정한다 하더라도 작업 할당의 기초(scheduling granuarity)는 호스트 기반이고, 어떤 사람은 사이트에서 많은 정보를 받아가고, 또 다른 사람은 몇 개의 정보만 흩어보다 가버릴 수 있기 때문에 사용자들의 각기 다른 접속 양식이 동적 부하 불균형을 초래할 것이다. 게다가 서버 노드에 장애가 있거나, 클라이언트들이 IP 주소에 대응되는 서버를 찾아가 그 서버가 사용 불능 상태(down)인것을 발견했을 때 그리 믿을만하지 못하고, 브라우저에서"reload" 나 "refresh" 버튼을 누를때조차 아직 문제가 남아있다.
4. 4. 3 서버 측면의 응용 프로그램 계층 작업 할당 방법
EDDIE6, Reverse-proxy7, pWEB8 그리고 SWEB9는 확장 가능한(scalable) 웹 서버를 구축하기 위해 응용 프로그램 계층 작업 할당(scheduling) 방법을 이용한다. 이들은 모두 HTTP 요청을 클러스터에 있는 다른 웹 서버에 전달한다. 그 후 결과를 얻어 최종적으로 그 결과를 클라이언트 에 돌려준다. 그러나 이런 방법은 각 요구(request)에 클라이언트와 부하 분산기(load balancer) 사이의 접속과 부하 분산기(load balancer)와 서버 사이의 접속의 두개 TCP 접속을 만들어야 하므로 지연(delay)이 높다. 그리고 응용 프로그램 계층에서의 HTTP 요구들과 반응들(replies)을 다루는 간접 비용 또한 높아서 서버 노드의 수가 증가하면 오래 지나지 않아 응용 프로그램 계층의 부하 분산기(load balancer)가 새로운 병목 구간이 된다.
4. 4. 4 서버 측면의 IP 계층 작업 할당 방법
버클리(Berkeley)의 MagicRouter10와 시스코(Cisco)의 LocalDirector11는 다른 서버들상의 병렬 서비스들을 단일 IP 주소상의 하나의 가상 서비스로 보이도록 넷트웍 주소 번역(Network Address Translation) 방법을 사용한다. 부하 분산기(load balancer)가 요청 패킷들(request packets)의 목 적지 주소(destination address)를 바꿔 선택된 서버로 보내준다. 그 후 응답 패킷들(reply packets)의 발생지 주소(source address)를 원래 요청 패킷의 목적지 주소로 바꿔준다. 그러나 MagicRouter는 다른 목적의 사용자에게는 별로 유용하지 않고 LocalDirector는 너무 비싸다. 그리고 이들은 단순히 TCP 전송 규약(protocol) 부분만을 지원할 뿐이다. 이 방법은 리눅스 가상서버에 잘 준비되어 있고 자세한 것들은 다음 장에서 논의할 것이다.
IBM의 TCP router12는 IBM의 확장 가능한(scalable) 병렬 SP-2 시스템에 확장 가능한 웹 서버를 구축하기 위해 변형된 넷트웍 주소 번역 방법(modified Network Address Translation)을 사용한다. TCP router는 요청 패킷들의 목적지 주소를 바꿔 선택된 서버로 보내준다. 이 서버는 응답 패킷들의 발생지 주소를 자신의 주소 대신 TCP router 주소로 넣도록 변형되어있다. 이 변형 방법의 장점은 TCP router가 응답 패킷을 변경(rewriting)해야만 하는 것을 피할 수 있다는 것이다. 단점은 클러스터의 모든 서버들의 커널 코드(kernel code)를 변경할 필요가 있다.
ONE-IP13는 또 다른 IP-계층 작업 할당 방법이다. 이 방법에서는 모든 서버들이 넷트웍에서 그들 자신의 IP 주소를 가지고 IP 별칭 인터페이스(IP alias i
nterface)에 모두 같은 IP 주소를 구성 해야만 한다. 두가지 발송(dispaching) 기술이 사용된다. 한가지는 중앙의 발송기(dispacher)가 IP패킷들을 다른 서버들로 직접 배송(routing)하는 것이고, 다른 하나는 패킷들을 흩뿌려(broadcast) 지역적으로 걸러내는(local filtering) 것이다. 응답 패킷을 변경(rewriting)하는 것을 피할 수 있다는 장점이 있다. 단점은 어떤 운영체제는 넷트웍 인터페이스가 IP 주소 충돌을 발견했을 때 정지(shutdown)하기 때문에 모든 운영체제에 적용할 수는 없다는 것이다. 지역적 걸름(local filtering) 역시 모든 서버의 커널 코드를 변경할 필요가 있다.
4. 5 기존의 클러스터링 방식
4. 5. 1 Round Robin DNS
이 방식은 DNS(Domain Name System)를 부하 분산에 이용하는 것으로, 가장 손쉽게 클러스터를 구성할 수 있다. DNS는 기본적으로 클라이언트가 요청하는 도메인 네임을 IP로 맵핑시켜주는 역할을 하며, 일반적으로 하나의 도메인 네임에 하나의 IP가 할당된다. 그러나 Round Robin DNS를 구성하려면 하나의 도메인 네임에 여러 개의 IP를 할당한다. 그러면 Round Robin DNS는 동일한 도메인 네임으로 서비스를 요청하는 클라이언트에게 각각 다른 IP를 되돌려줌으로써 부하 분산을 수행한다.
현재 대부분의 DNS 소프트웨어는 Round Robin 방식을 지원하므로, 설정 파일 수정만으로도 간단하게 클러스터링할 수 있다. 또한 클라이언트가 처음 도메인 네임에 대해 Resolving할 때만 DNS에 트래픽을 발생시키므로 특정한 서버에 병목현상이 발생되지 않는다. 단 이 방식의 단점은 일반적으로 Round Robin DNS가 서버 상태를 알 수 없다는 것이다. 만일, 서버 가운데 하나가 다운되더라도 Round Robin DNS는 서비스를 계속할 수 없는 서버의 IP를 클라이언트에게 되돌려준다. 이에 따라 일부 사용자에게 서비스가 중단되는 치명적인 결과를 가져온다.
만약 Round Robin DNS에 서버 실패 상황을 감지하는 기능을 추가하더라도, DNS 서버가 도메인 네임에 대한 요청을 캐싱하기 때문에 여전히 문제가 발생한다. 클라이언트와 Round Robin DNS 사이에 있는 중간 DNS 서버는 클라이언트의 요청을 좀더 빠르게 처리하기 위해 한 번 요청받았던 도메인 네임에 대한 IP를 캐시에 저장해 두고 다시 동일한 도메인에 대한 요청은 캐시의 내용을 참조해 응답한다. 이것은 부하 분산의 효과를 저하시키는 요인이 된다. 또한 클러스터 내의 서버 가운데 하나가 다운된 후 관리자가 다운된 서버를 클러스터에서 제거하더라도 여전히 서비스는 일정 시간 중단될 수 있다. 중간의 DNS 서버가 캐싱된 내용을 업데이트하는데 일정 시간이 요구되기 때문이다.
페일오버 기능 수행 : 앞서 언급된 DNS 캐싱 문제를 해결하기 위한 방안으론 가상 IP를 사용해 ‘페일오버(Fail-over)’ 기능을 수행하는 제품을 이용하는 것이 대두되고 있다. 이러한 제품은 한 대의 서버가 과부하로 다운되면, 다른 서버 중 하나가 가상 IP를 사용해 다운된 서버의 IP를 함께 가지고 있는 것이다. 이렇게 되면 중간 DNS에 캐싱된 IP에 대한 요청도 처리할 수 있다. 그러나 여기에도 문제점은 여전히 존재한다. 만일 A, B, C 3대의 서버로 네트워크 서비스를 하는 도중에 서버 A가 과부하로 다운됐다고 가정하자. 서버 B가 A의 백업 서버로 지정됐다면 B는 A의 IP를 가상 IP로 설정해 캐싱된 A의 네트워크 트래픽을 떠맡게 된다. 그러므로 B와 C는 균등한 부하 분산을 할 수 없으며, B 또한 과부하로 연이어 다운될 우려가 크다. 최악의 경우 전체 서버를 과부하로 다운시켜 전체 서비스가 중단되는 사태를 불러올 수 있다.
4. 5. 2 IP 주소 변경하는 NAT 방식
NAT(Network Address Translation) 방식은 패킷 내의 IP 주소를 변경해 부하 분산을 수행하는 방법이다. 먼저 클라이언트에게는 로드 밸런서(Loa d Balancer)의 도메인 네임 또는 IP가 알려져 있다. 클라이언트가 이 알려진 도메인 네임이나 IP를 사용해 로드 밸런서에게 서비스 요청 패킷을 전송한다. 또한 로드 밸런서는 n개의 서버 가운데 하나를 정해진 스케줄링 방법에 의해 선택한 후 패킷 내의 목적지 주소를 해당 서버의 IP로 다시 작성한다. 리얼 서버는 클라이언트의 요청을 처리한 후, 로드 밸런서에게 응답을 돌려준다. 이때 로드 밸런서는 실제 응답의 발신지 주소를 다시 자신의 IP로 변경한 후 클라이언트에 서비스를 제공한다.
이 방식은 로드 밸런서에서 다양한 스케줄링 방법을 사용할 수 있다. 또한 로드 밸런서에게 적절한 페일오버 기능을 부여할 경우, 클러스터 내의 서버가 다운되더라도 이것을 감지해 스케줄링 대상에서 제외하므로 네트워크 서비스가 중단되는 단점을 보완할 수 있다. 그리고 TCP/IP 프로토콜을 지원하는 어떠한 운영체제도 리얼 서버로 사용할 수 있다. 리얼 서버는 사설 IP를 사용해도 되며 오직 부하 분산 서버만 실제 IP를 사용하면 된다.
그러나 확장성에는 제한이 있다. 로드 밸런서는 리얼 서버로 오가는 모든 패킷의 주소를 재작성해야 하므로 병목현상이 발생할 수 있다. 따라서 클러스터를 구성할 수 있는 서버의 개수에 제한을 받는다. 이외에도 로드 밸런서가 다운될 경우 전체 서비스가 중단되는 문제가 발생한다. 이를 방지하기 위해 일반적으로 ‘백업 로드 밸런서’를 두지만, 평상시는 이 고가의 서버를 사용하지 않으므로 낭비 요소가 된다. 방식은 하드웨어나 어플라이언스 형태로 제공되는 경우가 많으며, 대표적인 NAT 방식으로는 레이어4 스위치(OSI 7 계층 모델 가운데 4번 계층인 전송 계층에서 이뤄지는 스위칭 기법을 지원하는 네트워크 장비), 시스코의 로컬 디렉터, LVS(Linux Virtual Server)-NAT 방식 등이 있다.
NAT에 의한 가상 서버의 구조
4. 5. 3 다이렉트 라우팅
다이렉트 라우팅은 리얼 서버와 로드 밸런서가 가상 IP 주소를 공유한다. 로드 밸런서와 리얼 서버는 네트워크 인터페이스에 가상 IP가 설정돼 있어야 하며, 이 인터페이스를 이용해 로드 밸런서는 요청 패킷을 받아들이고 스케줄링에 의해 선택된 리얼 서버로 직접 라우팅 한다.
먼저 클라이언트가 가상 IP로 서비스 요청을 하면 로드 밸런서는 리얼 서버 가운데 하나를 스케줄링한다. 그리고 선택된 서버로 직접 라우팅해 클라이언트의 요청을 리얼 서버로 전달한다. 리얼 서버는 요청 사항을 처리한 후, 로드 밸런서를 거치지 않고 클라이언트로 직접 응답을 한다. 각 리얼 서버는 로드 밸런서와 같은 가상 IP를 공유하고 있기 때문에, 로드 밸런서를 거치지 않고 클라이언트로 직접 응답할 수 있다.
이 방식은 로드 밸런서에서 병목현상이 NAT보다 적게 나타난다. 로드 밸런서의 시스템 환경에 따라 차이가 있겠지만, 이론적으로는 100여 개의 서버를 클러스터로 구성할 수 있다고 한다. 현재 대부분의 운영체제가 가상 IP 설정을 지원하므로 리얼 서버로 사용함에 있어 운영체제에 큰 제한을 받지 않는다. 하지만 로드 밸런서뿐만 아니라 리얼 서버도 각각의 리얼 IP를 가지고 있어야 한다. 그리고 NAT와 마찬가지로 백업 서버를 둬야 하는 부담이 있다. 특히 리눅스를 리얼 서버로 사용하는 경우 ARP 문제(다음 장에서 상세히 설명함)를 해결하기 위해 커널을 수정해 주어야 하는 경우가 있다. 참고로 다이렉트 라우팅 방식을 이용한 제품은 Resonate와 터보 클러스터, LVS-DR 등이 있다.
장점과 단점을 들면, 입력 패킷들(incoming packets)은 언제나 작고 응답 패킷들(reply packets)은 언제나 많은 양의 데이터를 가져가는 (웹 서비스같은) 많은 인터넷 서비스들이 있다. IP 터널링에 의한 가상 서버에서는 부하 분산기(load balancer)가 단지 다른 실제 서버들에 요청들을 작업 할당(schedule)할 뿐이다. 그리고 실제 서버들은 응답들을 사용자에게 직접 돌려준다. 따라서 부하 분산기는 많은 양의 요구들(requests)을 다룰 수 있다: 부하 분산기가 100대가 넘는 실제 서버들에 작업을 배정하여도 시스템의 병목 구간이 되지 않는다. 그러므로 IP 터널링(IP tunneling)을 사용하면 부하 분산기에 최대 서버 노드 수를 대단히 많이 증가시킬 수 있다. 부하 분산기가 단지 100Mbps의 전복조(full-duplex) 넷트웍 어댑터(network adapter)를 가졌다 하더라도 가상 서버의 최대 처리 능력은 1Gbps에 달할 수 있다.
IP 터널링의 성질은 대단히 고성능의 가상 서버를 구척하는데 이용될 수 있고, 가상 프락시 캐쉬 서버(virtual proxy cache server)를 구축하는데 대단히 좋다. 프락시 서버가 요구를 받으면 대상들을 가져오기 위해(to fetch objects) 인터넷에 직접 접근할 수 있고 사용자들에게 그것을 직접 돌려줄 수 있기 때문이다.
그러나 IP 터널링에 의한 가상 서버에서는 실제 서버들이 IP 터널링 전송 규약(IP tunneling protocol)을 지원할 필요가 있다. 이 방법의 특성은 리눅스가 운용되는 서버들에서 시험되었다. IP 터널링 전송 규약이 모든 운영 체제의 표준이 되어가고 있기 때문에 IP 터널링에 의한 가상 서버가 다른 운영 체제에서 운용되는 서버들에서 응용될 수 있게 될 것이다. 하지만 리눅스 이외의 서버에서는 아직 공식적으로 지원되지 않기 때문에 LVS와 Real Server 모두 리눅스이어야 한다는 단점이 있다.
4. 6 작업 할당 방식 (Scheduling Algorithms)
클러스터로부터 서버를 선택하기위한 네 개의 작업 할당 방식들(scheduling algorithms)이 준비되어있다: Round-Robin, 가중치가 있는(weighted) Round-Robin, 최소-접속(Least-Connection) 그리고 가중치가 있는 최소-접속의 방식들이다. 처음의 두 방식들은 서버에대한 어떠한 부하 정보(load information)도 가지고 있지 않기 때문에 자명(self-explanatory)하다. 뒤의 두 방식들은 각 서버에대한 활동 접속 수(active connection number)를 세어 이러한 접속 수에 의해 그들의 부하를 추정한다.
4. 6. 1 Round-Robin Scheduling (라운드 로빈 스케쥴링)
말그대로 라운드-로빈 방식을 이용해 네트웍 연결을 서로 다른 서버에 연결하는 것을 말한 다. 이경우 실제서버의 연결갯수나 반응시간등은 고려를 하지 않는다. 그렇지만 약간의 차이 가 있다. 라운드 로빈 DNS는 단일한 도메인을 서로 다른 IP로 해석을 하지만, 스케쥴링의 기초는 호스트 기반이며 캐싱때문에 알고리즘을 효율적으로 사용하기 힘들다. 그래서 실제 서버사이에 동적인 부하 불균형이 심각해 질수 있다. 가상 서버의 스케쥴링 기초는 네트웍 기반이며 라운드 로빈 DNS 에 비해 훨씬 더 훌륭하다.
4. 6. 2 Weighted Round-Robin Scheduling (가중치기반 라운드 로빈 스케쥴링)
가중치기반 라운드 로빈 스케쥴링은 실제 서버에 서로 다른 처리 용량을 지정할 수 있다. 각 서버에 가중치를 부여할 수 있으며, 여기서 지정한 정수값을 통해 처리 용량을 정한다. 기본 가중치는 1이다. 예를 들어 실제 서버가 A,B,C 이고 각각의 가중치가 4,3,2 일 경우 스케쥴링 순서는 ABCABCABA 가 된다.
가중치가 있는 라운드 로빈 스케쥴링을 사용하면 실제 서버에서 네트웍 접속을 셀 필요가 없고 동적 스케쥴링 알고리즘보다 스케쥴링의 과부하가 적으므로 더 많은 실제 서버를 운영 할 수 있다. 그러나 요청에 대한 부하가 매우 많을 경우 실제 서버사이에 동적인 부하 불균 형 상태가 생길 수 있다.
라운드 로빈 스케쥴링은 가중치기반 라운드 로빈 스케쥴링의 특별한 한 종류이며 모든 가중 치가 동일한 경우이다. 가상 서버의 규칙을 변경하고나서 스케쥴링 순서를 생성하는데는 거의 과부하가 걸리지 않으며 실제 스케쥴링에 어떠한 과부하도 추가하지 않는다. 그러므로 라운드 로빈 스케쥴링만 단독으로 실행하는 것은 불필요한 일이다.
4. 6. 3 Least-Connection Scheduling (최소 접속 스케쥴링)
최소 접속 스케쥴링은 가장 접속이 적은 서버로 요청을 직접 연결하는 방식을 말한다. 각 서버에서 동적으로 실제 접속한 숫자를 세어야하므로 동적인 스케쥴링 알고리즘중의 하나이다. 비슷한 성능의 서버로 구성된 가상 서버는 아주 큰 요구가 한 서버로만 집중되지 않기 때문에, 접속부하가 매우 큰 경우에도 아주 효과적으로 분산을 한다.
가장 빠른 서버에서 더 많은 네트웍 접속을 처리할 수 있다. 그러므로 다양한 처리 용랑을 지닌 서버로 구성했을 경우에도 훌륭하게 작동 한다는 것을 한눈에 알 수 있을 것이다. 그렇지만 실제로는 TCP의 TIME_WAIT 상태때문에 아주 좋은 성능을 낼수는 없다. TCP의 TIME_WAIT는 보통 2분이다. 그런데 접속자가 아주 많은 웹 사이트는 2분동안에 몇천개의 접속을 처리해야 할 경우가 있다. 서버 A는 서버 B보다 처리용량이 두배일 경우 서버 A는 수천개의 요청을 처리하고 TCP의 TIME_WAIT 상황에 직면하게 된다. 그렇지만 서버 B는 몇천개의 요청이 처리되기만을 기다리게 된다. 그래서 최소 접속 스케쥴링을 이용할 경우 다양한 처리용량을 지난 서버로 구성되었을 경우 부하분산이 효율적으로 되지 못할 수 있는 것이다.
4. 6. 4 Weighted Least-Connection Scheduling (가중치 기반 최소 접속 스케쥴링)
가중치 기반 최소 접속 스케쥴링은 최소 접속 스케쥴링의 한 부분으로서 각각의 실제 서버에 성능 가중치를 부여할 수 있다. 언제라도 가중치가 높은 서버에서 더 많은 요청을 받을 수 있다. 가상 서버의 관리자는 각각의 실제 서버에 가중치를 부여할 수 있다. 가중치의 비율인 실제 접속자수에 따라 네트웍 접속이 할당된다. 기본 가중치는 1이다.
가중치가 있는 최소 접속 스케쥴링은 다음과 같이 작동한다:
n개의 실제 서버가 있는 경우 각 서버 i는 가중치 Wi (i = 1, ... , n)를 가진다고 가정하자. 서버 i의 활동 접속(active connection)은 Ci (i = 1, ... , n)이고 모든_접속 은 Ci (i = 1, ... , n)의 합이다. 서버 j로 가는 넷트웍 접속은 아래와 같다.
(Cj/ALL_CONNECTIONS)/Wj = min { (Ci/ALL_CONNECTIONS)/Wi } (i=1,..,n)
이 비교에서 ALL_CONNECTIONS는 상수이므로 Ci를 모든_접속 으로 나눠줄 필요가 없다.그러면 다음과 갈이 최적화될 것이다.
Cj/Wj = min { Ci/Wi } (i=1,..,n)
가중치가 있는 최소 접속 스케쥴링 알고리즘은 최소 접속 스케쥴링 알고리즘에 비해 부가적인 배분작업이 필요하다. 서버들이 같은 처리 용량을 가졌을때는 작업 할당의 간접 비용을 최소화하기위해 최소 접속 스케쥴링과 가중치가 있는 최소 접속 스케쥴링 알고리즘 둘 다 사용할 수 있다.
4. 7 고 가용성
중요한 상업적 응용 분야가 인터넷으로 점점 더 많이 옮아옴에 따라 가용성이 높은 서버들을 제공하는 것이 점점 더 중요해지고 있다. 클러스터화된 시스템의 장점중 하나는 하드웨어와 소프트웨어의 여유분이 있다는 것이다. 높은 가용성은 노드(node)나 데몬(deamon)의 장애들(failures)이나 시스템의 재구성(reconfiguring)을 적절히 감지해 클러스터에 남아있는 노드로 작업 부하(workload)를 이전하는 것으로 이룰 수 있다. 가상 서버의 높은 가용성을 현재 "mon"과 "fake" 소프트웨어를 사용해 제공한다. "mon"은 넷트웍 서비스 가용성과 서버 노드를 모니터할 수 있는 범용 자원 모니터링 시스템(general-purpose resource monitoring system)이다. "fake"는 ARP 속이기(spoofing)를 사용해 IP를 이전하는 소프트웨어다.
서버의 장애 극복(failover)은 다음과 같이 제어한다: 부하 분산기(load balancer)에 클러스터의 서비스 데몬들과 서버 노드들을 모니터하기 위한 "mon" 데몬이 운영된다. 매 t 초마다 서버 노드들이 살아있는지 감지하도록 fping.monitor를 구성하고 매 m 분마다 모든 노드의 서비스 데몬들을 감지하기 위해 연관된 모니터 프로그램 역시 구성한다. 예를 들어 http 서비스를 점검하기위해 http.monitor를, ftp 서비스를 위해 ftp.monitor를 또, 기타 다른 모니터 프로그램을 사용할 수 있다. 서버 노드나 데몬이 새로 사용 불능 상태(down)가 되거나 사용 가능 상태(up)가 되면 가상 서버 테이블에 규칙을 제거하거나 추가하기위한 경보가 작성된다. 따라서 부하 분산기가 서비스 데몬이나 서버를 제거하거나 복구되었을 때 서비스에 추가하는 것을 자동으로 할 수 있다.
이제 부하 분산기는 장애가 있으면 전체 시스템에 영향을 미치는 곳(single failure point)이 되었다. 부하 분산기의 장애를 방지하기 위해 부하 분산기의 백업(backup) 서버를 설치한다. 부하 분산기에 장애가 있을 때 부하 분산기의 IP 주소를 백업 서버로 이전하기위해 "fake" 소프트웨어가 사용된다. 또, 백업 서버에서는 부하 분산기의 상태를 검사하여 "fake"를 실행하거나 실행 중단하기위해 "mon"을 사용한다. "mon" 데몬은 백업 서버에서도 또한 운용되어 백업 서버가 클러스터의 현재 상태를 알고 있어야 한다. 주 부하 분산기에 장애가 있을 때 백업 서버가 그 IP 주소(들)를 인수하여 서비스들을 계속 제공한다. 그러나 해쉬 테이블의 성립된 접속(established connection)은 소멸되며 클라이언트들은 그들의 요구들(requests)을 다시 보내야할 필요가 있다.
4. 8 문제점
현재의 로드 밸런서 시스템은 일반적으로 5분의 주기로 현재의 Load를 감시 하여 스케줄링에 반영하나 이는 5분이내의 급격한 클라이언트로부터의 요청을 처리하는데 있어서의 문제점이 있다. 이는 또한 급격한 부하의 증가로 인하여 서버의 다운시 다운된 서버의 Load를 다른 서버로 전환하기 때문에 다른 서버의 다운을 야기 할 수 있으므로 최악의 경우 웹 서버 전체의 다운을 가져올수 있다.
현재의 로드 밸런서 시스템에 있어서의 가중치에 대한 고려사항은 단지 전체 접속자 수에 대한 각각의 리얼 서버의 접속자 수로서 서버의 성능 및 현재 서버의 부하에 대한 반영이 불가능하다.
서버의 성능은 항상 같을 수 없으므로 각각의 가중치를 부여 하여야 하지만 이에 대한 방안이 없다.
4. 9 LVS의 장단점
LVS 시스템은 별도의 하드웨어 추가 없이 기존의 네트워크 스위치와 서버들 만으로 대규모 인넷 서비스 처리 요청에 대해 훌륭한 해답을 제시한다.
그러나 LVS와 관련 프로젝트는 몇가지 문제점이 있다. 우선 LVS는 사용이 쉽지 않다. 처리 용량이나 가중치의 설정이라거나, 서버 추가나 제거시 관리자가 이를 위해 일일이 시스템을 재설정해야 하는 문제가 있다. 또한 LVS의 자매 프로젝트인 HA는 고가용성 요구에 대한 해결책으로 보기에는 한계가 있다. 또, 단일 클러스터 내에 여러 개의 로드 밸런서의 설정이나 서브 클러스터의 구성 등, 기능성과 접근성에서 기존 L4 스위치와 비교하기엔 무리가 있다.
5. 프로젝트 목표
- 정규화된 자료제시로 확장성 높은 고가용성 클러스터 구축
- 시스템 모니터링을 통한 효율적인 서버관리 방안 제시
- 다양한 실험을 통한 수치해석으로 웹서버의 각 변수간 상관관계 분석
- 분석된 자료를 통한 최적의 클러스터링 웹서버 구현방향 제시
6. 프로젝트 내용
6. 1 이 슈
- 적정수위와 위험 수위를 두어 위험 수위를 넘을 경우 로드 밸런서에 통보.
- 로드 밸런서는 가중치를 재 계산 하여 다른 리얼 서버에 분배
- 서버별 절대 가중치 : a(CPU)*b(Memory)
- 서버별 상대 가중치 : CPU점유율*Memory사용율/전체 Memory
- 가중치 지수 : (Ci/Sum)/Wi
- 메모리 : 총 메모리 (고정값), 사용중인 메모리
- CPU : 타입(고정값), 점유율
- 기 타 : 스토리지 SeekTime, 트래픽, 접속자 수
6. 2 프로그램 흐름도(컨트롤러)
Client Daemon은 자신의 상태를 모니터 하고 적정수위 및 위험수위의 초과시 서버로 소켓을 통하여 자신의 상태를 전달한다. 이때 상태정보의 수집은 /proc을 통하여 정보를 수집하고 자료화된 적정수위와 위험수위를 통하여 자신의 상태를 결정한다.
프로그램 흐름도(컨트롤러)
리얼서버는 자신의 상태가 적정수위를 복구하였을 경우 로드 밸런서에 다시 자신이 웹서비스를 할 수 있음을 보내줌.
프로그램 흐름도 (컨트롤러)
로드 밸런서의 Server Daemon은 리얼서버의 자료를 종합하여 스케줄링에 있어서의 가중치를 변경함으로서 서버의 다운을 방지할 수 있다.
프로그램 흐름도 (모니터)
Client Daemon으로 부터의 정보를 Client Daemon은 log를 기록하고 http를 생성하여 Server Daemon은 이정보를 http로 제공할 수 있다. 또한 서버의 운영자는 원격지에서 인터넷 페이지를 통하여 현재 로드 밸런서의 상태와 리얼서버의 상태를 모니터링 할수 있으며 차후 제어에 대한 부분도 반영할 것임
6. 3 Server/Client 데몬
로드밸런서 컨트롤 부분 분석 및 동작원리 파악 & Server/Client 데몬 작성
-Client Daemon
Client Daemon은 리얼 서버의 CPU 점유율, Memory 사용율 및 네트워크의 트래픽을 모니터하며 이 정보를 통합하여 서버의 적정수준 및 위험 수준을 서버로 소켓을 형성하여 보고한다.
-Server Daemon
Client Daemon로부터의 정보를 이용하여 로드 밸런서의 가중치를 변경하여 이를 로드 밸런싱에 반영 함으로써 Dynamic한 로드 밸런서의 구현이 가능하다.
-클라이언트의 상태 정보 서버로 전송
-취합된 정보를 이용하여 능동적으로 LVS 설정 및 변경
6. 4 X-Window 기반 모니터링 / 컨트롤러 툴
X-Window 기반 유저 인터페이스 컨트롤러 및 모니터링 툴 제작
X-Window상에서 리얼서버의 삽입, 삭제 및 변경
6. 5 웹기반 모니터링 / 컨트롤러 툴
통계분석 출력 및 기본화면 구성 및 컨트롤 / 모니터링 기본골격 제작
클라이언트의 상태를 웹상에서 출력
웹상에서 리얼서버의 삽입, 삭제 및 변경
6. 5 5가지 방식의 테스트 페이지 작성
- 기본적인 텍스트로 구성된 페이지
(23KB, 70KB, 100KB, 200KB 의 페이지 구성)
- 이미지 및 사운드가 포함된 페이지
(1.5MB, 2.3MB, 3.0MB, 4.5MB 의 페이지 구성)
- 대용량 테스트 페이지
(Ftp기능이 포함된 페이지로 대용량의 파일 전송 )
- 스크립트 파일이 있는 페이지
(서버내의 모듈로 포함되어 있는 펄, PHP등 다양한 스크립트로 페이지 구성)
- 종합적인 페이지
(실제적으로 사용되어지는 페이지 구성)
6. 6 테스트 웹브라우저 작성
웹 서버의 부하의 상태를 시뮬레이션하기 위해 서버의 부하를 증가시키기 위한 실제에 근사한 에뮬레이트 툴 제작
- 부하를 임의적으로 생성하기 위해 8개의 독립적인 브라우징 지원
- 페이지를 읽고 난 후 읽은 시간을 측정하여 데이터 생성
6. 7 다양한 상황에서의 부하측정
접속자 수를 변화시키며 접속자 증가율에 따른 메모리 사용량, CPU 로드 증가율, 트래픽 증가율 측정
6. 7. 1 리얼서버 수치 해석을 위한 테스트 환경
3-111호의 PC를 이용하여 특정시간에 동작
(최대 64까지 8개 단위로 측정)
6. 7 .2 단일서버하에서 부하 측정
기준이 되는 서버에서 부하를 측정하되 테스트 홈페이지의 페이지들을 각각 접속자가 2에서 64명까지 2, 4, 8, 16, 32, 64명 단위로 측정한다. 측정은 각 10회 이상으로 하며 각 측정값을 기록하여 보간측정에 사용할 수 있도록 한다. 측정값으로는 접속자 증가율에 따른 메모리 사용량, CPU로드 증가율, 트래픽 증가율 등이 있다. 그리고 기준이 되는 서버의 사양을 달리하여 다시 측정한다. 이런식으로 데이터를 산출하게 되면 3차원 배열로 나타나게 될 것이다. 3차원 데이터는 선형 회귀분석을 하여 입체적인 근사값을 산출하게 된다.
스크립트가 제외된 텍스트문서 메모리 사용량 텍스트 결과(단위 : KB)
CPU
접속자 수
64MB
128MB
256MB
512MB
1GHz
2
67
60
53
51
1GHz
4
134
129
124
122
1GHz
8
165
160
159
154
1GHz
16
170
170
168
160
1GHz
32
178
178
175
171
1GHz
64
184
184
183
178
이미지가 포함된 텍스트문서 메모리 사용량 텍스트 결과(단위 : KB)
CPU
접속자 수
64MB
128MB
256MB
512MB
1GHz
2
124
122
120
116
1GHz
4
256
255
252
248
1GHz
8
287
286
284
275
1GHz
16
320
316
316
310
1GHz
32
329
329
328
321
1GHz
64
335
335
334
329
스크립트가 구성된 문서 메모리 사용량 텍스트 결과(단위 : KB)
CPU
접속자 수
64MB
128MB
256MB
512MB
1GHz
2
791
783
745
734
1GHz
4
810
822
783
764
1GHz
8
872
869
861
859
1GHz
16
842
816
808
788
1GHz
32
858
826
816
801
1GHz
64
840
811
795
810
접속자와 CPU에 따른 스크립트 실행시간
접속자수
Cel-333
P2-400
P3-1000
1GHz
3
3
1
1GHz
5
5
1.5
1GHz
11
10
2
1GHz
20
18
4.9
1GHz
41
39
8.8
1GHz
103
71
13.1
6. 7. 3 실제 사용된 스크립트 코드
$start=time(); 현재 시간을 start라는 변수에 저장
for($i=1;$i<500000;$i++) loop문
{}
$end=time()-$start; 현재시간에서 start를 뺀 값을 end라는 변수에 저장
echo "Time : $end"; end 출력
?>
6. 8 선형 회귀분석 및 보간함수 산출
각종 데이터를 선형 회귀분석을 하여 보간함수를 산출한다. 회귀분석은 뉴톤방식을 사용하며 보간함수 역시 뉴톤방식을 사용한다.
- 메모리에 대한 접속자 증가에 따른 변화에 대한 함수
X
Y
f[X0, X1]
f[X0, X2]
f[X0, X3]
0
64
835
-0.219
0.00033
0
1
128
821
-0.156
0.00032
2
256
801
-0.035
3
512
792
∴ P5(x)=0.00033x2-0.28236x+851.71936
접속자 증가에 따른 메모리 사용량은 거의 선형으로 증가하며 기울기 역시 거의 0에 가깝다.
- CPU속도에 따른 접속자 증가에 따른 실행속도 변화에 대한 함수
P6(x)=-0.0000034x5+0.0004008x4-0.0144228x3+0.1924916x2+0.2086584x+1.7354112
실행속도의 변화는 접속자 수가 커지면 커질수록 실행속도 역시 커지는 tan곡선에 가깝다.
6. 9 데이터 검증
산출한 함수식이 적합한지 검증하기 위해 700Mhz에 대해 검증
접속자가 많아짐에 따라 실제값에 점근
6. 10 웹서버의 부하 집중시 Defunct 발생 빈도수 측정
6. 10. 1 테스트 환경
- 단일서버
펜티엄 500MHz에서 웹서버 구축
펜티엄 700MHz에서 웹서버 구축
펜티엄 800MHz에서 웹서버 구축
펜티엄 1GHz에서 웹서버 구축
- 부하분산서버
펜티엄 1GHz에서 로드밸런싱
단일서버 4대로 리얼서버 구성
6. 10. 2 CPU에 대한 상대적인 수치 표현 방식
6. 10. 3 iCOMP 지수
-인텔에서 발표하는 CPU들에 대한 상대적인 성능에 대한 수치로 CPU속도가 아닌 iCOMP지수를 이용하여 측정
-500MHz(1650), 700MHz(2420), 800MHz(2690), 1000MHz(3280)
6. 10. 4 단일서버시 접속자수에 따른 Defunct 빈도
Defunct 발생횟수
구분
P3-500(1650)
P3-700(2420)
P3-800(2690)
P3-1000(3280)
32
0
0
0
0
64
8
1
1
0
96
12
3
3
1
128
17
12
11
7
Defunct
-서버와의 접속이 장애로 인하여 끊긴 상태
-원인은 서버의 과부하 및 네트워크 장애등 다양한 변수가 존재
TimeOut
-클라이언트의 요청을 처리중 시간의 타임아웃으로 접속이 종료
6. 10. 5 단일서버시 접속자수에 따른 Defunct의 발생 수
이론적으로 228명의 접속자가 동시 접속시까지 Defunct는 발생하지 않는다
6. 11 단일서버시 접속자수에 따른 Upper Bound 함수
함수 수치 산출방법
CPU
P3-500(1650)
P3-700(2420)
P3-800(2690)
P3-1000(3280)
최종발생시점
40
50
58
80
Upper Bound 함수
F(x)=-0.000000004x3+0.00004204x2-0.1078152x+121.40968
6.12 로드밸런서 컨트롤러에 쓰이는 함수
가중치 부여 함수
- 엔트리에 등록된 리얼서버중 가장 성능이 낮은 서버를 가중치 1로 계산
- 다른 엔트리에 등록된 리얼서버는 성능이 낮은 서버의 상대치로 계산
Upper/Lower Bound 측정 함수
- 해당 CPU에 따른 측정함수 구간을 생성하여 접속자구간 산출
- Upper Bound 초과시 로드밸런서에 시그널 송출
- Lower Bound 미만시 로드밸런서에 시그널 송출
7. 최종결론
현재 산출된 데이터를 이용하여 LVS가중치 계산에 적용 실험식 생성 및 최종적으로 클라이언트가 느끼는 체감 시간과 서버의 상태를 이용하여 Real Server의 한계치 및 Upper Bound와 Low Bound 산출하여 최적의 웹서비스 환경 구축
웹서비스의 가중치 및 상이한 서버간의 처리능력 계량화로 웹서비스 설계시 구체적인 기틀 마련
| |
|
|
즐겨찾기
상담 채팅: 접속자(1)