Upgrading Central Node installed as a cluster

Before installing the application upgrade package, it is recommended to first create a backup of the current state of each Central Node server to be updated and download it to the hard drive from the application administrator menu. If installing an application upgrade package fails, or if you need to reinstall Kaspersky Anti Targeted Attack Platform, you can use the backup copy of the application.
We also recommend learning about the limitations of the version to which you are upgrading.

If you are using the distributed solution and multitenancy mode, you need to upgrade each Central Node in accordance with the following procedure without disconnecting the SCNs from the PCN.

The disconnection of SCNs from the PCN is irreversible, you cannot reconnect an SCN to any PCN server.

You must first update the PCN first, then each SCN one by one. Upgrading SCNs before the PCN or upgrading multiple servers in parallel will cause the application to become inoperable.

The upgrade is delivered as an upgrade package. The package is included in the application distribution kit.

To upgrade Central Node installed as a cluster:

  1. Remove integration servers if any have been added.
  2. We recommend saving the settings of removed integration servers in any convenient way. After upgrading the application, you can restore these settings manually.

    All steps described below must be performed on servers in Technical Support Mode after elevating user privileges using the sudo -i command.

  3. If you upgraded Central Node to version 7.0.3 from version 6.1 or earlier, go to the cluster server where the 7.0.3 upgrade package was placed and run the following commands:

    rm -rf /data/upgrade/

    rm -rf /opt/upgrade_venv

    If you never upgraded to version 7.0.3, skip this step.

  4. Log in to any of the storage servers in the Central Node cluster and check if the Ceph storage is working. To do so, execute the following command:

    ceph -s | grep health:

    The Ceph storage is healthy if the following value is returned:

    health: HEALTH_OK

    If the value is different from health: HEALTH_OK, please contact Technical Support.

  5. Log in to each of the storage servers and restart the kata-osd-starter service:

    systemctl restart kata-osd-starter

  6. Make sure the Kafka service is working:
    1. Find out which servers in the cluster have the 'manager' role in Docker swarm. To do this, run the following command on any of the cluster servers:

      docker node ls

      A list of cluster servers is displayed. Look at the MANAGER STATUS column in the list: if a server has Leader or Reachable in that column, it means it has the 'manager' role.

    2. Run the following command:

      docker service ps kata_product_main_1_schema_registry

      Look at the value in the NODE column to determine which server has the Schema Registry.

    3. Log in to the server with the Schema Registry and run the following command:

      docker exec -it $(docker ps | grep schema_registry | awk '{ print $1 }') curl http://127.0.0.1:8081/subjects

      If you get a JSON with a list of subjects, it means the Kafka service is working.

  7. Place the application upgrade package on the Central Node cluster server with the manager role in the Docker swarm, in the /data directory. To view the role, use the $ docker node ls command.
  8. Enter the management console of the relevant server over SSH or through a terminal.
  9. Make sure you have more than 100 GB of free space on the /dev/sda2 partition on each server in the cluster.
  10. Unpack the upgrade archive:

    tar xvf /data/kata-upgrade-8.0.0.1-x86_64_en-ru-zh.tar.gz -C /data/

  11. Install the upgrade package by running the following commands:

    cd /data/upgrade/

    ./run_kata_upgrade.py

    The user name entry window is displayed.

  12. In the Username field, enter the name of the user with administrator rights, select the OK button and press Enter.

    Default value: admin.

  13. In the Password field, enter the password of the user with administrator rights, select the OK button, and press Enter.

    This opens the window for entering the path to the update archive.

  14. In the Data directory field, enter the path to the update archive, select the OK button, and press Enter.

    Default value: /data/upgrade.

  15. In the displayed window, confirm the refusal to use the KEDR functionality.
  16. In the displayed window, select the localization language for the NDR functionality.

    Parts of the application related to NDR functionality will be displayed in the selected language.

    After some time, the console will display a message prompting you to power off the server.

  17. Connect to the server that you want to power off over SSH or through a terminal.
  18. Run the poweroff command.
  19. Mount the Ubuntu-based ISO image of Kaspersky Anti Targeted Attack Platform 8.0 (kata-cn-8.0.0.1-inst.x86_64_en-ru-zh.iso). If you are using Kaspersky Anti Targeted Attack Platform based on the Astra Linux operating system, follow the instructions to create an ISO image.
  20. Boot from the device that has the mounted iso image.
  21. In the GRUB bootloader menu, select one of the following commands:
    • When upgrading a Central Node deployed on Astra Linux: Upgrade 7.1.1.530 if you are upgrading the component from version 7.1.1, or Upgrade 7.1.3.533 if you are upgrading the component from version 7.1.3.
    • When upgrading a Central Node deployed on Ubuntu: Upgrade 7.1.3.533.
  22. Follow the remaining steps of the wizard to complete the upgrade on the server.
  23. After the upgrade is complete, go to the console of the server you connected to at step 7, type next, and press Enter.

    A script is started that completes the upgrade process. After the update is complete, the console displays a message telling you to shut down the next server in the cluster.

  24. Repeat steps 15 to 21 for each server in the cluster.

    The last server to be updated is the server to which you connected at step 7. For that server, step 21 is omitted.

The Central Node component is upgraded.

After updating the component, you must log in again to the Central Node server management console over SSH or through the terminal.

If, after upgrading a Central Node component that has been used in distributed solution and multi-tenancy mode to version 7.1.1, 7.1.2, or 7.1.3, the Embedded Sensor is missing, you need to restore its functionality by removing the limitations.

Page top