test

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

가용성 계획

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

가용성 조정

시스템 및 응용 프로그램의 가용성을 계획하려면 여러 응용 프로그램에 액세스하는 사용자 그룹의 가용성 요구 사항을 평가합니다. 예를 들어 외부 유료 사용자와 비즈니스 파트너는 종종 내부 사용자보다 더 높은 QoS(서비스 품질) 기대치를 갖습니다. 따라서 응용 프로그램 기능이나 응용 프로그램, 또는 서버를 사용할 수 없게 되는 경우 내부 사용자가 외부 유료 고객보다 상황을 잘 받아들입니다.

다음 그림은 점점 감소하는 발생 가능한 이벤트를 완화하기 위해 증가하는 비용과 복잡성을 보여줍니다. 연속선상의 한쪽 끝인 로드 균형이 조정된 단순 클러스터의 경우 현지화된 응용 프로그램, 미들웨어 및 하드웨어 오류를 허용합니다. 반대편 끝의 지리적으로 떨어져 있는 클러스터의 경우 전체 데이터 센터에 영향을 주는 주요 재난을 완화할 수 있습니다.

적절한 투자 수익률(ROI) 실현을 위해 응용 프로그램 내 기능의 가용성 요구 사항을 확인하는 작업은 종종 의미가 있습니다. 예를 들어 보험 견적 시스템을 사용할 수 없게 되어 잠재적으로 새 비즈니스를 놓치는 상황은 허용될 수 없지만 기존 고객이 현재 보상 범위를 볼 수 있는 계정 관리 기능의 경우 잠시 사용할 수 없더라도 기존 고객을 잃게 되지는 않습니다.

클러스터를 사용하여 가용성 향상

가장 기본적인 수준의 클러스터는 대개 여러 개의 물리적 서버에서 호스팅되지만 클라이언트에 단일 인스턴스로 나타나는 Application Server 인스턴스의 그룹입니다. 클러스터는 단일 시스템의 단일 인스턴스보다 높은 가용성과 수평 확장성을 제공합니다. 이 기본 수준 클러스터링은 HTTP 및 HTTPS 요청을 수신하여 클러스터 내 Application Server 인스턴스 중 하나로 전달하는 Application Server의 HTTP 로드 밸런서 플러그인과 함께 작동합니다. ORB와 통합 JMS 브로커도 Application Server 클러스터에 대한 로드 균형 조정을 수행합니다. 한 인스턴스에 오류가 발생하거나 네트워크 오류 때문에 사용할 수 없게 되거나 응답하지 않으면 요청이 기존에 있던 사용 가능한 시스템으로만 리디렉션됩니다. 또한 로드 밸런서는 실패한 인스턴스가 복구되었을 때를 인식하고 그에 따라 로드를 재분산할 수 있습니다.

HTTP 로드 밸런서는 서버와 특정 URL을 모니터하여 사용 가능 여부를 확인할 수 있는 상태 검사기 프로그램도 제공합니다. 상태 검사 자체가 큰 부담이 되지 않도록 상태 검사 오버헤드 관리에 유의해야 합니다.

상태 비보존형 응용 프로그램이나 중요하지 않은 단순 사용자 트랜잭션만 관련된 응용 프로그램의 경우 로드 균형이 조정된 단순 클러스터만으로 대개 충분합니다. 업무상 중요한 상태 보존형 응용 프로그램의 경우 세션 지속성을 위해 HADB를 사용하는 것이 좋습니다. HADB에 대한 개요를 보려면 Application Server 관리 설명서의 1 장, 제품 개념에서 고가용성 데이터베이스를 참조하십시오.

응용 프로그램을 온라인으로 업그레이드하려면 Application Server 인스턴스를 여러 클러스터로 그룹화하는 것이 좋습니다. Application Server에는 응용 프로그램과 인스턴스를 모두 정지하는 기능이 있습니다. 정지는 현재 인스턴스나 응용 프로그램을 사용하는 사용자에게 영향을 주지 않고 제어된 방식으로 인스턴스(또는 인스턴스 그룹)나 특정 응용 프로그램을 오프라인으로 전환하는 기능입니다. 한 인스턴스가 정지됨에 따라 새 사용자는 다른 인스턴스의 업그레이드된 응용 프로그램을 사용하게 됩니다. 이러한 응용 프로그램 업그레이드 유형을 롤링 업그레이드라고 합니다. 활성 응용 프로그램 업그레이드에 대한 자세한 내용은 Sun Java System Application Server 9.1 고가용성 관리 설명서의 가용성 손실 없이 응용 프로그램 업그레이드 를 참조하십시오.

시스템에 중복 장치 추가

고가용성을 얻기 위한 한 가지 방법으로 하드웨어 및 소프트웨어를 중복하여 시스템에 추가할 수 있습니다. 한 장치에 오류가 발생하면 중복 장치가 역할을 인계 받게 되는데, 이를 내결함성이라고도 합니다. 일반적으로 고가용성을 극대화하기 위해 시스템의 모든 가능한 오류 지점을 확인 및 제거합니다.

오류 클래스 확인

중복 수준은 시스템이 허용해야 하는 오류 클래스(오류 유형)에 의해 결정됩니다. 다음은 오류 클래스의 몇 가지 예입니다.

중복 시스템 프로세스는 단일 시스템 프로세스 오류 및 단일 시스템 오류를 허용합니다. 미러된(쌍을 이룬) 중복 시스템을 다른 전원 공급 장치에 연결할 경우 단일 전원 오류가 허용됩니다. 미러된 시스템을 다른 건물에서 유지할 경우 한 건물에서 발생한 화재를 허용할 수 있습니다. 미러된 시스템을 지리적으로 격리된 위치에서 유지하면 지진과 같은 자연 재난을 허용할 수 있습니다.

HADB 중복 장치를 사용하여 가용성 향상

가용성을 향상시키기 위해 HADB 노드는 성능 목표 설정의 설명대로 항상 DRU(Data Redundancy Unit)에서 사용됩니다.

HADB 예비 노드를 사용하여 내결함성 향상

예비 노드를 사용하면 내결함성이 향상됩니다. 예비 노드는 필수 항목은 아니지만 최대 가용성을 제공합니다.

페일오버 용량 계획

페일오버 용량 계획은 서버나 프로세스 오류 시 시스템 중단 없이 데이터를 복구하고 처리를 계속할 수 있도록 Application Server 배포에 추가해야 하는 추가 서버 및 프로세스의 수를 결정하는 작업입니다. 시스템이 오버로드되면 프로세스나 서버 오류가 발생하여 응답 시간 저하나 전체 서비스 손실을 초래할 수 있습니다. 성공적인 배포에는 반드시 이러한 상황에 대한 대비가 있어야 합니다.

특히 최대 로드 시 용량을 유지하려면 Application Server 인스턴스를 실행하는 예비 시스템을 기존 배포에 추가합니다.

예를 들어 각각 한 개의 Application Server 인스턴스를 실행하는 시스템 두 대로 구성된 시스템을 가정할 경우 두 대의 시스템에서 초당 요청이 300개에 달하는 최대 로드를 함께 처리합니다. 두 시스템 간 로드 분산이 균일하다고 했을 때 둘 중 한 대의 시스템을 사용할 수 없게 될 경우 이 시스템은 요청을 150개만 처리할 수 있으므로 최대 로드 시 요청의 절반이 처리되지 않습니다.