Print-friendly Version

문서 색인

GlassFish Java EE 응용 프로그램 서버 버전 2에는 강화된 클러스터링 기능 외에도 다양한 새 기능들이 포함되어 있습니다. 새 클러스터링 기능을 사용하면 메모리 내 세션 상태 복제를 통해 배포 아키텍처를 위한 고가용성 및 확장성을 강화할 수 있습니다. 클러스터된 서버 인스턴스는 이 메모리 내 상태 복제를 통해 링 토폴로지에서 세션 상태를 복제하고 복제된 정보를 메모리에 저장합니다.

본 문서에서는 GlassFish 버전 2의 클러스터링 기능에 대해 설명하고, 응용 프로그램을 GlassFish 클러스터에 배포하는 데 도움이 되는 다양한 정보를 제공합니다.

Sun Java System Application Server 9.1은 Sun에서 지원하는 오픈 소스 GlassFish 버전 2 응용 프로그램 서버입니다. 본 문서에서는 이 두 서버를 GlassFish 버전 2로 통칭하여 사용합니다.

• 기본 개념
• 도메인 관리 아키텍처
• 클러스터링 아키텍처
• 일반 페일오버 시나리오
• 클러스터 동적 쉐이프 변경
• 그룹 관리 서비스
• 메모리 복제 구성
• 메모리 복제 구현
• 응용 프로그램 서버 설치
• 클러스터링 구성
• 도메인 검사
• 기존 도메인에 대한 클러스터 지원
• HTTP 로드 밸런서 플러그인
• 결론
• 감사의 말
• 참조

개념적 측면에서 보면 응용 프로그램 서버의 클러스터는 확장성과 가용성을 강화합니다.

하지만 서비스의 고가용성을 제공하려면 소프트웨어 시스템에 다음 기능이 있어야 합니다.

• 시스템은 서비스에서 제공하는 엔티티의 여러 인스턴스를 만들고 실행할 수 있어야 합니다. 응용 프로그램 서버의 경우 서비스에서 제공하는 엔티티가 클러스터에서 실행하도록 구성된 Java EE 응용 프로그램 서버 인스턴스에 해당하고 서비스는 배포된 Java EE 응용 프로그램에 해당합니다.
   
  
• 증가하는 서비스 로드를 수용하기 위해 응용 프로그램 서버 인스턴스를 클러스터에 추가하여 대규모 배포로 시스템을 확장할 수 있어야 합니다.
   
  
• 클러스터의 한 응용 프로그램 서버 인스턴스가 실패하면 서비스가 중단되지 않도록 다른 서버 인스턴스로 페일오버할 수 있어야 합니다. 서버 인스턴스 또는 물리적 시스템의 오류로 인해 전반적인 서비스 품질(QOS)이 떨어질 수 있지만 고가용성 환경에서 완전한 서비스 중단은 용인될 수 없습니다.
   
  
• 특정 프로세스를 통해 사용자 세션 상태가 변경되면 프로세스를 다시 시작하는 동안 세션 상태를 보존해야 합니다. 가장 간단한 방식은 신뢰할 수 있는 세션 상태 복제본을 유지 관리하는 것으로, 프로세스가 중단되더라도 프로세스를 다시 시작할 때 세션 상태를 복구할 수 있습니다. 원리는 고안정성을 갖춘 RAID 스토리지 시스템에 사용된 원리와 유사합니다.
  

종합해 보면, 고가용성을 얻기 위한 이러한 요구 사항으로 인해 시스템의 고효율성을 희생해야 합니다.

GlassFish 응용 프로그램 서버에서는 확장성 및 고가용성이라는 목표를 지원하기 위해 다음 서버 측 엔티티를 제공합니다.

• 서버 인스턴스 – 서버 인스턴스는 Java EE 응용 프로그램을 호스팅하는 Java EE 서버 프로세스(GlassFish 응용 프로그램 서버)입니다. Java EE 사양의 요구 사항에 따라 각 서버 인스턴스는 이를 실행할 다양한 하위 시스템에 맞게 구성됩니다.
   
  
• 노드 에이전트 – 노드 에이전트는 서버 인스턴스가 실행되는 모든 물리적 호스트에서 실행되는 에이전트 프로세스입니다. 이 노드 에이전트는 이 문서의 후반부에서 설명하는 도메인 관리 서버(DAS)의 명령을 받아 서버 인스턴스의 수명 주기를 관리합니다.
   
  
• 클러스터 – 클러스터는 클러스터를 구성하는 서버 인스턴스의 구성을 결정하는 논리적 엔티티입니다. 일반적으로 클러스터 구성에는 클러스터에 있는 모든 서버 인스턴스의 구성 유형이 같다는 의미가 함축되어 있습니다. 관리자는 일반적으로 클러스터를 단일 엔티티로 간주하고, GlassFish 관리 콘솔 또는 명령줄 인터페이스(CLI)를 사용하여 클러스터의 서버 인스턴스를 관리합니다.
  

노드 에이전트, 서버 인스턴스 및 클러스터는 이 문서의 후반부에서 설명한 대로 GlassFish 설치 시 만들 수 있습니다. 클러스터 및 인스턴스는 아래에 설명된 것처럼 도메인 관리 서버(DAS)에서 지정하는 관리 도메인으로 구성됩니다.

GlassFish 클러스터링 아키텍처의 핵심은 관리 도메인 개념입니다. 관리 도메인은 관리자 또는 관리자 그룹의 액세스 권한을 표시한 것입니다. 다음 그림에서는 단일 도메인에서의 도메인 관리 아키텍처에 대한 개요를 보여 줍니다.

그림 1. 도메인 관리 아키텍처

관리 도메인은 이중 속성 엔티티입니다.

• 개발자가 사용하는 이 관리 도메인은 응용 프로그램 및 서비스를 실행하기 위한 완전한 기능을 갖춘 Java EE 프로세스를 제공합니다.
  
  
• 실제 엔터프라이즈급 배포에 사용되는 관리 도메인은 다른 프로세스 구성 및 관리를 위한 프로세스를 제공합니다. 이 경우 관리 도메인은 순수 관리 목적으로 사용할 수 있는 도메인 관리 서버(DAS)의 형식을 취합니다.
  

파일 시스템에서 관리 도메인은 구성 파일 집합으로 이루어져 있으며, 런타임 시에는 관리 도메인 자체와 독립 서버 인스턴스, 클러스터, 응용 프로그램 및 리소스를 관리하는 프로세스 역할을 합니다.

일반적으로 고가용성 설치에는 독립 서버 인스턴스가 아닌 클러스터가 필요합니다. GlassFish 응용 프로그램 서버는 같은 유형의 클러스터들을 제공하기 때문에, 마치 각 클러스터가 단일 엔티티인 것처럼 클러스터를 관리 및 수정할 수 있습니다.

그림에 표시된 것처럼 각 도메인에는 도메인 관리 서버(DAS)가 있고, 이 DAS는 도메인의 Java EE 서버 인스턴스를 관리하는 데 사용됩니다. DAS는 그림 가운데에 있는 관리 노드에서 지원됩니다. 응용 프로그램, 리소스 및 구성 정보는 DAS와 매우 가까운 위치에 저장됩니다. DAS에서 관리하는 구성 정보를 구성 중앙 리포지토리라고 합니다.

각 도메인 프로세스는 물리적 호스트에서 실행되어야 합니다. 도메인 프로세스가 실행되면 도메인은 DAS로 표시됩니다. 마찬가지로, 모든 서버 인스턴스가 물리적 호스트에서 실행되어야 하며 Java 가상 기계(JVM)가 필요합니다. GlassFish 응용 프로그램 서버는 서버 인스턴스를 실행하는 각 시스템에 설치해야 합니다.

그림 오른쪽에 노드 1, 노드 2라는 두 가지 노드가 표시되어 있는데, 각 노드가 두 개의 GlassFish 서버 인스턴스를 호스팅합니다.

각 노드 에이전트는 지정한 도메인의 시스템에 구성되어 있는 인스턴스 수명 주기를 제어합니다. 일반적으로 각 수명 주기는 관리자 요청에 따라 DAS 에서 관리됩니다. DAS 는 각 인스턴스의 실제 수명 주기 관리를 해당 노드 에이전트에 위임합니다. 노드 에이전트는 Java EE 응용 프로그램을 자체 실행하지 않는 단순 프로세스입니다.

인스턴스 수명 주기를 제어하는 것 외에도 노드 에이전트는 담당하는 서버 인스턴스를 모니터링합니다("워치독"). 서버 인스턴스가 실패할 경우 관리자 또는 DAS 의 개입이 필요 없이 해당 노드 에이전트가 이를 백업합니다.

여러 관리 클라이언트가 그림 1 왼쪽에 표시되어 있습니다. DAS 의 관리 인프라는 JMX(Java Management Extension) 기술에 기반합니다. 그리고 DAS의 인프라는 JAX 사양의 계측 수준을 따르며 관리할 리소스를 나타내는 Java 개체인 MBean(Managed Bean)의 형태로 관리 정보를 사용합니다.

MBean은 JMX 표준을 준수하기 때문에 모든 원격 표준 JMX 클라이언트(예: Java SE 5.0 이상에서 배포되는 JConsole)를 통해 찾을 수 있습니다. 그림 1에 표시된 기본 제공 클라이언트에서는 JMX API를 사용하여 도메인을 관리합니다. 이러한 클라이언트가 도메인을 관리하려면 관리 권한이 필요합니다. 다음 관리 클라이언트를 살펴봅니다.

• 관리 콘솔 – 관리 콘솔은 중앙 리포지토리를 관리하기 위한 브라우저 기반 인터페이스입니다. 중앙 리포지토리는 DAS 수준의 구성을 제공합니다.
   
  
• 명령줄 인터페이스 – asadmin 명령은 관리 콘솔의 기능을 똑같이 사용합니다. 또한 도메인이나 노드 에이전트를 만드는 것과 같은 일부 작업은 asadmin을 통해서만 수행할 수 있습니다. 도메인 및 노드 에이전트를 전제로 하는 DAS가 없는 한 관리 콘솔을 실행할 수 없습니다. asadmin 명령은 아키텍처를 부트스트랩하기 위한 방법을 제공합니다.
   
  
• IDE – 그림에서는 NetBeans IDE의 일부인 JSP(JavaServer Page) 편집기의 스냅샷을 보여 줍니다. NetBeans IDE와 같은 도구를 사용하면 개발하는 동안 DAS 를 사용하여 응용 프로그램에 연결하고 이를 관리할 수 있습니다. 또한 NetBeans IDE는 클러스터 모드 배포를 지원할 수도 있습니다. 대부분의 개발자는 개발자 프로필이라고 하는 시스템 및 단일 도메인 내에서 작업합니다. 개발자 프로필에서 DAS 자체는 모든 응용 프로그램의 호스트 역할을 수행합니다.
   
  
• Sun Provisioning Server – Sun Provisioning Server는 초기에 구성된 시스템에서 DAS 를 설치 및 공급하는 데 사용됩니다. 예를 들어 새 시스템을 도입하는 대용량 데이터 센터를 가정합니다. 이 경우 운영 체제를 설치하여 시스템을 초기화한 다음, 필요한 소프트웨어 제품을 설치합니다. 그런 후 특정 요구 사항에 따라 노드 에이전트와 DAS를 만들 수 있습니다. 그 다음 노드 에이전트를 시작하여 시스템을 기존 도메인과 통합합니다. Sun Provisioning Server에서는 이러한 모든 사항을 새 시스템에 수동 설치를 수행할 필요 없이 수행할 수 있습니다.
  

그림 2에서는 런타임을 중심으로 본 GlassFish 클러스터링 아키텍처를 보여 줍니다. 이 관점에서는 아키텍처의 고가용성 측면이 강조됩니다. 그림 2에는 DAS가 표시되어 있지 않고 해당 응용 프로그램 서버 인스턴스의 노드가 클러스터된 인스턴스로 그룹화되어 표시되어 있습니다.

그림 2. 클러스터링 아키텍처 개요

그림 2 상단에는 다양한 전송( HTTP, JMS, RMI-IIOP)이 로드 균형 조정 계층을 통해 클러스터된 인스턴스와 통신하는 모습을 보여 줍니다. 엔터프라이즈 정보 시스템과 같은 사용자 정의 리소스가 Java 커넥터 아키텍처의 리소스 어댑터를 통해 로드 밸런서에 연결됩니다. 그리고 단일 지점 오류 발생 시 사용할 수 있는 중복 장치에서 구현되는 확장성 및 고장 허용 전략을 모두 지원하기 위해 클러스터 전반에 걸쳐 모든 전송의 로드를 균형 있게 조정할 수 있습니다.

그림 하단에는 세션 상태 스토리지의 개념인 고가용성 응용 프로그램 상태 리포지토리가 있습니다. 리포지토리는 HTTP 세션 상태, 정적 EJB 세션 상태 및 단일 사인 온(SSO) 정보 등 세션 상태를 저장합니다. 이 상태 정보는 메모리 복제 또는 데이터베이스를 통해 저장할 수 있습니다.

Sun Microsystems는 고가용성 데이터베이스(HADB) 기술에 기반하여 응용 프로그램 서버를 위한 강력한 고가용성 솔루션을 이전부터 제공해 왔습니다. HADB는 세션 상태 정보를 유지 관리할 수 있도록 99.999%("five nines") 가용성을 제공합니다. 그러나 구현 및 유지 관리 비용이 상대적으로 많이 들고, 자유롭게 사용할 수 있지만 오픈 소스 버전으로 제공되지 않습니다.

오픈 소스 GlassFish 응용 프로그램 서버를 수용하기 위한 보다 단순한 오픈 소스 대체 요청으로 인해 GlassFish 버전 2의 메모리 복제 기능을 제공하게 되었습니다. 메모리 복제는 클러스터 내의 인스턴스를 사용하여 데이터베이스가 아닌 메모리 내에서 서로 간의 상태 정보를 저장합니다. 그러나 HADB 솔루션도 여전히 사용 가능하고, 다양한 설치에서 선호될 수 있습니다.

메모리에서 상태 정보를 유지 관리하는 GlassFish 호환 고장 허용 시스템에는 여러 기능이 필요합니다. 이 시스템은 HTTP 세션 상태, 단일 사인 온(SSO) 상태 및 EJB 세션 상태에 대해 고가용성을 제공해야 합니다. 그리고 기존 HADB 기반 아키텍처와 호환되어야 합니다.

메모리 복제 기능을 사용하면 GlassFish의 클러스터링 기능을 활용하여 설치 및 관리 오버헤드를 크게 줄이면서도 대부분의 HADB 전략 이점을 얻을 수 있습니다.

GlassFish 응용 프로그램 서버에서 클러스터 인스턴스는 링 토폴로지로 구성됩니다. 링의 각 구성원은 메모리 상태 데이터를 링의 다음 구성원인 복제 파트너에게 전송하고 이전 구성원으로부터 상태 데이터를 수신합니다. 상태 데이터는 모든 구성원에서 업데이트되며 링을 따라 복제됩니다. 그림 3에서 토폴로지를 간략히 보여 줍니다.

그림 3. 클러스터링 토폴로지

토폴로지를 링 형태로 구성하는 방법은 인스턴스에 지정하는 이름의 영숫자 순서에 의해 결정됩니다. 따라서 그림 3에 표시된 것처럼 인스턴스 이름을 지정할 경우, 링을 따라 인스턴스 1은 인스턴스 2를, 인스턴스 2는 인스턴스 3을 복제하는 형태로 복제가 이루어집니다.

일반적인 클러스터 토폴로지는 그림 4에 표시되어 있습니다. 그림에는 다른 물리적 시스템에 호스팅된 인스턴스가 표시되어 있습니다. 한 시스템에 인스턴스 1과 3을 배치하고 다른 시스템에 인스턴스 2와 4를 배치하면 가용성이 극대화됩니다. 한 시스템에 심각한 오류가 발생하면 모든 데이터가 다른 시스템에 원래 형태대로 또는 오류가 발생한 시스템의 인스턴스 복제 형태로 보존됩니다.

그림 4. 일반적인 클러스터 토폴로지

GlassFish 응용 프로그램 서버는 오류가 발생하는 경우에도 로드 밸런서에서 특정 정보를 요구하는 일 없이 원활히 수행되도록 설계되었습니다. 예를 들어 인스턴스 1이 실패할 경우, 인스턴스 1에 세션을 라우팅하는 로드 밸런서가 세션을 인스턴스 2에 라우팅해야 하는지를 알 필요가 없습니다. 로드 밸런서는 클러스터의 인스턴스에 대해 페일오버 요청을 발급할 수 있습니다. 이러한 상황은 위치 투명성으로 설명되기도 합니다. 오류에 대한 응답은 클러스터에서 이루어집니다. 로드 밸런서가 작동 중인 인스턴스에 세션을 다시 라우팅하면 필요할 경우 해당 인스턴스가 다른 인스턴스에서 필요로 하는 저장된 세션 정보를 가져옵니다.

로드 밸런서의 페일오버 요청은 다음 두 가지 경우에 해당합니다.

• 사례 1: 세션에서 복제 데이터를 이미 저장하고 있는 인스턴스에 페일오버 요청이 전달됩니다. 이 경우 인스턴스는 세션에 대한 소유권을 가지며 프로세스가 계속 진행됩니다.
   
  
• 사례 2: 필요한 복제 데이터가 없는 인스턴스에 페일오버 요청이 전달됩니다. 이 경우 인스턴스는 데이터를 요청하는 SASE(Self-Addressed-Stamped-Envelope) 형태로 요청을 브로드캐스팅합니다. 복제 데이터가 있는 인스턴스는 데이터를 요청자에게 다시 전송하고 데이터를 수신했다는 확인 메시지가 나타나면 해당 복사본을 삭제합니다. 데이터 교환은 JXTA(Juxtapose) 기술을 통해 수행됩니다.
  

그림 5에 클러스터에 대해 자세히 설명되어 있습니다. 왼쪽에 로드 균형 조정 계층이 있으며, 대개 웹 서버상에 위치합니다. 각 서버 인스턴스의 로컬 캐시가 HTTP 세션 정보를 저장합니다. 캐시는 다음 인스턴스의 복제 캐시에 복사됩니다.

그림 5. 로드 밸런서가 있는 일반 클러스터 토폴로지 큰 이미지를 보려면 여기를 클릭합니다.

그림 6에서는 다시 라우팅된 서버 인스턴스가 세션 상태 데이터에 즉시 액세스하는 페일오버 사례 1에 대해 설명합니다. 그림에서 인스턴스 1이 실패하여 필요한 세션 상태 정보 복제본을 가진 인스턴스 2로 서비스에 대한 로드 밸런서 요청이 라우팅됩니다.

그림 6. 페일오버, 사례 1 큰 이미지를 보려면 여기를 클릭합니다.

그림 7에서는 로드 밸런서가 세션 상태 데이터에 즉시 액세스할 수 없는 서버 인스턴스에 세션을 다시 라우팅하는 페일오버 사례 2에 대해 설명합니다. 그림을 보면 인스턴스 4가 필요한 세션 상태 데이터가 없음을 인식하고 SASE 를 클러스터의 다른 인스턴스에 브로드캐스팅하여 데이터를 요청합니다. 이러한 요청은 노란색 화살표로 표시되어 있습니다.

그림 7. 페일오버, 사례 2 큰 이미지를 보려면 여기를 클릭합니다.

인스턴스 중 하나(그림 7의 인스턴스 2)가 해당 복제본에 필요한 데이터가 있음을 인식하고 SASE 요청에 응답합니다. 인스턴스 2가 세션 데이터를 인스턴스 4에 전송한 다음 해당 세션에 대한 서비스를 수행합니다.

