Skip to content

Commit

Permalink
F OpenNebula/one#6430: large-scale and HA (#2976)
Browse files Browse the repository at this point in the history
  • Loading branch information
jloboescalona2 authored Jul 12, 2024
1 parent 208176c commit 715291e
Show file tree
Hide file tree
Showing 14 changed files with 264 additions and 30 deletions.
25 changes: 15 additions & 10 deletions source/installation_and_configuration/ha/frontend_ha.rst
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,6 @@ Every HA cluster requires:

The servers should be configured in the following way:

* Sunstone (with or without Apache/Passenger) running on all the nodes.
* Shared datastores must be mounted on all the nodes.

Bootstrapping the HA cluster
Expand Down Expand Up @@ -351,16 +350,16 @@ OpenNebula stores virtual machine logs inside ``/var/log/one/`` as files named `
Optionally, if you are planning to use the FireEdge OneProvision GUI, in order to have all provision logs available in all HA nodes (hence, available on leader change), all nodes need to share the same ``/var/lib/one/fireedge`` folder.


Sunstone and FireEdge
FireEdge
================================================================================

There are several types of Sunstone deployments in an HA environment. The basic one is Sunstone running on each OpenNebula Front-end node configured with the local OpenNebula. Only one server, the *leader* with floating IP, is used by the clients.
There are several types of FireEdge deployments in an HA environment. The basic one is FireEdge running on **each OpenNebula Front-end node** configured with the local OpenNebula. Only one server, the *leader* with floating IP, is used by the clients.

It is possible to configure a load balancer (e.g. HAProxy, Pound, Apache, or Nginx) over the Front-ends to spread the load (read operations) among the nodes. In this case, the **Memcached** and shared ``/var/tmp/`` may be required. Please see :ref:`Configuring Sunstone for Large Deployments <suns_advance>`.
It is possible to configure a load balancer (e.g. HAProxy, Pound, Apache, or Nginx) over the Front-ends to spread the load (read operations) among the nodes.

To easily scale out beyond the total number of core OpenNebula daemons, Sunstone can be running on separate machines. They should talk to the cluster floating IP (see ``:one_xmlprc:`` in ``sunstone-server.conf``) and may also require **Memcached** and shared ``/var/tmp/`` between Sunstone and Front-end nodes. Please check :ref:`Configuring Sunstone for Large Deployments <suns_advance>`.
To easily scale out beyond the total number of core OpenNebula daemons, FireEdge can be running on separate machines. They should talk to the cluster floating IP (see ``:one_xmlprc:`` in ``fireedge-server.conf``) and shared ``/var/tmp/`` between Fireedge and Front-end nodes. Please check :ref:`Configuring FireEdge for Large Deployments <fireedge_advance>`.

FireEdge and Sunstone need to share the same ``/var/lib/one/.one/fireedge_key``. This is covered by the above procedure. Additionally, to have all provision logs available in all HA nodes (hence, available on leader change), all nodes need to share the same ``/var/lib/one/fireedge`` folder.
FireEdge need to share the same ``/var/lib/one/.one/fireedge_key``. This is covered by the above procedure. Additionally, to have all provision logs available in all HA nodes (hence, available on leader change), all nodes need to share the same ``/var/lib/one/fireedge`` folder.

Raft Configuration Attributes
================================================================================
Expand Down Expand Up @@ -416,17 +415,14 @@ Individual files:
- ``/etc/one/oneflow-server.conf``
- ``/etc/one/onegate-server.conf``
- ``/etc/one/sched.conf``
- ``/etc/one/sunstone-logos.yaml``
- ``/etc/one/sunstone-server.conf``
- ``/etc/one/vcenter_driver.default``

Folders:

- ``/etc/one/sunstone-views``
- ``/etc/one/fireedge``
- ``/etc/one/auth``
- ``/etc/one/ec2query_templates``
- ``/etc/one/hm``
- ``/etc/one/sunstone-views``
- ``/etc/one/vmm_exec``

.. note:: Any file inside previous folders that doesn't exist on the remote server (like backups) will **not** be removed.
Expand All @@ -441,3 +437,12 @@ Usage
# onezone serversync <remote_opennebula_server> [--db]

where ``<remote_opennebula_server>`` needs to be replaced by a hostname/IP of the OpenNebula server that will be used to fetch configuration files from. If ``--db`` option is used, the local database will be synced with the one located on remote server.

You also have to adjust the configuration file of each FireEdge ``/etc/one/fireedge-server.conf``, to know which FireEdge corresponds to which zone.

.. code::
default_zone:
id: 0
name: 'OpenNebula'
endpoint: 'http://localhost:2633/RPC2'
Original file line number Diff line number Diff line change
@@ -0,0 +1,228 @@
.. _fireedge_advance:

==============================
FireEdge for Large Deployments
==============================

Low to medium size enterprise clouds will typically deploy FireEdge on a single machine with the other OpenNebula daemons as part. However, this simple deployment can be extended by

- **Improving scalability** of the server for large user pools, usually by deploying FireEdge as a separate application on one or more hosts.

This guide introduces various deployment options to achieve this. Check also the :ref:`API Scalability <one_scalability_api_tuning>` guide for tips on how to improve FireEdge and OpenNebula Daemon performance.

.. _fireedge_large_web:

Deploy in Webserver
===================

Self-contained deployment of :ref:`FireEdge <fireedge_sunstone>`. (using ``opennebula-fireedge`` system service) is sufficient for small to medium installations. This is no longer enough 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).

The FireEdge server is implemented as a nodejs server. This makes it suitable to run on any server. Also, embed the service inside Apache HTTP Server or NGINX. Another advantage is the ability to run FireEdge on multiple servers and balance the load between them.

**Guacamole**

If you want to use Guacamole you need to have it running. You can start this service with the command:

.. prompt:: bash # auto

# systemctl enable opennebula-guacd
# systemctl start opennebula-guacd

.. _fireedge_fs_permissions:

**Filesystem Permissions**

Another thing you have to take into account is the user under which the server will run. The installation sets the permissions for the ``oneadmin`` user and group, and files like the FireEdge configuration and credentials cannot be read by other users.

.. prompt:: bash # auto

# chmod a+x /var
# chmod a+x /var/lib
# chmod a+x /var/lib/one
# chmod a+x /var/lib/one/.one

.. _fireedge_advance_apache_proxy:

Non-TLS Configuration
^^^^^^^^^^^^^^^^^^^^^
If FireEdge is installed and you want to place an apache to forward traffic to fireedge you can inside ``VirtualHost``, insert the following snippet and **adjust** it to your current configuration.

**Apache**

.. code-block:: bash
<VirtualHost *:80>
...
ProxyRequests off
ProxyPreserveHost on
# no proxy for /error/ (Apache HTTPd errors messages)
ProxyPass /error/ !
ProxyPass /fireedge http://localhost:2616/fireedge
ProxyPassReverse /fireedge http://localhost:2616/fireedge
RewriteEngine on
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteCond %{HTTP:Connection} upgrade [NC]
RewriteRule ^/fireedge/?(.*) "ws://localhost:2616/fireedge/$1" [P,L]
<Location /fireedge>
Order deny,allow
Allow from all
</Location>
</VirtualHost>
.. note::

As you can see in the configuration inside the **location** is in ``/fireedge`` that means that it is a path of your domain ``<YOUR_DOMAIN>/fireedge``. If you want the fireedge to be in the root you must change it to ``/``

**NGINX**

You will need to configure a new virtual host in NGINX. Depending on the operating system and the method of installation, NGINX loads virtual host configurations from either ``/etc/nginx/conf.d`` or ``/etc/nginx/sites-enabled``.

- A sample ``cloudserver.org`` virtual host is presented next:

.. code-block:: bash
# No squealing.
server_tokens off;
#### OpenNebula FireEdge upstream
upstream fire-edge {
server 127.0.0.1:2616;
}
#### cloudserver.org HTTPS virtual host
server {
listen 80;
server_name cloudserver.org;
### Proxy requests to upstream
location /fireedge {
proxy_pass http://fire-edge/fireedge;
proxy_redirect off;
log_not_found off;
proxy_buffering off;
proxy_cache_bypass $http_upgrade
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-FOR $proxy_add_x_forwarded_for;
access_log off;
}
}
.. note::

As you can see in the configuration inside the **location** is in ``/fireedge`` that means that it is a path of your domain ``<YOUR_DOMAIN>/fireedge``. If you want the fireedge to be in the root you must change it to ``/``


.. _fireedge_advance_apache_tls_proxy:

TLS-secured Configuration
^^^^^^^^^^^^^^^^^^^^^^^^^

We must create the Virtual Host that will run our FireEdge. Here is an example:

**Apache**

.. code::
<VirtualHost *:443>
ServerName one.example.com
SSLEngine on
SSLCertificateKeyFile /etc/ssl/private/opennebula-key.pem
SSLCertificateFile /etc/ssl/certs/opennebula-certchain.pem
SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder On
SSLCompression off
Header always set Strict-Transport-Security "max-age=15768000"
SSLCipherSuite 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'
RequestHeader set X-Forwarded-Proto "https"
ProxyRequests off
ProxyPreserveHost on
# no proxy for /error/ (Apache HTTPd errors messages)
ProxyPass /error/ !
ProxyPass /fireedge http://localhost:2616/fireedge
ProxyPassReverse /fireedge http://localhost:2616/fireedge
RewriteEngine on
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteCond %{HTTP:Connection} upgrade [NC]
RewriteRule ^/fireedge/?(.*) "ws://localhost:2616/fireedge/$1" [P,L]
<Location /fireedge>
Order deny,allow
Allow from all
</Location>
</VirtualHost>
Now the configuration should be ready. Restart or reload the Apache configuration to start the application and point to the virtual host to check that everything is running.

.. note::

As you can see in the configuration inside the **location**, **ProxyPass** and **ProxyPassReverse** is in ``/fireedge`` that means it is a path of your domain ``<YOUR_DOMAIN>/fireedge``. If you want the fireedge to be in the root you must change it to ``/``.

**NGINX**

You will need to configure a new virtual host in NGINX. Depending on the operating system and the method of installation, NGINX loads virtual host configurations from either ``/etc/nginx/conf.d`` or ``/etc/nginx/sites-enabled``.

.. code-block:: bash
# No squealing.
server_tokens off;
#### OpenNebula FireEdge upstream
upstream fire-edge {
server 127.0.0.1:2616;
}
#### cloudserver.org HTTP virtual host
server {
listen 80;
server_name cloudserver.org;
### Permanent redirect to HTTPS (optional)
return 301 https://$server_name:8443;
}
#### cloudserver.org HTTPS virtual host
server {
listen 8443;
server_name cloudserver.org;
### SSL Parameters
ssl on;
ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem;
ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;
location /fireedge {
proxy_pass http://fire-edge/fireedge;
proxy_redirect off;
log_not_found off;
proxy_buffering off;
proxy_cache_bypass $http_upgrade
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-FOR $proxy_add_x_forwarded_for;
access_log off;
}
}
.. note::

As you can see in the configuration inside the **location** is in ``/fireedge`` that means that it is a path of your domain ``<YOUR_DOMAIN>/fireedge``. If you want the fireedge to be in the root you must change it to ``/``
Original file line number Diff line number Diff line change
Expand Up @@ -9,5 +9,5 @@ Large-scale Deployment

Overview <overview>
Scalability Testing and Tuning <scalability>
Sunstone for Large Deployments <sunstone_for_large_deployments>
FireEdge for Large Deployments <fireedge_for_large_deployments>
Advanced SSH Usage <advanced_ssh_usage>
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ This chapter describes the performance capabilities of various OpenNebula compon
How Should I Read This Chapter
================================================================================

Read the :ref:`Scalability Testing and Tuning <one_scalability>` to understand the performance capabilities of OpenNebula and ways to improve performance by following test scenarios. Move on to the :ref:`Sunstone for Large Deployment <suns_advance>` to learn how to achieve a better performance and security by running Sunstone GUI within a web server or behind HTTP(S) proxy. After this, you can get familiar with how OpenNebula deals with SSH and how to streamline the SSH configuration in :ref:`Advanced SSH Usage <node_ssh>`.
Read the :ref:`Scalability Testing and Tuning <one_scalability>` to understand the performance capabilities of OpenNebula and ways to improve performance by following test scenarios. Move on to the :ref:`Sunstone for Large Deployment <fireedge_advance>` to learn how to achieve a better performance and security by running Sunstone GUI within a web server or behind HTTP(S) proxy. After this, you can get familiar with how OpenNebula deals with SSH and how to streamline the SSH configuration in :ref:`Advanced SSH Usage <node_ssh>`.

Hypervisor Compatibility
================================================================================
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -279,7 +279,7 @@ To connect to the cluster from another server you can use one of the two followi
export ONE_XMLRPC=http://ENDPOINT_IP:2633/RPC2
- Using Sunstone: Modify ``one_xmlrpc`` in :ref:`/etc/one/sunstone-server.conf <sunstone_sunstone_server_conf>`
- Using FireEdge: Modify ``one_xmlrpc`` in :ref:`/etc/one/fireedge-server.conf <fireedge_configuration>`

The new endpoint will be the load balancer address.

Expand All @@ -295,10 +295,10 @@ For non-test installations use a MySQL/MariaDB database. SQLite is too slow for

Be sure to review the :ref:`recommended maintenance procedures <mysql_maintenance>` for the MySQL database backend.

Sunstone Tuning
FireEdge Tuning
---------------------------

Please refer to the guide on :ref:`Configuring Sunstone for Large Deployments <suns_advance>`.
Please refer to the guide on :ref:`Configuring FireEdge for Large Deployments <fireedge_advance>`.


.. |scala| image:: /images/one_scalability.jpg
1 change: 1 addition & 0 deletions source/legacy_components/ruby_sunstone/index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -14,3 +14,4 @@ Ruby Sunstone
Sunstone views <ruby_sunstone_views>
Cloud view <ruby_sunstone_cloud_view>
Sunstone Authentication <ruby_sunstone_authentication>
Sunstone for Large Deployments <sunstone_for_large_deployments>
2 changes: 1 addition & 1 deletion source/legacy_components/ruby_sunstone/sunstone.rst
Original file line number Diff line number Diff line change
Expand Up @@ -440,7 +440,7 @@ Different Endpoint for Different View

OpenNebula :ref:`Sunstone Views <ruby_sunstone_views>` can be adapted to use a different endpoint for
each kind of user, such as if you want one endpoint for the admins and a different one for the
cloud users. You just have to deploy a :ref:`new sunstone server <suns_advance>` and set a default
cloud users. You just have to deploy a :ref:`new sunstone server <sunstone_advance>` and set a default
view for each sunstone instance:

.. code::
Expand Down
Loading

0 comments on commit 715291e

Please sign in to comment.