Я настраиваю высокодоступный веб-кластер, я планирую начать с двух веб-серверов, подключенных к общему хранилищу (возможно, через NFS). Как лучше всего это реализовать? Должны ли на веб-серверах работать только Apache, а весь веб-контент (html, css) находиться в общем хранилище? Итак, если я решу масштабировать, мне нужно будет только добавить дополнительные узлы Apache? Если я использую CMS, такую как Wordpress, означает ли это, что мне нужно установить Wordpress только один раз (в общем хранилище) и просто продолжать добавлять серверы с Apache, чтобы разделить нагрузку?
Создание очень надежного сервера NFS, на котором работает только NFS, имеет первостепенное значение. Использование системы с двумя головками и одной полкой может дать вам некоторую избыточность, но как только вы попытаетесь перейти на систему с двумя головками / двумя полками, вы столкнетесь с довольно большим количеством проблем. В то время как вы можете запускать главный / подчиненный сервер с двойной головкой / двойной полкой, для двойного основного требуется кластерная файловая система, такая как OCFS или GFS. Итак, шаг первый, создайте очень надежный и очень простой сервер NFS.
Вы можете использовать Heartbeat и запускать свои веб-серверы на периферии, а в случае сбоя одного из них другой отравляет ваш arp и начинает отвечать на запросы. Однако это становится немного громоздким, и в конечном итоге вы захотите поставить балансировщик нагрузки (или пару) перед своими веб-серверами и использовать IPVS / LVS для перенаправления запросов к вашим бэкэндам. С ipvs вы захотите настроить привязку подключения, чтобы пользователи обычно обращались к одному и тому же серверу, что делает все, что использует сеансы php, счастливыми. Вы также можете совместно использовать каталог сеансов на сервере NFS, что позволит обеим машинам получить доступ к одним и тем же файлам сеанса.
MySQL становится забавным. Для запуска кластеризации требуются три узла, однако, с небольшими хитростями, вы можете сделать это с двумя узлами. MySQL не очень хорошо работает с файловыми системами NFS, поэтому вам может потребоваться запустить настройку master / slave с тактовым сигналом для переключения при отказе или настроить пару серверов mysql и запустить их в кластерной настройке.
Ваша нагрузка чтения / записи будет реальным определяющим фактором. Вы захотите установить соединение GigE LAN с серверами NFS и отдельное соединение с Интернетом. Если у вас большая нагрузка на чтение, у вас не будет особых проблем. Если все ваши серверы сильно загружены записью, вы столкнетесь со многими другими проблемами. Если возможно, используйте Jumbo-кадры в локальной сети, если у вас есть большие файлы, которые вы обычно обслуживаете. Поскольку файлы находятся на сервере NFS, если вы используете sendfile с apache, и файл позже будет удален, при следующем доступе к файлу вы получите сообщение об ошибке шины.
Если вы хотите усложнить задачу и выполняете большой объем чтения, вы можете рассмотреть возможность использования AFS, который выполняет небольшие локальные кеши из общего хранилища. Таким образом, если веб-сервер отключится от узла хранения, он все равно сможет обслуживать большую часть статического содержимого. В качестве альтернативы, использование Varnish / Squid или какой-либо другой системы кэширования значительно сократит пропускную способность LAN. Затем у вас есть проблема с одним или двумя серверами Varnish с собственным кешем, дублирующим контент в памяти. Это может быть выгодным компромиссом для уменьшения трафика LAN.
После того, как вы настроили фреймворк, переход с двух веб-серверов на три - это просто вопрос добавления нового сервера. Это шаг от одного до второго, который обычно является большим скачком. Некоторое программное обеспечение ведет себя иначе при работе в кластере, чем при работе на одном компьютере.
Мне это кажется разумным планом. Вы просто хотите масштабировать или устранить единичные точки отказа? В последнем случае ваше общее хранилище также может представлять проблему (и добавлять дополнительную задержку, если чтения не кэшируются локально серверами Apache). Если ваш контент в основном статичен, есть способы создать авторитетное хранилище контента, а затем периодически реплицировать его на свои веб-узлы, чтобы у каждого из них была локальная копия. Это более сложно, но также позволяет централизованному хранилищу выйти из строя, не забирая с собой все веб-узлы.