慢速操作系统盘，快速数据盘

多年来，我发现人们往往在操作系统分区上倾向于采用高性能、高可靠性的数据存储，却为关键数据存储选择缓慢、“具成本效益”的存储。我惊讶于这种情况发生得如此频繁；而如今，随着虚拟机管理程序（hypervisor）的出现，我看到同样的行为在那里也再度上演–使原本就已存在的问题雪上加霜。

在如今的许多系统中，我们只需面对一个由系统所有组件共享的单一存储阵列。在这些情况下，我们不会面临存储系统性能配置失衡的问题。这是这种方法的一大优势，也是它备受推荐的一个主要原因。所有性能都汇集在一个共享池中，需要性能的组件都能访问到它。

在许多情况下，无论是出于提升性能或可靠性设计的尝试，还是出于技术上的必要，我发现人们会把他们的存储阵列分离开来，把虚拟机管理程序和操作系统放在一个阵列上，把数据放在另一个阵列上。但令我震惊的是，专门用于虚拟机管理程序或操作系统的阵列，其容量往往大得惊人，性能也极高–常常不惜重金动用 15,000 RPM 的磁轴，甚至固态硬盘。而且几乎总是采用 RAID 1（一如 1998 年的通行标准）。

这里需要理解的是，操作系统本身实际上几乎没有存储 IO 需求。是有一小部分，主要用于系统日志记录，但所需的也就仅此而已。操作系统分区几乎完全是静态的。所需的组件被加载到内存中，大多是在引导时加载，此后不会再被访问。即便在需要日志记录的情况下，这些日志许多时候也会被发送到一个集中式日志系统，而非发送到系统存储区域，从而也减少甚至消除了那部分需求。

对于虚拟机管理程序，这种效应甚至更为极端。由于虚拟机管理程序远比传统操作系统更轻量、更精简，它们的行为更像嵌入式系统，并且在许多情况下，实际上在很多时候它们本就是嵌入式系统。虚拟机管理程序在系统引导时加载到内存中，此后在系统运行期间，其介质几乎再也不会被用到，除了某些时候用于日志记录之外。由于虚拟机管理程序在物理尺寸上很小，即便在非常慢的介质上，把一个完整的虚拟机管理程序从存储中完整读取出来所需的总时间也非常短，因为其总大小非常小。

出于这些原因，存储性能对于操作系统、尤其是虚拟机管理程序而言几乎无足轻重。快速存储与慢速存储之间的差别，实际上只影响系统的引导时间，而一秒钟还是三十秒的差别很少会被察觉，甚至根本察觉不到。又有谁会在系统启动期间感知到哪怕多出来的几秒钟呢？而且在大多数情况下，启动是罕见的事件，最多一周发生一次，发生在计划内维护窗口期间一次自动化的例行系统重启时；对于那些只有在紧急情况下才会下线的系统而言，启动甚至更为罕见，有时几年才发生一次。即便是可以想见的最慢的存储系统，对于这一角色而言也远比所需的要快。

即便是慢速存储，对于系统日志记录活动而言通常也比所需的快上许多倍。在那些日志记录非常密集的罕见情况下，我们有许多办法来应对这一问题。这里最显而易见、也最常见的解决办法，是把日志发送到操作系统或虚拟机管理程序所用阵列之外的另一个硬盘阵列。这是一个非常简便的解决办法，并且在确有必要的情况下最终也非常实用。另一个常见且极为有用的解决办法，是干脆不在本地设备上保留日志，而是把它们发送到诸如 Splunk、Loggly 或 ELK 这样的远程日志收集工具。

大多数人围绕其操作系统和虚拟机管理程序所关心的另一大问题是可靠性。人们常常把更多精力放在保护系统中这些相对不重要的方面上，而非保护那些往往无可替代的数据。然而，操作系统和虚拟机管理程序在必要时很容易就能通过全新安装从零重建，并在必要时手动重新配置。那些可能丢失的细节，通常重新创建起来相对微不足道。

当然，这并不意味着这些系统文件系统不应被备份，它们当然应该被备份（在大多数情况下如此）。但即便备份也万一失败了，丢失一个操作系统分区或文件系统也很少真正意味着灾难，而仅仅是一种不便。在几乎所有情况下，只要“数据”文件系统是分开的，即便没有原始数据可用，也有办法恢复。而且由于操作系统和虚拟机管理程序的特性，变更很少发生，因此备份通常可以不那么频繁，甚至可能只在应用更新时才手动触发！

在 DevOps 和云计算领域的许多现代系统中，把操作系统和虚拟机管理程序文件系统视为完全可丢弃之物已变得非常普遍，因为它们是通过系统镜像或配置管理系统远程定义的。在这些日益普遍的情况下，无需进行数据保护或备份，因为整个系统从设计上就是要被几乎瞬时地、无需任何特殊交互地重新创建出来的。该系统完全能够自我复制。这进一步淡化了对系统文件系统加以保护的需要。

综合来看，对性能的需求之缺乏，以及对保护和可靠性的需求之缺乏（主要通过简单的重新创建来应对），我们所得到的，是一个其需求与我们通常所假设的大不相同的系统文件系统。这并不意味着我们就应当对自己的存储满不在乎，我们仍然想要避免在系统运行期间发生存储故障，而不必要的重建即便不至于酿成灾难，也是对时间和资源的浪费。因此，审慎地把握一种平衡很重要。

当然，正是出于这些原因，如今将操作系统或虚拟机管理程序与数据置于同一存储阵列上已成为常见做法–因为在访问数据文件的同时，几乎没有任何对系统文件进行存储访问的需要，所以我们能获得极好的协同效应：既为操作系统获得了快速的引导时间，又在系统上线之后对数据访问时间没有任何不利影响。这是当今系统设计者应对高效利用存储这一需求的主要手段。

