Service Insertion

Service Insertion是Neutron中实现L4/L7层服务的框架。Neutron以前只有一级插件结构用于实现各种L2层技术(如LinuxBridge,OVS等，部署时分两块：用于和数据库打交道的NeutronPlugin+用于干实际事情的L2Agent），对于L3层的路由和dhcp是采用单独的agent(l3-agent,dhcp-agent)来实现的。但L4-L7层服务要求:

（1）像FW,VPN,DNAT服务需要运行在l3-agent所在的网络节点上，即所谓的Routed/Embedded模式，可参见：https://wiki.openstack.org/wiki/Quantum/ServiceInsertion

(2)像LBaaS服务不需要运行在网络节点上，但网络节点上专门为它准备的port和实际运行haproxy的节点应该通，这个port和网关也应该通，即所谓的Floating/In-Path模式。

(3) 还有一种叫Out-of-Path模式，可能在实现sFlow之类的监控时有用：Where the service also runs in a standalone way but in this case the traffic is first sent to the Router entity and then redirected to the Advanced Service, finally send it back to the routed with specific configuration. In particular, this model could be reduced to the first assuming that a standalone service is regarded as a peculiar case of router capable of providing only a specific service. This mode needs specific changes at the routing entity and may not be implemented in Grizzly release.

于是，Neutron又实现了一层叫做“服务”的插件结构，即现在有两层插件结构，在NeutronPlugin上又可以启动多个服务，eutronPlugin的服务插件继续和数据库打交道同时也能共享原有的NeutronPlugin的信息，如port信息；同时，像FWaaS服务要求ServiceAgent可以运行在l3-agent所在的网络节点上，而LBaaS的haproxy并不需要也安装在l3-agent，但l3-agent也应该在一个专门的命名空间里创建一个port和haproxy所在host是联通的。

Service Type Concept

Just like the Quantum plugins allow for using several technologies for implementing the basic logical topologies, advanced services will use a similar mechanism. However, for advanced services, multiple different implementations of the same kind of service might co-exist in the same deployment. There are a number of reasons for this, most importantly the ability of giving tenants a choice among solutions. The Service Type concept tries to address the need for multiple, co-existing, service providers.

A Service Type definitions might be regarded as list of services (and their providers) which can be offered to tenants. Each advanced service, regardless of its insertion mode, should be either directly or indirectly associated with a single service type.

The association between a service and a service type can happen in two ways, according to the insertion mode of the service.

• Routed Insertion mode: The advanced service will be associated with Quantum logical router, which in turn is associated with a service_type resource;

In order to ensure backward compatibility a default service type must be specified. This implies that all the services which will be inserted on a router will share the same service type.

• Floating Insertion mode: The service type should be explicitly specified on the advanced service being created; if not, the default service type will be used.

When an advanced service is created at the API layer one of the following two should be specified:

1. service_type_id # floating or out-of-path insertion
2. router_id # routed or in-path insertion

It should not be allowed to specify both parameters.

The logical model for service insertion, augmented with the service type concept, is depicted in the following diagram:

下面以LBaaS为例(https://wiki.openstack.org/wiki/Quantum/LBaaS)，说明代码中是如何实现ServiceInsertion框架的。

1, 在NeutronPlugin的配置文件/etc/neutron/neutron.conf中配置核心插件和服务插件：

service_plugins =neutron.services.loadbalancer.plugin.LoadBalancerPlugin

core_plugin =neutron.plugins.openvswitch.ovs_neutron_plugin.OVSNeutronPluginV2

2,在$neutron/neutron/manager.py的init方法中加载service插件：

self.service_plugins ={constants.CORE:self.plugin}

self._load_service_plugins()

3,Agent到Driver的映射即是所说的第二层插件结构，例如haproxydriver只是LbaaSAgent实现的一种：

$neutron/neutron/services/loadbalancer/driver/haproxy/agent.py会调用

$neutron/neutron/services/loadbalancer/driver/haproxy/agent_manager.py来加载haproxy对应的driver，从lbaas的代码架构可以看出：

Service Chain

上节说了通过定义service这第二层的插件结构来实现L4/L7层服务，但一个tenant可能同时需要多个L4/L7层服务，如LB，如FW，并且是有序的。ServiceChain就是来做这件事。

　一个tenant可以请求创建多个有序的Service。ServiceTypes定义了service被插入到tenant网络中的行为：

• L3, 这类服务有ip具有路由流量,它运行在router上，或者不运行在router上但具有l3-forwarding的功能，如LBaaS

• L2,这类服务具有交换流量，有能力做l2-switching和mac地址学习，如L2-Firewallservice（如用ovs的流表来代替iptables）。

• Bump-in-the-wire,嵌入式服务，这类服务既无路由流量也无交换流量，只有出口和入口port，服务在入口port之前就运行了，如Firewallperforming filtering and auditing。

• Tap, 这类服务在servicechain中仅在特定的点消费流量，如monitoringservice

每个service有一个或两个ports。这样操纵一个service实例：

• 服务由硬件设备来提供（如LB或Firewall硬件设备），neutron也需要提供一个port去请求这些设备来服务。

• 服务由VM来提供，neutron也需要提供一个port去请求这个可能是独立也可能是共享的VM。

• tenant已经有一个现成的服务实现了，可能需要组合上述两步去请求它。

Neutron LbaaS的应用场景及实现要点

　　NeutronLbaaS实现了下列应用场景：

• VIP可以设置在router上

• VIP也可以不设置在router上

所以在下图的实现中，要特别注意防火墙规则保证sgdefault名空间能访问sgweb名空间，即应该让VIP用的port和网关port关联，也和提供LB的虚机所用的TAP关联起来。

防火墙的流程，我分析应该如下：

１）组成LB服务的虚机所在的计算节点上应为虚机nova-compute-haproxy-instance生成它自己的nova-compute-local防火墙规则：

-A nova-compute-local -d 10.0.0.8/32 -jnova-compute-haproxy-instance

-A nova-compute-haproxy-instance -s 10.0.0.0/24-j ACCEPT

-A nova-compute-haproxy-instance -s 10.0.0.1/32-p udp -m udp --sport 67 --dport 68 -j ACCEPT

-A nova-compute-haproxy-instance -jnova-compute-sg-fallback

-A nova-compute-sg-fallback -j DROP

　同时，它也应该有一条默认路由让vip的port（位于sgweb名空间）能访问它所在的网关

route add default gw 10.0.0.1

2）L3-agent的下列防火墙规则能保证l3-agent上的vip可以访问LB池中的其他虚机。

-A nova-network-POSTROUTING -s 10.0.0.0/8 -d10.0.0.0/8 -m conntrack ! --ctstate DNAT -j ACCEPT

参考：

http://blog.csdn.net/quqi99/article/details/9898139

https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining

https://wiki.openstack.org/wiki/Neutron/ServiceInsertion

本文转自http://blog.csdn.net/quqi99/article/details/9898139，有删改。