[gpfsug-discuss] GPFS AFM experience

[Tom King]

Thanks both Barry and Andrew

I'd love to be able to provide some numbers but a lot of this is hedge 
betting whilst there's budget available, I'm sure an environment we're 
all used to.

I'll probably get 2*10Gb/s to the data centre for GPFS and all other 
traffic. I can perhaps convince our networks team to QoS this.

At present, there's no latency figures though we're looking at a 30 mile 
point to point distance over a managed service, I won't go into the 
minutiae of higher education networking in the UK, we're hoping for <5ms.

I expect a good mixture of read/write, I expect growth in IO will be 
higher on the local side than the DC.

The GPFS nodes are running RHEL 6.5 so 2.6.32.

It doesn't seem obvious to me how one should size the capacity of the 
local AFM cache as a proportion of the primary storage and whether it's 
self-purging. I expect that we'd be looking at ~ 1 PB at the DC within 
the lifetime of the existing hardware.

Thanks again for assistance, knowing that there are people out there 
doing this makes me feel that it's worth running up a demo.

Tom





On 04/07/2014 16:07, Barry Evans wrote:
> Hi Tom,
>
> Couple of quick ones:
>
> Do you know what the latency and line distance is likely to be? What's
> the rated bandwidth on the line? Is the workload at the 'local' site
> fairly mixed in terms of reads/writes? What is the kernel version on the
> current cluster?
>
> Regards,
> Barry
>
>
>> Tom King <mailto:t.king at qmul.ac.uk>
>> 1 July 2014 17:39
>> Hi
>>
>> I've recently adopted a small two node GPFS cluster which is likely to
>> be relocated to an off-site datacentre in the near future and I'm
>> concerned that latency times are going to be impacted for on-site users.
>>
>> My reading of AFM is that an Independent Writer cache held on-site
>> could mitigate this and was wondering whether anybody had any
>> experience of using AFM caches in this manner.
>>
>> Thanks
>>
>> Tom King
>>
>>
>>
>
> This email is confidential in that it is intended for the exclusive
> attention of the addressee(s) indicated. If you are not the intended
> recipient, this email should not be read or disclosed to any other
> person. Please notify the sender immediately and delete this email from
> your computer system. Any opinions expressed are not necessarily those
> of the company from which this email was sent and, whilst to the best of
> our knowledge no viruses or defects exist, no responsibility can be
> accepted for any loss or damage arising from its receipt or subsequent
> use of this email.
>
>
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at gpfsug.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>


-- 
Head of Research Infrastructure
IT Services
Queen Mary University of London