test

Sun Cluster 3.0 개념

확장가능 데이터 서비스

확장가능 데이터 서비스는 여러 노드에서 인스턴스가 사용되고 있을 가능성을 수반합니다. 확장가능 서비스는 확장가능 자원 그룹을 이용하여, 확장가능한 서비스가 영향을 받는 네트워크 자원(공유 주소)을 포함하도록 페일오버 자원 그룹과 응용프로그램 자원을 포함시킵니다. 확장가능 자원 그룹은 여러 노드에서 온라인 상태로 있을 수 있으므로 서비스의 여러 인스턴스가 한번에 실행될 수 있습니다. 공유 주소를 호스팅하는 페일오버 자원 그룹은 한번에 한 노드에서만 온라인 상태입니다. 확장가능 서비스에 호스팅하는 모든 노드가 동일한 공유 주소를 사용하여 서비스를 호스팅합니다.

서비스 요청은 단일 네트워크 인터페이스(글로벌 인터페이스 또는 GIF)를 통해 클러스터에 제공되고 로드 밸런싱 정책에 의해 설정된 사전 정의된 몇 가지의 알고리즘 중 하나를 기초로 노드에 분산됩니다. 클러스터는 로드 밸런싱 정책을 사용하여 몇몇 노드 사이의 서비스 부하 균형을 맞추는 로드 밸런싱 정책을 사용할 수 있습니다. 다른 공유 주소에 호스트하는 다른 노드에 여러 개의 GIF가 있을 수 있으므로 유의하십시오.

확장가능 서비스의 경우, 응용프로그램 인스턴스는 몇 개의 노드에서 동시에 실행될 수 있습니다. 글로벌 인터페이스를 호스트하는 노드가 실패할 경우, 글로벌 인터페이스는 다른 노드로 페일오버합니다. 응용프로그램 인스턴스 실행이 실패하는 경우, 인스턴스는 동일한 노드에서 재시작을 시도합니다.

응용프로그램 인스턴스는 동일한 노드에서 재시작될 수 없으며, 사용되지 않는 다른 노드는 서비스를 실행하도록 구성된 경우, 서비스는 사용되는 않는 노드로 페일오버됩니다. 그렇지 않으면, 나머지 노드에서 실행을 계속하여, 서비스 처리량이 줄어들 수 있습니다.

주 -

각 응용프로그램 인스턴스에 대한 TCP 상태는 GIF 노드가 아니라 인스턴스가 있는 노드에 보존됩니다. 그러므로 GIF 노드의 실패는 연결에 영향을 주지 않습니다.

그림 3-4에는 페일오버와 확장가능 자원 그룹의 예와 확장가능 서비스에 대해 그 사이에 존재할 수 있는 종속성이 나와 있습니다 이 예는 세 개의 자원 그룹을 보여줍니다. 페일오버 자원 그룹에는 고가용성 DNS에 대한 응용프로그램 자원과 고가용성 DNS 및 고가용성 Apache 웹 서버에서 사용되는 네트워크 자원이 포함됩니다. 확장가능 자원 그룹에는 Apache 웹 서버의 응용프로그램 인스턴스만 포함됩니다. 확장가능 및 페일오버 자원 그룹 사이에 자원 그룹 종속성(실선)이 있고 모든 Apache 응용프로그램 자원이 공유 주소(실선)인 네트워크 자원 schost-2에 종속된다는 점에 유의하십시오.

그림 3-4 페일오버 및 확장가능 자원 그룹 예

Graphic

확장가능 서비스 구조

클러스터 네트워킹의 기본 목적은 데이터 서비스에 대한 확장성을 제공하는 것입니다. 확장성은 서비스에 대해 제공되는 로드가 증가하는 대로 데이터 서비스는 새로운 노드가 클러스터에 추가되고 새로운 서버 인스턴스가 실행되는 것처럼 이러한 작업로드 증가 시 일정한 응답 시간을 유지할 수 있음을 의미합니다. 그러한 서비스를 확장가능 데이터 서비스라고 합니다. 확장가능 데이터 서비스의 좋은 예는 웹 서비스입니다. 일반적으로, 확장가능 데이터 서비스는 몇 가지의 인스턴스로 구성되며, 각 인스턴스는 클러스터의 서로 다른 노드에서 실행됩니다. 이러한 인스턴스들은 해당 서비스의 원격 클라이언트 관점에서는 하나의 서비스로 작동합니다. 예를 들어, 서로 다른 노드에서 실행되는 몇 개의 httpd 디먼으로 구성되는 확장가능 웹 서비스를 사용할 수 있습니다. httpd 디먼은 클라이언트 요청에 서비스를 제공할 수도 있습니다. 요청에 서비스를 제공하는 디먼은 로드 밸런싱 정책에 따라 다릅니다. 요청에 서비스를 제공한 특정 디먼이 아니라 서비스에서 제공될 클라이언트에 대한 응답이 표시되므로 단일 서비스 형태가 유지됩니다.

