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; } } }

multiple sites

Adam Stoller

Environment[indent]TS/OD/LSDS/LSCS 7.2.1 on Linux - with WebSphere (application clustering)[/indent]Preamble[indent]I've read through a few forum postings, and Appendix E of the SP Dev manual, but I don't think I've seen the specific question for which I'm seeking an answer / some advice.
Feel free to point me to a specific thread or manual / section[/indent]Issue at hand[indent]We will be implementing multiple sites (each on distinct branches within TeamSite) that will be deployed to the same set of servers (web and app), and we're trying to determine the best strategy (or at least itemize pros and cons).
There will probably be some sharing of resources (images, css, etc.) but the content will be distinct. The front-end application code may or may not be the same (e.g. the content for one site doesn't utilize all the available features, but we're not sure if we want / need to have a completely separate code-base for the app)

Find more posts tagged with

Comments

Rick Poulin

Perhaps to put it another way: Should we try to use the same JVM for multiple sites or distinct JVMs for each site?
I believe that the former is "easier" in terms of setup, but the latter is the way we're leaning as it would seem cleaner and less likely to cause issues of scalability and such (granted, there may be licenses involved for the app server, but that's a separate issue)

Yep, those are pretty much your options and you've kinda pointed out all the pros + cons already.. but to reiterate:
Single LSDS = easier to manage a common template / look+feel; easier to configure
Multiple LSDS = better scalability, silo'd server resources for each site

Either way works.. just realize that separate instances will either require different web context roots, or different ports, so your apache conf gets a bit more interesting.

Assuming we go with distinct JVMs (which would be akin to #2 above) - what various configuration files do we need to augment on both the source side (including OD) and target side (LSCS, LSDS)?

Short list includes but is likely not limited to

new deployment nodes in customer-teamsite-resource-config.xml so you can alter the opendeploy.webroot target path
plc workflow update to pick the right node for each branch. alternately, using the ootb mechanism in default.site for specifying the target and letting the plc auto-match on that (very clunky IMHO)
branch mappings in lscs-authoring.xml if you want different branches to go to different LSCS instances
optionally, odnodes.xml and OpenDeployWebRoot.xml for using replicationfarms instead of single node targets

Am I correct that we can utilize a single LSCS [DB] for all the sites? and that we just need distinct LSDS instances?

You can. You could also set up distinct instances of LSCS as well, depending on how much content you're planning to serve through it. FYI: You can configure multiple instances of LSCS (the webapp) to talk to the same DB+IDOL instances for the purposes of content rendering, so long as you only use one instance to do the content writes (deployments).

Bowker

We had the same questions and have gone with the single instance of LSDS for all sites.

1 - our sites are not in the 1,000,000 hits per day category so scaling at that level was not necessary.
2 - way easier to manage on the production runtime world.

Challenges/solutions
1 - each site has it's own folder for includes/images/...
for example:
workarea/development/common/incs
workarea/development/common/images
workarea/development/common/docs
workarea/development/site-a/incs
workarea/development/site-a/images
workarea/development/site-a/docs
workarea/development/site-b/incs
workarea/development/site-b/images
workarea/development/site-b/docs
2 - xsl files included by components are divided as
workarea/development/xsl/common
workarea/development/xsl/site-a
workarea/development/xsl/site-b

Another option which we also employed was to setup multiple web-server front-ends to forward specific types of pages to LiveSite while serving others locally. Each of the web servers has a unique docroot which allows for some level of scaling and separation of "livesite page construction" from "simple static content requests".

We also have multiple LSDS servers pointing to the same database without any issues.

Adam Stoller

rpoulin, bowker - thanks for the input.

I spoke to one of the folks here today and based on that conversation we're now learning more towards option #1 (different sub-dirs under a common root folder) - but we still have to take it up with the IT folks and see how they feel about it.

At this point, I don't believe this is a super-heavily hit site and while I expect that there will be more sites coming - I think it's more on the order of ~ 10 sites, not 100's or 1000's, so while scalability is important - massive scalability is not [currently, to the best of my knowledge].

Thanks again.

I'll leave the thread open for a few more days in case there's more that either of you (or anyone else) want to chime in here.

jasonmcneil

Just to add from a scaling perspective, even if you do place multiple sites within the same LSDS instance (in sub-folders), if traffic increases beyond expectations, I would say that it is still likely simpler to add multiple, ~identical LSDS server instances with load balancing in front of them, all of which have the ability to serve content for any/all sites.

Just simpler to manage multiple copies of a single configuration (especially by leveraging fan-out deployments), than managing multiple configurations/content across multiple servers.

Adam Stoller

Just to add from a scaling perspective, even if you do place multiple sites within the same LSDS instance (in sub-folders), if traffic increases beyond expectations, I would say that it is still likely simpler to add multiple, ~identical LSDS server instances with load balancing in front of them, all of which have the ability to serve content for any/all sites.

Just simpler to manage multiple copies of a single configuration (especially by leveraging fan-out deployments), than managing multiple configurations/content across multiple servers.

Do multiple LSDS instances equate to multiple WebSphere instances? Or are you talking about having multiple LSDS instances within a single WebSphere instance?

(I was assuming the former, but I figured it is better to get verification, especially given my recent run with assumptions... ;-)

Rick Poulin

Do multiple LSDS instances equate to multiple WebSphere instances? Or are you talking about having multiple LSDS instances within a single WebSphere instance?

Both are valid, but the benefits of the latter are really 1) isolating the JVMs and 2) clearly distinguishing the webroots, to avoid deployments overwriting files that also exist in other branches. When you're looking for performance, only the former (multiple websphere instances on disparate servers) makes any sense for scalability.

