* Mario Kleinsasser <mario.kleinsasser+deb...@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: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ---------------------------------------------------------------------- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101020001829.ga20...@nibiru.local
