![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
백업 클러스터
백업 클러스터는 1차 서버 클러스터를 미러합니다. 미러된 클러스터 지원은 EJB(Enterprise JavaBeans) 요청에만 사용됩니다.

클러스터의 모든 멤버가 더 이상 EJB(Enterprise JavaBeans) 요청을 서비스할 수 없을 때, 클러스터의 EJB(Enterprise JavaBeans) 애플리케이션 서버 중 하나와 상호작용해야 하는 클라이언트가 기능하지 않습니다. 미러된 클러스터는 1차 클러스터의 어떤 EJB(Enterprise JavaBeans) 애플리케이션 서버도 요청을 서비스할 수 없을 때 EJB 클러스터(1차 클러스터)가 다른 EJB(Enterprise JavaBeans) 클러스터(백업 클러스터)로 장애 조치(failover)할 수 있게 합니다. 백업 클러스터를 사용하면 1차 클러스터의 모든 클러스터 멤버가 사용 불가능할 때 클라이언트가 계속 기능할 수 있게 합니다.
장애 복구(failback)는 자동으로 수행됩니다. 1차 클러스터에서 서버를 다시 시작한 후 1차 클러스터로의 장애 복구(failback)를 시작할 필요가 없습니다. 1차 클러스터가 사용 가능해지면 백업 클러스터가 즉시 요청 처리를 중지합니다. 그러나 모든 배치 관리자에 백업 클러스터 지원 기능이 있어야 하며 1차 클러스터를 백업 클러스터에 대한 백업으로 정의해야 합니다.
- 1차 클러스터에서 사용 가능한 오브젝트 및 자원이 백업 클러스터에서도 사용 가능해야 합니다.
- 백업 클러스터에 1차 클러스터에서와 동일한 클러스터 이름을 사용하고, 애플리케이션을 설치하며 동일한 애플리케이션 이름을 사용하고 동일한 자원을 정의해야 합니다.
- 클러스터가 셀 내에서 고유한 이름을 가져야 하기 때문에 1차 클러스터 및 백업 클러스터는 별도의 셀에 상주해야 합니다.
- 1차 및 백업 클러스터 모두는 백업 클러스터를 구성하고 각 클러스터의 백업이 반대 클러스터를 가리켜야 합니다.
1차 클러스터와 백업 클러스터는 서로 다른 셀에 상주하므로 현재 버전의 제품에서는 클러스터도 다른 코어 그룹에 상주합니다. 코어 그룹 브릿지 서비스를 구성해야 하고 코어 그룹 사이에서 통신이 가능하도록 하려면 이 태스크를 사용하십시오. 코어 그룹 브릿지 서비스는 백업 클러스터 지원을 위해 배치 관리자 및 노드 에이전트를 실행해야 하는 필요성을 없애줍니다. 이전 릴리스에서, 배치 관리자가 중지되면 1차 클러스터가 실패한 후 백업 클러스터로 새 요청을 전달할 수 없었습니다. 1차 클러스터 셀에 구성된 코어 그룹 브릿지 서버가 백업 클러스터에 대한 정보를 제공할 수 있습니다. 백업 클러스터는 셀에 있는 모든 코어 그룹 브릿지 서버가 실행되지 않는 경우에만 실패를 지원합니다.
클러스터 장애 조치(failover) 및 장애 복구(failback)가 예상한 대로 기능하려면 1차 클러스터와 백업 클러스터 둘 다에 대한 모든 서버(배치 관리자, 노드 에이전트, 애플리케이션 서버 포함)가 미러된 클러스터 지원을 제공하는 레벨 및 릴리스에 있어야 합니다.
미러된 클러스터 지원은 기본적으로 구성되어 있지 않습니다. 미러된 클러스터 지원을 사용하려면, 구성에서 백업 클러스터를 지정해야 합니다. 각 클러스터는 하나의 백업 클러스터만을 가질 수 있는데, 이는 백업 클러스터로 지정되기 전에 구성되어야 합니다.
클러스터에 백업 클러스터를 구성하려면 이름과 도메인 부트스트랩 주소를 지정해야 합니다. 부트스트랩 호스트는 백업 클러스터가 구성되는 배치 관리자를 포함하는 호스트입니다. 부트스트랩 포트는 배치 관리자의 부트스트랩 포트입니다.
1차 클러스터 및 백업 클러스터는 별도의 셀에 상주해야 합니다. 미러된 클러스터를 별도 셀에 배치하려면 적당한 백업 클러스터 도메인 부트스트랩 주소를 구성하십시오. 백업 클러스터 부트스트랩 호스트 및 포트가 백업 클러스터를 포함하는 셀을 판별합니다.
- 도메인 부트스트랩 주소 페이지의 구성 탭을 사용하여 백업 클러스터를 정적으로 정의합니다. 정적 값은 배치 관리자가 시작할 때마다 소비됩니다.
- 도메인 부트스트랩 주소 페이지에서 런타임 탭을 사용하여 클러스터가 실행 중일 때 백업 클러스터를 정의하십시오. 배치 관리자가 중지되면 런타임 백업 클러스터를 정의하는 정보는 버립니다.
1차 클러스터와 백업 클러스터는 서로 다른 셀에 상주하므로 현재 버전의 제품에서는 클러스터도 다른 코어 그룹에 상주합니다. 코어 그룹 브릿지 서비스를 구성해야 하고 코어 그룹 사이에서 통신이 가능하도록 하려면 이 태스크를 사용하십시오. 두 개의 코어 그룹을 결합하려면 액세스 지점 그룹을 사용하십시오. 1차 셀의 배치 관리자의 경우, 백업 셀에 대한 코어 그룹 액세스 지점을 갖는 액세스 지점 그룹을 피어 액세스 지점으로 구성하십시오. 백업 셀의 배치 관리자의 경우, 1차 셀에서 작성한 액세스 지점 그룹과 동일한 이름을 갖는 액세스 지점 그룹을 작성하십시오. 1차 셀의 코어 그룹 액세스 지점을 참조하는 피어 액세스 지점을 추가하십시오.
ExtendedCluster MBean을 사용하여 백업 클러스터를 구성하는 경우, 런타임 구성만을 변경할 수 있습니다. MBean 변경은 정적 구성에 영향을 주지 않습니다. ExtendedCluster MBean의 setBackup 조작을 사용하여 런타임 구성을 변경할 수 있습니다. 예를 들어, 다음 Java 코드를 사용하여 1차 클러스터의 백업 클러스터를 설정할 수 있습니다.
ac.invoke(extendedCluster, "setBackup", new Object[] {
backupClusterName, backupBootstrapHost, backupBootstrapPort},
new String[] {
"java.lang.String", "java.lang.String", "java.lang.Integer"});
샘플에서 ac는 AdminClient이고, extendedCluster는 1차 클러스터의 ExtendedClusterObjectName입니다.
- 첫 번째 시나리오에서는 클라이언트가 1차 클러스터에 요청을 작성하고, 결국 요청 승인이 중지됩니다. 그런 다음 요청이 백업 클러스터로 보내집니다. 클라이언트는 처음에 1차 클러스터로 요청을 전송하며 따라서 1차 클러스터에 대한 정보가 있습니다. 결국, 1차 클러스터가 다시 사용 가능할 때, 요청은 1차 클러스터로 장애 복구(failback)합니다.
- 두 번째 시나리오에서는 1차 클러스터가 정지된 후에야 클라이언트가 요청 전송을 시작하고, 요청은 직접 백업 클러스터로 이동합니다. 이 경우, 클라이언트는 백업 클러스터에 대한 정보만 있습니다. 클라이언트가 백업 클러스터에 대해서만 알고 있으므로, 1차 클러스터가 사용 가능하게 될 때 이 클러스터의 요청은 계속 백업 클러스터로 보내지고 1차 클러스터가 사용 가능하게 될 때 1차 클러스터로 장애 복구(failback)하지 않습니다. 이 시나리오는 오브젝트가 백업 클러스터에 작성될 때 발생합니다. 이 경우에는 백업 클러스터가 이 오브젝트에 대한 1차 클러스터가 됩니다.