ファむバヌチャネルの基本

FC SANの基本抂念を明確にするずいうトピックに぀いおは、匕き続き攟送したす。 最初の投皿ぞのコメントで、私は十分に深く掘ったず非難されたした。 特に、圌はFC自䜓に぀いおはほずんど語らず、BBクレゞット、IP、およびマルチパスに぀いおは䜕も語っおいたせん。 マルチパスずIPは個々の出版物のトピックですが、おそらくFCに぀いおは続けたす。 たたは、芋方を開始したす。



たず、小さな甚語の䜙談以前の投皿ぞのコメントから再び刺激を受けた。



ファむバヌたたはファむバヌ圓初、ファむバヌチャネルテクノロゞヌは、光ファむバヌ回線のみをサポヌトするように蚭蚈されおいたした。 ただし、銅線のサポヌトが远加されたずき、原則ずしお名前を保持するこずが決定されたしたが、暙準を参照するために英囜語のファむバヌを䜿甚したす。 American Fiberは、䞻にファむバヌぞの送信甚に保持されたす。

オリゞナル
ファむバヌチャネルはもずもず、光ファむバヌケヌブルのみをサポヌトするように蚭蚈されたした。 銅線のサポヌトが远加されたずき、委員䌚は原則ずしお名前を維持するこずを決定したしたが、暙準を参照する堎合は英囜英語のスペルファむバヌを䜿甚するこずにしたした。 䞀般的に光ファむバヌずケヌブルを指す堎合、米囜英語のスペルファむバヌは保持されたす。
IBM Redbook「SANおよびシステムネットワヌキングの抂芁」



開始する



OSIネットワヌクモデルず同様に、ファむバヌチャネルは5぀の局で構成されたす。 各レベルは、特定の機胜セットを提䟛したす。







FC-0は、物理むンタヌフェむスずメディアのレベルです。 物理的環境に぀いお説明したすケヌブル、コネクタ、HBA、トランシヌバ、電気的および光孊的パラメヌタ。



FC-1-䌝送および゚ンコヌドレベル。 送信前にデヌタを゚ンコヌドし、送信埌にデコヌドする方法に぀いお説明したす。 このレベルでは、3぀の䞻芁な機胜が定矩されおいたす。



FC-2-フレヌミングず信号のレベル。 送信される情報の構造ず構成、およびその送信の制埡ず管理を決定したす。 このレベルで実行される機胜



FC-3-基本サヌビス局。 このレベルは、将来ファむバチャネルに導入される可胜性がある新しい機胜のために芏定されおいたす。 このレベルでは、送信前のデヌタの暗号化ず圧瞮、およびいく぀かの方法でのデヌタストリヌムの分割ストラむピングなどが提䟛されたす。 しかし、私はこれたでそのような郚分の実装に遭遇しおいたせん。



FC-4-プロトコルマッピングレベル。 トランスポヌトずしおFCを䜿甚できるプロトコル、および実際には䜿甚順序これらのプロトコルをより䜎いレベルのFC0-3にマッピングするに぀いお説明したす。 SANの堎合、これらは次のずおりです。





そしお今、これらず他のあいたいなフレヌズに぀いおの詳现。 この蚘事では、FC SANむンフラストラクチャを䜜成および管理するずきに最も重芁な䞋䜍3レベルのみを怜蚎したす。



FC-0



おそらく、ケヌブル、トランスミッタヌ、およびそれらの特性の皮類の耇雑な衚は提䟛したせん。 第䞀に、ここにテヌブルを挿入するのは䞍䟿だから、第二に、これらのテヌブルは、FC ロシアのりィキペディア 、 非ロシアのりィキペディア に぀いお少なくずも䜕かが曞かれおいるどこにでもあるので、第䞉にそしお重芁な 、䞻なこずは本質を理解するこずですが、参照デヌタを芋぀けるこずは問題ではありたせん。

肝心なのは、マルチモヌドずシングルモヌドの2皮類のファむバヌがあるこずです。

マルチモヌドマルチモヌドファむバヌ、MMF -短波レヌザヌビヌム甚に蚭蚈された比范的広い断面50-62.5ミクロン。 「マルチモヌド」ずは、光がさたざたな方法でチャネルを通過できるこずを意味したす-ファむバヌの壁から倚重反射したす。 これにより、ケヌブルの曲げに察する感床は䜎䞋したすが、信号の匷床ず品質が䜎䞋し、このタむプは最倧500 mの短い距離に制限されたす。

シングルモヌドファむバヌSMFは、盎埄が小さい8〜10ミクロンファむバヌで、信号は長波レヌザヌによっお䌝送され、その光は人間の目には芋えたせん。 ここでは、光は唯䞀の方法で移動できたす-それぞれ盎線で、信号はより速く、より正確に送信されたすが、そのような信号を提䟛する機噚ははるかに高䟡なので、䞻に長距離最倧50 kmでの通信に䜿甚されたす。 シングルモヌドファむバは、ねじれや曲率の圱響を受けやすくなっおいたす。

繊維の皮類に関する詳现な蚘事はこちらにありたす 。

2぀のデバむスを接続するために2本のケヌブルが䜿甚されるこずに泚意しおください。 1぀は送信に䜿甚され、もう1぀は受信に䜿甚されたす。 したがっお、それらを正しく接続するこずが重芁です䞀方のTxを他方のRxに。



たた、 ダヌクオプティクス  ダヌクファむバヌ などの甚語に぀いおも蚀及したいず思いたす。 この甚語は、䜕らかの方法で特別な方法で色付けされおいるこずを意味したせん。 これらは、原則ずしお、リヌスされおいる長距離通信郜垂たたは遠方の建物間、および远加の信号増幅装眮を䜿甚する必芁のない専甚の光通信回線です所有者によっお提䟛されたす。 ただし、これは光ケヌブルであり、独自の刀断で配眮されるため、光信号が通過するたで「暗」のたたです。



HBA、ディスクアレむ、スむッチなどのデバむスの芁玠であるASICによっお、FC-0からFC-1ぞ、たたはその逆ぞのスムヌズな移行が提䟛されたす。

りィキペディアから

ASIC 英語からの略語。 特定甚途向け集積回路 、「特別な目的のための集積回路」-特定の問題を解決するために特化した集積回路。 汎甚集積回路ずは異なり、特殊な集積回路は特定のデバむスで䜿甚され、このデバむスに固有の厳密に制限された機胜を実行したす。 その結果、関数の実行が高速になり、最終的には安䟡になりたす。 ASICの䟋ずしおは、携垯電話の制埡専甚に蚭蚈されたマむクロチップ、オヌディオおよびビデオ信号信号プロセッサを゚ンコヌド/デコヌドするハヌドりェア甚のマむクロチップがありたす。


ファむバチャネル機噚では、ASICは次の機胜芁玠で構成されおいたす。



ASIC





トランシヌバヌ、トランシヌバヌ、たたはSFP — FCスむッチの堎合、これらはケヌブルをポヌトに接続するために必芁な個別のモゞュヌルです。 それらは、短波短波、SW、SXず長波長波、LW、LXが異なりたす。 LWトランシヌバヌは、マルチモヌドおよびシングルモヌドファむバヌず互換性がありたす。 SWトランシヌバヌ-マルチモヌドのみ。 そしお䞡方に、ケヌブルはLCコネクタヌによっお接続されたす。

たた、 SFP xWDM Wavelenght Division Multiplexingもあり、単䞀の光ビヌムで耇数の゜ヌスから長距離にわたっおデヌタを送信するように蚭蚈されおいたす。 ケヌブルを接続するには、SCコネクタが䜿甚されたす。



FC-1



8/10および64/66


このレベルで最初に発生するのは、情報の゚ンコヌド/デコヌドです。 これはかなり掗緎されたプロセスであり、その間、着信情報の8ビットごずに10ビット衚珟に倉換されたす。 これは、デヌタの敎合性の制埡を匷化し、デヌタをサヌビス信号から分離し、デヌタストリヌムからクロック信号を埩元する機胜れロず1のバランスを維持を目的ずしお行われたす。

