Windows Failover Clustering Can't Add iSCSI Disk



  • I have a Windows Server 2012 R2 failover cluster for SQL Server 2012. It works fine, I have a shared disk in there, and I can fail it over no problem.

    I want to add an additional shared disk to this cluster. In order to add a shared disk to the cluster, you set up the iSCSI connections on all the servers involved, and then connect tell the Failover Cluster Manager to "Add Disk"

    When I tell it to Add Disk, it simply tells me there are no suitable disks available. What am I missing?

    Cluster Validation looks good and tells me that the disk will fail over properly with no problems.



  • @dafyre said:

    I have a Windows Server 2012 R2 failover cluster for SQL Server 2012. It works fine, I have a shared disk in there, and I can fail it over no problem.

    I want to add an additional shared disk to this cluster. In order to add a shared disk to the cluster, you set up the iSCSI connections on all the servers involved, and then connect tell the Failover Cluster Manager to "Add Disk"

    When I tell it to Add Disk, it simply tells me there are no suitable disks available. What am I missing?

    Cluster Validation looks good and tells me that the disk will fail over properly with no problems.

    Wish I could help you ha.



  • @johnhooks said:

    @dafyre said:

    I have a Windows Server 2012 R2 failover cluster for SQL Server 2012. It works fine, I have a shared disk in there, and I can fail it over no problem.

    I want to add an additional shared disk to this cluster. In order to add a shared disk to the cluster, you set up the iSCSI connections on all the servers involved, and then connect tell the Failover Cluster Manager to "Add Disk"

    When I tell it to Add Disk, it simply tells me there are no suitable disks available. What am I missing?

    Cluster Validation looks good and tells me that the disk will fail over properly with no problems.

    Wish I could help you ha.

    If I had the option to build this out with Linux software, I'd have done that a long time ago... Sadly, 99% of the software we use is for Windows... /cry



  • @dafyre First absurdly dumb questioning here (hey, it's what I'm good at.) By your use of fail over cluster, that means you're setting this up at the SQL server and not the OS level, right?



  • @travisdh1 said:

    @dafyre First absurdly dumb questioning here (hey, it's what I'm good at.) By your use of fail over cluster, that means you're setting this up at the SQL server and not the OS level, right?

    Not this set, no. This set will be done as a File Server. I figured out part of what I am doing wrong, but I am waiting on my boss to give me an available IP address, lol.



  • And to comment, I am using the Windows Failover Clustering for my SQL Server instead of DAG or whatever it is called. That works perfectly fine for what we need. No need for it to be fancy. 🙂



  • @dafyre said:

    And to comment, I am using the Windows Failover Clustering for my SQL Server instead of DAG or whatever it is called. That works perfectly fine for what we need. No need for it to be fancy. 🙂

    I think DAG and SQL clustering are the same thing, one for Exchange and one for SQL.... Windows Failover Clustering is at the file level and should probably never be used for Exchange or SQL.



  • @Dashrender said:

    @dafyre said:

    And to comment, I am using the Windows Failover Clustering for my SQL Server instead of DAG or whatever it is called. That works perfectly fine for what we need. No need for it to be fancy. 🙂

    I think DAG and SQL clustering are the same thing, one for Exchange and one for SQL.... Windows Failover Clustering is at the file level and should probably never be used for Exchange or SQL.

    I don't think so. DAG is much more advanced where it is used. It's a different architecture.



  • @Dashrender said:

    I think DAG and SQL clustering are the same thing, one for Exchange and one for SQL.... Windows Failover Clustering is at the file level and should probably never be used for Exchange or SQL.

    This is the way it was done before SQL Server added DAG, I think. My first two Failover Clusters did this with SQL Server 2005, and 2008. We never had any problems with it... Go figure. The SQL Servers in both instances are backed by a SAN, so there's no need to have two copies of the files anywhere.

    I need to add DAG to my list of things to tinker with.



  • @dafyre said:

    This is the way it was done before SQL Server added DAG, I think. My first two Failover Clusters did this with SQL Server 2005, and 2008. We never had any problems with it... Go figure. The SQL Servers in both instances are backed by a SAN, so there's no need to have two copies of the files anywhere.

    Only problem is that you rely on the SAN. You have a single point of failure even after all of that work. If it is a super awesome SAN (EMC, HDS) this can work pretty well. But generally even a six figure SAN doesn't deliver as much as DAG would here.



  • aww.. so SQL has DAGs now too, eh?



  • @scottalanmiller said:

    @dafyre said:

    This is the way it was done before SQL Server added DAG, I think. My first two Failover Clusters did this with SQL Server 2005, and 2008. We never had any problems with it... Go figure. The SQL Servers in both instances are backed by a SAN, so there's no need to have two copies of the files anywhere.

    Only problem is that you rely on the SAN. You have a single point of failure even after all of that work. If it is a super awesome SAN (EMC, HDS) this can work pretty well. But generally even a six figure SAN doesn't deliver as much as DAG would here.

    sigh I really gotta update my definition of SAN to industry standards)... I am at a new employer, but we have a pair of highly available redundant Nimble SAN units (Network Raid 1,Two switches for each, two fiber paths for each, two UPSes for each, and Natural Gas Generators for each).



  • @Dashrender said:

    aww.. so SQL has DAGs now too, eh?

    Yes, actually SQL is the only thing that has them. AD and Exchange are using SQL under the hood. When they need HA, it is their SQL that primarily needs it. DAG is a SQL thing (AFAIK) and applies equally to all SQL-based products.



  • @dafyre said:

    @scottalanmiller said:

    @dafyre said:

    This is the way it was done before SQL Server added DAG, I think. My first two Failover Clusters did this with SQL Server 2005, and 2008. We never had any problems with it... Go figure. The SQL Servers in both instances are backed by a SAN, so there's no need to have two copies of the files anywhere.

    Only problem is that you rely on the SAN. You have a single point of failure even after all of that work. If it is a super awesome SAN (EMC, HDS) this can work pretty well. But generally even a six figure SAN doesn't deliver as much as DAG would here.

    sigh I really gotta update my definition of SAN to industry standards)... I am at a new employer, but we have a pair of highly available redundant Nimble SAN units (Network Raid 1,Two switches for each, two fiber paths for each, two UPSes for each, and Natural Gas Generators for each).

    Ah, are you using it the super correct way to refer to the entirety of the block storage network? In which case you need to update your parlance to the current slang for "storage array" 🙂



  • @scottalanmiller said:

    @dafyre said:

    @scottalanmiller said:

    @dafyre said:

    This is the way it was done before SQL Server added DAG, I think. My first two Failover Clusters did this with SQL Server 2005, and 2008. We never had any problems with it... Go figure. The SQL Servers in both instances are backed by a SAN, so there's no need to have two copies of the files anywhere.

    Only problem is that you rely on the SAN. You have a single point of failure even after all of that work. If it is a super awesome SAN (EMC, HDS) this can work pretty well. But generally even a six figure SAN doesn't deliver as much as DAG would here.

    sigh I really gotta update my definition of SAN to industry standards)... I am at a new employer, but we have a pair of highly available redundant Nimble SAN units (Network Raid 1,Two switches for each, two fiber paths for each, two UPSes for each, and Natural Gas Generators for each).

    Ah, are you using it the super correct way to refer to the entirety of the block storage network? In which case you need to update your parlance to the current slang for "storage array" 🙂

    Correction noted. 😛



  • @dafyre said:

    @scottalanmiller said:

    @dafyre said:

    This is the way it was done before SQL Server added DAG, I think. My first two Failover Clusters did this with SQL Server 2005, and 2008. We never had any problems with it... Go figure. The SQL Servers in both instances are backed by a SAN, so there's no need to have two copies of the files anywhere.

    Only problem is that you rely on the SAN. You have a single point of failure even after all of that work. If it is a super awesome SAN (EMC, HDS) this can work pretty well. But generally even a six figure SAN doesn't deliver as much as DAG would here.

    sigh I really gotta update my definition of SAN to industry standards)... I am at a new employer, but we have a pair of highly available redundant Nimble SAN units (Network Raid 1,Two switches for each, two fiber paths for each, two UPSes for each, and Natural Gas Generators for each).

    Is there a short name for a redundant SAN?

    Other than saying "I have a redundant SAN" I don't know how else you'd say it. Of course you can just talk about having a SAN, then the other party assumes that you only have one, and you'll be asked about it.. 😛



  • How do the Nimbles stack up against the big three: EMC, HDS and 3PAR? I've never used Nimble and hear people with good reports but I always find it hard to picture myself leaving the big three for enterprise block storage.



  • @Dashrender said:

    Is there a short name for a redundant SAN?

    Other than saying "I have a redundant SAN" I don't know how else you'd say it. Of course you can just talk about having a SAN, then the other party assumes that you only have one, and you'll be asked about it.. 😛

    Nope, same as with anything. If you say server, NAS, SAN, drive, etc. If you want people to know that it is redundant you have to say "I have two servers" or "I have drives in RAID 1" or whatever. If you say "a SAN" instead of "a pair of SANs" it sounds like there is just one, rather than one cluster.



  • @scottalanmiller said:

    Ah, are you using it the super correct way to refer to the entirety of the block storage network? In which case you need to update your parlance to the current slang for "storage array" 🙂

    Are you saying "storage array" has a specific meaning - 2 or more SANs replicating with redundant links, etc?



  • @scottalanmiller said:

    @Dashrender said:

    Is there a short name for a redundant SAN?

    Other than saying "I have a redundant SAN" I don't know how else you'd say it. Of course you can just talk about having a SAN, then the other party assumes that you only have one, and you'll be asked about it.. 😛

    Nope, same as with anything. If you say server, NAS, SAN, drive, etc. If you want people to know that it is redundant you have to say "I have two servers" or "I have drives in RAID 1" or whatever. If you say "a SAN" instead of "a pair of SANs" it sounds like there is just one, rather than one cluster.

    OK you can skip my other question then.



  • @scottalanmiller said:

    How do the Nimbles stack up against the big three: EMC, HDS and 3PAR? I've never used Nimble and hear people with good reports but I always find it hard to picture myself leaving the big three for enterprise block storage.

    These here have been rock solid. We actually have 4 pairs of them just for our VMware infrastructure, and another pair for our Banner virtual infrastructure (VMware, Oracle, and the Banner software).

    We had one blow out a drive last week, but it rebuilt over the weekend. Ours are configured with 3TB Spinning Rust drives, and some SSD drives for caching and tiering (unsure on size). Not sure what RAID they use or if it is a Nimble thing, but we didn't have any issues resulting from the dead drive.



  • @Dashrender said:

    @scottalanmiller said:

    Ah, are you using it the super correct way to refer to the entirety of the block storage network? In which case you need to update your parlance to the current slang for "storage array" 🙂

    Are you saying "storage array" has a specific meaning - 2 or more SANs replicating with redundant links, etc?

    I mean that what we always call a SAN is actually a block storage array. Technically the word SAN refers to the entire network on which a storage array (or many of them) sits including the switches, HBAs and everything attached.



  • @scottalanmiller said:

    @Dashrender said:

    @scottalanmiller said:

    Ah, are you using it the super correct way to refer to the entirety of the block storage network? In which case you need to update your parlance to the current slang for "storage array" 🙂

    Are you saying "storage array" has a specific meaning - 2 or more SANs replicating with redundant links, etc?

    I mean that what we always call a SAN is actually a block storage array. Technically the word SAN refers to the entire network on which a storage array (or many of them) sits including the switches, HBAs and everything attached.

    Which is why I usually refer to a single device as a storage device, lol.



  • @dafyre said:

    @scottalanmiller said:

    @Dashrender said:

    @scottalanmiller said:

    Ah, are you using it the super correct way to refer to the entirety of the block storage network? In which case you need to update your parlance to the current slang for "storage array" 🙂

    Are you saying "storage array" has a specific meaning - 2 or more SANs replicating with redundant links, etc?

    I mean that what we always call a SAN is actually a block storage array. Technically the word SAN refers to the entire network on which a storage array (or many of them) sits including the switches, HBAs and everything attached.

    Which is why I usually refer to a single device as a storage device, lol.

    Yeah, ideally we all would. Or at least a block storage device. Because really a NAS is a file storage device, too. And the two together is a unified storage device. But everyone uses the slang of calling the box a SAN. Which is what causes the problem of having to explain that it is the use that makes it a SAN, DAS or NAS rather than the device. It's because we are all using the slang instead of the correct terms from the get go.



  • @dafyre said:

    @travisdh1 said:

    @dafyre First absurdly dumb questioning here (hey, it's what I'm good at.) By your use of fail over cluster, that means you're setting this up at the SQL server and not the OS level, right?

    Not this set, no. This set will be done as a File Server. I figured out part of what I am doing wrong, but I am waiting on my boss to give me an available IP address, lol.

    Good! I'll buy the first round if we ever meet up.

    Also, looks like I need to dig into this DAG thing.



  • Looks like they are not using the DAG term, exactly, in SQL Server. Although it is a database and they do call it an availability group. So it is DAG, but without the acronym mentioned.

    https://msdn.microsoft.com/en-us/library/ms190202.aspx



  • @scottalanmiller said:

    Looks like they are not using the DAG term, exactly, in SQL Server. Although it is a database and they do call it an availability group. So it is DAG, but without the acronym mentioned.

    https://msdn.microsoft.com/en-us/library/ms190202.aspx

    Well that makes a lot more sense now - I've only ever seen DAG used in relation to Exchange. But it totally makes sense that MS build AD and Exchange from SQL, and that it's the SQL stuff that would be DAG'ed.



  • @scottalanmiller said:

    @Dashrender said:

    aww.. so SQL has DAGs now too, eh?

    Yes, actually SQL is the only thing that has them. AD and Exchange are using SQL under the hood. When they need HA, it is their SQL that primarily needs it. DAG is a SQL thing (AFAIK) and applies equally to all SQL-based products.

    Related to SQL but not iSCSI ( and not to hijack this thread ) I upgraded all my servers to MySQL 5.7 this weekend after finding out about the GTID and Channel features for multi-master replication. It works perfectly. This is a huge feature making multi-homed MySQL all-master all-active replication available in a community release. Someone should start a thread on this if there is not one already.

    About the iSCSI, I think I recall I saw a similar error once and found out I was doing something wrong. More specifically I didnt have the allowed iscsi initiators set correctly.

    thx
    -d



  • @drewlander said:

    @scottalanmiller said:

    @Dashrender said:

    aww.. so SQL has DAGs now too, eh?

    Yes, actually SQL is the only thing that has them. AD and Exchange are using SQL under the hood. When they need HA, it is their SQL that primarily needs it. DAG is a SQL thing (AFAIK) and applies equally to all SQL-based products.

    Related to SQL but not iSCSI ( and not to hijack this thread ) I upgraded all my servers to MySQL 5.7 this weekend after finding out about the GTID and Channel features for multi-master replication. It works perfectly. This is a huge feature making multi-homed MySQL all-master all-active replication available in a community release. Someone should start a thread on this if there is not one already.

    About the iSCSI, I think I recall I saw a similar error once and found out I was doing something wrong. More specifically I didnt have the allowed iscsi initiators set correctly.

    thx
    -d

    Nice to know about MySQL! I've never had to set up active/active MySQL before so that's a good thing to know. 😎

    I know what you mean about the iSCSI initiators not set correctly, but those are all correct here -- I can mount the iSCSI storage on each server (one at a time) with no problem. Heck, even the Windows Cluster validation tests the storage and it works fine! lol.



  • I have a sneaking suspicion that it is the fact that my 2 SQL Servers and the two other nodes that I want to use in this are on different subnets (although I am unsure as to why that would matter).

    My boss is going to get me an IP addy this morning, and I'll build a totally separate cluster for these two servers and see what happens.