SharePoint Server での高可用性および障害回復の概念

[アーティクル]
03/08/2023

適用対象: yes-img-13 2013 yes-img-16 2016 yes-img-19 2019 yes-img-se Subscription Edition no-img-sop SharePoint in Microsoft 365

SharePoint Server ファームの計画とシステム仕様を作成するとき、高可用性と障害復旧は最優先になります。ファームサーバーが高可用性ではなく、またファームが復旧できない場合は、高性能と十分な容量といった、計画のその他の側面は無意味になります。

効率的で中断のない運用を維持する効果的な戦略を設計、実装するには、高可用性と障害復旧の基本的な概念を理解する必要があります。また、これらの概念は、SharePoint 環境での最良の技術ソリューションを評価し、選ぶ際に重要です。

ビジネス継続性管理の概要

ビジネス継続性管理は、組織の継続的な実行に対するリスクを定義、評価、管理するのに役立つ管理プロセスまたはプログラムです。事業継続管理では、業務継続計画の作成と維持に重点を置いています。これは、通常の業務が不利な条件によって中断された場合の継続操作のロードマップです。これらの条件は、自然、人工、または両方の組み合わせにすることができます。継続計画は、次の分析と入力から派生します。

ビジネス影響分析
脅威およびリスク分析
影響シナリオの定義
一連の文書化された復旧要件

この結果は、ソリューション設計または識別された選択肢、実装計画、テストおよび組織受領計画、保守計画または予定となります。

ビジネス継続性管理の一例として、障害復旧およびデータとアプリケーションの保護は、Microsoft のビジネス継続性プログラムの一端を示しています。

当然、情報技術 (IT) は、多くの組織のビジネス継続計画の重要な側面です。ただし、ビジネス継続性はより包括的です。これには、大規模な破壊的イベントの間と直後に組織が引き続きビジネスを継続できるようにするために必要なすべての操作が含まれています。ビジネス継続計画には、次の要素が含まれますが、これらに限定されません。

ポリシー、過程、および手順
選択肢と意志決定責任
人的資源と施設
情報技術

高可用性および障害復旧は、しばしばビジネス継続性管理と同一視されますが、これらは、実際には、ビジネス継続性管理の一部でしかありません。

高可用性とは

特定のソフトウェアアプリケーションまたはサービスで、高可用性は、最終的には、エンドユーザーの体験と予測事項として測定されます。ダウンタイムの、具体的で認知されるビジネス影響は、情報損失、物品の損害、生産性の減少、機会費用、契約上の損害、または信用の損失として表れることがあります。

The principal goal of a high availability solution is to minimize or mitigate the impact of downtime. A sound strategy for this optimally balances business processes and Service Level Agreements (SLAs) with technical capabilities and infrastructure costs.

プラットフォームは、顧客および関係者の期待に応え、合意を得てはじめて高可用性であるとみなされます。システムの利用可能時間は、以下の計算で表せます。

実際の稼働時間/予期された稼働時間 X 100%

一般的に、結果の値は、ソリューションが実現する 9 の数で示されます。ここから、年間の稼働時間、または逆に、ダウンタイムの時間が導かれます。

9 の数	利用可能時間の割合	年間ダウンタイムの合計
2	99%	3 日、15 時間
3	99.9%	8 時間 45 分
4	99.99%	52 分 34 秒
5	99.999%	5 分 15 秒

計画されたダウンタイムと予定外のダウンタイム

システムの機能停止は、予定または計画されている場合と、予定外の障害の結果であることがあります。適切に管理されている場合、ダウンタイムは問題とみなす必要はありません。予測可能なダウンタイムには、主な種類が 2 つあります。

計画メンテナンス。 期間は事前に発表され、ソフトウェア修正プログラムの適用、ハードウェアのアップグレード、パスワードの更新、オフラインのインデックス作成、データの読み込み、ディザスターリカバリー手順のリハーサルなどの計画メンテナンスタスクに合わせて調整されます。慎重かつ適切に管理された運用手順により、ダウンタイムを最小限に抑え、データ損失を防ぐ必要があります。計画メンテナンスアクティビティは、計画外のその他の重大な停止シナリオを防止または軽減するために必要な投資と見なすことができます。
予定外の停止。 予定外または制御不可、あるいは予測可能だが発生の可能性が低いか影響が許容可能と見なされる、システムレベル、インフラストラクチャ、またはプロセス障害が発生することがあります。信頼性の高い高可用性ソリューションは、これらの種類の障害を検出して、機能停止から自動的に回復して、次にフォールトトレランスを再確立します。

高可用性の SLA を設定するとき、計画された保守作業と予定外のダウンタイムについて、個別の主要業績評価指標 (KPI) を計算する必要があります。この手法により、予定外のダウンタイムを回避する利点に対する、計画された保守作業への投資を比較できます。

利用可能時間の減少

高可用性は、妥協を許さない提案とみなすべきではありません。エンドユーザーにとっては、完全な機能停止を避けられる場合は、システムが一部のみ使用可能であることや、機能やパフォーマンスに制限が出ることは、一般的に許容範囲内です。利用可能時間の程度には、以下のものがあります。

読み取り専用および延期された作業。 メンテナンス時間中、または段階的に実行される障害復旧中に、データ取得はできますが、新しいワークフローまたはバックグラウンド処理が一時的に停止されるか、またはキューに入れられることがあります。
データ遅延とアプリケーション反応性。 重い負荷、処理中のバックログ、または部分的なプラットフォーム障害によって、一部のハードウェアリソースに過度に負荷がかかることや、容量不足になることがあります。ユーザーエクスペリエンスの質が低下し、生産性は下がりますが、作業は行うことができます。
部分的障害、一時的障害、または発生が予測される障害。 安定性の機能として、アプリケーションロジックまたはハードウェアスタックで、エラー発生時に再試行や自己修正を繰り返すことがあります。これは、エンドユーザーには、データ遅延またはアプリケーションの反応性の低下として表れることがあります。
部分的なエンドトゥエンドの障害。 機能停止は、計画されたものと予定外のものにかかわらず、ソリューションスタック (インフラストラクチャ、プラットフォーム、およびアプリケーション) の垂直レイヤーで、または、さまざまな機能コンポーネントの間で水平的に、正規の手順に沿って行うことができます。影響を受ける機能またはコンポーネントによって、ユーザーは、部分的に正常な機能を使えるか、機能低下を感じることがあります。

これらの次善のシナリオが受け入れられるものかどうかは、完全な機能停止に至る、利用可能時間の低下の連続体の一部として、また、段階的に実行する障害復旧の中間の手順として考える必要があります。

ダウンタイムを数値化する

計画されたものか予定外のものかにかかわらず、ダウンタイムが発生したとき、主なビジネス目標は、システムをオンライン状態に復帰し、データ損失を最小限にすることです。ダウンタイムには、分刻みで、直接および間接的な費用が発生します。予定外のダウンタイムが発生したとき、機能停止が発生した理由、現在のシステム状態、機能停止からの回復に必要な手順を判定するのに必要な時間と作業を調整する必要があります。

機能停止後の一定の時点で、機能停止の原因調査または保守タスクの中止をする、または、システムを再度オンラインにして機能停止から回復し、必要に応じて、フォールトトレランスを再確立するビジネス判断を、自分で行うか、または他者に依頼する必要があります。

復旧の目標

データ冗長性は高可用性データベースソリューションの主要な構成要素です。プライマリ SQL Server インスタンスのトランザクション操作は、同期的または非同期に、1 つまたは複数のセカンダリインスタンスに適用されます。機能停止が発生したとき、実行中のトランザクションはロールバックされるか、データ伝達の遅延があればセカンダリインスタンスで失われることがあります。

業務再開までに掛かる時間と、復旧された最後のトランザクションの待機時間がどれだけかについて、影響の測定と、復旧目標の設定の両方を実行できます。

目標復旧時間 (RTO)。 これは機能停止の継続時間です。初期の目標は、障害の調査が容易になるように、少なくとも読み取り専用となるようにシステムをオンラインに戻すことです。しかし、主要な目的は、新しいトランザクションが行えるようになるまで、完全なサービスを復旧することです。
目標復旧時点 (RPO)。 これは、一般的に許容範囲内のデータ損失の基準と呼ばれます。これは、障害前に最後に確定されたデータトランザクションと、障害後に復旧された最新のデータ間の時間差または遅延です。実際のデータ損失は、障害時のシステムのワークロード、障害の種類、使用された高可用性ソリューションの種類によって変わることがあります。

注:

関係する目標として、 復旧レベル目標 (RLO) があります。この目標は、データを復旧するときの復旧範囲の単位 (ファーム全体、Web アプリケーション、サイトコレクション、サイト、リストまたはライブラリ、あるいはアイテム) を定義します。詳細については、「 SharePoint Server でのバックアップと回復を計画する」を参照してください。

RTO 値と RPO 値は、ダウンタイムおよび許容範囲内のデータ損失の、ビジネス許容範囲を指定する目標として、また、可用性正常性を監視する測定基準として使用する必要があります。

ROI または機会費用を正当化する

ダウンタイムのビジネス費用は、財務への影響か、顧客信用の低下として表れることがあります。これらのコストは、時間と共に蓄積するか、機能停止での特定の時点で発生します。特定の復旧時間およびデータ復元ポイントでの、機能停止の費用予測に加えて、RTO および RPO 目標を達成するか、機能停止を完全に回避する目的で必要なビジネスプロセスおよびインフラストラクチャ投資を計算できます。これらの投資テーマには、以下を含める必要があります。

ダウンタイムの回避。 機能停止がそもそも発生しなければ、機能停止復旧にかかる費用は発生しません。投資には、フォールトトレラントで冗長なハードウェアまたはインフラストラクチャの費用、分離された障害ポイント間でのワークロードの分散、予防的保守による計画されたダウンタイムが含まれます。
復旧の自動化。 システム障害が発生したとき、自動的で透過的な復旧を使用すれば、ダウンタイムが顧客体験に悪影響を及ぼすことを大幅に軽減できます。
リソース利用率。 セカンダリまたはスタンバイインフラストラクチャは、機能停止に備えて、アイドル状態のまま待機します。読み取り専用のワークロードに使用するか、すべての使用可能なハードウェア間でワークロードを分散することによって全体的なシステムパフォーマンスを向上することに活用できます。

特定の RTO および RPO の目標で、ダウンタイムの推定費用と組み合わせた、必要とされる利用可能時間および復旧投資は、時間の関数として示し、正当化できます。これにより、実際の機能停止中に、ダウンタイム経過時間に基づいてコストベースの判断ができます。

可用性正常性を監視する

運用上の観点からは、実際の機能停止中に、すべての関連する変数を検討して、ROI または機会費用をリアルタイムで計算するべきではありません。むしろ、スタンバイインスタンスのデータ遅延を、予測される RPO のプロキシとして監視する必要があります。

また、機能停止が起こったときに、機能停止中に、根本原因を初期調査するのに時間をかけすぎないようにする必要があります。むしろ、復旧環境の正常性を確認することに重点を置き、以後の精密分析用には、詳細なシステムログと、データの 2 次的なコピーを使用する必要があります。

障害復旧の計画

高可用性の取り組みには、機能停止を防ぐことが必要ですが、障害復旧の取り組みでは、機能停止後に高可用性を、再度、確立する目的で行う作業が重要です。

実際の機能停止が発生する前に、できる限り、障害復旧の手順と責任を確立する必要があります。アクティブな監視および通知に基づいて、自動化または手動のフェールオーバーおよび復旧計画を開始する判断は、事前に確立された RTO および RPO しきい値と結び付けられる必要があります。適切な障害復旧計画の範囲には、以下を含める必要があります。

障害と復旧の詳細さ。 障害の場所と種類によって、データセンター、インフラストラクチャ、プラットフォーム、アプリケーション、ワークロードなどの、さまざまなレベルで修正処置を行うことができます。
調査用資料。 ベースラインと最近の監視履歴、システム通知、イベントログ、診断クエリは、すべて、適切な関係者が容易に入手可能である必要があります。
依存関係の調整。 アプリケーションスタック内で、また関係者間で、システムおよびビジネス上の依存関係は何でしょうか。
決定木。 ロールの責任、障害トリアージ、RPO と RTO の目標に関するフェールオーバー条件、および規定された復旧手順を含む、事前に定義された反復可能な検証済みのデシジョンツリー。
検証。 機能停止から回復する手順を行った後で、システムが通常動作に戻ったことを確認する目的で行う必要があることはなんでしょうか。
ドキュメンテーション。 上記のすべての項目をドキュメントのセットに取り込み、十分な詳細と明確さを備え、サードパーティチームが最小限の支援を受けて復旧計画を実行できるようにします。この種類のドキュメントは、一般に "実行ブック" または "クックブック" と呼ばれます。
回復リハーサル。 ディザスターリカバリー計画を定期的に実行して、RTO 目標のベースライン期待を確立し、プライマリと各ディザスターリカバリーサイトでプライマリ運用サイトをホストする定期的なローテーションを検討します。

次の方法で共有