This includes the response to LGs question....
NOTE: I was not saying anything about HOW you configure the DB connection. I am fine with the different type of DB connection. That is a CONFIGURATION option on each server - how the DB connection is defined. So, configure your new servers that are in the server group with their special type of connection to do the throttling that you are describing. My point is just that those severs are IN the server group. They are NOT behind the interactive load balancer so they would not be used for interactive queries. You still access them by a separate set of mid-tiers or URLs or whatever. Just because they are separately accessed and are not shared does NOT mean they are not part of the same server group. Too many people assume that server group means "all the same" or "all behind the load balancer" or any other permutation. You can have servers that are full members of the server group that are for isolated or special purpose use. They can have completely different rules and configurations. They can have different characteristics of DB connections (like in the case you are describing). They can have different settings for query limits. They can be accessed by different mid-tiers or not by the mid-tier at all. They can be part of background engine processing or not. They can be failover machines or not for background processing. So, the servers can be radically different and have different configurations and use. They are still however part of the server group and known to each other and they cooperate and they share users and they are told about config changes on each other and the like. Also, YOU know it is a server group. Users don't have to know anything. They are told to go here for interactive use and there for reporting.... So what if it is a server group or not from their perspective. Don't confuse the internal system design with how you expose different accesses and functionality to users. So, different settings and different limits on different servers are a "who cares" type of things. These things are set appropriate for the USE of that server. (yes, it would be odd to have multiple servers behind a load balancer with significantly different config that you direct a user to so that they get random config differences with the SAME access at different times. that is why these reporting servers ARE NOT behind the interactive use load balancer so that they are never directed to except by using your reporting URL which is DIFFERENT than the interactive use URL) Yes, there is no issue with different reporting tools. Ones that go through AR System (preferred as you get permission enforcement) go to the Reporting AR System server instances (in the server group). Ones that do not, just go to the DB directly and have nothing to do with any AR System server instance. Finally, note that the reporting functionality within AR System does have logic that when running a report, you bypass the "number of entries" limit as the reporting system automatically handles allowing you to get a report that is larger than the number of entries limit. This is a feature that is already built into the reporting through the mid-tier environment. The point of my message was NOT to change the overall design and goal you were trying to accomplish. That is just fine and I have no concerns or issues about it. It is just to point out that these servers ARE PART OF THE SERVER GROUP and please think of them and install them that way. You can have completely different configuration. You can have these excluded from failover support. They are part of the server group however and get all the benefits that entails. I hope this has cleared up any confusion, Doug Mueller From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of William Rentfrow Sent: Tuesday, December 10, 2013 10:00 AM To: [email protected] Subject: Re: Adding servers to the server group ** 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:[email protected]] On Behalf Of Mueller, Doug Sent: Tuesday, December 10, 2013 11:23 AM To: [email protected]<mailto:[email protected]> 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:[email protected]] On Behalf Of William Rentfrow Sent: Tuesday, December 10, 2013 7:42 AM To: [email protected]<mailto:[email protected]> 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 [email protected]<mailto:[email protected]> 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_ _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"
