SharePoint Server 用の障害回復戦略を選ぶChoose a disaster recovery strategy for SharePoint Server

適用対象:はい2013 yes2016 yes2019 SharePointOnline なしAPPLIES TO: yes2013 yes2016 yes2019 noSharePoint Online

この記事での障害復旧とは、SharePoint Server ファームをホストするプライマリ データ センターが機能しなくなった場合に、その状況から復旧することです。発生したイベントやその原因にかかわらず、データ センターの停止は、組織の障害復旧計画に定義された処置を実行に移すべき重大な事態です。これはイベントの影響を受けていないデータ センターのコンピューター リソースを使って、完全に機能するファームを運用に移すことを意味します。We define disaster recovery as the ability to recover from a situation in which the primary data center that hosts a SharePoint Server farm is unable to continue to operate. Regardless of the nature of event and its cause, the data center outage is significant enough to set into motion the actions defined in your organization's disaster recovery plan. This means putting a fully operational farm into production using computer resources that are located in a data center that is not affected by the event.

SharePoint Servers 2019、2016、2013、およびそれらをサポートしている SQL Server は、障害があった場合にビジネスに必要とされる目標復旧時間 (RTO) と目標復旧時点 (RPO) を達成できる構成およびコンテンツ復旧オプションを備えています。これらの概念およびその他の障害復旧の概念については、「SharePoint Server での高可用性および障害回復の概念」を参照してください。SharePoint Servers 2019, 2016, 2013, and the SQL Servers that support them provide configuration and content recovery options that can meet the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) that are required for your business if there is a disaster. For more information about these and other disaster recovery concepts, see High availability and disaster recovery concepts in SharePoint Server.

はじめにIntroduction

SharePoint Server ファームでの有効な障害復旧戦略は、組織のビジネス要件を十分に満たすものである必要があります。復旧戦略の策定には、目標復旧時間 (RTO) と目標復旧時点 (RPO) という 2 つの測定値が一般的に使われます。RTO と RPO の要件は、障害が起きたときにダウンタイムで生じる組織へのコストによって判断されます。An effective disaster recovery strategy for a SharePoint Server farm must be sufficient to meet your organization's business requirements, which are typically expressed by using two measures: Recovery Time Objective (RTO) and Recovery Point Objective (RPO). RTO and RPO requirements are derived by determining the downtime cost to the organization if a disaster happens.

重要

ベスト プラクティスとして、復旧戦略を策定して技術ソリューションを実装する前に、組織の RTO と RPO を明確にし、数値化することをお勧めします。要件を達成する方法ではなく、要件の内容に焦点を当ててください。As a best practice we recommend that you clearly identify and quantify your organization's RTO and RPO before you develop a recovery strategy and implement a technical solution. Focus on what is required, not how to do it.

ダウンタイムが与える影響はさまざまであるため、ダウンタイムのコストは業種ごとおよび業種内でも大きなばらつきがあります。ビジネスの規模は、最も顕著な要素です。しかし、原因はビジネス規模だけではありません。測定値を設定すると、障害の性質と影響が明確になります。大まかに言うと、重要なアプリケーションで障害が起きた場合は次のような損失が生じます。Downtime costs vary significantly between and within industries, especially due to the different effects of downtime. Business size is the most obvious factor. However, it is not the only one. Setting a measure means establishing the nature and implications of the failure. Reduced to the simplest level, a failure of a critical application could lead to the following types of losses:

  • アプリケーション サービスの損失。 ダウンタイムの影響は、アプリケーションおよびビジネスごとに異なります。Loss of the application service. The effect of downtime varies with the application and the business.

  • データの損失。システムの停止によって起こり得るデータの損失は、法的および財務的に大きな影響を与える場合があります。Loss of data. The potential loss of data due to a system outage can have significant legal and financial impact.

ほとんどの組織で上記の 2 種類の損失からダウンタイム コストが生じますが、一番大きな影響をもたらす損失の種類は、ビジネスの性質に左右されます。eWEEK 誌のクリス プライムスバーガー氏は、「予定外の IT ダウンタイムは 1 分間につき 5,000 ドルの損失をもたらす: レポート (Unplanned IT Downtime Can Cost $5K Per Minute: Report)」で、データ センターのダウンタイムが及ぼす財務的影響を紹介しています。Most organizations will incur a downtime cost from both of the previous types of loss but the nature of the business will determine which type of loss has the biggest effect. The following article, written by Chris Preimesberger at eWEEK, highlights the financial effect of data center downtime. Unplanned IT Downtime Can Cost $5K Per Minute: Report.

障害と見なされるデータ センターのシャットダウンが発生したとき、ほとんどの場合、回復しなければならないアプリケーションの 1 つは SharePoint 製品 です。このため、この記事では障害復旧計画に関する情報ではなく、別の場所で SharePoint Server ファームを復旧するためのオプションに重点を置いています。In most scenarios, SharePoint products is one of several applications that must be recovered in the event of a data center shutdown that qualifies as a disaster. For this reason we have not included information about disaster recovery planning but focus on options for making sure that you can recover your SharePoint Server farm at another location.

障害の種類とその規模にかかわらず、ファームの復旧はスタンバイ データ センターの使用を伴います。Regardless of the type and scale of a disaster, recovery involves the use of a standby data center that you can recover the farm to.

スタンバイ データ センターの復旧オプションStandby data center recovery options

プライマリ データ センターでローカルの冗長なシステムおよびバックアップを障害から回復できない場合、スタンバイ データ センターが必要になります。別の場所にある代替ファームを稼働させるための方策は、時間および緊急度別に、ホット スタンバイ、ウォーム スタンバイ、コールド スタンバイと呼ばれています。この記事では、これらのファーム復旧データ センターを次のように定義します。Standby data centers are required for scenarios where local redundant systems and backups cannot recover from the outage at the primary data center. The time and immediate effort to get a replacement farm up and running in a different location is often known as a hot, warm, or cold standby. Our definitions for these farm recovery data centers are as follows:

  • コールド スタンバイ 。数時間から数日で可用性を提供できるセカンダリ データ センター。Cold standby. A secondary data center that can provide availability within hours or days.

  • ウォーム スタンバイ。数分から数時間で可用性を提供できるセカンダリ データ センター。Warm standby. A secondary data center that can provide availability within minutes or hours.

  • ホット スタンバイ。数秒から数分で可用性を提供できるセカンダリ データ センター。Hot standby. A secondary data center that can provide availability within seconds or minutes.

これらのスタンバイ データ センターには、固有の特質および要件があり、関連する運用費や維持費が異なります。Each of these standby data centers has specific characteristics and requirements, and also an associated cost to operate and maintain.

  • コールド スタンバイの障害復旧戦略: ベア メタル回復を行うためのバックアップをローカルおよび地域のオフサイト ストレージに定期的に提供し、他の地域で緊急用のサーバーをレンタルする契約を締結している。Cold standby disaster recovery strategy: A business ships backups to support bare metal recovery to local and regional offsite storage regularly, and has contracts in place for emergency server rentals in another region.

    Pros: 通常、運用の観点から見ると、維持費が最も安価。障害の発生後に物理サーバーを適切に構成する必要があるため、通常は復旧コストが高価。Pros: Often the cheapest option to maintain, operationally. Often an expensive option to recover, because it requires that physical servers be configured correctly after a disaster has occurred.

    Cons: 復旧に最も時間がかかる。Cons: The slowest option to recover.

  • [Azure Site Recovery](https://docs.microsoft.com/ja-JP/azure/site-recovery/site-recovery-sharepoint) のウォーム スタンバイの障害復旧戦略。Warm standby disaster recovery strategy with [Azure Site Recovery](https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-sharepoint).

    Pros: 復旧の際に仮想サーバー ファームを構成する必要がほとんどないため、通常は復旧コストが比較的安価。Pros: Often fairly inexpensive to recover, because a virtual server farm can require little configuration upon recovery.

    Cons: 維持費が高価で、時間がかかる可能性がある。Cons: Can be very expensive and time-consuming to maintain.

  • ホット スタンバイの障害復旧戦略: 複数のデータ センターを運用しているが、1 箇所のデータ センターのみでコンテンツとサービスを提供している。Hot standby disaster recovery strategy: A business runs multiple data centers, but serves content and services through only one data center.

    Pros: 通常、比較的短時間で復旧できる。Pros: Often fairly fast to recover.

    Cons: 構成コストおよび維持費が高価。Cons: Can be very expensive to configure and maintain.

重要

上記のどの障害復旧ソリューションを適用する場合でも、いくらかのデータ損失が発生する可能性があります。No matter which of the previous disaster recovery solutions that you decide to apply, there is likely going to be some data loss.

コールド スタンバイの復旧Cold standby recovery

コールド スタンバイの障害復旧シナリオでは、復旧するには、(なるべくスクリプト化された展開を使用して) 新しい場所に新しいファームを設定し、バックアップを復元します。あるいは、System Center - Data Protection Manager (DPM) のようなバックアップ ソリューションを使ってファームを復元することもできます。DPM は、コンピューター オペレーティング システム レベルでデータを保護し、各サーバーを個別に復元できます。この記事では、コールド スタンバイ シナリオについて、スタンバイ環境の作成方法や復旧方法などの詳細は扱っていません。詳しくは、以下を参照してください。In a cold standby disaster recovery scenario, you recover by setting up a new farm in a new location (preferably by using a scripted deployment) and restoring backups. Or, you can recover by restoring the farm using a backup solution such as System Center - Data Protection Manager (DPM). DPM protects your data at the computer operating system level and lets you restore each server individually. This article does not contain detailed instructions for how to create and recover in cold standby scenarios. For more information, see:

ウォーム スタンバイの復旧Warm standby recovery

ウォーム スタンバイの障害復旧シナリオでは、代替データ センターにファームの複製を作成することによりウォーム スタンバイ環境を作成し、プライマリ ファームの完全バックアップと増分バックアップを使ってそれを定期的に更新します。In a warm standby disaster recovery scenario, you create a warm standby environment by creating a duplicate farm at the alternate data center and ensure that it is updated regularly by using full and incremental backups of the primary farm.

仮想ウォーム スタンバイ環境Virtual warm standby environments

仮想化は、有効でコスト効果の高いウォーム スタンバイ復旧 ソリューションを提供します。Hyper-V をインハウス ソリューションとして使用するか、Azure をホストされたソリューションとして使用して、復旧に必要なインフラストラクチャを提供できます。Virtualization provides a workable and cost effective option for a warm standby recovery solution. You can use Hyper-V as an in-house solution or Azure as a hosted solution to provide necessary infrastructure for recovery.

運用サーバーの仮想イメージを作成し、そのイメージをスタンバイ データ センターに送ることができます。仮想スタンバイ ソリューションを使用する場合は、ファームの復旧のために十分なレベルのファーム構成と最新のコンテンツを提供できるように、仮想イメージの作成を頻繁に行う必要があります。セカンダリの場所では、イメージを構成および結合してファームをすぐに再現できるような環境を用意しておく必要があります。詳細については、Azure で SharePoint Server 2016 と SQL Server の AlwaysOn 可用性グループを展開する を参照してください。You can create virtual images of the production servers and ship these images to the standby data center. By using the virtual standby solution, you have to make sure that the virtual images are created often enough to provide the level of farm configuration and content freshness that you must have for recovering the farm. At the secondary location, you must have an environment available in which you can easily configure and connect the images to re-create your farm environment. For more information, see Deploying SharePoint Server 2016 with SQL Server AlwaysOn Availability Groups in Azure

ホット スタンバイの復旧Hot standby recovery

ホット スタンバイの障害復旧シナリオでは、スタンバイ データ センターにフェールオーバー ファームを設定して、プライマリ ファームがオフラインになったら、ほとんど間髪を入れずに処理を引き継ぐことができるようにします。別個のフェールオーバー ファームがある環境には、次の特徴があります。In a hot standby disaster recovery scenario, you set up a failover farm in the standby data center so that it can assume production operations almost immediately after the primary farm goes offline. An environment that has a separate failover farm has the following characteristics:

  • 別個の構成データベースとSharePoint サーバーの全体管理 Web サイトのコンテンツ データベースをフェールオーバー ファームで管理する必要があります。A separate configuration database and the SharePoint Central Administration website content database must be maintained on the failover farm.

  • 両方のファームにカスタマイズをすべて展開する必要があります。All customizations must be deployed on both farms.

    ヒント

    2 箇所のファーム間の整合性を維持し、エラーの発生を削減するため、スクリプト化された展開を使用して、同じ構成設定とカスタマイズを適用してプライマリとフェールオーバー ファームを作成することをお勧めします。There is consistency between the two farms and to reduce the possibility of error we recommend that you use scripted deployment to create the primary and failover farm by using the same configuration settings and customizations.

  • オペレーティング システム、SQL Server、SharePoint Serverのソフトウェア更新プログラムを両方のファームに適用して、ファーム間で一貫した構成を維持する必要があります。Operating system, SQL Server and SharePoint Server software updates must be applied to both farms, to maintain a consistent configuration across both farms.

  • SharePoint Server のコンテンツ データベースをフェールオーバー ファームにコピーするには、非同期ミラーリング、可用性グループのレプリカでの非同期コミット、またはログ配布を使用できます。You can copy SharePoint Server content databases to the failover farm by using asynchronous mirroring, asynchronous commit on an availability group replica, or log-shipping.

    注意

    SQL Server のミラーリングでは、データベースを単一のミラー サーバーにしかコピーできませんが、ログ配布は複数のセカンダリ サーバーに対して実行できます。SQL Server mirroring can only be used to copy databases to a single mirror server, but you can log-ship to multiple secondary servers.

    SQL Server データベース ミラーリング機能は将来のバージョンで削除されます。新しい展開ではこの機能の使用を避けることをお勧めします。現在この機能を使用しているアプリケーションを変更するようにご計画ください。代わりに AlwaysOn 可用性グループを使用します。The SQL Server database mirroring feature will be removed in future versions. We recommend that you avoid using this feature in new deployments. Plan to change applications that currently use this feature. Use AlwaysOn Availability Groups instead.

  • サービス アプリケーションは、ファームにログ配布できる場合とそうでない場合があります。詳細については、後述の「サービス アプリケーションの冗長性」を参照してください。Service applications vary in whether they can be log-shipped to a farm. For more information, see Service application redundancy later in this article.

1 つ以上の追加のデータ センターへの SQL Server のログ配布を構成する場合は、ホットスタンバイのファーム トポロジを複数のデータ センターで繰り返すことができます。The hot standby farm topology can be repeated across more than one data center, as long as you configure SQL Server log shipping to one or more additional data centers.

重要

障害復旧でフェールオーバー アプローチを使用する場合は、使用可能なネットワーク帯域幅と待機時間が重要な検討事項になります。データ センターでホット スタンバイ レベルの可用性を実現するために、SQL データベースのための SAN レプリケーションを使用するか、別のサポートされたメカニズムにするかについて、SAN ベンダーに問い合わせてください。SharePoint サーバーのために SAN レプリケーションを使用することはサポートされていませんので、ご注意ください。Available network bandwidth and latency are major considerations when you are using a failover approach for disaster recovery. We recommend that you consult with your SAN vendor to determine whether you can use SAN replication for SQL databases or another supported mechanism to provide the hot standby level of availability across data centers. Note that using SAN replication for SharePoint servers is not supported.

サービス アプリケーションの冗長性Service application redundancy

サービス アプリケーションに対するデータ センターでの可用性を実現するには、ファーム間で実行できるサービスについては、プライマリおよびセカンダリのどちらのデータ センターからでもアクセスできる別個のサービス ファームを運用することをお勧めします。To provide availability across data centers for service applications, we recommend that for the services that can be run cross-farm, you run a separate services farm that can be accessed from both the primary and the secondary data centers.

ファーム間で実行できないサービスについて、サービス ファーム自体の可用性を実現する場合、データ センターでサービス アプリケーションの冗長性を実現する戦略にはさまざまなものがあります。使用する戦略は、次の事項によって左右されます。For services that cannot be run cross-farm, and to provide availability for the services farm itself, the strategy for providing redundancy across data centers for a service application varies. The strategy employed depends on whether:

  • サービス アプリケーションが使用されていないとき、障害復旧ファームでそれを実行することにビジネス価値があるかどうか。There is business value in running the service application in the disaster recovery farm when it is not being used.

  • サービス アプリケーションに関連付けられているデータベースをログ配布、非同期ミラーリング、または非同期コミットを使用してレプリケートできるかどうか。The databases associated with the service application can be log-shipped, asynchronously mirrored, or replicated using asynchronous commit.

  • サービス アプリケーションを読み取り専用データベースに対して実行できるかどうか。The service application can run against read-only databases.

ウォームまたはホット スタンバイ データ センターを使用する障害復旧ソリューションを設計する前に、「サポートされている SharePoint データベース用の高可用性と障害回復のオプション」の記事を参照してください。Review the Supported high availability and disaster recovery options for SharePoint databases article before designing a disaster recovery solution that uses a warm or hot standby data center.

復旧のためのシステム要件System requirements for recovery

理想的なシナリオでは、フェールオーーバーとプライマリのコンポーネントおよびシステムは、プラットフォーム、ハードウェア、サーバー数などのあらゆる点で一致します。少なくとも、フェールオーバー環境では、フェールオーバーの実行時に予想されるトラフィックを処理できる必要があります。ただし、フェールオーバー サイトは、必ずしもすべてのユーザーにサービスを提供する必要がない点に注意してください。フェールオーバーとプライマリのシステムは、少なくとも次の点で一致している必要があります。In an ideal scenario, the failover components and systems match the primary components and systems in all ways: platform, hardware, and number of servers. At a minimum, the failover environment must be able to handle the traffic that you expect during a failover. Keep in mind that only a subset of users may have to be served by the failover site. The systems must match in at least the following:

  • オペレーティング システムのバージョンとすべての更新プログラムOperating system version and all updates

  • SQL Server バージョンとすべての更新プログラムSQL Server versions and all updates

  • SharePoint Server バージョンとすべての更新プログラムSharePoint Server versions and all updates

上記の要件に加えて、ファームの復旧時間は、設備およびインフラストラクチャ コンポーネントの可用性の影響も受けます。次の要件が満たされていることを確認してください。In addition to the previous requirements, farm recovery time will also be affected by availability of facilities and infrastructure components. Make sure that the following requirements are met:

  • 電源、冷却、ネットワーク、ディレクトリ、および SMTP が完全に冗長化されている。Power, cooling, network, directory, and SMTP are fully redundant

  • ニーズに合った切り替えメカニズム (DNS またはハードウェア負荷分散) の選択。Choose a switching mechanism; whether DNS or hardware load balancing, that meets your needs.

関連項目See also

概念Concepts

SharePoint Server での高可用性および障害回復の概念High availability and disaster recovery concepts in SharePoint Server

その他のリソースOther Resources

Azure Site Recovery で保護できるワークロードとはWhat workloads can you protect with Azure Site Recovery?

Azure Site Recovery を使用して障害復旧の多層 SharePoint アプリケーションをレプリケートするReplicate a multi-tier SharePoint application for disaster recovery using Azure Site Recovery