8 replies to this topic

[kyfbof]

Hi there,

We are running DU 5.5 on hpux 11.11. I'm seeking for a procedure to migrate some apps fr ServerA (MU=U_SERVERA) to ServerB (MU=U_SERVERB).

On ServerA, I'm thinking of assign my apps to different MUs, and for certain MU I will just reassign it fr ServerA to ServerB.

Is my method sound, feasible and complete?

Thanks in advance!

[men]

Hi and welcome,

Can you elaborate on what you mean by "to migrate some apps"? Are you talking Uprocs, Sessions, Tasks belonging to the same Domain/Application in DU?

Michel

[kyfbof]

men, on January 21 2010, 03:01 AM, said:

Hi and welcome,

Can you elaborate on what you mean by "to migrate some apps"? Are you talking Uprocs, Sessions, Tasks belonging to the same Domain/Application in DU?

Michel

ServerA hosts 57 dbases, 2 web services, and ... Say, I want to move 20 dbases fr ServerA to ServerB. With SAN disk technology, we'll just need to shut those dbases down on ServerA, go to ServerB and start them up ... 5min outage. What would be the process to make $U running uproc, sess, tasks, calandar, ... that used to run on ServerA

[couak]

kyfbof, on January 21 2010, 05:49 PM, said:

ServerA hosts 57 dbases, 2 web services, and ... Say, I want to move 20 dbases fr ServerA to ServerB. With SAN disk technology, we'll just need to shut those dbases down on ServerA, go to ServerB and start them up ... 5min outage. What would be the process to make $U running uproc, sess, tasks, calandar, ... that used to run on ServerA

SAN is only a storage. I suppose that your applications hosted on nodes (server A, B, C...) are likely configured to run as a standy application or as an application cluster
If you want so with $Universe you'll need to configure the $Universe as a cluster

[kyfbof]

couak, on January 21 2010, 10:23 AM, said:

SAN is only a storage. I suppose that your applications hosted on nodes (server A, B, C...) are likely configured to run as a standy application or as an application cluster
If you want so with $Universe you'll need to configure the $Universe as a cluster

$U in cluster implies that you can run my applications on ServerA or ServerB. No that is not the case. I want to move the applications permanently from ServerA to ServerB. After that, when I want to bring up a dbase, $U would go to ServerB to start it up.

[couak]

Well the migration really depends on how the scheduling was developped. If you're absolutely sure that jobs will run on the server B, then you can stay at your first plan : reassign the MU to the B node.
As I remember you can't just reassign, you need to delete the MU and then recreate it with the new node assignment.

[men]

Hi,

Globally agree with couak.

This depends on how the scheduling was developped, and you should check points like:

Is there a MU defined for each DB?

Are Sessions running for 1 MU/DB or are there designed for various MUs/DBs starting from a unique point?

Are you using HDP?

Etc...

You will need to change the MU location - you can update them through the GUI or in command line - in the MU admin tables on all involved boxes.

You may also have to distribute or import any missing object (Uproc, Resource, Session...) and depending on your Session and Task structure delete and recreate the Tasks.

Michel

[kyfbof]

men, on January 22 2010, 02:50 AM, said:

This depends on how the scheduling was developped, and you should check points like:

Is there a MU defined for each DB?

>> No. Currently everything on that node is running under same MU that describes the node. That's why I think I have to assign new MU to ... perhaps one MU for each DB. Is there any limitation of # MUs per node?

men, on January 22 2010, 02:50 AM, said:

Are Sessions running for 1 MU/DB or are there designed for various MUs/DBs starting from a unique point?

>> The nature of it is that jobs/schedules are very independent from other dbases. I'm leaning to design one MU/DB.

men, on January 22 2010, 02:50 AM, said:

Are you using HDP?

>> I just read up to this. It's very interesting way of making jobs flow. However, my task is probably simple enough to solve with multiple MUs ... flat ... no hierarchy.

men, on January 22 2010, 02:50 AM, said:

You will need to change the MU location - you can update them through the GUI or in command line - in the MU admin tables on all involved boxes.

>> I'd rather use cmd line. Could you give me an example of one?

men, on January 22 2010, 02:50 AM, said:

You may also have to distribute or import any missing object (Uproc, Resource, Session...) and depending on your Session and Task structure delete and recreate the Tasks.

In summary, you think I should do as follows:
1. Leave MU=U_SERVERA alone,
2. On ServerA, create MU=D_DB001 # Of course we'll use something more descriptive than "001"
3. Pick objects that belong to DBASE1 modify them fr MU=U_SERVERA to MU=D_DB001
4. Repeat step 2 and 3 for all other targeted-to-move dbases
5. Export objects where MU=D_*
6. Delete MU=D_* on ServerA # how?
7. Insert the objects on ServerB

Thanks Couak and Michel. Of course, this is just a concept ... the works is the difficult part. I dont know how we can avoid lots of man hours to complete step 3. The good news is my schedule coordinator can take months to if she wants, and the cutover (step 7) would be very simple. And if we later on need to move, the hard works are already done.

[kenny]

Hello,

There is no limitation of # MUs per node. One MU for each DB may be the appropriate answer - but I don't know your IT Operations to be a 100% sure. All these MUs should be of the same MU Type as they all represent a DB.

Quote

I'd rather use cmd line. Could you give me an example of one?

You can use commands like:

uxadd MU MU=... LABEL=... TNODE=... to add a new MU in the MU table
uxdlt MU MU=... to delete an MU from the MU table
uxupd MU MU=... LABEL=... TNODE=... to modify an existing MU in the MU table (like its node or label).

Quote

In summary, you think I should do as follows:
1. Leave MU=U_SERVERA alone,
2. On ServerA, create MU=D_DB001 # Of course we'll use something more descriptive than "001"
3. Pick objects that belong to DBASE1 modify them fr MU=U_SERVERA to MU=D_DB001
4. Repeat step 2 and 3 for all other targeted-to-move dbases
5. Export objects where MU=D_*
6. Delete MU=D_* on ServerA # how?
7. Insert the objects on ServerB

There again, I don't know your IT Operations so it's difficult to be a 100% sure.

Create the MUs which represent the DBs at least on the Node where the DBs are located. Some customers prefer to have these MUs created on all Nodes - they can distribute the Node table to the various nodes to do so. If you are looking for consistency over the Admin tables you should go for it.

Your Uprocs and Sessions may not include anything hard-coded relating to MUs (no mention of a specific MU in the Uproc conditions, no MU mention in the Session): In this case, you don't have to modify them, just distribute/export them to Nodes where the jobs will be running. Otherwise, you'll have to do the updates + deployment.

For Tasks, you 'll have to create, copy or distribute the Tasks to the new target MUs.

Hope this helps,

Kenny