Communications
Exchange Server 2007의 데이터 보호 및 재해 복구
Lee Benjamin
한 눈에 보기:
- 기본 백업 및 복원
- 데이터 연속성
- 복제 기술
- 대체 솔루션
Microsoft Exchange Server는 백업을 고려하여 설계되었습니다. 조직은 메시징 데이터를 백업해야 하며 이러한 정보를 복원할 수도 있어야 합니다.
이러한 요구에 부응하기 위해 Microsoft는 낮은 수준의 기존 백업 및 복원에서 작업 연속성, 그리고 최고 수준의 가용성 및 재해 복구를 제공하는 진정한 비즈니스 연속성 솔루션에 이르기까지 모든 범위를 포괄하는 데이터 보호 옵션을 선보이게 되었습니다. 이 문서에서는 이러한 옵션을 하나씩 살펴보고 조직에 가장 적합한 Exchange 복구 솔루션을 구현하는 방법을 찾는 데 도움이 되는 정보를 제공합니다.
수준 1: 기본 백업 및 복원
Exchange 데이터베이스를 오프라인으로 전환하여 Exchange 파일을 백업할 수도 있고 Exchange가 실행되는 동안에 파일을 백업할 수도 있습니다. 사실 온라인 백업이 가장 권장되는 Exchange 백업 방법입니다. 그런데 Exchange는 단순한 파일 모음 그 이상이며, 대용량 데이터베이스 파일과 트랜잭션 로그를 포함하는 정보 저장소입니다. Exchange로 전송된 메시지는 즉시 트랜잭션 로그에 기록되며 시스템에 여유 주기가 있을 때(일반적으로 몇 밀리초 후) 메시지가 데이터베이스 자체에 복사됩니다. Exchange는 정보를 가능한 한 빨리 디스크로 가져옴으로써 매우 높은 수준의 복구 성능을 제공합니다. Exchange 복원에서 중요한 것은 데이터베이스 파일과 트랜잭션 로그라는 두 정보 집합의 가용성입니다. 시스템에 오류가 발생할 경우 가장 최근 정보로 Exchange를 복원할 수 있게 해 주는 것은 바로 이전 백업과 오류 발생 시점 이후부터의 모든 트랜잭션입니다. Exchange는 필요한 경우 복원된 데이터베이스에 트랜잭션을 자동으로 재생합니다.
백업 프로그램은 ESE(Extensible Storage Engine) 백업 API 또는 새로운 VSS(볼륨 섀도 복사본 서비스) 솔루션을 통해 Exchange 데이터베이스의 정보에 액세스합니다. VSS 솔루션에 대해서는 뒤에서 자세히 설명하겠습니다. ESE 백업이 시작될 때마다 Exchange는 데이터베이스에 대한 모든 쓰기를 임시로 일시 중단합니다. ESE는 데이터베이스를 임시로 읽기 전용 모드로 설정하여 데이터베이스가 전체 백업에 복사될 수 있도록 하는 동시에 백업 중 발생하는 새 트랜잭션을 임시 데이터베이스에 보관합니다. 백업이 완료되면 ESE는 데이터베이스를 원래의 읽기/쓰기 모드로 되돌리고 임시 데이터베이스에 누적된 트랜잭션을 적용합니다. 이전 트랜잭션 로그는 백업 프로세스가 완료될 때 제거됩니다.
이러한 백업 프로세스는 매우 단순하며 야간에 백업이 한참 진행 중일 때 로그온한 사용자조차도 알지 못하게 수행되지만 ESE가 완료되기까지 매우 오래 걸릴 수 있습니다. 특히, Exchange 데이터베이스의 크기가 몇 GB에서 관리 가능한 30-50GB나 심지어는 100GB에 이를 경우에는 시간이 더욱 많이 소요됩니다. 크기가 이렇게 크면 표준 기술을 사용해서는 야간에 백업을 완료하는 것이 어렵습니다. NTBackup.exe를 사용할 경우 선택할 수 있는 옵션을 보려면 그림 1을 참조하십시오.
그림 1** NTBackup 유틸리티 사용 **
Exchange에 적용할 수 있는 최선의 방법
일반적인 하드웨어 및 시스템 오류로부터 신속하게 복구할 수 있으려면 매일 밤 Exchange 전체 백업을 실행해야 합니다. Exchange 서버가 로컬 디스크를 사용할 때마다 성능 및 복구 능력을 개선하려면 독립된 RAID 배열을 사용하여 Exchange 데이터베이스와 Exchange 트랜잭션 로그를 저장하는 것이 중요합니다. 이렇게 하면 한 RAID 배열 컨트롤러에 오류가 발생하거나 배열에 있는 둘 이상의 디스크에 오류가 발생하여 나머지 디스크가 스트라이프 데이터를 다시 구성할 수 없는 경우에도 복구가 가능합니다. 트랜잭션 로그가 손실된 경우에는 다른 드라이브에 최신 Exchange 데이터베이스가 저장되어 있으므로 새 트랜잭션 로그를 사용하여 정상적으로 작업을 계속할 수 있습니다. 데이터베이스 드라이브가 손실된 경우에는 전날 밤의 Exchange 데이터베이스 전체 백업을 가져온 다음 당일 트랜잭션 로그를 적용하여 데이터베이스를 최신 상태로 업데이트하는 복구 방법을 실행할 수 있습니다.
적절한 시간 내에 백업, 그리고 더 중요한 복원이 가능하도록 각 Exchange 데이터베이스의 크기를 제한하는 것 또한 매우 중요합니다. 대부분의 조직에서는 데이터베이스 크기를 30에서 50GB 사이로 유지하는 것이 좋습니다. 데이터베이스의 크기가 이보다 커지면 복원을 손쉽게 수행할 수 있도록 여러 개의 데이터베이스로 나누는 것이 좋습니다.
백업 및 복원 연속선
데이터베이스와 트랜잭션 로그의 배치는 백업 성능뿐만 아니라 복구 속도를 위해서도 매우 중요합니다. 요즘에는 모든 서버에서 RAID라고 하는 다양한 계층의 디스크 드라이브 중복을 지원합니다. 기본적으로 RAID는 디스크 드라이브에서 오류가 발생하더라도 시스템이 중단되지 않도록 해 줍니다. 그러나 해당 디스크를 교체하고 다시 빌드할 때까지 시스템 성능이 저하됩니다. 그 전까지는 배열 컨트롤러가 각 디스크 액세스 요청에 응답하여 즉시 나머지 디스크에서 데이터를 다시 구성해야 합니다. 사서함 서버 저장소 설계에 대한 자세한 내용은 Microsoft IT Showcase 백서인 "64비트에서 Exchange Server 2007 사용"을 참조하십시오.
Exchange의 가장 두드러진 특징은 단일 인스턴스 데이터베이스 설계입니다. 이는 한 Exchange 데이터베이스 내에 특정 메시지의 단일 복사본만 단일 첨부 파일(있는 경우)과 함께 저장된다는 것을 의미합니다. 해당 메시지가 동일한 정보 저장소에 있는 여러 명의 받는 사람에게 전송되는 경우에는 해당 개체(메시지, 첨부 파일)에 대한 추가 포인터가 만들어지고 개체 자체는 복제되지 않습니다. 이로써 Exchange의 배달 효율성이 극대화될 뿐만 아니라 Exchange에서 사용하는 디스크와 테이프의 저장 공간 또한 절약됩니다.
Exchange의 전체 데이터베이스 복원 성능은 매우 우수하지만 개별 사서함, 폴더 또는 메시지를 복원하려면 먼저 전체 테이프를 복원해야 하는 단점이 있습니다. 따라서 사용자는 이보다 세분화된 복원 기능을 원합니다. 그러나 테이프에는 단일 인스턴스만 있으므로 세분화하기 매우 어렵습니다. 백업 공급업체에서 브릭 수준 백업(Brick-Level Backup)을 통해 이러한 요구에 부응했지만 필자는 이 방법을 권장하지 않습니다. 이 방법은 입증된 ESE 백업 API를 사용하여 Exchange 데이터베이스의 전체 백업이 만들어지면 백업 테이프에 각 사서함을 추가합니다. 그런데 백업 API는 개별 사서함에서 데이터를 가져오는 방법을 제공하지 않으므로 MAPI가 사용되고, 그 결과 모든 메시지와 첨부 파일이 복제되므로 백업 테이프가 상당히 길어지게 됩니다.
Microsoft는 이 문제를 부분적으로 해결하기 위해 몇 가지 기능을 개선했습니다. 예를 들어 관리자의 휴지통에는 사용자가 항목을 삭제한 후 항목이 다시 필요할 경우에 대비하여 일정 기간 동안 항목이 보관됩니다. 뿐만 아니라 이제 더 이상 Exchange 복구 포리스트로 예비 서버를 배치할 필요가 없습니다. 관리자가 복구 저장소 그룹을 통해 테이프에서 가져온 복원 데이터베이스를 부분적으로 마운트할 수 있게 되었으며 사서함 수준까지 데이터를 복사하거나 병합할 수 있게 되었습니다.
실패는 성공의 어머니
대부분의 조직은 결정된 백업 및 복구 수준에 관계없이 백업 미디어와 복구 절차를 정기적으로 테스트해야 한다는 사실을 비싼 대가를 치른 후에야 깨닫게 됩니다. 너무도 많은 관리자가 오류가 발생한 뒤에야 백업 기술과 복원 절차가 실제로 작동하는지 알게 됩니다. 테스트하기 가장 좋은 때는 새 서버를 빌드하고 구성한 바로 다음 날입니다. 즉, 새 서버가 Exchange 구성의 일부로 실행되지만 이를 사용하는 사용자가 얼마 되지 않을 때가 적기라고 할 수 있습니다. 이때는 Exchange 전체 백업과 드라이브에 대한 정기 백업을 수행해야 합니다. 또한 시스템 디스크의 중요한 파일과 IIS 메타베이스(Exchange 라우팅 구성이 보관되는 곳)가 들어 있는 시스템 상태를 캡처해야 합니다. 그런 다음 새 서버를 다시 포맷하고 다시 시작하여 서버를 처음 빌드할 때 기록한 내용을 업데이트합니다. 이렇게 하면 시스템 상태에서 설정을 복원할 수 있을 뿐만 아니라 시스템 구성 설정을 수동으로 다시 구현할 수 있도록 적절한 문서도 마련할 수 있게 됩니다.
이 재난 대비 훈련에 투자한 시간은 향후 복구에 걸리는 시간을 대폭 줄여줄 것입니다. 이 절차를 정기적으로 반복하는 것이 좋습니다. 이 작업을 수행하는 동안 오프사이트에서 테이프를 가져오는 데 걸리는 시간을 생각해 보십시오. 끝이 없을 것 같은 이 시간을 겪어 본 사람은 대개 자신의 백업 및 복원 전략에서 디스크 대 디스크 백업이 얼마나 중요한지에 대해 진지하게 고려하게 됩니다. 오프사이트 테이프 저장소가 여전히 재해 복구를 위한 궁극적인 안전 장치임에도 불구하고 말이지요.
테이프 백업의 문제
테이프에서 복원하는 데는 너무 많은 시간이 소요됩니다. 이제 Exchange는 사용자와 관리자가 항상 사용할 수 있어야 할 만큼 조직에서 중요한 역할을 하게 되었습니다. 심각한 문제가 발생하면 대부분의 조직은 대혼란에 빠집니다. 누구도 테이프에서 75GB의 데이터베이스를 복원하는 데 8시간이 걸린다는 사실을 받아들이려 하지 않습니다. 여기에는 오프사이트 저장소 시설에서 테이프를 가져오거나 운영 체제를 다시 설치하는 데 걸리는 시간은 포함되어 있지 않은데도 말입니다.
또한 테이프에서 올바른 데이터베이스를 검색해야 하는 문제도 있습니다. Exchange가 처음 릴리스된 이후 10년 동안 디스크 저장소와 WAN의 비용도 많이 저렴해져 대부분의 조직은 더 빠른 백업 및 복원 방법을 사용할 수 있게 되었으며, Exchange 인프라에 대해 작업 연속성 및 재해 복구 기능을 사용할 수 있는 기술을 활용하는 것이 가능해졌습니다.
수준 2: 작업 연속성
작업 연속성이란 복구 작업을 최대한 빠르게 수행할 수 있도록 하고 예기치 않은 작동 중단 시간을 최소화하는 일련의 프로세스와 기술입니다. 로컬 복구의 경우 작업 연속성을 통해 테이프에 비해 향상된 RTO(복구 시간 목표)와 RPO(복구 시점 목표)를 달성할 수 있습니다. 또한 작업 연속성에서는 가능한 한 테이프를 온사이트로 가져오는 시간을 줄이기 위해 노력합니다. 그림 2를 보면 백업, 복원 및 DR(재해 복구)을 작업 연속성과 비교할 수 있습니다.
그림 2** 복구 연속선 **(더 크게 보려면 이미지를 클릭하십시오.)
이 다이어그램은 왼쪽 아래의 느리고 저렴한 방식부터 오른쪽 위의 빠르고 비용이 많이 드는 방식에 이르는 복구 및 가용성 옵션의 연속선을 보여 줍니다. 여기에서 작업 연속성과 재해 복구 솔루션 간의 전환 경계는 명확하지 않습니다.
이 그래프를 보면 각 접근 방법에 따르는 비용, 복구 시간 및 가용성을 쉽게 비교해 볼 수 있습니다. 이 문서에서 필자는 로컬 연속성 프로세스와 재해 복구를 의도적으로 명확하게 구분했는데, 그 이유는 DR이 항상 오프사이트의 데이터를 가져오는 것을 주요 목표로 하는 원격 작업으로 간주되기 때문입니다. 거리로 인해 추가적인 작업이 필요하고 일반적으로 비용이 많이 들기도 하는 DR은 재해가 발생한 후의 비즈니스 연속성과 관련됩니다. 이에 대해서는 나중에 보다 자세히 다루겠습니다.
간단한 역사
Exchange가 인프라의 보다 중요한 부분을 차지하게 되고 Exchange 데이터베이스에 더 많은 정보가 저장됨에 따라 백업 및 복원 시간을 줄여야 하는 필요성 또한 절실해졌습니다. 몇몇 대규모 조직은 Microsoft와 협력하여 부분적인 작업을 크게 개선하는 한 가지 방법을 발견하게 되었습니다. 이 방법을 사용하면 오류가 발생해도 외부 세계와 새 전자 메일을 계속해서 주고 받을 수 있으므로 아무 일도 없는 것처럼 보일 수 있습니다. 결국 중요한 것은 겉으로 보이는 사실입니다.
Exchange에 이러한 "다이얼톤" 복원을 구현하기 위해 손상된 데이터베이스 대신 비어 있는 새 데이터베이스를 배치했습니다. 그런 다음 Exchange와 Active Directory®에서 적절한 권한으로 새 사서함을 만들었으며 사용자는 아무 일도 없는 것처럼 전자 메일을 주고 받을 수 있었습니다. 백업 테이프를 검색하고 데이터를 복구하고 나서 이를 관리적으로 마운트할 수 있었으며, 다음에는 Exchange 관리자가 복원된 사서함을 다이얼톤 사서함에 병합했습니다. 필요한 경우 사서함의 우선 순위를 정할 수도 있었습니다. 이러한 개선에도 불구하고 이 프로세스는 처음에는 EXMERGE를 사용하고 그런 다음 복구 저장소 그룹에 적용되었으므로 시간이 많이 걸리고 복잡했습니다. 그런데 다이얼톤 복구 시나리오 후 전체 데이터 복원은 매우 힘들고 복잡한 작업이라는 점에 유의해야 합니다. 특히, Exchange 2007에서는 저장소 그룹을 최대 50개까지 사용할 수 있다는 점을 감안하면 더욱 그렇습니다. 따라서 다이얼톤 복구 시나리오를 구현할지 고려 중이라면 여기에 드는 시간과 노력에 비해 그 결과가 충분히 만족스러운지를 먼저 확인할 필요가 있습니다.
볼륨 섀도 복사본 서비스
저렴한 디스크를 활용하고 프로덕션 Exchange 서버에서 프로세서 오버헤드를 없애기 위해 Microsoft® Windows Server® 2003 및 Exchange용의 새로운 백업 API가 개발되었습니다. 데이터에 대한 일관된 지정 시간 복사본을 만들기 위해 VSS(볼륨 섀도 복사본 서비스)가 만들어졌습니다. 이 서비스에서 만들어진 스냅숏은 Exchange 데이터에 대한 읽기 전용 복사본으로, 변경된 데이터만 연속적으로 포함합니다. 이들 복사본은 대개 사용할 수 있는 디스크 공간이 있는 다른 서버 또는 SAN(저장 영역 네트워크)을 가리킵니다. 백업은 테이프에 저장하고, 스냅숏을 여러 개 유지할 수 있습니다. 따라서 프로덕션 Exchange 서버가 더 이상 백업 소프트웨어 및 테이프 복사 오버헤드로 인해 성능에 영향을 받지 않게 되었습니다.
Exchange 데이터 보호를 위해 VSS를 사용하는 경우 몇 가지 장점이 있습니다. 첫째, 테이프 백업 작업으로 인한 성능 로드를 Exchange 서버에서 줄일 수 있습니다. 테이프 백업을 여전히 수행해야 하기는 하지만 Exchange 데이터의 복사본을 사용할 수 있으므로 사용자 성능에는 영향을 주지 않습니다. 둘째, 야간에 한 번 백업할 때보다 자주 스냅숏을 만들 수 있습니다. 뿐만 아니라 보조 서버나 다른 로컬 저장소에 여러 개의 스냅숏을 보관할 수도 있습니다.
VSS 스냅숏 기능을 사용하는 많은 타사 제품이 시장에 출시되어 있습니다. 단순히 Exchange 데이터베이스를 백업 및 복원하는 데 걸리는 시간만 줄여주는 제품도 있고, Exchange에 포함된 기본 복구보다 세분화된 복구 기능을 제공함으로써 사서함 수준의 복원을 가능하게 하는 제품도 있습니다. 누구도 브릭 수준 백업과 같은 백업 방법을 선호하지는 않지만, 특정 폴더, 심지어는 메시지 하나만 복원할 수 있는 방법을 원하는 것도 사실입니다.
복제 기술
소프트웨어를 활용한 Exchange 장애 조치는 몇몇 복제 공급업체가 제공하는 방법입니다. 이 방법을 사용하는 경우 대기 Exchange 서버를 실행하고 모든 사용자의 사서함이 이동되었음을 Active Directory에 알려 줘야 합니다. 이를 달성하는 방법은 두 가지인데 어떤 방법을 사용하든 Exchange 및 Windows 환경을 어느 정도 사용자 지정해야 합니다. 첫 번째 방법에는 대기 서버가 오류가 발생한 서버의 이름과 IP 주소를 사용하도록 DNS를 조작하는 작업이 필요합니다. 이 경우 Outlook®이 여전히 동일한 서버를 사용하고 있는 것으로 인식하므로 이 방법은 클라이언트 워크스테이션에서 사용하기에 좋습니다.
두 번째 방법은 데이터베이스의 복사본만 있고 어떤 것도 마운트되어 있지 않은 Exchange를 실행하는 대기 서버를 사용합니다. 오류가 발생하면 대기 서버가 모든 사용자의 사서함이 이동되었음을 Active Directory에 알려 줍니다. 그런 다음에는 클라이언트가 다른 메일 서버에 있음을 클라이언트에게 알려 주는 스크립트를 실행하거나 그룹 정책을 배포합니다. Outlook 2007은 Active Directory를 인식하므로 이러한 매핑을 스스로 자동 인식하며, 따라서 이 프로세스가 훨씬 수월하게 수행됩니다.
MSCS를 사용한 로컬 클러스터링
Microsoft Cluster Services(MSCS)는 가용성 연속선상에서 상위에 위치하는 제품이며, Exchange는 클러스터를 인식하는 응용 프로그램입니다. 클러스터링은 둘 이상의 컴퓨터 간에 정보를 공유하므로 한 컴퓨터에서 오류가 발생하면 다른 컴퓨터가 작업을 대신 수행할 수 있습니다. 현재 사용되는 대부분의 Exchange 클러스터는 2개 또는 4개의 노드로 구성되며 최대 8개의 노드를 사용할 수 있습니다. 이 중 한 개의 노드는 항상 패시브로 지정되며, Windows Server를 실행하고 Exchange Server가 설치되어 있지만 활성 사서함은 없습니다. Exchange 2003에서는 2노드 액티브/액티브 클러스터를 구현하는 것이 가능했지만 성능 로드로 인해 현재는 권장되지 않으며 Exchange 2007에서는 지원되지 않을 것입니다.
Exchange 2003 클러스터 배열과 마찬가지로 패시브 노드가 포함된 Exchange 2007 클러스터도 단일 공유 저장소 배열을 계속해서 사용할 수 있습니다. 클러스터 품질의 저장소 배열은 일반적으로 다양한 유형의 장애에 견디기 위해 여러 가지 중복 기능을 갖추고 있기는 하지만 데이터의 복사본을 하나만 제공하므로 취약한 영역이 남아 있다고 할 수 있습니다. 이 때문에 이러한 클러스터는 SCC(단일 복사본 클러스터)라고 하며 Exchange 2007의 MCC(다중 복사본 클러스터)와 함께 제공될 차세대 데이터 보호 기술과 구별됩니다. MCC에 대해서는 재해 복구에 대해 살펴볼 때 설명하겠습니다.
로컬 연속 복제
LCR(로컬 연속 복제)은 Exchange 데이터베이스와 트랜잭션 로그의 두 번째 복사본을 동일한 서버 내에 유지하는 Exchange 2007의 새로운 기능입니다. LCR은 Exchange 데이터베이스와 트랜잭션 로그를 서로 별개의 RAID 배열에 배치하는 기존의 방법에 중복 계층을 추가로 제공합니다. LCR을 사용하면 로그의 보조 복사본을 데이터베이스의 주 복사본이 저장된 배열에 저장하고, 데이터베이스의 보조 복사본을 로그의 주 복사본이 저장된 배열에 저장할 수 있습니다(그림 3 참조). 이 경우 RAID 컨트롤러나 배열에서 오류가 발생하더라도 다른 배열에 데이터베이스와 트랜잭션 로그가 저장되어 있으므로 걱정할 필요가 없습니다. 다소 불안하고 성능도 약간 저하되긴 하지만 오류가 발생한 배열을 다시 빌드할 때까지 작업을 계속할 수 있습니다.
그림 3** LCR 구성 **
LCR은 백업 솔루션이 아니라 로컬 작업 연속성 솔루션이므로 전체 백업 전략이 여전히 필요합니다. LCR을 사용하는 경우 서버가 데이터베이스와 트랜잭션 로그의 복사본을 두 개씩 만들게 되므로 성능이 저하될 수도 있습니다. 또한 Exchange 2007 구현의 경우 LCR은 한 저장소 그룹에서 데이터베이스를 하나만 지원하고 한 조직에서 공용 폴더 데이터베이스를 하나만 지원하기 때문에 소규모 조직에만 적합하게 만드는 여러 가지 제약이 있습니다.
LCR 복구를 사용한 장애 조치는 즉각적이지 않습니다. 숙련된 IT 전문가가 스크립트를 실행하여 Exchange 백업을 가져와야 하며, 이 프로세스에는 Exchange 관리 콘솔 외부에서 실행되는 Exchange 관리 셸 명령이 필요합니다.
Exchange Server 2003 Enterprise Edition에서는 최대 20개의 Exchange 데이터베이스(각각 5개의 데이터베이스가 있는 네 개의 저장소 그룹)를 실행할 수 있으며 Exchange 2007 Enterprise Edition에서는 각각 고유한 데이터베이스를 갖춘 최대 50개의 저장소 그룹을 실행할 수 있습니다. 트랜잭션 로그 파일의 크기가 Exchange 2003에서는 5MB였지만 Exchange 2007에서는 1MB로 줄었습니다. 이러한 변경은 모두 LCR을 지원하기 위한 것이며 아울러 이와 어느 정도 연관성이 있는 CCR(클러스터 연속 복제)을 지원하기 위한 것입니다.
중소 규모의 조직은 LCR을 사용하여 Exchange 작업에 대한 데이터 보호를 개선할 수 있습니다. LCR은 구현하기가 쉽지만 수동 작업도 필요합니다. 동일 서버/로컬 디스크 솔루션으로서의 LCR은 더 나은 작업 연속성으로 나아가기 위한 첫 걸음에 불과합니다. LCR은 RAID 배열 및 RAID 컨트롤러의 오류로부터 데이터를 보호하지만 동시다발적으로 디스크의 작동이 중단되거나 RAID 컨트롤러에 오류가 발생하는 경우는 흔하지 않습니다. 대부분의 오류 시나리오에는 전체 서버가 중단되는 상황이 포함되며 이를 처리하기 위해 Exchange를 보호하기 위한 추가 단계가 필요합니다.
타사 로컬 오프 호스트 복제
Exchange의 복구 기능을 더욱 향상시키기 위해 타사 공급업체들은 Exchange 로그 파일을 사용하여 Exchange 데이터베이스의 예비 복사본을 다른 컴퓨터에 보관하는 "오프 호스트" 복제 기술을 활용하는 제품을 개발했습니다. 이 경우 데이터 보호 또는 보관 솔루션은 ESE를 통해 다른 컴퓨터에 Exchange 전체 백업을 수행한 다음 트랜잭션 로그가 닫히는 즉시 트랜잭션 로그를 가져옵니다. 그런 다음 이러한 트랜잭션을 Exchange 데이터베이스 복사본에 삽입하여 복사본을 항상 최신 상태로 유지합니다. 앞에서 설명했듯이 이러한 로그는 크기가 상대적으로 작습니다. Exchange 2003의 경우 5MB이고 Exchange 2007의 경우 1MB입니다. 따라서 전체 백업이 완료된 후 이러한 로그 파일을 오프 호스트 서버에 복사하는 데는 오버헤드가 거의 발생하지 않습니다.
수준 3: 재해 복구 및 고가용성
재해 복구란 주 데이터 센터가 사용 불가능해질 경우 이를 원상 복구하여 실행하는 능력을 말합니다. 요즘에는 대부분의 조직에서 전자 메일 및 일정 기능이 핵심 기능이기 때문에 Exchange에는 효과적인 재해 복구를 적용할 필요가 있습니다.
일부 회사는 오프사이트에 저장된 기존의 테이프 백업이 일종의 재해 복구라고 생각합니다. 그런데 화재나 홍수로 인해 유일한 데이터 센터가 훼손되고 테이프만 한 트럭 남는다면 아무 쓸모가 없을 것입니다. 재해 복구에는 데이터를 다른 위치로 이동하는 것뿐만 아니라 응용 프로그램을 원상 복구하여 실행하는 기술 및 프로세스가 포함되어야 합니다. 재해 복구가 효과적으로 이루어지기 위해서는 주 시스템과 보조 시스템을 일정한 거리를 두고 분리해야 합니다. 두 사이트의 거리는 대비해야 할 재해의 규모에 따라서 다릅니다. 화재가 우려된다면 구내의 다른 건물만으로도 충분합니다. 그러나 열차나 비행기로 인해 인프라 자체에 피해가 발생하는 경우에는 반경 1.5km 이상까지 영향을 받을 수 있습니다. 홍수, 폭풍우, 지진, 정전 등 대부분의 재해는 지역적입니다. 통신에도 고유의 재해가 발생할 수 있습니다. ISP에 대한 연결을 끊는 굴착기에서 DoS(서비스 거부) 공격, 그리고 주로 상거래 조직을 대상으로 하는 인터넷 DoS 공격에 이르기까지 다양한 재해가 발생할 수 있습니다.
현실적으로 조직에 IT 직원이 있는 사이트가 둘 이상이라면 대비하려는 재해의 유형에 관계없이 이러한 위치 중 하나는 원격 작업 연속성을 위한 고유의 기준을 만족했을 것입니다. 자체 설비와 직원을 활용하는 것이 재해 복구 공급업체와 계약을 맺거나 새 위치에 장소를 임대하는 것보다 비용이 훨씬 저렴합니다.
재해 복구는 궁극적으로는 인식과 관련된 것입니다. 즉, 비즈니스를 계속 수행하고 있다는 확신을 고객에게 심어주는 것입니다. 한 도시나 지역에서 재해가 발생했음을 사람들이 알고 있는데 회사가 며칠 또는 한 주 내에 온라인 상태로 복구되지 않으면 고객과 공급업체는 최악의 상황을 가정하게 됩니다. 즉, 재해로 인해 대부분의 회사가 정상적으로 운영되지 않는다고 믿게 됩니다. 고객에게는 작업이 복구되고 있는 것으로 보여야 합니다. 그래야만 비즈니스가 계속되고 있다고 확신시킬 수 있습니다. 시기 적절한 복구와 관련하여 고객은 여러 가지 생각을 가질 수 있습니다. 당연히 고객은 사무용 가구 공급업체의 업무가 중단될 때보다 금융 서비스 회사의 업무가 중단될 때 더 초조해할 것입니다.
재해 복구 요구 사항
재해 발생 후 Exchange를 다시 온라인 상태로 만들려면 Exchange 데이터를 보조 사이트에 복제해야 하며 이러한 데이터를 언제든지 실행할 준비가 되어 있는 Exchange 대기 서버에 제공하는 복제 기술을 사용해야 합니다. 그런 다음 Outlook 클라이언트에 사서함이 이동되었음을 알려야 합니다.
Exchange는 복제 시 요구 사항이 많은 응용 프로그램이며, 특히 사이트 간의 거리가 멀 때 더욱 그렇습니다. 또한 진정한 트랜잭션 데이터베이스라고 할 수 있으므로 각 쓰기의 순서가 매우 중요합니다. Exchange는 서버 간에 모든 트랜잭션과 시스템 정보를 전달하는 데 SMTP 프로토콜을 사용하며 이 전송 프로토콜은 잘 알려진 대로 대역폭을 매우 많이 사용합니다. 바로 이 때문에 문제가 더욱 복잡해집니다. 더 나아가 Exchange 클러스터의 경우 시스템 간 하트비트 간격이 500밀리초로 유지되어야 합니다. 보조 노드가 이 하트비트를 수신하지 않으면 장애 조치를 시작하도록 트리거할 수 있습니다.
이러한 문제를 관리하는 것이 복잡하기 때문에 Microsoft는 Exchange 2007에 와서야 이 분야에 관심을 기울이게 되었습니다. Microsoft가 개입하기 전까지는 호스트 기반 또는 배열 기반 복제를 통해 Exchange 데이터를 복제하는 몇몇 타사 솔루션이 개발되었습니다.
공급업체들은 노드를 여러 위치로 분산시켜 클러스터를 확장하는 클러스터 확장이라는 기술을 발견했습니다. 현재 클러스터 확장을 구현하는 가장 일반적인 방법은 범용 타사 데이터 복제 제품이나 Exchange 노드를 확장할 목적으로 설계된 제품을 사용하는 것입니다. MSCS를 사용하면 이러한 목적을 달성할 수 있지만 WAN을 사용하는 경우 서브넷 요구 사항이 꽤 까다롭습니다. 클러스터링의 복잡성과 원격 데이터 센터에 대한 고대역폭 연결을 안정적으로 제공하는 데 따르는 어려움으로 인해 재해 복구 시스템을 빌드, 유지 관리 및 정기적으로 테스트하는 데 드는 비용과 인력이 점점 증가하고 있습니다.
클러스터 연속 복제
Microsoft는 Exchange 2007에서 CCR(클러스터 연속 복제)을 도입하여 클러스터 지원을 더욱 확장했습니다. CCR은 Exchange 데이터베이스와 트랜잭션 로그의 복사본 두 개를 유지 관리하는 LCR의 능력을 확장하여 두 개의 클러스터 노드에 동일한 개념을 구현합니다. 재해 복구는 주 시스템과 보조 시스템을 지리적으로 분리하는 것을 의미하는데, Microsoft MCC(다중 복사본 클러스터)로는 먼 거리를 연결할 수 없으며 이 문제는 Windows Server 2008(이전의 코드 이름 "Longhorn")에서 클러스터 확장이 가능해져야만 해결됩니다.
MCC 노드에 별개의 데이터 복사본을 보관할 수 있게 해 주는 기술을 MNS(주 노드 집합)라고 합니다. MNS는 데이터의 활성 복사본을 보관할 노드를 결정하기 위해 둘 이상의 노드가 참여하는 경합 프로세스를 나타냅니다. 오류가 발생할 경우 나머지 노드가 새 주 처리/데이터 서버의 역할을 맡을 노드를 결정하기 위해 새로운 경합 프로세스에 참여합니다. 이러한 기술 민주주의를 지원하는 것이 바로 각 노드의 데이터베이스를 최신으로 유지하는 CCR입니다. CCR을 사용하는 Exchange 2007 클러스터에서는 노드가 2개까지만 지원됩니다.
대규모 조직에서는 대개 Exchange 서버 자체에 로컬 시스템 디스크를 구성하고 SCSI, 파이버 또는 iSCSI 디스크 배열을 사용하여 SAN을 통해 Exchange 데이터베이스에 연결합니다. MCC/MNS 클러스터를 사용하는 경우 최고급 Exchange 저장소가 각 노드의 로컬 RAID 배열을 사용하는 쪽으로 발전할 것인지와 같은 흥미로운 질문을 던져볼 수 있습니다. MNS 클러스터의 목적이 각 노드에 고유의 별도 저장소를 두는 것이라면, 각 노드가 공통 저장소를 제공하는 것이 주 목적인 SAN을 가리키도록 하는 것이 과연 의미가 있을까요?
가능한 절충 MCC/MNS 클러스터 시나리오는 저장소가 SAN에 있는 주 노드와, 로컬 디스크 또는 저렴한 iSCSI SAN이 있는 보조 클러스터 노드를 사용하는 것입니다. 이 보조 노드는 SAN 인프라가 없으며 주 데이터 센터와는 떨어진 위치에 둘 수 있습니다.
결과가 어떻든 MNS 및 CCR을 사용하는 MCC는 여러 컴퓨터에서 장애 조치를 수행할 수 있고 데이터가 별도의 저장소에 복제되므로 중복 계층과 가용성에서 또 다른 한 단계의 발전을 의미합니다. 하지만 이 방법도 Windows Server 2008이 출시되기 전까지는 단일 데이터 센터 내로 범위가 제한됩니다. Windows Server 2008은 기본적으로 클러스터 확장을 지원합니다. 따라서 노드 간 네트워크 지연이 500ms 미만을 안정적으로 유지하는 한 얼마든지 멀리 MNS 클러스터의 노드를 지리적으로 떨어뜨려 놓을 수 있습니다. 그때까지는, 그리고 그 이후에도 당분간 Microsoft MNS 및 CCR 대신 타사 클러스터 기술이 효과적인 재해 복구 솔루션이 되기 위해 클러스터를 확장하는 데 필요한 지리적 분리 기능을 제공할 것입니다.
클러스터링은 재해 복구 연속선상에서 최상위에 위치하는 기술이라고 할 수 있고 CCR은 Exchange의 고가용성 기능이라고 하는 것이 적절합니다. 또한 비용과 인력이 많이 들더라도 이 둘을 조합하면 같은 유형의 Microsoft 환경을 운영하려고 하는 고객에게 매우 흥미로운 최상의 솔루션이 될 것입니다.
타사 원격 작업 연속성
Microsoft 솔루션과 타사 확장 기술을 함께 사용할 수 있다면 복구 연속선에서 최상위를 차지하는 기술이 될 것이라는 점은 의심의 여지가 없습니다. 몇 초 내의 자동 장애 조치가 가능해질 것입니다. 이보다 좋을 수는 없겠지요. 그러나 모든 회사가 이런 수준의 가용성 및 비즈니스 연속성을 원하는 것은 아니며 이러한 연속성을 제공하기 위해 엄청난 비용을 투자할 만큼 여력이 있는 것도 아닙니다. 대부분의 회사는 몇 분 내에 Exchange를 완전하게 복원하는 안정적인 솔루션만으로도 작업 연속성을 위해 필요한 모든 것을 확보할 수 있습니다.
한 예로 Mimosa Systems, Inc.는 단일 데이터 센터 내의 작업 연속성을 원격 연속성으로 확장했습니다. 원격 위치에 있는 Mimosa DR에서는 Exchange의 복사본을 유지 관리하고, 주 Exchange 서버에서 제공한 트랜잭션 로그를 사용하여 이 복사본을 최신 상태로 유지하며, 이러한 라이브 복사본을 대기 Exchange 서버가 언제든지 사용할 수 있도록 준비하고 있습니다. 원격 Exchange 서버는 표준 서버 하드웨어를 사용하며, 단일 데이터 센터 구현과 마찬가지로 재해가 발생할 경우 언제든지 사용할 수 있도록 만반의 준비가 되어 있습니다. 재해가 발생하면 원격 사이트의 운영자가 장애 조치를 시작하여 대기 데이터베이스 파일을 마운트하고 사서함 및 Outlook 프로필을 다시 매핑하는 등의 장애 조치를 수행합니다. 그런데 이러한 타사 솔루션은 기술 자료 문서 "Exchange 데이터베이스 콘텐츠를 수정 또는 추출하는 타사 제품을 위한 Microsoft 지원 정책"에 정의되어 있는 항목에 대해서만 지원을 받을 수 있습니다.
결론
Exchange 데이터 보호는 비용 및 성능을 기준으로 세 수준으로 그룹화할 수 있는 일련의 기술 및 절차입니다. Exchange 데이터 보호에 대한 요구 사항을 고려할 때는 이해 당사자가 감내할 수 있는 작동 중단 시간을 검토해야 합니다. 성능이 우수하고 복구 속도가 빠를수록 비용이 많이 듭니다. 최고급 옵션의 경우에는 막대한 비용을 들여야 합니다. 최고 수준은 아니지만 그에 가까운 가용성을 제공하는 적정 가격의 솔루션도 있습니다. 따라서 조직의 실제 필요에 맞게 적절한 솔루션을 선택하는 것이 중요합니다.
Exchange 2007 서비스 팩 1
현재 베타 테스트 중인 Exchange 2007 SP1(서비스 팩 1)에는 OWA의 향상 기능, 콘솔의 추가 GUI 기능을 비롯하여 관리자들이 고대해 온 수많은 기능이 포함될 예정입니다.
복구 솔루션을 계획 중인 관리자에게 특히 흥미로운 소식은 Exchange 2007 SP1에는 LCR과 CCR을 보완하는 타사 가용성 솔루션인 SCR(보조 연속 복제)이 포함된다는 것입니다. 이는 중도적 접근 방법으로, Microsoft는 이 기술이 완전한 "고가용성." 기술과 관련된 복잡함 없이 보다 우수한 복구 기능을 제공할 것으로 보고 있습니다.
SCR을 사용하면 일반적으로 사서함이 있는 서버가 아닌 다른 Exchange 서버에 Exchange 데이터베이스 및 트랜잭션 로그를 복제할 수 있습니다. SCR의 대상은 로컬 또는 원격 모두 가능하며 대기 Exchange 서버나 클러스터가 될 수도 있습니다. 그러나 SCR은 로컬이나 원격에서 클러스터를 필요로 하지 않습니다. 또한 대기 환경을 대상으로 하며 장애 조치가 수동으로 이루어진다는 점에서 CCR과 다릅니다. 그런데 SCR을 사용할 경우에도 처음의 대용량 복사본, 즉 전체 백업을 네트워크를 통해 가져와야 한다는 점에 유의해야 합니다. 이 대규모 복제 작업을 빈번히 수행해야 할 수도 있습니다. 또한 CCR과 타사 솔루션을 사용할 때와 마찬가지로 네트워크가 받을 영향을 정확하게 인식하고 있어야 합니다. SCR과 CCR 및 비슷하거나 더 나은 기능을 제공하는 그 밖의 추가 제품이 널리 사용될 것으로 예상됩니다.
Lee Benjamin은 ExchangeGuy Consulting Services를 운영하면서 고객과 만나 업무를 처리하고 Microsoft 파트너에게 자문을 주기도 합니다. Lee는 세계에서 가장 규모가 큰 Exchange 사용자 그룹인 ExchangeServerBoston의 회장이자 BostonUserGroups의 의장이며, Exchange MVP 및 Microsoft Certified Trainer 겸 업계 회의의 정규 강연자이기도 합니다.
© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..