Когда самое подходящее время начать добавлять (или думать о добавлении) серверов в ваше веб-приложение? Какие трудности возникают при переходе с одного сервера (БД и Интернет) на несколько?
Например:
Наиболее когда вы начинаете с одного сервера, который вы используете как для БД, так и для Интернета, вы разделяете свою БД / Интернет на другой сервер, затем переходите на несколько веб-серверов (что создает проблемы сеанса), затем, возможно, NAS для БД и т.д.
Когда самое подходящее время начать добавлять (или думать о добавлении) серверов в ваше веб-приложение? ... (переход от одного сервера ... к нескольким)
Подумай об этом: С начала.
Начать добавление: Когда вы получаете первую ошибку «сервер слишком занят». Все, что раньше - это преждевременная оптимизация.
(Если ваше веб-приложение не является критически важным, и в этом случае вы, вероятно, не начинаете с нуля и вам не нужно опрашивать сообщество serverfault.com.)
А если серьезно, то для современных потребительских веб-приложений "слишком загруженный сервер" может стать проблемой. хорошо вещь. Это, конечно, никогда не повредит Facebook, Twitter или YouTube. Опасность слишком раннего добавления серверов заключается в том, что ваше приложение никогда не станет таким популярным, как вы ожидаете, и в конечном итоге вы потратите деньги, которые можно было бы потратить на разработку функций.
Если вы один из немногих счастливчиков, у которых действительно есть популярный веб-ресурс, то (а) поздравляю, и (б) вы сможете измерить свое среднее время отклика на основе файлов журналов и использовать более метрические подход к добавлению серверов.
Лично я всегда начинаю с отдельного веб-сервера от сервера БД.
(на основе IIS6 и SQL Server)
Однако мы делаем ВСЕ это на сервере vmware (фактически, в кластере с 3 узлами), а веб-сервер и сервер db имеют только 1 виртуальный ЦП и 1 ГБ ОЗУ. И они без особых усилий поддерживают довольно загруженный набор веб-сайтов (внешних и внутренних).
Но я знаю, получу ли я всплеск популярности (и это мощь однажды случится!) Я могу быстро перенастроить виртуальную машину с большим количеством ОЗУ и ЦП.
Практическое замечание: отслеживайте свою эффективность с течением времени. Следите за изменениями и будьте активны.
Когда самое подходящее время начать добавлять (или думать о добавлении) серверов в ваше веб-приложение?
Когда вы разрабатываете свое приложение. Я видел слишком много приложений, не предназначенных для использования нескольких серверов, и обратное проектирование, которое в дальнейшем может оказаться ужасным.
Убедитесь, что вы тестируете также на нескольких серверах. Очередной раз. Я видел, как многие приложения отлично работают в режиме разработки / тестирования только для сбоя в производстве, потому что они не могут справиться с балансировщиками нагрузки или брандмауэрами, многоадресная рассылка не учитывалась и т.д.
И время для добавления еще одного сервера наступает тогда, когда ваша статистика управления мощностью предполагает, что у вас закончится емкость в течение времени, которое потребуется вам для добавления еще одного сервера.
Вы собираете статистику по мощностям? Нет? Тогда еще о чем поговорить с разработчиками приложений и людьми, управляющими инфраструктурой.
Я не согласен с тем, что правильно подождать, пока вы действительно не станете «сервер слишком занят» и не будете раздражать ваших пользователей. Добавление нового сервера в производственную среду может быть длительным процессом, и ждать, пока у вас не появятся ошибки, прежде чем начать, нецелесообразно.
Как уже упоминали другие, вопрос расплывчатый, но на самом деле есть довольно простой ответ:
Вам необходимо добавить еще один сервер, когда ограничения на текущий начинают стоить вам денег.
Если вы предлагаете бесплатную услугу, то действительно нет стимула добавлять дополнительные серверы.
Если вы зарабатываете деньги на своих услугах, вы можете провести анализ затрат и выгод: как дополнительные серверы повысят производительность и насколько увеличится прибыль?
Вам следует провести нагрузочное тестирование существующего односерверного приложения, чтобы увидеть, сколько сеансов и пользователей оно может поддерживать одновременно. Как только вы это узнаете, вы сможете отслеживать те же показатели с течением времени. Когда ваши цифры начинают приближаться к известным пределам, пора начинать подготовку нового оборудования к развертыванию. Вам нужно будет учитывать время подготовки дополнительных серверов, чтобы вы могли развернуть их до того, как существующая система достигнет своего предела. Это очень общий обзор, и его детали очень хорошо освещены в книге Джона Олспоу «Искусство планирования мощностей».
Сказав это, я бы разбил сервер базы данных и веб-сервер на их собственные системы в качестве отправной точки, а затем провел бы нагрузочный тест каждого, чтобы определить теоретическую нагрузку. Обычно узким местом первым становится веб-сервер, поэтому ваше приложение следует писать с учетом масштабируемости. В вопросе упоминаются сеансы, и в зависимости от платформы, которую вы используете, существует несколько способов обмена сеансами между серверами, хранения их в центральной базе данных или использования оборудования для балансировки нагрузки, которое направит одного и того же пользователя на один и тот же сервер, если он не станет недоступным. по какой-то причине.
Но чтобы ответить на основной вопрос «когда мы знаем, когда это делать», это будет все о метриках, которые вы собираете и сравниваете с известными пределами, достигнутыми в результате нагрузочного тестирования.
Без дополнительной информации о вашем приложении сложно дать какой-либо конкретный совет, но вот несколько слайдов из презентации Брэда Фитцпатрика 2005 года об инфраструктуре LiveJournal (с упором на балансировку нагрузки базы данных):
В общем, переход от одного интерфейса к нескольким сложнее, чем отделение интерфейса от серверной части (обычно базы данных). Однако осторожное использование балансировщиков нагрузки и «липких» сессий может облегчить этот переход.
Что касается «когда», ключ к его обнаружению - это измерение производительности вашего веб-сервера (и серверов базы данных). В идеале на тестовом стенде с реалистичной загрузкой трафика, затем посмотрите, где производительность падает до уровня «недостаточно хорошо». Как только нагрузка на действующий сайт начинает приближаться к "недостаточно хорошей", вы заказываете новый интерфейс.
Если вы примерно знаете, когда вам понадобится новый сервер и примерно как объем трафика растет с течением времени, вы можете стремиться к развертыванию нового сервера непосредственно перед тем, как он понадобится. К сожалению, я не могу назвать вам точных цифр, поскольку эти вещи очень зависят от специфики вашей установки.