All Flash Storage Configuration

Question

Our co is getting a new SAN with all flash storage which would be attached to a physical 8 core 48 GB RAM server. I have been studying what is the best way to configure this setup. Our DB has mostly read transactions, write occurs only during midnight when data is interface from core ERP system to this data warehouse DB. There really isn't any performance issues in our old setup right now, except the usual long running queries while crunching millions of financial records every now and then.

So, I have some concern about setting partition offset, file allocation unit size and stripe unit size. I know that file allocation unit size should be 64kb for datafiles volume, stripe unit size provided by vendor is 256kb, but i am not sure about setting the partition offset. But before that, does this 3 parameters even matter when we are using SSDs now? I get that this 3 parameters is important to improve IOPs on traditional mechanical harddrives, but on SSDs, does it matter at all?

Also, since the new setup is all flash, does it matter to split data files, log files and tempDBs into their each volume?

Would appreciate if anyone could provide some insights or advice on the configuration part.

Answer 1

The guidelines for different volumes were more of general best practices when you're trying to squeeze your performance/cost ratio. Outside of that, putting them in different volumes not only helps segregate workload which could cause performance to be affected by SSD functions such as TRIM or how it deletes data for example, but also helps you with management.

Transaction logs segregation is also very important for ACID compliance. If you don't have your Tlogs in a different volume and the data volume goes down, you just lost all of your transactions that were not backed up yet. See Tail of the log backup. This way you know you can still recover the transactions and restore to a point in time or right before the crash.

Partition alignment is done at the disk level by the OS so you'd still want to ensure you are partition aligned. Some flash drives might not need that such as the FGPA powered ones which treat SSDs differently a bit but why not double check anyways? It's easy and fast to.

The 64kb is done more so by SQL Server because that's how big an extent is. Your vendor could make it 256kb but you should get clear documentation as to why they recommend that. Do they really read that much data per operation? If so, great, set it. If not, stick to what SQL Server as the underlying DB engine needs.

Personally on my all flash storage arrays based on my performance testing and expected growth I tend to put Data/TempDB on the same volume, Transaction Logs on a different one, and backups on another one. This way if for some reason a backup all of a sudden is huge, or some job for some horrible reason doesn't delete some old data we don't interfere with the data drives. I test restore and check every backup nightly but I trust my scripts to delete the data which has worked fine. However, if one day it doesn't, I will know as the backup will fail, there will be no restore, and I'll be alerted along with the dashboard. These could be mitigating controls you could utilize if you wish.

Edit/update based on question:

Well TempDB will always create as much IO as it needs to depending on your queries, but from what I read you were doing almost all reads and not writes. TempDB would then be doing the bulk of the writes in your use case. Thus it would be easy to determine how much tempdb is writing and see if it gets closet to the IOPS limit you have available. From what I read your old system didn't have any performance issues and the new SSD as opposed to magnetic disk system would be much faster unless you shrunk a massive raid array into 1 disk or something.

When you're factoring in if TempDB contention is going to be an issue or not note the higher IOPS you get with a bigger RAID array as well. A RAID 5/6 array will still give you all the read performance boost without penalty so in your use case you might get more IOPS by combining your TempDB and data array together, than you would segregating them; again based on usage pattern.

Easy answer? Check perfmon to see your throughput and if you know the queries are largely going to remain the same (reasonably) and it should show you have to much in IOPS that it doesn't matter which one you go with. Pick the one you'd be more comfortable managing and scaling with. :)

-Tail Of The Log Backups:

Yes, if your transaction log drive(s) go down you will lose any transactions that have not been hardened to disk somewhere (a dirty page) and have not been yet backed up. Careful monitoring and proper raid arrays are mitigating controls for that, but many people also replicate/mirror/AG the data elsewhere so there is a copy that is very closely up to date. Some people like Brent Ozar prefer to run transaction log backup scripts continuously and restore them dynamically from queries if needed.