схема отказоустойчивости и балансировки для веб-ресурса

На отдельном сервере можно поставит haproxy, и им балансить на два идентичных сервера, где будет крутиться WordPress.

Точкой отказа будет сервер с Haproxy - в идеале его тоже нужно задублировать Haproxy + keepalived(для перекидиывания IP).

Но в этой схеме получается будет использоваться 4 сервера/виртуалки.

Ну вот тебе схема https://images.lessmore.pw/media/images/lor.png

Если на то пошло, можно ставить keepalived сразу на серверы с nginx, зачем 2 раза проксировать. Тут проблема не в том как балансировать.

балансить на два идентичных сервера

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

Второе - как добиться идентичности БД и распараллеливание нагрузки (выбор типа репликации, например).

Возможно большую часть нагрузки дает БД, тогда можно было бы обойтись какой то репликацией мастер-слейв + распаралеливание запросов на чтение. А код и контент просто регулярно бекапить.

Да, согласен, в случае с нагрузкой на БД все проще, можно её потюнить, для начала, затем сделать Master + Slave.

Если же нагружает сервер - то нужно будет задуматься о кластерной ФС, либо NFS для начала (не отказоустойчиво).

Не думаю что там вообще в БД или железе дело, но чем гадать это можно все замониторить и точно знать. Но скорее всего надо копать в сторону ворпресса.

Тут я так понимаю больше разговор про отказоустойчивость - тогда репликация БД и vIP должны решить проблему.

Мониторить в первую голову. Искать бутылочное горло.

Возможно решением станет не создание какой-то балансировочной системы, а банальное вынесение БД на отдельный сервер. Чаще всего горожение огорода бывает лишним.

upd.

На моей памяти один из высоконагруженных веб ресурсов расширялся в несколько этапов. 1. Вынос БД на отдельную машину. (итого 2 машины в связке) Этого хватило на год. 2. Дублирование веб части для балансировки нагрузки. (итого 3 машины в связке) Этого хватило еще на полтора года. 3. Вынос всего в облако. Было куплено совсем отдельное железо.

Делим задачу на составляющие: 1. база данных 2. application apache2 3. фронт nginx + keepalived

Решаем: 1. запускаем бд на 3х серверах - 1 мастер и 2 слейва, первый слейв пишет текущее состояние, второй отстаёт на вменяемое время реагирования админа, чтобы защититься от дропов и трункейтов кривых рук разрабов/редисок и прочих любителей поковырять прод 2. application поднимаем на всех 3х серверах. рут веба синхрим любым знаемым способом от rsync до небольшого ceph на 3 машинки с дупликацией 2, листим сокет или на нестандартные порты, если IP один для upstream nginx-а или в серую сеть, если есть и белые и серые адреса 3. фронт листим на белые IP ( см 2 пункт по поводу IP ) или просто на стантартные 80 и 443 порты, в upstream вносим все три application сервера с указанием тайм-аутов при отвале ( 503 ) чтобы при выходе из строя nginx не лез какое-то время на фейл и не вызывал ожидание у клиента

оптимальнее для твоей задачи и проще я не вижу. да, чтобы на VIP ( виртуальный IP ) листен порт назначался при «переезде» что-то надо было крутить в sysctl - сейчас не знаю, давно не использую такую схему, уполз на openstack - там другие решения)