As I'm preparing to deploy a new 2-node SQL Server 2014 Standard failover cluster, I'm considering what would be the best way to set up its storage. For the reference, OS will be Windows Server 2012 R2 on top of vSphere 5.5, and the storage will be handled by a NetApp FAS2552 running clustered Data OnTap, which supports SMB 3.0. Network (both storage and data) is 10GbE, with four ports per virtualization host. As far as I can tell, I have three options:1) Traditional iSCSI. Give each cluster node two extra vNICs connected to the two iSCSI VLANs (I do not want to use RDMs for a variety of reasons), install MPIO, activate iSCSI initiator, install SnapDrive, provision shared LUNs, set up the clustered instance. The advantage of this method is familiarity - we've been working with such setups for years now, with SQL 2005 and 2008/R2 on top of Windows Server 2008/R2, and while it has its quirks, it works reasonably well. Main disadvantage is relatively long failover time, as database engine is shut down, LUNs are dismounted, then re-mounted on the other node, and database engine is brought up.2) iSCSI with CSV. A new possibility brought by SQL 2014, I assume that it would speed up the failover process by removing the need to dismount and re-mount the LUNs, but having never worked with CSV, and this being an effectively v1 option, I'm somewhat wary of it. Also, I'm not sure whether or not it is supported by NetApp SnapManager for SQL - documentation doesn't mention it one way or the other.3) SMB 3.0. SQL 2014 being the second version of SQL to support SMB shares for database storage, I suppose it's a bit more mature than CSV. It would also significantly reduce management complexity, as databases would sit directly on WAFL, without a LUN container and an additional filesystem in the way, and backups would be as simple as doing a robocopy against \\filer\share\~snapshot\recent (an application-consistent snapshot generated by NetApp SnapManager). ODX and single file flexclone would make the admin's life a lot easier too. On the other hand... it's still SMB, and NetApp doesn't support SMB multichannel, leaving redundancy to the network layer, so a potential switch failure will have to be mitigated by both the filer (moving the SMB logical interface to a surviving port) and the ESXi host (executing a VM port group failover), and while Microsoft and NetApp may swear up and down about SMB 3.0 resiliency, and Juniper EX4550 are very reliable switches, I'd still sleep better at night knowing that the host OS is aware of dual independent paths to storage.Opinions?
↧