これにより、蚈算できるように、デヌタストリヌムの20が冗長オヌバヌヘッドであるため、有甚な垯域幅が著しく枛少したす。 しかし、ずりわけ、公匏トラフィックはこのストリヌムのかなりの郚分を占める可胜性がありたす。

ただし、1G、2G、4G、および8G機噚では8/10コヌディングが䜿甚されおいるこずは朗報です。 10Gの実装ず16Gからは、64/66の原則に埓っお゚ンコヌドが実行され、ペむロヌドが倧幅に増加したす8/10の堎合は80に察しお最倧97。



順序付きセット


ロシア語版りィキペディアでは、この甚語は「 順序付きセット 」ずしお翻蚳されおいたす 。 私の意芋では、ここでの語順は、「順序」の意味ではなく、「順序、呜什」の意味で理解されるべきです。

そもそも、FCのコンテキストで䜿甚される別の甚語- 送信ワヌド -送信するデヌタの最小郚分で、4バむトに盞圓したす。 送信された情報の量が少ない堎合、送信ワヌドは、受信偎で切り取られた特別な充填バむト充填バむトによっお補完されたす。

したがっお、 順序付きセットは特別なナヌティリティ送信ワヌドです。 これらは3぀のカテゎリに分類されたす。

  1. フレヌム区切りフレヌムの開始、SOFおよびフレヌムの終了、EOF。
  2. 2぀の基本信号-IDLEポヌトはデヌタを受信たたは送信する準備ができおいるおよびR_RDY受信者が準備ができおいる-ポヌトはデヌタの次の郚分を受信するためのバッファヌを解攟した
  3. 基本シヌケンスプリミティブシヌケンス

    • NOS操䜜䞍可-ポヌトが切断を怜出/接続なし
    • OLSオフラむン状態-ポヌトが接続の確立を開始するか、ポヌトがNOSを受信したか、ポヌトがオフラむン状態になりたす
    • LRリンクリセット-接続リセットの初期化。 OLSたたはいく぀かの送受信゚ラヌ通垞はフロヌ制埡のレベルを受信した堎合に送出されたす。 送信ポヌトは、バッファずそのカりンタをクリアしたす。
    • LRRリンクリセット応答-LRぞの応答。 送信ポヌトは、バッファずそのカりンタをクリアしたす。




リンクの初期化


ポヌトAずポヌトBの間に物理接続が確立されるず、ポヌト間で次の「代謝」が発生したす。





FC-2



フレヌム


ファむバヌチャネル環境で送信されるすべおのデヌタは、フレヌムフレヌムに分割されたす。 フレヌム構造は次のずおりです。





フレヌム間のギャップは、特別な「フィルワヌド」で埋められたす-フィルワヌド。 通垞、これはIDLEですが、FC 8G以降では、銅線機噚の電気ノむズを枛らすためにIDLEの代わりにARBFFの䜿甚が暙準化されたしたただし、デフォルトではスむッチはIDLEを䜿甚したす。



シヌケンス


ほずんどの堎合、゜ヌスは2112バむト1フレヌムの最倧デヌタ量よりもはるかに倚くの情報をレシヌバに送信しようずしたす。 この堎合、情報はいく぀かのフレヌムに分割され、これらのフレヌムのセットはシヌケンスず呌ばれたす。 パラレル送信䞭に䜙分なものがフレヌムの論理シヌケンスにくぎ付けになるのを防ぐため、各フレヌムのヘッダヌにはフィヌルドSEQ_IDシヌケンス識別子およびSEQ_CNTシヌケンスのフレヌム番号がありたす。



亀換


単䞀の操䜜を担圓する1぀以䞊のシヌケンスは、亀換ず呌ばれたす。 送信元ず受信者は耇数の䞊列亀換を行うこずができたすが、単䜍時間あたりの各亀換には1぀のシヌケンスのみを含めるこずができたす。 Exchangeの䟋むニシ゚ヌタヌはデヌタを芁求しシヌケンス1、タヌゲットはむニシ゚ヌタヌにデヌタを返しシヌケンス2、その埌ステヌタスを報告したすシヌケンス3。 無関係なフレヌムのセットは、このシヌケンスセットに割り蟌むこずができたせん。

このプロセスを制埡するために、各フレヌムのヘッダヌには、フィヌルドOX_ID発信者亀換ID-亀換の発信者が入力ずRX_ID応答者亀換ID-受信者が応答フレヌムに入力し、倀OX_IDをコピヌするが含たれたす。



サヌビスのクラス


アプリケヌションごずに、サヌビスレベル、配信保蚌、接続時間、垯域幅の芁件が異なりたす。 䞀郚のアプリケヌションでは、動䜜䞭に保蚌された垯域幅が必芁ですバックアップ。 その他のアクティビティは可倉であり、䞀定の保蚌されたチャネル垯域幅を必芁ずしたせんが、送信された各パケットの受信時に確認が必芁です。 これらのニヌズを満たし、柔軟性を提䟛するために、FCは次の6぀のサヌビスクラスを定矩したす。



クラス1


このクラスでは、2぀のデバむス間の最倧垯域幅を予玄する専甚接続が確立されたす。 領収曞の確認が必芁です。 フレヌムが゜ヌスを離れたのず同じ順序で受信機に到着する必芁がありたす。 他のデバむスが䌝送媒䜓を䜿甚するこずを蚱可しないずいう事実により、非垞にたれにしか䜿甚されたせん。



クラス2


垞時接続なしで、配信確認あり。 送信フレヌムず配信フレヌムの順序を䞀臎させる必芁がないため、さたざたな方法で工堎を通過できたす。 クラス1よりもリ゜ヌスに察する芁求は少なくなりたすが、配信を確認するず垯域幅の䜿甚率が増加したす。



クラス3


氞続的な接続および配信の確認なし。 ファクトリリ゜ヌスを䜿甚するずいう芳点からは最適ですが、䞊䜍レベルのプロトコルがフレヌムを正しい順序で収集し、欠萜したフレヌムの転送を再芁求できるこずを前提ずしおいたす。 最も䞀般的に䜿甚されたす。



クラス4


クラス1ず同様に、䞀定の接続、確認、フレヌムの順序が必芁です。䞻な違いは、垯域幅党䜓を予玄するのではなく、その䞀郚のみを予玄するこずです。 これにより、特定のQoSが保蚌されたす。 接続品質の保蚌が必芁なマルチメディアおよび゚ンタヌプラむズアプリケヌションに適しおいたす。



クラス5


ただ完党には説明されおおらず、暙準に含たれおいたせん。 以前は、接続を必芁ずしないが、デバむスにバッファリングせずに、衚瀺されたずおりにデヌタを即座に配信する必芁があるクラス。



クラス6


クラス1オプション、ただしマルチキャスト。 ぀たり、1぀のポヌトから耇数の゜ヌスたでです。



クラスf


クラスFは、スむッチ間リンクISLで䜿甚するためにFC-SW暙準で定矩されおいたす。 これは、工堎の監芖、管理、および構成に䜿甚される配信障害通知を備えた非氞続的なサヌビスです。 原則はクラス2に䌌おいたすが、その原則はNポヌトノヌドポヌト間の盞互䜜甚に䜿甚され、クラスF-Eポヌトの通信スむッチ間に䜿甚されたす。



フロヌ制埡


送信偎が過剰なフレヌムで受信偎を過負荷にしお受信偎が砎棄し始める状況を防ぐために、FCは送信デヌタのフロヌを制埡するメカニズムフロヌ制埡を䜿甚したす。 それらの2぀がありたす-バッファからバッファぞのフロヌ制埡ず゚ンドツヌ゚ンドのフロヌ制埡。 それらの䜿甚は、サヌビスクラスによっお芏制されおいたす。 たずえば、クラス1ぱンドツヌ゚ンドメカニズムのみを䜿甚し、クラス3はバッファツヌバッファを䜿甚し、クラス2はこれらのメカニズムの䞡方を䜿甚したす。



バッファヌ間フロヌ制埡


技術の原則- 各䜏宅ぞのロヌン;フレヌムの送信は、送信するロヌンの存圚によっお保蚌される必芁がありたす。

ポヌト入力に到着するすべおのフレヌムは、特別なキュヌバッファヌに配眮されたす。 これらのバッファの数は、ポヌトの物理特性によっお決たりたす。 1぀のバッファヌキュヌ䜍眮は1぀のロヌンに察応したす。 各ポヌトには2぀のクレゞットカりンタヌがありたす。

TX BB_Credit-クレゞットカりンタヌを転送したす。 各フレヌムの送信埌、1ず぀枛少したす。カりンタ倀がれロになった堎合、送信は䞍可胜です。 R_RDYが受信ポヌトから受信されるずすぐに、カりンタヌが1増加したす。

RX BB_Credit-クレゞットロヌンのカりンタヌ。 フレヌムが受信され、バッファに配眮されるずすぐに1枛少したす。フレヌムが凊理たたは送信されるず、カりンタヌが1増加し、R_RDYが送信者に送信されたす。 カりンタ倀が0に䜎䞋した堎合、原則ずしお、新しいフレヌムの受信を停止する必芁がありたす。 実際には、クレゞット同期゚ラヌが原因で、RX BB_creditがれロになった埌に゜ヌスがすでに1぀たたは耇数のフレヌムを送信したずいう状況が発生する堎合がありたす。 この状況は、 バッファオヌバヌフロヌず呌ばれたす。 ほずんどの実装では、ポヌトはそのような状況を「良い方法で」凊理したす-予備のバッファが原因です。 ただし、このような堎合の䞀郚の機噚はリンクリセットをリンクする堎合がありたす。



ここからは、ポヌト間隔がパフォヌマンスに倧きく圱響したす。 距離が長く、スルヌプットが高いほど、受信者が少なくずも最初のフレヌムを受信する前であっおも、より倚くのフレヌムが送信されたす消費された転送クレゞットを読み取りたす。 この状況は、FCスむッチのアヌキテクチャの機胜によっお促進されたす。 実際には、バッファの数は各ポヌトに厳密に固定されおいるわけではありたせん8぀の必須を陀くが、すべおに共通です。 たた、「遠方リンク」が自動たたは手動で怜出された堎合、このポヌトに察しおスむッチによっお割り圓おられたバッファヌの数が増加したす。 共有メモリのもう1぀の利点は、スむッチ内で1぀のポヌトから別のポヌトにバッファを駆動する必芁がないこずです。



゚ンドツヌ゚ンドのフロヌ制埡


これは、EE_Creditカりンタヌによっお実装されたす。このカりンタヌは、確認Acknowledge、ACKを受信せずに゜ヌスがレシヌバヌに送信できる最倧フレヌムを決定したす。 BB_Creditずは異なり、デヌタフレヌムにのみ適甚され、゚ンドノヌド間で亀換/アカりンティングが行われたす。



終わり



最初は、蚘事は半分になるず思われたしたが、執筆䞭に倚くの詳现が明らかになり、それなしでは幞犏は䞍完党に芋えたした。 私はただ匷調したいものをたくさん萜ずさなければなりたせんでした-執筆プロセスは無限になるず脅かされおいたした。 誰かがコメント、提案、他に曞く䟡倀があるものに぀いおの提案を持っおいる堎合、私は感謝したす。 そしお、この堎所を読んでくれたみんなに感謝したす。



材料は次の゜ヌスから䜿甚されたした。

IBM Redbook「SANおよびシステムネットワヌキングの抂芁」

EMCネットワヌクストレヌゞの抂念ずプロトコル

Brocade SAN Fabric Administrationベストプラクティスガむド



All Articles