2017年1月14日，Ucloud云北京B区业务中断。中断的原因是B区数据中心机房因运营商施工原因连接到北京核心汇聚点。两对光纤同时被切断，导致业务中断。这让人联想到2015年5月的支付宝业务中断事件，同样是运营商网络光纤建设造成的。当时中断了四根大对数光缆。如果没有备份和监控措施，互连的光纤链路中断等突发事件将导致业务受到影响。事实上，在数据中心内外，类似的链路故障问题时有发生，但这两个例子影响比较大。那么，数据中心如何提前做好链路检测，避免类似问题的发生呢？链路故障是数据中心遇到的一种非常常见的故障类型。如果是在数据中心内部，那还好办。通过增加链路备份方式来提高可靠性，一般分布在不同的网络设备上，并尽可能相互隔离。这样，当链路的一侧出现故障时，可以及时切换业务。另一方面，可以有两条或更多条链路，链路越多，可靠性越高。最常见的方法是使用聚合方法。当几个或多个链路出现问题时，也可以将业务切换到正常链路上。如果在数据中心外，尤其是租用运营商的线路，外部环境是数据中心无法控制的。如果财力允许，可以租用多条链路。如果单个链路发生故障，业务仍然可以通过其他链路。不过Ucloud和支付宝都有备份链接，支付宝甚至有四个链接。只要一个环节是连续的，业务就不会完全中断。遗憾的是，四次彻底断线的事件还是发生了。这时候，拯救数据中心的唯一方法就是拥有一个异地数据中心或者容灾数据中心。当正在运行的数据中心所有外部链路中断时，可以及时将业务迁移到其他数据中心，保证业务不受影响。这也是建立容灾数据中心的重要性。如果Ucloud和支付宝提前有完善的异地容灾系统，业务就不会中断那么久。通常数据中心与灾备数据中心之间存在实时备份流量。一旦主数据中心出现故障，应用会自动切换到容灾数据中心运行。切换过程非常短，对业务影响极小。仅仅各个环节的备份是不够的，数据中心的备份是不够的。最重要的是要有检测链路故障的手段，并根据这些检测结果自动执行应用服务的切换动作。首先，数据中心有网管监控系统。当链路DOWN事件发生时，可以在网管中心进行监控。网管中心可以根据链路DOWN的位置和数量，手动或自动进行链路切换或业务操作。转变。手动方式是通过检查链路DOWN的故障位置进行针对性的业务倒换，自动方式是将链路DOWN事件与系统预先设定的动作联系起来，不同位置的链路DOWN有不同的Contingency预案，只要系统自动执行，即可恢复业务。其次，在很多情况下，光传输设备可以通过互连链路的中间（主要是数据中心外或者数据中心之间），这样即使链路的一端宕机，另一端也无法感知，所以需要部署一些检测协议来感知。常见的有聚合LACP协议、DLDP协议、OAM协议。如果LACP协议采用慢速检测，检测报文发送时间为30秒，超时时间为90秒，切换速度相对较慢。当然这个可以配置成快速检测，最快1秒发送检测包，3秒超时，几秒内完成链路切换。有时候如果不是聚合备份关系，那就用DLDP协议。DLDP协议用于检测单纤不可达链路故障。如果使用DLDP，当协议超时时，端口会被快速关闭。这样，云管理平台就会检测到端口DOWN，并采取修复动作。OAM协议也是链路检测协议，物理链路层的协议，所以开销更小，检测速度更快，动作丰富，可以告警，可以DOWN端口，可以与其他协议链接。第三，要有容灾数据中心。如果是数据中心内部DOWN，业务影响的范围不是特别大，但是如果数据中心与外部连接的端口出现DOWN，严重的时候整个数据中心都无法运行。这时候必须启用容灾数据中心。应用业务切换到灾备机房，灾备机房接管业务。主业务数据中心和灾备数据中心之间必须有实时的业务备份，并有一个通用的管理平台，以保证在数据中心发生故障时，业务可以平滑地切换到灾备数据中心。采用路由切换的方式，通过调整路由将业务流量引入容灾数据中心。实现这个过程是相当复杂的。需要了解多数据中心的业务模型，需要业务迁移时，通过调整路由将业务切换到容灾数据中心。第四，有时调整路由太慢，也容易出错。这时，VXLAN技术出现了。VXLAN技术将多个数据中心进行二层连接，不同数据中心的虚拟机可以自由迁移到其他数据中心（所谓迁移就是二层转发）。这样，当一个数据中心发生故障时，可以将所有的虚拟机服务迁移到容灾数据中心。整个过程业务层面无感知，切换速度快，调整简单。在很多情况下，这种迁移是由系统自动完成的。需要人类参与。数据中心有多种链路检测和切换方式，目的是应对突发链路故障对业务的影响。当然，一切都太多了。对于核心网络设备，往往有数百甚至数千个端口。如果同时测试这么多端口，设备将厌倦处理每个端口发送的大量检测报文。对设备的CPU造成了负担，所以是否部署链路检测，部署在哪些端口，采用哪些检测协议和方法，都需要具体问题具体分析。根据每个数据中心的业务需求进行部署。尽量使用，既不增加设备负担，又能达到检测的目的。
