アップグレードの概要

インストール済みの Windows SharePoint Services をアップグレードする方法には、全自動の一括アップグレードと、段階的なアップグレードの 2 種類があります。一括アップグレードでは、旧バージョンのデータベースを直接書き換えてしまうので、元に戻すことはできません。一方、段階的な (あるいは並列) アップグレードの場合、新旧のバージョンが同一コンピュータ上で同時に稼働し、それぞれに独立したデータベースが存在します。データの更新は、システムを停止した状態で、管理しやすい単位ごとに順次行います。

一括アップグレード

Web アプリケーション中の旧バージョンのコードを、一括して新バージョンに置き換えます。また、それまで使っていたデータベースに直接、必要な修正を施します。システム全体を一体のものとしてアップグレードするため、データベースの更新が完了するまで、SharePoint サイトは使えません。

旧バージョンのサービスやリソースについて、適用可能なアップグレード処理があればすべて実行します。元に戻すことはできません。このアップグレードにより、Windows SharePoint Services コードを実行する Internet Information Services (IIS) Web サイト (Web アプリケーション) が更新されると共に、旧バージョンで作成されたデータベースとコンテンツが修正され、最新の Windows SharePoint Services のビルドで実行できるようになります。

一括アップグレードが適しているのは、単独システムか、複数であってもごく少数である場合です。また、独自の Web パーツをサーバー ファームに追加しておらず、ある期間中にまとめてアップグレードしても問題ない、という場合にも向いています。

段階的なアップグレード

段階的なアップグレードの場合、新バージョンの Windows SharePoint Services 用データベースが別に作られ、新旧のバージョンが同一サーバー上で並列して稼働します。各サイトのサービスを新旧のバージョンで提供しつつ、ユーザーを自動的に、新バージョンが動くドメインに誘導するようになっています。いくつものサイトをまとめて、新しいデータベースとアプリケーションに移行することもできます。旧バージョンのデータはそのまま残っているので、必要であればどのサイト コレクションでも、元の状態に戻すことができます。システムの停止時間が最小限で済むようになっていますが、両バージョンを並列して稼働させること、他と切り離してアップグレードできる、自己完結したデータの部分集合を定義することが必要です。

アップグレードは 2 つの段階に分けて実施します。第 1 段階の操作は一括して行います。Version 3 のサービス インスタンス群およびリソース群を別に生成し、Version 3 の構成データベースに、旧 Version 2 のサイト情報を設定します。この段階では、Version 2 のコンテンツは元のままです。リモート サイトに対する要求を実際の URL にリダイレクトし、旧バージョンでサービスを提供する、という状態になります。第 2 段階では、サイト コレクションのコレクションをアップグレードし、順次これに移行していきます。Version 2 のサイトをロックし、そのコンテンツ データベースの内容を、Version 2 のスキーマの一時データベースにコピーした上で、必要なアップグレード処理を実行します。次に、アップグレードが済んだサイトを、Version 3 のコンテンツ データベースにコピーします。この段階で、アップグレードが済んだサイトに対する要求については、リダイレクト処理を停止します。以上の処理を、旧バージョンのサイト コレクションすべてについて繰り返します。

すべてのアップグレードが完了したら、最後に管理者が手動で Version 2 と Version 3 のリンクを解除し、アップグレード手順を終了します。

ビルド間、バージョン間のアップグレード

Windows SharePoint Services は、バージョン間、および同一バージョン内のビルド間のアップグレードができます。ビルド間のアップグレードはすべて一括で行います。ビルド番号が違っていると、同一コンピュータ上で、同じバージョンのサーバー アプリケーションを並列して稼働させることはできないからです。バージョン間のアップグレードについては、一括か段階的かを必要に応じて選ぶことができます。

アップグレード シーケンス

Windows SharePoint Services のアップグレード機構には、アプリケーションの特定のリソースやサービス インスタンスをアップグレードするために、ユーザー設定コードを実装して拡張できるインターフェイスが組み込まれています。一貫性を保ち、状況によってアップグレード結果が違ってしまうことのないよう、あるリソースを対象とするアップグレード処理コードを論理的な単位としてまとめたアップグレード シーケンスを作成し、当該リソースに一括して適用するようになっています。

高レベルのオブジェクトから順次、これに含まれる低レベルのオブジェクトに向かって必要な処理を行い、最終的にサーバー ファーム全体をアップグレードします。まず、構成データベース、SharePoint サーバーの全体管理、ファーム内の各サーバーに特有のデータをアップグレードし、次に、各仮想サーバー上のサイト コレクションを順にアップグレードしていきます。これで Version 2 の仮想サーバーが、順次 Version 3 の Web アプリケーションにアップグレードされ、同時に対応するサイト コレクションの基盤となるコンテンツ データベースも新しくなります。

ある機能をアップグレードするために必要なアクションは複数存在し得るので、これを実行時に検索してアップグレード シーケンスにまとめます。Windows SharePoint Services は、アップグレードするよう指定されたリソース インスタンスについて、どのアップグレード シーケンスを適用するか、設定ファイルで指定されたアセンブリを読み込んだ上で決定し、実際にその処理を行います。シーケンスの実行順序は、設定ファイルの記述に基づいて決まります。

Windows SharePoint Services のアップグレードはデータ中心の処理であるといえます。構成データベースでアップグレード可能と登録されたリソースのみを、所定の順序でアップグレードしていくのです。言い換えると、アップグレードが必要なリソース インスタンスは、構成データベースに登録しておく必要があることになります。これにより、アップグレード可能なリソース インスタンスごとに、他のインスタンスとは独立に、アップグレード シーケンスを 1 つだけ決定できるのです。ここでいうリソース インスタンスには、Web アプリケーション (仮想サーバー)、コンテンツ データベース、共有サービスなどがあります。アップグレード可能なオブジェクトにはスキーマのバージョン管理機能が組み込まれているため、アップグレードの依存関係を分析して処理できます。また、当該オブジェクトはアップグレードが必要か、実際にアップグレードするか、を判断するためのプロパティがあります。

アップグレード機構にはインターフェイス定義機能があって、特定のリソースをアップグレードするためのユーザー設定コードを組み込んで拡張できるようになっています。リソースの種類ごとにアップグレード シーケンス (あるいはプラグイン) を定義し、そのインターフェイスを実装しておけば、実際のアップグレード処理の際、このユーザー設定コードが呼び出されます。

アップグレード シーケンスは、同じサーバーに対して何回でも実行できます。アップグレード シーケンスには、あるアクションが所定の時間内に終了する必要があるかどうかを判断するしくみが必要です。また、エラーが発生したら、次のアップグレード処理を所定の状態から再開できるよう、いくつかチェック ポイントを設けておく必要があります。さらに、実行の過程をログとして出力し、エラーが発生した場合には報告し、進捗状況を画面に表示する機能も必要です。