CL210OpenStack操作的故障排除--常见核心问题的故障排除
🎹 个人简介：大家好，我是 金鱼哥，CSDN运维领域新星创作者，华为云·云享专家，阿里云社区·专家博主
📚个人资质： CCNA、HCNP、CSNA（网络分析师），软考初级、中级网络工程师、RHCSA、RHCE、RHCA、RHCI、ITIL😜
💬格言：努力不一定成功，但要想成功就必须努力🔥🎈支持我：可点赞👍、可收藏⭐️、可留言📝
📜网络
📑问题：您已经创建了一个实例，但是不能给它分配一个浮动的IP地址。
当网络没有正确地确认时，可能会发生此问题。如果路由器没有被设置为外部网络的网关，那么用户将不能为一个实例分配一个floatinq IP地址。使用openstack router set --external-gateway external_network router命令将路由器设置为外部网络的网关。使用openstack server add floating ip命令为实例分配一个浮动ip地址。
注意：即使路由器没有连接到外部网络，您也可以创建浮动IP地址，但当用户试图将浮动IP地址与实例关联时，将显示一个错误。
使用openstack router set --external-gateway --external-network router命令将路由器设置为外部网络的网关。
使用openstack server add floating ip命令为实例分配一个浮动ip地址。
使用openstack server list命令来验证一个浮动IP地址已经与实例关联。
📑问题：您无法使用SSH登录到实例。
检查是否为实例分配了适当的安全组，以及是否存在允许SSH通信的规则。默认情况下不允许SSH连接。
验证分配给实例的安全组是否有允许SSH的规则
如果在实例上运行的cloud-init无法与元数据服务通信，导致没有将SSH公钥添加到authorized_keys（授权密钥）文件中，也会出现此问题。
实例和元数据服务之间的通信涉及到几个组件，然而，造成这种故障的一个常见原因是，在overcloud期间，proiect网络没有附加路由器和NeutronEnableIsolatedMetadata选项没有启用部署。
您可以通过检查/var/log/cloud-init.log来验证这一点。另外，检查/home/cloud-user/.ssh/ authorized_keys文件。直接通过控制台URL或仪表板访问实例。
在这种情况下，将子网附加到路由器上，然后重新启动实例。
SSH失败的另一个原因是在创建实例时没有将密钥对分配给实例。在此场景中，必须销毁实例并使用辅助密钥对重新创建实例。
📑物理网络问题
问题：您已经验证了所有OpenStack网络组件的配置，但是计算节点之间或与OpenStack外部系统之间的通信仍然失败。
所有OpenStack软件定义的网络都依赖于底层的物理网络。可以使用多种工具从控制器或计算节点测试物理网络连接。
首先，确定要研究的物理接口。使用ovs-vsctl命令发现物理接口到OVS网桥的映射。
br-int没有物理接口；它们都是内在的。从上面的输出，桥接到接口的映射是：
使用ip link show命令来验证物理连接。
上下设置表示存在一个链接。MTU也显示在输出中。MTU不匹配会导致数据包丢失或碎片化。
要分析进入和离开接口的流量，可以使用tcpdump命令。tcpdump可以显示数据包是否被分段、重传或仅在一个方向上工作。下面的示例展示了如何使用VLAN tags捕获数据包。
📑OpenFlow规则分析
📑问题：您怀疑没有通过OVN正确地处理数据包
由于OVN提供了Laver 3服务，OpenFlow规则现在比OVS多得多。通过转储流手动地通过OVN跟踪数据包是一项乏味且可能容易出错的操作。数据包根据每个表中的规则进行测试(可能进行修改)，然后重新提交到下一个表。
ovs-appctl ofproto/trace 命令允许模拟进入给定接口上的OVN桥接的不同数据包类型。要跟踪来自特定实例的数据包，首先要知道MAC地址和TAP接口名。在适用的计算主机上，使用virsh dumpxml domain命令
ovs-appctl ofproto/trace 命令的第一个指令是网桥名，第二个指令是描述模拟数据包的字段集合。下表描述了下面示例中使用的字段及其值。
最终结果是数据包被丢弃，这是正确的，因为目标实例不存在。
📜镜像
OpenStack镜像服务存储镜像和元数据。用户可以创建images并将其上传到镜像服务中。镜像服务有一个RESTful APl，它允许用户猜测镜像的元数据，以及获取实际镜像。
📑日志记录
镜像服务的日志记录可以在/var/lib/config-data/puppet-generated/glance_api/etc/glance/glance-api.conf配置文件中确认。它允许配置日志记录级别。日志文件的位置，使用syslog还是journald。
镜像的最大大小可以使用image_size_cap选项来限制，每个用户的存储容量限制可以使用user_storage_quota选项来确定。
📑管理镜像
在使用openstack命令创建新镜像时，可以选择使用--protected选项来保护该镜像不被删除。这可以防止镜像被删除，即使是管理员。在您可以删除该镜像之前，它必须是不受保护的。
📜卷
📑Ceph
OpenStack块存储服务可以使用Ceph作为存储后端。在块存储服务中创建的每个卷在Ceph中都有一个关联的RBD镜像。RBD镜像的名称是块存储卷的ID
OpenStack块存储服务需要Ceph中的一个用户和一个池才能使用它。这个用户是openstack，这个用户被指定用于其他使用Ceph作为后端的服务，比如openstack镜像服务。undercloud还为块存储服务创建了一个专用的Ceph池，名为卷。卷池包含与卷关联的所有RBD镜像。这些设置包含在/var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder. conf配置文件。
Ceph中的权限称为能力，并由守护进程类型授予，比如MON或OSD。Ceph有三个功能:读(r)来查看，写(w)来修改，执行(x)来执行扩展的对象类。对于OSD守护进程类型，所有守护进程类型都支持这三种功能，权限可以限制为一个或多个池，例如:
如果没有指定池，则对所有现有池授予权限。openstack用户拥有openstack服务使用的所有池的功能。
openstack用户要求openstack块存储服务使用的卷和镜像池具有读、写和执行能力。镜像池专用于OpenStack镜像服务。
📑附加和分离
每个附加和分离操作都有三个API调用。
- 卷的状态在数据库中更新。
- 处理卷上的连接操作。
- 卷的状态定稿，资源被释放。
为了附加一个卷，它必须处于可用状态。任何其他状态都会导致错误消息。可能发生的情况是，一个体积被卡在一个分离的状态。该状态可以由管理员用户更改。
如果尝试删除一个卷，但失败了，可以使用 --force选项强制删除该卷。
不正确的卷配置是块存储错误的最常见原因。如果出现错误，请查阅OpenStack块存储服务日志文件。
📑日志文件
块存储服务API日志文件在确定错误是由于端点错误还是连接错误时非常有用。也就是说，如果尝试创建一个卷，但失败了，那么首先应该查看/var/log/containers/cinder/cinder-api.log日志文件。验证请求是否在/var/log/containers/cinder/cinder-api.log中被接收。假设没有错误，检查记录在创建卷期间/var/log/containers/cinder/cinder-volume.log可能发生的错误。
要使OpenStack块服务正常运行，必须将它们配置为使用RabbitMQ消息传递服务。所有配置都可以在/var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf中找到。存储在控制器节点上的配置文件。rabbit_userid选项的默认值是guest。如果该用户被错误地确认并且块存储服务被重新启动，RabbitMQ将不会响应请求，因为身份验证将失败。在此期间创建的任何卷都会导致错误状态。任何处于错误状态的卷都必须在块存储服务重新启动并正常运行后删除并重新创建。
要确定这个场景中的问题，请检查记录控制器节点上/var/log/containers/cinder/cinder-scheduler.log的日志文件。如果问题是RabbitMQ，您将看到以下内容:
验证RabbitMQ集群和RabbitMQ-bundle Pacemaker资源是否可用。如果这两个资源都可用，那么问题可能会在/var/lib/config-data/puppet-generated/cinder/etc/cinder/ashes.conf配置文件中找到。确保/var/lib/config-data/puppet-generated/cinder/etc/cinder/ashes .conf配置文件中的所有用户名、密码、IP地址和url都是正确的。
📜课本练习
- 排除故障并修复导致实例启动失败的问题。
- 排除故障并修复OpenStack网络服务中的问题。
[student@workstation ~]$ lab troubleshooting-services setup
Setting up workstation for lab exercise work:
• Verifying project: finance.................................. SUCCESS
• Creating user env file: developer1-finance-rc............... SUCCESS
• Creating user env file: architect1-finance-rc............... SUCCESS
• Creating keypair: example-keypair........................... SUCCESS
. Creating flavor: default.................................... SUCCESS
. Creating image: rhel7....................................... SUCCESS
. Creating external network: provider1-104.................... SUCCESS
. Creating external network: provider2-104.................... SUCCESS
. Configuring environment for exercise: ...................... SUCCESS📑1. 启动一个名为finance-server1的实例。
[student@workstation ~]$ source developer1-finance-rc📑1.2.使用以下值创建一个名为finance-server1的实例。
[student@workstation ~(developer1-finance)]$ openstack server create --flavor default --image rhel7 --key-name example-keypair --network provider1-104 --wait finance-server1📑1.3.使用ctrl+C取消部署，删除实例，然后使用 --debug选项重新启动。
^CTraceback (most recent call last):
File "/usr/bin/openstack", line 10, in <module>
[student@workstation ~(developer1-finance)]$ openstack server delete finance-server1
[student@workstation ~(developer1-finance)]$ openstack server create --flavor default --image rhel7 --key-name example-keypair --network provider1-104 --wait finance-server1 --debug
START with options: [u'server', u'create', u'--flavor', u'default', u'--image', u'rhel7', u'--key-name', u'example-keypair', u'--network', u'provider1-104', u'--wait', u'finance-server1', u'--debug']
…………📑1.4 部署继续循环尝试调用计算服务。使用ctrl+C取消部署，然后删除实例。
[student@workstation ~(developer1-finance)]$ openstack server delete finance-server1📑2. 确定部署失败的原因
📑2.1 第一步，检查nova_conductor服务。登录到controller0，然后成为root用户。
[student@workstation ~(developer1-finance)]$ ssh controller0
Last login: Fri Oct 30 18:20:27 2020 from 172.25.250.254
[heat-admin@controller0 ~]$ sudo -i
[root@controller0 ~]#📑2.2 检查nova_conductor容器的运行状况。
[root@controller0 ~]# docker ps --format "table {{.Names}}\t{{.Status}}" | grep nova
nova_metadata Up 7 days
nova_api Up 5 days (healthy)
nova_scheduler Up 5 days (healthy)
nova_vnc_proxy Up 7 days (healthy)
nova_consoleauth Up 7 days (healthy)
nova_api_cron Up 7 days
nova_conductor Restarting (1) 9 hours ago
nova_placement Up 7 days
[root@controller0 ~]# docker exec -it nova_conductor /openstack/healthcheck
Error response from daemon: Container 8ffb511c9318d8024378f0419d709902a7601c33e59233203e7b7037c20c263b is restarting, wait until the container is running📑2.3 确定nova_conductor失败的原因。
[root@controller0 ~]# docker logs nova_conductor
…………
++ cat /run_command
+ CMD='/usr/bin/nova-conductor '
+ ARGS=
+ [[ ! -n '' ]]
+ . kolla_extend_start
++ [[ ! -d /var/log/kolla/nova ]]
+++ stat -c %a /var/log/kolla/nova
++ [[ 2755 != \7\5\5 ]]
++ chmod 755 /var/log/kolla/nova
++ . /usr/local/bin/kolla_nova_extend_start
+ echo 'Running command: '\''/usr/bin/nova-conductor '\'''
+ exec /usr/bin/nova-conductor
Running command: '/usr/bin/nova-conductor '
Traceback (most recent call last):
File "/usr/bin/nova-conductor", line 10, in <module>
sys.exit(main())
File "/usr/lib/python2.7/site-packages/nova/cmd/conductor.py", line 35, in main
config.parse_args(sys.argv)
File "/usr/lib/python2.7/site-packages/nova/config.py", line 52, in parse_args
default_config_files=default_config_files)
File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2507, in __call__
self._namespace._files_permission_denied)
oslo_config.cfg.ConfigFilesPermissionDeniedError: Failed to open some config files: /etc/nova/nova.conf这个错误表明，/etc/nova/nova.conf上的权限不允许容器作为运行的用户访问。
📑2.4 使用docker inspect命令确定nova_conductor服务的配置文件位置。
[root@controller0 ~]# docker inspect nova_conductor | grep -A 15 HostConfig
"HostConfig": {
"Binds": [
"/var/lib/config-data/puppet-generated/nova/:/var/lib/kolla/config_files/src:ro",
"/etc/hosts:/etc/hosts:ro",
"/etc/pki/ca-trust/extracted:/etc/pki/ca-trust/extracted:ro",
"/etc/pki/tls/cert.pem:/etc/pki/tls/cert.pem:ro",
"/etc/ssh/ssh_known_hosts:/etc/ssh/ssh_known_hosts:ro",
"/var/lib/kolla/config_files/nova_conductor.json:/var/lib/kolla/config_files/config.json:ro",
"/var/log/containers/nova:/var/log/nova",
"/etc/localtime:/etc/localtime:ro",
"/etc/pki/tls/certs/ca-bundle.crt:/etc/pki/tls/certs/ca-bundle.crt:ro",
"/etc/pki/tls/certs/ca-bundle.trust.crt:/etc/pki/tls/certs/ca-bundle.trust.crt:ro",
"/dev/log:/dev/log",
"/etc/puppet:/etc/puppet:ro"
],
"ContainerIDFile": "",📑2.5 /etc/nova/nova.conf文件错误中显示的将位于/var/lib/config-data/puppet-generated/nova/etc/nova/nova.conf。
检查文件的权限，然后纠正它们。
[root@controller0 ~]# cd /var/lib/config-data/puppet-generated/nova
[root@controller0 nova]# ll etc/nova/nova.conf
-rw-------. 1 root 42436 60203 Oct 31 20:23 etc/nova/nova.conf
[root@controller0 nova]# chmod 640 etc/nova/nova.conf
[root@controller0 nova]# ll etc/nova/nova.conf
-rw-r-----. 1 root 42436 60203 Oct 31 20:23 etc/nova/nova.conf📑2.6 重新启动nova_conductor容器，等待它恢复正常，然后从controller0注销。
[root@controller0 nova]# docker restart nova_conductor
nova_conductor
[root@controller0 nova]# docker ps --format "table {{.Names}}\t{{.Status}}" | grep nova
nova_metadata Up 7 days
nova_api Up 5 days (healthy)
nova_scheduler Up 5 days (healthy)
nova_vnc_proxy Up 7 days (healthy)
nova_consoleauth Up 7 days (healthy)
nova_api_cron Up 7 days
nova_conductor Up 5 minutes (healthy)
nova_placement Up 7 days📑3. 重试启动finance-server1实例。
[student@workstation ~(developer1-finance)]$ openstack server create --flavor default --image rhel7 --key-name example-keypair --network provider1-104 --wait finance-server1
+-----------------------------+---------------------------------------------------------+
| Field | Value
+-----------------------------+---------------------------------------------------------+
| OS-DCF:diskConfig | MANUAL
| OS-EXT-AZ:availability_zone | nova
| OS-EXT-STS:power_state | Running
| OS-EXT-STS:task_state | None
| OS-EXT-STS:vm_state | active
| OS-SRV-USG:launched_at | 2020-11-06T05:52:47.000000
| OS-SRV-USG:terminated_at | None
| accessIPv4 |
| accessIPv6 |
| addresses | provider1-104=10.0.104.107
| adminPass | U8wu8JvdEg8p
| config_drive |
| created | 2020-11-06T05:52:08Z
| flavor | default (e04380ed-b027-4a72-a697-4307bc014b6c)
| hostId | 3eb57302ddddc3af1fdc763eee541c699f0866f6458e3b5c9a722611
| id | 7124ed45-a316-4862-bb3e-afea0688785d
| image | rhel7 (6b0128a9-4481-4ceb-b34e-ffe92e0dcfdd)
| key_name | example-keypair
| name | finance-server1
| progress | 0
| project_id | 3c003f65d8d64914a053f178fbbf953c
| properties |
| security_groups | name='default'
| status | ACTIVE
| updated | 2020-11-06T05:52:47Z
| user_id | e4035d555f6b88cf42ca4cacb9fa9999dca9787392222d2eb0875e4e34e6d76f |
| volumes_attached |
+-----------------------------+---------------------------------------------------------+📑4. 从finance-server1, ping utility为10.0.104.1。
📑5. 调查通信问题，找出原因。
📑5.1 在workstation上，确定provider1-104网络的ID。这将用于确定包流。
[student@workstation ~(developer1-finance)]$ openstack network show provider1-104 -c id
+-------+--------------------------------------+
| Field | Value |
+-------+--------------------------------------+
| id | 4e13e6cd-d6fe-4112-b661-3bd55601437b |
+-------+--------------------------------------+📑5.2 确定哪个计算节点承载finance-server1实例。
[student@workstation ~(developer1-finance)]$ source architect1-finance-rc
[student@workstation ~(architect1-finance)]$ openstack server show finance-server1
+-------------------------------------+-------------------------------------------------+
| Field | Value
+-------------------------------------+-------------------------------------------------+
| OS-DCF:diskConfig | MANUAL
| OS-EXT-AZ:availability_zone | nova
| OS-EXT-SRV-ATTR:host | compute0.overcloud.example.com
| OS-EXT-SRV-ATTR:hypervisor_hostname | compute0.overcloud.example.com
| OS-EXT-SRV-ATTR:instance_name | instance-00000021📑5.3 登录到适当的compute节点，并更改为根用户。
[student@workstation ~(architect1-finance)]$ ssh compute0
Last login: Sat Oct 31 18:53:28 2020 from 172.25.250.254
[heat-admin@compute0 ~]$ sudo -i
[root@compute0 ~]#📑5.4 查找实例使用的TAP设备。
注意，它应该连接到brint。还要注意MAC地址；这将在跟踪包流时使用。
[root@compute0 ~]# virsh dumpxml instance-00000021 | grep bridge -A 10
<interface type='bridge'>
<mac address='fa:16:3e:9c:4b:94'/>
<source bridge='br-int'/>
<virtualport type='openvswitch'>
<parameters interfaceid='3367af4a-5c91-4e11-9e50-39490b1268eb'/>
</virtualport>
<target dev='tap3367af4a-5c'/>
<model type='virtio'/>
<mtu size='1500'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
<serial type='pty'>📑5.5 查看provider1-104 network和financeserver1 TAP设备的OVS连接。
[root@compute0 ~]# ovs-vsctl show
d2399352-a3b5-4559-9868-ec8f97fdf2f5
Manager "ptcp:6640:127.0.0.1"
is_connected: true
…………
Bridge br-int
fail_mode: secure
Port "patch-br-int-to-provnet-4e13e6cd-d6fe-4112-b661-3bd55601437b"
Interface "patch-br-int-to-provnet-4e13e6cd-d6fe-4112-b661-3bd55601437b"
type: patch
options: {peer="patch-provnet-4e13e6cd-d6fe-4112-b661-3bd55601437b-to-br-int"}
Port "tap3367af4a-5c"
Interface "tap3367af4a-5c"
…………
Bridge "br-eth3"
fail_mode: standalone
Port "patch-provnet-4e13e6cd-d6fe-4112-b661-3bd55601437b-to-br-int"
Interface "patch-provnet-4e13e6cd-d6fe-4112-b661-3bd55601437b-to-br-int"
type: patch
options: {peer="patch-br-int-to-provnet-4e13e6cd-d6fe-4112-b661-3bd55601437b"}
Port "br-eth3"
Interface "br-eth3"
type: internal注意，TAP设备将实例连接到br-int。还要注意，provider1-104网络的创建产生了一对接口，通过一个补丁端口将br-int连接到br-eth3。接口名包含provider1-104网络的ID。
📑5.6 通过OpenFlow规则跟踪数据包是冗长且容易出错的。
使用ovs-appctl命令模拟从finance-server1向实用程序发送ICMP包。对于上一步中显示的OVS连接，来自实例应该通过tap3367af4a-5c端口输入br-int，然后通过补丁端口传输到br-eth3。下表描述了该命令中使用的数据包字段。
[root@compute0 ~]# ovs-appctl ofproto/trace br-int in_port='tap3367af4a-5c',icmp,nw_src=10.0.104.107,dl_src=fa:16:3e:9c:4b:94,nw_dst=10.0.104.1
Flow: icmp,in_port=13,vlan_tci=0x0000,dl_src=fa:16:3e:9c:4b:94,dl_dst=00:00:00:00:00:00,nw_src=10.0.104.107,nw_dst=10.0.104.1,nw_tos=0,nw_ecn=0,nw_ttl=0,icmp_type=0,icmp_code=0
bridge("br-int")
----------------
0. in_port=13, priority 100
set_field:0x1->reg13
set_field:0x3->reg11
set_field:0x2->reg12
set_field:0xc->metadata
set_field:0x3->reg14
resubmit(,8)
8. reg14=0x3,metadata=0xc,dl_src=fa:16:3e:9c:4b:94, priority 50, cookie 0xc4e13a1c
resubmit(,9)
9. ip,reg14=0x3,metadata=0xc,dl_src=fa:16:3e:9c:4b:94,nw_src=10.0.104.107, priority 90, cookie 0x7e74e0c5
resubmit(,10)
10. metadata=0xc, priority 0, cookie 0x200f0f96
resubmit(,11)
11. ip,metadata=0xc, priority 100, cookie 0xa13d3fda
load:0x1->NXM_NX_XXREG0[96]
resubmit(,12)
12. metadata=0xc, priority 0, cookie 0xe499f477
resubmit(,13)
13. ip,reg0=0x1/0x1,metadata=0xc, priority 100, cookie 0x25d8cbff
ct(table=14,zone=NXM_NX_REG13[0..15])
drop
-> A clone of the packet is forked to recirculate. The forked pipeline will be resumed at table 14.
Final flow: icmp,reg0=0x1,reg11=0x3,reg12=0x2,reg13=0x1,reg14=0x3,metadata=0xc,in_port=13,vlan_tci=0x0000,dl_src=fa:16:3e:9c:4b:94,dl_dst=00:00:00:00:00:00,nw_src=10.0.104.107,nw_dst=10.0.104.1,nw_tos=0,nw_ecn=0,nw_ttl=0,icmp_type=0,icmp_code=0
Megaflow: recirc_id=0,eth,ip,in_port=13,vlan_tci=0x0000/0x1000,dl_src=fa:16:3e:9c:4b:94,nw_src=10.0.104.107,nw_dst=0.0.0.0/1,nw_frag=no
Datapath actions: ct(zone=1),recirc(0x119)
===============================================================================
recirc(0x119) - resume conntrack with default ct_state=trk|new (use --ct-next to customize)
===============================================================================
Flow: recirc_id=0x119,ct_state=new|trk,ct_zone=1,eth,icmp,reg0=0x1,reg11=0x3,reg12=0x2,reg13=0x1,reg14=0x3,metadata=0xc,in_port=13,vlan_tci=0x0000,dl_src=fa:16:3e:9c:4b:94,dl_dst=00:00:00:00:00:00,nw_src=10.0.104.107,nw_dst=10.0.104.1,nw_tos=0,nw_ecn=0,nw_ttl=0,icmp_type=0,icmp_code=0
bridge("br-int")
----------------
thaw
Resuming from table 14
14. ct_state=+new-est+trk,ip,reg14=0x3,metadata=0xc, priority 2002, cookie 0xf3084ce3
load:0x1->NXM_NX_XXREG0[97]
resubmit(,15)
15. metadata=0xc, priority 0, cookie 0x24aac1f
resubmit(,16)
16. metadata=0xc, priority 0, cookie 0x57781885
resubmit(,17)
17. metadata=0xc, priority 0, cookie 0x14c07320
resubmit(,18)
18. ip,reg0=0x2/0x2,metadata=0xc, priority 100, cookie 0xd6073813
ct(commit,zone=NXM_NX_REG13[0..15],exec(load:0->NXM_NX_CT_LABEL[0]))
load:0->NXM_NX_CT_LABEL[0]
resubmit(,19)
19. metadata=0xc, priority 0, cookie 0x21d4241a
resubmit(,20)
20. metadata=0xc, priority 0, cookie 0xe777d077
resubmit(,21)
21. metadata=0xc, priority 0, cookie 0x7b462ffe
resubmit(,22)
22. metadata=0xc, priority 0, cookie 0x9863707
resubmit(,23)
23. metadata=0xc, priority 0, cookie 0xe73a5aad
resubmit(,24)
24. metadata=0xc, priority 0, cookie 0x9e3c3d71
set_field:0xfffe->reg15
resubmit(,32)
32. priority 0
resubmit(,33)
33. reg15=0xfffe,metadata=0xc, priority 100
set_field:0x4->reg13
set_field:0x1->reg15
resubmit(,34)
34. priority 0
set_field:0->reg0
set_field:0->reg1
set_field:0->reg2
set_field:0->reg3
set_field:0->reg4
set_field:0->reg5
set_field:0->reg6
set_field:0->reg7
set_field:0->reg8
set_field:0->reg9
resubmit(,40)
40. metadata=0xc, priority 0, cookie 0x6732fb41
resubmit(,41)
41. ip,reg15=0x1,metadata=0xc, priority 110, cookie 0x7ef1d3
resubmit(,42)
42. metadata=0xc, priority 0, cookie 0x79aee1c5
resubmit(,43)
43. metadata=0xc, priority 0, cookie 0x7228a61c
resubmit(,44)
44. metadata=0xc, priority 0, cookie 0xd87c8baa
resubmit(,45)
45. metadata=0xc, priority 0, cookie 0xa36f3840
resubmit(,46)
46. metadata=0xc, priority 0, cookie 0x60f97baa
resubmit(,47)
47. metadata=0xc, priority 0, cookie 0xb7bbbcd1
resubmit(,48)
48. metadata=0xc, priority 0, cookie 0xe6aee358
resubmit(,49)
49. reg15=0x1,metadata=0xc, priority 50, cookie 0x96e3be18
resubmit(,64)
64. priority 0
resubmit(,65)
65. reg15=0x1,metadata=0xc, priority 100
push_vlan:0x8100
set_field:4200->vlan_vid
output:14
bridge("br-eth3")
-----------------
0. priority 0
NORMAL
-> no learned MAC for destination, flooding
pop_vlan
set_field:0xfffe->reg15
Final flow: recirc_id=0x119,eth,icmp,reg11=0x3,reg12=0x2,reg13=0x4,reg14=0x3,reg15=0xfffe,metadata=0xc,in_port=13,vlan_tci=0x0000,dl_src=fa:16:3e:9c:4b:94,dl_dst=00:00:00:00:00:00,nw_src=10.0.104.107,nw_dst=10.0.104.1,nw_tos=0,nw_ecn=0,nw_ttl=0,icmp_type=0,icmp_code=0
Megaflow: recirc_id=0x119,ct_state=+new-est-rel-rpl-inv+trk,ct_label=0/0x1,eth,icmp,in_port=13,vlan_tci=0x0000/0x1fff,dl_src=fa:16:3e:9c:4b:94,dl_dst=00:00:00:00:00:00,nw_src=10.0.104.107,nw_dst=10.0.104.1,nw_frag=no
Datapath actions: ct(commit,zone=1,label=0/0x1),push_vlan(vid=104,pcp=0),7模拟的ICMP流量确实成功到达br-eth3。
📑5.7 回顾br-eth3的配置。
[root@compute0 ~]# ovs-vsctl show | grep br-eth3 -A 8
Bridge "br-eth3"
fail_mode: standalone
Port "patch-provnet-4e13e6cd-d6fe-4112-b661-3bd55601437b-to-br-int"
Interface "patch-provnet-4e13e6cd-d6fe-4112-b661-3bd55601437b-to-br-int"
type: patch
options: {peer="patch-br-int-to-provnet-4e13e6cd-d6fe-4112-b661-3bd55601437b"}
Port "br-eth3"
Interface "br-eth3"
type: internal
Bridge br-trunk注意只有一个内部端口和一个补丁端口；没有显示外部接口。
📑5.8 查看计算节点的IP配置。
[root@compute0 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 52:54:00:00:f9:02 brd ff:ff:ff:ff:ff:ff
inet 172.25.249.54/24 brd 172.25.249.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe00:f902/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovs-system state UP group default qlen 1000
link/ether 52:54:00:01:00:02 brd ff:ff:ff:ff:ff:ff
inet6 fe80::5054:ff:fe01:2/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovs-system state UP group default qlen 1000
link/ether 52:54:00:02:fa:02 brd ff:ff:ff:ff:ff:ff
inet6 fe80::5054:ff:fe02:fa02/64 scope link
valid_lft forever preferred_lft forever
5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 52:54:00:03:00:02 brd ff:ff:ff:ff:ff:ff
…………eth3接口被列为down。
📑5.9 检查/etc/sysconfig/network-scripts/ifcfg-eth3文件。
[root@compute0 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth3
# This file is autogenerated by os-net-config
DEVICE=eth3
ONBOOT=no
HOTPLUG=no
NM_CONTROLLED=no
PEERDNS=no
DEVICETYPE=ovs
TYPE=OVSPort
OVS_BRIDGE=br-eth3
BOOTPROTO=none该接口在引导时已被禁用。
📑5.10 启用eth3接口。
[root@compute0 ~]# ifup eth3📑5.11 再检查一下br-eth3的配置。
[root@compute0 ~]# ovs-vsctl show | grep br-eth3 -A 8
Bridge "br-eth3"
fail_mode: standalone
Port "br-eth3"
Interface "br-eth3"
type: internal
Port "eth3"
Interface "eth3"
Port "patch-provnet-4e13e6cd-d6fe-4112-b661-3bd55601437b-to-br-int"
Interface "patch-provnet-4e13e6cd-d6fe-4112-b661-3bd55601437b-to-br-int"
type: patch
options: {peer="patch-br-int-to-provnet-4e13e6cd-d6fe-4112-b661-3bd55601437b"}
Bridge br-inteth3接口现在显示在输出中。
📑5.12 将eth3的ONBOOT选项更改为yes。
[root@compute0 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth3
# This file is autogenerated by os-net-config
DEVICE=eth3
ONBOOT=yes
HOTPLUG=no
NM_CONTROLLED=no
PEERDNS=no
DEVICETYPE=ovs
TYPE=OVSPort
OVS_BRIDGE=br-eth3
BOOTPROTO=none📑6. 使用ping命令重新测试finance-server1 和utility之间的通信。
📑清除实验
[student@workstation ~]$ lab troubleshooting-services cleanup💡总结
RHCA认证需要经历5门的学习与考试，还是需要花不少时间去学习与备考的，好好加油，可以噶🤪。
以上就是【金鱼哥】对 第九章 OpenStack操作的故障排除--常见核心问题的故障排除 的简述和讲解。希望能对看到此文章的小伙伴有所帮助。
💾 红帽认证专栏系列：
RHCSA专栏： 戏说 RHCSA 认证
RHCE专栏： 戏说 RHCE 认证
此文章收录在RHCA专栏： RHCA 回忆录
如果这篇【文章】有帮助到你，希望可以给【金鱼哥】点个赞👍，创作不易，相比官方的陈述，我更喜欢用【通俗易懂】的文笔去讲解每一个知识点。
如果有对【运维技术】感兴趣，也欢迎关注❤️❤️❤️ 【金鱼哥】❤️❤️❤️，我将会给你带来巨大的【收获与惊喜】💕💕！
