This topic has been locked.
7 replies Latest Post - 2012-04-26T13:25:21Z by SystemAdmin
Pinned topic GPFS cluster migration from ibm storage to hitachi storgae
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
PLease some one help me to do the migration from ibm storage to hitachi storage gpfs as well as lpar
Updated on 2012-04-26T13:25:21Z at 2012-04-26T13:25:21Z by SystemAdmin
tony.evans 0600007X8X4 PostsACCEPTED ANSWER
Re: GPFS cluster migration from ibm storage to hitachi storgae2012-04-17T12:04:46Z in response to madhavanbabuThat's a rather open ended query for a web discussion forum.
Perhaps you need to call out to your management team you don't feel able to achieve the work they've given you with the experience and resources you currently have, for what sounds like a reasonably large project.
Instead, ask them to pay for sufficient training and potentially consultancy from technical and experienced staff who can work with you to deliver the solution.
Perhaps you should engage other people in your organisation to see if they have skills they can lend to help you deliver.
HajoEhlers 0100001U0A232 PostsACCEPTED ANSWER
Re: GPFS cluster migration from ibm storage to hitachi storgae2012-04-17T19:11:32Z in response to tony.evansI think your right Tony but the OP ask for help....
Since you almost provide no information
- You have a large amount of data to migrate ( >20 TB ) - Otherwise use tar on LTO5 Tapes.
- You have a high speed link ( eth or FC ) between your DC or much time
- Create new cluster member at the new DC attached to the hitachi storage
- use GPFS tools ( Storage pool migration or mirroring ) to migrate from the old storage to the new storage
- Configure the new cluster member as quorum and manager nodes
- Shutdown old members.
There are better solution around but this is at least for free _
Re: GPFS cluster migration from ibm storage to hitachi storgae2012-04-17T19:26:20Z in response to HajoEhlersRight, in Hajo's scenario, you add new machines to the cluster, migrate and/or mmdeldisk and there you go. Still assumes you can hook all the machines together for a while...
StorageTeamGenomeCenter 270003CDEH31 PostsACCEPTED ANSWER
Re: GPFS cluster migration from ibm storage to hitachi storgae2012-04-18T18:45:26Z in response to SystemAdminYou can also use storage pools to migrate the data in GPFS.
setup a new storage pool for the new disk then use a policy to move the data from one pool to the other
RULE 'drain-old-disk-arry' MIGRATE FROM POOL 'old-disk-arry' TO POOL 'new-disk-arry'
you will need some good disk in the default system pool for metadata.
Re: GPFS cluster migration from ibm storage to hitachi storgae2012-04-17T19:22:58Z in response to tony.evansTechnically, relatively easy IF you can get all the disks hooked up to the same system, at least for a while....
mmadddisk and mmdeldisk !
Otherwise, you're looking at exercising your backup and restore functions! Or a potentially long running rcp/rsh/rsync/find/tar/cpio kinda thing.
If you don't know what I'm writing about, better google some of the terms or follow Tony Evans advice ;-)
madhavanbabu 2700033RX93 PostsACCEPTED ANSWER
Re: GPFS cluster migration from ibm storage to hitachi storgae2012-04-26T06:49:46Z in response to SystemAdminHi,
You mean add the new host to the gpfsi cluster and add NSD and migrate the file systems like that ?
But this will be differnet PV's right ? there are 2 nodes in cluster.
Can you explain little bit more
Re: GPFS cluster migration from ibm storage to hitachi storgae2012-04-26T13:25:21Z in response to madhavanbabuGenerally (there may be some limits and restrictions) you can add nodes via mmaddnode to an existing cluster and you can add real-disks, which become GPFS NSDs via mmcrnsd, and then filesystem disks via mmadddisk. If you defined any new GPFS pools when adding those disks, you probably want to run mmapplypolicy to migrate data to the new disks.
Then you can remove disks from a filesystem with mmdeldisk. mmdeldisk will automagically relocate data to other disks in the same pool(s) - of course it will fail if you don't have enough disk space in the remaining disks within the corresponding pool(s). Next mmdelnsd to delete NSD definitions corresponding to the disks you are decommissioning. Next mmdelnode to remove the nodes you are decommissioning. Be careful to maintain quorums and so forth. Of course, skip the mmaddnode/mmdelnode steps if you're not swapping out nodes, only re-provisioning disks.