Oh, I see, this will not relay work. Because I had the same customer
request, I wrote my own round robin.
First, SSGD servers must be every time addressable by there names. A
nick name or a common name for both server would not work.(IAR,
Printing, XPE Distribution)
Here is what we did.
Each ssgd server has ist own name: iego.domain and rishi.domain
Is fully secure, names have an exact DNS entry,
Also we set up an additional interface one iego.domain with ssgd.domain.
Behind ssgd.domain we have a cgi-interface which redirects either to
iego.domain or rishi.domain.
The cgi-interface knows tarantella status --byserver
The interface ssgd.domain is monitored on iego.domain and rishi.domain.
and if iego.domain fails, rishi.domain set up the interface and sends an
arp to the networt.
This is a very good fail over, no RRDNS is needed and alls certoficats
are correct.
We call this WebtopSession Distribution and VirtuallInteface to address
an SSGD Array with a commonURL.
Here is a part of the documention. If there is more interested, feel
free to send me an email.
TBS Webtop Balancing including virtual interface
SGD is a 3-tier architecture. Tier 1 is the client, tier 2 the SGDDE
server and tier 3 the applications.
The TBS Backplane Module "Weptop Balancing" solves the issue of
permanent accessibility, without DNS Round Robin or URL Load balancer.
First of all, if there is no load balance and the users have only one
URL, all Webtop sessions are handled from one SGD Server. If this
server goes down, all sessions will be lost.
Secondly, by using Round Robin for the URL it is possible to balance
the webtop session. But if DNS responses point to a SGD Server which
is down, the user gets an error message.
So it is important in a production environment that the user accesses
the SGD Array with one URL which is constantly reachable. This URL is
independent of the SGD.
TBS Backplane Service includes a Webtop Balancing mechanism. On each
SGD a background task determines the current status of webtop sessions
on each SGD member.
Additionally, a CGI interface is added in the document root
environment of the web server. This can be accessed via (*Fehler!
Hyperlink-Referenz ungültig.*-Server>). The CGI Interface is aware of
the status of the webtop session on all SGD Members and generates a
redirection for the browser (or native client) to the SGD member with
the least webtop sessions. Also, there is a status page for the
administration available.
This is the first step of a common URL to an SGD Array, which handles
members and is performing a continuous distribution of the webtop
sessions.
In a production environment this common URL is now a single point of
failure. With a special configuration TBS Backplane supports a virtual
Interface across multiple SGD arrays.
As a second step, each SGD Array can hold an additional Name and IP
(ipV). A background task on each SGD Server determines the array name
(production, test, etc) and monitors the existence of its assigned
additional name. Regarding a description the interface and name is set
automatically, if it does not already exist.
The background task (tbsVirtuellInterface.tcl) on each server
determines which virtual interface definition (viDefinition) is
responsible. The background task searches its host name in the lists
of virtual interface definitions. The list of responsible servers is
internally alphanumerically sorted and will be handled as a priority
list. If the server is found, the background task knows that it can be
responsible for the virtual interface. Before it is set, different
checks are performed.
The IP-interface will be assigned,
*
if its higher priority server is not available
*
if the server is running SGD
*
if the server is on the network
*
and the virtual IP is not found on the net.
The check is performed every 10 seconds. The transparent fail over
will by about 30 seconds.
Whenever an interface definition changes, the background tasks send an
arp request to the network. This is implemented to inform the routers
about the new MAC address.
The functionality of virtual Interface works only with a Secure
Installation based on https (port 443, firewall traversal)
Christian McHugh schrieb:
On Wednesday 02 May 2007 11:28:25 David W. Fong wrote:
Not sure if this would resolve your issue, but have you checked to make
sure that the peer DNS names of your array are resolvable forward and
reverse on both servers?
Well that brings up the issue of how this array was built. I'm not exactly
sure this is the right, but here goes. There are two servers iego.domain and
rishi.domain. We added External DNS entries for sgd.domain, and set up round
robin dns to point to both servers. Opening a webbrowser to sgd.domain works,
users log in, lauch apps etc.
Everything appeared fine.
We had heard that it would be better to run the web portion secured as well,
so we set up certs on both servers for sgd.domain, and changed the sgd
website login links to run https://sgd.domain/sgd/index.jsp. After that we
had occurrences of the before mentioned soap error. The error seemed to go
away after changing the links back to just http:// and we figured all was
well.
So all of this to say that yes, sgd.domain, rishi.domain, and iego.domain all
resolve in both directions, but sgd.domain is round robbin. Is there a better
solution or a recommended way to go about this type of setup?
Possibly related, when we had just a single server we set up pdf unix
printing. Users could then run the lp command described in the sgd docs and
get their results "printed" to a locally running pdf viewer. After setting up
the array this printing functionality only seems to function if you are
connected via one of the servers (I forget which off the top of my head). If
you try to print from the non-functional one, you see the job in your webtop
print queue, but your pdf viewer never opens. The only thing to do seems to
cancel that job and try logging back in, hoping you get a "good" connection
the next time.
Thanks everybody,
Christian
_______________________________________________
SGD-Users mailing list
[email protected]
http://node1.filibeto.org/mailman/listinfo/sgd-users
--
*ToolBox Solution GmbH*
CEO/CTO Tillmann A. Basien
Balinger Straße 37A
D-70567 Stuttgart
Fon: +49 (0) 711 71 68 631
Hy : +49 (0) 173 87 38 987
Fax: +49 (0) 711 45 70 899
*** Sun Microsystems OEM Partner ***
mailto:[EMAIL PROTECTED] / http://www.tbsol.de <http://www.tbsol.de>HRB: 23711
This message and any files or documents attached are strictly
confidential or otherwise legally protected. It is intended only for the
individual or entity named. If you are not the named addressee or have
received this email in error, please inform the sender immediately,
delete it from your system and do not copy or disclose it or use it for
any purpose. Please also note that transmission cannot be guaranteed to
be secure or error-free.
_______________________________________________
SGD-Users mailing list
[email protected]
http://node1.filibeto.org/mailman/listinfo/sgd-users
