我今天正在与Rackspace技术支持人员讨论寻找一个基于负载来扩展/缩小服务器的简单解决方案，他说可以通过他们的API以编程方式完成。
之前有没有人真正这样做过，或者对如何最好地接近这个有任何建议？在我深入研究并从头开始重写之前，我很想知道是否有人有一些大纲代码或笔记。
谢谢！ 沃克
答案 0 :(得分：2)
Walker，我建议您开始准备服务器，然后使用监控解决方案触发的脚本启动和停止服务器。一旦您能够以自动方式始终如一地部署经过质量认证的服务器，您仍然需要大约15到20分钟来创建服务器。因此，无论哪种方式，您都需要在需要时准备好资源。
在您的召唤中拥有自己的服务器库时，是时候准备好您的监控解决方案了。 Nagios可以很好地完成这项任务。任何可以使用触发器等响应事件的监控解决方案都可以正常工作。
有几种方法可以扩展，了解如何管理利用率。
<强>利用
这对我们来说是独一无二的项目，它是每秒系统负载/请求+ IO的聚合度量。至少考虑负载平均值。在我们的场景中，我们想要了解是什么使我们的系统更加繁忙并制定了我们自己的利用率措施。我们将其插入自定义监控解决方案中。我们应该扩大或缩小时的利用率。
向上扩展
涉及扩展到更大的服务器以处理请求，它实际上意味着为了服务器请求您必须迁移到更大的服务器。或者另一种思考方式是，如果在更大的服务器上提供请求，则会降低请求的成本。
根据我的经验，在短期内缩小规模的需求会减少。如果 您始终需要最小规格服务器来处理负载 然后你应该看到平均利用率水平增长。一旦 利用率水平一直是开始时间的60％左右 扩大规模。
扩展可能会很昂贵，所以如果你的负载达到高峰，你可能最好只是将另一台服务器添加到池中，这就是 Scaling Out 的工作方式。
向外扩展
对于大多数项目，在短期内扩展更为常见，该过程涉及向环境添加更多主机并使用负载均衡器分发请求。当利用率达到60％或更高时，监控解决方案中的触发器会触发启动主机的请求。当负载返回中位数时，监控解决方案会关闭服务器。它应该是自动的，并且在切换服务器时应该增加利用率水平。我们尝试将40％的利用率作为环境的中位数。
复杂性是自动配置负载均衡器以查看新主机。我知道即使在服务器关闭后，只需预先配置平衡器即可使用健康测量的人。负载均衡器不会为死宿主提供流量。当服务器启动时，负载均衡器应该再次看到它并开始自动向服务器提供请求。
最终解决方案
部署最低可行环境并设置监控以监控自己的利用率。创建在所选环境中启动服务器的触发器。触发器应执行一个请求，该请求将触发对Rackspace的调用并启动服务器。这是一个好的开始。
希望这对你有所帮助，然后你继续建立一个成功的环境。