Я работаю в небольшой финансовой фирме разработчиком веб-приложений. У нашей компании есть внутренний веб-сайт, написанный на PHP и работающий на Apache. Недавно наш сервер вышел из строя, и сайт не работал несколько дней, что привело к серьезным проблемам.
Меня попросили настроить еще два сервера для обслуживания веб-сайта. Итак, нам нужно три сервера Apache Web / App, работающих на трех разных машинах. Когда пользователь входит на сайт, он должен обслуживаться одним из трех серверов в зависимости от нагрузки. Также, если один или два сервера выходят из строя, сервер, который работает, должен обрабатывать запросы веб-сайта.
Я просто знаю, как создать сайт на PHP и разместить его на сервере Apache. Я не разбираюсь в сетях. Скажите, пожалуйста, что мне нужно узнать для создания вышеупомянутой системы.
Я не жду, что меня кормят с ложечки. Просто нужен указатель на то, чему я должен научиться, чтобы достичь своей цели. Я одновременно гуглию, но задал этот вопрос здесь, так как спешу его реализовать.
Распространенным подходом является разработка веб-приложений, поддерживающих кластеризацию. Вероятно, вам потребуется переделать основы вашего сайта, связанные с базой данных, сеансами, общими и динамическими данными. Я уверен, что мой вопрос вас заинтересует: Облачные / кластерные решения для масштабируемых веб-сервисов. Чтобы сделать веб-сайт «масштабируемым», вам необходимо создать масштабируемый дизайн. Увы, кнопки с надписью «Сделать быстрее» внизу нет :)
Простой способ - реплицировать все данные между этими серверами (вы можете использовать GlusterFS для файлов и реплицируйте ваш MySQL / что-то еще между этими серверами) и убедитесь, что все сеансы доступны со всех из них! Это не лучший вариант, но переделывать код не придется :)
Балансировку нагрузки можно легко реализовать с помощью Round-Robin DNS: просто добавьте несколько записей A, указывающих на разные серверы, и клиенты будут выбирать их случайным образом. Например, у Google есть такая функция:
$ host -t a google.com google.com has address 74.125.87.147 google.com has address 74.125.87.103 google.com has address 74.125.87.104 google.com has address 74.125.87.99 google.com has address 74.125.87.105
Хотя самый простой метод балансировки нагрузки - это что-то вроде циклического DNS, как указано в ответе o_O Tync, вы должны знать, что если один из этих серверов выйдет из строя и вы удалите его запись DNS, часть ваших пользователей будет направлена на неработающий сервер, пока не истечет TTL для их записей DNS или вы не измените IP-адреса вручную. В зависимости от того, насколько важно для вас время безотказной работы, это может быть неприемлемо. Кроме того, любые пользователи, которые находились в середине сеанса с отказавшим сервером, потеряли бы этот сеанс.
RRDNS подходит для балансировки нагрузки, но на самом деле не является ключом к высокой доступности.
Самый простой способ (и под самым простым я имею в виду самый простой, но не обязательно дешевый) реализовать истинную балансировку нагрузки с высокой доступностью - это использовать аппаратное сетевое устройство балансировки нагрузки, которое находится между подключением к Интернету и вашими веб-серверами. Такое устройство можно использовать для разделения нагрузки между вашими системами, а также для автоматического (или ручного) удаления сервера из ротации в случае возникновения проблемы. Кроме того, он позаботится о TCP-соединениях, чтобы пользователь мог автоматически подключиться к другому серверу, если его исходное устройство выйдет из строя. Еще одно преимущество этого решения состоит в том, что для его реализации обычно требуется небольшая модификация приложения или не требуется ее вообще. Обратите внимание, что действительно В конфигурации с «высокой доступностью» обычно используются два балансировщика нагрузки для уменьшения количества единичных точек отказа.
Другой вариант - использовать обычные серверы для достижения сценария балансировки нагрузки высокой доступности. Вот некоторая информация о настройке кластера Apache с высокой доступностью и балансировкой нагрузки. В Linux-HA site - отличный источник информации о балансировке нагрузки Linux.
Еще один вариант - что-то вроде Виртуальный сервер Linux проект. LVS использует Linux для всех компонентов, как серверов, так и балансировщиков нагрузки, и обычно обеспечивает бесшовное решение (после настройки).
В заключение: моя общая рекомендация состоит в том, что для такой ситуации, как ваша, когда неопытного администратора просят настроить балансировку нагрузки в такой ситуации, аппаратное устройство балансировки нагрузки является наиболее безболезненным способом сделать это. Очевидно, что это стоит денег, но может сэкономить много времени. Определение компромисса - это, конечно, индивидуальное решение.
Что бы я сделал, так это сяду и посмотрю, что в данный момент работает на рассматриваемом сервере.
На данный момент я предполагаю, что вы используете Linux, хотя вы явно этого не сказали. Вы хотите посмотреть на лак. Это высокопроизводительный обратный прокси-сервер и балансировщик нагрузки. Вы можете настроить его, следуя онлайн-примерам Вот и это должно быть несложно приступить к работе.
Если у вас есть 2 лаковых узла из 3-х серверов, направьте 1/3 трафика на каждый из серверов, организовав циклическое назначение. Этим двум серверам нужны уникальные общедоступные IP-адреса, и вы можете установить несколько записей A в DNS для выполнения RoundRobin DNS (RRDNS).
Если ваша услуга критически важна для бизнеса, а последнее отключение стоило серьезных денег, вы можете выступить за более устойчивую и избыточную сеть. Предполагая, что в настоящее время у вас есть только один сервер на одном IP-адресе, предоставленном одним поставщиком, если ваш предыдущий сбой был связан с сетью, вы можете обнаружить, что повышение устойчивости сети улучшит время безотказной работы.
Также внимательно следите за своим мониторингом, убедитесь, что вы отслеживаете вещи на сервере (-ах), которые могут вывести из строя сервер (-ы), данные SMART на жестких дисках, свободное пространство подкачки, свободную память, свободное / дисковое пространство. Подготовьте Нагиоса и Мунина. Nagios предупреждает о выполнении критических условий мониторинга, а Munin отображает эти данные в виде графика.
Возможно, вам также придется внести некоторые изменения на уровне приложения. Предполагая, что ваше приложение (а) основано на сеансах, вам понадобится способ обработки запросов пользователя, которые не всегда поступают на один и тот же сервер. Вы можете сделать их на стороне клиента или на стороне сервера и прикрепить. Вы, вероятно, обнаружите, что здесь вам очень поможет memcached. Что касается изменений на уровне приложений, вы можете спросить об изменениях в StackOverflow, поскольку они содержат больше кода и меньше серверного.
http://studyhat.blogspot.com/2009/11/clustering-linux-ha.html вместо службы mysql вы можете использовать службу httpd
Отказоустойчивость и балансировка нагрузки Apache
http://kbase.redhat.com/faq/docs/DOC-5677