Мой сайт в настоящее время работает на выделенном веб-сервере (с LiteSpeed) и выделенном сервере базы данных MySQL. Это сайт на основе загрузки с большим количеством пользовательского контента, который можно транслировать и скачивать, также есть тысячи миниатюр и статического контента.
Я нахожусь на этапе, когда веб-сервер больше не может обрабатывать такой объем трафика, поэтому я ищу наилучший способ увеличения пропускной способности, учитывая большой объем загружаемого контента.
Мой хостер предлагает зеркалировать все на втором веб-сервере и распределять нагрузку между ними с помощью DNS Made Easy или использовать собственный балансировщик нагрузки (используя ldirector) перед двумя веб-серверами.
Может ли кто-нибудь подсказать, будет ли вышеприведенный метод лучшим вариантом? Есть ли у кого-нибудь опыт работы с DNS Made Easy и/или ldirector?
Буду признателен за любую помощь.
решение1
Прежде всего, вам необходимо понять, где находится узкое место, прежде чем вы сможете добиться какого-либо прогресса.
Хостеры быстро рекомендуют новое оборудование, но во многих случаях, если только не очевидны ограничения вашего оборудования, новое оборудование может не дать существенных улучшений.
Добавление оборудования имеет убывающую отдачу, если не сделано разумно. Переход от одного сервера к двум может удвоить ваши ресурсы, но затем вам нужно будет перейти от 2->4, 4->8, чтобы получить тот же прирост.
Мониторинг и измерение
Если вы не отслеживаете системные метрики, время загрузки и другие данные, то это первое место, с которого стоит начать. Бесплатные инструменты, такие как Munin и systat, отлично подходят для серверных решений. Такие инструменты, какhttp://Browsermob.comиhttp://webpagetest.orgможет предоставить вам метрики, ориентированные на пользователя.
Сегмент трафика
Обычно прямой перенос сложного медиа-сайта на другой сервер не очень эффективен. Часто вы получите превосходные результаты для своих инвестиций, сегментируя трафик.
Например, у нас есть клиент с очень загруженным сайтом флеш-игр (миллионы посещений в день). Мы выгрузили флеш-игры на пул недорогих серверов, работающих на Nginx. Эти системы выдают терабайты трафика в месяц. Это коробки начального уровня, и все, что они выдают, это статический контент.
Теперь, что касается стоимости, эти два входных блока вместе были на 20% дешевле основного сервера. Мы получили более чем 4-кратное увеличение емкости. Если бы мы просто клонировали основной сервер и сбалансировали нагрузку, я подозреваю, что в лучшем случае улучшение составило бы 1,5-1,8x.
Короче говоря, приложив некоторые усилия для понимания сути проблемы производительности, вы сможете сэкономить много денег в дальнейшем.
DNS — это просто
Это решение DNS, и оно на самом деле не решает проблему балансировки нагрузки. Возможно, они говорят о циклическом DNS. Не совсем уверен, почему это было включено в уравнение на данном этапе.
Директор
Это инструмент для управления узлами в кластере LVS. Опять же, не уверен, почему был предложен именно этот пункт. Обычно мы просто используем балансировщик нагрузки (аппаратный или что-то вроде Nginx/HA-Proxy) и направляем трафик на соответствующие внутренние серверы.
решение2
Балансировка нагрузки на основе DNS неэффективна по нескольким причинам:
- Вы можете контролировать, как будет осуществляться доступ к вашим серверам, и вы не можете распределять трафик по-разному или равномерно между двумя серверами.
- Что еще важнее, этот способ балансировки нагрузки не распознает отказ сервера. Таким образом, вы потеряете часть трафика, если один из серверов неожиданно выйдет из строя.
- Кэширование DNS еще больше ухудшает ситуацию.
Я предпочитаю использовать более умную технику балансировки нагрузки, например ldirectorили haproxy. Этот тип балансировки нагрузки позволяет распределять трафик в соответствии со спецификациями серверов и использовать несколько факторов (нагрузка, количество подключений и т. д.).
Есть еще одна важная вещь, которую следует отметить. Вы сказали, что у вас есть база данных mysql и пользовательский контент на сервере. Если вы будете распределять трафик между двумя серверами, вам нужно иметь механизм синхронизации между двумя серверами. В противном случае пользователи не всегда будут видеть одни и те же данные, когда они каждый раз будут обращаться к другому серверу.