openstack/fuel-docs
Code Issues Proposed changes

merge fix

Browse Source
This commit is contained in:
Matthew Mosesohn 2013-10-09 12:59:05 +04:00
parent 9c7fbb76ba
commit cf1d070e6b
6 changed files with 117 additions and 112 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
pages/frequently-asked-questions/0080-other-questions.rst
View File

@ -12,15 +12,15 @@ Other Questions
**[A]** We are fully committed to providing our customers with working and **[A]** We are fully committed to providing our customers with working and
stable bits and pieces in order to make successful OpenStack deployments. stable bits and pieces in order to make successful OpenStack deployments.
Please note that we do not distribute our own version of OpenStack; we rather Please note that we do not distribute our own version of OpenStack; we rather
provide a plain vanilla distribution. As such, there is no vendor lock-in. provide a plain vanilla distribution. Put simply, there is no vendor lock-in
For convenience, our repository maintains the history of OpenStack packages with Fuel. For your convenience, we maintain repositories containing a
certified to work with our Puppet manifests. history of OpenStack packages certified to work with our Puppet manifests.
The advantage of this approach is that you can install any OpenStack version The advantage of this approach is that you can install any OpenStack version
you want. If you are running Essex, just use the Puppet manifests which you want (with possible custom big fixes). Even if you are running Essex,
reference OpenStack packages for Essex from our repository. With each new just use the Puppet manifests which reference OpenStack packages for Essex
release we add new OpenStack packages to our repository and created a from our repository. With each new release we add new OpenStack packages to
separate branch with the Puppet manifests (which, in turn, reference these our repository and create a new branch with Puppet manifests (which, in
packages) corresponding to each release. With EPEL this would not be turn, reference these packages) corresponding to each release. With EPEL
possible, as that repository only keeps the latest version for OpenStack this would not be possible, as that repository only keeps the latest version
packages. for OpenStack packages.

90
pages/install-guide/0015-sizing-hardware.rst
View File

@ -14,16 +14,16 @@ Sizing Hardware for Production Deployment
One of the first questions people ask when planning an OpenStack deployment is 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 "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 answer, but there are straightforward rules to selecting appropriate hardware
that will suit your needs. The Golden Rule, however, is to always accommodate that will suit your needs. The Golden Rule, however, is to always plan
for growth. With the potential for growth accounted for, you can move on to the for growth. With the potential for growth in your design, you can move onto
actual hardware needs. your actual hardware needs.
Many factors contribute to selecting hardware for an OpenStack cluster -- Many factors contribute to selecting hardware for an OpenStack cluster --
`contact Mirantis <http://www.mirantis.com/contact/>`_ for information on your `contact Mirantis <http://www.mirantis.com/contact/>`_ for information on your
specific requirements -- but in general, you will want to consider the following specific requirements -- but in general, you will want to consider the following
factors: factors:
* Processing * Processing power
* Memory * Memory
* Storage * Storage
* Networking * Networking
@ -31,8 +31,8 @@ factors:
Your needs in each of these areas are going to determine your overall hardware Your needs in each of these areas are going to determine your overall hardware
requirements. requirements.
Processing Processing Power
---------- ----------------
In order to calculate how much processing power you need to acquire you will In order to calculate how much processing power you need to acquire you will
need to determine the number of VMs your cloud will support. You must also need to determine the number of VMs your cloud will support. You must also
@ -56,7 +56,7 @@ density" of 17 VMs per server (102 VMs / 6 servers).
This process also accommodates growth since you now know what a single server This process also accommodates growth since you now know what a single server
using this CPU configuration can support. You can add new servers accounting using this CPU configuration can support. You can add new servers accounting
for 17 VMs each as needed without having to re-calculate. for 17 VMs each as needed without needing to re-calculate.
You will also need to take into account the following: You will also need to take into account the following:
@ -69,34 +69,35 @@ Memory
Continuing to use the example from the previous section, we need to determine Continuing to use the example from the previous section, we need to determine
how much RAM will be required to support 17 VMs per server. Let's assume that how much RAM will be required to support 17 VMs per server. Let's assume that
you need an average of 4 GBs of RAM per VM with dynamic allocation for up to you need an average of 4 GB of RAM per VM with dynamic allocation for up to
12GBs for each VM. Calculating that all VMs will be using 12 GBs of RAM requires 12 GB for each VM. Calculating that all VMs will be using 12 GB of RAM requires
that each server have 204 GBs of available RAM. that each server have 204 GB of available RAM.
You must also consider that the node itself needs sufficient RAM to accommodate You must also consider that the node itself needs sufficient RAM to accommodate
core OS operations as well as RAM for each VM container (not the RAM allocated core OS operations as well as the RAM necessary for each VM container (not the
to each VM, but the memory the core OS uses to run the VM). The node's OS must RAM allocated to each VM, but the memory the core OS uses to run the VM). The
run it's own operations, schedule processes, allocate dynamic resources, and node's OS must run it's own operations, schedule processes, allocate dynamic
handle network operations, so giving the node itself at least 16 GBs or more RAM resources, and handle network operations, so giving the node itself at least
is not unreasonable. 16 GB or more available RAM is within reason.
Considering that the RAM we would consider for servers comes in 4 GB, 8 GB, 16 GB Considering that the RAM we would consider for servers comes in 4 GB, 8 GB, 16 GB
and 32 GB sticks, we would need a total of 256 GBs of RAM installed per server. and 32 GB sticks, we would need a total of 256 GB of RAM installed per server.
For an average 2-CPU socket server board you get 16-24 RAM slots. To have For an average 2-CPU socket server board you get 16-24 RAM slots. To have
256 GBs installed you would need sixteen 16 GB sticks of RAM to satisfy your RAM 256 GB installed you would need sixteen 16 GB sticks of RAM to satisfy your RAM
needs for up to 17 VMs requiring dynamic allocation up to 12 GBs and to support needs for up to 17 VMs requiring dynamic allocation up to 12 GB and to support
all core OS requirements. all core OS requirements.
You can adjust this calculation based on your needs. You can adjust this calculation based on your needs.
Storage Space Storage Space
------------- -------------
When it comes to disk space there are several types that you need to consider: With regards to disk requirements, there are several types of storage that
you need to consider:
* Ephemeral (the local drive space for a VM) * Ephemeral (local disk for a VM)
* Persistent (the remote volumes that can be attached to a VM) * Persistent (remote volumes which can be attached to a VM)
* Object Storage (such as images or other objects) * Object Storage (such as images, documents, or other objects)
As far as local drive space that must reside on the compute nodes, in our As far as local drive space that must reside on the compute nodes, in our
example of 100 VMs we make the following assumptions: example of 100 VMs we make the following assumptions:
@ -108,19 +109,19 @@ example of 100 VMs we make the following assumptions:
Returning to our already established example, we need to figure out how much Returning to our already established example, we need to figure out how much
storage to install per server. This storage will service the 17 VMs per server. storage to install per server. This storage will service the 17 VMs per server.
If we are assuming 50 GBs of storage for each VMs drive container, then we would If we are assuming 50 GB of storage for each VM's drive container, then we
need to install 2.5 TBs of storage on the server. Since most servers have would need to outfit 2.5 TB of storage on the server. Since most servers have
anywhere from 4 to 32 2.5" drive slots or 2 to 12 3.5" drive slots, depending on anywhere from 4 to 32 2.5" disk bays or 2 to 12 3.5" disk bays, depending on
server form factor (i.e., 2U vs. 4U), you will need to consider how the storage server form factor (i.e., 2U vs. 4U), you will need to consider how the storage
will be impacted by the intended use. will be impacted by the intended use.
If storage impact is not expected to be significant, then you may consider using If the storage impact is not expected to be significant, then you may consider
unified storage. For this example a single 3 TB drive would provide more than using unified storage. For this example, a single 3 TB drive would provide
enough storage for seventeen 150 GB VMs. If speed is really not an issue, you might even more than enough storage for seventeen 150 GB VMs. If speed is not a major
consider installing two or three 3 TB drives and configure a RAID-1 or RAID-5 concern an issue, you may even consider installing two or three 3 TB drives and
for redundancy. If speed is critical, however, you will likely want to have a configuring a RAID-1 or RAID-5 setup for redundancy. If speed is critical,
single hardware drive for each VM. In this case you would likely look at a 3U however, you will likely want to have a single physical disk for each VM. In
form factor with 24-slots. this case you would likely look at a 3U form factor with 24 disk bays.
Don't forget that you will also need drive space for the node itself, and don't Don't forget that you will also need drive space for the node itself, and don't
forget to order the correct backplane that supports the drive configuration forget to order the correct backplane that supports the drive configuration
@ -131,7 +132,7 @@ it critical, a single server would need 18 drives, most likely 2.5" 15,000 RPM
Throughput Throughput
++++++++++ ++++++++++
As far as throughput, that's going to depend on what kind of storage you choose. Regarding throughput, it depends on what kind of storage you choose.
In general, you calculate IOPS based on the packing density (drive IOPS * drives In general, you calculate IOPS based on the packing density (drive IOPS * drives
in the server / VMs per server), but the actual drive IOPS will depend on the in the server / VMs per server), but the actual drive IOPS will depend on the
drive technology you choose. For example: drive technology you choose. For example:
@ -209,20 +210,19 @@ drives begin to fill up. That calculates to 200 TB in our example. So how do
you put that together? If you were to use 3 TB 3.5" drives, you could use a 12 you put that together? If you were to use 3 TB 3.5" drives, you could use a 12
drive storage frame, with 6 servers hosting 36 TB each (for a total of 216 TB). drive storage frame, with 6 servers hosting 36 TB each (for a total of 216 TB).
You could also use a 36 drive storage frame, with just 2 servers hosting 108 TB You could also use a 36 drive storage frame, with just 2 servers hosting 108 TB
each, but its not recommended due to the high cost of failure to replication each, but its not recommended due to the high cost of failed replication
and capacity issues. and capacity issues.
Networking Networking
---------- ----------
Perhaps the most complex part of designing an OpenStack cluster is the Perhaps the most complex part of designing an OpenStack cluster is networking.
networking.
An OpenStack cluster can involve multiple networks even beyond the Public, An OpenStack cluster can involve multiple networks even beyond the required
Private, and Internal networks. Your cluster may involve tenant networks, Public, Private, and Internal networks. Your cluster may involve tenant
storage networks, multiple tenant private networks, and so on. Many of these networks, storage networks, multiple tenant private networks, and so on. Many
will be VLANs, and all of them will need to be planned out in advance to avoid of these will be VLANs, and all of them will need to be planned out in advance
configuration issues. to avoid configuration issues.
In terms of the example network, consider these assumptions: In terms of the example network, consider these assumptions:
@ -249,7 +249,7 @@ that you have 48 x 1 Gb links down, but 4 x 10 Gb links up. Do the same thing wi
resulting in oversubscription. resulting in oversubscription.
Like many other issues in OpenStack, you can avoid this problem to a great Like many other issues in OpenStack, you can avoid this problem to a great
extent with careful planning. Problems only arise when you are moving between extent with sensible planning. Problems only arise when you are moving between
racks, so plan to create "pods", each of which includes both storage and racks, so plan to create "pods", each of which includes both storage and
compute nodes. Generally, a pod is the size of a non-oversubscribed L2 domain. compute nodes. Generally, a pod is the size of a non-oversubscribed L2 domain.
@ -264,7 +264,7 @@ In this example, you are looking at:
* Optional Cluster Management switch, plus a second for HA * Optional Cluster Management switch, plus a second for HA
Because your network will in all likelihood grow, it's best to choose 48 port Because your network will in all likelihood grow, it's best to choose 48 port
switches. Also, as your network grows, you will need to consider uplinks and switches. Also, as your network expands, you will need to consider uplinks and
aggregation switches. aggregation switches.
Summary Summary
@ -281,4 +281,4 @@ from Dell for compute nodes include:
You may also want to consider systems from HP (http://www.hp.com/servers) or You may also want to consider systems from HP (http://www.hp.com/servers) or
from a smaller systems builder like Aberdeen, a manufacturer that specializes from a smaller systems builder like Aberdeen, a manufacturer that specializes
in powerful, low-cost systems and storage servers (http://www.aberdeeninc.com). in powerful, low-cost systems and storage servers (http://www.aberdeeninc.com).

28
pages/install-guide/0030-how-it-works.rst
View File

@ -11,7 +11,7 @@ How Fuel Works
Fuel is a ready-to-install collection of the packages and scripts you need Fuel is a ready-to-install collection of the packages and scripts you need
to create a robust, configurable, vendor-independent OpenStack cloud in your to create a robust, configurable, vendor-independent OpenStack cloud in your
own environment. As of Fuel 3.1, Fuel Library and Fuel Web have been merged own environment. Since Fuel 3.1, Fuel Library and Fuel Web have been merged
into a single toolbox with options to use the UI or CLI for management. into a single toolbox with options to use the UI or CLI for management.
A single OpenStack cloud consists of packages from many different open source A single OpenStack cloud consists of packages from many different open source
@ -27,33 +27,33 @@ OpenStack-based infrastructure in your own environment.
.. image:: /_images/FuelSimpleDiagram.jpg .. image:: /_images/FuelSimpleDiagram.jpg
:align: center :align: center
Fuel works on a simple premise. Rather than installing each of the Fuel works by using a simple approach. Rather than installing each of the
components that make up OpenStack directly, you instead use a configuration components that make up OpenStack directly, it instead uses a configuration
management system like Puppet to create scripts that can provide a management system (Puppet) to compile a set of instructions that can provide a
configurable, reproducible, sharable installation process. configurable, reproducible, and sharable installation process.
In practice, Fuel works as follows: In practice, Fuel works as follows:
1. First, set up Fuel Master Node using the ISO. This process only needs to 1. First, set up Fuel Master node using the ISO. This process only needs to
be completed once per installation. be completed once per installation.
2. Next, discover your virtual or physical nodes and configure your 2. Next, discover your virtual or physical nodes and configure your
OpenStack cluster using the Fuel UI. OpenStack cluster using the Fuel UI.
3. Finally, deploy your OpenStack cluster on discovered nodes. Fuel will 3. Finally, deploy your OpenStack cluster on discovered nodes. Fuel will
perform all deployment magic for you by applying pre-configured and perform all deployment steps for you by applying pre-configured and
pre-integrated Puppet manifests via Astute orchestration engine. pre-integrated Puppet manifests via Astute orchestration engine.
Fuel is designed to enable you to maintain your cluster while giving you the Fuel is designed to enable you to maintain your cluster while giving you the
flexibility to adapt it to your own configuration. flexibility to adapt it to your own business needs and scale.
.. image:: /_images/how-it-works_svg.jpg .. image:: /_images/how-it-works_svg.jpg
:align: center :align: center
Fuel comes with several pre-defined deployment configurations, some of them Fuel comes with several pre-defined deployment configurations, plus
include additional configuration options that allow you to adapt OpenStack additional options that allow you to adapt your OpenStack deployment to your
deployment to your environment. environment.
Fuel UI integrates all of the deployments scripts into a unified, Fuel UI integrates all of the deployments scripts into a unified, web-based
Web-based Graphical User Interface that walks administrators through the interface that walks administrators through the process of installing and
process of installing and configuring a fully functional OpenStack environment. configuring a fully functional OpenStack environment.

22
pages/install-guide/0040-reference-topologies.rst
View File

@ -11,20 +11,20 @@ Deployment Configurations Provided By Fuel
One of the advantages of Fuel is that it comes with a number of pre-built 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 deployment configurations that you can use to quickly build your own
OpenStack cloud infrastructure. These are well-specified configurations of OpenStack cloud infrastructure. These are widely accepted configurations of
OpenStack and its constituent components that are expertly tailored to one OpenStack, with its constituent components expertly tailored to serve
or more common cloud use cases. Fuel provides the ability to create the multipurpose cloud use cases. Fuel provides the ability to create the
following cluster types without requiring extensive customization: following cluster types directly out of the box:
**Simple (non-HA)**: The Simple (non-HA) installation provides an easy way **Simple (non-HA)**: The Simple (non-HA) installation provides an easy way
to install an entire OpenStack cluster without requiring the degree of to install an entire OpenStack cluster without requiring the expense of
increased hardware involved in ensuring high availability. extra hardware required to ensure high availability.
**Multi-node (HA)**: When you're ready to begin your move to production, the **Multi-node (HA)**: When you are ready to move to production, the Multi-node
Multi-node (HA) configuration is a straightforward way to create an OpenStack (HA) configuration is a straightforward way to create an OpenStack
cluster that provides high availability. With three controller nodes and the cluster that provides high availability. With three controller nodes and the
ability to individually specify services such as Cinder, Neutron (formerly ability to individually specify services such as Cinder, Neutron (formerly
Quantum), and Swift, Fuel provides the following variations of the Quantum), Swift, and Ceph, Fuel provides the following variations of the
Multi-node (HA) configurations: Multi-node (HA) configurations:
- **Compact HA**: When you choose this option, Swift will be installed on - **Compact HA**: When you choose this option, Swift will be installed on
@ -32,8 +32,8 @@ Multi-node (HA) configurations:
for additional Swift servers while still addressing high availability for additional Swift servers while still addressing high availability
requirements. requirements.
- **Full HA**: This option enables you to install independent Swift and Proxy - **Full HA**: This option enables you to install dedicated Cinder or Ceph
nodes, so that you can separate their operation from your controller nodes. nodes, so that you can separate their operations from your controller nodes.
In addition to these configurations, Fuel is designed to be completely In addition to these configurations, Fuel is designed to be completely
customizable. For assistance on deeper customization options based on the customizable. For assistance on deeper customization options based on the

2
pages/install-guide/0050-supported-software.rst
View File

@ -35,7 +35,7 @@ components:
* Hypervisor * Hypervisor
* KVM * KVM
* QEMU * QEMU
* Open vSwitch * Open vSwitch

67
pages/install-guide/install.rst
View File

@ -9,9 +9,10 @@ Installing Fuel Master Node
.. contents :local: .. contents :local:
Fuel is distributed as both ISO and IMG images, each of them contains Fuel is distributed via both ISO and IMG images. Eac contains an installer for
an installer for Fuel Master node. The ISO image is used for CD media devices, Fuel Master node. The ISO image is used for CD media devices, iLO (HP) or
iLO or similar remote access systems. The IMG file is used for USB memory sticks. similar remote access systems. The IMG file is used for USB memory stick-based
installation.
Once installed, Fuel can be used to deploy and manage OpenStack clusters. It Once installed, Fuel can be used to deploy and manage OpenStack clusters. It
will assign IP addresses to the nodes, perform PXE boot and initial will assign IP addresses to the nodes, perform PXE boot and initial
@ -20,47 +21,49 @@ the cluster.
.. _Install_Bare-Metal: .. _Install_Bare-Metal:
On Bare-Metal Environment Bare-Metal Environment
------------------------- ----------------------
To install Fuel on bare-metal hardware, you need to burn the provided ISO to To install Fuel on bare-metal hardware, you need to burn the provided ISO to
a CD/DVD or create a bootable USB stick. You would then begin the a writeable DVD or create a bootable USB stick. You would then begin the
installation process by booting from that media, very much like any other OS. installation process by booting from that media, very much like any other OS
install process.
Burning an ISO to optical media is a deeply supported function on all OSes. Burning an ISO to optical media is a commonly supported function on all OSes.
For Linux there are several interfaces available such as `Brasero` or `Xfburn`, On Linux, there are several programs available, such as `Brasero` or `Xfburn`,
two of the more commonly pre-installed desktop applications. There are also two commonly pre-installed desktop applications. There are also
a number for Windows such as `ImgBurn <http://www.imgburn.com/>`_ and the a number for Windows such as `ImgBurn <http://www.imgburn.com/>`_ and the
open source `InfraRecorder <http://infrarecorder.org/>`_. open source `InfraRecorder <http://infrarecorder.org/>`_.
Burning an ISO in Mac OS X is deceptively simple. Open `Disk Utility` from Burning an ISO in Mac OS X is quite simple. Open `Disk Utility` from
`Applications > Utilities`, drag the ISO into the disk list on the left side `Applications > Utilities`, drag the ISO into the disk list on the left side
of the window and select it, insert blank media with enough room, and click of the window and select it, insert blank DVD, and click `Burn`. If you prefer
`Burn`. If you prefer a utility, check out the open source `Burn a different utility, check out the open source `Burn
<http://burn-osx.sourceforge.net/Pages/English/home.html>`_. <http://burn-osx.sourceforge.net/Pages/English/home.html>`_.
Installing the ISO to a bootable USB stick, however, is an entirely different Installing the ISO to a bootable USB stick, however, is an entirely different
matter. Canonical suggests `PenDriveLinux` which is a GUI tool for Windows. matter. Canonical suggests `PenDriveLinux` which is a GUI tool for Windows.
On Windows, you can write the installation image with a number of different On Windows, you can write the installation image with a number of different
utilities. The following list links to some of the more popular ones and they are utilities. The following list links to some of the more popular ones and they
all available at no cost: are all available at no cost:
- `Win32 Disk Imager <http://sourceforge.net/projects/win32diskimager/>`_. - `Win32 Disk Imager <http://sourceforge.net/projects/win32diskimager/>`_.
- `ISOtoUSB <http://www.isotousb.com/>`_. - `ISOtoUSB <http://www.isotousb.com/>`_.
After the installation is complete, you will need to allocate bare-metal After the installation is complete, you will need to make your bare-metal nodes
nodes for your OpenStack cluster, put them on the same L2 network as the available for your OpenStack cluster. Attach them to the same L2 network
Master node, and PXE boot. The UI will discover them and make them available (broadcast domain) as the Master node, and configure them to automatically
for installing OpenStack. boot via network. The UI will discover them and make them available for
installing OpenStack.
On VirtualBox VirtualBox
------------- ----------
If you are going to evaluate Fuel on VirtualBox, you should know that we If you would like to evaluate Fuel on VirtualBox, you can take advantage of the
provide a set of scripts that create and configure all of the required VMs for included set of scripts that create and configure all the required VMs for a
you, including the Master node and Slave nodes for OpenStack itself. It's a very test environment, including the Master node and Slave nodes for OpenStack
simple, single-click installation. itself. It is a simple, single-click installation.
.. note:: .. note::
@ -71,15 +74,17 @@ simple, single-click installation.
The requirements for running Fuel on VirtualBox are: The requirements for running Fuel on VirtualBox are:
A host machine with Linux or Mac OS. A host machine with Linux or Mac OS.
The scripts have been tested on Mac OS 10.7.5, Mac OS 10.8.3, Ubuntu 12.04 and Ubuntu 12.10. The scripts have been tested on Mac OS 10.7.5, Mac OS 10.8.3, Ubuntu 12.04,
Ubuntu 12.10, and Fedora 19.
VirtualBox 4.2.12 (or later) must be installed with the extension pack. Both VirtualBox 4.2.12 (or later) must be installed, along with the extension pack.
can be downloaded from `<http://www.virtualbox.org/>`_. Both can be downloaded from `<http://www.virtualbox.org/>`_.
8 GB+ of RAM 8 GB+ of RAM
to handle 4 VMs for non-HA OpenStack installation (1 Master node, 1 Controller Will support 4 VMs for non-HA OpenStack installation (1 Master node,
node, 1 Compute node, 1 Cinder node) or 1 Controller node, 1 Compute node, 1 Cinder node) or
to handle 5 VMs for HA OpenStack installation (1 Master node, 3 Controller
Will support 5 VMs for HA OpenStack installation (1 Master node, 3 Controller
nodes, 1 Compute node) nodes, 1 Compute node)
.. _Install_Automatic: .. _Install_Automatic: