Merge "Rework Bare Metal service overview in the install guide"
This commit is contained in:
Zuul
Gerrit Code Review
commit
ffa7dd520e
|
|
@ -2,12 +2,73 @@
|
|||
Bare Metal service overview
|
||||
===========================
|
||||
|
||||
The Bare Metal service is a collection of components that provides support to
|
||||
manage and provision physical machines.
|
||||
The Bare Metal service, codenamed ``ironic``, is a collection of components
|
||||
that provides support to manage and provision physical machines.
|
||||
|
||||
Also known as the ``ironic`` project, the Bare Metal service may, depending
|
||||
upon configuration, interact with several other OpenStack services. This
|
||||
includes:
|
||||
Bare Metal service components
|
||||
-----------------------------
|
||||
|
||||
The Bare Metal service includes the following components:
|
||||
|
||||
ironic-api
|
||||
A RESTful API that processes application requests by sending them to the
|
||||
ironic-conductor over `remote procedure call (RPC)`_. Can be run through
|
||||
WSGI_ or as a separate process.
|
||||
|
||||
ironic-conductor
|
||||
Adds/edits/deletes nodes; powers on/off nodes with IPMI or other
|
||||
vendor-specific protocol; provisions/deploys/cleans bare metal nodes.
|
||||
|
||||
ironic-conductor uses :doc:`drivers </install/enabling-drivers>` to execute
|
||||
operations on hardware.
|
||||
|
||||
ironic-python-agent
|
||||
A python service which is run in a temporary ramdisk to provide
|
||||
ironic-conductor and ironic-inspector services with remote access, in-band
|
||||
hardware control, and hardware introspection.
|
||||
|
||||
Additionally, the Bare Metal service has certain external dependencies, which
|
||||
are very similar to other OpenStack services:
|
||||
|
||||
- A database to store hardware information and state. You can set the database
|
||||
back-end type and location. A simple approach is to use the same database
|
||||
back end as the Compute service. Another approach is to use a separate
|
||||
database back-end to further isolate bare metal resources (and associated
|
||||
metadata) from users.
|
||||
|
||||
- An oslo.messaging_ compatible queue, such as RabbitMQ. It may use the same
|
||||
implementation as that of the Compute service, but that is not a requirement.
|
||||
Used to implement RPC between ironic-api and ironic-conductor.
|
||||
|
||||
Deployment architecture
|
||||
-----------------------
|
||||
|
||||
The Bare Metal RESTful API service is used to enroll hardware that the Bare
|
||||
Metal service will manage. A cloud administrator usually registers it,
|
||||
specifying their attributes such as MAC addresses and IPMI credentials.
|
||||
There can be multiple instances of the API service.
|
||||
|
||||
The *ironic-conductor* process does the bulk of the work. For security
|
||||
reasons, it is advisable to place it on an isolated host, since it is the only
|
||||
service that requires access to both the data plane and IPMI control plane.
|
||||
|
||||
There can be multiple instances of the conductor service to support
|
||||
various class of drivers and also to manage fail over. Instances of the
|
||||
conductor service should be on separate nodes. Each conductor can itself run
|
||||
many drivers to operate heterogeneous hardware. This is depicted in the
|
||||
following figure.
|
||||
|
||||
.. figure:: ../images/deployment_architecture_2.png
|
||||
:alt: Deployment Architecture
|
||||
|
||||
The API exposes a list of supported drivers and the names of conductor hosts
|
||||
servicing them.
|
||||
|
||||
Interaction with OpenStack components
|
||||
-------------------------------------
|
||||
|
||||
The Bare Metal service may, depending upon configuration, interact with several
|
||||
other OpenStack services. This includes:
|
||||
|
||||
- the OpenStack Telemetry module (``ceilometer``) for consuming the IPMI
|
||||
metrics
|
||||
|
|
@ -26,34 +87,33 @@ includes:
|
|||
- the OpenStack Object Storage (``swift``) provides temporary storage
|
||||
for the configdrive, user images, deployment logs and inspection data.
|
||||
|
||||
The Bare Metal service includes the following components:
|
||||
Logical architecture
|
||||
--------------------
|
||||
|
||||
ironic-api
|
||||
A RESTful API that processes application requests by sending them to the
|
||||
ironic-conductor over `remote procedure call (RPC)`_.
|
||||
The diagram below shows the logical architecture. It shows the basic
|
||||
components that form the Bare Metal service, the relation of the Bare Metal
|
||||
service with other OpenStack services and the logical flow of a boot instance
|
||||
request resulting in the provisioning of a physical server.
|
||||
|
||||
ironic-conductor
|
||||
Adds/edits/deletes nodes; powers on/off nodes with ipmi or other
|
||||
vendor-specific protocol;
|
||||
provisions/deploys/cleans bare metal nodes.
|
||||
.. figure:: ../images/logical_architecture.png
|
||||
:alt: Logical Architecture
|
||||
|
||||
ironic-python-agent
|
||||
A python service which is run in a temporary ramdisk to provide
|
||||
ironic-conductor and ironic-inspector services with remote access, in-band
|
||||
hardware control, and hardware introspection.
|
||||
A user's request to boot an instance is passed to the Compute service via
|
||||
the Compute API and the Compute Scheduler. The Compute service uses the
|
||||
*ironic virt driver* to hand over this request to the Bare Metal service,
|
||||
where the request passes from the Bare Metal API, to the Conductor, to a Driver
|
||||
to successfully provision a physical server for the user.
|
||||
|
||||
.. _`remote procedure call (RPC)`: https://en.wikipedia.org/wiki/Remote_procedure_call
|
||||
Just as the Compute service talks to various OpenStack services like
|
||||
Image, Network, Object Store etc to provision a virtual machine instance, here
|
||||
the Bare Metal service talks to the same OpenStack services for image, network
|
||||
and other resource needs to provision a bare metal instance.
|
||||
|
||||
Additionally, the Bare Metal service has certain external dependencies, which
|
||||
are very similar to other OpenStack services:
|
||||
See :ref:`understanding-deployment` for a more detailed breakdown of
|
||||
a typical deployment process.
|
||||
|
||||
- A database to store hardware information and state. You can set the database
|
||||
back-end type and location. A simple approach is to use the same database
|
||||
back end as the Compute service. Another approach is to use a separate
|
||||
database back-end to further isolate bare metal resources (and associated
|
||||
metadata) from users.
|
||||
- An oslo.messaging compatible queue, such as RabbitMQ. It may use the same
|
||||
implementation as that of the Compute service, but that is not a requirement.
|
||||
Associated projects
|
||||
-------------------
|
||||
|
||||
Optionally, one may wish to utilize the following associated projects for
|
||||
additional functionality:
|
||||
|
|
@ -62,6 +122,10 @@ python-ironicclient_
|
|||
A command-line interface (CLI) and python bindings for interacting with the
|
||||
Bare Metal service.
|
||||
|
||||
ironic-ui_
|
||||
Horizon dashboard, providing graphical interface (GUI) for the Bare Metal
|
||||
API.
|
||||
|
||||
ironic-inspector_
|
||||
An associated service which performs in-band hardware introspection by
|
||||
PXE booting unregistered hardware into the ironic-python-agent ramdisk.
|
||||
|
|
@ -74,7 +138,11 @@ bifrost_
|
|||
A set of Ansible playbooks that automates the task of deploying a base image
|
||||
onto a set of known hardware using ironic in a standalone mode.
|
||||
|
||||
.. _remote procedure call (RPC): https://en.wikipedia.org/wiki/Remote_procedure_call
|
||||
.. _WSGI: https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface
|
||||
.. _oslo.messaging: https://docs.openstack.org/oslo.messaging/latest/
|
||||
.. _python-ironicclient: https://docs.openstack.org/python-ironicclient/latest/
|
||||
.. _ironic-ui: https://docs.openstack.org/ironic-ui/latest/
|
||||
.. _ironic-inspector: https://docs.openstack.org/ironic-inspector/latest/
|
||||
.. _diskimage-builder: https://docs.openstack.org/diskimage-builder/latest/
|
||||
.. _bifrost: https://docs.openstack.org/bifrost/latest/
|
||||
|
|
|
|||
|
|
@ -49,45 +49,6 @@ Swift can be used with Ironic, but are missing from this diagram.)
|
|||
.. figure:: ../images/conceptual_architecture.png
|
||||
:alt: ConceptualArchitecture
|
||||
|
||||
Logical Architecture
|
||||
====================
|
||||
|
||||
The diagram below shows the logical architecture. It shows the basic
|
||||
components that form the Ironic service, the relation of Ironic service with
|
||||
other OpenStack services and the logical flow of a boot instance request
|
||||
resulting in the provisioning of a physical server.
|
||||
|
||||
.. figure:: ../images/logical_architecture.png
|
||||
:alt: Logical Architecture
|
||||
|
||||
The Ironic service is composed of the following components:
|
||||
|
||||
#. a RESTful API service, by which operators and other services may interact
|
||||
with the managed bare metal servers.
|
||||
|
||||
#. a Conductor service, which does the bulk of the work. Functionality is
|
||||
exposed via the API service. The Conductor and API services communicate
|
||||
via RPC.
|
||||
|
||||
#. various Drivers that support heterogeneous hardware
|
||||
|
||||
#. a Message Queue
|
||||
|
||||
#. a Database for storing information about the resources. Among other things,
|
||||
this includes the state of the conductors, nodes (physical servers), and
|
||||
drivers.
|
||||
|
||||
As in Figure 1.2. Logical Architecture, a user request to boot an instance is
|
||||
passed to the Nova Compute service via Nova API and Nova Scheduler. The Compute
|
||||
service hands over this request to the Ironic service, where the request passes
|
||||
from the Ironic API, to the Conductor, to a Driver to successfully provision a
|
||||
physical server for the user.
|
||||
|
||||
Just as the Nova Compute service talks to various OpenStack services like
|
||||
Glance, Neutron, Swift etc to provision a virtual machine instance, here the
|
||||
Ironic service talks to the same OpenStack services for image, network and
|
||||
other resource needs to provision a bare metal instance.
|
||||
|
||||
|
||||
Key Technologies for Bare Metal Hosting
|
||||
=======================================
|
||||
|
|
@ -131,31 +92,7 @@ operation. It is a method to manage systems that may be unresponsive or powered
|
|||
off by using only a network connection to the hardware rather than to an
|
||||
operating system.
|
||||
|
||||
|
||||
Ironic Deployment Architecture
|
||||
==============================
|
||||
|
||||
The Ironic RESTful API service is used to enroll hardware that Ironic will
|
||||
manage. A cloud administrator usually registers the hardware, specifying their
|
||||
attributes such as MAC addresses and IPMI credentials. There can be multiple
|
||||
instances of the API service.
|
||||
|
||||
The Ironic conductor service does the bulk of the work.
|
||||
For security reasons, it is advisable to place the conductor service on
|
||||
an isolated host, since it is the only service that requires access to both
|
||||
the data plane and IPMI control plane.
|
||||
|
||||
There can be multiple instances of the conductor service to support
|
||||
various class of drivers and also to manage fail over. Instances of the
|
||||
conductor service should be on separate nodes. Each conductor can itself run
|
||||
many drivers to operate heterogeneous hardware. This is depicted in the
|
||||
following figure.
|
||||
|
||||
The API exposes a list of supported drivers and the names of conductor hosts
|
||||
servicing them.
|
||||
|
||||
.. figure:: ../images/deployment_architecture_2.png
|
||||
:alt: Deployment Architecture 2
|
||||
.. _understanding-deployment:
|
||||
|
||||
Understanding Bare Metal Deployment
|
||||
===================================
|
||||
|
|
|
|||
Loading…
Reference in New Issue