Microsoft Azure에서 SharePoint Server 2013 재해 복구

Azure를 사용하여 온-프레미스 SharePoint 팜에 대한 재해 복구 환경을 만들 수 있습니다. 이 문서에서는 이 솔루션을 디자인하고 구현하는 방법을 설명합니다.

SharePoint Server 2013 재해 복구 개요 비디오 보기

재해가 SharePoint 온-프레미스 환경에 영향을 미칠 때 가장 우선 순위는 시스템을 신속하게 다시 실행하는 것입니다. Microsoft Azure에서 이미 실행 중인 백업 환경이 있는 경우 SharePoint를 사용한 재해 복구가 더 빠르고 쉽습니다. 이 비디오에서는 SharePoint 웜 장애 조치(failover) 환경의 주요 개념을 설명하고 이 문서에서 사용할 수 있는 전체 세부 정보를 보완합니다.

Microsoft Azure의 SharePoint 재해 복구 솔루션 모델과 함께 이 문서를 사용합니다.

PDF | Visio

재해 복구에 Azure Infrastructure Services 사용

많은 조직에는 SharePoint에 대한 재해 복구 환경이 없으므로 온-프레미스를 빌드하고 유지 관리하는 데 비용이 많이 들 수 있습니다. Azure Infrastructure Services는 온-프레미스 대안보다 더 유연하고 비용이 저렴한 재해 복구 환경에 대한 매력적인 옵션을 제공합니다.

Azure Infrastructure Services를 사용할 때의 이점은 다음과 같습니다.

• 비용이 많이 드는 리소스 감소 온-프레미스 재해 복구 환경보다 적은 리소스를 유지 관리하고 비용을 지불합니다. 리소스 수는 선택한 재해 복구 환경(콜드 대기, 웜 대기 또는 핫 대기)에 따라 달라집니다.

• 리소스 유연성 향상 재해가 발생할 경우 부하 요구 사항을 충족하도록 복구 SharePoint 팜을 쉽게 스케일 아웃합니다. 리소스가 더 이상 필요하지 않은 경우 스케일 인합니다.

• 낮은 데이터 센터 약정 다른 지역의 보조 데이터 센터에 투자하는 대신 Azure Infrastructure Services를 사용합니다.

재해 복구를 시작하는 조직에는 덜 복잡한 옵션과 복원력이 높은 요구 사항이 있는 조직을 위한 고급 옵션이 있습니다. 환경이 클라우드 플랫폼에서 호스트되는 경우 콜드, 웜 및 핫 대기 환경에 대한 정의는 약간 다릅니다. 다음 표에서는 Azure에서 SharePoint 복구 팜을 빌드하기 위한 이러한 환경에 대해 설명합니다.

표: 복구 환경

복구 환경 유형	설명
뜨거운	완전히 크기가 지정된 팜이 프로비전, 업데이트 및 대기 중으로 실행됩니다.
따뜻한	팜이 빌드되고 가상 머신이 실행되고 업데이트됩니다. 복구에는 콘텐츠 데이터베이스 연결, 서비스 애플리케이션 프로비전 및 콘텐츠 크롤링이 포함됩니다. 팜은 더 작은 버전의 프로덕션 팜일 수 있으며 전체 사용자 기반을 제공하기 위해 확장될 수 있습니다.
감기	팜이 완전히 빌드되었지만 가상 머신이 중지됩니다. 환경 유지 관리에는 때때로 가상 머신 시작, 패치, 업데이트 및 환경 확인이 포함됩니다. 재해 발생 시 전체 환경을 시작합니다.

조직의 RTO(복구 시간 목표) 및 RPO(복구 지점 목표)를 평가하는 것이 중요합니다. 이러한 요구 사항에 따라 조직에 가장 적합한 투자 환경이 결정됩니다.

이 문서의 지침에서는 웜 대기 환경을 구현하는 방법을 설명합니다. 이러한 종류의 환경을 지원하기 위해 추가 절차를 따라야 하지만 콜드 대기 환경에 맞게 조정할 수도 있습니다. 이 문서에서는 핫 대기 환경을 구현하는 방법을 설명하지 않습니다.

재해 복구 솔루션에 대한 자세한 내용은 SharePoint 2013의 고가용성 및 재해 복구 개념 및 SharePoint 2013에 대한 재해 복구 전략 선택을 참조하세요.

솔루션 설명

웜 대기 재해 복구 솔루션에는 다음 환경이 필요합니다.

• 온-프레미스 SharePoint 프로덕션 팜

• Azure의 복구 SharePoint 팜

• 두 환경 간의 사이트 간 VPN 연결

다음 그림에서는 이러한 세 가지 요소를 보여 줍니다.

그림: Azure의 웜 대기 솔루션 요소

DFSR(Distributed File System Replication)을 사용한 SQL Server 로그 전달은 데이터베이스 백업 및 트랜잭션 로그를 Azure의 복구 팜에 복사하는 데 사용됩니다.

• DFSR은 프로덕션 환경에서 복구 환경으로 로그를 전송합니다. WAN 시나리오에서 DFSR은 Azure의 보조 서버로 직접 로그를 전달하는 것보다 더 효율적입니다.

• 로그는 Azure의 복구 환경에서 SQL Server 재생됩니다.

• 복구 연습이 수행될 때까지 복구 환경에서 로그가 제공된 SharePoint 콘텐츠 데이터베이스를 연결하지 않습니다.

팜을 복구하려면 다음 단계를 수행합니다.

1. 로그 전달을 중지합니다.

2. 기본 팜에 대한 트래픽 허용을 중지합니다.

3. 최종 트랜잭션 로그를 재생합니다.

4. 콘텐츠 데이터베이스를 팜에 연결합니다.

5. 복제된 서비스 데이터베이스에서 서비스 애플리케이션을 복원합니다.

6. 복구 팜을 가리키도록 DNS(도메인 이름 시스템) 레코드를 업데이트합니다.

7. 전체 크롤링을 시작합니다.

이러한 단계를 정기적으로 연습하고 문서화하여 라이브 복구가 원활하게 실행되도록 하는 것이 좋습니다. 콘텐츠 데이터베이스를 연결하고 서비스 애플리케이션을 복원하는 데 다소 시간이 걸릴 수 있으며 일반적으로 일부 수동 구성이 포함됩니다.

복구를 수행한 후 이 솔루션은 다음 표에 나열된 항목을 제공합니다.

표: 솔루션 복구 목표

