異なるタイプのストレージサービスを選択・併用できる
Glanceでは、イメージの保管先に様々なストレージサービスを選べます（利用可能なストレージサービスについては後述）。様々なストレージサービスが使えることで、どのような利点が生まれるのでしょうか。
例えば、運用中のストレージをそのまま使うことができます。イメージの量が限られていることが明白なら、ファイルシステムに保存するという手段も採用できます。この場合、イメージを保管するためのストレージを増やす必要がなく、管理するサーバーが減ります。また、イメージの喪失が運用上きわめて大きなリスクとなる場合、Amazon S3の利用も選択できます。
また、Glanceは異なるタイプのストレージサービスを併用することも可能です。例えば、失ったときの被害が甚大なイメージはAmazon S3に保存するけれども、そうでもないイメージはファイルシステムに保存する、といった使い分けができます。
Amazon S3は極めて高い耐久性を備えていますが、利用にはお金がかかりますし、組織によっては利用申請といった準備が大変かもしれません。そのため、全てのイメージをAmazon S3に保管するという選択は避けたいところです。Glanceなら、目的に応じて最適なイメージを選べます。
このように、利用目的や状況によって保管先のストレージサービスを切り替えられるのは、イメージの実体とメタ情報の管理が切り離されているGlanceだから実現可能な強みです。この強みは、用途別にサービスが切り離されているマイクロサービスアーキテクチャの特徴によって実現されています。
Glanceで使用可能なストレージサービスには次表のものがあります。どれを使用するかは、glance-apiの設定ファイル（glance-api.conf）の中で指定します。
| ファイルシステム | Glanceがインストールされているサーバのファイルシステムにイメージを保管する |
|---|---|
| HTTP | ウェブ上に配置されたイメージを直接参照する |
| Amazon S3 | Amazon Web ServiceのAmazon Simple Storage Serviceに配置されたイメージを直接参照する |
| RBD | Rados Block Deviceによって作成されたストレージにイメージを保管する |
| Sheepdog | Sheepdog によって作成されたストレージにイメージを保管する |
| VMWARE | VMWARE の持つストレージにイメージを保管する |
| SWIFT | OpenStackのコアサービスSWIFTによって作成されたオブジェクトストレージにイメージを保管する |
| CINDER | OpenStackのコアサービスCINDERによって作成されたブロックストレージにイメージを保管する |
おわりに
Glanceは、Novaがインスタンスを作成するときに使用するイメージを、メタ情報とイメージの実体に分けて管理します。
ユーザーはglance-apiにイメージに付与されたIDを渡すことで、イメージのメタ情報や実体を利用できます。
イメージのメタ情報は、あらゆるサービスやユーザーから頻繁に使われます。これはglance-registryによって管理されており、高速で参照できます。
イメージの実体は様々なタイプのストレージに保管可能です。そのため、構築する際の状況や目的に応じて、最も使いやすいストレージを選択できます。異なるタイプのストレージを併用し、使い分けることも可能です。
これらの利点は、Glanceそのものがマイクロサービスの集合体として作られていることで実現されています。
