Я работаю с существующим веб-приложением, разработанным на Ruby с серверной частью MySQL, но я думаю, что общий вопрос о топологии оборудования будет применяться к широкому спектру серверных архитектур.
Я ищу документ / веб-ресурс, объясняющий и подробно описывающий текущую передовую практику, касающуюся организации оборудования в ферме серверов для доставки веб-приложения с серверной частью базы данных.
Текущая архитектура выглядит следующим образом;
HTTP Server (Apache)
|
Application Servers x 8 (Unicorn / Ruby-on-Rails)
|
MySQL Back-end (Master)
\
\
MySQL Slave (primarily for performing backups)
Предлагаемая архитектура должна быть более масштабируемой, чем описанная выше, включая балансировщик нагрузки перед несколькими HTTP-серверами, разделение серверов приложений между HTTP-серверами, несколько подчиненных MySQL для запросов только на чтение сервера (которые будут контролироваться изменениями в прикладном программном обеспечении)
Основная цель - сделать систему более устойчивой с использованием современных передовых методов, и это то, что предлагалось до сих пор.
Но, если кто-нибудь может предложить ресурс для передовой практики в этом типе среды или предложить архитектуру, которая обеспечит устойчивость, производительность и масштабируемость, которые нам нужны, я был бы очень благодарен :)
Дэйв
Масштабируемость распространяется не только на аппаратный уровень, но и на уровень приложений. Способность среды разрастаться до больших размеров в значительной степени зависит от способности программного обеспечения на каждом уровне обрабатывать ошибки и поддерживать согласованное состояние во всей среде. Если база данных, управляющая всей вашей средой, не может быть сегментирована, вы ввели ограничитель масштабируемости, используя эту базу данных. Такие вещи.
У Amazon есть несколько официальных документов по разработке для своего облака, и некоторые из них, как правило, применимы к любой масштабируемой инфраструктуре.
http://aws.amazon.com/whitepapers/
При масштабировании следует помнить о некоторых общих принципах:
Не используйте просто балансировщик нагрузки, используйте три балансировщика нагрузки, которые представлены как один LB, чтобы в случае сбоя одного из них другие могли взять на себя нагрузку.
На серверах веб-приложений и веб-приложений состояние пользователя должно быть доступно на всех узлах, поэтому, если пользователя перенаправляют на другой веб-сервер или сервер приложений, его сеанс сохраняется. В лучшем случае все состояние может обслуживаться со всех серверов.
В вашей сети должны быть резервные маршрутизаторы, чтобы вы могли отключить один, не останавливая весь трафик. HSRP - один из протоколов, позволяющих это сделать.
Ваш план базы данных должен включать, насколько вы будете масштабировать один сервер БД, прежде чем начнете сегментирование, и начнете разработку с учетом сегментирования, как только вы приблизитесь к этой точке.
Слои кэширования (memcached) могут потребоваться в вашей среде по соображениям производительности.
Когда вы станете достаточно большим, вам нужно будет спланировать, как вы будете размещать свою среду в нескольких разных местах (например, на западе США и востоке США или на западе США и Европе) через Anycast или GeoIP. Перемещение данных между отдельными местоположениями будет сложной задачей, и вам необходимо начать разработку в соответствии с этим предположением, как только вы приблизитесь к необходимости отдельных местоположений.
У самого Ruby есть некоторые проблемы с масштабированием, поскольку он сосредоточен на его способности (или нет) использовать преимущества нескольких процессоров на серверах. Возможности есть, но они довольно новые, поэтому еще не совсем понятны в сообществе разработчиков (по крайней мере, я так понимаю). По мере развития Ruby некоторые из этих проблем исчезнут.
Спасибо за прекрасное объяснение; проблема масштабируемости может быть уменьшена в случае реляционных баз данных за счет балансировщик нагрузки базы данных. Он может масштабироваться линейно и поддерживать гораздо больше одновременных пользователей за долю времени отклика, и все это без каких-либо изменений в вашем приложении, поэтому они вполне подходят для веб-приложений или веб-приложений.