SQL Server AlwaysON从入门到进阶(2)——存储

本文属于SQL Server AlwaysON从入门到进阶系列文章

前言:

本节讲解关于SQL Server 存储方面的内容,相对于其他小节而言这节比较短。本节会提供一些关于使用群集或者非群集系统过程中对存储的利用建议。当然,重点还是集中在对于一个标准的AlwaysOn可用组配置过程中,对存储的选择和配置上面。

AlwaysOn的部署首先建立在一个Windows Server Failover Cluster(WSFC)上。并且每个服务器通常有一个独立的SQL Server实例。另外,每个服务器使用其本地存储来存放独立的SQL Server实例的数据库文件(数据文件、日志文件、备份文件等)。虽然所有伙伴节点都属于同一个群集,但是不需要基于硬盘见证或者故障转移实例,也没有共享存储的要求。从而避免了FCI中的共享存储单点故障风险。但是AlwaysOn可用组可以使用FCI作为可用副本。这个不仅又重新引入单点故障的风险,也增加了群集对节点的复杂度。

言归正传,现在来看一下存储系统的核心内容:

  • 本地存储(Localized)
  • 网络存储(Networked)

下面来详细介绍一下:

本地附加存储(Locally Attached Storage):

这种模式下,本地存储是直接连到服务器上,硬盘直接插入硬件背板(backplane),然后连到服务器的主板上。较老的配置可能会包含将通过68/80针电缆连接到PCI总线的扩展RAID控制器上。

下图是一个典型的本地存储示意图。这是相对来说路径断和复杂度低的,可提供快速硬盘访问的方式。背板有一个输入输出BIOS,可以用于控制横跨本地硬盘的RAID阵列的硬盘冗余功能,但是由于硬件服务器的限制,通常最大只有16个硬盘可用。

这是典型的没有网络存储的节点中的单独存储示意图,在WSFC中,没有独立的存储共享给其他节点。这也使得查分节点的物理位置过程中,不需要对存储进行复制。

网络存储(Network Storage):

网络存储可以作为资源提供给多个计算机系统。有一个中央存储库通过降低很狂每个服务器的多个阵列的接触点从而更为简单地管理这些硬盘。如下图所示,通常系统中有很多服务器通过光纤(Fibre Channel,FC)网络互联,通常也称为“Fabric”。计算机通过一个Host Bus Adapter(HBA卡,主机总线适配器是网络与交换,是能插入计算机或大型主机的板卡),实际上HBA卡类似于一个网卡。

各个服务器也可以通过iSCSI网络进行互联,这个网络相对较新但带宽受限(1Gbps)。它运行在标准的、隔离的TCP\IP网络。服务器通常使用专用网卡,只用于iSCSI和TCP通信从而降低负载,意味着iSCSI的流量控制被分摊出来。现代iSCSI已经可以处理上限为10Gbps的带宽数据。对iSCSI配置的好处之一是它币传统的FC网络更加经济。但是,也不总是这样。

当有很多服务器发送请求给存储进程并从中接收结果时,可以快速发现在FC网络中产生了多少流量。正如TCP\IP网络那样,你会发现FC网络会被堵满。然后存储区域的网络会因此产生性能问题。在复杂的SAN配置中,会有多个交换机连接大量的网线和额外电源需求。如上图,可以看到这种情况下数据流动路径和复杂度都明显变大。

在这么长的路径和复杂路由中提出I/O请求,会消耗很多事件和其他开销。关于整合的存储,这类系统能提供什么呢?这类存储可以更容易地调配和交付资源给大规模的数据。然后就像虚拟化,不是每个实体都可以用。

这种模式的存储也常用于SQL Server 的FCI中,LUNs从磁盘阵列中划出来,而且数量巨大。这里的缺点是阵列可能被以128KB的块大小格式化。这个大小对于SQL Server来说并非最优化。其优点是,当被合理配置后,存储请求几乎可以不到末端阵列。因为请求可以直接发生在高速内存缓冲区,然后缓存的数据在合适的时间点被刷到硬盘从而降低对性能的影响。在停电时,后备电源也会把缓存中的数据刷新到硬盘以免数据丢失。

另外还有一种网络存储可用于在高可用节点中共享存储又避免多个主机连接的开销。这种存储类型称为Direct Attached Storage(DAS,直接附加存储),这类系统专门为可以使用基于私有光纤连接、基本上可以归到本地化的应用而设计。下面是一个典型的私有高可用存储配置示意图:

这个场景下,如果想创建私有高可用群集,会稍微比本地存储更好。一些存储供应商提供通过光纤连接的设备,并可以有最多两个主机连接到高可用方案的多个路径中。多个阵列存储模块可以顺便增加可用存储量。

这类存储也可以用于SQL Server FCI中。这种方式适合在特定环境下的小型或简单群集中少数几个节点共享存储之用。你可能已经注意到上图中LUNs的方式是一个方框,这是因为不是所有的Windows系统的逻辑硬盘底层都有独立的物理阵列。上图的情景也是最常见的配置中,磁盘被设置为一个较大的阵列。

想象一个大蛋糕。或者在这种情况下,从物理硬盘池中创建的阵列。切下一块蛋糕或者从阵列中划出一个LUN用于给Windows作为逻辑硬盘之用。

总结:

这一篇介绍了为群集和独立的SQL Server实例配置稳定坚固的典型存储要求。下一节会着重介绍支持WSFC和FCI及AlwaysOn可用组所需的基础设施。

时间: 2024-10-07 18:00:51

SQL Server AlwaysON从入门到进阶(2)——存储的相关文章

SQL Server AlwaysON从入门到进阶(1)——何为AlwaysON?

本文属于SQL Server AlwaysON从入门到进阶系列文章 本文原文出自Stairway to AlwaysOn系列文章.根据工作需要在学习过程中顺带翻译以供参考.系列文章包含: SQL Server AlwaysON从入门到进阶(1)--何为AlwaysON? SQL Server AlwaysON从入门到进阶(2)--存储 SQL Server AlwaysON从入门到进阶(3)--基础架构 SQL Server AlwaysON从入门到进阶(4)--分析和部署Windows Ser

SQL Server AlwaysON从入门到进阶(6)——分析和部署AlwaysOn Availability Group

前言: 本节是整个系列的重点文章,到现在,读者应该已经对整个高可用架构有一定的了解,知道独立的SQL Server实例和基于群集的SQL Server FCI的区别.上一节已经介绍了如何安装SQL Server Failover Cluster Instance(FCI)及其要求. 本节会深入AlwaysOn 可用组的内容,以演示部署为主线,包括如何启用只读路由和使用AlwaysOn组侦听器.并在最后演示故障转移. 在前面文章中对FCI和AlwaysOn可用组有了一定的平台要求.这里对其进行简要

管理SQL Server AlwaysOn(5)——常规监控(1)——常规监控

本文属于管理SQL Server AlwaysOn 系列文章 前言: 前面几节提到了如何对AlwaysOn做常规管理,这一节和接下来的一节专门对"监控"进行解释和演示.管理和监控这两个词在很多时候是混淆的,但是我们大概也可以区分出来,比如我做备份,算管理,对错误.异常进行响应这也是管理,但是对错误.异常的捕获和通知DBA这就是监控了,而且监控有时候是不需要进行干预的,比如我监控磁盘空间,当空间充足的时候,我可以不管. 在日常的DBA工作中,我本人对监控的重视程度远大于所谓的管理,因为有

SQL Server AlwaysON 同步模式的疑似陷阱

SQL Server 2012 推出的最重要的功能之一Alwayson,是一个集之前Cluster和Mirror于一体的新功能,即解决了Cluster依赖共享存储的问题,又解决了镜像不能实时读以及转移后连接串需要添加转移IP的问题,看起来的确很实用. 而且Alwayson多副本的功能为实现读写分离提供了可能,试想一下,当主副本压力比较大的时候,是否可以将读操作引向辅助副本呢?答案一般来讲是肯定的,请注意,是一般! Alwayson有两个同步模式,同步和异步,即然是同步,理所当然的我认为他是实时的

从0开始搭建SQL Server AlwaysOn 第一篇(配置域控)

从0开始搭建SQL Server AlwaysOn 第一篇(配置域控) 网上的 AlwaysOn可以说是非常的多,也可以说是非常的千篇一律,而且很多都是搭建非常顺利的,没有坑的,难道搭建 AlwaysOn真的可以这麽顺利吗?????? 由于公司使用的是最新的Windows Server 2012 R2,网上用的都是Windows Server 2008 R2 ,2012 R2和2008 R2在故障转移集群界面菜单和AD 服务管理工具 已经有较大变化,有一些步骤跟Windows Server 20

管理SQL Server AlwaysOn(1)——基础维护

本文属于管理SQL Server AlwaysOn系列文章 前言: 前面系列已经介绍了SQL Server AlwaysOn的知识点.安装演示及注意事项等.但是这并不是终点,更多的反而是起点.就像不能生了孩子就不管,你还得养(管理).作为DBA,更多的工作内容恰恰就是管理AlwaysOn.所以这里单独列出一个系列介绍SQL Server AlwaysOn的管理.本系列沿用从0开始部署基础的AlwaysOn 的环境. 在这个系列中,准备讲述以下内容: 管理SQL Server AlwaysOn(1

在权限受限制的AD域环境中部署SQL Server AlwaysOn高可用性

最近在给一个客户部署基于微软TFS的软件生命周期管理平台时,客户要求数据库层实现高可用性,减少因数据库服务器故障影响软件开发进展. 客户现有域是一台搭建在Windows Server 2008上的级别为Windows 2008的企业域.为了符合客户企业域的安全规定,需要在部署数据库高可用性期间使用最低权限,即只赋予操作账户(tfsadmin)在AD目录中用于ALM的组织单元的完全权限.在综合考虑和调用的基础上,我们提出了以下方案,并附上了操作说明. 方案: 1. 在AD域中为ALM创建用于保存计

SQL Server AlwaysOn日志收缩

当前好多项目都在逐渐的采用SQL Server AlwaysOn架构来作为数据库的高可用集群技术. 并且当前微软的大多数产品.Citrix XenDesktop.XenApp.PVS.XenMobile也都支持该技术,AlwaysOn兼具了Mirror和Cluster的双重优势,既能实现唯一的主机名.IP地址访问,由不需要像集群那样必须使用共享存储,而是可以像Mirror一样,将数据保存为多个副本,同时AlwaysOn还具有多读多写的架构,可以非常有效地提高数据库性能,单个AlwaysOn组最大

从0开始搭建SQL Server AlwaysOn 第二篇(配置故障转移集群)

从0开始搭建SQL Server AlwaysOn 第二篇(配置故障转移集群) 第一篇http://www.cnblogs.com/lyhabc/p/4678330.html 第二篇http://www.cnblogs.com/lyhabc/p/4682028.html 这一篇是从0开始搭建SQL Server AlwaysOn 的第二篇,主要讲述如何搭建故障转移集群,因为AlwaysOn是基于Windows的故障转移集群的 在讲解步骤之前需要了解一下故障转移集群仲裁配置 下面图片来自<Wind