Hi All, Interested to know peoples view on the scenario / project below and which way you would go. Currently in place:
Objective is to move to VCSA 6.7u3 or 7.0 and replace all 8 vSAN Hosts hardware with new servers. Options could be:
Any options i have missed?
Which approach have you taken / would you take?
Thanks,
Hello MJMSRI
I wouldn't really consider adding an existing cluster to a new vCenter as being a "big risk" - I have done all or part of this many many times and as long as all of the elements that need consideration (as covered in the kb) are adhered to, it shouldn't be a problem (but that being said, I fix problems for a living so maybe just nothing I would see as a big problem).
If you wanted to avoid some of the vDS import/export aspects, you could migrate all networking to standard switch(es) and then back to new vDS in the new vC.
Potentially a combination of Option 1 and 2 could be done e.g.:
- Upgrade and migrate current vC to vCSA 6.7 U3.
- Add new cluster to this vC as its own cluster and configure it as a 4+4+1 with whatever features you have/want (could temporarily use Evaluation license on this cluster until you can use the old clusters license).
- SvMotion all the VMs and/or other data to the new cluster.
- Once empty, decommission the old cluster.
While SvMotion (probably) may not be as fast as throughput when moving data with MM FDM option, it will make up (at least in part) by the facts that 1. no data is getting moved more than once (e.g. as per option 2 the data is getting moved to old hosts, then mix of old and new hosts and so on) and 2. won't require to have sufficient free space to fully evacuate a node in one site and thus will avoid any potential space issues - this would also apply if for instance a RAID5+RAID5 on each site Storage Policy was in use as FDM of any node would not be possible as this requires a minimum of 4+4+1 for component placement.
What I have seen some customers doing is adding the new nodes to the cluster to make it a 8+8+1 (4 old and 4 new on each site) then doing pretty much as you said in option 2, though this would require (temporarily at least) that the cluster be vSAN licensed for all 16 nodes worth of sockets.
daphnissov has a really good blog post on the pros and cons of upgrade vs migrate which should be considered for the vCenter aspect here:
Upgrading vSphere through migration
Bob
Hello MJMSRI
I wouldn't really consider adding an existing cluster to a new vCenter as being a "big risk" - I have done all or part of this many many times and as long as all of the elements that need consideration (as covered in the kb) are adhered to, it shouldn't be a problem (but that being said, I fix problems for a living so maybe just nothing I would see as a big problem).
If you wanted to avoid some of the vDS import/export aspects, you could migrate all networking to standard switch(es) and then back to new vDS in the new vC.
Potentially a combination of Option 1 and 2 could be done e.g.:
- Upgrade and migrate current vC to vCSA 6.7 U3.
- Add new cluster to this vC as its own cluster and configure it as a 4+4+1 with whatever features you have/want (could temporarily use Evaluation license on this cluster until you can use the old clusters license).
- SvMotion all the VMs and/or other data to the new cluster.
- Once empty, decommission the old cluster.
While SvMotion (probably) may not be as fast as throughput when moving data with MM FDM option, it will make up (at least in part) by the facts that 1. no data is getting moved more than once (e.g. as per option 2 the data is getting moved to old hosts, then mix of old and new hosts and so on) and 2. won't require to have sufficient free space to fully evacuate a node in one site and thus will avoid any potential space issues - this would also apply if for instance a RAID5+RAID5 on each site Storage Policy was in use as FDM of any node would not be possible as this requires a minimum of 4+4+1 for component placement.
What I have seen some customers doing is adding the new nodes to the cluster to make it a 8+8+1 (4 old and 4 new on each site) then doing pretty much as you said in option 2, though this would require (temporarily at least) that the cluster be vSAN licensed for all 16 nodes worth of sockets.
daphnissov has a really good blog post on the pros and cons of upgrade vs migrate which should be considered for the vCenter aspect here:
Upgrading vSphere through migration
Bob
Hi TheBobkin
Yes i think the combination approach will be the best considering the work involved with other options, this will allow for licencing changeover and also provide some good options for svmotion batches from old to new. Thanks.