Веб-сайт с высокой нагрузкой. как сделать балансировку нагрузки? [закрыто]
У меня следующая проблема: у меня два сервера (Intel xeon 3,4 ГГц с 32 ГБ ОЗУ и RAID 10 (4x1 ТБ корпоративные жесткие диски).
все серверы установлены с vmware esxi 5.5 (бесплатно). webserver, dbserver - все это виртуальные машины.
первый - это веб-сервер с новейшими версиями debian x64 и apache 2. load: 50% второй сервер - это сервер базы данных mysql с новейшей версией debian. x64. нагрузка: 95%
, поэтому теперь я заказал два новых сервера (думаю, я получу сервер в пятницу).
все четыре сервера имеют внутреннее соединение через 1 Гб локальной сети.
текущий веб-сайт: - обычный веб-сайт с drupal и одним приложением ioncube - с одной базой данных mysql
, так что я должен настроить кластер с балансировкой нагрузки, не так ли?
так что эксперты: у вас есть некоторая информация или учебники как я могу настроить кластер?
проект стартовал в 2013 году, но сейчас веб-сайт настолько интенсивен, что ...
большое спасибо!
многие приветствуют m.k.
Здесь происходит куча вещей. В общей категории настройки производительности существует несколько уровней / этапов процесса. Кажется, вы сначала перескакиваете на последний шаг. Обычно я подхожу к этому в своей работе следующим образом:
- Пользовательский опыт и статистика оборудования.
Первое правило: если сайт работает нормально для конечного пользователя, внутренняя статистика не имеет значения. Они полезны для планирования емкости, но если сервер загружен на 100% ЦП и сайт работает нормально, технически у вас нет проблем с производительностью. У вас есть проблема типа «нет лишних мощностей, если что-то пойдет не так, у вас проблемы», но это не проблема в данный момент.
И наоборот, если серверы в основном простаивают, но сайт работает медленно, то факт серверы простаивают, это не имеет значения - в смеси все еще есть что-то неоптимальное.
- Различные уровни в стеке приложений.
Здесь есть два уровня: уровень веб-сервера и уровень сервера базы данных. Веб-серверы балансировки нагрузки не помогут, например, если именно ваш сервер базы данных имеет проблемы с производительностью.
- Оптимизация отдельных уровней.
Вы хотите убедиться, что каждый уровень настроен для правильного обслуживания того, что необходимо. В этом случае комментарий первого автора о производительности диска, скорее всего, уместен. Дискового пространства недостаточно для выбора конфигурации хранилища, обычно IOPS или пропускная способность являются наиболее важной частью. Кроме того, в случае SATA и SAS вы хотите использовать диски SAS, потому что интерфейс хранилища поддерживает большее количество одновременных подключений.
Для CMS, такой как Drupal, вы почти наверняка используете базу данных для всего, и в этом случае вы вероятно, потребуется гораздо больше физических дисков, чтобы иметь нужную скорость. Специфика этого, к сожалению, зависит от ряда переменных, в том числе от того, используется ли ваш сайт в основном для чтения, записи или комбинации, а также от того, сколько данных передается в запросах (если все получают одну и ту же главную страницу, это одна передача, и вещи, вероятно, кэшируются vs.если все войдут в систему и получат индивидуальный контент, доступ к данным будет повсюду). Вам следует начать с максимальной оптимизации сервера базы данных, что потребует просмотра документации, относящейся к программному обеспечению и оборудованию вашей базы данных.
В некоторых случаях может оказаться полезной оптимизация уровня веб-сервера. Судя по тому, что я здесь вижу, вероятно, вас это не беспокоит. (Технически, даже настройка слоя "веб-сервер" имеет несколько мест для оптимизации - например, ставите ли вы перед ним прокси, отделяете статический контент и тому подобное. Но я думаю, вам не о чем беспокоиться это пока.)
- Оптимизация всей среды.
После того, как вы настроили каждый отдельный элемент, вы смотрите на такие вещи, как балансировка нагрузки. В случае наличия десятков серверов использование балансировки нагрузки для лучшего распределения ресурсов является жизнеспособным подходом. В случае небольшого количества серверов, как здесь, кажется, лучше рассматривать балансировку нагрузки как строго средство переключения при отказе / доступности, а не как средство компенсации проблем с производительностью.
Итак, в основном, настройте ваш стек наружу от данных. Информация, которую вы получите в результате этого процесса, скорее всего, поможет вам в процессе определения того, как или следует ли реализовать конкретное решение для балансировки нагрузки.