Уокер, я бы порекомендовал вам начать с предварительной подготовки серверов, а затем запускать и останавливать их с помощью сценариев, запускаемых решением для мониторинга. После того, как вы сможете последовательно развертывать утвержденные по качеству серверы в автоматическом режиме, вам все равно потребуется около 15-20 минут для создания сервера. Так или иначе, вам понадобятся ресурсы, чтобы быть готовыми, когда они вам понадобятся.
Как только у вас появится арсенал серверов, самое время подготовить решение для мониторинга. Nagios отлично подойдет для этой задачи. Любое решение для мониторинга, которое может реагировать на события с помощью триггеров и т. Д. Будет работать.
Есть несколько способов масштабирования, понимание того, как управлять использованием.
Использование
Это уникальный проект для нас, это агрегированный показатель загрузки системы / запросов в секунду + IO. По крайней мере, рассмотрим среднюю нагрузку. В нашем сценарии мы хотели понять, что делает наши системы более загруженными, и разработали собственные меры по их использованию. Который мы подключили в специальное решение для мониторинга. Использование мер, когда мы должны увеличить или уменьшить.
Увеличение
Включает масштабирование на более крупный сервер для обслуживания запросов, это буквально означает, что для обработки запросов на серверах вам необходимо перейти на более крупные серверы. Или, если подумать иначе, стоимость запроса будет уменьшена, если он будет обрабатываться на более крупном сервере.
По моему опыту, потребность в расширении в краткосрочной перспективе уменьшается. Если
вам постоянно требуется минимальный сервер спецификации для обработки нагрузки
тогда вы должны увидеть средний уровень использования. Однажды
уровень использования составляет около 60%, его время, чтобы начать
увеличение.
Увеличение может быть дорогостоящим, поэтому, если у вас пики нагрузки, вам, вероятно, лучше просто добавить другой сервер в пул, вот как работает Scaling Out .
Масштабирование
Для большинства проектов в краткосрочной перспективе более распространено масштабирование, процесс включает добавление большего количества хостов в среду и распределение запросов с использованием балансировщика нагрузки. Когда уровень использования достигает 60% или более, триггер в вашем решении для мониторинга запускает запрос, который запускает хост. Когда нагрузка возвращается к медиана , решение для мониторинга отключает серверы. Это должно быть автоматическим, а при отключении серверов уровень загрузки должен увеличиваться. Мы стараемся сохранить 40% использования в качестве медианы для окружающей среды.
Сложность состоит в том, чтобы автоматизировать настройку вашего балансировщика нагрузки для просмотра новых хостов. Я знаю людей, которые просто предварительно настраивают балансировщик для использования показателя работоспособности даже после выключения сервера. Балансировщик нагрузки не будет обслуживать трафик на мертвый хост. Когда сервер запускается, балансировщик нагрузки должен увидеть его снова и начать автоматически обслуживать запросы к серверу.
Окончательное решение
Развертывание минимально жизнеспособной среды и настройка мониторинга для отслеживания ваших собственных уровней использования. Создайте триггеры, которые запускают серверы в выбранной вами среде. Триггеры должны выполнить запрос, который запускает вызов Rackspace и запускает сервер. Это хорошее начало.
Надеюсь, что это было полезно для вас, и вы продолжаете создавать успешную среду.