Standard_D1_v21SKUでAzure VMを作成しますSoutheast Asia。このドキュメント予想される帯域幅は 750Mbps です。
しかし、ローカルマシンからVMへの接続帯域幅をテストすると、結果は約3Mbpsでした。テストツールはパーフェクト3VMをiPerf3サーバー、ローカルマシンをiPerf3クライアントとして使用しました。テスト中、VMに他の重いネットワーク負荷はありませんでした。NTTTCPこの結果に従いました。
実際の帯域幅は、次のようないくつかの理由により予想よりも少なくなることを理解しています。
- 接続は多数のホップを含む複数の領域にまたがります。
- 共有インフラストラクチャ内のVMは合計制限を共有します（リンク）。
- VMはレイテンシが最も少ないリージョンにデプロイされます（Azure スピードテスト）。
しかし、実際の帯域幅 (3Mbps) は予想 (750Mbps) よりはるかに低いです。それでは、次のことを行ってください。
- 根本的な原因をトラブルシューティングしますか? VM の構成ミス、リージョン間接続のホップ数が多すぎる、またはインフラストラクチャのどこかにスロットルがあるのでしょうか?
- ローカルマシンとリモート VM 間の帯域幅を改善するにはどうすればよいですか?
答え1
まったく明白なテストをいくつかやってみてはどうでしょうか。専門家向けのサイトではなく、スーパーユーザーで質問したほうがよいのではないかと思わせるようなテストです。
- 両端と両端の帯域幅をテストします。インターネットから取得したテストを使用します。その多くはブラウザで実行されます。Speedtest.net では、カウンターポイントを選択できるため、ローカル サーバーから開始して反対側 (少なくとも近い側) を使用し、パス全体をテストすることができます。
本質的には、あなたまたは相手側にローカルな問題がない限り (あなたが成功しているような非常に遅い速度レベルでは、ローカルな問題が発生する可能性は低い)、これはルーティングの問題であり、次の 2 つのことを除いて、何もできません。
- ISPサポートに相談する
- インターネットプロバイダーを変更します。
ルーティングは彼らの領域です。彼らは特定のルートを台無しにしている可能性がありますが、そうでない場合は、別のインターネット プロバイダーを探す以外に何もできません。
あなたのテストは（現状のままでは）まったく役に立ちません。なぜなら、A から B のみをテストし、いずれかの側にローカルな問題があるかどうかはテストしないからです。私のアプローチでは、対比を変えて、ローカル マシンに特定の宛先への問題があるかどうかを確認できます。ローカルの帯域幅は十分でも、国際リンクが過負荷になっている可能性があります。
それがうまくいけば、使用されている OS をチェックする時間です。RSS が存在するのには理由があります。RSS は、長い ping に必要な可能性がある「飛行中の」パケットの数を増やすためです。
それ以外に、本当にできることは何もありません。
答え2
フォーラムへようこそ。
ここでの問題は、間のポイントを制御できないことです。この粒度を見つけることは、科学と芸術の両面を持ちます。なぜなら、本当に良い答えは 1 つではなく、多くの要因にわたる調査結果のレポートだからです。
ボトルネックを適切に特定するには、各側との間のすべてのポイントをテストできる必要があります。すべてのポイントにアクセスすることはできませんが、いくつかのことを推測し、さまざまな角度から見て、より良い画像を得ることができます。
排除できるのは、「あなたの側に十分なスループットがありますか?」という質問です。これは、テストする専用帯域幅を持つ既知のサイトと、スループットを維持できる既知の良好なルートがあれば可能です。オンライン速度テストは、あなたには十分な接続があり、相手側にはテストを確実に実行するための十分な帯域幅がある可能性があるため、当てにならない場合があります。しかし、あなたと相手側の間で何が起こるかをコントロールするのはどちらもできません。複数のテスト サイトで一貫して良好な速度テストが得られている場合は、あなたがコントロールしている限り、問題があなたの側にあることを比較的安全に排除できます。もちろん、その反対に、すべてで失敗してもあなたのせいではない場合、ISP の ISP、どこかのコア ネットワークの誰か、ダウンしたルートが別のルートを混雑させてアップ状態を維持しているなどである可能性があります。その場合、ISP に介入を依頼できますが、消費者向け回線では「最大速度」を突きつけられますが、専用のビジネス回線では議論の余地はありますが、立証責任は残ります。
不可能ではありませんが、契約上帯域幅が制限されていない限り、Azure 側でチョーク ポイントが発生する可能性は低くなります。
MTRを使うなどのことができますhttps://en.wikipedia.org/wiki/MTR_(ソフトウェア)簡単に概要を説明しますが、ICMP のドロップはシステムの自然な動作の結果である可能性があることに留意してください。ほとんどのネットワーク機器はストレス下で ICMP を破棄し、一部の機器はデフォルトで応答しないように設定されているためです。このことから、より多くの情報が得られるかもしれませんが、決定的な証拠ではありません。これを読み、解釈する方法を理解する必要があります。
ここのような場所を見ることができますhttps://www.thousandeyes.com/outages/大規模な障害は、世界中のセンサー ネットワークを介して記録されます。特に AS ネットワーク (簡単に言えばインターネットのコア ノード) で、ルートに直接影響する問題が発生している場合は、そこからヒントが得られることがあります。
それを解釈し、「あなたの」ルートが何であるかを判断するには、HEのBGPツールから始めることができます。https://bgp.he.net/効果的に見ることができますどこインターネットでは、ルーティングの意味で存在します。インターネットにアクセスするために経由する IP (一般にパブリック IP と呼ばれます) をクリックすると、次のようなものが表示されます...
これは、インターネット上であなたが誰であるか（どこからアクセスしているか）、どのネットワークからアクセスしているか（どのようにアナウンスされているか）、そしてそれがどのように「インターネット」に入るか（あなたの ISP）です。
これを ASN から ASN (自律システム番号) まで追跡して、実際に通ったルート (ルートを開いたままにするために予告なく変更される可能性があるため、その時点で) を確認したり、グラフで確認したりすることもできます。
次に、千眼チャートやオンラインの多数の他の BGP レポート ツールと比較して、それらのルートに既知の輻輳があるかどうか、またはフラッピング (上下に動いている) があるかどうかなどを確認できます。
これにより、通常、どのシステムを誰が担当しているかを通知するのに十分な情報が得られます (ほとんどの ISP は、ISP 以外を気にしないことに注意してください)。これにより、希望どおりの結果にはならないかもしれませんが、希望どおりの結果にならない理由が説明されます。
全体的に、このように考える必要があります。インターネット全体で速度が一定しているわけではなく、一部のセクションは驚くほど高速なリンクで接続されていますが、他のセクションはそれほど高速ではありません。そして、それらの大きなリンクの 1 つがダウンすると、多くの小さなリンクが大きな影響を受けます。
それで、あなたは何ができるでしょうか? 時々ピアツーピア接続を行っている場合は、これを回避できますが、回避したからといって、同じルートを移動するすべての顧客が同じ体験を得られるとは限りません。たとえば、Web サーバーをあちらに置いて、リモート エンドに近い VPN プロバイダーなどに安定した良好なスループットの接続を確立し、より良いルートを強制的に選択できる場合があります。同じことをせずにサーバーにアクセスするユーザーは、同じ体験をすることはできません。これをすべて有料で実行できるサービスもあり、サーバーを実際とは異なる場所に見せかけて、プレミアム ルートを使用します。おそらく、Cloudflare にはこのようなサービスがありますが、私は使用したことがないので、Cloudflare の専門家に意見を聞いてみましょう。
うまくいけば、これで、これがいかに難しいものになるか、また、自分の経験と州をまたいだ誰かの経験がまったく異なる可能性があることを理解するのに十分な情報が得られるでしょう。