2026阿里云国际版 Elasticsearch 实战教程：容量按 3.4 倍算、单分片 30GiB、冷热分层与计费结构全拆解

阿里云国际版 Elasticsearch 是国际站少数「文档齐全、但价格页不公开」的产品：官方容量评估文档给出了一条可以手算的 3.4 倍存储公式、节点数上限 vCPU×5、单分片 30GiB（特殊 50GiB、日志 100GiB）三条硬经验值，而 /en/product/elasticsearch/pricing 这类价目页在国际站是 404，单价必须在创建集群的购买页按地域与规格现查。本文把「建集群时要选的 9 个参数 → 容量怎么估 → 节点与分片怎么配 → ILM 冷热分层怎么落地 → 计费项与成本控制 → 上线前检查与故障排查」串成一条可复现的路径，并把国际站与国内站的两处实质差异写清楚，避免照抄国内教程踩空。

Meta Description: 阿里云国际版 Elasticsearch 实战：3.4 倍容量公式、vCPU×5 节点上限、单分片 30GiB、专有主节点与协调节点配比、ILM 冷热分层 OpenStore、计费项拆解与故障排查清单。

关键词：阿里云国际版 Elasticsearch、ES 容量评估、分片规划、ILM 冷热分离、OpenStore、Elasticsearch 计费、Kibana、Logstash

一、先搞清楚你在买什么：四个组件 + 一个内核

阿里云 Elasticsearch 不是一个「装好 ES 的虚拟机」，而是把 Elastic Stack 整条链路托管了。理解这一点，后面所有的参数选择才有依据。

两个容易被忽略的事实：

1. X-Pack 是企业版功能，在阿里云托管的 ES 里默认集成。这意味着你不需要为「安全 + 告警 + 监控」再买一套商业授权，但反过来也意味着 Kibana 的账号体系必须按 X-Pack 的方式管理（见第九节）。
2. 控制台与内核是分离的两层。购买页现在提供「cloud-native new control mode」部署模式，扩缩容、监控告警的体验由控制面决定；而查询性能、索引写入由内核（AliES 内核增强版）决定。所以「升级内核版本」和「升级控制台」是两件事，排障时要分清是哪一层的问题。

1.1 标准版与内核增强版差在哪

购买页的 Cluster Type 只有两个选项，它们不是「版本新旧的差别」，而是「有没有启用增强能力入口」的差别：

📝 小提示：如果你的目标是日志检索 + 冷数据长期留存，选内核增强版并启用 OpenStore 通常比「堆大盘」更省；如果只是站内搜索、数据量在几百 GiB 量级，标准版完全够用，且没有额外的存储计费项。

二、创建集群时的 9 个参数，选错三个就要重建

地域和版本在集群创建后不可更改，这是最容易返工的地方。

关于可用区，官方的定位很明确：1-AZ 适合非关键业务，2-AZ 是跨区容灾形态，3-AZ（默认）是高可用形态。选 2 个或 3 个可用区后，页面会出现 Zone 2 / Zone 3 配置项，默认值为 Random（由系统自动分配），也可以手工指定。多可用区集群的代价是网络往返增加，写入路径上尤其明显，所以日志类业务用 2-AZ、交易类检索用 3-AZ 是比较常见的取舍。

2.1 国际站与国内站的两处实质差异

这是照抄国内教程最常翻车的地方，购买页文档里有明确说明：

• 国际站的数据节点没有「节点规格族（specification family）」选项。国内站可以选通用型/计算型等规格族，国际站直接给具体规格。
• 国际站的节点配置区没有 Elastic Node（弹性节点）这个区块。国内站可以把部分节点配成弹性节点按量计费，国际站买不到这个形态，所以「用弹性节点削峰」的方案在国际站不成立，只能靠 Auto Scaling 或提前预留。

