Когда добавить другой сервер (ы)

Лично я всегда начинаю с отдельного веб-сервера от сервера БД.

(на основе IIS6 и SQL Server)

1. База данных будет просто жевать ресурсы (RAM, DISK, CPU) и конкурировать с веб-сервером. Это может привести к тому, что веб-сервер перестает отвечать на запросы, а база данных "плохая".
2. Безопасность. Не очень хорошая идея иметь больше на "краю", чем вам нужно. Переместите базу данных внутрь DMZ и вставьте нестандартное отверстие (не 1433) в брандмауэр для трафика SQL.
3. Разделение ролей. Теперь вы можете видеть, жует ли процессор БД, IIS или приложение.

Однако мы делаем ВСЕ это на сервере vmware (на самом деле это кластер с 3 узлами), а веб-сервер и сервер БД имеют только 1 vCPU и 1 ГБ ОЗУ. И они поддерживают довольно загруженный набор веб-сайтов (внешних и интранет) без особых потов.

Но я знаю, что если я получу всплеск популярности (а это может случиться однажды!), Я могу быстро перенастроить виртуальные машины, используя больше оперативной памяти и процессора.

Практическое замечание: следите за своей эффективностью с течением времени. Отслеживайте изменения и будьте активными.

Когда подходящее время начинать добавлять (или думать о добавлении) серверы в ваше веб-приложение?

Когда вы разрабатываете свое приложение. Я видел слишком много приложений, не предназначенных для использования нескольких серверов, и обратное проектирование, которое позже может быть ужасным.

Убедитесь, что вы тестируете на нескольких серверах тоже. Снова. Я видел, что многие приложения отлично работают в dev / test, только в случае сбоя в работе, потому что они не могут справиться с балансировщиком нагрузки или с брандмауэрами, многоадресная рассылка не учитывается и т. Д. И т. Д.

И время для добавления другого сервера - это когда ваша статистика управления мощностью показывает, что вы исчерпаете емкость только через некоторое время, которое потребуется для добавления другого сервера.

Вы собираете статистику cpacity? Нет? Тогда еще одна вещь, чтобы поговорить с разработчиками ваших приложений и людьми, управляющими инфраструктурой.

Я не согласен с тем, что ожидание, пока вы на самом деле не станете "слишком занятым сервером" и раздражение ваших пользователей, является правильным решением. Добавление нового сервера в производственную среду может быть длительным процессом, и ожидание, пока у вас не возникнут ошибки, прежде чем начинать, не очень разумно.

Как уже упоминали другие, вопрос неясен, но на самом деле есть довольно простой ответ:

Вам нужно добавить другой сервер, когда ограничения на текущий начинают стоить вам денег.

Если вы предлагаете бесплатную услугу, тогда нет никаких стимулов для добавления дополнительных серверов.

Если вы зарабатываете деньги на своих услугах, тогда вы можете провести анализ затрат и выгод: как дополнительные серверы повысят производительность и какую большую прибыль вы получите?

Без какой-либо дополнительной информации о том, что представляет собой ваше приложение, трудно дать какой-либо конкретный совет, но вот несколько слайдов из презентации Брэда Фицпатрика 2005 года об инфраструктуре LiveJournal (с большим акцентом на балансировку нагрузки базы данных):

http://www.scribd.com/doc/2684169/LiveJournal-scaling

Одна из вещей, которую вы должны сделать, это нагрузочное тестирование вашего существующего приложения с одним сервером, чтобы увидеть, сколько сеансов и пользователей оно может поддерживать одновременно. Как только вы это узнаете, вы сможете отслеживать те же самые показатели с течением времени. Когда ваши цифры начнут приближаться к известным пределам, пора начинать готовить новое оборудование для развертывания. Вам нужно будет учесть время выполнения заказа для дополнительных серверов, чтобы вы могли развернуть их до того, как существующая система достигнет своего предела. Это очень общий обзор, и его детали очень хорошо освещены в книге Джона Аллспоу "Искусство планирования производственных мощностей".

Сказав это, я бы разбил сервер базы данных и веб-сервер на их собственные системы в качестве отправной точки, а затем загрузил каждый из тестов, чтобы определить теоретическую нагрузку. Обычно узким местом становится веб-сервер, поэтому ваше приложение должно быть написано с учетом масштабируемости. В этом вопросе упоминаются сеансы, и в зависимости от используемой платформы существует несколько способов совместного использования сеансов между серверами, их сохранения в центральной базе данных или использования оборудования с балансировкой нагрузки, которое направит одного и того же пользователя на один и тот же сервер, если он не станет недоступным. по какой-то причине.

Но ответить на основной вопрос "когда мы знаем, когда это сделать", - это все о метриках, которые вы собираете, и сравнении их с известными пределами, достигнутыми в ходе нагрузочного тестирования.

В общем, переход от одного к нескольким интерфейсам сложнее, чем отделять интерфейс от (обычно базы данных). Тем не менее, осторожное использование балансировщиков нагрузки и "липких" сеансов может облегчить этот переход.

Что касается "когда", ключом к определению является измерение производительности вашего веб-сервера (и базы данных). В идеале на тестовом стенде с реалистичной нагрузкой на трафик, тогда посмотрите, где производительность падает до "недостаточно хорошо". Как только нагрузка на действующий сайт начинает приближаться к "недостаточно хорошему", вы заказываете новый интерфейс.

Если вы примерно знаете, когда вам понадобится новый сервер, и примерно, как объем трафика растет со временем, вы можете стремиться к развертыванию нового сервера непосредственно перед тем, как он понадобится. К сожалению, я не могу дать вам какие-либо точные цифры, поскольку эти вещи очень зависят от особенностей вашей установки.