nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Best practices for multiple content stores

lhdavis

I have a client who is in the initial phase of a TeamSite rollout (currently on W2K 6.0 but planning on upgrading to 6.1 in next quarter) so they are currently using one content store and supporting 4-6 separate sites in the one store. Long term they will be looking to support a number of sites, in the range of 500 to 1000, and we are evaluating what best practices there are for managing multiple content stores.

From reading the Admin Guide (and realzing that the documentation is not always the most accurate), I understand that on any one TeamSite server, the maximum number of content stores that can be active at one time is 8. My current experience level has been on projects with initial rollouts and supporting smaller sites, not large implementations, so I do not have a ton of experience yet with the multiple content store concept (I keep typing backing store and having to correct myself with the "new" name).

As I mentioned previously, we are currently on a W2K server with 2 CPUs and looking to see how we should proceed with either:
a) purchasing more CPU's for the existing box (realizing there is a finite amount of space available for adding CPUs)
b) purchasing an additional box to serve as a SAN or placeholder for the additional backing stores and attempting to map the content store on the TeamSite server even though it physically exists on another box (not sure if this is a supported or accepted practice - most documentation says content store must reside locally on TeamSite server)
c) purchasing another TeamSite server altogether
d) or any other recommendations you might have

Ideally we would like to have the option to make the most out of the existing TeamSite server we do have and support it in a sinlge location, if we need to, add servers as necessary. So I was wondering how large implementations have managed sites in the 500 to 1000 range from a TeamSite server/content store perspective.

Also what best practices exist for supporting this number of sites. Has anyone done it yet?

Any and all information is much appreciated. Thanks!

- Luke

Luke Davis
Open Technology Group, Inc.
luke.davis@med.va.gov

Find more posts tagged with

Comments

Adam Stoller

I have not had to work in the scenario you present, but do want to point out that multiple stores is also a purchase item (the functionality is built-in, but to use it - legally - you have to purchase a "license" for each store).

I believe that although 8 stores is all that is officially supported, some of the Interwoven Engineers indicated that it could actually do more -- however, I'm not sure I'd want to try and exceed the maximum officially supported number for a production system.

That being said, I believe that you will probably want a combination of multiple servers with multiple stores each - to help breakup the large number of sites you're planning to support. You might also be able to make use of top-level sub-branching to reduce the overall expense and avoid having to purchase a server/store for each individual site (not knowing the details behind the various sites you're looking to support it makes it difficult to provide ideas here - but say you had 5 sites that were similar in terms of their general usage or audience or something - you might be able to divide those into sub-branches rather than stores)

Also - remember that there are different licences for different numbers of CPU's - so while increasing the number of CPUs on the server hardware is generally a good idea - you also need to figure that into your expenses.

Using network storage devices (like NetApps) - with suitable RAID settings - for the backing store(s) is supported [Interwoven does it, as do a number of their customers] - and is probably a very good way to go for a number of reasons (there have been various threads in the forums about this - you can probably find them if you search).

I believe Interwoven offers architectural consulting services these days - you might want to investigate bringing in someone from Interwoven to help scope out / plan the architectural layout for the system(s).

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

lhdavis

Thanks ghoti for the first response (as usual you are the "go-to" guy..."go-to" ghoti maybe?).

We do realize that there are licensing fees involved for each additional store as well as additional CPUs and that we will have to purchase them from Interwoven (not available on eBay just yet).

And the approach you listed (top-level subbranching for similar groups of users and/or content) is what we are going to be implementing. Sorry I didn't include that level of detail but for example, if the overall organization were DIsney, we would probably invest in separate content stores for ABC and ESPN but subbranches for ESPN, ESPN2, and ESPNNews.

I did search the forums for information on network devices but may not have used the correct keywords (not too experienced with network/clustering architecture). I will search again through the forums but if folks could post a reply to this discussion with the links to those threads that would help.

Just trying to get a feel for how people have done this in the past before we go back to Interwoven with questions. Plus there's always a difference between what Sales/Marketing might say and what Engineers will say Smiley Happy

Luke Davis
Open Technology Group, Inc.
luke.davis@med.va.gov