收到客户反馈:云上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数据库,发现互访确实存在丢包,需要进一步定位故障点
4、在图二所示的专线接入点1设备上部署双向流统,通过匹配ping ICMP报文进一步定位故障点
5、通过流统结果,发现云上报文正常发送至云下;云下报文发送至云上时有报文丢弃,定位故障点位于专线侧
6、客户联系供应商对专线进行质量排查,供应商通过排查监控发现专线有CRC告警
回顾该CASE案例在处理过程中整体排查结果符合预期,但还存在可优化的空间:
1、排查思路点1优化
可以通过快ping 更大数量的报文为进一步定位故障提供更可靠的判断依据,提升故障处理效率,建议探测报文数量为20000。
2、监控告警机制优化
对专线CRC监控部署更严格的监控指标,发现CRC告警后立刻通知客户,该案例涉及供应商已完成监控机制优化。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。