一个合适的例子可能是文件保存在单独的冗余EBS上 – 如果发生故障,将从预构建的AMI自动启动新实例,安装EBS卷,并无缝转换IP地址.
这可能吗？有比亚马逊更好的平台吗？你能否让我对我们正在讨论的基础架构有一个广泛的了解？
解决方法
亚马逊确实提供了实现目标所需的一些东西 – 并允许您实施其余的目标.
亚马逊的EC2服务器本质上是VPS – 您可以在它们上设置Heartbeat / Corosync / Pacemaker等(虽然上次我检查过,你不能在他们的网络上使用广播 – 你可以使用unicast – udpu).
你提到亚马逊分别解决的两个想法：容错和冗余.
EC2上没有内置的冗余机制,尽管取决于您要查找的内容,但有一些方法可以实现它.
>从理论上讲,S3设计有多层还原,“设计用于在给定年份内提供99.999999999% durability个物体”.他们的SLA是每年99.9% availability.如果要将该路由用于静态文件,可以使用s3fuse作为本地文件系统安装S3存储桶.然而,这相当慢,并且对于大多数目的(代码,数据库,服务器软件等)并不是真的可取.
> EBS快照将为您提供EBS卷的压缩差分时间点图像.这些作为备份非常棒 – 您可以从快照启动新实例 – 但它们不是真正的冗余.
>对于任何实际冗余的解决方案,您必须自己进行设置.为此问题设计的一种方法是GlusterFS.您可以将砖块设置为分布式,复制式或两者兼有,并且数据将分布在整个系统中 – 它对于删除单个节点具有弹性,并且它们具有预先构建的AMI,您可以从中启动多个实例来构建簇.
另一方面,容错性更好地由亚马逊平台提供：
> EC2网络提供多个区域和可用区域 – (理论上)提供隔离和/或地理上分离的数据中心,以避免单点故障
>亚马逊提供各种实例指标(cpu,网络,磁盘I / O等)的监控(Cloudwatch)以及自定义指标.这些可以用作从预构建的AMI启动新实例的触发器,这个过程称为“自动缩放”.
> EC2具有弹性IP地址 – 这些是可以保留的公共IP地址,并可根据需要快速重新映射到另一个实例,从而可以避免实例发生故障时DNS传播的延迟.
>最后,亚马逊拥有Elastic Load平衡器 – 这些平衡器应该被设计为避免单点故障,并且可以与传入流量进行扩展(它们不会受到与作为负载平衡器的单个实例设置相同的带宽限制)受制于). ELB能够监视后端实例的“运行状况”,并使用自动扩展来维护适当数量的实例.
除了上述内容之外,您还可以将自定义参数传递给新启动的实例,或者相当容易地检索有关当前运行实例的信息 – 这可能允许您编写一些设置脚本(当然,AWS确实有一个API将允许您编写它们提供的所有操作的脚本 – 包括重新映射弹性IP地址,启动新实例,分离/附加EBS卷等.
您描述’文件保存在单独的冗余EBS … [然后]已安装’.首先,在EC2上,EBS卷一次只能附加到一个实例(因此要将数据复制到它,需要附加EBS卷).由您来维护冗余(您可以设置EBS设备的RAID阵列,或者做其他任何事情).但问题是,当实例崩溃时,有时EBS卷不会分离 – 您可以强制分离它们(具有更好但不完美的成功率),并且即使在使用中也可以对EBS卷进行快照(其中然后,您可以使用创建新的EBS卷并启动AMI.但是,更好(恢复时间更短,更灵活等),以跨多个实例维护数据的副本,而不是跨同一实例上的多个EBS卷.
