随着技术的不断发展,大规模的并行计算方式越来越多的激发有关对高性能计算机的需求,如大数据挖掘、高性能计算处理等。同时结合云计算技术的快速普及与发展,并行计算已经延伸到容灾备份等多个对技术要求较高的应用场景中。随着企业的业务发展和数据的不断累积,多点灾备的需求也是越发强烈,两地多中心的市场需求更是如火如荼。
传统的灾备方式已经很难满足两地多中心或者多地多中心的业务需求了,IT部门也在积极寻找更加适合的方案来满足业务连续性的硬性要求。
本例中的双活解决方案【Active-Active】,就是两边都是活动在线提供服务的,是相对于传统的主备模式【Active-Standby】的,是应该涵盖基础设施、中间件、应用程序各个层次的。不分主从、并可同时部署业务,可极大的提高资源的利用率和系统的工作效率、性能,让客户从中获得最大的价值。
重要业务系统应用双活项目是单位业务支撑系统建设中极为重要的一环,既要考虑系统平台的双活切换能力和系统架构的高可用,又要考虑数据层次的业务连续性,同时也要考虑单位信息系统今后几年的业务发展需求。
单位IT部门承诺保证业务系统 7x24小时不间断运行,在此次重要业务系统双活项目中,要把系统的可靠性、稳定性、安全性和可扩展性作为本次规划的重点考虑因素。
一方面随着用户业务发展,业务层次对 IT 系统业务连续性(保证业务系统7*24 不间断)的要求程度越来越高。另一方面企业需要一个符合成本效益的解决方案来优化数据管理和提高数据中心对于前端业务的支持水平,而不是通过单纯地增加存储和设备去解决问题。最后达到用户业务层次所需的动态型全天候不间断数据访问和业务数据中心的支持。
为了有效地解决这些问题,企业需要寻找一个新的更有效的数据管理方法。这种新方法的数据管理需要具有解决几个关键问题的能力:
公司目前拥有两个数据中心,分别位于相同城市的不同区域。两个数据中心主要承载集团重要的应用业务。
主要采用了典型的SAN网络以及IBM的Power系列服务器承载核心业务。为了保障业务的连续性,降低因基础设施故障对业务的影响,集团计划采用数据中心双活解决方案,解决当前单一数据中心造成的单点故障。
当前某商业银行当前核心系统架构主要存在以下几个方面的问题:
1、重要业务系统服务器出现问题后,切换到备用服务器需要一定的时间。
2、数据中心机房A出现问题后,由于数据中心机房B服务器平常无法打开使用,无法实现无缝接管。
3、随着业务量的增长,当重要业务系统应用服务器的压力越来越大时,无法进行横向扩展。
4、资源严重浪费,数据中心机房 2 的资源(尤其是存储)平时无法打开使用。
5、切换时间长,一般需要 1-3 小时以上才能切换到灾备中心。
6、故障情况下切换决策难,有时切换时间+决策时间>=灾难修复时间,难以决策,期间无法办理业务。
7、流程复杂,维护难,系统切换需要一系列管理和技术流程,维护复杂,生产、容灾端都需要维护
图1-某核心系统架构
当前市场主流的集群存储产品还是很多的,各家的解决方案也大同小异。以下简单的对部分产品进行对比,读者可以依据公司的不同需求进行选择。如表1所示
表1-产品对比图
General Parallel File System (GPFS) 是 IBM 公司的高性能、可扩展、共享磁盘的并行文件系统。被普遍应用于 IBM 大规模 Linux 或 AIX 集群系统中,能够为并行应用程序提供高性能的 I/O 存取访问。
GPFS 允许在同一节点内的多进程或者应用使用标准文件系统同时访问(并发,读写)同一个文件。通过将节点内读写操作分布到多个磁盘上,大大增加了文件系统的带宽,通过整个系统的负载均衡避免了某个磁盘过大的读写。
GPFS 是一种日志文件系统,为不同节点建立各自独立的日志。日志中记录metadata 的分布,一旦节点发生故障后,可以保证快速恢复数据增加文件可用性。
通过 GPFS,系统资源可以动态调整,可以在文件系统挂载情况下添加或者删除硬盘。系统处于相对空闲时,用户可以在已配置的硬盘上重新均衡文件系统以提高吞吐量。可以在不重新启动 GPFS 服务情况下添加和删除新节点,提供系统扩展性。
GPFS 自动在各个节点间同步配置文件和文件系统信息,而且在同一个节点内,对 GPFS 的管理可以在任一个节点上进行,方便管理文件和系统信息。
GPFS 文件系统基本上由三层架构组成:磁盘,网络共享磁盘(NSD), GPFS文件设备,如下图2所示。
图2-GPFS系统架构
GPFS 文件系统最底层的是物理磁盘设备。原则上可以采用系统上任何块设备,包括磁盘,磁盘分区,逻辑卷。从物理连接上来看,GPFS 支持使用所有方式连接的磁盘。包括本地 IDE 磁盘,本地 SCSI 磁盘,光纤 SAN 磁盘,iSCSI磁盘,等等。
NSD 是由磁盘映射出来的虚拟设备,NSD 与磁盘是一一对应的关系。NSD被标记了不同属性来区分其用途,我们可以将磁盘标记为 4 种用途:
1、Desc Only:只存储 GPFS 文件系统描述信息的磁盘。
2、Data Only:只存储文件系统中的数据信息。
3、Meta data only: 只存储文件系统中的目录结构 inode 信息。
4、 Meta and data: 存储所有信息(默认)。
GPFS 设备是一个可被系统挂载的文件设备,由 NSD 创建而成,可以并行的同时挂载在多个节点上。
GPFS 采用条带化技术,文件可以跨节点和磁盘分布,提高并发访问性能,实际使用中 I/O 带宽可以达到每秒数十 GB. GPFS 支持客户端数据缓存,通过对文件访问模式的预测来进行预取,降低读写延迟,数据块的大小可定义为 16K,64K, 256K, 512K, 或 1024K,提高系统效率分布式的块级锁管理,通过令牌机制来避免并发读写冲突分布的元数据服务器,支持元数据自动日志功能,实现用户数据和元数据的备份和自动恢复支持多路径磁盘访问,一条路径访问失败,可以通过其它路径实现。
实测过的文件系统大小超过 4PB,20 亿个文件系统支持数千个节点的集群环境,实测过最大规模为 2441 个节点在不停止服务的情况下可以动态加入和移除节点或磁盘。
自动在各个节点间同步配置文件和系统信息可以集群内任何一个节点上完成对 GPFS 的管理任务,命令将在所有节点上生效。管理网络和数据网络可以分开。
GPFS 允许在同一节点内的多进程或者应用使用标准文件系统调用,同时访问(并发,读写)同一个文件。通过将节点内读写操作分布到多个磁盘上,大大增加了文件系统的带宽,通过整个系统的负载均衡避免了某个磁盘过大的读写。
1、GPFS 支持在一个集群内加入异构的平台。
2、支持异构的硬件环境:Power Systems(System p),
System x。
3、支持异构的操作系统:AIX, Linux。
GPFS 通过一套复杂的信令管理机制提供数据一致性。通过这套机制允许任意节点通过各自独立的路径到达同一个文件。即使节点无法正常工作,GPFS 也可以找到其它的路径。
GPFS 是一种日志文件系统,为不同节点建立各自独立的日志。日志中记录 metadata 的分布,一旦节点发生故障后,可以保证快速恢复数据。
GPFS 的fail-over功能通过规划,将数据分布到不同 failure group内达到高可用性,减少单点故障的影响。为了保证数据可用性, GPFS 在多个 failure group 内为每个数据实例做备份,即使创建文件系统时没有要求复制,GPFS 也会自动在不同的 failure group 内复制恢复日志。
通过 GPFS ,系统资源可以动态调整,可以在文件系统挂载情况下添加或者删除硬盘。系统处于相对空闲时,用户可以在已配置的硬盘上重新均衡文件系统以提高吞吐量。可以在不重新启动 GPFS 服务情况下添加新节点。
通过使用GPFS,系统资源既能够充分的利用,又能保证业务系统的正常运行,在其中某个节点发生问题时,其他节点能够正常使用,从而保持业务的不间断。保障系统的正常运行
GPFS 自动在各个节点间同步配置文件和文件系统信息,而且在同一个节点内,对 GPFS 的管理可以在任一个节点上进行。
结合应用系统现状以及高可用性需求,最终选择使用IBM的GPFS搭建分布式存储双活数据中心解决方案,确保应用的连续性、可靠性,提升整体应用整体服务水平。
在此次重要业务系统双活项目中,要把系统的可靠性、稳定性、安全性和可扩展性作为本次规划的重点考虑因素。在进行系统设计时,遵循以下原则:
稳定性:稳定性是系统运行的关键,也是系统维护管理的关键因素,更是充分发挥科技骨干技术储备的关键。
安全性:系统软、硬件需具有可信赖的安全性,软件系统安全性方面应满足单位信息系统安全策略的要求,系统有严格的用户权限和密码保护设计和办法。
可靠性/可用性:系统软、硬件平台应稳定、可靠,能够满足业务系统 7x24 不间断的运行要求;具备成熟的高可用性和双活解决方案。对数据的完整性和准确性有可靠的保证机制。
可持续发展性:所提供的技术是可持续发展的,是目前的主流技术并有长期发展的目标,能满足单位业务支撑信息系统未来几年业务发展的需求。
可扩展性:随着单位业务的不断发展、壮大,系统平台必须提供足够的可扩展能力以满足未来几年业务增长和系统扩展的需要。可扩展性是保护用户投资的重要方面之一。另外在系统设计时,应选择业界相关领域的主流产品,确保产品旺盛的生命力,以便充分地保护用户的投资。
易用性:系统软件平台应提供丰富的、简单的管理工具,便于管理及系统问题诊断。
开放的标准:系统软件需支持业界通用的开放式标准,降低因兼容性问题造成的问题发生率。
可维护性:系统维护需要简便快捷、不需要太多的管理人员和维护。系统可维护性十分重要,它直接决定了系统的效能、产出和用户的总体拥有成本。系统可维护性差会导致系统效能下降、产出降低,维护成本增加,后患无穷。
售后服务技术支持:厂家能提供足够、及时的技术支持与响应,来保证应用系统良好运行状态。在系统运行中存在着很多不确定因素,包括人为因素、自然因素等多方面原因,系统可能出现不同程度上的故障,这就要求系统用户与原厂商有着良好的配合,原厂商能够在事故发生后最短响应时间内排除故障,给系统用户以更加坚实的信心。因此原厂商的售后服务水平和响应时间同样是系统建设的一个重要考虑因素。
成熟性:采用的技术、产品应经过实践检验,被证明是成熟可靠的,以规避风险。在技术上要到达当前的国际先进水平。系统的软、硬件技术是经过市场考验的,证明是成熟的技术,在相关应用中有较多的成功案例。同时要采用先进的技术,既要满足目前的业务需求,又要充分考虑未来的发展,保证系统建成后 3 至 5 年不落后,选用符合国际标准的系统和产品,以及保证系统具有较长的生命力和扩展能力,满足将来系统升级的要求。
实现同机房与机房之间的应用双活,任何一个重要应用系统的服务器、磁盘阵列、交换机故障,都不会影响业务的正常运行。
在业务运行过程中保障系统运行的连续性是每个企业面对的痛点和难点,也是各个企业急需解决的问题。
选型过程中需要考虑本企业的基础架构和拓展性,能要充分考虑硬件和软件产品的兼容性问题,从而保障业务系统全方面能够有所提升。
任何一个重要应用系统应用的服务器、磁盘阵列、交换机故障,对该重要业务影响控制在 1 分钟以内。
根据当前某商业银行重要应用系统系统架构的现状,同时结合某商业银行对重要应用系统双活项目的需求,该商业银行采用 GPFS(General Parallel FileSystem,通用并行文件系统)的高可用方案实现此功能和目标。结合当前应用系统以及硬件、网络环境的现状,其中共采用以下两种实现方式:不同数据中心应用双活和同数据中心应用双活。
在满足跨机房实现应用双活的硬件、网络等条件下,结合该商业银行的应用系统现状,设计了实现应用双活的系统拓扑图和功能逻辑图。
图3-GPFS双活系统架构
图4-GPFS功能逻辑图
1、通过操作系统内的 GPFS 文件系统实现,最大程度不改变传统的物理拓扑,增加整体方案的安全性、可用性;
2、在操作系统层次,通过 GPFS 文件系统的 failure group 功能模块将生产、灾备两个中心的两台存储虚拟为一台存储使用;
问题一:两双活中心的网络带宽比较低,因此做双活的业务系统往两个中心写数据时,造成网络延迟比较严重,从而造成业务交易延迟业务比较大。
解决方法:针对以上情况,增加网络带宽,减少数据延迟。做到极好的维护和掌控两中心的网络。
问题二:由于网络质量的原因,造成了网络传输时的不稳定、从而造成GPFS双活的业务不停的进行切换工作,当频率达到一定程度导致双活数据中心产生脑裂状况。
解决方法:提供有效的Quorum / Tie-Breaker方式来保证数据完整性,最好将仲裁放在第三个数据中心。
问题三:由于双活业务系统的业务性质不同,造成业务系统的写操作、读操作严重不平衡,从而造成部分性能达到瓶颈,其它的工作未能够得到充分的利用,从而造成资源的浪费。
解决方法:推荐业务划分,读写分离等, 有效规避数据中心间交互的架构。进而合理的分配相对用的资源。
综合以上内容在实施过程中同样出现其他的问题,例如资金投入问题、业务系统连续性问题等。
该方案实施完成后,我们可以实现以下目标:
1、任何一个数据中心的应用服务器、存储、网络出现故障,另外一个数据中心可以无缝接管,应用基本不受影响。
2、两个数据中心的应用服务器同时对外提供服务,提高了应用系统整体的处理能力,同时由于灾备数据中心资源也可以同时对外提供服务,减少了资源的浪费。
3、实现了在线进行应用服务器的横向扩展。
4、系统切换演练以及维护较之前的双中心主备模式简单。
做容灾的方式其实很多,最简单的就是主备模式,也是最早的一种模式。一般是在两个中心建互备系统,主应用在A中心,容灾系统在B中心,这种模式比较容易切换。如果出问题了,需要一个较长时间的定位,影响业务正常使用。
后来为了节约资源和时间,发展到现在的双活并行模式。同一个系统,两个中心都可以承担业务,同时对外服务,坏掉任何一方不影响。
本文主要是将的第二种,这也是非常理想的一种状态,上文也是简单的描述了一下要实现这种架构或部分实现,需要哪些技术,需要做哪些工作。更深入的技术和讲解,需要大家共同学习和风险。
GPFS现已归入到IBM Spectrum存储软件家族,改称IBM Spectrum Scale。下面是产品介绍页面,可以了解更多信息。
https://www.ibm.com/cn-zh/marketplace/scale-out-file-and-object-storage
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞13
添加新评论7 条评论
2022-10-01 00:30
2018-12-18 15:53
2018-12-18 15:28
2018-12-18 09:35
2018-12-14 22:12
2018-12-14 16:14
2018-12-14 15:54