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

　　

时间： 2024-10-11 15:34:20

openstack项目【day23】：Neutron实现网络虚拟化的相关文章

Neutron实现网络虚拟化

熬了好几宿才整理出来,发表到博客园了,欢迎拍砖,因本人所在公司相关问题,copy及其衍生版必须加上出处 http://www.cnblogs.com/linhaifeng/p/6577199.html

openstack之Neutron网络虚拟化

第一:为什么需要网络虚拟化? 一.数据中心的现有网络不能满足云计算的物理需求: 互联网行业数据中心的基本特征就是服务器的规模偏大.进入云计算时代后,其业务特征变得更加复杂,包括:虚拟化支持.多业务承载.资源灵活调度等(如下图所示).与此同时,互联网云计算的规模不但没有缩减,反而更加庞大.这就给云计算的网络带来了巨大的压力. 互联网云计算业务特点 1. 大容量的MAC表项和ARP表项 虚拟化会导致更大的MAC表项.假设一个互联网云计算中心的服务器有5000台,按照1:20的比例进行虚拟化,则有10

openstack项目【day23】：虚拟化介绍

本节内容 一 什么是虚拟化 二 为何要学习虚拟化 三 虚拟化技术主要分类(了解) 四 平台虚拟化技术又可以细分(了解) 一 什么是虚拟化 虚拟化说白了就是本来是一个完整的资源,切分或者说虚拟成多份,让这多份资源都使用起来,物尽其用,减少了浪费,提高了利用率,省了钱. 虚拟化(Virtualization)技术最早出现在 20 世纪 60 年代的 IBM 大型机系统,在70年代的 System 370 系列中逐渐流行起来. 在物理硬件之上安装软件:虚拟机监控器(Virtual Machine Mo

openstack M 版 neutron网络组件基础入门

在我们openstack学习当中,网络组件neutron无疑是令很多人很难理解的,可以说要深入理解 了neutron组件,你基本完成了openstack 60%的学习,存储方面只要不涉及到分布式,剩下的基本都比较简单了 相信很多人第一次看到这种图的时候都会被吓一跳,没错,这就是openstack  neutron组件里面涉及到的数据流程,里面涉及到的知识点很多很多 Openstack网络模型中的几个概念网络: Management Network: 管理网络,连接所有节点. External N

openstack运维实战系列(二十)之neutron创建网络并指定vlan号码

1. 背景说明   neutron在openstack中负责instance的网络,如虚拟机内部网络,虚拟机外部网络等,和实体网络相类似,openstack中的网络也存在路由器router,交换机switch,网络network,子网subnet,端口port等概念,这些功能都有neutron来完成,neutron由有个不同的插件plugins组成,如二层插件neutron-openvswitch-agent,三层插件neutron-l3-agent,动态地址分配neutron-dhcp-age

KVM 网络虚拟化基础 - 每天5分钟玩转 OpenStack（9）

网络虚拟化是虚拟化技术中最复杂的部分,学习难度最大. 但因为网络是虚拟化中非常重要的资源,所以再硬的骨头也必须要把它啃下来. 为了让大家对虚拟化网络的复杂程度有一个直观的认识,请看下图 这是 OpenStack 官网上给出的计算节点(可以理解为 KVM 的宿主机)虚拟网络的逻辑图,上面的网络设备很多,层次也很复杂.我第一次看到这张图,也着实被下了一跳. 不过大家也不要怕,万丈高楼从地起,虚拟网络再复杂,也是由一些基础的组件构成的.只要我们将这些基础组件的概念和它们之间的逻辑关系搞清楚了,就能深刻

OpenStack（Kilo版本）网络服务neutron的安装部署

Openstack网络主要是和OpenStack计算交互,提供网络连接到它的实例.一.OpenStack网络服务包含的组件 图1.1. OpenStack Nova组件 二.OpenStack网络节点基本环节的搭建1.配置主机名和网络信息1.1配置主机名 [email protected]:~# vim /etc/hostname network 1.2 配置IP地址 [email protected]:~# vim  /etc/network/interfaces auto eth0 ifac

[ Openstack ] Openstack-Mitaka 高可用之 网络服务(Neutron)

目录 Openstack-Mitaka 高可用之 概述    Openstack-Mitaka 高可用之 环境初始化    Openstack-Mitaka 高可用之 Mariadb-Galera集群部署    Openstack-Mitaka 高可用之 Rabbitmq-server 集群部署    Openstack-Mitaka 高可用之 memcache    Openstack-Mitaka 高可用之 Pacemaker+corosync+pcs高可用集群    Openstack-M

Neuron实现网络虚拟化

一 引子 数据中心虚拟化成为了趋势,最典型的场景莫过于:对数据中心的服务器进行虚拟化,来提高资源利用率,同时降低单位能耗. 但是,随着数据中心虚拟化程度的不断提高.虚拟化服务器规模的不断扩大,带来了巨大的管理压力.===>这就孕育了云计算诞生的条件. ps:在大规模虚拟化的基础上,实现了自动化管理和集中化管理,就是云计算的基本模型.这一点在互联网行业尤其重要. 云计算的超大规模带来了诸多亟需解决的问题,这些问题中,首当其冲的就是网络问题.而关于网络,云计算的超大规模带来的压力问题也并不代表全部,