我需要以 4 種尺寸儲存 25M 張照片 = 總共 100M 個文件，每個文件的文件大小在 3Kb 到 200 kb 之間變化，開始時使用的儲存空間約為 14-15 TB。
我們的目標是讓 2-4 個伺服器上的資料可用，並透過本地快速 Web 伺服器（nginx 或 lighthttpd）為它們提供服務，我們需要每秒處理盡可能多的請求。
我的計劃是使用 Intel 的 2U Servercase，配備 12x2TB (WD RE4) 和 Raid 6（或具有冗餘的 FS？？） 用於數據，並使用 2x60GB SSD 用於操作系統，這是一個好方法嗎？現在：我發現Adaptec 5805ZQ可以使用SSD SLC驅動器來快取最常用的文件，有什麼建議嗎？
我需要選擇什麼讀取快取大小？
如果我計劃擁有 2-4 台此類伺服器，那麼實現冗餘和負載平衡的最佳方法是什麼？
就我們的目標而言，叢集和分散式檔案系統之間的利弊是什麼？
答案1
如果這是綠地開發，那麼我絕對會為此使用雲。 100M的文件是很多數據；將冗餘儲存卸載到 Amazon S3 將是一項重大改進。
鑑於我們正在談論 100 M 文件，我相信我們可以有把握地說數據集的某些部分將是「熱」的（經常請求），而大多數部分將是冷的。因此我們確實需要緩存。
關於如何在 Amazon Web Services 上完成此操作的概述：
- 第一層：Amazon 管理的 Elastic Load Balancing 和 Amazon CloudWatch 使用 nginx 或 Apache 對幾個小型 EC2 執行個體進行監控。這些伺服器只是帶有靜態設定檔的啞負載平衡器，因此 Cloudwatch 可以為我們監控它們，並在其中一個崩潰時自動產生新實例。
- 從第一層開始：基於請求 URL（檔案名稱）的一致哈希到一層快取伺服器。您希望基於檔案名稱進行雜湊處理，以確保每個檔案不會被快取多次（降低快取命中率），而是使用 N 個快取伺服器，每個伺服器處理 1/N 的位址空間。
- 第二層：緩存伺服器。您的快取伺服器是具有更多記憶體的 EC2 實例，以及 Squid 或 Varnish 或Apache 流量伺服器已安裝快取。
- 從第二層：普通舊式 HTTP 到 Amazon S3 檔案儲存。
由於此設定是鬆散耦合的，水平擴展很容易（隨著規模問題的發展）。
它的速度在很大程度上取決於熱數據和冷數據之間的比率。如果您的工作負載大多很熱，那麼如果僅從 2 個小型負載平衡器 EC2 和 2 個高記憶體快取 EC2 執行個體中看到遠高於 10.000 個請求/秒的速度，我不會感到驚訝。
答案2
SSD 對於作業系統本身來說是大材小用，除非你真的有興趣將啟動速度提高 30 秒。只要買一對小型 SAS 硬碟就足夠了。
沃特。緩存，快取的用處取決於工作集。即，對圖像的請求是否期望均勻分佈在所有圖像上，或者您期望大多數請求將針對一小部分？在後一種情況下，快取可能很有用，而在前一種情況下，快取就沒那麼有用了。請注意，磁碟控制器上的快取主要用於快取寫入（如果快取是非易失性的），這對於資料庫等 fsync() 密集型應用程式很有幫助。對於圖像服務，我懷疑好處不會那麼大。
叢集和分散式檔案系統的一個問題是它們的設定更加複雜，尤其是分散式檔案系統比「普通」單節點檔案系統不太成熟。叢集 FS 通常意味著共用存儲，如果您想避免單點故障，這意味著相對昂貴的 SAN。
另一種方法是設定一個運行某種類似 Amazon S3 的集群，該集群提供 HTTP 可存取的分佈式和複製鍵值儲存。例如開放堆疊存儲。
答案3
很大程度取決於這些物品的使用頻率。如果您預計其中一小部分會同時非常活躍，那麼您可能需要考慮使用 Varnish 來進行前端處理，並平衡 nginx/lighttpd 後端的負載。由於經常使用的映像會被緩存，因此磁碟速度就不那麼重要了。
然而，如果圖像沒有被重複請求並且快取不能提供巨大的提升，那麼一兩個伺服器上的 nginx/lighttpd 就可以做到這一點。您還需要考慮要提供的頻寬量。作業系統可以輕鬆快取資料集的一小部分 800mb/秒。資料集的一個巨大子集的800mb/秒可能會遇到IO 瓶頸，因為您無法足夠快地從磁碟獲取資料來提供服務，在這種情況下，您需要將系統拆分為足夠的部分以獲得IO頻寬。
即使您正在執行 raid-6，它仍然無法替代備份，因此，請預算一台類似的機器來進行備份，或者可能充當故障轉移儲存伺服器。
答案4
我會選擇自訂叢集而不是分散式檔案系統，因為它更容易理解和排除故障，同時仍然可以工作。也就是說，您自己的叢集的可靠性權衡是顯而易見的，而弄清楚分散式 FS 如何對死機伺服器或故障交換器做出反應本身就是一項任務。
針對您的問題類型的一個可能的解決方案是將整個照片存檔拆分為多個部分（例如2 個部分），並在URL 中明確顯示部分ID（例如，將其設為子域或GET 參數，以便使用常規方法輕鬆提取）表達式）。然後，您將擁有 4 台儲存照片的伺服器（每個部分 2 台伺服器）。使用第五台伺服器作為反向代理來分配和平衡負載。所有五台伺服器都可以運行lighttpd。也就是說，我提出了一個非常愚蠢但有效的方案（對於我工作的公司來說，每秒的總負載約為5000 個請求，檔案大小為3-10 KB，唯一檔案總數為8 TB，來自24 個後端的伺服器但是，執行自訂 HTTP 守護程序而不是 lighttpd）解決方案。
至於磁碟和RAM：我們使用了由每台伺服器上的四個快速但便宜的SATA 磁碟組成的軟體RAID-0（如果磁碟發生故障，所有資料都可以從不同伺服器上的副本複製），再加上自訂解決方案在單一讀取錯誤後使整個伺服器離線。 RAID-5和RAID-6即使其中一個磁碟出現故障，速度也很差，請不要使用它們。在內容伺服器上，大量 RAM 是必不可少的（作為磁碟快取），尋找 24 GB 或更多。即便如此，也要做好 30 分鐘的預熱時間的準備。在反向代理上，如果您使用 lighttpd，請考慮到它會盡快將整個上游響應緩衝到 RAM 中，並且可能會花費大量時間將緩存的照片推送給通過撥號或 GPRS 的某人（在此期間） ，需要RAM 中的緩衝區）。我們也使用了 24 GB 來擁有相同的配置，但我不確定這是否太過分了。反向代理上基於記憶體的 HTTP 快取並不是必需的（即使有熱映像！），因為後端作業系統提供的磁碟快取也可以正常運作。
確保為存檔的同一部分提供服務的所有後端都具有相同的資料：這很容易。發布照片時，只需將其複製到所有伺服器即可。然後對存檔的舊部分使用 rsync 來修正任何差異，從而使一個副本成為主副本。