做了两层OpenStack之后我越来越觉得网络服务是整个平台里最考验耐心、也最出彩的一环。前面几篇已经搞定控制节点的基础软件、认证、镜像、计算等模块这一篇终于轮到网络服务的主角Neutron登场而且是在控制节点上把核心骨架全部搭起来。如果你是从零开始照着系列文部署那么上一章完成Nova的安装之后就可以直接进入网络服务的控制节点安装流程了。我用的发行版是CentOS 7 Train版本属于Train底层网络采用Linuxbridge VXLAN的方案。选这套组合的原因后面会专门说但你先记住一个结论在控制节点上Neutron涉及的服务不少包括neutron-server、Linuxbridge agent、DHCP agent、metadata agent还有数据库、Keystone凭证、API endpoint再加上与Nova联动的那几行配置。任何一个环节漏掉后面创建网络、拉起虚拟机的时候都会莫名其妙地报错。这篇内容我会把控制节点的网络服务安装过程完整走一遍包括配置文件的每个关键参数的逻辑以及我踩过的坑。还是老规矩命令和配置都以CentOS 7 Train为准其他发行版或版本在包名、配置路径上会略有差异但对理解原理影响不大。1. 网络服务在控制节点上的整体设计拆解1.1 为什么控制节点要装这么多样东西先理清一个问题OpenStack的网络服务不等于简单的一个进程而是一组分工明确的服务协同工作。在控制节点上我们至少需要跑起来以下几类角色neutron-server负责接收API请求比如创建网络、创建子网、创建端口以及把请求分发给各插件和Agent。这个进程是绝对核心没它什么都玩不了。Linuxbridge agent如果你用Open vSwitch则对应为openvswitch-agent管理实际虚拟交换机处理二层转发和VXLAN隧道封装。控制节点部署该agent主要是为了处理流量转发以及支持安全组、VXLAN广播等动作。DHCP agent为租户网络提供DHCP服务负责给虚拟机分配IP地址。metadata agent负责把虚拟机内请求的metadata信息如主机名、密钥注入、用户数据转发给Nova metadata服务完成实例初始化。这四个角色在控制节点上要协同工作同时又依赖数据库Neutron自身的库、Keystone认证和鉴权、RabbitMQ消息队列各agent与server之间的通信总线、以及Nova计算服务需要与Neutron完成计算节点与网络节点的联动。所以在控制节点上这一组服务安装下来整个平台的神经系统基本就接上了。1.2 为什么选Linuxbridge而不是Open vSwitch部署方案首先要回答一个选型问题用Linuxbridge还是OVS。在生产环境中OVS的灵活性更高功能也更丰富比如支持流表控制、QoS上限配置、分布式虚拟路由DVR等。但在我这套教学部署和中小规模场景下我反而推荐Linuxbridge原因是它依赖的内核模块更少、排查二层问题更直接而且与Neutron的配置对应关系非常直观新手不容易迷路。Linuxbridge在VXLAN网络中扮演的角色是在每台宿主机上创建虚拟网桥把虚拟机网卡桥接进来同时根据VXLAN接口进行二层隧道的封装和解封装。控制节点上同样需要这么一套机制因为控制节点虽然不运行虚拟机但它需要接入网络并且承担路由、metadata等网络的连通性任务。注意如果后续要使用DVR、FWaaS、VPNaaS这些高级网络功能OVS会是更可靠的底子。但如果你主要是为了跑通Train部署、做实验、或者搭建中小规模私有云Linuxbridge完全没有问题而且维护成本更低。1.3 本次安装的网络拓扑与IP规划为了让后面的配置不迷路我先把这套环境的IP和网段规划写清楚你后面配置任何文件都可以对照着看。假设我们有三个节点控制节点、计算节点1、计算节点2本次重点在控制节点计算节点在下一章讲。节点管理网IP数据网VXLAN隧道IP角色控制节点10.10.20.1110.10.21.11neutron-server / agent / dhcp / metadata计算节点110.10.20.1210.10.21.12linuxbridge-agent nova-compute计算节点210.10.20.1310.10.21.13linuxbridge-agent nova-compute管理网主要用于API、数据库、消息队列等控制面通信数据网用于承载VXLAN隧道和实例流量。实际生产环境还会区分存储网络、外部网络等但实验环境我不想把拓扑搞得过于复杂否则排查问题的时候会被网络层级绕晕。VXLAN的网络ID范围在配置里会用到默认从100开始手动规划一个较大数值避免与VLAN ID冲突。比如我们用1001、1002来代表不同的租户网络。这里顺带说一下为什么用VXLAN而不是VLANVLAN只有4094个可用ID对大规模多租户场景不够用而VXLAN通过UDP封装可以支持上千万个逻辑网络而且天然适合跨三层组网。当然代价是报文头变大MTU需要相应调大隧道一般建议把物理MTU设到1600以上或者实例内部采用MTU 1450。2. 安装前的数据库与认证准备2.1 在数据库中创建Neutron实例Neutron服务需要自己的数据库这个库主要存网络、子网、端口、路由、安全组、DHCP租约等对象。在我的部署习惯里数据库字符集统一使用utf8避免后续有中文注释或特殊字符时出现存储问题。mysql -u root -p进入MySQL后执行CREATE DATABASE neutron; GRANT ALL PRIVILEGES ON neutron.* TO neutronlocalhost IDENTIFIED BY NEUTRON_DBPASS; GRANT ALL PRIVILEGES ON neutron.* TO neutron% IDENTIFIED BY NEUTRON_DBPASS; FLUSH PRIVILEGES; EXIT;这里有两个细节值得留意。第一主机名%不能省略因为控制节点上的服务可能通过管理网IP连接数据库而不仅仅是localhost第二密码不要用我写的NEUTRON_DBPASS当生产密码至少换成16位以上的随机字符串等安装完以后再统一回收密码。可能有人会问为什么Neutron的数据库授权要比Nova等组件多出%这个其实是为了后续扩展高可用或者多控制节点做准备。如果你的环境只有单控制节点也可以只授权localhost但代码习惯里我会一并加上%。2.2 创建服务凭证与API Endpoint这一节做的事情是让Neutron在OpenStack的世界里有合法身份。在OpenStack中每个服务都需要在Keystone注册用户、赋予admin角色然后登记service实体和endpoint。这样后续无论是命令行调用还是各组件之间互相访问都能完成认证和路由。首先要引入管理员环境变量。按系列文章一直以来的约定我的凭据文件放在 /root/keystonerc_admin 里source /root/keystonerc_admin创建neutron用户openstack user create --domain default --password-prompt neutron按提示输入密码例如NEUTRON_PASS。然后把该用户加入服务项目service项目并赋予admin角色openstack role add --project service --user neutron admin创建neutron服务实体和Endpointopenstack service create --name neutron --description OpenStack Networking network openstack endpoint create --region RegionOne network public http://10.10.20.11:9696 openstack endpoint create --region RegionOne network internal http://10.10.20.11:9696 openstack endpoint create --region RegionOne network admin http://10.10.20.11:9696你可能已经注意到三个endpoint的URL完全一样。这是单控制节点下最常见的配置也就是public、internal、admin三类网络入口指向同一个地址。生产环境如果做了分离可以把internal和admin指向管理网内网地址public指向对外提供服务的外网地址。执行完成后强烈建议用openstack endpoint list检查一遍输出确认network服务存在三条endpoint而且URL中没有任何的拼写错误。这个环节我经常看到有人把network误写成networking导致后续neutron命令报“Endpoint not found”之类的认证异常。2.3 安装Neutron软件包在CentOS 7 Train环境下需要安装的软件包如下yum install -y openstack-neutron openstack-neutron-linuxbridge openstack-neutron-dhcp-agent openstack-neutron-metadata-agent ebtables注意这里并不是安装openstack-neutron一个包就结束。openstack-neutron是主服务linuxbridge是二层agentdhcp-agent提供DHCP功能metadata-agent处理实例内的元数据请求。ebtables用于提供二层防火墙和安全组规则的底层支持。还有一个细节某些版本中如果你需要ML2插件配置工具包名可能是openstack-neutron-ml2但在Train上通常已经被合并到openstack-neutron里。用下面的命令快速确认安装结果rpm -qa | grep openstack-neutron安装完成后目录结构会很清晰 /etc/neutron/ 里会有neutron.conf、plugins/ml2/ml2_conf.ini、dhcp_agent.ini、metadata_agent.ini、l3_agent.ini虽然目前可能用不到等文件。我们后面所有的修改都围绕这几个文件展开。3. 编辑核心配置文件neutron.conf3.1 配置数据量、连接与消息队列neutron.conf是Neutron的主配置文件几乎所有的通用行为都受它控制。编辑之前建议先备份原文件养成好习惯cp /etc/neutron/neutron.conf /etc/neutron/neutron.conf.bak然后修改/etc/neutron/neutron.conf。在[database]部分设置数据库连接connection mysqlpymysql://neutron:NEUTRON_DBPASS10.10.20.11/neutron在[DEFAULT]部分启用Modular Layer 2插件并指定消息队列与认证方式core_plugin ml2 service_plugins router allow_overlapping_ips true transport_url rabbit://openstack:RABBIT_PASS10.10.20.11 auth_strategy keystone notify_nova_on_port_status_changes true notify_nova_on_port_data_changes true其中service_plugins router表示启用路由服务插件也就是三层路由功能后续创建外部网络和租户路由器时会用到。这里还得提醒一点allow_overlapping_ips 如果不配置多个租户之间就不能使用相同的IP段。如果你在实验环境想模拟多租户隔离这个选项必须开。在[keystone_authtoken]部分配置与Keystone集成[keystone_authtoken] www_authenticate_uri http://10.10.20.11:5000 auth_url http://10.10.20.11:5000 memcached_servers 10.10.20.11:11211 auth_type password project_domain_name default user_domain_name default project_name service username neutron password NEUTRON_PASS3.2 配置Nova联动Neutron需要通知Nova关于端口状态的变化比如虚拟机网卡拔出、插入、故障等事件。没有这段配置热迁移和故障处理时会缺少关键信息。在[nova]部分加入[nova] auth_url http://10.10.20.11:5000 auth_type password project_domain_name default user_domain_name default region_name RegionOne project_name service username nova password NOVA_PASS同时还需要在Nova的主配置文件/etc/nova/nova.conf中把[neutron]部分补齐[neutron] url http://10.10.20.11:9696 auth_url http://10.10.20.11:5000 auth_type password project_domain_name default user_domain_name default region_name RegionOne project_name service username neutron password NEUTRON_PASS service_metadata_proxy true metadata_proxy_shared_secret METADATA_SECRET这里的 metadata_proxy_shared_secret 必须和后面 metadata_agent.ini 里的密钥一致否则虚拟机在获取metadata时会出现403。这个坑非常经典几乎所有从零部署的人在启动实例以后发现cloud-init失败最后查下来都是这个密钥没对上。3.3 配置ML2插件ML2是Neutron的核心二层插件它本身不负责具体的网络接入技术而是把各种机制驱动例如linuxbridge、openvswitch统一抽象起来。在Train版本中配置文件位于/etc/neutron/plugins/ml2/ml2_conf.ini。我在这套环境里使用VXLAN作为租户网络的封装方式同时保留VLAN用于物理网络分隔。配置如下[ml2] type_drivers flat,vlan,vxlan tenant_network_types vxlan mechanism_drivers linuxbridge extension_drivers port_security [ml2_type_flat] flat_networks physnet1 [ml2_type_vlan] network_vlan_ranges physnet1:100:200 [ml2_type_vxlan] vni_ranges 1001:2000 [securitygroup] enable_ipset true firewall_driver neutron.agent.linux.iptables_firewall.NeutronFirewallProxy每个参数都有实际含义type_drivers声明支持的网络类型。flat用于外部网络的扁平接入vlan用于物理交换机上的VLAN划分vxlan用于软件隧道。我全部声明出来方便后续网络类型多样化。tenant_network_types指定租户创建网络时默认使用的类型。这里选择vxlan意味着用户在Dashboard上创建网络时如果不特别指定就自动用VXLAN。mechanism_drivers使用linuxbridge作为机制驱动。这里有个关键点你不能同时配置linuxbridge和openvswitch两种机制驱动否则会导致VXLAN接口创建方式冲突底层的转发逻辑会乱掉。extension_drivers启用port_security扩展这在默认安全组场景下是必须的。vni_rangesVXLAN网络ID范围。我用1001到2000避开VLAN ID 100-200段保证视觉上不容易混淆。firewall_driver安全组底层实现。Train版本推荐使用NeutronFirewallProxy它会在宿主机上通过iptables实现安全组规则。在[linux_bridge]部分需要指定物理网卡的映射关系。我的数据网网卡是 ens5以你的环境为准用ip addr确认配置如下[linux_bridge] physical_interface_mappings physnet1:ens5这句的意思是ML2中定义的“物理网络名physnet1”对应宿主机上实际的物理网卡ens5。外部网络将来要绑定物理网络时就会通过这张网卡走流量。如果你配置错了后面创建外部网络并绑定物理网络后会直接无法通信而且很难排查。注意这里映射的物理网卡在控制节点上必须承载数据网IP10.10.21.11因为VXLAN隧道需要它来传输。如果你混用了管理网网卡VXLAN流量会和管理面抢带宽生产环境里是不允许这么干的。3.4 配置Linuxbridge AgentLinuxbridge agent的配置文件是/etc/neutron/plugins/ml2/linuxbridge_agent.ini。它主要做两件事一是桥接虚拟机网卡和物理网卡二是提供VXLAN隧道的本地IP。[linux_bridge] physical_interface_mappings physnet1:ens5 [vxlan] enable_vxlan true local_ip 10.10.21.11 l2_population true [securitygroup] enable_security_group true firewall_driver neutron.agent.linux.iptables_firewall.NeutronFirewallProxyl2_population true是个值得展开讲的选项。它开启二层地址学习模式各Agent之间会通过消息队列交换MAC地址和ARP表项。这样做的好处是VXLAN网络在没有大量广播流量时依然可以正常工作减少了广播对网络的压力。在规模稍大的场景下这个选项几乎都是开启的否则每个新虚拟机上线都会触发一次全网ARP泛洪那种体验非常酸爽。控制节点的 local_ip 必须写数据网IP也就是10.10.21.11而不是管理网IP。这里我吃过亏最初图省事直接填了管理网IP结果VXLAN隧道能建立但数据包走的是管理网络导致一旦管理网络拥塞所有实例的内部通信都跟着卡顿。3.5 配置DHCP Agent和Metadata AgentDHCP agent的配置文件是/etc/neutron/dhcp_agent.ini。它负责给子网分配IP包含一些影响使用体验的参数[DEFAULT] interface_driver linuxbridge dhcp_driver neutron.agent.linux.dhcp.Dnsmasq enable_isolated_metadata true force_metadata trueinterface_driver linuxbridge让DHCP agent通过linuxbridge管理网络命名空间里的虚拟网卡。enable_isolated_metadata true即使网络没有连接外部路由器也允许实例获取metadata这一点在隔离的租户网络里非常关键。force_metadata true不管网络是否连接到外部网络都强制提供metadata服务否则在只有租户网络而没有外部网络时实例拿不到hostname和公钥等初始化信息。metadata agent的配置文件是/etc/neutron/metadata_agent.ini[DEFAULT] nova_metadata_host 10.10.20.11 metadata_proxy_shared_secret METADATA_SECRET这里的密钥与前面nova.conf里的metadata_proxy_shared_secret必须一致。另外nova_metadata_host 写的是Nova API所在地址也就是控制节点的管理IP不是数据网IP因为metadata请求需要回源到Nova服务获取实例数据。3.6 配置sysctlLinuxbridge VXLAN需要在宿主机上打开网桥相关的内核参数。修改/etc/sysctl.confnet.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1然后使配置生效。需要注意的是如果系统还没有加载br_netfilter模块直接执行sysctl -p可能会提示找不到文件所以先加载模块modprobe br_netfilter sysctl -p这个配置的作用是让通过Linux网桥的流量也能经过iptables规则这样安全组才能对虚拟机的流量生效。如果不开启安全组规则的防护会直接被绕过实例之间可以随意互通这是一个非常隐蔽的安全隐患。4. 数据库同步与服务启动4.1 初始化Neutron数据库所有配置就位后需要执行数据库同步。这一步会把配置中定义的表结构写入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 neutron执行过程会输出很多日志正常会看到类似Running upgrade for ...的进度。如果中途报错多半是数据库连接URL有误、密码不对或者某个配置文件中的插件路径写错。同步完成后用MySQL确认一下表是否生成mysql -u root -p -e use neutron; show tables;正常应该能看到几十张表比如networks、subnets、ports、ml2_vxlan_allocations、securitygroups等。如果一张表都没有说明数据库同步没成功此时不能急着启动服务先回头检查日志和配置文件。4.2 创建符号链接并启用服务安装后通常还需要把ML2的配置文件链接到Neutron默认寻找的位置。在CentOS上执行ln -s /etc/neutron/plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini这个链接不是可有可无的很多服务启动脚本会默认读取/etc/neutron/plugin.ini如果你不创建启动时会出现“找不到配置文件”的报错。接下来统一启动Neutron相关服务并设置开机自启systemctl enable neutron-server neutron-linuxbridge-agent neutron-dhcp-agent neutron-metadata-agent systemctl restart neutron-server neutron-linuxbridge-agent neutron-dhcp-agent neutron-metadata-agent启动不是终点检查状态才是重点。依次执行systemctl status neutron-server systemctl status neutron-linuxbridge-agent systemctl status neutron-dhcp-agent systemctl status neutron-metadata-agent我见过很多人只看systemd状态为running就觉得万事大吉但Neutron服务在启动后如果有配置错误会在一段时间后主动退出。所以正确的姿势是等几十秒后再次查看状态同时看日志tail -f /var/log/neutron/server.log如果一切正常server.log里会看到类似Neutron service started的日志。另外计算节点上的Neutron服务如果是本机也装了agent的话也会在这时候连上控制节点但它们属于下一章的内容这里不展开。4.3 重启Nova服务以加载Neutron配置因为我们修改了nova.conf里的neutron配置所以需要重启Nova相关服务让配置生效systemctl restart nova-api nova-novncproxy nova-conductor nova-scheduler重启后在Nova日志中不应该看到关于Neutron连接失败的报错。如果之前Nova的API已经在运行这一步往往会被遗漏结果就是后续创建虚拟机时Nova无法正确调用Neutron给实例分配端口。4.4 验证控制节点网络服务是否正常这里我提供一组指令帮助你确认安装是否成功。先重新加载管理员环境变量并查看Agent状态source /root/keystonerc_admin openstack network agent list正常情况下控制节点上应该能看到三个AgentLinux bridge agent状态为“:-)”或“up”主机名为控制节点主机名。DHCP agent状态为“:-)”。Metadata agent状态为“:-)”。如果某个Agent显示“xxx”或“down”需要根据日志进一步排查。最常见的两个原因一是消息队列通信异常二是配置文件里的IP或密码不一致。再看一下Neutron服务端点openstack endpoint list --service network确认存在三条Endpoint。然后试着创建一个最简单的网络openstack network create test-net openstack subnet create --network test-net --subnet-range 192.168.100.0/24 --gateway 192.168.100.1 test-subnet如果创建成功说明控制节点的Neutron API、ML2插件、数据库、Keystone认证都是一条龙打通的。如果第一个命令就报错建议先执行openstack network list看看是不是认证问题如果能列出网络但创建报错检查ML2配置和日志。5. 实操过程中踩过的坑与排查思路5.1 Linuxbridge Agent 状态一直down这是我在控制节点安装中最常遇到的问题。openstack network agent list里linuxbridge agent显示“xxx”但systemd又是active状态。排查思路如下。先检查agent日志tail -f /var/log/neutron/linuxbridge-agent.log如果日志中反复出现“No module named neutron.plugins.ml2...”一般是安装包不完整或者版本混源导致重新yum install -y openstack-neutron-linuxbridge即可。如果日志出现“Error while polling...”, 优先排查rabbitmq连接确认transport_url中的账号密码和rabbitmq实际创建的一致。另外还要检查VXLAN是否被系统支持ls /sys/class/net/ | grep vxlan ip link add vxlan-test type vxlan id 1001 remote 10.10.20.11 dstport 4789 dev ens5如果第二条命令报错说明内核模块不支持VXLAN或者物理网卡不支持VXLAN offload。多数情况下运行modprobe vxlan可以解决。5.2 实例创建后拿不到IP这个坑在控制节点装完DHCP agent后依然会出现。如果实例内部用ip addr看发现没有IP先看DHCP agent是否已经分配地址openstack network agent list --dhcp-agent再检查DHCP命名空间ip netns list正常可以看到类似 qdhcp-网络ID 的命名空间。如果没有说明子网的DHCP服务没启动检查dhcp_agent.ini里interface_driver是否配置正确。如果有命名空间可以进入命名空间里手动测试DHCP发现机制ip netns exec qdhcp-网络ID ip addr然后检查 DHCP 配置端口是否在命名空间内。我在一次实验中碰到过dnsmasq进程启动立即崩溃日志显示端口被占用。排查下来是之前残留的dnsmasq进程没有清干净用pkill dnsmasq后重启dhcp-agent解决。5.3 metadata地址能ping通但cloud-init拉取数据失败虚拟机内部通常可以通过curl http://169.254.169.254/latest/meta-data获取metadata。如果ping不通或者curl超时多数是metadata agent和nova api之间的密钥不一致。遇到这个问题时直接在虚拟机内部执行curl -v http://169.254.169.254/latest/meta-data观察是否返回403。如果403说明请求到达了metadata agent但共享密钥校验失败。这时去控制节点依次确认nova.conf和metadata_agent.ini两个文件中的metadata_proxy_shared_secret完全一致然后重启neutron-metadata-agent和nova-api。还有一个容易被忽略的点虚拟机内部的默认路由必须指向DHCP分配的网关。如果网关不对metadata请求虽然从169.254.169.254发出但网络栈无法走到宿主机的路由表。5.4 安全组规则不生效安全组依赖linuxbridge agent iptables。如果你发现安全组放行规则后虚拟机之间还是互相能ping通极有可能是net.bridge.bridge-nf-call-iptables内核参数没有开启或者br_netfilter模块没有加载。重新检查sysctl net.bridge.bridge-nf-call-iptables如果输出为0按前面说的方式加载并生效。另外确认linuxbridge_agent.ini里firewall_driver指向的还是iptables防火墙驱动。如果你曾把防火墙驱动切换到其他实现安全组规则就不会下发到iptables里。5.5 创建外部网络/路由器时出错在控制节点上是真正意义上把外部网络真正打通的地方因为我需要把租户网络与外部网络通过路由器连接。配置外部网络时必须指定--provider-physical-network physnet1 --provider-network-type flat。如果创建时报“物理网络不存在”要么是ml2_conf.ini里flat_networks没有声明要么是linuxbridge agent里physical_interface_mappings写错了映射。创建完外部网络和路由器后在路由器接口中加入内部网络然后去控制节点查看命名空间ip netns list | grep qrouter能看到qrouter开头的命名空间就说明三层路由服务正常。再进入命名空间检查路由器接口是否拿到了预期的IPip netns exec qrouter-路由器ID ip addr如果没有任何qrouter命名空间说明Neutron L3服务并没有启用。注意我现在安装的是train版本其实Train的包已经包含L3 agent但服务名不一定默认启用。如果你发现系统里根本没有l3 agent需要另外安装yum install -y openstack-neutron然后编辑/etc/neutron/neutron.conf中service_plugins router并重启相关服务。这里再补一个很容易忽略的细节在传统控制节点非DVR模式上路由器命名空间只会出现在网络节点也就是我们当前的控制节点上虚拟机的流量会经过一层集中式路由。这个模式下所有南北向流量都会汇聚到控制节点需要注意控制节点网卡带宽是否足够。如果后续规模扩大可以考虑启用DVR将路由流量分散到计算节点。5.6 常见问题速查表现象排查点处理方式neutron-server启动失败/var/log/neutron/server.log 中的ERROR检查数据库连接、Keystone密码、rabbitmq配置agent状态为downagent日志是否报连接异常检查transport_url、rabbit账号密码、hostname解析创建网络超时消息队列或数据库压力查看neutron-server日志确认API请求是否到达实例无IPdhcp-agent状态与dnsmasq日志检查命名空间是否创建必要时重启dhcp-agent和nova-computemetadata失败169.254.169.254是否可达检查metadata proxy共享密钥和各agent是否启动安全组失效iptables规则是否存在检查br_netfilter模块和bridge-nf-call-iptables参数6. 控制节点安装完成后的整体检查与后续衔接当所有服务都启动完毕上面的验证也都通过了控制节点的网络服务安装就算基本完成。但我还是建议你系统性做一轮全面的联调检查而不仅仅是验证单独一个组件。以下是我每次装完控制节点后固定要走的检查流程。第一件事再次确认Neutron的相关服务在重启后保持存活。机器重启后每个服务都应该自动拉起。我用一条命令批量查看openstack network agent list systemctl list-units | grep neutron第二件事创建一个完整的最小业务链网络外部网络、内部网络、路由器、租户、安全组规则。然后等计算节点也装好后直接启动一台测试虚拟机验证网络连通性。网络服务毕竟是所有服务的底座控制节点装得再顺利最后都要拉到真实实例上检验效果。第三件事检查日志有没有隐藏错误。很多人只看服务状态为running就不再管了但Neutron有哪些后台线程出错可能并不会导致服务退出只会持续在日志里报错。我一般会这样搜索级联错误grep -i ERROR /var/log/neutron/*.log | grep -v NotFound | tail -50如果发现大量关于“agent is not reachable”之类的日志先冷静排查不要直接重启。通常Agent和server之间的心跳超时会导致这类问题。这里再分享一个亲历过的例子我当时在控制节点装完后发现所有服务正常agent状态也是up但一到创建子网或路由的时候操作响应非常慢最终还超时。后来查出来是RabbitMQ所在主机名解析有问题服务之间通过消息队列通信时启用不了心跳机制导致有些消息在队列里积压。解决方式是确认/etc/hosts里已经把控制节点和计算节点的主机名都映射到了正确的管理IP。7. 从控制节点到计算节点的衔接要点这一篇虽然集中在控制节点安装但与计算节点的衔接点有必要提前交代清楚。因为网络服务不完全是控制节点的事计算节点上也要安装linuxbridge agent等组件否则虚拟机根本没法接入Overlay网络。控制节点和计算节点之间的合作方式如下。计算节点的Nova Compute服务通过消息队列与Nova的调度服务通信虚拟机创建时Nova会在所选计算节点上创建实例然后调用Neutron API去创建并绑定端口。这个端口信息会传递给计算节点上的Linuxbridge agent去做实际桥接。因此控制节点这边要保证Neutron API可访问而且Nova已经正确配置了Neutron的访问参数。此外Neutron的Agent与server之间的消息队列主题也需要一致。这些可以在后续安装计算节点时验证。我也建议你在控制节点装完后先不要急着给计算节点加网络服务而是先在控制节点上把网络动作都试一遍包括创建网络、子网、路由、安全组确保控制面完全正常后再到计算节点那边去对接数据面。这样定位问题时能快速区分故障是出在控制面还是数据面。另外控制节点上的网络命名空间在后续实验中会越来越多例如qdhcp和qrouter开头的命名空间。如果你在宿主机上使用原生的网络管理工具如NetworkManager需要留意它不要干扰这些命名空间否则虚拟机的网络故障会很诡异。我在实际部署中一般会关闭NetworkManager对网卡的管理统一由systemd-networkd或者手动配置网络脚本接管。我个人在实际操作中的体会是Neutron控制节点的安装难点不在于每个服务的单独安装而在于彼此之间的依赖关系极其密集。数据库、Keystone、RabbitMQ、Nova任何一个环节出现配置错位最终都会以某种诡异的网络故障形式暴露出来。所以我最建议你在动手前先把整个配置链的账号密码、IP地址都列成一张表然后按图索骥去改配置。不要一个文件改到一半又被其他事情打断那种状态下最容易出错。最后再分享一个细节Neutron的日志是分服务记录的比如server.log、linuxbridge-agent.log、dhcp-agent.log、metadata-agent.log。排障时不要只看一个日志而是要把相关的日志组合起来看。比如虚拟机拿不到IP我通常同时看dhcp-agent.log、nova-compute.log、linuxbridge-agent.log这样才能还原“请求到哪一步断了”的全貌。网络服务本身就像一张网排查问题也必须有个网状的思路单点思维很容易把人带偏。到了这一步控制节点的网络服务已经具备雏形后续计算节点安装完成后就可以回到控制节点这边创建完整网络并启动第一台实例。下一篇文章我会继续记录计算节点上网络服务的安装与联动过程。
