Oracle 19c RAC IP 변경 방법 정리

Oracle 19c RAC IP 변경 방법(상세)

RAC IP 변경은 “OS 네트워크 반영 → 클러스터 네트워크 정의(oifcfg) → VIP/SCAN 리소스(srvctl) → 리스너/서비스 확인” 순서를 지키는 게 핵심입니다. 실제 사용 시에는 변경 범위(Public/VIP/SCAN/Interconnect)를 명확히 나누고, 각 단계마다 롤백 포인트를 남겨야 장애 확산을 막을 수 있습니다.

개요

Oracle 19c RAC 환경에서 “IP 변경”이라고 하면 보통 아래 중 하나(또는 복합)를 의미합니다. 운영 환경에서는 범위를 섞어서 진행하면 리소스가 엉키기 쉬우니, 먼저 무엇을 바꾸는지 확정한 뒤 절차를 진행합니다.

구분	무엇이 바뀌나	영향 범위	주요 변경 지점
Public IP	각 노드의 기본 통신 IP	노드 접속/일부 클러스터 통신	OS NIC, DNS/hosts, oifcfg(선택), 노드 host 해석
VIP	노드별 가상 IP(빠른 failover)	클라이언트 접속(접속 빠른 전환)	srvctl( vip/ listener ), DNS/hosts
SCAN	클라이언트 접속 대표 이름/주소(보통 3개 IP)	접속 경로 전체	DNS(권장), srvctl scan/scan_listener
Interconnect(Private)	노드 간 내부 통신(캐시퓨전/하트비트 등)	클러스터 안정성/성능	OS NIC, oifcfg, 클러스터 통신 점검

전제(강력 권장) 본 절차는 계획된 점검 창(downtime 또는 제한 서비스)을 전제로 합니다.
Public/VIP/SCAN/IP 변경은 “이름 해석(DNS/hosts) 불일치”가 가장 흔한 실패 원인입니다.
관리자 입장에서 보면, 변경 전/후의 해석 결과를 노드별로 기록해 두는 것이 가장 값진 보험입니다.

환경

아래 항목을 변경 전 체크리스트로 고정해 두면 RAC IP 변경 작업의 재현성이 좋아집니다.

1) 변경 범위/대상 정리

• 변경 대상: Public / VIP / SCAN / Interconnect 중 무엇인지 구분
• 변경 방식: 동일 서브넷 내 IP 변경인지, 서브넷 자체가 바뀌는지(라우팅/게이트웨이 포함)
• 이름 정책: 노드명/호스트명/VIP명/SCAN명은 그대로 두고 IP만 바꾸는지, 이름도 바꾸는지
• DNS 사용 여부: SCAN은 DNS 기반을 권장(가능하면 hosts 고정 회피)

2) 변경 전 백업(최소)

• Grid/DB home의 네트워크 관련 설정 파일(배포/표준 절차에 따름)
• 현재 클러스터 리소스 상태 덤프(아래 명령 출력 저장)

# Grid 사용자(예: grid)로
crsctl stat res -t
srvctl config vip -n <node1>
srvctl config vip -n <node2>
srvctl config scan
srvctl config scan_listener
srvctl config listener
oifcfg getif
olsnodes -n -i

3) 변경값 매핑표(작업 표준)

변경 작업 중 실수의 대부분이 “어느 IP를 어느 리소스에 넣어야 하는지”에서 발생합니다. 아래처럼 표로 고정해두면 안전합니다.

항목	변경 전	변경 후	비고
node1 Public	x.x.x.x	y.y.y.y	OS NIC / name 해석
node1 VIP	x.x.x.x	y.y.y.y	srvctl vip
SCAN1~3	x.x.x.x	y.y.y.y	DNS A 레코드 3개 권장
Interconnect	10.x.x.x	10.y.y.y	oifcfg, MTU, 라우팅

증상

Oracle 19c RAC IP 변경 작업에서 자주 만나는 증상(실패 패턴)입니다.

• VIP/SCAN 리소스가 OFFLINE 또는 INTERMEDIATE 상태로 남음
• 리스너는 떠 있는데 원격 접속이 안 되거나, 특정 노드로만 접속됨
• 노드 간 통신 지연/재부팅/eviction(특히 Interconnect 변경 시)
• 이름 해석이 노드마다 달라서 어떤 노드는 old IP로, 어떤 노드는 new IP로 해석

핵심 포인트 RAC IP 변경이 실패할 때 “srvctl 명령 자체”보다 “DNS/hosts 불일치”가 원인인 경우가 더 많습니다.
따라서 증상 단계에서 바로 리소스를 재기동하기보다, 먼저 각 노드의 이름 해석부터 동일하게 맞추는 것이 빠릅니다.

1차 점검

1) 노드별 이름 해석 동일성 확인

각 노드에서 동일한 결과가 나오는지 확인합니다(노드별로 모두 실행).

# root 또는 일반 사용자
getent hosts <node1-hostname>
getent hosts <node2-hostname>
getent hosts <node1-vip-name>
getent hosts <node2-vip-name>
getent hosts <scan-name>

# DNS 사용 환경이면 추가(툴 존재 시)
nslookup <scan-name>

2) NIC/라우팅/ARP 기본 점검

ip addr
ip route
arp -n

3) 클러스터 네트워크 인터페이스 정의 확인(oifcfg)

# Grid 사용자
oifcfg getif

서브넷이 바뀌는 IP 변경이라면 여기에서 “public/cluster_interconnect” 매핑이 깨졌는지 먼저 확인합니다.

4) 리소스 상태 빠른 확인

crsctl stat res -t

작업 전 최소 체크 변경 전에는 반드시 VIP/SCAN/리스너가 ONLINE인지 확인하고 시작하세요.
이미 불안정한 상태에서 Oracle 19c RAC IP 변경을 하면, 변경 성공/실패 판단이 더 어려워집니다.

심화 분석

1) 변경 대상별 핵심 리소스 관계

• Public IP: 노드 기본 통신 → OS 네트워크/hostname 해석이 우선
• VIP: node별 VIP 리소스 → VIP가 떠야 노드 리스너가 정상 동작하기 쉬움
• SCAN: scan 리소스 + scan_listener → 클라이언트 접속의 대표 진입점
• Interconnect: cluster_interconnect → 지연/패킷 손실이 eviction으로 번질 수 있음

2) 로그/상태에서 확인할 것(요약)

• VIP/SCAN 리소스가 어느 단계에서 실패하는지(이름 해석/바인딩/포트 등)
• 노드별로 동일한 NIC에 동일한 서브넷이 잡히는지
• oifcfg에 등록된 인터페이스가 실제 OS 인터페이스와 일치하는지

여기서는 “어떤 리소스가 왜 안 올라오는지”를 과하게 파고들기보다, IP 변경 작업에서는 이름 해석 + 인터페이스 매핑을 먼저 정리하는 편이 성공률이 높습니다.

복구

진행 순서(권장) 1) DNS/hosts 선반영(가능하면 TTL 고려) → 2) OS IP/NIC 반영 → 3) oifcfg 정리(필요 시) → 4) VIP/SCAN srvctl 변경 → 5) 리스너/서비스 확인
RAC IP 변경 작업은 “선행조건이 갖춰진 상태에서 srvctl을 실행”해야 재시도가 줄어듭니다.

A. SCAN IP 변경(권장: DNS 기반)

SCAN은 가능한 한 DNS에서 관리하는 것이 안정적입니다. SCAN 이름은 유지하고 A 레코드(IP 3개)를 변경하는 방식이 일반적입니다.

• DNS에서 <scan-name>의 A 레코드(보통 3개)를 변경
• TTL이 남아있으면 클라이언트/노드별 캐시가 달라질 수 있으니 점검 창 전에 TTL을 줄이는 운영이 흔합니다
• 변경 후, 각 노드에서 getent hosts <scan-name> 결과가 새 IP로 일치하는지 확인

DNS 변경만으로 끝나는 경우도 있지만, 클러스터 리소스 재기동이 필요한 경우 아래를 순서대로 진행합니다.

# Grid 사용자
srvctl stop scan_listener
srvctl stop scan

# DNS 반영 확인 후
srvctl start scan
srvctl start scan_listener

srvctl status scan
srvctl status scan_listener

B. VIP IP 변경(노드별)

VIP는 노드별로 1개씩 존재합니다. VIP 이름은 유지하고 IP만 바꾸는 방식이 일반적이며, DNS/hosts에 VIP 이름이 새 IP로 해석되어야 합니다.

1) 선행: VIP 이름 해석 반영

# 각 노드에서 동일 결과 확인
getent hosts <node1-vip-name>
getent hosts <node2-vip-name>

2) srvctl로 VIP 수정(노드별 실행)

# Grid 사용자
srvctl stop vip -n <node1>
srvctl modify vip -n <node1> -A <new_vip_ip>/<prefix>
srvctl start vip -n <node1>
srvctl status vip -n <node1>

srvctl stop vip -n <node2>
srvctl modify vip -n <node2> -A <new_vip_ip>/<prefix>
srvctl start vip -n <node2>
srvctl status vip -n <node2>

