Rework Bare Metal service overview in the install guide
Currently we have a detailed explanation of how ironic is architected, but it resides in the user guide for some reason. This change moves relevant bits to the install guide to the existing "Bare Metal service overview" section. The text is cleaned up (e.g. s/ironic/Bare Metal/) and ordered to simplify reading. A link to ironic-ui is added. The user guide still contains the bits that are helpful for users to understand the bare metal deployment process. Change-Id: I17e38454f7893c00b71ac29328bd80d3978ed1f4
This commit is contained in:
parent
5c91ea0ce6
commit
c9e079da68
@ -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
Block a user