集群模式

对于低于每秒一百万个数据点的摄取率，建议使用单节点版本而不是集群版本。单节点版本可根据 CPU 内核、RAM 和可用存储空间的数量进行扩展。单节点版本比集群版本更容易配置和操作，所以在使用集群版本之前要三思而后行。上面我们介绍了 VM 的单节点版本的基本使用，接下来我们来介绍下如何使用集群版。（集群对于维护工作增加了，而且数据量不大的话没必要使用集群版本）

集群版主要特点：

支持单节点版本的所有功能。
性能和容量水平扩展。
支持时间序列数据的多个独立命名空间（多租户，和thanos receiver差不多）。
支持多副本。

组件服务

前面我们了解了 VM 的基本架构，对于集群模式下主要包含以下几个服务：

vmstorage：存储原始数据并返回指定标签过滤器在给定时间范围内的查询数据，当 -storageDataPath 指向的目录包含的可用空间少于 -storage.minFreeDiskSpaceBytes 时，vmstorage 节点会自动切换到只读模式，vminsert 节点也会停止向此类节点发送数据并开始将数据重新路由到剩余的 vmstorage 节点。（目录小于最小的可用磁盘空间就变为只读模式）
vminsert：接受摄取的数据并根据指标名称及其所有标签的一致性哈希将其分散存储到 vmstorage 节点。
vmselect：通过从所有配置的 vmstorage 节点获取所需数据来执行查询。

每个服务都可以进行独立扩展，vmstorage 节点之间互不了解、互不通信，并且不共享任何数据。这样可以增加集群的可用性，并且简化了集群的维护和扩展。

最小集群必须包含以下节点：

带有 -retentionPeriod(数据保留的时长，它默认是1个月，最长可以配置100年，永久保留意义不大，你可以配置一周，一个月，一年) 和 -storageDataPath 参数的单 vmstorage 节点
带有 -storageNode=<vmstorage_host>（指定vmstorage地址，如果又多个vmstorage那么就要配置多个vmstorage地址，因为要将所有节点拿过来做hash） 的单 vminsert 节点
带有 -storageNode=<vmstorage_host> 的单 vmselect 节点

生产环境我们建议为每个服务组件运行至少两个节点以实现高可用性，这样当单个节点暂时不可用时，集群会继续工作，而且其余节点还可以处理增加的工作负载。如果你的集群规模较大，那么可以运行多个小型的 vmstorage 节点，因为这样可以在某些 vmstorage 节点暂时不可用时减少剩余 vmstorage 节点上的工作负载增加。（vmstorage越多，那么分摊的压力越小）

各个服务除了可以通过参数标志进行配置之外，也可以通过环境变量的方式进行配置：

扫描二维码关注公众号，回复： 14368464 查看本文章

-envflag.enable 标志必须设置
每个标志中的 . 必须替换为 _，例如 -insert.maxQueueDuration <duration> 可以转换为 insert_maxQueueDuration=<duration>
对于重复的标志，可以使用另一种语法，通过使用 , 作为分隔符将不同的值连接成一个，例如 -storageNode <nodeA> -storageNode <nodeB> 将转换为 -storageNode=<nodeA>,<nodeB>
可以使用 -envflag.prefix 为环境变量设置前缀，例如设置了 -envflag.prefix=VM*，则环境变量参数必须以 VM* 开头

多租户（如果云产品，可能有这种需求）

此外 VM 集群也支持多个独立的租户（也叫命名空间），租户由 accountID 或 accountID:projectID 来标识，它们被放在请求的 urls 中。

每个 accountID 和 projectID 都由一个 [0 .. 2^32] 范围内的任意 32 位整数标识，如果缺少 projectID，则自动将其分配为 0。有关租户的其他信息，例如身份验证令牌、租户名称、限额、计费等，将存储在一个单独的关系型数据库中。此数据库必须由位于 VictoriaMetrics 集群前面的单独服务管理，例如 vmauth 或 vmgateway。（如果没有多租户 accountID projectID默认为0）
当第一个数据点写入指定租户时，租户被自动创建。
所有租户的数据均匀分布在可用的 vmstorage 节点中，当不同租户有不同的数据量和不同的查询负载时，这保证了 vmstorage 节点之间的均匀负载。
数据库性能和资源使用不依赖于租户的数量，它主要取决于所有租户中活跃时间序列的总数。如果一个时间序列在过去一小时内至少收到一个样本，或者在过去一小时内被查询，则认为时间序列是活跃的。
VictoriaMetrics 不支持在单个请求中查询多个租户。

集群大小调整和可扩展性

VM 集群的性能和容量可以通过两种方式进行扩展：

通过向集群中的现有节点添加更多资源（CPU、RAM、磁盘 IO、磁盘空间、网络带宽），也叫垂直可扩展性。
通过向集群添加更多节点，又叫水平扩展性。

对于集群扩展有一些通用的建议：

向现有 vmselect 节点添加更多 CPU 和内存，可以提高复杂查询的性能，这些查询可以处理大量的时间序列和大量的原始样本。
添加更多 vmstorage 节点可以增加集群可以处理的活跃时间序列的数量，这也提高了对高流失率(churn rate)的时间序列的查询性能(如果集群规模比较大，很多时候都是高流失率来影响集群的性能，比如一个指标里有大量的数据，但是数据有频繁的标签的变动，比如pod名称，pod重建了，那么名称就变化了，如果序列里面包含了经常变动的标签，那么就会导致高流失率，因为vm查询的时候会根据你的指标标签来做一些缓存，标签经常变化导致缓存失效，那么重新构建索引缓存会大大增加集群的压力)。集群稳定性也会随着 vmstorage 节点数量的增加而提高，当一些 vmstorage 节点不可用时，活跃的 vmstorage 节点需要处理较低的额外工作负载。
向现有 vmstorage 节点添加更多 CPU 和内存，可以增加集群可以处理的活跃时间序列的数量。与向现有 vmstorage 节点添加更多 CPU 和内存相比，最好添加更多 vmstorage 节点，因为更多的 vmstorage 节点可以提高集群稳定性，并提高对高流失率的时间序列的查询性能。
添加更多的 vminsert 节点会提高数据摄取的最大速度，因为摄取的数据可以在更多的 vminsert 节点之间进行拆分。
添加更多的 vmselect 节点可以提高查询的最大速度，因为传入的并发请求可能会在更多的 vmselect 节点之间进行拆分。

集群可用性

HTTP 负载均衡器需要停止将请求路由到不可用的 vminsert 和 vmselect 节点。
如果至少存在一个 vmstorage 节点，则集群仍然可用：
vminsert 将传入数据从不可用的 vmstorage 节点重新路由到健康的 vmstorage 节点
如果至少有一个 vmstorage 节点可用，则 vmselect 会继续提供部分响应（会丢失数据，因为数据在其他节点）。如果优先考虑可用性的一致性，则将 -search.denyPartialResponse 标志传递给 vmselect 或将请求中的 deny_partial_response=1 查询参数传递给 vmselect。

重复数据删除

如果 -dedup.minScrapeInterval 命令行标志设置为大于 0 的时间，VictoriaMetrics 会去除重复数据点。例如，-dedup.minScrapeInterval=60s 将对同一时间序列上的数据点进行重复数据删除，如果它们位于同一离散的 60 秒存储桶内，最早的数据点将被保留。在时间戳相等的情况下，将保留任意数据点。（比如说有两个Prometheus的副本同时将数据写入远程的vm，那么就有两份数据了，那么需要配置-dedup.minScrapeInterval 的参数，那么隔这么长时间就会重复的数据删除掉）

-dedup.minScrapeInterval 的推荐值是等于 Prometheus 配置中的 scrape_interval 的值，建议在所有抓取目标中使用一个 scrape_interval 配置。

如果 HA 中多个相同配置的 vmagent 或 Prometheus 实例将数据写入同一个 VictoriaMetrics 实例，则重复数据删除会减少磁盘空间使用。这些 vmagent 或 Prometheus 实例在其配置中必须具有相同的 external_labels 部分，因此它们将数据写入相同的时间序列。

容量规划

根据我们的案例研究，与竞争解决方案（Prometheus、Thanos、Cortex、TimescaleDB、InfluxDB、QuestDB、M3DB）相比，VictoriaMetrics 在生产工作负载上使用的 CPU、内存和存储空间更少。

每种节点类型 - vminsert、vmselect 和 vmstorage 都可以在最合适的硬件上运行。集群容量随着可用资源的增加而线性扩展。每个节点类型所需的 CPU 和内存数量很大程度上取决于工作负载 - 活跃时间序列的数量、序列流失率、查询类型、查询 qps 等。建议为你的生产工作负载部署一个测试的 VictoriaMetrics 集群，并反复调整每个节点的资源和每个节点类型的节点数量，直到集群变得稳定。同样也建议为集群设置监控，有助于确定集群设置中的瓶颈问题。

指定保留所需的存储空间（可以通过 vmstorage 中的 -retentionPeriod 命令行标志设置）可以从测试运行中的磁盘空间使用情况推断出来。例如，如果在生产工作负载上运行一天后的存储空间使用量为 10GB，那么对于 -retentionPeriod=100d（100 天保留期）来说，它至少需要 10GB*100=1TB 的磁盘空间。可以使用 VictoriaMetrics 集群的官方 Grafana 仪表板监控存储空间使用情况。

建议留出以下数量的备用资源。

