管光明,梁宏坤
(1.中国移动通信集团上海有限公司 上海200061;2.上海贝尔股份有限公司 上海201206)
移动通信网络管理系统将日常运行维护管理工作信息化后,积累了与网络运行有关的海量数据,包括告警信息、性能统计信息、网络参数配置信息等。对这些数据进行深度挖掘和分析,可以实时感知网络的运行质量,提出网络容量和处理能力方面的扩容要求,及时发现故障隐患,在客户察觉前将隐患排除,保持稳定的通信质量,提高客户感知度,增强网络竞争能力。这些数据对运营商极具价值,而保存这些数据的存储系统必须要有较好的可用性和冗余特性。因此,如何设计网管中的存储系统是一个重要的课题。
通过对很多企业级IT环境的分析,发现高性能和高可用性都是通过群集方式实现的,通常是采用多服务器以实现负载均衡,采用冗余主机以实现高可用性。这些方案主要聚焦于主机的高可用性和IP连通性,而存储部分则是通过 NAS (network attached storage)/SAN (storage area network)等来实现冗余弹性。现代企业级存储系统是相当复杂的,存储网络端到端整体性能和高可用性、存储资源的配置和通道(fabric)互联等都需要精心设计和规划,采用以往随机而没有整体规划的配置方法,性能和可用性都不理想,花费也较高。
本文分析了在群集环境中提供存储资源时所面临的问题和挑战,提出了一种设计方案,综合地考虑群集环境中存储资源的规划原则、优化策略、实际部署,并且把存储流量通过不同数据路径分散到各节点,从而实现负载均衡并防止单点故障的发生。
在应用有高性能和高可用性要求时,要达到同样的处理能力,单主机方案是相当昂贵的,而群集则要便宜很多。根据实际应用场景,群集一般分为如下3种类型。
·高可用性群集:当软硬件中有一个组件失败时,群集软件把应用切换到备份节点,从而减少宕机时间,根据应用程序对连接超时的容忍程度,用户可能都没有意识到这个现象的发生。
·负荷均衡群集:服务器组中的多个实例同时运行以提供共同的业务集合,负荷在这些实例间分布,这种方式实际上形成了一台功能强大的虚拟计算机。
·计算群集:主要用于大型的并行应用,而不是事务性应用。应用和数据处理过程被划分成很多小的组件或数据集,将这些任务分配给多个计算节点处理,将计算结果组合后再进行下一步处理。
不同的应用场景有不同的群集要求,因此群集需要精心规划、提供和配置,以满足实际应用在性能和可用性两方面的要求。提供群集资源时通常会面临如下3个问题。
·群集的端到端配置中有多个组件,包括应用、服务器、网络和存储等,而群集的性能依赖于这些组件的整体表现。
·即使群集软件能够侦测到软硬组件的错误,并采取了正确措施(将业务流迁移到备份节点并重新实现负载均衡),但没有一个全面的方案进行群集资源完整的端到端配置,完全是管理人员凭经验或粗略的计算来完成,这种做法费时易错。
·目前很多群集应用都要求访问共享存储,因为它向所有节点提供的数据视图都是一致的。但是,共享存储常常要为多个应用系统提供服务,这些系统上线时间前后不一,因此共享存储的规划、部署、配置等需要进行全面系统的考虑,这也是本文重点研究的内容。
群集环境中最常用的存储技术是基于文件访问的网络存储NAS和基于数据块访问的SAN。NAS和SAN是复杂的分布系统,需要大量的人工配置,而配置水平的高低决定了存储系统整体的性能和可用性。目前有一些商用工具,如IBM的全存储产品中心(TPC)、EMC的SAN架构器,试图介入这一过程,但往往只考虑某一环节,并没有将端到端配置的所有方面加以完整考虑,导致存储系统冗余弹性不佳。例如,在高可用性群集环境中,如果设计不当,主备节点通过同一条数据路径访问共享存储,一旦这条路径上的链路或交换机失败,将导致主备节点都不能访问存储,从而导致整个业务都宕掉。这种设计还有一个大问题,由于多个群集节点通过同一路径访问存储,这条路径很快就会成为I/O瓶颈,发生拥塞,导致性能恶化。
因此,有必要对群集访问存储的整体解决方案进行研究,主要方向是提高存储资源的性能和冗余,及时动态地感知群集运行的变化。
在NAS和SAN两种存储技术中,SAN几乎没有对业务环境中的IP网络增加一点负荷,而且具有更高的性能和可用性,因此在高端环境中得到了最广泛的使用,移动网管在实际部署时也普遍采用SAN。SAN同时也是最复杂的一种存储技术,是大规模共享存储系统的发展方向,存储行业对SAN的研究要远远超过NAS。因此,本文选择SAN环境进行存储设计方案的研究,并从群集资源组、存储资源规划提供、路径配置、LUN(逻辑存储单元)分配、流量切换等方面进行了完整的端到端考虑,同时还探讨了相关的配置策略。
常见的HA群集解决方案包括IBM的HACMP(高可用多处理器群集)、微软的MSCS(群集服务器)和Linux HA、赛门铁克的VCS(veritas cluster system)等。每个服务器节点中的群集软件通过IP网络、串行接口或共享磁盘交换心跳信息,监视各个节点状态。如果检测到一个软件或硬件错误,HA软件在备用节点上重启该应用,这样就避免了应用宕机或性能下降。具体做法是将该应用涉及的各种资源,按先后顺序打包集合成一个组,切换时在备用节点上将组中的资源依次挂接或重启。这个组就是群集资源组,是群集中应用涉及的所有资源的集合,定义了切换时需要进行的各个动作。可以说,资源组有效地界定了一个恢复域。
为方便地进行故障切换和流量均衡,群集应用访问存储一般是通过SAN访问。一个典型的SAN是由一个或多个存储子系统和它们与主机连接的光纤网络组成,存储子系统通常包括磁盘阵列、磁带库或其他存储媒介,光纤网络包括一个或几个FC交换机(fiber channel switch)组成的级联网络。这些也是群集环境中提供存储资源时需要重点考虑的内容。
向应用提供存储资源的过程,包括LUN的创建、LUN到主机的映射,后者包括创建和配置主机访问LUN的光纤通道路径。这两个过程需要精细的规划,LUN的创建基于业务量空间需求和存储子系统的特性 (RAID方式);LUN的映射基于物理连接、具体业务的流量和性能要求、故障切换要求等。在群集环境中,一组LUN需要映射给群集中多个节点,这些节点中有一些是活动的,另外一些是备份的,它们在不同数据路径上流量不同。
对方案进行研究时,主要考虑群集环境中存储资源规划和提供时常见的3种业务场景。
·已知管理环境:场景中有潜在可能引入群集的主机,根据群集类型、主机操作系统、应用类型等考虑存储资源的提供。
·已知群集:主机可能引入群集资源组,根据应用类型、失败几率、服务器性能等考虑存储资源的提供。
·已知群集节点和业务量需求:考虑存储和网络资源的最优分配,以满足性能和冗余特性要求。
群集感知存储资源的提供主要考虑两方面要求:冗余和性能。
存储资源冗余是为了保证应用即使在几个组件宕机的情况下仍然可用。从SAN的观点来看,冗余包括存储冗余和路径冗余,前者通过RAID阵列和其他冗余设备组件实现,后者就是存储LUN与群集节点之间路径的冗余,通过主备两条路径上不存在单点故障来实现。发生故障时,群集软件将应用从活动服务器切换到可用的备份服务器。完全的端到端冗余必须确保路径上的任何设备都不出现单点故障,包括光纤通道网络、连接服务器的交换机、连接存储控制器的FC交换机、存储控制器的光纤接口、主机的光纤接口、LUN分配等。
存储资源性能是为了保证读/写速率、带宽达到应用的要求,决定于底层磁盘子系统和数据路径的性能。磁盘子系统的性能决定于磁盘类型(包括SAS、SATA、SSD等)、RAID配置类型;数据路径的性能决定于路径的配置:一方面需要在路径上实现负载均衡,另一方面,为避免业务性能下降或故障切换时出现热点,在路径选择上还需要优化。
3.3.1 路径配置策略
网管系统中的业务不同,对应的群集配置也不相同。其中,群集节点的选择是基于操作系统、服务器硬件配置、群集类型、应用类型和业务量需求,群集资源组的选择则是基于应用需求和故障特性。一旦建立了群集和群集资源组,就需要按照方案来配置节点到LUN的数据路径。方案中采取了如下策略保证数据路径上没有单点故障。
·活动/备份服务器通过不同的fabric连接磁盘子系统,以防止fabric出现故障。
·在不具备多个fabric的条件下,工作/备份服务器要连接同一个fabric在主机边界侧的不同光纤交换机,以防止FC交换机出现故障;在具备多个fabric的条件下,工作/备份服务器访问数据要通过同一个fabric在存储边界侧的不同光纤交换机,以防止FC交换机出现故障。
·工作/备份服务器要分配给存储子系统不同端口。
·工作/备份服务器的端口要在存储子系统所有可用端口间统一分配。
·主备节点的光纤通道端口要根据故障切换特性进行分配。
上述策略是为群集主备节点创建不同的数据路径,以便在运行中及时感知群集的状态。当主用节点由于数据路径上的组件出现故障而宕机时,备用节点必须能够通过不同数据路径访问LUN,这样就实现了较高的冗余特性。
3.3.2 LUN分配
LUN分配是由<发起端口、目标端口、LUN>三元组决定的映射。发起端口即群集节点的FC端口,目标端口即存储子系统的FC端口,LUN即根据应用容量需求划分的空间。根据存储子系统的性能和冗余特性,方案中也考虑了分配存储时采用的策略:如果一个存储子系统已经服务于一个群集,则该群集在增加新空间时,该子系统具有比其他存储子系统高的优先级,简化了存储管理工作,如灾难恢复、数据复制等。
3.3.3 流量切换
方案中还有一个关键问题需要考虑:当一个活动的群集节点失败,群集软件将业务迁移到备用节点时,同时切换后端SAN中的流量。可以想象,I/O流量切换会拥塞fabric中的部分组件或存储子系统的光纤通道接口。为避免此瓶颈现象,在规划过程中需要计算这些失败和切换的流量,方法如下。
考虑群集节点的失败特性,计算存储子系统中每个光纤通道端口的预测流量,包括活动节点产生的正常I/O流量和活动节点出现故障切换到备份节点时产生的流量。必须注意的是,多个LUN可能通过相同端口映射给多个主机,也可能一个LUN通过多个端口映射给几个主机,规划LUN到端口的映射,实现预测流量在光纤通道端口上的均衡。
3.3.4 存储方案设计流程
存储方案研究的实际价值是为群集环境中存储资源的动态划分和配置提供相应依据,如根据业务的不同和发展演进提供存储、光纤通道分区和多路径配置等,以满足应用在容量、性能、冗余等方面的需求。具体实现是通过监视和收集环境中的各种配置和操作信息,包括应用、服务器、FC交换机、fabric、存储控制器、磁带库等。将这些信息综合在一起,根据不同场景形成不同模板,实际使用时,通过查询此模板形成各种动态任务,从而完成空间配置、性能报告和分析、问题定位、请求退回等存储资源的提供和变更工作。
完整的存储系统方案设计流程如图1所示。
通过如图2所示的网管中心案例 (节选)来解析群集感知存储规划的工作流程。该群集有两个资源组:CRG-DB和CRGAS。CRG-DB是由S2、S3构成的数据库资源组,S2为活动服务器,S3为备份服务器;CRG-AS是由S1、S3构成的应用资源组,S1为活动服务器,S3为备份服务器。假设数据库服务器和应用服务器不可能同时出现故障,两个资源组共用一个备份服务器,S3同时安装了数据库和应用软件。
在创建群集和群集资源组时,根据解决方案分析应用的业务特征,预测相关主机所需要的处理能力。在图2的案例中,S1、S2是群集中的2台活动服务器,属于不同的资源组。方案要完成以下两项任务。
·决定要加入群集的服务器S3,作为资源组CRG-DB、CRG-AS中 S1、S2的备用。
·为数据库服务器S2提供存储:容量为500 GB;RAID类型为RAID-5;业务类型为1 000个事务/秒的OLTP(联机事务处理)。
案例中的SAN包括 2个光纤fabric:F1和 F2,高端和中端存储各1个,高端存储连接了2个fabric,但中端存储只连接了1个fabric。因为群集要提供OLTP业务,相应的性能和冗余特性要求较高,存储子系统必须要有较高的IOPS(每秒I/O字节数)和较快的响应时间。根据这样的业务需求,案例选择高端存储来存放CRG-DB中的数据,并且把S2、S3配置成分别通过数据路径F1、F2访问其中的LUN。实际运行时,当活动主机S2或数据路径F1出现故障时,群集软件切换到备份节点S3,S3通过正常状态的F2访问高端存储中同样的LUN,业务没有中断。这样就实现了很好的故障切换冗余特性。相反,如果让中端存储来存放CRG-DB中的数据,则当F2出现故障时,切换后还是没有能够访问存储的数据路径,S2和S3都会宕机。在配置存储中的LUN映射时,方案还规定了存储子系统的FC前端口通过不同FC交换机向主机映射,这样一方面均衡了I/O流量,同时也防止了一个fabric中某个交换机出现故障导致整个数据路径中断。这个案例也说明了数据路径规划的重要性,可以切实提高群集的故障冗余特性。
本文通过对网管群集环境中提供存储资源时面临的各种问题的研究,提出了集成解决方案,采用定制策略的方式来实现群集节点的存储分配。尽管研究的内容是网管HA群集和SAN,但同样的思路也可以适用于其他群集和存储环境。目前,存储虚拟化、云存储等技术已经从理论研究走向实际应用,而本文讨论的相关底层技术正是这两者在生产环境中实际部署时必须解决的基础问题,具有很实际的生产指导意义。
将来的研究方向有如下几点考虑。
·对SAN错误类型感知的HA解决方案进行研究。目前很多群集高可用性解决方案不能区分SAN失败的不同情况。例如当LUN出现故障(由于磁盘阵列故障),切换到备用节点时,由于没有存储可用,业务还是会宕下来;而FC交换机或fabric出现故障,切换到备用节点后,应用和业务的可用性仍然能够保证。因此,将来进行这项研究是有一定价值的。
·对群集冗余中fabric分区的效果进行研究。分区本是光纤通道fabric一个安全特性,能够限制fabric不同部件之间的通信。分区配置错误会导致主机无法识别LUN、SAN的连接中断,从而整个业务群集宕机。这项研究旨在探索fabric分区的原则,以指导实际部署配置工作。
·远期目标是把本文提出的设计方案通过软件来实现,把与存储分配相关的端到端配置的所有任务、策略等固化成软件中的模块。实际使用时可以根据实际业务的性能和冗余要求,选择与应用场景相匹配的策略,软件自动输出实施方案。更进一步,在软件中加入SMI-S(存储管理主动性协议)协议接口,从而自动采集群集环境中的主机/存储的FC端口、FC交换机、fabric等信息,自动分配SAN存储和配置路径。
1 IBM TotalStorage:SAN product,design and optimization guide.http://www.redbooks.ibm.com/abstracts/sg246384.html?Open
2 刘国萍,谭国权,杨明川.基于云存储的在线备份安全技术研究.电信科学,2010,26(9)
3 周可,王烨,李春花.云存储技术及其应用.中兴通讯技术,2010(8)