It might depend on the version of ARServer. Things around licenses in server groups changed in the not too recent past; long enough ago that my assumptions may no longer be correct. This may only apply to servers that pre-date the license form and relied on the license file.
>From a simple test I was able to allocate 2 floating licenses across 2 remedy servers for the same user where the Remedy servers are in the same server group: >From Server 1 aruser.log file: > /* Fri Jan 14 2011 16:40:51.1490 */ FLOAT GRANT WRITE testfloater (2 of 16500 write) > /* Fri Jan 14 2011 16:41:28.9884 */ LOGIN testfloater >From Server 2 aruser.log file: > /* Fri Jan 14 2011 16:41:44.0675 */ FLOAT GRANT WRITE testfloater (1 of 16500 write) > /* Fri Jan 14 2011 16:43:28.3593 */ LOGIN testfloater On logout aruser.log shows the following: >From Server 1: > /* Fri Jan 14 2011 16:46:42.1756 */ FLOAT RELEASE testfloater (1 used of 16500 write) >From server 2: > /* Fri Jan 14 2011 16:46:42.2598 */ FLOAT RELEASE testfloater (0 used of 16500 write) 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. On Fri, Jan 14, 2011 at 4:26 PM, Easter, David <david_eas...@bmc.com> wrote: > ** > > Ø “For example, if users have a floating license, they can potentially > allocated a floating license on each server that their request is sent to. > ” > > > > Just to clarify, one user takes one floating token within a server group – > even if there are individual requests from the same user to each server in a > server group. So no matter how many different servers in a server group > that user accesses, they’ll get one token. > > There is logic in the system that stores logged in users in a table that > the various servers can coordinate from. Thus, I do not believe that > scenario can actually happen. > > > > Maybe I’m misunderstanding the scenario… > > > > -David J. Easter > > Manager of Product Management, Remedy Platform > > BMC Software, Inc. > > > > 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. > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Axton > *Sent:* Friday, January 14, 2011 11:04 AM > > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Server Group node > > > > ** Only 2 groups of people that I can think of that won't care about the > floating license multiple allocations: > > - people that don't use floating licenses > > - people that don't use (or pay for) floating licenses > > > > Chances are that applies to a very small subset of users, if any. > > > > 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. > > > > On Fri, Jan 14, 2011 at 12:00 PM, Danny Kellett < > dkell...@javasystemsolutions.com> wrote: > > ** > > 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"_ > _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"
