✨ New: Try our AI‑powered Search (Ctrl + K) — Read more

Configuring H/W Sensor Management - Warm Standby System

Prev Next

Introduction

This article provides the configuration values and verification steps for deploying Hardware Sensor Management (H/W SM) in a Warm Standby Redundancy environment with a worker VM instance. Use this article alongside the Replicated Cluster with H/W Sensor Management Worker Deployment article, which contains the broader Crosswork Assurance deployment workflow and additional background details.

In a warm standby setup, the database is mirrored to the secondary system at regular intervals. Failover is initiated manually.

Initial Setup

The initial setup for Warm Standby Redundancy is as follows:

  • The primary site normally manages devices. It periodically sends a backup of its data store to the secondary site.
  • The secondary site is in standby mode, ready to replace the primary site in case of failure.
  • A cleanup task at midnight deletes backup files older than seven days in the /home/skylight/backups/ directory (configurable in the Crosswork Assurance Admin Console Web GUI).
  • The Docker host of the H/W Sensor Management secondary site must have enough disk space to store the backup files.

Details for Configuring H/W Sensor Management on the Crosswork Assurance Admin Console Web GUI

Host Information

Field Value
Enable H/W Sensor Management Enabled
Host Information Enabled
Show the prerequisites Select to display the collector host requirements.
Host IP Address(es) IP address of the H/W SM worker — Host A on the first line, Host B on the second line. Each line supports IPv4 only.
SSH Private Key Upload the skylight private key file. This private key is used for both H/W and SM workers.
Skylight User Password Password for the skylight user (required for sudo access). Note: The skylight password must be the same on both hosts.
Enable Dual-Stack
  • Check: Sensor Management connects to devices on both IPv4 and IPv6 networks.
  • Uncheck: Sensor Management connects to devices on IPv4 networks only.

High Availability

Field Value
High Availability Enable
HA Mode Warm Standby (periodic DB backup transfer, manual failover)
DB Backup Remote Directory (Host B)

Directory on Host B where DB backup files pushed from Host A are stored. This directory is created automatically on Host B if it does not already exist

Default value: /home/skylight/backups

DB Backup Frequency How often the DB backup is pushed from Host A to Host B over SFTP.
  • Every 15 minutes: The data store will be backed up every 15 minutes.
  • Every hour: If you select hour as the frequency, an additional field appears. It allows you to set the minute (0 to 59) at which the backup should be done. The data store will be backed up every hour at the selected minute.
  • Every day: If you select day as the frequency, two additional fields appear. The extra fields allow you to set the hour (0 to 23) and minute (0 to 59) at which the backup should be done. The data store will be backed up once a day at the hour and minute you select.
  • Every week: If you select week as the frequency, three additional fields appear. The extra fields allow you to set the day (Sunday to Saturday), hour (0 to 23), and minute (0 to 59) at which the backup should be done. The data store will be backed up once a week on the day and at the hour and minute you select.
  • Every month: If you select month as the frequency, three additional fields appear. The extra fields allow you to set the day of the month (1 to 31), hour (0 to 23), and minute (0 to 59) at which the backup should be done. The data store will be backed up once a month on the day and time you select.
  • Never: If you select Never as the frequency, the data store will not be backed up automatically.

Min: You set the minutes you wish up to 59 by using the drop-down menu and making the selection.

H: You set the H you wish from 0 to 23 by using the drop-down menu and making the selection.

Default value: Every 15 minutes (Recommended)

Warning: Changes made in the Admin Console apply to the Sensor Management database backup schedule. Changes made in the Sensor Management UI do not update the Admin Console setting, so the two screens may display different schedules.

DB Backup Retention (days) Number of days: 1 - 10

Default value: 7

Active Site

Site A (Host A): Select if Host A is the Primary site

Site B (Host B): Select if Host B is the Primary site

Default value: Site A (Host A)

Manual Failover Trigger

Select the target Active Site, increase this value, and deploy the configuration. Failover stops services on the outgoing site and restores the latest backup to the target site.

Increase the value each time you want to trigger a failover. Reusing the same value will not trigger another failover.

Default value: 0

Application Configuration

Field Value
Application Configuration Enabled
Application Version 25.07.1-LTS-HYBRID
Deployment Selection Install
Device profile (max devices) 5K
Session profile (max sessions) 125K
User profile (max users) 250
FIPS mode Enabled: Sensor Management manages FIPS devices. Disabled: Sensor Management manages non-FIPS devices. Default: Enabled

H/W Sensor Collector

Field Value
Sensor Collector Disabled unless required (when enabled it needs a personal access token)

Refer to Configuring the Sensor Collector for H/W and S/W Sensor Management for details.

Deploy and Verify H/W SM Worker

The H/W SM worker is deployed together with Crosswork Assurance. Pre-flight checks include the H/W SM worker checks (SSH as skylight, sudo, firewalld/SELinux, disk, and other prerequisites); resolve any failures before deploying.

Follow the progress on the Controller node:

  1. Access the root user or run sudo su - if the account has sudo privileges.

  2. Configure to use kubectl command, enter:

export KUBECONFIG="/var/lib/embedded-cluster/k0s/pki/admin.conf"
export PATH="$PATH:/var/lib/embedded-cluster/bin"
  1. Check pods and job log, enter:
kubectl -n pca get jobs,pods | grep hw-sm
kubectl -n pca logs job/<hw-sm-app-deploy-job-name>

When the installation succeeds, the hw-sm-app-deploy log ends with:

The installation of Cisco Crosswork Assurance Sensor Management <version> ... is complete

Then verify:

Check Command Expected Result
Worker joined kubectl get nodes The SM worker is Ready alongside the Kubernetes node(s)
H/W SM containers On the worker: docker ps so-core, so-med, so-nbi, so-mysql, so-syslog all healthy
H/W SM CLI On the worker, as skylight: /usr/bin/smcli.sh SM management menu
Admin Console Dashboard Ready, Cluster State Up to date

The H/W SM files are under /home/skylight/so/ on the worker.

© 2026 Cisco and/or its affiliates. All rights reserved.

For more information about trademarks, please visit:
Cisco trademarks 
For more information about legal terms, please visit:
Cisco legal terms