자동화된 트랜잭션 피어 복구와 수동 트랜잭션 피어 복구 사이에 선택하는 방법
파일 시스템 유형은 사용할 트랜잭션 피어 복구 종류를 결정하는 데 중요한 요소입니다. 서로 다른 파일 시스템이 서로 다른 동작을 가지고 있습니다. 특히 파일 잠금 동작은 자동화된 피어 복구와 수동 피어 복구를 선택할 때 중요합니다.
WebSphere® Application Server 고가용성(HA) 지원은 하트비트 메커니즘을 사용하여 서버가 계속 실행 중인지 여부를 판별합니다. 서버는 하트비트 요청에 대한 응답으로 중지할 때 실패한 것으로 간주됩니다. 시스템 과부하 및 네트워크 파티셔닝(이 주제 어디에선가 설명됨)과 같은 일부 시나리오에서는 서버가 계속 실행 중인데도 하트비트에 대한 응답에서 중지될 수 있습니다. WebSphere Application Server는 파일 잠금 기술을 사용하여 이와 같은 이벤트에서 트랜잭션 복구 로그에 동시에 액세스하는 일이 없도록 합니다. 둘 이상의 서버가 복구 로그에 액세스하면 데이터 무결성이 손실될 수 있기 때문입니다.
그러나 모든 파일 시스템이 필요한 파일 잠금 시맨틱을 제공하지는 않습니다. 특히 서버가 실패할 때 파일 잠금이 해제됩니다. 예를 들어, NFSv4(Network File System Version 4)는 이 해제 동작을 제공하는 반면 NFSv3(Network File System Version 3)는 제공하지 않습니다.
WebSphere Application Server의 파일 시스템 잠금 프로토콜 테스트를 실행하여 공유 파일 시스템이 트랜잭션의 장애 복구 로그를 지원하는지 여부를 테스트할 수 있습니다. 테스트를 실행하려면 http://www-01.ibm.com/support/docview.wss?uid=swg24010222의 내용을 참조하십시오.
NFSv4는 호스트가 실패하는 경우에 호스트 대신 보유된 잠금을 해제합니다. 피어 복구는 실패한 하드웨어를 다시 시작하지 않아도 자동으로 발생할 수 있습니다. 따라서 이 NFS 버전은 자동화된 피어 복구에 사용하기 더 적합합니다.
NFSv3는 호스트를 다시 시작할 수 있을 때까지 실패한 호스트 대신 파일 잠금을 보유합니다. 이 컨텍스트에서 호스트는 잠금을 요청한 애플리케이션 서버를 실행하는 물리적 시스템이며 결국 잠금을 해제하도록 트리거하는 것은 애플리케이션 서버가 아닌 호스트의 다시 시작입니다.
- 서버 H가 호스트 H에서 실행 중이고 자체 고유의 복구 로그 파일에 대해 독점적 파일 잠금을 보유하고 있습니다.
- 서버 P가 호스트 P에서 실행 중이고 자체 고유의 복구 로그 파일에 대해 독점적 파일 잠금을 보유하고 있습니다.
- 서버 H를 실행 중인 호스트 H가 실패합니다. 파일 서버의 NFS 잠금 관리자가 대신 서버 H에 부여된 잠금을 보유합니다.
- WebSphere Application Server에서 서버 H에 대해 서버 P에서 피어 복구 이벤트가 트리거됩니다.
- 서버 P는 피어 복구 로그에 대해 독점적 파일 잠금을 얻으려고 하지만 서버 H 대신 보유되어 있으므로 그렇게 할 수 없습니다. 피어 복구 프로세스가 블로킹됩니다.
- 지정되지 않은 시간에 호스트 H가 다시 시작되었습니다. 대신 보유된 잠금이 해제되었습니다.
- 서버 P의 피어 복구 프로세스가 블로킹 해제되고 피어 복구를 수행하는 데 필요한 독점적 파일 잠금이 부여됩니다.
- 피어 복구는 서버 H 대신 서버 P에서 발생합니다.
- 서버 H가 다시 시작되었습니다.
- 피어 복구가 서버 P에서 계속 진행 중이면 복구는 정지합니다.
- 서버 P는 복구 로그에 대한 독점적 잠금을 해제하고 복구 로그 소유권을 서버 H로 되돌립니다.
- 서버 H는 독점적 잠금을 확보하므로 이제 정상적인 트랜잭션 로깅을 수행할 수 있습니다.
이와 같은 동작으로, NFSv3에서는 자동화된 피어 복구를 사용하려면 파일 잠금이 사용 불가능하도록 설정해야 합니다. 파일 잠금이 사용 불가능하도록 설정하면 복구 로그에 동시 액세스가 발생할 수 있으므로, 먼저 시스템 과부하 및 네트워크 파티셔닝에 대해 시스템을 보호하는 것이 중요합니다. 또는 수동 피어 복구를 구성할 수 있습니다. 이 때 사용자는 실패한 서버에 대해서만 피어 복구 처리를 수동으로 트리거하여 동시 액세스를 방지합니다.
- 시스템 과부하
- 시스템 과부하는 응답 시간이 너무 느려서 요청이 제한 시간을
초과하기 시작하는 것과 같이 시스템이 과중하게 부하될 때 발생합니다. 이와 같은 과부하의
가능한 몇 가지 이유는 다음과 같습니다.
- 서버 파워가 부족하여 워크로드를 처리할 수 없습니다.
- 서버는 요청의 임시 서지를 수신했습니다.
- 충분하지 않은 실제 메모리는 사용 가능합니다. 결과적으로, 운영 체제가 필요한 CPU 시간을 애플리케이션 서버에 제공하기 위한 페이징으로 너무 바쁩니다.
- 네트워크 파티션
- 네트워크 파티셔닝은 네트워크에서의 통신 장애로 독립적이고 서로 접속할 수 없는 두 개의 작은 네트워크가 생성될 때 발생합니다.

정상적으로 실행되는 동안 네트워크의 두 서버는 하트비트를 교환합니다. 시스템 과부하 상태에서는 하트비트 조작이 제한시간을 초과하여 서버 장애가 발생합니다. 네트워크 파티셔닝 후에는 각 서버가 독립된 네트워크에 있으므로 서버 간 하트비트를 전달할 수 없어서 서버 장애가 발생합니다.