Work

At some point in the last few weeks, I repeatedly had to recreate my Nagios config for currently six filers. After doing that a few times, I ended up (like sooo often) writing a short Bash script, that’ll do this for me - without any fuss. The only thing the script needs, is that the filers and the filers are registered in DNS … Here’s an example: 1 2 3 4 fas3240a IN A 172.31.76.150 fas3240a-sp IN A 172.31.74.150 fas3240b IN A 172.31.76.151 fas3240b-sp IN A 172.31.74.151 With that done, the script will create the necessary Nagios config for those filers.

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.

After rebuilding two MDS9148, I wanted them to correctly switch the summer/winter time for my time zone. Currently I’m in CET (or CEST during the summer), so I googled for that. The search came up with Cisco-FAQ, however that needed a slight adjustment. Apparently the NXOS doesn’t support the feature “recurring” in the clock configuration. So I had to slightly adapt the configuration line: 1 2 clock timezone MET 2 0 clock summer-time MET 5 Sun Mar 02:00 5 Sun Oct 03:00 60

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. ...