たとえば、ネットワークパフォーマンスを考えてみましょう。 Amazonがマシンの特定のネットワーク帯域幅を保証するかどうか、ネットワーク速度がサーバーリソース、地域、または時刻に依存する方法。 ネットワークの速度が重要な基準であり、最大速度が1G / sである場合、Amazonサポートは大きなマシンを使用することを強くお勧めします。 しかし、すべてを実際に確認する方が常に優れています。
1.テスト条件とテストサイトの準備
オペレーティングシステムとソフトウェアに応じて、可能な限り低いクリーンな最大ネットワーク帯域幅が必要だったため、Ubuntu 12.04プラットフォームとしてiperfがツールとして選択されました。
すべてのマシンを手動で実行し、必要なソフトウェアをインストールし、テストを手動で実行することは、もちろん「私たちの方法ではありません」。
したがって、ほとんどすべての操作が自動化されました。 自動化のために、次のものが選択されました。
- AMIには、 ここで説明するユーザーデータから必要なすべてのデータを受け取る開始スクリプトが含まれています
- iperfをインストール、構成、および起動するためのChef Runningレシピ
- スケジュールされた仮想マシンスタックを起動するクラウド形成
自動化されていないのは、クラウド形成テンプレートの作成、統計の表示、グラフの描画です。 そのようなテストを定期的に実施する必要がある場合は、これらすべてを簡単に自動化することもできます。
マシンはペアで起動されます。サーバー/クライアント、形状ごとに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 /秒のアベイラビリティーゾーン内 :
![](https://habrastorage.org/storage2/fac/c37/da1/facc37da110f8d59cb436aa07a19de48.jpg)
同じ地域内の異なるアクセシビリティゾーン、 Mbits /秒 :
![](https://habrastorage.org/storage2/155/64c/b11/15564cb11973d60ee48d873b01c858bc.jpg)
m1.mediumはm1.largeよりも良い結果を示していることがわかります。 車のサイズはt1であると想定できます。 microはm1.mediumまではより弱い物理サーバー上で実行され、m1.mediumは物理サーバーが持つほぼすべてのチャネルを取得できます。 m1.largeは、より強力で負荷の高いサーバーで起動しますが、ネットワーク速度はそれよりも遅くなります。
同じ大陸内の異なる地域、 Mビット/秒 :
![](https://habrastorage.org/storage2/852/0b2/ff7/8520b2ff7636305bbedc9240a87a6cf6.jpg)
US-EAST-1とEU-WEST-1のリージョン間、 Mbits /秒 :
![](https://habrastorage.org/storage2/b63/2d2/864/b632d2864b2f415a34a56c5ec1e5de71.jpg)
ここでは、地域間でさえ、異なるサイズのネットワーク速度の違いは異なりますが、同時に、メモリ(m1)によって最適化されたマシンでは、マシンのサイズに対するネットワーク速度の依存性は正比例します。 この場合、Amazonはネットワーク機器の速度を強制的に制限するという仮定があります。
US-EASTとAP-SOUTHEAST-2のリージョン間、Mbits /秒 :
![](https://habrastorage.org/storage2/163/6e8/fa9/1636e8fa918b0ff68e0f29f303e5957f.jpg)
このテストでは、起動から起動までの速度が非常に大きく広がりました。これは、おそらく中間ノードと通信チャネルの強い影響によるものです。
時刻に応じて、m1.medium、Mbits / sec 、UTCの場合:
![](https://habrastorage.org/storage2/d18/251/4b2/d182514b238b47dfe2552decf389427a.jpg)
時刻に応じたネットワーク速度の違いを確認するために、m1.mediumが選択され、平均的なマシンサイズでかなり良いネットワーク速度を示しました。 いくつかのテストを連続して開始したときに、任意のサイズの同じマシンペアが5〜10%の偏差を示す可能性があることを考慮すると、時刻はネットワークの輻輳に大きな影響を与えないと結論付けることができます。 スプレッドも5〜10パーセントです。
テスト中に明らかになった興味深い事実 :
- 約5%の場合、スタックの開始時に、少なくとも1台のマシンがヘルスチェックに合格せず、正しく起動しませんでした
- 約5%の場合、スタック全体は起動しませんでしたが、「作成中」状態でクラッシュしたため、手動で削除して再起動する必要がありました
- プロセッサパフォーマンス(c1)向けに最適化されたマシンは、他の2倍の長さで起動しましたが、クラウド形成なしで起動した場合、他のマシンと同じ速さで起動します
この情報がお役に立てば幸いです。