使用過 MQ 文件傳輸版？
我們有幾個跨伺服器移動文件的程序——SFTP、FTP、SCP；視窗、Linux、AIX；有一個工作流組件（通常需要一個帶有文件名和雜湊值的控製文件來移動一批相關文件）。該操作通常在我們的伺服器上啟動以獲取文件，因此我們需要確保它們已完成寫入。
我們有一些本地腳本來執行此操作，但它們並不總是能正常工作，並且通過這種方式進行故障排除、維護和日誌審查並不容易。有很多伺服器，我們的腳本沒有中央日誌記錄或儀表板/控制台/等。
我們正在研究商業產品來做到這一點。有人用過 MQ 文件傳輸版嗎？我們公司的另一個團隊正在使用 Aspera，有沒有人對此有任何想法，或者其他喜歡的產品？
我還不知道我們的預算是多少。只是試圖從其他管理員的角度來處理產品空間。
/edit - 在我的情況下，我們將掃描圖像的 2 個文件有效負載（一個二進製文件，一個元數據）從不同的來源移動到不同的目的地。我們等到第三個控製文件被寫入校驗和 - 當移動完成時，控製文件被刪除。
來源主要是少數 Windows 文件伺服器或 Windows SFTP 伺服器，它們從掃描過程中接收這些文件。我們也有 FTP 或 SFTP 伺服器的來源，它們從外部各方接收相同的有效負載。目標是一組 AIX 伺服器，它們將圖像攝取到存檔中，因此文件也不會保留在目標中。穩健性絕對是我們最關心的問題。
我猜我們每天移動幾 GB。（如果沒有集中式日誌記錄，我無法給出更好的數字。）二進製文件可能平均在 100 MB 左右，元數據要小得多。
我沒有使用過 MQ 文件傳輸版，所以我無法對此發表評論。我已經完成了很多文件傳輸，包括 EDI、FTP、AS2、FTPS、SFTP、rsync、SCP、aspera、svn 等。最終我的答案將取決於您的確切要求。聽起來你最重要的是文件傳輸的可靠性。
首先，我建議對平台、維護和管理進行某種標準化，這聽起來像是您正在做的事情。無論作業系統/配置如何，使每台伺服器都使用相同的程序來獲取和從節點獲取文件。跨不同配置增加故障排除可能會使簡單的任務非常令人沮喪。當我想到可靠性時，我不會想到 Windows，但很多時候根本沒有辦法避免它。
雖然我不知道您的確切要求，但我會為您提供一些可能的解決方案，如果您能準確說明您的需求（WAN、LAN、文件大小、每天的傳輸次數、傳輸的重要性等），我可以為您提供更準確的答案。我過去設置的傳輸範圍從小於 1kb 的小文件到數百 GB 的數據，從如果傳輸沒有發生到可能永遠不會使用的數據，人們就不會獲得報酬，從開放的網際網路傳輸到加密數據，跨加密 VPN 的加密傳輸。
您真正追求的是行業中的一個半新術語，稱為託管文件傳輸。 http://en.wikipedia.org/wiki/Managed_file_transfer
最終，獲取 Gartner 魔力像限報告，查看並選擇滿足您需求的供應商。您會在列表中註意到 Aspera，但請考慮 CFI 以滿足您的需求。考慮到您正在專門尋找商業產品，這是您最好的選擇。如果您想對我在該領域的研究有更多意見，請私信我或發表評論。
這是我的個性化輸入。
集中式 FTP：
這很好，因為 FTP 是通用的，它被用在很多地方，並且有很多跨系統的支持。許多流行的 FTP 伺服器將為許多身份驗證方法和協議提供支持。如果您能夠為所有節點集中伺服器，那麼故障排除會變得容易得多，當出現問題時，您可以檢查伺服器日誌，或者理想情況下讓日誌通過電子郵件自動報告給您，如果沒有任何問題，它很漂亮清除其客戶端或網路問題。問題是 FTP 並不完美，它很容易失敗，並且在處理大量小文件時速度特別慢。在整個作業系統中，您可能會發現文件命名問題等等。如果您打算考慮使用此解決方案，請使用可以支持簡單文件驗證的客戶端和伺服器。 http://en.wikipedia.org/wiki/Simple_file_verification。用於檢查文件的機制正如它所說的那樣簡單，並且可以跨多個平台進行檢查。有許多伺服器支持在上傳文件時檢查文件，並且可以在文件檢查失敗時自動報告，同時檢查完整的文件集而不是單個文件，還為要上傳的完整結構提供一定的百分比。gltfpd 是一個流行的，但請記住，它是一個配置的熊，但是一旦你設置了它，你可能永遠不需要再碰它了。 http://www.glftpd.com/。Gene6也很受歡迎
rsync 文件
我已經在腳本中大量使用了 rsync，我發現這在考慮錯誤檢查時非常可靠且非常健壯。因此，您會發現 rsync 在備份腳本中很受歡迎。我不知道有很多現成的 rsync 程序，所以您正在尋找為此編寫解決方案的程式碼，並且您將再次沒有集中式日誌記錄，您可能會遇到很多相同的問題，但老實說，我發現rsync 足夠可靠，並且具有大文件集和完整性檢查的增量傳輸是完成工作的一種非常快速而骯髒的方式。
粗糙的
Aspera 是高延遲、高頻寬傳輸的核心技術。如果您不通過 WAN 傳輸，也不傳輸大型數據集，我不建議您這樣做。我執行了一個大型 Aspera 部署，其中充斥著傳輸問題和軟體錯誤。如果您正在尋找非常基本的功能，這是一個很好的解決方案，但是當涉及到更高級的處理時，請準備好編寫自己的腳本來傳輸數據。該軟體似乎更專注於小型利基企業，並且它們似乎在企業部署中掙扎。他們使用其中一種產品的集中式日誌記錄將解決集中式日誌記錄的需求，他們的預處理和後處理也可以滿足您的需求，但請記住，您最終可能會花費相當多的錢來購買一半有效的解決方案。我在上面提到了 CFI，他們的產品更加企業化，但他們很難提供單一的體驗。根據您的需要，不要相信我的話，自己試用他們的產品。
版本控制系統
我首先要說這似乎不符合要求，但這是另一種選擇。如果您傳輸的文件不是事務性的，請考慮將這些文件儲存在版本控制系統中。在這種情況下，當需要傳輸文件時，會將其簽入版本儲存庫，並在需要時在遠端端進行同步。在您需要版本控制和文件可能相互互動以及集中式伺服器的情況下，這可能是一個不錯的選擇。
作為最後的附註，看看 twitter 使用什麼來在他們的許多節點之間傳遞配置文件：http: //engineering.twitter.com/2010/07/murder-fast-datacenter-code-deploys.html
我再一次強調，正確的答案是基於您的確切要求。
希望這對您有所幫助。