|
| Sun ONE Directory Server 5.2 安装和调整指南 |
适当的硬件大小调整是目录服务计划和部署的一个关键组件。调整硬件大小时，可用内存的容量以及本地磁盘的可用空间容量非常重要。
注意 为取得最好的结果，请安装并配置一个具有代表生产中所使用情况的条目子集的测试系统。然后可以使用该测试系统估计生产服务器的行为。
优化特定系统时，应确保已了解系统总线、外围设备总线、I/O 设备以及支持的文件系统的工作方式。这样，在调整这些特定系统以支持 Directory Server 时，就可以利用 I/O 子系统的功能。
本章介绍几种评估 Directory Server 实例的磁盘及内存需求的方法，此外，还涉及一些网络和 SSL 加速器的硬件要求。
建议的最低要求
表 4-1 建议了在生产环境中安装和使用该软件时，应满足的最小内存和磁盘空间要求。
事实上，指定条目数的最低要求可能和表 4-1 中提供的内容有所不同。这里的大小反映的是相对较小的条目，其索引是按照默认配置进行设置，并且只对缓存进行最低限度的调整。如果条目包含较大的二进制属性值（例如数字照片），或者如果索引或缓存与默认配置有所不同，则相应地向上修订最小磁盘空间和内存评估。
最低的磁盘空间要求包括用于访问日志的 1 GB。默认情况下，Directory Server 被配置为循环使用 10 个访问日志文件 (cn=config 上的 nsslapd-accesslog-maxlogsperdir)，每一个日志文件可存放最多 100 MB (cn=config 上的 nsslapd-accesslog-maxlogsize) 的信息。用于错误日志和审核日志的容量取决于 Directory Server 如何配置。有关配置日志文件的详细信息，请参阅 Sun ONE Directory Server 管理指南。
最小可用内存
最小内存估计反映典型部署中一个 Directory Server 实例所使用的内存。此估计没有计入系统和其他应用程序所占用的内存。若要进行更精确的计算，必须以经验为主对内存进行测量。详细信息，请参阅“调整物理内存大小”。
通常，可用内存越多，效果就越好。
最小本地磁盘空间
最小本地磁盘空间估计反映典型部署中一个 Directory Server 实例所需的空间。根据经验，建议如果目录条目较大，则所需空间至少是磁盘上等量 LDIF 大小的四倍。详细信息，请参阅“调整磁盘子系统的大小”。
请不要安装服务器或任何在网络磁盘上访问的数据。Sun ONE Directory Server 软件不支持通过 NFS、AFS 或 SMB 使用网络附加存储。相反，所有的配置、日志、数据库和索引文件必须始终驻留在本地存储器中（即使安装完成以后）。
在 Windows 系统上，将驱动器格式化为 NTFS 格式而不是 FAT 格式。Directory Server 不支持使用 FAT 格式。NTFS 允许在文件和目录上设置访问控制。
最小处理能力
大容量系统通常会使用多个高速处理器来提供适当的处理能力，处理多个同时发生的搜索、大范围的索引、复制及其他功能。详细信息，请参阅“为多处理器系统调整大小”。
最低网络容量
测试证明，100 Mbit 以太网甚至能够充分满足服务提供商的使用要求，这取决于预期的最大吞吐量。可采用以下公式估计理论上的最大吞吐量：
最大吞吐量 = 最大返回条目数/秒 x 条目的平均大小
设想这样一个示例，一个 Directory Server 必须响应峰值为每秒 5000 次的搜索，而每个搜索返回 1 个平均大小为 2000 字节的条目，因此理论最大吞吐量将为 10 MB 或 80 Mbit。80 Mbit 看起来比单个 100 Mbit 以太网卡所能提供的吞吐量要多一些。但实际观察到的性能可能会有所不同。
如果希望在广域网上执行多主复制，请确保连接提供足够的吞吐量、最短滞后时间和近乎零的包丢失。
详细信息，请参阅“调整网络容量大小”。
调整物理内存大小
Directory Server 使用数据库技术存储信息。与任何依赖数据库技术的应用程序一样，足够多的快速内存是优化 Directory Server 性能的关键。通常，可用内存越多，可以被缓存用于快速访问的目录信息就越多。理想状态下，每个服务器随时都有足够的内存来缓存整个目录内容。由于 Sun ONE Directory Server 5.2 支持 64 位内存寻址，所以缓存大小不再限制为几个 GB。相反，目前 64 位体系结构理论上可处理超过 1.5 TB 的总缓存大小。
注意 当在生产环境中部署 Directory Server 时，请将缓存大小配置在理论处理限制之下，将适当资源留给一般系统操作使用。
对运行 Directory Server 所要求的内存大小的估计既涉及特定 Directory Server 配置需要的内存的估计，也包括运行 Directory Server 的基础系统需要的内存的估计。
为 Directory Server 调整内存大小
根据特定部署的估计配置值，可以估算一个 Directory Server 实例所需要的物理内存。表 4-2 总结了本节中用于计算的值。
表 4-2 调整 Directory Server 内存大小的值
值
说明1
nsslapd-cachememsize
用于后缀的条目缓存大小
条目缓存包含格式化的条目，准备发送以响应客户机请求。一个实例可处理多个条目缓存。
nsslapd-dbcachesize
数据库缓存大小
数据库缓存存放来自服务器所使用的数据库和索引的元素。
nsslapd-import-cachesize
用于批量导入的数据库缓存大小
导入缓存仅在导入条目时使用。如果仅执行脱机导入，则有可能通过重新使用为条目或数据库缓存预算的内存，避免为导入缓存预算额外的内存。
nsslapd-maxconnections
最大的受管理连接数。
nsslapd-threadnumber
服务器启动时创建的操作线程的数量
有关完整的说明，请参阅 Sun ONE Directory Server 参考手册。
要大致估算内存大小，请执行以下步骤。
- 估计服务器进程的基本大小，slapdBase。
slapdBase = 75 MB +(nsslapd-threadnumber x 0.5 MB) +(nsslapd-maxconnections x 0.5 KB)
- 确定条目缓存大小的总和，entryCacheSum。
entryCacheSum = Sum 所有条目的缓存(nsslapd-cachememsize)
- 确定所有缓存的总大小，cacheSum。
cacheSum = entryCacheSum + nsslapd-dbcachesize + nsslapd-import-cachesize
- 确定 Directory Server 进程的总大小，slapdSize。
slapdSize = slapdBase + cacheSum
可以使用 Solaris 系统上 pmap(1) 公用程序或 Windows 任务管理器来衡量 Directory Server 使用的物理内存。
- 估算处理传入客户机请求所需的内存，slapdGrowth。
slapdGrowth = 20% x slapdSize
作为初步估算，假定 20% 的开销用于处理客户机请求。实际百分比可根据特定部署的特性确定。在将 Directory Server 投入生产之前，请先凭经验验证此百分比。
- 确定用于 Directory Server 的总内存大小，slapdTotal。
slapdTotal = slapdSize + slapdGrowth
对于涉及 32 位服务器的大型部署，slapdTotal 可能超过大约 3.4 GB 的实际限制，甚至可能超过 3.7 GB 的理论处理限制。在这种情况下，可选择按第 6 章“调整缓存大小”中的建议调整缓存，进而在系统限制范围内工作，或者使用该产品的 64 位版本。
为操作系统调整内存大小
估计运行基础操作系统所需的内存必须凭经验进行，因为根据系统配置的细节的不同，操作系统内存要求会有很大的不同。基于这个原因，在尝试估算基础操作系统需要多少内存之前，请考虑为部署调整一个代表性系统，如第 5 章“调整操作系统”中所述。调整系统之后，监视内存的使用情况以获取初始估计 systemBase。可以使用 Solaris 系统上的 sar(1M) 公用程序或 Windows 中的任务管理器来衡量内存使用。
注意 为获得最高性能，请将运行 Directory Server 的系统专用于此项服务。
如果必须运行其他应用程序或服务，请在调整所需的总内存大小的同时监视它们使用的内存。
此外，还要为一般系统开销和正常管理使用分配内存。对此数量的初步估算，systemOverhead，应至少为几百兆字节，或者占总物理内存的 10％（取其中较大的值）。目的是向 systemOverhead 分配足够的空间，进而在系统生产时避免从内存交换页面。
操作系统所需的总内存 systemTotal，可用以下公式估算。
systemTotal = systemBase + systemOverhead
调整总内存大小
根据从前面几节估算的 slapdTotal 和 systemTotal，估计所需的总内存 totalRAM。
totalRAM = slapdTotal + systemTotal
注意：totalRAM 是对所需的总内存的估算，包括假定系统专用于 Directory Server 处理的内存，也包括期望在此系统上运行的所有其他应用程序和服务所估计使用的内存。
处理内存不足
很多情况下，提供足够的内存来缓存 Directory Server 使用的所有数据并不是经济有效的方法。
最低限度，应该为服务器配备足够的内存以保证运行 Directory Server 时不会引起持续的页面交换。持续的页面交换会对性能产生严重的负面影响。可使用 Solaris 和其他系统上的公用程序（如 vmstat(1M)），以便在启动 Directory Server 和填充条目缓存前后查看内存的统计情况。不受支持的单独发售的公用程序（如用于 Solaris 系统的 MemTool）可用于监视当应用程序在测试系统上运行时内存的使用和分配情况。
如果系统不能提供额外内存，而您又连续观察到持续的页面交换，请减少数据库和条目缓存的大小。交换空间耗尽可能会导致 Directory Server 崩溃。
如果不能提供足够的物理内存以缓存所有的目录数据，请参阅第 6 章“调整缓存大小”，以获取有关其他备用方案的讨论。
调整磁盘子系统的大小
磁盘的使用情况和 I/O 的功能对性能有很大的影响。特别是对于支持大量修改的部署而言，磁盘子系统可能会变成一个 I/O 瓶颈。本节提供估算一个 Directory Server 实例的全部磁盘容量以及缓和磁盘 I/O 瓶颈的推荐方法。
请参阅第 8 章“调整日志记录”，以获取有关缓和磁盘 I/O 瓶颈的详细信息。
调整目录后缀大小
后缀的磁盘空间要求不仅取决于目录中条目的大小和数量，而且取决于目录配置，特别是后缀编制索引的方式。若要测量大型部署所需的磁盘空间，请执行以下步骤：
- 为三个代表性的条目集生成 LDIF，如同可能出现在部署中的那些一样，条目集的个数分别为 10,000、100,000 和 1,000,000。
生成的条目不仅应反映预期出现的条目类型（用户、组、角色、用于扩展架构的条目）的混合，还应反映单个属性值的平均大小，特别是在期望出现诸如 userCertificate 和 jpegPhoto 之类的大型属性值时。
- 按期望的部署配置 Directory Server 实例。
特别要按生产目录的方式编制数据库索引。如果希望以后添加索引，则还必须为这些索引增加空间。
- 加载每个条目集，记录每个条目集已用的磁盘空间。
- 将结果用图形表示，以推断部署需要的估算后缀大小。
- 增加额外的磁盘空间以弥补错误和变化占用的空间。
用于后缀的磁盘空间只是图形的一部分，还必须考虑 Directory Server 使用磁盘的方式。
Directory Server 使用磁盘的方式
目录后缀是 Directory Server 存储在磁盘上的一部分。许多影响磁盘使用的其他因素甚至会因 Directory Server 在部署后的使用方式而有很大的变化，因此这里概括地进行介绍。有关在此讨论的配置项目的说明，请参阅 Sun ONE Directory Server 管理指南。
Directory Server 二进制
需要大约 200 MB 磁盘空间来安装此版本的 Directory Server。此估算值不包括用于数据的空间，而是仅指产品二进制的空间。
事件日志记录
用于日志文件的磁盘使用估算取决于 Directory Server 的活动率、日志记录的类型和等级以及日志的轮换策略。
许多日志记录要求都可以事先预测和计划。如果 Directory Server 写入日志（特别是审核日志），磁盘使用的加载级别就会增加。当高负载部署要求扩展日志记录时，应计划额外的磁盘空间以适应高负载。对于具有高负载日志记录的部署，可通过下列方式减少磁盘空间的需求：制定智能化日志轮换和存档系统、经常轮换日志、自动将旧文件移植为价格比较低廉、容量较高的存储介质，如磁带或比较便宜的磁盘簇上。
某些日志记录的要求不容易预测。例如，调试日志记录可能会引起 errors 日志的大小暂时性的急剧增加。对于大型的高负载部署而言，请考虑留出几个 GB 的专用磁盘空间用于临时的高容量调试日志记录。详细信息，请参阅第 8 章“调整日志记录”。
事务日志
事务日志的大小取决于峰值写入负载。如果出现突发写入，事务日志就会使用比持续写入负载更多的空间。Directory Server 会定期整理事务日志。因此事务日志不应该不加限制的持续增长。但是，事务日志不会在联机备份期间进行刷新。
Directory Server 通常在启用了持久事务处理的情况下运行。启用持久事务处理功能时，Directory Server 对每项修改（add、delete、modify、modrdn）操作都同步写入事务日志。在这种情况下，如果磁盘忙，就可能会阻止某项操作，从而导致潜在的 I/O 瓶颈。
如果更新性能至关重要，请计划为事务日志使用具有快速写入缓存的磁盘子系统。详细信息，请参阅第 8 章“调整日志记录”。
复制 Changelog 数据库
如果部署涉及到复制，Directory Server 供应商就会执行更改日志记录。Changelog 的大小取决于修改的量和采用的 changelog 整理类型。请根据 changelog 的整理方式来计划容量。对于大型的高负载部署，请考虑留出几个 GB 的磁盘空间，以处理异常高修改率期间的 changelog 增长。详细信息，请参阅第 8 章“调整日志记录”。
后缀初始化和 LDIF 文件
在后缀初始化（也称为批量加载或导入）期间，Directory Server 需要磁盘空间以存放下列文件：后缀数据库文件和 LDIF（用于初始化后缀），以及中间文件（初始化过程期间需要使用）。在与用于 LDIF 文件和中间文件（初始化后缀期间使用）的数据库文件所在的相同目录中计划额外（暂时）容量。
备份和 LDIF 文件
备份通常会消耗大量的磁盘空间。备份的大小与涉及的数据库文件的大小相同。通过分配等同于数据库文件数倍大小空间的方式来容纳多个备份，保证在单独的磁盘上维护数据库及其相应的备份。采用智能化策略移植备份，以随着时间的增长而降低存储介质的成本。
如果部署涉及复制，请计划额外的空间以存放初始化 LDIF 文件，因为它们与备份 LDIF 文件不同。
基于内存（而非磁盘）的文件系统
一些系统支持基于内存的 tmpfs 文件系统。例如，在 Solaris 上，/tmp 经常被安装为基于内存的文件系统以提高性能。如果缓存文件放在 /tmp（一个与系统上其他应用程序共享的位置）上，请确保系统不会用掉 /tmp 下的所有空间。否则，当内存不足时，基于内存的文件系统中的 Directory Server 文件就会被分页到专用于交换分区的磁盘空间。
一些系统支持基于 RAM 磁盘和其他备用内存的文件系统。有关创建和管理基于内存的文件系统的指示，请参阅操作系统文档。请注意，此类文件系统中的所有文件都是易失，且在系统重引导后必须重新加载到内存中。
（UNIX 平台）核心文件
留出至少可供一至两个 core 文件使用的空间。虽然 Directory Server 不应转储核心，但是如果系统崩溃时生成的 core 文件可用于检查，则崩溃后的恢复和故障排除将会大大简化。生成时，core 文件存储在与 cn=config 上的 nsslapd-errorlog 指定的文件相同的目录中，或者存储在 ServerRoot/bin/slapd/server/ 下（如果启动时出现系统崩溃）。
管理空间
为预期的系统使用（包括系统和 Directory Server 管理）留出空间。确保为基本的 Directory Server 安装、配置后缀（如果驻留在本地实例上）、配置文件等分配足够的空间。
在磁盘上分发文件
通过将通常更新的 Directory Server 数据库和日志文件置于单独的磁盘子系统上，可以将 I/O 通信量分散到多个磁盘轴和控制器上，从而避免 I/O 瓶颈。请考虑为以下每个项目提供专用的磁盘子系统。
事务日志
当启用了持久事务功能时，Directory Server 会对每项修改操作执行同步写入事务日志。所以当磁盘忙时操作即被阻止。将事务日志置于专用的磁盘上可以改进写入性能，并提高 Directory Server 可以处理的修改率。
详细信息，请参阅“事务日志记录”。
数据库
多数据库支持允许每个数据库驻留在其各自的物理磁盘上。因而，可以在多个数据库各自的磁盘子系统上分配 Directory Server 负载。若要阻止数据库操作的 I/O 争用，请考虑将每组数据库文件置于单独的磁盘子系统上。
为达到最佳性能，可将数据库文件放在具备较大 I/O 缓冲区的专用快速磁盘子系统上。当在缓存中找不到候选条目时，Directory Server 将读取磁盘中的数据。它会定期刷新写入。对于此类操作，使用快速、专用的磁盘子系统可以减轻潜在的 I/O 瓶颈问题。
cn=config,cn=ldbm database,cn=plugins,cn=config 上的 nsslapd-directory 属性指定了 Directory Server 存储数据库文件（包括索引文件）的磁盘位置。默认情况下，此类文件位于 ServerRoot/slapd-ServerID/db/ 下。
当然，更改数据库位置不仅需要重新启动 Directory Server，而且还需要完全重建数据库。更改生产服务器上的数据库位置可能会是一项艰巨的任务，所以在将服务器用于生产前，应标识最重要的数据库并将其放在单独的磁盘上。
日志文件
Directory Server 提供具有缓冲日志记录功能的访问、错误和审核日志。尽管进行了缓冲，写入这些日志文件需要进行磁盘访问，这可能会与其他 I/O 操作发生争用现象。请考虑将日志文件置于单独的磁盘上，以改进性能、容量和管理。
详细信息，请参阅第 8 章“调整日志记录”。
基于内存的文件系统上的缓存文件
例如，在 tmpfs 文件系统中，仅当物理内存耗尽时才会将文件交换到磁盘中。如果有足够内存来存放物理内存中的所有缓存文件，就可以通过为 Solaris 平台上的 tmpfs 文件系统或其他基于内存的文件系统（如用于其他平台的 RAM 磁盘）分配等量的磁盘空间，并设置 nsslapd-db-home-directory 的值使 Directory Server 将缓存文件存储在该文件系统上，从而使性能得到改进。这可以避免系统不必要地将内存映射的缓存文件转储到磁盘。
磁盘子系统备用方案
“快速、廉价、安全：您可以任选两种。” - Sun Performance and Tuning, Cockroft and Pettit。
快速和安全
在实施性能和正常运行时间都至关重要的部署时，请考虑使用非易失内存缓存的基于硬件的 RAID 控制器，以提供在大型磁盘阵列上分发的高速缓冲区的 I/O。通过在多个轴上分布负载，以及在极快的连接上进行缓冲访问，可以对 I/O 进行优化，且可以通过高性能 RAID 条带或奇偶校验块提供极佳的稳定性。
大型非易失的 I/O 缓冲区和高性能磁盘子系统（如 Sun StorEdge™ 产品中所提供）可以极大地提高 Directory Server 性能和正常运行时间。
快速写入缓存卡提供潜在的写入性能改进，特别是在专用于事务日志使用的情况时。快速写入缓存卡提供非易失内存缓存，它独立于磁盘控制器。
快速和廉价
要获取快速、低成本的性能，请确保已在大量磁盘上分配了足够的容量。请考虑使用具有高转速和低寻道时间的磁盘。要获得最佳结果，请为每个分发的组件分配一个专用的磁盘。请考虑使用多主机复制以避免单点故障。
廉价和安全
若要获得廉价且安全的配置，请考虑使用低成本的、基于软件的 RAID 控制器，如 Solaris Volume Manager。
RAID 备用方案
RAID 表示廉价磁盘冗余阵列。顾名思义，RAID 的主要用途是提供恢复。如果阵列中的某个磁盘出现故障，该磁盘上的数据并不会丢失，仍可从此阵列中的一个或多个其他磁盘上得到该数据。为实现恢复，RAID 提出了一种抽象概念，允许多个磁盘驱动器被配置成一个较大的虚拟磁盘，通常称为一个卷。通过连接、镜像或条带化物理磁盘来实现此目的。连接是指通过让一个磁盘的块在逻辑上与另一个磁盘的块相连来实现目的。例如，磁盘 1 占有块 0-99，磁盘 2 占有块 100-199，以此类推。镜像是指通过将一个磁盘的块复制到另一个磁盘，然后使它们保持连续同步来实现目的。条带化则使用算法在多个物理磁盘上分配虚拟磁盘块。
条带化的目的是提高性能。可快速处理随机写入，因为写入的数据可能被指定到条带卷中的多个磁盘上，因此磁盘能并行工作。上述情况也适用于随机读取。对于大型的顺序读写来说，情况可能没有如此简单。但是据观察，顺序的 I/O 性能也可以提高。例如，一个生成许多 I/O 请求的应用程序会堵塞单个磁盘控制器。但是，如果条带卷中的磁盘都有其各自专用的控制器，堵塞情况就不太可能发生，性能也会因此提高。
使用软件或硬件 RAID 管理器设备都可实现 RAID。两种方法各有利弊：
- 硬件 RAID 是在硬件中实现的，因此一般可以提供较高的性能，从而比软件 RAID 产生较少的处理开销。此外，硬件 RAID 与主机系统脱离，主机资源可用于执行应用程序。
- 硬件 RAID 通常比软件 RAID 更昂贵。
- 软件 RAID 比硬件 RAID 更灵活。例如，硬件 RAID 管理器通常与单个磁盘阵列或指定阵列集相关联，而软件 RAID 则可以封装任意多个磁盘阵列，或者如果需要，可以只封装阵列中的某些磁盘。
以下几节讨论 RAID 的配置（也称为级别）。这里详细讨论了最常见的 RAID 级别（0、1、1+0 和 5），对于不常见的级别仅作了一些比较和对照。
RAID 0，条带卷
条带化将数据分散在多个物理磁盘上。逻辑磁盘或卷被分成块或条带，然后以循环的方式分布在物理磁盘上。条带在大小上始终是一个或多个磁盘块，而且所有条带的大小都相同。
RAID 0 的名称是自相矛盾的说法，因为它不提供冗余。RAID 0 条带中的任何磁盘故障都会导致整个逻辑卷丢失。但是，RAID 0 是所有 RAID 级别中最便宜的，因为其所有磁盘都专门用于存放数据。
RAID 1，镜像卷
镜像的目的是提供冗余。如果镜像中的一个磁盘发生故障，数据将仍然可用且处理可继续进行。但代价是每个物理磁盘都被镜像，这意味着有一半的物理磁盘空间专用于镜像。
RAID 1+0
RAID 1+0（也称为 RAID 10）提供最高级别的性能和恢复力。因此，也是成本最高的 RAID 实现级别。在多达三个磁盘出现故障后数据仍保持可用，只要所有出现故障的磁盘形成不同的镜像。RAID 1+0 是通过条带阵列（其中的段为 RAID 1）实现的。
RAID 0+1
RAID 0+1 比 RAID 1+0 的恢复力稍差。条带被创建且被镜像。如果位于镜像同一边的一个或多个磁盘出现故障，数据将仍然可用。但是如果镜像另一边的某个磁盘也出现故障，那么逻辑卷就丢失了。这点与 RAID 1+0 的微妙差别意味着位于同一边的磁盘可同时出现故障，而数据仍然可用。RAID 0+1 是通过镜像阵列（其中段为 RAID 0）实现的。
RAID 5
RAID 5 不如镜像的可恢复性强，但仍提供了冗余，在单个磁盘出现故障后数据仍可用。RAID 5 使用奇偶校验条带来实现冗余，这些奇偶校验带是通过执行逻辑排除或在其他磁盘上按相应带的字节而创建的。当一个磁盘出现故障时，该磁盘上的数据可使用其他磁盘上相应条带中的数据和奇偶校验来重新计算。不过在执行此类更正计算时，性能会受损。
在正常操作过程中，RAID 5 提供的性能通常比 RAID 0、1+0 和 0+1 低，原因是 RAID 5 卷必须为每个逻辑写入执行四次物理 I/O 操作。即，读取旧数据和奇偶校验、执行两次排除或操作，以及写入新数据和奇偶校验。读取操作并不会受到同样的影响，因此提供的性能仅比使用相等数量磁盘的标准条带略低一些。也就是说，实际上 RAID 5 卷在其条带上少了一个专用于奇偶校验的磁盘。这也意味着，RAID 5 卷通常要比 RAID 1+0 和 0+1 成本更低，因为 RAID 5 有更多磁盘空间可用于存放数据。
考虑到性能问题，一般不建议使用 RAID 5，除非数据为只读，或者对该卷的写入操作很少。不过，具有写入缓存和快速排除或逻辑引擎的磁盘阵列能够缓解这些性能问题，这使得 RAID 5 在某些部署中成为一种成本低廉而又切实可行的镜像备用方案。
RAID 级别 2、3 和 4
RAID 级别 2 和 3 适用于大型的顺序数据传输，如视频流。这两种级别都是每次只能处理一个 I/O 操作，因而不适用于要求进行随机访问的应用程序。RAID 2 是使用 Hamming 纠错码 (ECC) 实现的。这意味着需要用三个物理磁盘驱动器来存储 ECC 数据，因而其成本高于 RAID 5，但低于 RAID 1+0（只要条带上的磁盘多于三个）。RAID 3 使用逐位奇偶校验的方法来实现冗余。奇偶校验不是像 RAID 5 那样是分布式的，而是写入单个专用磁盘中。
同 RAID 2 和 3 不同，RAID 4 使用一种独立的访问技术，可同时访问多个磁盘驱动器。它所使用的奇偶校验方法与 RAID 5 类似，不同的是奇偶校验被写在一个磁盘中。这样一来，每次写入时都要访问奇偶校验磁盘，这实际上是将多次写入序列化了，因而奇偶校验磁盘可能会成为一个瓶颈。
软件卷管理器
诸如 Solaris™ Volume Manager 之类的卷管理程序也可用于 Directory Server 磁盘管理。在生产环境部署中，Solaris Volume Manager 要优于其他软件卷管理器。
监视 I/O 和磁盘使用
磁盘在正常操作情况下不应处于饱和状态。可以使用 Solaris 上的 iostat(1M) 和其他系统上的公用程序以隔离潜在的 I/O 瓶颈。有关处理 Windows 系统上 I/O 瓶颈的详细信息，请参阅 Windows 帮助。
为多处理器系统调整大小
Directory Server 软件已经作了优化以扩展到多处理器。一般来说，添加处理器可全面提高搜索、索引维护和复制操作的性能。
然而，在具体的目录部署中，可能会出现一个效率递减点，此时添加更多处理器不会对性能有很大帮助。如果对搜索、索引编制和复制操作的性能要求极高，那么请考虑将负载平衡和目录代理技术作为解决方案的一部分。
调整网络容量大小
Directory Server 是网络密集型应用程序。为提高 Directory Server 实例的网络可用性，可以为系统配备两个或更多的网络接口。Directory Server 支持在同一进程中对多个网络接口进行监听的硬件配置。
如果计划在网络上建立目录服务器群集来平衡负载，那么请确保网络基础结构能够支持所产生的额外负载。如果打算在广域网环境下的复制操作中支持高更新率，那么请通过经验测试确保网络质量和带宽满足复制吞吐量的要求。
为 SSL 调整大小
默认情况下，安全套接字层 (SSL) 协议在软件中已实现。使用基于软件的 SSL 实现方式可能会对 Directory Server 的性能有很大的负面影响。在 SSL 模式下运行目录可能需要部署多个目录副本以满足整体的性能要求。
虽然硬件加速卡不能消除使用 SSL 的影响，但与基于软件的实现方式相比，加速卡可以极大地提高性能。Sun ONE Directory Server 5.2 支持使用 SSL 硬件加速器，如受支持的 Sun Crypto Accelerator 硬件。
当 SSL 密钥计算是瓶颈时，使用 Sun Crypto Accelerator 板就很有用。然而，当 SSL 密钥计算不是瓶颈时，此硬件可能不会提高性能，由于在 SSL 握手以协商连接期间，它特别加快了密钥计算（但不会对后面的消息进行加密和解密）。请参阅附录B“使用 Sun Crypto Accelerator 板”来了解有关在 Directory Server 实例中使用此硬件的说明。