MQ File Transfer Editionの経験はありますか？
サーバー間でファイルを移動するプロセスがいくつかあります-SFTP、FTP、SCP。 Windows、Linux、AIX;ワークフローコンポーネントがあります（通常、関連ファイルのバッチを移動するには、ファイル名とハッシュ値を含む制御ファイルが必要です）。多くの場合、アクションはファイルを取得するためにサーバーで開始されるため、ファイルの書き込みが完了していることを確認する必要があります。
これを行うための独自のスクリプトがいくつかありますが、それらは常に正しく機能するとは限らず、トラブルシューティング、メンテナンス、およびログレビューはこの方法では簡単ではありません。サーバーはたくさんあり、スクリプトには中央ログやダッシュボード/コンソールなどがありません。
これを行うために、商用製品を検討しています。 MQ File Transfer Editionを使用した人はいますか？私たちの会社の別のチームがAsperaを使用していますが、誰かがそれや他のお気に入りの製品について何か考えを持っていますか？
このための予算はまだわかりません。他の管理者の観点から製品スペースを把握しようとしているだけです。
/ edit-私の状況では、スキャンした画像の2ファイルのペイロード（1つのバイナリと1つのメタデータ）をさまざまなソースからさまざまな宛先に移動しています。 3番目の制御ファイルがチェックサムで書き込まれるまで待機します。移動が完了すると、制御ファイルは削除されます。
ソースは主に、スキャンプロセスからこれらのファイルを受信する少数のWindowsファイルサーバーまたはWindowsSFTPサーバーです。また、外部の関係者から同じペイロードを受信するFTPまたはSFTPサーバーであるソースもあります。宛先は、イメージをアーカイブに取り込む一連のAIXサーバーであるため、ファイルも宛先に残りません。堅牢性は間違いなく私たちの主な関心事です。
私たちは毎日数GB移動していると思います。 （集中ログがないと、これ以上の数値を出すことはできません。）バイナリファイルの平均はおそらく約100 MBで、メタデータはかなり小さくなっています。
MQ File transfer editionを使用したことがないので、コメントできません。私はEDI、FTP、AS2、FTPS、SFTP、rsync、SCP、aspera、svnなどを含む多くのファイル転送を行いました。最終的に私の答えはあなたの正確な要件に依存します。あなたが求めている最も重要なことのように聞こえるのは、ファイル転送の信頼性です。
まず、プラットフォーム、メンテナンス、管理のある種の標準化についてお勧めします。これは、あなたがやろうとしているように聞こえます。 OS /構成に関係なく、すべてのサーバーが同じプロセスを使用してノードとの間でファイルを取得するようにします。さまざまな構成でトラブルシューティングを増やすと、単純なタスクが非常にイライラする可能性があります。信頼性について考えるとき、私はウィンドウについては考えませんが、多くの場合、それを回避する方法はありません。
私はあなたの正確な要件を知りませんが、あなたがあなたのニーズ（WAN、LAN、ファイルサイズ、1日の転送数、転送の重要性など）を正確に明確にすることができれば、私はあなたにいくつかの可能な解決策を提供しますより正確な答え。私が過去に設定した転送は、1kb未満の小さなファイルから数百GBのデータまで、オープンなインターネット転送から、使用されることさえない可能性のあるデータに転送が行われない場合、人々は支払いを受けません。暗号化されたデータ、暗号化されたVPNを介した暗号化された転送。
あなたが本当に求めているのは、マネージドファイル転送と呼ばれる業界の半新しい用語です。 http://en.wikipedia.org/wiki/Managed_file_transfer
一日の終わりに、これに関するGartner Magic Quadrant Reportを入手し、それを確認して、ニーズを満たすベンダーを選択してください。リストにAsperaがありますが、ニーズに合わせてCFIを検討してください。特に商用製品を探していることを考えると、これが最善の策です。この分野での私の研究についてさらに意見が必要な場合は、私にメッセージを送るかコメントしてください。
これが私のパーソナライズされた入力です。
集中FTP：
FTPは普遍的であり、非常に多くの場所で使用されており、システム間で非常に多くのサポートがあるため、これは良いことです。多くの人気のあるFTPサーバーは、プロトコルだけでなく多くの認証方法をサポートします。すべてのノードのサーバーを一元化できる場合は、トラブルシューティングがはるかに簡単になります。問題が発生した場合は、サーバーログを確認するか、理想的にはログをメールで自動報告します。問題がない場合は、かなり簡単です。クライアントまたはネットワークの問題をクリアします。問題は、FTPが完全ではなく、簡単に失敗する可能性があり、大量の小さなファイルを処理する場合は特に低速になることです。 OS全体で、ファイルの命名の問題などが見つかる場合があります。このソリューションを検討する場合は、単純なファイル検証をサポートできるクライアントとサーバーを使用してください。 http://en.wikipedia.org/wiki/Simple_file_verification 。ファイルのチェックに使用されるメカニズムは、それが言うように単純であり、複数のプラットフォーム間でチェックできます。アップロード中のファイルのチェックをサポートし、ファイルがチェックに失敗した場合に自動的にレポートできるサーバーがいくつかあります。また、個々のファイルではなく完全なファイルセットをチェックし、アップロードされる完全な構造のパーセンテージも提供します。 gltfpdは人気のあるものですが、構成には負担がかかることを覚えておいてください。一度セットアップすると、もう一度触れる必要がなくなる場合があります。 http://www.glftpd.com/ 。 Gene6もかなり人気があります
ファイルをRsyncします
私はスクリプトでrsyncをかなりの量使用しましたが、エラーチェックを考慮すると、これは非常に信頼性が高く、かなり堅牢であることがわかりました。このため、バックアップスクリプトの間でrsyncが人気があります。私はrsyncの既製のプログラムの多くを知らないので、これの解決策をコーディングすることを検討しています。もう一度、集中ログがなく、同じ問題がたくさん発生する可能性がありますが、正直に言って私は見つけましたrsyncは十分に信頼性が高く、大きなファイルセットと整合性チェックを備えたデルタ送信を使用すると、物事を成し遂げるための非常に迅速で汚い方法です。
アスペラ
Asperaは、高遅延、高帯域幅の転送を中核とする優れたテクノロジーです。 WANを介して転送しておらず、大きなデータセットを転送していない場合は、お勧めしません。大規模なAsperaデプロイメントを実行していますが、転送の問題やソフトウェアのバグがたくさんあります。非常に基本的な機能を探している場合、それはかなり良い解決策ですが、より高度な処理になると、データを転送するための独自のスクリプトを作成する準備をしてください。このソフトウェアは、小規模なニッチビジネスに重点を置いているようであり、企業の展開全体で苦労しているようです。彼らが自社製品の1つで持っている集中型ロギングは、集中型ロギングのニーズを解決し、前処理と後処理もニーズに対応しますが、半分の作業ソリューションにかなりの金額を費やしてしまう可能性があることに注意してください。上記でCFIについて説明しましたが、彼らの製品ははるかにエンタープライズですが、単一のエクスペリエンスを提供するのに苦労しています。あなたのニーズに応じて、私の言葉を信じないで、あなた自身のために彼らの製品の試用版を入手してください。
バージョン管理システム
最初に、これは要件に適合しないように思われますが、別のオプションであると言います。転送するファイルがトランザクションではない場合は、これらのファイルをバージョン管理システムに保存することを検討してください。このシナリオでは、ファイルを転送する必要がある場合、ファイルはバージョンリポジトリにチェックインされ、必要な場合はリモートエンドで同期されます。相互作用する可能性のあるバージョン管理とファイル、および集中型サーバーが必要な場合は、これが適切なオプションになる可能性があります。
最後の補足として、Twitterが構成ファイルを多数のノード間で渡すために使用するものを確認してください。 http://engineering.Twitter.com/2010/07/murder-fast-datacenter-code-deploys.html
もう一度、正しい答えがあなたの正確な要件に基づいていることを強調することはできません。
これがお役に立てば幸いです。
私はいくつかの顧客にWMQFTEを実装しましたが、それはあなたが説明した要件を確実に満たします。制御ファイルを監視し、データファイルを移動して制御ファイルを削除するように構成できます。また、ファイルを作成するものが送信するMQメッセージによって駆動することもできます。 FTEエージェントはクライアントとしてWMQに接続できるため、小規模な展開で必要なWMQサーバーは1つだけであり、FTEエージェントは前述のすべてのプラットフォームに配置できます。唯一の例外は、z/OS FTEエージェントにローカル・キュー・マネージャーが必要なことです（z/OSプラットフォーム用のWMQクライアントがないため）。もちろん、アドホックなユーザー主導の転送用にも設定されています。
FTEは、すべての非永続メッセージと、データストリームを攻撃する2つのエージェント間の（もちろんWMQを介した）光制御フローを使用します。両側が稼働していると仮定すると、転送全体がメモリ内で行われ、キューマネージャのディスクには何も書き込まれないため、高速で叫びます。片側がダウンした場合、サービスが回復するとすぐに、転送は中断したところから再開します。両方のエージェントがデータとファイルをチェックサムするため、停止中または送信中にソースファイルまたはターゲットファイルのいずれかが変更された場合、転送は適切なエラーメッセージで中止されます。
スクリプトを作成する可能性のあるあらゆる種類の自動化は、転送の前または後に、送信側または受信側のいずれかで、Antまたは呼び出したい実行可能ファイルを使用して実行できます。たとえば、顧客のSFTPサーバーに送信するファイルを暗号化し、到着時にファイルを復号化するクライアントが1人います。これは、Antを呼び出して、アウトバウンド転送の前とインバウンド転送の後にGPGを実行することによって行われます。
私が大規模な保険会社で働いていたとき、さまざまなWindows/Linux/AIX /メインフレームサーバー間のファイル転送（ほとんどはSSL/TLS経由）を自動化および管理するために Connect：Direct を使用しました。