Skip to content

Log Insight 3.0: Upgrade Improvements

In my last post, I talked about what you need to know to upgrade to Log Insight 3.0. In this post, I would like to drill into the new upgrade improvements contained within the release.
li-logo

Pre-validations

In order to better ensure a successful upgrade, Log Insight 3.0 now performs additional pre-validation checks prior to upgrading. In Log Insight 2.5, the following pre-validations existed:

  • Ensure enough space exists on the root filesystem (all nodes): A Log Insight upgrade requires a certain amount of space and if it does not exist then a manual cleanup operation will need to occur prior to the upgrade operation. Note that upgrades are done from the /tmp directory.
  • Ensure upgrading from a supported version (all nodes): Log Insight supports upgrades from GA release to GA release and previous TP release to GA release. This means upgrades from 2.5 GA to 3.0 GA and 2.6 TP2 to 3.0 GA are supported, but upgrades from 2.0 GA to 3.0 GA are not without going through 2.5 GA.

In Log Insight 3.0, the following pre-validations were added:

  • Clusters must be three or more nodes (master node only): While 2-node clusters have never been supported, upgrades to 3.0 require that 2-node clusters be increased to at least 3-node clusters.
  • All nodes online (master node only): If any node is offline when the upgrade operation starts then the upgrade operation will not proceed.
  • /etc/hosts file is valid (master node only): Having loopback addresses defined for routable IP addresses is not supported and will prevent an upgrade operation. Note that editing the /etc/hosts file from CLI has never been supported.

If a pre-validation fails then an error with possible remediation is presented. For example:
li-30-upgrade-failed-cassandraAlso note that a generic failure message also exists with a possible remediation action:

li-30-upgrade-failed-genericRolling Upgrade

There are several things to keep in mind prior to upgrading:

  • Please be advised that upgrading must be done from the cluster master URL directly and not via the ILB!
  • In addition, both ports 80 and 443 must be enabled to the cluster master node for the upgrade operation (port 80 can be disabled post-upgrade operation).
  • Finally, be advised that all worker nodes need to be able to access all core services (e.g. Active Directory) given the new query HA architecture in 3.0 — will be discussed in a future post.

Once you are ready for upgrade, the procedure for the cluster master node remains unchanged from Log Insight 2.5 (I covered the process in this video). It is important to note that the process for upgrading the workers has changed. Previously manual intervention was needed to complete the upgrade as documented here. In Log Insight 3.0, no manual intervention is needed to upgrade the workers — Log Insight does it for you automatically!
Once the cluster master upgrade is complete and you log back into the UI you will see the following message:
li-30-upgrade-successfulIf you navigate to the Cluster page during the upgrade operation you will see something similar to the following:
li-30-rolling-upgrade
Finally, note that the Appliance page no longer exists in Log Insight 3.0 and has been merged with the Cluster page.
For more information on upgrading, please see:

Summary

As you can see, the upgrade procedure for Log Insight 3.0 has been significantly enhanced. One of the key value adds of Log Insight in my opinion is ease of use and rolling upgrades definitely makes Log Insight even easier to use. What do you think of the improvements?

© 2015, Steve Flanders. All rights reserved.

Published inVMware

Be First to Comment

    Leave a Reply

    Your email address will not be published. Required fields are marked *