-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for High-Availability mode based on Backends #5
Conversation
Support for High-Availability mode based on Backends
Just my curiosity here...in order to setup HA, I need to unseal all servers? Essentially then you'd have all servers unsealed ready to step up. My question would be, in a lockdown / seal scenario, that'd then mean you'd need to seal all of them separately, correct? |
@pearkes Correct on both counts! |
Looks great! I'll add some more info the CLI output to relay this information. I think maybe changing |
Yeah that might be useful, since then we can provide standby and leader info. Also we may need configuration flags for that advertise address. We can detect a default if consul if being used by asking the agent for the local address. |
[NOJIRA] Timeout requests for input and deploys for now
This PR adds support for running Vault in a highly-available mode. In addition to a sealed/unsealed state, there is now an active/standby state. Once unsealed, if HA is enabled, the Core goes into a standby state. It waits until it can acquire the global mutex, and then enters the active state allowing operations to be processed. Sealing the core causes an immediate step-down, but otherwise once unsealed, the core will go between standby and active automatically based on lock acquisition.