Introduce Terminology Reference document
Note that this document needs a lot of xrefs added and it includes some xrefs that aren't in the prefered :ref: format. These will be resolved but I don't want to pull all the docs that need tags into this commit so will do that separately. Change-Id: I35974a294f947f12106c7943e0c89df6c86347ad
This commit is contained in:
Meg McRoberts
Dmitry Borodaenko
parent
d16128c1ce
commit
b1acab7c85
|
|
@ -19,4 +19,5 @@ Documentation
|
|||
reference-architecture
|
||||
release-notes
|
||||
frequently-asked-questions
|
||||
terminology
|
||||
eula
|
||||
|
|
|
|||
|
|
@ -6,4 +6,3 @@
|
|||
.. include:: /pages/pre-install-guide/0080-reference-configuration.rst
|
||||
.. include:: /pages/pre-install-guide/0090-appendix.rst
|
||||
.. include:: /pages/pre-install-guide/0030-pre-installation-checklist.rst
|
||||
.. include:: /pages/pre-install-guide/0091-glossary.rst
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
.. include:: /pages/terminology/allterms.rst
|
||||
|
|
@ -39,6 +39,11 @@ The following Mirantis OpenStack documentation is available in PDF:
|
|||
A deep dive into the structure of the Fuel OpenStack environment,
|
||||
network considerations, and deployment options.
|
||||
|
||||
* `Terminology Reference <pdf/Mirantis-OpenStack-4.1-Terminology-Reference.pdf>`_
|
||||
|
||||
Short articles about OpenStack terminology and technology
|
||||
with references to other documentation and other useful information.
|
||||
|
||||
* `Release Notes 4.1 <pdf/Mirantis-OpenStack-4.1-RelNotes.pdf>`_
|
||||
|
||||
The Release Notes provide general information about new features,
|
||||
|
|
|
|||
|
|
@ -4,6 +4,8 @@
|
|||
|
||||
.. index:: HA with Pacemaker and Corosync
|
||||
|
||||
.. HA_Pacemaker_Corosync
|
||||
|
||||
How HA with Pacemaker and Corosync Works
|
||||
========================================
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
Introduction
|
||||
============
|
||||
|
||||
.. index:: Introduction
|
||||
|
||||
.. include:: /pages/install-guide/0000-intro/0000-intro-header.rst
|
||||
.. include:: /pages/install-guide/0000-intro/0100-fuel-intro.rst
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
.. index:: Murano-operations
|
||||
|
||||
.. _murano-deploy-notes:
|
||||
.. _Murano-deployment-notes:
|
||||
|
||||
Murano Deployment Notes
|
||||
==================================
|
||||
|
|
|
|||
|
|
@ -1,6 +1,3 @@
|
|||
.. index:: Introduction
|
||||
|
||||
.. _QSIntro:
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
|
|
|||
|
|
@ -1,377 +0,0 @@
|
|||
Dictionary of terms used in this document
|
||||
=========================================
|
||||
|
||||
Bonding
|
||||
-------
|
||||
|
||||
NIC Bonding (also called NIC Aggregation)
|
||||
allows you to aggregate multiple physical links to one link
|
||||
to increase speed and provide fault tolerance.
|
||||
|
||||
Bonding is supported in the following modes:
|
||||
Active-backup, Balance SLB (Source Level Bonding),
|
||||
and Balance TCP with LACP (Link Aggregation Control Protocol).
|
||||
|
||||
The Fuel UI prevents you from configuring Bonding TCP by itself, without LACP.
|
||||
|
||||
Ceilometer
|
||||
----------
|
||||
Ceilometer collects measurements for monitoring and metering within OpenStack;
|
||||
the framework can be expanded to collect measurements for other needs.
|
||||
See the `Ceilometer wiki <https://wiki.openstack.org/wiki/Ceilometer>`_
|
||||
for more information.
|
||||
|
||||
Fuel can optionally deploy Ceilometer on any supported environment.
|
||||
See `Ceilometer deployment notes <http://docs.mirantis.com/fuel/fuel-4.1/user-guide.html#ceilometer-deployment-notes>`_
|
||||
for more information.
|
||||
|
||||
Ceph
|
||||
----
|
||||
An open source storage platform
|
||||
that provides unified object, block, and file storage.
|
||||
For more information, see the
|
||||
`Ceph documentation <http://ceph.com/docs/master/>`_.
|
||||
Ceph is supported and promoted by
|
||||
`Inktank <http://www.inktank.com>`_.
|
||||
|
||||
For information about deploying Ceph in Mirantis OpenStack,
|
||||
see `Storage Architecture <http://docs.mirantis.com/fuel/fuel-4.1/reference-architecture.html#storage-architecture>`_.
|
||||
|
||||
Cinder
|
||||
------
|
||||
Cinder is the code name for the OpenStack Block Storage project.
|
||||
Cinder was originally part of the Nova project
|
||||
but is now an independent core OpenStack project.
|
||||
For more information, see the
|
||||
`Cinder developer documentation <http://docs.openstack.org/developer/cinder/>`_.
|
||||
|
||||
Cinder can be deployed on its own OpenStack storage node
|
||||
(often called a "Cinder node")
|
||||
or can share a Controller node.
|
||||
For information about deploying Cinder in Mirantis OpenStack,
|
||||
see `Storage Architecture <http://docs.mirantis.com/fuel/fuel-4.1/reference-architecture.html#storage-architecture>`_.
|
||||
|
||||
Corosync
|
||||
--------
|
||||
The Corosync Cluster Engine is a Group Communication System
|
||||
with additional features for implementing high availability within applications.
|
||||
See the `Corosync home page <http://corosync.github.io/corosync/>`_
|
||||
for more information.
|
||||
For a good discussion about Pacemaker and Corosync
|
||||
and how they are related, see
|
||||
`What is Pacemaker? <http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html-single/Clusters_from_Scratch/#_what_is_pacemaker>`_.
|
||||
|
||||
Mirantis OpenStack uses Corosync with the Pacemaker cluster resource manager
|
||||
as the communication and quorum service; see
|
||||
`How HA with Pacemaker and Corosync Works <http://docs.mirantis.com/fuel/fuel-4.1/frequently-asked-questions.html#how-ha-with-pacemaker-and-corosync-works>`_
|
||||
for technical details about this implementation;
|
||||
the preceeding section of that documentation tells how to recover
|
||||
when Corosync's networking protocol (Totem) times out.
|
||||
|
||||
DevStack
|
||||
--------
|
||||
An OpenStack package that can be installed and deployed on your laptop
|
||||
or inside a VM on a cloud or other machine for evaluation purposes.
|
||||
DevStack runs in a virtual machine so does not give the same performance
|
||||
as OpenStack running on dedicated hardware
|
||||
and it only runs a single node.
|
||||
See the `DevStack web page <http://devstack.org/>`_
|
||||
for installation instructions.
|
||||
|
||||
Fuel is a more powerful tool that supports a virtualized deployment
|
||||
including multiple controllers and support for HA.
|
||||
Fuel can also be used to deploy a bare-metal cloud
|
||||
installed on bare metal and appropriate for a production environment.
|
||||
|
||||
Fencing
|
||||
-------
|
||||
Process of locking resources away from a node whose status is uncertain.
|
||||
Ceph supports fencing but you must ensure
|
||||
that no controllers host both the Ceph OSD and Ceph Mon roles.
|
||||
|
||||
Fuel Master Node
|
||||
----------------
|
||||
A server with the Mirantis Fuel application installed,
|
||||
also commonly referred to as the Fuel server.
|
||||
The Fuel Master node runs on its own server or VM
|
||||
to deploy and manage OpenStack environments.
|
||||
It assigns IP addresses to the OpenStack nodes,
|
||||
performs PXE boot and initial configuration,
|
||||
and provisions the nodes according to their roles in the environment.
|
||||
|
||||
Galera Cluster for MySQL
|
||||
------------------------
|
||||
Galera is a synchronous multi-master cluster
|
||||
for the MySQL database.
|
||||
Mirantis OpenStack uses MySQL/Galeria for HA deployments;
|
||||
see the `FAQ <http://docs.mirantis.com/fuel/fuel-4.1/frequently-asked-questions.html#other-questions>`_
|
||||
for more information.
|
||||
|
||||
Havana
|
||||
------
|
||||
Code name for the eighth release of the OpenStack software.
|
||||
For more information, see the
|
||||
`Havana web site <http://www.openstack.org/software/havana/>`_.
|
||||
Mirantis OpenStack version 4.x and Fuel 4.x incorporate and support
|
||||
the Havana code base
|
||||
except for the following features:
|
||||
The following improvements in Havana are not supported directly by Fuel 4.x
|
||||
although they are included in Mirantis OpenStack 4.x:
|
||||
|
||||
* Nova Compute: Cells, Availability zones, Host aggregates
|
||||
* Neutron (formerly Quantum): Load Balancer as a Service (LBaaS),
|
||||
Multiple L3 and DHCP agents per cloud
|
||||
* Keystone: Multi-factor authentication, PKI authentication
|
||||
* Swift: Regions, Adjustable replica count, Cross-project ACLs
|
||||
* Cinder: Cinder-backup service, Support for Fibre Channel over Ethernet (FCoE),
|
||||
Support for linux-iscsi.org (LIO)
|
||||
as an Internet Small Computer System Interface (iSCSI) backend
|
||||
|
||||
Heat
|
||||
----
|
||||
Main project in the OpenStack Orchestration program.
|
||||
Heat uses a template that humans can read and write
|
||||
and that can be maintained under source code control.
|
||||
See the `Heat wiki <https://wiki.openstack.org/wiki/Heat>`_
|
||||
for more information.
|
||||
|
||||
Mirantis OpenStack 4.0 and later
|
||||
integrates the Heat project.
|
||||
Fuel automatically deploys Heat into each environment.
|
||||
See `Heat Deployment Notes <http://docs.mirantis.com/fuel/fuel-4.1/user-guide.html#heat-deployment-notes>`_
|
||||
for more information.
|
||||
|
||||
Hypervisor
|
||||
----------
|
||||
A hypervisor creates and runs virtual machines.
|
||||
OpenStack runs a hypervisor as a component of the compute node.
|
||||
You can select the KVM or QEMU hypervisor from the Fuel UI;
|
||||
other hypervisors are available through
|
||||
`Mirantis Services <http://www.mirantis.com/openstack-services>`_.
|
||||
See the `HypervisorSupportMatrix <https://wiki.openstack.org/wiki/HypervisorSupportMatrix>`_
|
||||
web page for information about the status of other hypervisors for OpenStack.
|
||||
|
||||
Ironic
|
||||
------
|
||||
Ironic is an API to manage and provision physical machines;
|
||||
it is currently an incubated project that is forked from and will replace
|
||||
the Nova "baremetal" driver used in the Grizzly and Havana releases.
|
||||
See the `Ironic wiki page <https://wiki.openstack.org/wiki/Ironic>`_.
|
||||
|
||||
Mirantis OpenStack
|
||||
------------------
|
||||
Hardened OpenStack distribution plus additional services
|
||||
for high availability deployed by Fuel.
|
||||
Fuel deploys Mirantis OpenStack with an operating system
|
||||
based on either the Ubuntu or CentOS Linux distro.
|
||||
|
||||
Murano
|
||||
------
|
||||
Project that enables OpenStack to run on a Windows virtual machine.
|
||||
It supports Availability Zones, Disaster Recovery scenarios,
|
||||
and uses native Microsoft Windows features to provide HA solutions.
|
||||
See the `Murano wiki <https://wiki.openstack.org/wiki/Murano>`_.
|
||||
|
||||
Fuel can deploy a Dashboard, the Murano API,
|
||||
the Conductor orchestration engine, and a Metadata Repository
|
||||
on top of the Windows components that the customer
|
||||
installs and deploys natively without using Fuel.
|
||||
See `Murano Deployment Notes <http://docs.mirantis.com/fuel/fuel-4.1/user-guide.html#murano-deployment-notes>`_
|
||||
for more information about deploying Murano with Fuel.
|
||||
|
||||
MySQL
|
||||
------
|
||||
The database most frequently used in OpenStack deployments.
|
||||
The MySQL database runs on the controller node;
|
||||
MySQL client software must be installed on other nodes
|
||||
that access the MySQL database.
|
||||
|
||||
For HA deployments,
|
||||
Mirantis OpenStack uses Pacemaker/Corosync
|
||||
to provide redundancy and failover capabilities
|
||||
for MySQL.
|
||||
Mirantis OpenStack uses MySQL/Galera for database replication
|
||||
in HA deployments that use the CentOS or Ubuntu kernel;
|
||||
see `Preparing MySQL for Pacemaker high availability <http://docs.openstack.org/trunk/openstack-ops/content/security_groups.html>`_.
|
||||
|
||||
Native VLAN
|
||||
-----------
|
||||
An untagged VLAN on a tagged port.
|
||||
|
||||
Nailgun server
|
||||
--------------
|
||||
Nailgun is the configuration and management service
|
||||
used as the backend for the Fuel UI.
|
||||
|
||||
Note that Nailgun in Fuel
|
||||
is not in any way related to the Nailgun that provides
|
||||
a JVM in which Java programs can be run without incurring
|
||||
the standard JVM startup overhead.
|
||||
|
||||
Neutron (Quantum)
|
||||
-----------------
|
||||
OpenStack Core project to provide networking as a service
|
||||
between interface devices such as vNICS
|
||||
that are managed by other OpenStack services such as Nova.
|
||||
See the `Neutron web page <https://wiki.openstack.org/wiki/Neutron>`_
|
||||
for more information.
|
||||
|
||||
Mirantis OpenStack includes Neutron;
|
||||
see `Neutron Deployment <http://docs.mirantis.com/fuel/fuel-4.1/pre-install-guide.html#neutron>`_
|
||||
for a description of the recommended network configuration parameters
|
||||
for using the Neutron service.
|
||||
|
||||
NIC (Network Interface Card)
|
||||
----------------------------
|
||||
This usually refers to the physical Ethernet port
|
||||
and the hardware used for networking
|
||||
although in a virtualized deployment,
|
||||
it can also refer to the software interfaces
|
||||
between virtual machines.
|
||||
Configuring the NICS correctly is one of the more challenging tasks
|
||||
in deploying OpenStack.
|
||||
The following documents provide information:
|
||||
|
||||
* For a list of the types of networks used in OpenStack
|
||||
(Public, Storage, Administrative, and so forth), see
|
||||
`Network Configuration Options <http://docs.mirantis.com/fuel/fuel-4.1/pre-install-guide.html#network-configuration-options>`_
|
||||
|
||||
* For diagrams, detailed discussions, and instructions for deploying
|
||||
the different networking models, see
|
||||
`Network Deployment Models <http://docs.mirantis.com/fuel/fuel-4.1/pre-install-guide.html#network-deployment-models>`_,
|
||||
`Understanding and Configuring the Network <http://docs.mirantis.com/fuel/fuel-4.1/install-guide.html#understanding-and-configuring-the-network>`_, and
|
||||
`Fuel Deployment Schema <http://docs.mirantis.com/fuel/fuel-4.1/install-guide.html#fuel-deployment-schema>`_
|
||||
|
||||
* For information about calculating the hardware required for your deployment, see
|
||||
`Calculating Network <http://docs.mirantis.com/fuel/fuel-4.1/install-guide.html#calculating-network>`_.
|
||||
|
||||
* `Installing Fuel Master Node <http://docs.mirantis.com/fuel/fuel-4.1/install-guide.html#installing-fuel-master-node>`_
|
||||
includes instructions for changing network parameters
|
||||
during and after installation.
|
||||
|
||||
* `Advanced Network Configuration Using VSwitch <http://docs.mirantis.com/fuel/fuel-4.1/reference-architecture.html#advanced-network-configuration-using-open-vswitch>`_
|
||||
describes Open VSwitch and includes instructions for adjusting the network configuration
|
||||
by editing configuration files and using the command-line tools.
|
||||
|
||||
* `Network Architecture <http://docs.mirantis.com/fuel/fuel-4.1/reference-architecture.html#network-architecture>`_
|
||||
|
||||
Node
|
||||
-----------
|
||||
A server or VM that provides specific functionality
|
||||
within an OpenStack environment.
|
||||
For example, Fuel deploys Controller nodes, Compute nodes,
|
||||
and Storage nodes.
|
||||
|
||||
Nova
|
||||
----
|
||||
OpenStack Core project used for compute nodes;
|
||||
all major Nova components can be run on multiple servers
|
||||
and use message queues for communication between components.
|
||||
See the `Nova web page <http://docs.openstack.org/developer/nova/>`_
|
||||
for more information.
|
||||
|
||||
Mirantis OpenStack includes the Nova-network deployment model
|
||||
which offers the FlatDHCPManager and VLAN Manager options
|
||||
for deploying private networks for tenants;
|
||||
see `Nova-network Deployment Model <http://docs.mirantis.com/fuel/fuel-4.1/pre-install-guide.html#nova-network>`_
|
||||
for more information about using Nova-network in Mirantis OpenStack.
|
||||
|
||||
The Baremetal driver used for provisioning in Nova
|
||||
has recently been forked into its own project; see "Ironic".
|
||||
|
||||
Object Storage technology
|
||||
-------------------------
|
||||
Provides a fully distributed, API-accessible storage platform
|
||||
that can be integraed directly into applications
|
||||
or used for backup, archiving, and data retention.
|
||||
This is not a traditional file system
|
||||
but rather a distributed storage system for static data
|
||||
such as virtual machine images, photo storage, email storage,
|
||||
backups, and archives.
|
||||
Objects and files are written to multiple disk drives
|
||||
spread across different servers in the data center;
|
||||
the OpenStack software ensures data replication and integrity
|
||||
across the cluster.
|
||||
|
||||
OpenStack
|
||||
---------
|
||||
Open source software that can be used
|
||||
to deliver a massively scalable cloud operating system
|
||||
for private and public clouds.
|
||||
For more information, see the
|
||||
`OpenStack web page <http://www.openstack.org/>`_ and
|
||||
`OpenStack documentation <http://docs.openstack.org/>`_.
|
||||
|
||||
The Mirantis OpenStack distribution packages
|
||||
a stable version of the open source pieces
|
||||
into an installable package that deploys an operating system
|
||||
based on either Ubuntu or CentOS.
|
||||
and adds Fuel to simplify the deployment and management tasks.
|
||||
|
||||
OVS (Open vSwitch)
|
||||
------------------
|
||||
Multilayer virtual switch that the Neutron networking model uses
|
||||
to create a felxible network setup and to isolate tenants from each other on L2 and L3 layers.
|
||||
You can do some basic configuration of OVS on the Fuel UI beginning with Fuel 4.1;
|
||||
additional customization can be done
|
||||
by editing configuration files and using the command-line tools; see
|
||||
`Advanced Network Configuration Using VSwitch <http://docs.mirantis.com/fuel/fuel-4.1/reference-architecture.html#advanced-network-configuration-using-open-vswitch>`_.
|
||||
|
||||
Pacemaker
|
||||
---------
|
||||
Master control process for OpenStack High Availability deployments.
|
||||
Pacemaker is part of the Corosync services and is not specific to OpenStack.
|
||||
|
||||
See:
|
||||
|
||||
* `What is Pacemaker? <http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html-single/Clusters_from_Scratch/#_what_is_pacemaker>`_
|
||||
for a good discussion about Pacemaker and Corosync and how they are related.
|
||||
* `The Pacemaker Cluster Stack <http://docs.openstack.org/high-availability-guide/content/ch-pacemaker.html>`_
|
||||
discusses how Pacemaker is used with OpenStack.
|
||||
* `Pacemaker web page <http://clusterlabs.org/doc/>`_
|
||||
contains more in-depth information about Pacemaker.
|
||||
|
||||
Fuel uses Pacemaker to implement its Multi-Node-HA deployment.
|
||||
|
||||
Puppet
|
||||
------
|
||||
Puppet modules bring scalable and reliable IT automation
|
||||
to OpenStack cloud deployments.
|
||||
See the `Puppet web page <http://puppetlabs.com/solutions/cloud-automation/compute/openstack>`_ for more details.
|
||||
|
||||
Fuel uses Puppet as the configuration management system
|
||||
that compiles a set of instructions
|
||||
for a configurable, reproducible, and sharable installation process.
|
||||
In Fuel 4.1 and later, the Puppet modules and manifests are synchronized
|
||||
between the master nodes and the managed nodes, then applied locally.
|
||||
This solves the security signing, scalability, and performance issues
|
||||
encountered on earlier releases where the Puppet Master Node ran on the Fuel Node Master.
|
||||
|
||||
Passing custom attributes can be helpful when you have some Puppet manifests that should be run
|
||||
but are not supported by Fuel itself. see
|
||||
`Passing Custom Attributes from Fuel to Puppet <http://docs.mirantis.com/fuel/fuel-4.1/user-guide.html#passing-custom-attributes-from-fuel-to-puppet>`_.
|
||||
|
||||
QEMU
|
||||
----
|
||||
One of the hypervisors that can be selected from the Fuel UI.
|
||||
|
||||
Security groups
|
||||
---------------
|
||||
Sets of IP filter rules that are applied to an instance's networking.
|
||||
Most projects provide a "default" security group
|
||||
that is applied to instances that have no security group defined.
|
||||
See the `Security groups web page <http://docs.openstack.org/trunk/openstack-ops/content/security_groups.html>`_
|
||||
for more information.
|
||||
|
||||
Note that Savanna does does not provide a default security group.
|
||||
See this `note in <https://review.openstack.org/#/c/71299/>`_
|
||||
for information about defining a default security group for Savanna).
|
||||
|
||||
STP
|
||||
---
|
||||
Spanning Tree Protocol
|
||||
|
||||
Tagged port
|
||||
-----------
|
||||
802.1q frames from a switch to a server network card.
|
||||
|
||||
|
|
@ -0,0 +1,58 @@
|
|||
.. _Terminology-main:
|
||||
|
||||
Terminology Reference
|
||||
=====================
|
||||
|
||||
.. include:: /pages/terminology/b/bonding.rst
|
||||
.. include:: /pages/terminology/c/ceilometer.rst
|
||||
.. include:: /pages/terminology/c/ceph.rst
|
||||
.. include:: /pages/terminology/c/cinder.rst
|
||||
.. include:: /pages/terminology/c/compute-nodes.rst
|
||||
.. include:: /pages/terminology/c/corosync.rst
|
||||
.. include:: /pages/terminology/c/crm.rst
|
||||
.. include:: /pages/terminology/d/devstack.rst
|
||||
.. include:: /pages/terminology/f/fencing.rst
|
||||
.. include:: /pages/terminology/f/fuel-master-node.rst
|
||||
.. include:: /pages/terminology/g/galera-cluster.rst
|
||||
.. include:: /pages/terminology/h/hadoop.rst
|
||||
.. include:: /pages/terminology/h/havana-term.rst
|
||||
.. include:: /pages/terminology/h/heat.rst
|
||||
.. include:: /pages/terminology/h/horizon.rst
|
||||
.. include:: /pages/terminology/h/hypervisor.rst
|
||||
.. include:: /pages/terminology/i/icehouse.rst
|
||||
.. include:: /pages/terminology/i/identity-service.rst
|
||||
.. include:: /pages/terminology/i/image-service.rst
|
||||
.. include:: /pages/terminology/i/ironic.rst
|
||||
.. include:: /pages/terminology/m/mirantis-openstack.rst
|
||||
.. include:: /pages/terminology/m/mongodb.rst
|
||||
.. include:: /pages/terminology/m/murano.rst
|
||||
.. include:: /pages/terminology/m/mysql.rst
|
||||
.. include:: /pages/terminology/n/nailgun.rst
|
||||
.. include:: /pages/terminology/n/native-vlan.rst
|
||||
.. include:: /pages/terminology/n/networking.rst
|
||||
.. include:: /pages/terminology/n/neutron.rst
|
||||
.. include:: /pages/terminology/n/nic-rst
|
||||
.. include:: /pages/terminology/n/node.rst
|
||||
.. include:: /pages/terminology/n/nova.rst
|
||||
.. include:: /pages/terminology/n/nova-network.rst
|
||||
.. include:: /pages/terminology/o/object-storage.rst
|
||||
.. include:: /pages/terminology/o/openstack.rst
|
||||
.. include:: /pages/terminology/o/orchestration-service.rst
|
||||
.. include:: /pages/terminology/o/ovs.rst
|
||||
.. include:: /pages/terminology/p/pacemaker.rst
|
||||
.. include:: /pages/terminology/p/puppet.rst
|
||||
.. include:: /pages/terminology/p/pxe.rst
|
||||
.. include:: /pages/terminology/q/qemu.rst
|
||||
.. include:: /pages/terminology/q/quotas.rst
|
||||
.. include:: /pages/terminology/r/rally.rst
|
||||
.. include:: /pages/terminology/r/resource-agents.rst
|
||||
.. include:: /pages/terminology/s/sahara.rst
|
||||
.. include:: /pages/terminology/s/security-groups.rst
|
||||
.. include:: /pages/terminology/s/stateless-and-stateful-services.rst
|
||||
.. include:: /pages/terminology/s/storage-nodes-and-roles.rst
|
||||
.. include:: /pages/terminology/s/stp.rst
|
||||
.. include:: /pages/terminology/s/swift-object-storage.rst
|
||||
.. include:: /pages/terminology/t/tagged-port.rst
|
||||
.. include:: /pages/terminology/t/telemetry-services.rst
|
||||
.. include:: /pages/terminology/t/tenant.rst
|
||||
.. include:: /pages/terminology/v/vlan.rst
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
|
||||
.. _bonding-term:
|
||||
|
||||
Bonding
|
||||
-------
|
||||
|
||||
NIC Bonding (also called NIC Aggregation)
|
||||
allows you to aggregate multiple physical links to one link
|
||||
to increase speed and provide fault tolerance.
|
||||
|
||||
Bonding is supported in the following modes:
|
||||
Active-backup, Balance SLB (Source Level Bonding),
|
||||
and Balance TCP with LACP (Link Aggregation Control Protocol).
|
||||
|
||||
The Fuel UI prevents you from configuring Bonding TCP by itself, without LACP.
|
||||
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
|
||||
.. _ceilometer-term:
|
||||
|
||||
Ceilometer (OpenStack Telemetry)
|
||||
--------------------------------
|
||||
|
||||
Ceilometer aggregates usage and performance data
|
||||
across all the services deployed in an OpenStack environment.
|
||||
This data provides visibiity and insight
|
||||
into the usage of the cloud across dozens of data points
|
||||
and allows cloud operators to view metrics globally
|
||||
or by individual deployed resources.
|
||||
The information gathered can be used for monitoring and capacity planning,
|
||||
or to create an alarming service,
|
||||
or can serve data to external software for a customer billing system.
|
||||
The framework can be expanded to collect measurements for other needs.
|
||||
|
||||
Fuel can install Ceilometer on systems running
|
||||
either the CentOS or Ubuntu operating system;
|
||||
check the appropriate box when configuring your environment.
|
||||
|
||||
Note that Ceilometer collects a great deal of data
|
||||
and performas a large volume of database writes;
|
||||
for 400 resources inside the cloud,
|
||||
Ceilometer could do up to 13000 writes per office.
|
||||
In Fuel 4.x, Ceilometer uses only the common MySQL database,
|
||||
thus we do not recommend deploying standard Ceilometer
|
||||
for large production installations.
|
||||
|
||||
Notification bus support for Ceilometer is not part of the Fuel 4.x release
|
||||
because of issues with the MySQL backend.
|
||||
.. See
|
||||
.. `Bug 1255107 <https://bugs.launchpad.net/ceilometer/havana/+bug/1255107>`_ and
|
||||
.. `Bug 1257908 <https://bugs.launchpad.net/ceilometer/+bug/1257908>`_
|
||||
for more details.
|
||||
|
||||
The Horizon Metering Panel is disabled in Fuel 4.1;
|
||||
this functionality requires Ceilomter to run with the *metadata_query* feature
|
||||
which Ceilometer does not support with the MySQL driver.
|
||||
.. See `Bug 60317 <https://review.openstack.org/#/c/60317/>`_
|
||||
|
||||
|
||||
For more information, see
|
||||
* :ref:`ceilometer-deployment-notes`
|
||||
* `Ceilometer wiki <https://wiki.openstack.org/wiki/Ceilometer>`_
|
||||
* `Ceilometer blob <https://github.com/openstack/ceilometer/blob/stable/havana/doc/source/install/dbreco.rst>`_
|
||||
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
.. _ceph-term:
|
||||
|
||||
Ceph
|
||||
----
|
||||
An open source storage platform
|
||||
that provides unified object, block, and file storage.
|
||||
For more information, see the
|
||||
`Ceph documentation <http://ceph.com/docs/master/>`_.
|
||||
Ceph is supported and promoted by
|
||||
`Inktank <http://www.inktank.com>`_.
|
||||
|
||||
For information about deploying Ceph in Mirantis OpenStack,
|
||||
see :ref:`Storage_Architecture`.
|
||||
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
.. _cinder-term:
|
||||
|
||||
Cinder
|
||||
------
|
||||
Cinder is the code name for the OpenStack Block Storage project.
|
||||
Cinder was originally part of the Nova project
|
||||
but is now an independent core OpenStack project.
|
||||
For more information, see the
|
||||
`Cinder developer documentation <http://docs.openstack.org/developer/cinder/>`_.
|
||||
|
||||
Cinder can be deployed on its own OpenStack storage node
|
||||
(often called a "Cinder node")
|
||||
or can share a Controller node.
|
||||
For information about deploying Cinder in Mirantis OpenStack,
|
||||
see `Storage Architecture <http://docs.mirantis.com/fuel/fuel-4.1/reference-architecture.html#storage-architecture>`_.
|
||||
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
|
||||
.. _compute-nodes-term:
|
||||
|
||||
Compute nodes (OpenStack Compute)
|
||||
---------------------------------
|
||||
|
||||
Compute servers are the workhorses of your installation;
|
||||
they are the servers on which your users' virtual machines are created.
|
||||
`nova-compute` controls the life cycle of these VMs.
|
||||
|
||||
See the `Compute web site <http://www.openstack.org/software/openstack-compute/>`_
|
||||
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
.. _corosync-term:
|
||||
|
||||
Corosync
|
||||
--------
|
||||
The Corosync Cluster Engine is a Group Communication System
|
||||
with additional features for implementing high availability within applications.
|
||||
See the `Corosync home page <http://corosync.github.io/corosync/>`_
|
||||
for more information.
|
||||
For a good discussion about Pacemaker and Corosync
|
||||
and how they are related, see
|
||||
`What is Pacemaker? <http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html-single/Clusters_from_Scratch/#_what_is_pacemaker>`_.
|
||||
|
||||
Mirantis OpenStack uses Corosync with the Pacemaker cluster resource manager
|
||||
as the communication and quorum service.
|
||||
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
.. _crm-term:
|
||||
|
||||
CRM (Cluster Resource Manager)
|
||||
------------------------------
|
||||
|
||||
CRM is the main Pacemaker utility;
|
||||
use it to query, start/stop, or reset a resource
|
||||
and other maintenance tasks for the cluster.
|
||||
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
.. _devstack-term:
|
||||
|
||||
DevStack
|
||||
--------
|
||||
An OpenStack package that can be installed and deployed on your laptop
|
||||
or inside a VM on a cloud or other machine for evaluation purposes.
|
||||
DevStack runs in a virtual machine so does not give the same performance
|
||||
as OpenStack running on dedicated hardware
|
||||
and it only runs a single node.
|
||||
See the `DevStack web page <http://devstack.org/>`_
|
||||
for installation instructions.
|
||||
|
||||
Fuel is a more powerful tool that supports a virtualized deployment
|
||||
including multiple controllers and support for HA.
|
||||
Fuel can also be used to deploy a bare-metal cloud
|
||||
installed on bare metal and appropriate for a production environment.
|
||||
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
.. _fencing-term:
|
||||
|
||||
Fencing
|
||||
-------
|
||||
Process of locking resources away from a node whose status is uncertain.
|
||||
Ceph supports fencing but you must ensure
|
||||
that no controllers host both the Ceph OSD and Ceph Mon roles.
|
||||
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
.. _fuel-master-node-term:
|
||||
|
||||
Fuel Master Node
|
||||
----------------
|
||||
A server with the Mirantis Fuel application installed,
|
||||
also commonly referred to as the Fuel server.
|
||||
The Fuel Master node runs on its own server or VM
|
||||
to deploy and manage OpenStack environments.
|
||||
It assigns IP addresses to the OpenStack nodes,
|
||||
performs PXE boot and initial configuration,
|
||||
and provisions the nodes according to their roles in the environment.
|
||||
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
.. _galera-cluster-term:
|
||||
|
||||
Galera Cluster for MySQL
|
||||
------------------------
|
||||
Galera is a synchronous multi-master cluster
|
||||
for the MySQL database.
|
||||
Mirantis OpenStack uses MySQL/Galera for HA deployments;
|
||||
see the `FAQ <http://docs.mirantis.com/fuel/fuel-4.1/frequently-asked-questions.html#other-questions>`_
|
||||
for more information.
|
||||
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
.. _hadoop-term:
|
||||
|
||||
Hadoop (Apache Hadoop)
|
||||
----------------------
|
||||
The Apache Hadoop project develops software for processing "Big Data".
|
||||
See the `Apache Hadoop homepage <http://hadoop.apache.org/>`_.
|
||||
|
||||
The OpenStack Sahara project provides extensions to OpenStack
|
||||
that enable it to run Hadoop clusters.
|
||||
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
|
||||
.. _havana-term:
|
||||
|
||||
Havana
|
||||
------
|
||||
Code name for the eighth release of the OpenStack software.
|
||||
For more information, see the
|
||||
`Havana web site <http://www.openstack.org/software/havana/>`_.
|
||||
Mirantis OpenStack version 4.0 and Fuel 4.1 incorporate and support
|
||||
the Havana code base
|
||||
except for the following features:
|
||||
The following improvements in Havana are not supported directly by Fuel 4.x
|
||||
although they are included in Mirantis OpenStack 4.x:
|
||||
|
||||
* Nova Compute: Cells, Availability zones, Host aggregates
|
||||
|
||||
* Neutron: Load Balancer as a Service (LBaaS),
|
||||
|
||||
* Multiple L3 and DHCP agents per cloud
|
||||
|
||||
* Keystone: Multi-factor authentication, PKI authentication
|
||||
|
||||
* Swift: Regions, Adjustable replica count, Cross-project ACLs
|
||||
|
||||
* Cinder: Cinder-backup service, Support for Fibre Channel over Ethernet (FCoE)
|
||||
|
||||
* linux-iscsi.org (LIO) is now supported
|
||||
as an Internet Small Computer System Interface (iSCSI) backend
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
|
||||
.. _heat-term:
|
||||
|
||||
Heat
|
||||
----
|
||||
|
||||
Heat is the OpenStack Orchestration service.
|
||||
It implements a framework that manages the lifecycle
|
||||
of your infrastructure inside the OpenStack cloud.
|
||||
Mirantis OpenStack 4.0 and later
|
||||
deploys Heat into each environment by default.
|
||||
Heat uses templates to describe the deployment process of instances,
|
||||
but also supports the AWS CloudFormation template format.
|
||||
|
||||
Heat uses a template that can be maintained under source code control.
|
||||
See the `Heat wiki <https://wiki.openstack.org/wiki/Heat>`_
|
||||
for more information.
|
||||
|
||||
The Heat components are:
|
||||
|
||||
**heat-api** -- provides a native REST API and processes API requests.
|
||||
|
||||
**heat-api-cfn** -- similar to the *heat-api*
|
||||
but also provides an AWS CloudFormation compatible API.
|
||||
|
||||
**heat-engine** -- main component of the Heat framework.
|
||||
It does all the work of reading templates,
|
||||
launching instances and providing events to the API users.
|
||||
|
||||
See also:
|
||||
|
||||
* The official `documentation of the Heat project <https://wiki.openstack.org/wiki/Heat>`_
|
||||
* `Development documentation <http://docs.openstack.org/developer/heat/>`_
|
||||
* Mirantis `blog record <http://www.mirantis.com/blog/heat-things-up-with-openstack-before-your-competitors-do/>`_
|
||||
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
|
||||
.. _horizon-term:
|
||||
|
||||
Horizon
|
||||
-------
|
||||
|
||||
Horizon is the OpenStack dashboard application
|
||||
that provides a web-based GUI
|
||||
used to configure, monitor, and manage
|
||||
core OpenStack services
|
||||
such as Nova, Swift, and Keystone.
|
||||
|
||||
See http://docs.openstack.org/developer/horizon/
|
||||
for more information.
|
||||
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
.. _hypervisor-term:
|
||||
|
||||
Hypervisor
|
||||
----------
|
||||
A hypervisor creates and runs virtual machines.
|
||||
OpenStack runs a hypervisor as a component of the compute node.
|
||||
You can select the KVM or QEMU hypervisor from the Fuel UI;
|
||||
other hypervisors are available through
|
||||
`Mirantis Services <http://www.mirantis.com/openstack-services>`_.
|
||||
See the `HypervisorSupportMatrix <https://wiki.openstack.org/wiki/HypervisorSupportMatrix>`_
|
||||
web page for information about the status of other hypervisors for OpenStack.
|
||||
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
|
||||
.. _icehouse-term:
|
||||
|
||||
Icehouse
|
||||
--------
|
||||
Code name for the ninth release of the OpenStack software.
|
||||
For more information, see the
|
||||
`Icehouse web site <http://www.openstack.org/software/icehouse/>`_.
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
.. _identity-service-term:
|
||||
|
||||
Identity Service
|
||||
----------------
|
||||
|
||||
The OpenStack Identity service
|
||||
provides a central directory of users
|
||||
mapped to the OpenStack services they can access.
|
||||
It acts as a common authentication system across the cloud operating system
|
||||
and can integrate with existing backend directory services such as LDAP.
|
||||
It supports multiple forms of authentication
|
||||
including standard username and password credentials,
|
||||
token-based systems and AWS-style logins.
|
||||
|
||||
The catalog also provides a queryable list
|
||||
of all of the services deployed in an OpenStack cloud in a single registry.
|
||||
Users and third-party tools can programmatically determine
|
||||
which resources they can access.
|
||||
|
||||
As an administrator, OpenStack Identity enables you to:
|
||||
|
||||
* Configure centralized policies across users and systems.
|
||||
* Create users and tenants and define permissions
|
||||
for compute, storage and networking resources
|
||||
using role-based access control (RBAC) features.
|
||||
* Integrate with an existing directory such as LDAP,
|
||||
allowing for a single source of identity authentication
|
||||
across the enterprise
|
||||
|
||||
As a user, OpenStack Identity enables you to:
|
||||
|
||||
* Get a list of the services that you can access
|
||||
* Make API requests or log into the web dashboard
|
||||
to create resources owned by your account
|
||||
|
||||
Pacemaker uses an OpenStack Resource Agent to manage
|
||||
the Identity Service in OpenStack High Availability deployments.
|
||||
For information about the High Availability Identity service, see
|
||||
`Highly Available OpenStack Identity <http://docs.openstack.org/high-availability-guide/content/s-keystone.html>`.
|
||||
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
.. _image-service-term:
|
||||
|
||||
Image Service
|
||||
-------------
|
||||
|
||||
The OpenStack Image Service provides discovery,
|
||||
registration and delivery services for disk and server images.
|
||||
The ability to copy or snapshot a server image
|
||||
and immediately store it away
|
||||
is a powerful capability of the OpenStack cloud operating system.
|
||||
A stored image can be used as a template
|
||||
to get new servers up and running quickly and consistently;
|
||||
it can also be used to store and catalog an unlimited number of backups.
|
||||
|
||||
The Image Service can store disk and server images in a variety of back-ends,
|
||||
including OpenStack Object Storage.
|
||||
The Image Service API provides a standard REST interface
|
||||
for querying information about disk images
|
||||
and lets clients stream the images to new servers.
|
||||
|
||||
Capabilities of the Image Service include:
|
||||
|
||||
* Administrators can create base templates
|
||||
from which their users can start new compute instances
|
||||
* Users can choose from available images,
|
||||
or create their own images from existing servers
|
||||
* Snapshots can be stored in the Image Service
|
||||
so that virtual machines can be backed up quickly
|
||||
* A multi-format image registry,
|
||||
the image service allows uploads of private and public images
|
||||
in a variety of formats, including
|
||||
Raw, Machine (kernel/ramdisk outside of image, a.k.a. AMI),
|
||||
VHD (Hyper-V), VDI (VirtualBox), qcow2 (Qemu/KVM),
|
||||
VMDK (VMWare), and OVF (VMWare, others).
|
||||
|
||||
Pacemaker uses an OpenStack Resource Agent
|
||||
to manage the Image Service in OpenStack High Availability deployments.
|
||||
For information about the High Availability Image service, see
|
||||
`Highly Available OpenStack Image API <http://docs.openstack.org/high-availability-guide/content/s-glance-api.html>`_.
|
||||
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
.. _ironic-term:
|
||||
|
||||
Ironic
|
||||
------
|
||||
Ironic is an API to manage and provision physical machines;
|
||||
it is currently an incubated project that is forked from and will replace
|
||||
the Nova "baremetal" driver used in the Grizzly and Havana releases.
|
||||
See the `Ironic wiki page <https://wiki.openstack.org/wiki/Ironic>`_.
|
||||
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
.. _mirantis-openstack-term:
|
||||
|
||||
Mirantis OpenStack
|
||||
------------------
|
||||
Hardened OpenStack distribution plus additional services
|
||||
for high availability deployed by Fuel.
|
||||
Fuel deploys Mirantis OpenStack with an operating system
|
||||
based on either the Ubuntu or CentOS Linux distro.
|
||||
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
.. _mongodb-term:
|
||||
|
||||
MongoDB
|
||||
-------
|
||||
MongoDB is an open source NoSQL document database
|
||||
optimized to host very large tables on commodity hardware.
|
||||
See the `MongoDB web site <https://www.mongodb.org>`_.
|
||||
|
||||
Ceilometer interfaces with MongoDB in Mirantis OpenStack 5.0 and later
|
||||
(OpenStack Icehouse and later).
|
||||
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
.. _murano-term:
|
||||
|
||||
Murano
|
||||
------
|
||||
The Murano project provides an application catalog
|
||||
that application developers and cloud administrators can use
|
||||
to publish various cloud-ready applications
|
||||
in a browsable, categorized catalog.
|
||||
Users can then select the applications and services they need
|
||||
and install them in a "push-the-button" manner.
|
||||
See the `Murano wiki <https://wiki.openstack.org/wiki/Murano>`_.
|
||||
|
||||
Fuel can deploy all Murano components, including the Murano Dashboard.
|
||||
See :ref:`Murano-deployment-notes`
|
||||
for more information about deploying Murano with Fuel.
|
||||
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
|
||||
.. _mysql-term:
|
||||
|
||||
MySQL
|
||||
------
|
||||
The database most frequently used in OpenStack deployments.
|
||||
The MySQL database runs on the controller node;
|
||||
MySQL client software must be installed on other nodes
|
||||
that access the MySQL database.
|
||||
|
||||
For HA deployments,
|
||||
Mirantis OpenStack uses Pacemaker/Corosync
|
||||
to provide redundancy and failover capabilities
|
||||
for MySQL.
|
||||
Mirantis OpenStack uses MySQL/Galera for database replication
|
||||
in HA deployments that use the CentOS or Ubuntu kernel;
|
||||
see `Preparing MySQL for Pacemaker high availability <http://docs.openstack.org/trunk/openstack-ops/content/security_groups.html>`_.
|
||||
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
|
||||
.. _nailgun-term:
|
||||
|
||||
Nailgun
|
||||
-------
|
||||
|
||||
Nailgun is the configuration and management service
|
||||
used as the backend for the Fuel UI and CLI.
|
||||
It contains the logic for creating an environment and editing its settings;
|
||||
assigning roles to the discovered nodes;
|
||||
an starting the deployment process for a new OpenStack cluster.
|
||||
|
||||
Nailgun stores all of its data in a PostgreSQL database.
|
||||
that contains the hardware configuration of all managed nodes it discovers,
|
||||
plus the roles, environment settings,
|
||||
current deployment status and progress of running deployments.
|
||||
|
||||
Note that Nailgun in Fuel
|
||||
is not in any way related to the Nailgun that provides
|
||||
a JVM in which Java programs can be run without incurring
|
||||
the standard JVM startup overhead.
|
||||
|
||||
- For a detailed explanation of Nailgun's role in the Fuel architecture,
|
||||
see the `Fuel Architecture Overview <http://docs.mirantis.com/fuel-dev/develop/architecture.html>`_.
|
||||
- For details about developing and customizing Nailgun, see
|
||||
`Nailgun Development and Customization Instructions <http://docs.mirantis.com/fuel-dev/develop/nailgun.html>`_.
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
|
||||
.. _native-vlan-term:
|
||||
|
||||
Native VLAN
|
||||
-----------
|
||||
An untagged VLAN on a tagged port.
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
|
||||
.. _networking-term:
|
||||
|
||||
Networking
|
||||
----------
|
||||
|
||||
The nodes in the OpenStack environment
|
||||
communicate with each other over using one of the network topologies:
|
||||
|
||||
* With `neutron` networking, GRE tunnels or VLANs can be used for network
|
||||
segmentation.
|
||||
|
||||
* With `nova-network`, FlatDHCP and VLAN modes are available.
|
||||
|
||||
The following documents provide information:
|
||||
|
||||
* For a list of the types of networks used in OpenStack
|
||||
(Public, Storage, Administrative, and so forth), see
|
||||
`Network Configuration Options <http://docs.mirantis.com/fuel/fuel-4.1/pre-install-guide.html#network-configuration-options>`_
|
||||
|
||||
* For diagrams, detailed discussions, and instructions for deploying
|
||||
the different networking models, see
|
||||
`Network Deployment Models <http://docs.mirantis.com/fuel/fuel-4.1/pre-install-guide.html#network-deployment-models>`_,
|
||||
`Understanding and Configuring the Network <http://docs.mirantis.com/fuel/fuel-4.1/install-guide.html#understanding-and-configuring-the-network>`_, and
|
||||
`Fuel Deployment Schema <http://docs.mirantis.com/fuel/fuel-4.1/install-guide.html#fuel-deployment-schema>`_
|
||||
|
||||
* For information about calculating the hardware required for your deployment, see
|
||||
`Calculating Network <http://docs.mirantis.com/fuel/fuel-4.1/install-guide.html#calculating-network>`_.
|
||||
|
||||
* `Installing Fuel Master Node <http://docs.mirantis.com/fuel/fuel-4.1/install-guide.html#installing-fuel-master-node>`_
|
||||
includes instructions for changing network parameters
|
||||
during and after installation.
|
||||
|
||||
* `Advanced Network Configuration Using VSwitch <http://docs.mirantis.com/fuel/fuel-4.1/reference-architecture.html#advanced-network-configuration-using-open-vswitch>`_
|
||||
describes Open VSwitch and includes instructions for adjusting the network configuration
|
||||
by editing configuration files and using the command-line tools.
|
||||
|
||||
* `Network Architecture <http://docs.mirantis.com/fuel/fuel-4.1/reference-architecture.html#network-architecture>`_
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
|
||||
.. _neutron-term:
|
||||
|
||||
Neutron (formerly know as Quantum)
|
||||
------------------------------------
|
||||
|
||||
OpenStack Core project to provide networking as a service
|
||||
between interface devices such as vNICS
|
||||
that are managed by other OpenStack services such as Nova.
|
||||
See the `Neutron web page <https://wiki.openstack.org/wiki/Neutron>`_
|
||||
for more information.
|
||||
|
||||
Mirantis OpenStack includes Neutron;
|
||||
Fuel deploys per-tenant Routers with Private Networks.
|
||||
Each tenant has a virtual Neutron router with one or more private networks,
|
||||
each of which can communicate with the outside world.
|
||||
This allows full routing isolation for each tenant private network.
|
||||
|
||||
See `Neutron Deployment <http://docs.mirantis.com/fuel/fuel-4.1/pre-install-guide.html#neutron>`_
|
||||
for a description of the recommended network configuration parameters
|
||||
for using the Neutron service.
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
|
||||
.. _nic-term:
|
||||
|
||||
NIC (Network Interface Card)
|
||||
----------------------------
|
||||
The physical networking port and hardware used for networking.
|
||||
In a virtualized deployment,
|
||||
NIC can also refer to the software interfaces
|
||||
between virtual machines.
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
|
||||
.. _node-term:
|
||||
|
||||
Node
|
||||
-----------
|
||||
A server or VM that provides specific functionality
|
||||
within an OpenStack environment.
|
||||
For example, Fuel deploys Controller nodes, Compute nodes,
|
||||
and Storage nodes.
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
|
||||
.. _nova-network-term:
|
||||
|
||||
Nova Network
|
||||
------------
|
||||
|
||||
The Nova-network model was the original networking model for OpenStack.
|
||||
It supports two topologies -- the FlatDHCPManager and VLAN Manager --
|
||||
that can be used to deploy private networks for tenants;
|
||||
see `Nova-network Deployment Model <http://docs.mirantis.com/fuel/fuel-4.1/pre-install-guide.html#nova-network>`_
|
||||
for more information about using Nova-network in Mirantis OpenStack.
|
||||
|
||||
Nova network is scheduled for deprecation
|
||||
in favor of the :ref:`neutron-term` network model.
|
||||
See `Deprecation of Nova Network <http://docs.openstack.org/trunk/openstack-ops/content/nova-network-deprecation.html>`_ for more details.
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
|
||||
.. _nova-term:
|
||||
|
||||
Nova
|
||||
----
|
||||
OpenStack Core project used for compute nodes;
|
||||
all major Nova components can be run on multiple servers
|
||||
and use message queues for communication between components.
|
||||
See the `Nova web page <http://docs.openstack.org/developer/nova/>`_
|
||||
for more information.
|
||||
|
||||
The Baremetal driver used for provisioning in Nova
|
||||
has recently been forked into its own project; see "Ironic".
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
|
||||
.. _object-storage-term:
|
||||
|
||||
Object Storage
|
||||
--------------
|
||||
Provides a fully distributed, API-accessible storage platform
|
||||
that can be integrated directly into applications
|
||||
or used for backup, archiving, and data retention.
|
||||
This is not a traditional file system
|
||||
but rather a distributed storage system for static data
|
||||
such as virtual machine images, photo storage, email storage,
|
||||
backups, and archives.
|
||||
Objects and files are written to multiple disk drives
|
||||
spread across different servers in the data center;
|
||||
the OpenStack software ensures data replication and integrity
|
||||
across the cluster.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
|
||||
.. _openstack-term:
|
||||
|
||||
OpenStack
|
||||
---------
|
||||
Open source software that can be used
|
||||
to deliver a massively scalable cloud operating system
|
||||
for private and public clouds.
|
||||
For more information, see the
|
||||
`OpenStack web page <http://www.openstack.org/>`_ and
|
||||
`OpenStack documentation <http://docs.openstack.org/>`_.
|
||||
|
||||
The Mirantis OpenStack distribution packages
|
||||
a stable version of the open source pieces
|
||||
into an installable package that deploys an operating system
|
||||
based on either Ubuntu or CentOS.
|
||||
and adds Fuel to simplify the deployment and management tasks.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
|
||||
.. _orchestration-service-term:
|
||||
|
||||
Orchestration Service
|
||||
---------------------
|
||||
|
||||
OpenStack Orchestration is a template-driven engine
|
||||
that allows application developers
|
||||
to describe and automate the deployment of infrastructure.
|
||||
The flexible template language can specify
|
||||
compute, storage and networking configurations
|
||||
as well as detailed post-deployment activity
|
||||
to automate the full provisioning of infrastructure
|
||||
as well as services and applications.
|
||||
Through integration with the Telemetry service,
|
||||
the Orchestration engine can also perform
|
||||
auto-scaling of certain infrastructure elements.
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
|
||||
.. _ovs-term:
|
||||
|
||||
OVS (Open vSwitch)
|
||||
------------------
|
||||
Multilayer virtual switch that the Neutron networking model uses
|
||||
to create a felxible network setup and to isolate tenants from each other on L2 and L3 layers.
|
||||
You can do some basic configuration of OVS on the Fuel UI beginning with Fuel 4.1;
|
||||
additional customization can be done
|
||||
by editing configuration files and using the command-line tools; see
|
||||
`Advanced Network Configuration Using VSwitch <http://docs.mirantis.com/fuel/fuel-4.1/reference-architecture.html#advanced-network-configuration-using-open-vswitch>`_.
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
|
||||
.. _pacemaker-term:
|
||||
|
||||
Pacemaker
|
||||
---------
|
||||
Master control process for OpenStack High Availability deployments.
|
||||
Pacemaker is part of the Corosync services and is not specific to OpenStack.
|
||||
|
||||
See:
|
||||
|
||||
* `What is Pacemaker? <http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html-single/Clusters_from_Scratch/#_what_is_pacemaker>`_
|
||||
for a good discussion about Pacemaker and Corosync and how they are related.
|
||||
* `The Pacemaker Cluster Stack <http://docs.openstack.org/high-availability-guide/content/ch-pacemaker.html>`_
|
||||
discusses how Pacemaker is used with OpenStack.
|
||||
* `Pacemaker web page <http://clusterlabs.org/doc/>`_
|
||||
contains more in-depth information about Pacemaker.
|
||||
|
||||
Fuel uses Pacemaker to implement its Multi-Node-HA deployment.
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
|
||||
.. _puppet-term:
|
||||
|
||||
Puppet
|
||||
------
|
||||
Puppet modules bring scalable and reliable IT automation
|
||||
to OpenStack cloud deployments.
|
||||
See the `Puppet web page <http://puppetlabs.com/solutions/cloud-automation/compute/openstack>`_ for more details.
|
||||
|
||||
Fuel uses Puppet as the configuration management system
|
||||
that compiles a set of instructions
|
||||
for a configurable, reproducible, and sharable installation process.
|
||||
In Fuel 4.1 and later, the Puppet modules and manifests are synchronized
|
||||
between the master nodes and the managed nodes, then applied locally.
|
||||
This solves the security signing, scalability, and performance issues
|
||||
encountered on earlier releases
|
||||
where the Puppet Master Node ran on the Fuel Node Master.
|
||||
|
||||
Passing custom attributes can be helpful
|
||||
when you have some Puppet manifests that should be run
|
||||
but are not supported by Fuel itself. See
|
||||
:ref:`pass-attributes-from-fuel-to-puppet`.
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
|
||||
.. _pxe-term:
|
||||
|
||||
PXE (Preboot eXecution Environment)
|
||||
-----------------------------------
|
||||
An environment to boot a computer using a network interface
|
||||
independent of storage devices.
|
||||
Fuel uses PXE to boot all nodes in the OpenStack environment.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
|
||||
.. _qemu-term:
|
||||
|
||||
QEMU
|
||||
----
|
||||
One of the hypervisors that can be selected from the Fuel UI.
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
|
||||
.. _quotas:
|
||||
|
||||
quotas
|
||||
------
|
||||
OpenStack uses quotas to limit the resources one tenant consumes
|
||||
and thus prevent system capacities from being exhausted without notification.
|
||||
Fuel has a deployment setting to enable/disable quotas;
|
||||
they are disabled by default.
|
||||
|
||||
You can set quotas from Horizon;
|
||||
use the "Edit Quotas" form in the tenant panel.
|
||||
You can also use the **nova quota-update** command;
|
||||
For more information about how quotas work
|
||||
and how to use the */nova quota-upate** command, see
|
||||
`Manage quotas <http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html>`_.
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
|
||||
.. _rally-term:
|
||||
|
||||
Rally
|
||||
-----
|
||||
|
||||
Rally is the OpenStack benchmarking suite.
|
||||
You can run Rally against an established OpenStack environment
|
||||
to identify functional failures and performance bottlenecks.
|
||||
See https://wiki.openstack.org/wiki/Rally.
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
|
||||
.. _resource-agents-term:
|
||||
|
||||
Resource Agents (RAs)
|
||||
---------------------
|
||||
Resource Agents are used by Pacemaker to interract with applications.
|
||||
Pacemaker includes native that are used
|
||||
in OpenStack high-availability deployments
|
||||
such as those that manage the MySQL databases or virtual IP addresses.
|
||||
Pacemaker also supports third party RAs
|
||||
(such as one that manages RabbitMQ)
|
||||
and native OpenStack RAs
|
||||
(such as those that manage the OpenStack Identity and Image Services.
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
|
||||
.. _sahara-term:
|
||||
|
||||
Sahara (formerly known as "Savanna")
|
||||
------------------------------------
|
||||
Sahara is the OpenStack service
|
||||
that provisions a Hadoop cluster on top of OpenStack.
|
||||
Sahara currently supports vanilla hadoop
|
||||
and the Hortonworks Data Platform (HDP).
|
||||
|
||||
See the `Sahara wiki page <https://wiki.openstack.org/wiki/Sahara>`_
|
||||
for more information about Sahara,
|
||||
including a link to its documentation.
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
|
||||
.. _security-groups-term:
|
||||
|
||||
Security groups
|
||||
---------------
|
||||
Sets of IP filter rules that are applied to an instance's networking.
|
||||
Most projects provide a "default" security group
|
||||
that is applied to instances that have no security group defined.
|
||||
See the `Security groups web page <http://docs.openstack.org/trunk/openstack-ops/content/security_groups.html>`_
|
||||
for more information.
|
||||
|
||||
Avoid creating a secure group that refers to itself as a source.
|
||||
Such a configuration generates N^2 rules in *iptables*
|
||||
(where N is the number of FMs).
|
||||
This significantly impacts networking performance in large deployments.
|
||||
|
||||
Note that Sahara does does not provide a default security group.
|
||||
See this `note <https://review.openstack.org/#/c/71299/>`_
|
||||
for information about defining a default security group for Sahara).
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
|
||||
.. _stateless-and-stateful-services-term:
|
||||
|
||||
Stateless and Stateful services
|
||||
-------------------------------
|
||||
|
||||
A stateless service provides a response to your request
|
||||
and then requires no further attention.
|
||||
To make a stateless service highly available,
|
||||
you need redundant instances that are load balanced.
|
||||
OpenStack services that are stateless include
|
||||
nova-api, nova-conductor, glance-api, keystone-api,
|
||||
neutron-api and nova-scheduler.
|
||||
|
||||
A stateful service is one where subsequent requests to the service
|
||||
depend on the results of each previous request.
|
||||
Stateful services are more difficult to manage
|
||||
because a single action typically involves multiple requests,
|
||||
so simply providing addiitonal instances and load balancing
|
||||
does not solve the problem.
|
||||
For example, if the Horizon user interface reset itself
|
||||
every time you went to a new page,
|
||||
it would not be very useful.
|
||||
OpenStack services that are stateful
|
||||
include the OpenStack database and message queue.
|
||||
Implementing high availability for a stateful service
|
||||
depends on whether you choose
|
||||
an active/passive or active/active configuration.
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
|
||||
.. _storage-nodes-and-roles-term:
|
||||
|
||||
Storage nodes and roles
|
||||
-----------------------
|
||||
|
||||
OpenStack requires block and object storage to be provisioned.
|
||||
Fuel provides the following storage options:
|
||||
|
||||
* Cinder LVM provides persistent block storage
|
||||
to virtual machines over the iSCSI protocol
|
||||
|
||||
* Swift object stores can be used by Glance
|
||||
to store VM images and snapshots.
|
||||
It may also be used directly by applications.
|
||||
|
||||
* Ceph combines object and block storage
|
||||
and can replace either one or both of the above.
|
||||
|
||||
You can configure your environment to use
|
||||
either dedicated Storage Nodes
|
||||
or to run the Storage Role on the Compute Nodes.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
|
||||
.. _stp-term:
|
||||
|
||||
STP
|
||||
---
|
||||
Spanning Tree Protocol
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
|
||||
.. _swift-object-storage-term:
|
||||
|
||||
Swift Object Storage
|
||||
--------------------
|
||||
|
||||
Swift Object Storage provides
|
||||
a multi-tenant, highly scalable and durable object storage system
|
||||
that can store large amounts of unstructured data at low cost.
|
||||
Some key characteristics of Swift object storage are:
|
||||
|
||||
* Each object stored in Swift has its own URL
|
||||
and its own metadata
|
||||
* Each object is replicated times in the cluster to provide redundancy;
|
||||
the number of replicas is set by the administrator.
|
||||
Each replica is located in as unique a location as possible.
|
||||
* Libraries are provided for many programming languages;
|
||||
developers can use these libraries to access the data in Swift object stores
|
||||
or they can write directly to the RESTful API
|
||||
* New nodes can be added to the cluster
|
||||
and failed nodes can be replaced without downtime.
|
||||
|
||||
Fuel can deploy Swift on either a dedicated server storage node
|
||||
or as a role on a compute node.
|
||||
|
||||
See `Introducing OpenStack Swift' <https://swiftstack.com/openstack-swift/architecture/>`_
|
||||
for a good general introduction to Swift.
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
|
||||
.. _tagged-port-term:
|
||||
|
||||
Tagged port
|
||||
-----------
|
||||
A tagged port (Cisco Trunk Port)
|
||||
is an 802.1q frame from a switch to a server network card
|
||||
used for VLAN networks;
|
||||
untagged ports are used as access ports.
|
||||
Tagged ports are required for the Nova-network VLAN Manager
|
||||
or Neutron with VLAN segmentation.
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
|
||||
.. _telemetry-services-term:
|
||||
|
||||
Telemetry Services
|
||||
------------------
|
||||
|
||||
See :ref:`ceilometer-term`.
|
||||
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
|
||||
.. _tenant-term:
|
||||
|
||||
Tenant
|
||||
------
|
||||
|
||||
OpenStack Compute defines a tenant as a group of users.
|
||||
|
||||
- In the Dashboard,
|
||||
tenants are represented as projects.
|
||||
- One tenant can contain zero or more users.
|
||||
- One user can be associated with one or more tenants.
|
||||
- A role can be assigned to each tenant and user pairing.
|
||||
|
||||
See the `OpenStack Compute <http://www.openstack.org/software/openstack-compute/>`_
|
||||
web page for more information.
|
||||
|
||||
Use the `keystone <http://docs.openstack.org/developer/python-keystoneclient/man/keystone.html>`_ command line utility
|
||||
to query and manage a tenant project.
|
||||
The most common commands are:
|
||||
|
||||
**keystone tenant-list**
|
||||
List all tenants on the system, showing ID, name,
|
||||
and whether they are enabled or disabled.
|
||||
|
||||
To list all projects with their ID, name, and whether they are enabled or disabled:
|
||||
|
||||
|
||||
Create a project named new-project:
|
||||
|
||||
$ keystone tenant-create --name new-project --description 'my new project'
|
||||
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
|
||||
.. _vlan-term:
|
||||
|
||||
VLAN (Virtual Local Area Network)
|
||||
---------------------------------
|
||||
|
||||
A VLAN is a set of ports that form a logical Ethernet segment
|
||||
on an Ethernet switch.
|
||||
The ports of a VLAN form an independent traffic domain
|
||||
in which the traffic generated by the nodes
|
||||
remains within the VLAN.
|
||||
This allows you to use the switch management software
|
||||
to group nodes with related functions
|
||||
into their own separate, logical LAN segments.
|
||||
Fuel supports the Neutron with VLAN segmentation
|
||||
and Nova-network VLAN Manager topologies:
|
||||
|
|
@ -4,6 +4,8 @@
|
|||
|
||||
.. index:: Ceilometer
|
||||
|
||||
.. _ceilometer-deployment-notes:
|
||||
|
||||
Ceilometer deployment notes
|
||||
===========================
|
||||
|
||||
|
|
|
|||
|
|
@ -4,6 +4,8 @@
|
|||
|
||||
.. index:: Passing Custom Attributes From Fuel To Puppet
|
||||
|
||||
.. _pass-attributes-from-fuel-to-puppet:
|
||||
|
||||
Passing Custom Attributes From Fuel To Puppet
|
||||
=============================================
|
||||
|
||||
|
|
|
|||
|
|
@ -23,5 +23,6 @@ pdf_documents = [
|
|||
('pdf/pdf_operations', u'Mirantis-OpenStack-4.1-OperationsGuide', u'Operations Guide', u'2014, Mirantis Inc.'),
|
||||
('pdf/pdf_reference', u'Mirantis-OpenStack-4.1-ReferenceArchitecture', u'Reference Architecture', u'2014, Mirantis Inc.'),
|
||||
('pdf/pdf_preinstall', u'Mirantis-OpenStack-4.1-Pre-InstallationGuide', u'Pre-Installation Guide', u'2014, Mirantis Inc.'),
|
||||
('pdf/pdf_terminology', u'Mirantis-OpenStack-4.1-Terminology-Reference', u'Terminology Reference', u'2014, Mirantis Inc.'),
|
||||
# (master_doc, project, project, copyright),
|
||||
]
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
+-------------------------------------+-----------------------------------+
|
||||
| Mirantis OpenStack v4.1 | .. cssclass:: right|
|
||||
| | |
|
||||
| OpenStack Patching Quick Reference | ###Section### |
|
||||
| Terminology Reference | ###Section### |
|
||||
+-------------------------------------+-----------------------------------+
|
||||
|
||||
.. footer::
|
||||
|
|
@ -22,8 +22,4 @@
|
|||
|
||||
PageBreak oneColumn
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
.. include:: /pages/preface/preface.rst
|
||||
.. include:: /contents/contents-openstack-patch-quick-ref.rst
|
||||
.. include:: /contents/contents-terminology.rst
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
.. _terminology:
|
||||
|
||||
=====================
|
||||
Terminology Reference
|
||||
=====================
|
||||
|
||||
.. contents:: :local:
|
||||
:depth: 2
|
||||
|
||||
.. include:: /contents/contents-terminology.rst
|
||||
Loading…
Reference in New Issue