IWAN パート 4:IWAN ネットワークでのロード シェアリングおよびロード バランシング(Dmytro Muzychko)

    本ページは英語ドキュメントを翻訳したものです。

     


     

     IWAN パート 4:IWAN ネットワークでのロード シェアリングおよびロード バランシング(Dmytro Muzychko)

    お客様がネットワークに IWAN を選択する一番の理由は、使用可能なすべての WAN パスをインテリジェントに使用できるからです。PfRv3 で異なるアウトバウンド パスの負荷を分散する最もシンプルで一般的な方法は、明示的に指定された各トラフィック クラスの優先パスとフォールバック パスをさまざまに組み合わせることです。

     

    PfRv3 では、優先パス、フォールバック パス、およびネクストフォールバック パスを設定できます。これらの各設定では、最大 3 つの異なるパスを指定できます。さらに理解を深めるために、設定について説明します。

     

     

    path-preference Path1 Path2 Path3 fallback Path4 Path5 Path6 next-fallback Path7 Path8 Path9

     

    次の例を見ていきましょう。図 1 を参照してください。

    Blog41-figure+1.png

    図 1.

     

    容量の違う 2 つの MPLS 回線(MC/BR1 および BR2)、1 つの信頼性の高いインターネット接続(BR3)、および 1 つの信頼性の低い(Wi-Fi または LTE)インターネット接続(BR4)を持つブランチがあるとします。お客様は、通常、ミッション クリティカルなトラフィックを MPLS で送信し、優先順位の低いトラフィックをインターネットで送信したいと考えています。MPLS 回線は同じプロバイダーのものであるため、通常は遅延/ジッター/損失に関する SLA は同じになります。したがって、容量が違うとしても、ミッション クリティカルなトラフィックにどの MPLS 回線を選択するかは重要ではありません。お客様は、両方の回線を理論上均等に利用することを望んでいます。優先順位の低いトラフィックについては、信頼性の高いインターネット リンクの利用を希望しています。信頼性の低いインターネット接続は、他のすべてのリンクに障害が発生しているかサービスが低下している(PfRv3 ではポリシー違反(OOP)と呼ばれる)場合にのみ使用します。

     

    これらの要件に基づいて、ネットワーク設計者は、優先として MPLS パスの両方を、フォールバックとして信頼性の高いインターネット パスを、ネクストフォールバックとして信頼性の低いインターネット パスを指定することによって、ミッション クリティカルなトラフィックの PfRv3 ポリシーを定義します。優先度の低いトラフィックでは、優先パスとフォールバック パスが入れ替わります。しかし PfRv3 では、容量の異なる 2 つの使用可能な MLPS パスで、ミッション クリティカルなトラフィックの送信をどのように管理するのでしょうか。

     

    通常のルーティングでは、複数のネクストホップを経由するトラフィックの送信は、ほとんどのルーティング プロトコルでサポートされている等コスト マルチパス(ECMP)の方法か、EIGRP および BGP でサポートされている不等コストの方法によって実行されます。このブログで使用されるロードシェアリングとロードバランシングという用語は、ほとんど同じ意味で使用されます。シスコ ルータでは、この機能は CEF によって実行されます。方法の 1 つとしてパケット単位のロードバランシングがありますが、これはパケットの順序が入れ替わるリスクが生じます。ほとんどのシスコ プラットフォームでは、CEF はデフォルトで送信元および宛先 IP ハッシュに基づいてアルゴリズムを実行します。そのため、CEF がロードシェアリングに使用するデフォルトの単位は IP アドレス ペア間のメッセージ交換です。TCP/UDP セッションでさえも区別できるように、レイヤ 4 の情報を使用するようルータを設定することができます。重要なのは、PfRv3 はこのように詳細なレベルでは機能しないことを理解することです。PfRv3 が使用する最小単位はトラフィッククラス(TC)(宛先プレフィックスと DSCP マーキングの組み合わせ)です。つまり、TC は特定の DSCP 値でマークされたすべてのトラフィックを集約して、PfRv3 によって学習されたプレフィックス内の送信元から宛先に送信します。

     

    それでは、例を見てみましょう。ミッション クリティカルなトラフィックの TC が PfRv3 によって検出されると、ハッシュ関数が実行されますが、リンクの使用率も示されます。PfRv3 は計算を実行して、パーセンテージに基づいて帯域幅の使用率を同等にしようとします。そのため、容量が等しくないリンクに均等に負荷がかけられます。このプロセスは、PfRv3 でロードシェアリングと呼ばれ、デフォルトでは有効になっています。

     

    PfRv3 のロードシェアリングは継続的なプロセスではないという点に注意してくだい。TC は使用可能なパスの 1 つに割り当てられると、パスが到達不能または OOP になるまでそこにとどまります。図 2 を参照してください。

     

    Blog41-figure+2.png

    図 2.

     

    多数の TC がロードシェアリングされているが、しばらくした後にネットワーク通信が 20Mbps リンクで送信される TC に対して終了することがあります。そのため、TC 1、4、6 は最終的に PfRv3 から削除されます。この場合、10Mbps リンクでルーティングされる残りの TC 2、3、5 はそのリンクにそのまま残り、新しい TC(存在する場合)のみが空いているパスに割り当てられます。

     

    もう 1 つ重要な考慮事項があります。2 つの MPLS リンクの間にロードシェアリングされている多数の TC があるとします。図 3 に示すように、リンクの 1 つが突然ダウンすると、すべての TC が残りの機能している MPLS パスに移されます。

    Blog41-figure+3.png

    図 3.

     

    障害が発生したリンクが復元されたとき、TC 1、4、6 は今までどおりポリシーを満たしているため 2 番目の MPLS リンクに残ります(両方の MPLS リンクが優先として指定されている場合)。また、新しい TC(存在する場合)のみが空いているパスに割り当てられます。

     

    次の疑問は、PfRv3 ポリシーで明示的に指定されていないトラフィックはどうなるのかということです。このトラフィックこそが、PfRv3 ロードバランシングの対象となるのです。この機能は、デフォルトでは無効になっています。有効になっている場合、ポリシーが設定されていないと検出されたトラフィッククラスは MPLS およびインターネットを含む使用可能なすべてのパスでロードバランシングされます。ただし、ロードバランシングを必須パスのリストに制限して、信頼性の低いインターネット接続をリストから除外することが可能です。図 4 を参照してください。

    Blog41-figure+4.png

    図 4.

     

    TC 10 ~ 15 はポリシーが定義されていないため、ロードバランシングされます。PfRv3 のロードバランシングの最大の利点は、継続的なプロセスであるということです。この機能では、各パスの使用率を追跡して、リンクの帯域幅使用率の差が事前に定義したしきい値(デフォルトでは 20%)を超えないようにトラフィックのバランスを取ります。しきい値を超えると、ロードバランシング プロセスによって負荷の高いリンクから負荷の低いリンクにトラフィッククラスが移されます。たとえば、TC 13 は最終的に信頼性の高いインターネット パスに移されます。さらに、PfRv3 はパーセント単位で測定されたリンク使用率を使用するため、容量に応じてすべてのリンクに均等にトラフィックの負荷がかけられます。

     

    まとめ

    PfRv3 はトラフィッククラスのみを使用するため、ロードシェアリンクおよびロードバランシングで必要な粒度を実現するには、可能な場合はサイト プレフィックスの長さを調整したり、より大きい DSCP 値を使用する必要がある場合があります。

     

    最後に、設計要件に基づいて、IWAN ルーティングを使用するネットワークで、すべての信頼性の高いリンクに均等に負荷をかけ、信頼性の低い接続を最後の手段としてのみ保持することができます。異なるパスへのトラフィックの分散は、手動による実行(異なる TC の優先/フォールバック/ネクストフォールバック パス)、ロードシェアリング、およびロードバランシングによって同時に実現できます。すべての機能は相互に適切に連動し、ロードシェアリングのいくつかの制限でさえロードバランシングの自動調整によって補完できます。このブログで IWAN 設計シリーズは終了です。このシリーズが IWAN および PfRv3 の概念の理解に役立つことを期待しています。

     

    著者について

    pic Dmytro Muzychko.pngDmytro(Dima) Muzychko は、Verizon 社の主席設計エンジニアで、主に規格外の顧客要件を扱っています。サービス プロバイダーのネットワーキングに関する経験があり、特にルーティング スイッチングや仮想化、最近では SD-WAN に重点を置いています。Dima のプロフェッショナルとしての言葉を引用します。「問題を解決するにはインテリジェンスが必要だが、問題を起こさないためには知恵が必要だ。ネットワーク設計という作業は、まさに後者そのものだ」。

    Dima は現在、Routing & Switching の CCIE と CCDE を保有し、コンピュータ テクノロジーの修士号を取得しています。

     

     

    次の方法で、このテーマについてさらに学んだり情報を交換したりすることができます。

    CLNBanner