無効なイーサネット

前回の記事「 Ethernet＆FC 」の続きで、NetApp FASストレージシステムと連携するためのイーサネットネットワークの最適化に関する具体的な推奨事項を示したいと思います。 ただし、ここで説明した事項の多くは、他のソリューションにも役立つ可能性があると思います。

無効なイーサネット

イーサネットの「信頼性」を強く疑う人のために。 FC 8Gから10 GBEに完全に切り替えるように説得したいわけではありませんが、技術に対する不信と誤解のある特定の領域を削除したいのです。 技術専門家は、常に合理的かつ「冷静な」態度で問題に取り組む必要があります。 同時に、「イーサネットがフレームを失っている」という表現は、「偏りのないアプローチ」や「主観的思考」とはほとんど言えません。 イーサネットの信頼性についてのこの確固たる意見がどこから来たのかを検討することを提案します。
したがって、イーサネットが共有同軸ケーブル環境を使用する10Mbit / sであったとき、それはすべて標準の誕生から始まりました。 さらに、情報の送信は「半二重」でした。 ある時点で、1つのノードまたは情報の送信または受信によって時間が実行される可能性があります。 そのようなドメインのネットワークノードが多いほど、衝突が多くなり、「半二重」によって状況が悪化し、フレームは本当に失われました。 その後、イーサネットはさらに一歩進み、ツイストペアケーブルを使用して将来のバックログを提供し始めましたが、同じように愚かなハブがすべてのネットワークノードを1つのコリジョンドメインに結合し、状況は本質的に変わりませんでした。 「スイッチ」という誇りのある名前のスマートデバイスが登場しました。1つのポートから別のポートにフレームを複製するだけでなく、フレームに登って、フレームの送信元のアドレスとポートを記憶し、受信者ポートにのみ送信しました。 そして、すべてがうまくいきますが、衝突ドメインは断片化され、スイッチポートを持つノードにのみ縮小されているという事実にもかかわらず、100Mbit / sのネットワークでも衝突は依然として何らかの形で残っています。彼らがお互いにフレームを同時に送信しようとしたとき。 次に起こったこと-「デュプレックス」（10BASE-T、IEEE 802.3i）、つまり 各ノードは、異なるリンクでフレームを同時に送受信できます。ノード用のRXとTXの2つのペアとスイッチ用の2つのペアです。 1 GBEでは、半二重モードは存在しません。 これはどういう意味ですか？ 衝突は永遠に消えました...彼らはもうありません。 互いに密接に関連する2つの小児期イーサネット疾患があります。これは、バッファがオーバーフローするとスイッチがフレームを「忘れる」可能性があり、これは通常「ループバック」（イーサネットループ）が原因で発生します。 1）ロスレスイーサネットとも呼ばれるイーサネットプロトコル用のDCBアドオンは、 FCの場合のようにフレームを失わないようにするプロトコルのセットです。 2） データセンターのレベルスイッチにメモリを追加しました。 3）そして、10 GBEネットワークと特にシスコはさらに一歩を踏み出し、 データセンター向けNexusスイッチのラインでTRILLを提案しました。 TRILLプロトコルとFabricPathは、ループバックを防ぐためのIPパケットの存続時間フィールドと同様に、イーサネットフレームの新しいホップカウントフィールドの目的を単に決定するだけでなく、IPから「借用」されたいくつかの機能により、最近の小児病からイーサネットを排除します。

ジャンボフレーム

NFS 、 iSCSI 、 CIFSプロトコルを使用する場合、可能であればスイッチとホストでジャンボフレームを有効にすることをお勧めします。 NetApp ストレージは現在、 MTU 9000をサポートしています。これは、最大のイーサネット10GBです。 この場合、 ジャンボフレームは、イーサネットフレームのルート全体（送信元から宛先）に含める必要があります。 残念ながら、現時点ではすべてのスイッチおよびすべてのホストネットワークアダプターが「最大」 MTUをサポートしているわけではありません。そのため、サーバーと組み込み10GBスイッチを備えたHPブレードシャーシを適用すると、最大8000 MTUをサポートするため、 ストレージ側で最も多くを選択する必要があります適切なMTU値。 MTUが何であるかについて多少の混乱があるため、設定する必要があるMTU値を理解するのは困難です。 たとえば、イーサネットインターフェイスにMTU 9000値が設定されたNetApp ストレージシステムの通常の動作では 、 MTU値が 9000（Catalyst 2970/2960/3750/3560シリーズ）、9198（Catalyst 3850）のいずれかの値に設定されたスイッチで「通常」動作します。 ）、9216（Cisco Nexus 3000/5000/7000/9000、Catalyst 6000/6500 / Cisco 7600 OSR Series）、その他では一般にこの値は9252である必要があります。原則として、スイッチのMTUを最大許容値（9000以上）に設定します。 ）、すべてが機能します。 明確にするために、対応する記事Maximum Transmission Unit（MTU）を読むことをお勧めします。 神話とサンゴ礁 。

Cisco UCSのジャンボフレーム

各ファブリックインターコネクトのコマンドラインから設定を実行します。

system jumbomtu 9216 policy-map type network-qos jumbo class type network-qos class-default mtu 9216 multi-cast-optimize exit system qos service-policy type network-qos jumbo exit copy run start 

流量制御

フロー制御設定は 、 ストレージポートとそれらに接続されているスイッチポートの両方に対応する必要が あります。 つまり、 ストレージポートのフロー制御がnoneに設定されている場合、 スイッチのフロー制御はオフに設定する必要があり、その逆も同様です。 別の例： ストレージシステムがflowcontrol sendを送信する場合 、スイッチはそれらを受信するように設定する必要があります（ flowcontrol receive on ）。 フロー制御設定の不整合により 、確立されたプロトコルセッション（ CIFSやiSCSIなど）が中断しますが、通信は継続しますが、セッションが絶えず中断するため、リンクの負荷が大きくなると動作が非常に遅くなり、負荷が小さいときには問題はまったく発生しません。

• 原則として、可能であれば、 flowcontrol TR-3428を含めないでください。
• 10GBネットワークの場合、 flowcontrolを有効にすることは強く推奨されません。
• 1GBネットワークの場合、 フロー制御を有効にすることができます （ルールの例外として）： ストレージはフロー制御を送信し、スイッチは受け入れます - ストレージとスイッチで送信するようにフロー制御を設定します （または送信/ txオフ ＆ 受信/ rxオン ）。
• 100 MBネットワークの場合（ルールの例外として）、ストレージとスイッチの送受信フロー制御コマンドの両方で受信と送信のフロー制御を有効にできます。
• そのような推薦がここにある理由に興味がある人。
• TR - 3802も参照してください
• ストレージおよびスイッチ設定の例は、関連記事に記載されています。

DCB （ロスレス）Eternetの「通常の」FlowControlとPFC （IEEE 802.1Qbb）を混同しないでください。

スパニングツリープロトコル

「クラシックイーサネット」（つまり、「データセンター」レベルではないイーサネット）でNetAppを使用する場合は、 RSTPを有効にして、エンドノード（ ストレージとホスト）がportfastを有効にして接続するイーサネットポートを構成することを強くお勧めします。 TR-3749 「データセンター」レベルのイーサネットネットワークにはスパニングツリーはまったく必要ありません。vPCテクノロジーを備えたCisco Nexusシリーズスイッチは、このような機器の例として使用できます。

統合ネットワーク

10 GBEの「普遍性」を考慮して、 FCoE 、 NFS 、 CIFS 、 iSCSIがvPCやLACPなどのテクノロジーの使用、およびイーサネットネットワークのメンテナンスの容易さとともに同じ物理学を通過できる場合、プロトコルとスイッチをFCから区別し、機会を提供します変化するビジネスニーズの場合の「操作」と投資の保存。

FC8 vs 10GBE：iSCSI、CIFS、NFS

NetApp ストレージシステムの内部テスト（他のストレージベンダーでは、この状況は異なる場合があります） FC 8Gおよび10 GBE iSCSI 、 CIFS 、およびNFS は 、 OLTPおよびサーバーおよびデスクトップ仮想化に典型的な、 ほぼ同じパフォーマンスと遅延を示します。 小さなブロックとランダムな読み取りのある負荷の場合。
イーサネットとFCの類似点、相違点、見通しについて説明した記事をよく理解することをお勧めします。

お客様のインフラストラクチャに2つのスイッチが含まれる場合、 SANとイーサネットネットワークの両方をセットアップする同じ複雑さについて話すことができます。 しかし、多くのお客様にとって、 SANネットワークは「全員が全員を見る」2つのSANスイッチに要約されることはなく、原則として構成はそこで終わりません。この点で、イーサネットメンテナンスははるかに簡単です。 通常、顧客のネットワークのSANは 、冗長リンクとリモートサイトへのリンクを備えた多数のスイッチであり、決して維持するのは簡単ではありません。 また、何か問題が発生した場合、 Wiresharkのトラフィックはリッスンしていません。

Cisco Nexus 5500などの最新のコンバージドスイッチは、イーサネットとFCの両方のトラフィックを切り替えることができ、ツーインワンソリューションで将来の柔軟性を高めます。

ラック

また、EtherChannel LACPを使用したポート集約の可能性についても忘れないでください。 また、アグリゲーションはイーサネットポートを魔法のように結合するのではなく、トラフィックをそれらの間で分散（バランス）するだけです。つまり、2つのアグリゲートされた10 GBEポートが常に最大20 GBEに到達するわけではありません。 ここで、 ストレージがホストとは別のIPサブネットにあるかどうかに応じて、適切なバランス方法を選択する必要があることに注意してください。 SHDがホストとは別のサブネットにある場合、常に同じであるため、 MACバランシング（宛先）を選択できません-ゲートウェイのMACアドレス。 ストレージシステム上の集約リンクの数よりもホストが少ない場合、ネットワークロードバランシングアルゴリズムの完全性と制限を考慮して、バランシングは最適に機能しません。 逆もまた同様です。集約リンクを使用するネットワークノードが多くなり、バランシングアルゴリズムが「正しく」選択されるほど、集約リンクの最大帯域幅はすべてのリンクの帯域幅の合計に近づきます。 LACPバランシングの詳細については、記事「リンクの集約とIPトラフィックのバランシング 」を参照してください。
TR-3749は、NetAppストレージおよびCiscoスイッチを使用してVMWare ESXiを構成する際の微妙な違いについて説明しています。

時間が経つにつれて、ネットワーク最適化に関するこの記事に何か追加するものがあると確信していますので、随時ここに戻って確認してください。

本文の誤りや提案についてはPMにコメントを送ってください。