図面 (/)

技術 バックアップ制御プログラム、バックアップ制御方法、および情報処理装置

出願人 富士通株式会社
発明者 川本睦史
出願日 2012年3月14日 (8年8ヶ月経過) 出願番号 2012-057857
公開日 2013年9月26日 (7年1ヶ月経過) 公開番号 2013-191090
状態 特許登録済
技術分野 エラー時の再試行 計算機におけるファイル管理 マルチプログラミング 外部記憶装置との入出力 検索装置
主要キーワード 条件緩和 書き込み禁止モード 静止点 復帰コード 実ディスク バックアップ命令 実ハードウェア 論理ドメイン
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2013年9月26日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (13)

課題

所定の命令によるデータのバックアップが実行可能な条件を緩和する。

解決手段

バックアップ制御プログラムは、第1・第2の環境で実行される第1・第2のプログラムモジュールを含む。第2の環境では各実記憶装置が認識可能である。第1の記憶領域を利用するデータ利用プログラムのプロセスに第1の記憶領域に対する更新操作を一時的に停止させるための命令が、第1のプログラムモジュールにしたがって発行される。仮想記憶装置内で第1・第2の記憶領域を識別する情報が、第1のプログラムモジュールにしたがって、第2のプログラムモジュールのプロセスに対して通知される。実記憶装置内で第1・第2の記憶領域を識別する情報が、第2のプログラムモジュールにしたがって取得される。第1の記憶領域から第2の記憶領域にデータをバックアップするための命令が、取得された情報に基づいて、第2のプログラムモジュールにしたがって発行される。

概要

背景

近年は様々な仮想化技術が研究されている。ある種の仮想化技術によれば、物理的な資源を複数のプラットフォーム間共有することも可能である。
例えば、複数のコンピューティングプラットフォームで資源を共有するための、次のような方法が提案されている。当該方法は、共有ディスク記憶をサポートする目的で使用することができる。

当該方法によれば、各プラットフォームに設けられたファームウェアは、OS(Operating System)の実行時に利用可能なようにロードされる。共有資源は、プラットフォームで動作するOSに対し、ローカル資源として示される。実際には、共有資源は通常、他のプラットフォームによりホストされる。

オペレーティング資源アクセス要求は、要求するプラットフォームにより受信され、資源アクセス要求にサービスを提供するために用いられるターゲット資源を実際にホストする他のプラットフォームへと送られる。グローバル資源マップは、適切なホストプラットフォームを決定する目的で用いられる。

プラットフォーム間の通信は、OOB(Out-Of-Band)通信チャネルまたはネットワークを介して、可能になる。OOBチャネルを介したデータのルート変更を実現するために、隠し実行モードが実行される。それによって、当該方法は、プラットフォームで動作するOSに対し、トランスペアレントに実行される。

また、ある種の仮想化技術は、サーバ間の移行マイグレーション)を容易にする。サーバ間のライブマイグレーションについても様々な研究が行われている。
例えば、仮想サーバ同士が別々のSAN(Storage Area Network)環境にあるために、仮想サーバ間ストレージ装置ボリュームを共有することができない場合がある。このような場合でも仮想サーバのライブマイグレーションを可能とするために、次のような仮想計算機システムが提案されている。

移行元仮想サーバ移行先仮想サーバのそれぞれは、ボリューム割当て部と、ボリューム情報管理部と、識別部と、仮想OS移行部を有する。ボリューム割当て部は、管理OSが管理する論理ボリュームと、各仮想OSが管理する論理ボリュームとを割り当てる。ボリューム情報管理部は、論理ボリュームを識別するボリューム識別情報と、それぞれの管理OSが管理する論理ボリュームとを対応づけて管理する。識別部は、ボリューム識別情報に基づいて、移行元仮想サーバと移行先仮想サーバとが同一の論理ボリュームを対象論理ボリュームとして識別することを可能とする。

仮想OS移行部は、移行元仮想サーバの仮想OSが使用するメモリ領域内のデータを、移行先仮想サーバに移行する。仮想OS移行部はさらに、移行中更新されるメモリ領域内の更新データを、移行先仮想サーバに移行する。

以上例示したように、様々な仮想化技術が研究され、提案されている。しかし、仮想化されていない環境用に開発された技術の中には、そのままでは仮想環境で使用することができないものもある。仮想化されていない環境用に開発された技術を、仮想環境でも利用可能とするための研究の余地は、まだ残っている。

概要

所定の命令によるデータのバックアップが実行可能な条件を緩和する。バックアップ制御プログラムは、第1・第2の環境で実行される第1・第2のプログラムモジュールを含む。第2の環境では各実記憶装置が認識可能である。第1の記憶領域を利用するデータ利用プログラムのプロセスに第1の記憶領域に対する更新操作を一時的に停止させるための命令が、第1のプログラムモジュールにしたがって発行される。仮想記憶装置内で第1・第2の記憶領域を識別する情報が、第1のプログラムモジュールにしたがって、第2のプログラムモジュールのプロセスに対して通知される。実記憶装置内で第1・第2の記憶領域を識別する情報が、第2のプログラムモジュールにしたがって取得される。第1の記憶領域から第2の記憶領域にデータをバックアップするための命令が、取得された情報に基づいて、第2のプログラムモジュールにしたがって発行される。

目的

オペレーティング資源アクセス要求は、要求するプラットフォームにより受信され、資源アクセス要求にサービスを提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

コンピュータ上の第1の環境で実行される第1のプログラムモジュールと、前記コンピュータ上の環境であって、1つ以上の実記憶装置の各々を認識することが可能な第2の環境で実行される第2のプログラムモジュールとを含むバックアップ制御プログラムであって、前記コンピュータに、前記第1の環境上で動作し、かつ、バックアップ対象のデータが記憶されている第1の記憶領域を利用する、データ利用プログラムのプロセスに、前記第1の記憶領域に対する更新操作を一時的に停止させるための停止命令を、前記第1のプログラムモジュールにしたがって発行し、前記第1の環境において認識される1つ以上の仮想記憶装置内において前記第1の記憶領域を識別する第1の仮想識別情報と、前記データのバックアップ先である第2の記憶領域を前記1つ以上の仮想記憶装置内において識別する第2の仮想識別情報を、前記第2のプログラムモジュールのプロセスに対して、前記第1のプログラムモジュールにしたがって通知し、前記1つ以上の実記憶装置と前記1つ以上の仮想記憶装置との間の対応関係と、通知された前記第1の仮想識別情報とを用いて、前記1つ以上の実記憶装置内において前記第1の記憶領域を識別する第1の実識別情報を、前記第2のプログラムモジュールにしたがって取得し、前記対応関係と、通知された前記第2の仮想識別情報とを用いて、前記1つ以上の実記憶装置内において前記第2の記憶領域を識別する第2の実識別情報を、前記第2のプログラムモジュールにしたがって取得し、前記第1の記憶領域から前記第2の記憶領域に前記データをバックアップするためのバックアップ命令を、取得した前記第1の実識別情報と取得した前記第2の実識別情報に基づいて、前記第2のプログラムモジュールにしたがって発行することを含む処理を実行させるバックアップ制御プログラム。

請求項2

前記プログラムが前記コンピュータに実行させる前記処理が、前記1つ以上の実記憶装置のうち、前記第1の記憶領域または前記第2の記憶領域を有する実記憶装置を制御する制御装置から、前記バックアップ命令に対する応答を、前記第2のプログラムモジュールにしたがって受け取り、前記応答の内容を、前記第2のプログラムモジュールにしたがって、前記第1のプログラムモジュールのプロセスに対して通知し、前記応答が正常終了を示していれば、前記第1のプログラムモジュールにしたがって、前記停止命令を解除する解除命令を、前記データ利用プログラムの前記プロセスに対して発行することをさらに含むことを特徴とする請求項1に記載のバックアップ制御プログラム。

請求項3

前記第1の仮想識別情報と前記第2の仮想識別情報の通知は、ネットワークプロトコルにしたがって行われることを特徴とする請求項1または2に記載のバックアップ制御プログラム。

請求項4

コンピュータが、前記コンピュータ上の第1の環境上で動作し、かつ、バックアップ対象のデータが記憶されている第1の記憶領域を利用する、データ利用プログラムのプロセスに、前記第1の記憶領域に対する更新操作を一時的に停止させるための停止命令を、前記第1の環境で動作する第1の制御プログラムにしたがって発行し、前記コンピュータ上の環境であって、1つ以上の実記憶装置の各々を認識することが可能な第2の環境で動作する、第2の制御プログラムのプロセスに対して、前記第1の環境において認識される1つ以上の仮想記憶装置内において前記第1の記憶領域を識別する第1の仮想識別情報と、前記データのバックアップ先である第2の記憶領域を前記1つ以上の仮想記憶装置内において識別する第2の仮想識別情報を、前記第1の制御プログラムにしたがって通知し、前記1つ以上の実記憶装置と前記1つ以上の仮想記憶装置との間の対応関係と、通知された前記第1の仮想識別情報とを用いて、前記1つ以上の実記憶装置内において前記第1の記憶領域を識別する第1の実識別情報を、前記第2の制御プログラムにしたがって取得し、前記対応関係と、通知された前記第2の仮想識別情報とを用いて、前記1つ以上の実記憶装置内において前記第2の記憶領域を識別する第2の実識別情報を、前記第2の制御プログラムにしたがって取得し、前記第1の記憶領域から前記第2の記憶領域に前記データをバックアップするためのバックアップ命令を、取得した前記第1の実識別情報と取得した前記第2の実識別情報に基づいて、前記第2の制御プログラムにしたがって発行することを含むバックアップ制御方法

請求項5

第1の環境と、1つ以上の実記憶装置の各々を認識することが可能な第2の環境が構築された情報処理装置であって、前記第1の環境上で動作し、かつ、バックアップ対象のデータが記憶されている第1の記憶領域を利用する、データ利用プログラムのプロセスに対して、前記第1の記憶領域に対する更新操作を一時的に停止させるための停止命令を、前記第1の環境内から発行する停止命令発行部と、前記第1の環境において認識される1つ以上の仮想記憶装置内において前記第1の記憶領域を識別する第1の仮想識別情報と、前記データのバックアップ先である第2の記憶領域を前記1つ以上の仮想記憶装置内において識別する第2の仮想識別情報についての通知を、前記第1の環境内から発行する通知部と、前記通知を前記第2の環境において受け取り、前記1つ以上の実記憶装置と前記1つ以上の仮想記憶装置との間の対応関係と、通知された前記第1の仮想識別情報とを用いて、前記1つ以上の実記憶装置内において前記第1の記憶領域を識別する第1の実識別情報を取得し、前記対応関係と、通知された前記第2の仮想識別情報とを用いて、前記1つ以上の実記憶装置内において前記第2の記憶領域を識別する第2の実識別情報を取得する取得部と、前記第1の記憶領域から前記第2の記憶領域に前記データをバックアップするためのバックアップ命令を、取得された前記第1の実識別情報と取得された前記第2の実識別情報に基づいて、前記第2の環境内から発行するバックアップ命令発行部を備えることを特徴とする情報処理装置。

技術分野

0001

本発明はデータをバックアップする技術に関する。

背景技術

0002

近年は様々な仮想化技術が研究されている。ある種の仮想化技術によれば、物理的な資源を複数のプラットフォーム間共有することも可能である。
例えば、複数のコンピューティングプラットフォームで資源を共有するための、次のような方法が提案されている。当該方法は、共有ディスク記憶をサポートする目的で使用することができる。

0003

当該方法によれば、各プラットフォームに設けられたファームウェアは、OS(Operating System)の実行時に利用可能なようにロードされる。共有資源は、プラットフォームで動作するOSに対し、ローカル資源として示される。実際には、共有資源は通常、他のプラットフォームによりホストされる。

0004

オペレーティング資源アクセス要求は、要求するプラットフォームにより受信され、資源アクセス要求にサービスを提供するために用いられるターゲット資源を実際にホストする他のプラットフォームへと送られる。グローバル資源マップは、適切なホストプラットフォームを決定する目的で用いられる。

0005

プラットフォーム間の通信は、OOB(Out-Of-Band)通信チャネルまたはネットワークを介して、可能になる。OOBチャネルを介したデータのルート変更を実現するために、隠し実行モードが実行される。それによって、当該方法は、プラットフォームで動作するOSに対し、トランスペアレントに実行される。

0006

また、ある種の仮想化技術は、サーバ間の移行マイグレーション)を容易にする。サーバ間のライブマイグレーションについても様々な研究が行われている。
例えば、仮想サーバ同士が別々のSAN(Storage Area Network)環境にあるために、仮想サーバ間ストレージ装置ボリュームを共有することができない場合がある。このような場合でも仮想サーバのライブマイグレーションを可能とするために、次のような仮想計算機システムが提案されている。

0007

移行元仮想サーバ移行先仮想サーバのそれぞれは、ボリューム割当て部と、ボリューム情報管理部と、識別部と、仮想OS移行部を有する。ボリューム割当て部は、管理OSが管理する論理ボリュームと、各仮想OSが管理する論理ボリュームとを割り当てる。ボリューム情報管理部は、論理ボリュームを識別するボリューム識別情報と、それぞれの管理OSが管理する論理ボリュームとを対応づけて管理する。識別部は、ボリューム識別情報に基づいて、移行元仮想サーバと移行先仮想サーバとが同一の論理ボリュームを対象論理ボリュームとして識別することを可能とする。

0008

仮想OS移行部は、移行元仮想サーバの仮想OSが使用するメモリ領域内のデータを、移行先仮想サーバに移行する。仮想OS移行部はさらに、移行中更新されるメモリ領域内の更新データを、移行先仮想サーバに移行する。

0009

以上例示したように、様々な仮想化技術が研究され、提案されている。しかし、仮想化されていない環境用に開発された技術の中には、そのままでは仮想環境で使用することができないものもある。仮想化されていない環境用に開発された技術を、仮想環境でも利用可能とするための研究の余地は、まだ残っている。

先行技術

0010

特表2007−526527号公報
特開2009−140053号公報

発明が解決しようとする課題

0011

記憶媒体制御装置を含むストレージシステムは、第1の記憶領域から第2の記憶領域にデータをバックアップするためのバックアップ命令を、何らかのプロトコルにしたがってコンピュータから受け付ける。そして、ストレージシステムは、受け付けたバックアップ命令にしたがって、データをバックアップする。プロトコルによっては、第1と第2の記憶領域を指定する情報として、第1と第2の記憶領域を物理的に識別する情報しか使えないことがある。

0012

一方で、第1の記憶領域を物理的に識別する情報は、常に利用可能だとは限らない。例えば、物理コンピュータ上のある環境内では、第1の記憶領域を物理的に識別する情報ではなく、当該環境内で第1の記憶領域を仮想的に識別する情報が使われるかもしれない。そして、第1の記憶領域のデータを利用するデータ利用プログラムが、そのような環境において実行されるかもしれない。

