我目前有一個系統設置，其中客戶端透過 FTP 傳輸文件，從而觸發 inotify（透過 Linux 核心通知）來觸發解析以對這些文件採取操作。我遇到的問題是解析器目前正在達到一個 EC2 執行個體上的 I/O 容量，我想新增其他節點來拆分檔案負載。不幸的是客戶端只能透過FTP上傳。這讓我想知道如何才能擁有另一個不共享文件所在的 EBS 磁碟區的實例來處理該文件。
目前是否有一種 AWS 解決方案可以讓使用 FTP 的客戶保持不變（除了可能可以更改 IP 之外）並允許我讓多個 EC2 執行個體存取檔案系統？
答案1
當然...
您可以在任一類型的多個磁碟區之間附加和條帶化，以提高 Amazon EC2 應用程式可用的 I/O 效能。
這是我使用過的一件事，EBS 卷的 RAID-10，但是…但我假設您已經想到了這一點。
我考慮過建議使用類似的方法來擴展 FTP 伺服器HA代理和/或redir與Ubuntu 捆綁在一起的實用程式（它可以重寫FTP 資料包以修復該協議中的一些固有的荒謬之處），但FTP 尷尬的多連接性質可能會使這成為一個複雜的命題，而且它可能不是您真正想要的想。
那麼，s3fs 呢？
在我建議這個之前，我用谷歌搜尋並發現了類似的東西這個帖子，這表明它可能不起作用，但後來我意識到這種情況下的OP似乎對S3和文件系統的實際工作方式嚴重缺乏了解，並且期望inotify意識到S3中的事情已經通過外部原因遠程改變了（沒有遍歷本機檔案系統）這當然沒有意義。
但我編寫了一些程式碼來測試它，而 s3fs 確實似乎與 inotify 正確互動。您可以從FTP 伺服器安裝一個儲存桶，而不是EBS 卷，這樣當您的用戶端透過FTP 上傳檔案時，它們會直接放入儲存桶中，並且inotify 會像使用傳統檔案系統一樣捕獲該事件，網址為此時您可以使用 SQS 或任意數量的其他機制來提醒工作機器有工作要做。然後，他們可以獨立取得和處理文件，I/O 僅受每台電腦與 S3 基礎設施之間的可用頻寬限制。
有很多事情是 s3fs 完全不適合的，例如反复提供相同靜態內容的伺服器 - s3fs 不是一個好的解決方案，因為可能會出現大量冗餘請求發生和/或需要s3fs 在本地緩存內容（可以，但沒有意義——如果您需要，那麼您只需將文件存儲在本地），以及按需單獨獲取它們所涉及的延遲雖然嘗試提供響應式網站可能會出現問題...但是當每個文件都不是經過一次又一次的訪問，我得到了積極的結果。
我最近為一個客戶做了一個小項目，他們想在 S3 中儲存可公開下載的資源，但他們可能有與您類似的限制 - 他們真的希望能夠使用 FTP 上傳檔案。將proftpd 與透過s3fs 安裝到EC2 實例的儲存桶結合，為他們提供了一個進入S3 的簡單“網關”，並且與他們現有的系統相容......所以我知道它確實有效，並且已經使用inotify 測試了相同的設定現在，我可以告訴你，兩人似乎有預期的互動。
像這樣在 EC2 內部使用 S3，存儲價格本質上與 EBS 相同，如果存儲桶與端點位於同一區域，您將無需支付頻寬費用 - 您只需為每個存儲桶付費PUT（每百萬個請求5 美元） ，並且GET（每百萬個請求 4 美元）（我對定價表的解釋；我在 S3 中存儲了數百萬個對象，並且從未有過賬單意外，但請不要相信我的話）。文件和請求之間可能不會存在精確的 1:1 相關性，因為 s3fs 必須做一些後台猴子業務來將文件模式和所有權存儲在 S3 中作為其偽文件系統模擬的一部分，並且必須迭代對像以生成目錄列表，因此對請求的YMMV...但這似乎是一個可行的解決方案。
只要您正確理解 S3 的功能與傳統檔案系統的功能之間的阻抗不匹配，我就不明白為什麼這不能像您所需要的那樣無限地擴展您。
當然，我最喜歡 s3fs 的部分是你永遠不會用完空間。 :)
Filesystem Size Used Avail Use% Mounted on
s3fs 256T 0 256T 0% /var/xxxxxxxxxxx
答案2
如果您的用戶端能夠透過 DNS 而不是 IP 存取您的 ftp，似乎最簡單的解決方案可能是將 ELB 放在多個 ftp 實例前面，以便您可以水平擴展。
然後，如果您需要在處理完成後將所有 ftp 檔案最終存放在一個位置，則可以使用 S3 或任意數量的解決方案將處理後的檔案持久儲存在一個位置。
答案3
當inotify發現有新檔案被ftp到你的頭節點時，你不能有一個腳本將這些檔案scp到另一個節點嗎？