Answers:
日志和数据驱动器具有不同的数据访问模式，它们在共享驱动器时会相互冲突（至少在理论上是冲突的）。
日志写入
日志访问包含大量的小顺序写入。简单地说，DB日志是环形缓冲区，其中包含将数据项写出到磁盘上特定位置的指令列表。访问模式由必须保证完成的大量小顺序写入组成，因此它们被写到磁盘上。
理想情况下，日志应位于安静的RAID-1或RAID-10卷上（即不与其他任何共享）。从逻辑上讲，您可以将该过程视为主要的DBMS，写出日志条目以及一个或多个消耗日志的日志读取器线程，并将更改写出到数据磁盘（实际上，该过程已得到优化，以便写入数据在可能的情况下立即退出）。如果日志磁盘上还有其他流量，则磁头会因其他访问而移动，并且顺序日志写入将变为随机日志写入。这些速度要慢得多，因此繁忙的日志磁盘会创建一个热点，成为整个系统的瓶颈。
数据写入
（已更新）日志写入必须提交到磁盘（称为稳定媒体），以使事务有效并符合提交条件。可以逻辑地将其视为正在写入的日志条目，然后用作通过异步过程将数据页写出到磁盘的指令。实际上，磁盘页写操作实际上是在创建日志条目时进行准备和缓冲的，但是并不需要立即写入它们以提交事务。磁盘缓冲区通过Lazy Writer进程写到稳定的介质（磁盘）中（感谢Paul Randal指出了这一点），Tech Tech文章对此进行了详细讨论。
这是一种高度随机的访问模式，因此与日志共享相同的物理磁盘会造成人为的系统性能瓶颈。日志条目必须书面提交事务，所以有随机寻道减缓这个过程（随机I / O是多少比顺序日志I / O速度较慢）将开启日志从sequenital成随机存取设备。这会在繁忙的系统上造成严重的性能瓶颈，应避免使用。与日志卷共享临时区域时也是如此。
缓存的作用
SAN控制器往往具有较大的RAM缓存，可以在一定程度上吸收随机访问流量。但是，为了实现事务完整性，需要保证从DBMS进行磁盘写入。当控制器设置为使用回写缓存时，将对脏块进行缓存，并将I / O调用报告为已完成给主机。
这可以消除许多争用问题，因为缓存可以吸收大量I / O，否则这些I / O会流到物理磁盘。它还可以优化RAID-5的奇偶校验读写，从而减轻RAID-5卷对性能的影响。
这些都是推动“让SAN处理”思想的特征，尽管这种观点有一些局限性：
回写式缓存仍然具有可能会丢失数据的故障模式，并且控制器已转为使用DBMS，称已将块写出到磁盘，而实际上并没有。因此，您可能不希望对事务性应用程序使用回写缓存，尤其是某些存储任务关键或财务数据的数据，其中数据完整性问题可能会对业务造成严重影响。
SQL Server（特别是）以一种方式使用I / O，在这种方式下，标志（称为FUA或强制更新访问）会在调用返回之前强制对磁盘进行物理写入。微软有一个认证程序，许多SAN供应商生产的硬件都具有这些语义（此处总结了要求）。在这种情况下，没有任何数量的缓存将优化磁盘写入，这意味着如果日志流量位于繁忙的共享卷上，则流量将猛增。
如果应用程序生成大量磁盘流量，则其工作集可能会超出缓存，这也将导致写争用问题。
如果SAN与其他应用程序共享（尤其是在同一磁盘卷上），则来自其他应用程序的流量可能会产生日志瓶颈。
一些应用程序（例如数据仓库）会产生较大的瞬时负载峰值，从而使其在SAN上非常反社会。
即使在大型SAN上，仍建议使用单独的日志卷。您可能不担心在轻度使用的应用程序上的布局而感到困惑。在真正的大型应用程序上，您甚至可以从多个SAN控制器中受益。Oracle发布了一系列数据仓库布局案例研究，其中一些较大的配置涉及多个控制器。
将绩效归于责任
在大容量产品或性能可能成为问题的产品上，请SAN团队对应用程序的性能负责。如果他们将忽略您的配置建议，请确保管理层意识到这一点，并且将系统性能的责任放在适当的位置。特别是，为关键的数据库性能统计数据（例如I / O等待或页面闩锁等待或可接受的应用程序I / O SLA）建立可接受的准则。
请注意，将绩效责任分散到多个团队中会激励人们相互指责，并将责任推卸给另一个团队。这是一种已知的管理反模式，是解决拖延了数月或数年却从未解决的问题的公式。理想情况下，应该只有一个架构师有权指定应用程序，数据库和SAN配置更改。
另外，对负载下的系统进行基准测试。如果可以安排，则可以在Ebay上便宜地购买二手服务器和直接连接阵列。如果使用一个或两个磁盘阵列设置一个类似的框，则可以使用物理磁盘配置来限制并评估对性能的影响。
举例来说，我对大型SAN（IBM Shark）上运行的应用程序和具有直接连接的U320阵列的两路机箱进行了比较。在这种情况下，在eBay上购买的价值3,000英镑的硬件在100万英镑的高端SAN上的性能要高出两倍-在具有大致相同的CPU和内存配置的主机上。
从这一特殊事件中，可能会争辩说，像这样的事情四处散布是使SAN管理员保持诚实的一种很好的方法。
我假设Equallogic标记和请求的内容意味着您正在考虑Equallogic SAN。接下来的内容是关于Equallogic的，不适用于其他SAN类型。
使用Equallogic阵列时，无法像使用EMC Clariion阵列那样精确地指定用于卷的特定磁盘，因此方法必须有所不同。
Equallogic体系结构是非常自动化和动态的。它的基本构件是阵列单元，而不是其他SAN中看到的阵列中的RAID包/组。每个阵列都针对RAID 5、6、10或50进行了完整配置，尽管这并不意味着每个阵列只有一个RAID组，您永远都无法在该级别上决定或与其交互。您将阵列放入存储池中，然后这些池就属于一个存储组。存储组具有一个群集\虚拟ip地址，您可以用作该组中所有卷的iSCSI发现目标-EQL组管理软件和主机MPIO堆栈处理实际路由到最合适的端口所需的ip级重定向请求数据块时使用单个数组，但是您几乎无法控制。
存储量是从每个池的总可用空间中分配的。池中的所有卷分布在该池中的所有阵列中（最多4个单独的阵列），以便在网络接口的总数（每个Eql阵列2-4个，具体取决于型号）和IO中分配网络IO跨尽可能多的控制器。Equallogic管理软件会随时间监视卷\阵列性能，并动态优化成员阵列中块的分布。通常，除非您知道自己在做什么，否则应将所有阵列放在一个池中，并让它执行其操作，只是要记住确保使用RAID 10配置高速磁盘（SAS 10k \ 15k），使用RAID 50配置中等速度或5，以确保优化过程实际上选择了真正的高性能驱动器。
大致估计，根据驱动器类型和RAID类型，每个PS阵列将有2500-5000 IOP。如果您提供了足够的总IOP，那么即使您只是将所有卷都集中到一个池中，自动化管理过程最终也将为您提供良好的性能。
但是，如果您想保证日志，数据库，临时存储，操作系统驱动器等实际上彼此隔离，则可以执行以下操作。首先，您可以为卷定义RAID首选项，以确保特定卷始终仅存储在该RAID类型的阵列上（如果卷所属的池中存在阵列）。其次，您可以定义分层存储池，该存储池仅包含可提供特定层所需的各种性能等级的阵列，然后将卷分配到适当的池中。这种方法附带的运行状况警告是，通常需要很多阵列才能真正提供更好的整体性能-尽管对保证关键卷的性能而言，这可能不如保证关键卷上的性能重要，但它通常仍然是最好的选择。戴尔针对Oracle DB的参考体系结构使用一个池，其中包含2个RAID 10阵列用于数据，表决磁盘和OCR，而另一个池则具有一个RAID 5阵列用于闪存恢复区。
在使用Equallogic的所有时间点上，您都应该问自己，就可用分区而言，就可用网络接口，磁盘轴和控制器而言，是否要为卷提供更好的聚合性能。如果您无法回答，请选择最少数量的池并让其处理细节，或请Equallogic专家进行实际设计。如果只有一个阵列，那么在分离卷方面您无能为力。
好问题！
首先看一下布伦特·奥扎尔（Brent Ozar）关于此问题的“钢笼博客匹配”辩论。
在我们公司中，对于大多数服务器，我们将数据和日志放在同一SAN驱动器上，然后交给SAN团队来确保一切正常。
我开始认为这不是最佳策略，尤其是对于大容量服务器。潜在的问题是，除了为我们所需的空间分配足够的驱动器之外，我真的没有办法验证SAN团队在做什么。我们不会从我们这边或任何方面针对SAN驱动器运行IO基准测试，我们只是假设它们正在“完成工作”（针对性能和空间进行调整），这可能有点天真。
我的另一个想法是，数据与日志所需的访问类型不同。我将尝试查找我最近阅读的文章，该文章讨论了如何真正以两种不同的方式优化两种不同的驱动器类型（我认为一种需要针对顺序写入进行优化，另一种需要针对随机读取进行优化，诸如此类） ）
简而言之，是的，您将为SQL Server数据文件，日志文件以及TempDB数据和日志文件创建单独的卷。
由于您使用Equallogic标记了问题，因此在设计解决方案之前，请通读免费的《Dell参考体系结构指南：使用Dell™EqualLogic™PS5000系列存储阵列部署Microsoft®SQLServer®》（需要注册）。通常，您会发现有关特定配置的指南可能与一般建议有很大的不同。
在性能方面，我会同意BradC（+1）。通常，一个好的SAN将具有比您预期使用的更多的原始I / O。
从您的实时系统中分离出您的备份仍然是一个好主意（很明显，我知道，但是如果我每次看到这个都花了£1……）
另外，建议使tempdb远离日志文件。当您开始需要Logs，Data和Temp的“不同存储桶”（技术术语）时，SAN家伙的帐篷会注视着您，但是如果您告诉他们，那么您可以衡量前往每个区域和让他们向您展示他们的出色表现图！
只需仔细检查一下SAN专家是否已为您正确设置了它。如果您想要RAID 10，请坚持（我同意），即使他们一直说RAID 5不会降低性能。
（对于“基于文件”的操作，RAID 5很好。对于密集型写入，只要您写满了写入缓冲区，就可以拧紧！）