虚拟技术

首页虚拟技术
10
Oct
0

Mesos安装

使用yum安装很方便,这里就使用yum安装Mesos,手动安装参见官网安装步骤,这里默认已经安装了zookeeper。

节点设计:
node1:mesos-master
node2:mesos-slave
node3:mesos-slave

①每个节点添加mesosphere的yum源
rpm -Uvh http://repos.mesosphere.io/el/7/noarch/RPMS/mesosphere-el-repo-7-1.noarch.rpm

②每个节点安装mesos
yum -y install mesos marathon

③每个节点配置mesos
配置zookeeper的地址
vim /etc/mesos/zk
zk://172.18.2.94:2181,172.18.2.95:2181,172.18.2.96:2181/mesos

④mesos-master节点配置
vi /etc/mesos-master/quorum
(在里面添加一个数字,数字大小不小于master的数量除以2,这里测试一个master,填1就可以)
vi /etc/mesos-master/ip
(添加master的ip,默认是127.0.0.1,只做显示用)
vi /etc/mesos-master/hostname>(添加master的hostname,默认为localhost,主要在mesos集群间使用,不是机器的hostname,只做显示用)

⑤mesos-slave节点配置
如果要运行dockers,则要配置docker启动
(Note:slave节点都必须安装docker并且docker的版本必须一致,否则下面的配置会导致slave节点启动不了)
echo 'docker,mesos'
/etc/mesos-slave/containerizers
echo '5mins'
/etc/mesos-slave/executor_registration_timeout

⑥服务配置
由于yum安装会把mesos-master和mesos-slave添加到开机自启动,所以:

mesos-master节点需要停止slave服务并关闭开机启动
systemctl stop mesos-slave.service
systemctl disable mesos-slave.service

mesos-slave节点需要停止master服务并关闭开机启动
systemctl stop mesos-master.service
systemctl disable mesos-master.service

⑦启动服务
systemctl restart mesos-master.service
systemctl restart mesos-slave.service

启动服务后访问WebUI:http://mesos-master:5050/

作者:扳掘de
链接:http://www.jianshu.com/p/257f44167c45
來源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

10
Oct
0

Apache Mesos总体架构

  1. 前言
    同其他大部分分布式系统一样,Apache Mesos为了简化设计,也是采用了master/slave结构,为了解决master单点故障,将master做得尽可能地轻量级,其上面所有的元数据可以通过各个slave重新注册而进行重构,故很容易通过zookeeper解决该单点故障问题。

(什么是apache mesos?参考:《统一资源管理与调度平台(系统)介绍》,本文分析基于Mesos SVN Revision 1327410)

  1. Apache mesos中的基本术语解释
    (1) Mesos-master:Mesos master,主要负责管理各个framework和slave,并将slave上的资源分配给各个framework

(2) Mesos-slave:Mesos slave,负责管理本节点上的各个mesos-task,比如:为各个executor分配资源
(3) Framework:计算框架,如:Hadoop,Spark等,通过MesosSchedulerDiver接入Mesos
(4) Executor:执行器,安装到mesos-slave上,用于启动计算框架中的task。
当用户试图添加一种新的计算框架到Mesos中时,需要实现一个Framework scheduler和executor以接入Mesos。

  1. 总体架构
    Apache Mesos由四个组件组成,分别是Mesos-master,mesos-slave,framework和executor。

