Topic
2 replies Latest Post - ‏2013-06-20T13:32:38Z by jgrn
administratore
administratore
10 Posts
ACCEPTED ANSWER

Pinned topic Windows clients - native GPFS vs. Samba - exchange opinions / experiences

‏2013-01-11T11:40:21Z |
Hi all,

atm I'm thinking about what are the considerations of integrating Windows nodes (Server 2008R2, Win7) into a GPFS cluster regarding client access only.

I got the chance to deal deal with some V7kU and also SONAS clusters but I'm interested in opinions regardig native GPFS Windows clients.

Has anybody here already integrated some Windows clients (client clusters) and is willing to share his experiences?

To start....when I started to compare these two ways I didn't find sth. about Snapshot (vss) and ABE integration into native GPFS. Can anybody confirm that?

What traps did you already step into?

Would be great to collect a litte bit of stuff here...
regards
Updated on 2013-01-11T18:33:46Z at 2013-01-11T18:33:46Z by vpaul
  • vpaul
    vpaul
    78 Posts
    ACCEPTED ANSWER

    Re: Windows clients - native GPFS vs. Samba - exchange opinions / experiences

    ‏2013-01-11T18:33:46Z  in response to administratore
    Hello,

    In regards to VSS and ABE:

    GPFS for Windows does not come with a Volume Shadow Copy Services (VSS) provider. Hence it does not integrate with the VSS framework. It does provide its own snapshots feature which must be administered via various GPFS native commands.

    Access Based Enumeration (ABE) is an add-on feature on top of a filesystem. GPFS/Windows implements full ACL based security semantics. Hence ABE enablement on GPFS shares should work.

    Regards.
  • jgrn
    jgrn
    4 Posts
    ACCEPTED ANSWER

    Re: Windows clients - native GPFS vs. Samba - exchange opinions / experiences

    ‏2013-06-20T13:32:38Z  in response to administratore

    Hi there -- I was an end-user for an attempt to get the GPFS client for Windows, and we never did.  We could never get it playing nice with our AD system and file permissions (we tried for 4+ months).  We ended up going with Samba, although the asynchronous read/write isn't great either (we did manage to get good sequential reads and writes out of the system).

    A couple of headaches: Samba's oplocking doesn't play nicely with GPFS (particularly if you database work), so it will probably behoove you to turn them off.  The catch: you can only disable them with SMB1 (also, GPFS documents recommend SMB1) -- SMB1 is missing a lot of speed improvements that SMB2 and, more importantly, SMB3 have.  THe SMB3 protocol in particularl supports Samba over RDMA aka "Samba Direct" (although not quite yet in Samba 4.0 at the time of this post).  

    Later this year, assuming Samba begins supports Samba Direct (which is being tested right now), we will probably try out Windows Server 2012 (the only Win server client that supports SMB3) and SMB direct over our quad infiniband to see how it behaves.