Google Cloud Persistent Disk 是什么，云服务器磁盘应该如何规划

很多刚开始使用 Google Cloud Compute Engine 的开发者，第一次创建虚拟机时都会遇到一个看似简单的问题：系统盘到底应该多大，数据盘应该选什么类型，数据库需要 SSD 还是普通磁盘，Local SSD 和 Persistent Disk 又有什么区别。

这个问题表面上是在选磁盘，实际上是在设计整个云服务器的数据存储架构。

Google Cloud 中的 Persistent Disk 是一种持久化块存储。它与虚拟机的计算资源相互独立，可以作为启动盘或者数据盘挂载到 Compute Engine 实例。它并不是直接插在物理服务器上的 SSD，而是由 Google Cloud 提供的网络连接块存储。数据分布在多个物理存储设备上，因此从虚拟机的角度看，它表现得像一块普通磁盘，但底层并不等同于传统服务器里的本地硬盘。

这种“计算与存储分离”的设计，是云计算非常重要的一个变化。虚拟机可以被删除、重建、迁移，而数据盘可以继续存在。需要更换虚拟机规格时，也不必把数据和计算环境绑死在同一台物理服务器上。

不过，到了今天，Google Cloud 的块存储已经不只是 Persistent Disk。Google Cloud 目前把 Hyperdisk 和 Persistent Disk 都归为持久化块存储，而 Local SSD 则属于临时块存储。对于支持 Hyperdisk 的新型机器系列，Google 官方建议优先考虑 Hyperdisk，因为它能够把容量和性能更加独立地进行配置；Persistent Disk 的性能则与配置容量存在更直接的关系。

所以，规划云服务器磁盘时，第一个问题不是“我要买多少 GB”，而应该是“我的数据需要持久保存，还是只是临时高速空间”。

如果数据必须在虚拟机停止、重启甚至删除之后继续存在，那么应该使用持久化存储。Persistent Disk 和 Hyperdisk 都属于这一类。

如果数据只是缓存、临时计算文件、中间结果或者数据库的临时工作空间，而且即使丢失也可以重新生成，那么 Local SSD 才可能更合适。Local SSD 直接连接到承载虚拟机的物理服务器，延迟和 IOPS 通常明显优于网络块存储，但它的核心特点也是“临时”。Google Cloud 明确建议把 Local SSD 用于 scratch data、缓存以及类似 SQL Server tempdb 的临时工作负载，而不能把它当成唯一的数据持久化位置。

这也是很多初学者容易犯的错误：看到 Local SSD 性能很高，就把数据库全部放进去。

如果数据库里的数据丢失以后需要从备份恢复，那么 Local SSD 可以作为高速缓存或者临时数据层，但不应该成为唯一的数据存储。比较合理的设计通常是把需要长期保存的数据放在 Persistent Disk 或 Hyperdisk 上，再把 Local SSD 用于缓存、临时排序、临时索引或者其他可以重新生成的数据。

Persistent Disk 本身也不是一个单一产品，而是包含不同性能等级的磁盘类型。常见选择包括 Balanced Persistent Disk、SSD Persistent Disk 和 Standard Persistent Disk。它们面对的是不同的性能与成本需求。Google Cloud 的文档也明确指出，Persistent Disk 的性能受到磁盘容量以及虚拟机本身性能上限等因素影响，因此不能简单理解成“同样 500GB，所有磁盘的性能都一样”。

对于普通网站、CMS、后台管理系统和一般应用服务器，Balanced Persistent Disk 往往是一个比较合理的起点。它并不是所谓“SSD 和 HDD 混合磁盘”，而是一种面向成本与性能平衡的持久化块存储类型。

如果数据库存在比较明显的随机读写压力，或者应用对 IOPS 和吞吐量有更高要求，可以考虑 SSD Persistent Disk；如果机器系列支持 Hyperdisk，则还应该进一步比较相应的 Hyperdisk 类型。Hyperdisk 的一个重要优势在于，可以更加独立地调整容量和性能，因此不必为了获得更多 IOPS 而单纯把磁盘容量不断扩大。

Standard Persistent Disk 则更适合性能要求相对较低、成本更加敏感的工作负载。它并不是“不能用于生产环境”，关键还是看应用的 I/O 模型。一个每天只有少量访问的内部系统，与高并发数据库，对磁盘的要求完全不同。

规划磁盘时，还需要把容量和性能分开考虑。

假设一个网站目前只有 80GB 数据，那么不能因为担心性能就直接创建 1TB 磁盘。对于 Persistent Disk，容量本身可能影响可获得的性能，因此需要结合实际 IOPS 和吞吐量需求计算，而不是单纯追求容量。

反过来，也不能只按照当前数据量创建一块刚好够用的磁盘。如果数据库现在占用 150GB，就创建 160GB，然后等磁盘满了再处理，运营风险会明显增加。数据库还需要考虑索引、临时空间、事务日志、备份文件以及未来增长。

真正应该关注的是几个指标：容量、IOPS、吞吐量、延迟以及数据增长速度。

例如，一个典型 MySQL 或 PostgreSQL 数据库可能更关心随机读写 IOPS 和延迟；视频处理系统可能更加关心连续读取和写入吞吐量；日志系统则可能同时受到持续写入、文件数量和存储增长速度影响。

还有一个容易被忽视的问题：磁盘性能不是只由磁盘决定。

