🙇🏾 🏨 🍉 ストレージのリンクアグリゲーションとIPトラフィックバランシング ✍🏻 ♟️ 🧒🏾

仮想化機能を備えた2つまたは4つのサーバー、場合によってはスタッキング機能を備えた2つのイーサネットスイッチ、およびマルチシャーシEtherChannelとジュニアストレージシステムを使用することが多い小規模企業の場合、これは中規模ビジネスインフラストラクチャの完全に標準的な構成です。
そのような企業にとっては、機器を可能な限り活用するために、利用可能なすべての技術を最大限に活用することが非常に重要です。この記事では、これを実現する方法について説明します。

ボード上の最新のサーバーには通常、少なくとも2つの1Gbデータインターフェイスと1つの100Mbの管理インターフェイスがあります。

ジュニアNetApp FAS 2240 / FAS 2220シリーズのストレージシステムでは、各コントローラーに搭載されており、特に4つの1Gbポートがあります。
つまりスタック上の2つのスイッチが各シャーシから各スイッチへのリンクを集約するマルチシャーシEtherChannelを使用して、これらすべてのリンクのフォールトトレランスと帯域幅の使用率の両方を取得するスキームを使用することは非常に論理的です FlexPod Expressのイメージと似たようなアーキテクチャですが、NexusシリーズのCiscoスイッチのようなファッショナブルな高価なvPC機能がないため、この場合は、インライン化の代わりに、スイッチのスタックが使用されます。とにかく、このスキームのサーバーとスイッチはどのメーカーのものでも構いません。すべてが予算に余裕がない場合は、サーバーへの直接接続を使用できます。サーバーに2つのポートが搭載されている場合、4つのサーバーを接続でき、5番目のサーバーを追加する必要がある場合は、スイッチを購入する必要があります。

FlexPod Express接続図。

この記事で説明する回路の例を次に示します。
FAS 2240-4 HA-4つの1Gbitリンクを持つ2つのコントローラー
ストレージとの通信用に1 GBの専用ネットワークポート4個ごとに、VMware ESXiを搭載した2台のサーバー
マルチシャーシEtherChannelおよびLACPをサポートするスタック上の2ギガビットスイッチ

したがって、使用可能なすべての帯域幅と、使用可能なサーバーおよびストレージインターフェイスを使用する必要があります。つまりサーバー1は主にコントローラーAにあるVM、サーバー2はコントローラーBにあるVMで動作し、すべて4つのインターフェースを持ち、VMは4つのグループに分割され、すべてが均等かつ正直に分割されます。

理論部

しかし、ネットワークの負荷分散は、「魔法のように」すべてのリンク自体にこの負荷を塗りつぶすことはできません。集約チャネル内のリンクの1つを交互に使用できるようにするアルゴリズムがあります。これらのアルゴリズムの1つは、1つのリンクを選択して、ヘッダーから受信した送信元IPアドレスと宛先IPアドレスの合計のハッシュに基づいています。そして、このニュアンスは私たちの計画で重要な役割を果たしています。送信元IPと宛先IPの2つの異なる組み合わせのハッシュ合計が同じ場合、これらの組み合わせには同じ物理リンクが使用されるためです。つまり、ネットワークトラフィックバランシングアルゴリズムの仕組みを理解し、IPアドレスの組み合わせが、NetApp TR - 3749 、 TR - 3802 、およびTR - 3839のベストプラクティスに基づいて、フォールトトレラントインフラストラクチャスキームを取得し、すべてのネットワークリンクを使用することを確認することが重要です。

原則として、2〜4台のサーバーは帯域幅の観点から1Gbリンクをロードしません。すべてのリンクを同時に使用すると、ネットワークノード間の相互作用の速度とピーク負荷の帯域幅にプラスの効果があります。

説明

以下では（簡略化のため）、1つのコントローラー、1つのサーバー、およびNFSプロトコルを使用した操作について説明します。

