test

Sun Java System Application Server 9.1 배포 계획 설명서

1장 제품 개념

Sun Java System Application Server는 J2EE 응용 프로그램의 개발, 배포 및 관리를 위한 견고한 플랫폼을 제공합니다. 주요 기능으로는 확장 가능한 트랜잭션 관리, 컨테이너 관리 지속성 런타임, 웹 서비스 성능, 클러스터링, 고가용성 세션 상태, 보안 및 통합 기능이 있습니다.

이 장은 다음 내용으로 구성되어 있습니다.

J2EE 플랫폼 개요

Application Server는 J2EE(Java 2 Enterprise Edition) 1.4 기술을 구현합니다. J2EE 플랫폼은 Application Server의 응용 프로그램 구성 요소, API 및 런타임 컨테이너와 서비스를 설명하는 표준 사양 집합입니다.

J2EE 응용 프로그램

J2EE 응용 프로그램은 JSP(JavaServer Pages), Java Servlet 및 EJB(Enterprise JavaBeans)와 같은 구성 요소로 구성됩니다. 소프트웨어 개발자는 이러한 구성 요소를 사용하여 대규모 분산 응용 프로그램을 구축할 수 있습니다. 개발자는 J2EE 응용 프로그램을 작업 사이트에 배포할 수 있는 JAR(Java ARchive) 파일(zip 파일과 유사)로 패키지화합니다. 관리자는 J2EE JAR 파일을 하나 이상의 서버 인스턴스(또는 인스턴스 클러스터)에 배포하여 J2EE 응용 프로그램을 Application Server에 설치합니다.

다음 그림은 다음 절에 설명된 J2EE 플랫폼 구성 요소를 보여줍니다.

죄송합니다. 현재 그래픽을 사용할 수 없습니다.

컨테이너

각 서버 인스턴스에는 웹 및 EJB의 두 가지 컨테이너가 있습니다. 컨테이너는 J2EE 구성 요소에 보안 및 트랜잭션 관리 등의 서비스를 제공하는 런타임 환경입니다. Java Server Pages 및 서블릿 같은 웹 구성 요소는 웹 컨테이너에서 실행됩니다. Enterprise JavaBeans는 EJB 컨테이너에서 실행됩니다.

J2EE 서비스

J2EE 플랫폼은 다음과 같은 응용 프로그램 서비스를 제공합니다.

웹 서비스

클라이언트는 J2EE 1.4 응용 프로그램에 HTTP, RMI/IIOP 및 JMS를 통해 액세스할 뿐 아니라 원격 웹 서비스로 액세스할 수 있습니다. 웹 서비스는 JAX-RPC(Java API for XML-based RPC)를 사용하여 구현됩니다. J2EE 응용 프로그램은 네트워크 응용 프로그램에서 일반적인, 웹 서비스에 대한 클라이언트 역할을 담당할 수도 있습니다.

WSDL(Web Services Description Language)은 웹 서비스 인터페이스를 설명하는 XML 형식입니다. 웹 서비스 사용자는 WSDL 문서를 동적으로 구문 분석하여 웹 서비스에서 제공하는 작업과 작업 수행 방법을 확인합니다. Application Server는 다른 응용 프로그램에서 JAXR(Java API for XML Registries)을 통해 액세스할 수 있는 레지스트리를 사용하여 웹 서비스 인터페이스 설명을 배포합니다.

클라이언트 액세스

클라이언트는 다양한 방법으로 J2EE 응용 프로그램에 액세스할 수 있습니다. 브라우저 클라이언트는 HTTP(HyperText Transfer Protocol)를 사용하여 웹 응용 프로그램에 액세스합니다. 브라우저에는 보안 통신을 위해 SSL(Secure Sockets Layer)을 사용하는 HTTPS(HTTP Secure) 프로토콜이 사용됩니다.

Application Client Container에서 실행되는 다양한 클라이언트 응용 프로그램은 ORB(Object Request Broker), RMI(Remote Method Invocation), 그리고 IIOP(internet inter-ORB Protocol) 또는 IIOP/SSL(보안 IIOP)을 사용하여 Enterprise JavaBeans를 직접 조회 및 액세스할 수 있습니다. 또한, HTTP/HTTPS, JMS 및 JAX-RPC를 사용하여 응용 프로그램과 웹 서비스에 액세스할 수 있으며 JMS를 사용하여 응용 프로그램 및 Message-Driven Bean과 메시지를 주고 받을 수 있습니다.

WS-I(Web Services-Interoperability) 기본 프로필을 준수하는 클라이언트는 J2EE 웹 서비스에 액세스할 수 있습니다. WS-I는 J2EE 표준을 구성하는 필수 요소로서 상호 운용 가능한 웹 서비스를 정의하며 지원되는 언어로 작성된 클라이언트에서 Application Server에 배포된 웹 서비스에 액세스할 수 있도록 해줍니다.

최상의 액세스 메커니즘은 특정 응용 프로그램과 예상 트래픽 양에 따라 다릅니다. Application Server에서는 HTTP, HTTPS, JMS, IIOP 및 IIOP/SSL에 대해 개별적으로 구성할 수 있는 수신기를 지원합니다. 확장성과 안정성 향상을 위해 프로토콜별로 여러 수신기를 설정할 수 있습니다.

J2EE 응용 프로그램은 다른 서버에 배포된 Enterprise JavaBeans 모듈과 같은 J2EE 구성 요소의 클라이언트 역할을 할 수도 있고 이러한 모든 액세스 메커니즘을 사용할 수도 있습니다.

외부 시스템 및 자원

