Nexus controller on HA cluster: state storage, backup strategy, migration path & roadmap questions

ICS_DOS

Hi all,

We're evaluating Netgate Nexus for fleet management of roughly 100 pfSense Plus firewalls (datacenter multi-tenant environment). Our core setup is a two-node CARP HA cluster on 26.03.1.

Current plan for the evaluation phase: run the Nexus controller on the secondary HA node and register both cluster nodes plus a handful of test instances. We're aware the controller state is node-local (not part of XMLRPC sync), and that config changes to synced sections should only ever be pushed to the primary.

Long-term we want to separate fleet management from the HA cluster entirely - partly because of the current lack of RBAC separation between instance operators and controller admins, partly to decouple the management plane from the edge firewalls. So the controller will eventually move, either to a dedicated pfSense Plus VM or to the standalone Nexus instance that was mentioned as being in the works.

While investigating backups, we noticed that controller data (registrations, tags, etc.) does not appear in config.xml at all. Digging further: the pfnet-controller daemon reads /var/etc/pfnet-controller/pfnet-controller.conf, which points to its state store at /var/db/pfnet-controller.db - so the actual controller state lives entirely outside config.xml and is not covered by config backups or AutoConfigBackup.

Questions:

Backup: is backing up /var/db/pfnet-controller.db the supported approach for controller state? If yes, what is the recommended method for a consistent copy of the live database - ZFS snapshot, sqlite .backup, stopping the service, or is there a controller-ctl subcommand for this? Anything else that belongs in the backup set (e.g. the TLS identity in /var/etc/pfnet-controller/, or is that regenerated/derived)?
Migration: is transplanting this database (plus TLS identity and advertised address) to a new controller host a supported migration path, or is standing up a new controller and re-registering all instances the only official route? How does rehosting of managed-instance entitlements work in that case?
Is there a rough timeline for the standalone Nexus instance? If it's near, we'd rather wait than build an interim dedicated-VM setup.
Any news on RBAC (separating instance management from controller administration)? This is currently the main blocker for giving colleagues access.
Anything HA-specific planned for MIM, e.g. cluster-aware handling of node pairs?

Thanks!

keyser

@ICS_DOS Excellent analysis and questions ️

marcosm

The db is already included in config.xml backups under <mim>.
The necessary info is in the db. If that's migrated then there's no need to re-register the fleet. However the licensing is separate from that so there should be plans to deal with that accordingly in the case of a migration.

As for the rest, it's being worked on. Feel free to reach out to Sales as they may be able to help further.

ICS_DOS

@marcosm Thanks for your Answer

Ok I didn't see this as i was checking the config.xml file and not a backup export
Good to know, will check with Sales when I get the go ahead from Management.

Is there any Timeline you could share for the rest? From what I can see its not tracked on Redmine at least.