Oracle RAC를 NHN Cloud 하이브리드로: 서버는 그대로, 네트워크만 바꾸는 리로케이션

마이그레이션이 아니라 리로케이션

Oracle RAC(Real Application Clusters)를 NHN Cloud 같은 하이브리드 환경으로 옮기려 하면 현실적인 장벽을 만납니다. RAC를 클라우드 환경에 그대로 올려 구성·지원하는 데 제약이 크기 때문입니다. 그래서 서버를 새로 구축하는 대신 다른 길을 택합니다.

바로 리로케이션입니다. 고객의 물리 서버, OS, 디스크는 그대로 유지하고, 네트워크 연결만 변경해 하이브리드 구성에 편입시키는 작업이죠. 이미 안정적으로 돌고 있는 시스템을 새로 짓는 게 아니라, "배선"만 바꾸는 것에 가깝습니다. 마이그레이션이 집을 새로 짓는 일이라면, 리로케이션은 이사 없이 전기와 통신 회선만 새 경로로 트는 일에 비유할 수 있습니다.

RAC를 네트워크로 보면 세 개의 축

무엇을 바꿔야 하는지 이해하려면, RAC의 네트워크 구조부터 봐야 합니다. 크게 세 축으로 나뉩니다.

여기서 두 가지가 특히 중요합니다. 첫째, Public IP·VIP·SCAN은 같은 서브넷에 있어야 한다는 Oracle의 설계 전제입니다. 둘째, SCAN은 DNS에서 여러 IP로 해석되도록 구성하고 hosts 파일에는 두지 않는다는 권고입니다. hosts는 하나의 IP만 반환할 수 있어 SCAN의 부하 분산 목적에 맞지 않기 때문이죠. 리로케이션은 이 세 축에 걸친 OS·Oracle·스토리지 설정을 동시에 정합되게 바꾸는 일이고, 한 층만 바뀌고 다른 층이 어긋나면 클러스터가 기동에 실패합니다.

왜 "Oracle 먼저, 네트워크 나중에"인가

리로케이션의 성패는 순서에 달려 있습니다. 직관적으로는 OS 네트워크부터 바꿀 것 같지만, 그렇게 하면 순환 의존(circular dependency)에 빠집니다.

핵심 전략은 이렇습니다. CRS가 정상 동작하는 현재 네트워크에서 Oracle 설정(OCR·GPnP)을 먼저 새 서브넷으로 바꿔두고, OS 네트워크 파일은 복사만 해둔 뒤, 재부팅 한 번으로 둘을 동시에 적용하는 것입니다. 그러면 재부팅 후 OS 네트워크와 Oracle 설정이 같은 새 환경에서 함께 올라옵니다.

이 과정에서 가장 까다로운 지점이 GPnP(Grid Plug and Play) 프로파일입니다. 이 프로파일에 이전 서브넷이 남아 있으면 재부팅 후 기동이 실패하는데, 프로파일은 디지털 서명이 있어 sed로 직접 고치면 서명이 깨져 무시됩니다. 반드시 gpnptool의 편집·서명·반영 절차를 따라야 합니다.

자주 하는 실수

실제 현장에서 마주치는 함정은 대체로 정해져 있습니다.

• SCAN을 hosts에 고정: hosts는 단일 IP만 반환해 SCAN의 부하 분산에 맞지 않습니다. SCAN은 DNS로만 해석되게 두는 것이 원칙입니다.

• OS 네트워크를 먼저 변경: 위에서 본 순환 의존에 빠집니다. "Oracle 먼저" 전략은 바로 이 실수에서 도출됐습니다.

• GPnP 프로파일을 직접 편집: 서명이 깨져 변경이 무시됩니다. 전용 도구로 편집·서명·반영해야 합니다.

한 가지 더, 클러스터웨어 변경은 자동으로 롤백되지 않습니다. 그래서 변경 전에 네트워크와 클러스터 설정을 스냅샷으로 남겨 롤백 기준을 만들어 두고, OCR을 바꾸는 단계를 명확한 분기점으로 잡는 것이 안전합니다. 그 단계 전이라면 OS 파일 복원만으로 되돌릴 수 있고, 이후라면 OCR까지 되돌려야 합니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)