標準vSwitchがスパニングツリープロトコルを必要としない理由

今日、vSphere 5の熱から少し注意をそらして、標準vSwitchの基本、特にスパニングツリープロトコルなしでどのように機能するかを思い出したいと思います。



スイッチングの最も簡単な知識をすでにお持ちで、VLAN、スイッチングループ、スパニングツリープロトコル、およびいくつかのタイプのリンクアグリゲーションプロトコルが何であるかを知っていると思います。 標準vSwitchの主な機能について簡単に説明します。少なくとも、私にとっては興味深いと思われる、または公式ドキュメントではあまり明らかではない事実に焦点を当てます。 これは、以下の混乱も意味します。



標準vSwitch(またはvNetworking Standard Switch別名vSS)の主な目標は、仮想マシンと物理ネットワークインフラストラクチャ間の通信を提供することです。 さらに、ポートグループを使用して仮想マシンを論理的に分離し、1つのESXiホストに複数のアップリンクがある場合にさまざまなバランシングアルゴリズムを提供し、仮想マシンからvSSへの発信トラフィックシェーピングを提供し、最後にアップリンク障害を検出できますトラフィックを残りのアップリンクに自動的に切り替えます。







それでは、物理スイッチとの主な違いは何ですか?



物理スイッチとは異なり、vSSは同じブロードキャストドメイン内のすべてのデバイスのMACアドレスを学習する必要はありません。 すべての仮想マシンにはESXiによって割り当てられたMACアドレスがあるため、vSSはすべてのデフォルトアドレスをすでに知っています。 もう1つの特徴的な機能は、vSSがポートを内部ポートとアップリンクの2つのタイプに明確に分割し、異なるスイッチングルールを適用することです。



ポートグループとVLAN



ポートグループは、内部ポートの構成テンプレート(VLAN番号、シェーピング、トラフィックバランシングなど)を定義します。 仮想マシンをvSSに接続するときに、使用するポートグループを指定するだけで、事前定義された設定が適用されます。 たとえば、特定のポートグループの仮想マシンについて、特定のインターフェースのみをアップリンクとして使用し、残りのインターフェースをバックアップとして使用するように指定できます。 もう1つの良い例は、仮想マシンでMSネットワーク負荷分散クラスターをユニキャストモードで構成する場合です。 この場合、これらの仮想マシン用に個別のポートグループを作成し、それらの仮想マシンで[スイッチに通知]オプションを無効にする必要があります。



非常に頻繁に、ポートグループは物理スイッチ上のVLANと比較されますが、これは実際には完全に間違った比較です。 これは、ほとんどの場合、vSphere管理者がポートグループを使用して仮想マシンを異なるVLANに分割しているためだと思います。 ただし、常にそれらから直接の対応があります。 MSネットワーク負荷分散に関する前述の例は、この優れた証拠です。vSphereには、MSネットワーク負荷分散サーバー用と他のサーバー用の2つのポートグループがあります。 同時に、両方のポートグループの仮想マシンは同じVLANに属します。

さて、ポートグループとVlanのもう1つの違いはこれから続きます。 異なるvlan-ahのコンピューターは直接通信できません。 トラフィックをルーティングするにはL3デバイスが必要か、vlan-s間のブリッジを有効にする必要がありますが、ユニキャストトラフィックはポートグループ間で自由に送信できます。



私にとって大きな驚きは、昨日vlan 4095がオープンしたこと、またはvSS上のすべてのトラフィックを完全にリッスンできることでした。 原則として、公式ドキュメントではVMware vlan 4095はVGT-仮想ゲストvlanタギングとして示されています。 これにより、vlanタグを仮想マシン自体に転送して、このトラフィックをどう処理するかを決定できるようになります。 実際には、これはあまり使用されません。vSSがvlanタグを削除し、対応するポートグループにトラフィックを送信する場合、VST(仮想スイッチvlanタギング)がより頻繁に使用されます。 VGTはまったく使用していませんので、簡単に読みました。 ポートグループを作成してvlan 4095を割り当て、このポートグループでプロミスシャスモードを有効にしてから仮想マシンを配置すると、wiresharkを解凍し、このvSSに接続されているすべてのマシンからトラフィックを静かに収集して分析できることがわかります。 別の有用な実用的なアプリケーションは、トラフィック検査の目的でこのようなポートグループに仮想IDSを配置することです。



アップリンク-トラフィックバランシング



vSphere 4.1では、単一の仮想スイッチで最大32個のアップリンクを使用できます。 アップリンクは1つのvSSでのみ使用できます。つまり、同じアップリンクを別のvSSで使用することはできません。 また、トラフィックが1つのvSSから別のvSSに直接送信されることはありません。 それらの間のトラフィックは、L3デバイスへのアップリンクか、L3デバイスとして機能する仮想マシンへの内部仮想ポートを経由する必要があります。



99%の状況では、ESXiホストに複数のアップリンクがあり、2つ以上のアップリンクにトラフィックを分散する方法を決定する必要があります。 デフォルトでは、これらのルールはvSSに適用されますが、必要に応じて特定のポートグループでも変更できます。



vSSには3つの主要なトラフィックバランシングポリシーがあります。



最も一般的なトラフィック分散シナリオの1つは、スパニングツリープロトコルを使用する物理スイッチで使用されるシナリオと非常によく似ています。異なるVLANが異なるアップリンクに移動し、アップリンクの1つがこれらのVLANのすべてのトラフィックを「ドロップ」するまで、 s残りのアップリンクに切り替えます。 同様に、ESXiでは、同じvSSに2つのポートグループを作成します。 最初のポートグループについては、最初のアップリンクがアクティブ、2番目がバックアップとして示されます。 2番目のポートグループは、まったく逆に構成されます。 したがって、物理スイッチへの帯域幅のより効率的な使用を実現し、同時に冗長性を失うことはありません。



vSphere管理者は、vMotionまたはFTトラフィックにのみ個別のアップリンクペアを割り当てることがありますが、これは非常にまれなケースですが、vMotionまたはFTトラフィックは複数のインターフェイスに分散されているため、インターフェイスの無駄です。 ほとんどの場合、インターフェイスの1つは単純にアイドル状態になります。



発信シェーピング

vSSを使用する場合、仮想マシンからvSSへの発信トラフィックのみをシェーピングできます。 たとえば、原則として、これはvMotionトラフィックを形成するのに十分です。 しかし、残念ながら、物理マシンからの着信トラフィックをシェーピングすることはできません。



それでは、なぜvSSはスパニングツリープロトコルを必要としないのですか?





これはすべて、vSSと物理スイッチの間に多くのアップリンクを使用できることを基本的に証明していますが、トラブルシューティングが困難なスパニングツリープロトコルは必要ありません。



同志Ivan Pepelnjakの素晴らしいブログとVMwareの公式ドキュメントからほとんどの情報をまとめました。



All Articles