항목	설명
사이트 및 콘텐츠	사이트 및 콘텐츠는 복구 환경에서 사용할 수 있습니다.
검색의 새 인스턴스	이 웜 대기 솔루션에서는 검색 데이터베이스에서 검색이 복원되지 않습니다. 복구 팜의 검색 구성 요소는 프로덕션 팜과 최대한 유사하게 구성됩니다. 사이트 및 콘텐츠가 복원되면 검색 인덱스 다시 작성을 위한 전체 크롤링이 시작됩니다. 사이트 및 콘텐츠를 사용할 수 있도록 크롤링이 완료되기를 기다릴 필요가 없습니다.
서비스	데이터베이스에 데이터를 저장하는 서비스는 로그 제공 데이터베이스에서 복원됩니다. 데이터베이스에 데이터를 저장하지 않는 서비스는 단순히 시작됩니다. 데이터베이스가 있는 모든 서비스를 복원해야 하는 것은 아닙니다. 다음 서비스는 데이터베이스에서 복원할 필요가 없으며 장애 조치(failover) 후에 시작할 수 있습니다. Usage and Health Data Collection State Service Word 자동화 데이터베이스를 사용하지 않는 다른 모든 서비스

MCS(Microsoft Consulting Services) 또는 파트너와 협력하여 더 복잡한 복구 목표를 해결할 수 있습니다. 다음은 다음 표에 요약되어 있습니다.

표: MCS 또는 파트너가 해결할 수 있는 기타 항목

항목	설명
사용자 지정 팜 솔루션 동기화	이상적으로 복구 팜 구성은 프로덕션 팜과 동일합니다. 컨설턴트 또는 파트너와 협력하여 사용자 지정 팜 솔루션이 복제되는지 여부와 두 환경을 동기화된 상태로 유지하기 위한 프로세스가 준비되었는지 여부를 평가할 수 있습니다.
온-프레미스 데이터 원본에 대한 연결	BDC(백업 도메인 컨트롤러) 연결 및 검색 콘텐츠 원본과 같은 백 엔드 데이터 시스템에 대한 연결을 복제하는 것은 실용적이지 않을 수 있습니다.
복원 시나리오 검색	엔터프라이즈 검색 배포는 매우 독특하고 복잡한 경향이 있으므로 데이터베이스에서 검색을 복원하려면 더 많은 투자가 필요합니다. 컨설턴트 또는 파트너와 협력하여 조직에 필요할 수 있는 검색 복원 시나리오를 식별하고 구현할 수 있습니다.

이 문서에 제공된 지침에서는 온-프레미스 팜이 이미 설계 및 배포되었다고 가정합니다.

자세한 아키텍처

이상적으로 Azure의 복구 팜 구성은 다음을 포함하여 온-프레미스 프로덕션 팜과 동일합니다.

• 서버 역할의 동일한 표현

• 사용자 지정의 동일한 구성

• 검색 구성 요소의 동일한 구성

Azure의 환경은 더 작은 버전의 프로덕션 팜일 수 있습니다. 장애 조치(failover) 후 복구 팜을 확장하려는 경우 각 서버 역할 유형을 처음에 나타내는 것이 중요합니다.

일부 구성은 장애 조치(failover) 환경에서 복제하는 것이 실용적이지 않을 수 있습니다. 장애 조치(failover) 팜이 예상 서비스 수준을 제공하는지 확인하려면 장애 조치(failover) 절차 및 환경을 테스트해야 합니다.

이 솔루션은 SharePoint 팜에 대한 특정 토폴로지를 규정하지 않습니다. 이 솔루션의 초점은 장애 조치 팜에 Azure를 사용하고 두 환경 간에 로그 전달 및 DFSR을 구현하는 것입니다.

웜 대기 환경

웜 대기 환경에서는 Azure 환경의 모든 가상 머신이 실행되고 있습니다. 환경은 장애 조치(failover) 연습 또는 이벤트에 사용할 준비가 되어 있습니다.

다음 그림에서는 온-프레미스 SharePoint 팜에서 웜 대기 환경으로 구성된 Azure 기반 SharePoint 팜으로 재해 복구 솔루션을 보여 줍니다.

그림: 프로덕션 팜 및 웜 대기 복구 팜의 토폴로지 및 주요 요소

다음은 이 다이어그램에 대한 설명입니다.

• 온-프레미스 SharePoint 팜과 Azure의 웜 대기 팜이라는 두 가지 환경이 나란히 표시됩니다.

• 각 환경에는 파일 공유가 있습니다.

• 각 팜에는 4개의 계층이 포함됩니다. 고가용성을 달성하기 위해 각 계층에는 프런트 엔드 서비스, 분산 캐시, 백 엔드 서비스 및 데이터베이스와 같은 특정 역할에 대해 동일하게 구성된 두 개의 서버 또는 가상 머신이 포함됩니다. 이 그림에서는 특정 구성 요소를 호출하는 것은 중요하지 않습니다. 두 팜은 동일하게 구성됩니다.

• 네 번째 계층은 데이터베이스 계층입니다. 로그 전달은 온-프레미스 환경의 보조 데이터베이스 서버에서 동일한 환경의 파일 공유로 로그를 복사하는 데 사용됩니다.

• DFSR은 온-프레미스 환경의 파일 공유에서 Azure 환경의 파일 공유로 파일을 복사합니다.

• 로그 전달은 Azure 환경의 파일 공유에서 복구 환경의 SQL Server AlwaysOn 가용성 그룹에 있는 기본 복제본으로 로그를 재생합니다.

콜드 대기 환경

콜드 대기 환경에서는 대부분의 SharePoint 팜 가상 머신을 종료할 수 있습니다. (각 가상 머신이 도메인과 동기화할 수 있도록 2주마다 또는 한 달에 한 번 같은 가상 머신을 시작하는 것이 좋습니다.) Azure 복구 환경의 다음 가상 머신은 로그 전달 및 DFSR의 지속적인 작업을 보장하기 위해 계속 실행되어야 합니다.

• 파일 공유

• 주 데이터베이스 서버

• Domain Services 및 DNS를 Windows Server Active Directory 실행 중인 하나 이상의 가상 머신

다음 그림에서는 파일 공유 가상 머신 및 기본 SharePoint 데이터베이스 가상 머신이 실행 중인 Azure 장애 조치(failover) 환경을 보여 줍니다. 다른 모든 SharePoint 가상 머신이 중지됩니다. Windows Server Active Directory 및 DNS를 실행하는 가상 머신이 표시되지 않습니다.

그림: 실행 중인 가상 머신이 있는 콜드 대기 복구 팜

콜드 대기 환경으로 장애 조치(failover)한 후 모든 가상 머신이 시작되고 데이터베이스 서버의 고가용성을 달성하는 메서드(예: SQL Server AlwaysOn 가용성 그룹)를 구성해야 합니다.

여러 스토리지 그룹이 구현되는 경우(데이터베이스가 둘 이상의 SQL Server 고가용성 집합에 분산됨) 각 스토리지 그룹에 대한 기본 데이터베이스가 실행되어 해당 스토리지 그룹과 연결된 로그를 수락해야 합니다.

기술 및 경험

이 재해 복구 솔루션에는 여러 기술이 사용됩니다. 이러한 기술이 예상대로 상호 작용하도록 하려면 온-프레미스 및 Azure 환경의 각 구성 요소를 올바르게 설치하고 구성해야 합니다. 이 솔루션을 설정하는 사람 또는 팀은 다음 문서에 설명된 기술을 사용하여 강력한 실무 지식과 실습 기술을 갖추는 것이 좋습니다.

• DFS(분산 파일 시스템) 복제 서비스

• SQL Server 사용하는 WSFC(Windows Server 장애 조치(failover) 클러스터링)

• AlwaysOn 가용성 그룹(SQL Server)

• SQL Server 데이터베이스 백업 및 복원

• SharePoint Server 2013 설치 및 팜 배포

• Microsoft Azure

마지막으로 이러한 기술과 관련된 작업을 자동화하는 데 사용할 수 있는 스크립팅 기술을 권장합니다. 사용 가능한 사용자 인터페이스를 사용하여 이 솔루션에 설명된 모든 작업을 완료할 수 있습니다. 그러나 수동 접근 방식은 시간이 오래 걸리고 오류가 발생하기 쉬울 수 있으며 일관되지 않은 결과를 제공합니다.

Windows PowerShell 외에도 SQL Server, SharePoint Server 및 Azure에 대한 Windows PowerShell 라이브러리도 있습니다. 재해 복구 환경을 구성하고 유지 관리하는 시간을 줄이는 데 도움이 될 수 있는 T-SQL을 잊지 마세요.

재해 복구 로드맵

이 로드맵에서는 프로덕션 환경에 SharePoint Server 2013 팜이 이미 배포되어 있다고 가정합니다.

표: 재해 복구를 위한 로드맵

단계	설명
1단계	재해 복구 환경을 디자인합니다.
2단계	Azure 가상 네트워크 및 VPN 연결을 만듭니다.
3단계	Azure 가상 네트워크에 Windows Active Directory 및 Domain Name Services를 배포합니다.
4단계	Azure에서 SharePoint 복구 팜을 배포합니다.
5단계	팜 간에 DFSR을 설정합니다.
6단계	복구 팜에 로그 전달을 설정합니다.
7단계	장애 조치(failover) 및 복구 솔루션의 유효성을 검사합니다. 여기에는 다음 절차 및 기술이 포함됩니다. 로그 전달을 중지합니다. 백업을 복원합니다. 콘텐츠를 크롤링합니다. 서비스를 복구합니다. DNS 레코드를 관리합니다.

1단계: 재해 복구 환경 설계

SharePoint 2013용 Microsoft Azure 아키텍처의 지침을 사용하여 SharePoint 복구 팜을 비롯한 재해 복구 환경을 설계합니다. Azure Visio 파일의 SharePoint 재해 복구 솔루션에 있는 그래픽을 사용하여 디자인 프로세스를 시작할 수 있습니다. Azure 환경에서 작업을 시작하기 전에 전체 환경을 디자인하는 것이 좋습니다.

가상 네트워크, VPN 연결, Active Directory 및 SharePoint 팜을 디자인하기 위해 SharePoint 2013용 Microsoft Azure 아키텍처 에 제공된 지침 외에도 Azure 환경에 파일 공유 역할을 추가해야 합니다.

재해 복구 솔루션에서 로그 전달을 지원하기 위해 파일 공유 가상 머신이 데이터베이스 역할이 있는 서브넷에 추가됩니다. 파일 공유는 SQL Server AlwaysOn 가용성 그룹에 대한 노드 과반수의 세 번째 노드로도 사용됩니다. 이 구성은 SQL Server AlwaysOn 가용성 그룹을 사용하는 표준 SharePoint 팜에 권장됩니다.

참고

데이터베이스가 SQL Server AlwaysOn 가용성 그룹에 참여하기 위한 필수 조건을 검토하는 것이 중요합니다. 자세한 내용은 AlwaysOn 가용성 그룹에 대한 필수 구성 요소, 제한 사항 및 권장 사항을 참조하세요.

그림: 재해 복구 솔루션에 사용되는 파일 서버 배치

이 다이어그램에서는 파일 공유 가상 머신이 데이터베이스 서버 역할을 포함하는 Azure의 동일한 서브넷에 추가됩니다. 파일 공유 가상 머신을 SQL Server 역할과 같은 다른 서버 역할과 함께 가용성 집합에 추가하지 마세요.

로그의 고가용성이 우려되는 경우 Azure Blob Storage Service에서 SQL Server 백업 및 복원을 사용하여 다른 방법을 사용하는 것이 좋습니다. 이 기능은 Azure에서 Blob Storage URL에 직접 로그를 저장하는 새로운 기능입니다. 이 솔루션에는 이 기능 사용에 대한 지침이 포함되어 있지 않습니다.

복구 팜을 디자인할 때 성공적인 재해 복구 환경은 복구하려는 프로덕션 팜을 정확하게 반영한다는 사실에 유의하세요. 복구 팜의 크기는 복구 팜의 디자인, 배포 및 테스트에서 가장 중요한 것은 아닙니다. 팜 규모는 비즈니스 요구 사항에 따라 조직마다 다릅니다. 중단이 짧거나 성능 및 용량 요구가 팜의 크기를 조정해야 할 때까지 축소된 팜을 사용할 수 있습니다.

SLA(서비스 수준 계약) 요구 사항을 충족하고 비즈니스를 지원하는 데 필요한 기능을 제공하도록 복구 팜을 프로덕션 팜과 최대한 동일하게 구성합니다. 재해 복구 환경을 디자인할 때 프로덕션 환경에 대한 변경 관리 프로세스도 확인합니다. 프로덕션 환경과 동일한 간격으로 복구 환경을 업데이트하여 변경 관리 프로세스를 복구 환경으로 확장하는 것이 좋습니다. 변경 관리 프로세스의 일부로 팜 구성, 애플리케이션 및 사용자의 자세한 인벤토리를 유지하는 것이 좋습니다.

2단계: Azure 가상 네트워크 및 VPN 연결 만들기

온-프레미스 네트워크를 Microsoft Azure 가상 네트워크에 연결하면 Azure 에서 가상 네트워크를 계획하고 배포하는 방법과 VPN 연결을 만드는 방법을 보여 줍니다. 항목의 지침에 따라 다음 절차를 완료합니다.

• Virtual Network 개인 IP 주소 공간을 계획합니다.

• Virtual Network 대한 라우팅 인프라 변경 내용을 계획합니다.

• 온-프레미스 VPN 디바이스를 왕복하는 트래픽에 대한 방화벽 규칙을 계획합니다.

• Azure에서 프레미스 간 가상 네트워크를 만듭니다.

• 온-프레미스 네트워크와 Virtual Network 간의 라우팅을 구성합니다.

3단계: Azure 가상 네트워크에 Active Directory 및 도메인 이름 서비스 배포

이 단계에는 다음 그림과 같이 Microsoft Azure Architectures for SharePoint 2013에 설명된 대로 하이브리드 시나리오에서 Virtual Network Windows Server Active Directory 및 DNS를 모두 배포하는 것이 포함됩니다.

그림: 하이브리드 Active Directory 도메인 구성

그림에서 두 개의 가상 머신이 동일한 서브넷에 배포됩니다. 이러한 가상 머신은 각각 Active Directory 및 DNS라는 두 가지 역할을 호스팅합니다.

Azure에서 Active Directory를 배포하기 전에 Azure Virtual Machines Windows Server Active Directory 배포에 대한 지침을 참조하세요. 이러한 지침은 솔루션에 다른 아키텍처 또는 다른 구성 설정이 필요한지 여부를 결정하는 데 도움이 됩니다.

Azure에서 도메인 컨트롤러를 설정하는 방법에 대한 자세한 지침은 Azure Virtual Network에 복제본 Active Directory 도메인 컨트롤러 설치를 참조하세요.

이 단계 이전에는 가상 머신을 Virtual Network 배포하지 않았습니다. Active Directory 및 DNS를 호스팅하기 위한 가상 머신은 솔루션에 필요한 가장 큰 가상 머신이 아닐 수 있습니다. 이러한 가상 머신을 배포하기 전에 먼저 Virtual Network 사용할 가장 큰 가상 머신을 만듭니다. 이렇게 하면 솔루션이 필요한 가장 큰 크기를 허용하는 Azure의 태그에 배치됩니다. 현재 이 가상 머신을 구성할 필요가 없습니다. 단순히 만들고 따로 둡니다. 이렇게 하지 않으면 나중에 더 큰 가상 머신을 만들려고 할 때 제한 사항이 발생할 수 있습니다. 이 문서는 이 문서를 작성할 당시의 문제였습니다.

4단계: Azure에서 SharePoint 복구 팜 배포

디자인 계획에 따라 Virtual Network SharePoint 팜을 배포합니다. Azure에서 SharePoint 역할을 배포하기 전에 Azure Infrastructure Services에서 Planning for SharePoint 2013 을 검토하는 것이 도움이 될 수 있습니다.

개념 증명 환경을 구축하여 배운 다음 사례를 고려합니다.

• Azure Portal 또는 PowerShell을 사용하여 가상 머신을 만듭니다.

• Azure 및 Hyper-V는 동적 메모리를 지원하지 않습니다. 성능 및 용량 계획에 영향을 주어야 합니다.

• 가상 머신 로그온 자체가 아닌 Azure 인터페이스를 통해 가상 머신을 다시 시작합니다. Azure 인터페이스를 사용하는 것이 더 잘 작동하며 더 예측 가능합니다.

• 비용을 절감하기 위해 가상 머신을 종료하려면 Azure 인터페이스를 사용합니다. 가상 머신 로그온에서 종료하는 경우 요금이 계속 발생합니다.

• 가상 머신에 대한 명명 규칙을 사용합니다.

• 가상 머신이 배포되는 데이터 센터 위치에 주의하세요.

• Azure의 자동 크기 조정 기능은 SharePoint 역할에 대해 지원되지 않습니다.

• 복원할 팜의 항목(예: 사이트 모음)을 구성하지 마세요.

5단계: 팜 간에 DFSR 설정

DFSR을 사용하여 파일 복제를 설정하려면 DNS 관리 스냅인을 사용합니다. 그러나 DFSR을 설정하기 전에 온-프레미스 파일 서버 및 Azure 파일 서버에 로그온하고 Windows에서 서비스를 사용하도록 설정합니다.

서버 관리자 대시보드에서 다음 단계를 완료합니다.

• 로컬 서버를 구성합니다.

• 역할 및 기능 추가 마법사를 시작합니다.

• 파일 및 스토리지 서비스 노드를 엽니다.

• DFS 네임스페이스 및DFS 복제를 선택합니다.

• 다음을 클릭하여 마법사 단계를 완료합니다.

다음 표에서는 DFSR 참조 문서 및 블로그 게시물에 대한 링크를 제공합니다.

표: DFSR에 대한 참조 문서

제목	설명
복제	복제 링크가 있는 DFS Management TechNet 항목
DFS 복제: 생존 가이드	DFS 정보에 대한 링크가 있는 Wiki
DFS 복제: 질문과 대답	DFS 복제 TechNet 항목
Jose Barreto의 블로그	Microsoft의 파일 서버 팀에서 보안 주체 프로그램 관리자가 작성한 블로그
Microsoft의 스토리지 팀 - 파일 캐비닛 블로그	Windows Server의 파일 서비스 및 스토리지 기능에 대한 블로그

6단계: 복구 팜에 로그 전달 설정

로그 전달은 이 환경에서 재해 복구를 설정하는 데 중요한 구성 요소입니다. 로그 전달을 사용하여 주 데이터베이스 서버 인스턴스에서 보조 데이터베이스 서버 인스턴스로 데이터베이스에 대한 트랜잭션 로그 파일을 자동으로 보낼 수 있습니다. 로그 전달을 설정하려면 SharePoint 2013에서 로그 전달 구성을 참조하세요.

중요

SharePoint Server의 로그 전달 지원은 특정 데이터베이스로 제한됩니다. 자세한 내용은 SharePoint 데이터베이스에 대해 지원되는 고가용성 및 재해 복구 옵션(SharePoint 2013)을 참조하세요.

7단계: 장애 조치(failover) 및 복구 유효성 검사

이 최종 단계의 목표는 재해 복구 솔루션이 계획대로 작동하는지 확인하는 것입니다. 이렇게 하려면 프로덕션 팜을 종료하고 대체로 복구 팜을 시작하는 장애 조치(failover) 이벤트를 만듭니다. 수동으로 또는 스크립트를 사용하여 장애 조치(failover) 시나리오를 시작할 수 있습니다.

첫 번째 단계는 팜 서비스 또는 콘텐츠에 대한 들어오는 사용자 요청을 중지하는 것입니다. DNS 항목을 사용하지 않도록 설정하거나 프런트 엔드 웹 서버를 종료하여 이 작업을 수행할 수 있습니다. 팜이 "다운"된 후 복구 팜으로 장애 조치(failover)할 수 있습니다.

로그 전달 중지

팜 복구 전에 로그 전달을 중지해야 합니다. 먼저 Azure의 보조 서버에서 로그 전달을 중지한 다음 주 서버 온-프레미스에서 중지합니다. 다음 스크립트를 사용하여 먼저 보조 서버에서 로그 전달을 중지한 다음 주 서버에서 로그 전달을 중지합니다. 스크립트의 데이터베이스 이름은 환경에 따라 다를 수 있습니다.

-- This script removes log shipping from the server.
-- Commands must be executed on the secondary server first and then on the primary server.

SET NOCOUNT ON
DECLARE  @PriDB nvarchar(max)
,@SecDB nvarchar(250)
,@PriSrv nvarchar(250)
,@SecSrv nvarchar(250)

Set @PriDB= ''
SET @PriDB = UPPER(@PriDB)
SET @PriDB = REPLACE(@PriDB, ' ', '')
SET @PriDB = '''' + REPLACE(@PriDB, ',', ''', ''') + ''''

Set @SecDB = @PriDB

Exec ( 'Select  ''exec master..sp_delete_log_shipping_secondary_database '' + '''''''' + prm.primary_database +  ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec  ON  prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')

Exec ( 'Select  ''exec master..sp_delete_log_shipping_primary_secondary '' + '''''''' + prm.Primary_Database + '''''', '''''' + sec.Secondary_Server + '''''', '''''' + sec.Secondary_database + ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec  ON  prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')

Exec ( 'Select  ''exec master..sp_delete_log_shipping_primary_database '' + '''''''' + prm.primary_database +  ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec  ON  prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')

Exec ( 'Select  ''exec master..sp_delete_log_shipping_secondary_primary '' + '''''''' + prm.primary_server + '''''', '''''' + prm.primary_database +  ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec  ON  prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')

백업 복원

백업을 만든 순서대로 복원해야 합니다. 특정 트랜잭션 로그 백업을 복원하려면 먼저 커밋되지 않은 트랜잭션을 롤백하지 않고(즉, 를 사용하여 WITH NORECOVERY) 다음 이전 백업을 복원해야 합니다.

• 전체 데이터베이스 백업 및 마지막 차등 백업 - 특정 트랜잭션 로그 백업 전에 수행된 백업(있는 경우)을 복원합니다. 가장 최근의 전체 또는 차등 데이터베이스 백업을 만들기 전에 데이터베이스는 전체 복구 모델 또는 대량 로그 복구 모델을 사용하고 있었습니다.

• 모든 트랜잭션 로그 백업 - 전체 데이터베이스 백업 또는 차등 백업(복원하는 경우) 및 특정 트랜잭션 로그 백업 전에 수행된 트랜잭션 로그 백업을 복원합니다. 로그 백업은 로그 체인의 간격 없이 생성된 시퀀스에 적용해야 합니다.

사이트가 렌더링되도록 보조 서버에서 콘텐츠 데이터베이스를 복구하려면 복구 전에 모든 데이터베이스 연결을 제거합니다. 데이터베이스를 복원하려면 다음 SQL 문을 실행합니다.

restore database WSS_Content with recovery

중요

T-SQL을 명시적으로 사용하는 경우 모든 RESTORE 문에서 WITH NORECOVERY 또는 WITH RECOVERY 를 지정하여 모호성을 제거합니다. 이는 스크립트를 작성할 때 매우 중요합니다. 전체 및 차등 백업이 복원된 후 트랜잭션 로그는 SQL Server Management Studio 복원할 수 있습니다. 또한 로그 전달이 이미 중지되었으므로 콘텐츠 데이터베이스가 대기 상태이므로 상태를 모든 액세스 권한으로 변경해야 합니다.

SQL Server Management Studio WSS_Content 데이터베이스를 마우스 오른쪽 단추로 클릭하고 작업>복원을 가리킨 다음 트랜잭션 로그를 클릭합니다(전체 백업을 복원하지 않은 경우 사용할 수 없음). 자세한 내용은트랜잭션 로그 백업 복원(SQL Server)을 참조하세요.

콘텐츠 원본 크롤링

Search Service를 복원하려면 각 콘텐츠 원본에 대한 전체 크롤링을 시작해야 합니다. 검색 권장 사항과 같은 온-프레미스 팜에서 일부 분석 정보가 손실됩니다. 전체 크롤링을 시작하기 전에 Windows PowerShell cmdlet Restore-SPEnterpriseSearchServiceApplication을 사용하고 로그가 제공되고 복제된 검색 관리 데이터베이스인 Search_Service__DB_<GUID>를 지정합니다. 이 cmdlet은 검색 구성, 스키마, 관리 속성, 규칙 및 원본을 제공하고 다른 구성 요소의 기본 집합을 만듭니다.

전체 크롤링을 시작하려면 다음 단계를 완료합니다.

1. SharePoint 2013 중앙 관리에서 애플리케이션 관리>서비스 애플리케이션서비스 애플리케이션> 관리로 이동한 다음 크롤링할 Search Service 애플리케이션을 클릭합니다.

2. 검색 관리 페이지에서 콘텐츠 원본을 클릭하고 원하는 콘텐츠 원본을 가리킨 다음 화살표를 클릭한 다음 전체 크롤링 시작을 클릭합니다.

팜 서비스 복구

다음 표에서는 로그 제공 데이터베이스가 있는 서비스, 데이터베이스가 있지만 로그 전달을 사용하여 복원하지 않는 서비스 및 데이터베이스가 없는 서비스를 복구하는 방법을 보여 줍니다.

중요

온-프레미스 SharePoint 데이터베이스를 Azure 환경으로 복원해도 Azure에 수동으로 설치하지 않은 SharePoint 서비스는 복구되지 않습니다.

표: 서비스 애플리케이션 데이터베이스 참조

로그 제공 데이터베이스에서 이러한 서비스 복원	이러한 서비스에는 데이터베이스가 있지만 데이터베이스를 복원하지 않고 이러한 서비스를 시작하는 것이 좋습니다.	이러한 서비스는 데이터베이스에 데이터를 저장하지 않습니다. 장애 조치(failover) 후 이러한 서비스 시작
기계 번역 서비스 Managed Metadata Service Secure Store Service 사용자 프로필. (프로필 및 소셜 태그 지정 데이터베이스만 지원됩니다. 동기화 데이터베이스는 지원되지 않습니다.) Microsoft SharePoint Foundation 가입 설정 서비스	Usage and Health Data Collection State Service Word 자동화	Excel Services PerformancePoint Services PowerPoint Conversion Visio Graphics Service 작업 관리

다음 예제에서는 데이터베이스에서 관리되는 메타데이터 서비스를 복원하는 방법을 보여 주었습니다.

기존 Managed_Metadata_DB 데이터베이스를 사용합니다. 이 데이터베이스는 로그가 제공되었지만 보조 팜에는 활성 서비스 애플리케이션이 없으므로 서비스 애플리케이션이 설치된 후 연결해야 합니다.

먼저 를 사용하고 New-SPMetadataServiceApplication복원된 데이터베이스의 이름으로 스위치를 지정 DatabaseName 합니다.

다음으로, 다음과 같이 보조 서버에서 새 Managed Metadata Service 애플리케이션을 구성합니다.

• 이름: 관리되는 메타데이터 서비스

• 데이터베이스 서버: 제공된 트랜잭션 로그의 데이터베이스 이름

• 데이터베이스 이름: Managed_Metadata_DB

• 애플리케이션 풀: SharePoint 서비스 애플리케이션

DNS 레코드 관리

SharePoint 팜을 가리키도록 DNS 레코드를 수동으로 만들어야 합니다.

프런트 엔드 웹 서버가 여러 개 있는 대부분의 경우 Windows Server 2012 네트워크 부하 분산 기능 또는 하드웨어 부하 분산 장치를 활용하여 팜의 웹 프런트 엔드 서버 간에 요청을 분산하는 것이 좋습니다. 또한 네트워크 부하 분산은 웹 프런트 엔드 서버 중 하나가 실패하는 경우 요청을 다른 서버에 배포하여 위험을 줄이는 데 도움이 될 수 있습니다.

일반적으로 네트워크 부하 분산을 설정하면 클러스터에 단일 IP 주소가 할당됩니다. 그런 다음, 클러스터를 가리키는 네트워크의 DNS 공급자에 DNS 호스트 레코드를 만듭니다. (이 프로젝트의 경우 온-프레미스 데이터 센터 오류가 발생한 경우 복원력을 위해 Azure에 DNS 서버를 배치합니다.) 예를 들어 Active Directory의 DNS 관리자(예: ) https://sharepoint.contoso.com에서 부하 분산된 클러스터의 IP 주소를 가리키는 DNS 레코드를 만들 수 있습니다.

SharePoint 팜에 대한 외부 액세스의 경우 클라이언트가 방화벽의 외부 IP 주소를 가리키는 인트라넷(예 https://sharepoint.contoso.com: )에서 사용하는 것과 동일한 URL을 사용하여 외부 DNS 서버에 호스트 레코드를 만들 수 있습니다. (이 예제를 사용하는 모범 사례는 내부 DNS 서버가 신뢰할 수 있도록 분할 DNS를 설정하고 외부 DNS 서버 contoso.com 로 DNS 요청을 라우팅하는 대신 SharePoint 팜 클러스터에 직접 요청을 라우팅하는 것입니다.) 그런 다음 클라이언트가 찾고 있는 리소스를 찾을 수 있도록 외부 IP 주소를 온-프레미스 클러스터의 내부 IP 주소에 매핑할 수 있습니다.

여기에서 다음과 같은 몇 가지 재해 복구 시나리오가 발생할 수 있습니다.

예제 시나리오: 온-프레미스 SharePoint 팜의 하드웨어 오류로 인해 온-프레미스 SharePoint 팜을 사용할 수 없습니다. 이 경우 Azure SharePoint 팜으로 장애 조치(failover) 단계를 완료한 후 온-프레미스 팜과 동일한 방식으로 복구 SharePoint 팜의 웹 프런트 엔드 서버에서 네트워크 부하 분산을 구성할 수 있습니다. 그런 다음 내부 DNS 공급자의 호스트 레코드를 리디렉션하여 복구 팜의 클러스터 IP 주소를 가리킬 수 있습니다. 클라이언트에서 캐시된 DNS 레코드가 새로 고쳐지고 복구 팜을 가리키기까지 다소 시간이 걸릴 수 있습니다.

예제 시나리오: 온-프레미스 데이터 센터가 완전히 손실됩니다. 이 시나리오는 화재 또는 홍수와 같은 자연 재해로 인해 발생할 수 있습니다. 이 경우 엔터프라이즈의 경우 자체 디렉터리 서비스와 DNS가 있는 Azure 서브넷뿐만 아니라 다른 지역에서 호스트되는 보조 데이터 센터가 있을 수 있습니다. 이전 재해 시나리오와 마찬가지로 내부 및 외부 DNS 레코드를 Azure SharePoint 팜을 가리키도록 리디렉션할 수 있습니다. DNS 레코드 전파에는 다소 시간이 걸릴 수 있습니다.

호스트 이름 사이트 모음 아키텍처 및 배포(SharePoint 2013)에서 권장하는 대로 호스트 이름이 지정된 사이트 모음을 사용하는 경우 고유한 DNS 이름(예 https://sales.contoso.com : 및 https://marketing.contoso.com)을 사용하여 SharePoint 팜에서 동일한 웹 애플리케이션에서 호스트하는 여러 사이트 모음이 있을 수 있습니다. 이 경우 클러스터 IP 주소를 가리키는 각 사이트 모음에 대한 DNS 레코드를 만들 수 있습니다. 요청이 SharePoint 웹 프런트 엔드 서버에 도달하면 각 요청을 적절한 사이트 모음으로 라우팅하는 작업을 처리합니다.

Microsoft 개념 증명 환경

이 솔루션에 대한 개념 증명 환경을 설계하고 테스트했습니다. 테스트 환경의 디자인 목표는 고객 환경에서 찾을 수 있는 SharePoint 팜을 배포하고 복구하는 것이었습니다. 몇 가지 가정이 있었지만, 팜은 사용자 지정 없이 모든 기본 기능을 제공해야 한다는 것을 알고 있습니다. 토폴로지 필드 및 제품 그룹의 모범 사례 지침을 사용하여 고가용성을 위해 설계되었습니다.

다음 표에서는 온-프레미스 테스트 환경에 대해 만들고 구성한 Hyper-V 가상 머신에 대해 설명합니다.

테이블: 온-프레미스 테스트용 가상 머신

서버 이름	역할	구성
DC1	Active Directory가 있는 도메인 컨트롤러.	프로세서 2개 512MB에서 4GB RAM까지 1 x 127GB 하드 디스크
Rras	RRAS(라우팅 및 원격 액세스 서비스) 역할로 구성된 서버입니다.	프로세서 2개 2-8GB RAM 1 x 127GB 하드 디스크
FS1	백업에 대한 공유 및 DFSR의 엔드포인트가 있는 파일 서버.	4개의 프로세서 RAM 2-12GB 1 x 127GB 하드 디스크 1 x 1TB 하드 디스크(SAN) 1 x 750GB 하드 디스크
SP-WFE1, SP-WFE2	프런트 엔드 웹 서버.	4개의 프로세서 16GB RAM
SP-APP1, SP-APP2, SP-APP3	애플리케이션 서버.	4개의 프로세서 RAM 2-16GB
SP-SQL-HA1, SP-SQL-HA2	SQL Server 2012 AlwaysOn 가용성 그룹으로 구성된 데이터베이스 서버는 고가용성을 제공합니다. 이 구성에서는 SP-SQL-HA1 및 SP-SQL-HA2를 주 복제본 및 보조 복제본으로 사용합니다.	4개의 프로세서 RAM 2-16GB

다음 표에서는 온-프레미스 테스트 환경의 프런트 엔드 웹 및 애플리케이션 서버에 대해 만들고 구성한 Hyper-V 가상 머신에 대한 드라이브 구성에 대해 설명합니다.

표: 온-프레미스 테스트를 위한 프런트 엔드 웹 및 애플리케이션 서버에 대한 가상 머신 드라이브 요구 사항

드라이브 문자	Size	디렉터리 이름	경로
C	80	시스템 드라이브	<DriveLetter>:\Program Files\Microsoft SQL Server\
전자	80	로그 드라이브(40GB)	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
F	80	페이지(36GB)	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL\DATA

다음 표에서는 온-프레미스 데이터베이스 서버 역할을 하기 위해 만들어지고 구성된 Hyper-V 가상 머신에 대한 드라이브 구성에 대해 설명합니다. 데이터베이스 엔진 구성 페이지에서 데이터 디렉터리 탭에 액세스하여 다음 표에 표시된 설정을 설정하고 확인합니다.

표: 온-프레미스 테스트를 위한 데이터베이스 서버에 대한 가상 머신 드라이브 요구 사항

드라이브 문자	Size	디렉터리 이름	경로
C	80	데이터 루트 디렉터리	<DriveLetter>:\Program Files\Microsoft SQL Server\
전자	500	사용자 데이터베이스 디렉터리	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
F	500	사용자 데이터베이스 로그 디렉터리	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
G	500	임시 DB 디렉터리	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
H	500	임시 DB 로그 디렉터리	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA

테스트 환경 설정

다양한 배포 단계에서 테스트 팀은 일반적으로 온-프레미스 아키텍처에서 먼저 작업한 다음 해당 Azure 환경에서 작업했습니다. 이는 사내 생산 농장이 이미 실행 중인 일반적인 실제 사례를 반영합니다. 더욱 중요한 것은 현재 프로덕션 워크로드, 용량 및 일반적인 성능을 알아야 한다는 것입니다. 비즈니스 요구 사항을 충족할 수 있는 재해 복구 모델을 빌드하는 것 외에도 복구 팜 서버의 크기를 조정하여 최소 수준의 서비스를 제공해야 합니다. 콜드 또는 웜 대기 환경에서 복구 팜은 일반적으로 프로덕션 팜보다 작습니다. 복구 팜이 안정되고 프로덕션 환경에서 워크로드 요구 사항을 충족하기 위해 팜을 스케일 업 및 스케일 아웃할 수 있습니다.

다음 세 단계로 테스트 환경을 배포했습니다.

• 하이브리드 인프라 설정

• 서버 프로비전

• SharePoint 팜 배포

하이브리드 인프라 설정

이 단계에는 온-프레미스 팜 및 Azure의 복구 팜에 대한 도메인 환경 설정이 포함되었습니다. 테스트 팀은 Active Directory 구성과 관련된 일반적인 작업 외에도 라우팅 솔루션과 두 환경 간의 VPN 연결을 구현했습니다.

서버 프로비전

팜 서버 외에도 도메인 컨트롤러에 대한 서버를 프로비전하고 RRAS와 사이트 간의 VPN을 처리하도록 서버를 구성해야 했습니다. DFSR 서비스에 대해 두 개의 파일 서버가 프로비전되었고 테스터를 위해 여러 클라이언트 컴퓨터가 프로비전되었습니다.

SharePoint 팜 배포

필요한 경우 환경 안정화 및 문제 해결을 간소화하기 위해 SharePoint 팜이 두 단계로 배포되었습니다. 첫 번째 단계에서 각 팜은 필요한 기능을 지원하기 위해 토폴로지의 각 계층에 대한 최소 서버 수에 배포되었습니다.

SharePoint 2013 서버를 만들기 전에 SQL Server 설치된 데이터베이스 서버를 만들었습니다. 새 배포이므로 SharePoint를 배포하기 전에 가용성 그룹을 만들었습니다. MCS 모범 사례 지침을 기반으로 세 개의 그룹을 만들었습니다.

참고

SharePoint 설치 전에 가용성 그룹을 만들 수 있도록 자리 표시자 데이터베이스를 만듭니다. 자세한 내용은 SharePoint 2013에 대한 SQL Server 2012 AlwaysOn 가용성 그룹 구성을 참조하세요.

팜을 만들고 다음 순서대로 추가 서버를 조인했습니다.

• SP-SQL-HA1 및 SP-SQL-HA2를 프로비전합니다.

• AlwaysOn을 구성하고 팜에 대한 세 가지 가용성 그룹을 만듭니다.

• 중앙 관리를 호스트하도록 SP-APP1을 프로비전합니다.

• SP-WFE1 및 SP-WFE2를 프로비전하여 분산 캐시를 호스트합니다.

명령줄에서 psconfig.exe 실행할 때 skipRegisterAsDistributedCachehost 매개 변수를 사용했습니다. 자세한 내용은 SharePoint Server 2013에서 피드 및 분산 캐시 서비스 계획을 참조하세요.

복구 환경에서 다음 단계를 반복했습니다.

• AZ-SQL-HA1 및 AZ-SQL-HA2를 프로비전합니다.

• AlwaysOn을 구성하고 팜에 대한 세 가지 가용성 그룹을 만듭니다.

• 중앙 관리를 호스트하도록 AZ-APP1을 프로비전합니다.

• 분산 캐시를 호스트하도록 AZ-WFE1 및 AZ-WFE2를 프로비전합니다.

분산 캐시를 구성하고 테스트 사용자 및 테스트 콘텐츠를 추가한 후 배포의 2단계를 시작했습니다. 이렇게 하려면 계층을 확장하고 팜 아키텍처에 설명된 고가용성 토폴로지를 지원하도록 팜 서버를 구성해야 했습니다.

다음 표에서는 복구 팜에 대해 설정한 가상 머신, 서브넷 및 가용성 집합에 대해 설명합니다.

표: 복구 팜 인프라

서버 이름	역할	구성	서브넷	가용성 집합
spDRAD	Active Directory를 사용하여 도메인 컨트롤러	프로세서 2개 512MB에서 4GB RAM까지 1 x 127GB 하드 디스크	sp-ADservers
AZ-SP-FS	백업에 대한 공유 및 DFSR용 엔드포인트가 있는 파일 서버	A5 구성: 프로세서 2개 14GB RAM 1 x 127GB 하드 디스크 1 x 135GB 하드 디스크 1 x 127GB 하드 디스크 1 x 150GB 하드 디스크	sp-databaseservers	DATA_SET
AZ-WFE1, AZ -WFE2	프런트 엔드 웹 서버	A5 구성: 프로세서 2개 14GB RAM 1 x 127GB 하드 디스크	sp-webservers	WFE_SET
AZ -APP1, AZ -APP2, AZ -APP3	응용 프로그램 서버	A5 구성: 프로세서 2개 14GB RAM 1 x 127GB 하드 디스크	sp-applicationservers	APP_SET
AZ -SQL-HA1, AZ -SQL-HA2	AlwaysOn 가용성 그룹에 대한 데이터베이스 서버 및 주 및 보조 복제본	A5 구성: 프로세서 2개 14GB RAM	sp-databaseservers	DATA_SET

운영

테스트 팀이 팜 환경을 안정화하고 기능 테스트를 완료한 후 온-프레미스 복구 환경을 구성하는 데 필요한 다음 작업 작업을 시작했습니다.

• 전체 및 차등 백업을 구성합니다.

• 온-프레미스 환경과 Azure 환경 간에 트랜잭션 로그를 전송하는 파일 서버에서 DFSR을 구성합니다.

• 주 데이터베이스 서버에서 로그 전달을 구성합니다.

• 필요에 따라 로그 전달을 안정화, 유효성 검사 및 문제 해결합니다. 여기에는 로그 전달 또는 DFSR 파일 동기화 실패를 유발하는 네트워크 대기 시간과 같은 문제를 일으킬 수 있는 동작을 식별하고 문서화하는 것이 포함되었습니다.

데이터베이스

장애 조치(failover) 테스트에는 다음 데이터베이스가 포함되었습니다.

• WSS_Content

• ManagedMetadata

• 프로필 DB

• DB 동기화

• 소셜 DB

• 콘텐츠 형식 허브(전용 콘텐츠 형식 배포 허브의 데이터베이스)

문제 해결 팁

이 섹션에서는 테스트 중에 발생한 문제 및 솔루션에 대해 설명합니다.

용어 저장소 관리 도구를 사용하면 "관리되는 메타데이터 저장소 또는 연결을 현재 사용할 수 없습니다."라는 오류가 발생했습니다.

웹 애플리케이션에서 사용하는 애플리케이션 풀 계정에 용어 저장소에 대한 읽기 권한이 있는지 확인합니다.

사용자 지정 용어 집합은 사이트 모음에서 사용할 수 없습니다.

콘텐츠 사이트 모음과 콘텐츠 형식 허브 간의 누락된 서비스 애플리케이션 연결을 확인합니다. 또한 관리되는 메타데이터 - <사이트 모음 이름> 연결 속성 화면에서 이 옵션이 사용하도록 설정되어 있는지 확인합니다. 이 서비스 애플리케이션은 열별 용어 집합의 기본 스토리지 위치입니다.

Get-ADForest Windows PowerShell 명령은 "'Get-ADForest'라는 용어가 cmdlet, 함수, 스크립트 파일 또는 작동 가능한 프로그램의 이름으로 인식되지 않습니다."라는 오류를 생성합니다.

사용자 프로필을 설정할 때 Active Directory 포리스트 이름이 필요합니다. 역할 및 기능 추가 마법사에서 Windows PowerShell Active Directory 모듈을 사용하도록 설정했는지 확인합니다(원격 서버 관리 도구 역할 관리 도구>>AD DS 및 AD LDS 도구 섹션 아래). 또한 Get-ADForest 를 사용하기 전에 다음 명령을 실행하여 소프트웨어 종속성이 로드되도록 합니다.

Import-Module ServerManager
Import-Module ActiveDirectory

'<서버 이름>'에서 'AlwaysOn_health' XEvent 세션 시작 시 가용성 그룹 만들기 실패

장애 조치(failover) 클러스터의 두 노드가 "일시 중지됨" 또는 "중지됨"이 아닌 상태 "위쪽"에 있는지 확인합니다.

파일 공유에 연결하려고 시도하는 액세스 거부 오류로 인해 로그 전달 작업이 실패하는 SQL Server

SQL Server 에이전트 기본 자격 증명 대신 네트워크 자격 증명으로 실행되고 있는지 확인합니다.

SQL Server 로그 전달 작업은 성공을 나타내지만 파일은 복사되지 않습니다.

가용성 그룹에 대한 기본 백업 기본 설정이 보조 선호이기 때문에 발생 합니다. 주 서버 대신 가용성 그룹에 대해 보조 서버에서 로그 전달 작업을 실행해야 합니다. 그렇지 않으면 작업이 자동으로 실패합니다.

관리되는 메타데이터 서비스(또는 다른 SharePoint 서비스)가 설치 후 자동으로 시작되지 않음

SharePoint Server의 성능 및 현재 부하에 따라 서비스를 시작하는 데 몇 분 정도 걸릴 수 있습니다. 서비스에 대한 시작을 수동으로 클릭하고 시작에 적절한 시간을 제공하면서 서버의 서비스 화면을 새로 고쳐 상태를 모니터링하는 경우도 있습니다. 서비스가 중지된 상태로 유지되는 경우 SharePoint 진단 로깅을 사용하도록 설정하고 서비스를 다시 시작한 다음 로그에서 오류를 확인합니다. 자세한 내용은 SharePoint 2013에서 진단 로깅 구성을 참조하세요.

DNS를 Azure 장애 조치(failover) 환경으로 변경한 후 클라이언트 브라우저는 SharePoint 사이트의 이전 IP 주소를 계속 사용합니다.

DNS 변경 내용이 모든 클라이언트에 즉시 표시되지 않을 수 있습니다. 테스트 클라이언트에서 관리자 권한 명령 프롬프트에서 다음 명령을 수행하고 사이트에 다시 액세스하려고 시도합니다.

Ipconfig /flushdns

추가 리소스

SharePoint 데이터베이스에 대해 지원되는 고가용성 및 재해 복구 옵션

SharePoint 2013용 SQL Server AlwaysOn 가용성 그룹 구성

참고 항목

Microsoft 365 솔루션 및 아키텍처 센터