ミッション クリティカルなサイトへの SharePoint Server 2010 更新プログラムの展開
適用先: SharePoint Server 2010
トピックの最終更新日: 2016-11-30
この記事では、データベース接続方法を使用してソフトウェア更新プログラムを Microsoft SharePoint Server 2010 ファームに展開するビルド間アップグレードについて説明します。
この記事の内容
概要
更新戦略の目標
データベース接続の概念の概要
更新フェーズ、ガイダンス、および主なタスク
更新戦略の一環としての自動化
単一ファームでデータベース接続アップグレードを行うための論理的な手順
フェデレーション ファームでデータベース接続アップグレードを行うための論理的な手順
付録 A. サポートされるアップグレード オプション
付録 B. SQL Server データベースを読み取り専用として構成する
付録 C. カスタマイズ展開のガイダンス
付録 D. ファームのコンテンツとデータをレプリケートするための技法
付録 E. サービス アプリケーション移行のリファレンス
付録 F. 自動化のリソース
付録 G. その他の技術情報
概要
SharePoint Server 2010 環境の通常の有効期間内に、1 つ以上の更新プログラムをインストールする必要が生じます。通常、この更新プログラムは、累積的な更新プログラムまたはサービス パックの形式で提供されます。適切なアップグレード方法を選択し、詳細な展開計画を作成し、スクリプトを使用した自動化を行い、広範囲にわたるテストを実行することで、ソフトウェア更新プログラムの展開において、可用性、ユーザー エクスペリエンス、およびロールバック (必要な場合) に対する組織の要件が確実に満たされるようにすることができます。
この記事では、データベース接続方法を使用して単一ファームおよびフェデレーション ファームにソフトウェア更新プログラムを展開し、ファーム サーバーのビルド間アップグレードを行う方法について説明します。
注意
ビルド間アップグレードの計画については、この記事の範囲外です。計画のガイダンスについては、「アップグレードを計画および準備する (SharePoint Server 2010)」を参照することをお勧めします。
ソフトウェア更新プログラムについて
更新プログラムを SharePoint Server 2010 環境に展開するプロセスは、修正とアップグレードの 2 つのフェーズに分かれている点を理解することが重要です。この記事では、修正という用語を使用して、ソフトウェアの更新とアップグレードを区別しています。
各フェーズには特定の手順と結果が含まれています。アップグレード フェーズを延期することはできますが、数日以上にわたってアップグレードを延期すると、ファームの動作の一貫性を確保できなくなる可能性があります。つまり、延期期間が長くなると、ファームの動作に問題が発生するリスクが高くなります。
修正フェーズ
修正フェーズには、修正手順と展開手順の 2 つの手順が含まれます。修正手順では、新しいバイナリ ファイルがサーバーの全体管理サーバーにコピーされます。置き換える必要があるファイルを使用しているサービスはすべて、一時的に停止されます。サービスを停止することで、使用中のファイルを置き換えるためにサーバーを再起動する必要性が少なくなりますが、場合によっては、サーバーを再起動しなければならないこともあります。
修正フェーズの 2 番目の手順は展開手順です。この手順では、インストーラーによって、サポート ファイルが、Microsoft SharePoint Server を実行しているサーバー上の適切なディレクトリにコピーされます。この手順により、すべての Web アプリケーションが正しいバイナリ ファイルを実行し、更新プログラムのインストール後に適切に機能するようになります。更新フェーズは、展開手順の終了後に完了します。
次の最終フェーズではソフトウェア更新プログラムを展開します。これはアップグレード フェーズといいます。
アップグレード フェーズ
修正フェーズが終了すると、アップグレード フェーズを開始して、更新プログラムのインストールを完了する必要があります。アップグレード フェーズのタスクは多数あるので、完了までに最も時間がかかります。まず、実行中のすべての SharePoint Server プロセスをアップグレードします。プロセスがアップグレードされると、データベースのクロールとアップグレードが行われます。アップグレード プロセスは 1 台のサーバーで実行できるので、ファーム内の他のサーバーは引き続き要求を処理できます。
更新戦略の目標
ミッション クリティカルなアプリケーションをサポートする SharePoint ファームでは、このホワイト ペーパーで使用されているソフトウェア更新戦略をお勧めします。通常、ミッション クリティカルなアプリケーションは、ビジネスの正常な運営に不可欠なアプリケーションとして定義されます。アプリケーションが使用できなくなった場合や、特定の時間枠 (目標復旧時間 (RTO) とも呼ばれる) 内に更新を完了できない場合、企業のビジネスが大きな影響を受けます。たとえば、収益、法的要件、および契約義務が影響を受ける場合があります。
ここでの更新戦略は、以下の目標と目的を満たすように策定されています。これらの目標と目的は、更新が成功したことを示す主な指標にもなります。
ダウンタイムを短縮して管理する – この戦略では、ダウンタイムを効果的に管理することによって、すべてのサービスをできるだけ早くユーザーに戻し、ユーザーへの影響を軽減すること、高いユーザー満足度を維持すること、およびサービス レベル アグリーメントを満たすことに努める必要があります。
回復性を提供する – 更新中に致命的な障害が発生した場合、管理者は、ファームとアプリケーションを更新前の状態にできるだけ早く復元し、すべてのサービスをユーザーに戻す必要があります。
一貫性を提供する - 更新後は、Microsoft SharePoint Server を実行するすべてのサーバーが同じバージョン レベルに更新され、同じ構成になっている必要があります。一貫性のない環境では、予期しないダウンタイム、バグ、および問題の発生する可能性が最も高くなります。
期待される機能を提供する – 更新後のファームは、期待される機能状態になっている必要があります。これには、ソフトウェアの更新前に存在した機能が含まれるほかに、サービス パックまたは累積的な更新プログラムのインストールで期待されていた新しい機能あるいは強化された機能が含まれます。
データベース接続の概念の概要
示された目標と目的 (ダウンタイムが著しく短縮されて十分に管理されること、および更新前の状態に回復できること) を達成するには、データベース接続方法を使用する必要があります。この方法では、他のサポートされる方法 (一括アップグレード) と比べて、ソフトウェアの更新時に最高レベルの可用性が維持され、リスクの程度が最小限に抑えられます。
アップグレード オプションの詳細については、「付録 A. サポートされるアップグレード オプション」を参照してください。ここでは、2 つのアップグレード方法が詳細に比較されているほかに、いくつかの判断ポイントが示されたフローチャートが提供されます。このフローチャートを使用して、アップグレード方法を決定できます。また、このフローチャートによって、ソフトウェア更新プログラムのインストール手順の概要が示されます。
重要
「ソフトウェアの更新プロセス」(https://technet.microsoft.com/ja-jp/library/ff806329.aspx#updateprocess) で説明されているソフトウェア更新プロセスでは、一括アップグレードで必要とされるタスクのうち、データベース接続アップグレードでも必要とされる場合のある主なタスクに焦点が当てられています。更新を完了するには、すべてのファーム サーバーで、SharePoint 製品とテクノロジ構成ウィザードを実行する必要があります。
説明
データベース接続方法では、サービス パックおよび累積的な更新プログラムによって更新される運用ファームの複製を作成する必要があります。bNext (次のビルド) と呼ばれる新しいファームには、運用ファームのインフラストラクチャ、アプリケーション、およびデータが含まれます。bNext ファームは、コンテンツを含まない状態で目的のビルドに更新されます。その後、コンテンツ データベースが接続されます。次の図に、データベース接続方法の略称バージョンを示します。ここで、bCurrent (現在のビルド) ファームは既存のファームを表し、bNext ファームは bCurrent ファームのコピーを表します。
.gif "データベース接続を使用した更新プログラムのインストール")
この図に関しては、複数のデータベースを並行してアップグレードできることに注意してください。この機能によって、アップグレード時のダウンタイムを大幅に短縮できます。
更新フェーズ、ガイダンス、および主なタスク
データベース接続アップグレードのプロセスは、以下の主なフェーズで構成されます。
運用前環境でのアップグレードのテスト
新しいファームの準備
運用ファームのロック
運用のコンテンツおよびデータのレプリケーション
運用のコンテンツおよびデータを含む新しいファームのアップグレード
新しいファームでのアップグレードの終了
新しいファームでのアップグレードの検証
すべてのサービスの復元
運用前環境でのアップグレードのテスト
フル アップグレードを開始する前に、運用前環境でアップグレードのすべての側面をテストし、結果を評価することが非常に重要です。運用前環境を作成した後、計画されたアップグレードの以下の側面および要素をテストすることをお勧めします。
運用前テストで使用するファームは、運用ファームの複製であることが理想的です。ただし、これは必須の要件ではありません。通常、運用前ファームを運用ファームと同じ範囲にスケール アウトすることはできません。たとえば、フロントエンド Web サーバーが 3 または 4 台ではなく、2 台のみの場合があります。この場合、ファーム データベースは高可用性が維持されるようには構成されません。重要なことは、運用環境でのアップグレードおよび可能性のある影響を完全にテストするのに適したテスト環境を作成することです。
注意
機能のテストのみを目的として、パフォーマンスをテストしない場合は、物理コンピューターの代わりに仮想環境を使用できます。
bNext ファームでは、運用前ファームのインフラストラクチャを再度使用できます。ベスト プラクティスとして、運用前テストで使用したサーバーを完全にクリアすることをお勧めします。これにはオペレーティング システムも含まれます。新しいファームに合わせてそれらのサーバーを再構築します。サーバーのクリアは必須ではありません。ただし、運用前ファームを再利用するように選択した場合は、運用前テスト環境からすべての成果物を確実に削除してください。詳細については「アップグレードの前に環境をクリーンアップする (SharePoint Server 2010)」(https://go.microsoft.com/fwlink/?linkid=225682&clcid=0x411) を参照してください。
運用前環境を作成した後、計画されたアップグレードの以下の側面および要素をテストすることをお勧めします。
累積的な更新プログラムまたはサービス パックと共に提供される手順を確認する。 ソフトウェア更新プログラムには、アップグレードで必要とされる追加の手順または回避策が含まれる場合があります。
更新計画およびチェックリストを確認する。 運用前テストを使用して、更新計画に関するドキュメントの検証および調整を行います。ソフトウェア更新プログラムを展開するためのガイドとして、記事「データベース接続アップグレードのチェックリスト (SharePoint Server 2010)」を使用することをお勧めします。
現在のファームの動作を読み取り専用モードでテストする。 ファームのコンテンツおよびサービス アプリケーションのデータを bNext ファームに移動するプロセスの間、既存のファームは読み取り専用の状態になります。既存のファームで機能テストを実行し、アップグレード中のユーザー エクスペリエンスが許容されることを確認します。アップグレード計画プロセスの一環として運用ファームをロックする前に、記事「読み取り専用サイトでのユーザー エクスペリエンス (SharePoint Server 2010)」を確認することをお勧めします。
ビルド自動化を使用してファームを準備する。 運用前環境および bNext 環境を作成するには、可能な限り、手動プロセスを使用しないで自動化を利用することをお勧めします。自動化によって、構成の一貫性がファーム サーバー全体にわたって確保されると共に、サーバーを手動で準備する場合に発生する可能性のあるエラーがなくなります。自動化に関連するスクリプト、ツール、およびプロセスをテストします。
ユーザーの環境に合わせてカスタム自動化を開発するためのガイドとして、「付録 F. 自動化のリソース」のスクリプト コレクションを使用します。これらのスクリプトでは、Windows PowerShell 2.0 を使用して、SharePoint Server の展開とファームの構成が行われます。
ダウンタイム時間のベンチマークを確立する。 アップグレードの完了までにかかる時間を把握することが非常に重要です。最も重要な要素は、運用ファームを読み取り専用モードにする必要のある時間です。この情報を使用して、必要に応じて、更新計画を改定します。
アップグレードの結果を確認する。 アップグレードの結果が期待どおりであることを確認し、回避策が必要になる場合がある回帰バグを特定します。
新しいファームの準備
ソフトウェア更新プログラムがインストールされた bNext ファームは、現在の運用ファームのアップグレード バージョンです。bNext ファームを準備する場合、そのファームを現在の運用環境の複製となるようにします。たとえば、ファーム トポロジ、サイトの数、サーバー仕様 (物理的または仮想的)、ログイン、およびセキュリティ設定が含まれます。物理的な設計の変更を実装しないことを強くお勧めします。変更によって、アップグレードが複雑になり、未知の要素が生じて、アップグレードのリスク要因が増加する可能性があるためです。
運用前環境の場合と同様に、ビルド自動化を使用して bNext ファームの作成とテストを行うことをお勧めします。ビルド自動化を利用することで、構成エラーの可能性が大幅に減少し、全体的なビルド時間が大幅に短縮されます。また、自動化されたテストによって、アップグレードに影響する可能性のある構成の誤りを容易に見つけることができます。
コンテンツ データベースの接続とサービス アプリケーションの作成に進む前に、テストを実行してファーム構成が正しいことを確認します。
運用ファームのロック
アップグレード プロセスをテストし、bNext ファームを構築した後は、運用環境を読み取り専用の状態にしてアップグレードを完了します。ファームをロックし、アップグレード中に運用ファームでのコンテンツの作成、削除、または更新を禁止することで、コンテンツの再現性が保証されます。
重要
ファームでデータベース ミラーリングを使用している場合、データベースに読み取り専用フラグを設定する前にミラーリングを一時停止する必要があります。
新しいファームを同じビルド レベルにアップグレードしている間は、少なくとも、コンテンツ データベースを読み取り専用モードにする必要があります。また、読み取り専用モードでの実行がサポートされる任意のサービス アプリケーション データベースに読み取り専用の設定を構成することもできます。詳細については、「付録 E. サービス アプリケーション移行のリファレンス」を参照してください。
注意
データベースを読み取り専用に設定すると、読み取り専用フラグを設定する接続を除くすべての接続が停止します。データベースは保留中の変更をコミットしません。読み取り専用フラグの設定が完了すると、他の接続が有効になります。
データベースを読み取り専用として構成する方法の詳細については、「付録 B. SQL Server データベースを読み取り専用として構成する」を参照してください。
読み取り専用の Microsoft SharePoint Server ファームを実行する方法の詳細については、「読み取り専用データベースを使用するファームを実行する (SharePoint Server 2010)」を参照してください。
運用のコンテンツおよびデータのレプリケーション
データベース接続方法を使用して bNext ファームを更新するには、すべてのコンテンツ データベースとサービス アプリケーション データベースのコピーを bNext のデータベース サーバーにインストールする必要があります。運用ファームでデータベースのバックアップを作成し、そのバックアップを bNext にコピーして、その後、bNext でバックアップを復元してデータベース サーバーに接続する必要があります。
注意
コンテンツとデータをレプリケートするための他の技法があります。詳細については、「付録 D. ファームのコンテンツとデータをレプリケートするための技法」を参照してください。
運用のコンテンツおよびデータを使用して新しいファームをアップグレードする
コンテンツ データベースとサービス アプリケーション データベースのバックアップをコピーして、SQL Server を実行する bNext 環境のサーバーに復元した後、実際のデータベース接続プロセスを実行できます。接続およびアップグレードの手順は各データベースによって異なるため、必要な技法は少し異なります。
サービス アプリケーションを新しいファームに追加する
運用ファームのサービス アプリケーションを bNext ファームに追加するには、複数の方法を使用する必要があります。これは、各サービス アプリケーションに、サービス アプリケーションの移動または復元に対する特定の要件が存在するためです。すべてのサービス アプリケーションで使用できる方法はありません。詳細については、「付録 E. サービス アプリケーション移行のリファレンス」を参照してください。以下のいずれかの方法を使用して、サービス アプリケーションを bNext ファームに追加できます。
データベース接続 – 運用ファームからコピーしたデータベースを復元して接続することで、サービス アプリケーション データベースを作成します。
再作成 – 新しい bNext 環境でサービス アプリケーションを最初から再作成します。自動化を使用して、運用ファームから bNext ファームに設定を移行することをお勧めします。
SharePoint バックアップと復元 – サーバーの全体管理または Windows PowerShell を使用してサービス アプリケーションをバックアップし、bNext ファームに復元します。
コンテンツ データベースとサービス アプリケーション データベースに加えて、以下の構成データベースを bNext ファームで再度作成する必要があります。
WSS_Search
SharePoint 構成
SharePoint 管理コンテンツ
コンテンツ データベースを新しいファームに追加する
コンテンツ データベースを新しいファームに接続する前に、復元するデータベース内にあるサイト コレクションと衝突する URL パスを持つサイト コレクションが、データベースのマウント先の Web アプリケーションに存在しないことを確認します。次の手順を使用して、データベースを接続します。
Test-SPContentDatabase コマンドレットを使用して、マウントするデータベースをテストします。
Mount-SPContentDatabase コマンドレットを使用して、コンテンツ データベースを対象の Web アプリケーションにマウントします。
新しいファームでのアップグレードの終了
アップグレードで必要とされる一部のタスクは、データベースが接続されてアクティブになった後にのみ実行できます。その一部 (ただし必ずしもこれらに限定されない) の手順を以下に示します。
SQL Server 構成を確認する - 必要なメンテナンス計画が正しく復元され、bNext ファーム用に正しく構成されていることを確認します。たとえば、統計情報とインデックスを維持するメンテナンス ジョブ、バックアップ ジョブ、データベース ミラーリングなどを確認します。
プロファイルのインポートを実行する - ユーザー プロファイル データの増分インポートを開始して、プロファイル データベースが最新であること、およびプロファイル同期が新しい環境で正常に動作することを確認することをお勧めします。
コンテンツのクロール - 増分クロールを開始して、インデックスが、アップグレードされたコンテンツ データベースと同期していること、およびクロールが正しく機能していることを確認します。
新しいファームでのアップグレードの検証
ユーザーを新しい運用ファームにリダイレクトする前に、最終手順として、bNext ファームに対して機能テストを実行します。このテストは手動で実行できますが、自動化を使用することをお勧めします。自動化を使用すると、手動によるテストよりも厳密なテストを実施できます。また、自動化により、ファーム サーバー全体にわたってテストの一貫性が維持されます。
以下の記事で説明されているガイダンスとトラブルシューティング手順を使用して、アップグレードを検証することをお勧めします。
すべてのサービスの復元
bNext ファームが完全に操作可能な状態になり、ユーザーの要求を受け付ける準備ができると、読み取り専用の運用ファームに現在向けられているトラフィックを bNext ファームにリダイレクトする必要があります。このリダイレクトをロード バランサーで構成することをお勧めします (該当する場合)。この方法では、アプリケーションの仮想 IP アドレスが変更されないので、DNS の変更を環境にプッシュする要件がバイパスされます (すべてのクライアントに対してこの要件が完了するまで時間がかかる可能性があります)。
更新戦略の一環としての自動化
大規模または複雑な SharePoint Server 2010 環境では、ソフトウェア更新プログラムを展開するうえで自動化が重要な役割を果たす可能性があります。サーバーとファームの準備を自動化することで、現在の SharePoint Server 環境と、アップグレードの一環として作成される新しい環境との間で、ビルドの一貫性を容易に保つことができます。ビルドの一貫性が維持されることおよびエラーが減少することに加えて、自動化を使用することでファームのビルド時間が短縮され、全体的な環境のアップグレード時間が短縮されます。
自動化ソリューションには以下の要素を含める必要があります。
インフラストラクチャの準備 – SharePoint Server 2010 を仮想環境で実行する場合、仮想マシン、ディスク、仮想ネットワーク、および仮想環境の他のインフラストラクチャ コンポーネントの作成と準備を含めます。
オペレーティング システムのインストールと構成 – Windows Server および重要な更新プログラムの自動的なインストールと構成を含めます。展開のためにシステム準備ツール (Sysprep) を使用して準備したイメージが含まれる複数展開の技法、Windows 展開サービス、およびスクリプト化されたオペレーティング システム構成を使用して準備を自動化できます。
サーバーのインストールと構成 – サーバーの準備が完了すると、SQL Server および SharePoint Server 2010 をインストールして構成できます。Windows PowerShell 2.0 スクリプトを使用して、これらの 2 つの製品のインストールと構成を行うことができます。これらの製品を現在の更新プログラムのバージョン レベルに必ずアップグレードしてください。この処理もスクリプトを使用して実行できます。
アプリケーションの移行と復元 – bNext ファームの構築を自動化するための最後の要素は、データベースの移行とアップグレード、最終的なアプリケーション構成、および機能テストを自動化することです。自動化スクリプトを計画して実装する場合、以下のタスク用のスクリプトを検討します。
現在のファームを読み取り専用モードに変更する
現在のファームを読み取り/書き込みモードに戻す (アップグレードのロールバックが必要な場合)
ロード バランサーを構成する
カスタムの SharePoint Server ソリューションをインストールする
現在のファームのデータベース サーバーから、アップグレードされたデータベース サーバーにデータベースを移動する
データベースを bNext ファームのデータベース サーバーにマウントする
機能テスト
自動化のアーキテクチャ
以下のモデルは、SharePoint Server 自動化ソリューションの階層化されたアーキテクチャの概念を示しています。
.gif "ソフトウェア更新プログラム自動化のアーキテクチャ")
最上位レベルには、SharePoint Server の "ワークロード" が位置します。ワークロードは、環境の論理的な機能 (.COM の Web コンテンツ管理のワークロードなど) を表します。ワークロードは 1 つ以上のファームで構成されます。Web コンテンツ管理のシナリオでは、これは運用ファームとステージング ファームが考えられます。各ファームには、ワークロードと環境に基づいてサーバーのトポロジが存在します。最終的に、サーバーの構成では、1 つ以上の "ビルド タスク" が正常に実行される必要があります。たとえば、ビルド タスクとして "ファームへのサーバーの参加" が考えられます。
対象の環境を個々のビルド タスクに縮小する場合、範囲が限定された自動化スクリプトを設計して構築できます。これにより、自動化スクリプトの設計と構築が大幅に容易になり、自動化スクリプトが安定します。一連のビルド タスク スクリプトの単体テストが完了すると、それらのスクリプトを、Microsoft System Center で動作する、より上位レベルのオーケストレーション スクリプトまたはオーケストレーション製品 (Opalis など) 内で使用できます。詳細については、「Microsoft Server and Cloud Platform (英語)」(https://go.microsoft.com/fwlink/?linkid=186236&clcid=0x411) (英語) のページを参照してください。
自動化ツールとリソース
いくつかのテクノロジ オプションを使用して、SharePoint Server 環境の展開と構成を自動化できます。通常、自動化ソリューションでは、以下の技法の組み合わせが使用されます。
Windows PowerShell 2.0
Windows Server 2008、SharePoint Server 2010、および SQL Server 2008 のすべてで、Windows PowerShell を使用する自動化がサポートされます。Windows PowerShell は、強力で堅牢なスクリプト言語およびランタイムであり、自動化のための推奨テクノロジです。Windows PowerShell では、製品固有のコマンドレット, .NET API 呼び出し、およびコマンドライン ツールも使用できます。
コマンドライン ツール
Windows Server 2008、SharePoint Server 2010、および SQL Server 2008 にも、展開と構成の自動化を可能にするコマンドライン ツールが用意されています。ただし、これらのテクノロジの多くのコマンドライン オプションは、使用できなくなり、Windows PowerShell コマンドレットで置き換えられています (別のコマンドライン ツールを使用する前に、コマンドを置き換える Windows PowerShell オプションがないかどうかを確認してください)。
.NET API
Windows Server 2008、SharePoint Server 2010、および SQL Server 2008 では、サポートされる API を使用して製品の機能が公開されます。このサポートされるほとんどの API には、Microsoft .NET Framework を使用してアクセスできます。特定の製品の自動化機能が Windows PowerShell コマンドレットまたはコマンドライン ツールとして存在しない場合、製品の API を使用して必要な自動化のレベルを達成できる場合があります。
既存のスクリプト コレクション
以下のスクリプト コレクションを使用して、SharePoint Server の展開およびファームの構成を行うことができます。これらのスクリプトをそのまま使用するか、ユーザーの環境に合わせてカスタム スクリプトを開発するためのガイドとして使用できます。
SPModule.zip。SPModule.zip ファイルは、SharePoint 製品グループのメンバーによって記述された Windows PowerShell モジュールのサポートされていないサンプルです。このモジュールを使用すると、SharePoint ファームのインストールに関連する簡単な管理タスクを実行できます。SPModule.zip をダウンロードする (英語) (https://go.microsoft.com/fwlink/?linkid=229657&clcid=0x411) (英語)。
AutoSPInstaller。このプロジェクトは、Windows PowerShell 2.0 スクリプト、XML 入力ファイル、および展開/構成プロセスを開始するときに使用する標準の Windows バッチ ファイルで構成されています。AutoSPInstaller プロジェクトをダウンロードする (英語) (https://go.microsoft.com/fwlink/?linkid=229659&clcid=0x411) (英語)。
ラン ブック自動化
ラン ブック自動化 (RBA) を使用すると、SharePoint Server 環境の準備を完全に自動化できます。RBA では、ユーザーのシステムおよびネットワークの運用プロセスに合わせて作成されるワークフローの定義、構築、オーケストレーション、および管理を行ったり、そのワークフローに関するレポートを作成したりできます。オーケストレーションでは、複雑な依存関係および検証ロジックが含まれる可能性のあるワークフローの一部としてビルド タスクを特定の順序で実行できます。オーケストレーションを実装するには、Opalis などの製品を使用する方法が推奨されますが、他の製品および技法をこの目的で使用することもできます。
単一ファームでデータベース接続アップグレードを行うための論理的な手順
次の図のファーム トポロジは、高可用性を提供する典型的な 3 層ファームを示しています。
.gif "3 層 SharePoint Server 2010 ファーム")
この図に関しては、次の点に注目してください。
2 台のフロントエンド Web サーバー (WEB-1 および WEB-2) が共に負荷分散されており、ロード バランサーのローテーションに組み込まれています。これらのサーバーでは、bCurrent ファームと同じバージョン レベルに更新された Windows Server 2008 R2 が実行されます。
検索の可用性を高めるために 2 台のアプリケーション サーバー (APP-1 および APP-2) が使用されています。3 番目のサーバー (APP-3) では、サーバーの全体管理およびサービス アプリケーションがホストされます。これらのサーバーでは、bCurrent ファームと同じバージョン レベルに更新された Windows Server 2008 R2 が実行されます。
ファーム データベース サーバー (DB-1) がミラー化 (DB-2) されており、高可用性が提供されます。これらのサーバーでは、bCurrent ファームと同じバージョン レベルに更新された Windows Server 2008 R2 および Microsoft SQL Server 2008 R2 が実行されます。
単一ファームのアップグレード手順
SharePoint 更新プログラムを展開するための詳細手順は、2 つの部分に分かれます。1 番目の部分では、運用前環境を処理します。2 番目の部分のタスクでは、新しいファーム (bNext) の作成と構成を行います。
運用前ファーム
以下の手順は、運用前テスト ファームの構成方法を示しています。
運用ファーム トポロジのコア コンポーネントが含まれるテスト ファームを作成します。自動化を使用してサーバーの準備とファームの展開を行うことを検討します。ここで得られた経験は、bNext ファームでの自動化の実装に進化する可能性があります。
運用前テストでは、テストを実行するのに必要な最小数のサーバーのみが必要です。前の図に示された単一ファームのシナリオによると、運用前テストでは、以下のサーバーが最低限必要です。
2 台のフロントエンド Web サーバー。これは、負荷分散の最小要件です。
1 台のアプリケーション サーバー。テストで冗長性が要求されない場合、このサーバーを使用して、サーバーの全体管理、および運用ファームにインストールされたすべてのサービスを実行できます。
1 台のデータベース サーバー。テストで冗長性が要求されない場合、ミラー化されたデータベース サーバーは必要ありません。
bCurrent ファームの構成に一致するようにテスト ファームを構成します。テスト ファームを準備するためのガイドとして以下の手順を使用し、最小セットの運用前テストを完了します。
重要
ユーザーの運用環境を反映するように、テスト トポロジとテストをカスタマイズする必要があります。
運用ファームの完全なコンテンツ バックアップをテスト ファームに復元します。ファイルのコピーまたはバックアップの復元にかかった経過時間など、ベンチマーク情報を収集します。この情報は、アップグレードの計画で使用できます。
運用ファーム上のアプリケーションおよびカスタマイズをインストールします。計画、アップグレード、およびトラブルシューティングで使用できるすべてのベンチマーク データを記録します。カスタマイズの詳細については、「カスタマイズの処理方法を決定する (SharePoint Server 2010)」を参照してください。
ソフトウェア更新プログラムをダウンロードし、インストール ソースを準備します。詳細については、「ソフトウェア更新プログラムを取得して、インストール ソースを準備する (オプション)」を参照してください。このインストール ソースを使用して、運用前テスト、および bNext ファームへの更新プログラムのインストールを行うことができます。
ソフトウェア更新プログラムをテストします。ソフトウェア更新プログラムのインストール後に、期待される SharePoint Server 機能が存在することを確認します。つまり、回帰バグがないことを確認します。
運用ファームの機能を監視します。コンテンツ データベースとサービス アプリケーション データベースが読み取り専用に設定されたときの運用ファームの機能を監視します。
プロセスとツールを検証します。アップグレードのプロセスを検証し、アップグレードまたはアップグレード後のテストを自動化するために使用するツールをテストします。
bNext ファーム
以下の手順は、bNext ファームの準備および構成を行って、そのファームを新しい bCurrent ファームとして運用環境に移行できるようにする方法を示しています。
注意
運用前サーバーを再利用する場合、オペレーティング システムからサーバーを再構築することをお勧めします。この方法は、bNext ファームの SharePoint Server 展開に影響する可能性のあるテスト成果物が残らないようにするための最適な方法です。
自動化スクリプトを使用して、bNext ファームに必要なサーバーを準備します。この記事のこのシナリオでは、これには 3 台のフロントエンド Web サーバー、3 台のアプリケーション サーバー、およびミラー化されているファーム データベース サーバーが含まれます。
準備作業には、オペレーティング システムを、少なくとも運用ファームのサーバーと同じサービス パック レベルまたはソフトウェア更新プログラム レベルに更新する作業が含まれます。必要に応じて、かつ適切な場合は、最新のオペレーティング システム更新プログラムを bNext サーバーに適用します。
bNext データベース サーバーを準備します。これには、次の作業が含まれます。
SQL Server をインストールし、設定中、運用ファームの設定に合わせて構成します。
SQL Server を、少なくとも運用ファームと同じバージョン レベルに更新します。
bCurrent ログオンとアクセス許可を bNext データベース サーバーにコピーします。
必要なサービス、ファイアウォールの設定を構成し、データベースの機能を検証します。
重要
プライマリ データベースのミラー化は、SharePoint 製品とテクノロジ構成ウィザードでファーム ソフトウェアを更新するまで行わないでください。
SharePoint Server バイナリを bNext サーバーにインストールします。
SharePoint Server をインストールします。ただし、構成ウィザードは実行しないでください。
累積的な更新プログラムまたはサービス パック バイナリをインストールします。ただし、構成ウィザードは実行しないでください。
SharePoint 製品とテクノロジ構成ウィザードを実行して新しいファームを作成します。
重要
サービス アプリケーションは作成しないでください。このプロセスの後で作成するか、バックアップから復元します。
次の作業を行って、bNext を運用ファームのコピーとして準備します。
ファームの全般設定を構成します。
Web アプリケーションを作成して構成します。
カスタム ソリューションを bCurrent ファームから bNext 環境にコピーします。これらのソリューションの展開に影響する可能性がある依存関係に注意してください。たとえば、この時点ではファーム構成には存在しない依存関係がサービス アプリケーションに存在する可能性があります。詳細については、「付録 C. カスタマイズ展開のガイダンス」を参照してください。
運用ファームのデータベースの完全バックアップを行います。これには、SQL Server のバックアップと回復をサポートするコンテンツ データベースとサービス アプリケーション データベースが含まれます。
前の手順で説明されているデータベースのトランザクション ログのバックアップの取得を開始します。次の理由により、差分バックアップではなくトランザクション ログのバックアップをお勧めします。
これにより作業損失を最小限に抑えることができます。
バックアップ ファイルは小さいので、ネットワーク上での転送時間が短くなります。さらに、バックアップ ファイルは bNext ファームに毎日コピーできます。一度にまとめてコピーする必要はありません。
ファイル サイズとデザインにより、運用データベースを bNext ファームに完全に復元できます。詳細については、「トランザクション ログのバックアップ」(https://go.microsoft.com/fwlink/?linkid=152194&clcid=0x411) を参照してください。
運用データベースの完全バックアップを bNext SQL Server 環境に復元します。
重要
トランザクション ログのバックアップを完全バックアップに復元できるように NORECOVERY オプションを使用してバックアップを復元します。詳細については、「SQL Server でのバックアップの復元と復旧の動作について」(https://go.microsoft.com/fwlink/?linkid=134473&clcid=0x411) を参照してください。
運用ファーム (bCurrent) コンテンツ データベースと適切なサービス アプリケーション データベースを読み取り専用モードに変更します。運用ファームをロックする前に、次の点に注意してください。
一部のサービス アプリケーションは読み取り専用モードをサポートしていません。また、Microsoft SharePoint Server Search、Usage and Health Data Collection などのように、データベースが読み取り専用に設定されていなければ動作しないアプリケーションもあります。詳細については、「付録 E. サービス アプリケーション移行のリファレンス」を参照してください。
ファームのロック中に、構成設定やサービス アプリケーションが変更される可能性があります。たとえば、Search サービスは読み取り専用では動作しないので、管理者が設定を変更する場合があります。この変更は新しいファームには反映されません。ダウンタイム時間を最小限に抑えデータ損失の可能性を減らすには、この点を考慮したうえで計画する必要があります。
データベースを読み取り専用に設定すると、読み取り専用フラグを設定する接続を除くすべての接続が停止します。読み取り専用フラグの設定が完了すると、他の接続が有効になります。
既存のファームがミラー化されている場合は、サンプル ファームと同様に、データベースを読み取り専用に設定する前にミラーリングを一時停止する必要があります。詳細については、「データベース ミラーリングの管理方法に関するトピック (データベース エンジン)」(https://go.microsoft.com/fwlink/?linkid=225804&clcid=0x411) を参照してください。
次の作業を行って、Microsoft SharePoint Server Search を bNext ファームにインストールする準備をします。
SharePoint バックアップを使用して、検索データベースをバックアップし、そのバックアップを bNext ファームにコピーします。
インデックス パーティションを bNext ファームのアプリケーション サーバーにコピーします。
検索トポロジを XML ファイルにエクスポートし、このファイルを bNext データベース サーバーにコピーします。
次の作業を行って、Microsoft SharePoint Server Search を bNext ファームに復元します。
bNext サーバーの名前と bCurrent サーバーの名前が異なる場合は、エクスポートされた検索トポロジが含まれる XML ファイルを編集する必要があります。このファイルを編集し、新しいサーバー名を指定します。
Restore-SPEnterpriseSearchServiceApplication コマンドレットを使用して、検索を復元します。
bNext でファーム サービスを再作成し、必要に応じて、サービスを、bCurrent バックアップから復元されたアプリケーション サービス データベースに関連付けます。
SharePoint カスタム ソリューションを bNext 環境にインストールします。
重要
カスタマイズの範囲や性質がサービスに依存している可能性があるので、サービスを再作成した後に、カスタマイズを再インストールすることをお勧めします。
カスタム ソリューションをインストールした後、次の作業を行います。
Web アプリケーションが最初に bNext ファームに作成されたときに作成された空のコンテンツ データベースをすべて削除します。
Test-SPContentDatabase コマンドレットを使用して、新しく作成された Web アプリケーションに対してコンテンツ データベースをテストし、必要なカスタマイズがすべて展開されていること、および問題がないことを確認します。
Mount-SPContentDatabase コマンドレットを使用して、コンテンツ データベースを bNext ファームにマウントします。
重要
複数のコンテンツ データベースがある場合は、ルート サイト コレクションが含まれるデータベースを最初にマウントします。
Upgrade-SPContentDatabase コマンドレットを使用して、bNext ファーム上のコンテンツ データベースをアップグレードします。
アップグレードが完了した後、次のデータベース サーバー タスクを実行します。
データベースのミラーリングが bCurrent ファームで有効になっていた場合は、これを再確立します。
すべてのデータベース メンテナンス ジョブを復元し、テストします。
次の SharePoint プロセスを開始します。
検索クロール
プロファイルのインポート
必要なサービスすべてが実行中であることを確認します。
bNext ファームに対して機能テストを実行し、アップグレードが適切に行われたことを確認します。詳細については、「アップグレードの状態とアップグレードされたサイトを確認する (SharePoint Server 2010)」を参照してください。
ユーザー要求を bNext ファームにリダイレクトします。アップグレードをロールバックすることが必要になった場合に備えて、読み取り専用の bCurrent ファームはそのままにしておいてください。
アップグレード計画で定義した安定化期間中は、新しい bCurrent ファーム (bNext) のテストおよび監視を続けます。以前のビルドにロールバックする必要がないと確信した場合、古い bCurrent ファームを削除し、サーバーを他の目的で使用できるようにリサイクルすることができます。
新しいファームの構成のインベントリを取得して、今後のソフトウェア更新に使用できる最新情報を入手できるようにします。
フェデレーション ファームでデータベース接続アップグレードを行うための論理的な手順
フェデレーション ファームに SharePoint Server 2010 更新プログラムをインストールするには、単一ファームに更新プログラムをインストールする場合よりも綿密な予備計画を作成する必要があります。ただし、データベース接続方法を使用してフェデレーション ファームに更新プログラムをインストールするための考え方および基本的な手法は、単一ファームの場合と同じです。フェデレーション環境のアーキテクチャによって、ファーム サーバーの修正およびアップグレードのニュアンスは、ファームごとに異なる場合があります。
アップグレードの順序と下位互換性
フェデレーション ファーム環境のアップグレードに関して最もよく寄せられる質問は、ファーム間の修正プログラムの適用順序および n-1 下位互換性に関するものです。SharePoint Server 2010 では、以下のどちらかの順序で、フェデレーション サービス ファームをアップグレードできます。
最初にプロバイダー ファームをアップグレードし、次にコンシューマー ファームをアップグレードする。
最初にコンシューマー ファームをアップグレードし、次にプロバイダー ファームをアップグレードする。
Microsoft SharePoint Server 2010 Service Pack 1 (SP1) の既知の問題
SharePoint 製品と構成ウィザード (psconfig.exe) を実行してプロバイダー サービス ファームをアップグレードすることなく、最初にサービス コンシューマー ファームに修正プログラムを適用すると、n-1 互換性の問題が発生する可能性があります。潜在的な問題として、SharePoint Server Search サービスが機能しないこと、SharePoint Server インデックス サービスが機能しないこと、およびユーザーが展開したソリューションにおいてクレーム要求が機能しないことがあります。
重要
コンシューマー ファームを最初にアップグレードすることを選択した場合、コンシューマー ファームに修正プログラムを適用して SP1 にした後は、n-1 の状態になっている期間をできるだけ短くすることをお勧めします。詳細については、「SharePoint 2010 製品の更新プログラム」(https://go.microsoft.com/fwlink/?linkid=209614&clcid=0x411) のサイトを参照してください。
フェデレーション ファームのアップグレード手順
3 つのファームに SharePoint Server 更新プログラムをインストールするために必要なシーケンスと手順を示す例として、次の図に示されているフェデレーション ファーム環境を使用します。
.gif "コンシューマー ファームが 2 のフェデレーション サービス ファーム")
前の図のフェデレーション ファームは、次の要素で構成されます。
フェデレーション検索を含む 1 つのフェデレーション サービス プロバイダー ファーム (図の "プロバイダー ファーム")
2 つのフェデレーション コンシューマー ファーム (図の "コンシューマー A" および "コンシューマー B")
説明のために、最初にプロバイダー ファームをアップグレードし、次に 2 つのコンシューマー ファームをアップグレードします。
サービス プロバイダー ファームのアップグレードを続行する前に、この記事で既に説明されている運用前環境およびデータベース接続方法に関する情報とガイダンスについて十分に理解しておくことをお勧めします。
bNext プロバイダー ファーム
以下の手順は、bNext プロバイダー ファームの準備および構成を行って、そのプロバイダー ファームを新しい bCurrent プロバイダー ファームとして運用環境に移行できるようにする方法を示しています。
自動化スクリプトを使用して、bNext ファームに必要なサーバーを準備します。この記事のこのシナリオでは、これには 3 台のフロントエンド Web サーバー、3 台のアプリケーション サーバー、およびミラー化されているファーム データベース サーバーが含まれます。
準備作業には、オペレーティング システムを、少なくとも運用ファームのサーバーと同じサービス パック レベルまたはソフトウェア更新プログラム レベルに更新する作業が含まれます。必要に応じて、かつ適切な場合は、最新のオペレーティング システム更新プログラムを bNext サーバーに適用します。
bNext データベース サーバーを準備します。これには、次の作業が含まれます。
SQL Server をインストールし、設定中、運用ファームの設定に合わせて構成します。
SQL Server を、少なくとも運用ファームと同じバージョン レベルに更新します。
bCurrent ログオンとアクセス許可を bNext データベース サーバーにコピーします。
必要なサービス、ファイアウォールの設定を構成し、データベースの機能を検証します。
重要
プライマリ データベースのミラー化は、SharePoint 製品とテクノロジ構成ウィザードでファーム ソフトウェアを更新するまで行わないでください。
SharePoint Server バイナリを bNext サーバーにインストールします。
SharePoint Server をインストールします。ただし、構成ウィザードは実行しないでください。
累積的な更新プログラムまたはサービス パック バイナリをインストールします。ただし、構成ウィザードは実行しないでください。
SharePoint 製品とテクノロジ構成ウィザードを実行して新しいファームを作成します。
重要
サービス アプリケーションは作成しないでください。このプロセスの後で作成するか、バックアップから復元します。
次の作業を行って、bNext を運用ファームのコピーとして準備します。
ファームの全般設定を構成します。
Web アプリケーションを作成して構成します。
カスタム ソリューションを bCurrent ファームから bNext 環境にコピーします。これらのソリューションの展開に影響する可能性がある依存関係に注意してください。たとえば、この時点ではファーム構成には存在しない依存関係がサービス アプリケーションに存在する可能性があります。詳細については、「付録 C. カスタマイズ展開のガイダンス」を参照してください。
運用ファームのデータベースの完全バックアップを行います。これには、SQL Server のバックアップと回復をサポートするコンテンツ データベースとサービス アプリケーション データベースが含まれます。
前の手順で説明されているデータベースのトランザクション ログのバックアップの作成を開始します。次の理由により、差分バックアップではなくトランザクション ログのバックアップをお勧めします。
これにより作業損失を最小限に抑えることができます。
バックアップ ファイルは小さいので、ネットワーク上での転送時間が短くなります。さらに、バックアップ ファイルは bNext ファームに毎日コピーできます。一度にまとめてコピーする必要はありません。
ファイル サイズとデザインにより、運用データベースを bNext ファームに完全に復元できます。詳細については、「トランザクション ログのバックアップ」(https://go.microsoft.com/fwlink/?linkid=152194&clcid=0x411) を参照してください。
運用データベースの完全バックアップを bNext SQL Server 環境に復元します。
重要
トランザクション ログのバックアップを完全バックアップに復元できるように NORECOVERY オプションを使用してバックアップを復元します。詳細については、「SQL Server でのバックアップの復元と復旧の動作について」(https://go.microsoft.com/fwlink/?linkid=134473&clcid=0x411) を参照してください。
運用ファーム (bCurrent) コンテンツ データベースと適切なサービス アプリケーション データベースを読み取り専用モードに変更します。運用ファームをロックする前に、次の点に注意してください。
一部のサービス アプリケーションは読み取り専用モードをサポートしていません。また、Microsoft SharePoint Server Search、Usage and Health Data Collection などのように、データベースが読み取り専用に設定されていなければ動作しないアプリケーションもあります。詳細については、「付録 E. サービス アプリケーション移行のリファレンス」を参照してください。
ファームのロック中に、構成設定やサービス アプリケーションが変更される可能性があります。たとえば、Search サービスは読み取り専用では動作しないので、管理者が設定を変更する場合があります。この変更は新しいファームには反映されません。ダウンタイム時間を最小限に抑えデータ損失の可能性を減らすには、この点を考慮したうえで計画する必要があります。
データベースを読み取り専用に設定すると、読み取り専用フラグを設定する接続を除くすべての接続が停止します。読み取り専用フラグの設定が完了すると、他の接続が有効になります。
既存のファームがミラー化されている場合は、サンプル ファームと同様に、データベースを読み取り専用に設定する前にミラーリングを一時停止する必要があります。詳細については、「データベース ミラーリングの管理方法に関するトピック (データベース エンジン)」(https://go.microsoft.com/fwlink/?linkid=225804&clcid=0x411) を参照してください。
次の作業を行って、Microsoft SharePoint Server Search を bNext ファームにインストールする準備をします。
SharePoint バックアップを使用して、検索データベースをバックアップし、そのバックアップを bNext ファームにコピーします。
インデックス パーティションを bNext ファームのアプリケーション サーバーにコピーします。
検索トポロジを XML ファイルにエクスポートし、このファイルを bNext データベース サーバーにコピーします。
次の作業を行って、Microsoft SharePoint Server Search を bNext ファームに復元します。
bNext サーバーの名前と bCurrent サーバーの名前が異なる場合は、エクスポートされたトポロジが含まれる XML ファイルを編集する必要があります。このファイルを編集し、新しいサーバー名を指定します。
Restore-SPEnterpriseSearchServiceApplication コマンドレットを使用して、検索を復元します。
bNext でファーム サービスを再作成し、必要に応じて、サービスを、bCurrent バックアップから復元されたアプリケーション サービス データベースに関連付けます。
SharePoint カスタム ソリューションを bNext 環境にインストールします。
重要
カスタマイズの範囲や性質がサービスに依存している可能性があるので、サービスを再作成した後に、カスタマイズを再インストールすることをお勧めします。
カスタム ソリューションをインストールした後、次の作業を行います。
Web アプリケーションが最初に bNext ファームに作成されたときに作成された空のコンテンツ データベースをすべて削除します。
Test-SPContentDatabase コマンドレットを使用して、新しく作成された Web アプリケーションに対してコンテンツ データベースをテストし、必要なカスタマイズがすべて展開されていること、および問題がないことを確認します。
Mount-SPContentDatabase コマンドレットを使用して、コンテンツ データベースを bNext ファームにマウントします。
重要
複数のコンテンツ データベースがある場合は、ルート サイト コレクションが含まれるデータベースを最初にマウントします。
Upgrade-SPContentDatabase コマンドレットを使用して、bNext ファーム上のコンテンツ データベースをアップグレードします。
アップグレードが完了した後、次のデータベース サーバー タスクを実行します。
データベースのミラーリングが bCurrent ファームで有効になっていた場合は、これを再度確立します。
すべてのデータベース メンテナンス ジョブを復元し、テストします。
次の SharePoint プロセスを開始します。
検索クロール
プロファイルのインポート
必要なサービスすべてが実行中であることを確認します。
bNext ファームに対して機能テストを実行し、アップグレードが適切に行われたことを確認します。詳細については、「アップグレードの状態とアップグレードされたサイトを確認する (SharePoint Server 2010)」を参照してください。
ユーザー要求を bNext ファームにリダイレクトします。アップグレードをロールバックすることが必要になった場合に備えて、読み取り専用の bCurrent ファームはそのままにしておいてください。
アップグレード計画で定義した安定化期間中は、新しい bCurrent ファーム (bNext) のテストおよび監視を続けます。以前のビルドにロールバックする必要がないと確信した場合、古い bCurrent ファームを削除し、サーバーを他の目的で使用できるようにリサイクルすることができます。
新しいファームの構成のインベントリを取得して、今後のソフトウェア更新に使用できる最新情報を入手できるようにします。
bNext コンシューマー ファーム
以下の手順は、bNext コンシューマー ファーム (例の "コンシューマー A") の準備および構成を行って、そのコンシューマー ファームを新しい bCurrent コンシューマー ファームとして運用環境に移行できるようにする方法を示しています。
自動化スクリプトを使用して、bNext ファームに必要なサーバーを準備します。この記事のこのシナリオでは、これには 3 台のフロントエンド Web サーバー、3 台のアプリケーション サーバー、およびミラー化されているファーム データベース サーバーが含まれます。
準備作業には、オペレーティング システムを、少なくとも運用ファームのサーバーと同じサービス パック レベルまたはソフトウェア更新プログラム レベルに更新する作業が含まれます。必要に応じて、かつ適切な場合は、最新のオペレーティング システム更新プログラムを bNext サーバーに適用します。
bNext データベース サーバー (CADB-1、CADB-2) を準備します。これには、次の作業が含まれます。
SQL Server をインストールし、設定中、運用ファームの設定に合わせて構成します。
SQL Server を、少なくとも運用ファームと同じバージョン レベルに更新します。
bCurrent ログオンとアクセス許可を bNext データベース サーバーにコピーします。
必要なサービス、ファイアウォールの設定を構成し、データベースの機能を検証します。
重要
プライマリ データベースのミラー化は、SharePoint 製品とテクノロジ構成ウィザードでファーム ソフトウェアを更新するまで行わないでください。
SharePoint Server バイナリを bNext サーバーにインストールします。
SharePoint Server をインストールします。ただし、構成ウィザードは実行しないでください。
累積的な更新プログラムまたはサービス パック バイナリをインストールします。ただし、構成ウィザードは実行しないでください。
SharePoint 製品とテクノロジ構成ウィザードを実行して新しいファームを作成します。
重要
サービス アプリケーションは作成しないでください。このプロセスの後で再作成するか、バックアップから復元します。
次の作業を行って、bNext を運用ファームのコピーとして準備します。
ファームの全般設定を構成します。
Web アプリケーションを作成して構成します。
カスタム ソリューションを bCurrent ファームから bNext 環境にコピーします。これらのソリューションの展開に影響する可能性がある依存関係に注意してください。たとえば、この時点ではファーム構成には存在しない依存関係がサービス アプリケーションに存在する可能性があります。詳細については、「付録 C. カスタマイズ展開のガイダンス」を参照してください。
運用ファームのデータベースの完全バックアップを行います。これには、SQL Server のバックアップと回復をサポートするコンテンツ データベースとサービス アプリケーション データベースが含まれます。
前の手順で説明されているデータベースのトランザクション ログのバックアップの作成を開始します。次の理由により、差分バックアップではなくトランザクション ログのバックアップをお勧めします。
これにより作業損失を最小限に抑えることができます。
バックアップ ファイルは小さいので、ネットワーク上での転送時間が短くなります。さらに、バックアップ ファイルは bNext ファームに毎日コピーできます。一度にまとめてコピーする必要はありません。
ファイル サイズとデザインにより、運用データベースを bNext ファームに完全に復元できます。詳細については、「トランザクション ログのバックアップ」(https://go.microsoft.com/fwlink/?linkid=152194&clcid=0x411) を参照してください。
運用データベースの完全バックアップを bNext SQL Server 環境に復元します。
重要
トランザクション ログのバックアップを完全バックアップに復元できるように NORECOVERY オプションを使用してバックアップを復元します。詳細については、「SQL Server でのバックアップの復元と復旧の動作について」(https://go.microsoft.com/fwlink/?linkid=134473&clcid=0x411) を参照してください。
運用ファーム (bCurrent) コンテンツ データベースと適切なサービス アプリケーション データベースを読み取り専用モードに変更します。運用ファームをロックする前に、次の点に注意してください。
一部のサービス アプリケーションは読み取り専用モードをサポートしていません。また、Microsoft SharePoint Server Search、Usage and Health Data Collection などのように、データベースが読み取り専用に設定されていなければ動作しないアプリケーションもあります。詳細については、「付録 E. サービス アプリケーション移行のリファレンス」を参照してください。
ファームのロック中に、構成設定やサービス アプリケーションが変更される可能性があります。たとえば、Search サービスは読み取り専用では動作しないので、管理者が設定を変更する場合があります。この変更は新しいファームには反映されません。ダウンタイム時間を最小限に抑えデータ損失の可能性を減らすには、この点を考慮したうえで計画する必要があります。
データベースを読み取り専用に設定すると、読み取り専用フラグを設定する接続を除くすべての接続が停止します。読み取り専用フラグの設定が完了すると、他の接続が有効になります。
既存のファームがミラー化されている場合は、サンプル ファームと同様に、データベースを読み取り専用に設定する前にミラーリングを一時停止する必要があります。詳細については、「データベース ミラーリングの管理方法に関するトピック (データベース エンジン)」(https://go.microsoft.com/fwlink/?linkid=225804&clcid=0x411) を参照してください。
次の作業を行って、Microsoft SharePoint Server Search を bNext ファームにインストールする準備をします。
SharePoint バックアップを使用して、検索データベースをバックアップし、そのバックアップを bNext ファームにコピーします。
インデックス パーティションを bNext ファームのアプリケーション サーバーにコピーします。
検索トポロジを XML ファイルにエクスポートし、このファイルを bNext データベース サーバーにコピーします。
次の作業を行って、Microsoft SharePoint Server Search を bNext ファームに復元します。
bNext サーバーの名前と bCurrent サーバーの名前が異なる場合は、エクスポートされたトポロジが含まれる XML ファイルを編集する必要があります。このファイルを編集し、新しいサーバー名を指定します。
Restore-SPEnterpriseSearchServiceApplication コマンドレットを使用して、検索を復元します。
bNext でファーム サービスを再作成し、必要に応じて、サービスを、bCurrent バックアップから復元されたアプリケーション サービス データベースに関連付けます。
SharePoint カスタム ソリューションを bNext 環境にインストールします。
重要
カスタマイズの範囲や性質がサービスに依存している可能性があるので、サービスを再作成した後に、カスタマイズを再インストールすることをお勧めします。
カスタム ソリューションをインストールした後、次の作業を行います。
Web アプリケーションが最初に bNext ファームに作成されたときに作成された空のコンテンツ データベースをすべて削除します。
Test-SPContentDatabase コマンドレットを使用して、新しく作成された Web アプリケーションに対してコンテンツ データベースをテストし、必要なカスタマイズがすべて展開されていること、および問題がないことを確認します。
Mount-SPContentDatabase コマンドレットを使用して、コンテンツ データベースを bNext ファームにマウントします。
重要
複数のコンテンツ データベースがある場合は、ルート サイト コレクションが含まれるデータベースを最初にマウントします。
Upgrade-SPContentDatabase コマンドレットを使用して、bNext ファーム上のコンテンツ データベースをアップグレードします。
アップグレードが完了した後、次のデータベース サーバー タスクを実行します。
データベースのミラーリングが bCurrent ファームで有効になっていた場合は、これを再度確立します。
すべてのデータベース メンテナンス ジョブを復元し、テストします。
次の SharePoint プロセスを開始します。
検索クロール
プロファイルのインポート
必要なサービスすべてが実行中であることを確認します。
bNext ファームに対して機能テストを実行し、アップグレードが適切に行われたことを確認します。詳細については、「アップグレードの状態とアップグレードされたサイトを確認する (SharePoint Server 2010)」を参照してください。
ユーザー要求を bNext ファームにリダイレクトします。アップグレードをロールバックすることが必要になった場合に備えて、読み取り専用の bCurrent ファームはそのままにしておいてください。
アップグレード計画で定義した安定化期間中は、新しい bCurrent ファーム (bNext) のテストおよび監視を続けます。以前のビルドにロールバックする必要がないと確信した場合、古い bCurrent ファームを削除し、サーバーを他の目的で使用できるようにリサイクルすることができます。
新しいファームの構成のインベントリを取得して、今後のソフトウェア更新に使用できる最新情報を入手できるようにします。
"コンシューマー A" ファームのテストが終了すると、前の手順を繰り返して、残りの bNext コンシューマー ファーム (例の "コンシューマー B") の準備、更新、および構成を行って、そのコンシューマー ファームを残りの新しい bCurrent コンシューマー ファームとして運用環境に移行できるようにします。
まとめ
この記事で提供されているガイダンスと手順は、さまざまなサイズおよび複雑さのファームで使用できます。また、複数ファームのシナリオでは、これらを一括アップグレードと共に使用することもできます。これらの手順をユーザーの環境に合わせてカスタマイズできます (また、カスタマイズする必要があります)。これらの手順と、ユーザーのアップグレード経験の記録を、将来のソフトウェア更新プログラムをインストールするためのテンプレートとして使用することをお勧めします。
付録 A. サポートされるアップグレード オプション
前述の概要で説明したとおり、ビルド間アップグレードのシナリオで SharePoint Server 2010 ソフトウェア更新プログラムをインストールするには、一括アップグレードおよびデータベース接続アップグレードの 2 つのオプションがサポートされます。それぞれに利点と欠点があります。アップグレードする環境に照らして、この利点と欠点を検討する必要があります。
一括アップグレード
一括アップグレードは、SharePoint Server インストールの現在のバージョンと同じハードウェア上で実行されます。ソフトウェア更新プログラムは、運用環境のコンピューターにインストールされます。一括アップグレードを使用すると、固定された単一プロセスの一環として、ファーム内のすべてのサーバーが新しいビルド レベルにアップグレードされます。
一括アップグレードの利点
一括アップグレードには、以下のように、データベース接続アップグレードの方法より優れたいくつかの利点があります。
追加のインフラストラクチャを用意する必要がありません。アップグレード後は、既存環境のインフラストラクチャが引き続き使用されます。
ファーム全体の設定が保持されてアップグレードされます。
アップグレード後の環境でカスタマイズできますが、アップグレードや再稼働のために手動での手順が必要になる場合があります。
一括アップグレードの欠点
一括アップグレードには、以下のように、データベース接続アップグレードの方法と比較して不利な点がいくつかあります。
運用のダウンタイムが長い - アップグレードは連続して進行します。したがって、すべてのコンテンツが順にアップグレードされるのに十分な時間を割り当てる必要があります。また、インストールのアップグレード部分を実行するために運用ファームを停止する必要があります。一部のサーバーのみを停止する方法でファーム サーバーを更新する方法も使用できますが、ファームに対してアップグレードを実行し、データベースを更新するときに、サービス要求においてファーム全体が使用できなくなります。
アンインストールができない – アップグレードの障害が発生した場合に、累積的な更新プログラムおよびサービス パックをアンストールできません。サポートされる唯一の "ロールバック" 方法は、ファーム サーバーのイメージをアップグレード前の状態に復元するか、SharePoint ファームを再構築することです。どちらの場合も、コンテンツ データベースをアップグレード前のバックアップから復元する必要があります。
環境全体の整合性 – 運用前環境でアップグレードをテストしない限り、構成の差異や構成エラーによってアップグレードが失敗する可能性があります。運用前テストを行っても、検出されなかった差異やアップグレード プロセス中の人為的なミスによって、アップグレードのエラーが発生する可能性があります。
一括アップグレードの詳細については、「ソフトウェア更新プログラムのインストール (SharePoint Server 2010)」を参照してください。
データベース接続アップグレード
データベース接続アップグレードは、アップグレード用に作成された新しいファームで実行されます。このファームは、アップグレードの対象となるファームの複製です。
データベース接続アップグレードの利点
データベース接続アップグレードには、以下のように、一括アップグレードの方法より優れたいくつかの利点があります。
大規模のミッション クリティカルなサイトでは、アップグレード中にある程度の可用性が確保されます。
この方法では、ダウンタイムを効果的に管理できるため、アップグレードを容易に予測できるようになります。
アップグレード中に致命的なエラーが発生しても、ユーザーは既存の運用環境をすぐに利用できます。
データベース接続アップグレードの欠点
データベース接続アップグレードには、以下のように、一括アップグレードの方法と比較して不利な点がいくつかあります。
コスト。この戦略は、インフラストラクチャ (物理的または仮想的) の複製およびデータの複製に依存するため、全体的なアップグレード コストが増加します。
複雑さ。構成と運用の観点から見ると、一括アップグレードよりもプロセスが複雑です。以下に例を示します。
SharePoint Server の 2 番目の運用環境を作成、アップグレード、構成、および検証する必要があります。
一部のサービス アプリケーションは完全な再作成が必要です。また一部のサービス アプリケーションは再構成が必要です。
負荷分散または DNS 解決を使用して、ユーザーを 1 つのファームから別のファームにリダイレクトする必要があります。
アップグレード中に元のファームは使用可能な状態ですが、この戦略では、アップグレード中にユーザーに 100% の読み取り/書き込みの可用性が提供されません。アップグレード中、運用ファームは読み取り専用の状態になります。この状態の期間は個々の環境によって異なります。その要因は、データベース サイズ、複雑さ、自動化機能など、さまざまです。
ソフトウェア更新の判断ポイントおよびプロセス
以下のフローチャートには、ソフトウェア更新を計画するときに検討する必要のある主な判断ポイントが示されています。また、このフローチャートには、ソフトウェア更新プログラムをインストールするときの大まかなプロセスおよびその順序も示されています。
.gif "ソフトウェア更新プログラムの決定事項と手順")
付録 B. SQL Server データベースを読み取り専用として構成する
ファームの更新のために、SQL Server データベースを読み取り専用に設定するには、次の操作が必要です。
AUTO_UPDATE_STATISTICS_ASYNC を無効にする
実行されている非同期のすべての統計更新ジョブを停止する
データベースをシングル ユーザー モードに設定する
データベースを必要な状態 (READ_ONLY) に設定する
詳細については、「ALTER DATABASE (Transact-SQL)」(https://go.microsoft.com/fwlink/?linkid=148619&clcid=0x411) を参照してください。この記事では、データベースを読み取り/書き込みに構成する方法も説明されていますが、そのためには、データベースをマルチ ユーザー モードに戻して、AUTO_UPDATE_STATISTICS_ASYNC オプションを再度有効にする必要があります。
付録 C. カスタマイズ展開のガイダンス
アップグレード中は、カスタマイズが問題なく展開されるように特に注意する必要があります。以下のガイダンスを使用して、カスタマイズをテスト ファームに展開します。
カスタマイズを読み取り専用モードでテストします。ファームが読み取り専用モードに設定されたときにカスタマイズが引き続き機能すること、またはカスタマイズが自身を無効にすることを確認します。
ソリューションの展開および機能のアクティブ化をテストします。コンテンツのない状態で、カスタマイズを正常に展開できることを確認します。ソリューション パッケージは、データベースが接続される前にファームの構築プロセスの一環として展開されます。データのない状態で、ソリューション パッケージの展開と機能のアクティブ化をテストします。
アップグレードを試みる前に、問題を修復します。テストで見つかったカスタマイズの問題に直ちに対処することをお勧めします。データベース接続方法は複雑なプロセスです。カスタマイズを展開するために回避策を使用することで複雑さが増すと、アップグレードが失敗する恐れがあります。
付録 D. ファームのコンテンツとデータをレプリケートするための技法
運用ファームのコンテンツとデータを新しいファームで使用できるようにレプリケートするには、いくつかの方法を使用できます。
ファイルのコピー
サポートされる各データベースを新しい環境にコピーする従来のファイル コピー。
| 利点 | 欠点 |
|---|---|
|
|
SQL Server バックアップと復元
この方法では、SQL Server の完全バックアップ、差分バックアップ、または増分バックアップの組み合わせを使用し、運用コンテンツをレプリケートして新しい環境に復元します。
注意
増分バックアップでは、前回の増分バックアップ以降の変更のみがバックアップされるため、増分バックアップの時間は差分バックアップよりも短くなります。一方、差分バックアップでは、最後の完全バックアップ以降のすべての変更がバックアップされます。通常、1 つのバックアップ方法を選択するうえで、時間と記憶域が決定要因になります。詳細については、「SQL Server でのデータベースのバックアップおよび復元」(https://go.microsoft.com/fwlink/?linkid=215815&clcid=0x411) を参照してください。
| 利点 | 欠点 |
|---|---|
|
|
データベース ミラーリング
データベース ミラーリングは SQL Server の機能です。この機能では、SQL Server によって、同時に 2 つのデータベースに書き込みが行われます。ほとんどの場合、データベース サーバーおよびデータの高可用性を維持するために、この機能が使用されます。この方法を使用してアップグレード用のコンテンツをレプリケートする場合、ミラー化されたデータベースをコピーしてアップグレードできるように、ミラーの半分を無効にする必要があります。SQL Server のデータベース ミラーリングの詳細については、「データベース ミラーリング」(https://go.microsoft.com/fwlink/?linkid=216767&clcid=0x411) を参照してください。
| 利点 | 欠点 |
|---|---|
|
|
ログ配布
ログ配布を使用し、トランザクション ログをレプリケートして新しい環境に配布できます。これにより、トランザクション ログを再生してデータベース サーバーのデータを再構築できます。詳細については、「ログ配布」(https://go.microsoft.com/fwlink/?linkid=149021&clcid=0x411) を参照してください。
| 利点 | 欠点 |
|---|---|
|
|
Data Protection Manager またはサードパーティによるバックアップと復元
SQL Server は、バックアップ時間の短縮と記憶域の効率の向上を可能にする Microsoft およびサードパーティのバックアップ ユーティリティをサポートします。Microsoft System Center Data Protection Manager の詳細については、「Microsoft Server and Cloud Platform (英語)」(https://go.microsoft.com/fwlink/?linkid=179139&clcid=0x411) (英語) の Web サイトを参照してください。
| 利点 | 欠点 |
|---|---|
|
|
付録 E. サービス アプリケーション移行のリファレンス
以下の表で、各 SharePoint Server サービス アプリケーションを別のデータベース サーバーに移動するための、サポートされる方法について説明します。
| サービス アプリケーション | データベース | サポートされる方法 | 読み取り専用をサポート | メモ |
|---|---|---|---|---|
Access Services |
なし |
使用不可 |
使用不可 |
|
Application Discovery and Load Balancing |
なし |
使用不可 |
使用不可 |
|
Application Registry Service |
Application Registry Service |
再作成 |
なし |
|
Business Data Connectivity |
Business Data Connectivity |
|
||
Excel Services |
なし |
使用不可 |
使用不可 |
|
Microsoft SharePoint Foundation Subscription Settings |
サブスクリプション |
データベース接続 |
||
Managed Metadata Service |
Managed Metadata Service |
|
||
PerformancePoint Services |
PerformancePoint Services |
再作成 |
||
PowerPoint Service |
なし |
使用不可 |
使用不可 |
|
Project Server サービス アプリケーション |
|
データベース接続 |
なし |
詳細については、「Project Server 2010 へのデータベース接続フル アップグレード」を参照してください。 |
SharePoint Server Search |
|
|
なし |
|
Secure Store |
Secure Store |
|
新しいデータベースのパス フレーズはソース データベースと同一にする必要があります。 |
|
Security Token Service |
再作成 |
|||
State Service |
状態 |
再作成 |
なし |
|
Usage and Health Data Collection |
ログ |
再作成 |
なし |
|
User Profile |
|
|
プロファイルでは、暗号化された FIM キーの復元が必要です。 |
|
Visio Graphics Service |
なし |
使用不可 |
使用不可 |
|
Web Analytics Service |
|
|
||
Word Automation Services |
Word Automation Services |
再作成 |
使用不可 |
|
Word Viewing Service |
なし |
使用不可 |
使用不可 |
|
付録 F. 自動化のリソース
スクリプト
以下のスクリプト コレクションを使用して、SharePoint Server の展開およびファームの構成を行うことができます。これらのスクリプトをそのまま使用するか、ユーザーの環境に合わせてカスタム スクリプトを開発するためのガイドとして使用できます。
SPModule.zip。SPModule.zip ファイルは、SharePoint 製品グループのメンバーによって記述された Windows PowerShell モジュールのサポートされていないサンプルです。このモジュールを使用すると、SharePoint ファームのインストールに関連する簡単な管理タスクを実行できます。SPModule.zip をダウンロードする (英語) (https://go.microsoft.com/fwlink/?linkid=229657&clcid=0x411) (英語)。
AutoSPInstaller。このプロジェクトは、Windows PowerShell 2.0 スクリプト、XML 入力ファイル、および展開/構成プロセスを開始するときに使用する標準の Windows バッチ ファイルで構成されています。AutoSPInstaller プロジェクトをダウンロードする (英語) (https://go.microsoft.com/fwlink/?linkid=229659&clcid=0x411) (英語)。
付録 G. その他の技術情報
アップグレード前およびアップグレード中は、以下のリソースを参照することをお勧めします。
| 記事 | 説明 |
|---|---|
Microsoft Office SharePoint Server 2007 から Microsoft SharePoint Server 2010 へのアップグレードの計画と準備に役立つ記事へのリンクが提供されています。 |
|
アップグレードをテストし、そのテストから得られた情報を基にアップグレードに必要な時間と容量を予測する方法についての記事へのリンクが提供されています。また、記事には、実際のアップグレードを実行する前に環境をクリーンアップするために使用できる手順も含まれます。 |
|
アップグレード プロセスのテストを正確かつ有効に実行するためのベスト プラクティス ガイダンスが提供されています。 |
|
アップグレードの準備、アップグレードの実行、およびアップグレード後の手順の実行に必要なすべての手順のチェックリストです。 |
|
データベース接続を使用してバージョン間のアップグレードを実行する方法についての記事へのリンクが提供されています。 |
|
コンテンツをサポートするインフラストラクチャがユーザーからの要求の処理を再開できる状態になっていることを確認するための手順が説明されています。 |
|
Psconfig コマンドライン ツール、Config.xml、および Windows PowerShell を使用して Microsoft SharePoint Server をインストールする方法についての参照情報へのリンクが提供されています。 |