如何借助Anycast技术拯救运维工程师的睡眠？

半夜十二点，小王正在酣睡。

忽然一阵清脆的手机铃声响起，把小王从睡梦中拉扯回现实。

“喂，谁啊？”

“王工，我是监控中心的，公司的xxx服务器挂了，你赶忙看一下吧。”

小王揉了揉眼睛，起身打开笔记本电脑，开始了一宿的不眠夜。

做为一名运维工程师，以上桥段常常发生在你们身边。白天繁重的工做已经让人筋疲力尽，而夜间做为电话值班工程师，仍不得不面对时刻突发的网络或系统故障。生活黑白颠倒，日夜不分。

 

试问，拿什么来拯救运维工程上的睡眠？

 

再给你们说一个故事。

 

我有一个朋友，他是Cloudflare的网络工程师，咱姑且叫他“钱哥”。

我和钱哥闲聊之余，问了问他们的夜间电话值班任务是否繁重辛苦。他淡淡的回答以下：

 

“咱们全世界范围内若是有某个站点（PoP）挂了，彻底不担忧也不用着急。工程师该睡觉睡觉，该休息休息。”

我十分不解，你要知道Cloudflare是一家全球CDN服务提供商，听说全世界10%的互联网流量都运行在他们家网络上。

常识性来讲，拥有如此体量的公司，其中某一个区域性站点down掉是一件极其严重的事情。而钱哥的回答却让我百思不得其解，彻底颠覆了个人认知。

 

都是工程师，差距如此之大，别人夜晚睡觉，咱们机房干耗！

 

在个人一番追问以后，总算明白他们其中的奥秘，原来一切都归功于他们使用了Anycast这技术。

 

那咱们是否也能像钱哥同样，借助于Anycast技术，还工程师们一个宁静的睡眠之夜？

 

科普科普，什么是Anycast技术？

在IP地址的世界里，你们熟知的IP地址类型大体有以下几种：

Unicast IP

单播IP，IP地址和主机是一一对应关系。

 

以下图，红色为数据包发送端，而绿色节点为数据包接收端。

当数据包发送给某一个特定IP地址时，全局下仅有一个数据包接收主机。此为Unicast。

 

 

Multicast IP

组播IP，组播IP拥有特定的IP地址段，当数据包发送给此组播IP地址后，组内成员都能收到此数据包的一份拷贝。

 

以下图，红色为数据包发送端，而绿色节点为数据包接收端。

当数据包发送给某一个特定组播IP地址时，同时存在多个数据包接收端。

Broadcast IP

广播IP，任意Unicast单播网段中最后一个IP地址。数据包发送给此地址会扩散给全广播域的成员。

 

以下图，红色为数据包发送端，而绿色节点为数据包接收端。

当数据包发送给广播IP地址时，全部成员均为数据包接收端。

 

 

而Anycast IP，则是集Multicast和Unicast特性于一身的特殊IP地址类型

Anycast中文称为任意播。

从宏观上来讲，Anycast相似于Multicast，同一种类型的数据流同时存在多个接收者。

而从微观上来讲，Anycast又有着Unicast的惟一性。每个单独的IP会话都可以找到惟一的源主机和目标主机。

 

咋看之下很矛盾，其实否则.

 

以DNS请求为例，假设全国人民同一时间发送1百万个DNS请求，他们都是发送给1.1.1.1的Anycast  DNS服务器地址。

 

宏观上来讲，全部数据包都送达给了分布在全国各地的DNS服务器。处于各地的DNS服务器分别接收到了必定数量的DNS请求，并做出回复。这体现了Multicast的特性。

 

微观上，某一个特定的DNS请求数据包，必定是发送给了某一台DNS主机，而不是同时又多台DNS主机接收到了此数据包。此为Unicast特性。

 

以下图，红色为数据包发送端，而绿色节点为数据包接收端。

 

在Anycast 环境下，总的来讲，同时存在多个有效的数据包接收端，可是就某一个特定IP数据包而言，仅有一个接收端主机收到了此数据包。

 

 

 

Anycast 到底牛掰在哪里？

在企业网络环境中，Anycast不太常见，其主要应用于大范围的DNS部署，CDN数据缓存，数据中心等。

 

天然而然，不少作企业网络维护的朋友会有疑问。怎么能让互联网的多个主机用同一个IP，这岂不是IP地址冲突了？

 

回答：

首先，每个服务器主机处在不一样的地理位置，他们之间不在同一个广播域内。因此把全部主机配置成相同的IP地址并不会引发咱们平常所见的IP地址冲突。

其次，光靠配置相同的IP地址时不够的，咱们还须要借助强大的BGP帮忙。

 

经过BGP，各个站点向Internet宣告相同的Anycast IP地址。

 

天然而然，Internet 就会接收到不一样目标路径，可是具备相同IP地址段的prefix。那数据包是如何在这种环境下路由的呢？

 

别急，往下看。

 

为了让你们有更深入的理解和认识，下面将详细描述Anycast的主要优点和用途

：

用途一：Load-balancing 负载均衡以及系统冗余性

 

不讲理论了，直接上例子，方便理解。

 

为了阐明使用Anycast和负载均衡，以及冗余性的关系，特举例以下：

假设咱们如今有三个DNS服务器站点，地点分别在北京，上海，广州。他们服务了全国的DNS解析服务。

 

按照通常的解决方案，为了实现三个DNS服务器负载均衡，可能有人会考虑到使用硬件负载均衡设备，例如常见的F5负载均衡设备等。

 

但若使用硬件负载均衡，随之带来的问题有：

1.    网络流量瓶颈，全部有流量都须要先经过负载均衡设备，而硬件设备自己的吞吐量决定了整个网络环境的吞吐量。

 

2.    高昂的硬件成本，为了实现全国的流量负载均衡，试想须要多大吞吐量的硬件设备。硬件吞吐量越大，购买成本就越高。

 

而经过Anycast技术，无须要借助任何第三方负载均衡器，就能够轻松达到负载均衡的效果，同时还提供了冗余和高可靠性。

 

实施方案以下：

 

经过配置三个DNS站点的服务器IP为相同IP，例如1.1.1.1/32。而后经过各个站点的BGP对互联网宣告1.1.1.0/24的网段。

 

（注：为何要宣告/24，而不是/32? 。由于在Internet里面，为了减少全球Internet路由表尺寸，默认状况下运营商只接受小于等于/8，而大于等于/24的网段宣告进入互联网。）

 

以上步骤完成之后，互联网路由表针对1.1.1.1/24会有三个不一样的出口路由器，分别是北京，上海，广州。

 

重点来了，由于全部用户都使用1.1.1.1做为他们的DNS服务器。

以东北的用户来讲，哪一台DNS服务器会给东北的用户提供解析呢？

 

答案就是：就近原则！

 

 

让咱们来看看数据包在网络中的路由细节：

 

当用户的DNS请求到达运营商的宽带路由器之后，运营商的路由器会根据BGP的选路原则选择到达1.1.1.1的最优路径。

 

例如，在用户宽带运营商和DNS服务器Internet运营商相同的状况下，最终会以IGP metric为关键因素来决定哪一个DNS服务器给用户提供服务。

而IGP的 Metric某种程度上就是物理距离的表明。

如上图，四川的宽带路由器经过查看BGP路由，发现1.1.1.1出口最优路由是在广州。那么四川用户的DNS数据包将被发送给广州的DNS服务器。

 

同理，东北的用户DNS解析将会被发往北京的DNS服务器，而江南一带的则是上海DNS服务器负责。

 

万一出现故障怎么办？

 

若是三台DNS服务器中某一台出现故障，例如广东DNS服务宕机。BGP协议会当即中止通告此1.1.1.0/24的网段。Internet 路由表将会只有北京和上海的DNS可供选择。

 

此时原广东DNS服务的用户将再次根据“就近原则”选择其余DNS服务器，例如上海DNS。

从而达到业务的平滑迁移和服务的高可用性。

 

基于以上的分析，咱们很容易就得出以下结论：

