跳转到: 导航, 搜索

Neutron/LBaaS/Agent

< Neutron‎ | LBaaS

负载均衡服务的 Quantum Agent

文档范围

本文档描述了中子负载均衡服务的 Agent 组件,定义了需求、架构和一些实现细节。

需求

服务 Agent 需要为服务添加几个重要的特性,这些特性操作可能耗时较长,例如:

  1. 异步执行。
 Plugin is notified by agent when requested operation is complete. 
  1. 工作负载均衡。
 There could be serveral agents listening for quantum server messages thus in large deployments it allows splitting workload to several hosts.

架构

  1. 插件部分
 1.1. Calling agent
   Plugin packs all required information in the json message and sends it over AMQP to durable message queue.
   The message is consumed by one of the running agents and corresponding call is made via one of the drivers in synchronous manner.
   After driver call completes agent sends message to the plugin with status information for modified object.
 1.2. Receiving response
   Plugin should wait on another queue where responses are posted by the agent. 
   Information in response should allow plugin to uniquely identify object for which status of operation is returned.
   Plugin consumes response messages in synchronous manner one by one since their processing is not a time consuming operation.
  1. Agent 部分
  Agent should be able to consume messages in multithreaded manner. E.g. agent should allow execution of several operations at once.
  One technical difficulty of this is device sharing. Consider the case when several operations go for the same device. 
  Such operations should be executed sequentially rather than concurrently.
  1. 身份验证。
  Agent doesn't perform authentication of received requests, nor the requests contain any authentication information.
  It's presumed that authentication was done on the plugin part so caller has access to the device it is configuring.

简要组件/工作流图

Plugin-Agent Architecture.png

实现

  1. Agent 部分
 One of the most important issues of plugin-agent-driver architecture is device sharing/locking.
 Since Agent can process requests from plugin concurrently, it's important to preserve atomicity of access to the same device so different calls for the same device would not break its configuration.
 Consider the following use case:
 Tenant creates a vip object and then creates members.
 Depending on how those actions are packed as requests to agent it could result that agent may start executing member creation requests before pool creation is finished.
 The solution for this problem is that agent should internally queue the requests for the device. E.g. requests dedicated to the same device are processed sequentially. 
 Also, Agent is responsible for detecting timed out operations and sending a message with appropriate reason to plugin's response consumer.
  1. 插件部分
 Plugin is also responsible for assuring atomic device access.
 There could be two approaches to this:
  1. 插件部分在数据库中锁定对象,对并发的相同资源调用返回一些 HTTP 错误,从而将处理责任交给客户端。
  2. 插件部分像往常一样排队请求,并让 Agent 为特定设备排队请求,以便顺序执行它们。
 The second approach may preferable from client perspective.

如何在 DevStack 上运行代码

详细的说明在这里:Quantum/LBaaS/HowToRun