Forum Discussion

david_schramm's avatar
david_schramm
Day Hiker II
2 months ago

relationship between clusters and host groups

Due to circumstances beyond my control, over time and several upgrades of vSphere, there is no longer any commonality between the clusters in vSphere and what I see as host groups in the FlashArrays. So, my question is - does the API figure things out one way or another OR is my assumption that in the ideal world the clusters of hosts in VMware should match the host group names and such in Pure land? Basically some folks played shell games and since the zoning allowed it, lots of things don't line up like I once had them. I am unsure of the best way to make them sane again. 

thanks!

vmware
VSPHERE

8 Replies

  • Garry's avatar
    Garry
    Day Hiker III
    2 months ago

    Short answer: 

    FlashArray API doesn’t “figure it out” from vCenter. It’s deliberately agnostic. In the ideal (and supported best-practice) world, each vSphere cluster maps 1:1 to a FlashArray host group, and each ESXi host maps 1:1 to a FlashArray host object with its initiators. That alignment makes provisioning, automation, and LUN ID consistency dead simple. 

    What “sane” looks like

    • One FA host object per ESXi host, populated with the host’s FC WWPNs or iSCSI IQN. 
    • One FA host group per vSphere cluster (per array), containing those host objects; present shared VMFS datastores to the host group so every node sees the same LUN number. 
    • vVols nuance: you still map the Protocol Endpoint (PE) to the cluster’s host group; VASA handles per-VM vVol binding.
    • If you use the Pure vSphere Plugin, it will create/update the matching host/host-group objects for you when you provision (and it keeps LUN IDs consistent across hosts). 

    Safe(ish) way to get back to sane (no outages)

    The one hard rule: don’t rip a host out of its current host group without planning—that instantly drops access to any volumes presented via that group and can trigger PDL on the ESXi side. 

    A pragmatic, step-by-step approach:

    Inventory reality
    From FlashArray: list hosts, host groups, and connections (which volumes are connected to which host/host-group).

    From vCenter: list clusters and member hosts (and which datastores they’re using).
    The FA API and SDKs expose all of this; you can script it in PowerShell SDK v2 or Python. 

    • Define target state
    • Decide your naming (e.g., host objects = ESXi shortnames; host groups = cluster names).
    • Create any missing host groups that mirror clusters; create any missing host objects for ESXi hosts. (The Pure Plugin or Cody’s helper cmdlets can scaffold this for you.) 
    • Migrate host membership one host at a time
    • For each ESXi host, temporarily connect the currently-used datastore volumes directly to the host (host-level connections) so the host continues to see its LUNs even after you change groups. 
    • Move the host into the correct host group (the one that matches its vSphere cluster).
      Connect the same datastore volumes to the new host group, confirm the host sees the new group-based paths and stable LUN IDs, then remove the temporary host-level connections. (FA supports connections to hosts and host groups; group connections keep LUN IDs identical across the cluster.)

      Repeat for the next host.

    For vVols
    Ensure the Protocol Endpoint is mapped to the cluster’s host group; datastore(s) will enumerate via VASA automatically.

    Provisioning going forward
    Use the Pure vSphere Plugin to create/expand datastores; it will place volumes on FA and connect them to the right host group automatically—no more shell-games. 

    Quick audit helpers

    Pure vSphere PowerShell module & SDK2: there are cmdlets and examples that build FA host/host-group objects straight from vCenter clusters (e.g., New-PfaHostGroupFromVcCluster), and SDK2 samples for managing hosts/host groups. 

    https://blog.purestorage.com/purely-technical/configuring-an-esxi-cluster-for-storage-provisioning-for-a-flasharray-via-powershell/

    • david_schramm's avatar
      david_schramm
      Day Hiker II
      2 months ago

      Hi guys, thanks for all the suggestions. To clarify more and not throw anyone under the bus - if anyone has worked with "composable infrastructure", it allows people to rebuild blades and sometimes the WWPNs don't always remain. In most cases the WWPNs are still aligned with host names. The problems I see are that they decided to A) rename clusters and B) sometimes rename hosts and C) moved hosts between renamed clusters. All this came about largely due to not doing in-place vSphere upgrades but each "major" upgrade was a greenfield and thereby left to the whims of the virtualization team to build things "different" than was seen in the old vCenters, so, at one time I had everything 1:1 matching clusters to host groups, names, etc. and I (previously) did all provisioning via the plugin (because why wouldn't you). But over years (I delegated much, took eyes off the environment some) and several upgrades it is no longer recognizable to me and yes, I suspect I will have to methodically go through each environment to verify WWPNs match hostnames, etc. The plugin seems to be able to do the basics - resize datastores for example but I'm leery of updating host groups and removing/adding hosts because of the disconnect. Another example - as you know clusters can have spaces in names - host groups (at least from what I see in 6.5 purity) so "how does it know?". Should I convince the VMware team to standardize and name-match or what?

      thanks

      • Garry's avatar
        Garry
        Day Hiker III
        22 days ago

        Yeah, that makes perfect sense,  gear can definitely throw things off once WWPNs and hostnames start drifting. What you’re seeing happens a lot when teams rebuild vCenters and clusters instead of upgrading in place. The Pure plugin really depends on consistent naming and WWN alignment, so once that’s gone, it’s smart to be careful about using it for host group changes.

        If you can, get the VMware team to standardize names again and use  same cluster and host naming across vCenter and the array. It’ll make the plugin usable and predictable. In the meantime, I’d pull a current WWPN list from both sides and clean it up manually. Once you’ve got that alignment back, it’ll save a ton of confusion later.

        Purity 6.5 doesn’t like cluster names with spaces. Stick to clean alphanumeric names if you can. Until things are standardized, I’d handle host group edits directly from the array CLI or REST rather than through the plugin.

        Try to push for naming consistency. Once that’s fixed, everything else (plugin ops, automation, reporting) falls back into place. Also push for change management and CMDB changes - that will make your life easier....

        Last advise, if people do not know how to use plugins, do not allow access...

  • alex_carver's avatar
    alex_carver
    Puritan
    2 months ago

    david_schramm​, There are a couple parts that I'd look through to see what kind of drift you have here.  Is it just drift or outdated information at the host name and host group level?  

    General best practice would be that each ESXi initiator would map directly to a single FlashArray host object.  Then each ESXi cluster would map directly to a single FlashArray host group object.   Ideally the name of the ESXi cluster would be the name of the FA host group, and the hostname of the ESXi host would be the name of the FA host, but names can change and it's usually not too big of an issue.  

    Or is the issue that ESXi inits have moved in and out of ESXi clusters or between vCenters?  In which case the hosts on the array were not moved out of one host group and added to another host group?  And now you have hosts in the wrong host groups and unable to mount to the VMFS datastores?

    The other more complicated drift issue is if the host ports on the FA host object are not correct.  This can happen if FC cards are changed or moved between hosts, for iscsi if re-imaging happens or host names change.  Or it can happen where you have host ports from several ESXi inits added all to a single FlashArray host object?  

    But if it's esxi name to host name drift, the objects can be renamed fairly easily.  If it's an issue with ESXi hosts being in the wrong host groups, then it's a little tricky to fix, but is generally safe to move hosts to the correct host groups by putting the hosts into maintenance mode, sometimes unmounting them from the current datastores on those arrays, and then moving them to the correct host groups and remounting them.  

  • catud's avatar
    catud
    Community Manager
    2 months ago

    Hi David, thank you for submitting your question to the community forums!

    We are currently reaching out to the right experts at Pure to get back to your question as quickly as we can!

    • david_schramm's avatar
      david_schramm
      Day Hiker II
      2 months ago

      Thanks. I would have posted it in the Technical community but I have zero access to see or post anything for some reason.

      • dstevens's avatar
        dstevens
        Puritan
        2 months ago

        Hey david_schramm​

        Are you stating that host names or ESX cluster names in vCenter don’t equal the host objects or host group objects on the FlashArray?  I just want to clarify that’s what you are inquiring about before providing an answer.  Are you using iSCSI or fibre channel?  Are you experiencing any problems with volume connections by this mismatch?