KR101409561B1

KR101409561B1 - 데이터 부하 밸런싱 장치 및 방법

Info

Publication number: KR101409561B1
Application number: KR1020137000346A
Authority: KR
Inventors: 루크 티시옌; 휴고 버밴드트
Original assignee: 알까뗄 루슨트
Priority date: 2010-06-08
Filing date: 2011-06-01
Publication date: 2014-06-19
Also published as: WO2011154311A1; EP2395710B1; EP2395710A1; CN102918813A; JP2013528336A; CN102918813B; JP5632074B2; KR20130032354A; US20130080517A1

Abstract

본 발명은 IMS(IP Multimedia Subsystem)의 네트워크에서 데이터 트래픽 부하 분산을 결정하는 방법에 관한 것으로, 여기서 네트워크는 클라이언트 소스 노드 및 적어도 2개의 서버 목적지 노드를 포함한다. 적어도 2개의 서버 목적지 노드는 데이터 전송 요청을 처리하는 용량이 서로 다르다. 이 방법은, - 클라이언트 소스 노드가, 클라이언트-서버 프로토콜에 따라서 네트워크를 통해서 데이터 전송 요청을 적어도 2개의 서버 목적지 노드로 송신하는 단계와, - 적어도 2개의 서버 목적지 노드 각각이, 요청에 응답해서, 자신의 실용량의 상태에 대한 표시를 전송하는 단계와, - 상기 클라이언트 소스 노드가 이 상태 표시를 이용해서 서버 목적지 노드에 대해 데이터 트래픽의 부하 분산을 결정하는 단계를 포함한다.

Description

데이터 부하 밸런싱 장치 및 방법{DEVICE AND METHOD FOR DATA LOAD BALANCING}

본 발명은 전반적으로 분산형 네트워크 시스템에서의 데이터 트래픽 부하 밸런싱에 관한 것이다. 상세하게는, 이러한 부하 밸런싱을 수행하는 방법 및 장치에 관한 것이다.

분산형 네트워크 시스템에 부하 밸런싱(부하 셰어링이라고도 함) 알고리즘을 적용하는 것은 널리 공지되어 있다. 이러한 분산형 네트워크는 예컨대, IMS(IP Multimedia Subsystem)가 IP 멀티미디어 서비스를 고정 단말 및/또는 이동 단말에 제공할 때 이용하는 통신 네트워크가 될 수 있다. 단말이 IMS에 등록되면, 그 이후에 단말은 멀티미디어 서비스를 요청할 수 있다. IMS는 애플리케이션 서버를 이용해서 단말을 등록하고, 요청한 서비스를 단말에 제공한다. 다수의 애플리케이션 서버가 동시에 같은 단말에 서비스를 제공할 수 있다.

이러한 IMS는 전형적으로 다양한 기능을 가진 다수의 노드를 포함하고 있다. 제 1 노드의 세트는 네트워크를 통한 통신의 라우팅에 관한 것이다. 이러한 노드의 예로는, 네트워크에 대한 프록시로서의 역할을 할 수 있는 다양한 CSCF(Call Session Control Functions)를 들 수 있으며, 이는 인증 및 승인을 체크하고, 특정 유저의 메시지가 네트워크 내의 적절한 노드에 확실하게 도달하게 하는 혹은 그 반대로 하게 할 수 있다. 제 2 타입의 노드는 상기 설명한 애플리케이션 서버(AS)에 관한 것으로, 이는 IMS 네트워크의 유저에게 특정 서비스를 제공하는 것이다. 이러한 서비스의 범위는 존재 및 위치(presence and location)로부터 셀룰러 네트워크 서비스를 통한 푸시 투 토크와 같은 더 특정한 서비스까지가 될 수 있다. 제 3 타입의 노드는 유저 관리, 및 계좌 번호, 인증 정보, 특정 유저와 관련된 서비스, 특정 유저에게만 가능 혹은 불가능한 네트워크 옵션 등의 유저 관련 정보의 저장에 관한 노드이다. 제 3 타입의 노드의 전형적인 예가 HSS(Home Subscriber Server)로, 이는 IMS 네트워크에서 유저 프로필 및 다른 유저 관련 정보의 대용량 데이터베이스로서의 역할을 한다. HSS에서, 등록된 단말이 제공하는 식별자가 검색된다. HSS는 단말 식별자의 유효성을 확인한다.

AS나 CSCF와 같은 IMS 네트워크 내의 노드는 HSS와 통신해서, HSS로부터 특정 유저에 관한 정보를 검색할 수도 있고, HSS에 정보를 제공할 수도 있으며, 이는 HSS에 저장되거나 혹은 저장된 특정 유저에 관한 정보를 갱신하는데 이용된다. HSS의 TISPAN/3GPP 사양에서는, 인증, 승인, 과금 등에 이용되는 유저 관련 정보에 더해서, 유저에 대한 애플리케이션 특정 정보를 HSS에 저장할 수 있게 한다.

부하 밸런싱 알고리즘이 적용되어서, 클라이언트 소스 노드로부터 서버 목적지 노드로 데이터를 전송하는 여러 경로로 트래픽을 분산시킴으로써, 리소스의 사용을 최적화시킨다. 부하 밸런싱 판정은 클라이언트 혹은 프록시 노드의 아웃바운드 인터페이스에 대해 행해지는 것이 전형적이며, 따라서 부하 밸런싱은 아웃바운드 인터페이스에 구성되어야 한다.

종래의 부하 셰어링 알고리즘(라운드 로빈, 순차형, 순환형, 랜덤 등)은 모든 리셉터(receptors)가 동일한 용량을 갖고 있는 구성에서는, 즉 부하가 다수의 목적지 노드에 균일하게 확산되어야 하는 경우에 잘 동작한다. 수집 용량(즉, 서버 용량)은 리소스가 클라이언트 노드로부터 들어오는 요청을 수신해서 처리할 수 있는 정도를 나타낸다. 리소스는 연산력, 메모리 크기, 저장량 등에 대응한다.

도 1에 도시된 종래의 라운드 로빈에서는, 클라이언트-서버 구성의 서로 다른 컬렉터(서버)에 부하를 균일하게 분산시킨다. 개개의 서버 노드의 수집 용량은 고려하지 않는다. 도 1에 도시된 바와 같이, 노드의 수집 용량이 서로 다른 경우에는 개개의 노드 레벨의 부하는 서로 다르게 된다. 도면에서 직선은 이 구성에서의 동일한 부하 셰어링을 나타낸다. 도 1의 예에는, 4개의 노드에 대한 다양한 상대적인 부하 비율이 도시되어 있다.

그러나, 수집 용량이 서로 다른 서버 노드가 포함되어 있는 구성인 도 2에 도시된 상황에서는, 종래의 라운드 로빈을 선택하면, 동일한 부하 셰어링이 특정 레벨을 초과한 경우에, 수집 및 처리 용량이 낮은 노드에서는 일시적인 과부하 상태가 발생할 수 있다. 이후에 서버는 응답이 처리될 수 없다는 것을 나타내는 불 응답(Boolean responses)(예컨대, '공간 없음'을 의미함)을 리턴한다. 송신부(클라이언트 노드)는 새로운 컬렉터(즉, 서버 노드)를 선택해서, 요청을 재송신해야 한다. 이는 분명히 네트워크의 전체 트래픽을 증가시키고, 리소스의 이용 효율을 저하시킨다.

따라서, 현존하는 알고리즘은 특정한 상황 및 환경하에서는 여러가지 제한을 갖고 있다. 구성이 커지면, 확장시에 최상의 비용/효율비를 가진 노드를 통해서 확장되는 것이 이상적일 것이다. 많은 심지어 대부분의 경우에, 이는 다양한 제조사들의, 개선되었으며, 더욱 성능이 우수하고, 더 고용량이지만 서로 성능은 다른 플랫폼 및/또는 제품과, 용량 특성이 서로 다른 제품에 대응할 것이다. 따라서, 이러한 멀티-노드 구성은 균일하지 않을 것이다. 여러 종류의 노드로 이루어진 이러한 확장 구성은 상술한 바와 같은 종래의 기술의 해법으로는 적절하게 처리할 수 없다.

또한, 구성의 일부 노드의 용량을 서로 다른 기능(혹은 애플리케이션)이 공유하게 되면, 성능 저하가 발생할 수 있다. 현재의 선택 알고리즘은 천이 상태를 고려하고 있지 않다. 종종 트래픽이 낮은 시간에 배치(batch) 처리가 스케쥴링되어서, 수집에 최소의 서버 용량만을 이용할 수 있게 되는 것을 방지한다.

