JP2009230577A - ソフトウェアアップデート管理プログラム、ソフトウェアアップデート管理装置、およびソフトウェアアップデート管理方法 - Google Patents

Abstract

【課題】データの冗長性を維持したままディスクノードのソフトウェアをアップデートする場合におけるシステム全体の処理負荷の低下を抑制できるようにする。
【解決手段】移行パターン決定テーブル１ａｃには、対象ディスクノードで管理しているデータの更新を禁止することでデータの冗長性を維持する第１種移行パターンと、対象ディスクノードで管理しているデータを他のディスクノードにコピーすることでデータの冗長性を維持する第２種移行パターンとに分類された複数の移行パターンが設定されている。移行内容判断手段１ｂにより、対象ディスクノードの機能ごとの移行内容が判断され、移行パターン決定手段１ｃにより、移行内容に応じた移行パターンが決定される。そして、アップデート手段１ｄにより、対象ディスクノードのソフトウェアが、決定された移行パターンに示された処理でアップデートされる。
【選択図】図１

Description

本発明はソフトウェアアップデート管理プログラム、ソフトウェアアップデート管理装置、およびソフトウェアアップデート管理方法に関し、特に複数のディスクノードで冗長性を持たせたデータ管理を行う分散ストレージシステムにおけるディスクノードのソフトウェアアップデート手順を管理するためのソフトウェアアップデート管理プログラム、ソフトウェアアップデート管理装置、およびソフトウェアアップデート管理方法に関する。

分散ストレージシステムでは、複数のディスクノードに対して２重化させたデータが格納される。これにより、１台のディスクノードに障害が発生しても、システムの運用を継続することができる。

ただし、障害の発生によりディスクノードが停止した場合、そのディスクノードに格納されていたデータに対する更新が行われると２重化された一方のデータのみ更新され、停止したディスクノードが有するデータは更新できない。そこで、停止したディスクノードが復旧後に、そのディスクノードのデータを更新しデータの２重化状態（冗長構成）を回復させることとなる。ただし、このような場合、障害が発生したディスクノードが復旧するまでデータの冗長性が失われてしまう。

冗長構成を維持するには、障害により停止したディスクノードで管理されていたデータを、他のディスクノードにコピーする必要がある。コピー対象のデータは、停止したディスクノード内のデータと同じデータを管理する２重化相手のディスクノードから取得することができる。

なお、近年、ディスクノードで管理されるデータ量が大規模化している。そのため、１台のディスクノードが管理していたすべてのデータのコピーには長い時間を要する。すると、すべてのデータのコピーが完了する前に、停止していたディスクノードが復旧することもある。このような場合にまで、継続してすべてのデータのコピーを行うのは、非効率的である。そこで、復旧したディスクノードで管理していたデータのうち、障害による停止期間中に更新されていないデータについては、以後コピーを行わず、復旧したディスクノードで管理しているデータを有効にする技術が考えられている（例えば、特許文献１参照）。
特開２００５−３０１５９４号公報

ところで、ディスクノードは、ソフトウェアのアップデート時には、機能の少なくとも一部が停止する。このとき、ソフトウェアのアップデート開始後に障害発生時と同様の復旧処理を行うこともできるが、その場合、機能が停止してから復旧が完了するまでデータの冗長性が損なわれる。そこで、ソフトウェアをアップデートする場合、事前にアップデート対象のディスクノードで管理しているデータを、他のディスクノードにコピーしておく。これにより、一時的にデータは３重化される。その後、１台のストレージノードを停止させ、ソフトウェアのアップデートを行う。このようにして、データの冗長性を維持したままソフトウェアのアップデートが可能となる。

なお、ソフトウェアのアップデートに伴う機能停止時間は、アップデート対象のソフトウェア種別や、アップデートの内容によって異なる。例えば、オペレーティングシステム（ＯＳ）の入れ替えを行う場合、ＯＳや各種アプリケーションの再インストールに加え、各種環境設定を行う必要があり、作業に比較的長い時間を要する。一方、新バージョンのソフトウェアをインストールしておき、旧バージョンのソフトウェアの停止後に、新バージョンのソフトウェアを起動すればよい場合、短時間で作業が終了する。このようにアップデートの所要時間に長短があるにもかかわらず、従来は、アップデートの所要時間とは無関係に、３重化状態を経由することで、ソフトウェアアップデート時のデータの冗長性が維持されていた。

しかし、短時間で終了するソフトウェアのアップデートの場合にまでデータの３重化の処理を施すのは非効率的である。すなわち、データの３重化には、アップデート対象のディスクノードが管理するデータのすべてを他のディスクノードにコピーする必要がある。データのコピーを行う場合、コピー元のディスクノードでは大量のデータリードが発生し、処理負荷が増大すると共に、コピー先のディスクノードでは大量のデータライトが発生し、処理負荷が増大する。また、ネットワーク上には長い時間大量のデータ転送が発生し、ネットワークを介して転送されるデータ量が過大となり、データ転送効率が低下する。このようなシステムの処理負荷の増大は、外部からのディスクノードへのアクセス要求に対する応答遅延の原因となる。

本発明はこのような点に鑑みてなされたものであり、データの冗長性維持したままディスクノードのソフトウェアのアップデートする場合におけるシステム全体の処理能力の低下を抑制することができるソフトウェアアップデート管理プログラム、ソフトウェアアップデート管理装置、およびソフトウェアアップデート管理方法を提供することを目的とする。

上記課題を解決するために、複数のディスクノードで冗長性を持たせたデータ管理を行う分散ストレージシステムにおけるディスクノードのソフトウェアアップデート手順を管理するためのソフトウェアアップデート管理装置が提供される。このソフトウェアアップデート管理装置は、移行内容判断手段、移行パターン決定手段、およびアップデート手段を有する。

移行内容判断手段は、アップデート対象である対象ディスクノードのアップデート前のソフトウェアのソフトウェア名と版数とが対象ディスクノードの機能ごとに設定された移行前環境テーブルと、対象ディスクノードのアップデート後のソフトウェアのソフトウェア名と版数とが対象ディスクノードの機能ごとに設定された移行後環境テーブルとを記憶装置から読み出し、対象ディスクノードの機能ごとのアップデート前後におけるソフトウェア名と版数との推移を示す移行内容を判断する。移行パターン決定手段は、対象ディスクノードで管理しているデータの更新を禁止することでデータの冗長性を維持してソフトウェアアップデートを行う第１種移行パターンと、対象ディスクノードで管理しているデータを他のディスクノードにコピーすることでデータの冗長性を維持してソフトウェアのアップデートを行う第２種移行パターンとに分類される複数の移行パターンと、移行パターンを適用する移行内容との対応関係が設定された移行パターン決定テーブルを記憶装置から読み出し、移行内容判断手段により判断された移行内容と移行パターン決定テーブルとに基づいて、対象ディスクノードに適用する移行パターンを決定する。アップデート手段は、移行後環境テーブルを記憶装置から読み出し、移行パターン決定手段で決定された移行パターンに従って対象ディスクノードに対して指示を出し、対象ディスクノードの各機能を実行するソフトウェアを、移行後環境テーブルに設定されたソフトウェア名と版数とにアップデートする。

このようなソフトウェアアップデート管理装置によれば、移行内容判断手段により、対象ディスクノードの機能ごとの移行内容が判断される。次に、移行パターン決定手段により、対象ディスクノードに適用する移行パターンが決定される。そして、アップデート手段により、移行パターン決定手段で決定された移行パターンに従って対象ディスクノードに対して指示が出され、対象ディスクノードの各機能を実行するソフトウェアが、移行後環境テーブルに設定されたソフトウェア名と版数とにアップデートされる。

また、上記ソフトウェアアップデート管理装置と同様の機能をコンピュータに実行させるためのソフトウェアアップデート管理プログラムが提供される。さらに、上記ソフトウェアアップデート管理装置と同様の処理をコンピュータで実行するソフトウェアアップデート管理方法が提供される。

上記ソフトウェアアップデート管理装置では、少なくとも一部の移行内容のソフトウェアアップデートに対して第１種移行パターンを適用することで、システム全体の処理負荷の増加を低く抑えながら、データの冗長性を維持したままディスクノードのソフトウェアのアップデートが可能となる。

以下、本発明の実施の形態を図面を参照して説明する。
図１は、実施の形態の概要を示す図である。ソフトウェアアップデート管理装置１は、複数のディスクノード２，３，４，・・・で冗長性を持たせたデータ管理を行う分散ストレージシステムにおけるディスクノードのソフトウェアアップデート手順を管理する。ソフトウェアアップデート管理装置１は、オペレーティングシステムやアプリケーションソフトウェアのレベルアップやパッチ適用などのアップデートを実施するにあたって、データの完全２重化が損なわれることを防止するための機能を備えている。すなわち、ソフトウェアアップデート管理装置１は、記憶装置１ａ、移行内容判断手段１ｂ、移行パターン決定手段１ｃ、およびアップデート手段１ｄを有する。なお、図１の例では、記憶装置１ａは、ソフトウェアアップデート管理装置１に内蔵されているが、ソフトウェアアップデート管理装置１にネットワークで接続された他のコンピュータが記憶装置１ａを有していてもよい。

記憶装置１ａには、移行前環境テーブル１ａａ、移行後環境テーブル１ａｂ、移行パターン決定テーブル１ａｃが格納されている。移行前環境テーブル１ａａには、アップデート対象である対象ディスクノードのアップデート前のソフトウェアのソフトウェア名と版数とが対象ディスクノードの機能ごとに設定されている。移行後環境テーブル１ａｂには、対象ディスクノードのアップデート後のソフトウェアのソフトウェア名と版数とが対象ディスクノードの機能ごとに設定されている。

移行パターン決定テーブル１ａｃには、複数の移行パターンと、移行パターンを適用する移行内容との対応関係が設定されている。複数の移行パターンは、対象ディスクノードで管理しているデータの更新を禁止することでデータの冗長性を維持してソフトウェアアップデートを行う第１種移行パターンと、対象ディスクノードで管理しているデータを他のディスクノードにコピーすることでデータの冗長性を維持してソフトウェアのアップデートを行う第２種移行パターンとに分類される。例えば、移行パターン決定テーブル１ａｃには、ソフトウェアのアップデートに要する時間が所定時間以下の移行内容に対して、第１種移行パターンに属する移行パターンを適用することが設定されており、ソフトウェアのアップデートに要する時間が所定時間を超える移行内容に対して、第２種移行パターンに属する移行パターンを適用することが設定されている。

