任务：
在Amazon上为EC2实例创建具有故障转移的UDP负载均衡器.
问题：
根据以下解释,我有以下问题：
> AWS EC2没有适用于IPv4和IPv6流量的公有DNS名称.
>无法将当前IPv6地址重新分配给另一个可用区中的新实例.
说明：
通过故障转移,我的意思是如果实例因任何原因而中断,请启动一个新实例并替换它.如果它所在的可用区域向下旋转另一个可用区域中的新实例并替换它.
使用弹性IP地址,我可以将现有的弹性IP地址重新分配给新实例,而不管其可用区域如何.
使用IPv6地址,如果在不同的可用区域中创建新实例,则无法重新分配现有IPv6地址,因为它不在同一子网中.根据可用区,我指的是亚马逊的可用区,例如us-west-2a,us-west-2b,us-west-2c等.
我知道如何解决这个问题的唯一方法是使用新的IPv6地址更新我的注册商(在我的情况下是Godaddy)的主机记录. Godaddy有一个API,我相信我可以通过编程方式更新我的主机记录.但是,Godaddy的最小TTL为600秒,这意味着基于传播,IPv6流量可能无法访问我的服务器10分钟或更长时间.
如果我只是正常的TCP流量,亚马逊有一个惊人的Load Balancer系统.如果是这种情况,这个问题就不存在了.由于我需要负载均衡UDP流量,我遇到了这个问题. AWS ELB(Amazon Elastic Load Balancer)为我提供了一个CNAME,我可以将所有流量指向TCP流量.所以我不需要担心IPv4和IPv6的单独流量.我可以直接将CNAME指向Amazon提供给ELB的DNS名称.
Amazon还为EC2提供公共DNS,但它仅适用于IPv4流量.这样可以用于我的IPv4流量,但不适用于我的IPv6流量.
我能想到的唯一选择是在EC2实例上设置基于软件的负载均衡器,在我的例子中是Nginx.然后将域指向Nginx负载均衡器的IPv4和IPv6地址.然后当区域崩溃时,我在另一个区域中启动新的AWS EC2实例.然后使用Godaddy的API将IPv6地址更新为新实例的IPv6地址.
请求
有没有人知道如何在没有AWS ELB的情况下将CNAME分配给EC2实例？该实例需要能够在CNAME处接收IPv4和IPv6流量.
我能想到的唯一方法是,由于我的域名注册商的DNS更改传播问题,会导致停机时间.
我一直在关注亚马逊的Route 53选项,它似乎有相同的传播延迟.
我考虑过为域设置自己的DNS服务器.然后,如果IP地址发生变化,我可能会比使用Godaddy更快地更改DNS条目.但DNS传播问题将成为任何DNS更改的问题.
我没有提到的一个项目是Route 53支持简单的负载平衡和故障转移.由于您在下面的答案中需要两个系统,只需为您的服务启动两个EC2实例,使用Route 53进行循环负载平衡并添加故障转移记录.创建CloudWatch警报,以便在其中一个实例失败时,您知道手动替换它.这将为您提供UDP的“穷人”负载均衡器.
[编辑结束]
首先,我将从GoDaddy DNS迁移到Route 53.我没有编程GoDaddy DNS条目的经验,但Route 53的API非常出色.
GoDaddy不支持区域顶点CNAME记录(example.com).您需要使用IPv4 A记录和IPv6 AAAA记录.这应该不是问题.我会使用AWS EIP记录,以便在启动新实例时,至少IPv4 DNS条目不需要DNS延迟.
我不会设置自己的DNS服务器.我先切换到53号公路.当你提到传播延迟时,你指的是TTL.您可以将TTL更改为短. Route 53支持1秒TTL条目,但大多数DNS客户端将忽略短TTL值,因此您几乎无法控制它.短TTL也意味着更多的DNS请求.
AWS不提供UDP负载平衡,但有些第三方产品和服务在AWS上运行.如果您的服务很关键或产生收益,请使用经过充分测试的解决方
我不会尝试重新发明轮子.但是,有时这样做很有趣,可以更好地理解真实系统的工作原理.
第1步：您需要设计一个策略来检测您的实例是否已失败.您需要复制负载均衡器执行的运行状况检查,然后触发操作.
第2步：您需要编写可以更新Route 53(GoDaddy)DNS条目的代码.
步骤3：您需要编写可以启动EC2实例并终止旧实例的代码.
步骤4：您需要检测新实例的新地址并更新Route 53(GoDaddy).
上述步骤将需要专用的始终在线计算机,具有高度可靠的Internet连接.我会将EC2用于监控系统. T2-micro可能很好.
但是,请查看开发和测试此新系统所需的时间.回去重新思考你的策略.
