JP2005276233A - 計算機システム - Google Patents

Abstract

【課題】
従来のNC等のThinクライアント計算機システムは、運用管理をサーバに集約することで、TCOを削減するが、LANおよびサーバのオーバヘッドでアクセス性能が低下するという課題がある。
【解決手段】
計算機システムを、複数のクライアント計算機と、各クライアント計算機により共用されるストレージと、ストレージを管理するための管理コンソールと、各クライアント計算機とストレージと管理コンソールとを相互接続するための接続装置とで構成する。
【選択図】 図１

Description

本発明は、複数のクライアント計算機により構成するクライアント計算機システムの実現方法に関し、特に、クライアント計算機用の記憶装置のメンテナンスに要する運用コストの低減と、記憶装置のアクセス性能の向上の両立を実現する方法に関する。

複数のユーザが複数のPC等のクライアント計算機を用いて業務処理等を行う計算機システムをクライアント計算機システムと呼ぶ。従来は単独ですべての計算処理を実行できる機能を備えたPC等を用いてクライアント計算機システムを構築していた。このようなクライアント計算機には高性能なCPUや大容量のメモリや大容量なハードディスク装置や、高速なグラフィック装置等を搭載した”太った”計算機であるので、通称して「Fatクライアント」と称する。また、このFatクライアント計算機を用いたクライアント計算機システムのことをFatクライアントシステム(Fat Client System：FCS)と称する。 FCSでは複数のFatクライアントをLANで相互接続し、必要に応じファイル転送や、メール送受信等の通信を行う。Fatクライアントは、OSやアプリケーションやユーザデータ等を格納するためのストレージとしてディスク装置を備える。OSやアプリケーションのインストールは通常ユーザ自身が実施する。また、作成したユーザデータはハードディスクの障害で消失してしまわないように、LAN上のいずれかの場所に存在するテープ装置等のバックアップ装置でバックアップを行う。

また、このようなクライアント計算機システムの別の例としてNetwork Computerシステムが知られている。このシステムを構築する計算機はNetwork Computer（NC）と呼ばれ、OSやアプリケーションを格納するハードディスク装置を備えない等、低価格、低機能化した”痩せた”計算機を用いる。このような計算機のことをFatクライアントに対比し、「Thinクライアント」と称する。また、このThinクライアントを用いたクライアント計算機システムのことをThinクライアントシステム(Thin Client System：TCS)と称する。

以下、TCSの一例としてNCシステムシステムを図１１を用い説明する。

1000（a〜c）は複数台のNetwork Computer（以下NCと略記する）、7はサーバ、1はサーバ7用のストレージ、6はNC1000とサーバを相互に接続するLANである。

NC1000は、OSやアプリケーションやユーザデータを格納するためのストレージを備えない。LAN6を介してサーバ7のストレージ1の一部をNC1000用のリモートストレージとしてマウントし、ここにすべてのOS、アプリケーション、ユーザデータを格納する。起動時にはサーバ7のストレージ1からOSをLAN6経由でロードし実行する。アプリケーションの起動も同様である。

特開平６−１６８１９８号公報

従来技術のFCSは、容易にシステムを構築でき、初期導入コストが低いという長所がある反面、上記の通り、OS／アプリケーションのインストール、バージョンアップ等をユーザ自身が実施する必要があり、これらの運用管理コストが上昇し、その結果、システムを保持するために発生する総コスト（TCO：Total Cost of Ownership）が非常に高価になるという課題がある。

また、従来の技術のNCシステムを代表とするTCSは、運用管理をサーバに集約することで管理者が集中管理できるようにし、個別のユーザによる運用管理を排除し、TCOを削減することを狙ったものである。一方、すべてのユーザのディスクアクセスがLANおよびサーバ経由で発行されるため、LAN処理のオーバヘッドや、NCとサーバの両方で発生するリモートディスク制御処理のオーバヘッドにより各クライアントの内蔵ディスクへのアクセス性能に比べ大幅に低下するという課題がある。また、すべてのディスクアクセスがサーバに集中するため、サーバには非常に高いCPU性能とI/O処理性能が要求され、クライアント計算機システムの運用のために高価なサーバが必要になるという課題がある。

本発明の目的は、運用管理コストを低減することでTCOを低減したクライアント計算機システムを提供することである。

また、本発明の目的は、低オーバヘッドで高速なディスクアクセスを実現するクライアント計算機システムを提供することである。

また、本発明の目的は、LANやサーバに負荷をかけないクライアント計算機システムを提供することである。

また、本発明の目的は従来のFCSの内蔵ディスクアクセス性能を上回る高速ディスクアクセスを実現するクライアント計算機システムを提供することである。

