Clever Geek Handbook

Amazon EC2ネットワーク速度テスト

アマゾンで作業するとき、多くは舞台裏に残っています。 平均的なユーザーにとって、これはさらに良いことです。彼は実際のサービスが必要であり、このサービスがどのように実装されているかは関係ありません。 しかし、Amazonや他のクラウドプロバイダー向けにシステムを設計する人にとっては、これが問題になる可能性があります。 作業の内部的な側面は、それらを扱うときに明らかになります。 サポートしますが、ほとんどの場合、理解を深めるために、さまざまなテストと実験を行う必要があります。

たとえば、ネットワークパフォーマンスを考えてみましょう。 Amazonがマシンの特定のネットワーク帯域幅を保証するかどうか、ネットワーク速度がサーバーリソース、地域、または時刻に依存する方法。 ネットワークの速度が重要な基準であり、最大速度が1G / sである場合、Amazonサポートは大きなマシンを使用することを強くお勧めします。 しかし、すべてを実際に確認する方が常に優れています。





1.テスト条件とテストサイトの準備

オペレーティングシステムとソフトウェアに応じて、可能な限り低いクリーンな最大ネットワーク帯域幅が必要だったため、Ubuntu 12.04プラットフォームとしてiperfがツールとして選択されました。



すべてのマシンを手動で実行し、必要なソフトウェアをインストールし、テストを手動で実行することは、もちろん「私たちの方法ではありません」。



したがって、ほとんどすべての操作が自動化されました。 自動化のために、次のものが選択されました。

  1. AMIには、 ここで説明するユーザーデータから必要なすべてのデータを受け取る開始スクリプトが含まれています
  2. iperfをインストール、構成、および起動するためのChef Runningレシピ
  3. スケジュールされた仮想マシンスタックを起動するクラウド形成




自動化されていないのは、クラウド形成テンプレートの作成、統計の表示、グラフの描画です。 そのようなテストを定期的に実施する必要がある場合は、これらすべてを簡単に自動化することもできます。



マシンはペアで起動されます。サーバー/クライアント、形状ごとに1つのペア、アベイラビリティーゾーンとリージョン。



ユーザーデータには、Chefサーバーのアドレス、Chefクライアントのロール、レシピの属性、およびマシンの各ペアに固有のタグが渡されます。



chefserver = \ "chefserver：4000 \"; chefrole = \ "iperf \"; chefattributes = \ "iperf.role = client \"; tag = \ "us1a-to-us1a-t1micro \"



クラウド形成テンプレートを検証するために、クラウド形成なしで二重引用符がエスケープされますが、これは必要ありません。



iperf.role属性にはマシンのロールが含まれます：サーバーモードのiperfまたはクライアントモードのiperf。タグとロールを使用して、各マシンに対して一意の識別子が生成されます。 



tag = GetValue("#{node[:userdata]}","#{node[[:userdata]}","tag") node.override['iperf']['hostid'] = "#{tag}_#{node.iperf.role}"




サーバーはiperfを開始するだけです。 

 execute "iperf-server-run" do command "/usr/bin/iperf -s&" action :run end




クライアントは、同じタグとサーバーの役割を持つホストを検索し、public_hostnameでテストを開始して、結果をメールに送信します。 これはすべて、属性を介して設定されます。 



 server = search(:node, "hostid:#{node['iperf']['tag']}_server").first[:ec2][:public_hostname] Chef::Log.info("Server: #{server}") if server.any? execute "iperf-client-run" do command "/usr/bin/iperf -t #{node.iperf.time} -c #{server} | mail #{node['iperf']['email']} -s #{node['iperf']['region']}#{node['ipe rf']['shape']}_#{node['iperf']['role']}" action :run end else Chef::Log.info("iperf server not found, wait.") end




目的のタグを持つサーバーが見つからない場合、Chefクライアントで指定された間隔で検索が繰り返されます。



