test

Sun Cluster 3.0 12/01 개념

데이터 서비스

데이터 서비스는 Oracle이나 iPlanet Web Server와 같이 단일 서버가 아닌 클러스터에서 실행되도록 구성된 다른 회사 응용 프로그램을 나타내는 용어입니다. 데이터 서비스는 응용프로그램, Sun Cluster 구성 파일, 다음과 같은 응용프로그램 작업을 제어하는 Sun Cluster 관리 메소드 등으로 구성됩니다.

그림 3-4에서는 단일 응용프로그램 서버에서 실행되는 응용프로그램(단일 서버 모델)을 클러스터에서 실행되는 동일한 응용프로그램(클러스터 서버 모델)과 비교합니다. 사용자의 관점에서 보면 클러스터 응용프로그램이 더 빠르게 실행될 수 있고 가용성이 높다는 것 외에는 두 구성 사이에 큰 차이가 없습니다.

그림 3-4 표준 및 클러스터 클라이언트/서버 구성 비교

Graphic

단일 서버 모델에서는 응용프로그램이 특정 공용 네트워크 인터페이스(호스트 이름)를 통해 서버에 액세스하도록 구성합니다. 따라서 호스트 이름이 물리적 서버와 연결됩니다.

클러스터 서버 모델에서는 공용 네트워크 인터페이스가 논리적 호스트 이름이나 공유 주소입니다. 네트워크 자원은 논리적 호스트 이름과 공유 자원을 모두 나타내는 용어입니다.

일부 데이터 서비스에서는 논리적 호스트 이름 또는 공유 주소를 네트워크 인터페이스로 지정해야 합니다. 두 가지를 동일하게 사용할 수 없습니다. 그 외의 데이터 서비스에서는 논리적 호스트 이름이나 공유 주소를 지정할 수 있습니다. 지정하는 인터페이스 종류에 대한 자세한 내용은 각 데이터 서비스에 대한 설치 및 구성을 참조하십시오.

네트워크 자원은 특정 물리적 서버에만 연결되는 것이 아니고 물리적 서버 사이를 이동할 수 있습니다.

네트워크 자원은 처음에 하나의 노드(1차)와 연결됩니다. 1차 노드에 장애가 발생하면 네트워크 자원과 응용프로그램 자원이 다른 클러스터 노드(2차)로 페일오버합니다. 네트워크 자원이 페일오버하면 잠시 지연된 후에 응용프로그램 자원이 2차 노드에서 계속 실행됩니다.

그림 3-5에서는 단일 서버 모델과 클러스터 서버 모델을 비교합니다. 클러스터 서버 모델에서는 네트워크 자원(이 예에서는 논리적 호스트 이름)이 둘 이상의 클러스터 노드 사이에 이동할 수 있습니다. 응용프로그램은 특정 서버와 연결된 호스트 이름 대신 논리적 호스트 이름을 사용하도록 구성됩니다.

그림 3-5 고정 호스트 이름과 논리 호스트 이름 비교

Graphic

공유 주소도 처음에는 하나의 노드와 연결됩니다. 이 노드를 GIN(Global Interface Node)이라고 합니다. 공유 주소는 클러스터에 대한 단일 네트워크 인터페이스로 사용됩니다. 이러한 인터페이스를 글로벌 인터페이스라고 합니다.

논리적 호스트 이름 모델과 확장 가능 서비스 모델 사이의 차이는 확장 가능 서비스 모델에서는 각 노드에도 루프백 인터페이스에 활성으로 구성된 공유 주소가 있다는 것입니다. 이러한 구성 때문에 여러 노드에 대하여 여러 데이터 서비스 인스턴스를 동시에 실행할 수 있습니다. "확장 가능 서비스"는 클러스터 노드를 추가하여 응용프로그램에 CPU 기능을 추가하는 방법으로 성능을 확장할 수 있는 기능입니다.

GIN에 장애가 발생하면 응용프로그램 인스턴스를 실행하는 다른 노드로 공유 주소를 변경하고 변경한 노드를 새 GIN으로 만들 수 있습니다. 아니면 이전에 응용프로그램을 실행하지 않던 다른 클러스터 노드로 페일오버할 수 있습니다.

그림 3-6에서는 단일 서버 구성과 확장 가능한 클러스터 서비스 구성을 비교합니다. 확장 가능 서비스 구성에서는 모든 노드에 대한 공유 주소가 있습니다. 페일오버 데이터 서비스에 논리적 호스트 이름을 사용하는 방법과 유사한 방법으로 특정 서버와 연결된 호스트 이름 대신 이 공유 주소를 사용하도록 응용프로그램이 구성됩니다.

