Solaris Zones 分区技术.docx
- 文档编号:5720650
- 上传时间:2023-05-09
- 格式:DOCX
- 页数:24
- 大小:38.99KB
Solaris Zones 分区技术.docx
《Solaris Zones 分区技术.docx》由会员分享,可在线阅读,更多相关《Solaris Zones 分区技术.docx(24页珍藏版)》请在冰点文库上搜索。
SolarisZones分区技术
SolarisZones分区技术
ChienYen,2005年3月
目录:
∙1.0介绍
o1.1SolarisZones功能:
SolarisContainers的组件
∙2.0SolarisZones软件的优点
∙3.0区域(Zone)创建和初启
o3.1区域配置和安装
o3.2使用zoneadmd(1M)初启区域
o3.3区域配置和初启样例
∙4.0区域安全性
o4.1进程权利管理
o4.2区域进程权限
∙5.0区域资源和服务虚拟
o5.1联网
o5.2文件系统
o5.3进程间通信(InterprocessCommunication,IPC)
o5.4设备
o5.5进程
o5.6资源管理
o5.7软件包和修补程序数据库
∙6.0区域限制
o6.1系统调用
o6.2库函数
o6.3命令
o6.4设备和接口特殊文件
∙7.0参考资料
1.0介绍
Solaris操作系统中的SolarisZones[1][2]功能是一种用于虚拟化操作系统服务的分区技术,可提供安全的隔离环境以便承载和运行各种应用程序。
区域是一个虚拟的操作系统环境,它是在Solaris操作系统的单个实例中创建的。
区域有两种类型:
全局区域(globalzone)和非全局区域(non-globalzone)。
全局区域包含一次SolarisOS的完全正常运行的安装,可由系统硬件来引导。
如果SolarisOS安装由系统硬件引导,它即为全局区域。
一个系统中只能运行一个全局区域。
全局区域管理员可使用zonecfg(1M)和zoneadm(1M)来创建非全局区域。
全局区域控制所有非全局区域的安装、维护、操作和损毁。
SolarisZones功能为非全局区域中运行的进程提供服务虚拟和名称空间隔离。
非全局区域中的进程与其他区域中的进程相互隔离。
这种隔离可防止非全局区域中运行的进程监视或影响其他区域中运行的进程。
对于非全局区域中运行的进程,即使具有超级用户凭证也不能查看或影响其他区域中的活动。
区域还提供一个抽象层,用于将应用程序与部署应用程序的计算机的物理属性分隔开,物理设备路径和网络接口名称都是这些属性的示例。
在任何支持Solaris10发行版的计算机中都可以使用区域。
单个物理服务器中的区域数上限为8192。
单个物理服务器中可以有效承载的区域数取决于在组合的所有区域中运行的应用程序的总资源需求。
1.1SolarisZones功能:
SolarisContainers的组件
Solaris容器是一个虚拟的运行时环境,它对工作负荷所使用的系统资源(例如CPU)进行了限制。
SolarisContainers将SolarisOS资源管理功能与SolarisZones相结合,以提供一个对工作负荷具有固定资源边界的虚拟环境。
工作负荷是一个或一组应用程序的所有进程的总和。
除进程实体外,SolarisOS还添加了两种用于标识工作负荷的功能:
项目和任务。
如果不使用Solaris资源管理功能,则SolarisOS在响应工作负荷要求时会为系统中的所有活动提供相同的资源访问权限。
借助SolarisOS中的资源管理功能,系统管理员可以分别处理各个工作负荷,并可分配工作负荷所能使用的资源数量。
通过这些资源管理功能,系统管理员可以执行下列操作:
∙限制访问特定资源
∙按优先级别为工作负荷提供资源
∙将工作负荷彼此隔离
工作负荷的概念已得到扩展,以便适用于SolarisZones。
每个区域都有自己的project(4)数据库。
区域范围内的限制已添加到资源控制中。
如果将SolarisZones与Solaris资源管理功能结合起来使用,系统管理员就可以创建具有特定资源边界的虚拟操作环境-区域。
2.0SolarisZones软件的优点
SolarisZones的主要优点是可以利用服务器整合来降低总体拥有成本(totalcostofownership,TCO)。
利用SolarisZones软件可以实现:
∙在单个物理服务器上的单个操作系统实例中创建多个虚拟操作环境-区域。
∙每个非全局区域都有自己的虚拟标识、文件系统、设备、联网、操作系统资源和安全性。
∙每个非全局区域都与全局区域之外的其他区域相互隔离。
∙将应用程序故障隔离并限制在一个非全局区域中。
∙仅通过联网进行区域间通信。
∙应用程序仍在使用SolarisABI/API,因此无需进行应用程序移植。
∙可以单独重新引导和关闭每个非全局区域,不会影响其他区域。
∙可为每个区域划分CPU和网络带宽等系统资源。
管理员可以利用Solaris资源管理机制来提供更精确的资源控制。
∙可以将应用程序环境的管理委托给非全局区域管理员。
3.0区域(Zone)创建和初启
3.1区域配置和安装
全局区域管理员使用zonecfg(1M)、zoneadm(1M)和zlogin(1M)来管理区域。
zonecfg(1M)为每个非全局区域创建区域配置文件/etc/zones/my-zone.xml。
my-zone.xml用于说明my-zone配置。
zoneadm(1M)将my-zone.xml作为输入,并使用live_upgrade(5)机制在/etc/zones/my-zone.xml的zonepath字段中指定的位置创建引导环境(bootenvironment,BE)。
而且,zoneadm(1M)还会启动zoneadmd(1M)守护进程,以便在创建非全局区域BE后管理区域状态转换。
非全局区域可处于以下状态之一:
∙CONFIGURED(已配置)
∙INCOMPLETE(不完整)
∙INSTALLED(已安装)
∙READY(就绪)
∙RUNNING(正在运行)
∙SHUTTING_DOWN(正在关闭)
∙DOWN(关闭)
在标准的非全局区域初启过程中,区域会经过以下状态:
CONFIGURED(已配置)->INSTALLED(已安装)->READY(就绪)->RUNNING(正在运行)(请参见图1)。
3.2使用zoneadmd(1M)初启区域
zoneadmd(1M)是一种系统守护进程,用于创建非全局区域虚拟平台及管理该虚拟平台的状态转换。
虚拟平台组件包括网络接口、设备、zoneadmd(1M)守护进程及区域控制台。
系统中的每个非全局区域都有一个zoneadmd(1M)进程。
zoneadmd(1M)的功能包括:
∙为客户机实现门服务器,以请求区域状态更改。
全局管理员使用zoneadm(1M)、zonecfg(1M)和zlogin(1M)来管理区域。
这些命令通过Solarislibdoor(3LIB)与zoneadmd(1M)进行通信。
∙与zoneadm(1M)、zonecfg(1M)和zlogin(1M)交互,以创建、初启和销毁非全局区域虚拟平台。
在典型的非全局区域初启过程中,zoneadmd(1M)执行下列操作:
o创建和初始化内核区域结构和钩子(hook)。
o创建/dev目录和文件。
o挂载文件系统。
my-zone.xml中的inherited-pkg-dir目录和/dev挂载为回送文件系统。
vfstab、/proc和/system/contract中的其他文件系统以及交换文件系统按常规方式挂载。
o与devfsadmd(1M)通信,以便放置该区域的设备。
o创建并配置区域的逻辑网络接口。
o实例化区域控制台设备。
每个非全局区域都有一个zcons(7D)驱动程序实例。
该驱动程序的每个实例都代表一个全局区域/非全局区域对。
o配置进程运行时属性,例如资源控制、池绑定和精确权限。
o启动区域的init(1M)进程。
o创建zsched(非全局区域的内核伪进程)。
在非全局区域引导过程中,zsched将启动init(1M)。
3.3区域配置和初启样例
以下是一个快速区域配置样例,其中区域名称为my-zone,IPv4地址为10.0.0.1:
global#zonecfg-zmy-zone
zonecfg:
my-zone>create
/*缺省为稀疏根模型,请参见第3.4节了解详细信息*/
zonecfg:
my-zone>setzonepath=/export/home/my-zone
zonecfg:
my-zone>addnet
zonecfg:
my-zone:
net>setaddress=10.0.0.1
zonecfg:
my-zone:
net>setphysical=eri0
zonecfg:
my-zone:
net>end
zonecfg:
my-zone>verify
zonecfg:
my-zone>commit
zonecfg:
my-zone>^D
在此处,创建了一个区域配置文件/etc/zones/my-zone.xml,其中包含上述参数以及若干个用于回送挂载文件系统的inherited-pkg-dir字段。
一旦建立了区域配置文件,全局区域管理员便可使用zoneadm(1M)来安装区域配置:
global#zoneadm-zmy-zoneinstall
执行完zoneadm(1M)install命令后,将使用live_upgrade(5)功能创建一个引导环境。
区域引导与引导常规的Solaris环境相似,区别在于使用zoneadm(1M)创建运行时区域:
global#zoneadm-zmy-zoneboot
此语句将引导区域。
在区域内挂载相应的文件系统,启动zoneadmd(1M)等等。
在安装后初次引导某一区域时,该区域没有用于命名方案的内部配置,没有语言环境(Locale)或时区,也没有超级用户口令等。
需要访问区域的控制台,以应答提示并进行设置。
应使用zlogin(1M)命令来执行此操作:
#zlogin-Cmy-zone
【连接到区域my-zone控制台】
3.4区域根文件系统
配置非全局区域的根文件系统有两种方法:
完全根模型(whole-rootmodel)和稀疏根模型(sparse-rootmodel)。
完全根模型将所有必需的软件包和任何选定的可选Solaris软件包安装到区域的专用文件系统中,因此可提供最大化的配置能力。
此模型的优点是:
允许区域管理员定制其区域的文件系统布局(例如,创建/usr/local),并可以添加任意非随附软件包或第三方软件包。
此模型的缺点是:
无法共享虚拟内存系统共享的可执行文件和共享库中的文本段,并且磁盘使用量也会显著增加-如此进行配置的每个非全局区域约增加2GB。
全局区域管理员使用zonecfg(1M)中的create-b子命令来创建完全根模型的区域(或者删除my-zone.xml中的inherited-pkg-dir目录)。
稀疏根模型只安装(即将pkginfo(4)参数SUNW_PKGTYPE设置为root的软件包)根软件包的子集,并使用只读的回送文件系统来获得访问其他文件的权限,从而可优化对象的共享。
这与配置无盘客户机的方式类似,其中/usr和其他文件系统通过网络与NFS挂载。
使用此模型时,缺省情况下会将目录/lib、/platform、/sbin和/usr挂载为回送文件系统。
此模型的优点在于可提供更高的性能,原因是可以有效地共享可执行文件和共享库,并且区域本身的磁盘使用量会小很多。
稀疏根模型只需要将大约100MB的文件系统空间用于区域本身。
4.0区域安全性
每个非全局区域都有一个安全边界。
该安全边界通过以下各项进行维护:
∙采用Solaris10进程权利管理(privileges(5))
∙名称空间(如/proc和/dev)隔离
∙仅通过网络进行的区域间通信(在IP内环回)
4.1进程权利管理
传统的UNIX权限模型将所有的权限与有效的uid0(根)关联。
这种要么全有要么全无的方法存在很多缺点:
∙不能使用有限的权限集扩展普通用户的能力。
∙每个具有权限的进程都对系统具有完全的支配权。
可以利用具有权限的进程对系统进行完全访问。
Solaris10OS通过实现进程权利管理[3]的原则解决了上述问题,该原则是将用户的权限限制为执行作业所需的权限。
进程权利管理通过权限集扩展了Solaris进程模型。
每个权限集包含零个或多个权限。
每个进程有四个权限集。
其中的一个权限集-有效权限集,决定进程是否可以使用特定权限。
这四个权限集包括:
∙有效权限集-程序在执行时使用的一组权限。
要使某一权限成为有效权限,该权限还必须包含在允许权限集中。
∙允许权限集-可用的一组权限。
权限可通过继承或分配供程序使用。
允许权限集是可继承权限集的子集。
可以从允许权限集中删除权限,但不能向该权限集添加权限。
可识别权限的程序会从程序的允许权限集中删除其从未使用过的权限。
这样,程序便可避免使用不正确地分配或继承的权限。
∙可继承权限集-进程可以从父进程处继承而来的一组权限。
子进程实际继承哪些权限由进程的启动方式以及该子进程的允许权限集控制。
对用户而言,可继承权限集包括一组基本的权限。
通过调用fork
(2)启动的程序继承父进程的所有权限,并可以将新权限添加至进程。
通过调用exec
(2)启动的程序继承父进程的所有权限。
但是,此类程序不能添加任何新权限。
也就是说,程序的允许权限集等于可继承权限集。
可继承权限集由限制权限集的值来限制。
∙限制权限集-进程及其后代可以继承的权限的上限。
缺省情况下,限制权限集包括所有权限。
这样,如果为用户分配的配置文件中包括一个已分配权限的程序,则用户可以运行该程序,因为分配的权限在用户的限制权限集内。
在执行时,并非允许权限集中的所有权限都可以使用。
限制权限集仅在执行exec
(2)时实施,从而允许进程在执行exec
(2)时删除权限,但在此时刻之前可以一直使用这些权限。
允许权限集是可继承权限集的子集。
可继承权限集由限制权限集的值来限制。
exec
(2)权限集变换规则如下所示:
其中
C.E-父进程的有效权限集
C.P-父进程的允许权限集
C.I-父进程的可继承权限集
C.L-父进程的限制权限集
C'.E-子进程的有效权限集
C'.P-子进程的允许权限集
C'.I-子进程的可继承权限集
C'.L-子进程的限制权限集
所有内核安全策略检查都只能使用权限来执行。
内核提供用户使用系统所需的基本权限集。
登录时,每个用户都会继承基本权限集。
可以使用ppriv
(1)修改基本权限集。
限制权限集通常是完整的权限集合。
目前,为权限集定义了48种权限。
privileges(5)可列出这些权限及其定义。
如果某一进程可识别权限,则其有效权限集将决定该进程的行为。
如果进程的权限识别状态(PrivilegeAwareState,PAS)是不可识别权限(notprivilegeaware,NPA),则进程会忽略权限模型。
进程的权限状态可以通过PAS进行扩展,PAS可取以下值:
∙可识别权限(Privilegeaware,PA)-完全忽略有效UID
∙不可识别权限(Notprivilegeaware,NPA)-行为几乎与传统进程完全相同
进程可以通过setpflags
(2)尝试成为NPA。
如果没有继承PA,内核会尝试在执行exec
(2)时删除PA。
4.2区域进程权限
在非全局区域中运行的所有进程都可以识别权限。
这意味着非全局区域中的所有进程都受创建进程时为其分配的权限集的约束。
系统创建非全局区域时,会创建一个内核伪进程zsched作为该区域的根进程。
非全局区域中的所有进程都是zsched的后代。
zsched的可继承权限集决定了该区域中进程的有效权限集。
下面的列表显示非全局区域中的进程所具有的权限。
由于非全局区域中进程的权限受限,因此某些系统可能返回错误。
在大多数情况下,拥有权限的进程将返回EPERM。
某些检查PRIV_CPC_CPU或PRIV_NET_RAWACCESS的系统调用会返回EACCESS。
第6.0节总结了在非全局区域中调用时可能返回错误的系统调用、库函数和命令。
所有权限区域权限
=========================================================
PRIV_CONTRACT_EVENTPRIV_CONTRACT_EVENT
PRIV_CONTRACT_OBSERVERPRIV_CONTRACT_OBSERVER
PRIV_CPC_CPU
PRIV_DTRACE_PROC
PRIV_DTRACE_USER
PRIV_DTRACE_KERNEL
PRIV_FILE_CHOWNPRIV_FILE_CHOWN
PRIV_FILE_CHOWN_SELFPRIV_FILE_CHOWN_SELF
PRIV_FILE_DAC_EXECUTEPRIV_FILE_DAC_EXECUTE
PRIV_FILE_DAC_READPRIV_FILE_DAC_READ
PRIV_FILE_DAC_SEARCHPRIV_FILE_DAC_SEARCH
PRIV_FILE_DAC_WRITEPRIV_FILE_DAC_WRITE
PRIV_FILE_LINK_ANYPRIV_FILE_LINK_ANY
PRIV_FILE_OWNERPRIV_FILE_OWNER
PRIV_FILE_SETIDPRIV_FILE_SETID
PRIV_IPC_DAC_READPRIV_IPC_DAC_READ
PRIV_IPC_DAC_WRITEPRIV_IPC_DAC_WRITE
PRIV_IPC_OWNERPRIV_IPC_OWNER
PRIV_NET_ICMPACCESSPRIV_NET_ICMPACCESS
PRIV_NET_PRIVADDRPRIV_NET_PRIVADDR
PRIV_NET_RAWACCESS
PRIV_PROC_CHROOTPRIV_PROC_CHROOT
PRIV_PROC_CLOCK_HIGHRES
PRIV_PROC_AUDITPRIV_PROC_AUDIT
PRIV_PROC_EXECPRIV_PROC_EXEC
PRIV_PROC_FORKPRIV_PROC_FORK
PRIV_PROC_INFOPRIV_PROC_INFO
PRIV_PROC_LOCK_MEMORY
PRIV_PROC_OWNERPRIV_PROC_OWNER
PRIV_PROC_PRIOCNTL
PRIV_PROC_SESSIONPRIV_PROC_SESSION
PRIV_PROC_SETIDPRIV_PROC_SETID
PRIV_PROC_TASKIDPRIV_PROC_TASKID
PRIV_PROC_ZONE
PRIV_SYS_ACCTPRIV_SYS_ACCT
PRIV_SYS_ADMINPRIV_SYS_ADMIN
PRIV_SYS_AUDITPRIV_SYS_AUDIT
PRIV_SYS_CONFIG
PRIV_SYS_DEVICES
PRIV_SYS_IPC_CONFIG
PRIV_SYS_LINKDIR
PRIV_SYS_MOUNTPRIV_SYS_MOUNT
PRIV_SYS_NET_CONFIG
PRIV_SYS_NFSPRIV_SYS_NFS
PRIV_SYS_RESOURCEPRIV_SYS_RESOURCE
PRIV_SYS_SUSER_COMPAT
PRIV_SYS_TIME
5.0区域资源和服务虚拟
SolarisZones提供了强健的分区解决方案,以便为进程虚拟计算机操作环境。
当非全局区域中的进程的活动与其他区域中的进程隔离时,这些进程能够访问在操作环境中需要的资源和服务。
这些资源和服务包括:
∙联网接口
∙文件系统
∙进程间通信(Interprocesscommunication,IPC)
∙设备
∙进程
∙资源管理功能
∙打包数据库
5.1联网
每个非全局区域都有自己的逻辑网络和回送接口。
上层流与逻辑接口之间的绑定受到限制,因此流只能与同一区域中的逻辑接口建立绑定。
同样,来自逻辑接口的包只能传递到此逻辑接口所在区域中的上层流。
与回送地址之间的绑定也保留在区域内,但有一项例外:
当一个区域中的流试图访问另一区域中某一接口的IP地址时。
此外,以下联网虚拟和限制适用于非全局区域:
∙可以控制区域使用的带宽。
使用捆绑的IPQoS功能并为特定区域的每个已配置IP地址配置带宽参数可以实现此功能。
∙IPQoS和IPSec配置只能在全局区域中进行。
通过为配置指定区域的IP地址,可以创建特定于区域的配置。
∙在非全局区域中不允许对传输层以下的层进行原始访问(例如,使用IP、ARP和DLPI与链路层通信)。
因此,使用DLPI直接与链路层(NIC设备驱动程序)通信时将出现错误。
snoop(1M)使用DLPI直接访问接口驱动程序,因此无法在非全局区域中工作。
∙以下联网功能仍为系统范围内的功能,只能由全局管理员进行配置:
o路由
oIP多路径(IPmultipathing,IPMP)
o移动IP
oDHCP客户机
o网络高速缓存和加速器(NetworkCacheandAccelerator,NCA)
o使用/etc/system和ndd(1M)进行联网调优
oIP过滤器
5.2文件系统
尽管可在各区域之间共享文件系统,但每个非全局区域都有自己的文件系统名称空间。
全局区域文件系统使用lofs(7FS)回送挂载到区域中。
除lofs、autofs、tmpfs、mntfs、ctfs、procfs和NFS之外,客户机还可以本地挂载到非全局区域中。
要从非全局区域中隐藏全局区域目录,例如/usr/local,全局区域管理员可在全局区域中创建一个空目录,并在相应目录顶部为该非全局区域配置回送挂载:
global#zonecfg-zmy-zone
zonecfg:
my-zone>addfs
zonecfg:
my-zone:
fs>setdir=/usr/local
zonecfg:
my-zone:
fs>setspecial=/empty
zonecfg:
my-zone:
fs>settype=lofs
zonecfg:
my-zone:
fs>addopti
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Solaris Zones 分区技术 分区 技术
![提示](https://static.bingdoc.com/images/bang_tan.gif)