因此,我即将开始部署一个复杂的基础设施作为多个高流量站点的托管环境。我将使用 ec2 作为服务器和 AWS 的其他不同服务。请看一下我的图表并给我一些建议。 AWS 基础设施图
有关此次部署的事实:
- 这些机器上托管的主要是 LAMP 或 LNMP(M 在 DB 服务器中)堆栈。
- 计划使用 GlusterFS 来确保所有节点都具有相同的负载均衡器信息。
- 原本计划在所有节点上使用 Ubuntu,但是对 CentOS 也比较熟悉。
- 使用各种价格的现货实例进行自动扩展。
- 最终将转向 Chef 或 Puppet 来管理所有这些,但我还不知道如何使用它。
- 将使用 nginx 作为代理或唯一的网络主机。
- 计划使用一个小实例作为主实例,一个微实例作为辅助节点。根据需求自动扩展。
- 我没有图片,但我计划在每个节点上使用复制的 EBS 卷
我有一些问题:
- 您发现我的设置存在什么问题吗?
- 我应该按照什么顺序运行/设置不同的组件和软件?
- 您是否认为,如果我正在考虑这种部署,那么从小型实例开始太小了(这意味着这是否太复杂了,我是否应该增加服务器功率)?基本上,我只想始终有服务器备份来处理负载等,我认为我可以通过集群节省一些钱。
- 还有其他建议吗?
我非常感谢大家提前提出的反馈。
编辑:我刚刚在亚马逊上发现了这张与我相似的图表(我想我模仿了某种类似的东西)。AWS 图表
答案1
这里唯一突出的是 glusterFS 的使用 - 您真的打算将应用程序数据(而不仅仅是静态内容和代码)存储为文件吗?如果不是,那么只需在部署时复制文件(rsync、unison 或直接 VC 签出)即可解决问题,而不会出现与集群文件系统相关的问题。虽然 EBS 确实简化了这一点,但它仍然成为系统的瓶颈。
另一方面,如果你真的将应用程序数据存储在文件中....那么怎么办?!!!PHP 没有像这样的设置上并发访问所需的复杂锁管理设施。
您计划处理多少流量?
答案2
设置看上去不错,只是我认为您可能有很多地方是在假设。
从一开始就使用 Puppet/Chef 之类的配置管理工具来构建您的基础设施。
正如@symcbean 所问,您实际上不需要 GlusterFS 来快速同步所有应用程序文件。Chef、puppet 等配置管理工具可以在几秒钟内设置应用程序的完整副本。
您真的不应该预先决定要使用哪种类型的实例。部署应用程序,然后运行一些性能测试并查看其响应情况,根据这些情况,您可能需要迁移到更高的实例类型。
请记住,您应该跨多个可用区域(亚马逊数据中心的术语)进行扩展以构建冗余。使用 ELB 之类的负载均衡器,它可以抵御区域故障。