Я управляю веб-сайтом, который по сути является просто новостным блогом на WordPress. Среднее количество пользователей на сайте составляет 8-15 человек. Но иногда мы сообщаем новости в нашей нише, где у нас будет от 1,5 до 5 000 человек. До сегодняшнего дня мы размещали сайт на VPS через Dreamhost. Мы перешли на AWS / EC2, потому что я подумал, что было бы неплохо иметь масштабируемость.
Я сделал резервную копию всего нашего сервера, запустил экземпляр EC2 (t2.micro работает WordPress для AWS от Bitnami), создал для него накопитель, присвоил ему эластичный IP-адрес, перенес и восстановил все наши данные (с помощью UpdraftPlus). Затем я был счастлив, что сервер вёл себя разумно, отключил наш предыдущий сервер и создал запись DNS, указывающую на IP-адрес экземпляра AWS.
Однако сегодня мы столкнулись с проблемой, когда ЦП был загружен на 100%, а кредиты ЦП все еще доступны. Я думал, что доступные ресурсы ЦП позволят масштабировать сервер так, чтобы он не был привязан к 100% загрузке. Думаю, я неправильно понял. Поэтому я подумал, что мне нужно настроить группу автоматического масштабирования. Итак, я создал AMI из экземпляра, который у меня уже был настроен, создал конфигурацию запуска и создал балансировщик нагрузки. Затем я устанавливаю группу автоматического масштабирования, чтобы иметь 1 желаемый, 1 минимальный и 5 максимальных экземпляров, чтобы запустить экземпляр, если CPU => 85%, и закрыть один, если CPU = <35%.
Я думал, что это было бы хорошо, но однажды я столкнулся с проблемой, когда это настроил. Он остановил экземпляр, который я установил ранее, и отключил весь мой веб-сайт. Затем я в панике бегал вокруг, пока не понял, что это не удаляет хранилище, и я запустил еще один и подключил этот диск.
Я что-то упустил? Как я могу настроить AWS / EC2 для обработки пары тысяч пользователей, использующих одни и те же данные / веб-сайт, и всегда иметь его, а не отключать мой исходный экземпляр?
Любая помощь будет принята с благодарностью.
Когда вы начинаете работать с Auto Scaling, вам нужно привыкнуть к одному факту: экземпляры EC2 будут запускаться, а экземпляры EC2 завершаться. Даже при Min = Max = 1 ваш экземпляр может прекратить работу в любой момент и быть заменен. Не думайте об этом как о плохом, просто привыкните к этому и подыгрывайте. В конце концов, это очень хорошо.
Чтобы начать автоматическое масштабирование, вам необходимо переместить базу данных из экземпляров автомасштабирования. Данные могут быть на другом экземпляре EC2 или на экземпляре RDS. Не важно. Но его не должно быть на запускаемых и завершающихся инстансах EC2. Для этого есть две основные причины:
После того, как у вас будут данные с инстансов EC2, вы создадите «главный» инстанс EC2. Этот «мастер» будет экземпляром EC2, который вы используете SSH (или RDP) для обновления вашего сайта WordPress с точки зрения кода / версии. Он будет остановлен на 99% своего срока службы. Его единственная цель - создать новое изображение AMI при обновлении версии или кода сайта WordPress. Вы:
Если можете, я бы порекомендовал следующее:
Таким образом, у вас не будет ни одного экземпляра EC2, который отключит весь сайт, если он выйдет из строя.
Есть и другие способы управления автоматическим масштабированием, обновлениями и т. Д. Но для новичка вышеупомянутый фреймворк довольно легко понять.
Было бы неплохо еще немного почитать об AWS и попрактиковаться вне производства. Руководств много, и сами AWS предоставляют отличную информацию, это несложно. Вам действительно следует протестировать в другом VPC или регионе, прежде чем работать на производственных площадках.
t2.micro ограничен одним ядром, независимо от ресурсов процессора. Автоматическому масштабированию требуется время, чтобы сработать, в зависимости от интервалов предупреждений / мониторинга. Вы можете добавить существующие экземпляры в elb, но я бы предпочел настроить его, добавить их, а затем позволить ему добавить свои собственные экземпляры и остановить оригинал.
Группа автоматического масштабирования, «золотой» AMI и RDS были бы простым вариантом. Однако вы можете получить разные версии Wordpress, поэтому это требует дополнительных размышлений. Вы можете настроить кеширование на уровне веб-сервера, Nginx превосходен и значительно снизит вашу нагрузку - по крайней мере, на порядок.
У меня есть руководство, которое может быть вам полезно Вот. Он не входит в автомасштабирование, так как мне это самому не нужно, но его просто настроить - я делал это много раз.