| Author |
Topic |
|
coolerbob
Aged Yak Warrior
841 Posts |
 Posted - 2005-10-12 : 07:35:08
|
We are getting a Dell SAN.Now I know that there are some bits of hardware out there that you just dont want to buy (e.g. some types of 64 bit servers...).So I'm just checking firstly that no-one has had any bad experiences with any of the Dell SANs.Also, I am thinking of the following layout: -
a RAID 5 for the DSS database(s) data files-
a RAID 10 for DSS database(s) log files-
a RAID 10 for the tempdb file-
I assume it would be a good idea to have the OLAP database on a seperate RAID? If you agree, which RAID and other settings would help this predominently Read-access database performance-wise? |
|
|
eyechart
Master Smack Fu Yak Hacker
3575 Posts |
Posted - 2005-10-12 : 12:50:56
|
| I think Dell OEMs these from EMC. EMC is a pretty big name, so you should be in decent shape. Are you running Dell server hardware too?As for your config, that looks good too. RAID 5 has good performance for reads, so that should be fine for your OLAP environment. RAID5 typically has poor write performance though, usually referred to as the RAID5 'write penalty'. This is because a single write requires 4 or 5 individual I/O operations in a RAID5 config. Some SANs have better cached RAID5 designs that reduce the number of physical I/O operations and perform them in memory instead. -ec |
 |
|
|
MichaelP
Jedi Yak
2489 Posts |
Posted - 2005-10-12 : 15:47:55
|
| Well, I have and Dell / EMC CX200 unit that we've run in production for about 1.5 years now. Our installation was TERRIBLE! It took months due to some serious mistakes in the first five minutes of the install. A word to the wise: Make sure all of the drives are of the same size, and never pull out more than one of the first five drives in the cabinent at any one time. If you do, find a tall building and jump off of it. It's much less painful. All that being said, once they fixed everything, it ran great and performed pretty well.On to your disk config....If your database is read heavy, your config might be ok.You might want to go RAID 1 for your TXLogs and put more disks in your RAID 5 set and / or get a HotSpare for your arrays. Hotspare is your friend :)Michael<Yoda>Use the Search page you must. Find the answer you will. Cursors, path to the Dark Side they are. Avoid them, you must. Use Order By NewID() to get a random record you will.</Yoda> |
|
|
|
coolerbob
Aged Yak Warrior
841 Posts |
Posted - 2005-10-13 : 03:58:53
|
quote:
Originally posted by eyechart
I think Dell OEMs these from EMC. EMC is a pretty big name, so you should be in decent shape. Are you running Dell server hardware too?-ec
Yeah, we're all dell. |
|
|
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
Posted - 2005-10-13 : 10:55:49
|
| With EMC SAN, all writes go to cache memory, so unless your write IO load is extremely heavy and continuous, I doubt you will see any difference in performance between RAID 5 and RAID 10, provided you follow the manufactures recommendations for the amount of cache memory. You are better off configuring all the drives the same, and making all the disk chunks the same size. This gives you more flexibility in configuring volumes.CODO ERGO SUM |
|
|
|
MichaelP
Jedi Yak
2489 Posts |
Posted - 2005-10-13 : 14:25:21
|
| What Mr. Jones said about the cache is true, assuming you are doing a SAN and not a DAS. In a DAS environment, the cache is not used at all.DAS is Direct Attached storage. This is where your HBA's are plugged directly into the controllers in the EMC box. If you are going though a Fibre switch, then it's a SAN.Michael<Yoda>Use the Search page you must. Find the answer you will. Cursors, path to the Dark Side they are. Avoid them, you must. Use Order By NewID() to get a random record you will.</Yoda> |
|
|
|
eyechart
Master Smack Fu Yak Hacker
3575 Posts |
Posted - 2005-10-13 : 16:12:52
|
quote:
Originally posted by MichaelP
What Mr. Jones said about the cache is true, assuming you are doing a SAN and not a DAS. In a DAS environment, the cache is not used at all.DAS is Direct Attached storage. This is where your HBA's are plugged directly into the controllers in the EMC box. If you are going though a Fibre switch, then it's a SAN.Michael<Yoda>Use the Search page you must. Find the answer you will. Cursors, path to the Dark Side they are. Avoid them, you must. Use Order By NewID() to get a random record you will.</Yoda>
what kind of emc box are you talking about? a SYM or DMX? even in DAS mode the cache is still used. Even on the smaller boxes the cache is used, you would have horrendous performance otherwise. Using the switches should have nothing to do with if the onboard cache is used or not.THe boxes that Dell OEMs are not the big boxes from EMC and I would be very surprised if they had any kind of huge cache [EDIT: they have up to 8GB cache, not too shabby]. They are more like the midrange SANs available from IBM and HP than the high-end boxes from EMC/Hitachi/IBM.Anyway, I would still shy away from RAID 5 if at all possible. RAID 10 gives you better performance (no question), you can suffer more failed disks, when you run degraded you do not have a performance hit, and the rebuild from a failed drive is much, much faster than in a RAID 5 environment.Use RAID5 on an OLAP system, or on databases with low update/insert rates. Use RAID 10 on everything else if at all possible. Of course, budget comes into play here so that may be the real determining factor.EDIT:just looked at the current offerings from Dell, and the high end offering has 8GB of cache, the low end offering has 2GB. http://www1.us.dell.com/content/products/compare.aspx/sanet_fibre?c=us&cs=555&l=en&s=biz-ec |
|
|
|
MichaelP
Jedi Yak
2489 Posts |
Posted - 2005-10-13 : 18:08:49
|
| EC We were using a Dell / EMX CX200 Fibre Channel box. Since it was configured as a DAS, the cache was not used because if our cluster failed over, anything that was in the cache of one controller would be "gone" since that controller was not being used at the time. Something like that. I never understood the full details. Our servers were not fast enough to really push the array we found out anyway.I'm with you on the RAID 5 comments. I don't like RAID 5 for anything but large file storage systems. If you have a 73 or 147GB drive die, it's going to take forever to rebuild it in a high-io environment. I've been told it could take as much as a day or two to rebuild a 147GB drive in a RAID 5 set. Needless to say, that's risky.I think if he goes RAID 1 for his TXLogs he should have enough spindles left over to do RAID 1/0 for his data. You may even see benefits by putting your TempDB and Data on the same array, with twice the number of spindles. I'd be willing to bet that's going to perform better than splitting it out. That sounds dumb I know, but in my experience and from what I've been told by people in the know, that separating things out like that doesn't always give you the gains you are looking for. Your mileage may vary though, and I HIGHLY suggest you do some testing with both disk configs. It's a pain and it takes time, but reconfiguring your production array with production data is a lot more involved.Michael<Yoda>Use the Search page you must. Find the answer you will. Cursors, path to the Dark Side they are. Avoid them, you must. Use Order By NewID() to get a random record you will.</Yoda> |
|
|
|
eyechart
Master Smack Fu Yak Hacker
3575 Posts |
Posted - 2005-10-13 : 19:10:21
|
quote:
Originally posted by MichaelP
EC We were using a Dell / EMX CX200 Fibre Channel box. Since it was configured as a DAS, the cache was not used because if our cluster failed over, anything that was in the cache of one controller would be "gone" since that controller was not being used at the time. Something like that. I never understood the full details. Our servers were not fast enough to really push the array we found out anyway.
That is a huge drawback. Although, I still don't understand why this is an issue. When you connect to the switch, it has to connect back to the SAN in the same port as you would have used when directly connected. Seems like a pretty serious design flaw.This sounds like an issue with this particular model, and really is something to be considered if you will be implementing this system. I know for certain that the larger SANs don't behave this way when used in a DAS environment.-ec |
|
|
|
coolerbob
Aged Yak Warrior
841 Posts |
Posted - 2005-10-14 : 08:14:54
|
quote:
Originally posted by MichaelP
Your mileage may vary though, and I HIGHLY suggest you do some testing with both disk configs. It's a pain and it takes time, but reconfiguring your production array with production data is a lot more involved.Michael<Yoda>Use the Search page you must. Find the answer you will. Cursors, path to the Dark Side they are. Avoid them, you must. Use Order By NewID() to get a random record you will.</Yoda>
I was sort of hoping to take the guess work out of it and not have to test different configurations but just pick a good config based on sound technical reasons. |
|
|
|
bakerjon
Posting Yak Master
145 Posts |
Posted - 2005-10-14 : 10:08:48
|
| I believe the differences that EC and CB are discussing about Storage Device cache are 2 different caches. One is HBA cache (definitely turn off for cluster!), and storage array cache (don't ever turn this off!). There's actually a 3rd - disk drive cache, but no one brought that up so I'm a fool for mentioning it :).The EMC CX arrays (Dell resells the lower end of them) have 2GB to 8GB of data cache on them. All reads and writes happen to and from this cache. It is also persistant even in a cluster fail-over scenario (data is data is data to it). By default the arrays are set to have write cache larger than read cache, but it is configurable in Navisphere manager. You might want to think about this if you are using it primarily for DSS operations. Obviously discuss with the vendor. With that said, EMC still doesn't say good things about its own RAID 5. There is a write penalty. I try to use RAID 10 where possible. Since you have a heavy read load, I would do RAID 1 on the logs and add the disks to the data pool for RAID 10. If you are doing ETL at night, it might slow down slightly, but I think it will be mostly a wash with the improvements on the data side.Jon-Like a kidney stone, this too shall pass. |
|
|
|
coolerbob
Aged Yak Warrior
841 Posts |
Posted - 2005-12-06 : 08:19:10
|
| in sql2005, if we are putting all our production databases on one san, is there any value in building in hardware redundancy by having two servers logically grouped as one (and how would you do that?) so that if a processor/motherboard goes down, the other server can carry the load? Basically you would just "plug in" more servers to get more processing power / redundancy. What do you use to do that? Windows? SQL Server? Third party software? |
|
|
|
derrickleggett
Pointy Haired Yak DBA
4184 Posts |
Posted - 2005-12-06 : 23:59:31
|
| You wouldn't get more processing power. You would get redundancy though, and it makes a whole lot of sense. You just need clustering. If you design right, and decide to go with an active/active cluster, I suppose you could say that you are getting more "processing power" out of the deal. It's semantics at that point though.It makes sense to have the hardware redundancy clustering provides you whether you are on SQL 2000 or 2005 btw.MeanOldDBAderrickleggett@hotmail.comWhen life gives you a lemon, fire the DBA. |
|
|
|
coolerbob
Aged Yak Warrior
841 Posts |
Posted - 2005-12-07 : 05:21:16
|
| Is that SQL clustering or Windows clustering? This seems to me to be one of those things that are not strait-forward to implement. Where can I read up more about this? |
|
|
|
bakerjon
Posting Yak Master
145 Posts |
Posted - 2005-12-07 : 09:06:25
|
| http://www.sql-server-performance.com/clustering_resources.aspThis should give you some fun reading :)Jon-Like a kidney stone, this too shall pass.http://www.sqljunkies.com/weblog/outerjoin |
|
|
|
|
SQL on SAN