OpenNebula Sunstone: Advanced Deployments 4.2
Low to medium enterprise clouds will typically deploy Sunstone in a single machine a long with the OpenNebula daemons. However this simple deployment can be improved by:
By default the Sunstone server is configured to run in the frontend, but you are able to install the Sunstone server in a machine different from the frontend.
install.sh
script.:one_xmlprc:
variable in sunstone-server.conf
points to the right place where OpenNebula frontend is running, You can also leave it undefined and export ONE_XMLRPC
environment variable./var/lib/one/.one/sunstone_auth
. If you changed the serveradmin password please check the following section<xterm> $ cat /var/lib/one/.one/sunstone_auth serveradmin:1612b78a4843647a4b541346f678f9e1b43bbcf9 </xterm>
Using this setup the VirtualMachine logs will not be available. If you need to retrieve this information you must deploy the server in the frontend
Self contained deployment of Sunstone (using sunstone-server
script) is ok for small to medium installations. This is no longer true when the service has lots of concurrent users and the number of objects in the system is high (for example, more than 2000 simultaneous virtual machines).
Sunstone server was modified to be able to run as a rack
server. This makes it suitable to run in any web server that supports this protocol. In ruby world this is the standard supported by most web servers. We now can select web servers that support spawning multiple processes like unicorn
or embedding the service inside apache
or nginx
web servers using the Passenger module. Another benefit will be the ability to run Sunstone in several servers and balance the load between them.
When using one on these web servers the use of a memcached
server is necessary. Sunstone needs to store user sessions so it does not ask for user/password for every action. By default Sunstone is configured to use memory sessions, that is, the sessions are stored in the process memory. Thin and webrick web servers do not spawn new processes but new threads an all of them have access to that session pool. When using more than one process to server Sunstone there must be a service that stores this information and can be accessed by all the processes. In this case we will need to install memcached
. It comes with most distributions and its default configuration should be ok. We will also need to install ruby libraries to be able to access it. The rubygem library needed is memcache-client
. If there is no package for your distribution with this ruby library you can install it using rubygems:
<xterm> $ sudo gem install memcache-client </xterm>
Then you will have to change in sunstone configuration (/etc/one/sunstone-server.conf
) the value of :sessions
to memcache
.
If you want to use novcn you need to have it running. You can start this service with the command:
<xterm> $ novnc-server start </xterm>
Another thing you have to take into account is the user on which the server will run. The installation sets the permissions for oneadmin
user and group and files like the Sunstone configuration and credentials can not be read by other users. Apache usually runs as www-data
user and group so to let the server run as this user the group of these files must be changed, for example:
<xterm> $ chgrp www-data /etc/one/sunstone-server.conf $ chgrp www-data /etc/one/sunstone-plugins.yaml $ chgrp www-data /var/lib/one/.one/sunstone_auth $ chmod a+x /var/lib/one $ chmod a+x /var/lib/one/.one $ chgrp www-data /var/log/one/sunstone* $ chmod g+w /var/log/one/sunstone* </xterm>
We advise to use Passenger in your installation but we will show you how to run Sunstone inside unicorn web server as an example.
For more information on web servers that support rack and more information about it you can check the rack documentation page. You can alternatively check a list of ruby web servers.
To get more information about this web server you can go to its web page. It is a multi process web server that spawns new processes to deal with requests.
The installation is done using rubygems (or with your package manager if it is available):
<xterm> $ sudo gem install unicorn </xterm>
In the directory where Sunstone files reside (/usr/lib/one/sunstone
or /usr/share/opennebula/sunstone
) there is a file called config.ru
. This file is specific for rack
applications and tells how to fun the application. To start a new server using unicorn
you can run this command from that directory:
<xterm> $ unicorn -p 9869 </xterm>
Default unicorn configuration should be ok for most installations but a configuration file can be created to tune it. For example, to tell unicorn to spawn 4 processes and write stderr
to /tmp/unicorn.log
we can create a file called unicorn.conf
that contains:
worker_processes 4 logger debug stderr_path '/tmp/unicorn.log'
and start the server and daemonize it using:
<xterm> $ unicorn -d -p 9869 -c unicorn.conf </xterm>
You can find more information about the configuration options in the unicorn documentation.
Phusion Passenger is a module for Apache and Nginx web servers that runs ruby rack applications. This can be used to run Sunstone server and will manage all its life cycle. If you are already using one of these servers or just feel comfortable with one of them we encourage you to use this method. This kind of deployment adds better concurrency and lets us add an https endpoint.
We will provide the instructions for Apache web server but the steps will be similar for nginx following Passenger documentation.
First thing you have to do is install Phusion Passenger. For this you can use pre-made packages for your distribution or follow the installation instructions from their web page. The installation is self explanatory and will guide you in all the process, follow them an you will be ready to run Sunstone.
Next thing we have to do is configure the virtual host that will run our Sunstone server. We have to point to the public
directory from the Sunstone installation, here is an example:
<VirtualHost *:80> ServerName sunstone-server # !!! Be sure to point DocumentRoot to 'public'! DocumentRoot /usr/lib/one/sunstone/public <Directory /usr/lib/one/sunstone/publicc> # This relaxes Apache security settings. AllowOverride all # MultiViews must be turned off. Options -MultiViews </Directory> </VirtualHost>
Make sure you change the directory to /usr/share/opennebula/sunstone/public
if you are using Debian or Ubuntu.
Now the configuration should be ready, restart of reload apache configuration to start the application and point to the virtual host to check if everything is running.
You can run Sunstone in several servers and use a load balancer that connects to them. Make sure you are using memcache
for sessions and both Sunstone servers connect to the same memcached
server. To do this change the parameter :memcache_host
in the configuration file. Also make sure that both Sunstone instances connect to the same OpenNebula server.