Oracle Real Application Clusters(RAC) 환경에서 모든 인스턴스와 서버는 프라이빗 네트워크의 고속 인터커넥트(private interconnect)를 통해 서로 통신합니다. 만약 RAC 내 인스턴스들이 이 프라이빗 인터커넥트를 통해 서로 핑(ping)을 주고받지 못하거나 연결에 실패하면, 물리적으로 정상 작동 중인 모든 서버(및 해당 서버에서 구동 중인 데이터베이스 인스턴스)는 스플릿 브레인(split-brain)이라 불리는 상태에 빠질 수 있습니다.
Oracle RAC 12c Release 2 이전 버전의 Oracle 클러스터에서는 네트워크 또는 디스크 문제로 스플릿 브레인이 발생했을 때, 노드 번호가 가장 낮은 노드가 클러스터에서 생존했습니다. 그러나 최신 Oracle RAC 12c Release 2에서는 스플릿 브레인으로 인해 하위 클러스터(sub-cluster)에 동일한 수의 노드가 생성되는 특수한 경우, 축출 대상 노드를 선정하는 알고리즘이 변경되었습니다.
이 글에서는 새로운 노드 가중치(node-weighting) 기능을 기반으로 한 Oracle RAC 12c Release 2의 노드 축출 알고리즘 변화를 살펴보겠습니다.
노드 가중치 알고리즘이란?
노드 가중치(Node Weighting)는 Oracle RAC 12c Release 2에서 새롭게 도입된 기능으로, 펜싱(fencing) 과정에서 클러스터가 호스팅하는 워크로드까지 고려합니다. 스플릿 브레인 상황이 발생하면 Oracle Clusterware는 특정 규칙에 따라 생존할 그룹을 선택하는데, 이 과정에서 중요한 자원(critical resources)을 실행 중인 노드가 축출될 수도 있습니다. 이 새로운 기능을 활용하면 특정 노드에 가중치를 부여하여 해당 노드가 클러스터에서 강제 종료되는 것을 방지할 수 있습니다.
새롭게 추가된 태그인 CSS_CRITICAL은 다양한 수준과 구성 요소에 설정하여 '핵심(critical)'으로 표시할 수 있으며, 장애 발생 시 클러스터가 이를 보존하도록 유도합니다. Oracle Clusterware가 스플릿 브레인 상황에서 어떤 노드를 축출할지 결정할 때, 다른 기술적인 이유로 해당 노드의 생존이 불가능하지 않다면(장애 시점에 최소 하나 이상의 핵심 구성 요소를 보유한 경우) CSS_CRITICAL 태그가 우선 반영됩니다. 이 개념을 통해 그 외 조건이 동일하다면 대부분의 업무가 영향을 받지 않도록 보장할 수 있습니다.
노드 가중치 알고리즘의 주요 작업
노드 가중치 알고리즘은 다음과 같은 작업을 수행합니다:
- 데이터베이스 인스턴스 또는 서비스에 가중치 부여: 데이터베이스 인스턴스나 서비스를 추가할 때 srvctl add database 또는 srvctl add service 명령어에
-css_critical yes옵션을 지정할 수 있습니다. 또한 srvctl modify database 및 srvctl modify service 명령어로 파라미터를 설정하거나 변경할 수도 있습니다. - ora.*가 아닌 리소스에 가중치 부여: 리소스를 추가하거나 수정할 때 crsctl add resource 및 crsctl modify resource 명령어에
-attr CSS_CRITICAL=yes파라미터를 사용합니다. - 서버에 가중치 부여: crsctl set server 명령어에
-css_critical yes파라미터를 설정합니다.
다음은 데이터베이스 인스턴스 또는 서비스에 가중치를 부여하는 예시입니다:
$srvctl modify database –d <dbname> css_critical yes
$srvctl modify service –db <dbname> -service <service_name> css_critical yes
만약 리소스에 가중치가 부여되지 않았다면, 알고리즘은 아래 사항들을 검토합니다:
- 어떤 노드에 가장 많은 수의 서비스가 생성되어 있는가?
- 인스턴스용 싱글톤(singleton) 서비스가 생성되어 있는가?
- 해당 노드가 Flex ASM 인스턴스로 구성되어 있는가?
- 공용 네트워크(public network) 장애가 발생했는가?
- 노드 유형은 무엇인가 — 허브(hub)인가 리프(leaf)인가?
테스트 케이스
아래 코드 예제는 두 노드로 구성된 클러스터에서 bond2를 프라이빗 인터커넥트로 사용하는 사례를 살펴봅니다.
$oifcfg getif
bond0 147.167.80.0 global public
bond2 10.168.33.32 global cluster_interconnect
$olsnodes -s -n
node1 1 Active
node2 2 Active
$
$crsctl set server css_critical yes
$crsctl get server css_critical
CRS-5092: Current value of the server attribute CSS_CRITICAL is yes.
$
이제 bond2를 중단하여 node1과 node2 간의 통신 장애를 시뮬레이션해 보겠습니다:
#ifdown bond2
$olsnodes -s -n
node1 1 Active
node2 2 Inactive
OCSSD.trc 로그 출력 결과는 다음과 같습니다:
2018-01-09 11:01:21.220 : CSSD:1825834752: clssnmrCheckNodeWeight: node(1) has weight stamp(393228187) pebbles (0) goldstars (0) flags (3) SpoolVersion (0)
2018-01-09 11:01:21.220 : CSSD:1825834752: clssnmrCheckNodeWeight: node(2) has weight stamp(0) pebbles (0) goldstars (0) flags (0) SpoolVersion (0)
2018-01-09 11:01:21.727 : CSSD:1825834752: clssnmrCheckNodeWeight: node(1) has weight stamp(393228187) pebbles (0) goldstars (0) flags (3) SpoolVersion (0)
2018-01-09 11:01:21.727 : CSSD:1825834752: clssnmrCheckNodeWeight: node(2) has weight stamp(0) pebbles (0) goldstars (0) flags (0) SpoolVersion (0)
2018-01-09 11:01:21.727 : CSSD:1825834752: clssnmrCheckNodeWeight: Server pool version not consistent
2018-01-09 11:01:21.727 : CSSD:1825834752: clssnmrCheckNodeWeight: stamp(393228187), completed(1/2)
결론
RAC 12c Release 2부터 새로운 알고리즘은 스플릿 브레인 상황에서 축출 또는 유지할 노드를 다음과 같이 결정합니다:
- 하위 클러스터의 크기가 서로 다른 경우: 이전 릴리스와 동일하게 동작합니다.
- 모든 하위 클러스터의 크기가 동일한 경우: 다음과 같이 기능이 변경되었습니다.
- 하위 클러스터의 노드 가중치가 동일하면, 노드 번호가 가장 낮은 하위 클러스터가 생존합니다. 따라서 2노드 클러스터에서는 노드 번호가 낮은 노드가 생존합니다.
- 하위 클러스터의 노드 가중치가 다르면, 더 높은 가중치를 가진 하위 클러스터가 생존합니다. 따라서 2노드 클러스터에서는 가중치가 낮아 노드 번호가 낮은 노드가 축출될 수 있습니다.
서버 가중치 기반 노드 축출 방식을 사용하면, 스플릿 브레인 발생 시 어떤 클러스터 노드를 종료하거나 축출할지 직접 선택함으로써 Oracle Clusterware의 장애 복구 메커니즘을 더욱 세밀하게 제어할 수 있습니다. 이 주제에 대해 궁금한 점이 있거나 추가 안내가 필요하시면 아래 댓글로 의견을 남겨 주세요.