我以前问过这个ServerFault的问题： 有没有人有左手VSA SAN的经验
一般认为，即使在轻负载下，生产SQL服务器的性能也不够好。
所以，新的问题是，LeftHand的SAN如何在惠普或戴尔专用硬件盒上执行？
我们正在考虑在2路复制中使用2个HP节点的Starter SAN，2台ESX服务器总共托pipe2台Active Directory服务器，1台MS SQL服务器，1台文件服务器和1台通用服务器，所有的Microsoft Server 2005或2008）。
我看LeftHand的原因是完整的软件包。 我打算build立一个灾难恢复站点，比如SAN如何在异地执行asynchronous复制，而无需返回供应商获取更多许可证。
我也喜欢Network Raid架构中的冗余。
我看过其他的SANS，发现了不同的错误。
例如，戴尔的EqualLogic：发现虽然单个硬件盒非常冗余，但是跨越多个盒子的数据并不是多余的，如果某个节点出现故障，您将失去硬件上唯一的数据副本（一件事是肯定的，所有的硬件都会失败…什么时候是唯一的问题）。
我也使用了XioTech SAN。值得花钱，但是我认为这对于我所针对的办公室来说太过分了。 在XioTech中获得硬件冗余的成本使得我工作的预算有点不可及。
谢谢，
基思
大约一年前，我在惠普硬件上获得了几个关于性能基准testing的资料，我在LeftHand VSA SAN问题中也提到了一些同样的问题 。
那时候，LeftHand的iSCSI多path并不是真正的主动/主动。 假设你有：
当您在访问数据文件的SQL Server上运行查询时，尽pipe您使用的是四个网卡，但只能获得1GB的读取吞吐量。 LeftHand设备（实际上，我见过的所有iSCSI SAN设备）只会将数据从SAN发送到SQL Server上的一个特定MAC地址。
您可以通过以下方法解决此问题
如果你需要超过1GB的吞吐量，那么直到你听到一个真正把它拉下来的人，并且可以向你展示（不仅仅是说“哦，它在我的l337 b0xx0r上工作的很好”），那么不要投资你的钱。
光纤通道不一定是不同的：只需轻松获得4Gb光纤连接而不是1Gb以太网。 你仍然有相同的path挑战。 我正在下周在IndyPASS上做一个介绍，巧合的是 – 如果你在这个地区，那么就在那里 。
也许我们可以从Brent得到更多的input，但是我不认为asynchronous的SAN复制可以与SQL Server数据文件一起工作，你必须做一些事情，比如数据库镜像/日志传送。 或者至less，这是我一直认为的，还没有特权来亲自testing。
任何人都可以确认或否认？
那么，如果在SAN块级别完成复制的情况下，你不能只是假设日志传送也不会落后。 两种复制技术都会在一段时间内完成，对吧？ 那么担心的是数据丢失与数据损坏？ 如果整个差异更新没有收到，我不认为SAN复制将被认为是可用的。 那么数据是否被破坏或者简单的丢失？ 如果SQL是虚拟化的，那么你不是只发送数据库或只是发送日志; 我只是不确定数据如何被损坏？