openstack/blazar
Code Issues Proposed changes

Merge "[docs] Rewrite the architecture description"

Browse Source
This commit is contained in:
Zuul 2022-10-06 15:30:29 +00:00 committed by Gerrit Code Review
commit 68c6487465
3 changed files with 135 additions and 136 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
doc/source/index.rst
View File

@ -1,9 +1,9 @@
Blazar, the OpenStack Reservation Service
=========================================
Blazar is an OpenStack service to provide resource reservations in the
OpenStack cloud for different resource types - both virtual (instances,
volumes, stacks) and physical (hosts).
Blazar is the *Resource Reservation Service* for OpenStack.
If you are new to Blazar, please start with the :ref:`Introduction`.
Installation Guide
------------------

147
doc/source/user/architecture.rst
View File

@ -2,74 +2,125 @@
Blazar architecture
====================
Blazar design can be described by following diagram:
Blazar's architecture is described by the following diagram:
.. image:: ../images/blazar-architecture.png
:width: 700 px
:scale: 99 %
:align: left
**blazar-client** - provides the opportunity to communicate with Blazar via
*REST API* (blazar-api service).
**blazar-client** - provides a Python implementation of communication with
Blazar API (``blazar-api`` service). It works as a library, a standalone
``blazar`` CLI client, as well as a plugin of the ``openstack`` client.
**blazar-api** - waits for the REST calls from the outside world to redirect
them to the manager. blazar-api communicates with blazar-manager via RPC.
Runs as a separated process.
**blazar-api** - waits for REST API calls from the outside world to redirect
them to the manager. ``blazar-api`` communicates with ``blazar-manager``
via RPC.
**blazar-manager** - implements all logic and operations with leases,
reservations and events. Communicates with Blazar DB and stores there data
structure of connected leases, reservations (both physical and virtual) and
events. blazar-manager service is responsible for running events created for
lease and process all actions that should be done this moment. Manager uses
resource-plugins to work with concrete resources (instances, volumes, compute
hosts).
on leases, reservations and events.
``blazar-manager`` service is responsible for handling events created for
leases and running all relevant actions. ``blazar-manager`` uses
resource-plugins to work with other services' resources.
**resource-plugin** - responsible for exact actions to do with reserved
resources (VMs, volumes, etc.) When working knows only about resource ID and
token to use. All resource plugins work in the same process as blazar-manager.
**resource-plugin** - responsible for exact actions to apply to other services'
resources. All resource plugins reside in the same process as
``blazar-manager``.
Virtual instance reservation
----------------------------
Nova resource reservation
+++++++++++++++++++++++++
**Note** virtual instance reservation feature is not available in current
release. Expected to be available in the future (`bug tracker`_).
Blazar's integration with Nova is based on the following components working
in tandem:
.. _bug tracker: https://blueprints.launchpad.net/blazar/+spec/new-instance-reservation
* Nova
Virtual instance reservation mostly looks like usual instance booting for user
- he/she only passes special hints to Nova containing information about future
lease - lease start and end dates, its name, etc. Special Nova API extensions
parse these parameter and use them to call Blazar, passing to it ID of just
created instance. If there is a need to reserve all instances in cloud (like in
developer labs to automate process of resource reclaiming), default reservation
extension might be used. By default it starts lease at the moment of request
and gives it one month of lifetime.
* Nova host aggregates are used to control which hosts have their access
managed by Blazar.
The canonical name for the Blazar-owned host aggregate is ``freepool``.
During the time lease has not started yet, instance will be shelved.
* Nova flavors are used for instance reservations.
* Blazar-Nova
* The ``blazar-nova`` package offers the ``BlazarFilter`` filter for
nova-scheduler. ``BlazarFilter`` ensures that Nova does not schedule
regular (non-reservation-belonging) instances on Blazar-owned hosts
(unless preemption is enabled) and that host lease boundaries are respected.
* Placement
* Nested resource providers are used to control which hosts are managed by
Blazar.
* Reservation classes are created and nested resource providers' inventories
are updated for instance reservations.
It is worth noting that Blazar integrations are one-way, i.e. the other services
never call Blazar. Even the ``BlazarFilter`` operates in such a way that all
required data is present in Nova and Placement.
.. note::
Only the compute host reservation is compatible with preemptible instances
at the moment.
Compute host reservation
------------------------
Now process of compute hosts reserving contains two steps:
Compute host reservation is analogous to a dedicated virtualisation host
offering. The user asks for a certain number of hosts with specified
characteristics, such as:
* admin marks hosts from common pool as possible to be reserved. That is
implemented by moving these hosts to special aggregate;
* user asks for reserving of host with specified characteristics like:
* the region,
* the availability zone,
* the host capabilities extra specs,
* the number of CPU cores,
* the amount of available RAM,
* the amount of available disk space.
* the region
* the availability zone
* the host capabilities extra specs (scoped and non-scoped format is
accepted)
* the number of CPU cores
* the amount of free RAM
* the amount of free disk space
* the number of hosts
Matching hosts are reserved for the sole use in the user's project.
Other projects will not share the same hosts during the lease period.
Technically speaking, resource ID here will be not host ID, because there might
be many of them wanted. Resource here will be new aggregate containing reserved
hosts. The time lease starts, user may use reserved compute capacity to run
his/her instances on it passing special scheduler hint to Nova. When host is
reserved, it's not used for usual instance running, it might be used only when
lease starts and only by passing reservation ID to Nova. That is implemented
using special Nova Scheduler filter, that passes reservation ID to Blazar and
checks if user really can use reserved compute capacity.
Virtual instance reservation
----------------------------
Virtual instance reservation offers a more granular compute resource reservation
that does not book entire hypervisors but instead allows using Blazar-owned
hosts via special time-limited flavors set up by Blazar. The user asks for
a certain number of instances with specific flavor characteristics,
such as:
* the number of provided CPU cores,
* the amount of provided RAM,
* the amount of provided disk space,
* affinity rule.
When the lease is active, a dedicated flavor is presented to the leasee.
No other project may use this flavor. Blazar ensures, albeit in a best-effort
manner, that supporting compute resources are reserved, e.g., it will not allow
for oversubscribing with multiple reservation types (hosts supporting the
virtual instance reservation cannot also be targeted for compute host
reservation at the same time).
Neutron resource reservation
++++++++++++++++++++++++++++
Apart from compute resources of Nova, Blazar allows to reserve certain Neutron
resources. At the moment, these are only floating IPs.
The Neutron integration thus far does not require changes to the Neutron
environment. The Blazar interaction looks to Neutron like any other service
client interaction.
Floating IPs reservation
------------------------
Blazar admin may register floating IPs with Blazar which can then later be
leased to end users. End users request floating IPs from a chosen network
and they will be created in user's project once the lease starts.
The allowed floating IPs *must not* exist in subnet's allocation pools.
Blazar will validate this *only once* when admin registers the floating IP
with Blazar. The integration *will break* if admin then adds the same floating
IP to the allocation pool as Blazar will try to own it and fail.

118
doc/source/user/introduction.rst
View File

@ -1,107 +1,55 @@
.. _Introduction:
============
Introduction
============
Blazar is a resource reservation service for OpenStack.
Idea of creating Blazar originated with two different use cases:
Blazar is the *Resource Reservation Service* for OpenStack.
The idea of creating Blazar originated with two different use cases:
* Compute host reservation (when user with admin privileges can reserve
hardware resources that are dedicated to the sole use of a project)
* Virtual machine (instance) reservation (when user may ask reservation service
to provide him working VM not necessarily now, but also in the future)
* Virtual machine (instance) reservation (when user may ask Blazar
to provide them working VM not necessarily now, but also in the future)
Now these ideas have been transformed to more general view: with Blazar, user
can request the resources of cloud environment to be provided ("leased") to his
These ideas have been transformed to a more general view: with Blazar, user
can request the resources of cloud environment to be provided ("leased") to their
project for specific amount of time, immediately or in the future.
Both virtual (Instances, Volumes, Networks) and hardware (full hosts with
specific characteristics of RAM, CPU, etc) resources can be allocated via
"lease".
Currently, Blazar supports reservations of:
In terms of benefits added, Resource Reservation Service will:
* Nova resources:
* improve visibility of cloud resources consumption (current and planned for
* Compute hosts / hypervisors
* Instances / servers
* Neutron resources:
* Floating IPs
In terms of benefits added, Blazar:
* improves visibility of cloud resources consumption (current and planned for
future);
* enable cloud resource planning based on current and future demand from end
* enables cloud resource planning based on current and future demand from end
users;
* automate the processes of resource allocation and reclaiming;
* provide energy efficiency for physical hosts (both compute and storage ones);
* potentially provide leases as billable items for which customers can be
charged a flat fee or a premium price depending on the amount of reserved cloud
resources and their usage.
* automates the processes of resource allocation and reclaiming.
Glossary of terms
-----------------
**Reservation** is an allocation of certain cloud resource (Nova instance, Cinder
volume, compute host, etc.) to a particular project. Speaking about virtual
reservations, we may have not only simple, solid ones (like already mentioned
instances and volumes), but also complex ones - like Heat stacks and Savanna
clusters. Reservation is characterized by status, resource type, identifier
and lease it belongs to.
**Reservation** is an allocation of cloud resources to a particular project.
Main properties of a reservation are its status, resource type, identifier and
the lease it belongs to.
**Lease** is a negotiation agreement between the provider (Blazar, using OpenStack
resources) and the consumer (user) where the former agrees to make some kind of
resources (both virtual and physical) available to the latter, based on a set of
lease terms presented by the consumer. Here lease may be described as a contract
between user and reservation service about cloud resources to be provided right
now or later. Technically speaking, lease is a group of reservations granted to
a particular project upon request. Lease is characterized by start time, end
time, set of individual reservations and associated events.
cloud resources available to the latter, based on a set of lease terms presented
by the consumer. Technically speaking, lease is a group of reservations granted to
a particular project upon request. Main properties of a lease are its start time, end
time, set of reservations and set of events.
**Event** is simply something that may happen to a lease. In most simple case, event
might describe lease start and lease end. Also it might be a notification to user
(e.g. about soon lease expiration) and some extra actions.
Rationale
---------
Blazar is created to:
* manage cloud resources not only right now, but also in the future;
* have dedicated resources for a certain amount of time;
* prepare for the peak loads and perform capacity planning;
* optimize energy consumption.
Lease types (concepts)
----------------------
* **Immediate reservation**. Resources are provisioned immediately (like VM
boot or moving host to reserved user aggregate) or not at all. If request can
be fulfilled, lease is created and **success** status is returned. Lease
should be marked as **active** or **to_be_started**. Otherwise (if
request resource cannot be provisioned right now) failure status for this
request should be returned.
* **Reservation with retries**. Mostly looks like previous variant, but in case
of failure, user may want to have several (configurable number) retries to
process lease creation action. In this case request will be processed till
that will be possible to create lease but not more than set in configuration
file number of times.
* **Best-effort reservation**. Also might have place if lease creation request
cannot be fulfilled immediately. Best-effort mechanism starts something like
scavenger hunt trying to find resources for reservations. For compute hosts
reservation that makes much sense, because in case there are instances
belonging to other project on eligible hosts, and without them there will be
possible to reserve these hosts, Blazar may start instances migration.
This operation can be timely and fairly complex and so different strategies
may be applied depending on heuristic factors such as the number, type and
state of the instances to be migrated. Also Blazar should assert that there
are at least enough potential candidates for the migration prior to starting
the actual migration. If Blazar decides to start migration, it returns
**success** state and marks lease as **in_progress**, otherwise -
**failure**. If this 'hunting' ends successfully before configurable
timeout has passed, lease should be marked as **active**, otherwise its
status is set to **timedout**.
* **Delayed resource acquiring** or **scheduled reservation**. In this
reservation type, lease is created successfully if Blazar thinks there will
be enough resources to process provisioning later (otherwise this request
returns **failure** status). Lease is marked as **inactive** till all
resources will be actually provisioned. That works pretty nice and
predictable speaking about compute hosts reservation (because hosts as
resources are got not from common cloud pool, but from admin defined pool).
So it is possible for Blazar to predict these physical resources usage and use
that information during lease creation. If we speak about virtual reservations,
here situation is more complicated, because all resources are got from common
cloud resources pool, and Blazar cannot guarantee there will be enough
resources to provision them. In this failure case lease state will be marked
as **error** with appropriate explanation.
**Event** is something that may happen to a lease. In the simplest case, an event
might describe lease start and lease end. It might also be a notification to user
(e.g. about an upcoming lease expiration).