なお、図１の例では、１つの記憶装置１ａに移行前環境テーブル１ａａ、移行後環境テーブル１ａｂ、移行パターン決定テーブル１ａｃが格納されているが、移行前環境テーブル１ａａ、移行後環境テーブル１ａｂ、移行パターン決定テーブル１ａｃそれぞれが個別の記憶装置に格納されていてもよい。

移行内容判断手段１ｂは、移行前環境テーブル１ａａと移行後環境テーブル１ａｂとを記憶装置１ａから読み出し、対象ディスクノードの機能ごとのアップデート前後におけるソフトウェア名と版数との推移を示す移行内容を判断する。

移行パターン決定手段１ｃは、移行パターン決定テーブル１ａｃを記憶装置１ａから読み出し、移行内容判断手段１ｂにより判断された移行内容と移行パターン決定テーブル１ａｃとに基づいて、対象ディスクノードに適用する移行パターンを決定する。

アップデート手段１ｄは、移行後環境テーブル１ａｂを記憶装置から読み出し、移行パターン決定手段１ｃで決定された移行パターンに従って対象ディスクノード２に対して指示を出し、対象ディスクノード２の各機能を実行するソフトウェアを、移行後環境テーブル１ａｂに設定されたソフトウェア名と版数とにアップデートする。

このようなソフトウェアアップデート管理装置によれば、移行内容判断手段１ｂにより、対象ディスクノードの機能ごとの移行内容が判断される。次に、移行パターン決定手段１ｃにより、対象ディスクノードに適用する移行パターンが決定される。そして、アップデート手段１ｄにより、移行パターン決定手段１ｃで決定された移行パターンに従って対象ディスクノードに対して指示が出され、対象ディスクノードの各機能を実行するソフトウェアが、移行後環境テーブル１ａｂに設定されたソフトウェア名と版数とにアップデートされる。

このように、移行パターン決定テーブル１ａｃの内容に応じて移行パターンが決定されることで、移行内容に応じた適切な移行パターンを適用することができる。すなわち、移行パターン決定テーブル１ａｃにおいて、短時間でアップデート可能な移行内容に対しては、第１種移行パターンを適用するように対応関係を設定しておき、アップデートに長時間を要する移行内容に対しては、第２種移行パターンを適用するように対応関係を設定しておく。これにより、短時間でアップデート可能な移行内容の場合、対象ディスクノードで管理しているデータの更新を禁止することでデータの冗長性を維持してソフトウェアアップデートが行われる。この場合、書き込みを禁止するだけでデータの冗長性を維持するため、ソフトウェアアップデートによるシステム全体に与える処理負荷が少なくて済む。

また、アップデートに長時間を要する意向内容の場合、対象ディスクノードで管理しているデータを他のディスクノードにコピーすることでデータの冗長性を維持してソフトウェアのアップデートが行われる。これにより、対象ディスクノードの機能が停止しても、データの冗長性が維持される。

このように、短時間でアップデート可能な場合には、一時的にデータの書き込みを禁止するだけで、ディスクノードのデータのコピーを行わない。その結果、冗長性を維持しつつ、効率的なソフトウェアのアップデートが可能となる。

ところで、複数のディスクノードにデータを格納する分散ストレージシステムでは、全体の運用を管理するための管理ノードが設けられる。この管理ノードに、図１に示したソフトウェアアップデート管理装置１の機能を組み込むことができる。そこで、管理ノードによってソフトウェアアップデート管理を行う分散ストレージシステムの例を用いて、本実施の形態の詳細を説明する。

図２は、本実施の形態の分散ストレージシステム構成例を示す図である。本実施の形態では、ネットワーク１０を介して、複数のディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０、制御ノード５００、アクセスノード６００，７００、および管理ノード８００が接続されている。ディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０それぞれには、ストレージ装置１１１，１２１，１３１，２１１，２２１，２３１，３１１，３２１，３３１が接続されている。

各ストレージ装置１１１，１２１，１３１，２１１，２２１，２３１，３１１，３２１，３３１には、複数のハードディスク装置（ＨＤＤ）が実装されている。各ストレージ装置１１１，１２１，１３１，２１１，２２１，２３１，３１１，３２１，３３１は、内蔵するＨＤＤを用いたＲＡＩＤシステムである。

ディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０は、例えば、ＩＡ（Intel Architecture）と呼ばれるアーキテクチャのコンピュータである。ディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０は、接続されたストレージ装置１１１，１２１，１３１，２１１，２２１，２３１，３１１，３２１，３３１に格納されたデータを管理し、管理しているデータをネットワーク１０経由で端末装置２１，２２，２３に提供する。また、ディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０は、冗長性を有するデータを管理している。すなわち、同一のデータが、少なくとも２つのディスクノードで管理されている。

制御ノード５００は、ディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０を管理する。例えば、制御ノード５００は、管理ノード８００から新たなリモート論理ボリュームの割当要求を受け取ると、新たなリモート論理ボリュームを定義し、その定義内容をディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０やアクセスノード６００，７００に通知する。これにより、アクセスノード６００，７００から、新たに定義したリモート論理ボリュームを介したディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０へのアクセスが可能となる。

アクセスノード６００，７００には、ネットワーク２０を介して複数の端末装置２１，２２，２３が接続されている。アクセスノード６００，７００には、ローカル論理ボリュームとリモート論理ボリュームが定義されている。そして、アクセスノード６００，７００は、端末装置２１，２２，２３からのローカル論理ボリューム上でのデータのアクセス要求に応答して、リモート論理ボリュームによって定義されたディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０で管理されているデータへアクセスする。

管理ノード８００は、管理者が分散ストレージシステムの運用を管理するために使用するコンピュータである。管理ノード８００では、ディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０のソフトウェアの種別や版数を管理している。そして、管理ノード８００は、ディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０に実装されているソフトウェアのアップデートを管理する。

なお、本実施の形態では、各ディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０が複数のクラスタグループに分類されている。図２の例では、ディスクノード１１０，１２０，１３０で１つのクラスタグループが構成され、クラスタグループの識別子「クラスタＮｏ．１」が割り当てられている。また、ディスクノード２１０，２２０，２３０で１つのクラスタグループが構成され、クラスタグループの識別子「クラスタＮｏ．２」が割り当てられている。同様に、ディスクノード３１０，３２０，３３０で１つのクラスタグループが構成され、クラスタグループの識別子「クラスタＮｏ．３」が割り当てられている。

図３は、本実施の形態に用いる管理ノードのハードウェア構成例を示す図である。管理ノード８００は、ＣＰＵ（Central Processing Unit）８０１によって装置全体が制御されている。ＣＰＵ８０１には、バス８０７を介してＲＡＭ（Random Access Memory）８０２、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）８０３、グラフィック処理装置８０４、入力インタフェース８０５、および通信インタフェース８０６が接続されている。

ＲＡＭ８０２は、管理ノード８００の主記憶装置として使用される。ＲＡＭ８０２には、ＣＰＵ８０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ８０２には、ＣＰＵ８０１による処理に必要な各種データが格納される。ＨＤＤ８０３は、管理ノード８００の二次記憶装置として使用される。ＨＤＤ８０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、二次記憶装置としては、フラッシュメモリなどの半導体記憶装置を使用することもできる。

グラフィック処理装置８０４には、モニタ１１が接続されている。グラフィック処理装置８０４は、ＣＰＵ８０１からの命令に従って、画像をモニタ１１の画面に表示させる。モニタ１１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置がある。

入力インタフェース８０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース８０５は、キーボード１２やマウス１３から送られてくる信号を、バス８０７を介してＣＰＵ８０１に送信する。なお、マウス１３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

通信インタフェース８０６は、ネットワーク１０に接続されている。通信インタフェース８０６は、ネットワーク１０を介して、他のノードとの間でデータの送受信を行う。
なお、図３では管理ノード８００のハードウェア構成を示したが、ディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０、制御ノード５００、アクセスノード６００，７００も同様のハードウェア構成で実現することができる。

以上のようなハードウェア構成によって、分散ストレージシステムを実現することができる。分散ストレージシステムでは、端末装置２１〜２３に対して、仮想的なボリューム（以下、論理ボリュームと呼ぶ）として機能する。論理ボリュームは、クラスタグループごとに作成される。

図４は、論理ボリュームのデータ構造を示す図である。図４には、「クラスタＮｏ．１」のクラスタグループに構成された論理ボリューム９００を示している。論理ボリューム９００には、「ＬＶＯＬ−Ａ」という識別子（論理ボリューム識別子）が付与されている。また、ネットワーク経由で接続された３台のディスクノード１１０，１２０，１３０には、個々のディスクノードの識別のためにそれぞれ「ＳＮ−Ａ」、「ＳＮ−Ｂ」、「ＳＮ−Ｃ」というノード識別子が付与されている。

各ディスクノード１１０，１２０，１３０が有するストレージ装置１１１，１２１，１３１それぞれにおいてＲＡＩＤ５の論理ディスクが構成されている。この論理ディスクは５つのスライスに分割され個々のディスクノード内で管理されている。

図４の例では、ストレージ装置１１１が有する記憶領域は、５つのスライス１１１ａ，１１１ｂ，１１１ｃ，１１１ｄ，１１１ｅに分けられている。ストレージ装置１２１が有する記憶領域は、５つのスライス１２１ａ，１２１ｂ，１２１ｃ，１２１ｄ，１２１ｅに分けられている。ストレージ装置１３１が有する記憶領域は、５つのスライス１３１ａ，１３１ｂ，１３１ｃ，１３１ｄ，１３１ｅに分けられている。

なお、論理ボリューム９００は、セグメント９１０，９２０，９３０，９４０という単位で構成される。セグメント９１０，９２０，９３０，９４０の記憶容量は、ストレージ装置１１１，１２１，１３１における管理単位であるスライスの記憶容量と同じである。例えば、スライスの記憶容量が１ギガバイトとするとセグメントの記憶容量も１ギガバイトである。論理ボリューム９００の記憶容量はセグメント１つ当たりの記憶容量の整数倍である。例えば、セグメントの記憶容量が１ギガバイトならば、論理ボリューム９００の記憶容量は４ギガバイトといったものになる。

