• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

SAN - SQL Clustering, Exchange Databases, Altiris?

K

KapsZ28

2[H]4U
Joined
May 29, 2009
Messages
2,114
I am trying to get a better understanding of what a SAN is used for. I thought a SAN was typically setup using RAID 10 for high IOPS and 10GBe NICs. This way apps with high demand especially SQL will have their databases stored in the SAN. I always heard that Exchange databases should also be stored in a SAN.

At our company we have a serious performance issue with Altiris. Just trying to use the Management Console is excruciatingly slow. All our Altiris DBs are located in the SAN. Today an Altiris engineer says that a SAN is only supposed to be used for mass amounts of storage...?

I don't know the specifics of our SAN, but I am pretty sure we only use RAID 5 because of the additional cost for RAID 10. I know we are only using 1GBe, but are in the process of upgrading to 10GBe. I would guess the hard drives are 15k as we don't use any SSD.

Right now our Exchange DBs are in the SAN and every night it takes 12+ hours to back them up.

Besides the fact that the SAN at our company sucks, what do you primarily use a SAN for? Is it the best place to keep your SQL databases?
 
There are several reasons to use SAN's. Here are some, and different SANs cater to different areas:

1) Larger disk capacities as compared to local storage
2) Higher availability of data (heavy redundancy on power, disk, controller, fans etc)
3) Higher performance compared to slower local disks (larger number of disks = higher performance)
4) Clustering (multiple servers accessing the same data simultaneously, or in a failover/HA fashion)
5) Consolidation of data (instead of having data in multiple places, having it in one)
6) Snapshots and simplification of disaster recovery (leads of the previous point; if all data is in one place, snapshotting and sending offsite is easier).
7) "Simple expansion" (not always true!)

These are some of the more common reasons.

For a SQL database, typically yes, I would have this on a SAN (depending on the application of course). The reasons for this can be several fold:
1) Clustering for high availability
2) Higher performance (IO's are spread over a larger number of disks, or possibly SSD's)
3) Snapshots - recovering from a snapshot + Logs is easier with SQL+SAN than SQL+local disk
4) Larger disk capacities - often SQL databases can grow very large.

My 2 cents.

Depending on your SAN solution, it might be time to talk to your vendor and find out what can be done to deal with your performance issues. Most mid range SANs have the ability to do performance tuning/tweaking and monitoring to determine where a bottleneck might be. You may find the issue is not with the SAN it self, but the backup process being used. This could be come a long and complicated thread; i like!
 
You must log in or register to reply here.
Back
Top