This SnapManager for SQL case study was conducted for a real world client. Anything in this study that could identify the client has been removed from the article to protect their business. I wanted to take this opportunity to document the procedures and explanations for sizing such an environment.
This particular implementation involved a three node SQL Server 2012 AlwaysOn Availability Group running on Server 2008R2 physical servers. The databases are new and haven’t been populated with data, yet, so the sizing had to take these “known unknowns” into account. SnapManager for SQL 6.0 and SnapDrive for Windows 6.5 were used. The NetApp system includes a FAS3220 in an HA pair running Data ONTAP 8.1.2 7-mode.
Typical best practices were used such as using volume autogrow, letting SnapManager take care of Snapshot deletions, etc. I don’t address thin provisioning, deduplication, or space reservations in this document beyond saying that Fractional Reserve is kept at its default 0% and SnapReserve is changed to 0%. I suggested the LUNs and volumes be thinly provisioned because the client has a trained and dedicated NetApp Administrator on staff with the tools and alerts necessary to manage aggregate capacity properly. The storage deployment is a new, mid-size deployment and capacity is already at a premium. Thin provisioning now, monitoring, and growing or shrinking volumes and LUNs as actual growth is observed was advised so as not to waste space. Deduplication was used on the database volumes and CIFS shares – not the transaction logs, SnapInfo, TempDB, or System Databases.
A logical diagram of a SQL Server replication scheme is show below. There is an OLTP database that is relatively large compared to the many smaller databases that comprise the Data Warehouse (DW). Each Primary Replica will be at Site A hosted, under normal conditions, on separate nodes. These nodes will then synchronously replicate within the same site to the other node. Asynchronous replication will happen across sites to Site B and a third node.
I first had to do this at the direction of NetApp tech support. Ever since, I found myself searching my email for it so I could use it again and again. I finally took the hint and decided to post it here for my reference – but maybe you could use it as well. Oh, and copy it to Evernote, too.
They way I use this, as you might expect, is to start the capture, perform the operation that’s failing, and then stop the capture. So as not to capture too much traffic and therefore have to wade through all of it, I try to perform those steps rather quickly. But then again, if you know a few useful features of Wireshark, you can get around in the capture file pretty easily. So here you are.
filer> pktt start all -d /etc/crash
<perform the operation that fails here>
filer> pktt dump all filer> pktt stop all
Snapshots are enabled by default when a volume is created. They follow the schedule as seen from the CLI command snap sched: 0 2 6@8,12,16,20
and from the System Manager GUI. Note the default Snapshot Reserve is 5% and that the checkbox for Enable scheduled Snapshots is checked by default.
I ran across an issue today that my various sources of troubleshooting (ok, Google) couldn’t help solve – at least not directly. I configured SnapMirror between two disparate systems for a data migration. 16 of the 17 volumes initialized just fine, but I was getting an error on the one volume that had a LUN inside. It was a SnapDrive for Windows LUN, so I knew that just prior to the final cutover I’d have to take a Snapshot via SnapDrive, but I should be able to start the baseline transfer via the standard CLI. Here’s what I was seeing:
ControllerA> snapmirror initialize -S ControllerZ-vif01:vol_server2008 ControllerA:vol_server2008 Transfer started. Monitor progress with 'snapmirror status' or the snapmirror log. Mon May 13 14:21:26 CDT [ControllerA:replication.dst.err:error]: SnapMirror: destination transfer from ControllerZ-vif01:vol_server2008 to vol_server2008 : process was aborted.
I was asked by a client yesterday in passing how to check CPU utilization on one of their NetApp filers. I didn’t immediately know where to go and we quickly moved on to something else. So as I was showering this morning, as I do many mornings, I remembered that, of course, you can use sysstat to view performance data. Anyways, this is a real nice way to view instantaneous general performance data. Options for this command are shown below.
deathstar> sysstat ?
usage: sysstat [-c count] [-s] [-u | -x | -m | -f | -i | -b] [interval]
-c count – the number of iterations to execute
-s – print out summary statistics when done
-u – print out utilization format instead
-x – print out all fields (overrides -u)
-m – print out multiprocessor statistics
-f – print out FCP target statistics
-i – print out iSCSI target statistics
-b – print out SAN statistics
interval – the interval between iterations in seconds, default is 15 seconds
I had the opportunity to configure SnapMirror for a client today and it gave me a bit of a headache. I did what I thought was my due diligence: reading the relevant vendor documentation for SnapMirorr for each version of Data ONTAP, 7.3.2 and 8.0.3P3. What I failed to do was read a few lines further than I actually did – I missed a simple piece of syntax that turned a 30 minute WebEx into a 2 hour ordeal. I learned a good lesson about SnapMirror during this engagement, though, and I’d like to share it.
The SnapMirror of these three volumes were actually for a data migration because the source filer is being decommissioned. The general steps required in the engagement today were as follows:
<> Run a cable between what will be the dedicated replication links on each filer
<> Configure each interface with IP settings
<> Ensure SnapMirror is licensed and enabled on each filer
<> Configure /etc/hosts and /etc/snapmirror.allow files on source filer
<> Configure /etc/hosts and /etc/snapmirror.conf files on destination filer
<> Initialize the baseline replicaction
Edit: To jump to the good stuff, check out Neil Anderson’s free eBook, How to Build a NetApp ONTAP 9 Lab for Free!
I’d like to share quick note about my experience in studying for and taking the NetApp Certified Data Management Administrator exam for Data ONTAP 8.0 7-Mode, NS0-154. Perhaps someone out there will find the links and study methods here useful .
I’ve never held a pure Storage Administrator position, but I did recently complete a year-long contract implementing NetApp FAS3240 and FAS3270 filers as part of an Enterprise Virtualization Project for the US Army in Southwest Asia. I was actually hired as a Network Engineer to install, configure and migrate to Cisco Nexus 5020s and 2224 Fabric Extenders, but coming from a Systems background, I was able to perform the role of Implementation Engineer for the VMware, NetApp, and Nexus environments. It was a very satisfying role overall and one in which I gained a lot of varied experience.