如何为香港服务器的SSD缓存与大容量SATA分层存储规划容量？

香港服务器采用“SSD缓存层 + 大容量SATA存储层”时，容量规划不能只看硬盘总TB数。需要同时回答三个问题：业务高峰期有多少并发请求会触发存储访问，哪些数据需要低延迟响应，未来一段时间内主数据、快照和备份会增长到什么规模。

实际规划时，可先按“SSD负责高频访问和突发写入，SATA负责容量承载和长期保留”建立边界，再分别计算SSD的有效缓存容量、SATA的可用存储容量、冗余后的实际容量和扩容余量。SSD缓存只能改善部分请求的响应速度，不能替代主存储容量，也不能替代备份。

一、先把业务负载转换为存储需求

并发数不等于存储IOPS

并发用户数、请求数和存储IOPS是三个不同指标。

• 并发数表示同一时间处于处理过程中的请求数量。
• 请求量表示单位时间内进入应用或接口的请求数量。
• IOPS表示存储设备每秒完成的输入输出操作数量。
• 吞吐量表示单位时间内传输的数据量，通常以MB/s或GB/s表示。
• 延迟表示一次存储操作从发出到完成所需的时间。

一个页面请求可能只读取一条缓存数据，也可能同时触发多次数据库查询、日志写入和文件读取。因此，不能直接用“并发用户数 × 单次请求大小”推导SSD或SATA容量。

如果只需要估算存储处理压力，可先建立以下关系：

存储IOPS ≈ 每秒到达的业务请求数 × 每个业务请求触发的存储操作数

存储吞吐量 ≈ 每秒存储操作数 × 平均单次I/O大小

例如，在一个假设场景中，每秒有1,800次存储操作，平均每次I/O为16 KB，采用十进制单位计算：

• 总吞吐量：1,800 × 16 KB = 28,800 KB/s，约等于28.8 MB/s。
• 其中70%为读取，则读取吞吐量约为20.16 MB/s。
• 其中30%为写入，则写入吞吐量约为8.64 MB/s。
• 如果这些操作主要是4 KB随机I/O，即使总吞吐量只有7.2 MB/s，设备仍然需要处理1,800 IOPS。

这个例子说明，吞吐量不高并不代表SATA不会成为瓶颈。随机读写场景下，IOPS、平均延迟、队列长度通常比顺序吞吐量更值得关注。

需要收集的五类负载变量

容量规划至少需要整理以下变量。没有完整监控数据时，可以先以峰值估算，再通过上线后的监控结果修正。

同时，还要区分“逻辑数据量”和“物理占用量”。数据库表、文件系统和对象存储看到的容量，可能没有包含副本、校验、快照、日志、预留空间以及RAID冗余。

用峰值而不是平均值设计缓存层

SSD缓存最关心的是工作集，也就是在一个时间窗口内被反复访问的数据集合。

以下数据通常更可能进入SSD缓存：

• 最近访问的数据库索引和热点记录；
• 最近一段时间产生的订单、会话或交易数据；
• 高频读取的小文件；
• 网站首页、接口响应依赖的静态资源；
• 突发写入产生的日志、队列或临时文件。

以下数据通常不适合主要依赖SSD缓存：

• 长期不再访问的归档文件；
• 大量连续读取的视频、镜像或备份文件；
• 只写入一次、随后很少读取的大文件；
• 已经由应用层缓存或数据库内存池充分缓存的数据。

缓存容量应按照峰值工作集估算，而不是按照平均每天访问的数据量估算。否则，日常看似命中率正常，活动、批量任务或月末结算时就可能迅速把热数据挤出SSD。

二、SSD缓存层的容量计算方法

先区分三种缓存位置

同样叫“SSD缓存”，实际可能位于不同层级，容量含义也不同。

这三类缓存的容量不能简单相加。比如数据库已经把高频索引放在内存中，底层块缓存再次缓存同一批数据，增加SSD容量不一定能带来相同幅度的收益。

