docs restructured. grammar and syntax fixes
This commit is contained in:
Pavel Lechenko
parent
458ccd392d
commit
3f296834ac
Binary file not shown.
|
After Width: | Height: | Size: 55 KiB |
|
Before Width: | Height: | Size: 57 KiB After Width: | Height: | Size: 57 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 49 KiB |
|
Before Width: | Height: | Size: 45 KiB After Width: | Height: | Size: 45 KiB |
|
|
@ -1,3 +1,4 @@
|
|||
.. index:: About Fuel
|
||||
.. _About_Fuel:
|
||||
|
||||
============
|
||||
14
contents.rst
14
contents.rst
|
|
@ -6,11 +6,11 @@
|
|||
:maxdepth: 2
|
||||
|
||||
index
|
||||
0020-about-fuel
|
||||
0030-release-notes
|
||||
0040-reference-architecture
|
||||
0055-production-considerations
|
||||
0045-installation-fuel-ui
|
||||
0050-installation-fuel-cli
|
||||
0060-frequently-asked-questions
|
||||
about-fuel
|
||||
release-notes
|
||||
reference-architecture
|
||||
production-considerations
|
||||
installation-fuel-ui
|
||||
installation-fuel-cli
|
||||
frequently-asked-questions
|
||||
copyright
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
.. index:: License
|
||||
.. index:: Fuel License
|
||||
|
||||
============
|
||||
Fuel License
|
||||
============
|
||||
|
||||
.. literalinclude:: LICENSE
|
||||
:language: none
|
||||
:language: none
|
||||
|
|
@ -6,6 +6,8 @@
|
|||
Create an OpenStack cluster using Fuel UI
|
||||
============================================
|
||||
|
||||
Now let's look at performing an actual OpenStack deployment using Fuel.
|
||||
|
||||
.. contents:: :local:
|
||||
:depth: 2
|
||||
|
||||
|
|
@ -14,4 +16,4 @@ Create an OpenStack cluster using Fuel UI
|
|||
.. include:: /pages/installation-fuel-ui/network-issues.rst
|
||||
.. include:: /pages/installation-fuel-ui/red_hat_openstack.rst
|
||||
.. include:: /pages/installation-fuel-ui/post-install-healthchecks.rst
|
||||
.. include:: /pages/installation-fuel-ui/network-issues.rst
|
||||
.. include /pages/installation-fuel-ui/network-issues.rst
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
.. index: Supported Software; Components
|
||||
.. index:: Supported Software Components
|
||||
|
||||
Supported Software
|
||||
==================
|
||||
Supported Software Components
|
||||
=============================
|
||||
|
||||
Fuel has been tested and is guaranteed to work with the following software
|
||||
components:
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
.. index: Download Fuel
|
||||
.. index:: Download Fuel
|
||||
|
||||
Download Fuel
|
||||
=============
|
||||
|
|
|
|||
|
|
@ -190,12 +190,12 @@ Next, create Slave nodes where OpenStack needs to be installed.
|
|||
|
||||
2. Set priority for the network boot:
|
||||
|
||||
.. image:: /_images/vbox-image1.jpg
|
||||
.. image:: /_images/vbox-image1.png
|
||||
:align: center
|
||||
|
||||
3. Configure the network adapter on each VM:
|
||||
|
||||
.. image:: /_images/vbox-image2.jpg
|
||||
.. image:: /_images/vbox-image2.png
|
||||
:align: center
|
||||
|
||||
Changing network parameters before the installation
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
.. index:: Fuel UI; Network Issues
|
||||
.. index:: Fuel UI: Network Issues
|
||||
|
||||
Network Issues
|
||||
==============
|
||||
|
|
|
|||
|
|
@ -1,8 +0,0 @@
|
|||
Fuel simplifies the set up of an OpenStack cluster, affording you the ability
|
||||
to dig in and fully understand how OpenStack works. You can deploy on test
|
||||
hardware or in a virtualized environment and root around all you like, but
|
||||
when it comes time to deploy to production there are a few things to take
|
||||
into consideration.
|
||||
|
||||
In this section we will talk about such things including how to size your
|
||||
hardware and how to handle large-scale deployments.
|
||||
|
|
@ -2,8 +2,8 @@
|
|||
|
||||
.. _Sizing_Hardware:
|
||||
|
||||
Sizing Hardware
|
||||
===============
|
||||
Sizing Hardware for Production Deployment
|
||||
=========================================
|
||||
|
||||
.. contents :local:
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ Puppet supports assigning nodes 'environments'. These environments can be
|
|||
mapped directly to your development, QA and production life cycles, so it’s a
|
||||
way to distribute code to nodes that are assigned to those environments.
|
||||
|
||||
* On the Master node
|
||||
**On the Master node:**
|
||||
|
||||
The Puppet Master tries to find modules using its ``modulepath`` setting,
|
||||
which by default is ``/etc/puppet/modules``. It is common practice to set
|
||||
|
|
@ -48,7 +48,7 @@ way to distribute code to nodes that are assigned to those environments.
|
|||
[development]
|
||||
manifest = $confdir/$environment/manifests/site.pp
|
||||
|
||||
* On the Slave Node
|
||||
**On the Slave Node:**
|
||||
|
||||
Once the slave node makes a request, the Puppet Master gets informed of its
|
||||
environment. If you don’t specify an environment, the agent uses the default
|
||||
|
|
@ -65,22 +65,21 @@ way to distribute code to nodes that are assigned to those environments.
|
|||
Deployment pipeline
|
||||
-------------------
|
||||
|
||||
* Deploy
|
||||
1. Deploy
|
||||
|
||||
In order to deploy multiple environments that don't interfere with each other,
|
||||
you should specify the ``$deployment_id`` option in
|
||||
``/etc/puppet/manifests/site.pp``. It should be an even integer value in the
|
||||
range of 2-254.
|
||||
you should specify the ``deployment_id`` option in YAML file.
|
||||
It should be an even integer value in the range of 2-254.
|
||||
|
||||
This value is used in dynamic environment-based tag generation. Fuel applies
|
||||
that tag globally to all resources and some services on each node.
|
||||
|
||||
* Clean/Revert
|
||||
2. Clean/Revert
|
||||
|
||||
At this stage you just need to make sure the environment has the
|
||||
original/virgin state.
|
||||
|
||||
* Puppet node deactivate
|
||||
3. Puppet node deactivate
|
||||
|
||||
This will ensure that any resources exported by that node will stop appearing
|
||||
in the catalogs served to the slave nodes::
|
||||
|
|
@ -95,7 +94,7 @@ Deployment pipeline
|
|||
|
||||
cert list --all | awk '! /DNS:puppet/ { gsub(/"/, "", $2); print $2}' | xargs puppet node deactivate
|
||||
|
||||
* Redeploy
|
||||
4. Redeploy
|
||||
|
||||
Start the puppet agent again to apply a desired node configuration.
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,8 @@ profiles and distributions. Similarly, Puppet Master can be kept in sync with a
|
|||
combination of rsync (for modules, manifests, and SSL data) and database
|
||||
replication.
|
||||
|
||||
.. image:: /_images/cobbler-puppet-ha.jpg
|
||||
..
|
||||
image:: /_images/cobbler-puppet-ha.jpg
|
||||
:align: center
|
||||
|
||||
Downloading of operating systems and other software
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
.. index:: Deployment Configurations
|
||||
.. index Reference Architectures
|
||||
|
||||
Overview
|
||||
========
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
.. index:: Deployment Configurations; Non-HA Simple
|
||||
.. index:: Reference Architectures: Non-HA Simple, Non-HA Simple
|
||||
|
||||
.. _Simple:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
.. index:: Deployment Configurations; HA Compact
|
||||
.. index:: Reference Architectures: HA Compact, HA Compact
|
||||
|
||||
.. _HA_Compact:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
.. index:: Deployment Configurations; HA Compact Details
|
||||
.. index:: Reference Architectures: HA Compact Details, HA Compact Details
|
||||
|
||||
.. _Close_look_Compact:
|
||||
|
||||
|
|
@ -15,9 +15,9 @@ recall, this configuration looks something like this:
|
|||
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)
|
||||
management using keepalived and load balancing using HAProxy. Stateful
|
||||
management using Pacemaker and load balancing using HAProxy. Stateful
|
||||
OpenStack components, such as the state database and messaging server,
|
||||
rely on their respective active/active modes for high availability.
|
||||
rely on their respective active/active and active/passive modes for high availability.
|
||||
For example, RabbitMQ uses built-in clustering capabilities, while the
|
||||
database uses MySQL/Galera replication.
|
||||
|
||||
|
|
@ -25,6 +25,5 @@ database uses MySQL/Galera replication.
|
|||
:align: center
|
||||
|
||||
Lets take a closer look at what an OpenStack deployment looks like, and
|
||||
what it will take to achieve high availability for an OpenStack
|
||||
deployment.
|
||||
what it will take to achieve high availability for an OpenStack deployment.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
.. index:: Deployment Configurations; HA Full
|
||||
.. index:: Reference Architectures: HA Full, HA Full
|
||||
|
||||
.. _HA_Full:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
.. index:: Deployment Configurations; Red Hat OpenStack
|
||||
.. index:: Reference Architectures: RHOS, Red Hat OpenStack Architecture
|
||||
|
||||
Red Hat OpenStack Architectures
|
||||
===============================
|
||||
|
|
@ -31,7 +31,8 @@ Below is the list of modifications:
|
|||
fixed in a future release. As a result, Fuel for Red Hat OpenStack
|
||||
Platform will only support Nova networking.
|
||||
|
||||
.. index:: Deployment Configurations; Red Hat OpenStack; RHOS Non-HA Simple
|
||||
.. index:: Reference Architectures: RHOS Non-HA Simple, RHOS Non-HA Simple
|
||||
.. index Deployment Configurations; Red Hat OpenStack; RHOS Non-HA Simple
|
||||
|
||||
.. _RHOS_Simple:
|
||||
|
||||
|
|
@ -55,7 +56,8 @@ enable you to achieve this separation while still keeping your
|
|||
hardware investment relatively modest is to house your storage on your
|
||||
controller nodes.
|
||||
|
||||
.. index:: Deployment Configurations; Red Hat OpenStack; RHOS HA Compact
|
||||
.. index:: Reference Architectures: RHOS HA Compact, RHOS HA Compact
|
||||
.. index Deployment Configurations; Red Hat OpenStack; RHOS HA Compact
|
||||
|
||||
.. _RHOS_Compact:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,8 @@
|
|||
Logical Setup
|
||||
=============
|
||||
.. index:: Reference Architectures: HA Logical Setup, HA Logical Setup
|
||||
|
||||
HA Logical Setup
|
||||
================
|
||||
|
||||
.. contents :local:
|
||||
|
||||
An OpenStack HA cluster involves, at a minimum, three types of nodes:
|
||||
|
|
|
|||
|
|
@ -29,6 +29,8 @@ relevant nodes and networks.
|
|||
|
||||
Lets take a closer look at each network and how its used within the cluster.
|
||||
|
||||
.. index:: Public Network
|
||||
|
||||
Public Network
|
||||
--------------
|
||||
|
||||
|
|
@ -57,6 +59,8 @@ performed for traffic going from VM instances on the compute node to Internet.
|
|||
The public network also provides VIPs for Endpoint nodes, which are used to
|
||||
connect to OpenStack services APIs.
|
||||
|
||||
.. index:: Internal Network, Management Network
|
||||
|
||||
Internal (Management) Network
|
||||
-----------------------------
|
||||
|
||||
|
|
@ -71,6 +75,8 @@ between Compute and Storage nodes.
|
|||
This network usually is a single C class network from your private, non-globally
|
||||
routed IP address range.
|
||||
|
||||
.. index:: Private Network
|
||||
|
||||
Private Network
|
||||
---------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
.. index:: Neutron vs. nova-network, Quantum vs. nova-network
|
||||
|
||||
Neutron vs. nova-network
|
||||
========================
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
.. index:: Cinder vs. nova-volume
|
||||
|
||||
Cinder vs. nova-volume
|
||||
======================
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
.. index:: Object storage, Swift
|
||||
.. index:: Object storage, Swift, Glance
|
||||
|
||||
.. _Swift-and-object-storage-notes:
|
||||
|
||||
|
|
@ -21,5 +21,3 @@ Fuel currently supports several scenarios to deploy the object storage:
|
|||
reside on separate nodes, with two proxy nodes and a minimum of three storage
|
||||
nodes.
|
||||
|
||||
Now let's look at performing an actual OpenStack deployment using Fuel.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
HA with Pacemaker and Corosync
|
||||
==============================
|
||||
|
||||
.. index:: HA with Pacemaker and Corosync; Corosync settings
|
||||
.. index:: Corosync settings
|
||||
|
||||
Corosync settings
|
||||
-----------------
|
||||
|
|
@ -50,7 +50,7 @@ corosync configuration, which can also be altered in Fuel manifests.
|
|||
http://clusterlabs.org/doc/ if you want to know how to tune installation
|
||||
completely
|
||||
|
||||
.. index:: HA with Pacemaker and Corosync; Pacemaker settings
|
||||
.. index:: Pacemaker settings
|
||||
|
||||
Pacemaker settings
|
||||
------------------
|
||||
|
|
@ -79,7 +79,7 @@ booted to participate in such election. Every node is a self-aware, that means
|
|||
if nobody pushes higher epoch that it retrieved from corosync(neither no one did),
|
||||
it will just elect itself as a master.
|
||||
|
||||
.. index:: HA with Pacemaker and Corosync; How Fuel Deploys HA
|
||||
.. index:: How Fuel Deploys HA
|
||||
|
||||
How Fuel Deploys HA
|
||||
-------------------
|
||||
|
|
@ -153,7 +153,7 @@ And ties them with pacemaker colocation resource::
|
|||
order l3-after-metadata inf: clone_p_quantum-metadata-agent p_quantum-l3-agent
|
||||
order l3-after-ovs inf: clone_p_quantum-openvswitch-agent p_quantum-l3-agent
|
||||
|
||||
.. index:: HA with Pacemaker and Corosync; How To Troubleshoot Corosync/Pacemaker
|
||||
.. index:: HowTo: Troubleshoot Corosync/Pacemaker
|
||||
|
||||
How To Troubleshoot Corosync/Pacemaker
|
||||
--------------------------------------
|
||||
|
|
@ -275,7 +275,7 @@ There are several points:
|
|||
|
||||
2) corosync should start after network interfaces are configured
|
||||
|
||||
3) bindnetaddr should be in the management network or at least in the same
|
||||
3) `bindnetaddr` should be in the management network or at least in the same
|
||||
multicast reachable segment
|
||||
|
||||
You can check this in output of ``ip maddr show``:
|
||||
|
|
@ -315,7 +315,7 @@ If there is only one IP in members list that means there is corosync connectivit
|
|||
issue because the node does not see the other ones. The same stays for the case
|
||||
when members list is incomplete.
|
||||
|
||||
.. index:: HA with Pacemaker and Corosync; How To smoke test HA
|
||||
.. index:: HowTo: Smoke Test HA
|
||||
|
||||
How To Smoke Test HA
|
||||
--------------------
|
||||
|
|
|
|||
|
|
@ -18,8 +18,6 @@ hardware and how to handle large-scale deployments.
|
|||
.. contents:: :local:
|
||||
:depth: 2
|
||||
|
||||
.. include /pages/production-considerations/0010-introduction.rst
|
||||
.. include:: /pages/production-considerations/0015-sizing-hardware.rst
|
||||
.. include:: /pages/production-considerations/0020-deployment-pipeline.rst
|
||||
.. include:: /pages/production-considerations/0030-large-deployments.rst
|
||||
.. include /pages/production-considerations/0040-post-install-healthchecks.rst
|
||||
Loading…
Reference in New Issue