Le 14 avr. 2011 à 21:58, Roman Bogorodskiy a écrit :
> Tomaz Muraus wrote:
>
>> I am not totally sure, but for example, maybe we should also allow users to
>> pass in a Node object instead of the IP address to the balancer_attach_node
>> and other functions and the function would read private / public IP address
>> from the Node object.
>
> How do we understand if we should peak public or private address from
> the Node object?
Yes, node can have multiples IP address (private / public, ipv4 / ipv6) and we
must explicitly define which IP of a node to be used in the load balancer
definition. Check of the node status, or IP correctly attached, should be part
of driver logic, depending on the provider.
libcloud.networking.lb sound a more natural namespace, within my experiences.
I also have some questions / remarks around reuse of others libcloud objects or
concepts in this LB component.
* use of location object to create a load balancer
- Amazon elastic LB use availability zone like nodes at creation time.
* a concept, near the list_sizes Node component one, to choose a provider
dependent way to abstract the whole LB rule to configure:
- protocol (tcp / udp / http / ftp / ....) (level 4 or level 7 ones can
cohabit
- persistence mode (sticky and which type : vip, http_cookie, ...)
- type of load balancing (round-robin, vip-src, etc)
- type of healthcheck to use (tcp / ping / http get / ...)
- others attributes provider specific or not
- network topology (NAT/DSR/half-nat)
- healtchecks properties (interval, timeout, ...)
- price (???)
To create a LB, we must pick a location and a "rule" in the catalog (IP/port
still needed), driver will assemble all components involved (for example
listener / healtcheck in amazon vocabulary).
More capabilities of each providers should be accessible using such
configuration catalog, I hope.
my 2 cents, and this time my mail should be complete :)
Aymeric
--
Senior Database Architect -- www.gandi.net
