Jump to: navigation, search

Difference between revisions of "Neutron/LBaaS/Glossary"

< Neutron‎ | LBaaS
(Member)
(Proposed a fix for the definition of VIP)
 
(8 intermediate revisions by one other user not shown)
Line 9: Line 9:
 
<br/>
 
<br/>
 
Usually the workflow of creating operational configuration begins with creating the root object.
 
Usually the workflow of creating operational configuration begins with creating the root object.
==== Vip ====
+
 
 +
==== Vip (Old) ====
 
Object that represents an endpoint of load balancing device that has IP address.<br/>
 
Object that represents an endpoint of load balancing device that has IP address.<br/>
 
In existing model it also has tcp port, protocol, session persistence setting.
 
In existing model it also has tcp port, protocol, session persistence setting.
 
Vip is plugged into a subnet, so as an object, it has subnet attribute.<br/>
 
Vip is plugged into a subnet, so as an object, it has subnet attribute.<br/>
 +
 +
==== Vip (New) ====
 +
A Virtual IP address, as per: http://en.wikipedia.org/wiki/Virtual_IP_address
 +
 
==== Insertion mode ====
 
==== Insertion mode ====
 
Insertion mode represents a connectivity scheme between external network and the backend servers.
 
Insertion mode represents a connectivity scheme between external network and the backend servers.
 
There are several common ways of inserting a balancer into a newtork, most of them described here: https://wiki.openstack.org/wiki/Quantum/ServiceInsertion and https://wiki.openstack.org/wiki/QuantumServicesInsertion <br/>
 
There are several common ways of inserting a balancer into a newtork, most of them described here: https://wiki.openstack.org/wiki/Quantum/ServiceInsertion and https://wiki.openstack.org/wiki/QuantumServicesInsertion <br/>
 
Right now existing implementations (vendor drivers) seem to use L2 adjacent insertion, where Vip is plugged in the same subnet where pool members are.
 
Right now existing implementations (vendor drivers) seem to use L2 adjacent insertion, where Vip is plugged in the same subnet where pool members are.
 +
 
==== Pool ====
 
==== Pool ====
 
Object that represents a group of nodes. Pool defines subnet where nodes reside, balancing algorithm, nodes itself (indirectly)<br/>
 
Object that represents a group of nodes. Pool defines subnet where nodes reside, balancing algorithm, nodes itself (indirectly)<br/>
 
In existing LBaaS model Pool is the root object.
 
In existing LBaaS model Pool is the root object.
 +
 
==== Listener ====
 
==== Listener ====
 +
An object used to represent a listening endpoint of the Vip, where Vip itself only responsible for holding IP address.<br/>
 +
This object relates to the following proposal: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#VIP-centric_solution <br/>
 +
Most of the attributes related to balancing mode (session persistence) and the protocol are stored in Listener, instead of Vip. Also, Listener is a child object of the Vip.
 +
 
==== Member ====
 
==== Member ====
 
Represent single backend node: it's ip address, tcp port, weight (for appropriate balancing algorithm), status defined by health monitoring.
 
Represent single backend node: it's ip address, tcp port, weight (for appropriate balancing algorithm), status defined by health monitoring.
  
 
==== Health Monitor ====
 
==== Health Monitor ====
 +
An object that defines a check method for each member of the pool.<br/>
 +
Health monitor itself is a pure-db object which needs to be associated with a pool to start reporting health status of the nodes.
 +
 
==== Loadbalancer ====
 
==== Loadbalancer ====
 +
An object that represent a logical load balancer that may have multiple resources such as Vips, Pools, Members, etc.<br/>
 +
Loadbalancer is a root object in the meaning described above. <br/>
 +
It's a first entry to be created in the workflow, to receive provider/flavor properties and an object to turn on and off whole loadbalancer configuration.
 +
Corresponding object model is presented here: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#Loadbalancer_instance_solution
 +
 +
==== Backend ====
 +
Any device/appliance/process that actually does load balancing.<br/>
 +
 +
==== Implementation Detail ====
 +
Something (entity or attribute) that user/tenant should not have control over.<br/>
 +
In public cloud it is everything related to a particular backend implementation or any vendor-specific aspect.<br/>
 +
However, implementation details might be exposed to cloud admin for troubleshooting purposes.
 +
 +
==== Agent ====
 +
Application responsible for managing processes or appliances.<br/>
 +
Neutron-server communicates with agent with RPC in async manner.<br/>
 +
Main goal of agent is to be able to configure 'process-on-host'-like solutions (like haproxy in lbaas) and also to provide asynchronous behavior of API operations
 +
 +
==== Appliance ====
 +
Hardware or virtual machine which is capable of implementing a service (load balancing, for instance)
 +
 +
==== Virtualized Appliance ====
 +
Logical concept of one unit of hardware/software appliance
 +
 +
==== Device ====
 +
Synonym to Appliance, but with more 'hardware' semantics

Latest revision as of 15:24, 10 April 2014

Root object

An object that represents a logical configuration.
It has certain features that are applied to it and spread to all it's depending objects such as:

* vendor or provider or flavor
* admin state (Up or Down)

On implementation side there are some more attributes of that object

* insertion mode and insertion-specific parameters
* backend binding information


Usually the workflow of creating operational configuration begins with creating the root object.

Vip (Old)

Object that represents an endpoint of load balancing device that has IP address.
In existing model it also has tcp port, protocol, session persistence setting. Vip is plugged into a subnet, so as an object, it has subnet attribute.

Vip (New)

A Virtual IP address, as per: http://en.wikipedia.org/wiki/Virtual_IP_address

Insertion mode

Insertion mode represents a connectivity scheme between external network and the backend servers. There are several common ways of inserting a balancer into a newtork, most of them described here: https://wiki.openstack.org/wiki/Quantum/ServiceInsertion and https://wiki.openstack.org/wiki/QuantumServicesInsertion
Right now existing implementations (vendor drivers) seem to use L2 adjacent insertion, where Vip is plugged in the same subnet where pool members are.

Pool

Object that represents a group of nodes. Pool defines subnet where nodes reside, balancing algorithm, nodes itself (indirectly)
In existing LBaaS model Pool is the root object.

Listener

An object used to represent a listening endpoint of the Vip, where Vip itself only responsible for holding IP address.
This object relates to the following proposal: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#VIP-centric_solution
Most of the attributes related to balancing mode (session persistence) and the protocol are stored in Listener, instead of Vip. Also, Listener is a child object of the Vip.

Member

Represent single backend node: it's ip address, tcp port, weight (for appropriate balancing algorithm), status defined by health monitoring.

Health Monitor

An object that defines a check method for each member of the pool.
Health monitor itself is a pure-db object which needs to be associated with a pool to start reporting health status of the nodes.

Loadbalancer

An object that represent a logical load balancer that may have multiple resources such as Vips, Pools, Members, etc.
Loadbalancer is a root object in the meaning described above.
It's a first entry to be created in the workflow, to receive provider/flavor properties and an object to turn on and off whole loadbalancer configuration. Corresponding object model is presented here: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#Loadbalancer_instance_solution

Backend

Any device/appliance/process that actually does load balancing.

Implementation Detail

Something (entity or attribute) that user/tenant should not have control over.
In public cloud it is everything related to a particular backend implementation or any vendor-specific aspect.
However, implementation details might be exposed to cloud admin for troubleshooting purposes.

Agent

Application responsible for managing processes or appliances.
Neutron-server communicates with agent with RPC in async manner.
Main goal of agent is to be able to configure 'process-on-host'-like solutions (like haproxy in lbaas) and also to provide asynchronous behavior of API operations

Appliance

Hardware or virtual machine which is capable of implementing a service (load balancing, for instance)

Virtualized Appliance

Logical concept of one unit of hardware/software appliance

Device

Synonym to Appliance, but with more 'hardware' semantics