Как развернуть сайт [Ruby on Rails] масштабируемым способом?
Я работаю над моим [первым] запуском в течение месяца, и, хотя это, вероятно, еще один месяц от альфа-релиза, я хочу знать, как правильно его развернуть. Сайт будет иметь начальную высокую нагрузку (сеть + процессор) для нового пользователя, поэтому я думаю о наличии отдельного сервера/очереди для этого начального процесса, чтобы он не замедлял сайт для существующих пользователей.
основываясь на моих исследованиях до сих пор, я в настоящее время склоняюсь к nginx + haproxy + unicorn/thin + memcached + mysql и развертывание на Linode. Тем не менее, у меня нет предыдущего опыта ни в одном из вышеперечисленных; поэтому я надеюсь использовать опыт сообщества.
- кажется ли вышеуказанная архитектура разумной? Любые предложения/статьи/книги, которые вы бы порекомендовали?
- Линоде хороший выбор? Heroku / EY кажутся слишком дорогими для меня (по крайней мере, пока у меня нет достаточного дохода), но мне не хватает другого лучшего варианта? MediaTemple?
- любые хорошие предложения по архитектуре балансировки нагрузки? Я все еще читаю об этом.
- лучше ли иметь 2 отдельных экземпляра сервера Rails на 2 отдельных линодах или запускать 1 экземпляр на линоде двойной емкости (с точки зрения ОЗУ/хранения/пропускной способности)? Сколько Linodes я должен начать?
- какой дистрибутив Linux выбрать? (Linode предлагает 8 различных -http://www.linode.com/faq.cfm) есть ли какие-либо относительные преимущества/недостатки между ними для сайта рельсы?
Я прошу прощения, если какие-либо из моих вопросов глупы или противоречивы; пожалуйста, отнесите это к моей неопытности.
1 ответов
архитектура
вы на правильном пути. Я лично предпочитаю Passenger над thin / unicorn (запустив nginx для тонких бэкэндов в течение длительного времени) только для удобства, но ваша предлагаемая настройка довольно стандартная. Если вы находитесь на Ruby 1.8.7,я бы рекомендовал вам рассмотреть REE + Passenger для экономии памяти framework.
Хостинг И Балансировка Нагрузки
Linode фантастический, и я использую их примерно для все, что я могу, но вам нужно будет знать пределы ОЗУ. Каждый процесс Rails использует нетривиальное количество ОЗУ, и вы захотите избежать попадания машины в swap. Запланируйте запуск достаточного количества экземпляров Rails на машину, чтобы ваше распределение памяти составляло около 90% памяти на Линоде. Вероятно, вам понадобится другой Линод, посвященный вашей базе данных, хотя вы можете начать с них обоих на одной машине; просто будьте готовы отделить MySQL по мере роста. Можно настроить связь между Linodes в одном центре обработки данных на отдельный айпишник, который не засчитываются в счет квоты пропускной способности.
ваша стратегия масштабирования должна быть как можно более горизонтальной, поэтому я бы рекомендовал просто получить второй Линод и добавить его в свой пул haproxy, когда вам нужно больше лошадиных сил - Линод взимает с вас $20 за 512mb больше ОЗУ, или вы можете просто получить целый "другой Линод" (с CPU, RAM, HDD и квотой пропускной способности) за те же $20. Кажется, без проблем!). В случае Rails экземпляр является экземпляр-это экземпляр, поэтому на самом деле не имеет значения, находится ли он на той же виртуальной машине или нет, пока время подключения к вашей машине базы данных или что-то еще более или менее одинаковое. Вы можете запускать 10 Линодов, каждый из которых работает с 10 рельсами, без особых проблем. Linode также предлагает IP-отработки отказа, так что если ваш основной Линод (с haproxy) идет вниз, он может автоматически переключиться на вторичный Линод, который затем будет работать на haproxy и готов действовать в том же емкость как первое.
распределение
честно говоря, это зависит от вас! Многие люди идут с дистрибутивами Ubuntu или Redhat (CentOS/Fedora) - мне нравится CentOS, но на самом деле это то, с чем вы чувствуете себя наиболее комфортно. Если у вас нет любимого дистрибутива, я бы рекомендовал попробовать Ubuntu/CentOS, поскольку они, как правило, довольно дружелюбны к новичку и имеют чрезвычайно надежную поддержку сообщества.
вы, вероятно, захотите выбрать 32-бит дистрибутив если у вас нет веской причины выбрать 64-разрядный дистрибутив; 64-разрядные исполняемые файлы требуют больше ОЗУ, чем их 32-разрядные аналоги, и поскольку ОЗУ, вероятно, будет вашим самым ценным ресурсом, имеет смысл сохранить его там, где вы можете.