2つのコントローラーリンクが1つのスイッチに接続され、2つが別のスイッチに接続されます
IPバランシングを備えたマルチシャーシLACPがスイッチ側で構成されています
コントローラーポートのスイッチのFlowcontrol = on
すべてのポートのコントローラーでFlowcontrol = sendを設定します
コントローラー側の4つの1GBリンクは、IPバランシングを備えた1つのLACPに結合されます。
VLANが VIF （ifgrp）の上に作成され、IPが割り当てられ、3つの追加のエイリアスが作成されました（アドレスは順次発行されました）
4つのボリュームが作成され、qtreeが各ボリュームに作成され、ボリュームがNFSによってエクスポートされます
4つのIPバランスインターフェイスを持つESXiサーバーで作成されたvSwitch
このvSwitchで、vmkernelポートは同じIPサブネットと同じVLANに作成され、そこにメインIPとコントローラーのエイリアスが配置されます
ジャンボフレームはチェーン全体に含まれます（ストレージ、スイッチ、スイッチ上のVLAN 、 vSwitch 、vmkernelポート）
ESXiに追加された4つのNFSデータストア、すべて異なるIPアドレスから（つまり、プライマリIPとすべてのコントローラーエイリアスの両方が関係します）
4 VM vmware-io-analyzer.ovaは、たとえば、最大スループットパターンを使用してリンクの負荷をチェックするための異なるNFSデータストア上にあります

する必要があります：

1つのNFSエクスポートが同じIPアドレスのすべてのVMware ESXiホストに接続されたため、VMwareはそれを1つのデータストレージとして認識し、異なるものとして認識しませんでした（ iSCSIの場合、そのような要件はなく、サーバーごとに異なるIP ターゲット、 IQNを指定できます））
1つのサーバーから異なるデータストレージへのトラフィック（着信および発信）は、異なるサーバーおよびストレージリンクを通過する必要があります
異なるサーバーから1つのデータストレージへのトラフィック（着信および発信）は、異なるストレージリンクを通過する必要があります

カスタマイズ

NetApp FAS ストレージチューニングフラグメント：

「 ifgrp create lacp vif1 -b ip e0d e0b e0c e0a 」行のパラメーター「 lacp 」は、ドキュメントのダイナミックマルチモードに対応しており、スイッチの設定と一致する必要があることに注意してください。 TR - 3802
また、ストレージ側とスイッチの両方で正しいフロー制御設定を忘れないでください。ストアがフロー制御を「送信」（ flowcontrol send ）する場合、「一方で」スイッチは、フロー制御を「受信」するように構成する必要があります（ flowcontrol receive on ）。逆もまた同様です。誰も送信しない場合は、誰も受け入れるように設定しないでください。フロー制御の詳細。

NetApp 7モードのセットアップ例

san01a> rdfile /etc/rc #Auto-generated by setup Thu may 22 13:26:59 GMT 2014 hostname san01a ifgrp create lacp vif1 -b ip e0d e0b e0c e0a vlan create vif1 53 ifconfig e0a flowcontrol send up ifconfig e0b flowcontrol send up ifconfig e0c flowcontrol send up ifconfig e0d flowcontrol send up ifconfig e0M `hostname`-e0M netmask 255.255.255.0 broadcast 10.10.10.255 flowcontrol full partner 10.10.40.11 mtusize 1500 trusted wins up ifconfig e0P `hostname`-e0P netmask 255.255.252.0 broadcast 192.168.3.255 flowcontrol full up ifconfig vif1-53 `hostname`-vif1-53 netmask 255.255.255.0 partner vif1-53 mtusize 9000 trusted -wins up ifconfig vif1-53 alias 10.10.53.31 netmask 255.255.255.0 up ifconfig vif1-53 alias 10.10.53.32 netmask 255.255.255.0 up ifconfig vif1-53 alias 10.10.53.33 netmask 255.255.255.0 up route add net default 10.10.10.3 1 routed on options dns.domainname netapp.com options dns.enable on options nis.enable off savecore

NFSのフェールオーバー

2つのコントローラーがフォールトトレラントペアで機能し、1つのコントローラーが故障した場合、2つ目のコントローラーが（NetApp FailOverの観点から）「オーバーエット」し、2つのコントローラーが物理コントローラーで機能することを思い出してください。ホスト側からは、このような90秒の移動の場合にタイムアウトを設定することが非常に重要です。レコードパートナーvif1-53に注意してください。つまり、FailOverの場合、2番目のコントローラーに移動すると、この仮想インターフェイスの設定も一緒になります。したがって、このエントリを示すことを忘れないでください。そうしないと、コントローラーが食べ過ぎて、データが古いアドレスで利用できなくなります。インターフェイスにパートナーを割り当てる一般的なロジックは次のとおりです。

VLANを持つチームインターフェイス（ VIF ）がある場合は、そのような各VLANで構成します。
VIFが存在するが、すでにVLANが存在しない場合は、そのような各VIFインターフェイスで構成します。
VIFが存在しないが、物理インターフェイスにVLANがある場合は、そのような各VLANで構成します。
VIFまたはVLANがどこにも存在しない場合、各物理インターフェイスに。

また、移動する「対象」があるように、2番目のコントローラーのVIFとVLANに同じ設定を行うことを忘れないでください。最初のコントローラからのポート上のスイッチの側では、隣接するVLANの循環を許可するため、移動する場合に接続が可能になります。

また、NetApp FAS ストレージは、アルファベット順ではなく、追加された順序でVIFのバランスをとるためにインターフェイス番号を使用することに注意してください。
たとえば、 VIFが「ifgrp create lacp vif1 -b ip e0d e0b e0c e0a」というコマンドによって作成された場合、e0dは0番目のインターフェイス、e0b-1、e0c-2、e0a-3になります。

netApp 7-Modeの解決、エクスポート、およびQtreeセットアップの例

 san01a> rdfile /etc/hosts #Auto-generated by setup Thu may 22 13:26:59 GMT 2014 127.0.0.1 localhost localhost-stack 127.0.10.1 localhost-10 localhost-bsd 127.0.20.1 localhost-20 localhost-sk 10.10.40.10 san01a san01a-e0M 192.168.1.185 san01a san01a-e0P 10.10.53.30 san01a-vif1-53

 san01a> exportfs /vol/vol_filerA_nfsA -sec=sys,rw,nosuid /vol/vol_filerA_nfsB -sec=sys,rw,nosuid /vol/vol_filerA_nfsC -sec=sys,rw,nosuid /vol/vol_filerA_nfsD -sec=sys,rw,nosuid

 san01a> qtree status Volume Tree Style Oplocks Status -------- -------- ----- -------- --------- rootvol unix enabled normal vol_filerA_nfsA unix enabled normal vol_filerA_nfsA qtree_filerA_nfsA unix enabled normal vol_filerA_nfsB unix enabled normal vol_filerA_nfsB qtree_filerA_nfsB unix enabled normal vol_filerA_nfsC unix enabled normal vol_filerA_nfsC qtree_filerA_nfsC unix enabled normal vol_filerA_nfsD unix enabled normal vol_filerA_nfsD qtree_filerA_nfsD unix enabled normal

次のデータストアがVMware ESXiに接続されています

 ds_filerA_nfsA 10.10.53.30:/vol/vol_filerA_nfsA/qtree_filerA_nfsA ds_filerA_nfsB 10.10.53.31:/vol/vol_filerA_nfsB/qtree_filerA_nfsB ds_filerA_nfsC 10.10.53.32:/vol/vol_filerA_nfsC/qtree_filerA_nfsC ds_filerA_nfsD 10.10.53.33:/vol/vol_filerA_nfsD/qtree_filerA_nfsD

構成後、テストVMから負荷を与え、ストレージコントローラー側からポートの負荷を確認します。

7-ModeでNetAppポートの負荷を確認します

 san01a> ifgrp stat vif1 10 Interface group(trunk) vif1 e0b e0a e0c e0d Pkts In Pkts Out Pkts In Pkts Out Pkts In Pkts Out Pkts In Pkts Out 14225k 13673k 15542k 249k 13838k 11690k 15544k 7809k 46075 38052 90911 7 45882 37666 90812 37704 46953 37735 91581 4 46506 37613 91777 37625 46822 38016 91409 7 45498 37589 91670 37687 46906 38046 91514 6 45469 37591 91495 37588 46600 37737 91308 4 46554 37538 91514 37610 46792 37929 91371 7 45803 37532 91261 37508 46845 37831 91228 8 46307 37517 91450 37587

そのため、トラフィックは実質的にe0aインターフェイス（Pkts Out列）を介して送信されないことがわかります。

