Derhak
1 Copper

Relationship between access profiles, clusters and pools

Hi All:

I am new to Centera SDK programming, so please forgive what maybe a set of obvious questions.  I have read the EMC Centera SDK Programmers Guide (3.2)and the EMC Centera SDK (3.2) API Reference Guide.  I have also downloaded and built the Centera SDK samples compiled and ran them.  Specifically the GetClusterInfo sample.

I ran this particular sample first with just an IP address for US2 (128.221.200.60) and retrieved information from what I assume is the default "access profile" associated with the cluster.  I noticed that "privileged-delete" was turned off. I then ran the sample with the same sample with the same IP, but this time added the pea file to the connection string that had privileged-delete capability associated with it. I noticed that the results had "privileged-delete" turned on.

1. Is the first run with the sample the general cluster capabilities or did I retrieve the capabilites of the the default access profile? 

2. Is there a way to enumerate all the pools in a cluster through the SDK calls and what content they have access to?  If there is, can you get the capabilities of each of these these enumerated pools?

3. Can you have content being accessed by more than one "access profile" that have different capabilities?

4. Can you change the behavior of an "access profile" once it has been created?

Thank you in advance,

K

0 Kudos
6 Replies
Highlighted
khanz1
2 Iron

Re: Relationship between access profiles, clusters and pools

Hi K,

I recommend that you review the white paper on Virtual Pools.

All access rights (read,write,delete, privileged delete etc.) can be granted/removed at the cluster, pool and profile level.

1. When you connected to cluster with just the IP (no access profile) you got capabilities for the "default" pool/profile, and when you connected using the PEA file you got the capabilities that were allowed for that particular pool.

2. Not sure, hopefully our developers can answer that.

3. No - a profile (say profile2) should have the same capabilities and proper access rights to read the content written by a different profile (say profile1). If you wrote content using profileA (lets say profileA has poolA set as its home pool) and tried to read it with another profile e.g. profileB (profileB has poolB set as its home pool) you will get operation not allowed error. You will need to set the proper access rights to profileB such that it has read access to poolA.

4. Yes, you can go back and add/remove access rights for a particular profile by using Centera Viewer (update profile <profile_name>). 

Hope this helps.

Derhak
1 Copper

Re: Relationship between access profiles, clusters and pools

Hi Zeeshan:

Thank you for taking the time to look over and answer my questions. I will definitely review the white paper. How long does it usually take to get answers from the developers?

Thanks again,

Kevin

0 Kudos
gstuartemc
2 Iron

Re: Relationship between access profiles, clusters and pools

Hi Kevin - no, you cannot "discover" the names of all the profiles or pools that have been created on a cluster.

One of the fundamental concepts of the Centera is that is not based on "users", but contains "pools" of data that have been created by applications. As such, if you are a user of an application, that application (rather than you as an individual) is what makes the connection to the cluster. You are unaware of where your data resides, but based on the way the application is designed your data may reside on many different types of storage, one being Centera. The application will retrieve it seamlessly without you needing to know where it came from.

If you are installing an application, the cluster administrator will provide you with the authentication credentials that they wish you to use. This could be a PEA file, a username / secret pair or simply the default "anonymous" authentication. There is no scenario where an application should need to query for details of the pools or profiles that have been created (other than Centera Viewer, which is the Centera admin GUI).

In terms of discovering what content is stored in the pools, this is accomplished via the Query API commands. The result set will be determined by the pools that are available to the profile you used for connection - you will always get your "home" pool content (assuming the Query capability is enabled), and content located in other pools can be made available assuming your profile has been granted Query / Read access on those Pools.

Using the GetCapability API you can only obtain the capabilities for the active Pool connection. You could, in theory, open several pool connections to different Pools (by using different credentials) and issue the call for each open connection.

Hope that helps!

0 Kudos
Derhak
1 Copper

Re: Relationship between access profiles, clusters and pools

Hi:

Thank you for your help and quick response.

Kevin

0 Kudos
Derhak
1 Copper

Re: Relationship between access profiles, clusters and pools

Hi:

I have reviewed the White Paper; EMC Centera Virtual Pools Introduction and Principles of Operation and have found it very informative. After reading through the paper I have a couple of follow up questions that pertain to "profile types" and "pool vs. cluster" masks.

1. How do I query the cluster profile using the SDK?

2. Using the SDK can I get the cluster mask for a given cluster, say US2? Is this a matter of just using a connection string of an IP and name=Home?

3. The access profile for US2, us2_profile3_rdqeDcw.pea, has an application pool mask of read, delete, query, exists, privileged delete, clip-copy and write, correct? Therefore the cluster mask must have at least these capabilities set in it's mask, true? Please see question 2.

The reason I am asking these questions is I need to know if it is possible to get the cluster profile so I can use the SDK to get it's capabilities. Once I have these capabilities I can then tell the client whether or not the operation they are asking for can be performed through an access profile for a given pool, all using the SDK.

Again, thank you in advance for your patience and help,

Kevin

0 Kudos
holgerjakob
2 Iron

Re: Relationship between access profiles, clusters and pools

Hi

You cannot query the cluster profile. A query can be performed to get the objects created in a given timeframe.

Cluster profiles cannot write to a Centera. Only Access profiles can.

Cluster profiles are typically used for replication, restore or backup/recovery puposes. The usage of access profiles though is recommended as you can control on which pools your operations occur.

If you want the SDK to answer which operations you can perform, connect to the cluster and do a FPPool_GetCapability. The result will tell you which capabilities are enabled and which ones are not.

Why certain capabilities are disabled may have several reasons: They may not be granted in one or more of the following: profile capabilities, pool maks or cluster mask. Privileged Delete may also be disabled since you are using CE+ and not only the capbility settings.

GetCapability will tell you from the point of the access profile (and cluster profile) which capabilitities are enabled and disabled.

I suggest you use JCenteraVerify which will tell you the same thing without having to develop something on your own. This is available on the customer cd of the Centera Tools available in Powerlink.

Configuration and settings are visible in CenteraViewer if you connect as an admin to the Centera you are talking about. This would be the tool the admin uses to change any capabilities if your profile is missing some. If you want to know what the situation for your profile is perform a show profile list and see what the home pool for your profile is. Then do a show pool detail "homepool" where homepool is the home pool of your profile. The output for the pool will contain the cluster mask, pool maks and the capabilities granted and effective for your profile. This does generally quickly tell you where something is missing. I also suggest to remove any capabilities not necessary for normal operations (like query and Privileged Delete).

Best regards, Holger

0 Kudos