Google Cloud Z4D 存储优化实例：本地 SSD 扩至 84,000 GiB，如何评估数据库与搜索负载

预计阅读时间：11 分钟

Google Cloud 的新一代 Z4D 存储优化机型面向高 I/O、低延迟和大容量本地存储场景。Z4D 虚拟机已经正式可用；裸金属实例虽然属于同一产品组合，但根据当前开放状态仍处于预览阶段，需要联系客户团队确认区域与访问资格。

这次升级不只是增加几块 SSD。Z4D 将第五代 AMD EPYC（Turin）、Titanium 存储卸载能力、最高 400 Gbps 网络，以及最多 84,000 GiB 本地 SSD 放进同一实例，目标负载包括 SQL、NoSQL、KVrocks、向量数据库、Elasticsearch 类搜索系统、数据分析和分布式并行文件系统。

两类虚拟机，关键差异是每个 vCPU 对应多少本地 SSD

Z4D 虚拟机提供两种侧重点不同的类型，每种类型包含七种规格：

类型	本地 SSD 密度	更适合的工作负载
`Z4D-highmem-standardlssd`	219 GiB/vCPU	OLAP、MySQL、PostgreSQL 等 SQL 数据库
`Z4D-highmem-highlssd`	438 GiB/vCPU	分布式数据库、流处理、搜索、大型并行文件系统

整个系列最高可提供 384 个 vCPU、3,072 GiB 内存和 84,000 GiB 本地 SSD。与上一代 Z3 相比，官方给出的工作负载性能提升最高为 40%；本地 SSD 性能提升最高为 70%，随机读取最高达到 15,600K IOPS，顺序读取最高达到 75,600 MiB/s。写延迟最高降低 25%，混合读写 IOPS 最高提升 30%。

这些数字不能直接等同于应用性能。数据库的 WAL、检查点、压缩、索引写放大以及网络复制都会改变最终结果。客户测试也体现出明显差异：有的搜索与索引负载获得约 20% 至 50% 的吞吐提升，有的特定闪存负载提升更大。因此，选型时应使用自己的数据分布、读写比例和持久化策略进行验证，而不是只比较峰值 IOPS。

本地 SSD 很快，但不能把“本地”误当成“持久”

Z4D 使用 Titanium SSD，将部分本地存储处理从 CPU 卸载出去，减少存储路径对计算资源的占用。这对于数据库压缩、搜索索引构建和 AI 数据加载尤其有价值：CPU 可以更多地用于查询、编码或模型计算。

但本地 SSD 仍然与宿主机生命周期紧密相关。即使平台在特定计划维护事件中能够保留数据，也不应把单机本地盘当成唯一持久副本。可以按以下方式划分数据：

将搜索索引、缓存、临时 shuffle 文件和可重建数据放在本地 SSD。
数据库使用跨节点复制，并将备份、快照或归档放到独立持久存储。
把对象存储或 Hyperdisk 作为事实数据源，本地 SSD 作为热数据层。
对向量数据库验证索引是否可以从对象存储快速重建，以及重建期间是否仍能提供降级查询。

Z4D 同时支持 Hyperdisk Balanced、Hyperdisk Throughput 和 Hyperdisk Extreme，每个实例可挂载的 Hyperdisk 容量最高为 512 TiB。Balanced 最高可提供 320K IOPS；Extreme 在 Z4D 上最高可达 500K IOPS 和 12,500 MiB/s。实际架构不必在本地 SSD与网络块存储之间二选一：常见做法是把日志、元数据或权威数据放在 Hyperdisk，把索引和临时计算数据放在本地 SSD。

用自己的负载做一次可重复的 fio 基线测试

可以先查询当前项目可见的 Z4D 机型与所在区域。以下命令要求已经安装并登录 Google Cloud CLI：

gcloud compute machine-types list \
  --filter="name~'^z4d-'" \
  --format="table(name,zone,guestCpus,memoryMb)"

创建实例时可在控制台的 Storage-Optimized 机型族中选择 Z4D。具体规格和区域可能不同，因此自动化部署前应先执行上面的查询，而不要在模板中假定所有区域都有相同机型。

实例就绪并挂载本地 SSD 后，可以使用下面的脚本测试顺序写、随机读和 70/30 混合读写。运行前把 /mnt/localssd 改成实际挂载点，并确保至少有 25 GiB 可用空间。脚本只操作挂载点下的 z4d-fio-test.bin，但会产生高 I/O，禁止直接在承载生产流量的节点上运行。

sudo apt-get update
sudo apt-get install -y fio jq

cat > benchmark-z4d.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

MOUNT_POINT=${1:-/mnt/localssd}
SIZE=${2:-20G}
TEST_FILE=${MOUNT_POINT}/z4d-fio-test.bin

if ! mountpoint -q "$MOUNT_POINT"; then
  echo "Not a mount point: $MOUNT_POINT" >&2
  exit 1
fi

fio --name=prepare \
  --filename="$TEST_FILE" \
  --size="$SIZE" \
  --rw=write --bs=1M --direct=1 --iodepth=32 \
  --group_reporting

fio --name=randread \
  --filename="$TEST_FILE" \
  --size="$SIZE" \
  --rw=randread --bs=4k --direct=1 \
  --ioengine=libaio --iodepth=64 --numjobs=8 \
  --runtime=60 --time_based --group_reporting \
  --output-format=json --output=randread.json

fio --name=mixed \
  --filename="$TEST_FILE" \
  --size="$SIZE" \
  --rw=randrw --rwmixread=70 --bs=4k --direct=1 \
  --ioengine=libaio --iodepth=64 --numjobs=8 \
  --runtime=60 --time_based --group_reporting \
  --output-format=json --output=mixed.json

jq '.jobs[0] | {
  read_iops: .read.iops,
  read_bw_kib: .read.bw,
  read_p99_ns: .read.clat_ns.percentile["99.000000"],
  write_iops: .write.iops,
  write_bw_kib: .write.bw,
  write_p99_ns: .write.clat_ns.percentile["99.000000"]
}' randread.json mixed.json

rm -f "$TEST_FILE"
EOF

chmod +x benchmark-z4d.sh
sudo ./benchmark-z4d.sh /mnt/localssd 20G

不要只记录平均带宽。数据库和搜索系统通常更受 P99/P99.9 延迟、队列深度变化和混合读写抖动影响。建议在 Z3 与 Z4D 上使用相同镜像、文件系统、数据量和 fio 参数，至少运行三轮，并同时观察 CPU 利用率。Titanium 的价值之一正是减少存储处理占用的 CPU，因此“相同 IOPS 下节省了多少 CPU”也是重要指标。

维护行为会直接影响高可用设计

Z4D 会提前数天发出计划维护通知，但不同规格的处理方式并不相同：

本地 SSD 不超过 42,000 GiB 的 Z4D 虚拟机，可在维护期间进行实时迁移。
配置 84,000 GiB 本地 SSD 的虚拟机会被终止并重启，计划维护期间可保留数据。
Z4D 裸金属实例同样采用终止并重启的维护方式，并在计划维护流程中保留数据。

“保留数据”不等于“服务不中断”。84,000 GiB 规格和裸金属部署仍应把节点重启纳入容量规划：在一个节点离线时，剩余副本必须能够承担查询和写入流量。维护窗口还应与数据库再平衡、索引合并和备份任务错开，避免恢复阶段出现 I/O 峰值叠加。

裸金属的价值在于绕过虚拟化层，适用于极低延迟、定制虚拟机管理器和特殊许可证场景。它也可承载基于 microVM 的大量隔离沙箱，并计划支持基于 AMD 实例的 Nutanix Cloud Clusters。不过，如果应用没有明确的虚拟化开销、许可或隔离需求，虚拟机通常具有更简单的扩缩容与运维模型。

上线前的选型清单

采用 Z4D 前，可以用下面几个问题快速排除不匹配的方案：

数据丢失后能否从副本、Hyperdisk 或对象存储恢复？如果不能，不应只放在本地 SSD。
瓶颈究竟是存储、CPU 还是网络？只有 I/O 已经饱和时，更高的 SSD 密度才会转化为明显收益。
业务更需要 219 GiB/vCPU 还是 438 GiB/vCPU？按峰值容量选型可能造成大量闲置 CPU。
单节点维护时，集群是否仍满足延迟与吞吐目标？
基准测试是否覆盖真实块大小、读写比例、索引规模和 P99 延迟？
所需规格是否已在目标区域开放？裸金属当前还需要额外确认预览资格。

Z4D 最适合那些已经确认存储路径是核心瓶颈，并且能够通过复制或分层存储管理本地盘风险的系统。对于普通应用服务器，它可能只是昂贵的过度配置；对于大规模搜索、闪存型数据库和数据处理集群，它则有机会用更少节点提供更高吞吐。最终决策应基于应用级基准测试和完整 TCO，而不是单独追逐峰值 IOPS。