JJ,
Step 1 will be to confirm with the NetApp Interoperability Matrix Tool (http://support.netapp.com/matrix/) that the configuration above is supported. You will also need to ensure that the storage controller (FC/FCoE HBA, iSCSI HBA, iSCSI software initiator, etc.) are supported as well. I suggest using the IMT to first confirm that the OS, DSM/MPIO, and Data ONTAP versions are compatible. This will tell you which version(s) of the Host Utilities Kit (HUK) and other components are certified to interoperate correctly. If you are using an HBA, it is *essential* that the firmware and driver of the HBA match the versions on IMT *exactly.* I once used a newer firmware/driver combination than recommended and had unexpected problems. When I opened a support ticket with NetApp, I found out that the newer firmware/driver combo was not approved on the IMT because NetApp's internal testing had found bugs with that combination. After you have identified the correct supported configuration for the Windows OS, I suggest using the IMT to determine the supported versions of SnapDrive and SMSQL that match the OS support information. Sometimes, this necessitates using a slightly older version of some components.
Once you have confirmed the supported versions of the components, the next step will be following the best practices guide for SnapManager for SQL You should also consult the best practices guides for SnapDrive and for MS-SQL on NetApp storage. For example, here is a best practices guide for MS-SQL on NetApp storage from 2010 -- http://www.netapp.com/us/media/tr-3821.pdf. And here is a best practice guide for SMSQL with SnapDrive 7.0 on CLustered Data ONTAP -- http://www.netapp.com/us/media/tr-4225.pdf.
In a nutshell, your volumes should be arranged based on their workload and their disaster recovery value. For example, MS-SQL uses its TempDB to store temporary information while the database calculates a response to a query. If MS-SQL is restarted or moved between nodes of the cluster, MS-SQL will discard the TempDB data. As a result, the TempDB data has *absolutely no disaster recovery value.* However, the TempDB can require a lot of storage I/O and possibly require a lot of storage capacity. For these reasons, the TempDB LUN should be in a volume by itself. That way, if a snapshot is taken of the database, the TempDB LUN will not be included in the snapshot.
My recommendations for deploying MS-SQL failover clusters on a NetApp filer would be....
- One and only one LUN per volume
- A separate LUN for MS-SQL database data files (*.MDF, *.NDF).
- A separate LUN for MS-SQL database log files (*.LDF)
- A separate LUN for MS-SQL TempDB files
- A separate LUN for the SMSQL snapinfo information
- Older versions of MS-SQL installed MS-SQL binaries and the MS-SQL master, model, and system databases to a cluster shared drive. With MS-SQL 2008 R2 and later, the SQL binaries install to the local storage of each Windows server. In that scenario, I recommend putting the master, model, and system databases on the same volume as the MS-SQL database data files.
if you will be creating several database instances within the cluster, you may want to consider using NTFS mount points to conserve drive letters. In one instance, I configured a 4-node Windows cluster with 3 SQL instances. We limited our LUNs to 2TB for replication purposes (if replication breaks and must be reinitialized, very large LUNs can become very difficult to replicate). The result was that we nearly ran out of drive letters.
I hope this has got you started in the right direction. If you have additional questions, please let me know. I have been building MS-SQL clusters on NetApp storage for about 7 or 8 years.
-- Bill
