Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Large Cluster MCD4 to MCD 5 Upgarde/Migration

Status
Not open for further replies.

f1fanatic

Programmer
Jan 28, 2008
177
GB
I performed a few smaller migration/upgrades, up to about 12 elements. But i ahve one now we there are 40 odd 3300's in the cluster. My plan is below, comments welcome on the validity of this or anyones experiences.

1.Online upgrade to all 3300's to load MCD SP4 to inactive partitiona nd schedule OOH activation.
2.Second online upgrade, so both partitions are on MCD SP4, and we can run "SWAP" if migration fails for some reason.
3.Enable SDS sharing in cluster, amend sharing scope as required and rectify any issues.
4.Migrate cluster.
5.Individual online upgrades to MCD 5 on the elemnts to bring them up to this, this is my one big concern, and i am going to look into. Is there an issue with running MCD4 and MCD5 in the same SDS/GDM cluster. The reason i am planning this is you can imagine the logostics of arranging forty odd engineers, literally alll over the world to accomplish this in one weekend.



 
The only issue I am aware that you will run into ( other then if there are bugs ) is that you will get sync errors. These errors are in most part that if you are sharing COS forms, then MCD 5 might have an option that MCD 4 doesn't have and therefore you get an error each time the COS forms are synced. Not a big problem but you will get the same error on each sync until all systems are at the same load. So maybe the best plan is that until all the sites are at the same load, then share a minimum of forms. You will get fewer errors.

Note: if you are not currently using SDS then run the migration precheck in maintenance to check for potential problems. Correct those errors before going to SDS.

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.
 
cheers Loopylou, did think i may get SDS issues because of the load differnces. Dont know at the moment to what degree they will share forms. And yes agree run and rectify migration checks before SDS sync is carried out.

Many thanks.
 
Personally, if it were me, I would get them all to the final load before activating SDS.

**********************************************
What's most important is that you realise ... There is no spoon.
 
Isn't it more the RDN element that happens when switching from OpsMan management. From what I recall you can use SDS in a limited fashion in OpsMan deployments to share simple thinks like FAC and COS. In the new structure you need to share user accounts to allow passthru etc.

Anyway with this many elements I would take a hard look about what you really need to share and pare it down to a minimum.

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.
 
Totally agreed Loopy. None of teh are sharing at any level, and they have been installed by different re-sellers over a long period of time by different techs, so even when doing a form comparison wouldnt think any forms would be in sync enough without a lot of work to share all forms. Will strip right down so bare minimum is being shared.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top