The below figure illustrates the UFM high-level architecture.
![Picture3.png](https://docscontent.nvidia.com/dims4/default/7d94ffe/2147483647/strip/true/crop/866x486+0+0/resize/866x486!/quality/90/?url=https%3A%2F%2Fk3-prod-nvidia-docs.s3.us-west-2.amazonaws.com%2Fbrightspot%2Fconfluence%2F0000018c-5dd3-d8bb-ad8c-fff7759d0000%2Fimages%2Fnetworking%2Fdownload%2Fattachments%2F144714653%2FPicture3.png)
Support of Active-Standby HA approach. UFM is not designed to run with multiple instances (active-active mode). There are several constraints:
Single SM
Single SharpAM
Single UFM Telemetry
UFM is stateful and manages its internal state (cluster topology model) in RAM
Persistent storage usage is required for the following:
Configuration files (UFM, SM, SharpAM, UFM Telemetry, Apache)
DB (SQlite) – history telemetry + configuration + app state
Operation history – logs, events, alarms
FR#1
Develop “ufm operator” examples, refer to:
FR2#
1. KVS DB (etcd), Config Maps
2. 3rd party Cache\DB with load-balancing HA built-in (Redis, MongoDB, etc)