EC2: различия между версиями

Материал из noname.com.ua
Перейти к навигацииПерейти к поиску
 
(не показано 65 промежуточных версий этого же участника)
Строка 1: Строка 1:
  +
[[Категория:Amazon EC2]]
 
=Amazon EC2=
  
=Amazon EC2=
  +
  +
Задача: Есть некое приложение которое легко масштабируется. Задача - добавлать сервера в кластер при росте нагрузки и удалять при падении нагрузки автоматически. Метрика - результат работы скрипта, т.е. отличная от стандартных.
   
 
==Введение==
  
==Введение==
Строка 20: Строка 23:
 
в ~/.bashrc (у меня под рутом)
  
в ~/.bashrc (у меня под рутом)
 
<PRE>
  
<PRE>
−
export EC2_PRIVATE_KEY=$HOME/keys/ec2-key.pem
 +
export EC2_PRIVATE_KEY=$HOME/keys/nocrypt-ec2-key.pem
 
export EC2_CERT=$HOME/keys/ec2_cert.pem
  
export EC2_CERT=$HOME/keys/ec2_cert.pem
 
export JAVA_HOME=/usr/lib/jvm/jre-1.6.0-openjdk.x86_64/
  
export JAVA_HOME=/usr/lib/jvm/jre-1.6.0-openjdk.x86_64/
Строка 48: Строка 51:
 
<B>Внимание! нужно преобразовать ключ - с оригинальным работают не все утилиты!!!!</B>
  
<B>Внимание! нужно преобразовать ключ - с оригинальным работают не все утилиты!!!!</B>
 
<PRE>
  
<PRE>
−
openssl pkcs8 -topk8 -in ec2-key.pem -nocrypt > new-ec2-key.pem
 +
openssl pkcs8 -topk8 -in ec2-key.pem -nocrypt > nocrypt-ec2-key.pem
 
</PRE>
  
</PRE>
  +
 
===ssh keys===
  
===ssh keys===
 
После подключения сертефикатов - начинают работать ec2-утилиты
  
После подключения сертефикатов - начинают работать ec2-утилиты
Строка 78: Строка 82:
 
chmod 600 new_key.pem
 
chmod 600 new_key.pem
 
</PRE>
  
</PRE>
  +
  +
==Работа с инстансами (VM)==
  +
===Создать instance===
  +
Мне нужен Amazon Linux, пока я не знаю где смотреть полный список возможных образов - указал как на уже существующем инстансе (чуть ниже немного деталей где смотреть, этот вопрос под сомнением)
  +
<PRE>
  +
ec2-run-instances ami-2a31bf1a --instance-type t1.micro --region us-west-2 --key keyName
  +
  +
RESERVATION r-6dd5865e 371025327760 default
  +
INSTANCE i-d71c11e4 ami-2a31bf1a pending hcluster 0 t1.micro 2012-11-09T12:22:56+0000 us-west-2a aki-fc37bacc monitoring-disabled ebs paravirtual xen sg-c6dc4df6 default false
  +
</PRE>
  +
<B>Обратить внимание:</B> keyName это указатель на существующий ключ, и потому никакого расширения. Во многих источника я встречал keyName.pem - это ошибка
  +
  +
Параметры:
  +
* ami-2a31bf1a – Идентификатор AMI образа. Определяет какая операционная система будет установлена на EC2 instance.
  +
* --instance-type t1.micro – Какой величины будет instance. см. Варианты EC2 хостов
  +
* --region eu-west-1 – регион где будет создан instance.
  +
* --key test123.pem – Ключ который будет использоваться для доступа по ssh к instance.
  +
  +
Как то так смотреть список id:
  +
<PRE>
  +
ec2-describe-images -o amazon --region us-west-2 | grep "amzn-ami-pv"
  +
</PRE>
  +
Или тут что то есть http://aws.amazon.com/amazon-linux-ami/
  +
  +
===Список instances в регионе===
  +
<PRE>
  +
ec2-describe-instances --region us-east-1
  +
</PRE>
  +
  +
===Удалить instance===
  +
<PRE>
  +
ec2-terminate-instances instance_id
  +
</PRE>
  +
  +
instance_id можно посмотреть с помощью команды ec2-describe-instances.
  +
  +
===Перезагрузка ec2 instance===
  +
<PRE>ec2-reboot-instances</PRE>
  +
для ec2 instance идентична мягкой перезагрузке для обычного компьютера. Если попытка мягкой перезагрузки потерпит крах, возможна жесткая перезагрузка. Для instances с EBS 100% безопасно. Полезно если instance завис по каким то причинам.
  +
  +
<PRE>ec2-reboot-instances --region eu-west-1 instance_id</PRE>
  +
instance_id можно посмотреть с помощью команды ec2-describe-instances.
  +
===Создание/просмотр/удаление tags===
  +
  +
С помощью tags можно помечать instance, во избежании обретения кучи безымянных instances загадочного назначения.
  +
====Просмотр tags в регионе====
  +
<PRE>
  +
ec2-describe-tags --region us-west-2
  +
</PRE>
  +
  +
====Создание tags====
  +
<PRE>
  +
ec2-create-tags --region eu-west-1 instance_id --tag key[=value] [--tag key[=value]]
  +
</PRE>
  +
instance_id можно посмотреть с помощью команды ec2-describe-instances.
  +
удобно создавать tags вроде:
  +
<PRE>
  +
ec2-create-tags --region us-west-2 instance_id --tag Name=site_testing_area --tag Creator=employee1
  +
</PRE>
  +
=====Пример=====
  +
Нахожу свой инстанс:
  +
<PRE>
  +
ec2-describe-instances --region us-west-2
  +
....
  +
RESERVATION r-6dd5865e 371025327760 default
  +
INSTANCE i-d71c11e4 ami-2a31bf1a ec2-50-112-212-246.us-west-2.compute.amazonaws.com ip-10-248-15-79.us-west-2.compute.internal running hcluster 0 t1.micro 2012-11-09T12:22:56+0000 us-west-2a aki-fc37bacc monitoring-disabled 50.50.50.50 10.10.10.10 ebs paravirtual xen sg-c6dc4df6 default false
  +
BLOCKDEVICE /dev/sda1 vol-83dbd1a5 2012-11-09T12:22:59.000Z true
  +
....
  +
</PRE>
  +
<PRE>
  +
ec2-create-tags --region us-west-2 i-d71c11e4 --tag Name=TestNode
  +
</PRE>
  +
  +
====Удаление tags====
  +
<PRE>
  +
ec2-delete-tags --region eu-west-1 instance_id --tag clumsytag
  +
</PRE>
  +
  +
==Конфигурация инстанса==
  +
Я хочу наконфиггурировать инстанс паппетом, хотя эта часть статьи выходит за пределы EC2, потому - обзорно. Сервер puppet у меня уже есть, подробностей минимум.
  +
<BR>
  +
На ноде необходимо установить:
  +
* tomcat7
  +
* nginx
  +
* syslog-ng вместо rsyslog (rsyslog мне кажется неудобным но многие с этим не согласны - дело вкуса).
  +
* настроить пересылку логов на ценральное хранилище (инстансы подобные этому могут добавлятся и улдалятся автоматически, ничего не хранить локально)
  +
* актуальная конфигурация (паппет запускается раз в X минут и делает все что нужно)
  +
  +
===Наброски манифеста===
  +
<PRE>
  +
class nginx-tomcat-lb {
  +
  +
package {
  +
"nginx":
  +
ensure => installed
  +
}
  +
  +
  +
package {
  +
"tomcat7":
  +
ensure => installed
  +
}
  +
  +
  +
file { "/etc/nginx/nginx.conf":
  +
ensure => present,
  +
owner => "root",
  +
group => "root",
  +
alias => "nginx-config",
  +
content => template("nginx-tomcat-lb/nginx_conf.erb"),
  +
require => Package["nginx"],
  +
notify => Service["nginx"],
  +
}
  +
  +
service {
  +
"nginx":
  +
ensure => running,
  +
subscribe => File[nginx-config]
  +
}
  +
  +
service {
  +
"tomcat7":
  +
ensure => running,
  +
}
  +
}
  +
</PRE>
  +
  +
==Load Balancer==
  +
Для управление лоад балансерами используются elb- утилиты
  +
===Просмотр балансеров===
  +
<PRE>
  +
elb-describe-lbs
  +
LOAD_BALANCER lb-test1 test1-1812564742.us-east-1.elb.amazonaws.com 2012-07-06T08:39:01.940Z internet-facing
  +
LOAD_BALANCER lb-dev1 dev1-1835033989.us-east-1.elb.amazonaws.com 2012-07-09T12:52:11.290Z internet-facing
  +
</PRE>
  +
  +
<PRE>
  +
elb-describe-lbs --region us-west-2
  +
LOAD_BALANCER lb-west lb-west-1263536513.us-west-2.elb.amazonaws.com 2012-11-06T18:51:54.560Z internet-facing
  +
</PRE>
  +
  +
===Добавить балансер===
  +
<PRE>
  +
elb-create-lb test-lb --headers --listener "lb-port=80,instance-port=80,protocol=http" --availability-zones us-west-2a --region us-west-2
  +
DNS_NAME DNS_NAME
  +
DNS_NAME test-lb-1678700173.us-west-2.elb.amazonaws.com
  +
</PRE>
  +
<B>Следить за --availability-zones us-west-2a - балансер работает внутри зоны!</b>
  +
  +
===Добавить инстанс под балансер===
  +
<PRE>
  +
elb-register-instances-with-lb test-lb --instances i-d71c11e4
  +
elb-register-instances-with-lb: Service error: There is no ACTIVE Load Balancer named 'test-lb'
  +
AWSRequestId:b74a0d60-2a75-11e2-9b12-73ca28379447
  +
</PRE>
  +
<B>Не забывать про регион!</B>
  +
<PRE>
  +
#elb-register-instances-with-lb test-lb --instances i-d71c11e4 --region us-west-2
  +
INSTANCE_ID i-d71c11e4
  +
</PRE>
  +
  +
===Снять образ===
  +
<PRE>
  +
ec2-create-image i-d71c11e4 --no-reboot -n 'MyImageName' -d 'Description' --region us-west-2
  +
IMAGE ami-180a8328
  +
</PRE>
  +
  +
===создать launch-config===
  +
<PRE>
  +
as-create-launch-config test-launch-config -i ami-180a8328 --key=sshkey --group default --instance-type t1.micro --region us-west-2
  +
OK-Created launch config
  +
</PRE>
  +
* test-launch-config - имя конфига
  +
* sshkey — ssh kлючь с которым логинится на сервер
  +
* group — секьюрити группа, в которой будут подыматься серверы. У меня (т.к. это только тест ) - дефолтная группа
  +
  +
===Автоскейлинг группа===
  +
Везде помнить про регион! и про --availability-zones us-west-2 - это разные вещи!!!
  +
<PRE>
  +
as-create-auto-scaling-group test-scaling-group -l test-launch-config --availability-zones us-west-2a --min-size 0 --max-size 2 --load-balancers test-lb --region us-west-2
  +
OK-Created AutoScalingGroup
  +
</PRE>
  +
Здесь:
  +
* test-launch-config — конфиг (см. чуть выше)
  +
* us-west-2a — зона, в которой будут подыматься инстансы <B> Внимание - проверить что бы лоад балансер мог работать с этой зоной!</B>
  +
* 0 и 2 — минимальный и максимальный размеры группы соответственно;
  +
* test-lb — имя вашего балансировщика, под которым будет поднята вся группа.
  +
<BR>
  +
Итак, готова группа масштабирования и балансировщик.
  +
<BR>
  +
Теперь нужно настроить CloudWatch алармы. <BR>Автомасштабирование, основанное на CloudWatch работает через политику — policy, которая задаётся.
  +
<BR>
  +
Примером политики является увеличение кол-ва интансов на 1. Т.е. сначала мы задаём политику, потом мы создаём аларм, который, например, срабатывает при Load Average больше X на протяжении минуты.
  +
<BR>
  +
<B>Важный момент - если нужно поменять образ из которого разворачивать ноды, то можно содать новый launch-config а потом поредактировать auto-scaling-group</B>
  +
<PRE>
  +
as-update-auto-scaling-group test-scaling-group --launch-configuration new-test-launch-config --availability-zones us-west-2a --min-size 0 --max-size 2 --region us-west-2
  +
</PRE>
  +
  +
===Политика скейл апа===
  +
<PRE>
  +
as-put-scaling-policy TestScaleUpPolicy --auto-scaling-group test-scaling-group --adjustment=1 --type ChangeInCapacity --cooldown 120 --region us-west-2
  +
arn:aws:autoscaling:us-west-2:371025327760:scalingPolicy:09327221-3746-4575-afe7-49e0b7aff67b:autoScalingGroupName/test-scaling-group:policyName/TestScaleUpPolicy
  +
</PRE>
  +
Здесь:
  +
* --type ChangeInCapacity - изменения размера, тип политики
  +
* --adjustment=1 — +1 хост к группе
  +
* --cooldown 120 — на протяжении 2 минут все алармы будут игнорироваться и новые инстансы подняты не будут
  +
  +
===Аларм для скейл апа===
  +
<PRE>
  +
mon-put-metric-alarm HighLoadAvAlarm --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --metric-name LoadAverage --namespace CustomMetric --period 60 --statistic Average --threshold 3 --alarm-actions arn:aws:autoscaling:us-west-2:371025327760:scalingPolicy:09327221-3746-4575-afe7-49e0b7aff67b:autoScalingGroupName/test-scaling-group:policyName/TestScaleUpPolicy --region us-west-2
  +
OK-Created Alarm
  +
</PRE>
  +
Здесь:
  +
* --comparison-operator GreaterThanOrEqualToThreshold — оператор >= чем трешхолд.
  +
* --evaluation-periods 1 — срабатывает с первого раза
  +
* --metric-name LoadAverage --namespace CustomMetric — наша кастомная метрика
  +
* --period 60 — минута на срабатывание
  +
* --statistic Average — подсчитывается среднее значение
  +
* --threshold 3 — Load Average не больше 3
  +
* --alarm-actions — какая политика. (см выше - ее идентификатор выдается при создании)
  +
  +
===Политика скейл дауна===
  +
<PRE>
  +
as-put-scaling-policy ScaleDownPolicy --auto-scaling-group test-scaling-group --adjustment=-1 --type ChangeInCapacity --cooldown 420 --region us-west-2
  +
arn:aws:autoscaling:us-west-2:371025327760:scalingPolicy:88929ef9-73c2-43c4-88b0-2a5999089976:autoScalingGroupName/test-scaling-group:policyName/ScaleDownPolicy
  +
</PRE>
  +
  +
Здесь кулдаун больше. После даунскейла инстансы группа не даунскейлится ещё минимум 6 минут. Ну и adjustment=-1.
  +
  +
===Аларм для скейл дауна:===
  +
<PRE>
  +
mon-put-metric-alarm LoLoadAvAlarm --comparison-operator LessThanThreshold --evaluation-periods 1 --metric-name LoadAverage --namespace CustomMetric --period 120 --statistic Average --threshold 2 --alarm-actions arn:aws:autoscaling:us-west-2:371025327760:scalingPolicy:88929ef9-73c2-43c4-88b0-2a5999089976:autoScalingGroupName/test-scaling-group:policyName/ScaleDownPolicy --region us-west-2
  +
OK-Created Alarm
  +
</PRE>
  +
Здесь аларм срабатывает, если больше 2 минут Load Average был меньше 2.
  +
  +
Ну вот и всё. Итак, теперь в зависимости от нагрузки, наша скейл группа сможет разрастаться до 3х инстансов и 1 всегда будет жив. Здесь рассмотрен простейший пример автоскейлинга. Естественно, можно менять условия и баловаться с цифрами по своему усмотрению.
  +
  +
===Посмотреть политики===
  +
<PRE>
  +
as-describe-policies --region us-west-2
  +
</PRE>
  +
===Посмотреть алармы===
  +
<PRE>
  +
mon-describe-alarms --region us-west-2
  +
HighLoadAvAlarm OK arn:aws:autoscalin...e/TestScaleUpPolicy CustomMetric LoadAverage 60 Average 1 GreaterThanOrEqualToThreshold 3.0
  +
LoLoadAvAlarm ALARM arn:aws:autoscalin...ame/ScaleDownPolicy CustomMetric LoadAverage 120 Average 1 LessThanThreshold 2.0
  +