0013

この場合、バックアップ命令は、上記環境中のデータ利用プログラムのプロセスからではなく、第1と第2の記憶領域を物理的に識別する情報を認識することの可能な他の環境で実行される他のプログラムのプロセスから、発行されてもよい。しかし、データ利用プログラムによる動作と独立して任意にバックアップ命令が発行されると、バックアップ処理の実行中にデータが更新されるおそれがあり、その結果として、データの整合性が保たれないおそれがある。

0014

そこで、データの整合性を保つために、バックアップ命令の発行は、データ利用プログラムにしたがって行われる第1の記憶領域へのアクセス制約または監視するための処理をともなっていてもよい。

0015

ところが、データ利用プログラムが実行される環境の外部から、上記のような制約または監視を受けるためのインタフェイスは、データ利用プログラムに必ず備わっているとは限らない。つまり、バックアップ命令にしたがったデータのバックアップは、無条件に実行可能(feasible)な訳ではない。データ利用プログラムが実行される環境や、データ利用プログラムのインタフェイスによっては、データの整合性を保ちつつバックアップ命令を利用してデータをバックアップすることができない可能性がある。

0016

本発明は、1つの側面では、所定の命令にしたがったデータのバックアップが実行可能な条件を緩和することを目的とする。

課題を解決するための手段

0017

一態様によるバックアップ制御プログラムは、第1のプログラムモジュールと第2のプログラムモジュールとを含む。前記第1のプログラムモジュールは、コンピュータ上の第1の環境で実行される。また、前記コンピュータ上の環境であって、1つ以上の実記憶装置の各々を認識することが可能な第2の環境で、前記第2のプログラムモジュールが実行される。

0018

前記バックアップ制御プログラムが前記コンピュータに実行させる処理は、停止命令を前記第1のプログラムモジュールにしたがって発行することを含む。前記停止命令は、前記第1の環境上で動作し、かつ、バックアップ対象のデータが記憶されている第1の記憶領域を利用する、データ利用プログラムのプロセスに、前記第1の記憶領域に対する更新操作を一時的に停止させるための命令である。

0019

前記バックアップ制御プログラムが前記コンピュータに実行させる前記処理は、第1の仮想識別情報と第2の仮想識別情報を、前記第2のプログラムモジュールのプロセスに対して、前記第1のプログラムモジュールにしたがって通知することを含む。前記第1の仮想識別情報は、前記第1の環境において認識される1つ以上の仮想記憶装置内において前記第1の記憶領域を識別する情報である。前記第2の仮想識別情報は、前記データのバックアップ先である第2の記憶領域を前記1つ以上の仮想記憶装置内において識別する情報である。

0020

前記バックアップ制御プログラムが前記コンピュータに実行させる前記処理は、前記1つ以上の実記憶装置内において前記第1の記憶領域を識別する第1の実識別情報を取得することを含む。前記第1の実識別情報は、前記1つ以上の実記憶装置と前記1つ以上の仮想記憶装置との間の対応関係と、通知された前記第1の仮想識別情報とを用いて、前記第2のプログラムモジュールにしたがって取得される。

0021

前記バックアップ制御プログラムが前記コンピュータに実行させる前記処理は、前記1つ以上の実記憶装置内において前記第2の記憶領域を識別する第2の実識別情報を取得することを含む。前記第2の実識別情報は、前記対応関係と、通知された前記第2の仮想識別情報とを用いて、前記第2のプログラムモジュールにしたがって取得される。

0022

前記バックアップ制御プログラムが前記コンピュータに実行させる前記処理は、バックアップ命令を前記第2のプログラムモジュールにしたがって発行することを含む。前記バックアップ命令は、前記第1の記憶領域から前記第2の記憶領域に前記データをバックアップするための命令である。前記バックアップ命令は、取得した前記第1の実識別情報と取得した前記第2の実識別情報に基づいて発行される。

発明の効果

0023

上記のバックアップ制御プログラムによれば、バックアップ命令のような所定の命令にしたがったデータのバックアップが実行可能な条件が緩和される。

図面の簡単な説明

0024

第1実施形態のブロック図である。
第1実施形態におけるバックアップ制御シーケンス図である。
第1比較例を説明する図である。
第2比較例を説明する図である。
第2実施形態のブロック図である。
ステムハードウェア構成図である。
バックアップ制御処理フローチャートである。
処理に使われる値の例を示す図である。
仮想パーティション仮想ディスクと実パーティション実ディスクの例を説明する図である。
物理領域情報を取得する処理のフローチャートである。
デバイス領域情報を取得する処理のフローチャートである。
ストレージシステムにデータのコピーを指示する処理のフローチャートである。

実施例

0025

以下、実施形態について、図面を参照しながら詳細に説明する。具体的には、図1〜2を参照して第1実施形態についてまず説明する。次に、図3〜4を参照して第1〜第2比較例について説明する。その後、図5〜12を参照して第2実施形態について説明する。最後に、その他の変形例についても説明する。

0026

図1は、第1実施形態のブロック図である。図1には、コンピュータ100と、仮想記憶装置110と、実記憶装置120が図示されている。
図1では仮想記憶装置110が1つのブロックで示されているが、仮想記憶装置110の数は1でもよいし、2以上でもよい。同様に、図1では実記憶装置120が1つのブロックで示されているが、実記憶装置120の数は1でもよいし、2以上でもよい。

0027

例えば、各実記憶装置120が実ディスクであってもよい。その場合、各仮想記憶装置110は仮想ディスクである。
各実記憶装置120は、コンピュータ100にDAS(Direct Attached Storage)として接続された通常のHDD(Hard Disk Drive)のディスクであってもよい。あるいは、各実記憶装置120は、RAID(Redundant Array of Independent DisksまたはRedundant Array of Inexpensive Disksの略)システムにおいて、外部からは1台の実ディスクドライブとして認識される、1つの論理ユニットであってもよい。

0028

RAIDシステムは、例えばSANなどのネットワークを介してコンピュータ100に接続されていてもよい。また、RAIDコントローラと複数の磁気ディスク媒体とを含む1つのRAIDシステムの全体が、1つのシャーシに収められた1つの装置として提供されてもよい。

0029

RAIDシステムが使われる場合、RAIDレベルは任意である。例えば、RAID0、RAID1、RAID5、RAID0+1、RAID1+0、RAID0+5、RAID5+0などのレベルが利用可能である。

0030

以上例示したような、通常のHDDとRAIDシステムは、どちらも、記憶媒体(例えば磁気ディスク媒体)だけでなく、制御装置(例えばHDD内の制御回路またはRAIDシステムにおけるRAIDコントローラ)を含む。HDDやRAIDシステムは、コンピュータ100から命令を受け取り、受け取った命令に応じて、制御装置による制御のもとで動作する。

0031

また、コンピュータ100上には、第1の環境101と第2の環境102が構築されている。第2の環境102においては、1つ以上の実記憶装置120の各々を認識することが可能である。具体的には、例えば以下の(1a)や(1b)のような場合があり得る。

0032

(1a)第1の環境101がハイパーバイザ上で動作する第1の仮想マシンであり、第2の環境102がハイパーバイザ上で動作する第2の仮想マシンである場合。
(1b)第1の環境101が、第2の環境102上または第2の環境102内に構築された環境である場合。

0033

上記の(1a)と(1b)のいずれの場合においても、第1の環境101においては、1つ以上の実記憶装置120は認識されなくてもよく、代わりに、1つ以上の仮想記憶装置110が認識されてもよい。

0034

ところで、1つ以上の仮想記憶装置110のいずれかに含まれる記憶領域へのアクセスは、物理的には、いずれかの実記憶装置120上に割り当てられている当該記憶領域へのアクセスにより、実現される。

0035

例えば、1つ以上の仮想記憶装置110のいずれかに含まれる第1の記憶領域111として、物理的には、1つ以上の実記憶装置120のいずれかに含まれる第1の記憶領域121が使われる。したがって、仮想記憶装置110上の第1の記憶領域111へのアクセスは、物理的には実記憶装置120上の第1の記憶領域121へのアクセスによって、実現される。換言すれば、「111」と「121」という参照符号は、どちらも、物理的には同じ第1の記憶領域を指す。

0036

同様に、1つ以上の仮想記憶装置110のいずれかに含まれる第2の記憶領域112として、物理的には、1つ以上の実記憶装置120のいずれかに含まれる第2の記憶領域122が使われる。したがって、仮想記憶装置110上の第2の記憶領域112へのアクセスは、物理的には実記憶装置120上の第2の記憶領域122へのアクセスによって、実現される。換言すれば、「112」と「122」という参照符号は、どちらも、物理的には同じ第2の記憶領域を指す。

0037

例えば(1a)の場合に、上記のとおり第1の仮想マシンは、1つ以上の実記憶装置120を認識しなくてもよい。この場合、第1の仮想マシンから仮想記憶装置110へのアクセスを実現するための実記憶装置120へのアクセスは、第2の仮想マシンのデバイスドライバを介して行われてもよい。

0038

(1a)の場合、より具体的には、第1の環境101は、例えばXenハイパーバイザ上の「ドメインU」であってもよく、第2の環境102は、Xenハイパーバイザ上の「ドメイン0」であってもよい(Xenは登録商標)。仮想記憶装置110上の記憶領域へのドメインUからのアクセスは、物理的には実記憶装置120上の記憶領域へのアクセスとして実現される。そして、実記憶装置120上の記憶領域へのアクセスは、ドメイン0のデバイスドライバを介して行われる。

0039

もちろん、第1の環境101と第2の環境102は、Xen以外の他のハイパーバイザ上の仮想マシンであってもよい。ハイパーバイザ上で提供される環境は、「ドメイン」、「論理ドメイン」、「パーティション」など様々な名前で呼ばれる。また、例えば上記の(1b)の場合のように、ハイパーバイザ以外の仮想化技術により、コンピュータ100内に第1の環境101と第2の環境102が構築されていてもよい。

0040

また、上記のとおり、(1b)の場合も、1つ以上の仮想記憶装置110のいずれかに含まれる記憶領域への第1の環境101内からのアクセスは、物理的には、いずれかの実記憶装置120上に割り当てられている当該記憶領域へのアクセスにより、実現される。実記憶装置120へのアクセスは、上記(1b)の場合には、第2の環境102を提供するOSを介して行われてもよい。

0041

上記(1b)の場合のより具体的な例として、例えば以下の(2a)〜(2c)のような場合があり得る。

0042

(2a)第1の環境101が、ホストOS上で動作する仮想マシンであり、第2の環境102が、ホストOSが提供する環境(つまり仮想マシンより下のレイヤの環境)である場合。ホストOS上で仮想マシンを実行する技術として、例えば、VMware Playerなどの製品が知られている(VMwareは登録商標)。
(2b)第1の環境101が、第2の環境102内に含まれる実行環境(runtime environment)である場合。例えば、第1の環境101がSolarisコンテナ非大ゾーン(non-global zone)であり、第2の環境102がSolarisコンテナの大域ゾーン(global zone)である場合(Solarisは登録商標)。
(2c)第2の環境102が、ホストOSにより提供される環境であり、当該ホストOSのカーネルにはKVM(Kernel-based Virtual Machine)用のモジュールが組み込まれている場合。この場合、第1の環境101は、ゲストOSが提供する環境である。

0043

もちろん、コンピュータ100上に第1の環境101と第2の環境102を構築するための仮想化技術は、上記の仮想化技術の例には限られない。
また、図1では図示の便宜上、第1の環境101が第2の環境102の左に描かれているが、上記(1b)のとおり、第1の環境101は、第2の環境102上に構築されていてもよいし、第2の環境102内に構築されていてもよい。

0044

さて、第1実施形態のバックアップ制御プログラム103は、第1の環境101と第2の環境102が構築されたコンピュータ100により実行されるプログラムである。バックアップ制御プログラム103は、第1の環境101で実行される第1のプログラムモジュール104と、第2の環境102で実行される第2のプログラムモジュール105を含む。換言すれば、第1のプログラムモジュール104は、第1の環境101で動作する第1の制御プログラムであり、第2のプログラムモジュール105は、第2の環境102で動作する第2の制御プログラムである。

0045

図1に示すように、第1の環境101上では、第1のプログラムモジュール104だけでなく、データ利用プログラム106も動作する。データ利用プログラム106は、例えば、DBMS(Database Management System)のプログラムであってもよい。

0046

データ利用プログラム106は、仮想記憶装置110内の第1の記憶領域111を利用するプログラムである。上記のとおり、第1の記憶領域111は物理的には第1の記憶領域121であるから、第1の記憶領域121内のデータが、データ利用プログラム106にしたがってアクセスされることになる。

0047

ここで、第1の記憶領域111に記憶されているデータを第2の記憶領域112へバックアップすることを、ユーザ(例えば、コンピュータ100のアドミニストレータ)が望んだとする。

0048

上記のとおり、各実記憶装置120は、例えば、ディスクであってもよい。この場合、各仮想記憶装置110は仮想ディスクである。
仮想ディスクの数は2以上でもよく、すなわち、少なくとも第1と第2の仮想記憶装置110があってもよい。そして、第1の記憶領域111は第1の仮想記憶装置110上の1つのパーティションであってもよく、第2の記憶領域112は第2の仮想記憶装置110上の1つのパーティションであってもよい。

0049

第1の仮想記憶装置110用に、いずれかの実記憶装置120上の1つのパーティションが割り当てられていてもよい。同様に、第2の仮想記憶装置110用に、いずれかの実記憶装置120上の1つのパーティションが割り当てられていてもよい。

0050

これら2つの実パーティションは、同じ実ディスクに含まれていてもよい。しかし、より安全にデータを保護するためには、これら2つの実パーティションは違う実ディスクにあることが好ましい。

0051

つまり、より安全にデータを保護するためには、第1の記憶領域111に対応する第1の記憶領域121を含む実ディスクと、第2の記憶領域112に対応する第2の記憶領域122を含む実ディスクは、異なることが好ましい。なお、第1の記憶領域121を含む実ディスクと第2の記憶領域122を含む実ディスクは、同じ1台の装置(例えば、1つのシャーシに収容された1つのRAIDシステム)に含まれていてもよいし、2台の装置に分かれて存在していてもよい。

0052

バックアップ制御プログラム103は、第1の記憶領域111から第2の記憶領域112へのデータのバックアップ(換言すれば第1の記憶領域121から第2の記憶領域122へのデータのバックアップ)を制御するためのプログラムである。具体的には、コンピュータ100は、第1のプログラムモジュール104と第2のプログラムモジュール105にしたがって以下のように動作する。

0053

コンピュータ100は、第1のプログラムモジュール104にしたがって停止命令を発行する。停止命令は、データ利用プログラム106のプロセスに、第1の記憶領域111(つまりバックアップ対象のデータが記憶されている領域)に対する更新操作を一時的に停止させるための命令である。更新操作は、具体的には、新たなデータを追加する操作、既存のデータを削除する操作、既存のデータを書き換える操作などを含む。