规划前需要确认缓存层是否支持以下能力：

• 只读缓存还是读写缓存；
• 写回缓存是否支持掉电保护；
• 是否能够正确处理文件系统或数据库的flush请求；
• 缓存失效、重建和更换SSD时是否影响主数据；
• 是否可以查看读命中率、写回积压、缓存脏数据和后端延迟；
• SSD故障时是降级运行、绕过缓存，还是会导致存储不可用。

读缓存容量的基本公式

可以使用以下方法估算SSD读缓存的有效容量：

SSD有效缓存容量 ≈ 峰值工作集 × 缓存波动系数 × 缓存管理预留

其中：

• 峰值工作集是高峰时间窗口内持续访问的数据规模；
• 缓存波动系数用于覆盖热点扩大、批量任务和访问模式变化；
• 缓存管理预留用于避免缓存接近100%占用后频繁淘汰。

在没有长期监控数据时，可以先采用以下参考区间：

• 热点稳定、数据访问规律：缓存波动系数可按1.1至1.2估算；
• 访问模式变化明显：可按1.2至1.5估算；
• 存在批量报表、活动流量或周期性任务：应以峰值工作集为基础单独增加突发余量。

缓存管理预留不宜让SSD长期运行在接近满载状态。实际规划时，可以把目标占用控制在缓存可用容量的70%至80%以内，具体还要看缓存软件的淘汰策略和监控结果。

写缓存需要单独计算

读缓存和写缓存不能使用同一套容量逻辑。

写缓存主要用于吸收短时间写入峰值，最终仍需要由SATA层完成持久化。如果业务持续写入速度高于SATA层的稳定落盘速度，SSD只是延后瓶颈出现，不能从根本上解决问题。

写缓存可按以下关系估算：

写缓存需求 ≈ 峰值写入速率 × 需要吸收的突发时间

例如，SATA层可以稳定写入80 MB/s，业务在高峰期产生120 MB/s写入，预计需要吸收10分钟的差值，则理论积压量为：

• 速率差：120 - 80 = 40 MB/s；
• 时间：10分钟 = 600秒；
• 积压数据：40 × 600 = 24,000 MB，约24 GB。

这只是理想的净积压量，还没有计算元数据、写放大、缓存管理和安全余量。实际配置时，需要确认缓存系统对脏数据的管理方式，并保留明显高于24 GB的空间。

如果采用写回缓存，必须重点核实：

• SSD是否具备适合写回场景的掉电保护；
• 控制器、主板或服务器是否有可靠的电源保护机制；
• 数据库同步写入是否能够得到真实持久化确认；
• 服务器重启、缓存设备故障和更换后的恢复流程；
• 缓存设备损坏时，未落盘数据是否可能丢失。

UPS只能减少突然断电风险，不能自动等同于SSD自身的掉电保护。对数据库、交易、账务和订单类数据，若无法确认写回缓存的持久化语义，优先选择写通模式，或将关键写入放到具备明确数据保护能力的存储层。

SSD容量不能只按当前热数据购买

下面用一组假设参数说明计算过程：

• 当前逻辑数据量：4 TB；
• 月度数据增长率：8%；
• 规划周期：12个月；
• 预计12个月后的工作集比例：18%；
• 高峰期工作集波动系数：1.3；
• 缓存管理和安全预留：25%。

先计算12个月后的逻辑数据量：

4 ×（1 + 8%）^12 ≈ 10.07 TB

再计算预计工作集：

10.07 × 18% ≈ 1.81 TB

计算峰值工作集：

1.81 × 1.3 ≈ 2.35 TB

最后加入缓存预留：

2.35 × 1.25 ≈ 2.94 TB

因此，该示例至少需要约3 TB的SSD有效缓存容量。若缓存设备需要镜像，原始SSD容量还要按镜像方式重新折算。例如，若采用两块同规格SSD做镜像，名义可用容量通常接近单块SSD容量，而不是两块容量相加。若需要约3.2 TB有效缓存容量，就应按镜像后的可用容量选择设备，并额外考虑热备盘、格式化损耗和缓存软件要求。

这个结果不是对具体服务器承载能力的保证。工作集比例、峰值波动和缓存命中率发生变化时，SSD容量仍需重新评估。

三、大容量SATA层的可用容量计算

主数据容量只是第一项

SATA层的规划容量至少包括以下部分：

SATA所需有效容量 = 主数据 + 索引与元数据 + 快照增量 + 本地保留副本 + 文件系统与运行预留

其中，快照不能简单按照“快照数量 × 主数据大小”计算。快照通常依赖写时复制或增量变化，实际占用取决于快照期间的数据变化量、删除量、覆盖量和保留周期。

本地备份是否计入SATA容量，也要先确定备份架构：

• 备份存放在独立备份服务器或对象存储中，可以不计入业务服务器的SATA主池；
• 备份暂存在同一台服务器上，则必须占用本地容量；
• 快照用于快速回滚，不能自动视为独立备份；
• 只有一份本地副本时，硬件冗余不能替代跨设备或异地备份。

预留运行空间比理论满容量更重要

SATA存储池不应长期运行到理论上限。需要预留空间用于：

• 文件系统元数据；
• 数据库扩展和日志；
• 快照增量；
• 磁盘替换和阵列重建；
• 临时文件和批处理结果；
• 未来增长期间的采购与交付时间。

对于持续增长的业务，可以将70%至80%的有效容量作为日常运行目标区间，将80%至85%作为需要安排扩容的区间。这个区间不是所有阵列和文件系统的固定规则，但比“等到容量接近100%再处理”更容易控制风险。

RAID冗余后再计算实际容量

SATA盘的标称容量是原始容量，不能直接当作业务可用容量。需要按阵列方式、热备盘、文件系统和预留比例逐层折算。

一个假设案例：

• 12个月后主数据：10.07 TB；
• 快照增量预算：2.0 TB；
• 索引、元数据及临时空间：0.3 TB；
• 目标日常占用率：70%。

业务需要承载的有效数据量为：

10.07 + 2.0 + 0.3 = 12.37 TB

考虑70%的目标占用率：

12.37 ÷ 70% ≈ 17.67 TB

也就是说，该场景至少应规划约18 TB的阵列有效容量，而不是购买18 TB原始硬盘容量。

继续看一个便于理解的阵列示例。若使用8块4 TB SATA盘组成双校验冗余阵列，原始容量为：

8 × 4 TB = 32 TB

在不考虑文件系统损耗、热备和其他保留的理想情况下，双校验冗余后的名义容量约为：

（8 - 2）× 4 TB = 24 TB

如果再按照70%的日常占用率运行，可用于稳定承载业务的容量约为：

24 × 70% = 16.8 TB

这低于前面的17.67 TB规划需求，因此可能需要增加盘数、提高单盘容量、调整快照保留策略，或将备份和归档迁移到独立存储。实际阵列可用容量还要以服务器控制器或软件存储层的实现为准。

香港服务器还要考虑备份传输窗口

香港服务器的本地存储容量规划，还会受到跨机房、跨区域或外部备份带宽的影响。如果备份无法在规定窗口内传输完成，就可能需要增加本地保留周期，从而扩大SATA容量。

按十进制单位计算，传输量和带宽的换算关系是：

传输时间（秒）= 数据量（GB）× 8 × 1000 ÷ 带宽（Mbps）

例如，200 GB增量备份通过200 Mbps链路传输：

200 × 8 × 1000 ÷ 200 = 8,000秒

8,000秒约为2.22小时。这是持续使用满带宽的理论时间，实际还会受到协议开销、加密、远端写入速度和网络波动影响。

如果需要传输10 TB全量数据，使用100 Mbps链路：

10,000 × 8 × 1000 ÷ 100 = 800,000秒

800,000秒约为9.26天。若备份窗口只有24小时，就不能只依赖100 Mbps链路完成全量传输，需要采用增量备份、压缩、专用备份链路或更大的本地保留空间。

