☰

SCSIとSANはどのように信頼性を得るのですか？

tag-icon • tag-icon storage scsi san
SCSIとSANはどのように信頼性を得るのですか？

私はSCSIに初めて触れましたが、実際にこれが正しいフォーラムであるかどうかはわかりません。 （SCSIの問題が見つかったので、これをしました。）自由に改善/移行してください。

ファイバチャネル伝送を調査しており、TCPとは異なり、FCP-3を介したSCSIは提供が保証されていないという内部文書を読んでいます。したがって、私の質問は次のようになります。

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

答え1

同じ比較をする非公式記事を見つけましたが、おおよその印象と一致しました。 @Sobriqueが述べたように、この記事では、マルチパスがFCスイッチまたは大規模SANの単一ケーブル障害にも生き残ることができることを示しています。

SCSIは削除コマンドを親切に受け入れません。 SCSIがコマンドの損失を許容できないことは少し誤解です。はい、回復に時間がかかります（相対的に言うと）。システム速度を低下させるSCSIエラーの多くを見ました。したがって、SCSIコマンドを失わないことが最善です。

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

FCPは正式に保証する渡されましたが…Wikipediaの記事を読むと、FibreChannelは特定のビットエラーレート（許可/予想）を指定します。 TCPはリンク上で動作するように設計されており、FibreChannelよりもパケットへの関心がはるかに少ない。

FibreChannelには、輻輳/バッファオーバーフローによるパケット損失を防ぐためのフロー制御も含まれています。 IPはそうではありません。

たとえば、Googleにはこのようなものがあります。素晴らしい紙彼らは平均1％から1％の間のTCPパケット損失率を測定しました。20％以上。 （彼らはISPが20％以上の損失を引き起こす技術（政策）の代わりに1％の損失を引き起こす技術（シェーピング）を使用することを擁護しています。

私はほとんどのSCSI実装が失敗したコマンドを再試行すると思います。どれくらい標準化されているかはわかりませんが、いろんな面で調整ができたらいいですね。技術的には、これはTCPが最終的にタイムアウトになると予想できるように転送を保証しません（TCPは接続を放棄して閉じます）。

答え2

ServerFaultに関するものかもしれません。

しかし、あなたは正しいです。ファイバチャネルにはTCPと同じ保護メカニズムはありません。この点でこれはUDPに似ていますが（たとえ例えは少し弱いですが）、同じ理由でTCPはこの信頼性メカニズムのために一部のアプリケーションでは悪い解決策です。ストリームが再送信を中断する可能性があります。 「これはパケット損失よりもほぼリアルタイムのアプリケーションに大きなダメージを与えます。ストレージIOレイテンシが20ミリ秒を超えると、「傷」が発生し始めます。これは実際にTCPがタスクを実行するのに十分な時間ではありません。

FCPの場合、エンドポイントのSCSIドライバは安定性の一部としてロードバランシングも実行できるため、安定性の処理を担当します。通常、単一の光ファイバが接続されておらず、デュアル独立ストレージパスを持つデュアルHBAがあります。

したがって、ドライバはパケットを任意の方法でルーティングできます（一部のドライバは他のドライバよりもスマートです。最近はマルチパスを実行しますが、一部はかなりスマートな適応型マルチパスを実行します）、どのIOが承認されたかを追跡します。オペレーティングシステムは、適切な状況で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.

関連情報