专线CRC案例：云上访问云下Redis数据时偶发性高延时

背景

收到客户反馈：云上CVM通过专线访问云下IDC-A Redis数据库时存在偶发性延时超过1S现象，需要配合客户定位处理。

故障现象

通过和客户沟通，客户反馈通过公网直接访问IDC-A Redis数据库时不存在偶发性延时超过1S现象，通过云上访问时存在该现象，详见客户监控视图：

图一-故障现象

网络架构

客户本地有两个IDC，通过两条专线打通IDC和云上资源互访通道，目前两条专线通道之间以互备方式运行，网络拓扑架构详见下图：

图二-网络拓扑架构

流量模型

客户IDC-A通过通道1访问云上资源；客户IDC-B通过通道2访问云上资源，流量交互模型如下图：

图三-流量模型

业务模型

1、客户在云上部署了WEB服务和DNS解析服务了，

2、公网请求到达CVM后会通过内部DNS进行域名解析获取云下Redis数据库访问地址

3、CVM通过专线通道完成和云下Redis数据库交互

备注：目前客户在Module3/4各部署了一套内部DNS。

排查思路

根据客户提供信息，结合客户业务模型进行初步分析，怀疑故障点可能位于专线质量和DNS解析，特制定了以排查思路：

1、客户提供CVM到redis的访问延时参考

2、客户配置本地解析，观察通过专线读取Redis数据库是否有异常

3、查看内网DNS 解析log是否有异常

4、通过抓包获取高延时访问报文，需要核心节点部署抓包

排查步骤

1、客户快ping 5000个报文，测试结果正常

2、通过分析现象复现时捕获报文，发现有TCP报文丢失导致的报文重传

图四-报文分析

3、联系客户快ping 20000个报文探测云下Redis数据库，发现互访确实存在丢包，需要进一步定位故障点

图五-ping 探测报文

4、在图二所示的专线接入点1设备上部署双向流统，通过匹配ping ICMP报文进一步定位故障点

5、通过流统结果，发现云上报文正常发送至云下；云下报文发送至云上时有报文丢弃，定位故障点位于专线侧

图五-流统统计结果

6、客户联系供应商对专线进行质量排查，供应商通过排查监控发现专线有CRC告警

图六-专线CRC

案例回顾

回顾该CASE案例在处理过程中整体排查结果符合预期，但还存在可优化的空间：

1、排查思路点1优化

可以通过快ping 更大数量的报文为进一步定位故障提供更可靠的判断依据，提升故障处理效率，建议探测报文数量为20000。

2、监控告警机制优化

对专线CRC监控部署更严格的监控指标，发现CRC告警后立刻通知客户，该案例涉及供应商已完成监控机制优化。