Назад | Перейти на главную страницу

Хостинг Magento с ограниченным бюджетом

Мне нужно настроить Magento. Мое ограничение - это прежде всего простота настройки и отказоустойчивость / отказоустойчивость. Кроме того, стоимость является проблемой. У меня есть три идентичных физических сервера для выполнения работы. Каждый серверный узел имеет четырехъядерный процессор i7, 16 ГБ ОЗУ и 2x3 ТБ жесткого диска в программной конфигурации RAID 1. На каждом узле работает Ubuntu 12.04. сейчас. У меня есть дополнительный IP-адрес, который можно направить на любой из этих узлов.

Магазин Magento имеет макс. 1000 товаров, из них 50% - комплектные. Я бы оценил, что макс. Активны сразу 10 пользователей. Это подводит меня к выводу, что производительность здесь не главное.

Моя первая идея установки

Один узел (фунт) запускает nginx в качестве балансировщика нагрузки. Дополнительный IP-адрес используется с доменным именем и по умолчанию маршрутизируется на этот узел. Nginx распределяет нагрузку поровну на два других узла (shop1, shop2). Shop1 и shop2 настроены одинаково: на каждом сервере работают Apache2 и MySQL. MySQL настроен на репликацию главный / подчиненный.

Моя стратегия аварийного переключения:

Lb fails => Маршрутизация IP к shop1 (мастер MySQL), продолжить.
Shop1 терпит неудачу => Lb обработает это автоматически, продвинет подчиненное устройство MySQL в shop2 на master, перенастроит Magento для использования shop2 для записи, продолжит.
Shop2 терпит неудачу => Lb обработает это автоматически, продолжайте.

Это разумная стратегия? Кто-нибудь делал подобную настройку с Magento?

Моя вторая идея установки

Другой способ сделать это - использовать drbd для хранения файлов данных MySQL в shop1 и shop2. Я понимаю, что в этом сценарии может быть активен только один экземпляр узла / MySQL, а другой используется в качестве горячего резерва. Поэтому в случае сбоя shop1 я бы запустил MySQL на shop2, перенаправил IP на shop2 и продолжил. Мне это нравится, так как настройка MySQL проще, а узлы могут быть настроены на 99% идентичными. Таким образом, в этом случае балансировщик нагрузки становится бесполезным, и у меня есть запасной сервер.

Моя третья идея установки

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

Не могли бы вы посоветовать, по какому маршруту идти? Кажется, не существует одного "хорошего" способа сделать это. Например. Я читал сообщения в блоге, в которых описывается настройка MySQL master / slave для Magento, но в другом месте, которое я читал, эти данные могут дублироваться, когда подчиненное устройство отстает от мастера (например, когда размещен заказ, клиент может быть создан дважды). Я как бы потерялся здесь.

ПОЦЕЛУЙ

Делайте это просто глупо.

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

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

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

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

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

б) В типичном интернет-магазине с активностью пользователей-администраторов, разработкой, добавлением / удалением продукта это может снизиться примерно на 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 уникальных посетителей за час или около 7 500 уникальных посетителей за день.

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

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

Какова именно ваша цель?

Высокая доступность
Надежность
Простота администрирования
Производительность
Масштабируемость

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

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

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

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

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

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

Кто-нибудь делал подобную настройку с 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-файла).

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

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

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

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

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

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

В итоге

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

Единый сервер?

Я бы никогда не рекомендовал решение, содержащее SPoF (Single Point of Failure) для электронной коммерции.

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

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

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