启动zookeeper运行结果如下：

[root@zk1 bin]# ./zkServer.sh start

JMX enabled by default

Using config: /usr/local/zookeeper/bin/../conf/zoo.cfg

Starting zookeeper ... STARTED

查看状态如下：

[root@zk1 bin]# ./zkServer.sh status

JMX enabled by default

Using config: /usr/local/zookeeper/bin/../conf/zoo.cfg

Error contacting service. It is probably not running.

我netstat -anltup |grep 2018,并没有监听，端口没有占用啊？
 
那只好去看日志了，查看zookeeper的zookeeper.out日志内容如下：

2016-02-24 17:35:22,425 [myid:] - ERROR [main:ZooKeeperServerMain@63] - Unexpected exception, exiting abnormally

java.net.BindException: Address already in use

    at sun.nio.ch.Net.bind0(Native Method)

    at sun.nio.ch.Net.bind(Net.java:344)

    at sun.nio.ch.Net.bind(Net.java:336)

    at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:199)

    at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)

    at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)

    at org.apache.zookeeper.server.NIOServerCnxnFactory.configure(NIOServerCnxnFactory.java:95)

    at org.apache.zookeeper.server.ZooKeeperServerMain.runFromConfig(ZooKeeperServerMain.java:110)

    at org.apache.zookeeper.server.ZooKeeperServerMain.initializeAndRun(ZooKeeperServerMain.java:86)

    at org.apache.zookeeper.server.ZooKeeperServerMain.main(ZooKeeperServerMain.java:52)

    at org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:116)

    at org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:78)

从日志中"Address already in use"可以看出端口被占用了！
但我用netstat -lntup是没被使用的，再用 lsof -i:2181，发现了2181端口果然被占用了。其实最好的办法是nc -v -z locahost 2181 探测一些本地2181端口是否监听！

[root@zk1 ~]# nc -v -z localhost 2181

Connection to localhost 2181 port [tcp/eforward] succeeded!

[root@zk1 ~]# 

好了，端口被占用了，只能修改zk的默认端口，从新启动ok！

不可变基础设施（Immutable Infrastructure）是由Chad Fowler于2013年提出的一个很有的预见性的构想 ，其核心思想为任何基础设施的实例一旦创建之后变成为只读状态，如需要修改和升级，则使用新的实例进行替换。

 

这种模式可以为我们减少配置管理的负担，并使得 DevOps 更加容易实践，基于 Packer、Terraform及Docker， 我们正在实践和完善这种构想，现在给大家分享。

当前的不可变基础设施实践的主要内容有：

[]生产与开发环境的一致性系统[/][]利用 Terraform 构建基础设施[/]

生产与开发环境的一致性系统

我们平时的开发和测试乃至部署中，最常出现的问题之一就是由于系统环境的不一致导致bug或者运行失败， 这在长时间运行的服务器进行缓慢升级时最为常见，而老旧的系统和软件则带来更多的问题和维护成本。

因此我们使用 Packer 及 Vagrant 来统一生产环境和开发环境，Packer 构建操作系统镜像，供 Vagrant 运行虚拟开发环境，这样所有的开发人员都会有一个统一并且持续更新的开发环境，更利于减少问题和协作。

Packer 构建的镜像还可用于各大虚拟化平台，如 KVM、Xen和ESXi，以及导入到 AWS 等云计算平台，我们这里使用的就是 AWS。 

构建的基础镜像会预装好大部分需要的软件如 Docker、Consul，一些常见的 Docker 容器镜像也会拉取预装好。

这样我们在部署时就会有一个和开发环境几乎没有差别的统一基础设施可用。

我已经把我们镜像的构建脚本提取开源出来 zealic/packer-boxes，构建的镜像有 CentOS 及 Debian，大家可以参考以此构建自己的镜像。

利用 Terraform 构建基础设施

上面说过我们使用 AWS 作为基础设施平台，基于不可变基础设施的理念，我们希望的是基础设施是可以快速销毁和重建的，

基于这个目的，我们使用了 Terraform 来完全托管 AWS 基础设施。

在此之前，我需要介绍一下部分架构。 

首先我们会为基础设施分组，每个基础设施组对应一整套 VPC 环境。

每组基础设施我们根据功能场景分为两种；ops-center组 及应用基础设施组，ops-center 主要承载运维基础设施，如 Mesos Master，Docker Registry，持续集成服务，VPN接入以及管理后台都运行在 ops-center。

应用基础设施组则运行主要业务的微服务、反向代理及 Marathon 节点。

而这些体现到 AWS 中，每组基础设施组都会应对一个 VPC，通过 VPC Peering Connection 连接相关的基础设施组。

基于这样的前提，我们可以对此分出多个基础设施组，比方我们有国内和新加坡的业务，则可分出如下基础设施组：

[]ops-cn[/][]prd-cn[/][]ops-sg[/][]prd-sg-master[/][]prd-sg-slave[/]

下面将介绍我们使用 Terraform 托管基础设施时的一些细节。

我们写了一套 Thor 脚本来管理多个基础设施组，每个组都是一个文件夹，文件夹中包含了对基础设施组的 Terraform 定义， 这些定义文件均被版本控制，可以进行对资源的快速回滚和改动。 

当我们需要对 AWS 基础设施做一些修改时，只需要修改定义并运行如下命令：

thor exec:terraform apply

通过管理配置文件传递变量来关联多个基础设施组的关系。 目前通过 Terraform 托管了以下内容：

[]VPC[/][]VPC Subnet[/][]Route table[/][]Security Groups[/][]Route53 records[/][]ELB[/][]S3[/][]Internet/NAT Gateways[/]

以及上面提到的 ops-center 的中提供的各种功能服务器，在定义 aws_instance 时，我们会为其分配 tag，我们的管理程序在接收到服务器准备好的事件时，通过 tag 判断该服务器的角色，为其执行对应的 Ansible Playbook，从而完成自动化部署。

有时我们可能会有未受 Terraform 的资源需要纳入其托管范围，这里我们用了terraforming ，可以将已经存在的 VPC、S3 或者 EC2 实例纳入 Terraform 的托管；当然Terraform 也承诺了将会在未来加入 import 功能以导入已有资源。

应用基础设施组则仅部署 Marathon 管理 Docker 容器集群，由其管理业务服务及其他相关内容，由于我们的业务服务均会构建为 Docker 容器进行发布，因此这里仅仅只需要管理应用服务的配置，这里我们使用了 consul 和 confd 来进行动态配置管理。

这样，我们的基础设施均以相同的模式运行和创建，均具有不可变性，系统更为简单和可靠，并具有快速回滚的能力。

通过实施这套方案，我们可以获得以下好处：

[]快速重建[/][]销毁基础设施组[/][]部署多个基础设施组来实现灾容[/][]灰度发布及快速升级。[/]

Q&A
Q：你们这套方案中遇到过哪些坑让你印象深刻，请举一两个具体实例说明？

A：使用 Packer 在国内进行构建时，因为众所周知的网络原因，经常会有失败的问题，这一点可以通过其他方式避免。此外由于 Terraform 并非完全支持所有的 AWS 资源管理，如 Cloudfront、Route53 Geo DNS，仍然需要手工管理这些，不过未来 Terraform 会加入这些的支持。

Q：每个vpc组是完全独立的提供服务？能说下这套技术应对的业务层是哪个方面的么？

A：每个 VPC 组提供的是一个完整的应用功能实现，上面也提高了我们会有 prd-sg-master，prd-sg-slave，可用于灾容。业务层提供的主要是 HTTP 服务及内部依赖的微服务。

Q：请问为什么选用Consul？很多类似方案用的etcd。

A：Consul 对于 agent 的节点的失效更友好，此外 Vagrant、Consul、Terraform 都是由 HashiCorp 公司开发的，其文档和技术栈都很全面，值得应用实践。

Q：如果我用了Kubernetes，对大数据Hadoop、Spark都没啥需求，是否还有用Mesos的必要呢？换句话说Mesos和Kubernetes结合针对纯容器平台有什么好处，使用场景是什么？

A：Kubernetes 和 Mesos 都是容器管理调度的框架，Mesos 的优势是更具可开发扩展性。

Q：请问对于PHP这种可以动态加载代码的服务，在这套系统里应该怎么应用呢？​

A：动态加载代码的代码源建议使用微服务的方式提供。

Q：Vagrant在宿主机使用的是NAT模式还是bridge ？Packer相对于vagrant package 命令，优势是哪些？Vagrant 在宿主机使用 NAT 模式，这样可以减少 DNS 出问题的几率。

A：Packer 可以从ISO镜像开始构建你的系统，相对于Vagrant更纯粹；实际上Vagrant的大多数 box 都是从Packer打包过来的。

Q：我在上期分享时，介绍过类似的Packer+Terraform工具。在使用Terraform管理AWS资源时，你提到另外的脚本管理（thor exec:terraform apply)。请问，你为何不直接运行Terraform 的命令，用thor的目的是什么，你的哪个repo了有用到thor，我可以参考一下？

A：我们在运行Terraform时需要传递很多变量以及硬编码参数，同时我们使用了AWS国内区域和 AWS 国际区域，他们是分开的，对应的 AWS Access Key 及 SecretKey 不同，Thor 脚本的目的是讲这些内容通过配置文件和环境变量的的方式传递给 Terraform，使其能获取正确的参数和定位正确的执行环境。

Q：请问持续集成采用的是Jenkins加插件的方式吗？持续集成的代码采用了什么样的分支管理策略？

A：是的，持续集成采用Jenkins及插件，我们采用的分支是 Git Flow 的变种，基于pull的模型。

Q：单纯的用于AWS的话，亚马逊自家的CloudFormation支持的基础设施应该更全面，如果不考虑跨平台的能力，还有什么理由选择Terraform吗？

A：CloudFormation 的设计并不友好，基于 JSON 的语法非常晦涩且难于维护，不像 Terraform 一样一目了然。

Q：跨主机网络是咋解决的啊？是结合了Kubernetes和Mesos、Docker功能吗？

A：我们采用的方案是 Weave，没有使用Kubernetes。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

分享阅读原文：http://dockone.io/article/1044
分享作者：曾超，Hyku架构师，负责公司的基础架构和运维架构，精通AWS技术体系，热爱Docker及开源。
Dockone.io微信群分享
DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesz

关于linux 进程的处理器亲和性的vCPU 隔离和绑定之前已经做过测试，查考 ubuntu中测试进程的处理器亲和性和vCPU的绑定。查看链接：Setting KVM processor affinities
那么KVM 虚拟化下如何直接为虚拟机绑定CPU 呢，KVM 提供了很方便的方法
查看所有虚拟机：

root@network:~# virsh list --all  

 Id    Name                           State  

----------------------------------------------------  

 2     instance-000000ef              running  

 4     instance-000000f3              running  

 7     instance-00000120              running  

 10    instance-00000146              running  

 11    instance-00000147              running  

 12    instance-00000148              running  

 26    instance-00000157              running  

 35    instance-0000015c              running  

 38    instance-00000158              running  

 39    instance-0000015b              running  

 -     instance-00000122              shut off  

查看虚拟机信息

root@network:~# virsh dumpxml instance-00000146  

  

  instance-00000146  

  45d77d2b-723f-40c8-a953-13f886a317f8  

  4194304  

  4194304  

  4  

    

    /machine  

    

    

      

      OpenStack Foundation  

      OpenStack Nova  

      2014.1.3  

      202b2f9b-3fb8-dc11-8e76-e03f490e5d2c  

      45d77d2b-723f-40c8-a953-13f886a317f8  

      

    

    

查看cvpu

root@network:~# ps -ef|grep instance-00000146  

root     21561 13180  0 14:31 pts/12   00:00:00 grep --color=auto instance-00000146  

libvirt+ 31858     1  5 Jan08 ?        17:09:02 /usr/bin/qemu-system-x86_64 -name instance-00000146 -S -machine pc-i440fx-trusty,accel=kvm,usb=off -cpu Opteron_G5,+bmi1,+perfctr_nb,+perfctr_core,+topoext,+nodeid_msr,+tce,+lwp,+wdt,+skinit,+ibs,+osvw,+cr8legacy,+extapic,+cmp_legacy,+fxsr_opt,+mmxext,+osxsave,+monitor,+ht,+vme -m 4096 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 45d77d2b-723f-40c8-a953-13f886a317f8 -smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=2014.1.3,serial=202b2f9b-3fb8-dc11-8e76-e03f490e5d2c,uuid=45d77d2b-723f-40c8-a953-13f886a317f8 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-00000146.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/nova/instances/45d77d2b-723f-40c8-a953-13f886a317f8/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/var/lib/nova/instances/45d77d2b-723f-40c8-a953-13f886a317f8/disk.swap,if=none,id=drive-virtio-disk1,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=34 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:83:8e:cf,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/var/lib/nova/instances/45d77d2b-723f-40c8-a953-13f886a317f8/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -vnc 0.0.0.0:8 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6  

root@network:~# ps -eLo ruser,pid,ppid,lwp,psr|grep 31858  

libvirt+ 31858     1 31858   0  

libvirt+ 31858     1 31867   6  

libvirt+ 31858     1 31869   4  

libvirt+ 31858     1 31871   7  

libvirt+ 31858     1 31873   0  

libvirt+ 31858     1 31882   7  

libvirt+ 31858     1 19834   6  

libvirt+ 31858     1 20272   6  

libvirt+ 31858     1 20679   6  

libvirt+ 31858     1 20925   6  

