Synergy Doc
Search…
Deployment and Administration guide

Manual installation and configuration

Repository

Install the INDIGO repository.

Install the Synergy packages

On CentOS7:
1
yum install python-synergy-service python-synergy-scheduler-manager
Copied!
On Ubuntu:
1
apt-get install python-synergy-service python-synergy-scheduler-manager
Copied!
They can be installed in the OpenStack controller node or on another node.

Updating the Synergy packages

The Synergy project makes periodic releases. As a system administrator you can get the latest features and bug fixes by updating Synergy.
This is done using the standard update commands for your OS, as long you have the INDIGO repository set up.
On Ubuntu:
1
apt-get update
2
apt-get upgrade
Copied!
On CentOS:
1
yum update
Copied!
Once the update is complete remember to restart the service. Follow the instructions in "Configure and start Synergy" section of this guide to see how to do it.

Setup the Synergy database

Then use the database access client to connect to the database server as the root user:
1
$ mysql -u root -p
Copied!
Create the synergy database:
1
CREATE DATABASE synergy;
Copied!
Grant proper access to the glance database:
1
GRANT ALL PRIVILEGES ON synergy.* TO 'synergy'@'%' IDENTIFIED BY 'SYNERGY_DBPASS';
2
flush privileges;
Copied!
Replace SYNERGY_DBPASS with a suitable password.
Exit the database access client.

Add Synergy as an OpenStack endpoint and service

Source the admin credentials to gain access to admin-only CLI commands:
1
$ . admin-openrc
Copied!
Register the Synergy service and endpoint in the Openstack service catalog:
1
openstack service create --name synergy management
2
openstack endpoint create --region RegionOne management public http://$SYNERGY_HOST_IP:8051
3
openstack endpoint create --region RegionOne management admin http://$SYNERGY_HOST_IP:8051
4
openstack endpoint create --region RegionOne management internal http://$SYNERGY_HOST_IP:8051
Copied!

Adjust nova notifications

Make sure that nova notifications are enabled on the controller and compute node. Edit the /etc/nova/nova.conf file. In the [DEFAULT] and [oslo_messaging_notifications] sections add the following attributes:
1
[DEFAULT]
2
...
3
notify_on_state_change = vm_state
4
default_notification_level = INFO
5
6
[oslo_messaging_notifications]
7
...
8
driver = messaging
9
topics = notifications
Copied!
The topics parameter is used by Nova for informing listeners about the state changes of the VMs. In case some other service (e.g. Ceilometer) is listening on the default topic notifications, to avoid the competition on consuming the notifications, please define a new topic specific for Synergy (e.g. topics = notifications,synergy_notifications).
Then restart the nova services on the Compute node.

Configure Controller to use Synergy

Perform these steps on the controller node. In /etc/nova/ create a nova-api.conf file. Edit /etc/nova/nova-api.conf file and add the following to it:
1
[conductor]
2
topic=synergy
Copied!
The topic must have the same value of the synergy_topic defined in the /etc/synergy/synergy_scheduler.conf file.
Only for Ubuntu 16.04, edit the /etc/init.d/nova-api file and replace
1
[ "x$USE_LOGFILE" != "xno" ] && DAEMON_ARGS="$DAEMON_ARGS --log-file=$LOGFILE"
Copied!
with
1
[ "x$USE_LOGFILE" != "xno" ] && DAEMON_ARGS="$DAEMON_ARGS --config-file /etc/nova/nova-api.conf --log-file=$LOGFILE"
Copied!
Restart nova-api service to enable your configuration.
On the node where it is installed RabbitMQ, run the following command to check whether your configuration is correct:
1
# rabbitmqctl list_queues | grep synergy
2
synergy_fanout_1e30d613c19142ec8ce452292042c35c 0
3
synergy 0
4
synergy.192.168.60.231 0
Copied!
The output of the command should show something similar.

Configure and start Synergy

Configure the Synergy service, as explained in the following section.
Then start and enable the Synergy service. On CentOS:
1
systemctl start synergy
2
systemctl enable synergy
Copied!
On Ubuntu:
1
service synergy start
Copied!
If Synergy complains about incompatibility with the version of installed oslo packages, e.g.:
1
synergy.service - ERROR - manager 'timer' instantiation error: (oslo.log
2
1.10.0 (/usr/lib/python2.7/site-packages),
3
Requirement.parse('oslo.log<2.3.0,>=2.0.0'))
4
5
synergy.service - ERROR - manager 'timer' instantiation error:
6
(oslo.service 0.9.0 (/usr/lib/python2.7/site-packages),
7
Requirement.parse('oslo.service<1.3.0,>=1.0.0'))
8
9
synergy.service - ERROR - manager 'timer' instantiation error:
10
(oslo.concurrency 2.6.0 (/usr/lib/python2.7/site-packages),
11
Requirement.parse('oslo.concurrency<3.3.0,>=3.0.0'))
12
13
synergy.service - ERROR - manager 'timer' instantiation error:
14
(oslo.middleware 2.8.0 (/usr/lib/python2.7/site-packages),
15
16
Requirement.parse('oslo.middleware<3.5.0,>=3.0.0'))
Copied!
please patch the the file /usr/lib/python2.7/site-packages/synergy_service-1.0.0-py2.7.egg-info/requires.txt by removing the versions after the dependencies.

