アップグレード プロセスに要する時間と必要な容量を予測する (SharePoint Server 2010)
適用先: SharePoint Server 2010
トピックの最終更新日: 2016-11-30
Microsoft Office SharePoint Server 2007 から Microsoft SharePoint Server 2010 へのアップグレードを計画する際に重要なのは、アップグレード プロセスにかかる時間と必要な記憶域の容量を確認することです。環境はどれも固有のものであり、備わっているハードウェアの能力やサイトの特性はさまざまです。そのため、アップグレードの実行に必要な容量と時間は、環境によって大きく異なります。これらの要素を予測する最善の方法は、試験的なアップグレードを実行し、それに要した容量と時間を確認することです。試験的なアップグレードの実行方法の詳細については、「試用版のアップグレードを使用して潜在的な問題を発見する (SharePoint Server 2010)」を参照してください。
この記事の内容 :
アップグレードに必要な容量を予測する
アップグレードに要する時間を予測する
アップグレードに必要な容量を予測する
一括アップグレードとデータベース接続アップグレードのどちらの方法でも、アップグレード時にデータベースの拡張が起こる可能性があります。また、アップグレード プロセスの実行中には大量のトランザクションが発生するので、そうした変更を記録できるようにログ ファイル用に十分な領域を確保しておく必要があります。そのため、データベースとログ ファイルの両方についてサイズの拡張を計画する必要があります。
アップグレードを計画する際には、アップグレード時に最高の操作性とパフォーマンスが得られるように、現在の環境が Office SharePoint Server 2007 の記憶域に関するベスト プラクティスに従っていることを確認します。詳細については、「物理ストレージに関する推奨事項 (Office SharePoint Server)」を参照してください。また、SharePoint Server 2010 のベスト プラクティスを確認し、アップグレード対象の環境に対して必要な調整があればそれらも実行する必要があります。
新しいバージョンにおけるテーブル構造の変更により、データベースのサイズは、データの再編成中に一時的に増加します。この容量は、アップグレード後に回復できますが、一括アップグレードとデータベース接続アップグレードのどちらでも、データベースを現在のサイズよりも最大で 50% 拡大できるだけの容量を確保する必要があります (ただし、アップグレード後にデータベースを縮小させて、この容量の大部分を回復できます)。また、通常の使用によってデータベースが時間の経過と共に拡大していくことに対応できるように、データベース サーバーの容量を確保する必要もあります。データベースの現在のサイズを確認するには、Microsoft SQL Server の Enterprise Manager を使用します。データベースの容量に加えて、次の要素のための容量も確保する必要があります。
一時データベース。一時データベースの急激な容量の増加に対応できる十分なデータベース容量があることを確認します。空き容量が不足している場合は、アップグレード プロセスがタイムアウトし、アップグレードは失敗します。
アップグレード ログ ファイル。
データベースのトランザクション ログ ファイル。このログ ファイルは、データベースで発生する多くの変更を記録するために、サイズが急速に増加します。
注意
非常に大規模な環境では、トランザクション ログ ファイルに対する既定の成長率 (10%) ではアップグレード プロセスに十分に対応できない可能性があります。その場合は、タイムアウトが発生することがあります。ここでも、トランザクション ログ ファイルがアップグレード プロセスに対応できるかどうかを決定する最善の方法は、試験的なアップグレードを行うことです。環境が非常に大規模な場合、または試験的なアップグレードの途中でプロセスがタイムアウトした場合は、SQL Server のトランザクション ログ ファイルを事前に拡張して、処理が必要なトランザクションの数に対して十分な領域を確保することを検討します。SQL Server のトランザクション ログを拡張する方法の詳細については、「データベースの拡張 (SQL Server 2005)」(https://go.microsoft.com/fwlink/?linkid=182619&clcid=0x411) または 「データベースの拡張 (SQL Server 2008)」(https://go.microsoft.com/fwlink/?linkid=182620&clcid=0x411) を参照してください。
アップグレードに要する時間を予測する
ディスク容量を予測し、経験に基づいた確認を完了したら、実際のアップグレード プロセスに要するおよその時間を計算できます。アップグレードの時間は、環境によって大きく変わります。アップグレードのパフォーマンスは、使用しているハードウェア、サイトの複雑さ、および実装の具体的な特性に大きく依存します。たとえば、大規模なドキュメント ライブラリがある場合は、アップグレードにかかる時間が簡素なサイトに比べて長くなります。
パフォーマンスに影響する要因を以下の表に示します。
| コンテンツ要因 | ハードウェア要因 |
|---|---|
以下の要素の数量
これらに加えてデータベース全体のサイズ |
|
データ構造もアップグレード時間に影響します。たとえば、それぞれに 10 個のアイテムを持つリスト 10,000 個のアップグレードには、それぞれに 10,000 個のアイテムを持つリスト 10 個のアップグレードよりも時間がかかります。リスト インフラストラクチャのアップグレードに必要な処理は、アイテム数に関係なく、リストごとに実行されるので、リスト数が多いほど処理数も増えます。上記の表にある "コンテンツ要因" 列のほとんどの項目についても同様です。
ハードウェアの構造も、パフォーマンスに大きく影響する可能性があります。通常、データベース サーバーのパフォーマンスは Web サーバーのパフォーマンスよりも重要ですが、性能不足のハードウェアや接続の問題はどちらの層でもアップグレードのパフォーマンスに大きな影響を与えることがあります。
選択したアップグレード方法によっても、プロセスに要する時間は大きく異なります。最も速い方法は、データベース接続アップグレードを実行することです (ただし、この方法では、アップグレード前とアップグレード後の手順に要する時間が一括アップグレードよりも長くなります)。一括アップグレードでは、サイトに加えて環境もアップグレードするので、所要時間が少し長くなりますが、この方法を使用するとアップグレード前後の手順は少なくなります。
全所要時間を予測する最善の方法は、少量またはすべてのデータを使用して試験的なアップグレードを実行し、アップグレード ログ ファイルを確認することです。このログ ファイルには、アップグレードにかかった時間が記録されます。アップグレード ログ ファイルの末尾にある合計経過時間を参照してください。この時間を参考にして、全体をアップグレードする場合の所要時間を予測できます。また、このログ ファイルは、アップグレード プロセス実行中の進行状況の確認にも利用できます。アップグレード ログ ファイルは、%COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\14\LOGS にあります。
試験的なアップグレードに基づいて得られた予測は、そのデータの実際のアップグレード プロセスのものです。これには、その手順の前後に実行が必要なすべての手順が含まれているわけではありません。そこに含まれていない手順の実行に、データ自体のアップグレードよりも時間がかかる場合もあります。アップグレードの所要時間を予測するには、データの処理に必要な時間に加え、アップグレード前後の段階の作業に要する時間も予測する必要があります。
アップグレード前の手順では、次の要素を考慮します。
カスタム要素の作成 Web パーツのアップグレード、新しい機能を活用するためのカスタム テンプレートの再実行には、ある程度時間がかかります。カスタム要素作成のプロセスは、プロジェクトを評価する段階の早い時期に開始する必要があります。
データベースのバックアップ 一括アップグレードでは、アップグレードに失敗してサーバー ファームの再構築が必要になった場合に備えて、リモートで確実に回復できるようにするために環境全体の (差分バックアップではなく) 完全バックアップを実行する必要があります。大規模な環境では、この手順に相当な時間がかかることがあります。特に、ネットワーク上の場所にバックアップする場合は、ネットワーク待ち時間の問題によってこの処理が遅くなる可能性があります。
アップグレード後の手順では、次の要素を考慮します。
サイトの確認と変更の実施 アップグレード後は、ユーザーに自分のサイトを検証するための十分な時間を与えます。これには数日かかることがあります。詳細については、「アップグレードの状態とアップグレードされたサイトを確認する (SharePoint Server 2010)」を参照してください。
サービス アプリケーションの作成とサービスの構成 この手順が必要なのは、データベース接続アップグレードの場合だけです (一括アップグレードの場合は、サービス アプリケーションはアップグレード プロセスの一部として作成されます)。サービス アプリケーションの作成とサービスの構成には、長くかかりません。ただし、データベースを事前に作成するためにデータベース管理者に連絡する必要がある場合は、準備期間として 1、2 日かかる可能性があります。
User Profile Services 用のプロファイル プロパティから分類データへの変換および写真ストアの更新 選択肢リストが含まれるユーザー プロファイル プロパティは、Managed Metadata Service で提供される分類機能を使用するように変換する必要があります。環境内のユーザー プロファイルの数に応じて、この手順によってアップグレード プロセスの所要時間が 1 時間またはそれ以上長くなることがあります。
ユーザー クロールの実行 大規模な組織では、この手順に 24 時間以上かかる場合があります。
全コンテンツに対する検索クロールの実行 大規模なサイトでは、この手順には 24 時間以上かかる場合があります。
環境内に次のような追加の要素がある場合にも、アップグレードの時間が長くなる可能性があります。
非常に大きなドキュメント ライブラリ 250,000 件を超えるドキュメントがすべて (フォルダーではなく) ドキュメント ライブラリのルートに存在するようなドキュメント ライブラリでは、アップグレードに長い時間がかかり、正しくアップグレードできない可能性もあります。フォルダーを使用した大規模なドキュメント ライブラリの分割に関する Microsoft Office SharePoint Server 2007 のガイドラインに従うことは、ライブラリ サイズの管理に役立ちます。たとえば、同じドキュメント ライブラリを再配置して、250,000 件のドキュメントを 125 のフォルダーに分割すると、アップグレードが容易になります。
非常に大規模なデータベース 100 GB を超えるデータベースは、アップグレードに長い時間がかかることがあります。
注意
コンテンツ データベースが 100 GB より大きく、異なるサイトの種類を含む場合は (個人用サイトおよびチーム サイトと公開サイトが共存する場合など)、アップグレードを実行する前に、同種のデータだけを格納する小さいデータベースに分割することをお勧めします。データベースが大きいと、アップグレードに時間がかかるだけでなく、アップグレードが失敗した場合に復元が困難になる可能性があります。
Stsadm.exe の mergecontentdbs 操作または backup 操作と restore 操作を使用して、データベース間でサイトを移動できます。詳細については、「Mergecontentdbs : Stsadm 操作 (Office SharePoint Server)」および「バックアップと復元 : Stsadm 操作 (Office SharePoint Server)」を参照してください。非常に大規模な (100 GB を超える) データベースがあって (1 つのサイト コレクション内に大部分のコンテンツが存在するために) 分割できない場合には、アップグレード方法を再検討することも必要になる場合があります。非常に大規模なデータベースでは、バックアップと復元で問題が発生する可能性があるので、データベース接続アップグレードを選択できないことがあります。
警告
アップグレードを試みる前に、旧バージョンおよび新バージョンの容量計画ガイドラインに従っていることを確認してください。パフォーマンスを最大にするためにガイドラインに違反していると、アップグレード プロセスに長い時間がかかったり、アップグレード プロセスが成功しなかったりする可能性もあります (たとえば、同一の大きいドキュメント ライブラリでプロセスが繰り返しタイムアウトする)。実際の展開が推奨される容量ガイドラインを満たしていない場合は、アップグレードを試みる前に、何らかの作業を行ってガイドラインを満たす必要があるかどうかを検討してください。この場合も、試験的アップグレードがその決定に役立ちます。
コミュニケーションに関する要件
ユーザーおよびチームには、アップグレードのスケジュールを通知して、各自の作業を実行する時間を与える必要があります。詳細については、「情報伝達計画を作成する (SharePoint Server 2010)」を参照してください。
システム センターからのアラートとアラームの管理
アップグレード中はシステム パフォーマンスを監視する必要がありますが、特定の機能を監視する必要はありません。Microsoft Systems Center Operations Manager または Microsoft Operations Manager からの不要なアラームやアラートは一時停止し、アップグレード後に再びオンにします。
SQL のミラーリングおよびログ配布のオン/オフ
ミラーリングとログ配布は、アップグレード前にオフにし、アップグレード後に環境が正しく実行されることを確認したうえで再びオンにしてください。アップグレード中にミラーリングやログ配布を実行すると、SQL Server を実行しているサーバーの負荷が増大し、一時データをミラーリングまたは配布するリソースも浪費されるので、アップグレード中にはミラーリングとログ配布を実行しないことをお勧めします。
アップグレード プロセスをテストして所要時間を求めたうえで、アップグレード作業のスケジュールを作成し、スケジュールを検証してタイムラインを決定します。作業のタイムラインには、アップグレードの前後の手順を実行するのに必要な時間も含めてください。実行前の環境のバックアップに 5 時間かかる場合は、その時間をサービス停止期間に含める必要があります。復元や回復が必要になったときに備えて、バッファーとなる時間も含めてください。このようにして、計画済みのサービス停止期間 (現実的予測) と緊急時のサービス停止期間 (最悪の場合) の両方を算出しておく必要があります。