KR20170121311A - 분산 로드 밸런서 - Google Patents

분산 로드 밸런서 Download PDF

Info

Publication number
KR20170121311A
KR20170121311A KR1020177030237A KR20177030237A KR20170121311A KR 20170121311 A KR20170121311 A KR 20170121311A KR 1020177030237 A KR1020177030237 A KR 1020177030237A KR 20177030237 A KR20177030237 A KR 20177030237A KR 20170121311 A KR20170121311 A KR 20170121311A
Authority
KR
South Korea
Prior art keywords
node
server
load balancer
packet
flow
Prior art date
Application number
KR1020177030237A
Other languages
English (en)
Other versions
KR101863024B1 (ko
Inventor
제임스 크리스토퍼 3세 소렌슨
더글라스 스튜어트 로렌스
벤카트라가반 스리니바산
아크샤이 수하스 바이디아
판 장
Original Assignee
아마존 테크놀로지스, 인크.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 아마존 테크놀로지스, 인크. filed Critical 아마존 테크놀로지스, 인크.
Publication of KR20170121311A publication Critical patent/KR20170121311A/ko
Application granted granted Critical
Publication of KR101863024B1 publication Critical patent/KR101863024B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1002—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1023—Server selection for load balancing based on a hash applied to IP addresses or costs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1038—Load balancing arrangements to avoid a single path through a load balancer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/288—Distributed intermediate devices, i.e. intermediate devices for interaction with other intermediate devices on the same level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/72—Routing based on the source address
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Abstract

흐름당 해싱된 다중경로 라우팅 기법에 따라 라우터가 적어도 하나의 클라이언트로부터의 패킷을 수신하고 패킷 흐름을 복수의 로드 밸런서(LB) 노드로 라우팅하는 분산 로드 밸런서. 특정 패킷 흐름에 대해, LB 노드는 복수의 서버 노드 중에서 패킷 흐름에 대한 타깃으로서 한 서버 노드를 랜덤하게 선택하고, 연결 요청을 상기 서버 노드로 전송한다. 서버 노드 상의 로드 밸런서 모듈은 각각의 서버의 현재 로드를 가리키는 하나 이상의 메트릭을 기초로 연결을 수락할지 또는 거절할지를 결정한다. 모듈이 연결 요청을 수락하는 경우, 서버와 클라이언트 사이에 연결이 확립된다. 그렇지 않은 경우, 로드 밸런서 노드는 다른 한 서버 노드를 선택할 수 있고 이를 다시 시도할 수 있다. 클라이언트와 서버 간에 확립된 연결이 로드 밸런서 노드를 통과하지만 로드 밸런서 노드에서 종료되지는 않는다.

Description

분산 로드 밸런서{DISTRIBUTED LOAD BALANCER}
일반적으로 종래의 로드 밸런서(load balancer)는 복수의 네트워크 인터페이스 제어기(NIC), 가령, 8개의 NIC를 포함하는 단일, 전용 박스이며, 이때, NIC 중 일부가 클라이언트로부터의 인바운드 트래픽/클라이언트로의 아웃바운드 트래픽을 핸들링하고 또 다른 NIC가 로드 밸런싱되는 호스트 장치(가령, 서버, 가령, 웹 서버)로부터의 아웃바운드 트래픽/호스트 장치로의 인바운드 트래픽을 핸들링한다. 일반적으로 이들 종래의 로드 밸런서 상의 대역폭 또는 처리율이 클라이언트 측 상 40 기가비트/초(Gbps) 및 서버 측 상 40Gbps의 범위이다. 네트워크 기반 애플리케이션 및 네트워크 기반 서비스, 가령, 클라우드 컴퓨팅 서비스의 스케일 및 범위가 증가함에 따라, 데이터 센터가 로드 밸런싱될 필요가 있는 수백 개 또는 심지어 수천 개의 호스트 장치(가령, 웹 서버)를 하우징할 수 있다. 종래의 로드 밸런서는 이러한 환경에서 적절하게 스케일될 수 없다.
추가로, 일반적으로 종래의 로드 밸런서는 어느 호스트 장치가 연결을 핸들링할 것인지를 선택하기 위해 호스트 장치로부터 수집된 데이터에 적용되는 기법, 가령, 최대 연결(max connection)(즉, max conns), 라운드 로빈, 및/또는 최소 연결(least conns)을 이용한다. 덧붙여, 일반적으로 종래의 로드 밸런서는 자신 앞의 호스트 장치로의 프록시로서 기능 하고 따라서 클라이언트로부터의 연결(가령, TCP(Transmission Control Protocol) 연결)을 종료하며 호스트 장치와 로드 밸런서 간에 확립되는 TCP 연결 상의 호스트 장치로 클라이언트 트래픽을 전송한다. 따라서, 호스트 장치와 클라이언트는 이들 종래의 로드 밸런서를 이용할 때 직접 TCP 연결을 통해 통신하지 않는다.
도 1은 적어도 일부 실시예에 따르는, 예시적 분산 로드 밸런싱 시스템의 블록도이다.
도 2는 적어도 일부 실시예에 따르는, 도 1의 분산 로드 밸런서 시스템에 의해 구현될 수 있는 로드 밸런싱 방법의 하이-레벨 흐름도이다.
도 3은 적어도 일부 실시예에 따르는, 입구, 출구, 및 흐름 추적기 구성요소를 포함하는 예시적 로드 밸런서 노드를 도시한다.
도 4는 적어도 일부 실시예에 따르는, 분산 로드 밸런서에서의 라우팅 및 패킷 흐름을 도시한다.
도 5는 적어도 일부 실시예에 따르는, 입구 노드를 에지 라우터로 광고하는 것을 도시한다.
도 6은 적어도 일부 실시예에 따르는 다중경로 라우팅 방법의 흐름도이다.
도 7은 적어도 일부 실시예에 따르는 비대칭 패킷 흐름을 그래픽으로 도시한다.
도 8은 적어도 일부 실시예에 따르는 분산 로드 밸런싱 시스템에서의 패킷 흐름을 도시한다.
도 9a 및 9b는 적어도 일부 실시예에 따르는 분산 로드 밸런싱 시스템에서의 연결을 확립할 때 패킷의 흐름도를 제공한다.
도 10a 내지 10g는 적어도 일부 실시예에 따르는 분산 로드 밸런싱 시스템에서의 패킷 흐름을 도시한다.
도 11a 내지 11d는 적어도 일부 실시예에 따르는 로드 밸런서 노드 일관 해시 링에서의 구성원에 영향을 미치는 이벤트의 핸들링을 도시한다.
도 12는 적어도 일부 실시예에 따르는 건강 체크 간격에 따라 각각의 로드 밸런서 노드에 의해 수행될 수 있는 건강 체크 방법의 하이-레벨 흐름도이다.
도 13은 적어도 일부 실시예에 따르는 또 다른 로드 밸런서 노드로부터 로드 밸런서 노드를 건강 체크하기 위한 방법을 도시한다.
도 14는 적어도 일부 실시예에 따르는 하나 이상의 또 다른 로드 밸런서 노드를 건강 체크하는 로드 밸런서 노드를 그래픽으로 도시한다.
도 15는 적어도 일부 실시예에 따라 서버 노드를 건강 체크하는 로드 밸런서 노드를 도시한다.
도 16은 적어도 일부 실시예에 따라 로드 밸런서 노드(110)에 의해 유지관리될 수 있는 또 다른 노드의 건강의 뷰를 그래픽으로 도시한다.
도 17은 적어도 일부 실시예에 따라 각각의 로드 밸런서 노드에 의해 유지관리될 수 있는 건강 정보를 도시한다.
도 18a 및 18b는 적어도 일부 실시예에 따라 로드 밸런서 노드 고장을 핸들링하는 것을 도시한다.
도 19a 및 19b는 적어도 일부 실시예에 따라 연결 게시 기법을 그래픽으로 도시한다.
도 20은 적어도 일부 실시예에 따라 각각의 로드 밸런서 모듈에 의해 수행될 수 있는 연결 게시 방법의 하이-레벨 흐름도이다.
도 21은 적어도 일부 실시예에 따라, 타깃 로드 밸런서 노드로의 연결 게시 패킷으로 수신된 활성 연결 정보를 분산시키기 위한 방법의 흐름도이다.
도 22는 적어도 일부 실시예에 따라, 타깃 로드 밸런서 노드로의 연결 게시 패킷에서 수신된 활성 연결 정보를 분산시키기 위한 대안적 방법을 도시한다.
도 23은 적어도 일부 실시예에 따라 로드 밸런서 노드에 대한 예시적 소프트웨어 스택 아키텍처를 도시한다.
도 24는 실시예에서 사용될 수 있는 코어 패킷 프로세싱 기법의 양태를 도시한다.
도 25는 적어도 일부 실시예에 따라, 로드 밸런서 노드 상에서 데이터 흐름을 프로세싱하기 위한 예시적 멀티코어 패킷 프로세서를 도시한다.
도 26은 적어도 일부 실시예에 따라, 로드 밸런서 노드 상에서 데이터 흐름을 프로세싱하기 위한 또 다른 예시적 멀티코어 패킷 프로세서를 도시한다.
도 27은 적어도 일부 실시예에 따라, 로드 밸런서 노드 프로세스에 의한 인커밍 패킷의 프로세싱을 도시한다.
도 28은 적어도 일부 실시예에 따라, 로드 밸런서 노드 프로세스에 의한 아웃고잉 패킷의 프로세싱을 도시한다.
도 29는 적어도 일부 실시예에 따라, 생성 환경에서 분산 로드 밸런서를 포함하는 로드 밸런싱 시스템을 도시한다.
도 30은 적어도 일부 실시예에 따라, 복수의 분산 로드 밸런싱 시스템 구성요소가 단일 프로세스로 구성 및 실행되게 하는 메시지 버스 메커니즘을 포함하는 분산 로드 밸런서 시험 시스템을 도시한다.
도 31 및 32는 적어도 일부 실시예에 따르는 메시지 버스 패킷 어댑터 및 패킷 파이프라인을 도시한다.
도 33a는 적어도 일부 실시예에 따르는 예시적 제공자 네트워크 환경을 도시한다.
도 33b는 적어도 일부 실시예에 따르는 도 33a에서 도시된 바와 같은 예시적 제공자 네트워크 환경에서의 분산 로드 밸런서 구현을 도시한다.
도 34a는 적어도 일부 실시예에 따르는 분산 로드 밸런서 및 서버 노드의 예시적 물리 랙 구현을 도시한다.
도 34b는 적어도 일부 실시예에 따르는 분산 로드 밸런서 및 서버 노드의 또 다른 예시적 물리 랙 구현을 도시한다.
도 35는 적어도 일부 실시예에 따르는 네트워크에서 하나, 둘 또는 그 이상의 분산 로드 밸런서가 구현되는 예시적 네트워킹 환경을 도시한다.
도 36은 일부 실시예에서 사용될 수 있는 예시적 컴퓨터 시스템을 도시하는 블록도이다.
본 명세서에서 실시예가 몇 가지 실시예 및 예시적 도면을 예를 들어 기재되지만, 해당 분야의 통상의 기술자라면, 실시예는 기재된 실시예 또는 도면에 한정되지 않음을 알 것이다. 도면 및 상세한 설명이 실시예를 개시된 특정 형태로 한정하려는 의도가 아니며, 오히려, 특허청구범위에 의해 규정되는 사상 및 범위 내에 속하는 모든 변형, 균등, 및 대안예를 포함하는 의도임을 이해해야 한다. 본 명세서에서 사용되는 제목들은 구성 목적만 가지며 기재 또는 청구항의 범위를 제한하기 위해 사용되지 않았다. 본 명세서 전체에서 사용될 때, 단어 "~일 수 있다(may)"는 단정적 의미(즉, 의무(must)를 의미)보다는, 관용적인 의미(즉, 가능성을 가짐을 의미)로 사용된다. 마찬가지로, 단어 "포함하다", "포함하는", 및 "포함하다"는 비제한적으로 포함함을 의미한다.
네트워크 환경에서의 분산 로드 밸런싱(distributed load balancing)을 위한 방법 및 시스템의 다양한 실시예가 기재된다. 다양한 네트워크 환경에서의 분산 로드 밸런서의 실시예에 따라 구현될 수 있는 분산 로드 밸런싱 방법 및 시스템의 실시예가 기재된다. 분산 로드 밸런서의 실시예가, 예를 들어, 도 33a 및 33b에 도시된 바와 같이, 외부 네트워크 가령, 인터넷 상의 클라이언트와 도착지, 일반적으로 로컬 네트워크, 가령, 제공자 네트워크(1900) 상의 서버(가령, 웹 서버, 애플리케이션 서버, 데이터 서버 등) 간 패킷 흐름, 가령, TCP(Transmission Control Protocol) 기법 패킷 흐름을 촉진 및 유지관리하기 위해 사용될 수 있다. 본 명세서에 실시예가 주로 TCP 패킷 흐름을 프로세싱하는 것과 관련하여 기재되지만, 실시예는 TCP 외의 다른 데이터 통신 프로토콜 및 패킷 흐름 프로세싱이 아닌 다른 적용예에도 적용될 수 있다.
분산 로드 밸런서가 특정 클라이언트와 선택된 서버(가령, 웹 서버) 간의 TCP 패킷 흐름을 촉진 및 유지관리하도록 기능할 수 있다. 그러나, 분산 로드 밸런서는, 종래의 로드 밸런서에서 그런 것처럼, 클라이언트로부터의 TCP 흐름을 종료하거나 서버로의 프록시로서 역할 하지 않는다. 대신, 분산 로드 밸런서의 로드 밸런서 노드는 클라이언트에서 타깃 서버(타깃 server)로 수신된 TCP 패킷을 라우팅하고, 서버가 자신의 TCP 스택을 이용해 클라이언트로의 TCP 연결을 관리한다. 다시 말하면, 서버가 클라이언트로부터의 TCP 패킷 흐름을 종료한다.
또한, 종래의 로드 밸런서 기법에서 그런 것처럼, 로드 밸런서 노드(들)가 서버로부터 수집된 정보에 적용되는 로드 밸런싱 기법 또는 알고리즘을 기초로 어느 서버가 연결 요청을 서비스할 것인지에 대해 결정하는 대신, 로드 밸런서 노드는 새 연결 요청을 수신하기 위한 서버를 랜덤하게 선택할 수 있고, 서버 상에 위치하는 분산 로드 밸런서의 구성요소가 각각의 서버의 현재 상태의 하나 이상의 메트릭을 기초로 상기 선택된 서버가 새 연결 요청을 수락할지 또는 거절할지에 대해 로컬하게 결정한다. 따라서 어느 서버가 연결 요청을 수락할지에 대한 결정이 로드 밸런서 노드(들)에서 상기 연결을 핸들링할 서버 노드로 이동된다. 다시 말하면, 결정이 연결 요청이 서비스될 곳 및 시점에 가깝게 이동된다.
클라이언트와 서버 간 패킷 흐름을 촉진 및 유지관리하기 위해, 분산 로드 밸런서의 실시예가 다양한 기법 또는 기술을 채용할 수 있으며, 비제한적 예를 들면, 다중경로 라우팅(multipath routing) 기법, 일관 해싱(consistent hashing) 기법, 분산 해시 테이블(distributed hash table)(DHT) 기법, 경계 게이트웨이 프로토콜(Border Gateway Protocol)(BGP) 기법, 구성원 추적, 건강 체킹, 연결 게시(connection publishing), 및 패킷 캡슐화 및 역캡슐화가 있다. 이들뿐 아니라 그 밖의 다른 양태의 분산 로드 밸런싱 시스템이 도면과 관련하여 이하에서 기재된다.
분산 로드 밸런싱 시스템
도 1은 적어도 일부 실시예에 따른 예시적 분산 로드 밸런싱 시스템의 블록도이다. 도 33a 및 33b에 도시된 바와 같이, 상기 분산 로드 밸런서의 실시예는 네트워크(100), 가령, 서비스 제공자의 제공자 네트워크(1900)에서 구현될 수 있다. 분산 로드 밸런서 시스템에서의 클라이언트 패킷 핸들링의 하이-레벨 개요로서, 네트워크(100)의 하나 이상의 클라이언트(160)가, 예를 들어, 외부 네트워크(150), 가령, 인터넷을 통해, 네트워크(100)의 경계 라우터(border router)(102)로 연결될 수 있다. 경계 라우터(102)는 클라이언트(160)로부터의 인커밍 패킷(가령, TCP 패킷)을 분산 로드 밸런서의 에지 라우터(edge router)(104) 구성요소로 라우팅하고, 여기서 상기 인커밍 패킷을 분산 로드 밸런서 시스템의 로드 밸런서 노드 레이어에서 로드 밸런서(LB) 노드(110)으로 라우팅한다. 적어도 일부 실시예에서, 에지 라우터(104)는 흐름당 해싱 다중경로 라우팅 기법(per-flow hashed multipath routing technique), 가령, 등가 다중경로(equal-cost multipath)(ECMP) 해싱 기법에 따라 결정할 수 있다. 그 후 상기 로드 밸런서 노드(110)는 (가령, 사용자 데이터그램 프로토콜(UDP)에 따라) 패킷을 캡슐화하고, 네트워크(100) 상의 네트워크 패브릭(network fabric)(120)(가령, L3 네트워크)을 통해 캡슐화된 패킷을 서버 노드(130) 상의 로컬 로드 밸런서 모듈(132)로 라우팅한다. 상기 패브릭(120)은 하나 이상의 네트워킹 장치 또는 구성요소, 비제한적 예를 들면, 스위치, 라우터 및 케이블을 포함할 수 있다. 서버 노드(130) 상에서, 로컬 로드 밸런서 모듈(132)은 패킷을 역캡슐화(decapsulate)하고 클라이언트 TCP 패킷을 서버(134)의 TCP 스택으로 전송한다. 그 후 서버 노드(130) 상의 서버(134)는 자신들의 TCP 스택을 이용해 클라이언트(160)로의 연결을 관리할 수 있다.
도 2는 적어도 일부 실시예에 따라 도 1의 분산 로드 밸런서 시스템에 의해 구현될 수 있는 로드 밸런싱 방법의 하이-레벨 흐름도이다. 분산 로드 밸런서 시스템의 실시예는, 종래의 로드 밸런서에서 그런 것처럼 복수의 도착지(가령, 웹 서버) 간에 로드(load)를 할당하는 하드 문제(hard problem)를 해결하지 못할 수 있다. 예를 들어, 일반적으로 종래의 로드 밸런서는 기법 또는 알고리즘, 가령, 최대 연결, 라운드 로빈, 및/또는 최소 연결 기법을 이용해 어느 서버가 연결을 핸들링해야 하는지를 선택할 수 있다. 그러나 이들 기법은 단점을 가지는데, 구체적으로 종종 로드 밸런싱 결정을 하기 위해 사용되는 데이터가 종종 거의 바로 낡은 것(stale)이 되는 분산 시스템에서 성공적으로 수행되기 어렵다. 분산 로드 밸런서 시스템의 적어도 일부 실시예에서, 종래의 로드 밸런서에서처럼 로드 밸런싱 기법 중 하나 이상을 이용해 연결 요청을 만족하기 위한 서버 노드(130)를 선택하려 시도하는 대신, 로드 밸런서 노드 레이어에서 로드 밸런서 노드(110)가 클라이언트 연결에 대한 요청을 수신할 서버 노드(130)를 랜덤하게 결정할 수 있다. 상기 서버 노드(130)가 스스로 오버로드 상태라고 간주할 경우, 서버 노드(130)는 연결 요청을 로드 밸런서 노드(110)로 되돌려 보내, 로드 밸런서 노드(110)에게 서버 노드(130)가 현재 연결을 핸들링할 수 없다고 알릴 수 있다. 그 후 상기 로드 밸런서 노드 레이어는 연결 요청을 수신할 또 다른 서버 노드(130)를 랜덤하게 결정하거나, 대안적으로, 에러 메시지를 요청 클라이언트(160)에게 반환하여 상기 클라이언트(160)에게 연결이 현재 확립되지 않을 수 있음을 알릴 수 있다.
도 2의 (10)으로 지시되는 바와 같이, 분산 로드 밸런서 시스템의 로드 밸런서 노드 레이어가 출발지(source)로부터 통신 세션(가령, TCP 연결)에 대한 요청을 수신하다. 예를 들어, 출발지는 분산 로드 밸런서 시스템을 구현하는 네트워크(100)의 외부 네트워크(150) 상의 클라이언트(160)일 수 있다. 적어도 일부 실시예에서, 요청이 네트워크(100)의 경계 라우터(102)의 클라이언트(160)로부터 수신되고, 에지 라우터(104)로 라우팅되며, 상기 에지 라우터는 예를 들어, 흐름당 등가 다중경로(ECMP) 해싱 기법을 이용해 클라이언트(160)로부터의 특정 연결 요청이 라우팅될 로드 밸런서 노드(110)를 의사랜덤하게 선택하여, 인커밍 패킷을 로드 밸런서 노드 레이어에서 로드 밸런서(LB) 노드(110)로 라우팅할 수 있다.
(20)으로 지시되는 바와 같이, 로드 밸런서 노드 레이어는 도착지 노드를 랜덤하게 선택하고 연결 요청을 선택된 도착지 노드로 전달한다. 예를 들어, 상기 도착지 노드는, 로드 밸런서가 앞둔 복수의 서버 노드(130) 중 하나의 서버 노드일 수 있다. 적어도 일부 실시예에서, 로드 밸런서 레이어에서 로드 밸런서 노드(110)는 모든 알려진 서버 노드(130)로부터의 연결 요청을 수신하기 위한 서버 노드(130)를 랜덤하게 선택할 수 있다. 그러나 일부 실시예에서 연결 요청을 수신하기 위한 서버 노드(130)를 선택하기 위해, 모든 알려진 서버 노드(130)로부터 순수하게 랜덤하게 선택하는 것이 아닌 다른 방법이 사용될 수 있다. 예를 들어, 일부 실시예에서, 서버 노드(130)에 대한 정보가 로드 밸런서 노드(110)에 의해 사용되어 서버 노드(130)의 랜덤 선택에 가중치를 부여할 수 있다. 예를 들어, 로드 밸런서 노드(110)가 서로 다른 서버 노드(130)가 서로 다른 유형의 장치인지 또는 서로 다른 CPU로 구성되고 따라서 서로 다른 능력 또는 용량을 가짐을 아는 경우, 상기 정보는 랜덤 선택을 서버 노드(130)의 특정 유형(들) 또는 구성(들) 쪽으로(또는 반대로) 편향시키도록 사용될 수 있다.
(30)으로 지시되는 바와 같이, 도착지 노드는 통신 세션을 수락할 수 있는지 여부를 결정한다. 적어도 일부 실시예에서, 서버 노드(130) 상의 로컬 로드 밸런서(LB) 모듈(132)이 서버 노드(130) 상의 각각의 서버(134)가 각각의 서버(134)의 현재 상태의 하나 이상의 메트릭을 기초로 새 연결을 수락할 수 있는지 여부를 결정한다.
(40)에서, 연결 요청이 수락된 경우, 50으로 지시되는 바와 같이, 도착지 노드는 도착지 노드가 연결을 핸들링할 수 있다고 로드 밸런서 노드 레이어에게 알린다. 그 후 (60)에서 지시되는 바와 같이, 로드 밸런서 노드 레이어를 통해 출발지(가령, 클라이언트(160))와 도착지 노드(가령, 서버 노드(130) 상의 서버(134)) 사이에 통신 세션이 확립된다. 적어도 일부 실시예에서, 서버 노드(130) 상의 서버(134)가 TCP 스택을 이용해 클라이언트(160)로의 연결을 관리할 수 있다.
(40)에서, 연결 요청이 수락되지 않은 경우, (70)으로 지시되는 바와 같이 도착지 노드는 로드 밸런서 노드 레이어에게 통지하고 방법은 요소(20)로 복귀할 수 있다. 그 후 (20)에서 로드 밸런서 노드 레이어는 또 다른 도착지 노드를 랜덤하게 선택하거나, 요청 클라이언트(160)에게 연결이 현재 확립되지 않을 수 있다고 알릴 수 있다. 클라이언트(160)는, 필수는 아니지만, 연결 요청을 재재출(resubmit)하여 요소(10)에서 방법을 다시 시작할 수 있다.
도 1을 다시 참조하여, 분산 로드 밸런서 시스템의 적어도 일부 실시예는 상용화된 하드웨어를 이용하여 네트워크(100) 상의 에지 라우터(104)에서 수신된 클라이언트 트래픽을 네트워크(100) 상의 서버 노드(130)로 라우팅할 수 있다. 분산 로드 밸런서의 적어도 일부 실시예는 복수의 로드 밸런서 노드(110)를 포함하는 로드 밸런서 노드 레이어를 포함할 수 있다. 적어도 일부 실시예에서, 각각의 로드 밸런서 노드(110)는 로드 밸런서 노드 레이어에서 복수의 역할 중 하나 이상을 수행할 수 있다. 로드 밸런서 노드(110)의 이러한 역할은 입구 노드(ingress node), 출구 노드(egress node), 및 흐름 추적기 노드(flow tracker node)(특정 패킷 흐름에 대한 주 흐름 추적기 또는 보조 흐름 추적기)의 역할을 포함할 수 있다. 적어도 일부 실시예에서, 각각의 로드 밸런서 노드(110)는 로드 밸런서 노드 레이어에서 구현되거나 별도 컴퓨팅 장치, 가령, 상용화된 컴퓨팅 장치 상에서 구현될 수 있다. 적어도 일부 실시예에서, 각각의 로드 밸런서 노드(110)는 입구 노드, 출구 노드, 및 흐름 추적기 노드(패킷 흐름에 대한 주 흐름 추적기 또는 보조 흐름 추적기)의 세 가지 역할 각각을 수행할 수 있으며, 이때 로드 밸런서 노드(110)는 특정 패킷 흐름에 대한 역할들 중 단 하나의 역할(그러나 둘 또는 세 가지 역할도 가능)을 수행한다. 그러나 적어도 일부 실시예에서, 로드 밸런서 노드(110)는 특정 패킷 흐름에 대한 주 흐름 추적기와 보조 흐름 추적기 모두로서 역할 할 수 없다. 대안적으로, 일부 실시예에서, 각각의 로드 밸런서 노드(110)는 세 가지 역할 중 단 하나의 역할만 수행할 수 있다. 이 실시예에서, 컴퓨팅 장치의 개별 세트가 로드 밸런서 노드 레이어에서, 특히, 입구 노드, 출구 노드, 및 흐름 추적기 노드로 구현될 수 있다.
적어도 일부 실시예에서, 일관 해싱(consistent hashing) 및 일관 해싱 링(consistent hash ring) 기법이 적용되어 패킷 흐름에 대한 주 흐름 추적기 및 보조 흐름 추적기를 결정할 수 있다. 클라이언트로부터의 각각의 패킷 흐름은 예를 들어, 클라이언트 IP 주소, 클라이언트 포트, 서버(공중) IP 주소, 및 서버 포트로 구성된 4-튜플에 의해 고유하게 식별될 수 있다. 이 식별자는 클라이언트와 공중 종단점 쌍을 지시하는 CP 또는 CcPp로 약칭될 수 있다. 임의의 특정 TCP 흐름(또는 CP 쌍)과 연관된 패킷은 에지 라우터(104)로부터의 해싱된 다중경로(가령, ECMP) 흐름 분포 때문에 입구 서버(112)로서 동작하는 임의의 로드 밸런서 노드(110) 상에서 나타날 수 있다. 패킷이 입구 노드로서 역할 하는 로드 밸런서 노드(110)에 도달할 때, 입구 노드가 어느 로드 밸런서 노드(110)가 패킷 흐름에 대한 상태를 유지관리할 책임이 있는지(즉, 주 흐름 추적기 노드인지)를 결정할 수 있도록, 일관 해싱이 사용된다. 입구 노드에 의해 CP 쌍이 일관 해시 링(consistent hash ring)으로 해싱되어 어느 로드 밸런서 노드(110)가 패킷 흐름에 대한 상태 정보를 유지관리할 책임이 있는지를 결정할 수 있다. 일관 해시 링에서 패킷 흐름에 대한 CP 쌍의 일관 해시에 따라 결정된 노드(110)가 패킷 흐름에 대한 주 흐름 추적기로서 역할 하는 노드(110)이다. 적어도 일부 실시예에서, 일관 해시 링 내 다음 노드(successor node)가 패킷 흐름에 대한 보조 흐름 추적기로서 역할한다.
도 3은 적어도 일부 실시예에 따라, 세 가지 모든 역할(입구, 출구, 및 흐름 추적기)을 이행하는 구성요소를 포함하는 예시적 로드 밸런서(LB) 노드(110)를 도시한다. 이 예시에서, 입구 서버(112) 구성요소는 클라이언트(들)로부터의 인바운드 TCP 패킷을 수신하고 캡슐화된 패킷으로서 상기 TCP 패킷을 서버(들)로 전송하는 입구 역할을 수행한다. 출구 서버(114) 구성요소는 서버(들)로부터 아웃바운드 캡슐화된 패킷을 수신하고 역캡슐화된 TCP 패킷을 클라이언트(들)에게 전송하는 출구 역할을 수행한다. 흐름 추적기(116) 구성요소는 클라이언트(들)(160)와 서버(들)(134) 간에 확립되는 하나 이상의 패킷 흐름에 대한 주 또는 보조 흐름 추적기로서 역할 한다. 입구 서버(112)는 또한 로드 밸런서 노드(110) 상의 흐름 추적기(116)와 통신하거나 또 다른 로드 밸런서 노드(110) 상의 흐름 추적기(116)와 통신하여, 각각의 클라이언트(160)로부터 수신된 연결 요청에 응답하여, 클라이언트와 서버(134)들 중 하나의 서버 간 TCP 연결을 개시하거나, 패킷 흐름에 대한 맵핑 정보를 획득할 수 있다. 입구 서버가
로드 밸런서 노드
도 1을 다시 참조하면, 적어도 일부 실시예에서, 로드 밸런서 노드 레이어의 로드 밸런서 노드(110)는 네트워크 상의 하나 이상의 라우터(104)로부터 클라이언트 트래픽(패킷, 가령, TCP 패킷)을 수신하고 패브릭(120) 상에서 분산 로드 밸런서 시스템에 의해 사용되는 프로토콜(가령, UDP(User Datagram Protocol))에 따라 패킷을 캡슐화한다. 그 후 로드 밸런서 노드 레이어는 캡슐화된 패킷을 패브릭(120)을 통해 도착지 서버 노드(130)로 전달한다. 각각의 서버 노드(130)는 로드 밸런서 시스템의 구성요소인 로컬 모듈(132)을 포함한다. 상기 모듈(132)은 본 명세서에서 로드 밸런서 모듈 또는 단순히 LB 모듈이라고 지칭될 수 있고, 소프트웨어, 하드웨어, 또는 이들의 조합으로 서버 노드(130) 상에서 구현될 수 있다. 각각의 서버 노드(130)에서, 각각의 로드 밸런서 모듈(132)이 패킷을 역캡슐화하고 정규 TCP 프로세싱을 위해 TCP 패킷을 로컬 TCP 스택으로 전송한다. 적어도 일부 실시예에서, 로드 밸런서 노드 레이어는 모든 클라이언트-서버 TCP 흐름에 대한 상태 정보를 유지관리할 수 있지만, 로드 밸런서 노드 레이어에서 로드 밸런서 노드(110)는 TCP 흐름에 대한 어떠한 것도 해석하지 않을 수 있다. 각각의 서버 노드(130) 상의 서버(134)와 클라이언트(160) 간 각각의 흐름이 관리된다. 분산 로드 밸런서 시스템은 TCP 패킷이 올바른 도착지 서버(134)에 도달함을 보장한다. 각각의 서버 노드(130)에서 상기 로드 밸런서 모듈(132)은, 각각의 서버(134)가 로드 밸런서 노드(110)로부터 수신된 클라이언트 연결 요청에 응답하여 새 연결을 수락할지 또는 거절할지에 대한 결정을 할 수 있다.
적어도 일부 실시예에서, 분산 로드 밸런싱 시스템은 일관 해싱 기법을 이용해, 예를 들어, 어느 로드 밸런서 노드(들)(110)가 어느 서버 노드(130)가 특정 TCP 패킷 흐름에 대해 책임이 있는지를 기억해야 하는지를 결정할 수 있다. 일관 해싱 기법을 이용해, 로드 밸런서 노드 레이어의 로드 밸런서 노드(110)가 일관 해시 링으로 보여질 수 있고, 로드 밸런서 노드(110)는 링의 구성원들을 계속 파악할 수 있고, 일관 해싱 함수에 따라 특정 패킷 흐름에 대해 책임이 있는 링의 특정 구성원을 결정할 수 있다. 적어도 일부 실시예에서, 클라이언트(160)와 서버(134) 간의 각각의 패킷 흐름을 추적하는 데 책임이 있는 2개의 로드 밸런서 노드(110)가 존재하며, 이들 노드(110)가 주 흐름 추적기(PFT) 노드와 보조 흐름 추적기(SFT) 노드라고 지칭될 수 있다. 적어도 일부 실시예에서, 주 흐름 추적기가 흐름에 대한 일관 해시 링 상의 첫 번째 로드 밸런서 노드(110)이며, 보조 흐름 추적기가 주 흐름 추적기 노드와 구별되는 일관 해시 링 상의 다음 로드 밸런서 노드(110)이다. 이 배열에서, 주 흐름 추적기 노드가 고장 난 경우, 보조 흐름 추적기 노드가 새로운 주 흐름 추적기가 될 수 있고, 또 다른 로드 밸런서 노드(110)(가령, 일관 해시 링 상의 다음 노드(110))가 보조 흐름 추적기의 역할을 가정할 수 있다. 적어도 일부 실시예에서, 로드 밸런서 노드(110)가 특정 패킷 흐름에 대해 주 흐름 추적기와 보조 흐름 추적기 모두로서 역할 하도록 허용되지 않는다. 일관 해시 링에서의 이러한 그리고 그 밖의 다른 구성원 변경이 본 명세서에서 차후에 설명된다. 적어도 일부 실시예에서, 로드 밸런서 구현을 위한 구성 정보(가령, 구현에서 현재 존재하는 로드 밸런서 노드(110) 및 서버 노드(130)의 권한 리스트(들))가, 예를 들어 패브릭(120)을 통해 로드 밸런서 노드(110)로 연결된 하나 이상의 서버 장치 상에서 구현될 수 있는 분산 로드 밸런싱 시스템의 구성 서비스(122) 구성요소에 의해 유지관리될 수 있다.
적어도 일부 실시예에서, 주 및 보조 흐름 추적기 노드로서 역할 하는 것에 추가로, 또한 로드 밸런서 노드(110)는 특정 흐름에 대한 나머지 두 역할, 즉, 입구 노드의 역할 및 출구 노드의 역할 중 하나를 수행할 수 있다. 패킷 흐름에 대한 입구 노드가 에지 라우터(104)로부터 각각의 패킷 흐름을 수신하고 패브릭(120)을 통해 서버 노드(130) 상의 선택된 서버(134)로 패킷 흐름(캡슐화된 패킷)을 전달하는 로드 밸런서 노드(110)이다. 입구 노드는 실제 클라이언트 데이터(TCP 데이터 패킷)를 각각의 도착지 서버 노드(130)로 이동시키는 로드 밸런서 노드(110)일 뿐이다. 상기 입구 노드는 도착지 서버 노드(130) 상에서 각각의 로드 밸런서 모듈(132)로의 TCP 흐름의 맵핑을 유지관리하여, 입구 노드가 클라이언트 트래픽을 전달할 로드 밸런서 모듈(132)을 알 수 있다. 출구 노드는 패브릭(120)을 통해 서버 노드(130)로부터 수신된 패킷 흐름에 대한 응답 트래픽을 경계 네트워크를 통해 각각의 클라이언트(160)에게 전달할 책임이 있는 로드 밸런서 노드(110)이다. 상기 로드 밸런서 모듈(132)은 로드 밸런서 프로토콜(가령, UDP)에 따라 서버(134)로부터 획득된 응답 패킷을 캡슐화하고 패브릭(120)을 통해 캡슐화된 응답 패킷을 흐름에 대한 각각의 출구 노드로 전송한다. 상기 출구 노드는 무상태형(stateless)이며 단순히 패킷을 역캡슐화되고 경계 네트워크 상으로 응답 패킷(가령, TCP 패킷)을 경계 라우터(102)로 전송하여, 외부 네트워크(150)를 통해 각각의 클라이언트(160)로 전달되게 할 수 있다.
앞서 언급된 바와 같이, 적어도 일부 실시예에서, 각각의 로드 밸런서 노드(110)는 서로 다른 패킷 흐름에 대해 입구 노드, 출구 노드, 및/또는 (주 흐름 추적기 또는 보조 흐름 추적기로서의) 흐름 추적기 노드의 역할을 수행할 수 있다. 로드 밸런서 노드 레이어에서 단일 로드 밸런서 노드(110)가 노드가 프로세싱하는 패킷 흐름에 따라 역할들 중 임의의 한 역할을 수행할 수 있다. 예를 들어, 적어도 일부 실시예에서, 로드 밸런서 노드(110)는 하나의 패킷 흐름에 대해 입구 노드, 또 다른 패킷 흐름에 대해 주 또는 보조 흐름 추적기, 그리고 또 다른 패킷 흐름에 대해 출구 노드로서 역할 할 수 있다. 덧붙여, 적어도 일부 실시예에서, 로드 밸런서 노드(110)는 동일한 패킷 흐름에 대한 복수의 역할, 예를 들어 특정 패킷 흐름에 대해 입구 노드 및 주(또는 보조) 흐름 추적기 노드로서 역할 할 수 있다. 그러나 적어도 일부 실시예에서, 가외성 및 복원 목적으로, 로드 밸런서 노드(110)는 동일한 패킷 흐름에 대해 주 흐름 추적기 노드와 보조 흐름 추적기 노드 모두로서 역할 하도록 허용되지 않는다.
지금까지 각각의 로드 밸런서 노드(110)가 입구 서버, 출구 서버, 및 흐름 추적기의 세 가지 역할 중 임의의 역할을 수행할 수 있는 실시예가 기재되었다. 그러나 일부 실시예에서, 컴퓨팅 장치의 서로 다른 그룹이 로드 밸런싱 시스템에서 서로 다른 역할에 할당될 수 있다. 예를 들어, 일부 실시예에서, 각각 개별 컴퓨팅 장치 상에서 구현되는 입구 노드, 출구 노드 및 흐름 추적기 노드의 구별되는 세트가 존재할 수 있다. 또 다른 예를 들면, 일부 실시예에서, 컴퓨팅 장치의 하나의 세트가 입구 노드와 흐름 추적기 노드 모두로서 역할 할 수 있고, 반면에, 컴퓨팅 장치의 또 다른 세트가 출구 노드로서만 역할 할 수 있다.
로드 밸런서 모듈
앞서 언급된 바와 같이, 각각의 서버 노드(130)는 로드 밸런서 시스템의 구성요소인 로컬 로드 밸런서 모듈(132)을 포함한다. 상기 모듈(132)은 서버 노드(130) 상에서 소프트웨어, 하드웨어, 또는 이들의 조합으로 구현될 수 있다. 적어도 일부 실시예에서, 서버 노드(130) 상의 로드 밸런서 모듈(132)은 다음의 세 가지 주요한 역할을 수행할 수 있다: 아웃고잉 패킷의 캡슐화 및 인커밍 패킷의 역캡슐화, 노드(130) 상에서 서버(134)에 대한 로컬 로드 밸런싱 결정을 내림, 및 연결 게시. 이들 세 가지 역할은 이하에서 짧게 기재되고 본 명세서에서 차후에 더 상세히 기재된다.
분산 로드 밸런싱 시스템의 적어도 일부 실시예가 TCP 연결을 종료하지 않고 패킷을 스푸핑(spoof)하지 않으며, 로드 밸런서 노드 레이어를 통해 전송된 모든 패킷의 출발지 및 도착지 IP 주소가 패킷 흐름에 포함된 종단점(즉, 클라이언트(160) 및 서버(134))의 실제 IP 주소이다. 스푸핑 대신, 이들 실시예는 로드 밸런서 노드(110)와 패브릭(120) 상의 서버 노드(130) 간에 전송되는 모든 패킷을, 예를 들어, UDP 패킷으로, 캡슐화한다. 흐름에 대한 입구 노드로서 역할 하는 로드 밸런서 노드(110)로부터 서버 노드(130)에 도달하는 패킷 흐름에서의 인바운드 패킷이 로드 밸런서 노드(110)에 의해 캡슐화되기 때문에, 패킷은 역캡슐화되고 노드(130) 상에서 서버(134)에 대한 로컬호스트 TCP 흐름으로 재지향(redirect)될 필요가 있다. 노드(130) 상의 로드 밸런서 모듈(132)이 이 역캡슐화를 수행한다. 마찬가지로, 서버(134)로부터의 패킷 흐름에 대한 아웃고잉 패킷이 로드 밸런서 모듈(132)에 의해 캡슐화되고 패브릭(120)을 통해 패킷 흐름에 대한 출구 노드로서 역할 하는 로드 밸런서 노드(110)로 전송된다.
적어도 일부 실시예에서, 서버 노드(130) 상의 로드 밸런서 모듈(132)은 각각의 서버 노드(130) 상의 서버(134)에 대한 로드 밸런싱과 관련된 로컬 결정을 내린다. 구체적으로, 노드(130) 상의 로드 밸런서 모듈(132)은 새 TCP 연결에 대한 요청을 수신하는 것에 응답하여, 각각의 서버(134)가 또 다른 TCP 흐름을 수락할지 여부를 결정한다. 앞서 언급된 바와 같이, 로드 밸런서 노드(110)는 로드 밸런서 모듈(132)로 전송된 모든 패킷을 캡슐화며, 따라서 로드 밸런서 모듈(132)은 실제로 클라이언트(160)로부터 TCP 동기화(SYN) 패킷을 수신하지 않고, 대신, 로드 밸런서 모듈(132)은 로드 밸런서 모듈(132)이 수락하거나 거절할 수 있는 흐름 추적기(116)로부터 캡슐화 프로토콜(가령, UDP)에 따라 연결 요청 메시지를 수신한다. 로드 밸런서 모듈(132)이 연결 요청 메시지를 수락한 경우, 상기 로드 밸런서 모듈(132)은 로컬호스트를 도착지로 갖는 SYN 패킷을 생성한다. 로컬호스트가 연결을 수락할 때, 이는 각각의 클라이언트 연결을 핸들링하는 실제 TCP 스택이 된다.
적어도 일부 실시예에서, 연결 요청 메시지가 수락되어야 할지 여부에 대해 결정하기 위해, 로드 밸런서 모듈(132)은 서버 노드(130) 상에서의 현재 자원 소비와 관련된 하나 이상의 메트릭을 검토하고, 새 연결을 핸들링하기 위해 충분한 자원이 이용 가능한 경우, 로드 밸런서 모듈(132)은 연결을 수락한다. 적어도 일부 실시예에서, 로드 밸런서 모듈(132)에 의해 고려될 수 있는 자원 메트릭은, 비제한적으로, CPU 활용률, 최근 대역폭 소비율, 및 확립된 연결의 수 중 하나 이상을 포함할 수 있다. 일부 실시예에서, 이들 메트릭 대신 또는 이에 추가로 또 다른 메트릭이 고려될 수 있다. 예를 들어, 일부 실시예에서, 로드 밸런서 모듈은 서버 대기시간(즉, 서버 연결 백로그에서 요청이 머무는 시간)을 메트릭으로서 고려할 수 있고 서버 대기시간이 임계값 초과인 경우 연결 요청을 거절할 수 있다. 이들 및/또는 그 밖의 다른 메트릭을 이용해, 로드 밸런서 모듈(132)은 각각의 서버(134)에 대해 상기 서버(134)가 새 패킷 흐름을 수락할지 또는 거절할지를 결정할 수 있다. 적어도 일부 실시예에서, 메트릭(들)로부터 개별적으로 또는 조합되어 자원 활용률(가령, N% 활용률)이 결정되고 임계값(가령, 90% 활용률)에 비교될 수 있다. 결정된 자원 활용률이 임계값 이상인 경우, 또는 연결을 추가함으로써 활용률이 임계값보다 높아질 경우, 연결 요청이 거절될 수 있다.
적어도 일부 실시예에서, 로드 밸런서 모듈(132)이 연결 요청 메시지가 거절될 것인지 여부를 결정하기 위한 확률 방법을 구현할 수 있다. 자원 활용률이 임계값 이상인 경우 앞서 기재된 바와 같이 모든 연결 요청을 거절하는 대신, 이 방법에서 둘 이상의 서로 다른 레벨의 활용률에서 서로 다른 확률로 연결 요청을 거절할 수 있다. 예를 들어, 자원 활용률이 80%인 경우, 로드 밸런서 모듈(132)은 20% 확률로 연결 요청을 거절할 수 있고, 자원 활용률이 90%인 경우, 로드 밸런서 모듈(132)은 25% 확률로 연결 요청을 거절할 수 있으며, 자원 활용률이 95%인 경우, 로드 밸런서 모듈(132)은 50%의 확률로 연결 요청을 거절할 수 있고, 98% 이상인 경우, 로드 밸런서 모듈(132)은 모든 연결 요청을 거절할 수 있다.
적어도 일부 실시예에서, 각각의 연결 요청 메시지가 로드 밸런서 모듈(132)에 의해 연결 요청 메시지가 거절된 횟수의 지시자를 포함할 수 있다. 로드 밸런서 모듈(130)에 의해 수신된 연결 요청 메시지가 임계 횟수 이상으로 거절됐음을 지시하는 경우, 서버 노드(130)의 성능 메트릭이 연결 요청이 거절되어야 할 때를 지시하는 경우라도 로드 밸런스 모듈(130)은 연결을 수락할 수 있다.
일부 경우, 연결 요청 메시지가 전송된 모든 로드 밸런서 모듈(132)이 연결 요청을 거절할 수 있는 것이 가능하다. 적어도 일부 실시예에서, 연결 요청 메시지가 무한 주기 동안 로드 밸런서 모듈(132)로부터 로드 밸런서 모듈(132)로 바운싱되는 것을 막기 위해, 각각의 연결 요청 메시지에 수명시간(time to live)이 주어질 수 있다. 이 수명시간이 만료될 때, 흐름 추적기 노드가 요청을 종료하고 각각의 클라이언트(160)에게 요청이 현재 서비스되지 않을 수 있음을 통지할 수 있다.
적어도 일부 실시예에서, 또한 서버 노드(130) 상의 로드 밸런서 모듈(132)은 로드 밸런서 노드(110)로의 연결 게시(connection publishing)를 수행한다. 적어도 일부 실시예에서, 연결 게시를 수행하기 위해, 주기적으로 또는 비주기적으로(가령, 1초에 1회) 각각의 로드 밸런서 모듈(132)은 서버 노드(130) 상의 라우팅 테이블(가령, netstat 라우팅 테이블)을 살펴보고 활성 연결(TCP 흐름)의 리스트를 로드 밸런서 노드(110)에게 다시 게시한다. 특정 패킷 흐름의 존재에 대한 정보를 받을 필요가 있는 로드 밸런서 노드(110)는 각각의 패킷 흐름에 대해 입구 노드로서 그리고 주 및 보조 흐름 추적기로서 기능하는 로드 밸런서 노드(110)이다. 일부 실시예에서, 로드 밸런서 모듈(132)은 서버 노드(130) 상에서 활성 TCP 흐름에 대한 정보를 받을 필요가 있는 로드 밸런서 노드(110)의 리스트를 필터링하기 위해 일관 해싱 기법을 이용할 수 있다. 예를 들어, 로드 밸런서 모듈(132)은 일관 해시 링에 따라 어느 로드 밸런서 노드(110)가 특정 패킷 흐름에 대한 주 및 보조 흐름 추적기로서 역할 하는지를 결정할 수 있다. 일부 실시예에서, 로드 밸런서 모듈(132)은 각각의 패킷 흐름에 대해 어느 로드 밸런서 노드(110)가 마지막으로 데이터 패킷을 로드 밸런서 모듈(132)로 전송했는지를 추적하고, 이 정보를 이용해 어느 로드 밸런서 노드(110)가 패킷 흐름에 대한 입구 노드로서 역할 하는지를 결정하는데, 이는 입구 노드만이 클라이언트 데이터를 로드 밸런서 모듈(132)로 전달하기 때문이다. 일부 실시예에서, 그 후 로드 밸런서 모듈(132)은 로드 밸런서 노드(110) 각각에 대해 패킷 흐름에 대한 정보를 받을 필요가 있다고 결정한 메시지를 제작(fabricate)하고 상기 메시지를 로드 밸런서 노드(110)로 전송하여 노드(110)에게 각각의 서버 노드(130)가 여전히 클라이언트(들)(160)로의 연결(들)을 유지관리하고 있음을 알릴 수 있다. 이러한 로드 밸런서 모듈(132)에 의해 로드 밸런서 노드(110)로의 연결 게시는 로드 밸런서 노드(110)에서의 리스(lease)를 연장시키는 것으로 보일 수 있다. 로드 밸런서 노드(110)가 일정 시간 주기(가령, 10초) 내에 특정 패킷 흐름을 지시하는 연결 게시 메시지를 수신하지 않았던 경우, 로드 밸런서 노드(110)는 각각의 패킷 흐름에 대해 자유롭게 잊을 수 있다.
로드 밸런서 노드로의 다중경로 라우팅
도 4는 적어도 일부 실시예에 따라, 분산 로드 밸런서에서의 라우팅 및 패킷 흐름의 양태를 도시한다. 적어도 일부 실시예에서, 각각의 입구 노드(입구 노드는 도 4에서 입구 서버(112)로 나타난다)가 자신이 분산 로드 밸런서에 대한 하나 이상의 공중 종단점(public endpoint)(가령, IP 주소 및 포트)을 에지 라우터(104)로 라우팅할 수 있음을 가령, 경계 게이트웨이 프로토콜(BGP)을 통해 광고한다. 적어도 일부 실시예에서, 각각의 입구 노드가 BGP 세션을 통해 에지 라우터(104)로 스스로 광고하기보다는, 도 5에 도시된 바와 같이 하나 이상의 다른 입구 노드, 가령, 두 개의 이웃 노드가 에지 라우터(104)와의 BGP 세션을 확립하여 입구 노드를 광고할 수 있다.
일반적으로 종래의 로드 밸런서는 단일 공중 종단점을 서비스할 수 있다. 이와 달리, 분산 로드 밸런서의 실시예에 의해 복수의 로드 밸런서 노드(110)가 단일 공중 종단점을 서비스할 수 있다. 라우터 능력에 따라서, 이는 에지 라우터(들)(104)을 통해 모든 입구 서버(112)로 라우팅되는 단일 공중 IP 주소가 전체 대역폭(가령, 160 Gbps)을 핸들링할 수 있는 구성을 가능하게 한다. 적어도 일부 실시예에서, 이를 이루기 위해, 에지 라우터(들)(104)는 레이어 4 흐름당 해싱된 다중경로 라우팅 기법, 가령, 등가 다중경로(ECMP) 라우팅 기법을 이용해, 동일한 공중 IP 주소를 각각 광고하는 복수의 입구 서버(112)에 걸쳐 트래픽을 분산시킬 수 있다. 흐름에 대해 레이어-4 출발지 및 도착지 포트를 이용해 모든 입구 서버(112)로 인커밍 패킷을 에지 라우터(들)(104) 흐름 패킷의 일부로서 분산시키는 것은 일반적으로 입구 서버(112)로서 역할 하는 동일한 로드 밸런서 노드(110)로 라우팅되는 각각의 연결에 대해 패킷을 유지하여, 비정렬 패킷(out-of-order packet)을 피할 수 있다. 그러나 에지 라우터(들)(104)이 일부 실시예에서 입구 서버(112)들에게 트래픽을 분산시키기 위한 그 밖의 다른 기법을 이용할 수 있다.
또한 도 4는 둘 이상의 분산 로드 밸런서가 네트워크(100) 상에서 구현될 수 있다. 둘 이상의 분산 로드 밸런서 각각이 복수의 서버(130)를 앞두고 각각 서로 다른 공중 IP 주소를 광고하는 독립적인 로드 밸런서로서 역할 하거나, 대안적으로 도 4에 도시된 바와 같이 둘 이상의 분산 로드 밸런서가 각각 동일한 IP 주소를 광고할 수 있고, 해싱 기법(가령, 레이어 4 흐름당 해싱된 다중경로 라우팅 기법)이 경계 라우터(들)(102)에서 사용되어, 패킷 흐름을 에지 라우터(104)로 분할시킬 수 있으며, 이로써 패킷 흐름이 이들 각자의 입구 서버(112)로 분산된다.
도 5는 적어도 일부 실시예에 따라, 경계 게이트웨이 프로토콜(BGP)을 이용하여 입구 노드를 에지 라우터에게 광고하는 것을 도시한다. 이 예시에서, 로드 밸런서 구현에서 입구 노드(110A 내지 110D)로서 역할 하는 4개의 로드 밸런서 노드가 존재한다. 에지 라우터(104)는 클라이언트(도시되지 않음)로부터의 인커밍 패킷을 로드 밸런서 노드(110)로 라우팅한다. 적어도 일부 실시예에서, 에지 라우터(104)는 레이어 4 흐름당 해싱된 다중경로 라우팅 기법, 가령, 등가 다중경로(ECMP) 라우팅 기법에 따라 라우팅 결정을 할 수 있다.
적어도 일부 실시예에서, 에지 라우터(104)는 입구 노드(110)에 의해 개시되는 경계 게이트웨이 프로토콜(BGP) 기법 광고 세션을 통해 클라이언트 트래픽을 수신하기 위해 로드 밸런서 구현에서 현재 이용 가능한 입구 노드(110)에 대해 학습한다. 각각의 입구 노드(110)는 에지 라우터(104)에게 자신을 광고하기 위해 BGP를 이용할 수 있다. 그러나 일반적으로 BGP의 커버리지 시간은 비교적 길다(3초 이상). 각각의 입구 노드(110)가 BGP를 통해 자신을 광고하는 이 기법을 이용해, 입구 노드(110)가 작동 중단된 경우, 에지 라우터(104) 상의 BGP 세션이 만료되고, 따라서 에지 라우터(104)가 고장 폐쇄에 대해 학습하여 현재 TCP 흐름을 입구 노드(110)로 재라우팅(reroute)하는 데 네트워킹 측면에서 상당한 시간(3초 이상)이 걸릴 수 있다.
BGP가 갖는 수렴 문제(convergence problem)를 피하기 위해 그리고 노드(110) 고장을 더 빠르게 복원하기 위해, 적어도 일부 실시예에서, BGP 세션을 통해 입구 노드(110)가 스스로를 에지 라우터(104)에게 광고하는 대신, 로드 밸런서 구현의 적어도 하나의 다른 입구 노드(110)가 BGP를 통해 입구 노드(110)를 에지 라우터(104)에게 광고할 책임을 가진다. 예를 들어, 도 5에 도시된 일부 실시예에서, 특정 입구 노드(110)의 좌측 및 우측 이웃 입구 노드(110), 가령, 노드(110)들의 정렬된 리스트, 가령, 노드(110)로 형성된 일관 해시 링 내 좌측 및 우측 이웃이 특정 입구 노드(110)를 에지 라우터(104)에게 광고할 수 있다. 예를 들어, 도 5에서, 입구 노드(110A)가 입구 노드(110B 및 110D)를 광고하고, 입구 노드(110B)가 입구 노드(110A 및 110C)를 광고하며, 입구 노드(110C)가 입구 노드(110B 및 110D)를 광고하고, 입구 노드(110D)가 입구 노드(110C 및 110A)를 광고한다. 본 명세서에서 차후에 기재될 바와 같이, 입구 노드(110)들은 서로의 건강을 체크하고 가십을 전파한다. 기재된 건강 체크 방법을 이용해, 건강하지 않은 노드가 검출되고 1초 미만, 가령, 100밀리초(ms) 내에 정보가 노드(110)들 간에 전파될 수 있다. 입구 노드(110)가 건강하지 않다고 결정되면, 건강하지 않은 노드를 광고하는 입구 노드(110)는 건강하지 않은 노드(110)를 광고하는 것을 즉시 중단할 수 있다. 적어도 일부 실시예에서, 입구 노드(110)는 BGP 세션에 대한 TCP 폐쇄 또는 유사한 메시지를 에지 라우터(104)로 전송함으로써, 에지 라우터(104)와의 BGP 세션을 종료한다. 따라서 노드(110) 고장을 검출하기 위해 고장 난 노드(110)에 의해 확립된 BGP 세션이 만료되기를 기다릴 필요 없이, 고장 난 노드(110)를 대신하여 광고하는 그 밖의 다른 입구 노드(110)가 노드(110)가 건강하지 않음을 검출한 후 노드(110)를 광고하는 에지 라우터(104)와의 BGP 세션을 종료할 때 에지 라우터(104)가 고장 난 노드(110)를 발견할 수 있다. 로드 밸런서 노드의 고장 핸들링이 본 명세서에서 차후에 도 18a 및 18b를 참조하여 더 설명된다.
도 6은 분산 로드 밸런싱 시스템의 적어도 일부 실시예에 따르는 다중경로 라우팅 방법의 흐름도이다. (900)으로 지시되는 바와 같이, 로드 밸런서 구현에서의 입구 노드(110)가 자신의 이웃 노드(110)를 에지 라우터(104)로 광고한다. 적어도 일부 실시예에서, 입구 노드(110)는 노드(110)들의 정렬된 리스트, 가령, 일관 해시 링에 따라 자신의 이웃 노드(110)를 결정할 수 있다. 적어도 일부 실시예에서, 입구 노드(110)는 BGP 세션을 이용해 자신의 이웃 노드(들)(110)를 에지 라우터(104)에게 광고하고, 이때, 각각의 광고된 노드(110)에 대해 하나씩의 BGP 세션이 에지 라우터(104)로 확립된다.
(902)로 지시되는 바와 같이, 흐름당 해싱된 다중경로 라우팅 기법, 가령, 등가 다중경로(ECMP) 라우팅 기법에 따라, 에지 라우터(104)는 클라이언트(160)로부터 수신된 트래픽을 활성(광고되는) 입구 노드(110)로 분산시킨다. 적어도 일부 실시예에서, 에지 라우터(104)는 공중 IP 주소를 클라이언트(160)에게 노출시키고, 입구 노드(110)는 모두 동일한 공중 IP 주소를 에지 라우터(104)에게 광고한다. 상기 에지 라우터는 에지 라우터(104)의 흐름 해시의 일부로서 레이어-4 출발지 및 도착지 포트를 이용하여 인커밍 패킷을 입구 노드(110)들 간에 분산시킬 수 있다. 일반적으로 이는 각각의 연결에 대한 패킷을 동일한 입구 노드(110)로 라우팅되도록 유지한다.
(902)로 지시되는 바와 같이, 입구 노드는 데이터 흐름을 타깃 서버 노드(130)로 전달한다. 적어도 일부 실시예에서, 입구 노드(110)는 데이터 흐름에 대해 주 및 보조 흐름 추적기 노드와 상호대화하여 데이터 흐름을 타깃 서버 노드(130)로 맵핑할 수 있다. 따라서 각각의 입구 노드(110)는 수신된 패킷을 타깃 서버 노드(130)로 적절하게 전달하기 위해 사용될 수 있는 노드(110)를 통해 활성 데이터 흐름의 맵핑을 유지할 수 있다.
요소(906 내지 910)가 입구 노드(110) 고장의 검출 및 이로부터의 복원과 관련된다. (906)으로 지시되는 바와 같이, 입구 노드(110)는, 가령, 본 명세서에 기재된 바와 같이 건강 체크 기법에 따라, 입구 노드(110)가 동작 중단됨을 검출할 수 있다. 노드(110)가 동작 중단됨이 검출되면, 이의 이웃 노드(110)가 에지 라우터(104)에게 노드(110)를 광고하는 것을 중단한다. 적어도 일부 실시예에서, 이는 각각의 BGP 세션에 대해 에지 라우터(104)로 TCP 폐쇄를 전송하는 것을 포함한다.
(908)로 지시되는 바와 같이, 에지 라우터(104)는, BGP 세션의 폐쇄를 통해 입구 노드(110)가 동작 중단됨을 검출한 후, 흐름당 해싱된 다중경로 라우팅 기법에 따라, 클라이언트(160)로부터의 인커밍 트래픽을 나머지 입구 노드(110)로 재분산시킨다. 따라서 적어도 일부 데이터 흐름이 서로 다른 입구 노드(110)로 라우팅될 수 있다.
(910)로 지시되는 바와 같이, 입구 노드(110)가 필요에 따라 맵핑을 복원하고 데이터 흐름을 적절한 타깃 서버 노드로 전달할 수 있다. 입구 노드(110) 상에서 노드(110) 고장으로부터 복원되기 위한 방법이 본 명세서에서 언급된다. 하나의 예를 들면, 입구 노드(110)가, 현재 맵핑을 갖지 않는 패킷을 수신하면, 일관 해시 함수를 이용하여 일관 해시 링에 따라 데이터 흐름에 대한 흐름 추적기 노드를 결정하고 흐름 추적기 노드로부터 맵핑을 복원할 수 있다.
비대칭 패킷 흐름
적어도 일부 실시예에서, 인바운드 데이터에 대한 아웃바운드 트래픽의 비가 1보다 클 때 입구 노드 대역폭 및 CPU 이용률을 효과적으로 이용하기 위해, 도 7에 도시된 바와 같이, 분산 로드 밸런싱 시스템은 서버 노드(130)로부터의 아웃바운드 패킷을 복수의 출구 노드로 전달한다. 적어도 일부 실시예에서, 각각의 연결에 대해, 각자의 서버 노드(130) 상의 로드 밸런서 모듈(132)이 클라이언트 종단점/공중 종단점 튜플을 해싱하고 일관 해시 알고리즘을 이용해 각각의 아웃바운드 패킷 흐름에 대해 출구 서버(114)로서 역할 할 로드 밸런서 노드(110)를 선택할 수 있다. 그러나 일부 실시예에서, 그 밖의 다른 방법 및/또는 데이터가 연결에 대해 출거 서버(114)를 선택하도록 사용될 수 있다. 선택된 출구 서버(114)는 일반적으로, 그러나 필수는 아니게, 연결에 대해 입구 서버(112)로서 역할 하는 로드 밸런서 노드(110)와 상이한 로드 밸런서 노드(110)일 수 있다. 적어도 일부 실시예에서, 상기 로드 밸런서 노드(110)/출구 서버(114)에 고장이 있지 않는 한, 특정 연결에 대한 모든 아웃바운드 패킷이 동일한 출구 서버(114)로 전달되어 비정렬 패킷을 피할 수 있다.
적어도 일부 실시예에서, 서버 노드(130)에 의해 출구 서버(114)를 선택하기 위해 사용되는 방법 및 데이터가 에지 라우터(들)(104)에 의해 수행되는 입구 서버(112)를 선택하기 위해 사용되는 방법 및 데이터와 상이할 수 있다. 상이한 방법 및 데이터를 이용함으로써 일반적으로 연결에 대해 입구 노드로서 선택된 로드 밸런서 노드(110)와 상이한 로드 밸런서 노드(110)가 특정 연결에 대한 출구 노드로서 선택될 수 있고, 또한 복수의 로드 밸런서 노드(110)가 입구 노드로서 역할 하는 단일 로드 밸런서 노드(110)를 통과하는 연결에 대한 아웃고잉 트래픽을 핸들링하기 위한 출구 노드로서 선택될 수 있다.
도 7은 적어도 일부 실시예에 따르는 비대칭 패킷 흐름을 그래픽적으로 도시한다. 외부 네트워크(150) 상의 클라이언트(160)로부터 입구 서버(112)를 통해 서버 노드(130A, 130B, 130C, 및 130D) 각각으로 적어도 하나의 연결이 확립되었다. 적어도 일부 실시예에서, 연결에 대해 출구 노드를 선택하기 위해, 각각의 연결에 대해, 각각의 서버 노드(130) 상의 로드 밸런서 모듈(132)이 클라이언트 종단점/공중 종단점 튜플을 해싱하고 일관 해시 알고리즘을 이용해 각각의 아웃바운드 패킷 흐름에 대해 출구 서버(114)로서 역할 하는 로드 밸런서 노드(110)를 선택할 수 있다. 예를 들어, 서버 노드(130A)가 연결에 대해 출구 서버(114A)를 선택했고, 서버 노드(114B)가 한 연결에 대해 출구 서버(114A)를 그리고 다른 한 연결에 대해 출구 서버(114B)를 선택했다. 그러나 일부 실시예에서 그 밖의 다른 방법 및/또는 데이터가 연결에 대해 출구 노드를 선택하기 위해 사용될 수 있다.
클라이언트 연결을 끊지 않고 로드 밸런서 노드 고장으로부터 복원하기
로드 밸런서 노드(110)가 일관 해싱을 이용해 어느 서버 노드(130)가 클라이언트 트래픽을 수신해야 하는지를 결정하는 것이 가능하지만, 일부 연결의 긴 수명으로 인해, 이 방식은 새 서버 노드(130)가 일관 해시 구성원으로 가입하고 다음 입구 로드 밸런서 노드(110) 고장이 있는 경우에 기존 흐름을 유지관리할 수 없다. 이 시나리오에서, 서버(130)에 대한 일관 해시 링이 상이한 구성원을 가질 것이기 때문에, 고장 난 노드(110)로부터 흐름을 넘겨받은 로드 밸런서 노드(110)가 선택된 본래의 맵핑을 결정하지 못할 수 있다. 따라서 적어도 일부 실시예에서, 분산 해시 테이블(DHT)(distributed hash table) 기법이 로드 밸런서 노드(110)에 의해 사용되어 연결에 대한 서버 노드(130)를 선택하고 패킷을 선택된 서버 노드(130)로 라우팅할 수 있다. DHT에 따라 특정 연결을 수신하기 위한 서버 노드(130)가 선택되고, 서버 노드(130)가 건강한 상태를 유지하고 서버 노드(130) 상의 로드 밸런서 모듈(132)이 (가령, 연결 게시를 통해) DHT로 활성 연결의 상태를 주기적으로 전송함으로써 리스(lease)를 계속 연장한다고 가정하면, 상기 DHT는 연결이 완료될 때까지 맵핑을 유지할 것이다. 입구 노드(110) 고장이 에지 라우터(104)로부터의 패킷의 나머지 로드 밸런서 노드(110)로의 분산에 영향을 미침으로써, 로드 밸런서 노드(110)가 클라이언트 연결의 상이한 세트로부터 트래픽을 수신하게 된다. 그러나 DHT가 모든 활성 연결을 추적하기 때문에, 로드 밸런서 노드(110)는 임의의 활성 맵핑에 대한 리스를 획득하기 위해 DHT에게 질의할 수 있다. 따라서, 모든 로드 밸런서 노드(110)는 올바른 서버 노드(130)로 트래픽을 전달하여, 입구 로드 밸런서 노드(110) 고장의 경우에도 활성 클라이언트 연결의 고장을 방지한다.
분산 로드 밸런싱 시스템에서의 패킷 흐름
도 8은 적어도 일부 실시예에 따르는 분산 로드 밸런싱 시스템에서의 패킷 흐름을 도시한다. 도 8의 화살표 있는 실선은 TCP 패킷을 나타내고 반면에 화살표 있는 점선은 UDP 패킷을 나타낸다. 도 8에서, 입구 서버(112)는 에지 라우터(104)를 통해 하나 이상의 클라이언트(160)로부터 TCP 패킷을 수신한다. TCP 패킷의 수신 후, 입구 서버(112)는 자신이 서버 노드(130)로의 TCP 패킷 흐름에 대한 맵핑을 갖는지 여부를 결정한다. 입구 서버(112)가 TCP 패킷 흐름에 대한 맵핑을 갖는 경우, 서버(112)는 (가령, UDP에 따른) TCP 패킷을 캡슐화하고 캡슐화된 패킷을 타깃 서버 노드(130)로 전송한다. 입구 서버(112)가 TCP 패킷 흐름에 대한 맵핑을 갖지 않는 경우, 입구 서버(112)는 TCP 패킷으로부터 추출된 TCP 패킷 흐름에 대한 정보가 포함된 UDP 메시지를 주 흐름 추적기(116A)로 전송하여, 서버 노드(130)로의 연결을 확립 및/또는 TCP 패킷 흐름에 대한 맵핑을 획득할 수 있다. 도 9a 및 9b 및 도 10a 내지 10g는 클라이언트(160)와 서버 노드(130) 간 연결을 확립하기 위한 방법을 확립한다. 서버 노드(130) 상의 로드 밸런서 모듈(132)이 서버 노드(130) 상에서 TCP 연결(들)에 대한 출구 서버(들)(114)로서 역할 할 로드 밸런서 노드(들)(110)를 랜덤하게 선택하고 출구 서버(들)(114)를 통해 UDP-캡슐화된 TCP 응답 패킷을 클라이언트(들)(160)에게 전송한다.
도 9a 및 9b는 적어도 일부 실시예에 따라, 분산 로드 밸런싱 시스템에서 연결을 확립할 때 패킷 흐름의 흐름도를 제공한다. 도 9a의 (200)으로 지시되는 바와 같이, 입구 서버(112)가 클라이언트(160)로부터 에지 라우터(104)를 통해 TCP 패킷을 수신한다. (202)에서, 입구 서버(112)가 서버 노드(130)로의 TCP 흐름에 대한 맵핑을 갖는 경우, (204)로 지시되는 바와 같이, 입구 서버(112)는 TCP 패킷을 캡슐화하고 각각의 서버 노드(130)로 전송한다. 입구 서버(112)가 하나, 둘, 또는 그 이상의 클라이언트(160)로부터의 하나, 둘, 또는 그 이상의 TCP 흐름에 대해 패킷을 지속적으로 수신 및 프로세싱할 수 있다.
(202)에서, 입구 서버(112)가 TCP 흐름에 대한 맵핑을 갖지 않는 경우, 패킷은 클라이언트(160)로부터의 TCP 동기화(SYN) 패킷일 수 있다. (206)에서 도시된 바와 같이, SYN 패킷을 수신하면, 입구 서버(112)는 상기 SYN 패킷으로부터 데이터를 추출하고 상기 데이터를, 가령, UDP 메시지의 형태로 주 흐름 추적기(116A)로 전달한다. 적어도 일부 실시예에서, 입구 서버(112)는 일관 해시 함수에 따라 TCP 흐름에 대해 주 흐름 추적기(116A) 및/또는 보조 흐름 추적기(116B)를 결정할 수 있다. (208)에서, 주 흐름 추적기(116A)는 데이터를, 가령, 해시 테이블에 저장하고, TCP 연결의 서버 노드(130) 측을 위한 초기 TCP 시퀀스 번호를 생성하며, 데이터 및 TCP 시퀀스 번호를 보조 흐름 추적기(116B)에게 전달한다. (210)에서, 보조 흐름 추적기(116B)는 또한 데이터를 저장할 수 있으며, SYN/ACK 패킷을 제작하고 클라이언트(160)에게 전송하는데, 상기 SYN/ACK 패킷은 적어도 TCP 시퀀스 번호를 포함한다.
(212)로 지시되는 바와 같이, 입구 서버(112)는 에지 라우터(104)를 통해 클라이언트(160)로부터 TCP 긍정응답(ACK) 패킷을 수신한다. 입구 서버(112)는 서버(130) 노드로의 TCP 흐름에 대한 맵핑을 갖지 않으며, 따라서 (214)에서 입구 서버(112)는 ACK 패킷으로부터 추출된 데이터를 포함하는 메시지를 주 흐름 추적기(116A)로 전송한다. (216)로 지시되는 바와 같이, 메시지를 수신하면, 주 흐름 추적기(116A)가 저장된 데이터에 따라 TCP 흐름을 확인하고, ACK 패킷으로부터의 긍정응답된 시퀀스 번호(+1)가 SYN/ACK로 전송된 값과 매칭함을 확인한다. 그 후 주 흐름 추적기(116A)가 TCP 흐름을 수신할 서버 노드(130)를 선택하고, 데이터, TCP 시퀀스 번호, 및 선택된 서버 노드(130) 상의 로컬 로드 밸런서 모듈(132)의 IP 주소를 포함한 메시지를 보조 흐름 추적기(116B)로 전송한다. (218)로 지시되는 바와 같이, 보조 흐름 추적기(116B)는 데이터 및 TCP 시퀀스 번호를 확인하고 SYN 메시지를 제작하며 제작된 SYN 메시지를 선택된 서버 노드(130) 상의 로컬 로드 밸런서 모듈(132)에게 전송한다. 상기 방법은 도 9b의 요소(220)에서 계속된다.
도 9b의 (220)로 지시되는 바와 같이, 제작된 SYN 메시지에 응답하여, 로드 밸런서 모듈(132)은 서버 노드(130)의 하나 이상의 메트릭을 검사하여 서버 노드(130)가 연결을 수락할 수 있는지 여부를 결정할 수 있다. (222)에서, 로드 밸런서 모듈(132)이 서버 노드(130)가 현재 연결을 수락할 수 없다고 결정한 경우, (224)에서 로드 밸런서 모듈(132)은 보조 흐름 추적기(116B)에게 메시징한다. 보조 흐름 추적기(116B)는 자신이 이전에 저장한 흐름에 대한 정보를 삭제할 수 있다. (226)에서, 보조 흐름 추적기(116B)는 주 흐름 추적기(116A)에게 메시징한다. 그 후 도 9a의 (216)으로 지시되는 바와 같이, 주 흐름 추적기(116A)는 새 타깃 서버 노드(130)를 선택하고 보조 흐름 추적기(116B)에게 메시징할 수 있다.
(222)에서, 로드 밸런서 모듈(132)이 서버 노드(130)가 연결을 수락할 수 있다고 결정하는 경우, 도 9b의 (228)로 지시되는 바와 같이 로컬 로드 밸런서 모듈(132)은 제작된 SYN으로부터 TCP SYN 패킷을 구성하고 상기 TCP SYN 패킷을 서버 노드(130) 상의 서버(134)로 전송한다. TCP SYN 패킷의 소스 IP 주소가 클라이언트(160)의 실제 IP 주소로 채워져서, 서버(134)는 자신이 클라이언트(160)로의 직접 TCP 연결을 수신했다고 믿을 것이다. 로드 밸런서 모듈(132)은 TCP 흐름에 대한 관련 상세사항을, 가령, 로컬 해시 테이블에 저장한다. (230)으로 지시되는 바와 같이, 서버(134)가 로드 밸런서 모듈(132)이 인터셉트한 SYN/ACK 패킷으로 응답한다. 그 후 (232)로 지시되는 바와 같이, 로드 밸런서 모듈(132)은 연결 정보를 포함하는 메시지를 보조 흐름 추적기(116B)로 전송하여, 연결이 수락됐음을 가리킬 수 있다. 이 메시지가 수신되면, (234)에서 보조 흐름 추적기(116B)는 서버(134)로의 맵핑을 기록하고 유사한 메시지를 주 흐름 추적기(116A)로 전송하며, 주 흐름 추적기는 또한 맵핑 정보를 기록한다. (236)으로 지시되는 바와 같이, 그 후 주 흐름 추적기(116A)는 맵핑 메시지를 입구 서버(112)로 전달한다. 이제 입구 서버(112)는 클라이언트(160)로부터 서버(130)로의 TCP 흐름에 대한 맵핑을 가진다.
(238)에서, 입구 서버(112)는 데이터 흐름에 대한 임의의 버퍼링된 데이터 패킷을 캡슐화하고 서버 노드(130) 상의 로컬 로드 밸런서 모듈(132)로 전달한다. 클라이언트(160)로부터의 데이터 흐름에 대한 입구 서버(112)에 의해 수신된 추가 인커밍 패킷이 캡슐화되고 로드 밸런서 모듈(132)에게 직접 전달되며, 상기 로드 밸런서 모듈은 상기 패킷을 역캡슐화하며 데이터 패킷을 서버(134)로 전송한다
(240)에서, 로드 밸런서 모듈(132)은 데이터 흐름에 대한 출구 서버(114)를 랜덤하게 선택한다. 서버(134)로부터의 다음 아웃바운드 TCP 패킷이 로드 밸런서 모듈(132)에 의해 인터셉트되고, UDP에 따라 캡슐화되며, 임의로 선택된 출구 서버(114)로 전달된다. 출구 서버(114)는 아웃고잉 패킷을 역캡슐화하고 TCP 패킷을 클라이언트(160)에게 전송한다.
앞서 언급된 바와 같이, (202)에서, 입구 서버(112)가 수신된 패킷의 TCP 흐름에 대한 맵핑을 갖지 않는 경우, 패킷은 클라이언트(160)로부터의 TCP 동기화(SYN) 패킷일 수 있다. 그러나 패킷은 TCP SYN 패킷이 아닐 수 있다. 예를 들어, 로드 밸런서 노드(110)의 추가 또는 고장으로 인해 로드 밸런서 노드(110) 구성원이 변경된 경우, 에지 라우터(104)는 입구 서버(112)가 맵핑을 갖지 않는 하나 이상의 TCP 흐름에 대해 패킷을 입구 서버(112)로 라우팅하기 시작할 수 있다. 적어도 일부 실시예에서, 입구 서버(112)가 맵핑을 갖지 않는 이러한 패킷을 수신하면, 상기 입구 서버(112)는 일관 해시 함수를 이용해 일관 해시 링에 따라 TCP 흐름에 대해 주 흐름 추적기(116A) 및/또는 보조 흐름 추적기(116B)를 결정할 수 있고 주 흐름 추적기(116A) 또는 보조 흐름 추적기(116B)에게 메시징하여 맵핑을 요청할 수 있다. 흐름 추적기(116)로부터 TCP 흐름에 대한 맵핑을 수신하면, 입구 서버(112)는 맵핑을 저장하고 TCP 흐름에 대한 TCP 패킷(들)을 캡슐화하고 도착지 서버 노드(130)로 전달하기 시작한다.
로드 밸런서 노드 상세사항
적어도 일부 실시예에서, 로드 밸런서 노드(110) 각각은 다음의 세 가지 역할을 가진다:
Figure pat00001
입구 - 하나의 클라이언트 연결에서 클라이언트(160)로부터 모든 인커밍 패킷을 수신하고, 맵핑이 알려진 경우 패킷을 서버 노드(130)로 라우팅함 또는 맵핑이 알려져 있지 않은 경우 흐름 추적기에게 메시징함. 입구 노드에 의해 (가령, UDP에 따라) 입구 노드로부터의 아웃고잉 패킷이 캡슐화된다.
Figure pat00002
흐름 추적 - 연결 상태를 계속 파악함(가령, 어느 서버 노드(130)/ 서버(134)가 각각의 클라이언트 연결을 서비스하도록 할당됐는지를 계속 파악함). 흐름 추적기는 또한 클라이언트(160)와 서버(134) 간 연결을 확립하는 데 참여한다.
Figure pat00003
출구 - 서버(134)로부터 수신된 아웃바운드 패킷을 역캡슐화하고 클라이언트(160)로 전달함.
적어도 일부 실시예에서, 입구 역할에서, 로드 밸런서 노드(110)는, 클라이언트 -> 서버 맵핑이 알려져 있을 때 패킷을 서버(134)로 전달하거나, 맵핑이 알려져 있지 않을 때 흐름 추적기에게 요청을 전달하는 책임을 가진다. 적어도 일부 실시예에서, 특정 클라이언트 연결/데이터 흐름에 대해 입구 노드로서 역할 하는 로드 밸런서 노드(110)가 또한 클라이언트 연결에 대해 주 흐름 추적기 또는 보조 흐름 추적기로서도 역할 할 수 있지만, 두 역할 모두를 수행할 수는 없다.
적어도 일부 실시예에서, 흐름 추적기 역할에서, 로드 밸런서 노드(110)가 여전히 확립되어 있는 연결의 상태를 유지관리할 뿐 아니라 확립된 연결에 대해 클라이언트->서버 맵핑까지 유지관리할 책임을 가진다. 두 개의 흐름 추적기가 각각의 개별 클라이언트 연결과 연관되며, 주 흐름 추적기 및 보조 흐름 추적기라고 지칭된다. 적어도 일부 실시예에서, 일관 해시 알고리즘을 이용해 클라이언트 연결과 연관된 흐름 추적기가 결정될 수 있다. 또한 흐름 추적기는 로드-밸런싱 기능을 수행할 수 있는데, 비제한적 예를 들면, 각각의 새 클라이언트 연결에 대해 서버 노드(130)를 의사랜덤하게 선택할 수 있다. 서버(134)가 연결을 핸들링할 수 없다고 결정한 경우 선택된 서버 노드(130) 상의 로컬 로드 밸런서 모듈(132)이 연결 요청을 거절할 수 있다. 이러한 일이 발생하면, 흐름 추적기가 또 다른 서버 노드(130)를 선택하고 연결 요청을 그 밖의 다른 서버 노드(130)로 전송할 수 있다. 적어도 일부 실시예에서, 특정 연결에 대한 주 흐름 추적기 역할 및 보조 흐름 추적기 역할이 서로 다른 로드 밸런서 노드(110)에 의해 수행된다.
적어도 일부 실시예에서, 출구 역할에서, 로드 밸런서 노드(110)는 무상태형(stateless)이고 서버 노드(130)로부터 수신된 인커밍 패킷을 역캡슐화하고 일부 검증을 수행하며 아웃바운드 TCP 패킷을 각각의 클라이언트(160)로 전달한다. 적어도 일부 실시예에서, 서버 노드(130) 상의 로컬 로드 밸런서 모듈(132)은 특정 연결에 대해 로드 밸런서 노드(110)를 임의적으로 선택할 수 있다.
로드 밸런서 노드 일관 해시 링 토폴로지
적어도 일부 실시예에서, 로드 밸런서 노드(110)는 입력 키공간(클라이언트 종단점, 공중 종단점)의 일관 해싱을 기초로 링 토폴로지를 형성한다. 입력 키공간은 가용 흐름 추적기 노드들 간에 분할되고, 모든 흐름 추적기 노드가 자신의 키공간에 대응하는 질의에 대답할 책임을 가질 수 있다. 적어도 일부 실시예에서, 데이터가 일관 해시 링의 후속자(가령, 보조 흐름 추적기 노드가 일관 해시 링에서 주 흐름 추적기 노드의 후속자 노드, 또는 옆 노드이다)를 기초로 주 및 보조 흐름 추적기 노드로 복제될 수 있다. 흐름 추적기 노드가 어떠한 이유로 동작 중단되는 경우, 일관 해시 링 내 다음 로드 밸런서 노드가 고장 난 노드의 키공간을 획득한다. 새 흐름 추적기 노드가 합류할 때, 노드는 자신의 종단점을 (가령, 도 1에 도시된 구성 서비스(122)에게) 등록하여, 다른 로드 밸런서 노드들이 로드 밸런서 구현에서의 따라서 일관 해시 링 내에서의 구성 변화에 대해 학습할 수 있게 한다. 일관 해시 링에서의 흐름 추적기의 추가 및 고장의 핸들링이 도 11a 내지 11d를 참조하여 더 상세히 설명된다.
입구 노드 <-> 흐름 추적기 노드 통신
적어도 일부 실시예에서, 입구 노드로서 역할 하는 로드 밸런서 노드(110)가 구성 서비스(122)로부터 흐름 추적기 노드로서 역할 하는 로드 밸런서 노드(110)에 대해 학습할 수 있다. 입구 노드가 로드 밸런서 구현에서의 따라서 일관 해시 링에서의 구성원 변경에 대해 구성 서비스(122)를 모니터링할 수 있다. 입구 노드가 자신이 맵핑을 갖지 않는 클라이언트(160)로부터 패킷을 수신할 때, 상기 입구 노드는 어느 흐름 추적기 노드가 패킷을 서비스해야 하는지를 결정하기 위해 일관 해시 함수를 이용할 수 있다. 적어도 일부 실시예에서, 해시 기능으로의 입력(클라이언트 종단점, 공중 종단점)이 패킷으로부터의 쌍이다. 적어도 일부 실시예에서, 입구 노드 및 흐름 추적기 노드가 UDP 메시지를 이용해 통신한다.
주 흐름 추적기 노드가 새 패킷 흐름에 대해 입구 노드로부터 메시지를 수신할 때, 주 흐름 추적기 노드는 TCP 시퀀스 번호를 랜덤하게 결정하고 또 다른 메시지를 보조 흐름 추적기 노드로 전달한다. 보조 흐름 추적기 노드는 클라이언트를 위한 TCP SYN/ACK를 생성한다. 두 흐름 추적기 모두 클라이언트 연결 종단점 쌍 및 TCP 시퀀스 번호를 기억하고, 메모리 압력 또는 만료에 의해 상태가 정화(purge)될 때까지 이 정보를 유지한다.
주 흐름 추적기 노드가 TCP ACK 패킷이 수신된 입구 노드로부터 메시지를 수신할 때, 주 흐름 추적기 노드는 긍정응답 받은 TCP 시퀀스 번호가 SYN/ACK 패킷으로 전송된 저장 값과 매칭됨을 검증하고, 요청을 서비스할 서버 노드(130)를 선택하며, 메시지를 보조 흐름 추적기 노드로 전달한다. 보조 흐름 추적기 노드는 메시지를 선택된 서버 노드(130) 상의 로드 밸런서 모듈(132)로 전송하여 서버 노드(130) 상의 TCP 스택과의 실제 TCP 연결을 개시할 수 있으며, 그 후 서버 노드(130)로부터 긍정응답을 기다린다.
보조 흐름 추적기 노드가 서버 노드(130) 상의 로드 밸런서 모듈(132)로부터 연결 긍정응답을 수신할 때, 연관된 서버 노드(130)에 대한 정보를 두 노드 모두에 저장하는, 주 흐름 추적기를 통한 입구 노드로의 역 메시지 흐름(reverse message flow)이 트리거된다. 여기서부터 앞으로, 입구 노드에 수신된 추가 TCP 패킷이 서버 노드(130) 상의 로드 밸런서 모듈(132)로 직접 전달된다.
로드 밸런서 모듈 <-> 로드 밸런서 노드 통신
적어도 일부 실시예에서, 모든 로드 밸런서 모듈(132)이 자신의 종단점을 구성 서비스(122)에 등록하고, 로드 밸런서 노드 레이어에서의 구성원 변경에 대해 구성 서비스(122)를 계속 모니터링한다. 이하에서 적어도 일부 실시예에 따라 로드 밸런서 모듈(132)의 기능을 기재한다:
Figure pat00004
연결 게시 - 주기적으로(가령, 1초에 1회) 또는 비주기적으로 각각의 서버 노드(130) 상의 활성 연결의 세트(클라이언트 종단점, 공중 종단점)를 이들 연결에 대해 책임이 있는 주 흐름 추적기 노드와 보조 흐름 추적기 노드 모두에게뿐 아니라 이들 연결에 대해 로드 밸런서 모듈(132)로 마지막으로 패킷을 전송한 입구 노드에게도 게시한다. 연결 게시 기능은 책임 있는 로드 밸런서 노드(110)에서의 연결 상태에 대한 리스를 갱신한다.
Figure pat00005
로드 밸런서 레이어에서의 구성원 변경 모니터링. 구성원이 변경된 경우, 로드 밸런서 모듈(132)은 이 변경 정보를 이용해 활성 연결을 현재 연결에 대해 책임이 있는 로드 밸런서 노드로 즉시 전송할 수 있다.
분산 로드 밸런싱 시스템에서의 패킷 흐름 - 상세사항
분산 로드 밸런싱 시스템은 복수의 로드 밸런서 노드(110)를 포함할 수 있다. 적어도 일부 실시예에서, 분산 로드 밸런싱 시스템에서의 각각의 로드 밸런서 노드(110)는 클라이언트(160)에서 서버(134)로의 연결에 대한 흐름 추적기 노드, 출구 노드, 및 입구 노드의 역할을 수행할 수 있다. 분산 로드 밸런싱 시스템은 또한 각각의 서버 노드(130) 상에 로드 밸런서 모듈(132)을 더 포함할 수 있다.
도 10a 내지 10g는 적어도 일부 실시예에 따르는 분산 로드 밸런싱 시스템에서의 패킷 흐름을 도시한다. 도 10a 내지 10g에서, 로드 밸런서 노드(110)들 간에 교환되는 패킷 및 로드 밸런서 노드(110)와 서버 노드(130) 간에 교환되는 패킷이 UDP 메시지 또는 UDP-캡슐화된 클라이언트 TCP 패킷이다. 적어도 일부 실시예에서, 네트워크(100) 상에서 클라이언트 TCP 패킷은 경계 라우터(102)로 그리고 경계 라우터로부터의 수송 중에 로드 밸런서 노드(110)의 노스 측(north side) 상에서 역캡슐화된 형태(decapsulated form)로만 존재한다(도 1 참조). 도 10a-10g에서 화살표 있는 실선은 TCP 패킷을 나타내며, 반면에 화살표 있는 점선은 UDP 패킷을 나타낸다.
적어도 일부 실시예에서, 분산 로드 밸런싱 시스템은 단일 로드 밸런서 노드(110) 고장의 경우, 확립된 연결을 보존하려 시도할 수 있다. 적어도 일부 실시예에서, 이는 주 흐름 추적기 노드 및 보조 흐름 추적기 노드에서 연결 상세사항을 복제하여, 이들 노드 중 어느 하나가 고장인 경우, 나머지 흐름 추적기 노드에 의해 연결의 클라이언트 -> 서버 맵핑이 복원될 수 있도록 함으로써 이뤄질 수 있다. 적어도 일부 실시예에서, 노드 고장의 경우 일부 패킷 손실이 발생할 수 있지만, 클라이언트/서버 TCP 패킷 재송신이 손실된 패킷을 복원할 수 있다.
클라이언트로부터의 각각의 TCP 연결이 TCP 흐름이라고 지칭될 수 있으며, 4-튜플, 즉, 클라이언트 IP 주소, 클라이언트 포트, 서버(공중) IP 주소, 및 서버 포트에 의해 고유하게 식별된다. 이 식별자는 클라이언트 및 공중 종단점 쌍을 가리키는 CP 또는 CcPp로 약칭될 수 있다. 임의의 특정 TCP 흐름(또는 CP 쌍)과 연관된 패킷이 업스트림 에지 라우터(104)로부터의 해싱된 등가 다중경로(ECMP) 흐름 분포로 인해 입구 서버(112)로서 동작하는 임의의 로드 밸런서 노드(110) 상에서 나타날 수 있다. 그러나 일반적으로 TCP 흐름을 재지향시키는 링크 또는 로드 밸런서 노드(110) 고장이 없는 한 TCP 흐름에 대한 패킷이 동일한 로드 밸런서 노드(110)에 계속 도착할 수 있다. 업스트림 라우터(104)로부터 TCP 흐름에 대한 패킷을 수신하는 로드 밸런서 노드(110)가 TCP 흐름에 대한 입구 노드로서 지칭된다.
적어도 일부 실시예에서, 일관 해싱이 사용되어, 패킷이 TCP 흐름에 대한 입구 노드로서 역할 하는 로드 밸런서 노드(110)에 도착할 때, 상기 입구 노드는 어느 로드 밸런서 노드(110)가 TCP 흐름에 대한 상태를 가지는지(즉, 흐름 추적기 노드인지)를 결정할 수 있다. CP 쌍은 입구 노드에 의해 일관 해시 링으로 해싱되어 어느 로드 밸런서 노드(110)가 TCP 흐름에 대한 상태를 유지관리할 책임이 있는지를 결정할 수 있다. 이 노드는 TCP 흐름에 대한 주 흐름 추적기로서 역할 한다. 일관 해시 링 내 후속자 노드가 TCP 흐름에 대한 보조 흐름 추적기로서 역할 한다.
적어도 일부 실시예에서, 모든 로드 밸런서 노드(110)가 입구 노드, 주 흐름 추적기 노드, 및 보조 흐름 추적기 노드로서 역할 할 수 있다. TCP 흐름에 대한 일관 해시 결과에 따라서, TCP 흐름에 대한 입구 노드로서 역할 하는 로드 밸런서 노드(110)가 또한 TCP 흐름에 대한 주 흐름 추적기 노드 및 보조 흐름 추적기 노드로서 역할 할 수 있다. 그러나 적어도 일부 실시예에서, 서로 다른 물리적 로드 밸런서 노드(110)가 TCP 흐름에 대한 주 흐름 추적기 역할 및 보조 흐름 추적기 역할을 수행한다.
연결 확립
도 10a를 참조하면, 클라이언트(160)로부터의 새 연결이 클라이언트 TCP 동기화(SYN) 패킷에 의해 트리거될 수 있다. 로드 밸런서 노드(110)는 SYN 패킷을 수신할 때 서버 노드(130)와의 연결을 실제로 확립하지 않고, 연결을 수신하기 위한 서버 노드(130)를 즉시 선택하지도 않는다. 대신, 로드 밸런서 노드(110)는 클라이언트의 SYN 패킷으로부터의 관련 데이터를 저장하고 미선택된 서버 노드(130)를 대신하여 SYN/ACK 패킷을 생성한다. 도 10c를 참조하여, 클라이언트(160)가 TCP 3단계 핸드쉐이크(TCP three-way handshake)에서 첫 ACK 패킷으로 응답하면, 로드 밸런서 노드(110)가 서버 노드(130)를 선택하고, 상기 서버 노드(130)에 대해 등가 SYN 패킷을 생성하며 서버 노드(130)와의 실제 TCP 연결을 확립하여 시도한다.
도 10a를 다시 참조하면, TCP 흐름에 대해 입구 서버(112)로서 역할 하는 로드 밸런서 노드(110)에서 클라이언트 SYN 패킷이 수신되면, 입구 서버(112)는 SYN 패킷으로부터 데이터 필드를 추출하고 데이터를 TCP 흐름에 대한 주 흐름 추적기(116A)로 전달한다. 주 흐름 추적기(116A)가 데이터를, 가령, 해시 테이블에 저장하고, (TCP 연결의 서버 측에 대한) 초기 TCP 시퀀스 번호를 생성하며, 동일한 데이터를 보조 흐름 추적기(116B)로 전달한다. 보조 흐름 추적기(116B)가 클라이언트(160)에 대한 상기 서버 TCP 시퀀스 번호를 포함하는 SYN/ACK 패킷을 제작한다.
도 10a에서, 입구 서버(112), 주 흐름 추적기(116A), 및 보조 흐름 추적기(116B) 역할이 각각 서로 다른 로드 밸런서 노드(110)에 의해 수행된다. 그러나 일부 경우, TCP 흐름에 대해 입구 서버(112)로서 역할 하는 로드 밸런서 노드(110)가 TCP 흐름에 대해 주 흐름 추적기(116A) 또는 보조 흐름 추적기(116B)로서 역할 하는(그러나 둘 모두의 역할은 하지 않는) 하나의 동일 노드(110)일 수 있다. 패킷 흐름에 대한 입구 서버(112)가 흐름에 대한 흐름 추적기(116)로서 동일한 노드(110) 상에 있을 수 있는 이유가, 에지 라우터(104)가 흐름당 해싱된 다중경로 라우팅 기법(가령, ECMP 라우팅 기법)에 따라 흐름에 대한 입구 서버(112)를 의사랜덤하게 선택하는데, 반면에 패킷 흐름에 대한 흐름 추적기(116)는 패킷 흐름의 주소 정보에 적용되는 일관 해시 함수에 따라 일관 해시 링 상에서 결정되기 때문이다. 패킷 흐름에 대한 입구 서버(112)가 패킷 흐름에 대한 흐름 추적기(116)와 동일한 노드(110) 상에 있는 경우, SYN 패킷으로부터의 데이터가 입구 서버(112)를 구현하는 노드(110)로부터 다른 흐름 추적기(116) 노드(110)로만 전달될 수 있다. 예를 들어, 도 10b에서, 주 흐름 추적기(116A)는 TCP 흐름에 대한 입구 서버(112)와 동일한 로드 밸런서 노드(110A) 상에 있는데, 보조 흐름 추적기(116B)는 서로 다른 로드 밸런서 노드(110B) 상에 위치하며, 따라서 SYN 패킷으로부터의 데이터가 노드(110A)로부터 (흐름 추적기(116A)에 의해) 로드 밸런서 노드(110B) 상의 보조 흐름 추적기(116B)로 전달된다.
도 10c를 참조하면, 비-SYN 패킷이 입구 서버(112)에 도달할 때, 상기 입구 서버(112)는 패킷을 전달할 서버 노드(130)를 알거나 알지 못한다. TCP 흐름에 대해 입구 서버(112)에 도달하는 첫 번째 비-SYN 패킷이 TCP 3단계 핸드쉐이크에서 첫 번째 TCP 긍정응답(ACK) 패킷(또는 아마도 다음 데이터 패킷)이어야하며, 여기서 TCP 긍정응답 번호 필드가 도 10a에서 SYN/ACK 패킷으로 전송된 서버 시퀀스 번호(+1)와 매칭된다. 입구 서버(112)가 자신이 서버 맵핑을 갖지 않는 비-SYN 패킷을 수신할 때, TCP 흐름에 대한 주 흐름 추적기(116A)로 메시지를 전달하는데, 상기 메시지는 ACK 패킷으로부터의 정보, 가령, 시퀀스 번호를 포함하거나 ACK 패킷 자체를 담는다. 적어도 일부 경우, 주 흐름 추적기(116A)는 TCP 흐름에 대해 저장된 데이터를 기억하고 긍정응답 받은 시퀀스 번호(+1)가 SYN/ACK 패킷 내에서 클라이언트(160)로 전송됐던 값과 매칭됨을 확인한다. 그 후 주 흐름 추적기는 TCP 흐름에 대해 서버 노드(130)를 선택하고 TCP 흐름에 대한 이전에 저장된 데이터, 서버 시퀀스 번호, 및 선택된 서버 노드(130) 상의 로드 밸런서 모듈(132)에 대한 IP 주소를 포함하는 또 다른 메시지를 보조 흐름 추적기(116B)로 전달한다. 보조 흐름 추적기(116B)는 서버 시퀀스 번호를 확인하고, 정보를 기록하며, 제작된 SYN 메시지를 선택된 서버 노드(130) 상의 로드 밸런서 모듈(132)로 전송한다. 이제 TCP 흐름의 CP 종단점 쌍이 로드 밸런서 모듈(132)/서버 노드(130)로 맵핑된다. 서버 노드(130) 상의 로드 밸런서 모듈(132)이 보조 흐름 추적기(116B)로부터 제작된 SYN 메시지를 수신할 때 서버 노드(130) 상의 서버(134)에 대한 정당한 TCP SYN 패킷을 생성하는 책임을 가진다. SYN 패킷을 생성할 때, 출발지 IP 주소가 클라이언트(160)의 실제 IP 주소로 채워져서, 서버(134)는 자신이 클라이언트(160)로부터의 직접 TCP 연결 요청을 수신했다고 믿게 될 것이다. 로드 밸런서 모듈(132)은 TCP 흐름에 대한 관련 상세사항을 로컬 해시 테이블에 저장하고 TCP SYN 패킷을 서버(134)로 전송한다(가령, SYN 패킷을 서버(134)의 리눅스(Linux) 커넬로 주입한다).
도 10c에서, 입구 서버(112), 주 흐름 추적기(116A), 및 보조 흐름 추적기(116B) 역할 각각이 서로 다른 로드 밸런서 노드(110)에 의해 수행된다. 그러나 일부 경우, TCP 흐름에 대한 입구 서버(112)로서 역할 하는 로드 밸런서 노드(110)는 TCP 흐름에 대해 주 흐름 추적기(116A) 또는 보조 흐름 추적기(116B)로서 역할 하는(그러나 두 가지 역할 모두를 수행하지는 않음) 하나의 동일한 노드(110)일 것이다. 예를 들어, 도 10d에서, 보조 흐름 추적기(116B)가 TCP 흐름에 대한 입구 서버(112)와 동일한 로드 밸런서 노드(110A) 상에 있지만, 주 흐름 추적기(116A)는 상이한 로드 밸런서 노드(110B) 상에 있다.
도 10e를 참조하면, 서버(134)(가령, 리눅스(Linux) 커넬)가 로드 밸런서 모듈(132)이 또한 인터셉트하는 SYN/ACK 패킷으로 응답한다. SYN/ACK 패킷은 보조 흐름 추적기(116B)로부터 클라이언트(160)에게 생성된 SYN/ACK로 본래 전달됐던 것(도 10a 참조)과 상이한 TCP 시퀀스 번호를 포함할 수 있다. 로드 밸런서 모듈(132)이 시퀀스 번호 델타(delta)를 인커밍 및 아웃고잉 패킷으로 적용하는 데 책임이 있다. 서버(134)로부터의 SYN/ACK 패킷이 또한 로드 밸런서 모듈(132)로부터의 메시지(가령, UDP 메시지)를 다시 보조 흐름 추적기(116B)로 트리거하여, 선택된 서버 노드(130)/로드 밸런서 모듈(132)/서버(134)로의 연결이 성공적임을 나타낸다. 이 메세지의 수신 후, 보조 흐름 추적기(116A)가 클라이언트(160)와 서버(134) 간 클라이언트 및 공중 종단점 쌍(CP) 맵핑을 커밋(commit)된 것으로 기록할 수 있고, 유사한 메시지를 또한 CP 맵핑을 기록할 주 흐름 추적기(116A)로 전송한다. 그 후 주 흐름 추적기(116A)가 CP 맵핑 메시지를 입구 서버(112)로 전달할 수 있으며, 이로써, 입구 서버(112)는 연결에 대한 임의의 버퍼링된 데이터 패킷을 캡슐화된 데이터 패킷으로서 서버 노드(130) 상의 로컬 로드 밸런서 모듈(132)로 전달할 수 있다.
도 10f를 참조하면, 연결에 대한 CP 맵핑이 입구 서버에게 알려짐으로써, 연결에 대한 입구 서버(112)에 의해 수신된 인커밍 TCP 패킷이 (가령, UDP에 따라) 캡슐화될 수 있고, 캡슐화된 데이터 패킷으로서 서버 노드(130) 상의 로컬 로드 밸런서 모듈(132)로 직접 전달될 수 있다. 로드 밸런서 모듈(132)은 데이터 패킷을 역캡슐화하고, 가령, TCP 패킷을 커넬의 TCP 스택으로 주입함으로써, 서버 노드(130) 상의 서버(134)로 TCP 패킷을 전송한다. 서버(134)로부터의 아웃바운드 패킷이 서버 노드(130) 상의 로드 밸런서 모듈(132)에 의해 인터셉트되고, (가령, UDP에 따라) 캡슐화되고, 이 연결에 대해 로드 밸런서 모듈(132)이 출구 서버(114)로서 랜덤하게 선택한 임의의 로드 밸런서 노드(110)로 전달된다. 출구 서버(114)는 패킷을 역캡슐화하고 역캡슐화된 패킷을 클라이언트(116)로 전송한다. 선택된 로드 밸런서 노드(110)의 출구 기능이 무상태여서, 출구 서버로서 역할 하는 로드 밸런서 노드(110)의 고장의 경우, 상이한 로드 밸런서 노드(110)가 연결에 대한 출구 서버(114)로서 선택될 수 있다. 그러나 일반적으로 동일한 로드 밸런서 노드(110)가 연결 지속 시간 동안 출구 서버(114)로서 사용되어, 아웃바운드 패킷의 재정렬을 감소 또는 제거할 수 있다.
도 10g를 참조하여, 적어도 일부 실시예에서, 주 흐름 추적기(116A)(도 10c 참조)에 의해 선택된 서버 노드(130A) 상의 로드 밸런서 모듈(132A)이 과부하됐다고 결정한 경우, 보조 흐름 추적기(116B)로부터 수신된 제작된 SYN 메시지를 거절하는 옵션을 가진다(도 10c 참조). 적어도 일부 실시예에서, 제작된 SYN 메시지가 최대 횟수의 거절을 허용하는 수명시간(TTL) 값 또는 카운터를 포함한다. 적어도 일부 실시예에서, 이 TTL 값이 영(0)에 도달하는 경우, 로드 밸런서 모듈(132A)이 연결을 수락하거나 연결을 차단하여 로드를 분배할 수 있다. 로드 밸런서 모듈(132A)이 연결을 거절하려 결정한 경우, TTL 값을 결정하고 거절 메시지를 보조 흐름 추적기(116B)로 전송한다. 보조 흐름 추적기(116B)는 CP 맵핑을 재설정하며 주 흐름 추적기(116A)로 해제 메시지를 전송하여 이를 하게 한다. 주 흐름 추적기(116A)는 또 다른 서버 노드(130B) 상의 새 로드 밸런서 모듈(132B)을 선택하고 새 타깃 메시지를 다시 보조 흐름 추적기(116B)로 전송하며, 상기 보조 흐름 추적기가 새로 제작된 SYN 메시지를 새로 선택된 로드 밸런서 모듈(132B)로 전송한다. 패킷 폐기(packet drop)에 의해 이 시퀀스가 완성되지 못하지만, 클라이언트(160)로부터의 재전송이 주 흐름 추적기(116A)에서 로드 밸런서 모듈 선택 프로세스를 다시 트리거할 수 있으며, 주 흐름 추적기는, 반드시 그런 것은 아니지만, 제작된 SYN 패킷의 이전 거절에 대해 학습하지 않은 경우 연결에 대한 동일한 로드 밸런서 모듈(132)을 선택할 수 있다.
적어도 일부 실시예에서, TTL 카운터는 예를 들어, 모든 서버 노드(130)가 바쁠 때 발생할 수 있는, 서버 노드(130)로 연결 요청을 지속적으로 전송하는 것을 막기 위해 사용될 수 있다. 적어도 일부 실시예에서, 로드 밸런서 모듈(132)이 각각의 서버 노드(130)를 대신하여 연결 요청을 거절할 때마다, 로드 밸런서 모듈(132)이 TTL 카운터를 감분시킨다. 흐름 추적기 노드(116)는 TTL 카운터를 모니터링할 수 있으며, TTL 카운터가 0이 아닌 한(또는 일부 특정 임계값 이상인 한), 또 다른 서버 노드(130)를 선택하고 다시 시도할 수 있다. TTL 카운터가 0에 도달하는 경우(특정된 임계값에 도달하는 경우), 연결 요청이 폐기되고, 상기 연결에 대한 연결 요청을 서버 노드(130)들 중 선택된 서버 노드로 전송하기 위한 흐름 추적기 노드(116)에 의한 어떠한 추가 시도도 이뤄지지 않는다. 적어도 일부 실시예에서, 에러 메시지가 각자의 클라이언트(160)로 전송될 수 있다.
적어도 일부 실시예에서, 분산 로드 밸런서 시스템이 복수의 공중 IP 주소를 지원한다. 따라서 클라이언트(160)는 동일한 클라이언트 포트 번호에서 2개의 서로 다른 공중 IP 주소로의 2개의 TCP 연결을 개시할 수 있는 것이 가능하다. 이들 TCP 연결은 클라이언트(160)의 관점과 구별되지만, 내부적으로 분산 로드 밸런서는 연결을 동일한 서버 노드(130)로 맵핑할 수 있고, 이는 충돌을 초래할 것이다. 적어도 일부 실시예에서, 가능한 충돌을 검출 및 핸들링하기 위해, 로드 밸런서 모듈(132)은, 도 10c 및 10d에 도시된 바와 같이, 보조 흐름 추적기(116B)로부터 제작된 SYN 패킷을 수신할 때, 주소 정보를 자신의 활성 연결과 비교할 수 있으며, 이 연결이 충돌을 야기할 경우, 도 10g에 도시된 바와 같이 연결 요청을 거절할 수 있다.
로드 밸런서 노드 고장 및 추가 핸들링
여러 종래의 로드 밸런서에서, 로드 밸런서 고장의 경우 일부 또는 모든 기존 연결이 손실된다. 적어도 일부 실시예에서, 단일 로드 밸런서 노드(110)의 고장의 경우, 분산 로드 밸런싱 시스템이 확립된 연결 중 적어도 일부를 유지하여, 연결이 정상적으로 완료될 때까지 클라이언트 및 서버가 연결을 통해 패킷을 계속 교환할 수 있다. 덧붙여, 분산 로드 밸런싱 시스템은 고장 시에 확립되는 과정 중인 연결을 계속 서비스할 수 있다.
분산 로드 밸런싱 시스템의 적어도 일부 실시예에서, 단일 로드 밸런서 노드(110) 고장의 경우 기존 클라이언트 연결을 복원할 수 있는 고장 복원 프로토콜이 구현될 수 있다. 그러나 복수의 로드 밸런서 노드(110) 고장은 소실된 클라이언트 연결을 도출할 수 있다. 적어도 일부 실시예에서, 클라이언트(160)와 서버(134) 간 TCP 재전송이 로드 밸런서 노드(110) 고장 후 복원의 수단으로서 사용될 수 있다.
잠재적인 로드 밸런서 노드(110) 고장에 추가로, 새로운 로드 밸런서 노드(110)가 분산 로드 밸런서 시스템에 추가될 수 있다. 이들 새로운 노드(110)는 로드 밸런서 레이어에 추가될 수 있고 따라서 일관 해시 링에 추가될 수 있으며, 기존 클라이언트 연결과 관련된 로드 밸런서 노드(110) 역할이 변경에 따라 필요한 대로 조절될 수 있다.
흐름 추적기 노드 고장 및 추가의 핸들링
적어도 일부 실시예에서, 각각의 연결이 확립됨에 따라(가령, 도 10a 내지 10g 참조), 연결 상태 정보가, 가령, (클라이언트 IP:포트, 공중 IP:포트) 튜플을 해시 함수 입력으로서 이용하는 일관 해시 알고리즘을 이용해 결정될 수 있는 주 흐름 추적기 및 보조 흐름 추적기라고 지칭되는 2개의 로드 밸런서 노드(110)를 통과된다. 단일 로드 밸런서 노드(110) 고장의 경우, 생존 로드 밸런서 노드(110)들 중 적어도 하나가 일관 해시 함수를 통해 계속 맵핑될 수 있고, 연결에 대해 필수 상태 정보를 유지하여, 패킷을 연결에 대해 선택된 서버 노드(130)로 지향시킬 수 있다. 덧붙여, 로드 밸런서 노드(110)가 일관 해시 링에 추가되는 경우, 연결에 대한 상태 정보가 적절한 흐름 추적기로 리프레시될 수 있다.
도 11a 내지 11d는 적어도 일부 실시예에 따라 로드 밸런서 노드 일관 해시 링의 구성원에 영향을 미치는 이벤트의 핸들링을 도시한다. 이들 이벤트의 비제한적 예를 들면, 새(new) 주 흐름 추적기 노드의 추가, 새 보조 흐름 추적기 노드의 추가, 주 흐름 추적기 노드의 고장, 및 보조 흐름 추적기 노드의 고장이 있을 수 있다.
도 11a는 새 주 흐름 추적기 노드의 일관 해시 링으로의 추가를 핸들링하는 것을 도시한다. 도 11a의 상단 열이 하나 이상의 클라이언트 연결에 대한 주 흐름 추적기로서의 흐름 추적기(116A) 및 동일한 연결(들)에 대한 보조 흐름 추적기로서의 흐름 추적기 노드(116B)를 도시한다. 도 11a의 하단 열에서, 새 흐름 추적기 노드(116C)가 추가됐고 클라이언트 연결(들)에 대한 주 흐름 추적기가 된다. 이전에 주 흐름 추적기였던 흐름 추적기 노드(116A)가 보조 흐름 추적기가 되고, 이전에 보조 흐름 추적기였던 흐름 추적기 노드(116B)는 일관 해시 링 내 다음 흐름 추적기가 된다. 흐름 추적기(116A 및 116B)에 의해 유지됐던 클라이언트 연결(들)에 대한 상태 정보가 새 주 흐름 추적기(116C)로 제공될 수 있다. 덧붙여, 흐름 추적기(116B)가 보조 흐름 추적기의 역할에서 자신이 이전에 추적한 연결을 "잊을(forget)" 수 있다.
도 11b는 새 보조 흐름 추적기 노드의 일관 해시 링으로의 추가를 핸들링하는 것을 도시한다. 도 11b의 상단 열이 하나 이상의 클라이언트 연결에 대한 주 흐름 추적기로서의 흐름 추적기(116A) 및 동일한 연결(들)에 대한 보조 흐름 추적기로서 흐름 추적기 노드(116B)를 도시한다. 도 11b의 하단 열에서, 새 흐름 추적기 노드(116C)가 추가됐고, 클라이언트 연결(들)에 대한 보조 흐름 추적기가 된다. 흐름 추적기 노드(116A)는 연결(들)에 대한 주 흐름 추적기로서 유지되며, 반면에 이전에 보조 흐름 추적기였던 흐름 추적기 노드(116B)는 일관 해시 링 내 다음 흐름 추적기가 된다. 흐름 추적기(116A 및 116B)에 의해 유지된 클라이언트 연결(들)에 대한 상태 정보가 새 보조 흐름 추적기(116C)로 제공될 수 있다. 덧붙여, 흐름 추적기(116B)는 보조 흐름 추적기의 역할에서 자신이 이전에 추적한 연결을 "잊을" 수 있다.
도 11c는 일관 해시 링에서의 주 흐름 추적기 노드의 고장의 핸들링을 도시한다. 도 11c의 상단 열은 하나 이상의 클라이언트 연결에 대한 주 흐름 추적기로서의 흐름 추적기(116A), 동일한 연결(들)에 대한 보조 흐름 추적기로서의 흐름 추적기 노드(116B), 및 일관 해시 링에서의 다음 흐름 추적기로서의 흐름 추적기 노드(116C)를 도시한다. 도 11c의 하단 열에서, 주 흐름 추적기 노드(116A)가 고장 났다. 흐름 추적기 노드(116B)는 연결(들)에 대한 주 흐름 추적기가 되고, 반면에 흐름 추적기 노드(116C)는 연결(들)에 대한 보조 흐름 추적기가 된다. 클라이언트 연결(들)에 대한 상태 정보가 흐름 추적기(116B)에 의해 유지관리되고 새 보조 흐름 추적기(116C)로 제공될 수 있다.
도 11D는 일관 해시 링에서의 보조 흐름 추적기 노드의 고장의 핸들링을 도시한다. 도 11d의 상단 열은 하나 이상의 클라이언트 연결에 대한 주 흐름 추적기로서 흐름 추적기(116A), 동일한 연결(들)에 대한 보조 흐름 추적기로서의 흐름 추적기 노드(116B), 및 일관 해시 링에서의 다음 흐름 추적기로서의 흐름 추적기 노드(116C)를 도시한다. 도 11d의 하단 열에서, 보조 흐름 추적기 노드(116B)가 고장 났다. 흐름 추적기 노드(116A)는 연결(들)에 대한 주 흐름 추적기로서 유지되지만, 흐름 추적기 노드(116C)는 연결(들)에 대한 보조 흐름 추적기가 된다. 클라이언트 연결(들)에 대한 상태 정보가 흐름 추적기(116B)에 의해 유지관리되며, 새 보조 흐름 추적기(116C)로 제공될 수 있다.
적어도 일부 실시예에서, 서버 노드(130) 상의 로드 밸런서 모듈(132)이 로드 밸런서 노드(110)로의 연결 게시를 수행한다. 적어도 일부 실시예에서, 연결 게시는 주기적으로(가령, 1초에 1회) 또는 비주기적으로 현재 연결 상태 정보를 서버 노드(130)로부터, 연결에 대해 주 흐름 추적기 노드와 보조 흐름 추적기 노드 모두로의 연결 맵핑을 리프레시 또는 복원하도록 역할 하는 흐름 추적기 노드 및 입구 노드로서 역할 하는 로드 밸런서 노드(110)로 푸시(push)한다. 적어도 일부 실시예에서, 로드 밸런서 모듈(132)은 예를 들어 도 11a 내지 11d에서 도시된 바와 같이 흐름 추적기 구성원 변경을 검출할 수 있다. 이에 응답하여, 로드 밸런서 모듈(132)은 연결 게시를 수행하여, 구성원이 변경될 때 연결에 대해 변경될 수 있는 연결에 대한 상태 정보를 주 흐름 추적기 노드 및 보조 흐름 추적기 노드에 채울 수 있다. 연결 게시는 복수의 로드 밸런서 노드 고장의 경우 적어도 일부 확립된 연결이 복원되게 할 수 있다.
고장-관련 메시지 흐름
적어도 일부 실시예에서, 주 흐름 추적기 노드와 보조 흐름 추적기 노드 간 프로토콜이 교정(correction) 또는 동기화 기능을 포함할 수 있다. 예를 들어, 도 11a를 참조하면, 새 주 흐름 추적기 노드(116C)가 일관 해시 링에 합류할 때, 새 노드(116C)가 복수의 연결(~ 1/N)에 대해 일관 해시 키공간의 소유권을 주장할 수 있으며 에지 라우터(104)로부터의 이들 연결과 관련된 트래픽을 수신하기 시작할 수 있다. 그러나 새 주 흐름 추적기 노드(116C)는 연결에 대해 저장된 어떠한 상태도 갖지 않으며, 따라서 클라이언트(160)로부터 수신된 첫 번째 패킷인 것처럼 각각의 패킷을 다룰 수 있다. 주 흐름 추적기는 SYN 패킷에 응답하여 서버 TCP 시퀀스 번호를 생성하고(가령, 도 10a 참조) 클라이언트(160)로부터의 첫 번째 ACK 패킷에 응답하여 서버 노드(130)를 선택할(가령 도 1 참조) 책임을 가지며, 이들 생성된 값은 이전 주 흐름 추적기(도 11a의 흐름 추적기 노드(116A)에 의해 선택된 값과 불일치할 수 있다. 그러나 적어도 일부 실시예에서, 일관 해시 알고리즘은 이전 주 흐름 추적기(도 11A에서 흐름 추적기 노드(116A))를 보조 흐름 추적기 역할로 할당하고, 이 흐름 추적기는 연결에 대해 앞서 저장된 상태를 여전히 유지한다. 따라서 적어도 일부 실시예에서, 보조 흐름 추적기(도 11a의 흐름 추적기 노드(116A))가 주 흐름 추적기(116C)로부터 수신된 정보에서의 차이를 검출할 때, 업데이트 메시지를 다시 주 흐름 추적기(116C)로 전송하여 연결에 대한 흐름 추적기로서 역할 하는 2개의 로드 밸런서 노드(110)가 동기화되게 할 수 있다. 일관 해시 링 구성원에서 그 밖의 다른 변경 이후 흐름 추적기들을 동기화하기 위한 유사한 방법이 사용될 수 있다.
로드 밸런서 모듈 상세사항
적어도 일부 실시예에서, 로드 밸런서 모듈(132)은 서버 노드(130) 각각 상에 위치하는 분산 로드 밸런서 시스템의 구성요소이다. 로드 밸런서 노드(132)의 역할의 비제한적 예를 들면, 로드 밸런서 노드(110)로부터 수신된 패킷의 역캡슐화 및 역캡슐화된 패킷의 서버 노드(130) 상의 서버(134)로의 전송, 및 서버(134)로부터의 아웃고잉 패킷의 캡슐화 및 캡슐화된 패킷의 로드 밸런서 노드(110)로의 전송이 있다.
적어도 일부 실시예에서, 입구 서버(112)로서 역할 하는 로드 밸런서 노드(110)로부터 서버 노드(130) 상의 로드 밸런서 모듈(132)로의 인커밍 패킷은 실제 클라이언트 데이터 패킷을 캡슐화하는 무상태 프로토콜(가령, UDP) 패킷이다. 각각의 캡슐화된 클라이언트 데이터 패킷은 출발지 주소로서 각자의 클라이언트(160)의 본래의 클라이언트IP:포트(클라이언트IP:포트(clientIP:port))를 갖고 도착지 주소로서 서버(134)의 공중IP:포트(공중IP:포트(publicIP:port))를 가진다. 로드 밸런서 모듈(132)은 클라이언트 데이터 패킷으로부터 캡슐을 제거하고, 예를 들어 패킷을 로컬호스트 TCP 흐름으로 재지향시킴으로써 패킷을 서버 노드(130) 상의 각각의 서버(134)로 전송한다.
적어도 일부 실시예에서, 서버(134)에서 출구 서버(114)로서 역할 하는 로드 밸런서 노드(110)로의 아웃고잉 패킷이 아웃고잉 IP 패킷을 캡슐화하는 무상태 프로토콜(가령, UDP) 패킷이다. 상기 로드 밸런서 모듈(132)은 아웃고잉 IP 패킷을 캡슐화하고 캡슐화된 패킷을 패브릭(120)을 통해 출구 서버(114)로 전송한다. 각각의 캡슐화된 아웃고잉 IP 패킷은 출발지 주소로서 서버(134)의 공중IP:포트(publicIP:port)를 갖고 도착지 주소로서 각자의 클라이언트(160)의 클라이언트IP:포트(clientIP:port)를 가진다.
로드 밸런서 모듈 기능
적어도 일부 실시예에서, 서버 노드(130) 상의 로드 밸런서 모듈(132)의 기능은 다음의 비제한적 예시 중 하나 이상을 포함할 수 있다:
Figure pat00006
로드 밸런서 노드(들)(110), 가령, 연결을 핸들링하는 입구 서버(112)로부터 클라이언트(160)로의 UDP 터널의 종료. 이는 입구 서버(112)로부터 수신된 인커밍 클라이언트 데이터 패킷으로부터의 UDP 캡슐의 제거를 포함한다.
Figure pat00007
연결에 대한 아웃고잉 트래픽을 수신할 출구 서버(114)의 선택.
Figure pat00008
각각의 서버(134) 로의 연결 상의 아웃고잉 IP 패킷의 인터셉트, 연결에 대한 아웃고잉 IP 패킷의 캡슐화, 및 출구 서버(114)로의 캡슐화된 패킷의 전송.
Figure pat00009
흐름 추적기 노드(116)가 SYN/ACK를 클라이언트(160)로 전송할 때 시퀀스 번호가 흐름 추적기 노드(116)에 의해 생성된 시퀀스 번호와 정렬되도록 인커밍 및 아웃고잉 패킷에서의 시퀀스 번호의 맹글링(mangling).
Figure pat00010
예를 들어, 각각의 서버(134)의 현재 부하(load)를 가리키는 하나 이상의 메트릭을 기초로 각자의 서버(134)에 대한 연결을 수용할지 또는 거절할지에 대해 결정.
Figure pat00011
클라이언트IP:포트(clientIP:port) 주소에 대한 활성 연결이 있는 경우, 충돌을 피하기 위해 상기 동일한 클라이언트IP:포트(clientIP:port) 주소로부터 각자의 서버(134)로의 연결을 검출 및 거절.
Figure pat00012
연결 추적 및 연결 게시.
로드 밸런서 모듈 구성 정보
적어도 일부 실시예에서, 각각의 로드 밸런서 모듈(132)은, 자신의 구성을 위해 다음에서 비제한적으로 나열된 정보 세트 중 하나 이상을 획득하고 로컬하게 저장할 수 있다: 로드 밸런서 노드(110)의 종단점의 세트, 서비스할 유효 공중 IP 주소의 세트, 및 각각의 서버(134)가 인커밍 연결을 수락하는 포트 번호(들). 적어도 일부 실시예에서, 도 1에 도시된 바와 같이, 이 정보는 분산 로드 밸런서 시스템의 구성 서비스(122) 구성요소로 액세스 또는 질의함으로써 획득되거나 업데이트될 수 있다. 정보를 획득하는 그 밖의 다른 방법이 일부 실시예에서 사용될 수 있다.
로드 밸런서 모듈 패킷 핸들링
이하에서, 적어도 일부 실시예에 따라, 인바운드 트래픽 및 아웃바운드 트래픽을 위한 로드 밸런서 모듈(132) 동작이 기재된다. 적어도 일부 실시예에서, 인바운드 데이터 패킷이 로드 밸런서 모듈(132)에 의해 수신될 때, 상기 데이터 패킷이 UDP 패킷으로부터 역캡슐화되고, 역캡슐화된 TCP 패킷에서의 도착지 주소가 구성된 유효 공중 IP 주소의 세트에 대해 먼저 검증된다. 매칭이 없다면, 패킷은 폐기 또는 무시된다. 적어도 일부 실시예에서, 시퀀스 번호가 클라이언트(160)에게 SYN/ACK 패킷을 전송한 흐름 추적기 노드(116)에 의해 생성된 랜덤 선택 시퀀스 번호에 매칭될 수 있도록, 로드 밸런서 모듈(132)은 일정한 델타에 의해 TCP 헤더에서의 시퀀스 번호를 조절할 수 있다. 로드 밸런서 모듈(132)은 내부 상태로서 [클라이언트:공중] 종단점에서 [클라이언트:서버] 종단점으로의 맵핑을 기록한다.
적어도 일부 실시예에서, 서버(134)로부터의 아웃바운드 TCP 패킷에 대해, 로드 밸런서 모듈(132)은 자신의 내부 상태를 우선 체크하여, 패킷이 로드 밸런서 모듈이 관리 중인 활성 연결에 대한 것인지 여부를 결정할 수 있다. 그렇지 않다고 결정되면, 로드 밸런서 모듈(132)은 패킷을 통과시킨다. 그렇다고 결정되면, 로드 밸런서 모듈(132)은, 예를 들어 UDP에 따라 아웃고잉 TCP 패킷을 캡슐화하고, 캡슐화된 패킷을 이 연결에 대한 출구 서버(114)로서 선택된 로드 밸런서 노드(110)로 전달한다. 적어도 일부 실시예에서, 로드 밸런서 모듈(134)은 일정한 델타만큼 아웃고잉 TCP 패킷에서의 TCP 시퀀스 번호를 조절하여, 상기 시퀀스 번호가 SYN/ACK 패킷을 클라이언트(160)에게 전송했던 흐름 추적기 노드(116)에 의해 생성된 시퀀스 번호와 정렬되게 할 수 있다.
연결 추적
적어도 일부 실시예에서, 각각의 서버 노드(130) 상의 로드 밸런서 모듈(132)은 각각의 서버(134)로의 모든 활성 클라이언트 연결에 대해 연결 상세사항을 포함하는 해시 테이블을 관리한다. 적어도 일부 실시예에서, 해시 테이블에 대한 키가 (클라이언트IP:포트, 공중IP:포트) 튜플이다. 적어도 일부 실시예에서, 각각의 클라이언트 연결에 대한 연결 상태는 다음에서 비제한적으로 나열된 것들 중 하나 이상을 포함할 수 있다:
Figure pat00013
클라이언트 IP : 포트
Figure pat00014
공중 IP : 포트
Figure pat00015
흐름 추적기(116) 노드에 의해 제공되는 초기 서버 TCP 시퀀스 번호
Figure pat00016
서버 TCP 시퀀스 번호 델타
Figure pat00017
본래의 주 흐름 추적기 IP 주소.
Figure pat00018
본래의 보조 흐름 추적기 IP 주소.
Figure pat00019
마지막으로 검출된 입구 서버(112)의 IP 주소.
Figure pat00020
이 항목에 대한 만료 시점.
Figure pat00021
최근 최소 사용(LRU) /충돌 인덱스
적어도 일부 실시예에서, 각각의 로드 밸런서 모듈(132)은 모든 활성 클라이언트 연결에 대해 주 및 보조 흐름 추적기 노드로 연결 게시 메시지를 주기적으로 생성한다. 적어도 일부 실시예에서, /proc/net/tcp의 내용이 스캔되고 로드 밸런서 모듈의 해시 테이블 내 활성 연결에 의해 교차(intersect)되어, 리눅스(Linux) 커넬이 연결 추적을 종료할 때까지 흐름 추적기 노드로 계속 게시될 것이다. 연결 게시는 본 명세서에서 차후에 더 상세히 설명될 것이다.
시퀀스 번호 맹글링
앞서 기재된 바와 같이, 적어도 일부 실시예에서, 로드 밸런서 노드(110)는 서버(134)를 대신하여 클라이언트(160) SYN 패킷에 응답하여 SYN/ACK 패킷을 생성한다. 클라이언트(160)가 ACK 패킷(TCP 3단계 핸드쉐이크)을 전송한 후에야, 로드 밸런서 모듈(110)은 임의의 데이터를 서버 노드(130) 상의 로드 밸런서 모듈(132)로 전송한다. 로드 밸런서 모듈(132)이 클라이언트 연결을 확립하도록 초기에 명령 받을 때, 상기 로드 밸런서 모듈(132)은 서버 노드(130) 상의 서버(134)와의 TCP 연결을 시작하기 위해 SYN 패킷을 로컬하게 제작하고, 서버(134)의 대응하는 SYN/ ACK 패킷을 인터셉트한다. 일반적으로, 서버(134)(가령, 서버 노드(130) 상의 리눅스(Linux) 커넬)가 로드 밸런서 노드(110)로부터 클라이언트가 SYN/ACK 패킷에 수신한 것과 완전히 상이한 TCP 시퀀스 번호를 선택한다. 따라서 적어도 일부 실시예에서, 로드 밸런서 모듈(132)은 클라이언트(160)와 서버(134) 간 TCP 연결에서 모든 패킷에서 시퀀스 번호에 대해 교정을 수행할 수 있다. 적어도 일부 실시예에서, 로드 밸런서 모듈(132)은 로드 밸런서 노드(110)에 의해 생성된 시퀀스 번호와 서버(134)에 의해 생성된 시퀀스 번호 간 차이를 계산하고 상기 차이를 델타 값으로서 TCP 연결을 위한 해시 테이블 항목에 저장한다. 인커밍 데이터 패킷이 연결 상의 클라이언트(160)로부터 도착할 때, TCP 헤더가 서버(134)에 의해 사용되는 시퀀스 번호와 정렬되지 않을 긍정응답 번호를 포함하여, 로드 밸런서 모듈(132)이 (가령, 2의 보수를 이용해) TCP 헤더 내 시퀀스 번호 값에서 델타 값을 뺄 수 있다. 또한 로드 밸런서 모듈은 연결 상의 서버(134)로부터 클라이언트(130)로의 아웃바운드 패킷 내 시퀀스 번호에 델타 값을 더한다.
분산 로드 밸런서 시스템에서의 건강 체킹
분산 로드 밸런서의 적어도 일부 실시예에서, 각각의 로드 밸런서 노드(110)는 적어도 다음의 이유로 로드 밸런서 구현에서 건강한 구성원의(즉, 건강한 로드 밸런서 노드(110) 및 서버 노드(130)의) 일관된 뷰(consistent view)를 필요로 한다:
Figure pat00022
로드 밸런싱 - 로드 밸런서 노드(110)는 서버 노드(130) 장애를 검출할 필요가 있고 클라이언트 트래픽을 수락할 수 있는 건강한 서버 노드(130)의 세트에 수렴한다.
Figure pat00023
분산 상태 관리 - 로드 밸런서는 (가령, 일관 해싱 수단에 따라) 복수의 로드 밸런서 노드(110) 간에 공유/복제된 상태를 갖는 분산 시스템이다. 클라이언트 트래픽을 적절하게 핸들링하기 위해, 각각의 로드 밸런서 노드(110)는 로드 밸런서 구현에서 건강한 구성원 노드(110)의 최종적으로 일관된 뷰를 가질 필요가 있다.
이를 이루기 위해, 분산 로드 밸런서 시스템의 적어도 일부 실시예는 로드 밸런서 구현예에서 노드를 모니터링하고 가능한 빨리 건강하지 않은 노드를 검출하는 건강 체크 프로토콜의 실시예를 이행할 수 있다. 건강 체크 프로토콜은 로드 밸런서 구현 내 노드들 간에 건강 정보를 전파할 수 있고 노드들이 건강한 노드들의 세트로 수렴할 수 있게 하는 방법을 제공할 수 있다. 덧붙여, 건강 체크 프로토콜은 건강한/건강하지 않은 노드 및 로드 밸런서 구현의 상태 변경을 보고하기 위한 수단을 제공할 수 있다.
적어도 일부 실시예에서, 건강한 체크 프로토콜은 다음에서 비제한적으로 나열된 가정 중 하나 이상을 기초로 할 수 있다:
Figure pat00024
로드 밸런서 구현에서의 모든 노드가 알려져 있다. (즉, 건강 체크 프로토콜은 발견을 수행하지 않을 수 있다).
Figure pat00025
모든 노드 고장은 고장-중단(fail-stop)한다.
Figure pat00026
노드들 간 모든 메시지가 무상태 프로토콜(가령, UDP) 메시지이며, 상기 메시지는 폐기, 지연, 복제, 또는 오염될 수 있다. 메시지 전달에 대한 어떠한 보장도 없다.
적어도 일부 실시예에서, 로드 밸런서 구현(가령, 로드 밸런서 노드(110) 또는 서버 노드(130))에서의 노드가 다음의 조건 하에서 건강하다고 간주될 수 있다:
Figure pat00027
노드의 모든 구성요소가 대기 상태이다(클라이언트 트래픽을 핸들링할 준비가 됨).
Figure pat00028
노드의 인커밍/아웃고잉 네트워크 링크가 건강하다(적어도 클라이언트 트래픽이 흐르는 네트워크 인터페이스 제어기(NIC)에 대해).
도 12는 적어도 일부 실시예에 따라, 건강 체크 간격에 따라 각각의 로드 밸런서 노드에 의해 수행될 수 있는 건강 체크 방법의 하이-레벨 흐름도이다. (1000)으로 지시되는 바와 같이, 각각의 로드 밸런서 간격에서, 예를 들어 100밀리초마다, 각각의 로드 밸런서(LB) 노드(110)는 적어도 하나의 다른 LB 노드(110) 및 적어도 하나의 서버 노드(130)를 건강 체크할 수 있다. (1002)로 지시되는 바와 같이, 로드 밸런서 노드(110)는 건강 체크에 따라 자신이 로컬하게 저장한 건강 정보를 업데이트할 수 있다. 그 후 (1004)로 지시되는 바와 같이, 로드 밸런서 노드(110)는 적어도 하나의 다른 로드 밸런서 노드(110)를 랜덤하게 선택하고, 자신의 건강 정보를 선택된 로드 밸런서 노드(들)(110)로 전송할 수 있다. 적어도 일부 실시예에서, 노드(110)는 또한 건강한 로드 밸런서 노드(110)의 리스트를 하나 이상의 서버 노드(130), 가령, 노드(110)에 의해 건강 체크되는 동일한 서버 노드(들)(130)로 전송할 수 있다. 도 12의 요소가 다음에서 더 상세히 설명된다.
건강 체크 프로토콜의 적어도 일부 실시예에서, 로드 밸런서 노드(110)는 다른 로드 밸런서 노드(110)에게 자신의 건강을 단언하지 않는다. 대신, 하나 이상의 다른 로드 밸런서 노드(110)가 노드(110)를 건강 체크할 수 있다. 예를 들어, 적어도 일부 실시예에서, 각각의 로드 밸런서 노드(110)는 건강 체크할 하나 이상의 타 노드(110)를 주기적으로 또는 비주기적으로 랜덤하게 선택할 수 있다. 또 다른 예를 들면, 적어도 일부 실시예에서, 하나 이상의 타 로드 밸런서 노드(110), 예를 들어, 노드(110)들의 정렬된 리스트, 가령, 일관 해시 링 상의 특정 로드 밸런서 노드(110)의 2개의 최근접 이웃 각각이 특정 노드(110)의 건강을 주기적으로 또는 비주기적으로 체크할 수 있다. 적어도 일부 실시예에서, 노드(110)를 건강 체크하는 것은 도 23에 도시된 바와 같이 노드(110) 상의 NIC(1114)로 전송되는 건강 핑(health ping)을 이용하는 것을 포함할 수 있다. 적어도 일부 실시예에서, 제1 노드(110)가 건강 체크를 통해 제2 노드(110)가 건강하다고 결정한 경우, 제1 노드(110)가 로드 밸런서 노드(110)에 대한 로컬 건강 정보에 저장된 제2 노드(110)에 대한 하트비트 카운터를 업데이트(가령, 증분)할 수 있다. 제1 노드(110)는 자신의 로컬 건강 정보를 로드 밸런서 구현에서의 하나 이상의 그 밖의 다른 로드 밸런서 노드(110)로 주기적으로 또는 비주기적으로 전송하며, 상기 하나 이상의 그 밖의 다른 로드 밸런서 노드는 적절하게 (가령, 제2 노드에 대한 하트비트 카운터를 증분함으로써) 자신의 고유 건강 정보를 업데이트하고 업데이트된 로컬 건강 정보를 하나 이상의 타 노드(110)로 전송한다. 따라서 제2 노드(110)에 대한 하트비트 정보가 로드 밸런서 구현에서의 타 노드(110)로 전파될 수 있다. 따라서 제2 노드(110)가 건강한 한, 제2 노드(110)로부터 도달될 수 있는 타 노드(110) 모두가 일관되게, 가령, 1초에 1회 또는 10초에 1회 증분되는 제2 노드(110)의 하트비트 카운터를 봐야 한다. 제2 노드(110)가, 이의 건강을 체크하는 노드(들)(110)에 의해 건강하지 않다고 검출되는 경우, 건강 체크 노드(110)에 의해 노드(110)에 대한 어떠한 하트비트도 전송되지 않고, 약간의 임계 시간 후에, 로드 밸런서 구현(110) 내 타 노드(110)가 관심 노드(110)를 건강하지 않다고 또는 동작 중단됐다고 간주한다.
적어도 일부 실시예에서, 로드 밸런서 노드(110)가 자신 고유의 내부 상태의 하나 이상의 양태를 체크할 수 있고, 노드(110)가 일부 이유로 건강하지 않다고 검출하는 경우, 노드(110)는 이의 건강을 체크하는 타 노드(110)로부터 건강 핑에 응답하기를 중단할 수 있다. 따라서 건강하지 않은 노드(110)의 건강을 체크하는 노드(110)가 노드(110)를 건강하지 않다고 간주할 수 있고, 노드(110)를 대신하여 하트비트 증분을 전파하지 않을 수 있다.
건강 체크 프로토콜 상세사항
적어도 일부 실시예에서, 건강 체크 프로토콜은 하트비트 카운터 기법 및 가십 프로토콜(gossip protocol) 기법을 활용할 수 있다. 건강 체크 프로토콜은 2개의 주요 부분, 즉, 건강 체킹 및 가십/고장 검출을 가진다고 간주될 수 있다.
건강 체킹 - 로드 밸런서 구현에서의 모든 로드 밸런서 노드(110)가 구현에서의 하나 이상의 타 노드(110)를 주기적으로 또는 비주기적으로 건강 체크할 수 있다. 하나 이상의 그 밖의 다른 노드가 결정되는 방법은 차후 설명된다. 건강 체크의 핵심 아이디어는 노드(110)가 타 노드(110)를 건강 체크하고 상기 타 노드(110)가 건강하다고 결정하는 경우, 체크하는 노드(110)가 상기 타 노드(110)에 대한 하트비트 카운터를 증분 및 전파시킴으로써, 상기 타 노드(110)가 건강함을 단언하는 것이다. 다시 말하면, 노드(110)는 자신 고유의 건강을 타 노드에게 단언하지 않고, 대신, 하나 이상의 타 노드(110)는 로드 밸런서 구현에서의 각각의 노드(110)의 건강을 체크 및 단언한다.
가십 / 고장 검출 - 적어도 일부 실시예에서, 건강 체크 프로토콜은 로드 밸런서 노드(110)의 건강 정보를 로드 밸런서 구현의 구성원 로드 밸런서 노드(110)들에게 전파하기 위해 가십 프로토콜을 활용할 수 있다. 상기 가십 프로토콜은 빠르게 수렴하고, 결국 분산 로드 밸런싱 시스템의 목적을 위해 충분한 일관성 보장을 제공한다. 적어도 일부 실시예에서, 가십 프로토콜을 이용해, 각각의 로드 밸런서 노드(110)는 로드 밸런서 구현의 노드(110) 서로에 대한 하트비트 카운터를, 가령, 하트비트 리스트에 유지관리한다. 각각의 로드 밸런서 노드(110)는 앞서 기재된 바와 같은 적어도 하나의 타 로드 밸런서 노드(110)의 건강 체크를 주기적으로 또는 비주기적으로 수행하고, 건강 체크를 통해 체크된 노드(110)가 건강하다고 결정되면 노드(110)에 대한 하트비트 카운터를 증분한다. 적어도 일부 실시예에서, 각각의 로드 밸런서 노드(110)는 자신의 현재 하트비트 리스트를 전송하는 로드 밸런서 구현의 적어도 하나의 타 노드(110)를 주기적으로 또는 비주기적으로 랜덤하게 선택한다. 또 다른 노드(110)로부터의 하트비트 리스트가 수신되면, 두 개의 리스트(수신된 리스트 및 자신 고유의 리스트)에서 각각의 노드(110)에 대한 최대 하트비트 카운터를 결정하고 결정된 최대 하트비트 카운터를 자신 고유의 하트비트 리스트에서 사용함으로써, 로드 밸런서 노드(110)가 수신된 리스트에서의 하트비트 정보를 자신 고유의 하트비트 리스트와 병합한다. 그 후, 이 하트비트 리스트는 또 다른 랜덤하게 선택된 노드(110)로 전송되며, 이에 따라 상기 랜덤하게 선택된 노드는 자신의 고유 하트비트 리스트를 업데이트하는 등이다. 이 기법을 이용해, 각각의 건강 노드(110)에 대한 하트비트 정보가 로드 밸런서 구현의 모든 타 로드 밸런서 노드(110)로 (가령, 수 초 내에) 결국 전파된다. 하트비트 카운터가 특정 로드 밸런서 노드(110)에 대해 계속 증가하는 한, 다른 노드(110)에 의해 건강하다고 간주된다. 건강 체크 및 가십 방법에 의해, 로드 밸런서 노드(110)의 하트비트 카운터가 특정 주기 동안 증분되지 않는 경우, 타 로드 밸런서 노드(110)가 건강하지 않다고 간주되는 로드 밸런서 노드(110)로 수렴할 수 있다.
건강 체크 및 로드 밸런서 노드
이하에서 적어도 일부 실시예에 따르는, 타 로드 밸런서 노드(110)에 의해 수행될 수 있는 로드 밸런서 노드(110) 건강 체크 방법이 기재된다. 도 23을 참조하면, 적어도 일부 실시예에서, 로드 밸런서 노드(110)는, 노드(110)에 대해 다음의 조건 중 하나 이상이 결정되는 경우, 건강하다고 간주될 수 있다:
Figure pat00029
노드(110)의 프로세서 스레드(가령, 코어 패킷 프로세싱 코드(1108) 스레드)가 대기 상태이다(내부).
Figure pat00030
노드(110)가 에지 라우터(104)의 IP 주소 및/또는 MAC 주소를 안다(내부).
Figure pat00031
노드(110)의 모든 스레드 및/또는 프로토콜 핸들러가 대기 상태이다(내부).
Figure pat00032
노스 측(에지 라우터(104)/경계 네트워크) 및 사우스 측(서버(130)/생성 네트워크)로부터의 인커밍 및 아웃고잉 링크가 활성상태이다(외부).
Figure pat00033
노드(110)는 로드 밸런서 구현에서 사용되는 네트워크 인터페이스 제어기(NIC)를 통해 패킷을 수신하고 발송할 수 있다. 예를 들어, 도 23에 도시된 예시적 로드 밸런서 노드(110) 실시예에서, 노드(110)는 노스-면(north-facing) NIC(1114A) 및 사우스-면(south-facing) NIC(114B)를 통해 패킷을 성공적으로 수신 및 발송해야 한다.
이들 건강 조건들 중 하나 이상이 특정 노드(110)에 대해 유지되지 않는 경우, 노드(110)는 건강하지 않다고 간주될 수 있다. 일부 실시예에서, 노드(110)는 상기 조건들 모두가 노드(110)에 유지될 때만 건강하다고 간주된다.
적어도 일부 실시예에서, 상기 건강 조건에 추가로, 예를 들어, 제어 평면 통신을 위해 사용될 수 있는 각각의 로드 밸런서 노드(110) 상에서 도 23에 NIC(1114C)로 도시된 제3 NIC가 또한 건강 체크하는 노드(110)에 의해 패킷을 NIC로 전송하고 이로부터 패킷을 수신함으로써 체크될 수 있고, 제3 NIC 체크가 실패한 경우, 체크되는 노드(110)가 건강하지 않다고 간주될 수 있다.
도 13은 적어도 일부 실시예에 따르는 또 다른 로드 밸런서 노드로부터 로드 밸런서 노드를 건강 체크하기 위한 예시적 방법을 도시한다. 이 예시에서, 로드 밸런서 노드(110A)가 로드 밸런서 노드(110B)를 건강 체크한다. 각각의 노드(110A 및 110B)가 노스-면 NIC(도 23의 NIC(1114A)) 및 사우스-면 NIC(도 23의 NIC(1114B))를 가진다. (1)에서, 노드(110A)가 자신의 노스-면 NIC로부터 에지 라우터(104)를 통해 노드(110B)의 노스-면 NIC로 패킷(가령, 핑 패킷)을 전송한다. 노드(110B)는 자신의 노스-면 NIC 상에서 패킷을 수신하고, (2)에서, 상기의 리스트에서 주어진 조건이 만족된다고 가정할 때, 패브릭(120)을 통해 자신의 노스-면 NIC로부터 노드(110A)의 노스-면 NIC로 응답을 전송한다. 자신의 노스-면 NIC 상에서 응답을 수신한 후, (3)에서, 노드(110A)는 패브릭(120)을 통해 자신의 사우스-면 NIC로부터 노드(110B)의 사우스-면 NIC로 패킷(가령, 핑 패킷)을 전송한다. 노드(110B)는 자신의 사우스-면 NIC 상에서 패킷을 수신하고, (4)에서, 상기의 리스트에서 주어진 조건들이 만족된다고 가정할 때, 에지 라우터(104)를 통해 자신의 사우스-면 NIC로부터 노드(110A)의 사우스-면 NIC로 응답을 전송한다. 자신의 사우스-면 NIC 상에서 응답을 수신하면, 노드(110A)는 노드(110B)가 건강하다고 간주하고 노드(110B)의 로컬 하트비트 카운터를 증분시키며, 상기 로컬 하트비트 카운터는 앞서 기재된 바와 같이 가십 프로토콜에 따라 타 노드(110)로 전파될 수 있다.
상기에 대한 대안예로서, 일부 실시예에서, 로드 밸런서 노드(110B)가 자신의 사우스-면 NIC를 통해 노드(110A)의 사우스-면 NIC로 자신의 노스-면 NIC에 수신된 제1 핑 메시지에 응답할 수 있으며, 자신의 노스-면 NIC를 통해 노드(110A)의 노스-면 NIC로 자신의 사우스-면 NIC에서 수신된 제2 핑 메시지에 응답할 수 있다.
덧붙여, 일부 실시예에서, 노드(110A)는 또한, 자신 고유의 제3 NIC로부터 노드(110B)의 제3 NIC에 핑을 전송하고 노드(110B)가 건강한 경우 노드(110B)의 제3 NIC로부터 자신의 제3 NIC 상에서 핑 메시지에 대한 응답을 수신함으로써, 제어 평면 통신을 위해 사용되는 노드(110B)의 제3 NIC(도 23의 NIC(1114C)로서 나타남)를 건강 체크할 수 있다. 핑 메시지 및 응답이 하나 이상의 제어 평면 장치(들)(170), 예를 들어 네트워크 스위치를 통과할 수 있다.
앞서 기재된 건강 체크 메커니즘이 모든 방향(노스, 사우스, 및 제어 평면을 통과하는 방향)으로의 노드(110B)의 인커밍 및 아웃고잉 링크 모두 및 데이터 경로뿐 아니라 노드(110B)의 모든 NIC를 연습시키고 클라이언트 패킷이 그러는 것만큼 핑 패킷이 내부 큐(internal queue) 및 노드(110B)의 발송을 횡단할 때 노드(110B)의 내부 건강을 검증한다.
건강 체크 책임을 로드 밸런서 노드로 할당
적어도 일부 실시예에서, 로드 밸런서 구현의 모든 로드 밸런서 노드(110)가, 예를 들어, 도 1에 도시된 구성 기능 및/또는 구성 서비스(122) 구성요소를 통해, 로드 밸런서 구현의 모든 타 로드 밸런서 노드(110)의 리스트(가령, 정렬된 리스트)를 액세스할 수 있다. 적어도 일부 실시예에서, 각각의 로드 밸런서 노드(110)는 각각의 건강 체크 간격에서 건강 체크할 리스트 상에서 하나 이상의 타 노드(110)를 랜덤하게 선택할 수 있고, 건강하다고 결정되면 이들의 하트비트 카운터를 증분할 수 있다. 리스트는 건강 체크 메커니즘을 통해 현재 건강하다고 간주되거나 또는 건강하지 않다고 간주되는지에 무관하게, 로드 밸런서 구현의 모든 로드 밸런서 노드(110)를 포함하고, 건강한 노드(110)뿐 아니라 현재 건강하지 않은 노드(110)가 리스트로부터 랜덤하게 선택될 수 있고 건강 체크될 수 있다. 따라서 현재 건강하지 않은 노드(110)가 노드(110)를 건강 체크하는 하나 이상의 노드(110)에 의해 건강하다고 결정될 수 있고, 이의 하트비트 카운터가 증분되고 타 노드(110)로 전파될 수 있으며, 따라서 건강하지 않은 노드(110)가 건강 상태로 복귀할 수 있다.
대안적으로, 일부 실시예에서, 각각의 로드 밸런서 노드(110)는 리스트 내 하나 이상의 타 노드(110)를 건강 체크하고 건강하다고 결정되면 이들의 하트비트 카운터를 증분할 책임을 가질 수 있다. 예를 들어, 일부 실시예에서, 각각의 노드(110)는 2개의 타 노드, 가령, 리스트에서 자신의 "왼쪽"(또는 이전) 및 "오른쪽"(또는 다음) 최근접 이웃 노드(110)에 대한 책임을 가질 수 있다. 리스트는 순환형으로 간주될 수 있으며 상기 리스트의 "끝부분"의 노드(110)가 리스트의 "시작부분"에서의 노드(110)를 건강 체크할 책임을 가질 수 있으며, 그 반대도 가능할 수 있다. 일부 실시예에서, 그 밖의 다른 두 노드(110)가 그 밖의 다른 방식으로 선택될 수 있는데, 가령, 리스트 상에서 가장 가까운 2개의 옆 노드가 선택될 수 있다. 일부 실시예에서, 각각의 노드(110)가 리스트 상에서 셋 이상의 타 노드(110), 가령, 3개 또는 4개의 타 노드(110)를 건강 체크할 책임을 가질 수 있다. 적어도 일부 실시예에서, 노드(110)에 의해 체크되는 이웃 노드(110)가 건강하지 않다고 결정되는 경우, 노드(110)는 건강하지 않은 이웃 노드(110)가 체크할 책임을 가졌던 리스트 상의 적어도 하나의 노드를 건강 체크할 책임을 가질 수 있다. 적어도 일부 실시예에서, 자신의 이웃 노드(110)(가령, "왼쪽" 및 "오른쪽" 이웃 노드)를 건강 체크하는 것에 추가로, 각각의 로드 밸런서 노드(110)가 또한 링 내 하나의 노드(110)를 주기적으로 또는 비주기적으로 랜덤하게 선택하고 상기 랜덤하게 선택된 노드(110)의 건강 체크를 수행할 수 있으며, 건강한 경우, 랜덤 노드(110)의 하트비트를 증분하고 전파할 수 있다. 적어도 일부 실시예에서, 정렬된 리스트의 모든 나머지 노드(110)가, 나머지 노드(110)가 이전에 건강하다고 간주되었는지 또는 건강하지 않다고 간주되었는지에 무관하게, 랜덤 선택 및 건강 체크의 대상으로 간주된다.
적어도 일부 실시예에서, 각각의 노드(110)는 하나 이상의 랜덤하게 선택된 노드(110) 또는 이의 이웃 노드(110) 및 랜덤하게 선택된 노드의 건강 체크를, 건강 체크 간격으로 지칭될 수 있는 규칙적인 간격으로 수행한다. 예를 들어, 일부 실시예에서, 하트비트 간격은 100밀리초일 수 있지만, 더 짧거나 더 긴 간격도 사용될 수 있다. 덧붙여, 적어도 일부 실시예에서, 각각의 노드(110)는 규칙적인 간격으로 자신의 현재 하트비트 리스트를 적어도 하나의 타 랜덤 선택된 노드(110)로 전송 또는 "가십"하며, 상기 규칙적인 간격은 가십 간격이라고 지칭될 수 있다. 일부 실시예에서, 건강 체크 간격 및 가십 간격이 동일할 수 있지만, 반드시 동일할 필요는 없다.
도 14는 적어도 일부 실시예에 따르는, 하나 이상의 타 로드 밸런서 노드를 건강 체크하는 로드 밸런서 노드를 그래픽으로 도시한다. 이 예시에서, 로드 밸런서 구현에 8개의 로드 밸런서 노드(110A-110H)가 존재한다. 점선 원이 구현의 모든 노드(110)의 정렬된 리스트를 나타낸다. 일부 실시예에서, 각각의 노드(110)는 각각의 간격에서 건강 체크할 리스트 상에서 하나 이상의 타 노드(110)를 랜덤하게 선택할 수 있다. 대안예로서, 일부 실시예에서, 각각의 로드 밸런서 노드(110)는 정렬된 리스트 상의 하나 이상의 특정 노드(110)를 체크하는 책임을 가질 수 있는데, 가령, 노드(110A)가 도 14에 도시된 정렬된 리스트에 따라 자신의 2개의 최근접 이웃 노드(110B 및 110H)를 건강 체크할 책임을 가질 수 있다. 덧붙여, 로드 밸런서 노드는 각각의 건강 체크 간격에서 정렬된 리스트로부터 또 다른 노드(110)를 랜덤하게 선택할 수 있다. 이 예시에서 도시된 바와 같이, 노드(110A)는 또한 건강 체크하기 위해 랜덤하게 선태된 노드(110F)를 가진다. 가십 간격에서, 노드(110A)가 타 건강한 노드(110), 가령, 노드(110D)를 랜덤하게 선택하고, 이의 현재 하트비트 리스트를, 가령, UDP 메시지로 선택된 다른 노드(110)로 전송한다. 노드(110)는, 다른 노드(110)로부터 하트비트 리스트를 수신하면, 자신의 고유 하트비트 리스트를 업데이트할 수 있고 다음 가십 간격에서 하트비트 리스트를 하나 이상의 랜덤하게 선택된 노드(110)로 전파할 수 있다.
서버 노드의 건강 체크
앞서 기재된 바와 같이 로드 밸런서 노드(110)를 건강 체크하는 것에 추가로, 건강 체크 프로토콜의 실시예가 이들 노드(130) 상의 로드 밸런서 모듈(132) 및 서버(134)를 포함하는 서버 노드(130)의 건강 체크를 수행할 수 있다. 적어도 일부 실시예에서, 서버 노드(130)에 대해 다음의 조건 중 하나 또는 둘 모두가 결정되면, 노드(130)는 건강하다고 간주될 수 있다:
Figure pat00034
로드 밸런서 모듈(132)이 건강하다.
Figure pat00035
서버 노드(130)는 건강 핑(가령, L7 건강 핑(health ping))에 성공적으로 응답한다.
도 15는 적어도 일부 실시예에 따르는, 서버 노드를 건강 체크하는 로드 밸런서 노드를 도시한다. 적어도 일부 실시예에서, 로드 밸런서 구현의 모든 로드 밸런서 노드(110)가 로드 밸런서 구현의 모든 타 로드 밸런서 노드(110)의 리스트 및 로드 밸런서 구현의 모든 서버 노드(130)의 리스트를 액세스할 수 있다. 예를 들어, 도 1에 도시된 바와 같이 구성 기능 및/또는 구성 서비스(122) 구성요소를 통해 리스트(들)가 획득 및 업데이트될 수 있다. 적어도 일부 실시예에서, 서버 노드(130)는 건강한 로드 밸런서 노드(110)에 대해 일관 해시되어, 도 15에 도시된 바와 같은 일관 해시 링을 형성할 수 있다. 적어도 일부 실시예에서, 링 내 2개의 건강한 로드 밸런서 노드(110)에 의해 링 내 각각의 서버 노드(130)가 건강 체크된다. 예를 들어, 도 15에서, 서버 노드(130A)는 로드 밸런서 노드(110A 및 110C)에 의해 건강 체크된다. 이들 2개의 노드(110)는 일관 해시 링 내 서버 노드(130)에 대해 제1(노드(110A)) 및 제2(노드(110B)) 건강 체킹 노드(110)라고 지칭될 수 있다. 특정 건강한 로드 밸런서 노드(110)가 둘 이상의 서버 노드(130)를 건강 체크할 수 있다. 예를 들어, 도 15에서, 로드 밸런서 노드(110A)가 또한 서버 노드(130B 및 130C)를 건강 체크한다. 덧붙여, 특정 노드 밸런서 노드(110)가 하나 이상의 서버 노드(130)에 대한 제1 건강 체킹 노드(110)이자 하나 이상의 타 서버 노드(130)에 대한 제2 건강 체킹 노드(110)일 수 있다. 예를 들어, 도 15에서, 로드 밸런서 노드(110A)는 서버 노드(130A 및 130B)에 대한 제1 건강 체커 노드이자 서버 노드(130C 및 130D)에 대한 제2 건강 체커 노드이다.
적어도 일부 실시예에서, 로드 밸런서 노드(110)가 고장 난 경우, 일관 해시 링 내 구성원이 변경되고, 로드 밸런서 노드(110) 중 아직 건강하고 따라서 일관 해시 링 상에 있는 하나 이상의 다른 로드 밸런서 노드가 고장 난 노드(110)에 의해 이전에 건강 체크된 서버 노드(130)를 건강 체크할 책임을 가질 수 있다.
적어도 일부 실시예에서, 각각의 건강한 노드(110)가 서버 체크 간격이라고 지칭될 수 있는 규칙적인 간격으로, 자신의 할당된 서버 노드(130)의 건강 체크를 수행한다. 적어도 일부 실시예에서, 서버 체크 간격은 앞서 언급된 가십 간격보다 길거나 같을 수 있다.
적어도 일부 실시예에서, 서버 노드(130)의 건강 체크를 수행하기 위해, 건강한 로드 밸런서 노드(110)(가령, 도 15의 노드(110A))가 서버 노드(130)(가령, 도 15의 서버 노드(130A))로의 건강 핑 메시지(가령, L7 HTTP 건강 핑 메시지)를 개시한다. 건강한 경우, 서버 노드(130)는 로드 밸런서 노드(110)로 다시 핑 응답(ping response)을 전송한다. 적어도 일부 실시예에서, 서버 노드(130) 상의 로드 밸런서 모듈(132)에 의해 핑 메시지가 수신되고 프로세싱되어, 건강 체크 핑이 성공적인 경우, 서버 노드(130) 상의 모듈(132)이 건강하다고 확립한다. 핑에 대한 응답을 수신하면, 로드 밸런서 노드(110)가 서버 노드(130)를 건강한 것으로 간주하고, 서버 노드(130)에 대한 하트비트 카운터를 증분한다.
적어도 일부 실시예에서, 특정 건강한 로드 밸런서 노드(110)에 의해 건강 체크되는 모든 서버 노드(130)에 대한 하트비트 카운터가, 가령, 로드 밸런서 노드(110) 하트비트 카운터에 대해 앞서 기재된 가십 기법에 따라 타 로드 밸런서 노드(110)로 전파될 수 있으며, 여기서 각각의 노드(110)가 규칙적인 간격(가십 간격)으로 자신의 하트비트 리스트를 적어도 하나의 타 랜덤 선택된 노드(110)로 전송하고, 수신 노드(110)가 2개의 리스트에서의 최대 값에 따라 자신의 하트비트 리스트를 업데이트한다.
고장 검출 및 가십
적어도 일부 실시예에서, 모든 로드 밸런서 노드(110)는 로드 밸런서 구현의 일관 뷰를 유지관리할 수 있도록, 앞서 기재된 로드 밸런서 노드(110) 건강 체크 및 서버 노드(130) 건강 체크를 통해 획득된 정보가 로드 밸런서 구현의 모든 노드(110)로 전파될 필요가 있을 수 있다. 앞서 기재된 바와 같이, 적어도 일부 실시예에서, 로드 밸런서 노드(110)는 가십 프로토콜에 따라 서로 통신하여, 이 건강 정보를 교환 및 전파하고 로드 밸런서 노드(110) 및 서버 노드(130) 고장을 검출할 수 있다.
적어도 일부 실시예에서, 규칙적인 간격(가십 간격이라고 지칭됨)에서, 각각의 로드 밸런서 노드(110)가 또 다른 로드 밸런서 노드(110)를 랜덤하게 선택하고 건강한 로드 밸런서 노드(110) 및 서버 노드(130)의 관점에서 타 노드(110)에게 로드 밸런서 노드(110) 및 서버 노드(130)에 대한 하트비트 카운터와 함께 전송한다. 로드 밸런서 노드 또는 서버 노드(130)가 건강한 한, 노드는 자신의 건강 체크를 전달할 것이고 자신의 하트비트 카운터가 계속 증가할 것이다. 노드에 대한 하트비트 카운터가 (고장 시간 간격이라고 지칭될 수 있는) 특정된 간격 동안 변경되지 않으면, 노드는 로드 밸런서 노드(110)에 의해 고장이라고 추정된다. 노드가 고장 났다고 추정되면, 로드 밸런서 노드(110)는 노드가 건강하지 않다고 결정하기 전에 특정된 간격(비건강 시간 간격이라고 지칭될 수 있음) 동안 기다릴 수 있다. 이 비건강 시간 가격은 모든 로드 밸런서 노드(110)가 노드가 고장 났음을 학습할 때까지 로드 밸런서 노드(110)가 기다리게 한다.
도 16은 적어도 일부 실시예에 따라 로드 밸런서 노드(110)에 의해 유지될 수 있는 또 다른 노드(로드 밸런서 노드(110) 또는 서버 노드(130))의 건강에 대한 상태 또는 건강의 뷰를 그래픽으로 도시한다. 로드 밸런서 노드(110)가 (300)으로 지시되는 바와 같이, 건강한 관심 노드의 뷰로 시작한다고 가정한다. 이는 노드에 대한 하트비트 카운터가 증분했음을 가리킨다. 그러나 (302)로 지시되는 바와 같이 노드의 하트비트 카운터가 특정된 간격(고장 시간 간격) 동안 증가하지 않는 경우, (304)로 지시되는 바와 같이, 로드 밸런서 노드(110)는 노드가 고장 났다고 추측한다. (306)으로 지시되는 바와 같이 노드의 하트비트 카운터가 특정된 간격(비건강 시간 간격) 동안 증가하지 않은 경우, (308)로 지시되는 바와 같이, 로드 밸런서 노드(110)는 상기 노드가 건강하지 않다고 간주한다. 그러나 (310)으로 지시되는 바와 같이, 비건강 시간 가격이 만료하기 전에 노드에 대한 하트비트 카운터가 증분하는 경우, 로드 밸런서 노드(110)는 다시 노드를 비건강 상태로 간주한다(300). 마찬가지로, (312)로 지시되는 바와 같이 건강하지 않은 노드에 대한 하트비트 증분을 수신함으로써 상기 노드가 건강한 것으로 간주될 수 있다(300).
노드가 건강하지 않다고 결정하는 것은, 본 명세서에 기재될 바와 같이, 건강하지 않은 노드가 로드 밸런서 노드(110)인지 또는 서버 노드(130)인지에 따라, 또는 로드 밸런서 노드(110)의 건강하지 않은 노드와의 관계에 따라서, 로드 밸런서 노드(들)(110)에 의한 서로 다른 동작을 포함할 수 있다.
로드 밸런서 노드 데이터
적어도 일부 실시예에서, 각각의 로드 밸런서 노드(110)는 로드 밸런서 구현의 상태에 대한 데이터를 유지관리할 수 있다. 적어도 일부 실시예에서, 이 데이터는 각각의 로드 밸런서 노드(110) 상의 하나 이상의 데이터 구조, 비제한적 예를 들면, 건강한 로드 밸런서 노드 리스트, 의심 로드 밸런서 노드 리스트, 및 하트비트 리스트로 유지관리될 수 있다. 도 17은 건강한 로드 밸런서 노드 리스트(320), 의심 로드 밸런서 노드 리스트(322), 건강하지 않은 로드 밸런서 노드 리스트(324), 및 로드 밸런서 노드 하트비트 리스트(326)를 유지관리하는 예시적 로드 밸런서 노드(110)를 도시한다.
적어도 일부 실시예에서, 각각의 로드 밸런서 노드(110)는, 예를 들어, 어느 노드(110)가 건강한지, 따라서 가십 프로토콜에 참여하는지를 결정하는 데 사용될 수 있는 건강한 로드 밸런서 노드(110)들의 리스트인 건강한 로드 밸런서 노드 리스트(320)를 유지관리할 수 있다. 리스트(320) 상의 노드(110)만 가십 프로토콜을 통한 로드 밸런서 정보의 전파에 포함되고, 리스트(320) 상의 노드(110)만 일관 해시 링 내에 있다고 간주되며, 이 리스트 상의 노드(110)만 서버 노드(130)를 건강 체크한다. 노드(110)는 이 리스트(320)로부터, 자신의 하트비트 정보가 전송되는 또 다른 노드(110)를 랜덤 선택할 수 있다. 덧붙여, 하트비트 카운터는 건강한 로드 밸런서 노드 리스트(320) 내에 현재 있는 노드(110)에 대해서만 교환된다. 적어도 일부 실시예에서, 노드 N이 로드 밸런서 노드(110)에 의한 건강 체크를 통과한 경우 또는 로드 밸런서 노드(110)가 리스트(320) 상의 일부 다른 로드 밸런서 노드(110)로부터 노드 N에 대한 가십 메시지를 수신한 경우, 로드 밸런서 노드 N은 또 다른 로드 밸런서 노드(110)의 건강한 로드 밸런서 노드 리스트(320)에 추가될 수 있다.
적어도 일부 실시예에서, 각각의 로드 밸런서 노드(110)는 특정된 간격(고장 시간 간격이라고 지칭됨) 동안 증가되지 않은 하트비트 카운터(하트비트 리스트(326) 참조)를 갖는 로드 밸런서 노드들의 리스트인 의심 로드 밸런서 노드 리스트(322)를 유지관리할 수 있다. 로드 밸런서 노드 E가 로드 밸런서 노드(110)의 의심 로드 밸런서 노드 리스트(322) 내에 있는 경우, 로드 밸런서 노드(110)가 노드 E에 대해 가십을 전파하지 않을 것이다. 건강한 리스트(320) 상의 일부 다른 로드 밸런서 노드(110)가 로드 밸런서 노드(110)에게 노드(110)의 하트비트 리스트(326)에서 노드 E에 대한 카운터보다 더 높은 하트비트 카운터를 갖는 노드 E에 대해 가십을 전파하면, 노드 E는 의심 리스트(322)에서 건강 리스트(320)로 이동될 것이다. 노드 E가 특정된 간격(비건강 시간 간격이라고 지칭됨) 동안 로드 밸런서 노드(110)의 의심 리스트(322) 상에 머무르는 경우, 노드 E는 로드 밸런서 노드(110)에 의해 건강하지 않다고 간주되고 건강하지 않은 노드 리스트(324)로 이동된다. 노드 G가 노드(110)에 의한 건강 체크를 통과하면, 또는 또 다른 노드(110)로부터 노드 G에 대한 업데이트된 하트비트 카운터를 수신하면, 건강하지 않은 노드 리스트(324) 상의 노드(110)(이 예시에서, 노드 G)가 로드 밸런서 노드(110)의 건강한 노드 리스트(320)로 이동될 수 있다.
적어도 일부 실시예에서, 각각의 로드 밸런서 노드(110)가 모든 알려진 로드 밸런서 노드(110)에 대해 하트비트 리스트(326)를 유지관리할 수 있다. 각각의 노드(110)에 대해, 이 리스트(326)는 하트비트 카운터 및 상기 하트비트 카운터가 마지막으로 변경된 때를 지시하는 타임스탬프를 포함할 수 있다.
적어도 일부 실시예에서, 각각의 로드 밸런서 노드(110)는 또한 도 17에 도시되지 않은 모든 알려진 서버 노드에 대해 하트비트 리스트를 유지관리할 수 있다. 이 리스트는 로드 밸런서 노드 하트비트 리스트(326)와 유사할 수 있다. 일부 실시예에서, 2개의 리스트가 조합될 수 있다. 적어도 일부 실시예에서, 서버 노드(130)에 대한 상기 하트비트 정보가, 가령, 가십 프로토콜에 따라, 로드 밸런서 노드(110)에 대한 하트비트 정보와 함께 또는 이에 추가로, 로드 밸런서 노드(110)들 간에 전파될 수 있다.
도 17이 4개의 개별적인 리스트를 도시하지만, 리스트들 중 둘 이상의 리스트가 하나의 단일 리스트로 조합될 수 있음을 알아야 한다. 예를 들어, 일부 실시예에서, 모든 노드(110)들의 단일 리스트가 각각의 로드 밸런서 노드(110) 상에서 유지관리될 수 있으며, 각각의 노드가 현재 건강한지, 또는 의심되는지, 또는 건강하지 않은지를 지시하기 위해, 비트 플래그 또는 그 밖의 다른 데이터 구조가 사용될 수 있다.
서버 노드 데이터
적어도 일부 실시예에서, 상기 서버 노드(130) 및 노드(130) 상의 로컬 로드 밸런서 모듈(132)은 로드 밸런서 노드(110)에 의한 가십 프로토콜에 참여하지 않는다. 상기 로드 밸런서 노드(110)는 로드 밸런서 노드 건강 체크 방법에 의해 획득된 타 로드 밸런서 노드(110)에 대한 하트비트 정보 및 서버 노드 건강 체크 방법에 의해 획득된 서버 노드(130)에 대한 하트비트 정보에 대한 가십을 서로들 간에만 전파한다(구체적으로, 각각의 로드 밸런서 노드(110)는 자신의 건강한 로드 밸런서 노드 리스트(320) 상에 현재 있는 노드로만 가십을 전파한다).
그러나 각각의 서버 노드(130)/로드 밸런서 모듈(132)은 로드 밸런서 구현에서의 건강한 로드 밸런서 노드(110)에 대한 정보를 필요로 할 수 있어서, 서버 노드(130)는 서버 노드(130)는 아웃고잉 클라이언트 트래픽을 전달할 수 있는 로드 밸런서 노드(110)(구체적으로, 출구 노드)를 결정하고, 연결 게시 정보가 전송될 로드 밸런서 노드를 결정할 수 있다. 적어도 일부 실시예에서, 서버 노드(130)로 이 정보를 제공하기 위해, 로드 밸런서 노드(110)는 현재 건강한 로드 밸런서 노드(110)를 식별하는 정보(가령, 도 17의 건강한 로드 밸런서 노드 리스트(320)) 로 서버 노드(130)를 주기적으로 또는 비주기적으로 업데이트할 수 있다. 적어도 일부 실시예에서, 특정 서버 노드(130(도 15 참조)를 건강 체크할 책임이 있는 로드 밸런서 노드(110)는 현대 건강한 로드 밸런서 노드를 식별하는 정보를 서버(130)로 제공할 책임을 가진다. 예를 들어, 도 15를 참조하면, 로드 밸런서 노드(110A)는 자신의 건강한 로드 밸런서 노드 리스트(320)를 서버 노드(130A, 130B, 130C, 및 130D)로 전송할 수 있고, 로드 밸런서 노드(110B)는 자신의 건강한 로드 밸런서 노드 리스트(320)를 서버 노드(130C, 130D, 및 130E)로 전송할 수 있는 등이다.
로드 밸런서 노드 고장 핸들링
도 18a 및 18b는 적어도 일부 실시예에 따라 로드 밸런서 노드 고장을 핸들링하는 것을 도시한다. 도 18a는 예시적 로드 밸런서 구현을 도시한다. 로드 밸런서 구현에는 현재 4개의 로드 밸런서 노드(110A 내지 110D)가 존재한다. 에지 라우터(104)는 클라이언트(도시되지 않음)로부터의 인커밍 패킷을 로드 밸런서 노드(110)로 라우팅한다. 적어도 일부 실시예에서, 에지 라우터(104)는 레이어 4 흐름당 해싱된 다중경로 라우팅 기법, 가령, 등가 다중경로(ECMP) 라우팅 기법에 따라 라우팅 결정을 할 수 있다. 적어도 일부 실시예에서, 에지 라우터(104)는 로드 밸런서 노드(110) 광고를 통해, 가령, 로드 밸런서 노드(110)에 의해 개시된 경계 게이트웨이 프로토콜(Border Gateway Protocol)(BGP) 기법 세션을 통한 광고를 통해, 클라이언트 트래픽을 수신하기 위해 로드 밸런서 구현에 현재 이용 가능한 로드 밸런서 노드(110)에 대해 학습한다. 그러나 적어도 일부 실시예에서, 로드 밸런서 노드(110)가 BGP 세션을 통해 자신을 에지 라우터(104)로 광고하는 대신, 로드 밸런서 구현에서의 적어도 하나의 타 노드(110)가 BGP를 통해 에지 라우터(104)로 노드(110)를 광고할 책임을 가진다. 예를 들어, 도 18a의 일부 실시예에서, 특정 노드(110)의 왼쪽 및 오른쪽 이웃 노드(110)가 특정 노드(110)를 에지 라우터(104)에게 광고한다. 예를 들어, 로드 밸런서 노드(110A)는 노드(110B 및 110D)를 광고하고, 로드 밸런서 노드(110B)는 노드(110A 및 110C)를 광고하며, 로드 밸런서 노드(110C)는 노드(110B 및 110D)를 광고한다.
도 18a의 예시에서 도시된 바와 같이, 각각의 로드 밸런서 노드(110)는 로드 밸런서 노드 또는 하나 이상의 이웃 노드 및 하나 이상의 랜덤하게 선택된 노드의 정렬된 리스트에 의해 결정되는 바와 같이, 하나 이상의 타 로드 밸런서 노드(110), 가령, 하나 이상의 랜덤하게 선택된 노드(110), 하나 이상의 이웃 노드(110)를 주기적으로 건강 체크한다. 덧붙여, 각각의 로드 밸런서 노드(110)는 적어도 하나의 서버 노드(130)를 주기적으로 건강 체크할 수 있고 또한 건강한 로드 밸런서 노드(110)의 리스트를 자신이 건강 체크하는 서버 노드(들)로 전송할 수 있다. 로드 밸런서 노드(110) 및 서버 노드(130)에 대한 건강 정보가, 가령, 가십 프로토콜에 따라, 노드(110)로 전판될 수 있다.
도 18b는 도 18a의 예시적 로드 밸런서 구현에서의 단일 로드 밸런서 노드(110)의 고장의 핸들링을 도시한다. 이 예시에서, 로드 밸런서 노드(110B)는 몇 가지 이유로 고장 났다. 예를 들어, 노드(110A 및 110C)가 노드(110B)를 건강 체크할 수 있고, 둘 모두 노드(110B)까 자신의 건강 체크에 통과하지 못함을 검출할 수 있다. 따라서 노드(110A 및 110C)는 노드(110B)에 대한 하트비트 카운터를 증분하지 않는다. 두 노드(110A 및 110B) 모두로부터의 하트비트 정보가, 가십 프로토콜에 따라, 타 건강한 로드 밸런서 노드(110)로 전파된다(이 예시에서, 타 로드 밸런서 노드만 노드(110D)임). 건강한 로드 밸런서 노드(110)(이 예시에서, 노드(110A, 110C, 및 110D)) 모두가 노드(110B)의 고장에 수렴하자마자, 다음에서 비제한적으로 나열된 이벤트 중 하나 이상이 발생할 수 있다. 이들 이벤트가 이 순서로 반드시 발생하는 것은 아니다.
Figure pat00036
노드(110A 및 110C)가 에지 라우터(104)에게 노드(110B)를 광고하기를 중단한다. 적어도 일부 실시예에서, 이는 노드(110B)를 광고하기 위해 노드(110)가 확립한 에지 라우터(104)와의 BGP 세션을 종료하는 것을 포함한다. 각각의 노드(110)가 자신이 광고하는 각각의 타 노드(110)에 대해 에지 라우터(104)와의 개별적인 BGP 세션을 확립하는데, 따라서 노드(110B)에 대한 BGP 세션을 종료하는 것이 광고되는 다른 노드(110)에 영향을 미치지 않는다. 적어도 일부 실시예에서, 노드(110)는 BGP 세션에 대한 TCP 폐쇄(TCP Close) 또는 유사한 메시지를 에지 라우터(104)로 전송함으로써 에지 라우터(104)와의 BGP 세션을 종료한다.
Figure pat00037
임의의 노드에 의해 노드(110B)가 더는 광고되지 않음의 검출에 응답하여, 에지 라우터(104)는 노드(110B)로 클라이언트 데이터 패킷을 라우팅하기를 종료한다. 또한 에지 라우터(104)는 클라이언트에서 나머지 건강한 로드 밸런서 노드(110), 특히, 노드(110) 상의 입구 서버(112)로 패킷 흐름을 재분산하기 위해 다중경로(가령, ECMP) 해싱을 조절한다. 입구 서버(112)가 클라이언트->서버 맵핑을 갖지 않는 입구 서버(112)로 라우팅되는 임의의 패킷 흐름에 대해, 클라이언트->서버 연결에 대해 흐름 추적기 노드로부터 맵핑이 획득될 수 있거나, 대안적으로 도 10a 내지 10g에 도시되는 기법에 따라 새로운 클라이언트->서버 연결이 확립될 수 있다.
Figure pat00038
노드(110A 및 110C) 각각은 에지 라우터(104)로의 BGP 세션을 개방하여 서로를 광고할 수 있다. 두 노드(110A 및 110C) 모두 로드 밸런서 노드(110D)와 노드(110B)에 의해 에지 라우터(104)로 광고되기 때문에, 노드(110B)가 고장 날 때 노드(110A 및 110B)를 에지 라우터(104)로 광고하는 것을 중단할 수 있다는 사실이 에지 라우터(104)로 하여금 이들 두 노드(110)로 패킷을 라우팅하는 것을 중단하게 하지 않는다.
Figure pat00039
적어도 일부 실시예에서, 노드(110A 및 110C)는 현재 노드(110)의 이웃이기 때문에, 서로 건강 체크할 책임을 가질 수 있다. 노드(110B)는, 건강하지 않다고 간주되더라도, 타 노드(110) 중 하나 이상에 의해 여전히 랜덤하게 건강 체크될 수 있다.
Figure pat00040
나머지 건강한 로드 밸런서 노드(110) 중 하나 이상이 노드(110B)가 이전에 흐름 추적한 연결을 흐름 추적할 책임을 가질 수 있다. 예를 들어, 노드(110C) 및/또는 노드(110D)가 노드(110B)가 도 11c 및 11d에 도시된 바와 같이, 주 또는 보조 흐름 추적기였던 하나 이상의 연결에 대해 주 또는 보조 흐름 추적기로서의 역할을 넘겨 받을 수 있다.
Figure pat00041
나머지 건강한 로드 밸런서 노드(110) 중 하나 이상은 노드(110B)에 의해 이전에 건강 체크된 서버 노드(130)를 건강 체크할 책임을 가질 수 있다. 서버 노드(130)는 나머지 로드 밸런서 노드(110)에 의한 건강한 로드 밸런서 노드 리스트(현재는 노드(110B)를 포함하지 않음)로 업데이트된다. 예를 들어, 도 18b에서, 로드 밸런서 노드(110A)는 서버 노드(130C)를 건강 체크하고 업데이트하기 시작하며, 로드 밸런서 노드(110C)는 서버 노드(130B)를 건강 체크하고 업데이트하기 시작한다.
Figure pat00042
에지 라우터(104) 상에서, 고장 난 노드(110B)로부터의 BGP 세션이 결국 만료된다. 대안적으로, 에지 라우터(104)는 노드(110B)가 고장 났다는 것을 인식하면 BGP 세션을 종료할 수 있다.
두 개의 로드 밸런서 노드(110)가 동시에 고장 나거나 폐쇄되는 것이 가능할 수 있다. 두 개의 고장 난 로드 밸런서 노드가 서로 인접해 있지 않는 경우, 고장이 독립적이며, 도 18b에 도시된 방법에 따라 개별적인 단일 노드(110) 고장으로서 핸들링될 수 있다. 그러나 2개의 고장 난 노드가 서로에게 인접한 경우(가령 도 18a에서의 노드(110B 및 110C), 모든 건강한 로드 밸런서 노드(110)(이 예시에서, 노드(110A 및 110D))가 고장을 검출하고 이에 수렴되자마자, 다음에서 비제한적으로 나열된 이벤트들 중 하나 이상이 발생할 수 있다. 이들 이벤트는 반드시 이 순서로 발생하는 것은 아니다.
Figure pat00043
노드(110A)가 노드(110B)에 대한 에지 라우터(104)로의 BGP 세션을 종료한다.
Figure pat00044
노드(110D)가 노드(110C)에 대한 에지 라우터(104)로의 BGP 세션을 종료한다.
Figure pat00045
노드(110A 및 110D)가 에지 라우터(104)와의 BGP 세션을 시작하여 서로를 광고한다.
Figure pat00046
노드(110A 및 110D)가 서로를 건강 체크하기 시작할 수 있다. 노드(110A 및 110D)는 또한 고장 난 노드(110)를 계속 건강 체크할 수 있다.
Figure pat00047
나머지 건강한 노드(110)가 건강한 로드 밸런서 노드 리스트로 서버 노드(130)를 업데이트한다.
Figure pat00048
이들 2개의 노드(110)가 에지 라우터(104)로 서로를 계속 광고할 수 있기 때문에 트래픽이 에지 라우터(104)에서 노드(110B) 및/또는 노드(110C)로 계속 흐를 수 있다. 그러나 이들 BGP 세션은 결국 만료될 것이며, 이에 따라 에지 라우터(104)는 나머지 광고되는 노드(110)로 흐름을 재분산시킬 것이다.
Figure pat00049
노드(110B 및 110C)가 노드(110A 및 110D)가 아직 건강하다고 생각하는 경우, 노드(110B 및 110C)는 이들을 광고할 때 사용하는 에지 라우터(104)와의 BGP 세션을 폐쇄할 수 있다.
연결 게시
도 1을 다시 참조하면, 적어도 일부 실시예에서, 로드 밸런서 구현의 로드 밸런서 노드(110)는 서버(130)로의 클라이언트 TCP 연결에 대한 상태 정보를 유지관리한다. 이 상태 정보는 로드 밸런서 노드(110)가 에지 라우터(104)로부터의 인커밍 클라이언트 트래픽을 TCP 연결에 대한 책임을 갖는 서버 노드(130)로 라우팅할 수 있게 한다. 서버 노드(130) 상의 로드 밸런서 모듈(132)은 이들 각자의 서버(134)로의 활성 TCP 연결의 리스트를 유지관리한다. 연결 게시는 서버 노드(130) 상의 로드 밸런서 모듈(132)이 자신의 활성 클라이언트 TCP 연결들의 리스트를 로드 밸런서 노드(110)로 게시할 수 있게 하는 메커니즘이다. 적어도 일부 실시예에서, 연결 게시 패킷이, 연결 게시 간격이라고 지칭될 수 있는 규칙적인 간격으로 로드 모듈(132)에 의해 형성되고 로드 밸런서 노드(110)로 게시된다.
적어도 일부 실시예에서, 로드 밸런서 노드(110)에 의해 유지되는 연결 상태 정보가 캐시(cache)의 형태로 보여질 수 있고, 특정 연결에 대한 상태 정보를 유지관리하는 것이 상기 연결에 대해 로드 밸런서 노드(110) 상에 리스를 유지관리하는 것으로 보여질 수 있다. 캐시 항목이 갱신되지 않는 한, 로드 밸런서 노드(110)는 클라이언트 데이터 흐름을 데이터 흐름을 핸들링하는 중인 서버 노드(130)로 라우팅할 수 없을 수 있다. 연결 게시 메커니즘이 서버 노드(130)로부터의 현재 연결 상태 정보에 의해, 캐시를, 따라서 로드 밸런서 노드(110) 상의 리스를 주기적으로 갱신하여, TCP 패킷이 클라이언트(160)로부터 적절한 서버 노드(130)로 계속 흐르게 할 수 있다. 클라이언트(160)가 서버(134)로의 TCP 연결을 종료할 때, 상기 연결과 연관된 서버 노드(130) 상의 로드 밸런서 모듈(132)은 자신의 활성 연결 리스트로부터 연결을 폐기하고, 따라서 연결 게시 메커니즘을 통해 TCP 연결을 더는 게시하지 않을 것이다. 따라서 상기 연결과 연관된 로드 밸런서 노드(110)(특히, 상기 연결에 대한 입구 서버(112) 및 주 및 보조 흐름 추적기(116)) 상의 상기 연결에 대한 연결 상태 정보(캐시 항목 또는 항목들))가 더는 갱신되지 않고, 로드 밸런서 노드(110)에 의해 연결이 폐기된다. 적어도 일부 실시예에서, 상기 연결에 대한 캐시 항목 또는 항목들이 메모리가 일부 다른 활성 연결에 대해 요구될 때까지 로드 밸런서 노드(110) 상의 캐시에 유지될 수 있다.
따라서 연결 게시 메커니즘은 입구 서버(112) 및 주 및 보조 흐름 추적기(116) 상의 연결 리스를 주기적으로 또는 비주기적으로 연장하여 클라이언트 트래픽 흐름을 계속 유지할 수 있다. 덧붙여, 연결 게시 메커니즘이 적어도 일부 로드 밸런서 노드(110) 고장으로부터 복원하는 데 도움이 될 수 있다. 클라이언트 연결에 대한 상태 정보를 보유하는 하나 이상의 로드 밸런서 노드(110)가 고장 날 때, 연결 게시에 의해 나머지 로드 밸런서 노드(110)로 제공되는 활성 연결 정보가 일부 경우 상기 연결을 복원하는 데 사용될 수 있다.
연결 게시 메커니즘을 이용해, 서버 노드(130)는 서버(134)와 클라이언트(160) 간 연결의 상태에 대한 권한 있는 출발지(authoritative source)이다. 덧붙여, 서버(134)로의 연결의 폐쇄가 서버 노드(130) 및 로드 밸런서 노드(110) 상의 로드 밸런서 모듈(132)에 의해 수동적으로 핸들링된다. 서버 노드(130)와 로드 밸런서 노드(110) 간에 핸드쉐이킹이 필요하지 않다. 다시 말하면, 로드 밸런서 모듈(132)은 노드에게 특정 연결이 폐쇄됐다고 능동적으로 알리기 위해 로드 밸런서 노드(110)로 메시지를 전송할 필요가 없다. 서버(134)가 연결을 폐쇄할 때, 서버(134)는 연결에 대한 자신의 내부 상태를 비운다. 상기 로드 밸런서 모듈(132)은 서버(134)의 내부 상태를 이용해 연결 게시 패킷을 채울 수 있다. 연결이 더는 서버(134)의 내부 상태에 있지 않기 때문에, 연결이 로드 밸런서 노드(110)에게 게시되지 않는다. 따라서 로드 밸런서 노드(110) 상의 연결에 대한 리스가 만료되고 로드 밸런서 노드(110)가 상기 연결에 대해 수동적으로 잊는다. 연결에 대해 사용된 로드 밸런서 노드(110)의 캐시 내 메모리가 필요에 따라 다른 연결에 대해 사용될 수 있다.
일부 실시예에서, 로드 밸런서 노드(110)에 의해 유지관리되는 연결에 대한 리스가 캐시 내 연결에 대한 항목을 타임-스탬핑하는 것을 포함할 수 있다. 연결 게시 패킷에 의해 연결의 리스가 갱신될 때, 타임스탬프가 업데이트될 수 있다. 연결이 서버 노드(130) 상의 로드 밸런서 모듈(132)에 의해 더는 게시되지 않기 때문에 연결의 리스가 갱신되지 않는 경우, 타임스탬프가 더는 업데이트되지 않는다. 적어도 일부 실시예에서, 레이지 가비지 콜렉션(lazy garbage collection) 방법이 사용될 수 있으며, 여기서 메모리가 요구될 때까지 연결에 대한 항목이 캐시 내에 유지될 수 있다. 예를 들어, 적어도 일부 실시예에서, 캐시 항목 상의 타임스탬프가 리스 갱신 시간 임계값에 비교될 수 있고, 캐시 항목에 대한 타임스탬프가 임계값보다 오래됐다면, 항목은 낡은 것(stale)이며 재사용될 수 있다. 그러나 일부 실시예에서, 낡은 항목이 능동적으로 가비지 콜렉트될 수 있다.
연결 게시 수신자
적어도 일부 실시예에서, 각각의 클라이언트 TCP 연결에 대해, 연결 상태를 유지관리하는 3개의 로드 밸런서 노드(110), 즉 입구 서버(112)로서 역할 하는 노드(110), 주 흐름 추적기(116)로서 역할 하는 노드(110), 및 보조 흐름 추적기(116)로서 역할 하는 노드가 존재한다. 특정 TCP 흐름에 대해, 주 및 보조 흐름 추적기(116)는, 예를 들어, 로드 밸런서 노드(110)에 의해, 일관 해시 함수를 TCP 흐름에 적용하여 주 흐름 추적기(116) 노드 및 이의 후속자 노드를 일관 해시 링에서 찾음으로써, 결정될 수 있다. TCP 흐름에 대한 입구 서버(112)로서 역할 하는 로드 밸런서 노드(110)가 에지 라우터(104)의 내부 다중경로(가령, ECMP) 해시 함수를 기초로 에지 라우터(104)로부터의 흐름에 대한 트래픽을 수신하는 노드(110)다. 노드(110) 고장 또는 추가가 존재하는 경우, 입구 서버(112)로서 역할 하는 로드 밸런서 노드(110)가 활성 TCP 흐름 중 다수에 대해 변경될 수 있고, 적어도 일부 활성 TCP 흐름에 대한 흐름 추적기로서 역할 하는 로드 밸런서 노드(110)가 변경될 수 있다(가령, 도 11a 내지 11d). 서버 노드(130) 상의 서버(132)로의 모든 TCP 흐름에 대해, 상기 서버 노드(130) 상의 로드 밸런서 모듈(132)이, 상기 로드 밸런서 노드(110)로부터 트래픽을 수신하기 때문에, 로드 밸런서 노드(110)들 중 어느 것이 TCP 흐름에 대한 입구 서버(112)인지를 가리키는 상태 정보를 유지관리한다. 그러나 적어도 일부 실시예에서, 로드 밸런서 모듈(132)은 사용되는 일관 해시 함수를 알지 못할 수 있기 때문에, 로드 밸런서 모듈(132)은 어느 로드 밸런서 노드(110)가 TCP 흐름에 대한 주 및 보조 흐름 추적기로서 역할 하는지를 알지 못하고 이를 결정하지 못할 수 있다. 다시 말하면, 적어도 일부 실시예에서, 로드 밸런서 모듈(132)이 일관 해싱을 하지 않는다.
활성 연결 정보 게시
도 19a 및 19b는 적어도 일부 실시예에 따라 연결 기세 기법을 그래픽으로 도시한다. 도 19a는 로드 밸런서 노드로 활성 연결 정보를 게시하는 로드 밸런서(LB) 모듈을 도시한다. 적어도 일부 실시예에서, 각각의 로드 밸런서 모듈(132)은 서버 노드(130) 상의 각각의 활성 TCP 흐름에 대한 정보를 수집하고 연결 게시 패킷을 형성한다. 특정 TCP 흐름에 대한 정보가 흐름에 대한 입구 서버(112)로서 역할 하는 로드 밸런서 노드(110)를 식별하는 정보를 포함한다. 연결 게시 패킷이 준비될 때(가령, 연결 게시 간격에 도달될 때), 로드 밸런서 모듈(132)은 앞서 기재된 바와 같이 서버 노드(130)를 건강 체크하는 로드 밸런서 노드(110)로부터 서버 노드(130)로 주기적으로 전송되는 로드 밸런서 노드(110)로부터 서버 노드(130)로 주기적으로 전송되는 건강한 로드 밸런서 노드(110)의 리스트로부터 로드 밸런서 노드(110)를 랜덤하게 선택한다. 그 후 상기 로드 밸런서 모듈(132)은 선택된 노드(110)로 연결 게시 패킷을 전송한다. 예를 들어, 도 19a에서, 로드 밸런서 모듈(132A)은 하나의 연결 게시 패킷을 로드 밸런서 노드(110A)로 전송했고, 그 후, 또 다른 연결 게시 패킷을 로드 밸런서 노드(110B)로 전송한다.
도 20은 적어도 일부 실시예에 따라, 각각의 로드 밸런서 모듈(132)에 의해 수행될 수 있는 연결 게시 방법의 하이-레벨 흐름도이다. (500)으로 지시되는 바와 같이, 로드 밸런서(LB) 모듈(132)은 각각의 서버 노드(130) 상의 모든 활성 TCP 흐름에 대한 연결 게시 항목을 생성한다. 적어도 일부 실시예에서, 로드 밸런서 모듈(132)은 서버 노드(130) 상의 서버(134)가 핸들링하는 활성 TCP 연결의 세트를, 가령, 서버 노드(130) 상의 /proc/net/tcp로부터 불러온다. 모든 활성 TCP 연결에 대해, 로드 밸런서 모듈(132)은 TCP 흐름에 대한 입구 서버(112)로서 역할 하는 로드 밸런서 노드(110)를 (가령, 로컬하게 유지관리되는 활성 연결 테이블에서) 찾고 연결에 대한 TCP 튜플(가령, 4-튜플은 클라이언트 IP 주소, 클라이언트 포트, 서버(공중) IP 주소, 및 서버 포트로 구성됨) 및 상기 연결에 대한 입구 서버(112)를 가리키는 연결 게시 항목을 생성한다. 각각의 로드 밸런서 모듈(132)은 상기 연결에 대한 패킷이 온 마지막 로드 밸런서 노드(110)를 지시하는 각각의 활성 TCP 연결에 대한 정보를 유지관리하고, 이 정보는 로드 밸런서 모듈(132)에 의해 사용되어 각각의 활성 연결에 대한 입구 노드(110)를 식별할 수 있다.
(502)로 지시되는 바와 같이, 로드 밸런서 모듈(132)은 연결 게시 패킷(각각의 활성 TCP 연결에 대한 하나의 항목을 갖고 하나 이상의 연결 게시 항목을 포함)이 전송될 로드 밸런서 노드(110)를 랜덤하게 선택한다. 적어도 일부 실시예에서, 로드 밸런서 모듈(132)은 연결 게시 패킷이 전송될 준비가 됐다고 결정할 때 로드 밸런서 모듈(110)은 랜덤하게 선택될 수 있다. 적어도 일부 실시예에서, 연결 게시 간격에 따라 이 결정이 이뤄진다. 비제한적 예를 들면, 연결 게시 간격이 100밀리초(ms) 또는 1초일 수 있다. 적어도 일부 실시예에서, 로드 밸런서 모듈(110)은 로드 밸런서 노드(110)들 중 하나로부터 이전에 수신된 건강한 로드 밸런서 노드(110)의 리스트로부터 선택된다. (504)로 지시되는 바와 같이, 로드 밸런서 모듈은 연결 게시 패킷을 선택된 로드 밸런서 노드(110)로 게시한다. 적어도 일부 실시예에서, 연결 게시 패킷은 무상태 패킷, 가령, UDP 패킷이다. 일부 실시예에서, 연결 게시 패킷은 패킷을 타깃 로드 밸런서 노드(110)로 전송하기 전에 압축될 수 있다. 적어도 일부 실시예에서, 연결 게시 정보가 둘 이상의 패킷으로 타깃 로드 밸런서 노드(110)에게 전송될 수 있다.
요소(504)에서 요소(500)로 복귀하는 화살표로 지시되는 바와 같이, 로드 밸런서 모듈(132)은 연결 게시 패킷을 연속적으로 구축하고, 랜덤 노드(110)를 선택하며, 패킷을 선택된 노드로 전송할 수 있다. 앞서 언급된 바와 같이, 이는 연결 게시 간격에 따라 수행되어, 로드 밸런서 노드(110)가 현재 연결 정보로 비교적 규칙적으로 리프레시되어, 로드 밸런서 노드(110) 상에 연결 리스를 유지할 수 있다.
적어도 일부 실시예에서, 연결 게시 패킷은 로드 밸런서 모듈에 의해 로드 밸런서 노드(110)로 랜덤하게 분산되기 때문에, 연결 게시 패킷을 수신하는 로드 밸런서 노드(110)가 활성 연결 정보를 연결 게시 패킷으로 상기 연결에 대한 올바른 입구/주/보조 노드(110)로 분산시키는 책임을 가진다. 도 19b 및 21 및 22는 적어도 일부 실시예에서 사용될 수 있는 활성 연결 정보를 분산시키기 위한 방법을 도시한다.
도 19b는 적어도 일부 실시예에 따라 로드 밸런서 노드(110)들 간에 활성 연결 정보를 분산시키는 것을 도시한다. 로드 밸런서 노드(110)가 로드 밸런서 모듈(132)로부터 연결 게시 패킷을 수신할 때, 상기 로드 밸런서 노드(110)는 여기서 지시되는 각각의 TCP 흐름에 대한 정보를 분석하여, 상기 흐름에 대한 입구 노드 및 주 및 보조 흐름 추적기 노드를 결정할 수 있다. 로드 밸런서 노드(110)가 흐름에 대한 이들 역할 중 하나의 역할을 수행하는 경우, 로드 밸런서 노드(110)는 (가령, 자신의 상태 정보의 캐시를 업데이트함으로써) 상기 흐름에 대한 정보를 소비한다. 적어도 일부 실시예에서, 또한 로드 밸런서 노드(110)는 흐름에 대한 정보를 흐름에 대한 다른 역할을 수행 중인 하나 이상의 타 노드(110)로 전송될 패킷(들)에 넣을 수 있다. 연결 게시 패킷에 의해 지시되는 나머지 흐름에 대해, 로드 밸런서 노드(110)는 활성 연결 정보를 둘 이상의 더 작은 패킷으로 분할하고 각각의 패킷을 하나 이상의 타 로드 밸런서 노드(110)로 전송한다. 예를 들어, 적어도 일부 실시예에서, 하나 이상의 흐름에 대한 활성 연결 정보를 포함하는 패킷이 흐름(들)에 대한 입구 서버(112), 주 흐름 추적기(116A), 및 보조 흐름 추적기(116B) 로서 역할 중인 로드 밸런서 노드(110)로 전송될 수 있다.
도 21은 적어도 일부 실시예에 따라, 연결 게시 패킷으로 수신된 활성 연결 정보를 타깃 로드 밸런서 노드(110)로 분산시키는 방법의 흐름도이다. (520)으로 지시되는 바와 같이, 로드 밸런서 노드(110)는 로드 밸런서 모듈(132)로부터 연결 게시 패킷을 수신한다. 상기 로드 밸런서 모듈(132)은 도 19a 및 20을 참조하여 앞서 기재된 바와 같이, 패킷을 생성했고, 패킷을 수신할 로드 밸런서 노드(110)를 선택했다. 연결 게시 패킷은 패킷이 온 서버 노드(130)(가령, 서버 노드(130) 상의 로드 밸런서 모듈(132)의 IP 주소)를 식별하는 정보 및 활성 TCP 연결을 식별하는 항목들의 리스트를 포함할 수 있다(가령, 4-튜플은 각각의 연결에 대한 클라이언트 IP 주소, 클라이언트 포트, 서버(공중) IP 주소, 및 서버 포트로 구성됨).
도 21의 요소(522-530)에서, 로드 밸런서 모듈(110)은 수신된 연결 게시 패킷에서 지시되는 활성 TCP 연결 정보를 반복적으로 프로세싱한다. (522)로 지시되는 바와 같이, 로드 밸런서 노드(110)는 패킷 내 다음 TCP 흐름에 대한 항목을 분석하여 각자의 TCP 흐름에 대한 입구 노드(110) 및 주 및 보조 흐름 추적기 노드(110)를 결정할 수 있다. 적어도 일부 실시예에서, 로드 밸런서 노드(110)는 연결 게시 항목으로부터 입구 노드(110)의 신원을 획득한다. 적어도 일부 실시예에서, TCP 흐름에 대한 주 및 보조 흐름 추적기 노드(110)는 일관 해시 함수에 따라 결정될 수 있다. (524)에서, 로드 밸런서 노드(110)가 검사되는 TCP 흐름에 대한 역할들 중 한 역할을 수행하는 중인 경우, (526)에서 로드 밸런서 노드(110)는 가령 상태 정보의 캐시를 업데이트함으로써 흐름에 대한 정보를 소비한다. 지시되는 바와 같이, (528)에서, 로드 밸런서 노드(110)는 TCP 흐름에 대한 연결 게시 항목을 또 다른 로드 밸런서 노드(110)로 전송될 구성된 패킷에 추가할 수 있다. (530)에서, 연결 게시 패킷에서 흐름에 대한 연결 게시 항목이 더 존재하는 경우, 상기 방법은 (522)으로 복귀하여, 다음 항목을 프로세싱할 수 있다. 달리 말하면, 로드 밸런서 노드는 (532)에서 지시되는 바와 같이 패킷에 대한 타깃 로드 밸런서 노드(110)로 본래 연결 게시 패킷으로부터의 연결 게시 항목의 서브세트를 각각 포함하는 새로 구성된 패킷을 전송한다. 적어도 일부 실시예에서, 타깃 로드 밸런서 노드(110)로 전송된 패킷이 무상태 패킷, 가령, UDP 패킷이다. 일부 실시예에서, 상기 패킷은 패킷을 타깃 로드 밸런서 노드(110)로 전송하기 전에 압축될 수 있다.
따라서, 적어도 일부 실시예에서, 도 21의 요소(522-528)에서, 흐름 추적기 노드(110)는, 수신된 연결 게시 패킷 내 연결 게시 항목으로부터 (522)에서 결정된 정보에 따라 타 노드(110)들 중 특정 하나의 노드에 전송될 하나 이상의 패킷(가령, UDP 패킷)을 구성한다. 적어도 일부 실시예에서, 또 다른 노드(110)로 전송된 패킷이 타깃 노드(110)가 입구 노드(110), 주 흐름 추적기 노드(110), 또는 보조 흐름 추적기 노드(110)로서 역할 하는 TCP 흐름에 대한 항목을 포함한다. 일부 실시예에서, 특정 로드 밸런서 노드(110)는 TCP 흐름에 대한 입구 노드와 주 흐름 추적기 노드 모두로서 역할 하거나, TCP 흐름에 대한 입구 노드와 보조 흐름 추적기 노드 모두로서 역할 할 수 있다.
도 22는 적어도 일부 실시예에 따라, 타깃 로드 밸런서 노드(110)로 연결 게시 패킷으로 수신된 활성 연결 정보를 분산시키기 위한 대안적 방법을 도시한다. (550)으로 지시되는 바와 같이, 로드 밸런서 노드(110)는 로드 밸런서 모듈(132)로부터 연결 게시 패킷을 수신한다. 이 방법에서, (552)로 지시되는 바와 같이, 로드 밸런서 모듈(110) 상의 프로세스가 패킷 내 연결 게시 항목을 분석하고 따라서 수신된 패킷을 하나 이상의 더 작은 패킷으로 분할한다. 로드 밸런서 모듈(110)은 이 공정 동안 흐름 정보를 로컬하게 소비하지 않는다. 연결 게시 패킷이 하나 이상의 패킷으로 쪼개지면, 패킷은 (554-560)으로 지시되는 바와 같이 프로세싱된다. (554)에서, 패킷에 대한 타깃 노드(110)가 이 로드 밸런서 노드(110)인 경우, (556)에서 지시되는 바와 같이, 로드 밸런서 노드(110)는 패킷을 로컬하게 소비한다. 이와 달리, 패킷이 타깃 로드 밸런서 노드(110)로 전송된다. (560)에서, 처리될 패킷이 더 있는 경우, 방법이 (554)으로 복귀한다. 그렇지 않다면, 방법은 완료된다.
따라서 로드 밸런서 모듈(132)로부터 연결 게시 패킷을 수신하는 로드 밸런스 노드(110)는 연결 게시 패킷을 타 로드 밸런서 노드(110) 중 특정 하나에 특정된 둘 이상의 더 작은 패킷으로 분할하고 이에 따라 로드 밸런서 노드(110)에 의해 현대 핸들링되는 임의의 TCP 흐름에 대한 흐름 정보를 내부적으로 소비하면서, 패킷을 분산시킬 수 있다. 그동안, 타 로드 밸런서 노드(110)는 로드 밸런서 모듈(132)로부터 연결 게시 패킷을 수신하고, 연결 게시 항목을 복수의 더 작은 패킷으로 분할시키며, 더 작은 패킷을 타깃 노드(110)로 전송함으로써 노드(110) 간에 활성 연결 정보를 분산시킬 수 있다.
연결 게시 트리거
적어도 일부 실시예에서, 하나 이상의 서로 다른 이벤트에 의해 로드 밸런서 모듈(132) 상에 연결 게시가 트리거될 수 있다. 앞서 언급된 바와 같이, 일부 실시예에서, 연결 게시 패킷이 생성되고 연결 게시 간격에 따라, 가령, 100ms 또는 1초 간격으로 랜덤하게 선택된 로드 밸런서 노드(110)로 전송되어, 로드 밸런서 노드(110) 상의 TCP 연결에 대한 리스를 갱신할 수 있다. 일부 실시예에서, 로드 밸런서 노드(110)의 구성원의 변경이 즉각적인 연결 게시 이벤트를 트리거할 수 있다. 적어도 일부 실시예에서, 로드 밸런서 모듈(132)은 각각의 서버 노드(130)를 건강 체크하는 로드 밸런서 노드(110)들 중 하나로부터 전송된 건강한 로드 밸런서 노드(110)의 리스트로부터의 변경에 대해 학습할 수 있다. 리스트에 따라 변경(삭세 또는 추가)을 검출하면, 로드 밸런서 모듈(132)은 연결 게시 패킷을 생성하고 로드 밸런서 노드(110)로 전송하여, 변경에 의해 영향 받는 TCP 연결이 로드 밸런서 노드(110)에 의해 더 빠르게 복원될 수 있도록 할 수 있다.
패킷 루프 방지
연결 게시 패킷을 프로세싱하면서 로드 밸런서 레이어 구성원이 변경된 경우, 연결 게시 패킷 루프가 발생할 수 있다. 제1 노드(110)가 로드 밸런서 모듈(132)로부터 연결 게시 패킷을 수신하고 더 작은 패킷을 제2 노드(110)로 전송할 수 있다. 그러나 구성원이 변경된 경우, 제2 노드(110)는 패킷이 제1 노드(110)로 이동해야 한다고 결정할 수 있으며, 따라서 제1 노드(110)로 패킷을 전달할 수 있다. 적어도 일부 실시예에서, 이 루프가 발생하는 것을 막기 위해, 로드 밸런서 모듈(132)로부터 수신된 연결 게시 패킷, 로드 밸런서 노드(110)로부터 수신된 연결 게시 패킷에 대해 서로 다른 포트 번호가 사용될 수 있고, 로드 밸런서 노드(110)는 타 로드 밸런서 노드(110)로부터 수신된 연결 게시 패킷을 재분산시키지 않는다.
연결 게시 패킷 분산 대안예
앞서 기재된 연결 게시 방법에서, 로드 밸런서 모듈(132)이 연결 게시 패킷이 전송되는 로드 밸런서 노드(110)를 랜덤하게 선택한다. 그러나 일부 실시예에서, 그 밖의 다른 방법이 로드 밸런서 노드(110)를 선택하도록 사용될 수 있다. 예를 들어, 일부 실시예에서, 로드 밸런서 노드(132)는 활성 TCP 흐름 중 하나 이상을 핸들링하고 타깃 입구 노드(들)(110)로 패킷(들)을 전송한 특정 입구 노드(110)로 각각 타깃팅되는 하나 이상의 연결 게시 패킷을 구성할 수 있다. 그 후 입구 노드(들)(110)는 연결에 대한 주 및 보조 흐름 추적기로 활성 연결 정보를 재분산시킬 것이다. 또 다른 예를 들면, 일부 실시예에서, 연결 게시 패킷을 단일, 랜덤하게 선택된 노드(110)로 전송하는 대신, 연결 게시 패킷은 로드 밸런서 모듈(132)에 의해 건강한 노드(110)들 중 둘 이상, 또는 건강한 노드(110) 모두로 전송될 수 있다.
로드 밸런서 노드 아키텍처
도 23은 적어도 일부 실시예에 따라 로드 밸런서 노드(110)에 대한 시적 소프트웨어 스택 아키텍처를 도시하나 여기에 한정시키려는 의도는 아니다. 이 예시적 소프트웨어 스택 아키텍처에서, 로드 밸런서 노드(110)는 로드 밸런서 서버 네이티브 코드(1106) 및 코어 패킷 프로세싱 코드(1108), 가령, Intel™ 데이터플레인 개발 키트(Dataplane Development Kit)(DPDK) 기법 코드를 포함할 수 있는 네이티브 코드의 레이어를 관리하기 위해 자바 네이티브 인터페이스(Java Native Interface)(JNI™)(1104) 기법을 이용하는 단일 Java™ 기법 프로세스(1102) 내에서 실행된다. 네이티브 코드는 2개의 네트워크 인터페이스 제어기(NIC(1114A 및 1114B))로 인터페이싱할 수 있다. 제1 NIC (NIC(1114A))는 "노스(north)"를 면할 수 있다, 즉, 에지 라우터(104)를 향한다. 제2 NIC (NIC(1114B))는 "사우스(south)"를 면할 수 있고, 즉, 서버 노드(130)를 향한다. 적어도 일부 실시예에서, NIC(1114A 및 1114B)는 TCP 스택을 유지관리하지 않을 수 있다. 따라서 적어도 일부 실시예는 로드 밸런서 노드(110)가 제어 평면을 통해 프로세스와 통신할 수 있도록 하고 그 반대로 가능하게 하는 TCP 연결을 지원하는 제3 NIC(1114C)를 포함할 수 있다. 대안적으로, 일부 실시예에서, 제1, 노스-면 NIC(1114A) 및 제2, 사우스-면 NIC(111B)만 로드 밸런서 노드(110)에서 구현될 수 있고, 제2, 사우스-면 NIC(1114B)는 로드 밸런서 노드(110)가 제어 평면을 통해 프로세스와 통신할 수 있도록 하는 TCP 스택을 구현할 수 있다. 또한 로드 밸런서 노드(110)는 OS 기법 소프트웨어(1112) 및 JNI(1104) 기법에 추가로, 운영 체제(OS) 기법 소프트웨어(1112), 가령, Linux™ 커넬, 및 Java Virtual Machine (JVM™) 기법 소프트웨어(1110) 레이어를 포함한다.
적어도 일부 실시예에서, 분산 로드 밸런싱 시스템에서의 로드 밸런서 노드(110) 각각이 높은 패킷 레이트로 많은 데이터 흐름을 동시에 프로세싱할 필요가 있을 수 있다. 적어도 일부 실시예에서, 필요한 처리율 레벨을 획득하기 위해, 로드 밸런서 노드(110)가 고성능 패킷 프로세싱을 위한 Intel™ 데이터플레인 개발 키트(Dataplane Development Kit)(DPDK) 기법을 활용할 수 있다. DPDK 기법은, 사용자공간 프로그램이 네트워크 인터페이스 제어기(NIC)로 및 네트워크 인터페이스 제어기로부터 직접 패킷을 쓰고/읽게 할 수 있으며, (라이너스(Linus) ixgbe 기반 NIC 드라이버의 경우를 제외하고) 리눅스(Linux) 커넬 네트워킹 스택의 많은 레이어를 우회할 수 있다. 패킷 프로세싱에 대한 DPDK 방식이 바쁜 루프에서 NIC 하드웨어에게 직접 폴(poll)하는 전용 CPU 코어를 위해 인터럽트 핸들러-기반 입력을 거절한다. 이 방식에 의해, 바쁜 루프에서 전용 CPU 코어를 지속적으로 실행시킴으로써 증가하는 열 출력과 맞바꾼 훨씬 더 높은 패킷 레이트가 가능할 수 있다. DPDK 기법은 또한 CPU 코어 관리, 락-프리 큐(lock-free queue), 메모리 풀(memory pool), 및 동기화 기본형(synchronization primitive)을 포함하는 패킷 프로세싱을 위한 툴을 제공할 수 있다. 도 24에 도시된 바와 같이, DPDK 기법에서, 전용 CPU 코어(600)가 각각의 특정 작업에 대해 사용될 수 있고, 비차단 큐(non-blocking queue)(602)를 이용해 작업이 하나의 CPU 코어(600A)에서 또 다른 CPU 코어(600B)로 전달된다.
DPDK 큐(602)는 고속 2의 거듭제곱 링 버퍼를 이용해 구현되고, 단일 그리고 복수의 제조자/소비자 변형을 지원할 수 있다. 복수의 제조자/소비자 변형이 액세스를 동기화하기 위해 CAS(compare-and-swap) 루프를 포함하기 때문에 진정으로 락-프리가 아니다. 모든 패킷 버퍼 메모리가 메모리 풀에 사전-할당될 수 있어서, 버퍼로의 포인터만 큐(602)에서 읽히고 써진다. 메모리 풀이 큐로서 구현될 수 있고, 메모리 채널 및 랭크에 걸쳐 메모리를 분산시키도록 최적화되며, 비-균일 메모리 액세스(NUMA) 최적화된 할당을 지원할 수 있다. 적어도 일부 실시예에서, 패킷 버퍼는 방법, 가령, 충분한 헤드룸 및 테일룸을 각각의 패킷 버퍼에 과다-할당하여 버퍼 복사본을 필요로 하지 않으면서 외부 네트워크 레이어 헤더를 추가/제거할 수 있는 캡슐화/역캡슐화 동작을 지원하는 Mbuf 패러다임을 사용할 수 있다.
로드 밸런서 노드(110)의 적어도 일부 실시예에서, DPDK 기법을 활용하는 코어 패킷 프로세싱 아키텍처가 구현될 수 있다. 각각의 로드 밸런서 노드(110)가 코어 패킷 프로세싱 아키텍처에 따라 구현되는 적어도 하나의 멀티코어 패킷 프로세서를 포함할 수 있다. 상기 코어 패킷 프로세싱 아키텍처가 멀티코어 패킷 프로세서의 큐 및 코어를 통과하는 패킷 흐름에 대해 단일 제조자 / 단일 소비자 패러다임을 이용할 수 있다. 이 패러다임에서, 각각의 큐가 하나의 유일한 코어로 입력하고, 각각의 코어는 패킷을 공급하는 타 코어 각각에 대해 하나의 유일한 코어로 출력한다. 덧붙여, 멀티코어 패킷 프로세서에서 코어에 의해 사용되는 메모리가 공유되지 않고, 각각의 코어는 자신 고유의 개별적인 메모리 영역을 가진다. 따라서, 코어들 간에 어떠한 메모리 또는 큐 공유가 없고, 어떠한 메모리 또는 큐 경합도 없으며, 메모리 또는 큐 공유 메커니즘, 가령, 소유권 요청(RFO) 또는 CAS(compare-and-swap)에 대한 필요성이 없다. 도 25 및 26은 코어 패킷 프로세싱 아키텍처에 따라 구현되는 예시적 멀티코어 패킷 프로세서를 도시한다.
도 25는 적어도 일부 실시예에 따라 데이터 흐름을 프로세싱하기 위한 DPDK 기법을 활용하는 코어 패킷 프로세싱 아키텍처에 따라 구현되는 예시적 멀티코어 패킷 프로세서를 도시한다. 코어 패킷 프로세싱 아키텍처는 단일 제조자 / 단일 소비자 패러다임에 따르는 멀티코어 패킷 프로세서로서 구현될 수 있다. 적어도 일부 실시예에서, 도 23에 도시된 바와 같이, 로드 밸런서 노드(110) 각각은 2개의 네트워크 인터페이스 제어기(NIC) - 경계 네트워크/에지 라우터(104)에 면하는 노스-면 NIC(1114A) 및 생성 네트워크/서버 노드(130)에 면하는 사우스-면 NIC(1114B)를 가진다. 적어도 일부 실시예에서, NIC(1114)는 10Gpbs NIC일 수 있다. 로드 밸런서 노드(110)를 통해 흐르는 패킷들의 대부분이 이들 2개의 NIC 중 하나(NIC(1114A 또는 1114B)) 상에서 수신되고, 프로세싱(가령, 캡슐화 또는 역캡슐화)되고, 다른 NIC(NIC(1114B 또는 1114A)) 밖으로 전송된다.
도 25를 참조하면, 적어도 일부 실시예에서, 로드 밸런서 노드(110)는 각각의 NIC(1114)에 대해 2개의 CPU 코어, 수신(RX) 코어(610), 및 송신(TX) 코어(630)을 스핀업한다. 또한 상기 로드 밸런서 노드(110)는 두 NIC(1114) 모두에 대해 두 방향 모두로 패킷을 프로세싱하는 복수의 작업자 코어(worker core)(620)를 스핀업하며, 이 예시에서, 4개의 작업자 코어(620A 내지 620D)가 사용된다. 수신 코어(610)는 NIC(1114)에 도달할 때 자신의 입력 큐로부터 인커밍 패킷의 배치를 읽고, 상기 패킷을 각각의 패킷에 대해 작업의 벌크를 수행하는 작업자 코어(620)로 분산시키며, 이때 각각의 수신 코어(610)는 각각의 작업자 코어(620)에 대해 각자의 작업자 입력 큐(612)로 패킷을 공급한다. 적어도 일부 실시예에서, 수신 코어(610)는 각각의 인커밍 패킷에 대해 (앞서 기재된 바와 같이 에지 라우터(104)에 의해 사용될 수 있는 흐름당 해싱된 다중경로 라우팅 기법과 유사하게) 레이어 4 "흐름-해시" 기법을 수행하여, 임의의 특정 클라이언트 연결(IP 주소 및 포트에 의해 구별됨)이 동일한 작업자 코어(620)에 의해 프로세싱될 것임을 보장하면서 패킷을 작업자 코어(620)로 분산시킬 수 있다. 이는 각각의 작업자 코어(620)가 항상 동일한 패킷 서브세트를 볼 수 있음을 의미하며, 작업자 코어(620)에 의해 관리되는 상태 데이터에 대한 경합을 제거함으로써 어떠한 록(lock)도 필요하지 않게 된다. 수신된 패킷으로의 포인터가 작업자 코어(620)가 새 입력에 대해 지속적으로 모니터링하는 작업자 큐(622)에 걸쳐 분산될 수 있다. 상기 작업자 코어(620)는 각각의 연결에 대한 상태(가령, 할당된 서버 노드(130))를 관리할 책임을 가지며, 패킷을 이들의 아웃바운드 큐(632) 중 하나로 전달하기 전에 패킷에 대해 UDP 캡슐화 또는 역캡슐화를 수행할 수 있다. 송신 코어(630)는 작업자 코어(620) 아웃바운드 큐(632)를 통해 사이클링하고 출력 패킷이 큐(632) 상에서 나타나는 것처럼 출력 패킷을 이의 대응하는 NIC(1114)에 쓴다.
도 26은 적어도 일부 실시예에 따라, 데이터 흐름을 프로세싱하기 위한 DPDK 기법을 활용하는 코어 패킷 프로세싱 아키텍처에 따라 구현되는 또 다른 예시적 멀티코어 패킷 프로세서를 도시한다. 코어 패킷 프로세싱 아키텍처는 단일 생산자 / 단일 소비자 패러다임에 따라 멀티코어 패킷 프로세서로서 구현될 수 있다. 적어도 일부 실시예에서, 고처리율 클라이언트 TCP 흐름을 프로세싱하는 것에 추가로, 로드 밸런서 노드(110) 상의 DPDK 코어 아키텍처는 또한 그 밖의 다른 프로토콜, 가령, ARP, DHCP, 및 BGP에 대해 노스- 및 사우스-면 NIC(1114) 상에서 패킷을 전송 및 수신하도록 사용될 수 있다. 도 26에 도시된 실시예에서, 작업자 코어(620A)는 이들 그 밖의 다른 프로토콜에 대해 패킷을 핸들링하도록 특화된다. 이 작업 코어(620A)는 "저속(slow)" 작업자 코어라고 지칭될 수 있는데, 왜냐하면 이들 패킷의 프로세싱이 일반적으로 클라이언트 TCP 흐름보다 느린 속도로 발생하기 때문이며, 반면에, 클라이언트 TCP 흐름만 프로세싱하는 그 밖의 다른 작업자 코어(620B-620D)는 고속 작업자 코어라고 지칭될 수 있다. 각각, 노스-면 및 사우스-면 NIC(1114) 상에서 인커밍 패킷을 핸들링하는 수신 코어(610A 및 610B)는 저속 작업자 코어(620A)에 의해 핸들링될 패킷을 식별하고 상기 패킷을 저속 작업자 코어(620A)를 위한 입력 큐(622)로 지향시킬 수 있다. 또한 저속 작업자 코어(620A)는 자바(Java)/JNI에 의해 생성된 패킷에 대해 입력 큐(622)를 모니터링하고 자바(Java)/JNI로의 출력 패킷에 대해 출력 큐(634)를 모니터링할 수 있다. 저속 작업자 코어(620A)는 또한 고속 작업자 코어(620B 내지 620D) 각각에 대해 입력 큐(622)로 출력하여, 자속 작업자 코어(620A)가 패킷을 고속 작업자 코어(620B 내지 620D) 각각으로, 가령, 연결 게시 패킷을 전송할 수 있다. 저속 작업자 코어(620A)는 또한 송신 코어(630A 및 630B) 각각으로 공급하기 위한 아웃바운드 큐(632)를 가진다.
적어도 일부 실시예에서, 각각의 고속 작업자 코어(620B 내지 620D)의 제3 입력 큐(622)는 저속 작업자 코어(620A)의 출력 큐이다. 적어도 일부 실시예에서, 이 제3 입력 큐(622)는, 예를 들어, 각각 연결 상태 정보를 포함하는 연결 게시 패킷을 고속 작업자 큐(620B 내지 620D)에 의해 수신 및 프로세싱하기 위해 사용될 수 있다. 이들 연결 게시 패킷 중 적어도 일부에 대해, 송신 코어(630)로 어떠한 출력도 존재하지 않을 수 있다. 대신, 패킷 내 연결 상태 정보가 고속 작업자 코어(620)에 의해, 가령, 각각의 고속 작업자 코어(620)가 유지관리하는 하나 이상의 패킷 흐름에 대해 저장된 상태를 업데이트함으로써, 소비될 수 있다. 따라서 고속 작업자 코어(620B 내지 620D)로 입력하는 저속 작업자 코어(620A)로부터의 출력 큐가 고속 작업자 코어의 저장된 상태를 업데이트하기 위해 수신 코어(610)로부터 직접 입력 큐(622)와 다른 경로를 제공할 수 있다.
적어도 일부 실시예에서, 도 25 및 26의 멀티코어 패킷 프로세서는 인커밍 패킷을 필터링하고 유효한 패킷만 프로세싱 및 출력한다. 예를 들어, 적어도 일부 실시예에서, 수신 코어(610)는 어떠한 작업 코어(620)에 의해서도 지원되지 않는 프로토콜을 갖는 패킷을 필터링 제거하고 따라서 상기 패킷을 작업 코어(620)로 전송하지 않을 수 있다. 적어도 일부 실시예에서, 작업 코어(620)는, 패킷을 프로세싱할 때, 각각 먼저 자신 각자의 작업 입력 큐(622)로부터 읽힌 패킷을 분석하여, 패킷이 추가 프로세싱에 대해 수락되어 송신 코어(630)로 출력될 것인지 여부를 결정하고, 수락되는 패킷의 프로세싱 및 송신 코어(630)로의 출력만 완료할 수 있고, 수락되지 않는 패킷은 폐기될 수 있다. 예를 들어, 작업자 코어(620)는 각각의 패킷에 대해 주소 정보를 보고 로드 밸런싱되는 중인 유효 주소를 타깃으로 삼는 패킷만 수락할 수 있으며, 그 밖의 다른 임의의 패킷을 폐기한다.
경계 게이트웨이 프로토콜(BGP) 데이터 핸들링
적어도 일부 실시예에서, 코어 아키텍처 안팎으로의 BGP 클라이언트와 연관된 패킷 흐름이 다음과 같이 핸들링될 수 있다. NIC(1114A 및 1114B)가 리눅스(Linux) 커넬에 바운드되지 않기 때문에, 에지 라우터(104)로의 TCP 연결이 도 26에 도시된 코어 아키텍처에 의해 인터셉트되고, BGP 패킷을 출력 큐(634)를 통해 자바(Java) 공간으로 전달하는 저속 작업자 코어(622A)에 의해 프로세싱된다. 이들 TCP 패킷은 BGP z클라이언트로 전달되기 전에 로드 밸런서 노드(110) 상의 하나 이상의 모듈에 의해 추가 프로세싱되는데, 가령, 리눅스(Linux) 커넬에 의해 프로세싱되어 TCP 연결을 관리하고 TCP 스트림으로 패킷을 효과적으로 변환할 수 있다. 이 디자인에 의해, BGP 클라이언트는 표준 자바(Java) TCP 소켓 라이브러리를 이용해 써질 수 있다.
도 27은 적어도 일부 실시예에 따르는 로드 밸런서(LB) 노드 프로세스(650)에 의한 인커밍 BGP TCP 패킷의 프로세싱을 도시한다. 에지 라우터(104)로부터의 패킷이 노스-면 NIC(640)에 도착하고 수신 코어(652)를 위한 입력 큐(640) 내로 들어간다. 수신 코어(652)는 큐(640)로부터, BGP 패킷으로서 식별된 패킷을 읽고 패킷을 저속 작업자 코어(656)를 위한 입력 큐(654) 상에 놓는다. 저속 작업자 코어(656)는 패킷을 검증하고 이를 JNI 출력 큐(658) 상에 놓는다. JNI 패킷 수신기(660)는 JNI를 통해 큐(658)로부터 패킷을 읽고, 출발지/도착지 주소를 맹글링하며, 상기 패킷을 원시 소켓(raw socket)(644)에 쓴다. 리눅스(Linux) 커넬(646)은 원시 패킷을 수신하고, TCP 프로토콜에 따라 이를 핸들링하며, 상기 TCP 소켓 입력스트림(InputStream)에 페이로드를 첨부한다. 패킷으로부터의 데이터가 BGP 클라이언트(662) 내 자바(Java) TCP 소켓으로 전달된다.
도 28은 적어도 일부 실시예에 따라 로드 밸런서(LB) 노드 프로세스(650)에 의한 아웃고잉 BGP TCP 패킷의 프로세싱을 도시한다. 상기 BGP 클라이언트(662)는 데이터를 리눅스(Linux) 커넬(646)의 자바(Java) TCP 소켓에 쓴다. 상기 리눅스(Linux) 커넬(646)은 TCP 프로토콜에 따라 데이터를 핸들링하고 데이터를 TCP 패킷(들)로 변환한다. 적어도 일부 실시예에서, 상기 TCP 패킷(들)은 127.x.x.x 아이피표(iptable) 규칙에 부합한다. 상기 TCP 패킷(들)은 출력 큐(648), 가령, 넷필터 LOCAL_OUT 큐 상에 놓인다. JNI를 통해 큐(648)를 모니터링하는 JNI 패킷 수신기(670)의 자바(Java) 스레드가 TCP 패킷(들)을 수신하고 각각의 NF_STOLEN를 마킹하여 커넬(646)이 이들에 대해 잊게 만들 수 있다. 자바(Java) 스레드가 출발지/도착지 주소를 맹글링하고 JNI를 통해 패킷(들)을 저속 작업자 코어(656)를 위한 JNI 입력 큐(672)로 추가한다. 상기 저속 작업자 코어(656)는 TCP 패킷(들)을 자신의 JNI 입력 큐(672)로부터 수신하고 패킷들을 노스-면 NIC(640) 송신 코어(666)를 위한 아웃바운드 큐(664) 상에 배치한다. 송신 코어(666)은 자신의 입력 큐(664)로부터 TCP 패킷(들)을 읽고 이들을 노스-면 NIC(640)에 쓴다. 상기 TCP 패킷은 NIC(640)에 의해 에지 라우터(104)로 전송된다.
분산 로드 밸런서 시뮬레이션 및 시험
본원에 기재된 로드 밸런서는 많은 독립적인 구성요소(가령, 라우터, 로드 밸런서 노드, 로드 밸런서 모듈 등)의 상호대화를 필요로 하는 분산 시스템이다. 분산 구성요소, 로직 및 프로토콜의 시험을 수행하기 위해 그리고 노드 고장, 메시지 폐기(message drop) 및 지연 같은 시나리오를 시뮬레이션하기 위해, 분산 로드 밸런서가 단일 프로세스로 실행될 수 있게 하는 시험 시스템의 실시예가 기재되며, 여기서, 복합적인 네트워크 토폴로지(가령, 생성 네트워크)에서 코드가 복수의 호스트로 배치될 필요 없이 상호대화가 시험될 수 있다. 이를 이루기 위해, 복수의 로드 밸런서 구성요소가 하나의 단일 프로세스로 구성되고 실행될 수 있게 하는 메시지 버스라고 지칭되는 소프트웨어 메커니즘이 기재되며, 상기 단일 프로세스는 단일 호스트 시스템 상에서 실행될 수 있다. 메시지 버스 메커니즘에 의해, 분산 로드 밸런서 시스템이, 가령, 단일 호스트 시스템 상에서 단일 프로세스로서 시험될 수 있고, 로드 밸런서 구성요소(가령, 로드 밸런서 노드 및 로드 밸런서 모듈)와 관련해, 이들은 실제 생성 네트워크 상에서 실행 중인 것으로 나타난다.
메시지 버스는 분산 로드 밸런서가 단일 프로세스로서 실행될 수 있게 하는 프레임워크를 제공한다. 프로세스에서의 하나 이상의 메시지 버스 레이어 각각은 분산 로드 밸런서의 구성요소들 간 네트워크(가령, 이더넷) 세그먼트를 시뮬레이션한다. 분산 로드 밸런서 시스템의 소프트웨어 구성요소는 구성요소가 메시지 버스 환경 내에서 동작하도록 하기 위해 특수 방식으로 써질 필요는 없다. 대신, 메시지 버스 프레임워크는 분산 로드 밸런서 시스템의 구성요소가 생성한 패킷을 인터셉트하고 상기 패킷을 실제 물리 네트워크 대신 메시지 버스 레이어에 의해 제공되는 시뮬레이션되는 네트워크로 지향시키고, 상기 패킷을 타깃 구성요소로 전달하는 구성요소(메시지 버스 NIC 또는 패킷 어댑터라고 지칭될 수 있음)를 제공한다. 상기 메시지 버스 레이어는 구성요소들 간 통신을 위해 TCP/IP 스택(들)을 구현하지 않는다. 대신, 메시지 버스 레이어는 호스트 시스템의 운영 체제(OS)와 인터페이싱하고 호스트 시스템의 TCP/IP 스택을 이용한다. 상기 메시지 버스 레이어는 OS에 의해 제공되는 TCP/IP 스택을 활용하여, 메시지 버스가 인터셉트하고 전달하는 개별 패킷으로 및 개별 패킷으로부터 클라이언트 및 서버가 기대하는 TCP 스트림을 변환시킬 수 있다.
적어도 일부 실시예에서, 메시지 버스와 인터페이싱하기 위해, 로드 밸런서 구성요소에, 유효 매체 액세스 제어(MAC) 주소를 각각 갖는 적어도 하나의 메시지 버스 네트워크 인터페이스 제어기(NIC)가 제공될 수 있으며, 상기 메시지 버스 네트워크 인터페이스 제어기는 물리 네트워크 대신 메시지 버스 시뮬레이션되는 네트워크 환경으로 패킷을 전송하고 이로부터 패킷을 수신한다. 메시지 버스 NIC는 물리 네트워크 대신 메시지 버스에 부착되는 가상 네트워크 인터페이스 제어기이다. 메시지 버스를 통해 통신할 필요가 있는 각각의 로드 밸런서 구성요소는 적어도 하나의 메시지 버스 NIC를 필요로 한다. 메시지 버스 NIC는 메시지 버스의 파이프라인 출구 및 구성요소로의 파이프라인 입구로서 기능한다. 구성요소는 복수의 메시지 버스 네트워크 인터페이스를 각각의 메시지 버스 NIC에게 인스턴스화할 수 있다.
메시지 버스 네트워크 인터페이스는 구성요소가 메시지 버스 NIC를 통해 메시지 버스로 부착되기 위한 메커니즘이다. 메시지 버스 네트워크 인터페이스는 리눅스(Linux) 기법에서 인터페이스 구성(ifconfig) 인터페이스와 동의어일 수 있으며, 차이점은 메시지 버스 네트워크 인터페이스가 물리 네트워크 대신 메시지 버스에 부착된다는 것이다. 메시지 버스 네트워크 인터페이스는 IP 주소를 가지며, 메시지 버스 NIC에 안착된다. 상기 메시지 버스 네트워크 인터페이스는 구성요소에 의해 메시지 버스로부터 패킷을 수신하기 위해 사용될 수 있는 패킷 소스 인터페이스 및 구성요소에 의해 패킷을 메시지 버스로 전송하기 위해 사용될 수 있는 패킷 싱크를 노출한다.
각각의 로드 밸런서 노드는 패킷 소스 및 패킷 싱크 인터페이스의 구현을 통해 전달 및 전송되는 개별 네트워크 패킷을 프로세싱한다. 메시지 버스 환경에서 실행 중일 때, 이들 인터페이스는 (이를 예상하는 로드 밸런서 노드가 커넬 네트워크 스택에 의해 수행되도록) 레이어 2 이더넷 헤더를 추가 또는 제거하는 메시지 버스 네트워크 인터페이스에 의해 구현된다. 도 29에 도시된 생성 환경에서, 패킷 소스 및 패킷 싱크 인터페이스의 구현은 실제 네트워크 인터페이스 상에서 패킷을 수신 및 송신한다. 도 30에 도시된 메시지 버스 환경에서, 패킷 소스 및 패킷 싱크 인터페이스의 구현은 패킷을 메시지 버스 레이어 또는 레이어들로부터 수신하고 이들로 송신한다.
단순성을 위해, 메시지 버스 NIC 및 메시지 버스 인터페이스는 집합적으로 메시지 버스 패킷 어댑터, 또는 단순하게, 패킷 어댑터라고 지칭될 수 있다. 가령 도 31 및 32를 참조할 수 있다.
도 29는 적어도 일부 실시예에 따라 생성 환경에서의 분산 로드 밸런서(700)를 포함하는 로드 밸런싱 시스템을 도시한다. 상기 로드 밸런서(700)는 이 기재를 위해 단순화되었다. 상기 로드 밸런서(700)는, 네트워크 시설, 가령, 로드 밸런서(700)를 구현하는 데이터 센터의 경계 라우터(702)를 통해, 외부 네트워크(740) 상의 클라이언트(742)로 연결될 수 있다. 상기 로드 밸런서(700)는 몇 가지 유형의 구성요소 - 적어도 하나의 에지 라우터(704), 둘 이상의 로드 밸런서(LB) 노드710), 각각 개별적인 서버 노드(도시되지 않음) 상에 구현되는 둘 이상의 로드 밸런서(LB) 모듈(732), 패브릭(720)을 형성하는 하나 이상의 네트워킹 구성요소, 가령, 라우터 또는 스위치, 및 적어도 일부 실시예에서 구성 서비스(722)를 포함한다. 적어도 일부 실시예에서, 로드 밸런서(700)의 구성요소 각각은 개별 컴퓨팅 장치, 가령, 상품 랙(commodity rack)-장착된 컴퓨팅 장치로서 또는 상기 개별 컴퓨팅 장치 상에서 구현될 수 있다.
도 30은 적어도 일부 실시예에 따라 단일 프로세스로 복수의 분산 로드 밸런싱 시스템 구성요소가 구성 및 실행될 수 있게 하는 메시지 버스 메커니즘을 포함하는 분산 로드 밸런서 시험 시스템(800)을 도시한다. 도 29에 도시된 로드 밸런서(700)에서, 각각의 로드 밸런서 소프트웨어 구성요소가 개별 컴퓨팅 장치(가령, 로드 밸런서 노드(710) 상의 로드 밸런서 소프트웨어, 및 서버 노드 상의 로드 밸런서 모듈(732)) 상에 설치되고 실행된다. 이들 로드 밸런서 소프트웨어 구성요소가 단일 프로세스로 실행될 수 있도록 하기 위해, 각각의 로드 밸런서 소프트웨어 구성요소(도 30에서 로드 밸런서(LB) 노드(810) 및 로드 밸런서(LB) 모듈(832)로서 나타남)가 구성요소들의 네트워크 연결성을 추상화하여, 로드 밸런서 소프트웨어 구성요소 안팎의 패킷이 물리 네트워크로 전송 및 여기서 수신되는 대신 메시지 버스 메커니즘을 통해 인터셉트 및 라우팅될 수 있게 하는 코드를 포함할 수 있다.
적어도 일부 실시예에서, 분산 로드 밸런서 시험 시스템(800)에서, 메시지 버스 메커니즘은 구성요소들 간 통신을 위해 TCP 스택(들)을 구현하지 않는다. 대신, 메시지 버스 메커니즘은 호스트 시스템의 운영 체제(OS)와 인터페이싱하고 호스트 시스템의 TCP 스택을 이용한다. 적어도 일부 실시예에서, 메시지 버스 기능부가 IP 테이블을 통해 사용자 레이어 아래의 호스트 시스템의 OS의 커넬, 커넬의 기능부와 연결된다. 메시지 버스 기능부가 커넬 레벨에서 IP 테이블을 조사하고 패킷을 인터셉트하고, 패킷을 라우팅을 위해 메시지 버스 프로세스로 전송한다.
도 30에서 시뮬레이션된 에지 라우터(862) 및 시뮬레이션된 패브릭(864)에 의해 나타나는 바와 같이, 물리 네트워크 구성요소(가령, 도 29의 에지 라우터(704) 및 패브릭(720))의 기능부가, 클라이언트(860), 서버(834) 및 구성 서비스(866)가 할 수 있는 것처럼, 소프트웨어로 시뮬레이션될 수 있다. 그러나 적어도 일부 실시예에서, 시뮬레이션된 것보다는 실제 서버(834)가 분산 로드 밸런서 시험 시스템(800)에서 사용될 수 있다. 도 30의 메시지 버스 레이어(850)는 물리 네트워크 인프라구조를 대체한다. 따라서 로드 밸런서 소프트웨어 구성요소(로드 밸런서 노드(810) 및 로드 밸런서 모듈(832))은, 그들이 도 29에 도시된 바와 같이 생성 네트워크 환경에서 실행 중이 아니라는 것을 인지하지 못하면서, 로드 밸런서 시험 시스템(800)에서 실행될 수 있다.
일부 구성요소(가령, 시뮬레이션된 라우터)가 둘 이상의 메시지 버스 레이어(850)로 연결되어, 네트워크 세그먼트를 시뮬레이션하는 서로 다른 메시지 버스 레이어(850)로 패킷을 전달하고 이로부터 패킷을 수신할 수 있다.
분산 로드 밸런싱 시험 시스템(800)의 메시지 버스 레이어(850)에서 구현되는 메시지 버스 메커니즘은 네트워크 세그먼트의 "와이어(wire)"를 시뮬레이션한다. 적어도 일부 실시예에서, 메시지 버스 메커니즘은 구성요소의 MAC 주소를 기초로 하여 패킷을 분산 로드 밸런싱 시험 시스템(800)의 도착지 구성요소로 전달한다. 따라서 각각의 로드 밸런서 소프트웨어 구성요소(로드 밸런서 노드(810) 및 로드 밸런서 모듈(832))는 MAC 주소를, 자신이 연결된 메시지 버스 레이어(들)(850)로 제공하여, 로드 밸런서 소프트웨어 구성요소가 분산 로드 밸런싱 시험 시스템(800)의 다른 구성요소로부터 전송될 패킷을 수신할 수 있도록 한다.
메시지 버스 패킷 어댑터
도 31 및 32는 적어도 일부 실시예에 따르는 메시지 버스 패킷 어댑터를 도시한다. 적어도 일부 실시예에서, 각각의 로드 밸런서(LB) 소프트웨어 구성요소는 패킷소스(PacketSource) 및 패킷싱크(PacketSink) 인터페이스의 구현을 통해 전달 및 전송되는 개별 네트워크 패킷을 프로세싱한다. 도 31을 참조하면, 분산 로드 밸런싱 시험 시스템(800)에서 실행될 때, 이들 인터페이스(패킷 소스 인터페이스(862) 및 패킷 싱크 인터페이스(864)로서 나타남)가 메시지 버스 레이어(850)와 이는 커넬 네트워크 스택에 의해 수행될 것임을 제외하고 로드 밸런서 소프트웨어 구성요소(870)에 대한 레이어 2 이더넷 헤드를 추가 또는 제거하는 로드 밸런서 소프트웨어 구성요소(870) 간 패킷 어댑터(860)에 의해 구현될 수 있다. 도 29에 도시된 바와 같은 생성 환경에서, 로드 밸런서 소프트웨어 구성요소에 대한 패킷소스 및 패킷 싱크의 구현이 구성요소가 구현되는 물리 장치의 실제 네트워크 인터페이스 상에서 패킷을 수신 및 송신한다.
도 31을 참조하면, 적어도 일부 실시예에서, 로드 밸런서 소프트웨어 구성요소(870)가 패킷을 송신할 때, 패킷 싱크 인터페이스(864)의 패킷 전송 방법을 호출하는 실행의 스레드가 패킷 어댑터(860) 내 그리고 메시지 버스 레이어(850) 내 함수들의 체인을 순회하여, 패킷을 상기 구성요소의 입력 큐에 추가함으로써 패킷을 도착지 구성요소로 결국 전달할 수 있다. 적어도 일부 실시예에서, 로드 밸런서 소프트웨어 구성요소(870)가 패킷을 수신할 때, 상기 로드 밸런서 소프트웨어 구성요소(870)는 패킷 소스 인터페이스(862)의 패킷 수신 방법을 호출하고 이의 입력 큐로부터 패킷을 읽는다. 적어도 일부 실시예에서, 메시지 버스 메커니즘은 패킷을 전달하기 위해 자신 고유의 임의의 추가 스레드를 필요로 하지 않는다.
메시지 버스 패킷 파이프라인
도 32를 참조하면, 적어도 일부 실시예에서, 패킷 소스 인터페이스(862) 및 패킷 싱크 인터페이스(864)의 메시지 버스(850) 측은 패킷 파이프라인 특징을 제공한다. 로드 밸런서 소프트웨어 구성요소(870)가 패킷 싱크 인터페이스(864)를 통해 패킷을 전송할 때, 패킷 데이터는 메시지 버스 레이어(850)에 도달하기 전에 스테이지들의 시리즈(패킷 파이프라인(880))를 순회할 수 있다. 이들 스테이지는 패킷을 수정, 패킷을 폐기, 패킷을 복제, 패킷을 지연 등을 할 수 있다. 패킷이 패킷 파이프라인(880)을 순회하고 메시지 버스 레이어(850)가 도착지 구성요소(870)를 선택하면, 패킷이 도착지 구성요소(870)의 입력 큐에 추가되기 전에, 도착지 구성요소(870)와 연관된 파이프라인 스테이지의 두 번째 시리즈(패킷 파이프라인(882))가 또한 순회될 수 있다.
예시적 제공자 네트워크 환경
이 섹션은 분산 로드 밸런싱 방법 및 장치의 실시예가 구현되는 예시적 제공자 네트워크 환경을 기술한다. 그러나 이들 예시적 제공자 네트워크 환경에 한정되지 않는다.
도 33a는 적어도 일부 실시예에 따르는 예시적 제공자 네트워크 환경을 도시한다. 제공자 네트워크(1900)는 클라이언트가 가상화된 자원의 인스턴스(1912), 비제한적 예를 들면, 하나 이상의 데이터 센터 내 제공자 네트워크 또는 네트워크들 내 장치 상에서 구현되는 계산 및 저장 자원을 액세스, 구매, 대여 또는 그 밖의 다른 방식으로 획득할 수 있게 하는 하나 이상의 가상화 서비스(1910)를 통해 클라이언트에게 자원 가상화를 제공할 수 있다. 사설 IP 주소(1916)가 자원 인스턴스(1912)와 연관될 수 있고, 사설 IP 주소는 제공자 네트워크(1900) 상의 자원 인스턴스(1912)의 내부 네트워크 주소이다. 일부 실시예에서, 제공자 네트워크(1900)는 또한 클라이언트가 제공자(1900)로부터 획득할 수 있는 공중 IP 주소(1914) 및/또는 공중 IP 주소 범위(가령, IPv4(Internet Protocol version 4) 또는 IPv6(Internet Protocol version 6) 주소)를 제공할 수 있다.
종래에는, 제공자 네트워크(1900)는, 가상화 서비스(1910)를 통해, 서비스 제공자의 클라이언트(가령, 클라이언트 네트워크(1950A)를 운영하는 클라이언트)가 자신에게 할당된 적어도 일부 공중 IP 주소(1914)를 자신에게 할당된 특정 자원 인스턴스(1912)와 동적으로 연관시키는 것을 허용할 수 있다. 제공자 네트워크(1900)는 또한 클라이언트가 자신에게 할당된 하나의 가상화된 컴퓨팅 자원 인스턴스(1912)에 이전에 맵핑된 공중 IP 주소(1914)를, 자신에게 할당된 또 다른 가상화된 컴퓨팅 자원 인스턴스(1912)로 리맵핑하는 것을 허용할 수 있다. 서비스 제공자에 의해 제공되는 가상화된 컴퓨팅 자원 인스턴스(1912) 및 공중 IP 주소(1914)를 이용하여, 서비스 제공자의 클라이언트, 가령, 클라이언트 네트워크(1950A)의 운영자가, 예를 들어, 클라이언트-특정적 애플리케이션을 구현하고 클라이언트의 애플리케이션을 중간 네트워크(1940), 가령, 인터넷 상에서 제시할 수 있다. 그 후 중간 네트워크(1940) 상의 그 밖의 다른 네트워크 개체(1920)가 트래픽을 클라이언트 네트워크(1950A)에 의해 게시되는 도착지 공중 IP 주소(1914)로 생성할 수 있으며, 트래픽이 서비스 제공자 데이터 센터로 라우팅되며, 데이터 센터에서, 네트워크 서브스트레이트(network substrate)를 통해 현재 도착지 공중 IP 주소(1914)로 맵핑된 가상화된 컴퓨팅 자원 인스턴스(1912)의 사설 IP 주소(1916)으로 라우팅된다. 마찬가지로, 가상화된 컴퓨팅 자원 인스턴스(1912)로부터의 응답 트래픽이 네트워크 서브스트레이트를 통해 다시 중간 네트워크(1940)로 출발지 개체(1920)로 라우팅될 수 있다.
사설 IP 주소는, 본 명세서에서 사용될 때, 제공자 네트워크에서 자원 인스턴스의 내부 네트워크 주소를 지칭한다. 사설 IP 주소는 제공자 네트워크 내에서만 라우팅 가능하다. 제공자 네트워크 외부에서 기원하는 네트워크 트래픽은 사설 IP 주소로 직접 라우팅되지 않으며, 대신, 트래픽이 자원 인스턴스로 맵핑되는 공중 IP 주소를 이용한다. 상기 제공자 네트워크는 공중 IP 주소에서 사설 IP 주소로의 맵핑 및 그 반대의 맵핑을 수행하기 위해 네트워크 주소 변환(NAT) 또는 유사한 기능을 제공하는 네트워크 장치 또는 기기를 포함할 수 있다.
공중 IP 주소는, 본 명세서에서 사용될 때, 서비스 제공자 또는 클라이언트에 의해 자원 인스턴스로 할당되는 인터넷 라우팅 가능한 네트워크 주소이다. 공중 IP 주소로 라우팅되는 트래픽은, 예를 들어, 1:1 네트워크 주소 변환(NAT)을 통해 변환되고 자원 인스턴스의 각자의 사설 IP 주소로 전달된다.
일부 공중 IP 주소는 제공자 네트워크 인프라구조에 의해 특정 자원 인스턴스로 할당될 수 있고, 이들 공중 IP 주소는 표준 공중 IP 주소 또는 단순 표준 IP 주소로 지칭될 수 있다. 적어도 일부 실시예에서, 자원 인스턴스의 사설 IP 주소로의 표준 IP 주소의 맵핑이 모든 자원 인스턴스 유형에 대한 디폴트 런치 구성이다.
적어도 일부 공중 IP 주소는 제공자 네트워크(1900)의 클라이언트에 의해 할당 또는 획득될 수 있고, 그 후 클라이언트는 이들 할당된 공중 IP 주소를 자신에게 할당된 특정 자원 인스턴스로 할당할 수 있다. 이들 공중 IP 주소는 클라이언트 공중 IP 주소, 또는 단순히 클라이언트 IP 주소라고 지칭될 수 있다. 표준 IP 주소의 경우에서 제공자 네트워크(1900)에 의해 자원 인스턴스로 할당되는 대신, 클라이언트 IP 주소가 가령 서비스 제공자에 의해 제공되는 API를 통해 클라이언트에 의해 자원 인스턴스로 할당될 수 있다. 표준 IP 주소와 달리, 클라이언트 IP 주소가 클라이언트 계정에 할당되고 각자의 클라이언트에 의해 필요에 따라 그 밖의 다른 자원 인스턴스로 리맵핑될 수 있다. 클라이언트 IP 주소는 특정 자원 인스턴스가 아니라 클라이언트의 계정과 연관되며, 클라이언트는 상기 IP 주소를 클라이언트가 이를 해제하기를 선택할 때까지 제어한다. 종래의 정적 IP 주소와 달리, 클라이언트 IP주소는 클라이언트가 클라이언트의 공중 IP 주소를 클라이언트의 계정과 연관된 임의의 자원 인스턴스로 리맵핑함으로써, 자원 인스턴스 또는 가용성 존 장애를 마스킹하게 할 수 있다. 클라이언트 IP 주소는, 가령, 클라이언트 IP 주소를 리맵핑하여 자원 인스턴스를 대체함으로써, 클라이언트가 클라이언트의 자원 인스턴스 또는 소프트웨어와 관련된 문제를 해결할 수 있게 한다.
도 33b는 적어도 일부 실시예에 따라 도 33a에서 도시된 예시적 제공자 네트워크 환경에서의 분산 로드 밸런서 구현을 도시한다. 제공자 네트워크(1900)는 서비스(1910)를 클라이언트(1960), 가령, 가상화된 스토리지 서비스로 제공할 수 있다. 상기 클라이언트(1960)는 가령, 서비스(1910)로의 하나 이상의 API를 통해 서비스(1910)를 액세스하여, 제공자 네트워크(1900)의 생성 네트워크 부분에서의 복수의 서버 노드(1990) 상에서 구현되는 자원(가령, 스토리지 자원 또는 계산 자원)의 사용성을 획득할 수 있다. 서버 노드(1990)는 각각 서버(도시되지 않음), 가령, 웹 서버 또는 애플리케이션 서버 및 로컬 로드 밸런서(LB) 모듈(1992)을 구현할 수 있다. 하나 이상의 분산 로드 밸런서(1980)는 경계 네트워크와 생성 네트워크 사이의 로드 밸런서 레이어로 구현될 수 있다. 경계 라우터(들)(1970)는 중간 네트워크(1940), 가령, 인터넷을 통해 클라이언트(1960)로부터의 패킷 흐름으로 패킷(가령, TCP 패킷)을 수신하고, 상기 패킷을 경계 네트워크를 통해 분산 로드 밸런서(들)(1980)의 에지 라우터(들)로 전달할 수 있다. 상기 패킷은 분산 로드 밸런서(들)(1980)의 에지 라우터(들)에 의해 게시되는 공중 IP 주소(들)을 타깃으로 삼을 수 있다. 각각의 분산 로드 밸런서(1980)의 에지 라우터가 패킷 흐름을 각각의 분산 로드 밸런서(1980)의 로드 밸런서 노드들 간에 분산시킬 수 있다. 적어도 일부 실시예에서, 입구 노드로서 역할 하는 각각의 로드 밸런서 노드는 동일한 공중 IP 주소를 에지 라우터로 광고하고, 에지 라우터는 흐름당 해싱된 다중경로 라우팅 기법, 가령, 등가 다중경로(ECMP) 해싱 기법에 따라, 클라이언트(1960)로부터의 패킷 흐름을 입구 서버들 간에 분산시킨다. 로드 밸런서 노드는 본 명세서에 기재된 연결 프로토콜을 이용해 패킷 흐름에 대한 타깃 서버 노드(1990)를 결정하고 서버와 클라이언트(1960) 간 연결을 촉진시킬 수 있다. 연결이 확립되면, 입구 노드가 흐름에 대해 수신된 패킷을 캡슐화하고 생성 네트워크 상의 타깃 서버 노드(1990)로 전송하며, 이때 흐름 추적기 노드는 연결에 대한 상태를 유지관리한다. 서버 노드(1990) 상의 로드 밸런서 모듈(1992)은 서버 노드(1960) 상의 각각의 서버가 연결을 수락할지 여부에 대해 결정할 수 있다. 상기 로드 밸런서 모듈은 입구로부터의 패킷을 수신하고 역캡슐화하며, 역캡슐화된 패킷(가령, TCP 패킷)을 서버 노드(1990) 상의 각각의 서버로 전송한다. 로드 밸런서 모듈(1992)은 또한 패킷 흐름에 대한 출구 노드로서의 로드 밸런서 노드를 선택할 수 있고, 상기 흐름에 대한 아웃고잉 패킷을 캡슐화하고 생성 네트워크를 통해 선택된 출구 노드로 전송할 수 있다. 그 후 상기 출구 노드는 패킷을 역캡슐화하고 역캡슐화된 패킷을 각자의 클라이언트(1960)로의 전달을 위해 경계 네트워크 상으로 전송한다.
도 34a는 적어도 일부 실시예에 따르는 분산 로드 밸런서 및 서버 노드의 예시적 물리 랙(rack) 구현을 도시하며 이에 한정되지 않는다. 적어도 일부 실시예에서, 분산 로드 밸런서의 다양한 구성요소가 상품 랙-장착 컴퓨팅 장치 상에 또는 상기 컴퓨팅 장치로서 구현될 수 있다. 랙(190)은 로드 밸런서 노드(LB 노드(110A-110F))로서 각각 기능하는 복수의 컴퓨팅 장치, 및 서버 노드(서버 노드(130A-130L))로서 각각 기능하는 복수의 컴퓨팅 장치를 포함할 수 있다. 랙(190)은 또한 적어도 하나의 에지 라우터(104), 패브릭(120)을 형성하는 하나 이상의 랙-장착 네트워킹 장치(라우터, 스위치 등), 및 하나 이상의 기타 구성요소(180)(기타 네트워킹 장치, 패치 패널, 파워 서플라이, 냉각 시스템, 버스 등)을 포함할 수 있다. 도 33a 및 33b의 제공자 네트워크(1900)를 구현하는 네트워크(100) 시설, 가령, 데이터 센터 또는 센터들은 하나 이상의 랙(190)을 포함할 수 있다.
도 34b는 적어도 일부 실시예에 따라 분산 로드 밸런서 및 서버 노드의 또 다른 예시적 물리 랙 구현예를 도시하며 이에 한정되지 않는다. 도 34b는 랙(190)에서 슬롯-장착된 컴퓨팅 장치, 가령, 블레이드 서버(blade server)로서 구현되는 LB 노드(110) 및 서버 노드(130)를 도시한다.
도 35는 적어도 일부 실시예에 따라 하나, 둘, 또는 그 이상의 분산 로드 밸런서가 네트워크에서 구현될 수 있고, 이때 서버 노드가 개별적으로 구현되는 예시적 네트워킹 환경을 도시한다. 이 예시에서, 2개의 분산 로드 밸런서(1980A 및 1980B)가 도시된다. 분산 로드 밸런서(1980) 각각이 경계 네트워크를 통해 클라이언트(1960)로부터 패킷 흐름을 수신하고, 본 명세서에 기재된 바와 같은 로드 밸런싱 방법을 수행하여 패킷 흐름을 복수의 서버 노드(1990) 간에 분산시킬 수 있다. 일부 구현예에서, 각각의 분산 로드 밸런서(1980)는, 서버 노드가 로드 밸런서 랙에 설치되지 않는 것을 제외하면, 도 34a 및 34b에서 나타난 랙(190)과 유사한 랙 구현예일 수 있다. 서버 노드(1990)는 랙-장착된 컴퓨팅 장치, 가령, 데이터 센터 내 하나 이상의 개별 랙에 설치되는 블레이드 서버일 수 있다. 일부 구현예에서, 서버 노드(1990)는 제공자 네트워크에 의해 제공되는 둘 이상의 서로 다른 서비스를 구현할 수 있고, 각각의 서비스는 로드 밸런서(1980)들 중 서로 다른 하나 이상의 로드 밸런서와 면한다.
예시적 시스템
적어도 일부 실시예에서, 본 명세서에 기재된 분산 로드 밸런싱 방법 및 장치 중 일부 또는 전부를 구현하는 서버가 하나 이상의 컴퓨터 액세스 가능한 매체를 포함하거나 이를 액세스하도록 구성된 범용 컴퓨터 시스템, 가령, 도 36에 도시된 컴퓨터 시스템(2000)을 포함할 수 있다. 도시된 실시예에서, 컴퓨터 시스템(2000)은 입력/출력(I/O) 인터페이스(2030)를 통해 시스템 메모리(2020)로 연결된 하나 이상의 프로세서(2010)를 포함한다. 컴퓨터 시스템(2000)은 I/O 인터페이스(2030)로 연결된 네트워크 인터페이스(2040)를 더 포함한다.
다양한 실시예에서, 컴퓨터 시스템(2000)은 하나의 프로세서(2010)를 포함하는 유니프로세서(uniprocessor) 시스템 또는 복수의 프로세서(2010)(가령, 2, 4, 8, 또는 또 다른 적합한 개수)를 포함하는 멀티프로세서 시스템일 수 있다. 프로세서(2010)는 명령을 실행시킬 수 있는 임의의 적합한 프로세서일 수 있다. 예를 들어, 다양한 실시예에서, 프로세서(2010)는 다양한 명령 세트 아키텍처(ISA) 중 임의의 것, 가령, x86, PowerPC, SPARC, 또는 MIPS ISA, 또는 그 밖의 다른 임의의 적합한 ISA을 구현하는 범용 또는 임베디드 프로세서일 수 있다. 멀티프로세서 시스템에서, 각각의 프로세서(2010)는 반드시는 아니지만 일반적으로 동일한 ISA를 구현할 수 있다.
시스템 메모리(2020)는 프로세서(들)(2010)에 의해 액세스 가능한 명령 및 데이터를 저장하도록 구성될 수 있다. 다양한 실시예에서, 시스템 메모리(2020)는 임의의 적합한 메모리 기법, 가령, 정적 랜덤 액세스 메모리(SRAM), 동기식 동적 RAM(SDRAM), 비휘발성/플래시형 메모리, 또는 그 밖의 다른 임의의 유형의 메모리를 이용해 구현될 수 있다. 도시된 실시예에서, 하나 이상의 희망 기능, 가령, 분산 로드 밸런싱 방법 및 장치를 위해 앞서 기재된 방법, 기법, 및 데이터를 구현하는 프로그램 명령 및 데이터가 시스템 메모리(2020) 내에서 코드(2024) 및 데이터(2026)로서 저장되는 것이 나타난다.
하나의 실시예에서, I/O 인터페이스(2030)는 프로세서(2010), 시스템 메모리(2020), 및 임의의 주변 장치, 가령, 네트워크 인터페이스(2040) 또는 그 밖의 다른 주변기기 인터페이스를 포함하는 장치 간 I/O 트래픽을 조절하도록 구성될 수 있다. 일부 실시예에서, I/O 인터페이스(2030)는 임의의 필수 프로토콜, 타이밍 또는 또 다른 데이터 변환을 수행하여, 하나의 구성요소(가령, 시스템 메모리(2020)로부터의 데이터 신호를 또 다른 구성요소(가령 프로세서(2010))에 의해 사용되기 적합한 형태로 변환할 수 있다. 일부 실시예에서, I/O 인터페이스(2030)는 다양한 유형의 주변 버스, 가령, PCI(Peripheral Component Interconnect) 버스 표준 또는 USB(Universal Serial Bus) 표준의 변형을 통해 부착되는 장치를 위한 지원을 포함할 수 있다. 일부 실시예에서, I/O 인터페이스(2030)의 기능이 둘 이상의 개별 구성요소, 가령, 노스 브리지 및 사우스 브리지로 분할될 수 있다. 또한 일부 실시예에서 I/O 인터페이스(2030), 가령, 시스템 메모리(2020)로의 인터페이스의 기능의 일부 또는 전부가 프로세서(2010)로 직접 포함될 수 있다.
네트워크 인터페이스(2040)는 데이터가 컴퓨터 시스템(2000)과 네트워크 또는 네트워크들(2050)에 부착된 그 밖의 다른 장치(2060), 가령, 도 1 내지 35에 도시된 컴퓨터 시스템 또는 장치 간에 교환될 수 있도록 구성될 수 있다. 다양한 실시예에서, 네트워크 인터페이스(2040)는 임의의 적합한 유선 또는 무선 일반 데이터 네트워크, 가령, 일종의 이더넷 네트워크를 통한 통신을 지원할 수 있다. 덧붙여, 네트워크 인터페이스(2040)는 원격통신/전화 네트워크, 가령, 아날로그 음성 네트워크 또는 디지털 광섬유 통신 네트워크, 스토리지 영역 네트워크, 가령, 광섬유 채널 SAN, 또는 그 밖의 다른 임의의 적합한 유형의 네트워크 및/또는 프로토콜을 통한 통신을 지원할 수 있다.
일부 실시예에서, 시스템 메모리(2020)는 분산 로드 밸런싱 시스템의 실시예를 구현하기 위해 도 1 내지 35에 대해 앞서 기재된 프로그램 명령 및 데이터를 저장하도록 구성된 컴퓨터 액세스 가능한 매체의 하나의 실시예일 수 있다. 그러나 또 다른 실시예에서, 프로그램 명령 및/또는 데이터가 서로 다른 유형의 컴퓨터 액세스 가능한 매체 상에 수신, 전송, 또는 저장될 수 있다. 일반적으로 말하면, 컴퓨터 액세스 가능한 매체는 비-일시적 저장 매체 또는 메모리 매체, 가령, 자기 또는 광학 매체, 가령, I/O 인터페이스(2030)를 통해 컴퓨터 시스템(2000)으로 연결된 디스크 또는 DVD/CD를 포함할 수 있다. 비-일시적 컴퓨터 액세스 가능한 저장 매체는 또한, 컴퓨터 시스템(2000)의 일부 실시예에서 시스템 메모리(2020) 또는 또 다른 유형의 메모리로서 포함될 수 있는 임의의 휘발성 또는 비휘발성 매체, 가령, RAM(가령, SDRAM, DDR SDRAM, RDRAM, SRAM 등), ROM 등을 포함할 수 있다. 덧붙여, 컴퓨터 액세스 가능한 매체는 네트워크 인터페이스(2040)를 통해 구현될 수 있는 것과 같이 통신 매체, 가령, 네트워크 및/또는 무선 링크를 통해 운반되는 전송 매체 또는 신호, 가령, 전기, 전자기, 또는 디지털 신호를 포함할 수 있다.
본 발명의 실시예는 다음의 항목을 고려하여 기재될 수 있다:
1.분산 로드 밸런서 시스템으로서,
복수의 로드 밸런서 노드, 및
서버 및 로드 밸런서 모듈을 각각 포함하는 복수의 서버 노드
를 포함하며,
복수의 로드 밸런서 노드는 하나 이상의 클라이언트로부터의 패킷 흐름을 복수의 서버 노드 간에 분산시키도록 구성되고, 패킷 흐름을 복수의 서버 노드 간에 분산시키기 위해, 복수의 로드 밸런서 노드는
복수의 서버 노드 중에서 클라이언트로부터의 패킷 흐름에 대한 연결 요청을 수신할 서버 노드를 선택하고,
선택된 서버 노드로 연결 요청을 전송하도록 구성되며,
각각의 서버 노드 상의 로드 밸런서 모듈은,
복수의 로드 밸런서 노드 중 한 로드 밸런서로부터의 패킷 흐름에 대한 연결 요청을 수신하고,
상기 연결이 서버 노드 상의 서버에 의해 수락될 것인지 여부를 결정하며,
서버가 상기 연결을 수락할 수 없는 경우, 연결 요청을 거절하며,
서버가 상기 연결을 수락할 수 있는 경우, 복수의 로드 밸런서 노드와 협업하여, 각각의 클라이언트와 각각의 서버 간에 패킷 흐름에 대한 연결을 확립하도록 구성된, 분산 로드 밸런서 시스템.
2. 항목 1에 있어서, 해싱된 다중경로 라우팅 기법에 따라, 하나 이상의 클라이언트로부터의 패킷 흐름을 복수의 로드 밸런서 노드로 분산시키도록 구성된 라우터를 더 포함하는, 분산 로드 밸런서 시스템.
3. 항목 1에 있어서, 연결이 서버 노드 상의 서버에 의해 수락될 것인지 여부를 결정하기 위해, 상기 로드 밸런서 모듈은 서버 노드 상의 서버의 하나 이상의 현재 자원 사용 메트릭을 분석하여 서버가 연결을 수락할 수 있는지 여부를 결정하고, 상기 하나 이상의 현재 자원 사용 메트릭은 CPU 활용률, 대역폭 소비율, 서버 대기시간, 및 확립된 연결의 수 중 하나 이상을 포함하는, 분산 로드 밸런서 시스템.
4. 항목 1에 있어서, 복수의 로드 밸런서 노드는 랜덤 선택 기법에 따라 복수의 서버 노드 중에서 연결 요청을 수신할 서버 노드를 선택하도록 더 구성되는, 분산 로드 밸런서 시스템.
5. 항목 1에 있어서, 복수의 로드 밸런서 노드는 복수의 서버 노드 중에서, 거절된 연결 요청을 수신할 다른 한 서버 노드를 선택하고, 연결 요청을 상기 다른 한 서버 노드로 전송하도록 더 구성되는, 분산 로드 밸런서 시스템.
6. 항목 1에 있어서, 각각의 패킷 흐름은 TCP(Transmission Control Protocol) 패킷 흐름이고, 클라이언트와 서버 사이에 확립된 각각의 연결은 TCP 연결인, 분산 로드 밸런서 시스템.
7. 항목 1에 있어서, 클라이언트와 서버 간에 확립된 연결 각각은 클라이언트에서 시작되고, 복수의 로드 밸런서 노드 중 하나 이상을 통과하여, 서버에서 종료되는, 분산 로드 밸런서 시스템.
8. 방법으로서,
복수의 로드 밸런서 노드 중 하나 이상의 로드 밸런서 노드에 의해:
클라이언트에 대한 패킷 흐름으로 패킷을 수신하든 단계, 및
패킷 흐름에 대한 연결 요청을 복수의 서버 노드 중에서 선택된 서버 노드로 전송하는 단계
를 수행하는 단계,
선택된 서버 노드에 의해,
서버 노드 상의 서버가 연결을 수락할 수 있는지 여부를 결정하는 단계,
서버가 연결을 수락할 수 없다고 결정나면 연결 요청을 거절하는 단계, 및
서버가 연결을 수락할 수 있다고 결정나면 연결 요청을 수락하는 단계
를 수행하는 단계
를 포함하는, 방법.
9. 항목 8에 있어서, 연결 요청을 수락하는 단계는 선택된 서버 노드가 하나 이상의 로드 밸런서 노드와 협업하여 패킷 흐름에 대해 각각의 클라이언트와 각각의 서버 간에 연결을 확립하는 단계를 포함하는, 방법.
10. 항목 9에 있어서, 패킷 흐름은 TCP(Transmission Control Protocol) 패킷 흐름이고, 클라이언트와 서버 사이에 확립된 연결은 TCP 연결인, 방법.
11. 항목 9에 있어서, 확립된 연결은 클라이언트에서 시작하고, 복수의 로드 밸런서 노드 중 하나의 로드 밸런서 노드를 통과하여, 서버에 의해 종료되는, 방법.
12. 항목 8에 있어서, 상기 패킷은 해싱된 다중경로 라우팅 기법에 따라 하나 이상의 클라이언트로부터의 패킷 흐름을 복수의 로드 밸런서 노드 간에 분산시키는 라우터로부터 수신되는, 방법.
13. 항목 8에 있어서, 서버 노드 상의 서버가 연결을 수락할 수 있는지 여부를 결정하는 단계는 서버의 하나 이상의 현재 자원 사용 메트릭을 분석하여 서버가 연결을 수락할 수 있는지 여부를 결정하는 단계를 포함하는, 방법.
14. 항목 8에 있어서, 하나 이상의 로드 밸런서 노드가 랜덤 선택 기법에 따라 복수의 서버 노드 중에서 서버 노드를 선택하는 단계를 더 포함하는, 방법.
15. 항목 8에 있어서, 선택된 서버 노드가 연결 요청을 거절하는 경우, 하나 이상의 로드 밸런서 노드가 연결 요청을 복수의 서버 노드 중에서 선택된 다른 한 서버 노드로 전송하는 단계를 더 포함하는, 방법.
16. 복수의 서버 노드 각각 상에 로드 밸런서 모듈을 구현하기 위해 컴퓨터로 실행 가능한 프로그램 명령을 저장하는 비일시적 컴퓨터 액세스형 저장 매체로서, 각각의 로드 밸런서 모듈은
복수의 로드 밸런서 노드 중 한 로드 밸런서 노드로부터 클라이언트로부터의 패킷 흐름에 대한 연결 요청을 수신하며,
서버 노드 상의 서버가 연결을 수락할 수 있는지 여부를 결정하고,
서버가 연결을 수락할 수 없다고 결정나면 연결 요청을 거절하며,
서버가 연결을 수락할 수 있다고 결정나면 로드 밸런서 노드 및 서버와 통신하여, 패킷 흐름에 대해 클라이언트와 서버 간에 연결을 확립하도록 동작하는, 로드 밸런서 시스템.
17. 항목 16에 있어서, 서버 노드 상의 서버가 연결을 수락할 수 있는지 여부를 결정하기 위해, 로드 밸런서 모듈은 서버의 하나 이상의 현재 자원 사용 메트릭을 분석하여 서버가 연결을 수락할 수 있는지 여부를 결정하도록 동작하는, 비일시적 컴퓨터 액세스형 저장 매체.
18. 항목 17에 있어서, 하나 이상의 현재 자원 사용 메트릭은 CPU 활용률, 대역폭 소비율, 서버 대기시간, 및 확립된 연결의 수 중 하나 이상을 포함하는, 비일시적 컴퓨터 액세스형 저장 매체.
19. 항목 16에 있어서, 프로그램 명령은 복수의 서버 노드 중에서 연결 요청을 수신할 서버 노드를 랜덤하게 선택하는 로드 밸런서 노드를 구현하도록 더 컴퓨터로 실행되는, 비일시적 컴퓨터 액세스형 저장 매체.
20. 항목 16에 있어서, 연결 요청을 거절하기 위해, 로드 밸런서 모듈은 연결 요청 내 수명 시간(TTL) 카운터를 감분(decrement)시키고, 연결 요청을 로드 밸런서 노드로 반환하도록 동작하며, 로드 밸런서 노드가
반환된 연결 요청 내 TTL 카운터를 체크하고,
상기 TTL 카운터가 임계값을 초과한 경우, 복수의 서버 노드 중에서 연결 요청을 수신할 다른 한 서버 노드를 선택하며,
상기 TTL 카운터가 임계값 이하인 경우, 연결 요청을 폐기하도록
하는 프로그램 명령이 추가로 컴퓨터 실행되는, 비일시적 컴퓨터 액세스형 저장 매체.
결론
다양한 실시예가 상기의 기재에 따라 구현되는 명령 및/또는 데이터를 컴퓨터 액세스 가능 매체로 수신, 전송 또는 저장하는 것을 더 포함할 수 있다. 일반적으로 말하면, 컴퓨터 액세스 가능 매체는 스토리지 매체 또는 메모리 매체, 자기 또는 광학 매체, 가령, 디스크 또는 DVD/CD-ROM, 휘발성 또는 비휘발성 매체, 가령, RAM(가령 SDRAM, DDR, RDRAM, SRAM, 등), ROM 등, 전송 매체 또는 신호, 가령, 통신 매체, 가령, 네트워크 및/또는 무선 링크를 통해 운반되는 전기, 전자기, 또는 디지털 신호를 포함할 수 있다.
도면에서 도시되고 본 명세서에 기재된 다양한 방법은 방법의 예시적 실시예를 나타낸다. 상기 방법은 소프트웨어, 하드웨어, 또는 이의 조합으로 구현될 수 있다. 방법의 순서가 변경될 수 있고, 다양한 요소가 추가, 재순서화, 조합, 생략, 수정 등이 될 수 있다.
본 발명의 이익을 누리는 해당 분야의 통상의 기술자에게 다양한 수정 및 변경이 이뤄질 수 있음이 자명할 것이다. 모든 이러한 수정 및 변경을 포함하는 의도를 가지며, 따라서 상기의 기재는 한정보다는 예시의 의미로 간주되야 한다.

Claims (15)

  1. 분산 로드 밸런서 시스템으로서,
    복수의 로드 밸런서 노드 - 상기 복수의 로드 밸런서 노드 중 적어도 2개는 입구 서버들(ingress servers)로서 구성되고, 상기 복수의 로드 밸런서 노드 중 적어도 2개는 흐름 추적기 노드들(flow tracker nodes)로서 구성됨 -;
    복수의 서버 노드; 및
    해싱된 다중경로 라우팅 기법에 따라, 하나 이상의 클라이언트로부터의 패킷 흐름들을 상기 입구 서버들로 분산시키도록 구성된 라우터
    를 포함하고,
    각각의 입구 서버는,
    상기 라우터로부터 클라이언트에 대한 패킷 흐름으로 패킷을 수신하고,
    상기 입구 서버가 상기 복수의 서버 노드로의 상기 패킷 흐름에 대한 저장된 맵핑을 가지는지 여부를 결정하며,
    상기 패킷의 출발지 및 도착지 주소 정보에 적용되는 일관 해시 함수(consistent hash function)에 따라 상기 패킷 흐름에 대한 적어도 하나의 흐름 추적기 노드를 결정하고 - 상기 적어도 하나의 흐름 추적기 노드는 상기 패킷 흐름에 대응하는 상태 정보를 관리하도록 구성됨 -,
    상기 적어도 하나의 흐름 추적기 노드로부터, 상기 입구 서버가 상기 저장된 맵핑을 가지지 않는다는 결정에 기초하여, 상기 패킷 흐름에 대한 상기 복수의 서버 노드 중 특정 서버 노드로의 연결의 맵핑을 획득하며,
    상기 획득된 맵핑에 기초하여, 상기 패킷 흐름의 하나 이상의 패킷을 상기 특정 서버 노드로 전송하도록 구성되는, 분산 로드 밸런서 시스템.
  2. 제1항에 있어서,
    상기 패킷 흐름은 TCP(Transmission Control Protocol) 패킷 흐름인, 분산 로드 밸런서 시스템.
  3. 제1항에 있어서,
    상기 복수의 로드 밸런서 노드 중 적어도 2개는 아웃고잉 패킷들(outgoing packets)을 상기 서버 노드들로부터 상기 하나 이상의 클라이언트로 전송하도록 구성된 출구 서버들(egress servers)로서 구성되고,
    상기 서버 노드는,
    상기 패킷 흐름에 대한 상기 출구 서버들 중 하나의 출구 서버를 선택하고,
    상기 패킷 흐름에 대한 하나 이상의 아웃고잉 패킷을 상기 선택된 출구 서버로 전송하도록 구성되며,
    상기 출구 서버는 상기 아웃고잉 패킷들을 상기 클라이언트로 전송하도록 구성되고,
    상기 패킷 흐름에 대한 상기 선택된 출구 서버는 상기 패킷 흐름에 대한 상기 입구 서버와 상이한 로드 밸런서 노드인, 분산 로드 밸런서 시스템.
  4. 제3항에 있어서,
    상기 입구 서버는 상기 패킷들을 상기 서버 노드로 전송하기 이전에 UDP(User Datagram Protocol)에 따라 상기 하나 이상의 패킷을 캡슐화하고, 상기 서버 노드는 상기 아웃고잉 패킷들을 상기 출구 서버로 전송하기 이전에 UDP에 따라 상기 아웃고잉 패킷들을 캡슐화하며, 상기 출구 서버는 상기 아웃고잉 패킷들을 상기 클라이언트로 전송하기 이전에 상기 아웃고잉 패킷들로부터 상기 UDP 캡슐화를 제거하는, 분산 로드 밸런서 시스템.
  5. 제4항에 있어서,
    상기 서버 노드는 로드 밸런서 모듈을 포함하고,
    상기 로드 밸런서 모듈은,
    상기 패킷 흐름에 대한 상기 출구 서버를 선택하고,
    상기 입구 서버로부터 인입되는 상기 캡슐화된 패킷들을 수신하며,
    상기 패킷들로부터의 상기 UDP 캡슐화를 제거하고, 상기 패킷들을 상기 서버 노드 상의 서버로 전달하고,
    상기 서버 노드의 상의 상기 서버로부터 상기 아웃고잉 패킷들을 획득하며,
    UDP에 따라 상기 아웃고잉 패킷들을 캡슐화하고,
    상기 캡슐화된 아웃고잉 패킷들을 상기 출구 서버로 전송하도록 구성되는, 분산 로드 밸런서 시스템.
  6. 제1항에 있어서,
    상기 적어도 하나의 흐름 추적기 노드로부터 상기 패킷 흐름에 대한 상기 복수의 서버 노드 중 특정 서버 노드로의 연결의 맵핑을 획득하기 위해,
    상기 입구 서버는 상기 패킷 흐름에 대한 정보를 포함하는 메시지를 상기 패킷 흐름에 대한 주 흐름 추적기(primary flow tracker)로 전송하고,
    상기 주 흐름 추적기는 상기 패킷 흐름에 대한 상기 정보를 포함하는 메시지를 상기 패킷 흐름에 대한 보조 흐름 추적기(secondary flow tracker)로 전송하며 - 상기 패킷 흐름에 대한 상기 주 및 보조 흐름 추적기들은 상이한 로드 밸런서 노드들임 -,
    상기 보조 흐름 추적기는 상기 패킷 흐름에 대한 긍정응답 패킷(acknowledgement packet)을 상기 클라이언트로 전송하며,
    상기 입구 서버는 상기 클라이언트로부터 긍정응답 패킷을 수신하고 상기 긍정응답 패킷을 상기 주 흐름 추적기로 전달하며,
    상기 주 흐름 추적기는 상기 패킷 흐름을 수신하기 위한 상기 서버 노드로서 상기 복수의 서버 노드 중에서 상기 특정 서버 노드를 랜덤하게 선택하고, 상기 특정 서버 노드를 지시하는 메시지를 상기 보조 흐름 추적기로 전송하며,
    상기 보조 흐름 추적기는 동기화 메시지(synchronization message)를 제작(fabricate)하고, 상기 제작된 동기화 메시지를 상기 특정 서버 노드로 전송하며,
    상기 보조 흐름 추적기는 상기 특정 서버 노드로부터 상기 패킷 흐름에 대한 연결 정보를 수신하고, 상기 연결 정보를 포함하는 메시지를 상기 주 흐름 추적기로 전송하며,
    상기 주 흐름 추적기는 상기 패킷 흐름에 대한 상기 연결 정보를 포함하는 메시지를 상기 입구 서버로 전송하고, 상기 연결 정보는 상기 패킷 흐름을 상기 특정 서버 노드로 맵핑하는, 분산 로드 밸런서 시스템.
  7. 제6항에 있어서,
    상기 서버 노드는 로드 밸런서 모듈을 포함하고,
    상기 로드 밸런서 모듈은,
    상기 보조 흐름 추적기로부터 상기 제작된 동기화 메시지를 수신하고,
    상기 서버 노드 상의 서버가 연결을 수락할 수 있다고 결정하며,
    상기 제작된 동기화 메시지에 따라 동기화 패킷을 생성하고, 상기 동기화 패킷을 상기 서버 노드 상의 상기 서버로 전달하고,
    상기 서버 노드 상의 상기 서버에 의해 생성된 긍정응답 패킷을 인터셉트하며,
    상기 연결 정보를 포함하는 메시지를 상기 보조 흐름 추적기로 전송하도록 구성되는, 분산 로드 밸런서 시스템.
  8. 방법으로서,
    복수의 로드 밸런서 노드 중 하나의 로드 밸런서 노드 상의 입구 서버에 의해,
    클라이언트에 대한 패킷 흐름으로 패킷을 수신하는 단계 - 상기 패킷은 일관 해시 함수에 따라 패킷 흐름들을 하나 이상의 클라이언트로부터 상기 복수의 로드 밸런서 노드로 분산시키는 라우터로부터 수신됨 -;
    상기 패킷의 출발지 및 도착지 주소 정보에 적용되는 일관 해시 함수에 따라 상기 패킷 흐름에 대한 흐름 추적기 노드로서 역할하는 로드 밸런서 노드를 결정하는 단계;
    상기 패킷 흐름에 대한 상기 흐름 추적기 노드로부터, 상기 패킷 흐름에 대한 복수의 서버 노드 중 하나의 서버 노드로의 연결의 맵핑을 획득하는 단계 - 상기 패킷 흐름에 대한 상기 흐름 추적기 노드로부터 상기 연결의 상기 맵핑을 획득하는 단계 이전에 상기 입구 서버는 저장된 맵핑을 갖지 않음 -; 및
    상기 패킷 흐름의 하나 이상의 패킷을 상기 맵핑에 의해 지시되는 상기 서버 노드로 전송하는 단계
    를 수행하는 것을 포함하는 방법.
  9. 제8항에 있어서,
    상기 패킷 흐름의 상기 하나 이상의 패킷을 상기 서버 노드로 전송하는 단계 이전에, 상기 입구 서버가 UDP(User Datagram Protocol)에 따라 상기 패킷들을 캡슐화하는 단계
    를 더 포함하는 방법.
  10. 제8항에 있어서,
    상기 서버 노드에 의해, 상기 복수의 로드 밸런서 노드 중 하나의 로드 밸런서를 상기 패킷 흐름에 대한 출구 서버로서 선택하는 단계 - 상기 패킷 흐름에 대한 상기 선택된 출구 서버는 상기 패킷 흐름을 위한 상기 입구 서버와 상이한 로드 밸런서 노드 상에 있음 -;
    상기 서버 노드에 의해, 상기 패킷 흐름에 대한 하나 이상의 아웃고잉 패킷을 상기 선택된 출구 서버로 전송하는 단계; 및
    상기 출구 서버에 의해, 상기 아웃고잉 패킷들을 상기 패킷 흐름의 상기 클라이언트로 전송하는 단계
    를 더 포함하는 방법.
  11. 제10항에 있어서,
    상기 아웃고잉 패킷들을 상기 출구 서버로 전송하는 단계 이전에, 상기 서버 노드가 UDP(User Datagram Protocol)에 따라 상기 아웃고잉 패킷들을 캡슐화하는 단계; 및
    상기 아웃고잉 패킷들을 상기 클라이언트로 전송하는 단계 이전에, 상기 출구 서버가 상기 아웃고잉 패킷들로부터의 상기 UDP 캡슐화를 제거하는 단계
    를 더 포함하는 방법.
  12. 제8항에 있어서,
    상기 흐름 추적기 노드는 상기 패킷 흐름에 대한 주 흐름 추적기 노드이고, 상기 일관 해시 함수에 따른 일관 해시 링(consistent hash ring)에서의 다음 로드 밸런서 노드는 상기 패킷 흐름에 대한 보조 흐름 추적기 노드인, 방법.
  13. 제12항에 있어서,
    상기 패킷 흐름에 대한 상기 흐름 추적기 노드로부터, 상기 패킷 흐름에 대한 복수의 서버 노드 중 하나의 서버 노드로의 연결의 맵핑을 획득하는 단계는,
    상기 입구 서버에 의해, 적어도 하나의 메시지를 상기 패킷 흐름에 대한 상기 주 흐름 추적기 노드로 전송하는 단계 - 각각의 메시지는 상기 라우터로부터 수신된 상기 패킷 흐름의 패킷을 포함함 -;
    상기 주 흐름 추적기 노드에 의해, 상기 복수의 서버 노드 중에서 상기 패킷 흐름에 대한 상기 서버 노드를 선택하는 단계;
    상기 주 흐름 추적기 노드에 의해, 상기 선택된 서버 노드의 지시자를 포함하는 패킷 흐름 정보를 상기 보조 흐름 추적기 노드로 전송하는 단계;
    상기 보호 흐름 추적기 노드에 의해, 상기 서버 노드 및 상기 클라이언트와 통신함으로써 상기 패킷 흐름에 대한 상기 선택된 서버 노드로의 상기 연결의 확립을 촉진하는 단계; 및
    상기 보조 흐름 추적기 노드에 의해, 상기 패킷 흐름에 대한 연결 정보를 상기 입구 서버로 상기 주 흐름 추적기 노드를 통해 전송하는 단계 - 상기 연결 정보는 상기 패킷 흐름을 상기 선택된 서버 노드로 맵핑함 -
    를 포함하는, 방법.
  14. 제13항에 있어서,
    상기 서버 노드는 로드 밸런서 모듈을 포함하고, 상기 서버 노드 및 상기 클라이언트와 통신함으로써 상기 패킷 흐름에 대한 상기 선택된 서버 노드로의 상기 연결의 확립을 촉진하는 단계는,
    상기 보조 흐름 추적기 노드에 의해, 제작된 동기화 메시지를 상기 서버 노드 상의 상기 로드 밸런서 모듈로 전송하는 단계; 및
    상기 서버 노드 상의 상기 로드 밸런서 모듈에 의해,
    상기 서버 노드 상의 서버가 연결을 수락할 수 있다고 결정하고,
    상기 제작된 동기화 메시지에 따라 동기화 패킷을 생성하며,
    상기 동기화 패킷을 상기 서버 노드 상의 상기 서버로 전달하고,
    상기 서버 노드 상의 상기 서버에 의해 생성된 긍정응답 패킷을 인터셉트하며,
    상기 연결 정보를 포함하는 메시지를 상기 보조 흐름 추적기로 전송하는 것
    을 수행하는 단계
    를 포함하는, 방법.
  15. 복수의 로드 밸런서 노드 중 각각의 로드 밸런서 노드 상의 입구 서버 및 흐름 추적기를 구현하기 위해 컴퓨터로 실행 가능한 프로그램 명령들을 저장하는 비일시적 컴퓨터 액세스 가능한 저장 매체로서,
    각각의 입구 서버는,
    클라이언트에 대한 패킷 흐름으로 패킷을 수신하고 - 상기 패킷은 일관 해시 함수에 따라 패킷 흐름들을 하나 이상의 클라이언트로부터 상기 복수의 로드 밸런서 노드로 분산시키는 라우터로부터 수신됨 -,
    상기 패킷의 출발지 및 도착지 주소 정보에 적용되는 일관 해시 함수에 따라 상기 패킷 흐름에 대한 흐름 추적기 노드로서 역할하는 상기 복수의 로드 밸런서 노드 중 하나의 로드 밸런서 노드를 결정하며,
    상기 패킷 흐름에 대한 상기 흐름 추적기 노드로부터, 상기 패킷 흐름에 대한 복수의 서버 노드 중 하나의 서버 노드로의 연결의 맵핑을 획득하고 - 상기 연결의 상기 맵핑을 획득하기 이전에 상기 입구 서버는 상기 복수의 서버 노드로의 상기 패킷 흐름에 대한 저장된 맵핑을 갖지 않음 -,
    상기 패킷 흐름의 하나 이상의 패킷을 상기 맵핑에 의해 지시되는 상기 서버 노드로 전송하도록 구성되는, 비일시적 컴퓨터 액세스 가능한 저장 매체.
KR1020177030237A 2013-04-16 2014-04-16 분산 로드 밸런서 KR101863024B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/864,167 2013-04-16
US13/864,167 US10069903B2 (en) 2013-04-16 2013-04-16 Distributed load balancer
PCT/US2014/034428 WO2014172500A1 (en) 2013-04-16 2014-04-16 Distributed load balancer

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
KR1020157032262A Division KR101790315B1 (ko) 2013-04-16 2014-04-16 분산 로드 밸런서

Publications (2)

Publication Number Publication Date
KR20170121311A true KR20170121311A (ko) 2017-11-01
KR101863024B1 KR101863024B1 (ko) 2018-05-30

Family

ID=51687576

Family Applications (2)

Application Number Title Priority Date Filing Date
KR1020177030237A KR101863024B1 (ko) 2013-04-16 2014-04-16 분산 로드 밸런서
KR1020157032262A KR101790315B1 (ko) 2013-04-16 2014-04-16 분산 로드 밸런서

Family Applications After (1)

Application Number Title Priority Date Filing Date
KR1020157032262A KR101790315B1 (ko) 2013-04-16 2014-04-16 분산 로드 밸런서

Country Status (10)

Country Link
US (2) US10069903B2 (ko)
EP (2) EP3651440B1 (ko)
JP (2) JP6194100B2 (ko)
KR (2) KR101863024B1 (ko)
CN (2) CN105308929B (ko)
AU (1) AU2016277754B2 (ko)
BR (1) BR112015026342B1 (ko)
CA (1) CA2909621C (ko)
SG (1) SG11201508556RA (ko)
WO (1) WO2014172500A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102530913B1 (ko) * 2023-02-08 2023-05-10 주식회사 파이오링크 패킷의 콘텐츠 기반으로 dsr 로드 밸런싱을 수행하는 방법 및 패킷 콘텐츠 기반 dsr 로드 밸런싱 시스템

Families Citing this family (167)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8560634B2 (en) * 2007-10-17 2013-10-15 Dispersive Networks, Inc. Apparatus, systems and methods utilizing dispersive networking
ES2629311T3 (es) 2010-06-23 2017-08-08 Telefonaktiebolaget Lm Ericsson (Publ) Gestión de interferencias de señales de referencia en despliegues de redes heterogéneas
US9736065B2 (en) 2011-06-24 2017-08-15 Cisco Technology, Inc. Level of hierarchy in MST for traffic localization and load balancing
US8908698B2 (en) 2012-01-13 2014-12-09 Cisco Technology, Inc. System and method for managing site-to-site VPNs of a cloud managed network
EP2747386A1 (en) * 2012-12-20 2014-06-25 Telefonica S.A. Method and System for the creation, modification and removal of a distributed virtual customer premises equipment
JP6182861B2 (ja) * 2012-12-28 2017-08-23 富士通株式会社 情報処理装置、情報処理端末、情報検索プログラム及び情報検索方法
US10069903B2 (en) * 2013-04-16 2018-09-04 Amazon Technologies, Inc. Distributed load balancer
CN104144120A (zh) * 2013-05-07 2014-11-12 杭州华三通信技术有限公司 转发信息配置方法及装置
US9225638B2 (en) 2013-05-09 2015-12-29 Vmware, Inc. Method and system for service switching using service tags
US9391919B2 (en) 2013-08-14 2016-07-12 International Business Machines Corporation Adaptive algorithm for cloud admission policies
US9843540B2 (en) 2013-08-26 2017-12-12 Vmware, Inc. Traffic and load aware dynamic queue management
US9348602B1 (en) * 2013-09-03 2016-05-24 Amazon Technologies, Inc. Resource allocation for staged execution pipelining
US20150081400A1 (en) * 2013-09-19 2015-03-19 Infosys Limited Watching ARM
US9379982B1 (en) * 2013-09-30 2016-06-28 Juniper Networks, Inc. Adaptive stateless load balancing
US10063458B2 (en) 2013-10-13 2018-08-28 Nicira, Inc. Asymmetric connection with external networks
CN104811396A (zh) * 2014-01-23 2015-07-29 中兴通讯股份有限公司 一种负荷均衡的方法及系统
US9602424B1 (en) * 2014-03-31 2017-03-21 Amazon Technologies, Inc. Connection balancing using attempt counts at distributed storage systems
US10021028B2 (en) * 2014-06-16 2018-07-10 International Business Machines Corporation Controlling incoming traffic
US10122605B2 (en) 2014-07-09 2018-11-06 Cisco Technology, Inc Annotation of network activity through different phases of execution
DE102014109906B4 (de) * 2014-07-15 2016-03-03 Fujitsu Technology Solutions Intellectual Property Gmbh Verfahren zum Freischalten externer Computersysteme in einer Computernetz-Infrastruktur, verteiltes Rechnernetz mit einer solchen Computernetz-Infrastruktur sowie Computerprogramm-Produkt
US11159980B2 (en) 2014-07-22 2021-10-26 Parallel Wireless, Inc. Signaling storm reduction from radio networks
US10123232B2 (en) 2014-07-22 2018-11-06 Parallel Wireless, Inc. Signaling storm reduction from radio networks
US9531590B2 (en) 2014-09-30 2016-12-27 Nicira, Inc. Load balancing across a group of load balancers
US11296930B2 (en) 2014-09-30 2022-04-05 Nicira, Inc. Tunnel-enabled elastic service model
US10135737B2 (en) 2014-09-30 2018-11-20 Nicira, Inc. Distributed load balancing systems
US9876714B2 (en) 2014-11-14 2018-01-23 Nicira, Inc. Stateful services on stateless clustered edge
US11533255B2 (en) * 2014-11-14 2022-12-20 Nicira, Inc. Stateful services on stateless clustered edge
US9866473B2 (en) 2014-11-14 2018-01-09 Nicira, Inc. Stateful services on stateless clustered edge
US10044617B2 (en) 2014-11-14 2018-08-07 Nicira, Inc. Stateful services on stateless clustered edge
US9485310B1 (en) * 2014-12-23 2016-11-01 EMC IP Holding Company LLC Multi-core storage processor assigning other cores to process requests of core-affined streams
US9690576B2 (en) * 2015-02-11 2017-06-27 Dell Software, Inc. Selective data collection using a management system
US20160255013A1 (en) * 2015-02-27 2016-09-01 Ixia Dynamic Resource Management For Load Balancing In Network Packet Communication Systems
US10250562B1 (en) 2015-03-31 2019-04-02 Juniper Networks, Inc. Route signaling driven service management
US10210058B1 (en) 2015-03-31 2019-02-19 Juniper Networks, Inc. Application aware inter-chassis redundancy
US10594743B2 (en) 2015-04-03 2020-03-17 Nicira, Inc. Method, apparatus, and system for implementing a content switch
US20160301575A1 (en) * 2015-04-07 2016-10-13 Quanta Computer Inc. Set up and verification of cabling connections in a network
US10476982B2 (en) 2015-05-15 2019-11-12 Cisco Technology, Inc. Multi-datacenter message queue
US10034201B2 (en) * 2015-07-09 2018-07-24 Cisco Technology, Inc. Stateless load-balancing across multiple tunnels
US20170032300A1 (en) * 2015-07-31 2017-02-02 International Business Machines Corporation Dynamic selection of resources on which an action is performed
US9900377B2 (en) * 2015-08-07 2018-02-20 International Business Machines Corporation Dynamic healthchecking load balancing gateway
US10169172B2 (en) * 2015-08-11 2019-01-01 International Business Machines Corporation Passive detection of live systems during controller failover in distributed environments
US9942153B2 (en) * 2015-08-14 2018-04-10 Dell Products L.P. Multiple persistant load balancer system
MX2018002689A (es) 2015-09-25 2018-04-13 Deutsche Telekom Ag Metodo para manejo mejorado de al menos un intercambio de comunicacion entre una red de telecomunicaciones y al menos un equipo de usuario, red de telecomunicaciones, equipo de usuario, sistema, programa y producto de programa de computadora.
US10666574B2 (en) 2015-09-28 2020-05-26 Amazon Technologies, Inc. Distributed stream-based database triggers
US10623319B1 (en) 2015-09-28 2020-04-14 Amazon Technologies, Inc. Load rebalancing in a network-based system
US10033645B2 (en) * 2015-09-29 2018-07-24 Dell Products L.P. Programmable data plane hardware load balancing system
US10205677B2 (en) 2015-11-24 2019-02-12 Cisco Technology, Inc. Cloud resource placement optimization and migration execution in federated clouds
US10084703B2 (en) 2015-12-04 2018-09-25 Cisco Technology, Inc. Infrastructure-exclusive service forwarding
US10296394B2 (en) * 2015-12-04 2019-05-21 Nec Corporation Consistent hashing
US10367914B2 (en) 2016-01-12 2019-07-30 Cisco Technology, Inc. Attaching service level agreements to application containers and enabling service assurance
US20170214627A1 (en) * 2016-01-21 2017-07-27 Futurewei Technologies, Inc. Distributed Load Balancing for Network Service Function Chaining
JP6126259B1 (ja) * 2016-02-25 2017-05-10 日本電信電話株式会社 監視装置、監視方法、及びプログラム
US10291706B1 (en) * 2016-03-24 2019-05-14 EMC IP Holding Company LLC Container image distribution acceleration
US10432709B2 (en) * 2016-03-28 2019-10-01 Industrial Technology Research Institute Load balancing method, load balancing system, load balancing device and topology reduction method
US10574741B2 (en) * 2016-04-18 2020-02-25 Nokia Technologies Oy Multi-level load balancing
US10432532B2 (en) 2016-07-12 2019-10-01 Cisco Technology, Inc. Dynamically pinning micro-service to uplink port
US10382597B2 (en) 2016-07-20 2019-08-13 Cisco Technology, Inc. System and method for transport-layer level identification and isolation of container traffic
US10567344B2 (en) 2016-08-23 2020-02-18 Cisco Technology, Inc. Automatic firewall configuration based on aggregated cloud managed information
US10938668B1 (en) * 2016-09-30 2021-03-02 Amazon Technologies, Inc. Safe deployment using versioned hash rings
KR102567971B1 (ko) * 2016-11-10 2023-08-17 삼성전자주식회사 스토리지 어레이를 공유하는 다수의 서버 노드들을 포함하는 메모리 시스템 및 그 동작 방법
CN114826577A (zh) 2016-11-14 2022-07-29 诚信保安服务有限责任公司 设备的安全供应和管理
CN108173775A (zh) * 2016-12-08 2018-06-15 北京京东尚科信息技术有限公司 用于服务器限流的方法与系统
US10742746B2 (en) * 2016-12-21 2020-08-11 Nicira, Inc. Bypassing a load balancer in a return path of network traffic
CN108259370A (zh) * 2016-12-28 2018-07-06 航天信息股份有限公司 数据传输的方法及装置
US10735996B2 (en) * 2017-01-23 2020-08-04 Parallel Wireless, Inc. Systems and methods for a scalable heterogeneous network orchestrator
US10320683B2 (en) 2017-01-30 2019-06-11 Cisco Technology, Inc. Reliable load-balancer using segment routing and real-time application monitoring
US9787671B1 (en) * 2017-01-30 2017-10-10 Xactly Corporation Highly available web-based database interface system
US10671571B2 (en) 2017-01-31 2020-06-02 Cisco Technology, Inc. Fast network performance in containerized environments for network function virtualization
US10476945B2 (en) * 2017-02-01 2019-11-12 Juniper Networks, Inc. Consistent flow assignment in load balancing
US11005731B2 (en) 2017-04-05 2021-05-11 Cisco Technology, Inc. Estimating model parameters for automatic deployment of scalable micro services
US10491520B2 (en) * 2017-04-06 2019-11-26 Ca, Inc. Container-based software appliance
US10693951B2 (en) * 2017-06-01 2020-06-23 Salesforce.Com, Inc. Decentralized, resource aware load distribution in a distributed system
US10713223B2 (en) * 2017-06-01 2020-07-14 Salesforce.Com, Inc. Opportunistic gossip-type dissemination of node metrics in server clusters
US10382274B2 (en) 2017-06-26 2019-08-13 Cisco Technology, Inc. System and method for wide area zero-configuration network auto configuration
US10439877B2 (en) 2017-06-26 2019-10-08 Cisco Technology, Inc. Systems and methods for enabling wide area multicast domain name system
US10250493B2 (en) 2017-07-14 2019-04-02 Nicira, Inc. Asymmetric network elements sharing an anycast address
US10432513B2 (en) * 2017-07-14 2019-10-01 Nicira, Inc. Asymmetric network elements sharing an anycast address
US10425288B2 (en) 2017-07-21 2019-09-24 Cisco Technology, Inc. Container telemetry in data center environments with blade servers and switches
US10601693B2 (en) 2017-07-24 2020-03-24 Cisco Technology, Inc. System and method for providing scalable flow monitoring in a data center fabric
US10541866B2 (en) 2017-07-25 2020-01-21 Cisco Technology, Inc. Detecting and resolving multicast traffic performance issues
US11296984B2 (en) 2017-07-31 2022-04-05 Nicira, Inc. Use of hypervisor for active-active stateful network service cluster
US10951584B2 (en) 2017-07-31 2021-03-16 Nicira, Inc. Methods for active-active stateful network service cluster
US11570092B2 (en) 2017-07-31 2023-01-31 Nicira, Inc. Methods for active-active stateful network service cluster
US10834230B2 (en) * 2017-08-25 2020-11-10 International Business Machines Corporation Server request management
CN109510855B (zh) * 2017-09-15 2020-07-28 腾讯科技（深圳）有限公司 事件分发系统、方法及装置
US10805181B2 (en) 2017-10-29 2020-10-13 Nicira, Inc. Service operation chaining
US11012420B2 (en) 2017-11-15 2021-05-18 Nicira, Inc. Third-party service chaining using packet encapsulation in a flow-based forwarding element
CN107743152B (zh) * 2017-12-07 2020-09-22 南京易捷思达软件科技有限公司 一种OpenStack云平台中负载均衡器的高可用的实现方法
US10705882B2 (en) 2017-12-21 2020-07-07 Cisco Technology, Inc. System and method for resource placement across clouds for data intensive workloads
WO2019125483A1 (en) * 2017-12-22 2019-06-27 Nokia Technologies Oy Designs of an mptcp-aware load balancer and load balancer using the designs
US11595474B2 (en) 2017-12-28 2023-02-28 Cisco Technology, Inc. Accelerating data replication using multicast and non-volatile memory enabled nodes
US10659252B2 (en) 2018-01-26 2020-05-19 Nicira, Inc Specifying and utilizing paths through a network
US10797910B2 (en) 2018-01-26 2020-10-06 Nicira, Inc. Specifying and utilizing paths through a network
CN108306771B (zh) * 2018-02-09 2021-06-18 腾讯科技（深圳）有限公司 日志上报方法、装置及系统
US11153122B2 (en) 2018-02-19 2021-10-19 Nicira, Inc. Providing stateful services deployed in redundant gateways connected to asymmetric network
JP6888567B2 (ja) * 2018-02-26 2021-06-16 日本電信電話株式会社 通信装置、通信方法、及びプログラム
US11005925B2 (en) * 2018-02-28 2021-05-11 International Business Machines Corporation Load balancing with power of random choices
US11012410B2 (en) * 2018-03-13 2021-05-18 Charter Communications Operating, Llc Distributed denial-of-service prevention using floating internet protocol gateway
US10805192B2 (en) 2018-03-27 2020-10-13 Nicira, Inc. Detecting failure of layer 2 service using broadcast messages
US10728174B2 (en) 2018-03-27 2020-07-28 Nicira, Inc. Incorporating layer 2 service between two interfaces of gateway device
US10511534B2 (en) * 2018-04-06 2019-12-17 Cisco Technology, Inc. Stateless distributed load-balancing
US11876684B1 (en) * 2018-05-22 2024-01-16 Amazon Technologies, Inc. Controlled cross-cell migration of data in cell-based distributed computing architecture
US10728361B2 (en) 2018-05-29 2020-07-28 Cisco Technology, Inc. System for association of customer information across subscribers
US10904322B2 (en) 2018-06-15 2021-01-26 Cisco Technology, Inc. Systems and methods for scaling down cloud-based servers handling secure connections
US10764266B2 (en) 2018-06-19 2020-09-01 Cisco Technology, Inc. Distributed authentication and authorization for rapid scaling of containerized services
US11019083B2 (en) 2018-06-20 2021-05-25 Cisco Technology, Inc. System for coordinating distributed website analysis
US10680955B2 (en) * 2018-06-20 2020-06-09 Cisco Technology, Inc. Stateless and reliable load balancing using segment routing and TCP timestamps
US10819571B2 (en) 2018-06-29 2020-10-27 Cisco Technology, Inc. Network traffic optimization using in-situ notification system
WO2020014024A1 (en) * 2018-07-07 2020-01-16 Integrity Security Services Llc Scalable certificate management system architectures
US11075984B1 (en) * 2018-07-16 2021-07-27 Amazon Technologies, Inc. Workload management at streaming data service supporting persistent connections for reads
CN110769464A (zh) * 2018-07-25 2020-02-07 慧与发展有限责任合伙企业 分发任务
US10904342B2 (en) 2018-07-30 2021-01-26 Cisco Technology, Inc. Container networking using communication tunnels
US10681091B2 (en) * 2018-07-31 2020-06-09 Juniper Networks, Inc. N:1 stateful application gateway redundancy model
JP6544817B1 (ja) * 2018-07-31 2019-07-17 Quadrac株式会社 サーバ装置及びシステム
US11650862B2 (en) 2018-07-31 2023-05-16 Parallel Wireless, Inc. Service bus for telecom infrastructure
WO2020026335A1 (ja) * 2018-07-31 2020-02-06 Quadrac株式会社 サーバ装置及びシステム
US10855590B2 (en) * 2018-08-31 2020-12-01 Gigamon Inc. Elastic modification of application instances in a network visibility infrastructure
US11595250B2 (en) 2018-09-02 2023-02-28 Vmware, Inc. Service insertion at logical network gateway
US10944673B2 (en) 2018-09-02 2021-03-09 Vmware, Inc. Redirection of data messages at logical network gateway
US11144340B2 (en) * 2018-10-04 2021-10-12 Cisco Technology, Inc. Placement of container workloads triggered by network traffic for efficient computing at network edge devices
US10880218B2 (en) 2018-11-21 2020-12-29 Amazon Technologies, Inc. Load balanced access to distributed endpoints using resiliently advertised global network addresses
US11418581B2 (en) * 2019-01-31 2022-08-16 T-Mobile Usa, Inc. Load balancer shared session cache
US10949244B2 (en) 2019-02-22 2021-03-16 Vmware, Inc. Specifying and distributing service chains
US10855580B2 (en) 2019-03-27 2020-12-01 Amazon Technologies, Inc. Consistent route announcements among redundant controllers in global network access point
US11144226B2 (en) 2019-04-11 2021-10-12 Samsung Electronics Co., Ltd. Intelligent path selection and load balancing
US11570100B2 (en) * 2019-04-25 2023-01-31 Advanced New Technologies Co., Ltd. Data processing method, apparatus, medium and device
US11540170B2 (en) * 2019-05-20 2022-12-27 Commscope Technologies Llc Load-testing a cloud radio access network
US11216190B2 (en) 2019-06-10 2022-01-04 Samsung Electronics Co., Ltd. Systems and methods for I/O transmissions in queue pair-based NVMeoF initiator-target system
US11704617B2 (en) * 2019-06-20 2023-07-18 Stripe, Inc. Systems and methods for modeling and analysis of infrastructure services provided by cloud services provider systems
US10908834B2 (en) * 2019-06-28 2021-02-02 Hitachi, Ltd. Load balancing for scalable storage system
US11301316B2 (en) 2019-07-12 2022-04-12 Ebay Inc. Corrective database connection management
US11038952B2 (en) 2019-07-12 2021-06-15 Ebay Inc. Connection service discovery and load rebalancing
US11240294B2 (en) 2019-08-23 2022-02-01 Samsung Electronics Co., Ltd. Systems and methods for spike detection and load balancing resource management
US11159343B2 (en) 2019-08-30 2021-10-26 Vmware, Inc. Configuring traffic optimization using distributed edge services
US11070469B1 (en) * 2019-09-11 2021-07-20 Juniper Networks, Inc. Scaling border gateway protocol services
US11140081B2 (en) * 2019-10-01 2021-10-05 At&T Intellectual Property I, L.P. Extending distributed hash table-based software network functions to switching hardware
KR102235100B1 (ko) * 2019-10-08 2021-04-01 브이에스아이 주식회사 공유 버스를 통해 복수의 서버들에 예비 통신로를 제공할 수 있는 시스템
US11038793B2 (en) 2019-10-15 2021-06-15 Cisco Technology, Inc. Service assurance of ECMP using virtual network function hashing algorithm
US11025534B2 (en) * 2019-10-15 2021-06-01 Cisco Technology, Inc. Service-based node-centric ECMP health
US20210127296A1 (en) * 2019-10-25 2021-04-29 Qualcomm Incorporated Reducing feedback latency for network coding in wireless backhaul communications networks
US11140218B2 (en) 2019-10-30 2021-10-05 Vmware, Inc. Distributed service chain across multiple clouds
CN110795250B (zh) * 2019-10-30 2023-05-12 腾讯科技（深圳）有限公司 负载调度方法、装置、设备及存储介质
US11283717B2 (en) 2019-10-30 2022-03-22 Vmware, Inc. Distributed fault tolerant service chain
CN111010342B (zh) * 2019-11-21 2023-04-07 天津卓朗科技发展有限公司 一种分布式负载均衡实现方法及装置
US11223494B2 (en) 2020-01-13 2022-01-11 Vmware, Inc. Service insertion for multicast traffic at boundary
US11659061B2 (en) 2020-01-20 2023-05-23 Vmware, Inc. Method of adjusting service function chains to improve network performance
US11153406B2 (en) 2020-01-20 2021-10-19 Vmware, Inc. Method of network performance visualization of service function chains
US11438257B2 (en) 2020-04-06 2022-09-06 Vmware, Inc. Generating forward and reverse direction connection-tracking records for service paths at a network edge
US11429452B2 (en) 2020-04-16 2022-08-30 Paypal, Inc. Method for distributing keys using two auxiliary hashing functions
CN111694663B (zh) * 2020-06-02 2023-11-03 中国工商银行股份有限公司 服务器集群的负载均衡方法、装置及系统
CN113783904B (zh) * 2020-06-09 2023-05-09 比亚迪股份有限公司 负载均衡方法、路由服务器及负载均衡系统
US11606294B2 (en) 2020-07-16 2023-03-14 Vmware, Inc. Host computer configured to facilitate distributed SNAT service
US11616755B2 (en) 2020-07-16 2023-03-28 Vmware, Inc. Facilitating distributed SNAT service
US11611613B2 (en) * 2020-07-24 2023-03-21 Vmware, Inc. Policy-based forwarding to a load balancer of a load balancing cluster
US11902050B2 (en) 2020-07-28 2024-02-13 VMware LLC Method for providing distributed gateway service at host computer
US11451413B2 (en) 2020-07-28 2022-09-20 Vmware, Inc. Method for advertising availability of distributed gateway service and machines at host computer
US11394636B1 (en) 2020-12-10 2022-07-19 Amazon Technologies, Inc. Network connection path obfuscation using global access points
US11140220B1 (en) * 2020-12-11 2021-10-05 Amazon Technologies, Inc. Consistent hashing using the power of k choices in server placement
US11310309B1 (en) 2020-12-11 2022-04-19 Amazon Technologies, Inc. Arc jump: per-key selection of an alternative server when implemented bounded loads
US11734043B2 (en) 2020-12-15 2023-08-22 Vmware, Inc. Providing stateful services in a scalable manner for machines executing on host computers
US11611625B2 (en) 2020-12-15 2023-03-21 Vmware, Inc. Providing stateful services in a scalable manner for machines executing on host computers
CN112799811A (zh) * 2021-01-26 2021-05-14 重庆邮电大学 一种边缘网关的高并发线程池任务调度方法
WO2022187645A1 (en) * 2021-03-05 2022-09-09 Fastly, Inc. System and method for deterministic hash addressing
US11706193B2 (en) * 2021-08-09 2023-07-18 Juniper Networks, Inc. Intelligent flow state synchronization to improve resiliency, availability, and/or performance of redundant network security devices
US11799761B2 (en) 2022-01-07 2023-10-24 Vmware, Inc. Scaling edge services with minimal disruption
WO2024035634A1 (en) * 2022-08-11 2024-02-15 Cisco Technology, Inc. Scalable creation of connections
US11895182B1 (en) 2023-01-23 2024-02-06 Bank Of America Corporation Systems, methods, and apparatuses for dynamically determining data center transmissions by implementing load balancers in an electronic network

Family Cites Families (63)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5774660A (en) * 1996-08-05 1998-06-30 Resonate, Inc. World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network
JP3556476B2 (ja) 1998-07-13 2004-08-18 富士通株式会社 ロードシェアシステム及び処理要求中継プログラムを記録したコンピュータ読み取り可能な記録媒体
US7562110B2 (en) 2001-01-11 2009-07-14 F5 Networks, Inc. File switch and switched file system
JP2003131961A (ja) 2001-07-09 2003-05-09 Hitachi Ltd ネットワークシステム及び負荷分散方法
US20030009559A1 (en) 2001-07-09 2003-01-09 Naoya Ikeda Network system and method of distributing accesses to a plurality of server apparatus in the network system
CN1150464C (zh) * 2001-07-26 2004-05-19 华为技术有限公司 一种在应用层交换中提高服务器响应速度的系统及方法
US7283556B2 (en) 2001-07-31 2007-10-16 Nishan Systems, Inc. Method and system for managing time division multiplexing (TDM) timeslots in a network switch
JP3645852B2 (ja) * 2001-11-19 2005-05-11 Ｎｅｃアクセステクニカ株式会社 負荷分散方法、コンテンツ配信システム及び負荷分散装置
JP2003163689A (ja) * 2001-11-28 2003-06-06 Hitachi Ltd ネットワーク連携情報処理システムおよびその複数負荷分散機間のアクセス移動方法
JP3898498B2 (ja) 2001-12-06 2007-03-28 富士通株式会社 サーバ負荷分散システム
US7644436B2 (en) * 2002-01-24 2010-01-05 Arxceo Corporation Intelligent firewall
US7088718B1 (en) * 2002-03-19 2006-08-08 Cisco Technology, Inc. Server load balancing using IP option field approach to identify route to selected server
US7260645B2 (en) * 2002-04-26 2007-08-21 Proficient Networks, Inc. Methods, apparatuses and systems facilitating determination of network path metrics
US7380002B2 (en) * 2002-06-28 2008-05-27 Microsoft Corporation Bi-directional affinity within a load-balancing multi-node network interface
US7480737B2 (en) * 2002-10-25 2009-01-20 International Business Machines Corporation Technique for addressing a cluster of network servers
US7353276B2 (en) * 2003-02-13 2008-04-01 Microsoft Corporation Bi-directional affinity
WO2004088940A1 (ja) * 2003-03-31 2004-10-14 Fujitsu Limited 負荷分散システム
CN1300986C (zh) * 2003-04-14 2007-02-14 华为技术有限公司 实现快速五七层交换的方法
CN100581157C (zh) * 2003-04-18 2010-01-13 智邦科技股份有限公司 将第七层负载平衡器的工作负荷转移至服务器端来处理的方法
US20040246895A1 (en) 2003-06-09 2004-12-09 Telefonaktiebolaget Lm Ericsson (Publ) Bandwidth-limited supervisory packet transmission to control congestion and call establishment in packet-based networks
US7636917B2 (en) 2003-06-30 2009-12-22 Microsoft Corporation Network load balancing with host status information
US7567504B2 (en) 2003-06-30 2009-07-28 Microsoft Corporation Network load balancing with traffic routing
US7606929B2 (en) 2003-06-30 2009-10-20 Microsoft Corporation Network load balancing with connection manipulation
US20050027862A1 (en) 2003-07-18 2005-02-03 Nguyen Tien Le System and methods of cooperatively load-balancing clustered servers
US20050050187A1 (en) * 2003-09-03 2005-03-03 International Business Machines Corporation Method and apparatus for support of bottleneck avoidance in an intelligent adapter
US20050071469A1 (en) * 2003-09-26 2005-03-31 Mccollom William G. Method and system for controlling egress traffic load balancing between multiple service providers
US20060112170A1 (en) * 2004-05-03 2006-05-25 Craig Sirkin Geo-locating load balancing
US7020090B2 (en) * 2004-06-21 2006-03-28 Cisco Technology, Inc. System and method for loadbalancing in a network environment using feedback information
JP2006195904A (ja) * 2005-01-17 2006-07-27 Sharp Corp 処理実行方法、処理実行システム、処理実行装置、処理要求装置、コンピュータプログラム及び記録媒体
US7496653B2 (en) * 2005-01-31 2009-02-24 International Business Machines Corporation Method, system, and computer program product for providing quality of service guarantees for clients of application servers
US8315172B2 (en) * 2005-12-30 2012-11-20 Telefonaktiebolaget Lm Ericsson (Publ) Monitoring access nodes in a distributed radio access network
US8238237B2 (en) 2007-06-18 2012-08-07 Sony Computer Entertainment Inc. Load balancing distribution of data to multiple recipients on a peer-to-peer network
US8867341B2 (en) 2007-11-09 2014-10-21 International Business Machines Corporation Traffic management of client traffic at ingress location of a data center
US20100036903A1 (en) 2008-08-11 2010-02-11 Microsoft Corporation Distributed load balancer
JP4931881B2 (ja) 2008-08-13 2012-05-16 日本電信電話株式会社 ホワイトリストを利用したサーバ割り当てシステムおよびその方法
CN101364930A (zh) 2008-09-24 2009-02-11 深圳市金蝶中间件有限公司 会话控制方法、装置及系统
KR101104249B1 (ko) * 2008-12-11 2012-01-11 한국전자통신연구원 단말기의 캐리어 선택 방법 및 그것의 호 접속 방법
US8416692B2 (en) 2009-05-28 2013-04-09 Microsoft Corporation Load balancing across layer-2 domains
US8769541B2 (en) * 2009-12-31 2014-07-01 Facebook, Inc. Load balancing web service by rejecting connections
US8549146B2 (en) * 2010-01-28 2013-10-01 Telefonaktiebolaget L M Ericsson (Publ) Stateless forwarding of load balanced packets
JP2011182070A (ja) * 2010-02-26 2011-09-15 Nippon Telegr & Teleph Corp <Ntt> 仮想通信路接続システムおよび仮想通信路接続方法
US8848728B1 (en) * 2010-04-08 2014-09-30 Marvell Israel (M.I.S.L) Ltd. Dynamic load balancing switch architecture
EP2564561B1 (en) 2010-04-30 2019-07-31 Hewlett-Packard Enterprise Development LP Method for routing data packets in a fat tree network
US8499093B2 (en) * 2010-05-14 2013-07-30 Extreme Networks, Inc. Methods, systems, and computer readable media for stateless load balancing of network traffic flows
EP2395710B1 (en) 2010-06-08 2013-11-06 Alcatel Lucent Device and method for data load balancing
JP5489917B2 (ja) 2010-08-23 2014-05-14 日本電信電話株式会社 サーバ負荷分散システム及び方法
US8351329B2 (en) * 2010-09-14 2013-01-08 Cisco Technology, Inc. Universal load-balancing tunnel encapsulation
JP5580706B2 (ja) 2010-09-29 2014-08-27 Ｋｄｄｉ株式会社 再送制御プロトコルを用いるデータ転送装置、プログラム及び方法
US8711703B2 (en) 2010-10-29 2014-04-29 Telefonaktiebolaget L M Ericsson (Publ) Load balancing in shortest-path-bridging networks
US8755283B2 (en) 2010-12-17 2014-06-17 Microsoft Corporation Synchronizing state among load balancer components
US8780896B2 (en) 2010-12-29 2014-07-15 Juniper Networks, Inc. Methods and apparatus for validation of equal cost multi path (ECMP) paths in a switch fabric system
US8776207B2 (en) * 2011-02-16 2014-07-08 Fortinet, Inc. Load balancing in a network with session information
US8676980B2 (en) 2011-03-22 2014-03-18 Cisco Technology, Inc. Distributed load balancer in a virtual machine environment
CN102882699B (zh) * 2011-07-14 2015-07-29 华为技术有限公司 边缘节点的分配方法和装置及边缘节点控制器
US9590820B1 (en) * 2011-09-02 2017-03-07 Juniper Networks, Inc. Methods and apparatus for improving load balancing in overlay networks
CN103023797B (zh) * 2011-09-23 2016-06-15 百度在线网络技术（北京）有限公司 数据中心系统及装置和提供服务的方法
US9008102B2 (en) * 2012-01-18 2015-04-14 F5 Networks, Inc. Redundancy of network services in restricted networks
US8825867B2 (en) 2012-05-04 2014-09-02 Telefonaktiebolaget L M Ericsson (Publ) Two level packet distribution with stateless first level packet distribution to a group of servers and stateful second level packet distribution to a server within the group
US9325785B2 (en) 2012-06-29 2016-04-26 Rodolfo Kohn Device, system, and method for client-governed session persistency between one or more clients and servers of a data center
US20140025800A1 (en) * 2012-07-23 2014-01-23 Radisys Corporation Systems and methods for multi-blade load balancing
EP2747386A1 (en) 2012-12-20 2014-06-25 Telefonica S.A. Method and System for the creation, modification and removal of a distributed virtual customer premises equipment
US10069903B2 (en) * 2013-04-16 2018-09-04 Amazon Technologies, Inc. Distributed load balancer
US10038626B2 (en) 2013-04-16 2018-07-31 Amazon Technologies, Inc. Multipath routing in a distributed load balancer

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102530913B1 (ko) * 2023-02-08 2023-05-10 주식회사 파이오링크 패킷의 콘텐츠 기반으로 dsr 로드 밸런싱을 수행하는 방법 및 패킷 콘텐츠 기반 dsr 로드 밸런싱 시스템

Also Published As

Publication number Publication date
JP2017184272A (ja) 2017-10-05
US10069903B2 (en) 2018-09-04
EP3651440B1 (en) 2023-06-07
JP6445621B2 (ja) 2018-12-26
AU2014253953B2 (en) 2016-09-29
KR101790315B1 (ko) 2017-10-26
US11843657B2 (en) 2023-12-12
EP2987304A4 (en) 2016-11-23
KR101863024B1 (ko) 2018-05-30
BR112015026342A2 (pt) 2017-07-25
CA2909621C (en) 2019-06-04
EP2987304A1 (en) 2016-02-24
US20140310418A1 (en) 2014-10-16
AU2014253953A1 (en) 2015-11-12
SG11201508556RA (en) 2015-11-27
BR112015026342B1 (pt) 2022-12-06
JP6194100B2 (ja) 2017-09-06
WO2014172500A1 (en) 2014-10-23
CN105308929A (zh) 2016-02-03
EP3651440A1 (en) 2020-05-13
US20180375928A1 (en) 2018-12-27
KR20150140819A (ko) 2015-12-16
CN110166568A (zh) 2019-08-23
AU2016277754A1 (en) 2017-02-02
CA2909621A1 (en) 2014-10-23
JP2016518081A (ja) 2016-06-20
CN110166568B (zh) 2022-04-15
AU2016277754B2 (en) 2018-02-01
BR112015026342A8 (pt) 2019-12-24
CN105308929B (zh) 2019-06-07
EP2987304B1 (en) 2020-01-22

Similar Documents

Publication Publication Date Title
KR101863024B1 (ko) 분산 로드 밸런서
US10999184B2 (en) Health checking in a distributed load balancer
JP6030807B2 (ja) 分散型ロードバランサでの接続公開
JP6169251B2 (ja) 分散型ロードバランサにおける非対称パケットフロー
US9432245B1 (en) Distributed load balancer node architecture
US9559961B1 (en) Message bus for testing distributed load balancers
US9871712B1 (en) Health checking in a distributed load balancer

Legal Events

Date Code Title Description
A107 Divisional application of patent
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant