Windows Failover Clustering Can't Add iSCSI Disk
-
@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 availableredundant 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 availableredundant 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 availableredundant 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 availableredundant 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.
