Okay, that was an epic answer. The "what if's" here are interesting. We have spent a great deal of time developing this idea, including time with BMC PS last year, ongoing conversations with support, as well as our own internal database people.
The real crux of the problem we have is that you either can limit the records returned - or you can't. In a server group it's fairly reasonable to have that setting the same for all servers, or it would be confusing to the user base. Hence, we went this direction to have new servers, etc. It's also fair to point out that when I say "Reporting servers" that runs the gamut from someone using Crystal or ODBC to pull hundreds of thousands of records down to some random ad hoc query run by a user and then exported. It was be HIGHLY desirable to have a special reporting queue/thread/RPC that was unlimited while still limiting "normal" queries. (bonus points - make it only accessible by permissions/roles/etc) B From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mueller, Doug Sent: Tuesday, December 10, 2013 11:23 AM To: arslist@ARSLIST.ORG Subject: Re: Adding servers to the server group ** William, My strong suggestion is to add the servers as regular servers in the server group. Then, just don't have them behind the interactive load balancer but maybe a reporting load balancer. So, regular interactive traffic is not directed to them. Point mid-tiers for interactive use at the interactive load balancer, they will not go to these new servers. Do not register them for any services or failover. So, they won't run any of the standard services and nothing will fail over to them. Not sure what about SLM will be running here. but I see no issue with not running things related to SLM. For the CMDB however, I would go ahead and have the main CMDB running. Any CMDB API call - and maybe someone does some CMDB reporting in the future - will need that process. Don't run the Reconciliation engine or Normalization engine and don't have them configured for failover there. So, these servers are full and regular and complete members of the server group. They are simply "on the side". They do not run services. They do not have things failover to them. They are not behind the standard load balancers.... The same strategy is generally used for integration servers or other special processing servers where you have volume of interaction that you want to isolate. You are just doing this for reporting. By being in the server group, license sharing and coordination works vs. looking like separate environments, some future upgrade enhancements to upgrade the environment from single locations or zero down time work because it is in the server group, and many other benefits. Be in the server group, just configured to be a separate environment within the group..... Now, one more topic.... WHAT IF... WHAT IF you could imagine a situation where you could optionally specify a "reporting server" that whenever you ran a report, it would be directed to that "reporting server" rather than the server you were interacting with (say it was a server configuration setting so the server could tell you that there was a "reporting server" to use). If you had this, you could configure things just like the above, but then your interactive users just doing work who decided to run a report could have that report automatically and transparently directed to the "reporting server" so that ALL reporting would go through this secondary set of servers and never against the main interactive servers? WHAT IF - you didn't want to go as far as the above, but you could specify specific reporting RPC queues so that all reports were directed to separate queues and so separate DB threads to the interactive use of the environment. WHAT IF..... Lots of interesting WHAT IF thoughts and discussions that can be envisioned to take the type of configuration you are looking at and making it automatic and inherent in the overall system. Just some random thoughts with no implication that there are features or ideas or functions or anything along these lines... Just some simple WHAT IF thinking..... Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of William Rentfrow Sent: Tuesday, December 10, 2013 7:42 AM To: arslist@ARSLIST.ORG Subject: Adding servers to the server group ** So we currently have 6 AR servers in a server group - I'm adding some more. Two of the new servers will be solely to support reporting. I'm sort of mulling my options. I do not need them to be in the server group - at least in the sense of taking over any functions if a task goes down. The only reason we are adding these is so we can change the # of records returned in a query to unlimited. The users who use these servers will access them via a separate URL and separate MT servers. For example, our normal users access it internally via something like http://remedy - our reporting users will access it via an URL like http://remedy_rptg. These AR servers also connect to the database in a slightly different way, using a defined service instead of a regular listener - this gives the DB the ability to throttle their queries, so they do not receive more than X% of the total Oracle RAC computing power (and hence can't slow down regular users). So here's my rough plan - tell me if you'd do this differently (this is 7.6.04 for AR/Apps running on SuSe Linux with Websphere and Oracle, if you need to know) 1.) Install ARS, license, configure threads, etc 2.) Install CMDB, ITSM, RKM, SLM, SRM using the environment variable "Skip" option method to avoid loading the app in the database. 3.) Comment out the SLM and CMDB processes in the armonitor.con 4.) Add them to the server group but have NO entries in the Server Group Operation Ranking form - the only real reason to do this is to disable escalations and admin functions, as well as making them "aware" that they are not the top dog in the SG. 5.) Modify the ar.conf for all of servers and adding the IP-Name entries that are appropriate William Rentfrow wrentf...@stratacominc.com<mailto:wrentf...@stratacominc.com> Office: 715-204-3061 Cell: 715-398-5056 _ARSlist: "Where the Answers Are" and have been for 20 years_ ________________________________ No virus found in this message. Checked by AVG - www.avg.com<http://www.avg.com> Version: 2014.0.4158 / Virus Database: 3658/6902 - Release Date: 12/08/13 _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
