v8 - NetApp Backup from Storage Snapshots Inquiry

[ChrisV]

How will the NetApp "Backup from Storage Snapshots" protect direct attached LUNs / Volumes to VMs that utilize NetApp's SnapDrive software? It is clear that this solution will protect the VM itself but can it also protect the direct attached storage as well?

[Vitaliy S.]

Veeam will be able to backup any virtual disk that supports snapshotting and is visible on VM configuration. If you're referring to in-Guest direct attached volumes, than I assume you can use NetApp native capabilities to protect this VM on the storage layer.

[ChrisV]

Since the direct attached disks are not a VMDK (or RDM) then I highly doubt that the VMX file would reference these disks as any virtual disks since they are controlled via the SnapDrive software.

Our client is currently using the NetApp native SnapManager and Snapshot capabilities to protect the in-Guest direct attached volumes but they are seeking a means to backup this data to another backup target that is not the NetApp appliance. This is where the question falls if Veeam has any means to backup these in-Guest direct attached volumes to the non-NetApp backup target?

I would think that a good majority of NetApp solutions would utilize in-Guest direct attached volumes via Snapdrive. Hoping that Veeam has a solution otherwise having to add another supplemental backup solution with Veeam will cost our client's more $ and will be a less desirable solution.

[Vitaliy S.]

You're right, these volumes are not visible in VM configuration, thus neither snapshots not backups of these VMs using vStorage API for data protection are possible.

On a side note, can you please tell us a bit more on what data is usually stored on these volumes?

[ChrisV]

This is very unfortunate news and may be considered an under sight. Further integration should be considered in a near future revision of the Veeam NetApp integration, if possible. The claim that the Veeam integration with NetApp with being able to protect an entire virtual machine should be clarified further since this could end up being misleading to some considering this an all-in-one backup solution for VMs. SnapDrive is common with NetApp deployments and is pushed by sales as NetApp heavily relies on their licensing model to enable features and drive increased revenues.

The client's data within the in-Guest direct attached disks are both file and application based data such as Exchange, SQL, SharePoint, etc.

[ChrisV]

Has Veeam tested the NetApp Backup from Storage Snapshots option with SnapDrive mounted disks?

[Gostev]

We only support VMDK. And quite frankly speaking, in-guest iSCSI or RDM is a bad design these days anyway. By not having your VM storage virtualized, you are losing roughly half of all the benefits virtualization brings, and why people normally virtualize in the first place.

Now, I understand that back a few years ago, there were plenty of reasons to use in-guest iSCSI or RDM. But in 2014, there is not a single reason left. Just a bunch of drawbacks without a single benefit.

I don't think we are going to invest in supporting deployment scenarios which do not make sense today, even though I perfectly realize some customers have their virtual infrastructures deployed this way because of "heavy push from NetApp sales" as you put it. Alas, but sub-par virtualization storage architecture is what you get for letting sales people design your storage

Our vision is providing modern data protection for the modern data center, we are not really trying to be "everything for everyone" as this is the direct path to a failure.

[dellock6]

And to add my 2 cents, there are different methods to migrate easily from pRDM or in-guest disks to pure VMDK-based VMs, so instead of looking how to protect thos kind of disks, I would suggest and offer services to the customer to assist him/her in this migration.

[ChrisV]

Excellent feedback. Much appreciated for your thoroughness and patience. I completely agree with the VMDK statement, however we were trying to turn over every leaf from a client solution perspective since they have been particularly challenging when it comes to their standards.

Thank you again.

[BrettM]

We only support VMDK. And quite frankly speaking, in-guest iSCSI or RDM is a bad design these days anyway. By not having your VM storage virtualized, you are losing roughly half of all the benefits virtualization brings, and why people normally virtualize in the first place.

Now, I understand that back a few years ago, there were plenty of reasons to use in-guest iSCSI or RDM. But in 2014, there is not a single reason left. Just a bunch of drawbacks without a single benefit.

Sadly this is not true, even if I wish it were. One phrase - Virtualized Microsoft SQL clusters. Even now with vSphere 5.5, everything must be done either with in-guest iSCSI or with RDM; there is no support for virtualized shared storage outside "cluster in a box", aka everything on one host. Which is pointless from a DR or even HA perspective.

Microsoft SQL clusters are what most enterprise level companies use to protect their SQL data, whether to spread the load or merely provide "always on" protection. Annoyingly, even now it's the only practical way to keep a SQL instance up and running while updating the back end servers with patches and hotfixes. Technically SQL mirroring can also accomplish this, but all apps running on a SQL mirror must be written to be "mirror aware", whereas apps using clusters can be completely ignorant of such - so clusters tend to be far more prevalent in enterprise solutions these days (plus mirrors have a lot more administrative overhead).

The newer SQL Server 2012 and 2014 versions can use "shared storage" via SMB3.0 protocol from a Microsoft 2012 R2 file server - but this is pointless for "always on" connectivity (how will you update the file server without bringing down the SQL cluster?) unless the file services are also clustered - which again cannot yet be done via virtualized VMDK storage except in "cluster in a box" scenarios. (It *can* be done via Hyper-V and the built-in iSCSI Target capability of Server 2012 - but even Microsoft does not recommend doing this in production due to it being a very long I/O chain (high latency) and active-passive design.)

I look forward to the day when I really *can* host my entire environment on virtualized storage, Gostev, I really do - but unless the upcoming vSphere 6 has some unexpected plans to provide better virtualized shared storage support, it won't be happening anytime soon.

[dellock6]

VMware already has the multi-writer VMDK, but sadly it cannot be snapshotted. The day it will be supported with VADP I'll be an happy man. BTW also Oracle RAC uses this kind of disk design.

Luca.

[veremin]

Even now with vSphere 5.5, everything must be done either with in-guest iSCSI or with RDM.

If you have to use RDM due to the said reasons, stick at least to vRDM, as the latter is supported by VB&R, and, thus, VMs having such disks can be backed up. Thanks.

[chrisdearden]

as Luca said , any VM's with bus sharing enabled can't be snapshotted , which means no VADP

[Gostev]

Sadly this is not true, even if I wish it were. One phrase - Virtualized Microsoft SQL clusters. Even now with vSphere 5.5, everything must be done either with in-guest iSCSI or with RDM; there is no support for virtualized shared storage outside "cluster in a box", aka everything on one host. Which is pointless from a DR or even HA perspective.

I look forward to the day when I really *can* host my entire environment on virtualized storage, Gostev, I really do

Well, I am happy to say that your wish came true a couple of years ago, and you really *can* host your entire environment on virtualized storage these days, including SQL servers. What made this possible is called "SQL Server AlwaysOn Availability Groups" feature - this SQL Server deployment model does not require any shared storage. Perfect for virtualized SQL Servers!

[BrettM]

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. Granted this is still a giant leap forward, and many of us would love to use this new feature - but it is only available for SQL enterprise edition, and even then only if you have enough licenses to run two separate clusters, something that is hard for all but the largest and/or well-heeled organizations to afford.

[chrisdearden]

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]

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]

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]

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]

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

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.

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]

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]

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]

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.