내보내기(0) 인쇄
모두 확장

가용성 계획(Office SharePoint Server)

업데이트: 2009-04-23

이 문서에서는 SharePoint 제품 및 기술 환경의 일반적인 가용성, 비용 및 가용성 관련 문제점과 환경에서 사용할 수 있는 전략 및 솔루션에 대해 설명합니다. 팜에서 Microsoft Office SharePoint Server 2007을 실행 중인 경우에는 이 문서를 읽어야 합니다. 이 문서와 함께 제공되는 Office SharePoint Server 2007 가용성 모델(영문)(http://go.microsoft.com/fwlink/?linkid=122369&clcid=0x412)을 다운로드 및 인쇄할 수도 있습니다. 이 모델에서는 이 문서의 콘텐츠를 포스터 크기로 요약하여 제공합니다.

가용성 개요

가용성은 사용자가 SharePoint 제품 및 기술 환경을 사용 가능하다고 인식하는 수준입니다. 가용성을 보장한다는 것은 시스템을 복원 가능한 상태로 유지하는 것입니다. 즉, 서비스에 영향을 주는 사고의 발생 빈도를 줄이고, 사고가 발생하는 경우에는 효율적인 조치를 제때 취해야 합니다. 가용성 전략을 사용하면 계획되거나 계획되지 않은 가동 중지 시간을 사용자가 최소한으로 인식하도록 할 수 있습니다.

가용성은 보통 9의 개수로 표현되는 가동 시간 백분율로 측정합니다. 이는 지정된 시스템이 활성 상태이며 작동되는 시간을 백분율로 나타내는 것입니다. 예를 들어 가동 시간 백분율이 99.999인 시스템의 경우 가용성이 '9가 5개'라고 할 수 있습니다.

다음 표에는 9의 개수와 그에 해당하는 실제 시간이 나와 있습니다.

적절한 가동 시간 백분율 일간 가동 중지 시간 월간 가동 중지 시간 연간 가동 중지 시간

95

72.00분

36시간

18.26일

99

14.40분

7시간

3.65일

99.9

86.40초

43분

8.77시간

99.99

8.64초

4분

52.60분

99.999

0.86초

26초

5.26분

전체 가동 중지 시간을 합리적으로 예측할 수 있다면 아래 수식을 사용하여 연간, 월간 또는 주간 가동 시간 백분율을 계산할 수 있습니다.

% 가동 시간/년 = 100 - (8760 - 연간 총 가동 중지 시간)/8760

% 가동 시간/월 = 100 - ((24 * 해당 월의 일 수) - 해당 월의 총 가동 중지 시간)/(24 * 해당 월의 일 수)

% 가동 시간/주 = 100 - (168 - 해당 주의 총 가동 중지 시간)/168

가용성과 동일시하면 안 되는 개념

가용성은 데이터 보호 및 복구나 재해 복구가 아닙니다. 그러나 이러한 개념은 가용성과 관련이 있으며, 모든 고가용성 시스템에는 데이터 보호 및 재해 복구 계획이 마련되어 있어야 합니다. 데이터 보호 및 복구는 다음과 같은 특정 비즈니스 요구 사항의 기본이 되는 일반 비즈니스 요구 사항입니다.

  • 여러 버전의 항목 또는 사이트를 보관하고 검토 가능

  • 실수로 삭제된 항목 또는 사이트 복구

  • 법적, 규정 또는 업무상의 이유로 데이터 보관

  • 예기치 않은 하드웨어 또는 소프트웨어 장애 발생 시 시스템 복원

또한 가용성은 BCM(비즈니스 연속성 관리)이 아닙니다. BCM은 위기 상황을 처리하기 전에 미리 준비해 두는 업무상의 결정 사항, 프로세스 및 도구입니다. 위기 상황은 특정 지역에서 또는 국가 전체에서 발생할 수도 있고, 특정 업무에만 관련되어 있을 수도 있습니다.

SharePoint 기술 및 제품 가용성과 데이터 보호 관리 전략은 기술 BCM 계획의 일부분일 수 있지만, 전체 BCM 계획은 다음과 같은 요소를 포함하는 훨씬 포괄적인 계획입니다.

  • 명확하게 문서화된 절차

  • 주요 비즈니스 레코드의 오프사이트 저장소

  • 명확하게 지정된 연락처

  • 지속적인 직원 교육

  • 오프사이트 복구 메커니즘

가용성 관련 비용

가용성은 비용이 많이 드는 시스템 요구 사항 중 하나입니다. 가용성 수준이 높고 보호할 시스템 수가 많을수록 가용성 솔루션이 더 복잡해지고 비용이 증가할 가능성이 높습니다. 가용성에 투자하는 경우 다음과 같은 비용이 발생합니다.

  • 보통 장애 조치 및 복구용 사용자 지정 스크립트와 같은 소프트웨어 간의 복잡한 작업을 포함하는 추가 하드웨어 및 소프트웨어

  • 추가적인 운영 복잡성

가용성을 확보하는 데 드는 비용은 비즈니스 요구 사항에 기반하여 평가해야 합니다. 조직 내 모든 솔루션에 동일한 수준의 가용성이 필요한 것은 아닙니다. 여러 사이트, 서비스(예: 검색 및 비즈니스 인텔리전스) 또는 팜에 서로 다른 수준의 가용성을 제공할 수 있습니다.

가용성은 고객 그룹의 기대치를 설정하기 위해 IT(정보 기술) 그룹에서 SLA(서비스 수준 계약)를 제공하는 핵심 영역입니다. 대부분의 IT 조직은 여러 비용 부과 수준(chargeback)과 연결된 다양한 SLA를 제공합니다.

참고참고:

대부분의 조직에서는 가용성을 계산할 때 계획된 유지 관리 작업 시간을 구체적으로 제외하거나 추가합니다.

SharePoint 제품 및 기술의 가용성 관련 문제점

SharePoint 제품 및 기술 배포에서는 가용성 제공과 관련하여 다음과 같은 문제가 발생할 수 있습니다.

  • 패치를 적용하거나 팜을 업그레이드하는 동안 팜을 사용할 수 없습니다.

  • 여러 서버에 인덱스 역할을 설치하여 인덱스 서버 중복을 구현할 수 없습니다. 인덱스 서버의 손실을 막으려면 서버를 다시 설치하고 백업에서 복원하거나 검색이 콘텐츠를 다시 크롤링하는 동안 약간 오래된 결과를 사용해야 합니다. 그렇지 않으면 팜 내의 검색 가용성팜 간의 검색 가용성 섹션에서 설명하는 기술 중 하나를 사용하여 검색을 복구하는 데 걸리는 시간을 줄일 수도 있습니다.

  • SharePoint 제품 및 기술은 Microsoft SQL Server 2005 데이터베이스 미러링을 인식하지 못합니다. SharePoint의 가용성 기술로는 SQL Server 미러링을 사용하는 것이 좋지만, 그러면 추가적인 자동화 작업을 수행해야 합니다.

가용성 고려 시기

가용성 요구 사항은 SharePoint 솔루션 핵심 디자인의 일부분으로 고려하는 것이 좋습니다. 솔루션을 배포한 후 향상된 가용성을 제공할 수도 있습니다. 운영 측면에서는 팜 내에서 핵심 솔루션을 배포 및 조정한 후에 가용성 솔루션을 테스트하는 것이 좋습니다.

가용성 요구 사항 확인

조직의 사이트, 서비스 또는 팜 가동 중지 시간 허용 범위를 측정하려면 사이트, 서비스 또는 팜과 관련된 다음 질문에 답하십시오.

  • 사이트, 서비스 또는 팜을 사용할 수 없게 되는 경우 조직의 직원이 업무를 수행할 수 없습니까?

  • 사이트, 서비스 또는 팜을 사용할 수 없게 되는 경우 비즈니스 및 고객 트랜잭션이 중지되어 사업 기회와 고객을 잃게 됩니까?

위 질문 중 하나라도 예라고 답한 경우 가용성 솔루션에 투자해야 합니다.

가용성 전략 선택

다음을 포함한 여러 가지 방법 중 하나를 선택하여 가용성을 강화할 수 있습니다.

  • 구성 요소의 내결함성

  • 팜 내 서버 역할 및 데이터베이스 간 중복 및 장애 조치

  • 서버 팜 간 중복 및 장애 조치

가용성을 위한 시스템 요구 사항

이상적 시나리오에서는 장애 조치 구성 요소와 시스템이 플랫폼, 하드웨어, 서버 수 등 모든 측면에서 기본 구성 요소 및 시스템과 일치합니다. 최소한 장애 조치 환경은 장애 조치 중에 예상 트래픽을 처리할 수 있어야 합니다. 장애 조치 사이트에서는 일부 사용자에게만 서비스를 제공합니다. 시스템은 최소한 다음 조건에 일치해야 합니다.

  • 운영 체제 버전 및 모든 업데이트

  • SQL Server 버전 및 모든 업데이트

  • SharePoint 제품 및 기술 버전 및 모든 업데이트

이 문서에서는 SharePoint 제품 및 기술의 가용성에 대해 주로 설명하지만, 시스템 가동 시간은 시스템의 다른 구성 요소에 따라 영향을 받기도 합니다. 특히 다음과 같은 점을 고려해야 합니다.

  • 전원, 냉각, 네트워크, 디렉터리, SMTP 등의 인프라 종속성이 완전히 중복되는지 확인해야 합니다.

  • 요구 사항에 맞는 시스템용 전환 메커니즘(DNS 또는 하드웨어 부하 분산)을 선택합니다. 웹 서버 부하를 분산하는 최상의 방법은 다음 문서에 나와 있습니다.

팜 내의 가용성

팜 내의 가용성을 지원하려면 내결함성 있는 구성 요소, 중복 서버 역할을 포함하도록 계획하고 데이터베이스 가용성(클러스터링, 데이터베이스 미러링 또는 둘 모두)을 지원합니다.

구성 요소 내결함성

모든 시스템에서 하드웨어 공급업체와의 협력을 통해 RAID(Redundant Array of Independent Disks)를 비롯한 시스템에 적합한 내결함성 하드웨어를 준비하는 것이 좋습니다. 권장 사항을 보려면 성능 및 용량 계획(Office SharePoint Server)을 참조하십시오.

구성 요소 내결함성을 계획하는 경우 다음을 고려합니다.

  • 서버 내 모든 구성 요소를 완전히 중복하는 것은 불가능하거나 실용적이지 않습니다. 추가 중복을 확보하려면 추가 서버를 사용합니다.

  • 인덱스 서버 역할은 중복될 수 없으므로 인덱스 서버 역할에 대해서는 구성 요소 중복을 설정하십시오.

  • 최대 중복을 확보할 수 있도록 서버의 여러 전원 공급 장치가 서로 다른 전원에 연결되어 있는지 확인합니다.

팜 내 서버 역할 간 중복 및 장애 조치

SharePoint 제품 및 기술에서는 용량을 높이고 성능을 개선하며 기본적인 가용성을 제공하기 위해 중복 컴퓨터에서 서버 역할을 실행(즉, 확장)할 수 있습니다. 용량과 성능에 따라 팜의 서버 수와 크기가 결정됩니다. 이러한 기본적인 요구 사항이 충족되면 전체 서비스 가용성을 높이기 위해 서버를 추가할 수 있습니다.

단일 서버 팜 내의 중복
단일 팜 가용성

다음 표에서는 SharePoint 중앙 관리 웹 사이트의 서버 제공 서비스 페이지에 나와 있는 SharePoint 제품 및 기술 환경의 서버 역할 및 서비스와 팜 내에서 각 서버에 사용할 수 있는 기본 중복 전략에 대해 설명합니다.

서버 제공 서비스 팜 내에서 기본적으로 사용되는 중복 전략

웹 서버

소프트웨어 또는 하드웨어 부하 분산을 사용하여 여러 서버에 배포 및 부하 분산

중간 규모의 서버 팜용 웹 서버(웹 응용 프로그램 및 검색 쿼리 서비스)

여러 서버에 배포

검색 인덱싱

여러 서버에 배포할 수 없으며 중복될 수 없습니다. 다른 가용성 전략을 사용해야 합니다. 자세한 내용은 팜 내의 검색 가용성을 참조하십시오.

Excel 계산

여러 서버에 배포

Project 응용 프로그램

여러 서버에 배포

자세한 내용은 중복 계획(Office SharePoint Server)을 참조하십시오.

단일 팜의 데이터베이스 가용성 전략

SQL Server 클러스터링과 SQL Server 고가용성 미러링(동기 미러링이라고도 함)을 사용하여 팜 내에서 데이터베이스 가용성을 제공할 수 있습니다.

클러스터링 장애 조치(failover cluster) 클러스터링은 SQL Server의 전체 인스턴스에 대한 가용성을 지원합니다. 장애 조치 클러스터링은 두 개 이상의 공유 디스크를 함께 사용하는 하나 이상의 노드 또는 서버 조합입니다. 장애 조치 클러스터 인스턴스는 단일 컴퓨터로 나타나지만 현재 노드를 사용할 수 없게 될 경우 한 노드에서 다른 노드로 장애 조치를 제공하는 기능이 있습니다.

Office SharePoint Server 2007은 클러스터 전체를 참조하므로 장애 조치가 자동으로 이루어지며 SharePoint 제품 및 기술의 관점에서 매끄럽게 수행됩니다.

동기 데이터베이스 미러링 데이터베이스 미러링은 주 데이터베이스의 트랜잭션 로그 버퍼를 디스크에 쓸 때마다 데이터베이스 및 서버에서 미러 데이터베이스 및 서버로 직접 트랜잭션을 보내 가용성을 지원합니다. 높은 보호 모드(자동 장애 조치 기능 포함)라고도 하는 고가용성 데이터베이스 미러링을 사용하는 것이 좋습니다. 고가용성 데이터베이스 미러링 작업에는 주 서버, 미러 서버 및 미러링 모니터 서버 등 세 가지 서버 인스턴스가 필요합니다. 미러링 모니터 서버는 SQL Server가 주 서버에서 미러 서버로 자동으로 장애 조치를 수행하도록 합니다. 주 데이터베이스에서 미러 데이터베이스로 장애 조치를 수행하는 데는 일반적으로 몇 초가 걸립니다.

각 기술마다 나름의 장단점이 있습니다. 클러스터링은 구현이 더 쉽지만 비용이 많이 듭니다. Microsoft Office Project Server 2007 데이터베이스에는 SQL Server 미러링이 지원되지 않습니다.

다음 표에서는 장애 조치 클러스터링과 SQL Server 고가용성 미러링을 비교합니다.

SQL Server 장애 조치 클러스터링 SQL Server 고가용성 미러링

장애 시 미러링이 즉시 수행됨

장애 시 미러링이 즉시 수행됨

트랜잭션 방식으로 일관성 유지

트랜잭션 방식으로 일관성 유지

트랜잭션 방식으로 동시성 유지

트랜잭션 방식으로 동시성 유지

복구 시간이 짧음(수초에서 수분).

복구 시간이 조금 더 김(수초에서 수분)

데이터베이스 노드에서 장애를 자동으로 감지함. SharePoint 제품 및 기술은 클러스터를 참조하므로 SharePoint 제품 및 기술 측면에서 볼 때 장애 조치가 원활하게 자동으로 진행됩니다.

SharePoint 제품 및 기술 장애 조치를 수행하려면 스크립트를 작성해야 함

클러스터의 노드에서 저장소를 공유하므로 장애가 발생한 저장소가 보호되지 않음

기본 데이터베이스 서버와 미러 데이터베이스 서버가 모두 로컬 디스크에 쓰므로 장애가 발생한 저장소가 보호됨

고가의 공유 저장소가 필요함

저렴한 DAS(직접 연결 저장소) 사용 가능

동일한 서브넷

SQL Server와 웹 서버 간에 최대 1ms의 대기 시간

SQL Server 단순 복구 모델 사용 가능. 단, 클러스터가 손실되는 경우 사용 가능한 복구 지점은 마지막 전체 백업뿐임

SQL Server 전체 복구 모델이 필요함

성능 오버헤드가 없음

트랜잭션 지연이 발생하며 메모리 및 프로세서 오버헤드가 추가적으로 발생함

운영 부담이 거의 없음

스크립트 작성 및 SQL Server 별칭 설정 등의 운영 부담이 추가됨

클러스터링을 사용하는 방법에 대한 자세한 내용은 SQL Server 클러스터링을 사용하여 단일 팜에서 가용성 구성을 참조하십시오.

동기 미러링을 사용하는 방법에 대한 자세한 내용은 SQL Server 데이터베이스 미러링을 사용하여 단일 팜에서 가용성 구성데이터베이스 미러링 사용(Office SharePoint Server)(백서)을 참조하십시오.

단일 팜으로 구성된 근접 데이터 센터("연장된" 팜) 간 중복 및 장애 조치

일부 기업에서는 근접한 데이터 센터를 단일 팜으로 구성할 수 있도록 고대역폭으로 연결하기도 하는데, 이를 "연장된" 팜이라고 합니다. 연장된 팜이 작동하려면 SQL Server와 웹 서버 간에 단일 방향 대기 시간이 1ms 미만이어야 하며, 초당 대역폭이 최소 1GB 이상이어야 합니다.

  • 이 시나리오에서는 동기 미러링을 사용하여 SharePoint 데이터베이스에 대해 중복을 제공할 수 있습니다. 연장된 팜 내에서 구성 데이터베이스 및 콘텐츠 데이터베이스를 미러링할 수 있습니다. 연장된 팜을 사용한 회사의 사례 연구를 보려면 데이터베이스 미러링을 사용한 SharePoint 고가용성 사례 연구(백서)를 참조하십시오.

  • SAN 복제 또는 기타 지원 메커니즘을 사용해 여러 지역의 서버 클러스터에서 실행 중인 SQL Server 등과 같은 여러 데이터 센터에 가용성을 제공할 수 있는지 SAN 공급업체에 문의하십시오. 그리고 SAN 복제 솔루션에서 충분한 동시성 및 트랜잭션 일관성 수준을 제공하는지 확인하십시오.

연장된 팜 내에서는 다음을 통해 SSP를 실행하는 응용 프로그램 서버에 내결함성을 제공할 수 있습니다.

  • 여러 쿼리 서버

  • Excel 계산 서비스를 실행하는 여러 서버

이 시나리오에서는 인덱스 서버가 단일 장애 지점입니다. 검색을 백업 및 복원할 수도 있고, 복구 시의 검색 동시성이 보장되어야 하는 경우에는 장애 조치 SSP 팜을 사용할 수도 있습니다. 자세한 내용은 팜 내의 검색 가용성을 참조하십시오.

이 시나리오의 또 다른 단일 장애 지점은 프로젝트 서버입니다. 프로젝트 서버 데이터베이스 백업 및 복원을 계획하십시오.

"연장된" 팜
"늘어난" 팜

팜 내의 검색 가용성

팜 내에서 인덱스 서버 역할은 중복될 수 없습니다. 장애 조치 이후에 검색 동시성에 대한 비즈니스 요구 사항에 따라 솔루션의 논리 아키텍처가 결정될 수 있습니다.

장애 조치 이후에 업무상 즉각적인 검색 동시성과 가용성이 필요하지 않으면 검색 SSP를 백업하여 장애 조치 사이트로 복원할 수 있습니다.

업무상 신속한 검색 동시성과 가용성이 필요한 경우에는 다음 방법 중 하나를 사용할 수 있습니다.

  • 동일한 두 SSP가 포함된 단일 팜 아키텍처

    참고참고:

    비즈니스에서 빠른 검색 동시성과 가용성을 필요로 하는 경우 프로필을 사용하면 장애 조치 SSP의 프로필이 기본 SSP의 프로필과 동기화되지 않으며 처음 가져올 때의 상태를 유지합니다. 모든 SSP의 프로필을 동기화된 상태로 유지하려면 32비트 버전의 SharePoint 관리 도구 키트(영문)(http://go.microsoft.com/fwlink/?linkid=119535&clcid=0x412)나 64비트 버전의 SharePoint 관리 도구 키트(영문)(http://go.microsoft.com/fwlink/?linkid=119536&clcid=0x412)에 포함된 User Profile Replication Engine을 사용해야 합니다. 자세한 내용은 User Profile Replication Engine(Office SharePoint Server)을 참조하십시오.

  • 검색 및 기타 SSP를 호스팅하는 중앙 상위 팜. 중앙 팜의 검색 서비스는 다른 모든 팜의 콘텐츠를 크롤링합니다. 이 아키텍처를 사용하면 여러 팜을 지원할 수 있습니다.

두 SSP가 포함된 단일 팜

다음 아키텍처는 인덱스 서버의 장애로부터 팜을 보호합니다. 이러한 토폴로지에서는 두 SSP가 같은 규칙을 사용하여 같은 콘텐츠를 크롤링합니다. 장애 조치 SSP는 장애 조치가 발생하는 경우를 제외하고는 기본 웹 사이트에 연결되지 않습니다.

두 공유 서비스 공급자가 포함된 단일 팜
2개의 SSP가 구성된 팜

이 토폴로지에는 다음과 같은 제한이 있습니다.

  • 각 쿼리 서버의 인덱스에 대해 두 배의 공간이 필요합니다.

  • 장애 조치 SSP를 사용하려면 웹 응용 프로그램으로 수동 전환해야 합니다(스크립트 작성 가능).

  • 크롤링 가능한 모음 크기가 반으로 줄어듭니다.

  • 기본적으로 프로필을 사용하도록 설정하는 경우 장애 조치 SSP 팜의 프로필이 기본 SSP의 프로필과 동기화되지 않으며 처음 가져올 때의 상태를 유지합니다. 모든 SSP의 프로필을 동기화된 상태로 유지하려면 32비트 버전의 SharePoint 관리 도구 키트(영문)(http://go.microsoft.com/fwlink/?linkid=119535&clcid=0x412)나 64비트 버전의 SharePoint 관리 도구 키트(영문)(http://go.microsoft.com/fwlink/?linkid=119536&clcid=0x412)에 포함된 User Profile Replication Engine을 사용해야 합니다. 자세한 내용은 User Profile Replication Engine(Office SharePoint Server)을 참조하십시오.

큰 데이터 집합을 제때 크롤링하는 기능은 인덱스 서버와 웹 서버 간의 대기 시간 및 대역폭을 비롯한 다양한 요인의 영향을 받습니다.

대역폭이 제한된 환경에서는 이 토폴로지를 사용하면 성능이 크게 저하될 수 있습니다. 콘텐츠를 두 번 크롤링하면 크롤링되는 콘텐츠 저장소에 부하가 추가되어 저장소 성능에 영향을 줄 수 있습니다. 또한 인덱스를 최신 상태로 유지하는 검색 기능도 저하될 수 있습니다.

중앙 SSP 팜

다음 아키텍처에서는 상위 SSP 팜을 사용하여 인덱스 서버의 장애로부터 팜을 보호합니다. 이는 하드웨어를 많이 사용하는 솔루션처럼 보일 수 있지만, 인덱스 서버가 별도의 서버에 있으면 개별 SSP 팜은 클러스터된/미러링된 데이터베이스 서버와 같은 일부 하드웨어를 공유할 수 있습니다. SSP 팜을 계획 및 구성하는 방법에 대한 자세한 내용은 SSP 아키텍처 계획을 참조하십시오.

이 토폴로지에는 다음과 같은 이점이 있습니다.

  • SSP 관리가 중앙 집중화됩니다.

  • 팜 장애 시 크롤링을 다시 수행할 필요가 없습니다.

중앙 SSP 팜
SSP 장애 조치(Failover) 팜

이 토폴로지에는 다음과 같은 제한이 있습니다.

  • WAN(Wide Area Network)에서 콘텐츠를 크롤링할 때 대역폭이 사용됩니다.

  • 데이터 양이 많고 변경 비율이 높은 환경에서는 인덱스를 최신 상태로 유지하기가 어려울 수 있습니다.

  • WAN 링크의 성능에 따라 쿼리 성능이 영향을 받을 수 있습니다.

  • 기본적으로 프로필을 사용하도록 설정하는 경우 장애 조치 SSP의 프로필이 기본 SSP의 프로필과 동기화되지 않으며 처음 가져올 때의 상태를 유지합니다. 모든 SSP의 프로필을 동기화된 상태로 유지하려면 32비트 버전의 SharePoint 관리 도구 키트(영문)(http://go.microsoft.com/fwlink/?linkid=119535&clcid=0x412)나 64비트 버전의 SharePoint 관리 도구 키트(영문)(http://go.microsoft.com/fwlink/?linkid=119536&clcid=0x412)에 포함된 User Profile Replication Engine을 사용해야 합니다. 자세한 내용은 User Profile Replication Engine(Office SharePoint Server)을 참조하십시오.

여러 팜이 있는 데이터 센터 간 중복 및 장애 조치

기본 팜에서 개별 데이터 센터에 가용성을 제공하도록 장애 조치 팜을 설정할 수 있습니다. 개별 장애 조치 팜이 있는 환경의 특징은 다음과 같습니다.

  • 장애 조치 팜에서 개별 구성 데이터베이스 및 중앙 관리 콘텐츠 데이터베이스를 유지 관리해야 합니다.

    참고참고:

    기본 팜에 대해 대체 액세스 매핑을 구성한 경우에는 장애 조치 팜에서도 동일하게 구성해야 합니다.

  • 모든 사용자 지정 내용을 두 팜에 모두 배포해야 합니다.

  • 패치를 두 팜에 각각 적용해야 합니다.

  • 콘텐츠 데이터베이스만 비동기 방식으로 미러링하거나 로그를 장애 조치 팜으로 전달할 수 있습니다.

  • 미러링 또는 로그를 전달하는 데이터베이스는 전체 복구 모델을 사용하도록 설정해야 합니다.

  • SSP 데이터베이스(Office Project 2007 데이터베이스 포함)는 장애 조치 팜으로 백업 및 복원할 수 있습니다.

SAN 복제 또는 기타 지원 메커니즘을 사용해 여러 데이터 센터에 가용성을 제공할 수 있는지 SAN 공급업체에 문의하십시오.

하나 이상의 추가 데이터 센터에 대한 SQL Server 로그 전달을 구성하는 경우에는 이 토폴로지를 여러 데이터 센터에서 반복할 수 있습니다.

참고참고:

SQL Server 미러링은 단일 미러 서버에서만 사용할 수 있지만, 로그는 여러 보조 서버로 전달할 수 있습니다.

장애 조치 전 기본 팜 및 장애 조치 팜
장애 조치(Failover) 전의 기본 팜 및 장애 조치 팜

다음 표에는 SharePoint 제품 및 기술 환경의 서버 역할 및 서비스와 각 서버 팜 간에 사용할 수 있는 기본 중복 전략이 나와 있습니다.

서버 또는 서버 역할 기본적으로 사용되는 팜 간 중복 전략

SQL Server

SQL Server 비동기 데이터베이스 미러링, SQL Server 로그 전달 또는 기타 비동기 복제 메커니즘

참고참고:
검색 정보를 호스팅하는 SSP 데이터베이스 또는 프로젝트 서버 데이터베이스에는 사용할 수 없습니다.

프런트 엔드 웹 서버

사용자 지정 내용을 포함하여 두 팜에 모두 배포합니다.

중간 규모의 서버 팜용 웹 서버(웹 응용 프로그램 및 검색 쿼리 서비스)

두 팜에 모두 배포합니다.

검색 인덱싱

두 팜에 모두 배포합니다. 원본 팜에서 백업을 복구하여 장애 조치 팜으로 이동합니다.

Excel 계산

두 팜에 모두 배포합니다. SSP가 검색을 호스팅하지 않으면 비동기 데이터베이스 미러링, SQL Server 로그 전달 또는 기타 비동기 복제 메커니즘을 사용하여 데이터를 장애 조치 팜으로 이동할 수 있습니다.

SSP가 검색도 호스팅하는 경우에는 원본 팜에서 백업을 복구하여 이동해야 합니다.

Project 응용 프로그램

두 팜에 모두 배포합니다. 원본 팜에서 백업을 복구하여 장애 조치 팜으로 이동합니다.

팜 간의 검색 가용성

검색을 수행하려면 검색 데이터베이스, SSP 데이터베이스 및 인덱스를 완전히 동기화해야 합니다. 이러한 요구 사항으로 인해 비동기 복제 메커니즘(비동기 데이터 미러링, 로그 전달 또는 비동기 SAN 복제)을 사용하여 팜 간에 검색을 복제할 수는 없습니다.

참고참고:

검색 또는 프로젝트 없이 SSP를 실행하는 경우에는 비동기 복제 메커니즘을 사용하여 데이터를 이동할 수 있습니다.

장애 조치 팜에 검색 기능을 제공하려면 다음 방법 중 하나를 사용해야 합니다.

  • 검색 SSP의 백업을 장애 조치 팜으로 복구합니다.

  • 검색 및 기타 SSP를 호스팅하는 중앙 상위 팜을 사용합니다. 중앙 팜의 검색 서비스는 다른 모든 팜의 콘텐츠를 크롤링합니다.

요약

가용성 요구 사항은 면밀하게 검토해야 합니다. 가용성 수준이 높고 보호할 시스템 수가 많을수록 가용성 솔루션이 더 복잡해지고 비용이 증가할 가능성이 높습니다.

가용성 확보를 위한 비용은 비즈니스 요구 사항을 기준으로 평가해야 합니다. 조직 내의 모든 솔루션에 동일한 수준의 가용성이 필요한 것은 아닙니다. 즉, 각 사이트, 검색 및 비즈니스 인텔리전스 같은 각 서비스, 그리고 각 팜마다 서로 다른 수준의 가용성을 적용할 수 있습니다.

도움 주신 분

Microsoft Office SharePoint Server Content Publishing 팀에서는 이 문서에 도움을 주신 다음 기술 검토자에게 감사를 드립니다.

  • Bill Baer, Microsoft Online Services, Hosted SharePoint, 기술 설계자

  • James Petrosky, Microsoft Consulting Services, 선임 컨설턴트

  • Steve Peschka, Microsoft Consulting Services, IW 선임 설계자

  • Dan Winter, Microsoft Customer Support Services, 에스컬레이션 엔지니어

  • Sean Livingston, Microsoft SharePoint 제품 및 기술, 프로그램 관리자

  • Mike Watson, 기술 설계자

  • Todd Carter, Microsoft Premier Field Engineering, 수석 현장 엔지니어

  • Mike Plumley, Microsoft Office Project Server, 작성자

  • Christophe Fiessinger, Microsoft Office Project, 선임 기술 제품 관리자

  • Sid Shah, Microsoft Search, 프로그램 관리자

  • Luca Bandinelli, Microsoft SharePoint 제품 및 기술, 프로그램 관리자

이 문서의 다운로드

이 항목은 다운로드 가능한 다음 문서에도 포함되어 있어 더 쉽게 읽고 인쇄할 수 있습니다.

참고 항목

이 정보가 도움이 되었습니까?
(1500자 남음)
의견을 주셔서 감사합니다.
표시:
© 2014 Microsoft