User Guide

Cluster Upgrade from 4.35 to 4.36

This guide will lead you through the steps specific for upgrading a NetEye Cluster installation from version 4.35 to 4.36.

During the upgrade, individual nodes will be put into standby mode. Thus, overall performance will be degraded until the upgrade is completed and all nodes are revoked from standby mode. Granted the environment connectivity is seamless, the upgrade procedure may take up to 30 minutes per node.

Warning

Remember that you must upgrade sequentially without skipping versions, therefore an upgrade to 4.36 is possible only from 4.35; for example, if you have version 4.27, you must first upgrade to the 4.28, then 4.29, and so on.

Breaking Changes

Deprecation of the neteye_secure_install

Starting from NetEye 4.36, the neteye_secure_install script is deprecated, but will still be available for internal procedures only. The new installation command will be neteye install. To learn more about it, please refer to the neteye install section.

Alyvix Module General Module Access

Until NetEye 4.35, the permission General Module Access for the Alyvix module was providing the same permissions as the Full Module Access. However, with the introduction of Multi-Tenancy the Alyvix permissions are being revisited.

As a result, starting from version 4.36, upon enabling Multi-Tenancy for Alyvix (refer to Additional Tasks), General Module Access will no longer grant full access to the module. Instead, similar to other modules, it will provide visibility of the module itself without specific permissions.

For more details on the new permissions configuration for the Alyvix module, please refer to the User Roles configuration.

Prerequisites

Before starting the upgrade, you should read very carefully the latest release notes on NetEye’s blog and check out the features that will be changed or deprecated after the upgrade.

  1. All NetEye packages installed on a currently running version must be updated according to the update procedure prior to running the upgrade.

  2. NetEye must be up and running in a healthy state.

  3. Disk Space required:

    • 3GB for / and /var

    • 150MB for /boot

  4. If the SIEM module is installed:

    • The rubygems.org domain should be reachable by the NetEye Master only during the update/upgrade procedure. This domain is needed to update additional Logstash plugins and thus is required only if you manually installed any Logstash plugin that is not present by default.

1. Run the Upgrade

The Cluster Upgrade is carried out by running the following command:

cluster# (nohup neteye upgrade &) && tail --retry -f nohup.out

Warning

If the SIEM feature module is installed and a new version of Elasticsearch is available, please note that the procedure will upgrade one node at the time and wait for the Elasticsearch cluster health status to turn green before proceeding with the next node. For more information, please consult the dedicated section.

After the command was executed, the output will inform if the upgrade was successful or not:

  • In case of successful upgrade you might need to restart the nodes to properly apply the upgrades. If the reboot is not needed, please skip the next step.

  • In case the command fails refer to the troubleshooting section.

2. Reboot Nodes

Restart each node, one at a time, to apply the upgrades correctly.

  1. Run the reboot command

    cluster-node-N# neteye node reboot

  2. In case of a standard NetEye node, put it back online once the reboot is finished

    cluster-node-N# pcs node unstandby --wait=300

You can now reboot the next node.

3. Cluster Reactivation

At this point you can proceed to restore the cluster to high availability operation.

  1. Bring all cluster nodes back out of standby with this command on the last standard node

    cluster# pcs node unstandby --all --wait=300
cluster# echo $?

    0

    If the exit code is different from 0, some nodes have not been reactivated, so please make sure that all nodes are active before proceeding.

  2. Run the checks in the section Checking that the Cluster Status is Normal. If any of the above checks fail, please call our service and support team before proceeding.

  3. Re-enable fencing on the last standard node, if it was enabled prior to the upgrade:

    cluster# pcs property set stonith-enabled=true

4. Additional Tasks

Alyvix Nodes Multitenancy Migration

This section applies only to NetEye installations that are using the Alyvix Feature Module and should be followed for both single tenant and multi tenant environments.

After the upgrade to NetEye 4.35 has been completed, granted the connected Alyvix nodes are updated to version >= 2.5.0, it will be possible to enable the Multi-tenancy features.

Before enabling the Multi-tenancy feature, please ensure the following pre-requisites are met:

  1. All nodes configured as Multitenant - Tenant Specific must have a tenant associated in the Director. Please see Multitenant - Tenant Specific for more information.

  2. The IcingaWeb2 roles that were using the General Module Access permission on module Alyvix should be migrated to Full Module Access, to maintain the same level of access that was granted before. Please see the note in the Breaking changes section for more information.

To migrate your Alyvix system into a multi tenant architecture, the following command can be executed on any NetEye Operative Node:

neteye alyvix-node enable-multitenancy --all

This dedicated command will trigger an automatic migration of all the connected and updated Alyvix nodes to the new multi tenant based structure. Although most of the Alyvix objects such as sessions and test cases will be migrated automatically, the command may ask you to enter some information about the correct reallocation of some of them in case their association to tenants cannot be inferred. The interaction will be essential in order to avoid ambiguities and to accomplish a successful migration.

More information about the command can be found in the dedicated section.

After the switch, the Alyvix module UI will automatically present Multi-tenancy for users with Unrestricted Access, Administrative Access or Full Module Access.

Furthermore, it will also be possible to configure the new Tenant Admin role, to allow a fine-grained access to tenant administrators.

Please see the Roles and User Roles sections for more information about the supported roles and the corresponding IcingaWeb2 permissions.