【星海随笔】SDN neutron (二) Neutron-plugin(ML2)

【星海随笔】SDN neutron (二) Neutron-plugin(ML2)_第1张图片

Neutron架构之Neutron-plugin Core-plugin(ML2)篇

Neutron-server接收两种请求:

REST API请求:接收REST API请求,并将REST API分发到对应的Plugin(L3RouterPlugin)。
RPC请求:接收Plugin agent请求,分发到对应的Plugin(NeutronL3agent)。

Neutron-plugin分为Core-plugin和Service-plugin。

Core-plugin:ML2负责管理二层网络,ML2主要包括Network、Subnet、Port三类核心资源,对三类资源进行操作的REST API是原生支持的。
Service-plugin:实现L3-L7网络,包括Router、Firewall、VPN。
【星海随笔】SDN neutron (二) Neutron-plugin(ML2)_第2张图片

core-plugin

core-plugin(ML-2)
|- - - - - - - - - - - - - - - - - - - - - - - |
Type Manager(Vxlan) - - - - - - - Mechanism Manager(openvswitch )
每部分又分为Manager和Driver

【星海随笔】SDN neutron (二) Neutron-plugin(ML2)_第3张图片

执行流

_eventlet_wsgi_server():
service.serve_wsgi(service.NeutronApiService)
WsgiService.start
config.load_paste_app(app_name)
【星海随笔】SDN neutron (二) Neutron-plugin(ML2)_第4张图片

neutron.api.v2.router:APIRouter.factory

Neutron插件是Neutron的一个重要组成部分,它允许Neutron与不同的网络技术进行集成。
首先,我们需要安装Neutron插件。Neutron插件可以是Open vSwitch、Linux Bridge、Cisco Nexus、VMware NSX等。在安装Neutron插件之前,我们需要确保已经安装了Neutron服务。

以Open vSwitch为例,我们可以使用以下命令安装Open vSwitch插件:

sudo apt-get install neutron-plugin-openvswitch-agent 

安装Neutron插件后,我们需要配置它。配置文件通常位于/etc/neutron/plugins/目录下。以Open vSwitch为例,我们需要编辑/etc/neutron/plugins/ml2/ml2_conf.ini文件。

在该文件中,我们需要配置以下参数:

- type_drivers:指定支持的网络类型,例如vlan、vxlan等。
- tenant_network_types:指定租户网络类型,例如vlan、vxlan等。
- mechanism_drivers:指定网络机制驱动程序,例如Open vSwitch、Linux Bridge等。
- bridge_mappings:指定物理网络和虚拟网络之间的映射关系。

以下是一个示例配置文件:

[ml2] 
type_drivers = flat,vlan,vxlan 
tenant_network_types = vxlan
mechanism_drivers = openvswitch 

[ml2_type_flat] 
flat_networks = external 

[ml2_type_vxlan] 
vni_ranges = 1:1000 

[securitygroup] 
enable_security_group = True 
firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver 

[ovs] 
bridge_mappings = external:br-ex 

在上面的示例中,我们指定了Open vSwitch插件支持的网络类型为flat、vlan和vxlan。我们还指定了租户网络类型为vxlan,并将机制驱动程序设置为Open vSwitch。我们还指定了物理网络和虚拟网络之间的映射关系,例如将外部网络映射到br-ex网桥。
完成Neutron插件的配置后,我们需要重启Neutron服务以使配置生效。我们可以使用以下命令重启Neutron服务:

sudo service neutron-server restart 
sudo service neutron-plugin-openvswitch-agent restart 

neutron-plugin 分为 core-plugin 和 service-plugin 两类

L2-L3称为core plugin,包含network、subnet、port
L4-L7称为service plugin,包含router、firewall、loadbalancer、VPN、metering等等

Openstack neutron加载plugin
RESOURCES = {'network': 'networks',
             'subnet': 'subnets',
             'subnetpool': 'subnetpools',
             'port': 'ports'}
SUB_RESOURCES = {}
COLLECTION_ACTIONS = ['index', 'create']
MEMBER_ACTIONS = ['show', 'update', 'delete']
REQUIREMENTS = {'id': attributes.UUID_PATTERN, 'format': 'json'}
class APIRouter(wsgi.Router):

    @classmethod
    def factory(cls, global_config, **local_config):
        return cls(**local_config)

    def __init__(self, **local_config):
    	#创建mapper
        mapper = routes_mapper.Mapper()
        #获取NeutornManage的core_plugin,这个定义在/etc/neutron/neutron.conf,比如我的是core_plugin = ml2
        plugin = manager.NeutronManager.get_plugin()
        #扫描neutron/extensions下所有的extension
        ext_mgr = extensions.PluginAwareExtensionManager.get_instance()
        ext_mgr.extend_resources("2.0", attributes.RESOURCE_ATTRIBUTE_MAP)

        col_kwargs = dict(collection_actions=COLLECTION_ACTIONS,
                          member_actions=MEMBER_ACTIONS)
		#构建映射规则函数
        def _map_resource(collection, resource, params, parent=None):
            allow_bulk = cfg.CONF.allow_bulk
            allow_pagination = cfg.CONF.allow_pagination
            allow_sorting = cfg.CONF.allow_sorting
            #创建controller
            controller = base.create_resource(
                collection, resource, plugin, params, allow_bulk=allow_bulk,
                parent=parent, allow_pagination=allow_pagination,
                allow_sorting=allow_sorting)
            path_prefix = None
            if parent:
                path_prefix = "/%s/{%s_id}/%s" % (parent['collection_name'],
                                                  parent['member_name'],
                                                  collection)
            mapper_kwargs = dict(controller=controller,
                                 requirements=REQUIREMENTS,
                                 path_prefix=path_prefix,
                                 **col_kwargs)
            # mapper.collection这个就是构建映射规则
            #collection:一个字符串,就是资源的复数形式,比如networks
            #resource:一个字符串,就是资源的单数形式,比如network
            return mapper.collection(collection, resource,
                                     **mapper_kwargs)
	   #构建/的映射规则
        mapper.connect('index', '/', controller=Index(RESOURCES))
        
        for resource in RESOURCES:
        	#针对每一个核心资源(network、subnet等),调用_map_resource,构建映射规则
            _map_resource(RESOURCES[resource], resource,
                          attributes.RESOURCE_ATTRIBUTE_MAP.get(
                              RESOURCES[resource], dict()))
            resource_registry.register_resource_by_name(resource)
		#SUB_RESOURCES是空的,没啥用
        for resource in SUB_RESOURCES:
            _map_resource(SUB_RESOURCES[resource]['collection_name'], resource,
                          attributes.RESOURCE_ATTRIBUTE_MAP.get(
                              SUB_RESOURCES[resource]['collection_name'],
                              dict()),
                          SUB_RESOURCES[resource]['parent'])

        #清除当前配置在策略引擎中的所有规则。其在单元测试中和核心API router初始化的最后调用,确保在所有扩展加载之后加载规则
        policy.reset()
        #初始化wsgi.Router
        super(APIRouter, self).__init__(mapper)
四种组网模型

【星海随笔】SDN neutron (二) Neutron-plugin(ML2)_第5张图片

Type Manager

#neutron/plugins/ml2/managers.py
class TypeManager(stevedore.named.NamedExtensionManager):
    """Manage network segment types using drivers."""
    def __init__(self):
        # Mapping from type name to DriverManager
        self.drivers = {}
        LOG.info(_("Configured type driver names: %s"),
                 cfg.CONF.ml2.type_drivers)
        super(TypeManager, self).__init__('neutron.ml2.type_drivers',
                                          cfg.CONF.ml2.type_drivers,
                                          invoke_on_load=True)
        LOG.info(_("Loaded type driver names: %s"), self.names())
        self._register_types()
        self._check_tenant_network_types(cfg.CONF.ml2.tenant_network_types)

    def create_network_segments(self, context, network, tenant_id):
        """Call type drivers to create network segments."""
        segments = self._process_provider_create(network)
        session = context.session
        with session.begin(subtransactions=True):
            network_id = network['id']
            if segments:
                for segment in segments:
                    segment = self.reserve_provider_segment(
                        session, segment)
                    db.add_network_segment(session, network_id, segment)
            else:
                segment = self.allocate_tenant_segment(session)
                db.add_network_segment(session, network_id, segment)
Type Drivers
  1. Flat模型最为简单,所有的虚拟机共用一个私有IP网段,IP地址在虚拟机启动时完成注入,虚拟机间的通信直接通过HyperVisor中的网桥转发,公网流量在该网段的网关上进行NAT(Nova-network实现为开启nova-network主机内核的iptables,Neutron实现为网络节点上的l3-agent)。Flat DHCP模型与Flat区别在于网桥中开启了DHCP进程,虚拟机通过DHCP消息获得IP地址(Nova-network实现为nova-network主机中的dnsmaq,Neutron实现为网络节点上的dhcp-agent)。

Dnsmasq 的工作原理
Dnsmasq 在接受到用户的一个 DNS 请求时,首先会查找 /etc/hosts 这个文件,如果 /etc/hosts 文件没有请求的记录,然后查找 /etc/resolv.conf 中定义的外部 DNS(也叫上游 DNS 服务器,nameserver 配置),外部 DNS 通过递归查询查找到请求后响应给客户端,然后 dnsmasq 将请求结果缓存下来(缓存到内存)供后续的解析请求。
配置 Dnsmasq 为 DNS 缓存服务器,同时在 /etc/hosts 文件中加入本地内网解析,这样一来每当内网机器查询时就会优先查询 hosts 文件,这就等于将 /etc/hosts 共享给全内网机器使用,从而解决内网机器互相识别的问题。相比逐台机器编辑 hosts 文件或者添加 Bind DNS 记录,仅编辑一个 hosts 文件,这简直太容易了。

  1. VLAN模型引入了多租户机制,虚拟机可以使用不同的私有IP网段,一个租户可以拥有多个IP网段。虚拟机IP通过DHCP消息获取IP地址(Nova-network实现为nova-network主机中的dnsmaq,Neutron实现为网络节点上的dhcp-agent)。网段内部虚拟机间的通信直接通过HyperVisor中的网桥转发,同一租户跨网段通信通过网关路由,不同租户通过网关上的ACL进行隔离,公网流量在该网段的网关上进行NAT(Nova-network实现为开启nova-network主机内核的iptables,Neutron实现为网络节点上的l3-agent)。如果不同租户逻辑上共用一个网关,则无法实现租户间IP地址的复用。
  2. Overlay模型(主要包括GRE和VxlAN隧道技术),相比于VLAN模型有以下改进。1)租户数量从4K增加到16million;2)租户内部通信可以跨越任意IP网络,支持虚拟机任意迁移;3)一般来说每个租户逻辑上都有一个网关实例,IP地址可以在租户间进行复用;4)能够结合SDN技术对流量进行优化。
    【星海随笔】SDN neutron (二) Neutron-plugin(ML2)_第6张图片
    TYPE=0x8100,PRI是优先级字段,CFI不怎么常用,以太网中CFI=0。后面12位的VID就是VLAN的标签位,也就是说802.1q中一个局域网中最多有4096个VLAN,不过不同的交换机对VLAN的规划是不同的,用户实际在一台交换机上能用的VLAN数目要比4096少很多。很简单的一个字段吧,没有什么分域,更不能用来寻址,就只是一个标签,不过这对于传统局域网里的网络虚拟化来说就足够了。

【星海随笔】SDN neutron (二) Neutron-plugin(ML2)_第7张图片

vxlan与vlan区别:
vxlan支持更多的二层网络
vxlan使用12位bit表示vlan ID,因此最多支持2^12=4094个vlan
vxlan使用的ID使用24位bit,最多可以支持2^24个

已有的网络路径利用效率更高
vlan使用spanning tree protocol避免环路,会将一半的网络路径阻塞
vxlan的数据包封装成UDP通过网络层传输,可以使用所有的网络路径

防止物理交换机Mac表耗尽
vlan需要在交换机的Mac表中记录Mac物理地址
vxlan采用隧道机制,Mac物理地址不需记录在交换机

依赖物理的二层来建立虚拟的大二层(vlan模式)

物理的二层指的是:物理网络是二层网络,基于以太网协议的广播方式进行通信
虚拟的二层指的是:neutron实现的虚拟的网络也是二层网络(openstack的vm机所用的网络必须是大二层),也是基于以太网协议的广播方式进行通信,但毫无疑问的是该虚拟网络依赖于物理的二层网络

依赖物理的三层来建立虚拟的大二层(gre模块与vxlan模式)

物理的三层指的是:物理网络是三层网络,基于ip路由的方式进行通信
虚拟的二层指的是:neutron实现的虚拟的网络仍然是二层网络(openstack的vm机所用的网络必须是大二层),仍然是基于以太网协议的广播方式进行通信,但毫无疑问的是该虚拟网络依赖于物理的三层网络,这有点类似于VPN的概念,根本原理就是将私网的包封装起来,最终打上隧道的ip地址传输。

用户(例如demo用户)可以在自己的project下创建网络(L2 network),该网络就是在大二层的基础上划分出来的,是一个隔离的二层网段。类似于物理网络世界中的虚拟 LAN (VLAN),每建立一个l2 network,都会被分配一个段ID,该段ID标识一个广播域,这个ID是被随机分配的,除非使用管理员身份在管理员菜单下,才可以手动指定该ID
子网是一组 IPv4 或 IPv6 地址以及与其有关联的配置。它是一个地址池,OpenStack 可从中向虚拟机 (VM) 分配 IP 地址。每个子网指定为一个无类别域间路由 (Classless Inter-Domain Routing) 范围,必须与一个网络相关联。除了子网之外,租户还可以指定一个网关、一个域名系统 (DNS) 名称服务器列表,以及一组主机路由。这个子网上的 VM 实例随后会自动继承该配置。
每个网络使用自己的 DHCP Agent,每个 DHCP Agent 在一个 Network namespace 内
不同网络内的IP地址可以重复(overlapping)
跨网络的子网之间的流量必须走 L3 Virtual Router

L2 network之Provider与Tenant的区别

Provider network 是由 Admin 用户创建的,而 Tenant network 是由 tenant 普通用户创建的。
Provider network 和物理网络的某段直接映射,比如对应某个 VLAN,因此需要预先在物理网络中做相应的配置。而 tenant network 是虚拟化的网络,Neutron 需要负责其路由等三层功能。
对 Flat 和 VLAN 类型的网络来说,只有 Provider network 才有意义。即使是这种类型的 tenant network,其本质上也是对应于一个实际的物理段。
对 GRE 和 VXLAN 类型的网络来说,只有 tenant network 才有意义,因为它本身不依赖于具体的物理网络,只是需要物理网络提供 IP 和 组播即可。
Provider network 根据 admin 用户输入的物理网络参数创建;而 tenant work 由 tenant 普通用户创建,Neutron 根据其网络配置来选择具体的配置,包括网络类型,物理网络和 segmentation_id。
创建 Provider network 时允许使用不在配置项范围内的 segmentation_id。

Mechanism Manager

ML2 plugin 通过 neutron.plugins.ml2.managers.MechanismManager 与配置了的 mechanism driver 交互。

MechanismManager管理MechanismDriver。
MechanismDriver在创建、更新、删除网络或端口的时候被调用,负责二层网络技术底层的具体实现,和不同的网
络设备进行交互。在每次事件中会调用到MechanismDriver的两个方法

Mechanism Driver

这部分是对各种 L2 技术的支持,例如 Open vSwitch,linux bridge 等等。

会按照配置顺序依次调用每一个Driver的对应函数来完成,比如对需要配置交换机的操作,可能Open vSwitch虚拟交换机和外部真实的物理交换机比如Cisco交换机都需要进行配置,这个时候需要Open vSwitch Mechanism Driver和Cisco Mechanisam Driver都被调用处理。

extension drivers,type drivers 和 mechanism drivers,如果其中任何一个不能接受新创建的 Network,都会导致创建 Network 失败,并且清除在 Network 在 DB 中的记录。

整个流程与创建 Network 类似。差别是少了调用 type drivers,因为 type drivers 针对的是 Network type 的支持,所以没有必要在 Port create 中调用。另一方面,创建 Port 会调用 rpc 通知 L2 agents,这是因为 Port 在 ML2 中还只是一个内存或者 DB 中的对象,真正在 SDN 中起作用的,是在各个 L2 agents 上的虚拟端口。ML2 通过 rpc 通知到 L2 agents,并创建相应的虚拟端口,这样,虚机,虚拟路由器,DHCP 服务等都能基于虚机端口提供网络服务。

Neutron 默认采用的 开源Open vSwitch 创建的虚机交换机

Mechanism Manager分发操作并具体传递操作到Mechanism Driver的方式与Type Manager相同,但是一个需要Mechanism Driver处理的操作是:会按照配置顺序依次调用每一个Driver的对应函数来完成,比如对需要配置交换机的操作,可能Open vSwitch虚拟交换机和外部真实的物理交换机比如Cisco交换机都需要进行配置,这个时候需要Open vSwitch Mechanism Driver和Cisco Mechanisam Driver都被调用处理。

yum install openstack-neutron-openvswitch -y
vi /etc/neutron/plugins/ml2/openvswitch_agent.ini 
[ovs]
tunnel_bridge = br-tun
local_ip = 192.168.100.20   #隧道IP地址 管理网卡IP地址
integration_bridge = br-int
tenant_network_type = vxlan
tunnel_type = vxlan
tunnel_id_ranges = 1:1000
enable_tunneling = true
[agent]
tunnel_types = vxlan
l2_population = true
[securitygroup]
firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
enable_security_group = true
systemctl start neutron-openvswitch-agent.service
systemctl enable neutron-openvswitch-agent.service
ifconfig 
brctl show
ovs-vsctl show 
Neutron-VLAN-OVS

【星海随笔】SDN neutron (二) Neutron-plugin(ML2)_第8张图片

与Linux bridge不同,openvswitch 不是通过eth1.1 eth1.2这样的vlan接口来隔离不同的vlan,而是通过openvswitch的流表规则来指定如何对进出br-int的数据进行转发,实现不同vlan的隔离。

图中计算节点的所有虚拟机都连接在int网桥上,虚拟机分为两个网络。Int网桥会对到来的数据包根据network的不同打上vlan id号,然后转发到eth网桥,eth网桥直连物理网络。这时候流量就从计算节点到了网络节点。
网络节点的ehx int网桥的功能相似,多了一个ex网桥,这个网桥是管理提前创建好的,和物理网卡相连,ex网桥和int网桥之间通过一对patch-port相连,虚拟机的流量到达int网桥后经过路由到ex网桥。

OpenvSwitch的组成

1.ovs的主要组成模块如下:

ovs-vswitchd:OVS守护进程是,OVS的核心部件,实现交换功能,和Linux内核兼容模块一起,实现基于流的交换(flow-based switching)。它和上层 controller 通信遵从 OPENFLOW 协议,它与 ovsdb-server 通信使用 OVSDB 协议,它和内核模块通过netlink通信,它支持多个独立的 datapath(网桥),它通过更改flow table 实现了绑定和VLAN等功能。
ovsdb-server:轻量级的数据库服务,主要保存了整个OVS 的配置信息,包括接口啊,交换内容,VLAN啊等等。ovs-vswitchd 会根据数据库中的配置信息工作。它于 manager 和 ovs-vswitchd 交换信息使用了OVSDB(JSON-RPC)的方式。
ovs-dpctl:一个工具,用来配置交换机内核模块,可以控制转发规则。  
ovs-vsctl:主要是获取或者更改ovs-vswitchd 的配置信息,此工具操作的时候会更新ovsdb-server 中的数据库。  
ovs-appctl:主要是向OVS 守护进程发送命令的,一般用不上。
ovsdbmonitor:GUI 工具来显示ovsdb-server 中数据信息。  
ovs-controller:一个简单的OpenFlow 控制器  
ovs-ofctl:用来控制OVS 作为OpenFlow 交换机工作时候的流表内容。
【星海随笔】SDN neutron (二) Neutron-plugin(ML2)_第9张图片

2.OpenvSwitch的工作流程

通过ovs实现虚拟机和外部通信的过程,通信流程如下:

1.VM实例 instance 产生一个数据包并发送至实例内的虚拟网络接口 VNIC,图中就是 instance 中的 eth0.
2.这个数据包会传送到物理机上的VNIC接口,如图就是vnet接口.
3.数据包从 vnet NIC 出来,到达桥(虚拟交换机) br100 上.
4.数据包经过交换机的处理,从物理节点上的物理接口发出,如图中物理机上的 eth0 .
5.数据包从 eth0 出去的时候,是按照物理节点上的路由以及默认网关操作的,这个时候该数 据包其实已经不受你的控制了.

注:一般 L2 switch 连接 eth0 的这个口是一个 trunk 口, 因为虚拟机对应的 VNET 往往会设置 VLAN TAG, 可以通过对虚拟机对应的 vnet 打 VALN TAG 来控制虚拟机的网络广播域. 如果跑多个虚拟机的话, 多个虚拟机对应的 vnet 可以设置不同的 vlan tag, 那么这些虚拟机的数据包从 eth0(4)出去的时候, 会带上TAG标记. 这样也就必须是 trunk 口才行。

# 添加网桥:
ovs-vsctl add-br br0  
  
# 列出所有网桥:
ovs-vsctl list-br
  
# 判断网桥是否存在:
ovs-vsctl br-exists br0
  
# 将物理网卡挂载到网桥上:
ovs-vsctl add-port br0 eth0
  
# 列出网桥中的所有端口:
ovs-vsctl list-ports br0
  
# 列出所有挂载到网卡的网桥:
ovs-vsctl port-to-br eth0
  
# 查看ovs的网络状态:
ovs-vsctl show
  
# 删除网桥上已经挂载的网口:
ovs-vsctl del-port br0 eth0
  
# 删除网桥:
ovs-vsctl del-br br0
  
# 设置控制器:
ovs-vsctl set-controller br0 tcp:ip:6633
  
# 删除控制器:
ovs-vsctl del-controller br0
  
# 设置支持OpenFlow Version 1.3:
ovs-vsctl set bridge br0 protocols=OpenFlow13  
  
# 删除OpenFlow支持设置:
ovs-vsctl clear bridge br0 protocols 
  
# 设置vlan标签:
ovs-vsctl add-port br0 vlan3 tag=3 -- set interface vlan3 type=internal
  
# 删除vlan标签:
ovs-vsctl del-port br0 vlan3 
  
# 查询 VLAN:
ovs-vsctl show 
ifconfig vlan3 
  
# 查看网桥上所有交换机端口的状态:
ovs-ofctl dump-ports br0
  
# 查看网桥上所有的流规则:
ovs-ofctl dump-flows br0
  
# 查看ovs的版本:
ovs-ofctl -V# 给端口配置tagovs-vsctl set port br-ex tag=101

OpenFlow协议定义了交换机在报文匹配失败时向控制器申请流表的方法,当交换机收到一个不能被当前流表各条流匹配的数据包时,通过将失配报文的相关信息封装在Packet-In消息中发送给控制器,让控制器知晓报文失配情况,由控制器通过Flow-Mod等消息向交换机安装新流表。

extension

在neutron/plugins/ml2/manager.py文件中,除了Type Manager与Mechanism之外还定义有Extension Manger

extension应该放在neutron/extensions文件夹下,或者在配置文件中设置api_extensions_path
extension的class名应该和文件同名,当然首字母应该大写
应该实现neutron.api.extensions.py中ExtensionDescriptor定义的接口
在对应的plugin的supported_extension_aliases 中增加我们extension的别名。

create_network

create_network_in_db
extension_manager.process_create_network
type_manager.create_network_segments
mechanism_manager.create_network_precommit
db commit
mechanism_manager.create_network_postcommit

create_subnet

create_subnet_in_db
extension_manager.process_create_subnet
mechanism_manager.create_subnet_precommit
db commit
mechanism_manager.create_subnet_postcommit

create_port

create_port_in_db
extension_manager.process_create_port
port biding
mechanism_manager.create_port_precommit
db commit
mechanism_manager.create_port_postcommit

你可能感兴趣的:(python,openstack)