業務システムのデータを基幹システムへ渡すため、夜間に自動でファイルを伝送する仕組みを運用しています。伝送にはJP1/File Transmission Server/FTP（以下、JP1/FTP）を使い、伝送カードに登録した内容を決まった時刻に実行する構成です。
その夜間伝送が、421 Service not available, remote server has closed connection というエラーで異常終了しました。日中に再実行したら成功したので、そのときは一時的な不調だと思っていました。ところが数日後、同じ伝送カードがまた421で落ちます。1回目の対策は済んでいるのに、です。しかも原因はまったく別でした。
2回の421をどう切り分けたか、順に書いていきます。なお、実際のホスト名、アカウント名、IPアドレス、ディレクトリ、伝送カード名、相手側の具体的な時間帯は伏せ、業務システムと基幹システムの連携という形にしています。
JP1/FTPでは、伝送カードに伝送情報を登録する
先に、JP1/FTPの構成に触れておきます。この製品では、伝送する情報を「伝送カード」に登録して伝送します。相手ホスト名、相手ユーザ名、伝送ファイル名、伝送モード、圧縮モードなどを、カード単位で持つ形です。
今回の環境では、連携先ごとに伝送カードを分けています。基幹システム向け、別の業務システム向け、社内のデータベース向け、といった具合です。連携先が増えてもカードを追加すればよく、既存の伝送には影響しません。
実行結果は履歴として残ります。伝送番号、開始時刻と終了時刻、送受信の別、ローカルファイル名、伝送バイト数、相手ホスト名、終了状態、エラー種別が一覧で確認でき、1件を選べば詳細も見られます。今回の調査は、ほぼこの履歴だけで進みました。
1回目の421：再実行したら、成功してしまった
夜間の決まった時刻に起動した基幹システム向けの伝送が、異常終了していました。履歴のエラー種別は「プロトコルエラー」、メッセージは 421 Service not available, remote server has closed connection です。
最初に確認したのは、送るファイル側でした。ファイル名、更新日時、サイズに問題はなく、正常に作成されています。伝送が起動していないわけでもなく、予定時刻にきちんと動いていました。
次に、相手ホストへの ping と、FTPでの接続そのものを試しました。どちらも通ります。サーバーが落ちているわけでも、アカウントが無効化されているわけでもない。
そして、同じ伝送カードを手動で再実行したところ、正常終了しました。
ここが、この障害でいちばん判断を誤りやすいところでした。再実行で通ってしまうと、「一時的なネットワークの不調」「相手側の瞬間的な過負荷」あたりで片付けたくなります。実際、その日の対応としてはそれで復旧しています。
ただ、原因が分からないまま復旧しただけの状態です。同じ時刻にまた動く処理なので、翌日も同じことが起きる可能性が残っていました。
この件はエラーとして通知が届きましたが、そもそもジョブが起動していなければ通知も出ません。エラーメールが1通も来ないまま夜間処理が全滅していた件は、この記事とは逆のパターンです。
履歴の詳細を見ると、転送は始まってもいなかった
手がかりになったのは、異常終了した伝送の詳細情報です。
- 伝送時間：
00:00:00 - 伝送バイト：
0 - エラー種別：プロトコルエラー
伝送時間がゼロで、1バイトも送れていません。ファイルを送り始める前の、接続の段階で切られていたということです。
これが分かると、疑う対象が絞れます。送信ファイルの中身、文字コード、列数、ディレクトリの権限といった「転送してから問題になるもの」は全部外れる。残るのは、接続そのものを拒否する要因だけです。
421という応答コードも、これと整合します。421は「サーバ側が接続を受け付けられない状態として、接続を閉じた」ことを示すもので、認証の失敗やファイル操作の失敗とは違う段階のエラーです。ただし、なぜ受け付けられなかったのかまでは、コードからは分かりません。サービス停止、接続数の上限、接続元の制限、ファイアウォール。候補は複数あります。
原因は、夜間だけかかっていた接続元の制限だった
接続そのものを拒否する要因のうち、こちらから確認できないのは相手側の設定です。基幹システム側の担当者へ問い合わせたところ、外部からのFTP接続について、夜間の時間帯だけ、接続元を許可制で管理していました。
そして、こちらの伝送サーバーの接続元が、その許可リストへ登録されていませんでした。認証情報は正しく、経路も通っている。ただ、その時間帯に接続してよい相手として認められていなかった、という状態です。
ここで、再実行が成功した理由も説明がつきました。再実行したのは日中で、その時間帯には接続元の制限がかかっていなかったからです。
同じ伝送カード、同じ接続元、同じアカウント。違うのは実行した時刻だけで、それだけで結果が変わっていました。「再実行したら通ったので一時的な問題」という判断は、この構造だと必ず外れます。
対応として、伝送サーバーの接続元を、夜間の許可リストへ追加してもらいました。あわせて、この基幹システム向けの夜間伝送を今後追加・変更するときは、事前に許可リストへの登録要否を確認する、という手順を決めています。
この時点では、これで解決したつもりでいました。
2回目の421：接続元は登録済みなのに、また切られた
数日後、同じ伝送カードが、また421で異常終了しました。
前回の対策は済んでいます。接続元は許可リストに載っていて、夜間でも接続できるはずでした。それでも、接続直後に切断されている。
今回も履歴の詳細を確認しましたが、症状は前回と同じでした。伝送時間ゼロ、伝送バイトゼロ、プロトコルエラー。エラーメッセージも一字一句同じです。
違っていたのは、実行した日でした。
相手側へ確認したところ、基幹システムでは深夜の一定時間帯にバックアップを行っており、その間はFTPの受け口を完全に停止していました。さらに、特定の曜日は終日、外部からのFTPを受け付けていません。
1回目は「許可された接続元だけ通す」という制限、2回目は「そもそも誰も通さない」という停止。どちらも相手側から見れば接続を閉じているので、返ってくるのは同じ421になります。
恒久対応は、その曜日の連携をやめることにした
2回目の対応は、技術的な解決ではありませんでした。その曜日の伝送そのものを行わない設定に変更しています。
相手側のバックアップ運用は、こちらの都合で変えられるものではありません。時間をずらす案も検討はできますが、深夜帯の前後は業務システム側の処理と重なっていて、余裕がありませんでした。そもそも、その曜日に連携すべきデータがどれだけあるかを確認したところ、翌営業日にまとめて送っても業務上は支障のない内容でした。
無理に毎日送る必要がなかった、というのが結論です。エラーを技術で回避するのではなく、連携の前提条件を業務に合わせて見直したことになります。
自動化を組んだ後は、「毎日必ず動かす」ことを守るべき前提だと思い込みがちです。ただ、相手側の運用と噛み合っていないスケジュールを維持し続けると、エラー通知が定期的に鳴り、そのたびに担当者が確認する運用になります。止めてよいものを止める判断も、選択肢に入れておいた方がよさそうです。
421は「サーバ側が接続を閉じた」ことしか示しません。なぜ閉じたのかは、相手側の条件を確認しなければ分かりません。1回目の原因を覚えていたぶん、2回目はかえって判断が遅れました。
再実行の前に、どこまで進んでいたかを確認する
今回の2件は、どちらも接続段階での失敗だったため、再実行の判断は簡単でした。1バイトも送っていないので、相手側に中途半端なファイルが残っている心配がありません。
ただし、これは伝送バイトがゼロだと確認できたからこその判断です。転送が始まった後で失敗している場合は、そのまま再実行すると二重送信になる可能性があります。
異常終了を見つけたときは、まず履歴の詳細で次を確認するようにしています。
- 伝送バイト数がゼロか、途中まで進んでいるか
- 相手側に同名ファイルが到着していないか
- 基幹システム側で取り込みが始まっていないか
JP1のジョブが異常終了していても、ファイルが相手へ届いていることはあります。送信側の結果だけで判断せず、受信側の状態と合わせて確認してください。
連携を設計するとき、相手側へ確認しておくこと
今回の2件は、どちらも「相手側の受け入れ条件を知らなかった」ことが根本にあります。接続試験のときにアカウントとパスワードだけを確認して、通ったことで終わりにしていました。
同じことを繰り返さないために、連携を追加するときは次を確認する運用にしました。
- 接続元の制限があるか。あるなら、こちらの伝送サーバーは登録されているか
- その制限は常時か、特定の時間帯だけか
- 受け付けを停止する時間帯や曜日があるか（バックアップ、メンテナンス、定例停止）
- 接続元として認識されるのは、NATを通過した後のどのアドレスか
- 検証環境と本番環境で、接続元が別に登録されているか
特に、接続試験を管理者の端末から行うのは危険です。端末と伝送サーバーでは、接続元も経路も違います。本番のジョブが動くサーバーから、実際に伝送する時間帯に試すこと。これができていれば、1回目の421は稼働前に見つかっていました。
また、サーバー更改やネットワーク構成の変更で、接続元アドレスが変わることがあります。伝送カードの設定を移行しても、相手側の許可リストが旧環境のままなら接続できません。移行のチェック項目に入れておくべきところです。
相手側の受け入れ条件という意味では、データの中身も同じです。SAPへ送るコードの読替マスタに2件の登録漏れがあった件では、接続は成功していたのにデータ側で弾かれました。
まとめ
JP1/FTPの夜間伝送で発生した421エラーは、2回とも同じメッセージでしたが、原因は別でした。1回目は接続元が夜間の許可リストに未登録だったこと、2回目は相手側が特定の曜日にFTPの受け口を停止していたことです。
切り分けで役に立ったのは、履歴の詳細にあった伝送時間と伝送バイト数でした。どちらもゼロだったことから、転送前の接続段階で切られたと分かり、ファイルの中身や権限といった候補を外せています。
2回目は、その曜日の伝送をやめる形で決着しました。エラーコードは、何が起きたかは示しますが、なぜ起きたかまでは示しません。相手側のサーバーが絡む連携では、応答コードから原因を決め打ちせず、相手側の受け入れ条件まで確認するようにします。
コメント