Возможный дубликат:
Отказоустойчивость и балансировка нагрузки Apache
Я работаю в небольшой финансовой фирме разработчиком веб-приложений. У нашей компании есть внутренний веб-сайт, написанный на PHP и работающий на Apache. Недавно наш сервер вышел из строя, и сайт не работал несколько дней, что привело к серьезным проблемам.
Меня попросили настроить еще два сервера для обслуживания веб-сайта. Итак, нам нужно три сервера Apache Web / App, работающих на трех разных машинах. Когда пользователь входит на веб-сайт, он должен обслуживаться одним из трех серверов в зависимости от нагрузки. Также, если один или два сервера выходят из строя, сервер, который работает, должен обрабатывать запросы веб-сайта.
Я просто знаю, как создать сайт на PHP и разместить его на сервере Apache. Я не разбираюсь в сетях. Скажите, пожалуйста, что мне нужно узнать для создания вышеупомянутой системы.
Я не жду, что меня кормят с ложечки. Просто нужен указатель на то, чему я должен научиться, чтобы достичь своей цели. Я одновременно гуглию, но задал этот вопрос здесь, так как спешу его реализовать.
+1 для масштабируемых интернет-архитектур.
Что бы я сделал, так это сяду и посмотрю, что в данный момент работает на рассматриваемом сервере.
На данный момент я предполагаю, что вы используете Linux, хотя вы явно этого не сказали. Вы хотите посмотреть на лак. Это высокопроизводительный обратный прокси-сервер и балансировщик нагрузки. Вы можете настроить его, следуя онлайн-примерам Вот и это должно быть несложно приступить к работе.
Если у вас есть 2 лаковых узла из 3-х серверов, направьте 1/3 трафика на каждый из серверов, организовав циклическое назначение. Этим двум серверам нужны уникальные общедоступные IP-адреса, и вы можете установить несколько записей A в DNS для выполнения RoundRobin DNS (RRDNS).
Если ваша услуга критически важна для бизнеса, а последнее отключение стоило серьезных денег, вы можете выступить за более устойчивую и избыточную сеть. Предполагая, что в настоящее время у вас есть только один сервер на одном IP-адресе, предоставленном одним поставщиком, если ваш предыдущий сбой был связан с сетью, вы можете обнаружить, что повышение устойчивости сети улучшит время безотказной работы.
Также внимательно следите за своим мониторингом, убедитесь, что вы отслеживаете вещи на сервере (-ах), которые могут вывести из строя сервер (-ы), данные SMART на жестких дисках, свободное пространство подкачки, свободную память, свободное / дисковое пространство. Подготовьте Нагиоса и Мунина. Nagios предупреждает о выполнении критических условий мониторинга, а Munin отображает эти данные в виде графика.
Возможно, вам также придется внести некоторые изменения на уровне приложения. Предполагая, что ваше приложение (а) основано на сеансах, вам понадобится способ обработки запросов пользователя, которые не всегда поступают на один и тот же сервер. Вы можете сделать их на стороне клиента или на стороне сервера и прикрепить. Вы, вероятно, обнаружите, что здесь вам очень поможет memcached.
Что касается изменений на уровне приложений, вы можете спросить об изменениях в StackOverflow, поскольку они содержат больше кода и меньше серверного.
Если у вас нет денег на покупку балансировщиков нагрузки, вы можете создать балансировщик нагрузки сервера Apache, настроив mod_proxy_balancer. Чтобы сделать вашу архитектуру полностью избыточной, вам нужно будет запустить два экземпляра вашего балансировщика нагрузки, и вы можете указать свой домен на оба IP-адреса. Другой вариант - использовать VRRP или Карп описано в Книга Тео что потребует помощи команды сетевых операторов.
Если ваша компания серьезно относится к этому, они могли бы рассмотреть такое устройство, как Cisco CSS Content Services Switch 11501 series. Мы используем это устройство с несколькими веб-серверами / серверами приложений для балансировки нагрузки и обеспечения избыточности.
Беги - не ходи - на Amazon.com и покупай
http://www.amazon.com/Scalable-Internet-Architectures-Theo-Schlossnagle/dp/067232699X
Не тратьте на это время, пока не прочтете и не поймете эту книгу.
Вы не хотите (или не нуждаетесь) в балансировщике нагрузки с единственной точкой отказа.
Вы хотите простого Wackamole решение для распределения нагрузки.
И вам нужна единая база данных, используемая всеми вашими интерфейсными PHP-серверами.