1. 从“一体机”到“云原生”为什么我们需要存算分离如果你用过或者管理过Elasticsearch集群尤其是那种数据量稍微大一点、业务波动又比较明显的场景大概率经历过这种“甜蜜的烦恼”为了应对某个大促活动你提前扩容了集群的节点数量CPU和内存都上去了性能是稳了但活动一过流量骤降这些昂贵的计算资源就闲置在那里账单却一分不少。或者反过来数据量增长太快磁盘眼看就要爆了你不得不紧急扩容节点但新节点加入后数据重新分布Shard Rebalancing的过程又可能引发性能抖动影响线上查询。这种计算资源CPU、内存和存储资源磁盘强耦合的架构我们戏称为“一体机”模式它在云时代显得越来越笨重和不经济。阿里云Elasticsearch推出的存算分离架构核心目的就是解决这个痛点。它的设计思路非常“云原生”把数据持久化存储这个“重资产”从计算节点中剥离出来放到一个独立、无限扩展、高可靠且成本更优的共享存储层即OpenStore。计算节点负责索引、查询的实例则变成无状态的它们通过高速网络访问共享存储里的数据。这样做就好比把家里的书房计算和图书馆存储分开。书房里只放你最近正在读的几本书热数据缓存所有藏书都存放在一个巨大的、管理完善的公共图书馆里。你需要哪本书随时可以去图书馆取书房的空间和配置可以根据你当前的工作强度灵活调整而不用担心藏书放不下。这种架构带来的直接好处就是标题里说的“更快、更稳、更省”。**“更快”体现在数据访问层OpenStore底层基于阿里云盘ESSD等高性能云盘构建提供高吞吐和低延迟的IO能力并且计算节点本地会有智能缓存Query Cache, File System Cache对热数据的访问速度堪比本地SSD。“更稳”是因为存储和计算解耦后计算节点的故障恢复、扩缩容不再需要大规模的数据搬迁分钟级甚至秒级就能完成业务几乎无感知存储层本身具备多副本冗余数据可靠性高达99.9999999999%(12个9)。“更省”**则是经济效益最直观的体现存储按实际使用量付费成本可比本地SSD降低50%以上计算资源可以独立地、按需地弹性伸缩在业务低峰期缩容节省成本在高峰来临前快速扩容保障性能实现真正的按使用付费。2. OpenStore存算分离背后的“定海神针”要实现存算分离那个独立出来的“图书馆”——共享存储层是关键。阿里云Elasticsearch的存算分离能力其核心基石就是OpenStore。它不是简单的把一个网络挂载盘如NFS给ES用而是一套为Elasticsearch深度定制、重新设计的存储引擎。2.1 OpenStore的架构设计哲学传统的Elasticsearch每个节点既是计算单元也是存储单元数据以分片Shard形式分布在各个节点的本地磁盘上。OpenStore彻底改变了这个范式。它构建了一个存储池所有索引的数据最终都持久化在这个池子里。计算节点即你购买的ES实例在本地只保留最近访问过的数据块缓存和写入缓冲区Translog。写入流程是这样的当数据写入一个存算分离的索引时首先会被写入计算节点的内存缓冲区并同步记录Translog以保证可靠性。随后数据会以追加写Append-Only的方式打包成一个个数据块Block通过高性能网络异步上传到OpenStore存储池。这种追加写模式避免了本地磁盘的随机写对HDD/SSD混合介质的存储池非常友好也是成本能大幅降低的原因之一。读取流程则充分利用了缓存查询请求到达某个计算节点该节点会先检查本地文件系统缓存中是否有需要的数据块。如果有缓存命中直接内存计算速度极快。如果没有缓存未命中则向OpenStore存储池发起读取请求将需要的数据块拉取到本地缓存起来再进行计算。由于查询的热点数据通常具有局部性经过一段时间“预热”后缓存命中率会很高查询性能就能接近本地SSD的水平。2.2 成本与性能的平衡术OpenStore能大幅降低成本秘诀在于其存储介质和数据组织方式。它通常采用ESSD AutoPL云盘或ESSD云盘作为存储底座但通过大规模集群的共享和数据的智能分层、压缩、去重将单GB的存储成本压得非常低。官方数据显示可比自建本地SSD存储成本降低50%以上。对于海量的日志、监控、归档类数据这个节省是极其可观的。有人会担心用成本更低的云盘性能会不会下降这里就体现了云服务的规模优势和技术优化。首先OpenStore存储池本身是分布式、多副本的聚合IOPS和吞吐能力远超单个本地盘。其次计算节点本地的智能缓存通常基于ESSD云盘或内存有效地屏蔽了后端存储的延迟保证了热数据访问性能。最后整个数据通路从计算节点到OpenStore都在阿里云内部的高性能网络上网络延迟极低且稳定。所以对于大多数查询场景用户感知到的性能差异很小但在存储成本和弹性能力上获得的收益是巨大的。注意OpenStore目前主要适用于日志、指标、归档等非实时性要求极高的分析型场景。对于写入吞吐要求极高如每秒数十万条写入或要求每次写入后立即查询近实时性的在线交易类场景存算分离架构在写入链路稍长可能需要结合索引生命周期管理ILM和冷热分层架构来设计。3. 弹性扩缩容从“搬砖”到“魔法”在传统集群中扩容是个“体力活”。加节点 - 数据迁移Rebalance- 等待平衡 - 可能引发性能波动。缩容更麻烦你得先确保要下线的节点上数据已经迁走。这个过程动辄小时级且期间集群状态可能不稳定。存算分离架构下弹性扩缩容变成了“魔术”。因为数据不在计算节点上所以计算节点的增减与数据位置无关。扩容场景假设“双11”前预测负载将翻倍。在控制台或通过API将你的Elasticsearch集群的数据节点数量从5个增加到10个。新节点启动后会自动加入到集群中并从负载均衡器Coordinating Node开始接收查询请求。由于它们访问的是同一份OpenStore中的数据不需要等待任何数据迁移扩容在几分钟内即可完成并立刻分担负载。你可以通过配置索引的index.routing.allocation.total_shards_per_node等参数更精细地控制分片在新老节点间的分布优化资源利用。缩容场景大促结束流量回归常态。你决定将数据节点从10个缩回5个。操作前系统或你需要手动将待下线节点上的分片副本标记为迁移实际上这些分片的数据实体一直在OpenStore里。Coordinating Node会将原本路由到待下线节点的查询请求平滑地切换到其他存活节点。因为不需要物理搬迁大量数据缩容可以在业务低峰期快速、平稳地完成缩掉的计算资源立即停止计费。**垂直扩缩容升降配**也变得异常灵活。如果一个节点的CPU或内存不足你可以直接对该节点进行变配如从8核32G升到16核64G。在存算分离架构下变配过程类似于重启一个节点并加载新的配置由于本地无持久化数据切换速度比传统架构快得多。这种弹性能力使得成本优化策略可以非常主动。你可以结合监控指标如CPU使用率、查询延迟和定时任务在每天的业务高峰前自动扩容在低谷期自动缩容实现“用多少算力付多少钱”的理想状态。4. 实战如何创建并使用一个存算分离集群理论说了这么多我们来点实际的。如何在阿里云上创建一个存算分离的Elasticsearch集群并享受它带来的弹性红利下面是一个从创建到配置的实操指南。4.1 集群创建与配置要点进入阿里云Elasticsearch控制台点击“创建集群”。在“配置模式”中选择“存算分离”。这是最关键的一步。你会发现实例规格的选择主要围绕计算资源CPU、内存而存储部分则单独配置为OpenStore。选择计算节点规格根据你的查询复杂度、并发量和数据量主要是热数据集大小来选择数据节点Data Node的规格。例如对于重度聚合分析的场景需要更多内存对于高并发简单查询可能需要更高的CPU核数。协调节点Coordinating Node和专有主节点Dedicated Master Node也需按需配置。配置OpenStore存储这里通常是按容量付费。你需要预估一个初始的存储容量。好消息是OpenStore容量是弹性扩展的你可以先设置一个初始值如1TB后续根据实际使用量会自动扩容无需中断服务。存储费用会按小时从你的账户扣除。网络与安全务必把集群创建在与你业务服务器相同的专有网络VPC内这是保证低延迟、安全访问的基础。同时配置好访问白名单IP或者安全组禁止公网直接暴露。完成创建提交订单通常10-20分钟一个全新的存算分离集群就创建好了。4.2 创建存算分离索引集群创建好后默认创建的索引仍然是“本地盘索引”即数据存储在计算节点本地。要使用存算分离的能力必须在创建索引时显式指定。你可以通过Kibana Dev Tools或任何ES客户端来创建这样一个索引PUT /my_openstore_index { settings: { index: { number_of_shards: 3, number_of_replicas: 1, store: { type: hybrid // 关键设置指定为混合存储即存算分离 } } }, mappings: { ... } // 你的字段映射定义 }这里store.type: hybrid就是这个索引的“魔法开关”告诉Elasticsearch将这个索引的数据持久化到OpenStore中。创建成功后向这个索引写入的数据就会遵循我们第二章描述的流程先写本地缓存和Translog再异步持久化到OpenStore。4.3 与索引生命周期管理ILM结合存算分离与Elasticsearch的**索引生命周期管理ILM**是天作之合。你可以定义一个完整的策略让数据在“热-温-冷”层间自动流转并充分利用不同层的成本优势。例如一个经典的日志管理策略热阶段Hot索引刚创建写入和查询频繁。可以让索引留在计算节点性能较好的本地SSD上store.type: fs这是默认值或者使用高性能规格的计算节点承载存算分离索引以获得最佳体验。温阶段Warm索引只读偶尔被查询。此时可以触发一个ILM动作将索引的store.type迁移到hybrid如果创建时不是的话并将索引迁移到成本更低的计算节点规格上。数据自动沉降到OpenStore计算资源降配节省成本。冷阶段Cold数据很少被查询主要用于归档合规。ILM策略可以将索引迁移到只挂载了超低成本存储如OpenStore的专用“冷节点”上或者直接收缩索引、强制合并段以进一步节省存储空间。查询虽然慢但成本极低。通过ILM你实现了成本和性能的自动化、精细化管控。在控制台可以方便地配置ILM策略并关联到你的索引模板上。5. 性能调优与避坑指南迁移到存算分离架构并不意味着可以“躺平”。为了获得最佳性价比有一些关键的调优点和“坑”需要注意。5.1 缓存是性能的生命线存算分离索引的查询性能极度依赖计算节点本地的文件系统缓存。如果缓存命中率低查询就需要频繁从OpenStore远程拉取数据延迟会明显增加。优化建议确保足够的内存给文件系统缓存Elasticsearch的JVM堆内存一般建议不超过系统总内存的50%。剩下的内存会由操作系统自动用于文件缓存。在购买计算节点规格时要保证有充足的非堆内存空间。例如一个32GB内存的节点堆内存可设16GB剩下的16GB就会用于缓存。合理设置分片大小和数量分片是缓存和并行化的基本单位。过大的分片如50GB可能导致缓存效率低下因为一次查询可能只需要其中一小部分数据却要加载整个大分片。过小的分片则会产生大量开销。对于存算分离索引建议将单个分片大小控制在20GB到50GB之间是一个较好的实践起点。预热常用索引在业务高峰期来临前可以主动对常用的查询模式如聚合的字段、过滤的条件发起一些“预热”查询让必要的数据块加载到缓存中。5.2 写入优化与Translog存算分离索引的写入路径比本地盘索引略长因为它多了一步网络持久化。虽然OpenStore的延迟很低但在极高并发写入场景下仍需关注。优化建议调整Translog持久化策略Translog保证了数据的可靠性。默认是每个请求都同步刷盘request。对于可容忍少量数据丢失的日志场景可以将其改为异步async并适当调大刷盘间隔sync_interval和大小阈值flush_threshold_size以提升写入吞吐。PUT /my_openstore_index/_settings { index.translog.durability: async, index.translog.sync_interval: 5s, index.translog.flush_threshold_size: 512mb }使用批量写入Bulk API这永远是提升ES写入效率的第一法则对存算分离索引同样重要。监控写入延迟密切关注indexing_latency等相关指标。如果发现写入延迟显著高于本地盘索引需要结合网络监控、计算节点负载和OpenStore的IOPS/吞吐限制进行排查。5.3 一个常见的“坑”索引恢复与速度当一个新的计算节点加入集群或者一个节点重启后它需要加载恢复分配给它的分片。对于存算分离索引这个恢复过程主要是从OpenStore下载分片的元数据和热点数据到本地缓存速度比传统架构下从其他节点复制整个分片数据要快得多。但是如果一次性有大量存算分离索引的分片需要恢复例如整个集群重启可能会对网络和OpenStore造成压力恢复速度会受限于集群级别的并发恢复设置cluster.routing.allocation.node_concurrent_recoveries。在紧急恢复场景下可以适当调大这个值以加速进程但需注意对正常业务查询可能造成的资源争用。5.4 监控与告警配置切换到存算分离架构后监控视角需要做一些补充核心监控项查询缓存命中率这是衡量性能健康度的关键指标。在Kibana或云监控中关注indices.request_cache.hit_count和miss_count。OpenStore读写延迟与吞吐通过阿里云云监控查看存储层的平均I/O延迟、读写带宽。计算节点资源CPU使用率、内存使用率尤其是非堆内存、网络流入流出带宽。分片状态确保没有未分配的分片。关键告警查询缓存命中率持续低于某个阈值如80%。平均查询延迟或写入延迟超过业务可接受范围。计算节点CPU或内存持续高位运行如80%这可能意味着需要扩容了。OpenStore存储使用量接近购买容量触发自动扩容预警。从我实际迁移和维护的几个大型日志集群的经验来看存算分离架构带来的运维复杂度的降低和成本的节约是实实在在的。最大的体会是它把我们从“容量规划”的焦虑中解放了出来。以前总要提前很久预测半年后的数据量然后申请机器资源现在只需要关注当前的计算资源是否够用存储则几乎可以视为“无限”的。弹性扩缩容从“手术”变成了“魔术”这让应对突发流量和进行成本优化实验变得非常轻松。当然它也不是银弹理解其原理做好缓存规划、索引设计和监控告警才能把这个“云原生”的利器用到极致。