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 ?
cu
--
----------------------------------------------------------------------
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: