test

Sun Java System Application Server 9.1 고가용성 관리 설명서

1장 Application Server의 고가용성

이 장에서는 클러스터 프로필과 엔터프라이즈 프로필에서 사용 가능한 Sun Java System Application Server의 고가용성 기능에 대해 설명합니다.

주 –

HADB 소프트웨어는 Sun Java System Application Server의 Application Server 독립 실행형 배포와 함께 제공됩니다. 사용 가능한 Sun Java System Application Server 배포에 대한 자세한 내용은 Sun Java System Application Server 9.1 Installation Guide의 Distribution Types and Their Components를 참조하십시오. HADB 기능은 엔터프라이즈 프로필에서만 사용할 수 있습니다. 프로필에 대한 자세한 내용은 Sun Java System Application Server 9.1 관리 설명서의 사용 프로필을 참조하십시오.

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

고가용성 개요

고가용성 응용 프로그램 및 서비스는 하드웨어 및 소프트웨어 장애 발생 여부에 관계없이 해당 기능을 지속적으로 제공합니다. 시간의 99.999% 동안 사용 가능하도록 설계되기 때문에 이러한 응용 프로그램은 5-9(five nines)에 해당하는 안정성을 제공한다고 말하기도 합니다.

Application Server는 다음과 같은 고가용성 기능을 제공합니다.

고가용성 세션 지속성

Application Server는 HTTP 요청 및 세션 데이터(HTTP 세션 데이터 및 Stateful Session Bean 데이터)에 대해 고가용성을 제공합니다.

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

서버 오류가 발생해도 세션 상태를 지속하는 것은 최종 사용자에게 아주 중요합니다. 고가용성을 위해 Application Server에서는 다음 유형의 세션 상태 데이터 저장소를 제공합니다.

사용자 세션을 호스팅하는 Application Server 인스턴스에 오류가 발생하면 세션 상태가 복구될 수 있으며 세션은 정보 손실 없이 계속될 수 있습니다.

고가용성 세션 지속성을 설정하는 방법에 대한 자세한 내용은 9 장, 고가용성 세션 지속성 및 페일오버 구성을 참조하십시오.

고가용성 Java Message Service

Java Message Service(JMS) API는 Java EE 응용 프로그램 및 구성 요소가 메시지를 작성하고, 보내고, 받고, 읽을 수 있도록 하는 메시징 표준입니다. 또한 느슨하게 결합되고 안정적인 비동기식 분산 통신을 가능하게 합니다. JMS를 구현하는 Sun Java System Message Queue(MQ)는 Application Server와 긴밀하게 통합되어 MDB(Message-Driven Bean)와 같은 JMS에 의존하는 구성 요소를 만들 수 있도록 합니다.

JMS는 연결 풀링 및 페일오버와 MQ 클러스터링을 통해 고가용성을 제공합니다. 자세한 내용은 10 장, Java Message Service 로드 균형 조정 및 페일오버을 참조하십시오.

연결 풀링 및 페일오버

Application Server는 JMS 연결 풀링 및 페일오버를 지원합니다. Application Server에서는 JMS 연결을 자동으로 풀링합니다. 기본적으로 Application Server는 지정된 호스트 목록에서 기본 MQ 브로커를 무작위로 선택합니다. 페일오버가 발생하면 MQ는 로드를 투명하게 다른 브로커로 전송하고 JMS 의미를 유지 관리합니다.

JMS 연결 풀링 및 페일오버에 대한 자세한 내용은 연결 풀링 및 페일오버를 참조하십시오.

MQ 클러스터링

MQ Enterprise Edition은 브로커 클러스터로 알려져 있는 상호 연결된 여러 브로커 인스턴스를 지원합니다. 브로커 클러스터를 사용하면 클라이언트 연결이 클러스터에 있는 모든 브로커 간에 분산됩니다. 클러스터링은 수평적 확장을 제공하며 가용성을 향상시킵니다.

MQ 클러스터링에 대한 자세한 내용은 Application Server에서 MQ 클러스터 사용을 참조하십시오.

RMI-IIOP 로드 균형 조정 및 페일오버

RMI-IIOP 로드 균형 조정에서 IIOP 클라이언트 요청은 다른 서버 인스턴스나 이름 서버에 배포되며 이를 통해 클러스터에서 로드가 균등하게 분산되어 확장성을 제공합니다. IIOP 로드 균형 조정 기능과 EJB 클러스터링 및 가용성을 함께 사용하면 EJB 페일오버가 구현됩니다.

클라이언트가 객체에 대한 JNDI 조회를 수행할 경우 이름 지정 서비스는 기본적으로 요청을 특정 서버 인스턴스에 바인딩합니다. 이후, 해당 클라이언트의 모든 조회 요청은 동일한 서버 인스턴스로 보내지므로 모든 EJBHome 객체가 동일한 대상 서버에서 호스트됩니다. 이후에 가져온 모든 Bean 참조 또한 동일한 대상 호스트에서 만들어집니다. 이 경우 JNDI 조회를 수행할 때 모든 클라이언트가 활성 대상 서버 목록을 임의화하므로 로드 균형 조정이 효과적으로 제공될 수 있습니다. 대상 서버 인스턴스가 작동 중단되면 조회 또는 EJB 메소드 호출은 다른 서버 인스턴스로 페일오버됩니다.

IIOP 로드 균형 조정 및 페일오버는 투명하게 발생합니다. 응용 프로그램 배포 중에 특별한 단계가 필요하지는 않습니다. 응용 프로그램 클라이언트가 배포된 Application Server 인스턴스가 클러스터에 참여할 경우 Application Server가 자동으로 클러스터에서 현재 활성화된 모든 IIOP 종점을 찾습니다. 하지만 종점 중 하나가 실패한 경우에 대비하여 부트스트랩 용도로 지정된 종점이 최소한 두 개 이상 클라이언트에 있어야 합니다.

RMI-IIOP 로드 균형 조정 및 페일오버에 대한 자세한 내용은 11 장, RMI-IIOP 로드 균형 조정 및 페일오버을 참조하십시오.

추가 정보

하드웨어 요구 사항 평가, 네트워크 구성 계획 및 토폴로지 선택을 비롯한 고가용성 배포 계획에 대한 자세한 내용은 Sun Java System Application Server 9.1 배포 계획 설명서를 참조하십시오. 이 설명서에는 다음과 같은 개념이 자세히 설명되어 있습니다.

고가용성 기능의 이점을 활용하는 응용 프로그램의 개발에 대한 자세한 내용은 Sun Java System Application Server 9.1 Developer’s Guide를 참조하십시오.

고가용성 서버 및 응용 프로그램 조정

고가용성을 구현하여 최상의 성능을 얻을 수 있도록 응용 프로그램 및 Application Server를 구성하고 조정하는 방법에 대한 자세한 내용은 Sun Java System Application Server 9.1 Performance Tuning Guide를 참조하십시오. 이 설명서에는 다음과 같은 항목이 설명되어 있습니다.

Application Server에서 고가용성을 제공하는 방법

Application Server는 다음의 하위 구성 요소 및 기능을 통해 고가용성을 제공합니다.

로드 밸런서 플러그인

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

로드 밸런서는 여러 물리적 시스템으로 작업 로드를 분산시켜 전반적인 시스템 처리량을 늘립니다. 또한 HTTP 요청의 페일오버를 통해 보다 높은 가용성을 제공합니다. HTTP 세션 정보가 지속되려면 HTTP 세션 지속성을 구성해야 합니다.

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

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

로드 균형 조정 및 페일오버 구성에 대한 자세한 내용은 5 장, HTTP 로드 균형 조정 구성을 참조하십시오.

세션 상태 데이터 저장소

세션 상태 데이터를 저장하면 클러스터에서 서버 인스턴스의 페일오버가 이뤄진 후 세션 상태를 복구할 수 있습니다. 세션 상태를 복구하면 정보 손실 없이 세션을 계속할 수 있습니다. Application Server에서는 HTTP 세션 및 Stateful Session Bean 데이터에 대해 다음 유형의 고가용성 저장소를 제공합니다.

클러스터 내 다른 서버의 메모리 내 복제

다른 서버의 메모리 내 복제 기능은 HADB와 같은 별도의 데이터베이스를 사용할 필요 없이 가벼운 세션 상태 데이터 저장소를 제공합니다. 이러한 유형의 복제에는 HTTP 세션 및 Stateful Session Bean 데이터의 고가용성 저장소를 위해 다른 서버의 메모리가 사용됩니다. 클러스터링된 서버 인스턴스는 링 토폴로지에서 세션 상태를 복제합니다. 각 백업 인스턴스는 복제된 데이터를 메모리에 저장합니다. 다른 서버의 메모리에 있는 세션 상태 데이터를 복제하여 세션을 배포할 수 있습니다.

메모리 내 복제를 사용하려면 GMS(Group Management Service)가 활성화되어 있어야 합니다. GMS에 대한 자세한 내용은 그룹 관리 서비스를 참조하십시오.

클러스터의 서버 인스턴스가 다른 시스템에 있는 경우 다음 전제 조건을 충족하는지 확인하십시오.

고가용성 데이터베이스

주 –

HADB 소프트웨어는 Sun Java System Application Server의 Application Server 독립 실행형 배포와 함께 제공됩니다. 사용 가능한 Sun Java System Application Server 배포에 대한 자세한 내용은 Sun Java System Application Server 9.1 Installation Guide의 Distribution Types and Their Components를 참조하십시오. HADB 기능은 엔터프라이즈 프로필에서만 사용할 수 있습니다. 프로필에 대한 자세한 내용은 Sun Java System Application Server 9.1 관리 설명서의 사용 프로필을 참조하십시오.

Application Server에서는 HTTP 세션 및 Stateful Session Bean 데이터의 고가용성 저장을 위해 고가용성 데이터베이스(HADB)를 제공합니다. HADB는 로드 균형 조정, 페일오버 및 상태 보존형 복구 등을 통해 최고 99.999%의 서비스 및 데이터 가용성을 지원하도록 설계되었습니다. 일반적으로 HADB는 Application Server와는 별도로 구성하고 관리해야 합니다.

Application Server와 별도로 상태 관리를 수행하면 큰 이점을 얻을 수 있습니다. Application Server 인스턴스는 외부 고가용성 상태 서비스에 상태 복제를 위임하는 확장 가능하고 성능이 뛰어난 응용 프로그램 컨테이너의 역할을 수행합니다. 이와 같이 구조가 느슨하게 결합되어 있으므로 Application Server 인스턴스를 클러스터에서 아주 쉽게 추가 또는 삭제할 수 있습니다. HADB 상태 보존형 복제 서비스는 최적의 가용성 및 성능을 위해 독립적으로 확장될 수 있습니다. 또한 Application Server 인스턴스가 복제를 수행하면 Java EE 응용 프로그램의 성능이 저하될 수 있으며 가비지 모음이 더 오랫 동안 중단될 수 있습니다.

하드웨어 구성 결정, 크기 조정 및 토폴로지를 비롯하여 HADB를 통한 고가용성 구현을 위해 Application Server 설치를 계획 및 설정하는 방법에 대한 자세한 내용은 Sun Java System Application Server 9.1 배포 계획 설명서의 Planning for Availability와 Sun Java System Application Server 9.1 배포 계획 설명서의 3 장, 토폴로지 선택를 참조하십시오.

고가용성 클러스터

클러스터는 하나의 논리 엔티티로 함께 작동하는 Application Server 인스턴스 모음입니다. 클러스터는 하나 이상의 Java EE 응용 프로그램에 런타임 환경을 제공합니다. 고가용성 클러스터는 상태 보존형 응용 프로그램 서비스를 클러스터 및 로드 밸런서에 통합합니다.

클러스터를 사용하면 다음과 같은 이점을 얻을 수 있습니다.

클러스터의 모든 인스턴스는 다음과 같습니다.

도메인의 모든 클러스터에는 고유한 이름이 있습니다. 여기서 이 이름은 모든 노드 에이전트 이름, 서버 인스턴스 이름 및 구성 이름에 대해 고유해야 합니다. 또한 이름은 domain으로 지정할 수 없습니다. 클러스터링되지 않은 서버 인스턴스에서 수행하는 것과 동일한 작업(예: 응용 프로그램 배포 및 자원 작성)을 클러스터에서 수행합니다.

클러스터 및 구성

클러스터의 설정은 다른 클러스터와 공유될 수 있는 명명된 구성에서 파생됩니다. 다른 서버 인스턴스나 클러스터와 구성을 공유하지 않는 클러스터는 독립 실행형 구성 을 갖는다고 할 수 있습니다. 기본적으로 이 구성의 이름은 cluster_name -config입니다. 여기서 cluster_name은 클러스터의 이름입니다.

다른 클러스터나 인스턴스와 구성을 공유하는 클러스터는 공유 구성을 갖는다고 할 수 있습니다.

클러스터, 인스턴스, 세션 및 로드 균형 조정

클러스터, 서버 인스턴스, 로드 밸런서 및 세션은 다음과 같이 관련되어 있습니다.

클러스터는 클러스터 내 서버 인스턴스의 세션 페일오버에 대한 안전한 경계 역할을 합니다. 로드 밸런서를 사용하여 서비스 손실 없이 Application Server 내에서 구성 요소를 업그레이드할 수 있습니다.

오류 복구

Sun Cluster 사용

Sun Cluster는 도메인 관리 서버, 노드 에이전트, Application Server 인스턴스, Message Queue 및 HADB의 자동 페일오버를 제공합니다. 자세한 내용은 Sun Cluster Data Service for Sun Java System Application Server Guide for Solaris OS를 참조하십시오.

표준 이더넷 상호 연결 및 Sun Cluster 제품의 하위 집합을 사용합니다. 이 기능은 Java ES에 포함되어 있습니다.

수동 복구

다양한 기술을 사용하여 개별 하위 구성 요소를 수동으로 복구할 수 있습니다.

도메인 관리 서버 복구

도메인 관리 서버(DAS)가 손실되면 관리에만 영향을 줍니다. DAS에 연결할 수 없는 경우에도 Application Server 클러스터 및 응용 프로그램은 계속해서 이전과 같이 작동합니다.

다음 방법 중 하나를 사용하여 DAS를 복구합니다.

노드 에이전트 및 서버 인스턴스 복구

노드 에이전트와 서버 인스턴스를 복구하는 두 가지 방법이 있습니다.

백업 zip 파일 유지. 노드 에이전트와 서버 인스턴스를 백업하기 위한 명시적인 명령이 없습니다. 노드 에이전트 디렉토리의 내용을 포함하는 zip 파일을 만들면 됩니다. 오류가 발생한 후 동일한 호스트 이름과 IP 주소를 사용하여 새 시스템에서 저장된 백업의 압축을 풉니다. 동일한 설치 디렉토리 위치, OS 등을 사용합니다. 파일 기반 설치, 패키지 기반 설치 또는 복원된 백업 이미지가 시스템에 있어야 합니다.

수동 복구. 동일한 IP 주소가 있는 새 호스트를 사용해야 합니다.

  1. Application Server 노드 에이전트 비트를 시스템에 설치합니다.

  2. AS8.1 UR2 패치 4 설치에 대한 지침을 확인합니다.

  3. 노드 에이전트를 다시 만듭니다. 서버 인스턴스를 만들 필요는 없습니다.

  4. 동기화는 DAS에서 구성과 데이터를 복사 및 업데이트합니다.

로드 밸런서 및 웹 서버 복구

웹 서버 구성만 백업하는 명시적인 명령은 없습니다. 웹 서버 설치 디렉토리를 압축하면 됩니다. 오류가 발생한 후 동일한 네트워크 아이디를 사용하여 새 시스템에서 저장된 백업의 압축을 풉니다. 새 시스템에 다른 IP 주소가 있는 경우 DNS 서버나 라우터를 업데이트합니다.

주 –

이 경우 먼저 웹 서버가 이미지에서 다시 설치되거나 복원된다고 가정합니다.

로드 밸런서 플러그인(플러그인 디렉토리) 및 구성은 웹 서버 설치 디렉토리(일반적으로 /opt/SUNWwbsvr)에 있습니다. web-install/web-instance/config 디렉토리에는 loadbalancer.xml 파일이 포함되어 있습니다.

Message Queue 복구

