guettli Asked: 2019-08-07 01:46:58 +0800 CST2019-08-07 01:46:58 +0800 CST 2019-08-07 01:46:58 +0800 CST 担心逻辑卷与物理卷不匹配 772 如果逻辑卷与这张图片中的物理卷不匹配，那么我担心可靠性会下降。 如果一个 PV 崩溃，几个 LV 会损坏。 像上图这样的布局是（尽管如此）最佳实践吗？ lvm 3 个回答 Voted Best Answer Sven 2019-08-07T02:09:30+08:002019-08-07T02:09:30+08:00 我假设您的目标是物理设备和逻辑卷之间没有 1:1 映射。 出于这个确切原因，我认为这是非常糟糕的做法：一个损坏的物理卷将杀死多个 LV。 通过将某种 RAID10/RAID6（软件或硬件）作为 LVM 的物理卷来缓解此问题。 注意：除非您格外小心，否则 LVM 在创建 LV 时不一定会考虑 PV 边界，即使是在线性模式下，并且当所有 LV 的大小正好是一个（或多个）底层 PV 的大小时。 John Mahowald 2019-08-07T04:39:32+08:002019-08-07T04:39:32+08:00 存在跨越 PV 的 LV 的用例。也许单个磁盘无法在单个卷中提供您需要的 IOPS 或容量。例如，云中块设备的配额。 这些情况往往是例外的。许多存储系统可以通过一个 LUN 满足您的所有需求。适合一个 PV 的 LV 是简单的情况，应尽可能使用。 所有 PV 都需要到位才能使 VG 上线。物理磁盘冗余往往处于较低级别，一些具有 RAID 风格冗余的阵列被分割成 LUN，形成你的 PV。 另外，我不会为 PV 分区而烦恼，只是增加了额外的步骤。使用整个磁盘，/dev/sd[be]。 关于 LV /dev/fileserver/backup，我不认为这是原始磁盘上的“备份”。发送到单独保护存储的临时快照，确保有意义。 Sum1sAdmin 2019-08-14T00:35:41+08:002019-08-14T00:35:41+08:00 任何单个物理卷总是单点故障，情况无关紧要。你完全依赖那个物理磁盘，它坏了，灾难接踵而至，它与 LVM 无关
我假设您的目标是物理设备和逻辑卷之间没有 1:1 映射。
出于这个确切原因，我认为这是非常糟糕的做法：一个损坏的物理卷将杀死多个 LV。
通过将某种 RAID10/RAID6（软件或硬件）作为 LVM 的物理卷来缓解此问题。
注意：除非您格外小心，否则 LVM 在创建 LV 时不一定会考虑 PV 边界，即使是在线性模式下，并且当所有 LV 的大小正好是一个（或多个）底层 PV 的大小时。
存在跨越 PV 的 LV 的用例。也许单个磁盘无法在单个卷中提供您需要的 IOPS 或容量。例如，云中块设备的配额。
这些情况往往是例外的。许多存储系统可以通过一个 LUN 满足您的所有需求。适合一个 PV 的 LV 是简单的情况，应尽可能使用。
所有 PV 都需要到位才能使 VG 上线。物理磁盘冗余往往处于较低级别，一些具有 RAID 风格冗余的阵列被分割成 LUN，形成你的 PV。
另外，我不会为 PV 分区而烦恼，只是增加了额外的步骤。使用整个磁盘，/dev/sd[be]。
关于 LV /dev/fileserver/backup，我不认为这是原始磁盘上的“备份”。发送到单独保护存储的临时快照，确保有意义。
任何单个物理卷总是单点故障，情况无关紧要。你完全依赖那个物理磁盘，它坏了，灾难接踵而至，它与 LVM 无关