F5 clusters¶
Most production BIG-IPs run as a pair (active and standby) in a sync-failover device group. The configuration, including certificates, keys and SSL profiles, is written on one member and copied to the others by config-sync. PKIFactor handles this without any cluster-specific setting, and with one rule: it never decides which member holds the reference configuration. When the members disagree, a person decides on the BIG-IP.
What you configure¶
Nothing specific. Declare one endpoint for the pair, pointing at:
- the floating management address of the pair, if you have one (recommended); or
- either member, with the option Follow the ACTIVE unit of the HA pair (on by default). If the declared address is the standby member, writes go to the active member with the same credentials, with no reconfiguration after a failover.
Declare the other members' addresses
PKIFactor follows the active unit only to a management address you declared yourself: the endpoint setting peer_hosts (addresses of the other members of the HA pair, IP addresses or names separated by commas). The address announced by the device itself is never trusted on its own, since a compromised standby could announce a third machine and receive the credentials and the keys. With peer_hosts empty there is no following, and a write on the standby member is refused. In this version peer_hosts is set through the API only (PUT /api/deployment-targets/{id}, in config); the endpoint form does not show it.
The connection test shows the HA role of the member reached and the synchronization state of the group. The endpoint list shows a Cluster out of sync badge when the group is not synchronized.
Automatic sync on the device group
PKIFactor works whether Automatic Sync is enabled on the device group or not: it triggers the config-sync itself after each change. Enabling automatic sync is still recommended, so that any change made by hand on the active member is also propagated.
Before every write¶
PKIFactor checks the group before any configuration change:
| Situation | Decision |
|---|---|
| Standalone unit (no device group) | Write |
| The member reached is standby | Switch to the active peer, if its address is in peer_hosts, and check again; if the active peer is not declared or cannot be reached with the same credentials, refuse (writing on the standby and syncing to the group would overwrite the active member's newer configuration) |
| The member is neither active nor standby (forced offline, offline) | Refuse: its configuration may be stale or in maintenance |
| Group In Sync | Write |
| Group reports Changes Pending and these are this unit's own changes (made by PKIFactor in this operation) | Write; they are synchronized right after |
| BIG-IP recommends synchronizing the peer to the group (this unit is behind) | Refuse, naming the member to synchronize first |
| A change conflict, Awaiting Initial Sync, Disconnected, or a missing member | Refuse, with the BIG-IP's own status |
| The synchronization state cannot be read (account permissions) | Write, with a warning in the log |
A refusal is reported on the binding with its reason; PKIFactor retries later. It never runs a from-group synchronization by itself.
After every write¶
- PKIFactor saves the configuration (
save sys config), so that the change survives a reboot. - It runs
config-sync to-groupand waits for the group to report In Sync (30 seconds). - If the group does not converge, the deployment stays successful on the member written (it is never rolled back) and an alert HA cluster out of sync goes to the owner team: the peer may still serve the previous certificate until someone synchronizes.
Hourly check¶
Every hour, PKIFactor reads the synchronization state of each declared group. A group that stays out of sync raises an alert, even when no deployment is running: a peer that did not receive a configuration would serve an older certificate after a failover.
Repair a group out of sync¶
On the BIG-IP (Device Management > Overview):
- Read the recommended action: it names the member whose configuration is the reference.
- Check on that member that the certificate objects and profiles are those you expect (PKIFactor's objects are named
zetacert_<...>). - Sync that member to the group.
- In PKIFactor, run Deploy now on the bindings of that endpoint if you want to be sure every member serves the current certificate; the verification runs again.
Before synchronizing from a member
Synchronizing a member to the group replaces the configuration of the other members, including any partition managed by hand. Check which member holds the reference configuration before clicking, and save a UCS archive of each member beforehand.
Laboratory option¶
Allow writes on a STANDBY unit lifts the standby refusal. It exists for laboratories where the pair is rebuilt often. Never enable it in production.