This section describes how to upgrade from Abiquo 4.7.0 or above to the current Abiquo version. Please contact Abiquo Support for further information.
Major upgrade
The upgrade to Abiquo 5.2.0 is a major upgrade with upgrades of third-party software packages that are critical platform dependencies
You must make snapshots of ALL servers before you start the upgrade
- Abiquo YUM repositories are no longer open, please contact Abiquo Support to obtain your credentials
- This upgrade process starts from Abiquo 4.7 or above. To upgrade from earlier versions, please contact Abiquo Support
1. Prepare branding
- If you are upgrading from Abiquo 4.7.x, the new UI in Abiquo 5.0 requires new branding. See Abiquo branding guide
2. Prevent cloud users from performing VM operations
- In the UI in the Infrastructure view, select each physical machine and click Disable
- Using the API, set the state of each physical machine to DISABLED
3. Check for operations in progress on the platform
Before you shut down the platform servers you should check that no operations are in progress.
Before you shut down the platform servers you should check that no operations are in progress on the platform.
Check that the Abiquo RabbitMQ queues are empty on the Abiquo Monolithic Server, Abiquo Server or Datanode server
The number of messages in all queues must be 0.
# rabbitmqctl list_queues messages name
# rabbitmqctl list_queues messages name Listing queues ... 0 abiquo.am.notifications 0 abiquo.bpm.notifications 0 abiquo.datacenter.requests.ADatacenter.bpm 0 abiquo.datacenter.requests.ADatacenter.virtualfactory 0 abiquo.ha.tasks 0 abiquo.nodecollector.notifications 0 abiquo.pcrsync.messages 0 abiquo.pcrsync.parking-expect-no-consumers 0 abiquo.scheduler.fast.requests 0 abiquo.scheduler.requests 0 abiquo.scheduler.slow.requests 0 abiquo.tracer.traces 0 abiquo.virtualfactory.notifications 0 abiquo.virtualmachines.definitionsyncs 0 abiquo.vsm.eventsynk ...done.
On the V2V Server, check for any active conversions by checking for the V2V or Mechadora processes
$ ps aux | grep v2v $ ps aux | grep mechadora
When user VM operations are blocked and all of the above checks show that no tasks are running, it is safe to halt the platform.
4. Back up the main platform elements
To perform a basic backup of the platform, run the following backups:
Before you begin, stop platform services, and check you have enough space on your destination systems.
# On DB server, back up the Abiquo MySQL DBs mysqldump --routines --triggers kinton > kinton.sql-$(date +%Y%m%d_%H%M%S) mysqldump --routines --triggers kinton_accounting > kinton_accounting.sql-$(date +%Y%m%d_%H%M%S) # On the Monitoring server, back up Watchtower DB mysqldump --routines --triggers watchtower > watchtower.sql-$(date +%Y%m%d_%H%M%S) # On the Abiquo API Server or UI server, back up the UI tar cvfz /var/www/html/ui.tgz-$(date +%Y%m%d_%H%M%S) /var/www/html/ui # If you are using SAML authentication with multiple IdPs, on ALL Abiquo API Servers, back up this file cp /opt/abiquo/tomcat/webapps/api/WEB-INF/classes/springresources/security/saml/security-saml-generated-beans.xml /opt/abiquo/tomcat/webapps/api/WEB-INF/classes/springresources/security/saml/security-saml-generated-beans.xml-$(date +%Y%m%d_%H%M%S) # On ALL servers, back up the /opt/abiquo folder tar cvfz /opt/abiquo.tgz-$(date +%Y%m%d_%H%M%S) /opt/abiquo # On Abiquo Monolithic or API Server, Remote Services, or Datanode, back up Redis redis-cli save cp -a /var/lib/redis /var/lib/redis-$(date +%Y%m%d_%H%M%S)
If you are using HTTPS-SSL between your Tomcat servers, for each Tomcat server:
From the /opt/abiquo/tomcat/conf folder, back up the server.xml files. You will need to restore and modify them after the yum upgrade.
5. Disable old billing dashboards and delete last bills
In Abiquo 5.2, the billing dashboard feature is now in the core Abiquo platform.
If you are using the billing dashboard scripts from previous versions, disable them and delete last bills before you continue with the upgrade.
On the server where you were running the billing packages, remove the Cron jobs to run the billing scripts.
# rm /etc/cron.d/abiquo-billing-ec2 # rm /etc/cron.d/abiquo-billing-arm
Delete the last bills from the previous version of the billing dashboards (from the kinton.billing_consolidation and kinton.billing_register tables). Remove the bills for Azure and Amazon providers, for the number of months covered by the abiquo.enterprise.property.billing.monthoffset property, which has a default value of 2 months. Later the new billing dashboards feature will regenerate these bills.
6. Stopplatform services
This section describes how to stop platform services on all servers.
Before you begin, Check for operations in progress on the platform and wait for all operations to complete.
If there are operations in progress, DO NOT STOP the platform services because this can cause serious issues with your platform.
To stop platform services:
Stop the API on the API server or Monolithic server
systemctl stop abiquo-tomcat
Stop the UI on the API server or Monolithic server or dedicated UI server
systemctl stop httpd
Stop Remote services server
systemctl stop abiquo-tomcat
Stop the database on the Monolithic server or Database server or Datanode server.
systemctl stop mariadb
For a datanode configuration, you will also need to stop the Galera cluster. For more details, see Stop and start HA configuration
Stop RabbitMQ (on the monolithic server or API Server or Datanode)
systemctl stop rabbitmq-server
V2V server -
You do not need to stop anything because the BPM remote service is run on-demand onlyStop monitoring server
systemctl stop abiquo-delorean systemctl stop abiquo-emmett systemctl stop kairosdb systemctl stop cassandra
On the monitoring server, check if Cassandra is really dead
ps auwx | grep cassandra
Get the process number for Cassandra (the first number in the output of the previous command), and kill it. In this example, Cassandra is process
12345
.kill -9 12345
All processes on platform servers should now be halted.
7. Make snapshots and backups of all platform servers
The upgrade to Abiquo 5.2.x is a major upgrade with upgrades of third-party software packages that are critical platform dependencies
You MUST make snapshots of all servers in your platform before you upgrade to Abiquo 5.2.x.
8. Prepare yum repositories on all servers
9. Upgrade distributed API and DB servers
This section describes the upgrade for a standard API and DB server.
This section contains an alternative upgrade procedure for standalone Database servers and a Distributed API server without DB
10. Upgrade remote services servers
11. Upgrade monitoring server
12. Upgrade steps from 4.7.x to 5.0.x
Start with your original version and perform the steps to the final version.
13. Upgrade steps from 5.0.x to 5.1.x
Start with your original version and perform the steps to the final version.
14. Upgrade steps from 5.1.x to 5.2.x
Start with your original version and perform the steps to the final version.
When upgrading from 5.1.0 or 5.1.1 to 5.1.2 or above, follow the steps from the Upgrade steps from 5.0.x to 5.1.x block.
15. Upgrade steps for 5.2 versions
These steps apply to upgrades starting from version 5.2.0 and above.
16. Configure Abiquo after the upgrade
Before you start the Abiquo Tomcat server, add Abiquo configuration properties to the abiquo.properties file.
By default the abiquo.properties file is found in the /opt/abiquo/config/ folder.
See Changes to Abiquo configuration propertiesConfigure the user interface. The default UI location is /var/www/html/ui.
Optional: Add custom labels and translations in the lang_xx_XX_custom.json files in the lang folder
Add custom configuration to client-config-custom.json. See Configure Abiquo UI
If your API is not in the same domain as the UI, set the API endpoint pointing to your Abiquo API server:{ "config.endpoint": "http://myAPIserver/api" }
- Reporting changes: To upgrade the Abiquo Reports database for the upgrade to Abiquo 4.7.x+, contact Abiquo Support for the file and procedure.
17. Start Abiquo servers and services
To start the Abiquo platform servers and services, do these steps:
On the Abiquo server, restart the HTTP daemon to refresh the user interface files, and bring up the Tomcat server.
service httpd start service abiquo-tomcat start
On the Remote services server, start the Tomcat server
service abiquo-tomcat start
On the Monitoring server do these steps.
Edit the file
/opt/kairosdb/conf/kairosdb.properties
to update the name of the following variable and to remove the port from it:Replace the line
kairosdb.datastore.cassandra.host_list=192.168.888.999:9160
.With this line
kairosdb.datastore.cassandra.cql_host_list=192.168.888.999
. Please note the newcql_
prefix forhost_list
.
Edit the file
/etc/cassandra/conf/cassandra.yml
OR/etc/cassandra/default.conf/cassandra.yaml
(whichever exists) to remove a variable:Remove the line starting with
kairosdb.datastore.cassandra.datapoint_ttl
and save and close the file.
Edit the file
/opt/kairosdb/conf/kairosdb.properties
to add a new variable (ref: Internal JIRA SUP-333):Add
kairosdb.datastore.cassandra.datapoint_ttl = 15768000
On the Monitoring server, start the Cassandra service
sudo service cassandra start
WAIT about 5 minutes until the service is up and running
Start the KairosDB service
sudo service kairosdb start
Start the other services in this order
sudo service abiquo-emmett start sudo service abiquo-delorean start
On the V2V server: restart the Tomcat server:
service abiquo-tomcat restart
In Abiquo, re-enable the physical machines!
Clear your browser cache to prevent glitches in the UI