EVA8000 Contention HELP

[Steve_Gafri]

We're experiencing I/O contention due to SQL servers hogging all I/O during restore process. We have an EVA8k with 4 disk groups
DB group 96 disk
Log group 40 disk
Backup group 40 disk
1tb FATA group 66 disk
Our dev sql boxes use the fata group and when a restore from disk to disk is run to refresh a DB it impacts everything else on the array. The fata group has 66 disks configured as raid 5. Other servers that sit in the fata group are file/print and vmware dev. Write latency will spike in the array to about 20ms due to 1 sql dev box. We've noticed the fata disk group also impacting the performance of the other disk groups. Is there a spec sheet on what fata disk i/o max rate is or best practices in architecting 1tb fata disk groups along with other disk groups. We really noticed performance issues once we plugged up the expansion cabinet and added the fata drives. The only way to leverage the performance is by pinning the dev sql box issuing the restore to use a preferred port to the eva. This in turn drastically slows down the restore from 120mb/sec to 20mb/sec. How can we keep the i/o spread evenly without impacting production? It seems like the sql restore is taking all available i/o on the eva and the controllers & cache are backing up not being able to write data fast enough to the fata disks. Should we be using a write back or write through config on the vdisk setting? Thanks for any info offered. Mgmt. is doubting the eva and the storage team day after day.

[Uwe Zessin]

Throw out the FATA drives - they are not meant for this kind of I/O and their slowness can block the cache.

[OFC_EDM]

I concur with Uwe. We do use FATA drives. But only as an area for file storage of files not accessed to heavily: General user File store, backup area for backups with low priority, Intermediate archival of project data that sort of thing.

Use the FC diska for anything DB related. Even your Dev. Assuming budget is not an issue....Why would your Dev environment be on dissimilar H/W than your production?

If you're forced to use FATA for DB related then put in as many disks as possible into each group. Then also inform your user community what to expect...slower access compared to the FC.

[Steve_Gafri]

I'm going to move the SQL stuff of the FATA drives. What is ready causing this is the lightspeed utility SQl uses for restoring data. This backs up the cache and impacts other clients utilizing the same disk group. Any other recommendations on what can run smoothly on the 1TB drives?
Vmware?
Content Management?
VSS?

Looking for FATA data placement recommendations.

[Uwe Zessin]

FATA disks are meant for 'reference data'. Those are files which don't need high-speed access, but tape media is too slow. So stuff like photos, document scans which are stored and retrieved from time to time.

VMware is certainly not suited as it consolidates I/Os from several virtual machines. Snapshot data might not be a good idea, either, because a slow clone or copy-out can negatively affect writes from your production servers. Even the use for the Continuous Access Write History Log (WHL) is discouraged these days!