그림 3-6 고정 호스트 이름과 공유 주소 비교

Graphic

데이터 서비스 방법

Sun Cluster 소프트웨어는 여러 가지 서비스 관리 메소드를 지원합니다. 이 메소드는 Resource Group Manager(RGM)의 제어에 따라 실행되어 클러스터 노드의 응용프로그램을 시작하고 중지하고 모니터합니다. 클러스터 프레임워크 소프트웨어 및 멀티호스트 디스크와 함께 이 메소드를 사용하면 응용프로그램이 페일오버 또는 확장 가능 데 이터 서비스가 될 수 있습니다.

또한 RGM은 응용프로그램의 인스턴스 및 네트워크 자원(논리 호스트이름 및 공유 주소)과 같은 클러스터 내의 자원도 관리합니다.

Sun Cluster 소프트웨어에서 제공하는 메소드 외에 SunPlex 시스템에서도 API와 여러 가지 데이터 서비스 개발 도구를 제공합니다. 이 도구를 사용하면 Sun Cluster 소프트웨어에서 다른 응용프로그램을 가용성이 높은 데이터 서비스로 실행할 수 있도록 응용프로그램 프로그래머가 필요한 데이터 서비스 메소드를 개발할 수 있습니다.

Resource Group Manager(RGM)

RGM은 데이터 서비스(응용프로그램)를 자원 유형으로 구현하여 자원으로 관리합니다. 이 구현은 Sun에서 제공되거나 개발자가 일반 데이터 서비스 템플릿, DSDL API(데이터 서비스 개발 라이브러리 API) 또는 RMAPI(Resource Management API)를 사용하여 작성합니다. 클러스터 관리자는 resource groups라는 컨테이너에 자원을 만들어 관리합니다. RGM은 클러스터 멤버쉽 변경에 대한 응답으로 선택된 노드에서 자원을 정지하였다가 시작합니다.

RGM은 자원과 자원 그룹을 대상으로 작업을 합니다. RGM 작업을 수행하면 자원과 자원 그룹의 상태가 온라인 및 오프라인으로 전환됩니다. 자원과 자원 그룹에 적용할 수 있는 상태와 설정에 대한 자세한 설명은 "자원 및 자원 그룹의 상태와 설정" 단원을 참조하십시오.

페일오버 데이터 서비스

데이터 서비스가 실행되는 노드에 장애가 발생하면 사용자의 조작 없이 자동으로 서비스가 다른 작업 노드로 이동됩니다. 페일오버 서비스는 페일오버 자원 그룹을 사용합니다. 이 자원 그룹은 응용프로그램 인스턴스 자원 및 네트워크 자원(논리 호스트 이름)을 위한 컨테이너입니다. 논리 호스트 이름은 하나의 노드에서 구성될 수 있는 IP 주소로, 나중에 원래 노드에서 자동으로 구성이 중지되고 다른 노드에서 구성이 시작됩니다.

페일오버 데이터 서비스의 경우에는 응용프로그램 인스턴스가 단일 노드에서만 실행됩니다. 결함 모니터가 오류를 발견하면, 데이 터 서비스가 구성된 방법에 따라 동일한 노드에서 인스턴스를 다시 시작하거나 다른 노드에서 인스턴스를 시작합니다(페일오버).

확장 가능 데이터 서비스

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

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

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

동일한 노드에서 응용프로그램 인스턴스를 다시 시작할 수 없고, 사용되지 않는 다른 노드가 서비스를 실행하도록 구성되어 있으면, 서비스가 사용되는 않는 노드로 페일오버됩니다. 그렇지 않으면 계속 나머지 노드에서 실행되어 서비스 처리량이 감소할 수 있습니다.

주 -

각 응용프로그램 인스턴스에 대한 TCP 상태는 글로벌 인터페이스 노드에 보존되지 않고 인스턴스가 있는 노드에 보존됩니다. 따라서 글로벌 인터페이스 노드에 장애가 발생해도 연결에는 영향을 주지 않습니다.

