Axton, Thanks. I was looking for that Tomcat info. Hugo from BMC just did a presentation on this at WWRUG. The big thing he was stressing was to make sure IP Multicasting was setup if you are using 7.6.04. If this is setup you shouldn't have to use the stickbit. We are currently configuring this with one of our customers and the IP Multicasting was the missing piece.
Thanks, Brian On Wed, Sep 21, 2011 at 11:50 AM, debug ars <[email protected]> wrote: > ** Thanks Axton for all your inputs. > > Cheers > Amen... > > > On Tue, Sep 20, 2011 at 8:50 PM, Axton <[email protected]> wrote: > >> ** http://documents.bmc.com/supportu/documents/61/98/186198/186198.pdf >> >> The information is a bit vague in regards to load balancer configuration >> in front of the midtier/web servers, but note that in the whitepaper, >> everywhere it says that session persistence is not required, it refers to it >> as the load balancer between the midtier and arservers or in front of the >> arservers. >> >> The release notes make the following statement: >> http://documents.bmc.com/supportu/documents/43/74/184374/184374.pdf >> >> New load balancer configuration options >> If your AR System uses a hardware load balancer between the mid tier >> servers and AR System servers, BMC recommends configuring that load balancer >> without using a sticky bit by using the Connection Settings page in the BMC >> Remedy Mid Tier Configuration tool. >> >> Note that it does not state to turn it off for the load balancer in front >> of the mid-tier. >> >> You might be able to get away without setting up session persistence with >> the later versions of the midtier since the API does not have a native >> library dependency (assuming they implemented the serializable interface for >> all the non-native session specific things), but there is extra >> configuration you need to do with your J2EE container. For Tomcat, see >> here: >> >> http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html >> >> To run session replication in your Tomcat 6.0 container, the following >> steps should be completed: >> - All your session attributes must implement java.io.Serializable >> - Uncomment the Cluster element in server.xml >> - If you have defined custom cluster valves, make sure you have the >> ReplicationValve defined as well under the Cluster element in server.xml >> - If your Tomcat instances are running on the same machine, make sure the >> tcpListenPort attribute is unique for each instance, in most cases Tomcat is >> smart enough to resolve this on it's own by autodetecting available ports in >> the range 4000-4100 >> - Make sure your web.xml has the <distributable/> element >> - If you are using mod_jk, make sure that jvmRoute attribute is set at >> your Engine <Engine name="Catalina" jvmRoute="node01" > and that the >> jvmRoute attribute value matches your worker name in workers.properties >> - Make sure that all nodes have the same time and sync with NTP service! >> - Make sure that your loadbalancer is configured for sticky session mode. >> >> So even with Tomcat cluster configurations the load balancer must have >> session persistence. I imagine the strategy with the above statements is to >> support a session moving from one node to another node in the event a node >> fails, not to simply allow any random request to go to any node. >> >> Again, the J2EE container cluster configuration may or may not work. I >> can't find anything stating experimentation either way. >> >> Axton >> >> On Tue, Sep 20, 2011 at 9:21 AM, Richard Copits < >> [email protected]> wrote: >> >>> ** >>> >>> How can I get a copy of the whitepaper? Thanks.**** >>> >>> ** ** >>> >>> *From:* Action Request System discussion list(ARSList) [mailto: >>> [email protected]] *On Behalf Of *Axton >>> *Sent:* Tuesday, September 20, 2011 10:18 AM >>> *To:* [email protected] >>> *Subject:* Re: Software load balancer with AR Server and Mistier**** >>> >>> ** ** >>> >>> ** I believe you still need session persistence with the mid-tier in 7.6. >>> You do not (and have not really) required session persistence with the >>> ARServer. A whitepaper available for 7.6 details this.**** >>> >>> ** ** >>> >>> The timeout on the load balancer needs to match or exceed the session >>> timeout of your mid-tier application.**** >>> >>> If you are using a single sign on solution the mid-tier session timeout >>> needs to be less than or equal to the SSO session timeout.**** >>> >>> ** ** >>> >>> So this would be a valid combination:**** >>> >>> Mid-tier Session Timeout: 60 minutes**** >>> >>> SSO Session Timeout: 120 minutes**** >>> >>> Load Balancer Session Persistence Expiration: 60 minutes**** >>> >>> ** ** >>> >>> In order for a J2EE application to not require session persistence a >>> number of things have to be in place:**** >>> >>> - all objects in the container must be serializable**** >>> >>> - the container nodes in the farm must be configured as a cluster >>> (session information must be serialized)**** >>> >>> ** ** >>> >>> There are some things that make me believe this is not possible with the >>> midtier. Some information that is session specific is written to disk. I >>> doubt these can be properly replicated between the J2EE containers.**** >>> >>> ** ** >>> >>> Axton**** >>> >>> ** ** >>> >>> On Tue, Sep 20, 2011 at 4:53 AM, debug ars <[email protected]> wrote:* >>> *** >>> >>> ** Thanks Ken. We have search all articles and also went through >>> documentation related to this. [We found that in 7.6.04 Midtier there are >>> few additional configuration parameters available in which may not require >>> stickiness to be set on load balancer. I have not tried those options yet >>> though.] >>> >>> We have finalized on crossroads after careful review of all three. I will >>> post my comments once we complete our testing. **** >>> >>> ** ** >>> >>> On Tue, Sep 20, 2011 at 7:10 AM, Cecil, Ken <[email protected]> wrote:* >>> *** >>> >>> ** **** >>> >>> I have not done any testing but do recall seeing several Mistier related >>> BMC knowledge base articles where the cause of the issues were related to >>> Load Balancer use and settings like stickiness. Make sure you do a search on >>> the support sight for load balancer and review them…**** >>> >>> **** >>> >>> Ken Cecil**** >>> >>> Hubbell Incorporated**** >>> >>> **** >>> >>> *From:* Action Request System discussion list(ARSList) [mailto: >>> [email protected]] *On Behalf Of *debug ars >>> *Sent:* Monday, September 19, 2011 5:56 AM >>> *To:* [email protected] >>> *Subject:* Software load balancer with AR Server and Midtier**** >>> >>> **** >>> >>> ** We are exploring various options to setup our test environment in >>> server group with load balancer. >>> Does anyone tried to use software load balancer for AR Server Group and >>> Midtier? If yes, can you share details like, which software, version, >>> configuration parameters like stickiness, timeout etc? >>> [We have identified three with which we will be experimenting - >>> crossroads, balanceAG and haproxy] >>> >>> -- >>> Cheers >>> Amen >>> >>> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ **** >>> >>> *********************************************************************** >>> >>> This email and any files transmitted with it are confidential and**** >>> >>> intended solely for the use of the individual or entity to whom**** >>> >>> they are addressed. If you have received this email in error please**** >>> >>> notify the system manager. This footnote also confirms that this**** >>> >>> email message has been swept for the presence of computer viruses.**** >>> >>> www.Hubbell.com <http://www.hubbell.com/> - Hubbell Incorporated****** >>> >>> ** ** >>> >>> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_**** >>> >>> >>> >>> **** >>> >>> -- >>> Cheers >>> DA >>> -- On seventh day almighty started debugging**** >>> >>> >>> >>> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ **** >>> >>> ** ** >>> >>> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ **** >>> >>> ------------------------------ >>> >>> Portions of this message may be confidential under an exemption to Ohio's >>> public records law or under a legal privilege. If you have received this >>> message in error or due to an unauthorized transmission or interception, >>> please delete all copies from your system without disclosing, copying, or >>> transmitting this message. >>> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ >>> >> >> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ >> > > > > -- > Cheers > DA > -- On seventh day almighty started debugging > > _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"