nipper

Both are valid, but the benefits of the latter are really 1) isolating the JVMs .

Isolating the JVM is a big plus. A customer of mine has been having serious issues (731 LSDS on Linux/Tomcat), when a DCR was mistakenly JVM CPU went to 100% and brought down LSDS

jasonmcneil

The other added benefit is that with another instance of WebSphere, presumably on a different physical (or virtual) server, you're adding more available resources (memory, CPU, etc.) with each instance.

When dealing with high traffic, you can only squeeze so much out of a given set of resources on a single server, adding additional servers allows you to farm out the load.

Adam Stoller

Slowly but surely (I hope) I'm starting to get a grip on the architecture and its associated terminology.

While the points you make sound (and probably are) very valid, the powers-that-be here are planning to move forward with an approach like this ... on a per-server basis (there are multiple servers per environment):

One of the advantages of this, if I'm understanding all of it (a big if) is that, should resources become limited on the individual server, they have the option of moving the complete JVM to another server - and thus moving to something more like what I believe you are suggesting - yes?Granted, that may prove expensive if it comes to pass (additional hardware, and licenses) - but at this point - with only two sites in the very near-term and only a couple more in the current pipeline, they feel reasonably comfortable with each server in the cluster running multiple JVMs (each dedicated to an individual site).If you see something fundamentally flawed in the above, please let me know (in as much detail as you can - because I'll have to try to pass it along).Thanks for all your assistance.If I ever manage to get the fan-out stuff working I'll be able to really start making progress on all of this....

Adam Stoller

Additional question(s) based on this setup that we're trying to get done.

If we have each branch / site deployed to a distinct JVM / LSDS:

for the entire environment (zzz) - so does the fact that we're using a single database server negate the above paragraph or ...If there's a better part of this or one of the other manuals - or a reasonably well written KB article that you know about - please feel free to point me in those directions.

Rick Poulin

If a single app goes down, it should only affect a single site, all other sites should remain active. There's a slight issue here with respect to LSCS - but that's being considered as a local custom development issue for their business logic app

The proposed setup sounds fine to me. One note on the above point, I'd suggest considering installing LSCS on a server separate from the Websphere one. Otherwise, if your whole server is slowing down, moving the JVM to another instance isn't going to help speed up LSCS again, and that could potentially become a bottleneck.

[QUOTE]If we have each branch / site deployed to a distinct JVM / LSDS:

going to have schemas for LSDS, then the next question is whether your front-end is going to be writing back to the DB, or if information is only written by your deployment process. If the answer is "deployment writes only" then you can have as many DBs as you want and all LSDS instances will see the same information regardless of which DB they connect to. If the runtime is writing back to the DB, then you'll want some way to sync the DB instances, using DataGuard or similar.-- LSCS --I don't think iwov has a good answer for how to scale this yet, but in theory the optimal model is this: for each *idol* instance, have a corresponding DB instance. Now, regardless of how many LSCS web applications you have, you connect them to your IDOL farm via DAH/DIH connectors, and you connect them to your DB farm via DataGuard or similar. The low-cost version is having multiple LSCS webapp instances all connecting to a single IDOL and a single DB -- just make sure your deployments always write to the same webapp to avoid write synchronization problems (you could even potentially have one webapp instance dedicated to ingesting content only, and have the others only support 'read' operations on behalf of your LSDS instances).'Tying this back to my initial point, you could potentially host only IDOL on a separate server (and the DB, obv.) and then have one LSCS webapp instance for each LSDS instance, which would be equally portable in Websphere.

Adam Stoller

The proposed setup sounds fine to me. One note on the above point, I'd suggest considering installing LSCS on a server separate from the Websphere one. Otherwise, if your whole server is slowing down, moving the JVM to another instance isn't going to help speed up LSCS again, and that could potentially become a bottleneck.

Interesting point, I'll pass it along, though this would mean an additional server / OD license per environment (unless we try to use a single LSCS instance for multiple environments - which they might do for pre-PROD environments...)

-- LSDS --
[...]First, you don't need schemas for LSDS at all unless you're using OOTB database-driven components and/or user login. [...]. If you are going to have schemas for LSDS, then the next question is whether your front-end is going to be writing back to the DB, or if information is only written by your deployment process. If the answer is "deployment writes only" then you can have as many DBs as you want and all LSDS instances will see the same information regardless of which DB they connect to. If the runtime is writing back to the DB, then you'll want some way to sync the DB instances, using DataGuard or similar.

They are using logins for one of the two sites involved in the current plan. I don't know if there is any writing back to the DB - but I have a feeling any write-backs will be to a different DB system rather than what's used for LSDS.

-- LSCS --
I don't think iwov has a good answer for how to scale this yet, but in theory the optimal model is this: for each *idol* instance, have a corresponding DB instance. Now, regardless of how many LSCS web applications you have, you connect them to your IDOL farm via DAH/DIH connectors, and you connect them to your DB farm via DataGuard or similar. The low-cost version is having multiple LSCS webapp instances all connecting to a single IDOL and a single DB -- just make sure your deployments always write to the same webapp to avoid write synchronization problems (you could even potentially have one webapp instance dedicated to ingesting content only, and have the others only support 'read' operations on behalf of your LSDS instances).'

Hmm, interesting. I'll pass this along too and see if they want to adjust any of the design based on this or stick to the 1 LSCS / 1 DB / 1 Environment model that already planned.

Tying this back to my initial point, you could potentially host only IDOL on a separate server (and the DB, obv.) and then have one LSCS webapp instance for each LSDS instance, which would be equally portable in Websphere.

Hmm - that might work better, since the TS/LS IDOL instance doesn't require a separate license (right?) and certainly wouldn't require an OpenDeploy Receiver... As with the other ideas - I'll pass them along.

Thanks much for the clear descriptions.

Adam Stoller

FWIW - the architecture that we're attempting to go with looks like

I renamed some things but basically:

)

nipper

Often the F5 will also load balance the app servers, you do not mention that.

Adam Stoller

Often the F5 will also load balance the app servers, you do not mention that.

Sorry - yes, F5 load-balances both Web and App servers.
Updated diagram.

GRD

Interesting point, I'll pass it along, though this would mean an additional server / OD license per environment (unless we try to use a single LSCS instance for multiple environments - which they might do for pre-PROD environments...)

+1 on a separate JVM and server for LSCS instances. Poorly written LSCS queries, lack of proper indexing, uncached components to deliver personalized content, database connection latency, or just traffic spikes are all factors that can quickly overwhelm a LSCS box, and subsequently your site. Seriously, Ghoti, I recommend at least two (2) production LSCS instances with separate database instances, unless you want to take your site(s) down for upgrades, JVM restarts, adding an additional LSCS node, and other unforeseen problems.

They are using logins for one of the two sites involved in the current plan. I don't know if there is any writing back to the DB - but I have a feeling any write-backs will be to a different DB system rather than what's used for LSDS.

Are you planning to use the OOTB login and user management functionality? Keep in mind that user management screens within TeamSite are not extensible. Autonomy states they are a reference implementation only.

Tying this back to my initial point, you could potentially host only IDOL on a separate server (and the DB, obv.) and then have one LSCS webapp instance for each LSDS instance, which would be equally portable in Websphere.

Like you, I'm waiting to see a documented solution from Autonomy for this. But honestly, it sounds like a single point of failure to me.

-Greg

Adam Stoller

+1 on a separate JVM and server for LSCS instances. Poorly written LSCS queries, lack of proper indexing, uncached components to deliver personalized content, database connection latency, or just traffic spikes are all factors that can quickly overwhelm a LSCS box, and subsequently your site. Seriously, Ghoti, I recommend at least two (2) production LSCS instances with separate database instances, unless you want to take your site(s) down for upgrades, JVM restarts, adding an additional LSCS node, and other unforeseen problems.

Well, with the clustering of app servers and a distinct LSCS instance on each of the app servers, I'm hoping this doesn't become an issue. Time will ultimately tell, though hopefully I'll be on a different project if/when that occurs. (I like the folks, I just don't like sticking around on one project for extended periods of time)

Are you planning to use the OOTB login and user management functionality? Keep in mind that user management screens within TeamSite are not extensible. Autonomy states they are a reference implementation only.

I believe they have their own site authentication functionality (inside BIZ). There's no DataDeploy involved in this project, no LSDS schemas - just LSCS)

Like you, I'm waiting to see a documented solution from Autonomy for this. But honestly, it sounds like a single point of failure to me.

As nipper has pointed out (in a different thread) - you might have a better chance of winning the lottery :-)