银行双活容灾建设方案技术手册——实施篇 | 周末送资料
随着全球IT产业的飞速发展，金融行业的IT建设逐步成为主导金融企业业务发展的核心驱动力，基于金融行业IT系统建设的各种行业标准以及监管标准也相应提高。IT系统架构的扩展性、灵活性以及容灾能力就成为衡量企业IT建设很重要的标准。
本手册以某银行同城双数据中心建设过程为背景，详细从系统架构集成、资源云化、存储整合以及数据容灾等多个关键方面阐述其规划思路以及建设过程，旨在为同业在此类项目规划和建设过程中提供一些启示和帮助。之前已经为大家推送过了“分析篇”（点击可阅读）、“规划篇”（点击可阅读），今天继续为您推送的是“实施篇”。
银行双活容灾建设方案技术手册——实施篇
1、某银行双活设计案例
1.1 XX平台双活数据中心建设需求
目前平台架构存在的问题：
XX平台目前数据中心托管在某IDC机房，由于机房提供的单链路网络较不稳定，应用层面目前也没有做负载均衡和、冗余与容灾设计，网站存在多处单点故障风险。数据中心的各项服务均不能满足7×24小时的无故障运行，无法支撑与保障业务连续运行。因此而造成应用程序性能较低，故障率高的影响。随着各类业务应用对IT需求的深入发展，业务部门对资源的需求正以几何级数增长，传统的IT基础架构方式给运营人员和未来业务的扩展带来巨大挑战。
具体而言存在如下问题：
1. 资源利用率低：传统架构方式容易造成底层资源之间的竞争，普遍的现象就是忙的设备不堪重负，闲的设备资源又空闲更多，二者相互之间又无法借用和共用，反而互相干扰，没有充分发挥服务器和网络设备的性能，以至于影响了程序本身的性能，造成网站与移动应用体验不佳。
2. 扩展性差：现有架构都各自独立不能纵向与横向扩展，无法满足业务的弹性扩展，如在业务峰值时，弹性的扩充资源。并且在高峰过后，归还该扩展的资源。
3. 架构传统无法满足业务高可用性：XX平台主要运营的是互联网业务，传统的网络与服务器架构模型无法满足互联网应用，高并发、高吞吐、大数据增长的业务模式，无法满足跨数据中心级别的冗余与容灾。
4. 运维管理难：没有建立集中式的运维体系，缺乏立体式的多层监控。碰到故障时难以第一直接发现故障原因。缺少自动化的性能分析、优化工具与方法
XX平台数据中心目标架构：
XX平台多活数据中心的建设模式采用“分应用主备模型”。两个数据中心的应用根据业务不同来划分主从对外提供服务，两个数据中心都处于活动状态，都能独立工作且互为备份。两个数据中心之间通过稳定、低延时的私有专线连接实现数据与配置的同步。本案中所有互联网应用服务器都以生产数据中心为主，办公数据中心作为备份，当生产数据中心故障或者网络中断时，办公数据中心有能力接管用户访问，对外提供服务；而虚拟桌面和其他办公应用则主要建立在办公数据中心，一旦数据中心故障，呼叫中心的用户可以访问到数据中心的备用系统。两个数据中心之间通过专线进行互联，“分应用主备模型”的双活数据中心可充分盘活企业闲置资源，保证业务的连续性，帮助用户接入最优节点，提高用户访问体验。
1.2 XX平台数据中心设计
私有云设计概述：
XX平台设计的目标是建立一套可扩展与伸缩，稳定高效的私有云，建立私有云可以使上层业务应用仅仅根据自己所需的计算资源占用要求来对CPU、内存、I/O等实现自由调度，而无须考虑该应用所在的物理关联和位置。业务应用运行所依赖的物理计算环境通过网络实现连接，互连CPU和内存，实现真正意义上彻底的实现服务私有云化。
服务器虚拟化应用：
为了使服务器资源能够集成在一起，形成私有云，统一对外提供计算服务，必需部署软件的虚拟化系统来整合成云，本案采用VMware vSphere产品来搭建服务器虚拟化与桌面虚拟化，形成统一底层架构平台。因此在私有云数据中心内，服务器虚拟化软件平台是该系统最为核心的组成内容。
虚拟化软件平台分为虚拟化业务平台和管理平台两个部分，业务平台部署在物理服务器计算资源上，实现计算资源一虚多的虚拟化业务需求；而管理平台则通常会部署在统一管理平台组件内部，对业务平台所在物理服务器计算资源进行统一调度部署。
服务器虚拟化平台主要提供分区、隔离、封装和迁移4个关键特性。
1. 分区：在单一物理服务器上同时运行多个虚拟机。
2. 隔离：在同一服务器上的虚拟机之间相互隔离。
3. 封装：整个虚拟机都保存在文件中，而且可以通过移动和复制这些文件的方式来移动和复制该虚拟机。
4. 迁移：运行中的VM可实现动态迁移到不同物理机的虚拟平台上。
设计原则：
1. 灵活性：通过封装 vCenter 服务器为虚拟机， vCenter 可以方便地从一台 ESX 主机迁移到另一台 ESX 主机，满足硬件设备维护需要。
2. 快照：虚拟机快照能够被备份和归档利用，当需要为 VCMS 打补丁和升级时实现最小恢复时间。
3. 高可用性（ HA）：利用这种虚拟化架构平台的高可用性级别的功能去确保任意时间内管理功能的可用性。
本次项目主要组件：
1. vCenter Server –1 台 vCenter 服务器安装在虚拟机上，数据库安装在外部的数据库服务器上。
2. 数据库高可用 –项目中一共有 2 个数据库需求： 1 台 vCenter 服务器， 1 台事件服务器。 需要搭建数据库高可用环境，数据库搭建
3. MirrorESXi 主机– 支持所有的虚拟服务器和虚拟桌面，数据中心3台 Dell R730服务器
4. vSphere HA –互联网业务所有的虚拟机都放置在同一个 HA 中，每个应用群集各自为一个 HA，虚拟桌面业务所有虚拟机防止在另一个HA中，能做到故障切换。
组件说明：
1. vSphere VMware - 提供强大的服务器虚拟化功能，平台稳定，性能可靠
2. vCenter - 集中管理工具，集中管理 vSphere ESXi，提供高可用性功能
VMware vCenter 服务器将被安装到一台专用的虚拟机上，并且该 vCenter 虚拟机的克隆作为冷备恢复可用性方案。当出现 vCenter 虚拟机操作系统级或应用软件级别的故障时，使用冷备虚拟机进行最新数据的数据库恢复，从而实现 vCenter 服务器高可用性方案。
VDI桌面虚拟化应用
在建立的私有云构建为XX平台搭建虚拟桌面以提高办公效率，降低TCO。为了保持平台的一致性与可扩展性，本案采用Vmware Horizon View结合瘦客户机来实现虚拟桌面环境搭建。
本次项目主要组件
1. vSphere For Desktop
2. View Manager
组件说明：
1. vSphere VMware - 提供强大的服务器虚拟化功能，平台稳定，性能可靠View Manager - 是企业级虚拟桌面管理器，是 VMware View 的关键组件。 IT 管理员使用
2. VMware View Manager 作为中心控制点，支持最终用户安全灵活地访问其虚 拟桌面和应用程序，并利用与 VMware vSphere 之间的紧密集成，帮助用户以安全托管服务形式交付桌面。 VMware View Manager 具有极强的
3. 可扩展性和可靠性，它使用基于 Web 的直观管理界面创建和更新桌面映像、管理用户数据、实施全球策略等，从而同时代理和监控数以万计的虚拟桌面。
View Manager 组件：
1. VMware View Connection Server — 管理对虚拟桌面的安全访问，与VMware View Agent — 提供会话管理和单点登录功能
2. VMware View Client — 支持 PC 和瘦客户端上的最终用户通过 VMware View Connection Server 连接到虚拟桌面使用。
3. View Client with Local Mode，即使网络发生中断也可以访问虚拟桌面，不会影响 IT 策略的实施。
4. VMware View Administrator — 允许管理员进行配置设置、管理虚拟桌面和设置桌面的权限以及分配应用程序
虚拟化桌面的优势：
1. VMware桌面虚拟化解决方案可以在以下方面大大降低我们的桌面管理成本。
2. 将用户的操作系统集中运行在数据中心，并对其进行统一的管理及维护，大大降低了IT管理人员的运维成本
3. 加快了系统部署的时间，管理员可以在数分钟内部署用户桌面将交将使用。
4. 使用VMware独有的Composer功能，可以将整个企业的桌面系统进行单实例的管理及维护。同时大大降低了对后端存储扩容的压力。
5. 应用，系统补丁的安装、管理、升级等，也只需要操作一次，即可以让所有用户进行使用。
6. 延长用户桌面PC使用寿命，降低桌面更新的采购成本，维护桌面的费用大大降低。
7. 更灵活快捷的服务业务，如果新添加用户，只要硬件资源仍然充足，可以通过简单的配置，在一分钟只能为用户提供出一台桌面系统，而无需传统的复杂的桌面准备工作，而只需要一台统一的简单的终端设备，就可以让用户访问。
8. 提供高可扩展性，在架构设计合理和硬件充足的前提下，可以快速的将桌面交付用户；当硬件不足的情况下，只需要将新的物理服务器加入VMware的资源池中即可。
9. 因为在桌面虚拟化环境的边缘很少发生计算执行过程，所以计算体系结构对终端设备处理能力的依赖性降低。这为 IT 人员创造了一个大幅降低终端硬件成本的机会。他们可以将现有 PC 作为虚拟桌面终端设备重新加以利用，从而延长现有 PC 的生命周期，或者使用瘦客户端设备代替老化的 PC，这种瘦客户端设备的生命周期通常是标准 PC 的两倍。
10. 以更少的资源、时间和资金完成更多任务。通过将桌面基础架构集中到 VMware View，IT 人员可以跨桌面映像和应用程序的整个生命周期对其进行调配、维护和监控，不仅更加快捷轻松，而且可以降低成本。通过减少支持来电次数和终端用户停机时间，提高了整个工作场所的工作效率。
网络服务虚拟化应用：
传统网络是不具备虚拟机意识的，即在网络上传递的信息是无法区别它是来自于哪个虚拟机，也无法在网络上根据虚拟机来提供相应的网络服务，当虚拟机迁移，也没有相应的网络跟踪手段保证服务的全局一致性。
通过Distributed vSwitches（vDS或vNDS）支持一个交换机在多个宿主上配置使用。具有相同配置的vSwitch必须在每一个宿主上创建，以便支持如VMotion的特性。当一个VM从一个宿主移动到另一个宿主时，它需要发现另一个宿主的网络名称和相同的配置才能建立连接。在每一个宿主上配置每一个vSwitch是非常费时的过程，而如果并非所有配置都一样的，通常就会出现VMotion兼容问题。
vDS与标准交换机非常相似，但是标准vSwitch是在每一个宿主上单独配置，而vDS是使用vCenter Server进行集中配置。每个vCenter Server最多有16个vDS，每个vDS最多可以连接64个宿主。vDS通过vCenter Server创建和维护，但是它们的运行并不依赖于服务器。如果vCenter Server变得不可用，vDS不会丢失它们的配置。当一个vDS在vCenter Server中创建时，每一个宿主上会创建一个隐藏的vSwitch与vDS连接，它位于本地VMFS卷的名为.dvsData的文件夹中。
计算资源需求：
根据不同类型的用户分配不同的虚拟内存和 CPU，通常情况下，数据库服务器 对CPU和内存的要求比较高，资源的占用率大，数据库服务器启动或者业务高峰对计算资源是极大的挑战，分配8vCPU和16G内存。应用与代理服务器 分别使用4vCPU结合8G与4G内存组成分布式高性能群集。虚拟桌面 用户对于运算资源的需求相对比较低。一般情况下有播放 720p 视频需求， Windows7 64bit 的用户我们建议使用2vCPUs。
本案需要部署3台DELL R720服务器, 每台配备2颗E5-2620v3服务器CPU，至少需要284内存。为了保证硬件一致性与宿主机的稳定，取整采购288G( 16G单根内存)， 其中生产环境采购192G, 办公环境补充96G内存，以整体满足本次项目中跨数据中心容灾及可迅速弹性扩展的计算资源要求。
1.2.1 存储规划设计
本系统负责完成对业务系统的支持，对系统的高可靠性有着很高的要求。作为该系统核心的存储平台的高可靠性则更是重中之重。由于采用了集中存储的方案，所有的信息存储，信息管理及信息共享均集中存储于统一的平台之上，存储平台的任何故障会造成巨大的影响。因此存储平台的数据安全性和系统高可靠性尤为重要。另外本案存储的架构充分考虑到了跨数据中心级别的容灾迁移，企业关键核心将在业务空闲时段进行跨站点的数据备份，以满足容灾需要
1.2.2 系统的高性能
存储系统要存储大量的在线数据信息,支持更多服务器的在线业务并发写要求。由于总的数据量会很大,如何在这么大数据量情况下满足这么多客户机的并发访问，整个存储系统的性能也是一个非常关键的要求。而且考虑到将来业务的增长，数据量还会持续增加，客户机的数量也会继续增加，系统的性能还应能很好的适应未来的扩充和扩展的需要
1.2.3系统的可扩展性/可扩充性
作为集中存储的基本要求，存储系统应能支持巨大的存储容量，可以集中存储不同平台的企业数据，从而使企业在保留分布式处理好处的同时实现核心信息的集中存储和集中管理。
随着时间的推移、技术的发展以及环境的变化，业务系统的数据量会飞速增长，许多新业务系统会不断产生，因此对存储系统的可扩展性有很高要求。尽管我们在本方案中已经充分考虑了系统存储容量空间的预留，但随着业务的发展，对存储系统的可扩展性要求仍将非常迫切。这主要表现在对存储系统容量的平滑扩充以及对新的主机（HOST）系统的平滑连接，以尽量减少对已有正常业务的影响。
1.2.4 系统的多平台支撑能力
本系统是一个多层的体系结构，在集中的存储平台之上要为数据库服务器，应用服务器和其他服务器提供统一的存储方案。这不可避免的涉及到存储系统的多平台支持能力。作为应用服务器可能会采用Linux服务器，作为其它服务器可能会采用的是Windows 等。作为集中存储的基本要求，存储系统必须能够同时连接不同的服务器平台，以满足数据集中的需要。
1.2.5 灵活性和系统管理的简单性
由于存储系统的数据量非常大，如何有效的管理大量的数据，包括数据备份/恢复，都对存储系统的管理提出了巨大的挑战。系统管理人员需要有高效的方法实现全面的存储系统监控，包括实时数据性能监视、错误监测、错误状态识别等等。另外作为集中的存储平台，由于前端需要连接的服务器数量很多，如何在多个服务器平台之间对容量进行灵活的划分和调度也是为存储系统的管理提出了巨大的挑战。
1.2.6 存储的虚拟化
DELL SCv2000s系列存储设备将存储资源虚拟成一个“存储池”，这样做的好处是把许多零散的存储资源整合起来，从而提高整体利用率，同时降低系统管理成本。与存储虚拟化配套的资源分配功能具有资源分割和分配能力，可以依据服务的要求对整合起来的存储池进行划分，以最高的效率、最低的成本来满足各类不同应用在性能和容量等方面的需求。特别是虚拟磁带库，对于提升备份、恢复和归档等应用服务水平起到了非常显著的作用，极大地节省了企业的时间和金钱。 除了时间和成本方面的好处，存储虚拟化还可以提升存储环境的整体性能和可用性水平，这主要是得益于“在单一的控制界面动态地管理和分配存储资源”。 在当今的企业运行环境中，数据的增长速度非常之快，而企业管理数据能力的提高速度总是远远落在后面。通过虚拟化，许多既消耗时间又多次重复的工作，例如备份/恢复、数据归档和存储资源分配等，可以通过自动化的方式来进行，大大减少了人工作业。因此，通过将数据管理工作纳入单一的自动化管理体系, 存储虚拟化可以显著地缩短数据增长速度与企业数据管理能力之间的差距。
1.2.7 存储容量规划
充分利用DELL SCv2000s系列存储的分层，分资源I/O特性，把企业关键的核心业务放置到最先进的SSD存储固态磁盘群集中运行，把性能要求不高但是大容量需求的静态资源放置到存储普通硬盘群集中运行，其次VDI桌面系统放置到服务器本地的普通硬盘群集，另外存储中划分一块区域作为VDI桌面的跨数据中心容灾使用。
容量规划如下表所示：
1.2.8 跨数据中心网络设计
流量调度：
1.数据中心层面：我们推荐使用两层逻辑算法的智能DNS调度策略，首先，全局负载设备会判断用户的地理位置，将用户调度到速度最快的网络线路，解决南北互访的问题；其次，根据用户所属运营商选择对应链路供用户接入，解决跨运营商访问慢的问题。此外，全局负载还可对客户端LDNS发起反向探测，判断用户网络质量，为用户选择最佳接入路径。
2.服务单元层面：WEB、APP和DB服务单元都配备了本地负载均衡器，用户访问流量到达数据中心内部后，由服务单元的负载设备根据预设策略分发给各服务器，可根据用户需求灵活选择轮询、优先级、最小连接等算法。
业务连续性：
1.数据中心层面：通过DC Cookie保证用户接入同一数据中心。用户首次访问时，本地WEB负载设备在响应数据包中插入DC Cookie，当客户端网络发生变化时，第二次访问就可能被调度到其他数据中心，这时其他数据中心的WEB负载设备会识别该Cookie，将用户请求转发至第一次处理该用户访问的WEB负载设备，再由该负载设备进行调度。
2.服务单元层面：WEB服务单元的负载建议通过cookie会话保持（插入、改写和被动）保证业务连续性；APP服务单元的负载可通过cookie或源IP会话保持保证业务连续性（是否需要会话保持，选择何种会话保持方式需要结合应用具体情况）；DB服务单元一般不需要会话保持。
健康状态检查：
1.服务单元层面：通过内置的应用级健康监视器对服务器进行主动探测，提供HTTP、HTTPS、RADIUS、FTP等常用模板。对于其他应用，提供接口供用户自定义检测内容和响应内容。此外，还提供极具特色的被动健康检查功能，通过对TCP和HTTP协议的数据交互做采样分析，判断服务器的健康状态。
2.数据中心层面：全局负载与服务侧的各区域负载均衡联动，实时共享信息，判断服务侧整体服务能力；同时全局负载设备会探测出口各链路健康状态，结合服务侧整体服务能力和设备自身负荷情况，综合判断该数据中心的健康状态（正常、繁忙、故障）。
故障切换：
1. 服务单元层面：服务单元内部某服务器繁忙或故障时，将用户请求调度到其他正常服务器。
2. 数据中心层面：生产数据中心的WEB或APP服务器全部繁忙或全部故障时，用户接入链路不切换，通过专线将数据转发至正常数据中心对应服务单元。
生产主数据中心的数据库服务器全部故障时，用户接入链路不切换，通过专线将直接激活备数据中心的数据库，实现数据库一键切换。数据库切换前需要验证数据库的正确性，用户需要完成数据验证并保证数据库按顺序切换。
数据中心的所有链路同时故障时，全局负载设备将用户流量平滑牵引至办公数据中心。单链路故障时，可根据用户需求切换至本中心其他链路或其他中心同ISP链路。此外，当某数据中心出现服务能力不足时（链路繁忙、服务单元繁忙等），全局负载设备还可以基于数据中心的整体健康得分情况将用户分流至其他数据中心，保障用户正常访问。
业务优化加速：
互联网区的WEB服务单元直接面向公网，受公网网络质量影响较大，负载均衡可通过协议优化、数据压缩和智能加速等技术减少网络环境影响，提高用户访问体验。此外，外网用户会有大量重复请求，通过负载设备的高速缓存技术，对静态和内容进行缓存，减少服务器数据交互，降低服务器性能压力，提高访问速度。
跨数据中心的数据库同步需占用大量带宽资源，且数据量非常大，部署WOC设备可大幅压缩传输数据，削减流量。WEB或APP服务单元跨数据中心通信时，通过WOC设备的协议优化和流缓存等技术实现加速。当二者同时需要大量带宽资源时，优先保证数据库同步。
1.3 应用服务控制与负载均衡设计
1.3.1功能介绍
通过F5 BIG-IP 应用交付解决方案实现应用负载均衡, NetScaler应用交付解决方案将传统数据中心产品的各项特性与功能整合至一个单独的网络设施中，其中包括负载平衡、缓存、SSL加速、攻击防御和SSL VPN等。这一设施经过精心设计，旨在最大限度地提升应用性能。
由于应用通常要求在服务器和客户机之间建立端到端连接，并需将单个应用请求隐藏起来，因此，构建智能应用基础设施极具挑战性。这种针对单个应用请求所进行的“隐藏”，使得众多应用层解决方案在应对智能应用时几乎一筹莫展、无计可施。
而建立在F5 BIGIP的“请求交换”TM专利架构之上的F5 BIG-IP产品，却是业内首款可根据其强大的用户定义策略来处理每种应用请求的线速级技术。F5 BIG-IP的面向应用型策略引擎，能够独立于连接之上，针对单独的请求创建详细的基于策略的决策,使管理员能够创建复杂的应用请求处理策略，并支持基于应用的强大完善特性。
1.3.2 应用优化与应用交付设计
采用 F5 BIG-IP 产品
1.3.3 XX平台数据中心应用优化方案
应用优化：
本案应用优化主要通过三个方面进行
代码级别改造，解决代码中执行性能差，容易造成业务中断的部分。并且通过业务代码切分，使代码可以跨主机部署，分应用部署，使应用资源完全分离，互相不干扰，充分利用虚拟化与云计算带来的高速体验。
架构级别改造，实现代码的动静分离，负载负载均衡转发，防止单点故障形成，防止静态资源占用过多的带宽。
Web Portal主要用于提供静态内容
Application主要用于提供动态内容
通过F5 LTM来实现负载均衡
提供12种灵活的算法将所有流量均衡的分配到各个服务器，而面对用户，只是一台虚拟服务器。
可以确认应用程序能否对请求返回对应的数据。假如F5 BIG-IP后面的某一台服务器发生服务停止、死机等故障，F5会检查出来并将该服务器标识为宕机，从而不将用户的访问请求传送到该台发生故障的服务器上。这样，只要其它的服务器正常，用户的访问就不会受到影响。宕机一旦修复，F5 BIG-IP就会自动查证应用已能对客户请求作出正确响应并恢复向该服务器传送。
具有动态Session的会话保持功能。
iRules功能可以做HTTP内容过滤，根据不同的域名、URL，将访问请求传送到不同的服务器。
数据库应用优化：
XX平台数据库使用MySQL5.6，通过MySQL服务器复制功能对现有建构进行优化改造，可以在主服务器和从服务器之间实现负载均衡。即可以通过在主服务器和从服务器之间切分处理客户查询的负荷，从而得到更好的客户相应时间。出于技术成熟度、成本等因素考虑，数据库采用主备方式部署，数据库写入操作都在生产数据中心的主库进行，办公数据中心从库进行数据同步，默认情况下可提供只读查询，分担主库的负载。发生灾难时，办公数据中心间的从库可以快速切换为主库，避免业务中断；
在生产数据中心和办公数据中心都部署F5 BIG-IP的LTM模块实现数据库的负载均衡。通过F5 BIG-IP的iRules模块对数据库健康状态进行实时监测，实现跨数据中心的负载均衡及容灾方案。
数据库复制功能实现了主服务器与从服务器之间数据的同步，增加了数据库系统的可用性。当主服务器出现问题时，数据库管理员可以马上让从服务器作为主服务器，用来数据的更新与查询服务。这样子提供了充足的时间去检查主服务器的问题，等主服务器故障恢复后再进行主从切换，恢复原有架构。
在数据库之间实现负载的均衡，其关键点就是数据同步的时间。如果主服务器与从服务器之间数据的更新时间比较长，此时从主服务器中查询得到的数据就会同从从服务器中得到的数据有差异。而如果同步的时间比较短，如实现同步复制，对网络带宽、服务器设备等就有比较高的要求。
1.4 数据中心安全设计
1.4.1网络准入控制
如何保障网络信息安全，来自内部用户的威胁如何最大限度地减少或避免因网络内部接入客户端因素造成的信息泄漏和破坏，成为摆在我们面前一项刻不容缓的重要课题。由于XX平台的信息系统是基于WEB访问技术的，本案可以利用F5 BIG-IP Better Bundle中模块中赠送的SSL-VPN(免费10 用户并发) 结合活动目录Active Directory来实现准入控制和统一认证。
F5的SSL VPN不是利用传统的VPN客户机来提供全部网络接入支持，而是利用浏览器作为客户机与服务器之间的连接器，来支持远程访问个别应用。
• 支持从远端客户机访问应用服务器上的TCP应用。
• 可支持本地客户机端应用通过浏览器与SSL-VPN服务器之间的安全隧道，与公司的应用服务器进行通信。
• 允许连接的用户将LAN驱动器映射到远程系统。
• 无需用户预先安装或配置任何额外组件。
• 在网络端，被访问的应用服务器上无需安装额外软件。
• 采用标准HTTPS协议，并以SSL作为传输协议，因此可支持任何HTTP代理–包括公共接入点、专用LAN以及任何不支持传统IPSec VPN的其它网络和ISP。
• 身份认证技术系统通过密码来对照内部数据库进行鉴权。F5-SSL VPN经配置后可与RADIUS和LDAP鉴权方法、基于表格的基本HTTP鉴权以及负责鉴权与访问管理的AD联合运行。
1.4.2 VDI虚拟桌面安全管理
由于计算发生在数据中心，所有桌面的管理和配置都在办公数据中心进行，管理员可以在数据中心进行对所有桌面和应用进行统一配置和管理。例如系统升级、应用安装，等等。由于传递的只是最终运行图像，所有的数据和计算都发生在数据中心，则机密数据和信息不需要通过网络传递，增加了安全性，另外这些数据也不允许下载到客户端，保证用户不会带走、传播机密信息。
1.4.3 智能的监控、分析和威胁响应
数据中心层面：
网络出口处部署F5 BIG-IP防护设备并在运营商处购买流量清洗服务，保证数据中心整体安全。
网络出口处部署FW和IPS设备，从网络层和应用层保证数据中心不被恶意入侵。
F5 BIG-IP全局负载设备提供DNS防火墙功能，充分保证DNS安全。
DNSSEC 支持、UDP Flood、DNS 放大和反射。
服务单元层面：
各服务单元部署防火墙，保证区域安全。WEB服务单元直接面向互联网用户，需要部署SSL卸载设备实现SSL加解密，提高业务访问安全。同时，通过部署WAF保障WEB服务器的安全。
1.5 数据中心运维保障体系建设
1.5.1 运维监控系统建设方案
面对复杂的业务监控和问题诊断，通过大数据分析找到指标和事件之间的关联关系，进行因果关系推导，并最终定位故障，制定解决方案。使运维能够更加自动化、智能化地达成 保证服务高可用性的目标，即快速的问题发现、分析定位或止损。 本案采用企业级的开源分布式监控解决方案 Zabbix，并在该方案的基础上进行扩展，出现性能告警时不仅通过各种渠道进行通知，更可以通过定制 APP 进行进一步日志信息获取、方 案智能推荐和自动执行，达到远程智能处理的效果，实现智能运维
1.5.2 监控管理
通过zabbix server与可选组件zabbix agent，zabbix server可以对SNMP，zabbix agent，ping，端口监视等方法提供对远程服务器/网络状态的监控，数据收集等功能。可以对包括：CPU负荷、内存使用、磁盘使用、网络状况、端口监视、日志监视等功能进行监控，同时也可以对vmware，java，数据库，weblogic等系统进行监控。
zabbix支持多种网络方式下的监控，可通过分布式的方式部署和安装监控代理
Server：即安装 zabbix 服务的服务器，是最核心的部份，支持多种操作系统，Zabbix Server 运行在主流 LAMP 环境下，资源要求较低。
Agent：即安装在被监控设备上的 zabbix 代理，被监控设备上的数据由代理收集后统一上传到服务器端由服务器端收集、整理并呈现。目前已有的 agent 基本支持市面常见的OS。
SNMP：为 agent 的一种，指支持 SNMP 协议的设备，通过设定 SNMP 的参数将相关监控数据传送至服务器端，支持各类常见的网络设备。
IPMI：Agent 的另一种方式，应用于设备的物理性能监控，如设备的温度、风扇的转速等
1.5.3 网络监控
端到端的网络设施平台，高级故障和性能管理功能，管理WAN、VoIP、网络设备, 自动发现网络设备一系列包含设备配置的设备和接口模板
从支持NetFlow的设备直接导出NetFlow，详细了解网络中带宽使用情况
查看带宽使用图样，生成报表，无需部署硬件探针，节约成本
通过采用SNMP模板深入了解网络流量及其模式，实时掌握网络状况，以及流量如何影响网络总体健康状况
1.5.4 服务器监控
采用Zabbix-Agent代理方式监控服务器
监控服务器负载、磁盘利用率、进程、内存利用率、磁盘I/O、服务器CPU利用率等
1.5.5 应用监控
监控各种WEB、VDI、AD、邮件等业务关键应用
通过监控Microsoft .NET、Oracl、JBoss、Tomcat、WebLogic、WebSphere和Nginx，保证应用服务器健康状况和可用性
监测和诊断应用服务器及其服务出现的问题，保证正常运行
1.5.6 数据库监控
监控包括Oracle、MS SQL和MySQL的异构数据库服务器环境
数据库管理员可以规划资源需求，及时排除故障
数据库大小、缓存大小、数据库连接时间标签，方便查看
1.6 采购需求
1.6.1 硬件部分
1.6.2 软件部分
1.6.3 实施部分
2、某金融企业双活设计案例
2.1 项目介绍
本项目采用EMC VPLEX METRO解决方案，实现深圳RCCB老街和沙井（暂放在老街）两个机房容灾，结合实际情况本项目规划如下。
2.1.1 存储双活架构
注：本项目NS480、VNX5700和VPLEX共用SAN交换机
2.1.2 本项目设备配置
本次采购的VPLEX配置简要描述如下：
1. 2个处理器引擎，16个8Gb的FC前端口，16个8Gb的FC后端口
2. 144GB Cache
3. VPLEX METRO 10TB
4. 本次采购的VNX5700配置简要描述如下：
5. 5个300GB 15K SAS磁盘，85个600GB 15K SAS磁盘，45个2T 7200 SATA磁盘
6. 2个DATA MOVE
7. 本次采购的DCX配置简要描述如下：
8. 两台交换机，每台配置4张扩展卡,每卡48个端口。
2.2 存储设计实施
2.2.1 规划目标
VNX5700和NS480存储使用VPLEX local架构，并且同时要支持NAS。结合客户实际的应用，并且满足VPLEX METRO双活的解决方案规划如下。
2.2.2 Raid类型选择
由于本次采购的VNX5700支持block和file，block采用的raid 5的方式建立raid group。
2.2.3 VPLEX端口的使用
本项目中vplex版本为vs2，每台vplex有两个引擎每个引擎有两个控制器。每台主机配置了2张双口HBA卡用于连接VPLEX，每张卡使用一个端口，VPLEX的后端口用于连接VNX5700和NS480。所有VPLEX端口的使用如下表所示：
2.2.4 命名规则
VPLEX的端口命名规则：E1A0F0代表引擎1的director A的A0模块的第0口
VNX5700的端口命名规则：SPB2代表StroageProccess B的FC第2口
Zone的命名规则：VPLEX1_E1B2F2_VNX5700A_SPB2代表VPLEX1的引擎1的director B的B2模块的2口到VNX5700B的StroageProccess B的第2光纤口的zone。
2.2.5 端口连接交换机
注：此图为一台VPLEX的端口连接图。
VNX5700端口的使用
2.3 SAN网络规划
本项目使用的是两台DCX SAN交换机，vplex到一台dcx交换机需要24条光纤（8个FE，8个BE，8个Wan com）共计48条光纤。
2.3.1现有拓扑示意图
2.3.2存储迁移后拓扑示意图
注：线只代表路径，不代表数量。
2.3.3 VPLEX实施拓扑示意图
注：本图未注明网络连接
2.3.4设备IP规划
注：IP需求由客户工程师规划
2.3.5 SAN交换机端口分配表
注：交换机IP地址，Domain ID由客户补充完成。SWWN由工程师实施时由工程师记录。具体请更新文档《DCX光纤交换机配置.xls》，上图仅为SAN交换机配置示意，在后期实施过程中可不再更新。
2.3.6 Zone规划
由于本次采购两台DCX交换机（配置4*48口模块），替换原有两台DS5000B和DS5100B
交换机迁移完成后，为后期的的vplex实施需要增加vplex到存储的zone
主机到vplex的zone按照实际情况修改
Wan COM的zone
2.4 数据的迁移
本项目采用迁移存储的的控制器端口的方式来实现，CX3-80具体过程概述如下：
在DCX交换机上建立对应的zone
检查CX3-80上存储控制器的健康状态
每个SP选择一个NAS使用的端口准备连接到DCX交换机
在主机上移除这两个端口对应的路径
确认主机和NS网关的状态正常
拔除SP端口上的旧光纤，使用新光纤连接到DCX交换机
在CX3-80注册vplex的BE端口
把vplex 加入要迁移的storage group
在vplex上扫描lun，封装lun
在vplex上注册主机的wwn并建立mask view
NS-480具体过程概述如下：
在DCX交换机上建立对应的zone
检查NS-480上存储控制器的健康状态
每个SP选择一个DataMove3使用的端口准备连接到DCX交换机
关闭DataMove3
确认主机和DataMove2的状态正常
拔除SP端口上的旧光纤，使用新光纤连接到DCX交换机
在NS-480注册vplex的BE端口
把vplex 加入要迁移的storage group
在vplex上扫描lun，封装lun
在vplex上注册主机的wwn并建立mask view
2.4.1迁移前的准备
建立系统在NS-480和CX3-80上的lun信息，完成主机名、物理位置、光纤卡、WWN、在对应存储上的lun id 和大小信息的表格lun.xsl。
在vnx5700上根据lun.xsl的信息准备好对应的lun并增加lun.xsl的vnx的列。
在DCX上建立所有要迁移的主机到vplex的zone，并核对无误。
准备lun 封装的脚本并核对无误。
2.4.2迁移过程的拓补图
注：CX3-80也采用此方式迁移
2.4.3存储层面的迁移
VPLEX层面的离线数据转移方式将应用系统从传统的存储系统上转移到VPLEX环境中，在转移期间，应用系统需要停止运行，迁移步骤简述如下：
应用系统停止运行
存储系统回收应用系统使用的存储空间，然后将其分配给VPLEX
VPLEX将存储空间进行“封装”后分配给主机
恢复应用系统的运行
2.4.4 应用系统数据迁移实施步骤简述
安装支持VPLEX的EMC ODM软件
安装EMC PowerPath软件
如果主机没有安装PowerPath软件，请参照“PowerPath for AIX Installation and Administration Guide.pdf”，安装和配置PowerPath软件。
SAN Switch上增加主机与VPLEX前端端口之间的ZONE
在SAN Switch（DCX_A、DCX_B）上，创建主机HBA与VPLEX前端端口之间的ZONE。
VPLEX分配磁盘空间给主机
根据应用系统所使用的磁盘设备的数量和大小，在VPLEX上创建相应数量和大小的Distributed Device（由来自于VNX5700和NS480的磁盘设备组合成RAID 1类型），并且创建包含这些Distributed Device的Consistency Group，然后分配给主机。
主机识别和配置VPLEX磁盘设备
运行“/usr/lpp/EMC/INVISTA/bin/emc_cfgmgr –v”命令，识别和配置VPLEX磁盘设备
确认已经正确识别和配置VPLEX磁盘设备
运行“powermt config”命令，配置PowerPath设备，并且确认VPLEX磁盘设备的policy是Adaptive
在主机上将旧的磁盘设备清除，保留VPLEX磁盘设备
系统管理员将旧的存储系统磁盘设备清除，保留VPLEX磁盘设备
VPLEX层面的离线数据转移方式实施步骤简述
在VPLEX环境中，对后端存储系统的磁盘设备采用整盘封装的方式下，可以将应用系统完整的迁移到VPLEX环境中。
在主机上，停止应用系统的运行
在主机上，删除相应的后端存储系统的磁盘设备的映射关系
在主机上，安装支持VPLEX的EMC ODM软件
在后端存储系统上，取消主机对磁盘设备的访问
（可选）在SAN Switch上，删除主机HBA与后端存储系统前端之间的ZONE
在SAN Switch上，增加VPLEX后端端口与后端存储系统前端之间的ZONE
在SAN Switch上，增加主机HBA与VPLEX前端端口之间的ZONE
在后端存储系统上，赋予VPLEX对磁盘设备的访问
在VPLEX上，对后端存储系统的磁盘设备进行整盘封装，以及增加镜像的操作
在VPLEX上，将封装后的VPLEX磁盘设备分配给主机
在主机上，识别和配置VPLEX的磁盘设备
在主机上，启动应用系统
2.4.5 NAS数据的迁移
按照原来的cifs/nfs服务器设置，建立新的cifs/nfs服务器
使用Replicatior复制文件系统和iscsi
关机维护前做一次增量copy
umount旧nas系统
Mount 新nas到原来使用的目录
2.4.6 NAS数据迁移实施步骤简述
配置NAS control station 之间的连接
配置
配置data mover之间的连接
配置
源端
目标端
检查
[ALL NAS]$nas_cel -interconnect -list
[ALL NAS]$nas_cel -interconnect -validate connect_name
配置文件系统间的复制
(注：maxTimeOutOfSync＝10 minutes)
配置
从源端切换目标端
ISCSI数据迁移步骤（主机层面迁移） 推荐
Iscsi lun 建议新建一个iscsi lun给VMware，在主机层面做数据迁移
Iscsi lun创建例子
ISCSI数据迁移步骤（存储层面） 备用
在目标端建立容量一样的LUN，建立时设置为只读模式
主机initiator连接新存储
建立复制( 保证源端和目标端的文件系统有足够的空间FSmin
SizeofLun + SizeofSnapshots + SizeforTWS)
nas_replicate -create <name> -source -lun <lun number > -target <target name> -destination -lun <lun number > -target <target name> -interconnect <name> -source_interface ip=xxx.xxx.xxx.xxx -destination_interface ip=xxx.xxx.xxx.xxx -manual_refresh
例子
nas_replicate -create dm2_lun1-dm3_lun1 -source -lun 1 -target iqn.1992-05.com.emc:bb000c29c2de300000-3 -destination -lun 1 -target iqn.1992-05.com.emc:bb000c29c2de300000-4 -interconnect id=20003 -source_interface ip=192.168.137.40 -destination_interface ip=192.168.137.60 -manual_refresh
主机卸载旧ISCSI LUN
NS480停止ISCSI服务
VNX5700启动ISCSI服务，mask新ISCSI LUN给主机
主机验证ISCSI LUN
2.4.7数据迁移回退步骤简述
在客户环境中，VPLEX对后端存储系统的磁盘设备采用整盘封装的方式，因此，应用系统可以回退到传统的直接访问后端存储系统的磁盘设备的工作方式。由于之前的交换机和光纤线都还在使回退变得很容易。
主机删除相应的VPLEX的磁盘设备
VPLEX上删除相应的Storage View，取消主机对VPLEX磁盘设备的访问
（可选）在SAN Switch上删除主机HBA与VPLEX前端之间的ZONE
（可选）在SAN Switch上删除VPLEX后端与后端存储系统前端之间的ZONE
在后端存储系统上取消VPLEX对后端后端存储系统的磁盘设备的访问
把主机的原来使用的光纤线插回对应原来的交换机
在后端存储系统上分配磁盘设备给主机
主机识别后端存储系统的磁盘设备，启动应用系统
在VPLEX上，清除后端存储系统磁盘设备的配置信息
点击阅读原文可下载《银行双活容灾建设方案技术手册》全篇，含分析、规划、实施