Постоянная EBS на инстансах AWS EC2
У меня есть экземпляр t2.micro EC2, работающий на AWS. Чтобы справиться с пиками трафика, я создал группу автоматического масштабирования, которая динамически увеличивает и уменьшает экземпляры EC2 из AMI. До сих пор все в порядке. Проблема в том, что моя база данных для входа в систему находится в том же экземпляре EC2. Когда создается новый экземпляр EC2, он не содержит нового добавленного пользователя в основном экземпляре EC2. И если новый пользователь создает учетную запись в новом экземпляре, он теряется при завершении экземпляра. Есть ли способ создать единый том EBS для всех экземпляров?
Пожалуйста, укажите мне на некоторые полезные ресурсы по созданию масштабируемых веб-приложений на AWS.
Да, пользователи хранятся в реальной базе данных.
Ваша база данных также хранится в том же экземпляре EC2? Почему вы назначаете пользователям логин ОС? Что пользователи делают в вашей системе? Не стесняйтесь редактировать свой вопрос, чтобы предоставить более подробную информацию.
Ответы 1
Проблемы, с которыми вы сталкиваетесь, - это основная причина, по которой этот шаблон (все в одном и том же случае) не рекомендуется. Это работает, пока ваше приложение невелико и не получает большого трафика.
Вместо этого вам следует извлечь свою базу данных из экземпляров приложения и переместить ее в RDS (полууправление не позволит вам выполнять множество задач, таких как установка исправлений сервера, регулярное резервное копирование, настройка набора реплик и т. д.). Кроме того, RDS предоставит вам простое развертывание в нескольких зонах доступности, что поможет вам добиться реальной отказоустойчивости. Однако этот шаг не является обязательным - вы можете просто запустить новый экземпляр EC2 и вручную установить туда свою БД (но оставьте его предназначенным для целей БД).
Ваша архитектура должна выглядеть примерно так, как показано на следующей диаграмме;
ELB ---> INSTANCE 1 --> RDS DB INSTANCE
| ^
|-> INSTANCE 2 ---------|
| |
|-> INSTANCE n ---------|
Если вы хотите масштабировать, вы должны сохранять ваши экземпляры как можно более безгражданскими. Тот же подход применяется к файлам, которые вы храните в собственном экземпляре; вам следует переместить их в S3 (или, если это доступно в вашем регионе, вы также можете использовать эластичную файловую систему)
Это по существу и самый полезный ответ, который я видел. Спасибо! Могу я задать еще один вопрос. Мои экземпляры автомасштабирования создаются с использованием AMI. Если я обновлю код на своем реальном сервере, мой AMI не будет обновлен. Есть ли решение для этого? Потому что мне, возможно, придется часто исправлять ошибки, и изменение конфигурации автомасштабирования, на самом деле, не вариант.
К сожалению, у вас есть только несколько вариантов: 1 / разработать некоторый код для автоматизации создания новых AMI на основе свежего кода и обновить группы автомасштабирования для использования новых AMI; 2. разработать приложение, которое может развернуть новую версию для тех, кто масштабируется автоматически. экземпляр при загрузке, или 3. убедитесь, что у вновь созданных экземпляров есть сценарий запуска (данные пользователя AWS), который автоматически обновит локальную версию приложения.
В моей компании мы настроили хуки жизненного цикла автомасштабирования, так что каждый экземпляр, порожденный автоматическим масштабированием, переходит во временное состояние «ожидание - ожидание», во время которого уведомление отправляется на «развертывающий» компьютер, который отвечает за развертывание новой версии приложения на этот экземпляр
Я предполагаю, что ваши пользователи хранятся в базе данных, но поскольку вы говорите, что они связаны с ОС, я хотел подтвердить, что все данные вашего приложения и пользователи приложений хранятся в реальной базе данных, а не с использованием пользователей ОС. Это правильно?