web-dev-qa-db-ja.com

SCSIとSANで信頼性はどのように達成されますか？

私はSCSIにかなり慣れていないので、これが正しいフォーラムであるかどうかさえわかりません。 （SCSIに関する質問をいくつか見つけたので、そうしました:)ですから、この質問を自由に改善/移行してください。

私はファイバーチャネル伝送で遊んでいて、TCPとは異なり、SCSI over FCP-3は配信が保証されていないという内部文書を読んでいるので、私の質問は次のとおりです。

  1. これは、SCSI標準/プロトコル自体が信頼できないことを意味しますか？しかし、かつてはハードディスクで非常に人気があったと思います。信頼性の問題はどのように解決されましたか？
  2. 同様に、信頼性はSAN環境でどのように処理されますか？
storagescsisan
1
wlnirvana

ServerFault用のものかもしれません。

しかし、あなたはかなり正しいです。ファイバチャネルには、TCPと同じ保護メカニズムはありません。それはその点でUDPに似ています（それは少し弱いアナロジーですが）そして同じ理由の多くのために-いくつかのアプリケーションでは、TCPはそれらの信頼性メカニズムのために悪い解決策です-あなたのストリーム再送信のために「ストール」する可能性があり、それはドロップされたパケットよりもほぼリアルタイムのアプリケーションを傷つけます。ストレージIO遅延は、約以上のときに「傷つけ」始めます20ms、それはTCPが本当にそれをするのに十分な時間ではありません。

FCPで発生するのは、エンドポイントのSCSIドライバーが信頼性を処理することです。これは、その一部として負荷分散も実行できるためです。通常、ファイバーをシングル接続するのではなく、ストレージへのデュアル独立パスを備えたデュアルHBAを使用します。

そのため、ドライバーはパケットを好きなようにルーティングし（一部は他よりも賢く、最近はほとんどがマルチパスを実行しますが、一部は非常に巧妙な適応マルチパスを実行します）、どのIOが確認されたかを追跡します。 OSは、必要に応じてIOをキューに入れることができますが、それが悪い考えであると考える場合はそうではありません。実際には、ルーチンのファイルシステムキャッシュメカニズムの一部としてこれを実行します。

これが、たとえば open にO_DIRECTオプションがある理由です。

   O_DIRECT (since Linux 2.4.10)
          Try to minimize cache effects of the I/O to and from this
          file.  In general this will degrade performance, but it is
          useful in special situations, such as when applications do
          their own caching.  File I/O is done directly to/from user-
          space buffers.  The O_DIRECT flag on its own makes an effort
          to transfer data synchronously, but does not give the
          guarantees of the O_SYNC flag that data and necessary metadata
          are transferred.  To guarantee synchronous I/O, O_SYNC must be
          used in addition to O_DIRECT.  See NOTES below for further
          discussion.
2
Sobrique

同じ比較をしている非公式の記事を見つけました。これは私が持っていた大まかな印象と一致します。この記事では、@ Sobriqueが言及しているように、FCスイッチまたはケーブルの1つから大きなSANへの障害に耐えるためのマルチパスも示しています。

SCSIは、ドロップされたコマンドを親切に受け入れません。 SCSIが失われたコマンドを許容できないというのは少し誤解です。それは可能ですが、回復するのに長い時間がかかります（比較的言えば）。多くのSCSIエラーを確認しましたが、システムの速度が低下してクロールします。したがって、SCSIコマンドを失わないことが最善です。

https://datacenteroverlords.com/2011/09/14/fibre-channel-and-ethernet-the-odd-couple/

FCPは正式には行われていないようです保証配信ですが...ウィキペディアの記事を読むと、FibreChannelは特定のビットエラーレートを指定しています（許容範囲/期待どおり）。 TCPは、FibreChannelよりもパケットの処理がはるかに少ないリンク上で動作するように設計されています。

ファイバチャネルには、輻輳/バッファのオーバーフローによるパケットのドロップを回避するためのフロー制御も含まれています。 IPはそうしません（そして、基盤となるネットワークがそうすることを期待していません）。

たとえば、Googleはこれを持っています クールペーパー 彼らが測定していた場所TCP平均1％から20％以上のパケット損失率。 （彼らは、ISPが20％以上の損失（ポリシング）ではなく1％の損失（シェーピング）をもたらしたテクノロジーを使用することを提唱しています。これらのテクノロジーは、IPネットワークが一般に輻輳の問題を処理する方法です）。

ほとんどのSCSI実装は、失敗したコマンドを再試行すると思います。それがどれほど標準化されているかはわかりませんが、さまざまな方法で調整できると思います。技術的には、これも配信を保証するものではありません。同じように、TCPは最終的にタイムアウトします（TCPは接続を断念して閉じます）。

3
sourcejedi