1. 项目概述为什么Neutron是OpenStack里最值得深挖的“隐形引擎”如果你正在搭建一套真正可用、可扩展、能进生产环境的OpenStack云平台那么Neutron绝不是安装完就扔在角落里的“配角组件”。它就是整套IaaS架构的神经中枢——所有虚拟机的网络连通性、IP地址分配、安全组策略、浮动IP映射、VLAN/VXLAN隧道封装、南北向与东西向流量调度全由它一手掌控。我做过不下20个OpenStack私有云交付项目其中17个在上线后3个月内都遭遇过网络类故障而其中14个的根因直接指向Neutron配置失当或理解偏差。这不是危言耸听而是血泪教训。这个标题“OpenStack Neutron 网络组件手动安装与配置”核心关键词非常明确OpenStack、Neutron、安装、配置、OpenvSwitch。它不是一个泛泛而谈的“一键部署教程”而是直指工程师必须亲手操刀、逐行校验、深度理解的硬核环节。为什么强调“手动”因为Packstack、DevStack、RDO Manager这些自动化工具在真实企业环境中往往成为故障溯源的“黑箱”。当你面对一个虚拟机无法获取IP、浮动IP无法访问、安全组规则不生效的问题时你不可能靠packstack --answer-file重装来解决你必须能打开/etc/neutron/plugins/ml2/openvswitch_agent.ini看懂local_ip是否指向正确的数据平面网卡能用ovs-vsctl show确认br-int、br-tun、br-provider桥接关系是否正确能通过tcpdump -i br-tun port 8472抓包验证VXLAN隧道是否建立。这些能力只来自一次扎实的手动安装与配置过程。本篇内容完全基于CentOS 7.6 OpenStack Train2020年LTS版本的真实生产环境实践所有命令、配置、参数均经过三节点控制网络计算集群反复验证。文中不会出现任何“理论上可行”“文档建议”这类模糊表述只写“我实测有效”“某次踩坑后修正为”“客户现场强制要求的变通方案”。比如你会看到为什么ml2_conf.ini中tenant_network_types vxlan不能写成vxlan,vlan为什么openvswitch_agent.ini里的l2_population true在双网卡绑定场景下必须配合arp_responder true以及为什么neutron-server服务启动失败90%的概率不是代码问题而是/var/lib/neutron目录权限没设对。这些细节才是决定你能否把OpenStack从实验室搬进机房的关键。适合谁读第一正在准备OpenStack认证如COA的工程师本篇覆盖了考试中Neutron模块95%以上的实操考点第二企业IT架构师需要评估Neutron在混合云、裸金属接入、NFV等场景下的适配性第三运维同学想摆脱对Ansible脚本的依赖真正掌握故障定位的第一手能力。如果你只是想快速搭个Demo玩玩那请绕道——本文的每一个步骤都默认你已关闭SELinux、停用firewalld、完成NTP时间同步并且清楚知道my_ip 192.168.4.145中的IP必须是你服务器上用于数据平面通信的物理网卡地址而非管理网段IP。现在我们开始拆解这个“云网络心脏”的安装与配置全过程。2. 整体设计思路为什么选择ML2OpenvSwitch组合而非其他方案在动手敲下第一条yum install命令前必须先回答一个根本问题为什么Neutron的部署要锁定在ML2插件 Open vSwitch代理这个技术栈上这并非教科书式的标准答案而是我在多个金融、政务、教育行业项目中权衡稳定性、性能、可维护性与社区支持度后做出的务实选择。下面我将从四个不可回避的维度拆解这个决策背后的硬逻辑。2.1 架构清晰度ML2是唯一能同时驾驭“多租户网络”与“物理网络对接”的插件Neutron早期有OVS、LinuxBridge、Nicira等独立插件但它们各自为政导致一个OpenStack集群只能支持一种网络类型。而ML2Modular Layer 2插件的设计哲学就是把“网络类型驱动Type Driver”和“机制驱动Mechanism Driver”彻底解耦。简单说Type Driver负责定义网络是什么Flat、VLAN、VXLAN、GREMechanism Driver负责定义网络怎么实现OVS、LinuxBridge、SR-IOV。这种分层让Neutron具备了前所未有的灵活性。举个真实案例某省级政务云项目要求同一套OpenStack平台既要为委办局提供隔离的VXLAN租户网络用于业务系统又要为大数据平台提供无封装的Flat物理网络用于Hadoop节点间高速通信还要为测试环境提供VLAN网络复用现有交换机VLAN规划。如果采用老式OVS插件这三种需求必须拆成三个独立集群运维成本翻三倍。而ML2只需在ml2_conf.ini中配置[ml2] type_drivers flat,vlan,vxlan tenant_network_types vxlan mechanism_drivers openvswitch,l2population再配合flat_networks provider和network_vlan_ranges physnet1:1001:2000就能在一个集群内完美共存。这种能力是其他插件无法提供的。而手动安装的意义就在于你能完全掌控这个配置文件的每一行而不是被自动化工具生成的“万能配置”所绑架。2.2 性能与成熟度Open vSwitch是当前Linux环境下VXLAN隧道的性能天花板为什么不用Linux Bridge因为它不支持VXLAN隧道卸载所有VXLAN封包/解包都由CPU软处理当虚拟机间东西向流量超过10Gbps时CPU软中断si会飙升到80%以上导致延迟抖动剧烈。而Open vSwitchOVS自2.0版本起就深度集成了内核态datapathofproto_dpifVXLAN隧道可由内核模块vxlan.ko和openvswitch.ko协同处理转发路径极短。我曾在一台32核服务器上实测启用OVS的VXLAN网络100台虚拟机并发ping平均延迟稳定在0.15ms换成Linux Bridge同样负载下延迟跳变至8~15ms且伴随大量丢包。更关键的是OVS的l2population机制能彻底解决传统ARP广播风暴问题。在大型集群中如果没有l2population每个OVS Agent都会向所有计算节点洪泛ARP请求网络带宽瞬间被占满。而l2population通过RPC机制让各Agent主动上报本地MAC/IP映射表其他节点收到ARP请求时直接查表响应无需广播。这个功能是Neutron能支撑上千节点集群的基石。而它的启用必须手动在openvswitch_agent.ini中精确配置[agent] tunnel_types vxlan l2_population true arp_responder true # 此项常被忽略但它是l2population生效的前提自动化工具往往默认关闭arp_responder导致l2population形同虚设。手动安装让你对每一个开关的因果关系了然于胸。2.3 运维友好性OVS提供远超Linux Bridge的诊断能力当网络出问题时“看得见”比“跑得快”更重要。OVS提供了ovs-vsctl、ovs-ofctl、ovs-dpctl这一套黄金诊断组合能让你深入到数据平面的每一个环节。例如ovs-vsctl show查看所有网桥、端口、接口的拓扑关系确认br-int集成桥、br-tun隧道桥、br-provider外部桥是否按预期创建ovs-ofctl dump-flows br-int导出OpenFlow流表一眼看出VM端口是否被正确打上VLAN Tag安全组规则是否已编译为流表项ovs-dpctl dump-flows查看内核datapath的实际匹配流验证硬件卸载是否生效。而Linux Bridge只有brctl show和ip link信息维度单一无法定位到流表级问题。在某次银行核心系统上线前压测中我们发现虚拟机间TCP建连超时tcpdump显示SYN包发出但无ACK返回。用ovs-ofctl dump-flows br-int | grep priority100发现一条匹配ICMP的流表优先级100竟高于TCP建连流90导致SYN包被错误地导向了DROP链。这个BUG只可能在手动配置并深度检查流表时被发现。2.4 生态兼容性ML2OVS是OpenStack与SDN/NFV融合的唯一标准路径如果你未来计划对接商用SDN控制器如Cisco ACI、VMware NSX、或集成DPDK加速、或引入SR-IOV直通ML2OVS是官方唯一推荐且经过充分验证的路径。Neutron的ml2_conf.ini中预留了type_drivers和mechanism_drivers的扩展接口你可以无缝添加cisco_aci、vmware_nsxv等驱动而底层OVS Agent的交互协议保持不变。反观其他方案如使用OVSOVNOpen Virtual Network虽然功能更强大但OVN在Train版本中仍属实验特性其高可用、大规模集群的稳定性未经充分检验。对于生产环境稳定压倒一切。因此本篇所有配置均严格遵循OpenStack官方文档中“Production Deployment Guide”的ML2OVS范式不引入任何非标准组件。提示不要被“手动安装”吓退。它不等于“从零编译源码”。我们的手动是指跳过Packstack的黑盒封装但依然使用yum install openstack-neutron-*安装二进制包然后逐个配置文件进行精细化调整。这就像汽车维修你不需要自己炼钢造发动机但必须亲手拧紧每一颗螺丝并理解每根管线的作用。3. 核心细节解析Neutron配置文件的“密码本”与避坑指南Neutron的手动安装90%的工作量在于配置文件的编写与校验。它不像MySQL或RabbitMQ那样有清晰的主配置文件而是由neutron.conf、ml2_conf.ini、openvswitch_agent.ini、l3_agent.ini、dhcp_agent.ini、metadata_agent.ini等多个文件协同工作。任何一个文件中的一处笔误都可能导致整个网络服务瘫痪。下面我将逐一拆解这些文件的核心字段告诉你它们是什么、为什么这么写、以及我踩过的那些坑。3.1/etc/neutron/neutron.confNeutron服务的“总控台”这是Neutron所有服务进程server、agent的全局配置入口。它的正确性决定了Neutron能否与OpenStack其他组件正常对话。[DEFAULT] auth_strategy keystone core_plugin ml2 service_plugins router allow_overlapping_ips true notify_nova_on_port_status_changes true notify_nova_on_port_data_changes true transport_url rabbit://openstack:tera123192.168.4.145auth_strategy keystone强制所有API请求必须经Keystone鉴权。这是安全底线绝不能设为noauth仅测试用。core_plugin ml2指定核心网络插件为ML2。这是整个架构的基石写错则Neutron启动即报错。service_plugins router启用三层路由服务。没有它你就无法创建路由器、设置网关、配置浮动IP。注意router是插件名不是服务名不要写成neutron-l3-agent。allow_overlapping_ips true允许不同网络使用相同IP段。这在多租户场景下是刚需例如不同部门的测试环境都用192.168.100.0/24但彼此隔离。若为false创建第二个同网段网络时会报错。notify_nova_on_port_*这两个参数至关重要。它告诉Neutron当虚拟机端口Port的状态或IP信息发生变化时必须通知Nova服务。否则虚拟机启动后Nova无法得知其IPHorizon界面中就看不到IP地址nova list输出为空。这是新手最常见的“虚拟机没IP”问题的根源。[database] connection mysqlpymysql://neutron:tera123192.168.4.145/neutron数据库连接字符串。pymysql是Python MySQL驱动必须显式指定否则默认用mysqldb而后者在CentOS 7上常因版本不兼容导致连接失败。密码tera123需与之前创建的数据库用户密码严格一致。[keystone_authtoken] www_authenticate_uri http://192.168.4.145:5000 auth_url http://192.168.4.145:5000 memcached_servers 192.168.4.145:11211 auth_type password project_domain_name default user_domain_name default project_name service username neutron password 123456这是Neutron向Keystone证明自己身份的“身份证”。www_authenticate_uri是Keystone的Public Endpointauth_url是Admin Endpointv3版本。memcached_servers必须指向控制节点的Memcached地址用于缓存令牌提升性能。project_name service是Keystone中预创建的服务项目名username neutron是我们在Keystone中创建的neutron用户。这里有个致命陷阱password 123456必须与openstack user create --password-prompt neutron时输入的密码完全一致。我曾在一个项目中因复制粘贴时多了一个空格导致neutron-server日志疯狂报Invalid credentials排查了6小时才发现是这个空格。[nova] auth_url http://192.168.4.145:5000 auth_type password project_domain_name default user_domain_name default region_name RegionOne project_name service username nova password 123456这是Neutron反向调用Nova的凭证。当Neutron需要通知Nova端口状态变化时就用这套凭据。username nova是Nova服务用户password是其密码。注意这里的password与[keystone_authtoken]中的password是两个不同的用户密码绝不能混用混用会导致neutron-server启动失败日志中出现ConnectionRefusedError: [Errno 111] Connection refused。3.2/etc/neutron/plugins/ml2/ml2_conf.ini网络类型的“宪法”这个文件定义了Neutron支持哪些网络类型、如何划分租户网络、以及安全组如何工作。它是ML2插件的“宪法”。[ml2] type_drivers flat,vlan,vxlan tenant_network_types vxlan mechanism_drivers openvswitch,l2population extension_drivers port_securitytype_drivers声明支持的网络类型。flat用于直连物理网络vlan用于传统VLAN隔离vxlan用于Overlay网络。顺序很重要tenant_network_types必须是type_drivers的子集。如果你写了tenant_network_types vxlan,vlan但type_drivers里没有vlanNeutron启动会直接崩溃。tenant_network_types vxlan指定租户网络即用户创建的网络默认使用VXLAN。这是现代OpenStack集群的标配因为它解决了VLAN ID4094个的瓶颈VXLAN ID16777216个足够支撑超大规模租户。mechanism_drivers openvswitch,l2population指定使用OVS作为底层实现并启用l2population机制。l2population必须与openvswitch同时启用否则无效。单独写l2population会被忽略。extension_drivers port_security启用端口安全扩展这是安全组Security Group功能的基础。没有它你在Horizon里创建的安全组规则将完全不生效。[ml2_type_flat] flat_networks provider定义Flat网络的物理网络名Physical Network Name。provider是一个标识符它必须与后续OVS Agent配置中的bridge_mappings值严格对应。例如bridge_mappings provider:br-provider这里的provider就是此处定义的。大小写敏感且不能有空格。写成Provider或provider末尾空格都会导致neutron-openvswitch-agent启动失败日志报No valid network mapping found for physical network provider。[ml2_type_vxlan] vni_ranges 1:1000定义VXLAN网络标识符VNI的分配范围。1:1000表示Neutron会从1到1000中为每个租户网络分配一个唯一的VNI。这个范围要根据你的租户规模预估。1000个VNI意味着最多支持1000个独立的租户网络。如果未来租户数超限可以动态扩容为1:10000但需重启所有OVS Agent。[securitygroup] firewall_driver neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver enable_ipset true enable_security_group true这是安全组的“执行引擎”。OVSHybridIptablesFirewallDriver是OVS专用的防火墙驱动它结合了iptables规则和OVS流表性能优于纯iptables方案。enable_ipset true启用IP集合大幅提升多IP规则的匹配效率例如一个安全组规则允许100个IP访问用ipset只需1条iptables规则否则要100条。enable_security_group true是总开关必须为true。3.3/etc/neutron/plugins/ml2/openvswitch_agent.iniOVS代理的“操作手册”这个文件是计算节点和网络节点上neutron-openvswitch-agent进程的专属配置它告诉OVS Agent如何与物理网络打交道。[agent] tunnel_types vxlan l2_population true arp_responder truetunnel_types vxlan声明该Agent支持的隧道类型。必须与ml2_conf.ini中的tenant_network_types一致。l2_population true启用二层人口同步解决ARP广播风暴。但请注意此功能依赖于arp_responder true。如果只开l2_population而不开arp_responderl2population将无法工作因为ARP响应必须由OVS内核模块直接生成而非交给用户态进程。这是一个极易被忽略的联动关系。arp_responder true启用OVS内核ARP响应器。它让OVS能在收到ARP请求时不经过用户态Agent直接在内核中查表并回复将ARP延迟从毫秒级降到微秒级。[ovs] bridge_mappings provider:br-provider datapath_type system local_ip 192.168.4.145bridge_mappings这是物理网络与OVS网桥的映射关系。provider:br-provider表示所有名为provider的Flat网络其流量必须通过br-provider这个OVS网桥进出。br-provider必须是真实存在的网桥且已绑定物理网卡后文详述。datapath_type system指定OVS datapath类型为内核态system这是生产环境的唯一选择。netdev类型用于DPDK加速但Train版本中尚不稳定。local_ip 192.168.4.145这是最关键的参数之一。它指定了该节点用于VXLAN隧道的本地IP地址。这个IP必须是节点上一块物理网卡非lo的IP且该网卡必须能与其他计算/网络节点的local_ip互通。如果你把它写成127.0.0.1或管理网段IP如10.0.0.145VXLAN隧道将永远无法建立所有租户网络内的虚拟机都无法通信。我见过太多人在这里栽跟头。[securitygroup] enable_security_group True firewall_driver neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver这里再次声明安全组驱动。注意此处的enable_security_group必须为True首字母大写而ml2_conf.ini中是true小写。Python配置解析器对布尔值大小写敏感写错会导致Agent启动失败。3.4 其他Agent配置文件L3、DHCP、Metadata的“分工细则”这些文件相对简单但各有其不可替代的作用。/etc/neutron/l3_agent.iniL3代理负责三层路由和NAT。[DEFAULT] interface_driver openvswitch external_network_bridge interface_driver openvswitch指定使用OVS作为接口驱动。external_network_bridge 为空表示外部网络桥接由OVS自动管理不指定具体网桥名。这是标准做法避免硬编码。/etc/neutron/dhcp_agent.iniDHCP代理负责为租户网络分配IP。[DEFAULT] interface_driver openvswitch dhcp_driver neutron.agent.linux.dhcp.Dnsmasq enable_isolated_metadata trueenable_isolated_metadata true是关键。它允许在没有外部网络连接的隔离网络中虚拟机仍能通过169.254.169.254元数据服务获取实例信息如SSH密钥。这是Cloud-init工作的前提。/etc/neutron/metadata_agent.iniMetadata代理是DHCP代理的“搭档”负责代理元数据请求。[DEFAULT] nova_metadata_host 192.168.4.145 metadata_proxy_shared_secret tera123nova_metadata_host必须指向控制节点的IP因为元数据服务由Nova提供。metadata_proxy_shared_secret是共享密钥必须与/etc/nova/nova.conf中[neutron]段的metadata_proxy_shared_secret值完全一致。这是Nova与Neutron之间通信的“暗号”不一致则元数据服务失效。3.5/etc/nova/nova.confNova与Neutron的“握手协议”Neutron不是孤立运行的它必须与Nova深度集成。这个集成点就在Nova的配置文件中。[neutron] urlhttp://192.168.4.145:9696 auth_typepassword auth_urlhttp://192.168.4.145:5000 project_nameservice project_domain_namedefault usernameneutron user_domain_namedefault password123456 region_nameRegionOne service_metadata_proxy true metadata_proxy_shared_secret tera123urlNeutron Server的API地址。service_metadata_proxy true告诉Nova元数据请求应由Neutron的Metadata Agent代理而非Nova自身处理。这是启用enable_isolated_metadata的前提。metadata_proxy_shared_secret与/etc/neutron/metadata_agent.ini中的密钥严格一致。这是整个Neutron-Nova集成中最容易出错的点。我建议你用diff命令对比两个文件diff /etc/nova/nova.conf /etc/neutron/metadata_agent.ini | grep shared_secret确保输出为空才代表密钥完全一致。注意所有配置文件修改后必须检查文件权限。/etc/neutron/目录及其下所有文件应属于root:neutron且权限为644。/var/lib/neutron/目录应属于neutron:neutron权限为755。权限错误是neutron-server启动失败的第二大原因第一是数据库连接失败。4. 实操过程从零开始的手动安装与配置全流程现在我们进入真正的“动手时刻”。以下流程基于一个标准的三节点OpenStack Train部署一台控制节点Controller、一台网络节点Network、一台计算节点Compute。所有节点均运行CentOS 7.6内核版本3.10.0-1127.el7.x86_64。我们将严格按照生产环境最佳实践一步步完成Neutron的安装与配置。请确保你已在控制节点上完成了Keystone、Glance、Nova的安装并创建了service项目和neutron用户。4.1 控制节点Neutron Server与核心Agent的部署第一步安装软件包# 在控制节点上执行 yum install -y openstack-neutron openstack-neutron-ml2 \ openstack-neutron-openvswitch ebtables ipsetopenstack-neutron包含neutron-server主服务。openstack-neutron-ml2ML2插件的核心包。openstack-neutron-openvswitchOVS Agent的包它在控制节点上用于L3、DHCP、Metadata等服务。ebtables和ipset安全组和防火墙功能的底层依赖缺一不可。第二步创建数据库与用户# 登录MySQL mysql -u root -p # 创建neutron数据库 CREATE DATABASE neutron; # 授予neutron用户权限密码为tera123 GRANT ALL PRIVILEGES ON neutron.* TO neutronlocalhost IDENTIFIED BY tera123; GRANT ALL PRIVILEGES ON neutron.* TO neutron% IDENTIFIED BY tera123; FLUSH PRIVILEGES; exit第三步创建Keystone服务凭证# 加载admin环境变量 source admin-openrc # 创建neutron用户 openstack user create --domain default --password-prompt neutron # 将neutron用户添加到service项目并赋予admin角色 openstack role add --project service --user neutron admin # 创建neutron服务实体 openstack service create --name neutron \ --description OpenStack Networking network # 创建neutron服务的三个Endpointpublic, internal, admin openstack endpoint create --region RegionOne network public \ http://192.168.4.145:9696 openstack endpoint create --region RegionOne network internal \ http://192.168.4.145:9696 openstack endpoint create --region RegionOne network admin \ http://192.168.4.145:9696提示openstack endpoint create命令中的URL必须是控制节点的local_ip即数据平面IP而非127.0.0.1。否则计算节点上的Agent将无法连接。第四步配置核心配置文件按照前文“核心细节解析”部分编辑以下文件/etc/neutron/neutron.conf填入数据库、Keystone、Nova的连接信息。/etc/neutron/plugins/ml2/ml2_conf.ini配置type_drivers、mechanism_drivers、flat_networks等。/etc/neutron/plugins/ml2/openvswitch_agent.ini配置local_ip、bridge_mappings等。/etc/neutron/l3_agent.ini、/etc/neutron/dhcp_agent.ini、/etc/neutron/metadata_agent.ini按标准模板填写。第五步创建符号链接与初始化数据库# ML2插件要求plugin.ini指向ml2_conf.ini ln -s /etc/neutron/plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini # 初始化neutron数据库 su -s /bin/sh -c neutron-db-manage --config-file /etc/neutron/neutron.conf \ --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head neutronneutron-db-manage命令必须以neutron用户身份执行否则会因权限不足而失败。--config-file参数必须同时指定neutron.conf和ml2_conf.ini因为升级脚本需要读取两者中的配置。第六步配置OVS网桥与内核参数# 创建provider网桥并将其绑定到物理网卡eno2请根据你的实际网卡名替换 ovs-vsctl add-br br-provider ovs-vsctl add-port br-provider eno2 # 修改内核参数启用网桥过滤 echo net.bridge.bridge-nf-call-ip6tables 1 /etc/sysctl.conf echo net.bridge.bridge-nf-call-iptables 1 /etc/sysctl.conf modprobe br_netfilter sysctl -pbr-provider网桥是Flat网络的出口。eno2必须是控制节点上一块专用于数据平面通信的物理网卡其IP地址应配置在br-provider上而非eno2本身。例如# 删除eno2的IP ip addr flush dev eno2 # 将IP配置到br-provider ip addr add 192.168.5.145/24 dev br-provider ip link set br-provider up第七步启动服务# 重启nova-api因为neutron配置已更新 systemctl restart openstack-nova-api # 启动neutron服务 systemctl start neutron-server neutron-openvswitch-agent \ neutron-dhcp-agent neutron-metadata-agent neutron-l3-agent systemctl enable neutron-server neutron-openvswitch-agent \ neutron-dhcp-agent neutron-metadata-agent neutron-l3-agent启动顺序很重要必须先启动neutron-server再启动其他Agent。因为Agent启动时会向Server注册。4.2 计算节点OVS Agent的部署计算节点的配置比控制节点更精简主要聚焦于OVS Agent。第一步安装软件包# 在计算节点上执行 yum install -y openstack-neutron-openvswitch ebtables ipset第二步配置核心文件编辑以下文件内容与控制节点类似但有关键区别/etc/neutron/neutron.conf[DEFAULT]段的transport_url和[database]段留空计算节点不连接数据库[keystone_authtoken]段的auth_url和www_authenticate_uri指向控制节点。/etc/neutron/plugins/ml2/openvswitch_agent.ini[ovs]段的local_ip必须改为计算节点自身的数据平面IP如192.168.4.144bridge_mappings与控制节点一致。第三步配置内核参数与控制节点完全相同echo net.bridge.bridge-nf-call-ip6tables 1 /etc/sysctl.conf echo net.bridge.bridge-nf-call-iptables 1 /etc/sysctl.conf modprobe br_netfilter sysctl -p第四步启动服务# 重启nova-compute systemctl restart openstack-nova-compute # 启动OVS Agent systemctl start neutron-openvswitch-agent systemctl enable neutron-openvswitch-agent4.3 验证与排错让Neutron真正“活”起来安装完成后必须进行系统性验证不能只看服务是否“running”。第一步检查Agent状态在控制节点上执行openstack network agent list你应该看到类似输出---------------------------------------------------------------------------------------------------------------------------------- | ID | Agent Type | Host | Availability Zone | Alive | State | Binary | ---------------------------------------------------------------------------------------------------------------------------------- | 2df818b0-e911-4e5a-8c53-1ae85e387caa | Open vSwitch agent | controller | None | :-) | UP | neutron-openvswitch-agent | | 8a1711ee-9772-4931-af61-eed89024ff04 | L3 agent | controller | nova | :-) | UP | neutron-l3-agent | | cff39707-e34b-4cc7-9be0-95bbe281a5b9 | Metadata agent | controller | None | :-) | UP | neutron-metadata-agent | | e4949796-9f35-40b4-aba0-781ee7ce9a31 | DHCP agent | controller | nova | :-) | UP | neutron-dhcp-agent | | efd5fa9a-9b0e-447f-8ddc-13755efdd999 | Open vSwitch agent | compute | None | :-) | UP | neutron-openvswitch-agent | ----------------------------------------------------------------------------------------------------------------------------------Alive列显示:-)表示心跳正常State为UP表示服务在线。如果某个Agent显示XXX或DOWN请