セグメント９１０，９２０，９３０，９４０は、それぞれプライマリスライス９１１，９２１，９３１，９４１とセカンダリスライス９１２，９２２，９３２，９４２との組から構成される。同じセグメントに属するスライスは別々のディスクノードに属する。各スライスは、スライス管理情報によって管理される。スライス管理情報には、論理ボリューム識別子、セグメント情報、同じセグメントを構成するスライス情報、プライマリスライスかセカンダリスライスかを示すフラグなどが含まれる。

図４の例では、スライスの属性を識別するための識別子を、「Ｐ」または「Ｓ」のアルファベットと数字との組合せで示している。「Ｐ」はプライマリスライスであることを示している。「Ｓ」はセカンダリスライスであることを示している。アルファベットに続く数字は、何番目のセグメントに属するのかを表している。例えば、１番目のセグメント９１０のプライマリスライスが「Ｐ１」で示され、セカンダリスライスが「Ｓ１」で示される。

このような構造の論理ボリューム９００の各プライマリスライスおよびセカンダリスライスが、ストレージ装置１１１，１２１，１３１内のいずれかのスライスに対応付けられる。例えば、セグメント９１０のプライマリスライス９１１は、ストレージ装置１１１のスライス１１１ｂに対応付けられ、セカンダリスライス９１２は、ストレージ装置１２１のスライス１２１ｂに対応付けられている。

そして、各ストレージ装置１１１，１２１，１３１では、自己のスライスに対応するプライマリスライスまたはセカンダリスライスのデータを記憶する。
図５は、分散ストレージシステムの各装置の機能を示すブロック図である。アクセスノード６００は、論理ボリュームアクセス制御部６１０を有している。論理ボリュームアクセス制御部６１０は、端末装置２１，２２，２３からの論理ボリューム９００内のデータを指定したアクセス要求に応じて、指定されたデータを管理するディスクノードに対してデータアクセスを行う。具体的には、論理ボリュームアクセス制御部６１０は、アクセス対象のデータが記憶された論理ボリューム９００内のセグメントを特定する。次に、論理ボリュームアクセス制御部６１０は、特定した論理ボリューム９００のセグメントを構成するプライマリスライスに対応するディスクノードおよびそのディスクノード内のスライスを特定する。そして、論理ボリュームアクセス制御部６１０は、特定したディスクノードに対して、特定したスライスへのアクセス要求を出力する。

また、論理ボリュームアクセス制御部６１０は、ディスクノード１１０，１２０，１３０，・・・にアクセスするためのデータキャッシュ（アクセス対象のデータを一時的に記憶する記憶領域）を有している。リードキャッシュには、最近読み出したデータが格納される。論理ボリュームアクセス制御部６１０は、リードキャッシュに格納されたデータに対するリード要求であれば、該当データを管理しているディスクノードがアップデート中であっても、そのデータをリードキャッシュから取得できる。

アクセスノード７００も論理ボリュームアクセス制御部７１０を有している。論理ボリュームアクセス制御部７１０の機能は、アクセスノード６００の論理ボリュームアクセス制御部６１０と同様である。

制御ノード５００は、論理ボリューム管理部５１０とスライス管理情報群記憶部５２０とを有している。
論理ボリューム管理部５１０は、ディスクノード１１０，１２０，１３０，・・・が有するストレージ装置１１１，１２１，１３１，・・・内のスライスを管理する。例えば、論理ボリューム管理部５１０は、システム起動時に、ディスクノード１１０，１２０，１３０，・・・に対してスライス管理情報取得要求を送信する。そして、論理ボリューム管理部５１０は、スライス管理情報取得要求に対して返信されたスライス管理情報を、スライス管理情報群記憶部５２０に格納する。

スライス管理情報群記憶部５２０は、ディスクノード１１０，１２０，１３０，・・・から収集されたスライス管理情報を記憶する記憶装置である。例えば、制御ノード５００内のＲＡＭの記憶領域の一部がスライス管理情報群記憶部５２０として使用される。

ディスクノード１１０は、データアクセス部１１２、データ管理部１１３、およびスライス管理情報記憶部１１４を有している。
データアクセス部１１２は、アクセスノード６００からの要求に応答して、ストレージ装置１１１内のデータにアクセスする。具体的には、データアクセス部１１２は、アクセスノード６００からデータのリード要求を受け取った場合、リード要求で指定されたデータをストレージ装置１１１から取得し、アクセスノード６００に送信する。また、データアクセス部１１２は、アクセスノード６００からデータのライト要求を受け取った場合、ライト要求に含まれるデータをストレージ装置１１１内に格納する。なお、ディスクノード１１０のデータ管理部１１３は、データアクセス部１１２によってライト要求に基づくデータの書き込みが行われた場合、データが書き込まれたスライス（プライマリスライス）に対応するセカンダリスライスを管理するディスクノードのデータ管理部と連携動作し、セカンダリスライス内のデータも更新する。

さらに、データ管理部１１３は、論理ボリューム管理部５１０からのスライス管理情報取得要求に応答して、スライス管理情報記憶部１１４に記憶されたスライス管理情報を論理ボリューム管理部５１０に対して送信する。

スライス管理情報記憶部１１４は、スライス管理情報を記憶する記憶装置である。例えば、ＲＡＭ内の記憶領域の一部がスライス管理情報記憶部１１４として使用される。なお、スライス管理情報記憶部１１４に格納されるスライス管理情報は、システム停止時にはストレージ装置１１１内に格納され、システム起動時にスライス管理情報記憶部１１４に読み込まれる。

他のディスクノード１２０，１３０，・・・は、ディスクノード１１０と同様の機能を有している。すなわち、ディスクノード１２０は、データアクセス部１２２、データ管理部１２３、およびスライス管理情報記憶部１２４を有している。ディスクノード１３０は、データアクセス部１３２、データ管理部１３３、およびスライス管理情報記憶部１３４を有している。ディスクノード１２０，１３０，・・・内の各要素は、ディスクノード１１０内の同名の要素と同じ機能を有している。

管理ノード８００は、複写元プログラム記憶部８１０とアップデート管理部８２０とを有している。複写元プログラム記憶部８１０は、ソフトウェアアップデート用の複写元のプログラムを記憶する記憶機能である。例えば、ＨＤＤ８０３の記憶領域の一部が、複写元プログラム記憶部８１０として使用される。アップデート管理部８２０は、各ディスクノード１１０，１２０，１３０，・・・に実装されているソフトウェアの版数を管理している。そして、アップデート管理部８２０は、ソフトウェアをアップデートする際に、アップデートの所要時間に応じた手順でディスクノード１１０，１２０，１３０，・・・のソフトウェアをアップデートする。なお、図５では、関係線が複雑に交錯するのを避けるために、管理ノード８００と各ディスクノード１１０，１２０，１３０，・・・とを接続する関係線は省略されている。

次に、分散ストレージシステムにおいて論理ボリュームを管理するために必要な情報について説明する。
図６は、ディスクノード内のスライス管理情報のデータ構造例を示す図である。スライス管理情報記憶部１１４には、スライス管理情報１１４ａが格納されている。

スライス管理情報１１４ａは、ストレージ装置１１１内のスライス単位に分割された格納領域に格納されたデータの管理情報が登録されたデータテーブルである。スライス管理情報１１４ａには、ディスクノードＩＤ、スライスＩＤ、フラグ、論理ボリュームＩＤ、セグメントＩＤ、ペアのディスクノードＩＤ、およびペアのスライスＩＤの欄が設けられている。

ディスクノードＩＤの欄には、スライス管理情報１１４ａを有しているディスクノード１１０のノード識別子が登録される。スライスＩＤの欄には、ストレージ装置１１１内の各スライスを一意に識別するためのスライス番号が設定される。フラグの欄には、スライスＩＤで示されるスライスに対応するリモート論理ボリューム内のスライスが、プライマリスライスかセカンダリスライスを示すフラグが設定される。図６の例では、プライマリスライスを「Ｐ」、セカンダリスライスを「Ｓ」で表している。

論理ボリュームＩＤの欄には、スライスＩＤで示されるスライスに対応するリモート論理ボリュームを示す論理ボリューム識別子が設定される。セグメントＩＤの欄には、スライスＩＤで示されるスライスに対応するリモート論理ボリューム内のセグメントを示すセグメント番号が設定される。

ペアのディスクノードＩＤの欄には、スライスＩＤで示されるスライスとペアとなるスライス（同一セグメントを構成するスライス）を格納するディスクノードのノード識別子が設定される。ペアのスライスＩＤの欄には、スライスＩＤで示されるスライスとペアとなるスライスをディスクノード内で一意に識別するためのスライス番号が設定される。

このようなスライス管理情報が、各ディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０に格納されており、システム起動時に制御ノード５００に送信される。制御ノード５００では、各ディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０から取得したスライス管理情報をスライス管理情報群記憶部５２０に格納する。

図７は、スライス管理情報群記憶部のデータ構造例を示す図である。スライス管理情報群記憶部５２０には、ディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０それぞれから収集したスライス管理情報５２１，５２２，５２３，・・・が格納されている。各スライス管理情報５２１，５２２，５２３，・・・のデータ構造は、図６に示したとおりである。

このようなスライス管理情報群記憶部５２０に記憶されたスライス管理情報５２１，５２２，５２３，・・・のうち、プライマリスライスに関する情報（フラグの欄に「Ｐ」と設定されている情報）が、制御ノード５００からアクセスノード６００，７００に渡される。その結果、アクセスノード６００，７００において、論理ボリュームを構成する各セグメントのプライマリスライスに割り当てられたディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０のスライスを認識できる。

次に、管理ノード８００が有する機能について詳細に説明する。
図８は、複写元プログラム記憶部のデータ構造例を示す図である。複写元プログラム記憶部８１０には、ディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０に導入されるソフトウェアのプログラム８１１〜８１６が格納されている。図８の例では、クラスタ制御ソフトウェアの版数ごとのプログラム８１１〜８１３と、オペレーティングシステムのプログラム８１４〜８１６が格納されている。プログラム８１１は、「アプリＡ」というソフトウェアの版数「Ｖ２．０」のプログラムである。プログラム８１２は、「アプリＡ」というソフトウェアの版数「Ｖ２．１」のプログラムである。プログラム８１３は、「アプリＡ」というソフトウェアの版数「Ｖ２．２」のプログラムである。プログラム８１４は、「ＯＳα」というソフトウェアの版数「Ｖ９．０」のプログラムである。プログラム８１５は、「ＯＳβ」というソフトウェアの版数「Ｖ４．２」のプログラムである。プログラム８１６は、「ＯＳβ」というソフトウェアの版数「Ｖ４．４」のプログラムである。

