Merge "Broke several pages up so that they will appear correctly on the website. Re-added Cobbler config."
This commit is contained in:
Roman Alekseenkov
Gerrit Code Review
commit
cb486631ca
@ -6,6 +6,7 @@ Reference Architecture
|
||||
.. contents:: :local:
|
||||
|
||||
.. include:: /pages/reference-architecture/0010-overview.rst
|
||||
.. include:: /pages/reference-architecture/0015-closer-look.rst
|
||||
.. include:: /pages/reference-architecture/0020-logical-setup.rst
|
||||
.. include:: /pages/reference-architecture/0030-cluster-sizing.rst
|
||||
.. include:: /pages/reference-architecture/0040-network-setup.rst
|
||||
|
||||
@ -5,11 +5,14 @@ Create an example multi-node OpenStack cluster using Fuel
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
.. include:: /pages/installation-instructions/0000-preamble.rst
|
||||
.. include:: /pages/installation-instructions/0010-introduction.rst
|
||||
.. include:: /pages/installation-instructions/0015-before-you-start.rst
|
||||
.. include:: /pages/installation-instructions/0020-machines.rst
|
||||
.. include:: /pages/installation-instructions/0040-installing-configuring-puppet-master.rst
|
||||
.. include:: /pages/installation-instructions/0055-installing-os-using-cobbler.rst
|
||||
.. include:: /pages/installation-instructions/0042-installing-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
|
||||
|
||||
5
docs/pages/installation-instructions/0000-preamble.rst
Normal file
5
docs/pages/installation-instructions/0000-preamble.rst
Normal file
@ -0,0 +1,5 @@
|
||||
In this section, you’ll learn how to do an actual installation of OpenStack using Fuel. In addition to getting a feel for the steps involved, you’ll also gain some familiarity with some of your customization options. While Fuel does provide several different deployment topologies out of the box, its common to want to tweak those architectures for your own situation, so you’ll get some practice moving certain features around from the standard installation.
|
||||
|
||||
The first step, however, is to commit to a deployment template. A fairly balanced small size, yet fully featured, deployment is the Multi-node (HA) Swift Compact deployment, so that’s what we’ll be using through the rest of this guide.
|
||||
|
||||
Real world installations require a physical hardware infrastructure, but you can easily deploy a small simulation cloud on a single physical machine using VirtualBox. You can follow these instructions in order to install an OpenStack cloud into a test environment using VirtualBox, or to get a production-grade installation using actual hardware.
|
||||
@ -1,23 +1,3 @@
|
||||
In this section, you'll learn how to do an actual installation of
|
||||
OpenStack using Fuel. In addition to getting a feel for the steps
|
||||
involved, you'll also gain some familiarity with some of your
|
||||
customization options. While Fuel does provide several different
|
||||
deployment topologies out of the box, its common to want to tweak
|
||||
those architectures for your own situation, so you'll get some practice
|
||||
moving certain features around from the standard installation.
|
||||
|
||||
The first step, however, is to commit to a deployment template. A
|
||||
fairly balanced small size, yet fully featured, deployment is the
|
||||
Multi-node (HA) Swift Compact deployment, so that's what we'll be using
|
||||
through the rest of this guide.
|
||||
|
||||
Real world installations require a physical hardware infrastructure,
|
||||
but you can easily deploy a small simulation cloud on a single
|
||||
physical machine using VirtualBox. You can follow these instructions
|
||||
in order to install an OpenStack cloud into a test environment using
|
||||
VirtualBox, or to get a production-grade installation using actual
|
||||
hardware.
|
||||
|
||||
How installation works
|
||||
----------------------
|
||||
|
||||
@ -34,25 +14,3 @@ In contrast with version 2.0 of Fuel, version 2.1 includes orchestration capabil
|
||||
|
||||
Start by designing your architecture.
|
||||
|
||||
Before you start
|
||||
----------------
|
||||
|
||||
Before you begin your installation, you will need to make a number of important
|
||||
decisions:
|
||||
|
||||
* **OpenStack features.** You must choose which of the optional OpenStack features you want. For example, you must decide whether you want to install Swift, whether you want Glance to use Swift for image storage, whether you want Cinder for block storage, and whether you want nova-network or Quantum to handle your network connectivity. In the case of this example, we will be installing Swift, and Glance will be using it. We'll also be using Cinder for block storage. Because it can be easily installed using orchestration, we will also be using Quantum.
|
||||
* **Deployment topology.** The first decision is whether your deployment requires high availability. If you do choose to do an HA deployment, you have a choice regarding the number of controllers you want to have. Following the recommendations in the previous section for a typical HA topology, we will use 3 OpenStack controllers.
|
||||
* **Cobbler server and Puppet Master.** The heart of a Fuel install is the combination of Puppet Master and Cobbler used to create your resources. Although Cobbler and Puppet Master can be installed on separate machines, it is common practice to install both on a single machine for small to medium size clouds, and that's what we'll be doing in this example. (By default, the Fuel ISO creates a single server with both services.)
|
||||
* **Domain name.** Puppet clients generate a Certificate Signing Request (CSR), which is then signed by Puppet Master. The signed certificate can then be used to authenticate the client during provisioning. Certificate generation requires a fully qualified hostname, so you must choose a domain name to be used in your installation. We'll leave this up to you.
|
||||
* **Network addresses.** OpenStack requires a minimum of three networks. If you are deploying on physical hardware two of them -- the public network and the internal, or management network -- must be routable in your networking infrastructure. Additionally, a set of private network addresses should be selected for automatic assignment to guest VMs. (These are fixed IPs for the private network). In our case, we are allocating network addresses as follows:
|
||||
|
||||
* Public network: 10.20.1.0/24
|
||||
* Internal network: 10.20.0.0/24
|
||||
* Private network: 192.168.0.0/16
|
||||
|
||||
* **Network interfaces.** All of those networks need to be assigned to the available NIC cards on the allocated machines. Additionally, if a fourth NIC is available, Cinder or block storage traffic can also be separated and delegated to the fourth NIC. In our case, were assigning networks as follows:
|
||||
|
||||
* Public network: eth0
|
||||
* Internal network: eth1
|
||||
* Private network: eth2
|
||||
|
||||
|
||||
@ -0,0 +1,23 @@
|
||||
|
||||
Before you start
|
||||
----------------
|
||||
|
||||
Before you begin your installation, you will need to make a number of important
|
||||
decisions:
|
||||
|
||||
* **OpenStack features.** You must choose which of the optional OpenStack features you want. For example, you must decide whether you want to install Swift, whether you want Glance to use Swift for image storage, whether you want Cinder for block storage, and whether you want nova-network or Quantum to handle your network connectivity. In the case of this example, we will be installing Swift, and Glance will be using it. We'll also be using Cinder for block storage. Because it can be easily installed using orchestration, we will also be using Quantum.
|
||||
* **Deployment topology.** The first decision is whether your deployment requires high availability. If you do choose to do an HA deployment, you have a choice regarding the number of controllers you want to have. Following the recommendations in the previous section for a typical HA topology, we will use 3 OpenStack controllers.
|
||||
* **Cobbler server and Puppet Master.** The heart of a Fuel install is the combination of Puppet Master and Cobbler used to create your resources. Although Cobbler and Puppet Master can be installed on separate machines, it is common practice to install both on a single machine for small to medium size clouds, and that's what we'll be doing in this example. (By default, the Fuel ISO creates a single server with both services.)
|
||||
* **Domain name.** Puppet clients generate a Certificate Signing Request (CSR), which is then signed by Puppet Master. The signed certificate can then be used to authenticate the client during provisioning. Certificate generation requires a fully qualified hostname, so you must choose a domain name to be used in your installation. We'll leave this up to you.
|
||||
* **Network addresses.** OpenStack requires a minimum of three networks. If you are deploying on physical hardware two of them -- the public network and the internal, or management network -- must be routable in your networking infrastructure. Additionally, a set of private network addresses should be selected for automatic assignment to guest VMs. (These are fixed IPs for the private network). In our case, we are allocating network addresses as follows:
|
||||
|
||||
* Public network: 10.20.1.0/24
|
||||
* Internal network: 10.20.0.0/24
|
||||
* Private network: 192.168.0.0/16
|
||||
|
||||
* **Network interfaces.** All of those networks need to be assigned to the available NIC cards on the allocated machines. Additionally, if a fourth NIC is available, Cinder or block storage traffic can also be separated and delegated to the fourth NIC. In our case, were assigning networks as follows:
|
||||
|
||||
* Public network: eth0
|
||||
* Internal network: eth1
|
||||
* Private network: eth2
|
||||
|
||||
@ -157,10 +157,4 @@ Start up VirtualBox and create a new machine as follows:
|
||||
* Attach the downloaded ISO as a drive
|
||||
|
||||
|
||||
Installing Fuel from the ISO
|
||||
----------------------------
|
||||
|
||||
Start the new machine to install the ISO. The only real installation decision you will need to make is to specify the interface through which the installer can access the Internet:
|
||||
|
||||
.. image:: /pages/installation-instructions/screenshots/fuel-iso-choose-nic.png
|
||||
|
||||
|
||||
@ -0,0 +1,7 @@
|
||||
Installing Fuel from the ISO
|
||||
----------------------------
|
||||
|
||||
Start the new machine to install the ISO. The only real installation decision you will need to make is to specify the interface through which the installer can access the Internet:
|
||||
|
||||
.. image:: /pages/installation-instructions/screenshots/fuel-iso-choose-nic.png
|
||||
|
||||
@ -51,7 +51,7 @@ Set the ``public_net_router`` to be the master node. The ``ext_bridge`` is, in
|
||||
public_interface: eth1
|
||||
private_interface: eth2
|
||||
|
||||
Earlier, we decided which interfaces to use for which networks; note that here.
|
||||
Earlier, we decided which interfaces to use for which networks; note that here. ::
|
||||
|
||||
default_gateway: 10.20.0.10
|
||||
|
||||
@ -121,7 +121,7 @@ The ``cobbler_common`` section applies to all machines::
|
||||
# for Ubuntu
|
||||
profile: "ubuntu_1204_x86_64"
|
||||
|
||||
Fuel can install CentOS or Ubuntu on your servers, or you can add a profile of your own.
|
||||
Fuel can install CentOS or Ubuntu on your servers, or you can add a profile of your own. ::
|
||||
|
||||
netboot-enabled: "1"
|
||||
# for Ubuntu
|
||||
@ -136,8 +136,8 @@ Set the default nameserver to be fuel-pm, and change the domain name to your own
|
||||
puppet_auto_setup=1 \
|
||||
puppet_master=fuel-pm.your-domain-name.com \
|
||||
|
||||
Change the fully-qualified domain name for the Puppet Master to reflect your own domain name.
|
||||
::
|
||||
Change the fully-qualified domain name for the Puppet Master to reflect your own domain name. ::
|
||||
|
||||
puppet_enable=0 \
|
||||
ntp_enable=1 \
|
||||
mco_auto_setup=1 \
|
||||
@ -193,7 +193,7 @@ Repeat that step for any additional controllers::
|
||||
static: "1"
|
||||
ip-address: "10.20.0.102"
|
||||
netmask: "255.255.255.0"
|
||||
dns-name: "fuel-controller-02.your-domain-name"
|
||||
dns-name: "fuel-controller-02.your-domain-name.com"
|
||||
management: "1"
|
||||
eth1:
|
||||
static: "0"
|
||||
@ -221,7 +221,7 @@ Repeat that step for any additional controllers::
|
||||
static: "1"
|
||||
ip-address: "10.20.0.103"
|
||||
netmask: "255.255.255.0"
|
||||
dns-name: "fuel-controller-03.your-domain-name"
|
||||
dns-name: "fuel-controller-03.your-domain-name.com"
|
||||
management: "1"
|
||||
eth1:
|
||||
static: "0"
|
||||
@ -249,7 +249,7 @@ Repeat that step for any additional controllers::
|
||||
static: "1"
|
||||
ip-address: "10.20.0.201"
|
||||
netmask: "255.255.255.0"
|
||||
dns-name: "fuel-compute-01.your-domain-name"
|
||||
dns-name: "fuel-compute-01.your-domain-name.com"
|
||||
management: "1"
|
||||
eth1:
|
||||
static: "0"
|
||||
@ -268,6 +268,13 @@ Repeat that step for any additional controllers::
|
||||
|
||||
This file has been customized for the example in the docs, but in general you will need to be certain that IP and gateway information -- in addition to the MAC addresses -- matches the decisions you made earlier in the process.
|
||||
|
||||
|
||||
Load the configuration
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Once you've completed the changes to ``config.yaml``, you need to load the information into Cobbler. To do that, use the ``cobbler_system`` script::
|
||||
|
||||
cobbler_system -f config.yaml
|
||||
|
||||
Now you're ready to start spinning up the controllers and compute nodes.
|
||||
|
||||
|
||||
|
||||
@ -153,29 +153,4 @@ architecture.
|
||||
|
||||
Lets take a closer look at the details of this topology.
|
||||
|
||||
A closer look at the Multi-node (HA) deployment (compact Swift)
|
||||
-------------------------------------------------------------------
|
||||
|
||||
In this section, you'll learn more about the Multi-node (HA) Compact
|
||||
Swift topology 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:
|
||||
|
||||
.. 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)
|
||||
management using keepalived and load balancing using HAProxy. Stateful
|
||||
OpenStack components, such as 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.
|
||||
|
||||
.. image:: https://docs.google.com/drawings/pub?id=1PzRBUaZEPMG25488mlb42fRdlFS3BygPwbAGBHudnTM&w=750&h=491
|
||||
|
||||
Lets take a closer look at what an OpenStack deployment looks like, and
|
||||
what it will take to achieve high availability for an OpenStack
|
||||
deployment.
|
||||
|
||||
|
||||
26
docs/pages/reference-architecture/0015-closer-look.rst
Normal file
26
docs/pages/reference-architecture/0015-closer-look.rst
Normal file
@ -0,0 +1,26 @@
|
||||
A closer look at the Multi-node (HA) deployment (compact Swift)
|
||||
-------------------------------------------------------------------
|
||||
|
||||
In this section, you'll learn more about the Multi-node (HA) Compact
|
||||
Swift topology 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:
|
||||
|
||||
.. 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)
|
||||
management using keepalived and load balancing using HAProxy. Stateful
|
||||
OpenStack components, such as 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.
|
||||
|
||||
.. image:: https://docs.google.com/drawings/pub?id=1PzRBUaZEPMG25488mlb42fRdlFS3BygPwbAGBHudnTM&w=750&h=491
|
||||
|
||||
Lets take a closer look at what an OpenStack deployment looks like, and
|
||||
what it will take to achieve high availability for an OpenStack
|
||||
deployment.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user