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