数据生命周期管理实践：改银行数据中心存储架构

    数据生命周期管理是一项复杂的系统工程，其存储架构的建立比较简单，最大的难题是现有应用系统中的数据是否可以按照生命周期实施分离和，以及满足当年数据、历史数据查询使用的具体要求。本文作者提出了一种方案，供读者探讨。 
  
    早期的银行业务主要还是以经营性业务为主，其特点是业务处理运算量大，但数据量相对较少，处理对象主要是当前数据或短期之内的数据，数据时间跨度小，这就意味着处理的数据规模相对固定可控。近年来，以几大国有商业银行为代表的国内银行不约而同地走上了数据大集中的道路，数据集中统一处理造成数据量的急剧膨胀。随着国内银行业竞争的加剧，各家银行不断深化以客户为中心、以优质业务为核心的经营理念，长期被忽视的客户信息资源将作为银行拥有的重要无形资产被挖掘利用，以充分发挥其应有的价值。迫于沉重的不良资产压力，各类针对提高信贷管理和风险控制的管理信息系统在国内银行特别是国有商业银行中得到了前所未有的重视。而数据大集中也为管理信息的归集、挖掘和利用创造了条件。 
  
    SAN比NAS 更适合银行数据中心 
  
    谈到银行数据中心的存储架构与模式，不得不先看一下银行数据中心的特点何在。银行数据中心的数据主要以结构化数据为主，非结构化数据占比较小。这一特点成为了至今都非常流行的NAS(Network-attached Storage)技术在银行数据中心始终难成气候的根本原因。传统的银行数据中心均采用主机直连存储模式(Direct-attached Storage)，无论通过SCSI还是SSA串行协议，从存储架构的角度都可称之为DAS架构。 
  
    随着银行业务的不断扩充和拓展，在国内银行日益庞大的IT架构中，基于DAS模式的存储系统逐渐成为瓶颈。取而代之的是基于SAN(Storage Area Network)—-存储局域网络架构。几年来，SAN在国内银行数据中心得到了充分的应用，几乎达到了“无盘不SAN”的地步。SAN以其高性能、高可靠性、高扩展性、高可管理性为银行数据中心提高存储应用与管理水平创造了条件。本文将针对银行数据中心利用已具备的SAN平台，如何进一步对存储架构进行整合改造进行初步的分析探讨。 
  
    双Fabric SAN存储 架构存在问题 
  
    如图1所示，这是一个较为典型的银行数据中心双Fabric SAN存储架构。该架构存在的问题如下：

    1．基于SAN，绝大部分数据集中于2台EMC 8730及1台IBM ESS之中，数据的集中带来了数据风险的集中。在多数应用系统中，处理器的冗余通过双主机集群机制提供;存储链路的冗余通过每台主机双HBA通道卡、双主机-交换机I/O光纤通道、双交换机以及多条存储?D交换机I/O光纤通道来提供。 
  
    但在存储系统端，没有完全独立的冗余设备提供灾难备份。在整个数据存储链上，端末的存储系统成为安全瓶颈。目前存储系统的安全性只能依靠存储系统本身的部件冗余，而不具备设备冗余。 
  
    2．数据存储结构过于简单。其实从运行管理及资源控制的角度，数据应按照以下几个方面进行分类，形成结构化数据存储系统。将生产数据按照对应的业务重要性(核心系统、重要系统、次要系统等)或业务类别(交易处理系统、渠道系统、管理系统等)划分，有助于根据不同的数据类型采取不同级别的冗余保护措施或选用不同技术特性的存储设备。不同类型数据之间的关联程度不同，分类也将有助于进一步明确存储结构和数据关系。 
  
    也可按照数据生命周期对数据进行分类，例如，可将数据按照其生命周期分为: 当前数据(三个月内的业务数据)、当年数据（三个月以上一年以内的业务数据）和历史数据(一年以上的业务数据)。针对处于三个生命周期中不同阶段的数据，采取不同的管理方式。如提高当前数据的可靠性、完善冗余机制、提高访问效率、控制数据规模；对于当年数据，提供在线查询功能，降低存储设备安全及性能级别，不再进行数据备份操作，从而降低设备成本和管理成本；对于历史数据，将保存在移动介质中，不提供生产系统上在线查询功能，必要的时候可将历史数据进行非结构化处理，使其查询功能不必依赖生产系统或上线测试环境。 
  
    按照数据生命周期进行管理，能够有效地控制在线数据规模，提高生产数据访问效率，缩短或控制备份窗口，从而提高应用系统运行的整体效率和效果。 
  
    对存储架构 实施改造 
  
    第一阶段改造要按照数据对应的业务应用类型或重要性程度将其划分为三个层次：核心数据存储系统、管理/次要数据存储系统。实施这一目标可通过以下两个方案进行: 
  
    方案一（见图2）

    将核心交易类业务数据存储于EMC8730(1)中。而EMC8730(2)将作为EMC8730(1)的镜像(R2)，依靠EMC的SRDF技术，实现两套存储之间的数据同步。当8730(1)发生整机故障的时候，8730(2)可自动接管，从而提高核心交易类业务数据的可靠性、完善数据容灾机制，为今后实施异地灾难备份打下良好的基础。 
  
    增设一套大容量存储系统，如EMC CLARiiON系列。将从8730(1)、8730(2)上迁出的次要及管理信息类业务数据存入该存储系统，实现两类数据的分离。需要说明的是，Symmetrix 8730与CX700之间的数据迁移可利用EMC CLARiiON系列存储系统的数据迁移工具，在存储系统之间直接高速传递，不需主机服务器干预。根据次要及管理信息类业务数据的特点(重要程度相对低、时效性要求不十分苛刻，但数据量较大等)，对于其存储系统（CX700）不必进行SRDF的本地容灾保护，依靠存储设备本身的部件冗余和数据备份机制来保护其数据安全。 
  
    方案二（见图3）

    方案二与方案一的区别在于：方案一仅仅将两类业务数据的存储分开，但在整个存储数据流链路上两者依然有重合复用的部分—-存储交换机。 
  
    方案二不仅实现了两类业务数据存储设备的物理分离，而且还将存储交换机进行了分离，实现了两个存储数据流链路的完全独立。当然，正因为这样，方案二的投资将略高于方案一。图3中交换机2与交换机3之间的互联是通过SAN Router实现的，目的是为了两个各自独立的SAN网可以在可控的范围内共享存储网络资源或进行必要的数据迁移。 
  
    第二阶段改造要实现按照数据生命周期管理(ILM)的要求，在对各类业务数据进行整理分析的基础上，通过转储机制，按照当前数据、当年数据和历史数据的分类，建立相对应的三级存储系统，如图4所示。

    生产数据均存储于EMC 8730(1)及EMC CX中，按照既定的备份策略将数据定期(一般为每天)备份于磁带库中。当生产数据满三个月之后（即当前数据成为当年数据），将被转储至二级存储EMC 5630中，供各应用系统B机或专用主机进行历史数据在线查询。转储在技术上可以只在数据源与数据目标存储系统之间进行，无需主机干预。二级存储(EMC 5630)中的数据满一年之后（即当年数据成为历史数据）将被清空，一年以上的历史数据将不再支持生产系统的在线查询，其数据来源依靠备份于磁带库（三级存储）磁带介质上的数据。进一步地，将磁介质上的数据转换为非结构化数据，可不依赖原生产环境进行查询。二级存储应可较为精确地预估容量，在性能及安全性要求上也不必过高，因此可选用低档次存储系统，甚至运行状态较好的老旧设备。

未经允许不得转载：DOIT » 数据生命周期管理实践：改银行数据中心存储架构