Sun Java Enterprise System 2005Q4 배포 계획 설명서

가용성 전략 결정

가용성 요구 사항을 위한 전략을 개발하는 경우 고려할 가용성 솔루션이 어떤 것인지 결정하기 위한 구성 요소 상호 작용 및 사용 분석을 연구합니다. 가용성 및 페일오버 요구 사항을 위한 최적의 솔루션을 판별하여 구성 요소별로 분석합니다.

다음 항목은 가용성 전략을 결정하도록 도와주기 위해 수집한 정보 유형의 예입니다.

선택하는 가용성 전략에서는 최적의 자원 사용을 위한 설계에 설명되어 있는 서비스 가능성 요구 사항도 고려해야 합니다. 상당한 관리 및 유지 보수가 필요한 복잡한 솔루션은 피합니다.

가용성 전략

Java Enterprise System 배포의 가용성 전략은 다음과 같습니다.

다음 절에서는 다양한 수준의 로드 균형 조정, 페일오버 및 서비스 복제를 제공하는 가용성 솔루션의 예를 설명합니다.

단일 서버 시스템

서비스를 위한 모든 컴퓨팅 자원을 단일 서버에 배치합니다. 서버에 오류가 발생할 경우 전체 서비스가 실패합니다.

그림 5–2 단일 서버 시스템

성능 요구 사항을 충족시키는 10개의 CPU가 있는 단일 서버를 표시합니다.

Sun에서는 다음 이점을 제공하는 고성능 서버를 제공합니다.

고성능 서버는 일반적으로 비슷한 다중 서버 시스템보다 비용이 더 많이 듭니다. 그러나 단일 서버인 경우 데이터 센터의 서버에 대한 관리, 모니터링 및 호스팅 비용을 절약할 수 있습니다. 로드 균형 조정, 페일오버 및 단일 실패 지점 제거는 다중 서버 시스템에서 더 유연합니다.

수평으로 중복된 시스템

로드 균형 조정과 페일오버를 제공하는 병렬로 중복된 서버의 가용성을 늘릴 수 있는 몇 가지 방법이 있습니다. 다음 그림에서는 N+1 페일오버 시스템을 제공하는 두 개의 복제 서버를 설명합니다. N+1 시스템에는 한 서버가 실패할 경우 100% 용량을 제공하는 추가 서버가 있습니다.

그림 5–3 두 서버를 가진 N+1 페일오버 시스템

10개 CPU 성능 요구 사항을 충족시키기 위해 각각 10개의 CPU가 있는 2개의 복제 서버를 보여줍니다.

수평으로 중복된 시스템에서 각 서버의 컴퓨팅 성능은 동일합니다. 하나의 서버만 성능 요구 사항을 처리합니다. 다른 서버는 백업으로 서비스에 호출된 경우 100%의 성능을 제공합니다.

N+1 페일오버 설계의 장점은 페일오버 상황에서 100%의 성능을 유지하는 것입니다. 단점은 하드웨어 비용은 증가하면서도 그에 따른 성능을 모두 얻지 못한다는 것입니다(왜냐하면 한 서버는 오직 페일오버 상황에서만 사용하기 위해 대기하고 있기 때문입니다).

다음 그림은 두 서버 간 성능을 분산하도록 로드 균형 조정에 페일오버를 더하여 구현한 시스템을 보여줍니다.

그림 5–4 두 서버 간 로드 균형 조정 및 페일오버

10개 CPU 성능 요구 사항을 충족시키기 위해 각각 6개의 CPU가 있는 두 서버를 보여줍니다.

수평으로 중복된 시스템에서 설명한 시스템에서 한 서버가 실패하더라도 전체 용량의 일부이긴 하지만 모든 서비스가 여전히 사용 가능합니다. 남은 서버에서 10개 CPU 요구 사항의 60%인 6개 CPU의 컴퓨팅 성능을 제공합니다.

이 설계의 장점은 두 서버를 모두 사용할 수 있는 경우 추가로 2개의 CPU 잠재 용량이 있다는 점입니다.

다음 그림에서는 성능 및 로드 균형 조정을 위한 여러 서버 간의 배포를 보여줍니다.

그림 5–5 n개의 서버 간 로드 배포

10개 CPU 성능 요구 사항을 충족시키기 위해 각각 2개의 CPU가 있는 다섯 개의 서버를 보여줍니다.

수평으로 중복된 시스템과 같이 이 설계에 다섯 개의 서버가 있기 때문에 한 서버가 실패할 경우 나머지 서버에서 10개 CPU 성능 요구 사항의 80%인 총 8개 CPU의 컴퓨팅 성능을 제공합니다. 설계에 2개 CPU 용량을 가진 서버를 추가할 경우 결과적으로 N+1 설계가 됩니다. 한 서버가 실패하면 나머지 서버에서 성능 요구 사항의 100%를 충족시킵니다.

이 설계에는 다음과 같은 장점이 있습니다.

그러나 서버를 추가할 경우 관리 및 유지 보수 비용이 상당히 늘어날 수 있습니다. 또한 데이터 센터에 서버를 호스팅하는 비용을 고려해야 합니다. 일정 시점이 되면 서버 추가에 따른 수익이 줄어들기 시작합니다.

Sun Cluster 소프트웨어

높은 수준의 가용성이 필요한 경우(예: 4개 또는 5개의 9) Sun Cluster 소프트웨어를 가용성 설계의 일부로 고려할 수 있습니다. 클러스터 시스템은 저장소 및 기타 네트워크 자원이 있는 중복 서버를 연결한 것입니다. 클러스터의 서버들은 서로 계속해서 통신합니다. 한 서버가 오프라인이 될 경우 클러스터의 나머지 장치에서 해당 서버를 격리하고 실패한 노드의 응용 프로그램이나 데이터를 다른 노드로 페일오버합니다. 이 페일오버 프로세스는 시스템 사용자의 서비스를 방해하지 않고 비교적 빠르게 수행됩니다.

Sun Cluster 소프트웨어는 추가 전용 하드웨어와 구성, 관리 및 유지 보수를 위한 특수 기술이 필요합니다.

가용성 설계 예

이 절에서는 신원 기반 통신 예에서 이미 설명한 대로 1,000명에서 5,000명의 직원이 있는 중소 기업을 위한 신원 기반 통신 솔루션을 기반으로 하는 가용성 전략의 두 가지 예가 설명됩니다. 첫 번째 가용성 전략은 Messaging Server를 위한 로드 균형 조정을 보여줍니다. 두 번째는 Sun Cluster 소프트웨어를 사용하는 페일오버 솔루션을 보여줍니다.

Messaging Server를 위한 로드 균형 조정 예

다음 표에는 논리적 구조에 있는 각 논리적 Messaging Server 구성 요소의 CPU 성능에 대한 예상치가 나열되어 있습니다. 이 표에는 CPU 예상 개수 업데이트 절에서 계산한 최종 예상치가 반복되어 있습니다.

표 5–6 구성 요소 지원을 위한 CPU 예상 개수조정

구성 요소 

CPU 

메모리 

Messaging Server(MTA, 인바운드) 

4GB 

Messaging Server(MTA, 아웃바운드) 

4GB 

Messaging Server(MMP) 

4GB 

Messaging Server(메시지 저장소) 

4GB 

예를 들면 기술적 요구 사항 단계 중에 서비스 품질 요구 사항이 다음과 같이 지정되었다고 가정합니다.

가용성 요구 사항을 성취하기 위해 각 Messaging Server의 구성 요소가 각각 별개 하드웨어 서버에 있는 두 개의 인스턴스를 제공합니다. 한 구성 요소를 가진 서버가 실패하는 경우 다른 서버가 서비스를 제공합니다. 다음 그림은 이러한 가용성 전략을 위한 네트워크 다이어그램을 보여줍니다.

