Replication is a Vault enterprise feature, with two use cases: Disaster Recovery (DR) and Performance. Its core unit is a Vault cluster; in replication, there is a primary cluster linked to a series of follower secondaries, and these clusters communicate in a one-to-many near real-time flow. Disaster Recovery replication is meant to protect against a failure of entire clusters, while performance replication is built to distribute a high-volume workload.
In both instances, it is important to be able to monitor the health of both the primary and secondary clusters, be made aware of potential issues and ways to address those issues, and note the connections between clusters. In Vault 1.5, we redesigned the replication UI to create dashboards that are easy to read, and make problems easier to see and troubleshoot. We are excited to share our redesigned dashboards with you.
In the images below, the old replication UI is on the top, and the new UI on the bottom for a Disaster Recovery (DR) primary:
As you can see, there are quite a few visual changes and a lot of new information. A quick rundown of the DR primary dashboard:
If there’s an error, we’ll surface it:
And when the cluster is re-indexing, we’ll show you the progress:
The real power is in comparing dashboards. To get a look at this, here’s a DR secondary:
This dashboard is entirely new and includes:
Looking at the UI for both the primary and secondary allows for valuable comparison between the data presented so as to gauge the health of the cluster.
For the special case where the cluster is both a DR and a Performance primary, we created a custom “summary” dashboard that gives an overview of both, and links to individual dashboards for each:
There are also UI changes in the Manage tabs which include modals for each action to enable you to perform each action (promotion, demotion, generating tokens, etc.) with certainty. When performing a destructive action such as deletion or demotion, we’ve added a double-confirm.
Our process involved the collaboration of Product, Design, and Engineering in order to get it all done, with input from folks all across the company.
Our next steps are to gather feedback on this iteration of replication. We’ve made a lot of changes here to the UI and the UX of this feature. We look forward to hearing what you think and continuing to iterate on replication.
To learn more about Monitoring Vault Replication, visit our learn guide on the topic.
Thanks for reading! And if this kind of work interests you, we’re also hiring!
Learn about a Vault SlackBot made by DigitalOnUs.
When multiple teams use Consul, it becomes difficult to correlate manually managed policies with the identity accessing it. In this blog, we'll show you an automated method to ensure least-privilege access to Consul using Terraform and Vault.
We are happy to announce that we have an officially supported HashiCorp Vault GitHub Action. GitHub Actions allow you to easily automate your CI/CD developer workflows to run actions against repositories based on triggers within GitHub. The Vault GitHub Action allows you to take advantage of secrets sourced from your HashiCorp Vault infrastructure for things like static and dynamic secrets and inject these secrets into your GitHub workflows.