J2EE 플랫폼의 경우 외부 시스템을 자원이라고 합니다. 예를 들어 데이터베이스 관리 시스템은 JDBC 자원입니다. 각 자원은 JNDI(Java Naming and Directory Interface) 이름으로 고유하게 식별됩니다. 응용 프로그램은 다음 API와 구성 요소를 통해 외부 시스템에 액세스합니다.

Application Server 구성 요소

이 절에서는 다음과 같은 Sun Java System Application Server 구성 요소에 대해 설명합니다.

다음 그림은 고가용성을 제공하는 단순 토폴로지 예를 통해 이러한 Application Server 구성 요소가 상호 작용하는 방법을 보여줍니다. 이 토폴로지 예에서는 한 관리자가 클러스터로 구성된 두 개의 시스템을 관리합니다. HADB 및 Application Server 프로세스는 동일한 시스템에 있습니다. Domain Administration Server는 단독으로 별도 시스템에서 호스팅되거나 Application Server 인스턴스를 호스팅하는 시스템 중 한 시스템에서 호스팅될 수 있습니다. 다이어그램의 선은 통신 또는 제어를 나타냅니다.

브라우저 기반 관리 콘솔과 같은 관리 도구는 DAS(Domain Administration Server)와 통신하고 DAS는 다시 노드 에이전트 및 서버 인스턴스와 통신합니다.

서버 인스턴스

서버 인스턴스는 단일 Java 가상 머신(Java Virtual Machine, JVM) 프로세스에서 실행되는 Application Server입니다. Application Server는 J2SE(Java 2 Standard Edition) 5.0 및 1.4를 사용하여 인증됩니다. 권장 J2SE 배포가 Application Server 설치에 포함되어 있습니다.

Application Server 및 함께 제공되는 JVM은 여러 프로세서로 확장 가능하도록 개발되었으므로 일반적으로 한 시스템에서 한 개의 서버 인스턴스를 만드는 것으로 충분합니다. 그러나 응용 프로그램 격리 및 롤링 업그레이드를 고려하면 한 시스템에서 여러 인스턴스를 만드는 것이 유리할 수 있습니다. 또한, 경우에 따라 여러 인스턴스가 포함된 대규모 서버는 관리 도메인 이상으로 사용될 수 있습니다. 관리 도구를 사용하면 여러 시스템에 걸쳐 서버 인스턴스를 간편하게 생성, 삭제 및 관리할 수 있습니다.

관리 도메인

관리 도메인(또는 도메인)은 함께 관리되는 서버 인스턴스의 그룹입니다. 서버 인스턴스는 단일 관리 도메인에 속합니다. 도메인의 인스턴스는 서로 다른 물리적 호스트에서 실행될 수 있습니다.

하나의 Application Server 설치에서 여러 도메인을 만들 수 있습니다. 서버 인스턴스를 도메인으로 그룹화하면 서로 다른 조직이나 관리자가 단일 Application Server 설치를 공유할 수 있습니다. 도메인마다 다른 도메인과 독립된 고유한 구성 로그 파일 및 응용 프로그램 배포 영역이 있습니다. 도메인 구성을 변경해도 다른 도메인의 구성에 영향을 미치지 않습니다. 마찬가지로, 응용 프로그램을 한 도메인에 배포해도 다른 도메인에 배포되거나 표시되지 않습니다. 관리자는 항상 하나의 도메인에만 인증되므로 해당 도메인에 대해서만 관리를 수행할 수 있습니다.

DAS(Domain Administration Server)

도메인에는 특수 설계된 Application Server 인스턴스로서, 관리 응용 프로그램을 호스팅하는 Domain Administration Server(DAS)가 있습니다. DAS는 관리자를 인증하고 관리 도구의 요청을 승인하며 도메인의 서버 인스턴스와 통신하여 요청을 수행합니다.

관리 도구에는 asadmin 명령줄 도구, 브라우저 기반 관리 콘솔이 있습니다. Application Server에서는 서버 관리용 JMX 기반 API도 제공합니다. 관리자가 한 번에 하나의 도메인을 보고 관리할 수 있으므로 안전하게 구분되어 관리됩니다.

DAS는 admin 서버 또는 기본 서버라고도 합니다. DAS가 일부 관리 작업의 기본 대상이 되므로 기본 서버라고 합니다.

DAS는 Application Server 인스턴스이므로 테스트를 위해 J2EE 응용 프로그램을 호스팅할 수 있지만 DAS를 사용하여 프로덕션 응용 프로그램을 호스팅하지 마십시오. 예를 들어, 프로덕션 응용 프로그램을 호스팅할 클러스터와 인스턴스가 아직 생성되지 않은 경우 응용 프로그램을 DAS에 배포하려고 할 수 있습니다.

DAS는 도메인과 모든 배포된 응용 프로그램의 구성이 포함된 저장소를 유지합니다. DAS가 비활성화되거나 다운될 경우 활성 서버 인스턴스의 성능이나 가용성에는 영향이 없지만 관리 항목을 변경할 수 없습니다. 경우에 따라 보안을 위해 의도적으로 DAS 프로세스를 중지하는 것이 유용할 수 있습니다(예: 프로덕션 구성 중단).

도메인 구성과 응용 프로그램을 백업 및 복원하기 위한 관리 명령이 제공됩니다. 표준 백업 및 복원 절차를 사용하여 작업 구성을 신속하게 복원할 수 있습니다. DAS 호스트에 오류가 발생한 경우 이전 도메인 구성을 복원하려면 새 DAS 설치를 만들어야 합니다. 자세한 내용은 Sun Java System Application Server 9.1 관리 설명서의 Domain Administration Server 다시 만들기를 참조하십시오.

