APIs to determine Cluster from CIFS share UNC

[bobshouseofcards]

Need some help on this one - and accepting it might not be there, but hoping I simply missed the obvious. I probably didn't, but folks here are smarter than me.

I have a need, given a UNC only, to determine the ONTAP Cluster on which the UNC exists.  It's just the way someone wants to setup a higher level abstraction to implement some utility functions on storage.  

Using a ZAPI like <cifs-share-get-iter> can match up the server part of a UNC to an SVM (vServer), that API is only practical if you already know the unknown.  WFA is not currently an option.  OCI is available - considering working against that, but would prefer to limit this to ZAPIs only if possible.  OCUM is not an option as the environment is too big - multiple OCUMs exist in the environment, and it isn't inany short term plan to consolidate despite the latest OCUM versions.  

I can at least derive an IP address from the UNC to which a ZAPI call might be directed.  In short, is there a way to "tunnel" an API call without actually tunneling through a cluster management IP, so to speak.  Yeah I know - it's a weird request.

Thanks in advance!

Bob Greenwald
Senior Systems Engineer | cStor
NCSE | NCIE SAN ONTAP, Data Protection

[bobshouseofcards]

Well the OCI idea is out - sort of.  The REST API for OCI can access shares, but only if you know the ID.  There is no way to search via REST for a specific share and work backwards up to the owning storage.  The assumption in the REST is you start with storages and work down to shares, then get properties given a specific share id.

So yes, while I could build dump all storages and all shares from OCI each time I needed to run the reverse mapping, I'd prefer not to go that way.

Any other ideas?

Again thank you in advance.

Bob Greenwald
Senior Systems Engineer | cStor
NCSE | NCIE SAN ONTAP, Data Protection

[mbeattie]

Hi Bob,

There is no native API in OCUM to list CIFS shares either. Is API-S an option? Any reason you can't use WFA? You could use a WFA filter to determine which cluster the share is hosted on and return the cluster name and IP address as a return paramater. As an example the SQL filter would be something like:

SELECT
    cluster.name AS 'cluster_name',
    cluster.primary_address,
    cluster.`version` AS 'ontap_version'
FROM
    cm_storage.cluster,
    cm_storage.vserver,
    cm_storage.cifs_share
WHERE
    vserver.cluster_id = cluster.id
    AND cifs_share.vserver_id = vserver.id
    AND vserver.name = '${VserverName}'
    AND cifs_share.name = '${CifsShareName}'

Using an OCUM database user and integration schema you can query the CIFS share. EG

SELECT
   cluster.name,
   cluster.version
FROM
   netapp_model_view.cluster,
   netapp_model_view.vserver,
   netapp_model_view.cifs_share
WHERE
   vserver.clusterId = cluster.objid
AND
   cifs_share.vserverId = vserver.objid
AND
   cifs_share.name = 'test'
AND
   vserver.name = 'vserver1'

As you can't use either of those methods due to sizing and scale API-S might be an option (as it also might not scale based on the size of your enviornment by the sounds of it).

Alternatley have you considered using Active Directory groups and computer accounts to track the vserver to cluster mapping? EG create an AD group for each cluster and add the computer accounts for each CIFS vserver to the corresponding cluster group. You could then invoke an LDAP query for the vserver and look at it's group membership. EG

C:\>dsquery computer -name vserver1 | dsget computer -memberOf
"CN=CLUSTER1,OU=Groups,DC=testlab,DC=local"
"CN=Domain Computers,CN=Users,DC=testlab,DC=local"

This assumes that when you join a vserver to the domain that vservers computer account will be added to the cluster group in AD but i guess it might work for you? Don't know of any other native NetApp API that would enable you to do this (without first knowing which cluster to connect to). Just trying to offer some suggestions.

/Matt

[bobshouseofcards]

Matt -

All good suggestions.  The single biggest constraint is time.  The environment where I need this is extremely controlled and siloed.  Hence deploying anything new, whether application (such as WFA) or feature (such as a non-customer standard AD group for tracking) as you suggest can be literally six to 9 months from realization, mostly because of politics.  Of course the demand the customer makes must be done now.  

For back story, the short version is there was a significant site event recently, and now the customer wants to layer High Availability on top of existing non-HA designed infrastructure and application deployments.  They have DR, but now they want cross country HA capability, push button automation to swing entire application sets, invokable at any time by application support teams as they decide to do so, zero RPO/RTO targets (so not the DR setup already defined), and cover all parts of an application - physical and/or virtual servers, any CIFS/NFS shares, all related network components, and the over-riding application services.  Oh - and have it done by end of year for 50+ major applications.  No sweat, right?

From a storage perspective both MetroCluster and SyncMirror (ONTAP 9.5 - yay!) are non-starters due to distance and other technical/political reasons.  

Did I mention it's also end of year freeze, so don't change anything too major.

I like all of your suggestions, and have considered what OCUM and WFA could do already.   In the short term they fail due to the time constraint.  API-S is partially availablein the customer setup, just not where I need it to be.  The environment is highly segmented by firewalls so no single API-S or OCUM server can reach all necessary clusters to be a single entry point.  I think WFA is the better solution longer term from for the NetApp components in the environment (thankfully I only have to worry about the NetApp side of the house).  OCI is the only onsite system currently punched through the necessary firewalls, and hence is also the server from which any storage based automation has to run at this time.  Ironially, the server which will control the "HA-lite" functionality will not itself be Highly Available in any first effort.

On the plus side very late after my two posts from yesterday I learned enough of the OCI REST "Query" API to help out in this case, though it still isn't as simple as I might have hoped.  I like your AD group suggestion and will raise that as a possible long term way to work this system.  Lots of late nights with that and the SDK are ahead I suspect.

Thanks Matt!

Bob Greenwald
Senior Systems Engineer | cStor
NCSE | NCIE SAN ONTAP, Data Protection

[mbeattie]

Hi Bob,

Sure sounds like there is a lot of constraints in the enviroment, the most of challenging of which sounds like the 8th layer of the OSI model (politics and people). Would invoking an OCI SQL query for the CIFS share be an option for you? That might be the least constrained option given firewall rules already exists (though you migh have to add some for TCP 3306 to query OCI remotely)

/Matt

[SeanHatfield]

Well, not that this is great, but it might get you there:

Your UNC should reveal the CIFS server name, or an IP, which will take you to the IP of a data lif.  

If you have management access via the data lif, you can ssh, as vsadmin or some other account on the SVM.

'vserver show' will tell you what vserver you have landed on.

'net int show' will reveal the node names where the vserver's lifs reside.

Most of the time, knowing the node name will tell you which cluster you are living in.