ODA 기본구성 및 EEHA 이중화에서의 VIP, ScanIP 동작방식
해당 블로그는 개인의 공부를 목적으로 별도 정리하여 작성된 내용이므로, 잘못된 내용을 포함할 수 있습니다.
혹시나 틀린 내용이 있을 경우, 댓글로 말씀해주시면 계속하여 수정하겠습니다. 감사합니다.
현재까지는 하나의 서버에 DB를 구성할 때 OS, 스토리지, DB 등을 모두 개별로 설치 및 구성했어야 했다. 하지만 최근 오라클 사에서는 이 모든 것을 하나로 통합하여, 최종적으로 DB시스템을 빠르고 쉽게 구축하고 패치할 수 있는 ODA를 권장하고있다.
내가 지금껏 이해한 내용을 바탕으로 ODA에 대해 정리해보려한다.
ODA 개요 및 장단점
우선 ODA를 한마디로 표현하면 하나의 시스템에 모든 것을 때려박아둔 통합형 어플라이언스이다. ODA의 가장 큰 장점은 쉽고 빠르게 구축할 수 있다는 것이다. ODA기기에 데이터베이스 시스템을 구축하는 과정에서 선택 가능한 다양한 옵션들이 존재한다. 하지만 현재 내가 구성 및 구축을 담당하고있는 업무를 예시로 들면 OS(Oracle Linux), DB(Oracle 19C), Storage(통합형 공유 스토리지), 네트워크(VIP와 SCAN IP, 각종 리스너 설정) 등 필요한 모든 구성요소 및 선택사항들을 원클릭으로 몇 분 안에 구성할 수 있었고, 패치 적용 또한 빠르게 가능했었다.
우리 회사에서는 차세대 프로젝트의 일환으로 ODA 기기가 들어오게 되었는데, 실제로 도입하여 여러가지 테스트를 하다보니 다양한 복잡한 상황이 발생했다.
예를 들어, 여러 인스턴스가 하나의 서버에 올라가는 상황에 IP 및 리스너는 어떻게 구성할 것인가?
또는 인스턴스를 추가할 때 같이 올라가있는 인스턴스에는 어떤 영향이 있는가? 서비스 중단이 일어나는가?
포트를 구분하여 서비스(인스턴스)를 나누고싶다면, 이때 구성은 어떻게 해야하는가..
이때마다 ODA 기기는 다양한 선택 옵션과 기능들을 제공함으로써 유연하게 문제상황을 해결할 수 있게 했다. 또한 COD(Capacity on Demand) 정책으로 필요한 만큼만 라이센스를 구매하게했다.
ODA 실제 구성 (HA, EEHA 구조)
현재 우리 회사에서 ODA 기기는 HA구조로 구성되어있다. 오라클 코리아 쪽에서는 EEHA라고 표현하던데, 자세한 히스토리는 모르겠다.
HA(High Availability)
2개의 서버(노드)를 이용하여 하나는 Active, 나머지 하나는 Standby 상태로 정해둔다. 평상시에는 Active 상태인 노드가 모든 트랜잭션을 도맡아 수행하지만, 장애가 발생하여 Active 상태였던 1번 노드에 문제가 생기게 되면, 2번 노드로 절체되어 2번 노드가 Active 상태가 되고 모든 트랜잭션을 도맡아 수행하게 된다.
RAC 구조와의 차이점은 평소에 2번 노드가 살아있는가? 이다. RAC는 1번과 2번 노드 모두 Active 상태로 서비스를 할 수 있는 상태이며, 각각에서 트랜잭션이 로드밸런싱 되어 동작할 수도 있다. 하지만 HA 구조에서 Standby 서버는 DB가 내려가있는 상황과 같이 서비스를 할 수 없는 상태이다. DB가 내려가있는 상황 뿐만 아니라, 구성 방식에 따라서는 리스너가 떠있지 않아서 서비스를 받아줄 수가 없는 상황 등이 있을 수 있다.
현재 구성(ODA에서의 EEHA)에 대해 하나씩 알아보자.
노드 1번과 2번은 공유 스토리지가 연동되어있다.
현재 구성에서는 노드 1번과 2번이 통합 스토리지를 공유하여 데이터에 접근함으로써, 데이터 복제나 동기화에 대한 부담을 줄인다. 이때 정기적인 백업 및 복구작업은 오라클에서 제공하는 RMAN(Recovery Manager)를 이용한다.
RMAN(Recovery Manager)
오라클 데이터베이스의 백업, 복구 및 복제 작업을 관리하기 위한 도구이다. 주요기능으로는 전체백업(Full Backup) - 데이터베이스의 모든 데이터를 백업, 아카이브 로그 백업(Archived Log Backup) - 아카이브 로그 백업, 완전 복구(Complete Recovery) - 마지막 백업 시점까지 복구, 불완전 복구(Incomplete Recovery) - 특정 시점 또는 특정 트랜잭션까지 복구, 데이터베이스 복제(Database Duplication) - 원본 데이터베이스의 복사본을 생성 / 테스트 환경이나 데이터베이스 마이그레이션에 유용
RMAN 클라이언트(명령 인터페이스)를 활용하여 실행한다.
- 활용법 참고 : https://lusida-coding.tistory.com/168
IP는 크게 Public IP - Real(Physical) IP, Virtual IP / Private IP / Virtual IP / Scan IP 로 구성된다.
Public IP (Service IP - Real IP / Virtual IP)
Public IP는 외부와 통신하기 위한 IP이다. 클라이언트에서 데이터베이스 서버에 직접 접속할 때 사용하며(DBA, 관리자), 각 노드(1번 노드, 2번 노드)는 고유한 Public IP(rip / vip)를 가진다. 나는 실무에서 PIP - Physical IP 라는 표현을 많이 쓰는데, 공부하려고 내용을 막 찾아보니 RIP - Real IP 라는 표현을 많이 쓰더라...
- RIP(Real IP, Physical IP) : 192.168.1.161 (1번 노드) , 192.168.1.162 (2번 노드)
RIP(PIP)는 네트워크 카드(랜 카드)에 1대1 매칭되는 IP라고 이해하면 된다. 1번 노드에 대한 고정 IP이다(2번 노드로 절체 불가능) -> 1번 노드의 RIP로 물려있는 서비스가 있는데, 이 RIP가 죽는다? => 사용자는 현재 설정되어있는 TCP TimeOut 값 동안 기다려야만 응답을 받을 수 있음
- VIP(Virtual IP) : 192.168.1.163 (1번 노드) , 192.168.1.164 (2번 노드)
VIP는 가상으로 만든 고가용성을 위한 IP이다. 요청에 대한 응답속도를 빠르게 하기 위함이다 - 1번 노드 장애 시, 2번 노드로 자동 FailOver(절체),서비스를 구성할 때 1번 노드의 RIP가 아닌 VIP를 물고 있게 해놓으면(config), 1번 노드가 죽는 경우(장애 상황)에도 알아서 2번 노드로 가서 붙는다 => 빠른 응답을 받을 수 있다 (TCP Timeout 시간 동안 기다리지 않아도 되니까, 빠른 FailOver - sqlplus로 접속을 시도하는 경우를 가정하면 no listener 라고 응답이 바로 떨어짐)
클라이언트가 평소에 1번 노드 RIP가 아닌 VIP로 서비스를 하고 있었던 경우를 가정해보자.
만약, 1번 노드에 장애가 발생했다 (예를 들어, 1번 노드의 디비가 다운되는 경우) 그럼 RIP가 아닌 VIP로 설정을 해둠으로써,
클라이언트에서 빠르게(VIP가 1번노드에서 2번노드로 절체되는 시간만큼 소요) 에러 응답을 받을 수 있고(1번 노드 VIP : "현재 1번 노드가 죽어서, 나 지금 2번 노드에 와서 떠있어") - 만약 RIP로 해놨다면 TCP Timeout 만큼 기다려야 응답을 받을 수 있음
WAS 쪽 또는 클라이언트에서 서비스를 실행하는 주체에서 TAF 또는 CTF 와 같은 이중화 설정(커넥션 풀 설정) 해두었다면, 에러 응답을 받자마자 곧바로 1번 노드가 아닌 2번 노드로 서비스를 절체할 것이다(=> TAF와 CTF 등에 대해서는 따로 포스팅)
Private IP (Interconnect = heartbeat network)
- 192.168.56.161 (1번 노드) , 192.168.56.162 (2번 노드)
클러스터 노드 간의 통신을 담당한다. 각 노드가 서로 데이터를 공유 및 동기화하고, 노드 간의 상태정보 교환(HeartBeat - 각 노드가 현재 살아있는가), 클러스터 리소스를 할당 및 관리하는데 사용된다. 다른 네트워크 트래픽과 분리하여 충돌을 방지한다(외부 네트워크와 분리된 전용 네트워크), Oracle CRS(Cluster Ready Service)가 각 노드(인스턴스)를 관리할 때 사용하는 IP라고 이해하면 된다.
Scan IP
- 192.168.1.165 (1번 노드와 2번 노드가 동시에 사용한다는 개념), 클러스터에 대한 단일 진입점을 제공한다. 클러스터 노드 간의 로드 밸런싱과 페일오버를 자동으로 처리한다. 여러 노드에서 하나의 IP로 동시에 접근하기 위한 용도라고 이해하면 된다. 실무에 적용할 때는 ScanIP와 VIP가 굉장히 헷갈리는데, 다시 한번 내용정리를 해본다.
VIP 와 ScanIP 동작 방식의 차이점
2 node 구성에서, 1번 노드에 문제가 생겼을 경우, WAS(AP, 애플리케이션)에서의 이중화를 위한 목적이라면, VIP와 SCAN IP 모두 예상한 시나리오대로 잘 동작할 것이다. 하지만 동작방식에서 차이가 있다.
클라이언트에서 Scan IP 및 Scan Listener를 사용하기로 정해졌고, 접속을 시도한다고 가정해보자. 가장 먼저 Scan Listener는 클러스터 내의 어떤 노드에 서비스가 존재하는지 조회한다(또는 현재 어떤 노드가 서비스되고있는가?) 이때, 이 모든 정보는 오라클 클러스터웨어에 의해 관리된다. 가장 중요한 것은 클라이언트의 접속 요청을 처리하는 과정에서 이 세션이 ScanIP로 물리는 것이 아니라, 현재 서비스가 실행되고 있는 노드의 VIP로 물리는 것이다. 가장 처음 접속할 때(세션이 성립될 때) 클라이언트의 접속 요청은 ScanIP(Scan Listener)를 타고 들어와서 세션을 맺고, 곧바로 해당 서비스가 떠있는 노드의 VIP로 리다이렉트된다.
예를 들어, 사용자가 ScanIP를 쓴다고 정의하고 실제로 AP에서 ScanIP로 접속을 시도하더라도, 가장 처음 세션이 물릴 때만 ScanIP로 가고, 그 다음부터는 VIP로 네트워크 세션이 열려있는것이다. 이때, 만약 1번 노드에서 장애가 난다면(서비스를 할 수 없게 된다면), 오라클 클러스터웨어는 2번 노드에서 서비스를 실행할 것이고(절체, Failover) Scan Listener는 이를 감지하고 알아서 2번 VIP로 리다이렉트 시킬 것이다.
결국 ScanIP와 VIP의 차이점은 장애상황에서 드러난다. VIP는 실제로 2번 노드로 자기가 넘어가서 자신의 IP 및 리스너로 서비스를 이어가지만, ScanIP 및 Scan Listener는 항상 떠있으면서(현재 서비스가 되고있는 노드에 떠있음, 포지션이 굉장히 애매함) 새롭게 연결되는 신규 세션들을 포워딩? 중계해주는 Proxy 정도의 역할을 하는 것이다(이미 열려있는, 서비스되고있는 세션은 VIP로 계속 통신한다)
정확하진 않지만 이러한 ScanIP 및 Scan Listener의 동작방식에 대해서는 네트워크 패킷을 까보면서 알게되었다. 네트워크 패킷이 오고가는 과정을 실제로 까본 결과, 처음 신규로 세션이 열릴 때는 ScanIP 및 ScanListener로 네트워크가 열렸지만, 곧바로 현재 서비스가 되고있는 노드의 VIP로 다시 리다이렉트 되는 것을 확인할 수 있었다. 또한, 비슷한 개념으로 Scan Listener에 어떠한 Config 변경이 있더라도, 현재 물려있는 세션이 끊어진다던가 하는 영향은 없었다.
장애가 나는 시점을 가정한다면?
(디비가 장애라면 디비까지 같이 넘어간다. 아래의 예시는 네트워크(IP)의 장애상황을 예시로 든 것이다)
1번 노드에서 네트워크 장애가 발생한다면, 1번 노드의 VIP / Scan IP / Scan Listener가 2번 노드로 넘어간다(절체, Failover) 하지만 이때 중요한 점은, 1번 노드의 VIP에 대한 리스너는 1번 노드에 그대로 남아있기 때문에, 1번 노드의 VIP가 2번노드로 넘어와서 뜨더라도, 1번 노드의 VIP로는 서비스할 수 없는 것이다.
이때의 접속 과정은,
1) 가장 처음 신규 세션이 물릴 때, 기존과 같이 Scan Listener를(2번 노드에 떠있는) 타고 들어온다.
2) inter connect (heartbeat network 라고 표현하기도 함) 라인을 통해 1번 노드의 리스너를 연결한다.
3) 1번 노드에서 서비스되고있는 디비 인스턴스로 접속한다.
Oracle Clusterware (= CRS, Cluster Ready Service)
실무에서는 CRS라는 표현을 많이 쓴다. CRS는 오라클 클러스터웨어의 초기 이름 중 하나이다. Oracle 10g에서 처음 이 개념(상호 연결된 하나 이상의 컴퓨터, 노드들이 그룹을 이루어 작업을 함께 처리하는 방식)이 도입되었을 때 CRS로 불리기 시작했다고 한다 - 결국은 같은 의미임
주요 기능은 아래와 같다.
1) 클러스터 관리 : 클러스터 노드 간의 통신과 조정
- 만약 1번 노드에서 장애가 발생했다면, CRS가 이를 인지하고, 2번 노드로 절체하여 서비스를 지속할 수 있도록 한다.
2) 자원 관리 : 데이터베이스 인스턴스, 리스너 등 클러스터 내의 모든 리소스 관리
- 만약 1번 노드의 리스너가 비정상적이라면 CRS가 이를 감지하고, 재기동하거나 또는 2번 노드의 리스너를 활성화 시키는 등의 작업을 통해 클라이언트 연결을 유지한다.
3) 장애 감지 및 복구 : 장애를 감지하고 복구하는 기능
- 클러스터 내의 특정 디스크에서 장애가 발생한 경우, CRS는 이를 감지하고, 자동으로 장애가 발생한 디스크의 데이터를 복구하거나, 다른 디스크로 데이터를 이동시켜 데이터 손실을 방지한다.
4) 서비스 제공 : 로드 밸런싱 및 서비스 재기동 등의 기능
- RAC 환경에서 2개의 노드 모두 Active인 상황이고 Scan Listener를 사용한다는 가정에서, CRS는 요청받은 각각의 쿼리의 실행 부하를 모니터링 하여, 한 노드가 과부하되지 않도록, 다른 노드로 트랜잭션을 로드밸런싱 해준다. 이를 통해 전체 클러스터의 성능을 최적화한다.
- CRS 관련 작업 절차 및 명령어
https://u-comensee.tistory.com/87
https://m.blog.naver.com/kang_sok/221425422450
https://semode.tistory.com/201