标准做法是将日志和数据文件分开，将磁盘与操作系统分开（tempdb、备份和交换文件也是如此）。当您的驱动器全部基于 SAN 且您的 LUNS 不是由特定磁盘或 RAID 组划分而成时，这种逻辑是否仍然有意义 - 它们只是 SAN 上 x 个驱动器的一部分，而 LUN 只是空间分配
答案1
日志和数据驱动器具有不同的数据访问模式，当它们共享一个驱动器时，它们会相互冲突（至少在理论上）。
日志写入
日志访问由大量小的连续写入组成。简单地说，DB 日志是环形缓冲区，其中包含将数据项写入磁盘上特定位置的指令列表。访问模式由大量必须保证完成的小的连续写入组成 - 因此它们被写入磁盘。
理想情况下，日志应位于安静的（即不与其他任何东西共享）RAID-1 或 RAID-10 卷上。从逻辑上讲，您可以将该过程视为主 DBMS 写出日志条目，一个或多个日志读取器线程使用日志并将更改写入数据磁盘（实际上，该过程经过优化，以便尽可能立即写出数据写入）。如果日志磁盘上有其他流量，则这些其他访问会移动磁头，并且连续的日志写入将变成随机日志写入。这些速度要慢得多，因此繁忙的日志磁盘可能会创建一个热点，从而成为整个系统的瓶颈。
数据写入
（已更新）日志写入必须提交到磁盘（称为稳定介质），事务才有效并有资格提交。逻辑上可以将此视为正在写入的日志条目，然后将其用作异步进程将数据页写入磁盘的指令。实际上，磁盘页面写入实际上是在创建日志条目时准备和缓冲的，但它们不需要立即写入事务才能提交。磁盘缓冲区由 Lazy Writer 进程写入稳定介质（磁盘）（感谢 Paul Randal 指出这一点），这篇 Technet 文章更详细地讨论。
这是一种高度随机的访问模式，因此与日志共享相同的物理磁盘可能会对系统性能造成人为的瓶颈。必须写入日志条目才能提交事务，因此随机寻道会减慢此过程（随机 I/O 是很多比顺序日志 I/O 慢）会将日志从顺序设备变为随机访问设备。这在繁忙的系统中会造成严重的性能瓶颈，应避免这种情况。与日志卷共享临时区域时也会出现同样的情况。
缓存的作用
SAN 控制器往往具有较大的 RAM 缓存，可以在一定程度上吸收随机访问流量。但是，为了保证事务完整性，最好保证 DBMS 的磁盘写入操作能够完成。当控制器设置为使用写回缓存时，脏块将被缓存，并且 I/O 调用将报告给主机，表示已完成。
这可以消除许多争用问题，因为缓存可以吸收大量原本会流向物理磁盘的 I/O。它还可以优化 RAID-5 的奇偶校验读写，从而减轻 RAID-5 卷对性能的影响。
这些是推动“让 SAN 处理它”思想流派的特征，尽管这种观点具有一些局限性：
写回缓存仍然有可能导致数据丢失的故障模式，并且控制器会向 DBMS 撒谎，称数据块已写入磁盘，但实际上并没有。因此，您可能不想将写回缓存用于事务性应用程序，尤其是保存关键任务或财务数据的应用程序，因为数据完整性问题可能会对业务造成严重后果。
SQL Server（特别是）使用 I/O 时，在调用返回之前，标志（称为 FUA 或强制更新访问）会强制将物理写入磁盘。微软有一个认证计划许多 SAN 供应商生产的硬件都符合这些语义（要求总结如下这里）。在这种情况下，再多的缓存也无法优化磁盘写入，这意味着日志流量将要如果它位于繁忙的共享卷上，则会受到重击。
如果应用程序产生大量磁盘流量，其工作集可能会超出缓存，这也会导致写入争用问题。
如果 SAN 与其他应用程序共享（特别是在同一个磁盘卷上），来自其他应用程序的流量可能会产生日志瓶颈。
一些应用程序（例如数据仓库）会产生较大的瞬时负载峰值，这使得它们在 SAN 上非常不合群。
即使在大型 SAN 上，仍建议使用单独的日志卷。对于使用频率不高的应用程序，您可能无需担心布局。对于真正大型的应用程序，您甚至可以从多个 SAN 控制器中获益。Oracle 发布了一系列数据仓库布局案例研究，其中一些较大的配置涉及多个控制器。
将绩效责任放在应有的位置
对于大容量或性能可能存在问题的系统，让 SAN 团队负责应用程序的性能。如果他们要忽略您的配置建议，那么请确保管理层意识到这一点，并且系统性能的责任在适当的地方。特别是，为关键的 DB 性能统计数据（如 I/O 等待或页面闩锁等待）或可接受的应用程序 I/O SLA 建立可接受的指导方针。
请注意，将绩效责任分散到多个团队会促使人们互相指责，将责任推给其他团队。这是一种众所周知的管理反模式，也是导致问题拖延数月或数年而无法解决的惯用伎俩。理想情况下，应该有一位架构师有权指定应用程序、数据库和 SAN 配置更改。
另外，在负载下对系统进行基准测试。如果您可以安排，可以在 Ebay 上以相当便宜的价格购买二手服务器和直接连接阵列。如果您设置一个带有一个或两个磁盘阵列的盒子，您可以调整物理磁盘配置并测量对性能的影响。
举个例子，我曾对在大型 SAN（IBM Shark）上运行的应用程序和带有直接连接 U320 阵列的双插槽盒进行了比较。在这种情况下，在具有大致相当的 CPU 和内存配置的主机上，从 ebay 购买的价值 3,000 英镑的硬件的性能比价值 100 万英镑的高端 SAN 高出两倍。
从这一特定事件来看，有人可能会说，保留这样的东西是保持 SAN 管理员诚实的一种非常好的方法。
答案2
我假设 Equallogic 标签和请求内容意味着您正在谈论 Equallogic SAN。以下内容专门针对 Equallogic，不适用于其他 SAN 类型。
使用 Equallogic 阵列时，无法像 EMC Clariion 阵列那样精确指定用于卷的特定磁盘，因此方法必须略有不同。
Equallogic 架构高度自动化和动态化。其基本构建块是阵列单元，而不是其他 SAN 中看到的阵列内的 RAID 包\组。每个阵列都完全配置为 RAID 5、6、10 或 50，但这并不意味着每个阵列只有一个 RAID 组，您只是永远无法在该级别决定或与它们交互。您将阵列放入存储池，然后您的池将属于存储组。存储组有一个集群\虚拟 IP 地址，您可将其用作该组内所有卷的 iSCSI 发现目标 - EQL 组管理软件和主机 MPIO 堆栈处理在请求数据块时实际路由到各个阵列上最合适的端口所需的 IP 级别重定向，但这是您几乎没有或完全没有能力控制的。
存储卷是从每个池中的总可用空间中分配的。池中的所有卷分布在该池中的所有阵列中（最多 4 个独立阵列），以便将网络 IO 分布在所有网络接口上（每个 Eql 阵列 2-4 个，具体取决于型号），并将 IO 分布在尽可能多的控制器上。Equallogic 管理软件会随时监控卷\阵列性能，并动态优化成员阵列之间的块分布。一般来说，除非您知道自己在做什么，否则您应该将所有阵列放在一个池中，让它自己做，只需记住确保您将高速磁盘（SAS 10k\15k）配置为 RAID 10，中速磁盘配置为 RAID 50 或 5，以确保优化过程实际选择真正的高性能驱动器。实际上可能需要花费相当多的天数 (7 天以上) 才能达到最佳状态，但总的来说，它应该很快达到平衡分布，因为它在最初创建时会立即将卷分配到尽可能多的阵列上 (最多 4 个)。
粗略估计，每个 PS 阵列的 IOP 介于 2500-5000 之间，具体取决于驱动器类型和 RAID 类型。如果您提供足够的总 IOP，那么即使您只是将所有卷集中到一个池中，自动化管理流程最终也会为您提供良好的性能。
但是，如果您想保证日志、数据库、临时存储、操作系统驱动器等实际上彼此隔离，您可以做几件事。首先，您可以为卷定义 RAID 首选项，这将保证特定卷始终仅存储在该 RAID 类型的阵列上（如果它们存在于卷所属的池中）。其次，您可以定义分层存储池，该池仅包含可提供该特定层所需的各种性能等级的阵列，然后将卷分配到适当的池中。这种方法带来的健康警告是，您通常需要大量阵列才能真正提供更好的整体性能 - 这对您可能不如保证关键卷的性能重要，但通常它仍然是最佳选择。戴尔的 Oracle DB 参考架构使用一个池，其中有 2 个 RAID 10 阵列用于数据、表决磁盘和 OCR，以及一个单独的池，其中有一个 RAID 5 阵列用于闪存恢复区域。
在使用 Equallogic 时，您应随时问自己，您就强制分区做出的决定是否会在可用网络接口、磁盘轴和控制器方面为您的卷提供更好的总体性能。如果您无法回答，则选择最少数量的池并让其处理细节或让 Equallogic 专家进行实际设计。如果您只有一个阵列，那么在分离卷方面您无能为力。
答案3
我们将数据库存储在单个 SAN 盒中，但数据、日志和备份 LUN 是分开的，每个 LUN 位于不同的磁盘组上，按速度分层 - 将日志存储在 RAID 10 15Krpm LUN 上，将数据存储在 RAID 1 10/15krpm LUN 上，将备份存储在 RAID 5 7.2krpm LUN 上。我们还通过同一 SAN 上的不同控制器呈现日志和数据。
答案4
简而言之，是的，您可以为 SQL Server 数据文件、日志文件以及 TempDB 数据和日志文件创建单独的卷。
由于您使用 Equallogic 标记了您的问题，请阅读免费戴尔参考架构指南：使用 Dell™ EqualLogic™ PS5000 系列存储阵列部署 Microsoft® SQL Server®（需要注册）在设计解决方案之前。通常你会发现对特定配置的指导可能与一般建议有很大不同。