beginning SAN infrastructre for the company.

pts.
Tags:
SAN
SAN architecture
Storage strategy
On my windows 2 cpu server with 20 disks, disk queue lengths exceed 40. Windows perfmon and IOmeter benchmarks give me 0.9K IOPs for write and 2K for reads, 8K OLTP block size. #disks : 20 : 36 GB, 15K rpm, U320 scsi with two dual channel controllers with 256 MB cache each. I am moving to a SAN. How can I get double my current IO performance. In addition I also want a development/failover system with half the performance of production. production data size : 400 GB development data size : 400 GB temp table space : 100 GB each for production and develop. Log file : 100 GB each for development and production. In addition I have an application server which users upload data ( hence mainly writes). files are large : 50-100MB in uploads. All cases, 20 simultaneous access the SAN. My solution : 28, 73 GB 15K for production + temp tablespace. 28, 73 GB 10K for development/temp table space. 4 disks 146 GB, 10K for logs ( prod and develop) 8 disks 146 GB, 10K for application server. However the cost is 50% more than my budget. Also looking for d2d2t backup. 1 TB backup d2d : 5 hrs d2t : 10 hrs.

Answer Wiki

Thanks. We'll let you know when a new response is added.

Not knowing what all you looked into before deciding to go to a SAN environment or the hardware vendors you are using, I can only make these general suggestions.
If your storage environment is strictly for file sharing/storage then a NAS head would give you much better performance than a windows file server even connected to a SAN.
The I/O performance for the server may still be limited to the bus speed and throughput so it may not increase significantly going to SAN.
As far as a development/failover system I would suggest looking into a Serial ATA device (SAN or NAS). Prices for that type of device is much less than the Fibre Channel SCSI disks you would use for production and you are not paying for performance. This device could/should also be used for the d2d backup depending on your configuration.

Discuss This Question: 2  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Rkrishnan
    The data for production and development is for highly i/o intensive database. database query plan suggests between 50-90% time is spent in i/o to disk. thus NAS will not work in this regard. ( latency plays a role ) Application server could be moved into SATA however will it handle the writes from 20 simultaneous users? development system is used in case of failover from production and also during updates ( 2-3 days /month ) thus development system cannot be that far behind the production and should handle i/o load ( twice as long response times is acceptable for 2-3 days/month )
    0 pointsBadges:
    report
  • JamesLambert
    I agree with you - your database with high I/O should be on the SAN and I would not suggest any other place no matter what some NAS vendors say. We don't and we won't. In regard to the performance of the SATA disks - we have most of our Resaerch, Development, and UAT environments, our production file server, and others on SATA connected to the SAN and we have not seen any performance problems. (fyi-we have 500+ employees accessing the file server)
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following