当操作系统或虚拟机管理程序必须与存放数据的阵列分离开来时（这仍然可能由于种种原因而发生），我们通常会设法以较低的成本获得合理的可靠性。在使用传统存储（本地磁盘）时，这意味着为操作系统存储使用小型、慢速、低成本的旋转硬盘，通常采用简单的 RAID 1 配置。一个真实世界的例子，是使用尽可能小容量的 5400 RPM“环保型”SATA 硬盘。它们耗电少，购置起来也非常便宜。SSD 和高速 SAS 硬盘则会被避免，因为它们为无关紧要的保护和完全被浪费的性能付出了高昂的溢价。

在不那么传统的存储中，常见的做法是使用一个低成本、高密度的 SAN，把许多系统的低优先级存储整合到不进行复制的、共享的慢速阵列上。这只有在较大型的环境中才有效，因为这些环境才能够证明额外架构设计的合理性，并能在存储整合过程中达到足够的密度，从而创造出必要的成本节约；不过在较大型的环境中，这相对容易做到。SAN 引导设备可以跨众多服务器利用成本极低的阵列来节省成本。在虚拟领域，这可能意味着用一个低性能的数据存储来存放操作系统虚拟磁盘，再用另一个高性能的存储池来存放数据虚拟磁盘。这将产生与引导 SAN 策略相同的效果，但是在一种更现代的环境中，并且可以轻松地在底层借助 SAN 架构来实现它。

最后，也是最为引人注目的一点：对于虚拟机管理程序，有一条通用的经验法则，即把它们安装到 SD 卡或 USB 闪存盘上，而非传统存储上，因为它们对性能和可靠性的需求甚至比传统操作系统还要低得多。通常，如果这类驱动器在系统运行期间发生故障，系统实际上会毫无问题地继续运行，因为一旦系统最初引导完毕，该驱动器便再也不会被用到。只有在重启时才会发现问题，而到那时，可以使用一个备用引导设备，例如第二张 SD 卡或 USB 闪存盘。这是 VMware vSphere 的官方推荐做法，常常被 Microsoft 的代表针对 HyperV 推荐，并通过 HyperV 的 OEM 供应商获得官方支持；对于 Xen、XenServer 和 KVM 系统，它也常常被推荐，只是没有那么广泛地获得支持。为虚拟机管理程序存储使用 SD 卡或 USB 驱动器，实际上把一台虚拟化服务器变成了一个嵌入式系统。虽然这对于习惯把传统磁盘视为服务器必需品的系统管理员来说可能感觉不自然，但重要的是要记住，像路由器和交换机这样企业级的、极为关键的系统已经使用了数十年，它们出于完全相同的原因采用的正是这种完全相同的策略。

对于以这种使用 SD 卡或 USB 驱动器的嵌入式方式运行的虚拟机管理程序，一种常见的策略是配备两个这样的设备（实际上可能是一张 SD 卡和一个 USB 驱动器），每个上面都有一份虚拟机管理程序的副本。如果一个设备发生故障，引导到第二个设备几乎与传统的 RAID 1 系统一样有效。但与大多数传统的 RAID 1 配置不同，我们还有一种相对简便的方式来测试系统更新：每次只更新一个引导设备，在更新第二个引导设备之前先测试整个过程，从而在某次版本更新出岔子时，为我们留下一个可靠的、经过充分测试的回退方案。这一做法在大型 UNIX RISC 系统上其实很常见，那里的引导设备往往是支持类似实践的本地软件 RAID 1 集，在 AIX 和 Solaris 圈子里尤为常见。

还应当指出的是，虽然这种方法对于大多数虚拟机管理程序场景而言是最佳实践，但实际上没有任何理由说它不能同样应用于完整的操作系统文件系统，只不过往往工作量更大而已。某些操作系统，尤其是 Linux 和 BSD，非常擅长以嵌入式方式安装，只需稍加规划，便可轻松地适配为安装在 SD 卡或 USB 驱动器上。这种方法一点也不常见，但从技术上讲没有任何理由说在适当的情形下它不会是一种极佳的方法——唯一的例外是，几乎在任何时候都不应当把操作系统安装到物理硬件上，而应当安装在虚拟机管理程序之上。在那些确有必要进行物理安装的情况下，这种方法则极为可行。

在设计和规划存储系统时，请记得留意一个系统在运行时其读写模式实际上会是什么样子。并且请记住，自许多传统准则被制定以来，存储已经发生了相当剧烈的变化，用于制定这些准则的知识并非全部在今天仍然适用，或并非全部同等适用。不仅要思考哪些存储子系统会试图占用存储性能，还要思考它们将如何彼此交互（例如，两个系统是从不会在同一时间请求存储访问，还是会经常发生冲突），以及它们的访问性能是否重要。在一台数据库服务器上，通用的操作系统功能可以慢得出奇而不会带来负面影响，唯一重要的是数据库能被访问的速度。即便是对应用程序二进制文件的访问往往也无关紧要，因为它们同样在被加载到内存之后便驻留在那里，此后只有内存速度才会影响持续的性能。

所有这些都并非意在暗示把操作系统和数据存储子系统彼此分离是值得提倡的做法，事实上往往并非如此。我过去曾写到过，把这些子系统整合在一起常常是最佳的行动方案，这一点至今仍然成立。但也存在许多合理的情况，把某些存储需求彼此拆分是说得通的，这往往出现在处理大规模系统时——在那里我们可以通过把高成本存储专门用于某些需求、把低成本存储用于另一些需求来降低成本；而正是在那些情况下，我想要表明：除了在最极端的情形下，操作系统和虚拟机管理程序在性能和可靠性这两方面都应被视为最低优先级。