Availability for the Always-On Enterprise
chrisdearden
Expert
Posts: 1530
Liked: 225 times
Joined: Jul 21, 2010 9:47 am
Full Name: Chris Dearden
Contact:

Re: v8 - NetApp Backup from Storage Snapshots Inquiry

Post by chrisdearden » Jun 19, 2014 5:15 pm

I was under the impression that Always on Availability groups operated in the same way as exchange database availability groups.
http://msdn.microsoft.com/en-gb/library/ff877884.aspx

There are no shared disks, with a Majorty Node Quorum or file share witeness being used.

Gostev
Veeam Software
Posts: 23216
Liked: 2970 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: v8 - NetApp Backup from Storage Snapshots Inquiry

Post by Gostev » Jun 19, 2014 6:01 pm

BrettM wrote:Nope, not true - and again I wish it were. "AlwaysOn Availability Groups" is mostly just Microsoft's new pet name for SQL clusters. From microsoft's website ( http://msdn.microsoft.com/en-us/library/ff929171.aspx ): "AlwaysOn Availability Groups, the high availability and disaster recovery solution introduced in SQL Server 2014, requires Windows Server Failover Clustering (WSFC)"

Actually it was introduced in SQL 2012, but the only thing that's new is the ability to replicate *between* clusters - and while that does not require shared storage, the clusters themselves still do.
No, they don't. Not since Windows Server 2008.

BrettM
Novice
Posts: 9
Liked: never
Joined: Sep 01, 2011 10:03 pm
Full Name: Brett Mullins
Contact:

Re: v8 - NetApp Backup from Storage Snapshots Inquiry

Post by BrettM » Jun 19, 2014 8:21 pm

Gostev wrote:No, they don't. Not since Windows Server 2008.
Like I said above, only if you use SMB3.0 filesharing protocol to get around shared storage - which itself still requires a 2012 fileserver, so the storage itself is really still "shared", just not via traditional storage from SAN or NAS. Which means you can't update and reboot that fileserver without taking down the entire cluster - goodbye HA. Unless you choose to host that SMB3.0 fileshare on another MSCS cluster - and now you have a chicken & egg conundrum.

So I can completely virtualize my storage at the expense of clustered HA, or I can maintain clustered HA at the expense of virtualized storage - I can't have both. And being forced to choose between the two, at this time I have to choose SQL clustered HA for my own environment. At least in my environment, the SAN doesn't require updates every two weeks like MS servers do - and being properly redundant (two controllers, two switch fabrics) my storage stays up and running even when I *do* update it (although granted, not all SAN/NAS is created equal).

I have researched this exhaustively, because I *really* want to have my cake and eat it too - if anyone else knows how, tell me! I just don't see it working anytime soon with Microsoft clusters, and no other solution that works as well as MSCS for HA to keep services continuously running.

Great little article on using the SMB3.0 fileshare protocol: http://www.sqlskills.com/blogs/jonathan ... d-storage/

BrettM
Novice
Posts: 9
Liked: never
Joined: Sep 01, 2011 10:03 pm
Full Name: Brett Mullins
Contact:

Re: v8 - NetApp Backup from Storage Snapshots Inquiry

Post by BrettM » Jun 19, 2014 8:49 pm

chrisdearden wrote:I was under the impression that Always on Availability groups operated in the same way as exchange database availability groups.
http://msdn.microsoft.com/en-gb/library/ff877884.aspx

There are no shared disks, with a Majorty Node Quorum or file share witeness being used.
From your own quoted MS article, 6 paragraphs down: "Deploying AlwaysOn Availability Groups requires a Windows Server Failover Clustering (WSFC) cluster." It is the CLUSTER which is dependent on some form of shared storage, either from a "persistent" SCSI connection via traditional SAN/NAS (fiber/iSCSI), or from the SMB3.0 fileshare protocol which itself requires a shared 2012 or newer server.

Gostev
Veeam Software
Posts: 23216
Liked: 2970 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: v8 - NetApp Backup from Storage Snapshots Inquiry

Post by Gostev » Jun 19, 2014 8:54 pm 1 person likes this post

BrettM wrote:Like I said above, only if you use SMB3.0 filesharing protocol to get around shared storage - which itself still requires a 2012 fileserver, so the storage itself is really still "shared", just not via traditional storage from SAN or NAS. Which means you can't update and reboot that fileserver without taking down the entire cluster - goodbye HA. Unless you choose to host that SMB3.0 fileshare on another MSCS cluster - and now you have a chicken & egg conundrum.

So I can completely virtualize my storage at the expense of clustered HA, or I can maintain clustered HA at the expense of virtualized storage - I can't have both. And being forced to choose between the two, at this time I have to choose SQL clustered HA for my own environment. At least in my environment, the SAN doesn't require updates every two weeks like MS servers do - and being properly redundant (two controllers, two switch fabrics) my storage stays up and running even when I *do* update it (although granted, not all SAN/NAS is created equal).

I have researched this exhaustively, because I *really* want to have my cake and eat it too - if anyone else knows how, tell me! I just don't see it working anytime soon with Microsoft clusters, and no other solution that works as well as MSCS for HA to keep services continuously running.

Great little article on using the SMB3.0 fileshare protocol: http://www.sqlskills.com/blogs/jonathan ... d-storage/
Clearly, we are not on the same page in this discussion :D

For the AlwaysOn Availability Groups deployment scenario I am thinking about:
1. There is NO need for SMB 3.0 or Server 2012 anywhere in the picture. You can do everything with SMB 2.0 and Server 2008.
2. There is NO need for ANY sort of shared storage for the actual cluster. The independent database copies exist locally in VMDK of each SQL node. You do need a basic witness share, but it is used for voting only, and does not store cluster configuration data or SQL databases.
BrettM wrote:From your own quoted MS article, 6 paragraphs down: "Deploying AlwaysOn Availability Groups requires a Windows Server Failover Clustering (WSFC) cluster." It is the CLUSTER which is dependent on some form of shared storage, either from a "persistent" SCSI connection via traditional SAN/NAS (fiber/iSCSI), or from the SMB3.0 fileshare protocol which itself requires a shared 2012 or newer server.
That is absolutely right, AlwaysOn Availability Groups do rely on the Windows Server Failover Cluster (WSFC) for failure detection and management of the Availability Group replicas. And this is where you may be getting confused due to not knowing one Microsoft Cluster Services capability. In Windows Server versions prior to 2008, you must have some form of shared storage available for the cluster's quorum disk to be able to create a failover cluster. However, Windows Server 2008 and later provide the option to use a file share witness as a quorum configuration. Therefore, you do NOT need shared storage to create a Failover Cluster. That file share can be hosted anywhere (except on the actual cluster), and it does not need to be SMB 3.0, as it is used as a witness only. And yes, in this particular failover cluster deployment scenario you absolutely CAN reboot the VM or NAS behind the witness share without taking the entire cluster down, because the majority of voting elements will still remain in communication.

Does it make sense?

Gostev
Veeam Software
Posts: 23216
Liked: 2970 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: v8 - NetApp Backup from Storage Snapshots Inquiry

Post by Gostev » Jun 19, 2014 11:15 pm 1 person likes this post

SQL Server 2012 AlwaysOn: High Availability database for cloud data centers
How to deploy SQL Server AlwaysOn in a failover cluster without shared storage to achieve high availability SQL.

BrettM
Novice
Posts: 9
Liked: never
Joined: Sep 01, 2011 10:03 pm
Full Name: Brett Mullins
Contact:

Re: v8 - NetApp Backup from Storage Snapshots Inquiry

Post by BrettM » Jun 20, 2014 4:30 pm

Gostev and ChrisDearden, my apologies, I have been using AOAG groups and AOFCI (Failover Cluster Instance) interchangeably even though they are not the same. AOFCI (previously just known as "clustering") has been around since SQL 2005, while AOAG groups were not introduced until SQL 2012. While Gostev is technically correct with point #1, in practice it is a bad idea; it is not reliable, assuming you can even get it to work at all: http://www.mssqltips.com/webcasts/Real- ... 130131.pdf

Because AOAG groups are just an advanced form of database mirroring, I concede point #2 - but I already covered mirrors and their problems in an earlier post. AOAG groups add functionality that enables customers to configure multiple databases that will failover as a unit, with support for up to four active secondary servers and two synchronous secondary servers. Beyond that, AOAG groups continue to have the same technical problems that all mirror solutions do:

1. They only protect at the database level, not at the instance or server level (that's what FCI is for, which DOES require shared storage).
2. If you want HA, it requires each vendor App accessing an AOAG group to support mirroring (surprisingly few do). Otherwise the app can only point at one of the nodes, and will loose connection as soon as you have a failure (or if the node goes passive).
3. They have increased administrative overhead, including the fact you must manage everything at the DB level (though not as much as traditional mirroring does - that's the whole point of groupings).
4. They have database security limitations - either hope the DB app was designed to use windows domain security for DB access, or be forced to manually synchronize SQL account SIDs across the nodes for each DB. Again, it's surprising (and depressing) how many vendor solutions using SQL still require SQL accounts to work correctly.
5. As a mirror solution, each additional DB mirror introduces increased resource overhead. In SQL 2008 R2 and below, there was a practical limit of 10 mirrors per instance before resource contention started to cause significant performance problems. AOAG groups treat each "group" as a singular "mirror", with each group able to handle up to 10 DBs, so each instance can potentially handle up to 100 DBs - but that much mirroring still requires a lot of resources as the link above points out.

It should also be noted that even as of SQL 2014, AOAG protection is only available for Enterprise SQL ( http://technet.microsoft.com/en-US/libr ... .120).aspx ). Unless you only have one active node (and can prove it to a Microsoft audit team via access logs), then all nodes in an AOAG group must be licensed; at $7k per core with a 4 core minimum per node, *plus* the cost of SA software assurance required for Microsoft's inane legalities regarding failover, that can get expensive quick. If I don't actually *need* Enterprise SQL except for AOAG groups, then we potentially have a case of the tail wagging the dog - why should I care about non-shared virtualized storage when I could instead just *buy* some cheap SANs to replicate between and still come out ahead?

All that said however, if you can work with the limitations and/or expense of a mirror solution (traditional or AOAG) then they are an excellent alternative to FCI and indeed can be completely virtualized; we use one for our webfarm. Here's an excellent resource for everything about AOAG groups: http://www.brentozar.com/sql/sql-server ... ty-groups/

Gostev
Veeam Software
Posts: 23216
Liked: 2970 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: v8 - NetApp Backup from Storage Snapshots Inquiry

Post by Gostev » Jun 20, 2014 7:18 pm

Brett, thank you for taking time for thorough response. I certainly agree AOAG has its own disadvantages, but they are well balanced with enabling virtualized SQL Server, including virtualized storage. We are seeing exponential uptake of AOAG within our customer base, so support of this deployment model is one of the big focuses for us in the upcoming B&R v8, including full support of AOAG in the upcoming Veeam Explorer for SQL Server.

Post Reply

Who is online

Users browsing this forum: Google [Bot] and 19 guests