SharePoint Server의 재해 복구 전략 선택
적용 대상:
2013 2016 2019 Subscription Edition 
SharePoint in Microsoft 365
재해 복구는 SharePoint Server 팜을 호스트하는 기본 데이터 센터가 계속 작동할 수 없는 상황에서 복구하는 기능으로 정의합니다. 이벤트의 성격 및 해당 원인에 관계없이 데이터 센터 작동 중단은 조직의 재해 복구 계획에 정의된 조치를 취할 만큼 충분히 심각한 일입니다. 즉, 해당 이벤트의 영향을 받지 않는 데이터 센터에 있는 컴퓨터 리소스를 사용하여 완전히 작동하는 팜을 프로덕션으로 이동하게 됩니다.
SharePoint Servers 2019, 2016, 2013 및 지원되는 SQL Server는 재해가 발생한 경우 비즈니스에 필요한 RTO(복구 시간 목표) 및 RPO(복구 지점 목표)를 충족할 수 있는 구성 및 콘텐츠 복구 옵션을 제공합니다. 이러한 재해 복구 개념 및 기타 재해 복구 개념에 대한 자세한 내용은 SharePoint Server의 고가용성 및 재해 복구 개념을 참조하세요.
소개
SharePoint Server 팜에 대한 효과적인 재해 복구 전략은 일반적으로 RTO(복구 시간 목표) 및 RPO(복구 지점 목표)의 두 가지 측정값을 사용하여 표현되는 조직의 비즈니스 요구 사항을 충족하기에 충분해야 합니다. RTO 및 RPO 요구 사항은 재해가 발생할 경우 조직에서 발생하는 가동 중지 비용을 확인하여 파악합니다.
중요
가장 좋은 방법은 재해 복구 전략을 개발하고 기술 솔루션을 구현하기 전에 조직의 RTO 및 RPO를 명확히 파악하고 정량화하는 것입니다. 또한 수행 방법보다는 요구 사항에 초점을 맞추어야 합니다.
가동 중지 시간 비용은 특히 가동 중지 시간의 다양한 영향으로 인해 산업 내에서 크게 달라집니다. 비즈니스 규모가 가장 확실한 요소입니다. 그러나, 그것은 유일한 것은 아니다. 측정값을 설정하는 것은 실패의 특성과 의미를 설정하는 것을 의미합니다. 가장 간단한 수준으로 감소하면 중요한 애플리케이션이 실패하면 다음과 같은 유형의 손실이 발생할 수 있습니다.
응용 프로그램 서비스의 손실. 가동 중지의 효과는 응용 프로그램 및 업무마다 다릅니다.
데이터 손실. 시스템 중단으로 인한 잠재적인 데이터 손실은 심각한 법적 및 금전적 영향을 미칠 수 있습니다.
대부분의 조직에서는 앞서 나온 두 가지 손실 유형으로 인해 가동 중지 비용이 발생하지만 업무 성격에 따라 가장 큰 영향을 주는 손실 유형이 결정됩니다. eWEEK의 Chris Preimesberger가 작성한 다음 문서에서는 데이터 센터 가동 중지의 금전적 영향을 중점적으로 다룹니다. 계획되지 않은 IT 가동 중지 시간은 분당 $5K의 비용이 들 수 있습니다. 보고서.
대부분의 시나리오에서 SharePoint 제품은 재해로 자격이 있는 데이터 센터 종료 시 복구해야 하는 여러 애플리케이션 중 하나입니다. 이러한 이유로 재해 복구 계획에 대한 정보는 포함되지 않았지만 다른 위치에서 SharePoint Server 팜을 복구할 수 있도록 하는 옵션에 중점을 두고 있습니다.
재해의 유형 및 규모에 관계없이, 복구 중에는 팜을 복구할 수 있는 대기 데이터 센터를 사용하게 됩니다.
대기 데이터 센터 복구 옵션
대기 데이터 센터는 기본 데이터 센터의 작동 중단을 로컬 중복 시스템 및 백업으로 복구할 수 없는 경우에 필요합니다. 다른 위치에서 대체 팜을 작동 및 실행하는 데 드는 시간과 즉각적인 노력을 핫, 웜 또는 콜드 대기로 지칭하기도 합니다. Microsoft는 이러한 팜 복구 데이터 센터를 다음과 같이 정의하고 있습니다.
콜드 대기. 시간 또는 일 단위로 가용성을 제공할 수 있는 보조 데이터 센터
웜 대기. 분 또는 시간 단위로 가용성을 제공할 수 있는 보조 데이터 센터
핫 대기. 초 또는 분 단위로 가용성을 제공할 수 있는 보조 데이터 센터
이러한 각 대기 데이터 센터는 고유한 특징 및 요구 사항을 가지며 작동하고 유지 관리하는 데 드는 비용도 다릅니다.
콜드 대기 재해 복구 전략: 기업은 완전 복구를 지원하기 위해 로컬 및 지역 오프사이트 저장소로 백업을 전달하고, 다른 지역의 긴급 서버 대여를 위해 계약을 합니다.
프로: 운영적으로 유지 관리하는 가장 저렴한 옵션인 경우가 많습니다. 재해가 발생한 후 물리적 서버를 올바르게 구성해야 하므로 복구하는 데 비용이 많이 드는 옵션인 경우가 많습니다.
단점: 복구 속도가 가장 느립니다.
Azure 사이트 복구를 이용해 예비 재해 복구 전략을 준비합니다.
Pros: 가상 서버 팜은 복구 시 구성을 거의 필요로 하지 않으므로 복구 비용이 꽤 저렴합니다.
Cons: 유지 관리하는 데 시간과 비용이 많이 소요될 수 있습니다.
핫 대기 재해 복구 전략: 업무는 여러 데이터 센터에서 실행되지만 콘텐츠 및 서비스는 하나의 데이터 센터를 통해서만 처리됩니다.
Pros: 복구하는 데 빠른 편입니다.
Cons: 구성 및 유지 관리 비용이 비쌀 수 있습니다.
중요
이전에 어떤 재해 복구 솔루션을 적용하기로 결정했는지에 관계없이 어느 정도의 데이터 손실은 발생할 수 있습니다.
콜드 대기 복구
콜드 대기 재해 복구 시나리오에서는 새 위치에 새 팜을 설정하고(바람직하게는 스크립팅된 배포를 사용하여) 백업을 복원하여 복구합니다. 또는 System Center - DPM(Data Protection Manager)과 같은 백업 솔루션을 사용하여 팜을 복원하여 복구할 수 있습니다. DPM은 컴퓨터 운영 체제 수준에서 데이터를 보호하고 각 서버를 개별적으로 복원할 수 있도록 합니다. 이 문서에는 콜드 대기 시나리오에서 만들고 복구하는 방법에 대한 자세한 지침이 포함되어 있지 않습니다. 자세한 내용은 다음 항목을 참조하세요.
웜 대기 복구
웜 대기 재해 복구 시나리오에서는 대체 데이터 센터에 중복 팜을 만들어 웜 대기 환경을 만들고 기본 팜의 전체 및 증분 백업을 사용하여 정기적으로 업데이트되도록 합니다.
가상 웜 대기 환경
가상화는 웜 대기 복구 솔루션에 대한 실행 가능한 비용 효율적인 옵션을 제공합니다. Hyper-V를 사내 솔루션으로 사용하거나 Azure를 호스트된 솔루션으로 사용하여 복구에 필요한 인프라를 제공할 수 있습니다. 자세한 내용은 Azure에서 SQL Server Always On 가용성 그룹을 사용하여 SharePoint Server 배포를 참조하세요.
핫 대기 복구
핫 대기 복구 시나리오에서는 기본 팜이 오프라인 상태가 되는 즉시 프로덕션 작동이 진행될 수 있게 대기 데이터 센터의 장애 조치(failover) 팜을 설정합니다. 별도의 장애 조치(failover) 팜이 있는 환경은 다음과 같은 특성을 갖습니다.
별도의 구성 데이터베이스와 SharePoint 중앙 관리 웹 사이트 콘텐츠 데이터베이스가 장애 조치(failover) 팜에서 유지 관리되어야 합니다.
모든 사용자 지정 내용이 두 팜에 배포되어야 합니다.
팁
두 팜 간에 일관성이 유지되고 오류 가능성이 줄어듭니다. 스크립트된 배포를 사용하여 동일한 구성 설정 및 사용자 지정으로 기본 및 장애 조치(failover) 팜을 만드는 것이 좋습니다.
운영 체제, SQL Server 및 SharePoint Server 소프트웨어 업데이트를 두 팜에 모두 적용하여 일관된 구성을 유지해야 합니다.
비동기 미러링, 가용성 그룹 복제본에 대한 비동기 커밋 또는 로그 전달을 사용하여 SharePoint Server 콘텐츠 데이터베이스를 장애 조치(failover) 팜에 복사할 수 있습니다.
참고
SQL Server 미러링은 데이터베이스를 단일 미러 서버로 복사하는 데만 사용할 수 있지만 로그 전달 기능은 여러 보조 서버에 전달하는 데 사용할 수 있습니다.
SQL Server 데이터베이스 미러링 기능은 이후 버전에서 제거됩니다. 새 배포에서 이 기능을 사용하지 않는 것이 좋습니다. 현재 이 기능을 사용하는 응용 프로그램을 변경하세요. 대신 Always On 가용성 그룹을 사용합니다.
서비스 응용 프로그램은 팜에 로그 전달될 수 있는지 여부에서 차이가 있습니다. 자세한 내용은 이 문서의 뒷부분에 있는 서비스 애플리케이션 중복성을 참조하세요.
하나 이상의 추가 데이터 센터에 대해 SQL Server 로그 전달을 구성할 경우 핫 대기 팜 토폴로지를 둘 이상의 데이터 센터에서 반복할 수 있습니다.
중요
사용 가능한 네트워크 대역폭 및 대기 시간은 재해 복구를 위해 장애 조치(Failover) 방법을 사용할 때 주요 고려 사항입니다. SAN 공급업체와 상의하여 SQL 데이터베이스에 SAN 복제를 사용할 수 있는지 또는 지원되는 다른 메커니즘을 사용하여 데이터 센터에서 핫 대기 수준의 가용성을 제공할 수 있는지 확인하는 것이 좋습니다. SharePoint 서버에 SAN 복제를 사용하는 것은 지원되지 않습니다.
서비스 응용 프로그램 중복성
여러 데이터 센터에서 서비스 응용 프로그램 가용성을 제공하려면 팜 간에 실행될 수 있는 서비스의 경우 기본 및 보조 데이터 센터 둘 다에서 액세스할 수 있는 별도의 서비스 팜을 실행하는 것이 좋습니다.
팜 간에 실행될 수 없는 서비스의 경우 서비스 팜 자체의 가용성을 제공하기 위해 데이터 센터 간에 서비스 응용 프로그램에 대한 가용성을 제공하는 전략이 다양합니다. 사용되는 전략은 다음에 따라 달라집니다.
사용되고 있지 않은 서비스 응용 프로그램을 재해 복구 팜에서 실행할 경우 업무 가치가 높습니다.
서비스 응용 프로그램과 연결된 데이터베이스는 비동기 커밋을 사용하여 로그 전달되거나, 비동기식으로 미러링되거나, 복제될 수 있습니다.
읽기 전용 데이터베이스에서 서비스 응용 프로그램을 실행할 수 있습니다.
웜 또는 핫 대기 데이터 센터를 사용하는 재해 복구 솔루션을 디자인하기 전에 SharePoint 데이터베이스에 대해 지원되는 고가용성 및 재해 복구 옵션 문서를 검토하세요.
복구를 위한 시스템 요구 사항
이상적인 시나리오에서 장애 조치(failover) 구성 요소 및 시스템은 플랫폼, 하드웨어, 서버 수 등의 모든 측면에서 기본 구성 요소 및 시스템과 일치합니다. 적어도 장애 조치(failover) 환경은 장애 조치(failover) 중에 예상되는 트래픽을 처리할 수 있어야 합니다. 장애 조치(failover) 사이트를 반드시 사용해야 하는 대상을 일부 사용자로만 국한해야 합니다. 시스템의 다음 사항은 반드시 일치해야 합니다.
운영 체제 버전 및 모든 업데이트
SQL Server 버전 및 모든 업데이트
SharePoint Server 버전 및 모든 업데이트
팜 복구 시간은 이전 요구 사항 외에 시설의 가용성과 인프라 구성 요소에 의해서도 영향을 받습니다. 다음 조건이 충족되었는지 확인하세요.
전력, 냉각, 네트워크, 디렉터리 및 SMTP가 완전히 중복되는지 여부
전환 메커니즘 선택: DNS 또는 하드웨어 부하 분산이 요구를 충족하는지 여부
참고 항목
개념
SharePoint Server의 고가용성 및 재해 복구 개념
기타 리소스
Azure Site Recovery로 어떤 워크로드를 보호할 수 있습니까?
Azure Site Recovery를 사용하여 재해 복구용 다층 계층 SharePoint 응용 프로그램 복제