再说 Solaris Containers
正在看一份 Solaris 容器(Containers)的资料,现在写写学到的东西,学一点,写一点。有兴趣的请一起参加讨论。[ 本帖最后由 xiaobailong 于 2005-9-1 21:23 编辑 ] 1。主要内容包括一下几个方面:
* 服务器的整合: 就是从很多小的服务器,换成一个大的服务器,主要是为了省钱。
* Solaris资源管理:
* Solaris虚拟区:
* 虚拟区的技术细节:
* 开发人员最相关的:
* 虚拟区的安装和打包:
* 其它方面: 2。服务器整合目标:
最终目标当然是为了在完成同样功能的前提下,尽量少花钱。
把多个工作放在一个系统中来完成,能够很有效地降低费用。首先,硬件得到了充分的利用,如果每个应用放在一个或多个小的服务器上,每台机器就会有很多空闲时间,没有得到充分利用。而把多个应用放在一台大的服务器上,可以更好地共享资源。其次,不需要重复建设很多基础设施,例如机房的占地空间,空调的安装数量,用电量,等等。第三,降低了管理工作的工作量。
服务器整合所需要具备的条件有哪些呢?首先是资源控制,必须分配好每个应用所能利用的资源的上限,不然一个恶意的程序占用所有资源的话,会导致其它应用请求不能即使响应。其次是安全隔离,很多应用要求较高的安全性,必须把他们各自隔离开来,以免受其它应用的影响和窥探。第三必须有一定的容错性,例如一个应用出问题了,需要重新启动,这个时候不应该导致其它应用的中断。另外,要有delegated administrative control( 这个是什么,等我研究明白了再来说哈,如果有知道的,说一声。)最后,要有相对应的软件打包管理。 3。Solaris 容器概述
Solaris 容器是一种集成在Solaris 10中的新的服务器整合方案,是 Solaris操作系统的一部分。
它的基本设计理念是,在一个Solaris实例中实现多个独立的执行环境,这其中包括了资源独立,安全隔离,和错误孤立。它是一个轻量级的,灵活,有效率的服务器整合方案。它的建立和管理都很容易,而且管理员只要管理一个操作系统就可以了。
Solaris容器由两大部分组成,第一部分是资源管理,例如管理微处理器,内存等资源。另一部分是虚拟区,以实现安全性。 4。典型应用
Solaris容器可以应用在许多领域,包括
* 软件开发,例如可以设置一个容器实际使用,另一个容器测试新版本。
* 数据中心,例如把wen服务器,数据库,应用服务器等多种不同的应用整合到一台大机器上,由于各自的使用高峰期不同,提高了资源的整体使用率,保证了高峰期的响应速度。
* 怀有敌意的不信任的应用程序,例如从网上收到的一个程序,不能保证是否含有病毒或其它恶意代码的时候,就单开一个虚拟区给它,在里面试运行看看。
* 各种hosting环境,个人认为,这是最合适的应用了。例如每一个用户一个Solaris容器,都可以得到一个root用户和多个非 root用户。
* 面向广域网的服务,可以有效控制非法闯入所能接触到的资源和带来的破坏。 5。Solaris资源管理
Solaris资源管理是从早期 Solaris版本不断发展,增加新功能,不断完善过来的。它包含了许多实用的功能,其中包括
* 公平分享调度,用来控制微处理器工作周期的分配。而实际的执行周期也和其它程序的运行情况有关。比如我给三个程序各保留三分之一CPU周期,但是如果一个运行结束了的时候,其它两个程序就可以各用50%CPU周期了。使用公平分享调度确保了最低服务水准,保证了应用程序的最低CPU运行周期。
* 动态资源池,可以把某个或某几个微处理器放在一个资源池中,分配给某个项目及虚拟区专用。资源池中的微处理器可以动态调节。
* 扩展会计(extended accounting, 找不到更好的翻译了),可以统计任务和进程实际使用的系统及网络资源。
所有功能全部集成在Solaris操作系统中,不需要额外安装,更不需要另外购买。
资源保留可以基于Solaris中的项目(project)概念,也可以基于虚拟区( zone)概念来完成。 6。公平分享调度的计算方法
以项目为例,一个Solaris项目可以包含多个任务,一个任务可以包含多个进程。每个项目可以得到一个数字作为比重,这个数字在所有比重中所占的比例,就是保留给它的微处理器的运行周期的比例。例如图中四个项目,各自的比重是1:2:3:4,比重为3的那个项目,保留给它的微处理器份额就是3/(1+2 +3+4)=30%。 7。动态资源池
每个资源池拥有自己的微处理器组。项目和虚拟区都可以被绑定到资源池。一个项目或一个虚拟区只能绑定到一个资源池,而一个资源池可以绑定多个项目或虚拟区。资源池中的微处理器组是由所有绑定的项目和虚拟区共享的,也是排他的。
那么如何绑定呢?可以设置project.pool这个参数,或者使用poolbind这个命令,对于虚拟区 ,也可以使用虚拟区的配置程序。 8。扩展会计 (extended accounting)
扩展会计是对系统活动的综合记录,这些活动可以以项目为基础,也可以以虚拟区为基础来计算,另外也可以用其它传统的属性为基础来统计(都有哪些?)
这些统计结果可以被应用到和会计,记账,运营能力等等相关的更高级的应用程序中去。 9。Solaris虚拟区
Solaris虚拟区实现了一层虚拟化的操作系统层面,被虚拟化的包括了文件系统,设备,网络接口和进程。
通过这些虚拟化,Solaris虚拟区提供了私密性,安全性和故障隔离。私密性是说从一个虚拟区内不能看到它外部的东西,除非通过网络协议。安全性时说一个虚拟区内运行的程序,不能影响它外部的活动。通信要通过网络协议来完成。故障隔离是说一个虚拟区内的应用程序出问题了,不会影响到其他区的应用程序。所以,每一个虚拟区看起来就像是一个独立的操作系统,但是事实上这些
Solaris虚拟区是轻量级的,容易划分的,高效率的服务器整合方案。所占用的资源非常小,安装管理简单又方便。它和Solaris资源管理互为补充,也可以独立应用。
绝大多数应用程序不需要移植,直接就可以运行在Solaris虚拟区里,因为Solaris虚拟区里的应用程序二进制接口(ABI)和应用程序编程接口(API)是和以前的普通Solaris版本一致的。 10。Solaris虚拟区的结构
刚刚安装好的Solaris事实上只有一个全局区域(global zone),我把它简称为大区,另外在这个大区的基础上,可以划分局部区域(local zone),我把它们称为小区,就是通常所说的虚拟区。在一个Solaris实例中,大区只能有一个,小区的数量可以自由确定,最多可以达到8000个。每一个小区本身大概占用70-几百兆的硬盘空间,另外建议留给它40M的内存空间。
虽然每一个虚拟区看起来就像是一个独立的操作系统,但是事实上这些区全部是在一个Solaris实例中的。从图中可以看到,只有一个内核,其中也包括了虚拟区的管理模块。在内核上有一个虚拟层,实现各个小区的虚拟化,虚拟区就在这层虚拟层上。虚拟区可以安装不同的应用程序,或相同应用程序的不同版本,例如三个虚拟区,一个装了Apache1.3,一个装数据库,第三个装Apache2.0。 11。安全性
每一个虚拟区都有一个安全边界。
虚拟区中对特权(Privileges)进行了一定的限制。也就是说哪怕是虚拟区中的root,也不是具有所有Solaris中的48个特权的,例如改变系统时间。而且虚拟区不能扩大它自己的特权。
虚拟区有它自己的独立的命名空间(name space),例如自己的root用户和普通用户。
一个区里运行的进程不能影响其它区的活动。
Solaris的日志系统也考虑到了虚拟区。大区的管理员可以指定,是整个系统一起有共同的日志,还是每个虚拟区有各自的日志。如果是每个虚拟区有各自的日志,小区的管理员可以独立设置自己的参数。 12。虚拟区中的进程
每一个进程属于一个区,可以是大区,也可以是小区,但是不能更换自己所属的区。
在虚拟区中不允许进行某些特定的系统访问(system call),或是访问范围受到限制。
属于同一个区的进程之间的互动和平常一样。
一个虚拟区里只能看到并影响同一个区里的进程,而看不到区外的进程。为了实现这些,proc指令被虚拟化了。
从大区里能看到所有的进程,但是需要一定的特权 。Solaris 10一共定义了48个特权,可以赋予不同的用户和进程。想要从大区里控制所有的进程,需要proc_zone特权,一般只有大区的root用户才有。 13。虚拟区的文件系统
每一个虚拟区都有自己的根目录(/),这个根目录在大区有自己的绝对路径,是应该在设立虚拟区的时候指定的。
不象chroot(2)命令,虚拟区里的进程不能够操作超出虚拟区的范围。
虚拟区的文件系统有三种方式存在,可以是只读方式从大区mount上去的,也可以是安装的时候从大区复制过去的,还可以是读写方式mount上去的。缺省情况下,/usr, /lib, /sbin, 和 /platform 四个文件系统是采用只读方式的,这样一来节省了空间,二来安装公用程序比较方便,三来打补丁的时候比较快捷,只要打在大区,各个虚拟区也就都有了。 /etc和/opt两个文件系统是被复制到各个虚拟区的。大区的其它文件系统可以用读写方式mount到虚拟区去。NFS客户端程序可以在虚拟区运行,但是NFS服务器到目前为止仍然不可以。另外,automounter 也可以在虚拟区运行。 14。虚拟区的网络
每一个虚拟区除了有一个区名(zonename) 之外,都有自己的IP地址,可以是IPv4或IPv6的,甚至可以有多个IP地址。另外还有自己的主机名(hostname),端口范围(port space),和命名服务(naming service)。
在设置安装一个虚拟区的时候,可以用zonecfg指令中的add net选项来指定网络接口和IP地址。 在一个虚拟区运行当中,也可以用ifconfig指令来分配另外的IP地址给这个虚拟区。
虚拟区之间的相互通讯,虽然是通过网络通讯协议来实现,但是事实上是在Solaris内部完成的,而不是真正通过网络,所以虚拟区之间通讯是高带宽,低延迟,不会给网络造成负担。
同时,一个虚拟区能看到自己的网络使用情况,但是不能看到其他虚拟区的网络使用情况。应用程序可以绑定到INADDR_ANY(*.*.*.*)地址上去,也就是所有的地址,但是只能看到在自己的虚拟区里的通讯流量。 15。身份
每一个虚拟区都有自己的节点名(node name),域名(RPC domain name),时区,语言设定和命名服务(例如LDAP,NIS)。在第一次启动进入虚拟区的时候,系统会自动调用sysidtool(1M)命令来帮助设置这些内容。
虚拟区有自己单独的/etc/passwd文件,这意味着虚拟区可以拥有自己的root用户,虽然权限受到一定的限制。
不同虚拟区所拥有的用户名也可以是不同的,还可以有不同的命名服务(name service)。 16。服务管理
虚拟区也可以和服务管理设施(Service Management Facility, smf(5))结合使用。每一个虚拟区有自己的储藏室(repository),并在虚拟区内运行自己的svc.configd(1M)和 svc.startd(1M)实例。每一个虚拟区有自己的contract(4)文件系统。需要注意的是,虚拟区本身(尚)不能作为一种服务来实现。
虚拟区事实上一个学习SMF,并测试服务转变的很好的工具。
到目前为止,虚拟区支持标准多用户运行模式和单用户运行模式(用boot -s启动),而不支持其它的模式。 原帖由 xiaobailong 于 2005-9-2 15:18 发表
13。虚拟区的文件系统
每一个虚拟区都有自己的根目录(/),这个根目录在大区有自己的绝对路径,是应该在设立虚拟区的时候指定的。
不象chroot(2)命令,虚拟区里的进程不能够操作超出虚拟区的范围。
虚拟区的文件系统有三种方式存在,可以是只读方式从大区mount上去的,也可以是安装的时候从大区复制过去的,还可以是读写方式mount上去的。缺省情况下,/usr, /lib, /sbin, 和 /platform 四个文件系统是采用只读方式的,这样一来节省了空间,二来安装公用程序比较方便,三来打补丁的时候比较快捷,只要打在大区,各个虚拟区也就都有了。 /etc和/opt两个文件系统是被复制到各个虚拟区的。大区的其它文件系统可以用读写方式mount到虚拟区去。NFS客户端程序可以在虚拟区运行,但是NFS服务器到目前为止仍然不可以。另外,automounter 也可以在虚拟区运行
我想问一下
1。如果是只读方的话,那是不是就不能实现在不同的虚拟区上安装不同的软件了?
2。如果是读写方式Mount的,会不会对大区的安全性有影响? 原帖由 zat 于 2005-9-5 09:52 发表
我想问一下
1。如果是只读方的话,那是不是就不能实现在不同的虚拟区上安装不同的软件了?
2。如果是读写方式Mount的,会不会对大区的安全性有影响?
以缺省方式创建的虚拟区,根目录/是虚拟化了的一个文件系统;/usr, /lib, /sbin, /platform四个文件系统是只读方式;/etc, /opt两个文件系统是从大区复制到虚拟区的。
通常安装在/opt或其它子目录例如/mysoftware的软件,在每个虚拟区内都是不同的。如果软件需要安装到上述四个只读方式的目录下的时候,就用到读写方式mount.
举例来说, oracle需要安装到/oracle目录下,这个目录在虚拟区里本身就是可读可写可以创建的。
另一个例子,sap软件一般需要安装到/usr/sap子目录下。这个时候可以先用缺省方式创建一个虚拟区,/usr目录是只读方式的。然后用zonecfg里的add fs指令,把大区里创建好的一个文件系统以lofs方式mount到虚拟区里的/usr/sap上去,实现可读可写。
以这种lofs读写方式mount的文件系统,在大区里是不能够进行读写操作的,连大区的root也不行,所以不会对大区有安全性的影响。
除了lofs mount之外,另有几种其它的mount方式,其中有一些,例如直接mount raw disks,就可能会有安全隐患,在mount之前需要事先规划清楚才能杜绝这些隐患。 17。进程间的通信
IPC机制例如System V IPC, STREAMS, sockets, libdoor(3LIB) 以及loopback传输在虚拟区之内都工作良好。
重要的IPC命名空间在虚拟区内都被虚拟化了。(例如?何为虚拟化?)
虚拟区之间的通讯通过网络协议和软件回送(loopback)来进行。
Global zone can setup rendezvous too, although this is not commonly needed. 18。设备
虚拟区内包含一些“安全”的伪设备(pseudo devices) ,这些设备都存在于/dev 目录下。事实上,/dev目录在虚拟区内是可见的,而 /devices不可见。一些设备,例如/dev/random, /dev/console被认为是安全的,而另外一些例如/dev/ip被认为不安全。物理设备文件,例如raw盘,也可以被放在虚拟区内使用,但是通常没必要这么做。
通常使用zonecfg里的add device命令往虚拟区内增加设备。
虚拟区可以修改设备文件的参数,但是不可以mknod(2)。也就是说,所有的设备都必须在大区内可见,然后才可以增加到虚拟区内。 19。动态跟踪(DTrace)
动态跟踪也是Solaris 10的一个很有吸引力的新功能,对debug非常有用。不过到目前为止,动态跟踪只能够在大区内使用。但是可以使用zonename变量动态跟踪一些内容。
例如,计算虚拟区的系统调用(system calls)的数量,可以在大区内执行如下命令来完成:
global# dtrace -n 'syscall:::/zonename=="red"/ {@=count()}'
另外也可以用curpsinfo->pr_zoneid来获取虚拟区内的进程列表。
DTrace和虚拟区共同使用的话,在跟踪调试多层(multi-tier)应用程序的时候,特别有用。 20。微处理器(CPU)和虚拟区
缺省情况下,所有的虚拟区共享所有的微处理器。
当设置了资源池(resource pool, 前面讲过的)之后,就能对虚拟区所能看到和使用的为处理进行一定的限制。一个虚拟区只能见到自己绑定的那个资源池所包含的微处理器集(process set,包含一个或多个选定的微处理器)。那些用来获取CPU使用信息的命令,例如iostat(1M), mpstat(1M), prstat(1M), psrinfo(1M), sar(1M)等等,也都被虚拟化,而只提供这个资源池里包含的微处理器集的使用情况。在虚拟区使用sysconf(3C)和getloadavg可以得到微处理器集所含的CPU的数量。大量的kstat(3KSTAT)关于cpu, cpu_info和cpu_stat的统计数值也都被虚拟化了,从而只包含虚拟区的内容。
通过这些虚拟化措施,使软件的使用费可以限制在虚拟区的范围内。 21。什么程序可以在虚拟区内运行
那么要想软件可以在虚拟区内运行,需要满足哪些条件呢?
首先,凡是可以不需要root权限就可以运行的程序,都可以直接在虚拟区内运行,不需要任何改动。
其次,那些需要root权限对网络和文件系统进行操作的应用程序,如果不需要其它的I/O操作,也可以直接在虚拟区内运行,不需要任何改动。
第三,需要root权限区对一些设备进行直接操作的应用程序,例如磁盘分区,只有在对虚拟区进行相应的设置之后,才可以直接运行。这些程序也不需要改动。但是这样做有可能会产生安全隐患,应事先考虑周全,尽量避免。(这一点前面 zat 也问到了。)
而不可以在虚拟区内运行的也有一些,例如,那些需要对/dev/kmem设备进行直接操作的应用。 22。开发员要知道的
需要反复强掉的是,虚拟区没有改变现有的Solaris的应用程序接口,包括二进制接口(ABI)和编程接口(API)。因此,那些不需要root权限就能运行的程序,可以不做任何修改就直接在虚拟区内运行。
需要特殊权限的应用程序,绝大多数情况下也没有问题,当然也有一些限制。首先,某些特殊权限(privileges)在虚拟区内是不被允许拥有的,所以有些系统调用(system calls)会由于权限不足而失败。值得一提的是,使用truss(1)命令可以掌握这些失败的系统调用的情况;而使用ppriv(1)命令可以修改特权设置。其次,某些特定的命名空间也受到一些限制。第三,不是所有设备都可以在虚拟区内使用,这一点前面关于设备的一段也说到了。 23。受限制的特权
有一个表格,列出了受限制的特权(privileges)。在Solaris的48个privileges中,有19个在虚拟区受到了限制,它们是: cpc_cpu, dtrace_kernel, dtrace_proc, dtrace_user, gart_access, gart_map, net_rawaccess, proc_clock_highres, proc_lock_memory, proc_priocntl, proc_zone, sys_config, sys_devices, sys_ipc_config, sys_linkdir, sys_net_config, sys_res_config, sys_suser_compat, sys_time。 24。其它限制
就像前面回答zat网友问题的时候已经说过的一样,一些软件需要在/usr目录内进行写操作,这个时候可以用lofs(7FS)方式mount文件系统到虚拟区内,而且不会有安全问题产生。
如果想要更多了解Solaris文件系统的结构,可以参看Solaris中filesystem(5)的man page. 25。虚拟区的状态模型
创建一个虚拟区,可以使用命令行方式,也可以使用图形用户界面,还可以使用配置文件来创建。常用的命令有zonecfg, zoneadm, zlogin。图形用户界面是Solaris Container Manager程序。配置文件则是xml格式的。
虚拟区主要有设置(Configured), 安装(Installed),准备(Ready)和运行(running)几个状态。 26。文件类型和虚拟区安装
缺省情况下,所有在大区里打包的文件都会被安装到虚拟区。打包过的文件会被直接从大区的根目录复制到虚拟区,例外的情况是那些可修改文件 (editable,例如 configuration file)和变化文件(volatile, 例如log file或lock file), 详细信息可以在Solaris中查看pkgmap(4)的man page。
可修改文件和变化文件是从稀疏档案(sparse package archive)"stash"里复制过来的,因为"stash"里专门存放了这类文件的原始备份。
一个“节省类型的虚拟区”(sparse root zone)大约用掉70MB的空间,并且随着安装包的增多而增大。 27。虚拟区其它安装细节
在设置虚拟区的时候,可以自己确定,哪些目录将会以只读方式mount到虚拟区,使用的参数是inherit-pkg-dir,像是从小区从大区继承了这些包一样。对于这些目录里的文件,只有他们的包的元数据(package metadata)被复制,程序文本(scripts)被执行。
安装虚拟区所需的时间和空间,取决于大区中包的数量,以及哪些包被“继承(inherited)”。
如果一个虚拟区没有从大区“继承”任何包,这种虚拟区被定义为"whole root zone",而那些继承了至少一个子目录的虚拟区被称为"sparse root zone"。
一个whole root zone的应用例子是:在虚拟区里安装和运行JES(Java Enterprise System)的话,需要whole root zone。
页:
[1]
2