В настоящее время у меня есть выделенный веб-сервер и сервер базы данных, работающий в центре обработки данных (DC) 1. Я собираюсь расширить его с помощью еще одного веб-сервера в центре обработки данных 2, который будет общаться с db в DC 1.
Задержка между двумя центрами обработки данных составляет около 2-5 мс. Подходит ли это для веб-сайта с высокой посещаемостью (более 400 000 посетителей в день)?
Может быть (TM). Это, конечно, не повлияет на вашу производительность, и я бы опасался, что мои машины будут разбросаны таким образом только из-за потенциальных режимов отказа, которые это вызывает, но, вероятно, это не самая большая проблема производительности.
С другой стороны, удивительно, на что способны хостинг-провайдеры, если их подтолкнуть, поэтому я бы сказал вашему провайдеру, что их предлагаемое решение неприемлемо для ваших нужд, и если они не могут предоставить другой сервер в той же сети, что и ваши существующие машины. , тогда вы перенесете свой бизнес в другое место. Скорее всего, они чудесным образом найдут поблизости место.
На самом деле невозможно ответить на ваш вопрос - вы не предоставили никаких измерений воздействия на ваш сайт, и вы также не определили, каковы ваши цели производительности.
Но один важный указатель: многие Фреймворки webapp используют стратегию блокировки чтения, т.е. пока инфраструктура webapp выполняет SQL-запросы, поток webapp в вопросах помечается как занятый для операционной системы. Таким образом, вы могли видеть использование процессора на вашем внешний интерфейс серверы значительно увеличиваются из-за дополнительной задержки SQL-запроса.
Некоторые инфраструктуры веб-приложений, такие как ASP.NET MVC, предоставляют асинхронный ввод / вывод интерфейс, который может решить указанную выше проблему. Но асинхронный ввод-вывод не используется по умолчанию, и почти наверняка было бы слишком дорого перепроектировать код вашего сайта для его использования.
Почему бы просто не перенести ваши старые серверы на новый DC и не настроить красивую частную VLAN для всех ваших серверов в новом DC?
2-5мс - это не так уж и плохо, имхо. Опять же, это также зависит от того, как ваше приложение обрабатывает вызовы базы данных.
Более интересно, может быть, посмотреть на Отказоустойчивость, вы можете захотеть настроить идентичное решение в DC2, чтобы у вас был сервер БД в обоих, и вы могли быстро восстановить после любой аварии в одном центре обработки данных. Задержка в 2-5 мс будет очень подходящей для репликации базы данных, и если вы используете mySQL, вы даже можете настроить репликацию с несколькими мастерами и повысить производительность между веб-серверами и ближайшим сервером БД.
Хотя нет ничего плохого в том, чтобы подтолкнуть вашего поставщика услуг к достижению приемлемого уровня производительности, вам также необходимо «смотреть правде в глаза». Если центры обработки данных находятся на расстоянии 300 км друг от друга, первые 2 мс просто связаны с тем фактом, что даже оптоволоконные линии WAN не превышают скорость света (примерно 300 000 км / с). Время пинга - это время в обе стороны, поэтому 300 км фактически означают время, необходимое для поездки на 600 км (300 км в одну сторону). Это занимает 2 мс со скоростью света, и ни один хостинг-провайдер не может вмешиваться в физическую константу, такую как скорость света
Мне это кажется довольно высоким, и хотя у меня были базы данных в разных сетях, они всегда находились в одном и том же физическом месте, поэтому задержка не была проблемой. В зависимости от того, сколько запросов на один запрос вы обслуживаете в среднем (и насколько мало кэширования вы делаете на уровне веб-приложений или веб-приложений), это действительно может начать расти. Я хотел бы тщательно протестировать это при моделировании нагрузки, соответствующей вашим шаблонам использования.
Есть ли причина, по которой вы настраиваете веб-сервер в другом центре обработки данных? Если это необходимо для обеспечения избыточности, возможно, более подходящей будет настройка схемы репликации в другую локальную базу данных в Центре обработки данных 2.