警务大脑应用平台建设方案-虚拟数据中心建设部分

警务大脑应用平台是在充分考虑安全的前提下，利用大数据、云计算、人工智能等应用技术，以“人工智能赋能公安行业”的新型警务模式为目标，围绕整合和应用两大着力点，通过打造多警合一、高度共享的警务应用平台。

警务大脑应用平台建设包括虚拟数据中心建设部分、警务大脑支撑平台建设部分和一系列警务大脑应用系统建设。本文主要对虚拟数据中心建设部分进行描述。

1、辖区数据全域涵盖。 警务大脑项目数据资源需要做到“数据颗粒最小化”、“重点数据定制化”、“条线数据全接入”、“ 社会 面数据全获取”,实现辖区数据全域覆盖。

2、视图数据深度解析。 公安视频监控将从原先单纯的视频“看、管、存、控”向视频侦察实战业务应用跨越，形成一套全方位、多业务、可视化安防实战应用体系。为各警种提供基于视频监控系统的业务应用，实现公安各警种对治安防控、指挥调度、案件侦查、案件管理与警务督察等业务的综合应用服务。

3、异构多源联网共享。 利用公安警务大脑项目，通过联网共享服务，整合所需的全部第三方平台和信息资源，以实战应用为目的进行大数据挖掘、智能分析，并把挖掘、分析的结构化数据，与所整合的视频资源等非结构化数据，通过联网共享服务，为其他公安网提供综合服务。

4、全域资源服务实战。 公安警务大脑和其用户主要是应用所有接入的资源，利用公安警务大脑的智能化功能产生结构化数据，让其他平台用户能够共享相同的原始信息、平台智能分析的成果和彼此所分析得出的案件线索、嫌疑人轨迹等有价值的图文数据，进行公安办案实战应用，实现利用视频图像的指挥调度功能和视频图像侦破案件功能。

5、规范视图运维体系。 对于已接入、新建的设备设施，本项目可实现设备的自动化诊断，并安排人员定期巡查。

6、警务大脑权限管理。 建立面向全区所有公安干警开放的公安警务大脑，能在权限上对公安警务大脑的使用用户进行按责任、权利大小而细分的角色，使得同一用户能够在全网任意地方统一CA认证，统一单点登录，而其所能查看、使用的图综平台内容范围不会变化，都永远是其所获得的授权访问和使用的范围。

7、网络数据安全保障。 公安警务大脑需要在多个层面上与其他网络和系统进行对接，不同的系统可能处在不同的安全级别和访问区域的网络中。网络之间的安全边界建设需要实现完备的防护建设。

虚拟数据主要服务于数据汇聚、数据规整和数据对接。警务大脑虚拟数据中心建设包括以下具体内容：

1、基础矢量数据建设。 基础矢量数据类型至少应包括：桥梁详细数据、消防栓详细数据、地址数据、重点场所数据、小区信息数据、道路信息数据、路网信息数据、店铺信息数据等。

2、高清无人机影像图建设。 高清无人机影像数据拼接、正射纠偏、影像配准处理，基础影像地图服务发布。

3、重点场所区域三维模型建设。 重点场所区域根据无人机拍摄的影像照片，生成三维模型，并对自动生成异常的部位进行手动校正，对不清晰的部位进行清晰化处理，从而生成清晰准确的重点区域三维模型。

4、数据标准规范建设。 制定城市虚拟数据中心标准规范，生成数据录入、存储、对接的标准机制。按照要求，将发布的数据元标准，应用到虚拟中心库整合中，解决部门间信息壁垒及信息不一致、管理数据颗粒度过大的问题，实现标准工作管理信息化、数据资源管理动态化、数据颗粒度最细化以及数据资源服务标准化。开展全局对内、对外标准化信息共享服务，信息（查询）搜索集成，数据质量监控，数据统计分析，以及通过数据挖掘与分析开展警务预测、警务决策支持服务。

5、标准工作管理信息化。 主要包括：建立数据标准规范体系；建立数据标准设计工具；建立数据标准检测工具。

6、数据资源动态化管理。 主要包括实现数据关联和实现数据定制。

7、数据资源服务标准化。 对已汇集的数据资源，要求根据建立的数据元和数据项、代码的关联关系，以数据元为清洗标准，开展清洗转换，形成长度统一、类型一致、命名相对规范的标准资源库，按要素分类存储，并提供标准资源服务，有效提升信息共享数据服务能力。

8、警务数据接入。 包括辖区数据、警员、接处警、案件、监控、卡口、检查站、车辆车牌、人员、地址数据、重点场所和单位、区域和小区数据、巡防数据、道路交通和路网数据的接入与应用。

