We no longer recommend the shared mount point configuration. In fact in 7604SP5 and 81SP1, FTS has been reconfigured to have 2 FTS plugins on the "indexing" server - 1 for the indexing AR Server and 1 for the other servers (readers) in the group. This is the recommended configuration for any version. This does not resolve the slow access time with remote disk systems, but we have not seen index corruption problems since moving to this configuration. As Doug indicated, the simplest and most reliable way to resolve the slow performance of the search engine is to use a local disk. Keith
From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of William Rentfrow Sent: Thursday, October 23, 2014 12:29 PM To: arslist@ARSLIST.ORG Subject: Re: Remedy 8.1.2 on VM ** The one we've had the most trouble with is 7.6.04 SP3. And yes - the FTS indexes were created and stored on one mount point which was mounted on all of the AR Servers. The admin server was the only server capable of writing/updating the indexes but all of the servers needed access. We also tried a few different configurations - for example, we tried it with custom FTS plugin configurations so the AR servers were making calls to the admin server instead of reading the files directly - the thought here was that file locking was messing things up, so having only one server touching the files might work. That didn't fix it either. We have never had it be stable for longer than a month - and that was on 7.6.03x. On 7.6.04 we couldn't get it to be stable for more than a few days. We are now working on a couple separate instances of 8.1x and I'm hoping to get it working there. I haven't started yet though. Before I got started I wanted to see how everyone else was doing this in server groups. Also, the first 8.1x server group we are working on has only two servers, so my expectations are that any collision/competition for resources should be much lower. William Rentfrow wrentf...@stratacominc.com<mailto:wrentf...@stratacominc.com> Office: 715-204-3061 or 701-232-5697x25 Cell: 715-498-5056 From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Odom, Keith Sent: Thursday, October 23, 2014 1:58 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Remedy 8.1.2 on VM ** William, Down in this email chain you said : "... We always had the same issue - we'd index stuff, it would work, and the indexes would get corrupted within a few days. ... We did have separate ESX storage for the FTS directories, shared by all servers. " What do you mean by "shared by all servers"? Does each server in the server group have an FTS plugin pointing to a shared collection directory? What version of AR are you running? Keith From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mueller, Doug Sent: Thursday, October 23, 2014 10:42 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Remedy 8.1.2 on VM ** William, The challenge is the performance and reliability of the file system with heavy use. We have found that the heavy interaction with the file system that FTS performs runs into challenges with remote file systems. You can configure servers with local file systems vs. network file systems that are then used to host VMs. You can configure that certain VMs are run on certain machines. So, what customers do is have some machines in their environments with local disc interaction and they configure servers that are FTS indexers to run their VMs on the machines with local file systems. This is still using VMs, but with some specific configurations. For servers not FTS indexers, there is no restriction of local file systems. Not having local file system and using FTS will work - but at a notable performance penalty. So, how do customers deal with it? - don't use FTS or MFS (fewer customers in this camp every day) - accept the performance issue with MFS searches and use FTS sparingly for key large text/attachment fields so even with performance overhead, is faster than DB search - Lock FTS indexer server VMs to specific machines that have local file stores Doug From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of William Rentfrow Sent: Thursday, October 23, 2014 10:11 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Remedy 8.1.2 on VM ** Hi Doug - Thanks for the answer - we've been through this with support many times. The question I've never really gotten answered in an authoritative way is this: What exactly does BMC expect us to do with VM to have a "local" file system when we are using giant enterprise class servers? In the most simple VM setup (not ours) a person might have VM Ware with a file holding the entire VM. This file sits on one (or more depending on RAID, etc) drive of the server. That's not us. We're running VM's off of HP ProLiant BL685c G7's (64 CPU with 524GB Memory). Each VM server is allocated 4 processors and 15GB of RAM (at this point). All of the storage for the applications is ESX storage mounted over NAS. There really isn't any "local" storage. How do other people deal with this? William Rentfrow wrentf...@stratacominc.com<mailto:wrentf...@stratacominc.com> Office: 715-204-3061 or 701-232-5697x25 Cell: 715-498-5056 From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mueller, Doug Sent: Wednesday, October 22, 2014 2:31 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Remedy 8.1.2 on VM ** William, It feels like what you are seeing is not a VM vs. physical issue, but an issue about how FTS works and the requirements about configuration to allow scaling and proper behavior. FTS is very FILE SYSTEM intensive. All the indexing of the files and the searching of the indexes is file system dependent. So, what is important for FTS to scale and properly handle large volumes is to be on a LOCAL file system rather than a network file system for the main FTS index directory. This is important whether you are on a physical system or a virtual system. So, there should not be any issue with being virtual, just you need to be virtual tied to a specific physical system that has local disc that has the FTS index directory for full capability. This does constrain the virtual configuration to not just allowing the image to move around to any random machine. This would not apply to all servers, just to the ones that are FTS index servers so that they stay tied to their local file store. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of William Rentfrow Sent: Wednesday, October 22, 2014 10:40 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Remedy 8.1.2 on VM ** Are you guys who are running VM's using Full Text Search? We've never really gotten that working. We always had the same issue - we'd index stuff, it would work, and the indexes would get corrupted within a few days. BMC wanted us to go to independent physical drives but we have all VM's. We did have separate ESX storage for the FTS directories, shared by all servers. We tried a number of alternative FTS plugin configurations but always ran into some type of issue. It's worth noting this is a high-volume environment. I'd love to know if anyone is using FTS on a VM, and how it is configured (especially with a server group). William Rentfrow wrentf...@stratacominc.com<mailto:wrentf...@stratacominc.com> Office: 715-204-3061 or 701-232-5697x25 Cell: 715-498-5056 From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mueller, Doug Sent: Wednesday, October 22, 2014 12:21 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Remedy 8.1.2 on VM ** Tommy, With all the caveats about making sure you are correctly configuring your VMs and you have properly given them sufficient resources and you have properly done all the right things with how the network and disc and everything is interacting with VMs (all things that should be done regardless of what you are putting in a VM)... There is no issue with running mid-tier and server and any component of the AR System environment or apps on VMs. The DB layer can run in a VM. We have seen evidence of large scale users with lots of data getting better overall throughput on physical machines for the DB, but it will work in both places. BMC itself runs with a physical DB and all AR System servers and mid-tiers on VMs. This is a common configuration in many of our customer environments. I hope this helps, Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Tommy Morris Sent: Wednesday, October 22, 2014 9:04 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Remedy 8.1.2 on VM ** Just wondering how many are running the current ARS, CMDB, ITSM on VM's. My current hardware is at end of life and I need justification to purchase a new server. Our mid-tiers are running VM with no problem of course but I am concerned about the stability and performance of running ARS and CMDB on a VM instance. Anyone have pros/ cons of going virtual? [cid:image001.png@01CE87C8.A8D7D890] Tommy Morris Sr. Remedy Developer RadioShack Corporation 300 RadioShack Circle Fort Worth, TX 76102-1964 O > 817.415.2510 radioshack.com _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.4765 / Virus Database: 4040/8433 - Release Date: 10/22/14 _ARSlist: "Where the Answers Are" and have been for 20 years_ _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.4765 / Virus Database: 4040/8433 - Release Date: 10/22/14 _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _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.4765 / Virus Database: 4040/8433 - Release Date: 10/22/14 _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"
