0

我一直在仔细比较 Java PaaSes，并且真的开始喜欢 CloudBees。我对他们只有一个大问题，那就是他们的 SLA/正常运行时间。

在浏览了他们所有的文档之后，我只能找到他们提供的关于 SLA 的一篇论文，其中指出：

如果您在没有利用高可用性选项的情况下使用 CloudBees PaaS，则 CloudBees 只能提供接近基础设施云提供商的基本正常运行时间 SLA 的正常运行时间。

正如同一篇论文还提到的，亚马逊似乎提供了 99.95% 的正常运行时间，而且我知道 CloudBees 主要在 AWS/EC2 实例本身上运行。

因此，这产生了许多密切相关的 SLA 问题：

  1. 如果我不利用“高可用性”选项，那么我可以假设 CloudBees 甚至不能保证 99.95% 吗？或者其他地方是否有文档说明他们的正常运行时间是多少，以及未能满足正常运行时间的补救措施？
  2. 他们在这里谈论什么高可用性选项？我只是阅读了他们的整个开发者文档，从未看到任何关于 HA 的内容。
  3. 如果合作伙伴服务（例如用于邮件的 SendGrid 或用于缓存的 MemCachier）出现故障，我有什么补救措施？我喜欢 GAE 的一件事是CapabilitiesService，在您使用他们的电子邮件 API 或缓存 API 之前，您首先要与主服务器核对以CapabilitiesService确保这些服务正在运行。我想对 CloudBees 做同样的事情，但似乎我需要自己构建它。这很好，但不确定 CloudBees 是否甚至提供一种机制（API 调用等）来确定特定服务合作伙伴是在线还是离线。

提前致谢！

4

1 回答 1

2

  1. 如果一个月内未达到特定的正常运行时间水平，CloudBees 不提供可用性 SLA，也不提供积分形式的补救措施。这对于 AWS 上的其他产品（例如 Heroku）来说是常见的 AFAIK。CloudBees 确实通过支持协议提供基于标准响应时间的 SLA。正如您参考的白皮书中所讨论的，我们还为我们自己对 AWS 和外部提供商的使用采用了实践，这有助于将我们的用户与一些特定的 Amazon 问题隔离开来。

  2. 您可以使用的可用性功能包括：

    • 使用多个实例（并可能自动缩放）。应用程序实例由 CloudBees 分布在不同的 EC2 实例中，因此您可以避免在 EC2 实例发生故障时停机。
    • 使用会话存储。您可以使用我们的产品或合作伙伴产品（如 Memcachier）在与您的应用实例不同的层中共享会话状态。
    • 使用CloudBees 在多个 AWS 可用区中设置的专用服务器。
    • 确保与您的应用程序一起使用的数据库设置为高度可用的配置。例如，RDS 与 CloudBees 一起使用很简单，并且支持多个 AZ 中的备用和只读副本。
    • 使用来自 New Relic 和 AppDynamics 等合作伙伴的应用程序监控解决方案来提醒您任何问题。

    关于使用“高可用性选项”的评论的要点是警告人们，简单地在 CloudBees 上部署应用程序并不能使其具有高可用性。如果 EC2 实例在您的单实例部署下发生故障，您的用户将在我们的内部机器重新部署到工作实例时遇到停机时间，而在部署新实例之前，多实例部署可能只会遇到较慢的响应。与跨 AZ 没有备用数据库或副本的单实例数据库类似。虽然这只是说明对很多人来说显而易见的事情，但您可能会惊讶于有多少人只是假设一些魔法正在发生。

  3. CapabilitiesService 的好点子！我们在这方面有一些想法，但你现在必须自己做这样的事情。

于 2013-05-14T19:56:14.767 回答