The Synergy configuration file

Synergy must be configured properly by filling the synergy.conf and synergy_scheduler.conf configuration files in /etc/synergy/. To apply the changes of any configuration parameter, the Synergy service must be restarted.
This is an example of the synergy.conf configuration file:
1
[DEFAULT]
2
3
4
[Logger]
5
# set the logging file name
6
filename = /var/log/synergy/synergy.log
7
8
# set the logging level. Valid values are: CRITICAL, ERROR, WARNING, INFO, DEBUG, NOTSET.
9
level = INFO
10
11
# set the format of the logged messages
12
formatter = "%(asctime)s - %(name)s - %(levelname)s - %(message)s"
13
14
# set the max file size
15
maxBytes = 1048576
16
17
# set the logging rotation threshold
18
backupCount = 100
19
20
21
[WSGI]
22
# set the Synergy hostname
23
host = SYNERGY_HOST
24
25
# set the WSGI port (default: 8051)
26
port = 8051
27
28
# set the number of threads
29
threads = 2
30
31
# set the SSL
32
use_ssl = False
33
#ssl_ca_file =
34
#ssl_cert_file =
35
#ssl_key_file =
36
max_header_line = 16384
37
retry_until_window = 30
38
tcp_keepidle = 600
39
backlog = 4096
Copied!
The following describes the meaning of the attributes of the synergy.conf file, for each possible section:
Section [Logger]
Attribute
Description
filename
The name of the log file
level
The logging level. Valid values are: CRITICAL, ERROR, WARNING, INFO, DEBUG, NOTSET
formatter
The format of the logged messages
maxBytes
The maximum size of a log file. When this size is reached, the log file is rotated
backupCount
The number of log files to be kept
Section [WSGI]
Attribute
Description
host
The hostname where the Synergy service is deployed
port
The port used by the Synergy service
threads
The number of threads used by the Synergy service
use ssl
Specify if the service is secured through SSL
ssl_ca_file
The CA certificate file to use to verify connecting clients
ssl_cert_file
The Identifying certificate PEM file to present to clients
ssl_key_file
The Private key PEM file used to sign cert_file certificate
max_header_line
The maximum size of message headers to be accepted (default: 16384)
retry_until_window
The number of seconds to keep retrying for listening (default: 30sec)
tcp_keepidle
The value of TCP_KEEPIDLE in seconds for each server socket
backlog
The number of backlog requests to configure the socket with (default: 4096). The listen backlog is a socket setting specifying that the kernel how to limit the number of outstanding (i.e. not yet accepted) connections in the listen queue of a listening socket. If the number of pending connections exceeds the specified size, new ones are automatically rejected
This example shows how to configure the synergy_scheduler.conf file:
1
[DEFAULT]
2
3
4
[SchedulerManager]
5
autostart = True
6
7
# set the manager rate (minutes)
8
rate = 1
9
10
# set the list of projects accessing to the shared quota
11
# projects = prj_a, prj_b
12
#projects =
13
14
# set the projects share
15
# shares = prj_a=70, prj_b=30
16
#shares =
17
18
# set the default max time to live (minutes) for VM/Container (default: 2880)
19
default_TTL = 2880
20
21
# set, for the specified projects, the max time to live (minutes) for VM/Container
22
# TTLs = prj_a=1440, prj_b=2880
23
#TTLs =
24
25
# set the max depth used by the backfilling strategy (default: 100)
26
# this allows Synergy to not check the whole queue when looking for VMs to start
27
backfill_depth = 100
28
29
# set the notification topic used by Nova for informing listeners about the state
30
# changes of the VMs. In case some other service (e.g. Ceilometer) is listening
31
# on the default Nova topic (i.e. "notifications"), please define a new topic
32
specific for Synergy (e.g. notification_topics = notifications,synergy_notifications)
33
notification_topic = notifications
34
35
36
[FairShareManager]
37
autostart = True
38
39
# set the manager rate (minutes)
40
rate = 2
41
42
# set the period size (default: 7 days)
43
period_length = 7
44
45
# set num of periods (default: 3)
46
periods = 3
47
48
# set the default share value (default: 10)
49
default_share = 10
50
51
# set the dacay weight, float value [0,1] (default: 0.5)
52
decay_weight = 0.5
53
54
# set the vcpus weight (default: 100)
55
vcpus_weight = 50
56
57
# set the age weight (default: 10)
58
age_weight = 10
59
60
# set the memory weight (default: 70)
61
memory_weight = 70
62
63
64
[KeystoneManager]
65
autostart = True
66
67
# set the manager rate (minutes)
68
rate = 5
69
70
# set the Keystone url (v3 only)
71
auth_url = http://CONTROLLER_HOST:5000/v3
72
73
# set the name of user with admin role
74
#username =
75
76
# set the password of user with admin role
77
#password =
78
79
# set the project name to request authorization on
80
#project_name =
81
82
# set the project id to request authorization on
83
#project_id =
84
85
# set the http connection timeout (default: 60)
86
timeout = 60
87
88
# set the user domain name (default: default)
89
user_domain_name = default
90
91
# set the project domain name (default: default)
92
project_domain_name = default
93
94
# set the clock skew. This forces the request for token, a
95
# delta time before the token expiration (default: 60 sec)
96
clock_skew = 60
97
98
# set the PEM encoded Certificate Authority to use when verifying HTTPs connections
99
#ssl_ca_file =
100
101
# set the SSL client certificate (PEM encoded)
102
#ssl_cert_file =
103
104
105
[NovaManager]
106
autostart = True
107
108
# set the manager rate (minutes)
109
rate = 5
110
111
#set the http connection timeout (default: 60)
112
timeout = 60
113
114
# set the AMQP backend type (e.g. rabbit, qpid)
115
#amqp_backend =
116
117
# set the AMQP HA cluster host:port pairs
118
#amqp_hosts =
119
120
# set the AMQP broker address where a single node is used (default: localhost)
121
amqp_host = localhost
122
123
# set the AMQP broker port where a single node is used
124
amqp_port = 5672
125
126
# set the AMQP user
127
#amqp_user =
128
129
# set the AMQP user password
130
#amqp_password =
131
132
# set the AMQP virtual host (default: /)
133
amqp_virtual_host = /
134
135
# set the Nova host (default: localhost)
136
host = CONTROLLER_HOST
137
138
# set the Synery topic as defined in nova-api.conf file (default: synergy)
139
synergy_topic = synergy
140
141
# set the Nova conductor topic (default: conductor)
142
conductor_topic = conductor
143
144
# set the Nova compute topic (default: compute)
145
compute_topic = compute
146
147
# set the Nova scheduler topic (default: scheduler)
148
scheduler_topic = scheduler
149
150
# set the Nova database connection
151
db_connection=DIALECT+DRIVER://USER:[email protected]_HOST/nova
152
153
# set the Nova CPU allocation ratio (default: 16)
154
cpu_allocation_ratio = 16
155
156
# set the Nova RAM allocation ratio (default: 1.5)
157
ram_allocation_ratio = 1.5
158
159
# set the Nova metadata_proxy_shared_secret
160
metadata_proxy_shared_secret =
161
162
# set the PEM encoded Certificate Authority to use when verifying HTTPs connections
163
#ssl_ca_file =
164
165
# set the SSL client certificate (PEM encoded)
166
#ssl_cert_file =
167
168
169
[QueueManager]
170
autostart = True
171
172
# set the manager rate (minutes)
173
rate = 60
174
175
# set the Synergy database connection:
176
db_connection = DIALECT+DRIVER://USER:[email protected]_HOST/synergy
177
178
# set the connection pool size (default: 10)
179
db_pool_size = 10
180
181
# set the number of seconds after which a connection is automatically
182
# recycled (default: 30)
183
db_pool_recycle = 30
184
185
# set the max overflow (default: 5)
186
db_max_overflow = 5
187
188
189
[QuotaManager]
190
autostart = True
191
192
# set the manager rate (minutes)
193
rate = 5
Copied!
Attributes and their meanings are described in the following tables:
Section [SchedulerManager]
Attribute
Description
autostart
Specifies if the SchedulerManager manager should be started when Synergy starts
rate
the time (in minutes) between two executions of the task implementing this manager
projects
Defines the list of OpenStack projects entitled to access the dynamic resources
shares
Defines, for each project entitled to access the dynamic resources, the relevant share for the usage of such resources. If for a project the value is not specified, the value set for the attribute default_share in the FairShareManager section is used
default_TTL
Specifies the default maximum Time to Live for a Virtual Machine/container, in minutes (default: 2880)
TTLs
For each project, specifies the maximum Time to Live for a Virtual Machine/container, in minutes. VMs and containers running for more that this value will be killed by Synergy. If for a certain project the value is not specified, the value specified by the default_TTL attribute will be used
backfill_depth
The integer value expresses the max depth used by the backfilling strategy: this allows Synergy to not check the whole queue when looking for VMs to start (default: 100)
notification_topic
The notification topic used by Nova for informing listeners about the state changes of the VMs. In case some other service (e.g. Ceilometer) is listening on the default Nova topic (i.e. "notifications"), please define a new topic specific for Synergy (e.g. notification_topics = notifications,synergy_notifications)
Section [FairShareManager]
Attribute
Description
autostart
Specifies if the FairShare manager should be started when Synergy starts
rate
The time (in minutes) between two executions of the task implementing this manager
period_length
The time window considered for resource usage by the fair-share algorithm used by Synergy is split in periods having all the same length, and the most recent periods are given a higher weight. This attribute specifies the length, in days, of a single period (default: 7)
periods
The time window considered for resource usage by the fairshare algoritm used by Synergy is split in periods having all the same length, and the most recent periods are given a higher weight. This attribue specifies the number of periods to be considered (default: 3)
default_share
Specifies the default to be used for a project, if not specified in the shares attribute of the SchedulerManager section (default: 10)
decay_weight
Value between 0 and 1, used by the fairshare scheduler, to define how oldest periods should be given a less weight wrt resource usage (default: 0.5)
vcpus_weight
The weight to be used for the attribute concerning vcpus usage in the fairshare algorithm used by Synergy (default: 100)
age_weight
This attribute defines how oldest requests (and therefore with low priority) should have their priority increased so thay cam be eventaully served (default: 10)
memory_weight
The weight to be used for the attribute concerning memory usage in the fairshare algorithm used by Synergy (default: 70)
Section [KeystoneManager]
Attribute
Description
autostart
Specifies if the Keystone manager should be started when Synergy starts
rate
The time (in minutes) between two executions of the task implementing this manage
auth_url
The URL of the OpenStack identity service. Please note that the v3 API endpoint must be used
username
The name of the user with admin role
password
The password of the specified user with admin role
project_id
The project id to request authorization on
project_name
The project name to request authorization on
user_domain_name
The user domain name (default: "default")
project_domain_name
The project domain name (default: "default")
timeout
The http connection timeout (default: 60)
clock_skew
Forces the request for token, a delta time before the token expiration (default: 60 sec)
Section [NovaManager]
Attribute
Description
autostart
Specifies if the nova manager should be started when Synergy starts
rate
The time (in minutes) between two executions of the task implementing this manager
host
The hostname where the nova-conductor service runs (default: localhost)
timeout
The http connection timeout (default: 60)
amqp_backend
The AMQP backend tpye (rabbit or qpid)
amqp_hosts
The AMQP HA cluster host:port pairs
amqp_host
The server where the AMQP service runs (default: localhost)
amqp_port
The port used by the AMQP service
amqp_user
The AMQP userid
amqp_password
The password of the AMQP user
amqp_virtual_host
The AMQP virtual host
synergy_topic
The topic on which Nova API communicates with Synergy. It must have the same value of the topic defined in nova- api.conf file (default: synergy)
conductor_topic
The topic on which conductor nodes listen on (default: conductor)
compute_topic
The topic on which compute nodes listen on (default: compute)
scheduler_topic
The topic on which scheduler nodes listen on (default: scheduler)
cpu_allocation_ratio
The Nova CPU allocation ratio (default: 16)
ram_allocation_ratio
The Nova RAM allocation ratio (default: 1.5)
metadata_proxy_shared_secret
The Nova metadata_proxy_shared_secret
db_connection
The SQLAlchemy connection string to use to connect to the Nova database
Section [QueueManager]
Attribute
Description
autostart
Specifies if the Queue manager should be started when Synergy starts
rate
The time (in minutes) between two executions of the task implementing this manager
db_connection
The SQLAlchemy connection string to use to connect to the Synergy database
db_pool_size
The number of SQL connections to be kept open (default: 10)
db_pool_recycle
The number of seconds after which a connection is automatically recycled (default: 30)
db_max_overflow
The max overflow with SQLAlchemy (default: 5)
Section [QuotaManager]
Attribute
Description
autostart
Specifies if the Quota manager should be started when Synergy starts
rate
The time (in minutes) between two executions of the task implementing this manager

Installation and configuration using puppet

We provide a Puppet module for Synergy so users can install and configure Synergy with Puppet. The module provides both the synergy-service and synergy-scheduler-manager components.
The module is available on the Puppet Forge : vll/synergy.
Install the puppet module with:
1
puppet module install vll-synergy
Copied!
Usage example:
1
class { 'synergy':
2
synergy_db_url => 'mysql://synergy:[email protected]/synergy',
3
synergy_project_shares => {'A' => 70, 'B' => 30 },
4
keystone_url => 'https://example.com',
5
keystone_admin_user => 'admin',
6
keystone_admin_password => 'the keystone password',
7
nova_url => 'https://example.com',
8
nova_db_url => 'mysql://nova:[email protected]/nova',
9
amqp_backend => 'rabbit',
10
amqp_host => 'localhost',
11
amqp_port => 5672,
12
amqp_user => 'openstack',
13
amqp_password => 'the amqp password',
14
amqp_virtual_host => '/',
15
}
Copied!

The Synergy command line interface

The Synergy service provides a command-line client, called synergy, which allows the Cloud administrator to control and monitor the Synergy service.
Before running the Synergy client command, you must create and source the admin-openrc.sh file to set the relevant environment variables. This is the same script used to run the OpenStack command line tools.
Note that the OS_AUTH_URL variables must refer to the v3 version of the keystone API, e.g.:
export OS_AUTH_URL=https://cloud-areapd.pd.infn.it:35357/v3

synergy usage

1
usage: synergy [-h] [--version] [--debug] [--os-username <auth-user-name>]
2
[--os-password <auth-password>]
3
[--os-user-domain-id <auth-user-domain-id>]
4
[--os-user-domain-name <auth-user-domain-name>]
5
[--os-project-name <auth-project-name>]
6
[--os-project-id <auth-project-id>]
7
[--os-project-domain-id <auth-project-domain-id>]
8
[--os-project-domain-name <auth-project-domain-name>]
9
[--os-auth-url <auth-url>] [--os-auth-system <auth-system>]
10
[--bypass-url <bypass-url>] [--os-cacert <ca-certificate>]
11
{manager,queue,quota,usage} ...
12
13
positional arguments:
14
{manager,queue,quota,usage}
15
commands
16
17
optional arguments:
18
-h, --help show this help message and exit
19
--version show program's version number and exit
20
--debug print debugging output
21
--os-username <auth-user-name>
22
defaults to env[OS_USERNAME]
23
--os-password <auth-password>
24
defaults to env[OS_PASSWORD]
25
--os-user-domain-id <auth-user-domain-id>
26
defaults to env[OS_USER_DOMAIN_ID]
27
--os-user-domain-name <auth-user-domain-name>
28
defaults to env[OS_USER_DOMAIN_NAME]
29
--os-project-name <auth-project-name>
30
defaults to env[OS_PROJECT_NAME]
31
--os-project-id <auth-project-id>
32
defaults to env[OS_PROJECT_ID]
33
--os-project-domain-id <auth-project-domain-id>
34
defaults to env[OS_PROJECT_DOMAIN_ID]
35
--os-project-domain-name <auth-project-domain-name>
36
defaults to env[OS_PROJECT_DOMAIN_NAME]
37
--os-auth-url <auth-url>
38
defaults to env[OS_AUTH_URL]
39
--os-auth-system <auth-system>
40
defaults to env[OS_AUTH_SYSTEM]
41
--bypass-url <bypass-url>
42
use this API endpoint instead of the Service Catalog
43
--os-cacert <ca-certificate>
44
Specify a CA bundle file to use in verifying a TLS
45
(https) server certificate. Defaults to env[OS_CACERT]
46
47
Command-line interface to the OpenStack Synergy API.
Copied!
The synergy optional arguments:
-h, --help
1
Show help message and exit
Copied!
--version
1
Show program’s version number and exit
Copied!
--debug
1
Show debugging information
Copied!
--os-username <auth-user-name>
1
Username to login with. Defaults to env[OS_USERNAME]
Copied!
--os-password <auth-password>
1
Password to use.Defaults to env[OS_PASSWORD]
Copied!
--os-project-name <auth-project-name>
1
Project name to scope to. Defaults to env:[OS_PROJECT_NAME]
Copied!
--os-project-id <auth-project-id>
1
Id of the project to scope to. Defaults to env[OS_PROJECT_ID]
Copied!
--os-project-domain-id <auth-project-domain-id>
1
Specify the project domain id. Defaults to env[OS_PROJECT_DOMAIN_ID]
Copied!
--os-project-domain-name <auth-project-domain-name>
1
Specify the project domain name. Defaults to env[OS_PROJECT_DOMAIN_NAME]
Copied!
--os-user-domain-id <auth-user-domain-id>
1
Specify the user domain id. Defaults to env[OS_USER_DOMAIN_ID]
Copied!
--os-user-domain-name <auth-user-domain-name>
1
Specify the user domain name. Defaults to env[OS_USER_DOMAIN_NAME]
Copied!
--os-auth-url <auth-url>
1
The URL of the Identity endpoint. Defaults to env[OS_AUTH_URL]
Copied!
--os-auth-system <auth-system>
1
The auth system to be used. Defaults to env[OS_AUTH_SYSTEM]
Copied!
--bypass-url <bypass-url>
1
Use this API endpoint instead of the Service Catalog
Copied!
--os-cacert <ca-bundle-file>
1
Specify a CA certificate bundle file to use in verifying a TLS
2
(https) server certificate. Defaults to env[OS_CACERT]
Copied!

synergy manager

This command allows to get information about the managers deployed in the Synergy service and control their execution:
1
# synergy manager -h
2
usage: synergy manager [-h] {list,status,start,stop} ...
3
4
positional arguments:
5
{list,status,start,stop}
6
list list the managers
7
status show the managers status
8
start start the manager
9
stop stop the manager
10
11
optional arguments:
12
-h, --help show this help message and exit
Copied!
The command synergy manager list provides the list of all managers deployed in the Synergy service:
1
# synergy manager list
2
╒══════════════════╕
3
│ manager │
4
╞══════════════════╡
5
│ QuotaManager │
6
├──────────────────┤
7
│ NovaManager │
8
├──────────────────┤
9
│ SchedulerManager │
10
├──────────────────┤
11
│ TimerManager │
12
├──────────────────┤
13
│ QueueManager │
14
├──────────────────┤
15
│ KeystoneManager │
16
├──────────────────┤
17
│ FairShareManager │
18
╘══════════════════╛
Copied!
To get the status about managers, use:
1
# synergy manager status
2
╒══════════════════╤══════════╤══════════════╕
3
│ manager │ status │ rate (min) │
4
╞══════════════════╪══════════╪══════════════╡
5
│ QuotaManager │ RUNNING │ 1 │
6
├──────────────────┼──────────┼──────────────┤
7
│ NovaManager │ RUNNING │ 1 │
8
├──────────────────┼──────────┼──────────────┤
9
│ SchedulerManager │ RUNNING │ 1 │
10
├──────────────────┼──────────┼──────────────┤
11
│ TimerManager │ ACTIVE │ 60 │
12
├──────────────────┼──────────┼──────────────┤
13
│ QueueManager │ RUNNING │ 10 │
14
├──────────────────┼──────────┼──────────────┤
15
│ KeystoneManager │ RUNNING │ 1 │
16
├──────────────────┼──────────┼──────────────┤
17
│ FairShareManager │ RUNNING │ 1 │
18
╘══════════════════╧══════════╧══════════════╛
19
20
# synergy manager status TimerManager
21
╒══════════════╤══════════╤══════════════╕
22
│ manager │ status │ rate (min) │
23
╞══════════════╪══════════╪══════════════╡
24
│ TimerManager │ ACTIVE │ 60 │
25
╘══════════════╧══════════╧══════════════╛
Copied!
To control the execution of a specific manager, use the start and stop sub-commands:
1
# synergy manager start TimerManager
2
╒══════════════╤════════════════════════════════╤══════════════╕
3
│ manager │ status │ rate (min) │
4
╞══════════════╪════════════════════════════════╪══════════════╡
5
│ TimerManager │ RUNNING (started successfully) │ 60 │
6
╘══════════════╧════════════════════════════════╧══════════════╛
7
8
# synergy manager stop TimerManager
9
╒══════════════╤═══════════════════════════════╤══════════════╕
10
│ manager │ status │ rate (min) │
11
╞══════════════╪═══════════════════════════════╪══════════════╡
12
│ TimerManager │ ACTIVE (stopped successfully) │ 60 │
13
╘══════════════╧═══════════════════════════════╧══════════════╛
Copied!

synergy quota

The overall cloud resources can be grouped in:
    private quota: composed of resources statically allocated and managed using the 'standard' OpenStack policies
    shared quota: composed of resources non statically allocated and fairly distributed among users by Synergy
The size of the shared quota is calculated as the difference between the total amount of cloud resources (considering also the over-commitment ratios) and the total resources allocated to the private quotas. Therefore for all projects it is necessary to specify the proper quota for instances, VCPUs and RAM so that their total is less than the total amount of cloud resources.
Since Synergy is installed, the private quota of projects cannot be managed anymore by using the Horizon dashboard, but only via command line tools using the following OpenStack command:
1
# openstack quota set --cores <num_vcpus> --ram <memory_size> --instances <max_num_instances> --class <project_id>
Copied!
The private quota will be updated from Synergy after a few minutes without restart it. This example shows how the private quota of the project _prj_a (id=_a5ccbaf2a9da407484de2af881198eb9) has been modified:
1
# synergy quota show --project_name prj_a
2
╒═══════════╤═══════════════════════════════════════════════╤═════════════════════════════════════════════════════════════════════════════╕
3
│ project │ private quota │ shared quota │
4
╞═══════════╪═══════════════════════════════════════════════╪═════════════════════════════════════════════════════════════════════════════╡
5
│ prj_a │ vcpus: 0.00 of 3.00 | memory: 0.00 of 1024.00 │ vcpus: 0.00 of 26.00 | memory: 0.00 of 59956.00 | share: 70.00% | TTL: 5.00 │
6
╘═══════════╧═══════════════════════════════════════════════╧═════════════════════════════════════════════════════════════════════════════╛
7
8
# openstack quota set --cores 2 --ram 2048 --instances 10 --class a5ccbaf2a9da407484de2af881198eb9
9
10
# synergy quota show --project_name prj_a
11
╒═══════════╤═══════════════════════════════════════════════╤═════════════════════════════════════════════════════════════════════════════╕
12
│ project │ private quota │ shared quota │
13
╞═══════════╪═══════════════════════════════════════════════╪═════════════════════════════════════════════════════════════════════════════╡
14
│ prj_a │ vcpus: 0.00 of 2.00 | memory: 0.00 of 2048.00 │ vcpus: 0.00 of 27.00 | memory: 0.00 of 58932.00 | share: 70.00% | TTL: 5.00 │
15
╘═══════════╧═══════════════════════════════════════════════╧═════════════════════════════════════════════════════════════════════════════╛
Copied!
To get information about the private and shared quotas you must use the synergy quota command :
1
# synergy quota -h
2
usage: synergy quota [-h] {show} ...
3
4
positional arguments:
5
{show}
6
show shows the quota info
7
8
optional arguments:
9
-h, --help show this help message and exit
10
11
# synergy quota show -h
12
usage: synergy quota show [-h] [-i <id> | -n <name> | -a | -s]
13
14
optional arguments:
15
-h, --help show this help message and exit
16
-i <id>, --project_id <id>
17
-n <name>, --project_name <name>
18
-a, --all_projects
19
-s, --shared
Copied!
To get the status about the shared quota, use the option --shared:
1
# synergy quota show --shared
2
╒════════════╤════════╤════════╕
3
│ resource │ used │ size │
4
╞════════════╪════════╪════════╡
5
│ vcpus │ 2 │ 27 │
6
├────────────┼────────┼────────┤
7
│ memory │ 1024 │ 60980 │
8
├────────────┼────────┼────────┤
9
│ instances │ 1 │ -1 │
10
╘════════════╧════════╧════════╛
Copied!
in this example the total amount of VCPUs allocated to the shared quota is 27 whereof have been used just 2 CPUs (similarly to the memory and instances number). The value -1 means that the Cloud administrator has not fixed the limit of the number of instances (i.e. VMs), so in this example the VMs can be unlimited.
The --all_projects option provides information about the private and shared quotas of all projects:
1
# synergy quota show --all_projects
2
╒═══════════╤════════════════════════════════════════════════╤═══════════════════════════════════════════════════════════════════════════════╕
3
│ project │ private quota │ shared quota │
4
╞═══════════╪════════════════════════════════════════════════╪═══════════════════════════════════════════════════════════════════════════════╡
5
│ prj_b │ vcpus: 1.00 of 3.00 | memory: 512.0 of 1536.00 │ vcpus: 0.00 of 27.00 | memory: 0.00 of 60980.00 | share: 30.00% | TTL: 5.00 │
6
├───────────┼────────────────────────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
7
│ prj_a │ vcpus: 0.00 of 1.00 | memory: 0.00 of 512.00 │ vcpus: 2.00 of 27.00 | memory: 1024.0 of 60980.00 | share: 70.00% | TTL: 5.00 │
8
╘═══════════╧════════════════════════════════════════════════╧═══════════════════════════════════════════════════════════════════════════════╛
9
10
# synergy quota show --project_name prj_a
11
╒═══════════╤══════════════════════════════════════════════╤═══════════════════════════════════════════════════════════════════════════════╕
12
│ project │ private quota │ shared quota │
13
╞═══════════╪══════════════════════════════════════════════╪═══════════════════════════════════════════════════════════════════════════════╡
14
│ prj_a │ vcpus: 0.00 of 1.00 | memory: 0.00 of 512.00 │ vcpus: 2.00 of 27.00 | memory: 1024.0 of 60980.00 | share: 70.00% | TTL: 5.00 │
15
╘═══════════╧══════════════════════════════════════════════╧═══════════════════════════════════════════════════════════════════════════════╛
Copied!
In this example the project prj_b is currently consuming just resources of its private quota (1 VCPU and 512MB of memory) while the shared quota is not used. By contrary, the prj_a is consuming just the shared quota (2 VCPUs and 1024MB of memory). The share values fixed by the Cloud administrator are 70% for prj_a and 30% prj_b (the attribute shares in synergy.conf) while for both projects the TTL has been set to 5 minutes (the TTL attribute). Remark, in this example, the VMs instantiated in the shared quota can live just 5 minutes while the ones created in the private quota can live forever.

synergy queue

This command provides information about the amount of user requests stored in the persistent priority queue:
1
# synergy queue -h
2
usage: synergy queue [-h] {show} ...
3
4
positional arguments:
5
{show}
6
show shows the queue info
7
8
optional arguments:
9
-h, --help show this help message and exit
10
11
# synergy queue show
12
╒═════════╤════════╤═══════════╕
13
│ name │ size │ is open │
14
╞═════════╪════════╪═══════════╡
15
│ DYNAMIC │ 544 │ true │
16
╘═════════╧════════╧═══════════╛
Copied!

synergy usage

To get information about the usage of shared resources at project or user level, use:
1
# synergy usage show -h
2
usage: synergy usage show [-h] {project,user} ...
3
4
positional arguments:
5
{project,user}
6
project project help
7
user user help
8
9
optional arguments:
10
-h, --help show this help message and exit
11
12
13
# synergy usage show project -h
14
usage: synergy usage show project [-h] [-d <id> | -m <name> | -a]
15
16
optional arguments:
17
-h, --help show this help message and exit
18
-d <id>, --project_id <id>
19
-m <name>, --project_name <name>
20
-a, --all_projects
21
22
23
# synergy usage show user -h
24
usage: synergy usage show user [-h] (-d <id> | -m <name>)
25
(-i <id> | -n <name> | -a)
26
27
optional arguments:
28
-h, --help show this help message and exit
29
-d <id>, --project_id <id>
30
-m <name>, --project_name <name>
31
-i <id>, --user_id <id>
32
-n <name>, --user_name <name>
33
-a, --all_users
Copied!
The project sub-command provides the resource usage information by the projects.
The following example shows the projects prj_a (share: 70%) and prj_b (share: 30%) have consumed in the last three days, respectively 70.40% and 29.40% of shared resources:
1
# synergy usage show project --all_projects
2
╒═══════════╤═══════════════════════════════════════════════════════════════╤═════════╕
3
│ project │ shared quota (09 Dec 2016 14:35:43 - 12 Dec 2016 14:35:43) │ share │
4
╞═══════════╪═══════════════════════════════════════════════════════════════╪═════════╡
5
│ prj_b │ vcpus: 29.60% | memory: 29.60% │ 30.00% │
6
├───────────┼───────────────────────────────────────────────────────────────┼─────────┤
7
│ prj_a │ vcpus: 70.40% | memory: 70.40% │ 70.00% │
8
╘═══════════╧═══════════════════════════════════════════════════════════════╧═════════╛
9
10
# synergy usage show project --project_name prj_a
11
╒═══════════╤══════════════════════════════════════════════════════════════╤═════════╕
12
│ project │ shared quota (09 Dec 2016 15:01:44 - 12 Dec 2016 15:01:44) │ share │
13
╞═══════════╪══════════════════════════════════════════════════════════════╪═════════╡
14
│ prj_a │ vcpus: 70.40% | memory: 70.40% │ 70.00% │
15
╘═══════════╧══════════════════════════════════════════════════════════════╧═════════╛
Copied!
The time window is defined by Cloud administrator by setting the attributes period and period_length in synergy.conf.
It may happen that the prj_a (or prj_b) doesn't have the need to consume shared resources for a while: in this scenario the others projects (i.e. prj_b) can take advantage and so consume more resources than the fixed share (i.e. 30%):
1
# synergy usage show project --all_projects
2
╒═══════════╤═══════════════════════════════════════════════════════════════╤═════════╕
3
│ project │ shared quota (09 Dec 2016 14:35:43 - 12 Dec 2016 14:35:43) │ share │
4
╞═══════════╪═══════════════════════════════════════════════════════════════╪═════════╡
5
│ prj_b │ vcpus: 98.40% | memory: 98.40% │ 30.00% │
6
├───────────┼───────────────────────────────────────────────────────────────┼─────────┤
7
│ prj_a │ vcpus: 1.60% | memory: 1.60% │ 70.00% │
8
╘═══════════╧═══════════════════════════════════════════════════════════════╧═════════╛
Copied!
However, as soon as the prj_a requires more shared resources, it will gain a higher priority than the prj_b, in order to balance their usage.
The user sub-command provides the resource usage information by the project users.
The following example shows the usage report of users belonging to the project prj_a. They have the same value for share (35%) but different priority (user_a1=80, user_a2=100) because the user_a1 has consumed too much with respect to user_a2 (51.90% VS 48.10%).
1
# synergy usage show user --project_name prj_a --all_users
2
╒═════════╤══════════════════════════════════════════════════════════════╤═════════╤════════════╕
3
│ user │ shared quota (09 Dec 2016 14:58:44 - 12 Dec 2016 14:58:44) │ share │ priority │
4
╞═════════╪══════════════════════════════════════════════════════════════╪═════════╪════════════╡
5
│ user_a2 │ vcpus: 48.10% | memory: 48.10% │ 35.00% │ 100 │
6
├─────────┼──────────────────────────────────────────────────────────────┼─────────┼────────────┤
7
│ user_a1 │ vcpus: 51.90% | memory: 51.90% │ 35.00% │ 80 │
8
╘═════════╧══════════════════════════════════════════════════════════════╧═════════╧════════════╛
9
10
# synergy usage show user --project_name prj_a --user_name user_a1
11
╒═════════╤══════════════════════════════════════════════════════════════╤═════════╤════════════╕
12
│ user │ shared quota (09 Dec 2016 14:58:44 - 12 Dec 2016 14:58:44) │ share │ priority │
13
╞═════════╪══════════════════════════════════════════════════════════════╪═════════╪════════════╡
14
│ user_a1 │ vcpus: 51.90% | memory: 51.90% │ 35.00% │ 80 │
15
╘═════════╧══════════════════════════════════════════════════════════════╧═════════╧════════════╛
Copied!

Open Ports

To interact with Synergy using the client tool, just one port needs to be open. This is the port defined in the Synergy configuration file (attribute port in the [WSGI] section). The default value is 8051.
Last modified 3yr ago