-2

I am at my wit’s end with File Server clustering under Hyper-V. I am hoping that someone might be able to help me figure out this Gordian Knot of a technology that seems to have dead ends (like forcing cluster VMs to use iSCSI drives where normally-attached VHDX drives could suffice) where logic and reason would normally provide a logical solution.

My hardware:

I will be running three servers (in the end), but right now everything is taking place on one server. One of the secondary servers will exist purely as a witness/quorum, and another slightly more powerful one will be acting as an emergency backup (with additional storage, just not redundant) to hold the secondary AD VM and the other halves of a set of clustered VMs: the SQL VM and the file system VM. Please note, these each are the depreciated nodes of a cluster, the main nodes will be on the most powerful first machine.

My heavy lifter is a machine that also contains all of the truly redundant storage on the network. If this gives anyone the heebie-geebies, too bad. It has a 6TB (usable) RAID-10 array, and will (in the end) hold the primary nodes of both aforementioned clusters, but is right now holding all VMs. This is, right now: DC01, DC02, SQL01, SQL02, FS01 & FS02. Eventually, I will be adding additional VMs to handle Exchange, Sharepoint and Lync, but only to this main server (the secondary server won't be able to handle more than three or four VMs, so why burden it? The AD, SQL & FS VMs are the most critical for the business).

If anyone is now saying, “wait, what about a SAN or a NAS for the file servers?”, well too bad. What exists on the main machine is what I have to deal with.

I followed these instructions, but I seem to be unable to get things to work. In order to make the file server truly redundant, I cannot trust any one machine to hold the only data store on the network. Therefore, I have created a set of iSCSI drives on the VM-host of the main machine, and attached one to each file server VM. The end result is that I want my FS01 to sit on the heavy lifter, along with its iSCSI “drive”, and FS02 will sit on the secondary machine with its own iSCSI “drive” there as well. That is, neither iSCSI drive will end up sitting on the same machine as the other. As such, the clustered FS will utterly duplicate the contents of the iSCSI drives between each other, so that if one physical machine (or the FS VM) goes toes-up, the other has got a full copy of the data on its own iSCSI drive.

My problem occurs when I try to apply the file server role within the failover cluster manager. Actually, it is even before that -- it occurs when adding the disks. Since I have added each disk preferentially to a specific VM (by limiting the initiator by DNS hostname, and by adding two-way CHAP authentication), this forces each VM to be in control of its own iSCSI disk. However, when I try to add the disks to the Disks section of Storage within Failover Cluster Manager, the entire process fails for a random disk of the pair. That is, one will get online, but the other will remain offline because it does not have the correct “owner node”. I mean, really -- WTF? Of course it doesn’t have the right owner node, both drives are showing the same node name!! I cannot seem to have one drive show up with one node name as owner, and the other drive show up with the other node name as owner. And because both drives are not “online”, I cannot create a pool to apply to a cluster role. Talk about getting stuck between a rock and a hard place!

I’ve got more to add, but my work is closing for the day and I have to wrap things up. I will try to add more tomorrow morning when I get in.

My main objective is to have a file server VM on each machine, the storage on each machine, but a transparent failover in case one physical machine fails. Essentially, a failover FS that doesn’t care which machine fails -- the storage contents are replicated equally on each machine. Am I even heading in the right direction?

René Kåbis
  • 107
  • 2
  • 3
  • 9
  • 1
    Just for the record, Hyper-V doesn't really come into play here at all. You'd have the same problem on physical servers, or vSphere guests. – MDMarra Nov 06 '13 at 02:34
  • @René Kåbis - don't take this the wrong way, but taking a look at the other questions you have raised here, I would highly suggest you find a quality local technology provider to help you with your infrastructure if you don't have the resources in-house. You seem to lack a basic understanding of best practices and the various technologies that might provide better alternatives to help you accomplish your goals. – Rex Nov 06 '13 at 04:26
  • @Rex This has nothing about lacking in-house resources, and has everything to do with the boss having a tight pocketbook. If he can’t even pay for in-house resources that I have sourced myself (and I am *very good* at making dollars stretch wrt tech… typically 80-50% of what an outside provider would charge), what makes you think he’ll pay even more dollars for a provider’s recommendation? I had enough struggle to get the tech that I do have, paying even more for an outside firm is simply never going to happen. – René Kåbis Nov 06 '13 at 16:33
  • I would argue that you don't have a good grasp of the technologies involved here thus the suggestion to find people that can work directly with you on designing a proper solution. Buying technology without knowing how to use it or knowing it will work is like buying a bunch of material to build a house but not talking to an architect and not hiring key workers (contractors/electricians/carpenters/etc) to help you build it. – Rex Nov 12 '13 at 06:17

2 Answers2

13

The reason you're frustrated is because you're trying to do something that you shouldn't be doing.

You say

If anyone is now saying, “wait, what about a SAN or a NAS for the file servers?”, well too bad.`

You're right. Too bad for you.

What you're trying to do cannot work. A cluster disk must be the same disk shared amongst cluster members. You can't make separate disks, replicate the data somehow, and use it as a cluster volume. It doesn't work like that. This is why cluster disks typically live on a SAN and not on local storage.

Instead of clustering, you may be better off with DFS replication and namespaces. It's a slightly different animal than clustering, but if you need to use separate disks, because you don't have proper shared storage, it's the best option available.

Additional clarification:

As such, the clustered FS will utterly duplicate the contents of the iSCSI drives between each other, so that if one physical machine (or the FS VM) goes toes-up, the other has got a full copy of the data on its own iSCSI drive.

This isn't how clustering works. You can't do this.

I cannot seem to have one drive show up with one node name as owner, and the other drive show up with the other node name as owner.

Again - because that's not how it works. If you're trying to add a disk to a cluster, it should be shared amongst all nodes in the cluster. That's how it works. This is the expected outcome of trying to add disks to a cluster that all members cannot see.

My main objective is to have a file server VM on each machine, the storage on each machine, but a transparent failover in case one physical machine fails.

If you want independent storage on each machine, you don't want clustering. You'll be better off with DFS Namespaces and Replication instead. It's not the same as clustering, but you can usually accomplish a similar outcome for simple file services needs.

I strongly urge you to read through the Windows Failover Clustering documentation before you try and do anything else.

MDMarra
  • 100,183
  • 32
  • 195
  • 326
  • I will try DFS Replication and Namespaces. With that said, should I use a “storage” VHDX attached directly to a VM, or should I still use an iSCSI VHDX served up by the host? I’m thinking the former makes more sense in terms of migrating the VM to its eventual machine. – René Kåbis Nov 06 '13 at 16:36
  • And simple services are exactly what I need. There will be only two objectives with the file server. One is providing a network share for profile folder redirection (so everyone’s profile folders are on the network share for easy backup and maintenance… I can loose a physical workstation without worrying if it has been backed up). The other is for a generic network share - a single data dump point, as it were. – René Kåbis Nov 06 '13 at 16:39
  • @RenéKåbis it doesn't matter. A VHDX is a VHDX and can be moved around wherever you need it to be. Just make it on local storage unless you have a real reason not to. iSCSI just makes things unnecessarily complicated here. – MDMarra Nov 06 '13 at 17:16
  • That’s what I thought - thanks. As well, when installing DFS Namespaces and Replication, I also included Data Deduplication (primarily for the User Profiles vhdx, to keep it slim). Should I also be adding BITS and Remote Differential Compression for network responsiveness between the two VMs? Keep in mind, they will end up being on different physical machines. – René Kåbis Nov 06 '13 at 17:54
  • BITS doesn't factor in here. RDC can be leveraged but is probably unnecessary if on the same LAN. – MDMarra Nov 06 '13 at 17:57
  • It will be on the same LAN, so I’ve left it out. Another question: The two FS VMs have already been clustered, and the clustering provides me with a nice DNS hostname to point any share toward - should I leave clustering in place, or should I implement Namespaces? I have already implemented replication between “local drives” within each VM, so I am not sure what to do next prior to enabling a network share to each drive. – René Kåbis Nov 06 '13 at 21:18
  • Don't leave the cluster in place. Use namespaces. – MDMarra Nov 07 '13 at 00:09
  • Thanks, I had already gone ahead and destroyed the cluster. Shame, tho -- clustering gives such a nice singe point of access for the network. Still, the setup is odd: If a file server has its own storage internally, clustering cannot be used. DFS Namespaces & Replication must be used instead. But if the storage is external to the whole setup, clustering can be used. And yet, clustering provides a single IP/DNS entry for the set of machines that can fail over gracefully -- why not also allow replication between member machines? – René Kåbis Nov 07 '13 at 17:08
  • DFS using a single DNS entry as well (just not a single IP). You can setup Hyper-V replicas that replicate guests from one host to another but doesn't provide failover. You could setup a virtual storage appliance with local storage and connect your guests from either host to that virtual storage appliance. Some virtual storage appliances would even allow you to replicate that storage to the other host's local storage. There are a lot of ways to approach this but they way your originally tried is not one of them. – Rex Nov 11 '13 at 15:59
2

The article you link to sets up one server to act as an iSCSI target that both Hyper-V servers connect to for shared storage (did you not catch that?). Meaning, it acts as the NAS/SAN-like device and provides the shared storage that the other two hosts both connect to for storage. What you are trying to do is completely different.

.. Am I even heading in the right direction?

Frankly, No.

As MDMarra suggest, DFS would be technology I would look at to accomplish this objective.. If you want the same for Exchange, you would setup a DAG for the database and CAS Array for the CAS servers. For SQL 2012, you would be looking at SQL Always On.

These technologies are BUILT specifically for these purposes and all don't rely on Hyper-V. If you want to leverage Hyper-V in all this, I would suggest you look at Hyper-V replica in 2012. It wouldn't necessary provide you automatic failover, but it would create the redundant copy of the data that you seem to think you need.

edit: all these things were brought up in your last question here.

edit2: If you can't live with the limitations of DFS and want to setup a file server cluster either within Hyper-V or not, please read the clustering requirements to do so. In particular, note the storage section that starts off saying: "You must use shared storage.." What you are setting up is not shared storage.

Community
  • 1
Rex
  • 7,815
  • 3
  • 28
  • 44
  • RE: Your first paragraph -- Okay, then what happens if the NAS/SAN goes down? I would assume that a pair of them (mirrored for redundancy) would also need to be clustered in order to provide a single IP/DNS entry on the network… aaaaahhhh but then it cannot be clustered because you would need to enable replication (so each has identical content), but then what you have are multiple points on the network that would not have transparent failover capabilities so they would need to be clustered… **STACK OVERFLOW** – René Kåbis Nov 07 '13 at 17:18
  • Of course, with the above tounge-in-cheek example, I am focusing more on a need for a single IP/DNS address that can fail over than an actual namespace. What really attracted me to clustering was the ability to have a single IP address represent a range of clustered units. Namespaces look to be doable for my work’s requirements in the short term (1-5 years), but I really can’t understand why clustering couldn’t have been built with internal replication in mind (as an additional feature). Sure, prefer the external NAS/SAN, but also provide internal replication for those small-scale/edge cases. – René Kåbis Nov 07 '13 at 17:36
  • SAN's are built for redundancy. Almost any quality SAN will have dual controllers to manage controller failure. If you want, you could also look at storage like HP StoreVirtual scale out solution type SAN's that have multiple devices each with dual controllers and can setup network RAID mirroring between chassis to hand full chassis failure. – Rex Nov 07 '13 at 17:51