확장가능 서비스는 다음으로 구성됩니다.

다음 그림은 확장가능 서비스 구조를 보여줍니다.

그림 3-5 확장가능 서비스 구조

Graphic

글로벌 인터페이스를 호스트하지 않는 노드(프록시 노드)에는 해당되는 루프백 인터페이스에 호스트된 공유 주소가 있습니다. GIF의 패킷은 구성가능한 로드 밸런싱 정책을 기초로 다른 클러스터 노드에 분산됩니다. 가능한 로드 밸런싱 정책은 다음 부분에 설명되어 있습니다.

로드 밸런싱 정책

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

두 가지의 확장가능 데이터 서비스 클래스 pure와 sticky가 있습니다. pure 서비스는 인스턴스가 클라이언트 요청에 응답할 수 있는 서비스입니다. sticky 서비스는 클라이언트가 같은 인스턴스에 요청을 보내는 서비스입니다. 그러한 요청은 다른 인스턴스에 보내지 않아도 됩니다.

pure 서비스는 가중된 로드 밸런싱 정책을 사용합니다. 이 로드 밸런싱 정책에서 클라이언트 요청은 기본적으로 클러스터의 서버 인스턴스에서 일정하게 분산됩니다. 예를 들어, 3-노드 클러스터에서 각 노드의 가중치가 1이라고 가정합시다. 각 노드는 해당 서비스 대신 클라이언트의 요청 중 1/3에 서비스를 제공합니다. 가중치는 언제든지 scrgadm(1M) 명령 인터페이스를 통해 관리자에 의해 변경될 수 있습니다.

sticky 서비스에는 두 가지의 주요 기능인 보통 sticky와 와일드 카드 sticky가 있습니다. Sticky 서비스는 여러 TCP 연결을 거쳐 동시 응용프로그램 레벨 세션이 in-state 메모리(응용프로그램 세션 상태)를 공유할 수 있게 합니다.

보통 sticky 서비스는 클라이언트가 여러 개의 동시 TCP 연결 사이에 상태를 공유할 수 있게 합니다. 클라이언트는 단일 포트에서 청취하는 서버 인스턴스에 대해 "sticky"된다고 합니다. 클라이언트는 인스턴스가 남아 있고 액세스가능한 경우에 자체의 모든 요청이 동일한 서버 인스턴스로 가도록 보장받으며, 로드 밸런싱 정책은 서비스가 온라인인 동안에는 변경되지 않습니다.

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

sticky 정책의 일반화는 동일한 인스턴스의 장면 뒤에서 세션 정보를 교환하는 여러 개의 확장가능 서비스로 확장됩니다. 이러한 서비스가 같은 인스턴스의 장면뒤에서 세션 정보를 교환할 경우, 클라이언트는 서로 다른 포트에서 청취하는 동일 노드의 여러 서버 인스턴스에 대해 "sticky"된다고 합니다.

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

와일드 카드 sticky 서비스는 동적으로 할당된 포트 번호를 사용하지만, 여전히 클라이언트 요청이 같은 노드로 갈 것으로 예상합니다. 클라이언트는 동일한 IP 주소에 대해 포트를 거치는 "sticky 와일드 카드"입니다.

이 정책의 좋은 예는 수동 모드 FTP입니다. 클라이언트는 포트 21의 FTP 서버에 연결되고, 동적 포트 범위의 청취자 포트 서버에 다시 연결하도록 서버에서 알립니다. IP 주소에 대한 모든 요청은 제어 정보를 통해 서버가 클라이언트를 알린 동일 노드로 전송됩니다.

이 sticky 정책 각각에 대해 가중된 로드 밸런싱 정책이 기본적으로 적용되므로 클라이언트의 초기 요청은 로드 밸런서에 의해 지시된 인스턴스에 보내집니다. 인스턴스가 실행되는 노드에 대한 유사성을 클라이언트가 확립하고 나면, 차후 요청은 액세스할 수 있는 경우 그 인스턴스로 보내집니다. 그리고 로드 밸런싱 정책은 변경되지 않습니다.

특정 로드 밸런싱 정책에 대한 추가 세부사항이 아래에 설명되어 있습니다.