인스턴스가 복제 데이터를 사용하여 세션에 대한 서비스를 수행할 때마다(사례 1 및 사례 2 모두) 최신 버전의 데이터인지 확인하기 위해 복제 데이터를 먼저 테스트합니다.

클러스터의 인스턴스가 실패하거나 관리자에 의해 의도적으로 오프라인 상태가 되면 불가피하게 클러스터의 토폴로지가 변경됩니다.

여기에 제시된 예제의 경우 인스턴스 1이 실패했기 때문에 클러스터의 토폴로지가 세션 캐시 복제를 유지 관리하기 위해 변경되어야 합니다. 그림 8에서 인스턴스 2 및 인스턴스 4는 인스턴스 1이 사라졌음을 인식하게 됩니다. 인스턴스 1이 실패했기 때문에 이 인스턴스와의 통신 시도는 I/O 예외로 인해 실패합니다. 인스턴스를 의도적으로 종료할 경우 인스턴스 1에 대한 파이프를 닫았다는 메시지가 JXTA 기술을 통해 전송됩니다.

그림 8. 인스턴스 실패가 발생한 클러스터 큰 이미지를 보려면 여기를 클릭합니다.

그림 9에 표시된 것처럼, 인스턴스 1 상실에 대한 응답으로 인스턴스 4가 새 복제 파트너를 선택합니다. 인스턴스 4는 기존 연결을 정리하고 인스턴스 2와의 연결을 설정합니다. 그러면 이제 클러스터의 서버 인스턴스 수가 4개에서 3개로 줄어듭니다.

그림 9. :클러스터 동적 쉐이프 변경 큰 이미지를 보려면 여기를 클릭합니다.

규모가 더 작아진 클러스터의 각 인스턴스는 전체 세션 활동량이 동일한 경우 이제 더 많은 작업을 수행합니다. 리소스를 계획할 때에는 메모리 내 복제 기능이 힙 메모리를 사용한다는 점을 인식해야 합니다. 그리고 고가용성을 제공하기 위해 클러스터를 축소해야 할 경우 각 인스턴스에 대해 충분한 메모리 헤드룸이 있어야 합니다.

하나의 인스턴스가 클러스터에 조인 또는 다시 조인하는 경우에는 물론 반대의 프로세스가 이루어집니다. 클러스터의 새 인스턴스가 로드 밸런서로부터 요청을 받으면, 인스턴스가 복제 파트너에 대한 요청을 브로드캐스팅하고 하나를 선택합니다. 그러면 새 인스턴스를 수용하도록 토폴로지가 자동으로 조정됩니다.

그룹 관리 서비스(GMS)는 클러스터 및 클러스터의 구성원 인스턴스에 대한 동적 구성원 정보를 제공합니다. 이 서비스는 Java 기술에 기반한 클러스터링 프레임워크인 Project Shoal을 대부분 사용하여 설계되었습니다. 또한 JXTA 기술에 기반한다는 점도 핵심 사항입니다.

GMS는 GlassFish에서 클러스터 쉐이프 변경 이벤트를 관리하고, 구성원 조인, 정상적인 구성원 종료 또는 구성원 실패와 같은 이벤트를 조정합니다. 메모리 복제는 GMS를 통해 이러한 이벤트에 대한 응답으로 필요한 작업을 수행하고 지속적인 서비스 가용성을 제공합니다.

GMS는 GlassFish 응용 프로그램 서버에서 클러스터 상태를 모니터링하고 메모리 복제 모듈을 지원하는 데 사용됩니다.

요약하면, GMS는 다음 사항을 지원합니다.

• 클러스터 구성원 변경 알림 및 클러스터 상태
   
  
• 클러스터 전체 또는 구성원 간 메시징
   
  
• 복구 구성원 선택, 오류 방지, 여러 오류가 발생하는 경우의 복구 체인 등 복구 지향적인 컴퓨팅
   
  
• 클러스터 구성원에 대한 메시지 교환에 적합하도록 단순하게 구현된 배포된 캐시
   
  
• 그룹 통신 공급자에 연결하기 위한 서비스 공급자 인터페이스(SPI). 기본 공급자는 JXTA 기술에 기반합니다.
   
  
• 타이머 마이그레이션 – GMS는 필요할 경우 실패한 인스턴스의 타이머를 선택할 인스턴스를 선택합니다.
  

클러스터 메모리 복제를 구성하려면 다음 세 단계를 수행해야 합니다.

1. 관리 도메인을 만듭니다. 도메인이 만들어지면 클러스터를 호스팅하는 시스템의 노드 에이전트와 함께 클러스터 관리 프로필이 만들어집니다. 이 프로필에서 복제 기본값을 설정하고 GMS를 사용하도록 설정하며 persistence-type 속성을 replicated로 설정합니다.
    
   
2. 클러스터와 클러스터의 인스턴스를 만듭니다(이 문서의 후반부에서 설명).
    
   
3. availability-enabled 속성을 true로 설정한 상태에서 웹 응용 프로그램을 배포합니다.

이러한 단계는 GUI 또는 CLI를 통해 수행할 수 있습니다.

일부 추가 조정이 필요할 수 있습니다. 예를 들어 클러스터 관리 프로필의 기본 힙 크기가 512MB인 경우, 엔터프라이즈급 배포를 하기 위해서는 이 값을 1GB 이상으로 높여야 합니다. 이 작업은 다음 태그와 함께 JVM 옵션을 설정하여 도메인 관리 서버를 통해 간단히 수행됩니다.

<jvm-options>-Xmx1024m</jvm-options>
<jvm-options>-Xms1024m</jvm-options>

또한 <distributable /> 태그를 웹 응용 프로그램의 web.xml 파일에 추가해야 합니다. 이 태그에서 응용 프로그램이 클러스터 기능을 수행할 수 있는 것으로 식별합니다.

<distributable /> 태그 삽입 요구 사항은 응용 프로그램을 클러스터에 배포하기 전에 클러스터 환경에서 테스트해야 함을 상기시키기 위한 것입니다. 일부 응용 프로그램의 경우 단일 인스턴스에 배포하면 적절하게 작동하지만 클러스터에 배포할 경우 오류가 발생합니다. 예를 들어 클러스터에 응용 프로그램을 배포하려면, 응용 프로그램의 HTTP 세션의 일부가 되는 개체(예: 상태 세션 Bean)의 상태를 네트워크에서 보존할 수 있도록 개체를 일련화할 수 있어야 합니다. 일련화할 수 없는 개체를 단일 서버 인스턴스에 배포할 경우 개체가 작동할 수 있지만 클러스터 환경에서는 오류가 발생합니다. 세션 데이터 상태를 검사하여 개체가 배포된 환경에서 제대로 작동하는지 확인합니다.

GlassFish 버전 2 응용 프로그램 서버의 메모리 복제 기능은 JXTA 기술의 전송 및 메시징 기능에 기반합니다.

JXTA 기술은 피어 투 피어 기술과 많은 점에서 유사합니다. 이 기술은 네트워크 토폴로지와 관계없이 네트워크에 연결된 장치들이 메시지를 교환하고 협업할 수 있는 XML 기반 프로토콜 집합으로 정의됩니다. GlassFish 버전 2 응용 프로그램 서버 개발 시 메모리 복제의 대용량 및 처리량 요구 사항을 처리할 수 있도록 JXTA 기술을 간소화했습니다. 메모리 복제 기능 개발자는 확장성 및 성능을 향상시키기 위해 그리즐리 프로젝트(Grizzly Project)와의 합작을 통해서도 다양한 이점을 얻었고, 이 덕분에 개발자는 Java New I/O API(NIO)를 통해 확장 가능하고 강력한 서버를 구축하는 데 많은 도움을 받고 있습니다.

JXTA 기술의 그룹 구성원 개념은 GlassFish 응용 프로그램 서버 클러스터 및 인스턴스 모델에 적절하게 매핑됩니다. JXTA 그룹은 GlassFish 클러스터에 매핑되고 JXTA 피어는 GlassFish 서버 인스턴스에 매핑됩니다. GMS는 이러한 그룹 구성원 개념을 활용하여 메모리 복제, 런타임 이벤트에 대한 클러스터의 알림 이벤트 모델과 같은 사용량이 많은 구성 요소를 제공합니다.

GlassFish 버전 2 응용 프로그램 서버 개발 시 클러스터링 토폴로지는 단일 서브넷으로 제한되어 왔습니다. 앞으로는 JXTA를 사용하여 클러스터링 토폴로지의 지리적 분산을 포함시킬 예정입니다.

마지막으로, JXTA 기술의 간단한 API를 사용하기 때문에 GlassFish 클러스터링에 대한 구성 요구 사항이 매우 간단해졌습니다.

GlassFish 응용 프로그램 서버를 설치하려면 다음을 수행합니다.

1. 다음 명령을 입력합니다.
    
   

   java -jar filename.jar

    
   예:
    
   

   java -jar glassfish-installer-v2-b58g.jar

   
    
   
2. 사용권 계약에 동의합니다. 사용권 계약에 동의한 후 GlassFish 설치 디렉토리에 기본 이름이 glassfish인 파일의 압축을 풉니다.

이제 GlassFish 응용 프로그램 서버를 구성해야 합니다.

설치 디렉토리에는 두 개의 ant 빌드 스크립트가 있고, 이 스크립트를 사용하여 기본 도메인을 만들 수 있습니다. 두 개의 스크립트는 setup.xml과 setup-cluster.xml입니다.

setup.xml 스크립트를 사용하여 개발자 프로필을 만들고 setup-cluster.xml 스크립트를 사용하여 클러스터 프로필을 만듭니다. 아래 설명된 대로 Sun Java System Application Server 관리 콘솔을 통해 개발자 프로필을 클러스터 프로필로 변환할 수 있습니다.

클러스터링 프로필로 기본 도메인을 만들려면 다음을 수행합니다.

• GlassFish 설치 디렉토리에 다음 명령을 입력합니다.
   
  

  lib/ant/bin/ant -f setup-cluster.xml

   
  구성 스크립트를 통해 아카이브의 압축을 풀고 domains 하위 디렉토리와 domain1이라는 클러스터링 사용 가능 도메인을 만듭니다.

