Augmenting Performance Session Retention Times in Docker

The retention period for the performance session data collected by Skylight orchestrator is the maximum amount of time that the data is kept on Skylight orchestrator before it is purged. Older data (stored for longer than the retention period) is automatically purged on a "first in, first out" basis. The retention period applies to data collected during performance sessions set up on Skylight orchestrator.

The default retention period is one week. This is recommended if Skylight orchestrator will be collecting performance session data and also collecting streamed metrics data from Skylight elements and Skylight sensor: control.

To determine disk configurations of the Docker host before increasing retention, please refer to Docker Disk Configuration to extend disk usage.

Procedure Requirements

A. This procedure must be executed from the Skylight orchestrator console. Connect to the console via a remote SSH client (appliance IP address, port 2200).

B. Part of this procedure is performed in the Skylight orchestrator console (Climanager Service). To access the console, you need to know the credentials of the skylight user.

C. Part of this procedure is performed in mgr-commands mode. To enter this mode, you must know the credentials for a valid Skylight orchestrator user account (an account for the Skylight orchestrator web interface).

Procedure Steps

This procedure explains how to set the retention period for performance session data. Before doing the procedure, you should determine if you really need to change the default period (one week) as explained in Determining the Quantity and Size of Virtual Disks.

When you have determined the data retention period (a number of weeks) that is required for your system, you can set the value as explained below.

To augment performance session retention times in standalone orchestrator

1. Open SSH terminal session to the Skylight orchestrator CLI on port 2200. Log in as the skylight user.

2. Set the retention period by entering this command:
   mgr-config name RRRetentionPeriod value < X >
   Where:

• X is number of weeks. Value can be 1 to 52.

3. Stop services by entering:
   services stop
   When prompted enter: y
   After a short delay, a message indicates that the services have stopped.

4. Start the services by entering:
   services start
   When prompted enter: y
   

   ---

   Note: It may take up to 10 minutes for the Skylight orchestrator services to be healthy.

   ---

5. Confirm that the retention period has been changed:
   a. Access mgr-commands mode by entering:
   mgr-commands
   You will be prompted to enter a username and password.
   b. Enter the username and password for a valid Skylight orchestrator user account (an account that can be used to access the Skylight orchestrator web interface).
   c. Display the configuration:
   show mgr
   d. Check that the retention period now says: < X > weeks.
   e. Quit mgr-commands mode by entering:
   quit

To augment performance session retention times in HA orchestrator

1. Open an SSH terminal session to the Skylight orchestrator designated as the preferred active site on port 2200.

2. Log in as the skylight user.

3. Set the retention period by entering this command:
   mgr-config name RRRetentionPeriod value < X >
   Where:

• X is number of weeks. Value can be 1 to 52.

4. Restart the HA redundancy to apply a new configuration by entering:
   redundancy control restart
   

   ---

   Note: It may take up to 10 minutes for the Skylight orchestrator services to be healthy.

   ---

5. Confirm that the retention period has been changed:
   a. Access mgr-commands mode by entering:
   mgr-commands
   You will be prompted to enter a username and password.
   b. Enter the username and password for a valid Skylight orchestrator user account (an account that can be used to access the Skylight orchestrator web interface).
   c. Display the configuration:
   show mgr
   d. Check that the retention period now says: < X > weeks.
   e. Quit mgr-commands mode by entering:
   quit
   

   ---

   Notes:

   While HA redundancy is restarting, there will be a delay in PM reporting (5 to 10 minutes), but there will be no gap.

   No activity needs to be performed on the passive site. In case of failover, a new active site will have proper retention (< X > weeks in this example).

   ---