关于云存储使用情况的探讨和分析
版本历史
版本说明/变更理由/变更版本号修改日期修改人审批日期审批人
内容
V1.0. 2013-4-1 赵强首发
变更说明：C：Create，初始创建；A：Add，增加内容；M：Mod，修改；D：Del，删除
一、Hadoop的介绍及优缺点分析： (3)
1、读写性能和数据安全 (3)
2、易于扩展的集群架构 (3)
3、有效分散集群压力 (4)
4、高效的大数据分析 (4)
二、目前使用情况及反馈 (5)
1、目前线上Hadoop使用情况 (5)
2、针对目前线上环境的分析 (5)
3、关于Hadoop集群服务器的选用 (7)
4、关于nineCloud (8)
5、HBase (8)
6、监控 (10)
三、HBase和Oracle (10)
四、HDFS作为分布式存储的使用可能性分析 (13)
五、成功案例分析 (14)
六、发展方向 (15)
1、SaaS方向 (15)
2、数据挖掘方向 (17)
一、Hadoop的介绍及优缺点分析：
Hadoop一个分布式系统基础架构，由Apache基金会开发。用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力高速运算和存储。Hadoop实现了一个分布式文件系统 File System），简称HDFS。Hadoop拥有功能丰富的子项目，其中包括HBase、Hive、ZooKeeper等功能各异的子项目，灵活的使用这些项目可以轻松的做到云计算平台的构建。
1、读写性能和数据安全
Hadoop都是基于HDFS文件系统，HDFS可以有效的提高系统的吞吐量，减少系统等待时间。HDFS是以磁盘为存储单位的，比如有三台服务器，每个服务器有三块硬盘，对于HDFS 等于有九个写入单元，而传统的基于服务器的分布式存储等于只有三个写入单元。而且HDFS 通过数据块进行备份的数据冗余机制，磁盘底层不需要而且不建议组建RAID，所以在可使用的磁盘空间上得到了更进一步的提升，而读写性能跟组建注重读写的RAID 0后的效果相同。HDFS对于磁盘读写速度的提升和对数据安全性的提升如下：
磁盘读写速度（RAID0=HDFS>RAID[1+0]>RAID5>RAID1）
磁盘数据安全（RAID1=HDFS>RAID[1+0]>RAID5>RAID0）
由此可见，HDFS可以达到RAID1的数据冗余和RAID0的高速读写。在最新版本（测试版本或者第三方的商业版本）的Hadoop中，Hadoop提出了一个新的Name NodeHA功能，利用该功能可以有效地规避老版本的Name Node节点单点问题。
2、易于扩展的集群架构
而且Hadoop中的Data Node方便扩展，可以在不停止服务的状态下动态的添加新的Data Node节点进入集群，而且加入后也不需要重启整个集群，只需要正常配置Data Node节点并启动该节点，Name Node可以自动将该节点加入集群。为了方便集群启动时可以正常启动新加入的Data Node需要对Name Node服务器上的hosts文件及slaves文件进行修改。
3、有效分散集群压力
Hadoop采用动态存储资源分配，可以将数据更平衡的分布于不同的Data Node节点，防止出现数据不平衡而造成部分Data Node节点请求过多，而其它Data Node节点没有请求的情况。就算有新的Data Node节点加入集群，Hadoop也可以通过一条命令简单的做到数据的重新平衡。当然这个操作最好在使用量低的夜间进行。Hadoop的数据的交换是不经过Name Node节点的，Name Node上保存的文件是直接从Data Node上收集而来，所以当用户使用Hadoop集群上的数据时，是直接从Data Node获取数据，这样做使得Name Node的压力得到缓解。而且最新版的Hadoop还支持在一个Hadoop集群中分别创建多个Name Node 节点，每个Name Node节点分别管理整个HDFS空间的一部分。使HDFS中的数据做到有效的隔离，并且当一个Name Node节点出现问题，不至于影响到整个集群中数据的访问。
4、高效的大数据分析
HBase作为Hadoop的一个子项目，主要用于数据的存储。HBase适合于非结构化数据存储的数据库。与常用的数据库不同的是HBase基于列的而不是基于行的模式。由于HDFS的特点，所以HBase非常适合大数据量的数据分析。系统架构上和Hadoop相类似同样在进行架构的扩展上十分的方便，当出现存储空间不足的情况时，只需要添加进去新的Data Node 节点就可以了。
由于HBase是基于列的数据库，所以配合Hive可以发挥BI数据库的功能以达到数据分析的作用。加上HDFS分布式存储的底层支持，使得其在进行数据分析、数据挖掘上有一定的优势。但是Hive虽然提供了高级SQL的支持，但是对于专业的BI数据库上还略有不足针对BI/BO工程师不是十分友善。
HBase于ZooKeeper等项目的组合应用，可以保证HBase的HMaster节点没有单点的问题出现。而HBase和Pig及Hive等项目一同使用时还能得到对高层SQL语言的支持。
二、目前使用情况及反馈
1、目前线上Hadoop使用情况
HDFS总空间：10.74TB
已经使用空间：251.07GB
Name Node负载：平均小于0.1
Data Node负载：平均在0.1左右
通过iostat命令查看三台Data Node数据节点信息，内容如下：
CPU的使用情况：
avg-cpu: %user %nice %sys %iowait %idle
0.55 0.00 0.43 1.03 97.99
硬盘的使用情况：
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sdb 5.85 120.85 90.12 779560090 581333808
CPU的使用情况：
avg-cpu: %user %nice %sys %iowait %idle
0.34 0.00 0.30 0.36 99.00
硬盘的使用情况：
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sdb 5.53 41.10 84.69 265108546 546324728
CPU的使用情况：
avg-cpu: %user %nice %sys %iowait %idle
0.62 0.00 0.60 0.74 98.04
硬盘的使用情况：
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sdb 6.55 224.87 115.69 1450531354 746285984 2、针对目前线上环境的分析
通过上面这些数值可以看出，目前Hadoop云平台的整体压力较小，Data Node数据节点的写操作相对比较平衡，读操作则slave3的读取数据远远大于其它两台设备。
目前线上系统架构存在着一定的不合理性：
Hadoop集群的服务器上尽可能的不部署其它应用，因为无论Name Node，还是Data Node 其中Name Node负责镜像元数据的保存，随着业务量的增加这个文件的大小会越来越大，而
且这个文件是全部加载进内存中的；而Data Node 本身就是以进行计算和硬盘IO 操作为主，而当有其它程序运行是势必会造成磁盘IO 和CPU 资源的抢占，降低效率，这样的结果会进一步的降低Hadoop 集群的响应时间。
Hadoop 集群的逻辑架构为： H A
LD
Namenode
Datanode 集群
Ninecloud 负载均衡
LVS
Hadoop 云计算平台
而物理架构上，Data Node1和Data Node2兼做LD 和LD （B ）服务器的作用，Name Node 服务器同时还是CAS 统一认证的服务端，Data Node3为CAS 统一认证的服务端的备份。 Namenode Ninecloud
Ninecloud
Hadoop 云计算平台
Datanode Datanode
Datanode
LVS LD
用户访问云平台的流程图：
用户 SISS平台（支持中心） LVS NineCloud Hadoop云计算平台
|------------→ | Name Node Data Node
| |-------→|
| |-------→|
| |-----------→|
|←---------------------------------------------------|
|---------------------------------------------------------------→| |←------------------------------------------------------------- -- | 综上所述，由于目前集群的压力并不大，所以这些共用服务器的缺点还没有暴露出来。随着业务量的增加，服务器节点的访问量提高，每提升一倍的访问量，Name Node服务器和Data Node服务器的访问量将提高三倍甚至四倍。
并且通过用户访问云平台的流程可以看出一个用户的一次请求在现在的架构上，由于Name Node和SISS平台登录使用的是同一台服务器，所以该服务器会建立4个连接，其中两个是链接到NineCloud，另外两个连接是连接到用户的，而正常的情况下只会建立2个连接。由于目前访问量的压力不大，所以这种架构下还没有出现问题，但是随着业务的专业和访问量的进一步增大，这个节点的问题将逐渐的凸显出来。解决这个问题的方法相对比较简单，这里最好能够做到“专机专用”。由于这两个应用都会逐渐变成访问量较大，压力较重的服务器，所以和其它应用共享一台服务器可能会出现问题，所以建议这两个应用分别在两台不同的应用上运行。而LVS和Data Node应用也同样存在着上面说到的问题。
而且现在线上的云平台没有做安全方面的配置，加上Hadoop自身的安全控制非常简单，只包含简单的权限，即只根据客户端用户名，决定使用权限。它的设计原则是：“避免好人做错事，但不阻止坏人做坏事”。
如果你知道某台Name Node的IP和端口，则可以很轻松获取HDFS目录结构，并通过修改本机机器用户名伪装成HDFS文件所属owner，对该文件进行删除操作。这一点尤其是在以后进一步进行异地机房备份时要注意，入侵者可以利用上面的安全问题伪装IP地址入侵到系统，对系统的安全性将产生很大的影响。
这里在以后的工作中可以通过配置kerberos，可以实现身份验证。但很多管理员使用更简单有效的办法——通过防火墙对访问IP进行控制或者异地机房通过路由器组建通讯隧道（路由间VPN）。
3、关于Hadoop集群服务器的选用
Hadoop集群主要分成两部分，既Name Node节点和Data Node节点。其中Name Node 节点主要管理元数据的保存，而Data Node节点则是保存用户上传的数据。Hadoop不同的节点对于内存的需求量有着很大的差别，（修改内存占用可以通过文件bin/hadoop-evn.sh）主流节点内存配置为32GB，典型场景内存设置如下：
Name Node 15-25 GB
Job Tracker 2-4GB
Data Node 1-4 GB
Task Tracker 1-2 GB
Child VM 1-2 GB
集群的使用场景不同相关设置也有不同，如果集群有大量小文件，则要求NN内存至少要20GB，DN内存至少2GB。
根据以上可以看出，我们可以在服务器的选用上分成两部分：
第一部分对内存的大小要求比较高，主要用来计算和分配的Name Node。
第二部分对硬盘的IO和空间要求比较高，主要用来读写存储数据的Data Node节点。这部分甚至可以配一台配置较好的服务器之后利用虚拟化技术虚拟成多台服务器之后分别挂载硬盘的方式来节约成本。而大部分计算工作都是交给Data Node来完成的，所以Data Node服务器对于CPU配置要相对略高一些。
4、关于nineCloud
nineCloud是自行开发的java程序连接HBase的接口程序，java程序通过调用HBase 提供的API将数据保存到HBase中，目前是有两台服务器互为负载均衡。这两台服务器的压力相对较低，在考虑到该程序的访问量压力的前提下可以进行在该服务器上部署其它应用。由于HBase是线性工作模式，即完成一个任务才会进行下一个任务，只是在计算时使用的是并发计算。所以同时交付给HBase过多的任务并不会缩短任务的完成时间。
这里可以考虑HBase和nineCloud应用之间采用通道连接（即nineCloud和HBase建立永久性连接，用户的请求直接从该链接内发送给HBase，不在单独建立连接。可采用先到先出的内存管理模式。）的模式进行，用来降低创建连接的时间间隔，又可以有效地保证HBase 和nineCloud的连接。同时还方便维护人员进行监控，即只要保证连接存在即可保证两个应用之间的是保持通讯的，如断开则表明一侧的应用出现了问题。
5、HBase
HBase是Apache基金会Hadoop开源项目中的基于Google提出的BigTable所产生的列数据库，HBase拥有Hadoop的方便部署，架构扩展容易，可以利用低配置的机器组建大规模的集群等优势，同时由于Regionserver的机制使得HBase在大数据量的操作上会更有优势。HBase在读写上效率并不是很高一定意义上由于延时会造成系统运行相对较慢。虽然HBase属于noSQL的列数据库，但是HBase并不是针对数据的高速读取的内存数据库，而是偏向海量存储下的运算效率而非Key-Value存储的效率。
从以上的描述可以看出，HBase作为线上库对于系统的要求相对苛刻：
1、由于HBase是noSQL数据库，所以不支持事务；
2、存储效率上与一般的noSQL对比没有优势；
3、系统对于响应时间没有过分的要求。
而从目前线上应用来看，是存在着直接从HBase读取数据的情况存在，当访问量放大后，这种直接从HBase进行搜索的操作势必会对整个系统造成一定的拖累。所以对于线上系统要进行一定的改进用来创造要符合HBase的应用场景（与Oracle对比），比如数据量大、对线性拓展有需求、对自动化运维（负载均衡）有要求而且应用模式简单。这里前面几个应用场景是使用HBase的适合环境，但是应用模式简单是使用HBase的必须要求，如上所述，HBase 是不支持事务，且存储速度一般。在复杂的应用模式下使用HBase将会非常的麻烦，甚至HBase根本就无法满足要求。
如果需要完成负载的操作那么就需要增加Pig和Hive功能，Hive和Pig都是基于Hadoop 的大规模数据分析平台：
Pig简单说是一种编程语言，它简化了Hadoop常见的工作任务。开发人员可以通过Pig 直接加载数据，表达转换数据以及存储最总结果。Pig内置的操作使得半结构化数据变得有意义（如日志文件）。同时Pig课扩展使用Java中添加的自定义数据类型并支持数据转换。
Hive在Hadoop中扮演数据仓库的角色。Hive添加数据的结构在HDFS（hive superimposes structure on data inHDFS），并允许使用类似于SQL语法进行数据查询。与Pig一样，Hive的核心功能是可以扩展的。
通过上面的介绍可以看出，Hive更适合数据仓库的任务，可以用于静态的结构以及需要经常分析的工作。而且Hive对于SQL的支持是其可以直接与其他BI工具相结合。而Pig 则给开发人员提供了相当大的自由度，比直接只用Hadoop Java APIs相比大幅度的削减了代码量。
结合Hive和Pig可以是线上的Hadoop云平台在功能上得到进一步的完善，但是对于HBase在存储和读取数据的实时性上仍需要进行一些改善，可以考虑的改善方案：
1、在HBase前加传统的Key-Value内存数据库，增加数据的读取速度：
在这种方案中，应用程序直接与内存数据库进行数据的交互，之后再通过程序将已经写入内存数据库的数据保存到HBase中，这里HBase的作用更多的是数据收集和固化存储。完成以上操作后可以再利用Hive、Pig的Hadoop项目中的子项目对固话的数据进行分析和加工。再将处理后的数据以缓存的方式通过固定模式加载到内存数据库中，
并释放内存数据库中重复的数据；
2、HBase和Oracle、MySQL或者MSSQL协同使用：
基本原理和方案一类似，不过Oracle、MySQL或者MSSQL等数据库都是关系型数据库是是支持事务的，将处理完成的数据加载到这些数据库中，可以让应用进行相对负载的数据库查询操作。但是鉴于都是磁盘存储的方式，需要定期对数据进行精简。比如：实时搜索只能通过关系型数据库搜索到当前一个月的数据，如果想要查看一个月前的数据则直接加载从HBase、Hive或者Pig处理完后缓存出的镜像列表。
6、监控
线上系统的监控由Hadoop及HBase提供的页面管理工具和Ganglia集群监控工具组成，虽然两个工具可以保证在Hadoop及HBase出现故障时直接的反映出来，但是对于故障的预估和后续的解决故障上却没有什么帮助。
在后续的工作中，需要继续完善Hadoop及HBase的监控系统，目前已知的监控参考方案有：
1、Hadoop原生脚本
a)大部分是进程级管理
b)需要较多手工工作，自动化不足，无监控
2、Cloudera Manager
a)功能强大，为Hadoop Ecosystem定制
b)缺乏灵活的包版本管理，方便用官方发布包，不方便开发团队
c)按照成系统服务，单击无法部署多版本/多服务
d)商业软件，不开源，无法定制/改进
3、Apache Ambari
a)Hortonworks主导的开源实现
b)特点类似，目前还不成熟
4、大厂通用方案
a)MS Autopilot，Google Borg，Tencent Torca
三、HBase和Oracle
HBase已经在上一个章节简单的介绍过了，这里就直接介绍Oracle：Oracle作为一款商用软件，在性能上确实有很强大的竞争力。
HBase作为一款开源的列数据库，在非大数据量(PB级别)的数据操作上与Oracle相比并没有优势，尤其在数据量在TB以下级别时。HBase的优势是在大数据的数据操作，借助于HDFS的分部署云计算达到并发计算的效果。又因为从HBase中获取数据的三种办法：
1、通过rowID直接访问；
2、通过设置rowID的范围访问；
3、全表扫描。
由此可知，HBase无法使用复杂的SQL语句来进行查询，如果不知道rowID相关的信息，那么只有通过全表扫面才能获取信息，也就是说HBase在条件查找上有一定的局限性。而且HBase中所有表都是相互独立的，没有像Oracle等关系型数据库那样的外键的定义。虽然通过Hive可以使的HBase可以兼容简单SQL语句，但是对于事务依旧没有支持，并且很多复杂的SQL条件搜索语句也是不支持的。
当数据量达到一定的数量级时，由于数据文件大小的增长会逐步拉低Oracle的搜索速率。但是HBase当文件大小增长到一定程度时，会自动将过大的文件分割成多个小文件（分割成小文件的数量和HBase Region server的数量有关），这个功能和普通关系型数据库的分割表功能类似，不过分割表功能除了Oracle的RAC功能外，依旧只是在同一台服务器上面进行操作。并将每一个小文件交付给对应的一个Region Server进行处理。当用户进行相关的操作时可以更迅速的找到用户所需要的数据。
那么在什么情况下可以考虑使用HBase:
1、需要存储大量数据；
2、数据写入量大；
3、需要在大数据集内进行主键的随机查询；
4、需要存储非结构化或者半结构化的数据；
5、不需要RDBMS的一些功能（跨行事务，join等）。
综上所述，如果只是作为数据收集和分析的工具，HBase完全可以替换Oracle。但是在数据的检索上Oracle还是有一定的优势的，当且仅当数据量过大对Oracle的计算速率造成影响时，HBase在数据的检索上会有一定的优势。尤其在性价比方面则更为突出。
所以在使用HBase的时候，最好还是要用HBase和MySQL或者Oracle相互配合才能得到最好的效果。这里面可以用HBase作为大数据量的存储、调用和分析，并利用MySQL或者Oracle对于事务和复杂SQL语句的良好支持完成外部应用程序对数据库数据的调用和查询。
关于数据量对于Oracle和HBase的影响可以粗略的看做下图：
虽然Oracle可以通过大规模的组建RAC来达到分布式的效果，使其性能在对付大数据量时与HBase相差无几，但是这种大规模的使用Oracle必然会受到Listen的限制，如果从Oracle 购买必然会产生巨额的费用。所以无论从效果还是从经济利益上考虑，对于大数据HBase 都是要由于Oracle的，这也是HBase廉价的一个特点。
以目前线上HBase的数据量（150G左右的数据量，在数据等级上属于小数据量）来看，并不十分适合HBase的定义。简单来说，就目前的数据量来看用HBase作为目前保存报文的分析工具（分析内容包括但不限于：企业发送报文的时间统计，报文类型统计，发送报文的企业类型统计，申报内容统计等。）是完全没有问题的，但是让应用直接从HBase中搜索数据的并没有比让应用直接从Oracle中读取数据要有优势，且目前线上系统的节点并不多（有三个Region server）。
对于线上HBase系统在以后的使用上一方面要加强集群方面的扩展，可以说HBase属于节点越多对于数据的处理速度越快；另一方面目前线上HBase数据库里面的数据是从Oracle 完全倒过去的线上HBase数据库里面的数据是从Oracle完全倒过去的，所以在数据结构上更类似Oracle的结构化数据，这点在以后的使用中要逐渐将结构化数据转型为半结构化数据，最终边卫非结构化数据。为什么要这么做：
结构化数据即所有数据的格式相同，内容有相关性，这使得数据在传输的过程中会包含大量的空值信息，而这种空值信息在结构化数据中是占用空间的。这种情况直接影响的就是数据传输时，会有大量的带宽被这种没有实际意义的空值信息占用。当数据进入半结构化虽然空值信息不再占用空间，但是信息头依旧存在，这使得虽然在数据传输过程中带宽会降低，但是依旧不能摒弃掉没有用的信息对带宽的占用。而当数据最后进入非结构化时，那么数据传输已经基本做到了摒弃没有用的信息对带宽的占用，一方面加快了数据的传输速度，一方面节约了带宽。
四、HDFS作为分布式存储的使用可能性分析
以下三种环境，是最适合采用云存储。其实也正是这些实际需求，催生了云存储，也为云存储的发展提供了可能。
首先，判定是否存在着这种相关性，就是软硬件升级的费用和系统"无限"的可扩展性密切关联。此时就要注意了：当系统的能力受到限制后，一些架构隐含着惊人的再次认证许可费用。例如：你是否受到软件许可费的困扰呢?当你不得不再次增加驱动器或存储阵列的数量，这种做法实际上已超出了边际的最优成本。
其次，在系统维护过程中或软硬件重新配置时，确认存储环境是否在线、数据是否可用。包括软硬件，所有的存储系统有可能随时需要升级。当更新时，一定要知道在系统上会产生哪些影响。
最后，如果选择数据和灾难备份产品，如自动让快照和复制。但要提醒的是，提防一些隐性成本，如带宽要求。它可能限制一些快照的次数或复制(即每次都要更改或整个复制的容量)。
总结一下上面所说的三点就是表明了Hadoop具有的三种主要特性：
1、开源软件，没有使用限制；
2、扩展维护方便；
3、容灾体系简单明了。
基于HDFS的原理，分布式存储，一写多读，可以利用大量廉价设备组建大规模存储等优势。但是HDFS从文件写入、同步文件到可以读取需要一定的时间（HDFS的后台寻址时间是每次搜索约20ms），所以并不适合对响应时间有很高的要求的应用。
综上所述，适合存放于云存储的程序或文件包括：图片、网页、系统备份文件及已经归档的日志文件等。通过这个结论，我们可以将静态的页面文件，图片文件，应用和数据库的备份数据保存到Hadoop的云存储上，一方面目前HBase对于云存储的空间利用率较低，HDFS 上有大量的剩余空间（如果按照目前的数据增量计算大概需要十多年才能使用完）。
为什么不建议将常用的应用程序存到HDFS那？这是因为上面介绍过HDFS由于后台同步会造成响应时间的延后，而应用程序又是需要经常更新的，那么当对应用程序进行更新后，等待后台同步的时间很难把握，这段时间是不能对外提供服务的。鉴于此所以不建议将常用
的应用程序存到HDFS。
五、成功案例分析
云作为目前最热门的概念之一已经被不少厂商所使用，其中不乏微软、阿里巴巴、google、facebook等重量级的企业，云和虚拟化的概念已经被更多的融合到了一起。
目前公布了的云计算成功案例多数是基于日志分析的云计算平台，利用HDFS的分布式存储和大吞吐量的优势，对保存于HDFS上的日志文件进行日志分析，使日志分析的操作得到有效的速率上的提升，分析出来的日志信息可以提交给BI/BO人员进行进一步的数据挖掘，也可以提交给运维人员进行应用平台故障和潜在问题分析。
淘宝在双十一期间利用HBase和MySQL等技术的案例及分析：
Hadoop是离线计算平台，其中包括分布式文件系统（HDFS）和分布式计算（MapReduce），这本身是无法对响应时间做保证的。但是目前在Hadoop之上的生态系统越来越完善，其中HBase就是支持海量数据、高并发的在线数据库，应对这种场景就非常适合。HBase在这次双十一中与MySQL等在线数据库共同作为线上库使用，承担了重要的责任，并创下了并在全天高压力之下无故障的佳绩。另外非Hadoop生态圈的流式计算框架Storm、S4也同样可以为实时计算分担一定的压力。
淘宝用HBase替换MySQL的一部分应用，这些应用自然是要符合HBase的应用场景（与MySQL对比），比如数据量大、对线性拓展有需求、对自动化运维（负载均衡）有要求而且应用模式简单。在支付宝中因其增长速度快，业务量大，造成了很多应用都是数据量庞大而且速度增长快，因此有一些应用迫切需要一个数据库能够支撑现在的业务而降低对关系型的需求，所以尝试了HBase的解决方案。
在Hadoop的体系当中，支持实时的一条线，HBase，支持海量数据库初衷的时候，设计为了设计万亿级实时数据库，HBase这个东西经过这几年的发展，已经逐渐成为目前业界当中主要的实时数据库，分布式数据库，像支付宝直接上HBase系统，就是考虑到HBase的先进架构，能够帮助支付宝完成现在很多的海量数据的存储以及在线随机读写高性能的访问和存储。
第一个是HBase本身在底层依赖的HDFS，加载了唯一一块数据，单台机器保证一致性，HDFS保持了冗余。第二点，恢复过程当中，Failover过程非常复杂，这个时间消耗越长，
作为在线系统，这种时间越长可能会影响到在线访问用户体验。第三点它依赖的HDFS，HBase 作为在线数据库依赖HDFS有故障的，经过几小时恢复提供生产业务，对业务方没有直接感受，作为在线系统如果挂掉，如果需要经过近小时恢复时间，恐怕就会直接收到自于支付宝外部的用户投诉了。HBase目前它自己的监控体系尚不完善，目前的监控力度非常得粗，只能监控到单台的Region Server的情况，看不到当前用户表有多少读写比例，看不到当前服务结点写作量多少，读出量多少。
分析：
整个案例的前半段给出了淘宝尝试HBase的几点前提，那就是：数据量大、数据增长量大这两点，其次就是自动化运维，应用模式简单等几个方面。
后半段则是主要介绍了HBase的一些缺点和改进的地方：
1、HBase过于依赖底层的HDFS的冗余
2、数据恢复过程复杂且不透明。
这里第一点主要表现了由于HBase很大程度上依赖于HDFS，所以当出现故障时要考虑是HBase的问题还是HDFS出现了问题，也就是间接的增加了问题点。而第二点则有因为恢复时间的过长很容易对用户的使用体验造成影响，甚至直接造成用户量的下降。所以淘宝在原生的HBase上进行了改进，完善了监控体系和单点故障。
这里要强调一下，无论是阿里云、google还是百度等使用的Hadoop云计算平台都是经过他们内部开发部门通过二次开发过的，他们都有一个完整的Hadoop运维团队甚至是开发团队。因为Hadoop提供的并不是一个云平台的解决方案，而更像是一个云平台的框架。如果想要更好的使用Hadoop云计算平台，不仅需要对Hadoop提供的API接口进行研究，甚至还需要对MapReduce等程序进行二次开发来满足系统和业务的需求。
六、发展方向
1、SaaS方向
首先先解释一下什么叫SaaS，SaaS是Software-as-a-service的简称，中文翻译有软件即服务、软件运营模式等多种称呼。SaaS主要目的是去掉了用户购买软件及相关硬件设备的成本，改成直接通过网络使用。减少了客户对于部分专用设备的购买和维护方面的成本，用户只需要购买使用权（先计费模式）或者通过其它的方式进行注册（后计费模式）后，通过某些认证方式登录到提供服务的网站就能使用相关的功能。用户可以利用认证方式登录到应用，在用户登录的同时，程序会根据用户的认证许可加载用户要使用的对应模块并加载用户自身的配置文件，这样可以比较方便的解决目前客户端模块和客户端本地设置上的差异问题。
公司现有业务采用的是C/S架构，但是目前发现有可能存在着有的公司申报时可以申报，但是不会往报关数据统计服务器发送计费统计数据。这样就造成了计费信息不准确，甚至一直通过某些手段“免费”使用报关软件。
SaaS架构的优势:
1）服务的收费方式风险小：
客户使用的客户端和服务器端其实都是在公司方，所有的用户操作都可以很好的保存在系统日志中，计费时也不需要用户提供相应的报文信息，而直接从服务的日志或者数据库中获取；
2）产品更新速度加快：
由于客户端在公司一侧，使得更新维护变得更加的方便，发布更新内容只需要一次对服务器的更新，所有用户都能直接使用最新版本的客户端；
3）灵活启用和暂停，随时随地都可以使用：
传统的C/S模式使得用户只有在固定的安装了软件的计算机上才能进行操作，很大的限制了用户的灵活性，比如：报关员在外出、请假的时候，如果需要报关，还需要回到单位利用单位的电脑才能进行报关的操作。而SaaS模式下业务人员甚至可以在家里通过认证模块（USB认证，口令认证，证书认证等）的信息认证就能登录服务器进行操作；
4）大大降低客户的总体拥有成本：
用户不用针对应用的需求购买特定配置的计算机或者是服务器，甚至不需要特定的IT管理人员。减少了用户身边的物理成本。甚至可以把用户在这部分原本应该投入的一部分转移到系统运营的收入中。
可能存在的问题:
1）发布更新不统一：
往往都是按照地区单独发送。这样对于不同地区可能不能使用统一的客户端，不过这个问题可以通过CDN等IP识别技术或者直接在客户端内增加客户归属地选项列表进行解决；
2）占用带宽的提升：
对于服务器端的带宽压力会比现在有一定的提升，因为和C/S模式对比SaaS虽然不用再互联网上传递数据报文，但是在用户浏览器加载客户端是是需要消耗流量的。针对这个问题可以用目前Web游戏比较流行的伪客户端模式加以缓解。伪客户端模式就是
将图片、模型、文字信息等占用流量比较大的内容做成客户端保存在用户的电脑上，用户运行客户端后，客户端需要连接服务器才能调用主程序。
2、数据挖掘方向
Hadoop这个应用本身的立足点就是离线数据库的数据分析和数据挖掘功能。基于目前线上业务的内容和方向，如果进行数据挖掘初期可以从业务覆盖范围着手，并可以从数据中提取出比较有商业价值的客户和申报频繁的类型、产地等数据。
由于目前HBase中保存的数据是整个XML格式的文件，如果想要利用Pig或者Hive进行进一步的加工处理，首先需要对XML格式的文件进行解析。Hadoop自0.9X某个版本之后解除了对于XML文件读取和写入的支持，所以需要先利用Java程序对XML格式的文件进行分析处理（这里涉及到三种XML文件的解析方式：DOM、SAX、StAX）后在保存到Hive或者转存成标准格式的文件后用Pig进行提取分析。在完成XML文件的解析后就可以对报文进行进一步的数据挖掘了。除了可以对报文进行解析分析外还可以对应用程序（如：Tomcat、Resin 和Apache）的日志（应用日志及访问日志等）利用一下两种工具进行分析：
1、Pig
应用程序日志数据的分析需要先用程序通过Pig调用MR（Map Reduce）将保存到HDFS 文件系统中的日志文件加载到别名容器中，之后利用Pig调用MR对这个容器中的数据进行计算和统计，之后再合并返回出结果。
然而MapReduce计算模型适合结构一致的海量数据，且要求计算简单。对于大量的数据密集型应用（如数据挖掘任务），往往涉及到数据降维、程序迭代、近似求解等等复杂的算法，计算非常困难。
2、Hive
HBase存储报文分析，因为HBase不支持SQL语句，虽然用NoSQL的数据分析方式也可以直接进行，但是这里可以和Hive合用，以达到对与高级SQL语言的支持。Hive主要的功能就是数据仓库，数据挖掘工程师可以直接使用BI工具对Hive中保存的静态数据进行数据分析。在分析完毕后，需要将结果传给关系型数据库以方便对结果进行展示。
云计算中心运维管理制度 在数据中心生命周期中，数据中心运维管理是数据中心生命周期中最后一个、也是历时最长的一个阶段。数据中心运维管理就是：为提供符合要求的信息系统服务，而对与该信息系统服务有关的数据中心各项管理对象进行系统的计划、组织、协调与控制，是信息系统服务有关各项管理工作的总称。数据中心运维管理主要肩负起以下重要目标：合规性、可用性、经济性、服务性等四大目标。 由于云计算的要求弹性、灵活快速扩展、降低运维成本、自动化资源监控、多租户环境等特性除基于ITIL的常规数据中心运维管理理念之外，以下运维管理方面的内容，也需要我们加以重点分析和关注。 一、理清云计算数据中心的运维对象 数据中心的运维管理指的是与数据中心信息服务相关的管理工作的总称。云计算数据中心运维对象共可分成5类： (1) 机房环境基础设施部分。这里主要指为保障数据中心所管理设备正常运行所必需的网络通信、电力资源、环境资源等。这部分设备对于用户来说几乎是透明的，因为大多数用户基本并不会关注到数据中心的风火水电。但是，这类设备如发生意外，对依托于该基础设施的应用来说，却是致命的。 (2) 在提供IT服务过程中所应用的各种设备，包括存储、服务器、网络设备、安全设备等硬件资源。这类设备在向用户提供IT服务过程中提供了计算、存储与通信等功能，是IT服务最直接的物理载体。 (3) 系统与数据，包括操作系统、数据库、中间件、应用程序等软件
资源;还有业务数据、配置文件、日志等各类数据。这类管理对象虽然不像前两类管理对象那样“看得见，摸得着”，但却是IT服务的逻辑载体。 (4) 管理工具，包括了基础设施监控软件、监控软件、工作流管理平台、报表平台、短信平台等。这类管理对象是帮助管理主体更高效地管理数据中心内各种管理对象，并在管理活动中承担起部分管理功能的软硬件设施。通过这些工具，可以直观感受并考证到数据中心如何管理好与其直接相关的资源，从而间接地提升的可用性与可靠性。(5) 人员，包括了数据中心的技术人员、运维人员、管理人员以及提供服务的厂商人员。人员一方面作为管理的主体负责管理数据中心运维对象，另一方面也作为管理的对象，支持IT的运行。这类对象与其他运维对象不同，具有很强的主观能动性，其管理的好坏将直接影响到整个运维管理体系，而不仅仅是运维对象本身。 二、定义各运维对象的运维内容 云计算数据中心资源管理所涵盖的范围很广，包括环境管理、网络管理、设备管理、软件管理、存储介质管理、防病毒管理、应用管理、日常操作管理、用户密码管理和员工管理等。要对每一个管理对象的日常维护工作内容有一个明确的定义，定义操作内容、维护频度、对应的责任人，要做到有章可循，责任人可追踪。实现对整个系统的全生命周期的追踪管理。 三、建立信息化的运维管理平台系统 云计算数据中心的运维管理应从数据中心的日常监控入手，事件管理、
xxx区国土资源 一张图工程和服务平台系统基础支撑平台与运维保障平台 建 设 方 案
目录 1项目概述 (2) 1.1项目背景 (2) 1.2项目目标 (2) 1.3建设内容 (2) 2现状及需求分析 (3) 2.1信息化现状 (3) 2.2存在的问题 (4) 2.2.1运维保障面临主要问题 (4) 2.2.2现有保障手段不能满足需求 (4) 2.2.3管理运维问题 (5) 3方案总体设计 (6) 3.1设计原则 (6) 3.2总体架构设计 (7) 3.3实施思路 (7) 4虚拟桌面技术方案设计 (10) 5服务器虚拟化方案设计 (11) 6业务系统运维保障设计 (13) 6.1架构设计 (13) 6.2业务系统应急 (14) 6.3数据保障 (15) 6.4运维迁移 (15) 7项目实施计划 (16) 8项目组织保障 (17) 8.1工作领导小组 (17) 8.2项目专家小组 (17) 8.3项目技术小组 (17)
1项目概述 1.1项目背景 国土资源“一张图”和综合监管平台建设（以下简称“一张图”工程）是国土资源信息化“十二五”规划中的一项核心内容。 根据《国土资源部关于进一步运用现代科技信息手段规范和创新管理的指导意见》(国土资发〔2010〕81号)、《山东省国土资源系统‘一个平台、两个市场’建设方案的通知》（鲁国土资发〔2011〕33号）和《青岛市国土资源和房屋管理局关于加强信息化建设工作的意见的通知》（青土资房发〔2012〕465号）等一系列文件的要求，青岛市国土房管局xxx 分局拟开展xxx区国土资源一张图工程和服务平台系统基础支撑平台及运维保障平台建设，为一张图工程和服务平台系统搭建安全、可靠的基础设施环境，为全局信息化发展奠定坚实的基础。 1.2项目目标 基础支撑平台及运维保障平台的建设实现以下主要目标： （1）通过加强对业务内网、办公网、互联网的安全管理，实现生产数据和涉密信息的集中存放和管理，保证信息安全； （2）通过为32个乡镇国土所提供云端虚拟桌面服务，保障数据不在国土所用户的终端设备上落地的基础上，实现各项数据及业务应用的便捷接入，有效促进业务协 同； （3）通过运维保障平台的建设，为全区国土资源用户提供一致、高度可用、高度可扩展的服务，最大程度地减少系统停机，全面支持国土全系统的业务连续性； （4）通过云平台建设，充分整合已有资源，实现IT基础设施的集约化建设。 1.3建设内容 基础支撑平台及运维保证体系主要包括以下建设内容：
云计算数据中心的运维管理 现代信息中心已成为人们日常生活中不可缺少的部分，因此信息中心机房设备的运行正常与否就非常关键。在数据中心生命周期中，数据中心运维管理是数据中心生命周期中最后一个、也是历时最长的一个阶段。加强对云计算运维管理的要点以及相应改进方面措施的研究与探讨，以此不断提高IT运维质量，实现高效的运维管理。这就给运维是否到位提出了严格要求。 1 运维在机房中的地位 在数据中心生命周期中，数据中心运维管理是数据中心生命周期中最后一个、也是历时最长的一个阶段。数据中心运维管理是，为提供符合要求的信息系统服务，而对与该信息系统服务有关的数据中心各项管理对象进行系统地计划、组织、协调与控制，是信息系统服务有关各项管理工作的总称。数据中心运维管理主要肩负合规性、可用性、经济性、服务性等四大目标。 在信息中心机房配备有运维人员，但大都是“全才”的，即什么都管，尤其是对供电系统大都是由主机运维的人员代管。当电源系统出故障时，此代管人员一问三不知，甚至连配电柜门都没开过。这实际上就是把机房的运维放在了一个次要的地位。 当然也有的地方有所分工，看似重视，实际上也没得到真正地重视。比如说机房设备长时间一直运行正常，这时如果运维人员提出要增添运维方面的测量设备，有的领导就认为多余，很难得到批准。但他不知道机房设备所以长时间一直运行正常，正是由于这些运维人员的细心维护和努力保养所获得的。并不是这些人员每天闲着无事可干，他们的这些工作一般是领导看不见的。比如同样多款的UPS在同样的环境条件下，在某卫星地面站就极少出故障，而在同系统别的地方机房同一家同规格的机器就故障连连。原来是前者的运维人员每天都在细心观察和分析机器面板LCD上显示的数据，一旦发现异常苗头及时采取措施;而后者只限于每天抄写这些数据就算完成任务，使异常苗头不断积累，以致于导致故障。比如断路器在额定闭合状态发现触点处温度高了，就要检查是不是电流过大到超过额定值，如果不是就要检查触点接触是否牢靠，是否需要再紧固一下。这样一来，故障隐患就排除了。如果一直不管不问久而久之就会导致跳闸而使系统崩溃。这都是一些小的动作，都是在巡查中顺便做的事情。所以同是运维人员在巡查，但前者在做事而后者只是走马观花。这就是数据中心可靠与不可靠的区别。 运维人员就像幼儿园的保育员和老师。孩子交到幼儿园后，起主要作用的就是保育员和老师，这时保育员和老师就是主体。机器就好比是幼儿园的孩子，孩子是否健康成长，机器是否正常运行，除去本身的健康(可靠性质量)状况外，那就是运维人员的责任了。由于云计算的要求弹性、灵活快速扩展、降低运维成本、自动化资源监控、多租户环境等特性，除基于ITIL(IT 基础设施库)的常规数据中心运维管理理念之外，以下运维管理方面的内容，需要我们加以重点关注。 2 云计算数据中心运维管理的要点 (1)理清云计算数据中心的运维对象 数据中心的运维管理指的是与数据中心信息服务相关的管理工作的总称。云计算数据中心运维对象一般可分成5大类： ①机房环境基础设施 这里主要指的是为保障数据中心所管理的设备正常运行所必需的网络通信、供配电系统、环境系统、消防系统和安保系统等。这部分设备对于用户来说几乎是透明的，比如大多数用
望采纳 云计算数据中心的运维管理 现代信息中心已成为人们日常生活中不可缺少的部分，因此信息中心机房设备的运行正常与否就非常关键。在数据中心生命周期中，数据中心运维管理是数据中心生命周期中最后一个、也是历时最长的一个阶段。加强对云计算运维管理的要点以及相应改进方面措施的研究与探讨，以此不断提高IT运维质量，实现高效的运维管理。这就给运维是否到位提出了严格要求。 1 运维在机房中的地位 在数据中心生命周期中，数据中心运维管理是数据中心生命周期中最后一个、也是历时最长的一个阶段。数据中心运维管理是，为提供符合要求的信息系统服务，而对与该信息系统服务有关的数据中心各项管理对象进行系统地计划、组织、协调与控制，是信息系统服务有关各项管理工作的总称。数据中心运维管理主要肩负合规性、可用性、经济性、服务性等四大目标。 在信息中心机房配备有运维人员，但大都是“全才”的，即什么都管，尤其是对供电系统大都是由主机运维的人员代管。当电源系统出故障时，此代管人员一问三不知，甚至连配电柜门都没开过。这实际上就是把机房的运维放在了一个次要的地位。 当然也有的地方有所分工，看似重视，实际上也没得到真正地重视。比如说机房设备长时间一直运行正常，这时如果运维人员提出要增添运维方面的测量设备，有的领导就认为多余，很难得到批准。但他不知道机房设备所以长时间一直运行正常，正是由于这些运维人员的细心维护和努力保养所获得的。并不是这些人员每天闲着无事可干，他们的这些工作一般是领导看不见的。比如同样多款的UPS在同样的环境条件下，在某卫星地面站就极少出故障，而在同系统别的地方机房同一家同规格的机器就故障连连。原来是前者的运维人员每天都在细心观察和分析机器面板LCD上显示的数据，一旦发现异常苗头及时采取措施;而后者只限于每天抄写这些数据就算完成任务，使异常苗头不断积累，以致于导致故障。比如断路器在额定闭合状态发现触点处温度高了，就要检查是不是电流过大到超过额定值，如果不是就要检查触点接触是否牢靠，是否需要再紧固一下。这样一来，故障隐患就排除了。如果一直不管不问久而久之就会导致跳闸而使系统崩溃。这都是一些小的动作，都是在巡查中顺便做的事情。所以同是运维人员在巡查，但前者在做事而后者只是走马观花。这就是数据中心可靠与不可靠的区别。 运维人员就像幼儿园的保育员和老师。孩子交到幼儿园后，起主要作用的就是保育员和老师，这时保育员和老师就是主体。机器就好比是幼儿园的孩子，孩子是否健康成长，机器是否正常运行，除去本身的健康(可靠性质量)状况外，那就是运维人员的责任了。由于云计算的要求弹性、灵活快速扩展、降低运维成本、自动化资源监控、多租户环境等特性，除基于ITIL(IT基础设施库)的常规数据中心运维管理理念之外，以下运维管理方面的内容，需要我们加以重点关注。 2 云计算数据中心运维管理的要点 (1)理清云计算数据中心的运维对象 数据中心的运维管理指的是与数据中心信息服务相关的管理工作的总称。云计算数据中心运维对象一般可分成5大类： ①机房环境基础设施 这里主要指的是为保障数据中心所管理的设备正常运行所必需的网络通信、供配电系统、环境系统、消防系统和安保系统等。这部分设备对于用户来说几乎是透明的，比如大多数用户都不会忽略数据中心的供电和制冷。因为这类设备如果发生意外，对依托于该基础设施的应用来说是致命的。 ②数据中心所应用的各种设备
云计算中心运维管理制度 现代信息中心已成为人们日常生活中不可缺少的部分，因此信息中心机房设备的运行正常与否就非常关键。在数据中心生命周期中，数据中心运维管理是数据中心生命周期中最后一个、也是历时最长的一个阶段。加强对云计算运维管理的要点以及相应改进方面措施的研究与探讨，以此不断提高IT运维质量，实现高效的运维管理。这就给运维是否到位提出了严格要求。 1 运维在机房中的地位 在数据中心生命周期中，数据中心运维管理是数据中心生命周期中最后一个、也是历时最长的一个阶段。数据中心运维管理是，为提供符合要求的信息系统服务，而对与该信息系统服务有关的数据中心各项管理对象进行系统地计划、组织、协调与控制，是信息系统服务有关各项管理工作的总称。数据中心运维管理主要肩负合规性、可用性、经济性、服务性等四大目标。 在信息中心机房配备有运维人员，但大都是“全才”的，即什么都管，尤其是对供电系统大都是由主机运维的人员代管。当电源系统出故障时，此代管人员一问三不知，甚至连配电柜门都没开过。这实际上就是把机房的运维放在了一个次要的地位。 当然也有的地方有所分工，看似重视，实际上也没得到真正地重视。比如说机房设备长时间一直运行正常，这时如果运维人员提出要增添运维方面的测量设备，有的领导就认为多余，很难得到批准。但他不知道机房设备所以长时间一直运行正常，正是由于这些运维人员的细心维护和努力保养所获得的。并不是这些人员每天闲着无事可干，他们的这些工作一般是领导看不见的。比如同样多款的UPS在同样的环境条件下，在某卫星地面站就极少出故障，而在同系统别的地方机房同一家同规格的机器就故障连连。原来是前者的运维人员每天都在细心观察和分析机器面板LCD上显示的数据，一旦发现异常苗头及时采取措施;而后者只限于每天抄写这些数据就算完成任务，使异常苗头不断积累，以致于导致故障。比如断路器在额定闭合状态发现触点处温度高了，就要检查是不是电流过大到超过额定值，如果不是就要检查触点接触是否牢靠，是否需要再紧固一下。这样一来，故障隐患就排除了。如果一直不管不问久而久之就会导致跳闸而使系统崩溃。这都是一些小的动作，都是在巡查中顺便做的事情。所以同是运维人员在巡查，但前者在做事而后者只是走马观花。这就是数据中心可靠与不可靠的区别。 运维人员就像幼儿园的保育员和老师。孩子交到幼儿园后，起主要作用的就是保育员和老师，这时保育员和老师就是主体。机器就好比是幼儿园的孩子，孩子是否健康成长，机器是否正常运行，除去本身的健康(可靠性质量)状况外，那就是运维人员的责任了。由于云计算的要求弹性、灵活快速扩展、降低运维成本、自动化资源监控、多租户环境等特性，除基于ITIL(IT基础设施库)的常规数据中心运维管理理念之外，以下运维管理方面的内容，需要我们加以重点关注。 2 云计算数据中心运维管理的要点 (1)理清云计算数据中心的运维对象 数据中心的运维管理指的是与数据中心信息服务相关的管理工作的总称。云计算数据中心运维对象一般可分成5大类： ①机房环境基础设施 这里主要指的是为保障数据中心所管理的设备正常运行所必需的网络通信、供配电系统、环境系统、消防系统和安保系统等。这部分设备对于用户来说几乎是透明的，比如大多数用户都不会忽略数据中心的供电和制冷。因为这类设备如果发生意外，对依托于该基础设施的应用来说是致命的。 ②数据中心所应用的各种设备 这些设备包括存储、服务器、网络设备和安全设备等硬件资源。这类设备在向用户提供IT 服务过程中提供了计算、存传输和通信等功能，是IT服务最核心的部分。 ③系统与数据 这部分包括操作系统、数据库、中间环节和应用程序等软件资源，还有业务数据、配置文件、日志等各类数据。这类管理对象虽然不像前两类管理对象那样“看得见，摸得着”，但却是IT服务的逻辑载体。 ④管理工具 这部分包括基础设施监控软件、IT监控软件、工作流管理平台、报表平台和短信平台等。 这类管理对象是帮助管理主体更高效地管理数据中心内各种管理对象的工作情况，并在管理活动中承担起部分管理功能的软硬件设施。通过这些工具，可以直观感受并考证数据中心如何管理好与其直接相关的资源，从而间接地提升了可用性与可靠性。 ⑤人员管理 人员管理包括数据中心在内的技术人员、运维人员、管理人员以及提供服务的厂商人员的管理。 人员一方面作为管理的主体负责管理数据中心的运维对象，另一方面也作为管理的对象，支持IT的运行。这类对象与其他运维对象不同，具有很强的主观能动性，其管理的好坏将直接影响到整个运维管理体系，而不仅仅是运维对象本身。 (2)定义各运维对象的运维内容 云计算数据中心资源管理所涵盖的范围很广，包括环境管理、网络管理、设备管理、软件管理、存储介质管理、防病毒管理、应用管理、日常操作管理、用户密码管理和员工管理等。这就需要对每一个管理对象的日常维护工作内容有一个明确的定义，定义操作内容、维护频度、对应的责任人，要做到有章可循，责任人可追踪。实现对整个系统全生命周期地追踪管理。 (3)建立信息化的运维管理平台系统和IT服务管理系统 云计算数据中心的运维管理应从数据中心的日常监控入手，事件管理、变更管理、应急预案管理和日常维护管理等方面全方位地进行数据中心的日常监控。实现提前发现问题、消除隐患，首先要有完整的、全方位实时有效的监控系统，并着重监控数据的记录和技术分析。 数据中心的业务可以概括为：通过运行系统来向客户提供服务。没有信息系统的支撑来运行
软件平台运维技术方案 总体维护方案 全面保障招标人信息、应用系统平稳运行及有效应用，总体目标如下： 建立系统运维机制。提供全程运维服务，出现故障应能及时告警。必须建立完善的运维机制，包括运维团队、运维方案、运维制度、应急预案等：不发生六级及以上通信设备事件。不发生因云平台环境原因造成的系统故障、停机等事件。 信息安全。运维人员严格遵守有关信息安全与保密管理规定，运维期不得发生六级及以上信息安全事件。 运行指标要求。主机系统（包括存储）可用率不低于%。主机系统可用率=（总时间-主机计划外停机时间）/总时间*100%。应用系统可用率不低于%。应用系统可用率=（总时间-计划外停机时间）/总时间*100%。网络可用率不低于%。信息网络可用率=（总时间-计划外网络中断时间）/总时间*100%服务满意度。服务态度端正，有问必答，用语规范，态度诚恳，耐心解答用户疑难，虚心听取用户意见，处理业务不拖拉，不推诿。客户服务满意度达到99%以上。客户服务年投诉次数小于4次。 问题响应效率。从开始处理后3个小时内解决的问题占全部问题的比重不得低于80%；在一个小时内响应的问题占全部问题的比重不得低于95%；客户端、网络、用户管理、权限变更、操作类问题一个工作日内解决，业务流程、系统配置、权限设计类问题视问题的情况，一般在5个工作日内解决，系统变更业务审批在5个工作日内完成，新需求、开发类问题需视开发及测试情况尽快解决。 恢复措施。具备自动或手动恢复措施，以便在发生错误时能够快速地恢复
正常运行。软件系统故障时，自动恢复时间< 30分钟，手工恢复时间< 4 小时。 信息资产统计服务 此项服务为基本服务，包含在运行维护服务中，帮助我们对用户现有的信息资产情况进行了解，更好的提供系统的运行维护服务。 服务内容包括： 后台管理系统数据信息统计记录 门户网站信息发布安全管理 系统新增功能接口对接及研发 软件产品型号、版本和补丁等信息统计记录 网络结构、网络路由、网络IP地址统计记录 其它附属数据的统计记录 网络、安全系统运维服务 从网络的连通性、网络的性能、网络的监控管理三个方面实现对网络系统的运维管理。网络、安全系统基本服务内容： 序 号 服务模块内容描述 1云服务器配置配合用户进行，云服务器后买，安装部署，调试等工作 2系统故障诊断按服务级别：7×24小时
云平台下的运维体系建设工作容 一、系统运维 系统运维负责IDC、网络、CDN和基础服务的建设（LVS、NTP、DNS）；负责资产管理，服务器选型、交付和维修。详细的工作职责如下： IDC数据中心建设 收集业务需求，预估未来数据中心的发展规模，从骨干网的分布，数据中心建筑，以及Internet接入、网络攻击防御能力、扩容能力、空间预留、外接专线能力、现场服务支撑能力等方面评估选型数据中心。负责数据中心的建设、现场维护工作。
网络建设 设计及规划生产网络架构，这里面包括：数据中心网络架构、传输网架构、CDN网络架构等，以及网络调优等日常运维工作。 LVS负载均衡和SNAT建设 LVS是整个站点架构中的流量入口，根据网络规模和业务需求，构建负载均衡集群；完成网络与业务服务器的衔接，提供高性能、高可用的负载调度能力，以及统一的网络层防攻击 能力；SNAT集中提供数据中心的公网访问服务，通过集群化部署，保证出网服务的高性能与高可用。 CDN规划和建设 CDN工作划分为第三方和自建两部分。建立第三方CDN的选型和调度控制；根据业务发展趋势，规划CDN新节点建设布局；完善CDN业务及监控，保障CDN系统稳定、高效运行；分析业务加速频道的文件特性和数量，制定最优的加速策略和资源匹配；负责用户劫持等CDN日常故障排查工作。 服务器选型、交付和维护 负责服务器的测试选型，包含服务器整机、部件的基础性测试
和业务测试，降低整机功率，提升机架部署密度等。结合对公司业务的了解，推广新硬件、新方案减少业务的服务器投入规模。负责服务器硬件故障的诊断定位，服务器硬件监控、健康检查工具的开发和维护。 OS、核选型和OS相关维护工作 责整体平台的OS选型、定制和核优化，以及Patch的更新和部版本发布；建立基础的YUM包管理和分发中心，提供常用包版本库；跟进日常各类OS相关故障；针对不同的业务类型，提供定向的优化支持。 资产管理 记录和管理运维相关的基础物理信息，包括数据中心、网络、机柜、服务器、ACL、IP等各种资源信息，制定有效的流程，确保信息的准确性；开放API接口，为自动化运维提供数据支持。 基础服务建设 业务对DNS、NTP、SYSLOG等基础服务的依赖非常高，需要设计高可用架构避免单点，提供稳定的基础服务。 二、应用运维 应用运维负责线上服务的变更、服务状态监控、服务容灾和数据
Openstack运维手册 2017年7月18日 目录 ***执行任何openstack命令之前都必须运行openstack的环境变量source/root/（每次新开控制台窗口必须执行一次） 一、健康检查 1、认证模块检查 openstacktokenissue 有输出即可，如输出异常 重启服务即可 serviceapache2restart servicememcachedrestart 2、计算模块检查 novaservice-list 所有计算服务的status必须是enabled State必须是up 如有服务存在异常，直接重启异常的服务。
servicenova-certrestart servicenova-consoleauthrestart servicenova-schedulerrestart servicenova-conductorrestart servicenova-computerestart 3、网络模块检查 neutronagent-list 所有网络服务的alive必须是:-） 如有服务存在异常，直接重启异常的服务。serviceneutron-plugin-openvswitch-agentrestart serviceneutron-l3-agentrestart serviceneutron-dhcp-agentrestart serviceneutron-metadata-agentrestart 4、存储模块检查 cinderservice-list 所有存储服务的status必须是enabled State必须是up 如有服务存在异常，直接重启异常的服务。servicecinder-schedulerrestart servicecinder-apirestart servicecinder-volumerestart 5、镜像模块检查 glanceimage-list 有输出即可，如输出异常 重启服务即可 serviceglance-registryrestart serviceglance-apirestart 6、检查Horizon服务 ps-ef|grepapache2 如有输出horizon用户执行apache2命令即可如异常重启memcached servicememcachedrestart 7、分布式存储检查 ceph–s Health必须是HEALTH_OK 如遇到mon或者osddown 重启对应节点服务即可，查询节点命令cephosdtree 重启服务命令 /etc/ 二、运维命令 1、虚拟机开通 ?查询现有的虚拟机模拟 novaflavor-list ?查询当前的虚拟机镜像
Linux云计算运维真相揭秘 什么是运维工程师 百度百科上的官方解释如下： 运维工程师(Operations)在国内又称为运维开发工程师(Devops)，在国外称为 SRE （Site Reliability Engineering）。负责维护并确保整个服务的高可用性，同时不断优化系统架构、提升部署效率、优化资源利用率提高整体的ROI。 运维工程师面对的最大挑战是大规模集群的管理问题，如何管理好几十万台服务器上的服务，同时保障服务的高可用性，是运维工程师面临的最大挑战。在一些规模较大的公司(比如：Google、FaceBook、百度、阿里、腾讯等)，运维工程师和系统管理员是有一定的区别： ?系统管理员：主要负责机房网络、服务器等硬件基础设施的运行和维护。 ?运维工程师：主要负责管理并维护在运行在海量服务器上的软件服务。 2运维岗位的分类 IT技术一直在呈指数级别的发展，运维工程师面临的挑战越来越大，划分的岗位也越来越细。根据面向的不同，岗位的划分有：基础运维、应用运维、系统运维、虚拟化运维、存储运维、网络运维等。根据职业发展的层次而言，岗位的划分有：桌面运维、系统运维、开发型运维、系统架构师。
3运维工程师必须掌握的硬技能 Linux基础（重中之重！） 无论你找的是什么运维，不会linux你就丧失了至少一半的竞争几率。Why？因为服务器端的系统几乎都是Linux啊！可想而知，懂linux是件多么必要的事情。言归正传，linux基础包括了些什么内容？达妹认为有如下几方面。 ?Linux命令大全 ?Linux文件系统标准(Filesystem Hierarchy Standard)。 ?至少熟悉一个内置编辑器：vi、nano、vim。 ?至少熟悉一个linux发行版：Redhat、Ubuntu、Suse等。 ?至少熟悉一个远程登录linux工具：putty、xshell等 ?Linux服务，服务器配置安装：https、s、samba、DHCP、mail等 ?至少熟悉一种脚本语言：shell、python等 ?防火墙：iptables、ipset、firewalld等
xxx 区国土资源 一张图工程和服务平台系统 基础支撑平台与运维保障平台
建
设
方
案
目录
1 项目概述 ................................................................................................................................... 2
1.1 项目背景 ................................................................................................................................. 2 1.2 项目目标 ................................................................................................................................. 2 1.3 建设内容 ................................................................................................................................. 2
2 现状及需求分析 ........................................................................................................................ 3
2.1 信息化现状 ............................................................................................................................. 3 2.2 存在的问题 ............................................................................................................................. 4
2.2.1 运维保障面临主要问题 ................................................................................................. 4 2.2.2 现有保障手段不能满足需求 ......................................................................................... 4 2.2.3 管理运维问题 ................................................................................................................. 5
3 方案总体设计............................................................................................................................6
3.1 设计原则 ................................................................................................................................. 6 3.2 总体架构设计 ......................................................................................................................... 7 3.3 实施思路 ................................................................................................................................. 7
4 虚拟桌面技术方案设计 .......................................................................................................... 10
5 服务器虚拟化方案设计 .......................................................................................................... 11
6 业务系统运维保障设计 .......................................................................................................... 13
6.1 架构设计 ............................................................................................................................... 13 6.2 业务系统应急 ....................................................................................................................... 14 6.3 数据保障 ............................................................................................................................... 15 6.4 运维迁移 ............................................................................................................................... 15
7 项目实施计划.......................................................................................................................... 16
8 项目组织保障.......................................................................................................................... 17
8.1 工作领导小组 ....................................................................................................................... 17 8.2 项目专家小组 ....................................................................................................................... 17 8.3 项目技术小组 ....................................................................................................................... 17
云平台下的运维体系建设工作内容 一、系统运维 系统运维负责IDC、网络、CDN和基础服务的建设（LVS、NTP、DNS）；负责资产管理，服务器选型、交付和维修。详细的工作职责如下： IDC数据中心建设 收集业务需求，预估未来数据中心的发展规模，从骨干网的分布，数据中心建筑，以及Internet接入、网络攻击防御能力、扩容能力、空间预留、外接专线能力、现场服务支撑能力等方面评估选型数据中心。负责数据中心的建设、现场维护工作。
网络建设 设计及规划生产网络架构，这里面包括：数据中心网络架构、传输网架构、CDN网络架构等，以及网络调优等日常运维工作。 LVS负载均衡和SNAT建设 LVS是整个站点架构中的流量入口，根据网络规模和业务需求，构建负载均衡集群；完成网络与业务服务器的衔接，提供高性能、高可用的负载调度能力，以及统一的网络层防攻击 能力；SNAT集中提供数据中心的公网访问服务，通过集群化部署，保证出网服务的高性能与高可用。 CDN规划和建设 CDN工作划分为第三方和自建两部分。建立第三方CDN的选型和调度控制；根据业务发展趋势，规划CDN新节点建设布局；完善CDN业务及监控，保障CDN系统稳定、高效运行；分析业务加速频道的文件特性和数量，制定最优的加速策略和资源匹配；负责用户劫持等CDN日常故障排查工作。 服务器选型、交付和维护 负责服务器的测试选型，包含服务器整机、部件的基础性测试
和业务测试，降低整机功率，提升机架部署密度等。结合对公司业务的了解，推广新硬件、新方案减少业务的服务器投入规模。负责服务器硬件故障的诊断定位，服务器硬件监控、健康检查工具的开发和维护。 OS、内核选型和OS相关维护工作 责整体平台的OS选型、定制和内核优化，以及Patch的更新和内部版本发布；建立基础的YUM包管理和分发中心，提供常用包版本库；跟进日常各类OS相关故障；针对不同的业务类型，提供定向的优化支持。 资产管理 记录和管理运维相关的基础物理信息，包括数据中心、网络、机柜、服务器、ACL、IP等各种资源信息，制定有效的流程，确保信息的准确性；开放API接口，为自动化运维提供数据支持。 基础服务建设 业务对DNS、NTP、SYSLOG等基础服务的依赖非常高，需要设计高可用架构避免单点，提供稳定的基础服务。
云计算数据中心与智慧城市建设 导读：云计算是一种基于网络的支持异构设施和资源流转的服务供给模型，它提供给客户可自治的服务。云计算支持异构的基础资源和异构的多任务体系，可以实现资源的按需分配、按量计费，达到按需索取的目标，最终促进资源规模化，促使分工专业化，有利于降低单位资源成本，促进网络业务创新。 一、前言 云计算是一种基于网络的支持异构设施和资源流转的服务供给模型，它提供给客户可自治的服务。云计算支持异构的基础资源和异构的多任务体系，可以实现资源的按需分配、按量计费，达到按需索取的目标，最终促进资源规模化，促使分工专业化，有利于降低单位资源成本，促进网络业务创新。 智慧城市是以多应用、多行业、复杂系统组成的综合体。多个应用系统之间存在信息共享、交互的需求。各个不同的应用系统需要共同抽取数据综合计算和呈现综合结果。如此众多繁复的系统需要多个强大的信息处理中心进行各种信息的处理。 要从根本上支撑庞大系统的安全运行，需要考虑基于云计算的网络架构，建设智慧城市云计算数据中心。在满足上述需求的同时，云计算数据中心具备传统数据中心、单应用系统建设无法比拟的优势：
随需应变的动态伸缩能力（基于云计算基础架构平台，动态添加应用系统）以及极高的性能投资比（相对传统的数据中心，硬件投资至少下降30％以上）。 二、云计算应用于智慧城市的优势 （一）平台层的统一和高效能 通过架构即服务（Iaas）的构建模式，将传统数据中心不同架构、不同品牌、不同型号的服务器进行整合，通过云操作系统的调度，向应用系统提供一个统一的运行支撑平台。 同时，借助于云计算平台的虚拟化基础架构，可以有效地进行资源切割、资源调配和资源整合，按照应用需求来合理分配计算能力和存储资源，实现效能最优化。 （二）大规模基础软硬件管理 基础软硬件管理，主要负责大规模基础软件、硬件资源的监控和管理，为云计算中心操作系统的资源调度等高级应用提供决策信息，是云计算中心操作系统资源管理的基础。基础软件资源，包括单机操作系统、中间件、数据库等。基础硬件资源，则包括网络环境下的三大主要设备：计算（服务器）、存储（存储设备）和网络（交换机、路由器等设备）。基础软硬件管理中心，可以对基础软件、硬件资源进行资产管理；可以实现基础硬件的状态监控和性能监控；能够对异常情况触发报警，提醒用户及时维护问题设备；能够对基础软硬件资
云计算数据中心运维管理要点 在数据中心生命周期中，数据中心运维管理是数据中心生命周期中最后一个、也是历时最长的一个阶段。数据中心运维管理就是：为提供符合要求的信息系统服务，而对与该信息系统服务有关的数据中心各项管理对象进行系统的计划、组织、协调与控制，是信息系统服务有关各项管理工作的总称。数据中心运维管理主要肩负起以下重要目标：合规性、可用性、经济性、服务性等四大目标。 由于云计算的要求弹性、灵活快速扩展、降低运维成本、自动化资源监控、多租户环境等特性除基于ITIL的常规数据中心运维管理理念之外，以下运维管理方面的内容，也需要我们加以重点分析和关注。 一、理清云计算数据中心的运维对象 数据中心的运维管理指的是与数据中心信息服务相关的管理工作的总称。云计算数据中心运维对象共可分成5类： (1) 机房环境基础设施部分。这里主要指为保障数据中心所管理设备正常运行所必需的网络通信、电力资源、环境资源等。这部分设备对于用户来说几乎是透明的，因为大多数用户基本并不会关注到数据中心的风火水电。但是，这类设备如发生意外，对依托于该基础设施的应用来说，却是致命的。 (2) 在提供IT服务过程中所应用的各种设备，包括存储、服务器、网络设备、安全设备等硬件资源。这类设备在向用户提供IT服务过程中提供了计算、存储与通信等功能，是IT服务最直接的物理载体。 (3) 系统与数据，包括操作系统、数据库、中间件、应用程序等软件资源;还有业务数据、配置文件、日志等各类数据。这类管理对象虽然不像前两类管理对象那样“看得见，摸得着”，但却是IT服务的逻辑载体。 (4) 管理工具，包括了基础设施监控软件、监控软件、工作流管理平台、报表平台、短信平台等。这类管理对象是帮助管理主体更高效地管理数据中心内各种管理对象，并在管理活动中承担起部分管理功能的软硬件设施。通过这些工具，可以直观感受并考证到数据中心如何管理好与其直接相关的资源，从而间接地提升的可用性与可靠性。 (5) 人员，包括了数据中心的技术人员、运维人员、管理人员以及提供服务的厂商人员。人员一方面作为管理的主体负责管理数据中心运维对象，另一方面也作为管理的对象，支持IT的运行。这类对象与其他运维对象不同，具有很强的主观能动性，其管理的好坏将直接影响到整个运维管理体系，而不仅仅是运维对象本身。
云计算中心运维管 理制度
云计算中心运维管理制度 在数据中心生命周期中，数据中心运维管理是数据中心生命周期中最后一个、也是历时最长的一个阶段。数据中心运维管理就是：为提供符合要求的信息系统服务，而对与该信息系统服务有关的数据中心各项管理对象进行系统的计划、组织、协调与控制，是信息系统服务有关各项管理工作的总称。数据中心运维管理主要肩负起以下重要目标：合规性、可用性、经济性、服务性等四大目标。 由于云计算的要求弹性、灵活快速扩展、降低运维成本、自动化资源监控、多租户环境等特性除基于ITIL的常规数据中心运维管理理念之外，以下运维管理方面的内容，也需要我们加以重点分析和关注。 一、理清云计算数据中心的运维对象 数据中心的运维管理指的是与数据中心信息服务相关的管理工作的总称。云计算数据中心运维对象共可分成5类： (1) 机房环境基础设施部分。这里主要指为保障数据中心所管理设备正常运行所必须的网络通信、电力资源、环境资源等。这部分设备对于用户来说几乎是透明的，因为大多数用户基本并不会关注到数据中心的风火水电。可是，这类设备如发生意外，对依托于该基础设施的应用来说，却是致命的。 (2) 在提供IT服务过程中所应用的各种设备，包括存储、服务器、网络设备、安全设备等硬件资源。这类设备在向用户提供IT
服务过程中提供了计算、存储与通信等功能，是IT服务最直接的物理载体。 (3) 系统与数据，包括操作系统、数据库、中间件、应用程序等软件资源;还有业务数据、配置文件、日志等各类数据。这类管理对象虽然不像前两类管理对象那样“看得见，摸得着”，但却是IT服务的逻辑载体。 (4) 管理工具，包括了基础设施监控软件、监控软件、工作流管理平台、报表平台、短信平台等。这类管理对象是帮助管理主体更高效地管理数据中心内各种管理对象，并在管理活动中承担起部分管理功能的软硬件设施。经过这些工具，能够直观感受并考证到数据中心如何管理好与其直接相关的资源，从而间接地提升的可用性与可靠性。 (5) 人员，包括了数据中心的技术人员、运维人员、管理人员以及提供服务的厂商人员。人员一方面作为管理的主体负责管理数据中心运维对象，另一方面也作为管理的对象，支持IT的运行。这类对象与其它运维对象不同，具有很强的主观能动性，其管理的好坏将直接影响到整个运维管理体系，而不但仅是运维对象本身。 二、定义各运维对象的运维内容 云计算数据中心资源管理所涵盖的范围很广，包括环境管理、网络管理、设备管理、软件管理、存储介质管理、防病毒管理、应用管理、日常操作管理、用户密码管理和员工管理等。要对每一