이제 GlassFish 구성이 완료되었습니다.

CLI (asadmin 명령) 또는 GUI (Sun Java System Application Server 관리 콘솔)에서 도메인에 대한 정보를 배우고 도메인을 관리할 수 있습니다.

구성 단계를 통해 설치 디렉토리에 domains 하위 디렉토리를 만들었습니다. 이 디렉토리에 모든 GlassFish 도메인이 저장됩니다.

CLI 에서 asadmin 명령을 사용하여 설치 디렉토리 아래 bin 하위 디렉토리에 있는 도메인과 상호 작용할 수 있습니다. asadmin 명령은 배치 또는 대화형 모드에서 사용할 수 있습니다.

예를 들어 다음 명령을 통해 모든 도메인과 도메인 상태를 나열할 수 있습니다.

bin/asadmin list-domains 

domain1을 아직 시작하지 않은 경우에 위 명령을 실행하면 다음과 같이 출력됩니다.

domain1 not running

domain1을 시작하려면 다음 명령을 입력합니다.

bin/asadmin start-domain domain1

인수 domain1은 도메인이 하나만 있을 경우를 가정한 옵션입니다. 명령을 실행하면 domain1이 시작되고 로그 파일 위치, 서버 버전, 도메인 이름, 사용 가능한 웹 컨텍스트, 배포되는 응용 프로그램, 사용 중인 포트 등에 대한 정보가 제공됩니다.

asadmin 명령의 대체 방법으로 Sun Java System Application Server 관리 콘솔을 사용하여 응용 프로그램 서버를 제어할 수 있습니다. 다음 섹션에서는 콘솔을 시작하는 방법에 대해 설명합니다.

관리 콘솔을 사용하면 .war 또는 .ear 파일 또는 심지어 JBI(Java Business Integration) 서비스 어셈블리에서 손쉽게 응용 프로그램을 배포할 수 있습니다. 그리고 콘솔에서 리소스 사용 모니터링, 로그 파일 검색, 서버 시작 및 중지, 온라인 도움말에 대한 액세스, 기타 다양한 관리 및 서버 관리 기능을 수행할 수 있습니다.

클러스터링 지원을 기존 도메인에 추가할 수 있습니다. 개발자 프로필이 있는 도메인의 경우 해당 구성이 변경되지 않는 한 클러스터링을 지원하지 않습니다. GlassFish 설치 디렉토리에서 다음 명령을 통해 개발자 프로필 도메인을 만들 수 있습니다.

lib/ant/bin/ant -f setup.xml

개발자 프로필 도메인에서 클러스터링을 사용하도록 설정하려면 다음을 수행합니다.

1. GlassFish 설치 디렉토리에서 다음 명령을 입력하여 클러스터링에 대해 다시 구성할 도메인을 시작합니다.
    
   

   bin/asadmin start-domain domain_name

    
   

   예:

   bin/asadmin start-domain domain1

    
   

   명령을 실행하면 도메인에서 GlassFish 응용 프로그램 서버가 시작되고 명령 셸 창에서 정보가 제공됩니다. 정보의 마지막 줄에 도메인 기능에 대해 설명되어 있고 이 경우 다음과 같습니다.

   Domain does not support application server clusters and other standalone instances.

    
   
2. 웹 브라우저를 다음 URL로 이동하여 관리 콘솔을 시작합니다.
    
   

   http://hostname:port

    
   

   기본 포트는 4848입니다. 예:

   http://kindness.sun.com:4848

    
   

   관리 콘솔이 응용 프로그램 서버가 설치된 시스템에서 실행되고 있는 경우 호스트 이름으로 localhost를 지정합니다. Windows의 경우 시작 메뉴에서 응용 프로그램 서버 관리 콘솔을 시작합니다.

   기본 로그인은 다음과 같습니다.

   사용자 이름: admin
   암호: adminadmin

3. 창 왼쪽의 일반 작업 트리에서 응용 프로그램 서버를 선택합니다. 창 오른쪽에서 일반 탭을 선택합니다.
    
   
4. 다음 그림에 표시된 것처럼 클러스터 지원 추가 버튼을 클릭합니다.
    
   

   그림 10. :클러스터 지원 추가 큰 이미지를 보려면 여기를 클릭합니다.

    
   
5. 클러스터링 지원 변경 결과에 대해 환기시키는 확인 페이지가 표시됩니다. 변경 결과 중에서 다음 사항을 고려합니다.
    
   
   • 도메인 구성이 클러스터를 지원하도록 변경됩니다. 변경 내용에는 몇 가지 시스템 속성 및 템플릿 구성 추가에 대한 내용이 포함됩니다.
      
     
   • 클러스터링 사용 가능 서버는 클러스터 및 독립형 서버 인스턴스를 모두 지원합니다.
      
     
   • 클러스터는 리소스에 대한 수요를 높이는 경우가 있기 때문에 사용자는 힙 크기와 같은 관리 서버의 JVM 설정을 수정할 수 있습니다.
      
     
   • 클러스터링 사용 가능 도메인에 있는 서버에 현재 배포된 모든 응용 프로그램이 계속해서 작동합니다.
      
     
   • 클러스터링 지원에 대한 변경 내용은 도메인 서버 및 asadmin CLI를 다시 시작하면 적용됩니다.
      
     
   • 클러스터 지원을 롤백하려면 계속하기 전에 도메인에 대한 domain.xml 파일을 백업할 수 있습니다.
      
     