서버 노드의 용량을 고려해서 부하가 분산되어야 하는 혼합형(즉 서로 다른 용량) 구성에서 종래의 부하 셰어링을 행하는 경우에, 모든 송신부는 선택 규칙(예컨대, 부하 셰어링 규칙의 파퓰레이션(population))에 따라서 사전에 구성되어야 한다. 이러한 파퓰레이션은 전형적으로 고정식이다. 일괄 작업(batch job) 등의 다른 처리에 의해서 특정 노드에 추가적인 부하가 발생하면, 천이 과부하 상태가 발생할 수 있고, 이는 고정식 부하 분산으로는 해결할 수 없다.

대부분의 시스템은, 응답에 포함된 (불(Boolean)) 표시('양호함(OK)' 혹은 '양호하지 않음(not-OK)'을 의미함)에 의존해서 다음 선택을 결정한다. 이들 백오프(back-off) 응답은 분명히 추가 부하를 야기시킨다. 과부하 트래픽은 부하 레벨에 따라 증가한다(부정적인 응답이 더 많을수록). 불 온/오프 응답은 동작을 변동시킬 수 있으며, 이는 불안정성을 유발시킬 수도 있고, 우아한 성능 저하(graceful degradation)가 아닌 붕괴를 유발할 수 있다. 또한, 저용량 서버 노드가 상대적으로 더 많은 트래픽을 받으므로, 이용 가능한 용량이 비효율적으로 이용된다.

고정식 부하 분산 규칙의 예는 EP 2139195에 개시되어 있으며, 여기서 단말을 애플리케이션 서버에 등록하는 해법이 제안된다. 예컨대, 서버 그룹 사이에 부하 밸런싱을 취하기 위해서 사용될 수 있는, 고정된 사전 결정된 규칙의 세트가 제공된다.

상기 설명한 문제가 발생할 수 있는 전형적인 예가, 다수의 데이터 생성부가 다수의 데이터 컬렉터로 기록을 전송하는 3GPP Rf 인터페이스이다. 다른 예는 3GPP Cx 인터페이스로, HSS에 액세스하는데 다수의 FEP(Front End Processes)가 이용된다. 다른 인터페이스, 프로토콜, 환경도 가능하며, 당업자라면 이해할 것이다.

본 발명은 용량이 서로 다른 노드를 포함하는 구성에서 부하 밸런싱을 이용할 때 적용될 수 있으며, 종래의 해법의 제한을 극복한 방법 및 장치를 제공하는 것을 목적으로 한다.

본 발명은 IMS의 네트워크에서 데이터 트래픽 부하 분산을 결정하는 적절한 방법에 관한 것이다. 이 네트워크는 클라이언트 소스 노드 및 적어도 2개의 서버 목적지 노드를 포함하며, 여기서 적어도 2개의 서버 목적지 노드는 데이터 전송 요청을 처리하는 용량이 서로 다르다. 이 방법은

- 클라이언트 소스 노드가, 클라이언트-서버 프로토콜에 따라서 네트워크를 통해서 데이터 전송 요청을 적어도 2개의 서버 목적지 노드로 송신하는 단계와,

- 적어도 2개의 서버 목적지 노드 각각이, 요청에 응답해서, 자신의 실용량의 상태에 대한 표시를 전송하는 단계와,

- 클라이언트 소스 노드가 이 상태 표시를 이용해서 서버 목적지 노드에 대해 데이터 트래픽의 부하 분산을 결정하는 단계

를 포함한다.

아울러, 제안된 해법은 본 발명의 목적을 만족시킨다. 클라이언트 노드가 데이터 트래픽을 전송하기 위한 리소스를 요청할 때마다, 서버 목적지 노드는 자신의 실제 상태의 표시, 예컨대 이용가능한 최대 용량 중 사용되고 있는 비율(혹은 비어있는 비율)를 제공한다. 서버 노드로부터 얻은 정보로부터, 리소스를 요청한 클라이언트 노드에 의한 다음 데이터 트래픽 전송을 고려해서 부하를 어떻게 밸런싱시킬지가 판정될 수 있다. 이 판정은 클라이언트 노드가 요청한 데이터 전송에 어느 서버 노드가 이용될지를 나타낸다.

바람직한 실시예에서, 실용량의 상태에 대한 표시는 사용되는 용량의 양 혹은 자유 용량의 양을 나타낸다.

실용량의 상태는 바람직하게는 적어도 메모리 크기, CPU 처리 시간 혹은 이들 파라미터의 조합을 고려해서 결정된다.

다른 실시예에서, 네트워크는 클라이언트 소스 노드와 서버 목적지 노드 사이의 접속을 설정하는 프록시 노드를 더 포함한다.

