(OTN) [RAC] 9I REAL APPLICATION CLUSTERS의 FAST RECONFIGURATION

[RAC] 9I REAL APPLICATION CLUSTERS의 FAST RECONFIGURATION Posted: 2007. 2. 19 오후 9:09
제품 : ORACLE SERVER 작성날짜 : 2004-08-13 [RAC] 9I REAL APPLICATION CLUSTERS의 FAST RECONFIGURATION ======================================================== PURPOSE 이 문서는, 오라클 리얼 애플리케이션 클러스터 환경에서 fast reconfiguration이 얼마나 빨리 수행되는지에 대한 설명을 목적으로 한다. SCOPE Real Application Clusters(RAC) Option은 9i Standard Edition에서는 지원하지 않는다. Explanation Fast Reconfiguration은, 9i 리얼 애플리케이션 클러스터에서 새로 추가된 기능으로, RAC 인스턴스의 reconfiguration이 발생하는 상황에서 가용시간을 증가 시키는 것을 목적으로 한다. Oracle 8에서 open 상태의 dlm lock/resource에 대한 OPS reconfiguraion은 다음과 같은 조건을 만족할 때 수행된다 : 1. 새로운 인스턴스가 클러스터에 조인 되었을 때 2. 인스턴스가 종료 되거나 클러스터에서 빠져 나갈 때 3. 노드가 중단될 때 Oracle 8에서는 이와 같은 작업이 순간적으로 완료 될 수도 있으나, 경우에 따라서는 "lock remastering" 이라는 메시지와 함께 수분동안 진행될 수도 있다. 예를 들어 인스턴스가 클러스터에서 빠져 나가는 경우, 클러스터에서 빠져 나가는 인스턴스에서 점유 했던 open 상태의 모든 lock이나 resource가 삭제 된 후, 클러스터 내 나머지 인스턴스에 lock 이나 resource가 공평하게 분배 되는 동안 lock remastering 작업이 진행된다. 만약 freeze_db_for_fast_instance_recovery = true 로 지정되어 있다면 (기본 설정), 이 기간동안 데이터베이스 전체에 대한 lock 관련 작업은 진행되지 않는다. Reconfiguration 작업에 걸리는 시간은 open 상태의 dlm lock/resource의 갯수와 (fixed locking 시 많은 갯수가 사용됨) 하드웨어 자원 (메모리, 노드간 연결 회선 속도, CPU)에 의존적이다. Reconfiguration 작업이 자주 발생할 경우, 성능 저하가 발생해 사용자 입장에서는, 데이터베이스가 hang 상태가 된 것으로 느껴 질 수 있다. 이 문제는 Oracle 9i에서는 다음과 같이 조정 되었다. 1. reconfiguration에 걸리는 시간 단축. 2. reconfiguration 중에도 일부 프로세스는 진행 가능되도록 허용. RAC reconfiguration에 걸리는 시간 단축: RAC에서 reconfiguration에 걸리는 시간을 단축 시키기 위한 방법이 몇가지 적용되었다. 9i RAC에서 변경된 첫번째 사항은 더이상 fixed lock을 사용하지 않는다는 것이다. 이것은, 구동 시간을 단축 시켜 주는데 이것은 lock을 구동 시점에서 할당 받지 않아도 되기 때문이다. 두번째 사항은, 모든 노드를 대상으로, 모든 lock/resource에 대한 remastering을 하는 것이 아니라, "lazy remastering"이라는 알고리즘을 사용하여, reconfiguration 동안 최소한의 lock/resource에 대한 remastering을 수행한다. 클러스터에서 빠져 나가는 인스턴스에 대해서는, 빠져 나가는 인스턴스와 연관된 lock/resource에 대해서 확인을 하도록 하고, 나머지 인스턴스로 부터는 최소한의 lock/resource를 대상으로 remastering을 하도록 한다. 인스턴스 1,2,3이 모두 가용한 상태에서 dlm resource를 관장 (master) 하고 있다           Instance 1   Instance 2   Instance 3           Masters:   Masters:   Masters: R1, R2   R3, R4   R5, R6           예를 들어 인스턴스 3이 비정상 종료된 경우, 인스턴스 1, 2는 자신이 관장하고 있는 resource는 유지한채, 인스턴스 3에서 관장하던 resource를 분배 받는다. 인스턴스 1은 resource 5를 인스턴스 2는 resource 6을 분배 받았다.           Instance 1   Instance 2             Instance 3: Masters:   Masters:   Down R1, R2, R5   R3, R4, R6               즉, 모든 resource를 제거하고 remastering을 가용한 인스턴스에 배분하는 대신 RAC에서는 필요한 resource에 대한 remastering을 수행한다. ( 위 예에서는 클러스터를 빠져 나간 인스턴스의 resource를 대상으로 함) 따라서, reconfiguration 작업이 좀더 효과적으로 수행 되도록 변경 되었다. 클러스터에 인스턴스가 조인 하는 경우, RAC는 유한한 갯수의 resource를 새로운 인스턴스에 배당해준다 :           Instance 1   Instance 2             Instance 3: Masters:   Masters:   Down R1, R2, R3   R4, R5, R6               인스턴스가 클러스터에 조인을 한 다음 예에서, 최소 갯수의 resource가 다른 인스턴스로 부터 인스턴스 3에 remastering 되었다. 이것은 8i에서 보다 훨씬 빨리 처리되는 방식으로, 8i 까지는 모든 resource를 재 분배 해 주었다. 인스턴스는 인스턴스 1, 2로 부터 각각 resource 3, 6을 할당 받았다 :           Instance 1   Instance 2   Instance 3           Masters:   Masters:   Masters: R1, R2   R4, R5   R3, R6           이 예는, resource를 골고루 잘 나누어준 예를 보여 주고 있으나,이 예는 RAC 에서 primary/secondary 노드 기능을 사용하지 않는 다는 것을 가정하고 있다. primary/secondary 구성에서는, primary 인스턴스에서 모든 resource에 대한 mastering 작업을 수행한다. (Note 76632.1 참조) reconfiguration이 발생할 경우 alert log에는 다음과 같은 메시지가 남는다 : Wed Apr 25 16:56:14 2001 Reconfiguration started List of nodes: 1, Lock DB frozen one node partition Communication channels reestablished Server queues filtered Master broadcasted resource hash value bitmaps Non-local Process blocks cleaned out Resources and locks cleaned out Resources remastered 424 606 PCM locks traversed, 0 cancelled, 11 closed 311 PCM resources traversed, 0 cancelled 2989 PCM resources on freelist, 3300 on array, 3300 allocated set master node info 606 PCM locks traversed, 0 replayed, 11 unopened Submitted all remote-lock requests Update rdomain variables 0 write requests issued in 595 PCM resources 0 PIs marked suspect, 0 flush PI msgs Dwn-cvts replayed, VALBLKs dubious All grantable locks granted Wed Apr 25 16:56:14 2001 Reconfiguration complete reconfiguration이 발생할 경우 LMON trace에는 다음과 같은 메시지가 남는다 : *** 2001-04-25 16:56:14.565 Reconfiguration started Synchronization timeout interval: 600 sec List of nodes: 1, Lock DB frozen node 1 * kjshashcfg: I'm the only node in the cluster (node 1) Active Sendback Threshold = 100 % Communication channels reestablished Server queues filtered Master broadcasted resource hash value bitmaps Non-local Process blocks cleaned out Resources and locks cleaned out Resources remastered 424 606 PCM locks traversed, 0 cancelled, 11 closed 311 PCM resources traversed, 0 cancelled 2989 PCM resources on freelist, 3300 on array, 3300 allocated set master node info 606 PCM locks traversed, 0 replayed, 11 unopened Submitted all remote-lock requests Update rdomain variables 0 write requests issued in 595 PCM resources 0 PIs marked suspect, 0 flush PI msgs Dwn-cvts replayed, VALBLKs dubious All grantable locks granted *** 2001-04-25 16:56:14.775 Reconfiguration complete reconfiguration이 발생할 경우 DIAG trace에는 다음과 같은 메시지가 남는다 : Reconfiguration starts [incarn=5] I'm the master node Reconfiguration completes [incarn=5] reconfiguration 중에도 일부 프로세스는 진행 가능되도록 허용 : 앞에서 언급한 바와 같이 lazy remastering 개념을 통해 인스턴스에서는 이미 자신이 관장하던 lock/resource를 계속해서 유지할 수 있게 되었다. 반면 이전 버전에서는 모든 lock/resource가 reconfiguration동안 모든 인스턴스로 부터 삭제 되도록 처리 되었었다. 새로운 방법이 적용 됨에 따라, 많은 수의 프로세스는, reconfiguration 진행동안에도 처리하던 작업을 계속해서 진행할 수있게 되었는데, 이것은 lock/resource가 제거 되지 않았기 때문이다. Example Reference Documents Note:139435.1 - Fast Reconfiguration in 9i Real Application Clusters Note 114566.1 - OPS - Reconfiguration and Instance Startup in OPS Note 139436.1 - Understanding 9i Real Application Clusters Cache Fusion Note 144152.1 - Understanding 9i Real Application Clusters Cache Fusion Recovery

출처 : https://forums.oracle.com/forums/thread.jspa?threadID=477160