📝 小提示：文档在计费章节里写了一条与节点形态相关的规则——「无论集群选包年包月还是按量付费，弹性节点都按量计费」。国际站虽然买不到弹性节点，但如果你在混合架构里从国内站迁移过来，这条规则是账单对不上的常见原因。

三、容量评估：3.4 倍公式，以及它到底由哪五项构成

官方给的推荐存储公式，是本文最值得记住的一个数：

推荐集群存储 = 源数据量 × (1 + 副本数) × 索引开销 / (1 - OS 预留) / (1 - 集群内部开销) / (1 - 安全阈值)
            = 源数据量 × (1 + 1) × 1.7
            = 源数据量 × 3.4

1.7 不是拍出来的，而是四个系数的连乘：索引开销按源数据的 1.1 倍、操作系统预留 5%、集群内部开销（段合并、日志）20%、安全水位阈值 15%。把 1.1 ÷ 0.95 ÷ 0.80 ÷ 0.85 算一遍，得到 1.7028，再乘 (1+1) 个副本就是 3.4056 ——四舍五入即官方的 3.4。

一个直接可用的算例：源数据 500 GiB、1 副本 → 推荐存储 500 × 3.4 = 1,700 GiB。如果你按「500 × 2 = 1,000 GiB」买盘，集群在数据涨到约 60% 时就会开始频繁触发分片搬迁，写入延迟随之抖动。

3.1 两个容易被算漏的「隐形占用」

• X-Pack 监控索引会持续增长。.monitoring-es-6- 占用相当可观，.monitoring-kibana-6- 随索引数量增长，.watcher-history-3-* 占用小但会堆积。它们的保留期默认 7 天，不能改。
• 集群自身日志（运行日志、访问日志、慢查询日志）保留期同样是 7 天且不可更改，占用随查询量和写入量上升。

也就是说，3.4 倍里已经含了这部分，但如果你把安全阈值压到 5% 以下去「省盘」，省下来的空间会被监控索引和合并临时空间吃掉，最后表现为磁盘反复在 85% 上下横跳。

四、节点规格与数量：vCPU×5 是硬上限，内存×30/10/50 是场景系数

拿到 1,700 GiB 的存储需求之后，下一步是「拆成几个节点、每个节点多大」。官方给了两条硬规则：

• 单集群数据节点数上限 = 单节点 vCPU 数 × 5。2 vCPU 的节点最多 10 个，16 vCPU 的节点最多 80 个。这条规则的含义是：核数越小，节点数天花板越低，想扩就得换更大的规格，而不是无限堆小机器。
• 单节点最大存储 = 单节点内存 (GiB) × 场景系数：通用场景 ×30、查询（加速/聚合）场景 ×10、日志（导入/离线分析）场景 ×50。

集群总存储 = 单节点存储 × 节点数。用上面的 1,700 GiB 举例：

⚠️ 注意：查询场景（重度聚合、排序、加速查询）的单节点上限只有内存 ×10，比通用场景低三分之二。同一份数据，从日志分析改成面向用户的可视化查询，存储规划可能要翻三倍。

4.1 小数据量、重 IO 的场景不要只看容量

文档专门点了一类反直觉的情况：约 1,000 万条短文档、总大小约 3 GiB、以精确匹配/前缀匹配/聚合为主的索引。存储根本不是瓶颈，但每次查询要扫大量 term 与 segment，产生高频随机读，磁盘 IOPS 决定延迟。这种情况的处理方式是：

• 数据节点选 1:2 的 vCPU 内存比，且至少 4 vCPU / 16 GiB 起步，低于这个配置 page cache 留不住索引，请求会持续落到盘上；
• 存储类型选 Standard SSD，不要为了省钱用普通云盘；
• 别指望加主分片来提升 IO。官方明确写了：一个节点能达到的 IOPS 与吞吐由存储类型和节点规格决定，不由主分片数量决定。

五、专有主节点与协调节点：什么时候必须加

5.1 专有主节点（Dedicated master）