VIP 변경 직후에는 리스너도 연쇄 영향을 받을 수 있으니, VIP가 ONLINE인 것을 먼저 확인하고 리스너 상태를 확인합니다.

# Grid 사용자
srvctl status listener
srvctl stop listener
srvctl start listener
srvctl status listener

C. Public IP 변경(노드 기본 IP)

Public IP 변경은 OS 네트워크 변경이 핵심입니다. 여기서의 실수는 노드 접속 자체를 끊을 수 있으니, 원격 콘솔(iLO/DRAC/VM 콘솔 등) 확보를 강하게 권장합니다.

1) OS 네트워크 반영(예시 흐름)

• NIC 설정 파일/NetworkManager 프로파일에 새 IP/게이트웨이 반영
• 네트워크 재기동(운영 표준에 따라) 후 ip addr, ip route 확인
• 노드 hostname이 새 Public IP로 해석되는지 확인

# 노드에서
hostname
getent hosts $(hostname)
ip addr
ip route

2) 클러스터 관점 확인

# Grid 사용자
olsnodes -n -i
crsctl stat res -t

Public IP의 서브넷이 바뀌면서 인터페이스 매핑이 달라지면 oifcfg 조정이 필요할 수 있습니다(다음 항목 참고).

D. Interconnect(Private) IP/서브넷 변경

Interconnect 변경은 RAC 안정성에 직접 영향을 줍니다. 패킷 손실/MTU 불일치/라우팅 오류가 eviction으로 번질 수 있어, 변경 후에는 반드시 노드 간 지연/손실을 확인합니다.

1) OS NIC 반영

• 각 노드에 동일한 정책(MTU, bonding/teaming, VLAN 등) 적용
• IP/서브넷 변경 후 인터페이스 업 상태 확인

2) oifcfg 매핑 확인 및 조정(필요 시)

# Grid 사용자
oifcfg getif

인터페이스가 잘못 분류되어 있으면, 환경에 따라 아래처럼 재등록이 필요할 수 있습니다(명령 옵션은 환경에 맞게 적용).
이 단계는 표준 변경 절차서에 따라 “삭제 → 등록” 순서를 명확히 하고, 작업 전 출력값을 반드시 보관하세요.

# 예시(환경별로 다를 수 있음)
# oifcfg delif -global <ifname>
# oifcfg setif -global <ifname>/<subnet>:cluster_interconnect
# oifcfg setif -global <ifname>/<subnet>:public

3) 변경 후 클러스터 상태 확인

crsctl stat res -t

E. 서비스/접속 최종 확인

• 각 노드 VIP가 ONLINE인지
• SCAN/SCAN listener가 ONLINE인지
• 리스너가 정상 바인딩인지
• 애플리케이션 접속 문자열(특히 SCAN 기반)로 접속이 되는지

# Grid 사용자
srvctl status vip
srvctl status scan
srvctl status scan_listener
srvctl status listener

# DB 사용자(또는 DB 홈에서)
srvctl status database -d <db_unique_name>
srvctl status service -d <db_unique_name>

재발 방지

1) DNS/hosts 운영 원칙을 고정

• 가능하면 SCAN은 DNS로만 관리(노드별 hosts 편차 제거)
• VIP/노드명도 DNS로 일관되게 운영하거나, 불가피하면 hosts를 “배포 자동화”로 동일하게 유지
• 작업 전후에 getent hosts 결과를 노드별로 저장해 변경 이력을 남김

2) 변경 리허설과 롤백 포인트

• 변경 단계마다 “성공 판정 기준”을 문장으로 고정(예: VIP ONLINE 확인 후 다음 단계)
• 롤백은 “DNS 되돌림 + srvctl 되돌림 + OS 네트워크 되돌림”의 3축으로 준비
• Oracle 19c RAC IP 변경은 재시도보다 “되돌리고 다시”가 더 빠른 경우가 많음

3) 표준 점검 커맨드 묶음 운영

작업자 교체/야간 작업에서도 동일 결과를 보려면 점검 명령을 표준화하는 것이 중요합니다.

# 사전/사후 동일하게 실행(출력 저장)
getent hosts <scan-name>
getent hosts <node1-vip-name>
getent hosts <node2-vip-name>

oifcfg getif
olsnodes -n -i
crsctl stat res -t

srvctl status scan
srvctl status scan_listener
srvctl status vip
srvctl status listener

운영 관점 결론 RAC IP 변경은 “srvctl을 잘 치는 작업”이 아니라 “이름 해석과 인터페이스 정의를 정확히 맞추는 작업”입니다.
실무 기준으로 보면, 변경 전후의 해석 결과를 노드별로 증적화하는 것만으로도 장애 대응 시간이 크게 줄어듭니다.