云原生存储高可用容器编排【免费下载链接】longhornCloud-Native distributed storage built on and for Kubernetes项目地址https://gitcode.com/gh_mirrors/lo/longhorn点击查看免费下载导读本篇文章围绕 Longhorn 的balance-aware副本调度增强设计展开讲解当副本需要落盘时调度器如何从总是挑选剩余空间最大的磁盘升级为先均衡节点、再均衡节点内磁盘的两级评分模型。文中完整梳理三种可选的均衡评分公式绝对可用容量、可用容量比率、加权混合、对应的决策树与数值演练示例并结合当前仓库的配置项与变更记录给出可验证的实现事实。读完本文你将理解 Longhorn 副本调度中候选磁盘如何被筛选、均衡分数如何计算、为什么值得采用两阶段选择并能据此解释集群中存储水位分布不均的成因与改进方向。背景与问题为什么最大剩余空间策略会失衡Longhorn 是构建在 Kubernetes 之上的云原生分布式块存储系统。当一个 Volume 需要创建或补充副本Replica时Longhorn Manager 中的调度器要负责在集群的节点和磁盘之间选择落盘位置。在引入本增强设计之前调度器的磁盘选择策略非常朴素总是选择可用存储空间usable storage最大的那块磁盘。其判定口径为Disk_Usable_Storage Disk.StorageAvailable - Disk.StorageReserved即可用容量减去为系统预留的容量。这种贪心策略的短期收益是尽量把数据放到当前最空的地方但长期来看会带来一系列问题跨节点存储使用不均衡同一 Volume 的多份副本会持续涌向剩余空间最大的节点导致部分节点磁盘几乎占满、部分节点长期空闲未来调度灵活性下降故障域风险集中副本过度集中在少数节点上一旦这些节点故障Volume 的冗余能力会被显著削弱难以应对异构磁盘只比较绝对剩余空间忽略了磁盘总容量大小的差异无法感知同一块盘用了百分之多少。本设计关联的增强提案文档为 enhancements/20251001-replica-balance-scheduling.md对应 GitHub Issue #10512正是针对上述问题提出的调度算法改进方案。该特性已在 Longhorn v1.11.0 中落地。仓库 CHANGELOG/CHANGELOG-1.11.0.md 的 General 一节明确记载Longhorn improves the disk selection for the replica scheduling by introducing an intelligentbalance-awarescheduling algorithm, reducing uneven storage usage across nodes and disks.即通过引入智能的均衡感知调度算法改进副本调度的磁盘选择降低节点与磁盘之间存储使用的不均衡程度。设计目标与非目标Goals目标引入balance-aware调度算法改进磁盘选择降低节点之间、节点内磁盘之间的存储使用不均衡程度提升存储容量的整体利用率改善故障容忍度与长期稳定性存储水位均匀未来调度空间更充裕。Non-goals非目标不追求完美的全局均衡调度。Longhorn 的副本调度本身是一个多约束问题涉及诸多前置因素Tag 匹配磁盘/节点标签副本反亲和性规则节点级、磁盘级、Zone 级节点/磁盘的就绪状态预留Reserved与超额配置Over-provisioned容量。本提案只改进通过上述过滤之后的磁盘选择阶段在所有合格eligible候选磁盘中用新的均衡感知方法挑出最均衡的那一个而不是重写整个调度流程。也就是说均衡评分是调度流水线的最后一公里先由既有约束把候选集收窄再用均衡分数排序择优。核心算法设计原算法最大可用存储Max Usable Storage原有选择的量化依据Disk_Usable_Storage (Disk.StorageAvailable - Disk.StorageReserved)数值越大越优先。该方法完全不考虑磁盘总容量与已调度容量只看绝对剩余空间。新公式族的三个候选方案提案给出了三组可替换的均衡评分公式均遵循分数越低分布越均衡的约定。公式 1按可用存储量的绝对均衡Balance Factor by Usable Storage首先修正可用存储的计算口径把已调度出去的容量也扣掉Disk_Usable_Storage (Disk.StorageAvailable - Disk.StorageReserved) - Disk.StorageScheduled然后对一组数值 X节点级或磁盘级的可用存储集合计算均衡分数$$\text{BalanceScore}(X) \frac{\max(X) - \min(X)}{\text{mean}(X)}$$其中X 各节点或各磁盘的可用存储值集合分子是最大值与最小值之差极差分母是均值分数越低说明集合内数值越接近即分布越均衡分数为 0 表示完全均衡。公式 2按可用容量比率的均衡Balance Factor by Usable Storage Ratio该方案引入总容量概念用可用比例代替绝对量Disk_Usable_Storage (Disk.StorageAvailable - Disk.StorageReserved) - Disk.StorageScheduled Disk_Total Disk.StorageMaximum - Disk.StorageReserved每个磁盘的可用率$$\text{usableRatio}(\text{disk}) \dfrac{\text{usable}(\text{disk})}{\text{totalCapacity}(\text{disk})}$$对一组可用率 X 计算均衡分数$$\text{BalanceScore}(X) \frac{\max(\text{usableRatio}(X)) - \min(\text{usableRatio}(X))}{\text{mean}(\text{usableRatio}(X))}$$其中X 各节点或各磁盘的可用率集合通过比率归一化天然兼容不同大小的磁盘避免绝对量口径下大磁盘永远占优的问题。公式 3加权混合Hybrid将绝对均衡分数与比率均衡分数加权组合$$\text{Score} \alpha \cdot \text{BalanceScore(Absolute)} (1 - \alpha) \cdot \text{BalanceScore(Ratio)}$$其中 $\alpha \in [0,1]$ 控制两者权衡$\alpha 1$只看绝对可用容量均衡$\alpha 0$只看可用率均衡$\alpha 0.5$等权混合。三种公式的对比文档给出如下对比表直观说明各方案的取舍公式优点缺点绝对可用容量Absolute Usable保证留有较大的绝对空闲空间避免空间不足out of space错误忽略磁盘尺寸差异可能导致各磁盘使用率非常不均衡会倾向选择大磁盘 A可用率Usable Ratio %对不同大小的异构磁盘公平使各盘使用率百分比趋齐可能过度偏向大磁盘减少小磁盘上的绝对余量会倾向选择小磁盘 B混合Hybrid 加权同时兼顾绝对量与比率α 可调计算更复杂需要明确默认 α 以免产生歧义当前选型结论注意当前实现采用第一个公式即 $\alpha 1$绝对可用容量口径。上述每个公式在不同场景下表现不同一般来说第一个公式适用于大多数场景。如果未来出现不同需求只需调整 α 即可轻松切换到其他公式。这是一个先落地、可演进的务实决策仓库当前版本v1.11.0 及后续默认按绝对可用容量做两阶段均衡同时把 α 机制保留在设计中为后续调优留出扩展位。决策树先均衡节点再均衡节点内磁盘整个磁盘选择过程遵循两级决策结构伪代码如下getDiskWithMostBalanceScore(candidateDisks, replicaSize) ├── compute usable/total storage maps │ ├── nodeUsableStorage / nodeTotalStorage │ └── diskUsableStorage / diskTotalStorage ├── selectBestNode │ ├── simulate placing replica on each node │ ├── computeHybridBalanceScore() │ │ ├── computeBalanceScoreFromUsableStorage() │ │ └── computeBalanceScoreFromUsableStorageRatio() │ └── pick node with lowest imbalance score ├── selectBestDisk │ ├── simulate placing replica on each disk (within best node) │ ├── computeHybridBalanceScore() │ └── pick disk with lowest imbalance score └── return bestDisk关键设计要点模拟放置simulate placing计算分数前先把假设副本已经放上去之后的容量变化模拟一遍再用更新后的容量集合打分。这保证了分数反映的是放置后的真实均衡状态而不是放置前的静态水位。节点优先第一级在节点维度上选择均衡分数最低的节点——这一步决定了副本落到哪个节点直接影响故障域分布。盘内次之第二级只在已选节点内部对候选磁盘再做同样的模拟打分选出该节点内最均衡的磁盘保证节点内的多磁盘之间也水位均匀。入口参数replicaSize是模拟扣减的副本体积用于精确更新可用容量。从源码结构看该伪代码中computeHybridBalanceScore()内部同时挂载了computeBalanceScoreFromUsableStorage()与computeBalanceScoreFromUsableStorageRatio()两个打分器与上文公式 1、公式 2 一一对应最终由computeHybridBalanceScore()按 α 加权合并——这一拆分方式让切换公式只需调整加权参数而无需改动选择流程骨架。数值演练两个完整示例示例场景 1绝对可用容量公式公式 1假设集群有两个节点每个节点有两块合格候选磁盘副本大小为 100 GiB节点磁盘可用存储GiBNode AA1900Node AA2100Node BB1600Node BB2700旧算法最大可用空间直接选 Disk A1900 GiB。放置前 Node A 合计 1000 GiB、Node B 合计 1300 GiB放置后 Disk A1 变为 800 GiBNode A 合计 900 GiBNode B 仍为 1300 GiB。两节点差距明显拉大900 vs 1300存储继续向 A 节点倾斜。新算法均衡优先分两步Step 1节点选择模拟放到 Node A新合计Node A (900 100) − 100 900Node B 1300节点均衡分 $$\text{BalanceScore}_{NodeA} \frac{1300 - 900}{\tfrac{1300 900}{2}} \frac{400}{1100} \approx 0.364$$模拟放到 Node B新合计Node A 1000Node B (600 700) − 100 1200节点均衡分 $$\text{BalanceScore}_{NodeB} \frac{1200 - 1000}{\tfrac{1200 1000}{2}} \frac{200}{1100} \approx 0.182$$0.182 0.364选择Node B分数更低 更均衡。Step 2磁盘选择在 Node B 内部模拟放到 B1600 → 500新磁盘可用 B1 500、B2 700 $$\text{BalanceScore} \frac{700 - 500}{\tfrac{700 500}{2}} \frac{200}{600} \approx 0.333$$模拟放到 B2700 → 600新磁盘可用 B1 600、B2 600 $$\text{BalanceScore} \frac{600 - 600}{\tfrac{600 600}{2}} \frac{0}{600} 0$$分数 0 表示 B1 与 B2 完全均衡最终选择Disk B2。这个例子清楚地展示了新旧算法的行为差异旧算法把副本堆到最大的 A1 上新算法则把副本放到能让全局节点间、盘间最均衡的 B2 上。示例场景 2异构磁盘下的三种公式对照节点磁盘可用存储GiB总容量GiB可用率Node AA1900100090%Node AA210020050%Node BB160080075%Node BB2700100070%在 Node B 内分别模拟放置到 B1、B2 后三种公式的得分对比放置位置绝对分数比率分数混合α0.5B11.4550.5871.021B21.4550.5821.019结论在该案例中无论采用哪种公式Disk B2 都是最优选择。同时也说明绝对分数对异构磁盘不敏感B1/B2 的绝对分数完全相同而比率分数与混合分数能够区分出细微差异——这正是设计可用率与混合公式的价值所在当绝对量口径分不出高下时比率视角可以提供额外的区分能力。与既有调度约束的协同关系需要强调均衡评分不是调度器的唯一决策依据它只作用于候选集形成之后的择优阶段。Longhorn 既有调度体系中的过滤条件包括Tag 匹配节点/磁盘标签nodeSelector / diskSelector与 Volume 或 StorageClass 上的标签要求匹配副本反亲和性包括节点级软反亲和replicaSoftAntiAffinity、磁盘级软反亲和replicaDiskSoftAntiAffinity、Zone 级软反亲和replicaZoneSoftAntiAffinity以及硬性反亲和规则节点/磁盘就绪状态与污点容忍预留容量与超额配置Reserved / Over-provisioning。上述约束的配置入口可见于 chart/README.md 的默认设置说明表例如defaultSettings.replicaAutoBalance发现可用节点时自动再均衡副本defaultSettings.replicaDiskSoftAntiAffinity允许在已有同一 Volume 健康副本的磁盘上继续调度默认启用defaultSettings.replicaSoftAntiAffinity允许在已有健康副本的节点上继续调度默认禁用defaultSettings.replicaZoneSoftAntiAffinity允许将新副本调度到与已有健康副本同 Zone 的节点。副本自动再均衡replica auto-balance的取值域在 chart/templates/crds.yaml 中定义为ignored、disabled、least-effort、best-effort四档Volume 层面还可通过 StorageClass 参数覆盖全局默认见 chart/templates/default-setting.yaml 中replica-auto-balance的渲染逻辑以及 deploy/longhorn.yaml 中longhorn-default-settingConfigMap 的实际形态。这些约束先把候选范围收窄balance-aware算法再在范围内做均衡择优二者是过滤 排序的分层关系而非互相替代。测试计划Test Plan增强提案为验证算法效果给出了一个可重复的验收实验文档原文的 Test plan准备两块大小分别为 40Gi 与 25Gi 的磁盘创建 8Gi 的 Volume副本数为 1重复创建同样的 8Gi / 1 副本 Volume共 4 次即步骤 25 各建一个检查副本分布情况与旧算法最大剩余空间的分布结果对比预期结果新算法的副本分布明显更均衡。该测试的价值在于用两块容量差异显著的磁盘40Gi vs 25Gi放大旧算法的倾轧效应连续放置 4 个副本后旧算法会倾向于把副本全部堆到大盘上而均衡算法应让两块盘的使用水位趋齐。这也是判断均衡感知是否真正生效的最小闭环实验。升级策略本增强不需要任何升级策略No upgrade strategy is needed。理由很直观这是调度器内部的择优算法替换不改变任何 CRD 结构、API 版本或存储数据格式不新增、不修改用户可见的设置项当前采用公式 1无需用户配置 α已存在 Volume 的数据与副本布局不受影响新算法只影响后续新调度的副本放置。升级后存量副本不会被动迁移均衡效果随新副本的创建新建 Volume、副本重建、自动再均衡触发逐步显现。总结balance-aware副本调度是 Longhorn 在存储利用率治理上的一次关键改进其核心思路可以概括为问题按最大剩余空间贪心选择磁盘会导致节点/磁盘间存储水位严重失衡方案以放置后模拟为手段用极差/均值的归一化分数度量均衡度先均衡节点、再均衡节点内磁盘公式提供绝对可用容量、可用率、加权混合三种可切换口径当前默认公式 1α 机制留作演进空间落地v1.11.0 已正式引入见 CHANGELOG-1.11.0.md无需升级迁移仅影响后续调度决策。对于运维 Longhorn 集群的工程师理解这套算法有助于解释为什么新副本没有落在剩余空间最大的盘上、预判集群存储水位演化趋势以及在需要时通过 α 机制参与后续策略演进。对于想深入源码的开发者可以沿本提案的决策树结构selectBestNode→selectBestDisk→computeHybridBalanceScore→ 两个基础打分函数在 Longhorn Manager 的调度模块中追踪实际实现。赞分享云原生存储高可用容器编排【免费下载链接】longhornCloud-Native distributed storage built on and for Kubernetes项目地址https://gitcode.com/gh_mirrors/lo/longhorn点击查看免费下载相关推荐Longhorn 副本驱逐Replica Eviction机制深度解析磁盘与节点级驱逐的设计、实现与运维实战Longhorn 副本驱逐Replica Eviction机制深度解析磁盘与节点级驱逐的设计、实现与运维实战 本篇技术指南围绕 Longhorn 增强提案云原生存储高可用容器编排Longhorn 副本自动再平衡Replica Auto Balance完全指南配置、原理与测试验证Longhorn 副本自动再平衡Replica Auto Balance完全指南配置、原理与测试验证 本篇技术指南以 Longhorn 仓库中的设计增强文云原生存储高可用容器编排Longhorn 磁盘级副本软反亲和Disk Anti-Affinity单节点多磁盘场景下的副本分散调度指南Longhorn 磁盘级副本软反亲和Disk Anti Affinity单节点多磁盘场景下的副本分散调度指南 导读 Longhorn 允许每个节点挂载多块云原生存储高可用容器编排上一篇Mars中的前端监控数据 retention策略存储与清理方案设计下一篇如何使用Gradle Docker插件快速构建和推送Docker镜像创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考