Facebook史上最严重宕机,全网宕机近七小时,高管赴推特道歉。近7个小时时间,全都挂了Facebook全网宕机,连内网都废了。Twitter成为了最大赢家。对一家互联网巨头来说,这样的状况实在太尴尬。这已经是Facebook创办以来最严重的一次网络访问事故。直到下线近7个小时,美国西部时间下午三点左右,Facebook、Instagram等诸多产品才恢复正常访问。(目前只是美国地区恢复正常,全球其他国家和地区依然没有恢复。) 整个事件可以概况为:Facebook负责BGP变更的工程师,将包含Facebook权威(Authorized)域名服务器的网段185.89.218.0/23和129.134.30.0/23过滤掉了,从而造成的连锁反应。 以下是完整的整个事件的前因后果: Facebook网络工程师,更新BGP路由配置时,将185.89.218.0/23和129.134.30.0/23这两条路由过滤掉了,这两条路由分别包含512个IP地址,一共1024个IP地址,其中: 185.89.218.0/23代表IP地址从185.89.218.0开始到185.89.219.255结尾的512个地址。 129.134.30.0/23代表IP地址从129.134.30.0开始到129.134.31.255结尾的512个地址。 意味着Internet上其他路由器将没有通往这1024个IP地址的路由,怎么办? 丢弃处理! 可是要命的是,这1024个IP地址恰恰包含Facebook公司权威DNS服务器的IP地址。这样就出大事了。要想透彻理解为何要出大事,首先要了解DNS是如何工作的? 当用户在浏览器里输入Facebook.com之后敲回车键,浏览器需要将facebook.com解析成IP地址之后才能建立TCP连接,然后TLS安全连接,然后是http交易。 通常用户的本地DNS服务器就是家庭网关IP、或者公司网关、或者公司DNS Server,比如192.168.1.1 、10.0.0.1、172.16.1.1之类的,也有的用户使用诸如1.1.1.1 、8.8.8.8、114.114.114.114的DNS服务器。但是这些这些DNS服务器,仅仅是域名解析的搬运工。当用户的解析Facebook.com请求到来时,它们先检查自己的缓存里是否有facebook.com与IP地址的条目,如果有,直接返回给用户。 如果没有,需要这些域名解析的搬运工比如1.1.1.1,去根域名服务器(一共13个虚拟IP地址)去查询,返回com域名服务器(一级)IP地址列表。 1.1.1.1这台不知疲倦的搬运工再联系com域名服务器(使用IP地址联系),com域名服务器给1.1.1.1 返回facebook.com域名服务器的IP地址列表。就是这么几台服务器才是最权威的数据源头,因为它们才真正知晓facebook内部服务器域名与IP地址的映射关系。 可是当1.1.1.1这台搬运工尝试联系facebook.com域名服务器的IP地址列表时,无法连接,因为Internet上没有facebook.com域名服务器的IP地址列表的路由表,Facebook域名服务器的IP地址为何从Internet全球路由表里消失了,因为Facebook网络工程师将它们(185.89.218.0/23和129.134.30.0/23)过滤出去了。 这样1.1.1.1就无法将Facebook.com域名解析返回给用户,用户就无法访问facebook的网站。 为何Facebook全球有30多亿用户,该次事件只影响到其中的8000多万的用户? 如上文所说,域名解析搬运工如1.1.1.1、8.8.8.8,如果成功解析facebook网站的域名,通常会缓存一段时间,这样当下一个用户访问facebook网站时,可以立马将结果返回给用户,这样可以省却不少的时间,同时刷新缓存定时器。 这就意味着,如果一台域名搬运工一直有用户在解析facebook域名,一直在刷新缓存定时器,那么这个缓存一直不会被删除,一直可以被直接返回给用户。所以,即使在互联网无法访问facebook权威域名服务器,但是依靠分布在全球各地的域名解析搬运工的缓存机制,依然有很多用户可以访问Facebook网站。毕竟Facebook其他服务器是可路由的、是可以到达的! 当然如果有的域名搬运工,缓存的内容由于没有域名解析的刷新,超时最后被删除。当域名搬运工试图联系facebook权威服务器时,就出现问题了。 Facebook负责变更BGP的工程师为何不在第一时间做回滚(Rollback)操作? 做变更的工程师通常都是远程VPN操作,而做路由变更操作是一种极度高风险的操作,因为一旦路由配置出错,工程师就无法再访问正在远程操作的路由器了。为了保险起见,为了不和路由器失去联系,工程师在commit变更代码时,会使用一个confirm选项,后面跟着一个数字,单位是分钟。比如 Commit confirm 2 这条代码的意思是,将当前的修改配置commit, 两分钟之后自动回滚到修改前的版本。在这两分钟内,工程师发现远程SSH软件与路由器的远程SSH连接依然没有断,那么就认为当前的修改没有问题,于是再次使用 commit命令确认当前修改,那么修改的配置就真正的生效了。 相反,如果工程师敲完命令立马自己的远程软件SSH断了,说明当前的修改让路由器与Internet失去了联系,路由出问题了。好在这种影响只会影响2分钟,2分钟之后自动回滚到修改前的版本,工程师依然可以再次联系到路由器,检查自己的配置哪里出了问题。 很显然,在这两分钟内facebook工程师没有尝试去Ping一下Facebook内部权威域名服务器。否则他们一定不会commit这次变更操作。 为了简化操作,工程师在等待confirm 的时间内,可以使用自动化的脚本,将公司内部最关键的服务器Ping一遍,其中包括域名服务器、域控制器、时间服务器等等,确保它们全部没有问题再commit配置版本。 源:车小胖谈网络