2.3 KiB
Glance Architecture
Glance is designed to be as adaptable as possible for various
back-end storage and registry database solutions. There is a main Glance
API server (the glance-api program) that serves as the
communications hub between various client programs, the registry of
image metadata, and the storage systems that actually contain the
virtual machine image data.
From a birdseye perspective, one can visualize the Glance architectural model like so:
- digraph birdseye {
-
node [fontsize=10 fontname="Monospace"] a [label="Client A"] b [label="Client B"] c [label="Client C"] d [label="Glance API Server"] e [label="Registry Server"] f [label="Store Adapter"] g [label="S3 Store"] h [label="Swift Store"] i [label="Filesystem Store"] j [label="HTTP Store"] a -> d [dir=both] b -> d [dir=both] c -> d [dir=both] d -> e [dir=both] d -> f [dir=both] f -> g [dir=both] f -> h [dir=both] f -> i [dir=both] f -> j [dir=both]
}
What is a Registry Server?
A registry server is a service that publishes image metadata for internal consumption by the Glance API server. The Glance registry server uses a SQL database for its metadata storage.
What is a Store?
A store is a Python class that inherits from
glance.store.Backend and conforms to that class' API for
reading, writing, and deleting virtual machine image data.
Glance currently ships with stores for S3, Swift, RBD, a simple filesystem store, and a read-only HTTP(S) store.
Implementors are encouraged to create stores for other backends, including other distributed storage systems like Sheepdog.