Sun Cluster 3.0 12/01 개념

로드 밸런싱 정책

로드 밸런싱은 응답 시간과 처리량에서 확장 가능 서비스의 성능을 향상시킵니다.

확장 가능 데이터 서비스에는 puresticky 두 가지 서비스가 있습니다. pure 서비스는 포함된 모든 인스턴스가 클라이언트 요청 에 응답할 수 있는 서비스입니다. sticky 서비스는 클라이언트마다 동일한 인스턴스로 요청을 보내는 서비스입니다. 이 요청은 다른 인스턴스에 전달되지 않습니다.

pure 서비스는 가중(weighted) 로드 밸런싱 정책을 사용합니다. 이 로드 밸런싱 정책에서는 기본적으로 클라이언트 요청이 클러 스터의 서버 인스턴스에 고르게 분산됩니다. 예를 들어, 3-노드 클러스터에서 각 노드가 처리할 수 있는 로드의 크기가 1이라고 가정합니다. 각 노드는 해당 서비스를 위해 모든 클라이언트로부터 받는 요청의 1/3에 해당하는 서비스를 제공합니다. 관리자는 언제든지 scrgadm(1M) 명령 인터페이스나 SunPlex Manager GUI를 통해 노드의 처리량을 변경할 수 있습니다.

sticky 서비스에는 일반 sticky와 와일드카드 sticky 두 가지 종류가 있습니다. Sticky 서비스에서는 여러 번의 TCP 연결에 걸쳐 진행되는 동시 응용프로그램 레벨 세션이 상태 메모리(응용 프로그램 세션 상태)를 공유할 수 있습니다.

일반 sticky 서비스에서는 클라이언트가 여러 개의 동시 TCP 연결 사이에 상태를 공유할 수 있습니다. 서버 인스턴스가 단일 포트를 통해 서비스 요청을 받을 경우에 클라이언트 상태를 "sticky"라고 합니다. 서비스가 온라인 상태인 동안 인스턴스가 계속 실행되어 액세스할 수 있고 로드 밸런싱 정책이 변경되지 않으면, 클라이언트가 모든 요청을 동일한 서버 인스턴스로 보낼 수 있습니다.

예를 들어, 클라이언트의 웹 브라우저는 서로 다른 세 개의 TCP 연결을 사용하여 공유 IP 주소의 포트 80에 연결하지만, 서비스에서는 연결 사이에 캐시된 세션 정보를 교환합니다.

sticky 정책을 일반화하면 동일한 인스턴스에서 백그라운드로 세션 정보를 교환하는 여러 개의 확장 가능 서비스로 확장됩니다. 이 턴스에서 백그라운드로 세션 정보를 교환하면, 동일한 노드에서 서로 다른 포트를 통해 서비스 요청을받는 여러 서버 인스턴스에 대하여 클라이언트가 "sticky"하다고 합니다.

예를 들어, 전자 상거래 사이트의 고객이 포트 80에서 일반 HTTP를 사용하여 상품을 바구니에 채우지만, 바구니의 상품 대금을 신용 카드로 지불할 경우에는 보안 데이터를 보내기 위해 포트 443의 SSL로 전환합니다.

와일드 카드 sticky 서비스는 동적으로 할당되는 포트 번호를 사용하지만, 그래도 클라이언트의 요청이 동일한 노드에 전달될 것이라고 예상합니다. 이러한 경우에는 클라이언트가 동일한 IP 주소의 여러 포트에 대하여 "sticky wildcard" 상태입니다.

이러한 정책의 좋은 예로 수동 모드 FTP가 있습니다. 클라이언트가 FTP 서버의 포트 21로 연결하면, 서버가 동적 포트 범위에 있 는 수신자 포트 서버에 다시 연결하도록 알립니다. 이 IP 주소에 대한 모든 요청은 서버가 제어 정보를 통해 클라이언트에 알려준것과 동일한 노드로 전달됩니다.

이러한 sticky 정책 각각에 대해 기본적으로 가중(weighted) 로드 밸런싱 정책이 적용됩니다. 따라서 클라이언트의 초기 요청은로드 밸런서가 지시하는 인스턴스로 전달됩니다. 클라이언트가 인스턴스를 실행하는 노드에 적응한 후에 계속 노드에 액세스할 수 있고 로드 밸런싱 정책이 변경되지만 않으면 이후의 요청이 노드에서 실행되는 인스턴스에 전달됩니다.

특정 로드 밸런싱 정책에 대한 자세한 내용은 아래 설명을 참조하십시오.