本発明は、複数のディスクレスクライアント計算機と、すべてのクライアント計算機の共用ストレージと、共用ストレージを管理するための管理コンソールと、すべてのディスクレス計算機システムと共用ストレージと管理コンソールを相互に接続するI/Oチャネル結合回路により構成するクライアント計算機システムである。

ここで、ディスクレスクライアント計算機は、ファイバチャネル等のI/Oチャネルへの接続、制御を行うI/OチャネルI/F制御回路と、I/Oチャネルに接続したストレージからOSのブートアップを行うためのブートアップ制御回路とを備えたものである。なお、ディスクレスクライアント計算機には内蔵するディスク装置は備えない。

また、共用ストレージは、ファイバチャネル等のI/Oチャネルへの接続、制御を行うI/OチャネルI/F制御回路と、それぞれのクライアント計算機の専用の論理ユニット（LU：Logical Unit）や、各クライアントによる共用の論理ユニットを作成したり、削除したりするLU定義部と、各クライアント計算機に対する作成したLUのアクセス禁止／許可や、LUの属性や、クライアント計算機に見せる仮想的なLU番号（LUN：Logical UnitNumber）と共用ストレージ内部制御用のLU番号を管理するためのLUN管理テーブルと、LUN管理テーブルの格納情報に従い各クライアントからの各LUへのアクセスを制限し、また、許可した場合には当該ＬＵに対するリード・ライトアクセス制御を行うアクセス制御部と、LUを構築する少なくとも１台以上のディスク装置のデータをキャッシュし、キャッシュヒット時にはディスク装置からリード・ライトを行うことなく高速にデータ転送を実現するためのキャッシュと、指定したLUをキャッシュに常駐するよう制御するキャッシュ常駐制御部と、共用ストレージを設定・制御するための管理コンソールとの通信を制御する通信制御回路とを備えたものである。

また、管理コンソールは、共用ストレージのLU作成を指示し、クライアント計算機ごとの各 LUとのアクセス制限を設定し、各LUに仮想LUNを設定する制御を行うLU管理部と、共用ストレージとの通信を制御する通信制御回路と、ファイバチャネル等のI/Oチャネルへの接続、制御を行うI/OチャネルI/F制御回路とを備えたものである。

本発明によれば、アプリケーションやOSなどのインストールやバージョンアップや、データのバックアップを一元管理することができるので、運用管理コストを低減しTCOの低いクライアント計算機システムを実現できるという効果がある。

また、本発明によれば、複数のクライアントでストレージを共用するためにLANやサーバを使用しないので、低オーバヘッドで高速なディスクアクセスを実現するクライアント計算機システムを実現できるという効果がある。

また、本発明によれば、複数のクライアントでストレージを共用するためにLANやサーバを使用しないので、LANやサーバからストレージ共用のための負荷を解放することで高速なサーバ処理やネットワーク処理を実現できるという効果がある。

また、本発明によれば、複数のクライアントでアプリケーションやOSを共用することができるので、これらのインストールやバージョンアップにより発生する運用管理コストを最小減に低減できるとともに、キャッシュ常駐をすることで、高速アクセス性能を実現できるという効果がある。

以下、本発明の実施例について、図面を参照して説明する。尚、本発明は、本実施例に限られるものではない。

（Ａ）第一実施形態
○構成
第一実施形態を説明する。図１は第一実施形態のクライアント計算機システムの構成図である。なお、本実施形態ではクライアント計算機がPC（Personal Computer）であるとし、特にこのPCは内部にハードディスク装置を備えない「ディスクレスPC」であるとして説明する。なお、もちろんPC以外のクライアント計算機システムであっても同様に実施できる。

同図において、2（2a〜2c）は複数のディスクレスPC、1はすべてのクライアントPC2が共用するストレージ、4はストレージを管理するための管理コンソール、3はすべてのディスクレスPC2とストレージ1と管理コンソール4を相互に接続するファイバチャネル接続回路、5a〜5iはファイバチャネルである。

図２はディスクレスPC2の構成図である。21はディスクレスPCの全体制御を行い各種計算処理のプログラムを実行する中央制御装置、22はファイバチャネルの接続、制御を行うファイバチャネルI/F制御回路、23はこのPC2の操作者が操作するための入出力装置、221はファイバチャネルに接続したストレージからOSのブートアップを行うためのブートアップ制御回路である。なお、前述の通り、ディスクレスPCは内蔵するディスク装置を備えない。

