UFM High-Level Architecture

The below figure illustrates the UFM high-level architecture.

FR#1

Support of Active-Standby HA approach. UFM is not designed to run with multiple instances (active-active mode). There are several constraints:

1. Single SM

2. Single SharpAM

3. Single UFM Telemetry   

4. UFM is stateful and manages its internal state (cluster topology model) in RAM

FR#2

Persistent storage usage is required for the following:

1. Configuration files (UFM, SM, SharpAM, UFM Telemetry, Apache)

2. DB (SQlite) – history telemetry + configuration + app state

3. Operation history – logs, events, alarms

Solution Options

FR#1

Develop “ufm operator” examples, refer to:

• active-standby-controller

• Implementing leader election for Kubernetes pods

• kubernetes-active-passive

• ActiveStandbySingletonPod

FR2#

1.    KVS DB (etcd), Config Maps
2.    3rd party Cache\DB with load-balancing HA built-in (Redis, MongoDB, etc) 

Last updated: November 10, 2025