Messaging Server MMP 및 MTA 구성 요소에 대한 가용성을 나타내는 구조 다이어그램

이전 그림에서 CPU 수가 원래 예상치의 두 배가 됩니다. CPU는 다음 이유로 두 배가 됩니다.

Sun Cluster 소프트웨어를 사용하는 페일오버 예

다음 그림은 Calendar Server 백엔드 및 Messaging Server 메시징 저장소에 대한 페일오버 전략 예를 나타냅니다. Calendar Server 백엔드 및 메시징 저장소는 별개 하드웨어 서버에 복제되며 Sun Cluster 소프트웨어와 함께 페일오버를 위해 구성됩니다. CPU 수와 해당 메모리는 Sun Cluster의 각 서버에 복제됩니다.

그림 5–6 Sun Cluster 소프트웨어를 사용하는 페일오버 예

페일오버를 위한 Sun Cluster 소프트웨어와 함께 배포된 Calendar Server 및 Message Server 저장소를 나타내는 구조 다이어그램

디렉토리 서비스 복제 예

디렉토리 서비스를 고가용성을 제공하면서 다른 서버 간 트랜잭션을 분산하기 위해 복제할 수 있습니다. Directory Server는 다음을 포함하여 서비스 복제의 다양한 전략을 제공합니다.

Directory Server를 위한 가용성 전략은 복잡한 내용으로서 이 설명서 범위를 벗어납니다. 다음 절인 단일 마스터 복제 다중 마스터 복제에서는 기본 복제 전략에 대한 수준 높은 설명을 제공합니다. 자세한 내용은 Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide를 참조하십시오.

단일 마스터 복제

다음 그림은 기본 복제 개념을 보여 주는 단일 마스터 복제 전략을 나타냅니다.

그림 5–7 단일 마스터 복제 예

단일 마스터 복제 전략을 위한 데이터 흐름을 보여주는 다이어그램

단일 마스터 복제에서는 Directory Server의 한 인스턴스가 모든 변경 사항을 기록하면서 마스터 디렉토리 데이터베이스를 관리합니다. 마스터 데이터베이스는 모든 수의 사용자 데이터베이스에 복제됩니다. Directory Server의 사용자 인스턴스는 읽기 및 검색 작업을 위해 최적화되어 있습니다. 사용자가 수신한 모든 읽기 작업은 마스터에게 돌아가 참조됩니다. 마스터는 주기적으로 사용자 데이터베이스를 업데이트합니다.

단일 마스터 복제의 장점은 다음과 같습니다.

다중 마스터 복제

다음 그림은 디렉토리 액세스를 전세계적으로 분산하는데 사용할 수 있는 다중 마스터 복제 전략을 나타냅니다.

다중 마스터 복제에서는 Directory Server의 한 개 이상의 인스턴스가 마스터 디렉토리 데이터베이스를 관리합니다. 각 마스터에는 마스터 데이터베이스를 동기화하기 위한 절차를 지정하는 복제 계약이 있습니다. 각 마스터는 모든 사용자 데이터베이스에 복제합니다. 단일 마스터 복제와 같이 Directory Server의 사용자 인스턴스는 읽기 및 검색 액세스를 위해 최적화되어 있습니다. 사용자가 수신한 모든 읽기 작업은 마스터에게 돌아가 참조됩니다. 마스터는 주기적으로 사용자 데이터베이스를 업데이트합니다.

그림 5–8 다중 마스터 복제 예

다중 마스터 복제 전략을 위한 데이터 흐름을 보여 주는 다이어그램

다중 마스터 복제 전략은 단일 마스터 복제의 모든 장점에 더하여 마스터에 업데이트할 경우 로드 균형을 제어할 수 있는 가용성 전략을 제공합니다. 또한 전세계적으로 분산된 데이터 센터가 있는 기업에 있어서 중요한 고려 사항인 디렉토리 작업의 로컬 제어를 제공하는 가용성 전략도 구현할 수 있습니다.