libvirt+ 31858     1 20926   6  

libvirt+ 31858     1 20927   6  

libvirt+ 31858     1 20928   7  

libvirt+ 31858     1 20930   6 

最后一列是cpu 的编号，重复执行 ps -eLo ruser,pid,ppid,lwp,psr|grep 31858  可以看到 线程是不停在不通cpu 上漂移的，绑定这么多线程是很麻烦的
利用 virsh vcpuinfo instance-00000146  查看每个vCPU 对应物理核心（也是浮动的）

root@network:~# virsh vcpuinfo instance-00000146  

VCPU:           0  

CPU:            4  

State:          running  

CPU time:       16025.9s  

CPU Affinity:   yyyyyyyy            这里看到是宿主机所有物理CPU 核心，Y代表有可以使用，基于CPU时间片来回切换  

  

  

VCPU:           1  

CPU:            6  

State:          running  

CPU time:       20221.3s  

CPU Affinity:   yyyyyyyy  

  

VCPU:           2  

CPU:            6  

State:          running  

CPU time:       12179.5s  

CPU Affinity:   yyyyyyyy  

  

VCPU:           3  

CPU:            5  

State:          running  

CPU time:       12411.4s  

CPU Affinity:   yyyyyyyy 

绑定instance-00000146 的vcpu0 到物理cpu3

root@network:~# virsh vcpupin instance-00000146 0 3  

  

root@network:~# virsh vcpuinfo instance-00000146  

VCPU:           0  

CPU:            3  

State:          running  

CPU time:       16033.7s  

CPU Affinity:   ---y----                    这里看到只有第三个cpu 为Y  

  

VCPU:           1  

CPU:            1  

State:          running  

CPU time:       20234.7s  

CPU Affinity:   yyyyyyyy  

  

VCPU:           2  

CPU:            0  

State:          running  

CPU time:       12188.5s  

CPU Affinity:   yyyyyyyy  

  

VCPU:           3  

CPU:            0  

State:          running  

CPU time:       12420.2s  

CPU Affinity:   yyyyyyyy  

依次绑定

root@network:~# virsh vcpupin instance-00000146 1 4  

  

root@network:~# virsh vcpupin instance-00000146 2 5  

  

root@network:~# virsh vcpupin instance-00000146 3 6  

  

root@network:~# virsh vcpuinfo instance-00000146  

VCPU:           0  

CPU:            3  

State:          running  

CPU time:       16050.3s  

CPU Affinity:   ---y----  

  

VCPU:           1  

CPU:            4  

State:          running  

CPU time:       20255.6s  

CPU Affinity:   ----y---  

  

VCPU:           2  

CPU:            5  

State:          running  

CPU time:       12203.2s  

CPU Affinity:   -----y--  

  

VCPU:           3  

CPU:            6  

State:          running  

CPU time:       12438.0s  

CPU Affinity:   ------y-  

一，什么是KVM

KVM包括很多部件：首先，它是一个Linux内核模块（现在包括在主线中）用于转换处理器到一种新的用户 （guset） 模式。用户模式有自己的ring状态集合,但是特权ring0的指令会陷入到管理器(hypervisor)的代码。由于这是一个新的处理器执行模型，代 码不需要任何的改动。   除了处理器状态转换，这个内核模块同样处理很小一部分低层次的模拟，比如MMU注册（用于管理VM）和一部分PCI模拟的硬件。 在可预见的未来，Qemu团队专注于硬件模拟和可移植性，同时KVM团队专注于内核模块（如果某些部分确实有性能提升的话，KVM会将一小部分模拟代码移 进来）和与剩下的用户空间代码的交互。 kvm-qemu可执行程序像普通Qemu一样：分配RAM,加载代码，不同于重新编译或者调用calling KQemu，它创建了一个线程（这个很重要）；这个线程调用KVM内核模块去切换到用户模式，并且去执行VM代码。当遇到一个特权指令，它从新切换会 KVM内核模块，该内核模块在需要的时候，像Qemu线程发信号去处理大部分的硬件仿真。 这个体系结构一个比较巧妙的一个地方就是客户代码被模拟在一个posix线程，这允许你使用通常Linux工具管理。如果你需要一个有2或者4核的虚拟 机，kvm-qemu创建2或者4个线程，每个线程调用KVM内核模块并开始执行。并发性（若果你有足够多的真实核）或者调度（如果你不管）是被通用的 Linux调度器，这个使得KVM代码量十分的小 当一起工作的时候，KVM管理CPU和MEM的访问，QEMU仿真硬件资源（硬盘，声卡，USB，等等）当QEMU单独运行时，QEMU同时模拟CPU和 硬件。