Sun Cluster 데이터 서비스는 DAS 호스트 IP 주소의 페일오버 및 전역 파일 시스템 사용을 통해 DAS 고가용성을 제공합니다. 이 솔루션은 거의 지속적인 DAS 가용성과 다양한 실패 유형에 대한 저장소를 제공합니다. Sun Cluster 데이터 서비스는 Sun Java Enterprise System과 함께 제공되거나 Sun Cluster와 함께 별도로 구입할 수 있습니다. 자세한 내용은 Sun Cluster 데이터 서비스에 대한 설명서를 참조하십시오.

클러스터

클러스터는 동일한 응용 프로그램, 자원 및 구성 정보를 공유하는 명명된 서버 인스턴스 모음입니다. 여러 시스템의 서버 인스턴스를 하나의 논리적 클러스터에 그룹화한 후 하나의 단위로 관리할 수 있습니다. DAS를 사용하여 다중 시스템 클러스터의 수명 주기를 쉽게 제어할 수 있습니다.

클러스터를 구축하면 수평적인 확장, 로드 균형 조정 및 페일오버 보호가 구현됩니다. 정의에 따르면 한 클러스터의 모든 인스턴스에 동일한 자원 및 응용 프로그램 구성이 포함됩니다. 클러스터의 서버 인스턴스나 시스템에 장애가 발생하면 로드 밸런서는 장애를 감지하고, 실패한 인스턴스에서 클러스터의 다른 인스턴스로 트래픽을 리디렉션하고, 사용자 세션 상태를 복구합니다. 동일한 응용 프로그램 및 자원가 클러스터의 모든 인스턴스에 있으므로 한 인스턴스에서 클러스터의 다른 인스턴스로 페일오버가 수행될 수 있습니다.

클러스터, 도메인 및 인스턴스는 다음과 같이 관련되어 있습니다.

노드 에이전트

노드 에이전트는 DAS를 호스팅하는 시스템을 비롯하여 서버 인스턴스를 호스팅하는 모든 시스템에서 실행되는 경량 프로세스입니다. 노드 에이전트의 기능은 다음과 같습니다.

각 물리적 호스트에는 호스트가 속한 도메인별로 하나 이상의 노드 에이전트가 있어야 합니다. 물리적 호스트의 인스턴스가 둘 이상의 도메인에 포함된 경우 도메인별로 노드 에이전트가 필요합니다. 하나의 호스트에서 도메인별로 둘 이상의 노드 에이전트를 갖는 것은 가능하지만 아무런 이점이 없습니다.

노드 에이전트는 서버 인스턴스를 시작 및 중지하기 때문에 항상 실행 중이어야 합니다. 따라서 운영 체제가 부트될 때 시작됩니다. Solaris 및 기타 Unix 플랫폼의 경우 inetd 프로세스로 노드 에이전트를 시작할 수 있습니다. Windows의 경우 노드 에이전트를 Windows 서비스로 만들 수 있습니다.

노드 에이전트에 대한 자세한 내용은 Sun Java System Application Server 9.1 고가용성 관리 설명서의 8 장, 노드 에이전트 구성을 참조하십시오.

명명된 구성

명명된 구성은 Application Server 등록 정보 설정을 캡슐화하는 추상입니다. 클러스터와 독립 실행형 서버 인스턴스는 명명된 구성을 참조하여 해당 등록 정보 설정을 가져옵니다. 명명된 구성을 갖는 J2EE 컨테이너 구성은 IP 주소, 포트 번호 및 힙 메모리 양과 같은 항목을 제외하고 컨테이너가 상주하는 물리적 시스템과 무관합니다. 명명된 구성을 사용하면 유연하고 강력한 Application Server 관리가 가능합니다.

명명된 구성의 등록 정보 설정을 변경하기만 하면 해당 구성을 참조하는 모든 클러스터와 독립 실행형 인스턴스에서 변경 사항을 수용하여 구성 변경 사항이 자동으로 적용됩니다. 명명된 구성은 해당 구성에 대한 모든 참조를 제거한 경우에만 삭제할 수 있습니다. 도메인은 여러 개의 명명된 구성을 포함할 수 있습니다.

Application Server에는 default-config라는 기본 구성이 함께 제공됩니다. 기본 구성은 Application Server Platform Edition의 경우 개발자 생산성이, Application Server Enterprise Edition의 경우 보안 및 고가용성이 최적화되어 있습니다.

기본 구성은 목적에 맞게 사용자 정의할 수 있으므로 이를 바탕으로 사용자만의 고유한 명명된 구성을 만들 수 있습니다. 명명된 구성은 관리 콘솔과 asadmin 명령줄 유틸리티를 사용하여 만들고 관리합니다.

HTTP 로드 밸런서 플러그인

로드 밸런서는 작업 로드를 여러 물리적 시스템 간에 분산시켜 시스템의 전체 처리량을 높입니다. Application Server Enterprise Edition에는 Sun Java System Web Server, Apache Web Server 및 Microsoft Internet Information Server용 로드 밸런서 플러그인이 포함되어 있습니다.

로드 밸런서 플러그인은 HTTP 및 HTTPS 요청을 받아들인 후 클러스터의 Application Server 인스턴스 중 하나로 전달합니다. 한 인스턴스에 오류가 발생하거나 네트워크 결함 때문에 사용할 수 없게 되거나 응답하지 않으면, 기존에 있던 사용 가능한 시스템으로 요청이 리디렉션됩니다. 또한 로드 밸런서는 실패한 인스턴스가 복구되었을 때를 인식하고 그에 따라 로드를 재분산할 수 있습니다.

상태 비보존형 경량 응용 프로그램의 경우 로드 균형 조정된 클러스터만으로 충분할 수 있습니다. 그러나 세션 상태를 포함하는 업무에 중요한 응용 프로그램의 경우 HADB와 함께 로드 균형 조정된 클러스터를 사용하십시오.

시스템에 로드 균형 조정을 설정하려면 Application Server뿐만 아니라 웹 서버 및 로드 밸런서 플러그인도 설치해야 하며 그 후에 다음을 수행해야 합니다.

로드 균형 조정에 참여하는 서버 인스턴스와 클러스터의 환경은 같습니다. 일반적으로 이것은 서버 인스턴스가 동일한 서버 구성을 참조하고, 동일한 물리적 자원에 액세스할 수 있으며, 서버 인스턴스에 동일한 응용 프로그램이 배포되어 있다는 것을 의미합니다. 동일한 환경은 작업 실패 전과 후에 로드 밸런서가 클러스터의 활성 인스턴스에 항상 로드를 균등하게 분산합니다.

asadmin 명령줄 도구를 사용하여 로드 밸런서 구성을 만들고, 클러스터와 서버 인스턴스에 대한 참조를 구성에 추가한 후 로드 밸런서가 참조할 클러스터를 활성화합니다. 그런 다음 로드 균형 조정할 응용 프로그램을 활성화하고, 상태 검사기를 만든 다음(선택 사항) 로드 밸런서 구성 파일을 생성하고, 마지막으로 로드 밸런서 구성 파일을 웹 서버 config 디렉토리로 복사합니다. 관리자는 스크립트를 만들어 전체 프로세스를 자동화할 수 있습니다.

자세한 내용과 전체 구성 지침을 보려면 Sun Java System Application Server 9.1 고가용성 관리 설명서의 5 장, HTTP 로드 균형 조정 구성을 참조하십시오.

세션 지속성

J2EE 응용 프로그램은 일반적으로 많은 양의 세션 상태 데이터를 포함하게 됩니다. 웹 장바구니가 세션 상태의 일반적인 예에 해당합니다. 또한 응용 프로그램은 자주 필요한 데이터를 세션 객체에 캐시할 수 있습니다. 실제로 사용자 상호 작용이 자주 발생하는 거의 모든 응용 프로그램에서는 세션 상태가 유지되어야 합니다. HTTP 세션과 SFSB(StateFul Session Bean)은 모두 세션 상태 데이터를 갖습니다.

세션 상태는 데이터베이스에 저장된 처리 상태만큼 중요하지는 않지만 최종 사용자에게는 서버 오류 전체에 대해 세션 상태를 보존하는 것이 중요할 수 있습니다.Application Server는 이 세션 상태를 저장소에 저장하거나 유지하는 기능을 제공합니다. 사용자 세션을 호스팅 중인 Application Server 인스턴스에 오류가 발생할 경우 세션 상태를 복구할 수 있습니다. 정보의 손실 없이 세션을 계속할 수 있습니다.

Application Server에서는 다음 유형의 세션 지속성 저장소가 지원됩니다.

메모리 지속성의 경우 항상 메모리에서 상태가 유지되고 오류 발생 후에는 지속되지 않습니다. HA 지속성의 경우 Application Server에서 HTTP 세션과 SFSB 세션에 대해 모두 HADB를 지속성 저장소로 사용합니다. 파일 지속성의 경우 Application Server에서 세션 객체를 일련화하여 세션 관리자 등록 정보에 지정된 파일 시스템 위치에 저장합니다. SFSB의 경우 HA가 지정되어 있지 않으면 Application Server에서 이 위치의 session-store 하위 디렉토리에 상태 정보를 저장합니다.

SFSB 상태에 저장해야 할 변경 사항이 있는지 검사하는 작업을 검사점 지정이라고 합니다. 활성화된 경우 트랜잭션이 롤백되는 경우에도 검사점 지정은 일반적으로 SFSB 관련 트랜잭션이 완료된 후에 수행됩니다. Stateful Session Bean 개발에 대한 자세한 내용은 Sun Java System Application Server 9.1 Developer’s Guide의 Using Session Beans를 참조하십시오. SFSB 페일오버 활성화에 대한 자세한 내용은 Sun Java System Application Server 9.1 고가용성 관리 설명서의 Stateful Session Bean 페일오버를 참조하십시오.

세션 지속성 구성 설정은 Application Server에서 처리되는 요청의 수 외에도 HADB에서 수신하는 분당 요청 수뿐 아니라 각 요청의 세션 정보에 영향을 줍니다.

세션 지속성 구성에 대한 자세한 내용은 Sun Java System Application Server 9.1 고가용성 관리 설명서의 9 장, 고가용성 세션 지속성 및 페일오버 구성을 참조하십시오.

클러스터의 IIOP 로드 균형 조정

IIOP 로드 균형 조정 기능을 사용하면 IIOP 클라이언트 요청이 여러 서버 인스턴스나 이름 서버에 분산됩니다. 목표는 클러스터 내에서 로드를 균일하게 분산시켜 확장성을 제공하는 것입니다. Sun Java System Application에서 EJB 클러스터링 및 가용성 기능과 결합된 IIOP 로드 균형 조정 기능은 로드 균형 조정뿐 아니라 EJB 페일오버 기능도 제공합니다.

클라이언트가 객체에 대해 JNDI 조회를 수행하면 이름 지정 서비스는 특정 서버 인스턴스와 연결된 InitialContext(IC) 객체를 만듭니다. 그러면 해당 IC 객체를 사용하여 수행된 모든 조회 요청은 동일한 서버 인스턴스로 보내집니다. 해당 InitialContext를 사용하여 조회된 모든 EJBHome 객체는 동일한 대상 서버에 호스트됩니다. 이후에 가져온 모든 Bean 참조 또한 동일한 대상 호스트에서 만들어집니다. 이 경우 InitialContext 객체를 만들 때 모든 클라이언트가 활성 대상 서버 목록을 임의화하므로 로드 균형 조정이 효과적으로 구현될 수 있습니다. 대상 서버 인스턴스가 작동 중단되면 조회 또는 EJB 메소드 호출은 다른 서버 인스턴스로 페일오버됩니다.

예를 들어 이 그림에 표시된 대로 ic1, ic2 및 ic3은 Client2의 코드에서 생성된 3개의 서로 다른 InitialContext 인스턴스로서, 클러스터 내 3개의 서버 인스턴스로 배포됩니다. 따라서, 이 클라이언트에서 만든 Enterprise JavaBeans가 3개의 인스턴스에 분산됩니다. Client1은 한 개의 InitialContext 객체만 생성했고 이 클라이언트의 Bean 참조는 Server Instance 1에만 있습니다. Server Instance 2가 다운되면 ic2의 조회 요청이 다른 서버 인스턴스(반드시 Server Instance 3일 필요는 없음)로 페일오버됩니다. 이전에 Server Instance 2에서 호스팅된 Bean에 대한 모든 Bean 메소드 호출 또한, 안전한 경우에 한해 다른 인스턴스로 자동으로 리디렉션됩니다. 조회 페일오버가 자동인 상태에서 Enterprise JavaBeans 모듈은 안전한 경우에 한해 메소드 호출을 다시 시도합니다.

IIOP 로드 균형 조정 및 페일오버는 투명하게 발생합니다. 응용 프로그램 배포 중에 특별한 단계가 필요하지는 않습니다. 클러스터에서 새 인스턴스를 추가 또는 삭제해도 클러스터의 기존 클라이언트 뷰가 업데이트되지 않습니다. 클라이언트측의 종점 목록을 수동으로 업데이트해야 합니다.

메시지 대기열 및 JMS 자원

Sun Java System Message Queue(MQ)는 분산 응용 프로그램에 대한 신뢰할 수 있는 비동기 메시징을 제공합니다. MQ는 JMS(Java Message Service) 표준을 구현하는 엔터프라이즈 메시징 시스템입니다. MQ는 MDB(Message-Driven Bean)와 같은 J2EE 응용 프로그램 구성 요소에 대한 메시징을 제공합니다.

Application Server는 Sun Java System Message Queue를 Application Server로 통합하여 JMS(Java Message Service) API를 구현합니다. Application Server Enterprise Edition에는 페일오버, 클러스터링 및 로드 균형 조정 기능이 있는 MQ Enterprise 버전이 포함되어 있습니다.

기본 JMS 관리 작업의 경우 Application Server 관리 콘솔과 asadmin 명령줄 유틸리티를 사용합니다.

Message Queue 클러스터 관리와 같은 고급 작업에는 install_dir/imq/bin 디렉토리에 제공된 도구를 사용합니다. Message Queue 관리에 대한 자세한 내용은 Sun Java System Message Queue 관리 설명서를 참조하십시오.

메시지 페일오버를 위한 JMS 응용 프로그램 및 MQ 클러스터링 배포에 대한 자세한 내용은 Message Queue 브로커 배포 계획을 참조하십시오.

고가용성 데이터베이스

이 절은 다음 내용으로 구성되어 있습니다.

개요

J2EE 응용 프로그램의 세션 지속성에 대한 필요성은 이전에 세션 지속성에서 설명했습니다. Application Server는 가용성이 높은 세션 저장소로 HADB(고가용성 데이터베이스)를 사용합니다. HADB는 Application Server Enterprise Edition에 포함되어 있지만 별도의 호스트에 배포하여 실행할 수 있습니다. HADB는 HTTP 세션 및 Stateful Session Bean 데이터를 위한 가용성이 높은 데이터 저장소를 제공합니다.

이러한 분리된 구조의 이점은 다음과 같습니다.

주 –

HADB는 Application Server용으로 최적화된 데이터베이스로서, 응용 프로그램에서 일반 데이터베이스로 사용하도록 개발되지 않았습니다.

HADB 하드웨어 및 네트워크 시스템 요구 사항을 보려면 Sun Java System Application Server 9.1 릴리스 노트의 하드웨어 및 소프트웨어 요구 사항을 참조하십시오. HADB에 필요한 추가 시스템 구성 단계를 보려면 Sun Java System Application Server 9.1 고가용성 관리 설명서의 2 장, 고가용성 데이터베이스 설치 및 설정을 참조하십시오.

시스템 요구 사항

HADB 호스트에 대한 시스템 요구 사항은 다음과 같습니다.

네트워크 구성 요구 사항을 보려면 Sun Java System Application Server 9.1 고가용성 관리 설명서의 2 장, 고가용성 데이터베이스 설치 및 설정을 참조하십시오. 고가용성을 위한 추가 요구 사항을 보려면 이중 오류 완화를 참조하십시오.

HADB 구조

HADB는 노드 쌍으로 구성된 분산 시스템입니다. 노드는 두 개의 DRU(Data Redundancy Units)로 구분되는데, DRU(Data Redundancy Units)의 설명처럼 각 DRU에는 각 노드 쌍의 한 노드가 포함됩니다.

각 노드를 구성하는 요소는 다음과 같습니다.

한 개의 HADB 노드 세트는 하나 이상의 세션 데이터베이스를 호스팅할 수 있습니다. 세션 데이터베이스는 각각 다른 Application Server 클러스터와 연결됩니다. 클러스터를 삭제하면 연결된 세션 데이터베이스도 삭제됩니다.