全国用户最终会根据距离DNS服务器的远近来判断使用哪一个DNS服务器作域名解析。

 

从DNS角度来讲，正由于不一样的地理位置用户会根据就近路由判断，从而选择不一样的DNS服务器，最终会使三台DNS服务器达到负载均衡的效果。

 

若其中某一个节点出现故障之后，业务会当即迁移到其余可用的节点上，从而避免网路服务故障。彻底不须要人工干预。

 

以上就是Anycast在负载均衡中的用途说明。

 

 

用途二：防范DDOS***

 

相信不少在运营商工做的朋友都很是讨厌DDOS***。

当DDOS发生时，10G或100Gbps的流量忽然蜂拥而来，占用运营商核心MPLS网路带宽不说，这种洪泛***会给客户网络形成短期的瘫痪。形成的损失极大。

 

在阐述Anycast防范DDOS***细节以前，让咱们先来看看DDOS是如何产生的。

 

以NTP协议为例，NTP协议是client-server模式，客户发起NTP时间查询申请，服务器响应NTP查询。看似正常的NTP数据流量有时候及其容易被玩坏。

 

假设某个***控制了成千上万的僵尸主机，这些僵尸主机纷纷伪造以下数据包并发送给全球NTP服务器：

 

源地址：1.2.3.4 （伪造源地址为 被***者的IP地址）

目标地址：全球各个NTP服务器地址。（越多越好）

当全世界各地的NTP服务器收到此查询之后，它会把查询结果发送回给真正的受害者1.2.3.4。

这时IP地址为1.2.3.4 的受害者收到全世界的NTP服务器发过来的数据包时，其有限的带宽链路就很容易产生拥塞并形成服务中断。

 

假设这些僵尸不仅是发送一次虚假数据包，而是上万次。

那么受害者接收到的NTP回复数据包量将以下：

 

虚假数据包发送数量 x 全世界NTP服务器的数量= 最终DDOS***的流量。

 

Anycast如何防范DDOS***？

 

好了，铺垫完成之后，回到正题。Anycast如何防范DDOS***？

 

DDOS***最关键一点，是须要把全部地理位置分散的小流量最终聚集到一个点。从而造成涛涛洪水。

正所谓以彼之道，还施彼身。

在Anycast环境下，因为多个地理位置不一样的主机同时使用同一个IP地址。正由于如此，DDOS流量在穿越运营商路由器时，路由器会根据地理位置远近把数据包路由到距离源地址最近的受害者主机站点。从而分散掉整个DDOS流量。

 

仍是以上述NTP协议DDOS为例。

假设IP为1.2.3.4的受害者恰巧布局了Anycast协议。其服务器分布在全国各地。

 

当DDOS来临时，不一样的NTP服务器根据路由选择，把流量发送到距离NTP服务器最近的受害者服务器上。

最终，本来10Gbps-100Gbps的汇总流量被各个目标服务器以1Gbps不足的DDOS***消化掉。

如上图所示，DDOS流量最终被每个Anycast 主机分散掉了。

 

大型企业使用案例

 

既然Anycast好处多多，有多少企业部署了呢？

据我了解，包括Microsoft，Cloudflare，LinkedIn以及其余企业都在全球范围内使用了Anycast技术。

 

下面我就以Cloudflare和LinkedIn为例给你们简单介绍下，他们是如何部署的。

 

Cloudflare

 

Cloudflare做为CDN网络佼佼者，其主要采用了Anycast技术为用户提供距离用户最近的Cache服务器。从而大大提升了用户的服务体验满意度。

 

Cloudflare全球建设了118个数据中心，凭借于Anycast的高冗余性，正如本文开头提到的，任何一个数据中心出现网络、系统故障。均不会影响客户体验度，全部当地的客户流量会自动路由到其余就近的数据中心。

 

 

上图为Cloudflare的全球数据中心分布图

 

借助于Anycast的优点，相比传统企业网络面对网络节点故障的脆弱性，Cloudflare这方便就显得很是游刃有余了。

 

下面这张图为Cloudflare的部分数据中心Pop节点，请重点关注红框部分。

红框部分是美国-费城的一个数据中心节点，尾随其后有一个关键字“Re-routed”。

其含义为，此数据中心由于故障或者其余缘由不能正常工做，全部费城的Cloudflare用户流量将会被自动路由到离费城最近的数据中心，无需人工干预。

  

 

看到这里，有些老鸟就禁不住想问。

Anycast是挺不错，可是看起来都是例如DNS，或者CDN在使用。

并且，不管是DNS服务提供商仍是CDN服务提供商，他们最大的特色在于：每一个Pop站点的服务器内容彻底同样，因此客户不管访问站点A或者站点B，均能获取到相同的内容。

 

那让咱们来看一个不同的例子，以下。

 

LinkedIn

 

LinkedIn你们最熟悉不过了，找工做攀人脉LinkedIn是常常去的地方。

可是你可知道LinkedIn一样使用了Anycast技术。但是LinkedIn是纯粹的网页内容服务提供商。他与CDN，DNS提供商等性质不太相同。

 

并且你们须要注意的是，LinkedIn的流量可全是HTTPS，TCP流量。并不是通常你们部署的DNS UDP流量。

 

那为何LinkedIn也对Anycast如此感兴趣呢？

 

故事要从几年前提及。

话说当LinkedIn业务急速扩展之后，出现了用户体验度差的问题，缘由在于“时延”两个字。

由于数据中心地理位置固定，而用户位置多是全世界各地。很天然，地理位置遥远的用户访问LinkedIn时会产生高时延问题。加上HTTP，HTTPS协议采用了话痨型的TCP协议。

 

这TCP几回握手来回之后，加上后续HTTP数据流。原本时延就高的连接加上TCP信令数据包一来二去。用户体验度很是糟糕。

 

为了解决以上问题，LinkedIn引入小型数据中心站点(Pops)。在全世界有业务的地方构架小型DC。同时小型DC与美国总部的数据中心之间长期维持着稳定的TCP会话连接。

 

当远端用户访问LinkedIn后，TCP连接实际上是发送给了当地的小型DC，小型DC再经过已有的TCP连接访问总部DC。从而大大减小了中间TCP信令会话的数量，变相下降了访问延时，提升了用户体验度。

上图为，在没有小型数据中心的状况下，人机交互的流程以及时延。

 

下图为在用户所在地部署小型数据中心之后，时延的变化。

 

 

哎哎哎，别扯远了，这和Anycast有半点关系么？

当LinkedIn在全世界范围内大批量部署小型DC之后，摆在他们面前的问题是，如何让用户可以就近访问当地的小型DC，而不是选择远端的数据中心总部？

 

这不就是Anycast擅长的么？

 

对，LinkedIn也是这么想的，因而乎他们把整个美国的小型DC的IP地址修改成相同的IP，并经过BGP发布到Internet。

 

当用户访问LinkedIn时，DNS解析会返回此小型DC 的IP，而后用户运营商会根据就近原则路由用户数据到最近的小型DC。从而达到了上面所述的优化延迟的目的。

 

以下图所示，经过使用Anycast技术之后，LinkedIn小型DC访问命中率大大提升。

 

总结

今天咱们一块儿研究了什么是Anycast，以及Anycast的妙用。

正如开头所说，Anycast并非一个新技术，可谓是旧瓶装新酒。

可是经过结合BGP协议，变相提升了Anycast的使用广度和深度。

 

最后，针对Anycast 作以下总结：

优势：

• Anycast能够零成本实现负载均衡，无视流量大小。

• Anycast是自然的DDOS防护措施，体现了大事化小，小事化了的解决方法。

• 部署Anycast能够得到设备的高冗余性和可用性。

• Anycast适用于无链接的UDP，以及有链接的TCP协议。

 

缺点：

• Anycast严重依赖于BGP的选路原则，在整个Internet网络拓扑复杂的状况下，会致使次优路由选择。

固然，就篇幅有限，不可能把全部内容一一介绍，你们有兴趣的话，能够继续深刻研究Anycast的其余妙用。

 

谢谢你们。