This document is background on our work with Microsoft Opalis Server. You can read more about this on our blog.
Scenario 1 is a very simple scenario. The only thing interesting here is that we are using the PowerShell toolkit from within Opalis. This example only exists to show the most basic building block of Opalis integrations working with our tookit. In this scenario, we create a lun via a clone command and then mount that lun on host X.
First, we import the dataontap module. This is required by the PS Toolkit.
Then we connect to a controller. In this case, we use the IP address.
Next we run New-NALunClone. We create a new LUN called NewFromOpalis from a lun called V-SCVMM_Data using a snapshot called test.
We then map this lun to an existing iGroup. We cheat a bit in that we have already created an iGroup for each of our hosts and the name of the iGroup is the host name -LUNS. In the Video, this is P1-LUNS. Notice that we are using Opalis to hand us the server name in this case.
Lastly we turn space reserved off for the new LUN. This is to be sure we're not holding space on the volume that we don't need.
Scenario 2 is a bit more complex. In this case, we're replicating production data down into a test lab using LUN cloning. This means that the production database does not need to go offline. You may notice that the diagram above is different than the video. This is because during further testing of this scenario, we found that calling windows diskpart | "rescan" only worked about 75% of the time. Because this was a test server, we decided to change the workflow a bit and simply reboot the test server as part of the workflow. This guarantees that the LUN is mounted cleanly and that SQL starts again at the end. In general, windows doesn't take kindly to having it's disks removed while the OS is running so this is probably a good policy in general. Adding disks is fine, but taking them away may require a reboot.
Remove LUN Source Code:
$confirmpreference = "none"
Remove-NaLunMap -Path /vol/SAN_Vol/FromPSLun -InitiatorGroup viaRPC.iqn.1991-05.com.microsoft:v-sql.msbu.netapp.com
Remove-NaLun -Path /vol/SAN_Vol/FromPSLun
The first line is to supress the confirmation prompt which Opalis doesn't know how to deal with. the next two lines are the same as scenario 1.
In this case, we simply remove the LUN Map from the iGroup (which we know because we attached the lun in the first place). You have to remove the map before you can delete the LUN.
Then we call Remove-NALun and delete the LUN.
Clone LUN Source Code:
$clone = Start-NaClone -SourcePath /vol/SAN_Vol/SQL2_Lun_1 -DestinationPath /vol/SAN_Vol/FromPSLun
$status = Get-NaClone $clone
start-sleep -s 1
} while ($status.clonestate -eq "running")
Again, we load the dataontap module and connnect to the controller.
We then use the Start-NAClone command to begin the clone process. Note that in this case we are not starting from a snapshot but rather taking the snapshot on the fly as part of the clone operation. This will produce a crash-consistent snapshot which was fine for this demo. If you want an application consistent copy you will need to configure SnapManager for SQL to take regular backups and then use one of these application consistent snapshots as the basis for your clone.
The do loop simply waits for the satus to change from running. Start-NAClone is an asynchronous operation so you can't proceed to the next step without checking the status of the clone via the get-naclone command in the do loop.
Mount LUN Source Code:
Add-NaLunMap -Path /vol/SAN_Vol/FromPSLun -InitiatorGroup viaRPC.iqn.1991-05.com.microsoft:v-sql.msbu.netapp.com
Same here to load and connect.
The add-nalunmap just adds the correct iGroup to the new lun. Note that the LUN is the same as the clone command above and the iGroup is the same as the first command that removed the old lun.
Scenario 3 is a completely different animal. In Scenario 3, we created our own OIP and called the Data ONTAP SDK directly. We did this in VB.Net for simplicity's sake.
When creating and OIP, you must import the appropriate Opalis modules and you must implement their methods in order to make the OIP work. There are several examples in the Opalis QIK and we used these to get started. The source code for this project is too long to paste here but we have attached the project in a zip file.
Scenario 4 is our most complex scenario so far. Because we are integrating with System Center Service Manager, we are using the new OIP that is part of the 6.3 beta. We are also using some custom OIPs here to control the SnapMirror relationship The source code for these OIP's is included below in the NASnapMirror.zip file. We are also using the PowerShell toolkit to mount the LUN and we are using the native WMI control to check for the disk mount event.
Let's take them step by step.
In this case, we are simply waiting for a change request object to be created in SCSM. In a production environment, you would probably create a custom change request and you may want to add an approval step. We did not do this here in the interest of brevity.
Shut down SEA VM:
We are using the Hyper-V PS library from Codeplex. This is a great library if you're working with Hyper-V and we highly recommend it. Here's the script. There's nothing new here from a NetApp perspective, we're just using the functionality already provided by MSFT.
Invoke-VMShutdown -VM SEA* -Server P-03 -Force
Note that we're taking advantage of our naming convention here so any VM's added called SEA- will be included. Very handy.
This is our first OIP. We are using this OIP to call the Update Mirror command from the ONTAP SDK. You can get the SDK from the communities site. Again, sample code is below.
Get Status, Quiesce, Break Mirror:
These three are almost identical to Update mirrror. They are just calling different parts of the API.
We're using the PS Toolkit here to make a simple call. Here's the script.
connect-nacontroller <<your controller here>>
Add-NaLunMap -Path /vol/<<Your LUN HERE>> -InitiatorGroup <<Your iGroup Here>>
The simplest way we've found to rescan disks from Opalis is to just send a command line. This is not the most elegant method, but it works. We use the command line OIP and send a DISKPART command with a script file that does the rescan.
Check New Disk:
This one is a bit better. We're calling WMI using the built in OIP. We're looking for the disk object to show up. Here's the screen shot:
Then we wait for the string to contain the new disk:
Once this string contains the new PHYSICALDRIVE, then we know the mount was successful.
This is just a diskpart command again.
Start TAC VMs:
This one is a PowerShell script:
New-VM "TAC-EX1" -server P-02
Set-VMMemory -VM "TAC-EX1" -Server P-02 -Memory 3GB
Set-VMCPUCount -VM "TAC-EX1" -Server P-02 -CPUCount 2
Add-VMNIC -VM "TAC-EX1" -Server P-02 -VirtualSwitch "Network 1"
add-vmdisk -VM "TAC-EX1" -Server P-02 -LUN 0 -ControllerID 0 -Path e:\vms\SEA-EX1.VHD
Start-VM -VM "TAC-EX1" -Server P-02 -force
New-VM "TAC-SP1" -server P-02
New-VM "TAC-SQL1" -server P-02
add-vmdisk -VM "TAC-SP1" -Server P-02 -LUN 0 -ControllerID 0 -Path e:\vms\SEA-SP1.VHD
add-vmdisk -VM "TAC-SQL1" -Server P-02 -LUN 0 -ControllerID 0 -Path e:\vms\SEA-SQL1.VHD
Start-VM -VM "TAC-SQL1" -Server P-02 -force
Start-VM -VM "TAC-SP1" -Server P-02 -force
Again, we're using the Hyper-V module from Codeplex. Note that we're creating a new VM each time. We do this because it gives us the maximum flexibility and still allows us to re-use the existing VHD file.
This NetApp Community is public and open website that is indexed by search engines such as Google. Participation in the NetApp Community is voluntary. All content posted on the NetApp Community is publicly viewable and available. This includes the rich text editor which is not encrypted for https.