二、KVM架构

kvm基本结构有2个部分构成：

[] kvm 驱动，现在已经是linux kernel的一个模块了。其主要负责虚拟机的创建，虚拟内存的分配，VCPU寄存器的读写以及VCPU的运行。[/][]另个组成是Qemu，用于模拟虚拟机的用户空间组件，提供I/O设备模型，访问外设的途径。[/]

三、KVM 工作原理

kvm基本工作原理概述：

用户模式的qemu利用libkvm通过ioctl进入内核模式，kvm模块未虚拟机创建虚拟内存，虚拟CPU后执行VMLAUCH指令进入客户模 式。加载Guest OS并执行。如果Guest OS 发生外部中断或者影子页表缺页之类的情况，会暂停Guest OS的执行，退出客户模式出行异常处理，之后重新进入客户模式，执行客户代码。如果发生I/O事件或者信号队列中有信号到达，就会进入用户模式处理。

如下图所示：

四、手动安装配置KVM

1.安装前的准备

    1.CPU支持虚拟化（Inter-VT、AMD-V）

    [root@localhost ~]# grep --color 'svm|vmx|lm'  /proc/cpuinfo

 

    相关CPU功能标志包括：   

    svm=安全虚拟机（AMD-V）

    vmx=虚拟机x86（Inter-VT）

    lm=长模式（64位支持）  

     

    2. BIOS开启CPU虚拟化支持

    1）重启

    2）按delete键

    3) 进入BIOS开启     

2.安装虚拟化(yum配置完毕)

# yum -y install kvm python-virtinst libvirt bridge-utils 

virt-manager qemu-kvm-tools virt-viewer virt-v2v qemu-kvm tunctl

[root@localhost ~]#vim /etc/sysconfig/selinux //关闭selinux

SELINUX=disabled

3.启动libvirtd

[root@localhost ~]# /etc/init.d/libvirtd start  //启动

[root@localhost ~]# ps -e|grep libvirtd   //查看是否启动

[root@localhost ~]#chkconfig libvirtd on

注释：永久开启！不然系统重启后不会自动启动这个服务的哟～

# virsh  iface-bridge eth0 br0

注释：创建网络桥！

验证：

ifconfig   br0

注释:观察IP地址是否跑到了br0网卡上！ 

4.配置网络桥接

root@localhost network-script]# vi ifcfg-eth0 

DEVICE=eth0

TYPE=Ethernet

ONBOOT=yes

BOOTPROTO=none

BRIDGE=br0

 

[root@localhost network-scripts]# vi ifcfg-br0

DEVICE=br0

TYPE=Bridge

ONBOOT=yes

BOOTPROTO=static

IPADDR=192.168.0.100

GATEWAY=192.168.0.1

NETMASK=255.255.255.0

DNS1=192.168.0.1

DELAY=0

5.重启网络

[root@localhost]# service NetworkManager stop  //这个关闭掉就行

停止 NetworkManager 守护进程：                             [确定]

注释：为什么关闭它呢～因为它和KVM桥接网卡冲突！

#chkconfig NetworkManager off 

注释：永久关闭该服务！！！不然系统重启后还会自己再把这个服务开启的哟～

[root@localhost rules.d]# service network restart

6.用virt-install生成.img文件（参数含义在上一篇KVM初体验已有注释）

# virt-install --name=ubuntu1 

--ram 1024 --vcpus=1 

--disk path=/root/ubuntu1.img,size=10 

 --accelerate --cdrom /root/redhat6.4.iso 

--graphics vnc,port=5920 --network bridge=br0

[root@localhost ~]# vi /etc/libvirt/qemu.conf 

vnc_listen = "0.0.0.0"

user = "root"               //去掉注释

group = "root"              //去掉注释

dynamic_ownership = 0       //去掉注释，把1改为0

7.启动虚拟机

虚拟机使用方法：

virsh  destroy       虚拟机名        #关闭虚拟机

virsh  undefine      虚拟机名        #删除虚拟机

virsh  start         虚拟机名        #开启虚拟机

virsh   list   --all 显示所有虚拟机

virsh   console      虚拟机名        #连接虚拟机

手动安装完毕，现在就可以在命令行里秀操作了。

五、自动化脚本安装KVM

#!/bin/bash

echo "[1] 配置YUM"

echo "[2] 安装KVM工具"

echo "[3] 设置桥接"

echo "[4] 手动安装虚拟机"

echo "[5] 查看虚拟机"

echo "[6] 开启虚拟机"

