如何实现HashiCorp Vault 3节点集群？含单/多数据中心HA部署需求

Got it, let’s walk through setting up a 3-node highly available (HA) Vault cluster with your existing Consul backend, covering both single and multi-data center scenarios. I’ll keep this practical and actionable based on production best practices.

First, you’ll need to ensure your Consul backend is also running as a 3-node HA cluster (since Vault relies on Consul for storage and service discovery). If you currently have a single Consul node, start by expanding that first.

1. Prepare the Consul 3-Node Cluster #

For each Consul server node, create a configuration file (e.g., consul-server.hcl) with these settings:

datacenter = "dc1"
server = true
bootstrap_expect = 3 # Tells Consul to wait for 3 servers before forming a cluster
client_addr = "0.0.0.0"
bind_addr = "0.0.0.0"
retry_join = ["<consul-node-1-ip>", "<consul-node-2-ip>", "<consul-node-3-ip>"]
ui_config {
  enabled = true # Optional, for Consul UI access
}

• Start each Consul server with consul agent -config-file=consul-server.hcl
• Verify cluster health with consul members—you should see all 3 nodes as server and alive

2. Configure Each Vault Node #

Create a Vault configuration file (e.g., vault-config.hcl) for each node, adjusting the api_addr and cluster_addr to match the node’s own IP/FQDN:

storage "consul" {
  address = "<consul-node-1-ip>:8500,<consul-node-2-ip>:8500,<consul-node-3-ip>:8500"
  path    = "vault/"
  ha_enabled = true # Enables HA mode for Vault
}

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = false # **Critical for production**—use valid TLS certs
  tls_cert_file = "/path/to/your/cert.pem"
  tls_key_file  = "/path/to/your/key.pem"
}

# Unique to each Vault node
api_addr = "https://<vault-node-ip>:8200"
cluster_addr = "https://<vault-node-ip>:8201" # Used for intra-cluster communication

• Start each Vault node with vault server -config=vault-config.hcl

3. Initialize & Unseal the Cluster #

• Pick one Vault node to initialize: vault operator init -key-shares=5 -key-threshold=2 (adjust shares/threshold to your security needs)
  • Save the unseal keys and root token securely—you’ll need these for all nodes
• For each Vault node, run vault operator unseal <unseal-key> twice (matching your threshold) to unlock the node
• Verify cluster status: Log in with vault login <root-token>, then run vault operator members to see all 3 nodes listed, and vault status to confirm one node is the active leader

4. Client Access Tips #

• Use Consul DNS (e.g., vault.service.consul) to let clients automatically discover Vault nodes
• Or set up a load balancer (like NGINX) in front of the Vault nodes to distribute traffic

For multi-DC, you’ll first need a multi-DC Consul cluster, then configure Vault with replication across data centers. We’ll cover Disaster Recovery (DR) Replication (for failover) and Performance Replication (for low-latency access in remote DCs).

1. Set Up Multi-DC Consul Cluster #

For each Consul server in your primary DC (dc1), update the config to include WAN join settings:

datacenter = "dc1"
server = true
bootstrap_expect = 3
client_addr = "0.0.0.0"
bind_addr = "0.0.0.0"
retry_join = ["<dc1-consul-1>", "<dc1-consul-2>", "<dc1-consul-3>"]
retry_join_wan = ["<dc2-consul-1-ip>"] # IP of a Consul server in secondary DC

For the secondary DC (dc2) Consul servers:

datacenter = "dc2"
server = true
bootstrap_expect = 3
client_addr = "0.0.0.0"
bind_addr = "0.0.0.0"
retry_join = ["<dc2-consul-1>", "<dc2-consul-2>", "<dc2-consul-3>"]
retry_join_wan = ["<dc1-consul-1-ip>"]

• Start all Consul nodes, then verify WAN connectivity with consul members -wan

2. Configure Primary DC Vault Cluster #

Use the same SDC Vault config as above, but ensure the Consul storage block specifies the primary DC:

storage "consul" {
  address = "<dc1-consul-1>:8500,<dc1-consul-2>:8500,<dc1-consul-3>:8500"
  path    = "vault/"
  datacenter = "dc1"
  ha_enabled = true
}

• Initialize and unseal the primary cluster as before

3. Configure Secondary DC Vault Cluster (DR Replication) #

Create a config for each secondary Vault node, adding DR replication settings:

storage "consul" {
  address = "<dc2-consul-1>:8500,<dc2-consul-2>:8500,<dc2-consul-3>:8500"
  path    = "vault/"
  datacenter = "dc2"
}

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = false
  tls_cert_file = "/path/to/your/cert.pem"
  tls_key_file  = "/path/to/your/key.pem"
}

api_addr = "https://<dc2-vault-node-ip>:8200"
cluster_addr = "https://<dc2-vault-node-ip>:8201"

replication "dr" {
  primary_api_addr = "https://<dc1-vault-leader-ip>:8200"
  token            = "<dr-replication-token>" # Generate this in primary DC
}

• Generate the DR replication token in the primary DC:

  vault login <root-token>
  vault token create -policy=dr_replication -period=72h -orphan
  

• Start the secondary Vault nodes—they’ll automatically sync data from the primary
• Verify replication status with vault read sys/replication/dr/status in the secondary DC

4. Optional: Performance Replication (For Low-Latency Access) #

If you need remote clients to read/write from their local DC with low latency, set up Performance Replication instead of DR. The config is similar, but use:

replication "performance" {
  primary_api_addr = "https://<dc1-vault-leader-ip>:8200"
  token            = "<performance-replication-token>"
}

• Generate the performance token with vault token create -policy=performance_replication -period=72h -orphan in the primary DC

• Auto-Unseal: Avoid manual unseal by using Auto-Unseal (e.g., AWS KMS, Azure Key Vault, HashiCorp Cloud Platform) to automate the unseal process across all nodes
• Consul ACLs: Lock down Consul access with ACLs—create a policy for Vault that allows it to read/write to the vault/ path
• TLS Everywhere: Ensure all Vault and Consul communication uses valid TLS certificates (no self-signed in production)
• Monitoring: Set up monitoring for Vault (via vault status, Prometheus metrics) and Consul to track cluster health

内容的提问来源于stack exchange，提问作者rajeswari