数据节点一多，集群状态（cluster state）的维护就会和数据读写抢资源，一旦主节点选主抖动，整个集群会短暂失去元数据服务。官方的规格阶梯很直接：

文档还补了一句关键的例外：如果索引和分片数量很多，或者数据频繁变更、对专有主节点依赖很重，就要在主节点规格上再往上加一档。原因是分片元数据永远驻留在主节点内存里，分片数暴涨时主节点会先 OOM，而不是数据节点。

5.2 协调（客户端）节点

协调节点的作用是承接查询的 scatter/gather 阶段，避免聚合结果的 merge/GC 压在数据节点上。官方建议：

• 协调节点与数据节点按 1:5 配比；
• 协调节点选 1:4 或 1:8 的 vCPU 内存比；
• 至少买 2 个。

算例：10 个 8 vCPU / 32 GiB 的数据节点 → 建议 2 个 8 vCPU / 32 GiB 的协调节点。这个配比在小集群里并不划算（2 个协调节点的钱可能顶得上一个数据节点），所以 3 个数据节点以下的小集群先把数据节点做大更实际。

六、分片规划：单分片 30GiB 是分水岭

分片数量是 ES 里最容易被拍脑袋决定的参数，也是后期最难改的（主分片数只能通过 _split 或 reindex 改）。官方给出的经验值：

配套的三条规则：

1. 分片数与数据节点数相同，或为数据节点数的整数倍。否则磁盘占用与 CPU 负载会倾斜到某几个节点上。
2. 数据量小的时候，用「1 主多副」而不是「多主 1 副」。例：每个索引 20 GiB、集群 5 个数据节点 → 配 1 个主分片 + 4 个副本，既把数据摊到 5 个节点，又让查询可以并行。
3. 总数据量大时，反过来：每个索引配多个主分片 + 每个主分片 1 个副本，通过拆分写入压力来降负载。

6.1 版本差异会改变默认值，这是迁移时的大坑

• 7.x 及以后：每个索引默认 1 个主分片 + 1 个副本。
• 7.x 以前：默认 5 个主分片 + 1 个副本。

同一个「建个索引写日志」的操作，在老集群上会创建 10 个分片，在新集群上只有 2 个。从 5.x/6.x 迁移到 8.x 时，如果按老习惯做容量规划，分片数会直接少 80%，单分片体积随之膨胀，很容易越过 50 GiB 的上限。

📝 小提示：如果某个分片已经过大，官方推荐的做法是增加主分片数（_split API 或 reindex），而不是加副本。加副本只会按副本数成比例地增加磁盘占用，不会把单个分片变小。

七、冷热分层与 OpenStore：把 ILM 真正跑起来

日志类业务的成本结构里，90% 的存储是「没人查但必须留」的历史数据。托管的解法是热温两层 + ILM 自动搬迁。

7.1 先建热温集群

创建集群时开启 warm 节点即可得到热温集群。开启后系统会自动给节点启动参数加上 -Enode.attr.box_type，热节点为 hot，温节点为 warm——注意是 warm，不是 cold，这与原生 ES 的 warm tier 对齐。数据节点只有在开启 warm 节点之后才会被标记为 hot 节点。

建好之后先在 Kibana 的 Dev Tools 里确认属性：

GET _cat/nodeattrs?v&h=host,attr,value

返回里同时出现 hot 与 warm 节点，说明热温架构生效；只有一个值，说明 warm 节点没开成功，后面所有 ILM 的 cold 阶段都会卡在「等待分配」上。

7.2 一个可用的 ILM 策略

PUT /_ilm/policy/game-policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": { "max_size": "1GB", "max_age": "1d", "max_docs": 1000 }
        }
      },
      "warm": {
        "min_age": "30m",
        "actions": {
          "forcemerge": { "max_num_segments": 1 },
          "shrink": { "number_of_shards": 1 }
        }
      },
      "cold": {
        "min_age": "1h",
        "actions": {
          "allocate": { "require": { "box_type": "warm" } }
        }
      },
      "delete": {
        "min_age": "2h",
        "actions": { "delete": {} }
      }
    }
  }
}

