Unsolved

This post is more than 5 years old

2440

December 23rd, 2009 02:00

need EMC configuration information

  Hi,

       I am new to SAN . please can any  one suggest me for implenting new EMC SAN storage ,each one size should be atleast  2 TB and any GUI interface (sotware)  to mange SAN . we need 2 EMC storage .does every sever must require  to connect SAN , either server is runin any unix flavor or windows. thanks a lot in advance

28 Posts

December 31st, 2009 02:00

One more thing, there are many Flavours of windows and Linux/Unix and many available FC switches and HBA's make sure you check that your configuration is supported before buying or you may have issues logging support calls,

28 Posts

December 31st, 2009 02:00

Hi There,

A few things I would suggest you do before sizing a bunch of disks to the tune of 2TB. Firstly, your application response times are dependant upon a few things, one of the key things is ensuring you provision enough spindles/drives to support the disk load you are going to put on the SAN. If performance isn't considered and the SAN isn't sized with performance in mind, you could potentially see queue depth increasing on drives, the queue depth directly relates to the number of read/write requests waiting to access the drives. If the queue depth gets too high, applications which require sub 5ms or less response time (which a few do) may start timing out and you have problems. So you need to do a bit of data gathering..

In windows terms run something like perfmon in logging mode, looking at counters like bytes written, bytes read, number of reads, number of writes, queue depth. In Linux/unix terms, something like IOstat should be fine.

Ensure start logging over a reasonable period of time and ensure you capture metrics over peak hours of activity. We'll come back to this in a minute.

Identify the profile of your data, which applications write to disk in a sequential fashion which write in a Random fashion. Sequetial writes are optimised by some clever bits the clariion does in cache, if you mix Sequential and random type data on the same RAID groups, you won't see optimised writes with sequential data.

sequential data = Large writes (typically Backup to disk apps, archive applications, media streaming, large file)

Random data = lots of small read/writes. Ie. Database (exchange, SQL, oracle)

Next you need to think about the level of RAID protection required:

RAID 5 = Distributed parity, has a reasonably high write penalty, good usable vs raw capacity rating (equivalent of one drives usable capacity for parity) , a fair few people use this to get most bang for their buck. bear in mind that RAID 5 can suffer single drive failure (which will incurr performance degradation), but will protect from double disk failure. EMC Clariion does employ the use of hotspares, which can be proactively build when the Clariion detects a failing drive and used to substitute the failing drive when build, although if no hotspare exists or if a second drive fails during a drive rebuild or hotspare being build, you will lose your data. write penalty = 4

             

RAID 1/0 = Mirrored/Striped, lesser write penalty, more costly per GB as you lose 50% usable capacity to mirroring. RAID 1/0 provides better fault resilience and "rebuild" performance than RAID-5. It has better overall performance by combining the speed of RAID-0 with the redundancy of RAID-1 without requiring parity calculations. write penalty = 2

RAID 6 = Again distributed parity but instead of calculating horizontal parity only (as RAID 5 does) also calculated Diagonal parity essentially protecting you from double disk failure, there is a greater capacity overhead than RAID 5, but not as great as RAID 1/0 (equivalent of 2 drives usable capacity for parity).  The write penalty for RAID 6 is greater than RAID 5, although typically RAID 6 should only be used for sequential type data (back to disk, media streaming, large file), so writting to disk will be optimised by write coallescing in cache, writing all data and parity out do disk in one go without calculating parity on the disk (this incurring a lesser write penalty). This will only happen if the write sizes are greater than the stripe size of the RAID group and the drives are properly aligned.

There are a number of documents on powerlink outlining RAID sizing considerations for specific applications. Rule of thumb us keep your log files on seperate spindles to your main DB volumes.

I'm going to cut this a bit short -

from the data you gathered (mentioned at the beginning of the document), for each logical drive currently local or direct attached take the following :

number of reads + (number of writes x write pentalty) = disk load  (write penalty is specific to the raid type being used, RAID 5 = 5, RAID 1/0 = 2 )

Each drive type has an IOP rating = 10k FC = 150 IOPS, 15k FC = 180 IOPS, SATA = approx 80 IOPS

divide the disk load by the IOP rating of the disk type you've chosen and that will give you the spindles required to support your disk load (excluding parity drives). You will most likely have multiple volumes (LUNS) on a given RAID group, so ensure you divide the aggregate disk load of the volumes to reside on the given RAID group by the IOP rating of the drives in question.

Thats a starting point for you and some food for thought..   for more detail, there are FLARE best practice guides and application specific guides galore on powerlink...

Hope that helps somewhat.

Evan

No Events found!

Top