Set up Planning Guide

I started with the "Preparing the MOS Deployment" table
The hardware setup steps have been moved to the Install Guide in another CM
Added a few issues that were not spelled out
Set up separate sections to hold the discussions for each issue.

"Network Topologies" cross-references architectural information in ref-arch
* Andrey Danin provided the "advice"
* Restructuring the network docs became necessary to make this work. To whit:

For Neutron, various structural modifications were required;
no substantive content modifications were made
* Added a couple headers and tags to ref-arch for Neutron topologies
* Deleted files from pre-install/0051-network-plan/topology:
  * 0710-neutron-topologies.rst -- header only, no longer required
  * 0720-neutron-vlan.rst -- duplicates info in ref-arch/neutron-intro/\
    0210-vlan.rst; this had a couple sentences at the end that weren't in
    ref-arch so I moved those over
  * 0730-neutron-gre.rst -- duplicates info in ref-arch/neutron-intro/\
    0220-gre.rst; this had a couple sentences at the end that weren't in
    ref-arch so I moved those over
  * 0760-neutron-vlan-plan.rst and 0780-neutron-gre-plan.rst were pulled
    into ref-arch/0260-neutron-config.rst.  Yes, this leaves one file with
    three headers in it but, when we deal with the content, these pieces
    need to be considered together
* pre-install/0051-network-plan/topology/0700-neutron.rst just sourced the
    above files so is deleted

For Nova, moved the nova-network topology info from pre-install to ref-arch
to parallel the Neutron section we set up there.
* The following files from pre-installation/0051-network-plan/topology/nova
  are now in reference-architecture/nova-intro and sourced from the
  6070-nova-topologies.rst file in reference-architecture.  Section titles
  are also modified to include "Nova-network" to improve readability:
  - 0620-nova-flat-dhcp.rst
  - 0630-nova-vlan.rst
  - 0659-nova-net-plan.rst
  - 0660-nova-plan-flatdhcp.rst
  - 0680-plan-vlan.rst
  - [ignore 0650-nova-assign-networks-to-nics.rst -- it is going to User Guide]
* Other files from this directory are disposed of as follows:
  - 0610-nova-topologies -- sourced ino ref-arch/6070-nova-topologies.rst
    (top file of nova section in ref-arch)
  - 0650-nova-assign-networks-to-nics.rst -- material is obsolete and done
    better in other files now included in user-guide.
* The following files from pre-install/0051-network-plan/0100-netconfig-options are deleted:
  - 0100-netconfig-options (header/intro info no longer needed)
  - 0110- (info pulled into
  - 0200 - sourced files below it that are moved and sourced elsewhere

The same sections that discussed the topologies had information about
routers and switches.  I'm not exactly sure where the best place is
for this but, for now, I'm putting it in ref-arch right after the write-up
about Public and Floating IPs.  Alas, that is in a different commit, and
that other commit creates a sub-directory where these files should go.
So, for now, I created two files in the main ref-arch directory; I will
move these into the proper place after everything is merged.
* 6030-router is based on install-guide/0070-networks/350-router.rst,
  with content also pulled in from pre-install/0051-network-plan/topology/\
  0900-routing-req.rst.  I did some rewriting but the content is unchanged.
  This includes a bunch of Fuel screen shots that I think are superfluous
  but I need to compare them to the rewritten User Guide; I may need to do
  some moving or xref'ing of information.
* 6034-switch.rst is renamed from install-guide/0070-networks/
  300-switch-config.rst.  I did a bit of editing but the content is
  unchanged.
* I had to tag the files with sample switch configurations so I could
  link to them.  I also prefaced each of those titles with either "Nova-network"
  or "Neutron".
* After the above, the following files are deleted:
  * pre-install/0051-network-plan/topology/0900-routing-req (included in
    new routing document)
  * pre-install/0051-network-plan/0200-topology-include.rst -- included files
    that are deleted or moved
  * pre-install/0051-network-plan.rst -- included files that are deleted
    or moved

ref-arch/0030-cluster-sizing.rst is deleted; its content was pulled into
pre-install/nodes-roles.rst.  I added a bit of intro material; the substantive
content is unchanged.

pages/pre-install-guide/4000-plan0summary.rst was a bogus file; is deleted

At Patch 6, I deleted the screen shots from 0060-quick-start-instart-fuel;
this info doesn't belong here anyhow.  I also right-aligned the diagrams in
the Examples and fixed the header levels for the examples at the end of the
document.

Change-Id: Ia4e68200bea2166d48d7691f80cc921459a337ff
This commit is contained in:
Meg McRoberts 2014-05-20 21:21:49 -07:00 committed by Dmitry Borodaenko
parent b528ecfa9a
commit 52550d036c
63 changed files with 561 additions and 490 deletions

View File

@ -1,10 +1,14 @@
.. include:: /pages/pre-install-guide/0010-intro.rst
.. include:: /pages/pre-install-guide/0020-system-requirements.rst
.. include:: /pages/pre-install-guide/0025-supported-software-list.rst
.. include:: /pages/pre-install-guide/4000-planning-summary.rst
.. include:: /pages/pre-install-guide/4100-mode-ha.rst
.. include:: /pages/pre-install-guide/4200-net-topology.rst
.. include:: /pages/pre-install-guide/4300-linux-distro.rst
.. include:: /pages/pre-install-guide/4400-nodes-roles.rst
.. include:: /pages/pre-install-guide/4500-hardware.rst
.. include:: /pages/pre-install-guide/7000-sahara-plan.rst
.. include:: /pages/pre-install-guide/0031-fuel-configuration.rst
.. include:: /pages/pre-install-guide/0060-quick-install-fuel.rst
.. include:: /pages/pre-install-guide/0051-network-plan.rst
.. include:: /pages/pre-install-guide/0080-reference-configuration.rst
.. include:: /pages/pre-install-guide/0090-appendix.rst
.. include:: /pages/pre-install-guide/0030-pre-installation-checklist.rst

View File

@ -6,9 +6,11 @@
.. include:: /pages/reference-architecture/1100-ha-notes.rst
.. include:: /pages/reference-architecture/1200-mysql-galera.rst
.. include:: /pages/reference-architecture/1700-ceph.rst
.. include:: /pages/reference-architecture/0030-cluster-sizing.rst
.. include:: /pages/reference-architecture/0045-storage.rst
.. include:: /pages/reference-architecture/6000-network-architecture.rst
.. include:: /pages/reference-architecture/6030-router.rst
.. include:: /pages/reference-architecture/6034-switch.rst
.. include:: /pages/reference-architecture/6050-neutron-topologies.rst
.. include:: /pages/reference-architecture/6070-nova-topologies.rst
.. include:: /pages/reference-architecture/0100-openvswitch.rst
.. include:: /pages/reference-architecture/0110-bonding.rst

View File

@ -15,7 +15,7 @@ PDFs
----
The following Mirantis OpenStack documentation is available in PDF:
* `Pre-Installation Guide <pdf/Mirantis-OpenStack-5.0-Pre-InstallationGuide.pdf>`_
* `Pre-Installation Guide <pdf/Mirantis-OpenStack-5.0-PlanningGuide.pdf>`_
Prerequisites and pre-installation steps that you must execute before
installing Fuel and deploying Mirantis OpenStack.

View File

@ -1,18 +1,18 @@
Deployment Modes
-----------------------------
----------------
You can use Fuel for OpenStack to create virtually any OpenStack
configuration. However, Mirantis provides several pre-defined
architectures for your convenience.
The pre-defined architectures include:
* **Multi-node**
The Multi-node environment provides an easy way
to install an entire OpenStack environment without requiring the degree
of increased hardware involved in ensuring high availability.
Mirantis recommends that you use this architecture for testing
purposes.
* **Multi-node HA**
The Multi-node with HA environment is dedicated for highly available
production deployments. Using Multi-node with HA you can deploy
@ -22,6 +22,3 @@ The pre-defined architectures include:
With Fuel, you can create your own cloud environment that includes
additional components.
For more information, contact `Mirantis <http://www.mirantis.com/contact/>`_.
.. seealso:: :ref:`Reference Architecture<ref-arch>`

View File

@ -5,5 +5,3 @@
.. include:: /pages/install-guide/0070-networks/0200-fuel-deployment-schema.rst
.. include:: /pages/install-guide/0070-networks/0210-config-network.rst
.. include:: /pages/install-guide/0070-networks/0220-map-logical-to-physical-nic.rst
.. include:: /pages/install-guide/0070-networks/0300-switch-config.rst
.. include:: /pages/install-guide/0070-networks/0350-router.rst

View File

@ -1,74 +0,0 @@
Switch
++++++
Fuel can configure hosts, however switch configuration is still manual work.
Unfortunately the set of configuration steps, and even the terminology used,
is different for different vendors, so we will try to provide
vendor-agnostic information on how traffic should flow and leave the
vendor-specific details to you. We will provide an example for a Cisco switch.
First of all, you should configure access ports to allow non-tagged PXE booting
connections from all Slave nodes to the Fuel node. We refer this network
as the Fuel network.
By default, the Fuel Master node uses the `eth0` interface to serve PXE
requests on this network, but this can be changed :ref:`during installation
<Network_Install>` of the Fuel Master node.
So if that's left unchanged, you have to set the switch port for `eth0` of Fuel
Master node to access mode.
We recommend that you use the `eth0` interfaces of all other nodes for PXE booting
as well. Corresponding ports must also be in access mode.
Taking into account that this is the network for PXE booting, do not mix
this L2 segment with any other network segments. Fuel runs a DHCP
server, and if there is another DHCP on the same L2 network segment, both the
company's infrastructure and Fuel's will be unable to function properly.
You also need to configure each of the switch's ports connected to nodes as an
"STP Edge port" (or a "spanning-tree port fast trunk", according to Cisco
terminology). If you don't do that, DHCP timeout issues may occur.
As long as the Fuel network is configured, Fuel can operate.
Other networks are required for OpenStack environments, and currently all of
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
the Fuel UI should be configured on switch ports, pointing to Slave nodes,
as tagged.
Of course, it is possible to specify as tagged only certain ports for certain
nodes. However, in the current version, all existing networks are automatically
allocated for each node, with any role.
And network check will also check if tagged traffic pass, even if some nodes do
not require this check (for example, Cinder nodes do not need fixed network traffic).
This is enough to deploy the OpenStack environment. However, from a
practical standpoint, it's still not really usable because there is no
connection to other corporate networks yet. To make that possible, you must
configure uplink port(s).
One of the VLANs may carry the office network. To provide access to the Fuel Master
node from your network, any other free physical network interface on the
Fuel Master node can be used and configured according to your network
rules (static IP or DHCP). The same network segment can be used for
Public and Floating ranges. In this case, you must provide the corresponding
VLAN ID and IP ranges in the UI. One Public IP per node will be used to SNAT
traffic out of the VMs network, and one or more floating addresses per VM
instance will be used to get access to the VM from your network, or
even the global Internet. To have a VM visible from the Internet is similar to
having it visible from corporate network - corresponding IP ranges and VLAN IDs
must be specified for the Floating and Public networks. One current limitation
of Fuel is that the user must use the same L2 segment for both Public and
Floating networks.
Example configuration for one of the ports on a Cisco switch::
interface GigabitEthernet0/6 # switch port
description s0_eth0 jv # description
switchport trunk encapsulation dot1q # enables VLANs
switchport trunk native vlan 262 # access port, untags VLAN 262
switchport trunk allowed vlan 100,102,104 # 100,102,104 VLANs are passed with tags
switchport mode trunk # To allow more than 1 VLAN on the port
spanning-tree portfast trunk # STP Edge port to skip network loop
# checks (to prevent DHCP timeout issues)
vlan 262,100,102,104 # Might be needed for enabling VLANs

View File

@ -1,16 +0,0 @@
Router
++++++
To make it possible for VMs to access the outside world, you must have an IP
address set on a router in the Public network. In the examples provided,
that IP is 12.0.0.1 in VLAN 101.
Fuel UI has a special field on the networking tab for the gateway address. As
soon as deployment of OpenStack is started, the network on nodes is
reconfigured to use this gateway IP as the default gateway.
If Floating addresses are from another L3 network, then you have to configure the
IP address (or even multiple IPs if Floating addresses are from more than one L3
network) for them on the router as well.
Otherwise, Floating IPs on nodes will be inaccessible.

View File

@ -1,4 +0,0 @@
.. contents:: :local:
:depth: 3
.. include:: /pages/pre-install-guide/0031-fuel-configuration/0032-prepare-most-deploy.rst

View File

@ -1,77 +0,0 @@
.. _calculator: https://www.mirantis.com/openstack-services/bom-calculator/
.. index:: Preparing for the Mirantis OpenStack Deployment
.. _PrepMirDep:
Preparing the Mirantis OpenStack Deployment
===========================================
Before installation, plan your deployment. Determine the deployment type that
is appropriate for you configuration needs. You may want to print this
list and make notes indicating your selection so you can be sure
you have planned your deployment correctly.
The following table provides a list of configuration steps that you must
complete to plan the Mirantis OpenStack deployment.
+----+----------------------------+-------------------------------------------+
| | Step Description | Additional Information |
+====+============================+===========================================+
| 1 | Consider which deployment | For more information, see: |
| | mode you will deploy | :ref:`Reference Architecture <ref-arch>`. |
| | (Multi-node HA or non HA) | |
+----+----------------------------+-------------------------------------------+
| 2 | Select a network service | For more information, see: |
| | (Nova-Network: FlatDHCP, | :ref:`Network <fuelui-network>`. |
| | VLAN manager or Neutron: | |
| | GRE, VLAN). | |
+----+----------------------------+-------------------------------------------+
| 3 | Prepare all the necessary | For more information, see: the Mirantis |
| | hardware. | Hardware Bill of Materials calculator_, |
| | | HardwarePrerequisites_ |
+----+----------------------------+-------------------------------------------+
| 4 | Plan a role (or roles) to | A node may act as a controller, compute |
| | be assigned to each node | or storage node - or combine storage or |
| | server. | compute role. Network services are |
| | | automatically installed onto the |
| | | controller when utilizing the Fuel UI. |
+----+----------------------------+-------------------------------------------+
| 5 | Prepare an addressing plan | Identify the network addresses and VLAN |
| | and network association. | IDs for your Public, floating, Management,|
| | | Storage, and virtual machine (fixed) |
| | | networks. For more information on how to |
| | | plan your network, see: |
| | | NetworkConfiguration_ |
+----+----------------------------+-------------------------------------------+
| 6 | Prepare a logical network | For more information, see: |
| | diagram. | NetworkConfiguration_ |
+----+----------------------------+-------------------------------------------+
| 7 | Connect the Fuel and node | For more information, see the instructions|
| | servers' NICs to the | for your network. |
| | switches. | |
+----+----------------------------+-------------------------------------------+
| 8 | Connect the Fuel and node | For more information, see the instructions|
| | servers' IPMI cards to the | for your hardware. |
| | out of band management | |
| | network. | |
+----+----------------------------+-------------------------------------------+
| 9 | Configure access to the | For more information, see the IPMI |
| | node servers through IPMI | instructions for your hardware. |
+----+----------------------------+-------------------------------------------+
| 10 | Prepare the proper | According to your addressing plan and |
| | physical network | logical network diagram. |
| | configuration (configure | |
| | switches, routers, etc). | |
+----+----------------------------+-------------------------------------------+
| 11 | Connect the OpenStack | For more information, see the instructions|
| | networks to the server | for your routers and/or switches. |
| | Ethernet port on each | |
| | server. | |
+----+----------------------------+-------------------------------------------+
| 12 | Install the Fuel server | For more information, see: |
| | | FuelQuickInstall_. |
+----+----------------------------+-------------------------------------------+
.. seealso:: `Mirantis Services <http://www.mirantis.com/openstack-services>`_

View File

@ -1,6 +0,0 @@
.. contents:: :local:
:depth: 3
.. include:: /pages/pre-install-guide/0051-network-plan/0100-net-config-options.rst
.. include:: /pages/pre-install-guide/0051-network-plan/0110-openstack-networks.rst
.. include:: /pages/pre-install-guide/0051-network-plan/0200-topology-include.rst

View File

@ -1,11 +0,0 @@
.. index:: Network Configuration Options
.. _NetworkConfiguration:
Network Configuration Options
=============================
This section describes how to configure network settings depending on
your environment requirements and prerequisites.

View File

@ -1,11 +0,0 @@
Networks used by OpenStack
--------------------------
The OpenStack architecture defines a set of
logical networks that are used in the OpenStack environment;
see :ref:`logical-networks-arch`.
Your network plan must define how these logical networks
will be mapped to the physical NICs in your data center.
You will define this mapping in Fuel
before your environment is deployed.

View File

@ -1,5 +0,0 @@
.. include:: /pages/pre-install-guide/0051-network-plan/topology/0210-topology.intro.rst
.. include:: /pages/pre-install-guide/0051-network-plan/topology/0600-nova-topologies.rst
.. include:: /pages/pre-install-guide/0051-network-plan/topology/0700-neutron-topologies.rst
.. include:: /pages/pre-install-guide/0051-network-plan/topology/0900-routing-req.rst

View File

@ -1,7 +0,0 @@
Network Deployment Models
=========================
This section describes the following network deployment models:
* :ref:`Nova-network <novanetwork>`
* :ref:`Neutron <neutron>`

View File

@ -1,7 +0,0 @@
.. include:: /pages/pre-install-guide/0051-network-plan/topology/nova/0610-nova-topologies.rst
.. include:: /pages/pre-install-guide/0051-network-plan/topology/nova/0620-nova-flatdhcp.rst
.. include:: /pages/pre-install-guide/0051-network-plan/topology/nova/0630-nova-vlan.rst
.. include:: /pages/pre-install-guide/0051-network-plan/topology/nova/0650-nova-assign-networks-to-nics.rst
.. include:: /pages/pre-install-guide/0051-network-plan/topology/nova/0659-nova-net-plan-header.rst
.. include:: /pages/pre-install-guide/0051-network-plan/topology/nova/0660-nova-plan-flatdhcp.rst
.. include:: /pages/pre-install-guide/0051-network-plan/topology/nova/0680-nova-plan-vlan.rst

View File

@ -1,7 +0,0 @@
.. include:: /pages/pre-install-guide/0051-network-plan/topology/neutron/0710-neutron-topologies.rst
.. include:: /pages/pre-install-guide/0051-network-plan/topology/neutron/0720-neutron-vlan.rst
.. include:: /pages/pre-install-guide/0051-network-plan/topology/neutron/0730-neutron-gre.rst
.. include:: /pages/pre-install-guide/0051-network-plan/topology/neutron/0759.net-plan-header.rst
.. include:: /pages/pre-install-guide/0051-network-plan/topology/neutron/0760-neutron-plan-vlan.rst
.. include:: /pages/pre-install-guide/0051-network-plan/topology/neutron/0780-neutron-plan-gre.rst

View File

@ -1,30 +0,0 @@
Routing recommendations
-----------------------
Consider the following routing recommendations when you configure your
network:
- Use the default routing via a router in the Public network
- Use the the management network to access to your management
infrastructure (L3 connectivity if necessary)
- The Storage and VM networks should be configured without access to
other networks (no L3 connectivity)
.. image:: /_images/fuel-network-scheme.jpg
:align: center
.. image:: /_images/grub-screen.png
:align: center
.. image:: /_images/grub-cmdline.png
:align: center
.. image:: /_images/fuel-wizard.png
:align: center
.. image:: /_images/fuel-network-settings.png
:align: center
.. image:: /_images/fuel-settings.png
:align: center
.. image:: /_images/fuel-nodes.png
:align: center
.. image:: /_images/fuel-nodes-selected.png
:align: center
.. image:: /_images/fuel-node-network.png
:align: center

View File

@ -1,8 +0,0 @@
.. _neutron:
Neutron
-------
This section describes recommended parameters for network configuration
using the Neutron service.

View File

@ -1,12 +0,0 @@
VLAN Segmentation
~~~~~~~~~~~~~~~~~
The following diagram shows the network isolation using Open vSwitches and
VLANs:
.. image:: /_images/preinstall_d_vlan_segm.jpg
:align: center
:width: 75%
.. note:: You must have at least three network interfaces for this
configuration

View File

@ -1,14 +0,0 @@
GRE Segmentation
~~~~~~~~~~~~~~~~
The following diagram shows the network segmentation using Open vSwitch
and GRE tunneling.
.. image:: /_images/preinstall_d_gre_segm.jpg
:align: center
:width: 75%
Open vSwitch (OVS) GRE tunnels are provided through Management Network.
.. note:: This setup does not include physical Private network.

View File

@ -1,3 +0,0 @@
Network Planning Examples
~~~~~~~~~~~~~~~~~~~~~~~~~

View File

@ -1,39 +0,0 @@
VLAN Segmentation
^^^^^^^^^^^^^^^^^
Depending on the number of NICs you have in your node servers, you can use the
following examples to plan your NIC assignment:
3 NIC deployment
- eth0 - untagged port for Administrative network
- eth1 (br-eth1) - port for networks: Public/Floating, Management,
Storage
- eth2 (br-eth2) - port for Private network (where the number of VLANs
depends on the number of tenant networks with a continuous range)
.. image:: /_images/preinstall_d_vlan_3nics.png
:align: center
:width: 50%
4 NIC deployment
- eth0 - port for Administrative network
- eth1 (br-eth1) - port for networks: Public/Floating, Management
- eth2 (br-eth2) - port for Private network, with defined VLAN range
IDs
- eth3 (br-eth1) - port for Storage network
.. image:: /_images/preinstall_d_vlan_4nics.png
:align: center
:width: 50%
Routing recommendations
- Use the default routing via a router in the Public network
- Use the the management network to access to your management
infrastructure (L3 connectivity if necessary)
- The administrative network or only the Fuel server (via dedicated
NIC) should have Internet access
- The Storage and Private network (VLANs) should be configured without
access to other networks (no L3 connectivity)

View File

@ -1,46 +0,0 @@
GRE Segmentation
^^^^^^^^^^^^^^^^
Depdnding on the number of NICs you have in your node servers, you can use the
foldowing examples to plan your NIC assignment:
2  NIC deployment 
- eth0 - untagged port for Administrative network
- eth1 (br-eth1) - port for networks: Public/Floating, Management,
Storage
.. image:: /_images/preinstall_d_gre_2nics.png
:align: center
:width: 50%
3  NIC deployment 
- eth0 - untagged port for Administrative network
- eth1 (br-eth1) - port for networks: Public/Floating, Management
- eth2 (br-eth2) - port for Storage network
.. image:: /_images/preinstall_d_gre_3nics.png
:align: center
:width: 50%
4  NIC deployment 
- eth0 - untagged port for Administrative network
- eth1 (br-eth1) - port for Management network
- eth2 (br-eth2) - port for Public/Floating network
- eth3 (br-eth3) - port for Storage network
.. image:: /_images/preinstall_d_gre_4nics.png
:align: center
:width: 50%
Routing recommendations
- Use the default routing via router in the Public network
- Use the management network access to your management infrastructure (L3
connectivity if necessary)
- The administrative network or only Fuel server (via dedicated NIC)
should have Internet access
- The Storage and Private network (VLANs) should be configured
without access to other networks (no L3 connectivity)

View File

@ -1,10 +0,0 @@
.. _novanetwork:
Nova-network
------------
Nova-network offers two options for deploying private network for tenants:
* FlatDHCP Manager
* VLAN Manager

View File

@ -1,12 +0,0 @@
Assigning OpenStack Networks to Network Interfaces
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You must associate each OpenStack network with a server NIC.
To assign OpenStack networks to server NICs, using Fuel UI:
1. Click **Add Nodes**.
2. Select the role for this host.
3. Click **Apply Changes**.
4. Select the role you want to modify, and click **Configure Interfaces**.
5. Drag and drop the appropriate networks onto the physical interfaces.

View File

@ -1,3 +0,0 @@
Network Planning Examples
~~~~~~~~~~~~~~~~~~~~~~~~~

View File

@ -1,5 +1,5 @@
Reference configuration of hardware switches
--------------------------------------------
============================================
This section describes reference configuration for Cisco and Juniper
network switches.

View File

@ -1,5 +1,5 @@
Detailed Port Configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
---------------------------
The following table describes the detailed port configuration and VLAN
assignment.

View File

@ -1,5 +1,5 @@
Example 1: HA + Nova-network FlatDHCP manager
---------------------------------------------
=============================================
As a model example, the following configuration is used:

View File

@ -1,7 +1,7 @@
.. _cisco-2960g-config:
.. _cisco-2960g-nova:
Switch configuration (Cisco Catalyst 2960G)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nova-network Switch configuration (Cisco Catalyst 2960G)
--------------------------------------------------------
Use the following configuration to deploy Mirantis OpenStack using a Cisco
Catalyst 2960G network switch.::

View File

@ -1,5 +1,8 @@
Switch configuration (Juniper EX4200)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. _juniper-ex4200-nova:
Nova-network Switch configuration (Juniper EX4200)
--------------------------------------------------
Use the following configuration to deploy Mirantis OpenStack using
Juniper EX4200 network switch.::

View File

@ -1,5 +1,5 @@
Detailed port configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~
---------------------------
The following table describes port configuration for this deployment.

View File

@ -1,5 +1,6 @@
Example 2: HA + Neutron with GRE
--------------------------------
================================
As a model example, the following configuration is used:
* **Deploying mode:** Multi-node HA

View File

@ -1,5 +1,8 @@
Switch configuration (Cisco Catalyst 2960G)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. _cisco-2960g-neutron:
Neutron Switch configuration (Cisco Catalyst 2960G)
---------------------------------------------------
Use the following configuration to deploy Mirantis OpenStack using a Cisco
Catalyst 2960G network switch.

View File

@ -1,5 +1,8 @@
Switch configuration (Juniper EX4200)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. _juniper-ex4200-neutron:
Neutron Switch configuration (Juniper EX4200)
---------------------------------------------
Use the following configuration to deploy Mirantis OpenStack using
Juniper EX4200 network switch.

View File

@ -0,0 +1,46 @@
.. _calculator: https://www.mirantis.com/openstack-services/bom-calculator/
.. index:: Preparing for the Mirantis OpenStack Deployment
.. _planning-summary:
Planning Summary
================
Before installation, plan your deployment. Determine the deployment type that
is appropriate for you configuration needs. You may want to print this
list and make notes indicating your selection so you can be sure
you have planned your deployment correctly.
The following table provides a list of configuration steps that you must
complete to plan the Mirantis OpenStack deployment.
+----------------------------+-------------------------------------------+
| Step Description | Additional Information |
+============================+===========================================+
| Choose a deployment mode | See :ref:`mode-ha-plan` |
| and whether or not to | |
| deploy high availability | |
+----------------------------+-------------------------------------------+
| Select a network topology | See :ref:`net-topology-plan` |
| | |
+----------------------------+-------------------------------------------+
| Choose the Linux distro | See :ref:`linux-distro-plan` |
| to use on your nodes | |
+----------------------------+-------------------------------------------+
| Determine how many nodes | See :ref:`nodes-roles-plan` |
| to deploy and which roles | |
| to assign to each | |
+----------------------------+-------------------------------------------+
| Calculate the server and | See :ref:`hardware-plan` |
| network hardware needed | |
+----------------------------+-------------------------------------------+
| Prepare an IP address | Identify the network addresses and VLAN |
| management plan and | IDs for your Public, floating, Management,|
| network association. | Storage, and virtual machine (fixed) |
| | networks. |
+----------------------------+-------------------------------------------+
| Prepare a logical network | |
| diagram. | |
+----------------------------+-------------------------------------------+

View File

@ -0,0 +1,5 @@
.. _mode-ha-plan:
Choose Deployment Mode and High Availability
============================================

View File

@ -0,0 +1,62 @@
.. _net-topology-plan:
Choose Network Topology
=======================
OpenStack supports two network modes,
each of which supports two topologies.
For architectural descriptions of the four topologies, see:
* :ref:`neutron-vlan-ovs-arch`
* :ref:`neutron-gre-ovs-arch`
* :ref:`nova-flatdhcp-arch`
* :ref:`nova-vlan-arch`
**Nova-network** is a simple legacy network manager.
It can operate with predefined Private IP spaces only.
* If you do not want to split your VMs to an isolated groups (tenants),
you can choose the **Nova-network with FlatDHCP topology**.
In this case, you will have one big tenant for all VMs.
* If you want use multiple tenants
and all of them contain approximately the same number of VMs,
you can use the **Nova-network with VLANManager topology**.
In this case, the number of the tenants is predefined
and all the tenants have equal amount of Private IP space.
You must decide about these two numbers
(max number of tenants and Private IP space size)
before starting deployment.
Also, you must set up appropriate VLANs
on your underlying network equipment.
**Neutron** is a modern and more complicated network manager.
It can not only separate tenants
but it decreases the requirements for the underlying network
(physical switches and topology)
and gives a great deal of flexibility
for manipulating Private IP spaces.
You can create Private IP spaces with different sizes
and manipulate them on the fly.
* The **Neutron with VLAN topology**,
like Nova-network with VLANManager,
requires a predefined maximum number of tenants value
and underlying network equipment configuration.
* The **Neutron with GRE** topology
does not restrict the maximum number of VLANs
and you can spawn a very large number of tenants.
But GRE encapsulation decreases the speed of comminication between the VMs
and decreases the CPU utilization of the Compute and Controller nodes.
So, if you do not need really fast interconnections between VMs,
do not want to predetermine the maximum number of tenants,
and do not want to configure your network equipment,
you can choose the Neutron + GRE topology.
Some other considerations when choosing a network topology:
- :ref:`ovs-term` and :ref:`bonding-term` can only be implemented on Neutron.
- VMWare vCenter can only be implemented on Nova-network.
- Murano is supported only on Neutron.

View File

@ -0,0 +1,25 @@
.. _linux-distro-plan:
Linux Distribution for Nodes
============================
Fuel allows you to deploy either the CentOS or Ubuntu
Linux distribution as the Host O/S on the nodes.
All nodes in the environment must run the same Linux distribution.
Often, the choice is made based on personal preference;
many administrative tasks on the nodes
must be performed at shell level
and many people choose the distribution
with which they are most comfortable.
Some specific considerations:
- Each distribution has some hardware support issues.
See :ref:`release-notes` for details about known issues.
- In particular, the CentOS version used for OpenStack
does not include native support for VLANs
while the Ubuntu version does.
In order to use VLANs on CentOS based nodes,
you must configure VLAN splinters.
- CentOS supports .rpm packages; Ubuntu supports .deb packages.

View File

@ -1,16 +1,39 @@
.. raw:: pdf
PageBreak
.. index:: Cluster Sizing
.. _nodes-roles-plan:
Cluster Sizing
==============
Nodes and Roles
===============
This reference architecture is well suited for production-grade
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.
Your OpenStack environment contains a set of
specialized nodes and roles;
see :ref:`nodes-roles-arch` for a description.
When planning your OpenStack deployment,
you must determine the proper mix of node types
and what roles will be installed on each.
Some general guiding principles:
- When deploying a production-grade OpenStack environment,
it is best to spread the roles (and, hence, the workload)
over as many servers as possible
in order to have a fully redundant, highly-available OpenStack environment
and to avoid performance bottlenecks.
- For demonstration and study purposes,
you can deploy OpenStack on VirtualBox;
see :ref:`virtualbox` for more information.
This option has the lowest hardware requirements
- OpenStack can be deployed on smaller hardware configurations
by combining multiple roles on the nodes
and mapping multiple :ref:`logical-networks-arch`
to a single physical NIC.
This section provides information to help you decide
how many nodes you need and which roles to assign to each.
The absolute minimum requirement for a highly-available OpenStack
deployment is to allocate 4 nodes:

View File

@ -0,0 +1,5 @@
.. _hardware-plan:
Calculate hardware requirements
===============================

View File

@ -4,6 +4,8 @@
.. index Reference Architectures
.. _nodes-roles-arch:
OpenStack Environment Architecture
==================================

View File

@ -14,9 +14,12 @@ Logical Networks
For better network performance and manageability,
Fuel places different types of traffic into separate logical networks.
his section describes how to distribute
This section describes how to distribute
the network traffic in an OpenStack cluster.
Refer to :ref:`User_Guide` for instructions on how to configure network for
your OpenStack environment.
.. index:: Admin (PXE) Network
Admin (PXE) Network ("Fuel network")

View File

@ -0,0 +1,32 @@
.. _router-plan:
Router
------
Your network must have an IP address set on a router
in the Public :ref:`logical-networks-arch`.
Without this, your VMs are unable to access the outside world.
In many of the examples provided in these documents,
that IP is 12.0.0.1 in VLAN 101.
The Fuel UI includes a field on the networking tab for the gateway address.
When OpenStack deployment starts,
the network on each node is reconfigured
to use this gateway IP address as the default gateway.
If Floating addresses are from another L3 network,
then you must configure the IP address
(or multiple IPs if Floating addresses are from more than one L3 network)
for them on the router as well.
Otherwise, Floating IPs on nodes will be inaccessible.
Consider the following routing recommendations
when you configure your network:
- Use the default routing via a router in the Public network
- Use the the management network to access your management
infrastructure (L3 connectivity if necessary)
- The Storage and VM networks should be configured without access to
other networks (no L3 connectivity)

View File

@ -0,0 +1,107 @@
.. _switch-plan:
Switches
--------
You must manually configure your switches
before deploying your OpenStack environment.
Unfortunately the set of configuration steps, and even the terminology used,
is different for different vendors;
this section provides some vendor-agnostic information
about how traffic should flow.
We also provide sample switch configurations:
* :ref:`cisco-2960g-nova`
* :ref:`juniper-ex4200-nova`
* :ref:`cisco-2960g-neutron`
* :ref:`juniper-ex4200-neutron`
To configure your switches:
* Configure all access ports to allow non-tagged PXE booting connections
from each slave node to the Fuel Master node.
This network is referred to as the Fuel network.
* By default, the Fuel Master node uses the `eth0` interface
to serve PXE requests on this network,
but this can be changed :ref:`during installation <Network_Install>`
of the Fuel Master node.
* If you use the `eth0` interface for PXE requests,
you must set the switch port for `eth0` on the Fuel Master node
to access mode.
* We recommend that you use the `eth0` interfaces of all other nodes
for PXE booting as well.
Corresponding ports must also be in access mode.
* Taking into account that this is the network for PXE booting,
do not mix this L2 segment with any other network segments.
Fuel runs a DHCP server, and,
if there is another DHCP on the same L2 network segment,
both the company's infrastructure and Fuel's
are unable to function properly.
* You must also configure each of the switch's ports
connected to nodes as an "STP Edge port"
(or a "spanning-tree port fast trunk", according to Cisco terminology).
If you do not do that, DHCP timeout issues may occur.
As long as the Fuel network is configured, Fuel can operate.
Other networks are required for OpenStack environments,
and currently all of 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
the Fuel UI should be configured on switch ports, pointing to Slave nodes,
as tagged.
Of course, it is possible to specify as tagged
only certain ports for certain nodes.
However, in the current version,
all existing networks are automatically allocated for each node,
with any role.
And network check also checks if tagged traffic can pass,
even if some nodes do not require this check.
for example, Cinder nodes do not need fixed network traffic)
This is enough to deploy the OpenStack environment.
However, from a practical standpoint,
it is still not really usable
because there is no connection to other corporate networks yet.
To make that possible, you must configure uplink port(s).
One of the VLANs may carry the office network.
To provide access to the Fuel Master node from your network,
any other free physical network interface
on the Fuel Master node can be used
and configured according to your network rules (static IP or DHCP).
The same network segment can be used for Public and Floating ranges.
In this case, you must provide
the corresponding VLAN ID and IP ranges in the UI.
One Public IP per node is used to SNAT traffic out of the VMs network,
and one or more floating addresses per VM instance
are used to get access to the VM from your network,
or even the global Internet.
To have a VM visible from the Internet is similar
to having it visible from corporate network -
corresponding IP ranges and VLAN IDs must be specified
for the Floating and Public networks.
One current limitation of Fuel
is that the user must use the same L2 segment
for both Public and Floating networks.
Example configuration for one of the ports on a Cisco switch::
interface GigabitEthernet0/6 # switch port
description s0_eth0 jv # description
switchport trunk encapsulation dot1q # enables VLANs
switchport trunk native vlan 262 # access port, untags VLAN 262
switchport trunk allowed vlan 100,102,104 # 100,102,104 VLANs are passed with tags
switchport mode trunk # To allow more than 1 VLAN on the port
spanning-tree portfast trunk # STP Edge port to skip network loop
# checks (to prevent DHCP timeout issues)
vlan 262,100,102,104 # Might be needed for enabling VLANs

View File

@ -31,6 +31,9 @@ to act as a virtual Neutron router in HA (if deploying in HA mode).
.. include:: /pages/reference-architecture/neutron-intro/0200-neutron-tech-intro.rst
.. include:: /pages/reference-architecture/neutron-intro/0210-vlan.rst
.. include:: /pages/reference-architecture/neutron-intro/0220-gre.rst
.. include:: /pages/reference-architecture/neutron-intro/0260-neutron-config.rst
.. include:: /pages/reference-architecture/neutron-intro/0300-neutron-limits.rst
.. include:: /pages/reference-architecture/network-setup/0500-nic-usage.rst
.. include:: /pages/reference-architecture/neutron-intro/0500-nic-usage.rst

View File

@ -0,0 +1,17 @@
.. _nova-topologies-arch:
Nova Network Topologies
=======================
Nova-network offers two options for deploying private network for tenants:
* FlatDHCP Manager
* VLAN Manager
This section describes the Nova-network topologies.
.. include:: /pages/reference-architecture/nova-intro/0620-nova-flatdhcp.rst
.. include:: /pages/reference-architecture/nova-intro/0630-nova-vlan.rst
.. include:: /pages/reference-architecture/nova-intro/0659-nova-net-plan.rst

View File

@ -33,32 +33,5 @@ It is important to note:
separate NIC to ensure that traffic is separated adequately.
* Admin and Private networks must be located together
on a NIC that is separate from the other networks.
A typical network configuration for Neutron with VLAN segmentation might look
like this:
.. image:: /_images/Neutron_32_vlan_v2.png
:align: center
A typical network configuration for Neutron with GRE segmentation might look
like this:
.. image:: /_images/Neutron_32_gre_v2.png
:align: center
The most likely configuration for different number NICs on cluster nodes:
+------+--------------------------------------+--------------------------------------+
| NICs | VLAN | GRE |
+======+======================================+======================================+
| 2 | Not supported | .. image:: /_images/q32_gre_2nic.* |
| | | :align: center |
+------+--------------------------------------+--------------------------------------+
| 3 | .. image:: /_images/q32_vlan_3nic.* | .. image:: /_images/q32_gre_3nic.* |
| | :align: center | :align: center |
+------+--------------------------------------+--------------------------------------+
| 4 | .. image:: /_images/q32_vlan_4nic.* | .. image:: /_images/q32_gre_4nic.* |
| | :align: center | :align: center |
+------+--------------------------------------+--------------------------------------+
* :ref:`ovs-term` improves the flexiblity and performance
of both Neutron topologies.

View File

@ -0,0 +1,16 @@
.. _neutron-vlan-ovs-arch:
Neutron with VLAN segmentation and OVS
++++++++++++++++++++++++++++++++++++++
The following diagram shows the network isolation
using :ref:`ovs-term` and VLANs:
.. image:: /_images/Neutron_32_vlan_v2.png
:width: 90%
.. note:: You must have at least three network interfaces for this
configuration

View File

@ -0,0 +1,17 @@
.. _neutron-gre-ovs-arch:
Neutron with GRE segmentation and OVS
++++++++++++++++++++++++++++++++++++++
A typical network configuration for Neutron with GRE segmentation might look
like this:
.. image:: /_images/Neutron_32_gre_v2.png
:width: 90%
Open vSwitch (OVS) GRE tunnels are provided through Management Network.
.. note:: This setup does not include physical Private network.

View File

@ -0,0 +1,111 @@
.. _neutron-config-gen:
Neutron Configuration Planning -- General
+++++++++++++++++++++++++++++++++++++++++
The most likely configuration for different number NICs on cluster nodes:
+------+--------------------------------------+--------------------------------------+
| NICs | VLAN | GRE |
+======+======================================+======================================+
| 2 | Not supported | .. image:: /_images/q32_gre_2nic.* |
| | | :align: center |
+------+--------------------------------------+--------------------------------------+
| 3 | .. image:: /_images/q32_vlan_3nic.* | .. image:: /_images/q32_gre_3nic.* |
| | :align: center | :align: center |
+------+--------------------------------------+--------------------------------------+
| 4 | .. image:: /_images/q32_vlan_4nic.* | .. image:: /_images/q32_gre_4nic.* |
| | :align: center | :align: center |
+------+--------------------------------------+--------------------------------------+
.. _neutron-config-vlan:
Neutron VLAN Segmentation Planning
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Depending on the number of NICs you have in your node servers, you can use the
following examples to plan your NIC assignment:
3 NIC deployment
- eth0 - untagged port for Administrative network
- eth1 (br-eth1) - port for networks: Public/Floating, Management,
Storage
- eth2 (br-eth2) - port for Private network (where the number of VLANs
depends on the number of tenant networks with a continuous range)
.. image:: /_images/preinstall_d_vlan_3nics.png
:align: center
:width: 50%
4 NIC deployment
- eth0 - port for Administrative network
- eth1 (br-eth1) - port for networks: Public/Floating, Management
- eth2 (br-eth2) - port for Private network, with defined VLAN range
IDs
- eth3 (br-eth1) - port for Storage network
.. image:: /_images/preinstall_d_vlan_4nics.png
:align: center
:width: 50%
Routing recommendations
- Use the default routing via a router in the Public network
- Use the the management network to access to your management
infrastructure (L3 connectivity if necessary)
- The administrative network or only the Fuel server (via dedicated
NIC) should have Internet access
- The Storage and Private network (VLANs) should be configured without
access to other networks (no L3 connectivity)
.. _neutron-config-gre:
Neutron GRE Segmentation Planning
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Depdnding on the number of NICs you have in your node servers, you can use the
foldowing examples to plan your NIC assignment:
2  NIC deployment 
- eth0 - untagged port for Administrative network
- eth1 (br-eth1) - port for networks: Public/Floating, Management,
Storage
.. image:: /_images/preinstall_d_gre_2nics.png
:align: center
:width: 50%
3  NIC deployment 
- eth0 - untagged port for Administrative network
- eth1 (br-eth1) - port for networks: Public/Floating, Management
- eth2 (br-eth2) - port for Storage network
.. image:: /_images/preinstall_d_gre_3nics.png
:align: center
:width: 50%
4  NIC deployment 
- eth0 - untagged port for Administrative network
- eth1 (br-eth1) - port for Management network
- eth2 (br-eth2) - port for Public/Floating network
- eth3 (br-eth3) - port for Storage network
.. image:: /_images/preinstall_d_gre_4nics.png
:align: center
:width: 50%
Routing recommendations
- Use the default routing via router in the Public network
- Use the management network access to your management infrastructure (L3
connectivity if necessary)
- The administrative network or only Fuel server (via dedicated NIC)
should have Internet access
- The Storage and Private network (VLANs) should be configured
without access to other networks (no L3 connectivity)

View File

@ -1,5 +1,9 @@
FlatDHCP Manager Network Diagram
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. _nova-flatdhcp-arch:
Nova-network FlatDHCP Manager Network Diagram
---------------------------------------------
The following diagram describes network configuration when you use
Nova-network with FlatDHCP Manager:
@ -8,5 +12,5 @@ Nova-network with FlatDHCP Manager:
:align: center
:width: 75%
For more information about FlatDHCP Manager, see :ref:`Reference Architecture<ref-arch>`.
For more information about FlatDHCP Manager, see :ref:`ref-arch`.

View File

@ -1,5 +1,9 @@
VLAN Manager Network Diagram
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. _nova-vlan-arch:
Nova-network VLAN Manager Network Diagram
-----------------------------------------
The following diagram describes network configuration when you use
Nova-network with VLAN Manager:

View File

@ -0,0 +1,6 @@
Nova-network Planning Examples
------------------------------
.. include:: /pages/reference-architecture/nova-intro/0660-nova-plan-flatdhcp.rst
.. include:: /pages/reference-architecture/nova-intro/0680-nova-plan-vlan.rst

View File

@ -1,5 +1,5 @@
FlatDHCP
^^^^^^^^
Nova-network FlatDHCP
+++++++++++++++++++++
Depending on the number of NICs you have in your node servers, you can use the
following examples to plan your NIC assignment:

View File

@ -1,5 +1,5 @@
VLAN Manager
^^^^^^^^^^^^
Nova-network VLAN Manager
+++++++++++++++++++++++++
Depending on the number of NICs you have in your node servers, you can use the
following examples to plan your NIC assignment:

View File

@ -22,9 +22,10 @@ Here are the the available options:
"action": "add-port", # type of primitive
"name": "xxx-port", # unique name of the new port
"bridge": "xxx", # name of the bridge where the port should be created
"type": "internal", # [optional; default: "internal"] a type of OVS interface
# for the port (see OVS documentation);
# possible values: "system", "internal", "tap", "gre", "null"
"type": "internal", # [optional; default: "internal"] a type of OVS
# interface # for the port (see OVS documentation);
# possible values:
# "system", "internal", "tap", "gre", "null"
"tag": 0, # [optional; default: 0] a 802.1q tag of traffic that
# should be captured from an OVS bridge;
# possible values: 0 (means port is a trunk),
@ -62,8 +63,9 @@ Here are the the available options:
# tag passes); e.g. [0,10,20]
"properties": [], # [optional; default: []] a list of additional
# OVS bonded port properties to modify them in OVS DB;
# you can use it to set the aggregation mode and balancing
# strategy, to configure LACP, and so on (see the OVS documentation)
# you can use it to set the aggregation mode and
# balancing # strategy, to configure LACP, and so on
# (see the OVS documentation)
},
{
"action": "add-patch", # type of primitive

View File

@ -1,5 +1,5 @@
.. _RelNotes_50:
.. _RelNotes-5-0:
Release Notes for Mirantis OpenStack 5.0

View File

@ -17,7 +17,7 @@ execfile('../common_conf.py')
exclude_patterns = ['_*', "pages", 'relnotes', 'contents', 'index', '*-guide', '*.rst']
pdf_documents = [
('pdf/pdf_preinstall', u'Mirantis-OpenStack-5.0-Pre-InstallationGuide', u'Pre-Installation Guide', u'2014, Mirantis Inc.'),
('pdf/pdf_preinstall', u'Mirantis-OpenStack-5.0-PlanningGuide', u'Planning Guide', u'2014, Mirantis Inc.'),
('pdf/pdf_install', u'Mirantis-OpenStack-5.0-InstallGuide', u'Installation Guide', u'2014, Mirantis Inc.'),
('pdf/pdf_user', u'Mirantis-OpenStack-5.0-UserGuide', u'User Guide', u'2014, Mirantis Inc.'),
('pdf/pdf_operations', u'Mirantis-OpenStack-5.0-OperationsGuide', u'Operations Guide', u'2014, Mirantis Inc.'),

View File

@ -5,7 +5,7 @@
+-------------------------------------+-----------------------------------+
| Mirantis OpenStack v5.0 | .. cssclass:: right|
| | |
| Pre-Installation Guide | ###Section### |
| Planning Guide | ###Section### |
+-------------------------------------+-----------------------------------+
.. footer::

View File

@ -1,10 +1,10 @@
.. index:: Pre-install Guide
.. index:: Planning Guide
.. _Pre-install_Guide:
.. _planning-guide:
======================
Pre-Installation Guide
======================
==============
Planning Guide
==============
.. contents:: :local:
:depth: 3

View File

@ -1,6 +1,5 @@
.. index:: Release Notes
.. _Release_Notes:
.. _release-notes:
=============
Release Notes