如果您在两台服务器上提供服务以确保高可用性，那么最好以完全相同的方式配置它们，还是应该引入细微的差异以防止“异常配置”错误？
我们在 Linux（Ubuntu LTS）、Nginx、Apache 和 Python WSGI 堆栈上托管了一个基于 Django 的网站，这些网站在负载均衡器后面的三台服务器上重复。目前它们托管在亚马逊云中，但我们将来可能会迁移到自己的数据中心。我们最近在所有三台服务器上都遇到了一个问题，只能通过升级内核来解决，这让我们认为这是两者之间的不兼容性这个特定版本的内核和物理硬件亚马逊可能已经开始利用这一点了。
这让我开始思考：是不是让所有机器都保持完全相同的配置（更容易管理？）更好，或者我们应该保持稍有差异，这样两个组件之间的不兼容性只会在一台机器上表现出来，而不是所有机器上，让您的网站无法运行？
答案1
保持它们相同。出现仅在特定配置中表现出来的不兼容性的可能性很小，之后您必须记住所做的每件事之间的差异。
答案2
为了简单起见，它们都应该是相同的配置，但是在某些情况下（主要是由正在使用的软件决定），根本不可能实现负载平衡，而故障转移成为唯一的选择 - 在这种情况下可能需要稍微不同的配置。
另一方面，对于面向互联网的服务，可用性和安全性必须是优先考虑的事项。良好的安全性意味着定期应用补丁，良好的可用性意味着您不能同时修补所有设备 - 事实上，我为类似设置采用的做法是，一旦补丁可用，并在测试机器上应用并进行简要评估，就立即将其应用于一台实时机器，但将向其他节点的推出推迟几天，直到我知道补丁没有任何不利影响。
虽然 Sirex 是正确的 - 在完美的世界中 - 您会在预生产集群上实施补丁并使用来自生产系统的流量/数据进行测试 - 但实际上这在如此小的规模上远非成本效益。
答案3
是的，当然。这将有助于解决出现的问题。
使用 Puppet 来管理配置文件更改。我们会将配置文件存储在 svn 中，然后推送更改。我们有一个集中管理服务器，它会检查我们的更改，然后 Puppet 会推送这些更改。这提供了更改的历史记录，因此当您犯错时，您可以非常无缝地将其回滚，并且当您有多个管理员时，可以跟踪配置更改。