Saturday, 15 May 2010

SAN Performance -



SAN Performance -

have question regarding san performance emc vnx san. have important number of processes spread on number of blade servers running concurrently. number of processes typically around 200. each process loads 2 little files storage, 1 3kb 1 30kb. there millions (20) of files processed. processes running on windows server on vmware. way setup 1tb luns on san bundled single 15tb drive in vmware , shared network share 1 windows instance processes. processes running concurrently , performance abysmal. essentially, 200 simultaneous requests beingness serviced san through windows share @ same time , san not handling well. i'm looking recommendations improve performance. in advance...

with performance questions, there's grade of 'it depends'.

when you're talking accessing san, there's chain of potential bottlenecks unravel. first though, need understand actual problem is:

do have problems throughput - e.g. sustained transfer, or latency? it sounds we're looking @ random read io - 1 of hardest workloads service, because predictive caching doesn't work.

so begin @ beginning:

what sort of underlying storage using?

have fallen trap of buying big sata, configuring raid-6? i've seen plenty of places because looks inexpensive terabytes, without doing sums on performance. sata drive starts slow downwards @ 75 io operations per second. if you've got big drives - 3tb illustration - that's 25 iops per terabytes. rough rule of thumb, 200 per drive fc/sas , 1500 ssd.

are tiering? storage tiering clever trick of making 'sandwich' out of different speeds of disk. works, because usually little fraction of filesystem 'hot' - can set hot part on fast disk, , cold part on slow disk, , average performance looks better. doesn't work random io or cold read accesses. nor work total disk transfers - 10% of (or whatever proportion) can ever 'fast' , else has go slow way.

what's array level contention? point of san aggregate performance, such each user has higher peak , lower average, reflects most workloads. (when you're working on document, need burst of performance fetch it, barely until save again).

how accessing array? typically san accessed using fiber channel network. there's whole bunch of technical differences 'real' networks, don't matter - contention , bandwidth still do. esx in particular, find there's tendency underestimate storage io needs. (multiple vms using single pair of hbas means contention on esx server).

what sort of workload dealing with? 1 of other core advantages of storage arrays caching mechanisms. have big caches , clever algorithms take advantage of workload patterns such temporal locality , sequential or semi-sequential io. write loads easier handle array, because despite horrible write penalty of raid-6, write operations under soft time constraint (they can queued in cache) read operations under hard time constraint (the read cannot finish until block fetched). means true random read, you're not able cache @ all, means worst case performance.

is problem definitely array? sounds you've single vm 15tb presented, , vm handling io. that's bottleneck right there. how many iops vm generating esx server, , what's contention there? what's networking like? how many other vms using same esx server , might sources of contention? pass through lun, or vmfs datastore vmdk?

so - there's bunch of potential problems, , such it's hard roll single source. can give general recommendations getting io performance.

fast disks (they're expensive, if need io, need spend money on it). shortest path storage (don't set vm in middle if can perchance avoid it. cifs shares nas head may best approach). try create workload cacheable - know, easier said done. millions of files, if you've got predictable fetch pattern array start prefetching, , it'll got lot faster. may find if start archiving files big 'chunks' you'll gain performance (because array/client fetch whole chunk, , it'll available next client).

basically 'lots of little random io operations' on slow disks worst case storage, because none of clever tricks optimization work.

performance san

No comments:

Post a Comment