제 2 측면에서, 본 발명은 IMS의 네트워크에서 사용되는 인터페이스 장치에 관한 것으로, 여기서 네트워크는 클라이언트 소스 노드 및 적어도 2개의 서버 목적지 노드를 포함하고, 이 적어도 2개의 서버 목적지 노드는 데이터 전송 요청을 처리하는 용량이 서로 다르다. 이 인터페이스 장치는

- 적어도 2개의 서버 목적지로부터로부터 자신 실용량의 상태에 관한 표시를 수신하는 수신 수단과,

- 수신한 상태 표시에 기초해서 목적지 노드에 대한 부하 분산을 결정하는 처리 수단과,

- 결정된 부하 분산을 클라이언트 소스 노드로 통신하는 통신 수단

을 포함한다.

바람직하게는, 처리 장치는 부하 밸런싱 알고리즘을 수행하도록 배치되고, 상태 표시는 가중 인자로서 이용된다.

또 다른 실시예에서, 인터페이스 장치는 수신한 상태 표시를 저장하기 위한 저장 수단을 더 포함한다.

가장 바람직한 실시예에서, 인터페이스 장치는 RADIUS 혹은 다이어미터 프로토콜에 따라서 동작하도록 배치된다.

본 발명은 또한 IP 멀티미디어 서브시스템, IMS의 네트워크에서 사용될 클라이언트 소스 노드에 관한 것으로, 상술한 바와 같은 인터페이스 장치를 포함한다.

도 1은 공지된 종래의 라운드 로빈 알고리즘을 나타내는 도면,
도 2는 도 1에 도시된 종래의 해법의 한계를 나타내는 도면,
도 3은 다이어미터 프록시 노드의 셋업을 나타내는 도면,
도 4는 본 발명의 예시적인 애플리케이션을 나타내는 도면,
도 5는 다이어미터 리다이렉트 동작을 나타내는 도면,
도 6은 라운드 로빈 알고리즘(종래의 기술)의 성능을 나타내는 도면,
도 7은 본 발명에 따른 해법의 성능을 나타내는 도면이다.

본 발명에서, 클라이언트-서버 구성에서 네트워크로 멀티미디어 서비스를 제공하는데 IMS가 고려된다. 서버 노드가 모두 동일한 서버 용량을 갖고 있는 것은 아니다. 서버에서 용량이란, CPU 시간, 메모리 크기, CPU와 메모리 크기의 조합, 몇가지 시스템 측정값의 조합 등과 관련된 용량을 의미한다. 본 명세서에서 용량은 미래의 (유사한) 요청을 처리하는 능력을 나타낸다.

가장 바람직한 실시예에서, 클라이언트-서버 구성은 다이어미터 프로토콜 혹은 다이어미터의 이전 모델인 RADIUS에 따라서 동작하도록 배치된다.

RADIUS(Remote Authentication Dial In User Service)는 컴퓨터가 네트워크 서비스에 접속해서 이를 이용하는데 있어서의 중앙 집중된 AAA(Authentication, Authorization, and Accounting) 관리를 제공하는 네트워킹 프로토콜이다. RADIUS 프로토콜의 브로드 지원 및 유비쿼터스 특성으로 인해서, 이는 종종, 인터넷 서비스 제공자 및 기업이 인터넷 혹은 내부 네트워크, 무선 네트워크 및 통합 이메일 서비스에 대한 액세스를 관리하는데 이용된다. RADIUS는 전송 수단으로서 UDP를 이용하는 애플리케이션 계층에서 실행되는 클라이언트/서버 프로토콜이다. RADIUS는 3가지 기능 즉, 유저의 네트워크 액세스를 허가하기 전에 유저 혹은 장치를 인증하는 기능, 특정 네트워크 서비스에 대해서 이들 유저 혹은 장치를 인증하는 기능 및 이들 서비스의 이용에 대한 과금 기능을 제공한다. RADIUS를 통해서는 원격 액세스, IP 유동성 및 정책 제어를 효율적으로 처리할 수 없다.

다이어미터 프로토콜은 RADIUS의 업그레이드 경로를 제공한다. 다이어미터는 인증부와 인증을 요청한 임의의 네트워크 엔티티 사이의 통신을 제어한다. 다이어미터 프로토콜은 클라이언트가 정책(policy), AAA 및 리소스 제어를 수행하는데 이용할 정책 프로토콜을 정의한다. 이로써, 하나의 서버가 많은 서비스에 대한 정책을 처리할 수 있다. RADIUS와의 차이점 중 하나가 더 신뢰할 수 있는 전송 프로토콜(TCP 혹은 SCTP)을 이용한다는 점이다. 다이어미터 프로토콜은 상술한 3GPP IMS을 개발함으로써 더 강화된다.

