特開 2023-174559 コンテナ環境にボリュームを提供するための方法およびシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023174559

(43)【公開日】2023-12-07

(54)【発明の名称】コンテナ環境にボリュームを提供するための方法およびシステム

(51)【国際特許分類】

   G06F 3/06 20060101AFI20231130BHJP

   H04L 67/1097 20220101ALI20231130BHJP

   G06F 13/10 20060101ALI20231130BHJP

【ＦＩ】

G06F3/06 301Z

H04L67/1097

G06F13/10 340A

【審査請求】未請求

【請求項の数】20

【出願形態】ＯＬ

【外国語出願】

(21)【出願番号】P 2023080323

(22)【出願日】2023-05-15

(31)【優先権主張番号】10-2022-0065509

(32)【優先日】2022-05-27

(33)【優先権主張国・地域又は機関】KR

(71)【出願人】

【識別番号】516014409

【氏名又は名称】ライン プラス コーポレーション

【氏名又は名称原語表記】ＬＩＮＥ Ｐｌｕｓ Ｃｏｒｐｏｒａｔｉｏｎ

(74)【代理人】

【識別番号】110002952

【氏名又は名称】弁理士法人鷲田国際特許事務所

(72)【発明者】

【氏名】キム テウク

(72)【発明者】

【氏名】オ ヨンソク

(72)【発明者】

【氏名】ヨン ジェソン

(72)【発明者】

【氏名】イ ウンジェ

(72)【発明者】

【氏名】ソン ドンス

(57)【要約】

【課題】コンテナ環境にボリュームを提供するための方法およびシステムを提供する。
【解決手段】一実施形態に係るボリューム提供方法は、コンテナ環境のクライアントからボリューム生成要求を受信する段階、前記ボリューム生成要求にしたがってボリュームのメタデータをデータベースに格納する段階、前記ボリュームを生成する前記バックエンドストレージのボリュームノードをスケジューリングする段階、および前記スケジューリングによって選定されたボリュームノードに、前記ボリュームに対応する論理ボリューム（Ｌｏｇｉｃａｌ Ｖｏｌｕｍｅ：ＬＶ）の生成を要求する段階を含む。
【選択図】図４

【特許請求の範囲】

【請求項1】

バックエンドストレージを実現するコンピュータ装置のボリューム提供方法であって、
前記コンピュータ装置が含む少なくとも１つのプロセッサにより、コンテナ環境のクライアントからボリューム生成要求を受信する段階、
前記少なくとも１つのプロセッサにより、前記ボリューム生成要求にしたがってボリュームのメタデータをデータベースに格納する段階、
前記少なくとも１つのプロセッサにより、前記ボリュームを生成する前記バックエンドストレージのボリュームノードをスケジューリングする段階、および
前記少なくとも１つのプロセッサにより、前記スケジューリングによって選定されたボリュームノードに、前記ボリュームに対応する論理ボリューム（Ｌｏｇｉｃａｌ Ｖｏｌｕｍｅ：ＬＶ）の生成を要求する段階
を含む、ボリューム提供方法。

【請求項2】

前記ボリューム生成要求は、前記クライアントでＰＶＣ（Ｐｅｒｓｉｓｔｅｎｃｅ Ｖｏｌｕｍｅ Ｃｌａｉｍ）が生成されることによる前記クライアントのＡＰＩ呼び出しによって受信されることを特徴とする、請求項１に記載のボリューム提供方法。

【請求項3】

前記スケジューリングする段階は、
スケジューリングアルゴリズムによって前記ボリュームノードをスケジューリングするモジュールを呼び出した後、前記選定されたボリュームノードからの応答とは関係なく、前記ボリューム生成要求に対する応答を前記クライアントに伝送する段階、および
前記呼び出されたモジュールを利用した前記スケジューリングによって、複数のボリュームノードのうちから１つのボリュームノードを選定する段階
を含む、請求項１に記載のボリューム提供方法。

【請求項4】

前記クライアントに伝送された応答に基づいて前記クライアントでボリュームを管理するＰＶ（Ｐｅｒｓｉｓｔｅｎｃｅ Ｖｏｌｕｍｅ）が生成され、前記ボリューム生成要求を送信したＰＶＣとバインディングされることを特徴とする、請求項３に記載のボリューム提供方法。

【請求項5】

前記選定されたボリュームノードへの要求にしたがって、前記選定されたボリュームノードで前記ボリュームに対応する論理ボリュームが生成されることを特徴とする、請求項１に記載のボリューム提供方法。

【請求項6】

前記少なくとも１つのプロセッサにより、前記クライアントからボリューム削除要求を受信する段階、および
前記少なくとも１つのプロセッサにより、前記ボリューム削除要求を、メッセージキューを利用して前記選定されたボリュームノードに伝送する段階
をさらに含む、請求項１に記載のボリューム提供方法。

【請求項7】

前記ボリューム削除要求にしたがって、前記選定されたボリュームノードから対応する論理ボリュームが削除されることを特徴とする、請求項６に記載のボリューム提供方法。

【請求項8】

バックエンドストレージを実現するコンピュータ装置のボリューム提供方法であって、
前記コンピュータ装置が含む少なくとも１つのプロセッサにより、コンテナ環境のクライアントからボリュームエクスポート要求を受信する段階、
前記少なくとも１つのプロセッサにより、前記ボリュームエクスポート要求にしたがって対応するボリュームを管理するボリュームノードにターゲットの生成およびエクスポートを要求する段階、
前記少なくとも１つのプロセッサにより、前記ボリュームノードからエクスポートされたターゲットの情報を受信する段階、および
前記少なくとも１つのプロセッサにより、前記受信されたターゲットの情報を前記クライアントに伝送する段階
を含む、ボリューム提供方法。

【請求項9】

前記ボリュームエクスポート要求は、前記クライアントでＰｏｄが生成されることによる前記クライアントのＡＰＩ呼び出しによって受信されることを特徴とする、請求項８に記載のボリューム提供方法。

【請求項10】

前記ターゲットの生成およびエクスポート要求に応答して前記ボリュームノードで前記ボリュームノードに生成された論理ボリュームに対応するターゲットが生成およびエクスポートされ、前記生成されたターゲットの情報が前記コンピュータ装置に伝送されることを特徴とする、請求項８に記載のボリューム提供方法。

【請求項11】

前記ターゲットの情報は、前記ボリュームノードであるホストのＩＰ、ポート、および前記ターゲットの識別子を含むことを特徴とする、請求項８に記載のボリューム提供方法。

【請求項12】

前記ターゲットの情報に基づいて前記クライアントで前記ターゲットにアクセスすることによって前記ターゲットが前記クライアントのブロックデバイスにマッピングされ、
前記クライアントで生成されたＰｏｄが前記ブロックデバイスにバインディングされて、前記ターゲットに対応する前記ボリュームノードの論理ボリュームにアクセス可能になることを特徴とする、請求項８に記載のボリューム提供方法。

【請求項13】

前記少なくとも１つのプロセッサにより、前記クライアントからエクスポート除去要求を受信する段階、および
前記少なくとも１つのプロセッサにより、前記エクスポート除去要求を、メッセージキューを利用して前記ボリュームノードに伝送する段階
をさらに含むことを特徴とする、請求項８に記載のボリューム提供方法。

【請求項14】

前記エクスポート除去要求にしたがって、前記ボリュームノードから前記ターゲットを除去することを特徴とする、請求項１３に記載のボリューム提供方法。

【請求項15】

請求項１～１４のうちのいずれか一項に記載の方法を前記コンピュータ装置に実行させるためのコンピュータプログラム。

【請求項16】

コンピュータ装置であって、
前記コンピュータ装置で読み取り可能な命令を実行するように実現される少なくとも１つのプロセッサ
を含み、
前記少なくとも１つのプロセッサにより、
コンテナ環境のクライアントからボリューム生成要求を受信する段階、
前記ボリューム生成要求にしたがってボリュームのメタデータをデータベースに格納する段階、
前記ボリュームを生成するバックエンドストレージのボリュームノードをスケジューリングする段階、および
前記スケジューリングによって選定されたボリュームノードに、前記ボリュームに対応する論理ボリューム（Ｌｏｇｉｃａｌ Ｖｏｌｕｍｅ：ＬＶ）の生成を要求すること
を特徴とする、コンピュータ装置。

【請求項17】

