Automating Your Pure Storage Infrastructure: Part 2 - Active Port Connections with SDK1

Thu, Jul 11, 2024

Now for step 2 in our blog series, we’ll take a look at the CLI output which will give us the details that we are looking for, so we can work towards our “grouped by host” requirement.

The CLI command which will give us the results we are looking for is pureport list with the “initiator” parameter, and a basic run of this CLI command in an SSH session gives us this output:

OK, this is giving us a good base to start from, as we are getting the beginning details of the initiator connected to the host. Now let’s see what this output gives us when it’s run via New-PfaCLICommand

Hrmm, this is less useful to us, as we are essentially getting back the same text output that would look fine in an interactive console session, but isn’t giving us back anything that we can easily work with. To start adjusting this, let’s see what we get when we add the ‘—csv’ parameter to our CLI command.

OK, while it may not look pretty on the screen, we have output that we can easily tweak to work with as a PowerShell object. Let’s first capture our output in a variable, and then pipe it to “ConvertFrom-Csv”.

Alright, now we’re really making progress here, so let’s capture this output into a variable. We can then confirm that we’re working with a full PowerShell object by taking this output and piping it to “Get-Member”.

In the output from Get-Member we see that we have a TypeName of System.Management.Automation.PSCustomObject, so PowerShell sees this as a custom object. We’re now at a place that we’re more functional with our results and are able to work with them in PowerShell.

However, this same output from Get-Member shows us that the NoteProperty which serves as the headers for our CSV data have a space in them. This will make it slightly more difficult to deal with because we’ll have to wrap each property name in quotes, so let’s get back to our source data from the CLI output and fix that really quick.

If we take a minute to read the documentation - crazy, I know - which is our FlashArray 6.6.0 CLI Reference Guide in this instance, we’ll see that the ‘pureport’ command has another parameter of “—raw” which does the following:

“Displays the unformatted version of column titles and data. For example, in the purearray monitor output, the unformatted version of column title us/op (read) is usec_per_read_op. The –raw output is used to sort and filter list results.”

Let’s see what this does for our output:

OK, we can see that the NoteProperties changed in the output, but let’s confirm this in an easier view with “Get-Member” again.

OK, for some specific examples of how this output is easier to work with, let’s look at two specific NotePropetties. The first changed from “Initiator IQN” to “initiator.iqn”, and the second changed from “Failover” to “target.failover”. Our results are much more specific to work with for any necessary selection or manipulation, should this be required.

This same --raw parameter that we added to our CLI command also serves an additional functions for us, as it allows us to filter the results in our query from the array itself, which also goes to a core tenet of PowerShell with “Filter Left”. This means that we are filtering the results at the source, and we have less extraneous information to deal with in PowerShell.

To cover the last request of filtering out the VMs running iSCSI, all we need to do is to use the --filter parameter in the CLI which the documentation tells us will do the following:

“Displays only the rows that meet the filter criteria specified.”

Now that we know this parameter will filter the results of the source output on the FlashArray, we should understand how this will affect those results. In the perspective of PowerShell, this filter can work in a similar fashion to an if statement, where the only results that have a specific property pass through and are returned to us.

Giving the filter a value of ‘initiator.wwn’ to filter out only the results which have a WWN, thus giving us only our fiber-channel initiators which we are looking for.

We can confirm that our results are filtered down to only results with doing a stare and compare of these results, or we can be a bit more efficient and simply verify the counts that are returned.

The output does give us results which only have a value for ‘initiator.wwn’, which means that we only have our fiber-channel initiators in our results, and the count of our objects decreased from 132 values down to 97 values.

We only have 1 final tweak that we need to make to our filter to also ensure that we have only the active paths, and that is to add ’target.wwn’ to our filter.

If we adjust our filter and get our results again, we can see that we only have values with a WWN for both Initiator and Target, which means it is a live fiber-channel initiator, and the count of our results has only 62 values.

Now, we will just do some cleanup of our code to get the final sample script which looks like this:

$FlashArray = 'sn1-x90r2-f07-27.puretec.purestorage.com'
$FA_Credential = Get-Credential

Import-Module PureStoragePowerShellSDK

$arrayports_command = "pureport list --initiator --csv --raw --filter 'initiator.wwn and target.wwn'"

$arrayports_filter = New-PfaCLICommand -EndPoint $FlashArray -Credentials $FA_Credential -CommandText $arrayports_command

$arrayports_filter_output = $arrayports_filter | ConvertFrom-Csv

Write-Output $arrayports_filter_output

This will give us an output object of the count of active fiber-channel initiators, and we have achieved our first request – which was regular/timed updates for number active paths the customer can send to their NOC to watch these counts of host paths throughout the upgrade.

In the next post, we’ll discuss the second ask from the customer of the detailed output of all host initiators to verify before and after the upgrade.