Message Queue(MQ) 구성 및 자원은 DAS에 저장되며 인스턴스에 동기화될 수 있습니다. 다른 모든 데이터 및 구성 정보는 일반적으로 /var/imq 아래에 있는 MQ 디렉토리에 있으므로 필요에 따라 이러한 디렉토리를 백업 및 복원합니다. 새 시스템에는 MQ 설치가 이미 포함되어 있어야 합니다. 시스템을 복원할 때 이전처럼 MQ 브로커를 시작해야 합니다.

HADB 복구

주 –

HADB 소프트웨어는 Sun Java System Application Server의 Application Server 독립 실행형 배포와 함께 제공됩니다. 사용 가능한 Sun Java System Application Server 배포에 대한 자세한 내용은 Sun Java System Application Server 9.1 Installation Guide의 Distribution Types and Their Components를 참조하십시오. HADB 기능은 엔터프라이즈 프로필에서만 사용할 수 있습니다. 프로필에 대한 자세한 내용은 Sun Java System Application Server 9.1 관리 설명서의 사용 프로필을 참조하십시오.

두 개의 활성 HADB 노드가 있는 경우 오류 시 인계 받을 수 있는 두 개의 예비 노드를 별개의 시스템에 구성할 수 있습니다. HADB 백업 및 복원으로 인해 복원 중인 유효하지 않은 세션이 발생할 수 있으므로 이 방법은 더 완벽한 방법입니다.

예비 노드가 있는 데이터베이스를 만드는 방법에 대한 자세한 내용은 데이터베이스 만들기를 참조하십시오. 예비 노드를 데이터베이스에 추가하는 방법에 대한 자세한 내용은 노드 추가를 참조하십시오. 복구 및 자체 복원이 실패할 경우 예비 노드에서 자동으로 인계합니다.

Netbackup 사용

주 –

이 절차는 Sun QA에서 테스트되지 않았습니다.

Veritas Netbackup을 사용하여 각 시스템의 이미지를 저장합니다. BPIP의 경우 웹 서버 및 Application Server가 있는 네 개의 시스템을 백업합니다.

복원된 각 시스템에 대해 원래 구성과 동일한 구성(예: 동일한 호스트 이름, IP 주소 등)을 사용합니다.

Application Server와 같은 파일 기반 제품의 경우 관련 디렉토리만 백업 및 복원합니다. 그러나 웹 서버 이미지와 같은 패키지 기반 설치의 경우 전체 시스템을 백업 및 복원해야 합니다. 패키지는 Solaris 패키지 데이터베이스에 설치됩니다. 따라서 디렉토리만 백업한 다음 새 시스템에 복원할 경우 결과적으로 패키지 데이터베이스에 정보가 없는 "배포된" 웹 서버가 됩니다. 이로 인해 이후의 패치 작업이나 업데이트에 문제가 발생할 수 있습니다.

Solaris 패키지 데이터베이스를 수동으로 복사 및 복원하지 마십시오. 또 다른 방법은 웹 서버와 같은 구성 요소가 설치된 후에 시스템의 이미지를 백업하는 것입니다. 이 백업을 기본 tar 파일이라고 합니다. 웹 서버를 변경할 경우 예를 들어 /opt/SUNWwbsvr 아래에 이러한 디렉토리를 백업합니다. 복원하려면 기본 tar 파일에서 시작한 다음 수정된 웹 서버 디렉토리에 복사합니다. 마찬가지로 MQ(BPIP용 패키지 기반 설치)에 이 절차를 사용할 수 있습니다. 원래 시스템을 업그레이드하거나 패치할 경우 새 기본 tar 파일을 만들어야 합니다.

DAS가 있는 시스템이 다운될 경우 복원할 때까지 일정 시간 동안 사용할 수 없습니다.

DAS는 중앙 저장소입니다. 서버 인스턴스를 복원하고 다시 시작할 경우 해당 서버 인스턴스는 DAS의 정보와만 동기화됩니다. 이후 모든 변경 사항은 asadmin 또는 관리 콘솔을 통해 수행되어야 합니다.

이전 응용 프로그램 세션 상태가 이미지에 포함되었을 수도 있으므로 HADB의 일별 백업 이미지가 작동하지 않을 수 있습니다.

Domain Administration Server 다시 만들기