図３はストレージ1の構成図である。11はストレージの全体制御を司る中央制御装置である。本実施形態では、中央制御装置11はプログラムで動作する装置であるとし、次の各プログラム部位を備える。12はそれぞれのディスクレスPC2（2a〜2c）の専用の論理ユニット（LU：Logical Unit）や、複数のディスクレスPC2の共用の論理ユニットを作成したり、削除したりするLU定義部、14は各ディスクレスPCに対する各LUのアクセス禁止／許可や、LUの属性や、ディスクレスPCに見せる仮想的なLU番号（LUN：Logical Unit Number）とストレージ内部管理用の内部LUNの対応を管理するためのLUN管理テーブル、16はLUN管理テーブル14の情報に従い各ディスクレスPC2からの各LUへのアクセスを制限／許可する制御を行い、許可した場合には当該ＬＵに対するリード・ライトアクセス制御を行うアクセス制御部である。

また、13はストレージにLUを定義する等の制御を行う管理コンソールとの間の通信を制御する通信制御回路、15はファイバチャネル5dへの接続、制御を行うファイバチャネルI/F制御回路、17（170〜176）は少なくとも１台の物理的なディスク装置の一定の記憶領域により構成し上位装置から見える論理的なボリュームである論理ユニット（LU）である。

図４は管理コンソール4の構成図である。41は管理コンソール4全体の制御を司る中央制御装置である。本実施形態では、中央制御装置41はプログラムで動作する装置であるとし、次のプログラム部位を備える。44はストレージ1のLU作成を指示し、また、ディスクレスPCごとに各LUのアクセス制限を設定し、また、各内部LUNと仮想LUNの対応付けを設定する制御を行うLU管理部である。

また42は操作者が管理コンソール4を操作するための入出力装置、43はストレージの各種設定のための通信を行う通信経路6を制御する通信制御回路、45ははファイバチャネル5eへの接続、制御を行うファイバチャネルI/F制御回路、46は管理コンソール4のOSやプログラムを格納する内蔵ディスクであるローカルディスクである。
○動作
次に本実施形態の動作を説明する。

(１) 内部LUNと仮想LUN
LU（Logical Unit）について説明する。LUはディスクレスPC等の上位計算機から見たときの論理的なボリュームである。上位計算機は1つのLUを１台の論理的なディスク装置として認識する。

ストレージ1は内部に複数のLUを構築できる。これを内部LUと呼ぶことにする。ストレージ1では内部LUを管理するため0から始まる整数でシリアル番号付けする。この番号を内部LUN（Logical Unit Number）と呼ぶ。

一方、本発明のクライアント計算機システムでは複数のディスクレスPCが１台のストレージを共用するため、ディスクレスPCそれぞれに専用のLUを割り当てる。一般にPC等の上位計算機はOSブート時に接続するストレージをサーチしてLUを検出するが、サーチ方法にいくつかの制約がある場合がある。それは、
(a) LUNは0から順にサーチする
(b) LUNは連続番号で存在することを仮定し、ある番号が存在しない場合以降のサーチは行わない
の２点である。これはサーチ時間を短縮するための工夫である。本発明のディスクレスPCもこのような特性をもつ上位計算機であると仮定すると、内部LUN=0以外をLU割り当てられたディスクレスPCはこのLUを検出できない。そこで、すべてのディスクレスPCに対し、1つ以上のLUを割り当てる際には、0から始まり、かつ連続番号でLUNを割り当てる必要がある。このディスクレスPCから見えるLUを仮想LU、その番号を仮想LUNと呼び、内部LUおよび内部LUNと区別する。これらの内部LUN、仮想LUNとの対応関係はストレージ1の中央制御装置11が備えるLUN管理テーブル14で管理する。
(2)ＬＵＮ管理テーブル
LUN管理テーブル14の一例を図５に示す。LUN管理テーブル14には所有上位計算機識別子と、ポート番号と、Target IDと仮想LUNと、内部LUNと、属性を格納する。

所有上位計算機識別子は、あるLUを所有する上位計算機を特定する情報を格納する。より具体的には、本実施形態のようにファイバチャネルでストレージと上位計算機を接続する場合には、ディスクレスPC2のファイバチャネルI/F接続回路22のWorld Wide Nameに基づくPort Nameと、ファイバチャネルの初期化により決定されたS - ID（Source-ID）の組み合わせで表現する。また、本実施形態では示さないが、SCSI（Small Computer Systems Interface）を上位計算機との接続I/Fとして用いた場合には、SCSI IDを格納する。

ポート番号は、ストレージ1が備えるファイバチャネル接続ポートの番号を格納する。本実施形態ではポート数は２個であるので、それぞれのディスクレスPC2が接続しているポートの番号を格納する。

TargetIDは、上位計算機との接続I/Fにおけるストレージ1の識別 IDを格納する。本実施形態のように接続I/Fがファイバチャネルの場合には、各ポート毎に唯一のD-ID（Destination-ID）しか備えないと決められているためポート番号により識別可能なので、本項は省略してもよいし、またはファイバチャネルの初期化時に決定したD-IDを格納しても良い。接続I/FがSCSIの場合には同一ポートに複数のIDを備えることができるので、そのときの各IDを格納する。

仮想LUNと内部LUNは、上位計算機に割り当てた内部LUNと各上位計算機から見える仮想LUNとの対応関係を示す。たとえば、ディスクレスPC0には内部LUN＝0、1の２つのLUを割り当てており、その仮想LUNはそれぞれ1、0である。

属性は、上位計算機による各LUの所有属性を示す。「専用」は１台の上位計算機が専有するLUであることを示す。「共用」は複数の上位計算機が共有するLUであることを示す。「特権」は「専用」と同義であるが、特別な管理状態にあり、この実施形態の場合、管理コンソール4によってのみ操作可能な状態であることを示す。「専用」との相違は、管理コンソール4がプログラム等を格納して使用するために作成したLUではない点である。
(3)ＬＵの作成
次に、管理コンソール4からストレージ1を制御してLU17を作成する手順について説明する。

管理者は管理コンソール4の入出力装置42によりLU管理部44を操作する。管理者はLU管理部44によりLUを作成する物理ディスク装置を選択する。ストレージ1が複数のディスク装置を備えているならば、そのうちの１つを選択する。また、RAID（Redundant Arrays of Inexpensive Disks）を構成するならば、複数のディスク装置を選択し、これらをグループ化して仮想的な１台の物理ディスク装置と扱う。

次に、選択した物理ディスク装置に作成するLUの容量を決定する。以上の設定情報を用い、管理者はLU管理部44を制御してストレージ1にLU作成命令を発行する。LU管理部44の命令に基づき、中央制御装置41は通信制御回路43を制御し通信経路6を介しストレージ1に設定情報を転送する。

ストレージ1の通信制御回路13はこれを受信し中央制御装置11に通知し、該装置11はLU定義部12により指定の物理ディスク装置に指定の容量のLUを作成する。LU定義部12はLUN管理テーブル14の内部LUNにこのLUを登録する。この時点では、属性は特権、その他の設定は未設定である。

LUの作成が成功すると、LU定義部12は通信制御回路13の制御の下、通信経路6により管理コンソール4にLU作成成功の報告を行う。

次にLUを所有する上位計算機の識別子を設定する。作成した内部LUN＝１であったとする。管理者はこのLUをディスクレスPC0のLUN＝0で登録するものとする。管理者はLU管理部44を操作し当該LUの所有上位計算機識別子＝ディスクレスPC0の World Wide Name、仮想LUN＝０、ポート番号＝０、属性＝専用を設定する。以降上記同様通信経路6を経由しこれらの設定値がストレージ1に転送され、LU定義部12はLUN管理テーブル14に設定する。これにより、以降クライアントPC0のみがこのLUを使用でき、他のディスクレスPCからは認識できないLUに設定できた。

なお、本実施形態ではファイバチャネルを用いているのでTargetIDは未使用であるとし、LUN管理テーブルの同項には便宜上0を格納してある。

以下、その他のLUも上記同様に作成、所有設定を行い、各ディスクレスPC用の専用LUを作成できる。１台のディスクレスPCが複数の専用LUを備えることも可能であり、図５に示すディスクレスPC2は２台の専用LUを備える例である。
(4) 共用LUの作成
上記では各ディスクレスPC専用のLUの作成について説明したが、同様に各ディスクレスPCによる共用LUを作成することもできる。上記専用LUの作成とはLUの属性を「共用」に設定することが異なる。また、各ディスクレスPCから１つのLUNとして認識できるように同じ内部LUが各ディスクレスPC毎に仮想LUNの定義がなされる。図５の例では、内部LUN＝０は共用LUとしてディスクレスPC0用の仮想LUN＝１、ディスクレスPC1用の仮想LUN＝１、ディスクレスPC2用の仮想LUN＝２として３回定義される。なお、ある上位計算機に共有を許さないことも可能である。LUN管理テーブル14で当該上位計算機に対し仮想LUNを定義しないだけで実現できる。
(5) アクセス制御
次にLUのアクセス制御について説明する。ディスクレスPC2が起動すると、次の２つのステップの初期化処理を行う。

第一のステップは、ファイバチャネルの初期化時に実施するポートログイン処理である。これはファイバチャネル上での接続を確立するために行う処理である。この処理により、ストレージ1のファイバチャネルI/F制御回路15は接続可能な各ディスクレスPCのPortNameとしてのWorld Wide NameとそのS-IDを獲得する。LUN定義部12は、LUN管理テーブルの所有上位計算機識別子として格納してある各クライアントPCのWorld Wide Nameと比較し、その対応するS-IDを登録する。以降はS- IDのみ上位計算機の識別に使用する。