Google Cloud 官方文档明确提醒，虚拟机实例本身也存在性能上限。如果 VM 的计算实例无法达到某个磁盘所要求的性能，那么单纯升级磁盘并不能让应用获得对应的实际吞吐量。

因此，一个数据库突然变慢，并不一定意味着“磁盘不够快”。CPU、内存、数据库缓存命中率、网络、锁竞争、查询设计以及应用程序本身，都可能成为瓶颈。

这也是为什么云服务器磁盘规划不能脱离整个系统来进行。

如果需要多台虚拟机共享同一个文件系统，那么 Persistent Disk 并不是最自然的选择。此时可以考虑 Filestore 等托管文件存储服务，或者根据业务需求采用其他共享文件系统方案。Persistent Disk 本质上是块存储，而 Cloud Storage 则属于对象存储，两者解决的问题完全不同。

Cloud Storage 更适合图片、视频、备份、日志归档、数据集以及其他对象文件。它不是传统意义上的“硬盘”，应用通过对象接口读写数据。对于长期保存、访问频率较低的数据，可以使用 Nearline、Coldline 或 Archive 等存储类别。Google Cloud 目前将 Nearline 定义为适合至少保存约 30 天的低频访问数据，Coldline 适合至少保存约 90 天的数据，而 Archive 更适合长期归档。

因此，一个比较合理的网站架构可能是这样的：操作系统使用持久化启动盘，数据库使用独立的数据盘，网站上传的图片和视频放到 Cloud Storage，数据库备份和长期归档也放到对象存储，而不是把所有东西都塞进虚拟机的一块磁盘。

这样做还有一个明显好处，就是不会让数据库磁盘同时承担大量图片、视频和备份文件的读写压力。

备份同样需要单独设计。

Persistent Disk 并不意味着数据天然不会丢失。持久化解决的是存储生命周期问题，而备份解决的是误删除、程序错误、数据损坏和灾难恢复问题。

Google Cloud 提供 Persistent Disk Snapshot，可以对 Persistent Disk 和 Hyperdisk 创建快照，并可以通过快照创建新的磁盘。Google 也提供快照计划，可以自动执行定期快照。

如果业务要求更高的可用性，还可以考虑 Regional Persistent Disk。它可以在同一个区域的两个可用区之间进行同步复制，适用于对区域内高可用有要求的工作负载。Google Cloud 同时提供跨区域异步复制能力，用于更大范围的灾难恢复。

这里需要特别纠正一个传统服务器思维：在 Compute Engine 中，不应该习惯性地给一块 Persistent Disk 再做 RAID 10，然后认为这样才安全。

云环境已经把很多底层存储冗余交给平台处理。Persistent Disk 本身的数据会分布到多个物理磁盘上。是否需要在操作系统层继续做 RAID，要看具体应用、性能目标和架构要求，而不是把物理服务器时代的 RAID 方案机械地复制到云上。

同样，不能把 Cloud Storage 的 Nearline 和 Coldline 称作“便宜的冷磁盘”。它们是对象存储类别，而不是 Compute Engine 可以直接格式化和挂载的块设备。这个区别非常重要。

假设一家企业运行一个中型数据库，数据库容量目前约 300GB，每天持续产生交易数据。比较合理的规划可能是使用 Balanced Persistent Disk 或适合该机器系列的 Hyperdisk，数据库和操作系统数据根据实际 I/O 需求进行分离；定期创建快照；数据库本身继续执行逻辑备份；重要备份再保存到 Cloud Storage。

如果是一套高速缓存系统，情况就完全不同。缓存数据即使全部丢失，也可以从数据库或者其他数据源重新建立，那么 Local SSD 就可能非常有价值。它的作用不是“永久保存数据”，而是用极低延迟换取更高的处理速度。

如果是一套大数据或者 AI 数据处理平台，则不应该简单地把 PB 级数据全部放在 NFS 或虚拟机磁盘中。原始数据、训练数据集和长期数据通常更适合放在 Cloud Storage，而计算节点需要的数据再根据访问模式进入高速缓存、Local SSD、Hyperdisk 或 Persistent Disk。这样才能把容量成本和计算性能分开优化。

最终可以把 Google Cloud 的存储选择理解成几个不同层次。

需要持久化块存储时，先看当前 Compute Engine 机器系列是否支持 Hyperdisk；支持的话，根据性能和可用性要求选择合适的 Hyperdisk。没有 Hyperdisk 或现有架构更适合 Persistent Disk，则在 Balanced、SSD、Standard 等类型之间选择。

需要临时高速空间时，再考虑 Local SSD。

需要保存大量图片、视频、备份、数据集和归档文件，则优先考虑 Cloud Storage，而不是不断扩大虚拟机磁盘。

需要多台计算节点共享文件系统，则考虑 Filestore 等文件存储。

这套思路比简单地问“SSD 还是 HDD”更加符合云计算的实际。

云服务器磁盘规划的核心，从来不是把磁盘买得越大越快，也不是看到 IOPS 数字很高就选择性能最强的产品。真正合理的设计，是让不同类型的数据进入最适合自己的存储层，让持久化、性能、可用性、备份和成本各自承担明确的责任。

对于一台普通 Compute Engine 服务器，一块 Persistent Disk 可以解决很多问题，但它并不应该成为整个存储架构的全部。随着业务增长，把数据库、对象文件、缓存、备份和灾难恢复逐步拆开，往往比单纯不断升级一块磁盘更加重要。