In my case, there is an agent in front of Vault cluster for preprocessing requests and forwarding to vault instances, the agent could make sure that the same key (kv) will not be written into vault at the same time.
If we deploy vault cluster in active-active mode, which means deploying multiple standalone instances, and disable the cache, all vault instances can handle write and read requests.
And more, scale-out could improve vault cluster’s performance.
I’m not sure if there is any risk in write and read kv pair in vault active-active mode. Is there anyone could help to analyze ?
Hi,
What are the requirements you are trying to satisfy with this architecture?
You might post an architecture diagram/conceptual diagram of what you’re looking to do here - I think you might be mixing some terms up with actual Vault terms.
When you say “agent” do you meant Vault Agent? Or some custom proxy/API in front of Vault?
Can you clarify what you mean by active-active? This sounds similar to Enterprise’s replication functionality (Replication | Vault | HashiCorp Developer) but you still have to define a primary and secondary cluster. Are you looking to create entirely separate Vault clusters (or single-server instances) and manage replicating the KV data across them manually?
Which storage backend are you planning to use? Where will it be hosted (colated on vault, same DC, AZ, etc)?
Hopefully I’m not wrong though, but the only supported and ha enabled storage backends (Consul and embedded) are build on Raft. Raft has one leader and one leader only so you would have to use an unsupported storage backend.
In addition, attention must again be paid to a possible split brain, which makes the whole thing more difficult.
Mysql is used as the storage backend of vault. Raft, cache are disabled in my deployment. Every vault was deployed in standalone mode. Multiple vault instances use the same mysql instance, so they share the keys and secret data.
the “agent” mentioned there, is an application developed by myself. The agent can be a client, and vault is the server.
In this mode, everything runs normally. But, I’m sure whether there is any risk.
Using multiple standalone Vault instances pointing to a single/shared storage backend like this seems very fragile. I’m surprised it works at all.