728x90
반응형
OCSS (Oracle Cluster Synchronization Service)
소개
Clusterware의 OSSD 프로세스는 CSS 서비스를 제공한다.
여러 Hearbeat 매커니즘을 통해 실시간으로 클러스터 상태 모니터링
역할
- 클러스터 기본 서비스 (클러스터 그룹 서비스, 클러스터 locking)
- 여러 Hearbeat 매커니즘을 통해 실시간으로 클러스터 상태 모니터링
- 프로세스 상태, 특히 DB 인스턴스 상태를 모니터링 함
Background Processes
- ocssd.bin (CSSD)
스레드 하나는 Network Hearbeat를 모니터링, 하나는 Disk Hearbeat를 모니터링 함.
다중 스레드 프로세스, 높은 우선순위로 실행됨.
CPU 사용률이 100%일 때 다른 프로세스도 선점해버린다.
시작 순서 : INIT → init.ohasd → ohasd → ohasd.bin → cssdagent → ocssd → ocssd.bin - cssdmonitor (CSSD Monitor)
CSSD 모니터링의 중복성 제공
다중 스레드 프로세스, 루트 사용자로 높은 우선 순위로 실행
시작 순서 : INIT → init.ohasd → ohasd → ohasd.bin → cssdmonitor - cssdagent (CSSD Agent)
ocssd.bin 생성 담당, 노드 모니터링 및 Hang에 대한 CSSD 프로세스
다중 스레드 프로세스, 루트 사용자로 높은 우선 순위로 실행
시작 순서 : INIT → init.ohasd → ohasd → ohasd.bin → cssdagent
Heartbeat 매커니즘 소개
10g R2 (10.2.0.X) 이후로 Cluster를 구성하는 Node의 상태를 체크하기 위해 2가지 방법을 순차적으로 사용한다.
비정상 상태로 판단되면 Split-Brain 현상 방지하기 위해 서버를 Reboot 시킨다.
- Network Hearbeat (NHB)
inter-connect 네트워크를 통한 Heartbeat (CSS Misscount)
inter-connect 네트워크에 문제가 생기면 정의된 Misscount 동안 Network 복구되기를 기다린다.
이때 DB 관련 Service 는 Hang-Up 발생.
misscount 동안 Network 복구 되지 않으면 양 Node간 Data 정합성을 위한 Split-Brain 현상 방지하기 위해
비정상 노드를 Evict(추방) → I/O Fencing → System Rebooting
Oracle 10g R1 : 최대 600s (10m)
Oracle 10g R2 : 최대 120s (2m)
운영체제 별 Default 값
OS Oracle10g(R1 & R2) Oracle11g Linux 60s 30s Unix 30s 30s VMS 30s 30s Windos 30s 30s - Local Hearbeat (LHB)
CSSD 와 두 모니터 (cssdagent, cssdmonitor) 사이에 1초마다 ocssd.bin의 전송 스레드는 NHB, LHB를 동시에 전송한다.
두 모니터 (cssdagent, cssdmonitor) 가 css misscount-3초 = 27초 동안 LHB를 받지못하면 모니터 데몬이 노드 Rebooting 시킴. - Disk를 통한 Hearbeat (Voting Disk Check)
Voting Disk 에 노드별로 I/O를 성공하면 살아있다고 Marking 한다. 실패하면 Offline으로 표기
이 시간동안 Voting Disk에 I/O를 실패한 노드를 Reboot 시킨다.
Oracle 10g R2 부터 여러 개 즉, n개 (최대 31개)의 Voting Disk 를 가질 수 있다.
→ 어디서는 최대 15개라는데 버전별로 차이 있는듯 함. (최소 3~5개 권장)
Voting Disk 는 홀수 개 존재하며, 과반 수 이상 I/O 성공해야 성공으로 인정
1) short disktimout (SDTO) : 긴급상황
Network hearbeat 실패 시 디스크 검사는 짧게만 수행한다.
(Default) css misscount - reboottime = 30초-3초 = 27초
2) Long disktimeout (LDTO)
Network hearbeat 성공 시 디스크 검사를 길게 수행한다.
(Default) 200초 - reboottime
CSS 데몬이 추방(제거)된 후에 노드 Reboot이 완료되기까지 걸리는 시간
(Default) 3초
Eviction 을 위한 조건
1차 : Network Ping | 2차 : Disk Ping | Reboot 여부 |
misccount 이내 성공 (30s) | misccount 이내 성공 (30s) | N |
misccount 이내 성공 (30s) | misccount 이내 실패 (30s) Long disktimeout (LDTO) 이내 성공 (200s) |
N |
misccount 이내 성공 (30s) | Long disktimeout (LDTO) 이내 성공 (200s) | Y |
misccount 이내 실패 (30s) | misccount 이내 실패 (30s) → 이건 short disktimout (SDTO) 를 의미하는 것인가? 찾아봤지만 확인이 어려움.. |
Y |
용어 정리
- Split-Brain
클러스터 노드들이 private interconnect 를 통해 상호 연결 실패했을 경우 발생
개별 노드가 잘 동작하는 상태에서, 각각 유저 커넥션을 받아들이고 독립적으로 작업을 하는 것이다.
(뇌가 두개가 되어버린 상태) 이렇게 되면 데이터 무결성에 대한 문제가 생긴다. - Cluster Interconnect
클러스터의 노드만 액세스 가능한 스위치이다.
인스턴스 간 통신을 위해 Cache Fusion 사용함.
Clusterware는 1-4 개의 HAIP 주소를 생성함.
로드 밸런싱 - Node Eviction
클러스터 일관성 유지하기 위해
Critical Issue가 생겼거나 정의된 시간 내 응답 없는 노드를 강제로 내보내는 것이다. - I/O Fencing / Node Fencing
노드에서 클러스터 기능이 실패했지만, OS Level에서는 여전히 실행중인 것.
복구 프로세스가 시작된 후 실패한 DB 인스턴스에서 남아있는 Write 작업이 스토리지에 도달함.
이러한 Write 작업은 더 이상 올바른 serial order 이 아니므로, 데이터 일관성 손상시킬 수 있음.
따라서 클러스터 노드가 실패하면 실패한 노드는 모든 공유 디스크 장치/디스크 그룹에서 차단됨.
반응형
'인프라 > Database' 카테고리의 다른 글
인프라 지식 - Database HA Cluster, RAC (0) | 2021.05.31 |
---|