• [アーティクル]

SharePoint の内部SharePoint データを保護する

Pav Cherny

目次

SharePoint データの保護レベル
コンポーネント化したアプローチを採用する
可用性の高いフロントエンド サブシステムを構築する
バックエンド サブシステムのデータを保護するオプション
データの回復に使用できるツール
ベスト プラクティス

バックアップ、復元、および障害回復戦略によるデータ保護は、新しいアプローチではありません。また、SharePoint には、一般的なディスク バックアップ、負荷分散、冗長性によるアプローチでは対応できない特殊な問題があります。

SharePoint におけるデータ保護の問題は、SharePoint のアーキテクチャにより、コンテンツ データと構成データがフロントエンド サーバーとバックエンド サーバーに保存されていることに起因します。たとえば、多くのコンテンツ データは SQL Server データベースまたは共有サービス プロバイダ (SSP) データベースに格納され、多くの構成データは構成データベースに格納されています。ただし、SharePoint では、バイナリ ファイル、レジストリ ハイブ、およびカスタマイズの情報などのフロントエンド サーバー コンポーネントに依存しています。

ご使用の環境のニーズに応じた形で SharePoint におけるデータ保護の問題に対応するには、許容できるダウンタイム (目標回復時間、RTO)、前回の復元可能なバックアップからデータ損失が発生した時点までの間で損失を許容できるデータ量 (目標回復ポイント、ROO) を検討する必要があります。RTO と RPO が少ないほど、コストが増加する傾向にあるということに注意してください。ミッション クリティカルではないデータや変化の少ないデータがある場合は、サービス レベル アグリーメント (SLA) に基づいて複数の RTO と RPO を定義できます。また、データセンターの分布や WAN 接続など、RTO と RPO に影響する依存関係も考慮する必要があります。

この記事では、SharePoint のデータ保護戦略と利用できるオプションを検討します。利用できるオプションには、RTO と RPO の高い低コストなアプローチ (組み込みのごみ箱の機能など) から、RTO と RPO が低い場合に利用できる可用性が高い高度なアプローチ (ミラー化、Data Protection Manager など) まで、さまざまなものがあります。この記事では、考えられるすべてのシナリオとアーキテクチャを取り上げることはできないので、最も一般的な問題とその解決方法を紹介します。

SharePoint データの保護レベル

データ保護に関する既存ドキュメントで紹介されている従来のアプローチでは、データを復元する頻度に基づいて SharePoint を 3 つの層に分けています。1 つ目の層は、過失によるデータの削除、ドキュメント、リスト、サイトの破損など、ユーザーが原因で復元が必要となるデータです。このデータを復元するためのメンテナンス タスクは、サイトの管理者またはエンド ユーザーが実行します。

2 つ目の層は、管理者がファーム レベルでタスクを行い、より高度なバックアップと復元を行う場所にあるデータです。これには、ハードウェア障害、移行、データベースの操作時にデータを復元して、ビジネスの継続性の維持が必要なデータが含まれます。

一般的に障害回復と呼ばれる 3 つ目の層では、冗長性を使用し、単一障害点を排除することによって、高可用性を維持できるようにインフラストラクチャをデザインする必要があります。図 1 に、この 3 つの層の詳細を示します。

fig01.gif

図 1 従来のデータ保護層

SharePoint データの保護を層という観点で見ると、バックアップ、復元、および高可用性の計画を立てたり、サポート担当者が問題の解決策を特定するのに役立ちますが、必ずしもベスト プラクティスに基づいたツールやトポロジが提供されるとは限りません。

確かに、少数のトポロジをすべての環境で採用するのは困難ですが、柔軟性があれば、ほとんどの構成を採用できます。個人的には、可能な限り冗長性と高可用性を組み込んでから、いくつかの高可用性ベースのトポロジ オプションを提供するという方法が好きです。

サーバーとトポロジのデザインから着手して、論理層としてフロントエンド サブシステムとバックエンド サブシステムに重点を置き、高可用性のベスト プラクティスを採用したアプローチを使用すると、データ保護機能を備えた環境を構築できます。

つまり、データを 3 つの層に分けて、障害や復元の要求に対応するのではなく、単一障害点をなくして、標準のサーバー構成を含む適切なデザインを作成することで、データ損失のリスクを低減できます。ここでは、フロントエンドの IIS サーバーと SharePoint アプリケーション サーバー (crawl/indexing など) は、どちらもフロントエンド サブシステムの一部だと考えています。

コンポーネント化したアプローチを採用する

SharePoint データの保護戦略を調査するときには、マイクロソフトからガイダンスやベスト プラクティスを学ぶようにしています。製品ドキュメントだけではなく、デザイン、展開、および運用を管理している Microsoft IT も、この対象になります。

Microsoft IT では、インフラストラクチャの全要素を簡略化し、運用手順を標準化するイニシアチブを採用しています。このイニシアチブでは、問題の 80% 以上が第一線で任務に当たっているサポート担当者や現地まで出向いてサポートを提供する担当者が解決できるようにすることを目的としています。このイニシアチブは、SharePoint のインフラストラクチャとデータ保護も対象としています。

Microsoft IT のイニシアチブにおける主要な目的の 1 つは、標準の構成ブロックを作成して、簡単に展開してスケール アップとスケール アウトを行える物理コンポーネントと論理コンポーネントで構成された、標準の構成ブロックを作成することでした。図 2 に、この構成ブロックの例を示します。

fig02.gif

図 2 SharePoint の展開ブロックとインフラストラクチャ ブロック

Microsoft IT から学んだ、もう 1 つのアプローチは、データがある場所に基づいてデータ保護をコンポーネント化する方法でした。実際、このアプローチでは、フロントエンド ブロックとバックエンド ブロックを個別の要素として考える必要があります。予算とリソースが許す範囲で高い可用性を確保し、高可用性によりバックアップと復元の処理を削減します。たとえば、負荷分散構成のフロントエンド サーバーを使用して、すべてのカスタム データをコンテンツ データベースと構成データに格納することで、フロントエンド サーバーのバイナリ データとシステム状態データをバックアップする必要がなくなります。というのも、これが入れ替え可能なビルド ブロックの一部になっているからです。

可用性の高いフロントエンド サブシステムを構築する

一見すると、高可用性を確保するのは、コストがかかり、行き過ぎた処理であるように思われるかもしれません。特に、これまでテープにバックアップするというような昔ながらのアプローチが問題なく機能していた場合はそうでしょう。ですが、基本的なレベルでは、フロントエンド サーバーとアプリケーション サーバーで冗長性を確保するのは、コストが高いものでも、実装が難しいものでもありません。テープが破損したり、長時間にわたるダウンタイムが発生したりした場合の方がコストが高くなります。

ごく基本的なレベルで考えると、フロントエンド サブシステムのビルド ブロックは 4 台のサーバーで構成されています。そのうち 2 台のサーバーでは IIS を負荷分散の構成で実行し、残り 2 台のサーバーでは、Excel Calculation Services、Project Server、インデックスの作成など、アプリケーションの役割を実行しています。必要であれば、負荷分散の構成で実行している IIS サーバーとアプリケーション サーバーを別のブロックと見なすことができます。

この構成では、データをバックアップするという必要はなくなりません。web.config などのファイルに変更を加えた場合は、そのコピーを保持する必要があります。代替アクセス マッピング (AAM) など、IIS と SharePoint の構成設定も含め、構成設定のドキュメントを作成して保管する必要があります。IIS のメタデータ、XML マスター ファイル、構成ファイルのバックアップを作成し、ドキュメントに記載した手順を使用して、SSL 証明書のインストールなど、標準的な展開を再構成できます。ドキュメントを作成して、カスタマイズの内容を整理しておくと、代替ブロックを迅速に展開して組み込めるというメリットがあります。

バックエンド サブシステムのデータを保護するオプション

既に説明したように、SharePoint では、コンテンツ データと構成データを SQL Server データベースに格納しています。そのため、標準の構成を採用したコンポーネント化によるアプローチを使用すると、フロントエンド サーバーのバックアップを作成する必要をなくすことが可能です。フロントエンド サーバーのバックアップを作成する必要がなくなれば、SQL Server データベースに注力できます。

SharePoint では SQL Server に大きく依存しているので、バックアップに関する考慮事項は、SharePoint に直接関係するものではなく、SQL Server 寄りのものになります。

SharePoint のレベルで考えると、SharePoint は SQL Server と連動しているので、オプションはバックアップ操作と復元操作の UI になります。SQL Server のレベルで考えると、デザインについて検討してから、そのデザインがバックアップと復元の手順にどのような影響を与えるのかを検討する必要があります。

SQL Server のデータを保護する 1 つ目のオプションはスナップショットです。これは、ある特定の時点におけるデータベースの静的なバージョンで読み取り専用です。スナップショットは、ユーザーや管理者による誤操作が原因で、以前のソース データベースのバージョンに戻す場合などに便利です。スナップショットの詳細については、msdn.microsoft.com/ja-jp/library/ms187054(SQL.90).aspx を参照してください。

2 つ目のオプションは、ログ配布です。この機能は、アクティブなプライマリ サーバーからスタンバイ サーバーに転送されたトランザクション ログ ファイルに依存しています。プライマリ サーバーで障害が発生した場合には、操作を手動でスタンバイ サーバーにフェールオーバーして、配布されたログを復元できます。

ログ配布には自動フェールオーバーの機能はありません。また、ログを復元して、スタンバイ サーバーをオンライン状態にする手順により、復元には時間がかかることがあります。詳細については、msdn.microsoft.com/ja-jp/library/ms187103.aspx を参照してください。

3 つ目のオプションはミラーリングです。この機能は、ログ配布と組み合わせて使用するもので、SQL Server 2005 以降で使用できます。ミラーリングは、完全復旧モデルを使用しているデータベースで機能し、ホット スタンバイ サーバーへのクイック フェールオーバーをサポートしています。高い安全性、高いパフォーマンス、高可用性という 3 つのモードがあります。SharePoint 環境で最も一般的なモードは、高可用性です。このモードでは、ミラーリング監視サーバーによって自動フェールオーバーがサポートされます。また、ミラーリングでは、ログを手動で復元する必要がないので、ログ配布より処理が高速です。詳細については、go.microsoft.com/fwlink/?linkid=83725&clcid=0x411 を参照してください。

4 つ目と 5 つ目のオプションは、複製とクラスタリングです。レプリケーションを使用すると、中央で管理されているメインのデータセンターにデータをコピーできるので、複数のデータセンターが地理的に離れた場所にある場合に便利です。レプリケーションを使用して、いくらかのデータ保護機能を提供できますが、このオプションは、離れた場所のパフォーマンス向上を目的に使用することが多いです。

フェールオーバー クラスタリングでは、OS からストレージ サブシステムを分離することによって、コンポーネント化の概念を発展しています。クラスタリングを使用すると、複数の物理サーバーが、記憶域ネットワーク (SAN) などの共通のストレージ システムに依存するようになります (クラスタリングでは、ストレージ システムが単一障害点になるという問題を解決できないことに注意してください)。

最も一般的な高可用性ソリューションは、クラスタリングとミラーリングです。ログ配布は、ダウンタイムを許容できる場合または予算に制約がある場合に使用します。ミラーリングとクラスタリングのどちらを採用するかを検討する際には、クラスタリングでは共有のストレージ サブシステムを使うことが多く、ミラーリングでは明示的にミラー化されたデータベースのみが保護されることを考慮する必要があります。詳細については、technet.microsoft.com/ja-jp/library/ms179410.aspx を参照してください。

データの回復に使用できるツール

フロントエンド サブシステムとバックエンド サブシステムで安定した高可用性のデザインを採用していても、データの回復が必要になることがあります。たとえば、ユーザーまたは管理者が、リスト、ドキュメント、サイトを間違って削除したり、ファーム全体の可用性に影響する変更をファーム レベルで行ったりした場合には、データを回復する必要があります。また、自然災害など、サービスの回復が不可能となる不測の事態が発生することもあります。このような場合に役立つツールは多数ありますが、その例を次に示します。

  • バージョン管理: これは、ドキュメント ライブラリの機能で、ドキュメントとリストに使用できます。これは SharePoint のデータ保護機能の一環として用意されているものですが、既定では無効になっています。バージョン管理では、フォルダー、Web、またはサイトはサポートされません。バージョン管理を有効にすると、ユーザーは、管理者の手を煩わせることなく、以前のバージョンにアクセスできます。
  • ごみ箱: ユーザーは、この機能を使用して、リスト、ドキュメント、ドキュメント ライブラリ、フォルダー、リスト アイテムをサイトで復元できます。また、サイトのコレクション レベルで、サイトの管理者としてごみ箱にアクセスすることもできます。この機能は Web アプリケーション レベルで構成されています。
  • Microsoft IT Site Delete Capture: このツールでは、SPWebEvent­Receiver.WebDeleting メソッドを使用して、サイト レベルで、ごみ箱のような機能を提供します。SharePoint オブジェクト モデルの WebDeleting メソッドを使用すると、サイトのカスタム バックアップ機能を作成できます。詳細については、msdn.microsoft.com/ja-jp/library/microsoft.sharepoint.spwebeventreceiver.webdeleting.aspx を参照してください。
  • Stsadm.exe: このコマンド ライン ツールを使用すると、コンテンツを復元する際の柔軟性が高まります。サイト コレクション、satabse、Web アプリケーション、またはファーム全体をバックアップおよび復元できます。コマンドとコンテキストの詳細については、technet.microsoft.com/ja-jp/library/cc263441.aspx を参照してください。
  • サーバーの全体管理のバックアップ機能: これは SharePoint に用意されている GUI ツールで、ファーム、コンテンツ データベース、または Web アプリケーションのバックアップ作成に使用できます。
  • Data Protection Manager (DPM): Microsoft System Center 製品ファミリの 1 つです。DPM を使用すると、15 分おきにバックアップを作成して SharePoint のデータを保護し、ファーム、サイト コレクション、サイト、ドキュメント ライブラリなど、任意のレベルでデータを復元できます。DPM を使用する最大のメリットは、データベースのバックアップをプレステージしたり、マウントしたりする必要なく、アイテムを直接復元できることです。
  • サードパーティ製のツール: サードパーティ製のツールが、すべてのシナリオで問題なく動作することを期待していると厄介です。そのツールが SharePoint と Windows Server のボリューム シャドウ コピー サービスの機能とどの程度統合されるのかということと、バックアップと復元処理を行った後に実行する必要がある手順について検討する必要があります。このようなツールは、Quest、AvePoint、Commvault などの企業から入手できます。

ベスト プラクティス

SharePoint のデータを保護するコンポーネント化したアプローチを使用すると、デザイン要素をバックアップ ツールおよび復元ツールと組み合わせて、目標の RTO と RPO をクリアすることが可能です。たとえば、すべてのサーバーで標準の構成を使用すると、フロントエンド サーバーのバックアップを作成する必要がなくなります。その他には、次のようなベスト プラクティスがあります。

  • バックアップと復元のそれぞれに個別のツールと手順を用意する。バックアップの機能と復元の機能の両方が用意されているツールもありますが、この 2 つの処理は個別に考えることをお勧めします。というのも、高可用性のオプションとバックアップの粒度は、実行する復元の種類と必ずしも対応しないからです。また、バックアップと復元の処理にはオーバーヘッドが伴い、完了までに時間がかかります。これらの処理の計画を個別に立てることで、環境をより厳密に管理できるようになります。
  • ドキュメントを作成する。少なくとも、サーバー、トポロジ、SharePoint の設定、IIS の設定、バックアップと復元の手順についてのドキュメントは作成することをお勧めします。このドキュメントは、SharePoint 外の場所に保管する必要があります。
  • テストして確認する。復元タスクを実行して、データを回復できることを確認して、計画と手順に問題がないことを確認します。
  • シンプルにして、一元管理する。コンポーネント化した要素を使用することは、構成を簡略化および標準化する方法の 1 つです。一元管理、データセンター トポロジの簡略化など、他のオプションについても検討することをお勧めします。

Pav Cherny は、主にコラボレーションとユニファイド コミュニケーションに関するマイクロソフト テクノロジを扱う IT 専門家であり、IT 関連書籍の執筆も行っています。これまでに、IT の運用とシステム管理についてのホワイト ペーパー、製品マニュアル、書籍などを執筆してきました。Pav は、ドキュメント管理とローカライズ サービスの専門企業 Biblioso Corporation の代表取締役です。