EC2上的Cassandra Datastax AMI - 从“停止”/“开始”恢复

Question

我们正在寻找在EC2上部署小型生产Cassandra集群（社区）的最佳方式。出于性能原因，所有建议都是为了避免使用EBS。

但是，当部署Datastax为AMI提供Ephemeral存储时，每当短暂存储被清除时，实例将永久死亡。 （手动启动+停止，或者有时由AWS进行维护触发）将使实例无法使用。 重启后，OpsCenter无法修复实例，实例无法自行恢复。

我希望实例能够自我启动，运行一些脚本来检测短暂的存储被擦除，并与群集同步。因为AMI看起来不适合开发任务。

任何人都可以帮助我们了解替代方案吗？由于复制，我们可以暂时丢失节点，但如果节点永远不会恢复并且需要新的集群，那么这对于生产环境来说似乎是一个死胡同。

1. 有没有办法在EC2上安装Cassandra，以便从短暂的存储丢失中恢复？

2. 如果我们购买企业版许可证，这个问题会消失吗？

3. 这是否意味着尽管性能不佳，使用PIOPS进行EBS（优化）是在AWS上运行Cassandra的最佳方式？

4. 建议是否只是为了避免停止+启动实例而希望 AWS不会退出或重新分配其主机？在这种情况下的建议是什么？

5. AWS滚动更新怎么样？升级一台机器（杀死它）并再次启动它，然后继续下一台机器将清除所有集群数据，因为机器将响应（与Cassandra不同）。这样它就可以破坏小型（例如3节点）集群。

6. 有没有人对Instacluster等付费服务有过良好的经验？

Answer 1

Datastax的新文档实际上表明，EBS Optimized GP2 SSD支持的实例可用于生产工作负载。通过EBS支持，您可以轻松地创建快照，从而消除节点上数据丢失的可能性，并使其通过简单的启动/停止轻松迁移到新主机。

短暂的，你基本上必须计划失败，考虑整个集群是否在一个区域（SimpleSnitch），并且该区域是否会崩溃。

http://docs.datastax.com/en/cassandra/3.x/cassandra/planning/planPlanningEC2.html