Hi all,

 

It's been a while since I've had time to work on configuring Zen for our
RDP App server farms but I'm back on it now and could do with some
advice on the latest version. I have upgraded to v2rc3.1 on my test
cluster (running on VMware vSphere 5) and have a few bug reports/feature
requests. My apologies in advance if these have been addressed elsewhere
but I couldn't see them after a quick read through the archive.

 

Firstly, I ran into a bug when configuring my first farm. I accidentally
used a underscore character in the farm name, which resulted in a farm
that saved ok but I could not edit nor delete. I assume this is because
the underscore(_) is used in the config file name as a separator
(RDP_Farm1_pen.cfg for example) and the filename parser looks for the
first underscore but not the last. It would be useful if you could
prevent invalid farm (and cluster node) names from being saved in the
first place. In the end, I shut down zen and renamed the file, all fixed
now.

 

The second problem is a bit more serious for us. Laura did a load of
work for me implementing GARP on node failure behaviour. This means that
the backup node will automatically correct the router's ARP cache when
it takes over a farm. This doesn't appear to work when using the force
failover and maintenance mode buttons and the bad ARP entry stays making
it difficult to failback (you need to flush the router ARP cache
manually). Is this something that is easy to address?

 

Finally, are there any plans to (or does it already exist) some kind of
stateful failover? Things like RDP connections are generally very
long-lived compared with http, smtp or other "ephemeral" protocols. It
would be great of the master node could notify the backup of the current
connection state of each client and real server. A very simple (probably
too simple) approach would be to copy the contents of the "persistence
through memory" lookup, that you already have on the master, to the
backup node every time it changes. This might not be necessary, or even
desirable, with http and those other protocols (especially anything that
is "connectionless" by design) but a massive help with
connection-oriented protocols like RDP.

 

Phew, slightly longer than I'd intended, sorry! I really appreciate all
the hard work that has gone into Zen and with a bit of luck it will be
at the core of our RDP strategy going forward. We have decided NOT to
buy additional F5s based on the progress of Zen so far and I really hope
this is a position we can maintain.

 

Regards

 

David


Johnston Press plc  Registered in Scotland no. SC015382
Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

Opinions expressed in this email are those of the writer and not the company. 
E-mail traffic is monitored within Johnston Press and messages may be viewed.
This e-mail and any files with it are solely for the use of the addressee(s).
If you are not the intended recipient, you have received this e-mail in error.
Please delete it or return it to the sender or notify us by email at
[email protected]


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Zenloadbalancer-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

Reply via email to