警务云灾备数据中心建设方案文档格式.docx

上传人:b****6 文档编号:8539055 上传时间:2023-05-11 格式:DOCX 页数:12 大小:555.12KB
下载 相关 举报
警务云灾备数据中心建设方案文档格式.docx_第1页
第1页 / 共12页
警务云灾备数据中心建设方案文档格式.docx_第2页
第2页 / 共12页
警务云灾备数据中心建设方案文档格式.docx_第3页
第3页 / 共12页
警务云灾备数据中心建设方案文档格式.docx_第4页
第4页 / 共12页
警务云灾备数据中心建设方案文档格式.docx_第5页
第5页 / 共12页
警务云灾备数据中心建设方案文档格式.docx_第6页
第6页 / 共12页
警务云灾备数据中心建设方案文档格式.docx_第7页
第7页 / 共12页
警务云灾备数据中心建设方案文档格式.docx_第8页
第8页 / 共12页
警务云灾备数据中心建设方案文档格式.docx_第9页
第9页 / 共12页
警务云灾备数据中心建设方案文档格式.docx_第10页
第10页 / 共12页
警务云灾备数据中心建设方案文档格式.docx_第11页
第11页 / 共12页
警务云灾备数据中心建设方案文档格式.docx_第12页
第12页 / 共12页
亲,该文档总共12页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

警务云灾备数据中心建设方案文档格式.docx

《警务云灾备数据中心建设方案文档格式.docx》由会员分享,可在线阅读,更多相关《警务云灾备数据中心建设方案文档格式.docx(12页珍藏版)》请在冰点文库上搜索。

警务云灾备数据中心建设方案文档格式.docx

公安业务业务分级

A级

B级

C级

D级

业务重要性

核心业务

重要业务

一般业务

辅助及测试业务 

业务影响范围

部级/省级

市、县级

办公室级

小组级

数据重要性

核心原始数据

二次处理数据

总结数据

测试数据

业务连续性(维护时间)

<

30分钟/次

60分钟/次

2小时/次

4小时/次

公安业务系统按照业务模式可划分为BSS、OSS和MSS三类,其应用模型对应OLTP和OLAP两种模式,如下表所示:

公安业务类型划分

业务模式划分

BSS(业务支撑系统)

公安情报、综合信息查询、交通管理、出入境、机动车驾驶人信息、刑侦、治安、决策指挥等

OSS(运营支撑系统)

内部网管、网优、资源管理PKPMI、数据交换平台、请求与服务、搜索引擎等系统

MSS(管理支撑系统)

OA、邮件、财务、ERP,手机办公、后勤管理等系统

应用模式划分

OLTP

BSS、OSS;

高数据负载、高网络负载;

多线程应用;

多用户并发;

响应实时性高、事务小而多(除峰值阶段)

OLAP

BASS;

高数据负载;

响应实时性较低、事务大而少

结合公安行业的主要应用系统,对业务系统的灾备建设需求综合评定如下表所示:

业务名称

业务模式

应用模式

业务连续性

综合评定

警综系统

BSS

OLTP/OLAP

核心业务

核心原始

30分钟

A

情报系统

部门间共享和服务

重要业务

PGIS

综合信息查询

二次处理

DNA信息系统

60分钟

A/B

指纹信息系统

现场勘验系统

交通综合管理系统

出入境管理系统

经侦信息系统

人口信息管理系统

治安信息管理系统

决策指挥

资源管理

OSS

网管系统

数据交换系统

请求服务系统

1小时

B

OA

MSS

邮件

2小时

后勤管理

一般业务

C

测试业务n

BSS/OSS/MSS

测试业务

测试数据

4小时

D

1.1.3警务综合平台场景分析

1.1.3.1业务场景分析

公安的大部分业务各类应用系统隶属于公安系统不同业务管理部门,是在不同的时期建立的,因此它们所运行的平台、数据结构等是不同的。

警综平台是公安主体业务网上办理、网上流转和警务信息资源大集中、高共享的信息化工作平台,实现公安业务系统整合和业务信息最大化共享。

其建设目标:

∙实现公安业务系统整合,完成单点登录,全网漫游;

∙建立公安信息库进行整合,形成数据仓库,消除部门间的信息孤岛;

∙在整合基础上进行各类应用,实现公安信息资源的最大化利用。

图32警务信息综合应用架构

警综平台的建设涉及到以下8个基础信息数据库:

数据库名称

责任单位

人口基本信息资源库

户政

出入境人员资源库

出入境管理

机动车/驾驶人信息库

交警

警员基本信息资源库

人事

在逃人员信息资源库

监所管理

违法犯罪人员信息库

被盗抢汽车信息资源库

安全重点单位信息资源

治安

警综平台里面包含诸如警用地理信息系统、大情报系统等多个分支系统,出于应用需求,这些应用系统都具备专用的数据库以及硬件设备,这些数据库和硬件设备也是属于警综平台的。

一般情况下,这些应用系统都是独立立项建设,然后融入到警综平台中统一维护和管理,具体情况将在下面分项应用系统场景分析中介绍。

除去专用的应用系统外,警综平台存储建设的重点就是8个基础信息库的建设。

1.1.3.2警综平台需求分析

∙高性能需求:

多个业务部门及下级部门同时进行信息录入以及信息查询,需求存储系统高性能以满足业务需要。

∙异构阵列统一管理需求:

警综平台建设时间长,原本各系统各自建设,警综平台整合时不可能完全抛弃原有系统。

现有大部分省市的警综平台中,存储系统普遍存在异构存储阵列多,数据互联互通困难,设备管理复杂,扩容、容灾困难等问题。

需统一管理、统一规划。

∙高可靠及业务连续性需求:

警综平台建设的原则就是警务信息资源大集中、高共享。

然而信息的集中意味着风险的集中,信息集中后的警综平台一旦发生故障致使业务中断或者数据丢失,其影响的几乎是所有公安系统业务。

因此警综平台的业务安全性和可靠性在公安内部就是一项重要的政治任务。

1.2总体架构设计

基于系统总体设计原则,结合华为公司在**行业灾备系统成功案例和实际经验,推荐**行业灾备总体架构如下图。

推荐灾备总体架构为同城和异地的两地三中心模式。

同城灾备推荐A类业务采用同城应用双活灾备;

B类业务采用同城应用主备灾备模式;

C类业务采用数据级主备(如通过阵列异步复制功能实现)。

异地灾备推荐A、B类业务采用应用主备灾备模式;

C类业务采用数据级主备(如通过阵列远程异步复制功能实现)。

1.3应用双活架构设计

针对公安行业核心业务(如警务云、八大库)的高业务连续性要求,推荐采用华为双活灾备解决方案。

该方案采用虚拟化存储网关和主机集群、网络集群技术在同城的两个数据中心构建跨站点的业务集群和存储虚拟化集群。

双活灾备方案有别于传统主备模式的容灾方案,传统的主备方案,灾备中心不能对外提供服务,只有当灾难发生时业务才切换到灾备中心,造成业务中断时间长、业务切换风险高和设备资源利用率低的问题,华为双活灾备解决方案能够实现双数据中心同时对外提供负载均衡的业务,并且保障在集群单设备故障或者单站点故障的情况下,数据不丢失、业务不中断,实现RPO=0、RTO=0的业务连续性指标。

∙同城双活方案架构描述

采用虚拟化存储实现存储双活架构,为两个数据中心存储同时提供读写服务,且整个存储系统架构全冗余,任意数据中心故障时,另外一个数据中心有一份存储设备和相同数据可用,最大化提高了业务连续性。

在新建数据中心部署多台虚拟机服务器平台,以及虚拟化存储和存储阵列等设备,同老数据中心现有的虚拟化服务器平台和之前采购的虚拟化存储设备之间组成双活集群。

整个双活系统分为存储层、前端网络层与应用层与容灾管理层。

存储层,新老数据中心各部署一台华为存储,组成一个存储双活集群,为两数据中心主机业务同时提供读写服务。

同时,在新建数据中心配置与现网HP阵列系列(如HPXP24000)同等级和同容量的存储阵列。

为了提升热点数据的存储性能,使高价值硬盘得以更充分的利用,可以配置不同类型的硬盘:

SAS、NL-SAS、SSD以合理分配资源;

通过业务存储提供的智能分级功能对热点数据进行持续监控并从机械硬盘迁移到SSD中,进一步提升系统性能。

两个数据中心的存储阵列利用HyperMetro双活技术做镜像冗余配置,使得两个数据中心存储数据实时镜像,互为冗余。

任意数据中心故障,数据零丢失,实现数据层面的双活。

网络层,数据中心之间应用集群IP心跳和FC数据传输网络都采用裸光纤直连,传递应用集群信息和双写IO数据同步,满足双活数据中心网络时延要求。

应用层,两个数据中心的虚拟机服务器构成一个集群,通过警务云虚拟化平台的DRS提供跨数据中心的虚拟化自动负载均衡,通过警务云虚拟化平台HA提供跨数据中心的自动故障转移功能,实现业务层面的双活。

容灾管理层,为了实现双活数据中心存储设备的统一管理,建议部署统一容灾管理软件,通过统一容灾管理软件实现双活数据中心的可视化管理,并通过管理软件直观的展示双活业务的物理拓扑。

针对虚拟机业务双活需要,可以将容灾管理软件部署在两个数据中心当中任意一台虚拟机上,即可实现管理业务的双活。

建议部署拓扑图如下:

2关键技术

2.1网络层解决方案

2.1.1全局负载均衡(GSLB)

技术概述

随着用户对应用可用性和扩展性需求的进一步增加,越来越多的用户不满足于在单一数据中心提供服务,开始考虑容灾、用户就近访问等问题。

这正是负载均衡设备中的全局服务器负载均衡技术(GSLB)所要解决的问题。

绝大部分使用负载均衡技术的应用都通过域名来访问目的主机,在用户发出任何应用连接请求时,首先必须通过DNS请求获得服务器的IP地址,基于DNS的GSLB正是在返回DNS解析结果的过程中进行智能决策,给用户返回一个最佳的服务IP。

适用场景

全局负载均衡技术适用场景如下:

∙跨站点负载均衡:

可以实现跨数据中心的流量分担,用户就近访问某一数据中心。

∙客户端访问切换:

当生产中心故障,可以将用户的访问流量自动切换到容灾站点,从而实现客户端访问路径的自动切换。

组网架构

GSLB对于DNS请求的处理流程如下:

1) 

客户端向本地DNS发起站点查询请求。

2) 

当本地DNS中没有该站点对应的IP地址信息时,则转发该请求给GSLBMaster。

3) 

GSLBMaster转发该请求给所有GSLBSlave。

4) 

所有GSLBSlave反馈响应信息给GSLBMaster。

5) 

GSLBMaster会选择最快响应的GSLBSlave(例如:

SiteA中的GSLBSlave),并返回应答给本地DNS。

6) 

本地DNS转发GSLBMaster的应答给客户端。

7) 

客户端就可以访问提供服务的应用服务器了,例如:

SiteA中的RealServer。

技术特点

从GSLB处理流程可以看出,其核心在GSLB策略,常用的一些GSLB策略包括:

各内容站点的“健康状况”

GSLBController对各内容站点负载均衡设备上定义的VIP或服务器(没有本地负载均衡的情况)进行第四层TCP/UDP健康检查和第七层应用健康检查。

未能通过健康检查的站点不会被选为最佳的内容节点。

地理区域或用户自定义区域

一个区域为若干条IP地址前缀。

根据用户本地DNS的IP地址,将特定IP范围的用户优先分配到某个通过健康检查的站点。

值得一提的是,由于DNS本身的工作原理所限,GSLBController只能看到用户本地DNS的IP地址,而不是用户终端的IP地址。

当用户使用错误的本地DNS(如教育网用户配置网通的DNS服务器)时,GSLBController返回的DNS应答将不是最佳的站点。

这是基于DNS的GSLB的一个弱点,但由于绝大部分运营商现在限制其他运营商的客户使用自己的DNS,出现这种错误配置的比例非常小。

IP地址权重

可以为DNS应答中的每个IP地址分配权重,权重决定与其他候选IP相比分配到该IP的流量比例。

站点(Site)权重

可以为每个Site分配权重,权重决定与其他候选Site相比分配到该Site的流量比例。

会话能力阈值

通过厂商自由的GSLB协议,GSLBController可以获得每个站点负载均衡设备当前可用会话数和会话表大小的最大值,当前会话数/最大会话数比值超过定义的阈值时,该站点不再被选择。

活动服务器

指一个GSLB节点绑定到一个VIP上的活动真实服务器数量。

可以配置策略优先选择活动服务器最多的IP地址。

往返时间(RTT)

RTT策略是基于区域之外最常用的策略。

有两种模式的RTT测量:

ActiveRTT测量与PassiveRTT测量。

在实际部署中,由于网络限制和性能原因,ActiveRTT往往无法使用,PassiveRTT更实用一些。

8) 

当前可用会话数 

9) 

站点管理优先级(AdminPreference)

为每个站点预设优先级,选择优先级较高的站点。

10)最少选择

选择从前被选择的次数最少的节点。

11)轮询(RoundRobin)

采用轮询方式选择站点。

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 工作范文 > 行政公文

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2