このような複写元プログラム記憶部８１０に格納されたプログラム８１１〜８１６を用いて、アップデート管理部８２０による管理下で、ディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０のソフトウェアのアップデートが行われる。

次に、ソフトウェアのアップデート機能について説明する。
図９は、ソフトウェアのアップデート機能を示すブロック図である。アップデート管理部８２０は、移行前環境テーブル８２１、移行パターン決定テーブル８２２、所要時間テーブル８２３、メッセージ管理テーブル８２４、移行条件入力テーブル８２５、移行後環境テーブル生成部８２６、移行パターンテーブル生成部８２７、およびアップデート部８２８を有している。

移行前環境テーブル８２１は、各ディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０に実装されているソフトウェア資源の情報が登録されたデータテーブルである。移行前環境テーブル８２１はＨＤＤ８０３に予め格納されており、アップデート管理部８２０の起動後、ＲＡＭ８０２に読み込まれる。

移行パターン決定テーブル８２２は、ソフトウェアのアップデート内容に応じた移行パターンが登録されたデータテーブルである。移行パターンは、ソフトウェアのアップデート時に実行すべき処理の組合せパターンである。移行パターン決定テーブル８２２はＨＤＤ８０３に予め格納されており、アップデート管理部８２０の起動後、ＲＡＭ８０２に読み込まれる。

所要時間テーブル８２３は、移行パターンごとの所要時間が登録されたデータテーブルである。所要時間テーブル８２３はＨＤＤ８０３に予め格納されており、アップデート管理部８２０の起動後、ＲＡＭ８０２に読み込まれる。

メッセージ管理テーブル８２４は、ソフトウェアのアップデート時に利用者が使用する端末装置２１，２２，２３に表示するメッセージが登録されたデータテーブルである。登録されたメッセージは、アップデート処理に伴う注意を促す内容を示す文字列である。メッセージ管理テーブル８２４はＨＤＤ８０３に予め格納されており、アップデート管理部８２０の起動後、ＲＡＭ８０２に読み込まれる。

移行条件入力テーブル８２５は、ソフトウェアのアップデートを実行する際に、アップデート後のソフトウェア環境（移行条件）をクラスタグループごとに設定するためのデータテーブルである。移行条件入力テーブル８２５は、予めテンプレートとしてのデータ構造がＨＤＤ８０３に用意されている。そして、ソフトウェアのアップデートを行う場合、管理者からの操作入力に応じてテンプレートがＲＡＭ８０２に読み込まれ、エディタなどの編集機能によってアップデート後のソフトウェア環境が設定される。

移行後環境テーブル生成部８２６は、移行条件入力テーブル８２５に移行条件が設定されると、移行前環境テーブル８２１を参照し、移行後環境テーブル８２６ａを生成する。移行後環境テーブル８２６ａは、ソフトウェアアップデート後の各クラスタグループ内のディスクノードのソフトウェア環境が設定されたデータテーブルである。作成された移行後環境テーブル８２６ａは、ＲＡＭ８０２に格納される。

移行パターンテーブル生成部８２７は、移行後環境テーブル８２６ａが作成されると、移行前環境テーブル８２１と移行後環境テーブル８２６ａとに基づいて、移行内容を判断する。次に、移行パターンテーブル生成部８２７は、移行パターン決定テーブル８２２を参照し、移行内容に応じた移行パターンを決定する。そして、移行パターンテーブル生成部８２７は、移行パターンテーブル８２７ａを生成する。移行パターンテーブル８２７ａは、クラスタグループごとの移行パターンを登録したデータテーブルである。移行作成された移行パターンテーブル８２７ａは、ＲＡＭ８０２に格納される。なお、図１に示した移行内容判断手段１ｂと移行パターン決定手段１ｃとの機能は、移行パターンテーブル生成部８２７に含まれる。

アップデート部８２８には、各ディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０がどのクラスタグループに属するのかを示すグループ情報が予め登録されている。例えば、ＨＤＤ８０３内にグループ情報が予め格納されており、アップデート部８２８が処理を実行する際にそのグループ情報がＲＡＭ８０２に読み込まれる。そして、アップデート部８２８は、生成された移行パターンテーブル８２７ａに設定されたクラスタグループごとの移行パターンに従って、各ディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０に対するソフトウェアのアップデート指示を行う。なお、アップデート部８２８は、ソフトウェアのアップデート中に利用者の端末装置２１，２２，２３にメッセージを表示する場合、メッセージ管理テーブル８２４からメッセージの文字列を取得し、端末装置２１，２２，２３にメッセージを送信する。なお、図１に示したアップデート手段１ｄの機能は、アップデート部８２８に含まれる。

ディスクノード１１０は、更新エージェント１１６を有している。更新エージェント１１６は、管理ノード８００のアップデート部８２８からの指示に従って、クラスタ制御ソフトウェア１１０ａやＯＳ１１５のプログラムをアップデートする。なお、クラスタ制御ソフトウェア１１０ａには、データアクセス部１１２、データ管理部１１３、およびスライス管理情報記憶部１１４が含まれる。なお、更新エージェント１１６は、定期的に管理ノード８００の複写元プログラム記憶部８１０を参照する。更新エージェント１１６は、複写元プログラム記憶部８１０内に新しいプログラムを検出すると、管理ノード８００からダウンロードしてＨＤＤに格納しておく。そして、更新エージェント１１６は、アップデート部８２８からの指示に従って、ダウンロードしておいたプログラムによるアップデート処理を行う。

なお、更新エージェント１１６は、ＯＳのプログラムをダウンロードした場合、現在運用しているＯＳが導入されているパーティションとは別のパーティションに対して、ダウンロードしたプログラムを用いてＯＳを導入しておく。そして、更新エージェント１１６は、アップデート部８２８からの指示に従って、新たにＯＳを導入したパーティションからＯＳを起動する。これにより、ＯＳを移行することができる。

次に、アップデート管理部８２０が予め有しているデータテーブルの内容について説明する。
図１０は、移行前環境テーブルのデータ構造例を示す図である。移行前環境テーブル８２１には、クラスタＮｏ．とアップデート前の環境との欄が設けられている。

クラスタＮｏ．の欄には、クラスタグループの識別子が設定される。アップデート前の環境の欄には、対応するクラスタグループ内のディスクノードで動作しているソフトウェア資源が設定されている。

アップデート前の環境の欄は、クラスタ制御ソフトウェアとＯＳとの欄に分けられている。クラスタ制御ソフトウェアの欄には、さらにソフトウェア名と版数との欄が設けられており、それぞれの欄にディスクノードに実装されているクラスタ制御ソフトウェアの名称と版数とが設定される。ＯＳの欄には、さらにソフトウェア名と版数との欄が設けられており、それぞれの欄にディスクノードに実装されているＯＳの名称と版数とが設定される。

図１１は、移行パターン決定テーブルのデータ構造例を示す図である。移行パターン決定テーブル８２２には、移行パターン、クラスタ制御ソフトウェア、およびＯＳの欄が設けられている。移行パターンの欄には、移行パターンの識別子が設定される。

クラスタ制御ソフトウェアの欄には、移行前のクラスタ制御ソフトウェアと移行後のクラスタ制御ソフトウェアとの組合せパターンが設定される。具体的には、クラスタ制御ソフトウェアの欄は、移行前と移行後との欄に分けられている。移行前と移行後との欄には、それぞれソフトウェア名と版数との欄が設けられている。移行前の欄には、クラスタ制御ソフトウェアアップデート前のソフトウェア名と版数とが設定される。移行後の欄には、クラスタ制御ソフトウェアアップデート後のソフトウェア名と版数とが設定される。

クラスタ制御ソフトウェアの欄には、移行前のクラスタ制御ソフトウェアと移行後のクラスタ制御ソフトウェアとの組合せパターンが設定される。具体的には、クラスタ制御ソフトウェアの欄は、移行前と移行後との欄に分けられている。移行前と移行後との欄には、それぞれソフトウェア名と版数との欄が設けられている。移行前の欄には、クラスタ制御ソフトウェアアップデート前のソフトウェア名と版数とが設定される。移行後の欄には、クラスタ制御ソフトウェアアップデート後のソフトウェア名と版数とが設定される。

ＯＳの欄には、移行前のＯＳと移行後のＯＳとの組合せパターンが設定される。具体的には、ＯＳの欄は、移行前と移行後との欄に分けられている。移行前と移行後との欄には、それぞれソフトウェア名と版数との欄が設けられている。移行前の欄には、ＯＳアップデート前のソフトウェア名と版数とが設定される。移行後の欄には、ＯＳアップデート後のソフトウェア名と版数とが設定される。

クラスタ制御ソフトウェアの欄とＯＳの欄とに設定された移行前後のソフトウェア組合せパターンに示された移行内容（移行前後の環境変化）に合致するソフトウェアアップデートを行う場合、その移行内容に対応付けられた移行パターンが適用される。

図１１の例では、３種類の移行パターンが定義されている。「ＰＴ１」は、クラスタ制御ソフトウェアの再起動のみでアップデートが完了する場合である。すなわち、ＯＳがアップデート後のクラスタ制御ソフトウェアに対応していれば、「アプリＡ」の版数「Ｖ２．２」のプログラムをディスクノードにコピーしておき、「Ｖ２．１」のプログラム停止後に、直ちに「Ｖ２．２」のプログラムを起動することでアップデートが実施できる。

「ＰＴ２」は、ＯＳのバージョンアップを伴う場合である。この場合、別パーティションに新しいＯＳを導入しておき、新しいＯＳによる再起動を行うこととなる。
「ＰＴ３」は、異なる種類のＯＳへの入れ替えを伴う場合である。異なるＯＳを用いてアップデート前と同様の機能を構築するには、アップデート対象のディスクノードをシステムから切り離す必要がある。そこで、「ＰＴ３」では、データの３重化後にディスクノードを切り離し、ＯＳ後にＯＳの入れ換えが行われる。

図１２は、所要時間テーブルのデータ構造例を示す図である。所要時間テーブル８２３には、移行パターン、移行時処理内容、および所要時間の欄が設けられている。
移行パターンの欄には、移行パターンの識別子が設定される。移行処理内容の欄には、移行パターンごとのソフトウェアアップデート時の処理内容が設定される。所要時間の欄には、移行パターンに対応する処理内容の実行に要する時間の概算値が設定される。