그림 3-7은 페일오버 자원 그룹과 확장 가능 자원 그룹 및 확장 가능 서비스를 위한 둘 사이의 관계에 대한 예입니다. 이 예에는 세 가지 자원 그룹이 있습니다. 페일오버 자원 그룹에는 가용성이 높은 DNS를 위한 응용프로그램 자원과 가용성이 높은 DNS 및 가 용성이 높은 Apache Web Server에서 사용하는 네트워크 자원이 포함됩니다. 확장 가능 자원 그룹에는 Apache Web Server의 응용프로그램 인스턴스만 포함됩니다. 확장 가능 자원 그룹과 페일오버 자원 그룹 사이에는 자원 그룹 의존 관계가 있고(실선) Apache 응용프로그램 자원은 모두 공유 주소인 네트워크 자원 schost-2를 사용합니다(점선).

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

Graphic

확장 가능 서비스 아키텍처

클러스터 네트워킹의 기본 목적은 데이터 서비스에 확장성을 제공하는 것입니다. 확장성은 서비스에 요청되는 로드가 증가할 경우 에 증가하는 워크로드에 맞게 새로운 노드를 클러스터에 추가하고 새로운 서버 인스턴스를 실행하여 데이터 서비스가 일정한 응답시간을 유지하는 기능을 의미합니다. 이러한 서비스를 확장 가능 데이터 서비스라고 합니다. 확장 가능 데이터 서비스의 좋은 예로 웹 서비스가 있습니다.일반적으로 확장 가능 데이터 서비스는 각각 서로 다른 클러스터 노드에서 실행되는 여러 개의 인스턴스로 구성됩니다. 해당 서비스의 원격 클라이언트 관점에서는 이러한 모든 인스턴스가 하나의 서비스로 작동하면서 서비스의 기능을 구현합니다. 예를 들어, 서로 다른 노드에서 실행되는 여러 개의 httpd 데몬으로 확장 가능한 웹 서비스를 구성할 수 있습니다. 그러면 모든 httpd 데몬이 클라이언트 요청에 서비스를 제공할 수 있습니다. 요청에 서비스를 제공하는 데몬은 로드 밸런싱 정책에 의해 결정됩니다. 클라이언트에 응답이 전달될 때는 요청에 대하여 서비스를 제공하는 특정 데몬이 표시되는 것이 아니고 서비스로부터 전달되는 것처럼 표시되기 때문에 하나의 서비스로 표시됩니다.

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

다음 그림은 확장 가능 서비스의 아키텍처입니다.

그림 3-8 확장 가능 서비스 아키텍처

Graphic

글로벌 인터페이스를 호스트하지 않는 노드(프록시 노드)에는 자체 루프백 인터페이스에 대하여 호스트되는 공유 주소가 있습니다. 구성할 수 있는 로드 밸런싱 정책에 따라 글로벌 인터페이스에 전달되는 패킷이 다른 클러스터 노드에 분산됩니다. 구성할 수 있 는 로드 밸런싱 정책은 다음 단락에서 설명합니다.

로드 밸런싱 정책

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

확장 가능 데이터 서비스에는 pure 및 sticky 두 가지 서비스가 있습니다. 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) 로드 밸런싱 정책이 적용됩니다. 따라서 클라이언트의 초기 요청은로드 밸런서가 지시하는 인스턴스로 전달됩니다. 클라이언트가 인스턴스를 실행하는 노드에 적응한 후에 계속 노드에 액세스할 수 있고 로드 밸런싱 정책이 변경되지만 않으면 이후의 요청이 노드에서 실행되는 인스턴스에 전달됩니다.

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

페일백 설정

자원 그룹은 한 노드에서 다른 노드로 페일오버됩니다. 그러면 초기의 2차 노드가 새로운 1차 노드가 됩니다. 페일백 설정은 초기 1차 노드가 다시 온라인 상태가 될 때 수행되는 작업을 지정합니다. 초기 1차 노드가 다시 1차 노드가 되는 페일백 옵션 또는 현재 1차 노드를 그대로 유지하는 옵션이 있습니다. Failback 자원 그룹 등록 정보 설정을 사용하여 원하는 옵션을 지정합니다.

일부 인스턴스에서는 자원 그룹을 호스트하는 원래 노드에 장애가 발생하여 다시 부트하는 과정을 반복하면 페일백 설정으로 인해 자원 그룹에 대한 가용성이 떨어질 수 있습니다.

데이터 서비스 결함 모니터

각 SunPlex 데이터 서비스에는 주기적으로 데이터 서비스를 확인하여 안전 상태를 판단하는 결함 모니터가 있습니다. 결함 모니터는 응용프로그램 데몬이 실행되고 있는지 그리고 클라이언트에 서비스가 제공되고 있는지를 확인합니다. 프로브에서 반환되는 정보에 따라 데몬 재시작이나 페일오버 실행과 같이 사전 정의된 작업이 시작될 수 있습니다.