ストレージコントローラーポートの詳細な出力

 san01a> ifstat -a -- interface e0a (3 hours, 30 minutes, 53 seconds) -- RECEIVE Frames/second: 9147 | Bytes/second: 916k | Errors/minute: 0 Discards/minute: 0 | Total frames: 16347k | Total bytes: 73753m Total errors: 0 | Total discards: 0 | Multi/broadcast: 0 No buffers: 0 | Non-primary u/c: 0 | Tag drop: 0 Vlan tag drop: 0 | Vlan untag drop: 0 | Vlan forwards: 0 Vlan broadcasts: 0 | Vlan unicasts: 0 | CRC errors: 0 Runt frames: 0 | Fragment: 0 | Long frames: 0 Jabber: 0 | Alignment errors: 0 | Bus overruns: 0 Xon: 0 | Xoff: 0 | Jumbo: 8359k TRANSMIT Frames/second: 1 | Bytes/second: 87 | Errors/minute: 0 Discards/minute: 0 | Total frames: 249k | Total bytes: 7674m Total errors: 0 | Total discards: 0 | Multi/broadcast: 1006 Queue overflows: 0 | No buffers: 0 | Max collisions: 0 Single collision: 0 | Multi collisions: 0 | Late collisions: 0 Xon: 0 | Xoff: 0 | Jumbo: 239k LINK_INFO Current state: up | Up to downs: 2 | Speed: 1000m Duplex: full | Flowcontrol: none -- interface e0b (3 hours, 30 minutes, 53 seconds) -- RECEIVE Frames/second: 4678 | Bytes/second: 467k | Errors/minute: 0 Discards/minute: 0 | Total frames: 14637k | Total bytes: 73533m Total errors: 0 | Total discards: 0 | Multi/broadcast: 0 No buffers: 0 | Non-primary u/c: 0 | Tag drop: 0 Vlan tag drop: 0 | Vlan untag drop: 0 | Vlan forwards: 0 Vlan broadcasts: 0 | Vlan unicasts: 0 | CRC errors: 0 Runt frames: 0 | Fragment: 0 | Long frames: 0 Jabber: 0 | Alignment errors: 0 | Bus overruns: 0 Xon: 0 | Xoff: 0 | Jumbo: 8352k TRANSMIT Frames/second: 3773 | Bytes/second: 123m | Errors/minute: 0 Discards/minute: 0 | Total frames: 14007k | Total bytes: 57209m Total errors: 0 | Total discards: 1 | Multi/broadcast: 1531 Queue overflows: 1 | No buffers: 0 | Max collisions: 0 Single collision: 0 | Multi collisions: 0 | Late collisions: 0 Xon: 0 | Xoff: 0 | Jumbo: 2756k LINK_INFO Current state: up | Up to downs: 2 | Speed: 1000m Duplex: full | Flowcontrol: none -- interface e0c (3 hours, 30 minutes, 53 seconds) -- RECEIVE Frames/second: 4630 | Bytes/second: 461k | Errors/minute: 0 Discards/minute: 0 | Total frames: 14243k | Total bytes: 69574m Total errors: 0 | Total discards: 0 | Multi/broadcast: 0 No buffers: 0 | Non-primary u/c: 0 | Tag drop: 0 Vlan tag drop: 0 | Vlan untag drop: 0 | Vlan forwards: 0 Vlan broadcasts: 0 | Vlan unicasts: 0 | CRC errors: 0 Runt frames: 0 | Fragment: 0 | Long frames: 0 Jabber: 0 | Alignment errors: 0 | Bus overruns: 0 Xon: 0 | Xoff: 0 | Jumbo: 7800k TRANSMIT Frames/second: 3756 | Bytes/second: 123m | Errors/minute: 0 Discards/minute: 0 | Total frames: 12022k | Total bytes: 189g Total errors: 0 | Total discards: 0 | Multi/broadcast: 1003 Queue overflows: 0 | No buffers: 0 | Max collisions: 0 Single collision: 0 | Multi collisions: 0 | Late collisions: 0 Xon: 0 | Xoff: 0 | Jumbo: 6283k LINK_INFO Current state: up | Up to downs: 2 | Speed: 1000m Duplex: full | Flowcontrol: none -- interface e0d (3 hours, 30 minutes, 53 seconds) -- RECEIVE Frames/second: 9127 | Bytes/second: 915k | Errors/minute: 0 Discards/minute: 0 | Total frames: 16349k | Total bytes: 73554m Total errors: 0 | Total discards: 0 | Multi/broadcast: 0 No buffers: 0 | Non-primary u/c: 0 | Tag drop: 0 Vlan tag drop: 0 | Vlan untag drop: 0 | Vlan forwards: 0 Vlan broadcasts: 0 | Vlan unicasts: 0 | CRC errors: 0 Runt frames: 0 | Fragment: 0 | Long frames: 0 Jabber: 0 | Alignment errors: 0 | Bus overruns: 0 Xon: 0 | Xoff: 0 | Jumbo: 8339k TRANSMIT Frames/second: 3748 | Bytes/second: 123m | Errors/minute: 0 Discards/minute: 0 | Total frames: 8140k | Total bytes: 62385m Total errors: 0 | Total discards: 0 | Multi/broadcast: 1213 Queue overflows: 0 | No buffers: 0 | Max collisions: 0 Single collision: 0 | Multi collisions: 0 | Late collisions: 0 Xon: 0 | Xoff: 0 | Jumbo: 2413k LINK_INFO Current state: up | Up to downs: 2 | Speed: 1000m Duplex: full | Flowcontrol: none

スイッチ

スイッチの側面に移動し（使用率は80％であり、ほぼ100％ではないため、スイッチは数分間にわたってデータを平均します）、イーサネットポート1/11が実際にフレームを受け入れないことがわかります。

1GBEポートを介してスタック上に2つのCisco Catalyst 3850を設定する例

チャネルグループ1モードのアクティブラインインターフェイス設定の「モードアクティブ 」（ LACP ）に注意してください。 アクティブモード （ LACP ）は、NetAppのDynamic Multi-Modeに対応しています。詳細については、 TR - 3802を参照してください。
また、「 flowcontrol receive on 」に注意してください。このパラメーターの設定は、ポート速度とスイッチタイプなどのいくつかのパラメーターによって異なります。ストアがフロー制御に関するメッセージを「送信」（ flowcontrol send ）する場合、「一方で」スイッチは、フロー制御を「受信」するように構成する必要があります（ flowcontrol receive on ）。フロー制御の詳細。
また、 RSTPまたは独自のRapid ‐ PVST +を有効にし、エンドノードに接続されたスイッチポートをスパニングツリーportfast状態に設定することが望ましい場合、スパニングツリーの構成に関する推奨事項を忘れないでください。
NetApp FASシステムはCDPをサポートしており、オンまたはオフにできます。

 system mtu 9198 ! spanning-tree mode rapid-pvst ! interface Port-channel1 description N1A-1G-e0a-e0b switchport trunk native vlan 1 switchport trunk allowed vlan 53 switchport mode trunk flowcontrol receive on spanning-tree guard loop ! interface Port-channel2 description N1B-1G-e0a-e0b switchport trunk native vlan 1 switchport trunk allowed vlan 53 switchport mode trunk flowcontrol receive on spanning-tree guard loop ! interface GigabitEthernet1/0/1 description NetApp-A-e0a switchport trunk native vlan 1 switchport trunk allowed vlan 53 switchport mode trunk flowcontrol receive on cdp enable channel-group 1 mode active spanning-tree guard loop spanning-tree portfast trunk feature ! interface GigabitEthernet2/0/1 description NetApp-A-e0b switchport trunk native vlan 1 switchport trunk allowed vlan 53 switchport mode trunk flowcontrol receive on cdp enable channel-group 1 mode active spanning-tree guard loop spanning-tree portfast trunk feature ! interface GigabitEthernet1/0/2 description NetApp-B-e0a switchport trunk native vlan 1 switchport trunk allowed vlan 53 switchport mode trunk flowcontrol receive on cdp enable channel-group 2 mode active spanning-tree guard loop spanning-tree portfast trunk feature ! interface GigabitEthernet2/0/2 description NetApp-B-e0b switchport trunk native vlan 1 switchport trunk allowed vlan 53 switchport mode trunk flowcontrol receive on cdp enable channel-group 2 mode active spanning-tree guard loop spanning-tree portfast trunk feature

1GBEポート上にスタックされた2つのCisco Catalyst 6509の設定例

 ! For Cisco IOS Release 12.2(33)SXI and later releases system mtu 9198 ! spanning-tree mode rapid-pvst ! interface Port-channel1 description N1A-1G-e0a-e0b switchport switchport trunk native vlan 1 switchport trunk allowed vlan 53 switchport mode trunk flowcontrol receive on spanning-tree guard loop end ! interface Port-channel2 description N1B-1G-e0a-e0b switchport switchport trunk native vlan 1 switchport trunk allowed vlan 53 switchport mode trunk flowcontrol receive on spanning-tree guard loop end ! interface GigabitEthernet1/0/1 description NetApp-A-e0a switchport switchport trunk native vlan 1 switchport trunk allowed vlan 53 switchport mode trunk flowcontrol receive on cdp enable channel-group 1 mode active spanning-tree guard loop spanning-tree portfast edge trunk end ! interface GigabitEthernet2/0/1 description NetApp-A-e0b switchport switchport trunk native vlan 1 switchport trunk allowed vlan 53 switchport mode trunk flowcontrol receive on cdp enable channel-group 1 mode active spanning-tree guard loop spanning-tree portfast edge trunk end ! interface GigabitEthernet1/0/2 description NetApp-B-e0a switchport switchport trunk native vlan 1 switchport trunk allowed vlan 53 switchport mode trunk flowcontrol receive on cdp enable channel-group 2 mode active spanning-tree guard loop spanning-tree portfast edge trunk end ! interface GigabitEthernet2/0/2 description NetApp-B-e0b switchport switchport trunk native vlan 1 switchport trunk allowed vlan 53 switchport mode trunk flowcontrol receive on cdp enable channel-group 2 mode active spanning-tree guard loop spanning-tree portfast edge trunk end

1GBEポートを介してスタック上に2つのCisco Catalyst 3750を設定する例

