Репликация Apache

Вам нужна какая-то конфигурация высокой доступности, например, предоставляемая Linux-HA. Для файлов данных я бы использовал DRBD, который представляет собой способ репликации блочного устройства между двумя машинами (хотя обычно только одна машина будет использовать его одновременно - и это нормально, потому что у вас есть только одна машина, на которой одновременно запущен apache).

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

Вы ищете термин «аварийное переключение» - по сути, автоматическое переключение на вторичный ресурс при выходе из строя первичного ресурса.

Хотя настройка кластера серверов - это одновременно отличный учебный опыт и массу удовольствия, это легко становится сложной задачей, и к ней нельзя относиться легкомысленно. Сначала изучите другие альтернативы.

Похоже, вы пытаетесь настроить кластер высокой доступности. Допустим, у вас есть два узла - есть (как минимум) два подхода:

• Активный / пассивный - один узел будет обслуживать данные, другой будет обновляться и в случае отказа «активного» узла станет активным узлом.
• Активный / Активный - оба узла смогут обслуживать данные - и оба должны обновляться. Дополнительная сложность (помимо конфликтов файлов) заключается в том, что оба узла представляют пользователю как единый фронт (преимущество, конечно, заключается в балансировке нагрузки).

Основы кластера

Задумайтесь на мгновение, что потребуется даже для простого кластера:

• Каждому узлу необходимо знать статус / работоспособность другого узла. Обычно это достигается путем отправки «пульса» с заданным интервалом. Кроме того, в многоузловом кластере обычно есть главный узел - этот же уровень обычно определяет такую ​​роль. Для этой цели обычно используются пакеты Heartbeat и Corosync (уровень обмена сообщениями). Если другие узлы перестают получать контрольный сигнал от определенного узла, они реструктурируют кластер, чтобы пропустить этот узел (и, возможно, выберут новый главный узел).
• Ваш кластер должен контролировать отдельные ресурсы (например, Apache) - в некоторых случаях вам нужно, чтобы в вашем кластере в любой момент работал только один экземпляр определенной службы. Pacemaker обычно используется в качестве диспетчера ресурсов кластера.

Репликация файлов

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

• При активной / пассивной настройке только активный узел будет иметь доступ для чтения / записи к данным - другой узел может даже не иметь доступа для чтения. Типичный пример такой настройки будет использовать DRBD (модуль ядра и сценарии пользовательского пространства) в первичной / вторичной конфигурации. Когда первичный узел выходит из строя, вторичный узел может быть повышен и получит полный доступ к своей локальной копии данных (которая была реплицирована с первичного узла).
• При активной / активной настройке оба узла должны иметь возможность читать и (обычно) записывать данные. Для этого можно использовать DRBD (настроенный как dual-primary) (вместе с файловой системой с поддержкой кластера, такой как GFS2 или OCFS2). В качестве альтернативы вы можете использовать распределенную файловую систему, такую ​​как GlusterFS, которая предлагает больше функций, чем DRBD (и ее проще настроить), но имеет дополнительные накладные расходы. Когда оба узла могут писать в один и тот же ресурс, вероятность конфликтов и сценариев «разделенного мозга» намного выше.

Балансировки нагрузки

В кластере, где оба узла активны и настроены для обслуживания запросов, вам необходимо отправлять запросы на каждый узел. Обычно это достигается с помощью балансировщика нагрузки, который располагается перед узлами кластера. В зависимости от ваших потребностей существуют простые и эффективные балансировщики нагрузки уровня 3 (например, сети) (например, Linux Virtual Server) или более сложные балансировщики нагрузки уровня 7 (например, с учетом приложений / контента) (например, HAProxy). Некоторые веб-серверы (например, Nginx) также работают как простые балансировщики нагрузки. Проблема, конечно, затем становится одной из того, как справиться с отказом вашего балансировщика нагрузки (поэтому вам может потребоваться установка двух балансировщиков нагрузки для переключения при отказе).

Менеджеры конфигурации

При взаимодействии всех этих различных компонентов вам может понадобиться что-то, что упростит процесс обслуживания каждого узла и управления различными конфигурациями - для этой цели служат менеджеры конфигурации, такие как Puppet и Chef.

Я очень рекомендую DRBD + коросинхронизация Вы можете найти достаточную документацию на Кластеры с нуля

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

Для файлов данных вы можете использовать какую-либо форму общего хранилища, NAS (nfs или cifs) или SAN; или позволить каждому веб-серверу иметь собственное локальное хранилище, которое вы синхронизируете через определенные промежутки времени.

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