WEBKT

VictoriaMetrics 集群模式部署：从单节点到多副本高可用的平滑迁移实践

9 0 0 0

随着监控规模的扩大，单节点 VictoriaMetrics (VM) 纵使性能再强，也会面临磁盘 IO 瓶颈、计算资源上限以及单点故障风险。将单机版迁移至集群版（Cluster Mode）是支撑千万级活跃序列的必经之路。本文将深入探讨 VictoriaMetrics 集群架构，并提供一套从单机到集群的平滑迁移与数据管理方案。

一、 VictoriaMetrics 集群架构核心组件

不同于单机版（Single-node）将所有功能打包在一个二进制文件中，集群版采取了微服务化架构，核心组件包括：

  1. vmstorage：负责存储时序数据。它是状态服务，支持水平扩展。
  2. vminsert：负责接收数据（支持 Prometheus remote_write、InfluxDB 等多种协议），并根据一致性哈希算法将数据分发到 vmstorage。
  3. vmselect：负责查询数据。它从所有 vmstorage 节点汇总数据并进行聚合计算。
  4. vmagent（可选但推荐）：作为数据采集侧的代理，负责抓取、缓存、重试及流控。

二、 从单节点到集群的平滑迁移路径

在生产环境中，停机迁移通常不可接受。实现“零停机”迁移的关键在于**“双写”与“数据冷备份”**。

1. 部署集群基础架构

首先，在独立环境下部署好 VM 集群（vminsert, vmselect, vmstorage）。确保集群各组件网络互通，并配置好后端存储。

2. 实施双写策略 (Dual Writing)

修改数据采集端（如 vmagent 或 Prometheus）的配置，将 remote_write 同时指向旧的单机版地址和新的集群版 vminsert 地址。

remote_write:
  - url: "http://old-single-vm:8428/api/v1/write"
  - url: "http://new-cluster-vminsert:8480/insert/0/prometheus/api/v1/write"

注：这里的 0 是默认的 tenantID（租户 ID）。

此时，新产生的数据将同时存在于新旧两个系统中。

3. 历史数据迁移 (Backfilling)

对于旧单机版中的历史数据，可以使用 vmctl 工具进行迁移。它是 VM 官方提供的命令行工具，支持从单机版导出并导入到集群。

# 使用 vmctl 将单机数据迁移至集群
./vmctl prometheus --prom-snapshot /path/to/snapshot \
    --vm-address http://new-cluster-vminsert:8480 \
    --vm-account-id 0

迁移完成后，建议根据数据保留周期（Retention），等待新旧系统的数据重叠时间覆盖查询需求。

4. 切换查询后端

将 Grafana 或其他报警系统的查询地址从旧单机版切换到新集群的 vmselect 端口（通常是 8481）。确认数据无误后，关停旧单机节点。

三、 多副本高可用与数据重平衡策略

1. 多副本配置 (-replicationFactor)

在集群模式下，高可用是通过在 vminsert 启动参数中设置 -replicationFactor=N 实现的。

  • 如果设置 -replicationFactor=2，每一条数据会被写入两个不同的 vmstorage 节点。
  • vmselect 在查询时会自动处理副本去重。

2. 扩容后的“数据重平衡”陷阱

这是一个核心痛点：VictoriaMetrics 集群在新增 vmstorage 节点时，并不会像某些分布式数据库那样自动进行数据迁移（Rebalancing）。

新节点加入后，vminsert 会立即按照新的哈希权重将新数据写入新节点。这会导致：

  • 查询不均衡：新节点只有新数据，旧节点承载大量历史数据。
  • 存储不均衡：旧节点磁盘占用高，新节点增长缓慢。

3. 应对策略：平滑的扩容方案

由于 VM 官方认为自动平衡会带来巨大的 IO 开销影响稳定性，通常建议采取以下策略：

  • 自然过渡法：直接扩容。随着时间推移，旧数据根据 Retention 策略自动过期，磁盘压力会逐渐均衡。这是成本最低的方案。
  • 只读节点法：如果旧节点磁盘已满，可以将其启动参数改为只读，并加入新节点处理新写入。
  • 手动重平衡（不推荐用于大规模）：利用 vmctl 导出旧节点部分时间段数据并重新导入集群。

四、 性能调优与运维建议

  1. vmstorage 存储分层：尽可能使用 SSD。如果数据量极大，可以通过控制 retentionPeriod 来平衡成本。
  2. vmselect 缓存设置：针对复杂查询，增加 -search.cacheTimestampOffset 等参数可以有效利用缓存，减少对 storage 节点的压力。
  3. 监控集群自身：必须监控 vm_insert_errors_total 和 vm_storage_is_read_only 指标。一旦 storage 节点磁盘剩余低于阈值，该节点会变为只读，导致写入失败。
  4. 合理分配 TenantID：如果是多团队使用，利用集群版的多租户特性（在 URL 中区分 accountID），可以实现物理或逻辑上的数据隔离。

总结

从单机走向集群，VictoriaMetrics 提供了极高的写入吞吐量和查询性能。虽然它在自动重平衡上表现得较为“克制”，但这种设计规避了复杂的分布式事务开销。通过vmagent 双写 + vmctl 历史迁移 + 合理的副本因子，开发者可以构建出一个稳定、可水平扩展的生产级监控存储系统。

码界架构师 时序数据库运维自动化

评论点评