分享人：阿里云智能集团资深产品专家 彭亚雄（崆闻）
1.数据/大数据、AI/ML等关键工作负载在加速容器化
块存储技术对于开发者而言，就如同本地服务器上的一块硬盘般便捷。企业级客户历来习惯于从IBM、EMC等厂商处采购高端存储设备，这些设备通常配备有两个、四个乃至八个控制器，以满足大规模数据处理的需求。
步入当前的云原生时代，随着容器化微服务的蓬勃发展，云上的快速存储技术与传统的线下存储解决方案相比，正经历着显著的变化与进步。
当前，一个显著的趋势是，原本被视为IO密集型的应用正在迅速向加速容器化部署的方向转型。具体数据显示，K8S容器集群的增长速度极为迅猛，实现了超过127% 的增长率。此外，在AI负载领域，云上超过80%的AI负载采用了容器化部署，这一比例进一步证实了容器化技术在AI领域应用的广泛趋势。同时，当我们审视数据库及大数据领域时，可以清晰地看到，容器化部署已经成为云计算环境中不可或缺的一项基本选项。
另一方面，当客户积极采用Kubernetes并面临选型决策时，我们观察到，云上约有73%的客户倾向于选择云厂商提供的托管K8s发行版本。这一趋势表明，客户已经将容器环境节点管理、资源调度等职责委托给了云厂商。在此背景下，从EBS（Elastic Block Storage，弹性块存储）的角度出发，我们认为块存储与容器产品的集成度需要进一步加深。具体而言，我们应该从传统的块设备资源管理模式转变为基于K8s应用视角的数据服务模式，以更好地满足客户需求，并顺应技术发展的潮流。
在大背景下，我们可以清晰地观察到，无论是过去的repost阶段，还是现在的platform阶段，云上的块存储都展现出了对各类工作负载的强大支撑能力，确保了企业在云上迁移过程中的平稳与顺畅。
2.云原生时代，块存储面临挑战
在云上原生时代，我们需要与容器场景共同应对挑战，这包括使用界面的优化，即从资源维度提升至应用视角的应用界面和管理维度，以更好地匹配容器的细粒度算力分配以及大规模容器并发时的弹性扩展能力。在缓存AI大数据场景下，我们能否为客户提供一种除了本地快设备之外的、更为灵活的解耦选择，使得Port调度在大批量数据生成时能够更加自如地实现解耦。当面对云原生架构时，我们应考虑如何简化那些自诞生之初就生长在云上的应用，这可以基于云的多AG（Availability Zone，可用区）region服务高可用架构进行部署。最后，尽管微服务容器化部署的可观测性提升是一个长期的过程，但我们仍需不断探索和创新，以持续提升这一方面的能力。
3.面向云原生，企业级块存储核心能力
在迈向云原生时代的过程中，优秀的企业级块存储系统需要进行多方面的革新与优化。其应用模式与资源管理模式需要与Kubernetes实现深度集成，以确保资源供给能力能够紧密匹配并有效增强Kubernetes计算资源的供给效能，同时展现出强大的弹性伸缩能力。此外，该系统还应支持存储与计算的解耦，无论面对何种类型的工作负载，都能为云原生应用提供稳定且高可用的架构。在运维管理方面，强大的可观测性是不可或缺的，这被视为云原生时代企业级块存储系统核心竞争力的重要组成部分。
4.EBS和ACS容器计算服务深度集成，简化资源管理
正式推出商业化ACS容器服务后，在ACS商业化的初期阶段，EBS和ACS采用了深度集成模式。目前，用户可以在ACS上全系列地使用EBS的所有产品，包括从Auto PL到PL0/1/2/3等各种规格，均可自由选择。同时，用户还可以根据POD的不同规格类型来选择适合的磁盘类型。在使用过程中，通过插件和自定义的Storage Class，用户可以简化动态卷的创建过程，并自定义挂载和使用方式。
在创建MySQL Pod时，用户可以使用ACS中已经定义好的云盘存储类。如果根据需求，有不同的规格容量要求、云盘保存时间或扩容权限要求，用户可以自定义存储类，并设置样本文件以自定义生成。随后，在拉起MySQL Pod时，只需发起PV即可使用。而在销毁Pod时，用户可以根据存储类中定义的选项，选择与Pod一起销毁或单独保留作为持久化数据存储。
5.匹配容器细粒度资源使用模式，提供多种弹性扩展能力
除了在服务界面和资源管理上与ACS实现深度集成外，资源匹配也紧密对齐ACS与容器Pod的使用率。在云环境中，拉起的Pod最小规格为0.25核，相比之前拉起虚拟机时的2核或4核，有了显著的灵活性。同时，ESSD和P20的最小起步规格也从20GB降低到了1GB，这意味着可以拉起配置为0.25核、1GB内存或挂载1GB ESSD云盘的Pod来运行应用。在面临不可预期的业务压力时，快速拉起大量Pod能够支持系统的横向和纵向扩展。
在容器环境中，存在两种扩展模式，ESSD也提供了相应的支持。例如，单盘维度的容量可以从1GB在线扩容到64GB，同时IOPS，即输入/输出操作每秒可以根据业务负载自由设置在3000到100万之间。当需要在10分钟内快速拉起大量Pod以应对热点事件时，系统能够提供在单可用区内每分钟1万个Pod的并发启动能力，并且这种能力可以持续10分钟。
以微博为例，当有热点事件发生时，用户会纷纷打开微博查看热点，这经常导致微博因热点明星等事件而崩溃。但目前，微博崩溃的次数已经减少，用户查看热点事件也变得更加顺畅。这是因为微博在日常业务中使用了ECS（弹性计算服务），在弹性业务场景下则采用了容器实例（ECI）。微博将常用的容器镜像制作成快照，并从ECS快照中提前预热好环境。在需要时，可以从快照中快速创建多个ESSD来支撑ECI弹性容器实例的启动，包括未来对ACS的高并发启动能力的支持。目前，微博的常态弹性能力大约是每分钟启动1000台容器。
当前的技术上限是每分钟在单可用区内启动1万台Pod，团队希望越来越多的客户能够利用这一能力来抵御不可预期的业务洪峰。
Auto PL具备应对突发IO的能力，许多客户在使用后反响良好。然而，业务高峰期往往难以预测，如双十一和双十二等促销活动期间，客户更加关心如何应对流量高峰的问题。Auto PL能够在这方面提供帮助。另一方面，流量的增加会带来额外的费用，因此客户也希望能够有一种方式能够在承受流量的同时，对额外成本进行合理预期。
潮流电商行业往往追逐时尚潮流，而从事潮流服装行业的从业者普遍采用面向消费者的业务模式，即ToC业务。然而，在这个过程中，他们经常面临压力骤增的挑战。如果仅依据固定的预留性能水位来配置系统，可能会导致性能受损，进而使业务遭受全面冲击，并且费用支出也存在不可预测性。
为解决这一问题，引入费用封顶策略成为了一种有效的方案。应用这一策略后，电商企业在追求潮流的同时，能够更有效地管理成本，确保在面临压力时系统性能不会过度受损，业务运营也得以稳定进行。同时，费用支出也控制在可接受的范围内。右图展示了当前使用后云盘线上的真实情况。在某一小时内，这块云盘在第一分钟40秒时就出现了流量激增。当流量激增到一定程度后，会触发费用封顶机制。在触发费用封顶后，所有的激增流量将不再按照实际流量来收费，而是按照每小时固定费用计算，并且最多只需支付云盘费用的8倍。可以观察到，蓝色线代表的流量仍然在持续激增，但系统成功地扛住了这些流量，并且费用不会像流量那样变得不可预期。相比之前的模式，该小时内的费用从22元降低到了6元，下降了70%。
在用户面临不可预测的流量压力时，阿里云提供的burst能力结合其卓越的性能以及突发费用封顶功能，有效地保障了流量的平稳处理。此功能不仅能在流量激增时提供必要的支持，还将整体burst费用限制在一个完全可预期的固定范围内，从而确保了客户在费用方面的可预测性和稳定性。
从客户的角度来看，这一举措极大地增强了费用管理的透明度与可控性。无论流量规模大小，阿里云都致力于通过其强大的服务能力为客户的业务系统扩容争取更多宝贵的时间。这一承诺不仅适用于大型企业客户，也同样惠及小型客户。
阿里云为所有客户每小时免费提供高达10万个burst IO资源，以应对可能出现的短暂流量波动或轻微压力。即使是小规模客户，在面临突发流量时也能充分利用这一资源而无需担心额外的费用负担。
6.弹性临时盘，适配多款主售实例，灵活选择
弹性临时盘为大数据与AI缓存扩展场景下的客户，在原有本地盘的基础上提供了全新的选择。相较于以往，该盘现已适配当前全系列实例，使得CPU的选择变得更加灵活多样。对于大数据分析类的工作负载，客户可以选择按需添加一天的临时盘；而对于转码等其他类型的工作负载，则可以选择AMD实例来搭配临时盘使用，展现出极高的灵活性。此外，在不同应用场景下，弹性临时盘都能提供适宜的搭配方案。与此同时，相较于以往的扩展性、实例生命周期的解耦性以及可运维性，该方案均有了不同程度的优化与提升。
以下是一个具体案例的介绍：ClickHouse平台部署于云端，并采用了当前ECS Intel实例的存储增强型配置，同时搭配了弹性临时盘进行使用。在过去，为了应对ClickHouse的磁盘容量需求，用户需要根据实例规格进行选择，但这种选择方式受限于线性绑定模式，从而引发了一系列问题。具体而言，CPU资源存在大约60%的浪费现象——磁盘容量和性能需求仅相当于48核CPU，但用户却不得不配置128核CPU以满足实例规格的要求。然而，随着存储与计算解耦的实现，以及弹性临时盘与Intel、AMD及倚天系列实例的优化搭配，上述问题得到了有效解决。此外，用户现在还能够实现在线扩容，即随着业务需求的持续增长，可以灵活地扩展磁盘空间。这一改进相较于传统本地盘在磁盘空间耗尽后需要进行复杂迁移的情况，极大地提升了系统的可运维性和灵活性。
7.弹性临时盘，云上大数据平台临时数据存储新选择
在手机客户的应用场景中，大数据上云策略同样得到了采纳，而客户在本地部署时则选择了8代倚天服务器。倚天服务器在多个方面，如编译器和内核层面，进行了诸多优化，这些优化在计算侧能够带来超过15%的性能提升。同时，临时盘与710系列及Intel实例的搭配使用，在不同节点上提供了丰富的灵活选择。
整体而言，这样的配置不仅提升了扩容能力，还使得在线运维变得更加便捷。我们的团队致力于通过计算和存储在不同场景下的灵活搭配，为客户在本地盘之外提供更多样化的选择，从而助力客户在云上实现容器化部署时能够更高效地进行跨区资源的选择和调度。
8.为云原生应用架构所设计，Regional ESSD简化云上高可用部署
Regional ESSD已经进入了预览阶段，并将在杭州与香港两地面向早期客户开放预览。作为云上首款跨区级别的产品，Regional ESSD在单个可用区发生故障时，能够确保云盘服务的持续稳定运行。
接下来，我们介绍典型场景：数据库多AZ高可用、多AZ容灾。MySQL可以通过跨区域搭建储备实例，或者利用日志复制来实现同步、半同步或异步的数据传输，这取决于性能需求和对数据一致性容忍度的不同考量。在此模式下，通常需要在对端可用区部署常驻的备节点。然而，使用Regional ESSD时，无需在对端节点中部署常驻的计算节点。通过ECS容量预留的方式，可以轻松地预留资源，且成本相较于长期开启备节点的计算实例更为低廉。同时，Regional ESSD能够自动在多个区域间进行数据的强一致复制，从而简化了主备复制的管理复杂度，并解决了数据一致性问题。对于客户而言，整个架构因此变得更加简洁。当某个可用区发生故障时，只需在另一个区域启动对端的实例，并挂载即可进行读写操作。此外，整体存储成本和计算成本也会得到显著降低。Regional ESSD保留了原有单可用区的所有企业级特性，便于客户在关键业务场景和高可用场景中提升整个系统架构的韧性。
9.Cloud Lens for EBS全面提升云盘可观测性
在当今的云环境中，可观测性变得至关重要。随着容器化和微服务架构的普及，应用程序被拆分成更小的组件。在这种模式下，Cloud Lens for EBS 能够助力客户更有效地管理其底层存储资源。
Cloud Lens for EBS 引入了新的功能，增加了多项指标和事件监控。我们的团队将持续通过应用视角进行巡检，包括云盘事件通知和预配置建议，以帮助客户识别云盘的性能和安全性问题。这一功能有助于客户从应用层面，全面了解云盘使用的健康状况。
10.基于应用视角大规模和多维度云盘巡检
首先，我们基于应用视角提供了大规模、多维度的云盘巡检能力。以往，存储管理主要是从资源维度出发，关注地域、可用区内不同类型云盘的数量以及它们性能聚合后的表现。但现在，我们希望为客户提供从应用视角管理资源的新方式，即能够轻松地将云盘与已有的拍照标签关联到特定的业务系统中。这些业务系统可以是ES集群、Kafka集群或MySQL数据库等。
通过应用视角的数据聚合和异常分析，我们能够迅速定位这一组应用及其云上资源的负载使用情况。在负载中，我们能够识别出哪些情况需要发出告警、哪些问题需要优先处理、哪些配置需要优化以及哪些模式需要提升。此外，报告会自动周期性地生成，并给出相应的建议，帮助客户更好地管理其资源。
11.基于秒级监控，主动识别云盘使用过程中常见问题
当磁盘在一周内频繁接近或达到IOPS和吞吐量的上限时，即便未完全触达上限，实例也可能对整个云盘的性能产生不利影响。其中，预配置性能与burst性能之间的平衡往往难以把握。针对这些问题，我们提供的11种事件通知机制能够发挥关键作用。通过秒级监控，我们可以全面统计关键数据和事件，并设定定期告警配置，帮助客户更直观地了解自身的使用情况。
Auto PL 功能为用户提供了预配置性能建议，许多客户都倾向于利用 Auto PL 的 burst 能力。然而，在云环境中，相较于使用 burst 能力的客户数量，使用预配置能力的客户相对较少。这主要是因为客户往往难以准确判断某块磁盘所需的预配置性能水平，缺乏足够的数据支持相关配置和决策。
在云平台上，我们首先在启用 nest 功能的基础上，为用户提供 IOPS、bps 以及 burst IO的分析服务。我们会定期分析周期、IO模式及负载情况，并通过持续的特征提取和算法匹配，给出针对性的建议。这些建议包括是否应开启或关闭预配置能力、是否应调整其高低程度，以及如何与 burst 能力相配合，以实现最佳的经济效益。通过这种方式，我们旨在帮助客户在云平台上更加经济高效地利用性能资源。
诸多产品能力升级背后关键技术解读
分享人：阿里云智能集团存储产品线块存储负责人 朱家稷（满弓）
1.面向云原生场景，ESSD支持更高数量云盘挂载和并发访问
面向云原生场景，ESSD云盘进行了多项增强和优化，以适应容器技术和云原生技术的广泛应用趋势。对于后台服务中的单个计算节点和存储节点，需要能够挂载更多的云盘以提供更好的服务。为了实现支持更多云盘挂载和访问的目标，我们进行了以下工作：
首先，通过软硬一体优化，我们在CIPU上支持了更多的存储硬件队列。这使得更多数量的小盘也能够通过直通技术来加速数据读写路径。同时，我们需要在很短的时间内调度更多的云盘，以保证性能隔离和整个系统的服务质量（QoS）。
其次，我们优化了调度和隔离算法，以支持更多小盘的性能得到保证，与以前相比不降反升。此外，考虑到用户会随时创建、挂载或销毁更多的云盘，我们对云数据的管控路径进行了水平扩展能力的增强，以确保在随时需要弹性的场景下，系统能够得到更好的响应。
最后，在全链路上，我们对创建和挂载过程进行了并行优化，以降低整个端到端的时延。当前，我们的技术能力已经支持单个计算节点能够挂载并访问超过1000块云盘。同时，对于单个实例进行32个云盘的创建和挂载操作，整个平均时间小于三分钟。
这些优化措施使得ESSD云盘在云原生场景下更加高效、灵活和可靠。
2.面向云原生场景，ESSD加速镜像和快照高并发创盘启动
面向云原生的第二个优化场景，我们专注于通过镜像快照加速批量创盘和实地拉起的过程。首先，我们采用了Lazyload技术。当用户创建云盘后，云盘可以立即进行实时数据读写。同时，后台系统会并行地从OSS（对象存储服务）拉取相应的镜像和快照数据，这些数据会被条带化并打上伞，可能是指数据保护或校验机制，以提高效率。如果数据已经拉取到本地集群的高速缓存中，后续的读写操作就会命中缓存，从而实现加速访问。如果数据尚未在缓存中，系统会向OSS发送高优先级的数据请求，以快速完成数据获取。
在Block Server之后，我们增加了一层Cache Server，以确保在高并发、大批量读取的场景下，系统能够满足实时性能要求。此外，我们还采用了更先进的数据加速手段，可以将本地高性能缓存中的数据索引批量导入到Block Server中。这样，在访问数据时，就可以直接通过Block Server获取相应数据，而无需经过Cache Server进行中转，从而进一步提高了数据访问效率。
通过这些技术增强，我们优化了整个快照链路，包括云盘访问和链路共享能力，同时保证了多租户之间的隔离。
为了简化用户对数据保护方案的理解和实施，我们还支持云盘组一致性快照功能。用户可以对一组关联的计算实例和所有云盘进行一次性组快照。请求发送到后端后，快照服务会通知所有相关的Block Server。这些Block Server可能位于同一个集群内，也可能分散在不同的集群上，但它们会组成一个逻辑上的一致性组，并向后台的分布式时钟定序服务请求IO定序。通过后台的快照分布式一致性算法，我们可以确保云盘快照满足崩溃一致性要求。
同时，我们对算法的设计和实现进行了优化，以确保在IO定序和IO执行过程中可以并发进行，从而在快照期间对IO性能的影响几乎可以忽略不计。我们还优化了整个链路，使用户能够并发且频繁地创建快照。此外，快照可以在秒级内完成创建，并可用于创建新的云盘，从而满足用户在云原生场景下的可运营性要求。
3.Regional ESSD技术概览
了解Regional ESSD技术的增强特性，首先让我们概述一下Regional ESSD技术。Regional ESSD是基于盘古分布式存储架构设计的，该架构通过多AZ（可用区）数据布局和一致性读写技术，确保能够对单个可用区的故障进行容灾处理。同时，它支持在地区内的任意一个可用区进行挂载，并且具备共享挂载的能力。此外，Regional ESSD还提供了IO Fencing机制，以保障用户在进行访问切换时能够既快捷又安全。在性能和网络方面，Regional ESSD进行了优化，最大限度地保留了ESSD原有的性能优势，以满足用户对高并发和高吞吐量的需求。
4.Regional ESSD 数据布局保障高可靠高可用
具体来说，我们如何通过数据放置策略来满足高可靠性和高可用性的需求呢？首先，对于Regional ESSD云盘的LBA（逻辑块寻址）空间，我们进行了条带组的划分，每个条带组又由多个数据分段组成。这种方式不仅确保了性能和容量上的良好可扩展性，还使得整个Regional ESSD云盘能够分散在多个Block Server上，从而实现容量负载均衡和热点数据的分散处理。
在数据后端，分段数据会被存放在多个数据分块上。数据分块的好处在于它们能够进行动态映射，实时根据集群的运行状态来决定数据的读写位置。此外，我们还设计了一套机制，以实现节点级别的故障容错和快速切换。
最后，数据分片会被分散存储在多个AZ（可用区）的存储节点上。这一策略确保了即使某个AZ出现故障，数据仍然能够进行高可靠和高可用的访问，从而满足了用户对数据持久性和可用性的高要求。
5.Regional ESSD存储集群自动故障切换
了解Regional ESSD在遇到AZ（可用区）故障时如何进行容灾切换的过程如下：
首先，对于每个Regional ESSD集群，后台都部署有高可用感知服务（HA Service）。该服务会实时探测整个Regional ESSD的连通状态，并绘制出整个集群的拓扑连接图。当AZ1出现故障时，ha service会根据最新绘制的网络连接拓扑图来决定当前最优的切换方案。
对于管控服务来说，由于其基本上是无状态的，因此切换过程会比较快。而数据路径的切换则相对复杂一些。首先，需要隔离掉对AZ1的访问，将所有读写流量切换到AZ2和AZ3。同时，为了保证数据的可靠性，例如确保所有数据至少有三个副本，在新的方式下，这些副本会被分别存放在AZ2和AZ3中，尽管有些副本可能位于同一AZ下，但会确保整体数据的冗余度。完成数据切换和副本选择后，ha service还会持续感知AZ1的恢复状态。一旦AZ1恢复正常，系统会自动将数据路径和管控路径切回原先的状态，并自动将期间写入AZ2和AZ3的数据搬回到AZ1，以保证更高的可用性。
值得注意的是，后台存储服务的切换是自动进行的，用户无需感知这一过程。同时，前台为用户提供了IO Fence机制，以帮助用户更安全、快捷地进行访问切换。Regional ESSD支持两种访问模式：一种是独占挂载模式，即同一时刻只有计算实例能够访问这块云盘。在这种情况下，可以通过提供open API来开启该功能，让用户的新计算实例能够快速、安全地访问这块云盘。而假死的原实例则不会破坏数据的一致性。
对于共享挂载形式，用户在切换策略时需要协调各个节点的策略。我们的团队提供了相关的能力来满足标准协议的要求，以便用户能够更安全、快捷地进行访问切换。
6.ESSD可观测性大规模运维实践
在可运维性和可观测性方面的实践中，ESSD已在近百个可用区实现了大规模的销售和服务。面对如此庞大的后端运维挑战，我们对所有涉及ESSD的计算节点、网络节点和存储节点都进行了全面的数据运行采集覆盖。每天，我们能够采集到的可观测数据超过亿万条，这些数据支持对毫秒级精度的IO延迟进行诊断分析。
同时，我们的诊断分析系统会自动与日常巡检和监控告警系统联动，以确保服务的可持续性。通过CloudLens for EBS，我们将这些可观测指标推送到了用户侧，帮助用户更好地进行运维决策和实践。这样的实践不仅提升了我们的运维效率，也增强了用户对ESSD服务的信任度和满意度。
7.ESSD全链路IO性能诊断与恢复
以下是以IO链路检测和恢复场景为例，对ESSD技术的讲解：
ESSD是一项高度分布式的技术，其规模庞大且链路复杂。同时，它要保证正常的IO延迟在百微秒级别，这使得整个链路的延迟分析和诊断极具挑战性。
为了构建可运维、可诊断的能力，我们围绕提前发现、诊断分析、快速恢复这三个环节展开工作。我们利用线上多年积累的场景知识和不断丰富的智能检测算法，包括模型检测，并依赖于云间可扩展、高弹性的计算服务引擎进行实时诊断分析。同时，我们将诊断分析结果与预案精准联动，以帮助用户快速恢复。
以网络异常诊断为例，在云大规模机房的分布式节点结构中，网络问题的调查，包括延迟分析，通常极具挑战。问题可能源于端上网卡、交换机，甚至网络链路的配合。网络抖动往往会导致云盘延迟突然升高。通过我们的算法，我们可以快速定位并感知到受影响的云盘，找到热点，并发现它们属于同一台服务存储节点。接着，通过时空关联事件分析，我们会发现存储节点上相关网卡运行数据存在异常，包括输出异常日志。结合历史库中的沉淀积累，我们可以判断其置信度。一旦超过可信度阈值，系统会自动关联到恢复预案。例如，对网卡进行隔离、对服务节点进行隔离，或将服务迁移到其他节点上继续服务。对于大部分网络常见问题，我们可以在5分钟之内完成定位、诊断和自动恢复，从而更好地守护用户的数据服务质量。