チャネルグループ11モードのアクティブラインインターフェイス設定の「モードアクティブ 」（ LACP ）に注意してください。 アクティブモード （ LACP ）は、NetAppのDynamic Multi-Modeに対応しています。詳細については、 TR - 3802を参照してください。
また、「 flowcontrol receive on 」に注意してください。このパラメーターの設定は、ポート速度とスイッチタイプなどのいくつかのパラメーターによって異なります。ストアがフロー制御に関するメッセージを「送信」（ flowcontrol send ）する場合、「一方で」スイッチは、フロー制御を「受信」するように構成する必要があります（ flowcontrol receive on ）。フロー制御の詳細。
また、 RSTPまたは独自のRapid ‐ PVST +を有効にし、エンドノードに接続されたスイッチポートをスパニングツリーportfast状態に設定することが望ましい場合、スパニングツリーの構成に関する推奨事項を忘れないでください。
NetApp FASシステムはCDPをサポートしており、オンまたはオフにできます。

 system mtu 9198 ! spanning-tree mode rapid-pvst ! interface Port-channel11 description NetApp-A-e0a-e0b switchport trunk native vlan 1 switchport trunk allowed vlan 53 switchport mode trunk flowcontrol receive on spanning-tree guard loop spanning-tree portfast trunk feature ! interface Port-channel12 description NetApp-B-e0a-e0b switchport trunk native vlan 1 switchport trunk allowed vlan 53 switchport mode trunk flowcontrol receive on spanning-tree guard loop spanning-tree portfast trunk feature ! interface GigabitEthernet1/0/1 description NetApp-A-e0a switchport trunk encapsulation dot1q switchport trunk native vlan 1 switchport trunk allowed vlan 53 switchport mode trunk flowcontrol receive on cdp enable channel-group 11 mode active spanning-tree guard loop spanning-tree portfast trunk feature ! interface GigabitEthernet2/0/1 description NetApp-A-e0b switchport trunk encapsulation dot1q switchport trunk native vlan 1 switchport trunk allowed vlan 53 switchport mode trunk flowcontrol receive on cdp enable channel-group 11 mode active spanning-tree guard loop spanning-tree portfast trunk feature ! interface GigabitEthernet1/0/2 description NetApp-B-e0a switchport trunk encapsulation dot1q switchport trunk native vlan 1 switchport trunk allowed vlan 53 switchport mode trunk flowcontrol receive on cdp enable channel-group 12 mode active spanning-tree guard loop spanning-tree portfast trunk feature ! interface GigabitEthernet2/0/2 description NetApp-B-e0b switchport trunk encapsulation dot1q switchport trunk native vlan 1 switchport trunk allowed vlan 53 switchport mode trunk flowcontrol receive on cdp enable channel-group 12 mode active spanning-tree guard loop spanning-tree portfast trunk feature

10GBEポート上にスタックされた2つのCisco Small Business SG500の設定例

チャネルグループ1モードのアクティブラインインターフェイス設定の「モードアクティブ 」（ LACP ）に注意してください。 アクティブモード （ LACP ）は、NetAppのDynamic Multi-Modeに対応しています。詳細については、 TR - 3802を参照してください。
また、「 flowcontrol off 」に注意してください。このパラメーターの設定は、ポート速度とスイッチタイプなどのいくつかのパラメーターによって異なります。ストレージがフローを制御するコマンドを「送信せず、受信しない」（ flowcontrol off ）場合、スイッチは「受信も送信もしない」必要があります。フロー制御の詳細。
また、 RSTPを有効にして、エンドノードに接続されているスイッチのスイッチポートをスパニングツリーportfast状態に設定することが望ましいスパニングツリーの構成に関する推奨事項を忘れないでください。

 interface Port-channel1 description N1A-10G-e1a-e1b spanning-tree ddportfast switchport trunk allowed vlan add 53 macro description host !next command is internal. macro auto smartport dynamic_type host flowcontrol off ! interface Port-channel2 description N1B-10G-e1a-e1b spanning-tree ddportfast switchport trunk allowed vlan add 53 macro description host !next command is internal. macro auto smartport dynamic_type host flowcontrol off ! port jumbo-frame ! interface tengigabitethernet1/1/1 description NetApp-A-e1a channel-group 1 mode active flowcontrol off ! interface tengigabitethernet2/1/1 description NetApp-A-e1b channel-group 1 mode active flowcontrol off ! interface tengigabitethernet1/1/2 description NetApp-B-e1a channel-group 2 mode active flowcontrol off ! interface tengigabitethernet2/1/2 description NetApp-B-e1b channel-group 2 mode active flowcontrol off