Mesos-master是整个系统的核心,负责管理接入mesos的各个framework(由frameworks_manager管理)和slave(由slaves_manager管理),并将slave上的资源按照某种策略分配给framework(由独立插拔模块Allocator管理)。
Mesos-slave负责接收并执行来自mesos-master的命令、管理节点上的mesos-task,并为各个task分配资源。mesos-slave将自己的资源量发送给mesos-master,由mesos-master中的Allocator模块决定将资源分配给哪个framework,当前考虑的资源有CPU和内存两种,也就是说,mesos-slave会将CPU个数和内存量发送给mesos-master,而用户提交作业时,需要指定每个任务需要的CPU个数和内存量,这样,当任务运行时,mesos-slave会将任务放到包含固定资源的linux container中运行,以达到资源隔离的效果。很明显,master存在单点故障问题,为此,mesos采用了zookeeper解决该问题。
Framework是指外部的计算框架,如Hadoop,Mesos等,这些计算框架可通过注册的方式接入mesos,以便mesos进行统一管理和资源分配。Mesos要求可接入的框架必须有一个调度器模块,该调度器负责框架内部的任务调度。当一个framework想要接入mesos时,需要修改自己的调度器,以便向mesos注册,并获取mesos分配给自己的资源, 这样再由自己的调度器将这些资源分配给框架中的任务,也就是说,整个mesos系统采用了双层调度框架:第一层,由mesos将资源分配给框架;第二层,框架自己的调度器将资源分配给自己内部的任务。当前Mesos支持三种语言编写的调度器,分别是C++,java和python,为了向各种调度器提供统一的接入方式,Mesos内部采用C++实现了一个MesosSchedulerDriver(调度器驱动器),framework的调度器可调用该driver中的接口与Mesos-master交互,完成一系列功能(如注册,资源分配等)。
Executor主要用于启动框架内部的task。由于不同的框架,启动task的接口或者方式不同,当一个新的框架要接入mesos时,需要编写一个executor,告诉mesos如何启动该框架中的task。为了向各种框架提供统一的执行器编写方式,Mesos内部采用C++实现了一个MesosExecutorDiver(执行器驱动器),framework可通过该驱动器的相关接口告诉mesos启动task的方法。

10
Oct
0

如何使用Swarm

有3台机器:
sclu083:10.13.181.83
sclu084:10.13.181.84
atsg124:10.32.105.124
利用这三台机器创建一个Docker集群,其中sclu083同时充当swarm manager管理集群。

Swarm安装

最简单的安装Swarm的方式就是用Docker官方提供的Swarm镜像:

$ sudo docker pull swarm
Docker集群管理需要服务发现(Discovery service backend)功能。Swarm支持以下几种discovery service backend:Docker Hub上面内置的服务发现功能,本地的静态文件描述集群(static file describing the cluster),etcd(顺带说一句,etcd这玩意貌似很火很有前途,有时间研究下),consul,zookeeper和一些静态的ip列表(a static list of ips)。本文会详细介绍前面两种方法backend的使用。

在使用Swarm进行集群管理之前,需要先把准备加入集群的所有的节点的docker deamon的监听端口修改为0.0.0.0:2375,可以直接使用 sudo docker –H tcp://0.0.0.0:2375 &命令,也可以在配置文件中修改

$ sudo vim /etc/default/docker
在文件的最后面添加下面这句

D0OCKER_OPTS="-H 0.0.0.0:2375 –H unix:///var/run/docker.sock"
这里写图片描述

注意:一定是要在所有的节点上进行修改,修改之后要重启docker deamon

$ sudo service docker restart
第一种方法:使用Docker Hub上面内置的服务发现功能

第一步
在任何一个节点上面执行swarm create命令来创建一个集群标志。这条命令执行完毕之后,swarm会前往Docker Hub上内建的发现服务中获取一个全球唯一的token,用以唯一的标识swarm管理的Docker集群。

$ sudo docker run --rm swarm create
我们在sclu084 这台机器上执行上面的命令

这里写图片描述

返回的token是d947b55aa8fb9198b5d13ad81f61ac4d,这个token一定要记住,因为接下来的操作都会用到这一个token。

第二步
在所有的要加入集群的机器上面执行swarm join命令,把机器加入集群。

本次试验就是要在所有的三台机器上执行命令。

$ sudo docker run –-rm swarm join –addr=ip_address:2375 token://d947b55aa8fb9198b5d13ad81f61ac4d
在IP地址为10.13.181.84机器上面执行

这里写图片描述

执行这条命令后不会立即返回 ,我们手动通过Ctrl+C返回。