クラウド形成のテンプレートの例： 

 { "AWSTemplateFormatVersion" : "2010-09-09", "Parameters" : { "InstanceSecurityGroup" : { "Description" : "Name of an existing security group", "Default" : "iperf", "Type" : "String" } }, "Resources" : { "US1atoUS1aT1MicroServer" : { "Type" : "AWS::EC2::Instance", "Properties" : { "AvailabilityZone" : "us-east-1a", "KeyName" : "test", "SecurityGroups" : [{ "Ref" : "InstanceSecurityGroup" }], "ImageId" : "ami-31308c58", "InstanceType" : "t1.micro", "UserData" : { "Fn::Base64" : { "Fn::Join" : ["",[ "chefserver=\"chefserver:4000\";chefrole=\"iperf\";chefattributes=\"iperf.role=client\";tag=\"us1a-to-us1a-t1micro\"" ]]}} } }, "US1atoUS1aT1MicroClient" : { "Type" : "AWS::EC2::Instance", "Properties" : { "AvailabilityZone" : "us-east-1a", "KeyName" : "test", "SecurityGroups" : [{ "Ref" : "InstanceSecurityGroup" }], "ImageId" : "ami-31308c58", "InstanceType" : "t1.micro", "UserData" : { "Fn::Base64" : { "Fn::Join" : ["",[ "chefserver=\"chefserver:4000\";chefrole=\"iperf\";chefattributes=\"iperf.role=server\";tag=\"us1a-to-us1a-t1micro\"" ]]}} } } } }




必要なすべてのリージョンには、必要なAMIイメージとキーが必要です。 セキュリティグループの作成は、テンプレートで直接説明できます。



クラウンでクラウドフォーメーションスタックを開始する例：

05 00 * * * cfn-create-stack --template-file = iperf_us-east-1a-to-us-east-1a.template --stack-name iperf-us-east-1a-to-us-east- 1a-リージョンus-east-1

50 00 * * * cfn-delete-stack iperf-us-east-1a-to-us-east-1a --region us-east-1 --force



各スタックは、保存するために1時間以内の実行状態にあります。



2.テスト結果。



ランダムな歪みを回避するために、すべてのテストが数回繰り返され、残りとは非常に異なる単一のインジケーターは破棄され、残りのデータは平均化されました。



同じMbit /秒のアベイラビリティーゾーン内 ：





同じ地域内の異なるアクセシビリティゾーン、 Mbits /秒 ：





m1.mediumはm1.largeよりも良い結果を示していることがわかります。 車のサイズはt1であると想定できます。 microはm1.mediumまではより弱い物理サーバー上で実行され、m1.mediumは物理サーバーが持つほぼすべてのチャネルを取得できます。 m1.largeは、より強力で負荷の高いサーバーで起動しますが、ネットワーク速度はそれよりも遅くなります。



同じ大陸内の異なる地域、 Mビット/秒 ：





US-EAST-1とEU-WEST-1のリージョン間、 Mbits /秒 ：





ここでは、地域間でさえ、異なるサイズのネットワーク速度の違いは異なりますが、同時に、メモリ（m1）によって最適化されたマシンでは、マシンのサイズに対するネットワーク速度の依存性は正比例します。 この場合、Amazonはネットワーク機器の速度を強制的に制限するという仮定があります。



US-EASTとAP-SOUTHEAST-2のリージョン間、Mbits /秒 ：





このテストでは、起動から起動までの速度が非常に大きく広がりました。これは、おそらく中間ノードと通信チャネルの強い影響によるものです。



時刻に応じて、m1.medium、Mbits / sec 、UTCの場合：





時刻に応じたネットワーク速度の違いを確認するために、m1.mediumが選択され、平均的なマシンサイズでかなり良いネットワーク速度を示しました。 いくつかのテストを連続して開始したときに、任意のサイズの同じマシンペアが5〜10％の偏差を示す可能性があることを考慮すると、時刻はネットワークの輻輳に大きな影響を与えないと結論付けることができます。 スプレッドも5〜10パーセントです。



テスト中に明らかになった興味深い事実 ：

  1. 約5％の場合、スタックの開始時に、少なくとも1台のマシンがヘルスチェックに合格せず、正しく起動しませんでした
  2. 約5％の場合、スタック全体は起動しませんでしたが、「作成中」状態でクラッシュしたため、手動で削除して再起動する必要がありました
  3. プロセッサパフォーマンス（c1）向けに最適化されたマシンは、他の2倍の長さで起動しましたが、クラウド形成なしで起動した場合、他のマシンと同じ速さで起動します




この情報がお役に立てば幸いです。


More articles:


All Articles