10GBEポートを介してHP c7000シャーシブレードにHP 6120XGをセットアップする例

設定にフロー制御が表示されない場合、「 flowcontrol auto 」状態になり、スイッチに接続されているストレージポートでフロー制御がオフになっている場合、対応するポートのスイッチで「off」状態になります。。フロー制御の設定はさまざまであり、ポート速度とスイッチタイプなどのいくつかのパラメーターに依存します。ストレージがフローを制御するコマンドを「送信せず、受信しない」（ flowcontrol off ）場合、スイッチは「受信も送信もしない」必要があります。フロー制御の詳細。
また、 RSTPを有効にして、エンドノードに接続されているスイッチのスイッチポートをスパニングツリーportfast状態に設定することが望ましいスパニングツリーの構成に関する推奨事項を忘れないでください。

 # HP 6120XG from HP c7000 10Gb/s trunk 17-18 Trk1 LACP trunk 19-20 Trk2 LACP vlan 201 name "N1AB-10G-e1a-e1b-201" ip address 192.168.201.222 255.255.255.0 tagged Trk1-Trk2 jumbo exit vlan 202 name "N1AB-10G-e1a-e1b-202" tagged Trk1-Trk2 no ip address jumbo exit spanning-tree force-version rstp-operation

ステータスとカウンター-ポート使用率

  Rx Tx Port Mode | ------------------------- | ------------------------- | Kbits/sec Pkts/sec Util | Kbits/sec Pkts/sec Util ------- --------- + ---------- --------- ---- + ---------- ---------- ---  1/11-Trk10 1000FDx| 5000 0 00.50 | 23088 7591 02.30 1/12-Trk10 1000FDx| 814232 12453 81.42 | 19576 3979 01.95 2/11-Trk10 1000FDx| 810920 12276 81.09 | 20528 3938 02.05 2/12-Trk10 1000FDx| 811232 12280 81.12 | 23024 7596 02.30  1/17-Trk22 1000FDx| 23000 7594 02.30 | 810848 12275 81.08 1/18-Trk22 1000FDx| 23072 7592 02.30 | 410320 6242 41.03 2/17-Trk22 1000FDx| 19504 3982 01.95 | 408952 6235 40.89 2/18-Trk22 1000FDx| 20544 3940 02.05 | 811184 12281 81.11

[Rx Util]列のコントローラーの受信負荷（Rx）と[Tx Util]列のサーバーの送信負荷（Tx）が表示されます。 2つのデータストアが1つのコントローラーリンクを共有していることがわかります。

4つのVMすべて、およびそれに応じて4つのNFSボールで線形記録の生成を開始するとき、トラフィックバランシングはストレージシステムに依存しないため、状況が予想されます。

IP選択

IPバランシングを使用してチャネルを集約するときのストレージシステムは、理論上は使用可能なすべての回線を使用するわけではなく、4つのうち3つしか使用しないことがわかります。同時に、他のすべての参加者（スイッチおよびESXi）は、4行すべてで正しくバランスを取ります。ストレージからスイッチへの2つのデータストアのトラフィックは1つのリンクを通り、2つのスイッチからESXiに既に行きます。
iSCSIプロトコルで作業しているときに、同様の状況が観察されます。発信通信用のストレージシステムの 4つのリンクの1つは、実際にはロードされていません（10秒で5〜10パケット）。 2番目のコントローラーと別のサーバーでも、状況は似ています。

なぜこれが起こっているのですか？はい。2つのIPペアの合計のハッシュが一致するため、アルゴリズムは同じリンクを選択する必要があります。つまり、他のIPを取得するだけです。

IPオプションを単純に繰り返すことができます。 IPアドレスを選択するためのプログラムを作成する際の大きな難点は、アルゴリズムが符号付き32ビット整数のビット単位のシフトとそれらの加算操作を使用することです（オーバーフローは破棄されます）。スクリプト言語は固定ビット数に弱く指向されているため、Pythonで通常の計算を行うことはできませんでした。したがって、範囲全体の小さな計算プログラムがCで記述され、その結果を検索に使用します。

SuperFastHashアルゴリズム

Data ONTAP 7.3.2以降では、パスの選択は、2つの送信元および宛先IPアドレス（（source_address XOR destination_address）％number_of_links）に対するXOR操作だけではありません。 SuperFastHashと呼ばれるより複雑なビットシフトアルゴリズムは、より動的でバランスのとれた負荷分散の方法を表し、多数のクライアントにより優れた分散を提供します。結果はほぼ同じですが、各TCPセッションは1つのインターフェイスにのみ関連付けられています。

アレクサンダー・ゴルディエンコによるコーディング

 #include <stdio.h> int debug = 0; void f_shiftL(int *r, int step, int i, int offset) { r[step] = r[i] << offset; if (debug > 0) { printf("\nStep %i Left Shift %i %i\n", step, i, offset); printf("\t%i << %i\n", r[i], offset); printf("\t%i\n", r[step]); } } void f_shiftR(int *r, int step, int i, int offset) { r[step] = r[i] >> offset; if (debug > 0) { printf("\nStep %i Right Shift %i %i\n", step, i, offset); printf("\t%i\n", r[i]); printf("\t%i\n", r[step]); } } void f_xor(int *r, int step, int i, int j) { r[step] = r[i] ^ r[j]; if (debug > 0) { printf("\nStep %i XOR %i %i\n", step, i, j); printf("\t%i\n", r[i]); printf("\t%i\n", r[j]); printf("\t%i\n", r[step]); } } void f_sum(int *r, int step, int i, int j) { r[step] = r[i] + r[j]; if (debug > 0) { printf("\nStep %i ADD %i %i\n", step, i, j); printf("\t%i\n", r[i]); printf("\t%i\n", r[j]); printf("\t%i\n", r[step]); } } int balance_ip_netapp (int net, int src, int dst, int link_cnt) { int res[30]; res[0] = net*256 + src; res[1] = net*256 + dst; //printf ("a = %i.%i (%i)\n", net, src, res[0]); //printf ("b = %i.%i (%i)\n", net, dst, res[1]); f_shiftL(res, 2, 1,11); f_xor (res, 3, 0, 2); f_shiftL(res, 4, 0,16); f_xor (res, 5, 3, 4); f_shiftR(res, 6, 5,11); f_sum (res, 7, 5, 6); f_shiftL(res,15, 7, 3); f_xor (res,16, 7,15); f_shiftR(res,17,16, 5); f_sum (res,18,16,17); f_shiftL(res,19,18, 4); f_xor (res,20,18,19); f_shiftR(res,21,20,17); f_sum (res,22,20,21); f_shiftL(res,23,22,25); f_xor (res,24,22,23); f_shiftR(res,25,24, 6); f_sum (res,26,24,25); res[27] = res[26] % link_cnt; if (res[27] < 0) { res[27] = res[27] + link_cnt; } printf ("%i.%i -> %i, %i\n", net, src, dst, res[27]); return 0; } int main() { int src, dst, interface; //    interface = 4; printf ("IP Octet3.IP Octet4 Source -> IP Octet4 Destination, Interface\n"); //  destination    IP  (   21  23) for (src=21; src<=23; src++) { //  source    IP  (   30  250) for (dst=30; dst<=250; dst++) { //   IP  (  52  53) balance_ip_netapp(52, dst, src, interface ); balance_ip_netapp(53, dst, src, interface ); } } }

ところで、すぐに結果を得るには、オンラインコンパイラを使用するのが非常に便利です。

以下は、3つのサーバー（IPアドレスの末尾が21、22、23、ストレージシステムへのインターフェイス数がそれぞれ3、4、4）がある場合の、ストレージ IPアドレスの選択オプションです。
計算は、2つのネットワークXX.YY.52.ZZ / 24およびXX.YY.53.ZZ / 24に対して行われました。上記の条件を満たすストレージ用に選択されたIPアドレス。

タブレットの使用方法

IP XX.YY.52.22 IPとストレージエイリアスXX.YY.52.35のサーバー間でトラフィックを交換する場合、トラフィックは次のようになります。
ストレージからスイッチへのストレージ（列NetApp Out、22）は、スイッチからストレージへのストレージに番号を付けることにより、番号2のインターフェースを通過します（コラムNetApp In、22）は、スイッチからサーバーへ、およびサーバーからスイッチへのスイッチの番号により、番号1のインターフェースを通過しますServer InOutカラム、22）は、それぞれサーバーとポート番号のポート1に移動します（同じと見なすという事実ではありません）

各サーバーについて、同じコントローラー上の異なるエイリアスを持つトラフィックが異なるインターフェースを通過することがわかります。同様に、異なるサーバーから1つのIP ストレージへのトラフィックは、異なるインターフェースを通過します。

執筆時には、Alexander Gordienkoの資料、 Link Aggregation、およびNetAppによるIPトラフィックバランシングが使用されました。

C ++の記事とアルゴリズムの更新バージョン。

テキストのエラーに関するコメントをLANに送ってください。

ストレージのリンクアグリゲーションとIPトラフィックバランシング

More articles: