アップグレード プロセスに要する時間と必要な容量を予測する (Office SharePoint Server)

  • [アーティクル]

この記事の内容 :

  • アップグレードに必要な容量を予測する

  • アップグレードに要する時間を予測する

  • 関連ワークシート

すべての環境は固有であり、異なるハードウェア機能と異なるサイト特性が含まれます。 アップグレードを実行するために必要な容量と時間は、環境によって大きく異なります。 たとえば、Microsoft® Windows® SharePoint® Services 2.0 が基になっているサイトは、Microsoft Office SharePoint Portal Server 2003 に基づく個人サイトまたはポータル サイトよりはるかに短時間でアップグレードできます。これは、Windows SharePoint Services 2.0 サイトのアップグレード プロセスの方が、SharePoint Portal Server 2003 の個人サイトまたはポータル サイトに対するアップグレード プロセスより手順が少ないためです。 アップグレード プロセスに必要な容量と所要時間を予測する最善の方法は、試用版アップグレード パスを実行した後、サイズと時間を確認することです。試用版アップグレードの実行の詳細については、「試用版のアップグレードを使用して潜在的な問題を発見する (Office SharePoint Server)」を参照してください。

アップグレードに必要な容量を予測する

アップグレードの実行に必要なディスク空き容量は、選択したアップグレード方式に応じて異なります。アプローチに一括アップグレードまたはデータベースの移行を選択した場合、データベース サイズはごく小さな拡張しか計画する必要がありませんが、アップグレードの実行中に大量のトランザクションが発生するため、ログ ファイルは、発生した変更を記録できるように拡張する必要があります。

段階的なアップグレードの場合は、元のデータベース、アップグレードが行われる一時データベース、およびアップグレードの済んだデータベースという 3 セットのデータベースを格納するためのスペースが必要です。さらに、ログ ファイルと追加の検索インデックス (必要な場合) に対する容量が必要です。

サーバー ファームの最適なパフォーマンスと運用をサポートするために SQL Server のストレージ要件を計画しモニタリングするときに役に立つベスト プラクティスと主要な推奨事項については、SharePoint 用 SQL Server 記憶域の計画と監視 : パフォーマンスの推奨事項とベスト プラクティス (ホワイト ペーパー) を参照してください。

一括アップグレードまたはデータベース移行のための容量を予測する

一括アップグレードまたはデータベース移行の場合は、データベース容量の大量追加を計画する必要はありません。コンテンツ データベースを移行する場合は、現在のデータベースに必要な容量に将来のコンテンツ増加のための分を加えた容量を、新しいハードウェア上で使用できるように計画するだけで十分です。データベースの現在の大きさを調べるには、Microsoft SQL Server の Enterprise Manager を使用します。データベースの容量に加えて、以下の項目のための空間も確保する必要があります。

  • アップグレード ログ ファイル。

  • データベースのトランザクション ログ ファイル。これらのログ ファイルは、データベースで発生する多くの変更を収めるために、急速に拡大します。これらのログ ファイルのために十分なディスク容量を用意する必要があります。

    注意

    非常に大規模な環境では、トランザクション ログ ファイルに対する既定の成長率 (10%) では、アップグレード プロセスに対応するのに十分ではない可能性があります。十分ではない場合、タイムアウトが発生する可能性があります。この場合も、トランザクション ログ ファイルがアップグレード プロセスに対応できるかどうかを調べるには、試用版のアップグレードが最適な方法です。環境が非常に大規模な場合、または試用版アップグレードの間にプロセスがタイムアウトした場合は、SQL Server のトランザクション ログ ファイルを事前に拡大しておき、処理する必要のあるトランザクションの数に対して十分な容量を用意することを検討します。SQL Server のトランザクション ログの事前拡張の詳細については、SQL Server 2000 または 2005 のマニュアルでデータベースの拡張に関するトピックを参照してください。

段階的なアップグレードのための容量を予測する

段階的なアップグレードの方針に従ってアップグレードする場合は、最も大きいサイト コレクションのサイズの約 3 倍のデータを収容できるだけのデータベース空間を用意する必要があります。たとえば、Microsoft のある内部ポータル サイトに含まれる SharePoint Portal Server 2003 のルート ポータル サイトのデータベースには、400 ギガバイト (GB) のデータがありました。IT グループは、段階的なアップグレード プロセスを実行するために必要なデータベース容量を 1.2 テラバイト (TB) と予測しました。データベースの現在の大きさを調べるには、SQL Server の Enterprise Manager を使用します。

これだけのディスク空間を確保する余裕がない場合は、サイトをバッチでアップグレードすることによってこのオーバーヘッドを低減できます。いくつかのバッチをアップグレードして、以前のバージョンがもう必要ないことをサイトの所有者に確認した後、バックアップを作成してから、旧バージョンのサイトのクリーンアップと削除を開始できます。この方法で進める場合は、新しいバッチのアップグレードと古いバージョンからのサイトの削除を行うことで、必要な容量を調整できます。

共有サービスを使用している場合は、インデックスの約 2 倍の容量も必要です。共有サービスの段階的なアップグレードでは、古いバージョンと新しいバージョンの両方から、インデックスを 2 回作成するためです。

データベースの容量に加えて、以下の項目のための空間も確保する必要があります。

  • アップグレード ログ ファイル。

  • データベースのトランザクション ログ ファイル。これらのログ ファイルは、データベースで発生する多くの変更を収めるために、急速に拡大します。これらのログ ファイルのために十分なディスク容量を用意する必要があります。

    注意

    非常に大規模な環境では、トランザクション ログ ファイルに対する既定の成長率 (10%) では、アップグレード プロセスに対応するのに十分ではない可能性があります。十分ではない場合、タイムアウトが発生する可能性があります。この場合も、トランザクション ログ ファイルがアップグレード プロセスに対応できるかどうかを調べるには、試用版のアップグレードが最適な方法です。環境が非常に大規模な場合、または試用版アップグレードの間にプロセスがタイムアウトした場合は、SQL Server のトランザクション ログ ファイルを事前に拡大しておき、処理する必要のあるトランザクションの数に対して十分な容量を用意することを検討します。SQL Server のトランザクション ログの事前拡張の詳細については、SQL Server 2000 または 2005 のマニュアルでデータベースの拡張に関するトピックを参照してください。

  • 検索インデックス。段階的なアップグレードでは、2 つの検索クロールが同時に実行する場合があります。

段階的なアップグレードの間のディスク容量の使用の詳細については、「アップグレード プロセスの動作 (Office SharePoint Server)」を参照してください。

アップグレードに要する時間を予測する

ディスク容量を予測できたら、実際のアップグレード プロセスに要するだいたいの時間を計算できます。アップグレードの時間は、環境によって大きく変わります。アップグレードのパフォーマンスは、使用しているハードウェア、サイトの複雑さ、および実装の具体的な特性に大きく依存します。たとえば、大きなドキュメント ライブラリや個人用設定されたサイトが多くある場合は、単純なサイトよりアップグレードに時間がかかります。

選択したアップグレード方法によっても、プロセスに要する時間が大きく異なります。最も速い方法は、データベースの移行によるアップグレードです (ただし、この方式の場合、アップグレード前とアップグレード後の手順に要する時間が他の方法よりも長いことに注意してください)。段階的なアップグレードは、余分なデータ コピー手順が含まれるため、最も時間のかかる方法です。一括アップグレードは、両者の中間に位置します。

全体の時間を予測する最善の方法は、少量のデータを使用して試用版のアップグレードを行い、アップグレード ログ ファイルを確認することです。ログ ファイルを使用すると、アップグレード プロセス時の進捗を調べることもできます。 %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\LOGS にある upgrade.log ファイルに期間が含まれます。

ただし、データ セットに基づいて得られた予測は、そのデータの実際のアップグレード プロセスのものです。これには、その手順の前後に実行する必要のあるすべての手順が含まれているわけではありません。そして、それに含まれていない手順がデータ自体のアップグレードよりも時間がかかる場合もあります。アップグレードの所要時間を予測するには、データの処理に加え、アップグレード前後の段階で活動に要する時間も予測する必要があります。

アップグレード前の手順には、次のものがあります。

  • カスタム要素の作成   サイト定義や新しいページ レイアウトの作成、または Web パーツのアップグレードには、ある程度時間がかかります。カスタム要素作成のプロセスは、プロジェクトを評価する段階中、早い時期で始める必要があります。

  • データベースのバックアップ   アップグレードに失敗してサーバー ファームを再構築しなければならなくなった場合のことを考えて、リモートで確実に回復できるようにするために、完全バックアップ (差分バックアップではなく) を実行する必要があります。大規模な環境では、この手順に相当な時間がかかる場合があります。特に、ネットワーク上の場所にバックアップする場合は、ネットワーク遅延の問題によりこの処理が遅くなる可能性があります。

  • 段階的なアップグレードのための新しいドメイン ネーム システム (DNS) 名の作成   ドメイン ネーム システムでは、ネットワーク全体に変更を伝達するための時間がかかります。段階的なアップグレードのための DNS 名の事前作成の詳細については、「新しいドメイン名を作成する (段階的なアップグレードのみ)」を参照してください。

アップグレード後の手順には、次のものがあります。

  • サイトの確認、およびテンプレートの変更または復帰   アップグレード後は、ユーザーに自分のサイトを検証するための十分な時間を与える必要があります。 これには数日かかる場合があります。詳細については、「アップグレードしたサイトを確認する (Office SharePoint Server)」を参照してください。

  • 共有サービス プロバイダ (SSP) の作成   この手順が必要なのは、データベース移行の場合だけです (一括アップグレードまたは段階的なアップグレードの場合は、SSP はアップグレード プロセスの一部として作成されます)。SSP の作成には、10 ～ 20 分程度かかります。ただし、データベースを事前に作成するためにデータベース管理者に連絡する必要がある場合は、準備期間として 1、2 日かかる可能性があります。

  • アップグレード後のプロファイルのインポート   この手順には、数時間から、大規模な組織では 1 日程度かかる場合があります (プロファイルが 1,000 より多い場合など)。

  • ユーザー クロールの実行   大規模な組織では、この手順に 24 時間以上かかる場合があります。

  • 全コンテンツに対する検索クロールの実行   大規模なサイトでは、この手順には 24 時間以上かかる場合があります。

以下のような要素が環境に存在しても、アップグレードの時間が長くなる可能性があります。

  • 非常に大きなドキュメント ライブラリ   250,000 件を超えるドキュメントがすべてドキュメント ライブラリのルート (フォルダではなく) に存在するようなドキュメント ライブラリでは、アップグレードに長い時間がかかり、正しくアップグレードできない可能性もあります。フォルダを使用した大規模なドキュメント ライブラリの分割に関する 2003 および 2.0 のガイドラインは、ライブラリ サイズの管理に役立つ場合があります。たとえば、同じドキュメント ライブラリを変更して 250,000 件のドキュメントを 125 のフォルダに分割すると、アップグレードが簡単になります。

  • 非常に大きなデータベース   100 GB を超えるデータベースは、アップグレードに長い時間がかかる場合があります。ただし、ポータル サイトを含むコンテンツ データベースは、これより大きくなることがよくあります (200 GB など)。広い領域が数多くあるポータル サイトの場合は、SharePoint Portal Server 2003 では分割することができず、すべてを同時にアップグレードする必要があります。

    注意

    コンテンツ データベースが 100 GB より大きくても、ポータル サイトではなくチーム サイトまたは個人用サイトで構成されている場合は、アップグレードを実行する前に、より小さなデータベースに分割することをお勧めします。データベースが大きいと、アップグレードに時間がかかるだけでなく、アップグレードが失敗した場合に復元が困難になる可能性があります。コミュニティでサポートされているツールを利用すれば、データベース間でサイト コレクションを移動できます。このようなツールの 1 つに SharePoint Utility Suite というのがあり、https://www.microsoft.com/sharepoint/downloads/components/detail.asp?a1=724 (英語) にある SharePoint 製品と SharePoint テクノロジの Web コンポーネント ディレクトリから入手できます。

    データベースが非常に大きく (100 GB 超)、分割できない (コンテンツの大部分が単一のサイト コレクションにあるため) 場合は、アップグレード方法の再検討が必要になることもあります。段階的なアップグレード方法は、サイト コレクションを個別にアップグレードできるので、ある程度大規模のデータベースでも処理できます。データベース移行方式は、データベースが非常に大きくなると困難になりますが、これは単に、大きいデータベースではバックアップと復元で問題が発生しやすくなるためです。もちろん、段階的な方式にはより多くの空間が必要となるため、これらの選択肢は注意深く検討する必要があります。段階的なアップグレードの終了後に、サイトをアップグレードするためのデータベース移行の詳細については、Microsoft Knowledge Base の記事 926718「Windows SharePoint Services 2.0 ファームの段階的なアップグレード時に Windows SharePoint Services 3.0 にコンテンツ データベース バックアップを追加する方法」(https://go.microsoft.com/fwlink/?linkid=113886&clcid=0x411) を参照してください。

    注意

    アップグレードを試みる前に、旧バージョンおよび新バージョンの容量計画ガイドラインに従っていることを確認してください。パフォーマンスを最大にするためにガイドラインに違反していると、アップグレード プロセスに長い時間がかかったり、アップグレード プロセスが成功しなかったりする可能性もあります (たとえば、同一の大きいドキュメント ライブラリでプロセスが繰り返しタイムアウトする)。実際の展開が推奨される容量ガイドラインを満たしていない場合は、アップグレードを試みる前に、何らかの作業を行ってガイドラインを満たす必要があるかどうかを検討してください。この場合も、試用版のアップグレードがその決定に役立ちます。

ワークシート

Microsoft® Office SharePoint® Server 2007 データベース容量とアップグレード時間の予測ワークシート (https://go.microsoft.com/fwlink/?linkid=73752&clcid=0x411) を使用して、アップグレードに必要なディスク容量と所要時間を判断してください。

このブックのダウンロード

このトピックは、簡単に読んだり印刷したりできるように、次のダウンロード可能なドキュメントに収められています。

使用できるすべてのブックの一覧については、「Office SharePoint Server 2007 のダウンロード可能なブック」を参照してください。