Physical Address
South Korea
내가 밤새며 찾아낸 ExaCC-NetBackup 타임아웃(Status 41) 장애의 범인과 해결책
ExaCC 백업만 들어가면 뚝뚝 끊기는 네트워크, 도대체 뭐가 문제일까?
엔터프라이즈 인프라를 운영하다 보면 정말 피하고 싶은 순간들이 있습니다. 그중 하나가 바로 새벽 시간대에 들려오는 “백업 윈도우(Backup Window) 초과” 알람, 그리고 뒤이어 찾아오는 “시스템 행(Hang) 발생”이라는 최악의 시나리오일 것입니다. 특히 오라클의 고성능 클라우드 인프라 솔루션인 Exadata Cloud@Customer(ExaCC) 환경을 도입한 기업에서 이런 일이 터지면 당혹감은 배가 됩니다. 비싼 돈을 들여 초고속 인프라를 구축했는데, 왜 백업 레이어에서 발목을 잡히는 걸까요?
실무에서 가장 빈번하게 접하는 패턴은 온프레미스(On-Premise) 환경의 Veritas NetBackup 미디어 서버와 ExaCC의 RMAN(Recovery Manager)을 연동해 대규모 데이터베이스 백업을 수행할 때 발생합니다. 평소에는 멀쩡하던 시스템이 정기 대량 백업만 시작하면 특정 시점부터 네트워크 RTT(Round Trip Time)가 수백 ms 단위로 치솟다가, 결국 세션이 뚝 끊기며 타임아웃 장애로 이어지는 현상입니다.
제가 20년 동안 엔터프라이즈 인프라 현장에서 수많은 장애를 겪으며 뼈저리게 배운 것은, 이러한 고도화된 클라우드 아키텍처일수록 데이터베이스 내부만 들여다봐서는 답이 안 나온다는 사실입니다. 수많은 밤을 지새우며 패킷을 덤프 뜨고, 로그를 대조해가며 찾아낸 ExaCC와 NetBackup 연동 환경의 네트워크 병목 현상 원인, 그리고 현장에서 검증된 구체적인 트러블슈팅 가이드를 아낌없이 공유해 드립니다.
새벽 2시의 악몽: ORA-03113 에러와 Status Code 41의 연결고리
보통 장애는 아주 고약한 타이밍에 찾아옵니다. 풀 백업(Full Backup)이 시작되고 초기 1~2시간 동안은 기가비트 대역폭을 꽉 채우며 시원하게 데이터가 넘어가는 것처럼 보입니다. 엔진룸의 대시보드도 온통 초록빛이죠. 하지만 데이터 전송량이 테라바이트(TB) 단위를 넘어가기 시작하면, 오라클 알럿 로그(alert.log)에 불길한 메시지들이 찍히기 시작합니다.
Plaintext
ORA-03113: end-of-file on communication channel
ORA-19502: write error on file, block number 1420582
ORA-27030: skgfwrt: OSPM dependent error
이와 동시에 NetBackup 마스터 및 미디어 서버의 활동 모니터(Activity Monitor)를 확인해 보면 어김없이 Status Code 41 (network connection timed out) 또는 Status Code 24 (socket write failed) 에러를 뱉으며 작업이 ‘Failed’ 상태로 붉게 물들어 있습니다.
인프라 담당자와 DBA는 서로 남 탓을 하기 딱 좋은 상황입니다. DBA는 “네트워크가 끊겼다”고 하고, 네트워크 담당자는 “장비에는 아무 이상이 없다”고 맞섭니다. 하지만 이 장애의 근본 원인은 장비의 고장이 아니라, 네트워크 레이어의 처리 한계와 오라클 I/O 메커니즘의 불일치에 있습니다.
ExaCC 인프라는 무시무시한 속도로 대량의 DB 블록을 NetBackup 미디어 서버로 밀어냅니다. 이때 유선 네트워크 스위치나 인터페이스 카드(NIC) 레벨에서 처리 용량을 초과하는 순간 순간적인 패킷 드롭(Packet Drop)이 발생합니다. TCP 프로토콜은 신뢰성 있는 전송을 위해 즉시 재전송(Retransmission) 프로세스를 가동하는데, 이 재전송 횟수가 누적되면 왕복 지연 시간(RTT)이 오라클이 허용하는 임계치를 훌륭하게 넘어서게 됩니다. 결국 오라클 RMAN 프로세스는 “상대방 미디어 서버가 죽었구나”라고 판단하고, 스스로 세션을 강제로 닫아버리는 것입니다.
뼈아픈 시행착오 끝에 찾아낸 2단계 최적화 솔루션
이 문제를 해결하기 위해 단순히 “네트워크 회선을 증설해 주세요”라고 요청하는 것은 하수입니다. 비용도 비용이거니와, 파이프라인 구조를 바꾸지 않으면 대역폭이 넓어져도 똑같은 병목이 생깁니다. OS 커널 레벨의 TCP 버퍼 최적화와 오라클 RMAN 채널의 파라미터 튜닝을 동시에 정밀하게 맞물려 돌려야 비로소 해결의 실마리가 풀립니다.
1단계: Linux 엔터프라이즈 커널 네트워크 파라미터 튜닝
가장 먼저 해야 할 일은 ExaCC 데이터베이스 노드와 전용 미디어 서버의 OS 레벨에서 대용량 데이터 전송의 폭풍을 받아낼 수 있도록 완충 지대(Buffer)를 넓혀주는 것입니다. 기본 Linux 커널 설정은 일반적인 웹 서비스나 소규모 트래픽에 맞춰져 있어, 테라바이트급 백업 I/O가 몰치면 순식간에 링 버퍼가 가득 차버립니다.
서버의 /etc/sysctl.conf 파일을 열고 아래의 파라미터들을 과감하게 반영해 줍니다.
Plaintext
# 대규모 백업 I/O 처리를 위한 TCP 송수신 버퍼 극대화
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.netdev_max_backlog = 5000
설정을 저장한 후, 잊지 말고 sysctl -p 명령어를 실행해 커널에 즉시 반영해 줍니다.
Bash
$ sudo sysctl -p
이렇게 설정을 바꾸면 네트워크 구간에서 일시적으로 병목이 발생하더라도 패킷을 즉시 버리는(Drop) 대신, 메모리 공간인 링 버퍼에서 안정적으로 대기시킬 수 있는 든든한 방파제가 마련됩니다.
2단계: RMAN 백업 스크립트 파라미터 최적화 (SBT_TAPE 튜닝)
OS 레벨의 방파제를 쌓았다면, 이제 오라클 RMAN이 데이터를 던지는 방식을 튜닝해야 합니다. 핵심은 “자잘하게 자주 던지지 말고, 큼직하게 뭉쳐서 한 번에 던져라”입니다. 네트워크와 프로세스 간의 자원 경합을 줄이고 블록 사이즈를 극대화하는 스크립트 구조를 짜야 합니다.
실제 프로덕션 환경에 적용해 성공을 거둔 RMAN 할당 스크립트 스니펫을 공개합니다.
SQL
RUN {
-- NetBackup 미디어 관리 라이브러리(SBT_TAPE) 채널 할당
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE'
PARMS 'SBT_LIBRARY=/usr/openv/netbackup/bin/libobk.so,
ENV=(NB_ORA_CLIENT=exacc-node01, NB_ORA_SERV=nbu-master)';
-- 불필요한 오버헤드를 제거하고 대용량 버퍼 및 블록 사이즈 강제 지정
SET ENCRYPTION OFF;
SEND 'NB_ORA_BUFFERS=4, NB_ORA_BUFSIZE=1048576';
BACKUP
INCREMENTAL LEVEL 0
DATABASE
FORMAT 'bk_%U_%t'
FILESPERSET 8
BLOCKSIZE 1048576;
RELEASE CHANNEL ch01;
}
이 스크립트에서 눈여겨보셔야 할 튜닝 포인트는 딱 두 가지입니다.
BLKSIZE/NB_ORA_BUFSIZE(1MB로 확장): 오라클의 기본값은 64KB 또는 256KB 정도로 매우 작습니다. 이를 1MB(1048576)로 과감하게 확장해 줍니다. I/O를 호출하는 횟수 자체가 16분의 1 수준으로 줄어들기 때문에, 네트워크 RTT가 조금 흔들리더라도 타임아웃으로 이어지지 않는 엄청난 맷집을 갖게 됩니다.FILESPERSET = 8: 하나의 백업 세트에 너무 많은 데이터 파일을 묶어버리면 전송 도중 리스크가 누적됩니다. 8개에서 최대 12개 수준으로 제한하여 타임아웃 리스크를 잘게 분산시키는 것이 현명합니다.
가시성 확보가 가져다준 놀라운 변화
커널 파라미터 확장과 RMAN 블록 사이즈 고도화를 복합적으로 적용한 결과는 기대 이상이었습니다. 수시로 삐걱거리며 평균 120ms까지 치솟던 네트워크 RTT가 20ms 미만으로 완벽하게 안정화되었습니다.
가장 체감이 컸던 부분은 백업 시간 자체의 감소였습니다. 대량의 데이터베이스(약 8TB 규모)를 풀 백업할 때 기존 대비 약 35%의 시간 단축 효과를 거두었습니다. 새벽 내내 아슬아슬하게 이어지던 백업이 이제는 출근 시간 전 여유롭게 마무리가 되니, 운영팀의 피로도 역시 몰라보게 줄어들었습니다.
ExaCC 같은 고성능 아키텍처를 다룰 때일수록 단편적인 데이터베이스 내부 튜닝에만 매몰되면 안 됩니다. 시스템 전체를 관통하는 네트워크 레이어와 스토리지 백업 솔루션의 하부 메커니즘을 유기적인 시선으로 바라볼 때, 비로소 엔터프라이즈 시스템의 연속성과 안정성을 확보할 수 있습니다. 오늘 공유해 드린 트러블슈팅 경험이 동일한 패턴의 장애로 머리를 싸매고 계실 전국의 시스템 아키텍트와 인프라 엔지니어분들에게 명쾌한 이정표가 되기를 바랍니다.
전문가의 인사이트 : 함께 읽어 보세요.
“오라클이 해주니까 안전하다?” 자동 ExaCC OS backup의 치명적인 함정