第三步
启动swarm manager。

因为我们要让sclu083充当Swarm管理节点,所以我们要在这台机器上面执行swarm manage命令

$ sudo docker run –d –p 2376:2375 swarm manage token:// d947b55aa8fb9198b5d13ad81f61ac4d
重点内容需要注意的是:在这条命令中,第一:要以daemon的形式运行swarm;第二:端口映射:2376可以更换成任何一个本机没有占用的端口,一定不能是2375,否则就会出问题。

执行结果如下如所示:

这里写图片描述

执行完这个命令之后,整个集群已经启动起来了。

现在可以在任何一个节点上查看集群上的所有节点了。

这里写图片描述

之后可以在任何一台安装了docker的机器上面通过命令(命令中要指明swarm maneger 机器的IP地址和端口)在这个集群上面运行Dcoker容器操作。

现在在10.13.181.85这台机器上面查看集群的节点的信息。info命令可以换成任何一个Swarm支持的docker命令,这些命令可以查看官方文档

$ sudo docker –H 10.13.181.83:2376 info
这里写图片描述

由上图的结果,我们可以发现一个问题:明明这个小集群中是有3个节点的,但是info命令只显示了2个节点。还缺少节点10.32.105.124。为什么会出现这个情况呢?

因为10.32.105.124这台机器没有设置上面的docker daemon监听0.0.0.0:2375这个端口,所以Swarm没办法吧这个节点加入集群中来。

在使用Docker Hub内置的发现服务时,会出现一个问题,就是使用swarm create时会出现

time="2015-04-21T08:56:25Z" level=fatal msg="Get https://discovery-stage.hub.docker.com/v1/clusters/d947b55aa8fb9198b5d13ad81f61ac4d: dial tcp: i/o timeout"
类似于这样的错误,不知道是什么原因,有待解决。(可能是防火墙的问题)

当使用Docker Hub内置的服务发现功能出现问题时,可以使用下面的第二种方法。

第二种方法:使用文件

第二种方法相对而言比第一种方法要简单,也更不容易出现timeout的问题。

第一步
在sclu083这台机器上新建一个文件,把要加入集群的机器的IP地址写进去

这里写图片描述

第二步
在sclu083这台机器上面执行swarm manage命令:

$ sudo docker run –d –p 2376:2375 –v $(pwd)/cluster:/tmp/cluster swarm manage file:///tmp/cluster
这里写图片描述

注意:这里一定要使用-v命令,因为cluster文件是在本机上面,启动的容器默认是访问不到的,所以要通过-v命令共享。还有,file:///千万不能忘记了。

可以看到,swarm已经运行起来了。现在可以查看下集群节点信息了,使用命令:

$ sudo docker run –rm –v $(pwd)/cluster:/tmp/cluster swarm list file:///tmp/cluster
这里写图片描述

(在使用文件作为服务发现的时候,貌似manage list命令只能在swarm manage节点上使用,在其他节点上好像是用不了)

好了,现在集群也已经运行起来了,可以跟第一种方法一样在其他机器上使用集群了。同样在sclu085 机器上做测试:

这里写图片描述

可以看到,成功访问并且节点信息是正确的。接下来可以把上面的info命令替换成其他docker可执行命令来使用这个晓得Docker集群了。

Swarm调度策略

Swarm在schedule节点运行容器的时候,会根据指定的策略来计算最适合运行容器的节点,目前支持的策略有:spread, binpack, random.

Random顾名思义,就是随机选择一个Node来运行容器,一般用作调试用,spread和binpack策略会根据各个节点的可用的CPU, RAM以及正在运行的容器的数量来计算应该运行容器的节点。

在同等条件下,Spread策略会选择运行容器最少的那台节点来运行新的容器,binpack策略会选择运行容器最集中的那台机器来运行新的节点(The binpack strategy causes Swarm to optimize for the container which is most packed.)。

