SharePoint Server の高可用性のアーキテクチャと戦略を作成する
適用対象:
2016 2019 Subscription Edition 
SharePoint in Microsoft 365
高可用性戦略は、SharePoint Server の運用環境にとって重要な要件です。 エンド ツー エンド戦略には、運用プロセス、プラットフォーム ガバナンス、アーキテクチャ、および技術ソリューションが含まれます。 この記事では、高可用性のアーキテクチャと技術の側面に重点を置いて説明します。 説明する内容は、特定の SharePoint 設計の要素と、高可用性のための戦略を決定する技術のオプションです。
注:
高可用性と障害復旧は同じではありません。 計画とソリューションには重なる部分がありますが、それらはビジネス継続性の一部です。 高可用性の目的は、プライマリ データ センター内での回復性と、計画されたダウンタイムを実現することです。 障害復旧の目的は、プライマリ データセンターに障害が起こり、インフラストラクチャが使用不能になった場合に、セカンダリ データ センターでコンピューターの運用を再開できるようにすることです。 SharePoint Server の障害復旧の詳細については、「SharePoint Server 用の障害回復戦略を選ぶ」を参照してください。
通常、高可用性とは、障害ドメインでハードウェア、ソフトウェア、アプリケーションという分類のうち 1 つ以上の分類の障害が発生した場合にも、動作し続けてユーザーにリソースを提供するシステムの能力のことを言います。 可用性のレベルは、システムが継続的に動作してビジネス機能をサポートする時間の割合を測定単位として表します。 必要な可用性のレベルは組織によって異なります。 この要件はビジネス単位ごとに異なる可能性がありますが、サービス レベル契約は組織全体に適用されます。 ユーザーの観点から見ると、SharePoint ファームは、ユーザーがファームにアクセスし、自分の作業に必要な機能とサービスを使用できる場合に使用できます。
可用性の高い SharePoint ファームには、次のような目標と特徴があります。
ファームは潜在的な障害点が少なくなるように設計されています。 すべての障害点をなくすことはできないため、全体的な戦略で障害イベントに対処する必要があります。
フェールオーバー イベントはシームレスで、ユーザー活動への影響は最小限です。
ファームは完全に動作停止するのではなく、能力を縮小して継続的に動作します。
ファームには回復性があります。 サービスに影響を与える事象は頻繁には発生せず、発生した場合にはタイムリーで効果的な処置が実行されます。
概要
SharePoint 環境用に現実的で経済的な高可用性のアーキテクチャと戦略を作成するには、その前に、可用性の目標を定義し、数値化する必要があります。 可用性の目標には、組織が SharePoint Server にどれだけ依存しているか、また、サービスの停止が組織の運用にどのような影響があるかを反映させます。 サービス停止の影響は、全部のサービスが停止したのか、または一部のサービスが停止したのかによって、また、サービス停止の期間によって異なります。
成功する高可用性戦略には、組織の特定のニーズが反映されている必要があります。 さらに、ビジネス要件、IT サービス レベル契約 (SLA)、および技術ソリューションの可用性、IT サポート能力、およびインフラストラクチャ コストの間で最適なバランスを実現することも必要です。
組織の可用性の要件を特定した後、高可用性の設計とダウンタイムとサービス低下のリスクを低減する戦略の作成を開始できます。 可用性の高いシステムを設計し展開する IT 担当者は、目標達成のためのガイドとして次の原則に従ってください。
障害ドメインごとの単一障害点と、可能なすべてのレイヤー (オペレーティング システム、ソフトウェア、および SharePoint アプリケーション) のシステム全体での単一障害点を除去します。
非常に高速な障害の検出、切り分け、および解決を実装します。
高可用性ソリューションは広範囲に及び、定義済みの必要なサービスを提供するために統合されたシステム全体の共有リソースのセットを提供します。 このソリューションでは、ハードウェアとソフトウェアのさまざまな組み合わせを使用してダウンタイムを最小限に抑え、システムまたはシステムの一部で障害が発生したときにサービスを復元します。
フォールト トレラント ソリューションはハードウェア中心のソリューションであり、特別なハードウェアを使用して障害を検出し、直ちに冗長なハードウェア コンポーネントに切り替えます。 このコンポーネントはプロセッサ、メモリ ボード、電源、I/O サブシステム、ストレージ サブシステムのいずれかです。 冗長コンポーネントへの切り替えにより高レベルのサービスを実現します。
フォールト トレラントのソリューションと高可用性ソリューションのコスト効果分析によって、組織は SharePoint ファームの可用性の目標を達成するための効果的な戦略をたてることができます。 一般的に、2 つのソリューションの間にはコストの妥協点があります。
高可用性を実装するプロセスは、SharePoint ファームの中で比較的高価な投資の 1 つです。 求める可用性のレベルと高可用性システムの数が大きくなるにつれて、可用性ソリューションの複雑さとコストも増加します。
仮想化技術の進歩により、組織は仮想コンピューターをホット、ウォーム、またはコールド スペアとして使用できるようになりました。 同じ機能を提供するために仮想コンピューターが適している場合もあります。 仮想化は柔軟性とコスト効率性をもたらします。 ただし、置き換える物理コンピューターの負荷を処理するだけの容量が仮想マシンにあることを確認する必要があります。
高可用性をサポートするファーム アーキテクチャの作成
次の図は、ファーム全体の可用性向上のために SharePoint 環境のさまざまな部分を分散させて構成する方法を示しています。 この例は、冗長性によって障害ドメインに対処する方法も示しています。
注:
ここに記載する例は包括的なものではありません。 たとえば、障害ドメインとフォールト トレラント ハードウェアの一部は示されていません。
障害点に対処するためのファーム トポロジの冗長性の例
前に示した図のトポロジに関して、次の点に注意してください。
この例のファーム サーバーは物理コンピューターか、Hyper-V ホスト サーバーに展開された仮想マシンのいずれかです。 障害点の特定と障害点への対応の原則は、両方の種類の環境に適用されます。
4 台のサーバー (W1 ～ W4) は、コンテンツ提供専用サーバーであり、この冗長性によって、1 台以上のサーバーで障害が発生した場合の可用性が向上します。 また、このレベルの冗長性により、ソフトウェア更新プログラムを適用するときもファームは継続的に動作できます。
4 台のアプリケーション サーバー (A1 から A4) により、ファーム サービスおよび検索などの特定のアプリケーション コンポーネントの可用性が向上します。 検索の役割とコンポーネントは冗長化されています。
ファーム データベース サーバーは冗長化されており、データベースのミラーリングまたはクラスタリングによってデータベースの高可用性を実現できます。
仮想環境では、単一障害点を排除するため、仮想マシンは別々の Hyper-V ホスト サーバーに配置されます。 仮想マシンの配置に対するこのアプローチは、可用性とパフォーマンスのベスト プラクティス ガイドに従ったものです。
プライマリ データベース サーバー (図では 1) と、仮想ホスト コンピューターのうち 2 台を含むラック 2 (図では 2) は、障害ドメインとして特定されており、ファームとインフラストラクチャを複数のフォールト ドメインの集まりとしてとらえられることを示しています。 この図は、環境を掘り下げて分析し、全体的な戦略とコスト効果分析を作成する方法を表しています。
ファームのその他の役割とサービス
この例では、特定の SharePoint ファームで実行される役割、サービス、サービス アプリケーションをすべて示しているわけではありません。 SharePoint ファーム内のあらゆる要素の高可用性に対して、汎用的なアプローチを使用することはできません。 高可用性に対する標準的なアプローチでの重要な除外項目を次に示します。
分散キャッシュについては、フェールオーバー時に特別な考慮が必要です。 「分散キャッシュ サービスの計画」と「分散キャッシュ サービスを管理する (SharePoint Server)」を参照してください。
SharePoint ワークフローでは、Workflow Manager 1.0 の累積的な更新プログラム 3 が必要です。 SharePoint Server 2013 の場合と同じ SharePoint Server 2016 のワークフローを構成します。 詳細については、「3 の累積的な更新のワークフロー マネージャー 1.0 の説明」および「Workflow Manager 1.0 での高可用性ワークフローの構成」を参照してください。
注:
SharePoint Server 2016 のワークフローの構成は、SharePoint Server 2013 から変更されていません。 Workflow Manager 1.0 の累積的な更新プログラム 3 をインストールする必要があります。
サービス アプリケーションは複数のコンピューターで実行できますが (推奨)、高可用性に関する独自のインストールおよび構成の要件を持つアプリケーションもあります。 User Profile アプリケーションは、よく知られている例です。
高可用性ソリューションでのフォールト トレランスの使用
可用性の高いロールとワークロードをサポートするアーキテクチャを設計した後、フォールト トレラント コンポーネントを使用して可用性を向上させることができます。 フォールト トレラント ソリューションは、データベースを含むインフラストラクチャ全体で使用できます。
フォールト トレラント インフラストラクチャ
フォールト トレランスは、SharePoint ファームのインフラストラクチャ内のほぼすべてのハードウェアですぐに利用可能です。 高可用性の設計の一環として、運用およびコストの面からインフラストラクチャのどの部分をフォールト トレラントにする必要があるかを決定します。 インフラストラクチャのすべての部分をフォールト トレラントにすることは可能ですが、必ずしもそうする必要はありません。
フォールト トレラントなデータベース サーバーおよびデータベース
SharePoint プラットフォームとそのアプリケーション ワークロードは、すべての SharePoint データベースの可用性と信頼性に依存しているため、可用性の高いデータベースは高可用性戦略の観点からきわめて重要です。 Sharepoint データベース サーバーおよびデータベース用のフォールト トレラント ソリューションとして次の機能を使用できます。
SQL Server フェールオーバー クラスタリング (Sql Server 2014 の Always On フェールオーバー クラスター インスタンス (FCI) と Service Pack 1 (SP1)) と SQL Server 2012
Always On 可用性グループ
SQL Server 高可用性データベース ミラーリング
Always On フェールオーバー クラスター インスタンスと Always On 可用性グループについて
フェールオーバー クラスターには、2 台のコンピューター間に共有ディスク ストレージが必要です。 2 ノード構成の場合、コンピューターをアクティブ/パッシブとして構成し、完全に冗長なプライマリ ノード インスタンスを実現します。 パッシブ ノードはプライマリ ノードに障害が発生した場合にのみオンラインになります。 共有ディスクは一度に 1 台のコンピューターに対してのみ表示されます。 この構成は一般的に追加ハードウェアの必要性が最も大きくなります。 SQL Server 2014 (SP1) と SQL Server 2012 では、この種類のクラスター構成は Always On フェールオーバー クラスター インスタンスであり、SQL Server をインストールするための特定の方法です。 構成の要件により、標準の SQL Server インストールをフェールオーバー クラスター インスタンスに簡単に変更することはできません。
Always On 可用性グループは、Windows クラスタリングによって公開される一部の機能を使用する SQL Server 2014 (SP1) と SQL Server 2012 (データベース ミラーリングの子孫と考える) とは異なるテクノロジです。 一方、この可用性グループは共有ディスク ストレージを必要とせず、可用性グループ内のコンピューターにインストールされている SQL Server の特別な構成も必要ありません。 データベース サーバーを Windows クラスターに追加した後は、Always On 可用性グループを有効にしてから、必要な可用性グループを構成するのが非常に簡単です。
要約すると、SQL Server 2014 (SP1) と SQL Server 2012 Enterprise Edition を実行するサーバーは、クラスターに参加し、可用性グループを構成することで Always On 可用性グループを使用できます。 Always On フェールオーバー クラスターでは、フェールオーバー クラスター インスタンスを設定するための特別なハードウェアと構成の手順が必要です。 これらの各テクノロジは、特定の環境に使用されており、どちらも補完的な競合他社です。 これらの機能の詳細については、「高可用性ソリューション (SQL Server)」を参照してください。 使用する SQL Server 可用性テクノロジの決定については、「 ビジネス継続性とデータベースの復旧 - SQL Server」を参照してください。
重要
SQL Server 高可用性オプションにはそれぞれ独自の機能、強み、弱点があるので、あるオプションが別のオプションよりも必ずしも優れているわけではありません。 たとえば、Always On 可用性グループを使用する特定のシナリオでは、Always On フェールオーバー クラスター インスタンスが実現するパフォーマンス向上よりも、データ損失を最小限に抑える方が優れている可能性があります。 ビジネスの要件と IT インフラストラクチャの要件に基づいた高可用性ソリューションを選択する必要があります。
使用する SQL Server オプションを選択する際の決定要因は、SharePoint データベースです。 SharePoint Server データベースの特徴を理解する必要があります。 各データベースには特定の要件や制約があり、それによって、運用環境に適した完全にサポートされる SQL Server のフォールト トレラント ソリューションが決定します。 次の記事を確認することをお勧めします。
SQL Server フェールオーバー クラスタリング
フェールオーバー クラスタリングは、SQL Server 2014 (SP1) または SQL Server 2012 の SQL Server に可用性を提供します。
フェールオーバー クラスターは、1 つ以上のノードまたはサーバーと、2 つ以上の共有ディスクを組み合わせたものです。 フェールオーバー クラスターのインスタンスは単一のコンピューターとして表示されますが、現在のノードが使用不能になった場合は、このインスタンスで 1 つのノードから別のノードへのフェールオーバーが実行されます。 SharePoint Server は、SQL Server がサポートするクラスター内のアクティブ ノードとパッシブ ノードを任意に組み合わせたノード上で実行できます。
SharePoint Server はクラスター全体を参照します。 したがって、SharePoint Server から見たフェールオーバーは自動的かつシームレスです。
注:
計画されたフェールオーバーまたは計画外のフェールオーバーが発生すると、接続は切断され、1 つのクラスター ノードから別のクラスター ノードへの移行時に再び接続を確立することが必要になります
SQL Server フェールオーバー クラスタリングの詳細については、「 Always On フェールオーバー クラスター インスタンス (SQL Server)」を参照してください。
SQL Server Always On 可用性グループと SQL Server データベース ミラーリング
SQL Server Always On 可用性グループと SQL Server データベース ミラーリングの主な利点は、トランザクション処理用に構成する方法に応じて、完全またはほぼ完全なデータ冗長性を提供することです。 自動フェール オーバーはデータ損失を最小限にするだけでなく、運用データベースのダウンタイムも最小化します。
重要
SQL Server 2016、SQL Server 2014 (SP1)、SQL Server 2012 はデータベース ミラーリングをサポートしていますが、この機能は推奨されなくなります。 新しい開発作業ではこの機能の使用を避けることをお勧めします。 現在この機能を使用しているアプリケーションを変更するようにご計画ください。 代わりに Always On 可用性グループを使用します。
Always On 可用性グループ
SQL Server Always On 可用性グループ機能は、データベース ミラーリングに代わるエンタープライズ レベルの代替手段を提供する高可用性とディザスター リカバリーの両方のソリューションです。 Always On 可用性グループは、ユーザー定義コレクションに含まれる 1 つ以上のユーザー データベースのフェールオーバー環境をサポートします。 このコレクション (可用性グループ) は以下のコンポーネントから構成されます。
レプリカ。これは、単一のユニットとして処理される可用性データベースと呼ばれる個別のユーザー データベースのセットです。 可用性グループは、1 つのプライマリ レプリカと最大 4 つのセカンダリ レプリカをサポートします。
SQL Server の特定のインスタンス。各レプリカをホストし、可用性グループに属している各データベースのローカル コピーを維持します。
可用性グループがターゲット インスタンスまたはターゲット サーバーにフェールオーバーすると、グループ内のすべてのデータベースもフェールオーバーされます。 SQL Server 2014 (SP1) と SQL Server 2012 は 1 つのサーバーで複数の可用性グループをホストできるため、Always On を構成して、異なるサーバー上の SQL Server インスタンスにフェールオーバーできます。 これにより、可用性グループの多くの利点の 1 つであるプライマリ サーバーの全負荷を処理するためのアイドル状態の高パフォーマンス スタンバイ サーバーの必要性が軽減されます。
注:
データ ファイルの消失、データベースの削除、トランザクション ログの破損が原因でデータベースの信用性が疑わしくなるなどのデータベースの問題によってフェールオーバーが発生することはありません。
Always On 可用性グループの利点と Always On 可用性グループの用語の概要の詳細については、「 Always On 可用性グループ (SQL Server)」を参照してください。
データベース ミラーリング
注:
SQL Server 2016、SQL Server 2014 (SP1)、SQL Server 2012 はデータベース ミラーリングをサポートしていますが、この機能は推奨されなくなります。 新しい開発作業ではこの機能の使用を避けることをお勧めします。 現在この機能を使用しているアプリケーションを変更するようにご計画ください。 代わりに Always On 可用性グループを使用します。
データベース ミラーリングは、プライマリ データベース サーバーにミラー化されたデータベースのコピーを保持することにより、データベースの冗長性を確保します。 ミラーリングはデータベース単位で実装され、完全復旧モデルを使用しているデータベースでのみ有効です。
注:
2 種類のミラーリング運用モデルがあります。 その 1 つである「高い安全性モード」では、同期操作がサポートされます。 高い安全性モードでは、セッションが開始されると、ミラー サーバーがミラー データベースとプリンシパル データベースをできるだけ高速に同期化します。 データベースが同期化されるとすぐに、トランザクションがセカンダリ サーバーのログに書き込まれ、再現されます (トランザクションが確定されると、直ちに制御はプリンシパル サーバーに戻ります)。 (制御は、トランザクションが強化されるとすぐにプリンシパル サーバーに戻ります)。もう 1 つのミラーリング モードは高パフォーマンスで、非同期操作を使用してトランザクションの待機時間を短縮し、データ損失が増加します。
SharePoint ファームで高可用性ミラーリングを行うには、自動フェールオーバーで高い安全性モードを使用する必要があります。 安全性の高いデータベース ミラーリングには、プリンシパル、ミラー、ミラーリング監視の 3 つのサーバー インスタンスが必要です。 ミラーリング監視サーバーを使用すると、SQL Server はプリンシパル サーバーからミラー サーバーに自動的にフェールオーバーできます。 通常、プリンシパル データベースからミラー データベースへのフェールオーバーには数秒かかります。
データベース ミラーリングの概要については、「データベース ミラーリング」を参照してください。
重要
SQL Server FILESTREAM リモート BLOB ストア プロバイダーを使用するように構成されたデータベースは、ミラー化できません。
単一ファームに適用するデータベースの可用性および復元の戦略の比較
高可用性と障害復旧のための SQL Server 技術は、目標復旧時点 (RPO) および目標復旧時間 (RTO) に対する、組織のビジネス目標に基づいて選択する必要があります。 一般的に RPO と RTO は障害復旧に関連付けられますが、障害復旧の範疇ではないものの、プライマリ データセンターのローカル バックアップ メディアからの復旧を必要とする障害イベントもあります。
重要
特定のデータベースによっては、さまざまな SharePoint Server データベースで特定の SQL Server 高可用性オプションのみがサポートされます。 詳細については、「サポートされている SharePoint データベース用の高可用性と障害回復のオプション」を参照してください。
次の表に、使用可能な SQL Server ソリューションで実現される RPO および RTO の結果の比較を示します。
注:
次の表に示す時間は、データベース オプションを比較するためのものです。 実際には、すべての時間はワークロード、データ量、およびフェールオーバー手順によって異なります。
データベース技術に基づく RPO と RTO の比較
| SQL Server ソリューション | データ損失の可能性 (RPO) | 可能な復旧時間 (RTO) | 自動フェールオーバー |
読み取り可能なセカンダリ 手記： SharePoint Server では、ランタイムの使用のために読み取り可能なセカンダリ レプリカがサポートされています。 詳細については、「 2014 年 4 月の Office 2013 累積的な更新プログラム 」および 「SharePoint Server で読み取り専用データベースを使用するファームを実行する」を参照してください。 |
|---|---|---|---|---|
| Always On 可用性グループ (同期コミット) |
ゼロ |
秒 |
はい |
0 ～ 2 |
| Always On 可用性グループ (非同期コミット) |
秒 |
分 |
いいえ |
0 ～ 4 |
| Always On フェールオーバー クラスター インスタンス |
適用しません FCI 自体はデータ保護を提供しません。 データ損失の量はストレージ システムの実装によって異なります。 |
秒～分 |
はい |
適用しません |
| データベース ミラーリング - 高い安全性 (同期モード + ミラーリング監視サーバー) |
ゼロ |
秒 |
はい |
適用しません |
| データベース ミラーリング - 高パフォーマンス (非同期モード) |
秒 |
分 |
いいえ |
適用しません |
| バックアップ、コピー、復元 |
時間、または障害後にログの末尾にアクセスできる場合はゼロ |
時間～日 |
いいえ |
復元中は適用しません |
SQL Server クラスター、Always On 可用性グループ、データベース ミラーの比較
| プロセス | SQL Server フェールオーバー クラスター | SQL Server 2014 (SP1) と SQL Server 2012 Always On 可用性グループ | SQL Server 高可用性ミラー |
|---|---|---|---|
| フェールオーバーにかかる時間 |
障害の後ほぼ瞬時にクラスター メンバーが引き継ぎます。 クラスター ノードが起動するまで遅延が発生します。 |
障害の後ほぼ瞬時にレプリカが引き継ぎます。 セカンダリ レプリカが起動するまで遅延が発生します。 |
再実行キューが処理されるとすぐにミラーが引き継ぎます。 |
| トランザクションの一貫性 |
はい |
はい |
はい |
| トランザクションの同時実行 |
はい |
はい |
はい |
| 復旧時間 |
可用性グループよりも短い復旧時間。 |
フェールオーバー クラスターよりも長く、ミラー化されたソリューションよりも短い 復旧時間。 |
クラスターまたは可用性グループよりもわずかに長い復旧時間 |
| フェールオーバーに必要な手順 |
データベース ノードが障害を自動的に検出します。 SharePoint Server がクラスターを参照するため、フェールオーバーはシームレスで自動的です。 |
可用性グループ リスナーが障害を自動的に検出し、フェールオーバーはシームレスで自動的です。 |
データベースが障害を自動的に検出します。 SharePoint Server はミラーの場所を認識しています (自動的にフェールオーバーするよう正しく構成されている場合)。 |
| 障害が発生したストレージに対する保護 |
フェールオーバー クラスター自体はデータ保護を提供しません。 データ損失の量は実装されているストレージ システムによって異なります。 たとえば、SAN 環境には複数のファイル パス、RAID、ホット スペアなどの冗長コンポーネントがあります。 |
プライマリ レプリカがセカンダリ レプリカにあるローカル ディスクに書き込み、障害が発生したストレージを保護します。 |
プリンシパルとミラーの両方のデータベース サーバーがローカル ディスクに書き込み、障害が発生したストレージを保護します。 |
| サポートされるストレージの種類 |
専用ストレージよりも高コストな共有ストレージが必要です。 |
低コストの直接接続されたストレージ ソリューションを使用できます。 |
低コストの直接接続されたストレージを使用できます。 |
| 場所の要件 |
クラスターのメンバーは同じサブネット上に存在する必要があります。 Note: これは SQL Server 2014 (SP1) および SQL Server 2012 には該当しません。 |
遅延によるパフォーマンスの問題が発生しない限り、レプリカはさまざまなサブネット上に存在できます。 |
プリンシパル、ミラー、およびミラーリング監視サーバーは同じ LAN 上に存在する必要があります (遅延 1 ミリ秒以下のラウンド トリップ)。 |
| 復旧モデル |
SQL Server の完全復旧モデルをお勧めします。 SQL Server の単純復旧モデルを使用できます。 ただし、クラスターが失われた場合に使用可能な復旧ポイントは、最後の完全バックアップになります。 |
SQL Server 2014 (SP1) および SQL Server 2012 の完全復旧モデルが必要です。 |
SQL Server 完全復旧モデルが必要です。 |
| パフォーマンスのオーバーヘッド |
フェールオーバー実行中にパフォーマンス低下が発生する場合があります。 フェールオーバー中はサーバーが利用できなくなり、接続は切断されてから新しいアクティブなノードで再度確立されます。 |
Always On 可用性グループでは、セカンダリ レプリカでの同期コミットが原因でトランザクション待機時間が発生します。 待機時間の長さは、同期する必要があるセカンダリ レプリカの数によって異なります。 メモリとプロセッサのオーバーヘッドはクラスタリングよりも大きく、ミラーリングよりも少なくなります。 |
高可用性ミラーリングは同期的に行われるためトランザクションの待機時間が発生します。 また、追加のメモリとプロセッサのオーバーヘッドが生じます。 |
| 操作のオーバーヘッド |
サーバー レベルで設定および保守します。 |
操作のオーバーヘッドはクラスタリングおよびミラーリングよりも大きくなります。 Always On には、Windows Server レベルに加えて、SQL Server データベース サーバーのレベルでのオーバーヘッドが必要です。 メモ: ログオンやエージェントのジョブなどのサーバー レベル オブジェクトは手動で管理する必要があります。 コンテンツ データベースを追加する場合、可用性グループにデータベースを追加してから、プライマリ レプリカをセカンダリ レプリカに対して同期化する必要があります。 SharePoint ファーム環境では、SharePoint Server 接続文字列が可用性グループのリスナー名に正しく関連付けられていることを確認するために、複数の構成ステップを実行する必要があります。 |
操作オーバーヘッドはクラスタリングよりも大きくなります。 すべてのデータベースに対して設定し、管理する必要があります。 フェールオーバー後の再構成は手動で行います。 メモ: ログオンやエージェントのジョブなどのサーバー レベル オブジェクトは手動で管理する必要があります。 コンテンツ データベースを追加する場合、プリンシパルにデータベースを追加してから、プリンシパルをミラーに同期化する必要があります。 |
2 つのデータ センターを単一ファーム ("ストレッチド" ファーム) として構成することによる高可用性の実現
企業によっては、データ センター間を近接した場所に設置し、高帯域幅光ファイバーで接続しています。 こうした環境では、2 つのデータ センターを単一のファームとして構成できます。 このような分散ファーム トポロジを "ストレッチド" ファームと呼びます。
サポートされている高可用性ソリューションとしてストレッチド ファーム アーキテクチャを動作させるには、以下の前提条件を満たしている必要があります。
There is a highly consistent intra-farm latency of <1ms (one way), 99.9% of the time over a period of ten minutes. (Intra-farm latency is commonly defined as the latency between the front-end web servers and the database servers.)
帯域速度が少なくとも秒速 1 ギガビットであること。
ストレッチド ファームにフォールト トレランスを持たせる場合は、標準的なベスト プラクティスのガイダンスに従って、冗長性のあるサービス アプリケーションとデータベースを構成してください。
次の図はストレッチド ファームを示しています。
ストレッチド ファーム
高可用性戦略へのバックアップと復元の操作の組み込み
SharePoint ファームの復元力を確保するために、高可用性戦略には適切なバックアップと復元の運用を組み込む必要があります。 メディア障害やユーザー エラーのような事態が発生した場合、ファーム環境またはファーム データのうち影響を受けた部分をタイムリーに復旧できる必要があります。 効果的なバックアップと復元のソリューションを使用して、定義した目標復旧時間 (RTO) と目標復旧時点 (RPO) を達成できるようにする必要があります。