TM1 Architecture

[tm1expert-not]

Hey Folks -
My questions revolve around setting up a new TM1 setup. We have a Data Ware house in place ontop of a legacy ERP. When developing TM1, would it be easier to go against the ERP (which someday might be replaced) or against the Data Warehouse?

When installing TM1 on a multi-server setup, how would you split up the server setup? Is it similar to BI where you have a dispatcher and content store/ content manager? Which application should the more powerful server be allocated too?

Please advise!

[Alan Kirk]

My questions revolve around setting up a new TM1 setup. We have a Data Ware house in place ontop of a legacy ERP. When developing TM1, would it be easier to go against the ERP (which someday might be replaced) or against the Data Warehouse?

Doesn't really matter; you're looking at it the wrong way around.

First you determine what data you need in the TM1 system to meet your business needs.

Then you work out where you can get it from.

If the current answer to that question is the ERP, that's where you get it from. If that's subsequently replaced then there would need to be some form of transition to replace that data source with another one, but you'd face that issue with or without TM1 anyway. TM1 and its ETL tool TurboIntegrator are both very flexible, and changing from one data source to another isn't technically very difficult once you have a handle on them; getting equivalent data fields from the new source can be more of a challenge, however. Always think about your content needs, then work backwards.

When installing TM1 on a multi-server setup, how would you split up the server setup? Is it similar to BI where you have a dispatcher and content store/ content manager? Which application should the more powerful server be allocated too?

I strongly suggest that you look at the TM1 Operations Guide which gives an overview of TM1 system architecture.

Each TM1 server session (the program that stores, calculates and serves up the data) can reside on only one physical server. (With the proviso that if you're running TM1 Web, for instance, the Web server can be on a different physical box, and with the other provisio about running multiple servers that I'll come back to below.) "The more powerful server" is a problematic expression, as it doesn't address... more powerful how? The answer will depend on a range of questions such as how much of the data model will be calculated by rules vs how much is served up as straight, uncalculated, loaded data. If you have a heavily rule-dependent model then you'll want a fairly fast processor. However TM1 still doesn't make huge use of parallel processing (paging Dr. Usherwood, Dr. Usherwood to this thread, please) so if you have a processor with a ginormous number of cores you're probably throwing money away as opposed to a processor which has fewer but faster cores.

RAM is undoubtedly the biggest limiting factor, though, since TM1 operates almost entirely in memory. I say "almost" because obviously it loads data from disk when it starts, and stores the data back to disk when it shuts down or you tell it to. If you have a very large model that can be a serious performance bottleneck if you have to do data saves during working hours, so fast disks aren't wasted. The more RAM you can throw at TM1, the happier it will be and the more scope you have for expanding its use... provided that you're running on 64 bit and are not constrained by low application memory limitations. (As an aside, be aware that under 64 bit your licence costs are likely to increase as you go for a server with more cores. No, I have no idea why. No, I can't see the justification for it either. But again, it's a reason why you need to be careful about which "more powerful" you're talking about.)

Another option in some models is to split the cubes up between different server sessions, in which case you can have each session running on a different box and spread the load that way. The down side is that the sessions won't communicate with each other very well (they can, after a fashion, but there are limitations that I won't go into here) which means that the data stored on each server session should probably be fairly independent. Also users would need to log in to multiple sessions, though that's less of an issue if you go down the integrated login path. Finally, and very importantly, you would need to be very certain that your licence agreement lets you do that. Not all of them do, and if yours doesn't it's not worth the aggravation if you are audited by IBM.

[lotsaram]

With TM1 you need to get out of the middset of separate servers for content store, dispatcher, database, etc. The only component that you can split out with TM1 is the web server(s). TM1 is more of an integrated "all on 1 box" slution and therefore much simpler to install and set up. It is possible to split out multiple separate TM1 servers or "application instances" on the one physical server, and in the past this was also often the best way to handle performance tuning - but as Alan has pointed out there can be licensing issues with this design as some licensig models have a per application instance structure. However with 9.5.2 this kind of setup should be less necessary for performance reasons (but there may still be other valid considerations for splitting over distinct application instances.)

I'm looking forward to getting 9.5.2 installed on a test environment in the next week or 2 for a good testing, however in theory 9.5.2 should finally address that issue of TM1 making better use of the available processing power of multi-core servers and finally being able to handle "multi-threaded calculation" (at least in terms of distinct calculation requests from unique user threads as opposed to parellization of of a distinct calculation thread to improve performance response time for calculations.)

[Alan Kirk]

I'm looking forward to getting 9.5.2 installed on a test environment in the next week or 2 for a good testing, however in theory 9.5.2 should finally address that issue of TM1 making better use of the available processing power of multi-core servers and finally being able to handle "multi-threaded calculation" (at least in terms of distinct calculation requests from unique user threads as opposed to parellization of of a distinct calculation thread to improve performance response time for calculations.)

I'll be interested to hear how your tests go. (Unfortunately I don't have a spare server to test 9.5.2 on and it's all but impossible to test this kind of thing on a stand alone machine.) I'm still regarding this improvement as being "in theory" until or unless I see enough people experiencing genuine improvements in performance out there in the field.

[David Usherwood]

See
http://www.tm1forum.com/viewtopic.php?f=3&t=5147#p22026
Focusing on a massive, calculation intensive model, PI isn't helping. I can believe (and hope) that for multiuser planning apps, and/or for loading from external sources, it could be better - but I'm too busy to test further at present.

[David Usherwood]

The PI issue is with IBM for testing - it took an extreme amount of time negotiating an NDA which the client wanted.

[gmellor]

It is possible to split out multiple separate TM1 servers or "application instances" on the one physical server, and in the past this was also often the best way to handle performance tuning - but as Alan has pointed out there can be licensing issues with this design as some licensig models have a per application instance structure. However with 9.5.2 this kind of setup should be less necessary for performance reasons (but there may still be other valid considerations for splitting over distinct application instances.)

We have been advised against having multiple applications on one server. Is there any valid reasons for not combining? We want to have one 22Gb Rule focussed App for HQ and one 21Gb Process focussed App for a region on one server (with 60Gb RAM and 4 6-Core processors) to save on licensing & server costs.

[David Usherwood]

Advised by whom?

[tomok]

We have been advised against having multiple applications on one server. Is there any valid reasons for not combining? We want to have one 22Gb Rule focussed App for HQ and one 21Gb Process focussed App for a region on one server (with 60Gb RAM and 4 6-Core processors) to save on licensing & server costs.

It all depends on available resources. When you say 22GB and 21GB, at what point is that measured? Is it 22 and 21 upon initial load, or after regular use? If you have 64GB and are using 43GB upon initial load then you are not leaving much room, percentage-wise, for growth in the model(s). As a general rule I advise people to not have models with an initial load, especially if it has a lot of rules, that exceeds more than 50% of the available RAM. Better safe than sorry in my view, especially since RAM is so cheap compared to the problems caused by running out of it.