From 2e2d0906957a62b4abf158732bf571a5fbac0159 Mon Sep 17 00:00:00 2001 From: Serg Melikyan Date: Tue, 29 Apr 2014 15:51:50 +0400 Subject: [PATCH] Added missing articles from 0.3 * RabbitMQ additional instance * Specify SecurityGroups quotas * Reconfigure rate-limits for Nova * Configuring Neutron Closes-bug: #1287131 Change-Id: I694c7e1b95bc1f4fd5424e4190e1dc3ced063b3d --- .../src/docbkx/content/general.xml | 206 ++++++++++++++++++ 1 file changed, 206 insertions(+) diff --git a/src/administrators-guide/src/docbkx/content/general.xml b/src/administrators-guide/src/docbkx/content/general.xml index 7f1aa38..38dabe3 100644 --- a/src/administrators-guide/src/docbkx/content/general.xml +++ b/src/administrators-guide/src/docbkx/content/general.xml @@ -362,4 +362,210 @@ LOGFILE=$SCREEN_LOGDIR/stack.sh.log + +
+ RabbitMQ additional instance + + 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). + + + Configuration steps + + + + + Create file /etc/default/rabbitmq-murano with options listed below + + + #!/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 + + + + + Make copy of the original rabbitmq-server init script: + + + cd /etc/init.d + cp rabbitmq-server rabbitmq-server-murano + + + + + Make changes inside new file rabbitmq-server-murano, after test calls: + + + ... + test -x $DAEMON || exit 0 + test -x $CONTROL || exit 0 + . /etc/default/rabbitmq-murano + RETVAL=0 + ... + + + + + Fill in configuration files for new RabbitMQ instance. + + + + + Modify /etc/rabbitmq/enabled_plugins.murano + + + [rabbitmq_management] + + + + + Modify /etc/rabbitmq/rabbitmq-murano.config + + + [ + {rabbit, [ + {tcp_listeners, [5674]}, + {log_levels,[ + {connection, error} + ]} + ]}, + {rabbitmq_management, [ + {listener, [{port, 15673}]} + ]}, + {rabbitmq_mochiweb, [ + {listeners, [{mgmt, [{port, 55673}]}]} + ]} + ]. + + + + + Check that service works fine: + + + service rabbitmq-server-murano start + service rabbitmq-server-murano status + service rabbitmq-server-murano stop + + + + + Enable service start at OS boot time: + + + update-rc.d rabbitmq-server-murano defaults + + + + Don't forget about firewall rules for new RabbitMQ service! +
+
+ Specify SecurityGroups quotas + + Default quotas driver used by Neutron is neutron.quota.ConfDriver, all limits set in /etc/neutron/ + neutron.conf - is not flexible. To extend functionality and flexibility, default quota driver should be + changed to - neutron.db.quota_db.DbQuotaDrive. + + + + + Change /etc/neutron/neutron.conf with the next values: + + + [QUOTAS] + ... + #quota_driver = neutron.quota.ConfDriver + quota_driver = neutron.db.quota_db.DbQuotaDriver + ... + + + + + Restart all neutron services: + + + cd /etc/init.d/ + for q in quantum-*; do restart $q; done + + + + + Update required quota via Neutron CLI: + + + 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 | + +---------------------+-------+ + + + +
+
+ Reconfigure rate-limits for Nova + + Please reconfigure rate-limits to at least 500-1000 hits per minute. + + + API calls rate limits could be configured using this manual + or by disabling ratelimits in the /etc/nova/api-paste.ini file. + + ... + [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 + ... + + +
+
+ Configuring Neutron +
+ Allow subnet ip-range overlapping + + 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. + + + However, by default Neutron does not allow overlapping IPs for different subnets - even in different Networks. + To override this restriction, change /etc/neutron/neutron.conf: uncomment allow_overlapping_ips parameter + and change its value to True: + + + [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 + + + Then, restart all neutron services: + + + cd /etc/init.d/ + for q in quantum-*; do restart $q; done + +
+