트랜잭션 고가용성
트랜잭션 서비스의 고가용성은 클러스터의 서버가 같은 클러스터의 다른 서버를 위해 트랜잭션 작업을 복구할 수 있도록 합니다. 이 기능은 전체 WebSphere® Application Server 고가용성(HA) 계획의 일부를 형성합니다.
이 기능은 sysplex의 피어 시스템에서 다시 시작할 수 있는
피어 다시 시작 및 복구 지원에도 추가됩니다.
트랜잭션 서비스는 트랜잭션 복구를 위한 가장 중요한 파트로서 트랜잭션 복구 로그에서 활성 트랜잭션 작업에 대한 정보를 로그합니다. 트랜잭션 복구 로그는 지속적으로 정보를 저장합니다. 이는 서버 실패 시 진행 중이었던 트랜잭션 작업을 서버가 다시 시작되면 해석할 수 있다는 것을 의미합니다. 이 활동은 트랜잭션 복구 처리로 알려져 있습니다. 처리 중인 트랜잭션의 완료와 더불어 이 처리에서는 연관된 자원 관리자에 있는 모든 잠금의 해제를 보장합니다.
피어 복구 처리
애플리케이션 서버를 다시 시작할 때 수행되는 표준 복구 프로세스를 통해 서버가 로그된 트랜잭션 정보를 검색 및 처리하고 트랜잭션 작업을 복구하며 문제가 있는 트랜잭션을 완료할 수 있습니다. 트랜잭션 작업의 완료(및 트랜잭션이 보유한 데이터베이스 잠금의 해제)는 서버가 성공적으로 다시 시작되어 트랜잭션 로그를 처리하면 발생합니다. 서버 복구 속도가 느리거나 수동 개입이 필요한 경우, 트랜잭션 작업을 완료할 수 없으며 연관된 데이터베이스에 대한 액세스는 차단됩니다.
트랜잭션 작업 및 연관된 데이터베이스에 대한 방해를 최소화하기 위해 WebSphere Application Server는 트랜잭션 피어 복구라고 하는 고가용성 계획을 제공합니다.
피어 복구는 서버 클러스터 내에서 제공됩니다. 피어가 자신의 트랜잭션 워크로드를 계속 관리하는 동안 피어 서버(다른 클러스터 멤버)는 실패한 서버의 복구 로그를 처리할 수 있습니다. 실패한 서버가 다시 시작되기를 기다리거나 실패한 서버를 복구하기 위해 특별히 새 애플리케이션 서버를 시작할 필요는 없습니다.

피어 복구 프로세스는 실패한 서버를 다시 시작하는 것과 동일한 논리이지만 피어 서버에서 장애가 발생한 서버를 완전히 다시 시작하지는 않습니다. 피어 복구 프로세스는 미해결 프로세스를 완료할 수 있는 기회를 제공하며, 복구 처리 이후 새 작업을 시작할 수 없습니다. 실패한 서버에는 전달 처리가 불가능합니다.
피어 복구는 개별 서버의 고가용성 요구사항을 서버 클러스터로 이동합니다. 이러한 장애가 발생한 후에는 클러스터의 관리 시스템이 나머지 서버로 새 작업을 디스패치하므로 차이점만 전체 서버 처리량의 잠재적인 감소 요인이 됩니다. 서버가 실패하는 경우, 실패한 서버에서 활성화된 작업을 완료하고 대체 서버로 요청 경로를 재지정하면 됩니다.
- 자동 피어 복구
- 이 스타일은 복구 시작의 기본값입니다. 애플리케이션 서버가 실패하는 경우, WebSphere Application Server는 스스로 피어 복구 처리를 수행할 서버를 자동으로 선택하여 다시 시작 시 복구를 실패한 서버로 다시 전달합니다. 이 모델을 사용하려면 트랜잭션 로그 복구를 사용하게 하고 각 클러스터 멤버의 복구 로그 위치를 구성하십시오.
- 수동 피어 복구
- 이 피어 복구 스타일을 명시적으로 구성해야 합니다. 애플리케이션 서버가 실패하는 경우 관리 콘솔을 사용하여 스스로 복구 처리를 수행할 서버를 선택합니다.
HA 환경에서는 보정 로그 및 트랜잭션 로그를 구성해야 합니다. 클러스터의 각 서버에 대해 보정 서비스 설정을 사용하여 고유 보상 로그 위치를 구성하고 모든 클러스터 멤버가 해당 보정 로그에 액세스할 수 있는지 확인하십시오.
피어 복구 예
다음 다이어그램은 단일 서버가 실패하는 경우 수행하는 피어 복구 프로세스에 대해 설명합니다. 그림 2는 WebSphere Application Server 클러스터에서 실행 중인 세 개의 안정적인 서버를 보여줍니다. 워크로드는 이러한 서버 간의 균형을 조정하며 결과적으로 각 서버를 대신하여 백엔드 데이터베이스에 의해 잠기게 됩니다.

그림 3은 서버 1이 데이터베이스에서 잠금을 제거하지 않은 상태로 실패한 후 시스템의 상태를 보여줍니다. 서버 2 및 서버 3은 기존 트랜잭션을 실행하여 완료할 수 있으며 백엔드 데이터베이스의 기존 잠금을 해제할 수 있지만 서버 1을 대신하여 계속 잠겨 있어 추가 액세스는 불가능합니다. 실제로 서버 2 및 서버 3에 의한 일부 액세스 레벨은 잠금 세분성이 올바르게 구성된 것으로 가정하여 계속 가능하지만 이 예에서는 서버 2 및 서버 3이 잠긴 레코드에 대한 액세스를 시도했으나 차단되는 것으로 가정합니다.

그림 4는 서버 3 내부에서 실행 중인 서버 1에 대한 피어 복구 프로세스를 보여줍니다. 복구 프로세스의 트랜잭션 서비스 부분은 서버 1에 의해 저장되는 정보를 검색하고 이 정보를 사용하여 문제가 있는 트랜잭션을 완료합니다. 이 그림에서는 서버 1을 대신하여 데이터베이스에 의한 잠금이 계속 유지되므로 피어 복구 프로세스는 부분적으로 완료됩니다.

그림 5는 피어 복구 프로세스가 완료된 시점의 서버 클러스터 상태를 보여줍니다. 시스템이 두 개의 서버만으로 구성되어 안정적입니다. 워크로드가 두 서버 간의 균형을 조정합니다. 서버 1은 수행할 복구 처리 작업이 없으며 다시 시작할 수 있습니다.
