2021.01.08

허리케인이 강타한 섬에서 얻는 재해 복구에 관한 교훈

W. Curtis Preston | Network World
허리케인이 미국의 한 바이오테크 회사가 ‘미션 크리티컬’ 시스템을 제어하기 위해 운영하는 2개 데이터센터가 위치한 섬을 강타했다. 이 바이오테크 회사는 40년의 경력을 가진 백업 전문가를 전용기에 태워 섬으로 보냈다. 여기서는 익명을 요청한 이 전문가가 이 섬에서 부딪힌 문제와 이를 극복한 방법을 소개한다. 편의상 전문가와 섬, 회사 이름은 모두 가명을 사용하며, 관련 솔루션 업체와 서비스 업체도 밝히지 않는다.
 
ⓒ Getty Images Bank

이니테크(가칭)는 아틀란티스섬(가칭)에 2개 데이터센터를 갖고 있었다. 약 200대의 가상 및 물리 시스템에서 실행되는 데이터의 양은 모두 400TB에 달한다. 백업 시스템은 업계 수위의 전통적인 백업 소프트웨어 솔루션 업체의 제품을 기반으로, 중복제거 디스크 시스템에 데이터를 백업한다. 각 데이터센터는 데이터를 자체 중복제거 시스템에 백업한 후, 다시 다른 데이터센터의 디스크 시스템으로 백업을 복제한다. 각 데이터센터에 이니테크가 아틀란티스 섬에 보관한 모든 백업의 전체 사본이 위치하기 때문에, 데이터센터 한 곳이 파괴되어도 이니테크는 여전히 모든 데이터를 보존할 수 있다.

또한 이니테크는 에어갭(Air Gap) 용도로 가끔 이들 백업을 테이프에 복사해 아틀란티스 섬에 보관한다. 본사가 있는 지역에 저장할 수도 있었지만 그렇게 하지 않았다. 다행히 이번 허리케인에 테이프가 파괴되지는 않았지만, 손상될 수도 있었다. 이니테크는 재해 복구에 클라우드를 이용하는 것을 고려했지만, 아틀란티스의 대역폭 제한 때문에 실용적이지 않다는 판단을 내렸다.

허리케인이 닥쳤을 때, 이니테크는 지상 현장에서 복구 프로세스를 지휘할 사람을 찾기 시작했다. 피해가 심했기 때문에 복구 프로세스를 완벽하게 지휘 통솔할 수 있는 사람이 필요했다. 이런 정도의 기술력을 가진 사람은 소수에 불과했고, 그중 한 명이 론(가명)이었다. 이니테크는 론을 전용기에 태워 아틀란티스로 보냈다.
 

물에 잠긴 데이터센터의 이전과 복구

아틀란티스 섬 전체적으로 피해가 심했다. 이니테크로 한정하면, 1개 데이터센터가 침수됐는데, 모든 랙의 아래쪽 서버는 모두 물에 잠겼다. 위쪽 서버는 피해가 없었다. 론은 아직 작동하는 서버를 침수되지 않은 데이터센터로 옮겨 모든 것을 복구하는 계획을 세웠다.

서버를 한 장소에서 다른 장소로 옮기는 계획은 성공했다. 서두르면서 일부 서버를 잘못 다루는 문제가생기기도 했다. 이 때문에 옮긴 데이터센터에서 서버를 다시 조립하는 것이 훨씬 더 어려워졌다. 

론이 해결해야 했던 가장 큰 문제는 아틀란티스의 인터넷 연결이 허리케인 때문에 일시적으로 끊어진 것이었다. 이는 아주 큰 문제였다. 이니테크는 아틀란티스에 별개의 액티브 디렉터리를 구성하지 않고, 본사의 액티브 디렉터리에만 의지하는 잘못된 결정을 내렸었기 때문이다. 모든 AD 쿼리를 본사로 직접 전송해야 하는데, 그 연결이 끊어진 것이다. 복구 작업을 시작하는 데 필요한 시스템에 로그인할 수 없게 된 것이다.

대안으로 위성 기반 인터넷 등 여러 방법을 시도했다. 어느 정도의 연결성을 제공했지만, 금방 일일 대역폭 할당량이 소진되고 말으며, 위성 인터넷 ISP는 연결을 끊을 것이다. 다른 ISP로 마이크로파 연결도 시도했는데, 여러 단계로 구성된 마이크로파 릴레이 방식이었다. 이 방식은 릴레이되는 건물 중 하나에 정전이라도 일어나면, 또 다시 일시적으로 작동이 정지될 수 있다. 네트워크 연결의 기반인 건물과 전력이 안정적이지 않은 상태에서 안정적인 네트워크 연결을 확보하기 매우 어려웠다.

오히려 실제 데이터 복구는 쉬운 부분이었다. 어떤 기준을 적용해도 빨리 복구된 것은 아니지만, 복구 자체는 진행되었다. 한 데이터센터를 다른 데이터센터로 복구하는 전체 과정에 2주가 조금 넘는 시간이 소요됐다. 아틀란티스 섬의 피해 상태를 생각하면, 상당히 빨리 복구한 것이다.

사용하고 있던 백업 소프트웨어는 하이퍼바이저 수준에서 VM웨어를 백업하고 있었기 때문에 200대 정도의 VM 복구는 비교적 간단했다. 반면에 베어메탈 복구가 필요한 몇몇 물리 서버의 복구는 조금 더 어려웠다. 각각 다른 하드웨어에서 베어메탈 복구를 해본 적이 없다면, 몹시 어려운 작업이다. 윈도우는 기준이 엄격하지 않은 편이지만, 때때로 아무 이유없이 안되기도 해서 여러 단계를 추가로 수작업 처리해야 한다. 복구 프로세스에서 가장 힘들었던 부분이다.
 

재해가 알려준 교훈

이 재해가 알려준 첫 번째 교훈은 가장 중요한 교훈으로, 백업 및 복구 시스템이 중요하지만, 재해 복구에서 가장 어려운 과제는 이들 시스템으로 인한 것이 아닐 수도 있다는 것이다. 복구할 장소, 이용할 네트워크를 확보하는 것이 훨씬 더 어려운 문제일 수 있다. 백업 설계를 느슨하게 해도 된다는 말이 아니다. 다른 모든 것들이 작동하지 않을 때에도 백업만큼은 작동하도록 만들어야 한다는 것이다.

좋은 출발점은 액티브 디렉터리에 의존하지 않는 로컬 계정이다. 복구를 시작하는 데 필요한 액티브 디렉터 같은 서비스의 경우, 인터넷 연결이 없어도 작동하도록 로컬 환경에 캐시된 서비스 사본을 유지해야 한다. 이런 서비스가 완전히 분리된 인스턴스로 존재한다면 복구성이 더 높아질 것이다.

최대한 대규모로 복구 ‘훈련’을 하고, GUI 없이 복구하는 방법을 터득해야 한다. SSH를 통해 서버에 로그인하고, 명령줄로 복구 작업을 실행시킬 수 있어야 한다. 전력 효율성이 훨씬 더 높고, 유연한 방법이기 때문이다. 이제 이런 인터페이스에 익숙하지 않은 사람이 더 많겠지만, CLI를 이용한 복구가 유일한 방법인 경우가 많다. 아틀란티스는 전기가 귀했다. 따라서 모니터에 전력을 많이 사용하는 것은 좋은 선택지가 아니었다. 

추가 하드웨어는 도움이 된다. 재해 복구의 한 가지 문제는 시스템을 복구하는 즉시 백업을 해야 한다는 것이다. 그러나 이런 복구 작업의 경우, 백업에 사용할 여분의 하드웨어가 많지 않다. 가지고 있는 하드웨어는 다른 시스템 복구에 사용되고 있기 때문에, 방금 복구한 시스템을 백업하는 작업을 맡기는 것은 좋지 않다. 클라우드가 여기에 도움을 줄 수 있지만, 이번 경우에는 선택지가 될 수 없었다.



2021.01.08

허리케인이 강타한 섬에서 얻는 재해 복구에 관한 교훈

W. Curtis Preston | Network World
허리케인이 미국의 한 바이오테크 회사가 ‘미션 크리티컬’ 시스템을 제어하기 위해 운영하는 2개 데이터센터가 위치한 섬을 강타했다. 이 바이오테크 회사는 40년의 경력을 가진 백업 전문가를 전용기에 태워 섬으로 보냈다. 여기서는 익명을 요청한 이 전문가가 이 섬에서 부딪힌 문제와 이를 극복한 방법을 소개한다. 편의상 전문가와 섬, 회사 이름은 모두 가명을 사용하며, 관련 솔루션 업체와 서비스 업체도 밝히지 않는다.
 
ⓒ Getty Images Bank

이니테크(가칭)는 아틀란티스섬(가칭)에 2개 데이터센터를 갖고 있었다. 약 200대의 가상 및 물리 시스템에서 실행되는 데이터의 양은 모두 400TB에 달한다. 백업 시스템은 업계 수위의 전통적인 백업 소프트웨어 솔루션 업체의 제품을 기반으로, 중복제거 디스크 시스템에 데이터를 백업한다. 각 데이터센터는 데이터를 자체 중복제거 시스템에 백업한 후, 다시 다른 데이터센터의 디스크 시스템으로 백업을 복제한다. 각 데이터센터에 이니테크가 아틀란티스 섬에 보관한 모든 백업의 전체 사본이 위치하기 때문에, 데이터센터 한 곳이 파괴되어도 이니테크는 여전히 모든 데이터를 보존할 수 있다.

또한 이니테크는 에어갭(Air Gap) 용도로 가끔 이들 백업을 테이프에 복사해 아틀란티스 섬에 보관한다. 본사가 있는 지역에 저장할 수도 있었지만 그렇게 하지 않았다. 다행히 이번 허리케인에 테이프가 파괴되지는 않았지만, 손상될 수도 있었다. 이니테크는 재해 복구에 클라우드를 이용하는 것을 고려했지만, 아틀란티스의 대역폭 제한 때문에 실용적이지 않다는 판단을 내렸다.

허리케인이 닥쳤을 때, 이니테크는 지상 현장에서 복구 프로세스를 지휘할 사람을 찾기 시작했다. 피해가 심했기 때문에 복구 프로세스를 완벽하게 지휘 통솔할 수 있는 사람이 필요했다. 이런 정도의 기술력을 가진 사람은 소수에 불과했고, 그중 한 명이 론(가명)이었다. 이니테크는 론을 전용기에 태워 아틀란티스로 보냈다.
 

물에 잠긴 데이터센터의 이전과 복구

아틀란티스 섬 전체적으로 피해가 심했다. 이니테크로 한정하면, 1개 데이터센터가 침수됐는데, 모든 랙의 아래쪽 서버는 모두 물에 잠겼다. 위쪽 서버는 피해가 없었다. 론은 아직 작동하는 서버를 침수되지 않은 데이터센터로 옮겨 모든 것을 복구하는 계획을 세웠다.

서버를 한 장소에서 다른 장소로 옮기는 계획은 성공했다. 서두르면서 일부 서버를 잘못 다루는 문제가생기기도 했다. 이 때문에 옮긴 데이터센터에서 서버를 다시 조립하는 것이 훨씬 더 어려워졌다. 

론이 해결해야 했던 가장 큰 문제는 아틀란티스의 인터넷 연결이 허리케인 때문에 일시적으로 끊어진 것이었다. 이는 아주 큰 문제였다. 이니테크는 아틀란티스에 별개의 액티브 디렉터리를 구성하지 않고, 본사의 액티브 디렉터리에만 의지하는 잘못된 결정을 내렸었기 때문이다. 모든 AD 쿼리를 본사로 직접 전송해야 하는데, 그 연결이 끊어진 것이다. 복구 작업을 시작하는 데 필요한 시스템에 로그인할 수 없게 된 것이다.

대안으로 위성 기반 인터넷 등 여러 방법을 시도했다. 어느 정도의 연결성을 제공했지만, 금방 일일 대역폭 할당량이 소진되고 말으며, 위성 인터넷 ISP는 연결을 끊을 것이다. 다른 ISP로 마이크로파 연결도 시도했는데, 여러 단계로 구성된 마이크로파 릴레이 방식이었다. 이 방식은 릴레이되는 건물 중 하나에 정전이라도 일어나면, 또 다시 일시적으로 작동이 정지될 수 있다. 네트워크 연결의 기반인 건물과 전력이 안정적이지 않은 상태에서 안정적인 네트워크 연결을 확보하기 매우 어려웠다.

오히려 실제 데이터 복구는 쉬운 부분이었다. 어떤 기준을 적용해도 빨리 복구된 것은 아니지만, 복구 자체는 진행되었다. 한 데이터센터를 다른 데이터센터로 복구하는 전체 과정에 2주가 조금 넘는 시간이 소요됐다. 아틀란티스 섬의 피해 상태를 생각하면, 상당히 빨리 복구한 것이다.

사용하고 있던 백업 소프트웨어는 하이퍼바이저 수준에서 VM웨어를 백업하고 있었기 때문에 200대 정도의 VM 복구는 비교적 간단했다. 반면에 베어메탈 복구가 필요한 몇몇 물리 서버의 복구는 조금 더 어려웠다. 각각 다른 하드웨어에서 베어메탈 복구를 해본 적이 없다면, 몹시 어려운 작업이다. 윈도우는 기준이 엄격하지 않은 편이지만, 때때로 아무 이유없이 안되기도 해서 여러 단계를 추가로 수작업 처리해야 한다. 복구 프로세스에서 가장 힘들었던 부분이다.
 

재해가 알려준 교훈

이 재해가 알려준 첫 번째 교훈은 가장 중요한 교훈으로, 백업 및 복구 시스템이 중요하지만, 재해 복구에서 가장 어려운 과제는 이들 시스템으로 인한 것이 아닐 수도 있다는 것이다. 복구할 장소, 이용할 네트워크를 확보하는 것이 훨씬 더 어려운 문제일 수 있다. 백업 설계를 느슨하게 해도 된다는 말이 아니다. 다른 모든 것들이 작동하지 않을 때에도 백업만큼은 작동하도록 만들어야 한다는 것이다.

좋은 출발점은 액티브 디렉터리에 의존하지 않는 로컬 계정이다. 복구를 시작하는 데 필요한 액티브 디렉터 같은 서비스의 경우, 인터넷 연결이 없어도 작동하도록 로컬 환경에 캐시된 서비스 사본을 유지해야 한다. 이런 서비스가 완전히 분리된 인스턴스로 존재한다면 복구성이 더 높아질 것이다.

최대한 대규모로 복구 ‘훈련’을 하고, GUI 없이 복구하는 방법을 터득해야 한다. SSH를 통해 서버에 로그인하고, 명령줄로 복구 작업을 실행시킬 수 있어야 한다. 전력 효율성이 훨씬 더 높고, 유연한 방법이기 때문이다. 이제 이런 인터페이스에 익숙하지 않은 사람이 더 많겠지만, CLI를 이용한 복구가 유일한 방법인 경우가 많다. 아틀란티스는 전기가 귀했다. 따라서 모니터에 전력을 많이 사용하는 것은 좋은 선택지가 아니었다. 

추가 하드웨어는 도움이 된다. 재해 복구의 한 가지 문제는 시스템을 복구하는 즉시 백업을 해야 한다는 것이다. 그러나 이런 복구 작업의 경우, 백업에 사용할 여분의 하드웨어가 많지 않다. 가지고 있는 하드웨어는 다른 시스템 복구에 사용되고 있기 때문에, 방금 복구한 시스템을 백업하는 작업을 맡기는 것은 좋지 않다. 클라우드가 여기에 도움을 줄 수 있지만, 이번 경우에는 선택지가 될 수 없었다.



X