Validating LUN Path Consistency via PowerCLI
One of my customers needed some help with making some zoning changes on their fiber switches after standing up a batch of new ESXi servers. I already had a script to create 1:1 fiber channel zones on Brocade switches, so that part was easy, but zoning changes to an existing environment are a little scary. As in, if you really mess it up, the storage is going to disappear and every VM is going to crash, scary. Fortunately, you've got to really mess it up to cause an issue, and so this customer was willing to allow changes during business hours as long as we promised not to cause an outage ;)
So, how can I enforce that promise? Well, I've got my script to create accurate zones for the new hosts, but that's not really the dangerous part. If that's messed up, it just means that the new hosts won't work... and since they're still being configured, they're obviously not in production yet. The dangerous part is when you enable the new zones, in case you somehow manage to remove an existing zone from the active config.
As long as you're really careful, you're good, right? Well, yes, but it sure is nice to be sure. So, I always make my zoning changes to one switch first, then check to make sure that my storage availability is unaffected before moving on to the second switch. Rather than just spot checking through the GUI, I decided to leverage an auditing script that I had written previously. This script churns through an environment, examining each fiber channel VMHBA on each ESXi host, and records the total number of LUNs visible through each VMHBA. If one VMHBA sees a different number of LUNs from another, it throws an error (and spits out all of its results at the end).
So, it's pretty easy to use: just invoke the script. It will check each vmhost in each cluster in the environment, spitting out its results. I like to capture those results in a variable, by doing something like $a = check-lunpaths.ps1, so that I can more easily sort through the results in case of a delta that needs investigation.
So, back to current use case, I just fire off this script before making any zoning changes (to establish a baseline), then launch it again after enabling the changes in order to ensure that I didn't break anything. Of course, this will only give me information about the vSphere environment's zoning, but these days that seems to be almost every SAN use case that I come across.
Anyway, the script is below. As always, it's published as is with no implied guarantee, etc. While it worked for me in my situation, that's not guarantee that it'll work for you in yours; as with any script from the internet, test thoroughly before using it!
So, how can I enforce that promise? Well, I've got my script to create accurate zones for the new hosts, but that's not really the dangerous part. If that's messed up, it just means that the new hosts won't work... and since they're still being configured, they're obviously not in production yet. The dangerous part is when you enable the new zones, in case you somehow manage to remove an existing zone from the active config.
As long as you're really careful, you're good, right? Well, yes, but it sure is nice to be sure. So, I always make my zoning changes to one switch first, then check to make sure that my storage availability is unaffected before moving on to the second switch. Rather than just spot checking through the GUI, I decided to leverage an auditing script that I had written previously. This script churns through an environment, examining each fiber channel VMHBA on each ESXi host, and records the total number of LUNs visible through each VMHBA. If one VMHBA sees a different number of LUNs from another, it throws an error (and spits out all of its results at the end).
So, it's pretty easy to use: just invoke the script. It will check each vmhost in each cluster in the environment, spitting out its results. I like to capture those results in a variable, by doing something like $a = check-lunpaths.ps1, so that I can more easily sort through the results in case of a delta that needs investigation.
So, back to current use case, I just fire off this script before making any zoning changes (to establish a baseline), then launch it again after enabling the changes in order to ensure that I didn't break anything. Of course, this will only give me information about the vSphere environment's zoning, but these days that seems to be almost every SAN use case that I come across.
Anyway, the script is below. As always, it's published as is with no implied guarantee, etc. While it worked for me in my situation, that's not guarantee that it'll work for you in yours; as with any script from the internet, test thoroughly before using it!
Comments
Post a Comment
Sorry guys, I've been getting a lot of spam recently, so I've had to turn on comment moderation. I'll do my best to moderate them swiftly after they're submitted,