Question

Ian遭受过的一个特别痛苦的经历是一个集群化系统中的一系列查询陷入了停顿状态。最近的查询没有被消费，所以它们被堆积起来了。一些机器跑完了内存，所以它们的进程挂掉了。之前的查询正在被处理，但是没有把它们的结果传递给下一个队列，所以它们崩溃了。最后，第一个队列填充满了，但没有被消费，所以它崩溃掉了。然后我们为最终丢失了来自提供者的数据而付出了代价。你必须拟定出一些注意事项来考虑你的集群以各种各样的方式挂掉（不是如果它挂掉，而是当它挂掉的时候）以及会发生什么结果。你会丢失数据吗（这是个问题吗？）？你会有一个巨大的难以处理的积压任务吗？

有一个容易调试的系统可能胜过有一个更快的系统。工程时间以及失效时间的代价可能是你最大的开销（如果你正运行一个导弹防御程序，这就不恰当，但是对于一个创业公司来说是恰当的）。当传递消息时，与其使用一个低级的压缩的二进制协议来削减一些字节，不如使用人类可读的JSON文本。传递和解码消息的确增加了开销，但是当你剩下一个特别的数据库时，当一台核心计算机着火后，你就会庆幸当你努力把系统恢复上线时，你能够迅速读取出重要的信息。

确保花费少量时间和廉价的金钱来给系统部署升级——无论是操作系统升级还是你的软件新版本。每当集群中有任何改变时，如果它处于一个反复无常的状态，系统就会以一种古怪的方式来响应，你就会冒风险。确保你使用一个部署系统，类似于Fabric、Salt、Chef或Puppet，或者一个类似于Debian的.deb，RedHat的rmp或者类似于一个亚马逊机器镜像。能够健壮地部署一个升级整个集群的更新（在任何发现的问题上有报道）在困难期间大大减轻了压力。

正面报告是有用的。每天发一封邮件给某些人详述集群的性能。如果邮件没有找到，那就是一个有用的线索来告知发生了一些事情。你可能也想要其他的早期告警系统来更快地通知你，在这里，Pingdom和ServerDensity尤其有用。一个响应缺失事件的“死人开关”是另一个有用的备份（例如，死人的开关）。

把集群的健康状况报告给团队是很有用的。这可能是一个在web应用程序内部的管理页面，或者是一个独立的报告。Ganglia在这方面很给力。Ian看到了一个在办公室中的运行于一台多余PC上的类似于星际迷航中的LCARS的接口，当检测到问题时播出“红色警报”的声音——这对引起整个办公室的注意特别有效。我们已经看到了类似于老式风格的锅炉压力测量计的Arduinos驱动模拟设备（当指针移动时，发出美妙的声音！）显示出系统的负载。这种类型的报告是重要的，这样每个人就理解了“正常”和“这可能会破坏我们周五晚上的生活”之间的区别。