merged with tyler
This commit is contained in:
Pavel Lechenko
parent
9208860904
commit
1f67bf11d0
|
|
@ -0,0 +1,12 @@
|
|||
<a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/deed.en_US">
|
||||
<img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by-sa/3.0/88x31.png" />
|
||||
</a><br />
|
||||
<span xmlns:dct="http://purl.org/dc/terms/" property="dct:title">
|
||||
Mirantis Fuel for OpenStack Documentation</span> by
|
||||
<a xmlns:cc="http://creativecommons.org/ns#" href="http://docs.mirantis.com" property="cc:attributionName" rel="cc:attributionURL">
|
||||
Mirantis Inc.</a> is licensed under a
|
||||
<a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/deed.en_US">
|
||||
Creative Commons Attribution-ShareAlike 3.0 Unported License</a>.<br />
|
||||
Based on a work at
|
||||
<a xmlns:dct="http://purl.org/dc/terms/" href="https://github.com/Mirantis/fuel-docs"
|
||||
rel="dct:source">https://github.com/Mirantis/fuel-docs</a>
|
||||
10
conf.py
10
conf.py
|
|
@ -46,11 +46,11 @@ source_suffix = '.rst'
|
|||
#source_encoding = 'utf-8-sig'
|
||||
|
||||
# The master toctree document.
|
||||
master_doc = 'index'
|
||||
master_doc = 'contents'
|
||||
|
||||
# General information about the project.
|
||||
project = u'Fuel for OpenStack'
|
||||
copyright = u'2013, Mirantis'
|
||||
copyright = u'2013, Mirantis Inc.'
|
||||
|
||||
# The version info for the project you're documenting, acts as replacement for
|
||||
# |version| and |release|, also used in various other places throughout the
|
||||
|
|
@ -144,7 +144,7 @@ html_use_smartypants = True
|
|||
|
||||
# Custom sidebar templates, maps document names to template names.
|
||||
html_sidebars = {
|
||||
'**': ['globaltoc.html', 'sourcelink.html', 'searchbox.html'],
|
||||
'**': ['globaltoc.html', 'searchbox.html', 'doc_license.html'],
|
||||
}
|
||||
|
||||
# Additional templates that should be rendered to pages, maps page names to
|
||||
|
|
@ -198,7 +198,7 @@ latex_elements = {
|
|||
# (source start file, target name, title, author, documentclass [howto/manual]).
|
||||
latex_documents = [
|
||||
('index', 'fuel.tex', u'Fuel for OpenStack Documentation',
|
||||
u'Mirantis', 'manual'),
|
||||
u'Mirantis Inc.', 'manual'),
|
||||
]
|
||||
|
||||
# The name of an image file (relative to this directory) to place at the top of
|
||||
|
|
@ -242,7 +242,7 @@ man_pages = [
|
|||
# dir menu entry, description, category)
|
||||
texinfo_documents = [
|
||||
('index', 'fuel', u'Fuel for OpenStack Documentation',
|
||||
u'Mirantis', 'fuel', 'One line description of project.',
|
||||
u'Mirantis Inc.', 'fuel', 'One line description of project.',
|
||||
'Miscellaneous'),
|
||||
]
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,16 @@
|
|||
Table of Contents
|
||||
=================
|
||||
|
||||
.. toctree:: Table of Contents
|
||||
:maxdepth: 2
|
||||
|
||||
index
|
||||
pages/0010-package-contents
|
||||
pages/0020-about-fuel
|
||||
pages/0030-release-notes
|
||||
pages/0040-reference-architecture
|
||||
pages/0045-installation-fuel-web
|
||||
pages/0050-installation-instructions
|
||||
pages/0055-production-considerations
|
||||
pages/0060-frequently-asked-questions
|
||||
copyright
|
||||
|
|
@ -1,7 +1,6 @@
|
|||
.. index:: license
|
||||
|
||||
===================
|
||||
Copyright & License
|
||||
===================
|
||||
Fuel License
|
||||
============
|
||||
|
||||
.. literalinclude:: LICENSE
|
||||
|
|
|
|||
86
index.rst
86
index.rst
|
|
@ -1,17 +1,75 @@
|
|||
==============================
|
||||
Fuel™ for OpenStack: User Guide
|
||||
==============================
|
||||
Introduction to Fuel for OpenStack
|
||||
==================================
|
||||
|
||||
Table of contents
|
||||
=================
|
||||
OpenStack is an extensible, versatile, and flexible cloud management platform.
|
||||
By exposing its portfolio of cloud infrastructure services – compute, storage,
|
||||
networking and other core resources — through ReST APIs, OpenStack enables a
|
||||
wide range of control over these services, both from the perspective of an
|
||||
integrated Infrastructure as a Service (IaaS) controlled by applications, as
|
||||
well as automated manipulation of the infrastructure itself.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
This architectural flexibility doesn’t set itself up magically. It asks you, the
|
||||
user and cloud administrator, to organize and manage an extensive array of
|
||||
configuration options. Consequently, getting the most out of your OpenStack
|
||||
cloud over time – in terms of flexibility, scalability, and manageability –
|
||||
requires a thoughtful combination of complex configuration choices. This can be
|
||||
very time consuming and requires a significant amount of studious documentation
|
||||
to comprehend.
|
||||
|
||||
pages/0010-package-contents
|
||||
pages/0020-introduction
|
||||
pages/0040-reference-architecture
|
||||
pages/0045-installation-fuel-web
|
||||
pages/0050-installation-instructions
|
||||
pages/0055-production-considerations
|
||||
pages/0060-frequently-asked-questions
|
||||
Mirantis Fuel for OpenStack was created to eliminate exactly these problems.
|
||||
This step-by-step guide takes you through this process of:
|
||||
|
||||
* Configuring OpenStack and its supporting components into a robust cloud
|
||||
architecture
|
||||
* Deploying that architecture through an effective, well-integrated automation
|
||||
package that sets up and maintains the components and their configurations
|
||||
* Providing access to a well-integrated, up-to-date set of components known to
|
||||
work together
|
||||
|
||||
Fuel™ for OpenStack can be used to create virtually any OpenStack configuration.
|
||||
To make things easier, the installation includes several pre-defined
|
||||
architectures. For the sake of simplicity, this guide emphasises a single,
|
||||
common reference architecture; the multi-node, high-availability configuration.
|
||||
We begin with an explanation of this architecture, then move on to the details
|
||||
of creating the configuration in a test environment using VirtualBox. Finally,
|
||||
we give you the information you need to know to create this and other OpenStack
|
||||
architectures in a production environment.
|
||||
|
||||
This guide assumes that you are familiar with general Linux commands and
|
||||
administration concepts, as well as general networking concepts. You should have
|
||||
some familiarity with grid or virtualization systems such as Amazon Web Services
|
||||
or VMware, as well as OpenStack itself, but you don't need to be an expert.
|
||||
|
||||
The Fuel User Guide is organized as follows:
|
||||
|
||||
* :ref:`About Fuel <About_Fuel>`, gives you an
|
||||
overview of Fuel and gives you a general idea of how it works.
|
||||
|
||||
* :ref:`Reference Architecture <Reference-Architecture>`, provides a
|
||||
general look at the components that make up OpenStack.
|
||||
|
||||
* :ref:`Create a multi-node OpenStack cluster using Fuel Web <Fuel-Web-Cluster>`,
|
||||
takes you step-by-step through the process of creating a high-availability
|
||||
OpenStack cluster using Fuel Web.
|
||||
|
||||
* :ref:`Create a multi-node OpenStack cluster using Fuel <Create-Cluster>`,
|
||||
takes you step-by-step through the more advanced process of creating a
|
||||
high-availability OpenStack cluster using the standard Fuel tools.
|
||||
|
||||
* :ref:`Production Considerations <Production>`, looks at the
|
||||
real-world questions and problems involved in creating an OpenStack cluster
|
||||
for production use. We discuss issues such as network layout and hardware
|
||||
requirements, and provide tips and tricks for creating a cluster of up to 100
|
||||
nodes.
|
||||
|
||||
* With the current (3.1) release Fuel and FuelWeb has been integrated. We encourage all
|
||||
users to use the Fuel Web process for installation and configuration. However,
|
||||
the standard Fuel installation process is still available for those of you who
|
||||
prefer a more detailed approach to deployment. Even with a utility as powerful
|
||||
as Fuel, creating an OpenStack cluster can be complex, and
|
||||
:ref:`Frequently Asked Questions <FAQ>`, covers many of the issues that tend
|
||||
to arise during the process.
|
||||
|
||||
Lets start off by taking a look at Fuel itself. We'll start by explaining what
|
||||
it is and :ref:`how Fuel works <How-Fuel-Works>` , and then move to the process
|
||||
of installation itself.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,53 @@
|
|||
Introduction to Fuel for OpenStack
|
||||
==================================
|
||||
|
||||
.. This guide explains how to use Fuel to easily create and maintain an OpenStack
|
||||
cloud infrastructure.
|
||||
|
||||
Fuel™ for OpenStack can be used to create virtually any OpenStack configuration.
|
||||
To make things easier, the installation includes several pre-defined
|
||||
architectures. For the sake of simplicity, this guide emphasises a single,
|
||||
common reference architecture; the multi-node, high-availability configuration.
|
||||
We begin with an explanation of this architecture, then move on to the details
|
||||
of creating the configuration in a test environment using VirtualBox. Finally,
|
||||
we give you the information you need to know to create this and other OpenStack
|
||||
architectures in a production environment.
|
||||
|
||||
This guide assumes that you are familiar with general Linux commands and
|
||||
administration concepts, as well as general networking concepts. You should have
|
||||
some familiarity with grid or virtualization systems such as Amazon Web Services
|
||||
or VMware, as well as OpenStack itself, but you don't need to be an expert.
|
||||
|
||||
The Fuel User Guide is organized as follows:
|
||||
|
||||
* :ref:`About Fuel <About_Fuel>`, gives you an
|
||||
overview of Fuel and gives you a general idea of how it works.
|
||||
|
||||
* :ref:`Reference Architecture <Reference-Architecture>`, provides a
|
||||
general look at the components that make up OpenStack.
|
||||
|
||||
* :ref:`Create a multi-node OpenStack cluster using Fuel Web <Fuel-Web-Cluster>`,
|
||||
takes you step-by-step through the process of creating a high-availability
|
||||
OpenStack cluster using Fuel Web.
|
||||
|
||||
* :ref:`Create a multi-node OpenStack cluster using Fuel <Create-Cluster>`,
|
||||
takes you step-by-step through the more advanced process of creating a
|
||||
high-availability OpenStack cluster using the standard Fuel tools.
|
||||
|
||||
* :ref:`Production Considerations <Production>`, looks at the
|
||||
real-world questions and problems involved in creating an OpenStack cluster
|
||||
for production use. We discuss issues such as network layout and hardware
|
||||
requirements, and provide tips and tricks for creating a cluster of up to 100
|
||||
nodes.
|
||||
|
||||
* With the current (3.1) release Fuel and FuelWeb has been integrated. We encourage all
|
||||
users to use the Fuel Web process for installation and configuration. However,
|
||||
the standard Fuel installation process is still available for those of you who
|
||||
prefer a more detailed approach to deployment. Even with a utility as powerful
|
||||
as Fuel, creating an OpenStack cluster can be complex, and
|
||||
:ref:`Frequently Asked Questions <FAQ>`, covers many of the issues that tend
|
||||
to arise during the process.
|
||||
|
||||
Lets start off by taking a look at Fuel itself. We'll start by explaining what
|
||||
it is and :ref:`how Fuel works <How-Fuel-Works>` , and then move to the process
|
||||
of installation itself.
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
OpenStack is an extensible, versatile, and flexible cloud management platform. By exposing its portfolio of cloud infrastructure services – compute, storage, networking and other core resources — through ReST APIs, OpenStack enables a wide range of control over these services, both from the perspective of an integrated Infrastructure as a Service (IaaS) controlled by applications, as well as automated manipulation of the infrastructure itself.
|
||||
|
||||
This architectural flexibility doesn’t set itself up magically. It asks you, the user and cloud administrator, to organize and manage an extensive array of configuration options. Consequently, getting the most out of your OpenStack cloud over time – in terms of flexibility, scalability, and manageability – requires a thoughtful combination of complex configuration choices. This can be very time consuming and requires a significant amount of studious documentation to comprehend.
|
||||
|
||||
Mirantis Fuel for OpenStack was created to eliminate exactly these problems. This step-by-step guide takes you through this process of:
|
||||
|
||||
* Configuring OpenStack and its supporting components into a robust cloud architecture
|
||||
* Deploying that architecture through an effective, well-integrated automation package that sets up and maintains the components and their configurations
|
||||
* Providing access to a well-integrated, up-to-date set of components known to work together
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
Preface
|
||||
=======
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
.. include:: /pages/package-contents/0010-package-contents.rst
|
||||
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
Preface
|
||||
=======
|
||||
|
||||
OpenStack is an extensible, versatile, and flexible cloud management platform.
|
||||
By exposing its portfolio of cloud infrastructure services – compute, storage,
|
||||
networking and other core resources — through ReST APIs, OpenStack enables a
|
||||
wide range of control over these services, both from the perspective of an
|
||||
integrated Infrastructure as a Service (IaaS) controlled by applications, as
|
||||
well as automated manipulation of the infrastructure itself.
|
||||
|
||||
This architectural flexibility doesn’t set itself up magically. It asks you, the
|
||||
user and cloud administrator, to organize and manage an extensive array of
|
||||
configuration options. Consequently, getting the most out of your OpenStack
|
||||
cloud over time – in terms of flexibility, scalability, and manageability –
|
||||
requires a thoughtful combination of complex configuration choices. This can be
|
||||
very time consuming and requires a significant amount of studious documentation
|
||||
to comprehend.
|
||||
|
||||
Mirantis Fuel for OpenStack was created to eliminate exactly these problems.
|
||||
This step-by-step guide takes you through this process of:
|
||||
|
||||
* Configuring OpenStack and its supporting components into a robust cloud
|
||||
architecture
|
||||
* Deploying that architecture through an effective, well-integrated automation
|
||||
package that sets up and maintains the components and their configurations
|
||||
* Providing access to a well-integrated, up-to-date set of components known to
|
||||
work together
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
.. _About_Fuel:
|
||||
|
||||
About Fuel
|
||||
============
|
||||
|
||||
.. _contents:: :local:
|
||||
|
||||
.. _include:: /pages/about-fuel/0010-introduction.rst
|
||||
.. include:: /pages/about-fuel/0020-what-is-fuel.rst
|
||||
.. include:: /pages/about-fuel/0030-how-it-works.rst
|
||||
.. include:: /pages/about-fuel/0040-reference-topologies.rst
|
||||
.. include:: /pages/about-fuel/0050-supported-software.rst
|
||||
.. include:: /pages/about-fuel/0060-download-fuel.rst
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
.. _Introduction:
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
.. include:: /pages/introduction/0010-introduction.rst
|
||||
.. include:: /pages/introduction/0020-what-is-fuel.rst
|
||||
.. include:: /pages/introduction/0030-how-it-works.rst
|
||||
.. include:: /pages/introduction/0040-reference-topologies.rst
|
||||
.. include:: /pages/introduction/0050-supported-software.rst
|
||||
.. include:: /pages/introduction/0060-download-fuel.rst
|
||||
.. include:: /pages/introduction/0070-release-notes.rst
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
Release Notes
|
||||
-------------
|
||||
|
||||
.. include:: /pages/release-notes/v3-1-grizzly.rst
|
||||
.. include:: /pages/release-notes/v3-0-grizzly.rst
|
||||
.. include:: /pages/release-notes/v2-1-folsom.rst
|
||||
.. include:: /pages/release-notes/v2-0-folsom.rst
|
||||
.. include:: /pages/release-notes/v1-0-essex.rst
|
||||
|
||||
|
|
@ -1,10 +1,8 @@
|
|||
.. _Reference-Archiecture:
|
||||
.. _Reference-Architecture:
|
||||
|
||||
Reference Architecture
|
||||
======================
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
.. include:: /pages/reference-architecture/0010-overview.rst
|
||||
.. include:: /pages/reference-architecture/0015-closer-look.rst
|
||||
.. include:: /pages/reference-architecture/0020-logical-setup.rst
|
||||
|
|
|
|||
|
|
@ -1,11 +1,8 @@
|
|||
.. _Create-Fuel-Web:
|
||||
.. _Fuel-Web-Cluster:
|
||||
|
||||
====================================================
|
||||
Create a multi-node OpenStack cluster using FuelWeb
|
||||
====================================================
|
||||
|
||||
.. _contents:: :local:
|
||||
|
||||
.. include:: /pages/installation-fuel-web/install.rst
|
||||
.. include:: /pages/installation-fuel-web/networks.rst
|
||||
.. include:: /pages/installation-fuel-web/network-issues.rst
|
||||
|
|
|
|||
|
|
@ -3,13 +3,13 @@
|
|||
Create a multi-node OpenStack cluster using Fuel
|
||||
================================================
|
||||
|
||||
.. contents:: :local:
|
||||
.. _contents:: :local:
|
||||
|
||||
.. include:: /pages/installation-instructions/0000-preamble.rst
|
||||
.. include:: /pages/installation-instructions/0010-introduction.rst
|
||||
.. include:: /pages/installation-instructions/0015-before-you-start.rst
|
||||
.. include:: /pages/installation-instructions/0020-machines.rst
|
||||
.. include:: /pages/installation-instructions/0057-prepare-for-deployment.rst
|
||||
.. _include:: /pages/installation-instructions/0000-preamble.rst
|
||||
.. _include:: /pages/installation-instructions/0010-introduction.rst
|
||||
.. _include:: /pages/installation-instructions/0015-before-you-start.rst
|
||||
.. _include:: /pages/installation-instructions/0020-machines.rst
|
||||
.. _include:: /pages/installation-instructions/0057-prepare-for-deployment.rst
|
||||
.. include:: /pages/installation-instructions/0060-understand-the-manifest.rst
|
||||
.. include:: /pages/installation-instructions/0070-orchestration.rst
|
||||
.. include:: /pages/installation-instructions/0080-testing-openstack.rst
|
||||
|
|
|
|||
|
|
@ -3,8 +3,6 @@
|
|||
Production Considerations
|
||||
=========================
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
.. include:: /pages/production-considerations/0010-introduction.rst
|
||||
.. include:: /pages/production-considerations/0015-sizing-hardware.rst
|
||||
.. include:: /pages/production-considerations/0020-deployment-pipeline.rst
|
||||
|
|
|
|||
|
|
@ -3,13 +3,12 @@
|
|||
FAQ (Frequently Asked Questions)
|
||||
================================
|
||||
|
||||
.. contents:: :local:
|
||||
.. _contents:: :local:
|
||||
|
||||
Known Issues and Workarounds
|
||||
----------------------------
|
||||
.. Known Issues and Workarounds
|
||||
|
||||
.. include:: /pages/frequently-asked-questions/0070-common-technical-issues.rst
|
||||
.. include:: /pages/frequently-asked-questions/0010-rabbitmq.rst
|
||||
.. include:: /pages/frequently-asked-questions/0020-galera.rst
|
||||
.. include:: /pages/frequently-asked-questions/0070-common-technical-issues.rst
|
||||
.. include:: /pages/frequently-asked-questions/0080-other-questions.rst
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,11 @@
|
|||
.. _Create-PM:
|
||||
|
||||
Appendix A: Creating Fuel-pm from scratch
|
||||
==========================================
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
.. include:: /pages/creating-fuel-pm/0010-creating-fuel-pm-from-scratch.rst
|
||||
.. include:: /pages/creating-fuel-pm/0045-configuring-fuel-pm.rst
|
||||
.. include:: /pages/creating-fuel-pm/0050-installing-configuring-cobbler.rst
|
||||
.. include:: /pages/creating-fuel-pm/0060-register-with-fuel.rst
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
What is Fuel?
|
||||
-----------------
|
||||
|
||||
Fuel is a ready-to-install collection of the packages and scripts you need to
|
||||
create a robust, configurable, vendor-independant OpenStack cloud in your own
|
||||
environment.
|
||||
|
||||
A single OpenStack cloud consists of packages from many different open source
|
||||
projects, each with its own requirements, installation procedures, and
|
||||
configuration management. Fuel brings all of these projects together into a
|
||||
single open source distribution, with components that have been tested and are
|
||||
guaranteed to work together, and all wrapped up using scripts to help you work
|
||||
through a single installation.
|
||||
|
||||
Simply put, Fuel is a way for you to easily configure and install an
|
||||
OpenStack-based infrastructure in your own environment.
|
||||
|
||||
.. image:: /_images/FuelSimpleDiagramv.png
|
||||
:width: 100%
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
How Fuel Works
|
||||
--------------
|
||||
|
||||
Fuel works on a simple premise. Rather than installing each of the myriad
|
||||
components that make up OpenStack directly, you instead use a configuration
|
||||
management system like Puppet to create scripts that can provide a configurable,
|
||||
reproducible, sharable installation process.
|
||||
|
||||
In practice, that means that the process of using Fuel Library looks like this:
|
||||
|
||||
#. First, use Fuel's automation tools and instructions to set up a master
|
||||
node with Puppet Master and Cobbler. This process only needs to be
|
||||
completed once per installation.
|
||||
|
||||
#. Next, use Fuel's snippets, kickstart files, and preseed files for Cobbler
|
||||
to boot the appropriate servers from bare metal and automatically install
|
||||
the appropriate operating systems. These virtual or physical servers boot
|
||||
up already prepared to call on the Puppet Master to receive their
|
||||
respective OpenStack components.
|
||||
|
||||
#. Finally, to complete the basic OpenStack install, use Fuel's puppet
|
||||
manifests to install OpenStack on the newly created servers. These
|
||||
manifests are completely customizable, enabling you to start with one of
|
||||
the included OpenStack architectures and adapt to your own situation as
|
||||
necessary.
|
||||
|
||||
.. image:: /_images/010-how-it-works_svg.png
|
||||
:width: 100%
|
||||
|
||||
Fuel comes with several pre-defined deployment configurations, some of which
|
||||
include additional options from which you can choose.
|
||||
|
||||
As of the 3.1 release of Fuel for OpenStack, FuelWeb is included as part of the
|
||||
package. FuelWeb is a simplified way to deploy production-grade OpenStack
|
||||
clouds. FuelWeb provides a streamlined, graphical console experience using the
|
||||
underlying scripts from Fuel Library, including proven deployment configurations
|
||||
and a well-organized workflow for deploying and managing OpenStack environments.
|
||||
|
||||
FuelWeb integrates all of the components of Fuel Library into a unified,
|
||||
web-based graphical user interface that walks administrators through the process
|
||||
of installing and configuring a fully functional OpenStack environment.
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
Deployment Configurations Provided By Fuel
|
||||
------------------------------------------
|
||||
|
||||
One of the advantages of Fuel is that it comes with a number of pre-built deployment configurations that you can use to quickly build your own OpenStack cloud infrastructure. These are well-specified configurations of OpenStack and its constituent components are tailored to one or more common cloud use cases. Fuel provides the ability to create the following cluster types without requiring extensive customization:
|
||||
|
||||
**Single node**: Perfect for getting a feel for how OpenStack works, the Single-node installation is the simplest way to get OpenStack up and running. The Single-node installation provides an easy way to install an entire OpenStack cluster on a single physical server system or in a virtual machine environment.
|
||||
|
||||
**Multi-node (non-HA)**: The Multi-node (non-HA) installation enables you to try out additional OpenStack services like Cinder, Neutron (formerly Quantum), and Swift without requiring the degree of increased hardware involved in ensuring high availability. In addition to the ability to independently specify which services to activate, you also have the following options:
|
||||
|
||||
**Compact Swift**: When you choose this option, Swift will be installed on your controllers, reducing your hardware requirements by eliminating the need for additional Swift servers.
|
||||
|
||||
**Standalone Swift**: This option enables you to install independant Swift nodes, so that you can separate their operation from your controller nodes.
|
||||
|
||||
**Multi-node (HA)**: When you're ready to begin your move to production, the Multi-node (HA) configuration is a straightforward way to create an OpenStack cluster that provides high availability. With three controller nodes and the ability to individually specify services such as Cinder, Neutron, and Swift, Fuel provides the following variations of the Multi-node (HA) configuration:
|
||||
|
||||
**Compact Swift**: When you choose this option, Swift will be installed on your controllers, reducing your hardware requirements by eliminating the need for additional Swift servers while still addressing high availability requirements.
|
||||
|
||||
**Standalone Swift**: This option enables you to install independant Swift nodes, so that you can separate their operation from your controller nodes.
|
||||
|
||||
**Compact Neutron**: If you don't need the flexibility of a separate Neutron node, Fuel provides the option to combine your Neutron node with one of your controllers.
|
||||
|
||||
In addition to these configurations, Fuel is designed to be completely customizable. For assistance on deeper customization options based on the included configurations you can `contact Mirantis for further assistance <http://www.mirantis.com/contact/>`_.
|
||||
|
|
@ -11,7 +11,7 @@ Fuel has been tested and is guaranteed to work with the following software compo
|
|||
* 2.7.19
|
||||
|
||||
* MCollective
|
||||
* 2.2.4
|
||||
* 2.3.1
|
||||
|
||||
* Cobbler (bare-metal provisioning tool)
|
||||
* 2.2.3
|
||||
|
|
@ -21,6 +21,7 @@ Fuel has been tested and is guaranteed to work with the following software compo
|
|||
|
||||
* Hypervisor
|
||||
* KVM
|
||||
* QEMU
|
||||
|
||||
* Open vSwitch
|
||||
* 1.10.0
|
||||
|
|
@ -40,9 +41,6 @@ Fuel has been tested and is guaranteed to work with the following software compo
|
|||
* Corosync
|
||||
* 1.4.3
|
||||
|
||||
* Keepalived
|
||||
* 1.2.4
|
||||
|
||||
* Nagios
|
||||
* 3.4.4
|
||||
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
Download Fuel
|
||||
-------------
|
||||
|
||||
The first step in installing Fuel is to download the version appropriate for
|
||||
your environment.
|
||||
|
||||
Fuel is available for Essex, Folsom and Grizzly OpenStack installations, and
|
||||
will be available for Havana shortly after Havana's release.
|
||||
|
||||
The master node ISO, along with other Fuel releases, is available in the
|
||||
`Downloads <http://fuel.mirantis.com/your-downloads/>`_ section of the Fuel portal.
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
RabbitMQ Cluster Restart Issues Following A Systemwide Failure
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
--------------------------------------------------------------
|
||||
|
||||
**Issue:**
|
||||
As a rule of thumb, all RabbitMQ nodes must not be shut down simultaneously. RabbitMQ requires that after a full shutdown of the cluster, the first node brought up should be the last one to shut down, but it's not always possible to know which node that is in the event of a power outage or similar event. Versions 2.1 and later of Fuel solve this problem by managing the restart of available nodes, so you should not experience difficulty with this issue.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
Galera cluster has no built-in restart or shutdown mechanism
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
------------------------------------------------------------
|
||||
|
||||
**Issue:**
|
||||
A Galera cluster cannot be simply started or stopped. It is designed to work continuously.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,48 @@
|
|||
.. _add-remove-nodes-without-downtime:
|
||||
|
||||
Add or Remove Controller and Compute Nodes Without Downtime
|
||||
-----------------------------------------------------------
|
||||
|
||||
1. Addition of computes works seamlessly - just specify its IPs in site.pp (if needed) and run puppet
|
||||
2. Deletion of computes is the same as deletion from openstack: migrate machines, shutdown node, delete from database (Puppet class needed)
|
||||
3. Addition of controllers works as soon as puppet deploys. Which testing is needed:
|
||||
a. Test that altering the site.pp (adding new controller) and running puppet consequently on all controllers does not break anything
|
||||
4. Deletion of controllers should work as soon as quorum for galera and pacemaker is OK. What to test:
|
||||
a. Altering of quorum in case of node deletion
|
||||
b. If we need to alter quorum - we need to write classes for this
|
||||
|
||||
Node deletion
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
Disclaimer: BTW, this is not included into folsom as cinder service disabling is not supported: it is going to be there in grizzly. Even though, cinder deletion and migration of volumes is not going to be there. Artem Andreev says, they are working on cinder volume migration for Dell M2 and it will be ready by the end of the May.
|
||||
|
||||
Deletion of the node assumes the following sequence of actions:
|
||||
|
||||
1. Back databases (MySQL, AMQP(???), pacemaker) up
|
||||
2. Disable services hosted on this node:
|
||||
a. shutdown nova-compute and disable it (for computes)
|
||||
b. shutdown nova-api and other services residing on controllers
|
||||
c. move all the stuff from node being deleted:
|
||||
i. migrate VMS
|
||||
ii. migrate cinder volumes (HOW?????)
|
||||
iii. migrate singleton pacemaker services (if any)
|
||||
iv. avoid starting of pacemaker services on the node in case of multistate primitive
|
||||
d. Disable all the services for the node (by use of database or by use of client)
|
||||
|
||||
3. For controllers:
|
||||
a. Delete node from galera cluster (HOW???)
|
||||
b. Delete node from pacemaker (crm node delete ???)
|
||||
4. For swift storages:
|
||||
a. remove node from the ring (for storage)
|
||||
b. rebuild ring
|
||||
c. rebalance
|
||||
d. rsync new rings to nodes
|
||||
5. For swift proxies:
|
||||
a. shutdown the node
|
||||
b. update haproxy backends by site.pp edit and puppet run
|
||||
6. Cleanup the database
|
||||
|
||||
Necessity of special resources considerations
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Looks like we need to create special puppet resource called "node" with different providers "controller/storage/proxy/etc." for it and specify the :ensure property for them. Running the resource with corresponding property generates corresponding resources and does all the steps needed.
|
||||
|
|
@ -72,7 +72,7 @@ Common Technical Issues
|
|||
.. _create-the-XFS-partition:
|
||||
|
||||
Creating the XFS partition
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
--------------------------
|
||||
|
||||
In most cases, Fuel creates the XFS partition for you. If for some reason you need to create it yourself, use this procedure:
|
||||
|
||||
|
|
@ -100,7 +100,7 @@ In most cases, Fuel creates the XFS partition for you. If for some reason you n
|
|||
mount -a
|
||||
|
||||
Redeploying a node from scratch
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
-------------------------------
|
||||
|
||||
Compute and Cinder nodes in an HA configuration and controller in any configuration cannot be redeployed without completely redeploying the cluster. However, in a non-HA situation you can redeploy a compute or Cinder node. To do so, follow these steps:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
Installing Fuel Web
|
||||
===================
|
||||
Installing FuelWeb
|
||||
------------------
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
Fuel Web is distributed as both an ISO and an IMG image, each of which contains
|
||||
FuelWeb is distributed as both an ISO and an IMG image, each of which contains
|
||||
an installer for an admin node. The ISO image is used for CD media devices, iLO
|
||||
or similar remote access systems. The IMG file is used for USB memory drives.
|
||||
|
||||
|
|
@ -39,7 +39,7 @@ OpenStack.
|
|||
On VirtualBox
|
||||
-------------
|
||||
|
||||
If you are going to evaluate Fuel Web on VirtualBox, you should know that we
|
||||
If you are going to evaluate FuelWeb on VirtualBox, you should know that we
|
||||
provide a set of scripts that create and configure all of the required VMs for
|
||||
you, including the admin node and slave nodes for OpenStack itself. It's a very
|
||||
simple, single-click installation.
|
||||
|
|
@ -49,7 +49,7 @@ simple, single-click installation.
|
|||
VirtualBox by creating the VMs yourself. See "Manual Mode" for more
|
||||
information.
|
||||
|
||||
The requirements for running Fuel Web on VirtualBox are:
|
||||
The requirements for running FuelWeb on VirtualBox are:
|
||||
|
||||
* A physical machine with Linux or Mac OS.
|
||||
|
||||
|
|
@ -74,7 +74,7 @@ When you unpack the scripts, you will see the following important files and fold
|
|||
|
||||
* iso
|
||||
|
||||
* This folder needs to contain a single ISO image for Fuel Web. Once you
|
||||
* This folder needs to contain a single ISO image for FuelWeb. Once you
|
||||
download ISO from the portal, copy or move it into this directory
|
||||
|
||||
* config.sh
|
||||
|
|
@ -102,7 +102,7 @@ Manual mode
|
|||
^^^^^^^^^^^
|
||||
|
||||
If you cannot or would rather not run the convenience scripts, you can still run
|
||||
Fuel Web on VirtualBox by following these steps.
|
||||
FuelWeb on VirtualBox by following these steps.
|
||||
|
||||
Admin node deployment
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -126,7 +126,7 @@ First, create the admin node.
|
|||
3. Power on the VM in order to start the installation.
|
||||
|
||||
4. Wait for the welcome message with all information needed to login into the UI
|
||||
of Fuel Web.
|
||||
of FuelWeb.
|
||||
|
||||
Adding slave nodes
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
|||
|
|
@ -10,6 +10,7 @@ Usually it measn that switch or multiple switches are not configured correctly a
|
|||
traffic to pass through.
|
||||
|
||||
.. image:: /_images/net_verify_failure.png
|
||||
:width: 100%
|
||||
|
||||
On VirtualBox
|
||||
-------------
|
||||
|
|
|
|||
|
|
@ -282,7 +282,8 @@ these networks live in VLANs over the one or multiple physical interfaces on a
|
|||
node. This means that the switch should pass tagged traffic, and untagging is done
|
||||
on the Linux hosts.
|
||||
|
||||
.. note:: For the sake of simplicity, all the VLANs specified on the networks tab of
|
||||
.. note::
|
||||
For the sake of simplicity, all the VLANs specified on the networks tab of
|
||||
the FuelWeb should be configured on switch ports, pointing to slave nodes,
|
||||
as tagged.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,17 @@
|
|||
In this section, you’ll learn how to install OpenStack using Fuel and Fuel Web. In addition to getting a feel for the steps involved, you’ll also gain valuable familiarity with some of the customization options. While Fuel provides different deployment configuration templates in the box, it is common for administrators to modify the architecture to meet enterprise requirements. Working hands on with Fuel for OpenStack will help you see how to move certain features around from the standard installation.
|
||||
In this section, you’ll learn how to install OpenStack using Fuel and FuelWeb.
|
||||
In addition to getting a feel for the steps involved, you’ll also gain valuable
|
||||
familiarity with some of the customization options. While Fuel provides different
|
||||
deployment configuration templates in the box, it is common for administrators
|
||||
to modify the architecture to meet enterprise requirements. Working hands on with
|
||||
Fuel for OpenStack will help you see how to move certain features around from the
|
||||
standard installation.
|
||||
|
||||
The first step, however, is to commit to a deployment template. A balanced, compact, and full-featured deployment is the Multi-node (HA) Compact deployment, so that’s what we’ll be using through the rest of this guide.
|
||||
The first step, however, is to commit to a deployment template. A balanced,
|
||||
compact, and full-featured deployment is the Multi-node (HA) Compact deployment,
|
||||
so that’s what we’ll be using through the rest of this guide.
|
||||
|
||||
Production installations require a physical hardware infrastructure, but you can easily deploy a small simulation cloud on a single physical machine using VirtualBox. You can follow these instructions to install an OpenStack cloud into a test environment using VirtualBox, or to get a production-grade installation using physical hardware.
|
||||
Production installations require a physical hardware infrastructure, but you can
|
||||
easily deploy a small simulation cloud on a single physical machine using VirtualBox.
|
||||
You can follow these instructions to install an OpenStack cloud into a test
|
||||
environment using VirtualBox, or to get a production-grade installation using
|
||||
physical hardware.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
Understanding the Puppet Manifest
|
||||
---------------------------------
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
At this point you should have functioning servers that are ready to take an OpenStack installation. If you're using VirtualBox, save the current state of every virtual machine by taking a snapshot using ``File->Take Snapshot``. Snapshots are a useful tool when you make a mistake, encounter an issue, or just want to try different configurations, all without having to start from scratch.
|
||||
|
||||
Next, go through the ``/etc/puppet/manifests/site.pp`` file and make any necessary customizations. If you have run ``openstack_system``, there shouldn't be anything to change (with one small exception) but if you are installing Fuel manually, you will need to make these changes yourself.
|
||||
|
|
@ -523,10 +525,10 @@ This variable accepts the following values:
|
|||
* ``default``: In this mode, the dashboard uses keys supplied with the standard Apache SSL module package.
|
||||
* ``exist``: In this case, the dashboard assumes that the domain name-based certificate, or keys, are provisioned in advance. This can be a certificate signed by any authorized provider, such as Symantec/Verisign, Comodo, GoDaddy, and so on. The system looks for the keys in these locations:
|
||||
|
||||
for Debian/Ubuntu:
|
||||
* public ``/etc/ssl/certs/domain-name.pem``
|
||||
* private ``/etc/ssl/private/domain-name.key``
|
||||
for Centos/RedHat:
|
||||
.. for Debian/Ubuntu:
|
||||
.. * public ``/etc/ssl/certs/domain-name.pem``
|
||||
.. * private ``/etc/ssl/private/domain-name.key``
|
||||
.. for Centos/RedHat:
|
||||
* public ``/etc/pki/tls/certs/domain-name.crt``
|
||||
* private ``/etc/pki/tls/private/domain-name.key``
|
||||
|
||||
|
|
|
|||
|
|
@ -1,14 +1,22 @@
|
|||
Deploying OpenStack
|
||||
-------------------
|
||||
Deploying OpenStack using Puppet Manifests
|
||||
------------------------------------------
|
||||
|
||||
You have two options for deploying OpenStack. The best method is to use orchestration, but you can also deploy your nodes manually.
|
||||
.. contents:: :local:
|
||||
|
||||
You have two options for deploying OpenStack using Puppet manifests. The best
|
||||
method is to use orchestration, but you can also deploy your nodes manually.
|
||||
|
||||
.. _orchestration:
|
||||
|
||||
Deploying via orchestration
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Performing a small series of manual installs many be an acceptable approach in some circumstances, but if you plan on deploying to a large number of servers then we strongly suggest that you consider orchestration. You can perform a deployment using orchestration with Fuel using the "astute" script. This script is configured using the "astute.yaml" file that was created when you ran "openstack_system" earlier in this process.
|
||||
Performing a small series of manual installs many be an acceptable approach in
|
||||
some circumstances, but if you plan on deploying to a large number of servers
|
||||
then we strongly suggest that you consider orchestration. You can perform a
|
||||
deployment using orchestration with Fuel using the "astute" script. This script
|
||||
is configured using the "astute.yaml" file that was created when you ran
|
||||
"openstack_system" earlier in this process.
|
||||
|
||||
To confirm that your servers are ready for orchestration, execute the following command::
|
||||
|
||||
|
|
@ -64,34 +72,35 @@ Examples of OpenStack installation sequences
|
|||
|
||||
When running Puppet manually, the exact sequence depends on the configuration goals you're trying to achieve. In most cases, you'll need to run Puppet more than once; with every pass Puppet collects and adds necessary absent information to the OpenStack configuration, stores it to PuppedDB and applies necessary changes.
|
||||
|
||||
**Note:** *Sequentially run* means you don't start the next node deployment until previous one is finished.
|
||||
.. note::
|
||||
*Sequentially run* means you don't start the next node deployment until previous one is finished.
|
||||
|
||||
**Example 1: Full OpenStack deployment with standalone storage nodes**
|
||||
|
||||
**Example 1:** **Full OpenStack deployment with standalone storage nodes**
|
||||
* Create necessary volumes on storage nodes as described in :ref:`create-the-XFS-partition`.
|
||||
* Sequentially run a deployment pass on every SwiftProxy node (``fuel-swiftproxy-01 ... fuel-swiftproxy-xx``), starting with the ``primary-swift-proxy node``. Node names are set by the ``$swift_proxies`` variable in ``site.pp``. There are 2 Swift Proxies by default.
|
||||
* Sequentially run a deployment pass on every storage node (``fuel-swift-01`` ... ``fuel-swift-xx``).
|
||||
* Sequentially run a deployment pass on the controller nodes (``fuel-controller-01 ... fuel-controller-xx``). starting with the ``primary-controller`` node.
|
||||
* Run a deployment pass on the Neutron (formerly Quantum) node (``fuel-quantum``) to install the Neutron router.
|
||||
* Run a deployment pass on every compute node (``fuel-compute-01 ... fuel-compute-xx``) - unlike the controllers, these nodes may be deployed in parallel.
|
||||
* Run an additional deployment pass on Controller 1 only (``fuel-controller-01``) to finalize the Galera cluster configuration.
|
||||
|
||||
**Example 2: Compact OpenStack deployment with storage and swift-proxy combined with nova-controller on the same nodes**
|
||||
|
||||
* Create necessary volumes on storage nodes as described in :ref:`create-the-XFS-partition`.
|
||||
* Sequentially run a deployment pass on every SwiftProxy node (``fuel-swiftproxy-01 ... fuel-swiftproxy-xx``), starting with the ``primary-swift-proxy node``. Node names are set by the ``$swift_proxies`` variable in ``site.pp``. There are 2 Swift Proxies by default.
|
||||
* Sequentially run a deployment pass on every storage node (``fuel-swift-01`` ... ``fuel-swift-xx``).
|
||||
* Sequentially run a deployment pass on the controller nodes (``fuel-controller-01 ... fuel-controller-xx``). starting with the ``primary-controller`` node.
|
||||
* Run a deployment pass on the Neutron (formerly Quantum) node (``fuel-quantum``) to install the Neutron router.
|
||||
* Run a deployment pass on every compute node (``fuel-compute-01 ... fuel-compute-xx``) - unlike the controllers, these nodes may be deployed in parallel.
|
||||
* Run an additional deployment pass on Controller 1 only (``fuel-controller-01``) to finalize the Galera cluster configuration.
|
||||
* Create the necessary volumes on controller nodes as described in :ref:`create-the-XFS-partition`
|
||||
* Sequentially run a deployment pass on the controller nodes (``fuel-controller-01 ... fuel-controller-xx``), starting with the ``primary-controller node``. Errors in Swift storage such as */Stage[main]/Swift::Storage::Container/Ring_container_device[<device address>]: Could not evaluate: Device not found check device on <device address>* are expected during the deployment passes until the very final pass.
|
||||
* Run an additional deployment pass on Controller 1 only (``fuel-controller-01``) to finalize the Galera cluster configuration.
|
||||
* Run a deployment pass on the Neutron node (``fuel-quantum``) to install the Neutron router.
|
||||
* Run a deployment pass on every compute node (``fuel-compute-01 ... fuel-compute-xx``) - unlike the controllers these nodes may be deployed in parallel.
|
||||
|
||||
**Example 2:** **Compact OpenStack deployment with storage and swift-proxy combined with nova-controller on the same nodes**
|
||||
**Example 3:** **OpenStack HA installation without Swift**
|
||||
|
||||
* Create the necessary volumes on controller nodes as described in :ref:`create-the-XFS-partition`
|
||||
* Sequentially run a deployment pass on the controller nodes (``fuel-controller-01 ... fuel-controller-xx``), starting with the ``primary-controller node``. Errors in Swift storage such as */Stage[main]/Swift::Storage::Container/Ring_container_device[<device address>]: Could not evaluate: Device not found check device on <device address>* are expected during the deployment passes until the very final pass.
|
||||
* Run an additional deployment pass on Controller 1 only (``fuel-controller-01``) to finalize the Galera cluster configuration.
|
||||
* Run a deployment pass on the Neutron node (``fuel-quantum``) to install the Neutron router.
|
||||
* Run a deployment pass on every compute node (``fuel-compute-01 ... fuel-compute-xx``) - unlike the controllers these nodes may be deployed in parallel.
|
||||
* Sequentially run a deployment pass on the controller nodes (``fuel-controller-01 ... fuel-controller-xx``), starting with the primary controller. No errors should appear during this deployment pass.
|
||||
* Run an additional deployment pass on the primary controller only (``fuel-controller-01``) to finalize the Galera cluster configuration.
|
||||
* Run a deployment pass on the Neutron node (``fuel-quantum``) to install the Neutron router.
|
||||
* Run a deployment pass on every compute node (``fuel-compute-01 ... fuel-compute-xx``) - unlike the controllers these nodes may be deployed in parallel.
|
||||
|
||||
**Example 3:** **OpenStack HA installation without Swift**
|
||||
**Example 4:** **The simplest OpenStack installation: Controller + Compute on the same node**
|
||||
|
||||
* Sequentially run a deployment pass on the controller nodes (``fuel-controller-01 ... fuel-controller-xx``), starting with the primary controller. No errors should appear during this deployment pass.
|
||||
* Run an additional deployment pass on the primary controller only (``fuel-controller-01``) to finalize the Galera cluster configuration.
|
||||
* Run a deployment pass on the Neutron node (``fuel-quantum``) to install the Neutron router.
|
||||
* Run a deployment pass on every compute node (``fuel-compute-01 ... fuel-compute-xx``) - unlike the controllers these nodes may be deployed in parallel.
|
||||
|
||||
**Example 4:** **The simplest OpenStack installation: Controller + Compute on the same node**
|
||||
|
||||
* Set the ``node /fuel-controller-[\d+]/`` variable in ``site.pp`` to match the hostname of the node on which you are going to deploy OpenStack. Set the ``node /fuel-compute-[\d+]/`` variable to **mismatch** the node name. Run a deployment pass on this node. No errors should appear during this deployment pass.
|
||||
* Set the ``node /fuel-compute-[\d+]/`` variable in ``site.pp`` to match the hostname of the node on which you are going to deploy OpenStack. Set the ``node /fuel-controller-[\d+]/`` variable to **mismatch** the node name. Run a deployment pass on this node. No errors should appear during this deployment pass.
|
||||
* Set the ``node /fuel-controller-[\d+]/`` variable in ``site.pp`` to match the hostname of the node on which you are going to deploy OpenStack. Set the ``node /fuel-compute-[\d+]/`` variable to **mismatch** the node name. Run a deployment pass on this node. No errors should appear during this deployment pass.
|
||||
* Set the ``node /fuel-compute-[\d+]/`` variable in ``site.pp`` to match the hostname of the node on which you are going to deploy OpenStack. Set the ``node /fuel-controller-[\d+]/`` variable to **mismatch** the node name. Run a deployment pass on this node. No errors should appear during this deployment pass.
|
||||
|
|
|
|||
|
|
@ -1,23 +0,0 @@
|
|||
This document explains how to use Fuel to easily create and maintain an OpenStack cloud infrastructure.
|
||||
|
||||
Fuel can be used to create virtually any OpenStack configuration. To make things easier, the installation includes several pre-defined architectures. For the sake of simplicity, this guide emphasises a single, common reference architecture; the multi-node, high-availability configuration. We begin with an explanation of this architecture, then move on to the details of creating the configuration in a test environment using VirtualBox. Finally, we give you the information you need to know to create this and other OpenStack architectures in a production environment.
|
||||
|
||||
This document assumes that you are familiar with general Linux commands and administration concepts, as well as general networking concepts. You should have some familiarity with grid or virtualization systems such as Amazon Web Services or VMware, as well as OpenStack itself, but you don't need to be an expert.
|
||||
|
||||
The Fuel User's Guide is organized as follows:
|
||||
|
||||
* Section 1, :ref:`Introduction <Introduction>` (this section), gives you an overview of Fuel and gives you a general idea of how it works.
|
||||
|
||||
* Section 2, :ref:`Reference Architecture <Reference-Archiecture>`, provides a general look at the components that make up OpenStack, and describes the reference architecture to be instantiated in Section 3.
|
||||
|
||||
* Section 3.1, :ref:`Create a multi-node OpenStack cluster using Fuel Web <Fuel-Web-Cluster>`, takes you step-by-step through the process of creating a high-availability OpenStack cluster using Fuel Web.
|
||||
|
||||
* Section 3.2, :ref:`Create a multi-node OpenStack cluster using Fuel <Create-Cluster>`, takes you step-by-step through the more advanced process of creating a high-availability OpenStack cluster using the standard Fuel tools.
|
||||
|
||||
* Section 4, :ref:`Production Considerations <Production>`, looks at the real-world questions and problems involved in creating an OpenStack cluster for production use. We discuss issues such as network layout and hardware requirements, and provide tips and tricks for creating a cluster of up to 100 nodes.
|
||||
|
||||
* With the 3.1 release of Fuel, Fuel Web has been integrated. We encourage all users to use the Fuel Web process for installation and configuration. However, the standard Fuel installation process is still available for those of you who prefer a more detailed approach to deployment. Even with a utility as powerful as Fuel, creating an OpenStack cluster can be complex, and Section 5, :ref:`Frequently Asked Questions <FAQ>`, covers many of the issues that tend to arise during that process.
|
||||
|
||||
* Finally, the User's Guide assumes that you are taking advantage of certain shortcuts, such as using a pre-built Puppet master; if you prefer not to go that route, Appendix A, :ref:`Creating the Puppet master <Create-PM>`, will give you details regarding the configuration of a Puppet Master.
|
||||
|
||||
Lets start off by taking a look at Fuel itself. We'll start by explaining what it is and how it works, and then move to the process of installation itself.
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
What is Fuel?
|
||||
-----------------
|
||||
|
||||
Fuel is a ready-to-install collection of the packages and scripts you need to create a robust, configurable, vendor-independant OpenStack cloud in your own environment.
|
||||
|
||||
A single OpenStack cloud consists of packages from many different open source projects, each with its own requirements, installation procedures, and configuration management. Fuel brings all of these projects together into a single open source distribution, with components that have been tested and are guaranteed to work together, and all wrapped up using scripts to help you work through a single installation.
|
||||
|
||||
Simply put, Fuel is a way for you to easily configure and install an OpenStack-based infrastructure in your own environment.
|
||||
|
||||
.. image:: /_images/FuelSimpleDiagramv.png
|
||||
:width: 100%
|
||||
:align: center
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
How Fuel Works
|
||||
--------------
|
||||
|
||||
Fuel works on a simple premise. Rather than installing each of the myriad components that make up OpenStack directly, you instead use a configuration management system like Puppet to create scripts that can provide a configurable, reproducible, sharable installation process.
|
||||
|
||||
In practice, that means that the process of using Fuel Library looks like this:
|
||||
|
||||
#. First, use Fuel's automation tools and instructions to set up a master node with Puppet Master and Cobbler. This process only needs to be completed once per installation.
|
||||
|
||||
#. Next, use Fuel's snippets, kickstart files, and preseed files for Cobbler to boot the appropriate servers from bare metal and automatically install the appropriate operating systems. These virtual or physical servers boot up already prepared to call on the Puppet Master to receive their respective OpenStack components.
|
||||
|
||||
#. Finally, to complete the basic OpenStack install, use Fuel's puppet manifests to install OpenStack on the newly created servers. These manifests are completely customizable, enabling you to start with one of the included OpenStack architectures and adapt to your own situation as necessary.
|
||||
|
||||
.. image:: /_images/010-how-it-works_svg.png
|
||||
:align: center
|
||||
:width: 100%
|
||||
|
||||
Fuel comes with several pre-defined deployment configurations, some of which include additional options from which you can choose.
|
||||
|
||||
As of the 3.1 release of Fuel for OpenStack, Fuel Web is included as part of the package. Fuel Web is a simplified way to deploy production-grade OpenStack clouds. Fuel Web provides a streamlined, graphical console experience using the underlying scripts from Fuel Library, including proven deployment configurations and a well-organized workflow for deploying and managing OpenStack environments.
|
||||
|
||||
Fuel Web integrates all of the components of Fuel Library into a unified, web-based graphical user interface that walks administrators through the process of installing and configuring a fully functional OpenStack environment.
|
||||
|
|
@ -1,50 +0,0 @@
|
|||
Deployment Configurations Provided By Fuel
|
||||
------------------------------------------
|
||||
|
||||
One of the advantages of Fuel is that it comes with a number of pre-built
|
||||
deployment configurations that you can use to quickly build your own OpenStack
|
||||
cloud infrastructure. These are well-specified configurations of OpenStack and
|
||||
its constituent components are tailored to one or more common cloud use cases.
|
||||
Fuel provides the ability to create the following cluster types without
|
||||
requiring extensive customization:
|
||||
|
||||
**Single node**: Perfect for getting a feel for how OpenStack works, the
|
||||
Single-node installation is the simplest way to get OpenStack up and running.
|
||||
The Single-node installation provides an easy way to install an entire OpenStack
|
||||
cluster on a single physical server system or in a virtual machine environment.
|
||||
|
||||
**Multi-node (non-HA)**: The Multi-node (non-HA) installation enables you to try
|
||||
out additional OpenStack services like Cinder, Neutron (formerly Quantum), and
|
||||
Swift without requiring the degree of increased hardware involved in ensuring
|
||||
high availability. In addition to the ability to independently specify which
|
||||
services to activate, you also have the following options:
|
||||
|
||||
**Compact Swift**: When you choose this option, Swift will be installed on
|
||||
your controllers, reducing your hardware requirements by eliminating the need
|
||||
for additional Swift servers.
|
||||
|
||||
**Standalone Swift**: This option enables you to install independant Swift
|
||||
nodes, so that you can separate their operation from your controller nodes.
|
||||
|
||||
**Multi-node (HA)**: When you're ready to begin your move to production, the
|
||||
Multi-node (HA) configuration is a straightforward way to create an OpenStack
|
||||
cluster that provides high availability. With three controller nodes and the
|
||||
ability to individually specify services such as Cinder, Neutron, and Swift,
|
||||
Fuel provides the following variations of the Multi-node (HA) configuration:
|
||||
|
||||
**Compact Swift**: When you choose this option, Swift will be installed on
|
||||
your controllers, reducing your hardware requirements by eliminating the need
|
||||
for additional Swift servers while still addressing high availability
|
||||
requirements.
|
||||
|
||||
**Standalone Swift**: This option enables you to install independant Swift
|
||||
nodes, so that you can separate their operation from your controller nodes.
|
||||
|
||||
**Compact Neutron**: If you don't need the flexibility of a separate Neutron
|
||||
node, Fuel provides the option to combine your Neutron node with one of your
|
||||
controllers.
|
||||
|
||||
In addition to these configurations, Fuel is designed to be completely
|
||||
customizable. For assistance on deeper customization options based on the
|
||||
included configurations you can
|
||||
`contact Mirantis for further assistance <http://www.mirantis.com/contact/>`_.
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
Download Fuel
|
||||
-------------
|
||||
|
||||
The first step in installing Fuel is to download the version appropriate for your environment.
|
||||
|
||||
Fuel is available for Essex, Folsom and Grizzly OpenStack installations, and will be available for Havana shortly after Havana's release.
|
||||
|
||||
To make your installation easier, we also offer a pre-built ISO for installing the master node with Puppet Master and Cobbler. You can mount this ISO on a physical machine or in VirtualBox in order to easily create your master node. (Instructions for performing this step without the ISO are given in :ref:`Appendix A <Create-PM>`.)
|
||||
|
||||
The master node ISO, along with other Fuel releases, is available in the `Downloads <http://fuel.mirantis.com/your-downloads/>`_ section of the Fuel portal.
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
Release Notes
|
||||
-------------
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
.. include:: /pages/introduction/release-notes/v3-1-grizzly.rst
|
||||
.. include:: /pages/introduction/release-notes/v3-0-grizzly.rst
|
||||
.. include:: /pages/introduction/release-notes/v2-1-folsom.rst
|
||||
.. include:: /pages/introduction/release-notes/v2-0-folsom.rst
|
||||
.. include:: /pages/introduction/release-notes/v1-0-essex.rst
|
||||
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
v3.1-grizzly
|
||||
^^^^^^^^^^^^
|
||||
|
||||
**New Features in Fuel and Fuel Web 3.1**
|
||||
|
||||
PLACEHOLDER
|
||||
|
|
@ -1,6 +1,8 @@
|
|||
Sizing Hardware
|
||||
---------------
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
One of the first questions people ask when planning an OpenStack deployment is "what kind of hardware do I need?" There is no such thing as a one-size-fits-all answer, but there are straightforward rules to selecting appropriate hardware that will suit your needs. The Golden Rule, however, is to always accomodate for growth. With the potential for growth accounted for, you can move on to the actual hardware needs.
|
||||
|
||||
Many factors contribute to selecting hardware for an OpenStack cluster -- `contact Mirantis <http://www.mirantis.com/contact/>`_ for information on your specific requirements -- but in general, you will want to consider the following factors:
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
Redeploying An Environment
|
||||
--------------------------
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
Because Puppet is additive only, there is no ability to revert changes as you would in a typical application deployment. If a change needs to be backed out, you must explicitly add a configuration to reverse it, check the configuration in, and promote it to production using the pipeline. This means that if a breaking change does get deployed into production, typically a manual fix is applied, with the proper fix subsequently checked into version control.
|
||||
|
||||
Fuel offers the ability to isolate code changes while developing a deployment and minimizes the headaches associated with maintaining multiple configurations through a single Puppet Master by creating what are called environments.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
Large Scale Deployments
|
||||
-----------------------
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
When deploying large clusters -- those of 100 nodes or more -- there are two basic bottlenecks:
|
||||
|
||||
* Certificate signing requests and Puppet Master/Cobbler capacity
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
Overview
|
||||
--------
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
Before you install any hardware or software, you must know what it is
|
||||
you're trying to achieve. This section looks at the basic components of
|
||||
an OpenStack infrastructure and organizes them into one of the more
|
||||
|
|
@ -9,29 +11,29 @@ basis for installing OpenStack in the next section.
|
|||
|
||||
As you know, OpenStack provides the following basic services:
|
||||
|
||||
**Compute**: Compute servers are the workhorses of your installation; they're
|
||||
the servers on which your users' virtual machines are created. `Nova-scheduler`
|
||||
controls the life-cycle of these VMs.
|
||||
* **Compute**: Compute servers are the workhorses of your installation; they're
|
||||
the servers on which your users' virtual machines are created.
|
||||
`nova-scheduler` controls the life-cycle of these VMs.
|
||||
|
||||
**Networking**: Because an OpenStack cluster (virtually) always includes
|
||||
multiple servers, the ability for them to communicate with each other and with
|
||||
the outside world is crucial. Networking was originally handled by the
|
||||
`nova-network` service, but it has given way to the newer Neutron (formerly
|
||||
Quantum) networking service. Authentication and authorization for these
|
||||
transactions are handled by `keystone`.
|
||||
* **Networking**: Because an OpenStack cluster (virtually) always includes
|
||||
multiple servers, the ability for them to communicate with each other and with
|
||||
the outside world is crucial. Networking was originally handled by the
|
||||
`nova-network` service, but it has given way to the newer Neutron (formerly
|
||||
Quantum) networking service. Authentication and authorization for these
|
||||
transactions are handled by `keystone`.
|
||||
|
||||
**Storage**: OpenStack provides for two different types of storage: block
|
||||
storage and object storage. Block storage is traditional data storage, with
|
||||
small, fixed-size blocks that are mapped to locations on storage media. At its
|
||||
simplest level, OpenStack provides block storage using `nova-volume`, but it is
|
||||
common to use `cinder`.
|
||||
* **Storage**: OpenStack provides for two different types of storage: block
|
||||
storage and object storage. Block storage is traditional data storage, with
|
||||
small, fixed-size blocks that are mapped to locations on storage media. At its
|
||||
simplest level, OpenStack provides block storage using `nova-volume`, but it
|
||||
is common to use `cinder`.
|
||||
|
||||
Object storage, on the other hand, consists of single variable-size objects that
|
||||
are described by system-level metadata, and you can access this capability using
|
||||
`Swift`.
|
||||
Object storage, on the other hand, consists of single variable-size objects
|
||||
that are described by system-level metadata, and you can access this capability
|
||||
using `swift`.
|
||||
|
||||
OpenStack storage is used for your users' objects, but it is also used for
|
||||
storing the images used to create new VMs. This capability is handled by `Glance`.
|
||||
OpenStack storage is used for your users' objects, but it is also used for
|
||||
storing the images used to create new VMs. This capability is handled by `glance`.
|
||||
|
||||
These services can be combined in many different ways. Out of the box,
|
||||
Fuel supports the following deployment configurations:
|
||||
|
|
@ -46,8 +48,7 @@ deploy. It is, however, extremely useful if you just want to see how
|
|||
OpenStack works from a user's point of view. In this case, all of the
|
||||
essential services run out of a single server:
|
||||
|
||||
.. image:: /_images/060-single-node_svg.png
|
||||
:width: 100%
|
||||
.. image:: https://docs.google.com/drawings/d/1gGNYYayPAPPHgOYi98Dmebry4hP1SOGF2APXWzbnNo8/pub?w=767&h=413
|
||||
|
||||
Multi-node (non-HA) deployment (compact Swift)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
|
@ -60,15 +61,13 @@ enable you to achieve this separation while still keeping your
|
|||
hardware investment relatively modest is to house your storage on your
|
||||
controller nodes.
|
||||
|
||||
|
||||
Multi-node (non-HA) deployment (standalone Swift)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
A more common arrangement is to provide separate servers for storage.
|
||||
This has the advantage of reducing the number of controllers you must
|
||||
provide; because Swift runs on its own servers, you can reduce the
|
||||
number of controllers from three (or five, for a full Swift implementation)
|
||||
to one, if desired:
|
||||
number of controllers from three (or five, for a full Swift implementation) to one, if desired:
|
||||
|
||||
.. image:: https://docs.google.com/drawings/d/1nVEtfpNLaLV4EBKJQleLxovqMVrDCRT7yFWTYUQASB0/pub?w=767&h=413
|
||||
|
||||
|
|
@ -93,11 +92,8 @@ increasing hardware requirements is to install Quantum on your
|
|||
controller nodes. This architecture still provides high availability,
|
||||
but avoids the need for a separate Neutron node:
|
||||
|
||||
|
||||
|
||||
.. image:: https://docs.google.com/drawings/d/1GYNM5yTJSlZe9nB5SHnlrqyMfVRdVh02OFLwXlz-itc/pub?w=767&h=413
|
||||
|
||||
|
||||
Multi-node (HA) deployment (Standalone)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
|
@ -107,12 +103,8 @@ gives you the advantages of high availability, but this clean
|
|||
separation makes your cluster more maintainable by separating storage,
|
||||
networking, and controller functionality:
|
||||
|
||||
|
||||
|
||||
.. image:: https://docs.google.com/drawings/d/1rJEZi5-l9oemMmrkH5UPjitQQDVGuZQ1KS0pPWTuovY/pub?w=769&h=594
|
||||
|
||||
|
||||
|
||||
Where Fuel really shines is in the creation of more complex
|
||||
architectures, so in this document you'll learn how to use Fuel to
|
||||
easily create a multi-node HA OpenStack cluster. To reduce the amount
|
||||
|
|
|
|||
|
|
@ -8,7 +8,6 @@ configuration looks something like this:
|
|||
|
||||
.. image:: https://docs.google.com/drawings/d/1xLv4zog19j0MThVGV9gSYa4wh1Ma4MQYsBz-4vE1xvg/pub?w=767&h=413
|
||||
|
||||
|
||||
OpenStack services are interconnected by RESTful HTTP-based APIs and
|
||||
AMQP-based RPC messages. So redundancy for stateless OpenStack API
|
||||
services is implemented through the combination of Virtual IP (VIP)
|
||||
|
|
|
|||
|
|
@ -2,13 +2,14 @@
|
|||
Logical Setup
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
An OpenStack HA cluster involves, at a minimum, three types of nodes:
|
||||
controller nodes, compute nodes, and storage nodes.
|
||||
|
||||
Controller Nodes
|
||||
++++++++++++++++
|
||||
|
||||
|
||||
The first order of business in achieving high availability (HA) is
|
||||
redundancy, so the first step is to provide multiple controller nodes.
|
||||
You must keep in mind, however, that the database uses Galera to
|
||||
|
|
@ -18,14 +19,11 @@ controller nodes.
|
|||
.. image:: https://docs.google.com/drawings/pub?id=1aftE8Yes7CdVSZgZD1A82T_2GqL2SMImtRYU914IMyQ&w=869&h=855
|
||||
|
||||
|
||||
|
||||
Every OpenStack controller runs keepalived, which manages a single
|
||||
Virtual IP (VIP) for all controller nodes, and HAProxy, which manages
|
||||
HTTP and TCP load balancing of requests going to OpenStack API
|
||||
services, RabbitMQ, and MySQL.
|
||||
|
||||
|
||||
|
||||
When an end user accesses the OpenStack cloud using Horizon or makes a
|
||||
request to the REST API for services such as nova-api, glance-api,
|
||||
keystone-api, quantum-api, nova-scheduler, MySQL or RabbitMQ, the
|
||||
|
|
@ -34,18 +32,14 @@ and the connection gets terminated by HAProxy. When the next request
|
|||
comes in, HAProxy handles it, and may send it to the original
|
||||
controller or another in the cluster, depending on load conditions.
|
||||
|
||||
|
||||
|
||||
Each of the services housed on the controller nodes has its own
|
||||
mechanism for achieving HA:
|
||||
|
||||
|
||||
* nova-api, glance-api, keystone-api, quantum-api and nova-scheduler are stateless services that do not require any special attention besides load balancing.
|
||||
* Horizon, as a typical web application, requires sticky sessions to be enabled at the load balancer.
|
||||
* RabbitMQ provides active/active high availability using mirrored queues.
|
||||
* MySQL high availability is achieved through Galera active/active multi-master deployment.
|
||||
|
||||
|
||||
Compute Nodes
|
||||
+++++++++++++
|
||||
|
||||
|
|
@ -57,14 +51,11 @@ as RabbitMQ and MySQL. They use the same approach that provides
|
|||
redundancy to the end-users of Horizon and REST APIs, reaching out to
|
||||
controller nodes using the VIP and going through HAProxy.
|
||||
|
||||
|
||||
.. image:: https://docs.google.com/drawings/pub?id=16gsjc81Ptb5SL090XYAN8Kunrxfg6lScNCo3aReqdJI&w=873&h=801
|
||||
|
||||
|
||||
Storage Nodes
|
||||
+++++++++++++
|
||||
|
||||
|
||||
In this OpenStack cluster reference architecture, shared storage acts
|
||||
as a backend for Glance, so that multiple Glance instances running on
|
||||
controller nodes can store images and retrieve images from it. To
|
||||
|
|
|
|||
|
|
@ -7,35 +7,26 @@ OpenStack deployments on a medium and large scale when you can afford
|
|||
allocating several servers for your OpenStack controller nodes in
|
||||
order to build a fully redundant and highly available environment.
|
||||
|
||||
|
||||
|
||||
The absolute minimum requirement for a highly-available OpenStack
|
||||
deployment is to allocate 4 nodes:
|
||||
|
||||
|
||||
* 3 controller nodes, combined with storage
|
||||
* 1 compute node
|
||||
|
||||
|
||||
.. image:: https://docs.google.com/drawings/pub?id=19Dk1qD5V50-N0KX4kdG_0EhGUBP7D_kLi2dU6caL9AM&w=767&h=413
|
||||
|
||||
|
||||
If you want to run storage separately from the controllers, you can do that as well by raising the bar to 7 nodes:
|
||||
|
||||
* 3 controller nodes
|
||||
* 3 storage nodes
|
||||
* 1 compute node
|
||||
|
||||
|
||||
.. image:: https://docs.google.com/drawings/pub?id=1xmGUrk2U-YWmtoS77xqG0tzO3A47p6cI3mMbzLKG8tY&w=769&h=594
|
||||
|
||||
|
||||
Of course, you are free to choose how to deploy OpenStack based on the
|
||||
amount of available hardware and on your goals (such as whether you
|
||||
want a compute-oriented or storage-oriented cluster).
|
||||
|
||||
|
||||
|
||||
For a typical OpenStack compute deployment, you can use this table as
|
||||
high-level guidance to determine the number of controllers, compute,
|
||||
and storage nodes you should have:
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
Network Architecture
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
The current architecture assumes the presence of 3 NIC cards in hardware, but can be customized two or more NICs. Most servers come with at least two network interfaces. In this case, let's consider a typical example of three NIC cards. They're utilized as follows:
|
||||
|
||||
* **eth0**: the internal management network, used for communication with Puppet & Cobbler
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
v3.0-grizzly
|
||||
^^^^^^^^^^^^
|
||||
|
||||
**New Features in Fuel and Fuel Web 3.0**
|
||||
**New Features in Fuel and FuelWeb 3.0**
|
||||
|
||||
* Support for OpenStack Grizzly
|
||||
* Support for CentOS 6.4
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
v3.1-grizzly
|
||||
^^^^^^^^^^^^
|
||||
|
||||
**New Features in Fuel and FuelWeb 3.1**
|
||||
|
||||
PLACEHOLDER
|
||||
Loading…
Reference in New Issue