前記ボリューム生成要求は、前記クライアントでＰＶＣ（Ｐｅｒｓｉｓｔｅｎｃｅ Ｖｏｌｕｍｅ Ｃｌａｉｍ）が生成されることによる前記クライアントのＡＰＩ呼び出しによって受信されること
を特徴とする、請求項１６に記載のコンピュータ装置。

【請求項18】

前記スケジューリングのために、前記少なくとも１つのプロセッサにより、
スケジューリングアルゴリズムによって前記ボリュームノードをスケジューリングするモジュールを呼び出した後、前記選定されたボリュームノードからの応答とは関係なく、前記ボリューム生成要求に対する応答を前記クライアントに伝送し、
前記呼び出されたモジュールを利用した前記スケジューリングによって、複数のボリュームノードのうちから１つのボリュームノードを選定すること
を特徴とする、請求項１６に記載のコンピュータ装置。

【請求項19】

コンピュータ装置であって、
前記コンピュータ装置で読み取り可能な命令を実行するように実現される少なくとも１つのプロセッサ
を含み、
前記少なくとも１つのプロセッサにより、
コンテナ環境のクライアントからボリュームエクスポート要求を受信し、
前記ボリュームエクスポート要求にしたがって対応するボリュームを管理するボリュームノードに、ターゲットの生成およびエクスポートを要求し、
前記ボリュームノードからエクスポートされたターゲットの情報を受信し、
前記受信されたターゲットの情報を前記クライアントに伝送すること
を特徴とする、コンピュータ装置。

【請求項20】

前記ボリュームエクスポート要求は、前記クライアントでＰｏｄが生成されることによる前記クライアントのＡＰＩ呼び出しによって受信されること
を特徴とする、請求項１９に記載のコンピュータ装置。

【発明の詳細な説明】

【技術分野】

【0001】

以下の説明は、コンテナ環境にボリュームを提供するための方法およびシステムに関する。

【背景技術】

【0002】

ローカルコンピュータ環境では、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）やメモリなどがＳＡＴＡ（Ｓｅｒｉａｌ Ａｄｖａｎｃｅｄ Ｔｅｃｈｎｏｌｏｇｙ Ａｔｔａｃｈｍｅｎｔ）プロトコルに基づいてＳＡＴＡ ＳＳＤ（ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）と入力／出力を実行したり、ＮＶＭｅ（Ｎｏｎ Ｖｏｌａｔｉｌｅ Ｍｅｍｏｒｙ ｅｘｐｒｅｓｓ）プロトコルに基づいてＮＶＭｅ ＳＳＤと入力／出力を実行したりするなど、各自の通信規格に基づいてストレージとの通信を処理する。

【0003】

この反面、クライアント－サーバ環境でクライアントがサーバのＮＶＭｅ ＳＳＤを利用しようとする場合、クライアントがネットワークを介してサーバのＮＶＭｅ ＳＳＤにＮＶＭｅプロトコルに基づいてアクセスできるようにするためのＮＶＭｅ ｏＦ（ＮＶＭｅｏｖｅｒＦａｂｒｉｃｓ）技術が存在する。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】韓国公開特許第２０１９－０１０６６８０号公報

【発明の概要】

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

【0005】

クライアント－サーバ環境において、クライアントがサーバのストレージを使用できるようにサーバからクライアントにボリュームを提供することができる、ボリューム提供方法およびシステムを提供する。

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

【0006】

バックエンドストレージを実現するコンピュータ装置のボリューム提供方法であって、前記コンピュータ装置が含む少なくとも１つのプロセッサにより、コンテナ環境のクライアントからボリューム生成要求を受信する段階、前記少なくとも１つのプロセッサにより、前記ボリューム生成要求にしたがってボリュームのメタデータをデータベースに格納する段階、前記少なくとも１つのプロセッサにより、前記ボリュームを生成する前記バックエンドストレージのボリュームノードをスケジューリングする段階、および前記少なくとも１つのプロセッサにより、前記スケジューリングによって選定されたボリュームノードに、前記ボリュームに対応する論理ボリューム（Ｌｏｇｉｃａｌ Ｖｏｌｕｍｅ：ＬＶ）の生成を要求する段階を含む、ボリューム提供方法を提供する。

【0007】

一側によると、前記ボリューム生成要求は、前記クライアントでＰＶＣ（Ｐｅｒｓｉｓｔｅｎｃｅ Ｖｏｌｕｍｅ Ｃｌａｉｍ）が生成されることによる前記クライアントのＡＰＩ呼び出しによって受信されることを特徴としてよい。

【0008】

他の側面によると、前記スケジューリングする段階は、スケジューリングアルゴリズムによって前記ボリュームノードをスケジューリングするモジュールを呼び出した後、前記選定されたボリュームノードからの応答とは関係なく前記ボリューム生成要求に対する応答を前記クライアントに伝送する段階、および前記呼び出されたモジュールを利用した前記スケジューリングによって、複数のボリュームノードのうちから１つのボリュームノードを選定する段階を含むことを特徴としてよい。

【0009】

また他の側面によると、前記クライアントに伝送された応答に基づいて前記クライアントでボリュームを管理するＰＶ（Ｐｅｒｓｉｓｔｅｎｃｅ Ｖｏｌｕｍｅ）が生成されて、前記ボリューム生成要求を送信したＰＶＣとバインディングされることを特徴としてよい。

【0010】

また他の側面によると、前記選定されたボリュームノードへの要求にしたがって、前記選定されたボリュームノードで前記ボリュームに対応する論理ボリュームが生成されることを特徴としてよい。

【0011】

また他の側面によると、前記ボリューム提供方法は、前記少なくとも１つのプロセッサにより、前記クライアントからボリューム削除要求を受信する段階、および前記少なくとも１つのプロセッサにより、メッセージキューを利用して前記ボリューム削除要求を前記選定されたボリュームノードに伝送する段階をさらに含んでよい。

【0012】

さらに他の側面によると、前記ボリューム削除要求にしたがって、前記選定されたボリュームノードから対応する論理ボリュームが削除されることを特徴としてよい。

【0013】

バックエンドストレージを実現するコンピュータ装置のボリューム提供方法であって、前記コンピュータ装置が含む少なくとも１つのプロセッサにより、コンテナ環境のクライアントからボリュームエクスポート要求を受信する段階、前記少なくとも１つのプロセッサにより、前記ボリュームエクスポート要求にしたがって、対応するボリュームを管理するボリュームノードにターゲットの生成およびエクスポートを要求する段階、前記少なくとも１つのプロセッサにより、前記ボリュームノードからエクスポートされたターゲットの情報を受信する段階、および前記少なくとも１つのプロセッサにより、前記受信されたターゲットの情報を前記クライアントに伝送する段階を含む、ボリューム提供方法を提供する。

【0014】

一側によると、前記ボリュームエクスポート要求は、前記クライアントでＰｏｄが生成されることによる前記クライアントのＡＰＩ呼び出しによって受信されることを特徴としてよい。

【0015】

他の側面によると、前記ターゲットの生成およびエクスポート要求に応答して前記ボリュームノードで前記ボリュームノードに生成された論理ボリュームに対応するターゲットが生成およびエクスポートされ、前記生成されたターゲットの情報が前記コンピュータ装置に伝送されることを特徴としてよい。

【0016】

また他の側面によると、前記ターゲットの情報は、前記ボリュームノードであるホストのＩＰ、ポート、および前記ターゲットの識別子を含むことを特徴としてよい。

【0017】

また他の側面によると、前記ターゲットの情報に基づいて前記クライアントから前記ターゲットにアクセスすることにより、前記ターゲットが前記クライアントのブロックデバイスにマッピングされ、前記クライアントで生成されたＰｏｄが前記ブロックデバイスにバインディングされることで、前記ターゲットに対応する前記ボリュームノードの論理ボリュームにアクセスできるようになることを特徴としてよい。

【0018】

また他の側面によると、前記ボリューム提供方法は、前記少なくとも１つのプロセッサにより、前記クライアントからエクスポート除去要求を受信する段階、および前記少なくとも１つのプロセッサにより、メッセージキューを利用して前記エクスポート除去要求を前記ボリュームノードに伝送する段階をさらに含んでよい。

【0019】

さらに他の側面によると、前記エクスポート除去要求にしたがって前記ボリュームノードから前記ターゲットを除去することを特徴としてよい。

