"DB자동복구 왜 안됐나?"
지난 27일 2시간 15분 동안 계속된 국민은행 전산사고의 원인이 아직 밝혀지지 않고 있다. 또 사고원인을 놓고 한국IBM 외에 한국EMC 등 국민은행의 IT통합작업에 참여한 다른 IT업체로 책임공방이 확산될 조짐을 보이고 있다.
은행은 28일 오전 회의를 갖고 월말과 연말에 집중될 결제수요에 대비해 사고재발 방지를 위한 대책마련에 들어갔다.
은행 관계자는 "현재 원인을 파악하기 위해 IBM연구센터 등 해외 핫라인을 개설해 분석작업을 진행하고 있다"며 "이르면 다음주 초 결과가 나올 것"이라고 밝혔다.
은행은 현재 문제가 발생한 3호기를 대기상태로 전환시키고 1ㆍ2호기만으로 시스템을 가동하면서 로그데이터를 분산시킬 수 있는 로드밸런싱(load Balancing) 확보 등 다양한 방안을 강구하고 있다.
◇구체적인 사고경위〓은행측이 밝힌 사고의 직접적인 원인은 계정계 3호기의 `DB 자동복구기능'이 작동하지 않았기 때문이다. 따라서 은행도 `왜 데이터베이스(DB) 자동복구기능이 수행되지 않았는가'에 대한 원인분석으로 초점이 맞춰지고 있다.
현재로선 디스크와 시스플렉스 두 부문에서 복합적으로 문제가 발생한 것으로 보인다. 시스플렉스의 통제장치 역할을 하는 일조의 `가상메모리(CF)'에서 복구절차를 밟아야 했으나 이 과정이 제대로 작동되지 않았고, 디스크의 경우는 7개 DB가 반응을 보이지 않았던 것으로 파악되고 있다.
사고경위는 이렇다. 은행은 27일 오전 계정계시스템 3호기에서 장애가 발생하자 즉각 3호기를 `가동대기상태'로 전환해 시스플렉스 체계에서 `제외'(excluding)시켰다. 시스플렉스 체계에서는 하나의 시스템을 제외시킬 경우 반드시 그 시스템에서 처리하는 데이터를 자동복구(auto recovery)시켜야 한다. 그러나 어찌된 영문인지 복구대상이 되는 3호기의 3000개 DB 중 7개 DB에서 `자동복구불가' 메시지가 떴다.
은행은 7개 DB에 대해 `수동복구'를 할 수밖에 없었고 이 기간에 부득이하게 계정계 1ㆍ2호기까지 중단시켜야만 했다. 1ㆍ2호기를 중단시킨 이유는 3호기에서 처리되던 DB의 데이터 갱신이 안된 상황에서 1ㆍ2호기를 그대로 가동했을 경우 데이터 정합성에 심각한 문제가 발생할 수 있다고 판단했기 때문이다. 결국 3호기 장애로 나머지 1ㆍ2호기까지 모두 멈추게 된 것이다.
◇IT업체간 책임공방 확산〓이번 사고와 관련해 일각에서는 업체간 공방도 확산될 가능성이 있다고 보고 있다. 통상 시스플렉스 체계에서 운영되는 시스템이 다운될 때 DB의 `자동복구' 기능이 실행되려면 먼저 시스템과 물려있는 디스크(Disk)에서 처리(반응)가 선결돼야 하는데 디스크에서 반응이 없을 경우 `자동복구' 기능이 실행되지 않을 수 있다는 지적도 제기되고 있기 때문이다. 따라서 국민은행에 디스크를 납품한 EMC까지도 불똥이 튈 가능성도 배제할 수 없게 됐다.
◇한국IBM `곤혹'〓한국IBM측은 "아직 사고의 원인이 명확하게 밝혀지지 않은만큼 공식적인 입장표명이 어렵지만 문제가 재발하지 않도록 협조하고 있다"는 반응이다.
그러나 이번 사고는 `하나의 시스템이 다운되면 나머지 시스템이 이를 받아 처리함으로써 시스템의 무중단ㆍ무장애 환경을 구현한다'는 시스플렉스 의미를 살리지 못했다는 점에서 은행측의 향후 대응이 주목된다.
은행 관계자는 "시스플렉스 자체의 기술적 결함보다는 시스플렉스 운영상 노하우 부족 등에 초점을 맞추고 있다"고 밝혔다.
박기록기자
지난 27일 2시간 15분 동안 계속된 국민은행 전산사고의 원인이 아직 밝혀지지 않고 있다. 또 사고원인을 놓고 한국IBM 외에 한국EMC 등 국민은행의 IT통합작업에 참여한 다른 IT업체로 책임공방이 확산될 조짐을 보이고 있다.
은행은 28일 오전 회의를 갖고 월말과 연말에 집중될 결제수요에 대비해 사고재발 방지를 위한 대책마련에 들어갔다.
은행 관계자는 "현재 원인을 파악하기 위해 IBM연구센터 등 해외 핫라인을 개설해 분석작업을 진행하고 있다"며 "이르면 다음주 초 결과가 나올 것"이라고 밝혔다.
은행은 현재 문제가 발생한 3호기를 대기상태로 전환시키고 1ㆍ2호기만으로 시스템을 가동하면서 로그데이터를 분산시킬 수 있는 로드밸런싱(load Balancing) 확보 등 다양한 방안을 강구하고 있다.
◇구체적인 사고경위〓은행측이 밝힌 사고의 직접적인 원인은 계정계 3호기의 `DB 자동복구기능'이 작동하지 않았기 때문이다. 따라서 은행도 `왜 데이터베이스(DB) 자동복구기능이 수행되지 않았는가'에 대한 원인분석으로 초점이 맞춰지고 있다.
현재로선 디스크와 시스플렉스 두 부문에서 복합적으로 문제가 발생한 것으로 보인다. 시스플렉스의 통제장치 역할을 하는 일조의 `가상메모리(CF)'에서 복구절차를 밟아야 했으나 이 과정이 제대로 작동되지 않았고, 디스크의 경우는 7개 DB가 반응을 보이지 않았던 것으로 파악되고 있다.
사고경위는 이렇다. 은행은 27일 오전 계정계시스템 3호기에서 장애가 발생하자 즉각 3호기를 `가동대기상태'로 전환해 시스플렉스 체계에서 `제외'(excluding)시켰다. 시스플렉스 체계에서는 하나의 시스템을 제외시킬 경우 반드시 그 시스템에서 처리하는 데이터를 자동복구(auto recovery)시켜야 한다. 그러나 어찌된 영문인지 복구대상이 되는 3호기의 3000개 DB 중 7개 DB에서 `자동복구불가' 메시지가 떴다.
은행은 7개 DB에 대해 `수동복구'를 할 수밖에 없었고 이 기간에 부득이하게 계정계 1ㆍ2호기까지 중단시켜야만 했다. 1ㆍ2호기를 중단시킨 이유는 3호기에서 처리되던 DB의 데이터 갱신이 안된 상황에서 1ㆍ2호기를 그대로 가동했을 경우 데이터 정합성에 심각한 문제가 발생할 수 있다고 판단했기 때문이다. 결국 3호기 장애로 나머지 1ㆍ2호기까지 모두 멈추게 된 것이다.
◇IT업체간 책임공방 확산〓이번 사고와 관련해 일각에서는 업체간 공방도 확산될 가능성이 있다고 보고 있다. 통상 시스플렉스 체계에서 운영되는 시스템이 다운될 때 DB의 `자동복구' 기능이 실행되려면 먼저 시스템과 물려있는 디스크(Disk)에서 처리(반응)가 선결돼야 하는데 디스크에서 반응이 없을 경우 `자동복구' 기능이 실행되지 않을 수 있다는 지적도 제기되고 있기 때문이다. 따라서 국민은행에 디스크를 납품한 EMC까지도 불똥이 튈 가능성도 배제할 수 없게 됐다.
◇한국IBM `곤혹'〓한국IBM측은 "아직 사고의 원인이 명확하게 밝혀지지 않은만큼 공식적인 입장표명이 어렵지만 문제가 재발하지 않도록 협조하고 있다"는 반응이다.
그러나 이번 사고는 `하나의 시스템이 다운되면 나머지 시스템이 이를 받아 처리함으로써 시스템의 무중단ㆍ무장애 환경을 구현한다'는 시스플렉스 의미를 살리지 못했다는 점에서 은행측의 향후 대응이 주목된다.
은행 관계자는 "시스플렉스 자체의 기술적 결함보다는 시스플렉스 운영상 노하우 부족 등에 초점을 맞추고 있다"고 밝혔다.
박기록기자
[저작권자 ⓒ디지털타임스 무단 전재-재배포 금지]
실시간 주요뉴스
기사 추천
- 추천해요 0
- 좋아요 0
- 감동이에요 0
- 화나요 0
- 슬퍼요 0