I had the task of replicating an existing customers filer to their new DR system. This was quite a large system, and as much as creating SnapMirrors isn’t particularly complex, it is time consuming. So as with many things I do, I wrote a script to help my achieve this task quicker, and go have yet another coffee.

You’ll need pre-shared keys setup (as ever), but the rest is prompted for. There’s no data validation (no surprise). The script will output 4 text files, one for creating/restricting all the volumes, one for the “snapmirror.conf”, on to be used in place of “snapmirror.conf” while you are doing the baseline initialization, and finally one to actually initialize the snapmirrors. There’s no intelligence around concurrent streams, so initialization is still a bit of a juggling act and waiting game.

Please let me know if you find this useful.

#!/bin/bash

echo “Please enter the name of the PRIMARY filer: ”
read PRI_FILER

echo “Please enter the name of the DR filer: ”
read DR_FILER

ConnectString=”ssh -c 3des”
#ConnectString=”rsh”

SnapMirrorHour=22
SnapMirrorMinute=0
SnapMirrorStagger=5

echo “” > ${DR_FILER}_filer_volumes.txt
echo “” > ${DR_FILER}_snapmirror.conf
echo “” > ${DR_FILER}_sm_initialize.txt
echo “” > ${DR_FILER}_snapmirror_init.conf

for AGGR in `${ConnectString} $PRI_FILER “aggr status” | awk ‘$2!~/State/{print $1}’`
do
 SIZE=`${ConnectString} $PRI_FILER “df -Ah $AGGR” | sed ‘s/\([0-9][KMGT]\)B/\1/g’ | awk ‘$1!~/.snapshot|Aggregate/{print $2}’`
 for VOL in `${ConnectString} $PRI_FILER “aggr show_space $AGGR” | awk ‘$1!~/Space/{print $0}’ | awk ‘$4~/volume|file|none/{print $1}’`
 do
  echo “vol create ${VOL} -s none ${AGGR} ${SIZE} ” >> ${DR_FILER}_filer_volumes.txt
  echo “vol restrict ${VOL}” >> ${DR_FILER}_filer_volumes.txt
  echo “snapmirror initialize -S ${PRI_FILER}:${VOL} ${DR_FILER}:${VOL}” >> ${DR_FILER}_sm_initialize.txt
  echo “${PRI_FILER}:${VOL} ${DR_FILER}:${VOL} – ${SnapMirrorMinute} ${SnapMirrorHour} * *” >> ${DR_FILER}_snapmirror.conf
  echo “${PRI_FILER}:${VOL} ${DR_FILER}:${VOL} – - – - -” >> ${DR_FILER}_snapmirror_init.conf

  SnapMirrorMinute=`expr $SnapMirrorMinute + $SnapMirrorStagger`  Read more... (328 words, estimated 1:19 mins reading time)

Excuse the absence in both presence and posts. It’s been a roller-coaster past year with personal injury and flat-out work schedules, so I have had little time or motivation to blog or show my face around the communities. My apologies, and I am determined to break this habit and get back into things once again! But enough of the chatter, get on with the writings…

This isn’t something I see very often, but when I do, it’s interesting to see the stats speak for themselves. I’m with a customer who had a scripted deployment of their NetApp estate a few years ago, and it wasn’t designed or delivered with too much care or attention (something I want to discuss another day). They have a VMware estate with SQL, Exchange and other things. It all runs across a total of over 100 15k FC spindles. It’s not a huge estate in comparison with other sites, so I’m intrigued into why they have such performance issues.

Now when you run through “sysstat –u”, you can see that the filer itself is doing very little, quite happily getting on with what it should do. But the disk is hitting 100% quite often. Immediately this shows a disk problem. They need more spindles, obviously?

Firstly there is an imbalance of spindles. They have a second aggregate on the partner controller that only has test volumes. I get permission to remove this and hot, I re-allocate these to the other controller and expand the existing aggregate. This doubles the spindle count, but I know it’s not going to do anything for existing performance (in that the data won’t automatically redistribute itself!).  Read more... (799 words, estimated 3:12 mins reading time)