第二のステップは、SCSIの初期化時に実施するLUサーチ処理である。ブートアップ制御回路221を備えるファイバチャネルI/F制御回路22は、ブートアップ可能なLUを検出するため、全てのストレージに対しLU有無の検査を行う。また、ブートアップ制御回路221を備えていない場合でも、OSがファイバチャネルI/Fの初期化処理の際に同様のサーチを行う。いずれの検査においてもSCSIの仕様で定められたInquiryコマンドを用い順番にLUNを変化させて検査を実施する。検出したLUは、ブートアップ制御回路221においてはブート可能なLUの１つとして、また、OSにおいては使用可能なLUの１つとして認識する。

ストレージ1のファイバチャネルI/F制御回路15は、１台のディスクレスPC2からInquiryコマンドを受信すると、その発行元S-IDと検査対象の仮想LUNをアクセス制御部16に通知する。アクセス制御部16は、LUN管理テーブル14を参照し、当該仮想LUNと当該上位計算機の関係を検査する。もしテーブル14に存在する組み合わせならばこの検査は有効であり、ディスクレスPC2にはInquiryコマンドの結果としてLUが存在することを示す情報が送信される。一方、この組み合わせがテーブル14に存在しないならば、このLUは当該ディスクレスPCからはアクセスが禁止されたLUであるから、No Device応答等、LUが存在しないことを示す情報が送信される。このような動作により、ディスクレスPC2のLU検査により、アクセスが許された内部LUのみが仮想LUNとして認識されることになり、その他の内部LUは認識されないので、アクセスのディスクレスPC毎の排他制御を実現できる。

以降、原則として同テーブル14で定義された関係によってのみアクセスが行われるが、例外的に上位計算機から範囲外のアクセスが発生する恐れがある。これを抑止するためには、全アクセス毎にS-IDと仮想LUNの関係を検査する必要があるが、上記の応用で実現可能である。

定義された正しい関係の元でのディスクレスPCからのLUアクセスが発行された場合には、アクセス制御部16は、指定されたRead、Write等のコマンド処理を実行する。
(6) 専用ＬＵにＯＳ、ＡＰＰを格納
次に本発明の最も基本的な使用方法を説明する。図５のLUN管理テーブル14の例に示したとおり、各ディスクレスPC2用にストレージ1に専用LUを作成し、それぞれのOSやアプリケーションやデータをすべて格納する方法である。なお、共用LUの使用方法については第二実施形態以降で説明する。

はじめにOSについて説明する。各ディスクレスPC2に割り当てた仮想LUN＝０にそれぞれのOSを格納する。ディスクレスPC2に電源を投入すると、上記(5)の通りファイバチャネルの初期化が実施され、そしてファイバチャネルI/F制御回路22は接続するLUを検査する。これにより専用LUが検出される。ついでブートアップ制御回路221はこの検出したLUを「ブートディスク」としてOSのブートアップを実行する。なお、検出したすべてのLUのうち、どのLUをブートディスクにするかは事前に指定が必要である。図５のLUN管理テーブル14の例では、ディスクレスPC０，１，２ともに仮想LUN＝０をブートディスクとして設定したとする。

ブートアップ制御回路221は、このLUをあたかも内蔵ディスク装置であるかのようにエミュレーションを行う。これにより、このLUにOSをインストールすることができ、かつ、ここからブートアップすることが可能になる。この制御のことをブートエミュレーションと呼ぶ。

また、それぞれのアプリケーションや、データをこのLUに格納し動作させることは、すでにこのLUが内蔵ディスク装置としてエミュレーションされているので実施できる。
(7)特権の利用
図５に示したとおり、作成した内部LUには「特権」の属性を与えることができる。特権の属性を設定すると一時的に上位計算機からのアクセスを抑止し管理コンソール4から操作を行うことができる。これを利用しLUの各種メンテナンスを行うことができる。

たとえば、バックアップ処理に利用することができる。バックアップ対象LUを一時ディスクレスPCからアクセス禁止し、このLUを管理コンソール4の配下に置く。管理コンソール4はこのLUを外部ディスク装置としてファイバチャネルI/F制御回路45を用い接続し、システム内に備えたバックアップ装置（図示せず）を用いバックアップ処理を行うことができる。

また、OSやアプリケーションのインストールにも用いることができる。たとえば、OSを新規にインストールし直す際には、管理コンソール4からプレインストール作業を実施できる。この処理により、各ディスクレスPCは次回起動した際に、各ディスクレスPCに固有なハードウェア情報や使用者の登録等の最低限の設定により新規の環境を使用可能になる。

また、OS、アプリケーションのバージョンアップにも用いることができる。管理コンソール4からこのLUに対しバージョンアップ処理を実行すれば、ディスクの内容は更新され、次回ディスクレスPC2から新バージョンのOS、アプリケーションをただちに使用可能になる。
(8)効果
以上のように、複数のディスクレスPC2が１台のストレージ1を共用し、その内部にそれぞれ専用のLUを作成することでそれぞれ固有のOS、アプリケーションを格納でき、そしてこれらプログラムを直接I/Oロードできる。また、それぞれのデータも同一ストレージに格納できる。

これにより、１台のストレージ1にOS、アプリケーション、データをすべて集約できるので、１人の管理者のもと、集中的にストレージのメンテナンスを実行することができ、運用管理コストを低減できるという効果がある。

また、共用ストレージにはディスクアレイ等、従来の内蔵ディスク装置に対し高速、大容量、高信頼なストレージを使用でき、性能、容量拡張性、信頼性のいずれをも向上させることができる。

特にプログラムを直接I/Oロードできるので、従来のNCシステムのような LAN、サーバのオーバヘッドが発生せず高速なプログラム起動を実現できるという効果がある。

また、各ディスクレスPCの処理を肩代わりするサーバは不要であり、クライアント計算機システム全体のコストを低減できるという効果がある。

（Ｂ）実施形態２
○構成
第二実施形態を説明する。本実施形態の構成は第一実施形態と同一である。ただし、本実施形態では第一実施形態で説明しなかった共用LUについて説明する。図５に従い、内部LU＝０が共用LUであるとして以下説明する。
○動作
(1) アプリケーションの共用
第一実施形態では、各ディスクレスPC2がそれぞれ専用のLUを確保し、OS、アプリケーション、データのすべてを格納するとして説明した。本実施形態では、アプリケーションを共用LUに格納する例を説明する。
(2) 共用アプリケーション設定情報
図７にディスクレスPC2と内部LUの関係を表す模式図を示す。共用LU170はディスクレスPC#0(2a)、ディスクレスPC#1(2b)から仮想LUN＝１として、ディスクレスPC#2(2c)から仮想LUN＝2として見える。
アプリケーションプログラムはディスクレスPC2のメモリにロードして実行し、また、プログラム自体を変更することがないので、複数ディスクレスPC2間での排他制御は不要であり、各ディスクレスPC2 # 0〜２（2a〜2c）は内部LU0を共用していることも認識しない。このような共用するアプリケーションのことを共用アプリケーションと呼ぶ。

共用アプリケーションを使用する際にも、各クライアントPC2毎の固有の設定情報が必要になる。この設定情報としては、使用ライセンス情報、個人情報、各種環境情報等がある。これらの情報は、各ディスクレスPC2用の専用LUに格納する。このように共用アプリケーションを構成することで、複数ユーザで共用しながらも各ユーザ毎に異なるアプリケーション環境を構築でき、また、不正使用の防止等にも配慮できる。

(3) 効果
第一実施形態のようにアプリケーションをそれぞれの専用LUに格納すると、インストールやバージョンアップ等のメンテナンスをすべてのLUに対して実施しなくてはならず、管理コストが上昇するが、本実施形態の共用アプリケーションを共用LUに格納する方法によれば、メンテナンスを一カ所に集約でき、メンテナンスに要する運用管理コストを低減できるという効果がある。

（Ｃ）実施形態３
○構成
第三実施形態を説明する。本実施形態も第二実施形態と同様、構成は第一実施形態と同じである。

第二実施例との相違点は、各ディスクレスPC用のOSも共用し、共用LUに格納する
ことである。第二実施形態と同様、図５に従い、内部LU＝０が共用LUであるとし
て以下説明する。

○動作
(1) OSの共用
一般にクライアント計算機システムでは、同一のOSを用いることが多い。そこで、このOSも共用LU170に格納し、複数のディスクレスPC2で共用することを考える。このようなOSを共用OSと呼ぶ。

(2)ブートアップ用仮想LUNの設定
図８に本実施形態のディスクレスPC2と内部LUの関係を表す模式図を示す。第二実施形態と同様、共用LU170はディスクレスPC#0(2a)、ディスクレスPC#1(2b)から仮想LUN＝１として、ディスクレスPC#2(2c)から仮想LUN＝2として見える。

共用OSは共用LU170に共用アプリケーションと同様に格納する。第二実施形態と異なるのは、ディスクレスPC2のブートアップ制御回路221に設定したブートLUがディスクレスPC #0(2a)、ディスクレスPC#1(2b)では仮想LUN＝１に、ディスクレスPC#2(2c)では仮想LUN＝２に設定することである。これにより、各ディスクレスPC2のブートアップ制御回路221は共用LU170を仮想ブートディスクとして制御し、OSを起動する。

