openstack项目【day23】：Neutron实现网络虚拟化
本节内容
- 一 Neutron概述
- 二 neutron openvswitch+gre/vxlan虚拟网络
- 三 neutron ovs opnflow流表和l2 population
- 四 dhcp agent和l3 agent
- 五 MTU问题
一 Neutron概述
管理网络：包含api网络（public给外部用，admin给管理员用-是内部ip，internal给内部用-是内部ip）
数据网络
存储网络
IDRAC网络
PXE网络
控制节点相关服务
systemctl status chronyd.service systemctl status mariadb.service systemctl status mongod.service systemctl status rabbitmq-server.service systemctl status memcached.service systemctl status httpd.service systemctl status openstack-glance-api.service \ openstack-glance-registry.service systemctl status openstack-nova-api.service \ openstack-nova-consoleauth.service openstack-nova-scheduler.service \ openstack-nova-conductor.service openstack-nova-novncproxy.service systemctl status neutron-server.service
计算节点相关服务
systemctl status libvirtd.service openstack-nova-compute.service systemctl status neutron-openvswitch-agent.service
网络节点相关服务
systemctl status neutron-openvswitch-agent.service neutron-l3-agent.service \ neutron-dhcp-agent.service neutron-metadata-agent.service
验证时间服务（在所有节点执行）：
chronyc sources
验证keystone（在控制节点）
soure admin-openrc openstack token issue
验证glance服务（在控制节点）
openstack image list
验证compute服务（在控制节点）
openstack compute service list
验证glance服务（在控制节点）
openstack image list
二 neutron openvswitch+gre/vxlan虚拟网络
gre不足：
1.点对点，所有的计算节点和网络节点都会建立GRE Tunnel，规模扩大，效率极其的低下
2.扩大的广播域，GRE不支持组播，一个网络（GRE Tunnel ID一样）中的一个vm发出广播帧后，GRE 会将其广播到所有与该节点有隧道连接的节点。
3.GRE 封装的IP包的过滤和负载均衡问题
目前还是有很多的防火墙和三层网络设备无法解析 GRE Header，因此它们无法对 GRE 封装包做合适的过滤和负载均衡。
VxLAN 主要用于封装、转发2层报文。VXLAN 全称 Virtual eXtensible Local Area Network，简单的说就是扩充了的 VLAN，其使得多个通过三层连接的网络可以表现的和直接通过一台一台物理交换机连接配置而成的网络一样处在一个 LAN 中。
它的实现机制是，将二层报文加上个 VxLAN header，封装在一个 UDP 包中进行传输。VxLAN header 会包括一个 24 位的 ID（称为VNI），含义类似于 VLAN id 或者 GRE 的 tunnel id。GRE 一般是通过路由器来进行 GRE 协议的封装和解封的，在 VXLAN 中这类封装和解封的组件有个专有的名字叫做 VTEP。相比起 VLAN 来说，好处在于其突破了VLAN只有 4000+ 子网的限制，同时架设在 UDP 协议上后其扩展性提高了不少（因为 UDP 是高层协议，屏蔽了底层的差异，换句话说屏蔽了二层的差异）。
报文封装
http://www.cnblogs.com/xingyun/p/4620727.html
VXLAN和GRE都是虚拟的二层物理的三层，arp广播也可以通过物理的三层取转发，这样效率就低了，于是有SDN和l2population Driver
http://www.cnblogs.com/linhaifeng/p/6569539.html
三 neutron ovs opnflow流表和l2 population
arp_responder 的原理不复杂。Neutorn DB 中保存了所有的端口的 MAC 和 IP 地址数据。而 ARP 就是一个虚机要根据另一个虚机的 IP 地址查询它的 MAC。因此，只需要 Neutron server 通过 RPC 告诉每个计算节点上的 ML2 agent 所有活动端口的 MAC 和 IP，那么就可以将 br-tun 变成一个供本机适用的 ARP Proxy，这样本机上的虚机的 ARP 请求的响应就可以由 br-tun 在本地解决。Assaf Meller 有篇文章来阐述 ARP Responder。
使用 ARP Responder 需要满足两个条件：
（1）设置 arp_responder = true 来使用 OVS 的ARP 处理能力 。这需要 OVS 2.1 （运行 ovs-vswitchd --version 来查看 OVS 版本） 和 ML2 l2population 驱动的支持。当使用隧道方式的时候，OVS 可以处理一个 ARP 请求而不是使用广播机制。如果 OVS 版本不够的话，Neutorn 是无法设置 arp responder entry 的，你会在 openvswitch agent 日志中看到 “Stderr: '2015-07-11T04:57:32Z|00001|meta_flow|WARN|destination field arp_op is not writable\novs-ofctl: -:2: actions are invalid with specified match (OFPBAC_BAD_SET_ARGUMENT)\n'”这样的错误，你也就不会在 ”ovs-ofctl dump-flows br-tun“ 命令的输出中看到相应的 ARP Responder 条目了。
（2）设置 l2_population = true。同时添加 mechanism_drivers = openvswitch,l2population。OVS 需要 Neutron 作为 SDN Controller 向其输入 ARP Table flows。
四 dhcp agent和l3 agent
网络节点上neutron提供基于dnsmas（轻型的dns和dhcp服务）实现dhcp服务，
每个网络都独有自己的dhcp和router，二者被一个特定网络内的主机共享，在namespace内
五 MTU问题
VXLAN 模式下虚拟机中的 mtu 最大值为1450，也就是只能小于1450，大于这个值会导致 openvswitch 传输分片，进而导致虚拟机中数据包数据重传，从而导致网络性能下降。GRE 模式下虚拟机 mtu 最大为1462。
计算方法如下：
- vxlan mtu = 1450 = 1500 – 20(ip头) – 8(udp头) – 8(vxlan头) – 14(以太网头)
- gre mtu = 1458 = 1500 – 20(ip头) – 8(gre头) – 14(以太网头)
可以配置 Neutron DHCP 组件，让虚拟机自动配置 mtu，官方文档链接 http://docs.openstack.org/juno/install-guide/install/yum/content/neutron-network-node.html
重启 DHCP Agent，让虚拟机重新获取 IP，然后使用 ifconfig 查看是否正确配置 mtu。
#/etc/neutron/dhcp_agent.ini [DEFAULT] dnsmasq_config_file = /etc/neutron/dnsmasq-neutron.conf #/etc/neutron/dnsmasq-neutron.conf dhcp-option-force=26,1450或1458