다이어미터 애플리케이션은 소프트웨어 애플리케이션이 아니고, 다이어미터 기반 프로토콜에 기초한 프로토콜이다. 각각의 애플리케이션은 애플리케이션 식별자에 의해 정의되며, 새로운 커맨드 코드 및/또는 새로운 의무 속성값의 쌍(AVP:Attribute-Value Pairs)을 추가할 수 있다. 새로운 선택적인 AVP를 추가한다고 해서 새로운 애플리케이션이 필요한 것은 아니다.

선택적으로는, 클라이언트-서버 네트워크는 클라이언트와 서버 사이에 배치된 하나 이상의 프록시 노드를 더 포함한다. 프록시 노드는 전형적으로 라우팅 타입의 기능, 그리고 가능하다면 버퍼링도 수행하도록 배치된다. 다이어미터 프록시는 다이어미터 기반 프로토콜 rfc3588에 정의되어 있다. 도 3에는 프록시 노드를 포함한 셋업이 도시되어 있다. 클라이언트와 '서버 x' 사이의 링크는 다이어미터 프록시 노드를 통해서 설정된다. 통신은 표시된 순서로 이루어지며, 즉 클라이언트는 프록시에 접촉하고, 프록시는 요청시에 서버와 통신하며, 다시 클라이언트로 돌아온다.

제안된 해법에 따라서, 서버 노드는 데이터 전송을 위한 요청을 클라이언트 노드로부터 수신받으면, 예컨대 마지막 x초 동안, 자신의 실용량에 대한 표시를 리턴한다. 이 표시는 예컨대 이용가능한 최대 용량의 비율, 혹은 반대로 이미 사용중인 비율을 포함할 수 있다.

네트워크 내의 서버 노드의 실용량에 관한 정보는 본 발명에 따른 인터페이스 장치에 의해 수신되고, 데이터 트래픽이 송신되었을 때 목적지 노드에 대한 부하 분산을 결정하는데 이용된다. 더 높은 확률로 다음 데이터를 전송하기 위해서 순간적인 자유 용량이 더 높은 서버가 선택된다. 선택 알고리즘은 또한 이용 가능성이 더 낮다는 표시를 리턴한 서버는 선택될 확률이 확실히 더 낮게 한다. 실제 부하 분산에 대한 결과 정보가, 실제 전송이 개시되기 전에 클라이언트 소스에 제공된다.

본 발명에 따른 인터페이스 장치는 바람직하게는 소스 클라이언트 노드에 포함된다. 다른 방안으로, 독립형 장치가 될 수도 있다. 이러한 독립형 장치는 (프로토콜 측면에서) 다이어미터 프록시 노드로서 동작하는 것이 전형적이다.

제안된 방법은 다양한 이점을 제공한다. 이 방법은 리셉터(즉, 서버)의 볼륨 용량에 따라서, 다수의 목적지 노드에 대한 트래픽의 최적의 불균일한 확산을 가능하게 한다. 이와 같이 통신의 안정성과 효율성이 상당히 증가된다. 또한, 용량 및 처리 특성이 다른 구성 요소들을 이용해서 데이터 수집 용량 구성이 만들어질 수 있다. 이로써, 상이한 세대의 구성 요소 혹은 상이한 제조 업체의 구성 요소까지도 구성이 확대될 수 있다. 이와 달리, 종래의 해법에서는, 현존하는 구성 요소는 수집 용량이 추가될 때마다 업그레이드되어야 한다.

본원 발명의 중요한 특성은, 부하 분산이 새로운 상황에 유동적으로 적용될 수 있다는 점이다. 예컨대, 일괄 처리가 그 노드에서 실행되어서 서버 노드의 남은 수집 용량이 일시적으로 저하되었을 때에는, 트래픽 분산은 새로운 최적값으로 유동적으로 업데이트된다.

