VMware Cloud Community
ArchFan08
Contributor
Contributor
Jump to solution

VSAN Swing Migration

I'm doing a greenfield deployment of VSAN and I have a bit of a challenging situation. Initially we're going to start out with a 3 host cluster. 2 of the 3 hosts we're wanting to use long-term are currently bare metal installs and hosting important applications, the other is an R730xd purchased just for this purpose. I see 2 options:

  1. Bootstrap VSAN onto a single node, deploy vCenter to it, add 2 other servers to serve as temporary placeholders just to satisfy the 3 host VSAN requirement. Once everything has been configured, verified stable and working properly, P2V the applications running on the 2 long-term hosts and once they've been verified to be without issue, add 1 host at a time to the cluster and pull the temporary hosts out.
    • Pro:
      • Allows for testing of the configuration and verifying that vMotions can be completed, verifying that everything's stable, etc. This could all change with the addition of different hosts though
    • Con:
      • Complication of adding and removing hosts from the cluster. Possible licensing issues and increased risk of misconfiguration causing issues with the changes.
  2. Bootstrap VSAN onto a single node, deploy vCenter, P2V the applications running on the 2 long-term hosts and run those VM's on the R730xd, then add the newly freed-up servers to the cluster and add them to create the VSAN cluster
    • Pro:
      • Fewer steps. No migration of hosts required
    • Con:
      • Potential for failure is higher and with FTT=0 could leave us restoring from backups if something goes wrong

Any suggestions or possibilities I've missed?

Reply
0 Kudos
1 Solution

Accepted Solutions
zdickinson
Expert
Expert
Jump to solution

I would go with option 2.  If I understand, you get vSAN running on the new host with vCenter on it and FTT = 0.  You then P2V the bare metal to the vSAN with FTT = 0.  Then comes the high wire act of formatting the bare metal to ESXi and adding them to the vSAN cluster and the changing the FTT = 1.  The danger comes if you have a failure as you're adding the two nodes into the vSAN cluster.

A little twist on this, what I did.  We have 2 SSD and 14 disks in each host.  I created a RAID 5 using 3 of disks and made that a local data store.  That's where I deployed vCenter and where you could then P2V your bare metal.  Then I did vSAN on the rest of the disks and added my other hosts.  That way you can at least mitigate a disk failure taking you down.  Eventually I storage vMotion the VMs to vSAN, deleted the local datastore and claimed the disks for vSAN.

If that is you're only option, I guess you have to.  Obviously not ideal.  Thank you, Zach.

View solution in original post

Reply
0 Kudos
2 Replies
zdickinson
Expert
Expert
Jump to solution

I would go with option 2.  If I understand, you get vSAN running on the new host with vCenter on it and FTT = 0.  You then P2V the bare metal to the vSAN with FTT = 0.  Then comes the high wire act of formatting the bare metal to ESXi and adding them to the vSAN cluster and the changing the FTT = 1.  The danger comes if you have a failure as you're adding the two nodes into the vSAN cluster.

A little twist on this, what I did.  We have 2 SSD and 14 disks in each host.  I created a RAID 5 using 3 of disks and made that a local data store.  That's where I deployed vCenter and where you could then P2V your bare metal.  Then I did vSAN on the rest of the disks and added my other hosts.  That way you can at least mitigate a disk failure taking you down.  Eventually I storage vMotion the VMs to vSAN, deleted the local datastore and claimed the disks for vSAN.

If that is you're only option, I guess you have to.  Obviously not ideal.  Thank you, Zach.

Reply
0 Kudos
ArchFan08
Contributor
Contributor
Jump to solution

I hadn't thought of the scenario you mentioned and using storage vMotion - I like that route better so I'll probably do that. Thanks for the input!

Reply
0 Kudos