四个阶段的语义：

• hot：max_size（1 GB）、max_age（1 天）、max_docs（1000 条）任一满足就 rollover，旧索引等待 30 分钟后进入 warm；
• warm：shrink 到 1 个分片 + forcemerge 到 1 个 segment，减少段数量与文件句柄；
• cold：rollover 后 1 小时，把分片分配到 box_type=warm 的节点；
• delete：rollover 后 2 小时删除索引。

再配一个索引模板，把新索引路由到 hot 节点，并绑定策略与 rollover 别名：

PUT _template/gamestabes_template
{
  "index_patterns": ["gamestabes-*"],
  "settings": {
    "index.number_of_shards": 5,
    "index.number_of_replicas": 1,
    "index.routing.allocation.require.box_type": "hot",
    "index.lifecycle.name": "game-policy",
    "index.lifecycle.rollover_alias": "gamestabes"
  }
}

创建带序号的初始索引，并把它设为写索引：

PUT gamestabes-000001
{
  "aliases": {
    "gamestabes": { "is_write_index": true }
  }
}

之后所有写入都打别名 gamestabes，不要写具体索引名。rollover 发生时别名会自动指向新索引，业务侧无感。

7.3 四个必踩的坑

另外有一条隐蔽的性能事实：ILM 默认每 10 分钟检查一次匹配策略的索引。如果你把 max_age 设成 5 分钟，实际仍可能拖到 15 分钟才 rollover；要更灵敏就改 indices.lifecycle.poll_interval，但调小会增加主节点负担。

7.4 OpenStore：冷数据不占本地盘

对「必须留一年、但一年只查一次」的数据，OpenStore 是更彻底的做法：它是存算分离架构，存储按实际用量计费，扩容节点时不需要迁移底层数据。购买页默认关闭，开启后冷阶段可以直接落到 OpenStore，本地盘只留热数据。代价是冷查询的首次读取会比本地盘慢，适合「偶尔翻查、能接受秒级延迟」的合规留存场景。

进度确认命令：

GET _cat/shards/shrink-gamestabes-000012

分片所在节点的 box_type 为 warm，说明冷阶段已生效。

八、计费结构：没有公开价目表，但有公开的计费公式

这是本文必须提前说清的一点。国际站的 Elasticsearch 没有可供抓取的价格页（/en/product/elasticsearch/pricing 返回 404，中文路径同样为空），官方计费文档也明确写着「同一规格的价格随地域与订阅时长变化，请在购买页按实际配置查看」。所以任何声称「$X/月起」的第三方文章，基本是把某一次的地域报价当成了全站报价。

能确定的是计费项的构成与计算公式，这决定了你的账单被哪几个变量放大。

从这张表能读出四个成本控制要点：

1. 必选项只有「规格 + 存储」两项，其它全部是可选增强。预算紧张时先把可选项关掉，而不是砍规格——砍规格会直接击穿第四节的容量红线。
2. 两个存储增强项都只支持按量计费。这意味着一旦开启，即使集群是包年包月，这两项也会每月产生浮动费用，做年度预算时不能按固定值估。
3. ES Agent 按 token 计费，是唯一「用得越多越贵」的运维项。多人共用一个集群、频繁让它分析日志时，这项可能悄悄涨起来。
4. Logstash 独立计费。文档在 Logstash 购买页右下角提供价格明细，而「同一规格不同地域、不同时长价格不同」的说明同样适用。如果只是做轻量字段清洗，把过滤逻辑放进 Beats 的 processor 或写入侧的应用里，能省掉一整个 Logstash 集群的钱。

8.1 包年包月还是按量付费

官方推荐的路径是「先按量付费建集群验证，满足要求后再转包年包月」。这条路径的实际价值在于：容量评估里的 3.4 倍公式是经验值，先用按量付费跑一周真实写入，看 _cat/allocation 的实际磁盘水位，比任何公式都准，然后再决定包年的规格。

