Signiant Support

13.0 Manager and Agent Upgrade Best Practices Guide Print



Manager and Agent Upgrade

Introduction

This section provides best practices for the upgrade of a Signiant system. The intent is to ensure a smooth upgrade with minimal downtime and to identify early in the process any issues that may impact the upgrade and ensure they are resolved prior to the upgrade. The key part of this strategy is testing the upgrade process utilizing a sandbox.

Upgrade Time

The time required for the upgrade to complete will vary significantly depending on the size of the database and the log folder. The upgrade may complete in as little as 15 minutes or may take as long as 12 hours. The sandbox Manager upgrade test will provide the definitive time. To minimize the upgrade time,do the following:

  1. Run the Maintenance job with aggressive parameters to prune the size of the database and the log folder. It is recommended that the minimum parameters be selected to minimize the sizes of the database and log folder.
  2. Move the log folder contents out of the log folder structure for the duration of the upgrade.

Log Folder Management

The log file folder on the Manager can be very large in either total size and/or number of files. The Manager upgrade scans every file found in this folder which can take a long time, extending the total upgrade time. To shorten this interval, the contents of the log folder can be temporarily moved to a location outside the Signiant folder structure and copied back upon completion of the upgrade. At a minimum the Maintenance job on the Manager must be run prior to the upgrade.


Release Notes

The release notes for each Signiant release between the current Manager software release and the target release must be reviewed. All requirements and recommendations contained therein must be followed.


Test Plan

A test plan must be developed that covers all the regular administrative and operational tasks performed on the production system. This test plan is executed on the sandbox Manager before and after the test upgrade, as well as on the production manager after the upgrade. The tests should include:

  1. User login.
  2. Backup job run.
  3. Maintenance job run.
  4. SOAP job control (if used).
  5. Job reporting.
  6. Job run (all types).
  7. Agent administration.
  8. Cross-trust management.
  9. User creation.

If the installation includes Media Exchange, then the following additional tests should be included:

  1. User login through the Media Exchange login page.
  2. Uploading and sending a package.
  3. User login via the notification email link.
  4. Downloading a package.

If the installation includes the Content Transfer Engine (CTE), then the following additional tests should be included:

  1. CTE upload.
  2. CTE download.

Upgrading from a Windows 32bit Signiant Manager to a Windows 64bit Signiant Manager

To upgrade from a Windows 32bit Signiant Manager to a Windows 64bit Signiant Manager, do the following:

  1. Create test plan which fully exercises Manager functionality and jobs being used in the production system.
  2. Create a Manager backup by running the Backup job, ensuring the job completes successfully, and transfer the backup file to a separate server if that task was not performed by the Backup job.
  3. Run the Windows 64bit Signiant Manager installer.

If you need to restore the Manager, follow the restore procedures detailed in the Restoring the Managerin Chapter 4 in the Manager User's Guide.


Hardware and Operating System Changes

During a Manager upgrade the opportunity is sometimes taken to complete other hardware upgrades or operating system changes. In the interest of isolating application upgrade issues from system upgrade issues, the Manager software upgrade should be performed independently of other changes.

The following sections list the changes permitted and not permitted on the Manager, and the recommended process to follow.

Upgrade Hardware in Existing Server

When the existing server will be used after the hardware upgrade, or specifically the disk containing the Manager software will be used, then do the following:

  1. Create test plan which fully exercises Manager functionality and the jobs being used in the production system.
  2. Create a Manager backup by running the Backup job, ensuring the job completes successfully, and transfer the backup file to a separate server if that task was not performed by the Backup job.
  3. Shutdown the Manager.
  4. Perform the hardware upgrades. For example, add additional memory.
  5. Restart the Manager.
  6. Execute test plan.
  7. If the Manager fails to start, perform these additional steps:
    1. Rollback the hardware changes.
    2. Restore the Manager backup.
    3. Restart the Manager.
    4. Execute test plan.

Replace Existing Server or Switch from Windows to Linux

When a completely new server will be used, or the operating system on the server is to be switched from Windows to Linux, do the following:

  1. Create a test plan which fully exercises Manager functionality and the jobs being used in the production system.
  2. Commission new server hardware in a sandbox staging area where it will not interfere with production system.
  3. Install operating system.
  4. Install Manager software. The version installed must be the same as that on the production Manager.
  5. Ensure network connectivity to all agents to which the existing Manager has connectivity.
  6. Create backup of production Manager by running the Backup job.
  7. Restore this backup on the new server hardware.
  8. Execute test plan.
  9. Move server to production area.
  10. Create new backup of production Manager by running the Backup job. It is imperative to create a new backup as it is possible that agents will have renewed their certificates on the existing Manager since the first backup was taken. If a restore is then performed for production use, the agents whose certificates were renewed will no longer be able to communicate with the Manager or other agents.
  11. Restore this new backup on the new server hardware.
  12. Execute test plan.

Known Issues

The following issues have been known to occur during Manager software upgrades. The checks, as specified, should be made, and the detailed actions taken prior to initiating the upgrade.

Legacy Report Views

Legacy report views may exist on Managers that were originally installed with a release prior to 8.0. The Manager upgrade to the latest release will fail if these job views exist. These job views are no longer relevant as they have been replaced with newer job views. Contact Signiant support for instructions on deleting these obsolete job views from the Manager prior to the upgrade. 

  1. Login to the Manager as root on Linux or the Administrator on Windows.
  2. Open a shell window on Linux or a Command windows on Windows.
  3. Execute the following command:

    (Linux) <install folder>/db/pgsql/bin/psql -U postgres DTM_DB

    By default, on Linux the install folder is:

    /usr/signiant/dds/bin/

    (Windows) <install folder>\db\pgsql\bin\psql -U postgres DTM_DB

    By default, on Windows the install folder is:

    C:\Program Files\Signiant\Mobilize\

  4. From within the Postgres command interface, execute the following command:select * from report_template;

    This results in output similar to:

    report_type | template_name | report_template | created_by | changed_on
    -------------+---------------+-----------------+------------+------------ (0 rows)

    If a result other than "(0 rows)" is returned, then contact Signiant support for further instructions.

32-bit Manager Software on a 64-bit Linux Operating System

While the installation of 32-bit Linux Manager software on a 64-bit Linux operating system is not a supported configuration, the Manager may have been installed this way in the past. If it has been determined that 32-bit Manager software has been installed on a 64-bit operating system, contact Signiant support for further instructions.


Hardware Configuration

The Manager hardware requirements have changed for later releases of the software. Specifically the amount of memory required has increased to a minimum of 8 Gbytes. Review the hardware requirements in the current Manager Installation User's Guide and ensure they are met by the Manager hardware. If not, then a hardware upgrade must be scheduled prior to the software upgrade.


Sandbox Environment

Performing a test upgrade in environment identical to that of the production system is the single most important step for ensuring a trouble free production upgrade. And the key word is identical; the following areas must be identical between the production Manager and that in the sandbox: 

  • Hardware platform: 32/64-bit, processor type, processor speed, and amount of memory.
  • Operating system: Specific Windows or Linux version including patch level.
  • Disk configuration and free space available.
  • Manager software release and method in which it arrived at that level. For example, if the production Manager is at release 12.0 but was originally installed with 11.4 then upgraded to 12.0, then the same upgrade path must be followed on the sandbox Manager.

To prepare a sandbox Manager for the test upgrade, do the following:

Windows Manager

  1. Dump the database from the existing production Manager:
    1. Schedule a maintenance interval for the production Manager as it will be taken out of service for the duration of the database dump. This could take up to 30 minutes.
    2. Ensure the Maintenance job has run successfully in the past 24 hours.
    3. Ensure the Backup job has run successfully in the past 24 hours.
    4. Login to the product Manager as the Administrator user.
    5. Open a Command window.
    6. Stop all Manager services using the Services control panel. All Signiant services have a name which starts with the word “Signiant”.
    7. Start the Postgres database using the Services control panel. The name of the service is Signiant Postgres Database.
    8. Dump the database:

      <install folder>\db\pgsql/bin\pg_dump -U postgres DTM_DB > C:\tmp\dtmDB.dmp

      By default, the <install folder> is C:\Program Files\Signiant\Mobilize\. Ensure the folder into which the database is being dumped has adequate space.
  2. Copy the file created above, dtmDB.dmp from the production Manager to the Sandbox Manager.
  3. Load the database into the Sandbox Manager:
    1. Login to the product Manager as the Administrator user.
    2. Open a Command window.
    3. Drop the current database:

      <install folder>\db\pgsql/bin\dropdb -q -U postgres DTM_DB

      By default, the <install folder> is C:\Program Files\Signiant\Mobilize\.
    4. Create the new database:

      <install folder>\db\pgsql/bin\created --encoding UNICODE -U postgres DTM_DB

    5. Load the database:

      <install folder>\db\pgsql\bin/pgsql -q -U postgres DTM_DB < C:\tmp\dtmDB.dmp

    6. Restart the Manager services using the Services control panel.

Linux Manager

  1. Obtain and install hardware matching the production Manager.
  2. Obtain and install hardware matching a cross-section of the production agents. If sufficient hardware is not available to place all the necessary agents in the sandbox environment, an alternative is to cross-trust the sandbox Manager with existing production agents.
  3. Install the Manager software following the same process used on the production Manager.
  4. Dump the database from the production Manager and reload it on the sandbox Manager. Depending on whether the Manager is on a Windows or Linux server, do one of the following two sets of steps to perform this function:
    1. Dump the database from the existing production Manager:
      1. Schedule a maintenance interval for the production Manager as it will be taken out of service for the duration of the database dump. This could take up to 30 minutes.
      2. Ensure the Maintenance job has run successfully in the past 24 hours.
      3. Ensure the Backup job has run successfully in the past 24 hours.
      4. Login to the product Manager as the Administrator user.
      5. Open a Command window.
      6. Stop all Manager services using the Services control panel. All Signiant services have a name which starts with the word "Signiant".
      7. Start the Postgres database using the Services control panel. The name of the service is Signiant Postgres Database.
      8. Dump the database:

        <install folder>\db\pgsql/bin\pg_dump -U postgres DTM_DB > C:\tmp\dtmDB.dmp

        By default, the <install folder> is C:\Program Files\Signiant\Mobilize\. Ensure the folder into which the database is being dumped has adequate space.
    2. Copy the file created above, dtmDB.dmp from the production Manager to the Sandbox Manager.
    3. Load the database into the Sandbox Manager:
      1. Login to the product Manager as the Administrator user.
      2. Open a Command window.
      3. Drop the current database:

        <install folder>\db\pgsql/bin\dropdb -q -U postgres DTM_DB

        By default, the <install folder> is C:\Program Files\Signiant\Mobilize\.
      4. Create the new database:

        <install folder>\db\pgsql/bin\created --encoding UNICODE -U postgres DTM_DB

      5. Load the database:

        <install folder>\db\pgsql\bin/pgsql -q -U postgres DTM_DB < C:\tmp\dtmDB.dmp

      6. Restart the Manager services using the Services control panel.

    1. Dump the database from the existing production Manager:
      1. Schedule a maintenance interval for the production Manager because it will be taken out of service for the duration of the database dump. This could take up to 30 minutes.
      2. Ensure the Maintenance job has run successfully in the past 24 hours.
      3. Ensure the Backup job has run successfully in the past 24 hours.
      4. Login to the product Manager as the root user.
      5. Open a shell window.
      6. Stop all the Manager services: /etc/init.d/siginit stop
      7. Start the Postgres database: /etc/init.d/siginit start dbpostgres
      8. Dump the database:

        <install folder>/db/pgsql/bin/pg_dump -U postgres DTM_DB > /tmp/dtmDB.dmp

        By default, the <install folder> is "/usr/signiant/dds/". Ensure the folder into which the database is being dumped has adequate space.

  5. Copy the file created above, dtmDB.dmp from the production Manager to the Sandbox Manager.
  6. Load the database into the Sandbox Manager:
    1. Login to the sandbox Manager as the root user.
    2. Open a shell window.
    3. Drop the current database:

      <install folder>/db/pgsql/bin/dropdb -U postgres DTM_DB

      By default, the <install folder> is /usr/signiant/dds/.

    4. Create the new database:

      <install folder>/db/pgsql/bin/creatdb --encoding UNICODE -T template0 postgres DTM_DB

    5. Load the database:

      <install folder>/db/pgsql/bin/pgsql -U postgres DTM_DB </tmp/dtmDB.dmp

    6. Restart the Manager services:

      /etc/init.d/siginit start

 

Separate license keys are required for the Manager located in the sandbox. If you do not have a set of license keys for this Manager, please contact Signiant support for assistance.

Once the sandbox Manager and agents are installed, including the reload of the production database, the next step is to run all the types of jobs found on the production Manager with the size types and sizes of files used with the production jobs. While not every job needs to be run, at least one job of each type (including to and from each type of agent) must be included.

Ideally a complete cross-section of agents is installed in the sandbox environment. It is possible that not all types of agents are available for installation in the sandbox, or perhaps the agents in the sandbox do not have access to the production infrastructure or third party devices. In that case, a trust relationship can be setup between the sandbox Manager and some of the production agents. The jobs on the sandbox Manager can then be configured to jobs run against production agents. It is imperative that all job types be run on the sandbox Manager.


Peered Managers

An increasing number of Managers are peered (trust relationship established) with Managers from another part of the organization or from another company. While it is recommended that all Managers and their agents be upgraded to the latest software release to fully take advantage of the latest features, it is understood that this may not always be possible. Peered Managers at different releases are a supported configuration.

If a peered Manager utilizes restricted grants that include component checksums, upgrading a single Manager will cause jobs being run against the other Manager to fail. The specific reason is that the component checksum includes the script library references which are included from the local manager. The recommended practice is to disable component checksums prior to the upgrade and re-enable them, if desired; after all peered Managers have been upgraded.


Manager Upgrade

Follow the upgrade steps detailed in the Manager Installation User's Guide. It is imperative that a backup is taken immediately before the upgrade is performed and the resulting file is stored on a server other than the Manager.


Agent Upgrade

Once the production Manager upgrade is complete and all post-upgrade testing has been completed, then agents can be upgraded. While lower release agents are supported with a higher release Manager, and it is expected that for large networks upgrading all the agents may take some time, it is recommended that all agents be upgraded as soon as possible.

When performing an upgrade-in-place of the agents, that is with the upgrade triggered by the Manager, all jobs running on the agent must be stopped for the duration of the upgrade. If a job runs on an agent during the upgrade-in-place, the upgrade may not be successful. At that point the resolution is to perform a native upgrade of the agent, that is one where the agent installer is run directly on the agent server.

Note: upgrade-in-place is not supported when upgrading to 12.0 on Mac agents.

Signiant Agent Upgrade on Red Hat 7

The following details a specific Red Hat 7 upgrade scenario.

  • Version 12.0 or 12.1 Signiant Agent is installed on Red Hat 7.
  • You want to upgrade the Signiant Agent to use the 12.2 Red Hat 7 executables.
    • To do this you cannot use upgrade-in-place. To upgrade the Signiant Agent to version 12.2 on Red Hat 7, you must do so manually. For details on how to manually upgrade on Linux, see Chapter 3: Upgrading on Unix/Linux in the Agent Installation User's Guide.

References

The following Signiant documentation should be read when the upgrade is being planned, and the steps therein followed during the actual upgrade.

  • Manager Installation User's Guide
  • Agent Installation User's Guide
  • Clustered Installation User's Guide