mirror of
https://github.com/clearlinux/clear-linux-documentation.git
synced 2026-08-25 09:27:37 +00:00
Merge branch 'staging' into 'master'
Staging Updating master with updates staged from dpdk branch currently in staging See merge request !50
This commit is contained in:
Binary file not shown.
|
After Width: | Height: | Size: 32 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 27 KiB |
@@ -0,0 +1,344 @@
|
||||
.. _ac-dpdk:
|
||||
|
||||
DPDK
|
||||
####
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
DPDK_ is a set of libraries and drivers for fast packet processing.
|
||||
This document describes *how to* run a basic use case that involves **l3fwd
|
||||
DPDK example**, the objective is to *send packages between 2 platforms* using a
|
||||
traffic generator called :ref:`pktgen <sec_pktgen>` where l3fwd example
|
||||
application will forward those packages (:ref:`f1`).
|
||||
|
||||
.. _f1:
|
||||
|
||||
.. figure:: _static/images/pktgen_lw3fd.png
|
||||
:align: center
|
||||
:alt: platform A and B
|
||||
|
||||
Figure 1: environment for l3fwd DPDK application.
|
||||
|
||||
|
||||
**Requirements:**
|
||||
|
||||
* 2 platform using Clear Linux (recommended release 7160 or higher).
|
||||
* both Clear Linux images have to use **kernel-native boundle**
|
||||
* Install "dpdk-dev", "os-core-dev" and "sysadmin-basic" bundles
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# swupd bundle-add dpdk-dev os-core-dev sysadmin-basic
|
||||
|
||||
* The Platforms must have 2 NICs at least each one, check Network cards compatibility, it's very important to verify if your NIC is compatible with DPDK project, you can check it in this site http://dpdk.org/doc/nics.
|
||||
* 2 Network cables.
|
||||
|
||||
|
||||
1. Disable iommu on Clear Linux (platform A and B).
|
||||
===================================================
|
||||
|
||||
1. mount the :abbr:`ESP (EFI system partition)`
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# systemctl start boot.mount
|
||||
|
||||
2. move to entries directory
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# cd /boot/loader/entries/
|
||||
|
||||
edit **Clear-linux-native-.conf** and add **intel_iommu=off** in the end of the last line.
|
||||
|
||||
3. Umount *ESP* and reboot
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# cd /
|
||||
# systemctl stop boot.mount
|
||||
# reboot
|
||||
|
||||
|
||||
2. Installing dpdk bundle on Clear Linux and build l3fwd example (platform B).
|
||||
==============================================================================
|
||||
|
||||
1. Install dpdk bundle you can use the following command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# swupd bundle-add dpdk-dev
|
||||
|
||||
2. Move to l3fwd example
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# cd /usr/share/dpdk/examples/l3fwd
|
||||
|
||||
3. Assign RTE_SDK var the path where makefiles are
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# export RTE_SDK=/usr/share/dpdk/
|
||||
|
||||
4. Assign RTE_TARGET var the value where config file is
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# export RTE_TARGET=x86_64-native-linuxapp-gcc
|
||||
|
||||
5. Build the l3fwd application and add the configuration header to CFLAGS var
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# make CFLAGS+="-include /usr/include/rte_config.h"
|
||||
|
||||
|
||||
|
||||
.. _sec_pktgen:
|
||||
|
||||
3. Building pktgen (platform A).
|
||||
================================
|
||||
|
||||
Currently **pktgen project** is not included in Clear Linux, for that reason
|
||||
it is necessary to download it from upstream and build it:
|
||||
|
||||
1. Install dpdk bundle
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# swupd bundle-add dpdk-dev
|
||||
|
||||
2. Download pktgen tar package 2.9.12 version from this site: http://dpdk.org/browse/apps/pktgen-dpdk/refs/
|
||||
|
||||
3. Decompress packages and move to uncompressed source directory.
|
||||
|
||||
4. Assign RTE_SDK var the path where makefiles are
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# export RTE_SDK=/usr/share/dpdk/
|
||||
|
||||
5. Assign RTE_TARGET var the value where config file is
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# export RTE_TARGET=x86_64-native-linuxapp-gcc
|
||||
|
||||
6. Build Pktgen project setting CONFIG_RTE_BUILD_SHARED_LIB variable with "n"
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# make CONFIG_RTE_BUILD_SHARED_LIB=n
|
||||
|
||||
|
||||
4. Binding NIC's to dpdk kernel drivers (platform A and B).
|
||||
=============================================================
|
||||
|
||||
l3fwd application will use 2 NIC's, DPDK has useful tools in order for binding NICs to DPDK modules in order to run DPDK applications.
|
||||
|
||||
1. Load dpdk I/O kernel module
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# modprobe igb_uio
|
||||
|
||||
2. Check your status of your NIC's, this in order to know which network cards are not busy, in case that another application is using them, the status will be “Active” and those NICs could not be bound.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# dpdk_nic_bind.py --status
|
||||
|
||||
3. Binding 2 available NICs using the syntax: **dpdk_nic_bind.py --bind=igb_uio <device-entry>** , example:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# dpdk_nic_bind.py --bind=igb_uio 01:00.0
|
||||
|
||||
4. Be sure that your NIC's was binding correctly checking the status (point 2), drv should has igb_uio value, at this point the NIC's are using the DPDK modules.
|
||||
|
||||
|
||||
5. Setting hugepages (platform A and B).
|
||||
==========================================
|
||||
|
||||
Clear Linux supports hugepages for the large memory pool allocation used for packet buffers.
|
||||
|
||||
1. Set number of hugepages.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
|
||||
|
||||
2. Allocate pages on NUMA machines.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# echo 1024 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
|
||||
# echo 1024 > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages
|
||||
|
||||
3. Making memory available for DPDK.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# mkdir -p /mnt/huge $ mount -t hugetlbfs nodev /mnt/huge
|
||||
|
||||
If you would like to know more about this, you can check this site: http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html
|
||||
|
||||
|
||||
6. Setting a physical environment (platform A and B).
|
||||
=====================================================
|
||||
|
||||
In order to achieve the model proposed in the introduction of this document
|
||||
(:ref:`f1`), we need to connect the first grantley’s NICs to the second
|
||||
grantley’s NICs using the network cables (:ref:`f2`).
|
||||
|
||||
.. _f2:
|
||||
|
||||
.. figure:: _static/images/pyshical_net.png
|
||||
|
||||
Figure 2: Physical network environment.
|
||||
|
||||
|
||||
7. Running l3fwd application (platform B).
|
||||
==========================================
|
||||
|
||||
l3fwd application is one of the DPDK examples available when you install dpdk-dev bundle, this application is going to forward packages for one NIC to another.
|
||||
|
||||
1. Move to l3fwd example
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# cd /usr/share/dpdk/examples/l3fwd
|
||||
|
||||
2. The next step is very important, DPDK needs poll drivers for working, these poll drivers are shared objects and they are in /usr/lib64, dpdk just support some NICs, you can see which in the next link: <http://dpdk.org/doc/nics>, you need to know which kernel module the NIC is using and choose poll driver according to your NICs.
|
||||
|
||||
3. At this point the system must have hugepages requirements and the NICs bound and the configuration for running pktgen depends to the network use case and the available system resources, use “-d” flag for setting the pull driver, example, the NICs’ are using e1000 network driver, this means that they are going to use e1000 poll driver (librte_pmd_e1000.so), it should be in /usr/lib64 in clear linux and it should be enough to add the name, e.g
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# ./build/l3fwd -c 0x3 -n 2 -d librte_pmd_e1000.so -- -p 0x3 --config="(0,0,0),(1,0,1)"
|
||||
|
||||
4. When the application start to run, it will show a lot information about the steps that l3fwd is doing, pay attention when the application in the step when it is Initializing ports, after port 0 initialization it will show a mac address and the same for port 1, save this information in order to set configuration to Pktgen project.
|
||||
|
||||
|
||||
8. Running pktgen application (platform A).
|
||||
===========================================
|
||||
|
||||
Pktgen is network traffic generator, it will be used to measure the network packaging performance in a forwarding use case.
|
||||
|
||||
1. At this point the system must have hugepages requirements and the NICs bound, and the configuration for running pktgen depends to the network use case and the available system resources, this is just a basic configuration.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# ./app/app/x86_64-native-linuxapp-gcc/pktgen -c 0xf -n 4 -- -p 0xf -P -m "1.0, 2.1"
|
||||
|
||||
2. Active colorful output (this step is optional).
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
Pktgen> theme enable
|
||||
|
||||
3. l3fwd application showed a mac address per port initialized, this mac addresses must have set in pktgen environment (Pktgen prompt): set mac <port number> <mac address> example:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
Pktgen> set mac 0 00:1E:67:CB:E8:C9
|
||||
Pktgen> set mac 1 00:1E:67:CB:E8:C9
|
||||
|
||||
4. Start to send packages using the next command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
Pktgen> start 0-1
|
||||
|
||||
5. If you have done the steps of this document correctly, you should see that pktgen is sending and receiving packages.
|
||||
|
||||
For more information about Pktgen: https://media.readthedocs.org/pdf/pktgen/latest/pktgen.pdf
|
||||
|
||||
|
||||
Annex A: Using pass-through for running on virtual machines.
|
||||
============================================================
|
||||
|
||||
This section will explain how to do in order to work in a virtual environment where virtual machines will take the control of host's NIC's.
|
||||
|
||||
1. Create a new directory and move to it.
|
||||
|
||||
2. Download "start_qemu.sh" script in order to run a kvm virtual machine:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ curl -O https://download.clearlinux.org/image/start_qemu.sh
|
||||
|
||||
3. Download a bare-metal Clear Linux image and rename it as "clear.img".
|
||||
|
||||
4. Look for entry for device and vendor & device ID:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ lspci -nn | grep Ethernet
|
||||
|
||||
This is an output example from last step: **03:00.0 Ethernet controller [0200]: Intel Corporation I350 Gigabit Network Connection [8086:1521]**
|
||||
where 8086:1521 is vendor:device ID and 03:00.0 is the entry for device this information is necessary for unbinding host's NICs.
|
||||
|
||||
5. Unbind NICs from host, this in order to do passthrough with virtual machines, currently Clear Linux support this action, you can use the following commands:
|
||||
|
||||
* echo "vendor device_ID" > /sys/bus/pci/drivers/pci-stub/new_id
|
||||
* echo "entry for device" > /sys/bus/pci/drivers/igb/unbind
|
||||
* echo "entry for device" > /sys/bus/pci/drivers/pci-stub/bind
|
||||
* echo "vendor device_ID" > /sys/bus/pci/drivers/pci-stub/remove_id
|
||||
|
||||
e.g
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ echo "8086 1521" > /sys/bus/pci/drivers/pci-stub/new_id
|
||||
$ echo "0000:03:00.0" > /sys/bus/pci/drivers/igb/unbind
|
||||
$ echo "0000:03:00.0" > /sys/bus/pci/drivers/pci-stub/bind
|
||||
$ echo "8086 1521" > /sys/bus/pci/drivers/pci-stub/remove_id
|
||||
|
||||
6. Assign to kvm virtual machine (guest) the unbound NICs previously. Modify the "start_qemu.sh" script in qemu-system-x86_64 arguments, and add the lines with the host's NICs information.
|
||||
|
||||
**-device pci-assign,host="<entry for device>",id=passnic0,addr=03.0**
|
||||
**-device pci-assign,host="<entry for device>",id=passnic1,addr=04.0**
|
||||
|
||||
e.g
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-device pci-assign,host=03:00.0,id=passnic0,addr=03.0 \
|
||||
-device pci-assign,host=03:00.3,id=passnic1,addr=04.0 \
|
||||
|
||||
5. Assign to kvm virtual machine (guest) the unbound NICs previously. Modify the "start_qemu.sh" script in qemu-system-x86_64 arguments, and add the lines with the host's NICs information.
|
||||
|
||||
**-device pci-assign,host="<entry for device>",id=passnic0,addr=03.0**
|
||||
**-device pci-assign,host="<entry for device>",id=passnic1,addr=04.0**
|
||||
|
||||
e.g
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-device pci-assign,host=03:00.0,id=passnic0,addr=03.0 \
|
||||
-device pci-assign,host=03:00.3,id=passnic1,addr=04.0 \
|
||||
|
||||
|
||||
6. If you would like to add more NUMA machines to the virtual machine, you can add the next line in Makefile boot target:
|
||||
|
||||
**-numa node,mem=<memory>,cpus=<number of cpus>**
|
||||
|
||||
e.g.
|
||||
|
||||
you have a virtual machine with 4096 of memory and 4 cpus the configuration should be next:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-numa node,mem=2048,cpus=0-1 \
|
||||
-numa node,mem=2048,cpus=2-3 \
|
||||
|
||||
this means that each NUMA machine have to use the same quantity of memory.
|
||||
|
||||
7. Run "start_qemu.sh" script.
|
||||
|
||||
|
||||
.. _DPDK: http://dpdk.org
|
||||
|
||||
@@ -0,0 +1,291 @@
|
||||
.. _ac-ovs-dpdk:
|
||||
|
||||
OpenvSwitch and DPDK
|
||||
####################
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
Using *DPDK* support on **OpenvSwitch project**, gets an important network performance, an easy way for
|
||||
understanding the magnitude of this increment is to compare to another software solution and
|
||||
even compare with itself without using DPDK support, this document describes the "HOWTO" about
|
||||
a simple use case (:ref:`f1ovs`) where one virtual machine sends 1 million of HTTP requests to
|
||||
another virtual machine using Linux bridges, OpenvSwitch bridges and of course
|
||||
OpenvSwitch-DPDK bridges as a network link.
|
||||
|
||||
.. _f1ovs:
|
||||
|
||||
.. figure:: _static/images/use_case.png
|
||||
|
||||
Figure 1: Basic virtual network environment.
|
||||
|
||||
**Requirements:**
|
||||
|
||||
* 1 platform using Clear Linux (recommended release 7160) for host
|
||||
* The Clear Linux image for host has to use kernel-native
|
||||
* Install "network-advanced" and "os-clr-on-clr" bundles
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# swupd bundle-add network-advanced os-clr-on-clr
|
||||
|
||||
* Get 2 Clear Linux kvm images (recommended release 7160), these images will be the guest virtual machines, you can download them https://download.clearlinux.org/releases/. The virtual machines must have installed "network-basic" and "lamp-basic" bundles.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# swupd bundle-add network-basic lamp-basic
|
||||
|
||||
|
||||
Using Linux Bridges
|
||||
===================
|
||||
|
||||
1. Create an UP script for linux bridge in a virtual machine **(qemu-ifup)**.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
#!/bin/bash
|
||||
set -x
|
||||
switch=br0
|
||||
if [ -n "$1" ];then
|
||||
tunctl -u whoami -t $1
|
||||
ip link set $1 up
|
||||
sleep 0.5s
|
||||
brctl addif $switch $1
|
||||
exit 0
|
||||
else
|
||||
echo "Error: no interface specified"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
2. Change permissions to up script.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# chmod a+x qemu-ifup
|
||||
|
||||
3. Create a bridge using the openvswitch tool, you can verify if the bridge was created using ip tool.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# brctl addbr br0
|
||||
|
||||
Note: At this point as an option is possible to add a NIC with the next command: **brctl addif br0 <network interface>** e.g:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# brctl addif br0 enp3s0f0
|
||||
|
||||
If the last option is used, and the NIC is connected to DHCP server, the 1 and 2 steps should be omitted in "Setting ip address" section.
|
||||
|
||||
4. Setup the linux bridge
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# ip link set dev br0 up
|
||||
|
||||
5. Run guest virtual machine A using the next configuration as reference, where **$IMAGE** var is the clear linux image name.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
qemu-system-x86_64 \
|
||||
-enable-kvm -m 1024 \
|
||||
-bios OVMF.fd \
|
||||
-smp cpus=2,cores=1 -cpu host \
|
||||
-vga none -nographic \
|
||||
-drive file="$IMAGE",if=virtio,aio=threads \
|
||||
-net nic,macaddr=00:11:22:33:44:55,model=virtio -net tap,script=qemu-ifup \
|
||||
-debugcon file:debug.log -global isa-debugcon.iobase=0x402
|
||||
|
||||
|
||||
6. Run guest virtual machine B using the configuration from step 4, only it's necessary to change the mac address, example: 00:11:22:33:44:56
|
||||
|
||||
7. Follow instructions from "Setting ip address" section.
|
||||
|
||||
8. In order to clean the previous environment, turn off the virtual machines and delete the bridge.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# ip link set dev br0 down
|
||||
# brctl delbr br0
|
||||
|
||||
|
||||
Using OpenvSwitch
|
||||
=================
|
||||
|
||||
1. Start OpenvSwitch service.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# systemctl start openvswitch.service
|
||||
|
||||
2. Create a bridge using the openvswitch tool, you can verify if the bridge was created using ip tool.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# ovs-vsctl add-br br0
|
||||
# ip a
|
||||
|
||||
3. Create **UP-DOWN** scripts, this is in order to bring up the tap devices into the bridge created in the step 2 for **ovs-ifdown** script:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
#!/bin/sh
|
||||
switch="br0"
|
||||
/usr/bin/ifconfig $1 0.0.0.0 down
|
||||
ovs-vsctl del-port ${switch} $1
|
||||
|
||||
and for **ovs-ifup script**:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
#!/bin/sh
|
||||
switch="br0"
|
||||
/usr/bin/ifconfig $1 0.0.0.0 up
|
||||
ovs-vsctl add-port ${switch} $1
|
||||
|
||||
4. Change permissions to up-down scripts
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# chmod a+x ovs-ifdown
|
||||
# chmod a+x ovs-ifup
|
||||
|
||||
5. Run guest virtual machine A using the next configuration as reference, where **$IMAGE** var is the clear linux image name, notice that network configuration use the up-down scripts (step ).
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
qemu-system-x86_64 \
|
||||
-enable-kvm -m 1024 \
|
||||
-bios OVMF.fd \
|
||||
-smp cpus=2,cores=1 -cpu host \
|
||||
-vga none -nographic \
|
||||
-drive file="$IMAGE",if=virtio,aio=threads \
|
||||
-net nic,model=virtio,macaddr=00:11:22:33:44:55 -net tap,script=ovs-ifup,downscript=ovs-ifdown \
|
||||
-debugcon file:debug.log -global isa-debugcon.iobase=0x402
|
||||
|
||||
6. Run guest virtual machine B using the configuration from step 5, only it's necessary to change the mac address, you could use this: *00:11:22:33:44:56*
|
||||
|
||||
7. Follow instructions from "Setting ip address" section.
|
||||
|
||||
|
||||
Using Linux OpenvSwitch-DPDK
|
||||
============================
|
||||
|
||||
1. Use a new environment and add **iommu=pt intel_iommu=on** to kernel command line.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# systemctl start boot.mount
|
||||
# cd /boot/loader/entries/
|
||||
|
||||
Edit Clear-linux-native-<kernel-version>.conf and add **iommu=pt intel_iommu=on** in the end of the line, umount and reboot.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# cd /
|
||||
# systemctl stop boot.mount
|
||||
# reboot
|
||||
|
||||
|
||||
2. Set number of hugepages
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
|
||||
|
||||
3. Allocate pages on NUMA machines
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# echo 1024 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
|
||||
# echo 1024 > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages
|
||||
|
||||
4. Making memory available for DPDK.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# mkdir -p /mnt/huge
|
||||
# mount -t hugetlbfs nodev /mnt/huge
|
||||
|
||||
5. Add cores and memory configuration to OpenvSwitch example, the file **/usr/share/openvswitch/scripts/ovs-ctl** can be edited in the line 256 and add DPDK configuration it should look like this: **set ovs-vswitchd --dpdk -c 0x2 -n 4 --socket-mem 2048 -- unix:"$DB_SOCK"** or the next regular expression could be helpful:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# sed -i s/"set ovs-vswitchd unix:"/"set ovs-vswitchd --dpdk -c 0x2 -n 4 --socket-mem 2048 -- unix:"/g /usr/share/openvswitch/scripts/ovs-ctl
|
||||
|
||||
6. Start OpenvSwitch service
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# systemctl start openvswitch.service
|
||||
|
||||
7. Create a virtual bridge using openvswitch
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev
|
||||
|
||||
8. Add dpdk ports to the bridge
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# ovs-vsctl add-port br0 vhost-user1 -- set Interface vhost-user1 type=dpdkvhostuser
|
||||
# ovs-vsctl add-port br0 vhost-user2 -- set Interface vhost-user2 type=dpdkvhostuser
|
||||
|
||||
|
||||
9. Run guest virtual machine A using the next configuration as reference, where **$IMAGE** var is the clear linux image name.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
qemu-system-x86_64 \
|
||||
-enable-kvm -m 1024 \
|
||||
-bios OVMF.fd \
|
||||
-smp 4 -cpu host \
|
||||
-vga none -nographic \
|
||||
-drive file="$IMAGE",if=virtio,aio=threads \
|
||||
-chardev socket,id=char1,path=/run/openvswitch/vhost-user1 \
|
||||
-netdev type=vhost-user,id=mynet1,chardev=char1,vhostforce \
|
||||
-device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1 \
|
||||
-object memory-backend-file,id=mem,size=1024M,mem-path=/dev/hugepages,share=on \
|
||||
-numa node,memdev=mem -mem-prealloc \
|
||||
-debugcon file:debug.log -global isa-debugcon.iobase=0x402
|
||||
|
||||
|
||||
10. Run guest virtual machine B, use the configuration from step 6, only it's necessary change the mac address and the port socket, you can use 00:00:00:00:00:02 as a mac address and vhost-user2 as a socket.
|
||||
|
||||
11. Follow instructions from "Setting ip address" section.
|
||||
|
||||
|
||||
Setting ip address
|
||||
======================
|
||||
|
||||
1. Set ip address to virtual machine for virtual machine A:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# ip addr add dev enp0s2 10.0.0.5/24
|
||||
|
||||
for virtual machine B:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# ip addr add dev enp0s2 10.0.0.6/24
|
||||
|
||||
2. Check if there is communication between both virtual machines using ping tool.
|
||||
|
||||
3. Verify if apache service is running:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# systemctl status httpd.service
|
||||
# systemctl start httpd.service
|
||||
|
||||
(start httpd service only if it is inactive).
|
||||
Use apache benchmark in order to get information about the
|
||||
network performance between both virtual machines.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# ab -n 1000000 -c 100 http://10.0.0.6/
|
||||
|
||||
|
||||
@@ -0,0 +1,44 @@
|
||||
.. _configure_openstack_environment:
|
||||
|
||||
|
||||
Configure your environment
|
||||
==========================
|
||||
|
||||
Before continuing with the installation process, it's important to understand:
|
||||
|
||||
* The :file:`hosts` file; this file defines the roles your machines play in the
|
||||
overall scheme of your network mapping.
|
||||
**Note**: For more in-depth information, see :ref:`openstack_env_inventory_file`
|
||||
|
||||
* The ``group_vars/all`` structuring can be used to override variable
|
||||
values. **Note**: For more in-depth information, see :ref:`openstack_conf_vars_about`
|
||||
|
||||
Once you understand these components and are comfortable modifying them to affect
|
||||
the network configuration, you can proceed as follows:
|
||||
|
||||
#. Copy ``/usr/share/ansible/examples/openstack`` to your working directory.
|
||||
|
||||
#. Move into the copied directory.
|
||||
|
||||
#. Edit the :file:`hosts` file to specify node roles.
|
||||
|
||||
#. Edit the contents under ``group_vars/all`` to set passwords and other needed
|
||||
variables. **Note**: Default variables exist for every role in the
|
||||
:file:`roles/<role>/defaults/main.yml` file. To override a default, define
|
||||
it with specifications under ``group_vars/all``.
|
||||
|
||||
|
||||
Run the installer
|
||||
=================
|
||||
|
||||
Finally, you can run the installer.
|
||||
|
||||
#. Run the installer as follows, replacing ``<ssh_key>`` with the key you've
|
||||
previously set up::
|
||||
|
||||
$ ansible-playbook -i hosts openstack_deployment.yml --private-key=<ssh_key>
|
||||
|
||||
After running the previous command you should see the output of the tasks
|
||||
that are running.
|
||||
|
||||
At the end of the execution Ansible* will display a summary of the results.
|
||||
@@ -6,17 +6,8 @@ OpenStack* implementation
|
||||
|
||||
openstack_use_cases
|
||||
openstack_bundle_and_service_summary
|
||||
openstack_sys_req_and_pw_summary
|
||||
openstack_installing_bundles
|
||||
openstack_supporting-database
|
||||
openstack_supporting-messaging
|
||||
openstack_identity
|
||||
openstack_identity-openrc
|
||||
openstack_image
|
||||
openstack_compute
|
||||
openstack_block_storage
|
||||
openstack_dashboard
|
||||
openstack_networking
|
||||
openstack_orchestration
|
||||
openstack_telemetry
|
||||
openstack_object_storage
|
||||
installing_openstack
|
||||
configure_openstack_environment
|
||||
openstack_env_inventory_file
|
||||
openstack_conf_vars_about
|
||||
openstack_conf_vars_list
|
||||
|
||||
@@ -5,4 +5,7 @@ Advanced configuration
|
||||
:maxdepth: 2
|
||||
|
||||
network_boot
|
||||
mixer
|
||||
mixer
|
||||
ac-dpdk
|
||||
ac-ovs-dpdk
|
||||
|
||||
|
||||
@@ -0,0 +1,78 @@
|
||||
.. _installing_openstack:
|
||||
|
||||
Installing OpenStack
|
||||
####################
|
||||
|
||||
This section details an OpenStack* installation that uses
|
||||
bundles available for Clear Linux* OS for Intel® Architecture.
|
||||
|
||||
The sample configuration files that are included will likely
|
||||
require modification for your specific environment.
|
||||
|
||||
This Clear Config Management uses Ansible* as configuration management tool.
|
||||
|
||||
|
||||
Components supported by Clear Config Management
|
||||
===============================================
|
||||
|
||||
At the moment, this installer can deploy any or all of the following
|
||||
components:
|
||||
|
||||
- MariaDB
|
||||
- RabbitMQ
|
||||
- Keystone
|
||||
- Glance
|
||||
- Nova
|
||||
- Neutron
|
||||
- Dashboard (In identity node)
|
||||
- Heat
|
||||
|
||||
Note:
|
||||
-----
|
||||
|
||||
Below you will find the reference to componets supported on ClearLinux* but
|
||||
its support in Clear Config Management is still pending of development:
|
||||
|
||||
.. csv-table:: "Supported Components on ClearLinux*, but unsupported by Clear Config Management"
|
||||
:header: "Component", "Bundles", "OpenStack* official documentation"
|
||||
:widths: 20, 70, 100
|
||||
|
||||
"Swift", "openstack-object-storage and openstack-block-storage-controller", "http://docs.openstack.org/developer/swift/"
|
||||
"Cinder", "openstack-block-storage and openstack-block-storage-controller", "http://docs.openstack.org/developer/cinder/"
|
||||
"Ceilometer", "openstack-telemetry", "http://docs.openstack.org/developer/ceilometer/"
|
||||
|
||||
|
||||
Prerequisites
|
||||
=============
|
||||
|
||||
Before the installer can set up your cloud environment, these requirements
|
||||
should be completed (if they aren't already):
|
||||
|
||||
#. Create a pair of SSH keys.
|
||||
|
||||
#. Copy your public key to each node.
|
||||
|
||||
#. Create the :file:`sshd_config` in ``/etc/ssh`` if it doesn't exist::
|
||||
|
||||
# mkdir -p /etc/ssh && touch /etc/ssh/sshd_config
|
||||
|
||||
#. Allow ssh root access by adding "PermitRootLogin yes" to the ssh
|
||||
configuration.::
|
||||
|
||||
# echo "PermitRootLogin yes" >> /etc/ssh/sshd_config
|
||||
|
||||
|
||||
Using the Installer
|
||||
===================
|
||||
|
||||
This step presumes a Clear Linux* machine as the ansible host.
|
||||
|
||||
|
||||
Install the bundle
|
||||
------------------
|
||||
|
||||
#. Install the `sysadmin-hostmgmt` bundle::
|
||||
|
||||
# swupd bundle-add sysadmin-hostmgmt
|
||||
|
||||
**Next**: :ref:`configure_openstack_environment`
|
||||
+151
-102
@@ -26,34 +26,144 @@ computers that lack built-in PXE support.
|
||||
|
||||
Clear Linux Project for Intel Architecture can be configured to do network
|
||||
booting via HTTP with the help of iPXE. The following sets up an iPXE
|
||||
environment using Clear Linux OS for Intel Architecture, but the configuration
|
||||
options may apply elsewhere. First, add the ``pxe-server`` bundle to your
|
||||
system with:
|
||||
environment using Clear Linux OS for Intel Architecture, but the configuration
|
||||
options may apply elsewhere.
|
||||
|
||||
Step 1
|
||||
-------
|
||||
|
||||
Add the pxe-server bundle to your system which has all the bits to run a PXE
|
||||
server for Clear Linux.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# swupd bundle-add pxe-server
|
||||
|
||||
Step 2
|
||||
-------
|
||||
|
||||
DHCP configuration
|
||||
-------------------
|
||||
Configure the tftpd service using ``dnsmasq``. To do this, create the
|
||||
:file:`/etc/dnsmasq.conf` file with the following entries:
|
||||
|
||||
To use PXE chainloading, set up ISC DHCPD to hand out ``undionly.kpxe`` to legacy
|
||||
PXE clients and then hand out boot configuration only to iPXE clients. Do
|
||||
this by telling ISC DHCPD to use different configurations based on the DHCP user class.
|
||||
Here's one way to do this:
|
||||
.. code-block:: console
|
||||
|
||||
# cat << EOF > /etc/dnsmasq.conf
|
||||
enable-tftp
|
||||
tftp-root=/srv/tftp/
|
||||
EOF
|
||||
|
||||
Step 3
|
||||
-------
|
||||
|
||||
Download the ``undionly.kpxe`` (legacy) and ``ipxe.efi`` (EFI) files from `the
|
||||
iPXE website <http://boot.ipxe.org/>`_, and place them in your TFTP directory.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# mkdir /srv/tftp/
|
||||
# curl -o /srv/tftp/undionly.kpxe http://boot.ipxe.org/undionly.kpxe
|
||||
# curl -o /srv/tftp/ipxe.efi http://boot.ipxe.org/ipxe.efi
|
||||
|
||||
Step 4
|
||||
-------
|
||||
|
||||
Start the dnsmasq service with:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# systemctl start dnsmasq.service
|
||||
|
||||
Step 5
|
||||
-------
|
||||
|
||||
The kernel (linux), initramfs (initrd) and the iPXE scripts are transported via
|
||||
HTTP. Download the Linux kernel and initrdfiles, and place them into the http
|
||||
server root ``/var/www/pxe/``.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# mkdir -p /var/www/pxe/
|
||||
# version=$(cat /usr/share/clear/version)
|
||||
# curl -o /var/www/pxe/clear-${version}-pxe.tar.xz https://download.clearlinux.org/image/clear-${version}-pxe.tar.xz
|
||||
# tar -xJf /var/www/pxe/clear-${version}-pxe.tar.xz -C /var/www/pxe/ && rm /var/www/pxe/clear-${version}-pxe.tar.xz
|
||||
# unset version
|
||||
|
||||
Step 6
|
||||
-------
|
||||
|
||||
Create an iPXE script, and place it into the http server root
|
||||
:file:`/var/www/pxe/ipxe_boot_script.txt`.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# cat << EOF > /var/www/pxe/ipxe_boot_script.txt
|
||||
#!ipxe
|
||||
|
||||
kernel linux quiet rdinit=/usr/lib/systemd/systemd-bootchart initcall_debug tsc=reliable no_timer_check noreplace-smp rw initrd=initrd
|
||||
initrd initrd
|
||||
boot
|
||||
EOF
|
||||
|
||||
If your kernel is not named linux, either rename the kernel or create a symlink.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# kernel=$(find /var/www/pxe/ -name 'org.clearlinux.*')
|
||||
# ln -s ${kernel} /var/www/pxe/linux
|
||||
# unset kernel
|
||||
|
||||
Step 7
|
||||
-------
|
||||
|
||||
Create a configuration file for the http service (nginx in this example) to
|
||||
serve the kernel, initramfs, and ipxe_boot_script in
|
||||
:file:`/etc/nginx/nginx.conf` with the following:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# mkdir /etc/nginx/
|
||||
# cat << EOF > /etc/nginx/nginx.conf
|
||||
server {
|
||||
listen 80;
|
||||
server_name hostname;
|
||||
server_name_in_redirect off;
|
||||
location / {
|
||||
root /var/www/pxe;
|
||||
autoindex on;
|
||||
index index.html index.htm;
|
||||
}
|
||||
}
|
||||
EOF
|
||||
|
||||
Step 8
|
||||
-------
|
||||
|
||||
Start the nginx service with:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# systemctl start nginx.service
|
||||
|
||||
Step 9
|
||||
-------
|
||||
|
||||
To use PXE chainloading, set up ISC DHCPD to hand out ``undionly.kpxe`` to
|
||||
legacy PXE clients and then hand out boot configuration only to iPXE clients.
|
||||
Do this by telling ISC DHCPD to use different configurations based on the DHCP
|
||||
user class. Here’s one way to do this using the :file:`/etc/dhcpd.conf` file:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
allow booting;
|
||||
allow bootp;
|
||||
|
||||
DHCPDARGS="interface";
|
||||
|
||||
# Set up a class to assign an IP only to devices is attempting network boot.
|
||||
class "pxeclients" {
|
||||
match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
|
||||
next-server 192.168.1.1;
|
||||
if exists user-class and option user-class = "iPXE" {
|
||||
filename "http://my.web.server/real_boot_script.txt";
|
||||
filename "http://my.web.server/ipxe_boot_script.txt";
|
||||
} elsif exists client-arch and option client-arch = 9 {
|
||||
# client-arch = 9 (64-bit EFI)
|
||||
filename "ipxe.efi";
|
||||
@@ -62,6 +172,7 @@ Here's one way to do this:
|
||||
filename "undionly.kpxe";
|
||||
}
|
||||
}
|
||||
|
||||
# Private subnet, in case you aren't able to run your own network wide DHCP service.
|
||||
# Works when the machine you are network booting has two network interfaces,
|
||||
# one connected to the private PXE boot network and the other connected to an external
|
||||
@@ -73,23 +184,23 @@ Here's one way to do this:
|
||||
}
|
||||
}
|
||||
|
||||
This ensures that either iPXE image (``undionly.kpxe`` for BIOS or ``ipxe.efi`` for EFI) is handed
|
||||
out only when the DHCP request comes from a legacy PXE client or from a UEFI client. Once
|
||||
iPXE loads, the DHCP server will direct it to boot from options configured in your
|
||||
``http://my.web.server/real_boot_script.txt`` file, where ``my.web.server`` and the filename
|
||||
are replaced with your actual location.
|
||||
This ensures that either iPXE image (``undionly.kpxe`` for BIOS or ``ipxe.efi``
|
||||
for EFI) is handed out only when the DHCP request comes from a legacy PXE client
|
||||
or from a UEFI client. Once iPXE loads, the DHCP server will direct it to boot
|
||||
from options configured in your ``http://my.web.server/real_boot_script.txt``
|
||||
file.
|
||||
|
||||
The address ``192.168.1.1`` should be set to the address your TFTP server is using.
|
||||
Note.
|
||||
``192.168.1.1`` is set to the address your TFTP server is using.
|
||||
``my.web.server`` is set to the address your web server is using.
|
||||
``DHCPDARGS`` is set to the interface you are using.
|
||||
|
||||
The subnet being used in this example is private; if the DHCPD service you use applies to your
|
||||
entire network, modify the configuration as needed.
|
||||
Step 10
|
||||
-------
|
||||
|
||||
iPXE-specific options
|
||||
-----------------------
|
||||
|
||||
There are several DHCP options specific to `iPXE <http://ipxe.org/>`_ which are not recognized by the standard ISC
|
||||
dhcpd installation. To add support for these options, place the following at the start of your
|
||||
:file:`/etc/dhcpd.conf`:
|
||||
There are several DHCP options specific to `iPXE <http://ipxe.org/>`_ which are
|
||||
not recognized by the standard ISC dhcpd installation. To add suport for these
|
||||
options, place the following at the start of your :file:`/etc/dhcpd.conf`:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@@ -98,6 +209,7 @@ dhcpd installation. To add support for these options, place the following at the
|
||||
# Source: http://www.ipxe.org/howto/dhcpd #
|
||||
###################################################
|
||||
option space ipxe;
|
||||
option client-arch code 93 = unsigned integer 16;
|
||||
option ipxe-encap-opts code 175 = encapsulate ipxe;
|
||||
option ipxe.priority code 1 = signed integer 8;
|
||||
option ipxe.keep-san code 8 = unsigned integer 8;
|
||||
@@ -139,88 +251,25 @@ dhcpd installation. To add support for these options, place the following at the
|
||||
option ipxe.sdi code 40 = unsigned integer 8;
|
||||
option ipxe.nfs code 41 = unsigned integer 8;
|
||||
|
||||
Next, create an empty :file:`/var/db/dhcp.leases` file and start the dhcpd service with:
|
||||
Step 11
|
||||
-------
|
||||
|
||||
Create an empty :file:`/var/db/dhcpd.leases` file.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# mkdir /var/db/
|
||||
# touch /var/db/dhcpd.leases
|
||||
|
||||
Step 12
|
||||
-------
|
||||
|
||||
Start the dhcp service with:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# mkdir -p /var/db
|
||||
# touch /var/db/dhcp.leases
|
||||
# systemctl start dhcp4.service
|
||||
|
||||
TFTP configuration
|
||||
-----------------------
|
||||
|
||||
Clear Linux uses ``dnsmasq`` to provide the tftpd service. Modify
|
||||
:file:`/etc/dnsmasq.conf` with the following required entries:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
enable-tftp
|
||||
tftp-root=/srv/tftp/
|
||||
|
||||
Download the ``undionly.kpxe`` (legacy) and ``ipxe.efi`` (EFI) files from
|
||||
`the iPXE website <http://boot.ipxe.org/>`_ and place them in your TFTP
|
||||
directory. Then you can start the service with
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# systemctl start dnsmasq.service
|
||||
|
||||
|
||||
HTTP configuration
|
||||
-----------------------
|
||||
|
||||
The kernel (linux), initramfs (initrd) and the iPXE scripts are transported
|
||||
via HTTP. The Linux kernel and initrd files can be downloaded from
|
||||
https://download.clearlinux.org/image/ where ``clear-$version-pxe.tar.xz`` is a
|
||||
compressed tar file containing two clearly-labeled files that should be moved
|
||||
to the http server root ``/var/www/pxe/``.
|
||||
|
||||
Create a configuration file for the http service (nginx in this example) to
|
||||
serve the kernel and initramfs in :file:`/etc/nginx/nginx.conf` with the
|
||||
following:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
worker_processes 1;
|
||||
http {
|
||||
sendfile on;
|
||||
keepalive_timeout 65;
|
||||
server {
|
||||
listen 80;
|
||||
server_name hostname;
|
||||
server_name_in_redirect off;
|
||||
location / {
|
||||
root /var/www/pxe;
|
||||
autoindex on;
|
||||
index index.html index.htm;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
And start the service with:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# systemctl start nginx.service
|
||||
|
||||
|
||||
iPXE script
|
||||
-----------------------
|
||||
|
||||
The iPXE script used is
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
#!ipxe
|
||||
|
||||
kernel linux quiet rdinit=/usr/lib/systemd/systemd-bootchart initcall_debug
|
||||
tsc=reliable no_timer_check noreplace-smp rw initrd=initrd initrd initrd
|
||||
boot
|
||||
|
||||
This should be located in ``/var/www/pxe`` with the kernel and initrd.
|
||||
|
||||
|
||||
PXE + grub
|
||||
=======================
|
||||
|
||||
|
||||
@@ -1,478 +0,0 @@
|
||||
.. _openstack_block_storage:
|
||||
|
||||
Block Storage
|
||||
########################
|
||||
|
||||
The OpenStack* Block Storage service (cinder) adds persistent storage to
|
||||
a virtual machine. Block Storage provides an infrastructure for managing
|
||||
volumes, and interacts with OpenStack Compute to provide volumes for
|
||||
instances. The service also enables management of volume snapshots and
|
||||
volume types.
|
||||
|
||||
Install and configure controller node
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This section describes how to install and configure the Block
|
||||
Storage service, code-named cinder, on the controller node. This
|
||||
service requires at least one additional storage node that provides
|
||||
volumes to instances.
|
||||
|
||||
Prerequisites:
|
||||
--------------
|
||||
|
||||
Before you install and configure the Block Storage service, you
|
||||
must create a database, service credentials, and API endpoints.
|
||||
|
||||
#. To create the database, complete these steps:
|
||||
|
||||
* Use the database access client to connect to the database
|
||||
server as the ``root`` user::
|
||||
|
||||
$ mysql -u root -p
|
||||
|
||||
* Create the ``cinder`` database::
|
||||
|
||||
CREATE DATABASE cinder;
|
||||
|
||||
* Grant proper access to the ``cinder`` database::
|
||||
|
||||
GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'localhost' \
|
||||
IDENTIFIED BY 'CINDER_DBPASS';
|
||||
GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'%' \
|
||||
IDENTIFIED BY 'CINDER_DBPASS';
|
||||
|
||||
Replace ``CINDER_DBPASS`` with a suitable password.
|
||||
|
||||
* Exit the database access client.
|
||||
|
||||
#. Source the ``admin`` credentials to gain access to admin-only
|
||||
CLI commands::
|
||||
|
||||
$ source admin-openrc.sh
|
||||
|
||||
#. To create the service credentials, complete these steps:
|
||||
|
||||
* Create a ``cinder`` user::
|
||||
|
||||
$ openstack user create --domain default --password-prompt cinder
|
||||
User Password:
|
||||
Repeat User Password:
|
||||
+-----------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-----------+----------------------------------+
|
||||
| domain_id | default |
|
||||
| enabled | True |
|
||||
| id | bb279f8ffc444637af38811a5e1f0562 |
|
||||
| name | cinder |
|
||||
+-----------+----------------------------------+
|
||||
|
||||
* Add the ``admin`` role to the ``cinder`` user::
|
||||
|
||||
$ openstack role add --project service --user cinder admin
|
||||
|
||||
* Create the ``cinder`` and ``cinderv2`` service entities::
|
||||
|
||||
$ openstack service create --name cinder \
|
||||
--description "OpenStack Block Storage" volume
|
||||
+-------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------------+----------------------------------+
|
||||
| description | OpenStack Block Storage |
|
||||
| enabled | True |
|
||||
| id | ab3bbbef780845a1a283490d281e7fda |
|
||||
| name | cinder |
|
||||
| type | volume |
|
||||
+-------------+----------------------------------+
|
||||
|
||||
$ openstack service create --name cinderv2 \
|
||||
--description "OpenStack Block Storage" volumev2
|
||||
+-------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------------+----------------------------------+
|
||||
| description | OpenStack Block Storage |
|
||||
| enabled | True |
|
||||
| id | eb9fd245bdbc414695952e93f29fe3ac |
|
||||
| name | cinderv2 |
|
||||
| type | volumev2 |
|
||||
+-------------+----------------------------------+
|
||||
|
||||
.. note::
|
||||
|
||||
The Block Storage services requires two service entities.
|
||||
|
||||
#. Create the Block Storage service API endpoints::
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
volume public http://controller:8776/v1/%\(tenant_id\)s
|
||||
+--------------+-----------------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+-----------------------------------------+
|
||||
| enabled | True |
|
||||
| id | 03fa2c90153546c295bf30ca86b1344b |
|
||||
| interface | public |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | ab3bbbef780845a1a283490d281e7fda |
|
||||
| service_name | cinder |
|
||||
| service_type | volume |
|
||||
| url | http://controller:8776/v1/%(tenant_id)s |
|
||||
+--------------+-----------------------------------------+
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
volume internal http://controller:8776/v1/%\(tenant_id\)s
|
||||
+--------------+-----------------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+-----------------------------------------+
|
||||
| enabled | True |
|
||||
| id | 94f684395d1b41068c70e4ecb11364b2 |
|
||||
| interface | internal |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | ab3bbbef780845a1a283490d281e7fda |
|
||||
| service_name | cinder |
|
||||
| service_type | volume |
|
||||
| url | http://controller:8776/v1/%(tenant_id)s |
|
||||
+--------------+-----------------------------------------+
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
volume admin http://controller:8776/v1/%\(tenant_id\)s
|
||||
+--------------+-----------------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+-----------------------------------------+
|
||||
| enabled | True |
|
||||
| id | 4511c28a0f9840c78bacb25f10f62c98 |
|
||||
| interface | admin |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | ab3bbbef780845a1a283490d281e7fda |
|
||||
| service_name | cinder |
|
||||
| service_type | volume |
|
||||
| url | http://controller:8776/v1/%(tenant_id)s |
|
||||
+--------------+-----------------------------------------+
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
volumev2 public http://controller:8776/v2/%\(tenant_id\)s
|
||||
+--------------+-----------------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+-----------------------------------------+
|
||||
| enabled | True |
|
||||
| id | 513e73819e14460fb904163f41ef3759 |
|
||||
| interface | public |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | eb9fd245bdbc414695952e93f29fe3ac |
|
||||
| service_name | cinderv2 |
|
||||
| service_type | volumev2 |
|
||||
| url | http://controller:8776/v2/%(tenant_id)s |
|
||||
+--------------+-----------------------------------------+
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
volumev2 internal http://controller:8776/v2/%\(tenant_id\)s
|
||||
+--------------+-----------------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+-----------------------------------------+
|
||||
| enabled | True |
|
||||
| id | 6436a8a23d014cfdb69c586eff146a32 |
|
||||
| interface | internal |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | eb9fd245bdbc414695952e93f29fe3ac |
|
||||
| service_name | cinderv2 |
|
||||
| service_type | volumev2 |
|
||||
| url | http://controller:8776/v2/%(tenant_id)s |
|
||||
+--------------+-----------------------------------------+
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
volumev2 admin http://controller:8776/v2/%\(tenant_id\)s
|
||||
+--------------+-----------------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+-----------------------------------------+
|
||||
| enabled | True |
|
||||
| id | e652cf84dd334f359ae9b045a2c91d96 |
|
||||
| interface | admin |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | eb9fd245bdbc414695952e93f29fe3ac |
|
||||
| service_name | cinderv2 |
|
||||
| service_type | volumev2 |
|
||||
| url | http://controller:8776/v2/%(tenant_id)s |
|
||||
+--------------+-----------------------------------------+
|
||||
|
||||
.. note::
|
||||
|
||||
The Block Storage services requires endpoints for each service
|
||||
entity.
|
||||
|
||||
Install and configure components
|
||||
--------------------------------
|
||||
|
||||
#. Install OpenStack Block Storage Controller bundle::
|
||||
|
||||
# swupd bundle-add openstack-block-storage-controller
|
||||
|
||||
#. Custom configurations will be located at ``/etc/cinder``.
|
||||
|
||||
* Create ``/etc/cinder`` directory::
|
||||
|
||||
# mkdir /etc/cinder
|
||||
|
||||
* Create empty cinder configuration file in
|
||||
``/etc/cinder/cinder.conf``::
|
||||
|
||||
# touch /etc/cinder/cinder.conf
|
||||
|
||||
#. Edit the ``/etc/cinder/cinder.conf`` file and complete the following
|
||||
actions:
|
||||
|
||||
* In the ``[database]`` section, configure database access. Replace
|
||||
``CINDER_DBPASS`` with the password you chose for the
|
||||
database::
|
||||
|
||||
[database]
|
||||
...
|
||||
connection=mysql://cinder:CINDER_DBPASS@controller/cinder
|
||||
|
||||
* In the ``[DEFAULT]`` and ``[oslo_messaging_rabbit]`` section,
|
||||
configure RabbitMQ message queue access. Replace ``RABBIT_PASS``
|
||||
with the password you chose for the account in
|
||||
RabbitMQ::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
rpc_backend = rabbit
|
||||
|
||||
[oslo_messaging_rabbit]
|
||||
...
|
||||
rabbit_host = controller
|
||||
rabbit_userid = openstack
|
||||
rabbit_password = RABBIT_PASS
|
||||
|
||||
* In the ``[DEFAULT]`` and ``[keystone_authtoken]`` sections, configure
|
||||
Identity service access. Replace ``CINDER_PASS`` with the password you
|
||||
chose for the ``cinder`` user in the Identity service.::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
auth_strategy = keystone
|
||||
|
||||
[keystone_authtoken]
|
||||
...
|
||||
auth_uri = http://controller:5000
|
||||
auth_url = http://controller:35357
|
||||
auth_plugin = password
|
||||
project_domain_id = default
|
||||
user_domain_id = default
|
||||
project_name = service
|
||||
username = cinder
|
||||
password = CINDER_PASS
|
||||
|
||||
* In the ``[DEFAULT]`` section, configure the ``my_ip`` option to
|
||||
use the management interface IP address of the controller node::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
my_ip = 10.0.0.11
|
||||
|
||||
#. Populate the Block Storage database::
|
||||
|
||||
# su -s /bin/sh -c "cinder-manage db sync" cinder
|
||||
|
||||
Configure Compute to use Block Storage
|
||||
--------------------------------------
|
||||
|
||||
* Edit the ``/etc/nova/nova.conf`` file and add the following
|
||||
to it::
|
||||
|
||||
[cinder]
|
||||
os_region_name = RegionOne
|
||||
|
||||
Finalize installation
|
||||
---------------------
|
||||
|
||||
#. Restart the Compute API service::
|
||||
|
||||
# systemctl restart uwsgi@nova-api.service
|
||||
|
||||
#. Start the Block Storage services and configure them to start when
|
||||
the system boots::
|
||||
|
||||
# systemctl enable cinder-api cinder-scheduler
|
||||
# systemctl start cinder-api cinder-scheduler
|
||||
|
||||
Install and configure a storage node
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This section describes how to install and configure storage nodes
|
||||
for the Block Storage service. For simplicity, this configuration
|
||||
references one storage node with an empty local block storage device.
|
||||
The instructions use ``/dev/sdb``, but you can substitute a different
|
||||
value for your particular node.
|
||||
|
||||
The service provisions logical volumes on this device using the
|
||||
LVM driver and provides them to instances via iSCSI transport.
|
||||
You can follow these instructions with minor modifications to
|
||||
horizontally scale your environment with additional storage nodes.
|
||||
|
||||
Prerequisites
|
||||
-------------
|
||||
|
||||
#. Install the Openstack Block Storage bundle::
|
||||
|
||||
# swupd bundle-add openstack-block-storage
|
||||
|
||||
#. Create the LVM physical volume: ``/dev/sdb1`` If your system uses a
|
||||
different device name, adjust these steps accordingly::
|
||||
|
||||
# pvcreate /dev/sdb1
|
||||
Physical volume "/dev/sdb1" successfully created
|
||||
|
||||
#. Create the LVM volume group ``cinder-volumes``::
|
||||
|
||||
# vgcreate cinder-volumes /dev/sdb1
|
||||
Volume group "cinder-volumes" successfully created
|
||||
|
||||
The Block Storage service creates logical volumes in this volume
|
||||
group.
|
||||
|
||||
#. Only instances can access Block Storage volumes. However, the
|
||||
underlying operating system manages the devices associated with the
|
||||
volumes. By default, the LVM volume scanning tool scans the ``/dev``
|
||||
directory for block storage devices that contain volumes. If projects
|
||||
use LVM on their volumes, the scanning tool detects these volumes and
|
||||
attempts to cache them which can cause a variety of problems with
|
||||
both the underlying operating system and project volumes. You must
|
||||
reconfigure LVM to scan only the devices that contain the
|
||||
``cinder-volume`` volume group. Edit the ``/etc/lvm/lvm.conf`` file
|
||||
and complete the following action:
|
||||
|
||||
* In the ``devices`` section, add a filter that accepts the
|
||||
``/dev/sdb`` device and rejects all other devices::
|
||||
|
||||
devices {
|
||||
...
|
||||
filter = [ "a/sdb/", "r/.*/"]
|
||||
|
||||
Install and configure components
|
||||
--------------------------------
|
||||
|
||||
#. Edit the ``/etc/cinder/cinder.conf`` file and complete the following
|
||||
actions:
|
||||
|
||||
* In the ``[database]`` section, configure database access. Replace
|
||||
``CINDER_DBPASS`` with the password you chose for the Block Storage
|
||||
database::
|
||||
|
||||
[database]
|
||||
...
|
||||
connection = mysql://cinder:CINDER_DBPASS@controller/cinder
|
||||
|
||||
* In the ``[DEFAULT]`` and ``[oslo_messaging_rabbit]`` sections,
|
||||
configure ``RabbitMQ`` message queue access. Replace ``RABBIT_PASS``
|
||||
with the password you chose for the openstack account in
|
||||
``RabbitMQ``::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
rpc_backend = rabbit
|
||||
|
||||
[oslo_messaging_rabbit]
|
||||
...
|
||||
rabbit_host = controller
|
||||
rabbit_userid = openstack
|
||||
rabbit_password = RABBIT_PASS
|
||||
|
||||
* In the ``[DEFAULT]`` and ``[keystone_authtoken]`` sections,
|
||||
configure Identity service access. Replace ``CINDER_PASS`` with the
|
||||
password you chose for the cinder user in the Identity service::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
auth_strategy = keystone
|
||||
|
||||
[keystone_authtoken]
|
||||
...
|
||||
auth_uri = http://controller:5000
|
||||
auth_url = http://controller:35357
|
||||
auth_plugin = password
|
||||
project_domain_id = default
|
||||
user_domain_id = default
|
||||
project_name = service
|
||||
username = cinder
|
||||
password = CINDER_PASS
|
||||
|
||||
* In the ``[DEFAULT]`` section, configure the ``my_ip`` option.
|
||||
Replace ``MANAGEMENT_INTERFACE_IP_ADDRESS`` with the IP address
|
||||
of the management network interface on your storage node,
|
||||
typically 10.0.0.41 for the first node in the example
|
||||
architecture::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
my_ip = MANAGEMENT_INTERFACE_IP_ADDRESS
|
||||
|
||||
* In the ``[lvm]`` section, configure the LVM back end with the LVM
|
||||
driver, ``cinder-volumes`` volume group, iSCSI protocol, and
|
||||
appropriate iSCSI service::
|
||||
|
||||
[lvm]
|
||||
...
|
||||
volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
|
||||
volume_group = cinder-volumes
|
||||
iscsi_protocol = iscsi
|
||||
iscsi_helper = tgtadm
|
||||
|
||||
* In the ``[DEFAULT]`` section, enable the LVM back end::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
enabled_backends = lvm
|
||||
|
||||
* In the ``[DEFAULT]`` section, configure the location of the Image
|
||||
service::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
glance_host = controller
|
||||
|
||||
#. Ensure files have proper ownership by running the following command::
|
||||
|
||||
# systemctl restart update-triggers.target
|
||||
|
||||
Finalize installation
|
||||
---------------------
|
||||
|
||||
#. Start the Block Storage volume service including its dependencies
|
||||
and configure them to start when the system boots::
|
||||
|
||||
# systemctl enable iscsid tgtd cinder-volume
|
||||
# systemctl start iscsid tgtd cinder-volume
|
||||
|
||||
Configuring a compute node to use Block Storage
|
||||
-----------------------------------------------
|
||||
|
||||
#. Perform the following steps to enable a compute node to work with
|
||||
block storage::
|
||||
|
||||
# systemctl enable iscsid
|
||||
# systemctl start iscsi-gen-initiatorname iscsid
|
||||
|
||||
Verify operation
|
||||
~~~~~~~~~~~~~~~~
|
||||
Verify operation of the Block Storage service.
|
||||
|
||||
#. Source the ``admin`` credentials to gain access to
|
||||
admin-only CLI commands::
|
||||
|
||||
$ source admin-openrc.sh
|
||||
|
||||
#. List service components to verify successful launch of each process::
|
||||
|
||||
$ cinder service-list
|
||||
+------------------+------------+------+---------+-------+----------------------------+-----------------+
|
||||
| Binary | Host | Zone | Status | State | Updated_at | Disabled Reason |
|
||||
+------------------+------------+------+---------+-------+----------------------------+-----------------+
|
||||
| cinder-scheduler | controller | nova | enabled | up | 2014-10-18T01:30:54.000000 | None |
|
||||
| cinder-volume | block1@lvm | nova | enabled | up | 2014-10-18T01:30:57.000000 | None |
|
||||
+------------------+------------+------+---------+-------+----------------------------+-----------------+
|
||||
|
||||
Next topic: :ref:`openstack_dashboard`.
|
||||
@@ -6,10 +6,9 @@ OpenStack* bundle and service summary
|
||||
OpenStack provides an Infrastructure-as-a-Service (IaaS) solution
|
||||
through a variety of complementary services. Each service offers an
|
||||
application programming interface (API) that facilitates this
|
||||
integration. The following table provides a list of OpenStack MVP
|
||||
services:
|
||||
integration. The following table provides a list of OpenStack services:
|
||||
|
||||
.. csv-table:: OpenStack MVP services
|
||||
.. csv-table:: OpenStack services
|
||||
:header: "Bundle Name (service)", "Project Name", "Description"
|
||||
:widths: 90, 90, 300
|
||||
|
||||
@@ -63,4 +62,4 @@ uses a two-node architecture.
|
||||
using overlay segmentation methods. Additionally, this option provides
|
||||
the foundation for advanced services such as LBaaS and FWaaS.
|
||||
|
||||
Next topic: :ref:`openstack_sys_req_and_pw_summary`.
|
||||
Next topic: :ref:`installing_openstack`.
|
||||
|
||||
@@ -1,527 +0,0 @@
|
||||
.. _openstack_compute:
|
||||
|
||||
Compute
|
||||
##################
|
||||
|
||||
Use OpenStack Compute to host and manage cloud computing systems.
|
||||
OpenStack Compute interacts with OpenStack Identity for authentication,
|
||||
OpenStack Image Service for disk and server images, and OpenStack
|
||||
Dashboard for the user and administrative interface. Image access is
|
||||
limited by projects, and by users; quotas are limited per project (the
|
||||
number of instances, for example). OpenStack Compute can scale
|
||||
horizontally on standard hardware and download images to launch
|
||||
instances.
|
||||
|
||||
Install and configure controller node
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This section describes how to install and configure the
|
||||
Compute service, code-named nova, on the controller node.
|
||||
|
||||
Prerequisites
|
||||
-------------
|
||||
|
||||
Before you install and configure the Compute service, you must
|
||||
create a database, service credentials, and API endpoints.
|
||||
|
||||
#. To create the database, complete these steps:
|
||||
|
||||
* Use the database access client to connect to the database server
|
||||
as the root user::
|
||||
|
||||
$ mysql -u root -p
|
||||
|
||||
* Create the ``nova`` database::
|
||||
|
||||
CREATE DATABASE nova;
|
||||
|
||||
* Grant proper access to the nova database. Replace ``NOVA_DBPASS``
|
||||
with a suitable password::
|
||||
|
||||
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'localhost' \
|
||||
IDENTIFIED BY 'NOVA_DBPASS';
|
||||
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'%' \
|
||||
IDENTIFIED BY 'NOVA_DBPASS';
|
||||
|
||||
* Exit the database access client.
|
||||
|
||||
#. Source the admin credentials to gain access to admin-only CLI
|
||||
commands::
|
||||
|
||||
$ source admin-openrc.sh
|
||||
|
||||
#. To create the service credentials, complete these steps:
|
||||
|
||||
* Create the ``nova`` user::
|
||||
|
||||
$ openstack user create --domain default --password-prompt nova
|
||||
User Password:
|
||||
Repeat User Password:
|
||||
+-----------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-----------+----------------------------------+
|
||||
| domain_id | default |
|
||||
| enabled | True |
|
||||
| id | 8c46e4760902464b889293a74a0c90a8 |
|
||||
| name | nova |
|
||||
+-----------+----------------------------------+
|
||||
|
||||
* Add the ``admin`` role to the ``nova`` user::
|
||||
|
||||
$ openstack role add --project service --user nova admin
|
||||
|
||||
* Create the ``nova`` service entity::
|
||||
|
||||
$ openstack service create --name nova \
|
||||
--description "OpenStack Compute" compute
|
||||
+-------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------------+----------------------------------+
|
||||
| description | OpenStack Compute |
|
||||
| enabled | True |
|
||||
| id | 060d59eac51b4594815603d75a00aba2 |
|
||||
| name | nova |
|
||||
| type | compute |
|
||||
+-------------+----------------------------------+
|
||||
|
||||
#. Create the Compute service API endpoints::
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
compute public http://controller:8774/v2/%\(tenant_id\)s
|
||||
+--------------+-----------------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+-----------------------------------------+
|
||||
| enabled | True |
|
||||
| id | 3c1caa473bfe4390a11e7177894bcc7b |
|
||||
| interface | public |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | e702f6f497ed42e6a8ae3ba2e5871c78 |
|
||||
| service_name | nova |
|
||||
| service_type | compute |
|
||||
| url | http://controller:8774/v2/%(tenant_id)s |
|
||||
+--------------+-----------------------------------------+
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
compute internal http://controller:8774/v2/%\(tenant_id\)s
|
||||
+--------------+-----------------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+-----------------------------------------+
|
||||
| enabled | True |
|
||||
| id | e3c918de680746a586eac1f2d9bc10ab |
|
||||
| interface | internal |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | e702f6f497ed42e6a8ae3ba2e5871c78 |
|
||||
| service_name | nova |
|
||||
| service_type | compute |
|
||||
| url | http://controller:8774/v2/%(tenant_id)s |
|
||||
+--------------+-----------------------------------------+
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
compute admin http://controller:8774/v2/%\(tenant_id\)s
|
||||
+--------------+-----------------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+-----------------------------------------+
|
||||
| enabled | True |
|
||||
| id | 38f7af91666a47cfb97b4dc790b94424 |
|
||||
| interface | admin |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | e702f6f497ed42e6a8ae3ba2e5871c78 |
|
||||
| service_name | nova |
|
||||
| service_type | compute |
|
||||
| url | http://controller:8774/v2/%(tenant_id)s |
|
||||
+--------------+-----------------------------------------+
|
||||
|
||||
Installing and configuring the Compute controller components
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To install and configure the Compute controller components:
|
||||
|
||||
#. Install OpenStack Compute Controller bundle::
|
||||
|
||||
# swupd bundle-add openstack-compute-controller
|
||||
|
||||
#. Custom configurations will be located at ``/etc/nova``.
|
||||
|
||||
* Create ``/etc/nova directory``::
|
||||
|
||||
# mkdir /etc/nova
|
||||
|
||||
* Create empty nova configuration file ``/etc/nova/nova.conf``::
|
||||
|
||||
# touch /etc/nova/nova.conf
|
||||
|
||||
#. Edit the ``/etc/nova/nova.conf`` file and complete the following
|
||||
actions:
|
||||
|
||||
* In the ``[database]`` section, configure database access. Replace
|
||||
``NOVA_DBPASS`` with the password you chose for the Compute database::
|
||||
|
||||
[database]
|
||||
...
|
||||
connection=mysql://nova:NOVA_DBPASS@controller/nova
|
||||
|
||||
* In the ``[DEFAULT]`` and ``[oslo_messaging_rabbit]`` sections,
|
||||
configure ``RabbitMQ`` message queue access. Replace ``RABBIT_PASS``
|
||||
with the password you chose for the guest account in RabbitMQ::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
rpc_backend = rabbit
|
||||
|
||||
[oslo_messaging_rabbit]
|
||||
...
|
||||
rabbit_host = controller
|
||||
rabbit_userid = openstack
|
||||
rabbit_password = RABBIT_PASS
|
||||
|
||||
* In the ``[DEFAULT]`` and ``[keystone_authtoken]`` sections,
|
||||
configure Identity service access. Replace ``NOVA_PASS`` with the
|
||||
password you chose for the nova user in the Identity service::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
auth_strategy = keystone
|
||||
|
||||
[keystone_authtoken]
|
||||
...
|
||||
auth_uri = http://controller:5000
|
||||
auth_url = http://controller:35357
|
||||
auth_plugin = password
|
||||
project_domain_id = default
|
||||
user_domain_id = default
|
||||
project_name = service
|
||||
username = nova
|
||||
password = NOVA_PASS
|
||||
|
||||
|
||||
* In the ``[DEFAULT]`` section, configure the ``my_ip`` option to
|
||||
use the management interface IP address of the controller node::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
my_ip = 10.0.0.11
|
||||
|
||||
* In the ``[DEFAULT]`` section, enable support for the Networking service::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
network_api_class = nova.network.neutronv2.api.API
|
||||
security_group_api = neutron
|
||||
linuxnet_interface_driver = nova.network.linux_net.NeutronLinuxBridgeInterfaceDriver
|
||||
firewall_driver = nova.virt.firewall.NoopFirewallDriver
|
||||
|
||||
* In the ``[vnc]`` section, configure the VNC proxy to use the
|
||||
management interface IP address of the controller node::
|
||||
|
||||
[vnc]
|
||||
...
|
||||
vncserver_listen = 10.0.0.11
|
||||
vncserver_proxyclient_address = 10.0.0.11
|
||||
|
||||
* In the ``[glance]`` section, configure the location of the
|
||||
Image Service::
|
||||
|
||||
[glance]
|
||||
...
|
||||
host = controller
|
||||
|
||||
#. Ensure files have proper ownership by running the following command::
|
||||
|
||||
# systemctl restart update-triggers.target
|
||||
|
||||
#. Populate the Compute database::
|
||||
|
||||
su -s /bin/sh -c "nova-manage db sync" nova
|
||||
|
||||
Finalizing Compute installation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Complete the following steps to finalize Compute installation:
|
||||
|
||||
#. Create the ``/etc/nginx`` directory if doesn't exists and setup nova-api
|
||||
and nova-metadata to start with the Nginx http server::
|
||||
|
||||
# mkdir -p /etc/nginx
|
||||
# ln -s /usr/share/nginx/conf.d/nova-api.template /etc/nginx/nova-api.conf
|
||||
|
||||
#. Restart the Nginx server to reload new configurations::
|
||||
|
||||
# systemctl restart nginx
|
||||
|
||||
#. Start the Compute Service services and configure them to start
|
||||
when the system boots::
|
||||
|
||||
# systemctl enable uwsgi@nova-api.socket \
|
||||
uwsgi@nova-metadata.socket nova-cert.service \
|
||||
nova-consoleauth.service nova-scheduler.service \
|
||||
nova-conductor.service nova-novncproxy.service
|
||||
# systemctl start uwsgi@nova-api.socket \
|
||||
uwsgi@nova-metadata.socket nova-cert.service \
|
||||
nova-consoleauth.service nova-scheduler.service \
|
||||
nova-conductor.service nova-novncproxy.service
|
||||
|
||||
Install and configure a compute note
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This section describes how to install and configure the Compute service
|
||||
on a compute node. This configuration uses the QEMU hypervisor with the
|
||||
KVM extension on compute nodes that support hardware acceleration for
|
||||
virtual machines.
|
||||
|
||||
Install and configure components
|
||||
--------------------------------
|
||||
|
||||
#. Install OpenStack Compute bundle::
|
||||
|
||||
# clr_bundle_add openstack-compute
|
||||
|
||||
#. Custom configurations will be located at ``/etc/nova``.
|
||||
|
||||
* Create ``/etc/nova`` directory::
|
||||
|
||||
# mkdir /etc/nova
|
||||
|
||||
* Create empty nova configuration file ``/etc/nova/nova.conf``::
|
||||
|
||||
# touch /etc/nova/nova.conf
|
||||
|
||||
#. Edit the ``/etc/nova/nova.conf`` file and complete the following
|
||||
actions:
|
||||
|
||||
* In the ``[DEFAULT]`` and ``[oslo_messaging_rabbit]`` sections,
|
||||
configure RabbitMQ message broker access. Replace ``RABBIT_PASS``
|
||||
with the password you chose for the ``openstack`` account in ``RabbitMQ``::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
rpc_backend = rabbit
|
||||
|
||||
[oslo_messaging_rabbit]
|
||||
...
|
||||
rabbit_host = controller
|
||||
rabbit_userid = openstack
|
||||
rabbit_password = RABBIT_PASS
|
||||
|
||||
* In the ``[DEFAULT]`` and ``[keystone_authtoken]`` sections,
|
||||
configure Identity service access. Replace ``NOVA_PASS`` with the
|
||||
password you chose for the nova user in the Identity service::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
auth_strategy = keystone
|
||||
|
||||
[keystone_authtoken]
|
||||
...
|
||||
auth_uri = http://controller:5000
|
||||
auth_url = http://controller:35357
|
||||
auth_plugin = password
|
||||
project_domain_id = default
|
||||
user_domain_id = default
|
||||
project_name = service
|
||||
username = nova
|
||||
password = NOVA_PASS
|
||||
|
||||
* In the ``[DEFAULT]`` section, configure the ``my_ip`` option.
|
||||
Replace ``MANAGEMENT_INTERFACE_IP_ADDRESS`` with the IP address of
|
||||
the management network interface on your compute node, typically
|
||||
``10.0.0.31`` for the first node in the example architecture::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
my_ip = MANAGEMENT_INTERFACE_IP_ADDRESS
|
||||
|
||||
* In the ``[DEFAULT]`` section, enable support for the Networking service::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
network_api_class = nova.network.neutronv2.api.API
|
||||
security_group_api = neutron
|
||||
linuxnet_interface_driver = nova.network.linux_net.NeutronLinuxBridgeInterfaceDriver
|
||||
firewall_driver = nova.virt.firewall.NoopFirewallDriver
|
||||
|
||||
* In the ``[vnc]`` section, enable and configure remote console access::
|
||||
|
||||
[vnc]
|
||||
...
|
||||
enabled = True
|
||||
vncserver_listen = 0.0.0.0
|
||||
vncserver_proxyclient_address = MANAGEMENT_INTERFACE_IP_ADDRESS
|
||||
novncproxy_base_url = http://controller:6080/vnc_auto.html
|
||||
|
||||
The server component listens on all IP addresses and the proxy
|
||||
component only listens on the management interface IP address of
|
||||
the compute node. The base URL indicates the location where you
|
||||
can use a web browser to access remote consoles of instances on
|
||||
this compute node.
|
||||
|
||||
* In the ``[glance]`` section, configure the location of the
|
||||
Image Service::
|
||||
|
||||
[glance]
|
||||
...
|
||||
host = controller
|
||||
|
||||
Finalize compute node installation
|
||||
----------------------------------
|
||||
|
||||
#. Determine whether your compute node supports hardware acceleration
|
||||
for virtual machines::
|
||||
|
||||
$ egrep -c '(vmx|svm)' /proc/cpuinfo
|
||||
|
||||
If this command returns a value of ``one or greater``, your compute
|
||||
node supports hardware acceleration which typically requires no
|
||||
additional configuration.
|
||||
|
||||
If this command returns a value of ``zero`` , your compute node does
|
||||
not support hardware acceleration and you must configure ``libvirt``
|
||||
to use QEMU instead of KVM.
|
||||
|
||||
* Edit the ``[libvirt]`` section in the ``/etc/nova/nova.conf`` file
|
||||
as follows::
|
||||
|
||||
[libvirt]
|
||||
...
|
||||
virt_type = qemu
|
||||
|
||||
#. Ensure files have proper ownership by running the following command::
|
||||
|
||||
# systemctl restart update-triggers.target
|
||||
|
||||
#. Start the Compute service including its dependencies and configure
|
||||
them to start automatically when the system boots::
|
||||
|
||||
# systemctl enable libvirtd.service \
|
||||
nova-compute.service
|
||||
# systemctl start libvirtd.service \
|
||||
nova-compute.service
|
||||
|
||||
Verify operation
|
||||
~~~~~~~~~~~~~~~~
|
||||
Verify operation of the Compute service.
|
||||
|
||||
*Note:* Perform these commands on the controller node.
|
||||
|
||||
#. Source the ``admin`` credentials to gain access to
|
||||
admin-only CLI commands::
|
||||
|
||||
$ source admin-openrc.sh
|
||||
|
||||
#. List service components to verify successful launch and
|
||||
registration of each process::
|
||||
|
||||
$ nova service-list
|
||||
+----+------------------+------------+----------+---------+-------+--------------+-----------------+
|
||||
| Id | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason |
|
||||
+----+------------------+------------+----------+---------+-------+--------------+-----------------+
|
||||
| 1 | nova-conductor | controller | internal | enabled | up | 2014-09-16.. | - |
|
||||
| 2 | nova-consoleauth | controller | internal | enabled | up | 2014-09-16.. | - |
|
||||
| 3 | nova-scheduler | controller | internal | enabled | up | 2014-09-16.. | - |
|
||||
| 4 | nova-cert | controller | internal | enabled | up | 2014-09-16.. | - |
|
||||
| 5 | nova-compute | compute1 | nova | enabled | up | 2014-09-16.. | - |
|
||||
+----+------------------+------------+----------+---------+-------+--------------+-----------------+
|
||||
|
||||
#. List API endpoints in the Identity service to verify connectivity
|
||||
with the Identity service::
|
||||
|
||||
$ nova endpoints
|
||||
+-----------+------------------------------------------------------------+
|
||||
| nova | Value |
|
||||
+-----------+------------------------------------------------------------+
|
||||
| id | 1fb997666b79463fb68db4ccfe4e6a71 |
|
||||
| interface | public |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| url | http://controller:8774/v2/ae7a98326b9c455588edd2656d723b9d |
|
||||
+-----------+------------------------------------------------------------+
|
||||
+-----------+------------------------------------------------------------+
|
||||
| nova | Value |
|
||||
+-----------+------------------------------------------------------------+
|
||||
| id | bac365db1ff34f08a31d4ae98b056924 |
|
||||
| interface | admin |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| url | http://controller:8774/v2/ae7a98326b9c455588edd2656d723b9d |
|
||||
+-----------+------------------------------------------------------------+
|
||||
+-----------+------------------------------------------------------------+
|
||||
| nova | Value |
|
||||
+-----------+------------------------------------------------------------+
|
||||
| id | e37186d38b8e4b81a54de34e73b43f34 |
|
||||
| interface | internal |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| url | http://controller:8774/v2/ae7a98326b9c455588edd2656d723b9d |
|
||||
+-----------+------------------------------------------------------------+
|
||||
|
||||
+-----------+----------------------------------+
|
||||
| glance | Value |
|
||||
+-----------+----------------------------------+
|
||||
| id | 41ad39f6c6444b7d8fd8318c18ae0043 |
|
||||
| interface | admin |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| url | http://controller:9292 |
|
||||
+-----------+----------------------------------+
|
||||
+-----------+----------------------------------+
|
||||
| glance | Value |
|
||||
+-----------+----------------------------------+
|
||||
| id | 50ecc4ce62724e319f4fae3861e50f7d |
|
||||
| interface | internal |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| url | http://controller:9292 |
|
||||
+-----------+----------------------------------+
|
||||
+-----------+----------------------------------+
|
||||
| glance | Value |
|
||||
+-----------+----------------------------------+
|
||||
| id | 7d3df077a20b4461a372269f603b7516 |
|
||||
| interface | public |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| url | http://controller:9292 |
|
||||
+-----------+----------------------------------+
|
||||
|
||||
+-----------+----------------------------------+
|
||||
| keystone | Value |
|
||||
+-----------+----------------------------------+
|
||||
| id | 88150c2fdc9d406c9b25113701248192 |
|
||||
| interface | internal |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| url | http://controller:5000/v2.0 |
|
||||
+-----------+----------------------------------+
|
||||
+-----------+----------------------------------+
|
||||
| keystone | Value |
|
||||
+-----------+----------------------------------+
|
||||
| id | cecab58c0f024d95b36a4ffa3e8d81e1 |
|
||||
| interface | public |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| url | http://controller:5000/v2.0 |
|
||||
+-----------+----------------------------------+
|
||||
+-----------+----------------------------------+
|
||||
| keystone | Value |
|
||||
+-----------+----------------------------------+
|
||||
| id | fc90391ae7cd4216aca070042654e424 |
|
||||
| interface | admin |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| url | http://controller:35357/v2.0 |
|
||||
+-----------+----------------------------------+
|
||||
|
||||
*Note:* Ignore any warnings in this output.
|
||||
|
||||
#. List images in the Image service catalog to verify connectivity
|
||||
with the Image service::
|
||||
|
||||
$ nova image-list
|
||||
+--------------------------------------+--------+--------+--------+
|
||||
| ID | Name | Status | Server |
|
||||
+--------------------------------------+--------+--------+--------+
|
||||
| 38047887-61a7-41ea-9b49-27987d5e8bb9 | cirros | ACTIVE | |
|
||||
+--------------------------------------+--------+--------+--------+
|
||||
|
||||
Next topic: :ref:`openstack_block_storage`.
|
||||
@@ -0,0 +1,14 @@
|
||||
.. _openstack_conf_vars_about:
|
||||
|
||||
About "group_vars/all"
|
||||
######################
|
||||
|
||||
The ``group_vars/all`` section is where you will specify the
|
||||
values for your passwords and other required or optional parameters.
|
||||
|
||||
Variables in this section are built with yaml format.
|
||||
|
||||
For a more detailed reference of the numerous variables and parameters
|
||||
that can be set, see the :ref:`openstack_conf_vars_list`.
|
||||
|
||||
**Back to Configuration Section** :ref:`configure_openstack_environment`
|
||||
@@ -0,0 +1,53 @@
|
||||
.. _openstack_conf_vars_list:
|
||||
|
||||
Variables for OpenStack Deployment
|
||||
##################################
|
||||
|
||||
This installer provides a variety of configurations you can set through
|
||||
variables; below you will find a reference of the components supported
|
||||
with Clear Linux* OS for Intel® Architecture.
|
||||
|
||||
Required Variables
|
||||
==================
|
||||
|
||||
.. csv-table::
|
||||
:header: "*(Component)* `Variable`", "Description"
|
||||
:widths: 90, 150
|
||||
|
||||
"*(Heat, Neutron, Nova, RabbitMQ)* **rabbitmq_password**", "Password of RabbitMQ user "
|
||||
"*(ALL)* **database_root_password**","Password for root database user"
|
||||
"*(Keystone)* **keystone_database_password**", "Password for 'keystone' database"
|
||||
"*(ALL)* **keystone_admin_password**", "Password for 'admin' user"
|
||||
"*(Glance)* **glance_user_password**", "Password for 'glance' user"
|
||||
"*(Glance)* **glance_database_password**", "Password for 'glance' database"
|
||||
"*(Neutron, Nova)* **nova_user_password**", "Password for 'nova' user"
|
||||
"*(Nova)* **nova_database_password**", "Password for 'nova' database"
|
||||
"*(Neutron)* **neutron_database_password**", "Password for 'neutron' database"
|
||||
"*(Neutron, Nova)* **neutron_user_password**", "Password for 'neutron' user"
|
||||
"*(Neutron, Nova)* **metadata_proxy_shared_secret**", "Secret for the metadata proxy"
|
||||
"*(Heat)* **heat_domain_admin_password**", "Password for heat domain admin user"
|
||||
"*(Heat)* **heat_user_password**", "Password for heat user"
|
||||
"*(Heat)* **heat_database_password**", "Password for heat database"
|
||||
"*(Heat)* **heat_domain**", "The heat domain that contains projects and users for stacks"
|
||||
|
||||
Optional Variables
|
||||
==================
|
||||
|
||||
.. csv-table::
|
||||
:header: "*(Component)* **Variable** : Default value", "Description"
|
||||
:widths: 90, 150
|
||||
|
||||
"*(ALL)* **swupd_args**: unset", "Optional arguments for swupd"
|
||||
"*(ALL)* **log_debug**: False", "Set to True to enable debug log level on all services"
|
||||
"*(Heat, Neutron, Nova, RabbitMQ)* **rabbitmq_username**: openstack", "User ID for RabbitMQ"
|
||||
"*(Neutron, Nova)* **neutron_public_interface_name**: unset", "Public interface of Neutron machines, if is not set, it will take the default interface reported by **ip route**"
|
||||
"*(Nova)* **nova_public_interface_name**: unset", "Public interface of Neutron machines, if is not set, it will take the default interface reported by **ip route**"
|
||||
"*(Nova)* **nova_virt_type**: qemu", "Virtualization type (qemu | kvm), if this is not set, then the playbook will try to guess it"
|
||||
"*(Neutron)* **os_tuning_params**: net.ipv4.ip_forward: 1, net.ipv4.conf.default.rp_filter: 0, net.ipv4.conf.all.rp_filter: 0, net.bridge.bridge-nf-call-iptables: 1, net.bridge.bridge-nf-call-ip6tables: 1", "syctl values needed by neutron when using openvswitch deployment scenario"
|
||||
|
||||
Note:
|
||||
-----
|
||||
If you would like to override a default, you can define it in the
|
||||
:ref:`openstack_conf_vars_about`.
|
||||
|
||||
**Back to Configuration Section** :ref:`configure_openstack_environment`
|
||||
@@ -1,33 +0,0 @@
|
||||
.. _openstack_dashboard:
|
||||
|
||||
Dashboard
|
||||
####################
|
||||
|
||||
The OpenStack* Dashboard, also known as Horizon, is a web-based interface
|
||||
for cloud administrators and users to manage various OpenStack resources
|
||||
and services.
|
||||
|
||||
The Dashboard enables web-based interactions with the
|
||||
OpenStack Compute cloud controller through the OpenStack APIs.
|
||||
|
||||
Installation and configuration
|
||||
------------------------------
|
||||
|
||||
The dashboard relies on functional core services including
|
||||
Identity, Image service, Compute, and either Networking (neutron)
|
||||
or legacy networking (nova-network). Environments with
|
||||
stand-alone services such as Object Storage cannot use the
|
||||
dashboard.
|
||||
|
||||
To get started with OpenStack Dashboard services:
|
||||
|
||||
#. Install the OpenStack Dashboard bundle::
|
||||
|
||||
# swupd bundle-add openstack-dashboard
|
||||
|
||||
#. Enable and start the dashboard socket and the Nginx server::
|
||||
|
||||
# systemctl enable nginx uwsgi@horizon.socket
|
||||
# systemctl restart nginx uwsgi@horizon.socket
|
||||
|
||||
Next topic: :ref:`openstack_networking`.
|
||||
@@ -0,0 +1,59 @@
|
||||
.. _openstack_env_inventory_file:
|
||||
|
||||
The "hosts" file
|
||||
################
|
||||
|
||||
The :file:`hosts` file is an inventory file where you specify, via
|
||||
``ini`` format, the roles your machine plays.
|
||||
|
||||
The :file:`hosts` file can be structured with different groups, where each
|
||||
group plays a specific role in your environment and network mapping.
|
||||
|
||||
Consider the following example::
|
||||
|
||||
[openstack_identity]
|
||||
192.168.50.13
|
||||
|
||||
Here, the role ``[openstack_identity]`` syntax defines the group, and
|
||||
``192.168.50.13`` specifies the machine(s) that possess that role. You
|
||||
may define multiple machines in the same group; this is a standard
|
||||
configuration for role ``[openstack_compute]`` nodes::
|
||||
|
||||
[openstack_compute]
|
||||
192.168.50.16
|
||||
192.168.50.17
|
||||
|
||||
|
||||
Inventory file groups
|
||||
---------------------
|
||||
|
||||
Below you will find the description of each group in the `hosts` file.
|
||||
|
||||
.. csv-table:: "Inventory File Groups"
|
||||
:header: "Group", "Components", "Comments"
|
||||
:widths: 40, 40, 300
|
||||
|
||||
"[dbservers]", "MariaDB", ""
|
||||
"[messaging_servers]", "RabbitMQ", ""
|
||||
"[openstack_identity]", "Keystone, Horizon", ""
|
||||
"[openstack_image]", "Glance", ""
|
||||
"[openstack_compute_controller]", "Nova", ""
|
||||
"[openstack_compute]", "Nova", "Accepts multiple entries to have multiple compute nodes. You can add more entries and re-run the installer to add them to your environment."
|
||||
"[openstack_networking]", "Neutron", ""
|
||||
"[openstack_orchestration]", "Heat", ""
|
||||
|
||||
|
||||
Important Notes
|
||||
---------------
|
||||
|
||||
* To omit any role, do not add an entry under its group section.
|
||||
|
||||
* To create an ``All In One`` scenario, specify the same machine name or IPv4
|
||||
Address under all of the groups.
|
||||
|
||||
For further reference, check out the `Ansible`_ documentation.
|
||||
|
||||
|
||||
**Back to Configuration Section** :ref:`configure_openstack_environment`
|
||||
|
||||
.. _Ansible: http://docs.ansible.com/ansible/intro_inventory.html
|
||||
@@ -1,75 +0,0 @@
|
||||
.. _openstack_identity-openrc:
|
||||
|
||||
Create OpenStack* client environment scripts
|
||||
############################################
|
||||
|
||||
The previous section used a combination of environment variables and
|
||||
command options to interact with the Identity service via the
|
||||
``openstack`` client. To increase efficiency of client operations,
|
||||
OpenStack supports simple client environment scripts also known as
|
||||
OpenRC files. These scripts typically contain common options for
|
||||
all clients but also support unique options. For more information, see the
|
||||
`OpenStack User Guide <http://docs.openstack.org/user-guide/common/
|
||||
cli_set_environment_variables_using_openstack_rc.html>`__.
|
||||
|
||||
Creating the scripts
|
||||
--------------------
|
||||
|
||||
Create client environment scripts for the ``admin`` and ``demo``
|
||||
projects and users. Future portions of this guide reference these
|
||||
scripts to load appropriate credentials for client operations.
|
||||
|
||||
#. Create the ``admin-openrc.sh`` file and add the following content::
|
||||
|
||||
export OS_PROJECT_DOMAIN_ID=default
|
||||
export OS_USER_DOMAIN_ID=default
|
||||
export OS_PROJECT_NAME=admin
|
||||
export OS_TENANT_NAME=admin
|
||||
export OS_USERNAME=admin
|
||||
export OS_PASSWORD=ADMIN_PASS
|
||||
export OS_AUTH_URL=http://controller:35357/v3
|
||||
export OS_IDENTITY_API_VERSION=3
|
||||
|
||||
Replace ``ADMIN_PASS`` with the password you chose
|
||||
for the ``admin`` user in the Identity service.
|
||||
|
||||
#. Create the ``demo-openrc.sh`` file and add the following content::
|
||||
|
||||
export OS_PROJECT_DOMAIN_ID=default
|
||||
export OS_USER_DOMAIN_ID=default
|
||||
export OS_PROJECT_NAME=demo
|
||||
export OS_TENANT_NAME=demo
|
||||
export OS_USERNAME=demo
|
||||
export OS_PASSWORD=DEMO_PASS
|
||||
export OS_AUTH_URL=http://controller:5000/v3
|
||||
export OS_IDENTITY_API_VERSION=3
|
||||
|
||||
Replace ``DEMO_PASS`` with the password you chose
|
||||
for the ``demo`` user in the Identity service.
|
||||
|
||||
Using the scripts
|
||||
-----------------
|
||||
|
||||
To run clients as a specific project and user, you can simply load
|
||||
the associated client environment script prior to running them.
|
||||
For example:
|
||||
|
||||
#. Load the ``admin-openrc.sh`` file to populate
|
||||
environment variables with the location of the Identity service
|
||||
and the ``admin`` project and user credentials::
|
||||
|
||||
$ source admin-openrc.sh
|
||||
|
||||
#. Request an authentication token::
|
||||
|
||||
$ openstack token issue
|
||||
+------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+------------+----------------------------------+
|
||||
| expires | 2015-03-25T01:45:49.950092Z |
|
||||
| id | cd4110152ac24bdeaa82e1443c910c36 |
|
||||
| project_id | cf12a15c5ea84b019aec3dc45580896b |
|
||||
| user_id | 4d411f2291f34941b30eef9bd797505a |
|
||||
+------------+----------------------------------+
|
||||
|
||||
Next topic: :ref:`openstack_image`.
|
||||
@@ -1,416 +0,0 @@
|
||||
.. _openstack_identity:
|
||||
|
||||
Identity Service
|
||||
###################
|
||||
|
||||
The OpenStack Identity service provides a single point of integration for
|
||||
managing authentication, authorization, and service catalog services.
|
||||
Additionally, it provides information about users but that are not included in
|
||||
OpenStack (such as LDAP services) can be integrated into a pre-existing
|
||||
infrastructure.
|
||||
|
||||
When installing OpenStack Identity service, you must register each
|
||||
service in your OpenStack installation. Identity service can then track
|
||||
which OpenStack services are installed and where they are located on
|
||||
the network.
|
||||
|
||||
Install and configure
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This section describes how to install and configure the OpenStack
|
||||
Identity service, code-named keystone, on the controller node. For
|
||||
performance, this configuration deploys the Nginx* HTTP server to handle
|
||||
requests.
|
||||
|
||||
Prerequisites
|
||||
-------------
|
||||
|
||||
Before you configure the OpenStack Identity service, you must create a
|
||||
database and an administration token.
|
||||
|
||||
#. To create the database, complete the following actions:
|
||||
|
||||
* Use the database access client to connect to the database server as the
|
||||
``root`` user.::
|
||||
|
||||
$ mysql -u root -p
|
||||
|
||||
* Create the ``keystone`` database.::
|
||||
|
||||
CREATE DATABASE keystone;
|
||||
|
||||
* Grant proper access to the ``keystone`` databaseReplace ``KEYSTONE_DBPASS``
|
||||
with a suitable password.::
|
||||
|
||||
GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'localhost' \
|
||||
IDENTIFIED BY 'KEYSTONE_DBPASS';
|
||||
GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'%' \
|
||||
IDENTIFIED BY 'KEYSTONE_DBPASS';
|
||||
|
||||
|
||||
* Exit the database access client.
|
||||
|
||||
#. Generate a random value to use as the administration token during
|
||||
initial configuration::
|
||||
|
||||
$ openssl rand -hex 10
|
||||
|
||||
Install and configure components
|
||||
--------------------------------
|
||||
|
||||
#. Run the following command to install the packages.::
|
||||
|
||||
# swupd bundle-add openstack-identity
|
||||
|
||||
#. Custom configurations will be located at ``/etc/keystone/``.
|
||||
|
||||
* Create the ``/etc/keystone`` directory.::
|
||||
|
||||
# mkdir /etc/keystone
|
||||
|
||||
* Create keystone configuration file ``/etc/keystone/keystone.conf``.::
|
||||
|
||||
# touch /etc/keystone/keystone.conf
|
||||
|
||||
#. Edit the ``/etc/keystone/keystone.conf`` file and complete the following
|
||||
actions:
|
||||
|
||||
* In the ``[DEFAULT]`` section, define the value of the initial
|
||||
administration token. Replace ``ADMIN_TOKEN`` with the random value that
|
||||
you generated in a previous step.::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
admin_token = ADMIN_TOKEN
|
||||
|
||||
* In the ``[database]`` section, configure database access. Replace
|
||||
``KEYSTONE_DBPASS`` with the password you chose for the database.::
|
||||
|
||||
[database]
|
||||
...
|
||||
connection = mysql://keystone:KEYSTONE_DBPASS@controller/keystone
|
||||
|
||||
|
||||
#. Ensure files have proper ownership by running the following command::
|
||||
|
||||
# systemctl restart update-triggers.target
|
||||
|
||||
#. Populate the Identity service database::
|
||||
|
||||
# su -s /bin/sh -c "keystone-manage db_sync" keystone
|
||||
|
||||
Finalize the installation
|
||||
-------------------------
|
||||
|
||||
#. Keystone is deployed as a uwsgi module. To start the Identity
|
||||
service, you should enable and start the nginx service.::
|
||||
|
||||
# systemctl enable nginx uwsgi@keystone-admin.socket \
|
||||
uwsgi@keystone-public.socket
|
||||
|
||||
# systemctl start nginx uwsgi@keystone-admin.socket \
|
||||
uwsgi@keystone-public.socket
|
||||
|
||||
|
||||
Create the service entity and API endpoints
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The Identity service provides a catalog of services and their locations.
|
||||
Each service that you add to your OpenStack environment requires a
|
||||
service entity and several API endpoints in the catalog.
|
||||
|
||||
Prerequisites
|
||||
-------------
|
||||
|
||||
You must pass the value of the authentication token to the `openstack`
|
||||
command with the ``--os-token`` parameter or set the OS_TOKEN
|
||||
environment variable. Similarly, you must also pass the value of the
|
||||
Identity service URL to the `openstack` command with the ``--os-url``
|
||||
parameter or set the OS_URL environment variable. This guide uses
|
||||
environment variables to reduce command length.
|
||||
|
||||
#. Configure the authentication token::
|
||||
|
||||
$ export OS_TOKEN=ADMIN_TOKEN
|
||||
|
||||
Replace ``ADMIN_TOKEN`` with the authentication token that you
|
||||
generated before. For example::
|
||||
|
||||
$ export OS_TOKEN=294a4c8a8a475f9b9836
|
||||
|
||||
#. Configure the endpoint URL::
|
||||
|
||||
$ export OS_URL=http://controller:35357/v3
|
||||
|
||||
#. Configure the Identity API version::
|
||||
|
||||
$ export OS_IDENTITY_API_VERSION=3
|
||||
|
||||
#. Install the OpenStack Python clients bundle::
|
||||
|
||||
# swupd bundle-add openstack-python-clients
|
||||
|
||||
|
||||
Create the service entity and API endpoints
|
||||
-------------------------------------------
|
||||
|
||||
|
||||
#. The Identity service manages a catalog of services in your OpenStack
|
||||
environment. Services use this catalog to determine the other services
|
||||
available in your environment.
|
||||
|
||||
Create the service entity for the Identity service::
|
||||
|
||||
$ openstack service create \
|
||||
--name keystone --description "OpenStack Identity" identity
|
||||
+-------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------------+----------------------------------+
|
||||
| description | OpenStack Identity |
|
||||
| enabled | True |
|
||||
| id | 4ddaae90388b4ebc9d252ec2252d8d10 |
|
||||
| name | keystone |
|
||||
| type | identity |
|
||||
+-------------+----------------------------------+
|
||||
|
||||
#. The Identity service manages a catalog of API endpoints associated with
|
||||
the services in your OpenStack environment. Services use this catalog to
|
||||
determine how to communicate with other services in your environment.
|
||||
|
||||
OpenStack uses three API endpoint variants for each service: admin,
|
||||
internal, and public. The admin API endpoint allows modifying users and
|
||||
tenants by default, while the public and internal APIs do not allow these
|
||||
operations. In a production environment, the variants might reside on
|
||||
separate networks that service different types of users for security
|
||||
reasons. For instance, the public API network might be visible from the
|
||||
Internet so customers can manage their clouds. The admin API network
|
||||
might be restricted to operators within the organization that manages
|
||||
cloud infrastructure. The internal API network might be restricted to
|
||||
the hosts that contain OpenStack services. Also, OpenStack supports
|
||||
multiple regions for scalability. For simplicity, this guide uses the
|
||||
management network for all endpoint variations and the default
|
||||
``RegionOne`` region.
|
||||
|
||||
Create the Identity service API endpoints::
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
identity public http://controller:5000/v3
|
||||
+--------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+----------------------------------+
|
||||
| enabled | True |
|
||||
| id | 30fff543e7dc4b7d9a0fb13791b78bf4 |
|
||||
| interface | public |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | 8c8c0927262a45ad9066cfe70d46892c |
|
||||
| service_name | keystone |
|
||||
| service_type | identity |
|
||||
| url | http://controller:5000/v3 |
|
||||
+--------------+----------------------------------+
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
identity internal http://controller:5000/v3
|
||||
+--------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+----------------------------------+
|
||||
| enabled | True |
|
||||
| id | 57cfa543e7dc4b712c0ab137911bc4fe |
|
||||
| interface | internal |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | 6f8de927262ac12f6066cfe70d99ac51 |
|
||||
| service_name | keystone |
|
||||
| service_type | identity |
|
||||
| url | http://controller:5000/v3 |
|
||||
+--------------+----------------------------------+
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
identity admin http://controller:35357/v3
|
||||
+--------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+----------------------------------+
|
||||
| enabled | True |
|
||||
| id | 78c3dfa3e7dc44c98ab1b1379122ecb1 |
|
||||
| interface | admin |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | 34ab3d27262ac449cba6cfe704dbc11f |
|
||||
| service_name | keystone |
|
||||
| service_type | identity |
|
||||
| url | http://controller:35357/v3 |
|
||||
+--------------+----------------------------------+
|
||||
|
||||
Creating projects, users and roles
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Complete the following steps to create projects, users and roles:
|
||||
|
||||
#. Create an administrative project, user, and role for administrative
|
||||
operations in your environment:
|
||||
|
||||
* Create the ``admin`` project::
|
||||
|
||||
$ openstack project create --domain default \
|
||||
--description "Admin Project" admin
|
||||
+-------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------------+----------------------------------+
|
||||
| description | Admin Project |
|
||||
| domain_id | default |
|
||||
| enabled | True |
|
||||
| id | 343d245e850143a096806dfaefa9afdc |
|
||||
| is_domain | False |
|
||||
| name | admin |
|
||||
| parent_id | None |
|
||||
+-------------+----------------------------------+
|
||||
|
||||
* Create the ``admin`` user::
|
||||
|
||||
$ openstack user create --domain default \
|
||||
--password-prompt admin
|
||||
User Password:
|
||||
Repeat User Password:
|
||||
+-----------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-----------+----------------------------------+
|
||||
| domain_id | default |
|
||||
| email | admin@example.com |
|
||||
| enabled | True |
|
||||
| id | ac3377633149401296f6c0d92d79dc16 |
|
||||
| name | admin |
|
||||
+-----------+----------------------------------+
|
||||
|
||||
* Create the ``admin`` role::
|
||||
|
||||
$ openstack role create admin
|
||||
+-------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------+----------------------------------+
|
||||
| id | cd2cb9a39e874ea69e5d4b896eb16128 |
|
||||
| name | admin |
|
||||
+-------+----------------------------------+
|
||||
|
||||
* Add the ``admin`` role to the ``admin`` project and user::
|
||||
|
||||
$ openstack role add --project admin --user admin admin
|
||||
|
||||
#. This guide uses a service project that contains a unique user for each
|
||||
service that you add to your environment. Create the ``service``
|
||||
project::
|
||||
|
||||
$ openstack project create --domain default \
|
||||
--description "Service Project" service
|
||||
+-------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------------+----------------------------------+
|
||||
| description | Service Project |
|
||||
| domain_id | default |
|
||||
| enabled | True |
|
||||
| id | 894cdfa366d34e9d835d3de01e752262 |
|
||||
| is_domain | False |
|
||||
| name | service |
|
||||
| parent_id | None |
|
||||
+-------------+----------------------------------+
|
||||
|
||||
#. Regular (non-admin) tasks should use an unprivileged project and user.
|
||||
As an example, this guide creates the ``demo`` project and user.
|
||||
|
||||
* Create the ``demo`` project::
|
||||
|
||||
$ openstack project create --domain default \
|
||||
--description "Demo Project" demo
|
||||
+-------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------------+----------------------------------+
|
||||
| description | Demo Project |
|
||||
| domain_id | default |
|
||||
| enabled | True |
|
||||
| id | ed0b60bf607743088218b0a533d5943f |
|
||||
| is_domain | False |
|
||||
| name | demo |
|
||||
| parent_id | None |
|
||||
+-------------+----------------------------------+
|
||||
|
||||
* Create the ``demo`` user::
|
||||
|
||||
$ openstack user create --domain default \
|
||||
--password-prompt demo
|
||||
User Password:
|
||||
Repeat User Password:
|
||||
+-----------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-----------+----------------------------------+
|
||||
| domain_id | default |
|
||||
| email | demo@example.com |
|
||||
| enabled | True |
|
||||
| id | 58126687cbcc4888bfa9ab73a2256f27 |
|
||||
| name | demo |
|
||||
+-----------+----------------------------------+
|
||||
|
||||
* Create the ``user`` role::
|
||||
|
||||
$ openstack role create user
|
||||
+-------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------+----------------------------------+
|
||||
| id | 997ce8d05fc143ac97d83fdfb5998552 |
|
||||
| name | user |
|
||||
+-------+----------------------------------+
|
||||
|
||||
* Add the ``user`` role to the ``demo`` project and user::
|
||||
|
||||
$ openstack role add --project demo --user demo user
|
||||
|
||||
Verify operation
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Verify operation of the Identity service before installing other
|
||||
services.
|
||||
|
||||
#. For security reasons, remove admin_token from
|
||||
``/etc/keystone/keystone.conf``:
|
||||
|
||||
Edit the ``[DEFAULT]`` section and remove ``admin_token``.
|
||||
|
||||
#. Restart the keystone-admin service to reload the changes::
|
||||
|
||||
# systemctl restart uwsgi@keystone-admin.service
|
||||
|
||||
#. Unset the temporary ``OS_TOKEN`` and ``OS_URL`` environment variables::
|
||||
|
||||
$ unset OS_TOKEN OS_URL
|
||||
|
||||
#. As the ``admin`` user, request an authentication token::
|
||||
|
||||
$ openstack --os-auth-url http://controller:35357/v3 \
|
||||
--os-project-domain-id default --os-user-domain-id default \
|
||||
--os-project-name admin --os-username admin --os-auth-type password \
|
||||
token issue
|
||||
Password:
|
||||
+------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+------------+----------------------------------+
|
||||
| expires | 2015-03-24T18:55:01Z |
|
||||
| id | ff5ed908984c4a4190f584d826d75fed |
|
||||
| project_id | cf12a15c5ea84b019aec3dc45580896b |
|
||||
| user_id | 4d411f2291f34941b30eef9bd797505a |
|
||||
+------------+----------------------------------+
|
||||
|
||||
#. As the ``demo`` user, request an authentication token::
|
||||
|
||||
$ openstack --os-auth-url http://controller:5000/v3 \
|
||||
--os-project-domain-id default --os-user-domain-id default \
|
||||
--os-project-name demo --os-username demo --os-auth-type password \
|
||||
token issue
|
||||
Password:
|
||||
+------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+------------+----------------------------------+
|
||||
| expires | 2014-10-10T12:51:33Z |
|
||||
| id | 1b87ceae9e08411ba4a16e4dada04802 |
|
||||
| project_id | 4aa51bb942be4dd0ac0555d7591f80a6 |
|
||||
| user_id | 7004dfa0dda84d63aef81cf7f100af01 |
|
||||
+------------+----------------------------------+
|
||||
|
||||
Next topic: :ref:`openstack_identity-openrc`.
|
||||
@@ -1,277 +0,0 @@
|
||||
.. _openstack_image:
|
||||
|
||||
Image Service
|
||||
################
|
||||
|
||||
The OpenStack Image service (glance) enables users to discover, register, and
|
||||
retrieve virtual machine images.
|
||||
|
||||
Install and configure the Image Service
|
||||
---------------------------------------
|
||||
|
||||
This section describes how to install and configure the Image service,
|
||||
code-named glance, on the controller node. For simplicity, this configuration
|
||||
stores images on the local file system. By default, this directory is
|
||||
``/var/lib/glance/images/``.
|
||||
|
||||
Prerequisites
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Before you install and configure the Image service, you must create a database,
|
||||
service credentials, and API endpoints.
|
||||
|
||||
#. To create the database, complete these steps:
|
||||
|
||||
* Use the database access client to connect to the database
|
||||
server as the ``root`` user.::
|
||||
|
||||
$ mysql -u root -p
|
||||
|
||||
* Create the ``glance`` database::
|
||||
|
||||
CREATE DATABASE glance;
|
||||
|
||||
* Grant proper access to the ``glance`` database. Replace ``GLANCE_DBPASS``
|
||||
with a suitable password.::
|
||||
|
||||
GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'localhost' \
|
||||
IDENTIFIED BY 'GLANCE_DBPASS';
|
||||
GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'%' \
|
||||
IDENTIFIED BY 'GLANCE_DBPASS';
|
||||
|
||||
* Exit the database access client.
|
||||
|
||||
#. Source the ``admin`` credentials to gain access to admin-only CLI commands.::
|
||||
|
||||
$ source admin-openrc.sh
|
||||
|
||||
#. To create the service credentials, complete these steps:
|
||||
|
||||
* Create the ``glance`` user::
|
||||
|
||||
$ openstack user create --domain default --password-prompt glance
|
||||
User Password:
|
||||
Repeat User Password:
|
||||
+-----------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-----------+----------------------------------+
|
||||
| domain_id | default |
|
||||
| enabled | True |
|
||||
| id | e38230eeff474607805b596c91fa15d9 |
|
||||
| name | glance |
|
||||
+-----------+----------------------------------+
|
||||
|
||||
* Add the ``admin`` role to the ``glance`` user and ``service`` project.::
|
||||
|
||||
$ openstack role add --project service --user glance admin
|
||||
|
||||
* Create the ``glance`` service entity.::
|
||||
|
||||
$ openstack service create --name glance \
|
||||
--description "OpenStack Image service" image
|
||||
+-------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------------+----------------------------------+
|
||||
| description | OpenStack Image service |
|
||||
| enabled | True |
|
||||
| id | 8c2c7f1b9b5049ea9e63757b5533e6d2 |
|
||||
| name | glance |
|
||||
| type | image |
|
||||
+-------------+----------------------------------+
|
||||
|
||||
#. Create the Image service API endpoints.::
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
image public http://controller:9292
|
||||
+--------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+----------------------------------+
|
||||
| enabled | True |
|
||||
| id | 340be3625e9b4239a6415d034e98aace |
|
||||
| interface | public |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | 8c2c7f1b9b5049ea9e63757b5533e6d2 |
|
||||
| service_name | glance |
|
||||
| service_type | image |
|
||||
| url | http://controller:9292 |
|
||||
+--------------+----------------------------------+
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
image internal http://controller:9292
|
||||
+--------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+----------------------------------+
|
||||
| enabled | True |
|
||||
| id | a6e4b153c2ae4c919eccfdbb7dceb5d2 |
|
||||
| interface | internal |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | 8c2c7f1b9b5049ea9e63757b5533e6d2 |
|
||||
| service_name | glance |
|
||||
| service_type | image |
|
||||
| url | http://controller:9292 |
|
||||
+--------------+----------------------------------+
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
image admin http://controller:9292
|
||||
+--------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+----------------------------------+
|
||||
| enabled | True |
|
||||
| id | 0c37ed58103f4300a84ff125a539032d |
|
||||
| interface | admin |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | 8c2c7f1b9b5049ea9e63757b5533e6d2 |
|
||||
| service_name | glance |
|
||||
| service_type | image |
|
||||
| url | http://controller:9292 |
|
||||
+--------------+----------------------------------+
|
||||
|
||||
Install and configure components
|
||||
--------------------------------
|
||||
|
||||
#. Install OpenStack Image bundle.::
|
||||
|
||||
# swupd bundle-add openstack-image
|
||||
|
||||
#. Configurations will be located at ``/etc/glance``.
|
||||
|
||||
* Create ``/etc/glance`` directory.::
|
||||
|
||||
# mkdir /etc/glance
|
||||
|
||||
* Create ``/etc/glance/glance-api.conf`` and
|
||||
``/etc/glance/glance-registry.conf`` configuration files.::
|
||||
|
||||
# touch /etc/glance/glance-{api,registry}.conf
|
||||
|
||||
#. Edit the ``/etc/glance/glance-api.conf`` file and complete the following
|
||||
actions:
|
||||
|
||||
* In the ``[database]`` section, configure database access. Replace
|
||||
``GLANCE_DBPASS`` with the password you chose for the Image service
|
||||
database.::
|
||||
|
||||
[database]
|
||||
...
|
||||
connection = mysql://glance:GLANCE_DBPASS@controller/glance
|
||||
|
||||
* In the ``[keystone_authtoken]`` section, configure Identity service access.
|
||||
Replace ``GLANCE_PASS`` with the password you chose for the ``glance`` user
|
||||
in the Identity service.::
|
||||
|
||||
[keystone_authtoken]
|
||||
...
|
||||
auth_uri = http://controller:5000
|
||||
auth_url = http://controller:35357
|
||||
auth_plugin = password
|
||||
project_domain_id = default
|
||||
user_domain_id = default
|
||||
project_name = service
|
||||
username = glance
|
||||
password = GLANCE_PASS
|
||||
|
||||
#. Edit the ``/etc/glance/glance-registry.conf`` file and complete the following
|
||||
actions:
|
||||
|
||||
* In the ``[database]`` section, configure database access. Replace
|
||||
``GLANCE_DBPASS`` with the password you chose for the Image service
|
||||
database.::
|
||||
|
||||
[database]
|
||||
...
|
||||
connection = mysql://glance:GLANCE_DBPASS@controller/glance
|
||||
|
||||
* In the ``[keystone_authtoken]`` section, configure Identity service
|
||||
access. Replace ``GLANCE_PASS`` with the password you chose for the
|
||||
``glance`` user in the Identity service.::
|
||||
|
||||
[keystone_authtoken]
|
||||
...
|
||||
auth_uri = http://controller:5000
|
||||
auth_url = http://controller:35357
|
||||
auth_plugin = password
|
||||
project_domain_id = default
|
||||
user_domain_id = default
|
||||
project_name = service
|
||||
username = glance
|
||||
password = GLANCE_PASS
|
||||
|
||||
#. Ensure files have proper ownership by running the following command::
|
||||
|
||||
# systemctl restart update-triggers.target
|
||||
|
||||
#. Populate the Image Service database::
|
||||
|
||||
# su -s /bin/sh -c "glance-manage db_sync" glance
|
||||
|
||||
Finalize installation
|
||||
---------------------
|
||||
|
||||
#. Start the Image Service services and configure them to start when the
|
||||
system boots::
|
||||
|
||||
# systemctl enable glance-api.service glance-registry.service
|
||||
# systemctl start glance-api.service glance-registry.service
|
||||
|
||||
Verify operation
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Verify operation of the Image service using
|
||||
`CirrOS <http://launchpad.net/cirros>`__, a small
|
||||
Linux image that helps you test your OpenStack deployment.
|
||||
|
||||
#. In each client environment script, configure the Image service
|
||||
client to use API version 2.0::
|
||||
|
||||
$ echo "export OS_IMAGE_API_VERSION=2" \
|
||||
| tee -a admin-openrc.sh demo-openrc.sh
|
||||
|
||||
#. Source the ``admin`` credentials to gain access to admin-only CLI commands::
|
||||
|
||||
$ source admin-openrc.sh
|
||||
|
||||
#. Download the source image::
|
||||
|
||||
$ curl -Ok http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img
|
||||
|
||||
#. Upload the image to the Image service using the `QCOW2` disk format, `bare`
|
||||
container format, and public visibility so all projects can access it::
|
||||
|
||||
$ openstack image create cirros --file cirros-0.3.4-x86_64-disk.img \
|
||||
--disk-format qcow2 --container-format bare --public
|
||||
+------------------+------------------------------------------------------+
|
||||
| Field | Value |
|
||||
+------------------+------------------------------------------------------+
|
||||
| checksum | ee1eca47dc88f4879d8a229cc70a07c6 |
|
||||
| container_format | bare |
|
||||
| created_at | 2015-10-26T23:40:03Z |
|
||||
| disk_format | qcow2 |
|
||||
| file | /v2/images/fcf6fa55-56e9-4402-8137-3e9315c84905/file |
|
||||
| id | fcf6fa55-56e9-4402-8137-3e9315c84905 |
|
||||
| min_disk | 0 |
|
||||
| min_ram | 0 |
|
||||
| name | cirros |
|
||||
| owner | 2e3093872ebf4143a122e2cc01a50d13 |
|
||||
| protected | False |
|
||||
| schema | /v2/schemas/image |
|
||||
| size | 13287936 |
|
||||
| status | active |
|
||||
| tags | |
|
||||
| updated_at | 2015-10-26T23:40:03Z |
|
||||
| virtual_size | None |
|
||||
| visibility | public |
|
||||
+------------------+------------------------------------------------------+
|
||||
|
||||
#. Confirm upload of the image and validate attributes::
|
||||
|
||||
$ openstack image list
|
||||
+--------------------------------------+--------+
|
||||
| ID | Name |
|
||||
+--------------------------------------+--------+
|
||||
| 38047887-61a7-41ea-9b49-27987d5e8bb9 | cirros |
|
||||
+--------------------------------------+--------+
|
||||
|
||||
Next topic: :ref:`openstack_compute`.
|
||||
@@ -1,26 +0,0 @@
|
||||
.. _openstack_installing_bundles:
|
||||
|
||||
Installing OpenStack* MVP bundles
|
||||
############################################################
|
||||
|
||||
Note: This article walks through an OpenStack MVP installation by using
|
||||
bundles available for Clear Linux* OS for Intel® Architecture. The sample
|
||||
configuration files that are included would likely require modification
|
||||
for your environment.
|
||||
|
||||
To install, continue with the following topics:
|
||||
|
||||
* `Database <openstack_supporting-database.html>`_
|
||||
* `Message queue <openstack_supporting-messaging.html>`_
|
||||
* `OpenStack Identity <openstack_identity.html>`_
|
||||
* `Create OpenStack client environment scripts <openstack_identity-openrc.html>`_
|
||||
* `OpenStack Image <openstack_image.html>`_
|
||||
* `OpenStack Compute <openstack_compute.html>`_
|
||||
* `OpenStack Block Storage <openstack_block_storage.html>`_
|
||||
* `OpenStack Dashboard <openstack_dashboard.html>`_
|
||||
* `OpenStack Networking <openstack_networking.html>`_
|
||||
* `OpenStack Orchestration <openstack_orchestration.html>`_
|
||||
* `OpenStack Telemetry <openstack_telemetry.html>`_
|
||||
* `OpenStack Object Storage <openstack_object_storage.html>`_
|
||||
|
||||
Next topic: :ref:`openstack_supporting-database`.
|
||||
@@ -1,672 +0,0 @@
|
||||
.. _openstack_networking:
|
||||
|
||||
Networking
|
||||
############################################################
|
||||
|
||||
OpenStack* Networking allows you to create and attach interface devices
|
||||
managed by other OpenStack services to networks. Plug-ins can be
|
||||
implemented to accommodate different networking equipment and software,
|
||||
providing flexibility to OpenStack architecture and deployment.
|
||||
|
||||
Installing and configuring the controller node
|
||||
----------------------------------------------
|
||||
|
||||
Prerequisites
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Before configuring the OpenStack Networking (neutron) service, create a
|
||||
database, service credentials, and an API endpoint.
|
||||
|
||||
#. Create the database:
|
||||
|
||||
* Use the database access client to connect to the database server
|
||||
as the ``root`` user::
|
||||
|
||||
$ mysql -u root -p
|
||||
|
||||
* Create the ``neutron`` database::
|
||||
|
||||
CREATE DATABASE neutron;
|
||||
|
||||
* Grant proper access to the ``neutron`` database. Replace
|
||||
*'NEUTRON_DBPASS'* with a suitable password::
|
||||
|
||||
GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'localhost' \
|
||||
IDENTIFIED BY 'NEUTRON_DBPASS';
|
||||
GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'%' \
|
||||
IDENTIFIED BY 'NEUTRON_DBPASS';
|
||||
|
||||
* Exit the database access client.
|
||||
|
||||
#. Source the ``admin`` credentials to gain access to admin-only CLI commands::
|
||||
|
||||
$ source admin-openrc.sh
|
||||
|
||||
#. To create the service credentials, complete these steps:
|
||||
|
||||
* Create the ``neutron`` user::
|
||||
|
||||
$ openstack user create --domain default --password-prompt neutron
|
||||
User Password:
|
||||
Repeat User Password:
|
||||
+-----------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-----------+----------------------------------+
|
||||
| domain_id | default |
|
||||
| enabled | True |
|
||||
| id | e51ef98012974e5287d857bc709f89d0 |
|
||||
| name | neutron |
|
||||
+-----------+----------------------------------+
|
||||
|
||||
* Add the ``admin`` role to the ``neutron`` user::
|
||||
|
||||
$ openstack role add --project service --user neutron admin
|
||||
|
||||
Note: This command provides no output.
|
||||
|
||||
* Create the ``neutron`` service entity::
|
||||
|
||||
$ openstack service create --name neutron \
|
||||
--description "OpenStack Networking" network
|
||||
+-------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------------+----------------------------------+
|
||||
| description | OpenStack Networking |
|
||||
| enabled | True |
|
||||
| id | a56bcd5695b943afba528192acceff01 |
|
||||
| name | neutron |
|
||||
| type | network |
|
||||
+-------------+----------------------------------+
|
||||
|
||||
#. Create the Networking service API endpoints:
|
||||
|
||||
* ::
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
network public http://controller:9696
|
||||
+--------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+----------------------------------+
|
||||
| enabled | True |
|
||||
| id | 61a8b881c8654026be84c12b943e4ee3 |
|
||||
| interface | public |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | a56bcd5695b943afba528192acceff01 |
|
||||
| service_name | neutron |
|
||||
| service_type | network |
|
||||
| url | http://controller:9696 |
|
||||
+--------------+----------------------------------+
|
||||
|
||||
* ::
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
network internal http://controller:9696
|
||||
+--------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+----------------------------------+
|
||||
| enabled | True |
|
||||
| id | 83bf338752984e1cb5305b9a6a4b4e67 |
|
||||
| interface | internal |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | a56bcd5695b943afba528192acceff01 |
|
||||
| service_name | neutron |
|
||||
| service_type | network |
|
||||
| url | http://controller:9696 |
|
||||
+--------------+----------------------------------+
|
||||
|
||||
* ::
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
network admin http://controller:9696
|
||||
+--------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+----------------------------------+
|
||||
| enabled | True |
|
||||
| id | 19cfff5a2e9a43298182f8785ea90414 |
|
||||
| interface | admin |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | a56bcd5695b943afba528192acceff01 |
|
||||
| service_name | neutron |
|
||||
| service_type | network |
|
||||
| url | http://controller:9696 |
|
||||
+--------------+----------------------------------+
|
||||
|
||||
Installing the Networking components
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Complete the following step to install the Networking components:
|
||||
|
||||
#. Install OpenStack networking bundle::
|
||||
|
||||
# swupd bundle-add openstack-network
|
||||
|
||||
Configuring the Networking server component
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Complete the following steps to configure the Networking server component:
|
||||
|
||||
#. Custom configurations will be located at ``/etc/neutron/``.
|
||||
|
||||
* Create the ``/etc/neutron`` directory::
|
||||
|
||||
# mkdir /etc/neutron
|
||||
|
||||
* Create empty neutron configuration file ``/etc/neutron/neutron.conf``::
|
||||
|
||||
# touch /etc/neutron/neutron.conf
|
||||
|
||||
#. Edit the ``/etc/neutron/neutron.conf`` file:
|
||||
|
||||
* In the ``[database]`` section, configure database access. Replace
|
||||
*NEUTRON_DBPASS* with the password you chose for the database.::
|
||||
|
||||
[database]
|
||||
...
|
||||
connection = mysql://neutron:NEUTRON_DBPASS@controller/neutron
|
||||
|
||||
* In the ``[DEFAULT]`` section, enable the Modular Layer 2 (ML2) plug-in,
|
||||
router service, and overlapping IP addresses::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
core_plugin = ml2
|
||||
service_plugins = router
|
||||
allow_overlapping_ips = True
|
||||
|
||||
* In the ``[DEFAULT]`` and ``[oslo_messaging_rabbit]`` sections, configure
|
||||
RabbitMQ message queue access. Replace *RABBIT_PASS* with the password you
|
||||
chose for the ``openstack`` account in RabbitMQ::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
rpc_backend = rabbit
|
||||
|
||||
[oslo_messaging_rabbit]
|
||||
...
|
||||
rabbit_host = controller
|
||||
rabbit_userid = openstack
|
||||
rabbit_password = RABBIT_PASS
|
||||
|
||||
* In the ``[DEFAULT]`` and ``[keystone_authtoken]`` sections, configure
|
||||
Identity service access. Replace *NEUTRON_PASS* with the password you
|
||||
chose for the ``neutron`` user in the Identity service::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
auth_strategy = keystone
|
||||
|
||||
[keystone_authtoken]
|
||||
...
|
||||
auth_uri = http://controller:5000
|
||||
auth_url = http://controller:35357
|
||||
auth_plugin = password
|
||||
project_domain_id = default
|
||||
user_domain_id = default
|
||||
project_name = service
|
||||
username = neutron
|
||||
password = NEUTRON_PASS
|
||||
|
||||
* In the ``[DEFAULT]`` and ``[nova]`` sections, configure Networking to
|
||||
notify Compute of network topology changes. Replace *NOVA_PASS* with the
|
||||
password you chose for the ``nova`` user in the Identity service::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
notify_nova_on_port_status_changes = True
|
||||
notify_nova_on_port_data_changes = True
|
||||
nova_url = http://controller:8774/v2
|
||||
|
||||
[nova]
|
||||
...
|
||||
auth_url = http://controller:35357
|
||||
auth_plugin = password
|
||||
project_domain_id = default
|
||||
user_domain_id = default
|
||||
region_name = RegionOne
|
||||
project_name = service
|
||||
username = nova
|
||||
password = NOVA_PASS
|
||||
|
||||
Configuring the Modular Layer 2 (ML2) plug-in
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The ML2 plug-in uses the Linux bridge mechanism to build layer-2 (bridging and
|
||||
switching) virtual networking infrastructure for instances.
|
||||
|
||||
#. Custom configuration will be located at ``/etc/neutron/plugins/ml2``.
|
||||
|
||||
* Create the ``/etc/neutron/plugins/ml2`` directory::
|
||||
|
||||
# mkdir -p /etc/neutron/plugins/ml2
|
||||
|
||||
* Create empty ML2 configuration file
|
||||
``/etc/neutron/plugins/ml2/ml2_conf.ini``::
|
||||
|
||||
# touch /etc/neutron/plugins/ml2/ml2_conf.ini
|
||||
|
||||
#. Edit the ``/etc/neutron/plugins/ml2/ml2_conf.ini`` file and complete the
|
||||
following actions:
|
||||
|
||||
* In the ``[ml2]`` section, enable flat, VLAN and VXLAN networks::
|
||||
|
||||
[ml2]
|
||||
...
|
||||
type_drivers = flat,vlan,vxlan
|
||||
|
||||
* In the ``[ml2]`` section, enable VXLAN project (private) networks::
|
||||
|
||||
[ml2]
|
||||
...
|
||||
tenant_network_types = vxlan
|
||||
|
||||
* In the ``[ml2]`` section, enable the Linux bridge and layer-2 population
|
||||
mechanisms::
|
||||
|
||||
[ml2]
|
||||
...
|
||||
mechanism_drivers = linuxbridge,l2population
|
||||
|
||||
* In the ``[ml2]`` section, enable the port security extension driver::
|
||||
|
||||
[ml2]
|
||||
...
|
||||
extension_drivers = port_security
|
||||
|
||||
* In the ``[ml2_type_flat]`` section, configure the public flat provider
|
||||
network::
|
||||
|
||||
[ml2_type_flat]
|
||||
...
|
||||
flat_networks = public
|
||||
|
||||
* In the [ml2_type_vxlan] section, configure the VXLAN network identifier
|
||||
range for private networks::
|
||||
|
||||
[ml2_type_vxlan]
|
||||
...
|
||||
vni_ranges = 1:1000
|
||||
|
||||
* In the [securitygroup] section, enable ipset to increase efficiency of
|
||||
security group rules::
|
||||
|
||||
[securitygroup]
|
||||
...
|
||||
enable_ipset = True
|
||||
|
||||
Configure the Linux bridge agent
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The Linux bridge agent builds layer-2 (bridging and switching) virtual
|
||||
networking infrastructure for instances including VXLAN tunnels for private
|
||||
networks and handles security groups.
|
||||
|
||||
#. Custom configuration for Linux bridge agent will be stored in
|
||||
``/etc/neutron/plugins/ml2/linuxbridge_agent.ini``::
|
||||
|
||||
# touch /etc/neutron/plugins/ml2/linuxbridge_agent.ini
|
||||
|
||||
#. Edit the ``/etc/neutron/plugins/ml2/linuxbridge_agent.ini`` file and
|
||||
complete the following actions:
|
||||
|
||||
* In the ``[linux_bridge]`` section, map the public virtual network to the
|
||||
public physical network interface. Replace *PUBLIC_INTERFACE_NAME* with
|
||||
the name of the underlying physical public network interface::
|
||||
|
||||
[linux_bridge]
|
||||
physical_interface_mappings = public:PUBLIC_INTERFACE_NAME
|
||||
|
||||
* In the ``[vxlan]`` section, enable VXLAN overlay networks, configure the
|
||||
IP address of the physical network interface that handles overlay networks,
|
||||
and enable layer-2 population. Replace *OVERLAY_INTERFACE_IP_ADDRESS*
|
||||
with the IP address of the underlying physical network interface that
|
||||
handles overlay networks::
|
||||
|
||||
[vxlan]
|
||||
enable_vxlan = True
|
||||
local_ip = OVERLAY_INTERFACE_IP_ADDRESS
|
||||
l2_population = True
|
||||
|
||||
* In the ``[agent]`` section, enable ARP spoofing protection::
|
||||
|
||||
[agent]
|
||||
...
|
||||
prevent_arp_spoofing = True
|
||||
|
||||
* In the ``[securitygroup]`` section, enable security groups and configure
|
||||
the Linux bridge iptables firewall driver::
|
||||
|
||||
[securitygroup]
|
||||
...
|
||||
enable_security_group = True
|
||||
firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver
|
||||
|
||||
|
||||
Configure the layer-3 agent
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The Layer-3 (L3) agent provides routing and NAT services for virtual networks.
|
||||
|
||||
#. Custom configuration for the Layer-3 agent will be stored in
|
||||
``/etc/neutron/l3_agent.ini``::
|
||||
|
||||
# touch /etc/neutron/l3_agent.ini
|
||||
|
||||
#. Edit the ``/etc/neutron/l3_agent.ini`` file and complete the following
|
||||
actions:
|
||||
|
||||
* In the ``[DEFAULT]`` section, configure the Linux bridge interface driver
|
||||
and external network bridge::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver
|
||||
external_network_bridge =
|
||||
|
||||
Note: The ``external_network_bridge`` option intentionally lacks a value to
|
||||
enable multiple external networks on a single agent.
|
||||
|
||||
Configure the DHCP agent
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The DHCP agent provides DHCP services for virtual networks.
|
||||
|
||||
#. Custom configuration for Linux bridge agent will be stored in
|
||||
``/etc/neutron/dhcp_agent.ini``::
|
||||
|
||||
# touch /etc/neutron/dhcp_agent.ini
|
||||
|
||||
#. Edit the /etc/neutron/dhcp_agent.ini file and complete the following actions:
|
||||
|
||||
* In the ``[DEFAULT]`` section, configure the Linux bridge interface driver,
|
||||
Dnsmasq DHCP driver, and enable isolated metadata so instances on public
|
||||
networks can access metadata over the network::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver
|
||||
dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq
|
||||
enable_isolated_metadata = True
|
||||
|
||||
Configure the metadata agent
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The metadata agent provides configuration information such as credentials to
|
||||
instances.
|
||||
|
||||
#. Custom configuration for the metadata agent will be stored in
|
||||
``/etc/neutron/metadata_agent.ini``::
|
||||
|
||||
# touch /etc/neutron/metadata_agent.ini
|
||||
|
||||
#. Edit the ``/etc/neutron/metadata_agent.ini`` file and complete the
|
||||
following actions:
|
||||
|
||||
* In the ``[DEFAULT]`` section, configure access parameters. Replace
|
||||
*NEUTRON_PASS* with the password you chose for the ``neutron`` user
|
||||
in the Identity service::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
auth_uri = http://controller:5000
|
||||
auth_url = http://controller:35357
|
||||
auth_region = RegionOne
|
||||
auth_plugin = password
|
||||
project_domain_id = default
|
||||
user_domain_id = default
|
||||
project_name = service
|
||||
username = neutron
|
||||
password = NEUTRON_PASS
|
||||
|
||||
* In the ``[DEFAULT]`` section, configure the metadata host::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
nova_metadata_ip = controller
|
||||
|
||||
* In the ``[DEFAULT]`` section, configure the metadata proxy shared secret
|
||||
Replace *METADATA_SECRET* with a suitable secret for the metadata proxy::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
metadata_proxy_shared_secret = METADATA_SECRET
|
||||
|
||||
|
||||
Configuring Compute to use Networking
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Edit the ``/etc/nova/nova.conf`` file on the controller node as follows:
|
||||
|
||||
* In the ``[neutron]`` section, configure access parameters, enable the
|
||||
metadata proxy, and configure the secret.
|
||||
|
||||
Replace *NEUTRON_PASS* with the password you chose for the ``neutron``
|
||||
user in the Identity service.
|
||||
|
||||
Replace *METADATA_SECRET* with the secret you chose for the metadata
|
||||
proxy::
|
||||
|
||||
[neutron]
|
||||
...
|
||||
url = http://controller:9696
|
||||
auth_url = http://controller:35357
|
||||
auth_plugin = password
|
||||
project_domain_id = default
|
||||
user_domain_id = default
|
||||
region_name = RegionOne
|
||||
project_name = service
|
||||
username = neutron
|
||||
password = NEUTRON_PASS
|
||||
|
||||
service_metadata_proxy = True
|
||||
metadata_proxy_shared_secret = METADATA_SECRET
|
||||
|
||||
Finalizing installation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. The Networking service initialization scripts expect a symbolic link
|
||||
``/etc/neutron/plugin.ini`` pointing to the ML2 plug-in configuration
|
||||
file, ``/etc/neutron/plugins/ml2/ml2_conf.ini``. If this symbolic
|
||||
link does not exist, create it using the following command::
|
||||
|
||||
# ln -s /etc/neutron/plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini
|
||||
|
||||
#. Ensure files have proper ownership by running the following command::
|
||||
|
||||
# systemctl restart update-triggers.target
|
||||
|
||||
#. Populate the database::
|
||||
|
||||
# su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf \
|
||||
--config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron
|
||||
|
||||
#. Restart the Compute services::
|
||||
|
||||
# systemctl restart uwsgi@nova-api.service nova-scheduler.service nova-conductor.service
|
||||
|
||||
#. Start the Networking service and configure it to start when the
|
||||
system boots::
|
||||
|
||||
# systemctl enable neutron-server.service \
|
||||
neutron-linuxbridge-agent.service \
|
||||
neutron-dhcp-agent.service \
|
||||
neutron-metadata-agent.service \
|
||||
neutron-l3-agent.service
|
||||
# systemctl start neutron-server.service \
|
||||
neutron-linuxbridge-agent.service \
|
||||
neutron-dhcp-agent.service \
|
||||
neutron-metadata-agent.service \
|
||||
neutron-l3-agent.service
|
||||
|
||||
Install and configure compute node
|
||||
----------------------------------
|
||||
|
||||
Install the components
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
* Install OpenStack networking bundle::
|
||||
|
||||
# swupd bundle-add openstack-network
|
||||
|
||||
Configure the common component
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Edit the ``/etc/neutron/neutron.conf`` file and complete the following
|
||||
actions:
|
||||
|
||||
* In the ``[DEFAULT]`` and ``[oslo_messaging_rabbit]`` sections, configure
|
||||
RabbitMQ message queue access. Replace *RABBIT_PASS* with the password you
|
||||
chose for the openstack account in RabbitMQ.::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
rpc_backend = rabbit
|
||||
|
||||
[oslo_messaging_rabbit]
|
||||
...
|
||||
rabbit_host = controller
|
||||
rabbit_userid = openstack
|
||||
rabbit_password = RABBIT_PASS
|
||||
|
||||
* In the ``[DEFAULT]`` and ``[keystone_authtoken]`` sections, configure
|
||||
Identity service access. Replace *NEUTRON_PASS* with the password you chose
|
||||
for the ``neutron`` user in the Identity service::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
auth_strategy = keystone
|
||||
|
||||
[keystone_authtoken]
|
||||
...
|
||||
auth_uri = http://controller:5000
|
||||
auth_url = http://controller:35357
|
||||
auth_plugin = password
|
||||
project_domain_id = default
|
||||
user_domain_id = default
|
||||
project_name = service
|
||||
username = neutron
|
||||
password = NEUTRON_PASS
|
||||
|
||||
Configure the Linux bridge agent
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Edit the ``/etc/neutron/plugins/ml2/linuxbridge_agent.ini`` file and complete
|
||||
the following actions:
|
||||
|
||||
* In the ``[linux_bridge]`` section, map the public virtual network to the
|
||||
public physical network interface::
|
||||
|
||||
[linux_bridge]
|
||||
physical_interface_mappings = public:PUBLIC_INTERFACE_NAME
|
||||
|
||||
* In the ``[vxlan]`` section, enable VXLAN overlay networks, configure the
|
||||
IP address of the physical network interface that handles overlay
|
||||
networks, and enable layer-2 population::
|
||||
|
||||
[vxlan]
|
||||
enable_vxlan = True
|
||||
local_ip = OVERLAY_INTERFACE_IP_ADDRESS
|
||||
l2_population = True
|
||||
|
||||
* In the ``[agent]`` section, enable ARP spoofing protection::
|
||||
|
||||
[agent]
|
||||
...
|
||||
prevent_arp_spoofing = True
|
||||
|
||||
* In the ``[securitygroup]`` section, enable security groups and configure
|
||||
the Linux bridge iptables firewall driver::
|
||||
|
||||
[securitygroup]
|
||||
...
|
||||
enable_security_group = True
|
||||
firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver
|
||||
|
||||
Configure Compute to use Networking
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Edit the ``/etc/nova/nova.conf`` file and complete the following actions:
|
||||
|
||||
* In the ``[neutron]`` section, configure access parameters. Replace
|
||||
*NEUTRON_PASS* with the password you chose for the ``neutron`` user in
|
||||
the Identity service.::
|
||||
|
||||
[neutron]
|
||||
...
|
||||
url = http://controller:9696
|
||||
auth_url = http://controller:35357
|
||||
auth_plugin = password
|
||||
project_domain_id = default
|
||||
user_domain_id = default
|
||||
region_name = RegionOne
|
||||
project_name = service
|
||||
username = neutron
|
||||
password = NEUTRON_PASS
|
||||
|
||||
Finalize installation
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Restart the Compute service::
|
||||
|
||||
# systemctl restart nova-compute.service
|
||||
|
||||
#. Restart the Linux bridge agent::
|
||||
|
||||
# systemctl enable neutron-linuxbridge-agent.service
|
||||
# systemctl restart neutron-linuxbridge-agent.service
|
||||
|
||||
Verify Operation
|
||||
----------------
|
||||
|
||||
#. Source the ``admin`` credentials to gain access to admin-only CLI commands::
|
||||
|
||||
$ source admin-openrc.sh
|
||||
|
||||
#. List loaded extensions to verify successful launch of the neutron-server
|
||||
process::
|
||||
|
||||
$ neutron ext-list
|
||||
+-----------------------+-----------------------------------------------+
|
||||
| alias | name |
|
||||
+-----------------------+-----------------------------------------------+
|
||||
| dns-integration | DNS Integration |
|
||||
| address-scope | Address scope |
|
||||
| ext-gw-mode | Neutron L3 Configurable external gateway mode |
|
||||
| binding | Port Binding |
|
||||
| agent | agent |
|
||||
| subnet_allocation | Subnet Allocation |
|
||||
| l3_agent_scheduler | L3 Agent Scheduler |
|
||||
| external-net | Neutron external network |
|
||||
| flavors | Neutron Service Flavors |
|
||||
| net-mtu | Network MTU |
|
||||
| quotas | Quota management support |
|
||||
| l3-ha | HA Router extension |
|
||||
| provider | Provider Network |
|
||||
| multi-provider | Multi Provider Network |
|
||||
| extraroute | Neutron Extra Route |
|
||||
| router | Neutron L3 Router |
|
||||
| extra_dhcp_opt | Neutron Extra DHCP opts |
|
||||
| security-group | security-group |
|
||||
| dhcp_agent_scheduler | DHCP Agent Scheduler |
|
||||
| rbac-policies | RBAC Policies |
|
||||
| port-security | Port Security |
|
||||
| allowed-address-pairs | Allowed Address Pairs |
|
||||
| dvr | Distributed Virtual Router |
|
||||
+-----------------------+-----------------------------------------------+
|
||||
|
||||
#. List agents to verify successful launch of the neutron agents::
|
||||
|
||||
$ neutron agent-list
|
||||
+--------------------------------------+--------------------+------------+-------+----------------+---------------------------+
|
||||
| id | agent_type | host | alive | admin_state_up | binary |
|
||||
+--------------------------------------+--------------------+------------+-------+----------------+---------------------------+
|
||||
| 08905043-5010-4b87-bba5-aedb1956e27a | Linux bridge agent | compute1 | :-) | True | neutron-linuxbridge-agent |
|
||||
| 27eee952-a748-467b-bf71-941e89846a92 | Linux bridge agent | controller | :-) | True | neutron-linuxbridge-agent |
|
||||
| 830344ff-dc36-4956-84f4-067af667a0dc | L3 agent | controller | :-) | True | neutron-l3-agent |
|
||||
| dd3644c9-1a3a-435a-9282-eb306b4b0391 | DHCP agent | controller | :-) | True | neutron-dhcp-agent |
|
||||
| f49a4b81-afd6-4b3d-b923-66c8f0517099 | Metadata agent | controller | :-) | True | neutron-metadata-agent |
|
||||
+--------------------------------------+--------------------+------------+-------+----------------+---------------------------+
|
||||
|
||||
Next topic: :ref:`openstack_orchestration`.
|
||||
@@ -1,772 +0,0 @@
|
||||
.. _openstack_object_storage:
|
||||
|
||||
OpenStack* Object Storage
|
||||
#########################
|
||||
|
||||
The OpenStack Object Storage services (swift) work together to provide
|
||||
object storage and retrieval through a REST API. Your environment must
|
||||
at least include the Identity service (keystone) prior to deploying Object Storage.
|
||||
|
||||
OpenStack Object Storage
|
||||
------------------------
|
||||
|
||||
The OpenStack Object Storage is a multi-tenant object storage system.
|
||||
It is highly scalable and can manage large amounts of unstructured data
|
||||
at low cost through a RESTful HTTP API.
|
||||
|
||||
It includes the following components:
|
||||
|
||||
**Proxy servers (swift-proxy-server)**
|
||||
Accepts OpenStack Object Storage API and raw HTTP requests to upload files, modify metadata,
|
||||
and create containers. It also serves file or container listings to web browsers. To improve performance,
|
||||
the proxy server can use an optional cache that is usually deployed with memcache.
|
||||
|
||||
**Account servers (swift-account-server)**
|
||||
Manages accounts defined with Object Storage.
|
||||
|
||||
**Container servers (swift-container-server)**
|
||||
Manages the mapping of containers or folders, within Object Storage.
|
||||
|
||||
**Object servers (swift-object-server)**
|
||||
Manages actual objects, such as files, on the storage nodes.
|
||||
|
||||
**Various periodic processes**
|
||||
Performs housekeeping tasks on the large data store. The replication
|
||||
services ensure consistency and availability through the cluster.
|
||||
Other periodic processes include auditors, updaters, and reapers.
|
||||
|
||||
**WSGI middleware**
|
||||
Handles authentication and is usually OpenStack Identity.
|
||||
|
||||
**swift client**
|
||||
Enables users to submit commands to the REST API through a
|
||||
command-line client authorized as either a admin user, reseller user, or swift user.
|
||||
|
||||
**swift-init**
|
||||
Script that initializes the building of the ring file, takes daemon
|
||||
names as parameter and offers commands. Documented in
|
||||
http://docs.openstack.org/developer/swift/admin_guide.html#managing-services.
|
||||
|
||||
**swift-recon**
|
||||
A cli tool used to retrieve various metrics and telemetry information
|
||||
about a cluster that has been collected by the swift-recon middleware.
|
||||
|
||||
**swift-ring-builder**
|
||||
Storage ring build and rebalance utility. Documented in
|
||||
http://docs.openstack.org/developer/swift/admin_guide.html#managing-the-rings.
|
||||
|
||||
Install and configure the controller node
|
||||
-----------------------------------------
|
||||
|
||||
This section describes how to install and configure the proxy service
|
||||
that handles requests for the account, container, and object services
|
||||
operating on the storage nodes. For simplicity, this guide installs and
|
||||
configures the proxy service on the controller node. However, you can
|
||||
run the proxy service on any node with network connectivity to the
|
||||
storage nodes. Additionally, you can install and configure the proxy
|
||||
service on multiple nodes to increase performance and redundancy.
|
||||
|
||||
To configure prerequisites
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The proxy service relies on an authentication and authorization
|
||||
mechanism such as the Identity service. However, unlike other services,
|
||||
it also offers an internal mechanism that allows it to operate without
|
||||
any other OpenStack* services. However, for simplicity, this guide
|
||||
references the Identity service. Before you configure the Object Storage
|
||||
service, you must create service credentials and an API endpoint.
|
||||
|
||||
#. Source the ``admin`` credentials to gain access to admin-only CLI
|
||||
commands::
|
||||
|
||||
$ source admin-openrc.sh
|
||||
|
||||
#. To create the Identity service credentials, complete these steps:
|
||||
|
||||
* Create the ``swift`` user::
|
||||
|
||||
$ openstack user create --domain default --password-prompt swift
|
||||
User Password:
|
||||
Repeat User Password:
|
||||
+-----------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-----------+----------------------------------+
|
||||
| domain_id | default |
|
||||
| enabled | True |
|
||||
| id | d535e5cbd2b74ac7bfb97db9cced3ed6 |
|
||||
| name | swift |
|
||||
+-----------+----------------------------------+
|
||||
|
||||
* Add the admin role to the ``swift`` user::
|
||||
|
||||
$ openstack role add --project service --user swift admin
|
||||
|
||||
* Create the ``swift`` service entity::
|
||||
|
||||
$ openstack service create --name swift \
|
||||
--description "OpenStack Object Storage" object-store
|
||||
+-------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------------+----------------------------------+
|
||||
| description | OpenStack Object Storage |
|
||||
| enabled | True |
|
||||
| id | 75ef509da2c340499d454ae96a2c5c34 |
|
||||
| name | swift |
|
||||
| type | object-store |
|
||||
+-------------+----------------------------------+
|
||||
|
||||
#. Create the Object Storage service API endpoint::
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
object-store public http://controller:8080/v1/AUTH_%\(tenant_id\)s
|
||||
+--------------+----------------------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+----------------------------------------------+
|
||||
| enabled | True |
|
||||
| id | 12bfd36f26694c97813f665707114e0d |
|
||||
| interface | public |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | 75ef509da2c340499d454ae96a2c5c34 |
|
||||
| service_name | swift |
|
||||
| service_type | object-store |
|
||||
| url | http://controller:8080/v1/AUTH_%(tenant_id)s |
|
||||
+--------------+----------------------------------------------+
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
object-store internal http://controller:8080/v1/AUTH_%\(tenant_id\)s
|
||||
+--------------+----------------------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+----------------------------------------------+
|
||||
| enabled | True |
|
||||
| id | 7a36bee6733a4b5590d74d3080ee6789 |
|
||||
| interface | internal |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | 75ef509da2c340499d454ae96a2c5c34 |
|
||||
| service_name | swift |
|
||||
| service_type | object-store |
|
||||
| url | http://controller:8080/v1/AUTH_%(tenant_id)s |
|
||||
+--------------+----------------------------------------------+
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
object-store admin http://controller:8080/v1
|
||||
+--------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+----------------------------------+
|
||||
| enabled | True |
|
||||
| id | ebb72cd6851d4defabc0b9d71cdca69b |
|
||||
| interface | admin |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | 75ef509da2c340499d454ae96a2c5c34 |
|
||||
| service_name | swift |
|
||||
| service_type | object-store |
|
||||
| url | http://controller:8080/v1 |
|
||||
+--------------+----------------------------------+
|
||||
|
||||
To install and configure the controller node components
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Install OpenStack Object Storage bundle::
|
||||
|
||||
# swupd bundle-add openstack-object-storage
|
||||
# swupd verify --fix
|
||||
|
||||
#. Create the directory ``/etc/swift`` if does not exist::
|
||||
|
||||
# mkdir /etc/swift
|
||||
|
||||
#. Copy the sample proxy-server config file to the configuration
|
||||
directory::
|
||||
|
||||
# cp /usr/share/defaults/swift/proxy-server.conf /etc/swift
|
||||
|
||||
#. Edit the ``/etc/swift/proxy-server.conf`` file and complete the
|
||||
following actions:
|
||||
|
||||
* In the ``[pipeline:main]`` section, enable the appropriate
|
||||
modules::
|
||||
|
||||
[pipeline:main]
|
||||
pipeline = catch_errors gatekeeper healthcheck proxy-logging cache container_sync bulk ratelimit authtoken keystoneauth container-quotas account-quotas slo dlo versioned_writes proxy-logging proxy-server
|
||||
|
||||
* In the ``[app:proxy-server]`` section, enable automatic account
|
||||
creation::
|
||||
|
||||
[app:proxy-server]
|
||||
...
|
||||
account_autocreate = true
|
||||
|
||||
* In the ``[filter:keystoneauth]`` section, configure the operator
|
||||
roles::
|
||||
|
||||
[filter:keystoneauth]
|
||||
use = egg:swift#keystoneauth
|
||||
...
|
||||
operator_roles = admin,user
|
||||
|
||||
* In the ``[filter:authtoken]`` section, configure Identity service
|
||||
access. Replace *SWIFT_PASS* with the password you chose for the
|
||||
``swift`` user in the Identity service::
|
||||
|
||||
[filter:authtoken]
|
||||
paste.filter_factory = keystonemiddleware.auth_token:filter_factory
|
||||
...
|
||||
auth_uri = http://controller:5000
|
||||
auth_url = http://controller:35357
|
||||
auth_plugin = password
|
||||
project_domain_id = default
|
||||
user_domain_id = default
|
||||
project_name = service
|
||||
username = swift
|
||||
password = SWIFT_PASS
|
||||
delay_auth_decision = true
|
||||
|
||||
* In the ``[filter:cache]`` section, configure the ``memcached``
|
||||
location::
|
||||
|
||||
[filter:cache]
|
||||
...
|
||||
memcache_servers = 127.0.0.1:11211
|
||||
|
||||
Install and configure the storage nodes
|
||||
---------------------------------------
|
||||
|
||||
This section describes how to install and configure storage nodes that
|
||||
operate the account, container, and object services. For simplicity,
|
||||
this configuration references two storage nodes, each containing two
|
||||
empty local block storage devices. Each of the devices, ``/dev/sdb`` and
|
||||
``/dev/sdc``, must contain a suitable partition table with one partition
|
||||
occupying the entire device.
|
||||
|
||||
Although the Object Storage service
|
||||
supports any file system with extended attributes (xattr), testing and
|
||||
benchmarking indicate the best performance and reliability on XFS.
|
||||
|
||||
To configure prerequisites
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You must configure each storage node before you install and configure
|
||||
the Object Storage service on it. Similar to the controller node, each
|
||||
storage node contains one network interface on the management network.
|
||||
Optionally, each storage node can contain a second network interface on
|
||||
a separate network for replication.
|
||||
|
||||
#. Configure unique items on the first storage node:
|
||||
|
||||
* Configure the management interface::
|
||||
|
||||
IP address: 10.0.0.51
|
||||
Network mask: 255.255.255.0 (or /24)
|
||||
Default gateway: 10.0.0.1
|
||||
|
||||
* Set the hostname of the node to ``object1``.
|
||||
|
||||
#. Configure unique items on the second storage node:
|
||||
|
||||
* Configure the management interface::
|
||||
|
||||
IP address: 10.0.0.52
|
||||
Network mask: 255.255.255.0 (or /24)
|
||||
Default gateway: 10.0.0.1
|
||||
|
||||
* Set the hostname of the node to ``object2``.
|
||||
|
||||
#. Configure shared items on both storage nodes:
|
||||
|
||||
* Copy the contents of ``/etc/hosts`` file from ``controller`` node to ``storage`` nodes and add the
|
||||
following ::
|
||||
|
||||
# object1
|
||||
10.0.0.51 object1
|
||||
# object2
|
||||
10.0.0.52 object2
|
||||
|
||||
#. Install the OpenStack Object Storage bundle::
|
||||
|
||||
# swupd bundle-add openstack-object-storage
|
||||
# swupd verify --fix
|
||||
|
||||
#. Format the ``/dev/sdb1`` and ``/dev/sdc1`` partitions as XFS::
|
||||
|
||||
# mkfs.xfs /dev/sdb1
|
||||
# mkfs.xfs /dev/sdc1
|
||||
|
||||
#. Create the mount point directory structure::
|
||||
|
||||
# mkdir -p /srv/node/sdb1
|
||||
# mkdir -p /srv/node/sdc1
|
||||
|
||||
#. Edit the ``/etc/fstab`` file and add the following to it::
|
||||
|
||||
/dev/sdb1 /srv/node/sdb1 xfs noatime,nodiratime,nobarrier,logbufs=8 0 2
|
||||
/dev/sdc1 /srv/node/sdc1 xfs noatime,nodiratime,nobarrier,logbufs=8 0 2
|
||||
|
||||
#. Mount the devices::
|
||||
|
||||
# mount /srv/node/sdb1
|
||||
# mount /srv/node/sdc1
|
||||
|
||||
#. Edit the ``/etc/rsyncd.conf`` file and add the following to it::
|
||||
|
||||
uid = swift
|
||||
gid = swift
|
||||
log file = /var/log/rsyncd.log
|
||||
pid file = /var/run/rsyncd.pid
|
||||
address = MANAGEMENT_INTERFACE_IP_ADDRESS
|
||||
|
||||
[account]
|
||||
max connections = 2
|
||||
path = /srv/node/
|
||||
read only = false
|
||||
lock file = /var/lock/account.lock
|
||||
|
||||
[container]
|
||||
max connections = 2
|
||||
path = /srv/node/
|
||||
read only = false
|
||||
lock file = /var/lock/container.lock
|
||||
|
||||
[object]
|
||||
max connections = 2
|
||||
path = /srv/node/
|
||||
read only = false
|
||||
lock file = /var/lock/object.lock
|
||||
|
||||
Replace *MANAGEMENT_INTERFACE_IP_ADDRESS* with the IP address of
|
||||
the management network on the storage node.
|
||||
|
||||
Note: The ``rsync`` service requires no authentication, so consider
|
||||
running it on a private network.
|
||||
|
||||
#. Start the ``rsyncd`` service and configure it to start when the
|
||||
system boots::
|
||||
|
||||
# systemctl enable rsyncd.service
|
||||
# systemctl start rsyncd.service
|
||||
|
||||
Install and configure storage node components
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Copy the accounting, container, object, container-reconciler, and
|
||||
object-expirer service configuration files to the configuration
|
||||
directory::
|
||||
|
||||
# cp /usr/share/defaults/swift/account-server.conf /etc/swift
|
||||
# cp /usr/share/defaults/swift/container-server.conf /etc/swift
|
||||
# cp /usr/share/defaults/swift/object-server.conf /etc/swift
|
||||
# cp /usr/share/defaults/swift/container-reconciler.conf /etc/swift
|
||||
# cp /usr/share/defaults/swift/object-expirer.conf /etc/swift
|
||||
|
||||
#. Edit the ``/etc/swift/account-server.conf`` file and complete the
|
||||
following actions:
|
||||
|
||||
* In the ``[DEFAULT]`` section, configure the bind IP address and
|
||||
mount point directory::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
bind_ip = MANAGEMENT_INTERFACE_IP_ADDRESS
|
||||
devices = /srv/node
|
||||
|
||||
Replace *MANAGEMENT_INTERFACE_IP_ADDRESS* with the IP
|
||||
address of the management network on the storage node.
|
||||
|
||||
* In the ``[pipeline:main]`` section, enable the appropriate
|
||||
modules::
|
||||
|
||||
[pipeline:main]
|
||||
pipeline = healthcheck recon account-server
|
||||
|
||||
* In the ``[filter:recon]`` section, configure the ``recon`` (metrics)
|
||||
cache directory::
|
||||
|
||||
[filter:recon]
|
||||
...
|
||||
recon_cache_path = /var/cache/swift
|
||||
|
||||
#. Edit the ``/etc/swift/container-server.conf`` file and complete the
|
||||
following actions:
|
||||
|
||||
* In the ``[DEFAULT]`` section, configure the bind IP address and
|
||||
mount point directory::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
bind_ip = MANAGEMENT_INTERFACE_IP_ADDRESS
|
||||
devices = /srv/node
|
||||
|
||||
Replace *MANAGEMENT_INTERFACE_IP_ADDRESS* with the IP
|
||||
address of the management network on the storage node.
|
||||
|
||||
* In the ``[pipeline:main]`` section, enable the appropriate modules::
|
||||
|
||||
[pipeline:main]
|
||||
pipeline = healthcheck recon container-server
|
||||
|
||||
* In the ``[filter:recon]`` section, configure the recon (metrics)
|
||||
cache directory::
|
||||
|
||||
[filter:recon]
|
||||
...
|
||||
recon_cache_path = /var/cache/swift
|
||||
|
||||
#. Edit the ``/etc/swift/object-server.conf`` file and complete the
|
||||
following actions:
|
||||
|
||||
* In the ``[DEFAULT]`` section, configure the bind IP address and
|
||||
mount point directory::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
bind_ip = MANAGEMENT_INTERFACE_IP_ADDRESS
|
||||
devices = /srv/node
|
||||
|
||||
Replace *MANAGEMENT_INTERFACE_IP_ADDRESS* with the IP
|
||||
address of the management network on the storage node.
|
||||
|
||||
* In the ``[pipeline:main]`` section, enable the appropriate
|
||||
modules::
|
||||
|
||||
[pipeline:main]
|
||||
pipeline = healthcheck recon object-server
|
||||
|
||||
* In the ``[filter:recon]`` section, configure the ``recon`` (metrics)
|
||||
cache and lock directories::
|
||||
|
||||
[filter:recon]
|
||||
...
|
||||
recon_cache_path = /var/cache/swift
|
||||
recon_lock_path = /var/lock
|
||||
|
||||
#. Ensure proper ownership of the mount point directory structure::
|
||||
|
||||
# systemctl restart update-triggers.target
|
||||
|
||||
About creating initial rings
|
||||
----------------------------
|
||||
|
||||
Before starting the Object Storage services, you must create the initial
|
||||
account, container, and object rings. The ring builder creates
|
||||
configuration files that each node uses to determine and deploy the
|
||||
storage architecture. For simplicity, this guide uses one region and
|
||||
zone with 2^10 (1024) maximum partitions, 3 replicas of each object, and
|
||||
1 hour minimum time between moving a partition more than once. For
|
||||
Object Storage, a partition indicates a directory on a storage device
|
||||
rather than a conventional partition table.
|
||||
|
||||
Create Account Ring
|
||||
-------------------
|
||||
|
||||
The account server uses the account ring to maintain lists of
|
||||
containers.
|
||||
|
||||
To create the ring
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Create the base ``account.builder`` file::
|
||||
|
||||
# swift-ring-builder account.builder create 10 3 1
|
||||
|
||||
#. Add each storage node to the ring::
|
||||
|
||||
# swift-ring-builder account.builder \
|
||||
add --region 1 --zone 1 --ip STORAGE_NODE_MANAGEMENT_INTERFACE_IP_ADDRESS --port 6002 \
|
||||
--device DEVICE_NAME --weight DEVICE_WEIGHT
|
||||
|
||||
Replace *STORAGE_NODE_MANAGEMENT_INTERFACE_IP_ADDRESS* with the
|
||||
IP address of the management network on the storage node. Replace
|
||||
*DEVICE_NAME* with a storage device name on the same storage node.
|
||||
For example, using the first storage node with the ``/dev/sdb1`` storage
|
||||
device and weight of 100::
|
||||
|
||||
# swift-ring-builder account.builder add \
|
||||
--region 1 --zone 1 --ip 10.0.0.51 --port 6002 --device sdb --weight 100
|
||||
|
||||
Repeat this command for each storage device on each storage node. In
|
||||
the example architecture, use the command in four variations::
|
||||
|
||||
# swift-ring-builder account.builder add \
|
||||
--region 1 --zone 1 --ip 10.0.0.51 --port 6002 --device sdb --weight 100
|
||||
Device d0r1z1-10.0.0.51:6002R10.0.0.51:6002/sdb_"" with 100.0 weight got id 0
|
||||
# swift-ring-builder account.builder add \
|
||||
--region 1 --zone 2 --ip 10.0.0.51 --port 6002 --device sdc --weight 100
|
||||
Device d1r1z2-10.0.0.51:6002R10.0.0.51:6002/sdc_"" with 100.0 weight got id 1
|
||||
# swift-ring-builder account.builder add \
|
||||
--region 1 --zone 3 --ip 10.0.0.52 --port 6002 --device sdb --weight 100
|
||||
Device d2r1z3-10.0.0.52:6002R10.0.0.52:6002/sdb_"" with 100.0 weight got id 2
|
||||
# swift-ring-builder account.builder add \
|
||||
--region 1 --zone 4 --ip 10.0.0.52 --port 6002 --device sdc --weight 100
|
||||
Device d3r1z4-10.0.0.52:6002R10.0.0.52:6002/sdc_"" with 100.0 weight got id 3
|
||||
|
||||
#. Verify the ring contents::
|
||||
|
||||
# swift-ring-builder account.builder
|
||||
account.builder, build version 4
|
||||
1024 partitions, 3.000000 replicas, 1 regions, 4 zones, 4 devices, 100.00 balance, 0.00 dispersion
|
||||
The minimum number of hours before a partition can be reassigned is 1
|
||||
The overload factor is 0.00% (0.000000)
|
||||
Devices: id region zone ip address port replication ip replication port name weight partitions balance meta
|
||||
0 1 1 10.0.0.51 6002 10.0.0.51 6002 sdb 100.00 0 -100.00
|
||||
1 1 2 10.0.0.51 6002 10.0.0.51 6002 sdc 100.00 0 -100.00
|
||||
2 1 3 10.0.0.52 6002 10.0.0.52 6002 sdb 100.00 0 -100.00
|
||||
3 1 4 10.0.0.52 6002 10.0.0.52 6002 sdc 100.00 0 -100.00
|
||||
|
||||
#. Rebalance the ring::
|
||||
|
||||
# swift-ring-builder account.builder rebalance
|
||||
Reassigned 1024 (100.00%) partitions. Balance is now 0.00. Dispersion is now 0.00
|
||||
|
||||
Create Container Ring
|
||||
---------------------
|
||||
|
||||
The container server uses the container ring to maintain lists of
|
||||
objects. However, it does not track object locations.
|
||||
|
||||
To create the ring
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Create the base ``container.builder`` file::
|
||||
|
||||
# swift-ring-builder container.builder create 10 3 1
|
||||
|
||||
#. Add each storage node to the ring::
|
||||
|
||||
# swift-ring-builder container.builder \
|
||||
add --region 1 --zone 1 --ip STORAGE_NODE_MANAGEMENT_INTERFACE_IP_ADDRESS --port 6001 \
|
||||
--device DEVICE_NAME --weight DEVICE_WEIGHT
|
||||
|
||||
Replace *STORAGE_NODE_MANAGEMENT_INTERFACE_IP_ADDRESS* with the
|
||||
IP address of the management network on the storage node. Replace
|
||||
*DEVICE_NAME* with a storage device name on the same storage node.
|
||||
For example, using the first storage node with the ``/dev/sdb1`` storage
|
||||
device and weight of 100::
|
||||
|
||||
# swift-ring-builder container.builder add \
|
||||
--region 1 --zone 1 --ip 10.0.0.51 --port 6001 --device sdb --weight 100
|
||||
|
||||
Repeat this command for each storage device on each storage node. In
|
||||
the example architecture, use the command in four variations::
|
||||
|
||||
# swift-ring-builder container.builder add \
|
||||
--region 1 --zone 1 --ip 10.0.0.51 --port 6001 --device sdb --weight 100
|
||||
Device d0r1z1-10.0.0.51:6001R10.0.0.51:6001/sdb_"" with 100.0 weight got id 0
|
||||
# swift-ring-builder container.builder add \
|
||||
--region 1 --zone 2 --ip 10.0.0.51 --port 6001 --device sdc --weight 100
|
||||
Device d1r1z2-10.0.0.51:6001R10.0.0.51:6001/sdc_"" with 100.0 weight got id 1
|
||||
# swift-ring-builder container.builder add \
|
||||
--region 1 --zone 3 --ip 10.0.0.52 --port 6001 --device sdb --weight 100
|
||||
Device d2r1z3-10.0.0.52:6001R10.0.0.52:6001/sdb_"" with 100.0 weight got id 2
|
||||
# swift-ring-builder container.builder add \
|
||||
--region 1 --zone 4 --ip 10.0.0.52 --port 6001 --device sdc --weight 100
|
||||
Device d3r1z4-10.0.0.52:6001R10.0.0.52:6001/sdc_"" with 100.0 weight got id 3
|
||||
|
||||
#. Verify the ring contents::
|
||||
|
||||
# swift-ring-builder container.builder
|
||||
container.builder, build version 4
|
||||
1024 partitions, 3.000000 replicas, 1 regions, 4 zones, 4 devices, 100.00 balance, 0.00 dispersion
|
||||
The minimum number of hours before a partition can be reassigned is 1
|
||||
The overload factor is 0.00% (0.000000)
|
||||
Devices: id region zone ip address port replication ip replication port name weight partitions balance meta
|
||||
0 1 1 10.0.0.51 6001 10.0.0.51 6001 sdb 100.00 0 -100.00
|
||||
1 1 2 10.0.0.51 6001 10.0.0.51 6001 sdc 100.00 0 -100.00
|
||||
2 1 3 10.0.0.52 6001 10.0.0.52 6001 sdb 100.00 0 -100.00
|
||||
3 1 4 10.0.0.52 6001 10.0.0.52 6001 sdc 100.00 0 -100.00
|
||||
|
||||
#. Rebalance the ring::
|
||||
|
||||
# swift-ring-builder container.builder rebalance
|
||||
Reassigned 1024 (100.00%) partitions. Balance is now 0.00. Dispersion is now 0.00
|
||||
|
||||
Create Object Ring
|
||||
------------------
|
||||
|
||||
The object server uses the object ring to maintain lists of object
|
||||
locations on local devices.
|
||||
|
||||
To create the ring
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Create the base ``object.builder`` file::
|
||||
|
||||
# swift-ring-builder object.builder create 10 3 1
|
||||
|
||||
#. Add each storage node to the ring::
|
||||
|
||||
# swift-ring-builder object.builder \
|
||||
add --region 1 --zone 1 --ip STORAGE_NODE_MANAGEMENT_INTERFACE_IP_ADDRESS --port 6000 \
|
||||
--device DEVICE_NAME --weight DEVICE_WEIGHT
|
||||
|
||||
Replace *STORAGE_NODE_MANAGEMENT_INTERFACE_IP_ADDRESS* with the
|
||||
IP address of the management network on the storage node. Replace
|
||||
*DEVICE_NAME* with a storage device name on the same storage node.
|
||||
For example, using the first storage node with the ``/dev/sdb1`` storage
|
||||
device and weight of 100::
|
||||
|
||||
# swift-ring-builder object.builder add \
|
||||
--region 1 --zone 1 --ip 10.0.0.51 --port 6000 --device sdb --weight 100
|
||||
|
||||
Repeat this command for each storage device on each storage node. In
|
||||
the example architecture, use the command in four variations::
|
||||
|
||||
# swift-ring-builder object.builder add \
|
||||
--region 1 --zone 1 --ip 10.0.0.51 --port 6000 --device sdb --weight 100
|
||||
Device d0r1z1-10.0.0.51:6000R10.0.0.51:6000/sdb_"" with 100.0 weight got id 0
|
||||
# swift-ring-builder object.builder add \
|
||||
--region 1 --zone 2 --ip 10.0.0.51 --port 6000 --device sdc --weight 100
|
||||
Device d1r1z2-10.0.0.51:6000R10.0.0.51:6000/sdc_"" with 100.0 weight got id 1
|
||||
# swift-ring-builder object.builder add \
|
||||
--region 1 --zone 3 --ip 10.0.0.52 --port 6000 --device sdb --weight 100
|
||||
Device d2r1z3-10.0.0.52:6000R10.0.0.52:6000/sdb_"" with 100.0 weight got id 2
|
||||
# swift-ring-builder object.builder add \
|
||||
--region 1 --zone 4 --ip 10.0.0.52 --port 6000 --device sdc --weight 100
|
||||
Device d3r1z4-10.0.0.52:6000R10.0.0.52:6000/sdc_"" with 100.0 weight got id 3
|
||||
|
||||
#. Verify the ring contents::
|
||||
|
||||
# swift-ring-builder object.builder
|
||||
object.builder, build version 4
|
||||
1024 partitions, 3.000000 replicas, 1 regions, 4 zones, 4 devices, 100.00 balance, 0.00 dispersion
|
||||
The minimum number of hours before a partition can be reassigned is 1
|
||||
The overload factor is 0.00% (0.000000)
|
||||
Devices: id region zone ip address port replication ip replication port name weight partitions balance meta
|
||||
0 1 1 10.0.0.51 6000 10.0.0.51 6000 sdb 100.00 0 -100.00
|
||||
1 1 2 10.0.0.51 6000 10.0.0.51 6000 sdc 100.00 0 -100.00
|
||||
2 1 3 10.0.0.52 6000 10.0.0.52 6000 sdb 100.00 0 -100.00
|
||||
3 1 4 10.0.0.52 6000 10.0.0.52 6000 sdc 100.00 0 -100.00
|
||||
|
||||
#. Rebalance the ring::
|
||||
|
||||
# swift-ring-builder object.builder rebalance
|
||||
Reassigned 1024 (100.00%) partitions. Balance is now 0.00. Dispersion is now 0.00
|
||||
|
||||
Distribute ring configuration files
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Copy the ``account.ring.gz``, ``container.ring.gz``, and ``object.ring.gz`` files to
|
||||
the ``/etc/swift`` directory on each storage node and any additional nodes
|
||||
running the proxy service::
|
||||
|
||||
# cp account.ring.gz container.ring.gz object.ring.gz /etc/swift/
|
||||
|
||||
Finalize installation
|
||||
---------------------
|
||||
|
||||
Configure hashes and default storage policy
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Copy the swift service configuration file to the configuration directory::
|
||||
|
||||
# cp /usr/share/defaults/swift/swift.conf /etc/swift
|
||||
|
||||
#. Edit the ``/etc/swift/swift.conf`` file and complete the following
|
||||
actions:
|
||||
|
||||
* In the ``[swift-hash]`` section, configure the hash path prefix and
|
||||
suffix for your environment. Replace *HASH_PATH_PREFIX* and
|
||||
*HASH_PATH_SUFFIX* with unique values.::
|
||||
|
||||
[swift-hash]
|
||||
...
|
||||
swift_hash_path_suffix = HASH_PATH_PREFIX
|
||||
swift_hash_path_prefix = HASH_PATH_SUFFIX
|
||||
|
||||
* In the ``[storage-policy:0]`` section, configure the default storage
|
||||
policy::
|
||||
|
||||
[storage-policy:0]
|
||||
...
|
||||
name = Policy-0
|
||||
default = yes
|
||||
|
||||
#. Copy the ``swift.conf`` file to the ``/etc/swift`` directory on each storage
|
||||
node and any additional nodes running the proxy service.
|
||||
#. On all nodes, ensure proper ownership of the configuration directory::
|
||||
|
||||
# systemctl restart update-triggers.target
|
||||
|
||||
#. On the controller node and any other nodes running the proxy service,
|
||||
start the Object Storage proxy service including its dependencies and
|
||||
configure them to start when the system boots::
|
||||
|
||||
# systemctl enable swift-proxy.service memcached.service
|
||||
# systemctl start swift-proxy.service memcached.service
|
||||
|
||||
#. On the storage nodes, start the Object Storage services and configure
|
||||
them to start when the system boots::
|
||||
|
||||
# systemctl enable swift-account.service \
|
||||
swift-account-auditor.service \
|
||||
swift-account-reaper.service \
|
||||
swift-account-replicator.service \
|
||||
swift-container.service \
|
||||
swift-container-auditor.service \
|
||||
swift-container-replicator.service \
|
||||
swift-container-updater.service \
|
||||
swift-object.service \
|
||||
swift-object-auditor.service \
|
||||
swift-object-replicator.service \
|
||||
swift-object-updater.service
|
||||
# systemctl start swift-account.service \
|
||||
swift-account-auditor.service \
|
||||
swift-account-reaper.service \
|
||||
swift-account-replicator.service \
|
||||
swift-container.service \
|
||||
swift-container-auditor.service \
|
||||
swift-container-replicator.service \
|
||||
swift-container-updater.service \
|
||||
swift-object.service \
|
||||
swift-object-auditor.service \
|
||||
swift-object-replicator.service \
|
||||
swift-object-updater.service
|
||||
|
||||
Verify operation
|
||||
----------------
|
||||
|
||||
Verify operation of the Object Storage service.
|
||||
|
||||
#. In each client environment script, configure the Object Storage service client to use the Identity API version 3::
|
||||
|
||||
$ echo "export OS_AUTH_VERSION=3" \
|
||||
| tee -a admin-openrc.sh demo-openrc.sh
|
||||
|
||||
#. Source the demo credentials::
|
||||
|
||||
$ source demo-openrc.sh
|
||||
|
||||
#. Show the service status::
|
||||
|
||||
$ swift stat
|
||||
Account: AUTH_ed0b60bf607743088218b0a533d5943f
|
||||
Containers: 0
|
||||
Objects: 0
|
||||
Bytes: 0
|
||||
Containers in policy "policy-0": 0
|
||||
Objects in policy "policy-0": 0
|
||||
Bytes in policy "policy-0": 0
|
||||
X-Account-Project-Domain-Id: default
|
||||
X-Timestamp: 1444143887.71539
|
||||
X-Trans-Id: tx1396aeaf17254e94beb34-0056143bde
|
||||
Content-Type: text/plain; charset=utf-8
|
||||
Accept-Ranges: bytes
|
||||
|
||||
#. Upload a test file::
|
||||
|
||||
$ swift upload container1 FILE
|
||||
FILE
|
||||
|
||||
Replace *FILE* with the name of a local file to upload to the ``container1`` container.
|
||||
|
||||
#. List containers::
|
||||
|
||||
$ swift list
|
||||
container1
|
||||
|
||||
#. Download a test file::
|
||||
|
||||
$ swift download container1 FILE
|
||||
FILE [auth 0.295s, headers 0.339s, total 0.339s, 0.005 MB/s]
|
||||
|
||||
Replace *FILE* with the name of the file uploaded to the ``container1`` container.
|
||||
@@ -1,393 +0,0 @@
|
||||
.. _openstack_orchestration:
|
||||
|
||||
Orchestration
|
||||
############################################################
|
||||
|
||||
The OpenStack* Orchestration service provides a template-based orchestration for
|
||||
describing a cloud application by running OpenStack API calls to generate
|
||||
running cloud applications. The software integrates other core components of
|
||||
OpenStack into a one-file template system.
|
||||
|
||||
The templates allow you to create most OpenStack resource types, such as
|
||||
instances, floating IPs, volumes, security groups and users. It also provides
|
||||
advanced functionality, such as instance high availability, instance
|
||||
auto-scaling, and nested stacks. This enables OpenStack core projects to
|
||||
receive a larger user base.
|
||||
|
||||
Installing and configuring controller node
|
||||
------------------------------------------
|
||||
|
||||
This section describes how to install and configure the Orchestration
|
||||
service, codenamed heat, on the controller node.
|
||||
|
||||
Configuring prerequisites
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Before you install and configure Orchestration, you must create a
|
||||
database, service credentials, and API endpoints.
|
||||
|
||||
#. To create the database, complete these steps:
|
||||
|
||||
* Use the database access client to connect to the database server as
|
||||
the ``root`` user::
|
||||
|
||||
$ mysql -u root -p
|
||||
|
||||
* Create the ``heat`` database::
|
||||
|
||||
CREATE DATABASE heat;
|
||||
|
||||
* Grant proper access to the ``heat`` database. Replace *HEAT_DBPASS*
|
||||
with a suitable password::
|
||||
|
||||
GRANT ALL PRIVILEGES ON heat.* TO 'heat'@'localhost' \
|
||||
IDENTIFIED BY 'HEAT_DBPASS';
|
||||
GRANT ALL PRIVILEGES ON heat.* TO 'heat'@'%' \
|
||||
IDENTIFIED BY 'HEAT_DBPASS';
|
||||
|
||||
* Exit the database access client.
|
||||
|
||||
#. Source the ``admin`` credentials to gain access to admin-only CLI
|
||||
commands::
|
||||
|
||||
$ source admin-openrc.sh
|
||||
|
||||
#. To create the service credentials, complete these steps:
|
||||
|
||||
* Create the ``heat`` user::
|
||||
|
||||
$ openstack user create --domain default --password-prompt heat
|
||||
User Password:
|
||||
Repeat User Password:
|
||||
+-----------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-----------+----------------------------------+
|
||||
| domain_id | default |
|
||||
| enabled | True |
|
||||
| id | ca2e175b851943349be29a328cc5e360 |
|
||||
| name | heat |
|
||||
+-----------+----------------------------------+
|
||||
|
||||
* Add the ``admin`` role to the ``heat`` user::
|
||||
|
||||
$ openstack role add --project service --user heat admin
|
||||
|
||||
* Create the ``heat`` and ``heat-cfn`` service entities::
|
||||
|
||||
$ openstack service create --name heat \
|
||||
--description "Orchestration" orchestration
|
||||
+-------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------------+----------------------------------+
|
||||
| description | Orchestration |
|
||||
| enabled | True |
|
||||
| id | 727841c6f5df4773baa4e8a5ae7d72eb |
|
||||
| name | heat |
|
||||
| type | orchestration |
|
||||
+-------------+----------------------------------+
|
||||
|
||||
$ openstack service create --name heat-cfn \
|
||||
--description "Orchestration" cloudformation
|
||||
+-------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------------+----------------------------------+
|
||||
| description | Orchestration |
|
||||
| enabled | True |
|
||||
| id | c42cede91a4e47c3b10c8aedc8d890c6 |
|
||||
| name | heat-cfn |
|
||||
| type | cloudformation |
|
||||
+-------------+----------------------------------+
|
||||
|
||||
#. Create the Orchestration service API endpoints::
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
orchestration public http://controller:8004/v1/%\(tenant_id\)s
|
||||
+--------------+-----------------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+-----------------------------------------+
|
||||
| enabled | True |
|
||||
| id | 3f4dab34624e4be7b000265f25049609 |
|
||||
| interface | public |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | 727841c6f5df4773baa4e8a5ae7d72eb |
|
||||
| service_name | heat |
|
||||
| service_type | orchestration |
|
||||
| url | http://controller:8004/v1/%(tenant_id)s |
|
||||
+--------------+-----------------------------------------+
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
orchestration internal http://controller:8004/v1/%\(tenant_id\)s
|
||||
+--------------+-----------------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+-----------------------------------------+
|
||||
| enabled | True |
|
||||
| id | 9489f78e958e45cc85570fec7e836d98 |
|
||||
| interface | internal |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | 727841c6f5df4773baa4e8a5ae7d72eb |
|
||||
| service_name | heat |
|
||||
| service_type | orchestration |
|
||||
| url | http://controller:8004/v1/%(tenant_id)s |
|
||||
+--------------+-----------------------------------------+
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
orchestration admin http://controller:8004/v1/%\(tenant_id\)s
|
||||
+--------------+-----------------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+-----------------------------------------+
|
||||
| enabled | True |
|
||||
| id | 76091559514b40c6b7b38dde790efe99 |
|
||||
| interface | admin |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | 727841c6f5df4773baa4e8a5ae7d72eb |
|
||||
| service_name | heat |
|
||||
| service_type | orchestration |
|
||||
| url | http://controller:8004/v1/%(tenant_id)s |
|
||||
+--------------+-----------------------------------------+
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
cloudformation public http://controller:8000/v1
|
||||
+--------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+----------------------------------+
|
||||
| enabled | True |
|
||||
| id | b3ea082e019c4024842bf0a80555052c |
|
||||
| interface | public |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | c42cede91a4e47c3b10c8aedc8d890c6 |
|
||||
| service_name | heat-cfn |
|
||||
| service_type | cloudformation |
|
||||
| url | http://controller:8000/v1 |
|
||||
+--------------+----------------------------------+
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
cloudformation internal http://controller:8000/v1
|
||||
+--------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+----------------------------------+
|
||||
| enabled | True |
|
||||
| id | 169df4368cdc435b8b115a9cb084044e |
|
||||
| interface | internal |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | c42cede91a4e47c3b10c8aedc8d890c6 |
|
||||
| service_name | heat-cfn |
|
||||
| service_type | cloudformation |
|
||||
| url | http://controller:8000/v1 |
|
||||
+--------------+----------------------------------+
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
cloudformation admin http://controller:8000/v1
|
||||
+--------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+----------------------------------+
|
||||
| enabled | True |
|
||||
| id | 3d3edcd61eb343c1bbd629aa041ff88b |
|
||||
| interface | internal |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | c42cede91a4e47c3b10c8aedc8d890c6 |
|
||||
| service_name | heat-cfn |
|
||||
| service_type | cloudformation |
|
||||
| url | http://controller:8000/v1 |
|
||||
+--------------+----------------------------------+
|
||||
|
||||
#. Orchestration requires additional information in the Identity service to
|
||||
manage stacks. To add this information, complete these steps:
|
||||
|
||||
* Create the ``heat`` domain that contains projects and users for stacks::
|
||||
|
||||
$ openstack domain create --description "Stack projects and users" heat
|
||||
+-------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------------+----------------------------------+
|
||||
| description | Stack projects and users |
|
||||
| enabled | True |
|
||||
| id | 0f4d1bd326f2454dacc72157ba328a47 |
|
||||
| name | heat |
|
||||
+-------------+----------------------------------+
|
||||
|
||||
* Create the ``heat_domain_admin`` user to manage projects and users in the
|
||||
``heat`` domain::
|
||||
|
||||
$ openstack user create --domain heat --password-prompt heat_domain_admin
|
||||
User Password:
|
||||
Repeat User Password:
|
||||
+-----------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-----------+----------------------------------+
|
||||
| domain_id | 0f4d1bd326f2454dacc72157ba328a47 |
|
||||
| enabled | True |
|
||||
| id | b7bd1abfbcf64478b47a0f13cd4d970a |
|
||||
| name | heat_domain_admin |
|
||||
+-----------+----------------------------------+
|
||||
|
||||
* Add the ``admin`` role to the ``heat_domain_admin`` in the ``heat`` domain
|
||||
to enable administrative stack management privileges by the
|
||||
``heat_domain_admin`` user::
|
||||
|
||||
$ openstack role add --domain heat --user heat_domain_admin admin
|
||||
|
||||
* Create the ``heat_stack_owner`` role::
|
||||
|
||||
$ openstack role create heat_stack_owner
|
||||
+-------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------+----------------------------------+
|
||||
| id | 15e34f0c4fed4e68b3246275883c8630 |
|
||||
| name | heat_stack_owner |
|
||||
+-------+----------------------------------+
|
||||
|
||||
* Create the ``heat_stack_user`` role::
|
||||
|
||||
$ openstack role create heat_stack_user
|
||||
+-------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------+----------------------------------+
|
||||
| id | 88849d41a55d4d1d91e4f11bffd8fc5c |
|
||||
| name | heat_stack_user |
|
||||
+-------+----------------------------------+
|
||||
|
||||
Installing and configuring components
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To install and configure the Orchestration components:
|
||||
|
||||
#. Install OpenStack Orchestration bundle::
|
||||
|
||||
# swupd bundle-add openstack-orchestration
|
||||
|
||||
#. Custom configuration will be located at ``/etc/heat/heat.conf file``.
|
||||
|
||||
* Create the ``/etc/heat`` directory::
|
||||
|
||||
# mkdir /etc/heat
|
||||
|
||||
* Create empty heat configuration file ``/etc/heat/heat.conf``::
|
||||
|
||||
# touch /etc/heat/heat.conf
|
||||
|
||||
#. Edit the ``/etc/heat/heat.conf`` file and complete the following
|
||||
actions:
|
||||
|
||||
* In the ``[database]`` section, configure database access.
|
||||
Replace *HEAT_DBPASS* with the password you chose for the
|
||||
Orchestration database::
|
||||
|
||||
[database]
|
||||
...
|
||||
connection = mysql://heat:HEAT_DBPASS@controller/heat
|
||||
|
||||
* In the ``[DEFAULT]`` and ``[oslo_messaging_rabbit]`` sections, configure
|
||||
RabbitMQ message queue access. Replace ``RABBIT_PASS`` with the password
|
||||
you chose for the ``openstack`` account in RabbitMQ::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
rpc_backend = rabbit
|
||||
|
||||
[oslo_messaging_rabbit]
|
||||
...
|
||||
rabbit_host = controller
|
||||
rabbit_userid = openstack
|
||||
rabbit_password = RABBIT_PASS
|
||||
|
||||
* In the ``[keystone_authtoken]``, ``[trustee]``, ``[clients_keystone]``,
|
||||
and ``[ec2authtoken]`` sections, configure Identity service access. Replace
|
||||
``HEAT_PASS`` with the password you chose for the heat user in the Identity
|
||||
service.::
|
||||
|
||||
[keystone_authtoken]
|
||||
...
|
||||
auth_uri = http://controller:5000
|
||||
auth_url = http://controller:35357
|
||||
auth_plugin = password
|
||||
project_domain_id = default
|
||||
user_domain_id = default
|
||||
project_name = service
|
||||
username = heat
|
||||
password = HEAT_PASS
|
||||
|
||||
[trustee]
|
||||
...
|
||||
auth_uri = http://controller:5000
|
||||
auth_url = http://controller:35357
|
||||
auth_plugin = password
|
||||
project_domain_id = default
|
||||
user_domain_id = default
|
||||
project_name = service
|
||||
username = heat
|
||||
password = HEAT_PASS
|
||||
|
||||
[clients_keystone]
|
||||
...
|
||||
auth_uri = http://controller:5000
|
||||
|
||||
[ec2authtoken]
|
||||
...
|
||||
auth_uri = http://controller:5000
|
||||
|
||||
|
||||
* In the ``[DEFAULT]`` section, configure the metadata and wait
|
||||
condition URLs::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
heat_metadata_server_url = http://controller:8000
|
||||
heat_waitcondition_server_url = http://controller:8000/v1/waitcondition
|
||||
|
||||
* In the ``[DEFAULT]`` section, configure the stack domain and administrative
|
||||
credentials. Replace ``HEAT_DOMAIN_PASS`` with the password you chose for
|
||||
the ``heat_domain_admin`` user in the Identity service.::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
stack_domain_admin = heat_domain_admin
|
||||
stack_domain_admin_password = HEAT_DOMAIN_PASS
|
||||
stack_user_domain_name = heat
|
||||
|
||||
|
||||
#. Ensure files have proper ownership by running the following command::
|
||||
|
||||
# systemctl restart update-triggers.target
|
||||
|
||||
#. Populate the Orchestration database::
|
||||
|
||||
# su -s /bin/sh -c "heat-manage db_sync" heat
|
||||
|
||||
Finalize installation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Complete this step to finalize the installation:
|
||||
|
||||
* Start the Orchestration services and configure them to start when the
|
||||
system boots::
|
||||
|
||||
# systemctl enable heat-api.service heat-api-cfn.service heat-engine.service
|
||||
# systemctl start heat-api.service heat-api-cfn.service heat-engine.service
|
||||
|
||||
Verify operation
|
||||
----------------
|
||||
|
||||
#. Source the ``admin`` tenant credentials::
|
||||
|
||||
$ source admin-openrc.sh
|
||||
|
||||
#. List service components to verify successful launch and registration of each
|
||||
process::
|
||||
|
||||
$ heat service-list
|
||||
+------------+-------------+--------------------------------------+------------+--------+----------------------------+--------+
|
||||
| hostname | binary | engine_id | host | topic | updated_at | status |
|
||||
+------------+-------------+--------------------------------------+------------+--------+----------------------------+--------+
|
||||
| controller | heat-engine | 3e85d1ab-a543-41aa-aa97-378c381fb958 | controller | engine | 2015-10-13T14:16:06.000000 | up |
|
||||
| controller | heat-engine | 45dbdcf6-5660-4d5f-973a-c4fc819da678 | controller | engine | 2015-10-13T14:16:06.000000 | up |
|
||||
| controller | heat-engine | 51162b63-ecb8-4c6c-98c6-993af899c4f7 | controller | engine | 2015-10-13T14:16:06.000000 | up |
|
||||
| controller | heat-engine | 8d7edc6d-77a6-460d-bd2a-984d76954646 | controller | engine | 2015-10-13T14:16:06.000000 | up |
|
||||
+------------+-------------+--------------------------------------+------------+--------+----------------------------+--------+
|
||||
|
||||
Next topic: :ref:`openstack_telemetry`.
|
||||
@@ -1,52 +0,0 @@
|
||||
.. _openstack_supporting-database:
|
||||
|
||||
Database
|
||||
########
|
||||
|
||||
Most OpenStack* services use an SQL database to store information. The
|
||||
database typically runs on the controller node. The procedures in this
|
||||
guide use MariaDB.
|
||||
|
||||
Install and configure the database server
|
||||
-----------------------------------------
|
||||
|
||||
#. Install MariaDB bundle::
|
||||
|
||||
# swupd bundle-add database-mariadb
|
||||
|
||||
#. Create the ``/etc/mariadb/`` folder and the ``/etc/mariadb/openstack.cnf``
|
||||
file::
|
||||
|
||||
# mkdir /etc/mariadb
|
||||
# touch /etc/mariadb/openstack.cnf
|
||||
|
||||
#. Add the ``[mysqld]`` section, set the bind-address key to the
|
||||
management IP address of the controller node to enable access by
|
||||
other nodes via the management network and enable useful options for
|
||||
UTF-8 character set::
|
||||
|
||||
[mysqld]
|
||||
bind-address = 10.0.0.11
|
||||
default-storage-engine = innodb
|
||||
innodb_file_per_table
|
||||
collation-server = utf8_general_ci
|
||||
init-connect = 'SET NAMES utf8'
|
||||
character-set-server = utf8
|
||||
|
||||
Finalizing database installation
|
||||
--------------------------------
|
||||
|
||||
Complete the following steps to finalize database installation:
|
||||
|
||||
#. Start the database service and configure it to start when the system
|
||||
boots::
|
||||
|
||||
# systemctl enable mariadb.service
|
||||
# systemctl start mariadb.service
|
||||
|
||||
#. Secure the database service including choosing a suitable password
|
||||
for the root account::
|
||||
|
||||
# mysql_secure_installation
|
||||
|
||||
Next topic: :ref:`openstack_supporting-messaging`.
|
||||
@@ -1,47 +0,0 @@
|
||||
.. _openstack_supporting-messaging:
|
||||
|
||||
Message queue
|
||||
#############
|
||||
|
||||
OpenStack* uses a `message queue` to coordinate operations and
|
||||
status information among services. The message queue service typically
|
||||
runs on the controller node. OpenStack supports several message queue
|
||||
services. This guide implements the RabbitMQ message queue service.
|
||||
|
||||
Install the message queue service
|
||||
---------------------------------
|
||||
|
||||
#. Install the message queue bundle.::
|
||||
|
||||
# swupd bundle-add message-broker-rabbitmq
|
||||
|
||||
Configuring the message broker service
|
||||
--------------------------------------
|
||||
|
||||
Complete the following steps to configure the message broker service:
|
||||
|
||||
#. Message broker service needs to be able to resolve to itself. Add the
|
||||
following line to ``/etc/hosts``.::
|
||||
|
||||
127.0.0.1 controller
|
||||
|
||||
#. Start the message broker service and configure it to start when the
|
||||
system boots.::
|
||||
|
||||
# systemctl enable rabbitmq-server.service
|
||||
# systemctl start rabbitmq-server.service
|
||||
|
||||
#. Add the OpenStack user. Replace ``RABBIT_PASS`` with a suitable password.::
|
||||
|
||||
# rabbitmqctl add_user openstack RABBIT_PASS
|
||||
Creating user openstack ...
|
||||
...done.
|
||||
|
||||
|
||||
#. Permit configuration, write, and read access for the OpenStack user.::
|
||||
|
||||
# rabbitmqctl set_permissions openstack ".*" ".*" ".*"
|
||||
Setting permissions for user "openstack" in vhost "/" ...
|
||||
...done.
|
||||
|
||||
Next topic: :ref:`openstack_identity`.
|
||||
@@ -1,68 +0,0 @@
|
||||
.. _openstack_sys_req_and_pw_summary:
|
||||
|
||||
System requirements and password summary
|
||||
########################################
|
||||
|
||||
System requirements
|
||||
-------------------
|
||||
|
||||
For best performance, we recommend that your environment meets or
|
||||
exceeds the following hardware requirements:
|
||||
|
||||
- Controller Node: 1 processor, 2 GB memory, and 5 GB storage.
|
||||
- Compute Node: 1 processor, 2 GB memory, and 10 GB storage.
|
||||
|
||||
For OpenStack* services, this guide uses \ ``SERVICE_PASS``\ to reference
|
||||
service account passwords and ``SERVICE_DBPASS`` to reference database
|
||||
passwords.
|
||||
|
||||
Prerequisites
|
||||
-------------
|
||||
|
||||
All nodes require Internet access to install OpenStack bundles and
|
||||
perform maintenance tasks such as periodic updates.
|
||||
|
||||
OpenStack and supporting services require administrative privileges
|
||||
during installation and operation.
|
||||
|
||||
You must also configure networking so that each node can resolve the
|
||||
other nodes by name in addition to IP address. For example, the
|
||||
``controller`` name must resolve to ``10.0.0.11``, the IP address of the
|
||||
management interface on the controller node.
|
||||
|
||||
To configure name resolution:
|
||||
|
||||
#. Set the hostname of the node to ``controller``::
|
||||
|
||||
# hostnamectl set-hostname controller
|
||||
|
||||
#. Edit the ``/etc/hosts`` file to contain the following::
|
||||
|
||||
# controller 10.0.0.11 controller
|
||||
# compute1 10.0.0.31 compute1
|
||||
|
||||
Password summary
|
||||
----------------
|
||||
|
||||
The following table provides a list of services that require passwords,
|
||||
as well as their associated references in the guide:
|
||||
|
||||
.. csv-table:: Password Services
|
||||
:header: "Password name", "Description"
|
||||
:widths: 100, 100
|
||||
|
||||
"Database password (no variable used)", "Root password for the database."
|
||||
"RABBIT_PASS", "Password of user ``guest`` of RabbitMQ."
|
||||
"KEYSTONE_DBPASS", "Database password of Identity service."
|
||||
"DEMO_PASS", "Password of user ``demo``."
|
||||
"ADMIN_PASS", "Password of user ``admin``."
|
||||
"GLANCE_DBPASS", "Database password for Image Service."
|
||||
"GLANCE_PASS", "Password of Image Service user ``glance``."
|
||||
"NOVA_DBPASS", "Database password for Compute service."
|
||||
"NOVA_PASS", "Password of Compute service user ``nova``."
|
||||
"DASH_DBPASS", "Database password for the dashboard."
|
||||
"CINDER_DBPASS", "Database password for the Block Storage service."
|
||||
"CINDER_PASS", "Password of Block Storage service user ``cinder``."
|
||||
|
||||
|
||||
Next topic: :ref:`openstack_installing_bundles`.
|
||||
@@ -1,260 +0,0 @@
|
||||
.. _openstack_telemetry:
|
||||
|
||||
Telemetry
|
||||
############################################################
|
||||
|
||||
Overview
|
||||
---------
|
||||
|
||||
The OpenStack* Telemetry service performs the following functions:
|
||||
|
||||
- Efficiently polls metering data related to OpenStack services
|
||||
- Collects event and metering data by monitoring notifications sent
|
||||
from services
|
||||
- Publishes collected data to various targets, including data stores
|
||||
and message queues
|
||||
- Creates alarms when collected data breaks defined rules
|
||||
|
||||
Installing and configuring
|
||||
---------------------------
|
||||
|
||||
This section describes how to install and configure the Telemetry
|
||||
service, code-named ceilometer, on the controller node. The Telemetry
|
||||
service collects measurements from most OpenStack services and optionally
|
||||
triggers alarms.
|
||||
|
||||
|
||||
Prerequisites
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Before installing and configuring the ``telemetry`` service, install
|
||||
MongoDB* and create a MongoDB database, service credentials, and API
|
||||
endpoint.
|
||||
|
||||
#. Install the MongoDB bundle::
|
||||
|
||||
# swupd bundle-add database-mongodb
|
||||
|
||||
#. Create the ``/etc/mongodb/`` folder and the
|
||||
``/etc/mongodb/openstack.cnf`` file.::
|
||||
|
||||
# mkdir /etc/mongodb
|
||||
# touch /etc/mongodb/openstack.cnf
|
||||
|
||||
#. Configure the ``bind_ip`` key to use the management interface IP
|
||||
address of the controller node by editing the ``/etc/mongodb/openstack.cnf`` file::
|
||||
|
||||
bind_ip = 10.0.0.11
|
||||
|
||||
#. Start the database service and configure it to start when the system
|
||||
boots with the following commands::
|
||||
|
||||
# systemctl enable mongodb.service
|
||||
# systemctl start mongodb.service
|
||||
|
||||
#. Create the ``ceilometer`` database. Replace *CEILOMETER_DBPASS*
|
||||
with a suitable password::
|
||||
|
||||
# mongo --host controller --eval '
|
||||
db = db.getSiblingDB("ceilometer");
|
||||
db.createUser({user: "ceilometer",
|
||||
pwd: "CEILOMETER_DBPASS",
|
||||
roles: [ "readWrite", "dbAdmin" ]})'
|
||||
|
||||
MongoDB shell version: 3.1.7
|
||||
connecting to: controller:27017/test
|
||||
Successfully added user: { "user" : "ceilometer", "roles" : [ "readWrite", "dbAdmin" ] }
|
||||
|
||||
#. Source the ``admin`` credentials to gain access to admin-only CLI
|
||||
commands::
|
||||
|
||||
$ source admin-openrc.sh
|
||||
|
||||
#. To create the service credentials, complete these steps:
|
||||
|
||||
* Create the ``ceilometer`` user::
|
||||
|
||||
$ openstack user create --domain default --password-prompt ceilometer
|
||||
User Password:
|
||||
Repeat User Password:
|
||||
+-----------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-----------+----------------------------------+
|
||||
| domain_id | default |
|
||||
| enabled | True |
|
||||
| id | c859c96f57bd4989a8ea1a0b1d8ff7cd |
|
||||
| name | ceilometer |
|
||||
+-----------+----------------------------------+
|
||||
|
||||
* Add the ``admin`` role to the ``ceilometer`` user::
|
||||
|
||||
$ openstack role add --project service --user ceilometer admin
|
||||
|
||||
* Create the ``ceilometer`` service entity::
|
||||
|
||||
$ openstack service create --name ceilometer \
|
||||
--description "Telemetry" metering
|
||||
+-------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------------+----------------------------------+
|
||||
| description | Telemetry |
|
||||
| enabled | True |
|
||||
| id | 3405453b14da441ebb258edfeba96d83 |
|
||||
| name | ceilometer |
|
||||
| type | metering |
|
||||
+-------------+----------------------------------+
|
||||
|
||||
#. Create the Telemetry service API endpoints::
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
metering public http://controller:8777
|
||||
+--------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+----------------------------------+
|
||||
| enabled | True |
|
||||
| id | 340be3625e9b4239a6415d034e98aace |
|
||||
| interface | public |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | 8c2c7f1b9b5049ea9e63757b5533e6d2 |
|
||||
| service_name | celiometer |
|
||||
| service_type | metering |
|
||||
| url | http://controller:8777 |
|
||||
+--------------+----------------------------------+
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
metering internal http://controller:8777
|
||||
+--------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+----------------------------------+
|
||||
| enabled | True |
|
||||
| id | 340be3625e9b4239a6415d034e98aace |
|
||||
| interface | internal |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | 8c2c7f1b9b5049ea9e63757b5533e6d2 |
|
||||
| service_name | celiometer |
|
||||
| service_type | metering |
|
||||
| url | http://controller:8777 |
|
||||
+--------------+----------------------------------+
|
||||
|
||||
$ openstack endpoint create --region RegionOne \
|
||||
metering admin http://controller:8777
|
||||
+--------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+--------------+----------------------------------+
|
||||
| enabled | True |
|
||||
| id | 340be3625e9b4239a6415d034e98aace |
|
||||
| interface | admin |
|
||||
| region | RegionOne |
|
||||
| region_id | RegionOne |
|
||||
| service_id | 8c2c7f1b9b5049ea9e63757b5533e6d2 |
|
||||
| service_name | celiometer |
|
||||
| service_type | metering |
|
||||
| url | http://controller:8777 |
|
||||
+--------------+----------------------------------+
|
||||
|
||||
|
||||
Install and configure components
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Install the OpenStack Telemetry Controller bundle::
|
||||
|
||||
# swupd bundle-add openstack-telemetry
|
||||
|
||||
#. Custom configurations will be located at ``/etc/ceilometer``.
|
||||
|
||||
* Create ``/etc/ceilometer`` directory::
|
||||
|
||||
# mkdir /etc/ceilometer
|
||||
|
||||
* Create the empty ceilometer configuration file::
|
||||
|
||||
# touch /etc/ceilometer/ceilometer.conf
|
||||
|
||||
#. Edit the ``/etc/ceilometer/ceilometer.conf`` file and
|
||||
complete the following actions:
|
||||
|
||||
* In the ``[database]`` section, configure database access. Replace
|
||||
*CEILOMETER_DBPASS* with the password you chose for the
|
||||
Telemetry module database. You must escape special characters such
|
||||
as ':', '/', '+', and '@' in the connection string in accordance
|
||||
with RFC2396::
|
||||
|
||||
[database]
|
||||
...
|
||||
connection = mongodb://ceilometer:CEILOMETER_DBPASS@controller:27017/ceilometer
|
||||
|
||||
* In the ``[DEFAULT]`` and ``[oslo_messaging_rabbit]`` sections,
|
||||
configure RabbitMQ message queue access. Replace *RABBIT_PASS*
|
||||
with the password you chose for the ``openstack`` account in
|
||||
RabbitMQ::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
rpc_backend = rabbit
|
||||
|
||||
[oslo_messaging_rabbit]
|
||||
...
|
||||
rabbit_host = controller
|
||||
rabbit_userid = openstack
|
||||
rabbit_password = RABBIT_PASS
|
||||
|
||||
* In the ``[DEFAULT]`` and ``[keystone_authtoken]`` sections,
|
||||
configure Identity service access. Replace *CEILOMETER_PASS*
|
||||
with the password you chose for the ``celiometer`` user in the
|
||||
Identity service::
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
auth_strategy = keystone
|
||||
|
||||
[keystone_authtoken]
|
||||
...
|
||||
auth_uri = http://controller:5000
|
||||
auth_url = http://controller:35357
|
||||
auth_plugin = password
|
||||
project_domain_id = default
|
||||
user_domain_id = default
|
||||
project_name = service
|
||||
username = ceilometer
|
||||
password = CEILOMETER_PASS
|
||||
|
||||
* In the ``[service_credentials]`` section, configure service
|
||||
credentials. Replace *CEILOMETER_PASS* with the password you
|
||||
chose for the ``ceilometer`` user in the Identity service::
|
||||
|
||||
[service_credentials]
|
||||
...
|
||||
os_auth_url = http://controller:5000/v2.0
|
||||
os_username = ceilometer
|
||||
os_tenant_name = service
|
||||
os_password = CEILOMETER_PASS
|
||||
os_endpoint_type = internalURL
|
||||
os_region_name = RegionOne
|
||||
|
||||
* Ensure files have proper ownership by running the following command::
|
||||
|
||||
# systemctl restart update-triggers.target
|
||||
|
||||
|
||||
Finalizing installation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Start the Telemetry services and configure them to start when the system boots::
|
||||
|
||||
# systemctl enable ceilometer-agent-central.service \
|
||||
ceilometer-agent-notification.service \
|
||||
ceilometer-api.service \
|
||||
ceilometer-collector.service \
|
||||
ceilometer-alarm-evaluator.service \
|
||||
ceilometer-alarm-notifier.service
|
||||
|
||||
# systemctl start ceilometer-agent-central.service \
|
||||
ceilometer-agent-notification.service \
|
||||
ceilometer-api.service \
|
||||
ceilometer-collector.service \
|
||||
ceilometer-alarm-evaluator.service \
|
||||
ceilometer-alarm-notifier.service
|
||||
|
||||
Next topic: :ref:`openstack_object_storage`.
|
||||
@@ -50,7 +50,7 @@ Create a virtual machine
|
||||
|
||||
PS C:\> Convert-VHD -Path c:\path\to\clear-XXXX-live.vhd -DestinationPath c:\path\to\clear-XXXX-live.vhdx
|
||||
|
||||
You can save the new *VHDX* virtual hard disk in :file:`C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks`.
|
||||
You can save the new *VHDX* virtual hard disk in :file:`C:\\Users\\Public\\Documents\\Hyper-V\\Virtual Hard Disks`.
|
||||
|
||||
4. Create virtual machine using the **Hyper-V Manager**:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user