使用Spread策略会使得容器会均衡的分布在集群中的各个节点上运行,一旦一个节点挂掉了只会损失少部分的容器。

Binpack策略最大化的避免容器碎片化,就是说binpack策略尽可能的把还未使用的节点留给需要更大空间的容器运行,尽可能的把容器运行在一个节点上面。

过滤器

Constraint Filter

通过label来在指定的节点上面运行容器。这些label是在启动docker daemon时指定的,也可以写在/etc/default/docker这个配置文件里面。

$ sudo docker run –H 10.13.181.83:2376 –name redis_083 –d –e constraint:label==083 redis
Affinity Filter

使用-e affinity:container==container_name / container_id –-name container_1可以让容器container_1紧挨着容器container_name / container_id执行,也就是说两个容器在一个node上面执行(You can schedule 2 containers and make the container #2 next to the container #1.)

先在一台机器上启动一个容器

$ sudo docker -H 10.13.181.83:2376 run --name redis_085 -d -e constraint:label==085 redis
接下来启动容器redis_085_1,让redis_085_1紧挨着redis_085容器运行,也就是在一个节点上运行

$ sudo docker –H 10.13.181.83:2376 run –d –name redis_085_1 –e affinity:container==redis_085 redis
通过-e affinity:image=image_name命令可以指定只有已经下载了image_name的机器才运行容器(You can schedule a container only on nodes where the images are already pulled)

下面命令在只有redis镜像的节点上面启动redis容器:

$ sudo docker –H 100.13.181.83:2376 run –name redis1 –d –e affinity:image==redis redis
下面这条命令达到的效果是:在有redis镜像的节点上面启动一个名字叫做redis的容器,如果每个节点上面都没有redis容器,就按照默认的策略启动redis容器。

$ sudo docker -H 10.13.181.83:2376 run -d --name redis -e affinity:image==~redis redis
Port filter

Port也会被认为是一个唯一的资源

$ sudo docker -H 10.13.181.83:2376 run -d -p 80:80 nginx
执行完这条命令,任何使用80端口的容器都是启动失败。

10
Oct
0

KVM虚拟机

Kernel-based Virtual Machine的简称,是一个开源的系统虚拟化模块,自Linux 2.6.20之后集成在Linux的各个主要发行版本中。它使用Linux自身的调度器进行管理,所以相对于Xen,其核心源码很少。KVM目前已成为学术界的主流VMM之一。
KVM的虚拟化需要硬件支持(如Intel VT技术或者AMD V技术)。是基于硬件的完全虚拟化。而Xen早期则是基于软件模拟的Para-Virtualization,新版本则是基于硬件支持的完全虚拟化。但Xen本身有自己的进程调度器,存储管理模块等,所以代码较为庞大。广为流传的商业系统虚拟化软件VMware ESX系列是基于软件模拟的Full-Virtualization。

一、安装准备
1.确定机器有VT
终端输入命令: grep vmx /proc/cpuinfo (INTEL芯片)
grep svm /proc/cpuinfo (AMD芯片)
不知道芯片的生产厂商则输入:egrep '(vmx|svm)' /proc/cpuinfo
如果flags: 里有vmx 或者svm就说明支持VT;如果没有任何的输出,说明你的cpu不支持,将无法成功安装KVM虚拟机。

  1. 确保BIOS里开启VT
    Intel(R) Virtualization Tech [Enabled]

如有必要,还需在BIOS中开启VT-d

  1. 确保内核版本较新,支持KVM
    用uname –r查看内核版本,如果在2.6.20以下的linux版本,需升级内核。

二、安装KVM
下面就Ubuntu和CentOS下安装使用KVM虚拟机做介绍:
Ubuntu 中用guest登陆,安装KVM的命令为:
sudo apt-get install kvm qemu qemu-kvm virt-manager kernel-package linux-source kqemu-source build-essential
kvm安装成功后会有/dev/kvm,如果无需图形管理器,只需要安装前三个即可。
再来查看下KVM是否安装成功,执行:virsh -c qemu:///system list
如果输入结果像下面这样的,那么成功了:
Connecting to uri: qemu:///system

Id Name State

注1:CentOS中安装时,先要选择Selinux为enable,使用命令

system-config-securitylevel-tui

可查看或修改selinux的状态。
注2: CentOS中用root登陆时则安装命令为:
yum install kvm kmod-kvm qemu
再装入kvm模块:modprobe kvm-intel (Intel机器) 或者 modprobe kvm-amd (amd机器)
注3:可以用以下命令来检查是否装入kvm模块:
/sbin/lsmod | grep kvm
如果输出关于kvm版本的信息则已装入kvm模块
注4: 安装好后,可使用qemu-kvm命令,输入该命令,如果系统显示未知的命令,可查看/usr/libexec中是否有qemu-kvm可执行文件,如果有,将其拷贝到/bin目录下即可。如果确实按照上面的步骤进行了,却在/bin,/usr/libexec,/usr/bin,/usr/sbin里都找不到qemu-kvm可执行文件,可执行以下命令:

yum provides "*/qemu-kvm"

注5:安装新内核后,可能有部分软件版本过低,不兼容。比如firefox因版本过低,无法启动。
CentOS下可使用如下命令更新该软件(以firefox为例):

yum update firefox

三、在KVM下安装虚拟机
1.用QEMU创建磁盘镜像
sudo qemu-img create –f qcow windows.img 8G
注:在CentOS和新版Qemu中为:qemu-img create –f qcow2 windows.img 8G
2.使用KVM安装Guest VM
光盘安装:
sudo kvm –localtime –cdrom /dev/cdrom -m 512 -boot d win2.img
硬盘安装:
sudo kvm –localtime –m 512 –hda windows.img –cdrom winxp.iso –boot d –clock –rtc –no-acpi
注:官方推荐使用 -no-acpi 参数,原因是 qemu/kvm不太支持,可能造成 cpu 的占用偏高。
注1:CentOS下硬盘安装为 qemu-kvm –localtime –m 512 –hda windows.img –cdrom winxp.iso –boot d –no-acpi 即需要去掉了-clock rtc选项,否则会出现无法初始化时钟。
注2:CentOS quest mouse: export SDL_VIDEO_X11_DGAMOUSE=0可解决VM中无法识别USB鼠标的问题。
注3: 安装win 7时,不能使用-no-acpi选项。
使用编辑
KVM启动Guest
① sudo kvm –boot c –m 512
–hda windows.img
② sudo kvm -boot c
-m 512
-hda /home/lm/kvm/winxp.img
-localtime
-net nic,vlan=0,macaddr=52-54-00-12-34-01 -net tap,vlan=0,df=h,ifname=tap0,script=no
-clock rtc
-soundhw es1370
-smp 2
注意:在KVM-87下,请去掉df=h
-m 512 分配512MB的内存
-hda /home/lm/kvm/winxp.img
-localtime 使用本地时间(一定要加这个参数,不然虚拟机时间会有问题)
-net nic,vlan=0,macaddr=52-54-00-12-34-01 -net tap,vlan=0,df=h,ifname=tapo,script=no
使用网络,并连接到一个存在的网络设备tap0,注意mac地址一定要自己编一个,特别是如果你虚拟了多个系统并且要同时运行的话,不然就MAC冲突了,在KVM-87下去掉df=h
-boot d 从光盘启动 (从镜像启动也是用这个。从硬盘启动则为 -boot c )
-smp 2 smp处理器个数为2个,如果你是4核处理器,后面的数字就为4
-clock rtc
使用rtc时钟(如果不开启此选项,WINXP可能会很慢)
KVM管理工具编辑

能够管理KVM的工具很多。首先是单个资源的基础虚拟化管理,有开源的虚拟化工具集libvirt,通过命令行接口提供安全的远程管理,可管理单个系统。
然后是管理全部运行KVM的多个服务器,有两种:用Red Hat Enterprise Virtualization-Management,即RHEV-M(管理多个RHEV-H系统)和IBM Systems Director VMControl(管理多个RHEL系统)。
最后有Tivoli产品。包括Tivoli Provisioning Manager、Tivoli Service Automation Manager与Tivoli Monitoring for Virtual Servers。
IBM Systems Director VMControl
IBM Systems Director VMControl既能实现异构多平台管理,也能实现异构多系统管理。VMControl是IBM平台管理方案Systems Director的一部分,覆盖了虚拟化管理三个关键领域:虚拟化、管理与自动化。VMControl也可作为独立的产品插件使用。
前不久,IBM发布了新版VMControl 2.4,可管理KVM与其他hypervisor。VMControl即能管理物理资源也能管理虚拟资源,还能管理异构hypervisor。用户在现有运行VMware的环境中再安装KVM,管理也无压力。
VMControl 2.4允许跨平台跨hypervisor的镜像管理,降低了复杂性、提升了生产效率。该软件目前支持IBM PowerVM、z/VM VMware、Microsoft Xen 与KVM服务器虚拟机技术。主要分为三个版本:
VMControl Express Edition:轻松管理虚拟机。发现虚拟化资源,了解系统运作情况,并能虚拟工作负载。包括查看、创建、修改与删除虚拟机;开启、停止与迁移虚拟机,以及管理多hypervisor。
VMControl Standard Edition:侧重管理虚拟机镜像。添加对虚拟镜像库的完整支持,包括创建、捕捉、输入和部署镜像。自动化资源配置并能移动资源。
VMControl Enterprise Edition:自动化工作负载配置。创建并启用系统池管理,自动移动工作负载,完全支持KVM。
Tivoli产品系列
Tivoli是IBM Systems Director与VMControl的有益补充。提供高级别的端到端管理功能。主要的Tivoli产品已经能够支持KVM。Tivoli重要功能有如下三个:
IBM Tivoli Monitoring:通过对候选虚拟化服务器历史趋势的分析,作出整合级别的优先次序。此外,让用户对系统事件作出最佳反应。
Tivoli Provisioning Manager:为物理与虚拟软硬件提供端到端的自动功能。包括发现并追踪虚拟资源、同时创建上百台虚拟机,以及自动为Linux服务器配置软件。
Tivoli Service Automation Manager:自动请求、部署、监控并管理云计算服务。通过自动化与对技能需求的降低,减少了服务交付成本,同时交付了高度标准化的IT服务,节省了IT管理员时间去完成高价值任务。
RHEV-M
RHEV-M(Red Hat Enterprise Virtualization-Management)使用图形用户界面管理物理与逻辑资源。允许管理员查看并管理虚拟机及其镜像,还支持热迁移,配置高可用性集群。随着RHEV 3.0的发布,RHEV-M 3.0也已可用。
作为红帽虚拟化平台的核心组件,RHEV-M管理控制台还能运行虚拟机的主机节点。可将RHEV-H hypervisor或带有虚拟化授权的R红帽企业Linux服务器配置为节点。这两种类型的节点使用KVM作为底层的hypervisor。RHEV-H hypervisor是设置RHEV节点的默认选项,它是裸机hypervisor,只包含了运行虚拟机RHEL代码的一个子集。正因为如此,RHEV-H主机的维护更加容易。此外,这些主机需要较少的补丁和维护就能确保其安全性。
RHEV-H基础文件系统只有100多MB而且运行在内存中,这避免了对基础镜像的改变。专用的安全增强型Linux策略以及防火墙阻塞了所有流量,保证了RHEV-H节点的安全性。
RHEV管理器同样还支持运行KVM的RHEL主机。这一特性使在现有RHEL环境中部署RHEV更加容易。
此外,还有很多开源工具可以管理KVM。比如,IBM、红帽等厂商加入到oVirt,这个开源虚拟化项目提供功能丰富的服务器虚拟化管理系统,为主机和子机提供高级功能,包括高可用性热迁移存储管理系统调度等