基于VMware_vSphere的银行虚拟化平台设计 ——网络存储课程设计

一、引言

随着银行业务量的不断提升以及客户数量的持续增长，银行数据库和应用的数量也随之扩大，因而服务器的使用数量也相应增长。过多的物理服务器导致巨大的性能浪费，银行的运维成本不断攀升，如何使服务器性能做到最大化利用是当今企业研究的重要课题。因此，在商业银行，管理方式的革新、流程的再造和信息化平台的建设就被提上了议事日程。怎样最大化地利用硬件平台的全部资源，怎样有效地降低各种资源的管理难度等等，这些已经成为了很多商业银行正面临的大问题。虚拟化技术就在这样的背景之下应运而生。

服务器虚拟化平台的建设对商业银行而言，具有诸多的好处和优势，它不仅能够提高资源的利用率、增强系统的可用性，而且能够构建更为灵活多变的基础设施架构平台，从而大大提升业务的运行和响应能力。这些好处和优势在很大程度上也推动了各商业银行的服务器虚拟化平台建设。然而，各商业银行在进行虚拟化平台建设的过程中，依然遇到了不少实际问题和困难。比如，基础设施环境差异相对较大，人员技术资源不足，平台建设规模较小等，这些都成为虚拟化平台建设的障碍。因此，如何设计一套科学合理的虚拟化架构，如何保证建设好的商业银行虚拟化资源池既安全可靠又经济实用，如何简单而有效地进行运维管理工作，如何保障虚拟化资源池在投产后的安全稳定运行，这些都是值得研究的问题。

针对大作业要求，本文描述了针对该国际银行的虚拟化部署方案。首先，结合企业背景对目标虚拟化数据中心进行了细致的需求分析；然后提出了虚拟化方案以及存储方案，并对方案配置等进行了细节上的分析；接下来，对用户划分以及权限设置、虚拟机命名、共享存储容量规划以及地址池管理进行了描述；本文最后针对容灾方案结合vSphere的功能特性进行了阐述。

 

二、问题描述

2.1 问题背景

某国际银行目前采用CDC传统的数据中心解决方案，随着业务的变化，应用场景和需求越来越灵活，银行业务高速发展，原有平台已经满足不了目前的应用需求，运维带来很多不便。基于上述原因，现决定构建全新的虚拟化平台，采用最新的vSphere 6.7(6.5,6.0)版本，并考虑到未来的业务扩展。

现阶段规划X个分区，分别为生产业务区、综合管理区、网银在线区、产品测试区、运维基础区。每个业务区承载着不同数量的虚拟机，并且随着业务发展不断增加。随着新业务不断增长要求，未来将逐步把小型机服务器上应用系统迁移到虚拟化平台，最终实现数据中心x86服务器的全部虚拟化。

系统设计：根据我们所学习存储信息管理知识，设计一套虚拟化部署方案，考虑到业务的迁移的复杂性，默认不再使用原有设备(降低设计难度)，因为是银行业务需要100%的冗余方案，尽量考虑容灾，存储部分设计按照基础数据为100TB设计，年增长40%,设计一个满足3年的方案。

2.2 设计要求

1、主机配置:（计算和存储）

2、用户、组、权限和角色

3、共享存储容量规划

4、虚拟机命名规划

5、地址池管理规范化

 

三、需求分析

3.1 数据访问和存储

       银行数据从产生到存储、利用、归档，最后超过存储期限被删除，数据被读取的频率逐渐下降，数据存储的位置也应该随之变化，以提高存储设备的使用率，降低存储成本。因此有必要进行分级存储，因此考虑采用在线(On-line)存储、近线(Near-line)存储和离线(Off-line)存储三级存储方式。在存储其关键或者近期业务数据时，采用昂贵的存储设备、存储技术和存储方式；而对于时间较为久远，访问量不大的数据存放在性能较低的存储设备，但对这些设备的要求是寻址迅速、传输率高；最后通过离线存储对时间久远的数据进行归档，要求设备具有高可靠性、良好的安全性、大容量和低成本。

3.2 新业务扩展

在传统的业务上线部署模式中，一个新的应用系统从提出上线需求，到购买设备，再到安装部署，最后系统投入使用，整个周期会非常长，极大地影响了银行新业务的发展，而且无形中还给银行增大了成本，造成了损失。在建设银行虚拟化资源池时需要考虑到空闲资源的分配，从而应对新业务系统的服务器需求。提高服务器的快速部署能力，使商业银行在瞬息万变的激烈竞争中能保持对新业务的快速响应能力，从而促进业务的快速发展，创造更多的效益。

3.3 数据安全

       银行数据涉及到需要被长期保存的交易信息，并且具有较强的私密性，涉及用户个人隐私，所以数据安全保护是必须考虑的，需要通过对虚拟资源分区，实现其中一个虚拟机出现系统崩渍或被病毒感染时，保证其它虚拟机仍然可以正常运行，并且可以通过容灾备份方案对数据进行恢复，通过建立远程灾备存储数据中心，将所有数据备份到远程数据中心；在整个硬件平台的所有虚拟机上还需要设置资源消耗阀值，这样就能保证虚拟机的运行不会导致整个硬件平台的资源耗尽。

 

四、虚拟化部署方案

4.1虚拟化方案设计

  根据目前规划的5个分区：生产业务区、综合管理区、网银在线区、产品测试区、运维基础区，由于每个分区对于虚拟机的数量以及性能上的需求不同，故分配方案如下：

       银行的业务总体可以分为需求设计，资产业务、中间业务三类，因此生产业务区的设计可以主要根据这三类业务分配虚拟机。由于这三类业务的每类任务都部署装有同样软件的虚拟机，并需要根据操作员人数分配相应数量的终端服务器。

因此我们为每类业务分配一台配置较高的虚拟机作为终端服务器。从而满足每类业务异构性的需求，使一台服务器可以对应多台终端，这样所需的主机资源数为终端数与终端服务器数求和。

       综合管理区类似于传统的信息管理系统，因此只需要为其同样分配一台配置较高的虚拟机作为终端服务器以及满足需求的虚拟机数量即可。

       网银在线区承担银行的网银业务，该区域的特点是访问量随时间变化较为明显，所以网银在线区需要根据当前实际网银业务访问量动态调整虚拟机的数量，从而对网银业务实现负载均衡；同时由于网银在线区的虚拟机需要作为Web服务器使用而终端服务器使用，因此网银在线区的服务器需要承载更高的业务量，这也要求每台虚拟机需要更高的配置。

       服务器产品测试区需要为银行的新产品进行测试，但是总体需求的资源比较少，我们可以为每个产品根据其需求分配一台服务器终端服务器/Web服务器，在分配时需要根据业务的实际需求，分配配置尽可能与生产环境近似的虚拟机。

       运维基础区需要对生产业务区、 综合管理区、供运维服务，运维需要将一些数据直接存储到主机中，而运维数据需要存诸在银行的系统中而非运维人员本人主机中，同时运维基础区需要尽可能稳定的网络环境，因此直接分配客户虚拟机是较好的选择，故在运维基础区对生产业务区的三个终端服务器、网银在线区、综合管理区各分配一台虚拟机作为运维使用的虚拟机。

       数据中心整体虚拟化的网络拓扑结构图如下图所示：

 

                                图1 数据中心网络拓扑结构图

4.2 存储方案设计

4.2.1存储方案

分级存储是根据数据的重要性、访问频率、保留时间、容量、性能等指标，将数据采取不同的存储方式分别存储在不同性能的存储设备上，通过分级存储管理实现数据客体在存储设备之间的自动迁移。数据分级存储的工作原理是基于数据访问的局部性。通过将不经常访问的数据自动移到存储层次中较低的层次，释放出较高成本的存储空间给更频繁访问的数据，可以获得更好的性价比。这样，一方面可大大减少非重要性数据在一级本地磁盘所占用的空间，还可加快整个系统的存储性能。

由于对于银行数据的访问频率随着时间的推移变化明显，故本地存储采用分级存储，从而提高存储设备的使用率，降低存储成本，主要分为三级：认为一周内的业务数据属于活跃数据，将这部分数据储存在一级存储中。考虑到可拓展性，将其他的数据分成两级进行存储，将一个月以内的数据，放入二级存储；考虑到银行的数据非常宝贵，需要保留，因此将一个月外的数据进行归档存入三级存储。示意图如图2所示：

图2 分级存储示意图

       本地一级存储(在线存储)，主要功能是工作级的存储，其最大特征是存储设备和所存储的数据时刻保持在线状态，可以随时读取和修改，以满足前端应用服务器或数据库对数据访问的速度要求。在线存储的一周内的业务数据，需要满足存取速度快，性能好，并且出错概率小等要求，因此在这一级中采用高端存储介质来存储近期需要频繁访问的数据。采用高端存储介质SSD硬盘，一方面可以提高用户访问的响应速度，另一方面能增强数据的稳定性。

       本地二级存储(近线存储），是定位于客户在线存储和离线存储之间的应用。就是指将那些并不是经常用到(例如一些长期保存的不常用的文件归档)，或者说访问量并不大的数据存放在性能较低的存储设备上。近线存储一个月中产生的历史数据。在这一层可以通过数据迁移技术自动将在线存储中不常用的数据迁移到近线存储设备上。这一级中的数据访问频率不是很高，但需保证数据共享和快速在线访问。在这一级别将使用大量低端存储介质来存储需要长期访问但是访问频率较低的数据，并且需要具有一定的拓展能力和安全保护能力，故选用SAS磁盘阵列。

       本地三级存储(离线存储)，大多数情况下主要用于对在线存储或近线存储的数据进行备份，以防范可能发生的数据灾难，因此又称备份级存储。采用离线归档的方式，对该国际银行长期的业务数据进行归档，这一级中要求设备具有高可靠性、良好的安全性、大容量和低成本，因此选择SATA磁盘阵列。

4.2.2 存储容量计算

       银行业务需求：基础数据为100TB，年增长40%,设计一个满足3年的方案需要100%的冗余方案，尽量考虑容灾。

可以得到总存储需求，即离线存储空间需求为：

100×1+40%3×1+100%=548.8TB