I'll be publishing an article that covers this in more detail in the near future. The recommendation to have knowledge on a separate server still stands though as Lucene takes up considerably less space than Verity it's possible to have it on your application server.
Should you choose to build Lucene on a separate box then I would strongly recommend that you have TPS on that machine too. Background Processing could conceivably be installed on an application server, though, for simplicity I'd install that on the Knowledge server too. You should never have more than one instance of Background Processing started at any one time so there's no point installing it in more than one place unless you have a dedicated fail-safe server. This is because the tasks that background processing caries out are defined in the database and there is no mechanism for specifying which instance of background processing carries out each task.
As far as Knowledge-building goes, Background Processing just polls the knowledge queue tables and kicks off TPS to actually do the Lucene build so it's not an onerous task and should not have any detrimental effect on other background tasks such as escalation point processing. This is particularly true if it's using a dedicated TPS.
I hope that helps to clarify things,
Thanks for the quick response.
Our concern though is no so much about the disk space used by Lucene Knowledge but by the processing power needed.
I presume BS is doing the KB indexing and TPS does the free text searches?
Is either of those going to be max'ed out and need scaling out if we have for example lots of background searching going on.
No, Background Service polls the knowledge queue tables and if it finds any entries then it asks TPS to add the build. Requests for search results will go through TPS, but it will be the TPS that the client is logged in to. Using a separate knowledge server therefore means that the TPS that does the builds will not also be used for searching the knowledge base.
If you do a lot of background searching then yes, your TPS's will need scaling out to accomodate the extra work-load of the searching.
Still not 100% clear on this one. I've read the new Arch., & Tech. Spec doc (looks like Dave Edgar's handiwork judging by some of the Diagrams in there!!) too and doesnt from what I can see mention putting on a different server even for the large scale deployment.
If we did do then, and put the KB datafiles and TPS on a different (KB) server (ie split away from our App Server) then where does the Background engine sit, on App Server or KB Server?
We are planning to use background searching (blank space) heavily.
As far as putting Knowledge on a separate server is concerned it's entirely your choice. However, whereever you choose to build Lucene you must have a TPS on that same machine. In order to make life easier I'd put Background Services on that machine too.
If I understand correctly, you've currently put 'the KB index files in a shared folder on DB server and TPS/Background service on APPS server.'
From what Lara has said, the suggested approach is this:
"Should you choose to build Lucene on a separate box then I would strongly recommend that you have TPS on that machine too. Background Processing could conceivably be installed on an application server, though, for simplicity I'd install that on the Knowledge server too. "
Is this approach do-able for you? If it's not then we'd need to understand why I think.
I was trying to understand if you would have an instance of Background Service (BS) running on the APPS Server (against it's own local TPS) AND also copy of BS on the KB Server (again against it's own local TPS). The answer I'm hearing is ONLY 1 BS instance and put on the KB Server.
The BS on the KB Server will do the Knowledge builds AND all of the other stuff that the BS does; escalations, reminders etc or whatever else it does these days.
Add into the mix that console users will point at the TPS on the WEB server to process their FreeTextSearches (background searching) etc. These TPS talk directly to the KB Server files? How should we scale this up if background searching performance becomes an issue?