2つのデータセンター間の低速ネットワークノードを見つける
2つのデータセンター間で大量のデータを同期する際に問題が発生しました。両方のマシンはギガビット接続を備えており、完全には占有されていませんが、私が取得できる最速は6〜10メガビット=>許容できません！
昨日、LEVEL3ルーターに大きな負荷がかかっていることを示すtracerouteを作成しましたが、問題は数週間存在し、高い応答時間はなくなりました（300msではなく20ms）。
これをトレースして実際の遅いノードを見つけるにはどうすればよいですか？より大きなパッケージのtracerouteについて考えましたが、これは機能しますか？
さらに、他のサーバーまたはクライアントへの伝送速度がはるかに高いため、この問題はサーバーの1つに関連していない可能性があります。実際、office => serverはserver <=> serverよりも高速です！
どんなアイデアでも大歓迎です;）
更新
実際には、sshを介してrsyncを使用してファイルをコピーしています。暗号化にはボトルネックが増える傾向があるため、HTTPリクエストを試しましたが、残念ながら同じくらい遅いです。
データセンターの1つにSLAがあります。これは、トラフィックがルーティングされる安価なネットワークに関連しているため、ルーティングを変更しようとしたとのことです。確かにそれは「安いネット」を経由しますが、その逆です。私たちの方向はLEVEL3を経由し、反対の方向はラムダネットを経由します（彼らは良いネットワークではないと彼らは言いました）。 ）彼らは、LEVEL3を介したルーティングを強制するために、より長いパスをシミュレートし、ASパスでLEVEL3をアナウンスします。
私は基本的に彼らが正しいのか、それとも彼らが彼らの責任を放棄しようとしているのかを知りたいのです。問題は両方向に存在するということです（ルートは異なりますが）ので、それは私たちのホスティング業者の責任だと思います。そして正直なところ、600kb/s（1.5 MB/s）しか処理できないDC2DC接続が数週間あるとは思いません！問題は、このボトルネックがどこにあるかをどのように検出するかです。
パブリックインターネット上の低速リンクを介してルーティングされている場合、ほとんどの場合、唯一の選択肢は、強制的にその周りをルーティングすることです。これを行う最も簡単な方法は、2つのエンドポイント間でファイル転送を試みることです。そのうちの1つは、「ポイントA」（データの発信元）と、地理的に離れた中間サイトです。目的地「ポイントB」と同じ場所にあります。
直面している低速のインターネットルーターを介して not ルーティングされないサーバーである「ポイントC」を見つけたら、ポイントAとポイントCの間にVPNを設定できます。 、トラフィックが低速ノードを「ルーティング」するようにします。
ビジネス価値が高い（$$$$$$）か、ISPに影響力がある場合は、レベル3で直接問題を取り上げることもできます。ただし、L3はTier 1 ISPであり、サービスに関する苦情を特に受け入れない可能性があります。品質またはネットワークの飽和。ノードで競合を引き起こしているダウンストリームまたは他のTier1プロバイダーとのピアリング契約を拡張できない、できない、または拡張できない場合、これについてできることはほとんどないためです。
「オフィスからサーバーへ」のリンクの方が速いとおっしゃっていたので、適度に強力なコンピューターを使用して「オフィス」サイトでVPNをセットアップしてみてください（デュアルコアサーバーグレードシステムで十分です）。
ああ、また！「ポイントA」と「ポイントB」の間の遅延（エンドツーエンド）が非常に高い場合（サーバーの世界では100ミリ秒を超える場合）、次のことを確認する必要があります。 おしゃべりなネットワークプロトコルを使用していません。 Samba（SMBまたはWindowsファイル共有とも呼ばれます）は非常におしゃべりです。他の「同期」プロトコルもおしゃべりかもしれません。
おしゃべりなプロトコルは、データを転送するために多くの同期「往復」ラウンドトリップを必要とするプロトコルです。プロトコルがおしゃべりすぎると、リンクの速度に関係なく、遅延だけで転送のボトルネックになる可能性があります。
おしゃべりが実際にスループットに影響を与えているかどうかを判断するためにできることの1つは、テスト転送にHTTPなどの既知の un-chatty プロトコルを使用することです。したがって、「遅い」レベル3ルーターを介して「ポイントA」から「ポイントB」までの通常の古いHTTPを試してください。レイテンシーは高いがスループットは良好である場合は、知っている転送が遅い理由は、プロトコルがおしゃべりすぎるため、プロトコルを変更する必要があるためです。
それでは、簡単に定義して説明することで、議論を締めくくりましょうつのネットワーク障害そしてなぜそれらのいずれかがこの問題の原因となる可能性があります：
レイテンシ-データグラムが自分の端からもう一方の端に到達するまでにかかる時間。ほとんどの場合、コンピュータの1つが過負荷になり、そのネットワークスタック、カーネル、またはアプリケーションが大幅な追加の遅延を生成しない限り、遅延を直接改善することはできません。パブリックインターネットでのほとんどの遅延は、コンピューターやエンドポイントではなく、インターネットルーターから発生します。
帯域幅-帯域幅は、コンピューターとエンドポイント間の最も遅いリンクの最大スループットです。最近のほとんどのネットワークでは、帯域幅が実際の問題になるずっと前に、他のネットワーク障害が発生してネットワークの速度が低下するため、帯域幅は実際の制限ではありません。
パケット損失-パケット損失は増加する可能性があります知覚信頼できるデータグラム（TCPなど）の遅延であり、多くの場合、非常に飽和したリンクがパケットをパケットからドロップしなければならない結果です。 TCPバッファがすでにいっぱいになっているため、送信または受信バッファ。また、ほとんどすべてのTCPパケット。これは、パケットが期限後に到着した場合、破棄されるためです。これは、より大きなTCPパケットが複数のIPデータグラムにフラグメント化され、TCPプロトコルは、パケットの受信を中止することを決定する前に、すべてのフラグメントが到着するまで一定時間しか待機できません。したがって、パケット損失は、飽和の問題から間接的に派生します（これはis帯域幅の問題）、またはハードウェアの問題や障害から。
基本的なネットワーク障害から派生したのは、基本的な障害を変更せずにプログラムの信頼性を向上させるために実行できる緩和策です。ほとんどの場合、プログラムを制御するためにできることはほとんどまたはまったくないためです。
緩和策の1つは、プロトコルのおしゃべりを少なくすることです（または、システム統合の観点から、 use 現在のソリューションよりもおしゃべりが少ない既存のプロトコルを使用します）。エンドポイント間でデータを同期するために必要な「ラウンドトリップ」が少ないほど、より良い期間になります。一部のプロトコルは、可変周波数の同期を要求するように設計できます。この場合、高遅延またはパケット損失を検出した場合は、同期周波数を可能な限り動的にバックオフする必要があります。おしゃべりを減らすことは、遅延とパケット損失を軽減するのに役立ちますが、帯域幅の上限の問題は軽減しません。
緩和策2は、すべてのホップ（管理/ハードウェアレベルで直接制御するホップ）を構成して、利用可能な最良のアクティブキュー管理（AQM）アルゴリズム（現在は均等化キュー制御遅延AQM）を使用することです。これは、Linuxカーネル3.5以降でfq_codel qdisc実装として利用可能であり、動的に実行されますreduces遅延を減らすために、送信バッファーと受信バッファーのサイズこれらのバッファは常に生成します。これにより、パケット損失を減らし、TCPプロトコルを使用して遅延に対処するのに役立ちます。これは、パケットが通過するまでの待機時間を最小限に抑えると、フラグメント化されたパケットが期限切れになる可能性が低くなるためです。この緩和策は、ノードが「飽和」している場合にのみ違いが生じることに注意してください（つまり、TCPバッファが空の場合、効果はありません）。ノードは常に飽和状態になります。ネットワークソケットへのデータ書き込みの速度がアップリンクの伝送速度を超えています。この状況に対するTCPスタックの一般的な応答は、バッファを大きくすることです。これは実際には悪影響を及ぼします。レイテンシーが増加し、それがあらゆる種類の問題を引き起こすためです。したがって、fq_codelはそれを軽減するのに役立ちます。
これらの緩和策は両方とも、3つの基本的なネットワーク障害すべてに役立ちます。なし障害のあるノードを迂回するルーティング、およびなしハードウェアの変更またはISPへの連絡。