Neutron LBaaS Service（2）—— Neutron Services Insertion Model

標籤：style   blog   http   color   os   strong   

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，有刪改。