572 lines
23 KiB
XML
572 lines
23 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!--
|
|
Copyright (c) 2013 Mirantis, Inc.
|
|
|
|
Licensed under the Apache License, Version 2.0 (the "License");
|
|
you may not use this file except in compliance with the License.
|
|
You may obtain a copy of the License at
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
Unless required by applicable law or agreed to in writing, software
|
|
distributed under the License is distributed on an "AS IS" BASIS,
|
|
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
implied.
|
|
See the License for the specific language governing permissions and
|
|
limitations under the License.
|
|
-->
|
|
|
|
<chapter xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
xsi:schemaLocation="http://docbook.org/ns/docbook http://www.docbook.org/xml/5.0/xsd/docbook.xsd
|
|
http://www.w3.org/1999/xlink http://www.w3.org/1999/xlink.xsd"
|
|
version="5.0">
|
|
<title>General Deployment Steps</title>
|
|
<section>
|
|
<title>Prepare A Lab For Murano</title>
|
|
<para>
|
|
This section provides basic information about lab's system requirements. It also contains a description
|
|
of a test which you may use to check if your hardware fits the requirements. To do this, run the test
|
|
and compare the results with baseline data provided.
|
|
</para>
|
|
<section>
|
|
<title>Lab Requirements</title>
|
|
<table xml:id="_hardware_requirements" frame="all">
|
|
<title>Hardware requirements</title>
|
|
<tgroup cols="3" align="left" rowsep="1" colsep="1">
|
|
<colspec colname="col1" colwidth="1*"/>
|
|
<colspec colname="col2" colwidth="3*"/>
|
|
<colspec colname="col3" colwidth="3*"/>
|
|
<thead>
|
|
<row>
|
|
<entry>Criteria</entry>
|
|
<entry>Minimal</entry>
|
|
<entry>Recommended</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry>CPU</entry>
|
|
<entry>4 core @ 2.4 GHz</entry>
|
|
<entry>24 core @ 2.67 GHz</entry>
|
|
</row>
|
|
<row>
|
|
<entry>RAM</entry>
|
|
<entry>8 GB</entry>
|
|
<entry>24 GB or more</entry>
|
|
</row>
|
|
<row>
|
|
<entry>HDD</entry>
|
|
<entry>2 x 500 GB (7200 rpm)</entry>
|
|
<entry>4 x 500 GB (7200 rpm)</entry>
|
|
</row>
|
|
<row>
|
|
<entry>RAID</entry>
|
|
<entry>Software RAID-1 (use mdadm as it will improve read performance almost two times)</entry>
|
|
<entry>Hardware RAID-10</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
<para>
|
|
There are a few possible storage configurations except the shown above. All of them were tested and were working well.
|
|
</para>
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
1x SSD 500+ GB
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
1x HDD (7200 rpm) 500+ GB and 1x SSD 250+ GB (install the system onto the HDD and mount the SSD drive to folder where VM images are)
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
1x HDD (15000 rpm) 500+ GB
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
<para>
|
|
The list of OSes which can be used for a lab shown below:
|
|
</para>
|
|
<table xml:id="_software_requirements" frame="all">
|
|
<title>OS Requirements</title>
|
|
<tgroup cols="1" align="left" rowsep="1" colsep="1">
|
|
<colspec colname="col1" colwidth="1*"/>
|
|
<thead>
|
|
<row>
|
|
<entry>List</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry>Ubuntu Server 12.04 LTS</entry>
|
|
</row>
|
|
<row>
|
|
<entry>Centos 6.4</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</section>
|
|
<section>
|
|
<title>Test Your Lab Host Performance</title>
|
|
<para>
|
|
We have measured time required to boot 1 to 5 instances of Windows system simultaneously. You can use
|
|
this data as the baseline to check if your system is fast enough.
|
|
</para>
|
|
<para>
|
|
You should use sysprepped images for this test, to simulate VM first boot.
|
|
</para>
|
|
<para>
|
|
Steps to reproduce test:
|
|
</para>
|
|
<orderedlist numeration="arabic">
|
|
<listitem>
|
|
<para>
|
|
Prepare Windows 2012 Standard (with GUI) image in QCOW2 format. Let's assume that its name is ws-2012-std.qcow2
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Ensure that there is NO KVM PROCESSES on the host. To do this, run command:
|
|
<screen>
|
|
># ps aux | grep kvm
|
|
</screen>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Make 5 copies of Windows image file:
|
|
</para>
|
|
<screen>
|
|
># for i in $(seq 5); do \
|
|
cp ws-2012-std.qcow2 ws-2012-std-$i.qcow2; done
|
|
</screen>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Create script start-vm.sh in the folder with .qcow2 files:
|
|
</para>
|
|
<screen>
|
|
#!/bin/bash
|
|
[ -z $1 ] || echo "VM count not provided!"; exit 1
|
|
for i in $(seq $1); do
|
|
echo "Starting VM $i ..."
|
|
kvm \
|
|
-m 1024 \
|
|
-drive file=ws-2012-std-$i.qcow2,if=virtio \
|
|
-net user -net nic,model=virtio \
|
|
-nographic \
|
|
-usbdevice tablet \
|
|
-vnc :$i &
|
|
done
|
|
</screen>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Start ONE instance with command below (as root) and measure time between VM’s launch and
|
|
the moment when Server Manager window appears. To view VM’s desktop, connect with VNC viewer to your host to VNC screen :1 (port 5901):
|
|
</para>
|
|
<screen>
|
|
># ./start-vm.sh 1
|
|
</screen>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Turn VM off. You may simply kill all KVM processes by
|
|
</para>
|
|
<screen>
|
|
># killall kvm
|
|
</screen>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Start FIVE instances with command below (as root) and measure time interval between ALL VM’s
|
|
launch and the moment when LAST Server Manager window appears. To view VM’s desktops, connect with
|
|
VNC viewer to your host to VNC screens :1 thru :5 (ports 5901-5905):
|
|
</para>
|
|
<screen>
|
|
># ./start-vm.sh 5
|
|
</screen>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Turn VMs off. You may simply kill all KVM processes by
|
|
</para>
|
|
<screen>
|
|
># killall kvm
|
|
</screen>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
<section>
|
|
<title>Baseline Data</title>
|
|
<para>
|
|
The table below provides baseline data which we've got in our environment.
|
|
</para>
|
|
<para>
|
|
<emphasis role="bold">Avg. Time</emphasis> refers to the lab with recommended hardware configuration, while
|
|
<emphasis role="bold">Max. Time</emphasis> refers to minimal hardware configuration.
|
|
</para>
|
|
<informaltable
|
|
frame="all"
|
|
rowsep="1" colsep="1"
|
|
>
|
|
<tgroup cols="3">
|
|
<colspec colname="col_1" colwidth="33*"/>
|
|
<colspec colname="col_2" colwidth="33*"/>
|
|
<colspec colname="col_3" colwidth="33*"/>
|
|
<thead>
|
|
<row>
|
|
<entry/>
|
|
<entry>Boot ONE instance</entry>
|
|
<entry>Boot FIVE instances</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry align="left" valign="top">
|
|
<para>Avg. Time</para>
|
|
</entry>
|
|
<entry align="left" valign="top">
|
|
<para>3m:40s</para>
|
|
</entry>
|
|
<entry align="left" valign="top">
|
|
<para>8m</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry align="left" valign="top">
|
|
<para>Max. Time</para>
|
|
</entry>
|
|
<entry align="left" valign="top">
|
|
<para>5m</para>
|
|
</entry>
|
|
<entry align="left" valign="top">
|
|
<para>20m</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
</section>
|
|
<section>
|
|
<title>Host Optimizations</title>
|
|
<para>
|
|
Default KVM installation could be improved to provide better performance.
|
|
</para>
|
|
<para>
|
|
The following optimizations may improve host performance up to 30%:
|
|
</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
change default scheduler from <emphasis role="strong">CFQ</emphasis> to
|
|
<emphasis role="strong">Deadline</emphasis>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
use <emphasis role="strong">ksm</emphasis>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
use <emphasis role="strong">vhost-net</emphasis>
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
</section>
|
|
<section>
|
|
<title>Install OpenStack</title>
|
|
<warning>
|
|
<para>
|
|
Please keep in mind that in this guide we assume that Murano is installed in a separate devbox environment.
|
|
</para>
|
|
</warning>
|
|
<para>
|
|
Murano devbox requires an OpenStack installed somewhere in your lab. This OpenStack installation must be reachable from the Murano box.
|
|
Murano works great with Openstack packages installation as well as devstack installation.
|
|
For now we support Openstack Grizzly and working on Havana integration.
|
|
</para>
|
|
<para>
|
|
<emphasis role="strong">Package-based Installation</emphasis>
|
|
</para>
|
|
<para>
|
|
To install Openstack Grizzly please consult the following sources:
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
<link xlink:href="https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide">OpenStack Grizzly Install Guide</link>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<link xlink:href="http://longgeek.com/2013/03/18/openstack-grizzly-g3-for-ubuntu-12-04-all-in-one-installation-2/?lang=en">OpenStack Grizzly-g3 for Ubuntu 12.04 all-in-one installation</link>
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
<para>
|
|
In addition to that <link xlink:href=" https://wiki.openstack.org/wiki/Heat">Heat</link> should be installed.
|
|
Follow the link to setup Heat on
|
|
<link xlink:href="http://openstack.redhat.com/Deploy_Heat_and_launch_your_first_Application">Ubuntu</link>
|
|
and/or on <link xlink:href="http://docs.openstack.org/developer/heat/getting_started/on_ubuntu.html">CentOS</link>.
|
|
</para>
|
|
<para>
|
|
<emphasis role="strong">Devstack-based Installation</emphasis>
|
|
</para>
|
|
<para>
|
|
For a Devstack installation please vizit <link xlink:href="http://devstack.org/">Devstack Home Page</link> and clone devstack repository to your host.
|
|
</para>
|
|
<para>
|
|
For further installation process we recommend to use Devstack's <link xlink:href="http://devstack.org/guides/single-vm.html">Single VM Installation Guide</link>.
|
|
</para>
|
|
<para>
|
|
The example of localrc configuration file is provided below:
|
|
</para>
|
|
<formalpara>
|
|
<title>localrc example</title>
|
|
<para>
|
|
<screen width="80">
|
|
HOST_IP=
|
|
FLAT_INTERFACE=
|
|
FLOATING_RANGE=
|
|
|
|
ADMIN_PASSWORD=swordfish
|
|
MYSQL_PASSWORD=swordfish
|
|
RABBIT_PASSWORD=swordfish
|
|
SERVICE_PASSWORD=swordfish
|
|
SERVICE_TOKEN=tokentoken
|
|
|
|
ENABLED_SERVICES+=,heat,h-api,h-api-cfn,h-api-cw,h-eng
|
|
|
|
# Image's cache is in $TOP_DIR/files
|
|
IMAGE_URLS+=",http://fedorapeople.org/groups/heat/prebuilt-jeos-images/"
|
|
IMAGE_URLS+="F17-x86_64-cfntools.qcow2"
|
|
|
|
# /etc/nova/nova.conf
|
|
EXTRA_OPTS=(force_config_drive=true libvirt_images_type=qcow2 force_raw_images=false)
|
|
|
|
# Logging
|
|
SCREEN_LOGDIR=/opt/stack/log/
|
|
LOGFILE=$SCREEN_LOGDIR/stack.sh.log
|
|
</screen>
|
|
</para>
|
|
</formalpara>
|
|
</section>
|
|
|
|
<section>
|
|
<title>RabbitMQ additional instance</title>
|
|
<para>
|
|
RabbitMQ is used for services interconnection in the OpenStack. Murano also uses RabbitMQ as "message queue" service but the separate instance. In the OpenStack normal installation "message queue" service resides in the management network segment and should not be reachable from any tenant networks to prevent security breach.
|
|
Murano uses its own agent service running on deploying instance directly. Agent should have the ability to communicate with "message queue" service. Create one more "message queue" service instance in the external network, reachable from tenant networks through the OpenStack network router service (Quantum/Neutron).
|
|
</para>
|
|
<para>
|
|
<emphasis role="strong">Configuration steps</emphasis>
|
|
</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Create file <filename>/etc/default/rabbitmq-murano</filename> with options listed below
|
|
</para>
|
|
<screen>
|
|
#!/bin/sh
|
|
#
|
|
#
|
|
export RABBITMQ_NODENAME=murano@$(hostname)
|
|
export RABBITMQ_CONFIG_FILE=/etc/rabbitmq/rabbitmq-murano
|
|
export RABBITMQ_ENABLED_PLUGINS_FILE=/etc/rabbitmq/enabled_plugins.murano
|
|
CONTROL="${CONTROL} -n ${RABBITMQ_NODENAME}"
|
|
PID_FILE=/var/run/rabbitmq/murano.pid
|
|
</screen>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Make copy of the original rabbitmq-server init script:
|
|
</para>
|
|
<screen>
|
|
cd /etc/init.d
|
|
cp rabbitmq-server rabbitmq-server-murano
|
|
</screen>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Make changes inside new file <filename>rabbitmq-server-murano</filename>, after test calls:
|
|
</para>
|
|
<screen>
|
|
...
|
|
test -x $DAEMON || exit 0
|
|
test -x $CONTROL || exit 0
|
|
. /etc/default/rabbitmq-murano
|
|
RETVAL=0
|
|
...
|
|
</screen>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>
|
|
<emphasis role="strong">Fill in configuration files for new RabbitMQ instance.</emphasis>
|
|
</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Modify <filename>/etc/rabbitmq/enabled_plugins.murano</filename>
|
|
</para>
|
|
<screen>
|
|
[rabbitmq_management]
|
|
</screen>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Modify <filename>/etc/rabbitmq/rabbitmq-murano.config</filename>
|
|
</para>
|
|
<screen>
|
|
[
|
|
{rabbit, [
|
|
{tcp_listeners, [5674]},
|
|
{log_levels,[
|
|
{connection, error}
|
|
]}
|
|
]},
|
|
{rabbitmq_management, [
|
|
{listener, [{port, 15673}]}
|
|
]},
|
|
{rabbitmq_mochiweb, [
|
|
{listeners, [{mgmt, [{port, 55673}]}]}
|
|
]}
|
|
].
|
|
</screen>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Check that service works fine:
|
|
</para>
|
|
<screen>
|
|
service rabbitmq-server-murano start
|
|
service rabbitmq-server-murano status
|
|
service rabbitmq-server-murano stop
|
|
</screen>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Enable service start at OS boot time:
|
|
</para>
|
|
<screen>
|
|
update-rc.d rabbitmq-server-murano defaults
|
|
</screen>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<warning><para>Don't forget about firewall rules for new RabbitMQ service!</para></warning>
|
|
</section>
|
|
<section>
|
|
<title>Specify SecurityGroups quotas</title>
|
|
<para>
|
|
Default quotas driver used by Neutron is <filename>neutron.quota.ConfDriver</filename>, all limits set in <filename>/etc/neutron/
|
|
neutron.conf</filename> - is not flexible. To extend functionality and flexibility, default quota driver should be
|
|
changed to - <filename>neutron.db.quota_db.DbQuotaDrive</filename>.
|
|
</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Change <filename>/etc/neutron/neutron.conf</filename> with the next values:
|
|
</para>
|
|
<screen>
|
|
[QUOTAS]
|
|
...
|
|
#quota_driver = neutron.quota.ConfDriver
|
|
quota_driver = neutron.db.quota_db.DbQuotaDriver
|
|
...
|
|
</screen>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Restart all neutron services:
|
|
</para>
|
|
<screen>
|
|
cd /etc/init.d/
|
|
for q in quantum-*; do restart $q; done
|
|
</screen>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Update required quota via Neutron CLI:
|
|
</para>
|
|
<screen>
|
|
neutron quota-update --security_group 100 --tenant-id <tenant_id>
|
|
+---------------------+-------+
|
|
| Field | Value |
|
|
+---------------------+-------+
|
|
| floatingip | 50 |
|
|
| network | 10 |
|
|
| port | 50 |
|
|
| router | 10 |
|
|
| security_group | 100 |
|
|
| security_group_rule | 100 |
|
|
| subnet | 10 |
|
|
+---------------------+-------+
|
|
</screen>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
<section>
|
|
<title>Reconfigure rate-limits for Nova</title>
|
|
<para>
|
|
Please reconfigure rate-limits to at least 500-1000 hits per minute.
|
|
</para>
|
|
<para>
|
|
API calls rate limits could be configured using <link xlink:href="http://docs.openstack.org/grizzly/openstack-
|
|
compute/admin/content/configuring-compute-API.html">this manual</link>
|
|
or by disabling ratelimits in the <filename>/etc/nova/api-paste.ini</filename> file.
|
|
<screen>
|
|
...
|
|
[composite:openstack_compute_api_v2]
|
|
use = call:nova.api.auth:pipeline_factory
|
|
#noauth = faultwrap sizelimit noauth ratelimit osapi_compute_app_v2
|
|
#keystone = faultwrap sizelimit authtoken keystonecontext ratelimit osapi_compute
|
|
noauth = faultwrap sizelimit noauth osapi_compute_app_v2
|
|
keystone = faultwrap sizelimit authtoken keystonecontext osapi_compute_app_v2
|
|
keystone_nolimit = faultwrap sizelimit authtoken keystonecontext osapi_compute_ap
|
|
...
|
|
</screen>
|
|
</para>
|
|
</section>
|
|
<section>
|
|
<title>Configuring Neutron</title>
|
|
<section>
|
|
<title>Allow subnet ip-range overlapping</title>
|
|
<para>
|
|
During environment deployment, Murano will create dedicated network for each of them, and every such network will have a subnet created.
|
|
All these subnets will have identical ip-ranges. Theoretically this is perfectly fine, as these subnets belong to different isolated Networks
|
|
(L2 segments) and are connected to different routers.
|
|
</para>
|
|
<para>
|
|
However, by default Neutron does not allow overlapping IPs for different subnets - even in different Networks.
|
|
To override this restriction, change <filename>/etc/neutron/neutron.conf</filename>: uncomment <filename>allow_overlapping_ips</filename> parameter
|
|
and change its value to <filename>True</filename>:
|
|
</para>
|
|
<programlisting>
|
|
[DEFAULT]
|
|
...
|
|
# Enable or disable overlapping IPs for subnets
|
|
# Attention: the following parameter MUST be set to False if Neutron is
|
|
# being used in conjunction with nova security groups
|
|
allow_overlapping_ips = True
|
|
</programlisting>
|
|
<para>
|
|
Then, restart all neutron services:
|
|
</para>
|
|
<screen>
|
|
cd /etc/init.d/
|
|
for q in quantum-*; do restart $q; done
|
|
</screen>
|
|
</section>
|
|
</section>
|
|
</chapter>
|