Google Cloud 磁盘类型怎么选，Persistent Disk、SSD 和不同存储方案有什么区别

在 Google Cloud 上部署网站、数据库、AI 工作负载或者数据分析系统时，很多人第一次面对存储配置都会产生一个很自然的问题：SSD、Persistent Disk、Local SSD、Cloud Storage、Filestore 到底有什么区别？

这些产品都可以被理解为“存储”，但它们解决的其实不是同一个问题。

有的属于块存储，有的属于对象存储，有的属于共享文件存储，还有一些专门为极低延迟和临时高速计算设计。真正选择存储方案时，不能只比较“SSD快不快”，而应该先问三个问题：应用需要什么访问方式，数据是否必须持久保存，以及有多少台计算实例需要同时访问这些数据。

Google Cloud 当前的持久化块存储主要包括 Persistent Disk 和 Hyperdisk；Local SSD 则属于临时块存储。Google 官方目前建议，在支持 Hyperdisk 的机器系列上优先考虑 Hyperdisk，而不支持 Hyperdisk 的情况下再根据工作负载选择 Persistent Disk。

Persistent Disk 可以理解为连接到 Compute Engine 虚拟机的持久化块设备。

它在操作系统看来很像一块普通硬盘。你可以在上面安装系统、创建文件系统、存放数据库文件，也可以把它从一台 VM 分离下来，再连接到另一台符合条件的 VM。

但它和传统服务器里的物理硬盘有一个重要区别：Persistent Disk 是网络连接的存储，而不是直接插在服务器 PCIe 总线上的实体 SSD。数据通过 Google 的网络基础设施访问，因此它和 Local SSD 的性能特征完全不同。

Persistent Disk 本身也不是只有一种类型。

常见类型包括 SSD Persistent Disk、Balanced Persistent Disk 和 Standard Persistent Disk。不同类型针对的是不同的性能与成本需求。

SSD Persistent Disk 面向需要较高随机 I/O 性能和较稳定吞吐能力的工作负载，例如数据库、企业应用、网站后台以及其他对磁盘响应速度比较敏感的程序。

Balanced Persistent Disk 则更强调性能和成本之间的平衡。对于很多普通 Web 应用、开发环境以及一般企业业务系统，它未必比 SSD Persistent Disk 差到需要用户明显感知的程度，却可能更适合控制整体成本。

Standard Persistent Disk 则主要面向成本敏感、顺序吞吐为主或者性能要求相对较低的工作负载。它并不是“坏硬盘”，而是针对不同工作负载进行的成本优化。

因此，不能简单地说“SSD 一定比 Balanced 好，所以所有服务器都应该使用 SSD”。如果数据库实际负载很低，为了理论上的最高 IOPS 支付更高成本，并不一定划算。

还有一个容易被忽略的特点：Persistent Disk 的性能与配置容量存在关系。Google 官方说明，Persistent Disk 的性能会随着配置容量变化，因此某些情况下，提高磁盘容量不仅是为了获得更多存储空间，也可能是为了获得更高的性能。Hyperdisk 则在这一点上更加灵活，可以将容量和性能更加独立地配置。

这也是 Hyperdisk 越来越重要的原因。

Hyperdisk 同样属于持久化块存储，但它针对高性能和更灵活的性能配置进行了设计。与 Persistent Disk 相比，Hyperdisk 可以更加独立地配置存储容量和性能，Google 也明确表示其 IOPS 和吞吐上限高于 Persistent Disk。

对于大型数据库、高性能计算、AI、数据分析以及对存储性能有较高要求的企业工作负载，Hyperdisk 往往比简单地选择 SSD Persistent Disk 更值得研究。具体能使用哪一种 Hyperdisk，还取决于 VM 的机器系列和工作负载。

如果说 Persistent Disk 和 Hyperdisk 是“持久保存的数据仓库”，那么 Local SSD 的思路完全不同。