【0020】

コンピュータ装置と結合して前記方法をコンピュータ装置に実行させるためにコンピュータ読み取り可能な記録媒体に記録される、コンピュータプログラムを提供する。

【0021】

前記方法をコンピュータ装置に実行させるためのプログラムが記録されている、コンピュータ読み取り可能な記録媒体を提供する。

【0022】

コンピュータ装置であって、前記コンピュータ装置で読み取り可能な命令を実行するように実現される少なくとも１つのプロセッサを含み、前記少なくとも１つのプロセッサにより、コンテナ環境のクライアントからボリューム生成要求を受信する段階、前記ボリューム生成要求にしたがってボリュームのメタデータをデータベースに格納する段階、前記ボリュームを生成する前記バックエンドストレージのボリュームノードをスケジューリングする段階、および前記スケジューリングによって選定されたボリュームノードに、前記ボリュームに対応する論理ボリューム（Ｌｏｇｉｃａｌ Ｖｏｌｕｍｅ：ＬＶ）の生成を要求することを特徴とする、コンピュータ装置を提供する。

【0023】

コンピュータ装置であって、前記コンピュータ装置で読み取り可能な命令を実行するように実現される少なくとも１つのプロセッサを含み、前記少なくとも１つのプロセッサにより、コンテナ環境のクライアントからボリュームエクスポート要求を受信し、前記ボリュームエクスポート要求にしたがって、対応するボリュームを管理するボリュームノードにターゲットの生成およびエクスポートを要求し、前記ボリュームノードからエクスポートされたターゲットの情報を受信し、前記受信されたターゲットの情報を前記クライアントに伝送することを特徴とする、コンピュータ装置を提供する。

【発明の効果】

【0024】

クライアント－サーバ環境において、クライアントがサーバのストレージを使用できるようにサーバからクライアントにボリュームを提供することができる。

【図面の簡単な説明】

【0025】

【図1】本発明の一実施形態における、ネットワーク環境の例を示した図である。

【図2】本発明の一実施形態における、コンピュータ装置の例を示したブロック図である。

【図3】本発明の一実施形態における、クラウドストレージ環境の例を示した図である。

【図4】本発明の一実施形態における、ボリューム生成の過程の例を示した図である。

【図5】本発明の一実施形態における、ボリュームアタッチメントの過程の例を示した図である。

【図6】本発明の一実施形態における、ボリュームデタッチメントの過程の例を示した図である。

【図7】本発明の一実施形態における、ボリューム削除の過程の例を示した図である。

【図8】本発明の一実施形態における、バックエンドストレージ観点でのボリューム生成の過程の例を示した図である。

【図9】本発明の一実施形態における、バックエンドストレージ観点でのボリュームアタッチメントの過程の例を示した図である。

【図10】本発明の一実施形態における、バックエンドストレージ観点でのボリュームデタッチメントの過程の例を示した図である。

【図11】本発明の一実施形態における、バックエンドストレージ観点でのボリューム削除の過程の例を示した図である。

【発明を実施するための形態】

【0026】

以下、実施形態について、添付の図面を参照しながら詳しく説明する。

【0027】

本発明の実施形態に係るボリューム提供システムは、少なくとも１つのコンピュータ装置によって実現されてよい。このとき、コンピュータ装置においては、本発明の一実施形態に係るコンピュータプログラムがインストールされて実行されてよく、コンピュータ装置は、実行されたコンピュータプログラムの制御にしたがって本発明の実施形態に係るボリューム提供方法を実行してよい。上述したコンピュータプログラムは、コンピュータ装置と結合してボリューム提供方法をコンピュータに実行させるためにコンピュータ読み取り可能な記録媒体に記録されてよい。

【0028】

図１は、本発明の一実施形態における、ネットワーク環境の例を示した図である。図１のネットワーク環境は、複数の電子機器１１０、１２０、１３０、１４０、複数のサーバ１５０、１６０、およびネットワーク１７０を含む例を示している。このような図１は、発明の説明のための一例に過ぎず、電子機器の数やサーバの数が図１のように限定されることはない。また、図１のネットワーク環境は、本実施形態に適用可能な環境のうちの一例を説明したものに過ぎず、本実施形態に適用可能な環境が図１のネットワーク環境に限定されることはない。

【0029】

複数の電子機器１１０、１２０、１３０、１４０は、コンピュータ装置によって実現される固定端末や移動端末であってよい。複数の電子機器１１０、１２０、１３０、１４０の例としては、スマートフォン、携帯電話、ナビゲーションシステム、ＰＣ（ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ）、ノート型ＰＣ、デジタル放送用端末、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、ＰＭＰ（Ｐｏｒｔａｂｌｅ Ｍｕｌｔｉｍｅｄｉａ Ｐｌａｙｅｒ）、タブレットなどがある。一例として、図１では、電子機器１１０の例としてスマートフォンを示しているが、本発明の実施形態において、電子機器１１０は、実質的に無線または有線通信方式を利用し、ネットワーク１７０を介して他の電子機器１２０、１３０、１４０および／またはサーバ１５０、１６０と通信することのできる多様な物理的なコンピュータ装置のうちの１つを意味してよい。

【0030】

通信方式は、限定されることはなく、ネットワーク１７０が含むことのできる通信網（一例として、移動通信網、有線インターネット、無線インターネット、放送網）を利用する通信方式だけではなく、機器間の近距離無線通信が含まれてもよい。例えば、ネットワーク１７０は、ＰＡＮ（ｐｅｒｓｏｎａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ＬＡＮ（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ＣＡＮ（ｃａｍｐｕｓ ａｒｅａ ｎｅｔｗｏｒｋ）、ＭＡＮ（ｍｅｔｒｏｐｏｌｉｔａｎ ａｒｅａ ｎｅｔｗｏｒｋ）、ＷＡＮ（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）、ＢＢＮ（ｂｒｏａｄｂａｎｄ ｎｅｔｗｏｒｋ）、インターネットなどのネットワークのうちの１つ以上の任意のネットワークを含んでよい。さらに、ネットワーク１７０は、バスネットワーク、スターネットワーク、リングネットワーク、メッシュネットワーク、スター－バスネットワーク、ツリーまたは階層的ネットワークなどを含むネットワークトポロジのうちの任意の１つ以上を含んでもよいが、これらに限定されることはない。

【0031】

サーバ１５０、１６０それぞれは、複数の電子機器１１０、１２０、１３０、１４０とネットワーク１７０を介して通信して命令、コード、ファイル、コンテンツ、サービスなどを提供する１つ以上のコンピュータ装置によって実現されてよい。例えば、サーバ１５０は、ネットワーク１７０を介して接続した複数の電子機器１１０、１２０、１３０、１４０にサービス（一例として、クラウドサービス、インスタントメッセージングサービス、取引（一例として、送金）サービス、決済サービス、仮想取引所サービス、リスクモニタリングサービス、ゲームサービス、グループ通話サービス（または、音声会議サービス）、メッセージングサービス、メールサービス、ソーシャルネットワークサービス、地図サービス、翻訳サービス、検索サービス、および／またはコンテンツ提供サービスなど）を提供するシステムであってよい。

【0032】

図２は、本発明の一実施形態における、コンピュータ装置の例を示したブロック図である。上述した複数の電子機器１１０、１２０、１３０、１４０それぞれやサーバ１５０、１６０それぞれは、図２に示したコンピュータ装置２００によって実現されてよい。

【0033】

このようなコンピュータ装置２００は、図２に示すように、メモリ２１０、プロセッサ２２０、通信インタフェース２３０、および入力／出力インタフェース２４０を含んでよい。メモリ２１０は、コンピュータ読み取り可能な記録媒体であって、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、およびディスクドライブのような永続的大容量記録装置を含んでよい。ここで、ＲＯＭやディスクドライブのような永続的大容量記録装置は、メモリ２１０とは区別される別の永続的記録装置としてコンピュータ装置２００に含まれてもよい。また、メモリ２１０には、オペレーティングシステムと、少なくとも１つのプログラムコードが記録されてよい。このようなソフトウェア構成要素は、メモリ２１０とは別のコンピュータ読み取り可能な記録媒体からメモリ２１０にロードされてよい。このような別のコンピュータ読み取り可能な記録媒体は、フロッピー（登録商標）ドライブ、ディスク、テープ、ＤＶＤ／ＣＤ－ＲＯＭドライブ、メモリカードなどのコンピュータ読み取り可能な記録媒体を含んでよい。他の実施形態において、ソフトウェア構成要素は、コンピュータ読み取り可能な記録媒体ではない通信インタフェース２３０を通じてメモリ２１０にロードされてもよい。例えば、ソフトウェア構成要素は、ネットワーク１７０を介して受信されるファイルによってインストールされるコンピュータプログラムに基づいてコンピュータ装置２００のメモリ２１０にロードされてよい。