HADB 하드웨어 요구 사항을 보려면 Sun Java System Application Server 9.1 릴리스 노트의 하드웨어 및 소프트웨어 요구 사항을 참조하십시오.

노드 및 노드 프로세스

HADB 노드에는 두 가지 유형이 있습니다.

각 노드에는 한 개의 부모 프로세스와 여러 개의 자식 프로세스가 있습니다. NSUP(노드 수퍼바이저)라고 하는 부모 프로세스는 관리 에이전트에 의해 시작되며, 자식 프로세스를 만들어 실행 상태를 유지하는 작업을 수행합니다.

자식 프로세스는 다음과 같습니다.

DRU(Data Redundancy Units)

앞에서 설명한 대로 HADB 인스턴스에는 한 쌍의 DRU가 포함되어 있습니다. 각 DRU는 쌍을 이루는 다른 DRU와 동일한 수의 활성 노드와 예비 노드를 갖습니다. 한 DRU의 각 활성 노드에는 다른 DRU의 미러 노드가 있습니다. 각 DRU에는 미러링으로 인해 전체 데이터베이스의 복사본이 포함되어 있습니다.

다음 그림은 활성 노드 4개와 예비 노드 두 개로 구성된 6개의 노드가 있는 HADB 구조 예를 보여줍니다. 노드 0과 노드 1은 하나의 미러 쌍이고 노드 2와 노드 3도 미러 쌍입니다. 이 예에서 각 호스트에는 하나의 노드가 있습니다. 일반적으로, 시스템 자원이 충분할 경우 호스트에 둘 이상의 노드가 있을 수 있습니다( 시스템 요구 사항 참조).

주 –

각 DRU에 한 시스템씩 HADB 노드를 쌍으로 호스팅하는 시스템을 추가해야 합니다.

HADB는 데이터와 서비스를 복제하여 고가용성을 달성합니다. 미러 노드의 데이터 복제본은 기본 복제본과 상시 대기 복제본으로 지정됩니다. 기본 복제본은 삽입, 삭제, 업데이트 및 읽기와 같은 작업을 수행합니다. 상시 대기 복제본은 기본 복제본 작업의 로그 레코드를 수신하여 트랜잭션 수명 내에서 재실행합니다. 읽기 작업은 기본 노드에 의해서만 수행되므로 기록되지 않습니다. 각 노드는 기본 복제본과 상시 대기 복제본을 모두 포함하고 두 역할을 모두 수행합니다. 데이터베이스는 단편화되어 DRU의 활성 노드에 분산됩니다. 미러 쌍의 각 노드는 동일한 데이터 단편 집합을 포함합니다. 미러 노드의 데이터 중복화를 복제라고 합니다. 복제를 사용하면 HADB에서 고가용성을 제공할 수 있습니다. 노드에 오류가 발생하면 미러 노드가 몇 초 내로 거의 즉시 인계를 받습니다. 복제는 가용성을 확보하고 데이터나 서비스 손실 없이 노드 오류 또는 DRU 오류를 마스크합니다.

오류 발생 노드의 기능을 인계 받은 미러 노드는 자체 작업과 함께 오류 발생 노드의 작업까지 이중 작업을 수행해야 합니다. 미러 노드의 자원이 부족한 경우 오버로드로 인해 성능이 저하되고 오류 가능성이 높아집니다. 노드에 오류가 발생하면 HADB는 노드를 다시 시작하려고 시도합니다. 하드웨어 장애 등으로 인해 오류 발생 노드가 다시 시작되지 않으면 시스템은 계속 작동하지만 가용성이 감소합니다.

HADB는 노드 하나, 전체 DRU 또는 여러 노드의 오류를 허용하지만 노드와 해당 미러에 모두 오류가 발생하는 "이중 오류"는 허용하지 않습니다. 이중 오류 가능성을 줄이는 방법에 대한 자세한 내용은 이중 오류 완화를 참조하십시오.

예비 노드

노드에 오류가 발생하면 해당 미러 노드가 작업을 인계 받습니다. 오류 노드에 예비 노드가 없으면 이 때 오류 노드에 미러가 없습니다. 예비 노드는 오류 발생 노드의 미러를 자동으로 복제합니다. 예비 노드가 있으면 시스템이 미러 노드 없이 작동하는 시간이 감소합니다.

예비 노드는 일반적으로 데이터를 포함하지 않지만 DRU의 활성 노드에 오류가 있는지 지속적으로 모니터합니다. 한 노드에 오류가 발생하고 지정된 시간 초과 기간 내에 복구되지 않으면 예비 노드가 미러 노드에서 데이터를 복사하여 동기화합니다. 이 작업에 소요되는 시간은 복사되는 데이터 양과 시스템 및 네트워크 용량에 따라 달라집니다. 동기화한 후 예비 노드가 수동 개입 없이 미러 노드를 자동으로 대체하므로 미러 노드가 오버로드에서 해제되어 미러의 로드 균형이 조정됩니다. 이 작업은 페일백 또는 자체 복구라고도 합니다.

하드웨어를 바꾸거나 소프트웨어를 업그레이드하여 오류 발생 호스트가 복구 및 다시 시작되면 원래 예비 노드가 현재 활성 상태이므로 호스트에서 실행 중인 노드가 예비 노드로 시스템에 참가합니다.

예비 노드가 필수 항목은 아니지만 이를 사용하여 시스템에 오류가 발생한 경우에도 시스템의 전체 서비스 수준을 유지할 수 있습니다. 또한 예비 노드를 사용하면 활성 노드를 호스팅하는 시스템에서 계획된 유지 보수를 손쉽게 수행할 수 있습니다. 시스템 중 하나에 오류가 발생할 경우 HADB 시스템이 성능과 가용성에 악영향을 주지 않고 계속 작동하도록 DRU에 예비 시스템 역할을 수행할 시스템을 각각 하나씩 할당합니다.

주 –

일반적으로 사용할 수 없게 되는 시스템을 대체할 만큼 Application Server 인스턴스 및 HADB 노드가 충분한 예비 시스템을 사용합니다.

예비 노드 구성 예

다음 예는 HADB 배포에서 예비 노드의 사용을 보여줍니다. 가능한 두 가지 배포 토폴로지로 HADB 및 Application Server가 동일한 호스트에 상주하는 공존 토폴로지와 각각 다른 호스트에 상주하는 개별 계층 토폴로지가 있습니다. 배포 토폴로지에 대한 자세한 내용은 3 장, 토폴로지 선택을 참조하십시오.

예: 공존 구성

예비 노드 구성 예로서 각 서버에 Application Server 인스턴스 하나와 HADB 데이터 노드 둘이 있는 4대의 Sun FireTM V480 서버로 구성된 공존 토폴로지가 있다고 가정합니다.

예비 노드로 두 대의 서버를 추가로 할당합니다(DRU당 시스템 한 대). 각 예비 시스템은 Application Server 인스턴스 하나와 예비 HADB 노드 둘을 실행합니다.

예: 개별 계층 구성

HADB 계층에 서버당 두 개의 HADB 데이터 노드를 실행하는 두 대의 Sun FireTM 280R 서버가 있는 개별 계층 토폴로지가 있다고 가정합니다. 이 시스템에서 시스템 한 대가 사용할 수 없게 된 경우에도 성능을 유지하려면 Application Server 인스턴스 계층과 HADB 계층에 사용할 예비 시스템을 각각 하나씩 구성합니다.

Application Server 인스턴스 계층용 예비 시스템에는 Application Server 인스턴스 계층의 다른 시스템과 동일한 수의 인스턴스가 있어야 합니다. 마찬가지로 HADB 계층용 예비 시스템에도 HADB 계층의 다른 시스템과 동일한 수의 HADB 노드가 있어야 합니다.

이중 오류 완화

HADB의 기본 제공 데이터 복제를 사용하여 단일 노드 또는 전체 DRU의 오류를 허용하도록 할 수 있습니다. 기본적으로 HADB는 미러 노드 쌍이나 양쪽 DRU에 모두 오류가 발생하는 이중 오류를 허용하지 않습니다. 이 경우 HADB를 사용할 수 없게 됩니다.

이전 절의 설명대로 예비 노드를 사용하고 다음 단계를 수행하면 이중 오류 발생 가능성을 최소화할 수 있습니다.

이 단계는 선택 사항이지만 HADB 인스턴스의 전반적인 가용성을 높여줍니다.

HADB 관리 시스템

HADB 관리 시스템은 기본 제공 보안 기능이 포함되어 있으며 다중 플랫폼 관리를 용이하게 합니다. 아래의 그림에서 보여주는 것처럼 HADB 관리 구조는 다음 구성 요소로 구성됩니다.

그림과 같이 HADB 서비스를 실행하는 모든 시스템에서는 HADB 관리 에이전트가 실행됩니다. 각 시스템은 대개 하나 이상의 HADB 노드를 호스팅합니다. HADB 관리 도메인에는 Application Server 도메인처럼 여러 시스템이 포함되어 있습니다. 데이터베이스가 내결함성을 갖도록 구성하려면 도메인에 두 대 이상의 시스템이 필요하고 일반적으로 DRU 쌍을 형성할 수 있도록 시스템이 짝수로 존재해야 합니다. 따라서 도메인에 많은 관리 에이전트가 포함됩니다.

그림과 같이 도메인은 하나 이상의 데이터베이스 인스턴스를 포함할 수 있습니다. 시스템 한 대에는 하나 이상의 데이터베이스 인스턴스에 속한 하나 이상의 노드가 포함될 수 있습니다.

관리 클라이언트

HADB 관리 클라이언트는 HADB 도메인과 해당 데이터베이스 인스턴스를 관리하기 위한 명령줄 유틸리티 hadbm입니다. 연결된 Application Server 클러스터가 중지된 경우에도 HADB 서비스는 계속 실행될 수 있지만 삭제하려는 경우에는 조심스럽게 종료해야 합니다. hadbm 사용에 대한 자세한 내용은 Sun Java System Application Server 9.1 고가용성 관리 설명서의 3 장, 고가용성 데이터베이스 관리를 참조하십시오.

asadmin 명령줄 유틸리티를 사용하여 가용성이 높은 클러스터와 연결된 HADB 인스턴스를 만들거나 삭제할 수 있습니다. 자세한 내용은 Sun Java System Application Server 9.1 고가용성 관리 설명서의 9 장, 고가용성 세션 지속성 및 페일오버 구성을 참조하십시오.

관리 에이전트

관리 에이전트는 호스트의 자원에 액세스할 수 있는 ma라는 서버 프로세스로서, 장치를 만들거나 데이터베이스 프로세스를 시작하는 등의 작업을 수행할 수 있습니다. 관리 에이전트는 데이터베이스 인스턴스 시작 또는 중지와 같은 관리 클라이언트 명령을 조정 및 수행합니다.