6. 확인을 클릭하여 도메인에 대해 클러스터링 지원을 사용하도록 설정합니다. 도메인의 서버 인스턴스를 다시 시작하라는 페이지가 열립니다.
    
   
7. 인스턴스 중지 버튼을 클릭합니다.
    
   
8. asadmin 명령이 명령 셸에서 실행 중인 경우 asadmin> 프롬프트에서 quit를 입력하여 명령을 종료합니다.
    
   
9. 다음 명령을 입력하여 CLI에서 도메인을 다시 시작합니다.
    
   

   asadmin start-domain domain_name

    
   

   예:

   asadmin start-domain domain1

    
   

   이 도메인에 대해 클러스터링을 사용하도록 설정하면 명령 셸의 마지막 줄이 다음과 같이 출력됩니다.
    
   

   Domain supports application server clusters and other standalone instances

    
   

로드 밸런서는 여러 응용 프로그램 서버 인스턴스 간의 작업 부하를 분산하고 전반적인 시스템 처리량을 높입니다. 서버 인스턴스에 대한 세션 요청을 라우팅할 때 로드 밸런서에서 특정 정보가 필요 없지만 사용 가능한 노드 목록을 유지 관리해야 합니다. 노드가 예상한 대로 요청에 응답하지 않을 경우 로드 밸런서가 다른 노드를 선택합니다.

로드 밸런서는 소프트웨어 또는 하드웨어에서 구현할 수 있습니다. 장치 구현에 대한 자세한 내용은 하드웨어 공급업체에서 제공된 정보를 참조하십시오.

HTTP 로드 밸런서 플러그인은 GlassFish 버전 2 응용 프로그램 서버에서 사용할 수 있습니다. 이 플러그인은 Sun Java System Application Server 9.1, Apache 웹 서버 및 Microsoft IIS에서 작동합니다. 그리고 로드 밸런서를 사용하여 한 서버 인스턴스에서 다른 서버 인스턴스로 페일오버하도록 요청할 수 있고 고가용성 설치도 가능합니다.

로드 밸런서 플러그인 설정 방법에 대한 자세한 내용은 Sun Java System Application Server 9.1 관리 콘솔에서 제공하는 온라인 도움말을 참조하십시오. 자세한 내용은 Sun Java System Application Server 9.1 High Availability Administration Guide의 5장, Configuring HTTP Load Balancing을 참조하십시오.

GlassFish 버전 2 응용 프로그램 서버는 관리 도메인, 도메인 관리 서버, 서버 인스턴스 및 물리적 시스템으로 구성된 유연한 클러스터링 아키텍처를 제공합니다. 이 아키텍처에는 사용의 용이성과 높은 수준의 관리 제어가 결합되어 고가용성 및 수평적 확장성을 향상시킵니다.

• 고가용성 - 상태를 공유할 수 있는 여러 서버 인스턴스는 특히 로드 균형 조정 구성과 결합 시 단일 오류 지점을 최소화하고, 서버 인스턴스 실패 시 서버 세션 데이터의 메모리 내 복제를 통해 사용자의 혼란을 최소화합니다.
   
  
• 수평적 확장성 - 사용자 부하가 증가하면 증가하는 부하를 처리하도록 추가 시스템, 서버 인스턴스 및 클러스터를 추가하고 이를 손쉽게 구성할 수 있습니다. GMS는 고가용성 클러스터 유지 관리에 대한 관리 부하를 줄여줍니다.

본 문서를 준비하는 데 도움을 준 Larry White, Abhijit Kumar 및 Dinesh Patil에게 감사드립니다.

• Sun Java System Application Server 9.1 High Availability Administration Guide
• Sun Java System Application Server 9.1 설명서 모음
• GlassFish 커뮤니티 다운로드 페이지
• Aquarium - GlassFish 커뮤니티 Wiki
• Kedar Mhaswade 블로그 - 도메인에 클러스터링 지원 추가
• Prashanth Abbagani 블로그 - GlassFish 버전 2에서 로드 균형 조정 및 클러스터링 설정
• Sun Java System Application Server 페이지 - GlassFish 커뮤니티 사이트 링크 제공
• Sun Java System Application Server 지원 및 서비스
• Sun Java System Application Server 9.1 지원
• Java EE Learning Path - 교육 과정 카탈로그
• Sun Developer Expert Assistance
• Java 교육 및 인증 - 기술 강화를 위한 전문가 개발
• 개발자 지원 - 온라인 문제 기반 프로그래밍 조언, 전화 제품 지원, 개발자 교육 과정, 서비스 계획