여기서는, 일례를 제공한다(도 4 참조). 4개의 서버 목적지 노드가 서로 다른 용량을 갖고 있는 경우를 다시 상정한다. 각각의 노드마다 사용되는 용량의 일부가 표시되어 있다. 클라이언트 소스 노드는 데이터 트래픽 전송 요청을 목적지 노드에 송신한 것이다. 단계 [1]는, 이 요청에 응답해서 서버가 용량과 관련된 자신의 실제 상태의 표시를 전송하는 것을 나타낸다. 이 예에서, 서버 노드는 CDF(Charging Data Function:이는 3GPP에 의해서 TS 32.240에 정의된 IMS 함수이다)로서 표시된다. 서버 노드의 응답 메시지는 2 부분, 즉, 응답 코드(요청이 처리되었는지 여부를 나타냄), 및 아직 이용가능한 (CPU 및/또는 메모리 크기에 관한) 용량 측정값의 추가 표시를 포함한다. 당업자라면, 응답 메시지의 다른 구조도 상정될 수 있다는 것을 이해할 것이다. 바람직하게는 다양한 노드의 이용 가능성에 대한 표시가 CTF(Charging Trigger Function)에 저장되며, 이는 3GPP에 의해서 TS 32.240에 정의된 IMS 함수이다

CTF가 Rf 다이어미터 클라이언트를 구현한다는 점에 주의한다. 이 예에서, 수신된 부하 표시의 설명은 실제로 CTF의 일부이다. 그러나, 이는 독립형 기능이 될 수도 있고, 다이어미터 프록시 혹은 심지어 다이어미터 리다이렉트에서 구현되는 기능이 될 수도 있다.

다이어미터 프로토콜은 실제로 다이어미터 리다이렉트 노드도 정의한다. 이 노드는 클라이언트와 서버 사이의 실제 통신 이전에 라우팅하기 위해서 참고된다. 시그널링 경로 내에 리다이렉트 노드가 있는 경우에는, 실제 로드 분산은 클라이언트에 의해서 계속 수행된다. 이 경우 라우팅 작업은 리다이렉트 노드와 클라이언트 노드에 공유된다.

다음 메시지의 서버 목적지 노드를 선택하기 위해서, 서버 노드가 선택되는 부하 밸런싱 알고리즘에서는 이용 가능성 정보가 가중치로서 고려된다. 개시시에(혹은 저 트래픽에서), CTF는 모든 서버가 높은 이용 가능성의 수치(예컨대, 95%)를 리턴하기 때문에 모든 서버에 대해서 균일하게 분산시킨다. 부하가 증가하면, 용량이 낮은 서버가 리턴한 이용 가능성의 수치는 감소된다. 이용 가능한 용량이 더 남아있는 (따라서 이용 가능성 수치가 더 높은) 서버 노드는 자유 용량이 없는 혹은 거의 남아 있지 않은 서버보다 목적지로서 선택될 가능성이 더 높다. 상대적으로 많은 수의 요청이 이 서버의 어드레스를 가질 것이다. 따라서 부하가 큰 목적지 서버는 거의 선택되지 않는다. 결과적으로, 이러한 부하가 큰 서버의 어드레스를 획득하게 되는 요청의 수는 적다. 이런식으로, 최적의 부하 셰어링이 달성된다. 서버 중 하나에서 수집 조건이 변경되면(예컨대, CPU 소모 일괄 작업이 수행되는), 분산 패턴은 실제 상황에 유동적으로 맞춰진다.

어느 부하 밸런싱 알고리즘의 목적은 서버마다의 가중 표시를 유동적으로(실시간으로) 생성하고, 이들 표시를 이용해서 가중된 서버 선택을 적용하는 것이다(예컨대, DNS용으로 이용됨). 하나의 가능한 알고리즘이 다음과 같이 구현될 수 있다. 부하 분산 기능은

○ 각각의 서버에 대한 부하 표시를 수신해서 저장하고,

○ 유동적인 리스트 혹은 어레이를 서머마다 그 서버의 수신값에 대응하는 엔트리의 수와 함께 작성한다. 부하 표시자가 이용가능한 리소스에 대응하면 그 값 자체가 이용될 수 있다. 부하 표시자가 사용되는 리소스에 대응하면 (100-사용되는 부하 %) 정보가 적용된다.

○ 어레이의 모든 요소에, 대응 서버의 (혹은 대응 서버에 대한 포인터의) 어드레스가 저장된다.

새롭게 전송된 요청마다 송신부는 0과 (부하 표시. 서버-1+부하 표시 서버 2 등) 사이의 임의의 수를 작성한다.

이 임의의 수는 유동적인 어레이에 액세스하기 위한 인덱스로서 이용된다. 어레이의 요소에는 이 요청의 목적지가 저장된다.

