[[hardware]] === Hardware 如果你已經遵循了正常的開發路徑, 你可能已經在自己的筆記本電腦或周邊的機器集群上使用了Elasticsearch ((("deployment", "hardware")))((("hardware"))). 但當要部署到生產環境時, 有一些建議是你需要考慮的. 這里沒有什么必須要遵守的準則;Elasticsearch被用于在眾多的機器上處理各種任務. 但基于我們的生產集群經驗，可以提供一個好的起點. ==== 內存 如果有一種資源是最先被耗盡的, 它可能是內存.((("hardware", "memory")))((("memory"))) 排序和聚合都是很耗內存的, 所以使用足夠的堆空間來應付它們是很重要的.((("heap"))) 盡管當堆空間是比較小的時候, 也能為操作系統文件緩存提供額外的內存. 因為Lucene使用的很多數據結構格式是基于硬盤的, Elasticsearch 使得操作系統緩存能產生很大效果. 64 GB內存的機器是非常理想的, 但32 GB 和 16 GB 機器也是很常見的. 少于8 GB 會適得其反 (你最終需要很多很多的小機器), 大于64 GB的機器也會有問題，我們將在<<heap-sizing>>中討論. ==== CPUs 大多數Elasticsearch部署對CPU要求很小. 例如,((("CPUs (central processing units)")))((("hardware", "CPUs"))) 額外的處理器安裝問題比其它資源要少. 你應該選擇多核的現代處理器. 常規的集群利用2到8核機器. 如果你要在更快的CUPs和更多的核心之間選擇，選擇更多的核心更好. 多核心提供的額外并發將遠遠超出稍微快點的時鐘速度(注：CPU速度). ==== 硬盤 硬盤對所有的集群都很重要,((("disks")))((("hardware", "disks"))) 對高度索引的集群更是加倍重要 (例如那些存儲日志數據的). 硬盤是服務器上最慢的子系統,這意味著那些寫多的集群很容易讓硬盤飽和, 使得它成為集群的瓶頸. 如果你負擔得起SSD, 它將遠遠超出任何旋轉媒介(注：機械硬盤，磁帶等). 基于SSD 的節點的查詢和索引性能都有提升. 如果你負擔得起,SSD是一個好的選擇. .檢查你的 I/O 調度程序 **** 如果你正在使用SSDs, 確保你的系統 I/O 調度程序是((("I/O scheduler"))) 配置正確的. 當你向硬盤寫數據, I/O 調度程序決定何時把數據 _實際_ 發送到硬盤. 大多數 *nix 發行版下的調度程序都叫做 `cfq` (Completely Fair Queuing). 調度程序分配 _時間片_ 到每個進程, 并且優化這些到硬盤的眾多隊列的傳遞. 但它是為旋轉媒介優化的: 旋轉盤片的固有特性意味著它寫入數據到基于物理布局的硬盤會更高效. 這對SSD來說是低效的, 然而, 盡管這里沒有涉及到旋轉盤片. 但是, `deadline` 或 `noop` 應該被使用. deadline 調度程序基于寫入等待時間進行優化, `noop` 只是一個簡單的FIFO隊列. 這個簡單的更改可以帶來顯著的影響. 僅僅是使用正確的調度程序，我們看到了500倍的寫入能力提升. **** 如果你使用旋轉媒介, 嘗試獲取盡可能快的硬盤 (高性能服務器硬盤, 15k RPM 驅動器). 使用RAID 0是提高硬盤速度的有效途徑, 對旋轉硬盤和SSD來說都是如此. 沒有必要使用鏡像或其它RAID變體, 因為高可用已經通過replicas內建于Elasticsearch之中. 最后, 避免使用網絡附加存儲 (NAS). 人們常聲稱他們的NAS解決方案比本地驅動器更快更可靠. 除卻這些聲稱, 我們從沒看到NAS能配得上它的大肆宣傳. NAS常常很慢, 顯露出更大的延時和更寬的平均延時方差, 而且它是單點故障的. ==== 網絡 快速可靠的網絡顯然對分布式系統的性能是很重要的((("hardware", "network")))((("network"))). 低延時能幫助確保節點間能容易的通訊, 大帶寬能幫助分片移動和恢復. 現代數據中心網絡 (1 GbE, 10 GbE) 對絕大多數集群都是足夠的. 即使數據中心們近在咫尺,也要避免集群跨越多個數據中心. 絕對要避免集群跨越大的地理距離. Elasticsearch假定所有節點都是平等的--并不會因為有一半的節點在150ms外的另一數據中心而有所不同. 更大的延時會加重分布式系統中的問題而且使得調試和排錯更困難. 和NAS的爭論類似, 每個人都聲稱他們的數據中心間的線路都是健壯和低延時的. 這是真的--直到它不是時 (網絡失敗終究是會發生的; 你可以相信它). 從我們的經驗來看, 處理跨數據中心集群的麻煩事 &#x2013;是根本不值得的. ==== 一般注意事項 獲取真正的巨型機器在今天是可能的:((("hardware", "general considerations"))) 成百GB的RAM 和 幾十個 CPU 核心. 反之, 在云平臺上串聯起成千的小虛擬機也是可能的,例如 EC2(注：Amazon Elastic Compute Cloud). 哪條道路是最好的? 通常, 選擇中到大型機器更好. 避免使用小型機器,因為你不會希望去管理擁有上千個節點的集群, 而且在這些小型機器上 運行Elasticsearch的開銷也是顯著的. 與此同時, 避免使用真正的巨型機器. 它們通常會導致資源使用不均衡 (例如, 所有的內存都被使用, 但CPU沒有) 而且在單機上運行多個節點時，會增加邏輯復雜度.