</PRE>
  +
  +
==Custom checks==
  +
Теперь создадим скрипт который собвственно и будет выполнять проверку нагрузки.
  +
Во многих документах по масштабированию кластеров этот момент почему-то не описан, т.е. предпологается что этот скриапт существует и отдает данные.
  +
Насколько я могу судить, кастомнвй чем позволяеи отдавать что угодно в качестве метрики, я взял традиционно простейший LoadAverage
  +
<BR>
  +
<B>Цена за каждый такой чек - 50 центов в мес. Отключить чек нельзя, он удалится сам через 2 недели если его не использовать, т.е. не засылать новые данные</B>
  +
<PRE>
  +
#!/bin/bash
  +
  +
export AWS_CLOUDWATCH_HOME=/opt/aws/apitools/mon-1.0.13.4
  +
export AWS_CLOUDWATCH_URL=https://monitoring.amazonaws.com
  +
export PATH=AWS_CLOUDWATCH_HOME/bin:${PATH}
  +
export EC2_PRIVATE_KEY=/root/keys/nocrypt-ec2-key.pem
  +
export EC2_CERT=/root/keys/ec2_cert.pem
  +
export JAVA_HOME=/usr/lib/jvm/jre-1.6.0-openjdk.x86_64/
  +
  +
while [ true ]; do
  +
load_average=`cat /proc/loadavg | awk '{ print $2}'`
  +
  +
timestamp=`date -u +%Y-%m-%dT%H:%M:%S.000Z`
  +
  +
  +
mon-put-data --metric-name "LoadAverage" --namespace "CustomMetric" --timestamp $timestamp --value $load_average --region us-west-2
  +
  +
echo "$timestamp: Load Average $load_average" | /usr/bin/logger -t "LoadAverageCustomCheck"
  +
  +
  +
sleep 60
  +
done
  +
</PRE>
  +
  +
Скрипт запускаем в фоне, через некоторое время видим что-то вроде такого
  +
<PRE>
  +
mon-get-stats LoadAverage --statistics "Average,Minimum,Maximum" --namespace "CustomMetric" --region us-west-2
  +
2012-11-12 09:50:00 0.29 0.29 0.29 None
  +
2012-11-12 09:51:00 0.24 0.24 0.24 None
  +
2012-11-12 09:53:00 0.21 0.21 0.21 None
  +
2012-11-12 09:54:00 0.19 0.19 0.19 None
  +
2012-11-12 09:55:00 0.16 0.16 0.16 None
  +
2012-11-12 09:56:00 0.14 0.14 0.14 None
  +
2012-11-12 09:57:00 0.14 0.14 0.14 None
  +
2012-11-12 09:58:00 0.13 0.13 0.13 None
  +
2012-11-12 09:59:00 0.1 0.1 0.1 None
  +
2012-11-12 10:00:00 0.12 0.12 0.12 None
  +
2012-11-12 10:01:00 0.1 0.1 0.1 None
  +
2012-11-12 10:02:00 0.1 0.1 0.1 None
  +
2012-11-12 10:03:00 0.1 0.1 0.1 None
  +
2012-11-12 10:04:00 0.08 0.08 0.08 None
  +
2012-11-12 10:05:00 0.07 0.07 0.07 None
  +
</PRE>
  +
  +
==Тестирование==
  +
Самая важная часть.
  +
<BR>
  +
нагрузку создать было не сложно - все инстансы "микро".
  +
<BR>
  +
Просматриваю Алармы:
  +
<PRE>
  +
mon-describe-alarm-history --region us-west-2
  +
HighLoadAvAlarm 2012-11-12T12:15:44.089Z StateUpdate Alarm updated from ALARM to OK
  +
HighLoadAvAlarm 2012-11-12T11:38:44.106Z Action Successfully executed action arn:aws:autoscaling:us-west-2:371025327760:scalingPolicy:ffc0f83b-4cfd-4a41-8ca4-b1ebcc87094a:autoScalingGroupName/test-scaling-group:policyName/TestScaleUpPolicy
  +
HighLoadAvAlarm 2012-11-12T11:38:44.087Z StateUpdate Alarm updated from OK to ALARM
  +
LoLoadAvAlarm 2012-11-12T11:36:37.657Z StateUpdate Alarm updated from ALARM to OK
  +
LoLoadAvAlarm 2012-11-12T11:25:17.484Z Action Successfully executed action arn:aws:autoscaling:us-west-2:371025327760:scalingPolicy:9f0c2e09-6edb-435b-8660-70ba8f6ffe89:autoScalingGroupName/test-scaling-group:policyName/ScaleDownPolicy
  +
LoLoadAvAlarm 2012-11-12T11:25:17.458Z StateUpdate Alarm updated from INSUFFICIENT_DATA to ALARM
  +
LoLoadAvAlarm 2012-11-12T11:25:16.863Z ConfigurationUpdate Alarm "LoLoadAvAlarm" created
  +
HighLoadAvAlarm 2012-11-12T11:24:09.169Z StateUpdate Alarm updated from INSUFFICIENT_DATA to OK
  +
HighLoadAvAlarm 2012-11-12T11:24:08.580Z ConfigurationUpdate Alarm "HighLoadAvAlarm" created
  +
</PRE>
  +
Как я понимаю - LoLoadAlarm видит что загрузка меньше уровня но ничего изначально не удаляет - нечего.
  +
<BR>
  +
После того как нагрузка снята:
  +
<PRE>
  +
mon-describe-alarm-history --region us-west-2 | grep "LoLoadAvAlarm" | head
  +
LoLoadAvAlarm 2012-11-12T12:18:37.681Z Action Successfully executed action arn:aws:autoscaling:us-west-2:371025327760:scalingPolicy:9f0c2e09-6edb-435b-8660-70ba8f6ffe89:autoScalingGroupName/test-scaling-group:policyName/ScaleDownPolicy
  +
LoLoadAvAlarm 2012-11-12T12:18:37.668Z StateUpdate Alarm updated from OK to ALARM
  +
LoLoadAvAlarm 2012-11-12T11:36:37.657Z StateUpdate Alarm updated from ALARM to OK
  +
</PRE>
  +
Один из инстансов удален. Второй еще работает.
   
 
==Ссылки==
  
==Ссылки==
Строка 85: Строка 419:
   
 
===масштабирование===
  
===масштабирование===
  +
* http://www.munzandmore.com/2012/amazon/aws-autoscaling
 
* http://habrahabr.ru/company/epam_systems/blog/138732/
  
* http://habrahabr.ru/company/epam_systems/blog/138732/
  +
* http://www.thatsgeeky.com/2012/01/autoscaling-with-custom-metrics/

Текущая версия на 16:34, 28 февраля 2013

Amazon EC2

Задача: Есть некое приложение которое легко масштабируется. Задача - добавлать сервера в кластер при росте нагрузки и удалять при падении нагрузки автоматически. Метрика - результат работы скрипта, т.е. отличная от стандартных.

Введение

Для работы нужно РПМки поставить: (yum, epel от амазона.) 

# rpm -qa | grep aws
aws-apitools-ec2-1.6.3.0-1.0.amzn1.noarch
aws-scripts-ses-2012.07.09-1.0.amzn1.noarch
aws-apitools-iam-1.5.0-1.2.amzn1.noarch
aws-apitools-elb-1.0.17.0-1.4.amzn1.noarch
aws-cfn-bootstrap-1.3-6.amzn1.noarch
aws-amitools-ec2-1.4.0.7-1.4.amzn1.noarch
aws-apitools-common-1.1.0-1.7.amzn1.noarch
aws-apitools-as-1.0.61.1-1.0.amzn1.noarch
aws-apitools-rds-1.10.002-1.1.amzn1.noarch
aws-apitools-mon-1.0.13.4-1.0.amzn1.noarch

в ~/.bashrc (у меня под рутом) 

export EC2_PRIVATE_KEY=$HOME/keys/nocrypt-ec2-key.pem
export EC2_CERT=$HOME/keys/ec2_cert.pem
export JAVA_HOME=/usr/lib/jvm/jre-1.6.0-openjdk.x86_64/

ключи ec2-key - см. ниже (в моем случае они УЖЕ были сгенерированы)


Создание X.509 сертификата для аутентификации в Amazon AWS

  • Идем в http://aws.amazon.com/account/
  • Выбираем вкладку «Security Credentials»
  • Проходим аутентификацию (email и пароль)
  • Под заголовком «Access Credentials» выбираем вкладку «X.509 Certificates»
  • Нажимаем кнопку/ссылку «Create a new Certificate»
  • В открывшемся окне загружаем приватный ключ и сертификат. Обратите внимание что Amazon не хранит секретный ключ, поэтому скачать его надо здесь и сейчас.

Создание пары AWS Access ID и AWS Secret key аутентификации в Amazon AWS

  • Идем в http://aws.amazon.com/account/
  • Выбираем вкладку «Security Credentials»
  • Проходим аутентификацию (email и пароль)
  • Под заголовком «Access Credentials» выбираем вкладку «Access Keys»
  • Нажимаем кнопку/ссылку «Create a new Access Key»
  • В открывшемся окне загружаем access key и secret access key. Обратите внимание что Amazon не хранит секретный ключ, поэтому скачать его надо здесь и сейчас.


Внимание! нужно преобразовать ключ - с оригинальным работают не все утилиты!!!! 

openssl pkcs8 -topk8 -in ec2-key.pem -nocrypt > nocrypt-ec2-key.pem

ssh keys

После подключения сертефикатов - начинают работать ec2-утилиты Например:

Просмотр ключей

#ec2-describe-keypairs 
KEYPAIR	key001	xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
KEYPAIR	key002	xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
KEYPAIR	key003	xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
KEYPAIR	key004	xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
KEYPAIR	key005	xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
KEYPAIR	key006	xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx

Регион указывать явно! Ключи работают только в пределах региона! 

# ec2-describe-keypairs --region us-west-2 
KEYPAIR	key1	xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
KEYPAIR	key2	xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
KEYPAIR	key3	xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx

Создание ключей

cd ~/.ssh
ec2-add-keypair --region us-west-2 new_key > new_key.pem 
chmod 600  new_key.pem

Работа с инстансами (VM)

Создать instance

Мне нужен Amazon Linux, пока я не знаю где смотреть полный список возможных образов - указал как на уже существующем инстансе (чуть ниже немного деталей где смотреть, этот вопрос под сомнением) 

ec2-run-instances ami-2a31bf1a --instance-type t1.micro --region us-west-2 --key keyName

RESERVATION	r-6dd5865e	371025327760	default
INSTANCE	i-d71c11e4	ami-2a31bf1a			pending	hcluster	0		t1.micro	2012-11-09T12:22:56+0000	us-west-2a	aki-fc37bacc			monitoring-disabled			ebs					paravirtual	xen		sg-c6dc4df6	default	false

Обратить внимание: keyName это указатель на существующий ключ, и потому никакого расширения. Во многих источника я встречал keyName.pem - это ошибка

Параметры:

  • ami-2a31bf1a – Идентификатор AMI образа. Определяет какая операционная система будет установлена на EC2 instance.
  • --instance-type t1.micro – Какой величины будет instance. см. Варианты EC2 хостов
  • --region eu-west-1 – регион где будет создан instance.
  • --key test123.pem – Ключ который будет использоваться для доступа по ssh к instance.

Как то так смотреть список id: 

ec2-describe-images -o amazon --region us-west-2 | grep "amzn-ami-pv"

Или тут что то есть http://aws.amazon.com/amazon-linux-ami/

Список instances в регионе

ec2-describe-instances --region us-east-1

Удалить instance

ec2-terminate-instances instance_id

instance_id можно посмотреть с помощью команды ec2-describe-instances.

Перезагрузка ec2 instance

ec2-reboot-instances

для ec2 instance идентична мягкой перезагрузке для обычного компьютера. Если попытка мягкой перезагрузки потерпит крах, возможна жесткая перезагрузка. Для instances с EBS 100% безопасно. Полезно если instance завис по каким то причинам. 

ec2-reboot-instances --region eu-west-1 instance_id

instance_id можно посмотреть с помощью команды ec2-describe-instances.

Создание/просмотр/удаление tags

С помощью tags можно помечать instance, во избежании обретения кучи безымянных instances загадочного назначения.

Просмотр tags в регионе

ec2-describe-tags --region us-west-2

Создание tags

ec2-create-tags --region eu-west-1 instance_id --tag key[=value] [--tag key[=value]]

instance_id можно посмотреть с помощью команды ec2-describe-instances. удобно создавать tags вроде: 

ec2-create-tags --region us-west-2 instance_id --tag Name=site_testing_area --tag Creator=employee1
Пример

Нахожу свой инстанс: 

ec2-describe-instances --region us-west-2 
....
RESERVATION	r-6dd5865e	371025327760	default
INSTANCE	i-d71c11e4	ami-2a31bf1a	ec2-50-112-212-246.us-west-2.compute.amazonaws.com	ip-10-248-15-79.us-west-2.compute.internal	running	hcluster	0		t1.micro	2012-11-09T12:22:56+0000	us-west-2a	aki-fc37bacc			monitoring-disabled	50.50.50.50	10.10.10.10			ebs					paravirtual	xen		sg-c6dc4df6	default	false	
BLOCKDEVICE	/dev/sda1	vol-83dbd1a5	2012-11-09T12:22:59.000Z	true		
....

ec2-create-tags --region us-west-2 i-d71c11e4 --tag Name=TestNode

Удаление tags

ec2-delete-tags --region eu-west-1 instance_id --tag clumsytag

Конфигурация инстанса

Я хочу наконфиггурировать инстанс паппетом, хотя эта часть статьи выходит за пределы EC2, потому - обзорно. Сервер puppet у меня уже есть, подробностей минимум.
На ноде необходимо установить:

  • tomcat7
  • nginx
  • syslog-ng вместо rsyslog (rsyslog мне кажется неудобным но многие с этим не согласны - дело вкуса).
  • настроить пересылку логов на ценральное хранилище (инстансы подобные этому могут добавлятся и улдалятся автоматически, ничего не хранить локально)
  • актуальная конфигурация (паппет запускается раз в X минут и делает все что нужно)

Наброски манифеста

class nginx-tomcat-lb {

    package {
        "nginx":
        ensure => installed
    }


    package {
        "tomcat7":
        ensure => installed
    }


    file { "/etc/nginx/nginx.conf":
        ensure => present,
        owner => "root",
        group => "root",
        alias => "nginx-config",
        content => template("nginx-tomcat-lb/nginx_conf.erb"),
        require => Package["nginx"],
        notify  => Service["nginx"],
        }

    service { 
        "nginx":
        ensure => running,
        subscribe => File[nginx-config]
    }

    service { 
        "tomcat7":
        ensure => running,
    }
}

Load Balancer

Для управление лоад балансерами используются elb- утилиты

Просмотр балансеров

elb-describe-lbs 
LOAD_BALANCER  lb-test1    test1-1812564742.us-east-1.elb.amazonaws.com          2012-07-06T08:39:01.940Z  internet-facing
LOAD_BALANCER  lb-dev1     dev1-1835033989.us-east-1.elb.amazonaws.com           2012-07-09T12:52:11.290Z  internet-facing

elb-describe-lbs   --region us-west-2 
LOAD_BALANCER  lb-west  lb-west-1263536513.us-west-2.elb.amazonaws.com  2012-11-06T18:51:54.560Z  internet-facing

Добавить балансер

elb-create-lb  test-lb --headers --listener "lb-port=80,instance-port=80,protocol=http" --availability-zones us-west-2a  --region us-west-2
DNS_NAME  DNS_NAME
DNS_NAME  test-lb-1678700173.us-west-2.elb.amazonaws.com

Следить за --availability-zones us-west-2a - балансер работает внутри зоны!

Добавить инстанс под балансер

elb-register-instances-with-lb test-lb  --instances i-d71c11e4
elb-register-instances-with-lb:  Service error: There is no ACTIVE Load Balancer named 'test-lb' 
 AWSRequestId:b74a0d60-2a75-11e2-9b12-73ca28379447

Не забывать про регион! 

#elb-register-instances-with-lb test-lb  --instances i-d71c11e4 --region us-west-2
INSTANCE_ID  i-d71c11e4

Снять образ

ec2-create-image i-d71c11e4  --no-reboot -n 'MyImageName' -d 'Description' --region us-west-2
IMAGE	ami-180a8328

создать launch-config

as-create-launch-config test-launch-config -i ami-180a8328 --key=sshkey  --group default  --instance-type t1.micro --region us-west-2 
OK-Created launch config
  • test-launch-config - имя конфига
  • sshkey — ssh kлючь с которым логинится на сервер
  • group — секьюрити группа, в которой будут подыматься серверы. У меня (т.к. это только тест ) - дефолтная группа

Автоскейлинг группа

Везде помнить про регион! и про --availability-zones us-west-2 - это разные вещи!!! 

as-create-auto-scaling-group test-scaling-group -l test-launch-config --availability-zones us-west-2a --min-size 0 --max-size 2 --load-balancers test-lb --region us-west-2 
OK-Created AutoScalingGroup

Здесь:

  • test-launch-config — конфиг (см. чуть выше)
  • us-west-2a — зона, в которой будут подыматься инстансы Внимание - проверить что бы лоад балансер мог работать с этой зоной!
  • 0 и 2 — минимальный и максимальный размеры группы соответственно;
  • test-lb — имя вашего балансировщика, под которым будет поднята вся группа.


Итак, готова группа масштабирования и балансировщик.
Теперь нужно настроить CloudWatch алармы.
Автомасштабирование, основанное на CloudWatch работает через политику — policy, которая задаётся.
Примером политики является увеличение кол-ва интансов на 1. Т.е. сначала мы задаём политику, потом мы создаём аларм, который, например, срабатывает при Load Average больше X на протяжении минуты.
Важный момент - если нужно поменять образ из которого разворачивать ноды, то можно содать новый launch-config а потом поредактировать auto-scaling-group 

as-update-auto-scaling-group  test-scaling-group --launch-configuration  new-test-launch-config --availability-zones us-west-2a --min-size 0 --max-size 2  --region us-west-2

Политика скейл апа

as-put-scaling-policy TestScaleUpPolicy --auto-scaling-group test-scaling-group --adjustment=1 --type ChangeInCapacity --cooldown 120 --region us-west-2
arn:aws:autoscaling:us-west-2:371025327760:scalingPolicy:09327221-3746-4575-afe7-49e0b7aff67b:autoScalingGroupName/test-scaling-group:policyName/TestScaleUpPolicy

Здесь:

  • --type ChangeInCapacity - изменения размера, тип политики
  • --adjustment=1 — +1 хост к группе
  • --cooldown 120 — на протяжении 2 минут все алармы будут игнорироваться и новые инстансы подняты не будут

Аларм для скейл апа

mon-put-metric-alarm HighLoadAvAlarm --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --metric-name LoadAverage --namespace CustomMetric --period 60 --statistic Average --threshold 3 --alarm-actions arn:aws:autoscaling:us-west-2:371025327760:scalingPolicy:09327221-3746-4575-afe7-49e0b7aff67b:autoScalingGroupName/test-scaling-group:policyName/TestScaleUpPolicy  --region us-west-2
OK-Created Alarm

Здесь:

  • --comparison-operator GreaterThanOrEqualToThreshold — оператор >= чем трешхолд.
  • --evaluation-periods 1 — срабатывает с первого раза
  • --metric-name LoadAverage --namespace CustomMetric — наша кастомная метрика
  • --period 60 — минута на срабатывание
  • --statistic Average — подсчитывается среднее значение
  • --threshold 3 — Load Average не больше 3
  • --alarm-actions — какая политика. (см выше - ее идентификатор выдается при создании)

Политика скейл дауна

as-put-scaling-policy ScaleDownPolicy --auto-scaling-group test-scaling-group --adjustment=-1 --type ChangeInCapacity --cooldown 420 --region us-west-2
arn:aws:autoscaling:us-west-2:371025327760:scalingPolicy:88929ef9-73c2-43c4-88b0-2a5999089976:autoScalingGroupName/test-scaling-group:policyName/ScaleDownPolicy

Здесь кулдаун больше. После даунскейла инстансы группа не даунскейлится ещё минимум 6 минут. Ну и adjustment=-1.

Аларм для скейл дауна:

mon-put-metric-alarm LoLoadAvAlarm --comparison-operator LessThanThreshold --evaluation-periods 1 --metric-name LoadAverage --namespace CustomMetric --period 120 --statistic Average --threshold 2 --alarm-actions arn:aws:autoscaling:us-west-2:371025327760:scalingPolicy:88929ef9-73c2-43c4-88b0-2a5999089976:autoScalingGroupName/test-scaling-group:policyName/ScaleDownPolicy --region us-west-2 
OK-Created Alarm

Здесь аларм срабатывает, если больше 2 минут Load Average был меньше 2.

Ну вот и всё. Итак, теперь в зависимости от нагрузки, наша скейл группа сможет разрастаться до 3х инстансов и 1 всегда будет жив. Здесь рассмотрен простейший пример автоскейлинга. Естественно, можно менять условия и баловаться с цифрами по своему усмотрению.

Посмотреть политики

as-describe-policies  --region   us-west-2

Посмотреть алармы

mon-describe-alarms --region us-west-2
HighLoadAvAlarm  OK     arn:aws:autoscalin...e/TestScaleUpPolicy  CustomMetric  LoadAverage  60   Average  1  GreaterThanOrEqualToThreshold  3.0
LoLoadAvAlarm    ALARM  arn:aws:autoscalin...ame/ScaleDownPolicy  CustomMetric  LoadAverage  120  Average  1  LessThanThreshold              2.0

Custom checks

Теперь создадим скрипт который собвственно и будет выполнять проверку нагрузки. Во многих документах по масштабированию кластеров этот момент почему-то не описан, т.е. предпологается что этот скриапт существует и отдает данные. Насколько я могу судить, кастомнвй чем позволяеи отдавать что угодно в качестве метрики, я взял традиционно простейший LoadAverage
Цена за каждый такой чек - 50 центов в мес. Отключить чек нельзя, он удалится сам через 2 недели если его не использовать, т.е. не засылать новые данные 

#!/bin/bash

export AWS_CLOUDWATCH_HOME=/opt/aws/apitools/mon-1.0.13.4
export AWS_CLOUDWATCH_URL=https://monitoring.amazonaws.com
export PATH=AWS_CLOUDWATCH_HOME/bin:${PATH}
export EC2_PRIVATE_KEY=/root/keys/nocrypt-ec2-key.pem
export EC2_CERT=/root/keys/ec2_cert.pem
export JAVA_HOME=/usr/lib/jvm/jre-1.6.0-openjdk.x86_64/

while [ true ]; do
load_average=`cat /proc/loadavg  | awk '{ print $2}'`

timestamp=`date -u +%Y-%m-%dT%H:%M:%S.000Z`


mon-put-data --metric-name "LoadAverage" --namespace "CustomMetric" --timestamp $timestamp --value $load_average  --region  us-west-2

echo "$timestamp: Load Average $load_average" | /usr/bin/logger -t "LoadAverageCustomCheck"


sleep 60
done

Скрипт запускаем в фоне, через некоторое время видим что-то вроде такого 

mon-get-stats LoadAverage  --statistics "Average,Minimum,Maximum" --namespace "CustomMetric"  --region  us-west-2 
2012-11-12 09:50:00  0.29  0.29  0.29  None
2012-11-12 09:51:00  0.24  0.24  0.24  None
2012-11-12 09:53:00  0.21  0.21  0.21  None
2012-11-12 09:54:00  0.19  0.19  0.19  None
2012-11-12 09:55:00  0.16  0.16  0.16  None
2012-11-12 09:56:00  0.14  0.14  0.14  None
2012-11-12 09:57:00  0.14  0.14  0.14  None
2012-11-12 09:58:00  0.13  0.13  0.13  None
2012-11-12 09:59:00  0.1   0.1   0.1   None
2012-11-12 10:00:00  0.12  0.12  0.12  None
2012-11-12 10:01:00  0.1   0.1   0.1   None
2012-11-12 10:02:00  0.1   0.1   0.1   None
2012-11-12 10:03:00  0.1   0.1   0.1   None
2012-11-12 10:04:00  0.08  0.08  0.08  None
2012-11-12 10:05:00  0.07  0.07  0.07  None

Тестирование

Самая важная часть.
нагрузку создать было не сложно - все инстансы "микро".
Просматриваю Алармы: 

mon-describe-alarm-history --region us-west-2
HighLoadAvAlarm  2012-11-12T12:15:44.089Z  StateUpdate          Alarm updated from ALARM to OK
HighLoadAvAlarm  2012-11-12T11:38:44.106Z  Action               Successfully executed action arn:aws:autoscaling:us-west-2:371025327760:scalingPolicy:ffc0f83b-4cfd-4a41-8ca4-b1ebcc87094a:autoScalingGroupName/test-scaling-group:policyName/TestScaleUpPolicy
HighLoadAvAlarm  2012-11-12T11:38:44.087Z  StateUpdate          Alarm updated from OK to ALARM
LoLoadAvAlarm    2012-11-12T11:36:37.657Z  StateUpdate          Alarm updated from ALARM to OK
LoLoadAvAlarm    2012-11-12T11:25:17.484Z  Action               Successfully executed action arn:aws:autoscaling:us-west-2:371025327760:scalingPolicy:9f0c2e09-6edb-435b-8660-70ba8f6ffe89:autoScalingGroupName/test-scaling-group:policyName/ScaleDownPolicy
LoLoadAvAlarm    2012-11-12T11:25:17.458Z  StateUpdate          Alarm updated from INSUFFICIENT_DATA to ALARM
LoLoadAvAlarm    2012-11-12T11:25:16.863Z  ConfigurationUpdate  Alarm "LoLoadAvAlarm" created
HighLoadAvAlarm  2012-11-12T11:24:09.169Z  StateUpdate          Alarm updated from INSUFFICIENT_DATA to OK
HighLoadAvAlarm  2012-11-12T11:24:08.580Z  ConfigurationUpdate  Alarm "HighLoadAvAlarm" created

Как я понимаю - LoLoadAlarm видит что загрузка меньше уровня но ничего изначально не удаляет - нечего.
После того как нагрузка снята: 

mon-describe-alarm-history --region us-west-2 | grep "LoLoadAvAlarm" | head 
LoLoadAvAlarm    2012-11-12T12:18:37.681Z  Action               Successfully executed action arn:aws:autoscaling:us-west-2:371025327760:scalingPolicy:9f0c2e09-6edb-435b-8660-70ba8f6ffe89:autoScalingGroupName/test-scaling-group:policyName/ScaleDownPolicy
LoLoadAvAlarm    2012-11-12T12:18:37.668Z  StateUpdate          Alarm updated from OK to ALARM
LoLoadAvAlarm    2012-11-12T11:36:37.657Z  StateUpdate          Alarm updated from ALARM to OK

Один из инстансов удален. Второй еще работает.

Ссылки

масштабирование

Источник — https://noname.com.ua/mediawiki/index.php?title=EC2&oldid=6301