所有节点类型中 50% 的空闲内存，以减少工作负载临时激增时因为 OOM 崩溃的可能性。
所有节点类型中 50% 的空闲 CPU，以减少工作负载临时高峰期间的慢速概率。
vmstorage 节点上 -storageDataPath 命令行标志指向的目录中至少有 30% 的可用存储空间。

VictoriaMetrics 集群的一些容量规划技巧：

副本集将集群所需的资源量最多增加 N 倍，其中 N 是复制因子。
可以通过添加更多 vmstorage 节点和/或通过增加每个 vmstorage 节点的内存和 CPU 资源来增加活跃时间序列的集群容量。
可以通过增加 vmstorage 节点的数量和/或通过增加每个 vmselect 节点的内存和 CPU 资源来减少查询延迟。
所有 vminsert 节点所需的 CPU 内核总数可以通过摄取率计算：CPUs = ingestion_rate / 100K。
vminsert 节点上的 -rpc.disableCompression 命令行标志可以增加摄取容量，但代价是 vminsert 和 vmstorage 之间的网络带宽使用率会更高。

复制和数据安全

默认情况下，VictoriaMetrics 的数据复制依赖 -storageDataPath 指向的底层存储来完成。（它更加推荐的方式也是把数据存储在云盘上面，云盘就有些保障措施来保证数据的高可用，不至于磁盘挂了，数据就没了）

但是我们也可以手动通过将 -replicationFactor=N 命令参数传递给 vminsert 来启用复制，即每份数据存入 N 个不同的节点，在查询的时候，同时查询多个节点，去重后返回给客户端。这写入的时候对输入的数据进行一致性 hash 计算，写入到 storageIndex 节点，假设 N=2，则同时还要写入到 storageIndex + 1 节点。

启用复制保证了多达 N-1 个 vmstorage 节点不可用，所有数据仍可用于查询。集群必须至少包含 2*N-1 个 vmstorage 节点，其中 N 是复制因子，以便在 N-1 个存储节点丢失时为新摄取的数据维持指定的复制因子。

例如，当 -replicationFactor=3 传递给 vminsert 时，它将所有摄取的数据复制到 3 个不同的 vmstorage 节点，因此最多可以丢失 2 个 vmstorage 节点而不会丢失数据。vmstorage 节点的最小数量应该等于 2*3-1 = 5，因此当 2 个 vmstorage 节点丢失时，剩余的 3 个 vmstorage 节点可以为新摄取的数据提供服务。

启用复制后，必须将 -dedup.minScrapeInterval=1ms 命令行标志传递给 vmselect 节点，当多达 N-1 个 vmstorage 节点响应缓慢和/或暂时不可用时，可以将可选的 -replicationFactor=N 参数传递给 vmselect 以提高查询性能，因为 vmselect 不等待来自多达 N-1 个 vmstorage 节点的响应。有时，vmselect 节点上的 -replicationFactor 可能会导致部分响应。-dedup.minScrapeInterval=1ms 在查询期间对复制的数据进行重复数据删除，如果重复数据从配置相同的 vmagent 实例或 Prometheus 实例推送到 VictoriaMetrics，则必须根据重复数据删除文档将 -dedup.minScrapeInterval 设置为更大的值。请注意，复制不会从灾难中保存，因此建议执行定期备份。另外复制会增加资源使用率 - CPU、内存、磁盘空间、网络带宽 - 最多 -replicationFactor 倍。所以可以将复制转移 -storageDataPath 指向的底层存储来做保证，例如 Google Compute Engine 永久磁盘，该磁盘可以防止数据丢失和数据损坏，它还提供始终如一的高性能，并且可以在不停机的情况下调整大小。对于大多数用例来说，基于 HDD 的永久性磁盘应该足够了。

备份¶

建议从即时快照执行定期备份，以防止意外数据删除等错误。必须为每个 vmstorage 节点执行以下步骤来创建备份：

通过导航到 /snapshot/create HTTP handler 来创建一个即时快照。它将创建快照并返回其名称。

可以通过访问 /snapshot/create 这个 HTTP handler 来创建即时快照，它将创建快照并返回其名称。
使用 vmbackup 组件从 <-storageDataPath>/snapshots/<snapshot_name> 文件夹归档创建的快照。归档过程不会干扰 vmstorage 工作，因此可以在任何合适的时间执行。
通过 /snapshot/delete?snapshot=<snapshot_name> 或 /snapshot/delete_all 删除未使用的快照，以释放占用的存储空间。
无需在所有 vmstorage 节点之间同步备份。

从备份恢复：

使用 kill -INT 停止 vmstorage 节点。
使用 vmrestore 组件将备份中的数据还原到 -storageDataPath 目录。
启动 vmstorage 节点。

VictoriaMetrics 集群模式概述