SharePoint 2010: 冗長性と可用性が確保されるように SharePoint 2010 を構築する
高可用性と冗長性について考慮して SharePoint 2010 を展開すると、多くのメリットを得られます。
William Stanek
SharePoint 2010 ほど大きなメリットが得られる見込みのあるプラットフォームは、ほとんどありません。冗長性と可用性を考慮して SharePoint 展開環境を構築すると、展開した環境は、真に期待に応える数少ないプラットフォームになります。どのような規模の企業でも、環境を入念に計画するための時間を確保することで得られるメリットがあります。
SharePoint 2010 は、以前のバージョンの SharePoint とは異なっています。現在 SharePoint Portal Server 2003 または Microsoft Office SharePoint Server (MOSS) 2007 を使用している場合は、現在の環境から直接 SharePoint 2010 にアップグレードする方法がないときがあります。SharePoint 2010 は、64 ビット版の Windows Server 2008 か Windows Server 2008 R2 でしか動作しません。また、64 ビット版の SQL Server 2005、SQL Server 2008、または SQL Server 2008 R2 で実行されている SQL Server データベースも必要です。
ただし、これらの要件を満たすハードウェアであれば、サーバー ファーム全体の一括アップグレードが可能です。また、さまざまなアプローチを使用して、既存の環境から新しい環境に移行することもできます。アップグレード前チェックを実行すると、アップグレード プロセスに役立ちます。このチェックについては、図 1 を参照してください。また、TechNet マガジン 2010 年 6 月号の記事「SharePoint 2010 へのアップグレードの準備をする」でも説明しています。
図 1 展開の準備ができているかどうかテストするアップグレード前チェック ツールの使用
予算に配慮する必要がある IT マネージャーの皆さんは、このような要件を検討することをお勧めします。また、SharePoint 2010 が本当に期待に応えてくれるかどうかも知りたいと思われるでしょう。ご安心ください。SharePoint 2010 には、ソーシャル コンピューティング、コンテンツ管理、ドキュメント処理、エンタープライズ検索、ビジネス インテリジェンス、アプリケーション開発、および Web での生産性を対象とした豊富な新機能と機能強化が用意されています。
SharePoint 2010 では、スケーラビリティ、管理性、およびガバナンスが大幅に向上しました。ソーシャル コンピューティングに関する機能強化には、タグ、評価、機能豊富なプロファイル、ナビゲーション用ソーシャル フィードバック、ソーシャル ブックマーク、検出、フィルターなどがあります。また、新しい Web ベースの共同作業向けの作成ツールやクライアントの拡張機能もあります。
クライアントでは、SharePoint Workspace を使用して、Office、クロス ブラウザー、モバイル モード、およびオフライン モードを選択できるようになりました。レポート機能が強化されたので、監視機能では、潜在的な問題をより迅速に特定できます。Business Connectivity Services には、さらに充実したデータ接続機能や読み取り/書き込み機能が用意されています。また、資産ライブラリ (企業のドキュメントやメディア ファイルのリポジトリ) には、数百万個ものオブジェクトを格納できるようになりました。
Visio と SharePoint Designer を使用したワークフローの強化、Visual Studio 2010 と統合された開発ツールの強化、Silverlight との統合、開発者ダッシュボード、およびデバッグ ツールを加味すれば、SharePoint 2010 に移行するのは当然と言えます。
ですから、SharePoint の導入をまだ検討されていない場合、今こそが最高のチャンスです。オーランドで開催された ITxpo 2010 においてガートナー社のアナリストは、2015 年までに、iPhone や iPad がコンシューマー アプリケーション向けプラットフォームとして普及しているのと同じくらい、SharePoint がエンタープライズ コンテンツ アプリケーション向けプラットフォームとして普及するという予測を発表しました。
すべてに対応した単一のオプションはない
SharePoint 2010 は、1 つのオプションですべてに対応できるソリューションではありません。1 つの組み込みデータベースを使用する単一サーバー環境、1 つの SQL Server データベースを使用する単一サーバー環境、複数層を使用する複数サーバー環境など、多数のインストール オプションがあります。
2 層環境では、SharePoint のサーバー コンポーネントとデータベース コンポーネントは、別々のサーバーにインストールします。この場合、SharePoint をインストールした第 1 層を Web (フロントエンド) 層と呼び、SQL Server をインストールした第 2 層をデータベース (バックエンド) 層と呼びます。3 層環境では、図 2 に示すように、SharePoint をインストールしたフロントエンド Web サーバー、中間層のアプリケーション サーバー、およびバックエンド データベース サーバーが連動して、SharePoint サイトとサービスを提供します。
.jpg)
図 2 3 層環境の SharePoint 2010 サーバー ファーム
どの環境でも、4 基以上のプロセッサ コアと 8 GB 以上の RAM を備えた 64 ビット対応のハードウェアが必要です。Windows Server 2008 と Windows Server 2008 R2 では、既定で IPv4 と IPv6 の両方がインストールされて有効になります。両方のプロトコルが有効な場合は、IPv6 が優先されます。SQL Server と SharePoint 2010 では IPv6 がサポートされていますが、SharePoint 2010 が正常に機能するには、すべてのエンド ユーザーの URL が AAAA レコードを持つ DNS 名に基づいている必要があります。
IPv6 リテラル アドレスを使用している SharePoint URL の参照はサポートされていません (ただし、リテラル アドレス形式が必要な一部の管理機能は除きます)。リテラル アドレス形式を使用する場合は、http://[2001:db8:85a3:8d3:1319:8a2e:370:7344] のように、リテラル アドレスを角かっこで囲む必要があります。
サーバーを仮想化することもできます。SharePoint Server 2010 ファームの一部として、Windows Server 2008 Hyper-V テクノロジを使用して仮想マシン (VM) を構成します。このような VM は、フロントエンド Web サーバー、中間層のアプリケーション サーバー、およびバックエンド層のデータベース サーバーとして使用することもできます。VM では、外部に配置されているサーバーや親パーティションとの通信に、外部ネットワークを使用します。また、同じ物理サーバーや親パーティションにある他の VM との通信には内部ネットワークを使用し、同じ物理サーバー上の他の VM との通信にのみプライベート ネットワークを使用します。
マクロ レベルからマイクロ レベルのアーキテクチャ
SharePoint 2010 の実装には、論理アーキテクチャがあります。このアーキテクチャは、マクロ レベルのサーバー ファームから、マイクロ レベルのサイトとページまでのコンポーネントに分類できます。サーバー ファームは、コンテンツを物理的に分離します。分離に関する詳細な要件を満たすために資産ライブラリごとにサーバー ファームを作成できます。また、パフォーマンスとスケーラビリティの目標を達成するために別のサーバー ファームを作成しなければならない場合もあります。
SharePoint 2010 には、サービスを個別管理および集中管理できる、新しいサービス アーキテクチャが導入されています。このアーキテクチャには、同じファーム内の複数のサイト間や場合によっては複数のファーム間でサービスをカスタマイズして共有できる、サービス アプリケーションのリソースがあります。また、1 つのサーバー ファーム内には、同じサービス アプリケーションのインスタンスを複数展開することができます。新しいサービス アプリケーションが導入されたので、SharePoint サービスを共有サービス プロバイダー (SSP) に含める必要がなくなりました。サービス アプリケーションには、サービス設定や 1 つ以上のデータベースを含めることも、サービス設定だけを含めることもできます。
サービス アプリケーションは、いくつかある論理アーキテクチャ コンポーネントの 1 つに過ぎません。Web アプリケーションも論理アーキテクチャ コンポーネントです (これは、SharePoint で作成して使用する IIS Web サイトです)。Web アプリケーションは、必要なサービスだけを使用するように構成できます。また、Web アプリケーションを拡張してそれぞれに最大 5 つの IIS Web サイトを含め、各サイトを領域として扱うこともできます。領域は、同じ Web アプリケーションへのアクセスに使用する異なる論理パス (URL) です。
SharePoint 2010 で Web アプリケーションとサービスを作成すると、これらのコンポーネントは指定したアプリケーション プールに追加されます。アプリケーション プールは、1 つ以上のワーカー プロセスによって処理される URL のグループです。各アプリケーション プールには、独自のワーカー プロセスがあります。別々の ID を割り当てて、各アプリケーション プールを分離することもできます。
Web アプリケーションのコンテンツにアクセス許可を適用するにはポリシーを使用します。既定では、1 つの Web アプリケーションのコンテンツは、1 つのコンテンツ データベースに保存されます。このコンテンツは、サイト コレクション レベルで複数のデータベースに分割することもできます。1 つのコンテンツ データベースに複数のサイト コレクションを含めることは可能ですが、1 つのサイト コレクションを複数のデータベースに分けることはできません。一般的には、1 つの Web アプリケーションで使用するデータベースの数は 100 個以下にすることをお勧めします。
サイト コレクションは、所有者が同じで管理設定を共有している一連の Web サイトです。各サイト コレクションには 1 つのトップレベル Web サイトがあり、多くの場合は 1 つ以上のサブサイトがあります。サイトは、サイト コレクション内にホストされている 1 つ以上の関連する Web ページとその他のアイテムで構成されています。1 つのコンテンツ データベースで使用するサイト コレクションの数は 50,000 以下に制限することをお勧めします。実際には、サイト コレクション数を 10,000 未満に抑えると、最適なパフォーマンスを実現できます。
スケールアウトするには、複数のデータベース サーバーにサイト コレクションを分散します。この方法を利用すると、記憶容量とスループットが増加します。また、ほとんどの場合は、1 つのサイト コレクションで使用するサイトの数を 250,000 以下にすることもお勧めします。サイトの数を 5,000 以下に抑えると、バックアップとアップグレードを簡単に行えるようになります。
SharePoint 2010 サーバー環境の全体的な複雑さは、最終的には、企業が抱える要件や特定のプロジェクトの具体的な要件によって決まります。さまざまな実装や構成を提供して、さまざまな要件を満たすことができます。チーム レベルや部門レベルの資産ライブラリが必要なプロジェクトもあれば、全社で使用する中央レポジトリが必要なプロジェクトもあるでしょう。ただし、どのような場合でも、少なくとも次の作業を計画に含める必要があります。
- デジタル資産管理の役割を特定する: 参加者や関係者を特定します。
- 資産の使用状況を分析する: 各デジタル資産を使用するユーザー、関連するデジタル資産の種類、および資産の使用方法を特定します。
- 資産ライブラリの構成を計画する: 必要なライブラリの数、ライブラリを作成する場所、およびライブラリの用途と構成方法を決定します。
- コンテンツの種類を計画する: テキスト、イメージ、オーディオ、ビデオなど、特定のライブラリに含めるコンテンツの種類を決定します。
- コンテンツ ガバナンスを計画する: コンテンツのカテゴリと保存場所ごとに、適切な制御のレベルを決定します。また、監査、保持、およびラベル付けのために適用する必要があるポリシーを決定します。
- コンテンツのワークフローを計画する: 各ライブラリ内で、ドキュメントのバージョン管理、チェックアウト、およびチェックインを使用する予定があるかどうか、予定がある場合はその方法を決定します。
企業のメディア資産 (イメージ、オーディオ、ビデオなど) は、ドキュメントやその他の種類のテキスト ファイルと一緒に管理することも、別々に管理することもできます。通常、デジタル資産の構成には、単一サイトまたは別個のサイト コレクションのアプローチを使用します。単一サイトのアプローチの場合、コンテンツ データベースには、すべてのメディア資産を含むすべてのサイト コンテンツが含まれます。
別個のサイト コレクションのアプローチでは、サイト コンテンツとメディア資産で異なるコレクションを使用します。たとえば、サイト コンテンツ用に "サイト コレクション 1" コンテンツ データベースをセットアップし、メディア資産用に "サイト コレクション 2" コンテンツ データベースをセットアップします。メディア ファイルとドキュメント ファイルを分離することは、多くの場合理にかなっています。分離することで、2 種類のデータを個別に管理できるようになるので、より簡単にスケールアウトできるようになります。
マクロ レベルで資産のアーキテクチャを検討すると同時に、全般的な構成についても検討する必要があります。特に次の機能について検討することをお勧めします。
- ビット レート調整: メディア ファイルとデータのダウンロード速度を測定して、全体的なパフォーマンスが低下していないことを確認できます。資産ライブラリにオーディオやビデオなどのサイズが大きいファイルが含まれている場合は、必ずビット レート調整を使用する必要があります。ビット レート調整は IIS 7 の機能なので、すべてのフロントエンド Web サーバーの IIS 7 で、この機能をインストール、有効化、および構成する必要があります。
- ディスク ベースのバイナリ ラージ オブジェクト (BLOB) キャッシュ: 頻繁に使用されるイメージ、オーディオ、ビデオに加え、Web ページの表示に使用される他のファイル (.js ファイルや .css ファイル) などの、BLOB キャッシュを制御します。環境に資産ライブラリが存在する場合は、BLOB キャッシュを使用する必要があります。BLOB キャッシュは、IIS 7 で有効にして、すべてのフロントエンド Web サーバーに格納します。キャッシュするのに十分な記憶容量が確保されるように Web サーバーを構成する必要があります。また、リモート BLOB ストレージ (RBS) の使用を検討することもお勧めします。データベースから BLOB を削除すると、大量のコンテンツを簡単にスケーリングできるようになります (図 3 参照)。
- アップロードするファイルの最大サイズ: ユーザーがサーバーにアップロードできるファイルの最大サイズを制御します。このサイズは、サーバーの全体管理をホストするサーバーの Web アプリケーションごとに構成します。この機能は、資産ライブラリにアップロードする必要があるファイルの種類と一般的なサイズに基づいて調整する必要があります。データベース サーバーを構成する際は、このような種類のファイルを格納するのに十分な記憶域が確保されるようにします。
.jpg)
図 3 他のコンテンツと BLOB データの分離
単一サーバー環境、マルチサーバー ファーム、仮想サーバー、または社内でこれらの環境の独自の実装のいずれを採用する場合でも、ビジネスの継続性の計画は必須です。ビジネスの継続性の計画では、必要に応じて冗長性と可用性のメカニズムを使用して、企業のデジタル資産の保護に力を入れる必要があります。
特定のコンテンツを保護する
すべての SharePoint 2010 環境に強力なコンテンツ保護を組み込むことは、IT プロフェッショナルの任務です。この作業では、まず、ごみ箱とバージョン管理を使用します。SharePoint 2010 では、次の 2 種類のごみ箱がサポートされています。
- ユーザーのごみ箱 (第 1 段階のごみ箱)
- サイト コレクションのごみ箱 (第 2 段階のごみ箱)
ごみ箱を有効にすると、アイテムを 2 段階で削除できます (図 4 参照)。第 1 段階はごみ箱です。ごみ箱では、ファイル、リスト アイテム、ドキュメント ライブラリなど、ユーザーが削除したアイテムを復元できます。ユーザーがアイテムをごみ箱に送って削除しても、そのアイテムは、削除されるか、期限切れになるか、または復元されるまでごみ箱に保持されます。ごみ箱はサイト レベルで配置されるもので、サイト上に対して投稿、デザイン、またはフル コントロールのアクセス許可を持つユーザーが使用できます。ユーザーまたはサイト コレクションの管理者は、削除したアイテムをごみ箱から復元して、このアイテムを元に戻すことができます。
.jpg)
図 4 SharePoint 2010 における 2 段階のごみ箱
ユーザーとサイト コレクションの管理者の両方が、ごみ箱からアイテムを削除できます。ごみ箱から削除したアイテムは、サイト コレクションのごみ箱に送られます。サイト コレクションのごみ箱はサイト コレクションの管理者レベルで配置されるもので、サイト管理者だけが使用できます。
既定では、削除したアイテムには合計 30 日間の保存期間が設定されています。つまり、ユーザーのごみ箱に送られてから 20 日後に削除されてサイト コレクションのごみ箱に送られたアイテムには、自動的 (かつ完全に) 削除されるまで 10 日間しか保存期間がありません。
サイト コレクションの管理者は、ごみ箱に保持されるアイテムの期限を設定して、削除されたアイテムの有効期限を制御します。サイト コレクションのごみ箱がサイズ制限に達した場合、管理者は有効期限が切れる前に手動でアイテムを削除できます。
また、コンテンツ制御の一環としてバージョン管理機能を使用して、冗長性を提供することができます。バージョン管理には、ドキュメントのバージョンを作成する方法とタイミングを制御する、コンテンツ承認権限、ドキュメントのチェックアウトとチェックインなどがあります。既定のコンテンツ制御は、特定の資産ライブラリに固有のもので、その資産ライブラリに適用されているサイト コレクションのテンプレートに基づいて行われます。SharePoint 2010 には、次の 3 つのバージョン管理オプションがあります。
- バージョンを管理しない: バージョン管理が無効になり、以前のバージョンのドキュメントは作成されません。そのため、ドキュメントの履歴は保持されません。
- メジャー バージョンを作成する: ドキュメントを保存するたびに以前のバージョンが保持されます。管理者は、保持する以前のバージョンの数を制御できます。資産ライブラリに対してアクセス許可を持っているユーザーは、ドキュメントとそのメジャー バージョンを表示できます。
- メジャーとマイナー (下書き) バージョンを作成する: ドキュメントには、公開バージョンと見なせるメジャー バージョンが指定されます。マイナー バージョンは、下書きバージョンと見なします。メジャー バージョンは .0、マイナー バージョンは 0 以外の拡張子 (.1、.2、.3 など) になっています。ユーザーがドキュメントを保存するたびに、以前のメジャー バージョンとマイナー バージョンが自動的に保存されます。読み取りアクセス許可を持つすべてのユーザーは、ドキュメントのメジャー バージョンを表示できます。通常、編集アクセス許可を持つすべてのユーザーは、ドキュメントのマイナー バージョンを表示して操作できます。
バックアップと回復の強化
コンテンツ保護の計画には、可用性、バックアップ、および回復の戦略を含める必要があります。このような戦略は、ビジネス要件、関連するデジタル資産の種類、および資産の相対的な価値によって異なります。
高可用性を確保するには、計画的なダウンタイム (システムの更新など) と予期しないダウンタイム (障害など) の両方の影響を軽減するのに役立つ一連のサーバーを使用する必要があります。Web サーバーやアプリケーション サーバーをファームに追加して、スケールアウトできます。このようにすると、サービスとアプリケーションの可用性を確保できます。
バックエンド データベースの可用性を向上するには、お手持ちのデータベース クラスタリング ツールやデータベース ミラーリング ツールを使用する必要があります。データベース クラスタリングでは、フェールオーバー クラスターを使用して可用性を確保します。クラスター化されたサーバー (通称、ノード) は、物理的なケーブルとソフトウェアによって接続されます。
1 つのノードで障害が発生した場合、別のノードでサービスの提供が開始されます。この処理はフェールオーバーと呼ばれ、ユーザーへのサービスやバックエンド データベース接続の提供が中断される回数を最小限に抑えます。フェールオーバー クラスターは、高い可用性、スケーラビリティ、および信頼性を必要とするアプリケーションやサービスの可用性を向上します。
データベース ミラーリングでは、プリンシパル データベースから "ミラー" (重複するデータベース) にトランザクションを送信することで可用性を確保します。SharePoint 2010 では、ミラーリングに "自動フェールオーバー機能付き高安全性モード" 構成を使用します。この構成では、プリンシパル サーバー、ミラー サーバー、および監視サーバーを使用します。監視サーバーは、数秒間の障害を発生させるだけで、SQL Server によるプリンシパル サーバーからミラー サーバーへの自動的なフェール オーバーを可能にします。ミラーリングは、SharePoint のコンテンツ データベースと構成データベースに冗長性を提供します。
バックアップと回復については、まず保護する対象を決定します。SharePoint 2010 製品のバックアップと回復の計画に関するワークブック (英語) を使用すると、計画の作成に役立ちます。SharePoint のバックアップをデータベースのバックアップと組み合わせて使用すると、SharePoint インフラストラクチャのほとんどを保護できます。
1 つのサイト コレクションが 1 つのデータベースに保存されている場合、サイト コレクションの回復には、ファーム レベルとデータベース レベルのバックアップと復元を使用できます。また、これらのレベルのバックアップを未接続データベース復旧と併用すると、サイト コレクション、サイト、リスト、および構成を復元できます。ファーム レベルとデータベース レベルのバックアップと復元では、RBS ストアに格納されているデジタル資産がその他のコンテンツと共にバックアップおよび回復されます (ただし、使用している RBS プロバイダーが対応している場合に限ります)。
ただし、これらのバックアップでは一部のカスタマイズした設定を対象としていません。サーバーの全体管理を使用しないで行った Web.config への変更は、ファイル システム レベルでバックアップする必要があります。また、SharePoint を使用しないで設定した IIS 構成も、IIS または OS レベルでバックアップする必要があります。特定の SharePoint ファーム用のサーバーの全体管理のコンテンツ データベースや構成データベースを回復することは可能ですが、同じサーバーで構成された同じファームへの完全ファーム回復手順を実行した場合にのみ回復できます。
サービス アプリケーションについては、関連するデータベースのみを復元してもサービス アプリケーション全体を復元することはできないことに注意してください。データベースを復元してから、サービス アプリケーションを再度準備する必要があります。SQL Server Reporting Services データベースは、SharePoint のバックアップと回復とは別にバックアップして復元する必要があります。この作業には SQL Server のツールを使用します。
以上で、冗長性と可用性が確保されるように SharePoint Server 環境を構築する方法についての説明は終わりです。SharePoint 2010 には、すべてに対応する単一オプションはなく、物理アーキテクチャを設計する際には多数の論理コンポーネントについて考慮する必要があります。また、デジタル資産を保護するための、SharePoint 環境の最適な構成方法についても考慮する必要があります。
SharePoint が、iPhone や iPad がコンシューマー アプリケーション向けプラットフォームとして普及しているのと同じレベルで、エンタープライズ コンテンツ アプリケーション向けプラットフォームとして普及するかどうかについては、今後の展開を見守る必要があるでしょう。
.jpg)
William R. Stanek (williamstanek.com、英語) は、先駆者的なテクノロジの専門家で、優秀なトレーナーや 100 冊以上もの優れた書籍の著者としても活躍しています。好評発売中の書籍と予約受付中の著書には、『Active Directory Administrator's Pocket Consultant』(Microsoft Press、2009 年)、『Windows Group Policy Administrator's Pocket Consultant』(Microsoft Press、2009 年)、『Microsoft SQL Server 2008 Administrator's Pocket Consultant 2nd Edition』(Microsoft Press、2010 年)、『Windows 7: The Definitive Guide』(O'Reilly Media、2009 年)、『Windows Server 2008 Inside Out』(Microsoft Press、2008 年)、『Windows PowerShell 2.0 Administrator's Pocket Consultant』(Microsoft Press、2009 年)、『Windows 7 Administrator's Pocket Consultant』(Microsoft Press、2009 年)、および『Windows Server 2008 Administrator's Pocket Consultant, 2nd Edition』(Microsoft Press、2009 年) などがあります。[twitter.com/WilliamStanek、英語]https://(twitter.com/williamstanek) で Stanek をフォローしてみてください。