After figuring out the SnapVault stuff, I needed to implement a whole bunch of SnapMirror relations. As I am lazy (as in click-lazy), I ended up writing a somewhat short Bash script, that’ll either establish a bunch of SnapMirror relations (for a single host) or just for a single volume. The script expects, that SSH public key authentification has been set up, and that the source for the SnapMirror exists and is online/not-restricted.
Well, the name says it pretty much. Once you rename the snapshot on the SnapVault destination from daily.0 to something else, the whole builtin SnapVault snapshot retention isn’t gonna work anymore. Back when I started all the code-writing, I wasn’t aware of this. One of my co-worker complained to me about it on Wednesday that there are an assfull of snapshots on the SnapVault destination (one snapshot each day since the end of October, meaning more than 50 snapshots per volume, in a total of 12 or so FlexVolumes, making the total about 500 snapshots). So I took the time to write this little Bash script (yeah, I know I’m mixing a bunch of languages - I really like the KISS principle), which will get the necessary information from the filer (snapvault snap sched needs to be set) and then deletes the over-aged snapshots.
The MSSQL admins decided to dump the SMSQL Snapinfo stuff on a separate volume, that SMSQL also snapshots. Same as before, I need a PowerShell script that’ll archive the snapshot and rename it.
And here’s the script for SMO. However, since different people administrate the Oracle Databases, they don’t want me to tinker with the database like the MSSQL admins. They give me a CSV-list of volumes, that should be backed up and I work with that.
Well, yesterday I got pissed of those Virtual Storage Console custom attributes. Currently we don’t use the Provisioning & Cloning feature of the VSC, thus we don’t need the custom attributes. After poking around, I decided to write a short PowerCLI script to do the task. It’s really rather simple, so here goes: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 param( [string] $vCenter ) # Add the VI-Snapin if it isn't loaded already if ( (Get-PSSnapin -Name "VMware.VimAutomation.Core" -ErrorAction SilentlyContinue) -eq $null ) { Add-PSSnapin -Name "VMware.VimAutomation.Core" } If ( !($vCenter) ) { Write-Host Write-Host "vcenter-remove-vsc-attributes: <vcenter-server>" Write-Host Write-Host " <vcenter-server> - DNS name of your vCenter server." Write-Host exit 1 } Connect-VIServer -Server $vCenter Remove-CustomAttribute -CustomAttribute "PnC.CustSpec", "PnC.Deployed", "PnC.GroupID", "PnC.Source" -Confirm:$false Disconnect-VIServer -server $vCenter -Confirm:$false
I’m working on a project right now, providing a SnapVault target for our “big” NetApp. So we moved our 3240 to it’s target location, I spent most of my time yesterday doing the cabling (SAS and ACP, as well as power). I’m still not finished, I still need to " beautify" the power cables, need to fix the network cables (currently I don’t have none ….) and some other minor stuff. But lemme skip back a bit. ...
Well, I’m in a situation, where I need to move all volumes from one controller to two others. So I looked at the ways I had available: Freshly implementing everything: No option at all! vol copy: Is rather slow, thus no option ndmpcopy: That’s exactly what I needed! ndmpcopy is a great way to copy over a whole volume including it’s files (thus FCP luns) to another volume/controller. First I threw in a crossover cable, since at around 6 PM our backup system starts it’s daily run, and everything else running via IP in between 6 PM and 6 AM is seriously impaired by this. Configured the additional ports on all three controllers (picked a private, not-routed range just in case) and then kicked of a simple bash script that ran the following: ...
Well, as you might know I’ve been tinkering with a NetApp FAS at work. The last few months, I’ve been trying to figure out a few things, which I actually did. One “error” I ran into with creating the lun’s and volumes by hand was that the volumes were running out of space. Even if the volume was a bit larger than the LUN. After that happened a few times, I decided to see how to fix that. As it turns out, the GUI “fixes” that already in a way I wouldn’t have expected. ...
Well, we recently upgraded the SnapManager version on our test box to 6.4.1. Now however, after restarting the box the SnapManager service failed to start … The error was something like this: Now, first I stumbled upon this NetApp Community post, which only contained the “solution” to increase the global! wait time for services. That didn’t sit well with me. So after looking through NOW! for a bit, I actually found the correct way. The fix is described in KB2010835. Yet again, another certificate error. Why do vendors deploy SSL certificates, when they use untrusted ones, which defeats the purpose of SSL certs or at least “brings up” users to ignore any error message they get concerning SSL certificates ? ...
As promised in the earlier post, for completeness sake, here’s the counterpart for removing the LUNs in the first place. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 #!/bin/bash KEY_FILE="/root/.ssh/netapp.dsa" SSH_OPTS="/root/.ssh/netapp-ssh_config" if [ $# -ne 2 ] ; then echo "fas-remove-lunmap: FAS_CONTROLLER TARGET_IGROUP" echo echo "Remove every mapped lun from the target igroup (for example reinstallation)" echo echo " Usage:" echo " - FAS_CONTROLLER: Hostname/IP-adress of the DATA ONTAP controller" echo " - TARGET_IGROUP: igroup that is actually modified" echo exit 1 fi FAS_CTRL=$1 TARGET=$2 ssh_fas() { # $@: commands for Data ONTAP COMMANDS="$@" /usr/bin/ssh -i $KEY_FILE -l root -F $SSH_OPTS $COMMANDS } # Get the hostname of the controller, necessary for the reporting CTRL_HOSTNAME="$( ssh_fas $FAS_CTRL rdfile /etc/rc | grep ^hostname | cut -d -f2 | tr 'a-z' 'A-Z' )" #set -x # Get the lun list. for lun in $( ssh_fas $FAS_CTRL lun show -g $SOURCE | awk '{ print $1 }' | sort -u ); do # If the LUN id is 0, skip otherwise we would remove the boot LUN if [ "$LUN_ID" != "0" ] ; then # Actually remove the mapping to our host echo "Removing $lun from $TARGET" ssh_fas $FAS_CTRL lun unmap $lun $TARGET fi done #set +x With that, you can simply run it against a NetApp controller and remove every LUN map except the one with LUN ID 0 (which is pretty handy when installing/reinstalling ESX servers).