CRSD
다음은 crsd에 대해 알아보겠습니다.
CRSD는 cluster내에서 사용하는 resource를 monitoring하고 관리하는 역할을 합니다.
CRSD는 shell script인 racgwrap을 call하게 되고, 이 racgwrap은 racgmain을 call하여 특정
resource를 start/stop/check할 수 있습니다.
이 resource들을 관리하기 위해 해당 resource의 정보를 담아야 하는 공간이 필요하며, 이것이 ocr입니다.
CRSD는 이 OCR내의 정보를 직접 read/write하여 data를 유지 관리하는 역할을 합니다.
Read/write시 disk io를 최소화하기위해 OCR data를 memory에 caching하는 기능도 제공합니다.
CRSD는 root user로 기동하고, process fail이 발생하면 자동적으로 재기동 됩니다.
CRS Resources
Oracle entity는 database, instance, service나 listener등이 있습니다.
이런 oracle entity의 생성은 dbca, netca, srvctl등의 oracle tool들에 의해 생성하도록 요청되고,
CRSD가 실질적으로 OCR을 update하여 생성하게 됩니다.
이런 crs resource들간에는 dependency를 가질 수 있습니다.
예를 들어 database instance나 listener는 vip가 있어야만 생성될 수 있고, start될 수 있습니다.
이 경우 dependency가 성립됩니다.
Oracle crs가 crs resource를 관리하기위해 내부적으로 관리하는 명령어들은 다음과 같습니다.
이 명령어들이 담당하는 역할은 하나의 resource의 lifecycle과 동일합니다.
Crs_profile은 resource의 각종 attribute를 정의합니다.
일단 attribute가 정의되면, crs_register에 의해 resource로서 추가되고, ocr에 쓰여지게 됩니다.
Crs_start는 resource를 start할때 사용됩니다.
Crs_stat는 해당 resource의 정보를 조회할때 사용합니다.
Crs_relocate는 해당 resource를 move할때 사용합니다.
Crs-stop은 resource를 stop하며, crs_unregister를 이용하여 resource를 삭제할 수 있습니다.
Resource를 관리한다는 것은 위의 7가지 상태를 말하며, 이 7개의 단계는 resource의 life cycle이 됩니다.
CRS application resources
일단 resource가 startup 되면 crsd 는 resource 마다 하나씩 thread 를 생성하여 이 resource를
check_interval을 주기로 정상작동 여부를 check하게 됩니다.
Resource가 비정상 종료되면(예를 들어 instance crash) resource의 state는 offline으로 변경되고,
restart_attemps에 해당되는 숫자만큼 restart를 자동적으로 시도하게 됩니다. 이 숫자를 넘어서게 되면
더 이상 restart를 시도하지 않습니다.
Crs resource의 현재 상태는 crs_stat을 통하여 알 수 있습니다.
이 명령 결과로 조회되는 state는 current상태를 표시하고, target은 crs가 유지해야 하는 resource의 상태입니다.
즉, target이 대부분 online으로 되어있으므로 crs는 해당 resource의 current state를 online으로 유지하려고 합니다.
CRS Action
Crsd가 resource를 관리하기위해 node간에 message를 주고받는 예를 한번 보겠습니다.
Node는 2개이고, instnace start상황이라고 가정을 하겠습니다.
1. Node1의 client에서 api를 통해‘crs_start oracle’요청이 들어옵니다.
2. local CRSD는 이 요청을 받고, 이를 처리하기위해 새로운 thread를 생성합니다.
요청이 타당한지 검증을 하고, 어느 node에서 이 명령이 수행되어야 하는지 판단합니다.
여기서는 node2에서 작동하는 경우를 예로 들겠습니다.
3. Request=start resource=oracle로 key/value형태로 message를 생성합니다.
4. Node2의 crsd와 통신할 수 있는 port를 확인합니다.
5. Node2의 port가 open되고, socket이 open됩니다. Node2의 crsd는 이 요청을 처리하기 위한 thread를 생성합니다.
6. 3번에서 생성한 message를 node2로 보냅니다.
7. Node2의 crsd는 message를 decode하고, 이 message가 타당한지 여부를 확인하기 위해 ocr을 확인합니다.
특히, timeout value인 script_timeout의 값을 확인합니다.
8. Node2는 script_timeout의 값을 node1에 보내서 응답을 이 시간동안 기다리도록 합니다.
9. Node1은 timer를 시작하여 이 script_timeout동안 응답이 오기를 기다립니다.
10. Node2는 resource를 start합니다.
11. Node2는 node1으로 action program이 수행되었음을 socker을 통해서 보냅니다.
12. Node2에서 socket을 close합니다.
13. Node1에서 resource의 status를 변경함으로써 모든 작업이 완료됩니다.
OCR (Oracle Cluster Registry)
OCR은 oracle cluster registry의 약자입니다. CRS에서 사용하는 data를 저장하는 repository 역할을 합니다.
Data의 구조는 window의 registry처럼 tree구조로 되어있고, keyvalue의 형태로 data가 저장되어있습니다.
이 OCR data는 DBCA, NetCA, SRVCTL등의 oracle tool과 CRS가 사용합니다.
Srvctl에서 resource를 생성하는 예를 보면, srvctl create database –d mydatabase –o myOracleHome 의 형태입니다.
이 명령으로 OCR에는 mydatabase라는 database가 추가됩니다.
그러나 실제로 database가 생성 되는 것은 아닙니다.
Database의 생성은‘create database’문장으로 생성을 해야 합니다.
Dbca를 이용하면 database를 실제로 생성한 후 OCR에 등록하는 역할까지 합니다.
OCR은 shared device에 생성되어야 하며, raw device나 cluster file system도 가능합니다.
OCR의 위치는 일반적으로 /var/opt/oracle/srvConfig.loc file에 지정되어있거나, 환경 변수인 SRV_CONFIG로 지정이 가능합니다.
OCR Cache Architecture
Srvctl등의 oracle tool이 OCR정보를 access해야되는 경우 local node의 crsd가 관리하는 local ocr cache를 읽습니다.
Ocr cache는 각 node의 crs에 의해 관리되지만 그중의 한 crs는 cluster master cache로서 역할을 합니다.
이 master cache만이 OCR disk에 disk io를 발생시키게 되고 read한 data를 다른 node의 ocr cache로 전파합니다.
Resouce start/add등 OCR disk에 write해야 되는 상황에도 master cache를 담당하는 crsd가 write를 하고,
이 사실을 다른 node의 crsd에 전파합니다.
OCR write가 발생하면, 기존에 cache되어있던 해당 data는 invalid상태로 변경되어 master ocr cache로부터 다시 전달 받아야 합니다.
OCR Record 구조
각 ocr record는 key, value, permission의 3개의 field를 갖습니다.
여기 예에서 보면, 제일 위의 Databases.reld.instance.reld1은 key입니다.
여기서는 database instance를 예를 들었습니다.
그 밑에 oratext항목에 나타나는 reld1은 key에 대한 value입니다.
여기서는 instance명인 reld1이 value입니다.
세번째 항목은 security입니다.
Unix에서 permission을 관리하는 방식처럼 user, group, other group의 세 부분으로 나뉘고,
username과 primary_group_name에 이 user의 user명과 그룹 명이 표시됩니다.
여기 예에서는 oraha user에 other group으로 표시되었지만, 일반적인 경우에 oracle user에 dba group이 표시됩니다.
Voting disk
Voting disk는 split brain상태에서 node의 상태를 판단하기위한 second heart beat의 역할을 합니다.
Nm은 이 상태에서 어느 sub cluster node를 evict할지 결정하기 위해 voting disk를 사용합니다.
Eviction이 결정되면 해당 node가 eviction되도록 eviction message를 voting disk에 적어줍니다.
Voting disk는 dd로 backup을 받아 disk failure시 복구할 수 있습니다.
10gR1에서는 multiple voting disk를 지원하지 않으므로 os level의 mirroring 기능을 이용해야 하지만,
10gR2에서 multiple voting disk기능을 지원합니다.
참고로 OCR backup은 $ORA_CRS_HOME/cdata/<cluster name>/ direcotry에 자동적으로 backup이 됩니다.
Backup은 매 4시간마다 1개, 매일 1개, 매주 1개의 갯수로 유지됩니다.
Oraconfig –showbackup 명령으로 가용한 backup을 알수 있으며,
oraconfig–restore filename 명령으로 restore할 수 있습니다. Restore시는 crs를 down후 restore해야 합니다.
자세한 절차는 metalink에서 note. 268937.1를 확인하시기바랍니다.