図１２の例では、移行パターン「ＰＴ１」の場合、移行時の処理内容として、クラスタ制御ソフトウェアの停止処理、書き込み禁止処理、および事前復旧処理が行われ、所要時間は３秒である。移行パターン「ＰＴ２」の場合、移行時の処理内容として、ＯＳのリブート処理、書き込み禁止処理、および事前復旧処理が行われ、所要時間は６分である。移行パターン「ＰＴ３」の場合、移行時の処理内容として、３重化処理、ディスクノードの分散ストレージシステムからの切り離し処理、およびプログラムの入れ替え処理が行われ、所要時間は１時間である。

ここで、書き込み禁止処理は、ソフトウェアアップデート対象のディスクノードへのデータの書き込みを禁止する処理である。事前復旧処理は、障害発生時と同様の復旧処理である。ソフトウェアアップデート時の事前復旧処理では、クラスタ制御ソフトウェアがアップデート後に正常に起動できない場合を見越して障害発生前から障害復旧を開始する。アップデート後のクラスタ制御ソフトウェアが正常に起動された場合には、障害復旧処理は中止される。

３重化処理は、アップデート対象のディスクノードで管理されている全データを他のディスクノードにコピーし、一時的にデータの３重化状態を作り出す処理である。３重化処理後に対象のディスクノードを分散ストレージシステムから切り離すと、切り離されたディスクノードに格納されていたデータは、２重化状態に戻ることとなる。

ディスクノードの分散ストレージシステムからの切り離し処理は、該当するディスクノードが管理するスライスの論理ボリュームへの割当を解除する処理である。割当を解除することで、アクセスノード６００，７００からディスクノードへのアクセスがなくなる。

なお、移行パターン「ＰＴ１」、「ＰＴ２」は、書き込み禁止処理によってデータの冗長性を維持しており、図１で説明した第一種移行パターンに属する移行パターンである。また、移行パターン「ＰＴ３」は、３重化処理によってデータの冗長性を維持しており、図１で説明した第２種移行パターンに属する移行パターンである。

図１３は、メッセージ管理テーブルのデータ構造例を示す図である。メッセージ管理テーブル８２４には、メッセージＮｏ．、移行パターン、およびメッセージの欄が設けられている。メッセージＮｏ．の欄には、メッセージの識別番号が設定される。移行パターンの欄には、対応するメッセージを適用する移行パターンが設定される。メッセージの欄には、端末装置２１，２２，２３に送信するメッセージの内容を示す文字列が設定される。

以上のようなデータが予め登録された状態で、システムの管理者の管理ノード８００への操作入力に基づいて、ディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０のソフトウェアのアップデート処理が実行される。管理者は、まず管理ノード８００の移行条件入力テーブル８２５に対して、クライアントグループごとの移行条件を入力する。

図１４は、移行条件入力テーブルのデータ構造例を示す図である。移行条件入力テーブル８２５には、クラスタＮｏ．、クラスタ制御ソフトウェア、およびＯＳの欄が設けられている。

クラスタＮｏ．の欄には、クラスタグループの識別子が設定される。クラスタ制御ソフトウェアの欄には、ソフトウェア名と版数との欄が設けられており、それぞれにディスクノードに導入すべきクラスタ制御ソフトウェアのソフトウェア名と版数とが設定される。ＯＳの欄には、ソフトウェア名と版数との欄が設けられており、それぞれにディスクノードに導入すべきＯＳのソフトウェア名と版数とが設定される。

このような移行条件入力テーブル８２５に対して管理者が移行条件を入力し、移行指示を管理ノード８００に入力すると、アップデート管理部８２０によってソフトウェアの移行処理が開始される。

図１５は、ソフトウェア移行処理の手順を示すフローチャートである。以下、図１５に示す処理をステップ番号に沿って説明する。
［ステップＳ１１］移行後環境テーブル生成部８２６は、移行条件入力テーブル８２５で指定された移行条件に従って移行した場合の各ディスクノードの移行後の環境を示す移行後環境テーブル８２６ａを生成する。この処理の詳細は後述する（図１６参照）。

［ステップＳ１２］移行パターンテーブル生成部８２７は、移行後環境テーブル生成部８２６で生成された移行後環境テーブル８２６ａに応じた移行パターンテーブル８２７ａを生成する。この処理の詳細は後述する（図１８参照）。

［ステップＳ１３］アップデート部８２８は、移行パターンテーブル生成部８２７で生成された移行パターンテーブル８２７ａに設定された移行パターンに従って、各ディスクノード１１０，１２０，１３０，２１０，２２０，２３０，３１０，３２０，３３０のソフトウェアのアップデート処理を実行する。この処理の詳細は後述する（図２０〜図２３参照）。

次に、ソフトウェア移行処理の各ステップの処理を詳細に説明する。
図１６は、移行後環境テーブル生成処理の手順を示すフローチャートである。以下、図１６に示す処理をステップ番号に沿って説明する。

［ステップＳ２１］移行後環境テーブル生成部８２６は、移行条件入力テーブル８２５を参照し、クラスタＮｏ．の欄に設定されている識別子のクラスタグループのうち、未選択のクラスタグループを１つ選択する。

［ステップＳ２２］移行後環境テーブル生成部８２６は、ステップＳ２１で選択したクラスタグループの情報を移行条件入力テーブル８２５から抽出し、移行後環境テーブル８２６ａに設定する。

［ステップＳ２３］移行後環境テーブル生成部８２６は、移行条件入力テーブル８２５に設定されているすべてのクラスタグループを選択したか否かを判断する。すべてのクラスタグループが選択済であれば、移行後環境テーブル生成処理が終了する。未選択のクラスタグループがあれば、処理がステップＳ２１に進められる。

このようにして、移行後環境テーブル８２６ａが生成される。
図１７は、移行後環境テーブルのデータ構造例を示す図である。移行後環境テーブル８２６ａには、クラスタＮｏ．とアップデート後の環境との欄が設けられている。

クラスタＮｏ．の欄には、クラスタグループの識別子が設定される。アップデート後の環境の欄には、対応するクラスタグループ内のディスクノードで動作しているソフトウェア資源が設定されている。

アップデート後の環境の欄は、クラスタ制御ソフトウェアとＯＳとの欄に分けられている。クラスタ制御ソフトウェアの欄には、さらにソフトウェア名と版数との欄が設けられており、それぞれの欄にディスクノードに実装するクラスタ制御ソフトウェアの名称と版数とが設定される。ＯＳの欄には、さらにソフトウェア名と版数との欄が設けられており、それぞれの欄にディスクノードに実装されるＯＳの名称と版数とが設定される。

このような移行後環境テーブル８２６ａに基づいて、移行パターンテーブル生成部８２７によって移行パターンテーブル８２７ａが生成される。
図１８は、移行パターンテーブル生成処理の手順を示すフローチャートである。以下、図１８に示す処理をステップ番号に沿って説明する。

［ステップＳ３１］移行パターンテーブル生成部８２７は、移行後環境テーブル８２６ａを参照し、クラスタＮｏ．の欄に識別子が設定されている未選択のクラスタグループを１つ選択する。

［ステップＳ３２］移行パターンテーブル生成部８２７は、ステップＳ３１で選択したクラスタグループの移行前後の環境（ソフトウェア名と版数）を取得する。具体的には、移行パターンテーブル生成部８２７は、クラスタＮｏ．を検索キーとして、移行前環境テーブル８２１と移行後環境テーブル８２６ａとから、選択されたクラスタグループに関する情報を取得する。

［ステップＳ３３］移行パターンテーブル生成部８２７は、移行前後の環境に対応する移行パターンを判定する。具体的には、移行パターンテーブル生成部８２７は、移行パターン決定テーブル８２２から、移行前後の環境に合致する移行パターンを検索する。そして、移行パターンテーブル生成部８２７は、検索でヒットした情報の移行パターンの識別子を取得する。

［ステップＳ３４］移行パターンテーブル生成部８２７は、所要時間テーブル８２３を参照し、ステップＳ３３で取得した移行パターンの識別子に対応する所要時間を取得する。

［ステップＳ３５］移行パターンテーブル生成部８２７は、移行パターンテーブル８２７ａに、クラスタグループの識別子、移行パターンの識別子、および所要時間の各情報を登録する。

［ステップＳ３６］移行パターンテーブル生成部８２７は、ステップＳ３４で取得した所要時間が１分以内か否かを判断する。所要時間が１分以内であれば、処理がステップＳ３７に進められる。所要時間が１分より長ければ、処理がステップＳ３８に進められる。

［ステップＳ３７］移行パターンテーブル生成部８２７は、所要時間が１分以内の場合、移行パターンテーブル８２７ａのステップＳ３５で登録した情報に対して、顧客通知フラグとして「ＯＦＦ」を設定する。その後、処理がステップＳ４１に進められる。

［ステップＳ３８］移行パターンテーブル生成部８２７は、所要時間が１分より大きい場合、所要時間が１５分以下か否かを判断する。所要時間が１５分以下であれば、処理がステップ３９に進められる。所要時間が１５分より長ければ、処理がステップＳ４０に進められる。

［ステップＳ３９］移行パターンテーブル生成部８２７は、所要時間が１分より長く、１５以下の場合、移行パターンテーブル８２７ａのステップＳ３５で登録した情報に対して、顧客通知フラグとして「ＯＮ」を設定すると共に、メッセージの識別番号「Ｍ１」を設定する。その後、処理がステップＳ４１に進められる。

［ステップＳ４０］移行パターンテーブル生成部８２７は、所要時間が１５分より長い場合、移行パターンテーブル８２７ａのステップＳ３５で登録した情報に対して、顧客通知フラグとして「ＯＮ」を設定すると共に、メッセージの識別番号「Ｍ２」を設定する。

［ステップＳ４１］移行パターンテーブル生成部８２７は、すべてのクラスタグループを選択したか否かを判断する。すべてのクラスタグループが選択されていれば、移行パターンテーブル生成処理が終了する。未選択のクラスタグループがあれば、処理がステップＳ３１に進められる。

このようにして、移行パターンテーブル８２７ａが生成される。
図１９は、移行パターンテーブルのデータ構造例を示す図である。移行パターンテーブル８２７ａには、クラスタＮｏ．、移行パターン、所要時間、顧客通知フラグ、およびメッセージＮｏ．の欄が設けられている。

クラスタＮｏ．の欄には、ソフトウェアのアップデート対象となるクラスタグループの識別子が設定される。移行パターンの欄には、対応するクラスタグループに属するディスクノードに適用される移行パターンが設定される。所要時間の欄には、適用される移行パターンに従ったソフトウェアのアップデートに要する時間が設定される。

顧客通知フラグの欄には、ソフトウェアのアップデート時に顧客にメッセージを通知するか否かが設定される。顧客にメッセージを通知する場合、顧客通知フラグは「ＯＮ」であり、顧客にメッセージを通知しない場合、顧客通知フラグは「ＯＦＦ」である。

このような移行パターンテーブル８２７ａが作成されると、アップデート部８２８によってディスクノードのソフトウェアアップデート処理が行われる。
図２０は、アップデート処理の手順を示すフローチャートである。以下、図２０に示す処理をステップ番号に沿って説明する。

［ステップＳ５１］アップデート部８２８は、移行パターンテーブル８２７ａに識別子が設定されているクラスタグループの中から、未選択のクラスタグループを１つ選択する。

［ステップＳ５２］アップデート部８２８は、移行パターンテーブル８２７ａを参照し、選択したクラスタグループに適用する移行パターンが「ＰＴ１」か否かを判断する。適用する移行パターンが「ＰＴ１」であれば、処理がステップＳ５３に進められる。適用する移行パターンが「ＰＴ１」以外であれば、処理がステップＳ５４に進められる。

［ステップＳ５３］アップデート部８２８は、移行パターン「ＰＴ１」によるアップデート処理を実行する。この処理の詳細は後述する（図２１参照）。その後、処理がステップＳ５７に進められる。

［ステップＳ５４］アップデート部８２８は、移行パターンテーブル８２７ａを参照し、選択したクラスタグループに適用する移行パターンが「Ｐ２」か否かを判断する。適用する移行パターンが「ＰＴ２」であれば、処理がステップＳ５５に進められる。適用する移行パターンが「ＰＴ２」以外であれば、処理がステップＳ５６に進められる。

［ステップＳ５５］アップデート部８２８は、移行パターン「ＰＴ２」によるアップデート処理を実行する。この処理の詳細は後述する（図２２参照）。その後、処理がステップＳ５７に進められる。

［ステップＳ５６］アップデート部８２８は、移行パターン「ＰＴ３」によるアップデート処理を実行する。この処理の詳細は後述する（図２３参照）。
その後、処理がステップＳ５７に進められる。

［ステップＳ５７］アップデート部８２８は、移行パターンテーブル８２７ａに設定されているすべてのクラスタグループに対するソフトウェアのアップデートが完了したか否かを判断する。すべてのクラスタグループのアップデートが完了した場合、アップデート処理が終了する。アップデートが未完了のクラスタグループがある場合、処理がステップＳ５１に進められる。

次に、移行パターンごとのアップデート処理について説明する。
図２１は、移行パターン「ＰＴ１」によるアップデート処理の手順を示すフローチャートである。以下、図２１に示す処理をステップ番号に沿って説明する。

［ステップＳ６１］アップデート部８２８は、書き込み禁止処理を行う。具体的には、アップデート部８２８は、アップデート対象のクラスタグループに属する各ディスクノードに対して、書き込み禁止要求を送信する。書き込み禁止要求を取得したディスクノードでは、書き込み禁止が解除されるまで、ストレージ装置へのデータの書き込みを停止する。

［ステップＳ６２］アップデート部８２８は、ディスクノードで運用されている旧クラスタ制御ソフトウェアを停止する。具体的には、アップデート部８２８は、ディスクノードに対して、クラスタ制御ソフトウェアの停止要求を送信する。その停止要求を受け取ったディスクノードは、クラスタ制御ソフトウェアを停止する。

［ステップＳ６３］アップデート部８２８は、制御ノード５００に対して事前復旧処理の開始指示を送信する。これにより、制御ノード５００において事前復旧処理が開始される。事前復旧処理を行っておくことで、新クラスタ制御ソフトウェアの起動に失敗した場合に迅速な復旧が可能となる。

なお、制御ノード５００では、アップデート部８２８からの指示がなくても、ディスクノードからのハードビート（起動していることを通知するために定期的に送信される信号）が所定期間途絶えると、自動的にそのディスクノードが管理するデータの事前復旧処理が開始される。本実施の形態では、アップデート部８２８から指示で強制的に事前復旧処理を開始させることで、ハートビートが途絶えたことを検出するのを待たずに、迅速に事前復旧処理を開始することができる。

［ステップＳ６４］アップデート部８２８は、ディスクノードで新しい版数のクラスタ制御ソフトウェアを起動させる。具体的には、アップデート部８２８は、ディスクノードに対して、移行後環境テーブル８２６ａを参照し、移行後のクラスタ制御ソフトウェアのソフトウェア名と版数とを取得する。そして、アップデート部８２８は、移行後のソフトウェア名と版数とを指定して、ディスクノードに対してクラスタ制御ソフトウェアの起動要求を送信する。起動要求を受け取ったディスクノードは、指定されたクラスタ制御ソフトウェアの指定された版数のプログラムを起動する。プログラムの起動と共に、書き込み禁止処理は解除される。その後、移行パターン「ＰＴ１」によるアップデート処理が終了する。

図２２は、移行パターン「ＰＴ２」によるアップデート処理の手順を示すフローチャートである。以下、図２２に示す処理をステップ番号に沿って説明する。
［ステップＳ７１］アップデート部８２８は、新ＯＳがディスクノードに準備完了しているか否かを判断する。具体的には、アップデート部８２８は、移行後環境テーブル８２６ａを参照し、移行後のＯＳのソフトウェア名と版数とを取得する。そして、アップデート部８２８は、ディスクノードに対して、新ＯＳの準備の有無を問い合わせる。ディスクノードは、問い合わせに応じて、移行後のソフトウェア名と版数とに相当するＯＳが、現在動作しているＯＳが導入されたパーティションとは別のパーティションに導入されるか否かを応答する。アップデート部８２８は、新ＯＳが別バーティションに導入されていれば、新ＯＳ準備済と判断する。新ＯＳが準備済であれば、処理がステップＳ７３に進められる。新ＯＳが準備済でなければ、処理がステップＳ７２に進められる。

［ステップＳ７２］アップデート部８２８は、現在動作しているＯＳが導入されたパーティションとは別のパーティションに、移行後のＯＳを導入する。具体的には、アップデート部８２８は、新ＯＳの導入をディスクノードに指示する。ディスクノードでは、アップデート部８２８からの指示に応じて新ＯＳを導入する。

［ステップＳ７３］アップデート部８２８は、移行パターンテーブル８２７ａを参照し、アップデート対象のクラスタグループに対する顧客通知フラグがＯＮか否かを判断する。顧客通知フラグがＯＮであれば、処理がステップＳ７４に進められる。顧客通知フラグがＯＦＦであれば、処理がステップＳ７５に進められる。なお、移行パターンが「ＰＴ２」でありながら顧客通知フラグがＯＦＦの場合とは、所要時間テーブル８２３において移行パターン「ＰＴ２」の所要時間の値が１分以下に設定されていたときである。例えば、ディスクノードに対して機能を制限したＯＳを導入する場合、ＯＳのリブートを短時間で行うことも可能である。その場合、移行パターン「ＰＴ２」であっても、アップデートの所要時間が１分以内となることもある。

［ステップＳ７４］顧客通知フラグがＯＮであれば、アップデート部８２８は、停止メッセージを端末装置２１〜２３に送信する。具体的には、アップデート部８２８は、移行パターンテーブル８２７ａを参照し、メッセージの識別番号を取得する。次に、アップデート部８２８は、メッセージ管理テーブル８２４を参照し、メッセージの識別番号に対応するメッセージを取得する。そして、アップデート部８２８は、アクセスノード６００，７００経由で、各端末装置２１〜２３に対して取得したメッセージを送信する。図１３の例であれば、所定時間データの書き込みが禁止される旨のメッセージが送信される。

［ステップＳ７５］アップデート部８２８は、書き込み禁止処理を行う。具体的には、アップデート部８２８は、アップデート対象のクラスタグループに属する各ディスクノードに対して、書き込み禁止要求を送信する。書き込み禁止要求を取得したディスクノードでは、書き込み禁止が解除されるまで、ストレージ装置へのデータの書き込みを停止する。

［ステップＳ７６］アップデート部８２８は、ディスクノードで運用されている旧クラスタ制御ソフトウェアを停止する。具体的には、アップデート部８２８は、ディスクノードに対して、クラスタ制御ソフトウェアの停止要求を送信する。その停止要求を受け取ったディスクノードは、クラスタ制御ソフトウェアを停止する。

［ステップＳ７７］アップデート部８２８は、制御ノード５００に対して事前復旧処理の開始指示を送信する。これにより、制御ノード５００において事前復旧処理が開始される。

［ステップＳ７８］アップデート部８２８は、新ＯＳで再起動を行う。具体的には、アップデート部８２８は、ディスクノードに対して、新ＯＳでの再起動を指示する。すると、ディスクノードは、次に起動するときのＯＳの読み込み先（ブート先）として、新ＯＳを導入したパーティションを設定する。その後、ディスクノードは、現在動作しているＯＳにおいて、再起動の命令を実行する。すると、ディスクノードでは、現在動作しているＯＳが停止（シャットダウン）した後、新たなＯＳが起動される。

［ステップＳ７９］アップデート部８２８は、ディスクノードで新しい版数のクラスタ制御ソフトウェアを起動する。具体的には、アップデート部８２８は、ディスクノードに対して、移行後環境テーブル８２６ａを参照し、移行後のクラスタ制御ソフトウェアのソフトウェア名と版数とを取得する。そして、アップデート部８２８は、移行後のソフトウェア名と版数とを指定して、ディスクノードに対してクラスタ制御ソフトウェアの起動要求を送信する。起動要求を受け取ったディスクノードは、指定されたクラスタ制御ソフトウェアの指定された版数のプログラムを起動する。プログラムの起動と共に、書き込み禁止処理は解除される。その後、移行パターン「ＰＴ２」によるアップデート処理が終了する。

図２３は、移行パターン「ＰＴ３」によるアップデート処理の手順を示すフローチャートである。以下、図２３に示す処理をステップ番号に沿って説明する。
［ステップＳ８１］アップデート部８２８は、移行パターンテーブル８２７ａを参照し、アップデート対象のクラスタグループに対する顧客通知フラグがＯＮか否かを判断する。顧客通知フラグがＯＮであれば、処理がステップＳ８２に進められる。顧客通知フラグがＯＦＦであれば、処理がステップＳ８３に進められる。なお、移行パターンが「ＰＴ３」でありながら顧客通知フラグがＯＦＦの場合とは、管理者がメッセージの通知は不要と判断し、移行パターンテーブル８２７ａの顧客通知フラグをＯＦＦに書き換えた場合である。移行パターンが「ＰＴ３」の場合、３重化処理を行うため、ユーザへのサービスが停止することはない。そのため、管理者が、端末装置２１〜２３に対してメッセージを送信しないという選択をすることも可能である。

［ステップＳ８２］顧客通知フラグがＯＮであれば、アップデート部８２８は、停止メッセージを端末装置２１〜２３に送信する。具体的には、アップデート部８２８は、移行パターンテーブル８２７ａを参照し、メッセージの識別番号を取得する。次に、アップデート部８２８は、メッセージ管理テーブル８２４を参照し、メッセージの識別番号に対応するメッセージを取得する。そして、アップデート部８２８は、アクセスノード６００，７００経由で、各端末装置２１〜２３に対して取得したメッセージを送信する。図１３の例であれば、所定時間処理能力が低下する旨のメッセージが送信される。

［ステップＳ８３］アップデート部８２８は、ソフトウェアのアップデート対象のディスクノードを指定して、制御ノード５００に対して３重化処理を指示する。３重化処理の指示を受けた制御ノード５００は、アップデート対象のディスクノードで管理されているデータを、同一クラスタグループに属する他のディスクノードにコピーする。コピーが完了すると、制御ノード５００は、コピーしたデータが格納されたスライスを論理ボリュームに割り当て、アップデート対象のディスクノードで管理されているスライスの割り当てを解除する。この割り当ての変更に伴って、制御ノード５００は、スライス管理情報群記憶部５２０内のスライス管理情報を更新し、更新されたスライス管理情報をアクセスノード６００，７００に送信する。このように３重化状態を経た後、アップデート対象のディスクノードをシステムから切り離す（セグメントへの割当対象外とする）。これにより、アップデート対象のディスクノードに格納されていたデータは、システム上二重化状態となる。

［ステップＳ８４］アップデート部８２８は、ソフトウェアのアップデート対象のディスクノードに対して旧ＯＳの停止を指示する。指示を受け取ったディスクノードは、ＯＳを停止させる。

［ステップＳ８５］アップデート部８２８は、遠隔操作によりディスクノードに対して新ＯＳを導入する。なお、遠隔操作でのＯＳの導入ができない場合は、管理者がディスクノードに直接操作入力を行い、ＯＳの導入作業を行う。

［ステップＳ８６］アップデート部８２８は、ディスクノードに対してＯＳの起動を指示する。すると、ディスクノードが新ＯＳを起動する。この際アップデートしたディスクノードのストレージ装置（ＲＡＩＤ）を初期化する。

［ステップＳ８７］アップデート部８２８は、ディスクノードで新しい版数のクラスタ制御ソフトウェアを起動させる。具体的には、アップデート部８２８は、ディスクノードに対して、移行後環境テーブル８２６ａを参照し、移行後のクラスタ制御ソフトウェアのソフトウェア名と版数とを取得する。そして、アップデート部８２８は、移行後のソフトウェア名と版数とを指定して、ディスクノードに対してクラスタ制御ソフトウェアの起動要求を送信する。起動要求を受け取ったディスクノードは、指定されたクラスタ制御ソフトウェアの指定された版数のプログラムを起動する。プログラムの起動と共に、書き込み禁止処理は解除される。この後、アップデート部８２８は、制御ノード５００にデータの再配置を指示し、移行パターン「ＰＴ３」によるアップデート処理が終了する。

データの再配置は、データアクセスが効率的となるように、論理ディスクの各セグメントに割り当てるスライスを変更する処理である。すなわち、論理ディスクのセグメントに割り当てられたスライスの属するディスクノードに偏りがあると、特定のディスクノードに対してアクセスが集中する。そのため、データアクセスの際の応答遅延が発生しやすくなる。３重化を経由したソフトウェアアップデート直後は、アップデート対象のディスクノードのスライスはセグメントに割り当てられていない。そのため、各ディスクノード１１０，１２０，１３０，・・・における論理ディスクに割り当てられたスライスの数が、ディスクノード間で均等となるように、データの再配置が行われる。

具体的には、データの再配置の指示を受け取った制御ノード５００では、論理ボリューム管理部５１０が、論理ボリュームのセグメントへのセグメントの割当関係を判断する。その際、論理ボリュームへの割当対象として、各ディスクノード１１０，１２０，１３０，・・・のスライスを均等に選択する。そして、論理ボリューム管理部５１０は、判断した割当関係となるように、各ディスクノード１１０，１２０，１３０，・・・に対してデータの再配置を指示する。ディスクノード１１０，１２０，１３０，・・・は互いにデータの受け渡し、再配置後の割当に応じたデータをスライスに格納する。その後、各ディスクノード１１０，１２０，１３０，・・・、制御ノード５００、およびアクセスノード６００，７００のスライス管理情報が更新される。このような再配置を行うことで、移行パターン「ＰＴ３」によるソフトウェアアップデート後においても、効率的なデータアクセスが可能となる。

なお、図２３に示した処理は、クラスタグループに属するディスクノードに対して順番に行われる。順番に処理を実行することで、３重化の際のデータコピー処理が重複して発生するのを防止できる。また、クラスタグループ内の複数のディスクノードのＯＳが同時期に停止することも防止できる。

以上のようにして、ソフトウェアのアップデート時の処理内容に応じた移行パターンを定義しておくことで、短時間でアップデートが可能な場合にはデータの３重化を行わなくて済む。その結果、ソフトウェアのアップデートを短時間で終了させることができる。

ここで、事前復旧処理について説明する。
図２４は、事前復旧処理の概要を示す図である。事前復旧処理は、ソフトウェアのアップデートにおいて新しいソフトウェアの再起動に失敗する場合を想定して、予防的に実行される復旧処理である。

第１の状態［ＳＴ１］は、ソフトウェアのアップデート開始前のデータ配置を示している。この配置の内容は、図４に示したとおりである。
第２の状態［ＳＴ２］は、ソフトウェアのアップデートのためにディスクノード１１０の機能が停止した状態を示している。ディスクノード１１０の機能が停止したことにより、ディスクノード１１０に接続されたストレージ装置１１１に格納されているデータの復旧処理が開始される。

具体的には、制御ノード５００が、停止したディスクノード内に存在するスライスデータを特定し、他の正常ディスクノード内に存在するペアとなるスライスデータを探す。そして、制御ノード５００は、該当するデータを管理するディスクノードに対して、別のディスクノード（停止したディスクノードの除く）へのコピーを指示する。図２４の例では、１番目のセグメントのプライマリスライス「Ｐ１」、２番目のセグメントのセカンダリスライス「Ｓ２」、および４番目のセグメントのプライマリスライス「Ｐ４」の復旧が必要である。そこで、ストレージ装置１３１のスライス１３１ａからストレージ装置１２１のスライス１２１ｃに、４番目のセグメントのデータがコピーされ、ストレージ装置１２１のスライス１２１ｂからストレージ装置１３１のスライス１３１ｂに、１番目のセグメントのデータがコピーされる。そして、２番目のセグメントのデータをコピーする前に、ディスクノード１１０が復帰したものとする。

第３の状態［ＳＴ３］は、ディスクノード１１０復帰後の状態を示している。ディスクノード１１０が正常に復帰した場合、ディスクノード１１０が有するディスク装置１１１に格納されているデータが有効となる。事前復旧処理によってコピーされたデータの格納領域は解放され、該当領域に格納されたデータは無効となる。

このように、アップデートを実施することでデバイスが一時停止してリカバリ処理が発生するが、アップデートが完了することによりディスクノード１１０が復帰すると、リカバリ処理は終了する。もしディスクノード１１０が復帰できなかった場合、復旧処理が継続される。この場合、ディスクノード１１０が復帰できないことが判明してから復旧処理を開始する場合にくらべ、復旧までの時間が短縮される。

また、事前復旧処理を行っていれば、データの冗長性が損なわれる時間を短くすることができる。すなわち、ソフトウェアアップデート中にコピーが完了したデータは、コピー後は２重化が保たれており、データの信頼性が維持できる。

なお、本実施の形態では、事前復旧処理が実行される場合には、データの書き込み禁止処理が行われている。そのため、データの書き込みを考慮せずに事前復旧処理を実施することができ、処理を簡略化することができる。すなわち、データの書き込みを許可した状態で事前復旧処理を行うには、以下のような処理が余計に必要となる。

各ディスクノードにおいて、管理しているスライスの更新状況を管理する。更新の状況は、各ディスクノードに設定された更新カウンタで判断する。更新カウンタとしては、例えば、シリアルナンバを用いることができる。更新カウンタとしてシリアルナンバを用いた場合、各ディスクノードは、スライスのデータが更新される度に、シリアルナンバを１ずつ加算する。同一セグメントを構成するスライス（プライマリスライスとセカンダリスライス）のデータの更新は同じ回数なので、通常の動作中はセグメントを構成する２つのスライスでシリアスナンバは一致する。

しかし、停止中のディスクノードに格納されているデータに対する更新処理が行われると、ペアとなるスライスのデータのみが更新され、更新カウンタがカウントアップされる。その後、停止していたディスクノードが復帰すると、復帰したディスクノードが管理するスライスの更新カウンタと、そのスライスとペアとなる他のディスクノードで管理されているスライスの更新カウンタとは異なる値となる。従って、これらの更新カウンタを比較することで、データの更新の有無を判定することができる。

そこで、停止していたディスクノードが復帰すると、そのディスクノードが管理するスライスの更新カウンタと、ペアとなるスライスの更新カウンタとを比較して、更新の有無が判定される。未コピーのデータが未更新であれば、コピーは中止となる。未コピーのデータが更新されていれば、更新されたデータをコピーして２重化される。既コピーのデータが未更新であれば、ディスクノード１１０が有するストレージ装置１１１内のデータが有効とされる。そのため、ストレージ装置１２１のスライス１２１ｃの領域は開放される（コピーされたデータは無効となる）。既コピーのデータが更新されていれば、事前復旧処理でコピーしたデータが有効とされる。そのため、ストレージ装置１１１のスライス１１１ｂの領域は開放される（格納されていたデータは無効となる）。

