SAN for SQL Server: One large spindle set for all loads, or discrete by load? SQL Server 2014, Standard Edition (running under vmware, fwiw).
Adding a Dell MD3420 DAS box.

In the old school, you would set up discrete spindle sets for MDF, LDF, TEMPDB, BACKUP.

E.g.


MDF:  Qty 6: 300GB-15K, RAID 10  // 900GB storage
LDF:  Qty 4: 150GB-15K, RAID 10  // smaller data footprint, spindles to increase IOPS
TEMPDB: Qty 4: 150GB-15K, RAID 10  // smaller data footprint, spindles to increase IOPS
BACKUP: Qty 2: 2TB, RAID 1


Use Case:
This system has 5 databases, and is OLTP.

Nowadays, I am being told: Just set up Qty 10: 600GB-15K drives, and put MDF, LDF, TEMPDB and BACKUP all on there. The overall higher performance of the larger spindle set more than makes up for the conention writing to LDF and BACKUP concurrently during backups.


a) Is this new way the right way?
b) LDF is supposed to be discrete relative to MDF... I feel funny!
c) I really feel backups should be their own spindle set (for a bunch of reasons)


The winner is ?  SQL Tradition? Or the Dell Storage Architect?
This is a database recovery question first and foremost, then performance.  

DB Recovery:

By keeping the LDF and the MDF file in the same physical array, then you lose any chance of performing a 'tail of log' backup.  This means your data is gone from either:


The last transaction log taken and copied off the failed array.
A mirrored pair/availability group/replicated database elsewhere


So first question is 'how much data can you lose'.  If you cannot lose more than the frequency in which you back your logs then putting it on that array isn't going to meet your data loss objective. 

Performance:

The rest really depends on your usage patterns.  It seems like you do not have a active machine we can get a baseline from, if I'm wrong let me know.  Assuming we don't though, we should understand that DiskIO is critical, especially when there might not be enough RAM or in a high transaction environment. Do you think it will be very highly transactional?  If so, give lots of disks to the transaction log drive.  That version of the Dell SAN let's you short stroke your disks which should give you a good performance boost as the transaction log drives typically go multi disk not for space, but for write performance. 

Putting TempDB on it's own disks was useful but if you don't have any real clear idea as to why you would do it, then really you should test this or just put it in the same array and test that.  TempDB can have odd patterns so you might get various performance results and growth.  Many people though do just put it on the same disks as the data.  It's up to you in this case.

It sometimes might be worth segregating disks by the app patterns and the DBs that support them.  I'm not sure if you have that option.  If you don't, your layout looks fine but without testing it's impossible to tell.  Personally I would test as much as I could first, look at how much growth we are expecting, and then see if it makes more sense to add more IOPS to the main data array, or to keep them separate.

Are you able to do any kind of benchmarking at all?