A TM1 Dream Machine

[John Hammond]

I have been charged with spec'ing a TM1 Dream Machine for our Live System.

Rather than go into a massive evaluation exercise as suggested by COGNOS as to number of users I would be inclined to go for a machine that couldn't possibly fail and lay out the sponduliks for cheap hardware rather than waste expensive human time.

We shall have about 100 users and a comprehensive overnight schedule.

Here's what I propose.

4 dual core 64 bit processors
32 GB RAM with ability to max out to 64GB
200 GB Raid 1 disks.
W2K3 Server x64
IIS 6

Now in my experience the COGNOS advice to run IIS on a separate machine is not that great. It only makes sense if you only have 2 smaller machines available because the communication overhead is so much more expensive when compared with a bequeath connection.

Windows gets my vote over UNIX since although it is more stable there seem to be more limitations than W2K3 as to what you can do.

IIS would get the vote for supportability over Tomcat but I have a feeling that Servlet offers more performance than CGI. We use a product called WebFOCUS and the Servlet performance spanks the CGI.

64 bit has been chosed because it is an unlimited architecture. In practice our servers are living for 5 years or more so we would like to be able to keep pumping in RAM as the need arises.

There no longer is the limit imposed by chip speed since machines these days gain their speed through multi tasking and multi cores so the top end becomes less expensive because it is less dependent on a lucky chip coming out of the die.

Certainly there is no excuse for letting hw take the slack for poor programming practices but if you've got it you might as well use it...

We have our IT outsourced and so in practice the limit may be the outsourcing levy that is charged for a larger machine. But I want to start high and get bartered down

Certainly having a single machine should should cut overheads. What do other forum members think they would do with hindsight given a blank slate.

Thank you.

[aaronxramirez]

Only one caution going to the 64 bit platform, that we overlooked in our upgrade...if you have some old odbc datasources that use special drivers, you better make sure your vendor supplies a 64 bit compatible driver!

[lotsaram]

I couldn't resist.

If you're talking of a dream machine then the main things are lots-of-ram and fast CPUs.

I think you have had some questionable advice in terms of running the web server on a separate box. If you have a honking great 64 bit machine this isn't necessary. In days of yore with 32 bit IIS there certainly were limitations on how many users a web server could support under heavy usage so splitting app server and webserver and having multiple web servers made sense. However now with 64 bit IIS support web is far more scalable. Also you can run multiple instances of tm1 web on the same box with different IP addresses and load balance all on the one physical box. The only advantage I can see to running a separate web server is in terms of making the system more failover proof. If you have 8 CPUs that should be enough to support several hundred users using the app server and web server(s) and makes better use of your hardware (and is easier to install/maintain, and requires less hardware overall.)

My biggest concern for you would be that you have stated your IT is outsourced. These days if it's outsourced someone is going to insist on virtualisation, but if you are talking 32 or 64 Gb of RAM that's just not going to be possible with VM software. A database that is 100% RAM based and won't tolerate swapping of memory resources won't be understood by your outsourcers so be prepared to do battle on this front. Also in an outsourced environment make sure that the TM1 developers will actually have sufficient access to the server to do their jobs.