0054

ここで、第1のプログラムモジュール104のプロセスと、データ利用プログラム106のプロセスは、同じ第1の環境101内のプロセス同士である。よって、停止命令の発行と受領は、第1の環境101内でのプロセス間通信のためのインタフェイス(例えば、第1の環境101内で使われるAPI(Application Programming Interface)など)を介して行われてもよい。

0055

コンピュータ100はさらに、第1のプログラムモジュール104にしたがって、第2のプログラムモジュール105のプロセスに対して、下記(3a)と(3b)の情報を通知する。

0056

(3a)第1の環境101において認識される1つ以上の仮想記憶装置110内において、第1の記憶領域111を識別する、第1の仮想識別情報。
(3b)第1の環境101において認識される1つ以上の仮想記憶装置110内において、第2の記憶領域112(つまりデータのバックアップ先)を識別する、第2の仮想識別情報。

0057

第1の仮想識別情報は、例えば、第1の記憶領域111を含む1つの仮想記憶装置110を、1つ以上の仮想記憶装置110の中で識別する情報と、当該1つの仮想記憶装置110内での第1の記憶領域111の位置を表す情報を含んでいてもよい。同様に、第2の仮想識別情報は、第2の記憶領域112を含む1つの仮想記憶装置110を、1つ以上の仮想記憶装置110の中で識別する情報と、当該1つの仮想記憶装置110内での第2の記憶領域112の位置を表す情報を含んでいてもよい。

0058

仮想記憶装置110内での記憶領域の位置を表す情報は、より具体的には、当該記憶領域の開始アドレスを含んでいてもよい。例えば、開始アドレスとサイズの組み合わせ、または、開始アドレスと終了アドレスの組み合わせが、記憶領域の位置を表す情報として使われてもよい。

0059

第1の仮想識別情報と第2の仮想識別情報の通知は、異なる環境間の通知(具体的には、第1の環境101内から第2の環境102内への通知)である。よって、第1の仮想識別情報と第2の仮想識別情報の通知は、ネットワークプロトコルにしたがって行われてもよい。ネットワークプロトコルとしては、例えば、TCP/IP(Transmission Control Protocol/Internet Protocol)が使われてもよいが、他のプロトコルが使われてもよい。

0060

コンピュータ100は、続いて、第2のプログラムモジュール105にしたがって、下記(4a)と(4b)の情報を取得する。

0061

(4a)1つ以上の実記憶装置120内において、第1の記憶領域121(すなわち第1の記憶領域111用に割り当てられている領域)を識別する、第1の実識別情報。
(4b)1つ以上の実記憶装置120内において、第2の記憶領域122(すなわち第2の記憶領域112用に割り当てられている領域)を識別する、第2の実識別情報。

0062

具体的には、コンピュータ100は、1つ以上の実記憶装置120と1つ以上の仮想記憶装置110との間の対応関係と、通知された(3a)の第1の仮想識別情報とを用いて、(4a)の第1の実識別情報を取得する。同様に、コンピュータ100は、1つ以上の実記憶装置120と1つ以上の仮想記憶装置110との間の対応関係と、通知された(3b)の第2の仮想識別情報とを用いて、(4b)の第2の実識別情報を取得する。

0063

ここで、第2のプログラムモジュール105は、1つ以上の実記憶装置120を認識することの可能な第2の環境102内で実行される。そして、第2の環境102内においては、より具体的には、各仮想記憶装置110がどの実記憶装置120に対応するのかを認識することが可能である。よって、コンピュータ100は、第2のプログラムモジュール105にしたがって、上記対応関係を用いて、(4a)と(4b)の情報を取得することができる。

0064

なお、第1の実識別情報は、例えば、第1の記憶領域121を含む1つの実記憶装置120を、1つ以上の実記憶装置120の中で識別する情報と、当該1つの実記憶装置120内での第1の記憶領域121の位置を表す情報を含んでいてもよい。同様に、第2の実識別情報は、第2の記憶領域122を含む1つの実記憶装置120を、1つ以上の実記憶装置120の中で識別する情報と、当該1つの実記憶装置120内での第2の記憶領域122の位置を表す情報を含んでいてもよい。

0065

実記憶装置120内での記憶領域の位置を表す情報は、より具体的には、当該記憶領域の開始アドレスを含んでいてもよい。例えば、開始アドレスとサイズの組み合わせ、または、開始アドレスと終了アドレスの組み合わせが、記憶領域の位置を表す情報として使われてもよい。

0066

コンピュータ100は、続いて、第2のプログラムモジュール105にしたがって、バックアップ命令を発行する。バックアップ命令は、第1の記憶領域121から第2の記憶領域122にデータをバックアップするための命令である。

0067

バックアップ命令の形式に応じて、バックアップ命令は、第1の記憶領域121を含む装置(例えばRAIDシステムまたはHDD)に対して発行されてもよいし、第2の記憶領域122を含む装置に対して発行されてもよい。なお、第1の記憶領域121と第2の記憶領域122が、同じ1つの装置(例えば同じ1つのRAIDシステムまたは同じ1つのHDD)に含まれる場合もあり得る。

0068

具体的には、コンピュータ100は、取得した第1の実識別情報と取得した第2の実識別情報を用いて、バックアップ命令を発行する。例えば、第1の実識別情報と第2の実識別情報そのものまたはその一部(例えば、位置を表す情報)が、バックアップ命令のパラメタとして使われてもよい。第1の実識別情報と第2の実識別情報から得られる他の情報(例えば、実識別情報よりもさらに物理的なレベルにおいて実記憶装置120に割り当てられている識別番号など)が、バックアップ命令のパラメタとして使われてもよい。第1の実識別情報と第2の実識別情報は、さらに、バックアップ命令の宛先を決めるために用いられてもよい。

0069

バックアップ命令などの各種の命令は、特定のプロトコル(例えばSCSI(Small Computer System Interface)プロトコル)にしたがった形式を持つ。しかし、プロトコルの種類によっては、仮想識別情報がバックアップ命令のパラメタとして使えないことがある。例えば、バックアップ命令が具体的にはSCSIコマンドである場合、パラメタとしては、実識別情報(または、実識別情報から得られる、より低レベルの情報)が使われる。

0070

仮想識別情報がバックアップ命令のパラメタとして使えない場合にも、上記のバックアップ制御プログラム103によれば、データのバックアップが可能である。つまり、コンピュータ100は、第1の実識別情報と第2の実識別情報を用いることによって、適切なバックアップ命令を発行することができる。

0071

バックアップ命令の発行後、コンピュータ100は、バックアップ命令に対する応答を、第2のプログラムモジュール105にしたがって待ち、応答を受信する。バックアップ命令に対する応答は、具体的には、1つ以上の実記憶装置120のうち、第1の記憶領域121または第2の記憶領域122を有する実記憶装置120を制御する制御装置から返される。制御装置の具体例は、RAIDシステム内のRAIDコントローラや、HDD内のコントローラなどである。

0072

コンピュータ100は、受け取った応答の内容を、第2のプログラムモジュール105にしたがって、第1のプログラムモジュール104のプロセスに対して通知してもよい。例えば、応答は、バックアップのための処理が正常に終了したか否かを示す結果情報を含んでいてもよく、結果情報が第1のプログラムモジュール104のプロセスに通知されてもよい。

0073

また、受け取った応答が正常終了を示していれば、コンピュータ100は、第1のプログラムモジュール104にしたがって、停止命令を解除する解除命令を、データ利用プログラム106のプロセスに対して発行してもよい。解除命令の受領に応じて、データ利用プログラム106のプロセスは、第1の記憶領域111に対する更新操作を再開する。

0074

以上説明したように、コンピュータ100は、第1のプログラムモジュール104と第2のプログラムモジュール105を含むバックアップ制御プログラム103にしたがって動作する。そして、コンピュータ100がバックアップ制御プログラム103にしたがって動作することにより、バックアップ命令にしたがったデータのバックアップが実行可能な条件は緩和される。具体的には、下記(5a)〜(5c)の3つの観点から、条件は緩和される。

0075

(5a)バックアップ命令のパラメタとして使える情報の種類は何か、という観点。
(5a)データ利用プログラム106のプロセスが、第1の環境101の内部からしか停止命令を受け付けることができないのか、それとも第1の環境101の外部からも停止命令を受け付けることができるのか、という観点。
(5c)第1の環境101内で、各実記憶装置120を認識することができるか否か、という観点。

0076

これら3つの観点からの条件緩和と、その理由についてまとめれば、下記のとおりである。
バックアップ命令のパラメタとして仮想識別情報が使えなくても、バックアップ命令を使ったデータのバックアップが可能である。なぜなら、コンピュータ100は、第1の実識別情報と第2の実識別情報を取得し、取得した第1の実識別情報と第2の実識別情報に基づいてバックアップ命令のパラメタを決定し、バックアップ命令を発行するからである。

0077

データ利用プログラム106のプロセスが、第1の環境101内からしか停止命令を受け付けることができなくても、バックアップ命令を使ったデータのバックアップが可能である。なぜなら、第1の環境101内で実行される第1のプログラムモジュール104にしたがって、停止命令が発行される(すなわち、第1のプログラムモジュール104のプロセスから停止命令が発行される)からである。

0078

第1の環境101内では各実記憶装置120を認識することができなくても、バックアップ命令を使ったデータのバックアップが可能である。なぜなら、バックアップ制御プログラム103は、第1の環境101内で実行される第1のプログラムモジュール104だけでなく、各実記憶装置120を認識することが可能な第2の環境102内で実行される第2のプログラムモジュール105も含むからである。そして、第1のプログラムモジュール104のプロセスと第2のプログラムモジュール105のプロセスの間で情報が送受信されるからである。

0079

続いて、第1実施形態におけるバックアップ制御の例について、図2のシーケンス図を参照して説明する。
テップS101で、第1の記憶領域111中のデータを第2の記憶領域112にバックアップする処理を開始するきっかけとなる、何らかのイベントが発生する。例えば、ステップS101では、下記(6a)または(6b)のようなイベントが発生する。

0080

(6a)予めスケジュールされていた日時になった、というイベント。
(6b)ユーザが、バックアップ処理の開始を命じる入力を、入力装置を介して与えた、というイベント。

0081

すると、ステップS102でコンピュータ100は、第1のプログラムモジュール104にしたがって、停止命令を発行する。換言すれば、第1のプログラムモジュール104のプロセスが停止命令を発行する。上記のとおり、停止命令は、データ利用プログラム106のプロセスに、第1の記憶領域111に対する更新操作を一時的に停止させるための命令である。

0082

そして、ステップS103でコンピュータ100は、データ利用プログラム106にしたがって、第1の記憶領域111に対する更新操作を一時的に停止するための制御を行う。換言すれば、データ利用プログラム106のプロセスが、第1の記憶領域111に対する更新操作を一時的に停止するための制御を行う。

0083

例えば、データ利用プログラム106が、第1の記憶領域111上のデータベース(DB)を利用するDBMSプログラムである場合、ステップS103では、例えば以下の(7a)〜(7c)のような処理が行われてもよい。(7a)〜(7c)の処理は、データの静止点(quiescent point)を作成するための処理の例である。

0084

(7a)実行途中トランザクションがある場合、実行途中の各トランザクションを、最後まで実行してコミットするか、または、強制的にロールバックする処理。
(7b)第1の記憶領域111用のディスクキャッシュとして使われるメモリ上の領域に記憶されているデータを、第1の記憶領域111へ書き出す(つまりフラッシュ(flush)する)処理。
(7c)DBMSの動作モードを書き込み禁止モードに変更する処理。

0085

なお、書き込み禁止モードは、具体的には、新たな書き込みアクセス要求を受け付けた場合に、要求に応じた書き込みアクセスはしないで、要求の内容をキューに記憶するモードであってもよい。あるいは、書き込み禁止モードは、新たな書き込みアクセス要求を受け付けた場合に、要求に応じた結果を、第1の記憶領域111へは書き込まずに、他の記憶領域に書き込むモードであってもよい。例えば、他の記憶領域は、第1の記憶領域111用のディスクキャッシュとして使われるメモリ上の領域であってもよいし、第1の記憶領域111とは別の、ディスク上の記憶領域であってもよい。

0086

ステップS103の制御が完了すると、ステップS104において、データ利用プログラム106のプロセスから第1のプログラムモジュール104のプロセスへと完了通知が送られる。つまり、コンピュータ100はデータ利用プログラム106にしたがって完了通知を送り、第1のプログラムモジュール104にしたがって完了通知を受け取る。

0087

そして、ステップS105でコンピュータ100は、第1のプログラムモジュール104にしたがって、第2のプログラムモジュール105のプロセスに対して、上記(3a)の第1の仮想識別情報と上記(3b)の第2の仮想識別情報を通知する。換言すれば、第1のプログラムモジュール104のプロセスが、上記(3a)と(3b)の情報を、第2のプログラムモジュール105のプロセスに通知する。

0088

次のステップS106では、コンピュータ100は、第2のプログラムモジュール105にしたがって、上記(4a)の第1の実識別情報と上記(4b)の第2の実識別情報を取得する。換言すれば、第2のプログラムモジュール105のプロセスが、上記(4a)と(4b)の情報を取得する。

0089

さらに、ステップS107でコンピュータ100は、第2のプログラムモジュール105にしたがって、バックアップ命令を発行する。換言すれば、第2のプログラムモジュール105のプロセスが、バックアップ命令を発行する。

0090

上記のとおり、バックアップ命令は、第1の記憶領域121を含む装置(例えばRAIDシステムまたはHDD)に対して発行されてもよい。あるいは、バックアップ命令は、第2の記憶領域122を含む装置に対して発行されてもよい。

0091

図2には、バックアップ命令の宛先の装置内の制御装置123(具体的には、例えば、RAIDシステムにおけるRAIDコントローラ、あるいは、HDDにおける制御回路など)が図示されている。制御装置123は、受信した命令(例えば、バックアップ命令、リード命令ライト命令など)に応じた制御を行い、命令に対して応答を返す。

0092

具体的には、ステップS108では、制御装置123は、バックアップ命令にしたがった制御を行う。ステップS108での制御は、例えば、第1の記憶領域121のスナップショットを作成する処理を含んでもよい。

0093

第1の記憶領域121が比較的大きい場合、第1の記憶領域121全体を第2の記憶領域122に実際にバックアップするには、ある程度長い時間がかかる。しかし、スナップショットを作成するのにかかる時間はわずかである。よって、ステップS108の制御はすぐに完了する。

0094

なお、スナップショットの作成後、制御装置123は、第1の記憶領域121から第2の記憶領域122へ実際にデータをコピーする(つまりバックアップする)ためのバックグラウンド処理を開始する。このバックグラウンド処理は、具体的には、コピーオンライト(Copy-On-Write)にしたがった処理でもよい。

0095

そして、次のステップS109で制御装置123は、第2のプログラムモジュール105のプロセスに対して、バックアップ命令に対する応答を返す。
例えば、ステップS108でスナップショットの作成が成功した場合、ステップS109での応答は、バックアップ処理の正常終了を表す通知であってもよい。つまり、実際にデータをコピーする処理は、ステップS109よりも後にバックグラウンドで行われるとしても、制御装置123は、コンピュータ100に対して、あたかも実際のデータのコピーがステップS108で完了したかのように見せかけてもよい。図2の例では、ステップS109の応答が、バックアップ処理の正常終了を表すものとする。

0096

すると、ステップS110でコンピュータ100は、制御装置123から受け取った応答の内容を、第2のプログラムモジュール105にしたがって、第1のプログラムモジュール104のプロセスに対して通知する。換言すれば、第2のプログラムモジュール105のプロセスが、上記応答の内容を第1のプログラムモジュール104のプロセスに通知する。

0097

例えば、上記のようにステップS109の応答が、バックアップ処理の正常終了を表す場合、ステップS110では、バックアップ処理の正常終了が第1のプログラムモジュール104のプロセスに対して通知される。

0098

そして、以上のようにして正常終了が通知された場合、ステップS111でコンピュータ100は、第1のプログラムモジュール104にしたがって、解除命令をデータ利用プログラム106のプロセスに対して発行する。換言すれば、第1のプログラムモジュール104のプロセスが解除命令を発行する。なお、上記のとおり、解除命令は、停止命令を解除するための命令である。

0099

すると、ステップS112でコンピュータ100は、データ利用プログラム106にしたがって、第1の記憶領域111に対する更新操作を再開するための制御を行う。換言すれば、ステップS112での制御は、データ利用プログラム106のプロセスにより行われる。

0100

例えば、ステップS103で上記(7c)のように動作モードを変更する処理が行われた場合、ステップS112では、DBMSの動作モードを通常モードに戻すための処理が行われる。通常モードへの復帰にともなって、例えば以下のような処理がさらに行われてもよい。

0101

書き込み禁止モードは、上記のとおり、実施形態に応じて、キューを使うモードであってもよいし、第1の記憶領域111とは別のキャッシュ領域(例えば、ディスクキャッシュとして使われるメモリ上の領域)を使うモードであってもよい。よって、ステップS112では、もしデータ利用プログラム106のキューに1つ以上の書き込みアクセス要求の内容が記憶されていれば、当該1つ以上の書き込みアクセス要求に順々にしたがって、第1の記憶領域111への書き込みアクセスが行われてもよい。あるいは、動作モードが書き込み禁止モードに設定されていた間に、上記キャッシュ領域に何らかの書き込みアクセス要求に応じて結果が書き込まれていた場合、当該結果がステップS112で第1の記憶領域111へ書き出されてもよい。

0102

また、ステップS112以降に、データ利用プログラム106のプロセスが新たに別の書き込みアクセス要求を受け付けた場合、当該新たな書き込みアクセス要求に応じた書き込みアクセスも行われる。例えば、以上のようにして、データ利用プログラム106のプロセスは、解除命令の受領に応じて、第1の記憶領域111に対する更新操作を再開する。

0103

続いて、以上説明した第1実施形態の利点についての理解を助けるため、図3〜4を参照して、第1〜第2比較例について説明する。図3は、第1比較例を説明する図であり、図4は、第2比較例を説明する図である。

0104

図3の第1比較例では、物理サーバ200上でゲストOS201が動作する。物理サーバ200内では、例えば「管理OS」または「ホストOS」と呼ばれるような、特定のOSがさらに動作している。当該特定のOSからは、実ハードウェア(例えば実ディスク)が認識可能である。しかし、図3では、当該特定のOSは省略されている。物理サーバ200内では、不図示の別のゲストOSがさらに動作していてもよい。

0105

ゲストOS201は、具体的には、物理サーバ200内の仮想マシン上で動作する。また、ゲストOS201上では、バックアップソフトウェア202と、バックアップ対象のデータを利用するアプリケーション203(例えばDBMSアプリケーション)が動作する。

0106

また、物理サーバ200は、SAN210を介してストレージシステム220に接続されている。ストレージシステム220は実ディスク221と222を含む。例えば、ストレージシステム220はRAIDシステムであってもよく、実ディスク221と222のそれぞれは、物理的にはディスクアレイにより実現されてもよい。

0107

説明の便宜上、アプリケーション203が利用するデータ(つまりバックアップ対象のデータ)は、物理的には実ディスク221上の記憶領域に記憶されているものとする。また、データのバックアップ先が、実ディスク222上の記憶領域であるものとする。

0108

ところで、ある種の仮想化技術によれば、ゲストOS201が動作する仮想マシンからも、実ディスクが認識可能である。例えば、Hyper−Vの「パススルーディスク」オプションや、VMwareの「RDM」(Raw Device Mapping)オプションは、仮想マシンが実ディスクを認識して利用することを可能にする技術の例である(Hyper−VおよびVMwareは登録商標)。

0109

第1比較例では、例えば以上のような仮想化技術を用いることにより、ゲストOS201が動作する仮想マシンから、実ディスクが認識可能になっているものとする。仮想マシンから実ディスクが認識可能な場合、仮想マシン上で動作するバックアップソフトウェア202にしたがったバックアップ処理は、実マシンにおけるバックアップ処理と同じ手順で実行することが可能である。理由は以下の(8a)〜(8b)のとおりである。

0110

(8a)アプリケーション203のプロセスに実ディスク221への書き込みアクセスを停止させるための命令(すなわち停止命令)が、定義されていてもよい。アプリケーション203のプロセスが停止命令として受け付けることのできる命令は、ゲストOS201が動作する仮想マシン内から発せられた命令に限られるかもしれない。しかし、その場合も、第1比較例によれば、アプリケーション203のプロセスは、バックアップソフトウェア202のプロセスからの停止命令を受け付けることが可能である。なぜなら、バックアップソフトウェア202とアプリケーション203は、同じゲストOS201上で動作するからである。
(8b)ストレージシステム220が受け付け可能なバックアップ命令のパラメタとして、仮想ディスクを識別する情報が使えず、実ディスクを識別する情報しか使えないかもしれない。しかし、その場合も、第1比較例では、バックアップソフトウェア202のプロセスは、ストレージシステム220が受け付け可能なバックアップ命令を発行することができる。なぜなら、ゲストOS201が動作する仮想マシンから、実ディスク221や222が認識可能であり、バックアップソフトウェア202はゲストOS201上で動作するからである。

0111

具体的には、第1比較例では、以下のようにして実ディスク221から実ディスク222へのデータのバックアップが行われる。
まず、バックアップソフトウェア202のプロセスが、アプリケーション203のプロセスに対して停止命令を発行する。例えばバックアップソフトウェア202がDBSMアプリケーションの場合、アプリケーション203のプロセスは、停止命令の受領に応じて上記(7a)〜(7c)と類似の制御を実行する。その結果、データの静止点が作成される。こうして、アプリケーション203が利用する実ディスク221上のデータは、停止命令の発行と受領にともなって、バックアップ可能な状態になる。

0112

静止点の作成後、アプリケーション203のプロセスは、バックアップソフトウェア202のプロセスに対して、静止点の作成が完了したことを通知する。このように、同じゲストOS201上で動作するバックアップソフトウェア202のプロセスとアプリケーション203のプロセスは、互いに連携することができる。

0113

ここで、実ディスク221と222は、ゲストOS201上で動作するバックアップソフトウェア202のプロセスから認識可能である。換言すれば、バックアップソフトウェア202のプロセスは、実ディスク221と222上の記憶領域をそれぞれ識別する実識別情報を取得することができる。

0114

よって、アプリケーション203のプロセスからの通知にともない、バックアップソフトウェア202のプロセスは、ストレージシステム220に対してバックアップ命令を発行する。バックアップ命令のパラメタとして、上記のようにして取得された実識別情報(または実識別情報から得られる他の情報)が使われる。また、バックアップ命令は、SAN210を介してストレージシステム220へと送信される。

0115

すると、ストレージシステム220は、バックアップ命令にしたがった制御を行う。例えば、ストレージシステム220は、図2のステップS108と同様に、実ディスク221上の、バックアップ対象のデータが記憶されている記憶領域のスナップショットを作成する。スナップショットの作成が完了したら、ストレージシステム220は、バックアップソフトウェア202のプロセスに完了を通知する。完了通知は、SAN210を介して送信される。また、ストレージシステム220は、実ディスク221から実ディスク222へ実際にデータをコピーする処理を、バックグラウンドで実行する。

0116

他方、ストレージシステム220からの完了通知の受信に応じて、バックアップソフトウェア202のプロセスは、バックアップ処理の完了をアプリケーション203のプロセスに通知する。すると、アプリケーション203のプロセスは、図2のステップS112と同様の制御を行う。その結果、実ディスク221への更新操作が再開される。

0117

以上のようにして、第1比較例では実ディスク221から実ディスク222へのデータのバックアップが行われる。
そして、第1実施形態と第1比較例は「オンラインバックアップが可能である」という点で共通である。オンラインバックアップは、ホットバックアップとも言われ、例えばDBMSのようなシステムのシャットダウンを伴わずにデータをバックアップする処理のことである。換言すれば、第1実施形態と第1比較例は、「バックアップ対象のデータを利用するプログラムの実行を停止することなく、バックアップ命令に応じたバックアップ処理を行うことが可能である」という点で共通である。

0118

しかしながら、第1比較例では、上記のとおり、ゲストOS201が動作する環境から実ディスク221と222が認識可能でなくてはならない。つまり、第1比較例は、特定の仮想化技術(例えば「パススルーディスク」オプションなど)に依存している。特定の仮想化技術への依存は、「バックアップ命令に応じたバックアップ処理が実行可能な条件が限定されてしまう」ということを意味する。

0119

それに対し、第1実施形態では、第1の環境101から実記憶装置120が認識可能である必要はない。つまり、第1実施形態には、第1比較例のような、特定の仮想化技術への依存性がない。そのため、第1実施形態では、バックアップ命令を用いたバックアップ処理が実行可能な条件が、第1比較例よりも緩和されている。

0120

そして、以上の比較から分かるように、実システムから仮想システムへの移行を検討するユーザにとって、第1比較例は、バックアップ処理のために仮想ディスクの使用を諦めなくてはならないシステム構成である。他方、第1実施形態は、実記憶装置120を仮想化した仮想記憶装置110を使用することと、バックアップ命令を用いたオンラインバックアップを行うことが両立可能なシステム構成である。つまり、上記の条件の緩和は、オンラインバックアップの適用範囲の拡大であるとも言えるし、仮想化に関する選択肢の増加であるとも言える。したがって、第1実施形態は、第1比較例と比べて優れている。

0121

次に、図4を参照して、第2比較例について説明する。図4の第2比較例では、第1比較例とは異なり、バックアップ対象のデータを利用するアプリケーションが動作する仮想マシンからは、実ディスクが認識されない。

0122

具体的には、第2比較例では、物理サーバ300上で管理OS301とゲストOS302が動作する。そして、管理OS301上ではバックアップソフトウェア303が動作する。一方、バックアップ対象のデータを利用するアプリケーション304(例えばDBMSアプリケーション)は、ゲストOS302上で動作する。

0123

物理サーバ300は、SAN310を介してストレージシステム320に接続されている。ストレージシステム320は実ディスク321と322を含む。例えば、ストレージシステム320はRAIDシステムであってもよく、実ディスク321と322のそれぞれは、物理的にはディスクアレイにより実現されてもよい。

0124

説明の便宜上、アプリケーション304が利用するデータ(つまりバックアップ対象のデータ)は、物理的には実ディスク321上の記憶領域に記憶されているものとする。また、データのバックアップ先が、実ディスク322上の記憶領域であるものとする。

0125

ところで、第2比較例において、ゲストOS302の動作する仮想マシンからは、実ディスク321上の領域に割り当てられた仮想ディスク323や、実ディスク322上の領域に割り当てられた仮想ディスク324が認識可能である。しかし、ゲストOS302の動作する仮想マシンからは、実ディスク321や322自体は認識されない。

0126

他方、第2比較例では、ストレージシステム320が受け付け可能なバックアップ命令のパラメタとして、仮想ディスクを識別する情報が使えず、実ディスクを識別する情報しか使えない。また、バックアップソフトウェア303は、ストレージシステム320に対してバックアップ命令を発行することを含む処理を、物理サーバ300のCPU(Central Processing Unit)に実行させるプログラムである。よって、第2比較例のバックアップソフトウェア303は、管理OS301上で動作するようにインストールされる。

0127

このようにバックアップソフトウェア303とアプリケーション304が異なるOS上で動作する場合、オンラインバックアップができないことがある。なぜなら、ある種のアプリケーション304によれば、アプリケーション304のプロセスに書き込みアクセスを停止させるための停止命令は、アプリケーション304が動作するゲストOS302内からのみ受け付け可能だからである。換言すれば、ある種のアプリケーション304には、アプリケーション304が動作する仮想マシンの外部から停止命令を受け付けるためのインタフェイスがない。

0128

第2比較例では、上記のような種類のアプリケーション304が使われているものとする。例えば、アプリケーション304のプロセスは、ゲストOS302により提供されるAPIを介して、ゲストOS302の内部から発行された停止命令を受け付けることはできるかもしれない。しかし、アプリケーション304には、ゲストOS302の外部から発行された停止命令(例えば、ネットワーク経由で送信される停止命令)を受け付けるためのインタフェイスがないかもしれない。

0129

上記のように、アプリケーション304のプロセスが、ゲストOS302の外部から停止命令を受け付けることができないと、停止命令を用いたバックアップソフトウェア303とアプリケーション304の間の連携も不能である。そして、停止命令を用いた連携が不能な場合、停止命令の発行と受領に応じて静止点が作成されることもない。静止点が作成されないと、データの整合性を保ってオンラインバックアップを行うことができない。つまり、第2比較例では、オンラインバックアップがサポートされない。

0130

したがって、第2比較例では、オフラインバックアップコールドバックアップともいう)が行われる。具体的には、実行中のアプリケーション304が先に停止され、その後、バックアップソフトウェア303のプロセスからバックアップ命令が発行される。バックアップ命令に対する応答がストレージシステム320から返された後、アプリケーション304は再起動される。

0131

このように、オフラインバックアップが行われる場合、アプリケーション304が実行されない期間(すなわち、アプリケーション304のプロセスが外部から要求を受け付けることのできない期間)が生じる。例えば、アプリケーション304がDBMSアプリケーションの場合、オフラインバックアップの実行中は、DBMSがシャットダウンされているので、データベースへの外部からのアクセス要求は受け付け不能である。

0132

他方、アプリケーション304により提供されるサービスに高可用性が求められる場合は、オンラインバックアップがサポートされることが望ましい。換言すれば、オンラインバックアップがサポートされない第2比較例は、求められる可用性のレベルによっては、好ましくないことがある。

0133

