Назад | Перейти на главную страницу

Как настроить несколько веб-серверов и серверов баз данных?

Мои веб-сайты росли с точки зрения трафика, и нагрузка на mysql возрастала. Мне нужно было решение, которое помогло бы справиться с возросшей нагрузкой на mysql (все запросы уже оптимизированы) из-за увеличения трафика + резервные серверы, которые могли бы служить в качестве аварийного переключения, если мой основной сервер выйдет из строя.

Я читал о настройке нескольких веб-серверов и серверов баз данных, но у меня возникло несколько вопросов:

1) Как настроить несколько веб-серверов, сохраняя при этом один и тот же контент (мне придется загружать файлы на все серверы каждый раз, когда они обновляются, или есть другой способ?)

2) Точно так же, если бы мне пришлось масштабировать БД на более чем один сервер, есть ли другой способ, кроме репликации, или репликация mysql - лучший способ сделать это.

3) Я читал, что отделение базы данных от веб-сервера - хорошая идея, почему? Если бы у меня было 2 сервера, разве я не мог бы иметь и БД, и файлы на обоих серверах.

4) Требуется ли что-то, известное как балансировщик нагрузки, и поможет ли это сбалансировать запросы mysql, если бы была настроена репликация?

Просто очень запутался, мне нужна помощь.

Традиционная установка заключалась бы в разделении вашего веб-сервера / сервера приложений и сервера БД. Их наличие в одной коробке будет довольно ограничительным. Если ваше веб-приложение состоит из смеси статического и динамического содержимого, дальнейшее разделение (отдельный веб-сервер, сервер приложений и сервер содержимого) повысит производительность.

Что касается MySQL, вы можете попробовать это;

  • Определенно иметь MySQL на собственном выделенном сервере.
  • Добавьте столько памяти, сколько вы можете себе позволить, и машина может принять MySQL любит объем памяти.
  • Поместите вашу ОС, журналы корзины и данные на три отдельных физических диска.

1) Как настроить несколько веб-серверов, сохраняя при этом один и тот же контент (мне придется загружать файлы на все серверы каждый раз, когда они обновляются, или есть другой способ?)

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

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

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

В произвольном порядке:

  • Использовать сеть доставки контента.
  • Прокси статического контента с кешированием самостоятельно.
  • Переведите хранилище данных в высокодоступную файловую систему.
  • Часто в идеале предпочтительным решением является хранение контента в базе данных.

2) Точно так же, если бы мне пришлось масштабировать БД на более чем один сервер, есть ли другой способ, кроме репликации, или репликация mysql - лучший способ сделать это.

Это зависит от вашей конечной цели: согласованности, доступности или допустимости разделов. Скорее всего, потребуются компромиссы. Это обширная тема, и вам было бы полезно прочитать такую ​​книгу, как Высокая производительность MySQL. Общие варианты:

  • Двойная главная репликация с использованием такой технологии, как Linux-HA, VRRP, или multi master MySQL. У этого будет плавающий IP. Вам нужно будет реализовать автоматическое смещение идентификатора и знать о производительности приложения.
  • Используя решение вроде DRBD для репликации хранилища на уровне блоков, а затем снова с использованием такой технологии, как Linux-HA, для переключения ресурсов в случае сбоя.

MySQL также имеет различные белые бумаги опубликовано.

3) Я читал, что отделение базы данных от веб-сервера - хорошая идея, почему? Если бы у меня было 2 сервера, разве я не мог бы иметь и БД, и файлы на обоих серверах.

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

Он также позволяет выполнять стандартные сборки, масштабирование и перенос ролей с меньшими сложностями. Тем не менее, эти функции не являются уникальными для разделения ролей сервера.

4) Требуется ли что-то, известное как балансировщик нагрузки, и поможет ли это сбалансировать запросы mysql, если бы была настроена репликация?

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

Вы можете легко сбалансировать нагрузку на подчиненные серверы репликации MySQL, что позволит вам использовать VIP с балансировкой нагрузки для запросов только для чтения.