【0034】

プロセッサ２２０は、基本的な算術、ロジック、および入出力演算を実行することにより、コンピュータプログラムの命令を処理するように構成されてよい。命令は、メモリ２１０または通信インタフェース２３０によって、プロセッサ２２０に提供されてよい。例えば、プロセッサ２２０は、メモリ２１０のような記録装置に記録されたプログラムコードにしたがって受信される命令を実行するように構成されてよい。

【0035】

通信インタフェース２３０は、ネットワーク１７０を介してコンピュータ装置２００が他の装置（一例として、上述した記録装置）と互いに通信するための機能を提供してよい。一例として、コンピュータ装置２００のプロセッサ２２０がメモリ２１０のような記録装置に記録されたプログラムコードにしたがって生成した要求や命令、データ、ファイルなどが、通信インタフェース２３０の制御にしたがってネットワーク１７０を介して他の装置に伝達されてよい。これとは逆に、他の装置からの信号や命令、データ、ファイルなどが、ネットワーク１７０を経てコンピュータ装置２００の通信インタフェース２３０を通じてコンピュータ装置２００に受信されてよい。通信インタフェース２３０を通じて受信された信号や命令、データなどは、プロセッサ２２０やメモリ２１０に伝送されてよく、ファイルなどは、コンピュータ装置２００がさらに含むことのできる記録媒体（上述した永続的記録装置）に記録されてよい。

【0036】

入力／出力インタフェース２４０は、入力／出力装置２５０とのインタフェースのための手段であってよい。例えば、入力装置は、マイク、キーボード、またはマウスなどの装置を、出力装置は、ディスプレイ、スピーカのような装置を含んでよい。他の例として、入力／出力インタフェース２４０は、タッチスクリーンのように入力と出力のための機能が１つに統合された装置とのインタフェースのための手段であってもよい。入力／出力装置２５０は、コンピュータ装置２００と１つの装置で構成されてもよい。

【0037】

また、他の実施形態において、コンピュータ装置２００は、図２の構成要素よりも少ないか多くの構成要素を含んでもよい。しかし、大部分の従来技術による構成要素を明確に図に示す必要はない。例えば、コンピュータ装置２００は、上述した入力／出力装置２５０のうちの少なくとも一部を含むように実現されてもよいし、送受信機、データベースなどのような他の構成要素をさらに含んでもよい。

【0038】

図３は、本発明の一実施形態における、クラウドストレージ環境の例を示した図である。図３は、Ｋｕｂｅｒｎｅｔｅｓによって実現されたコンテナ環境のクライアント端３１０と、ＯｐｅｎＳｔａｃｋ－Ｃｉｎｄｅｒによって実現されたクラウド環境のストレージサーバサイド３２０を示している。ここで、ＫｕｂｅｒｎｅｔｅｓとＯｐｅｎＳｔａｃｋ－Ｃｉｎｄｅｒは、オープンソースとして広く知られているものである。

【0039】

本発明の実施形態では、ストレージサーバサイド３２０のストレージサーバに分散されているストレージ（ＮＶＭｅ ＳＳＤｓ）をコンテナ環境のクライアントにどのように提供するかについての方法およびシステムを提供する。ストレージは、可変サイズの論理ボリューム（Ｌｏｇｉｃａｌ Ｖｏｌｕｍｅ：ＬＶ）を生成してよい。一実施形態に係るボリューム提供方法では、クライアントのコンテナが希望とするサイズのボリュームを要求すれば、要求されたサイズの論理ボリュームをサーバからコンテナに提供する方式によってボリュームがコンテナ環境のクライアントに提供されてよい。このとき、ＫｕｂｅｒｎｅｔｅｓにＯｐｅｎＳｔａｃｋ－Ｃｉｎｄｅｒのボリュームを提供するために、コンテナストレージインタフェース（Ｃｏｎｔａｉｎｅｒ Ｓｔｏｒａｇｅ Ｉｎｔｅｒｆａｃｅ：ＣＳＩ）が利用されてよい。このようなボリューム提供方法の具体的な過程については、以下でより詳しく説明する。

【0040】

図４は、本発明の一実施形態における、ボリューム生成の過程の例を示した図である。図４は、Ｋｕｂｅｒｎｅｔｅｓによって実現されたコンテナ環境のクライアントサイド３１０と、ＯｐｅｎＳｔａｃｋ－Ｃｉｎｄｅｒによって実現されたクラウド環境のストレージサーバサイド３２０を示している。クライアントサイド３１０および／またはストレージサーバサイド３２０は、複数が実現されて利用されてもよい。

【0041】

本実施形態において、Ｋｕｂｅｒｎｅｔｅｓ（Ｋ８ｓ）には、ＮＶＭｅ ｏＦ（ＮＶＭｅ ｏｖｅｒ Ｆａｂｒｉｃｓ）のコンテナストレージインタフェースが提供されてよい。コンテナストレージインタフェースのコンポーネントは、大きく、ノード１（ｎｏｄｅ １）４１０に示すように、コントローラプラグイン（Ｃｏｎｔｒｏｌｌｅｒ Ｐｌｕｇｉｎ）４１１と各ノードに含まれるノードプラグイン（Ｎｏｄｅ Ｐｌｕｇｉｎ）４１２で構成されてよい。このとき、コントローラプラグイン４１１は、クライアントサイド３１０でボリュームの生成や削除などの責任を担うコンポーネントであり、ノードプラグイン４１２は、各ノードにボリュームをインポートしてコンテナにボリュームをバインドマウントするコンポーネントであってよい。

【0042】

また、ＯｐｅｎＳｔａｃｋ－Ｃｉｎｄｅｒによって管理されるバックエンドストレージ（Ｂａｃｋｅｎｄ Ｓｔｏｒａｇｅ）であるストレージサーバサイド３２０のマネージャーノード（ｍａｎａｇｅｒ ｎｏｄｅ）４２０は、ｃｉｎｄｅｒ－ａｐｉ４２１とｃｉｎｄｅｒ－ｓｃｈｅｄｕｌｅｒ４２２を含んでよい。ｃｉｎｄｅｒ－ａｐｉ４２１とｃｉｎｄｅｒ－ｓｃｈｅｄｕｌｅｒ４２２は、マネージャーノード４２０でのボリューム管理のために利用されるｄｅｍｏｎであってよい。ストレージサーバサイド３２０のボリュームノード１（ｖｏｌｕｍｅ ｎｏｄｅ １）４３０は、ｃｉｎｄｅｒ－ｖｏｌｕｍｅ４３１を含んでよい。ｃｉｎｄｅｒ－ｖｏｌｕｍｅ４３１は、ボリュームノード１（４３０）に含まれるストレージ（一例として、ＮＶＭｅ ＳＳＤｓ）を管理するｄｅｍｏｎであってよい。ここで、ストレージサーバサイド３２０には多数のボリュームノードが存在してよく、多数のボリュームノードそれぞれは自身のｃｉｎｄｅｒ－ｖｏｌｕｍｅを含んでよい。また、ｄｅｍｏｎは、ソフトウェアモジュールであってよい。図４の実施形態では、マネージャーノード４２０がｃｉｎｄｅｒ－ａｐｉ４２１とｃｉｎｄｅｒ－ｓｃｈｅｄｕｌｅｒ４２２を含む例を説明しているが、ｃｉｎｄｅｒ－ａｐｉ４２１とｃｉｎｄｅｒ－ｓｃｈｅｄｕｌｅｒ４２２は互いに異なるノードに含まれてもよい。例えば、ノード１がｃｉｎｄｅｒ－ａｐｉとｃｉｎｄｅｒ－ｖｏｌｕｍｅ１を含み、ノード２がｃｉｎｄｅｒ－ｓｃｈｅｄｕｌｅｒ４２２とｃｉｎｄｅｒ－ｖｏｌｕｍｅ２を含み、ノード３がｃｉｎｄｅｒ－ｖｏｌｕｍｅ３を含む形態が考慮されてもよい。言い換えれば、多数のボリュームノードのうちの少なくとも１つのボリュームノードが、ｃｉｎｄｅｒ－ａｐｉ４２１とｃｉｎｄｅｒ－ｓｃｈｅｄｕｌｅｒ４２２を含む実施形態が考慮されてもよい。

