本文档介绍如何从虚拟机实例访问永久性磁盘以及永久性磁盘复制过程。本文档还介绍永久性磁盘的核心基础架构。本文档适用于希望在系统中使用永久性磁盘的 Google Cloud 工程师和架构师。
永久性磁盘不是挂接到物理机器的本地磁盘，而是作为网络块存储设备挂接到虚拟机的网络服务。从永久性磁盘读取数据或者将数据写入永久性磁盘时，数据通过网络传输。永久性磁盘是一种网络存储设备，但它们在容量、灵活性和可靠性方面提供了许多用例和功能，而传统磁盘无法提供这些用例。
永久性磁盘和 Colossus
永久性磁盘设计为与 Google 的文件系统 Colossus 协同运行，该文件系统是一个分布式块存储系统。在将虚拟机上的数据从虚拟机传输到网络之前，永久性磁盘驱动程序会自动加密这些数据。然后，Colossus 将持续保存数据。当 Colossus 读取数据时，驱动程序将解密传入数据。
永久性磁盘使用 Colossus 作为存储后端。
在许多情况下，将磁盘用作服务非常有用，例如：
- 可以在虚拟机正在运行的情况下调整磁盘大小，比先停止虚拟机更容易。您无需停止虚拟机即可增加磁盘大小。
- 当磁盘和虚拟机不必共用同一生命周期或位于同一位置时，挂接和分离磁盘更容易。可以停止虚拟机并使用其永久性启动磁盘来启动另一个虚拟机。
- 高可用性功能（例如复制）变得更加简单，因为磁盘驱动程序可以隐藏复制详情并提供自动写入时复制功能。
磁盘延迟时间
您可以使用各种基准化分析工具来监控将磁盘用作网络服务的开销延迟时间。下面的示例使用的是 SCSI 磁盘接口（而非 NVMe 接口），并显示了从永久性磁盘执行 4 KiB 块读取的虚拟机输出。下面显示了您在读取中看到的延迟时间示例：
$ ioping -c 5 /dev/sda1
4 KiB <<< /dev/sda1 (block device 10.00 GiB): time=293.7 us (warmup)
4 KiB <<< /dev/sda1 (block device 10.00 GiB): time=330.0 us
4 KiB <<< /dev/sda1 (block device 10.00 GiB): time=278.1 us
4 KiB <<< /dev/sda1 (block device 10.00 GiB): time=307.7 us
4 KiB <<< /dev/sda1 (block device 10.00 GiB): time=310.1 us
--- /dev/sda1 (block device 10.00 GiB) ioping statistics ---
4 requests completed in 1.23 ms, 16 KiB read, 3.26 k iops, 12.7 MiB/s
generated 5 requests in 4.00 s, 20 KiB, 1 iops, 5.00 KiB/s
min/avg/max/mdev = 278.1 us / 306.5 us / 330.0 us / 18.6 us
Compute Engine 还允许您将本地 SSD 挂接到虚拟机，以应对您需要越快越好的过程的情况。在运行缓存服务器或运行具有中间输出的大型数据处理作业时，建议您选择本地 SSD。与永久性磁盘不同，本地 SSD 上的数据不是永久性的，因此虚拟机每次重启时都会清除数据。本地 SSD 只适合优化情况。
下面的输出是使用 NVMe 磁盘接口从本地 SSD 读取 4 KiB 的延迟时间示例：
$ ioping -c 5 /dev/nvme0n1
4 KiB <<< /dev/nvme0n1 (block device 375 GiB): time=245.3 us(warmup)
4 KiB <<< /dev/nvme0n1 (block device 375 GiB): time=252.3 us
4 KiB <<< /dev/nvme0n1 (block device 375 GiB): time=244.8 us
4 KiB <<< /dev/nvme0n1 (block device 375 GiB): time=289.5 us
4 KiB <<< /dev/nvme0n1 (block device 375 GiB): time=219.9 us
--- /dev/nvme0n1 (block device 375 GiB) ioping statistics ---
4 requests completed in 1.01 ms, 16 KiB read, 3.97 k iops, 15.5 MiB/s
generated 5 requests in 4.00 s, 20 KiB, 1 iops, 5.00 KiB/s
min/avg/max/mdev = 219.9 us / 251.6 us / 289.5 us / 25.0 us
复制
在创建新的 Persistent Disk 时，您可以在一个可用区中创建磁盘，也可以在同一区域内的两个可用区之间复制磁盘。
例如，如果您在可用区（例如 us-west1-a）中创建一个磁盘，则您将获得该磁盘的一个副本。这些区域称为可用区磁盘。您可以通过将磁盘的另一个副本存储在区域内的不同可用区（例如 us-west1-b）中来提高磁盘的可用性。
在同一区域中的两个可用区之间复制的磁盘称为区域级 Persistent Disk。
一个区域不太可能全都发生故障，但可用区级故障可能会发生。如下图所示，在区域内不同可用区中复制有助于提高可用性并缩短磁盘延迟时间。如果两个复制可用区都发生故障，则视为区域范围故障。
磁盘复制到两个可用区中。
在复制场景中，数据可在本地可用区 (us-west1-a) 中提供，该可用区是运行虚拟机的可用区。然后，数据会复制到另一个可用区 (us-west1-b) 中的另一个 Colossus 实例。至少有一个可用区应该是运行虚拟机的可用区。
请注意，永久性磁盘复制仅适用于磁盘的高可用性。可用区级中断还可能影响虚拟机或其他组件，这也可能会导致服务中断。
读取/写入序列
在确定读取/写入序列或者从磁盘读取数据/将数据写入磁盘的顺序时，大部分工作由虚拟机中的磁盘驱动程序完成。作为用户，您不必处理复制语义，并且可以照常与文件系统进行交互。底层驱动程序会处理读取和写入序列。
默认情况下，系统以完全复制模式运行，即从磁盘读取或写入磁盘的请求将发送到两个副本。
在完全复制模式下，会发生以下情况：
- 写入时，写入请求会尝试写入两个副本，并在两个写入都成功时确认。
- 读取时，虚拟机会向两个副本发送读取请求，并从成功的副本中返回结果。如果读取请求超时，则发送另一个读取请求。
如果副本落后且未能确认读取或写入请求已完成，则读写请求将不再发送到副本。副本必须经过协调过程，将其恢复到最新状态，复制才能继续。
后续步骤
- 了解如何配置磁盘以满足性能要求。
- 查看永久性磁盘快照最佳做法