The witness design consists primarily of two component areas: The witness service running on the Linux machine, and the witness logic residing in PowerStoreOS. These components work together to provide a robust set of predictable outcomes and application uptime in the event of an unplanned infrastructure outage.
Witness service:
- Installed outside of PowerStoreOS at a third site
- Registered in PowerStore Manager
- Communicates using the PowerStore cluster management network
- No active checks and only responds to requests from a PowerStore
- Only responds to requests from PowerStore and does not trigger a metro session operation
- Is not involved in the application data path and doesn’t get any host workload
- Maintains a witness status database
- Witness logic in PowerStoreOS:
- Exchanges the witness session information with the metro witness
- Runs periodic keep-alive checks against the metro witness
- Uses a preferred/non-preferred role to prioritize surviving volume
- Gets the winner or loser role from metro witness during a failure scenario
- Allows to keep preferred or non-preferred volume online after a decision with metro witness