echo "[7] 关闭虚拟机"

echo "[8] 连接虚拟机"

echo "[9] 自动安装虚拟机"

echo "[0] 退出"

read -p "type:"  NUM

if [ $NUM = 0 ];then

exit;

elif [ $NUM = 1 ];then

#配置YUM

    rm -rf /etc/yum.repos.d/*;

cat > /etc/yum.repos.d/yum.repo << EOF

[yum]

name=yum

enabled=1

gpgcheck=0

baseurl=ftp://192.168.0.200/rhel6.4

EOF

elif [ $NUM = 2 ];then

#安装KVM工具

     LANG=en yum groupinstall "Virtualization*" -y;

elif [ $NUM = 3 ];then

#设置桥接

    chkconfig NetworkManager off;

    chkconfig network on;

    service NetworkManager stop;

    service network start;

    yum install  "bridge-utils" -y;

    service libvirtd restart;

    chkconfig libvirtd on;

    virsh iface-bridge eth0 br0;

elif [ $NUM = 4 ];then

#安装虚拟机

    read -p "输入虚拟机的名字："  NAME

    read -p "输入虚拟及硬盘大小(G): "  SIZE

    read -p "输入虚拟机内存大小(M): "  MEM

    ping -c 1 192.168.0.200 > /dev/null

    if [ $? -ne 0 ];then

    echo "无法接连192.168.0.200，请检查网络！";

    exit;

    fi

    virt-install --nographics -n $NAME --os-type=linux --os-variant=rhel6 -r $MEM --arch=x86_64 --vcpus=1 --disk path=/var/lib/libvirt/images/$NAME,size=$SIZE,format=qcow2 -w bridge=br0 -l ftp://172.16.8.100/rhel6.4 -x " console=ttyS0";

elif [ $NUM = 5 ];then

#查看虚拟机

virsh list --all

elif [ $NUM = 6 ];then

#开机

read -p "虚拟机名称: " XNAME

virsh start $XNAME;

elif [ $NUM = 7 ];then

#关闭

read -p "虚拟机名称: " XNAME  &> /dev/null

virsh destroy $XNAME;

elif [ $NUM = 8 ];then

#连接虚拟机

read -p "虚拟机名称: " XNAME

virsh console $XNAME;

elif [ $NUM = 9 ];then

#自动安装虚拟机

read -p "输入虚拟机的名字："  NAME

        read -p "输入虚拟及硬盘大小(G): "  SIZE

        read -p "输入虚拟机内存大小(M): "  MEM

        ping -c 1 192.168.0.200 > /dev/null

        if [ $? -ne 0 ];then

        echo "无法接连192.168.0.200，请检查网络！";

        exit;

        fi

        virt-install --nographics -n $NAME --os-type=linux --os-variant=rhel6 -r $MEM --arch=x86_64 --vcpus=1 --disk path=/var/lib/libvirt/images/$NAME,size=$SIZE,format=qcow2 -w bridge=br0 -l ftp://192.168.0.200/rhel6.4 -x "ks=ftp://192.168.0.200/rhel6.4.ks console=ttyS0";

 

 

else

echo "请输入:0~4数字!";

fi

注：此脚本已基本实现KVM自动化安装的基本功能。

总结

其实KVM的安装和使用都很方便简单的，大家要理解KVM各个参数的含义。最关键的就是KVM的网络桥接的设置，但是现在KVM在某些方面还是有一定的缺陷（比如创建光驱要关机等），希望会在后续版本中有所改进，在这里大家要多看官方软件自身的文档，会有很大的帮助。

分享原文地址：http://5323197.blog.51cto.com/5313197/1738805

一、定义

虚拟化是指通过虚拟化技术将一台计算机虚拟为多台逻辑计算机。在一台计算机上同时运行多个逻辑计算机，每个逻辑计算机可运行不同的操作系统，并且应用程序都可以在相互独立的空间内运行而互不影响，从而显著提高计算机的工作效率。

虚拟化技术可以扩大硬件的容量，简化软件的重新配置过程。CPU的虚拟化技术可以单CPU模拟多CPU并行，允许一个平台同时运行多个操作系统，并且应用程序都可以在相互独立的空间内运行而互不影响，从而显著提高计算机的工作效率。

二、虚拟化的类别

虚拟化的类别有很多，定义也很宽泛；无法做到全面详述。这里将简单说明：

1、模拟：emulation(底层和模拟架构不需要一致)；通过软件模拟是需要模拟环Ring0/1/2/3层；但是性能差；所以使用相对较少。

硬件 ---> Host ---> VMM(emulation) ---> Virtulization host

2、完全虚拟化(full-virtualization):只虚拟出环ring0(以CPU虚拟化来说明)

[]BT：二进制翻译技术(Binary Translate)；将模拟的CPU直接翻译成特权指令；限定虚拟结构平台和底层物理架构必须保持一致。基于软件的完全虚拟化。[/][]优点：不用修改GuestOS内核可以直接使用；应用广泛。[/][]缺点：在VMM捕获特权指令和翻译过程会导致性能的下降。[/]

[]硬件辅助虚拟化：5个指令环；在环0的底层加了环-1；环0的特权指令给了环-1；HVM(hardware virtulization machine)；属于硬件的完全虚拟化。[/]

3、半虚拟化(para-virtulization)：Guest明确知道自己运行在虚拟机上；；在执行特权指令时直接向hyper call调用；省去了特权指令的翻译过程。

[]优点：相对完全虚拟化；性能高；省去了特权指令的翻译过程。[/][]缺点：需要对GuestOS内核的修改；应用有限制。[/]

4、OS级别的虚拟化：硬件-->OS kernel-->多个用户空间

5、库虚拟化：wine

6、应用程序虚拟化：jvm

虚拟化的实现方式两种类型：

[]Type-I：Hypervisor；在虚拟机的管理上更加的彻底和可靠。[/][]Type-II：宿主机运行在硬件上；可以依赖宿主机的各种管理软件进行虚拟机管理。[/]

 

三、内存(Memory)虚拟化

内存虚拟化是虚拟机实现中的重要部分。在虚拟机中，虚拟出来的Guest OS和Host OS用的是相同的物理内存，却不能让它们相互影响到。如果OS在物理机上运行，只要OS提供页表，MMU会在访存时自动做虚拟地址(Virtual address, VA)到物理地址(Physical address, PA)的转化。而如果虚拟机上运行时，Guest OS经过地址转化到的“物理地址”并不是真实物理内存上的地址(GVA-->GPA)，因此还需要使用软件将其转化为真实物理内存地址(HPA)。也就是说Guest OS要访问VA需要经过GVA-->GPA-->HPA的转化。

[]MMU Virtualization[/]

Guest完成GVA-->GPA第一层转化，硬件同时完成GPA到HPA这第二层转化。第二层转化对于Guest OS来说是透明的。Guest OS访问内存时和在物理机运行时是相同的，所以可以实现全虚拟化。这种特性Intel和AMD都有支持。Intel称之为Extended Page Tables (EPT)，AMD称之为Nested Page Tables (NPT)。其优点是hypervisor节省了工作，缺点是需要硬件支持。

[]TLB Virtualization：tagged TLB[/]

TLB：转换后援存储器；原生只存储VA-->PA的对应关系。所以在虚拟内存中的两次转换会导致TLB的命中率失效。致使性能降低。所以使用tagged TLB，它缓存了Guest对象和GVA-->HPA的对应关系。需要CPU的支持。

四、I/O虚拟化的方式

[]模拟(完全虚拟)：完全使用软件来模拟真实硬件；模拟通常硬件；例如键盘鼠标；通过焦点捕获；焦点被哪个主机捕获就被哪个主机使用。性能很差。[/][]半虚拟化：对硬件驱动由前端(IO frontend)直接转到后端(IO backend)调用；通常仅适用于硬盘和网卡。性能高。[/][]IO-through:IO透传；直接分配给虚拟机物理设备；例如直接分配一个硬盘或网卡给虚拟机；需要硬件具备IO透传技术；在Xen下由Dom0分配；但是访问使用直接使用；不经过Dom0。需要硬件支持。[/]

I/O具体工作模式： VMM：对IO的驱动有三种模式：

[]自主VMM：由VMM自行提供驱动和控制台；[/][]混合VMM：借助于OS提供驱动；[/]

                              依赖于外部OS实现特权域                              自我提供特权域

[]寄宿式VMM：[/]

五、虚拟化网络

bridge：把原宿主机上的网卡当交换机；然后虚拟出一个桥来接收发往宿主机的数据包。

isolation mode：仅guest之间通信；不与外部网络和宿主机通信。

routed mode：与外部主机通信；依赖于静态路由指定到各Guest需经过pnet0。
host-only：不与外部主机通信。

nat：地址转换；在虚拟网卡和物理网卡之间建立一个nat转发服务器；对数据包进行源地址转换。

到此基本虚拟化基础以详解完成。

分享阅读原文：http://www.toxingwang.com/cloud/2885.html

 Elasticsearch更名为Elastic后，Kibana、Sense等一大票工具不再免费了 (具体价格可以参见 -Subscriptions)，让人有点伤心。呵呵，毕竟是个好项目，人家也要挣钱去养家糊口，希望之后的版本能够更稳定，特别是在系统升级的稳定性方面。最近刚将生产环境由1.2.2升级到 1.5.2，相对上一次1.1.1到1.2.2，这次总体还是平稳的，但还是有些意料之外的问题 - checksum check。

       Elasticsearch是构建在Java之上的、开源的、分布式搜索和分析引擎，因此JVM的性能对Elasticsearch性能至关重要。在负载超出节点所能承受的情况下，JVM垃圾内存回收的“Stop-The-World”会造成节点被踢出Elasticsearch集群。如果只是偶尔发生，Elasticsearch的冗余设计可以克服（如: Replica # = 1）。但如果是经常出现节点被踢出的情况，则会对整个集群的稳定造成很致命的影响，很可能会造成数据的丢失，这就需要认真排查一下节点被踢出的原因。
       如果是因为JVM的“Stop-The-World”造成的，则在Elasticsearch的日志中一定可以看到[monitor.jvm ]日志。根据程度不同，它分为 INFO, WARN和DEBUG。下面是一些笔者遇到过的例子：

Example 1

[2016-01-11 14:09:52,783][INFO ][monitor.jvm             ] [ES-DIAG2-16-data] [gc][young][3402090][244044] duration [887ms],collections [1]/[1.5s], total [887ms]/[3.3h], memory [4.5gb]->[4gb]/[6.9gb],all_pools {[young] [499.4mb]->[782.8kb]/[532.5mb]}{[survivor][32.7mb]->[30.2mb]/[66.5mb]}{[old] [3.9gb]->[3.9gb]/[6.3gb]}

上面这个例子的情况无须紧张，只是young gc，并且只用了887ms，对于Elasticsearch而言，没有啥影响。唯一需要留心的是，如果在日志中出现连续的和长时间的young gc，则需要引起警觉，可能是你的Heap内存分配不够。

Example 2

[2016-01-11 15:54:14,630][WARN][monitor.jvm             ] [ES-DIAG-35-data] [gc][old][76581][22] duration [3.1m], collections[2]/[3.1m], total [3.1m]/[3.1m], memory [3gb]->[1.2gb]/[3.4gb], all_pools{[young] [251mb]->[74.9mb]/[266.2mb]}{[survivor][25.8mb]->[0b]/[33.2mb]}{[old] [2.8gb]->[1.1gb]/[3.1gb]}

如果这种JVM出现，则你的节点一定被踢出了集群。old gc是比较耗时，上面这个例子用了3.1分钟，一定是出了啥大事，要不是然“世界”不会停转这么久的，呵呵！

Example 3

[2016-01-11 17:33:33,287][WARN][monitor.jvm             ] [ES-DIAG-X-master] [gc][old][160117][1326] duration [41.4s], collections [2]/[42.4s],total [41.4s]/[4.7h], memory [3.4gb]->[3.4gb]/[3.4gb], all_pools {[young][266.2mb]->[266.2mb]/[266.2mb]}{[survivor][33.2mb]->[33.2mb]/[33.2mb]}{[old] [3.1gb]->[3.1gb]/[3.1gb]}

       这个例子相对于例-2而言更为严重，虽然old gc只让“世界”停了41.4秒，但gc之后，young，survivor和old都已经没有有可用的内存空间了。这种情况发生时，你会看到日志中满满的都是这样的日志，也一定会有 "java.lang.OutOfMemoryError: Java heap space"相伴。你摊上事儿了，摊上大事儿了，呵呵！
 
       一般情况下造成JVM "Stop-The-World"的原因是由于heap内存分配不够，适当的增加内存可以解决问题。当然也不是heap内存越大越好，32GB是个极限，超过这个极限性能反而会下降，具体请参阅Limiting Memory Usage 和 Heap: Sizing and Swapping。

       此外，造成JVM "Stop-The-World"的原因也是多方面的，没有包治百病的神药，需要去分析和测试实际生产环境下Elasticsearch集群的负载和配置。Elasticsearch已经提供了很多内部参数帮助我们了解系统节点的运行情况，建议大家好好阅读Monitoring Individual Nodes 这篇文档，了解这些参数的意义。Six Ways to Crash Elasticsearch 也给出一些可以让Elasticsearch崩溃的例子。

分享原文：http://blog.csdn.net/quicknet/article/details/45148447
参考：http://jprante.github.io/2012/11/28/Elasticsearch-Java-Virtual-Machine-settings-explained.html