ПОЦЕЛУЙ

Держите это просто глупо.

Я как бы потерялся здесь.

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

Во-первых, давайте обратимся к оборудованию

Ссылка: https://www.sonassihosting.com/help/magestack/cpu-sizing/

а) Стандартный демонстрационный магазин Magento способен обеспечить примерно 230 уникальных устройств на ГГц в час.

b) Типичный интернет-магазин с активностью пользователя-администратора, деятельностью по разработке, добавлением / удалением продукта может видеть это снижение примерно на 100%, до 115 уникальных значений на ГГц в час.

Используя вашу цифру 100 активных посетителей в любой момент времени,

hourly_hits = (60 / time_on_site (mins)) * concurrent_users

Итак, мы предполагаем, что среднее по отрасли время на сайте составляет 8 минут и 8 просмотров страниц за посещение.

hourly_hits = (60 / 8) * 100
hourly_hits = (7.5) * 100
hourly_hits = 750 

Что дает цифру в 750 уникальных посетителей в час, или около 7500 уникальных посетителей в день.

Для поддержки 750 посетителей в час на скорости 115 уникальных единиц / ГГц - вам потребуется эквивалент 7x 1 ГГц процессорных ядер. Итак, давайте предположим, что ваш i7 Quad Core имеет частоту 2,5 ГГц, что в совокупности даст 10 ГГц.

Во-вторых, давайте обратимся к вашей конфигурации

Какова ваша цель?

1. Высокая доступность
2. надежность
3. Простота администрирования
4. Спектакль
5. Масштабируемость

Ни одна из ваших идей не особенно хороша, ваш балансировщик нагрузки является единственной точкой отказа, и я чувствую, что вы слишком увлеклись избыточностью MySQL.

Мастер-Мастер - это кошмар конфигурации, и вы не получаете никакой выгоды от этого. Magento НЕ связан MySQL, по крайней мере. См. Что я должен поставить на мою большую машину? Magento Веб-сервер базы данных Magento?

И если вы не планируете делать ВСЕ в своей архитектуре избыточным, т.е.

1. Связанные сетевые интерфейсы
2. Переключатели A+B
3. Брандмауэры A+B
4. A+B раздельное питание от разных ИБП
5. Многосетевое соединение в восходящем направлении

... нет особого смысла пытаться создать некоторую устойчивость на уровне программного обеспечения.

Как бы мы это сделали

Кто-нибудь делал подобные настройки с Magento?

В слове. Да.

Мы настраиваем что угодно, от одного сервера до n серверы в MageStack - путем контейнерирования каждого узла.

Таким образом, в вашем случае мы обычно настраиваем следующее (при условии, что вы запросили HA).

**Server 1**        **Server 2**        **Server 3**
LB  (m)    <==>     LB  (s)             
Web (m)             Web (m)             Web (m)
                    DB  (s)    <==>     DB  (m)

Виртуальные серверы LB и DB будут иметь свои корневые разделы на зеркале DRBD (представлено <==>). Веб-узлы будут использовать либо общее хранилище NFS, либо, чаще, репо на живых веб-узлах.

Просто чтобы сослаться на ответ здесь Как организовать веб-серверы с Varnish?

Наша типичная архитектура

lvs (initial ssl load balancing)
 -> pound (ssl-unwrapping) 
 -> varnish (caching) 
 -> haproxy (load balancing) 
 -> nginx (static content) 
 -> php (dynamic content) 
 -> mysql (db)

Heartbeat будет поддерживать проверки работоспособности между компьютерами и обеспечивать восстановление после отказа IP-адреса и запускать / останавливать соответствующие виртуальные серверы.

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

Как я бы порекомендовал вам сделать это

Не используйте master/slave, не используйте DRBD и просто держите его действительно, очень просто - так что вам легко управлять и отлаживать, когда что-то не работает.

**Server 1**        **Server 2**        **Server 3**
LB                           
Web                 Web                 Web 
                                        DB  

Таким образом, вы получаете распределение нагрузки и полное использование оборудования. В худшем случае - если сервер 1 или сервер 3 выйдет из строя - вы извлекаете жесткие диски и помещаете их в сервер 2. С помощью удаленных рук на контроллере домена - это можно сделать в течение ~5 минут. Это будет чертовски простой в управлении сайт, это будет означать, что вам не нужно будет создавать 30-страничный документ о конфигурации машин и процедурах учета заданий, и на настройку уйдет значительно меньше времени.

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

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

В итоге

Я бы не советовал пытаться самостоятельно создавать, управлять и контролировать конфигурацию сервера для магазина электронной коммерции, где хостинг и поддержка являются единственными наиболее важными составляющими поддержания вашего бизнеса в сети.

Один сервер?

Я бы никогда не рекомендовал решение, содержащее SPoF (единую точку отказа) для электронной коммерции.

В настоящее время я работаю над руководством по настройке сервиса Amazon Elastic Beanstalk, которое позволит вам автоматически масштабировать по всем измерениям, оплачивая только те ресурсы, которые вы фактически используете.

Конечно, это все мультизоны и имеет встроенную избыточность и аварийное переключение:)

Техническое обслуживание очень простое - и вы можете обновить ваш Magento либо напрямую, используя инструменты командной строки AWS и git, либо загрузив zip-файл вашего приложения Magento в консоль AWS, - это не так просто!