SQL Server:共享磁盘柜性能

SQL Server:共享磁盘柜性能

我们的服务器管理员制定了一个计划,将所有存储移至中央磁盘柜,并让每台服务器都使用它。我们有一个使用率很高的中央 SQL Server(200+ 个并发用户),我担心这可能会严重影响性能。

使用中央磁盘柜存储 SQL Server 数据库安全吗?这会影响性能吗?或者是否可以建立与许多其他服务器共享磁盘柜的快速 SQL Server 设置?

答案1

性能不是简单地说“嘿,我有一台有 200 个用户的 SQL 服务器,我的性能负载是多少?”。您对服务器的当前性能(特别是磁盘性能)了解多少?这就是我要开始讨论的地方。

此外,因为有 200 个用户访问该服务器而说该服务器使用率很高也不是分析性能的最佳方法。这不仅仅是用户数量,还包括事务数量、事务性质等。我有一台 SQL 服务器,有 2,000 个用户访问它,但根据我监控和绘制的性能指标,我不认为它使用率很高。

答案2

使用中央磁盘柜存储 SQL Server 数据库是否安全?

只要它是一个足够好的中央 SAN 盒,那么是的,您会希望它具有双控制器和磁盘路径以及大量主机端口,但是是的,它可以很容易地变得更加安全。

这会影响性能吗?或者是否可以建立一个与许多其他服务器共享磁盘柜的快速 SQL Server 设置?

它肯定会影响性能,性能可能会根据 SAN 配置而上升或下降,但几乎肯定不会保持不变。根据配置,您可以从质量更好、速度更快、缓存更多的磁盘中受益,这些磁盘在更好的 RAID 模式下工作,通过更快的链路和多条路径工作 - 或者也可能相反。

基本上,这一切都取决于这个人有多少时间、金钱和专业知识,但如果他拥有足够的这些,就没有什么可怕的。

答案3

数据库性能(特别是 SQL Server,如下所述)在 SAN 设备上可能会很慢。通常,数据库服务器上的直接连接存储子系统会更便宜、更快。一种选择是,您可以在服务器上安装 SAN 卷并将数据库备份到此卷上。使用 SAN 处理数据库工作负载有明显的优缺点:

  • 优点:如果您想要集群服务器并实现热故障转移,那么您需要一个共享磁盘。通常,这是通过 SAN 实现的,尽管还有其他架构。

  • 优点:如果您想使用刀片服务器,SAN 存储是唯一合理的选择。

  • 优点:SAN 集中磁盘存储和备份管理。

  • 优点:SAN(通常)在硬件中没有单点故障(光纤通道的关键设计特点之一),因此它们非常适合对可用性要求高的系统。

  • 缺点:要从针对通用工作负载进行调优的 SAN 中获得不错的数据库性能可能存在问题。供应商通常会建议购买专用于应用程序的 SAN,这在某种程度上违背了购买 SAN 的初衷。

  • 缺点:SAN 设备价格昂贵。通常,SAN 的成本要高于与其相连的服务器设备,尤其是当您计算运行成本和备份时。

  • 缺点:SAN 是吸引帝国建造者的另一个控制点。如果您发现自己需要另一个磁盘架,除非有专门为此分配的资金,否则前期成本也会产生内部摩擦。

我的直觉是,你应该让基础设施人员证明该系统将在 SAN 上充分运行(即对其进行基准测试)并提出可信的商业案例,然后才允许他们将服务器移到 SAN 上。

尤其是,不要购买超出实际需要的 SLA。实际上,实现高水平的可靠性非常昂贵,而仅仅将服务器放在 SAN 上并不能实现这一点,因此除非有真正的需求支持,否则这是一个荒谬的论点。

答案4

这是可以做到的,但需要时刻保持警惕。确实需要有人对现有数据库服务器进行充分的性能监控,以了解其当前的性能,然后将这些指标与集中存储进行比较。这样,您就没问题了。或者,您现有的存储 I/O 子系统可能已经出现瓶颈,添加一些主轴即可解决该问题。

为了让您了解我所说的内容,如果您现有的存储是 15K 驱动器的镜像对,则根据确切的访问模式,可以合理地预期 150-500 个并发 I/O 操作(高度随机的会更低,但您的数据库备份/导出过程可能是连续的,因此会更高)。如果中央存储是 24 个 15K 驱动器,您可以预期获得 3000 到 8000 个并发 I/O 操作(存储网络愿意)。根据您与之竞争的其他内容,您的数据库最终可能会在 I/O 方面拥有更多的余量。

但你必须弄清楚你目前的表现才能确定。

相关内容