这里我指的是具有一定数量临时 SSD 存储的云服务器（来自任何供应商）。处理标准映像时，默认情况下，此临时 SSD 存储会被浪费且不会被利用。
在将 LAMP 堆栈部署到此类虚拟机上时，有哪些明显的方法可以利用临时 SSD 存储？
一个明显的例子是将交换文件和 /tmp 放在临时文件夹中。
还有什么是唾手可得的成果？这些事情太明显了，只有不称职的系统管理员才会错过？
答案1
/tmp和交换确实是显而易见的唾手可得的成果。
我认为，我能想到的任何其他东西都将是非常特定于应用程序的。
要么就是你和我都是同样不称职的系统管理员，因为我们都忽略了一些显而易见的事情。
临时存储是免费且快速的，并且在用户启动的实例重启后仍然存在，因此实际上，当启动实例或以其他方式从其来源获取时，任何最终“可丢弃”的东西都可以（自动）从其他地方（可能从代码存储库克隆或从存储在 S3 中的 tarball 中提取）暂存在那里。
当你完全“思考云”时，许多人会认为，许多或大多数服务器上的所有内容都应该是一次性的......我认为我们中的许多人或大多数人都认识到了这一趋势，但只是在我们前往那里的路上——我们还没有完全到达那里。
如果您的系统日志是远程收集的，您的本地系统日志可能会被转移到临时磁盘。当日志内容被认为不是特别有价值或您收集它们主要只是因为您可以时，网络服务器或代理日志也是如此。
说到“仅仅因为你可以”，有一个例子，我在物理数据中心有一台带有 SAN 阵列的旧服务器，里面有大量的静态资产，这些资产最终将被迁移到 S3。在此之前，除了定期备份外，文件还会同步到临时驱动器，在某些情况下，临时驱动器没有任何特别明确的用途。这些用作在线备用副本，如果发生灾难性事件，上线速度会比从备份中恢复快得多。
我们有一个应用程序，它每天两次从头开始（从其他来源）构建一个实质性的 SOLR 索引，然后将其推送到主服务器。这不是传统意义上的“临时”空间，但没错，它是在临时磁盘上构建的。
我想到了一个特定于应用程序的示例，即我的一个临时数据库服务器设置……它仅用于针对生产数据库的克隆测试代码。整个 MySQL 后备存储都位于临时磁盘上。我已经自定义了 initscript，因此“sudo service mysql resync”会停止 MySQL 服务器守护进程，将当前目录移开（使用文件名中的日期和时间重命名），复制（从 EBS）新安装的 MySQL 的后备存储，符号链接/usr/local/mysql/data到新的临时目录，启动 MySQL，获取生产数据库的实时副本，加载它……开发人员现在拥有一个与生产数据库相同的克隆……当然，它是一次性的，因为它立即“过时”并且仅用于测试代码。如果您从 AMI 启动其中一个新克隆，它会被唤醒并意识到它没有数据库，并立即获取主数据库的新副本。
另一种情况可能是集群数据库，其中所有节点都拥有所有数据的副本并作为法定人数运行（如 MariaDB Galera Cluster）。此类集群，尤其是在地理分布的情况下，在正常运行时需要适当选择（通常为奇数）节点数，因为作为一种保护措施，在隔离事件（分区）中，除非仍存在一个分区，其中包含发生拆分之前在线节点数的一半以上，否则整个集群将不可用。2 节点集群或 4 节点集群在从中间分裂时变得毫无用处，因为没有剩余的多数。有时使用“仲裁”节点来解决这个问题，该节点在法定人数中投票，但实际上没有数据的副本。它的全部存在就是为了让集群保持正常运行。更进一步，充分利用该节点上的临时存储，使其成为一个完整节点，为其提供完整的数据副本，而不仅仅是使其成为仲裁者。
一个可能有趣的想法是将临时卷与 EBS 卷组合成 RAID-1 配置。取决于您相信谁，同时读取多个文件时，读取 I/O 可能会增加近一倍。
我担心这个答案已经让我严重偏离了 DBA 的范畴，但在我的世界中，这些都是我使用临时卷来做的事情...除了您已经确定的显而易见的事情之外。