⚠️ 一个账单层面的坑：弹性节点无论集群采用何种计费方式，都按量计费。国际站购买页目前不提供弹性节点区块，但如果你是从国内站迁移过来、或者混合使用两站资源做对账，这条规则是「包年账单里为什么会冒出按量费用」的标准答案。

九、上线前的六项检查

托管的 ES 少了装包和调 JVM 的活，但把「安全」和「可恢复」的责任留给了你。

快照这一项建议做一次恢复演练，而不是建完仓库就结束。演练步骤：建一个临时索引写入测试数据 → 手工触发一次快照 → 删索引 → 从快照恢复到另一个索引名 → 比对文档数。整个流程在托管环境下只需要几条 API，但没有演练过的快照，在真出事那天通常不可用。

PUT _snapshot/oss_repo
{
  "type": "oss",
  "settings": {
    "endpoint": "oss-ap-southeast-1.aliyuncs.com",
    "bucket": "your-es-snapshot-bucket",
    "base_path": "es/snapshots",
    "compress": true
  }
}

OAuth 相关字段（AccessKey、SecretKey）按控制台提示补齐即可，这里不写入正文以免误配。仓库建好后用 PUT _snapshot/oss_repo/manual_1 触发一次手工快照，GET _snapshot/oss_repo/_all 看状态是否为 SUCCESS。

十、故障排查：症状 → 根因 → 修复

这几条里，第一条和第六条最能体现「托管 ≠ 免运维」：

• 写入拒绝不是故障，而是保护。ES 用有界队列挡住写入以保护内存，出现拒绝说明持续写入速率已经超过集群处理能力。此时先看是「分片太大导致单分片写入热点」还是「节点整体不够」，两者的解法完全不同：前者要加主分片做水平拆分，后者要加节点。
• box_type 写成 cold 是最常见的静默失败。原生 ES 教程里经常用 cold，但阿里云托管版只有 hot 和 warm 两个值，写 cold 的分配规则永远不会匹配到任何节点，分片就静静躺在那里等一个不存在的节点。

10.1 排障时的三条命令

GET _cluster/health?pretty
GET _cat/allocation?v&h=shards,disk.indices,disk.used,disk.avail,disk.percent,node
GET _cluster/allocation/explain

第一条看整体状态与未分配分片数，第二条看每个节点的磁盘水位（disk.percent 超过安全阈值就是搬迁的起点），第三条在出现未分配分片时给出逐条原因——包括「节点属性不匹配」「磁盘水位过高」「副本数大于节点数」这类明确判断，比盯着日志猜快得多。

十一、边界：什么时候不该用 ES

ES 在国际站不是孤立的，周边至少有三个产品会和它抢同一份需求。选错产品的代价不是性能差一点，而是成本高一个档、或者能力根本对不上。

判断标准可以简化成一句话：你要的是「可检索的搜索能力」还是「可查询的日志管道」。前者选 ES，后者选 SLS。两者也可以共存——SLS 做全量采集与告警，ES 承接面向业务方的高相关度搜索，用 Logstash 或函数计算做一次分流。SLS 的接入方式见 日志服务 SLS 实战教程，多模存储的取舍见 Lindorm 多模数据库实战，向量场景见 DashVector 向量检索实战。

11.1 数据落地与备份的衔接

ES 的快照仓库建在 OSS 上，意味着备份成本会出现在 OSS 账单而不是 ES 账单里。OSS 的存储类型、生命周期规则可以直接作用在快照目录上，把 30 天以前的快照转低频甚至归档，比在 ES 侧省钱得多。OSS 的存储类型与生命周期配置见 OSS 对象存储实战教程。监控侧则建议把 ES 的集群指标接到应用实时监控 ARMS 或云监控里统一告警，避免「ES 控制台一个告警、业务监控一个告警」两套体系。