In terms of sizing, Applix did have some docos on their "TM1 Recommended Practices" site (... don't know where this resides at IBM if at all) which suggested allowing for 10 - 20 bytes per populated numeric cell and 1 - 8 bytes per fed cell. The reason it's a (wide) range is that dimension order optimization can have a very large effect on cube size (and calculation/performance). My understanding is that in an x64 system these storage estimates would be doubled. To match "populated cube cells" to the origin of the data, each numeric cell will probably equate to a record in an SQL table or query.

My feeling is that the old rule of thumb of making sure to have 20% spare RAM buffer from the TM1 server loading to available capacity no longer applies and needs to be updated. My experience is that if active forms are being heavily used then the memory used in 9.4 for stored views and calculated values is significantly more than in older versions. I have seen plenty of instances where after a couple of days TM1 is using double the memory used initially from loading the model without loading additional data.

The last point might be a little off topic but the take out is be comfortable with having a server that appears to be overspec for the initial build. You need to allow for a comfortable buffer, and TM1 applications have a way of expanding their reach to new business areas over time (and therefore requiring more RAM) which is quite unlike any other product you will see.

[John Hammond]

aaron: Thanks for the advice - we currently access sql server and oracle systems so hopefully 64 bit should not be a problem there although there might be older stuff that is still in access though I would not expect problems there.

Lotsaram:

Thank you very much for confirming my thoughts about having the webserver on a different machine as being old hat.

Regarding the point you made about outsourcing and virtualisation: currently we buy our own boxes but the idea the outsourcer has is to move all this to their server farm which is based on vm-ware. I assume the great benefit for the outsourcer is that they can replace several boxes with a single more modern server with multiple vms. Of course our fears are that address translation is not free and seems to add 2-3x overhead opposed to running on raw metal. Add to that the comms to the server farm (not on the LAN anymore) and there will be issues with normal applications let alone TM1.

Certainly with you advice I shall have to put my foot down on this one.

Just to see what was on offer I got a quote off Dell website for all this in a Poweredge rack mount server for £9.5 k. It seems that 2* quad core is the preferred way rather than 4 * dual core. 32gb of RAM is much cheaper than 64Gb but you have to move it to another machine if you then want to upgrade because of the size of the DIMMs.

I am off now to find out what Microsoft 'cals' actually mean. I have been told its a forlorn task!

Processor:
2 * Intel® Xeon® X5570, 2.93Ghz, 8MB Cache, 6.40 GT/s QPI, Turbo, HT quad core
Memory:
64GB Memory for 2CPU (8x8GB Dual Rank RDIMMs) 1066MHz
Windows Server® 2008, Standard x64 Edition,Incl Hyper-V™,Includes 5 CALs English
Raid Connectivity:
C4 Cabled - RAID 1 with PERC 6/i, 2 SAS/SATA Cabled HDDs
Hard Drive - Multiquantity:
2 * 160GB, SATA, 3.5-inch, 7.2K RPM Hard Drive (Cabled)

[David Usherwood]

John, before you go forward _get_ and _test_ the 64 bit drivers for your data sources. I read elsewhere in the forum that the AXNET 'shim' to make 32 bit drivers work with 64 bit servers doesn't work with 9.4. Yes, there are good 64 bit drivers for _major_ databases. But I would validate them first. I have used both (the AXNET shim and full on 64 bit drivers) but I wouldn't know what to do if they don't work.

You haven't (I think) said what version of TM1 you will be using. If you are pre 9.1 (and if I were you I would be) then I wouldn't overdose on cores. TM1 really doesn't do a lot with multithreading. Throw the budget at RAM and CPU speed.

[dubs]

David,

John has mentioned that he is using Oracle and SQL Server- surely, given their market share, these would have been the first drivers tested.

does anyone have any experience using these drivers with a 64-bit server?

cheers

[George Regateiro]

We have been using 64 bit oracle drivers for a few years without any issues. There have been some users having installation and configuration issues for 64 bit oracle (check other posts in the forum).

Where we did end up in trouble was with the smaller vendors who did not offer 64 bit drivers. Our solution was to write small .net applications to dump the data into Oracle first and then read into TM1. As mentioned in the earlier posting if you are using a version not supporting axnet then the intermediate oracle staging might be a requirement to get around the lack of 64 bit drivers, but this then creates a whole new layer of complexity and time to the project.

I would at least to the time to conact the vendors that you think TM1 might connect to in the future. You might think that the possiblity is remote now, but with user adoption the chances of accessing the smaller data sources grows and as i learned the hard way not all software vendors are embracing 64 bit so without research you might be painting yourself into a corner.