Merge "RC for docs, main pages, preface, intro, reference architecture"
This commit is contained in:
Roman Alekseenkov
Gerrit Code Review
commit
95b6430902
9
docs/pages/0000-preface.rst
Normal file
9
docs/pages/0000-preface.rst
Normal file
@ -0,0 +1,9 @@
|
||||
OpenStack is a very versatile and flexible cloud management platform. By exposing its portfolio of cloud infrastructure services – compute, storage, networking and other core resources — through ReST APIs, it enables a wide range of control over these services, both from the perspective of an integrated Infrastructure as a Service (IaaS) controlled by applications, as well as automated manipulation of the infrastructure itself.
|
||||
|
||||
This architectural flexibility doesn’t set itself up magically; it asks you, the user and cloud administrator, to organize and manage a large array of configuration options. Consequently, getting the most out of your OpenStack cloud over time – in terms of flexibility, scalability, and manageability – requires a thoughtful combination of automation and configuration choices.
|
||||
|
||||
Mirantis Fuel for OpenStack was created to solve exactly this problem. This step-by-step guide takes you through this process of:
|
||||
|
||||
* Configuring OpenStack and its supporting components into a robust cloud architecture
|
||||
* Deploying that architecture through an effective, well-integrated automation package that sets up and maintains the components and their configurations
|
||||
* Providing access to a well-integrated, up-to-date set of components known to work together
|
||||
@ -1,5 +1,5 @@
|
||||
Package Contents
|
||||
================
|
||||
Preface
|
||||
=======
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
|
||||
@ -10,5 +10,8 @@ Reference Architecture
|
||||
.. include:: /pages/reference-architecture/0020-logical-setup.rst
|
||||
.. include:: /pages/reference-architecture/0030-cluster-sizing.rst
|
||||
.. include:: /pages/reference-architecture/0040-network-setup.rst
|
||||
.. include:: /pages/reference-architecture/0045-technological-considerations.rst
|
||||
.. include:: /pages/reference-architecture/0010-technical-considerations-overview.rst
|
||||
.. include:: /pages/reference-architecture/0060-quantum-vs-nova-network.rst
|
||||
.. include:: /pages/reference-architecture/0050-cinder-vs-nova-volume.rst
|
||||
.. include:: /pages/reference-architecture/0070-swift-notes.rst
|
||||
|
||||
|
||||
@ -11,9 +11,9 @@ Create an example multi-node OpenStack cluster using Fuel
|
||||
.. include:: /pages/installation-instructions/0020-machines.rst
|
||||
.. include:: /pages/installation-instructions/0040-installing-configuring-puppet-master.rst
|
||||
.. include:: /pages/installation-instructions/0042-installing-the-iso.rst
|
||||
.. include:: /pages/installation-instructions/0045-configuring-the-iso.rst
|
||||
.. include:: /pages/installation-instructions/0050-configuring-cobbler.rst
|
||||
.. include:: /pages/installation-instructions/0055-installing-os-using-cobbler.rst
|
||||
.. include:: /pages/installation-instructions/0045-configuring-the-iso.rst
|
||||
.. include:: /pages/installation-instructions/0057-prepare-for-deployment.rst
|
||||
.. include:: /pages/installation-instructions/0060-deploying-openstack.rst
|
||||
.. include:: /pages/installation-instructions/0062-orchestration.rst
|
||||
|
||||
@ -5,7 +5,8 @@ FAQ (Frequently Asked Questions)
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
.. include:: /pages/frequently-asked-questions/0005-known-issues-and-workarounds.rst
|
||||
.. include:: /pages/frequently-asked-questions/0010-rabbitmq.rst
|
||||
.. include:: /pages/frequently-asked-questions/0020-galera.rst
|
||||
.. include:: /pages/frequently-asked-questions/0070-common-technical-issues.rst
|
||||
.. include:: /pages/frequently-asked-questions/0020-other-questions.rst
|
||||
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
This document explains how to use Fuel to more easily create and
|
||||
maintain an OpenStack cloud infrastructure.
|
||||
|
||||
Fuel can be used to create virtually any OpenStack topology, but the
|
||||
installation includes several pre-defined configurations. To simplify
|
||||
Fuel can be used to create virtually any OpenStack configuration, but the
|
||||
installation includes several pre-defined architectures. To simplify
|
||||
matters, the guide emphasises a single common reference architecture,
|
||||
the multi-node, high-availability topology. It begins by explaining
|
||||
the multi-node, high-availability configuration. It begins by explaining
|
||||
that architecture, then moves on to the details of creating that
|
||||
architecture in a development setting using VirtualBox. Finally, it
|
||||
configuration in a development setting using VirtualBox. Finally, it
|
||||
gives you the information you need to know to create this and other
|
||||
OpenStack architectures in a production environment.
|
||||
|
||||
@ -16,22 +16,22 @@ concepts. You should have some familiarity with grid or virtualization
|
||||
systems such as Amazon Web Services or VMware, as well as OpenStack
|
||||
itself, but you don't need to be an expert.
|
||||
|
||||
The Fuel Users Guide is organized as follows:
|
||||
The Fuel User's Guide is organized as follows:
|
||||
|
||||
* Section 1, :ref:`Introduction <Introduction>` (this section), explains what Fuel is and gives you a general idea of how it works.
|
||||
|
||||
* Section 2, :ref:`OpenStack Reference Architecture <Reference-Archiecture>`, provides a general look at the components that make up OpenStack, and describes the reference architecture to be instantiated in Section 3.
|
||||
* Section 2, :ref:`Reference Architecture <Reference-Archiecture>`, provides a general look at the components that make up OpenStack, and describes the reference architecture to be instantiated in Section 3.
|
||||
|
||||
* Section 3, :ref:`Create an example multi-node OpenStack cluster using Fuel <Create-Cluster>`, takes you step-by-step through the process of creating a high-availability OpenStack cluster on test hardware.
|
||||
* Section 3, :ref:`Create an example multi-node OpenStack cluster using Fuel <Create-Cluster>`, takes you step-by-step through the process of creating a high-availability OpenStack cluster.
|
||||
|
||||
* Section 4, :ref:`Production Considerations <Production>`, looks at the real-world questions and problems involved in creating an OpenStack cluster for production use. It discusses issues such as network layout and hardware requirements, and provides tips and tricks for creating a cluster of up to 100 nodes.
|
||||
|
||||
* Even with a utility as powerful as Fuel, creating an OpenStack cluster can be complex, and Section 5, :ref:`Frequently Asked Questions <FAQ>`, covers many of the issues that tend to arise during that process.
|
||||
|
||||
* Finally, the Users Guide assumes that you are taking advantage of certain shortcuts, such as using a pre-built Puppet master; if you prefer not to go that route, Appendix A, :ref:`Creating the Puppet master <Create-PM>`.
|
||||
* Finally, the User's Guide assumes that you are taking advantage of certain shortcuts, such as using a pre-built Puppet master; if you prefer not to go that route, Appendix A, :ref:`Creating the Puppet master <Create-PM>`.
|
||||
|
||||
|
||||
Lets start off by taking a look at Fuel itself. Well start by
|
||||
explaining what it is and how it works, then get you set up and ready
|
||||
Lets start off by taking a look at Fuel itself. We'll start by
|
||||
explaining what it is and how it works, and then get you set up and ready
|
||||
to start using it.
|
||||
|
||||
|
||||
@ -7,26 +7,16 @@ a configuration management system such as Puppet to create scripts
|
||||
that can provide a configurable, repeatable, sharable installation
|
||||
process.
|
||||
|
||||
In practice, that means that the process of using Fuel is as follows:
|
||||
In practice, that means that the process of using Fuel looks like this:
|
||||
|
||||
First, Use Fuel's automation tools and instructions to set up a master
|
||||
node with Puppetmaster and Cobbler. This process only needs to be
|
||||
completed once per installation.
|
||||
#. First, use Fuel's automation tools and instructions to set up a master node with Puppet Master and Cobbler. This process only needs to be completed once per installation.
|
||||
|
||||
Next, use Fuel's snippets, kickstart files, and preseed files for
|
||||
Cobbler to boot the appropriate servers from bare metal and
|
||||
automatically install the appropriate operating systems. These virtual
|
||||
or physical servers boot up already prepared to call on the Puppet
|
||||
Master to receive their respective OpenStack components.
|
||||
#. Next, use Fuel's snippets, kickstart files, and preseed files for Cobbler to boot the appropriate servers from bare metal and automatically install the appropriate operating systems. These virtual or physical servers boot up already prepared to call on the Puppet Master to receive their respective OpenStack components.
|
||||
|
||||
Finally, to complete the basic OpenStack install, use Fuel's puppet
|
||||
manifests to install OpenStack on the newly created servers. These
|
||||
manifests are completely customizable, enabling you to start with one
|
||||
of the included OpenStack architectures and adapt to your own
|
||||
situation as necessary.
|
||||
#. Finally, to complete the basic OpenStack install, use Fuel's puppet manifests to install OpenStack on the newly created servers. These manifests are completely customizable, enabling you to start with one of the included OpenStack architectures and adapt to your own situation as necessary.
|
||||
|
||||
.. image:: https://docs.google.com/drawings/pub?id=15vTTG2_575M7-kOzwsYyDmQrMgCPT2joLF2Cgiyzv7Q&w=678&h=617
|
||||
|
||||
Fuel comes with several pre-defined topologies, some of which include
|
||||
Fuel comes with several pre-defined deployment configurations, some of which include
|
||||
additional options from which you can choose.
|
||||
|
||||
|
||||
@ -1,32 +1,32 @@
|
||||
Reference Topologies Provided By Fuel
|
||||
-------------------------------------
|
||||
Deployment Configurations Provided By Fuel
|
||||
------------------------------------------
|
||||
|
||||
One of the advantages of Fuel is that it comes with several pre-built
|
||||
reference topologies that you can use to immediately deploy your own
|
||||
OpenStack cloud infrastructure. Reference topologies are well-specified configurations of OpenStack and its constituent components
|
||||
tailored to one or more cloud use cases. As of version 2.0, Fuel
|
||||
deployment configurations that you can use to immediately build your own
|
||||
OpenStack cloud infrastructure. These are well-specified configurations of OpenStack and its constituent components
|
||||
tailored to one or more cloud use cases. As of version 2.1, Fuel
|
||||
provides the ability to create the following cluster types without
|
||||
requiring extensive customization:
|
||||
|
||||
**Single node**: Perfect for getting a basic feel for how OpenStack works, the Single-node installation is the simplest way to get OpenStack up and running. The single-node installation provides an easy way to install an entire OpenStack cluster on a single physical or virtual machine.
|
||||
**Single node**: Perfect for getting a basic feel for how OpenStack works, the Single-node installation is the simplest way to get OpenStack up and running. The Single-node installation provides an easy way to install an entire OpenStack cluster on a single physical or virtual machine.
|
||||
|
||||
**Multi-node (non-HA)**: The Multi-node (non-HA) installation enables you to try out additional OpenStack services such as Cinder, Quantum, and Swift without requiring the increased hardware involved in ensuring high availability. In addition to the ability to independently specify which services to activate, you also have the following options:
|
||||
**Multi-node (non-HA)**: The Multi-node (non-HA) installation enables you to try out additional OpenStack services such as Cinder, Quantum, and Swift without requiring the degree of increased hardware involved in ensuring high availability. In addition to the ability to independently specify which services to activate, you also have the following options:
|
||||
|
||||
**Compact Swift**: When you choose this option, Swift will be installed on your controllers, reducing your hardware requirements by eliminating the need for additional Swift servers.
|
||||
|
||||
**Standalone Swift**: This option enables you to install independant Swift nodes, so that you can separate their operation from your controller nodes.
|
||||
|
||||
**Multi-node (HA)**: When you're ready to begin your move to production, the Multi-node (HA) topology is a straightforward way to create an OpenStack cluster that provides high availability. With three controller nodes and the ability to individually specify services such as Cinder, Quantum, and Swift, Fuel provides the following variations of the Multi-node (HA) topology:
|
||||
**Multi-node (HA)**: When you're ready to begin your move to production, the Multi-node (HA) configuration is a straightforward way to create an OpenStack cluster that provides high availability. With three controller nodes and the ability to individually specify services such as Cinder, Quantum, and Swift, Fuel provides the following variations of the Multi-node (HA) configuration:
|
||||
|
||||
**Compact Swift**: When you choose this variation, Swift will be installed on your controllers, reducing your hardware requirements by eliminating the need for additional Swift servers while still addressing high availability requirements.
|
||||
|
||||
**Standalone Swift**: This variation enables you to install independant Swift nodes, so that you can separate their operation from your controller nodes.
|
||||
|
||||
**Compact Quantum**: If you don't need the flexibility of a separate Quantum node, Fuel Library provides the option to combine your Quantum node with one of your controllers.
|
||||
**Compact Quantum**: If you don't need the flexibility of a separate Quantum node, Fuel provides the option to combine your Quantum node with one of your controllers.
|
||||
|
||||
In addition to these configurations, Fuel is designed to be completely
|
||||
customizable. Upcoming editions of this guide discuss techniques for
|
||||
creating additional OpenStack reference topologies.
|
||||
creating additional OpenStack deployment configurations.
|
||||
|
||||
.. Need the correct location for the "contact Mirantis" link; do we have a special sales link?
|
||||
|
||||
|
||||
@ -2,13 +2,13 @@ Download Fuel
|
||||
-------------
|
||||
|
||||
The first step in installing Fuel is to download the version
|
||||
appropriate to your environment.
|
||||
appropriate for your environment.
|
||||
|
||||
Fuel is available for both Essex and Folsom OpenStack installations, and will be available for Grizzly
|
||||
shortly after Grizzly's release.
|
||||
|
||||
To make your installation easier, we also offer a pre-built ISO for installing master node with Puppet Master and Cobbler. You can mount this ISO in a physical or VirtualBox machine in order to
|
||||
To make your installation easier, we also offer a pre-built ISO for installing the master node with Puppet Master and Cobbler. You can mount this ISO in a physical or VirtualBox machine in order to
|
||||
easily create your master node. (Instructions for performing this step
|
||||
without the ISO are given in Appendix A.)
|
||||
without the ISO are given in :ref:`Appendix A <Create-PM>`.)
|
||||
|
||||
Master node ISO, as well as Fuel releases, are available at "Downloads" section at the Fuel portal: http://fuel.mirantis.com/your-downloads/
|
||||
The master node ISO, along with other Fuel releases, is available in the `Downloads <http://fuel.mirantis.com/your-downloads/>`_ section of the Fuel portal.
|
||||
|
||||
@ -5,11 +5,11 @@ v2.1-folsom
|
||||
* Features
|
||||
|
||||
* Support deploying Quantum on controller nodes, as well as on a dedicated networking node
|
||||
* Active/Standby HA for Quantum with Pacemaker, when Quantum is deployed on controller nodes
|
||||
* Active/Standby HA for Quantum with Pacemaker when Quantum is deployed on controller nodes
|
||||
* Logging: an option to send OpenStack logs to local and remote locations through syslog
|
||||
* Monitoring: deployment of Nagios, health checks for infrastructure components (OpenStack API, MySQL, RabbitMQ)
|
||||
* Installation of Puppet Master & Cobbler Server node from ISO
|
||||
* Deployment orchestration based on mcollective, eliminates the need of running Puppet manually on each node
|
||||
* Deployment orchestration based on mcollective eliminates the need to run Puppet manually on each node
|
||||
* Recommended master node setup for mid-scale deployments, tested up to 100 nodes
|
||||
|
||||
* Improvements
|
||||
|
||||
@ -1,10 +1,12 @@
|
||||
OpenStack is a very versatile and flexible cloud management platform. By exposing its portfolio of cloud infrastructure services – compute, storage, networking and other core resources — through ReST APIs, it enables a wide range of control over these services, from the perspective of both integrated Infrastructure as a Service (IaaS) controlled by applications and automated manipulation of the infrastructure itself.
|
||||
|
||||
This architectural flexibility doesn’t set itself up magically, however. It asks you, the user and cloud administrator, to organize and manage a large array of configuration options. Consequently, getting the most out of your OpenStack cloud over time – in terms of flexibility, scalability, and manageability – requires a thoughtful combination of automation and configuration choices.
|
||||
|
||||
Mirantis Fuel for OpenStack was created to solve exactly this problem. This step-by-step guide takes you through the process of:
|
||||
|
||||
* Configuring OpenStack and its supporting components into a robust cloud architecture
|
||||
* Deploying that architecture through an effective, well-integrated automation package that sets up and maintains the components and their configurations
|
||||
* Providing access to a well-integrated, up-to-date set of components known to work together
|
||||
|
||||
Fuel package contains the following items:
|
||||
|
||||
#. Puppet and Cobbler automation
|
||||
* resides in Fuel distribution under /deployment directory
|
||||
#. Access to Mirantis repository of OpenStack packages
|
||||
* all packages are installed from http://download.mirantis.com
|
||||
#. Configuration guide
|
||||
* available online through Fuel portal http://fuel.mirantis.com
|
||||
|
||||
|
||||
@ -13,44 +13,22 @@ basis for installing OpenStack in the next section.
|
||||
As you know, OpenStack provides the following basic services:
|
||||
|
||||
|
||||
**Compute**
|
||||
|
||||
Compute servers are the workhorses of your installation; they're the
|
||||
servers on which your users' virtual machines are created. **Nova-scheduler** controls the life-cycle of these VMs.
|
||||
* **Compute**: Compute servers are the workhorses of your installation; they're the servers on which your users' virtual machines are created. `Nova-scheduler` controls the life-cycle of these VMs.
|
||||
|
||||
|
||||
**Networking**
|
||||
|
||||
Because an OpenStack cluster (virtually) always includes multiple
|
||||
servers, the ability for them to communicate with each other and with
|
||||
the outside world is crucial. Networking was originally handled by the
|
||||
**Nova-network** service, but it is slowly giving way to the newer **Quantum** networking service. Authentication and
|
||||
authorization for these transactions are handled by **Keystone**.
|
||||
* **Networking**: Because an OpenStack cluster (virtually) always includes multiple servers, the ability for them to communicate with each other and with the outside world is crucial. Networking was originally handled by the `Nova-network` service, but it is slowly giving way to the newer `Quantum` networking service. Authentication and authorization for these transactions are handled by `Keystone`.
|
||||
|
||||
|
||||
**Storage**
|
||||
* **Storage**: OpenStack provides for two different types of storage: block storage and object storage. Block storage is traditional data storage, with small, fixed-size blocks that are mapped to locations on storage media. At its simplest level, OpenStack provides block storage using `nova-volume`, but it is common to use `Cinder`.
|
||||
|
||||
Object storage, on the other hand, consists of single variable-size objects that are described by system-level metadata, and you can access this capability using `Swift`.
|
||||
|
||||
OpenStack provides for two different types of storage: block storage
|
||||
and object storage. Block storage is traditional data storage, with
|
||||
small, fixed-size blocks that are mapped to locations on storage media. At
|
||||
its simplest level, OpenStack provides block storage using **nova-volume**, but it is common to use **Cinder**.
|
||||
|
||||
|
||||
|
||||
Object storage, on the other hand, consists of single variable-size
|
||||
objects that are described by system-level metadata, and you can
|
||||
access this capability using **Swift**.
|
||||
|
||||
|
||||
|
||||
OpenStack storage is used for your users' objects, but it is also used
|
||||
for storing the images used to create new VMs. This capability is
|
||||
handled by **Glance**.
|
||||
OpenStack storage is used for your users' objects, but it is also used for storing the images used to create new VMs. This capability is handled by `Glance`.
|
||||
|
||||
|
||||
|
||||
These services can be combined in many different ways. Out of the box,
|
||||
Fuel supports the following topologies:
|
||||
Fuel supports the following deployment configurations:
|
||||
|
||||
|
||||
Single node deployment
|
||||
@ -96,15 +74,15 @@ number of controllers from three (or five, for a full Swift implementation) to o
|
||||
|
||||
|
||||
|
||||
Multi-node (HA) deployment (Compact Swift)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
Multi-node (HA) deployment (Compact)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Production environments typically require high availability, which
|
||||
involves several architectural requirements. Specifically, you will
|
||||
need at least three controllers (to prevent split-brain problems), and
|
||||
need at least three controllers, and
|
||||
certain components will be deployed in multiple locations to prevent
|
||||
single points of failure. That's not to say, however, that you can't
|
||||
reduce hardware requirements by combining your storage and controller
|
||||
reduce hardware requirements by combining your storage, network, and controller
|
||||
nodes:
|
||||
|
||||
|
||||
@ -146,11 +124,11 @@ Where Fuel really shines is in the creation of more complex
|
||||
architectures, so in this document you'll learn how to use Fuel to
|
||||
easily create a multi-node HA OpenStack cluster. To reduce the amount
|
||||
of hardware you'll need to follow the installation in section 3,
|
||||
however, the guide focuses on the Multi-node HA Compact Swift
|
||||
however, the guide focuses on the Multi-node HA Compact
|
||||
architecture.
|
||||
|
||||
|
||||
|
||||
Lets take a closer look at the details of this topology.
|
||||
Lets take a closer look at the details of this deployment configuration.
|
||||
|
||||
|
||||
|
||||
@ -1,4 +1,7 @@
|
||||
Technical Considerations
|
||||
----------------------------
|
||||
|
||||
Before performing any installations, you'll need to make a number of
|
||||
decisions about which services to deploy, but from a general
|
||||
architectural perspective, it's important to think about how you want
|
||||
to handle both networking and block storage.
|
||||
to handle both networking and block storage.
|
||||
@ -1,19 +1,19 @@
|
||||
A closer look at the Multi-node (HA) deployment (compact Swift)
|
||||
-------------------------------------------------------------------
|
||||
A closer look at the Multi-node (HA) Compact deployment
|
||||
-------------------------------------------------------
|
||||
|
||||
In this section, you'll learn more about the Multi-node (HA) Compact
|
||||
Swift topology and how it achieves high availability in preparation
|
||||
deployment configuration and how it achieves high availability in preparation
|
||||
for installing this cluster in section 3. As you may recall, this
|
||||
topology looks something like this:
|
||||
configuration looks something like this:
|
||||
|
||||
.. image:: https://docs.google.com/drawings/d/1xLv4zog19j0MThVGV9gSYa4wh1Ma4MQYsBz-4vE1xvg/pub?w=767&h=413
|
||||
|
||||
|
||||
OpenStack services are interconnected by RESTful HTTP-based APIs and
|
||||
AMQP-based RPC messages. So, redundancy for stateless OpenStack API
|
||||
services is implemented through the combination of Virtual IP(VIP)
|
||||
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
|
||||
OpenStack components, such as state database and messaging server,
|
||||
OpenStack components, such as the state database and messaging server,
|
||||
rely on their respective active/active modes for high availability.
|
||||
For example, RabbitMQ uses built-in clustering capabilities, while the
|
||||
database uses MySQL/Galera replication.
|
||||
|
||||
@ -10,8 +10,7 @@ Controller Nodes
|
||||
The first order of business in achieving high availability (HA) is
|
||||
redundancy, so the first step is to provide multiple controller nodes.
|
||||
You must keep in mind, however, that the database uses Galera to
|
||||
achieve HA, and Galera is a quorum-based system. That means that in
|
||||
order to avoid split-brain problems, you must provide at least 3
|
||||
achieve HA, and Galera is a quorum-based system. That means that you must provide at least 3
|
||||
controller nodes.
|
||||
|
||||
.. image:: https://docs.google.com/drawings/pub?id=1aftE8Yes7CdVSZgZD1A82T_2GqL2SMImtRYU914IMyQ&w=869&h=855
|
||||
|
||||
@ -5,10 +5,7 @@ Network Architecture
|
||||
|
||||
The current architecture assumes the presence of 3 NIC cards in
|
||||
hardware, but can be customized to a different number of NICs (less,
|
||||
or more). For example, in section 3 you will see how to deploy your
|
||||
cluster with four NICs.
|
||||
|
||||
In this case, however, let's consider a typical example of 3 NIC cards.
|
||||
or more). In this case, let's consider a typical example of 3 NIC cards.
|
||||
They're utilized as follows:
|
||||
|
||||
|
||||
@ -17,7 +14,7 @@ They're utilized as follows:
|
||||
* **eth2**: the private network, for communication between OpenStack VMs, and the bridge interface (VLANs)
|
||||
|
||||
|
||||
In the multi-host networking mode, you can choose between
|
||||
In the multi-host networking mode, you can choose between the
|
||||
FlatDHCPManager and VlanManager network managers in OpenStack. The
|
||||
figure below illustrates the relevant nodes and networks.
|
||||
|
||||
@ -37,7 +34,7 @@ outbound connections from VMs to the outside world.
|
||||
|
||||
|
||||
For security reasons, the public network is usually isolated from the
|
||||
private network and internal (management) network. Typically, its a
|
||||
private network and internal (management) network. Typically, it's a
|
||||
single C class network from your globally routed or private network
|
||||
range.
|
||||
|
||||
|
||||
@ -1,9 +0,0 @@
|
||||
Technical Considerations
|
||||
----------------------------
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
.. include:: /pages/reference-architecture/technical-considerations/0010-overview.rst
|
||||
.. include:: /pages/reference-architecture/technical-considerations/0060-quantum-vs-nova-network.rst
|
||||
.. include:: /pages/reference-architecture/technical-considerations/0050-cinder-vs-nova-volume.rst
|
||||
.. include:: /pages/reference-architecture/technical-considerations/0070-swift-notes.rst
|
||||
@ -1,6 +1,6 @@
|
||||
|
||||
Cinder vs. nova-volume
|
||||
----------------------
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Cinder is a persistent storage management service, also known as block-storage-as-a-service. It was created to replace nova-volume, and
|
||||
provides persistent storage for VMs.
|
||||
@ -1,6 +1,6 @@
|
||||
|
||||
Quantum vs. nova-network
|
||||
------------------------
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Quantum is a service which provides networking-as-a-service
|
||||
functionality in OpenStack. It has a rich tenant-facing API for
|
||||
@ -10,7 +10,7 @@ power their cloud networking.
|
||||
|
||||
|
||||
|
||||
There are several common deployment use cases for Quantum. Fuel
|
||||
There are various deployment use cases for Quantum. Fuel
|
||||
supports the most common of them, called Provider Router with Private
|
||||
Networks. It provides each tenant with one or more private networks,
|
||||
which can communicate with the outside world via a Quantum router.
|
||||
@ -1,7 +1,7 @@
|
||||
.. _Swift-and-object-storage-notes:
|
||||
|
||||
Swift (object storage) notes
|
||||
----------------------------
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
FUEL currently supports several ways to deploy the swift service:
|
||||
|
||||
Loading…
Reference in New Issue
Block a user