트랜잭션 고가용성
트랜잭션 서비스의 고가용성은 클러스터의 모든 서버가 동일한 클러스터의 다른 모든 서버에 대해 트랜잭션 작업을 복구할 수 있도록 합니다. 이 기능은 전체 WebSphere® Application Server 고가용성 (HA) 전략의 일부를 형성합니다.
![[z/OS]](../images/ngzos.svg)
이 기능은 피어 다시 시작 및 복구에 대한 지원에 추가되며 이를 사용하여
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은 다시 시작 가능하고 수행해야 할 자체 복구 프로세스는 없습니다.
