微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

sql-server – 不用关注幕后的SAN

曾几何时,我构建了自己的sql服务器,并控制了驱动器配置,RAID级别等.传统的数据,日志,tempdb,备份分离建议(取决于预算!)始终是一个非常重要的部分sql服务器设计过程.

现在使用企业级SAN,我只需要为新的sql服务器请求特定数量的驱动器空间,分为用于数据,备份和文件共享的逻辑驱动器.当然让我的工作变得更轻松,但是我有一部分感觉不舒服,我无法真正地“躲在幕后”,看看那里到底发生了什么.

我的理解是,SAN团队不会以不同的方式配置不同的“类型”驱动器(优化随机访问的数据驱动器与流式写入的日志驱动器).其中一些可能取决于SAN产品本身(我们有HP XP12000和HP XP24000),但我确信HP软件可以进行各种动态性能配置(观察IO热点并动态重新配置)优化这些LUN),以便应用程序团队和DBA不需要担心任何这些问题.关于“将所有服务器的负载分散到大量主轴上”或类似的东西.

我的问题/讨论:

>如果不在SAN团队中制造敌人,我怎样才能让自己和应用程序开发人员放心,我们的sql服务器没有配置不当的存储?只需使用perfmon统计数据?其他基准测试如sqlio?
>如果我在这些SAN驱动器上加载测试,这真的能给我一个可靠的,可重复的测量方法来衡量我们上线时会看到什么吗? (假设SAN软件可能在不同的时间点“动态配置”.)
> SAN的一部分(比如Exchange服务器)中的大量IO会影响我的sql服务器吗? (假设他们没有给每个服务器提供专用磁盘,我被告知他们不是这样)
>请求为不同功能逻辑驱动器(数据vs log vs tempdb)分离逻辑驱动器会有帮助吗? SAN会在这些上看到不同的IO活动并以不同的方式对它们进行最佳配置吗?
>我们现在正处于空间紧张状态.应用团队被告知要修剪数据存档等.空间问题会导致SAN团队就如何配置可能影响我服务器性能的内部存储(RAID级别等)做出不同的决策吗?

感谢您的想法(类似主题简要讨论过in this SF question)

解决方法

如果不在SAN团队中制造敌人,我们的sql服务器没有配置不当的存储?只需使用perfmon统计数据?其他基准测试如sqlio?

简而言之,可能没有办法真正确定.我想说的是(我是SAN管理员),如果您的应用程序达到了您的期望,请不要担心.如果您开始发现您认为可能与SAN /磁盘IO性能相关的性能问题,那么查询可能是明智之举.我没有像你那样使用太多HP存储,但在IBM / NetApp世界中,我可以从经验中说,没有太多选项可以让你“配置得很差”.如今,大多数企业存储都需要对构建raid阵列进行大量的猜测,并且不会让你做错.除非他们在同一团队中混合驱动器速度和容量,否则在大多数情况下您可以确保磁盘性能良好.

如果我在这些SAN驱动器上加载测试,可重复的测量方法来衡量我们上线时会看到什么吗? (假设SAN软件可能在不同的时间点“动态配置”.)

负载测试应该足够可靠.请记住,当您对共享SAN /磁盘阵列上的一个盒子进行负载测试时,其性能可能(并且将)会受到使用相同存储的其他系统的影响.

SAN的一部分(比如Exchange服务器)中的重IO会影响我的sql服务器吗? (假设他们没有给每个服务器提供专用磁盘,我被告知他们不是这样)

它可以.它不是关于磁盘,也不是服务器所在的磁盘.所有数据都通过磁盘控制器和SAN交换机提供.您将看到的性能在很大程度上取决于磁盘控制器如何连接到相应的磁盘架以及相应的SAN.如果整个阵列连接到单链4gbps光纤上的主干SAN,那么显然性能将受到影响.如果阵列连接在两个负载均衡的冗余SAN上,使用中继链路,则单独交换就不可能吸收太多带宽.需要考虑的另一件事是阵列能够达到多少IO / sec.只要连接的阵列和SAN正确扩展,SAN环境其他部分的大量IO就不会影响sql性能.

请求为不同功能逻辑驱动器(数据vs log vs tempdb)分离逻辑驱动器会有帮助吗? SAN会在这些上看到不同的IO活动并以不同的方式对它们进行最佳配置吗?

这可能是一个偏好问题,也很大程度上取决于您的存储管理员如何配置它.他们可以在同一个阵列或卷中为您提供三个LUN,在这种情况下它们都是相同的.如果他们在不同的阵列上,在不同的卷(物理上不同的磁盘)中为您提供了单独的LUN,那么将它们分开可能是值得的.

我们现在处于空间紧张状态.应用团队被告知要修剪数据存档等.空间问题会导致SAN团队就如何配置可能影响我服务器性能的内部存储(RAID级别等)做出不同的决策吗?

我不认为你的存储管理员会改变raid级别以释放空间.如果他愿意,那么他应该被解雇.空间问题可能导致事物的配置不同,但通常不会影响性能.他们可能会对他们给你多少空间变得更加紧张.它们可能会启用重复数据删除功能(如果阵列支持它),这可能会在进程运行时阻碍阵列的性能,但不会全天候.

原文地址:https://www.jb51.cc/mssql/81490.html

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