十二、总结

把这篇的结论压缩成六句话：

1. 容量按源数据 ×3.4 算（1 副本口径），这 3.4 由「索引开销 1.1 / OS 5% / 内部 20% / 安全阈值 15%」四项连乘得出，不是拍脑袋的经验数。
2. 节点数上限 vCPU×5，单节点存储上限按场景取内存的 30/10/50 倍，查询场景最吃紧，同样的数据在查询场景下可能需要三倍存储。
3. 分片按单分片 ≤30 GiB 规划，分片数取数据节点数的整数倍，7.x 起默认 1 主 1 副，5.x/6.x 默认 5 主 1 副，迁移时要重新算。
4. 专有主节点按 10/30/50 个数据节点的三档阶梯升配，协调节点按 1:5 且至少 2 个，小集群优先做大数据节点而不是加协调节点。
5. 冷热分层只有 hot 和 warm 两个值，ILM 策略名创建后不可改、Kibana UI 只支持小时粒度、默认 10 分钟检查一次，这三点决定了你的策略能不能「按预期时间」生效。
6. 国际站没有公开价目表，能确定的是计费项与公式：规格 + 存储是必选，Indexing Service 托管存储、OpenStore、AI 模型服务、ES Agent 全部按量计费，Logstash 独立计费。做预算时把「按量项」单独列一行。

如果你正准备把一套自建 ELK 迁到托管版，建议的顺序是：先按第四节把现有数据量套进 3.4 倍公式算出目标存储 → 按第六节反推分片数 → 用按量付费建一个小规格集群跑一周真实写入 → 看 _cat/allocation 的实际水位再决定包年规格。跳过前三步直接买包年，是这类项目最常见的返工原因。

新账号的注册与支付方式可参考 阿里云国际版注册教程，实例规格与地域的选择逻辑可参考 ECS 选购教程。

常见问题 FAQ

• Q: 阿里云国际版 Elasticsearch 有公开价格表吗？

A: 没有可抓取的公开价目页，官方计费文档只给计费项与计算公式，并注明价格随地域、规格、订阅时长变化，需在创建集群页面按实际配置查看。任何给出单一「$X/月起」的说法都只对某个地域某次报价成立。

• Q: 3.4 倍公式里的副本数怎么取？

A: 公式写的是 (1 + 副本数) × 1.7，官方算例用 1 个副本得 3.4。如果你配 2 个副本，系数变成 (1+2) × 1.7 = 5.1，磁盘要按 5.1 倍备，而不是 3.4 倍。

• Q: 加了主分片会不会更占磁盘？

A: 不会。加主分片只是把已有数据重新分布到更多分片，总量不变；只有加副本才会按副本数成比例增加占用。所以「单分片太大」的解法是加主分片，不是加副本。

• Q: 为什么我的 ILM 冷阶段一直不执行？

A: 三个常见原因：集群没开 warm 节点；分配规则里写成了 cold（托管版只认 hot/warm）；活动索引还在用旧版本策略，要等下一次 rollover 才切换。用 GET _cat/nodeattrs?v 和 GET _cat/shards/<index> 两条命令即可定位。

• Q: 数据节点买 2 vCPU 的能堆多少台？

A: 最多 10 台，因为单集群数据节点上限是单节点 vCPU × 5。想突破这个数量必须换更大的规格，这也是小规格机型不适合做日志集群的根本原因。

• Q: 国际站能买到弹性节点（Elastic Node）吗？

A: 购买页的数据节点配置区在国际站不提供节点规格族选项，也没有弹性节点区块。需要削峰只能靠 Auto Scaling 或提前预留规格。

⚠️ 免责声明：本文中提到的配置、价格和优惠信息可能随时间变化，请以阿里云国际版官网（alibabacloud.com）的实时信息为准。本文不构成任何投资或购买建议。注册前请确认当地法规合规性。

本文由 2.chengzicloud.cloud 提供，点击访问首页了解更多