DAS(Domain Administration Server)를 호스팅하는 시스템이 실패할 경우 DAS를 이전에 백업해 두었다면 해당 DAS를 다시 만들 수 있습니다. DAS의 작업 복사본을 다시 만들려면 다음 사항이 필요합니다.

주 –

첫 번째 시스템에서 DAS의 백업을 보존해야 합니다. asadmin backup-domain을 사용하여 현재 도메인을 백업합니다.

ProcedureDAS를 마이그레이션하는 방법

첫 번째 시스템(machine1)에서 세 번째 시스템(machine3)으로 DAS(Domain Administration Server)를 마이그레이션하려면 다음 단계가 필요합니다.

  1. 첫 번째 시스템에 설치한 대로 세 번째 시스템에 응용 프로그램 서버를 설치합니다.

    DAS를 세 번째 시스템에 제대로 복원하고 경로 충돌을 방지하려면 이 단계가 필요합니다.

    1. 명령줄(대화식) 모드를 사용하여 Application Server 관리 패키지를 설치합니다.

      대화형 명령줄 모드를 활성화하려면 console 옵션을 사용하여 설치 프로그램을 호출하십시오.


      ./bundle-filename -console

      명령줄 인터페이스를 사용하여 설치하려면 루트 권한이 있어야 합니다.

    2. 기본 도메인을 설치하려면 옵션을 선택 해제합니다.

      백업한 도메인을 복원하는 것은 동일한 구조뿐만 아니라 정확하게 동일한 설치 경로를 가진 두 시스템(즉, 두 시스템에서 동일한 as-install 및 domain-root-dir 사용)에서만 지원됩니다.

  2. 첫 번째 시스템에서 백업 ZIP 파일을 세 번째 시스템의 domain-root-dir에 복사합니다.

    파일을 FTP에 올릴 수도 있습니다.

  3. ZIP 파일을 세 번째 시스템에 복원합니다.


    asadmin restore-domain --filename domain-root-dir/sjsas_backup_v00001.zip 
--clienthostname machine3 domain1
    주 –

    --clienthostname 옵션을 지정하면 domain.xml 파일에서 jmx-connector 요소의 client-hostname 등록 정보를 수정할 필요가 없습니다.

    모든 도메인을 백업할 수 있습니다. 그러나 도메인을 다시 만들 때 도메인 이름이 원본과 동일해야 합니다.

  4. 첫 번째 시스템의 동일한 디렉토리의 권한과 일치하도록 세 번째 시스템의 domain-root-dir/domain1/generated/tmp 디렉토리의 권한을 변경합니다.

    이 디렉토리의 기본 권한은 drwx------(또는 700)입니다.

    예를 들면 다음과 같습니다.


    chmod 700 domain-root-dir/domain1/generated/tmp

    위 예는 domain1을 백업하는 것을 가정합니다. 다른 이름으로 도메인을 백업할 경우 위 domain1을 백업할 도메인 이름으로 대체해야 합니다.

  5. 세 번째 시스템의 domain-root-dir/domain1/config/domain.xml 파일에서 jms-service 요소의 host 속성 값을 업데이트합니다.

    이 속성의 원래 설정은 다음과 같습니다. 

    <jms-service... host=machine1.../>

    이 속성의 설정을 다음과 같이 수정합니다. 

    <jms-service... host=machine3.../>

  6. machine3에서 복구된 도메인을 시작합니다.


    asadmin start-domain --user admin-user --password admin-password domain1

    DAS는 실행 중인 모든 노드 에이전트에 연결하고 노드 에이전트에 DAS 연결에 대한 정보를 제공합니다. 노드 에이전트는 이 정보를 사용하여 DAS와 통신합니다.

  7. DAS가 다시 시작될 때 실행 중이지 않은 모든 노드 에이전트에 대해서는 machine2의 as-install/nodeagents/nodeagent/agent/config/das.properties에서 agent.das.host 등록 정보 값을 변경합니다.

    DAS가 다시 시작될 때 실행 중인 노드 에이전트에는 이 단계가 필요하지 않습니다.

  8. machine2에서 노드 에이전트를 다시 시작합니다.

    주 –

    asadmin start-instance 명령을 사용하여 클러스터 인스턴스를 시작하면 클러스터 인스턴스를 복원된 도메인과 동기화할 수 있습니다.