云上访问云下Redis数据时偶发性高延时?

  • 回答 (1)
  • 关注 (0)
  • 查看 (20)

云上CVM通过专线访问云下IDC-A Redis数据库时存在偶发性延时超过1S现象,请问怎么定位处理?

五星格兰特五星格兰特提问于
叮当叮当スターバーストするには回答于
推荐

回答来自于问答智囊团成员:王超超-Ryanccwang

专栏:https://cloud.tencent.com/developer/column/89781

故障现象

通过和客户沟通,客户反馈通过公网直接访问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告警后立刻通知客户,该案例涉及供应商已完成监控机制优化。

所属标签

可能回答问题的人

  • 腾讯云视频

    腾讯 · 行业应用产品经理 (已认证)

    136 粉丝0 提问1 回答
  • 腾讯云技术服务团队

    腾讯云 · 技术服务团队 (已认证)

    41 粉丝0 提问7 回答
  • 宝哥@devops运维

    腾讯 · 高级云计算工程师 (已认证)

    112 粉丝0 提问0 回答
  • elliswu

    腾讯计算机系统有限公司 · 高级工程师 (已认证)

    5 粉丝0 提问0 回答
  • 小翔

    1 粉丝0 提问1 回答
  • 1076485026

    0 粉丝0 提问0 回答

扫码关注云+社区

领取腾讯云代金券