在里面过去在物理服务器上，无论托管的应用程序多么简单，服务器始终至少有两个磁盘（卷）被认为是一种良好做法（至少在我工作过的地方）。
一个磁盘用于操作系统 (OS)，另一个磁盘用于应用程序。造成这种情况的原因如下：
- 如果应用程序通过填满磁盘或用 I/O 敲击磁盘而杀死了磁盘，您通常仍然可以登录并查看发生了什么，并且操作系统将能够继续记录事件以告诉您可能发生了什么。
- 它阻止操作系统通过争夺单个卷可用的 I/O 来影响应用程序的性能。
- 备份/恢复只需担心应用程序磁盘，因为操作系统可以重建。
- 可以管理应用程序磁盘（例如卸载），因为这不会影响操作系统。
默认情况下，云服务器只有一个磁盘。这让我想到这种多磁盘方法在云中是否仍然有意义？考虑到上述几点：（1）、（3）和（4）可能仍然适用，但（2）不太适用，因为磁盘是虚拟的：映射到云供应商以我看不到的方式管理的存储子系统上。
那么看起来这个最佳实践在云中仍然值得遵循吗？
或者我是否错过了为什么在云环境中使用多个卷并不那么重要的原因？
答案1
租用计算机作为服务不会显著改变使用单独数据磁盘的决定。
当然，您可以更改默认设置，否则为什么会存在用于创建和向实例添加额外磁盘的 API。
一个磁盘管理起来更简单。特别是对于相对静态的映像，其中实例是操作系统和应用程序安装，没有太多动态数据。
防止文件系统已满仍然很有用。尽管除了多个物理磁盘之外还有其他解决方案。使用 LVM 分离逻辑卷。或者集中日志记录或消息传递，以便某些实例没有不断增长的数据文件。
如果超出 IOPS 和大小的配额，则可能需要将多个磁盘组合成逻辑卷。（即使物理阵列仍然神秘，但至少配额在云中往往定义得很好。）存在扩展数据库。
单独的数据卷允许一些块级技巧。想象一下数据库实例的操作系统重大升级，但没有可复制到的辅助存储。准备一个升级的实例，但没有数据。在停机期间，卸载并分离数据卷，将它们呈现给新实例，然后安装。快速升级，无需复制数据，无需复制卷的第二份副本。