migration DR550 to new hardware

[Michel de Kraker]

Hi All,

Current CMOD hardware running in a DR550 is almost 6 years old. Time to migrate to a new system.
DR550 has an object server and library server in a different LPAR in the same POWER5 server.
We are migrating to POWER7. This POWER7 server is not dedicated for these 2 CMOD lpars, so other lpars are also in that same P7 server. The luns for the object server will come from IBM V7000 instead of the DS4300 which is part of DR550.

DR550 is an IBM specific Feature. When we are moving to POWER7 the DR550 concept is lost.
Can i get into issues regarding IBM Support when we choose for the NON-DR550 solution? Are there other disadvantages with the new setup?

Thx for your input.

Kind regards,

Michel.

[Justin Derrick]

You should be able to get all of the functionality of SSAM (System Storage Archive Manager aka TSM) by restoring the database backup into a newer version of TSM.

The only thing I suspect is different is the firmware tweaks on the DS4300 that prevent removal of data -- your new storage technology might have an equivalent feature though.

Let us know how it goes!

-JD.

[Michel de Kraker]

thx JD.

So the fact that i am moving from a official IBM product (DR550) to a non-DR550 environment (seen from a hardware point) should be no problem?

Or was DR550 just a marketing name? (my opinion)

[demaya]

Very interesting... keep us up to date!

[Justin Derrick]

thx JD.

So the fact that i am moving from a official IBM product (DR550) to a non-DR550 environment (seen from a hardware point) should be no problem?

Or was DR550 just a marketing name? (my opinion)

Pretty much.  The DR550 was simply a box with what was (at the time) some newly added features...  AIX (locked down), TSM (with 'Archive Retention Protection' enabled), and the DS4300 (with a feature to prevent deletion of storage by admins).  You can build your own similar system by using these (now common) features in widely-available software.

Good luck!

[Michel de Kraker]

@JD, library server and object server were on 2 different lpars. What is your opinion and experience about putting the library (db2)and object (tsm) server on the same lpar?

[Justin Derrick]

I prefer to have both pieces of the server in the same LPAR.  With the newer versions of TSM, you'll need to bump up the RAM -- the memory requirements of TSM 6.x are dramatically higher than TSM 5.x.

[Michel de Kraker]

Thx Justin.

[Alessandro Perucchi]

Just for your information, and for people reading this thread in the future.

It is possible to have TSM and CMOD on the same server/LPAR, but you cannot have both of them in the same server if your server is running Windows.
Apparently this is a limitation with the new TSM V6.X on Windows environment. At least that's what my TSM guru colleagues told me.
In Unix there is no problem.

Concerning the bump of ressources that TSM V6.X needs, you can tell him to reduce a bit it's need of memory, otherwise it will take 100% of the RAM you might have, if he really needs it.
In order to reduce the RAM usage of TSM, you can tune it with the option DBMEMPERCENT.

And for my information Michel, when you said that the object server was running in the DR550, you mean that the documents themselves are/were stored in the DR550, and not that the CMOD daemon arsobjd was running in the DR550?
Because for me, you have always 3 components with CMOD:

• Library Server
• Object Server
• Object Storage Server (or something like that :-D)

On the Library Server, you have the daemon arssockd that runs.
If you separate the Object Server and the library server, then the object server will need to run arsobjd
The part that I call "Object Storage Server" is your cache, if you don't have TSM, or simply TSM.

So if you had only 1 Library Server, and one Object Storage Server... then there is no problem in your migration strategy, you can combine them without any problems.

Now if you have a Library Server AND a Object Server AND an Object Storage Server in different LPAR/servers, then to merge the Library Server and the Object Server could be a problem, well no a big problem, but you need to be careful with the cache merging of both library and object servers. The Object Storage Server won't be a problem at all.

From what I read until now in this thread, you have only 2 LPARs that needs to be migrated into 1 a library server and a TSM server (object storage server in my own words :-)) but no real CMOD Object Server... so you should have absolutely no problem with that migration.

Sincerely yours,
Alessandro

[Michel de Kraker]

Hi Alessandro

thx for your answer.

just to be sure after reading your comments

i have 1 lpar running db2 and arssockd (so a library server, which also holds the cache filesystem)
I have 1 lpar running TSM (so a object storage server)

Nowhere i have a arsobj daemon running

so i should be able to put the db2 and tsm on one lpar.

Thx.

Kind regards,

Michel.

[Justin Derrick]

Hi Michael.

An object server is different than TSM.  Back in the day, when dedicated leased lines were slow (and expensive), the architecture of CMOD allowed for multiple 'object servers' to be geographically diverse, without having to send gigs of data over slow connections -- instead, the data was loaded into a 'local' object server with it's own cache and optionally TSM storage, and index data was sent over the wire to the library server.

Today, that doesn't make much sense, given that network connectivity is exceptionally fast, and relatively affordable.

So, your standalone TSM server doesn't really count as an 'object server' in the CMOD definition, even though it's a server filled with objects. 

-JD.

[Michel de Kraker]

thx JD for the clarification.

Regards,

Michel.