(3)共用OS用設定情報
第二実施形態の共用アプリケーション用設定情報と同様、各ディスクレスPC2それぞれの設定情報が必要になる。設定情報としては、使用ライセンス情報、個人情報、各種環境情報等がある。これらは、共用アプリケーションと同様、各ディスクレスPC2毎に、対応する専用LUに共用OS設定情報として格納する。このように共用アプリケーションを構成することで、複数ユーザで共用しながらも各ユーザ毎に異なるアプリケーション環境を構築でき、また、不正使用の防止等にも配慮できる。

(4) 効果
第一、第二実施形態のようにOSをそれぞれの専用LUに格納すると、インストールやバージョンアップ等のメンテナンスをすべてのLUに対して実施しなくてはならず、管理コストが上昇するが、本実施形態の共用OSを共用LUに格納する方法によれば、メンテナンスを一カ所に集約でき、メンテナンスに要する運用管理コストをさらに低減できるという効果がある。

（Ｄ）第四実施形態
○構成
次に第四実施形態を説明する。本発明は図９に示すとおり第一実施形態のストレージ1の構成にキャッシュ18とLUキャッシュ常駐制御部19を設けたものである。

○動作
(1)共用LUの課題
動作を説明する。上記第二、第三実施形態で説明したとおり、共用LUに共用アプリケーションや共用OSを格納することで、管理コストを低減することができる。一方、ディスクレスPC2からのアクセスが同一LUに集中することになり、性能低下が発生するという新たな課題が発生する。そこで、この性能低下を解決する方法を提供する。

(2)キャッシュ
キャッシュ18は一般にDRAMで構成した回路であり、中央制御装置11の制御によりLUと上位計算機の中間に位置してアクセス高速化を実現する。リードアクセス要求発生した場合には、LUのデータのコピーがキャッシュ18に存在する場合（キャッシュヒット）にはディスクアクセスを行うことなくキャッシュ18から上位計算機にデータを転送することができる。また、ライトアクセス要求が発生した場合には、ディスクアクセスを行うことなくライトデータを一時保存しアクセスを終了することができる。このライトデータはいずれLUに書き戻す必要がある。この書き戻し処理のことを遅延ライトと呼ぶ。

(3)キャッシュ常駐制御部
キャッシュ常駐制御部19は、第二、第三実施形態の共用LUの全部もしくは一部のデータをキャッシュに格納するとともに、ひとたびキャッシュ18に格納したならば、常時キャッシュ上に当該データを保持し続けるようキャッシュ18を制御する。また、アクセス制御部16からアクセスのヒットミス判定要求があった際には、キャッシュを検査し、ヒット、ミスを判定する。

図１０は LUN管理テーブル14の構成図である。第一から第三実施形態のLUN管理テーブル14との相違点は、「キャッシュ属性」のフィールドを備えていることである。

第一実施形態と同様に、管理者は管理コンソール4からLUの定義・作成作業を行う際に、キャッシュ属性も指定する。同図においては共用アプリケーションや共用OSを格納する共用LU170（内部LUN＝０）に「常駐」属性を設定している。一方、その他の専用LUに対しては「通常」属性を設定している。

通常、キャッシュ制御にはLRU（Least Recent Use）方式が使用される。これはキャッシュ18上に存在するデータのうち、最も最近に使われなかったデータから順番に廃棄し、新しいデータを格納する方法である。これにより、少ないキャッシュ容量で効果的にキャッシュヒット率を向上させることができる。

一方、本実施形態のLUキャッシュ常駐は、LRUによらずに指定LUのデータに関しては、ひとたびキャッシュ18にデータを格納したならば、これを廃棄せずに保持し続ける方法である。このような制御を行うことで、たとえばディスクレスPC#0(2a)がある共用アプリケーションを使用した際に、キャッシュ18がこのアプリケーションを格納すると、次に他のディスクレスPC#1(2b)が同一の共用アプリケーションを使用する際に、かならずキャッシュヒットによる高速アクセスを実現できる。もし、LRU方式による制御を行うと、キャッシュ18にはディスクレスPC #0(2a)が使用したデータや、その他のアプリケーションが格納され、上記の共用アプリケーションはキャッシュ18上から廃棄されてしまう可能性がある。この場合、ディスクレスPC#1(2b)が同共用アプリケーションを使用するときに、再びキャッシュ18が格納し直すことになり、キャッシュが効果的に作用しないことになる。

上記の説明では、キャッシュ18には共用LUのデータのみを常駐指定するとして説明したが、キャッシュ容量が十分に確保できるときや、意図をもって特定のディスクレスPC2の高速化を特に図りたい際などには専用LUをキャッシュ指定することももちろん可能である。

(4)効果
本実施形態によれば、共用LUに格納する一部または全部の内容をキャッシュ常駐することができ、その結果、共用アプリケーションや共用OSをアクセス性能の高速なキャッシュ上に常駐することができるので、１台のディスクレスPC2がひとたび共用アプリケーションや共用OSを使用すると、それ以降には他のディスクレスPCが同一アプリケーションや同一OSを使用した際に非常に速いアクセス性能を得ることができるという効果がある。これにより、アプリケーション、OSの運用管理コストの低減に加え、高性能化をも実現することができるという効果がある。また、ディスク装置に比べ遥かに高速なキャッシュを活用するので、各PCが内蔵ディスク装置にOSやアプリケーションを格納するときのアクセス速度に比べ高速化できるという効果がある。

第一実施形態のクライアント計算機システムの構成図。 第一実施形態のディスクレスPCの構成図。 第一実施形態のストレージの構成図。 第一実施形態の管理コンソールの構成図。 第一実施形態のLUN管理テーブルの構成図。 第一実施形態のディスクレスPCとLUの関係を示す図。 第二実施形態のディスクレスPCとLUの関係を示す図。 第三実施形態のディスクレスPCとLUの関係を示す図。 第四実施形態のストレージの構成図。 第四実施形態のLUN管理テーブルの構成図。 従来の技術のNCシステムの構成図。

符号の説明

1…ストレージ
11…中央制御装置
12…LU定義部
13…通信制御回路
14…LUN管理テーブル
15…ファイバチャネルI/F制御回路
16…アクセス制御部
17...LU
18…キャッシュ
19…LUキャッシュ常駐制御部
2…ディスクレスPC
21…中央制御装置
22…ファイバチャネルI/F制御回路
23…入出力装置
221…ブートアップ制御回路
3…ファイバチャネル接続回路
4…管理コンソール
41…中央制御装置
42…入出力装置
43…通信制御回路
44…LU管理部
45…ファイバチャネルI/F制御回路
46…ローカルディスク
5…ファイバチャネル
6…通信経路

Claims (9)

1. 計算機システムであって、複数のクライアント計算機と、前記クライアント計算機により共用されるストレージと、前記ストレージを管理するための管理コンソールと、前記複数のクライアント計算機と前記ストレージと前記管理コンソールとを相互接続するための接続装置とからなることを特徴とする計算機システム。
2. 前記各クライアント計算機は、内蔵デイスクを備えないことを特徴とする請求項１に記載の計算機システム。
3. 前記クライアント計算機は前記ストレージに配置されたプログラムをロードして使用することを特徴とする請求項１に記載の計算機システム。
4. 前記クライアント計算機はブートアップ制御回路を備え、前記ストレージはオペレーティングシステム（OS)を格納し、前記ブートアップ制御回路は前記ストレージに格納されたOSをブートすることを特徴とする請求項１に記載の計算機システム。
5. 前記管理コンソールは、各クライアント計算機用の論理ボリュームを前記ストレージ内に作成するための制御部を備え、
   前記ストレージは、前記管理コンソールからの指令に従って各クライアント計算機用の論理ボリュームを作成する制御部と、各クライアント計算機から論理ボリュームへのアクセス制限情報を格納するための管理テーブルと、当該管理テーブルの情報に従ってクライアント計算機からのアクセスを許可するかを判定するアクセス制御部とを備えることを特徴とする請求項１に記載の計算機システム。
6. 前記管理コンソールは、少なくとも２台のクライアント計算機により共用される論理ボリュームを作成するための制御部を備え、
   前記ストレージは、管理コンソールからの指令に従って前記共用される論理ボリュームを作成する制御部と、クライアント計算機から共用される論理ボリュームへのアクセス制限情報を格納するための管理テーブルと、当該管理テーブルの情報に従ってクライアント計算機からのアクセスを許可するかを判定するアクセス制御部とを備えることを特徴とする請求項１に記載の計算機システム。
7. 前記共用される論理ボリュームにアプリケーションを格納し、各クライアント計算機が占有する論理ボリュームに前記アプリケーションを使用する場合に必要なクライアント計算機の固有情報を格納することを特徴とする請求項６に記載の計算機システム。
8. 前記共用される論理ボリュームにOSを格納し、各クライアント計算機が占有する論理ボリュームに前記OSを使用する場合に必要なクライアント計算機の固有情報を格納することを特徴とする請求項７に記載の計算機システム。
9. 前記ストレージは、前記アプリケーション及びOSの少なくとも一方を常駐させるためのキャッシュと、前記キャッシュを制御する制御部と、論理ボリュームに格納する内容の一部もしくは全部を前記キャッシュに常駐するように制御する制御部と、キャッシュに内容を常駐させる論理ボリュームを指定するための設定情報を格納するための管理テーブルとを備えることを特徴とする請求項８に記載の計算機システム。
   

Images