一、安装kvm
1 在安装CentOS6.3时可以选择安装好kvm
2 如果未安装好kvm,请按照下列方式安装
[创建本地yum源]
挂载iso文件
mount -o loop -t iso9660 CentOS-6.3-x86_64-bin-DVD1.iso /mnt
设置本地yum源
在/etc/yum.repos.d/创建 “任意文件名.repo" 文件
vi 刚才新建的文件名编辑
【localyum】任意名称 ,不能有空格。
name= local yum 任意名称
baseurl=file:////mnt/Packages 这个路径是自定的。Server为光盘中的Server目录 ,Packages与Server放在同一目录下。即/software目录下
enabled=1 代表 生效 0为不生效
gpgcheck=1 检查gpgkey 1 生效 0不生效
gpgkey=file:///software 安装光盘里有这个文件 不指定 安装时,可能提示没有注册
保存退出
执行命令 yum clean all
(1) kvm需要有 CPU 的支持(Intel VT 或 AMD SVM)
[root@moniter ~]#egrep '^flags.*(vmx|svm)' /proc/cpuinfo
(2) 安装kvm libvirted
yum install kvm kmod-kvm qemu kvm-qemu-img virt-viewer virt-manager libvirt libvirt-python python-virtinst
yum groupinstall KVM(3) 启动libvirted
service messagebus start
service haldaemon start
service libvirtd start
chkconfig messagebus on
chkconfig haldaemon on
chkconfig libvirtd on
(4)检查kvm是否安装成功
[root@moniter ~]#virsh -c qemu:///system list
Id Name State
----------------------------------
(5)kvm模块
/sbin/lsmod | grep kvm
二、配置网桥
vi /etc/sysconfig/network-scripts/ifcfg-br0
DEVICE=br0
TYPE=Bridge
BOOTPROTO=static
BROADCAST=10.207.20.255
IPADDR=10.207.20.200
NETMASK=255.255.255.0
NETWORK=10.207.20.0
ONBOOT=yes
b、
vi /etc/sysconfig/network-scripts/ifcfg-eth0
# Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
BRIDGE=br0
c、
重起网络服务生效
service network restart
d、
echo 1 > /proc/sys/net/ipv4/ip_forward #虚拟机上网
e、
检查桥接网络
[root@moniter ~]# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.842b2b74e1b6 no eth0
virbr0 8000.000000000000 yes
br0是我们配置的桥接网卡,virbr0是系统脚本自动配置的NAT网卡
三、安装vnc
注意:CentOS6.3 VNC的命名rpm为tiggervnc-server
(1)
yum install tigervnc-server
(2)
vi /etc/sysconfig/vncservers
#加一行
VNCSERVERS="1:root"
(3)
vncpasswd
创建密码
(4)
/etc/init.d/vncserver start
(5)
# netstat -nulpt | grep vnc
tcp 0 0 0.0.0.0:5901 0.0.0.0:* LISTEN 29167/Xvnc
tcp 0 0 0.0.0.0:6001 0.0.0.0:* LISTEN 29167/Xvnc
tcp 0 0 :::6001 :::* LISTEN 29167/Xvnc
表示vnc可以使用了
四、创建kvm虚拟机
virsh-install
1、输入虚拟机名称
2、分配多少内存
3、处理器的个数
4、此步可以直接输入iso的位置或是url
5、虚拟机类型KVM
6、定义虚拟机磁盘映像的位置
7、磁盘的大小
6、指定哪个桥或者可以指定多个桥
7、额外的控制台和KS文件
8、连接到系统参数
参数说明注意每行都要空格
-n 虚拟机名称
-r 分配虚拟机内存大小
--vcpus 分配虚拟cpu个数
-c 镜像文件位置
--vnc --vncport=5901 --vnclisten=0.0.0.0 启动图形安装界面
--virt-type 虚拟机模式
-f 虚拟机系统文件存储目录
-s 分配磁盘大小(GB)
-w 联网方式(birdge bridge:br0/nat bridge:virbr0)
--os-type='windows' --os-variant=win2k3 安装windows最好加上这个否则会报错
virt-install工具安装虚拟机后,在目录/etc/libvirt/qemu/下生成xml配置文件
-s 用来指定虚拟磁盘的大小单位为GB
-m 指定虚拟网卡的硬件地址默认virt-install自动产生
-p 以半虚拟化方式建立虚拟机
-l 指定安装来源
-x EXTRA, --extra-args=EXTRA当执行从"--location"选项指定位置的客户机安装时,附加内核命令行参数到安装程序。
-v, --hvm 设置全虚拟化
virt-install --name=centos6.3 --ram 1024 --vcpus=2 --disk path=/data0/centos-6.3.x86_64.img.img,size=20 --accelerate --cdrom /data0/CentOS-6.3-x86_64-bin-DVD1.iso --graphics vnc,listen=0.0.0.0,port=5920, --network bridge=br0 --force --autostart
执行后,netstat -nulpt | grep 5920 看端口启用否
五、用vnc连接5920完成安装
IP:5920
六、管理kvm虚拟机
virsh --connect qemu:///system
a、如果你修改了一个客户机的xml文件(位于/etc/libvirt/qemu/ 目录),你必须重新定义客户机:
define /etc/libvirt/qemu/vm10.xml
b、启动和停止客户机,运行:
start vm10
c、停止一个客户机,运行
shutdown vm10
d、立即中断一个客户机(类似直接关电源),运行
destroy vm10
e、挂起一个客户机:
suspend vm10
f、恢复客户机:
resume vm10
七、克隆
virt-clone --connect=qemu:///system \
-o 原虚拟机 -n 新虚拟机 -f /data0/centos5.4/新虚拟机镜像
新虚拟机配置文件需要注意:虚拟机克隆完毕后,需修改vnc端口;MAC地址也是需要注意的。
八、加载磁盘空间
#qemu-img create -f qcow2 disk1.img 50G
#vi /etc/libvirt/qemu/centos1.xml
增加的部分为:
<disk type='file' device='disk'>
<source file='/data0/disk1.img'/>
<target dev='hdb' bus='ide'/>
</disk>
使配置文件生效
virsh --connect qemu:///system
virsh #define /etc/libvirt/qemu/centos1.xml
重起虚拟机生效
virsh # shutdown centos1
virsh # start centos1
进入虚拟机:
mkfs.ext3 /dev/hdb
mkdir /data
mount /dev/hdb /data
月度归档: 2015年6月
whois
由于Internet的历史原因,apin负责整个网络IP的整体规划以及北美区 还有部分非洲地区的IP分配管理,与此相应的是,whois.apin.net是IP whois的root server,标准的IP whois查询方法是,首先向whois.apin.net查询某个IP属于哪个大区,然后再向该区的whois 服务器查询此IP的whois详细信息。
目前负责IPV4的大区
whois.arin.net 美洲区 北美,包含非洲地区的查询
whois.apnic.net 亚太区 包括亚洲和澳大利亚
whois.ripe.net 欧洲区 欧洲/中东(西亚)/北非
whois.lacnic.net 拉美区 拉丁美洲和加勒比海区域向某个whois服务器提交whois查询的过程
打开一个到whois服务器的43端口的连接,然后发送要查询的域名 和一个回车换行。如果要查询多个域名,请用空格分开然后从sokect中读取结果。最后服务器将自动断开连接。
用PHP实现
验证IP(用 ip2long代替 ereg)
向whois.arin.net查询,如果数据库中没有相关信息,会给出一个Referral Server的URL,格式如下
ReferralServer:xxxx然后根据此信息,继续查询。
whoisip.php
可以根据ip地址或域名查询whois信息。
zookeeper原理
ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,它包含一个简单的原语集,分布式应用程序可以基于它实现同步服务,配置维护和命名服务等。Zookeeper是hadoop的一个子项目,其发展历程无需赘述。在分布式应用中,由于工程师不能很好地使用锁机制,以及基于消息的协调机制不适合在某些应用中使用,因此需要有一种可靠的、可扩展的、分布式的、可配置的协调机制来统一系统的状态。Zookeeper的目的就在于此。本文简单分析zookeeper的工作原理,对于如何使用zookeeper不是本文讨论的重点。
1 Zookeeper的基本概念
1.1 角色
Zookeeper中的角色主要有以下三类,如下表所示:
系统模型如图所示:
1.2 设计目的
1.最终一致性:client不论连接到哪个Server,展示给它都是同一个视图,这是zookeeper最重要的性能。
2 .可靠性:具有简单、健壮、良好的性能,如果消息m被到一台服务器接受,那么它将被所有的服务器接受。
3 .实时性:Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息,或者服务器失效的信息。但由于网络延时等原因,Zookeeper不能保证两个客户端能同时得到刚更新的数据,如果需要最新数据,应该在读数据之前调用sync()接口。
4 .等待无关(wait-free):慢的或者失效的client不得干预快速的client的请求,使得每个client都能有效的等待。
5.原子性:更新只能成功或者失败,没有中间状态。
6 .顺序性:包括全局有序和偏序两种:全局有序是指如果在一台服务器上消息a在消息b前发布,则在所有Server上消息a都将在消息b前被发布;偏序是指如果一个消息b在消息a后被同一个发送者发布,a必将排在b前面。
2 ZooKeeper的工作原理
Zookeeper的核心是原子广播,这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式,它们分别是恢复模式(选主)和广播模式(同步)。当服务启动或者在领导者崩溃后,Zab就进入了恢复模式,当领导者被选举出来,且大多数Server完成了和leader的状态同步以后,恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。
为了保证事务的顺序一致性,zookeeper采用了递增的事务id号(zxid)来标识事务。所有的提议(proposal)都在被提出的时候加上了zxid。实现中zxid是一个64位的数字,它高32位是epoch用来标识leader关系是否改变,每次一个leader被选出来,它都会有一个新的epoch,标识当前属于那个leader的统治时期。低32位用于递增计数。
每个Server在工作过程中有三种状态:
-
LOOKING:当前Server不知道leader是谁,正在搜寻
-
LEADING:当前Server即为选举出来的leader
-
FOLLOWING:leader已经选举出来,当前Server与之同步
2.1 选主流程
当leader崩溃或者leader失去大多数的follower,这时候zk进入恢复模式,恢复模式需要重新选举出一个新的leader,让所有的Server都恢复到一个正确的状态。Zk的选举算法有两种:一种是基于basic paxos实现的,另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。先介绍basic paxos流程:
-
1 .选举线程由当前Server发起选举的线程担任,其主要功能是对投票结果进行统计,并选出推荐的Server;
-
2 .选举线程首先向所有Server发起一次询问(包括自己);
-
3 .选举线程收到回复后,验证是否是自己发起的询问(验证zxid是否一致),然后获取对方的id(myid),并存储到当前询问对象列表中,最后获取对方提议的leader相关信息(id,zxid),并将这些信息存储到当次选举的投票记录表中;
-
4. 收到所有Server回复以后,就计算出zxid最大的那个Server,并将这个Server相关信息设置成下一次要投票的Server;
-
5. 线程将当前zxid最大的Server设置为当前Server要推荐的Leader,如果此时获胜的Server获得n/2 + 1的Server票数, 设置当前推荐的leader为获胜的Server,将根据获胜的Server相关信息设置自己的状态,否则,继续这个过程,直到leader被选举出来。
通过流程分析我们可以得出:要使Leader获得多数Server的支持,则Server总数必须是奇数2n+1,且存活的Server的数目不得少于n+1.
每个Server启动后都会重复以上流程。在恢复模式下,如果是刚从崩溃状态恢复的或者刚启动的server还会从磁盘快照中恢复数据和会话信息,zk会记录事务日志并定期进行快照,方便在恢复时进行状态恢复。选主的具体流程图如下所示:
fast paxos流程是在选举过程中,某Server首先向所有Server提议自己要成为leader,当其它Server收到提议以后,解决epoch和zxid的冲突,并接受对方的提议,然后向对方发送接受提议完成的消息,重复这个流程,最后一定能选举出Leader。其流程图如下所示:
2.2 同步流程
选完leader以后,zk就进入状态同步过程。
-
1. leader等待server连接;
-
2 .Follower连接leader,将最大的zxid发送给leader;
-
3 .Leader根据follower的zxid确定同步点;
-
4 .完成同步后通知follower 已经成为uptodate状态;
-
5 .Follower收到uptodate消息后,又可以重新接受client的请求进行服务了。
流程图如下所示:
2.3 工作流程
2.3.1 Leader工作流程
Leader主要有三个功能:
-
1 .恢复数据;
-
2 .维持与Learner的心跳,接收Learner请求并判断Learner的请求消息类型;
-
3 .Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息,根据不同的消息类型,进行不同的处理。
PING消息是指Learner的心跳信息;REQUEST消息是Follower发送的提议信息,包括写请求及同步请求;ACK消息是Follower的对提议的回复,超过半数的Follower通过,则commit该提议;REVALIDATE消息是用来延长SESSION有效时间。
Leader的工作流程简图如下所示,在实际实现中,流程要比下图复杂得多,启动了三个线程来实现功能。
2.3.2 Follower工作流程
Follower主要有四个功能:
-
1. 向Leader发送请求(PING消息、REQUEST消息、ACK消息、REVALIDATE消息);
-
2 .接收Leader消息并进行处理;
-
3 .接收Client的请求,如果为写请求,发送给Leader进行投票;
-
4 .返回Client结果。
Follower的消息循环处理如下几种来自Leader的消息:
-
1 .PING消息: 心跳消息;
-
2 .PROPOSAL消息:Leader发起的提案,要求Follower投票;
-
3 .COMMIT消息:服务器端最新一次提案的信息;
-
4 .UPTODATE消息:表明同步完成;
-
5 .REVALIDATE消息:根据Leader的REVALIDATE结果,关闭待revalidate的session还是允许其接受消息;
-
6 .SYNC消息:返回SYNC结果到客户端,这个消息最初由客户端发起,用来强制得到最新的更新。
Follower的工作流程简图如下所示,在实际实现中,Follower是通过5个线程来实现功能的。
对于observer的流程不再叙述,observer流程和Follower的唯一不同的地方就是observer不会参加leader发起的投票。
主流应用场景:
Zookeeper的主流应用场景实现思路(除去官方示例)
(1)配置管理
集中式的配置管理在应用集群中是非常常见的,一般商业公司内部都会实现一套集中的配置管理中心,应对不同的应用集群对于共享各自配置的需求,并且在配置变更时能够通知到集群中的每一个机器。
Zookeeper很容易实现这种集中式的配置管理,比如将APP1的所有配置配置到/APP1 znode下,APP1所有机器一启动就对/APP1这个节点进行监控(zk.exist("/APP1",true)),并且实现回调方法Watcher,那么在zookeeper上/APP1 znode节点下数据发生变化的时候,每个机器都会收到通知,Watcher方法将会被执行,那么应用再取下数据即可(zk.getData("/APP1",false,null));
以上这个例子只是简单的粗颗粒度配置监控,细颗粒度的数据可以进行分层级监控,这一切都是可以设计和控制的。
(2)集群管理
应用集群中,我们常常需要让每一个机器知道集群中(或依赖的其他某一个集群)哪些机器是活着的,并且在集群机器因为宕机,网络断链等原因能够不在人工介入的情况下迅速通知到每一个机器。
Zookeeper同样很容易实现这个功能,比如我在zookeeper服务器端有一个znode叫/APP1SERVERS,那么集群中每一个机器启动的时候都去这个节点下创建一个EPHEMERAL类型的节点,比如server1创建/APP1SERVERS/SERVER1(可以使用ip,保证不重复),server2创建/APP1SERVERS/SERVER2,然后SERVER1和SERVER2都watch /APP1SERVERS这个父节点,那么也就是这个父节点下数据或者子节点变化都会通知对该节点进行watch的客户端。因为EPHEMERAL类型节点有一个很重要的特性,就是客户端和服务器端连接断掉或者session过期就会使节点消失,那么在某一个机器挂掉或者断链的时候,其对应的节点就会消失,然后集群中所有对/APP1SERVERS进行watch的客户端都会收到通知,然后取得最新列表即可。
另外有一个应用场景就是集群选master,一旦master挂掉能够马上能从slave中选出一个master,实现步骤和前者一样,只是机器在启动的时候在APP1SERVERS创建的节点类型变为EPHEMERAL_SEQUENTIAL类型,这样每个节点会自动被编号
我们默认规定编号最小的为master,所以当我们对/APP1SERVERS节点做监控的时候,得到服务器列表,只要所有集群机器逻辑认为最小编号节点为master,那么master就被选出,而这个master宕机的时候,相应的znode会消失,然后新的服务器列表就被推送到客户端,然后每个节点逻辑认为最小编号节点为master,这样就做到动态master选举。
Zookeeper 监视(Watches) 简介
Zookeeper C API 的声明和描述在 include/zookeeper.h 中可以找到,另外大部分的 Zookeeper C API 常量、结构体声明也在 zookeeper.h 中,如果如果你在使用 C API 是遇到不明白的地方,最好看看 zookeeper.h,或者自己使用 doxygen 生成 Zookeeper C API 的帮助文档。
Zookeeper 中最有特色且最不容易理解的是监视(Watches)。Zookeeper 所有的读操作——getData(), getChildren(), 和 exists() 都 可以设置监视(watch),监视事件可以理解为一次性的触发器, 官方定义如下: a watch event is one-time trigger, sent to the client that set the watch, which occurs when the data for which the watch was set changes。对此需要作出如下理解:
-
(一次性触发)One-time trigger
当设置监视的数据发生改变时,该监视事件会被发送到客户端,例如,如果客户端调用了 getData("/znode1", true) 并且稍后 /znode1 节点上的数据发生了改变或者被删除了,客户端将会获取到 /znode1 发生变化的监视事件,而如果 /znode1 再一次发生了变化,除非客户端再次对 /znode1 设置监视,否则客户端不会收到事件通知。
-
(发送至客户端)Sent to the client
Zookeeper 客户端和服务端是通过 socket 进行通信的,由于网络存在故障,所以监视事件很有可能不会成功地到达客户端,监视事件是异步发送至监视者的,Zookeeper 本身提供了保序性(ordering guarantee):即客户端只有首先看到了监视事件后,才会感知到它所设置监视的 znode 发生了变化(a client will never see a change for which it has set a watch until it first sees the watch event). 网络延迟或者其他因素可能导致不同的客户端在不同的时刻感知某一监视事件,但是不同的客户端所看到的一切具有一致的顺序。
-
(被设置 watch 的数据)The data for which the watch was set
这意味着 znode 节点本身具有不同的改变方式。你也可以想象 Zookeeper 维护了两条监视链表:数据监视和子节点监视(data watches and child watches) getData() and exists() 设置数据监视,getChildren() 设置子节点监视。 或者,你也可以想象 Zookeeper 设置的不同监视返回不同的数据,getData() 和 exists() 返回 znode 节点的相关信息,而 getChildren() 返回子节点列表。因此, setData() 会触发设置在某一节点上所设置的数据监视(假定数据设置成功),而一次成功的 create() 操作则会出发当前节点上所设置的数据监视以及父节点的子节点监视。一次成功的 delete() 操作将会触发当前节点的数据监视和子节点监视事件,同时也会触发该节点父节点的child watch。
Zookeeper 中的监视是轻量级的,因此容易设置、维护和分发。当客户端与 Zookeeper 服务器端失去联系时,客户端并不会收到监视事件的通知,只有当客户端重新连接后,若在必要的情况下,以前注册的监视会重新被注册并触发,对于开发人员来说 这通常是透明的。只有一种情况会导致监视事件的丢失,即:通过 exists() 设置了某个 znode 节点的监视,但是如果某个客户端在此 znode 节点被创建和删除的时间间隔内与 zookeeper 服务器失去了联系,该客户端即使稍后重新连接 zookeeper服务器后也得不到事件通知。
Zookeeper C API 常量与部分结构(struct)介绍
与 ACL 相关的结构与常量:
struct Id 结构为:
struct Id { char * scheme; char * id; };
struct ACL 结构为:
struct ACL { int32_t perms; struct Id id; };
struct ACL_vector 结构为:
struct ACL_vector { int32_t count; struct ACL *data; };
与 znode 访问权限有关的常量
-
const int ZOO_PERM_READ; //允许客户端读取 znode 节点的值以及子节点列表。
-
const int ZOO_PERM_WRITE;// 允许客户端设置 znode 节点的值。
-
const int ZOO_PERM_CREATE; //允许客户端在该 znode 节点下创建子节点。
-
const int ZOO_PERM_DELETE;//允许客户端删除子节点。
-
const int ZOO_PERM_ADMIN; //允许客户端执行 set_acl()。
-
const int ZOO_PERM_ALL;//允许客户端执行所有操作,等价与上述所有标志的或(OR) 。
与 ACL IDs 相关的常量
-
struct Id ZOO_ANYONE_ID_UNSAFE; //(‘world’,’anyone’)
-
struct Id ZOO_AUTH_IDS;// (‘auth’,’’)
三种标准的 ACL
-
struct ACL_vector ZOO_OPEN_ACL_UNSAFE; //(ZOO_PERM_ALL,ZOO_ANYONE_ID_UNSAFE)
-
struct ACL_vector ZOO_READ_ACL_UNSAFE;// (ZOO_PERM_READ, ZOO_ANYONE_ID_UNSAFE)
-
struct ACL_vector ZOO_CREATOR_ALL_ACL; //(ZOO_PERM_ALL,ZOO_AUTH_IDS)
与 Interest 相关的常量:ZOOKEEPER_WRITE, ZOOKEEPER_READ
这 两个常量用于标识感兴趣的事件并通知 zookeeper 发生了哪些事件。Interest 常量可以进行组合或(OR)来标识多种兴趣(multiple interests: write, read),这两个常量一般用于 zookeeper_interest() 和 zookeeper_process()两个函数中。
与节点创建相关的常量:ZOO_EPHEMERAL, ZOO_SEQUENCE
zoo_create 函数标志,ZOO_EPHEMERAL 用来标识创建临时节点,ZOO_SEQUENCE 用来标识节点命名具有递增的后缀序号(一般是节点名称后填充 10 位字符的序号,如 /xyz0000000000, /xyz0000000001, /xyz0000000002, ...),同样地,ZOO_EPHEMERAL, ZOO_SEQUENCE 可以组合。
与连接状态 Stat 相关的常量
以下常量均与 Zookeeper 连接状态有关,他们通常用作监视器回调函数的参数。
ZOOAPI const int | ZOO_EXPIRED_SESSION_STATE |
ZOOAPI const int | ZOO_AUTH_FAILED_STATE |
ZOOAPI const int | ZOO_CONNECTING_STATE |
ZOOAPI const int | ZOO_ASSOCIATING_STATE |
ZOOAPI const int | ZOO_CONNECTED_STATE |
与监视类型(Watch Types)相关的常量
以下常量标识监视事件的类型,他们通常用作监视器回调函数的第一个参数。
-
ZOO_DELETED_EVENT; // 节点被删除,通过 zoo_exists() 和 zoo_get() 设置监视。
-
ZOO_CHANGED_EVENT; // 节点发生变化,通过 zoo_exists() 和 zoo_get() 设置监视。
-
ZOO_CHILD_EVENT; // 子节点事件,通过zoo_get_children() 和 zoo_get_children2()设置监视。
Zookeeper C API 错误码介绍 ZOO_ERRORS
ZOK |
正常返回 |
ZSYSTEMERROR |
系统或服务器端错误(System and server-side errors),服务器不会抛出该错误,该错误也只是用来标识错误范围的,即大于该错误值,且小于 ZAPIERROR 都是系统错误。 |
ZRUNTIMEINCONSISTENCY |
运行时非一致性错误。 |
ZDATAINCONSISTENCY |
数据非一致性错误。 |
ZCONNECTIONLOSS |
Zookeeper 客户端与服务器端失去连接 |
ZMARSHALLINGERROR |
在 marshalling 和 unmarshalling 数据时出现错误(Error while marshalling or unmarshalling data) |
ZUNIMPLEMENTED |
该操作未实现(Operation is unimplemented) |
ZOPERATIONTIMEOUT |
该操作超时(Operation timeout) |
ZBADARGUMENTS |
非法参数错误(Invalid arguments) |
ZINVALIDSTATE |
非法句柄状态(Invliad zhandle state) |
ZAPIERROR |
API 错误(API errors),服务器不会抛出该错误,该错误也只是用来标识错误范围的,错误值大于该值的标识 API 错误,而小于该值的标识 ZSYSTEMERROR。 |
ZNONODE |
节点不存在(Node does not exist) |
ZNOAUTH |
没有经过授权(Not authenticated) |
ZBADVERSION |
版本冲突(Version conflict) |
ZNOCHILDRENFOREPHEMERALS |
临时节点不能拥有子节点(Ephemeral nodes may not have children) |
ZNODEEXISTS |
节点已经存在(The node already exists) |
ZNOTEMPTY |
该节点具有自身的子节点(The node has children) |
ZSESSIONEXPIRED |
会话过期(The session has been expired by the server) |
ZINVALIDCALLBACK |
非法的回调函数(Invalid callback specified) |
ZINVALIDACL |
非法的ACL(Invalid ACL specified) |
ZAUTHFAILED |
客户端授权失败(Client authentication failed) |
ZCLOSING |
Zookeeper 连接关闭(ZooKeeper is closing) |
ZNOTHING |
并非错误,客户端不需要处理服务器的响应(not error, no server responses to process) |
ZSESSIONMOVED |
会话转移至其他服务器,所以操作被忽略(session moved to another server, so operation is ignored) |
Watch事件类型:
ZOO_CREATED_EVENT:节点创建事件,需要watch一个不存在的节点,当节点被创建时触发,此watch通过zoo_exists()设置
ZOO_DELETED_EVENT:节点删除事件,此watch通过zoo_exists()或zoo_get()设置
ZOO_CHANGED_EVENT:节点数据改变事件,此watch通过zoo_exists()或zoo_get()设置
ZOO_CHILD_EVENT:子节点列表改变事件,此watch通过zoo_get_children()或zoo_get_children2()设置
ZOO_SESSION_EVENT:会话失效事件,客户端与服务端断开或重连时触发
ZOO_NOTWATCHING_EVENT:watch移除事件,服务端出于某些原因不再为客户端watch节点时触发
KVM的B/S架构虚拟化管理系统
云计算的提出为信息技术学术界和产业界的发展提供了一个全新的思路。虚拟化作为云计算Iaas层的关键技术,近年来也得到了迅速发展。20世纪60年代,IBM就开始研究虚拟化技术,使得大型机的资源能得被多用户使用。经过几十年的发展,虚拟化技术已经日渐成熟,诞生了如VMware,virtual PC,Xen和KVM(kernel based virtualmachine)等一批成熟的虚拟化产品。与其他虚拟化产品相比,KvM的最大优势是完全开源。KVM是基于内核的完全虚拟化,在与其他虚拟化产品效率对比中表现出色,但是其管理系统仍然只有C/S架构的,C/S架构本身的缺点造成了系统资源的浪费。而且用户进行管理工作之前,需要预先安装管理软件;而且不同的管理软件对操作系统和硬件资源还有不同的要求。相比起来,B/S模式的管理系统就灵活很多,只要有浏览器的终端都可以用来进行管理工作,提高了管理效率,节省了客户端资源占用。
本文实现了一个基于KVM虚拟化产品的B/S架构的虚拟化管理系统。通过调用KVM的libvirt开发接口,利用J2EE技术,系统管理员可在任何地方通过浏览器登陆系统,进行虚拟机和虚拟存储的管理工作。最后通过实际测试表明B/S架构的优越性。
1.系统组成部分
基于KVM的虚拟化管理系统,主要包括客户端、web服务器、虚拟化服务器集群和共享存储服务器4个模块。其中客户端是具有浏览器的上网设备,操作系统可以是Linux、windows甚至嵌入式操作系统;web服务器上安装web容器tomcat,操作系统采用“nux或windows,将完成管理工作的J2EE工程放在web容器里;虚拟化服务器集群上统一安装Linux操作系统,KVlⅥ虚拟化软件和lib—virt接口,并与web服务器建立ssh无密码连接;共享存储服务器是一个磁盘阵列,安装freenas后通过IP网络向虚拟化集群提供数据存储服务。
用户通过jsp页面登陆后进行相关操作,操作参数传递给web服务器,web服务器与管理目标服务器建立ssh连接,通过调用libvirt接口进行虚拟化集群的管理工作,并将操作结果通过jsp页面呈现给用户。用户还可以通过调用spice插件,用图形界面的方式查看虚拟机的工作情况。整个系统结构如图1所示。
图1 系统架构
1.1 KVM(Kernel based virtual machine)
KVM即基于内核的虚拟化,依赖于“Linux内核,其性能优越,接近单机操作系统。由于其优越的性能和开源性,得到业界的一致认可并在近年来取得很大的发展。KVM使用软件模拟的方式实现完全虚拟化,通过将客户操作系统的I/0指令提交给宿主操作系统(即Linux操作系统)上的QEMU,QEMU将操作指令转换为对宿主机的I/0操作这种方式来实现虚拟化,然后宿主操作系统调用驱动程序访问硬件。通过这种方式对硬件进行了模拟,实现起来比较简洁,而且效率较高|。
1.2 SPICE(simple procotol for independent computing environment)
spice是一个开源的远程桌面协议,可以用于在服务器、远程计算机和瘦客户端等设备上部署虚拟桌面,与微软的Remote Desktop Protocol相似,支持windows和Linux操作系统。
spice包括两部分:spice server和spice client。通过在虚拟机里安装spice Server进行相应的配置后,就可以在客户端通过spice client插件远程链接该虚拟机,以图形界面形式进行操作。
1.3 Libvirt接口
Libvirt是一套开源的、用C语言开发的支持虚拟化函数库编程接口,用一种单一方式管理不同的虚拟化提供方式和管理工具,适用于主流虚拟化工具包括Xen、KVM和vmware等,支持与Java、python、C/C++等开发语言的绑定。Linux下常用的虚拟化管理工具Virt-manager和virt—install都是基于libvirt开发。
1.4 Freenas
Freenas是一款免费的NAS(网络附加存储)服务器软件,它能将普通PC或服务器的硬盘资源变成网络存储服务器。该软件基于FreeBSD,Samba及PHP,支持FTP/NFS/RSYNC/CIFS/AFP/UNISON/SSH协议及web界面的设定工具。Freems还可以被安装在移动存储设备中,使用方便灵活,在组建网络存储服务器方面应用广泛。
2.J2EE工程架构
系统实现的核心是完成管理工作并和用户交互的J2EE工程。J2EE工程架构如图2所示。
图2 J2EE工程架构
客户层实现用户和系统的交互,用户通过Web浏览器登录系统,并通过页面提交操作参数。浏览器负责用户请求接收和服务器返回信息的显示。
struts控制器负责接收和处理用户请求,并将相应请求转发到业务逻辑层,然后从业务逻辑层接收结果并返回给客户层进行显示。
业务逻辑层是J2EE工程的核心,负责接收stmts传递的用户请求,调用底层libvirt API完成相应的操作,并将处理结果经Web层展现给用户。
将管理虚拟化的J2EE工程放在中心服务器(即web服务器)的tomcat容器里,这台web服务器应该与虚拟化集群在同一局域网中以保证连接速度。用户通过前台jsp页面登陆管理系统,web服务器接收到用户的请求参数后,与管理目标服务器通过ssh建立连接,用户即可进行相关的管理操作。在web服务器接收到用户管理操作参数后,将参数转换为libvirt接口认可的xml格式文件的参数,然后发送给管理目标服务器,目标服务器接收到参数后调用Libvirt接口,执行相关操作。具体实现过程如下:
用户提交请求参数:用户登录成功后,可以进行如下四方面管理:用户管理、存储磁盘、虚拟机管理和集群管理。通过用户管理可以修改用户登录密码,定期修改密码可以增强安全性;通过存储管理可以添加或删除资源池,查看、删除或者新建虚拟磁盘;通过虚拟机管理,可以查
看和修改虚拟机信息,并通过spice查看虚拟机图形界面;集群管理可以查看集群中的物理机信息,并可以将虚拟机迁移到另一台物理机上。用户操作通过表单形式提交给Web服务器。
Web服务器转换请求参数并发送给目标服务器:web服务器通过servIet接收到用户请求参数,转换为字符串,然后将参数组合为ml格式的libvirt配置文件,然后与目标服务器建立ssh连接,通过配置文件将需要进行的操作传递给目标服务器。
目标服务器进行相关管理操作并向web服务器返回结果:目标服务器收到配置文件参数后,调用libvirt接口将操作参数传人,进行相应的操作。然后将操作结果返回给Web服务器。
Web服务器将操作结果返回给用户:web服务器接收到返回结果后,进行相应的封装后传递给前台页面,显示给用户。如果用户的请求是图形界面查看虚拟机,则Web服务器将虚拟机的参数传递给客户端后,客户端与目标服务器直接建立连接。
3.系统设计功能
用户登录后可以进行如下四方面管理工作:用户管理、存储管理、虚拟机管理和集群管理。系统功能框图如图3所示。
图3 系统功能结构
3.1用户管理
用户名和密码通过加密后写在配置文件里,用户提交登录请求后web服务器读取配置文件并进行登录验证,验证通过即可进行权限内的相关管理操作。用户可以定期修改密码,以增强安全性。超级用户可以对用户进行管理,包括添加、删除用户,为用户分配权限等,但是超级用户本身不能对虚拟化集群直接进行管理。通过这种权限分离的方式提高系统的安全性。
3.2虚拟存储管理
创建虚拟磁盘之前需要先创建资源池,然后在资源池中创建虚拟磁盘。虚拟磁盘就是提供给虚拟机用的存储空间,是位于共享存储之上的虚拟逻辑磁盘空间。用户登录之后,存储管理界面提供的管理操作包括:新建和删除资源池,新建和删除虚拟磁盘。新建和删除虚拟磁盘的时候,将虚拟磁盘名作为参数传递给web服务器,创建虚拟磁盘时提交表单包括磁盘名称和磁盘大小。表单提交给servlet进行处理。
3.3虚拟机管理
创建虚拟机之后,KVM会给每个虚拟机分配一个UUD(universally unique identifier),用于唯一标识该虚拟机。KVM每次启动的时候,都会为每个虚拟机分配一个ID。通过UUID或者ID都可以唯一找到该虚拟机。虚拟机管理进行的操作包括:新建和删除虚拟机,查看和修改虚拟机配置信息,启动、挂起和关闭虚拟机,导出虚拟机模板,从模板创建虚拟机,显示虚拟机界面(spice)。本系统将虚拟机的ID作为参数进行传递。首先用户将操作指令和虚拟机ID传递给web服务器,web服务器封装后传递给目标服务器,然后接受目标服务器执行后的返回结果,再传递给用户显示。
在调用spice通过图形界面方式查看虚拟机中,首先检测spice插件是否正确安装,如果没有正确安装,提示用户下载并安装。如果正确安装,在拦截到查看指令后,从网页启动spice插件。并将虚拟机参数传递给spice,输入密码即可查看虚拟机的界面。
3.4 集嚣管理
集群管理包括物理主机管理和集群调度。物理机管理包括向虚拟化集群添加和删除物理机,通过SNMP(simplenetwork management protocol)协议收集物理机信息,维护活动物理机列表;集群调度采用虚拟机迁移来实现,采用中心任务调度算法,根据管理节点服务器(即Web服务器)通过SNⅧ协议收集到的主机状态信息,在物理机负载过高时,将其上的部分虚拟机迁移到其他物理机上,也可以将负载量很小的物理机上的虚拟机迁移到其他主机上,然后关闭该物理机以节省电能。
4.关键技术
4.1 封装ssh连接类
系统中用到建立ssh连接的地方比较多,因此通过对连接类进行封装可以有效减少代码量,提高可读性。
封装ssh连接类需要用到两个类:org. libvirt包下的Connect和LibvirtException类。实现封装的类如下:
public class SSHConnect{
private static final String SSHURLl=“
qemu+ssh://”;
private static final String SSHURL2=“/system”;
public static Connect getSSHConnect(String userIp,
boolean flag){
Connect conn=null;
try{
conn = new Connect (SSHURL1+userIp+
SSHURL2,fIag);
}catch(LibvirtException e){
e.printstackTrace();
System.out.println(e.getError());
return:
}
return conn:
}
public static void close(Connect conn){
if(conn!=null){
try{
conn.close();
}catch(LibvirtException e){
e.printStackTrace();
Systern.out.println(e_getError());
}
}
}
}
4.2 Ajax(Asynchronous JavaScript and XML)技术
考虑到不同的用户同时对一台服务器进行管理的可能性,本系统在向服务器读取数据的时候都是实时读取的,这就要用到Ajax技术。
Ajax即异步JavaScript和XML,是一种创建交互式网页应用的网页开发技术。其工作原理是,在用户和服务器之间增加了了一个中间层——Ajax引擎.使用户操作与服务器响应异步化,部分操作由Ajax直接完成,无需向服务器提交数据。在用户需要从服务器读取新数据时由Ajax引擎代为向服务器提交请求,然后将读取结果发送给用户。在使用Ajax擎后,用户从感觉上几乎所有的操作都会很快响应没有页面重载的等待,也没有页面跳转。其工作原理如图5所示。
图4 Ajax工作原理
4.3用spice查看虚拟机
在创建虚拟机的时候,将图形设备选择为spice,添加spice server并设置端口号,将显卡设备选择为视频卡QXL设备。Web服务器在接收到查看图形界面请求后,首先进行客户操作系统的判断,并检测用户是否正确安装spice,如果没有安装则根据用户操作系统提示用户下载安装spice包。
如果spice正确安装,则通过网页启动spice,并将相应参数传人,即可打开虚拟机的图形界面。
4.4 提供类应用软件试图
为了使管理的步骤更加清晰和兼顾用户使用习惯,本系统设计类似应用软件的用户交互界面。首先将操作拆分成各个步骤,并为每一步骤设计一个jsp页面,然后使用Css+div建立一个可拖动的层,然后采用ifr锄e技术将操作步骤对应的jsp页面加载到层中显示,用Javascript控制层中内容的切换和数据的缓存,需要与服务器及时交互的数据则采用Ajax技术实时获取。在一个操作完成后将表单数据整合并提交。
5.系统性能测试
以VMware的vCenter server/vClient为例,与本系统性能做一个比较,测试环境为包含6台服务器的集群。用pc做客户端进行测试,CPU为双核2.9GHz,内存为2G,Windows Xp系统使用内存约350M。使用的系统资源情况分别如图6和图7所示。
图5 VMware 客户端资源使用
图6 B/S架构客户端资源使用
由图可见,C/S架构客户端CPU利用率约为50%,内存使用为350M左右,而使用B/S架构系统的客户端CPU平均使用率约为20%,内存使用为190M左右。管理节点采用的是2个64位CPU,主频2.5GHz,内存8G,硬盘100G。安装hyper_V和作web服务器时系统资源使用情况见表1。
由此可见,B/S架构管理系统能极大降低系统资源的消耗。这一特点在集群规模增大时会体现的更加明显,因此对大规模虚拟化集群部署有重要的参考价值。
6.结束语
基于KVM的B/S架构虚拟化管理系统,将虚拟化管理工作由C/S模式转向了B/S模式,用户在管理虚拟化集群之前不用先安装客户端,直接通过浏览器登陆即可进行管理,管理工作不用限定在特定的客户机上,也不用限定在特定的网络环境中。由于web服务器取代了管理中心服务器,使系统的资源消耗更少,管理方式更加灵活。本系统在WindowS和Linux下经过测试,运行良好