So I have two old physical Windows Server 2003 clustered file servers using a fiber attached SAN. We didn't upgrade them to Window Server 2008 due to cluster scoping issues. Now, we need to retire the old hardware and want to move the data to a new iSCSI SAN and make use of our 2012 HyperV Cluster. We want them HA and when we do patching don't want any down time. We do use Domain DFS so that makes it easier but I'm not sure of which way to setup?
Should I add a File Server role to our 2012 HyperV cluster and have it access a volume on the SAN? No downtime with patching when using the CAU.
Should I setup a new VM (WS2012) on the cluster with a 2TB vhdx and go that route? I know I don't use Pass Thru disks. Problem is when it comes to patching that there will be some down time.
Should I setup 2 new VM's (WS2012), put them in a cluster, and have them use a shared VHDX? Each VM can then be patched with no downtime.
Performance issues one way or the other? Pros and/or Cons of each? Recommendations?
Edit: May have to use PassThrough after reading Finn's articles again.
quote:•Passthrough: A raw LUN that is formatted and used by the VM. It is immobile. With the 64 TB VHDX around, there are only 2 valid reason to use this in the real world: you need to share a LUN via iSCSI/Virtual HBAs to create a guest cluster, or you are in a very rare situation where a 64 TB VHDX is not big enough.
Hey Jerrod, Yah, you'll need to use passthrough if you want to create a guest cluster. Honestly, I don't know the migration path from W2003 file server cluster to a "general use" WS2012 file server cluster. There's usually a file server migration toolkit or whitepaper published when a new version of Server is released.
Please ignore some of the muppets online saying you should use a Scale Out File Server for end user file shares. They're muppets. Nuff said. SOFS is for application file shares.
Since you are using DFS, the migration should be fairly straightforward. You can use the FSMT, but I've found robocopy works well enough. The command you want is "robocopy /mir /sec". You can run this command multiple times to keep the new file share in sync until you cutover.
So basically, the steps would be: 1. Run robocopy to pre-stage the new share 2. Run it the next day to get an idea how long the delta copy will take. 3. Schedule downtime to cutover based on that second run. 4. Unshare the old file share 5. Run a final robocopy to update the new share. 6. Add the new file share to DFS
If you are running 2003 R2, you could also potentially use DFS Replication instead, but since this is a one-time cutover, it's probably not the best option.
Michael D'Angelo (former)MVP-MIIS, Pace University Senior Systems Administrator (Windows)(MS)NMDANGE PhoeniX WorX Systems Administrator. If you play Total Annihilation, please join us. http://www.phoenixworx.org
Maybe, I could use a virtual nic (team?) and connect to the iSCSI SAN that way but then am sharing the bandwidth with the rest of the NIC Team. That would give us the most flexibility when if we needed to move it but I would be sacrificing performance.
The data migration of the data will be done using robocopy to the new location and adding to DFS. These are homedir and profiles so can only do so much in prep. Thanks for the extra thoughts.