Создание отказоустойчивого кластера для интернет-магазина (продолжение темы)

Архитектура более или менее стандартная для высоконагруженных приложений.

На входе стоит nginx, который раздает статику и картинки.

Далее идет Apache. Транзакционные данные хранятся в MySQL, нетранзакционные в MongoDB. Для кеширования используется memcached, для поиска с учетом морфологии - Sphinx.

Все это сейчас работает на одном сервере под FreeBSD. Там 48 Гбайт памяти и SAS диски на контроллере LSI с батарейкой.

Memcached отражает примерно 100К запросов в минуту, со временем возрастет в несколько раз.

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

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

Если нужно что-то еще по архитектуре, пожалуйста, напишите.

Как я понял, Вы являетесь разработчиком приложения. Вы сможете переписать часть логики работы приложения если это потребуется для кластеризации ?

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

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

Есть возможность продублировать работу сервиса на тестовом сервере с демо данными ?

Не два а четыре

Чтоб небыло задержек бери шасси сразу с оптикой, они стоят от $20k

Как это делать я рассказывал на видеопризентации, она есть в моей теме

Дальнейшее обсуждение предлагаю перенести туда

вот опять свою шарманку завел

Там все конфиденциально, логику работы описать не сможем, особенно детально. Она, кстати, очень сложная, а внесение изменений очень трудоемкое. Хотелось бы получить решение на системном уровне. Видимо, допускается разнесение сервисов по хостам, но с обеспечением быстродействующего канала передачи данных. Сейчас ведь все в оперативной памяти одного хоста, и работает быстро, а вот если разнестим по хостам - не уверен.

Собственно, помимо чисто аппаратной кластеризации от IBM рассматриваю возможность выделения в кластер сервер приложений, т.е. будет балансировщик, Апач с nginx, отдельно кластер MySQL, отдельно кластер MongoDB и Sphinx.

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

Аппаратная кластеризация не защитит от необходимости обновления ОС, версий ПО и т.д., а также возможных ошибок в работе серверов приложений. Не всегда все возможно обновить без перерыва в работе. Обеспечение дублирования приложения даст больше возможностей для маневров при плановом техническом обслуживании.

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

На данном этапе мне нужно подобрать архитектуру кластера и решение, найти тех, кто сможет сконфигурировать системные средства, понять, во что все это обойдется заказчику. А приложение мы будем переносить на кластер уже силами своих программистов. Т.е. конфигурирование системных средств, возможно, мы бы могли отдать на аутсорсинг, а лучше бы выполнили сами по описанию. В теории можно ведь установить самостоятельно ISP Manager Cluster, там есть какая-то инструкция и установщик.

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

В этом плане с точки зрения прозрачности и понятности мне нравится предложение ISP Manager Cluster, но как я уже писал, в стндартной конфигурации у них NFS и с гарантированной реакцией на заявки не очень понятно.

NFS тут совершенно не причем. ISP Manager Cluster разрабатывается для других задач.

Никто в здравом уме не станет писать howto "как настроить кластер", вы сталкиваетесь с кучей проблем в любом случае.

Как вы себе в принципе представляете работу по обслуживанию ?

Кажется вы все еще сами не знаете чего хотите.

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

Готового продукта на котором "с ходу" заработает ваше приложение вы не найдете. А без доступа к логике его работы никто вам его и не разработает.

Присоединяюсь к мнению V(o)ViK. Если вы опасаетесь предоставлять администратору доступ к уже работающему и организованному кластеру, то как вы себе представляете устранение неполадок, которые (в теории) могут случиться?

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

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

Почему?

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