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:
Leona
2016-04-15 08:20:32 -07:00
29 changed files with 1047 additions and 4218 deletions
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

+344
View File
@@ -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 grantleys NICs to the second
grantleys 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
+291
View File
@@ -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.
+5 -14
View File
@@ -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
+4 -1
View File
@@ -5,4 +5,7 @@ Advanced configuration
:maxdepth: 2
network_boot
mixer
mixer
ac-dpdk
ac-ovs-dpdk
+78
View File
@@ -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
View File
@@ -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. Heres 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
=======================
-478
View File
@@ -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`.
-527
View File
@@ -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`.
+14
View File
@@ -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`
+53
View File
@@ -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`
-33
View File
@@ -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`.
+59
View File
@@ -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
-75
View File
@@ -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`.
-416
View File
@@ -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`.
-277
View File
@@ -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`.
-26
View File
@@ -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`.
-672
View File
@@ -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`.
-772
View File
@@ -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.
-393
View File
@@ -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`.
-52
View File
@@ -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`.
-47
View File
@@ -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`.
-260
View File
@@ -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`.
+1 -1
View File
@@ -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**: