Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.
Version: 2.15.0

LiveOps Continuous Operations Dashboard

Introduction

Legacy UI

The LiveOps dashboard described on this page is part of the legacy Eyeglass desktop interface and has no direct equivalent in the 2.15.0 GUI. Of its five columns, Cluster Reachability and Cluster Version are available on the 2.15.0 Inventory page instead — a shared page at the top of the sidebar across all products, see Navigation overview for the redesigned equivalent. Continuous Ops Status and Effective Cluster Version have no 2.15.0 home as of this release.

The LiveOps dashboard, available from the Eyeglass desktop in the legacy UI, gave a single view of ongoing operational status between replicating PowerScale cluster pairs. Where the DR Dashboard focused on failover readiness (SyncIQ, Access Zone, and configuration replication state), LiveOps focused on the continuous operational health of the clusters themselves — reachability, release compatibility, and whether snapshot and dedupe settings stayed in sync between source and target.

What the Dashboard Shows

The LiveOps dashboard lists each cluster managed by Eyeglass with the following columns:

ColumnDescription
Cluster NameThe cluster managed by Eyeglass.
Cluster ReachabilityWhether Eyeglass can log in to the cluster. This check runs every minute.
Cluster VersionThe detected PowerScale OneFS release running on the cluster.
Effective Cluster VersionThe API version actually in use between Eyeglass and the cluster. If a replicating pair is running different OneFS releases, Eyeglass operates in mixed API mode and uses the lower of the two cluster versions' API. Only objects or attributes supported by that lower API version will be synchronized to the newer cluster.
Continuous Ops StatusA per-policy and per-cluster summary confirming that snapshot and dedupe settings are in sync and audited between the replicating cluster pairs.
Mixed API mode example

If a target cluster is running OneFS 8.x but Eyeglass detects the source cluster at OneFS 7.x, the Effective Cluster Version for that pair will show OneFS 7.x — meaning only attributes supported in OneFS 7.x are synchronized, even though the target cluster supports newer capabilities.

LiveOps Sync Jobs

The Continuous Ops Status column summarizes the health of two background jobs that keep a replicating cluster pair aligned beyond the file data SyncIQ itself replicates:

Snapshot Sync

For each replicating cluster pair, a job scans for SnapshotIQ policies at or under the paths covered by a SyncIQ policy, and syncs those snapshot policies (schedule and other settings) to the corresponding path on the target cluster. This keeps the target cluster's snapshot schedule aligned with the source, so a target that becomes active after a failover already has the same snapshot protection in place.

Dedupe Sync

Replicates dedupe settings between the source and target clusters so the target cluster's SmartDedupe jobs can reduce the data to the same disk space savings as the source. Without this, a cluster that becomes active after a failover would need to run its own dedupe jobs from scratch before reaching the source's usage levels — Dedupe Sync avoids that delay so normal operations aren't affected by a lag in space reclamation.

Why It Matters

Snapshot and dedupe configuration drift between a source and target cluster does not block a failover the way a SyncIQ or configuration replication error does, but it can leave the target cluster's data protection posture out of alignment with the source once a failover makes it the active cluster. Reviewing LiveOps status alongside the DR Dashboard gives you a complete picture of both failover readiness and ongoing operational parity between cluster pairs.

See Also

  • Readiness Checks – DR Dashboard status for SyncIQ, DFS, Policy, and Access Zone failover readiness.
  • Cluster Check – Verify a managed cluster remains reachable and free of configuration replication errors.