Разводить и умирать экземпляры AWS без видимой причины
Это произошло пару раз с тех пор, как мы перевели наш кластерный проект с Google на AWS.
У нас есть том EFS, смонтированный на кластере с балансировкой нагрузки в проекте Beanstalk.
Я буду в процессе настройки чего-либо, загружая большой ZIP-файл на этот том EFS (через экземпляр в кластере с балансировкой нагрузки), или разархивирую один из сеанса ssh на экземпляре кластера, и я внезапно найду экземпляр вырвался из-под меня и обнаружил, что кластер породил два (или более) новых экземпляра и закрывает тот, к которому я обращался.
Что здесь происходит? Все экземпляры являются экземплярами "t2-micro"; они неадекватны устойчивой нагрузке и исчерпывают взрывную мощность? Кто-нибудь видел что-нибудь подобное?
1 ответ
Итак, вы получили это t2.micro в группе автоматического масштабирования (ASG) я предполагаю?
И этот ASG настроен для увеличения / уменьшения в зависимости от средней загрузки процессора?
Вы перегружаете его большими операциями с ZIP-файлами, исчерпываете кредиты ЦП, CloudWatch замечает, что средняя загрузка ЦП превышает пороговое значение, и запускает новый экземпляр. Как и ожидалось.
Это снижает среднюю загрузку ЦП, и ASG завершает самый продолжительный экземпляр (тот, над которым вы работаете). Также, как и ожидалось.
Я предполагаю, что ваши пороги масштабирования вверх / вниз слишком близки друг к другу (возможно, у вас есть масштабирование при нагрузке> 60% и уменьшение при загрузке < 50%) - настройте больший зазор, например, 60% / 30%),
Не перегружайте T2/T3, не используйте T2/T3 Unlimited или используйте другой тип экземпляра, такой как M4, M5 или C5, который не использует кредиты ЦП и обеспечивает стабильную производительность.
Относитесь к экземплярам в ASG как к неизменным - вам никогда не нужно входить в систему к экземпляру в ASG, все их настройки должны выполняться автоматически с помощью скриптов Launch Config. Потому что вы никогда не знаете, когда они начинаются или останавливаются.
Надеюсь, это поможет:)