Tungsten Fabric入门宝典丨8个典型故障及排查Tips

Tungsten Fabric入门宝典系列文章,来自技术大牛倾囊相授的实践经验,由TF中文社区为您编译呈现,旨在帮助新手深入理解TF的运行、安装、集成、调试等全流程。如果您有相关经验或疑问,欢迎与我们互动,并与社区极客们进一步交流。更多TF技术文章,请点击【TF中文社区】公号底部按钮>学习>文章合集。

作者:Tatsuya Naganawa 译者:TF编译组

在使用vRouter时,可能会出现某些情况,使得路由无法正常工作。

我收集了最常见的问题和步骤来研究vRouter的路由行为。

有两种方法可以解决问题,一是查看相关配置的详细信息,二是查看控制平面和vRouter的操作状态。

对于前者来说,最有用的是contrail-api-cli,而对于后者,最有用的是ist.py(特别是对于remote-debug而言),下面我使用这种格式进行描述。

注意:如果没有这些工具,你还可以使用curl来达到此目的。

例如,当需要以下命令时,

source /etc/kolla/kolla_toolbox/admin-openrc.sh
contrail-api-cli --host x.x.x.x ls -l virtual-network
contrail-api-cli --host x.x.x.x cat virtual-network/xxxx-xxxx-xxxx-xxxx

下述的命令将收集相同的信息。

source /etc/kolla/kolla_toolbox/admin-openrc.sh
openstack token issue
curl -H 'x-auth-token: tokenid' x.x.x.x:8082/virtual-networks
curl -H 'x-auth-token: tokenid' x.x.x.x:8082/virtual-network/xxxx-xxxx-xxxx-xxxx

同样,ist.py也可以用各种curl命令替换。以下是最常见情况中的curl命令。(cli更令人难忘)

ist.py ctr route show
   curl control-ip:8083/Snh_ShowRouteReq
ist.py ctr route nei
   curl control-ip:8083/Snh_BgpNeighborReq
ist.py vr intf
   curl vrouter-ip:8085/Snh_ItfReq
ist.py vr vrf
   curl vrouter-ip:8085/Snh_VrfListReq
ist.py vr route -v vrf-id
   curl vrouter-ip:8085/Snh_Inet4UcRouteReq?vrf_index=vrf-id

此外,ifmap信息(与vRouter的设备配置类似,例如接口、vrf、虚拟机等)对于查看配置内容也很有用。
可以通过以下的命令查看:

ist.py ctr ifmap table
   curl control-ip:8083/Snh_IFMapNodeTableListShowReq
ist.py ctr ifmap table virtual-network
   curl control-ip:8083/Snh_IFMapTableShowReq?table_name=virtual-network

ist.py ctr ifmap client
   curl control-ip:8083/Snh_IFMapPerClientLinksShowReq
ist.py ctr ifmap node
   curl control-ip:8083/Snh_IFMapLinkTableShowReq
ist.py ctr ifmap link
   curl control-ip:8083/Snh_IFMapNodeShowReq

ist.py vr ifmap
   curl vrouter-ip:8085/Snh_ShowIFMapAgentReq

注意:使用ist.py时,每个目标都有两个通用属性uve和trace。这些也可以用于进行详细的状态检查。

ist.py vr uve
 curl vrouter-ip:8085/Snh_SandeshUVETypesReq
ist.py vr uve VrouterStatsAgent
 curl vrouter-ip:8085/Snh_SandeshUVECacheReq?x=VrouterStatsAgent

ist.py ctr trace
 curl control-ip:8083/Snh_SandeshTraceBufferListRequest
ist.py ctr trace BgpTraceBuf
 curl control-ip:8083/Snh_SandeshTraceRequest?x=BgpTraceBuf
ist.py vr trace
 curl vrouter-ip:8085/Snh_SandeshTraceBufferListRequest
ist.py vr trace Flow
 curl vrouter-ip:8085/Snh_SandeshTraceRequest?x=Flow

UVE(用户可见实体)是Tungsten Fabric每个组件都会使用的一种度量标准,通常可以从analytics/uves API中看到。在每个组件的introspect中也可以直接看到它。

  • https://tungsten.io/operational-state-in-the-opencontrail-system-uve-user-visible-entities-through-analytics-api/

Trace是每个组件的跟踪日志,存储在每个进程的内存中。通过使用此选项,可以转储该trace的内存。

x. 一些VM-to-VM的报文无法到达其它节点

要对此进行排查,首先需要搞清楚这是控制平面问题还是数据平面问题。对于控制平面问题,以下命令将是最有用的。

 #ist.py ctr route show
 #ist.py vr intf
 #ist.py vr vrf
 #ist.py vr route -v (vrf id)

如果路由看起来是好的,则可以先利用tcpdump查看报文是否到达了目标vrouter。

 #tcpdump -i any -nn udp port 6635 or udp port 4789 or proto gre or icmp # for physical NIC
 #tcpdump -i any -nn icmp # for tap device

当报文到达目标vRouter后,请检查

#flow -l

以查看它是否被flow动作所丢弃。

  • 例如,动作: D(Policy), D(SG)表示已被网络策略(network-policy)或安全组(security-group)丢弃。要进一步查看flow动作,以下命令将有所帮助。
#ist.py vr intf -f text
 # ist.py vr acl

注意:要查看报文丢弃的原因,dropstats命令可能包含更多信息。

 #watch -n 1 'dropstats | grep -v -w 0'
 #watch -n 1 'vif --get 0 --get-drop-stats'
 #watch -n 1 'vif --get n --get-drop-stats' (n is vif id)
 #ping -i 0.2 overlay-ip # this can be used to see specific dropstats counter is incrementing because of that packets

x. 无法从外部节点访问VM

使用以下命令

#flow -l

以查看此报文的flow动作。

如果动作是D(SG),则它是被安全组(security-group)丢弃,因此需要进行更改以允许外部访问(openstack ingress规则的默认设置是仅允许VM-to-VM的访问)。

x. kubernetes service / ingress无法启动,带有浮动IP的SNAT无法正常工作

由于这些是由svc-monitor设置的,因此可以首先检查

 # tail -f /var/log/contrail/contrail-svc-monitor.log

以查看是否能看到一些错误。

  • 一种情况是日志中有“No vRouter is availale”,所以这些服务无法被启动。由于某种原因,从vRouter到analytics-api的NodeStatus导致了“非功能性”(Non-Functional),因此需要从vRouter端进行调查。

如果svc-monitor正常运行,则需要调查负载均衡器对象的行为。
当使用服务时,它将添加ecmp路由以到达应用程序,因此这些命令可用于调查控制平面(VM-to-VM路由步骤相同)。

 # ist.py ctr route show
 # ist.py vr route -v (vrf-id)

使用ingress或SNAT时,它将在vRouter容器的linux命名空间内启动haproxy进程。要调查详细信息,你可以尝试使用这些命令,以查看那些名称。

 #docker exec -it vrouter-agent bash
   #ip netns
   #ip netns exec vrouter-xxx ip -o a
   #ip netns exec vrouter-xxx ip route
   #ip netns exec vrouter-xxx iptables -L -n -v -t nat
 #tail -f /var/log/messages # haproxy log is logged

由于ingress service和SNAT也使用vRouter路由,因此这些命令还有助于查看这些service的前缀是否已导出到vRouter的路由表。

 #ist.py ctr route show
 #ist.py vr vrf
 #ist.py vr route -v (vrf-id)

x. 服务链无法正常工作

服务链的使用将更改vRouter路由表,因此首先可以使用以下命令查看路由实例是否已成功创建,以及ServiceChain路由是否已正确导入。

 #ist.py ctr route summary
 #ist.py ctr route show
 #ist.py ctr route show -p ServiceChain
 #ist.py ctr sc

如果控制平面运行良好,则需要以与VM-to-VM流量相同的方式调查数据平面行为(安全组也可以阻止服务链流量,因此也请从外部流量检查服务链的情况)。

# tcpdump -i any -nn udp port 6635 or udp port 4789 or proto gre or icmp
 # ist.py vr intf
 # ist.py vr vrf
 # ist.py vr route -v (vrf-id)
 # flow -l

x. 分布式SNAT不能很好地工作

该功能由vRouter上的ACL实现,因此要研究此功能,以下的命令很有用。

 #ist.py vr intf -f text

如果icmp正常运行,而tcp / udp无法正常运行,请检查端口列表。

x. cni返回Poll VM-CFG 404错误

在kubernetes部署中,cni有时会返回此错误,并且不会将IP分配给pod。(这在诸如以kubectl描述pod的各个地方都可以看到)

networkPlugin cni failed to set up pod "coredns-5644d7b6d9-p8fkk_kube-system" network: Failed in Poll VM-CFG. Error : Failed in PollVM. Error : Failed HTTP Get operation. Return code 404

此消息是通用错误的描述,会由多种原因引起。

在内部创建pod时,cni尝试从vrouter-agent接收其IP,后者又利用XMPP从control进程中接收该IP。

基于virtual-machine-interface信息,该信息由kube-manager从kube-apiserver信息创建。

因此,要解决此问题,需要完成几个步骤。

  1. controller节点上的contrail-status
    config-api, control需要处于“活动”状态
  2. contrail-kube-manager节点上的contrail-status处于“活动”状态
    此进程将从kube-apiserver检索信息,并在config-api上创建pod /负载均衡器等
  3. vrouter节点上的contrail-status
    vrouter-agent需要处于“活动”状态
  4. 如果使用独立的kubernetes yaml,则在vrouter注册和vrouter-agent重新启动之间的竞争条件方面存在已知限制。重新启动control可能会解决此问题。
 # docker restart control_control_1

如果一切都很好,

  • /var/log/contrail/contrail-kube-manager.log
  • /var/log/contrail/api-zk.log/var/log
  • /contrail/contrail-vrouter-agent.log
  • /var/log/contrail/cni/opencontrail.log <- cni log

这几项需要进一步调查……

  • 根本原因可能是xmpp问题、underlay问题、/etc/hosts问题等等

x. 磁盘已满

如果磁盘大小为50GB,则安装后一周左右可能就会占满。发生这种情况时,需要删除analytics数据,并需要重新启动analytics数据库。

[check analytics db size]
du -smx /var/lib/docker/volumes/analytics_database_analytics_cassandra/_data/ContrailAnalyticsCql

[if it is large, remove by this]
rm -rf /var/lib/docker/volumes/analytics_database_analytics_cassandra/_data/ContrailAnalyticsCql
docker-compose -f /etc/contrail/analytics_database/docker-compose.yaml down
docker-compose -f /etc/contrail/analytics_database/docker-compose.yaml up -d

为避免将来出现此问题,可以使用此knob。

echo 'ANALYTICS_STATISTICS_TTL=2' >> /etc/contrail/common_analytics.env
docker-compose -f /etc/contrail/analytics/docker-compose.yaml down
docker-compose -f /etc/contrail/analytics/docker-compose.yaml up -d

x. analytics cassandra状态检测到关闭

如果在contrail-status中看到此错误,则表明analytics cassandra运行不正常。

== Contrail database ==
nodemgr: initializing (Cassandra state detected DOWN.)

如果设置了JVM_EXTRA_OPTS: “-Xms128m -Xmx1g”,则最有可能的原因是Java的OutOfMemory错误,因此可以将其更新为类似。

JVM_EXTRA_OPTS: "-Xms128m -Xmx2g"

在/etc/contrail/common.env中,并可以重新启动analytics数据库。

docker-compose -f /etc/contrail/analytics_database/docker-compose.yaml down
docker-compose -f /etc/contrail/analytics_database/docker-compose.yaml up -d

Tungsten Fabric入门宝典系列文章——
1.首次启动和运行指南
2. TF组件的七种“武器”
3. 编排器集成
4.关于安装的那些事(上)
5.关于安装的那些事(下)
6.主流监控系统工具的集成
7.开始第二天的工作


Tungsten Fabric 架构解析系列文章——
第一篇:TF主要特点和用例
第二篇:TF怎么运作
第三篇:详解vRouter体系结构
第四篇:TF的服务链
第五篇:vRouter的部署选项
第六篇:TF如何收集、分析、部署?
第七篇:TF如何编排
第八篇:TF支持API一览
第九篇:TF如何连接到物理网络
第十篇:TF基于应用程序的安全策略


Tungsten Fabric入门宝典丨8个典型故障及排查Tips_第1张图片

Tungsten Fabric入门宝典丨8个典型故障及排查Tips_第2张图片

你可能感兴趣的:(Tungsten,Fabric中文社区,#Tungsten,Fabric入门宝典系列)