재해 복구 계획(SharePoint Server 2010)
적용 대상: SharePoint Foundation 2010, SharePoint Server 2010
마지막으로 수정된 항목: 2016-11-30
이 문서에서는 Microsoft SharePoint Server 2010 환경에 대한 재해 복구 전략을 선택하는 과정에 결정해야 할 주요 사항에 대해 설명합니다.
이 문서의 내용:
재해 복구 개요
재해 복구 전략 선택
정지 대기 계획
예열 대기 계획
상시 대기 데이터 센터 계획
재해 복구를 위한 시스템 요구 사항
재해 복구 개요
이 문서에서는 재해 복구를 SharePoint Server을 호스팅하는 데이터 센터를 사용할 수 없게 된 상황에서 복구할 수 있는 능력으로 정의합니다.
SharePoint Server에 대해 사용하는 재해 복구 전략은 Active Directory 도메인, Exchange Server 및 Microsoft SQL Server 같은 관련된 인프라에 대한 재해 복구 전략과 조화를 이루도록 해야 합니다. 따라서 사용하는 인프라의 관리자와 협력하여 적절한 조화를 이루는 재해 복구 전략 및 계획을 디자인합니다.
다른 위치에서 또 다른 팜을 실행하는 데 드는 시간과 즉각적인 노력을 대개 상시 대기, 예열 대기 또는 정지 대기라고 합니다. 여기서는 이러한 용어를 다음과 같이 정의하고 있습니다.
상시 대기 몇 초 또는 몇 분 내로 가용성을 제공할 수 있는 보조 데이터 센터입니다.
예열 대기 몇 분 또는 몇 시간 내로 가용성을 제공할 수 있는 보조 데이터 센터입니다.
정지 대기 몇 시간 또는 며칠 내로 가용성을 제공할 수 있는 보조 데이터 센터입니다.
재해 복구는 가장 많은 비용이 드는 시스템 요구 사항 중 하나일 수 있습니다. 장애 상태와 가용 상황 간의 간격이 짧고 보호할 시스템의 수가 많을수록 재해 복구 솔루션이 더 복잡해지고 비용이 증가할 가능성이 높습니다. 상시 대기 또는 예열 대기 데이터 센터에 투자하는 경우 비용에는 다음이 포함됩니다.
소프트웨어 응용 프로그램 간에 발생하는 작업의 복잡도를 높이는 추가 하드웨어 및 소프트웨어(예: 장애 조치 및 복구를 위한 사용자 지정 스크립트)
추가적인 운영 복잡성
상시 또는 예열 대기 데이터 센터의 유지 관리 비용은 특정 비즈니스 요구 사항을 토대로 산정해야 합니다. 재해 발생 후 솔루션에 요구되는 가용성 수준은 조직 내에서 솔루션마다 각기 다를 수 있습니다. 따라서 여러 콘텐츠, 서비스 또는 팜(예: 비즈니스에 영향을 주는 콘텐츠, 검색 서비스 또는 인터넷 게시 팜)에 대해 서로 다른 재해 복구 수준을 제공할 수 있습니다.
재해 복구는 고객 그룹의 기대치를 설정하기 위해 IT 그룹에서 SLA(서비스 수준 계약)를 제공하는 핵심 영역입니다. 많은 IT 조직에서는 여러 비용 부과 수준(chargeback)과 연결된 다양한 SLA를 제공합니다.
서버 팜 간에 장애 조치를 구현할 때는 먼저 팜 내에 핵심 솔루션을 배포 및 조정한 다음 재해 복구를 구현 및 테스트하는 것이 좋습니다.
재해 복구 전략 선택
비즈니스 요구 사항에 따라 많은 접근 방식 중에서 하나를 선택하여 SharePoint Server 환경에 대한 재해 복구를 제공할 수 있습니다. 다음 예에서는 기업에서 정지, 예열 또는 상시 대기 재해 복구 전략을 선택하는 이유를 보여 줍니다.
정지 대기 재해 복구 전략: 기업에서는 로컬 및 지역 오프사이트 저장소에 대한 완전 복구를 지원하기 위해 백업 파일을 주기적으로 전달하고 다른 지역에 비상 서버 임대 계약을 체결해 둡니다.
장점:
운영상 유지 관리 비용이 가장 저렴한 옵션입니다.
재해가 발생한 후 실제 서버를 올바르게 구성해야 하기 때문에 복구 비용이 많이 드는 옵션입니다.
단점: 복구 속도가 가장 느린 옵션입니다.
예열 대기 재해 복구 전략: 기업에서는 가상 서버 이미지를 로컬 및 지역 재해 복구 팜으로 전달합니다.
장점: 가상 서버 팜에는 복구 시 구성 노력이 거의 들지 않을 수 있기 때문에 복구 비용이 비교적 적게 듭니다.
단점: 유지 관리 비용과 시간이 많이 소요될 수 있습니다.
상시 대기 재해 복구 전략: 기업에서는 여러 데이터 센터를 운영하지만 하나의 데이터 센터를 통해서만 콘텐츠와 서비스를 제공합니다.
장점: 비교적 복구 속도가 빠릅니다.
단점: 구성 및 유지 관리 비용이 매우 많이 들 수 있습니다.
중요
환경에 대해 구현하기로 결정한 재해 복구 솔루션의 유형에 관계없이 일부 데이터가 손실될 가능성이 있습니다.
정지 대기 데이터 센터 계획
정지 대기 재해 복구 시나리오에서는 새 위치에 새 팜을 설정하고(가능하면 스크립트 배포 사용) 백업을 복원하는 방식으로 복구를 수행할 수 있습니다. 또는 컴퓨터 수준의 데이터를 보호하고 각 서버를 개별적으로 복원할 수 있도록 하는 Microsoft System Center Data Protection Manager 2007 같은 백업 솔루션에서 팜을 복원하여 복구를 수행할 수도 있습니다. 이 문서에서는 정지 대기 시나리오에서 만들기 및 복구를 수행하는 방법에 대한 자세한 지침은 다루지 않습니다. 자세한 내용은 다음을 참조하십시오.
예열 대기 데이터 센터 계획
예열 대기 재해 복구 시나리오에서는 팜에서 보조 위치로 전달하는 서버의 가상 이미지를 일관되게 자주 만들도록 하는 방식으로 예열 대기 솔루션을 만들 수 있습니다. 보조 위치에는 이미지를 손쉽게 구성 및 연결하여 팜 환경을 다시 만들 수 있는 환경이 마련되어 있어야 합니다.
이 문서에서는 예열 대기 솔루션을 만들기 위한 자세한 지침은 다루지 않습니다. 가상 솔루션을 사용하여 팜을 배포하는 방법에 대한 자세한 내용은 가상화 계획(SharePoint Server 2010)을 참조하십시오.
상시 대기 데이터 센터 계획
상시 대기 재해 복구 시나리오에서는 장애 조치 팜을 설정하여 기본 팜에서 별도의 데이터 센터에 재해 복구를 제공할 수 있습니다. 별도의 장애 조치 팜을 사용하는 환경의 특징은 다음과 같습니다.
별도의 구성 데이터베이스 및 중앙 관리 콘텐츠 데이터베이스를 장애 조치 팜에서 유지 관리해야 합니다.
모든 사용자 지정 내용을 두 팜에 모두 배포해야 합니다.
참고
스크립트 배포를 통해 동일한 구성 설정 및 사용자 지정 내용을 사용하는 방식으로 기본 및 장애 조치 팜을 만드는 것이 좋습니다. 자세한 내용은 Windows PowerShell을 사용하여 SharePoint Server 2010 설치를 참조하십시오.
업데이트는 두 팜에 모두 개별적으로 적용해야 합니다.
SharePoint Server 콘텐츠 데이터베이스에서는 비동기식 미러링을 수행하거나 장애 조치 팜으로 로그를 전달할 수 있습니다.
참고
SQL Server 미러링은 여러 데이터베이스를 단일 미러 서버에 복사하는 데만 사용할 수 있지만 여러 보조 서버로 로그를 전달할 수 있습니다.
서비스 응용 프로그램은 해당 응용 프로그램에서 팜으로 로그를 전달할 수 있는지 여부에 따라 달라집니다. 자세한 내용은 이 문서의 뒷부분에서 데이터 센터 간의 서비스 응용 프로그램 중복을 참조하십시오.
하나 이상의 추가 데이터 센터로 SQL Server 로그를 전달하도록 구성한 경우 이 토폴로지를 많은 데이터 센터에 걸쳐 반복할 수 있습니다.
SAN 공급업체와 상의하여 여러 데이터 센터에 걸쳐 가용성을 제공하기 위해 SAN 복제를 사용할 것인지 또는 지원되는 다른 메커니즘을 사용할 것인지 결정합니다.
다음 그림에서는 장애 조치 전의 기본 팜과 장애 조치 팜을 보여 줍니다.
장애 조치 전의 기본 팜 및 장애 조치 팜
.gif "장애 조치(Failover) 전의 기본 팜 및 장애 조치 팜")
데이터 센터 간의 서비스 응용 프로그램 중복
서비스를 팜 간에 실행할 수 있고 여러 데이터 센터에 걸쳐 서비스 응용 프로그램에 대한 가용성을 제공하려는 경우 기본 데이터 센터와 보조 데이터 센터 모두에서 액세스할 수 있는 별도의 서비스 팜을 실행하는 것이 좋습니다.
서비스를 팜 간에 실행할 수 없고 서비스 팜 자체에 대한 가용성을 제공하려는 경우에는 여러 데이터 센터에 걸쳐 서비스 응용 프로그램에 대한 중복을 제공하기 위해 다양한 전략을 사용할 수 있습니다. 사용되는 전략은 다음에 따라 달라집니다.
재해 복구 팜에서 사용되지 않는 서비스 응용 프로그램을 실행하는 것이 비즈니스적인 가치가 있습니다.
서비스 응용 프로그램과 연결된 데이터베이스에서 로그를 전달하거나 비동기식 미러링을 수행할 수 있습니다.
서비스 응용 프로그램을 읽기 전용 데이터베이스에 대해서만 실행할 수 있습니다.
다음 섹션에서는 각 서비스 응용 프로그램에 대해 권장되는 재해 복구 전략을 소개합니다. 서비스 응용 프로그램은 전략별로 그룹화되어 있습니다.
로그를 전달하거나 비동기식 미러링을 수행할 수 있는 데이터베이스
서비스 응용 프로그램을 보조 팜에 처음 배포하고 나면 다음 서비스 응용 프로그램을 지원하는 데이터베이스에서는 비동기식 미러링을 수행하거나 팜으로 로그를 전달할 수 있습니다.
Managed Metadata Service 응용 프로그램
데이터베이스: Managed Metadata Service
참고
태그 지정 기능을 사용하는 경우 재해 복구 팜에서 Managed Metadata Service 응용 프로그램을 정상적으로 사용하려면 SharePoint Administration Toolkit에 포함된 User Profile Replication Engine을 실행해야 합니다. 자세한 내용은 User Profile Replication Engine 개요(SharePoint Server 2010)를 참조하십시오.
PerformancePoint Services
데이터베이스: PerformancePoint Service 응용 프로그램
Project Server 서비스 응용 프로그램
데이터베이스: 임시, 게시된, 보관 및 보고
Project Server 2010을 사용하려면 해당 데이터베이스 간에 동기화를 수행해야 합니다. Project Server는 비동기식 복제 메커니즘(비동기식 데이터베이스 미러링, 로그 전달 또는 비동기식 SAN 복제)을 사용하여 팜 간에 복제할 수 있지만 복구를 수행하려면 복원할 때 프로젝트 데이터베이스 로그가 동기화되어 있어야 합니다.
참고
Project Server 데이터베이스에서 재해 복구 팜에 대해 로그를 전달하거나 미러링하는 것이 좋지만 Project Server 서비스 응용 프로그램은 읽기 전용 데이터베이스에 대해서는 실행할 수 없습니다. 따라서 장애 조치가 끝날 때까지는 재해 복구 팜에서 Project Server 서비스 응용 프로그램을 실행하지 않는 것이 좋습니다. 재해 복구 팜에서 Project Server 데이터베이스를 성공적으로 동기화하려면 데이터베이스에 대해 타임스탬프나 로그 표시를 구성해야 합니다.
Secure Store Service 응용 프로그램
데이터베이스: 보안 저장소
Usage and Health Data Collection 서비스 응용 프로그램
데이터베이스: 로깅
참고
로깅 데이터베이스에서도 로그를 전달하거나 미러링을 수행할 수 있지만, Usage and Health Data Collection 서비스를 재해 복구 팜에서 실행하는 것은 권장되지 않으며 로깅 데이터베이스에서는 로그를 전달하거나 미러링을 수행하지 않는 것이 좋습니다.
Web Analytics Service 응용 프로그램
데이터베이스: 준비 및 보고
참고
Web Analytics 준비 및 보고 데이터베이스에서는 로그를 전달하거나 미러링하는 것이 좋지만 Web Analytics Service 응용 프로그램은 장애 조치가 끝날 때까지 재해 복구 팜에서 실행하지 않는 것이 좋습니다.
로그를 전달하거나 비동기식 미러링을 수행할 수 없는 서비스 응용 프로그램 및 데이터베이스
다음 서비스 응용 프로그램은 기본 팜과 장애 조치 팜에 모두 배포해야 하며 로그를 전달하거나 비동기식 미러링을 수행할 수 없습니다. 이러한 서비스 응용 프로그램의 대부분에 대해서는 서비스 응용 프로그램을 배포한 다음 장애 조치 팜의 구성 설정이 기본 팜과 동일한지 확인하는 것이 좋습니다. 기본 팜에서 서비스에 영향을 주는 구성 변경 사항이 발생하는 경우 장애 조치 팜을 업데이트해야 합니다.
Application Registry Service 응용 프로그램
데이터베이스: Application Registry Service
Application Registry Service 데이터베이스에서는 로그 전달이 지원되지 않습니다.
Business Data Connectivity Service Application
데이터베이스: 비즈니스 데이터 연결
User Profile Service 응용 프로그램
데이터베이스: 프로필, 동기화, 공유 태그 지정
프로필, 동기화 및 공유 태그 데이터베이스에서는 로그를 전달할 수 없습니다.
User Profile Service 응용 프로그램에 대한 중복을 제공하려면 먼저 기본 데이터 센터와 보조 데이터 센터에 모두 해당 서비스 응용 프로그램을 배포해야 합니다.
프로필 및 동기화 데이터베이스를 설정하려면 데이터베이스의 백업을 보조 데이터 센터로 복구한 다음 이를 해당 데이터 센터의 User Profile Service 응용 프로그램에 연결하는 것이 좋습니다.
프로필을 동기화된 상태로 유지하려면 기본 팜에서 프로필 데이터를 업데이트한 후 64비트 SharePoint Administration Toolkit에 포함된 User Profile Replication Engine을 실행해야 합니다. 자세한 내용은 User Profile Replication Engine 개요(SharePoint Server 2010)를 참조하십시오.
Microsoft SharePoint Foundation 가입 설정 서비스 응용 프로그램
데이터베이스: 가입
참고
가입 설정 데이터베이스에서는 로그 전달이 지원되지 않습니다.
Access Services
데이터베이스: 없음
Excel Services
데이터베이스: 없음
검색
데이터베이스: 크롤링, 속성 및 검색 관리
검색을 수행하려면 해당 데이터베이스와 인덱스를 완전히 동기화해야 합니다. 이러한 요구 사항으로 인해 비동기 복제 메커니즘(비동기식 데이터 미러링, 로그 전달 또는 비동기식 SAN 복제)을 사용하여 팜 간에 검색을 복제할 수 없습니다.
장애 조치 팜에 최신 검색 내용을 제공하려면 검색을 보조 팜에서 실행해야 합니다.
중요
장애 조치 팜의 Search Service 응용 프로그램은 보조 팜을 적극적으로 크롤링하도록 설정해야 합니다. 장애 조치 시에는 장애 조치 Search Service 응용 프로그램을 사용하도록 웹 응용 프로그램 연결을 구성해야 합니다.
State Service
데이터베이스: 상태
참고
상태 데이터베이스에서는 로그 전달이 지원되지 않습니다.
Visio Services
데이터베이스: 없음
Word Automation Services
데이터베이스: Word Automation Services
Word Automation Services 데이터베이스에서는 로그 전달이 지원되지 않습니다.
재해 복구를 위한 시스템 요구 사항
이상적인 시나리오에서는 장애 조치 구성 요소와 시스템이 모든 면(플랫폼, 하드웨어, 서버 수)에서 기본 구성 요소 및 시스템과 일치합니다. 최소한 장애 조치 환경에서는 장애 조치 중 예상되는 트래픽을 처리할 수 있어야 합니다. 장애 조치 사이트에서는 일부 사용자에게만 서비스를 제공합니다. 시스템은 최소한 다음 조건이 일치해야 합니다.
운영 체제 버전 및 모든 업데이트
SQL Server 버전 및 모든 업데이트
SharePoint 2010 제품 버전 및 모든 업데이트
이 문서에서는 주로 SharePoint 2010 제품의 가용성을 논의하지만 시스템 가동 시간은 시스템의 다른 구성 요소로부터 영향을 받기도 합니다. 특히 다음을 수행해야 합니다.
전력, 냉각, 네트워크, 디렉터리 및 SMTP와 같은 인프라 종속성이 완전히 중복되어 있는지 확인합니다.
DNS 또는 하드웨어 부하 분산 방식에 상관없이 요구를 만족하는 전환 메커니즘을 선택합니다.