9、警务数据加工处理。 主要包括：

（1）数据并行计算，编写业务代码，将功能代码打包后通过平台功能页面或开发接口将任务文件发送到计算平台，实现最终的多任务的并行离线计算。

（2）数据实现流处理，对数据服务平台提供的开发接口完成业务中一系列对实时性要求比较高或最近某一段时间内的数据进行计算需求。

（3）交互式查询，通过平台了解所能访问的数据目录权限，并且可以通过数据检索语句直接调用数据仓库的数据，进行应用平台的开发。

（4）数据挖掘，通过平台的功能页面配置所拥有权限下的数据仓库中的数据，并进行一系列的公安行业规则配置实现结构化数据与非结构化数据的深度数据挖掘功能。

10、虚拟数据中心与省市级平台对接。 与上级平台进行数据对接，实现各类信息的汇总应用，便于一键查询所需要的信息，可用于人员轨迹分析、车辆轨迹分析、重点人员监管等。对于各平台新增数据，虚拟中心库可实时监控更新，获取最新资源。

11、服务引擎建设与发布。 主要包括：

（1）地理信息服务引擎。将地理信息资源发布为服务使该资源可供其他用户使用。根据资源类型的不同，资源会被发布成不同类型的服务，各种客户端通过服务实现对GIS资源的访问和管理。

（2）数据服务引擎。数据服务引擎，指的是对数据进行收集、存储、计算、挖掘和管理，并通过深度学习技术和数据建模技术，使数据具有“智能”。在技术架构上，将数据进行标准的API封装，形成标准化的数据API服务。把数据统一进行封装。对外提供标准化的服务目录。在服务目录中体现数据服务的各种业务元数据，以供数据使用者进行掌握动态的数据资源的现状，并且根据数据资源元数据中的定位信息获取实际的数据。

（3）全文搜索引擎。全文检索引擎是按照全文检索理论建立起来的用于提供全文检索服务的软件系统。一般来说，全文检索需要具备建立索引和提供查询的基本功能，此外现代的全文检索系统还需要具有方便的用户接口、面向>

数字化时代，越来越多用户采用私有云架构，自建数据中心。随之而来的便是业务连续性和数据安全挑战。如何搭建一个高可靠、高安全的IT基础架构，确保业务连续不中断，数据安全不丢失？大兆 科技 配置的解决方案如下：

No 1 方案设计

双活数据中心方案，通过分布式架构的天然属性优势，提供高可用及保护的解决方案，为数字化转型保驾护航。

通过若干台超融合一体机构成一个超融合集群，分别放置在用户两个机房中，并提供第三方仲裁存储，实现两地双活。确保任意节点故障，数据仍然安全，业务虚机均可以漂移到其他节点上，以保证服务持续在线。

No 2 方案特点

1、底层分布式架构，冗余物理架构，任意物理节点或者物理设备故障，都不影响服务可用性和数据安全性；

2、统一的X86服务器，管理员只需要维护一套设备即可，可通过统一的地址管理与监控所有物理设备；

3、支持横向扩展，随着业务的增长，可以随时扩容，扩容后，不仅计算与存储能力能得到提升，性能也会得到近似线性增长。

4、性价比高，通过虚拟化和云计算技术，将底层的物理资源灵活组合，面向业务提供服务。底层存储为融合存储架构，无需额外购买存储服务器，绿色节能。

针对以上两个问题，大兆 科技 通过数据迁移与设备纳管理旧方案，使得问题得以完美解决，解决方案分两步：

首先，通过大兆 科技 产品内置的数据迁移引擎，将可以将SAN、NAS和对象的数据迁移到新的分布式存储，享受更全面的数据保护。业务只需要短暂地切换窗口，做到秒级切换，迁移速度支持QoS控制，将对业务影响降到最低。迁移过程意外中断，可以续传，也不会造成数据丢失。整个过程无需第三方软件接入，即可实现数据迁移；

其次，利旧和纳管功能，可通过存储虚拟化技术将传统SAN, NAS以及DAS存储设备中的存储资源整合成一个巨大的，易管理的，d性的存储实体，从而实现给原有存储赋能，实现按需创建虚拟存储池(SAN、NAS、对象存储) 并且提供各类数据服务，包括定义存储容量，性能(IOPS和吞吐量)，可访问性以及高可用性等新的能力，并享受副本或纠删码的数据保护。

No 3 两地三中心

除双活数据中心之外，利用这套架构，并配合我们的机架感知和远程数据复制等功能，我们还可以提供两地三中心的解决方案，充分利用Bigtera产品本身的分布式架构、机架感知以及远程数据备份等功能实现，充分利用资源，避免了一个数据中心常年处于闲置状态而造成浪费

在双活数据中心通过主备机房以及仲裁节点的方式，保证在两个数据中心分别保存一份完整的数据，当其中某个数据中心故障时，业务可以迅速切换到另一个数据中心， 并拥有完整的数据，用户无感知。

No 4 总结

通过大兆 科技 软件定义存储改造后的新一代数据中心，具有以下四大亮点：

硬件资源池化，按需平滑扩容

·软件将硬件资源池化；

·纵向扩容内存、扩容硬盘；

·横向扩容计算存储节点，扩容计算 节点，扩容机箱。更丰富的存储能力；

虚拟化感知的分布式存储

·分布式存储解决I/O性能瓶颈问题；

·SDS最小化占用计算资源，HDD/SSD混合存储，I/O本地化；

·按照策略在本地和其他节点固态磁盘读 写缓存。读取可在多个副本同时进行；

·存储针对虚拟机行为进行策略优化，混 合负载下进行存储优化；

业务高可用，高可靠性

·物理服务器故障时， VM 自动迁移到 健康 物理服务器，确保业务高可用；

·数据副本分布在不同的机柜或不同的节点 上，遇故障时数据自动恢复。并行、快速数据重建，数据本地化，数据平衡，确保高可 靠性；

·机柜级容量负载均衡、资源调度，资源合理 化分配，消除单点故障，加速故障解决；

简化管理，自动化运维

·通过一个超融合管理平台，统一管理 网络、存储、计算等，插件式管理界 面与虚拟化软件深度融合，实现简化 管理；

·一键式自动化运维管理。通过数据辅助管理者进行决策；

一直想整理一下这块内容，既然是漫谈，就想起什么说什么吧。我一直是在互联网行业，就以互联网行业来说。
先大概列一下互联网行业数据仓库、数据平台的用途：

整合公司所有业务数据，建立统一的数据中心；

提供各种报表，有给高层的，有给各个业务的；

为网站运营提供运营上的数据支持，就是通过数据，让运营及时了解网站和产品的运营效果；

为各个业务提供线上或线下的数据支持，成为公司统一的数据交换与提供平台；

分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果；比如广告定向精准投放、用户个性化推荐等；

开发数据产品，直接或间接为公司盈利；

建设开放数据平台，开放公司数据；

。。。。。。

上面列出的内容看上去和传统行业数据仓库用途差不多，并且都要求数据仓库/数据平台有很好的稳定性、可靠性；但在互联网行业，除了数据量大之外，越来越多的业务要求时效性，甚至很多是要求实时的 ，另外，互联网行业的业务变化非常快，不可能像传统行业一样，可以使用自顶向下的方法建立数据仓库，一劳永逸，它要求新的业务很快能融入数据仓库中来，老的下线的业务，能很方便的从现有的数据仓库中下线；
其实，互联网行业的数据仓库就是所谓的敏捷数据仓库，不但要求能快速的响应数据，也要求能快速的响应业务；
建设敏捷数据仓库，除了对架构技术上的要求之外，还有一个很重要的方面，就是数据建模，如果一上来就想着建立一套能兼容所有数据和业务的数据模型，那就又回到传统数据仓库的建设上了，很难满足对业务变化的快速响应。应对这种情况，一般是先将核心的持久化的业务进行深度建模（比如：基于网站日志建立的网站统计分析模型和用户浏览轨迹模型；基于公司核心用户数据建立的用户模型），其它的业务一般都采用维度+宽表的方式来建立数据模型。这块是后话。
整体架构下面的图是我们目前使用的数据平台架构图，其实大多公司应该都差不多：
逻辑上，一般都有数据采集层、数据存储与分析层、数据共享层、数据应用层。可能叫法有所不同，本质上的角色都大同小异。
我们从下往上看：
数据采集数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些简单的清洗。
数据源的种类比较多：

网站日志：

作为互联网行业，网站日志占的份额最大，网站日志存储在多台网站日志服务器上，
一般是在每台网站日志服务器上部署flume agent，实时的收集网站日志并存储到HDFS上；

业务数据库：

业务数据库的种类也是多种多样，有Mysql、Oracle、SqlServer等，这时候，我们迫切的需要一种能从各种数据库中将数据同步到HDFS上的工具，Sqoop是一种，但是Sqoop太过繁重，而且不管数据量大小，都需要启动MapReduce来执行，而且需要Hadoop集群的每台机器都能访问业务数据库；应对此场景，淘宝开源的DataX，是一个很好的解决方案（可参考文章 《异构数据源海量数据交换工具-Taobao DataX 下载和使用》），有资源的话，可以基于DataX之上做二次开发，就能非常好的解决，我们目前使用的DataHub也是。
当然，Flume通过配置与开发，也可以实时的从数据库中同步数据到HDFS。

来自于Ftp/>
有可能一些合作伙伴提供的数据，需要通过Ftp/也可以满足该需求；

其他数据源：

比如一些手工录入的数据，只需要提供一个接口或小程序，即可完成；
数据存储与分析毋庸置疑，HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。
离线数据分析与计算，也就是对实时性要求不高的部分，在我看来，Hive还是首当其冲的选择，丰富的数据类型、内置函数；压缩比非常高的ORC文件存储格式；非常方便的SQL支持，使得Hive在基于结构化数据上的统计分析远远比MapReduce要高效的多，一句SQL可以完成的需求，开发MR可能需要上百行代码；
当然，使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很乐意开发Java，或者对SQL不熟，那么也可以使用MapReduce来做分析与计算；Spark是这两年非常火的，经过实践，它的性能的确比MapReduce要好很多，而且和Hive、Yarn结合的越来越好，因此，必须支持使用Spark和SparkSQL来做分析和计算。因为已经有Hadoop Yarn，使用Spark其实是非常容易的，不用单独部署Spark集群，关于Spark On Yarn的相关文章，可参考：《Spark On Yarn系列文章》
实时计算部分，后面单独说。
数据共享这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库；
前面使用Hive、MR、Spark、SparkSQL分析和计算的结果，还是在HDFS上，但大多业务和应用不可能直接从HDFS上获取数据，那么就需要一个数据共享的地方，使得各业务和产品能方便的获取数据； 和数据采集层到HDFS刚好相反，这里需要一个从HDFS将数据同步至其他目标数据源的工具，同样，DataX也可以满足。
另外，一些实时计算的结果数据可能由实时计算模块直接写入数据共享。
数据应用

业务产品

业务产品所使用的数据，已经存在于数据共享层，他们直接从数据共享层访问即可；

报表

同业务产品，报表所使用的数据，一般也是已经统计汇总好的，存放于数据共享层；

即席查询

即席查询的用户有很多，有可能是数据开发人员、网站和产品运营人员、数据分析人员、甚至是部门老大，他们都有即席查询数据的需求；
这种即席查询通常是现有的报表和数据共享层的数据并不能满足他们的需求，需要从数据存储层直接查询。
即席查询一般是通过SQL完成，最大的难度在于响应速度上，使用Hive有点慢，目前我的解决方案是SparkSQL，它的响应速度较Hive快很多，而且能很好的与Hive兼容。
当然，你也可以使用Impala，如果不在乎平台中再多一个框架的话。

OLAP

目前，很多的OLAP工具不能很好的支持从HDFS上直接获取数据，都是通过将需要的数据同步到关系型数据库中做OLAP，但如果数据量巨大的话，关系型数据库显然不行；
这时候，需要做相应的开发，从HDFS或者HBase中获取数据，完成OLAP的功能；
比如：根据用户在界面上选择的不定的维度和指标，通过开发接口，从HBase中获取数据来展示。

其它数据接口

这种接口有通用的，有定制的。比如：一个从Redis中获取用户属性的接口是通用的，所有的业务都可以调用这个接口来获取用户属性。
实时计算现在业务对数据仓库实时性的需求越来越多，比如：实时的了解网站的整体流量；实时的获取一个广告的曝光和点击；在海量数据下，依靠传统数据库和传统实现方法基本完成不了，需要的是一种分布式的、高吞吐量的、延时低的、高可靠的实时计算框架；Storm在这块是比较成熟了，但我选择Spark Streaming，原因很简单，不想多引入一个框架到平台中，另外，Spark Streaming比Storm延时性高那么一点点，那对于我们的需要可以忽略。
 我们目前使用Spark Streaming实现了实时的网站流量统计、实时的广告效果统计两块功能。
做法也很简单，由Flume在前端日志服务器上收集网站日志和广告日志，实时的发送给Spark Streaming，由Spark Streaming完成统计，将数据存储至Redis，业务通过访问Redis实时获取。
任务调度与监控在数据仓库/数据平台中，有各种各样非常多的程序和任务，比如：数据采集任务、数据同步任务、数据分析任务等；
这些任务除了定时调度，还存在非常复杂的任务依赖关系，比如：数据分析任务必须等相应的数据采集任务完成后才能开始；数据同步任务需要等数据分析任务完成后才能开始； 这就需要一个非常完善的任务调度与监控系统，它作为数据仓库/数据平台的中枢，负责调度和监控所有任务的分配与运行。
前面有写过文章，《大数据平台中的任务调度与监控》,这里不再累赘。
总结在我看来架构并不是技术越多越新越好，而是在可以满足需求的情况下，越简单越稳定越好。目前在我们的数据平台中，开发更多的是关注业务，而不是技术，他们把业务和需求搞清楚了，基本上只需要做简单的SQL开发，然后配置到调度系统就可以了，如果任务异常，会收到告警。这样，可以使更多的资源专注于业务之上。

高校信息化建设已经进入了高速发展时期,在基本完成了数字校园的基础设施建设之后,信息集成和业务集成成为高校信息化的重要任务。目前,有越来越多的高校认识到了数据集中、IT基础设施集中、运行服务集中的必要性,同时,数据中心是数字校园的核心这一理念也得到了大部分高校的认同。校园数据中心建设正逐渐成为目前高校信息化领域的一大热点。

在校园网的管理方面,安全管理问题常常是高校数据中心管理者最头疼的事。某大学的校园网每天的平均访问量是6000多次,而被攻击的次数比访问量还多。记者在采访中了解到,这些攻击有些来自校园外部。但令人感到意外的是,其中一部分攻击却是来自校园内部,尤其在许多工科大学中,都设置有计算机、网络甚至信息安全学科,这些专业的本科生、研究生和博士生中的一些人把校园网当做试验平台,不断进行攻击。当然来自校园内部的攻击中,也有一部分是无意识的。
对于校园网的安全问题,各高校都采取了相应的措施,以保证校园网的安全正常运行。北京交通大学信息中心主任贾卓生介绍说:“以前我们的安全措施基本上是在网络出口进行安全防护,如防火墙、入侵检测、防病毒。现在我们在数据中心前也会加一些防范,防止校内学生的攻击。”贾卓生说,他们还通过对核心交换机插防火墙板子,使每栋楼都有防火墙。同时,他们正逐渐把各部门的服务器集中到数据中心,通过集中管理,增加各种防范措施。对于一些不能集中管理的系统,包括试验系统、研究系统,则采取分别增加安全防范设备的方法,进行安全防范。“对于整个学校信息化的安全,我们通过等级保护,根据不同的安全级别来确定具体的安全防护办法。”贾卓生说,目前,北京交通大学在网络中心下成立了安全室,利用软件侦测漏洞,并及时修补,防患于未然。
南开大学信息中心主任张四海认为,目前校园网中遇到的安全问题通过技术手段和安全设备都可以防范。当然,这种防范不可能是100%的。而具体采取什么样的措施和设备,这涉及到投入产出比问题。也就是说,系统的可靠性和可用性要达到几个“9”,投入的资金不同,所达到的目标也不同。

“守”住安全

在高校数据中心里,除了网络安全外,机房环境安全和数据安全对于整个数据中心的正常运行也是至关重要的方面。南开大学信息中心主任张四海介绍说,南开大学采取的安全措施是划分区域、划分模块。对于用户,他们通过引导、提供杀毒软件、提出安全防范方法和规则,使用户自己可以在用户端做到防范;同时,通过技术手段和安全设备,在数据中心端做到严格的管控。而对于数据安全,张四海介绍说,他们正在逐步建立数据灾备机制,包括异地灾备。“随着业务系统越来越多,大家对数据的安全性、敏感性会越来越高。”
他认为,随着技术的发展,在不同时期,大家对安全的关注点不太一样。例如在3年前,大家关注的可能是三层、四层防火墙,而现在,它们已经起不到任何作用了,大家更关注的是应用防火墙。根据他们的检测,安全漏洞和攻击有80%到90%都在应用层,普通的防火墙能做到一些隔离,但是要真正起到安全防范作用的话,还需要应用防火墙。今年上半年,南开大学对所有二级网站都进行了摸底,并设立了安全实验室和专门的设备,计划建立定期扫描监测制度,以便及时发现问题和改进。
在校园网的建设和管理中,安全问题永远伴随其中,正所谓“道高一尺,魔高一丈”。因此,太原理工大学信息化管理与建设中心主任王宝俊认为,安全问题就像校园网的建设,永远是一个“过程”,没有一劳永逸的办法。除了一些必要的防范措施外,安全问题常常是“攻”在前,“守”在后,而处于被动的状态下,因此它甚至比校园网建设的困难更多。王宝俊介绍说,学校刚刚启用了新建的机房,目前大部分应用服务器已经集中管理了。设备多了,安全设备也多了,而他现在最担心的,一是这些安全设备未必安全,二是在出现问题时,如何排查问题。
在采访中,记者了解到,H3C公司为高校校园网和数据中心建设提供了全面的解决方案,从设备虚拟化、通道虚拟化、管控虚拟化、存储虚拟化四大维度提供端到端的校园信息集成服务。而其中管控虚拟化技术正是为了解决学校面临的业务集中后的L2-L7层安全隐患,H3C公司公共事业部副总监徐继恒介绍说,H3C校园数据中心解决方案已经应用于300多所高校数据中心和图书馆,目前已成为教育行业主机连接数最多的国内厂商。

亟需整合

目前,高校信息化应用已经开始从系统集成逐渐走向信息集成。不过,集成并不是一件简单的事,也不是单靠技术就能实现的事,而是涉及到学校的体制、机制、各方责任和利益的复杂的系统工程,同时也不是一朝一夕就能完成的事。太原理工大学信息化管理与建设中心主任王宝俊认为,高校信息化建设水平与学校的教学和科研水平也密切相关。
王宝俊介绍说,太原理工大学原来负责信息化建设的是网络中心,现在,网络中心整合了其他几个机构,更名为信息化管理与建设中心,被赋予了管理的责任和机制。以前,网络中心负责建立校园网,建成了,任务也就完成了。现在,信息化管理与建设中心更多参与到学校信息化规划、“十二五”规划、山西省教育十年纲要等制定工作中,提供技术指标,参与政策制定。
王宝俊认为,数据库的集成是高校信息化建设中最基础的问题,也是最重要和最核心的问题。在学校中,有各类数据库,包括教务系统、财务系统、人事系统等,如果不集成起来,形成统一的数据库,那么对于最简单的统计学生和教职员工人数这样的问题,各部门上报的数字都会不一样,因为统计的方法不一样,更新时间不一样。他认为,要突破各个部门的壁垒和应用,需要更改一些习惯,更改一些工作流程,甚至是更改利益分配。这些都不是简单的事,而是一个渐进的过程,它代表了学校信息化的水平。
南开大学信息中心主任张四海从信息发布的角度认为信息集成是非常必要的。他说,学校不同业务部门中的业务系统有大量的信息发布,每个系统的模式、流程都不同,这使得信息的受众非常苦恼,迫切需要将信息归类,统一业务流程、统一发布过程。
H3C公司公共事业部副总监徐继恒认为,信息集成的实施有待观念的转变,这不单是提升了信息的服务水平,更重要的是提升了学校的竞争力。他说,通过帮助高校构建校园网和数据中心的实践,徐继恒认为,从校园数据中心建设来看,校园应用系统数据集中密度越来越高,服务器存储数量不断增长,网络架构不断扩展,空间布局、系统布线、电力能耗压力不断增加,校园数据中心建设面临诸多挑战,系统性能、安全性、可靠性、扩展性、管理性等都面临极大挑战,迫切需要进行整合与优化。

链接
高校信息化发展进入第二阶段

高校教育信息化已经进行了多年,北京交通大学信息中心主任贾卓生认为,高校目前正处在信息化发展三阶段的第二阶段。
他认为,信息化发展的第一阶段是网络提供,通过网络向学生和教师提供不同的应用,这个阶段现在已经基本完成。第二个阶段是网络服务,通过网络向教师和学生提供各种服务,高校现在正处在这个阶段。而下一个阶段就是网络生活。
网络生活最终实现的是让教育信息化真正应该受益的主体――学生,能够通过网络提供的便利,提高学习效率和学习质量,而不是仅仅觉得方便而已。贾卓生认为,目前的教育信息化更多的是为教师提供方便,而没有真正调动起学生的积极性,这是一个误区。教育信息化最终要提高整体效率,而不仅仅是便利性。

EMC从信息生命周期（ILM ）的角度来整合并管理数据，提出了一套完整的节能服务策略和实施方法，在全球众多相关项目中广为使用并得到验证，协助客户达到节能降耗效果。 某大型数据中心（以下简称客户）向 EMC公司提出改善现有IT能效问题的需求，希望能达到下一代的数据中心的节能降耗目标。EMC公司通过仔细了解用户需求，帮助客户制定了存储节能策略，提出调整存储基础架构的建议。
实际上，EMC在节能服务方面有着一套完整的策略和实施方法，它是多年来 EMC通过对实施 ILM（信息生命周期管理）服务，以及专注于发展信息基础架构所积累的经验进行提炼开发而成的。该实施方法在全球众多相关项目中广为使用并得到验证。这一方法包括评估（Assess）、规划（Plan）、设计（Design）和建立（Build）四个阶段的咨询和技术服务。

评估: 解决问题前先了解问题

1了解数据增长及容量需求
现有数据的多寡以及磁盘容量的持续需求是直接影响能耗的关键因素。EMC File System Assessment （FSA）服务正是一项能够解决上述问题的专业服务方案，通过 FSA 客户可以清楚了解现有数据的容量、使用率、增长率、静态数据量、重复数据量等重要信息。
2 测量现在及预估未来能耗
测量能耗现状是评估过程中的一个基本工作。因为规划中的未来能耗节省能否有显著的投资回报率（ROI），这个基本值是关键的衡量数据。当然，为求更精确的测量还必须考虑下列影响因素: 冗余电力需求、用电量安全系数、设备规格、工作负荷、工作循环周期以及蓄电池充电的状态等; 另外，对能耗设备的淘汰升级也很重要。
3 能耗与摩尔定律
摩尔定律认为，计算机的性能大约每18个月会提升一倍。换言之，更高的性能代表更热的组件、更高密度的封装与单位面积的更多耗电需求。如今，IT很容易陷入更多应用系统、数据、服务器、存储以及更多能耗的“恶性循环”当中。因此，在制定新一代机房的节能策略上，应当考虑这个重要因素，才能在符合低能耗的同时，保持稳定的营运服务水平。
4 掌握各类磁盘用电需求
虽然低能耗往往意味着低性能，但根据 EMC 的经验，IT的信息中平均有高达70% 的数据属于静态数据，这些数据正是使用低能耗磁盘的理想对象。EMC 在设计新一代存储设备时充分了解这一点，全系列高、中、低存储设备均支持从最高性能的73GB、15Krpm到最节能的750GB、72Krpm的各类磁盘。

规划: 提出能效策略及建议

方向1 : 服务器虚拟化

即通过服务器整合的方法达到能效优化的目标。EMC的VMware可将服务器虚拟化整合比达到10:1，有些时候甚至可以达到 20:1。经由大量的服务器虚拟化，EMC可将每一台实体服务器的使用率提升到80%，这不但提高了资产使用率，也大幅改善了能效问题。
方向2: 存储分级 与优化（Optimize）
按服务水平协议（SLA）分级存储是IT降低总体营运成本的主要手段之一，其附带的好处是通过节能降耗达到能效优化的目标。通用方法是采购较少的但容量较大的存储设备，将现有工作负荷予以整合与优化，进而提高存储资产的利用率。这部分的关键在于存储设备是否支持各类磁盘，是否可以满足各种 SLA 的存储需要。
方向3: 发挥存储软件的功能
用更少的数据量达到相同的功能如今也是提升能效的有效方法。例如，利用自动精简配置（Thin Provisioning）技术延缓磁盘的采购时程、在满足SLA的条件下利用递增快照（Incremental Snap）取代完整复制（Full Clone）、利用Virtual LUN技术在线迁移数据至低能耗卷。其中很多都是EMC独有的技术，可以在能效优化领域助客户一臂之力。
方向4:改进备份与归档能力
如何改进备份的效率进而改善能效问题也是一个不容忽视的问题。客户可通过EMC精准的FSA服务，充分了解 IT 数据的存取特征并进行存储规划，从而在每日的备份作业上以最小的备份量完成备份作业。因此，客户可以得到两个能耗优化点，即以归档达到分级存储及精简备份资源的节能降耗目标。
方向5: 删除重复性数据
如果可以将备份的数据直接做全域性重复数据删除，将可以大幅缩减备份资源，这是一项革命性的数据保护方法，彻底颠覆以往传统IT的备份思维。EMC的 AVAMAR 产品正是这一领域的佼佼者，平均数据的缩减率可以达到令人难以想像的300∶1，这一前所未有的方法是大幅提升能效的利器之一。
最后，EMC 的专业服务可以综合上述方法制定能效优化策略，并以 EMC 独有的能耗计算器 EMC Power Calculator精准预估各种节能方式的投资回报率（ROI），从而建议客户应当采用哪种策略，这是EMC的专业能力。
设计与实施: 落实能效优化策略
第三步是设计，即在与客户达成策略共识后，EMC 能够确定相应的能效改进方式，在设计阶段将在此基础上针对细节部分进行设计工作。涉及范围如主机虚拟化调整设计、存储基础架构调整设计、应用软件调整设计、组态调整设计、机房调整设计、项目日程规划等设计。
最后一步是建立（Build），即按设计细节实施，实现能效优化的目标。
总体说来，由于制定节能服务方案是一个涉及范围极广的课题，如何组合出最佳能效策略是一门艺术。EMC结合长期以来在信息领域的实践以及在此领域颇具深度和广度的专业经验，它以一系列扎实可行的方法，从 ILM 角度整合和管理数据，进而协助客户达到节能降耗效果。
以本文案例来说，该客户采用 EMC 专业的节能服务方案后得到以下明显效益：
1 原有26个数据中心，整合为1个数据中心;
2 原有436台服务器，虚拟化整合为105台服务器;
3 原有约5800平方米占地面积，整合后只需3600平方米;
4 原有电力及空调费用年支出为1180万美元，节能改进后只需年支出730万美元;
5 能效优化效果每年约达到450万美元;
6 额外效益，包括以标准化技术改善原有作业效率、构建以信息为中心的基础架构、改善原有业务支持的d性和服务水平等。
专家点评
正如本方案所提到的，绿色存储的实现是一系列技术、方案、策略的组合，绝不仅仅是一项或多项技术的简单部署。实际上，“绿色”管理与信息安全管理一样，应该是IT管理的一个主题。本方案对绿色存储方案的规划、部署和评估给出了一个较为完整的实施框架，给出了“绿色”管理的一个实现轮廓，对用户全面实施“绿色”管理（而不仅仅是“绿色存储”管理），具有实际指导意义。从整体上看，EMC的绿色方案非常系统和全面，从评估、规划、设计到建设都做了描述，尤其值得称道的是方案的前半部分，评估和规划部分都很精彩。EMC所推荐的技术都有助于降低能耗，尤其是“删除重复数据”这项技术对于能耗降低的贡献非常大。尽管其中提到的很多技术是从EMC公司自有产品出发的，但用户仍旧可以得到很多具体的参考和启示。当然如果能把这些技术综合地集成在数据中心的建设中，在实现绿色存储这个目标上就会事半功倍。EMC所推荐的评估角度都非常有助于用户充分了解自身在存储上的能量损耗，从中认识到绿色存储的重要性，并为下一步的规划和设计提供了坚实的基础。由于评估是“绿色”管理中很重要的一环，由此可见在这方面的探索和实践方面，EMC已经做了大量工作。
本方案中提到的方法论和技术，很多都是比较“底层”的，需要用户在构建数据中心或在大规模部署新应用时，进行充分的考虑。但对用户现有的数据中心来说，要从头实现，动作也太大了些。另外，本方案后半部分有点虎头蛇尾，设计和建设的讲解与说明远远少于评估和规划。

数据中心建设必须考虑数据信息：　

1、数据中心建设必须要考察四点

一是数据的可用性和时效性；二是数据中心规模；三是机柜的功率密度(KW/机柜)；四是气象条件、网络以及水、电资源。任何数据中心系统设计方案的选择，都必须建立在对这些内容的考察之上。

2、不同行业对数据中心建设提出的设计要求大相径庭

如金融行业和军用系统，一切问题都要让位于可用性和时效性;而在BAT或者电信机房，其对节能和投资成本的关注度则要高出很多;在超算系统，则对机柜的高功率密度和机房运行的经济性更为关注。诸如此类，未来数据中心的设计与规划应满足多元化的技术需求，并非单一模式，为设计者提出了明确的方向性要求。

3、基于这一需求，未来数据中心的建设可从四个维度进行设计规划，这就包括了：可靠性、节能性、经济性、以及可维护性等。他认为，其中节能与绿色环保的概念不能混淆，从其观察到的实际案例中已发现，部分地区的数据中心建设，在节能与绿色环保间已出现了“不调和”的矛盾，例如：在部分缺水的西北地区对水资源的利用等问题。

4、评估数据中心可利用率的关键指标

包括了是否存在因供电系统停电/闪断而诱发的故障隐患、是否存在因空调系统”失效”而诱发的故障隐患、是否存在因电池组“检测失效”而诱发的故障隐患、是否存在因输出短路而诱发“输入主开关误跳闸”的故障隐患、是否存在因防雷“设计欠妥”而诱发“输入主开关误跳闸”的故障隐患、是否存在因输入电网“停电”或供电系统的主ATS开关执行切换 *** 作而诱发的IGBT整流型UPS“损坏”的故障隐患、是否存在因发电机带电容性负载和阶跃性负载而诱发的故障隐患、是否存在因“地环流偏大”、“零地电压偏高”、“腐蚀性气体”所而诱发的IT设备损坏或寿命缩短的故障隐患等。

---