Local SSD 是直接连接到承载虚拟机的物理服务器上的本地高速存储。由于数据访问路径更短，因此它能够提供非常低的延迟和很高的 I/O 性能。

但 Local SSD 最大的问题恰恰也是它最大的特点：它是临时存储。

Google 官方明确把 Local SSD 定位为临时块存储，并建议用于缓存、临时计算空间、高性能计算中的 scratch space，以及某些数据库的临时数据，例如 Microsoft SQL Server 的 tempdb。Local SSD 数据并不应该承担唯一的数据持久化责任。

所以，“Local SSD 比 Persistent Disk 快”并不意味着“数据库应该全部放在 Local SSD 上”。

更合理的架构通常是让持久化数据放在 Hyperdisk 或 Persistent Disk 上，而把 Local SSD 用作高速缓存、临时文件、排序空间、中间计算结果或者其他丢失后可以重新生成的数据。

这其实是云计算存储设计中非常重要的一个原则：高速不等于持久。

如果一份数据丢失以后无法恢复，那么它就不应该仅仅依赖 Local SSD。

Local SSD 的容量和可用方式也受到具体机器系列限制。传统 Local SSD 单个磁盘提供 375 GiB，新的 Titanium SSD 则是 Google 针对新一代机器系列推出的本地高速存储方案，不同机器系列支持情况并不一样。Local SSD 也不能像普通 Persistent Disk 那样随时添加到已经创建好的 VM；在很多情况下需要在创建实例时配置。

这意味着不能再用“Local SSD 一般只有375GB或者1TB”这种固定数字概括所有 Google Cloud 本地 SSD。具体容量和性能取决于机器系列以及使用的 Local SSD 类型。

接下来是完全不同的一类产品：Cloud Storage。

Cloud Storage 不是块存储，而是对象存储。

如果 Persistent Disk 像一块可以安装文件系统的硬盘，那么 Cloud Storage 更像一个巨大的对象仓库。应用程序把文件作为对象存进去，通过 API、SDK、命令行工具或者其他兼容方式进行访问。

因此，Cloud Storage 非常适合图片、视频、备份、日志、数据集、静态文件、归档数据以及机器学习训练数据等。

例如一个网站每天生成大量用户上传的视频，与其把所有视频都堆在 Web 服务器的 Persistent Disk 上，通常更合理的设计是将视频放进 Cloud Storage，Web 服务器和 CDN 只负责处理访问请求。

这种架构还能够让计算资源和数据存储解耦。

服务器增加或者减少不会导致用户上传的文件跟着服务器一起消失。

这也是为什么 Cloud Storage 和 Persistent Disk 并不是竞争关系。一个解决对象存储问题，一个解决块设备问题。

如果应用需要的是“多个 VM 同时访问同一个共享文件系统”，那么又是另外一个问题。

这时候 Filestore 更合适。

Filestore 是 Google Cloud 提供的托管文件存储服务，本质上提供共享的 NFS 文件系统。Compute Engine VM、GKE 等客户端可以通过网络挂载同一个文件共享，从而让多个计算实例同时访问文件。Google Cloud 当前的 Filestore 支持 NFSv3，并在部分服务层级提供 NFSv4.1。

例如一个媒体处理平台有几十台计算服务器，需要同时访问同一个素材目录；或者一个企业应用需要让多台服务器访问共享文件系统，这种情况下 Filestore 就比给每台 VM 各挂一块 Persistent Disk 更符合需求。

Filestore 也不是简单的“给 Persistent Disk 加一个 NFS”。

它是独立的托管文件服务，针对共享访问、文件系统语义以及不同级别的可用性和性能进行了设计。Google 当前提供 Zonal、Regional 等不同服务层级，其中 Regional 版本面向需要区域级韧性的关键业务。

因此，如果应用只是需要一台 VM 使用高速磁盘，没必要为了“共享”而上 Filestore；但如果多台 VM 必须同时读写同一个文件系统，Filestore 的价值就会明显体现出来。

还有一个非常常见的误区，是认为可以用 Persistent Disk 加 NFS 挂载来替代 Filestore。

