При работе с Amazon многое остается за кадром. Для обычного пользователя это даже хорошо, ему нужен работающий сервис и не имеет значение, как этот сервис реализован. Но для тех, кто проектирует системы для Amazon или других облачных провайдеров это может быть проблемой. Некоторые внутренние аспекты работы выясняются при общении с тех. поддержкой, но в большинстве случаев для лучшего понимания приходится проводить различные тесты и эксперименты.
Возьмем, к примеру, производительность сети. Гарантирует ли Amazon определенную пропускную способность сети для любой машины или нет, как зависит скорость сети от ресурсов сервера, от региона или времени суток. Скажу сразу, что поддержка Amazon настоятельно рекомендует использовать машины больших размеров, если скорость сети является важным критерием и то, что максимально скорость 1G/s. Но всё всегда лучше проверить на практике.
1. Условия теста и подготовка тестовой площадки
Нужна была чистая максимальная пропускная способность сети, как можно меньше зависящая от операционной системы и программного обеспечения, поэтому в качестве инструмента был выбран iperf, в качестве платформы Ubuntu 12.04.
Запускать все машины вручную, устанавливать на них нужное программное обеспечение и запускать тесты вручную это, разумеется «не наш метод».
Поэтому почти все операции были автоматизированы. Для автоматизации были выбраны:
- AMI включающий стартовый скрипт получающий все необходимые данные из user-data, описано здесь
- Chef выполняющий рецепт по установке, конфигурированию и запуску iperf
- Cloud Formation для запуска стеков необходимых виртуальных машин по расписанию
То, что не осталось автоматизированным это создание Cloud Formation шаблонов, отображение статистики и рисование графиков. Всё это тоже можно легко автоматизировать, если есть необходимость проводить такие тесты регулярно.
Машины запускаются парами: сервер/клиент, одна пара для каждого шейпа, зоны доступности и региона.
В user-data передаются адрес Chef сервера, роль для Chef клиента, атрибуты для рецепта и тег, уникальный для каждой пары машин:
chefserver=«chefserver:4000»;chefrole=«iperf»;chefattributes=«iperf.role=client»;tag=«us1a-to-us1a-t1micro»
Для того, чтобы шаблон Cloud Formation прошел валидацию двойные кавычки экранируются, без Cloud Formation в этом нет необходимости.
Атрибут 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
Клиент ищет хост c таким же тегом и ролью server, получает её 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 клиенте.
Пример шаблона для Cloud Formation:
{
"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 образы и ключи. Создание групп безопасности можно описать прямо в шаблоне.
Пример запуска стека Cloud Formation по крону:
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
Каждый стек находится в запущенном состоянии не более часа в целях экономии.
2. Результаты тестов.
Все тесты повторялись по несколько раз, для того чтобы избежать случайных искажений, единичные показатели, которые сильно отличались от остальных были отброшены, а остальные данные были усреднены.
В пределах одной зоны доступности:
Разные зоны доступности, в пределах одного региона, Mbits/sec:
Можно увидеть, что m1.medium показывает лучшие результаты по сравнению с m1.large. Можно предположить, что машины размером от t1. micro до m1.medium запускаются на более слабых физических серверах, и m1.medium может получить почти весь канал, который есть у физического сервера. В то время, как m1.large стартует на более мощных, но более загруженных серверах и скорость сети для неё ниже.
Разные регионы в пределах одного континента, Mbits/sec:
Между регионами в US-EAST-1 и EU-WEST-1, Mbits/sec:
Здесь видно, что даже между регионами разница в скорости сети для разных размеров отличается, но при этом для машин, оптимизированных по памяти (m1) зависимость скорости сети от размера машины прямо пропорциональна. Есть предположение, что в данном случае Amazon ограничивает скорость в принудительном порядке на своем сетевом оборудовании.
Между регионами в US-EAST и AP-SOUTHEAST-2, Mbits/sec:
Этот тест давал очень большой разброс по скорости от запуска к запуску, скорее всего это обусловлено сильным влиянием промежуточных узлов и каналов связи.
В зависимости от времени суток, для m1.medium, Mbits/sec, UTC:
Для проверки разницы скорости сети в зависимости от времени суток был выбран m1.medium, показывающий довольно хорошую скорость сети при среднем размере машины. Учитывая тот факт, что одна и та же пара машин любого размера при запуске нескольких тестов подряд могла показывать отклонения 5-10 процентов, можно сделать вывод, что время суток не имеет сильного влияния на загруженность сети. Так как разброс тоже составляет 5-10 процентов.
Интересные факты, выявленные во время тестов:
- примерно в 5% случаев при старте стека хотя бы одна из машин не проходила health check и не стартовала корректно
- примерно в 5% случаев весь стек не стартовал, а зависал в состоянии «creation in progress», его приходилось удалять вручную и перезапускать
- машины, оптимизированные по производительности процессора (c1) стартовали в два раза дольше остальных, хотя при запуске их без Cloud Formation они запускаются так же быстро, как и остальные
Надеюсь, эта информация была полезна для вас.
Автор: helldesigner
