信息化标准体系文档AIX6.1操作系统部署方案设计和安装配置指南（V1.1）北京数据中心开放系统平台管理部2011-3修改记录人都无权复制或利用。
®Copy Right 2005 by China Construction Bank目录1前言 (7)1.1编写目的 (7)1.2预期读者 (7)2系统部署模式 (8)2.1单机模式 (8)2.2基于系统技术的HA方案； (8)2.2.1Active-Standby主备方式 (9)2.2.2Active-Active 互备方式 (9)2.2.3一备二模式 (9)2.2.4循环备份模式 (10)2.2.5Concurrent并行处理模式 (11)2.3基于软件技术的CLUSTER方案 (11)2.4基于网络硬件设备的负载均衡方案 (11)3应用部署建议 (12)4系统设计考虑的因素 (13)4.1用户 (13)4.2相关命名 (13)4.3存储/本地盘容量限制 (13)4.4系统网络 (14)4.5参数设置 (14)4.6软件安装 (14)4.7空间规划 (15)4.8安全加固 (15)4.9时钟同步 (16)5命名规范 (17)5.1资源分配原则 (17)5.1.1设备分档 (17)5.1.2资源调整 (17)5.2机器及机柜的编号规则 (17)5.2.1机柜的命名和编号规则 (17)5.3分区使用规范 (18)5.3.1分区的部署原则 (18)5.3.2分区资源的分配原则 (18)5.4主机命名原则 (20)5.5用户及用户组命名 (21)5.5.1目标 (21)5.5.2指导方针 (21)5.5.3用户组 (22)5.5.4用户 (23)5.5.5用户和组ID的分配情况 (24)5.6应用VG、LV和文件系统 (25)5.6.1应用vg (25)5.6.2应用lv的命名 (26)5.6.3LV条带化 (27)5.6.4应用文件系统的使用规范 (39)5.6.5patrol监控使用的文件系统 (40)5.7软件安装路径 (27)5.7.1数据库 (27)5.7.2中间件 (27)5.7.3应用系统 (28)5.8H ACMP命名 (28)5.8.1命名规则 (28)5.8.2配置举例 (28)6AIX设计规范 (30)6.1操作系统的内核 (30)6.2软件包安装规范 (30)6.2.1AIX系统需要安装的软件包 (30)6.2.2字符集安装要求 (31)6.3系统补丁的安装规范 (31)6.3.1操作系统 (31)6.3.2Adapter 微码 (32)6.4操作系统参数的设置 (32)6.4.1基本操作参数系统环境 (32)6.4.2VMM参数 (33)6.4.3IO参数 (35)6.4.4网络参数 (35)6.4.5Security参数 (36)6.4.6Hacmp相关参数 (36)6.5系统主要文件系统的使用方法 (37)6.5.1/tmp (38)6.5.2/var (38)6.5.3/usr (38)6.5.4/ (38)6.5.5/home (39)6.5.6AIX文件系统建议值 (39)6.6系统转储空间和交换区的设置 (40)6.6.1Dump设置 (40)6.6.2Pagingspace设置 (41)6.7用户权限设置 (41)6.7.1用户文件权限规范 (41)6.7.2用户资源限制 (41)6.8口令使用规范 (42)6.8.1口令设置规范 (42)6.8.2口令保存规范 (42)6.8.3用户口令限制 (43)6.8.4root用户口令使用规范 (43)6.9系统安全加固 (43)6.9.1系统安全加固的原则 (43)6.9.2AIX系统安全加固 (44)6.9.3 用户P ATH搜索路径 (44)6.10系统网络设置规范 (48)6.10.1IP地址申请 (48)6.10.2网卡速率的设置 (52)6.10.3网卡绑定的设置 (52)6.10.4系统静态路由的设置 (52)6.10.5网络端口的使用 (53)6.11系统监控 (53)6.12系统备份的相关规定 (54)6.13NFS的使用 (54)1前言1.1 编写目的为总结我中心开放系统建设的成果，加强开放系统平台建设工作的规范化管理，我们梳理了开放系统平台基础设施设计的相关文档，并进行了深化、细化，力求结合实际的设计、实施工作，对设计、实施起到规范、指导作用。
本指南主要从一个设计者的角度进行阐述，相关章节也按此思路编写。
作为一个设计者，首先要了解产品可实现的部署模式，如何选择部署模式，其次要考虑设计涉及到的因素，有针对性地做好IBM操作系统的设计等；在界线的划分上，基础产品只涉及本产品的设计，上层应用产品对基础产品的需求放在应用产品中，例如，ORACLE部署对AIX的要求，放在ORACLE设计指导中。
在编写过程中，特别关注可操作性，不仅仅是要求，而是提出建议，尽量覆盖设计工作中涉及的工作要点。
本指南中参数建议值是对系统设计时的指导，是合理的经验值，但由于应用系统的复杂性，每个系统有自己的特点，建议按建议值进行系统的初始配置，在压力测试和系统上线后根据实际需要做相应的调整。
1.2 预期读者项目基础设施可行性研究、设计和实施人员，项目组应用系统设计人员，相关运行维护技术人员。
2系统部署模式对于业务中断时间要求高的系统和服务，应该提供高可用性保护。
对于业务中断时间要求不高的应用系统，可以考虑采用单机或冷备机方式进行部署。
针对网络的不同层次，我们提供了不同的高可用性保护方式。
包括：1、基于系统技术的HA方案；2、基于软件技术的cluster方案；3、基于网络硬件设备的负载均衡方案；4、基于数据库技术的并行处理模式2.1 单机模式对于业务中断恢复时间要求比较低的非关键系统，可以采用单机的部署模式，单机部署具有以下特点。
优点1、硬件成本低。
单节点，硬件投入较低，满足非重要系统的需求。
2、安装配置简单，管理维护成本低。
缺点1、可用性不高，由于是单台服务器，没有备机，故障恢复时间较长。
2、扩展性差。
2.2 基于系统技术的HA方案；HA方案是服务器生产厂商或第三方提供的，基于硬件设备的系统级软件。
它可以提供系统失效接管的自动解决方案，在系统失效后，自动将应用相关资源交由备份机接管，并可以自动恢复业务的运行。
应用相关资源包括：网络地址，应用代码、存储和业务数据，进程及相关内存区，相关服务。
HA解决方案的缺点是：技术复杂，需要一整套硬件设施来提供失效接管的冗余结构，包括服务器、网络链路、存储链路、存储空间等，其开销是比较大的，另外，维护成本也相应提高；HA方案的优点是：业务恢复的时间短，自动化程度高，不需要人工干预。
此方案适合部署了数据库软件的服务器使用，对于单数据库、多数据库、并行数据库都适用。
部署方式主要有：2.2.1Active-Standby主备方式主备方式一台服务器为生产机，另一台服务器为备份机，备机平时不提供任何服务。
这种方式适用于服务器在故障切换后，要求备机处理能力不能下降的重要系统。
对于采用ha方式的数据库软件代码、中间件代码、应用代码要求部署在本地，数据部分部署在共享存储上。
2.2.2Active-Active 互备方式一般由于服务器数量限制，但又有高可用保护需求的系统，如只有两台服务器的系统一台为AP，一台为DB服务器。
AP与DB服务器配置成互为备份，AP 服务器平时提供应用服务，DB平时提供数据库服务，当任一台服务器故障时，其上的服务会切换到另一台健康的服务器上，继续对外提供服务。
此时由于AP、DB同时运行在一台服务器上，服务器的处理能力会明显下降。
这种方式适用于服务器负载相对空闲的系统。
部署时还要考虑切换后两个服务使用一台服务器的CPU、内存资源，由于资源的减少，当DB服务切换到AP服务器上，启动数据库时，需要减小DB的SGA区分配等操作（Oracle），以满足数据库对资源的需求。
2.2.3一备二模式一备二模式类似于主备模式，只是备份服务器同时承担两台生产机的备份工作，优点是可以节省一台备份服务器。
如A为生产主机，B为生产主机，C为备份机，C机同时备份A机及B机。
考虑数据存储的安全，配置一备二的系统，A、B两台生产机的存储设备不需共享，即不识别对方的存储设备。
2.2.4循环备份模式A-B-C均为生产机，C机备份A机，C机备份B机，A机又备份C机。
这种方式适用于服务器资源紧张的非关键应用，又有高可用保护要求的系统，缺点是只有一台生产服务器发生故障时备机可以接管，当两台服务器同时发生故障时备机无法正常接管。
注意：对于采用一备二或者循环备份方式的系统需要考虑两个因素，一是实施要求，集群中的所有服务器需要部署在相同网段；二是维护要求，由于所有服务器均在同一个集群cluster中，如果其中的一台主机进行配置变更需要ha同步配置时，整个集群中的服务器都需要停下来同步ha，因此最好是同一套应用系统，且可以同时启停的系统采用一备多的方式。
2.2.5Concurrent并行处理模式适用于Oracle数据库的RAC方式等，详细内容见oracle设计规范部分。
2.3 基于软件技术的cluster方案基于软件技术的cluster方案，是利用中间件等应用平台软件本身具有的集群功能，将应用部署到多台设备上，在某台设备出现故障时，由其它正常的设备将出现故障的设备上的客户访问请求接管过来，继续提供服务。
（如tuxedo、weblogic、websphere的集群技术）cluster方案的缺点是：需要购买额外的license；配置比较复杂，增加了管理难度；此方案的优点是：不需要购置额外的网络链路、存储链路，也不需要额外的存储空间，业务恢复的时间比较短，只有连接故障服务器的客户需要重新登录；此方案适合那些部署了带有集群功能软件的设备使用，主要适合应用层的中间件服务器使用。
2.4 基于网络硬件设备的负载均衡方案基于网络硬件设备的负载均衡方案，是利用网络负载均衡设备，根据一定的负载均衡算法，将客户端访问请求分配到若干台服务器上，其中任何一台服务器出现故障都不影响业务的正常运行。
这种解决方案的优点是：服务器上不需要配置任何冗余部件，也不需要进行任何额外的软件配置，控制简单，服务器扩展平滑简单。
缺点是：只能对少数类型的服务提供负载均衡功能。
此方案尤其适合web服务。
3应用部署建议在三层架构中，居于中心位置的是业务数据。
相对于业务代码和web服务，业务数据的规模比较大，业务数据一旦丢失，整个业务都将陷于停顿，并且难以恢复。
因此，应该重点保护业务数据。
应用逻辑是重要性相对低一些的部分，恢复相对容易，所以在三层架构中是次要保护对象。
重要性最低的是数据展现层，该层没有自己独立的数据和业务逻辑，完全被动地展现经业务逻辑层过滤后的业务数据，因此，它的恢复是最容易的，不需要花费太大的力量进行保护。