HADR 운영 가이드 - Part 3: 튜닝 매개변수 2

HADR(High Availability Disaster Recovery)은 데이터베이스를 Primary와 Standby로 나눠 구성함으로써, 어떤 돌발적인 장애 상황에서건 데이터베이스의 성능과 가용성에 영향이 없도록 Primary 데이터베이스의 변경사항을 Standby 데이터베이스로 복제하는 기능이다. HADR 운영가이드 문서에서는 HADR 환경을 설치, 튜닝, 관리하는 다양한 방법을 소개한다. 이번 회에서는 지난 회에 이어 HADR 시스템의 최적의 성능을 내기 위해 필요한 매개변수에 대해 소개한다.

<연재순서>
HADR 운영 가이드 - Part 1: HADR 시스템 설치
HADR 운영 가이드 - Part 2: 튜닝 매개변수 1
HADR 운영가이드 Part 3: 튜닝 매개변수 2

hadr_peer_window 튜닝

Primary 가 지정된 시간인 피어 윈도우 (peer window) 동안 장애가 발생한다면 , hadr_peer_window 데이터베이스 구성 매개변수는 데이터 손실 없이 페일오버 (failover) 가 가능하다 . HADR Primary 가 피어 (peer) 상태에서 , 로컬 디스크에 로그를 작성할 때 in-memory 로그 버퍼에서 로그를 직접 보낸다 .만약 연결이 끊기면 Primary 는 hadr_peer_window 시간 동안 로깅을 차단하고 트랜잭션을 커밋하지 않는다 . 따라서 윈도우 내에서 Primary 의 장애가 발생하면 , 커밋되었지만 복제되지 않은 트랜잭션이 없어 , Standby 로 데이터 손실없이 페일오버 (failover) 가 이뤄진다 .피어 윈도우 (Peer Window) 가 0 이 아닌 값으로 설정되어 활성화되면 , Primary 는 피어 (peer) 상태에서 일정한 간격으로 Standby 에 메시지를 전송한다 . Primary 가 Standby 에 보낸 메시지는 ‘peer window end' 타임스탬프이다 .‘peer window end' 타임스탬프는 Primary 가 로깅을 차단하여 Standby 로의 연결이 끊어질 때까지의 시간이다 . 데이터베이스 스냅샷 또는 db2pd 도구와 같은 일반 HADR 모니터링 매커니즘을 사용하여 Primary 와 Standby 에서 피어 윈도우 엔드 (peer window end) 를 검색한다 . Primary 데이터베이스에 장애가 발생하면 , 피어 윈도우 내의 장애 발생 여부를 위해 , Standby 데이터베이스에서 피어 윈도우 엔드를 확인한다 .피어 윈도우 (Peer Window) 의 장애가 맞다면 , 데이터 손실 없이 페일오버가 가능하다 . 그렇지 않으면 , 피어 윈도우가 종료된 후 Primary 는 커밋된 트랜잭션 (Committed transactions) 이 발생되거나 발생되지 않을 수 있다 . 이 경우 데이터 손실의 위험을 감수해야 한다 . 페일오버 대신 장애가 발생한 Primary 를 복구한 후 다시 시작 (restart) 을 선택해야 한다 .클러스터 매니저와의 손쉬운 통합을 위해 TAKEOVER BY FORCE 명령문에 PEER WINDOW ONLY 옵션을 추가한다 . 이 옵션을 사용하여 명령문을 수행하면 현재 시간이 피어 윈도우 엔드 보다 빠른 경우에만 페일오버를 수행한다 .Primary 장애를 감지하면 , 클러스터 매니저는 페일오버를 시작하기 위해 TAKEOVER BY FORCE PEER WINDOW ONLY 명령문을 실행한다 . 이 옵션의 사용으로 자동화된 페일오버는 데이터 손실을 일으키지 않을 가능성을 최대화한다 .PEER WINDOW ONLY 옵션은 자동화된 페일오버에 사용하는 것이 가장 좋다 . 이 같은 구성에서 피어 윈도우 시간은 클러스터 매니저가 Primary 장애를 감지하고 페일오버를 사용하여 장애에 대응하기 위해 필요한 시간의 양만큼 설정되어야 한다 .다음과 같은 시간을 사용하여 예상 시간을 계산한다 .

hadr_peer_window 설정값 >= 응답 시간 + 안전 여유분 + 하트비트(heartbeat) 간격

여기에서 :- 응답 시간 = 자동화 소프트웨어가 장애를 감지하고 HADR takeover 를 호출하기 위한 예상 시간- 안전 여유분 = 5 초 . Primary-Standby 시스템 시계의 동기화를 위한 안전 여유분- 하트비트 (heartbeat) 간격 = MIN(hadr_timeout 값 /4, hadr_peer_window 값 /4, 30 초 )
< 그림 1>에서는 위 공식의 원리를 나타낸다 . 하트비트 (heartbeat) 와 primary 장애 사이의 시간이 하트비트 간격이다 . 하트비트는 Primary 가 또 다른 하트비트를 보내기 바로 전에 장애가 발생하는 최악의 시나리오이다 .Primary 시스템에서 ‘peer window end' 타임스탬프가 생성되고 하트비트 메시지를 통해 Standby 시스템에 보낸다 . TAKEOVER BY FORCE PEER WINDOW ONLY 명령문을 실행하는 동안 Standby 의 현재 시간과 비교할 때 , 완벽히 동기화된 Primary 와 Standby 서버 시계의 오차 처리를 적게 하기 위해서 타임 스탬프를 비교하는데 ‘5 초의 안전 여유분 ' 을 사용한다 . Primary 와 Standby 서버 시계를 동기화하기 위해 network time 프로토콜과 같은 방법을 사용한다 . 따라서 피어 윈도우 크기는 적어도 하트비트 간격 + 응답 시간 + 안전 여유분이어야 한다 .< 그림 1>