수신한, 서버 x에 대한 부하 표시가 높다면, 서버 x의 어드레스는 비교적 높은 넘버의 어레이 엔트리가 갖게 될 것이다. 수신한, 서버 y에 대한 부하 표시가 낮다면, 서버 y의 어드레스는 결과적으로는 비교적 낮은 넘버의 어레이 엔트리가 갖게 될 것이다. 랜덤 넘버 서버 x를 포인팅할 확률이 높다.

예서직인 경우는 수집 용량이 서로 다른 노드들에 3GPP Rf 트래픽(다이어미터) 부하가 공유되는 것에 관한 것이다. 이용가능한 용량을 피드백함으로써 최적의 부하 셰어링이 가능해진다.

본 발명에서 제안하는 해법에 의해 얻는 성능의 이점을 설명하기 위해서, 이하에서는 종래의 기술인 라운드 로빈 알고리즘의 성능과 비교한다.

도 6은 이용 가능한 서버 용량의 80%인 컷오프 임계값이 이용되는 라운드 로빈 선택법을 적용했을 때의 성능 곡선을 나타낸다. 이 임계 레벨에 도달한 시점부터는 '양호하지 않음(not-OK)' 메시지가 송신된다. 레벨이 60%까지 떨어지면 트래픽이 재개된다. 이 값은 전형적으로 과부하 상태에서 안정성을 '조정(tune)'하도록 각 구성마다 설정된다. 서버 상태가 온 상태와 오프 상태를 오실레이팅하는 상황을 방지하도록 이하의 일종의 히스테리시스 곡선을 정의하고 있다. 이 도면에서는, 용량이 서로 다른 4개의 서버로 이루어진 구성의 경우의 초당 요청 수를, 시간의 함수로서 나타내고 있으며, 누적 스루풋을 나타내고 있다. 과부하 트래픽이 관찰된다(특히 저용량 노드에서). 누적 스루풋(총 대역폭)의 변동이 심하다는 것을 알 수 있다. 최대 레벨(개개의 서버 노드 용량의 합의 80%가 된 경우)까지는 도달할 수 없다.

도 7은 본 발명에 따른 용량 피드백 해법을 이용할 때 얻게 되는 성능을 나타내고 있다. 도 6에 도시한 것과 동일한 서버 노드의 구성의 경우에, 초당 요청의 횟수를 시간의 함수로서 나타내고 있으며, 누적 스루풋과 최적 스루풋을 나타내고 있다. 도 6과는 달리, 어디에서도 과부하 트래픽은 관찰되지 않는다. 오실레이팅 특성도 없다. 천이 시간 이후에, 누적 용량은 최적 레벨에 대응한다.

당업자라면, 본 발명이 특정 실시예를 이용해서 설명되었지만, 본 발명이 상기 예시한 실시예의 세부 사항으로 한정되지 않으며, 본 발명은 그 범주를 벗어남없이 다양하게 변경되고 수정되어서 실시될 수 있다는 것을 이해할 것이다. 따라서, 본 실시예들은 예시적인 것을 뿐 한정의 의미는 아니며, 본 발명의 범주는 상기 설명이 아닌 첨부된 청구의 범위에 의해서 개시되어 있으므로, 청구의 범위의 균등물의 사상 및 범주 내에 포함되는 모든 변경이 모두 포함되는 것으로 의도되었다. 환언하면, 기본 원리의 사상 및 범주에 들어가고 본 특허 출원에서 필수적인 특성이 청구되고 있는 임의의 그리고 모든 수정, 변경 혹은 균등물을 커버하는 것으로 봐야 한다. 또한, 본 특허 출원을 읽을 때, 용어 '포함한다'는 다른 구성 요소 혹은 단계가 없다는 의미는 아니며, 컴퓨터 시스템, 프로세서 혹은 다른 집적 유닛과 같은 하나의 구성 요소가 청구항에 개시된 다수의 수단의 기능을 수행할 수도 있다는 것을 이해할 것이다. 청구항에 참조 번호가 기재되어 있다고 해서, 관련된 각각의 청구항을 한정한다는 것은 아니다. 상세한 설명 혹은 청구항에 용어 '제 1', '제 2', '제 3', 'a', 'b', 'c' 등이 개시되어 있다면, 이는 유사한 구성 요소 혹은 단계를 구별하기 위한 것일 뿐, 반드시 순차적으로 즉 개시된 순서여야 된다는 것은 아니다. 유사하게 '상부', '바닥부', '위에', '아래에' 등의 용어는 설명을 위한 것일 뿐 반드시 관련 위치를 나타내고 있는 것은 아니다. 이렇게 사용되는 용어는 상황에 따라 달라질 수도 있으며, 본 발명의 실시예는 상기 개시된 혹은 설명된 것과는 다른 순서로, 혹은 다른 방향에서 본 발명에 따라 동작할 수 있다는 것을 이해할 것이다.

