再说 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