以上のような第2比較例を、図1〜2の第1実施形態と比較してみると、以下のことが言える。まず、「バックアップ対象のデータを利用するアプリケーションが動作する環境からは、仮想ディスクしか認識可能でなくてもよい」という点では、第2比較例と第1実施形態は共通である。しかし、第2比較例では上記のようにオンラインバックアップがサポートされないのに対して、第1実施形態ではオンラインバックアップがサポートされる。

0134

つまり、仮に図1のデータ利用プログラム106が第1の環境101内からしか停止命令を受け付けることができないとしても、図1〜2の第1実施形態では、オンラインバックアップが可能である。それに対し、第2比較例では、アプリケーション304がゲストOS302の外部から停止命令を受け付けることができないと、オンラインバックアップが不能である。したがって、第1実施形態の方が第2比較例よりも優れている。

0135

換言すれば、ある特定のアプリケーションを仮想環境下で利用したいとユーザが望む場合、第2比較例によれば、ユーザはオンラインバックアップ機能を諦めなくてはならない。しかし、第1実施形態によれば、ユーザはオンラインバックアップ機能を諦める必要がない。

0136

あるいは、ユーザが仮想環境下でのオンラインバックアップを望む場合、ユーザは、第2比較例のバックアップソフトウェア303を利用しようとする限りは、アプリケーション304のようなある種のアプリケーションを使うことを諦めなくてはならない。しかし、第1実施形態によれば、たとえデータ利用プログラム106が第1の環境101内からしか停止命令を受け付けることができないとしても、ユーザはデータ利用プログラム106を使うことを諦める必要はない。

0137

以上のように、第1実施形態では、バックアップ命令を用いたバックアップ処理が実行可能な条件が、第2比較例のようにオフラインバックアップに限定されておらず、オンラインバックアップが可能である。また、第1実施形態では、バックアップ処理を実行可能にするための条件として、データ利用プログラム106に特に課される制約もない。

0138

つまり、第1実施形態では、バックアップ命令を用いたバックアップ処理が実行可能な条件が、第2比較例よりも緩和されている。そして、条件が緩和されてユーザの選択肢が多いぶん、第1実施形態は第2比較例よりも優れている。

0139

さらに、第1実施形態には次のような利点もある。
バックアップ制御プログラム103のユーザインタフェイスは、仮想化されていないコンピュータで実行されるバックアップ制御プログラムのものと同様でもよい。ユーザインタフェイスの1つの例は、例えば、バックアップ制御プログラム103の実行スケジュールを設定するためのインタフェイスである。ユーザインタフェイスの他の例は、ユーザ定義スクリプトにしたがってバックアップ制御プログラム103を実行するためのインタフェイスである。

0140

具体的には、バックアップ制御プログラム103のユーザインタフェイスは、第1のプログラムモジュール104によって提供されてもよい。
仮想化されていないコンピュータでは、バックアップ対象のデータを利用するデータ利用プログラムと、バックアップ制御プログラムは、同じOS上で動作する。また、第1実施形態において第1のプログラムモジュール104は、データ利用プログラム106と同じく、第1の環境101内で動作する。

0141

このように、データ利用プログラムと同じ環境内で動作するという点で、第1実施形態の第1のプログラムモジュール104は、仮想化されていないコンピュータで実行されるバックアップ制御プログラムと類似である。よって、仮想化されていないコンピュータで実行されるバックアップ制御プログラムと同様のユーザインタフェイスを、第1のプログラムモジュール104に設けることが可能である。

0142

そして、仮想化されていないコンピュータで実行されるバックアップ制御プログラムと同様のユーザインタフェイスを第1のプログラムモジュール104が提供する場合、次のような利点がある。すなわち、この場合、実システムから仮想システムへの移行に際して、今まで実システムで使用されていたユーザ定義スクリプト等のユーザ資産がそのまま利用可能である。よって、ユーザにとっては、「ユーザ資産を無駄にすることなく、実システムから仮想システムへ移行する」という選択肢が選択可能となる。

0143

このように、第1実施形態は、ユーザ利便性に優れている。また、第1実施形態は、仮想システムへの移行を容易にするという効果がある。

0144

続いて、図5〜12を参照して第2実施形態について説明する。比較の詳細説明は省略するが、第2実施形態も第1実施形態と同様に、第1比較例よりも優れており、また、第2比較例よりも優れている。

0145

図5は、第2実施形態のブロック図である。第2実施形態では、仮想化技術として具体的にはXenハイパーバイザが利用される。図5のコンピュータ400では、不図示のXenハイパーバイザが動作する。

0146

図5には、Xenハイパーバイザ上で動作する2つの仮想マシン410と420が図示されている。また、図5には、SAN430を介してコンピュータ400と接続されたストレージシステム440も図示されている。

0147

仮想マシン410は、具体的にはドメインUであり、仮想マシン420は、具体的にはドメイン0である。仮想マシン410は図1の第1の環境101に対応し、仮想マシン420は図1の第2の環境102に対応する。

0148

仮想マシン410上では、アプリケーション411が動作する。以下では説明の便宜上、アプリケーション411が具体的にはDBMSアプリケーションであるものとする。アプリケーション411は、図1のデータ利用プログラム106と対応する。

0149

他方、仮想マシン420(すなわちドメイン0)は、仮想マシン管理部421とXenStore422を含む。Xenハイパーバイザが使われる場合、1つまたは複数のドメインUが存在し得る。仮想マシン管理部421は、当該1つまたは複数のドメインUに関する情報を管理する。XenStore422は、各ドメインに関する情報を格納する1種のデータベースである。XenStore422では名前空間階層化されている。

0150

ところで、上記のように第1実施形態では、バックアップ制御プログラム103が、第1の環境101上で動作する第1のプログラムモジュール104と、第2の環境102上で動作する第2のプログラムモジュール105を含む。同様に、第2実施形態のバックアップ制御プログラムは、仮想マシン410上で動作するフロントエンドコンポーネント412と、仮想マシン420上で動作するバックエンドコンポーネント423を含む。

0151

フロントエンドコンポーネント412は連携部413と要求部414を含み、バックエンドコンポーネント423は受付部424とAPI群425を含む。

0152

連携部413は、アプリケーション411とフロントエンドコンポーネント412の間の連携のためのモジュールである。例えば、連携部413は、第1実施形態と同様の停止命令や解除命令を、アプリケーション411のプロセスに対して発行する。連携部413は、ユーザインタフェイスも提供する。

0153

要求部414は、バックエンドコンポーネント423への要求をフロントエンドコンポーネント412から送信し、バックエンドコンポーネント423からの応答を受信するためのモジュールである。要求部414から送信された要求は、受付部424により受信される。

0154

詳しくは後述するが、受付部424は、要求部414から受け付けた要求に応じて様々な処理を行う。そして、受付部424は、要求部414からの要求に対する応答を、要求部414に送信する。

0155

API群425は、ストレージシステム440に関連するいくつかのAPIを含む。例えば、コンピュータ400からストレージシステム440に対してコマンドを与え、コマンドに対する応答をストレージシステム440から受け取るためのいくつかのAPIが、API群425には含まれる。コマンドは、具体的には例えばSCSIコマンドでもよく、コマンドに対する応答は、例えば、SCSIコマンドに対して返されるステータスであってもよい。受付部424は、API群425を用いていくつかの処理を行う。

0156

フロントエンドコンポーネント412とバックエンドコンポーネント423が協働して行うバックアップ制御のさらなる詳細は、図7〜12とともに後述する。

0157

さて、ストレージシステム440は実ディスク441と442を含む。ストレージシステム440は、具体的にはRAIDシステムでもよく、実ディスク441と442のそれぞれは、物理的にはディスクアレイにより実現されてもよい。RAIDレベルは任意である。

0158

ストレージシステム440がRAIDシステムである場合、実ディスク441は、具体的には、仮想マシン420(すなわちドメイン0)から1台の実ディスクドライブとして認識される、1つの論理ユニットである。同様に、ストレージシステム440がRAIDシステムである場合、実ディスク442は、仮想マシン420から1台の実ディスクドライブとして認識される、もう1つの論理ユニットである。

0159

実ディスク441と442は、仮想マシン410(すなわちドメインU)からは認識されない。その代わり、仮想マシン410からは、仮想ディスク443と444が認識される。仮想ディスク443は、物理的には、実ディスク441上の領域に割り当てられている。同様に、仮想ディスク444は、物理的には、実ディスク442上の領域に割り当てられている。

0160

説明の便宜上、アプリケーション411が利用するデータ(すなわちバックアップ対象のデータ)が、仮想ディスク443に記憶されているものとする。そして、バックアップ先の領域は、仮想ディスク444にあるものとする。換言すれば、アプリケーション411が利用するデータは、物理的には実ディスク441に記憶されており、実ディスク441上のデータが実ディスク442にバックアップされる。

0161

たとえアプリケーション411が仮想マシン410内からしか停止命令を受け付けることができなくても、また、たとえ仮想マシン410からは実ディスク441と442が認識されなくても、第2実施形態によれば、オンラインバックアップが可能である。なぜなら、バックアップ制御プログラムのフロントエンドコンポーネント412とバックエンドコンポーネント423は、仮想マシン410と420に分かれており、協働してバックアップ処理を制御するからである。

0162

次に、図5のようなコンピュータ400とSAN430とストレージシステム440を含むシステムのハードウェア構成の例について説明する。図6は、システムのハードウェア構成図である。

0163

図6には、コンピュータ500と、ネットワーク510と、ネットワーク510を介してコンピュータ500に接続された他のコンピュータ520と、コンピュータ読み取り可能な記憶媒体530が示されている。ネットワーク510は、例えば、LAN(Local Area Network)、WAN(Wide Area Network)、インターネット、またはそれらの組み合わせであってもよい。

0164

また、図6には、SAN540と、SAN540を介してコンピュータ500に接続された2つのストレージシステム550および560も示されている。SAN540は、例えば、ファイバチャネルによるネットワークでもよい。ストレージシステム550と560のそれぞれは、例えば、コントローラと複数の磁気ディスク媒体が1つのシャーシに収容されたRAIDシステムであってもよい。

0165

また、ストレージシステム560はなくてもよい。逆に、3つ以上のストレージシステムがSAN540に接続されていてもよい。

0166

図5のコンピュータ400は、具体的には図6のコンピュータ500であってもよい。また、図5のSAN430は図6のSAN540に対応する。図5では1つのストレージシステム440のブロックのみが図示されているが、図6に示すように、SAN540には2つ以上のストレージシステムが接続されていてもよい。

0167

例えば、図5の実ディスク441と442の双方が、具体的には図6のストレージシステム550に含まれていてもよい。あるいは、実ディスク441と442のうちの一方がストレージシステム550に含まれ、実ディスク441と442のうちの他方がストレージシステム560に含まれているのでもよい。

0168

コンピュータ500は、CPU501と、RAM(Random Access Memory)502と、LANインタフェイス503を含む。なお、紙幅都合上、図6では「インタフェイス」を「I/F」と表記している。コンピュータ500は、LANインタフェイス503を介して、ネットワーク510に接続されている。

0169

コンピュータ500はさらに、記憶媒体530の駆動装置504と、入力装置505と、出力装置506を有する。入力装置505は、例えば、キーボードを含み、さらに、マウスなどのポインティングデバイスを含んでいてもよいし、マイクを含んでいてもよい。出力装置506は、例えば、ディスプレイスピーカ、またはその組み合わせでもよい。

0170

コンピュータ500は、さらに、ホストバスアダプタ507と、ローカルHDD508も有する。ホストバスアダプタ507は、コンピュータ500とSAN540を接続するインタフェイスである。

0171

コンピュータ500は、ストレージシステム550または560のディスク上のデータを用いてクライアントにサービスを提供するサーバであってもよい。例えば、コンピュータ500は、図5のアプリケーション411によるデータベースサービスを提供するデータベースサーバであってもよい。

0172

サービスに使われるデータは、上記のとおりストレージシステム550または560のディスクに記憶される。他方、コンピュータ500自体の制御に使われるデータ(例えば、CPU501が実行する種々のプログラム、XenStore422中のデータ、仮想マシン管理部421が管理するデータ、など)は、ローカルHDD508に記憶される。

0173

ローカルHDD508の代わりに(あるいは、ローカルHDD508とともに)SSD(Solid-State Drive)が使われてもよい。なお、コンピュータ500内の上記構成要素同士は、バス509で互いに接続されている。

0174

さて、コンピュータ500のCPU501は、様々なプログラムをRAM502にロードし、RAM502をワーキングエリアとしても使いながら、プログラムを実行する。CPU501が実行するプログラムの例は、(9a)〜(9g)に示すとおりである。

0175

(9a)Xenハイパーバイザのプログラム。
(9b)仮想マシン410(つまりドメインU)のOSのプログラム。
(9c)仮想マシン420(つまりドメイン0)のOSのプログラム。
(9d)アプリケーション411のプログラム。
(9e)フロントエンドコンポーネント412のプログラム。
(9f)バックエンドコンポーネント423のプログラム。
(9g)仮想マシン管理部421を実現するためのプログラム。

0176

換言すれば、図5の連携部413は、CPU501により実現される。また、要求部414もCPU501により実現される。

0177

なお、要求部414と受付部424の間ではTCP/IP通信が行われるが、要求部414と受付部424を実現するために、物理的なLANインタフェイス503は必ずしも使われなくてもよい。なぜなら、LANインタフェイス503も仮想化されるからである。要求部414と受付部424の間のTCP/IP通信は、物理的なLANインタフェイス503を介さずに、コンピュータ500内の仮想ネットワークのレベルで行われてもよい。

0178

受付部424の一部も、要求部414と同様に、CPU501により実現される。また、受付部424は、API群425を用いて、SAN430を介して、命令を送信したり応答を受信したりする。SAN430を介した通信は、具体的にはホストバスアダプタ507により実現される。

0179

ところで、CPU501が実行する(9a)〜(9g)のような各種プログラムは、予めローカルHDD508に記憶されていてもよいし、ネットワーク510を介してコンピュータ520からコンピュータ500にダウンロードされてもよい。あるいは、CPU501が実行する各種プログラムは、記憶媒体530に記憶されて提供されてもよい。つまり、プログラムは、駆動装置504にセットされた記憶媒体530から読み取られ、ローカルHDD508にコピーされてもよい。あるいは、プログラムは、駆動装置504から直接RAM502へロードされてもよい。

0180

記憶媒体530は、具体的には、CD(Compact Disc)やDVD(Digital Versatile Disk)などの光ディスクでもよいし、光磁気ディスクでもよいし、磁気ディスクでもよいし、フラッシュメモリカードなどの不揮発性半導体メモリでもよい。また、記憶媒体530だけでなく、例えばRAM502や、ローカルHDD508に含まれるディスク媒体なども、コンピュータ読み取り可能な記憶媒体の例である。そして、以上例示したような各種の記憶媒体は、いずれも、有形の(tangible)媒体であり、信号搬送波のような一時的な(transitory)媒体ではない。