Claims

IMS(IP Multimedia Subsystem)의 네트워크에서 데이터 트래픽 부하 분산을 결정하는 방법에 있어서 - 상기 네트워크는 클라이언트 소스 노드 및 적어도 2개의 서버 목적지 노드를 포함하며, 상기 적어도 2개의 서버 목적지 노드는 데이터 전송 요청을 처리하는 용량이 서로 다름 - ,
상기 방법은
상기 클라이언트 소스 노드가, 클라이언트-서버 프로토콜에 따라서 상기 네트워크를 통해서 상기 적어도 2개의 서버 목적지 노드로 데이터 전송 요청을 송신하는 단계와,
상기 요청에 응답해서, 상기 적어도 2개의 서버 목적지 노드 각각이, 자신의 실용량(actual capacity)의 상태에 대한 표시를 전송하는 단계와,
상기 클라이언트 소스 노드가 상기 상태 표시를 이용해서 상기 서버 목적지 노드에 대해 상기 데이터 트래픽의 부하 분산을 결정하는 단계를 포함하며,
상기 네트워크를 통해서 상기 적어도 2개의 서버 목적지 노드로 상기 데이터 전송 요청을 전송하기 위하여 다이어미터 프로토콜 또는 RADIUS(Remote Authentication Dial In User Service) 프로토콜이 사용되는
방법.
제 1 항에 있어서,
상기 실용량의 상태에 대한 상기 표시는 사용되는 용량의 양 혹은 자유 용량의 양을 나타내는
방법.
제 1 항 또는 제 2 항에 있어서,
상기 실용량의 상태는 적어도 메모리 및/또는 처리 시간을 고려해서 결정되는
방법.
제 1 항 또는 제 2 항에 있어서,
상기 네트워크는 상기 클라이언트 소스 노드와 상기 서버 목적지 노드 사이의 접속을 설정하는 프록시 노드를 더 포함하는
방법.
IMS의 네트워크로서
클라이언트 소스 노드와,
상기 클라이언트 소스 노드 내에 포함되거나 독립형 장치의 형식을 갖는 인터페이스 장치와,
적어도 2개의 서버 목적지 노드를 포함하고,
상기 적어도 2개의 서버 목적지 노드는 데이터 전송 요청을 처리하는 용량이 서로 다르며,
상기 클라이언트 소스 노드는 클라이언트 서버 프로토콜에 따라서 상기 네트워크를 통해서 상기 적어도 2개의 서버 목적지 노드로 데이터 전송 요청을 전송하도록 조정되며,
상기 인터페이스 장치는
상기 클라이언트 소스 노드에 의하여 전송된 상기 요청에 응답하여, 상기 적어도 2개의 서버 목적지로부터로부터 자신의 실용량의 상태 표시를 수신하는 수신 수단과,
상기 수신한 상태 표시에 기초해서 상기 목적지 노드에 대한 부하 분산을 결정하는 처리 수단과,
상기 결정된 부하 분산을 상기 클라이언트 소스 노드로 통신하는 통신 수단을 포함하며,
상기 인터페이스 장치는 다이어미터 프로토콜 또는 RADIUS 프로토콜에 따라 상기 네트워크를 통해서 상기 적어도 2개의 서버 목적지 노드로 상기 데이터 전송 요청을 전송하기 위하여 배치되는
네트워크.
제 5 항에 있어서,
상기 처리 수단은 부하 밸런싱 알고리즘을 수행하도록 배치되고, 상기 상태 표시는 가중 인자로서 이용되는
네트워크.
제 5 항 또는 제 6 항에 있어서,
상기 수신한 상태 표시를 저장하기 위한 저장 수단을 더 포함하는
네트워크.
제 5 항 또는 제 6 항에 있어서,
상기 클라이언트 소스 노드는 상기 인터페이스 장치를 포함하는
네트워크.
제 5 항 또는 제 6 항에 개시된 IMS의 네트워크에서 사용되는
클라이언트 소스 노드.