SQL Server – 本地存储(ssd's)vs SAN

我计划更改可能SQL Server的硬件,并将其升级到SQL Server 2016 Enterprise。 AlwaysOn AG将build立在两个节点之上+ dr。

我有两个选项来存储

只有本地磁盘,RAID1中的ssd,Windows,Data,Logs和TempDb具有单独的磁盘,本地存储与ssd的TempDb(RAID1)混合,其余磁盘的Windows,数据和日志将从networking上的SAN我个人更喜欢本地存储上的所有东西,因为:

您摆脱单点故障(SAN)在本地存储上更快的速度,SAN将不会有ssd的没有networking瓶颈使用本地存储有什么主要的缺点?

正在使用SAN进行存储更好的select?

不pipe解决scheme如何,硬件都将从硬件提供商那里租用。 所以不会涉及买入。

提前致谢!

关于微软的文档,您应该使用本地存储或共享存储或Microsoft Storage Spaces Direct。

假设你实现MSSQL服务器的可用性,我build议你去本地存储,为每个主机相同的设置,这将为您提供相同的性能节点故障的情况下。

使用共享存储,如果你想使用MSSQL FCI。

至于SAN,它的SPoF。 恕我直言

一如既往,一切都有很多优点和缺点。

存储arrays提供高容量和集中pipe理。 您可以快照一些卷并将它们呈现给其他主机。 尽pipe用于连接SAN的交换机和线缆可能会更复杂一些。

本地存储所涉及的服务器节点较less,可能对操作系统pipe理员更为熟悉。 除非添加类似磁盘机箱的内容,否则服务器容量可能有限制。

数据库级别的复制使得使用两个独立的存储系统来实现业务连续性解决scheme相对容易。 存储级别故障可以通过激活DR来缓解。 单点故障分析仍然是一个好主意,检查冗余电源和SANpath等。 DR副本可能位于远程站点,如果主要副本不可用,恢复速度将更快。

就个人而言,我看到SAN成为过去时代的遗迹。 不要误会我的意思 – 就像他们有自己的位置的主机一样,并且适当地使用它们是非常有价值的。 没有它们,大型虚拟化设施就不可能实现。 曾几何时,像SAN这样的共享存储是使SQL Server或VMWare ESXi等高可用性的唯一方法。

但是要获得与本地SSD存储一样快的SAN是非常昂贵的。 要获得像NVMe存储一样快的产品(如Intel P3608)分成六个数字。 如果您不需要4TiB的存储空间,那么比较便宜的是4TiB P3608。

使用SQL Server Always On提供了一个很好的高可用性选项,使用本地存储,同步或asynchronous复制选项以及分布式可用性组 ,没有理由为绝大多数新的SQL Server安装部署SAN。

就SQL Server而言,使用本地存储没有任何不利之处。