需要注意十进制单位差异：1 GB按1,000 MB计算，而1 Gb等于1,000 Mb；硬盘容量的GB、TB与网络带宽的Gbps、Mbps不能混用。

四、根据瓶颈选择分层比例

读密集型业务：优先观察缓存命中率

如果业务以随机读为主，且热点数据相对稳定，可以采用较大的SSD读缓存配合大容量SATA。

适用特征包括：

• 读取请求明显高于写入请求；
• 热点数据集中在较小范围；
• SATA随机读延迟较高；
• SSD缓存命中后，应用响应时间明显改善；
• 读取数据不要求全部实时写回主存储。

这类场景中，SSD容量的重点不是覆盖全部数据，而是覆盖高峰工作集。若增加SSD后命中率没有提升，可能说明数据访问范围过于分散，或者应用层、数据库层已经存在更有效的缓存。

写入密集型业务：先验证落盘速度

如果业务有大量日志、交易记录、消息队列或批量导入，不能只看SSD能否短时间承受写入。

需要分别观察：

• 峰值写入速率；
• SATA层持续写入速率；
• SSD脏缓存占用；
• 后端刷新是否持续追赶；
• 写入延迟的P95和P99；
• 阵列重建期间的写入下降幅度。

如果SSD脏缓存只在短时突发期间上升，随后能够恢复到较低水平，说明缓存可能有效。如果脏缓存持续增长并最终接近上限，说明SATA后端的稳定写入能力不足。此时继续增加SSD，只会延长达到上限的时间，不能替代提升后端盘组、优化写入模式或拆分业务负载。

顺序读写型业务：不要盲目扩大SSD

大文件、备份、镜像、媒体文件和归档数据通常以顺序读写为主。此类业务的瓶颈可能是：

• SATA盘的顺序吞吐量；
• 阵列校验开销；
• 网络带宽；
• 文件服务器协议；
• CPU校验或压缩能力；
• 多任务并发读取造成的磁头寻道。

如果数据访问频率低、单次传输量大，SSD缓存可能很快被大文件占满，却没有明显提升后续命中率。应在缓存策略中限制大文件污染，或将归档、备份和热数据放到不同存储池。

数据库场景需要避免重复缓存

数据库可能同时使用：

• 数据库缓冲池；
• 操作系统页缓存；
• 存储层SSD缓存；
• 应用层对象缓存。

如果同一份热点数据在多个层重复保存，实际可用内存和SSD会被消耗，但延迟改善有限。规划时应明确每一层负责什么：

• 数据库内存优先保存高频数据页和索引；
• SSD缓存用于吸收数据库内存未覆盖的随机读，或改善后端盘延迟；
• SATA用于保存完整数据集和低频数据；
• 日志和数据文件可以根据写入特征拆分到不同设备或存储池。

五、三种常见分层方案及适用条件

读缓存型的容量建议

读缓存型通常可以从“高峰工作集”倒推SSD容量，而不是从SATA总容量倒推。例如，预计12个月后的主数据为10 TB，但高峰工作集只有2 TB，则SSD可先围绕2 TB至3 TB有效容量规划，再结合缓存命中率调整。

需要验收：

• 高峰期读命中率；
• SATA后端读取IOPS是否下降；
• 应用P95和P99延迟是否改善；
• 大文件读取是否造成缓存污染；
• 缓存失效后是否能够回退到SATA正常运行。

混合缓存型的容量建议

混合型方案需要把读缓存和写缓冲分开核算。SSD有效容量至少应满足：

读缓存目标容量 + 峰值写入积压容量 + 缓存管理预留

不能用“SSD总容量”直接代表写入安全空间。写回缓存还需要确认掉电保护和数据一致性。如果业务写入具有强一致性要求，应把缓存策略、数据库flush行为和服务器电源保护一起进行验收。

分离存储型的容量建议

如果关键数据库、日志或高频业务数据对延迟敏感，直接使用SSD作为主存储、SATA作为归档层，可能比在SATA前增加通用缓存更容易控制。

这类方案适用于：

• 关键数据集规模可控；
• 热数据与冷数据边界清晰；
• 应用或数据库能够指定数据文件位置；
• 能够分别监控SSD和SATA层；
• 不希望缓存策略在不同访问模式下频繁变化。

但分离存储并不意味着SSD上的数据天然更安全。SSD主存储仍然需要冗余、备份、健康监测和故障更换流程。

围绕热数据与长期数据分开承载的业务需求，A5数据提供香港SSD、NVMe服务器及大容量存储服务器产品。前者结合不同档位的CPU与内存资源，为数据库、高频业务数据提供计算与存储基础；香港存储系列则配备四块14TB企业级机械硬盘及H730控制器，面向大容量文件、备份和归档需求，为分离存储架构提供不同层级的资源选择。

六、把容量、性能和成本放在同一口径比较

不要只比较原始TB

两个方案即使都标称相同的原始容量，实际业务价值也可能不同。比较时至少要统一以下口径：

• 原始容量；
• RAID或副本后的名义可用容量；
• 目标运行占用率；
• 快照和本地备份是否计入；
• 热备盘是否占用；
• SSD缓存是单盘还是镜像；
• SSD是否支持适合写缓存的掉电保护；
• SSD持续写入耐久度；
• SATA盘组在随机访问和重建期间的表现；
• 后续扩容是否需要停机或迁移数据。

参考方案的容量结构

在不绑定具体型号和报价的情况下，可以用以下方式形成配置草案：

这些是容量推演的参考区间，不是特定服务器的实测承载结果。最终配置仍应使用业务峰值监控数据、实际I/O大小和存储层测试结果校正。

成本不只来自硬盘数量

混合存储的成本变量包括：

• SSD和SATA盘的原始容量；
• 镜像、双校验或多副本所需的冗余盘；
• 热备盘；
• 控制器或软件存储授权；
• 备份存储与跨区域传输；
• 机柜空间、电源和散热；
• 扩容时的数据迁移；
• 阵列重建期间的性能损失；
• SSD写入耐久度不足导致的更换周期。

如果业务数据增长快，初始购买更多SATA容量不一定比频繁迁移更贵。反过来，如果热数据规模小而长期数据增长快，过度配置SSD则会增加成本，却未必提升命中率。

七、交付和验收时分别核对SSD与SATA

SSD缓存层验收项

SSD缓存层应单独确认：

• 缓存有效容量与标称原始容量是否一致；
• 是否采用镜像或其他冗余方式；
• 读缓存、写缓存和写回策略是否符合设计；
• 写回模式下是否有可验证的掉电保护；
• 是否能够查看缓存命中率和脏数据量；
• 缓存设备故障时是否自动旁路或进入降级状态；
• 缓存重建是否会影响主存储可用性；
• 高峰期延迟是否按P95、P99分别记录；
• SSD健康度、温度和写入量是否纳入监控。

SATA容量层验收项

SATA层应分别核对：

• 原始容量、阵列后容量和文件系统可用容量；
• 实际数据占用达到70%或80%时的告警行为；
• RAID降级后是否仍能读写；
• 更换硬盘和重建过程是否有明确操作窗口；
• 重建期间的IOPS、吞吐量和延迟变化；
• 快照保留策略是否真正占用规划容量；
• 本地备份是否与业务主数据分开统计；
• 扩容时是否需要停机、迁移或重建存储池。

不要只在交付时查看“磁盘总容量”。应分别记录原始容量、阵列有效容量、文件系统容量、当前已用容量和预留容量，后续监控才能使用同一口径。

八、用监控数据确定扩容触发点

扩容触发点不应只设置一个“磁盘满了”的告警，而应同时观察容量、增长速度、性能和故障余量。

容量类指标

可以建立如下参考规则：

• SATA有效容量达到65%至70%：进入容量规划和采购评估；
• 达到75%至80%：安排扩容、迁移或清理策略；
• 达到85%以上：减少非必要快照和临时数据，优先处理扩容；
• SSD缓存长期超过80%且命中率没有继续提升：检查工作集是否超出设计范围；
• 写缓存脏数据持续上升且不能在低峰期恢复：优先处理后端落盘瓶颈。

这些阈值需要结合存储层的快照机制、阵列重建时间和供应交付周期调整。容量告警应使用连续时间窗口，避免单次批量任务导致误报。

性能类指标

SSD缓存是否有效，不能只看命中率。建议同时监控：

• 读命中率和写命中率；
• SATA后端实际读取IOPS；
• SATA后端实际写入吞吐；
• 设备平均延迟、P95和P99；
• 存储队列长度；
• SSD脏缓存占用；
• 阵列忙碌时间；
• 应用端请求延迟；
• 高峰期和低峰期的差异。

例如，缓存命中率从60%提升到80%，但应用P99延迟没有下降，可能说明瓶颈在数据库锁、CPU、网络或后端写入，而不在读取路径。反过来，命中率只有50%，但SATA读取压力较低，也不一定需要继续增加SSD。

用增长率倒推扩容时间

可以用当前可用余量和平均日增长量估算容量耗尽时间：

预计可用天数 ≈（扩容触发容量 - 当前已用容量）÷ 平均日增长量

例如：

• 当前已用容量：10 TB；
• 计划在80%占用时触发扩容；
• 有效容量：16 TB；
• 80%触发容量：12.8 TB；
• 近90天平均增长：每天0.03 TB。

可用余量为：

12.8 - 10 = 2.8 TB

预计触发时间为：

2.8 ÷ 0.03 ≈ 93天

如果服务器交付、迁移和验证需要45天，还应保留至少30天的安全窗口，那么这个方案已经接近扩容决策点，不能等到占用率达到80%后才开始采购。

以滚动周期替代单日数据

增长率最好采用滚动周期计算：

• 用近7天观察短期突发；
• 用近30天观察近期趋势；
• 用近90天判断长期增长；
• 对促销、月末、季末等周期性峰值单独建模。

如果近30天日增长量为0.03 TB，但近90天包含多个业务高峰，容量预测不应只使用0.03 TB。可以选择近90天平均值与高峰增长值中较高者，再加入增长波动系数。

SSD寿命也要纳入扩容计划

SSD容量足够，并不表示设备适合长期承受写入。需要监控：

• 主机累计写入量；
• SSD健康度；
• 剩余寿命指标；
• 温度；
• 写入放大；
• 磨损均衡；
• 错误计数和介质错误。

剩余寿命告警阈值应结合设备厂商给出的耐久度指标和实际写入曲线设置。若SSD主要承担写回缓存，应以主机写入量和高峰写入速率为依据，不能只根据容量使用率判断是否需要更换。

最终形成一张扩容决策表

可以按以下逻辑执行：

1. 每日采集SATA已用容量、SSD缓存占用、读写IOPS、吞吐量和延迟。
2. 每周计算近7天、30天和90天增长率。
3. 当容量预测在“采购周期 + 备用周期”内达到目标阈值时，启动扩容评估。
4. 当SATA后端延迟、队列或写回积压持续恶化时，先判断是缓存容量不足、盘组性能不足还是业务请求模式变化。
5. 当SSD命中率下降但热点数据规模没有明显增加时，检查大文件污染、缓存策略和数据库重复缓存。
6. 扩容后重新记录原始容量、冗余后容量、目标占用率和性能基线。

这样规划出来的香港服务器混合存储，不是简单地把一组SSD和一组SATA放在同一台机器中，而是让SSD容量、SATA容量、并发负载、增长速度和扩容周期相互匹配：SSD解决可识别的热点和突发，SATA承担经过冗余折算后的长期数据，监控则负责判断什么时候需要增加缓存、扩充盘组或调整分层边界。