【0043】

Ｋｕｂｅｒｎｅｔｅｓでボリュームを管理する主体はＰＶ（Ｐｅｒｓｉｓｔｅｎｃｅ Ｖｏｌｕｍｅ）４４０であるが、ユーザはＰＶ４４０に直接アクセスせずにＰＶＣ（Ｐｅｒｓｉｓｔｅｎｃｅ Ｖｏｌｕｍｅ Ｃｌａｉｍ）４５０というオブジェクトを生成（１．ｃｒｅａｔｅ ＰＶＣ）することで、ユーザが希望するボリュームのスペックをＰＶＣ４５０に入力する。一例として、ＮＶＭｅ ＳＳＤｓのボリューム１００ギガバイトを使用するというスペックがＰＶＣ４５０に入力されてよい。このとき、図４の実施形態では、ＮＶＭｅ ｏＦの「ＳｔｏｒａｇｅＣｌａｓｓ」によって「ｔｅｓｔｐｖｃ」という名称のＰＶＣ４５０が生成された例を示している。例えば、ＮＶＭｅ－ｏＦのための「ＳｔｏｒａｇｅＣｌａｓｓ」というオブジェクトが１つ存在し、ＰＶＣ４５０はこの「ＳｔｏｒａｇｅＣｌａｓｓ」をスペックに記入してよい。

【0044】

一方、コントローラプラグイン４１１は、ＰＶＣ４５０の生成をモニタリングしてよく、ＰＶＣ４５０が生成されることを確認することにより、クライアントサイド３１０とストレージサーバサイド３２０の間のエンドポイント（ｅｎｄｐｏｉｎｔ）によってボリューム生成（２．ｃｉｎｄｅｒ ＡＰＩ：ｃｒｅａｔｅ ｖｏｌｕｍｅ）要求を伝送してよい。このとき、ボリューム生成要求は、ｃｉｎｄｅｒ－ａｐｉ４２１に伝送されてよい。言い換えれば、ボリューム生成要求は、クライアントでのＰＶＣ４５０の生成によってクライアントでｃｉｎｄｅｒ－ａｐｉ４２１をＡＰＩ呼び出すことでｃｉｎｄｅｒ－ａｐｉ４２１に伝送されてよい。実施形態によって、コントローラプラグイン４１１は、ｃｉｎｄｅｒ－ａｐｉ４２１にボリューム生成要求を直接送信してもよいし、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）を設定してボリューム生成要求を伝送することも可能である。このとき、ボリューム生成要求は、ＰＶＣの名称（本実施形態では「ｔｅｓｔｐｖｃ」）を含んでよい。

【0045】

ｃｉｎｄｅｒ－ａｐｉ４２１は、ボリューム生成要求にしたがってボリューム４６０を生成（３．ｃｒｅａｔｅ ｖｏｌｕｍｅ）してよい。ボリューム４６０は、データベースに格納されるメタデータの形態で生成されてよい。このとき、生成されるボリューム４６０の名称は、ＰＶＣ４５０の名称と同一であってよい。また、ｃｉｎｄｅｒ－ａｐｉ４２１は、生成されたボリューム４６０によるＬＶ（Ｌｏｇｉｃａｌ Ｖｏｌｕｍｅ）を実際に生成するノード（ストレージサーバとしてのボリュームノード（ｖｏｌｕｍｅ ｎｏｄｅ））を探索するために、ｃｉｎｄｅｒ－ｓｃｈｅｄｕｌｅｒ４２２にスケジューリング要求（４．ｓｃｈｅｄｕｌｉｎｇ）を伝送する。このとき、ｃｉｎｄｅｒ－ａｐｉ４２１とｃｉｎｄｅｒ－ｓｃｈｅｄｕｌｅｒ４２２は非同期的に通信するため、コントローラプラグイン４１１は、スケジューリング要求後すぐにコントローラプラグイン４１１にボリューム生成要求に対する応答を伝送（５．ｒｅｔｕｒｎ ａｆｔｅｒ ｃａｌｌｉｎｇ ｓｃｈｅｄｕｌｉｎｇ）してよい。このとき、ｃｉｎｄｅｒ－ａｐｉ４２１は、ｃｉｎｄｅｒ－ｓｃｈｅｄｕｌｅｒ４２２からの応答や、以下で説明するｃｉｎｄｅｒ－ｖｏｌｕｍｅ４３１またはボリュームノード１（４３０）からの応答とは関係なく、すぐにボリューム生成要求に対する応答をクライアントに伝送してよい。

【0046】

ｃｉｎｄｅｒ－ｓｃｈｅｄｕｌｅｒ４２２は、スケジューリングアルゴリズムに基づいてｃｉｎｄｅｒ－ａｐｉ４２１によって生成されたボリューム４６０による実際のＬＶを生成するノードをスケジューリングしてよい。一例として、ｃｉｎｄｅｒ－ｓｃｈｅｄｕｌｅｒ４２２は、バックエンドストレージに存在する複数のボリュームノードのうちの１つのボリュームノードを実際のＬＶを生成するノードとして選定してよい。図４の実施形態では、ボリュームノード１（４３０）が、実際のＬＶを生成するノードとしてスケジューリングされた例を示している。このとき、ボリュームノード１（４３０）のｃｉｎｄｅｒ－ｖｏｌｕｍｅ４３１は、ストレージ（ＮＶＭｅ ＳＳＤｓ）を利用してボリューム４６０のためのＬＶ４７０を生成してよい。スケジューリングアルゴリズムは、最大能力（ｃａｐａｃｉｔｙ）のノードを探索してスケジューリングする簡単なアルゴリズムを基本アルゴリズムとして利用してよいが、実際の実現によってはスケジューリングのための他の要素がさらに考慮されてもよい。

【0047】

一方、ｃｉｎｄｅｒ－ａｐｉ４２１からの応答を受け取ったコントローラプラグイン４１１は、ＰＶ４４０を生成した後、ＰＶ４４０とＰＶＣ４５０をバインディングしてよい。この場合、ユーザは、ＰＶＣ４５０によって実際のボリュームを使用できる状態であってよい。

【0048】

図４に示したｋｕｂｅｌｅｔ４８０は、以下で説明するＫｕｂｅｒｎｅｔｅｓのＰｏｄとボリュームの生成および処理を担当する。各実施形態において、Ｋｕｂｅｒｎｅｔ４８０は、説明の便宜上、同じ図面符号で表示しているが、実質的にはＫｕｂｅｒｎｅｔｅｓのノードそれぞれに含まれる互いに異なるインスタンスモジュールであってよい。このようなＫｕｂｅｒｎｅｔ４８０については、以下でより詳しく説明する。

【0049】

図５は、本発明の一実施形態における、ボリュームアタッチメントの過程の例を示した図である。図５の実施形態は、ＰＶＣ４５０を利用してコンテナにボリュームを連結する過程の例を示している。

【0050】

一方、図５の実施形態では、ユーザの要求にしたがい、ＰＶ４４０をマウントするＰｏｄ５１０がノード２（５２０）によってスケジューリングされて生成（１．ｃｒｅａｔｅ Ｐｏｄ）された例を示している。この場合、ノード２（５２０）のノードプラグイン５２１は、Ｐｏｄ５１０を確認することによってｃｉｎｄｅｒ－ａｐｉ４２１にエクスポートボリューム（２．ｃｉｎｄｅｒ ＡＰＩ：ｅｘｐｏｒｔ ｖｏｌｕｍｅ）を呼び出してボリュームのエクスポートを要求してよい。より具体的に、Ｐｏｄ５１０の生成を確認する主体は、ｋｕｂｅｌｅｔのＫ８ｓで使用するワーカーノードのエージェントｄｅｍｏｎであってよい。この場合、ｋｕｂｅｌｅｔ４８０がＰｏｄ５１０とボリュームの実際の生成および処理を担当してよい。このとき、生成されたＰｏｄ５１０がＮＶＭｅ－ｏＦボリュームを使用すれば、ｋｕｂｅｌｅｔ４８０がノードプラグイン５２１にボリュームアタッチメントを要求することによって、ノードプラグイン５２１がこのようなＰｏｄ５１０に関する情報の伝送を受け取る。言い換えれば、ノードプラグイン５２１は、Ｐｏｄが生成されることにより、ＡＰＩ呼び出しによってボリュームエクスポート要求をｃｉｎｄｅｒ－ａｐｉ４２１に伝送してよい。この場合、ｃｉｎｄｅｒ－ａｐｉ４２１は、ボリュームノード１（４３０）のｃｉｎｄｅｒ－ｖｏｌｕｍｅ４３１でターゲット５３０を生成してエクスポートせよという命令（３．ｃｒｅａｔｅ ｔａｒｇｅｔ ａｎｄ ｅｘｐｏｒｔ）をする。この場合、このような命令のためのｃｉｎｄｅｒ－ａｐｉ４２１とｃｉｎｄｅｒ－ｖｏｌｕｍｅ４３１は、同期方式で通信してよい。これにより、ｃｉｎｄｅｒ－ａｐｉ４２１は、ｃｉｎｄｅｒ－ｖｏｌｕｍｅ４３１でターゲット５３０を生成することにより、ｃｉｎｄｅｒ－ｖｏｌｕｍｅ４３１が伝送する応答に基づいてホストＩＰ、ポート、サブシステムＮＱＮ（ターゲット５３０の識別子））をノードプラグイン５２１に返信（４．ｒｅｔｕｒｎ ｗｉｔｈ ｈｏｓｔ ＩＰ、ｐｏｒｔ、ｓｕｂｓｙｓｔｅｍ ＮＱＮ）してよい。

【0051】

この場合、ノードプラグイン５２１は、伝送された情報（ホストＩＰ、ポート、およびターゲット５３０の識別子）を利用して、エクスポートされたＬＶ４７０ベースのターゲット５３０にＮＶＭｅ連結を呼び出し（５．ｎｖｍｅ ｃｏｎｎｅｃｔ）してよい。この場合、ターゲット５３０は、ノード２（５２０）のＮＶＭｅタイプのブロックデバイス（ｂｌｏｃｋ ｄｅｖｉｃｅ）５５０にマッピングされてよく、ノード２（５２０）にターゲット５３０がアタッチ（ａｔｔａｃｈ）されれば、ボリューム４６０の状態をｉｎ－ｕｓｅに転換（６．ｃｈａｎｇｅ ｖｏｌｕｍｅ ｓｔａｔｕｓ ｔｏ ｉｎ－ｕｓｅ）することで、ユーザはＮＶＭｅボリュームを利用できるようになる。このために、ノードプラグイン５２１は、エクスポートの生成要求などと同じように、ｃｉｎｄｅｒ－ａｐｉ４２１にクエリを伝送してボリューム４６０の状態をｉｎ－ｕｓｅに転換してよい。この後、ノードプラグイン５２１は、Ｐｏｄ５１０とターゲット５３０がマッピングされたブロックデバイス５５０をバインドマウント（６．ｂｉｎｄ ｍｏｕｎｔ）することにより、ユーザアプリケーションはＰｏｄ５１０によってＮＶＭｅボリュームを使用することができるようになる。一般的なマウントコマンドは新規ディレクトリツリーを生成する反面、バインドマウントは既存のディレクトリツリーをそのまま使用してコンテナにノードのボリュームを付けるのに使用される。言い換えれば、クライアントで生成されたＰｏｄ５１０がブロックデバイス５５０にバインドマウントされ、ターゲット５３０に対応するボリュームノード１（４３０）のＬＶにアクセスできるようにすることができる。

【0052】

図６は、本発明の一実施形態における、ボリュームデタッチメントの過程の例を示した図である。ＰＶ４４０をマウントするＰｏｄ５１０が削除（１．ｄｅｌｅｔｅ Ｐｏｄ）されれば、ノードプラグイン５２１は、当該ＰＶ４４０にマウントされているターゲット５３０のバックエンドストレージサーバ（ボリュームノード１（４３０））にＮＶＭｅ連結解除命令（２．Ｎｖｍｅ ｄｉｓｃｏｎｎｅｃｔ）をしてよい。ターゲット５３０のサーバ情報であるホストＩＰ、ポート、およびターゲット５３０の識別子は、ｃｉｎｄｅｒ－ａｐｉ４２１への要求として受け取ってよい。この場合にも、Ｐｏｄ５１０の削除を確認する主体は、ｋｕｂｅｌｅｔのＫ８ｓで使用するワーカーノードのエージェントｄｅｍｏｎであってよい。言い換えれば、ｋｕｂｅｌｅｔ４８０がＰｏｄ５１０の削除をモニタリングしてノードプラグイン５２１にボリュームデタッチメントを要求することにより、ノードプラグイン５２１がこのようなＰｏｄ５１０の削除に関する情報の伝送を受け取るようにしてよい。

【0053】

ＮＶＭｅ連結の解除が完了した後、ノードプラグイン５２１は、ｃｉｎｄｅｒ－ａｐｉ４２１に当該エクスポートを削除することを要求（３．ｃｉｎｄｅｒ ＡＰＩ：ｒｅｍｏｖｅ ｅｘｐｏｒｔ）してよい。この場合、ｃｉｎｄｅｒ－ａｐｉ４２１は、当該ホスト（ボリュームノード１（４３０））のｃｉｎｄｅｒ－ｖｏｌｕｍｅ４３１にエクスポートを除去せよというメッセージを伝送（４．ｒｅｍｏｖｅ ｅｘｐｏｒｔ）してよい。ｃｉｎｄｅｒ－ｖｏｌｕｍｅ４３１は、伝送されたメッセージにしたがってターゲット５３０に対するエクスポートを削除してよい。

【0054】

この後、ノードプラグイン５２１は、ボリューム４６０を使用可能にしてほしいという要求（６．ｃｉｎｄｅｒ ＡＰＩ：ｅｎａｂｌｅ ｖｏｌｕｍｅ）をｃｉｎｄｅｒ－ａｐｉ４２１に伝送してよく、ｃｉｎｄｅｒ－ａｐｉ４２１は、要求にしたがって、当該ボリューム４６０の状態を使用可能な状態（ａｖａｉｌａｂｌｅ）に変更（７．ｍａｋｅ ｖｏｌｕｍｅ ｓｔａｔｕｓ ａｖａｉｌａｂｌｅ）してよい。

【0055】

図７は、本発明の一実施形態における、ボリューム削除の過程の例を示した図である。ＮＶＭｅ ｏＦのＰＶＣ４５０が削除（１．ｄｅｌｅｔｅ ＰＶＣ）されれば、コントローラプラグイン４１１は、ｃｉｎｄｅｒ－ａｐｉ４２１にボリューム削除を要求（２．ｃｉｎｄｅｒ ＡＰＩ：ｄｅｌｅｔｅ ｖｏｌｕｍｅ）してよい。この場合、ｃｉｎｄｅｒ－ａｐｉ４２１は、データベースからボリューム４６０の情報を削除（３．Ｄｅｌｅｔｅ ｖｏｌｕｍｅ）してよい。この後、ｃｉｎｄｅｒ－ａｐｉ４２１は、当該ボリュームを管理するｃｉｎｄｅｒ－ボリューム４３１に実際にＬＶ４７０を除去せよというメッセージを送信（４．ｒｅｍｏｖｅ ｖｏｌｕｍｅ）してよい。ｃｉｎｄｅｒ－ボリューム４３１は、受信したメッセージにしたがってＬＶ４７０を削除（５．ｄｅｌｅｔｅ ＬＶ）してよい。

【0056】

一方、コントローラプラグイン４１１は、ｃｉｎｄｅｒ－ａｐｉ４２１にボリューム削除を要求した後、ＰＶ４４０を削除（６．ｄｅｌｅｔｅ ＰＶ）してよい。

【0057】

図８は、本発明の一実施形態における、バックエンドストレージ観点でのボリューム生成の過程の例を示した図である。図８は、ストレージサーバ端３２０に対応するバックエンドストレージの例であって、ｃｉｎｄｅｒ－ａｐｉ８１０、Ａｕｔｈ ｍａｎａｇｅｒ８２０、ｃｉｎｄｅｒ－ｓｃｈｅｄｕｌｅｒ８３０、Ｃｉｎｄｅｒ ＤＢ８４０、メッセージキュー（Ｍｅｓｓａｇｅ Ｑｕｅｕｅ８５０、ｃｉｎｄｅｒ－ｖｏｌｕｍｅ１（８６０）、およびｃｉｎｄｅｒ－ｖｏｌｕｍｅ２（８７０）を示している。ここで、ｃｉｎｄｅｒ－ａｐｉ８１０、ｃｉｎｄｅｒ－ｓｃｈｅｄｕｌｅｒ８３０、およびｃｉｎｄｅｒ－ｖｏｌｕｍｅ８６０、８７０は、上述したｃｉｎｄｅｒ－ａｐｉ４２１、ｃｉｎｄｅｒ－ｓｃｈｅｄｕｌｅｒ４２２、およびｃｉｎｄｅｒ－ｖｏｌｕｍｅ４３１にそれぞれ対応してよい。一方、Ａｕｔｈ ｍａｎａｇｅｒ８２０、Ｃｉｎｄｅｒ ＤＢ８４０、およびメッセージキュー８５０は、マイクロサービスアキテクチャにしたがってＯｐｅｎＳｔａｃｋ－Ｃｉｎｄｅｒとは別に管理されるコンポーネントであってよい。

【0058】

クライアントからボリューム生成要求が伝送されれば、ｃｉｎｄｅｒ－ａｐｉ８１０は、Ａｕｔｈ ｍａｎａｇｅｒ８２０にユーザ要求の認証／認可を確認（１．Ａｕｔｈ ｕｓｅｒ、ｐｒｏｊｅｃｔ ａｎｄ ｒｏｌｅ）してよい。例えば、ｃｉｎｄｅｒ－ａｐｉ８１０は、ＡＰＩを呼び出したユーザの情報、ユーザが属するプロジェクト（ｐｒｏｊｅｃｔ）の情報、ユーザがボリュームを生成できるかどうかに対するロール（ｒｏｌｅ）情報を確認してよい。

【0059】

認証が完了した後、ｃｉｎｄｅｒ－ａｐｉ８１０は、Ｃｉｎｄｅｒ ＤＢ８４０に、ボリュームのメタデータとしてボリューム名、サイズ、生成タイプなどを格納（２．Ｃｒｅａｔｅ ｖｏｌｕｍｅ ｍｅｔａｄａｔａ）してよい。Ｃｉｎｄｅｒ ＤＢ８４０のアップデートは、一例として、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）が利用されてよい。

【0060】

また、ｃｉｎｄｅｒ－ａｐｉ８１０は、メッセージキュー８５０を利用して、ｃｉｎｄｅｒ－ｓｃｈｅｄｕｌｅｒ８３０にボリューム生成のためのスケジューリングを要求してよい。このとき、ｃｉｎｄｅｒ－ａｐｉ８１０は、ボリュームスケジューリングを要求するためのメッセージをメッセージキュー８５０で伝送（３．Ｒｅｑｕｅｓｔ ｖｏｌｕｍｅ ｓｃｈｅｄｕｌｉｎｇ）してよい。この後、ｃｉｎｄｅｒ－ｓｃｈｅｄｕｌｅｒ８３０は、メッセージキュー８５０によってメッセージの伝送を非同期方式で受け取ってよい。

【0061】

ｃｉｎｄｅｒ－ｓｃｈｅｄｕｌｅｒ８３０は、伝送されたメッセージに基づいて、ボリュームを生成するｃｉｎｄｅｒ－ｖｏｌｕｍｅ（本実施形態ではｃｉｎｄｅｒ－ｖｏｌｕｍｅ２（８７０））を決定してよく、ＮＶＭｅボリュームを生成せよという命令（４．Ｓｃｈｅｄｕｌｅ ｎｖｍｅ ｖｏｌｕｍｅ）をメッセージキュー８５０に入力してよい。このとき、スケジューリングの基準は、ｃｉｎｄｅｒ－ｖｏｌｕｍｅが担当するディスクの残余容量などが考慮されてよい。

【0062】

一方、ｃｉｎｄｅｒ－ｓｃｈｅｄｕｌｅｒ８３０は、ｃｉｎｄｅｒ－ｖｏｌｕｍｅをスケジューリングした後、ボリュームの識別子とｃｉｎｄｅｒ－ｖｏｌｕｍｅのホスト情報などをＣｉｎｄｅｒ ＤＢ８４０にアップデートしてよい。

【0063】

ｃｉｎｄｅｒ－ｖｏｌｕｍｅ２（８７０）は、メッセージキュー８５０で命令の伝送を受け取ってよく、伝送された命令にしたがって、ＬＶとしてＮＶＭｅボリュームを生成（５．Ｃｒｅａｔｅ ｎｖｍｅ ｖｏｌｕｍｅ）してよい。

【0064】

図９は、本発明の一実施形態における、バックエンドストレージ観点でのボリュームアタッチメントの過程の例を示した図である。

【0065】

ボリュームアタッチメント時にクライアントからボリュームエクスポート（ターゲットエクスポート）要求がｃｉｎｄｅｒ－ａｐｉ８１０に到着すれば、ｃｉｎｄｅｒ－ａｐｉ８１０は、Ａｕｔｈ ｍａｎａｇｅｒ８２０にユーザ要求の認証／認可を確認（１．Ａｕｔｈｕｓｅｒ、ｐｒｏｊｅｃｔ ａｎｄ ｒｏｌｅ）してよい。この後、ｃｉｎｄｅｒ－ａｐｉ８１０は、当該ボリュームを担当するｃｉｎｄｅｒ－ｖｏｌｕｍｅ（本実施形態ではｃｉｎｄｅｒ－ｖｏｌｕｍｅ２（８７０））にＮＶＭｅターゲットをエクスポートするように要求（２．Ｒｅｑｕｅｓｔ ｎｖｍｅ ｔａｒｇｅｔ ｅｘｐｏｒｔ ａｎｄ ｗａｉｔ ｒｅｓｐｏｎｓｅ）を伝送してよい。上述したように、当該要求は、メッセージキュー８５０を利用した非同期方式で伝送されるが、ｃｉｎｄｅｒ－ａｐｉ８１０は、ｃｉｎｄｅｒ－ｖｏｌｕｍｅ２（８７０）からの応答を待たなければならないため、ｃｉｎｄｅｒ－ａｐｉ８１０にはｃｉｎｄｅｒ－ｖｏｌｕｍｅ２（８７０）からの応答を待つためのロジックが含まれてよい。

【0066】

ｃｉｎｄｅｒ－ｖｏｌｕｍｅ２（８７０）は、メッセージキュー８５０で伝送された要求にしたがって、ＮＶＭｅターゲットエクスポートの作業を実行（３．Ｅｘｐｏｒｔ ｎｖｍｅ ｖｏｌｕｍｅ ｔａｒｇｅｔ）してよい。一例として、ｃｉｎｄｅｒ－ｖｏｌｕｍｅ２（８７０）は、カーネルモジュールである「ｎｖｍｅｔ－ｔｃｐ」を利用してターゲットエクスポートを処理してよい。また、ｃｉｎｄｅｒ－ｖｏｌｕｍｅ２（８７０）は、エクスポートしたターゲットの情報（ｉｐ、ポート、ホストｎｑｎ）をメッセージキュー８５０でｃｉｎｄｅｒ－ａｐｉ８１０に伝送してよい。ここで、ｉｐは、上述したホストＩＰに対応してよく、ホストｎｑｎは、ターゲットの識別子として説明したサブシステムＮＱＮに対応してよい。

【0067】

ｃｉｎｄｅｒ－ａｐｉ８１０は、ｃｉｎｄｅｒ－ｖｏｌｕｍｅ２（８７０）の応答を待ち、エクスポートが完了した後、メッセージキュー８５０でｃｉｎｄｅｒ－ｖｏｌｕｍｅ２（８７０）の応答の伝送を受け取るようになれば、クライアントに当該情報を返信（４．Ｒｅｔｕｒｎ ｎｖｍｅ ｖｏｌｕｍｅ ｔａｒｇｅｔ ｉｎｆｏ（ｉｐ、ｐｏｒｔ、ｈｏｓｔ ｎｑｎ））してよい。

【0068】

図１０は、本発明の一実施形態における、バックエンドストレージ観点でのボリュームデタッチメントの過程の例を示した図である。

【0069】

ボリュームデタッチメント時にクライアントからエクスポート削除（Ｒｅｍｏｖｅ ｅｘｐｏｒｔ）要求が入れば、ｃｉｎｄｅｒ－ａｐｉ８１０は、Ａｕｔｈ ｍａｎａｇｅｒ８２０にユーザ要求の認証／認可を確認（１．Ａｕｔｈｕｓｅｒ、ｐｒｏｊｅｃｔ ａｎｄ ｒｏｌｅ）してよい。この後、ｃｉｎｄｅｒ－ａｐｉ８１０は、メッセージキュー８５０を利用して、当該ボリュームを担当するｃｉｎｄｅｒ－ｖｏｌｕｍｅ２（８７０）にＮＶＭｅターゲットを削除するように要求（２．Ｒｅｑｕｅｓｔ ｒｅｍｏｖｅ ｎｖｍｅ ｔａｒｇｅｔ）を送信してよい。このとき、ｃｉｎｄｅｒ－ｖｏｌｕｍｅ２（８７０）は、メッセージキュー８５０で伝送された要求にしたがって、ＮＶＭｅターゲットを削除する作業を実行（３．Ｒｅｍｏｖｅ ｎｖｍｅ ｔａｒｇｅｔ）してよい。

【0070】

図１１は、本発明の一実施形態における、バックエンドストレージ観点でのボリューム削除の過程の例を示した図である。

【0071】

ボリューム削除時にクライアントからボリューム削除要求（Ｖｏｌｕｍｅｄｅｌｅｔｅ）が入力されれば、ｃｉｎｄｅｒ－ａｐｉ８１０は、Ａｕｔｈ ｍａｎａｇｅｒ８２０にユーザ要求の認証／認可を確認（１．Ａｕｔｈ ｕｓｅｒ、ｐｒｏｊｅｃｔ ａｎｄ ｒｏｌｅ）してよい。この後、ｃｉｎｄｅｒ－ａｐｉ８１０は、削除要求が入力されたボリュームに関する情報をＣｉｎｄｅｒ ＤＢ８４０から削除（２．Ｄｅｌｅｔｅ ｖｏｌｕｍｅ ｍｅｔａｄａｔａ）してよい。

【0072】

また、ｃｉｎｄｅｒ－ａｐｉ８１０は、メッセージキュー８５０を利用して、当該ボリュームを担当するｃｉｎｄｅｒ－ｖｏｌｕｍｅ２（８７０）にＬＶを削除するように要求（３．Ｒｅｑｕｅｓｔ ｖｏｌｕｍｅ ｄｅｌｅｔｅ）を送信してよい。このとき、ｃｉｎｄｅｒ－ｖｏｌｕｍｅ２（８７０）は、メッセージキュー８５０で伝達された要求にしたがって、ＬＶを除去する作業を実行（４．Ｄｅｌｅｔｅ ＬＶ）してよい。

【0073】

上述した実施形態で説明したコンポーネントは、ソフトウェアモジュールの形態で実現されてよく、少なくとも１つのプロセッサ（一例として、プロセッサ２２０）が実行する動作の機能的表現（ｆｕｎｃｔｉｏｎａｌ ｅｘｐｒｅｓｓｉｏｎｓ）であってよい。例えば、クライアントやバックエンドストレージを実現するコンピュータ装置２００のプロセッサ２２０は、メモリ２１０が含むオペレーティングシステムのコードと、少なくとも１つのコンピュータプログラムのコードとによる制御命令（ｉｎｓｔｒｕｃｔｉｏｎ）を実行するように実現されてよい。ここで、プロセッサ２２０は、コンピュータ装置２００に記録されたコードが提供する制御命令にしたがってコンピュータ装置２００が上述した実施形態に係る過程の動作を実行するようにコンピュータ装置２００を制御してよい。

【0074】

このように、本発明の実施形態によると、クライアント－サーバ環境において、クライアントがサーバのストレージを使用できるようにサーバからクライアントにボリュームを提供することができる。

【0075】

上述した装置は、ハードウェア構成要素、またはハードウェア構成要素とソフトウェア構成要素との組み合わせによって実現されてよい。例えば、実施形態で説明された装置および構成要素は、例えば、プロセッサ、コントローラ、ＡＬＵ（ａｒｉｔｈｍｅｔｉｃ ｌｏｇｉｃ ｕｎｉｔ）、デジタル信号プロセッサ、マイクロコンピュータ、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、ＰＬＵ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｕｎｉｔ）、マイクロプロセッサ、または命令を実行して応答することができる様々な装置のように、１つ以上の汎用コンピュータまたは特定目的コンピュータを利用して実現されてよい。処理装置は、オペレーティングシステム（ＯＳ）およびＯＳ上で実行される１つ以上のソフトウェアアプリケーションを実行してよい。また、処理装置は、ソフトウェアの実行に応答し、データにアクセスし、データを記録、操作、処理、および生成してもよい。理解の便宜のために、１つの処理装置が使用されるとして説明される場合もあるが、当業者であれば、処理装置が複数個の処理要素および／または複数種類の処理要素を含んでもよいことが理解できるであろう。例えば、処理装置は、複数個のプロセッサまたは１つのプロセッサおよび１つのコントローラを含んでよい。また、並列プロセッサのような、他の処理構成も可能である。

【0076】

ソフトウェアは、コンピュータプログラム、コード、命令、またはこれらのうちの１つ以上の組み合わせを含んでもよく、思うままに動作するように処理装置を構成したり、個別にまたはまとめて処理装置に命令したりしてよい。ソフトウェアおよび／またはデータは、処理装置に基づいて解釈されたり、処理装置に命令またはデータを提供したりするために、いかなる種類の機械、コンポーネント、物理装置、仮想装置（ｖｉｒｔｕａｌ ｅｑｕｉｐｍｅｔ）、コンピュータ記録媒体または装置に具現化されてよい。ソフトウェアは、ネットワークによって接続されたコンピュータシステム上に分散され、分散された状態で記録されても実行されてもよい。ソフトウェアおよびデータは、１つ以上のコンピュータ読み取り可能な記録媒体に記録されてよい。

【0077】

実施形態に係る方法は、多様なコンピュータ手段によって実行可能なプログラム命令の形態で実現されてコンピュータ読み取り可能な媒体に記録されてよい。前記コンピュータで読み取り可能な媒体は、プログラム命令、データファイル、データ構造などを単独でまたは組み合わせて含んでよい。媒体は、コンピュータ実行可能なプログラムを継続して記録するものであっても、実行またはダウンロードのために一時記録するものであってもよい。また、媒体は、単一または複数のハードウェアが結合した形態の多様な記録手段または格納手段であってよく、あるコンピュータシステムに直接接続する媒体に限定されることはなく、ネットワーク上に分散して存在するものであってもよい。媒体の例としては、ハードディスク、フロッピー（登録商標）ディスク、および磁気テープのような磁気媒体、ＣＤ－ＲＯＭおよびＤＶＤのような光媒体、フロプティカルディスク（ｆｌｏｐｔｉｃａｌ ｄｉｓｋ）のような光磁気媒体、およびＲＯＭ、ＲＡＭ、フラッシュメモリなどのような、プログラム命令語が格納されるように構成されたものであってよい。また、媒体の他の例として、アプリケーションを配布するアプリケーションストアやその他の多様なソフトウェアを供給または配布するサイト、サーバなどで管理する記録媒体または格納媒体が挙げられる。プログラム命令の例は、コンパイラによって生成されるもののような機械語コードだけではなく、インタプリタなどを使用してコンピュータによって実行される高級言語コードを含む。

【0078】

以上のように、実施形態を、限定された実施形態および図面に基づいて説明したが、当業者であれば、上述した記載から多様な修正および変形が可能であろう。例えば、説明された技術が、説明された方法とは異なる順序で実行されたり、かつ／あるいは、説明されたシステム、構造、装置、回路などの構成要素が、説明された方法とは異なる形態で結合されたりまたは組み合わされたり、他の構成要素または均等物によって対置されたり置換されたとしても、適切な結果を達成することができる。

【0079】

したがって、異なる実施形態であっても、特許請求の範囲と均等なものであれば、添付の特許請求の範囲に属する。

【符号の説明】

【0080】

３１０：クライアントサイド
３２０：ストレージサーバサイド

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【外国語明細書】