You have to remember that if the AR Server is looking for the FQDN, then you have to remember how the TCP packet will travel to get to that address. E.g. If its not in the local host of the AR server (which I recommend as well as having an IP-Name: FQDN in the ar.conf) then the packet could route out to front end side of the firewall and thus get rejected.
I add the AR Servers and the front end address of the firewall to DNS for the client, but I also add the same details to the local host of the AR servers. Kind regards Danny Kellett -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of strauss Sent: 11 November 2010 19:56 To: arslist@ARSLIST.ORG Subject: Re: DNS entry for Server Group I never got the apps to install properly - ITSM 7.6.03 refused to install in a server group environment, even with the admin server that I was installing on taken out of the group. As a result I never even got to try the SRM, RKM, and SLM installations. I just finished bring the same server up completely with all apps in standalone mode - the cleanest install I've had lately except for RKM, and am debating just adding servers to the same db (no server group). I _might_ try to build a server group on the complete stack, but with the expectation that server groups are a black hole that you can pour time and energy into without ever finding the bottom. Needless to say, I am not impressed. It's no accident that there are dozens of KB articles on 7.x server group problems, and they are not exhaustive of the issues (nor always in agreement on the solutions). BTW, one lesson learned (now that you have to install FTS to support RKM) is that the ARS installer adds FTS to the ar.cfg incorrectly using the FQDN: Server-Plugin-Alias: ARSYS.ARF.FTS ARSYS.ARF.FTS servername.domain.unt.edu:9998 You won't notice it until you try to index something (we've never had FTS before, plus this is a brand new one in 7.6.03, so we would never have noticed), OR until you try to install RKM 7.6.03. It has to be changed to: Server-Plugin-Alias: ARSYS.ARF.FTS ARSYS.ARF.FTS servername:9998 ...preferably before the install. During my RKM install, it generated 177,000 error entries in the arerror.log when I didn't change it, but left it as installed by ARS 7.6.03 with the FQDN. Most of the errors that I have encountered in the server group testing involved plugin errors, and of course a lot of the plugins were converted from C to java in 7.6.03 so I don't expect them to work as reliably as they once did, anyway. The installers - ARS, Atrium, and the apps - like to switch between short server name and FQDN in how they define the Server-Plugin-Aliases, and I think that is a _major_ part of the problem, which becomes a fatal error in a server group. Until BMC sorts this out completely - and DOCUMENTS it, it may be more trouble than it's worth. The only people who have responded to me with information that are actually using server groups successfully (after numerous support tickets and changes to the ar.cfg/conf file) are on 7.5.00.006 or earlier, not 7.6.03. I cannot recommend 7.6.03 for server groups (yet;...ever??) without more testing than I probably have time for. It is more important to me to migrate to the 7.6.03 apps than to get server groups working, so I will not re-visit a 7.5/7.6.00 implementation, but will probably limit myself to having multiple servers on the same db. You may find 7.5 a safer route, since it sounds like a lot of sites (on arslist) have successfully upgraded their AR servers to 7.5 underneath the 7.0.x (or custom) applications. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Murnane, Phil Sent: Thursday, November 11, 2010 1:07 PM To: arslist@ARSLIST.ORG Subject: Re: DNS entry for Server Group Christopher: Did you ever get you 7.6.03 server group to fail over properly? I have a customer that's planning to update their 7.1 ARS server groups, and we're trying to figure out whether 7.5 or 7.6 is best for now. Thanks! --Phil -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of strauss Sent: Monday, November 01, 2010 17:57 To: arslist@ARSLIST.ORG Subject: Re: DNS entry for Server Group Off-list hints led me to add an "A" record in the Active Directory DNS in my forest for each IP address - the admin server and the member server - for the common server name alias. That name does not need to be added to campus DNS since it is only used by the servers to communicate amongst themselves. Today I started trying to test fail over of things like the mail system or the entire AR system, with no success at all. The mail server on the failover AR server never picks up the work - it remains suspended when the admin server mail service is shut down. It also remains suspended when I shut the entire admin server down, and in fact does not take over as the admin server - it starts crashing the armonitor and ar service constantly, with an ARERR - 90 against its own server name. When I rebooted the member server without the admin server running, the ar monitor crashed a half dozen times complete with a popup faulting error. When I rebooted both of them (after updating the hosts file on each with a pointer to the shortname of the server and the server group alias) they both either pop up application fault errors or crash continuously in the arerror.log or report unavailability of the FTS Plugin. Impressive. Since I have followed the server group configuration docs to the letter in almost every section (did not config Alerts), I am becoming convinced that server groups in 7.6.03 are completely dead on arrival. Depending on which server reboots first, one will constantly crash the arserver.exe, and the other will spit out plugin server errors or FTS plugin errors or both, and errors about not being able to connect to its own local AR Server (the ARERR 90's). There are no apps on this lash-up, just the two AR Servers, and they are behaving so badly today that I'm just going to shut them down. I'll open a ticket to support and give them a shot at the log files before abandoning the entire concept (of server groups). Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Murnane, Phil Sent: Thursday, October 28, 2010 4:00 PM To: arslist@ARSLIST.ORG Subject: Re: DNS entry for Server Group Funny you should mention this Christopher, I just had to do the same thing for a client. It seems the normal configuration is to point all ARS clients (user tool, mid-tier, API, etc) to the load balancer alias name, which is also the name of the server group. The load balancer then does its job and spreads the load among the group member servers. Since each member of the group knows the load balancer alias as itself, it doesn't really matter which server handles any given transaction (speaking generally, in practice there are "sticky" session matters to deal with). So what to do if you're not using a load balancer? We followed the instructions in the AR System guide for managing server groups and then added one additional step of our own -- for each host that will run an ARS client, we manually updated the hosts file to resolve the server group name to one of the group member server's IP address. We estimated the load each client would generate, and tried to balance that load across the member servers. Of course if a client is running on a member server, then it's efficient to have the server group name resolve to 127.0.0.1 (or the equivalent). It's important to note that all clients are configured with server name = group name except for admin class clients, who always have server name = admin server name. HTH, --Phil ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org 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" ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org 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"