0181

ところで、ストレージシステム550は、上記のとおり、例えばRAIDシステムでもよい。ストレージシステム550は、ストレージシステム550を制御するコントローラ551(より具体的には、例えばRAIDコントローラ)を含む。また、ストレージシステム550はN個のディスク552−1〜552−Nを含む。Nは1以上であれば任意である。図6には、例として2≦Nの場合が例示されている。

0182

詳しくは図9とともに説明するが、ディスク552−1は、“/dev/sda”というパス名のデバイスファイルに対応する実ディスクとして、コンピュータ400上の仮想マシン420からは認識される。同様に、ディスク552−2は、“/dev/sdb”というパス名のデバイスファイルに対応する実ディスクとして、コンピュータ400上の仮想マシン420からは認識される。例えば、図5の実ディスク441が具体的には図6のディスク552−1であってもよく、実ディスク442がディスク552−2であってもよい。

0183

ストレージシステム560の詳細は、図示を省略した。しかし、ストレージシステム560も、ストレージシステム550と同様に、コントローラと、1個または複数個のディスクを含む。

0184

なお、第1実施形態の図1のコンピュータ100も、具体的には、例えば図6のコンピュータ500により実現されてもよい。つまり、CPU501が、以下の(10a)〜(10e)のような種々のプログラムを実行してもよい。

0185

(10a)第1の環境101を提供するためのプログラム。
(10b)第2の環境102を提供するためのプログラム。
(10c)第1のプログラムモジュール104。
(10d)第2のプログラムモジュール105。
(10e)データ利用プログラム106。

0186

CPU501は、第1のプログラムモジュール104を実行することにより、データ利用プログラム106のプロセスに対して第1の環境101内から停止命令を発行する停止命令発行部として動作してもよい。さらに、CPU501は、第1のプログラムモジュール104を実行することにより、第1の仮想識別情報と第2の仮想識別情報についての通知を第1の環境101内から発行する通知部として動作してもよい。

0187

一方で、CPU501は、第2のプログラムモジュール105を実行することにより、第1の仮想識別情報と第2の仮想識別情報からそれぞれ第1の実識別情報と第2の実識別情報を第2の環境102内において取得する取得部として動作してもよい。さらに、CPU501は、第2のプログラムモジュール105を実行することにより、第2の環境102内からバックアップ命令を発行するバックアップ命令発行部として動作してもよい。

0188

換言すれば、コンピュータ100は、停止命令発行部と通知部と取得部とバックアップ命令発行部を含む情報処理装置である。そして、停止命令発行部と通知部は、第1の環境101上に実装され、取得部とバックアップ命令発行部は第2の環境102上に実装される。

0189

そして、図1の1つ以上の実記憶装置120のそれぞれは、具体的には、ストレージシステム550内のディスクでもよいし、ストレージシステム560内のディスクでもよい。例えば、第1の記憶領域121は、ディスク552−1上の領域であってもよいし、第2の記憶領域122は、ディスク552−2上の領域であってもよい。

0190

ここで、第2実施形態の説明に戻る。以下では、第2実施形態で行われるバックアップ制御について、フローチャートと具体的なデータ例を参照して説明する。
図7は、バックアップ制御処理のフローチャートである。図7のバックアップ制御処理は、フロントエンドコンポーネント412が仮想マシン410にインストールされ、かつ、バックエンドコンポーネント423が仮想マシン420にインストールされた後、任意のタイミングで開始されてよい。図7のステップS201は初期化であり、初期化が終わった後、ステップS202〜S206が繰り返し実行される。

0191

具体的には、ステップS201で、ユーザからの入力にしたがい、(11a)と(11b)の情報が所定のファイルに登録される。

0192

(11a)バックエンドコンポーネント423(より具体的には受付部424)のIPアドレス
(11b)バックエンドコンポーネント423(より具体的には受付部424)のポート番号。

0193

ステップS201における上記所定のファイルは、具体的には、ドメイン0の管理OSが使用する所定のファイルである。当該所定のファイルは、第2実施形態においては、例えば図8のファイル601のようなCSV(Comma Separated Values)形式のファイルである。図8の例では、ステップS201の結果として、ファイル601に、“10.10.10.10”という受付部424のIPアドレスと、“1226”という受付部424のポート番号が登録されている。

0194

ステップS201の処理は、要求部414と受付部424の間の通信のための事前準備であり、より具体的には以下のように行われる。
連携部413が提供するユーザインタフェイスを介して、ユーザから、上記(11a)と(11b)の入力が与えられる。ユーザは、例えば図6の入力装置505を用いて(11a)と(11b)の情報を入力する。そして、連携部413が入力を受け取る。

0195

ここで、ファイル601は、仮想マシン420上で管理OSにより管理されるファイルである。したがって、ファイル601は、仮想マシン420の外部にある連携部413からは、直接にはアクセスされない。その代わり、例えば、仮想マシン410からファイル601に間接的にアクセスするための特定のドライバが、仮想マシン410にインストールされていてもよい。

0196

連携部413は、入力された(11a)と(11b)の情報をファイル601に登録することを、上記特定のドライバに要求してもよい。上記特定のドライバは、XenBusを介して、(11a)と(11b)の情報をファイル601に登録してもよい。

0197

XenBusは、ドメインUとドメイン0の間の(例えば、図5の例では、仮想マシン410と420の間の)情報共有に使われる仕組みである。XenBusへのアクセスがドメイン0において検出されると、XenStore422が参照される。

0198

例えば、仮想マシン420内ではXenBusへのアクセスを監視するデーモンが動作していてもよい。当該デーモンが、上記特定のドライバからのXenBusへのアクセスを検出し、検出したアクセスに応じて、実際に(11a)と(11b)の情報をファイル601に書き込んでもよい。

0199

例えば以上のようにして、ユーザからの入力にしたがって、ファイル601に受付部424のIPアドレスと、受付部424のポート番号が登録される。その後、ステップS202に示すように、データバックアップトリガが発生するまでは、特に何の処理も行われなくてよい。そして、データバックアップのトリガが発生するたびに、ステップS203〜S206の処理が実行される。

0200

なお、フロントエンドコンポーネント412とバックエンドコンポーネント423を含むバックアップ制御プログラムの実行は、ステップS201の実行後、一旦終了してもよい。また、バックアップ制御プログラムの実行は、ステップS206の実行後にも、一旦終了してもよい。そして、データバックアップのトリガの発生に応じて、バックアップ制御プログラムが再度起動されてもよい。

0201

逆に、ステップS201やS206の実行後、バックアップ制御プログラムは終了されなくてもよい。例えば連携部413がトリガの発生を監視し続けてもよい。

0202

また、データバックアップのトリガは任意である。例えば、ユーザが、入力装置505を介してバックアップ制御プログラムを起動してもよい。ユーザはさらに、アプリケーション411が利用するデータをバックアップするための指示を、入力装置505を介して連携部413に与えてもよい。ユーザから連携部413に指示が与えられたというイベントは、トリガの一例である。

0203

あるいは、決められたスケジュールにしたがってバックアップ制御プログラムを起動し、いくつかのパラメタを連携部413に与えるためのスクリプトが予め作成されていてもよい。この場合、決められた日時になったというイベントが、トリガである。

0204

例えば上記のような何らかのトリガが発生すると、次に、ステップS203において、連携部413とアプリケーション411が連携して、静止点を作成する。なお、ステップS202におけるトリガの発生は、図2のステップS101に対応し、ステップS203における静止点の作成は、ステップS102〜S104に対応する。つまり、ステップS203では、ステップS102〜S104と類似の処理が行われる。

0205

具体的には、ステップS203で連携部413は、実行中のアプリケーション411のプロセスに対して、停止命令を発行する。上記のとおり第2実施形態では、アプリケーション411は、仮想ディスク443上の記憶領域に記憶されたデータを利用する。よって、第2実施形態における停止命令は、具体的には、アプリケーション411のプロセスに、仮想ディスク443上の上記記憶領域に対する更新操作を一時的に停止させるための命令である。

0206

なお、停止命令のパラメタとして、仮想ディスク443上の記憶領域を識別する情報が指定されてもよい。あるいは、当該記憶領域に記憶されているデータベースの名前や、当該データベースに含まれるテーブルの名前が停止命令のパラメタとして指定されてもよい。

0207

アプリケーション411のプロセスは、停止命令に応じて、例えば第1実施形態における(7a)〜(7c)の処理と類似の、(12a)〜(12c)の処理を行ってもよい。

0208

(12a)実行途中のトランザクションがある場合、実行途中の各トランザクションを、最後まで実行してコミットするか、または、強制的にロールバックする処理。
(12b)仮想ディスク443上の、アプリケーション411の利用する上記記憶領域用のディスクキャッシュとして使われるRAM502上の領域に記憶されているデータを、仮想ディスク443上の上記記憶領域へとフラッシュする処理。
(12c)アプリケーション411(つまりDBMSアプリケーション)の動作モードを、書き込み禁止モードに変更する処理(書き込み禁止モードについては、第1実施形態に関連して説明したとおりである)。

0209

例えば(12a)〜(12c)のような処理により、バックアップ対象のデータ(すなわちコピー元のデータ)は、全体としてバックアップ可能な状態となる。なお、データをバックアップ可能な状態にするための処理は、(12a)〜(12c)の処理に限られない。そして、停止命令は、データをバックアップ可能な状態に遷移させる処理をアプリケーション411のプロセスに行わせるための命令のうちの、一つの例である。

0210

例えば、アプリケーション411のプロセスは、更新操作を一時的に停止する代わりに、更新操作のログをとることによって、データをバックアップ可能な状態にしてもよい。換言すれば、(12c)の処理の代わりに、アプリケーション411の動作モードをログモードに変更する処理が行われてもよい。この場合、アプリケーション411のプロセスに動作モードを書き込み禁止モードへ変更させることになる停止命令の代わりに、アプリケーション411のプロセスに動作モードをログモードへ変更させることになる別の命令を、連携部413が発行してもよい。

0211

なお、ログモードにおいて、アプリケーション411のプロセスは、新たな書き込みアクセス要求を受け付けた場合に、次のように動作する。すなわち、アプリケーション411のプロセスは、書き込みアクセスによってデータがどのように更新されるかをログに記録するとともに、要求に応じた書き込みアクセスを実行する。

0212

以上のようにして、ログモードでは、書き込みアクセスが監視され、記録される。つまり、仮想ディスク443から仮想ディスク444へとデータが実際にバックアップされている最中に起きる書き込みアクセスによるデータの変更は、ログモードを利用することで管理可能となる。このような管理が可能な場合、書き込みアクセスが禁止されていなくても、データの整合性を保ったバックアップ処理が可能である。換言すれば、ログモードへの遷移により、データはバックアップ可能な状態になる。

0213

以上例示したように、データをバックアップ可能な状態にするための具体的な手法は、アプリケーション411の種類に応じて様々である。しかし、以下では説明の便宜上、連携部413から停止命令が発行され、停止命令に応じて書き込みアクセスが禁止され、その結果として、静止点が作成される(つまりデータがバックアップ可能な状態になる)ものとする。

0214

アプリケーション411のプロセスは、静止点の作成に成功すると、図2のステップS104と同様に、連携部413に対して完了通知を送る。

0215

完了通知に応じて、次のステップS204では、要求部414が、後のステップS205〜S206での受付部424との通信に使うための情報を取得する。具体的には、要求部414は、図8のファイル601に登録されている、受付部424のIPアドレスとポート番号を取得するとともに、仮想マシン410のドメイン名を取得する。

0216

ステップS201に関して説明したとおり、仮想マシン410からファイル601に間接的にアクセスするための特定のドライバが、仮想マシン410にインストールされていてもよい。また、仮想マシン420内(つまり管理OS上)では、XenBusへのアクセスを監視するデーモンが動作していてもよい。ステップS204では、上記ドライバとデーモンを介して、要求部414が情報を取得してもよい。

0217

例えば、要求部414は、ファイル601に登録されているIPアドレスとポート番号と、仮想マシン410のドメイン名とを読み取るように、上記特定のドライバに要求する。すると、上記特定のドライバはXenBusにアクセスし、XenBusへのアクセスをデーモンが検出する。

0218

そして、検出に応じて、デーモンは、XenStore422を参照してファイル601を特定する。デーモンは、IPアドレスとポート番号をファイル601から読み取るとともに、仮想マシン410のドメイン名をXenStore422の“/vm/name”パスから読み取る。そして、デーモンは、読み取ったIPアドレスとポート番号とドメイン名を上記特定のドライバに返す。すると、上記特定のドライバは、以上のようにして得られたIPアドレスとポート番号とドメイン名を、要求部414に返す。

0219

例えば以上のような一連の処理により、所定のファイル601に登録されているIPアドレスとポート番号と、仮想マシン410のドメイン名とが、要求部414からの要求に応じて、XenStore422を介して読み取られ、要求部414に返される。すなわち、要求部414は、以上のようにして、受付部424のIPアドレスとポート番号を取得する。よって、要求部414は今後のステップS205〜S206において、TCP/IPにしたがって、受付部424との間で通信を行うことができる。

0220

さて、ステップS205は、図2のステップS105〜S106に対応し、ステップS206は図2のステップS107〜S111に対応する。また、ステップS205の詳細は図10のとおりであり、ステップS206の詳細は図12のとおりである。ここでは、ステップS205とS206の概要を説明する。

0221

ステップS205では、要求部414が受付部424に要求を送る。そして、要求に応じて、受付部424は、コピー元の仮想デバイスコピー先の仮想デバイスそれぞれについて、ストレージシステム440上での物理的な領域情報を取得する。

0222

そして、ステップS206では、受付部424が、データをコピーする(すなわちバックアップする)ようストレージシステム440に指示する。換言すれば、受付部424は、物理的な領域情報に基づいて、API群425中のあるAPIを介して、バックアップ命令を発行する。バックアップ命令に応じて、ストレージシステム440は、データをバックアップするための処理を実行し、受付部424に応答する。

0223

以上のようにしてステップS202〜S206でオンラインバックアップが行われた後、図7の処理は、ステップS202に戻る。なお上記のとおり、ステップS206の完了後、フロントエンドコンポーネント412とバックエンドコンポーネント423を含むバックアップ制御プログラムの実行は、一旦終了されてもよい。

0224

続いて、上記のステップS205〜S206の詳細について、図8〜9の具体的な値の例と、図10〜12のフローチャートを参照しながら説明する。図8のファイル601は、ステップS201とS204に関して既に説明したとおりである。図8コマンド実行例602については、図10のステップS304〜S305とともに後述する。

0225

図9は、仮想パーティションと仮想ディスクと実パーティションと実ディスクの例を説明する図である。
仮想パーティションは、仮想マシン410から認識されるパーティションであり、仮想ディスクは仮想マシン410から認識されるディスクである。仮想ディスクの例は、図5の仮想ディスク443と444である。