테이크오버 (takeover) 명령문은 피어 윈도우 엔드 내에 데이터가 손실 여부 확인 전까지 실행하지 않는다 . 피어 윈도우 엔드 이후에도 지속적으로 데이터베이스 스냅샷와 db2pd 와 같은 일반 HADR 모니터링 인터페이스를 사용해 Primary 와 Standby 에 보고된 피어 윈도우 엔드를 분석한다면 , Primary 장애 시간과 비교해봐야 한다 .Primary 장애시간이 피어 윈도우 엔드보다 더 먼저 발생했다면 . 데이터 손실을 없애기 위해 테이크오버 명령문을 실행한다 . 피어 윈도우 엔드 이후 명령문을 수행한다면 ‘peer window only' 옵션을 사용해선 안 된다 . ‘peer window only' 옵션은 클러스터 매니저가 Primary 장애 이후 빠르게 안전한 페일오버를 수행하여 다운타임을 최소화하는데 사용된다 .Primary 에서 Standby 로 보내는 peer window end' 메시지는 실제 하트비트 메시지로 구현된다 . 그러므로 피어 윈도우가 설정된 시스템의 하트비트 간격은 위 공식을 사용하여 피어 윈도우 크기를 계산한다 . Standby 에서 나타나는 피어 윈도우 엔드는 Primary 의 피어 윈도우 엔드 이면에 있는 하나의 업데이트 간격이다 . 즉 하트비트 간격이다 . 따라서 위의 피어 윈도우 설정 공식은 윈도우 크기에 하트비트 간격을 추가했다 .위 공식은 자동 페일오버만 고려한 것이다 . 그 외에 적은 데이터 손실 수용 , 네트워크와 Standby 장애의 지속 기간 , 네트워크 파티션에 대한 감지 및 대응 시간 등의 요소들은 피어 윈도우가 더 길어야 한다 .예를 들어 네트워크 또는 Standby 장애가 있는 경우 Primary 는 피어 윈도우가 만료한 후에도 HA 보호 없이 트랜잭션 처리를 지속한다 . Standby 복사본을 갖는 것이 중요하다는 비즈니스 요구사항이 기술된 경우 DBA 작업에서 Primary 를 차단하기 위해 더 긴 피어 윈도우가 필요하다 .hadr_peer_window 의 기본값은 0 이다 . 이는 Primary 는 연결이 끊어져도 대기중인 모든 트랜잭션을 차단하지 않고 , 곧바로 로깅을 재개한다는 것을 의미한다 . 이러한 작업은 페일오버 동안 데이터 손실의 위험을 감수하면서 최대한의 가용성을 제공한다 . 이 매개변수는 0 에서 무한대의 수까지 조정하여 사용자가 가용성과 데이터 손실 위험 간의 균형을 조정할 수 있다 .가장 긴 피어 윈도우는 ‘Primary 에 트랜잭션 커밋은 Standby 시스템에 복사본이 있어야 한다 ' 는 규칙을 필수적으로 적용한다 . 가용성이 중요하다면 , hadr_peer_window 최소의 값을 사용한다 .우선 네트워크에서 장애가 발생한 후 , Primary 시스템으로 이어지는 롤링 장애 (rolling failure) 에서 데이터 손실의 가능성을 줄일 수 있기 때문이다 . hadr_peer_window 값을 짧게 설정하면 , Primary 는 트랜잭션을 Standby 에 복제하지 않고 커밋한다 . 이러한 데이터는 페일오버 시에 손실된다 . 기본값 0 은 이전 버전과 호환성을 위해 사용된다 .연결 끊김 , 네트워크 오류 , Standby 장애뿐만 아니라 , hadr_timeout 값과 DB2_HADR_PEER_WAIT_LIMIT 레지스트리 변수 설정의 초과 등에 관계없이 , 일단 피어 윈도우가 활성화되면 Primary 은 구성된 기간 동안 트랜잭션을 차단한다 .Standby 의 ‘peer window only' 페일오버는 모든 경우에 안전하다 . 그러나 Standby 의 정상적인 종료로 연결이 종료된 경우 , 연결이 종료되자 마자 Primary 는 피어 윈도우를 건너 뛰고 로깅을 재개한다 .피어 윈도우와 hadr_timeout 은 독립적이며 순차적으로 적용된다 . 피어 윈도우는 연결이 끊어진 이후 얼마나 오랫동안 Primary 트랜잭션을 유지할지 지정한다 . 반면hadr_timeout은 연결이 끊기 위한 조건을 지정한다 .피어 윈도우와 DB2_HADR_PEER_WAIT_LIMIT 역시 독립적이다 . DB2_HADR_PEER_WAIT_LIMIT 은 연결이 끊어짐으로써 Primary 로깅 대기를 종료하기 위한 조건을 지정하기 때문이다 . 피어 윈도우를 사용할 때는 하트비트 간격을 기본값인 120 초에서 30 초로 낮춘다 .DB2_HADR_PEER_WAIT_LIMIT 레지스트리 변수를 설정하면 , 느리거나 차단된 Standby 데이터베이스 때문에 Primary 데이터베이스 로깅 차단을 방지할 수 있다 .

DB2_HADR_PEER_WAIT_LIMIT 튜닝

DB2_HADR_PEER_WAIT_LIMIT 값은 만약 Primary 데이터베이스에 로깅이 피어 상태에서 지정된 시간 동안 차단되었다면 , 연결이 끊어지기 전 HADR Primary 데이터베이스의 대기 기간을 결정한다 . Primary 데이터베이스는 로그를 보내기 위해 기다리거나 또는 로그를 내보내고 난 후 Standby 에서 ACK 메시지 응답을 기다린다 .연결이 끊겼는데 피어 윈도우가 활성화되어 있으면 Primary 데이터베이스는 피어 윈도우 크기 기간 동안 로깅 차단을 지속한다 . 그렇지 않은 경우 바로 로깅을 재개한다 . 따라서 DB2_HADR_PEER_WAIT_LIMIT 가 0 이 아닌 값으로 설정되어 있으면 클라이언트 최대 차단 시간은 DB2_HADR_PEER_WAIT_LIMIT 값과 hadr_peer_window 을 합한 값과 같다 .DB2_HADR_PEER_WAIT_LIMIT 값을 설정할 때 중요한 고려사항은 클라이언트의 ‘ 응답 시간 ' 이다 . DB2_HADR_PEER_WAIT_LIMIT 와 HADR_PEER_WINDOW 모두의 경우 더 짧은 값을 사용하면 클라이언트 응답 시간이 빨라진다 . 그러나 페일오버시 데이터를 손실할 가능성이 높다 .DB2_HADR_PEER_WAIT_LIMIT 과 hadr_timeout 을 대상 튜닝과 연계하여 사용할 수 있다 . hadr_timeout 을 짧게 지정하여 네트워크 문제와 Standby 의 크래시 (crash) 를 신속하게 감지할 수 있다 . 반면에 Primary 와 Standby 가 연결되어 있다면 , DB2_HADR_PEER_WAIT_LIMIT 를 상대적으로 길게 설정하여 복제를 활성화 상태로 유지할 수 있다 .반대로 보다 나은 클라이언트 응답시간을 위해 DB2_HADR_PEER_WAIT_LIMIT 의 짧은 지정과 보다 긴 hadr_timeout 을 사용하여 데이터베이스가 피어 상태가 아닐 때 잦은 끊김을 방지한다 .DB2_HADR_SOSNDBUF( 소켓 전송 버퍼 크기 ) 와 DB2_HADR_SORCVBUF( 소켓 수신 버퍼 크기 ) 레지스트리 변수를 사용하여 시스템에 있는 다른 TCP 연결에 영향을 주지 않고 HADR TCP 연결을 최적화할 수 있다 . TCP 윈도우 크기를 설정하는 데 있어 일반적인 규칙은 ‘TCP 윈도우 크기 = 전송 비율 x 왕복 이동 시간 ' 이다 .

DB2_HADR_SOSNDBUF 및 DB2_HADR_SORCVBUF 튜닝

WAN 시스템에서는 상대적으로 왕복 이동 시간이 길기 때문에 시스템 기본값보다 큰 값으로 설정한다 . 윈도우 크기가 너무 작으면 네트워크는 해당 대역폭을 충분히 활용할 수 없다 . HADR 과 같은 애플리케이션은 명목상의 대역폭보다 더 낮은 처리량을 나타낸다 . 필요비하는 것 외에는 다른 문제는 없다 .Primary 와 Standby 데이터베이스에서 DB2_HADR_SOSNDBUF 와 DB2_HADR_SORCVBUF 의 설정 값은 같아야 한다 .Primary 와 Standby 최적의 네트워크 설정 값을 찾기 위해 HADR 시뮬레이터를 사용한다 . 시뮬레이터는 실제 데이터베이스 시스템에 전혀 영향을 주지 않고 몇 초 만에 실행할 수 있다 .그러나 데이터베이스에서 이러한 매개변수를 업데이트 하려면 인스턴스를 중지한 후 다시 시작해야 한다 . 시뮬레이터를 먼저 사용한 후 해당 값을 데이터베이스에 적용한다 .

필자소개

Dale McInnis: DB2 Availability Architect 선임 기술자
Yuke Zhuge: DB2 개발자
Jessica Rockwood: DB2 개발자
Robert Causley: DB2 Information 개발자출처 : KDUG (http://www.kdug.kr/)제공 : DB포탈사이트 DBguide.net