자동화된 트랜잭션 피어 복구와 수동 트랜잭션 피어 복구 사이에 선택하는 방법

파일 시스템 유형은 사용할 트랜잭션 피어 복구 종류를 결정하는 데 중요한 요소입니다. 서로 다른 파일 시스템이 서로 다른 동작을 가지고 있습니다. 특히 파일 잠금 동작은 자동화된 피어 복구와 수동 피어 복구를 선택할 때 중요합니다.

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는 호스트를 다시 시작할 수 있을 때까지 실패한 호스트 대신 파일 잠금을 보유합니다. 이 컨텍스트에서 호스트는 잠금을 요청한 애플리케이션 서버를 실행하는 물리적 시스템이며 결국 잠금을 해제하도록 트리거하는 것은 애플리케이션 서버가 아닌 호스트의 다시 시작입니다.

NFSv3에서의 파일 잠금을 설명하기 위해 클러스터 멤버가 실패한 경우의 동작을 고려해 보도록 하겠습니다.
  1. 서버 H가 호스트 H에서 실행 중이고 자체 고유의 복구 로그 파일에 대해 독점적 파일 잠금을 보유하고 있습니다.
  2. 서버 P가 호스트 P에서 실행 중이고 자체 고유의 복구 로그 파일에 대해 독점적 파일 잠금을 보유하고 있습니다.
  3. 서버 H를 실행 중인 호스트 H가 실패합니다. 파일 서버의 NFS 잠금 관리자가 대신 서버 H에 부여된 잠금을 보유합니다.
  4. WebSphere Application Server에서 서버 H에 대해 서버 P에서 피어 복구 이벤트가 트리거됩니다.
  5. 서버 P는 피어 복구 로그에 대해 독점적 파일 잠금을 얻으려고 하지만 서버 H 대신 보유되어 있으므로 그렇게 할 수 없습니다. 피어 복구 프로세스가 블로킹됩니다.
  6. 지정되지 않은 시간에 호스트 H가 다시 시작되었습니다. 대신 보유된 잠금이 해제되었습니다.
  7. 서버 P의 피어 복구 프로세스가 블로킹 해제되고 피어 복구를 수행하는 데 필요한 독점적 파일 잠금이 부여됩니다.
  8. 피어 복구는 서버 H 대신 서버 P에서 발생합니다.
  9. 서버 H가 다시 시작되었습니다.
  10. 피어 복구가 서버 P에서 계속 진행 중이면 복구는 정지합니다.
  11. 서버 P는 복구 로그에 대한 독점적 잠금을 해제하고 복구 로그 소유권을 서버 H로 되돌립니다.
  12. 서버 H는 독점적 잠금을 확보하므로 이제 정상적인 트랜잭션 로깅을 수행할 수 있습니다.

이와 같은 동작으로, NFSv3에서는 자동화된 피어 복구를 사용하려면 파일 잠금이 사용 불가능하도록 설정해야 합니다. 파일 잠금이 사용 불가능하도록 설정하면 복구 로그에 동시 액세스가 발생할 수 있으므로, 먼저 시스템 과부하 및 네트워크 파티셔닝에 대해 시스템을 보호하는 것이 중요합니다. 또는 수동 피어 복구를 구성할 수 있습니다. 이 때 사용자는 실패한 서버에 대해서만 피어 복구 처리를 수동으로 트리거하여 동시 액세스를 방지합니다.

시스템 과부하
시스템 과부하는 응답 시간이 너무 느려서 요청이 제한 시간을 초과하기 시작하는 것과 같이 시스템이 과중하게 부하될 때 발생합니다. 이와 같은 과부하의 가능한 몇 가지 이유는 다음과 같습니다.
  • 서버 파워가 부족하여 워크로드를 처리할 수 없습니다.
  • 서버는 요청의 임시 서지를 수신했습니다.
  • 충분하지 않은 실제 메모리는 사용 가능합니다. 결과적으로, 운영 체제가 필요한 CPU 시간을 애플리케이션 서버에 제공하기 위한 페이징으로 너무 바쁩니다.
네트워크 파티션
네트워크 파티셔닝은 네트워크에서의 통신 장애로 독립적이고 서로 접속할 수 없는 두 개의 작은 네트워크가 생성될 때 발생합니다.
그림 1. 정상적으로 실행되는 시스템의 하트비트와 시스템 과부하 및 네트워크 파티셔닝의 명백한 서버 장애 후 하트비트의 비교정상적으로 실행되는 시스템의 하트비트와 시스템 과부하 및 네트워크 파티셔닝의
명백한 서버 장애 후 하트비트의 비교

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


주제 유형을 표시하는 아이콘 개념 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjta_hacons_log
파일 이름:cjta_hacons_log.html