|
| 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 次的搜尋，每次搜尋都傳回一個平均大小為 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 = Sumall entry caches(nsslapd-cachememsize)
- 決定所有快取大小的總和，cacheSum。
cacheSum = entryCacheSum + nsslapd-dbcachesize + nsslapd-import-cachesize
- 決定 Directory Server 處理序的總大小，slapdSize。
slapdSize = slapdBase + cacheSum
您可以使用 Solaris 系統或 Windows 工作管理員上的公用程式來計算 Directory Server 所使用的實體記憶體，如 pmap(1) 等公用程式。
- 估計處理傳入用戶端要求所需的記憶體，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 瓶頸。
如需減緩磁碟 I/O 瓶頸的詳細資訊，請參閱第 8 章「調整記錄」。
調整目錄尾碼大小
尾碼對磁碟空間的需求除了取決於目錄中項目的大小和數目外，還取決於目錄組態，尤其是尾碼編製索引的方式。若要計算大型部署所需的磁碟空間，請執行下列步驟：
- 產生 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 二進位檔案碼
若要安裝此版本的 Directory Server，則需要大約 200 MB 磁碟空間。此估計值並不包括用於資料的空間，而僅包括用於產品二進位檔案碼的空間。
事件記錄
記錄檔的磁碟使用估計值取決於 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 檔案
請至少保留一些空間給一或兩個 core 檔案。雖然 Directory Server 不應傾印 core，但如果當機期間所產生的 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 和 Pettit 著。
快速且安全
當在執行效能與存留時間都至關重要的部署時，請考慮使用有靜態記憶體快取的硬體型態 RAID 控制器，以便能提供分散在大型磁碟陣列上的高速緩衝 I/O。將負載分散到許多磁軸，並透過非常快速的連線進行緩衝存取，這樣 I/O 不但能夠獲得最佳效能，而且可以透過高效能的 RAID 等量分割或同位區塊提供極佳的穩定性。
大型的靜態 I/O 緩衝區和高效能的磁碟子系統 (如 Sun StorEdgeTM 中所提供的磁碟子系統) 能夠大幅增強 Directory Server 的效能和存留時間。
快速寫入快取擴充卡可能改善寫入效能，尤其是當快取擴充卡專供交易記錄檔使用時。快速寫入快取擴充卡提供與磁碟控制器無關的靜態記憶體快取。
快速且廉價
為達到快速低成本的效能，請確定您在數個磁碟上分配了足夠的空間。請考慮使用高轉速和低搜尋時間的磁碟。為達到最佳結果，請為每個分散的元件指定一個專用磁碟。請考慮使用多主機的複寫以避免單點故障。
廉價且安全
為得到廉價且安全的組態，請考慮使用低成本、軟體型態的 RAID 控制器，如 Solaris Volume Manager。
RAID 替代項目
RAID 是 Redundant Array of Inexpensive Disks (獨立磁碟容錯陣列) 的縮寫。顧名思義，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 10，RAID 1+0 能提供最高層級的效能和恢復功能。因此，它是最昂貴的 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 Level 2、3 和 4
RAID Level 2 和 Level 3 非常適合連續大量傳輸資料，如視訊串流。這兩個層級一次只能處理一個 I/O 作業，因此非常不適合需要經常隨機存取的應用程式。RAID 2 是使用漢明錯誤校正碼 (ECC) 來執行。這表示需要用三個實體磁碟機來儲存 ECC 資料，因此它比 RAID 5 昂貴，但又比 RAID 1+0 廉價，前提是等量分割中要有三個以上的磁碟。RAID 3 使用位元同位方法來完成冗餘。同位資料並不會像每個 RAID 5 一樣分散出去，而是會寫入一個專用磁碟中。
與 RAID Level 2 和 Level 3 不同，RAID 4 使用獨立存取技術，以同時存取多部磁碟機。RAID 4 以類似於 RAID 5 的方式來使用同位資料，不同的是它將同位資料寫入單一磁碟中。由於每次寫入時都會存取同位磁碟，並且有效地連續多次寫入，因此同位磁碟便有可能成為瓶頸。
軟體磁碟區管理員
磁碟區管理員 (如 Solaris杼olume 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 加速板會大有益處。在 SSL 金鑰計算尚未成為瓶頸時，這類硬體可能不會改善效能。然而，在 SSL 信號交換交涉連線期間 (但之後不交涉訊息的加密和解密)，它會特別加快金鑰的計算速度。如需有關將這類硬體與 Directory Server 實例一起使用的說明，請參閱附錄 B「使用 Sun Crypto 加速板」。