このように、データの書き込みを禁止せずに事前復旧処理を行うには、データの更新管理（更新カウンタの管理、およびディスクノード復帰後のデータの更新の有無判断）が必要となる。データの書き込みを禁止していれば、これらの処理を行わずに済み、事前復旧処理の処理効率が向上する。

なお、上記の実施の形態では、管理ノード８００がアップデート管理部８２０を有しているが、アップデート管理部８２０の機能を制御ノード５００内に設けることもできる。
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、管理ノードや制御ノードが有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disc）などがある。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

なお、本発明は、上述の実施の形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変更を加えることができる。

実施の形態の概要を示す図である。 本実施の形態の分散ストレージシステム構成例を示す図である。 本実施の形態に用いる管理ノードのハードウェア構成例を示す図である。 論理ボリュームのデータ構造を示す図である。 分散ストレージシステムの各装置の機能を示すブロック図である。 ディスクノード内のスライス管理情報のデータ構造例を示す図である。 スライス管理情報群記憶部のデータ構造例を示す図である。 複写元プログラム記憶部のデータ構造例を示す図である。 ソフトウェアのアップデート機能を示すブロック図である。 移行前環境テーブルのデータ構造例を示す図である。 移行パターン決定テーブルのデータ構造例を示す図である。 所要時間テーブルのデータ構造例を示す図である。 メッセージ管理テーブルのデータ構造例を示す図である。 移行条件入力テーブルのデータ構造例を示す図である。 ソフトウェア移行処理の手順を示すフローチャートである。 移行後環境テーブル生成処理の手順を示すフローチャートである。 移行後環境テーブルのデータ構造例を示す図である。 移行パターンテーブル生成処理の手順を示すフローチャートである。 移行パターンテーブルのデータ構造例を示す図である。 アップデート処理の手順を示すフローチャートである。 移行パターンＰＴ１によるアップデート処理の手順を示すフローチャートである。 移行パターンＰＴ２によるアップデート処理の手順を示すフローチャートである。 移行パターンＰＴ３によるアップデート処理の手順を示すフローチャートである。 事前復旧処理の概要を示す図である。

符号の説明

１ ソフトウェアアップデート管理装置
１ａ 記憶装置
１ａａ 移行前環境テーブル
１ａｂ 移行後環境テーブル
１ａｃ 移行パターン決定テーブル
１ｂ 移行内容判断手段
１ｃ 移行パターン決定手段
１ｄ アップデート手段
２，３，４，・・・ ディスクノード

Claims (10)

1. 複数のディスクノードで冗長性を持たせたデータ管理を行う分散ストレージシステムにおける前記ディスクノードのソフトウェアアップデート処理をコンピュータに実行させるソフトウェアアップデート管理プログラムであって、
   前記コンピュータを、
   アップデート対象である対象ディスクノードのアップデート前のソフトウェアのソフトウェア名と版数とが前記対象ディスクノードの機能ごとに設定された移行前環境テーブルと、前記対象ディスクノードのアップデート後のソフトウェアのソフトウェア名と版数とが前記対象ディスクノードの機能ごとに設定された移行後環境テーブルとを記憶装置から読み出し、前記対象ディスクノードの機能ごとのアップデート前後におけるソフトウェア名と版数との推移を示す移行内容を判断する移行内容判断手段、
   前記対象ディスクノードで管理しているデータの更新を禁止することでデータの冗長性を維持してソフトウェアアップデートを行う第１種移行パターンと、前記対象ディスクノードで管理しているデータを他の前記ディスクノードにコピーすることでデータの冗長性を維持してソフトウェアのアップデートを行う第２種移行パターンとに分類される複数の移行パターンと、移行パターンを適用する移行内容との対応関係が設定された移行パターン決定テーブルを記憶装置から読み出し、前記移行内容判断手段により判断された移行内容と前記移行パターン決定テーブルとに基づいて、前記対象ディスクノードに適用する移行パターンを決定する移行パターン決定手段、
   前記移行後環境テーブルを記憶装置から読み出し、前記移行パターン決定手段で決定された移行パターンに従って前記対象ディスクノードに対して指示を出し、前記対象ディスクノードの各機能を実行するソフトウェアを、前記移行後環境テーブルに設定されたソフトウェア名と版数とにアップデートするアップデート手段、
   として機能させるソフトウェアアップデート管理プログラム。
2. 前記移行前環境テーブルには、ソフトウェアアップデート前のクラスタ制御機能とオペレーティングシステムとに関するソフトウェアのソフトウェア名と版数とが設定されており、前記移行後環境テーブルには、ソフトウェアアップデート前のクラスタ制御機能とオペレーティングシステムとに関するソフトウェア名と版数とが設定されていることを特徴とする請求項１記載のソフトウェアアップデート管理プログラム。
3. 前記移行パターン決定テーブルには、オペレーティングシステムのソフトウェアが変更される移行内容の場合には、前記第２種移行パターンに属する移行パターンを適用することが設定されていることを特徴とする請求項１記載のソフトウェアアップデート管理プログラム。
4. 前記移行パターン決定テーブルには、オペレーティングシステムのソフトウェアが同一のまま、オペレーティングシステムの版数が更新される移行内容の場合には、前記第１種移行パターンに属する移行パターンを適用することが設定されていることを特徴とする請求項１記載のソフトウェアアップデート管理プログラム。
5. 前記移行パターン決定テーブルには、前記第１種移行パターンに属する移行パターンが複数設定されていることを特徴とする請求項１記載のソフトウェアアップデート管理プログラム。
6. 前記移行パターン決定テーブルには、前記第１種移行パターンに属する移行パターンとして、オペレーティングシステムのリブートを伴う移行パターンと、オペレーティングシステムのリブートを伴わない移行パターンとが設定されていることを特徴とする請求項５記載のソフトウェアアップデート管理プログラム。
7. 前記移行パターン決定テーブルには、前記第１種移行パターンに属する移行パターンとして、ソフトウェアアップデート処理と並行して、前記対象ディスクノードで管理されているデータの復旧処理を開始し、アップデートされたソフトウェアが正常に起動できた場合には、ソフトウェアアップデート中に更新されていない他データについての復旧処理を停止する移行パターンが含まれていることを特徴とする請求項１記載のソフトウェアアップデート管理プログラム。
8. 前記アップデート手段は、移行パターンごとの所要時間が設定された所要時間テーブルを記憶装置から取得し、前記対象ディスクノードに適用する移行パターンの所要時間が、所定時間を超えていれば前記対象ディスクノードへのアクセス要求を出力する端末装置に対してアップデート処理に伴う注意を促すメッセージを送信することを特徴とする請求項１記載のソフトウェアアップデート管理プログラム。
9. 複数のディスクノードで冗長性を持たせたデータ管理を行う分散ストレージシステムにおける前記ディスクノードのソフトウェアアップデート処理を実行するソフトウェアアップデート管理装置であって、
   アップデート対象である対象ディスクノードのアップデート前のソフトウェアのソフトウェア名と版数とが前記対象ディスクノードの機能ごとに設定された移行前環境テーブルと、前記対象ディスクノードのアップデート後のソフトウェアのソフトウェア名と版数とが前記対象ディスクノードの機能ごとに設定された移行後環境テーブルとを記憶装置から読み出し、前記対象ディスクノードの機能ごとのアップデート前後におけるソフトウェア名と版数との推移を示す移行内容を判断する移行内容判断手段と、
   前記対象ディスクノードで管理しているデータの更新を禁止することでデータの冗長性を維持してソフトウェアアップデートを行う第１種移行パターンと、前記対象ディスクノードで管理しているデータを他の前記ディスクノードにコピーすることでデータの冗長性を維持してソフトウェアのアップデートを行う第２種移行パターンとに分類される複数の移行パターンと、移行パターンを適用する移行内容との対応関係が設定された移行パターン決定テーブルを記憶装置から読み出し、前記移行内容判断手段により判断された移行内容と前記移行パターン決定テーブルとに基づいて、前記対象ディスクノードに適用する移行パターンを決定する移行パターン決定手段と、
   前記移行後環境テーブルを記憶装置から読み出し、前記移行パターン決定手段で決定された移行パターンに従って前記対象ディスクノードに対して指示を出し、前記対象ディスクノードの各機能を実行するソフトウェアを、前記移行後環境テーブルに設定されたソフトウェア名と版数とにアップデートするアップデート手段と、
   を有するソフトウェアアップデート管理装置。
10. 複数のディスクノードで冗長性を持たせたデータ管理を行う分散ストレージシステムにおける前記ディスクノードのソフトウェアアップデート処理を、コンピュータが実行するソフトウェアアップデート管理方法であって、
    前記コンピュータが、
    アップデート対象である対象ディスクノードのアップデート前のソフトウェアのソフトウェア名と版数とが前記対象ディスクノードの機能ごとに設定された移行前環境テーブルと、前記対象ディスクノードのアップデート後のソフトウェアのソフトウェア名と版数とが前記対象ディスクノードの機能ごとに設定された移行後環境テーブルとを記憶装置から読み出し、前記対象ディスクノードの機能ごとのアップデート前後におけるソフトウェア名と版数との推移を示す移行内容を判断し、
    前記対象ディスクノードで管理しているデータの更新を禁止することでデータの冗長性を維持してソフトウェアアップデートを行う第１種移行パターンと、前記対象ディスクノードで管理しているデータを他の前記ディスクノードにコピーすることでデータの冗長性を維持してソフトウェアのアップデートを行う第２種移行パターンとに分類される複数の移行パターンと、移行パターンを適用する移行内容との対応関係が設定された移行パターン決定テーブルを記憶装置から読み出し、前記移行内容判断手段により判断された移行内容と前記移行パターン決定テーブルとに基づいて、前記対象ディスクノードに適用する移行パターンを決定し、
    前記移行後環境テーブルを記憶装置から読み出し、前記移行パターン決定手段で決定された移行パターンに従って前記対象ディスクノードに対して指示を出し、前記対象ディスクノードの各機能を実行するソフトウェアを、前記移行後環境テーブルに設定されたソフトウェア名と版数とにアップデートする、
    ことを特徴とするソフトウェアアップデート管理方法。

Images