我之前问过这个 ServerFault 问题： 有谁使用过 lefthands VSA SAN
普遍的共识是，即使在轻负载下，它对于生产 SQL 服务器来说性能也不够好。
所以新的问题是，LeftHand 的 SAN 在 HP 或 Dell 专用硬件盒上的表现如何？
我们正在研究具有 2 个 HP 节点的 Starter SAN，它们进行双向复制，2 个 ESX 服务器，总共托管 2 个 Active Directory 服务器，1 个 MS SQL 服务器，1 个文件服务器，以及 1 个通用服务器，用于病毒扫描之类的操作（所有 Microsoft Server 2005 或 2008）。
我之所以考虑 LeftHand，是因为它有完整的软件包。我计划建立一个 DR 站点，并且喜欢 SAN 如何执行异步复制到异地位置，而无需返回供应商获取更多许可证。
我还喜欢 Network Raid 架构中内置的冗余功能。
我研究过其他 SANS，发现它们有不同的故障。
例如，戴尔的 EqualLogic：发现虽然单个盒子在硬件上非常冗余，但是一旦跨越多个盒子的数据就不是冗余的，如果一个节点发生故障，您将丢失位于该硬件上的唯一数据副本（有一件事是肯定的，所有硬件都会发生故障......什么时候？是唯一的问题。）。
我也使用过 XioTech SAN。顺便说一句，物有所值，但我认为对于我所针对的办公室规模来说，它有点过头了。XioTech 中的硬件冗余成本有点超出我的预算。
谢谢你，
基思
答案1
大约一年前，我在 HP 硬件上安装了几个，用于性能基准测试，我在LeftHand VSA SAN 问题也适用于此。
当时，LeftHand 的 iSCSI 多路径并非真正意义上的主动/主动。假设您有：
- 四台 LeftHand 服务器，每台配备 2 个 1GB 网卡
- SAN 上的一个卷用于存储 SQL Server 数据文件
- SAN 上的一个卷用于存储 SQL Server 日志文件
- 一台 SQL Server，配备四张 1gb 网卡，专用于 iSCSI
当您在访问数据文件的 SQL Server 上运行查询时，尽管使用了四块网卡，但读取吞吐量也只有 1GB。LeftHand 设备（实际上，我见过的所有 iSCSI SAN 设备）只会将数据从 SAN 发送到 SQL Server 上的一个特定 MAC 地址。
您可以通过以下方式解决此问题：
- 使用多个数据卷和日志卷，并手动管理哪条路径是返回服务器的“主要”路径。即便如此，您仍然只能为每个数据文件获得 1gb 的吞吐量，这会限制您的备份性能、DBCC 性能等。
- 使用10gb以太网。
- 使用真正有效的网络协作软件。我尝试过使用几个供应商，但我还没有看到他们解决这个问题。
如果您需要超过 1gb 的吞吐量，那么除非您听到有人真正做到这一点并能向您展示（而不仅仅是说“哦，是的，它在我的 l337 b0xx0r 上运行良好”），否则不要投资。
光纤通道并不一定不同：只是您可以轻松获得 4gb 光纤连接，而不是 1gb 以太网。您仍然面临相同的路径挑战。我下周将在印地通行证，巧合的是——如果你在附近，可以顺便过来。
答案2
也许我们可以从 Brent 那里得到更多意见，但我认为异步 SAN 复制不适用于 SQL Server 数据文件，您必须执行数据库镜像/日志传送之类的操作。或者至少，这是我一直认为的，但我还没有机会亲自测试它。
有人可以证实或否认吗？
答案3
好吧，如果在 SAN 块级别进行复制时出现延迟，您就不能仅仅假设日志传送不会延迟。两种复制技术都会以某个间隔进行，对吗？那么问题是数据丢失还是数据损坏？如果没有收到整个差异更新，我认为 SAN 复制不会被视为可用。那么数据是损坏的还是只是丢失了？如果 SQL 是虚拟化的，您发送的不仅仅是数据库或事务日志；我只是不确定数据是如何损坏的？