0226

各仮想ディスクは、物理的には、いずれかの実ディスク上の領域に割り当てられている。実ディスクの例は、図5の実ディスク441と442や、図6のディスク552−1〜552−Nなどである。以下では参照符号「552−1」〜「552−N」のディスクのことを「実ディスク」とも表記する。

0227

もちろん、実ディスクもパーティショニングされていてよい。実ディスク上のパーティションを、以下では実パーティションという。
一方、第2実施形態では、デバイスドライバのインタフェイスとして、デバイスファイルが使われる。したがって、デバイスは、OSの標準的なシステムコールを介してアクセスされる。パーティションとディスクは、いずれも、デバイスの1種であり、各々のデバイスファイルと対応する。

0228

つまり、仮想パーティションと仮想ディスクの各々は、仮想マシン410内で認識されるデバイスファイルと対応する。実パーティションと実ディスクの各々は、仮想マシン420内で認識されるデバイスファイルと対応する。

0229

以下では説明の便宜上、以下の(13a)〜(13h)のように仮定する。

0230

(13a)バックアップ対象の記憶領域は、仮想マシン410から認識される仮想ディスク443上の1つのパーティション全体である。当該パーティションは、具体的には、仮想マシン410において“/dev/xvda3”というパス名で識別されるデバイスファイルに対応する、図9の仮想パーティション603−1である。
(13b)データのバックアップ先の記憶領域は、仮想マシン410から認識される仮想ディスク444上の1つのパーティション全体である。当該パーティションは、具体的には、仮想マシン410において“/dev/xvdb3”というパス名で識別されるデバイスファイルに対応する、図9の仮想パーティション603−2である。
(13c)仮想パーティション603−1は、仮想マシン410において認識される仮想ディスク604−1上のパーティションのうちの1つである。仮想ディスク604−1は、仮想マシン410において“/dev/xvda”というパス名で識別されるデバイスファイルに対応する。図5の仮想ディスク443は、具体的には仮想ディスク604−1である。
(13d)仮想パーティション603−2は、仮想マシン410において認識される仮想ディスク604−2上のパーティションのうちの1つである。仮想ディスク604−2は、仮想マシン410において“/dev/xvdb”というパス名で識別されるデバイスファイルに対応する。図5の仮想ディスク444は、具体的には仮想ディスク604−2である。
(13e)物理的には、実パーティション605−1の全体が仮想ディスク604−1用に使われる。実パーティション605−1は、仮想マシン420において“/dev/sda6”というパス名で識別されるデバイスファイルに対応する。
(13f)物理的には、実パーティション605−2の全体が仮想ディスク604−2用に使われる。実パーティション605−2は、仮想マシン420において“/dev/sdb6”というパス名で識別されるデバイスファイルに対応する。
(13g)実パーティション605−1は、仮想マシン420において認識される実ディスク552−1上のパーティションのうちの1つである。図6にも示したように、実ディスク552−1は、仮想マシン420において“/dev/sda”というパス名で識別されるデバイスファイルに対応する。図5の実ディスク441は、具体的には実ディスク552−1である。
(13h)実パーティション605−2は、仮想マシン420において認識される実ディスク552−2上のパーティションのうちの1つである。図6にも示したように、実ディスク552−2は、仮想マシン420において“/dev/sdb”というパス名で識別されるデバイスファイルに対応する。図5の実ディスク442は、具体的には実ディスク552−2である。

0231

ところで、ディスクやパーティションなどのデバイス上のアドレスは、例えば、512バイトのセクタを単位としたLBA(Logical Block Addressing)番号で表されてもよい。図9には、アドレスも例示されている。具体的には以下のとおりである。

0232

実ディスク552−1上のアドレスA1から始まる領域が、実パーティション605−1として使われる。実ディスク552−1のサイズはA2である。
また、仮想ディスク604−1上のアドレスB1から始まる領域が、仮想パーティション603−1として使われる。仮想ディスク604−1のサイズはB2である。

0233

なお、第2実施形態では、実パーティション605−1の全体が、仮想ディスク604−1用に割り当てられている。そのため、実パーティション605−1のサイズもB2であり、仮想パーティション603−1が物理的に位置する領域は、実パーティション605−1上のアドレスB1から始まる領域である。

0234

図9のとおり、仮想パーティション603−1のサイズをCとする。すると、仮想パーティション603−1は、仮想ディスク604−1上の、アドレスB1からアドレス(B1+C−1)までの領域である。また、仮想パーティション603−1は、物理的には、実パーティション605−1上の、アドレスB1からアドレス(B1+C−1)までの領域を占める。そして、当該領域の開始アドレスと終了アドレスを、実ディスク552−1上のアドレスにより表すと、それぞれ、アドレス(A1+B1)とアドレス(A1+B1+C−1)である。

0235

さて、実ディスク552−2上のアドレスD1から始まる領域が、実パーティション605−2として使われる。実ディスク552−2のサイズはD2である。
また、仮想ディスク604−2上のアドレスE1から始まる領域が、仮想パーティション603−2として使われる。仮想ディスク604−2のサイズはE2である。

0236

なお、第2実施形態では、実パーティション605−2の全体が、仮想ディスク604−2用に割り当てられている。そのため、実パーティション605−2のサイズもE2であり、仮想パーティション603−2が物理的に位置する領域は、実パーティション605−2上のアドレスE1から始まる領域である。

0237

ところで、仮想パーティション603−2は、仮想パーティション603−1上のデータをバックアップするために使われるので、仮想パーティション603−2は仮想パーティション603−1と同じか、それより大きいサイズである。以下では簡単のため、仮想パーティション603−1と603−2は同一サイズであるとする。

0238

したがって、仮想パーティション603−2は、仮想ディスク604−2上の、アドレスE1からアドレス(E1+C−1)までの領域である。また、仮想パーティション603−2は、物理的には、実パーティション605−2上の、アドレスE1からアドレス(E1+C−1)までの領域を占める。そして、当該領域の開始アドレスと終了アドレスを、実ディスク552−2上のアドレスにより表すと、それぞれ、アドレス(D1+E1)とアドレス(D1+E1+C−1)である。

0239

続いて、図9の仮想パーティション603−1から仮想パーティション603−2へのデータのバックアップを具体例として参照しながら、図7のステップS205の詳細を説明する。図10は、ステップS205において物理領域情報を取得する処理のフローチャートである。

0240

なお、説明の便宜上、図10では、コピー元の仮想デバイスの名前を“src”と表記し、コピー先の仮想デバイスの名前を“dst”と表記してある。また、以下では、特に断らない限り、デバイスの名前として当該デバイスに対応するデバイスファイルのパス名が使われるものとする。

0241

したがって、図9の例においては、コピー元の仮想デバイスの名前srcは、コピー元の仮想パーティション603−1に対応するデバイスファイルの、“/dev/xvda3”というパス名である。そして、コピー先の仮想デバイスの名前dstは、コピー先の仮想パーティション603−2に対応するデバイスファイルの、“/dev/xvdb3”というパス名である。

0242

なお、コピー元の仮想デバイスの名前srcと、コピー先の仮想デバイスの名前dstは、図7のステップS202でトリガイベントが検出されたときに、連携部413により取得される。例えば、これらの名前srcとdstは、入力装置505を介して入力されてもよいし、スクリプトに記載されていてもよい。

0243

そして、これらの名前srcとdstは、連携部413から要求部414に通知される。したがって、要求部414は、これらの名前srcとdstを用いて図10の処理を開始することができる。

0244

まず、ステップS301で要求部414は、コピー元の仮想デバイスについての領域情報を、コピー元の仮想デバイスの名前srcから取得する。ステップS301で取得される領域情報は、ゲストOSにより認識される領域情報(つまり、要求部414が含まれる仮想マシン410から認識される領域情報)であって、具体的には、例えば以下の(14a)〜(14c)を含む。

0245

(14a)仮想デバイスが存在する仮想ディスクを識別する情報(例えば、仮想ディスクに対応するデバイスファイルのパス名)。
(14b)仮想デバイスの、仮想ディスク上での開始位置(例えば、LBA番号により表される開始アドレス)。
(14c)仮想デバイスのサイズ(例えば、LBA番号と同様に512バイトのセクタを単位として表されるサイズ)。

0246

以上の領域情報は、仮想マシン410において認識される1つ以上の仮想ディスク(図9の場合、少なくとも2つの仮想ディスク604−1と604−2)の中で、仮想パーティション603−1を識別する情報の例である。したがって、(14a)〜(14c)を含む領域情報は、第1実施形態の(3a)に示した第1の仮想識別情報に対応する。

0247

また、例えば、図9の例の場合、要求部414はステップS301で、コピー元の仮想パーティション603−1の名前(すなわち“/dev/xvda3”)から、以下の(15a)〜(15c)を含む領域情報を取得する。

0248

(15a)仮想ディスク604−1の名前(すなわち“/dev/xvda”)。
(15b)仮想パーティション603−1の、仮想ディスク604−1上での開始位置を示すアドレスB1。
(15c)仮想パーティション603−1のサイズC。

0249

なお、ステップS301における領域情報の取得のための具体的方法は実施形態に応じて様々であってよい。ここで、一例として、図11の方法について説明する。図11は、デバイスの領域情報を取得する処理のフローチャートである。

0250

図11に示す処理は、フロントエンドコンポーネント412内の要求部414によって実行されてもよいし、後述するように、バックエンドコンポーネント423内の受付部424によって実行されてもよい。要求部414が図11の処理を実行する場合は、仮想デバイス(具体的には仮想パーティションまたは仮想ディスク)の名前から、当該仮想デバイスについての領域情報が得られる。他方、受付部424が図11の処理を実行する場合は、実デバイス(具体的には実パーティションまたは実ディスク)の名前から、当該実デバイスについての領域情報が得られる。以下では、図10のステップS301において要求部414が図11の処理を実行する場合を例として、説明する。

0251

なお、説明の便宜上、図11では、領域情報を取得する対象のデバイスの名前を“d”と表記してある。例えば、要求部414がステップS301で、仮想パーティション603−1の名前(すなわち“/dev/xvda3”)から領域情報を取得しようとする場合、図11におけるデバイス名dは、“/dev/xvda3”である。

0252

ステップS401で要求部414は、デバイス名dのデバイスをオープンして、ファイルディスクリプタを取得する。以下では説明の便宜上、取得されたファイルディスクリプタを、“f”という符号で参照する。要求部414は、仮想マシン410のゲストOSが提供するシステムコールを利用することで、デバイス名dのデバイスをオープンすることができる。

0253

次に、ステップS402で要求部414は、例えばioctl(f,HDIO_GETGEO)というシステムコールを実行することによって、上記デバイスの開始位置とサイズを取得する。

0254

そして、ステップS403で要求部414は、取得した開始位置が0であるか否かを判断する。
開始位置が0の場合、上記デバイスは、ディスクの一部のパーティションではなく、ディスク全体である。そこで、図11の処理はステップS404へと移行する。

0255

逆に、開始位置が0ではない場合(より具体的には開始位置が0より大きい場合)、上記デバイスは、ディスク上のパーティションである。そこで、図11の処理は、ステップS405へと移行する。

0256

ステップS404で要求部414は、デバイス名dで識別されるデバイスについての領域情報として、以下の(16a)〜(16c)の組を取得する。そして、図11の処理は終了する。

0257

(16a)ディスク名であるデバイス名d。
(16b)0という開始位置。
(16c)ステップS402で取得したサイズ。

0258

例えば、図9の例では、コピー対象(つまりバックアップ対象)のデバイスは仮想パーティション603−1である。しかし、実施形態によっては、アプリケーション411が仮想ディスク604−1全体を利用してもよい。

0259

アプリケーション411が仮想ディスク604−1全体を利用する場合、仮想ディスク604−1全体がバックアップ対象として指定される。つまり、実施形態によっては、図10のステップS301におけるコピー元の仮想デバイスが、仮想ディスク604−1全体であるかもしれない。例えば、コピー元の仮想デバイスが仮想ディスク604−1全体である場合、ステップS404では、“/dev/xdva”という仮想ディスク604−1の名前と、0という開始位置と、B2というサイズが取得される。

0260

さて、開始位置が0ではない場合、ステップS405で要求部414は、以下の(17a)と(17b)から、ディスク名(すなわち、デバイス名dで識別されるパーティションが存在するディスクの名前)を取得する。

0261

(17a)パーティションを示すデバイス名d。
(17b)パーティション名とディスク名の間の対応関係。例えば、「ディスク名の末尾数字をつけた名前が、パーティション名として使われる」などの既知規則により表される対応関係。

0262

例えば、デバイス名dが仮想パーティション603−1の名前(すなわち“/dev/xvda3”)である場合、(17b)の対応関係から、要求部414は、“/dev/xvda”というディスク名を取得する。このディスク名は、図9から理解されるように、仮想パーティション603−1が存在する仮想ディスク604−1の名前である。

0263

そして、次のステップS406で要求部414は、デバイス名dで識別されるデバイスについての領域情報として、以下の(18a)〜(18c)の組を取得する。そして、図11の処理は終了する。

0264

(18a)ステップS405で取得したディスク名。
(18b)ステップS402で取得した開始位置。
(18c)ステップS402で取得したサイズ。

0265

例えば、デバイス名dが“/dev/xvda3”である場合、図9の例によれば、ステップS402で要求部414は、開始位置としてアドレスB1を取得するとともに、サイズとしてCという値を取得する。また、この場合、上記のとおり要求部414は、ステップS405で仮想ディスク604−1のディスク名(つまり“/dev/xvda”)を取得する。よって、要求部414は、“/dev/xvda”というディスク名と、アドレスB1と、サイズCとの組を、仮想パーティション603−1の領域情報として取得する。

0266

以上、図10のステップS301の処理の一例として、図11のフローチャートについて説明した。しかし、もちろん、実施形態に応じて、ステップS301の処理の詳細は様々であってよい。

0267

例えば、図11のフローチャートは、LVM(Logical Volume Manager)などのボリューム管理ソフトウェアが仮想マシン410において使われていない場合に行われる処理を示す。しかし、場合によっては、ボリューム管理ソフトウェアが使われていてもよい。その場合、ステップS301で要求部414は、ボリューム管理ソフトウェアのCLI(Command Line Interface)を介して、コピー元の仮想デバイスの名前から、コピー元の仮想デバイスについての領域情報を取得してもよい。

0268

ここで、図10の説明に戻る。ステップS302で要求部414は、コピー先の仮想デバイスについての領域情報を、コピー先の仮想デバイスの名前dstから取得する。ステップS302で取得される領域情報も、ゲストOSにより認識される領域情報である。ステップS302の処理の詳細は、ステップS301と同様である。

0269

ステップS302で取得される領域情報は、仮想マシン410において認識される1つ以上の仮想ディスク(図9の場合、少なくとも2つの仮想ディスク604−1と604−2)の中で、仮想パーティション603−2を識別する情報の例である。したがって、ステップS302で取得される領域情報は、第1実施形態の(3b)に示した第2の仮想識別情報に対応する。

0270

例えば、図9の例の場合、要求部414はステップS302で、コピー先の仮想パーティション603−2の名前(すなわち“/dev/xvdb3”)から、以下の(19a)〜(19c)を含む領域情報を取得する。

0271

(19a)仮想ディスク604−2の名前(すなわち“/dev/xvdb”)。
(19b)仮想パーティション603−2の、仮想ディスク604−2上での開始位置を示すアドレスE1。
(19c)仮想パーティション603−2のサイズC。

0272

そして、次のステップS303で要求部414は、以下の(20a)〜(20d)の情報を、TCP/IPにしたがって受付部424に通知する。ステップS303での通知は、換言すれば、コピー元の仮想デバイスとコピー先の仮想デバイスについての物理的な領域情報を取得するよう、受付部424に求める要求である。また、ステップS303は図2のステップS105に対応する。

0273

(20a)ステップS301で取得した、コピー元の仮想デバイスについての領域情報のうち仮想ディスクの名前(例えば、(15a)の“/dev/xvda”という名前)。
(20b)ステップS302で取得した、コピー先の仮想デバイスについての領域情報のうち仮想ディスクの名前(例えば、(19a)の“/dev/xvdb”という名前)。
(20c)要求部414が含まれる仮想マシン410のドメイン名。
(20d)要求部414がステップS303で受付部424に要求する処理に対応する特定のAPIを、API群425の中で識別する識別情報(例えば、“7”などの番号で表されるID(identifier))。

0274

なお、要求部414は、図7のステップS204で受付部424のIPアドレスとポート番号を既に取得している。よって、要求部414は、取得したIPアドレスとポート番号を用いて、受付部424との間でTCP/IP通信を行うことができる。TCP/IPを利用することにより、互いに異なる仮想マシンに含まれる要求部414と受付部424との間での通信が可能となる。

0275

受付部424は、要求部414からの通知を受信すると、ステップS304〜S309の処理を行い、ステップS310で要求部414に応答する。ステップS304〜S309は、図2のステップS106に対応し、具体的には以下のとおりである。

0276

ステップS304で受付部424は、コピー元について通知された(20a)の情報(すなわち仮想ディスク名)から、コピー元の実デバイスを識別する識別情報を取得する。具体的には、受付部424は、例えば、“list −−long”オプションを指定したxmコマンドを利用して、コピー元の実デバイスの識別情報を取得してもよい。受付部424は、管理OSの動作する仮想マシン420内にあるので、xmコマンドを呼び出して使うことができる。

0277

例えば図8のコマンド実行例602に示すように、受付部424は、要求部414から通知されたドメイン名(例えば“domA”)をパラメタとして、xmコマンドを呼び出してもよい。参照の便宜のため、図8では適宜改行空白を加えて、コマンド実行例602をS式(S-expression)の形式で示している。

0278

受付部424は、コマンドの実行結果の中から、次の条件(21a)〜(22b)をともに満たすようなS式を検索する。

0279

(21a)“device”タグを持っている。
(21b)要求部414から通知された仮想ディスク名を“dev”タグと対応づけるS式を含んでいる。

0280

コマンド実行例602の場合、“device”タグを持っており、かつ、“(dev xvda:disk)”というS式を含むS式が見つかる。そして、受付部424は、見つかったS式の中で、“uname”タグを含むS式を検索する。コマンド実行例602の場合、“(uname phy:/dev/sda6)”というS式が見つかる。

0281

受付部424は、見つかったS式において“uname”タグと対応づけられている実デバイス名を取得する。コマンド実行例602の場合、“/dev/sda6”という実デバイス名が取得される。こうして取得される“/dev/sda6”という実デバイス名は、図9に示すように、実パーティション605−1(すなわちコピー元の仮想パーティション603−1が物理的に位置している実デバイス)の名前である。

0282

受付部424は、例えば以上のようにして、xmコマンドを利用することで、コピー元の実デバイスの識別情報を取得する。もちろん、実施形態によっては、xmコマンド以外のコマンドが使われてもよい。

0283

次に、ステップS305で受付部424は、コピー先について通知された(20b)の情報(すなわち仮想ディスク名)から、コピー先の実デバイスを識別する識別情報を取得する。例えば、受付部424は、ステップS304で実行したxmコマンドの結果を用いて、ステップS304と同様の方法により、ステップS305でコピー先の実デバイスの識別情報を取得してもよい。

0284

図8のコマンド実行例602によれば、“/dev/xvdb”という仮想ディスク名から“/dev/sdb6”という実デバイス名が取得される。こうして取得される“/dev/sdb6”という実デバイス名は、図9に示すように、実パーティション605−2(すなわちコピー先の仮想パーティション603−2が物理的に位置している実デバイス)の名前である。

0285

そして、ステップS306で受付部424は、コピー元の実デバイスについての領域情報を、ステップS304で取得した識別情報から取得する。ステップS306で取得される領域情報は、管理OSにより認識される領域情報(つまり受付部424が含まれる仮想マシン420から認識される領域情報)であって、具体的には、例えば以下の(22a)〜(22c)を含む。

0286

(22a)実デバイスが存在する実ディスクを識別する情報(例えば、実ディスクに対応するデバイスファイルのパス名)。
(22b)実デバイスの、実ディスク上での開始位置(例えば、LBA番号により表される開始アドレス)。
(22c)実デバイスのサイズ(例えば、LBA番号と同様に512バイトのセクタを単位として表されるサイズ)。

0287

例えば、図9の例の場合、受付部424はステップS306で、コピー元の実パーティション605−1の名前(すなわち“/dev/sda6”)から、以下の(23a)〜(23c)を含む領域情報を取得する。

0288

(23a)実ディスク552−1の名前(すなわち“/dev/sda”)。
(23b)実パーティション605−1の、実ディスク552−1上での開始位置を示すアドレスA1。換言すれば、仮想ディスク604−1が実ディスク552−1上に占める領域の開始位置を示すアドレスA1。
(23c)実パーティション605−1のサイズB2。

0289

なお、ステップS306における領域情報の取得のための具体的方法は実施形態に応じて様々であってよい。例えば、仮想マシン420においてLVMなどのボリューム管理ソフトウェアが使われていなければ、受付部424は、図11のフローチャートにしたがって上記の(22a)〜(22c)を含む領域情報を取得してもよい。図11に関しては、要求部414が図11の処理を行う場合について具体的に説明したが、上記のとおり受付部424が図11の処理を行うこともできる。

0290

あるいは、仮想マシン420においてボリューム管理ソフトウェアが使われていれば、受付部424は、ボリューム管理ソフトウェアのCLIを介して、コピー元の実デバイスの名前から、コピー元の実デバイスについての領域情報を取得してもよい。

0291

次に、ステップS307で受付部424は、コピー先の実デバイスについての領域情報を、ステップS305で取得した識別情報から取得する。ステップS307で取得される領域情報も、管理OSにより認識される領域情報である。ステップS307の詳細は、ステップS306と同様である。

0292

例えば、図9の例の場合、受付部424はステップS307で、コピー先の実パーティション605−2の名前(すなわち”/dev/sdb6”)から、以下の(24a)〜(24c)を含む領域情報を取得する。

0293

(24a)実ディスク552−2の名前(すなわち“/dev/sdb”)。
(24b)実パーティション605−2の、実ディスク552−2上での開始位置を示すアドレスD1。換言すれば、仮想ディスク604−2が実ディスク552−2上に占める領域の開始位置を示すアドレスD1。
(24c)実パーティション605−2のサイズE2。

0294

そして、次のステップS308で受付部424は、コンピュータ400に接続された1つまたは複数のストレージシステム440(例えば図6では2つのストレージシステム550と560)の中でコピー元の実ディスク552−1を識別する識別情報を取得する。ステップS308における識別情報の取得は、具体的には、API群425のうちで、ステップS303の通知中の(20d)の識別情報で識別される特定のAPIを介して、行われる。以下では説明の便宜上、この特定のAPIを「ボリューム取得API」と呼ぶことにする。

0295

例えば、図6のストレージシステム550と560が、いずれも、SCSIコマンドを受け付けるRAIDシステムであるとする。この場合、ステップS308で受付部424は、具体的には、実ディスク552−1に対するSCSIコマンドを、ボリューム取得APIを介して発行する。

0296

例えば、SCSIコマンドは、次のようにして発行されてもよい。受付部424は、実ディスク552−1の名前をパラメタに指定して、ボリューム取得APIを呼び出す。すると、ボリューム取得APIにより、指定された名前のデバイスファイルがオープンされて、ファイルディスクリプタが取得される。さらに、取得されたファイルディスクリプタとSCSIコマンドの内容がパラメタとして指定されたioctl()システムコールが、ボリューム取得APIから呼び出される。

0297

SCSIコマンドの発行は、例えば以上のような一連の処理によって実現されてもよい。発行されたSCSIコマンドは、ホストバスアダプタ507とSAN540を介して送信される。

0298

受付部424は、SCSIコマンドに対する応答として、ストレージシステム550と560の中で実ディスク552−1を識別する識別情報を、実ディスク552−1を含む方のストレージシステム550から取得する。取得される識別情報は、具体的には、以下の(25a)〜(25b)を含む。

0299

(25a)コピー元の実ディスクを有するストレージシステムの識別情報(以下、ストレージシステムIDともいう)。例えば、実ディスク552−1を含むストレージシステム550のID(例えば、“1”などの番号で表されるID)。
(25b)上記(25a)の識別情報で識別されるストレージシステムのディスクアレイ内において、コピー元の実ディスクに対応するボリュームを識別する識別情報(以下、ボリュームIDともいう)。例えば、ストレージシステム550内で実ディスク552−1に対応するボリュームを識別するために使われ、ストレージシステム550内で一意のID(例えば、“2”などの番号で表されるID)。ボリュームIDは、具体的にはLUN(Logical Unit Number)であってもよい。

0300

さらに、ステップS309で受付部424は、コンピュータ400に接続された1つまたは複数のストレージシステム440(例えば図6では2つのストレージシステム550と560)の中でコピー先の実ディスク552−2を識別する識別情報を取得する。ステップS309の詳細はステップS308と同様である。受付部424は、ボリューム取得APIを介して、例えば以下の(26a)〜(26b)を含む識別情報を、実ディスク552−2を含むストレージシステム550から取得する。

0301

(26a)実ディスク552−2を含むストレージシステム550のストレージシステムID。
(26b)ストレージシステム550のディスクアレイ内において、実ディスク552−2に対応するボリュームを識別するボリュームID。

0302

そして、次のステップS310で受付部424は、ステップS304〜S309の処理により取得した情報を、要求部414に通知する。ステップS310の通知はステップS303の要求に対する応答である。

0303

ステップS310での通知も、TCP/IPにしたがって行われる。また、ステップS310では、具体的には以下の(27a)〜(27g)の情報が通知される。

0304

(27a)処理結果を示す情報(例えば、復帰コードエラー番号の組み合わせ)。
(27b)ステップS308で取得されたストレージシステムID(例えば、ストレージシステム550のID)。
(27c)ステップS308で取得されたボリュームID(例えば、ストレージシステム550内で実ディスク552−1に対応するボリュームのID)。
(27d)ステップS306で取得された開始位置(例えば、アドレスA1)。
(27e)ステップS309で取得されたストレージシステムID(例えば、ストレージシステム550のID)。
(27f)ステップS309で取得されたボリュームID(例えば、ストレージシステム550内で実ディスク552−2に対応するボリュームのID).
(27g)ステップS307で取得された開始位置(例えば、アドレスD1)。

0305

なお、今までの説明においては、簡単化のためエラー処理について特に言及しなかった。しかし、場合によっては、何らかのエラーが生じることもあり得る。何らかのエラーが生じた場合、上記(27b)〜(27g)の項目はすべて無効な値でもよい。

0306

以下では説明の簡単化のため、エラーが生じなかったものとする。つまり、(27a)の復帰コードは成功を示す値であるものとする。

0307

受付部424からの応答を受信すると、要求部414はステップS311で、コピー元の仮想デバイスの実ディスク上での開始位置を計算する。具体的には、要求部414は、受付部424からの応答に含まれる(27d)の開始位置と、ステップS301で取得した(14b)の開始位置とを足す。

0308

図9の例によれば、コピー元の仮想デバイスは仮想パーティション603−1であり、(27d)の開始位置はアドレスA1であり、(14b)の開始位置は(15b)に例示したとおりアドレスB1である。よって、要求部414は、アドレスA1とB1を足す。その結果、仮想パーティション603−1の実ディスク552−1上での開始位置である、アドレス(A1+B1)が得られる。

0309

以上のようにして、第2実施形態においても、第1実施形態の(4a)に示した第1の実識別情報に相当する情報が取得される。つまり、1つ以上の実ディスク(図9の場合、少なくとも2つの実ディスク552−1と552−2)の中で、仮想パーティション603−1が占める記憶領域を識別する情報が取得される。

0310

1つの観点から見れば、(23a)の実ディスク名(すなわち“/dev/sda”)と、ステップS311で計算されたアドレス(A1+B1)の組み合わせが、第1の実識別情報に相当する。別の観点から見れば、(25a)のストレージシステムIDと、(25b)のボリュームIDと、ステップS311で計算されたアドレス(A1+B1)の組み合わせが、第1の実識別情報に相当する。しかし、いずれにしろ、第1の実識別情報に相当する情報は、コンピュータ400がバックエンドコンポーネント423にしたがって動作した結果に基づいて、取得される。

0311

また、要求部414はステップS312で、コピー先の仮想デバイスの実ディスク上での開始位置を計算する。具体的には、要求部414は、受付部424からの応答に含まれる(27g)の開始位置と、ステップS302で取得した開始位置(例えば(19b)に例示した開始位置)とを足す。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 富士ゼロックス株式会社の「 データ管理システム」が 公開されました。( 2020/09/24)

    【課題】階層構造になっている管理システムにおいて、管理対象データの実体を最上位の装置が全て管理する場合と比較して、管理対象データがユーザの意図しない装置に提供されないシステムを提供する。【解決手段】管... 詳細

  • 株式会社ウフルの「 デバイス管理システム、デバイス管理方法、情報処理装置、及びプログラム」が 公開されました。( 2020/09/24)

    【課題】デバイスの信頼性を向上可能なデバイス管理システム、デバイス管理方法、情報処理装置、デバイス及びプログラムを提供する。【解決手段】デバイス管理システム1は、複数の情報処理装置2をネットワーク3で... 詳細

  • 本田技研工業株式会社の「 サーバ」が 公開されました。( 2020/09/24)

    【課題】車両の利用者が、該利用者の生活圏外の人であって前記利用者の属性に類似した属性を持つ地域人(地元民)が利用したPOI情報をリコメンドとして受けることができるサーバを提供する。【解決手段】サーバ1... 詳細

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