Shoeisha Technology Media

CodeZine(コードジン)

記事種別から探す

Glanceの動作と仕組み~Novaのインスタンスイメージを柔軟に管理

マイクロサービスアーキテクチャが支えるOpenStackの動作と仕組み 第3回

  • LINEで送る
  • このエントリーをはてなブックマークに追加

 前回は、仮想サーバーの作成・管理を司るコアサービス「Nova」を紹介しました。Novaはその柔軟さによってクラウドコンピューティングサービスの規模拡大や障害への対応を容易としています。今回は、3つ目のOpenStackのコアサービスとして「Glance」を取り上げます。Glanceは、Novaが仮想サーバーを作成する際にベースとなる「イメージ」を管理するコアサービスです。そのため、Novaを使う場合にはGlanceも必ず使います。

目次

Novaはインスタンスを作成する際にイメージを使う

前回解説したNovaは、OpenStackのコンピュートノードに仮想サーバーを作成し、管理するコアサービスでした。Novaが作成した仮想サーバーは「インスタンス」といいます。

作成したインスタンスには、OSや各種ミドルウェアをインストールすることになります。また、同じ構成で複数のインスタンスを作成することもあります。これを毎回ゼロから実行していては、時間がかかる上、途中でオペレーションミスが発生する恐れがあります。

そこで、OpenStackには、インスタンスに利用するOSやミドルウェアまでインストールしたイメージを事前に作成し、インストール作成時にそれを利用する仕組みが実装されています。イメージを利用してインスタンスを作成すれば、必要なOSやミドルウェアがインストールされたサーバーを、ミスなく短時間で立ち上げられます。

ただし、イメージを管理するのはNovaの役目ではありません。Novaはインスタンスの作成・管理を行う機能に特化しています。代わりにイメージを管理するコアサービスが、今回解説するGlanceです[1]

Glanceが管理するのはイメージに関する情報だけ

Glanceの特徴は、イメージの実体とイメージに関する情報(メタ情報)とを別途に保管するところです。メタ情報は、Glance内部のデータベースで保管します。一方、イメージの実体はGlance内部ではなく、ファイルシステムや、OpenStackのオブジェクトストレージサービス(Swift)あるいはブロックストレージサービス(Cinder)など、外部のシステムに預けます。Amazon S3などのクラウドサービスに預けることも可能です。

イメージの実体を外部で保管するのは、そのファイルサイズが大きいためです。大きなファイルを安全・確実に保管するには、そのための機能が必要です。しかし、ファイルの保管は、Glanceが本質的に提供すべき機能ではありません。そのため、外部に預けるようになっています。これも、OpenStackがマイクロサービスアーキテクチャで設計されている例の1つでしょう。

Glance内部に保管するメタ情報には、イメージの実体がどのような形で、どこに置かれているかといった情報が書き込まれています。イメージの実体を取り出すときには、メタ情報を参照して置かれている場所などを調べることになります。イメージに関するその他の情報やイメージ一覧が欲しい場合にも、メタ情報を調べるだけで済みます。

Glanceは2つのコンポーネントで動作する

Glanceは次表に示すように、glance-apiglance-registryという2つのコンポーネントで構成されています。

コンポーネント 機能
glance-api ユーザーからのリクエストを受け付けるコンポーネント。ここがエンドポイントとなるほか、認可もここで実施する
glance-registry 各イメージのメタ情報を管理するコンポーネント。ただし、イメージそのものの管理は行わない

これらのコンポーネントは次図のように配置されます。

Glanceの構造と関連するサービスやストレージ
Glanceの構造と関連するサービスやストレージ

そして、Glanceは次のように動作します。実行はglance-apiが担当します。

  1. イメージのリクエストを受け付ける
  2. リクエストの認可のためにKeystoneにアクセスする
  3. glance-registryにメタ情報を問い合わせてイメージの実体の位置を取得する
  4. 取得した位置にあるイメージの実体をリクエスト元に送信する

抽象化されたリクエストを受け付けるglance-api

ユーザーはglance-apiへリクエストを送信することで、Glanceの構造を意識することなくGlanceの機能を利用できます。

例えば、ユーザーがイメージの実体をリクエストするときのことを考えてみましょう。Glanceは異なる種類のストレージを同時に使用できます(後述)。けれども、ユーザーが、どのタイプのどのストレージにイメージの実体が保管されているのかを、具体的に指定する必要はありません。イメージに付与されたIDを指定して、glance-apiにリクエストを送信するだけです。リクエストは抽象化されています。

リクエストを受け取ったglance-apiは最初に、イメージのリクエストを認可するか否かを判断します。そのために、Keystoneにリクエスト元のユーザー情報を問い合わせて、Glanceが持つ認可情報と照らし合わせます。照らし合わせた結果、認可されれば、glance-apiが指定されたイメージの位置などをメタ情報で確認し、判明した場所からイメージの実体を送信してくれます。

このように、どこにあるか分からないイメージの実体を取得するのに、ユーザーはIDを指定するだけ済むのは、イメージのメタ情報を別途管理するGlanceの設計の優秀さを示しています。

[1]: 逆に、Glanceはイメージの管理に特化しています。これはマイクロサービスアーキテクチャで設計されているOpenStackの特徴です。詳しくは本連載第1回をご覧ください。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

バックナンバー

連載:マイクロサービスアーキテクチャが支えるOpenStackの動作と仕組み
All contents copyright © 2005-2017 Shoeisha Co., Ltd. All rights reserved. ver.1.5