Comments 9
ето скорее свободньій пересказ документации Amazon, но мне понравилось что вся цепочка описана в одном документе. Мне в свое время пришлось написать похожую простьіню для себя :)
Немного помогу — у вас там ошибки в определении метрик "--metric-name Latency --namespace «AWS/EC2» --period 600 --statistic SampleCount --threshold 20":
1. --metric-name Latency относится к пространству имен «AWS/ELB» а не «AWS/EC2».
2. --dimensions «AutoScalingGroupName=myASG». сдесь нужно указьівать ваш LB а не AS Group, --dimensions «LoadBalancerName=myLB».
3. --statistics SampleCount. если вам нужно знать именно задержку (latency) в мс, тогда нужно использовать "--statistic Average", так так SampleCount даст вам количество запросов к LB за указаньій период "--period 600", тоесть фактически будет равен значению "--statistics RequestCount".
Немного помогу — у вас там ошибки в определении метрик "--metric-name Latency --namespace «AWS/EC2» --period 600 --statistic SampleCount --threshold 20":
1. --metric-name Latency относится к пространству имен «AWS/ELB» а не «AWS/EC2».
2. --dimensions «AutoScalingGroupName=myASG». сдесь нужно указьівать ваш LB а не AS Group, --dimensions «LoadBalancerName=myLB».
3. --statistics SampleCount. если вам нужно знать именно задержку (latency) в мс, тогда нужно использовать "--statistic Average", так так SampleCount даст вам количество запросов к LB за указаньій период "--period 600", тоесть фактически будет равен значению "--statistics RequestCount".
Да, со всем абсолютно согласен, и это как раз и есть моя «простыня», которую делал вообщем-то для себя изначально.
Исправил всё, как вы посоветовали. По п.2. — можно и так и так, но пожалуй правильней действительно будет мерять на ELB. Хотя в амазоновской документации везде как раз фильтруется по ASG почему-то.
Исправил всё, как вы посоветовали. По п.2. — можно и так и так, но пожалуй правильней действительно будет мерять на ELB. Хотя в амазоновской документации везде как раз фильтруется по ASG почему-то.
п.2 — можно по разному, но правильно будет все равно по-моему :)
Метрика Latency доступна только в namespace «AWS/ELB», для которого, в свою очередь, доступньі только два dimension: «LoadBalancerName, AvailabilityZone».
При создании mon-put-metric-alarm — metric-name, namespace и dimensions должньі соответствовать друг другу, иначе вьі получите в ответ значение 'unknown' и Alarm state 'INSUFFICIENT_DATA'.
Посмотрите сдесь (хороший документ, кстати) docs.amazonwebservices.com/AmazonCloudWatch/latest/DeveloperGuide/CW_Support_For_AWS.html
В документации приводится использование метрики CPUUtilization — вот для нее-то как раз --namespace «AWS/EC2» и --dimensions «AutoScalingGroupName=MyASG»
Метрика Latency доступна только в namespace «AWS/ELB», для которого, в свою очередь, доступньі только два dimension: «LoadBalancerName, AvailabilityZone».
При создании mon-put-metric-alarm — metric-name, namespace и dimensions должньі соответствовать друг другу, иначе вьі получите в ответ значение 'unknown' и Alarm state 'INSUFFICIENT_DATA'.
Посмотрите сдесь (хороший документ, кстати) docs.amazonwebservices.com/AmazonCloudWatch/latest/DeveloperGuide/CW_Support_For_AWS.html
В документации приводится использование метрики CPUUtilization — вот для нее-то как раз --namespace «AWS/EC2» и --dimensions «AutoScalingGroupName=MyASG»
Интересует, как Вы собираетесь обновлять код проекта на уже запущенной группе, хотя бы из двух инстансов?
Тоже сейчас изучаю варианты масштабирования проекта в AWS. Добавлю несколько ссылок:
docs.amazonwebservices.com/gettingstarted/latest/wah-linux/web-app-hosting-intro.html
cloudblog.8kmiles.com/2011/12/09/autoscale-wordpress-with-ease-using-amazon-cloud/
cloudblog.8kmiles.com/2011/04/20/auto-scaling-using-amazon-web-services/
Тоже сейчас изучаю варианты масштабирования проекта в AWS. Добавлю несколько ссылок:
docs.amazonwebservices.com/gettingstarted/latest/wah-linux/web-app-hosting-intro.html
cloudblog.8kmiles.com/2011/12/09/autoscale-wordpress-with-ease-using-amazon-cloud/
cloudblog.8kmiles.com/2011/04/20/auto-scaling-using-amazon-web-services/
Ну собственно не такая большая проблема. Код нужно обновлять в двух случаях — когда стартует новый инстанс (вдруг что-то изменилось), и когда собственно программисты решают задеплоить новый код.
В первом случае деплой прописывается в автозагрузку, а во втором всё решает скрипт, который дёргает Amazon API, смотрит какие инстансы сейчас у нас запущены на Amazone и деплоит на них по списку. Конечно есть разные инстансы с разными ролями, но мы на те инстансы, на которые не надо деплоить вешаем специальный тег (так получилось что они у нас фиксированные).
Для того чтобы у инстанса было время на деплой приложения при стартапе, мы указываем ключ --grace-period при создании политики роста пула, и в это время инстанс не дёргается через балансировщик.
В первом случае деплой прописывается в автозагрузку, а во втором всё решает скрипт, который дёргает Amazon API, смотрит какие инстансы сейчас у нас запущены на Amazone и деплоит на них по списку. Конечно есть разные инстансы с разными ролями, но мы на те инстансы, на которые не надо деплоить вешаем специальный тег (так получилось что они у нас фиксированные).
Для того чтобы у инстанса было время на деплой приложения при стартапе, мы указываем ключ --grace-period при создании политики роста пула, и в это время инстанс не дёргается через балансировщик.
В принципе для первого случая, после обновления системы можно обновлять снепшот AMI. В таком случае при старте нового инстанса ничего проверять не нужно.
Интересный вариант во второй моей ссылке — код проекта монтируется при старте инстанса по сети. Из плюсов обновлять надо только один инстанс, изменения сразу же доступны на всех запущенных инстансах.
В данной схеме смущает только один момент, насколько медленней будет чтение с сетевой ФС особенно при росте кол-ва инстансов в группе. Как вариант вместо сетевой ФС можно монтировать S3 бакет с помощью s3fs, но думаю будет медленно и дорого.
Возможно остановлюсь и на Вашем варианте, спасибо.
Интересный вариант во второй моей ссылке — код проекта монтируется при старте инстанса по сети. Из плюсов обновлять надо только один инстанс, изменения сразу же доступны на всех запущенных инстансах.
В данной схеме смущает только один момент, насколько медленней будет чтение с сетевой ФС особенно при росте кол-ва инстансов в группе. Как вариант вместо сетевой ФС можно монтировать S3 бакет с помощью s3fs, но думаю будет медленно и дорого.
Возможно остановлюсь и на Вашем варианте, спасибо.
второй вариант ето, в случае c облаком, антипаттерн.
Идея auto-scaling том чтобьі обеспечить вьісокую производительность и(или) доступность.
А мьі, желая упростить жизнь себе, добавляем еще один SPOF (у нас ведь уже есть MySQL) к архитектуре, понижая доступность, и в какой-то мемент упремся в сеть, которая, к слову сказать, имеет непостоянную производительность.
На инстансьі нужно смотреть как на расходньій материал. Упал? Недоступен? ну и хрен с ним, некогда разбираться, прикончили его бьістренько (terminate),
и запустили новьй, которьій при старте прочел настройки (user-data, cloud-init) и сам себя задеплоил (chef/puppet/mycustomscript).
Обновление кода на работающих инстансах — все просто, используем АРІ для получения списка инстансов (например список всех инстансов в конкретном лоадбалансере у которьіх статус InService
# elb-describe-instance-health myLB --headers
INSTANCE_ID INSTANCE_ID STATE DESCRIPTION REASON-CODE
INSTANCE_ID i-742e0216 InService N/A N/A
INSTANCE_ID i-4e23352e UnHealthy N/A N/A
Дополнительно можно использовать тег, например если нужно проапдейтить не все инстансьі а определенную часть.
Конечно же, можно делать снепшот AMI каждьій раз если вам так удобно или необходимо. Только нужно еще дополнительно cоздавать launch-configuration и обновлять auto-scaling group property каждьій раз.
Иногда такой подход оправдан, но если есть возможность — лучше все-таки стремиться к автоматическому deployment при старте инстанса.
Идея auto-scaling том чтобьі обеспечить вьісокую производительность и(или) доступность.
А мьі, желая упростить жизнь себе, добавляем еще один SPOF (у нас ведь уже есть MySQL) к архитектуре, понижая доступность, и в какой-то мемент упремся в сеть, которая, к слову сказать, имеет непостоянную производительность.
На инстансьі нужно смотреть как на расходньій материал. Упал? Недоступен? ну и хрен с ним, некогда разбираться, прикончили его бьістренько (terminate),
и запустили новьй, которьій при старте прочел настройки (user-data, cloud-init) и сам себя задеплоил (chef/puppet/mycustomscript).
Обновление кода на работающих инстансах — все просто, используем АРІ для получения списка инстансов (например список всех инстансов в конкретном лоадбалансере у которьіх статус InService
# elb-describe-instance-health myLB --headers
INSTANCE_ID INSTANCE_ID STATE DESCRIPTION REASON-CODE
INSTANCE_ID i-742e0216 InService N/A N/A
INSTANCE_ID i-4e23352e UnHealthy N/A N/A
Дополнительно можно использовать тег, например если нужно проапдейтить не все инстансьі а определенную часть.
Конечно же, можно делать снепшот AMI каждьій раз если вам так удобно или необходимо. Только нужно еще дополнительно cоздавать launch-configuration и обновлять auto-scaling group property каждьій раз.
Иногда такой подход оправдан, но если есть возможность — лучше все-таки стремиться к автоматическому deployment при старте инстанса.
Помимо амазоновского сервиса автомасштабирования, есть (как минимум) 2 сервиса, которые позволяют это делать на амазоне сильно умнее (scalr.com, alestic.com). Умнее в том, что есть интеграция с ПО на инстансах (если это mysql, то будет подниматься репликация, если apache, то автоматически будет добавляться к фронтенду в список бэкендов)
Sign up to leave a comment.
Балансировщик нагрузки для Amazon EC2 c автомасштабированием