Neutron里的服务框架 (by quqi99)

最新推荐文章于 2024-05-30 14:02:00 发布

quqi99

最新推荐文章于 2024-05-30 14:02:00 发布

阅读量3.7k

点赞数

分类专栏： OpenStack Networking

本文链接：https://blog.csdn.net/quqi99/article/details/42743905

版权

OpenStack Networking 专栏收录该内容

79 篇文章 1 订阅

订阅专栏

作者：张华发表于：2014-01-15
版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明

( http://blog.csdn.net/quqi99 )

在Neutron中，在L2层有ML2, 在L4/L7层有LBaaS, FWaaS, VPNaaS, 没有一个从L2/L7层统一的服务框架。
而网络服务在L2/L7层是都有的，例如：
   1, FWaaS应该和网络节点在一块
   2, LBaaS可能就不是一定需要和网络节点在一块，那么安装Haproxy的虚机就必须有两个port (新类型，Service Interface)，一个port能访问子网的网关，一个port能访问要做LB的其他虚机
   3, 像TapaaS，是在port前面拦一下，可以做port mirror或者port monitoring, 这个可是L2层。
   另一方面，这些网络服务之间可能需要是有序的（用例：一个tenant下的两个networks, 一个network里有FWaaS, 一个network里有LBaaS,现在要求他们有序）
   主要基于上述两大原因，出现了一系列的变种BPs.
   1, Service Insertion, 在原有的Neutron Service Type的代码之上扩展serviceBase来实现，本质在于在每个network的边界neutron port处再插入service port, 缺点在于仍然只在L4/L7层，另外也不够灵活，但通用性更好，与neutron更亲和。(https://review.openstack.org/#/c/93128)
   2, Service Chain, 基于Service Insertion，让服务变得有序。
   3, Traffic Steering, 基于ovs流表截取要走“有序服务”的流量，然后通过流表控制流量在各个service的ports上做有序流转。优点更灵活一些，缺点在于仅限于ovs. (https://review.openstack.org/#/c/92477)
   4, 华为也有一个类似的BP, 和Traffic Steering类似，但不需显式指定neutron port, 粒度更粗一些显示和FW这些服务关联，FW肯定也是有neutron port的，实际上实现原理是一样的，缺点也是仅限于ovs (https://review.openstack.org/#/c/146315/)

Service Insertion

例：

neutron create-service-interface <uuid_of_service_to_be_inserted> --insertion-type <neutron-port | external-port | service> <uuid_of_insertion_point>

uuid_of_insertion_point是指port的uuid, 可以network边缘处的neutron port插入服务port, uuid_of_service_to_be_inserted, 如FWaaS.

此替代方案是使用serviceContext （https://review.openstack.org/#/c/62599/）

实现时，在FWaaS, LBaaS, VPNaaS共同的基类ServiceBase里扩展下列方法：
* get_supported_insertion_type()
--- returns the type of interface context (neutron port, external port, or attach to service) supported, should only be one
* create_service_interface(service_interface)
--- create service interface
* delete_service_interface(service_interface_id)
--- delete service interface
* get_service_interfaces()
--- get the list of service interfaces for this service

1, 对VPN DB的影响，目前VPN DB里一个叫router的属性表示一个vpn已经和一个l3 router关联了，需要删除这个属性，用新的type=SERVICE and insertion_point_id=VPN代替。
2, 对FW DB的影响，当时每一个l3 router上都关联了一个FW, 这个可以指定FW只和具体的router关联，为和老的兼容，在DB迁移时为每个router都关联一个FW.
3, 对LB DB的影响，目前LB的VIP表中有一个port属性指明具有VIP，需要删除这个属性，用新的type=NEUTRON_PORT and ap_id=<VIP's port>代替。

Service Chain

数据模型

ServiceChainNode (id, name, type, config, config_params)
ServiceChainSpec (id, name, nodes)
ServiceChainInstance (id, name, service-chain-spec, port)
neutron servicechain-node-create --type flavor_id --config_file fw_heat_template --config_params "destion1=IP1;destination2=IP2" fw_node
neutron servicechain-node-create --type flavor_id --config_file lb_heat_template --config_params "router=router_uuid" lb_node
neutron servicechain-spec-create --nodes "fw_node;lb_node" fwlb_spec

https://review.openstack.org/#/c/93524/13/specs/juno/service-chaining.rst

Traffic Steering

服务框架的本质就是在neutron port之上再创建service port关联相应的service嘛，traffic steering直接通过流表根据classfier截取哪些流量要用service chain功能，然后再在各个neutron port之类导流就行了。

port chain (id, name, descrip, tenant_id, ports, classfiers, override_warning)
classifier (id, name, descrip, tenant_id, protocol, scr_port_min, src_port_max, dst_port_min, dst_port_max, src_ip, dst_ip)

Huawei Service Chain

和上面的三类做同样的事情
数据结构：
ServiceFunctionPool (id, name, type[FW|LB])
ServiceFunctionPoolInstance (id, pool_id, name, sf_id) (用来提供vm port的）
MatchRule (id, name, protocol, src-port, dst-port)
ServiceFunctionChain (id, name, chain[FW|LB], rule_id)
用法流程：
即从目标端口为100及源端口为50的流量应用"FW,LB"的service-chain, FW会关联neutron port, LB会关联neutron port (它没有像上面三种方法显示的关联port，但LB等肯定会有neutron port，所以是隐式的）, 于是流量在这些port上有序的流动。
neutron sf-pool-create --type FW
neutron sf-pool-create --type LB
neutron sf-pool-inst-associate --pool_Id fw_sfpool_uuid --sf_Id fw1_uuid
neutron sf-pool-inst-associate --pool_Id fw_sfpool_uuid --sf_Id fw2_uuid
neutron sf-pool-inst-associate --pool_Id lb_sfpool_uuid --sf_Id lb1_uuid
neutron sf-pool-inst-associate --pool_Id lb_sfpool_uuid --sf_Id lb2_uuid
neutron sf-chain-create --chain "FW,LB"
neutron sf-matchrule-create --protocol tcp --dst-port 100
neutron sf-matchrule-create --protocol udp --src-port 50
neutron sf-chain-update --sf_chain_Id sf_chain_uuid --rule_Id rule_uuid1 --rule_Id rule_uuid2

也有midonet之类，定义service, 然后为port指定有序的service列表，由pipline来按service列表的顺序来根据流表过滤。

社区批准的sfc

http://docs.openstack.org/developer/networking-sfc/
+-------+ +----------+ +------------+
| Port |--------| Port Pair|--------| Port Pairs |
| Chain |* *| Groups | 1 *| |
+-------+ +----------+ +------------+
|1
|
|*
+--------------+
| Flow |
| Classifiers |
+--------------+

+------+ +------+ +------+
| SF1 | | SF2 | | SF3 |
+------+ +------+ +------+
p1| |p2 p3| |p4 p5| |P6
| | | | | |
----+ +---------+ +----------+-|---->

例如：两个service VMs (vm1与vm2), 从源地址22.1.20.1到目的地址172.4.5.6/32的流要经过VM1[p1, p2]，和VM2[p3, p4].
nova boot --image xxx --nic port-id=p1 --nic port-id=p2 vm1
nova boot --image yyy --nic port-id=p3 --nic port-id=p4 vm2

neutron flow-classifier-create --ip-version ipv4 --source-ip-prefix 22.1.20.1/32
--destination-ip-prefix 172.4.5.6/32 --protocol tcp --source-port 23:23
--destination-port 100:100 FC1

neutron port-pair-create --ingress=p1 --egress=p2 PP1
neutron port-pair-create --ingress=p3 --egress=p4 PP2
neutron port-pair-create --ingress=p5 --egress=p6 PP3

neutron port-pair-group-create --port-pair PP1 --port-pair PP2 PG1 # 虚机有多网卡
neutron port-pair-group-create --port-pair PP3 PG2

neutron port-chain-create --port-pair-group PG1 --port-pair-group PG2 --flow-classifier FC1 PC1

实现：

Traffic from SF Egress port: classify for chain and direct to group:
priority=10,in_port=SF_EGRESS_port,traffic_match_field,
actions=strip_vlan,set_tunnel:VNI,group:gid.

Traffic from Tunnel port:
priority=10,in_port=TUNNEL_port,
actions=resubmit(,TUN_TABLE[type]).

Group Table Flows。注： Group 类型：group 类型有四种‘ all ’、“select”、“indirect”、“fast failover”。将一些 flow 指向 group table 是为了处理报文转发中的一些高级功能，譬如‘ all ’是为了处理多播或者广播。
group_id=gid,type=select,selection_method=hash,fields=ip_src,nw_proto,tp_src
bucket=set_field:10.1.1.3->ip_dst,output:10,
bucket=set_field:10.1.1.4->ip_dst,output:10

openflow group table flows的流程如下图，其中action bucket指一组有序的action.

服务链如何与外部系统交互：

Ironic通过LLDP协议向Neutron报告ToR Switch的二层网络拓扑，这样Neutron可以统一给裸机分配port。见： https://review.openstack.org/#/c/188528/7/specs/liberty/ironic-ml2-integration.rst

External Attachment Point用于neutron和外部系统（如ironic，如L2 gateway)系统连接：
http://specs.openstack.org/openstack/neutron-specs/specs/juno/neutron-external-attachment-points.html
neutron port-create --external-attachment-point-id <external_attachment_point_id>
neutron external-attachment-point-create --attachment_type 'vlan_switch' --attachment_id switch_id=00:12:34:43:21:00,port=5,vlan_tag=none

参考
[1] https://docs.google.com/a/canonical.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit
[2] https://review.openstack.org/#/c/93524/13/specs/juno/service-chaining.rst
[3] https://review.openstack.org/#/c/93128/22/specs/juno/service-base-and-insertion.rst

[4] https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining