虽然ES提供了replicas shards的机制来保证数据的完整性不会因为几个节点的奔溃而被破坏，但是定期的数据备份以备不时之需依然重要。此外，通过备份与恢复也可实现数据在不同集群间的迁移（直接复制data目录下的索引文件的做法我尝试过，但没有成功）。
 
备份的方式在官方文档里有清楚的交代：先创建仓库(repository)，再往仓库里添加一个快照(snapshot)，查看备份状态，搞定。虽然官方文档很轻描淡写，但我在第一步就卡住了，创建仓库时需要一个共享文件系统（每个ES节点都需要能访问），我只是想把数据从线上集群迁移到线下进行更全面的测试，为了这么点事去找系统部走流程等待共享服务器是多么头疼啊……
 
一阵Google之后，决定使用sshfs在ES集群中每个节点的相同位置挂载一个共享目录，以下是操作命令：

// 在每个节点上安装sshfs

yum install fuse sshfs

 

// 选定一个节点的一个目录作为共享目录（不要放在系统盘所在目录）

mkdir /data0/es_backup

 

// 在每个节点的相同位置创建目录，并挂载共享目录

mkdir /mnt/backup

sshfs root@192.168.x.x:/data0/es_backup /mnt/backup -o allow_other

 

// 测试运行ES的用户是否有对共享目录的写权限

sudo -u elasticsearch touch /mnt/backup/test

这里最大的坑是写权限问题，我试过在创建/mnt/backup时把owner改成elasticsearch或者在挂载的时候用-o uid= gid= 这样参数更改目录的owner，然并卵……折腾了一下午。最后总算在Stackoverflow找到了这个参数-o allow_other，但其实这样做比较粗鲁，机器上的任何用户都可以访问这个目录了，有更优雅实现方式的同学请赐教。
 
解决了共享目录的问题之后，就可以像官方文档一样轻描淡写啦：

// 在_plugin/marvel/sense里

 

// 创建仓库

PUT _snapshot/my_backup

{

    "type": "fs", 

    "settings": {

        "location": "/mnt/backup",

        "compress": true

    }

}

 

// 针对具体的index创建快照备份

PUT _snapshot/my_backup/snapshot_test

{

    "indices": "index_1, index_2"

}

 

// 查看备份状态

GET _snapshot/my_backup/snapshot_test/_status

现在可以开始进行迁移了：

// 备份创建好之后，在共享目录/root/backup里是这样的：

-rw-r--r-- 1 root root   31 12月 15 22:14 index

drwxr-xr-x 3 root root 4096 12月 15 22:14 indices

-rw-r--r-- 1 root root   83 12月 15 22:14 metadata-snapshot_test

-rw-r--r-- 1 root root  181 12月 15 22:14 snapshot-snapshot_test

 

// 在迁移目标的集群上重复上面创建仓库的操作

 

// 将源集群的备份内容（/root/backup里的所有文件），复制到迁移目标的集群仓库目录里

 

// 在sense中使用RESTful API进行备份的恢复

POST _snapshot/my_backup/snapshot_test/_restore

 

// 查看恢复的状态

GET _snapshot/my_backup/snapshot_test/_status

以上就是参照官方文档实施的ES数据备份与迁移，希望对大家有帮助，欢迎留言与交流。

分享阅读原文：http://logos.name/archives/515

TCP(Transmission Control Protocol)传输控制协议

TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接:

位码即tcp标志位,有6种标示:SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)

Sequence number(顺序号码) Acknowledge number(确认号码)

[]第一次握手：主机A发送位码为syn＝1,随机产生seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机；[/][]第二次握手：主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1),syn=1,ack=1,随机产生seq=7654321的包[/][]第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，主机A会再发送ack number=(主机B的seq+1),ack=1，主机B收到后确认seq值与ack=1则连接建立成功。[/][]完成三次握手，主机A与主机B开始传送数据。[/]

在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。 

[]第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认； [/][]第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器 进入SYN_RECV状态； [/][]第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入 ESTABLISHED状态，完成三次握手。 [/][]完成三次握手，客户端与服务器开始传送数据.[/]

实例

IP 192.168.1.116.3337 > 192.168.1.123.7788: S 3626544836:3626544836IP 192.168.1.123.7788 > 192.168.1.116.3337: S 1739326486:1739326486 ack 3626544837IP 192.168.1.116.3337 > 192.168.1.123.7788: ack 1739326487,ack 1

[]第一次握手：192.168.1.116发送位码syn＝1,随机产生seq number=3626544836的数据包到192.168.1.123,192.168.1.123由SYN=1知道192.168.1.116要求建立联机;[/][]第二次握手：192.168.1.123收到请求后要确认联机信息，向192.168.1.116发送ack number=3626544837,syn=1,ack=1,随机产生seq=1739326486的包;[/][]第三次握手：192.168.1.116收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，192.168.1.116会再发送ack number=1739326487,ack=1，192.168.1.123收到后确认seq=seq+1,ack=1则连接建立成功。[/]

图解

一次三次握手的过程（图1，图2） 第一次握手的标志位（图3）我们可以看到标志位里面只有个同步位，也就是在做请求(SYN) 第二次握手的标志位（图4）我们可以看到标志位里面有个确认位和同步位，也就是在做应答(SYN + ACK) 第三次握手的标志位（图5）我们可以看到标志位里面只有个确认位，也就是再做再次确认(ACK) 一个完整的三次握手也就是 请求---应答---再次确认  四次分手：

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

[]（1）客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送（报文段4）。[/][]（2）服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。[/][]（3）服务器B关闭与客户端A的连接，发送一个FIN给客户端A（报文段6）。[/][]（4）客户端A发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）[/]

状态详解：

CLOSED：这个没什么好说的了，表示初始状态。

LISTEN：这个也是非常容易理解的一个状态，表示服务器端的某个SOCKET处于监听状态，可以接受连接了。

SYN_RCVD： 这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个ACK报文不予发送。因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。

SYN_SENT： 这个状态与SYN_RCVD遥想呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。

ESTABLISHED：这个容易理解了，表示连接已经建立了。

FIN_WAIT_1：这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。

FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。

TIME_WAIT： 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。

CLOSING： 这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。

CLOSE_WAIT： 这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。

LAST_ACK：这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。

总结

Q：为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？

A：这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的.

Q：为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？

A：这是因为虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。

云端框架v1.0Alpha版​

框架引擎

Python 2.7.9 、Cherrypy 3.6.0 、Mako 1.0.1 

本次架构纯属个人兴趣所致，如今开发各类机器人也并非难事，本框架基于最简单的Wechat Http协议所开发 网上关于Wechat的 Web协议分析的资料也不少。这里不再赘述。这套协议分析就很不错web 微信与基于node的微信机器人实现 实现的原理都一样，只过是实现的语言不一样而已，笔者用Node做过基于PCQQ协议的消息互通,简单的写了一个简单的Demo，个人对人工智能比较感兴趣啦~ 由于个人能力有限，工作也比较繁忙，所以就将这个云端框架贡献出来~ 希望有志同道合的同仁一起来维护这个框架。在实际测试中感觉Cherrypy这个框架效率还是蛮低的~后来想用Tornado非阻塞的Python web框架 个人精力有限~~

协议分析

[]WEB协议也就是网页版微信 web 协议有web的好处~嘎嘎我就不说了避免XX00[/][]Android/ios协议 市面上很少见。[/]

PC协议 ...........

[]如何使用 搭建好Python环境安装好对应模块 run CherryWeChatSwever.py 代码写的比较渣渣~啦~ 对于新手熟悉CherryPy框架也是不错想选择~[/]

效果展示

ChangeLog 

开源协议

GPL

项目地址：https://github.com/lu4kyd0y/WeChat-Cloud-Robot

根据如上思维导图，我们来展开对Zookeeper的基本的一些概念解释。

一、集群角色

Leader

Leader服务器是整个Zookeeper集群工作机制中的核心 

Follower

Follower服务器是Zookeeper集群状态的跟随者

Observer

Observer服务器充当一个观察者的角色

Leader，Follower 设计模式；Observer 观察者设计模式

二、会话

会话是指客户端和ZooKeeper服务器的连接，ZooKeeper中的会话叫Session，客户端靠与服务器建立一个TCP的长连接；

来维持一个Session,客户端在启动的时候首先会与服务器建立一个TCP连接，通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能向ZK服务器发送请求并获得响应。

三、数据节点

Zookeeper中的节点有两类：

[]集群中的一台机器称为一个节点[/][]数据模型中的数据单元Znode，分为持久节点和临时节点[/]

 

Zookeeper的数据模型是一棵树,树的节点就是Znode，Znode中可以保存信息。

如下图所示：

ZK大致数据结构跟上图是一致的，如上图所示这个图就像一棵树，这个树有个根节点，然后其下有些子节点，然后每个子节点其下又可以有子节点，大多数的开发就是跟zk的这些数据节点打交道，来读写这些数据节点，来完成任务。

四、版本

ZK中的版本，是用来记录节点数据或者是节点的子节点列表或者是权限信息的修改次数，注意是这里是修改次数。如果一个节点的version是1，那就代表说这个节点从创建以来被修改了一次，那么这个版本怎么用呢，典型的我们可以利用版本来实现分布式的锁服务。我们知道在数据库中，一般有两种锁，一种是悲观锁一种是乐观锁。

悲观锁

悲观锁又叫悲观并发锁，是数据库中一种非常严格的锁策略，具有强烈的排他性，能够避免不同事务对同一数据并发更新造成的数据不一致性，在上一个事务没有完成之前，下一个事务不能访问相同的资源，适合数据更新竞争非常激烈的场景；

乐观锁

相比悲观锁，乐观锁使用的场景会更多，悲观锁认为事务访问相同数据的时候一定会出现相互的干扰，所以简单粗暴的使用排他访问的方式，而乐观锁认为不同事务访问相同资源是很少出现相互干扰的情况，因此在事务处理期间不需要进行并发控制，当然乐观锁也是锁，它还是会有并发的控制！对于数据库我们通常的做法是在每个表中增加一个version版本字段，事务修改数据之前先读出数据，当然版号也顺势读取出来，然后把这个读取出来的版本号加入到更新语句的条件中，比如，读取出来的版本号是1,我们修改数据的语句可以这样写，update 某某表 set 字段一=某某值 where id=1 and version=1，那如果更新失败了说明以后其他事务已经修改过数据了，那系统需要抛出异常给客户端，让客户端自行处理，客户端可以选择重试。

锁，ZK中版本有类式的作用。

ZK的版本类型有三种：version cversion aversion

五、Watcher

Watcher我们可以理解为他是一个事件监听器

ZooKeeper允许用户在指定节点上注册一些Watcher，当数据节点发生变化的时候，ZooKeeper服务器会把这个变化的通知发送给感兴趣的客户端。

两个客户端都在zookeeper集群中注册了watcher（事件监听器），那么当zk中的节点数据发生变化的时候，zk会把这一变化的通知发送给客户端，当客户端收到这个变化通知的时候，它可以再回到zk中，去取得这个数据的详细信息。

六、ACL权限控制

 
ACL是Access Control Lists 的简写， ZooKeeper采用ACL策略来进行权限控制，有以下权限：

[]CREATE: 创建子节点的权限[/][]READ: 获取节点数据和子节点列表的权限[/][]WRITE: 更新节点数据的权限[/][]DELETE: 删除子节点的权限[/][]ADMIN: 设置节点ACL的权限[/]

上面的权限有点类似我们信息系统的权限管理，我们在开发系统的时候一般也会对数据做这些权限管理，一个zk集群可能会服务很多的业务，尤其是一些大公司，zk集群的节点中会保存重要的信息，那么这些信息通常只能对一部分的访问者开放，通过acl我们可以对某些节点的访问进行授权，从而来保证数据的安全。

顾客就是上帝

传统的行业IT架构实现“云”化的过程多是基于现有业务系统采用为虚拟化，并辅之以资源池化等措施，渐渐构建为一个完整的私有云系统。由于各行业的业务系统差异较大，私有云落地过程中总会遇到这样那样的问题。作为一个技术人，将从私有云在典型行业的典型部门中落地的过程中，简述厂商在虚拟化方面很有可能遇到的痛点。

政务

政企中的桌面按职能划分包括办公、财务等，而这些正是桌面云的期望场景。加之目前国内政企在一些关键项目上非常乐意采用国内虚拟化产品，这也就给国内的IT厂商带来了机遇。

场景分析：

政企中的私有云，尤其是虚拟化部分近些年来一直在进行尝试性地推广。下面我以需求最直接的桌面云进行叙述。

用户桌面：

面向办公的桌面，一般需求为Mircosoft Office、邮件处理等文字密集型软件；通信类软件一般为国内厂商开发的非广域网通信软件以及QQ；防病毒软件种类比较多，目前卡巴斯基、诺顿等占 多，360使用较少；影音类软件使用局限于网页flash，或者国内厂商定制的流媒体客户端。

对于财务桌面，需求除普通办公桌面外也有一些财务类软件，而这些软件对桌面负荷较普通办公桌面会高出一定量的资源消耗，同时也会有U-Key、指纹 仪等终端设备，所以对于这类桌面，我们一般进行特殊设置，比如将其固定到某台服务器上运行，并赋予一定优先级，保证资源优先分配。

在普通桌面与财务桌面以外，也有浮动桌面可供出差人员或者来访人员临时使用，此种桌面与一般办公桌面无异，但可能要求有严格的用户检查控制以及无状态模式要求，防止恶意使用导致损失。

系统维护：

政企中的网络管理人员一般为具有一定计算机水平的专业人士，并且他们在部门里推广办公桌面的时候起着很重要的作用。所以我们首先获得他们对产品的认可，解决他们在现有架构中遇到的管理困难。 不管在哪种场景中，管理人员对产品的认可，都是产品价值的体现之一 。

安全保障：

政务IT系统中的安全模块在系统的每个层次里都有体现，包括桌面、网络、交换设备、服务器、操作系统等，同时也可能会与其他基础设备连接，每个模块 相对独立又保持联系。一般在涉及安全的场景中，我们会采取服务端镜像加密和其他一系列的安全保障工作，兼顾性能和安全的同时保证桌面体验，这点在以后的章 节中会有所阐述。

虚拟化融合架构：

物理机与虚拟机同时提供服务的模式已经不是什么新东西了，早些年就已经有一大批使用虚拟服务器的政企客户，但涉及的产品基本以国外产品为主。随着国 产化的一系列强制措施和美国对华的服务器CPU的禁售，国产品牌才开始崭露头角。在一些服务器消耗量比较大的政企客户中，也渐渐地在周边业务系统上使用国 产虚拟化产品。我相信在未来几年内，国内虚拟化厂商会在政务云的服务器虚拟化中会占有很大比例，并且是不可替代的重要组成。

痛点----->文件监控：

谈政务云，多数标书中都会提到的一点就是文件监控。一般虚拟化厂商在这方面积累较少，使用fs-notify去开发有一定开发量，所以多数人会使用 第三方产品进行集成。国内常用的文件监控方法即使用Windows文件系统事件通知机制，软件相对比较成熟，在此我就不一一推荐了。那么，既然有现成的 解决方案，那么我为什么要把它列为虚拟化软件的痛点呢？

从我的使用经验来看，主要有以下原因：

技术方面：此类软件一般不止监控文件读写、目录读写、重命名、拷贝，同时也会进行磁盘扫描，而这点，对于用于桌面云的增量磁盘来说是比较高的IOPS负载。对于一台12盘位的15K SAS机械硬盘存储设备，最多能扛住40到70台虚拟机同时扫描（数据来自某国产存储）。

销售方面：标书中有时会提到“上述功能需来自同一厂商提供”，这就需要虚拟化厂商有一定实力，传统监控软件厂商才会与之合作为其定制，而这点对于现 在雨后春笋般的虚拟化厂商而言，正是痛处——目前国内各家虚拟化系统差异化严重，导致传统厂商为虚拟化定制的成本相对会比较高，而不愿意为国内中小厂商定 制了。目前这一状况随着国内市场的虚拟化推进正有所改善。

痛点----->权限管理：

政务中的权限管理包括：虚拟机控制权限管理、桌面软件安装权限管理、文件权限管理，对于开源虚拟化厂商而言，只有虚拟机控制权限自己可以控制，桌面 软件安装权限管理可以借助Windows AD来进行管理，当然需要一定开发量，而较细颗粒的文件权限管理则一样需要借助第三方。

同文件监控一样，但是它一般不会进行后台文件扫描，但技术上要求是要和虚拟化紧耦合的状态，用某次客户交流的原话，“你最好界面里有一个控制台，我可以看到虚拟机里的Word文档，同时我也可以控制哪些人访问哪些文件”

目前来说，这类权限管理软件可以配合集中/分布式存储软件（云存储），一般虚拟化厂商要在开源云存储的基础上进行大量修改才能达到国内政企客户的基本要求。目前国内有许多私有网盘厂商做的都不错，但是比较缺少它们和虚拟化厂商深度合作的案例。

总结：

政务私有桌面项目中，对桌面“虚拟化”的概念不是很有需求，除非有特别文件下发，即使下发后，客户还是倾向于按照传统的那一套路来。如果要在这个行业中产生影响，建议与传统软件厂商合作，一起发力。

教育

教育行业是目前国内大多数虚拟化厂商都在发力的市场，而这方面做的比较好的厂商有两类。一类是专注教育行业数十年乃至更长的传统软件厂商，他们拥有难以复制的经验，其私有云产品往往会弱化“虚拟化”概念，有强烈的“传统”色彩；还有就是专注教育行业的新厂商，他们的对教育行业的需求定位是从私有云的特性考虑，在解决问题的同时也能够将新理念传达至客户。

学校对于虚拟桌面的需求近几年开始增长，教学机房、服务器机房、教师电脑等都有虚拟化产品的进入。而他们在虚拟化产品的采购上，关心桌面体验与服务器性能的同时，也比较在乎“成本”的问题。

场景分析：
通用教学云模型 

用户桌面：

学校中使用的桌面，一般可分为教师办公桌面和机房教学桌面。

教师桌面即普通办公桌面，主要用途即为老师提供日常办公软件，一般无特殊要求。

对于机房教学桌面，有安装软件繁多、使用时间固定、并发量大等特点，比较考验虚拟化产品的综合素质。桌面安装软件除日常办公软件外，也包括各种文字、图形密集类教学软件，同时也可能会安装影音广播教学类软件。无特殊要求外，很少安装杀毒软件。

系统管理：

对于机房教学桌面，有安装软件繁多、使用时间固定、并发量大等特点，比较考验虚拟化产品的综合素质。桌面安装软件除日常办公软件外，也包括各种文字、图形密集类教学软件，同时也可能会安装影音广播教学类软件。无特殊要求外，很少安装杀毒软件。

安全保障：

教学环境中的安全要求一般比较低，除了常见的流量安全管理软件外，很少有桌面级监控软件。每个老师的桌面一般由管理员定期提醒查杀，主要维护工作还是由各个老师来做。

痛点----->多媒体教学：

那么对于进入教育行业的国内虚拟化厂商，可能都会遇到一个新旧交替环境中必须面对的问题——多媒体广播教学。

传统教学机房使用多媒体广播卡或者广播教学软件来进行教学。多媒体广播卡即是在学生机、教师机上安装的硬件，广播时将教师端桌面转化后直接覆盖学生机的VGA信号，此时使用虚拟桌面并不影响广播体验，但是采用纯软件的多媒体教学系统时情况就有所不同了。这类软件进行视频广播时，默认会利用本地显卡的硬解能力，而一般虚拟化产品中并没有符合要求的模拟GPU硬件支持，所以会带来体验上的硬伤。不过比较喜人的是，这些厂商已经意识到这个问题，开始在其广播教学软件中加入了软解选项从而改善体验。

还有就是在语音质量要求比较高的教学环境中，虚拟化厂商有时也会遭遇意外。语音质量的好坏，除了网络环境外，教学软件、虚拟化软件也有一定影响。在某次测试项目中，公司网络环境下的虚拟桌面语音很流畅、延迟极低，但是到客户机房后，就出现了杂音，声音小等问题。后来我们尝试优化协议、简化虚拟桌面网络拓扑，然后才取得令人满意的效果；

多说一点，在呼叫中心（VoIP、传统PBX）这种语音传输质量要求极高的场景中，有时必须特定硬件配合才能完成虚拟桌面中语音的流畅。

痛点----->3D教学：

对于设计专业、工科专业来说，3D设计、3D模拟、3D建模都是很平常的科目，而这类软件采用学生机本地独显能很好地处理，但是到了虚拟化产品中就是整个开源虚拟化头疼的问题了。一般这种情况下，开源软件从技术上的处理方法可能不如闭源软件（Citrix、PCoIP、RDP RemoteFX）来的稳妥。

由于它涉及到桌面协议、模拟器、GPU等相关知识，所以其开发难度较大，国内私有云厂商在未与GPU提供商合作的前提下很难在点有所突破。

常见设计类软件比如Adobe Fireworks，在虚拟桌面中我们将“显示渲染”设置为“软件”，能够比较流畅的拖动、显示模型，但是此时会占用大量带宽，原生Spice协议此时甚至维持在20MBps，对于拥有几十台教学机的机房而言这点是不可接受的。另一种妥协的解决方式是采用RDP，带宽能降到10MBps，但是使用场景就被大大限制了。

目前，国内这些3D教学类的项目，采用Citrix的多于VMWare，也有人使用Hyper-V，而极少有国内厂商提供KVM虚拟化的方案。我曾在KVM下的GPU虚拟化以及流媒体桌面协议有所尝试。

总结：

目前国内教育行业虚拟化前景广阔，但是伴随着现有kvm虚拟化的一些弱点以及人们面对虚拟桌面教学的担心，厂商在全面推广虚拟桌面的道路上走的比较艰辛。比较令人欣慰的是国内已经有大规模并发虚拟桌面的实例了，这点我相信会是一个很好的开端。

银行

目前国内教育行业虚拟化前景广阔，但是伴随着现有kvm虚拟化的一些弱点以及人们面对虚拟桌面教学的担心，厂商在全面推广虚拟桌面的道路上走的比较艰辛。比较令人欣慰的是国内已经有大规模并发虚拟桌面的实例了，这点我相信会是一个很好的开端。

场景分析：

私有云在银行中目前在研发中心、服务集群、营业网点中都有应用，由于笔者经验有限，在此我们进行的讨论仅限于柜台虚拟桌面。

银行中现阶段核心业务由于历史原因，仍有相当部分的小型机在运行，x86服务器份额也在逐渐提高，并且慢慢取代小机成为核心业务承载。由于银行IT的特殊要求，他们使用虚拟化的步伐比较缓慢，一般在其研发机构或者网点柜台中使用较多。

用户桌面：

柜台桌面功能较为单一，从早期的DOS系统到现在的Win7桌面，柜员也只限于在上面查询、办理业务。所需软件除Office以为，也有一部分本行开发的软件与指定的杀毒软件。对于外设，常见的有高清摄像头、POS设备、读卡设备等。

系统维护：

柜台桌面一般会要求还原模式的桌面，大型网点部署在网点内部，小型网点部署在机房，由IT部门定期维护，系统一旦部署完成之后维护量较少。他们对于虚拟化的要求既是性能和功能只要满足，界面上复杂一些也能接受。

痛点----->外设接入：

那么问题来了，银行柜员桌面的外接设备繁多，除USB口以外也有串口、并口等设备。这些对于物理机来说都很轻松，但是到了虚拟机以后，就会出现这样那样的问题。

读者于此可能会问，外接设备多对于技术上来说只是个协议转发的问题，有什么痛处呢？笔者总结有如下原因：

设备接入到虚拟机以后，数据传输所需的额外带宽可能会对柜员机的其他业务产生影响，降低实时性，但是如果将可压缩数据进行无损压缩，对服务器和客户端又带来一定压力，需要较高性能的服务器与客户的才能保证实时性，势必又会导致虚拟化成本的上升。

由于设备与接口繁多，一般的虚拟化厂商需要投入很大一部分物力与财力，甚至要开发专门的硬件设备来进行设备的重定向操作。很多设备尽管接口相同，但经过重定向以后仍然会出现不可识别的情况，需要厂商到现场进行测试甚至开发。

正因为以上两点综合技术因素，现在众多虚拟化厂商谈到银行外设时仍谈虎色变。
痛点----->高实时性：

影响柜台桌面实时性要求的主要因素有两个，一个是客户端到桌面的连接，另一个是桌面到业务系统的连接。

一般由于虚拟桌面是由IT部门直接部署在离业务系统逻辑位置较近的地方，其网络质量较高，可以保证桌面到业务系统的延迟满足要求。但是客户端到桌面的网络是使用银行专有网络，网点到机房的带宽有限，并发高了以后网络拥堵所造成的延迟甚至丢包都会出现。

总结：

银行业相较于其他行业，其IT技术既先进又保守，而虚拟化产品除VMWare老牌厂商或者有行业背景的厂商外，他们的IT部门或多或少的有一定排斥心理。虽然银行客户交涉难度较大，但是如果成功以后就会树立很良好的产品及企业形象，所以，请努力。

根据如上思维导图，我来展开对Zookeeper的介绍

一、Zookeeper背景

随着互联网技术的高速发展，企业对计算机系统的计算、存储能力要求越来越高，最简单的证明就是出现了一些诸如：高并发，海量存储这样的词汇。在这样的背景下，单纯依靠少量高性能主机来完成计算任务也就不能满足现有大部分企业的需求了，企业的IT架构逐步从集中式向分布式过度，所谓的分布式是指：把一个计算任务分解成若干个计算单元，并且分配到若干不同的计算机中去执行，然后汇总计算结果的过程。

这好比公司里面的某个团队，接到公司派发的任务，首先团队的主管，要把任务进行拆分，然后安排下去，划分给团队中不同的人去完成，并随时跟进任务的进展。如果团队主管离职了，那我们可能就会在团队中挑选一个对业务比较熟悉的人来接管主管位置。最后各个组员把任务完成，主管进行汇总，并上报给公司。在团队内部需要制定多个工作流程，来保证工作的有序开展。在分布式系统中同样需要设置这么一个协作规范。zookeeper可以很好的帮助我们来实现这个目的。

二、Zookeeper是什么？

ZooKeeper是一个开放源码的分布式协调服务，由知名互联网公司雅虎创建，是基于Google Chubby开源实现。（Google chubby是google公司开源的一个锁服务。）

ZooKeeper是一个高性能的分布式数据一致性解决方案，它将那些复杂的、容易出错的分布式一致性服务封装起来了，构成了一个高效可靠的源语集，并提供一系列简单易用的接口给用户。

ZooKeeper致力于提供一个高性能、高可用、且具有严格的顺序访问控制能力的分布式协调服务。分布式应用可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知，集群管理、Master 选举、分布式锁和分布式队列等功能。

Zookeeper知识点：
1、源代码开放

开源意味着我们可以免费的获取和使用zk，并且可以深入研究zk的源代码，甚至可以根据自己业务特性和要求进行二次开发修改。

2、是分布式协调服务，它解决分布式数据一致性问题
A、顺序一致性

所谓的顺序一致性是指从一个客户端发起一个请求，最终会严格按照发起的顺序应用到zk中。

B、原子性

原子性是指所有事物请求的处理结果在整个集群的所有机器上的应用情况是一致的。

C、单一视图

单一视图是指无任客户端连接到哪个zk的服务器，它看到的服务端数据都是一致的。

D、可靠性

可靠性是指一旦服务端成功的应用了一个事物并完成了对客户端的响应，那么这个事物所引起的服务端状态的变更会一直保留下来，除非有另外一个事物又对它进行了修改。

E、实时性

实时性是指zk保证在一段时间内客户端一定能从服务端读取最新的数据状态。

3、高性能

zk具有很高的吞吐量，一个三台服务器的集群可以达到12w-13w的QPS。

4、我们可以通过调用zk提供的接口解决一些分布式易用中的实际问题。

三、Zookeeper的典型应用场景

Zookeeper包括但不限于如下应用场景
 
3.1、数据发布/订阅

顾名思义就是一方把数据发布出来，另一方通过某种方式可以得到这些数据;

通常数据订阅有两种方式：推送模式和拉取模式

推送模式一般是服务器主动向客户端推送信息， 拉取模式是客户端主动去服务器获取数据（通常是采用定时轮询的方式），ZK采用两种方式相结合;

发布者将数据发布到ZK集群节点上，订阅者通过一定的方法告诉服务器，我对哪个节点的数据感兴趣，那服务器在这些节点的数据发生变化时，就通知客户端，客户端得到通知后可以去服务器获取数据信息。

3.2、负载均衡

实现过程：

1、首先DB在启动的时候先把自己在ZK上注册成一个临时节点，ZK的节点后面我们会讲到有两种，一种是永久节点，一类是临时节点临时节点在服务器出现问题的时候，节点会自动的从ZK上删除，那么这样ZK上的服务器列表就是最新的可用的列表。

2、客户端在需要读写数据库的时候首先它去ZooKeeper得到所有可用的DB的连接信息（一张列表），得到可用的数据列表。

3、客户端随机的算法，随机选择一个与之建立连接，每次会跟不同的数据库连接，就达到简单的复杂均衡。

4、当客户端发现连接不可用的时候可再次从ZK上获取可用的DB连接信息，当然也可以在刚获取的那个列表里移除掉不可用的连接后再随机选择一个DB与之连接。

3.3、命名服务

顾名思义，就是提供名称的服务，例如数据库表格ID，一般用得比较多的有两种ID，一种是自动增长的ID，一种是UUID(9291d71a-0354-4d8e-acd8-64f7393c64ae)，两种ID各自都有缺陷，自动增长的ID局限在单库单表中使用，不能在分布式中使用，UUID可以在分布式中使用但是由于ID没有规律难于理解，我们可以借用ZK来生成一个顺序增长的，可以在集群环境下使用的，命名易于理解的ID。

3.4、分布式协调/通知

心跳检测，在分布式系统中，我们常常需要知道某个机器是否可用，传统的开发中，可以通过Ping某个主机来实现，Ping得通说明对方是可用的，相反是不可用的；

ZK中我们让所有的机其都注册一个临时节点，我们判断一个机器是否可用，我们只需要判断这个节点在ZK中是否存在就可以了，不需要直接去连接需要检查的机器 ，降低系统的复杂度。

四、Zookeeper的优势

[]源代码开放[/][]已经被证实是高性能，易用稳定的工业级产品。[/][]有着广泛的应用：Hadoop,HBase,Storm,Solr。[/]

转载请注明来自开源技术社区 : http://openskill.cn/article/281

一般类提示

eth1: Too much work at interrupt, IntrStatus=0x0001

这条提示的含意为. 某网卡的中断请求过多. 如果只是偶尔出现一次可忽略. 但这条提示如果经常出现或是集中出现,那涉及到的可能性就比较多有可能需要进行处理了. 可能性比较多,如网卡性能;服务器性能;网络攻击..等等.

IPVS: incoming ICMP: failed checksum from 61.172.0.X!

服务器收到了一个校验和错误的ICMP数据包. 这类的数据包有可能是非法产生的垃圾数据.但从目前来看服务器收到这样的数据非常多.一般都忽略.
一般代理服务器在工作时会每秒钟转发几千个数据包.收到几个错误数据包不会影响正常的工作.
这是问我最多的一类提示了.

NET: N messages suppressed.  or  __ratelimit: N messages suppressed。

服务器忽略了 N 个数据包.和上一条提示类似.服务器收到的数据包被认为是无用的垃圾数据数据. 这类数据多是由攻击类的程序产生的.
这条提示如果 N 比较小的时候可以忽略.但如果经常或是长时间出现3位数据以上的这类提示.就很有可能是服务器受到了垃圾数据类的带宽攻击了.


UDP: bad checksum. From 221.200.X.X:50279 to 218.62.X.X:1155 ulen 24 
UDP: short packet: 218.2.X.X:3072 3640/217 to 222.168.X.X:57596
218.26.131.X sent an invalid ICMP type 3, code 13 error to a broadcast: 0.1.0.4 on eth0

服务器收到了一个错误的数据包.分别为 UDP校验和错误; 过短的UDP数据包; 一个错误的ICMP类型数据. 这类信息一般情况下也是非法产生的.
但一般问题不大可直接忽略.


kernel: conntrack_ftp: partial 227 2205426703+13
FTP_NAT: partial packet 2635716056/20 in 2635716048/2635716075

服务器在维持一条FTP协议的连接时出错. 这样的提示一般都可以直接忽略.


eth1: Promiscuous mode enabled. 
device eth1 entered promiscuous mode
device eth1 left promiscuous mode

这几行提示指. 某块网卡进入(离开)了混杂模式. 一般来说混杂模式是当需要对通信进行抓包时才用到的. 当使用维护或故障分析时会使用到(比如consoletools中的countflow命令). 正常产生的这类提示可以忽略.
如果在前台和远端都没有进行维护时出现这个提示倒是应该引起注意,但这种可能性不大.


基本无关

keyboard: unknown scancode e0 5e

键盘上接收到未定义的键值. 如果经常出现.有可能是键盘有问题. linux对于比较特殊的键或是组合键,有时也会出这样的提示.
要看一下服务器的键盘是不是被压住了. 其它情况一般忽略.


 uses obsolete (PF_INET,SOCK_PACKET)

系统内核调用了一部分功能模块,在第一次调入时会出现. 一般情况与使用调试工具有关. 可直接忽略.

 

报警程序的提示 

0001 WMPCheckV001 2005-04-13_10:10:01 Found .(ARP Spoofing sniffer)! IP:183 MAC:5
0002 WMPCheckV001 2005-04-07_01:53:32 Found .(MAC_incomplete)! IP:173 mac_incomplete:186
0003 WMPCheckV001 2005-04-17_16:25:11 Found .(HIGH_synsent)! totl:4271 SynSent:3490
0004 WMPCheckV001 20......

这是由报警程序所引起的提示. 详细的信息需要用报警程序的客户端进行实时接收.

网络通信故障

Neighbour table overflow.

出现这个提示.一般都是因为局域网内有部分计算机被病毒感染. 情况严重时会影响通信. 必须处理内部网通信不正常的计算机.


eth1: Transmit error, Tx status register 82.
Probably a duplex mismatch. See Documentation/networking/vortex.txt
Flags; bus-master 1, dirty 9994190(14) current 9994190(14)
Transmit list 00000000 vs. f7171580.
0: @f7171200 length 800001e6 status 000101e6
1: @f7171240 length 8000008c status 0001008c
.... 

这个提示是3com网卡特有的. 感觉如果出现量不大的话也不会影响很严重. 目前看维一的解决办法是更换服务器上的网卡. 实在感觉3com的网卡有些问题...


网络通信严重问题! 

NETDEV WATCHDOG: eth1: transmit timed out
eth1: link down
eth1: link up, 10Mbps, half-duplex, lpa 0x0000
eth2: link up, 100Mbps, full-duplex, lpa 0x41E1
setting full-duplex based on MII #24 link partner capability of 45e1

这些提示是网络通信中出现严重问题时才会出现. 故障基本和网络断线有关系. 这几条提示分别代表的含意是 某块网卡传送数据超时; 网卡连接down; 网卡连接up,连接速率为10/100Mbps,全/半双功.
这里写到的最后三行的提示比较类似. 出现这类提示时必须注意网络连接状况进行处理!!!


NIC Link is Up 100 Mbps Full Duplex

情况和 kernel: eth1: link up,...相同.指某块网卡适应的连接速率. 一般认为没有说明哪个网卡down,只是连续出现网卡适应速率也是通信有问题.
如果是网线正常的断接可以忽略这类的信息.


eth0: Transmit timed out, status 0000, PHY status 786d, resetting...
eth0: Reset not complete yet. Trying harder.

第一条提示 网卡关送数据失败. 复位网卡. 第二条提示 网卡复位不成功.... 这些提示都属于严重的通信问题.


服务器系统严重故障

CPU0: Temperature above threshold
CPU0: Running in modulated clock mode

服务器CPU工作温度过高. 必须排除硬件故障.


I/O error, dev hda, sector N
I/O error, dev sda, sector N
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=811562, sector=811560

服务器系统磁盘存储卡操作失败. 这样的问题一般不会使服务器直接停止工作, 但会引起很多严重问题.

收到告警邮件，监控一台java web服务器的端口链接超时，登录到服务器上查看/var/log/message log如下：

Feb 27 22:32:01 java_web1 kernel: TCP: time wait bucket table overflow

Feb 27 22:32:01 java_web1 kernel: TCP: time wait bucket table overflow

Feb 27 22:32:01 java_web1 kernel: TCP: time wait bucket table overflow

Feb 27 22:32:01 java_web1 kernel: TCP: time wait bucket table overflow

Feb 27 22:32:01 java_web1 kernel: TCP: time wait bucket table overflow

Feb 27 22:32:01 java_web1 kernel: TCP: time wait bucket table overflow

Feb 27 22:32:01 java_web1 kernel: TCP: time wait bucket table overflow

Feb 27 22:32:02 java_web1 kernel: TCP: time wait bucket table overflow

Feb 27 22:32:02 java_web1 kernel: TCP: time wait bucket table overflow

 服务器的TCP连接数，超出了内核定义最大数。
 
查看设置的参数：

[root@java_web1 ~]# cat  /proc/sys/net/ipv4/tcp_max_tw_buckets

5000

才5千，用ss -tan state time-wait | wc -l命令查看，已经有4500多的time-wait链接。
 
解决方法：
修改内核参数 /proc/sys/net/ipv4/tcp_max_tw_buckets

# echo 30000 > /proc/sys/net/ipv4/tcp_max_tw_buckets

写入/etc/sysctl.conf使之永久生效

echo 'net.ipv4.tcp_max_tw_buckets = 30000' >> /etc/sysctl.conf && sysctl -p

转载请注明来自开源技术社区 : http://openskill.cn/article/279

1. 查看系统内核版本​

[root@funsion geekxa]# cat /etc/issue

CentOS release 6.5 (Final)

Kernel \r on an \m

显示了系统名称(CentOS)和内核版本（release 6.5）
The file /etc/issue is a text file which contains a message or system identification to be printed before the login prompt. 
 
2. 查看系统信息

flyhup@ubuntu:~$ uname -a

Linux ubuntu 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:18:00 UTC 2015 i686 i686 i686 GNU/Linux

uname -a ：显示系统名、节点名称、操作系统的发行版号、操作系统版本、运行系统的机器 ID 号
 
3. 查看磁盘空间占用情况

$df -hl

Filesystem            Size  Used Avail Use% Mounted on

/dev/xvda1            100G  5.0G   90G   6% /

tmpfs                 1.9G  104K  1.9G   1% /dev/shm

参数：

[]-h:方便阅读[/][]-a：全部文件系统列表[/]

4. 查看内存一、free命令

root@xen_202_12 /]# free -m             total       used       free     shared    buffers     cachedMem:          3072       2459        612          0        207       1803-/+ buffers/cache:        447       2624Swap:         1913          0       1913

第2行:

[]otal 内存总数: 3072【注意单位是M，可以用参数-hm更醒目】[/][]used 已经使用的内存数: 2459[/][]free 空闲的内存数: 612[/][]shared 当前已经废弃不用，总是0[/][]buffers: Buffer Cache内存数: 207[/][]cached: Page Cache内存数: 2803[/][]关系：total = used + free[/]

 第3行:

[]-/+ buffers/cache的意思:[/][]-buffers/cache 的内存数: 447 (等于第1行的 used - buffers - cached)[/][]+buffers/cache 的内存数: 2624 (等于第1行的 free + buffers + cached)[/]

注:此处的内存数在用上面式子计算后，在大小上有一点点出入(还不知道是什么原因)。可见-buffers/cache反映的是被程序实实在在吃掉的内存，而+buffers/cache反映的是可以挪用的内存总数。 5. 查看cpu内核数

# 总核数 = 物理CPU个数 X 每颗物理CPU的核数 # 总逻辑CPU数 = 物理CPU个数 X 每颗物理CPU的核数 X 超线程数# 查看物理CPU个数cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l# 查看每个物理CPU中core的个数(即核数)cat /proc/cpuinfo| grep "cpu cores"| uniq# 查看逻辑CPU的个数cat /proc/cpuinfo| grep "processor"| wc -l

 6. 查看系统负载

dimite@ubuntu:~$ uptime15:41:09 up 42 min,  2 users,  load average: 0.08, 0.03, 0.05

[]当前时间 15:41:09[/][]系统已运行的时间 42min[/][]当前在线用户 2 user[/][]平均负载：0.54, 0.40, 0.20，最近1分钟、5分钟、15分钟系统的负载[/]

何为系统负载呢？系统平均负载被定义为在特定时间间隔内运行队列中的平均进程数目。如果一个进程满足以下条件则其就会位于运行队列中：

[]它没有在等待I/O操作的结果[/][]它没有主动进入等待状态(也就是没有调用'wait')[/][]没有被停止(例如：等待终止)[/]

一般来说，每个CPU内核当前活动进程数不大于3，则系统运行表现良好！当然这里说的是每个cpu内核，也就是如果主机是四核cpu的话，那么只要uptime最后输出的一串字符数值小于12即表示系统负载不是很严重.当然如果达到20，那就表示当前系统负载非常严重，估计打开执行web脚本非常缓慢. 7. 查看进程

ps -ef  or ps aux

杀死所有含worker的进程

ps -ef | grep worker | awk '{print $2}' | xargs sudo kill -9orps -aux | grep worker | awk '{print $2}' | xargs sudo kill -9

8. 查看端口占用

netstat -anpornetstat -nltup

参数：

[]-a (all)显示所有选项，默认不显示LISTEN相关[/][]-t (tcp)仅显示tcp相关选项[/][]-u (udp)仅显示udp相关选项[/][]-n 拒绝显示别名，能显示数字的全部转化成数字。[/][]-l 仅列出有在 Listen (监听) 的服務状态[/][]-p 显示建立相关链接的程序名[/][]-r 显示路由信息，路由表[/][]-e 显示扩展信息，例如uid等[/][]-s 按各个协议进行统计[/][]-c 每隔一个固定时间，执行该netstat命令。[/][]提示：LISTEN和LISTENING的状态只有用-a或者-l才能看到[/]