技术上当然可以自己建立文件服务器，但这意味着你自己负责文件服务器的高可用、故障恢复、升级、容量管理和运维。Filestore 的价值就在于把这些基础设施管理工作交给 Google Cloud 的托管服务。

所以，实际选择时可以用一个非常简单的逻辑开始。

如果操作系统或者数据库需要一块“硬盘”，选择持久化块存储，也就是 Hyperdisk 或 Persistent Disk。

如果需要极低延迟的临时高速空间，考虑 Local SSD。

如果主要存放图片、视频、备份、数据集和归档文件，考虑 Cloud Storage。

如果多台 VM 或 GKE 工作负载需要共享一个文件系统，考虑 Filestore。

如果工作负载是数据库，那么还要进一步区分数据库类型和数据层。

例如 MySQL、PostgreSQL、SQL Server 等传统数据库通常需要块存储作为主要数据盘。对于普通数据库，可以从 Balanced Persistent Disk 或 SSD Persistent Disk 开始评估；大型、高性能数据库则可以进一步研究 Hyperdisk。Local SSD 可以用于临时数据、缓存或者数据库允许丢失后重建的高速工作区，但不应该把唯一的持久数据放在那里。

对于 Redis 这类以内存为核心的系统，Local SSD 可以用于临时数据和某些持久化策略中的高速工作空间，但具体是否适合还要根据 Redis 的持久化方式、恢复要求以及故障模型决定。

对于视频平台，通常不会把所有原始视频都放进 SSD Persistent Disk。视频文件更适合进入 Cloud Storage，数据库只保存元数据，而 CDN 负责向用户分发内容。

对于数据分析和 AI 工作负载，则经常会同时使用几种存储。

原始数据可以放在 Cloud Storage，计算实例启动以后将需要高速处理的数据放到 Hyperdisk 或 Local SSD，计算完成后把结果写回 Cloud Storage。这样可以避免让昂贵的高速存储承担所有长期数据。

备份和归档则更加明确。

数据库备份、服务器镜像、日志、历史文件以及长期保存的数据，通常应该考虑 Cloud Storage 等对象存储，而不是一直占用高性能块存储。

Google Cloud 的存储架构真正值得理解的地方，就是“容量、性能、访问方式和持久性”并不是一个指标。

一块非常快的 Local SSD，不代表它适合保存永久数据；一块容量巨大的 Persistent Disk，也不意味着它适合让几十台 VM 同时共享文件；Cloud Storage 可以保存海量对象，却不能简单地当成操作系统的本地硬盘；Filestore 可以让多台机器共享文件，却不应该被理解成数据库专用的块存储。

对于普通 Compute Engine 服务器，一个比较稳妥的思路是：操作系统和需要持久化的数据使用 Hyperdisk 或 Persistent Disk；需要高速临时空间时增加 Local SSD；用户上传的图片、视频和备份放进 Cloud Storage；只有真正存在多实例共享文件系统需求时，再考虑 Filestore。

而对于大型企业环境，则应该进一步考虑区域级高可用、快照和备份、灾难恢复、数据驻留、网络带宽、数据库 IOPS、吞吐量以及实际访问模式。

云存储的选择最终不是“SSD越快越好”，也不是“最便宜的磁盘最划算”。真正合理的方案，是让昂贵的高速存储只承担需要高速的部分，让便宜而持久的存储承担长期数据，让对象存储承担海量文件，让共享文件系统解决多机器协同访问。把不同类型的存储放在它们最擅长的位置，通常比给整个系统只选择一种“万能磁盘”更经济，也更容易扩展。

Google Cloud 当前的产品体系也说明了这一点：Persistent Disk 和 Hyperdisk 负责持久化块存储，Local SSD 负责高速临时存储，Cloud Storage 负责对象存储，Filestore 负责托管共享文件系统。理解这四种存储背后的访问模型，比记住某个产品的理论 IOPS 数字更加重要。