관리 클라이언트는 에이전트의 주소와 포트 번호를 지정하여 관리 에이전트에 연결합니다. 연결된 후 관리 클라이언트는 관리 에이전트를 통해 HADB에 명령을 보내고 에이전트는 요청을 수신하여 실행합니다. 따라서 관리 에이전트는 hadbm 관리 명령을 호스트에 지시하기 전에 해당 호스트에서 실행 중이어야 합니다. 관리 에이전트는 자동으로 시작되는 시스템 서비스로 구성할 수 있습니다.

관리 에이전트 가용성 보장

관리 에이전트 프로세스는 HADB 노드 수퍼바이저 프로세스가 실패한 경우 프로세스를 다시 시작하여 HADB의 가용성을 보장합니다. 따라서 배포 시 HADB의 전체적인 가용성을 유지하려면 ma 프로세스의 가용성을 보장해야 합니다. 다시 시작한 후 관리 에이전트는 도메인의 다른 에이전트에서 도메인 및 데이터베이스 구성 데이터를 복구합니다.

호스트 운영 체제(OS)를 사용하여 관리 에이전트의 가용성을 보장합니다. Solaris나 Linux의 경우 init.d를 사용하여 프로세스 오류와 운영 체제 재부트 이후 ma 프로세스의 가용성을 보장할 수 있습니다. Windows의 경우 관리 에이전트가 Windows 서비스로 실행됩니다. 따라서 에이전트에 오류가 발생하거나 OS가 재부트될 경우 OS에서 관리 에이전트를 다시 시작합니다.

관리 도메인

HADB 관리 도메인은 각기 동일한 포트 번호에서 실행되는 관리 에이전트가 있는 호스트의 집합입니다. 도메인의 호스트는 하나 이상의 HADB 데이터베이스 인스턴스를 포함할 수 있습니다. 관리 도메인은 에이전트가 사용하는 공통 포트 번호 및 도메인을 만들거나 도메인에 에이전트를 추가할 때 생성되는 도메인 키라는 식별자로 정의됩니다. 도메인 키는 도메인의 고유 식별자로서 관리 에이전트가 멀티캐스트를 사용하여 통신하기 때문에 중요한 역할을 합니다. Application Server 도메인과 일치하는 HADB 관리 도메인을 설정할 수 있습니다.

한 도메인에 데이터베이스 인스턴스가 여러 개 있으면 여러 개발자 그룹에서 각각 전용 데이터베이스 인스턴스를 사용할 수 있기 때문에 개발 환경에서 유용할 수 있으며 프로덕션 환경에서도 경우에 따라 유용할 수 있습니다.

도메인에 속한 모든 에이전트는 해당 관리 작업을 조정합니다. hadbm 명령을 통해 데이터베이스 구성을 변경하면 모든 에이전트가 이에 따라 구성을 변경합니다. 노드의 호스트에서 관리 에이전트가 실행되고 있지 않으면 해당 노드를 중지하거나 다시 시작할 수 없습니다. 그러나 일부 에이전트를 사용할 수 없는 경우에도 HADB 상태 또는 구성 변수 값을 읽는 hadbm 명령을 실행할 수 있습니다.

다음 관리 클라이언트 명령을 사용하여 관리 도메인 작업을 수행합니다.

저장소

관리 에이전트는 데이터베이스 구성을 저장소에 저장합니다. 저장소는 모든 관리 에이전트에서 복제되기 때문에 내결함성이 우수합니다. 서버에서 구성을 유지하면 관리 클라이언트가 설치된 모든 컴퓨터에서 관리 작업을 수행할 수 있습니다.

저장소 내용을 변경하려면 도메인에 속한 대부분의 관리 에이전트가 실행 중이어야 합니다. 따라서 도메인에 M개의 에이전트가 있는 경우 저장소 내용을 변경하려면 에이전트가 M/2+1개(정수로 절사) 이상 실행 중이어야 합니다.

하드웨어 장애 등으로 인해 도메인의 일부 호스트를 사용할 수 없는 상태에서 쿼럼이 없기 때문에 일부 관리 명령을 수행할 수 없는 경우 hadbm disablehost 명령을 사용하여 도메인에서 오류 발생 호스트를 제거합니다.

설정 및 구성 로드맵

Procedure고가용성 구현을 위한 Application Server의 설정 및 구성 방법

  1. 1 장, 제품 개념의 설명대로 성능과 QoS 요구 사항 및 목적을 결정합니다.

  2. 1 장, 제품 개념의 설계 결정 사항에 설명된 대로 시스템 크기를 설정합니다.

    • Application Server 인스턴스 수

    • HADB 노드 및 호스트 수

    • HADB 저장소 용량

  3. 3 장, 토폴로지 선택의 설명대로 시스템 토폴로지를 결정합니다.

    HADB를 Application Server와 동일한 호스트 시스템에 설치할 것인지 다른 시스템에 설치할 것인지를 결정하는 단계입니다.

  4. HADB, 웹 서버 등 관련된 하위 구성 요소와 함께 Application Server 인스턴스를 설치합니다.

  5. 도메인과 클러스터를 만듭니다.

  6. 웹 서버 소프트웨어를 구성합니다.

  7. 로드 밸런서 플러그인을 설치합니다.

  8. 로드 균형 조정 기능을 설정 및 구성합니다.

  9. HADB 노드와 DRU를 설정 및 구성합니다.

  10. HA 세션 지속성을 사용하도록 AS 웹 컨테이너와 EJB 컨테이너를 구성합니다.

  11. 응용 프로그램을 배포하고 고가용성과 세션 페일오버를 사용하도록 구성합니다.

  12. 광범위하게 메시징을 사용하는 경우 페일오버를 사용하도록 JMS 클러스터를 구성합니다.

    자세한 내용은 Sun Java System Message Queue 관리 설명서를 참조하십시오.