[Lustre-devel] GSS cross-realm on MDT -> OST

Peter Braam Peter.Braam at Sun.COM
Tue Jul 8 10:43:39 PDT 2008


Yes, it will be very important that we can separate OST's/MDT's widely.

But placing them in different realms, I'm not sure about.  Can PSC explain
what administrative model warrants that?  Why can a remote OST not be part
of the realm of the MDS that controls it?

Peter


On 7/8/08 11:27 AM, "Eric Mei" <Eric.Mei at Sun.COM> wrote:

> Hi Ben,
> 
> Benjamin Bennett wrote:
>> Hi Eric,
>> 
>>   If you could give me your input on something I'd greatly appreciate
>> it.  Or, if I should just sent this to -devel let me know...
> 
> Yes you can always send to -devel for open discussions. I'm CCing it.
> 
>>   For Lustre-WAN across TeraGrid we were hoping to distribute OSSs
>> across several resource providers (sites), leveraging existing kerberos
>> infrastructure, placing OSSs in each resource provider's local kerberos
>> realm, and the MDS in the teragrid realm.  Unfortunately, MDT -> OST
>> connections will not allow the MDT and OST to be in different realms,
>> since an OSS considers an MDS to be anyone holding a lustre_mds
>> principal in their local realm.
>> 
>>   This also seems undesirable within a single-realm where multiple
>> lustre clusters may exist, as an OSS in cluster A will trust an MDS for
>> cluster B, and an OSS for cluster B will trust an MDS for cluster A.
>> 
>>   My first thought was to add functionality to tell the OSSs lsvcgssd
>> what the trusted MDS principals should be (local or not).  Do you have
>> any thoughts on this?
> 
> We just never thought the usage that OSS could locate in multiple
> realms. I agree with you in this case, we can make OSS configurable to
> only accept designated lustre_mds principals, local or remote.
> 
> I'v questions just for curiosity: 1) is the benefit of cross site OSSs
> about bandwidth? 2) in the future with CMD (clustered metadata, multiple
> MDS nodes), would it be useful to distribute MDSs across multiple site
> as well?
> 
> Thanks





More information about the lustre-devel mailing list