epamcloud.blogspot.ca: Testing Amazon EC2 network speed

epamcloud.blogspot.ca: Testing Amazon EC2 network speed

by Serhiy Topchiy

While working with Amazon many aspects remain behind the scenes, which is a benefit for most of users, who require a working service, while having no interest in its implementation. However, this can be a problem for Amazon solution architects. Some of the internal aspects can be learned from Amazon support, yet in most cases deeper understanding requires various tests and experiments.
Think, for instance, of network performance. Does Amazon guarantee a certain bandwidth for each machine? What is the relation between network performance and server resources, region or time of day? I should mention that Amazon support strongly recommends using large machine shapes whenever network speed is critical, while the maximum speed is 1 Gb/sec. However, we would better see for ourselves.

1. Test Conditions and Site Preparation

The goal of this test is to find out the pure maximum network bandwidth, ideally independent from operating system and software. This is why we picked iperf as a testing tool and Ubuntu 12.04 as a platform.

Naturally, running all machines, setting up required software and launching the tests manually is not an option for us.

We have had nearly every operation automated using the following tools:

1. AMI including a launch script that receives all necessary data from user-data, described here
2. Chef executing a recipe for installation, configuration and launch of iperf
3. Cloud Formation launching stacks of required virtual machines as scheduled

The things left unautomated are creation of Cloud Formation templates, display of statistics and charts drawing. However, all of them can also be easily automated, in case there is a need to run these tests regularly.

Machines are launched in the server-client pairs: a pair for each shape, availability zone and region.

User-data pass Chef server address, a role for Chef client, recipe attributes and a unique tag for each machine pair:

chefserver=\«chefserver:4000\»;chefrole=\«iperf\»;chefattributes=\«iperf.role=client\»;tag=\«us1a-to-us1a-t1micro\»

Double quotes on the example above are enclosed so that the Сloud Formation template can pass validation. Without Cloud Formation there is no need to do that.

The iperf.role attribute contains a machine role: iperf in server mode or iperf in client mode. This tag and role combination is used to create a unique identifier for each machine:

tag = GetValue(“#{node[:userdata]}”,”#{node[[:userdata]}”,”tag”)
node.override[‘iperf’][‘hostid’] = “#{tag}_#{node.iperf.role}”

The server simply launches iperf:

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

Client simply looks for a host with the same tag and server role, retrieves its public_hostname, launches testing and emails its results. All of the above is specified using attributes:

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

If the client fails to find a server with the required tag, it repeats the search after a specified interval.

Example of a Cloud formation template:

{
“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\””
]]}}
}
}
}
}

All required regions must have required AMI images and keys provided. Creation of security groups can be described right in the template.

Below is the example of Cloud Formation stack launch by cron:
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 –region us-east-1
50 00 * * * cfn-delete-stack iperf-us-east-1a-to-us-east-1a –region us-east-1 –force

Each stack stays launched for up to one hour for cost effectiveness reasons.

2. Test results.

Each test was run several times to avoid inadvertent distortion. We discarded individual results, markedly different from the general picture and averaged out the rest of the data.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s