2つのデータセンター間の低速ネットワークノードを見つける

Question

パブリックインターネットの低速リンクを経由している場合には、強制的に迂回するしか選択肢はありません。これを行う最も簡単な方法は、2つのエンドポイント間でファイル転送を試みることです。1つは「ポイントA」（データの発信元）で、もう1つは「ポイントA」です。中間サイト目的地である「ポイント B」と地理的に同じ場所ではありません。

「ポイントC」を見つけたら、それはない低速のインターネットルーターを経由してルーティングされないようにするには、ポイント A とポイント C の間に VPN を設定し、トラフィックが低速ノードを「迂回」するようにします。

ビジネス価値 ($$$$$$) が高い場合や ISP に対する影響力がある場合は、Level 3 に直接問題を提起することもできます。ただし、L3 は Tier 1 ISP であり、サービス品質やネットワークの飽和に関する苦情に特に耳を傾けない可能性があります。これは、ノード上で競合を引き起こしているダウンストリームプロバイダーや他の Tier 1 プロバイダーとのピアリング契約を拡大できない、拡大しない、または拡大できない場合、L3 にできることはほとんどないからです。

「オフィスからサーバー」へのリンクの方が高速だとおっしゃっているので、適度に高性能なコンピューター (デュアルコアサーバーグレードのシステムで十分でしょう) を使用して「オフィス」サイトで VPN を設定してみるのもよいでしょう。

ああ、また！「ポイントA」と「ポイントB」間の遅延（エンドツーエンド）が非常に高い場合（サーバーの世界では100ミリ秒を超えると高い）、次のことを確認する必要があります。チャットネットワークプロトコルを使用していないSamba（SMBまたはWindowsファイル共有とも呼ばれる）は非常にチャッティ。他の「同期」プロトコルもチャッティになる可能性があります。

チャッティプロトコルとは、データを転送するために、同期した「往復」の往復を何度も必要とするプロトコルです。プロトコルのチャッティが高すぎると、リンクの速度に関係なく、遅延だけで転送がボトルネックになる可能性があります。

チャットがスループットに本当に影響しているかどうかを判断するには、既知の口数が少ないテスト転送にはHTTPなどのプロトコルを使用します。したがって、「遅い」Level3ルーターを介して「ポイントA」から「ポイントB」への通常のHTTPを試し、遅延は大きいがスループットがまだ良好であれば、知る転送が遅い理由はプロトコルが多すぎるためであり、プロトコルを変更する必要があります。

それでは、簡単に定義して説明して議論を締めくくりたいと思います。3つのネットワーク障害なぜ誰でもこの問題の原因は、次のとおりです。

レイテンシー-- データグラムが自分の側から相手側の側に届くまでにかかる時間。ほとんどの場合、コンピュータの 1 つが過負荷になり、ネットワークスタック、カーネル、またはアプリケーションが大幅な遅延を発生させている場合を除き、遅延を直接改善することはできません。パブリックインターネット上の遅延のほとんどは、自分のコンピュータやエンドポイントではなく、インターネットルーターから発生します。
帯域幅-- 帯域幅は、コンピュータとエンドポイント間の最も遅いリンクの最大スループットです。ほとんどの最新ネットワークでは、帯域幅が実際の問題になるずっと前に、他のネットワーク障害が発生してネットワークの速度が低下するため、帯域幅は実際の制限ではありません。
パケットロス-- パケット損失が増加する可能性がある認識された遅延は、信頼性の高いデータグラム (TCP など) の遅延であり、多くの場合、TCP 送信または受信バッファがすでにいっぱいになっているために、リンクが飽和状態にあるためにパケットを TCP 送信または受信バッファからドロップしなければならない結果です。また、パケット損失は、ほとんどすべての TCP パケットの場合と同様に、「時間に敏感な」パケットで発生する可能性があります。これは、パケットが期限後に到着すると破棄されるためです。これは、大きな TCP パケットが複数の IP データグラムに断片化され、受信側の TCP プロトコルが、パケットの受信を中止する前に、すべてのフラグメントが到着するまで一定時間しか待機できない場合に発生します。したがって、パケット損失は、飽和 (は帯域幅の問題、またはハードウェアの問題や障害によっても発生する可能性があります。

基本的なネットワーク障害から派生した緩和策は、基本的な障害を変更することなくプログラムの信頼性を向上させるために実行できます。ほとんどの場合、それらを制御するためにできることはほとんどないか、まったくないためです。

緩和策の1つは、プロトコルをあまりチャティにしないことです（または、システム統合の観点から言えば、使用既存のプロトコルで、現在のソリューションよりも通信量が少ないもの) を推奨します。エンドポイント間でデータを同期するために必要な「往復」回数が少ないほど、状況は良くなります。一部のプロトコルは、同期の頻度を可変にするよう設計できます。この場合、遅延やパケット損失が大きいことが検出されたら、同期頻度を動的に可能な限り減らす必要があります。通信量を減らすと、遅延やパケット損失が軽減されますが、帯域幅の上限の問題は軽減されません。

2つ目の緩和策は、すべてのホップ（管理レベルまたはハードウェアレベルで直接制御するもの）を、現在利用可能な最良のアクティブキュー管理（AQM）アルゴリズム（現在はフェアキュー制御遅延AQM）を使用するように構成することです。これは、Linuxカーネル3.5以降でfq_codelqdisc実装として利用可能であり、動的に減らす送信バッファと受信バッファのサイズを変更して、これらのバッファが必ず生成する遅延を削減します。これにより、パケット損失が削減され、TCP プロトコルを使用した遅延に対処するのに役立ちます。これは、パケットがリンク経由で送信される前に待機する時間を最小限に抑えると、断片化されたパケットが期限切れになる可能性が低くなるためです。この緩和策は、ノードが「飽和」している場合にのみ効果があります (つまり、TCP バッファが空の場合は効果がありません)。ネットワークソケットへのデータ書き込み速度がアップリンクの送信速度を超えると、ノードは飽和します。この状況に対する TCP スタックの一般的な応答は、バッファを大きくすることですが、これは実際には悪影響を及ぼします。遅延が増大し、さまざまな問題が発生するためです。そのため、fq_codel はこれを緩和するのに役立ちます。

これらの緩和策は、3つの基本的なネットワーク障害すべてに役立ちます。それなし障害のあるノードを迂回してルーティングし、それなしハードウェアを変更したり、ISP に連絡したりしないでください。

Answer 1