[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GSLB global server loadbalancing - possible?

* Mario Kleinsasser <mario.kleinsasser+debian@gmail.com> schrieb:

> Yes, I know. Currently we have in one sinlge central location an Apache
> acting as load balancer for an "portal" application hosted on multiple
> (four) Tomcats. The farm is useing about +160 Tomcats but this isn't
> important. Important is, that this self programmed portal has also
> implementet the Citrix API (beside others RSA etc.). Therefore this portal
> should reside in different countries, because the terminalserver farms are
> also in different countries. So in "worst" case the country with the
> terminalservers in this country is like an island. Let me say there is a
> terminalserverfarm in warsaw Poland and another is in cologne Germany.

How exactly are the terminalservers related to the portal ?
> Normaly the users are connecting to all farms through europe but in desaster
> case they should be able to connect to there "local" farm (priority) and
> they should be able to use always the same domain name to use the portal
> that is providing the applications.

Wouldnt it be better to provide more locality, IOW: let the users always
connect their local tsfarm and have a backup at another location ?

> The main thing is, how to provide the same domainname like
> portal.company.com in different locations with maybe different ip addresses?
> Bind zones would be an option I think.

You mean bind views. That might be an option. Assuming switching A 
records is enough for a failover.

Where do the clients come from ? Intranets or outside ?
Do you have control over their resolvers ? (otherwise you might have a
bad awakening, when they cache too long).

> Jep, we are currently testing BGP (of course anycast) but this isn't easy to
> manage in an MPLS environment through multiple countries and different
> providers :-)

What do you MPLS for ? Do you have your own carrier lines ?

> If you want, I would make a short draft to make things clear.

Okay, let's see it :)

> > Yes, indeed. For example, mirroring cluster node's storage space via
> > DRBD (beware: synchronous write performance over the ocean is *really*
> > bad. the commercial proxy, essentially a buffered pipeline, helps a bit,
> > but still suboptimal) - we already have some concepts for a transaction-
> > based replicated blockstore (which also includes cheap snapshots, etc),
> > but not yet the resources to actually implement it.
> >
> No need to sync data that way. The portal software is able to store all
> needed data in local Derby DB. And the data used by the portal could be
> "older" and must not be highly synced. If the primary portal where the user
> is connected crashes, the users have to close the browser, fire up a new
> one, create a new session in the "next" location ans login again. But the
> domain have to be reachable in any case....

What about the terminal servers ? How are they synced ?

 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme

Reply to: