load balancers with FGCP

["Koper, Dies" <di...@fast.au.fujitsu.com>]

I've been looking at how to map the load balancer API to FGCP's load
balancer concept better.

Let me first briefly explain the load balancer concept in the FGCP.
In the FGCP a load balancer module is provided as a 'built-in server'.
I.e. you create one in a similar way as a server instance, need to start
it before you can configure it, it is assigned its own private IP
address and you can map one (or more) public IP addresses to it.
Once running, you can create groups, each having a source port and
protocol (and a few more settings, such as distribution method
(round-robin or least number of connections), service monitoring method
(ping or tcp), consistency guarantee method (source IP, connection,
cookie/url or cookie client id insertion), etc.).
To each group you can add listeners, which consist of a destination
server instance and server instance port each.

So the main differences to the DC API are:

1. load balancer needs to be created first, then started, then
configured. Can't create & configure in a single step.
2. FGCP load balancer can have multiple groups, each with its own listen
port and protocol, instead of just one.
3. The instance destination port is specified per instance, not per load
balancer.

This is how I think we can address them:

1. As load balancers are a type of server instances in the FGCP, they
are returned in the list of instances and can be started, stopped and
removed from there. For the create & configure operation, the best I can
do is create if not already created, and configure if created and
running.

2. Instead of mapping a DC load balancer to an FGCP load balancer, I
think I can map a DC load balancer to an FGCP load balancer group. That
solves the single versus multiple listen ports and protocols issue.

3. For this one I'd like to request a change/addition to the DC API:
a. the operation to register an instance has an optional 'instance port'
parameter. If supported by the provider and specified, it overrides the
value of the load balancer's 'instance port' field. If not specified,
the value of already configured instances is used (and if there aren't
any, the same value as the load balancer port).
b. the current listener_instance_port field becomes optional for
providers that don't support it.

Wdyt?

In additional to the above, I'd have an rfe for the UI:
The register instance page in the UI lists all instances. I'd like to
change that page to:
1. only list the instances in the same realm(s) as the load balancer.
2. add a way for the user to enter the instance port number.

Thanks,
Dies Koper

RE: load balancers with FGCP

[David Lutterkort <lu...@redhat.com>]

On Sat, 2012-08-18 at 18:04 +1000, Koper, Dies wrote:
> > > 1. As load balancers are a type of server instances in the FGCP,
> they
> > > are returned in the list of instances and can be started, stopped
> and
> > > removed from there.
> > 
> > Is it desirable to expose the load balancer in this way ? Could we
> > suppress load balancer instances in the instances list ?
> 
> That is a good question, which does not apply only to load balancers.
> I should have brought this up with the initial fgcp driver
> implementation but there were so many bigger issues at the time :)
> 
> Technically we can definitely supress them. But load balancers need to
> be started before they can be configured, so if we supress them in the
> instance list we need start and stop operations elsewhere.

Can we handle the start/stop transparently ? IOW, API users do not need
to know that LB's need to be started explicitly, we start them for them
when they are needed, and stop them when they are not balancing anything
anymore.

> I'd like to do the same for the load balancer: the load balancer is
> created using DC's equivalent operation, the user would then go to the
> instances list to find it and start it.

My problem with this is that LB's can only be used then if the user
knows to start some special instance - with that, the FGPC driver will
behave differently from other drivers.

> > >  For the create & configure operation, the best I can
> > > do is create if not already created, and configure if created and
> > > running.
> > 
> > Yes, I agree. As long as the operation is idempotent (i.e., if you
> make
> > a call to DC to create a LB, and some of the intermediate steps of
> > creating/configuring fail, we kick back an error to the client; when
> the
> > client repeats its request, we pick up the LB creation if it still
> needs
> > to be done)
> 
> I will look into that. What HTTP error code would fit that situation?
> 269 Call Back Later?

Heh .. for example; I would use 502 Bad Gateway or 504 Gateway Timeout,
unless the failure from FGCP gives us an indication that something else
went wrong that would explain things better to the user (e.g., if FGCP
gives us ome other 5xx code)

> > it. This is so that we do not have to store data when the LB is set
> up,
> > and use that when an instance is registered to the LB, right ? Is
> there
> 
> Right. I don't want to store that data on DC's side and on FGCP's LB (or
> LB group) there are no attributes I can use of abuse (not even a
> 'description' field) to store a port number.

Is there _anything_ we could abuse for storage ?

> > some way to avoid that, since it constitutes API breakage ?
> 
> The API breakage being to make the current listener_instance_port
> attribute a feature?
> I'm not sure how that could cause any impact, systems that have used it
> so far would continue to work, wouldn't they?

Only if they don't rely on DC being cross-cloud and try to set a
listener_instance_port on FGCP.

> 1. DC LB API will include a new feature to add a port number to the
> operation to add an instance to a LB listener.
> 2. DC LB UI will offer the user a field to enter that port number when
> adding an instance to a LB.
> 3. FGCP will implement and advertise the above feature and all other
> functionality described in this e-mail.

I believe so ;)

David

RE: load balancers with FGCP

["Koper, Dies" <di...@fast.au.fujitsu.com>]

> > 1. As load balancers are a type of server instances in the FGCP,
they
> > are returned in the list of instances and can be started, stopped
and
> > removed from there.
> 
> Is it desirable to expose the load balancer in this way ? Could we
> suppress load balancer instances in the instances list ?

That is a good question, which does not apply only to load balancers.
I should have brought this up with the initial fgcp driver
implementation but there were so many bigger issues at the time :)

Technically we can definitely supress them. But load balancers need to
be started before they can be configured, so if we supress them in the
instance list we need start and stop operations elsewhere.

The FGCP api to list instances returns two types of instances. "normal"
instances and "built-in" instances. Currently two types of "built-in"
instances are supported, firewalls and load balancers. I decided at the
time to include all in the instances list.
Most operations and attributes on the built-in instances are the same as
normal instances: they can be started, stopped and destroyed, they have
an id, name and private IP address. 
The creation operation is different in the fgcp api: the load balancer
creation option only takes a name and realm, it is not created from an
image. The fgcp api has no operation to create a firewall, rather
creates one automatically when creating a system. It takes a name and
system template descriptor id (which defines whether the system gets a
1, 2 or 3 tier network).

So what I've done is to map DC's firewall creation operation to FGCP's
system creation method. The user would then go to the instances list to
find the firewall instance and start it. Operations such as allocating
and mapping public IP addresses depend on the FW to be running. In fact,
you can't even start a "normal" instance in a system realm unless the FW
is running, so having them in the same list is convenient.

I'd like to do the same for the load balancer: the load balancer is
created using DC's equivalent operation, the user would then go to the
instances list to find it and start it.

> >  For the create & configure operation, the best I can
> > do is create if not already created, and configure if created and
> > running.
> 
> Yes, I agree. As long as the operation is idempotent (i.e., if you
make
> a call to DC to create a LB, and some of the intermediate steps of
> creating/configuring fail, we kick back an error to the client; when
the
> client repeats its request, we pick up the LB creation if it still
needs
> to be done)

I will look into that. What HTTP error code would fit that situation?
269 Call Back Later?

> > 2. Instead of mapping a DC load balancer to an FGCP load balancer, I
> > think I can map a DC load balancer to an FGCP load balancer group.
That
> > solves the single versus multiple listen ports and protocols issue.
> 
> What will we do with additional groups that people might have created
> outside of DC ? Will they just get mapped to different DC LB's ?

Yes, I should be able to map all groups to DC LBs.

> > 3. For this one I'd like to request a change/addition to the DC API:
> > a. the operation to register an instance has an optional 'instance
port'
> > parameter. If supported by the provider and specified, it overrides
the
> > value of the load balancer's 'instance port' field. If not
specified,
> > the value of already configured instances is used (and if there
aren't
> > any, the same value as the load balancer port).
> 
> Makes sense to me - this should be advertised as a feature.
> 
> > b. the current listener_instance_port field becomes optional for
> > providers that don't support it.
> 
> It sounds more to me that what you want is that the
> listener_instance_port is not supported for providers that don't
support

Yes, ideally I'd see both the existing listener_instance_port and the
one I'm requesting to be advertised features as fgcp only supports the
one and ec2 only the other.

> it. This is so that we do not have to store data when the LB is set
up,
> and use that when an instance is registered to the LB, right ? Is
there

Right. I don't want to store that data on DC's side and on FGCP's LB (or
LB group) there are no attributes I can use of abuse (not even a
'description' field) to store a port number.

> some way to avoid that, since it constitutes API breakage ?

The API breakage being to make the current listener_instance_port
attribute a feature?
I'm not sure how that could cause any impact, systems that have used it
so far would continue to work, wouldn't they?

> > In additional to the above, I'd have an rfe for the UI:
> > The register instance page in the UI lists all instances. I'd like
to
> > change that page to:
> > 1. only list the instances in the same realm(s) as the load
balancer.
> > 2. add a way for the user to enter the instance port number.
> 
> Both sensible, (2) of course would only show up if the appropriate
> feature is supported by the backend.

Thanks!

So to summarise the current status of the change request:

1. DC LB API will include a new feature to add a port number to the
operation to add an instance to a LB listener.
2. DC LB UI will offer the user a field to enter that port number when
adding an instance to a LB.
3. FGCP will implement and advertise the above feature and all other
functionality described in this e-mail.

Regards,
Dies

Re: load balancers with FGCP

[David Lutterkort <lu...@redhat.com>]

Hi Dies,

On Wed, 2012-08-15 at 18:57 +1000, Koper, Dies wrote:
> I've been looking at how to map the load balancer API to FGCP's load
> balancer concept better.
> 
> Let me first briefly explain the load balancer concept in the FGCP.
> In the FGCP a load balancer module is provided as a 'built-in server'.
> I.e. you create one in a similar way as a server instance, need to start
> it before you can configure it, it is assigned its own private IP
> address and you can map one (or more) public IP addresses to it.
> Once running, you can create groups, each having a source port and
> protocol (and a few more settings, such as distribution method
> (round-robin or least number of connections), service monitoring method
> (ping or tcp), consistency guarantee method (source IP, connection,
> cookie/url or cookie client id insertion), etc.).
> To each group you can add listeners, which consist of a destination
> server instance and server instance port each.
> 
> So the main differences to the DC API are:
> 
> 1. load balancer needs to be created first, then started, then
> configured. Can't create & configure in a single step.
> 2. FGCP load balancer can have multiple groups, each with its own listen
> port and protocol, instead of just one.
> 3. The instance destination port is specified per instance, not per load
> balancer.
> 
> This is how I think we can address them:
> 
> 1. As load balancers are a type of server instances in the FGCP, they
> are returned in the list of instances and can be started, stopped and
> removed from there.

Is it desirable to expose the load balancer in this way ? Could we
suppress load balancer instances in the instances list ?

>  For the create & configure operation, the best I can
> do is create if not already created, and configure if created and
> running.

Yes, I agree. As long as the operation is idempotent (i.e., if you make
a call to DC to create a LB, and some of the intermediate steps of
creating/configuring fail, we kick back an error to the client; when the
client repeats its request, we pick up the LB creation if it still needs
to be done)

> 2. Instead of mapping a DC load balancer to an FGCP load balancer, I
> think I can map a DC load balancer to an FGCP load balancer group. That
> solves the single versus multiple listen ports and protocols issue.

What will we do with additional groups that people might have created
outside of DC ? Will they just get mapped to different DC LB's ?

> 3. For this one I'd like to request a change/addition to the DC API:
> a. the operation to register an instance has an optional 'instance port'
> parameter. If supported by the provider and specified, it overrides the
> value of the load balancer's 'instance port' field. If not specified,
> the value of already configured instances is used (and if there aren't
> any, the same value as the load balancer port).

Makes sense to me - this should be advertised as a feature.

> b. the current listener_instance_port field becomes optional for
> providers that don't support it.

It sounds more to me that what you want is that the
listener_instance_port is not supported for providers that don't support
it. This is so that we do not have to store data when the LB is set up,
and use that when an instance is registered to the LB, right ? Is there
some way to avoid that, since it constitutes API breakage ?

> In additional to the above, I'd have an rfe for the UI:
> The register instance page in the UI lists all instances. I'd like to
> change that page to:
> 1. only list the instances in the same realm(s) as the load balancer.
> 2. add a way for the user to enter the instance port number.

Both sensible, (2) of course would only show up if the appropriate
feature is supported by the backend.

David