sql-server-2008 – SQL Server文件本地或NAS还是SAN？

我应该使用iSCSI怎么样？

SAN怎么样？

服务器有4Gb的RAM,该数据库文件大约2GB.

为了让我自己清楚今天服务器没有RAID,我必须实施某种策略,所以如果发生了什么事我可以保证我的文件安全,那么我应该选择本地文件,NAS,SAN？什么选项具有最高性能,哪些更安全？

解决方法

绝对不是SQL Server的NAS. SMB / CIFS没有足够的文件锁定支持来支持DBMS(至少在几年前,大约2002-2003).请注意,NFS确实可以在NFS服务器上使用Oracle执行此操作.但是,由于协议的限制,CIFS共享上的SQL Server不可靠.它甚至可能不允许您将文件放在CIFS挂载的共享上.

SAN

这对于事务性应用程序很有用,因为RAID控制器上的缓存可以吸收相当大的工作集. SAN RAID控制器通常支持比基于主机的RAID控制器更多的缓存,特别是在高端套件中,其中RAID控制器可能是一个与服务器一样强大的多处理器盒.

具有双控制器的SAN还具有无单点故障的架构,并提供许多热备份选项.这使他们从可管理性和可靠性的角度来看是一场胜利.然而,它们是昂贵的并且受限于流数据量,尽管后者不太可能是事务系统上的问题.

对于操作系统,SAN几乎总是最佳选择(如果可用).它们也可以在运行中低容量系统的多个服务器之间共享.然而,它们带有价格标签,在该技术可以使用的最小系统上具有相当大的下限.

直接附加

在某些情况下,直接连接存储是最好的.一种可能性是带宽受限的流应用,其中有限数量的光纤通道连接将可用带宽限制为低于高端SAS控制器可能的带宽.但是,这些可能是相当专业的应用程序,例如非常大的数据仓库,其中shared-nothing架构可以提供最佳吞吐量.

实际上,出于多种原因,直接连接存储通常比SAN更适合数据仓库系统：

>数据仓库在磁盘子系统上引入了大量瞬态负载峰值.这使得它们在SAN上非常反社交,因为它们会影响SAN上其他系统的性能.
>上述流媒体瓶颈.
>直接连接存储比SAN存储便宜得多.

直接连接存储的另一个市场是当你向一个不能为SAN支付足够资金的市场销售时.这通常适用于销售给SMB客户的应用程序.对于具有六个用户的销售点系统或实践管理系统,SAN可能是过度的.在这种情况下,具有一些内部磁盘的小型独立塔式服务器是更合适的解决方案.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!