Yes I agree but that is fault tolerance not load balancing.
From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: 14 January 2011 18:45 To: arslist@ARSLIST.ORG Subject: Re: Server Group node ** The difference between straight to and with LB between mid-tier and App is that if one of the nodes fails, traffic will be automatically be transferred from the broken nodes to the active nodes. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Danny Kellett Sent: Friday, January 14, 2011 11:00 AM To: arslist@ARSLIST.ORG Subject: Re: Server Group node ** I guess its not true load balancing then. Just load sharing. If you have a session infinity set at the LB on in front of the ARServers then there is no difference that having each midtier bypassing the LB and going straight to the ARServer instance. E.g. mt1 to AR1, mt2 to AR2 etc I don't think anyone would want to implement something that could take more than one floating license at one time though Axton right? From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: 14 January 2011 17:52 To: arslist@ARSLIST.ORG Subject: Re: Server Group node ** >From Page 8 of 84092-Using A Hardware Load Balancer with AR System.pdf The load balancer acts like a NAT device that routes any TCP or UDP traffic. Since the AR System server uses an ONC-RPC implementation that is layered on top of TCP/IP, AR System server traffic can be load balanced. Because of the nature of the client/server interaction within AR System, the "sticky" option is required. This reduces the balancing that can occur, but still allows for the spreading of the workload from multiple clients. I'm just using the docs J From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Axton Sent: Friday, January 14, 2011 10:11 AM To: arslist@ARSLIST.ORG Subject: Re: Server Group node ** Authentication information is included in each packet to the arserver, so it can run without session persistence. However, there are trade-offs. For example, if users have a floating license, they can potentially allocated a floating license on each server that their request is sent to. This statement does not apply to the mid-tier layer though. The J2EE container in use has session information stored that is required to handle requests from a user. If the user is re-directed to a mid-tier server where this session information is not available, the user will fail authentication and will be redirected to the login interface. The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
